?

Log in

No account? Create an account

Музыка

дек. 2, 2018 | 02:17 am

https://soundcloud.com/yakov-zhmurov/202bpm - попробовал вернуться к музыке, может пойдет

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

yarn plug-n-play

окт. 17, 2018 | 03:09 am

https://github.com/yarnpkg/rfcs/pull/101

Товарищи из yarn наконец-то догадались пропропатчить метод require(), и доставать модули прямо их кэша, вместо того, чтобы копировать их миллионами в node_modules. Чтобы сделать простое решение, как у всех, детям потребовалось почти 10 лет. Надо было всего-лишь повзрослеть, и перестать делать папе назло.

Вот тут детали: https://github.com/yarnpkg/rfcs/files/2378943/Plugnplay.pdf - особенно интересно в контексте "какой же пиздец в npm".

Надеюсь теперь хотя-бы npm как тула подохнет. Хотелось бы, конечно, дожить еще и до похорон node и всего говна вокруг неё.

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

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

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

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



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

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

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

-

июл. 22, 2018 | 12:06 am

Здравствуйте! Я губернатор Рязанской области. Я - крепкий хозяйственник. Я меняю вам асфальт и бордюры. У меня пока получается не очень, и не везде.

Извините.
Губернатор Рязанской области.

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

grow.by

июн. 12, 2018 | 11:49 pm

Зацените - https://grow.by

Это мы один из своих внутренних тулов выставили наружу. ToDo-list такой специализированный под персональное развитие. Внутри оно используется, в частности, для того, чтобы зафиксировать разговоры типа "ну вот, английский выучишь, и мы тебя подвинем повыше".

Как по мне, календарик просто заебись, такого ни у кого нету. И drag-n-drop так даже трелло не вылизывал, хотя на мобилках мы его так и не завели.

А проблема, которую мы решаем, она про "надо ли кому-нибудь еще что-то такое вообще". Что-нибудь может посоветуете, чтобы это люди юзали? Может синк с айфончиком добавить, и как обычная тудушка заедет?

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

-

мар. 17, 2018 | 03:20 am

Проголосуйте сходите.
Кто не сходит - тот мудак.
Если сомневаетеяся - ну там что угодно, только бы не Путину галочку.

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

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 фронтовую часть про данные, можно написать на том же языке, на котором бэк. Можно будет пилить обе части на чем угодно. И обмазывать тестами, даже не стартуя фронт.

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

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

Про 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-базу.

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

Греция

июл. 22, 2017 | 03:44 am

В июне сгоняли в Грецию на 2 недели. Побукали 4 отеля через booking, 3 места через AirBnb, самолеты, тачку, и поехали кругом. Салоники — Паралия — Метеоры — Делфы — Афины — Салоники — Халкидики.

Читать дальше...Свернуть )

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