Привет, Хабр! В апреле мы официально выложили в открытый доступ лучшие видеозаписи с DotNext 2017 Moscow. В результате получился плейлист из 25 докладов. Просто напомню здесь об этом магическом плейлисте.

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

Формально, чем ниже по списку, тем выше рейтинг. Но тут есть важное уточнение: все доклады из первой десятки имеют очень-очень высокий рейтинг, и их точное положение сильно зависит от нюансов подсчета. Например, если использовать soft quorum, то кейноут Андрея Акиньшина про перформанс-тестирование обгонит доклад Саши Гольдштейна про отладку и профилирование на Linux. Иначе говоря, смотрите всё :-)

Под катом будет оглавление для удобной навигации по содержимому поста.

Привет, Хабр! Меня зовут Михаил Голованов, в Сбертехе я занимаюсь технической архитектурой и перспективными разработками. У нас, как и у любого современного банка, есть множество систем, которые поддерживают разные стороны работы банка: вклады, счета, зачисление денег, кредитование, финансовые рынки, акции и т.д. Всякий раз, когда появляется какая-то новая система, мы начинаем следующий уровень увлекательной игры под названием «Интеграция». И каждый следующий уровень сложнее предыдущего — ведь систем нужно охватывать все больше и больше. Этот пост — то, что в геймерских кругах именуется walkthrough: сначала мы пробежимся по локальным сетям и затем через очереди сообщений перейдем к масштабному этапу потоковых вычислений посредством Apache Kafka в широко распределенных сетях.  

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

Код быстро превращается в нечитаемое месиво, в котором не разобрать, где логика, где текст, где форматирование. Это ужасно! Когда мы пишем GUI, у нас в распоряжении все прелести современной разработки: паттерны MV*, байндинги и прочие крутые штуки. После работы с GUI написание консольных приложений сродни возвращению в каменный век.

CsConsoleFormat спешит на помощь!

Еще 4 года назад использование контейнеров в production было экзотикой, но сейчас это уже норма как для маленьких компаний, так и для больших корпораций. Давайте попробуем посмотреть на всю эту историю с devops/контейнерами/микросервисами ретроспективно, взглянуть еще раз свежим взглядом на то, какие задачи мы изначально пытались решить, какие решения у нас есть сейчас и чего не хватает для полного счастья?

Я буду в большей степени рассуждать про production окружение, так как основную массу нерешенных проблем я вижу именно там.

Всем привет! Меня зовут Юрий Лилеков, я работаю в Server Team Badoo. На днях мне попалась довольно интересная статья о новой семантике exactly-once в Apache Kafka, которую я с радостью для вас перевёл.

Вот к такому можно стремиться

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

— Почему у нас всё упало?
— Потому что вы откатали это на стенде, всё протестировали, а потом развернули на проде. Вот у вас настройка, которая не попала в инструкции, и жила только в голове старого админа.

Или:

— Почему не запускается по всей стране?
— Потому что у вас несколько десятков разных региональных инсталляций, каждая делалась руками, и на каждой разные конфиги. И ещё в паре случаев инженер ошибся.
— Поправите до завтра? Очень нужно! Только доступ удалённо мы вам не дадим.
— ..! Конечно, у нас есть команда высокооплачиваемых спецов, обожающих ездить на Дальний Восток. Нет проблем.

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

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

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

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

Технология «блокчейн» прекрасна и перспективна. Всё в ней было бы совсем замечательно, если бы несколько досадных нюансов:

1. Очень долго. Время добавления транзакции в цепочку биткоина, например, оценивается от минуты до получаса. В Ethereum добавляется быстрее, но в любом случае довести время до долей секунды невозможно. Нечего и думать о том, чтобы сделать добавление данных в блокчейн частью OLTP-транзакции.
2. Майнинг — это очень ресурсоёмко. Он, собственно, и нужен для того, чтобы добавить в архитектуру вычислительную сложность.
3. Очень дорого. Следствие ресурсоёмкости.
4. Технология отвратительно масштабируется как вверх, так и вниз. Если нужно построить систему, которая будет регистрировать миллиарды записей ежедневно, блокчейн не годится. Также блокчейн будет стрельбой из пушки по воробьям, если его пытаться приспособить для надёжного логирования какой-нибудь мелкой ерунды.

Хотелось бы иметь технологию, которая бы одновременно и реестры позволяла вести непрошибаемо надёжным образом, и была бы как-то попроще и подешевле.

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

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

Данная статья написана в стиле от новичка-новичкам, поэтому опытные читатели вряд ли, почерпнут для себя, что-то новое и если есть желание решить задачу классификации источников света по спектрам, то им есть смысл сразу взять данные из GitHub

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

Мы пройдем с вами путь от попытки понять где можно применить даже небольшие знания по ML (которые можно получить из базовых книг и курсов), до решения непосредственно самой задачи классификации и мыслей о том «что теперь со всем этим делать?!»

Милости прошу всех под кат.

О чем пойдет речь

Здесь периодически появляются посты, в которых авторы делятся своими подходами по использованию docker. Ну что же, вот вам еще один. Ниже я расскажу о нашем опыте использования docker-окружения, о неудобствах, с которыми мы столкнулись, как мы с ними боролись, и во что это вылилось. А также поделюсь небольшим, но столь полезным для нас, инструментом.

Мы всё-таки смогли дойти до третьей части и добрались до самого интересного — организации асинхронных вычислений.

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

Теперь посмотрим, как можно управлять потоком исполнения (control flow) в случае обработки асинхронных задач.

• Параллелизм (часть 1)
  
  
  • Потоки: scheduling, сон
  • Синхронизация: Spinlock, семафоры, барьеры памяти
  • Атомарность: TAS, CAS
  
  
• Кооперативность (часть 2)
  
  
  • Корутины (coroutines)
  • Акторы
  
  
• Асинхронность (часть 3, текущая)
  
  
  • Event loop
    • select
  • Callbacks
  • Async Monad
  • Промисы (promises, обещания)
  • async/await — промисы + корутины
  
  

Архитектура – это про будущее…
— именно на этой мысли мы остановились в конце 1й части статьи. Продолжаем.

Что такое хорошая архитектура?

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

Задачи бывают разные. Стандартные и специфичные. Локальные и масштабные.
Но в любом случае, как вряд ли кто-то захочет дом “на один сезон” (хотя такое тоже возможно, но это как раз из разряда “специфичного”, и едва ли для подобного строительства будут прибегать к услугам архитектора) — так и сомнительно, чтобы кто-то хотел получить в итоге систему без перспективы ее развития в будущем.

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

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

В этой статье речь пойдет об архитектуре хранилищ данных. Чем руководствоваться при ее построении, какие подходы работают – и почему.

«Сказка ложь – да в ней намек…»

Посадил дед… хранилище. И выросло хранилище большое-пребольшое. Вот только толком не знал, как оно устроено. И затеял дед ревью. Позвал дед бабку, внучку, кота и мышку на семейный совет. И молвит такую тему: «Выросло у нас хранилище. Данные со всех систем стекаются, таблиц видимо-невидимо. Пользователи отчеты свои стряпают. Вроде бы все хорошо – жить да жить. Да только одна печаль – никто не знает, как оно устроено. Дисков требует видимо-невидимо – не напасешься! А тут еще пользователи ко мне ходить повадились с жалобами разными: то отчет зависает, то данные устаревшие. А то и совсем беда – приходим мы с отчетами к царю-батюшке, а цифры-то между собой не сходятся. Не ровен час – разгневается царь – не сносить тогда головы – ни мне, ни вам. Вот решил я вас собрать и посоветоваться: что делать-то будем?».

    Добрый день, коллеги. В своей статье я хочу осветить проблему, с который может столкнуться разработчик, желающий написать свой инсталлятор с помощью технологии WiX.
Думаю, что многие программисты сталкивались с задачей написания инсталлятора для своего программного продукта. Вот и меня постигла та же участь. Решено было использовать WiX. Необходимо было сделать автоматическую сборку инсталлятора на build server. Проекты, из которых берутся файлы для инсталляции, могут меняться, и поэтому нельзя жестко указать список файлов, которые необходимо добавить в инсталлятор.

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

Как правило, язык C++ используют там, где требуется высокая скорость работы. Но на C++ без особых усилий можно получить код, работающий медленнее какого-нибудь Python/Ruby. Именно подобным кодом оперируют многочисленные сравнения Any-Lang vs C++.

Вообще, оптимизация бывает трех типов:

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

Специально заниматься оптимизацией готового кода следует только после того, как проект закончен и используется. Как правило, оптимизация потребуется только в небольшой части проекта. Поэтому сначала нужно найти места в коде, которые съедают большую часть процессорного времени. Ведь какой смысл ускорять код, пусть даже на 500%, если он отнимает только 1% машинного времени? И следует помнить, что, как правило, гораздо больший выигрыш в скорости дает оптимизация самих алгоритмов, а не кода. Именно про данный ее вид говорят: «преждевременная оптимизация — зло» (с).

Второй тип оптимизации — это изначальное проектирование кода с учетом требований к производительности. Такое проектирование не является ранней оптимизацией.

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

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

В этой статье мы рассмотрим ряд примеров иллюстрирующих различные особенности работы кэшей и их влияние на производительность. Примеры будут на C#, выбор языка и платформы не так сильно влияет на оценку производительности и конечные выводы. Естественно, в разумных пределах, если вы выберите язык, в котором чтение значения из массива равносильно обращению к хеш-таблице, никаких результатов пригодных к интерпретации вы не получите. Курсивом идут примечания переводчика.

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

«Хмм… правдивого архитектора… А что, такие бывают? – спросите вы и подумаете. — Врет, поди! Сейчас будет нам рассказывать очередную концепцию „бла-бла-бла.2.0“. Знаем, плавали, видали мы „витающих в небесах архитекторов“ и их умозрительные конструкции».
И будете правы: нормальный «пацанский» архитектор — человек очень занятой, и времени писать статьи у него, как правило, нет… Но! Бывает, что настает момент – и желание человека поделиться опытом, рассказать о своих удачах и сложностях миру настолько высоко, что и время находится, и присущий нашему брату-технарю страх публичных высказываний отступает. К тому же коллеги по цеху давно призывали меня начать подобную деятельность.

Стартовать я решила с темы несколько общего характера – ИТ-архитектуры в целом. Почему бы сразу не перейти непосредственно к деталям, которые наиболее занимают читателей технических блогов?
Ответ прост: уж больно много вопросов, трактовок и кривотолков возникают вокруг работы и задач архитекторов. И чтобы двигаться дальше, нужно выстроить некую «общую систему координат» — некую отправную точку.
За время моей работы сложилось некое «видение» происходящего, которым хотелось бы поделиться и обсудить с коллегами.

Итак, попробуем поискать ответы на следующие вопросы.

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

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

Уже несколько месяцев использую docker для структуризации процесса разработки/доставки веб-проектов. Предлагаю читателям «Хабрахабра» перевод вводной статьи о docker — «Understanding docker».

Что такое докер?

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

Пришло время разложить информацию о контейнерах «по полочкам» в голове в статье и формализовать подход к построению образов Docker. Еще при первом знакомстве с Docker все запущенные контейнеры напоминали костыли и велосипеды избыточные наборы файлов, библиотек, поверх которых запускались процессы. Что бы такого не было, хотелось объединить дублирующие слои в один, но в то же время предоставить каждому исполняемому файлу свой контейнер. Так постепенно начал формироваться свой подход к построению образов. Но чем же плохи «костыли и велосипеды»? Ответ один – они могут появиться в конечном продукте.