<bgdev />free

| |  


All tags 2023 9may ai algorithm alpha amd american api argon2 arm asm asmbb assembler attachment awareness balgaria bay888 bcrypt bender beta bgdev-next bgdev-next.👍 big.data bitchnigga bitcoin bmw boi borg brexit bug bulgaria business c cad chat cloud computer-names console crossorigin deprivation desktop dna dotnet email eupl falling feature forum foundation fp fresh fun game gcc github goats google gpl gpt gpt.3.5 gypsies happiness harvard hash improvement include investment it java javascript js kleta kleta.maqka.balg lambi language learning leftovers legend level levenshtein.dist libx license linkedlist linux m0 ma mcafee mele microsoft minimag minimalism negro net nginx nigga not.a.bug oop paradigm parler patterns perception persuasion pipe play.station politics populi pornhub pow pro programming protonmail python reba rust sci-fi scripting seks seo server shell sleep smartbeauty soft-skills sqlite srabska sse starship sugerface syntax tablet tailwindcss telegram theme thug troll80lvl tutanota typescript uacme ui uk unix untermensch upload uptime usa utilities ux vb via viber virtual.reality vox vps vulnerable war wasm weapons-grade web windows word x86 xbox xss youtube zig ziglang Übermensch БОКЕБЪЛГАРИН БЪ БЪлгария Белезниците Били Били.Белезниците БялДонор Веган Виста Възраждане ГЛУПАК Гана Глиста ЕС Казарма Копейкин Мода.и.овча.мисъ НЕКАДЪРНИК НРБ ПО-ЗЛЕ.И.ОТ.РАБИ Подкасти Разни Румен СИК СКУМ СетенЧук Скум ТИР Туче Украйна Урсула Яначков авангард аз айфонджия алгоритми амбиции анархизъм антиваксъри армения аудио аутисти бази.данни бакъп без без.пръчове безпросвета бенчмарк биготи биомаса бира боклук борисов ботев брадва булшит бъг бъгове бял ваксина вандал век венерика викинги вицове вишу война вървежен гана ганорник гей гейщина германия герои гешев глупак говеда групировка гюбек данъкоплатец двойни.стандарти дедотия демокрация дизайн дисциплина добитък докери долар донори држава дришльо дрон ебане еврогейски.съюз езици експеримент електроника електроника.s2 емиграция ендпойнт енум ерген ергономия жалкар задача затоплизъм защита здраве златен злато игри идеали идиократ идиократи идиокрация идиот избори избори.рабин изкуство икономика имбецили имейл инвестиране инокулация инструмента интервю ипад искам.да.си.реда казах камшикодържач капитализъм карабах караница картечница кино клавиатура ковид19 колайдер колям.кур комари комплексар комунизъм консолидация конспирации космонавтика кофа кофит-19 краставица криптовалути курви кучелюбци лайно лаладжия лаптоп либерастия литература лоши.практики луд лъжеучени лъжец любов майни майтапи малоумници мафия мениджмънт месо местене метавселена метафизика механика мистика мисъл мода мода.овча.мисъл модерация морал мутра мутри наука национализъм не.it негър некадърник некадърници неон нидерландия овча овчи олигофрени организация офтопик парички партия педал пенджури пенсия пишока плюскане победа погромист поезия политика порно посредствен почивка празници прасе превод предалщина програмиране проект проста простотии против.правилата проф пръч пръч.дришльо пръчка психика психични.болести психология пустиняк путин путката путьо рабин рабин.е.шибан.пе работа радост разврат разни разработка расизъм резерват рейтинг реклама рекламен религия рест ризи ропче ропчета русия руски.език рутина самоковска сасипаха секира село селяндур сериали сериозно.програм сетен сеянин симулация скопяване скръм слушалки сортиране софия софтуер софтуни социализъм спектрометър спринтове сране стандарти стил стуйо стюи сушилня сцена съвет съм сън сървър сърничка таб ташаци телевизия тема територията терминология термояд технологии титли традиция тролинг тръмп туба туче тъпак тъпанари тъпня уиндоус украйна умнокрасивци фалит фантастика фашизъм фейк.акаунти физика филми форум форумни.проекти футбол хазарт хамали харабия хардуер хахаха хомофобия хостинг храна хумор цайко цайси целофан цензура цензурра циганин чалга чалгар чекии чернокраки честота чипове чнг чужбина чук шпация щайга юан яката яко ям 🔨 😂 🪓


Patterns'n'shit

  

0 1 2 3 4 5 6 7 8


  Дон Реба  Създадено на 06.08.2020, видяно: 2237 пъти. #3107

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

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



  johnfound  Създадено на 06.08.2020, видяно: 2234 пъти. #3109
Дон Реба

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

Всъщност има, но той не се харесва на джендърите, защото е много просташки. А моделът е абсолютно еко, природно натурален. Пряко следствие от същността на компютрите.

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

Но за съжаление мейнстрийма го е страх от такъв подход:

АБС

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



  Дон Реба  Създадено на 06.08.2020, видяно: 2218 пъти. #3110
johnfound

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

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



  johnfound  Последно редактирано на 06.08.2020 от johnfound, видяно: 2212 пъти. #3111
Дон Реба

...или ти си единствения който се е сетил за това, или просто не е вярно. кое според тебе е по-вероятния вариант?

Откъде накъде "или-или"??? Разбира се, че не съм единственият който се е сетил за това.

Какво да говорим, когато ти самият преди два поста написа същото и колко си бил потресен от ефекта.



  Rabin  Последно редактирано на 06.08.2020 от Rabin, видяно: 2055 пъти. #3112

Най-потресающия грандиозен провал, в който по неволя участвах. Начи у лъскава западна столица, техния бизнес парк до горичката. Отдел на международна многомилиардна Корпорация. Голяма сграда с офиси, наще заели цели 2 етажа и пишат новия велик ERP дето ще връти мелеардите. Получавам язе почти завръшения им проект, и очите ми не верват кво виждат. Тия се мъчили да пишат собствено ORM, ама толкоз смотано, че ако някой се освести как се мапва обект, то след макс. 2 чАса го е забравил, като след събуждане от лош сън. Почвам да мрънкям язе, на всичко отгоре не се билдва с мавенжийницата.

Отиваме там на място да си подкарат лайната. Инак сичко по Скум, буквално кибичат прави сутрин по половин час, и то не къв да е Скум, ами международен. Един конферентен телефон на средата на залата, и се надвикват с още един такъв екип от другия край на света. Ние бяхме ларж и не застанахме на един крак, а нащо шефче по едно време заспа за малко, буквално. Сичко по TDD писано, 2 реда да бутнеш и сичко тръгва да се ребилдва и тества наново. Диви интерфейси и патърни, свет да ти се извие. Фикснах един бъг, системата беше толкова тромава и опропастена, че фиксът ми тъй и не успя да се добере до репото. Една камара огледални сървъри, екип DevOps да го прави по книга да връви, и нищо не бачка накрая. Па да кажа, туй не у кмб, ми у огромна мега Корпорация. Накрая биг Бос се усети кви лайна са натворили по стандарт, угаси ламбите и ни прати сичките на борсата. Чужденците за 5 цифрено в евро, назе за 5 цифрено в лева. Та така с големите науки. А можеха да си турят някой безплатен ORM дето бачка...

Толкоз беше насрано, че аз лично не се сещам кой може да оправи толкоз много сбръкана работа на ено место. Трябваше да се почне наново. Имаха си дедо архитект дето го е натворил, и ни учеше на ум и разум назе туземците, кво велико дело е TDD със 100% test coverage. За отдела на ганите няма нужда да поменувам. Кокошарникът стигаше за 2 футболни отбора на Симитли.



  Courvoisier  Създадено на 06.08.2020, видяно: 2185 пъти. #3113

Ако пускаш постоянно на прод с CI/CD, лично мисля, че трябва да имаш поне смоук тестове, bare minimum, даже Unit Test-овете са ти нужни. Трябва да си нагласил девопсването, ако си с кубернетес е лесно, но ако си с 2-3 виртуалки зад балансер пишеш скриптове яко. Обаче интегрираш по- малки части. Друг добър похват е да имаш feature switch. Първо даваш новата функционалност на малко клиенти и ако работи, тогава на повече. Ако ти спре бизнеса за всички е гадно, но ако ти спред за 10% някакви по-евтини мастии и можеш бързо да го изключиш, защо не. Струва ми се по- оптимално да съм баш lean, пиша, тестват, UA, Prod. Така интегрирам по- малко неща наведнъж. Но ако съм копал feature-и 2 месеца или повече и трябва да ъпдейтвам нещо голямо, трябва да кибича повече време с админите и опсовете по нощите и накрая ни будят след 3 часа да връщаме версия, не е приятно. На малки стъпки интеграцията ми се струва по- безболезнена.



  Golden Gega  Създадено на 06.08.2020, видяно: 2182 пъти. #3114

Най-малко код да, обаче как се мери най-малкото? Зад един ред код може да стои метод с 10к редове и още незнайно колко други в извиквани от него методи.

В големи системи, писани много време и от много хора има три метода които подобряват една система - импакт анализ, концентрация на логика и TCO анализ. Т.е. може да се окаже по-добре да се махне/пренапише даден метод, например да се добавят нови 1000 реда вместо да се напише нов метод със 100 реда, ако това ще концентрира логика. За последното - добре е да се смята TCO-то в правилен интервал - т.е. може в текущия проблем да се загуби повече време, ако това ще намали цената в по-дълъг план. От друга страна един бърз фикс и преработка наново по-късно може да избегне големи щети.

Са тия неща са отвлечени и малко встрани от Истинското програмиране и Архитектуриране, но е хубаво да се знае че големите бизнес системи рядко са в застой - те винаги се развиват или поне се опитват да го правят. Има два варианта на развитие - в единия системата независимо от нарастването си се оптимизира, става по-гъвкава и по-приятна за работа, и другия - става по-раздута, по-тромава, по рабиноидна - т.е. с повече претенции и с по-малко реална полза.

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



  Courvoisier  Последно редактирано на 06.08.2020 от Courvoisier, видяно: 2181 пъти. #3115

Дай малко акъл как се управлява ИТ проект, че само с копане не става. А как убеждаваш C-Level-ите, че това е нирваната. В крайна сметка чичковците с пари натискат да се вадят пари по-бързо. Ако не им го представя в сметки, няма да ми обърнат внимание. А ако сбъркам сметките, може да си ходя. И така навлизаме в едно делегиране на решенията отгоре надолу, блеймоспективи, комплейнспективи, Гошо от 10-ти етаж го реши това, аз му казах да си караме по старому, ще го махнем и няма да има проблеми. Горните мениджъри ще разиграят цирк да си запазят мястото, то такова място не се отваря всеки ден.



  Rabin  Последно редактирано на 06.08.2020 от Rabin, видяно: 2055 пъти. #3116

Пропуснах да напиша, че тяхната Гана караше нова служебна расова бегачка. Само единия фар струваше повече от заплата при назе. Като станат на 4 години им ги сменят, че остарели. Колегата искаше да купи някоя такава 4 годишна остарелница, ама на нас южняците не се полагало. Държаха шефчето по 6 чАса на конферентни разговори. Софтуер за големи мелеони изисква многочасови разговори. После тотален краш по учебник. Някой от вас едва ли е виждал толкоз насрана архитектура. Просто не е за вярване.

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

3 (ТРИ) отдела с админи си имат. По печес човека у собичка и си геедат у мониторите. Ужас и безумие. И ме пратили менека да им оправям бакиите. Близо 100 виртуалки имаха у вътрешната мрежа. Дори не съм админ на щат, ми го правя щото няма кой друг.



  Courvoisier  Създадено на 06.08.2020, видяно: 2168 пъти. #3117

Рабе, кажи си, че и ти искаш да си С-level, с всичките благини на това :D



  bvbfan  Създадено на 06.08.2020, видяно: 2166 пъти. #3118
Дон Реба
johnfound

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

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

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



  Rabin  Последно редактирано на 06.08.2020 от Rabin, видяно: 2055 пъти. #3119
Courvoisier

Рабе, кажи си, че и ти искаш да си С-level, с всичките благини на това :D

Искам да съм това дето съм в момента. Тъпото е, че изисква големи мангизи за да стане в обозрим срок. Нямам мелеоните на Ганите, и пълзя във времето. Ейго иде зима, и хангар нямам дори.

Ако съм незнам кой левъл в Корпорация, ще трябва на 100 % да пърформя корпоративен шит. Гади ми се от тия неща. До такава степен са насрали занаята ни, че 10 човека вършат работа за един. У казармения форум (ега ин го турнье слон) имаше една тема за SOLID. Гюро е часниче и пише софт дето го купуват многомелеардници. Гюро също отрича залитанията в патърни и корпоративен шит.



  Дон Реба  Създадено на 06.08.2020, видяно: 2158 пъти. #3120
bvbfan

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

то всички сме на тоя принцип, но само "понякога", и той като всички останали велики патерни е верен самоза част от случаите. в другите , там където не е валиден, смело скачаме в езерото с лайна и плуваме юнашката



  Golden Gega  Създадено на 06.08.2020, видяно: 2154 пъти. #3121
Courvoisier

Ако не им го представя в сметки, няма да ми обърнат внимание.

Отиваме малко в управление на чичковщина, не на проект.

Като едно добро начало - ти си напред с материала, първото правило в управлението на чичковци/Гани е да представиш сметка. И когато те я пренебрегнат, се инкасират загуби. След като загубите достигнат едно критично ниво се задейства защитния механизъм и чичкото почва да разбира че с чичковщина пари не стават или поне не достатъчно. Почват анализи, и първата стъпка към подобрението е когато чичо има добре представена сметка, в която може да види алтернатива. Едно добро правило е на чичкото да не се дава акъл какво решение да вземе, а да се представят варианти. Никой (вкл. чичото) не се ражда научен, и в основата на ученето е да избираш и да страдаш при грешни решения. Най-тъпото което можеш да направиш с един чичко е да го караш да взима решение, така той свиква да си бара чичовеца и да разчита на теб, съответно да не мисли и да прави глупости.

В предоставянето на сметки също има разни интересни детайли, един добър вариант е дадена сметка да се дава в интервал (min, max) и с делта като %, което за умния чичко подсказва доколко сметката е сигурна според сметкаджията. В класическия вариант се дава едно число, и тогава оставяш на чичото да определя доколко е вероятна преценката за нещо.

Като резюме - не се опитвай да промениш системата ако не си мениджър и нямаш права да я променяш. Давай варианти, върши твоята работа и оставяй отговорните да взимат решения и да поемат вината за грешните.



  Rabin  Последно редактирано на 06.08.2020 от Rabin, видяно: 2055 пъти. #3122
Golden Gega

Като резюме - не се опитвай да промениш системата ако не си мениджър и нямаш права да я променяш. Давай варианти, върши твоята работа и оставяй отговорните да взимат решения и да поемат вината за грешните.

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



  bvbfan  Създадено на 06.08.2020, видяно: 2147 пъти. #3123
Дон Реба

то всички сме на тоя принцип, но само "понякога", и той като всички останали велики патерни е верен самоза част от случаите. в другите , там където не е валиден, смело скачаме в езерото с лайна и плуваме юнашката

Как така само понякога? Аз имам предвид най-малкото код, който върши работата, не най-малкото код, който решава част от работата.



  johnfound  Създадено на 06.08.2020, видяно: 2147 пъти. #3124
Golden Gega

Най-малко код да, обаче как се мери най-малкото? Зад един ред код може да стои метод с 10к редове и още незнайно колко други в извиквани от него методи.

Лично аз меря кода в бинарни байтове. Тоест, не е важно колко реда е сорса ами колко е после изпълнимият файл.

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

Ако се използва език с интерпретатор - то кода на програмата плюс интерпретатора.

Разбира се, точна преценка е много трудно или даже невъзможно да се направи. Но важното е да има стремеж към минимизиране на кода при проектирането на проекта и после при написването му.



  Rabin  Последно редактирано на 06.08.2020 от Rabin, видяно: 2055 пъти. #3126

Жони не те знам как мериш кода, ама като ви слушам със Стилгара го мерите с рулетката.

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

Аз с твоя асемблер съм го ял немит!

п.с. Аве ти ли беше хостнал за Дзен в кодолеярството. Много удачно би се вписало в тоя форум.



  Golden Gega  Създадено на 06.08.2020, видяно: 2232 пъти. #3127
Rabin
Golden Gega

Като резюме - не се опитвай да промениш системата ако не си мениджър и нямаш права да я променяш. Давай варианти, върши твоята работа и оставяй отговорните да взимат решения и да поемат вината за грешните.

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

Нали се разбрахме че от робче кирлив джуньо (като теб) до робче синиър и нагоре (като останалите) има мааалка разлика?



  Golden Gega  Създадено на 06.08.2020, видяно: 2231 пъти. #3128
johnfound
Golden Gega

Най-малко код да, обаче как се мери най-малкото? Зад един ред код може да стои метод с 10к редове и още незнайно колко други в извиквани от него методи.

Лично аз меря кода в бинарни байтове. Тоест, не е важно колко реда е сорса ами колко е после изпълнимият файл.

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

Ако се използва език с интерпретатор - то кода на програмата плюс интерпретатора.

Разбира се, точна преценка е много трудно или даже невъзможно да се направи. Но важното е да има стремеж към минимизиране на кода при проектирането на проекта и после при написването му.

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


0 1 2 3 4 5 6 7 8


Patterns'n'shit

  



AsmBB v3.0 (check-in: 7544654b24928b93); SQLite v3.47.0 (check-in: 03a9703e27c44437);
©2016..2024 John Found; Licensed under EUPL; Powered by Assembly language Created with Fresh IDE