Отдел новостей 21 сентября 2015, 10:00

Неделя за 10 ссылок: все дороги ведут в ИТ

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

1. Как интернет нам выживать помогает

«Тутэйшы» программист разработал криминальную карту Минска: можно проверить свой район и дом. В комментариях добавляют, что есть более старый проект на аналогичную тему. Сверившись с обоими картами, могу вас заверить, что редакция dev.by находится в одном из самых безопасных и образцовых мест Минска.

2. Все дороги ведут в ИТ

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

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

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

3. Соседний ИТ-рынок в цифрах

Пульс российского рынка: зарплаты в ИT и так хорошие, поднимать из-за курса их будут только те, кто борется за кадры с Западом.

4. Древности компьютерные

Старички-айтишники вспоминают о бурной молодости и отчасти брюзжат на молодое поколение:

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

Я начал работать в сентябре, но какие-то графики поломались и ещё целый месяц или два у нас не было работы. У меня было достаточно времени для акклиматизации. И это было хорошо, потому что с момента, когда я ступил в это здание у меня появилось ощущение, что я странным образом переместился в параллельную вселенную, где сейчас начало 80-х годов. Ну, знаете, тот случай, когда вам нужно найти некоторую старую документацию и в конце-концов вы её находите внутри древней самописной системы контроля версий, написанной поверх RCS.

В первый же рабочий день я обнаружил, что компания Х использует, вероятно, самый большой кластер VAX в мире для сборки своего продукта. Да, дюжины VAX под VMS, работающих как компилирующая ферма, создающая x86-код. Зачем вообще этой компании понадобилось иметь собственный компилятор С? Ну, у них существовал их собстенный внутренний невероятный язык программирования, который вы можете представить, если подумаете об императивном Erlang с синтаксисом Pascal. Программы на этом языке компилировались в код на С, для сборки которого и нужен был собственный компилятор С. Я не знаю сколько кода было написано на этом их невероятном внутреннем языке, но по моим оценкам — где-то миллионов 10 строк кода минимум.

Да, молодёжь, вот как раньше проблемы решались — через реверсера по вызову: Код 15-летней давности и газета объявлений:

Случилась эта история в 2001 году и началась с того, что в FIDO-шной конференции $CRACK$.TALKS, обычным содержанием которой являлись кряки, объявления о поиске кряков и разговоры крякеров «за жизнь», я увидел нетипичное объявление с вопросом кто мог бы взяться за доработку графической программы. Так как в этой конференции «доработкой» любили называть взлом коммерческого программного обеспечения, например, «отвязку» от аппаратного ключа, а коммерческим взломом я не занимался, то на это объявление я не стал обращать внимания, решив, что тут уж найдутся те, кто выполнит заказ, связавшись с адресатом через личную почту. Однако, через неделю объявление повторилось, мне стало интересно о чем идет речь, и я связался с его автором.

5. Проблематика собеседований и мотивации

Вот тут вот «менеджер по персоналу» учит жизни с завоёванных высот (далее все сопроводительные открытки взяты отсюда).

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

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

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

Для точки по теме, вот свежая статья про стилистку найма и эксплуатации айтишного пролетариата в Amazon:

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

В Amazon работников поощряют к критике чужих идей на совещаниях, работе допоздна (емейлы приходят после полуночи, а вслед за ними приходят SMS с вопросами о том, почему ты не ответил на емейлы), и придерживаются стандартов, которые, как похваляются боссы компании, «неразумно высоки».

ИМХО, ответственность и мотивацию в 21 веке нужно искать как-то иначе, за пределами дедовского тотального контроля плановой экономики. Например, в свежей статье Google — это 2 миллиарда строчек кода указывается удивительная смелая мотивация, которая используется в Google для своих работников — это полный доступ ко всем исходниками компании:

В целом для управления кодом в Google используется собственная VCS, которая называется Piper и которая в свою очередь опирается на серьёзную инфраструктуру, состоящую из 10 дата-центров.

Любопытна статистика, приведённая Рейчел. По её словам, Piper управляет 85 терабайтами данных «Google-кода», в который ежедневно 25 000 разработчиков делают примерно 40 000 коммитов. Таким образом за каждую неделю модифицируются 250 000 файлов и 15 миллионов строк кода. В сравнении с Linux, которая вся насчитывает примерно 40 000 файлов, работа программистов Google выглядит фантастической.Также Рейчел отметила, что сейчас Google и Facebook вместе работают над новой open source VCS, которую можно будет использовать на проектах любого масштаба, сравнимого даже с самой Google. Интересно, что основой будущей VCS является не модная среди разработчиков git, а Mercurial, которую пытаются масштабировать до уровня, с которым приходится иметь дело обоим интернет-гигантам.

6. О вредности и ненужности дедлайнов

В условиях жёстких временных рамок и всестороннего контроля программирование порой превращается в разновидность армейской службы или образец плановой экономики. Не все согласны с продуктивностью подобного подхода. Цитирую отсюда:

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

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

Реальность: 26 миллионов проектов на GitHub, созданные 10 миллионами программистов в основном в свободное время, смотрят на вас как на г**но. Наш соотечественник Игорь Сысоев написал один из популярнейших в мире веб-серверов (Nginx), сидя в тихом углу, где его никто не трогал, и справился с этой задачей лучше, чем некоторые энтерпрайз-конторы.

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

Реальность: программист пилит задачу не «вечно», а в соответствии со своим видением надёжности, качества, поддерживаемости и расширяемости своего решения в будущем. Скорее всего, он разбирается в этом больше вас. И это ваша вина, если вы не прислушались и своё видение до него не донесли.

Миф третий: программисты все — ленивые задницы.

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

Миф четвёртый: мы отчитываемся перед инвестором о сроках.

Реальность: ваш инвестор — папенькин сынок, получивший возможность порулить не своими деньгами. Нормального инвестора интересуют, в первую очередь, финансовые показатели (ARPU, LTV и т.д.)

Под текстом кивают-соглашаются:

Ну, в общем, всё правильно. В большинстве случаев, нафиг не сдались никому эти «сроки» с «дедлайнами».

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

Ссылка по теме: Польза и вред от сроков (deadlines) в программировании.

7. Стратегическое семантическое версионирование 2.0.0

Теория о том, как правильно версии именовать нужно.

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

В качестве решения данной проблемы я предлагаю простой набор правил и требований, которые определяют, как назначаются и увеличиваются номера версий. Для того чтобы эта система работала, вам необходимо определить публичный API. Он может быть описан в документации или определяться самим кодом. Главное, чтобы этот API был ясным и точным. Однажды определив публичный API, вы сообщаете об изменениях в нём особым увеличением номера версий. Рассмотрим формат версий X.Y.Z (мажорная, минорная, патч). Баг-фиксы, не влияющие на API, увеличивают патч-версию, обратно совместимые добавления/изменения API увеличивают минорную версию и обратно несовместимые изменения API увеличивают мажорную версию.

Я называю эту систему «Семантическое Версионирование» (Semantic Versioning). По этой схеме номера версий и то, как они изменяются, передают смысл содержания исходного кода и что было модифицировано от одной версии к другой.

8. О безопасности UEFI

Интересная серия статей (часть 1, часть 2, часть 3) о хронологии развития UEFI, а также об опасностях, от которых она спасает, либо, наоборот, провоцирует:

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

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

9. Дорожная карта веб-программиста

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

Вышел TypeScript 1.6, с встроенной поддержкой ReactJS.

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

webpack + typescript для компиляции, сборки, загрузки, и статических проверок типов.

github.com/rackt/react-router — для того, чтобы структурировать приложение на верхнем уровне. В сочетании с webpack, практически бесплатно делается динамическая загрузка кода.

ReactJS для слоя UI.

Какое-нибудь решение для слоя данных. Я лично беру nestedtypes и React-компоненты с databinding, которые сейчас делаю. Чтобы это считалось «flux», достаточно завести синглтон, играющий роль глобальной message bus, и вместо прямой модификации моделей делать на нем dispatcher.trigger( 'eventname', arg1 ). После чего, модели подписываются на эти события.Забавный паттерн, в общем. Позволяет делать слой данных в стиле SOA, если знать, что это такое. Тока flux-чуваки про это не знают.

И выкидываем все фреймворки. Не нужны.

10. Альтернативное программирование

Набор свежих ссылок по альтернативным направлениям программирования.

Введение в Scheme:

В практике программирования часто возникает потребность в написании небольших скриптов для автоматизации различных административных процессов, тестирования и мониторинга. Так же не редко появляется необходимость встроить какой-либо интерпретатор в приложение или просто создать прототип для проверки идеи. Для этих целей можно использовать различные популярные инструменты JavaScript, Python, Lua, Bash, BAT, PHP и много чего еще. А еще бывает потребность хранить структурированные данные в файлах или передавать по сети, когда речь идет о текстовых форматах обычно используются XML, JSON, CSV, даже KV. Однако несмотря на достоинства и распространенность таких широко известных инструментов меня не оставляла навязчивая идея поиска более гибкого и изящного средства. Таким образом, я однажды обратил внимание на семейство Lisp языков. И Lisp позволил застрелить сразу всех зайцев одним выстрелом, причем красиво и элегантно.

Парадигма ситуационно-ориентированного программирования:

Как известно, существует три вида алгоритмов: линейные, разветвленные и циклические:

Основой всего, что сделано в методологии программирования, включая и объектное программирование стало структурное программирование, предложенное Эдсгером Дейкстрой в 1970-х годах. Одной из основных идей было введение блочных операторов ветвления (IF, THEN, ELSE) и цикличности (WHILE, FOR, DO, UNTIL и др.) вместо проблемного оператора GOTO, который приводил к получению запутанного, неудобочитаемого «спагетти-кода».

FP на Scala: Что такое функтор?

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

В этой статье, не используя теорию категорий с одной стороны и эзотерические языковые механизмы Scala с другой стороны, рассмотрены два важнейших понятия (ко-вариантный функтор и контра-вариантный функтор), которые являются стартовой точкой для понимания всего множества категориальных конструкций, куда можно включить:

Exponential (Invariant) Functor, BiFunctor, ProFunctor

Applicative Functor, Arrow, Monad / Co-Monad

Monad Transformers, Kleisli, Natural Transformations

Что такое красивый код, и как его писать?

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

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

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

Иллюстрации: tut.by, roem.ru, adme.ru, onliner.by, lib.custis.ru

*Мнение колумнистов может не совпадать с позицией редакции.

**В цитировании сохранены авторская орфография и пунктуация.