Вот это уже интересно! Во-первых, не ожидал, что empty / isset быстрее всего прочего. Во-вторых может мне кто-то объяснит, почему функции «_key» быстрее обычных (типа in_array)? С точки зрения «и там и тут строки, массивы строк», алгоритм должен быть одинаковым. К сожалению, я программирование больше как вычислительные приложения в ВУЗе учил (специальность не программистская), а дальше (несколько позже) — довольно много вещей просто делал на php.
Хэшсет O(m) вы все равно как-то будете строить? Все равно ключ или значение придется сравнивать с образцами, нет?
Это внезапно второй элемент будет :)
ОК, хотя (про intersect), возможно решение на Си нативной функцией php будет побыстрее самого php-кода. Принципиальной же разницы между object-> toArray() и последующим in_array() (с перебором 5 проверочных значений против массива значений из объекта) против flip+array_key_exists() + такой же перебор, но по ключам, вообще не вижу.
Ну или приведите, пожалуйста, код/псевдокод, чтобы было понятно, чем array_key_exists тут «правильнее» in_array.
Ну про array_push некритично, но можно глянуть в доку, где написано, что лучше вставлять «по-простому».
А про array_flip/in_array , ну может стоит поглубже копнуть функции работы с массивами (а то у меня почти фейспалм), ибо там есть вообще array_intersect, который решает задачу «в лоб» без перебора. Вот только не каждый объект сразу преобразовывается в массив, поэтому иногда просто перебор + проверка значения быстрее чем перебор не всегда предсказуемого результата после array_flip.
Я исключительно в смысле «человек-Солнце» :) .
Работающая — нет. Перерабатывающая — да. То же относится и к отцам, и ко всем. Жизнь — не только ради работы. А дети уж точно важнее.
Здравствуйте, господин Туркменбаши.
ОК, вы проводите на работе 10 часов вместо 9 (или 11, если +1 час вечером). Потом ещё 2 часа на дорогу. В сутках 24 часа.
Мое мнение — на таких условиях, если у вас нет кого -то (родителей или жены), кто как минимум вам поможет по хозяйству, вы на такой работе обречены. Или работа обречена на то, что вы её рано или поздно покинете побыстрее. Если не хотите всю жизнь посвятить этой работе, конечно.
И, хм, где тут «не фанатичный»? :-)
Хе-хе, вот за «вторую величину» вашей компании будет выставляться большой и жирный минус.
Да потому что частые овертаймы для многих — это повод попрощаться с компанией. Саморазвитие — да, полезно, а подчинять всю свою жизнь работе (и «выкладкам на 300%») просто вредно для здоровья, любой сферы жизни (включая личную) и т.п.
Сколько ваши постоянные «овертаймщики» часов в будний день проводят с детьми? Помогают детям со школой? С семьей? С родителями? Высыпаются ли?
Можно нормально выкладываться на 100%, успевать многое в офисе за 8 часов, и в случае «авралов» хорошо помочь с проектом в овертайме. Но если овертаймы — это система, то, простите, для людей, которые работают, чтобы жить (а не «живут ради работы» — т.е. кроме работы должна быть ещё масса видов деятельности, как в общем-то и заведено у большинства нормальных людей) нормальное существование в такой компании невозможно.
Исходя из статьи у вас слишком странная «система управления», которая категорически не подходит людям (как семейным, так и без семьи), которым необходимо «тянуть» и тянуть хорошо не одну только работу в этой жизни.
личных водителей CEO украинских офисов :)
Маркетологи — не разработчики. Сайт — для разработчиков.
Что же касается людей, имеющих отношение и к разработке и к SEO — они тут попадаются и дают интервью: некольких персон из Яндекса (который именно SE) вы можете найти на сайте.
Тупо украинский Белый дом. В Вашингтоне.
Виктор, я сам немножко такой. Но как только от меня, как «фулл-стека» хотят раскапывания кроссбраузерного ада (да, чтобы в ИЕ, ФФ, Хроме и Сафари совпадало все до пиксела, при этом блоки генерируются динамически, и несмотря на кроссбраузерный jQuery и прочие плюшки рендеринг блоков отличается на +/- 3 пикселя, за что просто жестко трахают мозг) — мне как-то перестает хотеться быть «фронтендщиком». Особенно когда сверху ещё накидывают чисто верстальщицкие задачи (ага, опять с кроссбраузерным адом), и приговаривают «ты теперь у нас и по фронт-энду, значит должен уметь всё, это твоя работа» — мне в такой ситуации хочется откреститься и уйти в тот самый бэк-энд, который я и знаю чуть лучше, и который «друг от друга» отличается в худшем случае только версиями языков, серверов и клиентов баз данных (ну и окружением, единым в пределах сервера, слава богу, для любых клиентов «снаружи»).
Когда коллеги-руководство жестко имеют мозг коллегам за каждый кривоватый рендеринг на экзотическом мобильном клиенте (а фронт-энд делается на вполне грамотных кроссбраузерных библиотеках, т.е. изначально костылей нет) — просто нет желания уходить в дебри фронт-энда. Я это оставлю людям с более крепкой психикой.
Есть одна проблемка — хорошим full-stack при этом быть крайне сложно. Если вы легко сгенерируете фронтэнд со всеми совместимостями с разнообразными браузерами, скорее всего у вас «поплывут» нетривиальные запросы к БД, или, от незнания, вы будете 10 строчками делать операцию, выполнимую одной функцией сервер-сайд-языка.
Или, даже зная эти функции, вы не будете на сравнимом уровне по вашему сервер-сайд фреймворку в плане качества разработки. Я плавал и знаю, более того, видел наглядные примеры, только для случая MySQL/PHP/Javascript + популярные фреймворки. Уметь fullstack, конечно, неплохо, но «быть специалистом во всем» — это быть дилетантом.
Да ладно, а как же Кубунту/Убунту?
Кто-то имея другие корни получает в итоге гражданство Израиля и там и живет.
a[1] — это a[0]? Вы противоречите написанному выше (если a — массив с автоматически заполненными числовыми ключами).