<bgdev />free

Вход

ASM future
0

0 1 2 3 4 5 6 7 8
#1247 (ツ) stewie
Създадено на 28.07.2020, видяно: 1951 пъти.
Courvoisier
stewie

Какъв е смисълът на цялото това напрежение? Винаги да си в топ форма за интервю? В последните 2 години уча нещо ново само ако ама много ми се налага.

Да! Аз съм негър с мнение, карам се на шефовете. Ще ги ева и геевете, като ги мързи да четат нови аналогии и искат некви имплементации от преди 20 години, ще ги унижавам пред всички. Ако се уважаваме взаимно нема проблем, но повечето ме гледат като негър и аз се кефя да им давам газ.

Хмм. Хайпаджия ли си? Увличаш ли се като излезе нещо ново веднага да го бутнеш във фирмените проекти, не защото е по-добро, а за да си трупаш цв-то?

#1248 (ツ) Courvoisier
Създадено на 28.07.2020, видяно: 2108 пъти.

Любими теми са ми неразбирането на микросървиси и асинхронна комуникация, неразбирането на agile, глупваите time estimates базирани на story point-ове, както и като почнем да усложняваме, щото сме баси кодерите, което е против идеята за микросървиси. Още по- яко е като кажат тая технология я ползвах преди 10 години и е супер. То и аз преди 10 години пишех на jquery, обаче вече не го ползвам.

#1250 (ツ) stewie
Последно редактирано на 28.07.2020 от stewie, видяно: 1949 пъти.
Courvoisier

Любими теми са ми неразбирането на микросървиси и асинхронна комуникация, неразбирането на agile, глупваите time estimates базирани на story point-ове, както и като почнем да усложняваме, щото сме баси кодерите, което е против идеята за микросървиси. Още по- яко е като кажат тая технология я ползвах преди 10 години и е супер. То и аз преди 10 години пишех на jquery, обаче вече не го ползвам.

Микросървисите могат да са голямо зло. Особенно когато един такъв трябва да джойне огромни данни от два други, всички използващи различни бази. Ти да видиш как като не се домислят нещата как се репликира част от едната база на единия сървис в базата на другия. Лайна с царевица! Имай впредвид, че много ползват микросървиси без да има нужда. Просто така е модерно.

#1251 (ツ) Golden Gega
Създадено на 28.07.2020, видяно: 2102 пъти.

Аз досега не съм виждал приложен смислен аджайл, поради естествената причина че никой (от тези които трябва да го разбират) не го разбира

#1252 (ツ) Courvoisier
Създадено на 28.07.2020, видяно: 2099 пъти.

Ажура от ден на ден се променя. Онзи ден ми писаха некви, Хайпърнещо си, правили неща с Azure Log Analytics. Викам им, по принцип го ровя от година и нещо, обаче сега не ми се рискува с вас.

Имах два свестни шефа. Единия се казваше Ивелин. Другия е македонец :D Всички останали не са пипали код от 10 години и само на теория, на практика не. Толкова хайп чак не съм, допреди година не използвах netcore в production. Но сега 3.1 е достатъчно ОК, последните няколко месеца пуснах 10-на сървиса с netcore. До преди 2 години пишех все още WCF :) Просто не се кефя като ми се мрънка против нъгет сървъра и как е било по- яко да си инклуудвам dll-и без никъв вършънинг, щото, why not, едно време работело. Или да ме карат да инсталирам access database engine, щото едно време го правили така. Едно време почнах .net-а на mvc 2, но сега не бих го ползвал.

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

#1254 (ツ) Courvoisier
Последно редактирано на 28.07.2020 от Courvoisier, видяно: 2097 пъти.
stewie

Микросървисите могат да са голямо зло. Особенно когато един такъв трябва да джойне огромни данни от два други, всички използващи различни бази. Ти да видиш как като не се домислят нещата как се репликира част от едната база на единия сървис в базата на другия. Лайна с царевица! Имай впредвид, че много ползват микросървиси без да има нужда. Просто така е модерно.

Ако данните не трябва да са ми баш real time и са много, мога да си ги джойнвам предварително в Reddis или Mongo и по- скоро ще направя така. Това е именно лош дизайн. Трябва да се мисли именно кое от какъв поддомейн е и това е точно тънкото в микросървисите. Ако го правиш agile, за момента ще имаш правилен отговор, но това може и да не е правилен отговор след време и трябва да не те е страх да поправиш идеята.

То си трябва и gateway отпред, да джойнва заявки.

#1255 (ツ) Courvoisier
Създадено на 28.07.2020, видяно: 2096 пъти.
Golden Gega

Аз досега не съм виждал приложен смислен аджайл, поради естествената причина че никой (от тези които трябва да го разбират) не го разбира

Аз съм виждал, но не в бг фирми. На ниво мениджмънт и организация сме прословуто зле. Има единици, но като цяло редовно е бай иван копа с лопатата, а 10 човека му дават акъл и всеки акъл инвалидира другия акъл.

#1256 (ツ) Courvoisier
Създадено на 28.07.2020, видяно: 2093 пъти.
Golden Gega

Аз досега не съм виждал приложен смислен аджайл, поради естествената причина че никой (от тези които трябва да го разбират) не го разбира

Любим момент ми е сутрин да дейлито да стоим 1 час и да си говорим глупости. Виждал съм го в 3 фирми :D

#1257 (ツ) stewie
Създадено на 28.07.2020, видяно: 1949 пъти.
Courvoisier
stewie

Микросървисите могат да са голямо зло. Особенно когато един такъв трябва да джойне огромни данни от два други, всички използващи различни бази. Ти да видиш как като не се домислят нещата как се репликира част от едната база на единия сървис в базата на другия. Лайна с царевица! Имай впредвид, че много ползват микросървиси без да има нужда. Просто така е модерно.

Ако данните не трябва да са ми баш real time и са много, мога да си ги джойнвам предварително в Reddis или Mongo и по- скоро ще направя така. Това е именно лош дизайн. Трябва да се мисли именно кое от какъв поддомейн е и това е точно тънкото в микросървисите. Ако го правиш agile, за момента ще имаш правилен отговор, но това може и да не е правилен отговор след време и трябва да не те е страх да поправиш идеята.

Малко теоретично се изказа. След 5 години работа с монго осъзнах следното - е не може преджойнеш всичко. Да не говорим, че трябваше да се пише домейн ивент дривън сървиси, които ъпдейтват преджойнатите данни на база оплога на монго. На 3 терабайта продъкшън база това не е хич евтина работа.А иначе много ме кефи некви бастуни, като имат х апита с една база и споделен общ модел как казват, че били ползвали микросървиси.

#1258 (ツ) stewie
Създадено на 28.07.2020, видяно: 1949 пъти.
Courvoisier
Golden Gega

Аз досега не съм виждал приложен смислен аджайл, поради естествената причина че никой (от тези които трябва да го разбират) не го разбира

Любим момент ми е сутрин да дейлито да стоим 1 час и да си говорим глупости. Виждал съм го в 3 фирми :D

Затова бачкаш ремоут със слушалки на такива срещи. В една слушаш "Тъпак" в другата 2pac. Меринджея ми нещл сипваше днед на срещата, а аз поклащам глава на 2pac - No More Pain.

#1259 (ツ) Golden Gega
Последно редактирано на 28.07.2020 от Golden Gega, видяно: 2090 пъти.
stewie
Courvoisier
stewie

Микросървисите могат да са голямо зло. Особенно когато един такъв трябва да джойне огромни данни от два други, всички използващи различни бази. Ти да видиш как като не се домислят нещата как се репликира част от едната база на единия сървис в базата на другия. Лайна с царевица! Имай впредвид, че много ползват микросървиси без да има нужда. Просто така е модерно.

Ако данните не трябва да са ми баш real time и са много, мога да си ги джойнвам предварително в Reddis или Mongo и по- скоро ще направя така. Това е именно лош дизайн. Трябва да се мисли именно кое от какъв поддомейн е и това е точно тънкото в микросървисите. Ако го правиш agile, за момента ще имаш правилен отговор, но това може и да не е правилен отговор след време и трябва да не те е страх да поправиш идеята.

Малко теоретично се изказа. След 5 години работа с монго осъзнах следното - е не може преджойнеш всичко. Да не говорим, че трябваше да се пише домейн ивент дривън сървиси, които ъпдейтват преджойнатите данни на база оплога на монго. На 3 терабайта продъкшън база това не е хич евтина работа.А иначе много ме кефи некви бастуни, като имат х апита с една база и споделен общ модел как казват, че били ползвали микросървиси.

То интересното започва когато трябва да се посочи как микросървисната архитектура ще оптимизира нещо, да кажем като за по-просто скорост. Присъствал съм в интересни проекти в които всичко - архитектура, технологии, схеми и каквото се сетиш бяха на топ ниво. Следваше въпроса как това ще оправдае допълнителните ресурси, т.е. как ще вдигне производителноста като цяло. Беше трагикомично, много подобно на един по-стар форум.

#1260 (ツ) Courvoisier
Създадено на 28.07.2020, видяно: 2090 пъти.
stewie

некви бастуни, като имат х апита с една база и споделен общ модел как казват, че били ползвали микросървиси.

Точно това съм виждал няколко пъти.

Да не говорим, че трябваше да се пише домейн ивент дривън сървиси

Да, основната идея на microservices, иначе влизаш във филма с HTTP Chaining, който сваля availability-то и вдигна Latency-то сериозно.

След 5 години работа с монго осъзнах следното - е не може преджойнеш всичко.

Именно, лош дизайн. Ловят комари с базуки и слонове с прашки. Имплементирания домейн не отговаря на желаният домейн и почват да се появяват дракони. Почваш да правиш неестествени неща и започваш да се питаш ко става.

Ако трябва да върнеш много данни през gateway, напълно е ок да ги сглобиш от няколко сървиса през queue, по възможност паралелно. Ако едните данни ти зависят от другите данни, то тогава може би след корекция на домейна ще стане по- леко. ОК е. Кофти е ако трябва да имплементираш сага и влизаш в дедлок, което е падението на всякаква абстракция.

#1261 (ツ) Courvoisier
Последно редактирано на 28.07.2020 от Courvoisier, видяно: 2087 пъти.

Микросървисите са за нас и за организацията. Има намалена когнитивна сложност, някой по- лесно ще влезне в микросървиса и ще може да направи нещо в него. Имаме отделни компоненти, което правят нещо добре, без да се съобразяват с други неща и могат да следват собствена еволюция. Те могат да се пишат на различни езици, според случая, За скрейпър и текстообработка пих ползвал питон, просто има по- добри библиотеки от .net. Също така скалират по- добре и по- лесно от монолитите. Скалират и по- точно от монолитите. Ако имам 100 use-case-а от 3 поддомейна в един монолит, от които 1 поддомейн се използва в 80% от заявките, скалирам ли, ще скалирам всичко. Ако е на микросървиси, ще скалирам само поддомейна. Даже в Ажур това го приветствам и на ниво Web App/App Service, не само Kubernetes + Docker.

Обаче да имаш 100-200 сървиса означава, че трябва да имаш свястна документация на общата картинка, да имаш и добри архитекти. Трябва да се мисли, не става само с кодене.

Също така е естествено. Когато имате голям проблем за решаване го разделяте на малки под-проблеми. И микросървисите така.

#1264 (ツ) stewie
Последно редактирано на 28.07.2020 от stewie, видяно: 1949 пъти.
Golden Gega
stewie
Courvoisier
stewie

Микросървисите могат да са голямо зло. Особенно когато един такъв трябва да джойне огромни данни от два други, всички използващи различни бази. Ти да видиш как като не се домислят нещата как се репликира част от едната база на единия сървис в базата на другия. Лайна с царевица! Имай впредвид, че много ползват микросървиси без да има нужда. Просто така е модерно.

Ако данните не трябва да са ми баш real time и са много, мога да си ги джойнвам предварително в Reddis или Mongo и по- скоро ще направя така. Това е именно лош дизайн. Трябва да се мисли именно кое от какъв поддомейн е и това е точно тънкото в микросървисите. Ако го правиш agile, за момента ще имаш правилен отговор, но това може и да не е правилен отговор след време и трябва да не те е страх да поправиш идеята.

Малко теоретично се изказа. След 5 години работа с монго осъзнах следното - е не може преджойнеш всичко. Да не говорим, че трябваше да се пише домейн ивент дривън сървиси, които ъпдейтват преджойнатите данни на база оплога на монго. На 3 терабайта продъкшън база това не е хич евтина работа.А иначе много ме кефи некви бастуни, като имат х апита с една база и споделен общ модел как казват, че били ползвали микросървиси.

То интересното започва когато трябва да се посочи как микросървисната архитектура ще оптимизира нещо, да кажем като за по-просто скорост. Присъствал съм в интересни проекти в които всичко - архитектура, технологии, схеми и каквото се сетиш бяха на топ ниво. Следваше въпроса как това ще оправдае допълнителните ресурси, т.е. как ще вдигне производителноста като цяло. Беше трагикомично, много подобно на един по-стар форум.

Хахаха, точно! Само, че нашите архитекти никой не им поиска сметка (май само аз и още двама колеги), защо беше нужно 2 годишно преминаване и пренаписване на целият монолитен блок с множество апита, сплитване на десетки бази, после докери, ама после ай заеби докерите, дай кюбернетис, ама дай да е ранчър, ама ей кво си. Ама енджиайенекса ми не форуардва хедърите на уя ми, ама тоя контейнер не може се въже към базата заради еди какъв си проблем с айпитата и т.н и т.н. И накрая същият перформънс хуй както като си бяхме качили всичките апита на две ИИС-та зад лоад балансър. Отговорът на защо всичко това беше, че като са ни сплитнати базите, много по-лесно можем да ги бекъпваме и репликираме. Ми хубо бате, ама сме над 30 програмиста, контрактори, папкаме повече от негър в балканско ЕООД. За тея години това са милиони долари. Всичко се прави с една единствена цел - мангизи и нищо друго. Ако може сайт за лютеница с микросървиси - давайте смело.

#1265 (ツ) Courvoisier
Последно редактирано на 28.07.2020 от Courvoisier, видяно: 2079 пъти.
stewie

Ако може сайт за лютеница с микросървиси - давайте смело.

Сайт за лютеница на Сайткор :) Доволно скъпо! Джаварите имат ли сайткор? :D Нямат!

Хардуерът е евтин. Ние и лицензите са по- скъпи.

#1266 (ツ) stewie
Последно редактирано на 28.07.2020 от stewie, видяно: 1949 пъти.

Явно вие четете много, аз съм затъпял от писане на джабаскрипт, репортинг агрегации за монго, или поредните поправки на множество разцепени бази през драйвера му за .нет. Та попадна ми следното вчера. "Архитектът" почна да ми мрънка как сега имало Channels в .нет патладжан. Въпреки, че е с по-малко опит и от мен в .нета, ходи там на конференции, лектор е, снимки с микрофони в слака, а-у. А аз чета 9гаг, щот съм тъпо мързеливо копеле като един друг форумен администратор.

Тоя е надъхан повече и от рабиняк върху затлъстяла домакиня. Вика ползвай го. Викам ко да еба е туй, той producer/consumer.

Задава се въпроса запознат ли съм с какво е producer/consumer !!! Нали щотото проблема на много четящите е, че те знаят всичко, а другите сме прости рая. Викам да уе, кензъл и гребъл патърна. Единият сере, другия гребе. И на място, което плаче за прост foreach и много далеч от нужда на употреба на Dataflow (TPL) той просто иска да го набутаме, нали защото е ново.

Надявам се да ме разбираш сега защо не съм фен на всичко ново и на хайпъджиите. Хайпъджиите са като нарко босовете - те няма да се спрът пред нищо, важното е да са номер 1 и егото да расте. Дразнят много, но : удължават с години проекта (повече пари присвоявате) и научаваш най-новите неща докато гледаш мемета :)

#1267 (ツ) Golden Gega
Създадено на 28.07.2020, видяно: 2076 пъти.

Ако за простота се ограничим само в проектирането на даден продукт, има две генерални цели - едната е да се постигне нужната функционалност (за простота слагам тук и гъвкавост, т.е. възможност за склаиране), другата е цената за постигане на първата цел.

Естествено, от едната страна са технологичните гурута, които ще си отхапят и чурките само и само проекта да се прави с най-най-най ама наистина най-най-най правилната технология/платформа/... От другата са момците с пачките които се интересуват от две неща - нещото да стане в срок и разходите да са най-малки. По средата е така наречения архитект който трябва да поеме ритниците и от едната, и от другата страна.

И тук започва интересната част - обикновено дадена технология е създадена да реши даден проблем... но за сметка на друг такъв. Типичен пример са микросървисите - те привидно решават едни проблеми, като обаче решително създават други. И тук започва голямата мъка - да се преценят плюсовете и минусите, да се вземе правилното (оптимално) решение и ... битката е спечелена наполовина, защото остава да се убедят двете пасмини че то е оптимално. И това не е краят, защото трябва да ги убедиш че е оптимално за целия срок на проектиране/изработка/експлоатация на решението.

Като се заговорихме за микросървисите - това си е за отделна тема. Най-малкото защото с плюсовете си те имат и много съществени недостатъци, и когато се реши да се ползват трябва да се прави баланс с плюсовете и минусите не само в проектирането и изработката, ами и в QA фазата, скалирането, експлоатацията, интеграцията с други системи и т.н. и т.н. И освен това този баланс трябва да включва спецификите на приложението, качествата на екипа, срокове, БА анализа...

Въобще проектирането е една доста тегава и неблагодарна професия, с доста мистика и с много повече здрав (ама необясним за околните) разум.

#1269 (ツ) Courvoisier
Създадено на 28.07.2020, видяно: 2073 пъти.

Това за проектирането е много вярно. Те затова и вземат заплати. Много е важно да знаеш какво може да си позволиш. На ниво 1-2 да правят нещо, 3-4 да се опитват и 10 да са там за красота е по- лесно с микросървиси. Джуниъра като види 20 класа и вика не е сложно, има желание. Като види 2000 класа и вика What Da Fuck, защо са толкова и какви са тези всичките интерфейси и защо има не знам си какво. Аз лично намирам когнитивната комплексност за много важна и като имам време на работа по някой малко забозен проект, почвам да раздробявам методите на такива между 5 и 15 реда, според зависи. Те джуниърите се стряскат и да многото проекти, защото не са свикнали да боравят с абстракция. Имам ключове, ок, 10 ключа. Този отключва входната, този колата, този избата, този е за пощата, онзи е за къщата на нашите. Всеки ключ си върши работата, нямам един универсален ключ за всичките ми врати. По- естествено е. По- ниска когнитивна комплекстност. Нетрениран човек може да държи между 5 и 9 единици информация едновременно в кеш, magic number 7. С тренинг стават и повече. На момента, като го пиша, мога да ти кажа с точност какво прави всеки един ред код от 6-те ми сървиса, които писах 3 месеца паралелно. След още 6 месеца, обаче няма да си спомням. Но ако са loose coupled, ще влезна в единия, ще видя, ако е с ниска комплексност, по- бързо ще разбера какво става. Имам добра памет, но забравям. Тук микросървисите са добри, раздробяват проблема. И скейлват много по- лесно, особено с докер и кюбернетис е детска игра. За мен това е достатъчно полезно, ако fit-ва на бизнеса. По- естествено е за дистрибутирани системи. Разделение на труда. Аз съм зидаромазач, съседът отсреща е лекар, под мен съседа прави шпакловки и бани, домоуправителят е електротехник, другият домоуправител ОВК, разбираме се целия блок. Всеки допринася с каквото може. Ние сме един вид микросървиси в тази конкретна абстракция, макар да правим и други неща.

#1270 (ツ) stewie
Създадено на 28.07.2020, видяно: 1949 пъти.

И като трябва всички комшии да се обедините дружно и да си платите асансьорната такса и става греда :)

#1272 (ツ) Courvoisier
Създадено на 28.07.2020, видяно: 2069 пъти.
stewie

И като трябва всички комшии да се обедините дружно и да си платите асансьорната такса и става греда :)

Плащаме, даже през една стара щайга контролираме тези, които не плащат асансьор и им изключваме чиповете :D Изградили сме комунизма.

Плуралсайта не е хайп, има много интересни неща. Сега гледам:

Useful Cryptography: An Introduction

In this talk, Randall Degges discusses useful cryptographic primitives and how to practically apply them in your development projects. You'll learn about hashing, HMACs, encryption, TLS, and more. You'll gain a strong foundational knowledge of cryptographic principles and an understanding of how to make use of various algorithms to secure your applications. You'll also know what to look out for when building secure applications and where to be careful during implementation.

Стана ми интересно от дискусията за сертификатите, TLS с ECC и т.н., преговарям и гледам нови неща.

0 1 2 3 4 5 6 7 8

ASM future
0

AsmBB v3.0 (check-in: a316dab8b98d07d9); SQLite v3.42.0 (check-in: 831d0fb2836b71c9);
©2016..2023 John Found; Licensed under EUPL. Powered by Assembly language Created with Fresh IDE