NewsPack# 14: самые интересные ИТ-ссылки за прошлые недели14.10.2015 17:31

Пришло время выкатить в паблик новую порцию свежих и сочных http-ссылок, бережно накопленных за три прошедших недели в священных буферах моего мягкотельного ПЗУ — и это самое интересное, что попало в поле моего поле зрения по теме ИГ ИТ.

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

1. Базы данных

А также два новых видео по теме БД:

Мы хотим рассказать о незаслуженно малоизвестной, графовой/документно-ориентированной базе данных — OrientDB. Эта база данных реализована на 100% на Java, что сильно облегчает её использование в Java приложениях.

Ниже не менее интересное видео: Илья Космодемьянский: «Внутреннее устройство PostgreSQL для практикующих инженеров».

Это двухчасовая видео-лекция об устройстве и проблематике современных СУБД стоит потраченного на неё времени

Возможности PostgreSQL, которых нет в MySQL, и наоборот http://t.co/hqMvwW026T
— Алексеев Алексей (@greenkaktusx) October 13, 2015

2. Оценка компетентности программистов

Пара интересных проектов, посвященных оценке компетенций программиста:

По последней технологии предлагается бесплатный онлайн-тест вашей компетентности.

3. Почему HTTPS — не панацея против утечки данных?

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

Могу лишь добавить по https-проблематике свою серию статей: Это СОРМ, детка.

RT habrahabr: Коллизия для SHA-1 за 100$ тыс http://t.co/Wck3xWq6xh
— Vlsu (@Vlsu) October 9, 2015

4. Айтификация всей страны

Эстония глазами украинцев — статья читается обычным российским айтишником как-то тяжеловато с невольной тоской:

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

По этой же теме присовокуплю другую свежую статью: Энтони Таунсенд об умном городе и интернете вещей:

Город, в котором у каждого второго жителя в кармане смартфон, превращается в smart city. Квартира, в которой лампочка по Wi-Fi узнает о приближении хозяина и включается, становится царством интернета вещей. Вокруг нас много сценариев о том, как меняется наше общественное и частное пространство с приходом в него новых технологий. Чтобы понять, каким из них верить и что применимо к нам, T&P встретились с Энтони Таунсендом — урбанистом, ведущим экспертом NYU, автором книги «Умные города: большие данные, хакеры общества и поиск новой утопии».

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

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

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

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

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

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

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

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

6. Технари учат отдел кадров

Лекция для отдела HR про найм Java-разработчиков:

Из комментариев, насчет советов по оптимизации резюме:

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

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

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

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

Для точки по теме, вот свежая статья про стилистку найма и эксплуатации айтишного пролетариата в 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, которую пытаются масштабировать до уровня, с которым приходится иметь дело обоим интернет-гигантам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А как же истории об успешном проникновении в ИТ? Без этой сквозной темы ссылкобзор был бы, согласитесь, не полным. Понижаем планку: Путь от питерского бомжа до Senior Developer-а.

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

Если вам, как и мне, понравилась эта глубоко личная история, можно покопаться в Facebook автора-героя истории, вот например его 2006 год.

В дополнение ещё одна исповедь прошлой недели, на этот раз «неправильного» программиста: Я разработчик, но это не моя страсть:

Считается, что хороший программист страстно любит свою работу. В вакансиях наряду с «гуру», «суперстар» и «ниндзя» часто встречается «... who is passionate about programming...» в качестве требования к кандидату. Сказать, что ты не очень-то кайфуешь от кодинга, но доволен работой и зарплатой, и на вас как минимум посмотрят косо. Однако, есть большая разница между «не испытывать страсть» и «ненавидеть и не хотеть».
Сегодняшний перевод эссе Антонина Януска посвящен программированию без страсти, программированию как исключительно работе. В наши дни подобное мнение это уже олдскул, чуть ли не архаизм. Сегодня не принято сильно отдалять работу от жизни. Но, возможно, вы увидите в этом мнении что-то близкое себе.

11. Свет в конце туннеля

Ух, как уже достали истории прихода все новых и новых людей в ИГИЛ ИТ. И млад, и стар, и немые и слепые, вот что цифра животворящая делает! Но после частого чтения вот этого всего невольно просыпаешься среди ночи с томящим душу вопросом: а есть ли выход из ИТ наружу? Да! Оцените далее, какова незамутненная чистота жизнеописания, буквально два абзаца — и вся личная философия разложена по полочкам:

Я считал себя хорошим программистом. Я сидел и вторую неделю программировал на Action Script II. Кто имел опыт общения с этим языком и вообще со средой Flash, может подтвердить, что это довольно ублюдочное занятие — отладить в нём что-то многомодульное, многокомпонентное и написанное не тобой. В итоге через 12 бессонных ночей я закончил работу.
За этот проект мне заплатили 2 000 долларов (около 60 000 рублей по тем временам), которых мне копейка в копейку хватило на ремонт моей машины после аварии. Которая случилась через 15 минут после того, как мне перевели деньги... В этот момент я принял решение перестать программировать для клиентов и заняться управлением своей компанией.

В результате этого невольного инсайта простой бренный программист буквально встал из-за клавиатуры, вышел из своего офиса и ушел стопами прямиком в небо: Как перестать работать программистом, получить лётные права и купить свой самолёт.

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

12. О Google и современной работорговле

7 грязных секретов Google: Как работа мечты портит карьеру и личную жизнь:

На протяжении нескольких лет Google регулярно занимает лидирующие позиции в рейтингах лучших работодателей мира. В 2015 году издание Fortune вновь поставило компанию на первое место. Между тем сами сотрудники интернет-гиганта не всегда остаются довольны. На сервисе вопросов и ответов Quora они рассказывают, как в компании обстоят дела на самом деле.

Сотрудников Google вынуждают работать без выходных и отпусков, люди болеют от стресса и переутомления http://t.co/sWC7HYq1X5 #капитализм
— Рустем Адагамов (@adagamov) October 7, 2015

Недавно также издательство «Манн, Иванов и Фербер» выпустило книгу «Работа рулит!» о принципах работы в Google (вернее, это перевод на русский). Автором материала выступил вице-президент компании по персоналу Ласло Бок.

На Roem.ru публикуются выдержки, посвящённые корпоративной культуре Google — её ценностях, миссии и способах принятия важных решений.

Вдогонку свежее:

13. «Валильщик» делится опытом

Большое и насыщенное интервью о переезде сисадмина Сергея Полищука из Киева (кстати, это один из «отцов уанета» — создатель украинской точки обмена трафиком UA-IX) в Виннипег (Канада).

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

Нужно привязываться не к job offer, а к тому, что вам лично нужно в жизни.
Если компания пошла на все тяготы с оформлением job offer для иностранца, значит ни один из местных там работать не станет. У человека, приехавшего на такую работу, может сложиться совсем неправильное впечатление о стране, если у него вообще будет шанс её увидеть, а не проводить сутки напролёт за компьютером.
Одно дело — когда тебя выбирают, и совсем другое — когда выбираешь ты. Очень важно понимать — чего тебе нужно в этой жизни и от чего стоит отказаться.
Некоторые не могут смириться с тем, что здесь нельзя дать взятку, чтобы попасть к врачу без очереди. Кто-то не способен выучить английский. Можно легко попасть на survival job в случае недостатка средств, но не все могут потом подняться выше.
Для успешной иммиграции нужно всего четыре компонента: несоветский менталитет, толковые мозги, деньги (чем больше, тем лучше), хороший английский.

Взгляд на процесс утекания мозгов с другой стороны идеологического фронта:

Шимків: те що зараз робить Польща, Канада, Румунія — виманюючи наших кращих спеців у той час як ми боремося за незалежність це удар в спину!
— DOU (@devua) September 26, 2015

14. Советы по повседневной работе с Git

19 полезных лайфхаков доступны в этом материале:

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

Из комментариев вынес такой полезный диалог:

Большую часть команд `git log` для меня заменил `tig`, смотрите его вот здесь.
Tig очень хорош, да, но это всё-таки не совсем то, это GUI (ncurses).
По поводу утилит есть ещё чумовая git up (и её же вариант на питоне, который лично я предпочитаю).

Вдогонку ссылка: Моя шпаргалка по работе с Git.

15. О чистом коде и культуре программиста

PHP: культура программирования:

Низкий порог вхождения, легкий способ прострелить себе ногу, потратьте свою энергию на изучение настоящего языка программирования — много обидных слов может услышать PHP-разработчик от коллег-программистов, которым посчастливилось освоить другие технологии. PHP удобно ругать всем, — каждый посвященный может найти, за что зацепиться. Тем не менее, на рынке до сих пор очень востребованы хорошие специалисты, способные писать качественный код на этом языке. Более того, если вы выбрали этот путь, на собеседовании в серьезной компании с подкованными технически руководителями и старшими программистами вы вряд ли услышите что-нибудь глумливое про PHP.
Во многом такое негативное отношение объясняется отсутствием культуры программирования у большого количества PHP-разработчиков. Почему так происходит? Да, у этого языка действительно низкий порог вхождения и легко освоить его может человек без специального технического образования. Изучив основы, можно сразу делать небольшие проектики и даже продавать свои услуги на биржах фрилансеров. А раз на такое есть спрос, зачем тратить время на углубление своих знаний, когда деньги можно зарабатывать уже сейчас?

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

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

В комментариях нарываются на полемику:

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

16. Хаскель теперь торт

Все мы знаем, что Haskell — идеальный язык для любых задач и лишь болезненный недостаток библиотек не даёт использовать его в больших серьёзных проектах, например, уровня национального поисковика. Но теперь ваши мольбы услышаны, и решение явлено миру: интероп с Rust! ТАДА!

Хаскель такой классный, прям завтра с утра начну учить https://t.co/pxkaValAVO
— JQ (@JackQack) September 11, 2015

Если Хаскель вам не по вкусу, можете попробовать свои силы в спасении мира любым другим подручным инструментом разработки:

Мы запустили игру для программистов :) http://t.co/1×9lJwylS9 Выбирай оружие (язык) и побеждай!
— Rakhim Davletkaliyev (@freetonik) October 3, 2015

17. Как Facebook’у iOS танцевать мешала

Самая скандальная ссылка этой недели. Удивлены частыми падениями Facebook’a? Напомню, что в этом году FB падал уже дважды (последний раз завалился сразу после выступления Путина в ООН).

Инженер Facebook публично поделился своими соображениями, в чьей архитектуре собаки порылись: «iOS Can’t Handle Facebook Scale». А вот и прекрасные слайды к его выступлению, и они просто эпические:

Некоторые не согласны с этим диагнозом, типа всё гораздо хуже:

PHP is a disease and Facebook is suffering more and more
— Egor Homakov (@homakov) September 29, 2015

18. Уголок молодого джаваскриптера

Давайте повысим градус неадекватности этой свежей, буквально с огорода, ссылкой: React with C++: Building the Quip Mac and Windows Apps.

Другой свежачок «Full-Stack Redux Tutorial» — A Comprehensive Guide to Test-First Development with Redux, React, and Immutable. Это подробное и плотное описание архитектуры (однопоточность, иммутабельность и т.д.) с наглядным объяснением концептов и примерами кода. Ну, и про React там тоже много всего.

Из прочитанного понял, что redux вроде пока лучшее, что случилось с flux. Новое видео в тему:

Изоморфный Javascript — новая серебряная пуля:

Вдогонку посорю тематическими ссылками:

19. Java для людей

Интересное интервью с Андреем Паньгиным из «Одноклассников»:

Сегодня я приготовил для вас большое интервью с Андреем Паньгиным aka apangin, ведущим инженером Одноклассников. Андрей больше 6 лет проработал JVM-инженером в Sun Microsystems, в том числе, в команде HotSpot, а последние 5 лет работает в Одноклассниках, решая там вопросы, связанные с JVM и производительностью. Так что Андрей по праву считается одним из сильнейших JVM-щиков в России.

Это полный текст интервью, а вот его видео-вариант:

В добавку свежая тематическая статья: Как писать код, который никто не сможет сопровождать:

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

Диалог двух довольных читателей статьи из комментариев:

Вспомнилось. Собеседовал как-то человека, который писал примерно вот так (код выдрал из первой попавшейся lib-ы, только переформатировал). Его код напоминал wall_of_text. Т.е. экран был заполнен от края до края кодом на каждой строке.
Для того чтобы как-то в этом разбираться, он для разделения блоков кода использовал множественные табуляции (или просто груду пробелов). Долго хвалился тем, какой он опытный перец. Что у него собственный framework и большой пулл довольных клиентов. Робко задал ему вопрос, как у него дела обстоят с MVC, ООП и пр... Он заявил мне, что слышал про это, но в деле не использовал, ибо не особенно то и нужно. Видимо, ему и так удобно. Код он набирал в FAR-е. Мне кажется, я никогда это не забуду :)
Да, один мой коллега набирает весь свой код в FARе. А то напридумывали тут ересь всякую: автоформатирование, подсветка синтаксиса, статические анализаторы какие-то...

20. Бинарные деревья поиска и рекурсия — максимально просто

Взято отсюда:

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

В комментариях сразу задают вопросы по частностям и получают полезные ответы:

Вопрос. Как сбалансировать несбалансированное бинарное дерево и обычное дерево (неотсортированное)?
Ответ: Поворотами узлов.

И ещё оттуда:

На практике, для обхода дерева в глубину (ну и для балансировки тоже) удобно, чтобы были восходящие связи — от детей к родителям. Тогда можно двигаться прямо по картинке, не используя стек. Аналогично двунаправленному списку против однонаправленного.
В терминах графов, — это означает, что каждой вершине соответствуют наборы входящих и исходящих рёбер.
А для быстрого обхода в ширину нужны списки вершин на каждом ярусе дерева. Либо мы можем свести задачу к последовательности обходов в глубину, опускаясь каждый раз на один ярус дальше. Это, конечно, даст квадратичное время (и логарифмическую память под стек, если рекурсивно) вместо линейной памяти под очередь.

21. Критика Go

Перевод статьи Один год с Go:

Итак, прошел год с тех пор, как я начал использовать Go. Неделю назад я удалил его из production.
Я пишу этот пост, потому что в течение последнего года многие спрашивали меня о впечатлениях от работы с Go, и мне бы хотелось рассказать о нем несколько больше, чем это возможно в Twitter и IRC — пока воспоминания не выветрились у меня из памяти.
Итак, поговорим о том, почему я не считаю Go полезным инструментом.

Из комментариев звучат дополнения:

Попробовал писать на Go несколько домашних поделок, на работе пишу на C#. Если вкратце, я пока так и не смог оценить преимуществ Go, кроме кросплатформенности:

1. Нет удобных средств для разработчика, IDE со встроенным дебаггером под винду так и не нашёл. Пользуюсь плагином для Idea.
2. Каналы — удобно, но мне они нужны для параллельной обработки массивов данных. В C# это решается проще, Parallel.ForEach и вперёд.
3. Очень непривычно создавать свои ненужные структуры для простой сортировки в Go. И в целом, LINQ для работы с коллекциями в разы удобнее. При работе с Go сильно не хватает.
4. Зачастую, Go кажется слишком низкоуровневым, даже чрезмерно. В идеале, не хотел бы видеть в языке указатели без особой на то причины.
5. Использовал библиотеку написанную на C++ в Go. Не скажу, что очень удобно, а, например, valgrind и вовсе не работает с такими приложениями. Встроенный отладчик память, выделенную в C++ коде, разумеется, не видит. И как отлаживать утечки?

В целом, язык интересный, но для себя достоинств я пока не увидел.

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

22. Децентрализация как тренд

Почему интернету нужен IPFS, пока ещё не поздно:

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

Если вы не знаете что такое IPFS, в конце статьи прикладывается FAQ по основам этой технологии.

Вдогонку:

В тему порочности блокировок отличное свежее видео: How the mysterious dark net is going mainstream (есть субтитры для тех, кому это надо).

Это захватывающая видео-лекция про Tor и сетевую наркоторговлю (не про то, где купить спайсы, а как технически это всё работает). Ничего особо нового для людей интересующихся темой технологий, но (ребята из Роскомнадзора, обратите пристальное внимание) сколько энтузиазма у лектора в голосе и жестах!

23. Старые идеи под напором времени

Весьма здравая и практичная идея — расширение U-SQL для анализа данных. Естественно, SQL и так про данные. Здесь же в язык добавлены работы по подготовке данных и работа с произвольными типами данных.

Также интересна попытка использовать клон SQL для процессинга интернета котиков изображений, что реализовано в проекте pixQL.

Делаем на нем попытку создать два запроса:

SELECT (img1_pixel.red+img2_pixel.red)/2
(img1_pixel.green+img2_pixel.green/2
(img1_pixel.blue+img2_pixel.blue)/2
FROM img1 img1_pixel INNER JOIN img1 img2_pixel
ON img1_pixel.column = img2_pixel.column
AND img1_pixel.row = img2_pixel.row+1;
# Superimpose one image over another, offset by 100 pixels width/height
UPDATE img1, img2
SET img1.rgb = img2.rgb
WHERE img1.row = img2.row+100
AND img1.column = img2.column;

24. Как «погрепать» интернет

Цитата из статьи об утилизации возможностей проекта Сommoncrawl:

Аналитикам иногда нужно отвечать на вопросы вроде таких: «Сколько сайтов используют WordPress, а сколько Ghost?», «Какое покрытие у Google Analytics, а какое у Метрики?», «Как часто сайт X ссылается на сайт Y?». Самый честный способ на них ответить — пройтись по всем страничкам в интернете и посчитать.
Эта идея не такая безумная, как может показаться. Существует проект Сommoncrawl, который каждый месяц публикует свежий дамп интернета в виде gzip-архивов суммарным размером в ~30Тб. Данные лежат на S3, поэтому для обработки обычно используется MapReduce от Amazon. Есть масса инструкций про то, как это делать.
Но с текущим курсом доллара такой подход стал немного дороговат. Я хотел бы поделиться способом, как удешевить расчёт примерно в два раза.

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

25. HiLoad-проблематика

26. История одной уязвимости

Низкоуровневые шалости в свежем материале: Побег из VMware Workstation через порт COM1.

© Blogerator