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

Наследование директив в nginx - это классная штука. Именно наследование позволяет писать простые и понятные конфиги. При слиянии конфигураций значение директивы и её функциональность переходит из вышестоящего контекста в текущий. Логично, что наследование не происходит от параллельных контекстов, например от соседнего location или if.

Вроде бы всё хорошо. Пока не возникают исключения.

N.B.: Здесь и далее описывается работа с nginx версии 1.21.1 (если не указано иное). Всё сказанное основывается лишь на опыте и ошибках автора. Вместе с тем автор не является разработчиком nginx и даже его маститым сварщиком, поэтому не стоит принимать слова автора как догму, а, наоборот, подвергать сомнению и самостоятельному тестированию.

Всем привет, последние года три мое основное хобби – создание игр. Не могу сказать, что я добилась чего-то сверхъестественного, но в Steam есть две мои игры (горжусь самим фактом доведенных до конца проектов, но сейчас многое в них уже поменяла бы). И обе эти игры сделаны на движке Unity.

Почему на нем?

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

Эта статья является переводом материала «What is functional programming?».

В этой статье Владимир Хориков попытается ответить на вопрос: что такое функциональное программирование?

Итак, что такое функциональное программирование? Этот термин возникает довольно часто, и каждый автор, пишущий о нем, дает собственное объяснение. На взгляд автора оригинала, самым простым и в то же время точным определением является следующее: функциональное программирование - это программирование с математическими функциями.

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

Серьезно. Кода на который можно посмотреть и сказать "это сделано на отлично" почти не бывает – в основном один фарш из легаси, гвоздей, и иероглифов.

Это не пессимизм. Откройте почти любой коммерческий проект, где люди решают задачи, живут с тем что есть, проект уже прожил сравнительно долгую жизнь, а команда меняется (и это нормально).

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

Проблема

Описание

• инкапсулирование запроса в виде объекта для последующего протоколирования/логирования и т.п.
• наделение сущности “вызов метода объекта” свойствами самостоятельного объекта;
• объектно-ориентированный обратный вызов (callback);
  
  

Когда будут устранены все проблемы в программе?

Как нам удалось это сделать?

Когда ты уже сделаешь задачу?

Вы будете на нас тренироваться?

Почему программа постоянно тормозит?

Когда вы начнёте нормально работать?

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

Но важно не содержание ответов, а само их наличие. Вопросы, как вы поняли, весьма тенденциозные.

Основано на реальных событиях.

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

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

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

 - Да, добрый день, друзья. – начинает Виктор. – Меня зовут Виктор, я принёс вас настоящий скрам. Предлагаю обсудить варианты сотрудничества.

Повисла неловкая пауза. С одной стороны, у меня в голове был целый ворох вопросов по методике и практике применения скрама, но они вряд ли подходили для собеседования. С другой стороны, я примерно представлял, кто такой скрам-мастер и чем он занимается, поэтому не знал, что спросить на тему «а чем вы у нас будете заниматься?». Но выручил Александр.

 - Итак, скрам... – Александр сложил ладони вместе, медленно опустил их на стол, выдержал паузу («завис»), будто обдумывая следующую фразу. – Иван заставил меня изучить, что это за методика, в рамках подготовки к этой встрече. Я сразу честно скажу – прочитал лишь половину книги. Поэтому, Виктор, если не затруднит, можете в двух словах рассказать, что именно хотите нам предложить? Чем будете заниматься, проще говоря?

Скорость разработки и производительность программистов могут отличаться в зависимости от их уровня и используемых в проектах технологиях. Для проектирования ПО нет стандартов и ГОСТов, только вы выбираете, как будете разрабатывать свою программу. Один из лучших способов повысить эффективность работы — применить шаблон проектирования CQRS. 

Существует три вида паттерна CQRS: Regular, Progressive и Deluxe. В этой статье я расскажу о первом — классическом паттерне Regular CQRS, который мы используем в DD Planet в рамках разработки онлайн-сервиса «Выберу.ру». Progressive и Deluxe — более сложные архитектуры и влекут за собой использование обширного набора абстракций.

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

SQLite во многих случаях является удобным, незаменимым инструментом. Я уже не могу себе представить - как мы все жили без него. Тем не менее, есть некоторые неудобства при его использовании, связанные с тем, что это легкая встраиваемая СУБД.

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

Предлагаю свой вариант решения проблемы:

Выносим весь SQL-код в отдельный файл ресурсов, подключенный к проекту

Запросы в SQL-файле разделяем маркерами начала с идентификаторами и маркерами конца

Создаем класс - менеджер SQL-запросов. При загрузке приложения он читает SQL-файл из ресурсов и составляет из него список хранимых процедур.

В процессе работы приложения менеджер извлекает текст SQL-запроса по его идентификатору для последующей его передачи на выполнение

1. Как провести собрание. И нет, не болтать больше всех на собрании, а именно провести его.
2. Как написать проектную документацию, получить отзывы и довести ее до решения в разумные сроки
3. Как наставлять «младшего» коллегу по команде, инженера в середине карьеры, нового менеджера, которому нужен технический совет
4. Как порадовать старшего менеджера, который хочет поговорить о технических вещах, которых он на самом деле не понимает, не закатывая глаза и не заставляя его чувствовать себя глупо
5. Как объяснить техническую концепцию за закрытыми дверями высокопоставленному лицу, слишком смущенному, чтобы открыто признать, что он ее не понимает
6. Как убедить другую команду использовать ваше решение вместо написания собственного
7. Как заставить другого инженера сделать что-то для вас, попросив о помощи таким образом, чтобы он почувствовал, что его ценят
8. Как вести проект, даже если вы не менеджерите никем из людей, работающих над ним
9. Как заставить других инженеров прислушиваться к вашим идеям, не заставляя их чувствовать угрозу
10. Как прислушиваться к идеям других инженеров, не чувствуя угрозы

Буквально на днях пришел вопрос от одного из подписчиков касательно одного из постов моего telegram канала. Его смутил вот такой кусок кода:

usort($firstArray, static function($first, $second) { return $first <=> $second;
});

Вопрос звучал так:

"Зачем делать callback’и в функции сортировки (usort), статическими?"

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

Матчасть

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

Начнём с самого начала. В 2000 году один из авторов спецификаций HTTP и URI Рой Филдинг защитил докторскую диссертацию на тему «Архитектурные стили и дизайн архитектуры сетевого программного обеспечения», пятая глава которой была озаглавлена как «Representational State Transfer (REST)». Диссертация доступна по ссылке.

Как нетрудно убедиться, прочитав эту главу, она представляет собой довольно абстрактный обзор распределённой сетевой архитектуры, вообще не привязанной ни к HTTP, ни к URL. Более того, она вовсе не посвящена правилам дизайна API; в этой главе Филдинг методично перечисляет ограничения, с которыми приходится сталкиваться разработчику распределённого сетевого программного обеспечения. Вот они:

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

Всё, на этом определение REST заканчивается. Дальше Филдинг конкретизирует некоторые аспекты имплементации систем в указанных ограничениях, но все они точно так же являются совершенно абстрактными. Буквально: «ключевая информационная абстракция в REST — ресурс; любая информация, которой можно дать наименование, может быть ресурсом».

Ключевой вывод, который следует из определения REST по Филдингу, вообще-то, таков: любое сетевое ПО в мире соответствует принципам REST, за очень-очень редкими исключениями.

ASP.NET Core Blazor — это разработанная Microsoft веб-платформа, предназначенная для запуска на стороне клиента в браузере на основе WebAssembly (Blazor WebAssembly) или на стороне сервера в ASP.NET Core (Blazor Server), но две эти модели нельзя использовать одновременно. Подробнее о моделях размещения написано в документации.

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

• запустить Server и WebAssembly одновременно в одном приложении,
• переключаться с Server на WebAssembly без перезагрузки приложения,
• реализовать универсальный механизм аутентификации,
• синхронизировать состояние Server и WebAssembly с помощью gRPC.

TL;DR:

Пример доступен на github.

Давно хотел написать статью про своё хобби, которое стало нечто большим для меня. 

Я закончил математический факультет(ТвГУ) в 2012г.  В период учёбы я профессионально играл в покер, как вживую, так и онлайн(yura_$198802,основной аккаунт PS). Не могу сказать, что был супер успешен, но для студента вполне себе подработка. Уже с 2011 года я начал карьеру программиста и продолжаю её по сей день. Это мой основной источник заработка. Но где-то в 2014 я серьёзно решил заняться написание покерного бота, для онлайн площадок. На данный момент “я” превратился в команду энтузиастов, которая двигает этот проект вперёд! Еще в университете довольно таки плотно был знаком с Байесовским классификатором, а также имел  базовые представления по нейронным сетям. Сейчас стало "мейнстримом" считать, что если вы нашли релевантные данные и корректно обучили сетку с использованием (ML,CatBoost,TensorFlow и т.д.), то вы сделали что-то похожее на “искусственный интеллект”(далее AI). Я решил ,что если раскрою верхнеуровневую архитектуру своего проекта, это может кого-то удивить тем, что AI - это нечто большое.(только не профессионалов в этой области) И даже в такой игре как покер, где казалась бы не обойтись без нейронных сетей(на самом деле это действительно так), до момента органического встраивания их в продукт, лично у меня прошло примерно 2500 дней. Сразу хочу отметить, что  способ, когда ты знаешь всю информацию обо всех участниках и играешь с одними и теми же, где можно просто собрать модель и обучить её по лучшим и быть в их числе, не подходит для так называемого реального онлайн покера. Тут  нужно делать изначально экспертную систему, которую уже можно бесконечно долго улучшать и модифицировать.

Я верю: придёт великий день, и какой-нибудь могучий законодатель обяжет программистов 1С указывать на этикетке состав оказываемой услуги. С продуктами питания вроде получилось – не всё гладко, конечно, но отличить колбасу «точно не из мяса» от «возможно, из мяса» уже получается.

Пока же у услуги «доработка 1С под требования заказчика» весьма и весьма мутный состав. Давайте возьмём лупу и прочитаем то, что написано мелким шрифтом.

Какое-то время назад мы писали цикл статей про то, как правильно измерять качество систем распознавания речи, и собственно снимали метрики с доступных решений (цикл статей — 1, 2, 3) (на тот момент и коммерческих и некоммерческих решений). На Хабре была выжимка из этого цикла в рамках этой статьи, но до масштабного обновления исследования, достойного публикации на Хабре, руки никак не доходили (это требует как минимум большого количества усилий и подготовки).

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

• Добавилось много валидационных сетов из разных реальных доменов;
• На рынок вышел Сбер, в первую очередь интересно протестировать именно его;
• Для чистоты эксперимента, мы не предупреждали разработчиков систем о доменах и факте проведения тестов;
• Мы также попробовали немного протестировать пропускную способность сервисов (понятно, что мы не знаем какое железо и ограничения стоят в облаке);
• Мы рассматриваем только коммерческие системы, к которым у нас получилось получить доступ и которые показали хоть какой-то намек на "всеядность", работу с холодного старта и "энтерпрайзность";

Перевод статьи "Why most unit testing is waste?"

Автор: James O Coplien, Перевод: Епишев Александр  

1.1 Наши дни

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

Когда я работаю с файлами в Node.js, меня не оставляет мысль, что я пишу очень много однотипного кода. Создание, чтение и запись, перемещение, удаление, обход файлов и подкаталогов, всё это обрастает неимоверным количеством бойлерплейта, который еще усугубляется странными названиями функций модуля fs. Со всем этим можно жить, но меня не оставляла мысль, что можно сделать удобнее. Хотелось, чтобы такие элементарные вещи, как, например, чтение или запись текста (или json) в файл можно было написать в одну строчку.

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