Как ще реагирате ако човек над вас ви каже, че нямате право да си дебъгвате кода закачен към стейдж/продъкшан данни (приемаме, че сте в read-only режим и не може да засерете данните), а вместо това трябвало да се измисли такова логване, че едва ли не никога да не се налага да се дебъгва :)
synergie
Създадено на 29.08.2022, видяно: 618 пъти. #67186
Защо ти е да дебъгваш на production? Туй не е ли "мега лошата практика"? 😏
Ай ся нема да се правя на интересен - понекога се налага да видиш "как работят нещата в реалния живот", ама да се налага да дебъгваш на production, говори зле за проекта и кода.
Второ начало:
Що не си направиш 1 backup на базата и да си я гавриш и мандръсаш колкото си искаш и да си вдигнеш една среда. Docker ползвате ли?
Те в цивилизованите държави си вдигат тестови среди за минути. Ех, сасипаха я таа држава. 😔
synergie
Създадено на 29.08.2022, видяно: 589 пъти. #67209
Как ще реагирате ако човек над вас ви каже, че нямате право да си дебъгвате кода закачен към стейдж/продъкшан данни
Много педалско от твоя страна!
Е какво друго да ти кажа освен, че ще ти скубя космите на умнокрасивата ти путка :)
СиКурАрЕс системата не фитва ли в адвансд патърна "Testing & Debugging in Production"
Са, на Единьо нема се подигравам, че е млад и неопитен и не е виждал ама наистина гигантски проект с десетки бази данни зад него. Като цяло из еоод-тата, в които интернет коментаторите скатават (в това число и повечето от читателите тук) обикновено нямат достъп до такива проекти.
И за майстора на невронни мрежи с интерполиращи функции за диагностика на размер за джапанки написан на питоня, уважаемият Синжир Баба, ще поясня кратко и ясно.
Генерират се репорти в комбинация от агрегация между десетки бази(наблягам на БАЗИ, а не на БАЗА) , както и се дърпат солидно количество мета данни от рест и grpc базирани сървиси. Всичко това е обилно полято със сървърен код, който се изпълнва преди да се върне репорта.
Така, имаме всички възможни юнит и ацептънс тестове. Всичко точно. Дали може да си издърпаш стейдж или продъкшън базите локално? Цената за хостване и бекъп на стейджа и прод базите беше около 31700 долара на месец в последната сметка.
Така, обаче въпреки всичко някъде в полетата на репорта нещо е грешно. И не се улавя от тестовете. Ам уви в цялата схема от куерита, агрегации, трансформации и проекции някъде нещо се е засрало.
Та да видим сенсеите на форума какво ще направят :) Очаквам от Единьо да изкара нещо де не го знам от торбата със сертификатите си, а Синжира както винаги ще ми каже, че съм педерас и мижав контрактор и ще се скрие обратно в дупката си където коди на питон за сигурна заплатка и ваучери за храна, рупайки фафли Чайка.
Са, на Единьо нема се подигравам, че е млад и неопитен и не е виждал ама наистина гигантски проект с десетки бази данни зад него. Като цяло из еоод-тата, в които интернет коментаторите скатават (в това число и повечето от читателите тук) обикновено нямат достъп до такива проекти.
И за майстора на невронни мрежи с интерполиращи функции за диагностика на размер за джапанки написан на питоня, уважаемият Синжир Баба, ще поясня кратко и ясно.
Генерират се репорти в комбинация от агрегация между десетки бази(наблягам на БАЗИ, а не на БАЗА) , както и се дърпат солидно количество мета данни от рест и grpc базирани сървиси. Всичко това е обилно полято със сървърен код, който се изпълнва преди да се върне репорта.
Така, имаме всички възможни юнит и ацептънс тестове. Всичко точно. Дали може да си издърпаш стейдж или продъкшън базите локално? Цената за хостване и бекъп на стейджа и прод базите беше около 31700 долара на месец в последната сметка.
Така, обаче въпреки всичко някъде в полетата на репорта нещо е грешно. И не се улавя от тестовете. Ам уви в цялата схема от куерита, агрегации, трансформации и проекции някъде нещо се е засрало.
Та да видим сенсеите на форума какво ще направят :) Очаквам от Единьо да изкара нещо де не го знам от торбата със сертификатите си, а Синжира както винаги ще ми каже, че съм педерас и мижав контрактор и ще се скрие обратно в дупката си където коди на питон за сигурна заплатка и ваучери за храна, рупайки фафли Чайка.
Ами хубаво е да "конкретизираш" преди да питаш, че така не става ясно. А иначе съм виждал поне на неколко места проекти с 10-ки бази данни. BI-те от една компания ми показваха, SAP интеграцията на Coca Cola Hellenic със 50+ бази под проекта, а и май у Scale бех виждал такива проекти.
А бе проблемът ти звучи като "бюрократичен", а не като "технически". Щом има "техническо решение", ама проблемът са парите - да му мислят меринджеите. 😄 Ама то тва си е верно "меринджеймънт" проблем дето се учи в дебелите (че и "тънките") PM книжки за "Project Management 101" и там пише:
"Подсигурете си тестова среда! Без оправдания!"
Еми бих посъветвал, щом unit и acceptance тестовете не гърмят, да:
1. Провериш дали не са закоментирани. 😅
2. Да провериш дали са написани като хората.
3. Да провериш кви case-ове не покриват и да почнеш от там.
И после да кажеш на шефовете:
"Пичуе, като немаме пари за staging, ще ви решавам проблема по селски! И ще отнеме време, ама ако сте готови да плащате - ок."
И почваш query по query, агрегация по агрегация и т.н. да търсиш "къв е проблемът". Ако можеш да си автоматизираш работата с некво tool-че или report (или да отхвърлиш къде не е проблемът), ок. Иначе нема бързо решение.
🤔 Вариант е да четеш и некви server-ни логове по server-ите дето са ти host-нати базите (а и логовете на базите), ама не ти знам каква грешка търсиш (пак не е много конкретизирано). Кво му е на репорта?
За не знам кой път искаш да конкретизитам. Истинския архитект трябва да има решение за всичко без много детайли :) Но ето още един детайл - парите не са проблем. Бачкам за милиардери, 30к зелено на месец за тях е все едно ти си отишал на циганка в Бургас.
Цялата фирма със сите й продукти се търгува в nasdaq. Даже ако искаш си купи от акциите й. За да се търгува обаче има едни compliance лайна де ти стъжват живота. Едно от тях е, че трябва да се молиш и да имаш одобрение от цто-то ако искаш да се вържеш към стейдж/прод бази независимо за какво. Та ти ще изревеш ли в тази ситуация?
Сървърни логове... Имаме 2 кибани където се логват от всичките подове на к8с какво ли не, но скоро и всеки стейтмънт от кода ще логваме дали е минал или не.
Големия фън ще е като се насере нещо следобед наше време, клиентитее бръмчат и ще почнат да се губят яко пари, докато аз чакам цто-то да се събуди за одобрение на другия край на планетата :)
За не знам кой път искаш да конкретизитам. Истинския архитект трябва да има решение за всичко без много детайли :) Но ето още един детайл - парите не са проблем. Бачкам за милиардери, 30к зелено на месец за тях е все едно ти си отишал на циганка в Бургас.
Цялата фирма със сите й продукти се търгува в nasdaq. Даже ако искаш си купи от акциите й. За да се търгува обаче има едни compliance лайна де ти стъжват живота. Едно от тях е, че трябва да се молиш и да имаш одобрение от цто-то ако искаш да се вържеш към стейдж/прод бази независимо за какво. Та ти ще изревеш ли в тази ситуация?
Сървърни логове... Имаме сигурно 2 кибани където се логват от всичките подове на к8с какво ли не, но скоро и всеки стейтмънт от кода ще лигваме дали е минал или не.
Хах, един ентърпраз архитект ми викаше, че "требе да виждам голямата картинка". Много се хранихме с него, но си имаме некво уважение. Той си знаеше, че го бива в "чертаенето на чертички и квадратчета", аз си знаех че ме бива в 1-2 технологиийки и все пак не се правихме на "голуемите специалисти". 😅
Ама нема идеално решение за всичко - то реално в архитектурите, едно нещо е за сметка на друго винаги. Реши ми CAP теоремата и следващото събитие го правя в "твоя възхвала" - обещавам ти. Ще измисля как да го направя (да не изглежда педалско докато обяснявам на публиката), ама ще обясня как "един архитект е измислил ебати решението на тоя проблем" (то и аз ще намажа от славата, та верно ще направя такова събитие).
Аа аз бих се молил. За много неща съм мрънкал и на шефове и на C-Level-и. Те за тва и ме hate-ят половината меринджеи, а другата ме уважават. От KPMG за туй ме махнаха, щото нахраних една руса Senior меринджейка. Ама колегата дето ми е наследил проекта вика, че въпреки всичко ми четат документацията дето оставих и ми споменават името. 😎 Дето е казал Вазов:
"Един ще жали, друг ще ме проклина,. но мойте песни все ще се четат."
Та удрии смело - ако ония CTO е пич, ще вземе решение. Ако не е - не си блъскай залудо нервите заради тъпизма на другите хора.
А щом имате сървърни логове пак добре - а бе лека полека ще го дебъгнете, ама ей такива low, low level "не технически проблеми" ме демотивират да работя. 😓
П.П. Във връзка с love-hate relationship-a ми с меринджеите. Е преди месец един C-Level от ScaleBokus ми писа да се връщам, ама му казах, че "засега не мисла". Ще пробвам да се продам за чужбина догодина, па ако не стане ще им искам 10+k и ако дадат се връщам.
synergie
Създадено на 29.08.2022, видяно: 561 пъти. #67225
За не знам кой път искаш да конкретизитам. Истинския архитект трябва да има решение за всичко без много детайли :) Но ето още един детайл - парите не са проблем. Бачкам за милиардери, 30к зелено на месец за тях е все едно ти си отишал на циганка в Бургас.
Цялата фирма със сите й продукти се търгува в nasdaq. Даже ако искаш си купи от акциите й. За да се търгува обаче има едни compliance лайна де ти стъжват живота. Едно от тях е, че трябва да се молиш и да имаш одобрение от цто-то ако искаш да се вържеш към стейдж/прод бази независимо за какво. Та ти ще изревеш ли в тази ситуация?
Сървърни логове... Имаме 2 кибани където се логват от всичките подове на к8с какво ли не, но скоро и всеки стейтмънт от кода ще логваме дали е минал или не.
Големия фън ще е като се насере нещо следобед наше време, клиентитее бръмчат и ще почнат да се губят яко пари, докато аз чакам цто-то да се събуди за одобрение на другия край на планетата :)
Добре бе стуйка, оплели сте се яко, ясно, ама толко ли не може да изчакате да стане 9 сутринта у Индия като се събуди главния архитект да реши проблема?
За не знам кой път искаш да конкретизитам. Истинския архитект трябва да има решение за всичко без много детайли :) Но ето още един детайл - парите не са проблем. Бачкам за милиардери, 30к зелено на месец за тях е все едно ти си отишал на циганка в Бургас.
Цялата фирма със сите й продукти се търгува в nasdaq. Даже ако искаш си купи от акциите й. За да се търгува обаче има едни compliance лайна де ти стъжват живота. Едно от тях е, че трябва да се молиш и да имаш одобрение от цто-то ако искаш да се вържеш към стейдж/прод бази независимо за какво. Та ти ще изревеш ли в тази ситуация?
Сървърни логове... Имаме 2 кибани където се логват от всичките подове на к8с какво ли не, но скоро и всеки стейтмънт от кода ще логваме дали е минал или не.
Големия фън ще е като се насере нещо следобед наше време, клиентитее бръмчат и ще почнат да се губят яко пари, докато аз чакам цто-то да се събуди за одобрение на другия край на планетата :)
Добре бе стуйка, оплели сте се яко, ясно, ама толко ли не може да изчакате да стане 9 сутринта у Индия като се събуди главния архитект да реши проблема?
Аха, да, ако не бях мижав контрактор сигурно щях да мина през Факултето да сбера вашият главен и да похарчим заедно ваучерите си за кренвирши в Билата.
Са, на Единьо нема се подигравам, че е млад и неопитен и не е виждал ама наистина гигантски проект с десетки бази данни зад него. Като цяло из еоод-тата, в които интернет коментаторите скатават (в това число и повечето от читателите тук) обикновено нямат достъп до такива проекти.
И за майстора на невронни мрежи с интерполиращи функции за диагностика на размер за джапанки написан на питоня, уважаемият Синжир Баба, ще поясня кратко и ясно.
Генерират се репорти в комбинация от агрегация между десетки бази(наблягам на БАЗИ, а не на БАЗА) , както и се дърпат солидно количество мета данни от рест и grpc базирани сървиси. Всичко това е обилно полято със сървърен код, който се изпълнва преди да се върне репорта.
Така, имаме всички възможни юнит и ацептънс тестове. Всичко точно. Дали може да си издърпаш стейдж или продъкшън базите локално? Цената за хостване и бекъп на стейджа и прод базите беше около 31700 долара на месец в последната сметка.
Така, обаче въпреки всичко някъде в полетата на репорта нещо е грешно. И не се улавя от тестовете. Ам уви в цялата схема от куерита, агрегации, трансформации и проекции някъде нещо се е засрало.
Та да видим сенсеите на форума какво ще направят :) Очаквам от Единьо да изкара нещо де не го знам от торбата със сертификатите си, а Синжира както винаги ще ми каже, че съм педерас и мижав контрактор и ще се скрие обратно в дупката си където коди на питон за сигурна заплатка и ваучери за храна, рупайки фафли Чайка.
Мойта реакция: Кой по дяволите (who the fuck) генерира сложни репорти он дъ флай от множествени бази данни, че и проудкционна, транзакционална база?
Има си аналитична база данни, където лайната са преселектирани за репортите.
Мойта реакция: Кой по дяволите (who the fuck) генерира сложни репорти он дъ флай от множествени бази данни, че и проудкционна, транзакционална база?
Има си аналитична база данни, където лайната са преселектирани за репортите.
Ем принципно е така - ама глей, че се циганят за staging на мултимилиарден проект. 😒
А и в случая не бих ги критикувал баш за тва, щото не знаеш къв шит може да са базите и дали лесно и ефективно могат да врътнат един Extract-Transform-Load процес, че да мандръсат данните в аналитичната база. Може да има още един куп ограничения и лайна за които Стюи го е "срам да каже".
Но примерно в Dynamics 365, репортите се изпълняват успешно ако се генерират за 5 минути. Та за 5 минути "кой ебал - ебал", ако отнеме повече генерирането се фърла грешка. Та с бая сериозни архитекти съм си говорил (поне 3-ма; един италианец и един немец идваха до БГ по един проект, a и един много добър нашенец ме интервюира баш за тоя проблем) и единственото решение е да си направиш reporting таблица (викат му entity у тоя bullshit) и за всека операция Create, Delete, Update и др. да променяш данните у reporting таблицата.
И пак - ако успееш да генерираш после репорт върху една таблица за 5 мин, кеф, ако не - духаш на Баце Били големия Core.
Та не му знаеш на Стюи проблема. Туй ме кефи у тая IT сфера - има яко абсурдни проблеми. Ако тръгнеш да ги обясняваш на хора извън IT-то (и вземат, че те разберат) ще си помислят, че сме "тухладжии", а не "иноватори градящи бъдещето на Света". 😄
П.П. Ограничението от 5 минути е наложено, щото Dynamics 365 е у Azure и да не харчат "некви селяни" ресурсите на целия cloud. Ама пак е шит (нищо, че е основателен). Малко като при коврите - плащаш си за час, а то 5 минути. 😅
Мойта реакция: Кой по дяволите (who the fuck) генерира сложни репорти он дъ флай от множествени бази данни, че и проудкционна, транзакционална база?
Има си аналитична база данни, където лайната са преселектирани за репортите.
Ем принципно е така - ама глей, че се циганят за staging на мултимилиарден проект. 😒
А и в случая не бих ги критикувал баш за тва, щото не знаеш къв шит може да са базите и дали лесно и ефективно могат да врътнат един Extract-Transform-Load процес, че да мандръсат данните в аналитичната база. Може да има още един куп ограничения и лайна за които Стюи го е "срам да каже".
Но примерно в Dynamics 365, репортите се изпълняват успешно ако се генерират за 5 минути. Та за 5 минути "кой ебал - ебал", ако отнеме повече генерирането се фърла грешка. Та с бая сериозни архитекти съм си говорил (поне 3-ма; един италианец и един немец идваха до БГ по един проект, a и един много добър нашенец ме интервюира баш за тоя проблем) и единственото решение е да си направиш reporting таблица (викат му entity у тоя bullshit) и за всека операция Create, Delete, Update и др. да променяш данните у reporting таблицата.
И пак - ако успееш да генерираш после репорт върху една таблица за 5 мин, кеф, ако не - духаш на Баце Били големия Core.
Та не му знаеш на Стюи проблема. Туй ме кефи у тая IT сфера - има яко абсурдни проблеми. Ако тръгнеш да ги обясняваш на хора извън IT-то (и вземат, че те разберат) ще си помислят, че сме "тухладжии", а не "иноватори градящи бъдещето на Света". 😅
Ко? Не! Веднъж на ден когато има най-малко трафик към трансакционалната(ните) база(и) се стартира сървис, който прави селекциите и ги дъмпва в аналитичната база.
При този процес може да се сложат най-различни логове да се види има ли нещо сбъркано някъде.
Мойта реакция: Кой по дяволите (who the fuck) генерира сложни репорти он дъ флай от множествени бази данни, че и проудкционна, транзакционална база?
Има си аналитична база данни, където лайната са преселектирани за репортите.
Ем принципно е така - ама глей, че се циганят за staging на мултимилиарден проект. 😒
А и в случая не бих ги критикувал баш за тва, щото не знаеш къв шит може да са базите и дали лесно и ефективно могат да врътнат един Extract-Transform-Load процес, че да мандръсат данните в аналитичната база. Може да има още един куп ограничения и лайна за които Стюи го е "срам да каже".
Но примерно в Dynamics 365, репортите се изпълняват успешно ако се генерират за 5 минути. Та за 5 минути "кой ебал - ебал", ако отнеме повече генерирането се фърла грешка. Та с бая сериозни архитекти съм си говорил (поне 3-ма; един италианец и един немец идваха до БГ по един проект, a и един много добър нашенец ме интервюира баш за тоя проблем) и единственото решение е да си направиш reporting таблица (викат му entity у тоя bullshit) и за всека операция Create, Delete, Update и др. да променяш данните у reporting таблицата.
И пак - ако успееш да генерираш после репорт върху една таблица за 5 мин, кеф, ако не - духаш на Баце Били големия Core.
Та не му знаеш на Стюи проблема. Туй ме кефи у тая IT сфера - има яко абсурдни проблеми. Ако тръгнеш да ги обясняваш на хора извън IT-то (и вземат, че те разберат) ще си помислят, че сме "тухладжии", а не "иноватори градящи бъдещето на Света". 😅
Ко? Не! Веднъж на ден когато има най-малко трафик към трансакционалната(ните) база(и) се стартира сървис, който прави селекциите и ги дъмпва в аналитичната база.
При този процес може да се сложат най-различни логове да се види има ли нещо сбъркано някъде.
🤔 Хм, тая манджа звучи вкусно. Туй може да сработи. Стига да немат некви супер bullshit регулации и органичения на ресурсите и да викнат:
"Ама немаме ресурси да изпълняваме сървис дет да върши толкоз работа!"
Поддържал съм "сървъра" на некъв селянин-балканджия и баровец (шеф на IT фирма) дето на сървър с 8 GB има инсталиран CRM (с минимални изисквания от 4 GB RAM), ERP (с минимални изисквания от 8 GB RAM) и публичен уебсайт. И тоя "сървър" падаше поне веднъж седмично. Но поне шефа караше нови коли всека година.
Но такава цигания да има у мултимелеарден проект - ще е ебати IT селото. Не вервам.
"Транзакционна", а не "транзакционална" се нарича. Добре, че не написа и релационна :)
Викаш дълбоко сме сгрешили, защото твоето решение е по-добро. Май пишеше някакви ui хуйни ако не се лъжа, а фронтендаджиите като ми дават акъл и си вземам пуканките.
Репортите са много малка част от услугите, и да всеки ноsql ще издъхне, и да търсиме в посока къде да мигрираме само частта за тях. Междувременно някой трябва да се грижи за тях. И не, с немци не работя. Какво друго видя като си погледна в чашата с кафе - cqrs-a и той ли ти се появи? Ми grpc-то?
Веднъж на ден се дъмпвало в аналитичната база, ахахаха. Огромни данни в реално време не си копал явно, ама требе се обадиш и ти като синжира.
Единьо, не разбра пак, не са проблем парите. Заради комплаянс шитните не можем си клонираме продъкшана ей тъй. Дори наскоро ни вземаха достъпа до секюрити репликите, къстъм секюрити апи и великият ни тунинг на IS4, за който трябва да си чувал.
Веднъж на ден се дъмпвало в аналитичната база, ахахаха. Огромни данни в реално време не си копал явно, ама требе се обадиш и ти като синжира.
Единьо, не разбра пак, не са проблем парите. Заради комплаянс шитните не можем си клонираме продъкшана ей тъй. Дори наскоро ни вземаха достъпа до секюрити репликите, къстъм секюрити апи и великият ни тунинг на IS4, за който трябва да си чувал.
Ахаа - и мене това ме учуди. Или е некъв "експерт" и знае как се dump-ват данни от бази, или май не е в час. То за тоя хуй си има "Data Warehouse архитектури", ама ся ако почнете да ги мислите - бая кинта, време и шитня ще мине. Не е добре тая посока.
А и казали са хората:
"С малка диня не можеш да се наядеш, но с малка база - можеш да се наебеш!"😏
И много зависи от комплексността на данните когато правиш такива ETL маневри, а тука щом става дума за "10-ки бази", тепърва да се тръгва в тая посока е "простотийка".
Но мога да ти предложа следното - все пак сме хора християни:
Отиди да запалиш една свещичка за проекта ти и да се помолиш! 🕯🕍
На един проект с едни италианци така предложих на колегите да направим, че се беше увъртел яко. След година го завършихме. Може и на теб да помогне.
"Транзакционна", а не "транзакционална" се нарича. Добре, че не написа и релационна :)
Викаш дълбоко сме сгрешили, защото твоето решение е по-добро. Май пишеше някакви ui хуйни ако не се лъжа, а фронтендаджиите като ми дават акъл и си вземам пуканките.
Репортите са много малка част от услугите, и да всеки ноsql ще издъхне, и да търсиме в посока къде да мигрираме само частта за тях. Междувременно някой трябва да се грижи за тях. И не, с немци не работя. Какво друго видя като си погледна в чашата с кафе - cqrs-a и той ли ти се появи? Ми grpc-то?
Веднъж на ден се дъмпвало в аналитичната база, ахахаха. Огромни данни в реално време не си копал явно, ама требе се обадиш и ти като синжира.
Единьо, не разбра пак, не са проблем парите. Заради комплаянс шитните не можем си клонираме продъкшана ей тъй. Дори наскоро ни вземаха достъпа до секюрити репликите, къстъм секюрити апи и великият ни тунинг на IS4, за който трябва да си чувал.
Пиша много работи и UI и сървиси за тях и бакенд за за сървисите. Най различни работи според каквото се иска. Действително не съм писал бакенд за репорти, но съм им брал гайлето когато локнаха транзакционалната база данни.