Я работаю специалистом по обработке и анализу данных (data scientist), поэтому большая часть моей работы включает в себя подбор оптимизируемых метрик и размышления о том, как выполнять процессы с максимальной эффективностью. Недавно я обнаружил совершенно удивительную книгу об экономических проблемах в СССР и о коллективе экономистов и компьютерных учёных, стремившихся решить их на основе данных. Книга называется Red Plenty. На самом деле она написана в жанре романа, что странно, однако представляет собой точную экономическую историю СССР. Автор активно заимствует информацию из книги 1973 года под названием Planning Problems in the USSR, которую я тоже приобрёл. При чтении этих книг я не мог не обратить внимания на параллели с планированием в любой современной организации. Факт, который покажется сегодня знакомым каждому data scientist: во второй книге есть цитата исследователя, жалующегося на то, что 90% своего времени он потратил на очистку данных, и только 10% — на само моделирование!

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

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

Надо ли писать код на доске? Надо ли жонглировать бинарными деревьями и знать наизусть все сложности алгоритмов, или просто разговаривать про жизнь и проекты?

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

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

В магазинах можно встретить множество мощных светодиодных ламп, например «свечки» и «шарики» 9 и 11 Вт.

Вот только свечек и шариков такой мощности сегодня существовать не может.

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

Был у меня в жизни такой опыт автоматизации, за который долгое время было стыдно. Не потому, что система плохо работала, или метаданные кривые были, или ТЗ не соответствовала — ровно наоборот. Все красиво, быстро, с полным внедрением во всей компании. С точки зрения формальных критериев это был полный успех.

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

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

Обо всем по порядку.

Это первая статья в серии, где я буду документировать мой опыт написания веб-приложения на Python, используя микрофреймворк Flask.

Здесь список всех статей в серии:
Часть 1: Привет, Мир!
Часть 2: Шаблоны
Часть 3: Формы
Часть 4: База данных
Часть 5: Вход пользователей
Часть 6: Страница профиля и аватары
Часть 7: Unit-тестирование
Часть 8: Подписчики, контакты и друзья
Часть 9: Пагинация
Часть 10: Полнотекстовый поиск
Часть 11: Поддержка e-mail
Часть 12: Реконструкция
Часть 13: Дата и время
Часть 14: I18n and L10n
Часть 15: Ajax
Часть 16: Отладка, тестирование и профилирование
Часть 17: Развертывание на Linux (даже на Raspberry Pi!)
Часть 18: Развертывание на Heroku Cloud

Моя предыстория

Я разработчик ПО с двузначным числом лет опыта разработки комплексных приложений на нескольких языках. Впервые я познакомился с Python для создания привязок к C++ библиотеке на работе. Вдобавок к Python, я писал веб-приложения на PHP, Ruby, Smalltalk и, верите вы или нет, еще на С++. Из всего этого, я нахожу комбинацию Python/Flask самой гибкой.

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

— Это теперь называется Front-End инженер, но да, я — именно он. Я работаю с вебом в 2016. Визуализации, музыкальные плееры, летающие дроны, которые играют в футбол, все что угодно. Я только что вернулся из JsConf и ReactConf, так что я знаю новейшие технологии для создания веб-приложений.

— Круто. Мне нужно создать страницу, которая отображает последние действия со стороны пользователей, так что мне просто нужно получить данные от REST и отобразить их в какой-то фильтруемой таблице, ну и обновлять её, если что-то изменится на сервере. Я думал, может быть, использовать JQuery для извлечения и отображения данных?

— О, Мой Бог! Нет! Никто больше не использует JQuery. Ты должен попробовать React: это — 2016!

Представляю на ваш суд ещё один перевод коанов о Мастере Фу на русский язык. В данный сборник вошли все коаны, на данный момент опубликованные на сайте Эрика Реймонда. Надо сказать, что сам Эрик личность весьма неординарная, но упоминания в данной статье стоящая. Помимо холиваров в списках рассылки всевозможных проектов за его авторством также несколько серьёзных трудов о Unix — в том числе и о сообществе, без которого экосистема современных открытых проектов не была бы возможной (полный список книг). Идея перевести коаны в очередной раз пришла мне в голову во время чтения одного из таких трудов, а именно «The Art of Unix Programming», поскольку многое из скрытого смысла коанов становится ясно только после прочтения очередной главы оттуда.

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

Dojo Toolkit это одновременно самый мощный и наименее используемый JavaScript фреймворк. Dojo состоит из AMD модулей, большая часть которых является виджетами. Виджеты обычно состоят из логики на JavaScript и HTML шаблона. В будущей версии 2.0 заявлена поддержка WebComponents. Dojo позволяет легко как создать полностью новый виджет, так и расширить или изменить уже существующий. В этом посте я расскажу как это делать.

О преимуществах перехода с версии 1.2 написано немало статей. Однако, согласно статистике, более 45% сайтов всё ещё используют версию 1.2, только 31% перешёл на более новую 1.3 и всего 5% используют 1.4.

И это когда космические корабли бороздят просторы вселенной версия 1.2.0 вышла в релиз почти два года назад, версия 1.3.0 − год назад, версия 1.4.0 − ещё этой весной, а 1.5.0 уже выходит в бету.



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

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

В последнее время мои коллеги начинают знакомство с git'ом. И один из интересующих их вопросов — как откатиться до определённой ревизии. В интернете можно найти набор команд, но хочется, чтобы было понимание каждой из них. Баловство с комадами git'а без понимания может привести к потере истории разработки.

В этой статье я хочу рассказать о командах git checkout и git reset с ключами --soft и --hard.

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

В нашем блоге мы уже неоднократно рассказывали о создании email-рассылок с помощью CSS и HTML. Сегодня же речь пойдет о самом подходе к созданию верстки. Итальянский дизайнер Массимо Кассандро на сайте SitePoint описал свой процесс разработки html-писем. В нем есть несколько интересных моментов, так что мы решили сделать адаптированный перевод этой заметки.



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

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

Если и есть что-то, что веб-разработчики любят, так это знать что-то, что лучше традиционного. Но традиционное является таковым по одной причине: это дерьмо работает. Что-то давно беспокоило меня во всей этой шумихе вокруг Node.js, но у меня не было времени разобраться, что именно, пока я не прочитал полный боли в жопе пост от Райана Дала, создателя Node.js. Я бы забыл его, как любое очередное нытьё какого-то осла о том, что Unix слишком сложен. Но, как полицейскому, который, жопой чуя, что что-то не так с этой семьёй в микроавтобусе, останавливает его и находит пятьдесят килограммов героина, мне показалось, что что-то не так с этой слезливой историей, и возможно, просто возможно, он понятия не имеет, что делает, и много лет программирует, никем не контролируемый.

К написанию сей заметки меня сподвигло то, что я устал делать развёрнутые замечания на эту тему в комментариях к статьям, где в качестве части инструкции по сборке и настройке чего-либо для конкретного дистра предлагают выполнить make install.

Суть сводится к тому, что эту команду в виде «make install» или «sudo make install» использовать в современных дистрибутивах нельзя.

Но ведь авторы программ в руководствах по установке пишут, что нужно использовать эту команду, возможно, скажете вы. Да, пишут. Но это лишь означает, что они не знают, какой у вас дистрибутив, и дистрибутив ли это вообще, может, вы вступили в секту и обкурилисьчитались LFS и теперь решили под свою хтоническую систему скомпилять их творение. А make install является универсальным, хоть и зачастую неправильным способом это сделать.

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

Что если бы вы могли построить сложный css лейаут в считанные минуты? Flexbox — это новый лейаут CSS верстки, который позволяет легко построить динамические макеты. С Flexbox выравнивание по вертикали, блоки с одинаковой высотой, перестановка и направление становится проще простого.



Есть популярный миф, что flex еще не готов к использованию. Но это не так! У 93% людей сейчас запущен браузер, поддерживающий flexbox. Это лучше, чем поддержка для HTML5.

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

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

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

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.

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



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

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

Цели: классические. Повысить качество работы, эффективность, вывести отдел на новый уровень в целом.