User
Прокрастинацию принято считать разновидностью лени и ерундой, а эффективным лекарством от нее грозный окрик: «Соберись, тряпка!» На деле прокрастинация — опасная проблема, сродни зависимости, которая вызывает много вины и стыда, и способна со временем разрушить личность. Почему она так опасна, редко лечится попыткой «взять себя в руки» и как ее одолеть?
Я веду канал в Telegram GameDEVils и блог на Substack . Подписывайтесь, я делюсь там материалами про геймдизайн, разработку и историю игр. 
Поступают сообщения об отказе спутниковой навигации на авиалайнерах при движении по маршрутам в Прибалтике. Аналогичные сообщения поступали ранее из восточного средиземноморья, что побудило немецкий DLR (German Aerospace Center) отправить свой A320 на Кипр для сбора информации. Миссия состоялась в начале 2020 года, а по её результатам была выпущена научная статья, о выводах которой под катом
Привет, Хабр.
В этой статье я хочу рассказать о своем опыте создания учебной среды для экспериментов с микросервисами. При изучении каждого нового инструмента мне всегда хотелось его попробовать не только на локальной машине, но и в более реалистичных условиях. Поэтому я решил создать упрощенное микросервисное приложение, которое впоследствии можно будет "обвешивать" всякими интересными технологиями. Основное требование к проекту — его максимальная функциональная приближенность к реальной системе.
Изначально я разбил создание проекта на несколько шагов:
Создать два сервиса — 'бекенд' (backend) и 'шлюз' (gateway), упаковать их в docker-образы и настроить их совместную работу
Ключевые слова: Java 11, Spring Boot, Docker, image optimization
Разработка Kubernetes конфигурации и деплой системы в Google Kubernetes Engine
Ключевые слова: Kubernetes, GKE, resource management, autoscaling, secrets
Создание чарта с помощью Helm 3 для более эффективного управления кластером
Ключевые слова: Helm 3, chart deployment
Настройка Jenkins и пайплайна для автоматической доставки кода в кластер
Ключевые слова: Jenkins configuration, plugins, separate configs repository
Каждому шагу я планирую посвятить отдельную статью.
Направленность этого цикла статей заключается не в том, как написать микросервисы, а как заставить их работать в единой системе.
В последнее время задача распознавания символов в прикладных программах не представляет особой сложности — можно использовать множество готовых OCR-библиотек, многие из которых доведены почти до совершенства. Но все же иногда может возникнуть задача разработать свой алгоритм распознавания без использования сторонних «навороченных» OCR-библиотек.
Именно такая задача возникла у меня по ходу работы, а причин, почему лучше не использовать готовые библиотеки, несколько: закрытость проекта, с его дальнейшей сертификацией, определенное ограничение на количество строчек кода и размер подключаемых библиотек, тем более что по предметной области распознавать приходится достаточно определенный набор символов.
Квантовые компьютеры и квантовые вычисления — новый баззворд, который добавился в наше информационное пространство наряду с искусственным интеллектом, машинным обучением и прочими высокотехнологическими терминами. При этом мне так и не удалось найти в интернете материал, который бы сложил у меня в голове пазл под названием “как работают квантовые компьютеры”. Да, есть много прекрасных работ, в том числе и на хабре (см. Список ресурсов), комментарии к которым, как это обычно и бывает, еще более информативны и полезны, но картинка в голове, что называется, не складывалась.
А недавно ко мне подошли коллеги и спросили “Ты понимаешь как работает квантовый компьютер? Можешь нам рассказать?” И тут я понял, что проблема со складыванием в голове целостной картинки есть не только у меня.
В результате была сделана попытка скомпилировать информацию о квантовых компьютерах в непротиворечивую логическую схему, в которой бы на базовом уровне, без глубокого погружения в математику и структуру квантового мира, объяснялось что такое квантовый компьютер, на каких принципах он работает, а также какие проблемы стоят перед учеными при его создании и эксплуатации.
Функциональное программирование — это очень забавная парадигма. С одной стороны, про неё все знают, и все любят пользоваться всякими паттерн матчингами и лямбдами, с другой на чистом ФП языке обычно мало кто пишет. Поэтому понимание о том, что же это такое восходит больше к мифам и городским легендам, которые весьма далеко ушли от истины, а у людей складывается мнение, что "ФП подходит для всяких оторванных от жизни программок расчетов фракталов, а для настоящих задач есть зарекомендовавший себя в бою проверенный временем ООП".
Хотя люди обычно признают удобства ФП фич, ведь намного приятнее писать:
int Factorial(int n)
{
Log.Info($"Computing factorial of {n}");
return Enumerable.Range(1, n).Aggregate((x, y) => x * y);
}чем ужасные императивные программы вроде
int Factorial(int n)
{
int result = 1;
for (int i = 2; i <= n; i++)
{
result *= i;
}
return result;
}Так ведь? С одной стороны да. А с другой именно вторая программа в отличие от первой является функциональной.
Как же так, разве не наоборот? Красивый флюент интерфейс, трансформация данных и лямбды это функционально, а грязные циклы которые мутируют локальные переменные — наследие прошлого? Так вот, оказывается, что нет.
Я расскажу о том, как изучать иностранный язык и буду это делать на примере личного опыта изучения английского языка. Английский я начал учить в 36 лет, а уже сейчас у меня свободный английский язык (как письменный, так и устный), подтверждённый официальными сертификатами. Чтобы не быть голословным: у меня есть сертификат IELTS 7.5 баллов (это С1 level) и сертификат переводчика NAATI. Короче, я знаю о чем говорю.
Оглавление:
Итак, вопрос: “Как выучить английский язык?”.
Человек остается начинающим в течение 1000 дней. Он находит истину после 10000 дней практики.
«Мастер совершает больше ошибок, чем новичок — попыток»
Maybe определяет два связанных контекста:
data Maybe a = Nothing | Just a
Just a против Nothing. Но сначала поговорим о функторах!
Как я писал в предисловии предыдущей статьи, я нахожусь в поисках языка, в котором я мог бы писать поменьше, а безопасности иметь побольше. Моим основным языком программирования всегда был C#, поэтому я решил попробовать два языка, симметрично отличающиеся от него по шкале сложности, про которые до этого момента приходилось только слышать, а вот писать не довелось: Haskell и Go. Один язык стал известен высказыванием "Avoid success at all costs"*, другой же, по моему скромному мнению, является полной его противоположенностью. В итоге, хотелось понять, что же окажется лучше: умышленная простота или умышленная строгость?
Я решил написать решение одной задачки, и посмотреть, насколько это просто на обоих языках, какая у них кривая обучения для разработчика с опытом, сколько всего надо изучить для этого и насколько идиоматичным получается "новичковый" код в одном и другом случае. Дополнительно хотелось понять, сколько в итоге мне придется заплатить за ублажание хаскеллевского компилятора и сколько времени сэкономит знаменитое удобство горутин. Я старался быть настолько непредвзятым, насколько это возможно, а субъективное мнение приведу в конце статьи. Итоговые результаты меня весьма удивили, поэтому я решил, что хабровчанам будет интересно почитать про такое сравнение.