В последнее время Jupyter Notebook стал очень популярен среди специалистов Data Science, став де-факто стандартом для быстрого прототипирования и анализа данных. В Netflix, стараемся раздвинуть границы его возможностей еще дальше, переосмысливая то, чем может быть Notebook, кем может быть использован, и что они могут могут с ним делать. Мы вкладываем много сил, чтобы воплотить наше видение в реальность.

В данной статье мы хотим рассказать почему считаем что Jupyter Notebooks настолько привлекательным и что вдохновляет нас на этом пути. Кроме того, опишем компоненты нашей инфраструктуры и сделаем обзор новых способов использования Jupyter Notebook в Netflix.

Примечание от переводчика: осторожно, много текста и мало картинок

На «Моём круге» ежемесячно размещается 35% вакансий, предлагающих удалённую работу в сфере ИТ. При этом, если изучить базу резюме сервиса, то увидим, что к удалённой работе готовы 67% специалистов. Налицо явный разрыв между спросом работодателей на удалённую работу и предложением со стороны соискателей на неё. Как следствие, откликов на вакансии с удалённой работой в среднем в 3-4 раза больше, чем на вакансии с офисной работой. В условиях растущего недостатка в ИТ-специалистах очевидно, что в более выигрышном положении оказываются те работодатели, которые готовы переходить на удалённую работу.

Мы решили разобраться, что сейчас собой представляет рынок удалённой работы в России. Для этого мы провели опрос среди пользователей «Моего круга» и «Хабрахабра», собрали почти 3000 ответов, все их обработали, визуализировали и прокомментировали.

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

Предлагаем вашему вниманию последнюю в этом году подборку с ссылками на новые материалы из области фронтенда и около него.

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

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

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

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

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

Всем привет. Как вы, возможно, знаете, раньше я все больше писал и рассказывал про хранилища, Vertica, хранилища больших данных и прочие аналитические вещи. Сейчас в область моей ответственности упали и все остальные базы, не только аналитические, но и OLTP (PostgreSQL), и NOSQL (MongoDB, Redis, Tarantool).

Эта ситуация позволила мне взглянуть на организацию, имеющую несколько баз данных, как на организацию, имеющую одну распределенную гетерогенную (разнородную) базу. Единую распределенную гетерогенную базу, состоящую из кучи PostgreSQL, Redis-ов и Монг… И, возможно, из одной-двух баз Vertica.

Работа этой единой распределенной базы порождает кучу интересных задач. Прежде всего, с точки зрения бизнеса важно, чтобы с данными, движущимися по такой базе, все было нормально. Я специально не использую здесь термин целостность, consistency, т.к. термин это сложный, и в разных нюансах рассмотрения СУБД (ACID и CAP теорема) он имеет разный смысл.

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

13 сентября в офисе Wrike прошел бэкенд-митап, посвященный глобальным изменениям в продукте. Поговорили о глобальном рефакторинге, смене методологии разработки на лету, унификации в проектах и микросервисах.

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

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

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

Решением было создание централизованного лог хранилища с агрегацией логов и поиском. Выбор пал на ELK стек. ELK — сочетание трех OpenSource проектов: ElasticSearch, Logstash и Kibana. ELK хранит логи, строит графики и есть поддержка полнотекстового поиска с фильтрами. В статье описывается процесс настройки ELK стека для хранения логов Django приложения.

В первой части мы рассмотрели тревожные симптомы и возможные способы «лечения» Product Owner в «механическом» scrum. Продолжим разбор ролей и следующая на очереди – команда.
Все же знают мантру, что команда должна быть самоорганизованной и кросс-функциональной, это выглядит как самая простая часть scrum: берем людей с нужными компетенциями, говорим им: «вы команда», и полетели! Но на деле все несколько сложнее.

Я больше 10 лет работаю с / в / для agile в сфере web-разработки. Из них больше всего пришлось иметь дело с самым популярным agile фреймворком — scrum (по данным VersionOne). Хочу поделиться с вами накопленными наблюдениями и выводами.

Начну с метафоры, так как иногда приходилось видеть внедрение scrum по такому сценарию:

• До scrum: «разработка» как младенец — она целеустремленна, но не умеет нормально ходить, а очень хочет научиться, чтобы добираться до цели.
• Внедрение: приходит учитель (scrum тренинги, курсы, agile coach и т.п.) и показывает, как ходить. Малыш счастлив, он двигается шагами! Топ-топ-топ. У нас спринты — мы ходим!
• После внедрения: терпеливые стейкхолдеры говорят: «Окей, погнали к цели», на что получают «не давите на команду, мы ходим!». Разработка выписывает интересные траектории и получает удовольствие от процесса, но цель забыта.
• Scrum-но: дальше пилюля правды от бизнеса, scrum «мутирует» и позволяет бизнесу получать какой-никакой продукт от разработки. И, к сожалению, формально ставится галочка «мы работаем по scrum», а реальный потенциал команды разработки так и не раскрыт, да и кругом говорят «scrum ненастоящий».

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

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

Т.к. мой классификатор из прошлого поста таки работает (впрочем, параметры «из коробки» не всегда удачны, потому я вынес возможность слегка настроить Conv1d-слои и скрытый слой) — я решил прикрутить его к боту. Да, запоздал я на этот хайп ) Кстати, заранее уточню, что прикрутить русский я пока таки не пробовал, хотя это не должно стать проблемой — в nltk поддерживаются нужные фичи, обучение word2vec концептуально не отличается от английского, да и предобученные модели вроде бы имеются.

Ну и сходу возникают вопросы:

• под какие платформы его пилить — пока решил остановиться на telegram. В теории — конструкция позволяет легко дописать обертки для других платформ (как будто он кому-то понадобится )
• как описывать «сценарий». Навелосипедил свою структуру с классами и сущностями поверх YAML
• ну и неплохо бы хранить ботов/состояние в какой-нибудь БД

Здравствуйте! Данная статья является продолжением цикла статей, посвященных разработке для мобильной платформы Sailfish OS и их тестированию. Одна из предыдущих статей была посвящена тестированию QML-компонентов приложения. Однако, часто разработчики сталкиваются с потребностью написания собственных компонентов на языке C++ для использования функционала, недоступного из QML, или для улучшения производительности. Об этом также уже было написано. Тестирование таких компонентов отличается от тестирования уже существующих. В данной статье мы расскажем, как тестировать собственные QML-компоненты, написанные на языке C++.

Вот и подоспели материалы с фестиваля РИТ++ 2017. Мы выступили там с докладами по темам machine learning, front-end и mobile разработки и провели отдельный тематический блок, посвященный микросервисам. Под катом – видеозаписи выступлений на этой секции наших докладчиков и коллег из других компаний. Обязательно загляните, чтобы узнать о подходах к работе с микросервисами и интересных приемах, которые реально использовать для решения ваших задач.

Мне очень понравилась библиотека socket.io. С помощью нее можно легко реализовать realtime-приложения. Она сама выбирает протокол в зависимости от браузера, если необходимо, создает WebSocket.

Это, конечно, все хорошо, но не стоит забывать о том, что Node.js работает в одном потоке. Для этого у нас есть отличный инструмент Cluset.

Передо мной встал вопрос, а можно ли сделать приложения с кластеризацией, но не использовать для этого REDIS? Также для удобства используем EXPRESS.

Мы всегда в поисках хороших статей о дизайне, чтобы потом использовать их в работе над сайтом «Я люблю ИП». Сегодня мы перевели ещё одну статью, которая рассказывает, чем отличается UI-дизайн от UX-дизайна и на каких основных принципах строится дизайн интерфейсов.

UI vs. UX

Если вы хоть немного интересовались дизайном приложений, то наверняка слышали термины «UI» и «UX». Но чем же они отличаются?

В самой простой форме, UX-дизайн — это то, что делает интерфейс полезным, а UI-дизайн — делает его красивым. Дизайн интерфейсов — это смесь визуальной иерархии и элементов интерфейса. Чтобы разобраться, чем отличается прекрасный дизайн от просто хорошего, необходимо понять, что дизайн интерфейсов — это всего лишь один из слоев целого дизайн-процесса. Возможно, именно поэтому эти два термина так часто путают. В этой статье я постараюсь рассказать, в чём же заключается разница между ними с точки зрения дизайн-процесса.

Согласно книги Дж. Гарретта «Элементы опыта взаимодействия», UX-дизайн можно определить через пять основных уровней. Давайте начнём с самого абстрактного.

Примечание от переводчика:

Этот пост был написан и опубликован на Medium разработчиком приложений Адрианом Космачевским из Швейцарии. Кроме подготовки перевода его публикации, я также пригласил и самого автора, Адриана ( akosma ), на Хабр, для того, чтобы он смог лично ответить на любые вопросы участников сообщества, если таковые возникнут. Думаю, для общего удобства при общении в комментариях с ним стоит использовать английский (и, при желании, дублировать на русском).

---

Привет всем, я — сорокадвухлетний программист-самоучка, а это моя история.

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



Эти размышления привели меня туда, откуда все начиналось.

Я дебютировал в роли разработчика программного обеспечения в 10 часов утра 6 октября 1997 года, в городе Оливос, к северу от Буэнос-Айреса, в Аргентине. Был понедельник. Не так давно я праздновал свой 24-й день рождения.

Мир в 1997 году

Тогда он был немного другим. На веб-сайтах не было предупреждений об использовании cookie. Новаторскими в сети были сайты вида Excite.com, а моим любимым поисковиком был AltaVista.

Мой электронный ящик имел вид kosmacze@sc2a.unige.ch и был расположен на личном веб-сайте, который размещался по адресу http://sc2a.unige.ch/~kosmacze. Тогда мы еще оплакивали принцессу Диану, а Стив Джобс только-только вернулся на роль CEO и убедил Microsoft «вбросить» в Apple Computer 150 миллионов долларов. Digital Equipment Corporation подала в суд на Dell, останки Че Гевары вернули на Кубу, только начался четвертый (!) сезон «Друзей». Был убит Джанни Версаче, скончались Мать Тереза, Рой Лихтенштейн и Жанна Кальман. Люди зависали за Final Fantasy 7 на PlayStation, будто бы были наркоманами, Би-Би-2 начал вещание телепузиков, а Кэмерон только собирался показать миру свой «Титаник».

Я использую Qt в разработке уже более 6 лет, из них последние 3 года для создания приложений под Android и iOS на Qt Quick. Моя приверженность этому framework'у обусловлена двумя причинами:

• Qt предоставляется большой пакет компонентов, функций, классов и т.п., которых хватает для разработки большинства приложений;
• Если нужно создать недостающий компонент, Qt предоставляет несколько уровней абстракции для этого — от простой для кодирования, до наиболее производительной и функциональной.

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

Этот пост участвует в конкурсе „Умные телефоны за умные посты“
Не так давно фреймворк Qt Quick обзавелся дополнением Qt Quick3D, позволяющим полноценно работать с 3D объектами (поддерживается импорт из 3D Max и Blender), совершать над ними различные трансформации, анимации, применять эффекты, ну и вообще по полной использовать возможности лежащего в основе OpenGL. Работает всё это под Symbian, MeeGo, Windows\Linux\MacOs (ну и вообще везде, где Qt есть). В этом топике мы попробуем технологию «на зуб». Писать что-то сложное и серьёзное не хочется, поэтому мы сделаем хабрахолодильник, из которого по клику будет вылетать НЛО.
Сразу результат:

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

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

Аттеншн, лонгрид!