A Laravel csapat kiadta a v12.50.0 verziót, amely több mint 40 pull requestet tartalmaz 20 közreműködőtől. Ebben a cikkben a három legfontosabb, fejlesztői élményt javító újdonságot mutatjuk be.

A collection-ökön eddig is létezett a containsOneItem() és a containsManyItems() metódus, de valljuk be, ezek elég hosszúak és nehezen megjegyezhetők voltak. A v12.50.0-ban két új, tömörebb alternatíva érkezett:

A hasMany() boolean értéket ad vissza, és callback-et is elfogad, ha pontosítani szeretnéd, mire keresel:

A régi containsOneItem() és containsManyItems() metódusok Laravel 13-ban deprecated-té válnak, úgyhogy érdemes már most átszokni az újakra.

Közreműködő: @JosephSilber — #58550

A Config facade-on már régóta elérhetők a típusos getterek (getString(), getInteger() stb.), amelyek biztosítják, hogy a visszakapott érték a várt típusú legyen. Most ez a Cache facade-ra is megérkezett:

Ez egy extra biztonsági réteg, ami segít korán elkapni a típushibákat, különösen nagyobb alkalmazásokban, ahol a cache-ben tárolt adatok típusáról könnyű megfeledkezni.
Közreműködő: @ahinkle — #58451

Ez a funkció különösen hasznos lapozásnál. Képzeld el, hogy van egy terméklistád, ahol a felhasználó kiválaszthatja, hány elemet lát oldalanként: 10, 25 vagy 50. Eddig semmi nem akadályozta meg, hogy valaki kézzel átírja az URL-ben a per_page paramétert mondjuk 5000-re — ami komoly terhelést okozhat a szerveren.
Az új clamp() metódussal ez egyszerűen megoldható:

Ha a felhasználó 5000-et ad meg, az automatikusan 50-re csökken. Ha 1-et, akkor 10-re nő. Nem kell többé kézzel validálni és korlátozni a lapozási értékeket.
Közreműködő: @cosmastech — #58608

A fenti három kiemelt újdonságon túl a release számos egyéb javítást és fejlesztést is tartalmaz:

A teljes changelog elérhető a GitHub release oldalon.
Köszönet a 20 közreműködőnek, akik ezt a kiadást lehetővé tették! 🚀

Ha a digitális fejlesztésre úgy tekintesz, mint egy megrendelésre a boltban – „kérek egy weboldalt, köszi” – akkor valószínűleg nem azt fogod kapni, amire igazán szükséged van.

Egy fejlesztő megír egy funkciót. Egy technológiai partner megérti, hogy miért van rá szükséged – és azt is megmondja, ha nincs.
Ez a különbség nem árnyalatnyi. Ez dönti el, hogy a fejlesztésed befektetés lesz, vagy pénzkidobás.

A „megrendelem, megkapom” csapda

A legtöbb KKV így gondolkodik a digitális fejlesztésről: van egy elképzelés, keresnek rá egy programozót vagy egy céget, megrendelik, kifizetik, és reménykednek, hogy jó lesz.

Ez a modell két helyen szokott eltörni.

Az első probléma, hogy a megrendelő ritkán tudja pontosan, mire van szüksége. Nem azért, mert nem ért a saját üzletéhez – pont ellenkezőleg. De az üzleti problémát lefordítani műszaki feladatra nem egyszerű. „Gyorsabb legyen az ügyfélkiszolgálás” – ez üzleti igény. De mit jelent ez a gyakorlatban? Automatizált státuszértesítések? Ügyfélportál? CRM-integráció? Vagy mind a három, de más sorrendben?

A második probléma, hogy egy „csak programozó” nem fogja feltenni ezeket a kérdéseket. Ő azt csinálja, amit kérnek tőle. Ha azt mondod, „legyen egy űrlap”, lesz egy űrlap. Hogy az az űrlap beépül-e a folyamataidba, csökkenti-e az adminisztrációt, vagy csak egy újabb dolog, amit valakinek manuálisan kell kezelnie – az már nem az ő asztala.

Mi az, amit egy technológiai partner másképp csinál?

A válasz nem az, hogy „jobban kódol”. Lehet, hogy igen, de nem ez a lényeg. A különbség a gondolkodásmódban van.

Megérti az üzleti kontextust. Mielőtt egy sor kódot is írna, megérti, hogyan működik a céged. Hol vannak szűk keresztmetszetek, manuális folyamatok, ismétlődő hibák. Nem a technológiából indul ki, hanem az üzleti problémából.

Kérdez, nem csak végrehajt. Egy jó technológiai partner néha azt mondja: „Ezt kéritek, de valójában erre van szükségetek.” Vagy: „Ezt most ne csináljuk meg, mert három hónap múlva úgyis átírjuk.” Ez nem pimaszság – ez az, ami hosszú távon pénzt és időt spórol.

Rendszerben gondolkodik. Nem egy weboldalt épít, hanem egy digitális rendszert, ami a céged működését támogatja. Ahol az egyes elemek – weboldal, ügyfélportál, belső admin felület, számlázás, CRM – nem szigetek, hanem összefüggő egész.

Hosszú távon is ott van. Nem az átadás pillanatában ér véget a kapcsolat. Egy technológiai partner üzemeltet, karbantart, fejleszt tovább. Ismeri a rendszert, ismeri a cégedet, és tudja, merre érdemes lépni.

A „programozó” és a „partner” közötti különbség a gyakorlatban

Képzeld el, hogy van egy 40 fős szolgáltató céged. Az ügyfeleidet Excelben tartod nyilván, az ajánlatokat Wordben írod, az e-maileket kézzel küldöd ki, a számlázás külön rendszerben megy.

A programozó megcsinálja, amit kérsz: egy szép weboldalt, egy ajánlatkérő űrlapot, talán egy admin felületet. Átadja, kész.

Három hónap múlva rájössz, hogy az űrlapból érkező adatokat továbbra is kézzel viszed át az Excelbe. Az admin felület nem beszél a számlázóval. Az ügyfelek nem látják a saját státuszukat. Új fejlesztőt keresel, aki újrakezdi.

A technológiai partner leül veled, végigmegy a folyamataidon, és azt mondja: „Ne weboldallal kezdjük, hanem az ügyfélkezelési folyamattal. Építünk egy rendszert, ahol az ajánlatkéréstől a számlázásig minden egy helyen van. A weboldal ennek a rendszernek a frontend-je lesz – nem fordítva.”

Nem ugyanaz az ár. De nem is ugyanaz az eredmény.

Hogyan ismered fel a valódi technológiai partnert?

Nem a portfólió méretéből és nem az óradíjból. Hanem abból, ahogyan az első beszélgetés zajlik.

Ha az első megbeszélésen a fejlesztő rögtön megoldásokról beszél, az gyanús. Ha viszont a te cégedről kérdez – hogyan dolgoztok, mi fáj, hol veszítetek időt – az jó jel. Az igazi partner először diagnosztizál, aztán javasol.

Figyelj arra is, hogy a fejlesztő mond-e nemet. Ha mindenre azt mondja, „persze, megcsináljuk”, az nem rugalmasság – az kockázat. Egy partner meg meri mondani, hogy „ez így nem lesz jó” vagy „erre nincs szükségetek”.

Végül: kérdezz rá a fejlesztés utáni időszakra. Ha a válasz annyi, hogy „átadjuk, és ha kell valami, keressetek” – az programozó. Ha a válasz az, hogy „havi szinten átnézzük, hogyan működik, és ha kell, fejlesztünk rajta” – az partner.

Összefoglalás: mire érdemes figyelni?

Egy technológiai partner nem luxus. Egy 10-200 fős, növekvő cégnek ez alapvető szükséglet. Mert ezen a szinten a digitális rendszerek már nem „kiegészítők” – ezek a cég működésének gerince.

Ha most ott tartasz, hogy érzed: kinőttétek az Excelt, a sablont, a szétszórt rendszereket – ne fejlesztőt keress, hanem partnert. Olyat, aki megérti az üzletedet, és segít rendszerben gondolkodni.

Az iWorkshop csapata pontosan így dolgozik: nem kódsorokban gondolkodunk, hanem üzleti értékben. Ha érdekel, hogyan tudnánk a ti cégeteket támogatni, beszélgessünk.