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


Источник

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

Вроде бы когда-то это был настроенный конвейер, но теперь его куски — как будто в разных зданиях. Особо не заботятся о том, что было «до» и что будет «после». А если всё падает, то люди поднимают руки: «Я не виноват. Я не знаю, как поднять».

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

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

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

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

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

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

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

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

Иной раз чудится, что тимлид — это кто-то или что-то вроде Снарка из поэмы Льюиса Кэрролла: точно существует, разносторонне и противоречиво описан в своих бытовых и деловых проявлениях, но при всем при том что представляет собой — загадка. Разобраться с тем, насколько значима эта (тимлида, не Снарка) роль в инженерных командах, кого правильнее на нее ставить и какие подводные камни скрыты в «тимлидстве», обещает помочь Saint TeamLead Conf 2018, которая пройдет 24–25 сентября в Санкт-Петербурге.

За месяц до мероприятия мы без лишних формальностей поговорили с техническим директором проекта Mos.ru Романом Ивлиевым, который возглавляет Программный комитет Saint TeamLead Conf 2018. В беседе: кто такие тимлиды, как их правильно готовить, кого и к чему должны готовить они, каким должен быть круг их обязанностей и многое другое.

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

1. Контейнеры незыблемы: ОС, библиотеки, папки и приложения – поскольку все это хранится прямо в контейнере, вы на 100 % уверены, что в продакшн всегда пойдет именно тот образ, который тестировался в QA. И работать он при этом будет абсолютно аналогично.
2. Контейнеры легковесны: Контейнер не ест память впустую. Вместо сотен мегабайт и гигабайт контейнеру нужна память лишь под основной процесс.
3. Контейнеры быстрые: Контейнер запускается так же быстро, как и обычный Linux-процесс. Не минуты, а буквально считанные секунд.

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

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

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

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

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

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

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

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

Как же все таки они устроены? И кому это может быть полезно? Вам определенно с этим следует ознакомиться, если:

1. Вы ими пользуетесь в своей торговле
2. Вы планируете написать торгового робота
3. Вы хотите реализовать торговую стратегию сами

Про установку SSL-сертификатов на веб-сервер написано достаточно много, и обычно этот вопрос не вызывает сложности у системных администраторов. Однако непосредственно перед установкой неплохо сделать несколько проверок, чтоб не созерцать в браузере досадное «The site's security certificate is not trusted!» (Сертификат безопасности сайта не является доверенным!). Особенно это актуально, когда сертификаты вы получаете не от регистратора, а от заказчика, который может, к примеру, перепутать приватные ключи или выслать сертификат в формате своего текстового редактора с добавлением мусора форматирования.

Таким образом, чтоб всё и сразу заработало, перед установкой SSL-сертификата желательно сделать несколько проверок.

Продолжаю знакомить читателей Хабра с главами из своей книжки «Теория счастья» с подзаголовком «Математические основы законов подлости». Это ещё не изданная научно-популярная книжка, очень неформально рассказывающая о том, как математика позволяет с новой степенью осознанности взглянуть на мир и жизнь людей. Она для тех кому интересна наука и для тех, кому интересна жизнь. А поскольку жизнь наша сложна и, по большому счёту, непредсказуема, упор в книжке делается, в основном, на теорию вероятностей и математическую статистику. Здесь не доказываются теоремы и не даются основы науки, это ни в коем случае не учебник, а то, что называется recreational science. Но именно такой почти игровой подход позволяет развить интуицию, скрасить яркими примерами лекции для студентов и, наконец, объяснить нематематикам и нашим детям, что же такого интересного мы нашли в своей сухой науке.



Это, одна из первых глав, в которой на примере велосипедиста рассматриваются нужные нам инструменты для измерения несправедливости: кривая Лоренца и индекс Джини, а также упоминаются пресловутый Парето и грозный инспектор.

Перевод поста из блога GitLab.com.

GitLab.com по плану 28 июля переезжает на Google Cloud Platform. Рассказываем, чем это обернется для вас сейчас и в будущем.

Для нас всегда в приоритете стояло повышение быстродействия и надежности GitLab.com. И то, и другое постепенно росло, а мы тем временем планировали серьезные перемены, способные обеспечить настоящий прорыв: сделать GitLab облачным (cloud native) приложением для Kubernetes.

В прошлых двух статьях мы рассказывали об IIoT — индустриальном интернете вещей — строили архитектуру, чтобы принимать данные от сенсоров, паяли сами сенсоры. Краеугольным камнем архитектур IIoT да и вообще любых архитектур работающих с BigData является потоковая обработка данных. В ее основе лежит концепция передачи сообщений и очередей. Стандартом работы с рассылкой сообщений сейчас стала Apache Kafka. Однако, для того, чтобы разобраться в ее преимуществах (и понять ее недостатки) было бы хорошо разобраться в основах работы систем очередей в целом, механизмах их работы, шаблонах использования и основной функциональности.

Мы нашли отличную серию статей, которая сравнивает функциональность Apache Kafka и другого (незаслуженно игнорируемого) гиганта среди систем очередей — RabbitMQ. Эту серию статей мы перевели, снабдили своими комментариями и дополнили. Хотя серия и написана в декабре 2017 года, мир систем обмена сообщениями (и особенно Apache Kafka) меняется так быстро, что уже к лету 2018-го года некоторые вещи изменились.

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

Но нет, эта статья не об обществе, а о технологиях.

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



Сегодня я расскажу про второй опыт восстановления зрения, но на этот раз более радикальный и с каким-то вообще невероятным результатом. А именно — о лазерной коррекции по технологии ReLEx SMILE.

Все мы знаем о том, что JavaScript-код веб-проектов может разрастаться до прямо-таки огромных размеров. А чем больше размер кода — тем дольше браузер будет его загружать. Но проблема тут не только во времени передачи данных по сети. После того, как программа загрузится, её ещё надо распарсить, скомпилировать в байт-код, и, наконец, выполнить. Сегодня мы представляем вашему вниманию перевод 14 части серии материалов об экосистеме JavaScript. А именно, речь пойдёт о синтаксическом анализе JS-кода, о том, как строятся абстрактные синтаксические деревья, и о том, как программист может повлиять на эти процессы, добившись повышения скорости работы своих приложений.

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

Цель статьи — рассказать немного о MSBuild, показать что такое таргеты и таски в MSBuild, научить работать с файлом .csproj, дать полезные ссылки. Если у вас будет более подходящее название для статьи, то буду рад обсудить в комментариях.

Меню

• Основные понятия — что такое target и task в MSBuild
• Жизненный цикл сборки MSBuild — какая последовательность вызова таргетов
• Подготовка окружения для примеров
• Таргеты в MSBuild — пример использования некоторых таргетов MSBuild
• Создание собственного таргета MSBuild
• Таски в MSBuild — пример использования некоторых тасков MSBuild
• Переменные и макросы в .csproj
• Ссылки

UPD: так как тема хорошо зашла и показала наличие спроса на такой сервис, буду развивать его дальше. Завел паблик вконтакте для сбора фидбека и публикации информации об обновлениях https://vk.com/sightsafari

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

Ситуация еще больше осложняется, если рядом нет никаких крупных достопримечательностей, о которых все знают и которые можно было бы включить в свой маршрут после короткого поиска в интернете. Что делать если вы застряли в каком-нибудь Купчино, про которое вы только и слышали, что там лучше не застревать? Приходится идти по навигатору, надеясь, что на пути встретится что-то интересное. Однако популярные навигаторы учитывают лишь расстояние и время в пути, но не принимают во внимание интересность маршрута. Мне попадались еще проекты, пытающиеся учитывать удобство пешего маршрута (ведущие в обход шумных магистралей), но хочется же пройти не только комфортно, но и увидеть какие-нибудь красоты.



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

Описание алгоритма и примеры работы под катом, ссылка в конце.

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

Пожалуй, первое, что многим приходит в голову при слове «консоль» — это команда console.log(). Однако, она — лишь одна из многих подобных команд. Материал, перевод которого мы сегодня публикуем, посвящён особенностям работы с консолью JavaScript.

Предлагаю самим разобраться с докладом «мирового правительства», а заодно и помочь перевести первоисточник.

3.18 Образование для устойчивой цивилизации

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

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

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