Натолкнулся в разделе QA на интересный вопрос. Ответ на него заставил написать эту статью как бОлее полный ответ на вопрос «как организовать поиск по множеству параметров, как в Яндекс-маркете, например».

Я знаю, что на Хабре, да и вообще есть много сторонников noSQL решений (сам не без греха), но все же я сторонник сначала подумать, а уже потом выбирать решение.

Итак, что имеем в «ДАНО»

• Имеем 120 чекбоксов — вариант 1/0
• Имеем 30 «радио» с выбором «да/нет/не важно»
• Имеем 2-3 слайдера для указания диапазона цен/размера чего нить
• Имеем самое главное: 12 млн записей в БД.
• Имеем Select * From tovar Where (wifi=true) and (led=false) and (type=3) and ….остальные параметры …; со временем выполнения близкому к истерике клиента.

Не секрет, что каждый интернет-магазин должен помогать пользователям найти то, что им нужно. Особенно, если товаров у вас много (> 10). На помощь приходит каталогизация товаров, но разбить товары по категориям — полдела. Товары внутри категории нужно уметь фильтровать по их свойствам. Особенно, если товары у вас разношёрстные, например, одежда, электроника, ювелирные изделия и т.д. И тут любой разработчик, пишущий свой e-commerce продукт, сталкивается с неприятными реалиями жизни: у товаров могут быть совершенно разные свойства, у некоторых товаров они могут отсутствовать, некоторые товары по одному свойству могут попадать под разные значения (цвет платья то ли синий, то ли голубой, соответственно, неплохо бы его показать и по синему и по голубому цвету). Проще говоря, у вас EAV. Бывает ещё, что EAV вам диагностирует заказчик ближе к концу разработки, а то и просит добавить фильтр по динамическим свойствам уже после релиза.

Оказывается, кодовые замки можно делать не только из железа, но и из дерева. Вряд ли его можно использовать на практике, но простая конструкция выглядит довольно изящно. Неплохой проект, чтобы помастерить на выходных. К тому же модель хорошо показывает, как на самом деле работают кодовые замки (ведь ими интересовался даже сам Ричард Фейнман).

Кстати, никто не мешает изготовить всё из железных деталей по тому же принципу — получится настоящий кодовый замок, который можно использовать в деле!

Продолжаем делиться адаптированной подборкой историй об ИТ-стартапах, прекративших работу. Анализ ошибок коллег поможет вам в развитии собственного бизнеса, а ссылки на профили основателей позволят в любой момент обратиться к ним с вопросом [первая часть].

Постановка вопроса

Недавно, во время собеседования в одну крупную компанию мне задали простой вопрос, что такое Load Average. Не знаю, на сколько правильно я ответил, но лично для себя пришло осознание, что точного ответа я на самом деле и не знаю.

Большинство людей наверняка знают, что Load Average — это среднее значение загрузки системы за некоторый период времени (1, 5 и 15 минут). Так же можно узнать некоторые подробности из данной статьи, про то, как этим пользоваться. В большинстве случаев этих знаний достаточно для того, что бы по значению LA оценивать загрузку системы, но я по специальности физик, и когда я вижу «среднее за промежуток времени» мне сразу становится интересна частота дискретизации на данном промежутке. А когда я вижу термин «ожидающие ресурсов», становится интересно, каких именно и сколько времени надо ждать, а так же сколько тривиальных процессов надо запустить, что бы получить за короткий промежуток времени высокий LA. И главное, почему ответы на эти вопросы не дает 5 минут работы с гуглом? Если вам данные тонкости так же интересны, добро пожаловать под кат.

Мы перевели и адаптировали подборку историй об ИТ-стартапах, которые были вынуждены прекратить свою деятельность. Анализ ошибок в их работе поможет вам подготовиться к возможным сложностям на пути собственного бизнеса. В первой части вас ждут истории и основатели первых 50-ти компаний.

^{On s'engage et puis… on voit...}

Вы все еще пытаетесь разработать идеальное устройство или приложение? Боитесь выпуска недоработанного продукта? Откладываете запуск все дальше и дальше?

В 2004 году Гай Кавасаки писал в своей книге «The Art of the Start» об искусстве предпринимательства и вывода новых продуктов на рынок, по опыту работы в Apple. До появления современных технологических гигантов типа Apple и Microsoft, подход, используемый ими для вывода своих продуктов, практически не существовал. В истории успеха двух давних соперников гораздо больше авантюризма, чем нам кажется на сегодняшний день. Это сейчас они обладают огромными возможностями для реализации любых авантюр, в начале же своей деятельности ни одна из них не брезговала идти путем бутстрэппинга.

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



Но машины все еще не люди, и далеко не всегда будет вырезана нужная область. Старые способы типа вырезать миниатюру 100х100 из левого верхнего угла или из центра отходят на второй план, и на арену выходит смарт-кроп.

В программировании самокритика – это умение распознать контрпродуктивные решения в дизайне, коде, процессах и поведении. Знание о вредных шаблонах решений полезно для программиста. В этой статье я опишу анти-паттерны, которые я встречал на своём личном опыте время от времени.

Некоторые из них напрямую или косвенно связаны с когнитивными искажениями человеческого сознания – в этих случаях я даю ссылки на соответствующие вики-статьи. Также интересен список известных когнитивных искажений.

1 Преждевременная оптимизация

В 97% случаев надо забыть об эффективности малых частей программы: преждевременная оптимизация – корень всех зол. Но в 3% случаев об оптимизации забывать не нужно.
Дональд Кнут

Хотя никогда зачастую лучше, чем прямо сейчас
Тим Питерс, Зен языка Python

Что это

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

Почему плохо

На практике сложно предсказать, где встретится узкое место. Попытки навести оптимизацию до получения эмпирических результатов приведут к усложнению кода и появлению ошибок, а пользы не принесут.

Как избежать

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

Перевод статьи Seven Deadly Sins of a Software Project автора Yegor Bugayenko.

Сопровождаемость — это наиболее ценное достоинство современной разработки программного обеспечения. Сопровождаемость может измеряться, в основном, рабочим временем, которое требуется новому разработчику, чтобы вникнуть в проект, до того, как он начнет вносить значимые изменения. Чем больше времени это занимает, тем меньше уровень сопровождаемости. В некоторых проектах это время близко к бесконечности, что означает, эти проекты практически не сопровождаемы. Я хочу рассказать вам о семи смертных грехах, которые делают программный продукт несопровождаемым.

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

Вторая часть серии статей посвящена одному из самых сложных и объемных вопросов о современном PHP — что такое «callable»? Я постарался свести в один текст некий минимум знаний об этом вопросе.

От переводчика: в процессе программирования никогда не забываю о том, что я опасно некомпетентен в криптографии, и всем советую исходить из этого тезиса (ну, может быть кроме вас и еще вон того крутого парня). Однако, так или иначе, в процессе работы возникают задачи, связанные с защитой данных, и их надо решать. Поэтому я предлагаю вашему вниманию перевод статьи финского разрабочика Timo H, которая показалась мне достаточно интересной и полезной.

Важный update: в комментариях SamDark сделал замечание, что библиотека Mcrypt давно не поддерживается и имеет ряд недоработок, поэтому рекомендуется использовать OpenSSL. Если требуется переписывать имеющийся код, то может помочь эта статья. Кроме того, есть сведения, что Mcrypt может быть удален в PHP7.

Это краткое руководство о том, как избежать распространенных ошибок с симметричным шифрованием на PHP.

Будем рассматривать случай, когда данные обрабатываются на стороне сервера (в частности, шифрование происходит на сервере, а данные могут быть получены, например, от клиента в виде открытого текста, пароля и т.п.), что является типичным случаем для PHP-приложений.

Cведения из этого руководства не стоит использовать для создания шифрованных сетевых соединений, которые имеют более сложные требования. Для таких случаев надо использовать spiped или TLS.

Естественно, рекомендации, приведенные здесь, не являются «единственно возможным способом» организации шифрования на PHP. Цель этого руководства — попытаться оставить поменьше места для ошибок и сложных неоднозначных решений.

В последнее время все большую популярность набирают анимации, проигрываемые по мере прокрутки страницы. Однако, я заметил, что подавляющее большинство браузеров не создано для таких анимаций. Прокрутка страниц мышью в них происходит не плавно (как в Firefox), а ступенчато. В результате скролл-анимации на страницах проигрываются тоже рывками. По моему мнению, проблема здесь совсем не в браузерах, а в плагинах, которые используются для создания этих анимаций. Потому что именно они допускают резкие скачки. Я считаю, что для любой анимации должна быть какая-то максимальная скорость воспроизведения, при которой анимация будет плавной, а пользователь сможет понять, что же произошло на странице. Если вы со мной согласны, то плавно и без рывков перемещайтесь под кат.

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

Стресс-интервью – игра, в которую вас могут вовлечь на собеседовании без вашего согласия. Зная правила игры и следуя им, вы избежите нервного срыва и пройдете на новый уровень.

Предлагаю читателям «Хабрахабра» перевод статьи «Mastering Composer – Tips and Tricks» за авторством Bruno Skvorc.



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

На Хабре уже были публикации о DIY-ламповых усилителях, которые было очень интересно читать. Спору нет, звук у них чудесный, но для повседневного использования проще использовать устройство на транзисторах. Транзисторы удобнее, поскольку не требуют прогрева перед работой и долговечнее. Да и не каждый рискнёт начинать ламповую сагу с анодными потенциалами под 400 В, а трансформаторы под транзисторные пару десятков вольт намного безопаснее и просто доступнее.

В качестве схемы для воспроизведения я выбрал схему от John Linsley Hood 1969 года, взяв авторские параметры в расчёте на импеданс своих колонок 8 Ом.

Классическая схема от британского инженера, опубликованная почти 50 лет назад, до сих пор является одной из самых воспроизводимых и собирает о себе исключительно положительные отзывы. Этому есть множество объяснений:
— минимальное количество элементов упрощает монтаж. Также считается, что чем проще конструкция, тем лучше звук;
— несмотря на то, что выходных транзисторов два, их не надо перебирать в комплементарные пары;
— выходных 10 Ватт с запасом хватает для обычных человеческих жилищ, а входная чувствительность 0.5-1 Вольт очень хорошо согласуется с выходом большинства звуковых карт или проигрывателей;
— класс А — он и в Африке класс А, если мы говорим о хорошем звучании. О сравнении с другими классами будет чуть ниже.

Анимация скролла к месту страницы с момента изобретения почти не подвергалась никаким модификациям, никак не украшалась. Да никому и не надо вроде, и так все работает. Говоришь куда скроллить и за сколько нужно добраться. Всё.

Я решил на анимацию скролла посмотреть под другим углом. Не потому что сейчас с ним что-то не так, а потому что можно и поинтереснее. В результате некоторых наблюдений и всплесков фантазии удалось придумать 3 способа для более интересной анимации. В итоге завернул все в плагин «Scrollport.js» с 3 новыми и 1 классическим режимом. Смотрите демо и проходите под кат.

Создание резюме — головная боль для каждого, кто ищет работу. Резюме — это ваша история, которую вы рассказываете рекрутёру или потенциальному работодателю. Согласитесь, что изучать сюжет с лишними подробностями или большим количеством ошибок будет не очень приятно. Мы расскажем вам о том, что пора выбросить из своей истории.

Итак, перейдём к резюме и ошибкам, которые вы совершаете.

Начнём с того, что вы не должны злоупотреблять стандартными словами (ответственный, стрессоустойчивый и т.д.), а также применять чересчур креативный дизайн, который в некоторых случаях может принести больше вреда, чем пользы. Очень часто в резюме закрадывается большое количество деталей, которые раздражают, а иногда даже отталкивают рекрутеров. Для того, чтобы получить приглашения на большее количество собеседований, пробегитесь по своему резюме и убедитесь, что там нет ни одного из этих 38 пунктов.

Год назад мы выпустили контроллер Wiren Board Smart Home. Благодаря невысокой цене и широким возможностям он имел успех среди энтузиастов.

Поэтому мы решили не останавливаться и выпустили новую версию — контроллер для автоматизации Wiren Board 4, к которому написали и новый софт.

Несмотря на название, покупатели часто использовали Wiren Board Smart Home и для совсем не “домашних” задач: сбора климатических параметров, опроса счётчиков и датчиков, удалённого контроля оборудования — то есть в качестве универсального логического контроллера.

Wiren Board 4 (как в железе, так и в ПО) лучше приспособлен для таких задач. Домашних пользователей это тоже коснулось — контроллер стал надёжнее.