Привет, Хабр! Представляю вашему вниманию перевод статьи Functional options on steroids от автора Márk Sági-Kazár.



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

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

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

Поэтому темой третьей встречи сообщества PHP-разработчиков в нашем офисе мы сделали производительность бэкенда и пригласили к обсуждению коллег из Авито и «Мамбы».



Читайте под катом расшифровку дискуссии, в которой мне повезло быть модератором: как устроена инфраструктура трёх компаний, как мы измеряем производительность и на какие метрики ориентируемся, какие инструменты используем, как делаем выбор между железом и оптимизацией.

А 15 февраля приходите на следующий Badoo PHP Meetup: обсудим легаси.

В этой статье подробно объясняется, как решать проблемы, связанные с совместимостью баз данных при деплое. Мы расскажем, что может произойти с вашими приложениями на проде, если вы попытаетесь выполнить деплой без предварительной подготовки. Затем мы пройдемся по этапам жизненного цикла приложения, которые необходимы, чтобы иметь нулевое время простоя (прим. пер.: далее — zero downtime). Результатом наших операций будет применение обратно несовместимого изменения базы данных обратно совместимым способом.

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



Год назад одна из команд в Skyeng сталкивалась с такими холиварами почти на каждом ревью. Но затем человек, у которого больше всех болело, сказал: «Теперь живем на Prettier'e, согласны?» За следующие месяцы ребята ни разу не поднимали вопрос о форматировании, а теперь эта штука стоит на всем монорепозитории фронтенда — и его использует каждая команда, которая туда заезжает.

Ленивая загрузка компонентов в Angular? Может, речь идёт о ленивой загрузке модулей с помощью маршрутизатора Angular? Нет, мы говорим именно о компонентах. Текущая версия Angular поддерживает лишь ленивую загрузку модулей. Но Ivy даёт разработчику новые возможности в работе с компонентами.

Те телефоны, о которых идёт речь в заголовке, по-английски называют «feature phone». Они отличаются крайне скромными возможностями. Кроме того, они весьма доступны, так как стоят в районе $20-25. Их можно сравнить с облегчёнными версиями современных смартфонов. Такие телефоны позволяют сотням миллионов человек из развивающихся стран пользоваться веб-ресурсами.


Телефон Jio

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

Друзья и коллеги, в последнее время на Хабре участились статьи с хейтом в адрес 1С, как платформы для разработки, и выступлениями ее защитников. Эти статьи обозначили одну серьезную проблему: чаще всего, критики 1С критикуют ее с позиции "не осиливших", ругая проблемы, которые де-факто, легко решаются, и, напротив, не задевая проблемы, которые действительно важны, стоят обсуждения и не решаются вендором. Полагаю, что имеет смысл провести трезвый и взвешенный обзор платформы 1С. Того, что она умеет, того что она не умеет, того что она должна бы делать, но не делает и, на сладкое — то, что она делает на ура, а ваши разработчики на %technology_name% будут делать стопицот лет, выкинув на ветер не один годовой бюджет.

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

Под катом — масса толстых набросов на 1С, на критиков 1С, на Java, .NET и вообще… Вентилятор заправлен, добро пожаловать!

Привет, Хабр! Представляю Вашему вниманию перевод статьи «Improve SPA performance by splitting your Angular libraries in multiple chunks» автора Kevin Kreuzer.

Angular — отличный фреймворк. Мы все его любим <3.

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

Сегодня благодаря Angular CLI библиотеки легко создать. Они прекрасно подходят для того, чтобы делиться кодом между несколькими приложениями.

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

В Frontend есть разные типы производительности. runtime — производительность и initial load. В этой статье мы сосредоточимся на initial load.

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

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

Предупреждение: ничему полезному эта мини-статья вас не научит.

Как создать и настроить Angular проект с нуля

Статья была обновлена 29 Февраля 2020 чтобы следовать лучшим практикам.

Короткое вступление

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

В настоящее время все больше компаний начинают использовать GraphQL. Это относительно новая технология (если быть более точным, то это язык запросов), которая призвана решить существующие проблемы REST.

Если вы еще не знакомы с GraphQL, то рекомендую начать с ресурсов:

• https://www.howtographql.com/ — интерактивное обучение с заданиями и контрольными точками. Обучение начинается с нуля и заканчивается разработкой GraphQL-приложения.
  
• https://graphql.org/learn/ и https://graphql.github.io/graphql-spec/June2018 — обучение в формате документации. Подходит, если вы хотите изучить конкретную тему.
  
• [upd 04.07.19] https://ctf.hacker101.com — HackerOne сделали два задания на поиск уязвимостей в GraphQL. Хорошее место, чтобы опробовать Voyager. Задания называются BugDB v1 и BugDB v2.
  

В этой статье я хочу поделиться одним из инструментов для поиска уязвимостей в GraphQL API. Если вы искали уязвимости в GraphQL API, то наверняка сталкивались с такими проблемами:

• Вместо документации у вас огромный нечитаемый JSON (GraphQL schema).
  
• Веб-приложение использует только часть GraphQL API, поэтому вы не видите все данные и эндпойнты.
  

В решении этих проблем хорошим помощником является GraphQL Voyager, который визуализирует GraphQL schema. Визуализация значительно облегчает понимание GraphQL API и помогает быстрее найти уязвимости.

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

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

Даны строка данных и строка поиска как произвольные наборы символов, состоящие из слов – групп символов, разделенных пробелами.

Требуется найти в строке данных наиболее близкий к строке поиска по составу и взаимному расположения символов набор фрагментов.

Для оценки качества результата поиска вычислить коэффициент релевантности, значение которого должно лежать в диапазоне от 0 до 1, где 0 должен соответствовать полному отсутствию символов строки поиска в строке данных, а 1 – наличию строки поиска в строке данных в неискаженном виде.

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

Описание алгоритма

Поиск осуществляется в несколько этапов.

Построение матрицы совпадений

Матрица совпадений (M) представляет собой двумерную матрицу, количество столбцов которой соответствует длине строки данных, а количество строк – длине строки поиска. Элементы матрицы совпадений принимают значения 0 или 1 в зависимости от того, совпадают или нет соответствующие символы строк за исключением пробелов (разделителей слов).
Матрица совпадений для строки данных «ABCD EF» и строки поиска «ABC» имеет вид:

Вашему вниманию предлагается перевод поста Гергелия Ороса, занимающего должность Engineering Manager в Uber. В нем он делится своим взглядом на проектирование крупномасштабных систем, основанном на собственном практическом опыте работы в Uber и Microsoft. В сочетании с комментариями на Hacker News, которые добавляют весомые контр-аргументы и дополняют точку зрения автора, его статья стала одним из самых интересных постов недели. В статье используется термин «дизайн кода» для сравнения с традиционной «архитектурой» — о нем подробнее можно прочитать здесь.

На мою долю выпало достаточно опыта в проектировании и создании крупномасштабных систем. Я принимал участие в переписывании распределенной системы платежей в Uber, проектировании и релизе Skype на Xbox One и выпуске в открытый доступ RIBs — мобильного архитектурного фреймворка, созданного в Uber. Все эти системы имели тщательно продуманный дизайн, прошли через несколько итераций, с ними связано множество совещаний, проведенных у маркерной доски, и других обсуждений. Затем придуманный дизайн сводился к дизайн-документу, который распространялся среди других разработчиков для сбора дополнительной обратной связи, который продолжался до тех пор, пока мы не переходили к разработке.

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

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

Если компромиссные решения не для вас, адаптируйте структуру под новую семантику.

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

Новая структура данных Redis 5 под названием «потоки» (streams) вызвала живой интерес в сообществе. Как-нибудь я поговорю с теми, кто использует потоки в продакшне, и напишу об этом. Но сейчас хочу рассмотреть немного другую тему. Мне начинает казаться, что многие представляют потоки неким сюрреалистичным инструментом для решения ужасно трудных задач. Действительно, эта структура данных *также* осуществляет обмен сообщениями, но будет невероятным упрощением считать, что функциональность Redis Streams ограничена только этим.

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

Технология GraphQL за последние несколько лет, после того, как компания Facebook перевела её в разряд опенсорсных, стала весьма популярной. Автор материала, перевод которого мы сегодня публикуем, говорит, что попробовал работать с GraphQL в среде Node.js и на собственном опыте убедился в том, что эта технология, благодаря её замечательным возможностям и простоте, неслучайно привлекает к себе столько внимания. Недавно он, занимаясь новым проектом, перешёл с Node.js на Golang. Тогда он и решил испытать совместную работу Golang и GraphQL.

В начале эпохи домашних компьютеров существовала компания под названием Apple. Она только что заработала огромный успех благодаря линейке компьютеров Apple II, но чтобы оставаться на вершине быстро развивающегося компьютерного рынка, ей необходимы были инновации. Компания уже работала над линейкой Lisa, которая вдохновлялась мини-компьютерами и была предназначена для бизнес-пользователей, а значит, и имела соответствующую цену, но для среднестатистического потребителя она казалась слишком дорогой. В качестве дополнительного проекта был разработан Macintosh, который должен был стать реализацией идеи нового поколения компьютеров для «людей с улицы» и стоить около 500 долларов. Проектом занялся Стив Джобс, и под его руководством «железо» стало более продвинутым, ПО получило вместо текстового интерфейса GUI, а цена взлетела почти до 2500 долларов. Хотя оборудование, получаемое за эту цену, немного разочаровывало, например, ему не хватало графических ускорителей и звуковых возможностей, имевшихся у других машин, зато цену оправдывало ПО. Первым Macintosh был Mac 128K, и его успех подтолкнул к созданию более продвинутых моделей этого компактного Mac, в частности, Macintosh 512K, Macintosh Plus и серии Macintosh SE.

Хотя разработка Macintosh происходила примерно в 1984 году, задолго до того, как я начал разбираться в компьютерах, я питаю к компактным Macintosh какую-то слабость: первым компьютером, купленным моими родителями, был Macintosh Plus. Позже он был дополнен жёстким диском SCSI на 20 МБ, и на этой машине я писал свои первые программы на Basic. Когда ещё жил в Нидерландах, я купил сломанную машину SE/30 и превратил её в Linux-сервер, который тем не менее способен был запускать ПО для Mac. Однако я оставил эту машину в Нидерландах, а здесь, в Шанхае, у меня больше нет классического «железа» Apple.

Хоть и очевидно, что в повседневной жизни Mac Plus мне больше не понадобится, мне понравилась идея иметь его под рукой на случай приступов ностальгии.

Удержать пользователя в мобильном приложении – это целая наука. Ее основы в нашей статье на VC.ru описал автор курса Growth Hacking: аналитика мобильного приложения Максим Годзи, руководитель подразделения Машинного обучения в App in the Air. Максим рассказывает о разработанных в компании инструментах на примере работы по анализу и оптимизации мобильного приложения. Такой системный подход к совершенствованию продукта, разработанный в App in the Air, называют Retentioneering. Использовать эти инструменты вы можете и в своем продукте: часть из них есть в свободном доступе на GitHub.

В конце 2018-го года в Самаре состоялся Panda-Meetup #9 Frontend. На этом мероприятии я попробовал себя в новой роли и выступил с докладом. Меня зовут Евгений Холмов. В программирование я пришёл более 10 лет назад, будучи студентом. Последние 5 лет я занимаюсь разработкой систем дистанционного обслуживания в крупнейших российских банках, из них два года на позиции руководителя. За это время я поучаствовал в создании нескольких ведущих российских enterprise-приложений, пройдя через тернии тяжелых архитектурных, интеграционных и процессных решений. Опираясь на свой опыт разработки нескольких крупных интернет-банков, я рассказал гостям митапа, какую выгоду даёт следование правилам хорошего стиля в разработке. Озвученные цифры впечатлили слушателей. Участники встречи меня буквально завалили вопросами. Не исключено, что и среди читателей Хабра эта тема найдёт живой отклик.

Ранее мы уже рассказывали о том, что по мере роста нагрузки постепенно ушли от использования Python в бэкенде критичных сервисов на продакшене, заменив его на Go. А сегодня я, Денис Гирько, тимлид команды разработки Madmin, хочу поделиться деталями: как и почему это происходило на примере одного из важнейших для нашего бизнеса сервисов — расчета цены с учетом скидок по купонам.