Помнится, во времена .NET 1.1 и 2.0 можно было часто увидеть пророчества майкрософтовских евангелистов, мол, скоро любая домохозяйка сможет создавать сайты и писать программы. Большинство программистов посмеялось, но, как выяснилось, кто-то отнёсся к этому серьёзно. Во всяком случае, это объясняет, почему шаблоны проектирования IoC/DI получили второе дыхание в 2000-х, причём даже внутри самой MS (желаю Вам никогда в жизни не столкнуться с SCSF).
С точки зрения теории разработки ПО лично мне гораздо чаще приходилось читать или слышать хвалебные статьи и отзывы об IoC/DI, но, как всегда, критика тоже есть. Можно ознакомиться, например, здесь (англ.), здесь (англ.), тут (хабр), ещё (англ.). В частности в вину ставится нарушение принципа инкапсуляции в ООП.
Читать полностью »
Рубрика «Анализ и проектирование систем» - 102
Несколько аргументов против Dependency Injection и Inversion of Control
2017-04-01 в 8:09, admin, рубрики: dependency injection, di, inversion of control, ioc, Анализ и проектирование систем, Программирование, теория заговора, техподдержка, управление проектамиПростейший HTTP сервер на Golang и Elixir. Сравнение производительности
2017-03-31 в 7:00, admin, рубрики: ab, Erlang/OTP, Go, golang, jmeter, wrk, Анализ и проектирование систем, высокая производительность, Тестирование веб-сервисов
Пару недель назад, я решил взять простейший пример HTTP сервера на Go и измерить его производительность. Потом я смело взял Phoenix, прогнал на тех же тестах, и расстроился. Результаты были не в пользу Elixir/Erlang (45133 RPS у Go и всего 3065 RPS у Phoenix). Но Phoenix — это тяжело. Надо что-то хотя бы примерно равное по простоте и логике разработки тому, что есть на Go: когда есть путь — "/" и handler для него. Логичной аналогией мне показалось решение cowboy + plug, где у нас есть Router, который так же ловит "/" и отвечает на него. Результаты убили — Elixir/Erlang опять оказался медленнее:
Golang
sea@sea:~/go$ wrk -t10 -c100 -d10s http://127.0.0.1:4000/
...
452793 requests in 10.03s, 58.30MB read
Requests/sec: 45133.28
Transfer/sec: 5.81MBelixir cowboy plug
sea@sea:~/http_test$ wrk -t10 -c100 -d10s http://127.0.0.1:4000/
...
184703 requests in 10.02s, 28.57MB read
Requests/sec: 18441.79
Transfer/sec: 2.85MBКак жить дальше? Две недели я не спал и не ел (почти). Все, во что я верил все эти годы: совершенство vm erlang, ФП, зеленые процессы, было растоптано разорвано, сожжено и пущено по ветру. Немного отойдя от шока, успокоившись, и подтерев сопли я решил разобаться, в чем дело.
MIPSfpga и UART
2017-03-29 в 20:18, admin, рубрики: C, fpga, mips, MIPS microAptiv UP, MIPSfpga, SoC, Verilog, Анализ и проектирование систем, программирование микроконтроллеров, системное программированиеПрошло чуть больше месяца с тех пор, как я портировал open source модуль UART16550 на шину AHB-Lite. Писать об этом на тот момент было несколько не логично, так как еще не была опубликована статья про прерывания MIPSfpga.
Если вы опытный разработчик, то для вас только одна полезная новость: UART16550 добавлен в состав системы MIPSfpga-plus, дальше можете не читать. А тем, кого интересует разобранный пример использования этого модуля — добро пожаловать под кат.
Интеграция XML данных — другой путь
2017-03-29 в 15:00, admin, рубрики: big data, data warehouse, olap, sql server, XML, xpath, xslt, Анализ и проектирование системВ данной статье описывается «нетрадиционная», но достаточно мощная технология обработки XML, позволяющая импортировать любые XML-данные и преобразовывать их структуру эффективно и просто, при этом один и тот же процесс обработки позволяет трансформировать исходные данные любой структуры без какого-либо изменения программного кода.
Читать полностью »
Frontera: архитектура фреймворка для обхода веба и текущие проблемы
2017-03-29 в 12:16, admin, рубрики: big data, frontera, Hbase, information retrieval, python, Анализ и проектирование систем, высокая производительность, метки: fronteraВсем привет, я занимаюсь разработкой Frontera, первым в истории фреймворком для масштабного обхода интернета сделанным на Python-е, с открытым исходным кодом. С помощью Фронтеры можно легко сделать робота который сможет выкачивать контент со скоростью тысяч страниц в секунду, при этом следуя вашей стратегии обхода и используя обычную реляционную БД или KV-хранилище для хранения базы ссылок и очереди.
Разработка Фронтеры финансируется компанией Scrapinghub Ltd., имеет полностью открытый исходный код (находится на GitHub, BSD 3-clause лицензия) и модульную архитектуру. Мы стараемся чтобы и процесс разработки тоже был максимально прозрачным и открытым.
В этой статье я собираюсь рассказать о проблемах с которыми мы столкнулись при разработке Фронтеры и эксплуатации роботов на ее основе.
Читать полностью »
MIPSfpga и прерывания
2017-03-27 в 11:59, admin, рубрики: C, fpga, mips, mips assembler, MIPS microAptiv UP, MIPSfpga, SoC, Verilog, Анализ и проектирование систем, программирование микроконтроллеров, системное программированиеВ статье приводится несколько примеров настройки и использования прерываний MIPS32 Release 2, включая подробное описание задаваемой при этом конфигурации, описывается работа с контроллером внешних прерываний.
Весь описываемый код опубликован на github в составе проекта mipsfpga-plus [L3].
Микрооптимизации важны: предотвращаем 20 миллионов системных вызовов
2017-03-27 в 8:26, admin, рубрики: ruby, syscalls, Анализ и проектирование систем, Блог компании Mail.Ru Group, высокая производительность, никто не читает теги, оптимизация, Проектирование и рефакторинг, метки: syscalls
Эта публикация — логическое продолжение поста «Как настройка переменной окружения TZ позволяет избежать тысяч системных вызовов». Здесь мы рассмотрим характерную ситуацию, когда микрооптимизации (например, удаление системного вызова) очень сильно влияют на производительность.
Как Discord индексирует миллиарды сообщений
2017-03-27 в 8:17, admin, рубрики: cassandra, Discord, elasticsearch, Google Cloud Platform, lucene, open source, redis, solr, Анализ и проектирование систем, высокая производительность, Системы обмена сообщениями, метки: Discord
Миллионы пользователей ежемесячно отправляют миллиарды сообщений в Discord. Поиск в этих сообщениях стал одной из самых востребованных функций, какие мы сделали. Да будет поиск!
Требования
- Экономически эффективный: Основное взаимодействие пользователя с Discord — это наш текстовый и голосовой чат. Поиск — вспомогательная функция, и стоимость инфраструктуры должна отражать это. В идеале это значит, что поиск не должен стоить дороже, чем фактическое хранение сообщений.
- Быстрый и интуитивно понятный: Все создаваемые нами функции должны быть быстрыми и интуитивными, в том числе поиск. Он должен выглядеть и ощущаться по высшему стандарту.
- Самовосстановление: У нас нет отдела DevOps (пока), так что поиск должен выдерживать сбои с минимальным человеческим вмешательством или вообще без него.
- Линейно масштабируемый: Как и с хранением сообщений, увеличение ёмкости поисковой инфраструктуры должно предусматривать добавление нодов.
- Ленивая индексация: Не все пользуются поиском — мы не должны индексировать сообщения, пока кто-то не попытается хотя бы раз их найти. Вдобавок, после сбоя индекса должна быть возможность переиндексации серверов на лету.
Постепенное наращивание функционала в сложных информационных системах
2017-03-26 в 3:19, admin, рубрики: Анализ и проектирование систем, метки: Внедрение, информационная системаХочу предложить организациям, занимающимся разработкой сложных информационных систем, типа документооборота (СЭД), способ внедрения своих продуктов в организации клиентов. А именно, постепенное наращивание функционала для каждого сотрудника.
Читать полностью »
Элементы, универсумы и регистры правил
2017-03-25 в 15:16, admin, рубрики: sql, Алгоритмы, Анализ и проектирование систем, атрибуты отношений, выборка данных, Значения, множества, Программирование, регистры правил, релевантность, метки: Значения"Дуэли запрещены в субботу, воскресенье и остальные дни недели."
Речь в статье пойдет о некоторых нюансах операции выборки данных. Эта довольно востребованная в информационных системах операция сводится фактически к определению принадлежности значений (элементов) множествам. Табличная функция, содержащая значения-множества, называется регистром правил. При наличии нескольких множеств, которым принадлежит элемент, возникает вопрос определения наиболее релевантного из них. Вопросам оценки релевантности выборки данных посвящена первая часть работы.
Забегая вперед, укажем, что основным результатом (многолетних наблюдений) является то, что в реляционных отношениях следует учитывать род атрибутов — являются ли значения атрибута отношения конкретными (элементами) или абстрактными (множествами). При этом в операции выборки данных атрибуты входной таблицы и таблицы, к которой обращаются, должны быть разных родов. Более подробно об этом — во 2-й части.
И еще одна оговорка. Там, где приходилось выбирать между простотой (понятностью) описания и его строгостью, автор старался выбирать простоту (хотя слов, в том числе не всегда понятных, все равно набралось много).