Tā, kā mums nav topika, kurā postot lietas par specifiski šo tēmu, tad izdomāju uzbliezt. Droši vien, ka programming memes arī jāposto šeit, jo vairums cilvēku tās nesaprot anyway.
Sākšu ar šo:
https://education.oracle.com/mysql-promo
1 Like
At first, sounds interesting, but then:
jj log satur, on first glance, nevajadzīgu info (divi commit hashi? wut?), un info nav sakārtota pareizā secībā (why the hell commit useris ir pirms timestamp? timestamp ir fixed width, commit useru e-pastu garums ir mainīgs).
Nav branchu, jeb, pareizāk sakot, kkādi dīvaini tie branchi… 
Faktiski es varu tās pašas lietas izdarīt krietni ērtāk un ātrāk caur IntelliJ Git integrāciju. Vienkārši šis ir tāds fancy flex priekš termināļu nerdiem.
Nu flex IT vienmer felt kinda dumb. Like ok dude we get it you soo cool. Well actually we dont care we just want things run smooth.
I personally believe creating is not art AI already do that. Art is making already existing things better.
2 Likes
Programming is a hobby like any other.
Yes, but creating GOOD stuff that’s appreciated by others is a form of art.
So I guess people should just stop creating art because AI can do some forms of art? Maaaaaan…
Manuprāt tu biki pārprati domu(vai drīzāk nedalāmi domu sadalīji divās daļās) . Arguments bija ka lietu rādīšana pati pa sevi nav māksla un ar šo bezmākslas radīšanu ļoti labi nodarbojas AI
Viņa doma bija, ka programmēšana nav mākslas forma, un ka AI jau tāpat programmē.
Tas nekas, ka programmē slikti.
Es, savukārt, uzskatu, ka kvalitatīvs kods ir mākslas forma (kuru, protams, saprot tikai retais).
Nu un tas, ka AI “padara jau esošās lietas labākas”, ir subjektīvi un stipri atkarīgs no pielietojuma. Katrā ziņā programmēšanā es šim apgalvojumam nepiekrītu; jā, tas teorētiski padara programmēšanu ātrāku (darba devēja pātaga dzen!), bet noteikti ne kvalitatīvāku, technical debt tikai turpina augt.
Jautājums kas ir kvalitatīvs kods? Viegli lasāms? Kam lasāms citiem vai sev? tur tā lieta mes gribām art standartizēt un tas uzreiz is approval. To pašu jau dara AI stadartizē. Protams jo sarežģitāks tasks jo vajag vairāk ko standartizēt. Vai tā ir māksla nu nez. Maksla liekās personiska. Nevis robotizēta.
1 Like
Tāds, kas ir viegli maināms. Tas izriet no nosaukuma - Software. Ja mēs vēlētos, lai to būtu grūti mainīt, tad mēs to gan jau ka sauktu par Hardware 
.
2 Likes
Loģiski, ka viegli lasāms vairumam programmētāju.
Kurš pie velna grib standartizēt mākslu?? WTF? Eww! Viss prikols mākslā ir tajā, ka katram māksliniekam ir savs pieskāriens! Ja visi taisītu vienādi, tad priekš kam tādi mākslinieki vajadzīgi?
Tas jau ir atkarīgs no sarežģītības. Ne visu kodu ir iespējams uzrakstīt tā, ka tas ir viegli maināms, lai kā to gribētos. Ir kods, kurš vienkārši nepieciešamības spiests ir sarežģīts, vnk smaga biznesa loģika. Tāds kods tipiski ir diezgan nefleksabls, bet pa lielam perfekti pilda savu darbu. Var būt viegli vai grūti kaut ko pamainīt, atkarībā no nepieciešamajām izmaiņām, bet kamēr nepieciešamās izmaiņas nav baigi lielas, tikmēr ir ok - leave it as is, don’t fix what’s not broken just because you want to “make it better”, because it’s most likely a waste of time. Bet ja pienāk punkts, kad nepieciešamas būtiskas izmaiņas (piemēram, performance bottleneck spiež būtiski pārtaisīt data handling), tad ir sūdi. Tad ir divi varianti:
A) refactoring little bit by bit - takes time and planning, but can be done step by step and will give guaranteed results (provided you’re not an idiot)
B) complete rewrite - te vajag plānot vēl vairāk nekā refactoring, jo vajag izdomāt kaut ko jaunu, kas ir vismaz vairumā aspektu labāks par iepriekšējo versiju, citādāk nav jēgas.
Ar kaut kādu maksimāli component/composable architecture based system ir tāda būtiska problēma, ka jo vairāk funkcionalitātes, jo vairāk pieaug komponenšu skaits, un tipiski ne lineāri, jo nereti lielai komponentei vajag vēl X mazākas child komponentes. Rezultātā, tā vietā, lai būtu, piemēram, viena klase (+ optionally kāda saujiņa mazu DTO klasīšu) ar kinda nefleksablu, bet viegli lasāmu un highly performant kodu, tev ir 101 komponente, kura varbūt nav liela, bet tās visas salikt prātā kopā, lai saprastu, kā pie velna tas viss reāli strādā, ir nereāli. Un tev kā programmētājam VAJAG saprast, kā tas viss strādā kopā, lai spētu pareizi un efektīvi veikt izmaiņas.
TL;DR: It’s a balancing game. Es, personīgi, izvēlos pēc iespējas vienkāršāku arhitektūru, kura man sniedz pietiekami daudz fleksibilitātes manām vajadzībām. Pēc manas pieredzes, ļoti daudzi citi programmētāji mīl lieki sarežģīt lietas, un tad tērē nejēdzīgi daudz laika, strādājot ar to jumbled mess, jo viņi vienkārši nav spējīgi paturēt prātā visu procesa plūsmu no input līdz output - jo tas vienkārši ir pārāk sarežģīts.
Izklausās vairāk pēc nepārdomātas sistēmas arhitektūras.
Biznesa loģika parasti nav nemaz tik sarežģīta, ja tā tiešām ir tikai biznesa loģika, kas ne uz ko nedependojas. Sarežģītākais, kas tur varētu būt ir matemātika, vai kaut kādi dīvaini industrijas specifiski noteikumi, kuru gadījumā, ja ir grūtības lasīt, tad gan jau ka pašam izstrādātājam trūkst zināšanu par doto industriju.
Komponenšu ziņā es nedomāju, ka būtu jādomā par visu sistēmu kopumā. Ja, lai veiktu papildinājumu/izmaiņas, jādomā par visu sistēmu, tad tas izklausās pēc spageti koda.
Godīgi sakot šis neizklausās pareizi. Piemēram, ja tiek prasīts pievienot jaunu, vēl neredzētu fīču, tad tas visticamāk aizskars vairākas dažādas komponentes, kas tā arī var būt ne-spageti koda sistēmas gadījumā.
Var būt ka tad labi pārdomāta arhitektūra būtu tāda, kur varētu mainīt katru komponenti atsevišķi, neatkarīgi no citām. Labi pārdomāta sistēma ļautu veikt izmaiņas/papildinājumus nepieprasot uzreiz mainīt pārējās komponentes.
Un gan jau ka labs kods ir tāds, kas ļauj pastāvēt šādai labi pārdomātai arhitektūrai.
^
Tajā kodā, ar kādu man ir nācies strādāt, ir bijušas situācijas, kad ir čupa ar corner-cases, kurus ir jāparedz, citādāk būs sūdi, un katram corner-case var būt čupa sava atsevišķa koda.
Nekā dīvaina vai industrijas specifiska, vienkārši “šajā gadījumā jāparedz varianti A, B, C, D un E, un katram ir nepieciešama vismaz nedaudz, bet tipiski krietni citādāka turpmākā loģika”. Complexity by necessity. Such is life.
Vienmēr ir jādomā par visu sistēmu kopumā. Ja tu nedomāsi par visu sistēmu kopumā, kā reiz tad technical debt/spaghetti code is guaranteed.
Nav iespējams, ka komponente, kas pēc definīcijas ir daļa no vesela, ir bezgalīgi maināma, šīm izmaiņām neietekmējot veselo vai citas komponentes.
Bet ja to ignorē, tad tas ir basically the whole idea behind microservices, bet, kā mēs zinam, tad šī padarīšana kinda izkrita no popularitātes, jo tā iekrita manis iepriekš aprakstītajā balancing game overengineered atzarā. Ja tev ir projekts, kas sastāv no 20 mikroservisiem, katram savs Git repo, varbūt pat katram sava komanda - it becomes a PITA to manage changes between them. Pat ja tie mikroservisi individuāli nav baigi lieli.
Jo vairāk pieaug sarežģītība, jo vairāk krītas produktivitāte. Tāpēc tas ir balancing game. Sapņot par infinitely flexible kodu var, bet tas nav reālistiski, vismaz ne cilvēka prātam. Te, protams, var naivi sapņot par programmētāju pilnīgu aizstāšanu ar AI, bet līdz tam vēl ir kāds laiciņš, un tas, iespējams, nemaz nebūs tik izdevīgi, jo AI tomēr prasa būtiskus resursus.
Nē, nav gan. Mainot UI nebūtu jādomā par datubāzi. Mainot biznesa loģiku nebūtu jādomā par komunikācijas moduļiem ar ārējo pasauli. Mainot motora draiveri nebūtu jādomā par skaņas draiveri. Moduļi tāpēc arī ir moduļi ka tie ir modulāri.
Nav svarīgi vai microservices, vai arī monolīta lietojumprogramma. Šī ideja ir implementējama visur.
Varbūt no sākta gala nebija jāveido 20 ar 20 dažādām komandām . Citādi nav diži ieguvuma no šiem “savstarpēji atsaistītiem” mikroservisiem, ja tie ir tik cieši saistīti.
Ok, es to nebiju domājis tādā ziņā, bet gan kā “mainot daļu no vesela, ir jādomā par veselo”. UI un datubāze īsti nav divas daļas no vesela, manā izpratnē tās ir divas dažādas sistēmas. Es šeit ar “sistēmu” nedomāju visu produktu kopumā (websaitam, piemēram, ir gan UI, gan datubāze), es šeit domāju abstrakto terminu.
Ja doma ir sadalīt sistēmu pa moduļiem (lai individuālos moduļus “vieglāk” menedžētu), tad tie apriori ir saistīti. Un ja tie ir saistīti, tad kaut kādos brīžos - tipiski bieži - neizbēgami būs situācijas, kad jāveic izmaiņas vairākos moduļos, lai panāktu vienas fīčas implementāciju, un šīs izmaiņas ir jākoordinē starp moduļiem un cilvēkiem, kas ar tiem moduļiem strādā. Jo smalkāk tu sadali sistēmu pa moduļiem, jo vairāk nepieciešamo izmaiņu vairāk moduļos, jo vairāk koordinācijas, un… balancing game.
Ja šie mikroservisi NAV savstarpēji saistīti, tad tās ir faktiski pilnīgi atsevišķas sistēmas, un par to mēs šeit nerunājam.
Faktiski, ja nav reāla nepieciešamība izdalīt kaut kādu daļu sistēmas kā atsevišķu moduli (e.g. for reusability elsewhere), tad nafig to nevajag darīt. “Just because it’s hip right now” is the most retarded reason to do anything.
Izcilā gadījumā jaunas fīčas tiek implementētas rakstot jaunu kodu, nevis papildinot esošo. Laba arhitektūra to panāk ar veiksmīgiem moduļu interfeisiem, kas ļauj tajos iespraust ko vajag.
Protams panākt tik veiksmīgu arhitektūru ir sarežģīti. Taču tiecoties pēc tās kods paliks labāks.
good example is d1 it was literal shit but the something like lighting in bottle. you can see passion, that is what art is a struggle to express. btw d1 my fav game ever.
more of diablo 1 meme:
1 Like
Nereti esošā koda papildināšana tieši ir jauna fīča. Pielikt jaunu IF bloku esošajā kodā, šā tā pamainīt esošu IF bloku, pielikt jaunu pogu esošajā lapā, pielikt jaunu modālo blakus esošajiem, utt.
Nu vot, kad sākas runa par interfeisiem, tad sākas arī overengineering. Ja tava sistēma kaut par 1/3 sastāv no interfeisiem un to implementācijām, tad tā jau IMO ir problēma, it īpaši, ja ir daudz interfeisu ar tikai vienu implementāciju, kā bieži arī ir, pēc manas pieredzes.
