(швед. arkitektur)

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

В конце июля 2016 года в корпоративном блоге Uber появилась поистине историческая статья о причинах перехода компании с PostgreSQL на MySQL. С тех пор в жарких обсуждениях этого материала было сломано немало копий, аргументы Uber были тщательно препарированы, компанию обвинили в предвзятости, технической неграмотности, неспособности эффективно взаимодействовать с сообществом и других смертных грехах, при этом по горячим следам в Postgres было внесено несколько изменений, призванных решить некоторые из описанных проблем. Список последствий на этом не заканчивается, и его можно продолжать еще очень долго.

Наверное, не будет преувеличением сказать, что за последние несколько лет это стало одним из самых громких и резонансных событий, связанных с СУБД PostgreSQL, которую мы, к слову сказать, очень любим и широко используем. Эта ситуация наверняка пошла на пользу не только упомянутым системам, но и движению Free and Open Source в целом. При этом, к сожалению, русского перевода статьи так и не появилось. Ввиду значимости события, а также подробного и интересного с технической точки зрения изложения материала, в котором в стиле «Postgres vs MySQL» идет сравнение физической структуры данных на диске, организации первичных и вторичных индексов, репликации, MVCC, обновлений и поддержки большого количества соединений, мы решили восполнить этот пробел и сделать перевод оригинальной статьи. Результат вы можете найти под катом.

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

Меня зовут Денис Исаев, и я руковожу одной из бэкенд групп в Яндекс.Такси. Сегодня я поделюсь с читателями Хабра описанием проблем, которые могут возникнуть, если не учитывать идемпотентность распределенных систем в своем проекте. Для этого я выбрал формат вымышленных историй о стажёре Васе, который только-только учится работать с API. Так будет нагляднее и полезнее. Поехали.

Привет, Хабр!

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

Знай, это не бред юмориста!
Ода дня одного программиста.
^{(прим. авт.)}

Что вас бесит сильнее всего, когда вы пытаетесь организовать читаемые логи в вашем NodeJS приложении? Лично меня чрезвычайно напрягает отсутствие каких-либо вменяемых зрелых стандартов по созданию trace ID. В этой статье мы поговорим о том, какие есть варианты создания trace ID, разберемся на пальцах как работает continuation-local storage или CLS и призовем на помощь силу Proxy, чтобы завести все это с абсолютно любым логером.

В этой статье мы обсудим разные Git-команды, которые могут оказаться полезными для разработчика или специалиста по Big Data. Вы узнаете, как проверять, удалять и приводить код в порядок. А еще рассмотрим способы выхода из Vim и экономию времени с помощью псевдонимов Bash и конфигурации редактора Git.

App Extensions появились в iOS 8 и сделали систему более гибкой, мощной и доступной для пользователей. Приложения могут отображаться в виде виджета в Центре Уведомлений, предлагать свои фильтры для фотографий в Photos, отображать новую системную клавиатуру и многое другое. При этом сохранилась безопасность пользовательских данных и системы. Об особенностях работы App Extensions и пойдёт речь ниже.

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

Функциональное Программирование: Определение

Прежде всего, Функциональное Программирование — это не язык или синтаксис, а скорее всего — способ решения проблем путем разбиения сложных процессов на более простые и последующей их композиции. Как следует из названия "Функциональное программирование", единицей композиции для данного подхода является функция; и цель такой функции — избежать изменения состояния или значений за пределами своей области действия (scope).

В Мире Swift для этого есть все условия, ибо функции здесь являются такими же полноправными участниками процесса программирования, как и объекты, а проблема изменяемости (mutation) решается на уровне концепции value ТИПОВ (структур struct и перечислений enum), которые помогают управлять изменяемостью (mutation) и четко сообщают о том, как и когда это может произойти.

Однако Swift не является в полном смысле языком Функционального программирования, он не принуждает вас к Функциональному программированию, хотя и признает преимущества Функциональных подходов и находит способы встраивания их.

В этой статье мы сфокусируемся на использовании встроенных в Swift (то есть «из коробки») элементов Функционального программирования и понимании того, как можно их комфортно использовать в вашем приложении.

Введение в MVP, MVC, MVVM и VIPER. Что между ними общего и в чем разница.

Делаете все по MVC, а получается некрасиво? Сомневаетесь, переходить ли на MVVM? Слышали о VIPER, но не уверены, стоит ли оно того?

В этой статье я кратко рассмотрю некоторые популярные архитектурные паттерны в среде iOS и сравню их в теории и на практике. Больше информации вы найдете при переходе по ссылкам, указанным в тексте.

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

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

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

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

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

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

Давно я хотел написать эту статью. Все думал — с какой стороны зайти правильнее? Но, вдруг, недавно, на Хабре появилась подобная статья, которая вызвала бурю в стакане. Больше всего меня удивил тот факт, что статью начали вбивать в минуса, хотя она даже не декларировала что-то, а скорее поднимала вопрос об использовании кодов ответа web-сервера в REST. Дебаты разгорелись жаркие. А апофеозом стало то, что статья ушла в черновики… килобайты комментариев, мнений и т.д. просто исчезли. Многие стали кармо-жертвами, считай, ни за что :)

В общем, именно судьба той статьи побудила меня написать эту. И я очень надеюсь, что она будет полезна и прояснит многое.

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

Автор материала, перевод которого мы публикуем сегодня, работает DevOps-инженером. Он говорит, что ему приходится пользоваться Docker. В частности, эта платформа для управления контейнерами применяется на разных этапах жизненного цикла Node.js-приложений. Использование Docker, технологии, которая, в последнее время, является чрезвычайно популярной, позволяет оптимизировать процесс разработки и вывода в продакшн Node.js-проектов.



Сейчас мы публикуем цикл статей о Docker, предназначенных для тех, кто хочет освоить эту платформу для её использования в самых разных ситуациях. Этот же материал сосредоточен, в основном, на профессиональном применении Docker в Node.js-разработке.

Друзья, всем привет!

Эта статья в первую очередь будет интересна фронтенд-разработчикам, особенно тем кому актуальна тема GraphQL, но в то же время я надеюсь, что она будет полезна и бэкенд-разработчикам и поможет им понять преимущества GraphQL глазами фронтендера.

AudioKit — это аудиофреймворк, разработанный аудиоинженерами, программистами и музыкантами специально для iOS и OSX. Он предоставляет инструменты для обработки и синтезирования звука. Под капотом — это смесь из Swift, Objective-C, C++ и С, и Audio Unit API от Apple. Потрясающие (и довольно сложные) технологии завёрнуты в очень дружелюбное Swift API, к которому можно обращаться прямо из Xcode Playgrounds!

В этом туториале мы отправимся в путешествие по AudioKit, а заодно и истории синтезирования звука. Вы узнаете об основах физики звука и том, как работали первые синтезаторы, такие как Hammond Organ. Также будут рассмотрены и современные техники, например, семплинг.

Приготовьте ваш любимый напиток, устраивайтесь поудобнее и вперёд!

Небольшой вопрос/ответ:

Для кого это? Людям, которые мало или вообще не сталкивались с распределенными системами, и которым интересно увидеть как они могут строится, какие существуют паттерны и решения.

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

Постановка задачи

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

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

%рандомная шутка про почту россии%

Использовать будем Node.JS, он идеален для прототипирования. Для сокетов возьмем Socket.IO. Писать на TypeScript.

И так, что вообще мы хотим:

1. Чтоб пользователи могли слать друг-другу сообщения
2. Знать кто онлайн/оффлайн

Как мы это хотим:

Привет, %habrauser%!

Сегодня я хочу рассказать тебе об одном отличном, на мой взгляд, микросервисном фреймворке Moleculer.



Изначально этот фреймворк был написан на Node.js, но в последствии у него появились порты и на других языках таких как Java, Go, Python и .NET и, скорее всего, в ближайшем будущем, появятся и другие имплементации. Мы используем его в продакшене в нескольких продуктах уже около года и словами сложно описать, каким благословением он нам показался после использования Seneca и своих_велосипедов. Мы получили всё что нам нужно из коробки: сбор метрик, кэширование, балансировка, fault-tolerance, транспорты на выбор, валидация параметров, логирование, лаконичное объявление методов, несколько способов межсервисного взаимодействия, миксины и многое другое. А теперь по порядку.

Это последняя часть моего обзора компилятора Swift. Я покажу, как можно осуществить генерацию LLVM IR из AST и что выдаёт настоящий фронтенд. Если вы не читали предыдущие части, то переходите по ссылкам:

• Общий обзор компонентов
• Разбор исходного файла
• Swift intermediate language

Доброго времени суток.

Опишу процесс авторизации с использованием некоторого сервера авторизации и интерфейса HttpInterceptor, который стал доступен с версии Angular 4.3+. С помощью HttpInterceptor`a будем добавлять наш токен в Header запроса перед отправкой каждого запроса. Так же, по истечению срока действия токена, получая 401ую ошибку, будем восстанавливать токен и повторять запросы, которые не прошли авторизацию пока ждали рефреша.

Начнем с конфигурации Interceptor`ов:

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