ЛОЛШТО?

Пожалуйста, не поймите меня неправильно. Я профессиональный разработчик с 30-летним стажем. Я могу читать и понимать почти двадцать языков, полных по Тюрингу. Я могу писать ясный и выразительный код на доброй дюжине из них. В языках, которые я действительно люблю и использую ежедневно — мое имя можно увидеть на доске почета StackOverflow (топ-20 в мире: ruby, elixir). Я по-настоящему люблю писать код, и я отклоняю все предложения «вырасти» по должностной лестнице, будь то руководство проектами, CTO, или что угодно в этом направлении, несмотря на потенциальное увеличение дохода в разы.

— Abraham Willemsens (Metropolitan Museum of Art)

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

Перевод статьи из блога инженера Джорджа Хиллиарда


Кликабельно

Я инженер встроенных систем. В свободное время я часто ищу то, что можно будет использовать в проектировании будущих систем, или что-то из разряда моих интересов.

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

Я подумал: «Эти процессоры настолько дешёвые, что их практически можно раздавать даром». И через некоторое время ко мне пришла идея сделать голую карточку для Linux в форм-факторе визитной карточки.

У меня есть мечта – лет в 50 выйти на пенсию, сидеть на берегу моря и программировать для какого-нибудь проекта. Бесплатно и для души…



Сейчас я сижу на пляже и пишу код за деньги. Мне 34. Я во Вьетнаме. Передо мной столик с ноутбуком, надо мной — навес пляжного бара, слева – славный город Нячанг, а справа – волны Южно-Китайского моря. К этому столику в пляжном баре я шел последние пять лет.

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

Введение: найди кота

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

Тот, кто записал баг, точно знает, где кот. Он его уже нашёл. Он уже не может его развидеть.
А я должен сидеть, пыриться в монитор и искать грёбаного кота.

Привет, меня зовут Дмитрий, мне 35 лет. Раньше я часто слышал, что программист — профессия для молодых. Тем не менее прошлым летом я получил приглашение в Яндекс и перебрался работать в Москву.

В этой статье я хотел бы затронуть вопрос, который не раз обсуждался на Хабре: насколько реально быть программистом после 35–40 лет? Не ведущим архитектором, не тимлидом, не менеджером проекта, а именно программистом? Я не согласен с мнением, что программирование — это удел молодых. Считаю его вредным и сейчас расскажу почему.

Существует несколько доводов, на которые опирается этот миф. Давайте-ка их подробно рассмотрим.

Все хорошие стартапы либо быстро умирают, либо дорастают до необходимости масштабироваться. Мы смоделируем такой стартап, который сначала про фичи, а потом про перфоманс. Перфоманс будем улучшать с MongoDB — это популярное NoSQL-решение для хранения данных. С MongoDB легко стартовать, и многие проблемы имеют решения «из коробки». Однако, когда нагрузка растет, вылезают грабли, о которых вас заранее никто не предупреждал… до сегодняшнего дня!



Моделирование проводит Сергей Загурский, который отвечает за инфраструктуру бэкенда вообще, и MongoDB в частности, в Joom. Также был замечен в серверной части разработки MMORPG Skyforge. Как сам себя описывает Сергей — «профессиональный набиватель шишек собственным лбом и граблями». Под микроскопом — проект, который использует стратегию накопления для управления техническими долгом. В этой текстовой версии доклада на HighLoad++ будем двигаться в хронологическом порядке от возникновения проблемы до решения с помощью MongoDB.

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

Артем Московский — багхантер, пентестер и безопасник которому сразу хочется задать стыдный вопрос «сколько ты зарабатываешь?» В прошлом году он получил самое большое вознаграждение в истории Valve — $20 тыс и $25 тысяч за две крупные уязвимости в Steam и еще $10 тыс за баги поменьше.

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

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

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

Чем бы оно ни было, я эту фигню не понимал никогда.

Сторонники культов кажутся мне непроходимыми тупицами. А я всегда пытаюсь понять, как тупицы стали тупицами, и почему тупицей не стал я. Начал думать и бам! — понял, что все-таки стал. Я тупица-культист, который восхваляет F#. И конечно за этим есть история.

Предисловие

Данный текст предполагает, что читатель ознакомлен с т.н. agile-манифестом разработки программного обеспечения и его т.н. основополагающими принципами.

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

Содержание

1. Манифест жёсткого программиста
2. Основополагающие принципы манифеста жёсткого программиста
3. Комментарии

Манифест жёсткого программиста

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

Концепция важнее новых требований
Качество важнее скорости
Делать как надо важнее, чем делать как просят

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

^{Мыс Доброй Надежды}

С английским у меня беда. Дело в том, что учил я его по MS-DOS и Паскалю, а потом по фильмам. Поэтому читать и переводить в нашу сторону научился хорошо, а вот строить предложения на лету для разговора – нет. А оно сильно надо, потому что у Мосигры всё больше и больше партнёров в Европе. Думаю, у вас такие проблемы не возникают, но вот желание заправить трактор иногда появляется — и живой английский реально нужен почти каждому.


^{Мой заезд: Швейцария, Эмираты, Германия, Канада, Франция}

Поэтому я недолго думая отправился в Южную Африку. Быстрых по визе вариантов с тёплой погодой было три: Мальта (где среди учеников сплошь китайцы, а сам остров можно обойти за два дня), Дублин (с очень интересным акцентом) и Кейптаун (колония Великобритании). Поэтому – вниз, за экватор, и на самый край обитаемого мира. В Африку, к пушистым слонам и пингвинам, копающим норы.

Ну привет. Я только что с собеса, и у меня бомбит. Сколько не пишут на Хабре, как правильно собеседовать — лучше не становится.

Мне кинули предложение — Senior full-stack .NET Developer, удаленно, крутой проект, куча денег. В списке требований хренова гора не связанных между собой вещей из мира .net и js/ts. Выглядит так, будто просто свалили в кучу все, что нагуглили за 10 минут — причем мало понимая, что именно.

Тревожно, но ничего. Собеседовать, думаю, будет разработчик — человек, с которым я говорю на одном языке. Расскажу про то, что делал, обсудим подходы к решению задач, проблемы в .NET, перспективы C#. Поговорим про структуры данных. Расскажу, почему структурная типизация мне нравится больше, чем мнемоническая. Если пойдет хорошо, поделюсь даже своей идеей фикс — всегда использовать структуры вместо классов в качестве моделей. Посравниваю FLUX с MVVM, расскажу, как нереально красив симбиоз ФП и ООП в TypeScript.

В общем, предвкушаю хороший разговор.

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

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

Для примера, современные автомобили работают, скажем, на 98% от того, что физически позволяет нынешняя конструкция двигателя. Современная архитектура использует точно рассчитанное количество материала, чтобы выполнять свою функцию и оставаться в безопасности в данных условиях. Все самолёты сошлись к оптимальному размеру/форме/нагрузке и в основном выглядят одинаково.

Только в программном обеспечении считается нормальным, если программа работает на уровне 1% или даже 0,01% от возможной производительности. Ни у кого вроде нет возражений.

Это практическое пособие познакомит вас c Ansible. Вам понадобится виртуальная или реальная машина, которая будет выступать в роли узла для Ansible. Окружение для Vagrant идет в комплекте с этим пособием.

Ansible — это программное решение для удаленного управления конфигурациями. Оно позволяет настраивать удаленные машины. Главное его отличие от других подобных систем в том, что Ansible использует существующую инфраструктуру SSH, в то время как другие (chef, puppet, и пр.) требуют установки специального PKI-окружения.

Пособие покрывает такие темы:

1. Установка Ansible и Vagrant
2. Файл инвенторизации
3. Модули shell, copy, сбор фактов, переменные
4. Запуск на группу хостов
5. Плейбуки
6. Пример: поднимаем кластер, устанавливаем и настраиваем Apache и балансировщик нагрузок HAproxy
7. Обработка ошибок, откат
8. Шаблоны конфигурации
9. Роли

Ansible использует так называемый push mode: конфигурация «проталкивается» (push) с главной машины. Другие CM-системы обычно поступают наоборот – узлы «тянут» (pull) конфигурацию с главной машины.

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

Я люблю делать простые как топор вещи, но одновременно жутко полезные, например, как прошлая статья 9 летней давности — Установка Ubuntu Linux с винчестера. Скрипт, вот и сейчас настал час для такой деятельности.
Под катом вы найдете подробнейшую инструкцию как на основе Arduino и дешевых и доступных средств автоматизировать подачу чистой свежей воды в кофемашину, а также организовать отвод жидкости из поддона кофемашины, на которой не предусмотрено подключение к внешним коммуникациям.

В 2014 году начали свое действие постановления правительства РФ №758 №801, обязывающие владельцев публичных WiFi сетей настроить на роутерах идентификацию пользователей через паспортные данные, sms или портал гос. услуг. Нежелание владельцев кафе тратиться за Captive portal'ы поспособствовало некоторым провайдерам в распространении своих точек доступа с платной sms-авторизацией. У меня возникло желание проверить, можно ли подобную sms-авторизацию обойти.

Эксперименты на людях любят не только социологи, но и менеджеры продуктов – особенно, когда это самый эффективный способ узнать, какие «фишки» сработают на твою аудиторию. Мы, в Mobile Dimension, решили проверить, котики или продуманное ценностное предложение увеличит количество in-app покупок, и пришли к любопытным результатам.

В первый раз я услышал о CQRS, когда устроился на новую работу. В компании, в которой работаю и по сей день, мне сразу сказали что на проекте, над которым я буду работать используется CQRS, Event Sourcing, и MongoDB в качестве базы данных. Из этого всего я слышал только о MongoDB. Попытавшись вникнуть в CQRS, я не сразу понял все тонкости данного подхода, но почему-то мне понравилась идея разделения модели взаимодействия с данными на две — read и write. Возможно потому что она как-то перекликалась с парадигмой программирования “разделение обязанностей”, возможно потому что была очень в духе DDD.

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

Сразу хочу уточнить что я работал только со связкой CQRS + Event Sourcing, и никогда не пробовал просто CQRS, так как мне кажется что без Event Sourcing он теряет очень много бенефитов. В качестве CQRS фреймворка я буду использовать наш корпоративный Paralect.Domain. Он чем-то лучше других, чем то хуже. В любом случае советую вам ознакомиться и с остальными. Я здесь упомяну только несколько фреймворков для .NET. Наиболее популярные это NCQRS, Lokad CQRS, SimpleCQRS. Так же можете посмотреть на Event Store Джонатана Оливера с поддержкой огромного количества различных баз данных.

Начнем с CQRS

Что же такое CQRS?
CQRS расшифровывается как Command Query Responsibility Segregation (разделение ответственности на команды и запросы). Это паттерн проектирования, о котором я впервые услышал от Грега Янга (Greg Young). В его основе лежит простое понятие, что вы можете использовать разные модели для обновления и чтения информации. Однако это простое понятие ведет к серьёзным последствиям в проектировании информационных систем. (с) Мартин Фаулер

Сегодня мы продолжаем обсуждать прошедший Google I/O, производительные API, вместе с Кармаком вспоминаем Джобса, рисуем формы и копаемся в пользователях. Присоединяйтесь!