Pull to refresh
-2
0
jakobz @jakobz

User

Send message

Вариант с JSON - лучше. Потому что с ним понятно как работать, скажем - генерировать из заданных на UI фильтров. Даже если надо будет руками хардкодать запросы в большом количестве - то правильнее будет сделать eDSL, а не впихивать SQL строками в коде.

Честно говоря, непонятно почему сами БД не принимают какой-то машино-читаемый формат, а-ля AST. Потому что в большинстве случаев, запросы к ним тоже генерируют - те же ORM, всякие репортинговые системы а-ля Power BI. И непонятно зачем двум программам разговаривать на языке, придуманном даже не для программистов.

У одной строчки - 27 состояний, лезет а 5 бит. Делаем табличку на 27 значений, пихаем в 3 числа по 5 бит, получаем 15 бит.

Я в свое штуке делал to be, через оверрайд текущего состояния тупо хард-кодом. Просто поверх мерджился патч, который перешибал часть текущего состояни. И у каждого квадратика и стрелочки - был статус planned и retire. И они рисовались зеленым и красным.

Я как-то делал штуку, которая по метаданным про то же - делает UI, который все это рисует через graphvis. С фильтрами по сервисам и прочему. И можно было, скажем, сделать диаграмму одного сервиса с интеграциями, дальше тыкнуть в какой-нибудь соседний, и сказать «покажи еще его интеграции». Или посмотреть кто юзает определенный топик.

Меня улыбнул кирпичик «postgresql adapter”. Сразу представил типичное бизнес-приложение, написанное по канонам. Обычно там вся логика в дата-леере, а все остальное - красивое, разделенное по слоям, и покрытое тестами - просто перекладывает все между уровнями.

Я вот так и не смог понять про какую такую бизнес-логику все в таких статьях говорят, когда ее отделяют от данных. У меня в бекендах 90% логики - это как данные положить и достать из БД, по дороге денормализуя, кешируя, агрегируя, проверяя права, и т.п. Как отделить такую логику от слоя доступа к данным, не упоров производительность - я за все годы так и не понял. Все статьи про архитектуру строятся на том что это как-то сделать можно, и поэтому для меня выглядят бессмысленными.

А версии реакта и других зависимостей - синхронизированы между приложениями и общими пакетами, или могут быть разными?

Мы как-то на наших задачах смотрели - uuid был в два раза медленнее на селектах. Ну оно и понятно - он в два раза больше, а в обычной такой OLTP-базе у тебя половина колонок - это id (ведь кроме PK есть куча FK). А размер строки - влияет буквально на все.

Т.к. БД обычно - узкое место, как-то стрёмно прям 2х терять от входа.

Снаружи системы - во внешних API и кафках, все равно обычно мешанина - где guid, где long. Для людей вообще email могут быть. И мы все равно об отдельную табличку маппим с внешних id (которые для универсальности вообще varchar) на внутренние.

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

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

Чуть более чем все CRM/CMS/ERP и прочее из трех букв работает на метаданных. Как и большая часть доморощенных систем где много разношерстных форм и таблиц.

Мне рассказывали, на рубеже 90х и 2000х, про контору, у которой сервер с 1С стоял в Газеле за офисом. Если проверка - газель просто уезжает, перемещая данные со скоростью 60км/ч

За 3-4 часа проходится до ракеты легко, по инструкции от спидранеров.

Во всех статьях, и фреймворках типа single-spa, предполагаются пошаренные между микрофронтами библиотеки, билд-тулчейн, и даже версия реакта. Как по мне, это нивелирует все плюсы микрофронтов - возможность делать куски приложения отдельными командами независимо. Независимо обновляться, менять стек под свои нужды. Например - накидать какую-нибудь админку, и потом вообще там разработку поставить на паузу. Или наоборот - user-facing часть переписать на next.js. Или, банально, обновлять реакт или библиотеку компонент по частям.

А разделить по фичам приложение на одном стеке - проще через те же чанки вебпака, и eslint-рулы - чтобы зависимости между папками с фичами не плодили.

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

Т.е. полноценное решение я вижу как-то так:

  • качаете GQL схему (в виде результата introspection query) в файл, кладете его в репу

  • запускаете команду из пакета X, у вас получается набор cs-файлов под эту схему

  • подключаете твою библиотеку

  • можете ходить в нужный GQL-API, с автокомплитом в IDE, строго-типизированно

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

  • уметь писать запрос сразу в сокет (минуя построение большой UTF-16 строки в памяти, и конвертацию ее дальше в UTF-8 - как теперь делает тот же встроенный JSON-сериализатор)

  • сделать некие pre-build queries - возможность написать (параметризированный) запрос, вызвать ему .Build(), и положить в какую-нибудь static-переменную.

Класс, то что нужно чтобы в graphql ходить из .net. Пара вопросов:

  • чем-то можно классы из gql-схемы сгенерить? Ну, чтобы не руками писать.

  • что с перформансом? Получается как-нибудь строки с запросами кэшировать, или хотя-бы прям в utf8 сразу писать?

Ставить же надо. Всем кто участвует. Т.е. порог входа великоват для задачи. Плюс всем участвующим учиться пользоваться. По этой же причине онлайн-варианты тоже не прижились.

Мне часто в экселе приходится прикидывать проекты - разбивать на фазы, задачи (work breakdown structure), делать оценки, раскидывать ресурсы. В общем - то для чего ms project. Но MS Project использовать не выходит - он не у всех есть, сложно вместе работать, показывать, отсылать куда-то.

И я пришел к тому, что делаю «Формат 6. Путь к листу (только листы)». И на соседний лист кидаю pivot (сводная таблица?) - где можно накрутить и иерархию, и даже и более хитрое.

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

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

Надеюсь что тулы вроде Airtables когда-нибудь победят эксель. Впрочем, я и там пока не видел чтобы нормально сделали иерархии, но там хотя-бы понятно как это можно приделать.

Кстати, а что про встроенные в эксель иерархии? Там же есть какая-то группировка строк. Я как-то потыкал, но вообще не понял ничего…

Так большинство библиотечных хуков и сейчас возвращает объект, а не массив. Вроде как.

С параметрами функций - надо все-таки потоньше. Хорошая идея сразу принимать объект options, если начинаются всякие необязательные параметры. Но можно обязательные 1-2 и отдельными оставить.

Я тут недавно r-type на эмуляторе проходил. С вечными жизнями. После изрядного задротства в ту же hydorah. Вот не знаю кто и как ее тогда мог по-честному пройти.

В начале 2000х верстал. На компах было ну может 16-32 метра памяти, windows NT, pagemaker 6. В память все картинки в нужных 600dpi не лезли - грузилась превьюшка, или вообще шоткатом на серые квадратики переключали. Текст - если отзумить - тоже квадратиками. Все это был вроде удобно, и не помню чтобы тормозило.

Картинки - в фотошопе, он тоже может (мог?) работать подгружая куски с диска. Обработка была не быстрая, но превью всякие выручали.

Дальше все это «выводится» в здоровенный postscript-файл, который векторный - т.е. весит примерно как все картинки в нём. Он пишется на винт в съемной коробке, или магнитооптику/zip, и несётся в фотонабор.

Фотонабор - это такой принтер на плёнке, метра 3 на 2, на метр высотой, ценой в 100килобаксов. Печатает на пленке шириной в метр, лазером, с разрешением в 6000dpi минимум. Потому что он прям вот растр «пискелями» рисует - эти самые кружочки, которых 120-180 на дюйм, которые позволяют на фотках полутона передавать. В него заливается ps-файл с компа, он думает - порой долго, из него вылезает пленка.

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

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

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

Есть куча проектов, которые в одной репе разрабатываются спокойно сотнями людей. ОС (Linux, Windows), десктопные приложения (Chromium), всякие БД и прочие кубернетесы. Просто куча примеров.

И часто это проекты посложнее этих наших всяких веб-приложений - десктоп или ОС писать посложнее веба.

Также есть много успешных бизнесов, которые пишут (в т.ч. и на хабре), как распиливали монолит на части. Часто - когда уже стали большие и богатые. А вот обратного - бизнесов, которые пишут "мы начали с микросервисов, и пришли к успеху" - я что-то не очень вижу.

В общем, с чего все взяли, что если код разложить по репам и обмазать докером - это путь к успеху? С чего все взяли, что если код сложить в одну репу - будет помойка?. Внутри монорепы можно точно также построить границы, обозначить API между ними. Если только от того, что с монорепой на порядочек деньги можно не тратить, а когда много реп - ты вынужден нанять девопсов и строить хоть какие-то API.

Делать микросервисы на проекте от входа - в 90% случаев - самоубийство для бизнеса:

  • микросервисное приложение предельно сложно рефакторить. Цена ошибки типа "мы не угадали как попилить на микросервисы" - предельно высока. А когда только начинают - в большинстве случаев даже не знают чего хотят и куда приедем

  • несмотря на все девопсы, разработка все равно будет дороже. Хотя-бы потому что на надо кому-то этим девопсом заниматься.

  • весь это цирк с breaking changes в API - либо деплоим все одновременно, либо заморачиваемся backward compatibility в API (на старте проекта, да, когда все старые версии все равно выкинутся)

  • пока эти все девопсы устаканятся, пока это все поедет - конкуренты уже на луне будут

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

Information

Rating
3,517-th
Location
Россия
Date of birth
Registered
Activity

Specialization

Fullstack Developer, Software Architect
Lead
From 500,000 ₽
JavaScript
CSS
React
TypeScript
.NET Core
PostgreSQL
Entity Framework
Microsoft SQL Server