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

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

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

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Эта статья для вас, если вы:

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

Моя статья не для вас, если вы:

• хорошо умеете готовить свою любимую БД, оптимизировать индексы, настраивать и всякое такое;
• имеете в штате хорошего специалист, который сможет аргументировано выбрать нужный вашему проекту вариант. специалист должен быть действительно хорошим, а не «экспертом на диване»;
• обслуживаете проект с так называемым «big data», то есть у вас огромные базы, десятки или сотни серверов в кластере и всякое такое — ну у вас как бы должен быть в штате один или несколько специалистов.

О чем пойдет речь в статье?

Я разберу в своей статьи некоторые типичные и не очень варианты выбора баз данных, а если быть более точным — подходы к выбору. Когда следует остановится на том, что используют большинство, а когда можно и задуматься над новым и неизведанным. Я опишу СУБД MySQL, PostgreSQL, MongoDB, Redis, CouchDB/PouchDB и упомяну о Aerospike с Tarantool, парочку других — но в некоторых моментах конкретный выбор не настолько принципиален. Надо понимать, что лучше изначально правильно спроектировать структуру данных, чем выбрать СУБД, а потом уже пытаться придумывать, что в ней собственно хранить.
Итак, начнем.

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

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

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

В блоге на Хабре мы много пишем о построении ИТ-инфраструктуры — например, раскрываем вопросы выбора дата-центров в России и США. Сейчас в рамках King Servers работают сотни физических и тысячи виртуальных серверов. Сегодня наши инженеры делятся советами по управлению инфраструктурой таких размеров.

Привет, Хабр! Меня зовут Виталий Котов, я работаю в Badoo, в отделе QA. Большую часть времени занимаюсь автоматизацией тестирования. Недавно я столкнулся с задачей максимально быстро развернуть Selenium-тесты для одного из наших проектов. Условие было простое: код должен лежать в отдельном репозитории и не использовать наработки предыдущих автотестов. Ах, да, и нужно было обойтись без CI. При этом тесты должны были запускаться сразу после изменения кода проекта. Отчёт должен был приходить на почту.

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

Поехали!

С того момента как мы начали вести корп. блог на Хабре, на демо и при обращениях в поддержку нас стали чаще сравнивать с оркестраторами. И если раньше были вопросы о том, в чем отличия D2C от Heroku, Clou66 и тому подобных сервисов, то теперь, видимо, нас стали рассматривать как альтернативное решение для оркестрации.

Чтож, попробую поправить ситуацию и провести сравнение с несколькими популярными решениями, о которых слышно чаще: Docker swarm, Kubernetes и Rancher. А чтобы зайти не «с конца», кратко дам по маленькому обзору на каждую из них.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Please Stop Using Local Storage" автора Randall Degges.

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

Кент С. Доддс, автор материала, перевод которого мы публикуем сегодня, говорит, что недавно группа программистов, с которыми он должен был провести тренинг по React, заинтересовалась шаблоном «render props», который ещё называют шаблоном «функция как потомок» (в разных публикациях его упоминают как «children as a function» или «function as child»). Документация по React определяет «render prop» как простую технику передачи кода между компонентами React с использованием свойства, значением которого является функция. Компонент, использующий render prop, принимает функцию, которая возвращает элемент React. Этот компонент вызывает данную функцию вместо реализации собственной логики рендеринга. Кент рекомендует тем, кто не знаком с шаблоном render prop, почитать этот материал и посмотреть это видео, а потом уже читать дальше.

Хочу рассказать про цикл работы над дизайном готового продукта, опираясь на собственный опыт работы в beepcar.ru. Это сервис который одним помогает попасть из пункта А в пункт Б, другим — сэкономить на бензине, а иногда — даже заработать. Короче, сводит водителей
и пассажиров. У нас есть веб-версия и два приложения — для Android и iOS.

Сам цикл поделён на три модуля: Before Design, Design и After Design. Ниже я расскажу про каждый подробно.

Код этого поста, как и сам пост, выложен на github.

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

Часть 1: Парсинг

Спецификация

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

• . — соответствие любому символу
• | — соответствие abc или cde
• + — соответствие одному или более предыдущего паттерна
• * — соответствие 0 или более предыдущего паттерна
• ( и ) — для группировки

Хотя набор опций невелик, с его помощью можно создать интересные regex-ы, например, m (t|n| ) | b позволяющий найти субтитры к Star Wars без субтитров к Star Trek, или (..)* для нахождения множества всех строк чётной длины.

План атаки

Мы будем анализировать регулярные выражения в три этапа:

1. Парсинг (синтаксический анализ) регулярного выражения в синтаксическое дерево
2. Преобразование синтаксического дерева в конечный автомат
3. Анализ конечного автомата для нашей строки

Для анализа регулярных выражений (подробнее об этом ниже) мы будем использовать конечный автомат под названием NFA. На высоком уровне NFA будет представлять наш regex. При получении входных данных мы будем перемещаться в NFA от состояния к состоянию. Если мы придём в точку, из которой невозможно совершить допустимого перехода, то регулярное выражение не соответствует строке.

Сегодня мы публикуем перевод материала Нейта Ванга, создателя Rekit. Здесь он рассказывает о новом стабильном релизе системы, Rekit Studio. Это — полноценная IDE для разработки приложений, созданных с использованием технологий React, Redux и React Router. Он говорит, что его команда создаёт с помощью Rekit сложные веб-приложения уже больше года.

Предыдущая версия Rekit Studio называлась Rekit Portal. Она не поддерживала возможностей по редактированию кода. Теперь, благодаря редактору Monaco Editor, того, который используется в VS Code, и благодаря замечательному средству для форматирования кода prettier, Rekit Studio позволяет удобно работать с кодом. Именно поэтому в названии системы появилось слово «studio».

Rekit Studio

Недавно я познакомился с замечательной серией статей "Thinking in Ramda", которые проясняют на простых и ясных примерах способы написания кода в функциональном стиле с использованием библиотеки Ramda. Эти статьи показались мне настолько прекрасными, что я не смог удержаться от того, чтобы не перевести их на русский язык. Надеюсь, что в этом будет польза для многих людей :) Давайте начнём перевод с первой вступительной статьи.

1. Первые шаги
2. Сочетаем функции
3. Частичное применение (каррирование)
4. Декларативное программирование
5. Бесточечная нотация
6. Неизменяемость и объекты
7. Неизменяемость и массивы
8. Линзы
9. Заключение

Данный пост — это начало серии статей «Мышление в стиле Ramda» о функциональном программировании.

Я буду использовать библиотеку Ramda в этих статьях, хотя многие из обсуждаемых идей применимы также к множеству других библиотек, таких как Underscore и Lodash, а также к другим языкам программирования.

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

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

class Observable {
  listeners = new Set();
  subscribe(listener){
    this.listeners.add(listener)
  }
  unsubscribe(listener){
    this.listeners.delete(listener)
  }
  notify(){
    for(const listener of this.listeners){
       listener();
    }
  }
}

В redux-е этот паттерн применяется без всяких изменений  — пакет "react-redux" предоставляет функцию connect которая оборачивает компонент и при вызове componentDidMount вызовет subscribe() метод у Observable, при вызове componentWillUnmount()  вызовет  unsubscribе() а dispatch() просто вызовет метод trigger() который в цикле вызовет всех слушателей где каждый в свою очередь вызовет mapStateToProps() и потом в зависимости от того изменилось ли значение  —  вызовет setState() на самом компоненте. Все очень просто, но платой за такую простоту реализации является необходимость работать с состоянием иммутабельно и нормализировать данные а при изменении отдельного объекта или даже одного свойства оповещать абсолютно всех подписчиков-компонентов даже если они никак не зависят от той измененной части состояния и при этом в компоненте-подписчике необходимо явно указывать от каких частей стора он зависит внутри mapStateToProps()

Самые известные на мировом рынке объектные хранилища — это Amazon S3 (Simple Storage Service), Google Cloud Storage и Microsoft Blobs Storage. Они надежны, доступны через интернет и масштабируются до сотен петабайт. Наиболее популярный способ доступа к объектному хранилищу — S3 RESTful API от компании Amazon. Есть и альтернатива, OpenStack Swift — поддерживает оба API и даже имеет собственное (как у Microsoft или Google, например). Дополнительно предоставляется доступ по другим файловым и блочным протоколам вроде WebDAV, NFS и FTP, но в контексте этой статьи мы тестируем только доступ по протоколу HTTPS через разнообразные API.

Для сравнения возьмем отечественные публичные объектные хранилища. Их не так много, и мы рассмотрим наиболее заметных игроков российского рынка: Mail.Ru Cloud Solutions, servers.ru, Selectel, Техносерв и Ростелеком.

О производительности react

React не зря считается очень производительным фреймворком. Он позволяет создавать быстрые динамические страницы с большим количеством элементов.

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

React 16.3-alpha опубликован в npm, его уже можно загружать и использовать. Сегодня мы поговорим о самых крупных и интересных нововведениях этого релиза. В частности, речь пойдёт об API Context, о новых методах жизненного цикла, о статическом методе getDerivedStateFromProps, о компонентах StrictMode и AsyncMode, а также об обновлённых инструментах разработчика React.

Приветствую вас, хабровчане, решил поделиться с сообществом переводом довольно часто (по личным наблюдениям) упоминаемого поста SOLID Go Design из блога Dave Cheney, который выполнял для собственных нужд, но кто-то говорил, что нужно делиться. Возможно для кого-то это окажется полезным.

SOLID дизайн Go

Этот пост на основе текста из основного доклада GolangUK прошедшего 18-ого Августа 2016.
Запись выступления доступна в YouTube.

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

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

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

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

const ageAbove18 = (person) => person.age > 18;
const isFemale = (person) => person.gender === ‘female’;
const livesInTheNetherlands = (person) => person.country === ‘NL’;
const pickFullName = (person) => person.fullName;
const output = bigCollectionOfData
  .filter(livesInTheNetherlands)
  .filter(isFemale)
  .filter(ageAbove18)
  .map(pickFullName);

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

Конечно, отфильтрованные коллекции будут несколько сокращены, но это, все еще довольно затратно.

Однако главный момент заключается в том, что map и filter могут быть определены с помощью reduce. Давайте попытаемся реализовать приведенный выше код в формате сокращений.