На картридже, вместо обычной ROM, для тайлов была RAM. Там где рисуется 3D - раскладывались уникальные тайлы, и CPU мог в них рисовать. Т.е. получался эдакий нелинейный буфер кадра, куда можно рисовать попиксельно.
public static int Count<T>(this IEnumerable<T> seq) {
switch (seq) {
case Array a: return a.Length;
case ICollection<T> c: return c.Count;
case IReadOnlyCollection<T> c: return c.Count;
// Matches if seq is not null
case IEnumerable<T> _: return seq.Count();
// Discard pattern when seq is null
default: return 0;
}
}
Плохо в null-terminated strings даже не лишние байты и плохие алгоритмы. А то, что одно из 256 значений байта «заныкали». И дальше вот эти все ascii, http, json, регекспы, бесконечный парсинг и сериализация. Только потому что в си последовательность байт где ноль нельзя - отличается от последовательности байт, где ноль - можно.
Мне вот недавно потребовалось сделать на mssql аналог intarray из postgres. Это когда в колонку пишется массив int-ов, и дальше можно фильтровать выражениями типа (1|3)&4&5. И мы расшибли лоб, и так ничего вменяемого и не придумали.
Важна не эта конкретная задача, а то что в mssql если чего-то нет, то это даже сколхозить не из чего: типы данных не добавить, даже массив положить в колонку не во что, и передать в функцию нельзя. T-SQL - просто издевательство, а альтернатив нет. Что-то можно изображать на CLR, но облачные mssql в него не умеют.
И вроде вот они данные, лежат в правильных b-tree как надо, алгоритмы понятно какие надо сделать. Но подлезть не дают.
Обидно даже за нее - т.к. на низком уровне она хорошо сделана.
А зачем вообще тестировать каждую такую форму? Покрыть тестами всякие простые и сложные сочетания компонентов в форме - понятно. Добавить валидацию созданных форм - орфографию, какие-то еще проверки - понятно. Но зачем созданные формы потом тестировать то, что в них может ломаться?
>асинк эвейты это специализированное решение для конкретного кейса, и в рамках этого кейса они лучше генераторов.
Как минимум, await всегда откладывает продолжение на следующий тик, даже если вернуть что-то синхронно. А это было бы полезно, скажем, на беке - чтобы задачу, которая часто может выполниться целиком синхронно (достать все из кешей, например) - не кидать в конец очереди, увеличивая latency, и держа лишнее время все нужные ей ресурсы.
Интересно было бы, кстати, посмотреть на тесты перформанса для этой Effection. А то может оно еще и быстрее работает, чем нативные промисы - как раз за счет этого.
Вот как вот в JS умудрились сделать await-ы хуже, чем получается сделать то же на yield? И зачем вообще этот async делали, если сразу было понятно, что на yield можно запилить любые монадки?
А почему человечество не может придумать какой-то стандарт на ABI, чтобы у был способ запускать бинари на любой ОС? Хотя-бы для серверного софта. Там же вроде многого не надо - сокеты, треды, и файловая система. Веб же вон есть, и там 100500 стандартных API - вплоть до WebGL всяких, и гироскопов на мобилках. А в типичных применениях докера - все сильно проще же. Что я тут не понимаю? Зачем там привязка ко всем накопившимся API ядра того же линукса?
Ну я вот как-то 18 лет работы обхожусь без скриптов на баше. И даже без grep-а и пайпов команд друг в друга. Понятно что в command line вызвать git/openssh/ping/docker/etc - я могу. Но если что-то чуть сложнее - беру просто язык программирования, на котором все остальное в проекте, и на нем делаешь на нём всё что нужно. В человеческих языках, кроме grep-ов по файлам - можно и в API сходить, и сервак выставить, и в БД сходить, и алгоритм какой нетривиальный сделать. Не говоря уже что можно делать функции, циклы и переменные без каких-то нечеловеческих страданий.
Реализации GraphQL для .NET и Java обходят запрос в ширину, по крайней мере насколько я понял. Потому что ну зачем использовать этот хак на промисах и event loop, если можно тоже самое сделать явно, и это будет даже проще.
Шаблон DataLoader - он хорош чтобы батчить тогда, когда у сложно переписать алгоритм, который дёргает какие-нибудь походы в БД или API. Скажем, если бизнес-логика утыкана всякими getUserById, и нет возможности это поменять. Плюс, он вообще возможен только в однопоточной среде (т.е. считай только в ноде).
Отлично эта проблема решилась бы монадами - скажем, если бы в JS, и можно было бы написать свой promise и использовать с ним await. К слову, такое можно сделать на yield-ах.
В общем, как часто бывает - придумали хак, распиарили, и через 10 лет поняли что он вообще был не нужен.
Вариант с JSON - лучше. Потому что с ним понятно как работать, скажем - генерировать из заданных на UI фильтров. Даже если надо будет руками хардкодать запросы в большом количестве - то правильнее будет сделать eDSL, а не впихивать SQL строками в коде.
Честно говоря, непонятно почему сами БД не принимают какой-то машино-читаемый формат, а-ля AST. Потому что в большинстве случаев, запросы к ним тоже генерируют - те же ORM, всякие репортинговые системы а-ля Power BI. И непонятно зачем двум программам разговаривать на языке, придуманном даже не для программистов.
Я в свое штуке делал 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км/ч
На картридже, вместо обычной ROM, для тайлов была RAM. Там где рисуется 3D - раскладывались уникальные тайлы, и CPU мог в них рисовать. Т.е. получался эдакий нелинейный буфер кадра, куда можно рисовать попиксельно.
https://elite.bbcelite.com/deep_dives/drawing_vector_graphics_using_nes_tiles.html
Т.е. вот так низя? :(((
Плохо в null-terminated strings даже не лишние байты и плохие алгоритмы. А то, что одно из 256 значений байта «заныкали». И дальше вот эти все ascii, http, json, регекспы, бесконечный парсинг и сериализация. Только потому что в си последовательность байт где ноль нельзя - отличается от последовательности байт, где ноль - можно.
Мне вот недавно потребовалось сделать на mssql аналог intarray из postgres. Это когда в колонку пишется массив int-ов, и дальше можно фильтровать выражениями типа (1|3)&4&5. И мы расшибли лоб, и так ничего вменяемого и не придумали.
Важна не эта конкретная задача, а то что в mssql если чего-то нет, то это даже сколхозить не из чего: типы данных не добавить, даже массив положить в колонку не во что, и передать в функцию нельзя. T-SQL - просто издевательство, а альтернатив нет. Что-то можно изображать на CLR, но облачные mssql в него не умеют.
И вроде вот они данные, лежат в правильных b-tree как надо, алгоритмы понятно какие надо сделать. Но подлезть не дают.
Обидно даже за нее - т.к. на низком уровне она хорошо сделана.
А зачем вообще тестировать каждую такую форму? Покрыть тестами всякие простые и сложные сочетания компонентов в форме - понятно. Добавить валидацию созданных форм - орфографию, какие-то еще проверки - понятно. Но зачем созданные формы потом тестировать то, что в них может ломаться?
>асинк эвейты это специализированное решение для конкретного кейса, и в рамках этого кейса они лучше генераторов.
Как минимум, await всегда откладывает продолжение на следующий тик, даже если вернуть что-то синхронно. А это было бы полезно, скажем, на беке - чтобы задачу, которая часто может выполниться целиком синхронно (достать все из кешей, например) - не кидать в конец очереди, увеличивая latency, и держа лишнее время все нужные ей ресурсы.
Интересно было бы, кстати, посмотреть на тесты перформанса для этой Effection. А то может оно еще и быстрее работает, чем нативные промисы - как раз за счет этого.
Вот как вот в JS умудрились сделать await-ы хуже, чем получается сделать то же на yield? И зачем вообще этот async делали, если сразу было понятно, что на yield можно запилить любые монадки?
А почему человечество не может придумать какой-то стандарт на ABI, чтобы у был способ запускать бинари на любой ОС? Хотя-бы для серверного софта. Там же вроде многого не надо - сокеты, треды, и файловая система. Веб же вон есть, и там 100500 стандартных API - вплоть до WebGL всяких, и гироскопов на мобилках. А в типичных применениях докера - все сильно проще же. Что я тут не понимаю? Зачем там привязка ко всем накопившимся API ядра того же линукса?
Ну я вот как-то 18 лет работы обхожусь без скриптов на баше. И даже без grep-а и пайпов команд друг в друга. Понятно что в command line вызвать git/openssh/ping/docker/etc - я могу. Но если что-то чуть сложнее - беру просто язык программирования, на котором все остальное в проекте, и на нем делаешь на нём всё что нужно. В человеческих языках, кроме grep-ов по файлам - можно и в API сходить, и сервак выставить, и в БД сходить, и алгоритм какой нетривиальный сделать. Не говоря уже что можно делать функции, циклы и переменные без каких-то нечеловеческих страданий.
А зачем знать bash?
Реализации GraphQL для .NET и Java обходят запрос в ширину, по крайней мере насколько я понял. Потому что ну зачем использовать этот хак на промисах и event loop, если можно тоже самое сделать явно, и это будет даже проще.
Шаблон DataLoader - он хорош чтобы батчить тогда, когда у сложно переписать алгоритм, который дёргает какие-нибудь походы в БД или API. Скажем, если бизнес-логика утыкана всякими getUserById, и нет возможности это поменять. Плюс, он вообще возможен только в однопоточной среде (т.е. считай только в ноде).
Отлично эта проблема решилась бы монадами - скажем, если бы в JS, и можно было бы написать свой promise и использовать с ним await. К слову, такое можно сделать на yield-ах.
В общем, как часто бывает - придумали хак, распиарили, и через 10 лет поняли что он вообще был не нужен.
Вариант с 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км/ч