Как это вообще взбрело мне в голову?

У каждого хабракомментария есть свой адрес. Строение адреса коментария:
habrahabr.ru/blogs/gtd/135090/#comment_4486120
То что до "#" — это ссылка на топик, а после — якорь, указывающий положение комментария на странице.
Если в комментариях указывать ссылки на другие комментарии, а потом жмякать по ним, то страница будет прокручиваться до нужного места. Еще у самих коментариев есть пара стрелок ↑ ↓ позволяющих перемещаться между ответами на комментарии.
«Эй!» — подумал я, — «что-то в этом есть». Сначала я размышлял над пределом запутанности комментариев, если в них ставить ссылки друг на друга. Но потом понял что тут кроется вообще что-то из элементарного программирования, сильно похожее на машину Тьюринга. Но какой-то детали не хватало, а ссылки в содержании комментариев использовать не хотелось. На помощь пришло добавление в избранное!

Согласно поговорке, программисты — это устройства, преобразующие кофеин в код.

Если спросить первого попавшегося программиста, когда он наиболее продуктивен, — скорее всего, он назовёт ночь. Кто-то пораньше, кто-то попозже. Популярен вариант встать в 4 утра и сделать работу до начала дневной суматохи. А некоторые предпочитают ложиться в 4 утра.

Цель всего этого — избавиться от отвлекающих факторов. Но можно было бы просто закрыть дверь… Что же такого особенного в ночи?

Я думаю, что всё сводится к трём вещам: расписанию творца, сонному мозгу, и яркому экрану компьютера.

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

Желая привлечь еще больше разработчиков, в Google приняли решение организовать самостоятельно специальную программу для обучения программированию под свою мобильную платформу.

Обучающая программа носит название Android Training и уже доступна желающим. Надо сказать, что диапазон тем программы весьма разный: начиная от азов, таких как работа с Layout — затем рассматриваются такие темы как работа с аудио, фото, оптимизация работы батареи — заканчивая вопросами монетизации приложения. Статьи, конечно, сопровождаются инфографикой и примерами кода, а сам ресурс, как обещает команда Android Team, будет развиваться и дополняться.

Думается, что перевод программы Android Training на русский язык может стать одним из лучших руководств по разработке для Android.

Пост-анонс можно посмотреть здесь.

[Android Training]

Хочу рассказать несложное действие по оптимизации рабочего пространства, которое упростит жизнь многим пользователям GNOME Shell, привыкшим видеть в трее иконки любимых IM (Pidgin и др.), Skype или других приложений. В стандартной настройке они находятся в «нижнем» трее, вызов которого осуществляется наведением мыши на нижний край экрана. Неудобство упомянутого «нижнего» трея в плане общения по jabber, skype, icq и т.д. состоит в том, что пропустив от кого-либо сообщение (например, отойдя от ПК), увидеть его при возвращении без дополнительного вызова дефолтного трея невозможно. Иконка же на верхней панели сразу бросается в глаза, поэтому пропустить важное сообщение или не ответить на него вовремя менее вероятно.

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

В сети гуляет довольно много решений для эмуляции многопоточности в php. Чаще всего они основываются на форках, но есть и вариации на тему с использованием curl, proc_open и т.п.

Все встреченные варианты по тем или иным причинам меня не устроили и пришлось написать свое решение.
Набор требований у меня был следующий:

• Использование форков;
• Синхронный режим с сохранением интерфейса при отсутствии необходимых расширений;
• Многократное использование дочерних процессов;
• Полноценный обмен данными между процессами. Т.е. запуск с аргументами и получение результата по завершении;
• Возможность обмена событиями между дочерним процессом-«потоком» и основным процессом во время работы;
• Работа с пулом потоков с сохранением многократного использования, передачи аргументов и получения результатов;
• Обработка ошибок выполнения;
• Таймауты на выполнение работы, ожидание работы потоком, инициализацию;
• Максимум производительности;

В результате получилась библиотека AzaThread (старое название — CThread).

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

Например, встречались такие варианты:

if ($error['type'] == E_ERROR || $error['type'] == E_PARSE || $error['type'] == E_COMPILE_ERROR){…}

или

if(in_array($error['type'], array(E_ERROR, E_PARSE,  E_COMPILE_ERROR)) {…}

В связи с этим решил написать небольшую статью о битовых операциях с примерами их использования.

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

Я ответил: «Что тут действительно интересно, так то, что эти люди отправят трубку с муравьями любому, кто их об этом попросит.»

Этот пост участвует в конкурсе „Умные телефоны за умные посты“

Данный пост посвящен применению шейдеров OpenGL вместе с элементами декларативного языка QML. Тема, на мой взгляд, является актуальной, так как в будущей версии QML 2.0 планируется широко использовать OpenGL, как backend для отрисовки графических элементов интерфейса. Написание шейдеров — тема непростая и целью данного поста является то, чтобы в первую очередь человек, прочитав её, мог сразу же что-то попробовать сделать интересное для себя и поэкспериментировать, получив, например, вот такие примеры:



В конце я приведу полезные ссылки, где Вы сможете посмотреть материал для дальнейшего, более глубокого изучения данной темы, если она конечно Вас заинтересует, и реализовать еще более интересные шейдеры, применив их вместе с элементами языка QML. Работу с шейдерами можно рассмотреть на примере различных элементов QML: ShaderEffectItem, множества классов Qt3D, так же использующих OpenGL и т.д. В данном посте я продемонстрирую несколько примеров, используя элемент ShaderEffectItem вместе с ShaderEffectSource.

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

Рекомендации геймдизайнеру от программиста (архитектора).

Вступление

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

Все слышали про pre poduction, но мало кто знает как именно это происходит. И если про стадию разработки написано много, а про стадию издания — еще больше, то про стадию планирования известно очень мало. В лучшем случае вам посчастливится ознакомится с результатами планирования. А вот как были достигнуты эти результаты? — загадка во тьме.

Этот документ является результатом «разбора полетов» после написания игры Звездная арена для социальных сетей. В этом документе я попытался упорядочить список проблем и решений к которым я и Александр пришли в процессе совместной работы над игрою. Кроме того этот документ является частью большой работы по выстраиванию рабочего процесса создания компьютерных игр.

Я намеренно оставил за кадром другие документы: концепцию, экономическое обоснование и ТЗ для других исполнителей. Это позволило сфокусироваться на одной теме и осветить ее и только ее достаточно подробно.

Я считаю, что каждый программист должен написать свой компилятор.

Я сам долгое время считал, что создание компиляторов — это удел элиты, а простому смертному программисту не постичь этой науки. Попробую доказать, что это не так.

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

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

Каждый блинчик в меню Теремка — всего лишь набор из примерно 8ми ингредиентов. С такой простой периодической таблицей элементов компания заработала 1.9 млрд долларов в прошлом году (нет, не Теремок, а всё-таки Taco Bell).
Чем больше я программирую и проектирую системы, тем больше я понимаю, что в множестве случаев можно достигнуть желаемого результата банально сочетая базовый набор инструментов, данный нам Unix. В конце концов, функциональность — это ценность, а код — это задолженность. Это утверждение обратно абсурднму тренду DevOps (разработчико-админов), исходя из которого системные администраторы начинают писать юнит-тесты и прочие вещи, чтобы помочь разработчикам, и гласит что программирование в стиле Теремка это разработчики, которые знают достаточно об администрировании (и Unix в целом) так, что они не изобретают велосипед, и приходят к простым и масштабируемым решениям.

Вот конкретный пример: представьте, вам нужно скачать и записать на диск миллионы веб-страниц для дальнейшей обработки. Как это сделать? Детки-крутышки скажут, что нужно написать распределённый паук на Clojure и запустить на EC2, коммуницируя с помощью SQS или 0MQ.

Представляю вашему вниманию перевод статьи под названием "Site Search: Strategies for No Results Found" от Linda Bustos. Перевели в компании UXDepot специально для пользователей Хабрахабра с одобрением компании Elastic Path.

Эта статья написана по мотивам книги Грега Ньюдельмана "Designing Search: UX Strategies for Ecommerce Success". Необычно видеть книгу на 300 страниц, посвященную одному единственному аспекту создания интернет-магазинов, но оптимизация поиска по сайту действительно заслуживает такого внимания!



Есть одна составляющая оптимизации поиска по сайту, на которой мы часто зацикливаемся: как удержать пользователя на сайте, даже если в результате поиска ему не удалось найти то, что требовалось. Статья основана на разделе "No Search Results Strategy: Not a Zero-Sum Game" вышеупомянутой книги. Ньюдельман говорит о том, что «нет простого набора правил, которые гарантировали бы успешное внедрение страницы результатов поиска в случае, когда не было найдено ни одного совпадения. Но есть четыре принципа, от которых стоит отталкиваться»:

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

Безусловно в этом списке вы обязательно найдёте уже знакомые расширения, однако огромный пласт полезных расширений всегда остаётся в стороне. Так что приготовьтесь установить ещё парочку расширений! :)

Встроенные инструменты разработки в Firefox

Перед началом списка было бы неправильно не упомянуть об инструментах, уже встроенных в Firefox. Здесь речь идёт о тех самых инструментах разработки в Firefox Aurora 10 и том функционале, который сегодня можно найти в любом современном браузере.

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



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

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

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

Понятно, что напрашивающийся (и правильный) ответ — «Потому что код приходится не только писать, а и читать». Едва ли этот ответ стоит целого поста, но автор им не ограничивается.

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

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

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

Приветствую, хабровчане!
Представляю вашему вниманию перевод статьи IT аналитика-предпринимателя-инвестора Стива Гермона о предстоящих распрях между любимыми нами компаниями.

В мире много известных троиц, таких как три мушкетера, Пэрис Хилтон, Бритни Спирс и Мадонна. Но битва за информационную среду произойдет именно между этими тремя: Apple, Google и Microsoft.

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

В настоящее время существует много стандартов наименования переменных, но два из них являются наиболее популярными среди программистов: это camel case («Верблюжья» нотация) и underscore (именование переменных с использованием символа нижнего подчеркивания в качестве разделителя). Кто-то может возразить, что существуют и другие популярные стандарты, но в рамках данной статьи мы сравним эти два, и узнаем у программистов — какого стандарта придерживаются они. Конечно, некоторые программисты связаны рамками стандартов кодирования языка или фреймворка, который они используют, но мы постараемся сделать независимое сравнение.

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

Я всегда мечтал создать робота, которым можно управлять с помощью компьютера и смотреть за его перемещениями от первого лица.
Весь процесс я условно разделил на три части:
1. Сборка робота
2. Программирование боротового микроконтроллера
3. Программирование управления с ПК