Как-то раз моему коллеге в беклог упала задача «хотим организовать взаимодействие с внутренним REST-api так, чтобы любое изменение контракта сразу приводило к ошибке компиляции». Что может быть проще? – подумал я, однако работа с получившимся кактусом вынудила заняться многочасовым курениям документации, спуску от привычных концепций оверинжинеринга «налепим побольше интерфейсов, добавим максимум косвенности, и приправим всё это DI» до переезда на .Net Core, ручной кодогенерации промежуточного ассемблера и изучения нового компилятора C#. Лично я для себя открыл много интересного как в рантайме, так и в структуре самого компилятора. Думаю, некоторые вещи хабровчане уже знают, а некоторые станут полезной пищей для размышления.

Хотите узнать о том, что такое React, но вам всё никак не выпадает шанс изучить его? Или, может быть, вы уже пробовали освоить React, но не смогли толком понять? А может, вы разобрались с основами, но хотите привести в порядок знания? Эта статья написана специально для тех, кто положительно ответил хотя бы на один из этих вопросов. Сегодня мы создадим простой музыкальный проигрыватель, раскрывая основные концепции React по мере продвижения к цели.

Разобравшись с этим материалом, вы освоите следующее:

• Компоненты React.
  
• Рендеринг ReactDOM.
  
• Классы компонентов и функциональных компоненты.
  
• JSX.
  
• Состояние (state).
  
• Обработка событий.
  
• Асинхронный метод setState.
  
• Свойства (props).
  
• Ссылки (refs).
  

Это — практически всё, что нужно знать для того, чтобы создавать и поддерживать React-приложения.

Нередко рассказы о том, как веб-разработчики заботятся о своих приложениях, начинаются с процесса визуализации сайта, опускаются на уровень DOM и останавливаются на утверждениях типа: «И это быстро потому, что используется ускорение». Мартин Сплитт рассказывает о производительности снизу вверх: он начинает с пикселя и поднимается уровень за уровнем, заканчивая компоновкой страницы.


В основе статьи – выступление Мартина на JavaScript-конференции HolyJS 2017 в Питере, где он рассказывает о том, как происходит визуализация в браузерах и что нужно делать для того, чтобы ваши сайты «летали».

A/Б-тестирование на сервисах Яндекса проводится постоянно. «Раскатить на такую-то долю аудитории» и посмотреть на реакцию людей — настолько стандартная практика, что ни у кого в команде не возникает вопроса, зачем это нужно. А чтобы не было проблем с самим тестированием, у нас есть специальная инфраструктура для экспериментов. Подробности рассказывают разработчики Сергей Мыц и Данил Валгушев.


Сергей:
— Я попробую упрощенно описать задачу A/Б-тестирования. Есть абстрактная система с пользователями, в нее мы вносим какие-то изменения, и нужно уметь измерять в ней пользу. Пока все просто, но слишком абстрактно. Пример. Есть веб-сервис по сравнению пары фотографий котов. Пользователь должен выбрать наиболее понравившуюся фотографию. При этом он может выбрать не только левый или правый снимок, но и «против всех». Значит, мы подобрали картинки не очень хорошо. Наша задача — обоснованно улучшать сервис, доказывая это цифрами.

или «Прекратите характеризовать хранилища данных как CP или AP»

Джеф Ходжес в своем прекрасном посте «Заметки о распределенных системах для новичков» рекомендует использовать САР теорему для критики найденных решений. Многие, похоже, восприняли этот совет слишком близко к сердцу, описывая свои системы как «СР» (согласованность данных, но без постоянной доступности при сетевой распределенности), «АР» (доступность без согласованного состояния при сетевой распределенности), или иногда «СА» (означает «Я всё ещё не читал статью Коды (Coda Hale) почти 5-летней давности»).

Я согласен со всеми пунктами статьи кроме того, что касается САР теоремы. Она слишком всё упрощает и слишком многие понимают её неверно для того, чтобы использовать для определения характеристик системы. Так что я прошу перестать ссылаться на САР теорему, говорить о ней и дать ей уже спокойно уйти на покой. Вместо неё мы должны использовать более точную терминологию для обсуждения различных компромиссов.

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

САР использует слишком узкое определение

Если вы хотите ссылаться на САР как на теорему (а не на расплывчатый концепт в маркетинговых материалах к вашей базе данных), вы должны быть точны. Математика требует точности. Доказательство сохраняется только если вы вкладывается в слова, то же самое значение, что было использовано при доказательстве. И оно опирается на очень точные определения:

Этот текст является вольным переводом замечательного поста Kaushik Sathupadi на тему распределённых систем и существующих ограничений при их создании.

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

Часть №1: Идея нового сервиса — «Позвони, напомню!»

Вчера, когда ваша супруга в очередной раз оценила тот факт, что вы вспомнили о её дне рождения и подарили шикарный подарок, в голове всплыла забавная идея. «Хм, а ведь люди вечно всё забывают». А у вас просто блестящая память! Почему бы не сделать новый сервис, который позволит полностью раскрыться вашему таланту? С каждой мыслью об этой идее вам всё больше и больше она нравится. Вы уже даже придумали рекламу, которую можно было бы напечатать в газете:

«Позвони, напомню» — Никогда не забывайте, даже если вы не помните, что забыли!
Плохо себя чувствуете из-за того, что вы что-то забыли? Не переживайте. Помощь на расстоянии одного телефонного звонка!
Если вам нужно что-то запомнить, просто позвоните и сообщите нам об этом! Допустим, позвоните нам и сообщите телефон вашего босса. Забудьте про него. Когда вам нужно будет вспомнить его, перезвоните, и мы вам обязательно напомним.
Всего 3 рубля за звонок.

Типичное обращение в ваш сервис выглядело бы вот так:

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

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

Знакомство

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



Версии браузеров, в которых работает PouchDB:

• Firefox 29+ (включая Firefox OS и Firefox для Android)
• Chrome 30+
• Safari 5+
• Internet Explorer 10+
• Opera 21+
• Android 4.0+
• iOS 7.1+
• Windows Phone 8+

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

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

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

У меня проблемы с поиском фронтенд-разработчика, в основном, по WP, Foundation, CSS, JS, на низкоуровневую позицию. Не могу понять, в чём дело. Ни у кого из кандидатов нет «базовых знаний» ничего из перечисленного. Но они могут делать сайты на React или других JS-фреймворках, или на базе WP-шаблонов. Но если я говорю, что нужно сделать простые изменения в CSS, смотрят пустыми глазами… Или какую-нибудь мелочь на чистом JS, ничего.

Нет недостатка в учебных лагерях, курсах, полно ресурсов для изучения фронтенд-разработки. Но я собеседовал кучу ребят из этих учебных лагерей и думаю, что там серьёзно недооценивают важность CSS и основ JavaScript.

Конечно, есть ограничения на то, сколько можно усвоить за 12 недель обучения. Но огромная часть проблемы в том, что наша индустрия восхищается новым, одержима самыми последними и прекрасными SPA-фреймворками, в то же время обесценив CSS и «старые» имплементации.

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

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

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

И если, обучение чтению условия задачи и ораторскому мастерству лежит за гранью предмета «Основы веб-технологий», то отрефлексировать поразившее меня многообразие идей структурирования такой простой раскладки кажется интересным.

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

Если вы не изучали JavaScript с самого начала, то осваивать его современную версию сложно. Экосистема быстро растёт и меняется, так что трудно разобраться с проблемами, для решения которых придуманы разные инструменты. Я начал программировать в 1998-м, но начал понимать JavaScript только в 2014-м. Помню, как просматривал Browserify и смотрел на его слоган:

Browserify позволяет делать require («модули») в браузере, объединяя все ваши зависимости

Я не понял ни слова из предложения и стал разбираться, как это может помочь мне как разработчику.

Цель статьи — рассказать о контексте, в котором инструменты в JavaScript развивались вплоть до 2017-го. Начнём с самого начала и будем делать сайт, как это делали бы динозавры — безо всяких инструментов, на чистом HTML и JavaScript. Постепенно станем вводить разные инструменты, поочерёдно рассматривая решаемые ими проблемы. Благодаря историческому контексту вы сможете адаптироваться к постоянно меняющемуся ландшафту JavaScript и понять его.

Сделать веб-сайт доходным можно двумя способами. Первый – привлекать больше трафика, второй – повышать конверсию, т.е. побуждать большее количество посетителей становиться покупателями. Скорее всего, вы уже слышали о том, что трафик можно просто купить – сотни интернет-ресурсов предлагают эту услугу. А не лучше ли оптимизировать конверсию? Как узнать, что именно нужно проверить, и как провести A/B тестирование?

А/В тестированию и оптимизации уровня конверсии посвящено бесчисленное количество ресурсов. Однако, очень редко на сайтах подробно разбирается весь этот процесс целиком от самого начала («Что и как тестировать?») и до конца («Как улучшить конверсию?»).

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

До недавнего времени такой взгляд на вещи действительно был недалек от истины: говорим ФП, подразумеваем Хаскель и теорию категорий. В последнее время ситуация изменилась и функциональная парадигма набирает обороты в web-разработке, не без помощи F#, Scala и React. Попробуем взглянуть на «паттерны» функционального программирования, полезные для решения повседневных задач с точки зрения ООП – парадигмы.

ООП широко распространено в разработке прикладного ПО не одно десятилетие. Все мы знакомы с SOLID и GOF. Что будет их функциональным эквивалентом?.. Функции! Функциональное программирование просто «другое» и предлагает другие решения.

От переводчика: данный текст даётся с незначительными сокращениями по причине местами излишней «разжёванности» материала. Автор абсолютно справедливо предупреждает, что отдельные темы могут показаться читателю чересчур простыми или общеизвестными. Тем не менее, лично мне этот текст помог упорядочить имеющиеся знания по анализу сложности алгоритмов. Надеюсь, что он окажется полезен и кому-то ещё.
Из-за большого объёма оригинальной статьи я разбила её на части, которых в общей сложности будет четыре.
Я (как всегда) буду крайне признательна за любые замечания в личку по улучшению качества перевода.

Опубликовано ранее:
Часть 1
Часть 2
Часть 3

Оптимальная сортировка

Поздравляю! Теперь вы знаете о том, как анализировать сложность алгоритмов, что такое асимптотическая оценка и нотация «большое-О». Вы также в курсе, как интуитивно выяснить является ли сложностью алгоритма O( 1 ), O( log( n ) ), O( n ), O( n² ) и так далее. Вы знакомы с символами o, O, ω, Ω, Θ и понятием «наихудшего случая». Если вы добрались до этого места, то моя статья уже выполнила свою задачу.

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

Данный текст будет являться новой главой для учебного пособия по защите информации кафедры радиотехники и систем управления МФТИ (ГУ). Полностью учебник доступен на github. На хабре я же планирую выкладывать новые «большие» куски, во-первых, чтобы собрать полезные комментарии и замечания, во-вторых, дать сообществу больше обзорного материала по полезным и интересным темам.

Когда у вас есть знания о том, что такое криптографически стойкая хеш-функция, понять, что такое blockchain («цепочка блоков») очень просто. Blockchain – это последовательный набор блоков (или же, в более общем случае, ориентированный граф), каждый следующий блок в котором включает в качестве хешируемой информации значение хеш-функции от предыдущего блока.

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

В таких системах есть три группы действующих лиц:

• источники событий (транзакций)
• источники блоков (фиксаторы транзакций)
• получатели (читатели) блоков и зафиксированных транзакций.

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

Основное требование к таким журналам таково:

• Невозможность модификации журнала: после добавления транзакции в журнал должно быть невозможно её оттуда удалить или изменить.

Недавно на ресурсе Medium были опубликованы две статьи от одного и того же автора, затрагивающие функциональность C# async/await.

Основными выводами были:

• рекурсивный вызов асинхронного метода в C# подвержен StackOverflowException
• goroutine'ы лучше задач (тасков) в .NET в плане производительности

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

Далее в статье я попытаюсь раскрыть суть проблемы более подробно с примерами решения.

NB: использоваться будут свежевыпущенный .NET Core 2.0 и Go 1.8.3.

В конце прошлого года два капитана Docker представили свою разработку под названием Play with Docker (PWD) — «игровую площадку для Docker». Пользователям предлагается бесплатно поработать со сборкой и запуском Docker-контейнеров прямо в веб-браузере, а также выполнить лабораторные работы для знакомства с Docker с нуля и совершенствования своих навыков.

Предлагаю общественности мой перевод статьи Dan Pupius'а об архитектура сервиса Medium и используемых технологиях. Хочу особо отметить, что статья является переводом, поэтому местоимение "я", используемое в тексте далее относится к автору оригинального текста, а не к переводчику.

Фон

Medium это сеть. Это место, где обмениваются историями и идеями, которые важны — место, где вы развиваетесь, и где люди провели 1.4 миллиарда минут — 2.6 тысячелетия.

У нас более 25 миллионов уникальных читателей в месяц, и каждую неделю публикуются десятки тысяч постов. Но мы хотим, чтобы на Medium мерилом успеха было не количество просмотров, а точки зрения. Чтобы значение имело качество идеи, а не квалификация автора. Чтобы Medium был местом, где обсуждения развивают идеи, а слова по-прежнему важны.

Я руковожу инженерной командой. Раньше я работал инженером в Google, где я работал над Google+ и Gmail, а также был одним из со-основателей проекта Closure. В прошлой жизни я гонял на сноуборде, прыгал из самолёта и жил в джунглях.

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

Предыстория

В 2014 году в компании начали редизайн проекта и в основу вёрстки мы положили свежий на тот момент Bootstrap 3.0.1. Использовали мы его не как отдельную стороннюю библиотеку, а тесно заинтегрировали с нашим собственным кодом: отредактировали переменные под наш дизайн и компилировали кастомизированный Бутстрап из LESS исходников самостоятельно. Проект оброс собственными модулями, которые использовали бутстраповские переменные и добавляли в файл с настройками свои новые переменные.

В тот момент я думал, что это правильный подход.

Месяц назад завершился очередной Чемпионат мира по программированию ACM-ICPC (результаты), на котором блестяще выступили команды Санкт-Петербурга и Екатеринбурга. Чуть хуже показали себя команды из Москвы, Перми, Новосибирска, Саратова и Самары. Прекрасный результат у команды из Томска, один лишь выход в финал которой для многих уже стал неожиданностью. Заметьте, что почти все города — миллионники, они располагают крупными вузами и интересными компаниями для работы. А теперь представьте, что вы всё детство живете в городе с населением 50 тыс. человек, затем переезжаете в соседний город с небольшим вузом с сомнительным качеством образования, и впереди маячит перспектива работать на заводе за 20 тыс. рублей в месяц. Эффективные способы сойти с этого мрачного пути есть, и один из них — ACM-ICPC. Я хочу поделиться своей историей, рассказать, как помогает опыт ACM-ICPC в повседневной работе и как эти соревнования стали моей путевкой в жизнь. Если вы студент первого-второго курса и выбираете между скорым заработком и подготовкой к турнирам по программированию, то, я надеюсь, эта статья поможет вам определиться.


Фото icpcnews icpcnews / CC