- Член од
- 24 март 2010
- Мислења
- 15.284
- Поени од реакции
- 26.164
Или ќе користат ORMs и нема да го реизмислуваат тркалото.
Ne ti ja svakjam poentata, ne znam na so mislis (tehnicki). Probuvam da ti dolovam kako funkcionira sekoj biznis, od it do elektro do sanitarija.A ako ne e, kje ostavat povekje kverinja da pravat update na eden record od db vo ist moment? Da receme cena na proizvod ili balance na smetka?
ОРМ е на апликациско ниво, имаш во ист момент 3 исти дб реквести од три различни апликации што пробуваат да селектираат дата од една табела и со тие вредности да апдејтуваат рекорди од друга табела, SELECT statement не прави lock на рекордите/редовите од табелата кои што ги селектира така што друга трансакција може да ги апдејтира тие вредности и SELECT statement от од три различни дб рекевсти да ти даде три различни вредности, а треба да бидат исти.Или ќе користат ORMs и нема да го реизмислуваат тркалото.
Муабетот ми беше дека има различни ситуации. Ако луѓето што ти ја одржуваат инфраструктурата те коштаат помалце од 5% од цената на инфраструктурата, и те како ти се исплаќа да вложиш во нив. Да успеат да ја намалат цената за 2%, ќе бидеш на 0 за нивниот ефорт (а да бидеме реални, оптимизација не е единсвтвена работа на девОпс) а секоја натамошна оптимизација ќе ти биде профит.Сигурно не ја одржува цела инфраструктура еден човек
Немој да го дупни паметот некој да почне да бара начини да ве оптимизира, оти не постои проект и фирма каде што не може да се крати ако се заменат одредени луѓе и процеси.
Бројот на requests не кажува многу за инфраструктурата во позадина. Затоа прашав за query/transactions бидејќи тоа многу подобро го објаснува load-ot на системот.На најзахтевната апликација имаме ~милион конкурентни јузери, што креираат неколку милиони (7-8) реквести кон API во минута, кон база немам проверено, ама знаејќи ја технологијата сигурно е бар 10-15 кверија по АПИ реквест.
И целата таа инфраструктура е сложена. Има реплики, сегментација по географија, кеширање, балансирање. И секако дека имаме дев опс луѓе што го работат тоа. Ама од 60, секогаш се истите тројца што знаат да средат нешто. Другите 57 менуваат параметри.
И да, имаме инженери што го разбираат се тоа што е иссетирано. Како би триажирале проблем инаку?
Како што имаме инженери што немаат поим кај се наоѓаат. Не ми е поентата девопс не треба, девелоперите се гении.
Повеќето девелопери го делат ова мислење. Мислењето на сопствениците и менаџментот секогаш ќе биде пристрасно, иако знаат дека си потполно во право. Нивниот став е дека цедење тројца генералисти е подобро од вработување од секој сегмент/сектор по најмалку двајца.Она што се обидувам да го доловам е дека е глупо да се збори дека нема потреба од специјализација, кога во некои случаи таа е неопходна.
Ќе се бара оптимизација и во големите фирми, во места каде што сега имало 60, за 1-2 години од сега ќе има 20 и ќе покриваат дури и повеќе проекти.Муабетот ми беше дека има различни ситуации. Ако луѓето што ти ја одржуваат инфраструктурата те коштаат помалце од 5% од цената на инфраструктурата, и те како ти се исплаќа да вложиш во нив. Да успеат да ја намалат цената за 2%, ќе бидеш на 0 за нивниот ефорт (а да бидеме реални, оптимизација не е единсвтвена работа на девОпс) а секоја натамошна оптимизација ќе ти биде профит.
Е сеа нормално ако имаш мала фирма и плаќаш 30к годишно за инфраструктура, не ти се исплаќа да запослиш човек за оптимизација, како што кажа ти во твојот пример.
Она што се обидувам да го доловам е дека е глупо да се збори дека нема потреба од специјализација, кога во некои случаи таа е неопходна.
Бројот на requests не кажува многу за инфраструктурата во позадина. Затоа прашав за query/transactions бидејќи тоа многу подобро го објаснува load-ot на системот.
Но нејсе, да се вратиме на муабетот.
Муабетот дојде од тоа дека луѓето треба да бидат сестрани, да учат повеќе работи, бидејќи во спротивно нема да се снајдат.
Мојот аргумент беше дека во големи фирми (како ете и твојата, со 60 девОпс луѓе) секогаш ќе има потреба од специјализација.
И самиот кажуваш дека имате 60 девОпс луѓе од кои 3 знаат доволно. Е сеа, рандом БЕ девелопер може да ги замени тие тројца? Ако овие 57 само менуваат параметри, тогаш зошто ги чувате? Што не му дадете на некој БЕ дев да менува параметри 20-30 минути секој ден и готово.
Она што го зборам е дека специјализацијата е неопходна. И во самите дев тимови, сигурно луѓето се специјализрани одредени работи. Сигурно некој работи на микросервисите за автентикација, друг работи на микросервисите за user management а трет на процесирање на фактури.
Сигурно нема еден ден таск за фактури, друг ден таск за user management, а трет ден таск за нешто шесто. Ако има девелопери кои работат на сите делови, тогаш системот едноставно не е доволно голем.
Ова е веќе муабет за квалитетот на работниците. Ние претходно зборевме за специјализација.....
Па види, ако тројца генералисти може да им ги решат проблемите, тогаш и ти да си газда би вработил тројца генералисти. Муабетот е дека не може се да решиш со генералисти. Го имав и јас тој mindset кога работев во фирма кај што земав проект и го сработував од од планирање, до целосен сетап на продукција (клуч на рака што пиша некој) ама кога ќе видиш како изгледа поголем и покомплициран проект сфаќаш дека едноставно не е можно тоа.Повеќето девелопери го делат ова мислење. Мислењето на сопствениците и менаџментот секогаш ќе биде пристрасно, иако знаат дека си потполно во право. Нивниот став е дека цедење тројца генералисти е подобро од вработување од секој сегмент/сектор по најмалку двајца.
Не е само до квалитетот, туку и колку работат тие што ги имаш.Ова е веќе муабет за квалитетот на работниците. Ние претходно зборевме за специјализација.
Во однос на големите фирми, не е дека тие ги прават тие вработувања наивно. Вработија еден куп луѓе во короната, покажуваа growth, ги растеа цените на акциите. Сеа ќе ги избркаат пола од тие, ќе намалат трошоци и пак ќе имаат growth. За некоја година ќе почнат пак нагло да вработуваат, и кругот ќе почне пак.
Па види, ако тројца генералисти може да им ги решат проблемите, тогаш и ти да си газда би вработил тројца генералисти. Муабетот е дека не може се да решиш со генералисти. Го имав и јас тој mindset кога работев во фирма кај што земав проект и го сработував од од планирање, до целосен сетап на продукција (клуч на рака што пиша некој) ама кога ќе видиш како изгледа поголем и покомплициран проект сфаќаш дека едноставно не е можно тоа.
Или ќе користат ORMs и нема да го реизмислуваат тркалото.
Se iznasmeav taka sabajlecki na razmenava.ОРМ е на апликациско ниво, имаш во ист момент 3 исти дб реквести од три различни апликации што пробуваат да селектираат дата од една табела и со тие вредности да апдејтуваат рекорди од друга табела, SELECT statement не прави lock на рекордите/редовите од табелата кои што ги селектира така што друга трансакција може да ги апдејтира тие вредности и SELECT statement от од три различни дб рекевсти да ти даде три различни вредности, а треба да бидат исти.
НЕ мора да крене ништо,ќе биде поспоро со serializable, секоја трансакција ќе биде комплетно изолирана и за read, insert, update. Ти треба select for update, тогаш прави лок на редовите селектирани според критериумите во statement отSe iznasmeav taka sabajlecki na razmenava.
Inglorious nema pojma za sto zboruva zmejot posto Inglorious raboti so baza od segasniot milenium, kako i 90% od IT industrijata.
Zmeju, ova sto go opisuvas se reseni problemi vo PG. Postgres i koga cita nekomitirano kveri ne dozvoluva prljavo citanje (toa ti sto go opisuvash). Znaci i da se zaebe nekoj admin da go spusti nivoto na izolacija na PG baza na "uncommited" pak nema da moze da procita nekomitirano kveri.
Ponataka, retko koj menuva nivo na izolacija na postgres posto PG po default e konfiguriran kako "repeatable read" sto go resava i problemot so fantomski citanja bez da bide premnogu obstruktiven.
Za da go postignes istovo na MySQL ili MariaDB, treba nekoj DB admin da vleze vo baza i racno da go krene nivoto na izolacija vo "seriallizable", sto pak ako me prasuvas mene e nepotrebno obstruktivno.
Прегледај го приврзокот 420097
Така де, сите сме имале такви колеги. Тука збориме за неефикасно работење на фирмата, ама тоа си е за сосема друга тема. И јас би вработил консултат и би го плаќал по саат за работа за која што немам цело време потреба. Само немој да мислиш дека и тој консултатот нема да проба да ги игра саатите (наместо пинг понг да игра).Не е само до квалитетот, туку и колку работат тие што ги имаш.
Паметам времиња кога имав колеги што во денот имаа по 1.5 ефективен саат, другото време муабетче, троа интернет, пинг понг и пикадо, па некој состанок каде апсолутно немаше потреба да се појават, малку социјални мрежи и денот поминал.
Налет тоа, туку шефовите нивни бараа и уште кадар, а ни тековниот не работеше ништо.
Истовремено другите си ебававме матер и по 14 саати, ама овој "требал" на проектот и ќе се шлае по цел ден.
За такви позиции овде најчесто се земаат консултанти на договор, го плаќаш премиум дневница, ама не ти треба 12 месеци туку само 3 месеци по 20 саати неделно. На крај мора да достави детално документација, покриен е со осигурување ако заебе нешто,и додека е на проект работи, ако ја направиш математиката доаѓа далеку поефтино.
За вакви проекти како кај змеј може да ги ангажираш само за продукција, инаку ќе си брка работа сам девелоперот.
Во ред, мислам дека не се разбравме. Јас не викам дека специјализација е лоша. Напротив. Ама од 1000 вработени, 50 ќе ти бидат специјалисти. Не може 900.Така де, сите сме имале такви колеги. Тука збориме за неефикасно работење на фирмата, ама тоа си е за сосема друга тема. И јас би вработил консултат и би го плаќал по саат за работа за која што немам цело време потреба. Само немој да мислиш дека и тој консултатот нема да проба да ги игра саатите (наместо пинг понг да игра).
Се ова зависи од луѓето (вработените и работодавачите).
Јас не знам како е кај вас, ама според agile методологија секој си има тикет и се знае на што ќе се работи тој ден и си има дејли на кое тоа се утврдува, а си има и спринт планинг за да се креираат доволно тикети и да се утврдат кои се целите на спринтот. Мене работниот ден не ми стига, после работно време често останувам, не па цел ден пинг-понг да плешам. Ако имате девелопери кои не го поштуваат тоа, не знам што ги чувате...Во ред, мислам дека не се разбравме. Јас не викам дека специјализација е лоша. Напротив. Ама од 1000 вработени, 50 ќе ти бидат специјалисти. Не може 900.
А денешната реалност е дека 90% од луѓето во индустријава си измислуваат експертиза, додека денот го трошат на баналности. Проблемот е што долго време тоа поминуваше, и луѓето се убедија себеси дека сите се глупи, и не знаат дека баналностите не се тешки за правење.
Не мислев да кажам дека луѓето што си ја работат работата супер, и имаат многу сериозна експертиза на некоја тема ќе останат без работа. Напротив. Ама тие ќе бидат консултанти најчесто.
Se iznasmeav taka sabajlecki na razmenava.
Inglorious nema pojma za sto zboruva zmejot posto Inglorious raboti so baza od segasniot milenium, kako i 90% od IT industrijata.
Zmeju, ova sto go opisuvas se reseni problemi vo PG. Postgres i koga cita nekomitirano kveri ne dozvoluva prljavo citanje (toa ti sto go opisuvash). Znaci i da se zaebe nekoj admin da go spusti nivoto na izolacija na PG baza na "uncommited" pak nema da moze da procita nekomitirano kveri.
Ponataka, retko koj menuva nivo na izolacija na postgres posto PG po default e konfiguriran kako "repeatable read" sto go resava i problemot so fantomski citanja bez da bide premnogu obstruktiven. Vo pogled na izolacija PG e dosta strog i namenet da raboti OOTB.
Za da go postignes istovo na MySQL ili MariaDB, treba nekoj DB admin da vleze vo baza i racno da go krene nivoto na izolacija vo "seriallizable", sto pak ako me prasuvas mene e nepotrebno obstruktivno.
Прегледај го приврзокот 420097
Затоа ќе имаш некој што разбира, пред неколку страни муабетот беше дека некогаш е непредвидливо и може да се изгуби време, тоа е, некогаш зијан фирмата, некогаш консултантот, за времето секогаш е војување.Така де, сите сме имале такви колеги. Тука збориме за неефикасно работење на фирмата, ама тоа си е за сосема друга тема. И јас би вработил консултат и би го плаќал по саат за работа за која што немам цело време потреба. Само немој да мислиш дека и тој консултатот нема да проба да ги игра саатите (наместо пинг понг да игра).
Се ова зависи од луѓето (вработените и работодавачите).
Брат, да пробам некој совет да ти дадам за ова прекувременто работење. Си размислил ли зошто работиш повеќе од колку што можеш да постигнеш во тие 8 саати?Јас не знам како е кај вас, ама според agile методологија секој си има тикет и се знае на што ќе се работи тој ден и си има дејли на кое тоа се утврдува, а си има и спринт планинг за да се креираат доволно тикети и да се утврдат кои се целите на спринтот. Мене работниот ден не ми стига, после работно време често останувам, не па цел ден пинг-понг да плешам. Ако имате девелопери кои не го поштуваат тоа, не знам што ги чувате...
НА крај краева си има и скрам мастер и проект менаџер кои цело време те прашуваат за статус до кај си.