Вступление

Люди всегда стремились систематизировать музыку, разбивая её на жанры и поджанры. Основным методом такой систематизации был и остаётся «исторический» метод, который можно описать так:
Есть исполнитель K, который играет музыку похожую на жанр L, но явно в этот жанр не вписывающуюся. Сам исполнитель или муз. критик, лейбл придумывают для такой музыки новый под жанр, жанра L – LL. И через R лет жанр LL становится каноническим. Или не становится, в зависимости от результатов «проверки временем». Таким образом, все музыкальные жанры можно соединить в граф, в котором жанр L ближе к корню, а LL – к листьям.

Этот метод является историческим, так как поджанры всегда появлялись позже основных жанров. Т.е. этот способ иллюстрирует развитие музыки, её эволюцию. Но такой граф не совсем корректно иллюстрирует связи жанров друг с другом, с плоской музыкальной точки зрения. Т.е. из двух совершенно разных музыкальных направлений, разных эпох могут появиться поджанры которые будут настолько близки, что значительное число музыкантов будут в качестве своей “лейбы” указывать оба жанра. Но в “историческом” графе они вряд ли будут рядом.
К тому же из-за высокой степени субъективности и сложности исторического метода, не существует “единого дерева жанров”. Насколько я осведомлён, существуют лишь отдельные успешные попытки построить такой граф на уровне отдельных групп близких жанров.

Буду краток, господа, так как хочу лишь донести до вас на мой взгляд достаточно интересное событие: Facebook отказывается от разработки мобильных приложений на HTML 5 и переходит на нативную разработку под каждую платформу.
Марк Цукерберг в свой речи признался, что стратегия разработки HTML 5 приложений не оправдала себя. Он признал, что использование HTML 5 было самой большой ошибкой компании, а итогом стало лишь потерянное время. Как он выразился, «We just were never able to get the quality of it we wanted...» — «мы так и не смогли добиться от приложений такого качества, которое хотели бы». Он не говорит, что HTML 5 — это плохо. Это лишь констатация факта, что в конкретной ситуации данная технология не смогла решать поставленные задачи на должном уровне.

Заинтересовавшиеся могут ознакомиться с более полным текстом тут (текст на английском).

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

Давайте попробуем. Для этого нам необходимо понять по каким принципам идет развитие: внимательно рассмотреть те пещерные технологии, что мы использовали пару лет назад и то, как они превращались в “технологии будущего”, что мы используем сегодня.

Понадобилось быстро подключить SD-карточку к микроконтроллеру, и задача казалась простецкой — добрый микрочип предлагает библиотеки для всего чего угодно ^{(ах, поставить линк на библиотеки — не судьба)}, но после первого взгляда на их код, волосы на голове начали шевелиться.

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



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

Индусский код (не индийский или индейский) — жаргонное нарицательное название для программного кода крайне низкого качества, использующего простые, но порочные принципы «copy-paste».
Почему именно индусский?
По слухам в Индии с некоторых времен существует практика оценки производительности труда программиста на основе количества написанного кода. Чем больше кода, тем больше программист работает, и, следовательно, выше его оклад. Шустрые индусы быстро сообразили, как обманывать неквалифицированных заказчиков.
Полезное замечание от kaladhara
Житель Индии — индиец, а индус — это последователь любого направления индуизма. Таким образом даже чукча преклонных годов, исповедующий шиваизм (и, вероятно пишуший на с++) — индус.

Итак, если вы хотите научиться программировать так как это делают в микрочипе следуйте следующим простым советам…

На Хабре присутствует довольно много бизнесменов, еще больше фрилансеров и работающих по найму.

Большинство из нас (уж я-то точно!) попалось в ловушку жизненной колеи, утверждённой социумом, как стандарт: школа => институт => работа по найму. Кто-то сразу подался во фриланс или бизнес.

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

Приступим к сравнению по набору параметров, которые я считаю наиболее важными, все оценки субъективны — на основании собственного опыта работы по найму + бизнеса, а также опыта работы знакомых по фрилансу.

Летом обещал, что осенью начнем выкладывать функционал с алгоритмами Теории Ограничений в области управления запасами и производства.

Вот, начинаю с запасов.

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

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

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

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

Прочтение этой статьи: 15 минут
Осмысление методики: 10 минут
Ощутимые результаты: 30 минут

Полгода назад команда из нескольких энтузиастов открыла в Питере коворкинг-центр Зона действия. За прошедшее время по всей стране открылся еще десяток центров. Мы решили поделиться своими знаниями со всем нынешними и будущими создателями рабочих пространств. По нашим оценкам, к концу 2013 года, в России будет более 100 коворкинг-центров.

Команда

• Основные роли которые нужно распределить между участниками команды: администратор, дизайнер пространства, технические вопросы, продвижение, ивенты, сообщество, спецпроекты.
• Как правило, в основной команде будет 4-8 человек и еще 5-20 волонтереов или друзей проекта.
• Зарплаты с первого дня. Несколько сильных профессионалов на старте значительно улучшат результат по сравнению с полностью волонтерской командой.
• Коворкинг — это бизнес тысячи мелочей. Все в голове не удержишь, так что нужно использовать вики, гугл-доки или Trello/Basecamp/Asana.

В жизни многих обитателей софтверной индустрии иногда настаёт момент, когда им приходится нарисовать план проекта. Люди, что-то слышавшие об управлении проектами, читавшие книжки на эту тему (особенно книжки, не описывающие конкретную индустрию), а также учившиеся управлению проектами где-либо (в ВУЗе, на курсах и т.п.) чаще всего автоматически выбирают для создания этого плана Microsoft Project. Иногда использование MS Project навязывается руководством, клиентом, процессными стандартами в компании и т.п.

Для софтверных проектов выбор MS Project обычно крайне неудачен и ниже мы объясним почему, но сначала напомним несколько простых фактов о том, как устроены софтверные проекты, особенно в контексте заказной разработки.

Я работаю в компании, которая занимается разработкой заказных учётных систем уже достаточно долго. Примерно столько же времени существует технологический отдел — команда людей, которые разрабатывают инструменты и фреймворки для своих товарищей, а те уже в свою очередь создают системы для заказчиков. Кратко можно сказать, что мы (технологи) унифицируем процесс написания бизнес-логики за счёт собственного ORM, объединяем проектировщиков и программистов за счёт UML-редактора с генераторами кода, предоставляем различные UI элементы управления, позволяющие продуктивно работать пользователям конечных приложений.
В этой статье я хочу поделиться своим опытом относительно процесса создания технологического слоя.

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

Кодекс и долг

• Моя работа — отражение моего мастерства. Лично я отождествляю это с качеством.
• Если я возложил на себя обязательства касательно проекта и сроков сдачи, то я сделаю всё возможное, чтобы сдержать своё слово.
• Это дело чести — выполнять свои обещания. Я готов идти на личные жертвы, чтобы сдержать свое слово.
• Обязательства и жертвы сугубо добровольны и руководствуются лишь внутренней мотивацией. Дополнительное внешнее давление рассматривается как нарушение Кодекса: я уже выполняю свою работу настолько хорошо, насколько могу.

Общение

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

ВНИМАНИЕ, статья устарела, но её всё еще можно использовать в ознакомительных целях
Захотелось внезапно рассказать подробнее об открытом и свободном проекте для управления различными летательными аппаратами (ЛА). Вообще до недавнего времени он был рассчитан только на мультиротороные системы (коптеры), стабилизацию подвеса камеры и в бета версии была стабилизация для летающего крыла, но судя по dev прошивкам в скором времени будут официально добавлены самолеты и вертолеты, а стабилизация полета летающего крыла уже вышла из стадии бета тестирования.

Я – выпускник специальности «Микроэлектроника и полупроводниковые устройства». За годы обучения я разработал множество устройств на микроконтроллерах, участвовал в конкурсах вместе со своей командой и являлся заведующим лабораторией встраиваемых систем. У меня есть мечта – создать в своей стране условия для разработки роботизированных систем и есть план её достижения, одним из пунктов которого является участие в подготовке большого количества профессионалов в этой области.


Я радуюсь, когда будущие инженеры создают свои устройства и расстраиваюсь, когда слышу, как кто-то говорит об использовании Arduino в них.

Это не первая моя статья на эту тему: у меня возникает желание написать такую сразу после прочтения фразы о безграничных возможностях платформы в DIY-топике на Хабре. У меня возникает желание написать об истинной цене деталей после прочтения статьи о покупке конструктора за $200 почти ничего не содержащего (уж простите, запамятовал где видел).

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

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

Одним из самых замечательных и притягательных свойств языка Common Lisp является, безусловно, его система обработки исключений.

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

Механизм «исключений»(или, как они называются в мире CL — conditions) в Common Lisp отделен от механизма раскрутки стека, а это, соответственно, позволяет обрабатывать любые всплывающие в программе исключительные(да и не только исключительные) ситуации прямо в том месте, где они возникли, без потери контекста выполнения программы, что влечет за собой удобство разработки, отладки, да и вообще, удобство построения логики программы.

Наверное, следует сказать, что Common Lisp Condition System, несмотря на свою уникальность в среде высокоуровневых языков программирования, очень близка известным многим разработчикам низкоуровневым средствам современных операционных систем, а именно: синхронным сигналам UNIX и, гораздо ближе, механизму SEH(Structured Exception Handling) из Windows. Ведущие реализации CL основывают такие элементы управления потоком вычислений, как механизм обработки исключений и раскрутка стека, именно на них.

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

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

Итак, представьте себе следующую ситуацию. Так уж случилось, что вам надо отрефакторить очень большой кусок кода, целую подсистему. Строк, эдак, на 200К. Причем рефакторинг явно выглядит очень крупным, затрагивающим базовые концепции, по которым построена ваша подсистема. Фактически надо переписать всю архитектуру, сохранив бизнес логику. Такое бывает, если, например, вы сделали один проект и у вас впереди новый, и вы хотите в нём исправить все ошибки прошлого. Допустим, по первым прикидкам, на рефакторинг надо месяца 2, не меньше. В процессе рефакторинга всё должно работать, в том числе нельзя мешать другим программистам добавлять новые фичи и чинить баги в подсистеме. Часто такой рефакторинг бывает насколько сложен, что совершенно невозможно замерджить старый код в новый, а также невозможно выкатить результат по частям. Фактически вам надо заменить двигатель самолёта на лету.

Примеры из практики, как моей, так и моих коллег:

• Переделать всю работу с базой данных с чистого JDBC на Hibernate.
• Переделать архитектуру сервиса с отсылки-приёмки сообщений на удалённый вызов процедур (RPC).
• Полностью переписать подсистему трансляции XML файлов в рантайм объекты.

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

Многие считают, что тестирование ПО — это поиск ошибок. Иногда я говорю тестировщикам: «не старайся найти как можно больше ошибок, старайся пропустить как можно меньше!», и меня не понимают: а в чём разница?

А разница огромная! В этой статье я хочу рассказать, в чём она заключается, и какие инструменты необходимо использовать для настоящего полезного тестирования.

Идея и реализация: жмем в SublimeText2 сочетание клавиш, получаем панель со списком build-вариантов, автоматически сформированным по файлу выбранной Build System, выбираем нужный вариант и наблюдаем как непосредственно в интерфейсе Sublime Text 2 отображается процесс сборки проекта.

Сразу скажу, что здесь я делюсь своим бесценным опытом совместной разработки плагина ProjectBuild для Sublime Text 2, потому что в результате только опыт и был получен, поскольку, как оказалось, необходимости в реализации данного плагина не было, и весь этот процесс оказался изобретением велосипеда. Печально, но опыт все же бесценен. Повествование будет таким, что о «велосипеде» будет сказано только в конце.

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