[Javalist] RegExp probléma: nem aposztrófok közé zártak felismerése

2013. Dec. 8., V, 22:10:25 CET

Sziasztok !

> Én éppen pénteken vágtam ki egy ilyen helper class-t a kukába. Igaz, hogy
fél napig írtam, és pont olyan volt, ahogy én szeretem, de aztán bevillant,
> hogy ennek a funkcionalitásnak meg kell lennie apache common- ban vagy
guavaban. És fél óra alatt meg is találtam.
> Nem pont olyan. Egy kicsit nehézkesebb a használata, de talán mert
általánosabb, meg aki írta nem úgy gondolkodott ahogy én (naná).
> És a másik oldalról: nem tudott mindent amit a saját. Ezért a sajátot
kidobtam es elkezdtem használni ami az apacheban van.

Nagyon sajnálom hogy kidobtad. Kár érte. Én biztos nem dobtam volna ki
ilyen jellemzők alapján ahogy írtad.
A Te kódod egyértelműen jobb lehetett, ezek alapján.
Dehát embere válogatja.
Persze nálam is van olyan hogy nem tetszik a régi kódom, de ilyen esetben
egy másik sajátra cserélem, ami többet és jobban tud mint elődje.
Az lehetséges hogy erőforrásigényes saját cuccokat gyártani, de ha ez nem
megy a munkánk rovására (mert pl. itthon csináljuk amikor kedvünk van) akkor
sosem számít a ráfordított erőforrás.

Az pedig alapvető emberi reakció hogy egy ismeretlen ember "barkácsolt"
dolgát sosem tartjuk jónak (általában SZAR-ral jellemezzük) ellentétben egy
komolynak
vélt cuccot mert azt 100-an fejlesztik, 10.000-en használják stb. Pedig
valljuk be hány olyan dolog van a neten amire ezek igazak és amikor
kipróbáljuk valóban
úgy érezzük egy nagy trágya/foshalom stb. Én biztos nem vagyok attól
meghatva hogy 100+10000. Mondok egy példát: Postgres adatbázishoz keresünk
a kollégákkal
valami tool/gui felületet hogy ne a pgadmin-t használjuk (mert az sem
igazán jó). Az az igazság hogy a neten ami van mind egy foshalom.
Nevetséges de így van, nincs normális eszköz.
És ilyenkor felmerül bennünk hogy kéne írni egy sajátot ami jobb
mindezeknél (persze ilyet nem fogunk írni, már látom előre), használjuk azt
ami van :((

Joe

2013. december 8. 10:25 Peter Verhas írta, <peter.verhas at gmail.com>:

> Én éppen pénteken vágtam ki egy ilyen helper class-t a kukába. Igaz, hogy
> fél napig írtam, és pont olyan volt, ahogy én szeretem, de aztán bevillant,
> hogy ennek a funkcionalitásnak meg kell lennie apache common- ban vagy
> guavaban. És fél óra alatt meg is találtam.
>
> Nem pont olyan. Egy kicsit nehézkesebb a használata, de talán mert
> általánosabb, meg aki írta nem úgy gondolkodott ahogy én (naná).
>
> És a másik oldalról: nem tudott mindent amit a saját. Ezért a sajátot
> kidobtam es elkezdtem használni ami az apacheban van. Es közben rájöttem,
> hogy ami nincs meg az apache-ban az nem is kellett nekem. (Ezt ők honnan
> tudták?)
>
> Az a jó programozó, aki a funkcionalitást kevesebb kóddal tudja
> megvalósítani.
> --
> Dipl. Ing. Peter Verhas
>
>
> On Sun, Dec 8, 2013 at 8:33 AM, Auth Gábor <auth.gabor at javaforum.hu>wrote:
>
>> Hi,
>>
>>
>>
>> Suller Andras a következőt írta ekkor: 2013. december 8. 07:52:06
>>
>> > Nem ertem ezeket a reakciokat. Rajtam es Joe-n kivul senkinek
>>
>> > sincsenek statikus helper osztalyai?
>>
>>
>>
>> Amire van kész és dobozos megoldás, mondjuk elterjedt és népszerű csomag,
>> ami mondjuk nyílt forrású is: azt célszerű használni. Csak és kizárólag
>> arra a problémára legyen saját fejlesztésű Utility csomag (szigorúan külön
>> csomag), ami nincs közismerten elterjedve, tehát mondjuk rákeresünk a
>> feladatra és az első tíz találatban csak panaszt látunk arra, hogy nincs rá
>> jó megoldás.
>>
>>
>>
>> Akkor lehet még szó saját megoldásokról, ha nagyon idő vagy teljesítmény
>> kritikus a fejlesztés és az általános megoldások túl lassúak vagy több
>> erőforrást igényelnek, mint a specializált megoldások, de általános esetben
>> az ilyen saját fejlesztések mindig drágábbak, mint a megspórolt idő vagy
>> erőforrás.
>>
>>
>>
>> A fejlesztés jel/zaj (üzletileg hasznos kód / üzletileg haszontalan kód)
>> viszonyában minden helper, utility, hack, workaround és a többi kiszolgáló
>> osztály a zajt növeli. Lehet okosan is csinálni az OOP paradigma
>> használatával, illetve JavaEE használatával, de lehet úgy is, hogy a
>> hasznos kódbázis töredéke a kiszolgáló kódbázisnak, mert a fejlesztő
>> alapvetően nem szeret üzleti problémákat megoldani, helyette keretrendszeri
>> fejlesztéseket csinál, mert az sokkal érdekesebb... csak nem azért fizetik.
>>
>>
>>
>> > En copy-paste-eltem a projektjeim kozott ezeket a helper osztalyokat.
>>
>> > Ami most mar tudom, hogy balgasag volt, de akkor megfelelo megoldasnak
>>
>> > tunt.
>>
>>
>>
>> Kicsit később már azt is balgaságnak fogod tartani, hogy írtál ilyen
>> helper osztályokat... az ember előbb-utóbb belátja ezt. Mindenki úgy kezdi,
>> hogy túl nagynak, összetettnek, nehézkesnek tartja az összes utility
>> csomagot, ezért megírja a sajátját, aztán napról-napra kiderül, hogy mit
>> nem tud a saját csomagja, jó esetben hozzá lesz ragasztva egy új metódus,
>> rossz esetben ilyenkor kiderül, hogy az egész koncepció hibás és nulláról
>> újra kell írni az új körülményeknek megfelelően. A szokásos stációk:
>>
>> - valamelyik komponens újabb verziójával nem működik, mert van benne
>> deprecated függőség, mert az egyszerűbb volt
>>
>> - másik futtató környezetben nem működik, mert más a JVM, más a web
>> konténer, más az operációs rendszer
>>
>> - másik fejlesztésben nem működik, mert tulajdonképpen nem általános
>> utility, hanem specializált, ettől meg az első fejlesztésben nem működik jól
>>
>> - másik fejlesztővel nem működik, mert nem érthető a működése, illetve
>> késhegyre menő viták vannak folyamatosan, mert nem várt hibák vannak benne,
>> amit csak az ismer, aki fejlesztette
>>
>> - nem működik együtt szabványos vagy elterjedt utility osztályokkal, mert
>> azok "nem jól működnek"
>>
>> - nem működik elosztott környezetben, mert nem volt szempont a
>> kifejlesztésénél
>>
>> - lelépett vagy kirúgták a fejlesztőt és itt hagyta a sok "szart", amihez
>> csak ő értett, ezért kidobják az egyedi fejlesztést
>>
>>
>>
>> Bye,
>>
>> Auth Gábor
>>
>> http://www.javaforum.hu/web/10/authgabor
>>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20131208/cce1bbae/attachment.html>