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

Самый бедный и несчастный вид разработчиков — это версталы. Как их, бедненьких, только не называли. «Верстальщик», «клиентский разработчик», «браузерный программист», «фронтовик», «разработчик HTML», «джаваскрипт-разработчик» (это самое обидное, на мой взгляд). Гугл вообще переводит это как «разработчик переднего конца».

Сегодня в соцсетях прочитал вообще феерическую формулировку: «Нашему клиенту на аутстафф требуется Фронт Эндщик». Фронт, мать его, Эндщик!

— Ват из йоур нейм, мистер?
— Май нейм из Эндщик. Фронт Эндщик.

Эта формулировка заиграет совсем другими красками, если любого разработчика назвать «эндщик». Попробуйте сами произнести это вслух: «биг дата эндщик», «си эндщик», «питонэндщик».

Хорошего дня, эндщики!

Читая различные доски объявлений о поиске работы и вакансий практически невозможно наткнуться на «оператора дрели Bosh», «установщика вентильных кран-буксовых смесителей для умывальника». Такая вот узкая специализация вообще позволительна только в тех случаях, когда совершенно точно понятно с чем нужно иметь дело. Например «адвокат по бракоразводным процессам» или «водитель маршрутного такси». И даже в этом случае даже узкая специализация говорит скорее о результате, а не об инструментах. Согласитесь, инструментарий в названии профессии выглядит как минимум странно. Конечно же это касается и вакансий. «Требуется виртуозный крутильщик руля и нажиматель педалей с опытом нажатия педалей от двух лет».

А что касается нас, айтишников, то такое встречается сплошь и рядом и, что самое ужасное, считается естесстевнным. Речь о «джаваскрипт-разработчиках» или «питон-разработчиках». Еще более серьезная степень инструментного ориентирования выражается в виде фрейморков или библиотек. «Вордпрес-разработчик», «rails-разработчик» или даже «react.js-разработчик». Гнать таких в шею. Программисты в первую очередь — решатели проблем, и что они используют для решения этих самых проблем, это дело десятое. И формулировать профессию нужно в виде проблемы, а не инструмента, который используется для этого.

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

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

А что будет, если подсоединить вместо руки какую-нибудь кардинально другую сложную штуковину, которая вовсе на руку и не похожа? Сможет ли человеческое сознание адаптироваться и управлять ею? Однозначно да. А что если эта штуковина вообще не будет манипулятором, а, скажем, флеш-картой с возможностью записи и чтения через нейроинтерфейс? Мозг адаптируется и начнет использовать это для запоминания какой-то там нужной мозгу информации, тем самым расширив базовые возможности мозга. Эта электронная часть мозга, в отличие от основной, перестанет стареть, будет все время выдавать тот же результат на одни и те же раздражители и вообще будет работать стабильней всего остального мозга. Свыкнувшись с новым органом, отказаться от него уже будет тяжело — это будет равносильно потере руки или глаза. Таким вот образом, постепенно мозг можно будет заменить целиком и в конце будет совершенно непонятно что есть человек и где тут робот.

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

Ребята, нас уже больше пятиста человек! Ради такого события и эмоджи можно поставить. Вот оно: 🎉 (или эмоджи — это «он»?).

Я очень рад, что заметки в этом канале читают и невероятно приятно, что нас становится все больше и больше. Хотелось бы услышать пару слов и от вас тоже. Мне будет очень приятно, если вы напишете пару строк мне лично. Расскажите что вам нравится в этом канале, а что вам не нравится в канале и что стоило бы улучшить. Спасибо вам. Пишите: @aratak.

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

И ещё повод гордится кодом может найтись совсем не там, где приложение его предполагает.

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

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

Есть офигительно красивое и умное слово, которое объясняет достаточно простую и очевидную штуку. Если нечто может быть вызвано несколько раз подряд, и это ничего не сломает и результат всегда будет один и тот же, то это нечто обладает свойством «идемпотентность». Это свойство применимо как правило к куску кода, будь то метод класса, процедура, скрипт или отправка http-запроса. Если метод класса меняет объект каждый раз, как вызывается, то он не идемпотентен. Допустим, метод увеличения числа на единицу не идемпотентен: a.increment(). А вот метод, который разрешает пользователю вход в систему, как правило, идемпотентен: user.approve().

Идемпотентность критична, когда это применимо к какому-либо независимому состоянию, например база данных или сервер. Скрипт echo 'hello' > 1.txt — идемпотентен, скрипт echo 'hello' >> 1.txt — нет. Еще одним хорошим примером важности этого свойства служат GET и POST запросы. Все, что идемпотентно может быть сделано через GET. Неидемпотентные операции делать лучше POST-подобными запросами.
В результате можно вывести правило, что ваш код должен быть идемпотентен чуть менее, чем полностью за редким исключением.

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

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

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

Сейчас невероятно модным считается архитектура, где одно приложение состоит из множества маленьких отдельных программок, называемых микросервисами. Черт подери, это не микросервисы, это самая обычная инкапсуляция с полиморфизмом на уровне процессов и виртуализации. Если бы код в монолитном проекте был чистым и красивым, то микросервисы бы вообще не понадобились! А так микросервисная архитектура – это способ заставить разработчиков писать код с понятным и вменяемым интерфейсом взаимодействия, соблюдая вышеупомянутые принципы. Потому что в монолитном приложении за этим следить значительно сложнее.

Кстати, у эмоджи есть специальный символ хаоса, применимого к коду: «💩»

Один из самых серьёзных аргументов против использования гибких методологий основан на примере строительства дома. Говорят, мол, «как вы, Адепты Великого Оджайла построите дом без чертежей, плана и на ходу переделывая архитектуру?». Еще в подкрепление своих слов приводят в пример картинку с домом, основанном на подпорках, разных способах постройки, который вот-вот развалится.

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

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

Еще сейчас сильно извратили понятие "MVP", что в расшифровке означает «минимально жизнеспособный продукт» (согласитесь, русская аббревиатура «МЖП» звучит как-то колоритнее английского аналога). Купленный домен и страничка на вордпрессе — это не МЖП, это всего лишь картинка продукта. Прям как у Джека Воробья с его картой сокровищ.

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

Да, да. Вы правы. Капитана Джека Воробья.

Давно придумал такой термин, как «презумпция дружественности», по аналогии с общеизвестным юридическим термином. Значение у него очень простое и очевидное из названия: любой товарищ-друг относится к тебе дружественно, если не доказано обратного. Если бы все придерживались этого принципа то:

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

Конечно, не стоит вообще даже начинать думать об этом термине, встречаясь в подворотне с джентельменами в спортивках.

Цена за рекламу, как правило коррелирует с ее эффективностью, что вполне себе логично и очевидно. Реклама, которая менее эффективна стоит меньше, высокоэффективная реклама стоит дороже, уж простите за очевидность.
Эффективность рекламы считается тоже вполне логично — стоимость рекламы делят на количество людей, которые её увидят и на количество людей, которые на рекламу клюнули.
Давайте закроем глаза и представим самый дешевый и неэффективный способ рекламы, который вообще возможен. Я вот представляю себе футболки с логотипами брендов. Особенно те, которые раздают на конференциях. И правда, посудите сами: стоимость размещения рекламы равна нулю и платить нужно только за себестоимость произведения самой рекламы.
А чувствовать себя человек, надевающий футболку должен приблизительно как Брюс Уиллис в третьем «Крепком орешке».

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

Сегодня я опять о версталах. Фронтэндер с парой лет опыта (что уже довольно много по современным сеньорным оценкам) пришел в профессию уже когда react.js и angular.js существовали. Для него, молодого, это что-то такое естественное и незыблемое, что было, есть и наверное будет всегда. Кроме того, засилье разнообразных способов подготовить статические файлы для вашего сайта продолжается и не собирается останавливаться. Вспомните только количество современных вебпаков! И да, современный верстальщик ко всему прочему еще и верстать уметь должен.

Кстати, пользуясь случаем верстальщической темы, взаимно порекомендую телеграм-канал, который сам с удовольствием читаю: @front_end_dev. Там можно увидеть новости мира верстки и браузерного программирования до того, как они появится в менее поворотливых медиа-ресурсах.

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

Выходные — зло. Затянувшиеся выходные — затянувшееся зло.

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

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

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

Уверен, вы знаете, что каждые 7, 11, 13 или 17 лет цикады одновременно и массово вылезают на свет, отращивают крылья и устраивают оргии с целью размножения и вскоре умирают. Животные, что питаются цикадами живут более быстрыми и более стабильными циклами от двух до шести лет между пиком и спадом популяции. Получается, что задача цикад состоит в том, чтобы минимизировать контакты с представителями, удобно расположившихся выше пищевой цепочке. Простота выбранных чисел гарантирует минимальное пересечение с любым другим циклом, что означает повышенную гарантию выживаемости. Гениально, правда?

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

- неделя может быть длиной 5, 7, 11 или 13 дней;
- каждая следующая неделя должна быть не такой длины, как предыдущая;
- количество выходных дней, рассчитывается согласно стандартной пропорции пять рабочих дней к двум выходным. Накопилось целое количество выходных добавляется к следующей неделе;

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