Már Java alapokon hasít a Tesco útvonaltervező motorja (x)

Hirdetés

Újraírta áruszállításhoz használt útvonaltervező motorjának egy részét a Tesco Technology magyar fejlesztőcsapata. A korábbi Python alapokat Java váltotta, az eredmény pedig tizenhatodára csökkent futásidő, hatékonyabb szállítások, félmillió font megspórolt cloud költség és kevesebb üzemanyag.

Mára a vásárlókat az áruházaknak egyszerre két fronton is ki kell tudniuk szolgálni: a rohamosan növekvő online rendelésekhez, illetve a fizikai üzletekbe betérő ügyfelek számára is megfelelő árukészlettel kell rendelkezniük. A hatalmas árumennyiségek célba juttatása a logisztikai központokból az üzletekbe mind az utakon, mind pedig a leghatékonyabb kiszállítási útvonalak megtervezésénél komoly erőforrásokat igényel.

A Tesco kötelékében az áruk optimális célba juttatásán a Tesco Technology budapesti fejlesztői dolgoznak, az útvonalak megtervezéséről a Transport and Fulfillment csapat által fejlesztett Hive gondoskodik - amely már az idei Craft konferencián is bemutatkozott. A csapat már bizonyított, a koronavírus-járvány miatt ugrásszerűen megugró rendelésszámok jelentette kihívást is az ő megoldásaiknak köszönhetően tudta leküzdeni az áruházlánc.

A legjobb útvonalak megtervezése során a fejlesztőknek egy jól ismert "feladványt", az utazó ügynök problémáját kell megoldaniuk. A rendelt árukkal megpakolt járműveket a lehető leggyorsabban kell eljuttatni az üzletekbe, majd vissza a központokba, az aktuális forgalmi viszonyokat, akár időleges útakadályokat, lezárásokat is számításba véve - persze a lehető legkisebb üzemanyag-fogyasztással.

Nehezített pálya

A vállalat ehhez már az előző években kifejlesztette saját gráfmotorját és routing engine-jét – miután a piacon elérhető kész megoldások között egy sem volt, amely megfelelően igazodott volna az áruházlánc igényeihez. Ez egyébként annyira nem is meglepő: a szoftvernek az Egyesült Királyságban lévő négyezer Tesco-telephelyről napi szinten induló hétezer teherautó útvonalát kell kiszámolnia. Mindezt ráadásul nehezítő körülmények mellett. Figyelembe kell venni például az egyes brit városokban éjszaka a teherforgalom elől elzárt utakat, illetve „észben tartani” a 26 féle járműtípust - kellemetlen lehet, ha utólag derül ki, hogy a teherautó felépítménye magasabb, mint a navigáció által kijelölt alagút bejárata.

Bár a gráfmotorral a vállalat valóban hatékonyan tudta terelgetni az áruszállító flottáját, a megoldás eredetileg Pythonban íródott (még a Tesco Technology egyik fejlesztőjének doktori munkájaként), ami nem éppen visszafogott erőforrásétvággyal és tekintélyes felhős költségekkel járt. A fejlesztőcsapat ezért már az elmúlt években elkezdett dolgozni a gráfmotor jóval hatékonyabb, Java verzióján, amely mára munkába is állt – és nem meglepő módon látványos teljesítménybeli előrelépést produkál.

Míg a Python verziónak nagyjából 1 óra 20 percre volt szüksége a gráf felépítéséhez, addig a Java alapokra építő variáns ugyanezzel a feladattal 3-5 perc alatt végez. Természetesen az ugrásszerű javulás nem kizárólag a két programozási nyelv sajátosságaiból adódik, a fejlesztőcsapat egy sor optimalizációt is elvégzett a rendszer Javára való átültetése során.

Gyorsabb futás, olcsóbb infra

A Tesco Technology új Java alapú megoldásával nem csak a szigorúan vett árufuvarozási költségeken spórolhat az áruházlánc, de az erőforráskímélőbb működésnek hála a felhős infrastruktúra is számottevően barátságosabb árakon biztosítható: míg korábban a Hive éves cloud költsége a vállalatnál nagyságrendileg az 1 millió fonthoz közelített, mára közelebb áll a félmillió fonthoz.

De az utakon mérhető spórolás is tiszteletet parancsoló: a Tesco a tavalyi évben a rendszernek köszönhetően 5,3 millió kilogrammal csökkentette szén-dioxid kibocsátását. Az optimalizált útvonalakon a járművek összesen mintegy 4,6 millióval kevesebb mérföldet kellett hogy megtegyenek – ez értelemszerűen az üzemanyagfogyasztás csökkenésében is megmutatkozott. Ezen a téren a cég tavaly 2,3 millió fonttal költött kevesebbet. Az áruházlánc idei várakozásai pedig még látványosabbak: a Tesco 2022-ben 13 millió kilogrammal kevesebb CO2 kibocsátásra, 11,4 millióval kevesebb megtett mérföldre és 5,7 millió fontos üzemanyagköltség-megtakarításra számít.

A Tesco Technology budapesti csapata folyamatosan bővül: a gráfmotorhoz hasonló, izgalmas projektekhez a vállalat főként "V-shaped" fejlesztőket keres: például egy Java fejlesztő esetében a "V" hegye jelöli a mély Java tudást, míg a kiterjedő szárak a különböző, horizontális kompetenciákat tartalmazzák. Ilyen lehet a DevOps vagy épp a prezentációs és üzleti kapcsolattartási képességek, amelyekkel hatékonyan be tudnak kapcsolódni Tesco Technology Magyarországon zajló, globálisan alkalmazott fejlesztéseibe – akár távmunkán keresztül, amit a vállalat maximálisan támogat.

[A Tesco Technology megbízásából készített, fizetett anyag.]

( arpi_esp v | 2022. 08. 29., h – 18:42 )

> Python alapokat Java váltotta, az eredmény pedig tizenhatodára csökkent futásidő

ahelyett hogy kiprobaltak volna a pypy-t :)

A pypy bizonyos workloadokra tud gyorsítani, de a GIL miatt többszálú futtatásra nem lesz olyan jó, mint egy modern JVM vagy SubstrateVM AOT-val.

Ha már mindenképpen Python, akkor a mypyc és a GraalPython lehetne jó irány, de mindkettő a fejlesztők saját bevallása szerint erősen alpha állapotban van...

Már csak azt nem értem, hogy hova tűnt a kommentem második fele. :)
 

Szóval a nogil patchről leírás: https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0/

Viszont talán a 3.11-ben lesz mimalloc, ami a nogil patchből jön és legalább a mallocnak nem kell majd GIL: https://github.com/python/cpython/pull/31164

( Hevi v | 2022. 08. 29., h – 18:51 )

...főként "V-shaped" fejlesztőket keres: például egy Java fejlesztő esetében a "V" hegye jelöli a mély Java tudást...

Érdekes, én ezt "T-shaped"-nek ismertem.

A T szára a mély tudás, a T teteje pedig a különböző egyéb kompetenciákat jelöli.

Nem mintha nagyon fontos lenne, a V-shaped is érthető kifejezés.

Pont azért linkeltem a toolingokat, amik nem az adatbázis, hanem az azon való navigálást szolgálják, és még van pár ilyen engine.

KAMI | 神
Linux Mint: https://linuxmint.hu LibreOffice: http://libreoffice.hu SeaMonkey : http://is.gd/smhun
Legyél Te is Mozilla és Linux Mint önkéntes

Figyelembe kell venni például az egyes brit városokban éjszaka a teherforgalom elől elzárt utakat, illetve „észben tartani” a 26 féle járműtípust - kellemetlen lehet, ha utólag derül ki, hogy a teherautó felépítménye magasabb, mint a navigáció által kijelölt alagút bejárata.

Ilyeneket nem tud az open-source routing.

emlexem amikor Bp-n elindult a szoftver-vezerelt taxi kiosztas a korabbi urh-s ki-nyom-gyorsabban helyett. es a program azt nezte melyik taxis van a legkozelebb. eloszor legvonalban, de azt nem szerettek, aztan atalltak arra, hogy utvonalat tervezett es megnezte melyik erne oda eloszor. de valami teheraru-szallitashoz keszult utvonalkalkulatort vettek meg es az ugye nem nagyon tervezett a belvarosba, vagy a szomszed utcaba is az M0-an at akart eljutni... szoval igen nagyon nem mindegy a tervezo milyen gepjarmutipusra es idopontra szamol.

Biztos lehet benne NIH szindróma is, de a másik oldalról: mind az utas.hu, mind a futar.bkk.hu alatt meg van mókolva az open source OTP motor, sőt, picit máshogy, nem tudnak helyi sajátosságokat out of the box.

A vasúton meg talán már sikerült lenyomni a 3 motort kettőre, az 1371-es EU rendelet MÁV-os értelmezése miatt ugyanis az útvonaltervezés nem elválasztható a jegyértékesítéstől: a belső doktrina szerint kötelező a leggyorsabb (oké), legrövidebb (minek?) és legolcsóbb(!) utakat is kilistázni.

namost onnantól kezdve h az a kérdés, mi a “legolcsóbb”, tudni kell a delikvens életkorát és igazolványkészletét (65 feletti, 14 alatti, interrail, stb), a csodálatos regionális kedvezményrendszert, az IC felár napi állását (szerdáról szombatra véve van hogy olcsóbb mint aznap) A leggyorsabbat is kétféleképp lehet értelmezni: ami legelőször érkezik, vagy ami a legrövidebb idő alatt van ott - ha megjelensz a pénztárban hogy most mennél, valószínű az előbbire vágysz, de ha egy hétvégi utazást tervezel, inkább az utóbbit értheted alatta.

az esetek 99%-ában az utas valami helyi vasutat akar csak (váci gyors tipikusan, esetleg mizse), vagy IC-zik az egyik nagyvárosba, esetleg a Balatonra és kb ennyi, a maradék 1% teszi ki a kód 99%-át - csakhogy törvényi kötelezettség.

Szóval ezért van custom engine-je a MÁVnak (meg amúgy a DBahn-nak is), és nem lehet simán el-OTP-zgetni. 
 

Simán el tudom képzelni, hogy valami hasonló nyavaja van a tesco-nál is, ami miatt üzletileg megéri hogy sajátot fejlesszenek, ami mondjuk csak balra kanyarodik és fordítva megy be az egyirányúba, mittomén, a lényeg hogy ez lehet versenyelőny amivel olcsóbb mint a konkurencia.

Simán el tudom képzelni, hogy valami hasonló nyavaja van a tesco-nál is, ami miatt üzletileg megéri hogy sajátot fejlesszenek, ami mondjuk csak balra kanyarodik és fordítva megy be az egyirányúba, mittomén, a lényeg hogy ez lehet versenyelőny amivel olcsóbb mint a konkurencia.

Le van írva n+1 helyen egyébként, hogy a Tesco nem egy A-ból B-be jutó útvonalat számol ki, hanem van x darab szállítandó csomag néhány fontosabb jellemzővel, mint a dimenziója, hűtendő-e, satöbbi, amit y darab címre kell át és kiszállítani és van z darab jármű, amivel ezek megoldhatóak. Tehát leegyszerűsítve: azt kell kidobnia a rendszernek, hogy mikor, hol, mivel és milyen sorrendben pakolják meg a teherautókat, majd azok milyen útvonalon dobják le a csomagokat és melyik telephelyre menjenek új csomagokért.

https://iotguru.cloud

Másrészt ez nem az OSM egyik routing szolgáltatása, amiről ebben a szálban szó van.

Egyrészt ott van az OP által linkelt wiki oldalon. Másrészt meg te sem a routingról beszélsz [1], hanem arról, hogy a routingon túl egy ennél komplexebb, optimalizációs problémát kell megoldaniuk - amire ugyancsak vannak OSS megoldások. És nyilván, ezekhez egy rahedli domain specifikus dolgot kell majd odabiggyeszteni. De meglepődnék, ha a Tesco Technology doktorandusza jobb routingot írt volna, vagy jobb constraint solvert egyedül, mint amin doktoranduszok és ipari munkások tömkelege dolgozik évek óta.

[1]: „mikor, hol, mivel és milyen sorrendben pakolják meg a teherautókat, majd azok milyen útvonalon dobják le a csomagokat és melyik telephelyre menjenek új csomagokért”

Egyrészt miből gondolod, hogy nem használtak ilyet?

„A vállalat ehhez már az előző években kifejlesztette saját gráfmotorját és routing engine-jét”. Most vagy nem sajátot fejlesztettek ki, vagy szeretnek nagyot mondani, amiért van ~elenyésző kontribúciójuk valamiben :)

Vagy ők az <insert-random-open-source-routing>/<insert-random-open-source-constraint-solver> fő maintainerei, csak valamiért az itteni közönségből nem nézik ki, hogy ismernék az adott eszközt.

Másrészt meg te sem a routingról beszélsz [1], hanem arról, hogy a routingon túl egy ennél komplexebb, optimalizációs problémát kell megoldaniuk - amire ugyancsak vannak OSS megoldások.

Az a helyzet, hogy a routing nem elválasztható része annak, hogy milyen sorrendben mit rakodjanak hova, mert tudni kell az útvonalon, hogy mekkora jármű fér el, tehát könnyen el tudom képzelni, hogy a térképből megfelelő formátumban és felbontással kiextrahált gráfot egyszerűbb a logisztikába beleemelni, mint külön meghívogatni egy teljesen külön élő generikus OSM funkciót, ami lehet akár bűn lassú is, mert nem volt szempont a gyorsasága vagy hatékonysága.

De meglepődnék, ha a Tesco Technology doktorandusza jobb routingot írt volna, vagy jobb constraint solvert egyedül, mint amin doktoranduszok és ipari munkások tömkelege dolgozik évek óta.

Speciálisan a céljaikra simán el tudom képzelni, hogy jobbat írnak, mert dolgozhatnak a Tesco-nál volt doktoranduszok és jó ipari munkások évek óta és el tudnak hagyni egy csomó felesleges feature-t, ami nem érdekli őket.

https://iotguru.cloud

Ha ennek megnezed az api-jat, es mikor lehet benne bellitani, akkor rajosz, hogy eleg sokmindent lehet, amire nem is gondoltal: openrouteservice.org osmand hasznalja pl. weben beallitod a preferenciakat, es a generalt api kulcsot hasznalod. Szerintem logikusan beallithato, bar vannak benne "vicces" megoldasok.

szerintem itt nemcsak a jarmu eljuttatasa A-bol B-be a feladat, hanem az egesz logisztika: A raktarban van 10tonna cukor, de azt szet kene teriteni 4 helyen. kuldjunk egyenkent a cukrot + mas egyebet a gepen, vagy inkabb egy auto jarja vegig a helyeket (es mindenhol ledob X mennyiseget)? aztan cukor mellett van liszt, sor, stb. mindez megspekelve, hogy egyik helyen a cukorbol fogy sok, masik helyen a sorbol :)

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Az a probléma, hogy csak kommentelsz, és egyszerűbb opensource-huszárkodást emlegetni.

Lehet, hogy a linkelt megoldások nem tökéletesek, de lehet egyszerűbb egy ilyet használni, mint nulláról írni egyet. Az is lehet, hogy nekik nem. De hogy semmi technikailag lényeges dolog nem derült ki a cikkből, preziből az biztos. Amúgy a megtakarításért gratula, jön ez a technológia Magyarországra is?

Sokan meg nem gondolnak bele, hogy az adott dolog, amit használnának már kész van, s lehet nem kell újraimplementálni.

KAMI | 神
Linux Mint: https://linuxmint.hu LibreOffice: http://libreoffice.hu SeaMonkey : http://is.gd/smhun
Legyél Te is Mozilla és Linux Mint önkéntes

> Volt olyan projekt, ahol akartam pl. pont Graphhoppert használni, eléggé kényelmetlen volt. 
 

Szerintem OP arra akart ravilagitani, h. legtobbszor a cegek ujra feltalaljak a kereket. Vagy azert, mert nem is tudnak arrol, h. letezik vagy hiusagbol, de nem azert, mert jobb vegeredmenyt akarnak. Igy szuletik meg az n+1. crypto/web/security framework. A szallitmanyozas-tervezesre azt gondolna az ember, h megoldott problema. Az algoritmusok ismertek, a korlatok is, kresz sem valtozott... gondolna az ember h. ez mar egy megoldott problema. Legalabbis annyira, h. nem kell a vilag tobbmillio szallitmanyozo cegenek sajat szoftvert irnia.

Nem feltétlenül. A one-size-fits all szoftverek sosem arról voltak híresek, hogy mindenre jók legyenek. Sok mindenre használhatók, de semmiben nem kiemelkedők.
Jó példa erre például a uDig/GeoTools és társai. A top Java geospatial könyvtárak és UI ezek, de bűn lassúak voltak pl. ahhoz, hogy egy iGo térképet megjelenítsenek, rajta minden elem tulajdonságaival, custom rendereléssel, míg kereskedelmi, proprietary eszközök sokszorosát tudták annak.

Jó dolog sokszor az opensource, de a jack-of-all-trades működésű libraryk sokszor elhasalnak akkor, amikor valami speciálisban kell nagyon jónak lenni.

> Jó dolog sokszor az opensource, de a jack-of-all-trades működésű libraryk sokszor elhasalnak akkor, amikor valami speciálisban kell nagyon jónak lenni.

Itt az az ertetlenseg targya, h. a Tesco nem specialis eset. Nincsenek egyedi jarmuveik, egyedi raktarkeszletuk, egyedi utvonalaik. Ugyanazok vannak, mint barmely masik szallitmanyozo cegnek - legalabbis a kulso szemlelo szamara.

Nem egy céget, cégeket. Hány cégnél láttál olyan workflow-t, ami egy az egyben egy másik cégnél használható, megvan hozzá minden szükséges input, minden szükséges outputot előállít (és itt nem a technikai dolgokról beszélek, hanem a cégben elérhető/előállítandó információktól, formátumtól, előállítási helytől függetlenül. Például az is egy workflow része, hogy Micike az aláírt papírokat iktatja az irattárban). Hány ilyen céges workflowt láttál, ami felhasználható volt egyik cégnél, a másik cég számára készített támogató szoftver pedig használható volt? Én nem tudnék egyet sem felsorolni az általam látott céges belső szoftverek közül, amelyek egy workflow támogatására vannak kihegyezve. Vannak olyan részrendszerek, amik használhatók részfeladatokra (lehet venni Sharepointot, Outlookot, lehet venni CRM rendszereket, de ezek integrációja is külön munka), de egy az egyben egyik kihegyezett workflowról egy másik cég másik workflowjára használható szoftvert még nem láttam.

Az Ocado nem konkurenciája, tök más a termékük.

Az Ocado eszközeit például hogyan tudná a Tesco a saját ellátási láncába integrálni? 

Az Ocado totál mások számára ad technológiát, mint a Tesco. A kifli.hu például tudna tőlök technológiát venni (ők online grocery), de a Tesco nem, csak egy nagyon kis szelete az online grocery a teljes logisztikájuknak.  Az Ocado end-to-end megoldást ad online groceryk számára, a Tesco nem ez.

> Az Ocado nem konkurenciája, tök más a termékük.

A penzugyi elemzoket is oktasd ki legyszives, hogy ne hasonlitgassak ossze folyton a ket ceget.

https://www.ocadogroup.com/technology/competencies/

Powerful optimisation tools enable the optimal routing of our thousands of vans each day. As an example, the best place to park on a Wednesday afternoon during school term time may be very different to the best location on a Sunday morning, and we need to know that.

To achieve this, our vans are like mobile sensing platforms. A huge amount of data such as GPS position, wheel speed, engine revs, and fuel consumption are streamed back in real time. This data is used both for real-time monitoring of the routes and to feed into our routing systems so that the routes we drive tomorrow will be even better than the ones we drove today.

https://www.modernretail.co/platforms/how-ocado-is-building-an-autonomo… .

Although Ocado has had a warehouse solutions partnership with supermarket chain Morrison’s in the U.K. since 2013, the pace of its fulfillment deals took off around 2017. That year, it struck a pact with Casino Group in France, its first international partner, and Bon Preu in Spain; followed by Canada-based Sobey’s, Sweden’s ICA and U.S. grocer Kroger in 2018; Japan’s Aeon and Australia’s Coles inked deals with Ocado in 2019, the same year it divested half of its U.K. retail business to Marks & Spencer as part of its pivot to tech; Spanish supermarket Alcampo struck a deal with Ocado in July.

Ezek nem online grocery-k. Amugy en nem erre, hanem arra reagaltam, h. miert licencelne egy ceg a konkurencianak az egyedi szoftveret. Penzert.

En itt abba is hagyom, nem latom ertelmet ezen vitazni.

Elbeszéltek egymás mellett. Szerintem:

A = {open source megoldások; piacon elérhető off-the-shelf megoldások; más cégtől licencelhető megoldások}

B = {Tesco számára kielégítő megoldások}

A Tesco döntéshozói szerint A ∩ B = ∅. Lehet, hogy tévednek, lehet, hogy nem, de ideológiát nem gyártanék mögé.

A Tesco döntéshozói szerint A ∩ B = ∅.

Általában nem ez szokott lenni, hogy egyáltalán nem jó, hanem az, hogy az A halmaz tud 100 egységnyi valamit, ebből kell 20 egységnyi valami, és kell még további 20 egységnyi valami, ami nincs benne az A-ban, belefejleszteni sokkal nagyobb meló, mint implementálni nulláról a 20+20 egységnyi valamit. A legtöbb probléma abból van, hogy egy nyílt forrású valami - ami nem alap library, hanem egy solution, sokkal több dolgot tartalmaz, mint amire szükség van és ha hozzá kell nyúlni, akkor sokkal több dologra kell figyelni, több dolgot kell érteni, illetve az API általában szent és sérthetetlen.

https://iotguru.cloud

A legtöbb probléma abból van, hogy egy nyílt forrású valami - ami nem alap library, hanem egy solution, sokkal több dolgot tartalmaz, mint amire szükség van és ha hozzá kell nyúlni, akkor sokkal több dologra kell figyelni, több dolgot kell érteni, illetve az API általában szent és sérthetetlen.

Nem feltétlen kell visszapusholni az upstreambe a változtatások jelentős részét, nem az az, ami szerintem tré ebben. És akkor máris kidobhatsz belőle rengeteg dolgot, meg viheted az API-t, amerre akarod.

Nekem továbbra is a „a megoldás eredetileg Pythonban íródott (még a Tesco Technology egyik fejlesztőjének doktori munkájaként), ami nem éppen visszafogott erőforrásétvággyal és tekintélyes felhős költségekkel járt.” büdös, nagyon not invented here szaga van. Ami nem feltétlen baj, ha arról van szó, hogy a Tesco SAP-t kellene a brit adóhivatal online interfészeihhez heggeszteni, de a sokadik A* routingot megírni a világon annyira nem izgi.

Főleg, hogy az OP-ből nem az jön le, hogy megnézték, mit tud a <random kész megoldás>, és mi nem jó belőle nekik, hanem az, hogy az egyik unatkozó IT-suk megoldása kicsúszott prodba, kiderült hogy lassú, és kurva drága üzemeltetni, de csakazért is azt reszelik tovább. Ami nem biztos, hogy így van: de sokkal izgalmasabb hirdetés lenne, ha szó lenne belőle arról, hogy melyik meglévő megoldás miért nem volt jó, nem csak annyi, hogy egy one-man-show python scriptet kell addig tutujgatni, amíg nem fut elfogadhatóan.

Nem feltétlen kell visszapusholni az upstreambe a változtatások jelentős részét, nem az az, ami szerintem tré ebben. És akkor máris kidobhatsz belőle rengeteg dolgot, meg viheted az API-t, amerre akarod.

Na, az az igazi extra szopás, amikor minden egyes nyomorult verzióváltás esetén merge conflict halmot kell feloldani és kontrollálatlanul jönnek be olyan változások, amelyek nem kompatibilisek a saját változtatásokkal, mert nem tudnak róla.

Főleg, hogy az OP-ből nem az jön le, hogy megnézték, mit tud a <random kész megoldás>, és mi nem jó belőle nekik, hanem az, hogy az egyik unatkozó IT-suk megoldása kicsúszott prodba, kiderült hogy lassú, és kurva drága üzemeltetni, de csakazért is azt reszelik tovább.

Miért feltételezed rögtön azt, hogy meg se próbáltak körülnézni a piacon?

https://iotguru.cloud

Persze, e lehet már egy adott megoldás létezik, és nem kell újra és újra feltalálni a kereket.

Például:

Biztos hogy nem tud mindent amit kell, de a routinghoz szerintem nem sokat kellene okosítani ezt a szoftvert - de kíváncsi vagyok a véleményetekre. Ahogy néztem Here maps adatokat használtak. Sajnos a leírásból nem derült ki miket néztek, és miért nem volt jó nekik. Sajnos pont az érdekes részletek nem lettek kifejtve, pedig jó lenne egy ilyen technikai portálon inkább az lenne és nem ilyen felszínes írás. Vagy legalábbis műszaki emberként engem érdekelne részletesebben a téma, hogy miket próbáltak, a Python az rossz volt tényleg, vagy nem találtak hozzá megfelelő embereket, és nem is próbálták tuningolni, mi volt a gond a meglévő megoldásokkal, miket próbáltak, miért pont Java?

Vagy akár ezek is:

KAMI | 神
Linux Mint: https://linuxmint.hu LibreOffice: http://libreoffice.hu SeaMonkey : http://is.gd/smhun
Legyél Te is Mozilla és Linux Mint önkéntes

de a routinghoz szerintem nem sokat kellene okosítani ezt a szoftvert - de kíváncsi vagyok a véleményetekre

Nos, ha már valaha próbáltál másnak a picit is nagyobb és bonyolultabb szoftverébe belehekkelni bármit utólag, akkor tudhatnád, hogy a "csak kicsit kellene okosítani a szoftvert" szinte mindig azt jelenti, hogy sokkal jobban jársz, ha tanulsz a másik megoldásaiból (jól megnézed, hogy mi jó és mi szar benne) - majd újraírod from scratch. Ez úgy kb. az esetek 90+%-ában igaz.

:-D

Ugyanez megtörtént esetben: Mivel az üzemeltetők soha nem olvasnak doksit, ezért  egy-két kiselőadást szoktam tartani átadáskor. Készítettem apró ábrákka egy A0  méretű rajzot, ahol csak a (tudjukminek) jogosultságkezelése és az ahhoz szükséges adatáramlás vázlatát ábrázoltam. Ezeken a fejtágítókon rendszeresen és lelkesen részt szokott  venni a hivatalos megbízómat képező leányzó. A lelkesedés közben a nyála folyott, bár soha nem horkolt... és ezúttal valamiért felébredt! - ÉRTEM!!!! Amikor kérek tőled egy egyszerű dolgot, akkor azért kezdesz el dadogni és mondasz egy nagy összeget, mert a rendszer k*bonyolult.

Ugyanő (feszültséglevezetésként), amikor az UDP szerver előnyeit magyaráztam: - Mi az az UDP?

Osztályvezető (merev arcizmokkal) - A TCP és az UDP hálózati protokoll.

Leányzó: - Akkor miért nem TCP?

Szintén leányzó, igaz, kis fejlesztő csapatunk szakmai irányítója és "esze", külső partnerrel egyeztetés. Szóba kerül, hogy a webes motyóban a jelszavakat titkosítva kell tárolni, jön a krédés, hogy hogyan. Mondom (kb. 20 éve volt...) sózott MD5 hash. Erre a szakmainagyonokos leányzó "mi az az emdéöt"... Lehet, hogy nem volt pol.korrekt adott körben emlékeztetni arra, hogy ennek a nem ismerete a jelenlegi pozíciójában kifejezetten nagy hiba, mert azt követően nagyon tudott utálni :-P

Egyrészt, gondolom, nincs benne logisztikai segédlet, hogy a 7000 teherautó a 4000 telephelyről a százezernyi címre milyen sorrendben vigye ki a rendelést.

Másrészt, gondolom, nem véletlenül kerül öt-tízszer annyiba a Tesco routing rendszere, mint kb. a teljes OSM üzemeltetés.

https://iotguru.cloud

( aries | 2022. 08. 30., k – 12:25 )

Nem kellene a Python v. mas szapulasat ennyire nyomni mert a hozza nem erteseteket hangsulyozza.

Szamomra sokkal szimpatikusabb lett volna, ha azt irjatok, h. a csapat nem rendelkezik akkora tudassal Python-ban, h. a legacy kodot jobb teljesitmenyre birja, ezert az alapokrol ujrairtatok Java-ban. Pozitiv szinben allitana be a menedzsmentet, hogy vegeredmeny-fokuszu, hallgat a mernokeire, ki meri dobni a meglevo megoldast.

 

 

 

 

+sok

dolgozom mind2 nyelvben, es nincs 16x kulonbseg kozottuk, ha jol van megirva. a JIT-ek/compiler implementaciok kozott lehet komoly kulonbseg, de az mind2 nyelv eseten igaz. van olyan kodom ami pypy-vel 10x gyorsabb, de olyan is, ami nem.

amugy ha jol ertem java fejlesztoket is keresnek, szoval abbol sincs sok nekik :)

"a megoldás eredetileg Pythonban íródott (még a Tesco Technology egyik fejlesztőjének doktori munkájaként)"

Az én értelmezésemben az eredeti Python kód egy túlfejlett PoC volt. Én is csináltam már ilyet, kicsit szégyellem, hogy még mindig éles üzemben működik. De mivel jól működik, nincs sürgető ok a leváltására. Ha lesz, akkor majd cikkezhet a cég, hogy leváltottunk egy gyakorló elmebeteg ötezer sor bash kódját öhhm... Ezer sor Pythonra?

( emberk | 2022. 08. 31., sze – 18:59 )

Szerkesztve: 2022. 08. 31., sze – 19:13

Mi a pythont úgy használjuk (mint szerintem szinte a világon mindenki) ha kell a kényelem és a gyorsaság, hogy írunk egy libet hozzá C-ben és élvezzük a numpy felxibilitását. a numy-hoz nagyon könnyű pár extern fügvénnyel villámgyors optimalizált funkciót összerakni. 

( _Franko_ v | 2022. 09. 01., cs – 17:57 )

A valóság nem benchmark, az utóbbi 10 évben több Python projektet is áttettem Java alapokra, volt, amelyiknél jóval nagyobb volt a teljesítmény növekedés, mert ki lehetett használni olyan Java feature-t, ami nem volt Python esetén. És persze volt olyan, ami maradt Python, mert az gyorsabb vagy egyszerűbb volt.

Van, amire a Java alkalmasabb, van amire a Python.

--

A másik dimenzió, amit esetleg érdemes figyelembe venni ilyenkor, hogy egy-két nagyságrenddel több Java-hoz értő senior ember van a piacon, mint Python-hoz értő senior, mert a Python piac tele van alacsonyan képzett, magáról igen sokat gondoló junior mentalitású emberrel. Volt olyan cég, ahol hónapokig kellett válogatni a jelentkezőket, igen sok erőforrást elpazarolva és akkor is sikerült kétszer mellé lőni, mert az ígéretes jelentkezőről kiderült, hogy igencsak hézagos a tudása. A Python könnyen elhiteti az emberrel, hogy ért hozzá, pedig...

https://iotguru.cloud

( nagylzs v | 2022. 09. 02., p – 09:09 )

Sok dolog elhangzott már, talán hozzá tudok tenni valamit. Aktívan programozom Java-ban és Python-ban is, sok sok éve. (Még Python 1.5-ös verzióval kezdtem a 90-es évek végén.) Az a tapasztalatom, hogy egy szoftver megbízhatósága és teljesítménye elsősorban attól függ, hogy mennyire minőségi programkód van alatta. A Java-ban írt végtelen ciklus pont olyan sokáig fut, mint a Python-ban írt, csak több processzort tud elhasználni. Ez az útvonaltervezési/optimizálási probléma több módon megközelíthető. A manapság legdivatosabb AI megközelítésben a számítási munka nagy részét GPU-kon végzik el, neurális hálókkal. Ilyen szempontból majdnem mindegy, hogy Java vagy Python. Mindkettőhöz van AI library, amik hasonlóan hatékonyak. A TESCO IT részlegénél valószínűleg nem az fogja jelenteni a szűk keresztmetszet, hogy nincs pénz GPU-ra. A lényegi különbség az algoritmusban és a megírt kód minőségében van. Ha jól van megírva a szoftver, akkor Python-ban se lassú, mert a Python az kb. csak annyit csinál, hogy betölti a modellt meg a feladatot a grafikus kártyákra. A Java meg pontosan ugyan ezt csinálja...

Persze meg lehet közelíteni máshogy is a problémát. Neurális hálók helyett lehet kézzel írt, CPU-n futtatott gráfos kereső algoritmusokat is írni. Ha valaki így közelíti meg a kérdést, akkor természetesen a Java sokkal hatékonyabb tud lenni, mint a Python. (De csak akkor, ha két hasonlóan jól megírt szoftvert hasonlítunk össze.)

Az eredeti cikk fontos két tényt közöl. Az egyik, hogy Python-ról áttértek Java-ra. A másik, hogy gyorsabb és hatékonyabb lett. De a lényeges részt (hogyan változott az algoritmus, és a kód minősége) kihagyták. Egy ilyen cikk főcíme alapján szerintem nincs értelme arról vitát nyitni, hogy a Python vagy a Java a jobb. :-)

Velelmezem, hogy itt azert rafert egy atiras, de a logika valtozas miatt. Ha meg akarod tartani a regi funkcionalitast es nem kell jelentos atformazas, egyetertenek, de szerintem itt erosen meg kellett ujitani az egeszet, ujragondolni. Aztan, ha jopar logikat atvettek (ujrairtak) py -> java formatumban, az lehetett a legegyszerubb resze a dolognak.

Érdemes az ilyen általánosításokat átgondolni mielőtt ráhúzzuk egy konkrét szituációra.

A Netscape browser ugye egy "termék", egy "end-user-software" volt.
A Tesco routingja meg egy pontosan egy helyen használt egyedi szoftver. Teljesen mások az ilyen szoftver követelményei és folyamatai. Szinte semmi közös nincs bennük.

Ezt a fenti remek bölcsességet követte jó néhány bank is a mainframe-es motyójával, aztán most a cobol/mainframe programozók tulajdonképpeni kihalásával lassan egyszerűbb lesz új bankot alapítani mint az egészet új, fenntartható informatikai alapokra helyezni. A szoftver "hibátlan", csak senki nem mer hozzányúlni, mindenki inkább ötször körbetáncolja. Ettől aztán totál megáll az élet.

zászló, zászló, szív

( hajbazer v | 2022. 09. 04., v – 18:46 )

Szerkesztve: 2022. 09. 04., v – 18:47

Java alapokon hasít - eddig olvastam. :D

Már csak az a kérdés, hogy ezzel a Tescot vagy a Java bloatot akarják reklámozni.