?

Log in

No account? Create an account

GraphQL

авг. 15, 2019 | 01:56 am

Посмотрел ролик: https://www.youtube.com/watch?v=783ccP__No8

Подумал что IT Science - больше не про N(n), а приведение масс людей в движение в правильном направлении.

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

Осознал, что даже такая простая хуйня как GraphQL, за 7 лет, типа еще новая для многих. Сотни лямов баксов инвестиций.

Если что, GraphQL, вообще-то - это способ закинуть весьма уёбищный аппликативный функтор считаться на сервере. Причем авторы - этого не особо понимают (хотя может просто хитрые).

Ну и повангую:
- дураку уже очевидно, что идея декларативного языка, в котором можно из O(N^4) автомагически сделать O(log(N)) - токсична. SQL должен умереть.
- понятно, что надо эволюцию, а не революцию. Нужна простая идея, опирающаяся на имеющиеся наработки
- GraphQL хитро решил проблему "что если нам закинут программу, которая ебнет сервер". Тупо white list программ и банить
- кто-то сообразит, что можно выставить API в стиле:
- кидаем WebAssembly,
- у нее есть API в стиле db.persons.byId(111)
- она выкидывает взад JSON

Короче кто не ссыт - можно ёбнуть новый мир.

Ссылка | Оставить комментарий {15} |

Должен ли программист уметь программировать?

июл. 24, 2019 | 04:36 pm

Статья на хабре:

Почему Senior Developer'ы не могут устроиться на работу
https://habr.com/ru/post/460901/?reply_to=20426003#comment_20426003

Типа заставляют задачки решать, пидоры.

Я тут собесал как-то чувака, типа 10 лет опыта, лид/PM. Попросил открыть студию - нету студии. Ок, давай попишем где-нибудь еще. А он такой: "знаешь, у меня уже кинжал заржавел". Вот это вот "кинжал заржавел" - стало локальным мемасом. И я всегда, всех, на собесах прошу писать код. И даже клаву нормальную им притаскиваю, чтобы не тыкаться в ноут незнакомый.

Прошу не красно-чёрные деревья, а прям тупо "найди в строке слова из массива". И дальше - а как-нибудь не за O(N^2)? Dictionary - ок, а как оно внутри работает? А давай мы еще запятые отпарсим. И смотришь - от входа код говно, или даже после нескольких хотелок прилично всё. А если человек кодит збс - то и в голове дальше порядочек.

Ссылка | Оставить комментарий {17} |

Про фуллстек

апр. 11, 2019 | 09:39 am

Наблюдаю печальные проекты, на которых лид - джавист, с представлением о фронте уровня типа: "Реакт? Мне говорили лучше ангуляр. Ну да ладно. Где тут у вас верстальщиков набирают?". Ну дальше всякое типа: "мы вам REST API вон дали, дизайнеры вон скрины нарисовали, пилите, у нас тут поважнее дела есть - микросервисы настраивать".

И начинается:
- фронты делают по 50 вызовов к API на скрин с дичайшим overquerying
- бекенд - оптимизирует эту лишнюю нагрузку
- дизайнеры рисуют компоненты на килобаксы, чисто потому что фронты молодые и без права голоса
- т.к. на бекенде особо нечем заняться - вынимай с БД да кидай в API, начинается изобретаться всякое говно типа 5 слоёв абстракции, CORS, и чего-нибудь еще модного для важности
- проблемы архитектуры сваливаются на фронтов, например "если это API лежит, рисуйте крутилку" или "если сервис A отдал ID, а в B по такому ID пока ничего нет - рисуйте крутилку и пингуйте"
- сами фронты без присмотра, всегда берут Redux, и занимаются копипаст-онанизмом

Алё, ребяты! Фронтенд сейчас - зачастую, наиболее технически сложная часть, и именно она продает продукт. А API - ключевой элемент, определяющий всю архитектуру. Нельзя технически лидить фронтовый проект, не понимая проблемы html/css/js, и не шаря в распределенных системах - чтобы строить API.

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

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

Ссылка | Оставить комментарий {26} |

Самый пиздец в том...

сент. 14, 2018 | 10:10 pm

Шутка в шутке - джависты показывают какие они дебилы, иллюстрацией про то, какие дебилы джаваскриптеры.



Я тут поспрашивал про картинку - оказалось что очень мало кто понимает в чем проблема с этим LinkedList. Параллельно смотрим на machine learning - вообще никто не помнит даже как матрицы умножаются.

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

Ссылка | Оставить комментарий {17} |

frontend/backend - меняем линию отреза

ноя. 15, 2017 | 11:50 pm

Вот пост про WebAssembly: https://yorool-gui.livejournal.com/267418.html - навеял мысли.

На классических, server-side rendered, веб-проектах, роли распределяются как-то так:
- backend: достать данные с БД в VM-ки, сунуть в шаблоны, убедиться что данные все под рукой, убедиться что запросы эффективные, отдать фронтендерам. Плюс обмазать кешем, плюс навести порядок в коде - включая вьюшки. Всякий бандлинг CSS/JS, локализацию - тоже бекендеры делают
- frontend: допилить шаблоны, обмазать CSS-кой, посыпать JS-кой на JQuery

Когда мы начали делать SPA-шечки, линия реза переехала:
Backend:
Достать данные с БД, положить в VM-ки, пинать хуи, ебать овец, изобретать пизданутые микросервисные архитектуры

Fontend:
В хорошем случае (власть на проекте у фронтов):
- понять что надо для страницы
- рассказать бекендеру какое запилить API, чтобы все вынуть в 1-2 запроса
В плохом случае (власть у бекендеров):
- сходить в пизданутыми дебилами задизайненное микросерисное API
- 10 раз сходить с каждой страницы, потому что пидарасы дебилам продали REST, и они теперь отдают белочек и зайчиков с отдельных эндпоинтов
- все еще в параллель, чтобы быстро
- обработав ошибки, потому что у дебилов сервис про зайчиков лежит, а про белочек - нет, а зайчики - не обязательны. И похуй всем, что все с одной БД берется.
В любом случае:
- куда-то данные сложить удобно, кешить
- как-то кэши инвалидировать
- ну и дальше еще написать UI, который в 100 раз сложнее того, что было с server-side rendering-ом

Короче, текущая огранизация труда, часто приводит что бекенд может построить красивое халявное REST-API вида GET /api/person?id=123. А что фронтендерам оно неудобно - их не ебёт, у них так в книжках написано делать. Этот пиздец иногда и к полному факапу проектов приводит.

Ну и вообще, REST сдох, лучше пока не подвезли, и кому-то надо велосипедить.

Я думаю что должна родиться новая специализация, вот с таким скоупом:
[ ---------------------- Data Access Developer ----------------------- ] [ -------------- front -------------- ]
[DB] [ Business Logic ] [ Wire Protocol ] [ Front-end data store ] [ CSS, реакты, пауки из розетки ]

Т.е. фронт от бека получает на клиенте API типа store.getPersons({ name: 'Ivan' }) - и имеет право его дергать 60 раз в секунду по 100 раз на кадр. Как оно данные достает и кэшит - его не парит, на фронте и без этого забот тьма.

Можно сказать что это то, что сейчас называют фулл-стеком. Но по-факту, людей умеющих хорошо CSS/JS/интерактивщину - достаточно, эта часть - тоже целый хитрожопый мир, но она легко отпиливается и делегируется. Поэтому пусть сам UI остается фронту. А чтобы на фронте были данные, быстро и свежие - вот там надо нормально сечь в распределенных системах, ну и хорошо уметь в алгоритмы и данные.

С WebAssembly фронтовую часть про данные, можно написать на том же языке, на котором бэк. Можно будет пилить обе части на чем угодно. И обмазывать тестами, даже не стартуя фронт.

По факту, у нас уже сейчас роли похоже распределяются. Думаю что скоро это будет трендом.

Ссылка | Оставить комментарий {24} |

Про Web X.0

сент. 29, 2017 | 04:00 am

https://habrahabr.ru/post/338880/

- ссылка ради дискуссии, оригинал тут: https://blog.plan99.net/its-time-to-kill-the-web-974a9fe80c89?gi=cfea8a5c0bb5 и дальше тут https://blog.plan99.net/what-should-follow-the-web-8dcbbeaccd93

Я, даже когда трезвый, ору на курилке что веб - говно, кривляясь как обезьяна, кукарекая как курица - подражая только что влепленым мною CSS-хакам. Я вообще молодежь учу что веб надо ебать и бросать. Там же пиздец, там любви не может быть в принципе.

Но тут вроде децл посерьезнее всё. Хайпануть надо.

Что не идеально - там все согласны. Вопрос - где инженерный движ за идеальное?

Нужен же движ "сделаем Web X.0 с нуля". Как минимум — как выхлоп для кучи идеалистов, которые сейчас делают всякие ReactOS. Будет фонтан идей, в который можно кунать авторов очередного border-radius или flexbox. Будет там и адище срача.

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

Ссылка | Оставить комментарий {27} |

GraphQL/Apollo - hands on

сент. 14, 2017 | 02:21 am

Запилили проектик на GraphQL. Взяли Apollo (http://dev.apollodata.com/) на фронт, GraphQL.NET Conventions (https://github.com/graphql-dotnet/conventions) - на бек.

Ощущения смешанные.

От GraphQL однозначно выигрывает бекенд на чтение. Раньше ведь как - либо делаем под каждый скрин по API-шке и VM-ке - чтобы за раз все нужное достать. Тут боль и копипаста. Либо включаем режим "мне вообще похую на перформанс, плюс я ненавижу фронтендеров", и делаем канонический REST. Правда, я не видел нигде UI, сделанный поверх канонического REST API - видимо это физически невозможно, т.к. слабоумных фанатиков REST предостаточно.

С GQL получается что все сущности лежат по кучкам - контроллер+VM, и друг про друга не очень знают. А сбоку прикручен супер-клей, позволяющий достать ровно то, что надо, в один запрос к серверу, да еще и к БД запросы сбатчить. Прям писечка.

С мутациями сложнее. На бекенде, как минимум, мозг ебет то, что в GraphQL почему-то на вход API нельзя дать тот же тип, что был на выходе. А для каких-нибудь форм, типичное API - это { load(): T; save(updated: T); }. Но в целом, жить можно.

На фронте с Apollo на чтение все тоже очень неплохо. Типы для TypeScript, кстати, норм приделываются. И даже плагин есть чтобы внутри TypeScript в GQL-синтаксисе работала типизация от GQL (понятно это глючит, т.к. ебаная магия).

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

Короче если у вас аппа много разного показывает, а меняет - немного и точечно - GraphQL+Apollo очень ок. Если у вас опердень с гридами и формами - я бы сильно подумал. Ну или можно взять GraphQL, но без Apollo - тоже может быть норм вариант.

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

Ссылка | Оставить комментарий {2} |

Просто про webpack и npm

мар. 2, 2017 | 01:51 am

20% времени разработчиков на моих проектах, уходит либо на еблю с webpack/npm, либо на их перенастройку в иллюзии что ебля попустит. Большая часть проблем - из-за того что module resolving в node сделали идиоты.

Ссылка | Оставить комментарий {26} |

Внезапно договорились все не менять объекты в JavaScript

ноя. 4, 2016 | 03:34 am

Недавно один молодой боец мутировал значение по ссылке. И другой молодой боец ему сделал ата-та.

Будущее наступило. Такое, как вы хотели, господа.

Время вам, уставшим дядям, рассказывавщим про зависимые типы, вступать в роль.

Ссылка | Оставить комментарий {9} |

CSS Houdini

май. 4, 2016 | 11:19 pm

Чуваки мутят programmable pipeline для браузеров - чтобы можно было пилить "шейдеры" на JS для всех стадий: парсинга, раскладки, рендеринга, и композитинга.

Спеки: https://drafts.css-houdini.org/ Популярно: https://www.smashingmagazine.com/2016/03/houdini-maybe-the-most-exciting-development-in-css-youve-never-heard-of/

Это сука блядь первая нормальная идея от разработчиков этих веб-стандартов. ПЕРВАЯ НОРМАЛЬНАЯ БЛЯДЬ ИДЕЯ. За годы разработки браузеров хоть кто-то там включил свой ёбаный мозжечок.

До этого эти ёбаные кретины делали всякие градиенты - с хитрожопым несовместимым синтаксисом. Которые используются для всего, кроме градиентов - например для рисования палочек на фоне. Потому что в CSS нельзя взять и нарисовать палочку.

Кретины делали скругленные углы. Которые были и есть дань какой-то мимолётной моде. Завтра станут модными треугольные углы - и кретины добавят такое свойство.

Они делали флексбокс - который позволил наконец поставить элементы в ряд. Он до сих пор нехуево глючит в топовых браузерах. Хотя ладно, за флексбокс спасибо - мы хоть теперь в ебаном 2016-м году можем ставить элементы горизонтально.

А можно было сразу дать API - и всё это говно, плюс столько же 10 раз, люди бы написали за год. Да, тормозило бы может по началу. А что - через JS div-ы двигать - это не тормозит?

Я только вот боюсь что всё это идиотское говно с border: radius наверняка сделано поперёк pipeline-а хаками, и останется с нами навека - это вам не тег marquee убрать.

Может быть, лет через 10, я смогу уже нарисовать клетчатый фон, написав (ctx) => ((ctx.offsetX + сtx.offsetY) / 10) % 2 > 1 ? color.black : color.white. Может быть, мои дети смогут наложить два div-а друг на друга, написав display: layout('overlay'). Может быть, мои внуки смогут написать color: constract - чтобы текст был контрастным в зависимости от фона, не каскадя селекторы от .parent:hover.

Ссылка | Оставить комментарий {12} |