Új hozzászólás Aktív témák
-
Ha már van valami a túloldali serpenyőben, tehát a nagyobb fogyasztás mondjuk valós munkaerő-megtakarítást eredményez, akkor már nem beszélhetünk tiszta pazarlásról, hanem érdemes mérlegelni.
Sajnos azonban gyakran nem ez a helyzet, hanem érdemi előny nélkül van egy csomó helyen nagyobb fogyasztású gép.
Egyébként az egyenlet / egyenlőtlenség fordítva is igaz: az is pazarlás, ha a munkaerőt tétlen várakozásra kényszerítjük, amíg a gép dolgozik. De ez inkább régen volt jellemző.
MaCS
Fán nem lehet motorozni, motoron viszont lehet fázni!
-
olbaidhun
őstag
A szenvedély szavunk nagyon szépen rámutat erre. Kifejező. Nem kockaság az, ha hasonló dologban leli az ember az örömét. Télen nem mindenki járhat el horgászni, prémet begyűjteni.
Musk papi jól ráérzett erre. Fel is szippantotta a legtehetségesebbeket sok területről. Neki sokat jelent a hatékonyság. Szemben a többi gyártóval meg is reformál egy ipart.
7o/638-9O93 ► Telón érsz el leghamarabb \_(ツ)_/
-
gabor.79
aktív tag
"Alapvetően itt szembe kerül a profit vs alacsony fogyasztás. Amíg a vas olcsóbb mint a munkaóra addig a kutyát nem fogja érdekelni hogy mennyit eszik a gép ha 10 perc alatt össze lehet haxxolni valamit ami pazarol vagy több nap mire összekalapálódik egy hatékony megoldás."
Szerintem ez azért összetettebb. Korábban többször kértek meg, hogy segítsek be website-ok fejlesztésébe, és használjunk jQuery-t vagy egyéb rutinkönyvtárakat, keretrendszereket. Egy idő után rájöttem, hogy ilyenkor kapunk egy kockát, amit gömb formájúra kell kalapálnom, ami vagy sikerül vagy nem, mert az adott eszköz ezt vagy megengedi vagy nem. És számomra egyszerűbb és sokkal gyorsabb nulláról megírni, mint a korlátokkal bajlódni, még úgy is, ha ismerem a működését.
Jó példa erre a redizájnolt prohardver család, ahol bootstrap-et használtak. Lehet, hogy írok belőle cikket, a lényeg, hogy kevesebb munkával el lehet érni ugyanazt az eredményt (kinézetre), sokkal gyorsabb lenne a megjelenítés, jóval kevesebb memóriát fogyasztana, és azt már le sem merem írni, hogy egy húszéves böngészőben is tökéletesen használható lenne.
A másik, hogy ezek a harmadik féltől származó komponensek általánosan vannak megírva, és sok absztrakciós réteget tartalmaznak. Ha ilyenekből dobálsz össze egy rendszert, akkor az tipikusan akkor működik jól, ha a kicsi a képernyőn megjelenítendő elemszám.És arról sem szabad elfelejtkezni, hogy nem tudhatjuk, a felhasználónak milyen hardvere van: lehet, hogy egy i9, de lehet, hogy egy tízéves Atom. Ha valaki nem tudja megnézni az oldalt/használni a szolgáltatást, az pénzveszteség.
Még egy példa: valamelyik nap azzal kellett foglalkoznom, hogy a rendszerünkbe kellett integrálni a Mailchimp marketingeszközt. Rákerestem a neten, találtam egy php scriptet, nem nagy, tizenhat kilobájt, szépen dokumentált, gyönyörű, OOP kód, húsz metódus. Belekukkantottam, és elkezdtem értelmezni a kódot, formázni stb.
Aztán láttam, hogy sok benne a mellébeszélés, kitöröltem belőle a felesleget, amit lehetett, összevontam. Az eredmény egy darab négy kilobájtos függvény, ami pontosan ugyanazt a végeredményt adja.
Ez nem egyedi eset, sok hasonlót csináltam már. Nagyon sokszor jóval több munkával oldják meg a feladatot, mint ami szükséges, és ez minden érintettnél sokba kerül (idő, pénz, sebesség).
Új hozzászólás Aktív témák
lo Minél nagyobb teljesítmény, minél nagyobb számok? Nem, ez az írás azoknak szól, akik a minél kisebbeket keresik.
