?

Log in

No account? Create an account

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} |

Линзы, но не линзы

июл. 22, 2017 | 01:38 am

Такая идея:
- приложение берет свой state: { filter: { itemColor: 'red' }, sort: 'name' }
-- рисует FilterPanel, передавая внутрь state: { itemColor: 'red' }
--- FilterPanel рисует кнопку Clear Filter
--- юзер кликает по Clear Filter, в FilterPanel кидается событие { action: 'clear' }
-- FilterPanel кидает вниз событие { action: 'change_filter', value: {}, cause: { action: 'clear' } }
- приложение делает state = { filter: {}, sort: 'name'}

Потом нам захотелось стирать sort если жамкнули по "Clear Filter". Но не стирать, если все фильтры руками потёрли. Ну мы нагло лезем в cause, и делаем if (cause.action == 'clear') ...

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

Можно провести аналогию с ООП. Есть приватный метод, и хер ты чего сделаешь. Но если если его сделать protected - можно чуть что подлезть, и исправить. Ну и халявные плюшки, вроде того что можно каждое действие юзера логировать детально - для аналитики, чтобы баги воспроизводить, или пост-фактум какие-нибудь датафиксы делать.

Я ищу тут что-то, что позволит просто и быстро писать UI, пока у тебя все как всех, но чуть что - иметь возможность погнуть систему. Банальный ООП неплохо тут пашет - простое - просто, среднее - норм, сложное - ад пизды. Хочется вот попробовать последний пункт попробовать полечить как-то, сохранив первые два.

Может посоветуете чего?

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

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

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

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

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

Прекрасное будующее

фев. 28, 2017 | 11:48 pm

Фантасты говорили нам, что в будующем все будут пристроены по творческим проффесиям.

Найдите хоть одну годную онлайн-аппу про творчество.

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

Про гомеопатию

фев. 7, 2017 | 02:07 pm

А я вот думаю не надо ничего запрещать. И даже пусть дальше в аптеках продают. Есть гораздо более дорогие и более бесполезные вещи: тюнинг на ВАЗы, объективы для фотоаппаратов, солдатики для настольных игр, кухонные комбайны. Не писать же на всем этом типа: "влияние антикрыла для ВАЗ 2106 на скорость не доказана наукой", или "99% покупателей кухонных комбайнов используют их 2 раза после покупки".

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