Как стать автором
Обновить
0
0
Rhaps107 @Rhaps107

Пользователь

Отправить сообщение
Благодарю. То, что нужно.

Благодарю. То, что нужно.

С сильным запозданием я осознал, что хотелось бы анаг с синтаксисом xpath, но для поиска по php-массиву. Наиболее приближенный найденный функционал — jsonpath -http://goessner.net/articles/JsonPath/. Ведь массивы php и json в принципе идентичные типы хранения данных (однозначно представляют друг друга). Костылем можно было бы использовать сам jsonpath, в аргументы ему передавая json_encode от данных шаблона.
Господа знающие, подскажите, может ли бот видеть сообщения, которые написаны в чате, где бот участник. При этом сообщение написано не лично боту (с указанием ника) и не в качестве ответа на сообщение бота. Т.е. просто сообщения из чата, не личные для бота.
После перехода с xslt на twig- или php-шаблоны, очень хочется иметь в шаблонизаторе поиск, хотя бы близкий к функциональности xpath, чтобы ловко жонглировать данными и не думать о их красивой подготовке на стороне модели/контроллера. Есть что-то такое в вашем шаблонизаторе?
readyState == 3

Насколько это стало кроссбраузерно?
Года 3 назад я заметил эту возможность у xmlhttprequest обрабатывать порции данных, но тогда именно вот этот ready state 2 не выдавали какие-то из популярных на то время браузеров.
По пункту 1.
Все рассылки, которые проводит компания REG.RU клиентам своих Партнеров регулируются Договором на обслуживание и Правилами регистрации. Вы можете отключить в своем личном кабинете все некритические уведомления. Нельзя отключить только критические уведомления рассылки, которые регулируют Правила регистрации доменных зон, в которых зарегистрированы домены. Обязанность регистратора – направлять некоторые виды писем согласно Правил регистрации.


Я ни у одного регистратора не видел писем, отправляемых владельцам доменов, зарегистрированных через партнёра, где регистратор предлагает зайти в свой кабинет и заплатить ему. Да, есть уведомления, что домен истечёт, но во-первых упоминается организация, через которую была регистрация. Во-вторых платить регистратору не предлагается.
Как итог этой рассылки — половина клиента впала в ступор, т.к. не работала с регистратором напрямую, а тут вдруг незнакомая им организация просит заплатить. Другая половина заплатила регистратору, продлила свои домены в reg.ru, и лишилась бонусов хостера, который забесплатно продлевал домены при оплате только хостинга, в результате осталась недовольна.

Если у вас имеются индивидуальные пожелания по работе с письмами, просим вас обратиться в отдел по работе с Партнерами и предложениями.


Обращались сразу же по обнаружению подобной рассылки. Нам сказали, что наше пожелание «передано руководству» и более ничего.

Ошибки, которые имели место в работе API при открытии зон .MOSCOW/.МОСКВА были исправлены после их обнаружения. На данный момент времени, ошибок в работе API 2.0 для указанных зон не обнаружено.


Может быть стоит ответить по существу на вопросы, заданные в техподдержку?
Повторяю тот факт, что вопросы туда уже были заданы, ответы по причинам даны так и не были, ответы в духе «разберемся и ответим», но ответа в итоге не было. Мне кажется неэтичным с моей же стороны писать одни и те же вопросы по нескольку раз.

И ещё тот вопрос, который проигнорирован — в документации по API появится какое-то упоминание по.москва и .moscow?
www.reg.ru/support/help/api2
Ни документация, ни даже техподдержка опять-таки не говорила, каким образом должен выглядеть запрос на регистрацию доменов в этих зонах. Я пробовал различные варианты запросов для других зон, ни один из них не завершается успехом. Может быть вы хотя бы здесь эту документацию дадите?

> Лимиты на работу с API являются единственно верным решением при работе с открытым API для неограниченного круга лиц, чтобы обеспечить его бесперебойную работу.

Простой вопрос — почему у r01.ru и nic.ru всё работает и нет лимитов? Партнёров у nic.ru не думаю, что на порядок меньше.
Да, работать можно, но это лимитирование сильно меняет логику общение с сервисом. И это отличие не в пользу API reg.ru.
При работе с reg.ru в качестве партнёра всё ещё хуже, чем в качестве клиента.

1. По контактным емейлам доменов, зареганным через партнёра-хостера, устроили рассылку с предложением заплатить за продление домена себе (в reg.ru) — воровство клиентов у своих же партнёров. Эта тема настолько возмутительна, что достойна отдельной статьи.

2. Провалено внедрение регистрации доменов.москва и .moscow. Эти зоны при запросе через API светились в списке возможных к заказу, однако регистрация их через API не работает и поныне, API выдаёт ошибку. Сколько времени прошло с момента начала открытой регистрации в.москва и .moscow? Вот весь этот период саппорт не дал никакого внятного ответа по причине невозможности регистрации черз API. Документация по API не содержит никакой информации по регистрации этих зон до сих пор. Такое впечатление, что партнёры компании reg.ru вовсе не нужны.

3. Лимитированное API на любой запрос. Я понимаю, почему whois может лимитирован. Но ограничивать вообще любые запросы? Ни у nic.ru ни у r01.ru подобной ерунды нет.

Единственный плюс reg.ru с т.з. партнёра — очень много доменных зон. Т.е. не надо искать нескольких регистраторов.
Но проблемы при использовании API зачастую сводят это преимущество на нет.
ssl_session_timeout 28h;

А чем это обосновано?
У меня ровно такая же специальность, как тут искали — МАИ, факультет радиоэлектроники.
Специализация — радиолокация и радионавигация.
Уровень ~ 0, т.к. ещё учась начал работать программистом. Опыта работы по специальности не было в принципе.
Хотя примерно больше половины озвученных тут вопросов кое-как ответить смогу.
Но диодный мост не помню.

А вот мой тесть имеет такую же специальность, только учился в СПб и работает по ней, немецкой фирме, которая торгует устройствами и компонентами у нас в РФ. Хороший спец. Если надо, могу дать контакты. Правда он далеко уже не студент, конечно.

Ещё есть одногруппник, который тоже по нашей специальности и как раз пару дней назад начал искать работу — vk.com/basist_kaif?w=wall4930_1369
> Код с foreach часто выглядит элегантнее чем код с for, а если знать что он еще и быстрее, то это ли не повод взять за правило использование foreach как основного способа итерации.

Выше описал, что «быстрее» оно только в специально подготовленной пробирке, да и то на громадных массивах и всё равно несущественное.
Так что рекомендовать что-то из for или foreach из соображений скорости — как-то не совсем оправдано.
Рекомендовать эти конструкции с современным движком PHP можно только из соображений удобства использования.
foreach — краткий синтаксис для перебора всех ключей со значениями; for — более длинный синтаксис, но можно использовать его не только для перебора. Смотря какую операцию хотите сделать. Перебрать — foreach. Сделать более хитрый цикл, нежели перебор — тогда for для вас. Вот всё, что сейчас можно порекомендовать.
Вы правы, синтаксис foreach со ссылкой — это ещё одно наследие версий PHP, передававшееся от деда к внуку, и оно давно неактуально. Zend Engine постоянно оптимизируется и синтаксис без ссылки на сколько я помню где-то в четвертых версиях PHP не даёт скорости.
Если оно несущественно, в чем смысл заострять на нём внимание? :)
Вы правы, выбор кавычек и for vs foreach в PHP после версии 3, если не ошибаюсь, не оказывают никакого влияния на производительность и темы исчерпали себя многократно много лет назад.

Полезнее темы в исходниках можно найти от обратного — от проблемы, а уже видя проблему, смотреть в исходники. Я так например в soap баги находил.
Хорошее исследование, но не даёт никакой практической пользы, т.к. время доступа к элементам массива составляет пренебрежимо малый процент от общего времени работы скриптов. Даже если всё переписать в соответствии с вашими наблюдениями, в результате никто ничего не заметит.
> Просто не надо тратить время на подключение каждый раз.

Разумеется, при каждом получении ключа отдельного подключения не происходит, но совсем без подключения к редису не обойтись. Хотя бы одно подключение в одном процессе есть, поэтому оно тоже влияет на время работы и должно рассматриваться.
Или у вас каким-то образом создаётся подключение к redis, расшаренное между процессами? Если да, то научите.

> Либо у вас тестирование было на небольшом количестве данных, либо очень специфическое. Все прекрасно понимают, что файловая система не может отдавать данные быстрее оперативной памяти, за исключением одного случая

Я это тоже понимаю, отчасти поэтому меня и удивляют мои результаты и разочаровывает то, что редис пока не оправдывает ожиданий.
Именно поэтому я и спрашивал — какой скорости удалось добиться другим, чтобы сравнить. И кстати этот вопрос — о скорости получения ключа пока что так и остался без ответа. Зато некто, вероятно, очень мудрый, минуснул. Я что оскорбил чьи-то религиозные чувства, рассказав о своем опыте и задав вопрос? :)
> практически в каждой статье ей посвященной, мы встречаем утверждение о том, что эта база невероятно быстро работает.

Подскажите, а «невероятно быстро», это какое самое быстрое время на операцию подключения и получения значения простого скалярного ключа?
Мне не удалось сделать это быстрее, чем 1 миллисекунда. При использовании для аналогичных целей простого файлового хранилища на локальной машине это время колеблется в порядке микросекунд, т.е. значительно быстрее. Тесты проводились на средненьком VDS с 2мя ядрами и 500 МБ оперативной памяти.
Правила контакта — это ничто и юридически и по факту.
Да, имея емейл и/или телефон, можно пополнить базу спам-знаний очень неплохо. И это действительно плохая особенность данной фичи контакта.

Но это не утечка персональных данных, не надо дезинформировать людей. Персональным данным дана ясная трактовка в законе. Выше я достаточно это обосновал.
Аватар и ник, насколько мне известно, данные не скрываемые никакой настройкой контакта. Т.е. они всегда доступны.
Номер телефона вам не выводит контакт, вы его знаете сами, заранее.
А на выходе получаете и так доступные данные пользователя.
Тут вопрос относительно того, как это квалифицировать очень глубокий и я бы всё же это пока утечкой не называл. :)
Разве это можно назвать утечкой ПД? ФИО вконтактике, это не 100% имя по паспорту. А аватар вообще ничего не говорит. Юридически контакт дает возможность сопоставить ник и аватар из своей базы, которые не являются ПД, по предоставлению ПД — телефона или емейла.
Добрый день, я абсолютный новичок в использовании Redis. Поставил его впервые и более менее познакомился с ним после прочтения этой статьи.
Простое подключение к серверу и получение значения строкового скалярного значения ключа занимает 8-10 мс.
Это довольно много. Например, самодельная система хранения сериализованных значений в файлах делает это примерно в 100 раз быстрее.
Подскажите, пожалуйста, это нормальная ситуация для redis? И можно ли как-то ускорить? Буду благодарен за советы и ссылки.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность