Андрей Аксенов (shodan, Разработчик поискового движка Sphinx)

Поиск устроен вот так:



Индексация – по большому счету, ничего сложного. Понятное дело, что по малому счету, там в каждой из трех «деталей» спрятан не то, что демон, а целое где-то стадо, где-то легион, не совсем понятно. Но концепция всегда простая. Все начинается с маленького простенького патчика к Многосерчу, а потом 15 лет этой херней занимаешься.

Берешь документы, разваливаешь их на ключевые слова. И просто взять и развалить документ на ключевые слова «мама, мыла, раму» – это ты не далеко ушел от grep’а, потому что потом все равно эти ключевые слова перебирать. Надо строить некую спец. структуру – полнотекстовый индекс. Вариантов для его построения человечество придумало в свое время довольно много, но, слава Богу, от всех отказалось и в нормальных продакшн системах, по большому счету, победил на данный момент вариант ровно один. Про него и буду рассказывать. Все остальные имеют скорее историческое значение, что ли, и практического интереса не представляют.

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



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

Перевод pdf файла с сайта http://www.mcdonaldland.info/ с описанием 23-х шаблонов проектирования GOF. Каждый пункт содержит [очень] короткое описание паттерна и UML-диаграмму. Сама шпаргалка доступна в pdf, в виде двух png файлов (как в оригинале), и в виде 23-х отдельных частей изображений. Для самых нетерпеливых — все файлы в конце статьи.

Под катом — много картинок.

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

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

Кто я такой? Да в общем-то, обычный разработчик. Работаю с битриксом с ноября 2010 года (5.5 лет). Работаю только с битриксом, не сделал ни одного коммерческого проекта на других CMS, не использовал фреймворки в создании сайтов. По роду деятельности я занимаюсь в основном интернет-магазинами, их созданием, поддержкой и развитием.

«В 1997 году Deep Blue обыграл в шахматы Каспарова.
В 2011 Watson обставил чемпионов Jeopardy.
Сможет ли ваш алгоритм в 2013 году отличить Бобика от Пушистика?»

Эта картинка и предисловие — из челленджа на Kaggle, который проходил осенью прошлого года. Забегая вперед, на последний вопрос вполне можно ответить «да» — десятка лидеров справилась с заданием на 98.8%, что на удивление впечатляет.

И все-таки — откуда вообще берется такая постановка вопроса? Почему задачи на классификацию, которые легко решает четырехлетний ребенок, долгое время были (и до сих пор остаются) не по зубам программам? Почему распознавать предметы окружающего мира сложнее, чем играть в шахматы? Что такое deep learning и почему в публикациях о нем с пугающим постоянством фигурируют котики? Давайте поговорим об этом.

Open Source проекты с каждым днём набирают всё большие обороты, появляются новые, активно развиваются популярные.
Такие проекты как Bootstrap, Angular.js, Elasticsearch, Symfony Framework, Swift и многие другие привлекают новых разработчиков, их сообщество растёт. Всё это даёт огромный рост проектам, а самим разработчикам интересно поучаствовать в разработке чего-то, чем пользуется весь мир.

Я, как и многие другие программисты, не устоял и также время от времени участвую в разработке Open Source проектов, в основном на PHP. Но когда я начинал, я столкнулся с проблемой — я не знал, как правильно организовать процесс «контрибьютинга», с чего начать, как сделать так, чтобы мой Pull Request рассмотрели и т.д.

Всем начинающим «контрибьютерам», которые столкнулись с похожим проблемами, добро пожаловать под кат.

Привет Хабр. История начинается с того что мы решили сделать гео сервис с возможностью размещения меток на карте самими пользователями.
И когда решили залить в базу 1 миллион маркеров то поняли, что даже если запрашивать маркеры только в определенном радиусе то все работает очень медленно и кластеризация на клиенте тоже не вариант :)

А где-то под этим лесом находится манхетен

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

Слышали ли вы про PHP-функции realpath_cache_get() и realpath_cache_size()? А может быть про параметры realpath_cache_size и realpath_cache_ttl в php.ini?

Кэш realpath — довольно важный механизм PHP, который нужно иметь в виду. Особенно, когда приходится работать с символическими ссылками, например, при деплое проекта. Настройка кэширования realpath может значительно влиять на быстродействие сервера и нагрузку на дисковую подсистемы сервера. Этот параметр был введен в версии 5.1, когда начали появляться первые PHP-фреймворки.

Далее мы разберемся, как все это работает под капотом, и как с этим жить. Под катом много ссылок на исходники.

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

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

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

Слышали что-то подобное от коллег или может быть у самих возникали подобные ситуации? Тогда вот вам пятничный пост с примерами про приведение типов, как это работает с оператором ==.

Буду краток, дальше будут только примерчики. А к тебе, дорогой читатель, просьба. Некоторые ответы спрятаны под спойлер. Перед тем, как заглянуть в ответ под спойлером, попробуй ответить сам. За каждый правильный ответ заслуженно прибавляй себе по баллу. В конце поста в опросе не забудь проставить свой результат. Договорились?

Вторая часть довольно подробного и интересного изложения материала, касающегося кэша и его использования. Часть 1.

Автор, Mark Nottingham, — признанный эксперт в области HTTP-протокола и веб-кэширования. Является председателем IETF HTTPbis Working Group. Принимал участие в редактировании HTTP/1.1, part. 6: Caching. В настоящий момент участвует в разработке HTTP/2.0.

Текст распространяется под лицензией Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.

От переводчика: об опечатках и неточностях просьба сообщать в личку. Спасибо.

Здравствуйте, коллеги.

Сегодня мы хотели затронуть такую многогранную и противоречивую тему, как фреймворки JavaScript. За последние несколько месяцев в издательстве неоднократно обсуждались перспективы издания книг и по Angular.js, и по Knockout.js, а книга по Backbone.js у нас выходила в прошлом году. Следующий материал призван помочь разобраться в сильных и слабых сторонах различных фреймворков JavaScript. Возможно, после изучения статьи читателю будет проще ответить на вопросы о том, так ли схожи эти фреймворки, и желает ли он дополнительно изучить какую-то из технологий, упомянутых в этом обзоре. Мы же попросим вас поделиться вашими соображениями о том, нужны ли новые книги по этим фреймворкам, если да — то по каким (высказываемся в комментариях, не стесняемся давать ссылки на книги).

Разработка веб API это нечто большее чем просто URL, HTTP статус-коды, заголовки и содержимое запроса. Процесс проектирования – то, как будет выглядеть и восприниматься ваш API – очень важен и является хорошей инвестицией в успех вашего дела. Эта статья кратко описывает методологию для проектирования API с опорой на преимущества веба и протокола HTTP, в частности. Но не стоит думать, что это применимо только для HTTP. Если по какой-то причине вам необходимо реализовать работу ваших сервисов используя WebSockets, XMPP, MQTT и так далее – применяя большую часть всех рекомендаций вы получите практически тот же API, который будет хорошо работать. К тому же полученный API позволит легче разработать и поддерживать работу поверх нескольких протоколов.

Хороший дизайн затрагивает URL, статус-коды, заголовки и содержимое запроса

Обычно руководства по проектированию Web API фокусируются на общих концепциях: как проектировать URL, как правильно использовать HTTP статус-коды, методы, что передавать в заголовках и как спроектировать дизайн содержимого, которое представлено сериализованными данными или графом объектов. Это всё очень важные детали реализации, но не настолько в смысле общего проектирования API. Проектирование API – это то, как сама суть сервиса будет описана и представлена, то что вносит значительный вклад в успех и удобность использования Web API.

Хороший процесс проектирования или методология предоставляют набор согласованных и воспроизводимых шагов для создания компонентов сервисов, которые будут доступны в виде Web API. Это значит, что такая прозрачная методология может быть использована разработчиками, дизайнерами и архитекторами для координации своих действий по реализации ПО. Использованная методология так же может уточнятся со временем по мере того, как улучшается и автоматизируется процесс без ущерба для деталей методологии. На самом деле, детали реализации могут меняться (например, платформа, ОС, фреймворки и стиль UI) независимо от процесса проектировки, когда эти две активности полностью разделены и задокументированы.

Сегодня объекты используются очень активно, хотя это трудно было предположить после выхода PHP 5 в 2005 году. Тогда я ещё мало что знал о возможностях этого языка. Пятую версию PHP сравнивали с предыдущей, четвёртой, и главным преимуществом нового релиза стала новая, очень мощная объектная модель. И сегодня, десять лет спустя, около 90% всего PHP-кода содержит объекты, не изменившиеся со времени PHP 5.0. Это убедительно говорит о том, какую роль сыграло внедрение объектной модели, неоднократно улучшавшейся на протяжении последующих лет. В этом посте я хотел бы рассказать о том, как всё устроено «под капотом». Чтобы люди понимали суть процессов — почему сделано так, а не иначе — и лучше, полнее использовали возможности языка. Также я затрону тему использования памяти объектами, в том числе в сравнении с эквивалентными массивами (когда это возможно).

Я буду рассказывать на примере версии PHP 5.4, и описываемые мной вещи справедливы для 5.5 и 5.6, потому что устройство объектной модели там почти не претерпело изменений. Обратите внимание, что в версии 5.3 всё не так хорошо с точки зрения возможностей и общей производительности.

В PHP 7, который пока ещё активно разрабатывается, объектная модель переработана не сильно, были внесены лишь незначительные изменения. Просто потому что всё и так хорошо работает, а лучшее — враг хорошего. Были добавлены возможности, не затрагивающие ядро, но здесь об этом речи не пойдёт.

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

Даже если ваши дети не хотят в будущем зарабатывать на жизнь программированием, базовое понимание принципов программирования развивает мышление и, в дальнейшем, ребенок лучше справляется с решением возникающих задач. Билл Гейтс когда-то сказал: «Если вы учитесь создавать программы, это развивает ваш разум, помогает вам лучше мыслить и создает образ восприятия вещей. В целом, я думаю, что человеку это будет полезно вне зависимости от сферы его деятельности».

Такие платформы, как Scratch и Alice позволяют детям (и взрослым) создавать собственные игры и анимации, используя упрощенные методы программирования. Однако не всем детям это интересно. И вот для таких детей существует множество игр, которые обучают базовым принципам программирования в веселой и доступной форме.

Данный пост я создаю для тех, кто хочет своей профессией выбрать системный анализ и хочет понимать, что его ждёт.
Не так давно я перебрался из Питера в Москву. Работая в небольшой компании, выполнял очень разнообразные задачи, но при поиске работы системным аналитиком в столице понял, что требования к одной и той же профессии, по сути, очень разные. Чем больше компания и проект, тем меньший скоп задач придётся выполнять, и как следствие, тем более узкая будет специализация. Широкий профиль возможен только на небольших проектах, где хватает ресурсов одного системного аналитика.

Вот что входит в его обязанности (обобщённо) в избыточном варианте:

Уже второй раз сталкиваюсь с задачей «поставь https на наш сервер» от моего босса, поэтому решил сделать для самого себя шпаргалку, а заодно и для всех остальных. Итак, ситуация следующая: к нам пришел босс и заявил, что ему нужен https. Под катом я напишу 5 простых шагов, как все сделать буквально за час. Приступим.

UPD: к нижеприведенному материалу поступило множество дельных замечаний, поэтому он был полностью переработан: habrahabr.ru/company/makeitlab/blog/252015

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

Или об особенностях управления отдаваемым контентом в PHP.

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

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

В этой статье я хочу рассказать о том, как реализован слой «буферизации вывода» в PHP, как работает и как с ним взаимодействовать из PHP. В этом слое нет ничего сложного, но многие разработчики либо совсем не понимают, как с ним обращаться, либо не имеют полной ясности. Всё, о чём я буду писать, относится к PHP версии 5.4 и выше. Именно начиная с неё изменились многие вещи, связанные с буфером вывода (БВ). По сути, этот функционал был полностью переписан, поэтому совместимость с версией 5.3 сохранилась лишь частично.

Что такое буфер вывода?

Поток вывода в PHP содержит байты, обычно в виде текста, которые разработчику надо вывести на экран. Чаще всего для этого используется конструкция echo или printf(). Во-первых, нужно понимать, что любая функция, которая что-то выводит, будет использовать БВ из области PHP. Если говорить о расширениях для PHP, то можно получить доступ к функциям, пишущим в SAPI напрямую, в обход любого вышерасположенного БВ. API C задокументировано в lxr.php.net/xref/PHP_5_5/main/php_output.h, отсюда можно почерпнуть немало информации, например, о размере буфера по умолчанию.

Второй важный момент: слой БВ является не единственным слоем, в котором буферизуются выводимые данные.

И третье: в зависимости от SAPI, который вы используете (веб или cli), слой БВ может вести себя по-разному.

Ниже представлена схема, которая поможет понять всё вышесказанное: