Привет, Хабр!

Летом в нашем ланитовском блоге мы делали подборку сериалов про ИТ (и хакеров), а теперь в преддверии Нового года пришло время полного метра. Такие «Топ-10 фильмов про ИТ» появляются примерно раз в год, и список там примерно один и тот же: «Хакеры» с Джоли, «Пароль «Рыба-меч» и «Матрица».

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

Так вот, про подборку. Мы решили предложить вам  фильмы посвежее. Под катом нет Джоли и знаменитой сцены из «Пароль „Рыба-меч“», но есть фильмы про ИТ, суперкомпьютеры, и информационную безопасность, большинство из которых выпущены в 2010–2018 годах.

Кадр из фильма «Апгрейд»

Кажется, мы так глубоко погрузились в дебри highload-разработки, что просто не задумываемся о базовых проблемах. Взять, например, шардирование. Чего в нем разбираться, если в настройках базы данных можно написать условно shards = n, и все сделается само. Так-то, он так, но если, вернее когда, что-то пойдет не так, ресурсов начнет по-настоящему не хватать, хотелось бы понимать, в чем причина и как все починить.

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

Фотография котиков (хоть они случайно и оказались щеночками) уже как бы отвечает на вопрос, зачем это всё, но начнем последовательно.

Привет, Хабр! Меня зовут Святослав, и я VP of Engineering. Вся моя жизнь прошла в Питере: я родился и вырос на улице Союза Печатников напротив Мариинского театра, учился во второй гимназии с углублённым изучением английского языка и физмата, поступил в Университет аэрокосмического приборостроения (ГУАП). После учёбы я работал в нескольких софтверных компаниях в России и США, но в итоге всё вернулся в Санкт-Петербург и оставался тут даже когда это казалось верной дорогой к карьерному болоту.



На основании своего личного опыта я расскажу о том, почему многим IT-специалистам нереально найти в Санкт-Петербурге работу по своему уровню, как работает механизм перетягивания лучших специалистов — как минимум, в Москву, а то и сразу в США или другие страны. И о том, как мне всё-таки удалось найти в родном городе свою лучшую работу на данный момент. Но обо всём по порядку.

Из Санкт-Петербурга в Санкт-Петербург через Санкт-Петербург

Моя трудовая биография началась с позиции Java-разработчика в небольшой софтверной компании в 1999 году. За следующие 9 лет я продвинулся по карьерной лестнице до позиции Эккаунт Менеджера, где мне подчинялось более 100 человек. Кризис 2008 года сбил нас на взлёте, и моей следующей записью в трудовой стала должность Lead IT Process Manager в московском отделении Deutsche Bank. Полтора года спустя мне поступило заманчивое предложение из США: консультировать бизнес-клиентов компании Grid Dynamics в вопросах оптимизации процессов разработки.

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

У нас, разработчиков программного обеспечения, довольно интересная профессия. Мы можем спокойно кодировать целыми днями, а затем прочитать статью о чём-то — и она подвергает сомнению всю нашу работу, потому что какой-нибудь Netflix сказал XYZ.

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

Привет, друзья.

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

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

Ура-а-а! Сборные команды ЛАНИТ (взводы №3460 и №3464) заняли третье и 30 места в забеге Гонки Героев 18 августа в Алабино в категории «Приключение». Мы стали лучшими в абсолютном зачете и среди всех ИТ-команд этого забега!

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

Источник

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

Успокойтесь, начальство всё равно не даст ничего переписать. Остаётся рефакторить. На что лучше всего потратить свои невеликие ресурсы? Как именно рефакторить, где проводить чистки?

Название этой статьи — в том числе отсылка к книге Дяди Боба «Чистая Архитектура», а сделана она на основе замечательного доклада Victor Rentea (твиттер, сайт) на JPoint (под катом он начнёт говорить от первого лица, но пока дочитайте вводную). Чтения умных книжек эта статья не заменит, но для такого короткого описания изложено весьма хорошо.

Идея в том, что популярные в народе вещи вроде «Clean Architecture» действительно являются полезными. Сюрприз. Если нужно решить вполне конкретную задачу, простой изящный код не требует сверхусилий и оверинжиниринга. Чистая архитектура говорит, что нужно защищать свою доменную модель от внешних эффектов, и подсказывает, как именно это можно сделать. Эволюционный подход к наращиванию объема микросервисов. Тесты, которые делают рефакторинг менее страшным. Вы ведь уже знаете всё это? Или знаете, но боитесь даже подумать об этом, ведь это же ужас что тогда делать придётся?

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

Масштабирование базы данных через шардирование и партиционирование

Денис Иванов (2ГИС)

Всем привет! Меня зовут Денис Иванов, и я расскажу о масштабировании баз данных через шардирование и партиционирование. После этого доклада у всех должно появиться желание что-то попартицировать, пошардировать, вы поймете, что это очень просто, оно никак жрать не просит, работает, и все замечательно.

Немного расскажу о себе — я работаю в команде WebAPI в компании 2GIS, мы предоставляем API для организаций, у нас очень много разных данных, 8 стран, в которых мы работаем, 250 крупных городов, 50 тыс. населенных пунктов. У нас достаточно большая нагрузка — 25 млн. активных пользователей в месяц, и в среднем нагрузка около 2000 RPS идет на API. Все это располагается в трех датацентрах.

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

Мы собрали могучую команду на железную триатлонную эстафету IronStar 226, которая пройдет в Сочи 22 сентября 2018 года, и призываем ИТ-шников присоединится! Лучше всего — это собрать команду и зарубиться с нами… ну или в крайнем случае предлагаем просто поболеть с пивком за (пока) единственную ИТ-команду

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

1. 3,8 км – плавание на открытой воде (плыву я);
2. 180 км – велосипед по живописной трассе Адлер - Красная Поляна (поедет Дмитрий Сидельников);
3. 42,2 км – бег (побежит Антон Старшов).

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

Зарегистрироваться можно тут. Стоимость – 20 000 руб за команду.

Надпись на плакате у милой девушки: "Железные люди – сексуальные". "Железные люди" – это те, кто преодолевают классическую дистанцию триатлона, пусть даже в эстафете ;-)

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

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

Мы приготовили для вас небольшую подборку сериалов, так или иначе связанных с ИT. А натолкнула нас на идею этого поста многолетняя дружба ЛАНИТ с Международным фестивалем документального кино "ДОКЕР", где, кстати, в том числе с нашей помощью традиционной стала номинация для фильмов о возможностях информационных технологий «Let IT Doк!».

Кадр из сериала «Mr. Robot» (eps3.1_undo.gz)

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

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

Хранение запасов стоит денег. Предположим, что на хлебозаводе есть шесть 50-тонных силосов для хранения муки. Это значит, что в среднем каждый день в них находится около 150 тонн муки. По сегодняшним ценам это 73000$ мёртвого капитала.

Есть и другие издержки, например порча. Мука может храниться месяцами, но готовые булочки начинают терять в цене как только выйдут из печи; через 24 часа они не стоят почти ничего.

Зачем тогда вообще хранить запасы? Затем что есть ещё и расходы связанные с их нехваткой. Если на заказ новой партии булочек с кунжутом уходит два дня, то, если они вдруг закончатся в вашей закусочной, ваш бизнес по продаже гамбургеров остановится на двое суток. Запасы — это буфер, который предотвращает непредвиденные остановки. Сейчас придумано множество алогоритмов для вычисления оптимального объёма этих буферов (для начала: бережливое производство, теория ограничений).

Зачем я вам всё это рассказываю? Затем, что в производстве ПО тоже существуют места, где накапливаются «производственные запасы». И хранение этих запасов может стоить кучу времени и денег.

Это мой доклад с Meetup-а Московской Atlassian User Group от 1 марта 2017 года

Контекст и задача

Компания самостоятельно разрабатывает программное обеспечение (Продукты) под нужды своих бизнес-подразделений (Заказчиков). Некоторые из продуктов поставлены заказчикам и компания занимается их доработкой-развитием.

Есть общий перечень задач по каждому из продуктов (Product Backlog). Каждый месяц выходят новые релизы по некоторым продуктам.

Цель – ответить на вопрос по каким продуктам необходимо выпустить релизы и какие клиентские запросы войдут в каждый из релизов.

Результат – план разработки на следующий производственный цикл (Sprint Backlog). Список релизов по продуктам, которые будут выпущены в следующем цикле.

Бизнес-логика

Каждый из продуктов закреплен за Менеджером по продукту (Product Owner). Каждое бизнес-подразделение закреплено за IT-Business Partner-ом (Менеджер по клиенту). Менеджер по клиенту обращается к Менеджеру по продукту с возможным заказом на разработку (User Story). Если Менеджеру по продукту «боль Заказчика» и «запрошенная таблетка» понятны, то он запрашивает у Руководителя команды разработки (Team Lead-а) оценку возможности реализации опции в продукте и приблизительную трудоемкость. По результатам оценки Заказчик либо подтверждает размещение заказа либо отказывается. Так формируется список запросов на доработку продуктов (Product Backlog).

Предисловие переводчика: Недавно я рассказал о том, как реализовать процедуру планирования выпуска релизов по продуктам с помощью семейства продуктов Atlassian и дал ссылки на статьи как сделать тоже самое в Team Foundation Server и Redmine.

А что делать если компания не дозрела купить JIRA, TFS или Redmine, как обойтись только Excel-ем?

И эта статья о том как это сделать.

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

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

— Какое отношение имеет морская свинка к морю?
— Примерно такое же, как утконос к проектированию дирижаблей.

Введение.

Я имею обыкновение во время прогулок прокручивать информацию из нескольких источников, сопоставляя куски. Одна из любопытных находок – почти полное соответствие статистических наблюдений Демарко и Листера в «Peopleware» и теоретических выкладок Голдратта в «Критической цепи».

Осенью 2011 я крутил в голове:
[1] «Стоя на плечах гигантов» Эли М. Голдратт © Eliyahu M. Goldratt, 2008
[2] «Производственный менеджмент: управление потоком» Одед Коуэн, Елена Федурко
[3] «История одной доски» (http://cartmendum.livejournal.com/tag/theboard).

Далее хотелось бы написать: «Как вдруг…», — но это будет неправдой. Это случилось не вдруг. Мне понадобилось пару недель, но, в конце концов, в голове сложилась достаточно цельная картинка.

За что именно я зацепился:

• Таичи Оно (Öno Taiichi) не понимал, почему его система работает.
• Существует несколько разных типов производственных потоков – V, A, T, I. Каждый тип потока ставит особые задачи.
• Неудачи внедрения доски Максима Дорофеева в некоторых подразделениях
• Ряд компаний не смог внедрить систему Тойота, несмотря на все приложенные усилия.
• Система Тойота и система Форда основывается на одинаковых принципах, но прикладные решения ограничены определенными типами производства.

В Риме 8 апреля 2018 года я пробежал свой первый марафон (время — 4:29.41). У нас очень спортивная компания (см. отчет о ИТ-чемпионате в Гонке героев), но очень многие друзья и коллеги, которые меня поздравляли, абсолютно не представляли себе, что такое марафон и как интерпретировать мой результат.

Наш диалог был примерно следующим (Д — друг, Я — я):

(Д): Ну че красавчик! Ты что-то там, говорят, пробежал?
(Я): Спасибо, да, марафон.
(Д): Ну ты не умничай, скажи сколько пробежал?
(Я): 42 км 195 метров, конечно же, за 4:30.
(Д): Ни фига себе пробежал 42 км за 4:30! Да ты просто мегамонстр!

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

К сожалению, примеры проектов, на которые разработчики потратили много времени, скажем более полугода, но так никогда и не выпустили в свет, нередки.

Фагнер Брек считает, что такое происходит потому, что эти проекты не реализовывали принципы непрерывной интеграции. В своей заметке, перевод которой перед вами, он пишет, что в известном ему случае кое-что нужно делать по-другому с самого начала:

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

Но как это сделать? Это фундаментальный вопрос, с которым каждому приходится столкнуть в программном проекте: всё изменится.

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

Каждый из нас видел волнующие и торжественные моменты, когда, например, устанавливается связь с космонавтами или со спутником. Люди радостно вскидывают руки, искренне и тепло улыбаются, иногда обнимаются, особенно если событие значимое. Команда ЛАНИТ улыбалась, обнималась, вскрикивала и жала влажной от пота взволнованных рук мышкой кнопку «Опубликовать» 51 раз.  2 февраля исполняется год, как мы пришли на Хабр. Эмоции, опыт, находки, факапы, паника и много позитива — в нашей истории успеха под катом. Все это точно пригодится тем, кто хочет раскачать свой корпоративный блог на Хабре, но не знает, как.

Мы уже почти написали пост к старому Новому году с отличной задумкой и героями русских сказок, но процесс прервало сообщение в Telegram. А в нём — анонс новости от экспертов рынка. Исследователи из Оксфордского и Йельского университетов пришли к выводу, что переход к полной автоматизации большинства экономических и технологических процессов закончится через 150 лет. Их азиатские коллеги показывают более оптимистичный срок — 104 года.

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


Источник

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

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

Мы надеемся, что этот материал вдохновит тех, кто хотел бы учиться, но не решался это сделать по разным причинам. Кроме того, вот прямо сейчас есть шанс выиграть сертификаты на бесплатное обучение на дистанционных пользовательских курсах MS Office, например, для секретаря вашей компании или бухгалтера. Лучший подарок тем, кто самым активным образом обращается к вам с просьбами «#тыжпрограммист». В конце текста размещены 10 фактов из жизни нашего учебного центра, два из которых — сущий вымысел. Среди тех, кто правильно их укажет, мы разыграем 10 сертификатов. Ответы можно размещать в комментариях под этим постом. Ни пуха, ни пера! Порадуйте коллег.


Источник