Я хочу рассказать вам историю, которая, скорее всего, случится в 2023 году в калифорнийском офисе разработки одной крупной ИТ-компании FAC***GLE. Я думаю, история поможет посмотреть на реальность, окружающую программистов, с новой точки зрения.

Часть первая. Внутри офиса

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

Усики сканера альфа-активности приятно поглаживали виски и Шон чувствовал, что его, как и всегда, «прет»… О, это ощущение демиурга, когда ты видишь воплощение своих строчек кода в чудесных элементах виртуальной реальности.
Шон не зря был ведущим разработчиком — его показатель количества безошибочных строк в день на 4% превышал средний уровень по корпорации, и это в положительную сторону отражалось на зарплатных чеках и разнообразных бонусах.
Компания исключительно хорошо заботилась о своих программистах, которые, в свою очередь, не жалели сил и энергии на самую качественную разработку.

Только что пришло письмо, в котором сказано:
«Мы рады сообщить, что Mars One открывает двери в программу отбора астронавтов. Несколько дней назад мы открыли регистрацию для небольшой группы желающих поучаствовать в программе, чтобы протестировать работу системы регистрации.Теперь Ваша очередь.
Первый этап отбора продлится до 31 августа 2013 года. Форма регистрации доступна на 11 языках, включая английский, немецкий, французский, испанский, португальский, русский, японский, китайский, индонезийский, корейский и арабский.

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

Традиционно, для тех кто не любит много буков, краткие (более-менее) тезисы:

• Будучи долгое время лидером на рынке, Нокиа сильно расслабилась и загадила свою внутреннюю инфраструктуру бюрократией, чрезмерным аутсорсингом и огромным количеством бесполезной «менеджерской прослойки».
• Будучи долгое время лидером, Нокиа просрала потратила много денег на ненужные операционные расходы, поглощения никому не нужных фирм и на невменяемую модель аутсорсинга.
• Полностью оторвавшись от реальности с уходом Йормы Оллилла, Нокиа, под управлением гениального юриста CEO Олли-Пекки Каласвуо, потратила кучу денег и усилий на создание бесполезной и неконкурентоспособной сервисной инфраструктуры Ovi. В результате этого, помимо денег, Нокиа потеряла уйму полезного времени, которое можно и нужно было потратить на развитие основного бизнеса — телефонов, софта и т.д.
• Бюрократия и непотопляемая менеджерская прослойка в Нокиа, последовательно мигрировала из одного передового проекта в другой, в составе одних и тех же групп лиц, самореплицируясь в виде кучи формальных дебилопроцессов комитетов и управленческих групп, немного перетасовываемых с учетом специфики. В итоге именно эта бюрократия убила и Symbian, и Ovi, и MeeGo и остальные попытки догнать уходящий поезд своими силами.
• Борьба с бюрократией и прослойкой в Нокиа зашла в полный тупик.
• У великого CEO Элопа просто не было другого выхода кроме как прибить всю старую, неповоротливую и прогнившую организацию, путем создания альянса с Майкрософтом и переходом на Windows Phone. Тем самым все старые процессы, компетенции, технологии и самое главное — люди резко стали, что называется, «не в тему». И следовательно тем самым можно было под благовидным предлогом прибить этот табун менеджеров, бесконечно рисующих фэнтезийные роадмапы с единорогами и перекладывающих бумаги с левого края стола на правый.
• Новая Нокиа, после 2011 года и старая Нокиа до 2011 года – это две РАЗНЫЕ организации. Их объединяет только общее название и операционка S40 для телефонов Asha.
• Горящая платформа, это не Symbian и не MeeGo. Горящая платформа, это то состояние в которое Нокиа загнали годы расслабленного лидерства и тупоголовые амбиции предыдущего CEO – Олли-Пекки Каласвуо с кликой подкаркивающих вице-президентов.
• С бюрократией и бизнес процессами, имеющимися на 2010 год, Нокиа не спас бы ни Андроид, ни половина населения Бангалора, пишущих на Qt под MeeGo. Даже если бы Apple бесплатно передал Нокиа iOS и все сервисы, то они бы выродились руками всяких Requirement Managerов в типичные Нокийские дизайн-химеры и в итоге загнулись через какое-то время.
• То, что сделал великий CEO Элоп – было единственно возможным разумным решением, дающим хоть какие-то шансы на выживание. Вопрос «каким образом он это сделал?», остается открытым, равно как и вопрос «поможет ли это Нокиа?» в итоге. Не следует забывать, что нынешняя Нокиа — это совершенно новая организация, поэтому глупо предполагать, что она разом вернет себе лидерство. Как и всем новым организациям ей придется за это лидерство долго бороться.
• Без ошибок и побед Нокиа никогда не было бы ни Андроида, ни Айфона. И Google и Apple тщательно проанализировали достоинства и недостатки более старших конкурентов перед тем как шагнуть вперед.

Все это в деталях — под катом. Предупреждаю что клевых картинок там нет. Сплошное графоманство и ёрничанье.

В далеком (а может и не очень далеком) 1975 году Альфред Ахо и Маргарет Корасик опубликовали статью, в которой был подробно описан алгоритм эффективного поиска всех вхождений всех строк-образцов в заданную строку. В дальнейшем этот алгоритм и получил название «алгоритм Ахо-Корасик». Неудивительно, что через некоторое время появились технические и «художественные» переводы данной статьи на русский язык. Порой мне даже встречались вольные изложения сути алгоритма в том виде, в котором его понимает автор. Причем последний, судя по тексту, узнал об алгоритме далеко не из первоисточника. Я не знаю существовал ли перевод, который послужил первоисточником проблемы, но мне всё больше и больше попадаются статьи с описанием алгоритма Ахо-Корасик, в котором допущена одна и та же кардинальная ошибка. Последней каплей была статья пользователя rmq на хабре, которую данная ошибка не миновала. Собственно об этой ошибке мне и хотелось бы рассказать общественности в своей статье.
Замечание: статья пользователя rmq, как выяснилось позже, не содержит этой ошибки. Как она решена там расскажу ниже. А ему огромное спасибо, если бы не его топик я бы не написал свой и не получил бы инвайт!
Перед началом, еще пара слов о целевой аудитории: Скорее всего, тем, кто давно знаком с алгоритмом Ахо-Корасик, моя статья будет не интересна, так как о его особенностях они давно уже знают. По крайней мере, все мои знакомые программисты не один раз применявшие данный алгоритм знают о существовании его неверных интерпретаций не понаслышке. А вот новичкам и тем, кому не довелось часто применять его на практике, эта статья может оказаться довольно полезной.
Итак, начнем.

Коллеги,

а помните была такая статья-перевод на Хабре Чек-лист разработчика языка программирования Колина Макмиллена о проблемах новых языков программирования? Статья просто изумительная! Если не читали — обязательно посмотрите.

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

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

Асинхронность… Услышав это слово, у программистов начинают блестеть глаза, дыхание становится поверхностным, руки начинают трястись, голос — заикаться, мозг начинает рисовать многочисленные уровни абстракции… У менеджеров округляются глаза, звуки становятся нечленораздельными, руки сжимаются в кулаки, а голос переходит на обертона… Единственное, что их объединяет — это учащенный пульс. Только причины этого различны: программисты рвутся в бой, а менеджеры пытаются заглянуть в хрустальный шар и осознать риски, начинают судорожно придумывать причины увеличения сроков в разы… И уже потом, когда большая часть кода написана, программисты начинают осознавать и познавать всю горечь асинхронности, проводя бесконечные ночи в дебаггере, отчаянно пытаясь понять, что же все-таки происходит…

Именно такую картину рисует мое воспаленное воображение при слове “асинхронность”. Конечно, все это слишком эмоционально и не всегда правда. Ведь так?.. Возможны варианты. Некоторые скажут, что “при правильном подходе все будет работать хорошо”. Однако это можно сказать всегда и везде при всяком удобном и не удобном случае. Но лучше от этого не становится, баги не исправляются, а бессонница не проходит.

Так что же такое асинхронность? Почему она так привлекательна? А главное: что с ней не так?

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

Дело в том, что я занимаюсь технологиями data mining и text mining последние лет пятнадцать. И поэтому все недавние скандалы, связанные с делом Сноудена и PRISM, XKeyScore, Muscular, СОРМ, чтением почты Гуглом, передачей конфиденциальных и гео данных с мобильников, и множество прочих оставили меня абсолютно равнодушным.

По очень простой причине – я уже знаю, что Большой Брат давно существует.



Если точнее, я абсолютно в этом уверен – так же, как не могу знать, что Солнце завтра взойдет, но весьма и весьма в этом убежден. И все новые доказательства существования Большого Брата полезны, но уже не обязательны.
А объяснение уверенности очень простое: при наличии необходимых ресурсов я сам мог бы его построить.

Статья родилась из того, что мне потребовался удобный и простой механизм перехвата для некоторых задач, который легко реализуется техниками АОП. Существует довольно много перехватчиков (Casle.net, Spring.net, LinFu и т.д.), требующих внедрять динамические дочерние классы в IL-код во время исполнения и приводящих практически всегда к одним и тем же ограничениям, накладываемым на перехватываемые классы: не статические, не запечатанные, методы и свойства должны быть виртуальными и т.д…

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

Некоторое время назад уже был опубликован аналогичный пост, с тех пор количество дополнений для Visual Studio 2010,2012 и 2013 перешагнуло планку в 4к, появилось немало новых дополнений. Ниже перечислено 20 наиболее популярных или интересных расширений для Visual Studio 2012 и 2013 в дополнение к предыдущему посту.

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

Представленный здесь перевод является вольным. Однако если под «вольным», как правило, понимают сокращённый перевод, с упущениями, упрощениями и пересказами, то здесь всё наоборот. Данный перевод является немного расширенной, уточнённой и обновлённой версией оригинала. Я выражаю огромную благодарность Сергею Теплякову aka SergeyT, который внёс неоценимый вклад в перевод и оформление данной статьи.

Люди часто испытывают затруднения в понимании различий между событиями и делегатами. И C# ещё больше запутывает ситуацию, так как позволяет объявлять field-like события, которые автоматически преобразуются в переменную делегата с таким же самым именем. Эта статья призвана прояснить данный вопрос. Ещё одним моментом является путаница с термином «делегат», который имеет несколько значений. Иногда его используют для обозначения типа делегата (delegate type), а иногда — для обозначения экземпляра делегата (delegate instance). Чтобы избежать путаницы, я буду явно использовать эти термины — тип делегата и экземпляр делегата, а когда буду использовать слово «делегат» — значит, я говорю о них в самом широком смысле.

Я надеюсь, что эта статья станет началом цикла заметок о lock-free структурах данных. Я хочу поделиться с хабрасообществом своим опытом, наблюдениям и размышлениями о том, что такое lock-free структуры данных, как их реализовывать, подходят ли концепции контейнеров стандартной библиотеки STL к lock-free контейнерам, и когда стоит (и стоит ли вообще) применять lock-free структуры данных.

Я поделюсь 30 практиками для достижения максимальной производительности приложений, которые этого требуют. Затем, я расскажу, как применил их для коммерческого продукта и добился небывалых результатов!
Приложение было написано на C# для платформы Windows, работающее с Microsoft SQL Server. Никаких профайлеров – содержание основывается на понимании работы различных технологий, поэтому многие топики пригодятся для других платформ и языков программирования.

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

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

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

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

Привет тебе, хабраюзер!

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

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

В последних двух выпусках Радио-T ведущие пытались обсудить GIT. Евгений (@Umputun) задавался вопросом зачем нужен rebase и очень удивился, когда я спросил, редактирует ли он коммиты. На мой взгляд, чтоб понять GIT, достаточно вникнуть в процесс разработки Linux Kernel, т к создавался он именно для этого.

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

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

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

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

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

На позицию CTO я пришёл не через стандартный путь “Developer -> Senior -> Team lead -> CTO”, а через гуманитарный вариант – “PM -> Senior PM -> CTO”. В этом были как свои плюсы, так и минусы, и трудно сказать, чего больше, но персональных вызовов хватало всегда и техническое прошлое часто спасало, однако, сейчас не об этом.

4. Вынужденные оценки

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

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

Предыстория

Раньше для поиска по сайту мы использовали обычный fulltext поиск. Но в определенный момент он перестал нас устраивать и мы решили опробовать альтернативную технологию поиска: Sphinx. К сожалению, у сфинкса совсем нет русской документации, поэтому эта статья — аналог статьи Build a custom search engine with PHP, только на русском языке и для моего локального окружения (windows 7, mysql/php)
Статья состоит из 4 частей:

1. Краткий рассказ про подготовку базы для поиска.
2. Рассказ про первоначальную установку и настройку сфинкса
3. Индексирование базы и тестовый поиск из командной строки
4. Тестовый поиск из php