Category: производство

Category was added automatically. Read all entries about "производство".

Book

QD32? Щазз

1. Ввиду того что kernel aio никому не нужен, он как правило поломан
2. Ввиду того что позикс-семантика говно, ни винда через IOCP, ни aio не обеспечивают позикс семантику
3. libuv на линуксе использует pread/pwrite в тредпуле
4. Размер этого пула равен... барабанная дробь... 4

Ну то есть вы хоть усритесь но БД на ноде не напишете. Ну на самом деле он меняется через UV_THREADPOOL_SIZE. Также показательно, что обсуждение UV_THREADPOOL_SIZE в контексте диска https://github.com/nodejs/node/issues/22468 не содержит упоминаний NCQ но содержит упоминание элеватора.

Ну то есть блядь не удивительно, что шапкозакидоны "ща напишем эвентлуп с ЯВУ и всех вас уделаем по IO" обосрались. Банально не осилили!

IO это вам не хуй собачий. Они не только не осилили буферизацию, но и даже базовые вещи типа IO concurrency. В-общем тут непаханое поле, на котором закопано бабло.
Book

Абстрактная фабрика синглтонов-2

Поскольку все ответы были в стиле кармановского пункта 6 https://www.atraining.ru/trainers/karmanov/hint/ - "Разбираться в проблеме не нужно, ... – надо просто неправильное заменить на правильное", я сформулирую одновременно более абстрактно и более предметно.

Есть компонент А создающий и дёргающий компонент Б, а компонент Б запускает ракеты и возвращает слово из трёх букв.

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

Классическое решение - сделать, чтобы в тесте компонент А дёргал компонент Б', который будет просто возвращать ожидаемое компонентом А слово из трёх букв, никаких "ракет" при этом не "запуская".

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

Вариант 1 - пусть компонент А не создает объект Б, а принимает его параметром.

В системе будет A(Б), а в тесте A(Б'). Но тут есть недостаток - например если компонент А создаёт Б не напрямую, а создаёт С, который уже создает Б - то С тоже придётся параметризовать.

Ну и для того чтобы этого размножения параметров избежать - используется старый трюк "передаём параметр вглубь, используя глобальную переменную". И мы подходим к варианту 2

Вариант 2 - пусть будет глобальная фабрика БFactory, которая будет производить экземпляры Б или Б'

В системе будет А и Б, без параметров. Может быть даже произвольное количество промежуточных уровней С. Но C будет использовать метод БFactory для конструирования Б. И этот метод будет разным в системе и в тестах.

Но тут недостаток что у нас будет много фабрик - для Б, потом понадобится фабрика для Х, У, ну и т.д. Ну и будут простыни конструирования этих минифабрик при старте системы и в тестах.

Это можно решить вариантом 3.

Вариант 3 - пусть будет одна большая фабрика ФабрикаВсего.

У него есть 2 подварианта

3а - мы просто добавляем в БFactory методы - makeБ, makeХ, makeУ.

3б - мы используем готовую ФабрикуВсего, которых уже написаны тучи.

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

Тут мы избавились от "параметризации всего всем", но для обепечения подменяемости, для каждого подменяемого класса Б нам нужен интефейс IБ. Ну и если у нас классы здорового человека с 1-2 методами - то появляются тучи мелких интерфейсов, ненужных для работы системы, а нужных лишь для работы тестов. Ну то есть код превращается в сплошной бойлерплейт интерфейсов, учитывая, что от бойлерплейта параметров и бойлерплейта фабрик мы избавились.

Тут на помощь (сомнительную, но будем пробовать) приходит Акка, заявляющая что нетипизированность акторов - это не недостаток, а преимущество. В данном случае оно проявляется в том, что если Б - актор, то поскольку всё общение с актором происходит через IDispatch IActor, нам не надо делать тучу этих IБ. И мы приходим к варианту 4.

Вариант 4 - фабрика всего, производящая акторы

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

Но есть ещё

Вариант 4в - трёхэтажная фабрика из прошлого поста

Она получается, если фабрику фабрик в стиле 4а конструировать готовой фабрикой в стиле 3б. Что даёт нам компактность 3а-фабрики в сочетании с конфигурируемостью 3б-фабрики.
Book

Абстрактная фабрика синглтонов

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

Но мы тут делаем пилотный проект сервиса на C#, Dotnet Core, Akka.Net и Linux.

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

Ну и нам понадобился HTTP-клиент. Как его делать "на акторах"?

Я решил, что основной принцип - актор на каждый чих. То есть, HttpClient.Get выглядит так (у нас на самом деле пока не так, но не суть важно):

1. Cоздать HttpActor, параметры запроса - параметры конструктора.
2. Дождаться от него сообщения

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

Для этого очень хочется мокать HttpClient. Но я хочу мокать не хелпер-класс HttpClient, а актор HttpActor. Преимущество - в том что акторы нетипизированные и не надо будет лепить IHttpActor, HttpActor и MockHttpActor.

Ну и у нас "because we can" подключен AutoFac DI, так что хочется как-то задействовать его.

Так что я нашёл на гитхабе репу, которая делает то что мы хотим: мокает дочерний актор.

Но делает она его, мамочки!

https://github.com/sachabarber/AkkaNetDITesting

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

Решили запилить минимальный пример в духе этой репы, но попробовать сократить количество бойлерплейта и параметризации. Например, в автофаке есть named services:

https://autofac.readthedocs.io/en/latest/advanced/keyed-services.html

Ну и получится пирамида из фабрик всё равно, но с меньшим количеством хелпер-классов. Будет автофаковская именованная фабрика акковских фабрик.

Есть ещё трёхэтажный вариант с аутофаковской фабрикой абстрактных фабрик акковских фабрик. Но надеемся что до этого дело не дойдёт.

В-общем я бы конечно хотел отказаться от всего этого говна и сделать на го. Но нет!
Book

Аппы WinRT

После ие, скайпа и может ещё бинг-карт всё остальное под WinRT - какой-то адов ад и пиздец.

Viber? Охх!

Скачал 4 или 5 версий гуглокарт. Часть имеет фпс ниже браузерного. Все по тачпадовскому скроллу делают зум (а не пан, как бингокарты).

Хоть ссш-клиенты есть, и поддерживают стандартные методы авторизации(ключи и агента). Пока не пробовал, сижу в путте.

На удивление не обнаружил такой олдскульной шняги, как клиента RFC 5023 Atom Publishing Protocol. Вроде как есть в Nokia Suite, но она только под телефон (!) и под winrt не заводится.

Обнаружил такой идиотизм и карго-культ, как клиенты Youtube и TED, представляющие из себя, по сути, сайты.

Есть приложение, показывающее текущий IP, но оно не умеет live tile (!).

Есть альтернативный winrt-гуй к ие-трайденту под названием ucbrowser. Отличается тем, что табы вверху, и снова есть разделение на (!) на адресную и поисковую строки.

В родной почте ссылки не отображаются ссылками, приходится копипастить (что, как я понимаю, то ещё удовольствие на тачскрине)
Book

Коммерческое промышленное энтерпрайз-ПО

У людей почему-то возникает деление ПО на "низшее", "высшее" и "настоящее". Низшее и высшее ПО объявляется ненастоящим и не имеющим значения, уделом, соответственно, усатых школьников и единичных элитариев.

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

EclipseFP внезапно допилили

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

Ну поддержку UUAG так и не сделали, хоть официально она и есть. Тьфу

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

В-общем, ещё пару лет им желаю в том же духе попилить.
Book

(no subject)

http://spasche.net/files/lcdfiltering/

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