One morning you wake up find out you have access to God’s developer console. What’s the first thing you do with this power?
Discussion
♦ 154 + W 479 & Share
^ BEST COMMENTS ▼
I like forks • 5h
hehe3301 • 7h
sudo rm -rf oceans/*/contents/
*.plástic
sudo rm -rf people/*/*.cáncer sudo rm -rf v
Та часть где происходит вся "магия" и юзерам не видна - полная жопа
"В проприетарной реализации 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, но с несколькими проприентарными кусками.
Что касается "всё это уже давно не актуально" - ну так статья 2014 года. Я просто привёл пример "полной жопы" в контексте frontend-backend. Ещё хотел прикрепить картинку с башней, красивой наверху с идеально подогнанными кирпичиками, и костылями внизу, на которых она стоит, но не нашёл. Просто эта картинка идеально характеризует fglrx: там приходила новая команда программистов и писала прослойку поверх существующего кода, чтобы не разбираться, и так несколько раз.
У меня вообще складывается ощущение, что теперь мы пишем не одно большое приложение, а сразу два.
Большой и сложный бэкенд с кучей логики, интеграций итд итп, а сверху не менее большой и сложный spa на каком-нибудь фрэймворке.
Бд на postgres, две таблицы. В первой id и тип сущности. Вторая связана с первой один ко многим и в ней тип свойства и его значение. Сверху все густо обмазано хранимками с бизнес- логикой.
Затем бэкенд-прослойка на руби и фронтенд соплями на jquery.
Некий сумрачный гений это наговнокодил, получил деньги и свалил.
К тому времени, как меня наняли, половина запросов в бд занимала уже десятки секунд.
Это был травмирующий опыт, но на год работой этот парень меня обеспечил.
Нужно получить сущность А по id. Получаем из бд запись из таблицы сущностей и все связанные с ней записи из таблицы свойств. Если свойство оказалось в свою очередь сущностью - делаем для него аналогичную операцию и так далее.
Ну то есть ебаный велосипед, который решается нормальной схемой в бд (я в итоге этот ужас разбил на 3-4 десятка таблиц) + ормкой с нормальными navigation property/lazy loading.
Но простых запросах оно еще жило, а не генерации отчетов, для которой нужно половину бд перелопатить, умирало.
Это кто сказал? Откуда вообще взялась эта страсть к хуевой туче хранимых процедур?
Потому что только так можно избежать избыточных запросов и дать наконец-то базе данных построить нормальный execution plan или выдать рекомендации - я даже не рассматриваю вариант, что говнокодеры смогут продумать его заранее, но пусть хотя бы не мешают.
Часть говнокодеров не понимает как работают селекторы в CSS, потому что "чо тут понимать" и херачат стили абы как, густо обмазываясь !important-ами и дублируя все на свете по пять раз.
Часть радостно тащит в любой проект какое-нибудь монстроидальное говно типа бутстрапа и небуляра, потому что им лень прописать пару стилей, а то и сразу несколько CSS-фреймворков, а потом героически пытается сражаться с ними и их конфликтами.
Есть особо ебанутые - те тащат в Ангуляр какое-нибудь паскудство типа jquery и специально выводят его из контроля зоны, а потом пол-проекта засрано попытками заставить Ангуляр определять изменения.
Есть любители халявы - ну, тут все как и в остальных областях, находят какую-нибудь хрень на гитхабе, которая сэкономит им час работы, пихают всюду, а потом выясняется, что там 100500 багов, а автор хуй забил на проект 3 года назад.
TypeScript - чудесный инструмент с очень гибкой и мощной системой типов, но что говорят ему говнокодеры? "Any"!