Салют, хабровчане! В преддверии старта продвинутого курса «Разработчик IOS» мы подготовили еще один интересный перевод.

---

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

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

Из законов физики следует, что течение времени – всего лишь иллюзия. Чтобы избежать такого заключения, нам, возможно, придётся переосмыслить реальность чисел с бесконечной точностью.

Если числа нельзя записывать бесконечными последовательностями цифр, то и будущее не предопределено

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

К примеру, в теории относительности Эйнштейна время переплетено с тремя измерениями пространства, и формирует гибкий четырёхмерный пространственно-временной континуум – "блок-вселенную", охватывающую прошлое, настоящее и будущее. Уравнения Эйнштейна описывают всё в блок-вселенной, как предрешённое с самого начала; изначальные условия космоса определяют, что будет дальше, и никаких сюрпризов не происходит – они только кажутся сюрпризами. «Для нас, верящих в физику, — писал Эйнштейн в 1955, за несколько недель до смерти, — различие между прошлым, настоящим и будущим является лишь упорной и настойчивой иллюзией».

Недавно мне довелось разрабатывать на Go http-клиент для сервиса, предоставляющего REST API с json-ом в роли формата кодирования. Стандартная задача, но в ходе работы мне пришлось столкнуться с нестандартной проблемой. Рассказываю в чем суть.

Как известно, формат json имеет типы данных. Четыре примитивных: строка, число, логический, null; и два структурных типа: объект и массив. В данном случае нас интересуют примитивные типы. Вот пример json кода с четырьмя полями разных типов:

{
	"name":"qwerty",
	"price":258.25,
	"active":true,
	"description":null,
}

Как видно в примере, строковое значение заключается в кавычки. Числовое — не имеет кавычек. Логический тип может иметь только одно из двух значений: true или false (без кавычек). И тип null соответственно имеет значение null (также без кавычек).

А теперь собственно сама проблема. В какой-то момент, при детальном рассмотрении получаемого от стороннего сервиса json-кода, я обнаружил, что одно из полей (назовем его price) помимо числового значения периодически имеет строковое значение (число в кавычках). Т. е. один и тот же запрос с разными параметрами может вернуть число в виде числа, а может вернуть это же число в виде строки. Ума не приложу, как на том конце организован код, возвращающий такие результаты, но видимо, это связано с тем, что сервис сам является агрегатором и тянет данные из разных источников, а разработчики не привели json ответа сервера к единому формату. Тем не менее, надо работать с тем что есть.

Но далее меня ждало еще большее удивление. Логическое поле (назовем его active), помимо значений true и false, возвращало строковые значения «true», «false», и даже числовые 1 и 0 (истина и ложь соответственно).

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

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

UPD. Ссылка на новый репозиторий проекта с поддержкой развертывания в Kubernetes

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

Первая часть шаблона посвящена HTTP серверу:

• настройка HTTP сервера через командную строку и конфигурационный файл
• настройка параметров TLS HTTP сервера
• настройка роутера и регистрация HTTP и prof-обработчиков
• настройка логирования HTTP трафика, логирования ошибок в HTTP
• HTTP Basic и MS AD аутентификация, JSON Web Token
• запуск сервера с ожиданием возврата в канал ошибок
• использование контекста для корректной остановки сервера и связанных сервисов
• настройка кастомной обработки ошибок и кастомного логирования
• сборка кода с внедрением версии, даты сборки и commit

Вторая часть шаблона посвящена прототипированию REST API.
Ссылка на репозиторий проекта осталась прежней.

Третья часть посвящена развертыванию шаблона в Docker, Docker Compose, Kubernetes (kustomize).

Пятая часть посвящена оптимизации Worker pool и особенностям его работы в составе микросервиса, развернутого в Kubernetes.

В ходе тестирования шаблона на стенде были получены следующие результаты.

Всем привет. На связи Владислав Родин. В настоящее время я являюсь руководителем курса «Архитектор высоких нагрузок» в OTUS, а также преподаю на курсах, посвященных архитектуре ПО.

Помимо преподавания, как вы могли заметить, я занимаюсь написанием авторского материала для блога OTUS на хабре и сегодняшнюю статью хочу приурочить к запуску курса «PostgreSQL», на который прямо сейчас открыт набор.

---

Введение

В прошлый раз мы с вами поговорили про то, что транзакции в базах данных служат для решения двух задач: обеспечения отказоустойчивости и доступа к данным в конкурентной среде. Для полноценного выполнения этих задач транзакция должна обладать свойствами ACID. Сегодня мы подробно поговорим про букву I (isolation) в данной аббревиатуре.

Оглавление

Введение
1. Установка и начало работы
2. Redux
....2.1 createStore
....2.2 reducer()
....2.3 dispatch()
....2.4 actionCreator()
....2.5 Actions
....2.6 getState()
....2.7 subscribe()
....2.8 combineReducers()
....2.9 initialState
3. React-redux
....3.1 Provider
....3.2 mapStateToProps()
....3.3 mapDispatchToProps()
....3.4 connect()

Введение

Вот вы прочитали мою статью про React (если нет, то настоятельно рекомендую вам сделать это) и начали разрабатывать приложения на нём. Но что это? Вы замечаете, как с расширением вашего приложения становится всё сложнее следить за текущим состоянием, сложно следить за тем, когда и какие компоненты рендарятся, когда они не рендарятся и почему они не рендарятся, сложно следить за потоком изменяющихся данных. Для этого и есть библиотека Redux. Сам React хоть и лёгкий, но для комфортной разработки на нем нужно много чего изучить.

Доброго времени суток, друзья!

Представляю вашему вниманию перевод статьи «Understanding (all) JavaScript module formats and tools» автора Dixin.

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

• IIFE модуль: шаблон JS модуля
• Открытый модуль: шаблон открытого JS модуля
• CJS модуль: CommonJS модуль или Node.js модуль
• AMD модуль: асинхронное определение модуля или RequireJS модуль
• UMD модуль: универсальное определение модуля или UmdJS модуль
• ES модуль: ECMAScript2015 или ES6 модуль
• ES динамический модуль: ECMAScript2020 или ES11 динамический модуль
• Системный модуль: SystemJS модуль
• Webpack модуль: транспиляция и сборка CJS, AMD и ES модулей
• Babel модуль: транспиляция ES модуля
• TypeScript модуль: транспиляция CJS, AMD, ES и SystemJS модулей

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



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

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

Осенью 2018 года мы опубликовали список из 25 полезных инструментов Kubernetes. С тех популярность платформы сильно выросла. Экосистема оркестрации контейнеров бурно развивается, можно найти вспомогательные инструменты практически для любой задачи.

Поэтому команда Kubernetes aaS от Mail.ru обновила и дополнила подборку. Предлагаем вашему вниманию список с почти сотней полезных инструментов, упрощающих жизнь тем, кто работает с Kubernetes.

Приветствую! Представляю вашему вниманию перевод статьи «Understanding CSS Grid: Grid Template Areas» автора Rachel Andrew

При использовании CSS Grid, вы можете располагать элементы на сетке, указывая начальную и конечную grid-линии. Однако, существует и другой, более наглядный способ описания разметки. В этой статье мы узнаем, как использовать свойство grid-template-areas для размещения элементов на сетке и выясним, как оно в действительности работает.

Введение от автора обзора

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

Хочу поделиться с вами подходом который я уже много лет использую в разработке приложений, в том числе и веб-приложений. Многим разработчикам настольных, серверных и мобильных приложений этот подход хорошо знаком, т.к. является фундаментальным при построении таких приложений, однако в вебе он представлен очень скудно, хотя желающие использовать такой подход однозначно есть. Кроме того на таком подходе написан редактор VS Code.



В результате применения этого подхода вы отвяжетесь от конкретного фреймворка. Сможете легко переключать библиотеку представления внутри вашего приложения, например React, Preact, Vue, Mithril без переписывания бизнес логики, а в большинстве случаев даже вьюхи. Если у вас есть приложение на Angular 1, вы без проблем сможете перевести его на Angular 2+, React, Svelte, WebComponents или даже свою библиотеку представления. Если у вас есть приложение на Angular 2+, но нету специалистов для него, то вы без проблем сможете перевести приложение на более популярную библиотеку без переписывания бизнес логики. А в итоге вообще забыть про проблему миграции с фремворка на фреймворк. Что же это за магия такая?

27 ноября 1923 года американские радиолюбители Джон Рейнарц (John L. Reinartz, 1QP) и Фред Шнелль (Fred H. Schnell, 1MO) провели двустороннюю трансатлантическую радиосвязь с радиолюбителем из Франции Леоном Делоем (Leon Deloy, F8AB) на длине волны около 100 м. Это событие оказало огромное влияние на развитие мирового радиолюбительского движения и радиосвязи на коротких волнах. Одним из решающих факторов, повлиявшим на успех, оказалась доработка Шнеллем и Рейнарцем схемы регенеративного радиоприёмника Армстронга. Доработки оказались настолько удачными, что для конструкций подобных приёмников фамилии «Шнелль» и «Рейнарц» стали именами нарицательными.

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

Содержание:

• Что такое тикет?
• Публичный или приватный?
  
  • Для публичных тикетов
  • Для приватных тикетов
• Оценка
  
  • Оценка по приоритетности
  • Оценка по степени влияния
  • Оценка по величине ущерба
  • Оценка по размеру
  • Оценка по критерию MoSCoW
  • Оценка по частоте
  • Совокупная оценка
• Обсуждение оценок
• Шаблон тикета
• Запуск постмортемов
• Безобвинительные постмортемы

Привет, меня зовут Александр Васин, я бэкенд-разработчик в Едадиле. Идея этого материала началась с того, что я хотел разобрать вступительное задание (Я.Диск) в Школу бэкенд-разработки Яндекса. Я начал описывать все тонкости выбора тех или иных технологий, методику тестирования… Получался совсем не разбор, а очень подробный гайд по тому, как писать бэкенды на Python. От первоначальной идеи остались только требования к сервису, на примере которых удобно разбирать инструменты и технологии. В итоге я очнулся на сотне тысяч символов. Ровно столько потребовалось, чтобы рассмотреть всё в мельчайших подробностях. Итак, программа на следующие 100 килобайт: как строить бэкенд сервиса, начиная от выбора инструментов и заканчивая деплоем.



TL;DR: Вот репка на GitHub с приложением, а кто любит (настоящие) лонгриды — прошу под кат.

Транслитерация — это запись кириллических слов латиницей (Анна → Anna, Самара → Samara). Её используют в загранпаспортах, водительских удостоверениях, трансграничной доставке, библиотечных каталогах и множестве других международных процессов.

Так вышло, что я недавно окунулся в эту тему, а в Википедии она раскрыта слабо. Поэтому расскажу, что к чему (спойлер — если вы думаете, что с транслитерацией всё плохо, то на самом деле всё ещё хуже).

И конечно, поскольку это Хабр — предложу open-source библиотеки для решения проблемы.

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


Эта статья посвящена всему, что нужно знать о настройке расстояний между элементами и о настройке внутренних пространств элементов. В частности, речь пойдёт о том, в каких ситуациях стоит использовать внутренние отступы (padding), а в каких — внешние (margin).

>>> +--+_+-+_++_+--_+_-_+-+-+-___++++_+-_-+++_+-+_--++--_
'ПРИВЕТ, ХАБР!'

Что это было? Да, вы не ошиблись — это азбука Морзе с плюсиками вместо точек прямо в синтаксисе Питона!

Если вы не понимаете, как это работает, или просто не прочь освежить свои знания в День Советской армии (и Военно-морского флота!), добро пожаловать под кат.