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

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

• Во-первых, нашему монолиту уже 9 лет.
• Во-вторых, всю жизнь он провёл под хайлоадом (сейчас это 23 млн запросов в час).
• А в NaN-ых, мы пишем наш монолит на Node.JS, который за эти 9 лет изменился до неузнаваемости. Да, мы начинали писать на ноде в 2010, безумству храбрых поём мы песню!

Так что всякой специфики и реального опыта у нас довольно много. Интересно? Поехали!

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

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

[В квадратных скобках — мои примечания.]

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

В прошлой статье мы оптимизировали поиск в PostgreSQL стандартными средствами. В этой статье мы продолжим оптимизацию с помощью индекса RUM и проанализируем его плюсы и минусы в сравнении с GIN.

Это, пожалуй, самая интересная статья о перспективах применения смарт-контрактов в деловой практике, которая мне попадалась (правда, попадалось их не так уж много). Она написана юристами и опубликована в конце мая на сайте Гарварда. Хоть и на примере США, текст раскрывает такие вопросы как применение законодательства к сделкам на смарт-контрактах, проблему понимания сторонами кода, проблему оракулов, риски и другие.

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

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

1. Для создания иерархии используем цвет и вес вместо размера

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

Итак, что дано:

• Есть большой репозиторий, содержащий множество папок. Каждая папка – это отдельный проект.

Что необходимо сделать:

• Одну из папок перенести в отдельный репозиторий с сохранением ее истории коммитов.

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

Я использовал стандартный гитовый filter-branch. За основу я взял следующие статьи:

• Moving Files from one Git Repository to Another, Preserving History
• Splitting a subfolder out into a new repository

В этом посте я хочу немного адаптировать процесс для лучшего восприятия.

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

Мысли Криса Койера

От переводчика

В этой статье я расскажу о различии возможностей, которые предоставляют iOS-разработчикам языки Swift и Objective-C. Безусловно, разработчики, которые интересовались новым языком от Apple, уже видели немало подобных статей, поэтому я решил акцентировать внимание на тех отличиях, которые действительно влияют на процесс разработки и на архитектуру приложения. То есть, те отличия, которые следует знать, чтобы использовать язык максимально эффективно. Я попытался составить наиболее полный список, удовлетворяющий этим критериям.

Кроме того, рассказывая о новых возможностях, которые Swift привнёс в разработку, я постарался не забыть упомянуть то, что он потерял по сравнению с Objective-C.

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

На момент написания статьи текущая версия Swift — 3.0.1.