Программирование, т. 8

Уже выпилили (

d

 

 

вот вы пидоры
дается решение с циклом - хуйня
рекурсивное решение - хуйня
чо вам еще надо бля

бтв отправил резюме в дойче банк

удачи работать погромистом в смокинге

 

ну нет на самом деле

бывший коллега дружаня там воркает - все ок там с этим

в однобортном можно?

бля не представляю что чувствуют прогеры изза ошибки которых убивают десятки человеков

если жс, то скорее всего просто рофлят над этой хуйней

кто-нить делал такую хуйню с кафкой:

есть сервис, который должен служить неким вахтером, который консьюмит ивенты из одного топика, ждет пока придут все ивенты из законфигуреного списка и потом отправляет их в другой топик

есть несколько вариантов как это сделать, но хотелось бы без хаков (типа всяких левых редисов) и если можно - каким-нить бэст практисом (чет ничего толкового на сайте конфлуэнта не нашел)

кто-нить делал такую хуйню с кафкой:

есть сервис, который должен служить неким вахтером, который консьюмит ивенты из одного топика, ждет пока придут все ивенты из законфигуреного списка и потом отправляет их в другой топик

есть несколько вариантов как это сделать, но хотелось бы без хаков (типа всяких левых редисов) и если можно - каким-нить бэст практисом (чет ничего толкового на сайте конфлуэнта не нашел)

Так, бойз. Очередная задачка из мира современного фронтэнда. Есть какие-то паттерны ща построения Create/Update/Read интерфейсов? В своё время у меня всегда был один контроллер с одной вьюхой, но с разным стейтом, типа создавал компоненту, передавал туда модель и stateView = StateView.EDIT/CREATE/READ и от этого поля строились и наполнялись, всякие валидации подсасывались. Ща же может фронтэнд дальше шагнул? А то всё чо в инете нахожу, советуют просто делать 3 разных компонента и маппить на разные рауты, типа /app/hui/123/edit (редактирование), /app/hui/123 (вью) /app/hui/ (создание). Но выглядит поносно и дохуя копипаста/бойлерплейта. Дык как правильно (чтобы ссаными тряпками меня джуны не закидали)

блэть, тебе тут скажут, а ты потом будешь перед джунами выебываться

вроде ща графкьюэль модно и через него пилишь свой круд

Так, бойз. Очередная задачка из мира современного фронтэнда. Есть какие-то паттерны ща построения Create/Update/Read интерфейсов? В своё время у меня всегда был один контроллер с одной вьюхой, но с разным стейтом, типа создавал компоненту, передавал туда модель и stateView = StateView.EDIT/CREATE/READ и от этого поля строились и наполнялись, всякие валидации подсасывались. Ща же может фронтэнд дальше шагнул? А то всё чо в инете нахожу, советуют просто делать 3 разных компонента и маппить на разные рауты, типа /app/hui/123/edit (редактирование), /app/hui/123 (вью) /app/hui/ (создание). Но выглядит поносно и дохуя копипаста/бойлерплейта. Дык как правильно (чтобы ссаными тряпками меня джуны не закидали)

Опять хуй чо поймешь полностью с твоих описаний, но если в кратце то у меня в аппе на подобные хуйни (которые отвечают за создание/редактирование/просмотр) отвечает 1 компонент. Редактирование и просмотр вообще по сути дела одно и тоже (можешь только пути разные ебануть), а разница между ними должна осуществлятся с помощью параметров доступа (у нас флаги с бэкенда приходят, на их основе делаем компоненты статичными и все такое). Естественно на бэкенде есть своя валидация, даже если что-то пошлешь минуя неактивные кнопки, будучи уебком без прав, бэкенд скажет пойти нахуй.

А вот для создания новой хуйни у нас идет небольшое разветвление в логике. Мы на основе параметров routing'а проверяем новая эта хуйня или нет (банально чекаешь передан ли параметр типа ID сущности для редактирования) и решает ебашить ли query бэкенду для получения данных для редактирования, или скипать все это и просто показывать юзеру голую форму. Ну и офк в самом компоненте на основе этого ветвления делаешь простые изменения, типа разные названия для кнопок (аля Create вместо Save) и все такое.

Я бы ебанулся создавать новые компоненты ради такой хуйни, когда там добрые 80% кода надо реюзать (по крайней мере у меня).

https://ekaterinburg.hh.ru/vacancy/26371629

https://ekaterinburg.hh.ru/vacancy/26371629

 

Блять, моя контора   Чёт вголос

и каково работать фронтэнд пхпшником?

и каково работать фронтэнд пхпшником?

Да это видимо екатеринбургское какое-то отпочкование, я-то в москве гребу и не знаю что там

Да это заголовок скорее всего такой только, а как пролистаешь на требования и желательно знать ахуеешь 

а че в голос то?

сервера тоже могут быть фронтенд/бекенд серверами

фронтенд != веб клиент/браузер

а че в голос то?

сервера тоже могут быть фронтенд/бекенд серверами

фронтенд != веб клиент/браузер

бэкенд на пыхаче землепухом

тогда я вообще не понял рофла

Я и есть синьёр

маководы совсем в сарказм не умеют?

его отдельно докупать надо, комплектный с ограничениями