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

2013. Dec. 8., V, 23:01:45 CET

Sziasztok,

OFF:
Postgres kapcsán eddig ami legjobb gui-t találtam az a TOra (QT4 
multiplatformos, http://tora.sourceforge.net) Linux alatt a 2.1.3-at 
használom, azt gondoltam, hogy megállt a fejlesztése, de most 
ellenőrizve az oldalt hír + release ugyan nem volt az elmúlt két évben, 
de az svn trunk aktív.
Ha néztétek akkor nem szóltam, ha nem, akkor javaslom. (Ha emlékezetem 
nem csal, akkor lehet, hogy fordítanom kellett ahhoz, hogy MySql-t, 
PostgreSQL-t támogassa mert alapból csak az Oracle ment.)  Nem hibátlan, 
de foshalomnak koránt sem mondanám.

Üdv:
Tamás

On 2013-12-08 22:10, József Keresztes wrote:
> 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 
> <mailto: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 <mailto: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 <mailto:Javalist at lists.javaforum.hu>
>     http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
>
>
> _______________________________________________
> 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/e4356fcc/attachment.html>