В прошлом месяце Trisha Gee (JetBrains) представила на SpringOne демонстрацию создания приложения, отображающего стоимость акций в реальном времени, с использованием Spring Boot, Kotlin и JavaFX. Демонстрация в режиме реального времени была записана и доступна в виде 70-минутного видео.

18 декабря Trisha завершила публикацию на сайте dzone.com туториала про реактивный Spring Boot на основе указанного видео, в виде серии более коротких видеороликов с сопровождающим сообщением в блоге, объясняющих каждый из шагов более медленно и более подробно.

У меня появилась мысль перевести этот туториал на русский язык. Однако на мой запрос об этом Trisha ответила вежливым отказом:

«Let me check with my organisation. I would love to have it translated but we might have a prefered way to get things translated.»

Поэтому я решил ограничиться обзором этого туториала, включающего следующую серию уроков:

Ember Octane — это новая редакция фреймворка Ember.js, а также лучший способ для команд создавать амбициозные веб-приложения.

20 декабря вышла новая версия Ember 3.15. И это Octane! Любопытно, что это значит для веб-разработки? Этот пост поможет вам сориентироваться.

Мы с гуглотранслейтом усердно старались над переводом (особенно гуглотранслейт). Добро пожаловать под кат!

Наверное, не я один после прочтения документации о sealed классах подумал: «Ладно. Может быть это когда-нибудь пригодится». Позже, когда в работе я встретил пару задач, где удалось успешно применить этот инструмент, я подумал: «Недурно. Стоит чаще задумываться о применении». И, наконец, я наткнулся на описание класса задач в книге Effective Java (Joshua Bloch, 3rd) (да-да, в книге о Java).

Давайте рассмотрим один из вариантов применения и оценим его с точки зрения семантики и производительности.

Новый год все ближе, скоро закончатся 2010-е годы, подарившие миру нашумевший ренессанс нейросетей. Мне не давала покоя и лишала сна простая мысль: «Как можно ретроспективно прикинуть скорость развития нейросетей?» Ибо «Тот, кто знает прошлое — тот знает и будущее». Как быстро «взлетали» разные алгоритмы? Как вообще можно оценить скорость прогресса в этой области и прикинуть скорость прогресса в следующем десятилетии? 



Понятно, что можно примерно посчитать количество статей по разным областям. Метод не идеальный, нужно учитывать подобласти, но в целом можно пробовать. Дарю идею, по Google Scholar (BatchNorm) это вполне реально! Можно считать новые датасеты, можно новые курсы. Ваш же покорный слуга, перебрав несколько вариантов, остановился на Google Trends (BatchNorm). 

Мы с коллегами взяли запросы основных технологий ML/DL, например, Batch Normalization, как на картинке выше, точкой добавили дату публикации статьи и получили вполне себе график взлета популярности темы. Но не у всех тем путь усыпан розами взлет такой явный и красивый, как у батчнорма. Некоторые термины, например регуляризацию или skip connections, вообще не получилось построить из-за зашумленности данных. Но в целом тренды собрать удалось.

Кому интересно, что получилось — добро пожаловать под кат!

Познакомившись с Аланом Тьюрингом, Брукер отправился работать в Манчестерский университет и написал язык программирования для первого коммерческого компьютера

Тони Брукер, справа, с коллегами из Университета Эссекса в 1972 году

Тони Брукер, математик и специалист по информатике, разработавший язык программирования для первого коммерческого компьютера, умер 20 ноября в доме престарелых в Хексеме, Англия. Ему было 94 года. Его кончину подтвердил его сын Стивен.

Брукер занимался компьютерными исследованиями на их раннем этапе в Кембриджском университете, и однажды, возвращаясь домой после восхождений на горы Северного Уэльса, остановился в Манчестерском университете, чтобы посетить тамошнюю компьютерную лабораторию, одну из первых в своём роде. Он приехал туда без приглашения, и познакомился с Аланом Тьюрингом, отцом-основателем компьютерной эпохи, бывшим тогда заместителем директора лаборатории.

Привет, Хабр! Представляю вашему вниманию перевод статьи Protecting Your GraphQL API From Security Vulnerabilities.

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

Всем доброго здравия!

В преддверии Нового года хочу продолжить рассказывать про использование С++ на микроконтроллерах, на этот раз попытаюсь рассказать про использование шаблона Наблюдатель (но далее я буду называть его Издатель-Подписчик или просто Подписчик, такой вот каламбур), а также реализацию статической подписки на С++17 и преимущества этого подхода в некоторых приложениях.

Для организации обработки потока задач используются очереди. Они нужны для накопления и распределения задач по исполнителям. Также очереди могут обеспечивать дополнительные требования к обработке задач: гарантия доставки, гарантия однократного исполнения, приоритезация и т. д.

Как правило, используются готовые системы очередей сообщений (MQ — message queue), но иногда нужно организовать ad hoc очередь или какую-нибудь специализированную (например, очередь с приоритетом и отложенным перезапуском не обработанных из-за исключений задач). О создании таких очередей и пойдёт речь ниже.

Ограничения применимости

Предлагаемые решения предназначены для обработки потока однотипных задач. Они не подходят для организации pub/sub или обмена сообщениями между слабо связанными системами и компонентами.

Очередь поверх реляционной БД хорошо работает при малых и средних нагрузках (сотни тысяч задач в сутки, десятки-сотни исполнителей), но для больших потоков лучше использовать специализированное решение.

Суть метода в пяти словах

select ... for update skip locked

OTP расшифровывается как Open Telecom Platform; так исторически сложилось, потому что платформа создавалась для нужд и на деньги Ericsson. Но, в принципе, это название имеет примерно столько же коннотаций с ее функциональностью, сколько и яблоки со среднего качества телефонами.

Основной отличительной характеристикой OTP по замыслу авторов является отказоустойчивость. Не многопоточность, не модель акторов, не богатые возможности pattern matching’а, даже не прозрачная кластеризация и не hot code upgrades. Отказоустойчивость.

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

In my blog I argued that processes should behave pretty much like people. People have private memories and exchange data by message passing.
— Why I don't like shared memory

Обмен сообщениями внутри OTP очень прост: один процесс посылает сообщение другому (или группе других процессов), синхронно, или асинхронно. Но для этого необходимо знать, кому эти сообщения посылать. То есть менеджером обмена выступает отправитель. Но что если мы хотим просто слать broadcast и дать возможность всем заинтересованным процессам подписаться на это сообщение?

Пролог

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

Предисловие

Всем привет! Меня зовут Саша, и я больше шести лет занимаюсь тестированием бэкенда (сервисы Linux и API). Мысль о статье у меня появилась после очередной просьбы знакомого тестировщика подсказать ему, что можно почитать по командам Linux перед собеседованием. Обычно от кандидата на позицию QA инженера требуют знание основных команд (если, конечно, подразумевается работа с Linux), но как понять, про какие команды стоит почитать во время подготовки к собеседованию, если опыта работы с Linux мало или вовсе нет?

Поэтому, хоть про это уже и много раз написано, я всё же решился написать ещё одну статью «Linux для новичков» и перечислить здесь базовые команды, которые нужно знать перед любым собеседованием в отдел (или компанию), где используют Linux. Я подумал, какие команды и утилиты и с какими параметрами я использую чаще всего, собрал фидбек от коллег, и скомпоновал это всё в одну статью. Статья условно делится на 3 части: сначала краткая информация об основах ввода-вывода в терминале Linux, затем обзор самых базовых команд, а в третьей части описывается решение типовых задач в Linux.

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

Здравствуй, читатель! Меня зовут Александр, родился я в небольшом городке (меньше 10000 человек) в Беларуси. Моя семья была бедной, игрушек крайне мало, про компьютер и какие либо приставки вообще можно не заикаться. Не смотря на то, что семья была бедной, у матери были не бедные родственники, которые иногда дарили нам какие либо не дешевые вещи. И вот однажды (где то в 2001 году) эти самые родственники, дарят нам компьютер «Байт»(советский аналог ZX Spectrum 48k). Радости моей не было предела! Сразу же я начал, запускать на нем игры. Игры на этом компьютере загружались с обычных аудиокассет с магнитной лентой. Загрузка одной игры длилась примерно 5 минут и с не малой вероятностью, могла прекратиться из-за некачественного сигнала. Чтобы увеличить вероятность успешной загрузки, мне приходилось протирать спиртом и регулировать положение считывающей головки магнитофона. Весь этот шаманизм при загрузке, длительность загрузки и невозможность сохраняться в играх, привели к тому, что постепенно я начал терять интерес к играм. Но вместе с «Байт»-ом мне также подарили книгу, по работе с этим компьютером. Я решил прочитать эту книгу, чтобы узнать больше о возможностях «Байт»-а. В книге оказался учебник по встроенному в «Байт» языку программирования «Бэйсик».

Пока Stephen Fluin традиционно не выпустил новый релиз и статью про фичи нового Angular, я попытался собрать в кучу все и ответить на вопрос что нового?

Одна из самых крутых фич, которую мы ждали почти 2 года — Angular Ivy, и наконец то Angular 9 будет компилироваться с Ivy по умолчанию. Если вы хотите погрузится во внутренности Angular Ivy есть 2 видео с AngularConnect: про Compiler и Runtime.

Как и всегда с Angular CLI вы сможете проапгреиться довольно легко, подробный гайд.

Привет, Хабр!

Давно вынашивали мысль обсудить с вами тему GraalVM, откладывали, пока не нашли, наконец, сегодняшнюю статью, тематика которой серьезно выходит за рамки разбора конкретной виртуальной машины. Автор Майк Хёрн (Mike Hearn) ни много ни мало излагает целую парадигму межъязыковых взаимодействий и многоязычного программирования (polyglot programming). Далее — знаменитый пример вертикального масштабирования и весьма длинная статья под катом.

Я давно обещался написать статью о том, как себя показал Haskell в реальных задачах в продакте.

Для тех, кто не уследил — его в начале 2012 пролоббировали и с энтузиазмом начали внедрять программисты в Селектеле. Тогда же я обещал опубликовать отчёт о том, насколько «это всё» можно использовать.

Продакт в коммерческом проекте — это не в маленькая песочница «для себя», не академический эксперимент в области Computer Science. Это бесконечная борьба за «линию партии», когда вокруг ад, ужас и погибель, а оно всё равно должно работать. Int64 в XML-RPC кодируется строкой (потому что int'ы в XML-RPC signed int32), openssl при чтении нескольких сертификатов из файла читает только первый из них, в bool надо писать либо «1», либо «0», но иногда — «2», ибо только так придумали закодировать третий режим — и т.д. и т.п. В этих условиях требования к языку постепенно перерастают в требования к его экосистеме, инфраструктуре, готовности адаптироваться к реальному миру.

Я буду писать о Haskell с позиций product owner'а, менджера проекта, системного администратора, но никак не программиста. Так что не ожидайте от меня задушевных восторгов о том, как изящно через монадки можно сделать семигрупоид и как здорово выводить типы через типы с помощью типов.

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

Начнём с потребительских свойств.

Я мирно сидел на семинаре, слушал доклад студента о статье с прошлого CVPR и параллельно гуглил тему.

— К достоинствам статьи можно отнести наличие исходного кода….
Пришлось вмешаться:
— Наличие чего, простите?
— Э-э-э… Исходного кода…
— Вы его смотрели? 
— Нет, но в статье указано… 
(мать-мать-мать… привычно отозвалось эхо)
ㅡ Вы ходили по ссылке?

В статье, действительно, предельно обнадеживающе написано: “The code and model are publicly available on the project page …/github.io/...”, — однако в коммите двухлетней давности по ссылке значится вдохновляющее «Код и модель скоро выложим»‎:


Ищите и обрящете, стучите и откроется… Может быть… А может быть и нет. Я бы, исходя из печального опыта, ставил на второе, поскольку ситуация в последнее время повторяется ну уж о-о-очень часто. Даже на CVPR. И это только часть проблемы! Исходники могут быть доступны, но, к примеру, только модель, без скриптов обучения. А могут быть и скрипты обучения, но за несколько месяцев с письмами к авторам не получается получить такой же результат. Или за год на другом датасете с регулярными скайп-звонками автору в США не удается воспроизвести его результат, полученный в наиболее известной лаборатории в отрасли по этой теме… Трындец какой-то.

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

Кому интересно, что стало со студентом куда катится научный мир, в том числе по «вине»‎ глубокого обучения, добро пожаловать под кат!

Очень хотелось назвать статью «Proxy-сервис на Go в 3 строчки», но я выше этого.

В действительности так и есть, основную логику можно уместить в трёх строках. Для нетерпеливых и тех, кто хочет увидеть самую суть:

proxy := httputil.NewSingleHostReverseProxy(url)
r.Header.Set(header, value)
proxy.ServeHTTP(w, r)

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

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

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

Скомпилируем простенькую программу выводящую "Hello World" и пройдемся по его структуре

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

На самом деле, это не так сложно. Достаточно использовать инструмент javap из JDK и рассмотреть дизассемблированный код.

А мы приступим к разбору самой структуры байт-кода для JVM

К сожалению, адекватно перевести название затеянного мной безобразия на русский язык оказалось не просто. С удивлением я обнаружил, что официальная документация MSDN называет "дженерики" "шаблонами" (по аналогии с C++ templates, я полагаю). В попавшемся мне на глаза 4-м издании "CLR via C#" Джеффри Рихтера, переведенном издательством "Питер", дженерики именуются "обобщениями", что гораздо лучше отражает суть понятия. В этой статье речь пойдет о небезопасных обобщенных математических операциях в C#. Учитывая, что C# не предназначен для высокопроизводительных вычислений (хотя, безусловно, на это способен, но не в состоянии тягаться с тем же C/C++), математическим операциям в BCL уделено не так много внимания. Давайте попробуем упростить работу с базовыми арифметическими типами силами C# и CLR.