Кто бы это мне раньше показал, гуманитарию, и не пришлось бы тратить время, чтобы понять
27.04.2020, 18:59
На самом деле, современный уклад дел таков, что все как раз наоборот.
Почему-то вспомнился рассказ программиста из Valve, который в 2012 году осуществлял порты игр на движке Source1 на Linux и OpenGL.
"В проприетарной реализации OpenGL от ATi некоторые расширения существуют только на бумаге. Этот факт хорошо дополняет высказанное им мнение о несовершенстве самой спецификации OpenGL (например десятки вариантов одного только glVertexAttrib). Зато другие расширения соответствуют спецификациям гораздо точнее, чем на NVIDIA. Большинство людей знает о факте неполной реализации, и не знает о факте более точному следованию спецификации в некоторых местах. Из-за этого бывали случаи, когда программист пишет и отлаживает код на NVIDIA, а когда на Catalyst его код не работает, он думает что это баг драйвера. Потом, когда оказывается, что драйвер fglrx сработал как надо, а NVIDIA - нет, все страшно удивляются.
Update из 2020: сейчас NVIDIA пофиксила расхождения со спецификацией, чтобы в системах с гибридной графикой могли работать обе реализации OpenGL одновременно (Mesa и NVIDIA). Возможно даже над одной сценой смогут работать (DMA-BUF), но это в будущем.
Он считает что ATi силён в официальном OpenGL, но слаб в сторонних расширениях. А ещё, что редко при обновлении драйвера fglrx что-нибудь не сломают, а потом прилетает hotfix и сломает что-нибудь ещё. А ещё в Catalyst слой на слое лежит быдлокод программистов, которые давно не работают в ATi. А ещё он предполагает, что fglrx определяет, какая игра запущена, чтобы отключать конкретно для неё наиболее забагованные расширения OpenGL.
А ещё он выполнял один и тот же код несколько раз, и получал разные результаты: первый раз нормально, второй раз массово повреждались буферы.
Плюсы реализации OpenGL от ATi: более точное следование спецификации OpenGL, и много утилит разработки и отладки OpenGL. Например, если бы ATi когда-то не сделала togl (враппер из Direct3D в OpenGL), портирование Source1 заняло бы гораздо больше времени".
Если что, вот оригинал:
http://richg42.blogspot.com/2014/05/things-that-drive-me-nuts-about-opengl.html
http://richg42.blogspot.com/2014/05/the-truth-on-opengl-driver-quality.html
"В проприетарной реализации OpenGL от ATi некоторые расширения существуют только на бумаге. Этот факт хорошо дополняет высказанное им мнение о несовершенстве самой спецификации OpenGL (например десятки вариантов одного только glVertexAttrib). Зато другие расширения соответствуют спецификациям гораздо точнее, чем на NVIDIA. Большинство людей знает о факте неполной реализации, и не знает о факте более точному следованию спецификации в некоторых местах. Из-за этого бывали случаи, когда программист пишет и отлаживает код на NVIDIA, а когда на Catalyst его код не работает, он думает что это баг драйвера. Потом, когда оказывается, что драйвер fglrx сработал как надо, а NVIDIA - нет, все страшно удивляются.
Update из 2020: сейчас NVIDIA пофиксила расхождения со спецификацией, чтобы в системах с гибридной графикой могли работать обе реализации OpenGL одновременно (Mesa и NVIDIA). Возможно даже над одной сценой смогут работать (DMA-BUF), но это в будущем.
Он считает что ATi силён в официальном OpenGL, но слаб в сторонних расширениях. А ещё, что редко при обновлении драйвера fglrx что-нибудь не сломают, а потом прилетает hotfix и сломает что-нибудь ещё. А ещё в Catalyst слой на слое лежит быдлокод программистов, которые давно не работают в ATi. А ещё он предполагает, что fglrx определяет, какая игра запущена, чтобы отключать конкретно для неё наиболее забагованные расширения OpenGL.
А ещё он выполнял один и тот же код несколько раз, и получал разные результаты: первый раз нормально, второй раз массово повреждались буферы.
Плюсы реализации OpenGL от ATi: более точное следование спецификации OpenGL, и много утилит разработки и отладки OpenGL. Например, если бы ATi когда-то не сделала togl (враппер из Direct3D в OpenGL), портирование Source1 заняло бы гораздо больше времени".
Если что, вот оригинал:
http://richg42.blogspot.com/2014/05/things-that-drive-me-nuts-about-opengl.html
http://richg42.blogspot.com/2014/05/the-truth-on-opengl-driver-quality.html
Оффтопом.
Вроде как fglrx, catalist и прочее - старое говно. Под новые карты (Polaris и выше? Или даже раньше?) сейчас у AMD есть нормальные открытые дрова, которая она сама и разрабатывает aka amdgpu, которые входят в состав mesa, т.е. присутствуют, скорее всего, в любом свежем дистре. Есть еще amdgpu-pro, который тот же amdgpu, но с несколькими проприентарными кусками.
Вроде как fglrx, catalist и прочее - старое говно. Под новые карты (Polaris и выше? Или даже раньше?) сейчас у AMD есть нормальные открытые дрова, которая она сама и разрабатывает aka amdgpu, которые входят в состав mesa, т.е. присутствуют, скорее всего, в любом свежем дистре. Есть еще amdgpu-pro, который тот же amdgpu, но с несколькими проприентарными кусками.
fglrx состоял из нескольких компонентов: драйвер ядра fglrx.ko, драйвер "иксов", файл libGL.so.1. Сейчас fglrx не существует (последняя версия запускается только с X-Server 1.17), теперь есть два драйвера: amdgpu и amdgpu-pro. В первом все эти три компонента - компоненты с открытым исходным кодом. Во втором, первые два компонента - те же самые, что и в открытом драйвере. А третий - закрытый. libGL из admgpu-pro это продолжение развития fglrx.
Что касается "всё это уже давно не актуально" - ну так статья 2014 года. Я просто привёл пример "полной жопы" в контексте frontend-backend. Ещё хотел прикрепить картинку с башней, красивой наверху с идеально подогнанными кирпичиками, и костылями внизу, на которых она стоит, но не нашёл. Просто эта картинка идеально характеризует fglrx: там приходила новая команда программистов и писала прослойку поверх существующего кода, чтобы не разбираться, и так несколько раз.
Что касается "всё это уже давно не актуально" - ну так статья 2014 года. Я просто привёл пример "полной жопы" в контексте frontend-backend. Ещё хотел прикрепить картинку с башней, красивой наверху с идеально подогнанными кирпичиками, и костылями внизу, на которых она стоит, но не нашёл. Просто эта картинка идеально характеризует fglrx: там приходила новая команда программистов и писала прослойку поверх существующего кода, чтобы не разбираться, и так несколько раз.
просто сейчас фронт получил свой бэк - шадов дом, мильёны скриптов и т.п., и если для юзера всё ещё более-менее, если комп новый и быстрый, то в отладчике там лютый пиздец творится
Есть третий слой -- 100500 SP на БД. Практически всегда есть процедуры удаления какого-нибудь врехнего родительского элемента тянущего за собой до сотни других сущностей, половину из которых нужно проверить на возможность удаления. Но самый ад и израиль начинается когда в SP засунули ВСЮ бизнеслогику определеного бизнес процесса, в ней дохренища вызовов других процедур, и гребаный лабиринт из if-return.
Лет 5 назад меня наняли переписать полностью один проект.
Бд на postgres, две таблицы. В первой id и тип сущности. Вторая связана с первой один ко многим и в ней тип свойства и его значение. Сверху все густо обмазано хранимками с бизнес- логикой.
Затем бэкенд-прослойка на руби и фронтенд соплями на jquery.
Некий сумрачный гений это наговнокодил, получил деньги и свалил.
К тому времени, как меня наняли, половина запросов в бд занимала уже десятки секунд.
Это был травмирующий опыт, но на год работой этот парень меня обеспечил.
Бд на postgres, две таблицы. В первой id и тип сущности. Вторая связана с первой один ко многим и в ней тип свойства и его значение. Сверху все густо обмазано хранимками с бизнес- логикой.
Затем бэкенд-прослойка на руби и фронтенд соплями на jquery.
Некий сумрачный гений это наговнокодил, получил деньги и свалил.
К тому времени, как меня наняли, половина запросов в бд занимала уже десятки секунд.
Это был травмирующий опыт, но на год работой этот парень меня обеспечил.
Какие-то индексы там были, но беда была именно в этих двух таблицах.
Нужно получить сущность А по id. Получаем из бд запись из таблицы сущностей и все связанные с ней записи из таблицы свойств. Если свойство оказалось в свою очередь сущностью - делаем для него аналогичную операцию и так далее.
Ну то есть ебаный велосипед, который решается нормальной схемой в бд (я в итоге этот ужас разбил на 3-4 десятка таблиц) + ормкой с нормальными navigation property/lazy loading.
Но простых запросах оно еще жило, а не генерации отчетов, для которой нужно половину бд перелопатить, умирало.
Нужно получить сущность А по id. Получаем из бд запись из таблицы сущностей и все связанные с ней записи из таблицы свойств. Если свойство оказалось в свою очередь сущностью - делаем для него аналогичную операцию и так далее.
Ну то есть ебаный велосипед, который решается нормальной схемой в бд (я в итоге этот ужас разбил на 3-4 десятка таблиц) + ормкой с нормальными navigation property/lazy loading.
Но простых запросах оно еще жило, а не генерации отчетов, для которой нужно половину бд перелопатить, умирало.
Нет, это в случае, если ты все делаешь правильно. Логика работы с БД должна быть реализована в БД. А современные клиентские фреймворки убрали необходимость отдавать с сервера что-то кроме ответа БД. Вот и осталась за бэком только пара ролей - следить за авторизацией или делать те запросы к сторонним ресурсам, которые нельзя доверить клиенту по вопросам безопасности.
Это Best Practices говорят последние лет 20.
Потому что только так можно избежать избыточных запросов и дать наконец-то базе данных построить нормальный execution plan или выдать рекомендации - я даже не рассматриваю вариант, что говнокодеры смогут продумать его заранее, но пусть хотя бы не мешают.
Потому что только так можно избежать избыточных запросов и дать наконец-то базе данных построить нормальный execution plan или выдать рекомендации - я даже не рассматриваю вариант, что говнокодеры смогут продумать его заранее, но пусть хотя бы не мешают.
Ой да ладно. Надо писать не "фронтенд", а "то, что рисует браузер на экране". Потому что даже во фронте за пикселями на экране скрывается ад и погибель: километры HTML/CSS с хаками, призванными обойти врожденные болезни этой системы разметки, костыли для поддержки говнобраузеров, километры JS-кода на всяких ангулярах и реактах, чтобы делать ваши охуенные интерактивные сраные приложения, три миллиарда тонн полифилов и кодогенерации. А потом еще десяток трекеров, метрик, аналитик и рекламных скриптов. Неет, фронт - это какое-то хтоническое поделие, которое эволюционировало-эволюционировало и пришло к текущему виду.
Врожденная болезнь системы - это низкий уровень вхождения.
Часть говнокодеров не понимает как работают селекторы в CSS, потому что "чо тут понимать" и херачат стили абы как, густо обмазываясь !important-ами и дублируя все на свете по пять раз.
Часть радостно тащит в любой проект какое-нибудь монстроидальное говно типа бутстрапа и небуляра, потому что им лень прописать пару стилей, а то и сразу несколько CSS-фреймворков, а потом героически пытается сражаться с ними и их конфликтами.
Есть особо ебанутые - те тащат в Ангуляр какое-нибудь паскудство типа jquery и специально выводят его из контроля зоны, а потом пол-проекта засрано попытками заставить Ангуляр определять изменения.
Есть любители халявы - ну, тут все как и в остальных областях, находят какую-нибудь хрень на гитхабе, которая сэкономит им час работы, пихают всюду, а потом выясняется, что там 100500 багов, а автор хуй забил на проект 3 года назад.
TypeScript - чудесный инструмент с очень гибкой и мощной системой типов, но что говорят ему говнокодеры? "Any"!
Часть говнокодеров не понимает как работают селекторы в CSS, потому что "чо тут понимать" и херачат стили абы как, густо обмазываясь !important-ами и дублируя все на свете по пять раз.
Часть радостно тащит в любой проект какое-нибудь монстроидальное говно типа бутстрапа и небуляра, потому что им лень прописать пару стилей, а то и сразу несколько CSS-фреймворков, а потом героически пытается сражаться с ними и их конфликтами.
Есть особо ебанутые - те тащат в Ангуляр какое-нибудь паскудство типа jquery и специально выводят его из контроля зоны, а потом пол-проекта засрано попытками заставить Ангуляр определять изменения.
Есть любители халявы - ну, тут все как и в остальных областях, находят какую-нибудь хрень на гитхабе, которая сэкономит им час работы, пихают всюду, а потом выясняется, что там 100500 багов, а автор хуй забил на проект 3 года назад.
TypeScript - чудесный инструмент с очень гибкой и мощной системой типов, но что говорят ему говнокодеры? "Any"!
всё прах
Чтобы написать коммент, необходимо залогиниться
