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

«Исходный код словно заржавел!» — Джоэл Спольски

Почти два десятилетия назад Джоэл Спольски устроил разнос Netscape за то, что она переписала кодовую базу браузера, в своём эпохальном эссе «Чего никогда нельзя делать». Он пришёл к выводу, что функционирующий софт абсолютно никогда не следует переписывать с нуля. У него было два основных аргумента:

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

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

FoundationDB — это распределенная NoSQL база данных с ACID-транзакциями уровня Serializable, хранящая отсортированные пары ключ-значение (ordered key-value store). Ключами и значениями могут быть произвольные последовательности байт. У неё нет единой точки падения — все машины кластера равноправны. Она сама распределяет данные по серверам кластера и  масштабируется на лету: когда в кластер нужно добавить ресурсов, ты просто добавляешь адрес новой машины на конфигурационных серверах и база сама подхватывает ее.

Обратноосмотическая вода — во всех смыслах иллюстрация дихотомии H2O / Примеси.
Мы в АКВАФОР привыкли, что мир делится на:

1. тех кто считает, что осмотический фильтр чистит все, кроме кармы и совести
2. и тех, кто подливает осмотическую воду в чай врагу, считая ее мертвой.

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

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

Мы больше не контролируем свои домашние каталоги.

В моём собственном 25 обычных файлов и 144 скрытых. В дотфайлах хранятся данные, которые не принадлежат мне: они принадлежат программистам, чьи программы решили захватить моё пространство, предназначенное для хранения моих личных файлов.

Я не могу убрать эти файлы в другое место. Если я попытаюсь их удалить, они появятся снова. Всё, что я могу сделать — это сидеть и знать, что в темноте, за кулисами, они есть. Ожидание в тишине. Некоторые из этих программистов решили дополнительно разместить здесь несколько обычных файлов и каталогов. Они хорошо видны каждый раз, когда я выполняю ls. Понятия не имею, как в мою личную папку попали каталог node_modules, файлы package-lock.json, yarn.lock (я никогда сознательно даже не ставил yarn!), какие-то два странных лог-файла от какой-то Java-программы, явно использующей СУБД H2, и папка Desktop. Последнюю создал Steam, что довольно неудачно, поскольку на моей машине просто нет рабочего стола или какого-то десктопа. Боюсь того дня, когда услышу громкий стук в дверь — и один из этих программистов ворвётся и сообщит, что собирается хранить часть своей мебели посреди моей гостиной, если я не возражаю.

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

«В течение недели мне предложили должность инженера-программиста в Google, Facebook, Amazon, Apple, LinkedIn и Yelp. Вот как я проходил у них собеседование.


Что если я скажу вам… что собеседования не так страшны, как кажется?

Понесло пакет по кочкам в дальний лес за DNS…
Л. Каганов "Гамлет на дне"

При разработке сетевого приложения иногда возникает необходимость запустить его локально, но обращаться к нему по реальному доменному имени. Стандартное проверенное решение — прописать домен в файле hosts. Минус подхода в том, что hosts требует чёткого соответствия доменных имён, т.е. не поддерживает звёздочки. Т.е. если есть домены вида:

dom1.example.com,
dom2.example.com,
dom3.example.com,
................
domN.example.com,

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

*.example.com

Решением проблемы может стать использование собственного DNS-сервера, который будет обрабатывать запросы в соответствии с заданной логикой. Такие сервера есть, и вполне бесплатные, и с удобным графическим интерфейсом, например CoreDNS. Так же, можно менять DNS-записи на роутере. Наконец, воспользоваться сервисом наподобие xip.io, это не совсем полноценный DNS-сервер, но для некоторых задач отлично подойдёт. Словом, готовые решения существуют, можно использовать и не заморачиваться.

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

Перевели для вас статью Юлиуса Минмо о настройке непрерывного развертывания (Continuous Deployment) для своего проекта. Автоматизация позволяет сэкономить кучу времени и сил. Статья будет полезна, в первую очередь, начинающим программистам.

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

Всем привет!

Кратко о себе. По образованию я математик, а вот по профессии — программист. В сфере разработки с 2006 года. Хотя, поскольку программирование начали изучать ещё в школе, свои первые программки и игры я начал писать ещё в школе (примерно, с 2003). Так сложилось, что пришлось выучить и поработать на нескольких языках. Если не брать во внимание ВУЗ-овские лекции по С, С++, Бэйсику, Паскалю и Фортрану, то реально я работал с Delphi (более 6 лет), PHP (более 5 лет), Embedded (Atmel + PIC около 2.5 лет) и последним временем Python + чуть-чуть Scala. Конечно же без баз данных тоже никак не обойтись.

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

Автор материала, перевод которого мы сегодня публикуем, говорит, что в JavaScript-объектах содержится много такого, о существовании чего можно и не подозревать, пользуясь ими в повседневной работе. Объекты в JavaScript очень легко создавать, с ними удобно работать, они кажутся понятными и гибкими сущностями, и многие программисты попросту не задумываются о том, что на самом деле устроены объекты не так уж и просто.

NB: Информацию из публикации на практике следует применять крайне аккуратно и под присмотром более опытных коллег.

Наверное, вы слышали про технологию Яндекса DeepHD, с помощью которой они как-то раз улучшили качество советских мультфильмов. Увы, в публичном доступе ее еще нет, а у нас, рядовых программистов, вряд ли найдутся силы написать свое решение. Но лично мне, как обладателю Retina-дисплея (2880х1800), недавно очень захотелось посмотреть «Рика и Морти». Какого же было мое разочарование, когда я увидел, как мыльно на этом экране выглядит 1080р, в котором существуют оригиналы этого мультсериала! (это прекрасное качество и обычно его вполне достаточно, но поверьте, ретина так устроена, что анимация с ее четкими линиями в 1080р выглядит мыльновато, словно 480р на FHD-мониторе)

Я твердо решил, что хочу увидеть этот мультсериал в 4К, хотя и совершенно не умею писать нейросети. Однако решение было найдено! Любопытно, что нам даже не придется писать код, понадобится лишь ~100 ГБ места на диске и немного терпения. А результат — четкое изображение в 4К, которые выглядит достойнее, чем любая интерполяция.

Операционные системы (ОС) — обширная тема. На протяжении десятилетий здесь доминировал один подход: Unix. Действительно, большинство современных систем, включая большинство дистрибутивов GNU/Linux, *BSD и macOS, придерживаются архитектуры Unix. (Windows нет, но там почти ничего интересного по этой теме).

В 2000 году Роб Пайк выступил с докладом о том, почему исследования системного ПО не релеванты. Из-за пессимизма или пренебрежения к сообществу он, кажется, полностью проигнорировал жалобы, собранные многими Unix-пользователями в книге The Unix-Haters Handbook (1994). Книга умышленно саркастична, однако указывает на некоторые критические проблемы систем Unix — и они не решены до сих пор.

В 2006 году Элко Доситра опубликовал диссертацию «Полностью функциональная модель развёртывания программного обеспечения», где описан функциональный менеджер пакетов Nix. В 2008 году автор опубликовал NixOS: полностью функциональный дистрибутив Linux. В то время как NixOS повторно использует много свободного ПО для Unix-систем, она настолько отходит от дизайна и философии Unix, что вряд ли её можно назвать «системой Unix».

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

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

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

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

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

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

Автор материала, перевод которого мы публикуем сегодня, говорит, что он, после того, как долго занимался объектно-ориентированным программированием, задумался о сложности систем. По словам Джона Оустерхаута, сложность (complexity) — это всё, что делает тяжелее понимание или модификацию программного обеспечения. Автор этой статьи, выполнив некоторые изыскания, обнаружил концепции функционального программирования наподобие иммутабельности и чистых функций. Применение таких концепций позволяет создавать функции, не имеющие побочных эффектов. Использование этих функций упрощает поддержку систем и даёт программисту некоторые другие преимущества.



Здесь мы поговорим о функциональном программировании и о некоторых его важных принципах. Всё это будет проиллюстрировано множеством примеров кода на JavaScript.

Расшифровка выступления на конференции Web Camp Zagreb Мачея Цегловского, американского веб-разработчика, предпринимателя, докладчика и социального критика польского происхождения.

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

Опасение было оправданным. Азот, из которого состоит большая часть атмосферы, энергетически нестабилен. Если столкнуть два атома достаточно сильно, они превратятся в атом магния, альфа-частицу и выпустят огромную энергию:

N¹⁴ + N¹⁴ ⇒ Mg²⁴ + α + 17,7 МэВ

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

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

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

План Адама представляет собой список основных пунктов, которые вам нужно изучить самостоятельно. Мы добавили описание, а в некоторых сложных моментах указали ссылки на дополнительные справочные материалы, с помощью которых вы получите ответ на вопрос: «Что я должен узнать как React-разработчик?».

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

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

Начнем с того, что разделение на физиков и лириков придумали в 60ые для смеха, типа западников и славянофилов, или патриотов и либералов, спартак или динамо — классическая “двухпартийная система” наглядно показанная в серии Южного Парка про клизму и бутерброд. Еще древние римляне называли этот принцип “разделяй и властвуй”.

В итоге разным командам дали разные книжки, а про чужие говорили «скучно, вам не понять, да и понимать НЕ НАДО», а понять меж тем легко, главное посмотреть сквозь другие очки, сменить парадигму. Ведь ни одна из парадигм не истина, а вот бинокулярное зрение сильно облегчает жизнь. А тут, дали людям разные очки, одним плюс, другим минус, гуманитариям шестеренок в часах не рассмотреть, а для технарей через 200 метров вся природа абстракция.

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

Перевёл после прочтения комментариев к статье «О ненависти к C++». В цитатах можно найти ответы на большинство возникших там вопросов.

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

49. Lisp — это не язык, а строительный материал.
— Alan Kay

48. Ходить по воде и разрабатывать программы, следуя спецификации, очень просто… если они заморожены.
— Edward V Berard