В одной из статей про шишки, которые довелось набить за 15 лет использования акторов в C++, речь зашла о том, что большое количество акторов — это, зачастую, сама по себе проблема, а отнюдь не решение. И что использование идей из SEDA-подхода может существенно упростить жизнь при разработке приложений на базе модели акторов. Однако, как показали затем вопросы в комментариях к предыдущим статьям, совмещение SEDA-подхода и модели акторов отнюдь не очевидно, поэтому есть смысл копнуть данную тему чуть глубже.

Модель акторов и ее достоинства

Пара слов о модели акторов

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

Алёна Лазарева, редактор-фрилансер, перевела для блога Нетологии статью Benjamin Martin о городах, в которых разработчиков ждут лучшие зарплаты.



Где лучше всего искать работу разработчику? В Нью-Йорке? Сан-Франциско?

Если судить по уровню заработной платы, Кремниевая долина явный победитель — среднегодовой доход для разработчика там составляет 110 554 $, согласно данным Glassdoor. Но стоимость аренды в области залива Сан-Франциско настолько высока, что не все разработчики могут позволить себе снимать там жильё.

Выбор лэптопа, подходящего для программирования – задача непростая.

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

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

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

При написании статьи я исходил из следующего:

• Вы — веб-разработчик
  
• Ваш лэптоп – ваш основной инструмент разработки
  

Вот некоторые соображения, которые, возможно, помогут вам при покупке нового лэптопа.

Переведено в Alconost

Александр Крижановский ( krizhanovsky )

По материалам доклада "Linux Kernel Extension for Databases" на HighLoad++ 2016.

Сегодня буду рассказывать про внутренности базы данных, про внутренности ОС и о том, что происходит на стыке. Когда я говорю про базу данных, я имею в виду в основном ввод/вывод, управление памятью и обработку транзакций. Это совершенно не про SQL, не про индексы, не про блокировки и т.д. Только ввод/вывод, управление памятью и транзакции.

Продолжаем развивать тему использования компьютера с ubuntu server в качестве устройства для связи мира микроконтроллеров с миром персональных компьютеров.

Ссылка на часть 1

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

Недавно столкнулся с забавной проблемой во время написании API при помощи grape. Grape тут на самом деле не при чем, статья скорее про то, как работает ActiveSupport, создавая всю ту магию, благодаря которой нам не нужны в rails постоянные require, и как на этом можно подорваться. Кому интересно, прошу под кат.

Перечисления (enumeration) по определению это — «действие упоминания некоторого количества чего-либо один за одним». В программировании, вместо упоминания, мы выбираем любое действие, которое хотим произвести, будь то простой вывод на монитор или выполнение некоторого рода выборки и/или преобразования над элементом.

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

Всем счастья и добра!

Эволюционно так получилось, что в моем личном владении оказался не маленький зоопарк различных серверов: от дешевого Supermicro до топового (на момент выпуска) HP Gen 8. Все конечно связано оптикой и прочими радостями жизни.

Но сказ не про то, как сеть класть, и даже не про то, как сервера настраивать, а про то, как правильно просто на всем этом деле docker-compose сервисы поднимать и радоваться.

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

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

А теперь я работаю с разработкой ПО, и это невыносимо скользкая тема. Ни одна концепция точно не определена. Результаты оцениваются с характеристиками «обычно» или «в целом». Сегодняшние исследования могут или не могут помочь завтрашней работе. Новые подходы часто опровергают предыдущие методы, а сами ярко горят недолгое время, а потом выходят из моды, когда всплывают их ограничения. Мы верили в структурное программирование. Затем начали верить в языки четвёртого поколения, потом в объектно-ориентированные методы, потом в экстремальное программирование, а теперь, может быть, в open source.

Галактика Андромеды

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

Клиент что-то заказал и ждёт, когда ему это привезут? День доставки заранее согласован? Значит, курьер может выезжать? Увы, нет. Рейд курьера может быть бессмыслен и бесполезен, потому что клиент… только что вышел в магазин, застрял в пробке, сидит на совещании, заснул, ушел с ребенком на детскую площадку – и ещё 1000 и одна причина, почему не сейчас. Как плохой футболист, которому внезапно дали пас. И, чтобы передача состоялась, надо как-то проверить, удобно ли клиенту, и не будет ли курьер мотаться почём зря. В компания СДЭК задумались, как это сделать, и при помощи Voximplant нашли для себя оптимальное решение, о котором – под катом.

Эта статья представляет собой адаптацию разделов 2 и 3 из главы 9 моей книги «Глубинное обучение с Python» (Manning Publications).

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

---

Ограничения глубинного обучения

Глубинное обучение: геометрический вид

Самая удивительная вещь в глубинном обучении — то, насколько оно простое. Десять лет назад никто не мог представить, каких потрясающих результатов мы достигнем в проблемах машинного восприятия, используя простые параметрические модели, обученные с градиентным спуском. Теперь выходит, что нужны всего лишь достаточно большие параметрические модели, обученные на достаточно большом количестве образцов. Как сказал однажды Фейнман о Вселенной: «Она не сложная, её просто много».

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

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

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

Заключительную часть описания Red Architecture посвятим многопоточности. Ради справедливости стоит сказать, что начальный вариант класса v нельзя считать оптимальным, так как в нём ничего нет для решения одной из главных проблем к которой неминуемо приходят разработчики real world приложений. Для полного понимания текущей статьи необходимо познакомиться с концепцией Red Architecture здесь.



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

Тот самый момент, когда даже Флэш может позавидовать разработчикам. Ровно неделю назад у нас вышел крутой анонс о новой службе экземпляров контейнеров Azure (Azure Container Instances, ACI), которая максимально упрощает развёртывание контейнеров. Это первая в мире облачная служба такого рода. Ниже я хочу рассказать вам подробнее, что она из себя представляет и как с ней можно работать.

Бинго-бонго и Джимбо-джамбо, дорогие друзья!

У меня на дачке не было света 2 дня, я практически иссох и впал в спячку, но я снова здесь! В этом посте мы начнем писать предсказания погоды и немного напишем кода, а не потыкаем мышкой! Ура! Наконец-то!

Какие прогнозы мы хотим делать

Очень простые! Пока прогнозировать будем только следующий день, а правила придумаем сами; а точнее, правил не будет. Мы просто будем выводить температуру на следующий день, абсолютно такую же, как и сегодня. Сделаем один прикольчик, демонстрирующий возможности projectional editor.

Концепты

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

В прошлой статье Создание сервлетов для чайников. Пошаговое руководство я описал, как создать сервлеты и попытался объяснить, как это работает. В этой статье мы научим наши сервлеты работать с UI через HTTP-запросы GET и POST.

На самом деле, этих запросов намного больше, но для чистоты эксперимента мы разберём только два основных.

• GET — обрабатывает адресную строку, которая получается при вызове сервлета. Например, site.com/example?action=test&id=10&admin=true
• POST — обрабатывает загруженный контент (картинку, файл, строки, объектные данные), в общем, всё, что можно передать через HTTP

В Java-сервлете запросы POST и GET обрабатывают соответствующие методы doPost(); и doGet().

5 июня 2017 года на РИТ я рассказал доклад про то, как мы рефакторим свое огромное клиентское приложение на 2 500 000 строк кода.

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

P.S.: Заранее прошу прощение за качество видео. К сожалению, ничего с этим поделать не могу.

Вводная часть (со ссылками на все статьи)

Лет 10-15 назад, когда программы состояли из исходников и небольшого количества двоичных файлов с работой по сборке итоговых программ отлично справлялись всевозможные «?make». Однако сейчас современные программы и подходы к разработке сильно изменились – это:
множество различных файлов (не считаю исходников) – стили, шаблоны, ресурсы, конфигурации, скрипты, бинарные данные и.т.д;

• предпроцессоры;
• системы проверки стиля исходников или всего проекта (lint, checkstyle и т.д.);
• методики разработки, основанные на тестах, с их запуском при сборке;
• различного типа стенды;
• системы развёртывания на базе облачных технологий и т.д. и.т.п.