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

Эта статья о новых оптимизациях компилятора, которые готовятся к релизу Go 1.9, но я бы хотел начать разговор с логирования.

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

Принято считать, что разработчики смартфонов и прочей мобильной электроники (планшетов, ноутбуков, смарт-часов и пр.) наживаются на бедных потребителях. Видели новости с заголовком вроде «айфон нам продают за 500 баксов, а цена его комплектующих всего 250»? Я как раз об этом. Однако Apple со своими смартфонами – это ещё относительно честный производитель, который делает минимальную наценку. Неужели бывает хуже? Бывает. Пальму первенства в области развода покупателей удерживают – тарам-пам-там – производители наушников!

Всё дело в том, что производство наушников – бизнес крайне высокомаржинальный. Если не считать профессиональные аудиофильские модели ценой в пару тысяч долларов, где действительно применяются уникальные компоненты (вроде моделей STAX или Astell&Kern), подход к созданию «ушей» у всех производителей примерно такой. Берём старую начинку, слегка подкручиваем звучание (ну чтобы новая модель хотя бы немного отличалась от старой), чуток изменяем дизайн (с той же целью), продаём. Всё! Учитывая, что каких-либо реально дорогостоящих компонентов в массовых серийно выпускающихся наушниках нет, а на разработку «c нуля» тратиться не приходится, стоимость производства (cost of materials) одного флагманского экземпляра практически любого бренда редко превышает 50, ну максимум 70 долларов. Откуда же появляются модели за 500 баксов и дороже? Оттуда и появляются – потребителю впаривают не столько технологии и звучание, сколько бренд. Давайте-ка разберёмся в ситуации поглубже и параллельно обозреем линейку «антипафосных» наушников не так давно появившегося на российском рынке бренда Bluedio. Наушники этого производителя ориентированы как раз на тех, кто не желает выбрасывать даже лишний рубль (пусть даже может себе это позволить) и при этом хочет получить реально клёвые, хорошо звучащие «уши». Без наценки за «пафос».

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

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

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

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

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

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

Привет, Geektimes! Этот пост я пишу в соавторстве с Лобановым Виталием (hdablin) по следам его публикации «Когнитивные стимуляторы и другая психофарма: можно ли стать умнее», посвящённой фармакологическим аспектам проблемы «разгона» мышления. В нём я хочу рассказать о патопсихологии, о том, как проверяют людей на адекватность в психиатрической больнице, о том, какими бывают нарушения мышления, как их выявляют, о том, где проходит разница между гиком и психически больным человеком, о том, можно ли диагностировать у себя психическое заболевание самостоятельно, и о многом другом, имеющем отношение к теме.

Немного о себе: меня зовут Кристина, я медицинский психолог (именно медицинский, окончивший медицинский же университет по специальности «Клиническая психология», это важно), три года проработала в психиатрической больнице, сейчас ушла в частную практику, но осталась в психиатрии как в индустрии. Имею специализацию в нейропсихологии. За время работы мне приходилось сталкиваться с самыми разными категориями пациентов — шизофрениками, БАРщиками, депрессивными, органиками; часть из них обращалась добровольно, часть была госпитализирована в остром состоянии, часть вообще была «принудчиками» (это люди, совершившие преступление, но направленные судом не в тюрьму, а к нам в психушку на принудительное лечение).

tl;dr: В статье рассказано о том, как, зачем и почему проводится диагностика нарушений работы психики.

Знаете такую компанию — Facebook? Да-да, ту самую, у сайта которой 1,6 миллиардов пользователей. И если взять все посты-поздравления с днем рождения, ваши позорные детские фотографии (у меня они такие), того дальнего родственника, лайкающего каждый ваш статус, — и вот вам множество данных для анализа.

С точки зрения анализа изображений Facebook весьма далеко продвинулся со сверточными нейронными сетями (Convolutional Neural Network, CNN). В августе подразделение Facebook по исследованиям в области искусственного интеллекта (Facebook AI Research, сокращенно FAIR) опубликовала блог-пост об алгоритмах компьютерного зрения, которые лежат в основе некоторых их алгоритмов сегментации изображений. В этом посте мы кратко изложим и разъясним три статьи, на которые ссылается этот блог.

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

В последнее время много разговоров идёт о «фальшивых новостях», которые публикуются в мусорных СМИ и раскручиваются ботами в соцсетях. Но не меньшей проблемой являются и фальшивые научные исследования, которым удаётся пролезть в научные журналы. Попав на страницы такого издания, автор может ссылаться на «официально опубликованную» научную работу и получить соответствующие бенефиты, которые положены за публикацию статей в научной прессе. Если эти научные статьи будут ссылаться друг на друга, то автор даже заработает неплохой индекс цитирования. Он становится «авторитетным учёным», имеет право читать доклады на конференциях, выступать экспертом в СМИ. Даже может подняться до должности министра РФ. Но этот авторитет куплен за деньги.

Содержание

1. Введение в Computer Science
2. Структуры данных и Алгоритмы
3. Системное программирование
4. Распределенные системы
5. Базы данных
6. Объектно-ориентированный дизайн и разработка софта
7. Искусственный интеллект
8. Машинное обучение
9. Веб-разработка и интернет-технологии
10. Concurrency
11. Компьютерные сети
12. Разработка мобильных приложений
13. Математика для программистов
14. Теория информатики и языки программирования
15. Архитектура компьютера
16. Безопасность
17. Компьютерная графика
18. Работа с изображениями и компьютерное зрение
19. Интерфейс Человек-Компьютер
20. Вычислительная биология
21. Прочее

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


Под катом — расшифровка лекции и часть слайдов Сергея.

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

Используемые компоненты:

• REACT-CPP;
• AMQP-CPP;
• RapidJSON;
• LevelDB;
• Easylogging++.

Для примера буду делать микросервис для выдачи рейтинга игроков. От ядра системы в микросервис приходят следующие сообщения:

• player_registered(id,name);
• player_renamed(id,name);
• player_won(id, points).

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

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

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

Существуют три вида почтовых услуг, которые могут пригодиться блоггеру или владельцу сайта:

1. Транзакционные. Нужны для отправки писем о событиях, транзакциях, уведомлений о заказе, регистрационных данных и т.д.;
   
   
2. Маркетинговые. Нужны при осуществлении новостной рассылки, проведении акций, обновлениях в блоге и т.д.;
   
   
3. Хостинг почты. Нужен для получения и отправки электронных писем (потребуется, если вы пользуетесь виртуальными серверами, например, DigitalOcean, Linode и т.п.).

Вот уже около трех лет я использую в работе принципы Spec By Example, Domain Driven Design и CQRS. За это время накопился опыт практического применения этих практик на платформе .NET. В статье я хочу поделиться нашим опытом и выводами, которые могут быть полезными командам, желающим использовать эти подходы в разработке.

Это будет длиннопост. Я давно хотел написать этот обзор, но sim0nsays меня опередил, и я решил выждать момент, например как появятся результаты ImageNet’а. Вот момент настал, но имаджнет не преподнес никаких сюрпризов, кроме того, что на первом месте по классификации находятся китайские эфэсбэшники. Их модель в лучших традициях кэгла является ансамблем нескольких моделей (Inception, ResNet, Inception ResNet) и обгоняет победителей прошлого всего на полпроцента (кстати, публикации еще нет, и есть мизерный шанс, что там реально что-то новое). Кстати, как видите из результатов имаджнета, что-то пошло не так с добавлением слоев, о чем свидетельствует рост в ширину архитектуры итоговой модели. Может, из нейросетей уже выжали все что можно? Или NVidia слишком задрала цены на GPU и тем самым тормозит развитие ИИ? Зима близко? В общем, на эти вопросы я тут не отвечу. Зато под катом вас ждет много картинок, слоев и танцев с бубном. Подразумевается, что вы уже знакомы с алгоритмом обратного распространения ошибки и понимаете, как работают основные строительные блоки сверточных нейронных сетей: свертки и пулинг.

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

Если вы относитесь к числу таких разработчиков, вам стоит обратить внимание на разработку гибридных приложений, так как вы сможете работать с языком, который вы уже знаете, будь то: HTML5 или JavaScript. Более того, вы можете использовать популярные фреймворки, например: Twitter Bootstrap или jQuery Mobile для разработки своих приложений.

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

Почему Telerik AppBuilder?

«К сожалению, мы не выбираем себе смерть, но мы можем встретить её достойно, чтобы нас запомнили как мужчин.»
— к/ф «Гладиатор»



Питер Хинченс (Pieter Hintjens) — бельгийский разработчик, писатель. Занимал должность CEO и chief software designer для iMatix, компании, производящей free software, такие как библиотека ZeroMQ (библиотека берет на себя часть забот по буферизации данных, обслуживанию очередей, установлению и восстановлению соединений, и прочие вещи), OpenAMQ, Libero, GSL code generator, и веб-сервиса Xitami.

• Автор более 30 протоколов и распределённых систем.
• Основатель проекта Edgenet по созданию полностью безопасной, анонимной глобальной P2P-сети.
• Президент ассоциации Foundation for a Free Information Infrastructure (FFII), которая воевала с патентным правом.
• CEO сервиса по созданию собственных вики-проектов Wikidot.
• Он был активистом open standards, и основателем Digital Standards Organization.
• Питер в 2007 был назван одним из «50 самых влиятельных людей в области Интеллектуальная собственность».

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

Так что я хочу написать одну последнюю модель, последний протокол, который посвящён тому, как уйти из жизни, имея в запасе некоторые знания и время. В этот раз я не буду оформлять RFC.

Моим детям 12, 9 и 5 лет. Они вырастут с моим ДНК, с моими бесконечными выступлениями на Youtube и книгами.

Под катом немного наследия, которое оставил Питер.

Иллюстрация @alvaro_sanchez

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

Естественно, в реальности все оказалось совсем наоборот. Когда смотришь назад, на произошедшее, то зрение оказывается ближе к 100%, чем когда смотришь с надеждой в будущее.

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

Данная статья в некотором роды выжимка того, что Вы могли бы узнать просмотрев разные видео ролики господина Шипилева, Елизарова, Смирнова. Собственно мы даже собрали для Вас плейлист если Вы захотите пойти «the hard way». В статье я лишь попробую Вам передать некоторые основные мысли/идеи, которые при желании Вы сможете намного более глубоко изучить в первоисточниках.

Итак, давайте теперь перейдем к собственно сабжу. Еще лет пять назад можно было не сильно «парясь» выдавать на-гора однопоточные программы, которые с трудом запускались на топовом железе и знать, что через год-два этот кусочек “программки” (простите за аллегорию) начнет работать нормально. Сегодня подобный «бесплатный обед» закончился.


На картинке четко видно, что количество транзисторов все еще растет, но с точки зрения частот мы практически достигли потолка. «Кривизну» рук разработчиков уже трудно компенсировать тем, что через год железо станет работать в два раза быстрее. Хотя не все так печально, процессоры пока еще растут, только с точки зрения количество ядер. Как следствие, для того чтобы «программка», написанная криворуким орком, смогла хоть как-то нормально работать на новом железе, нужно чтобы она нормально работала в многопроцессорной среде. А производительность была напрямую связана с количеством ядер на железе. Вот собственно от том, а что же такое «нормально работала многопроцессорной среде» мы и поговорим далее.