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

2013. Dec. 9., H, 08:37:31 CET

Sziasztok,

OFF:
Évek óta az "EMS SQL Management Studio for PostgreSQL"-t használom. A
fizetős változat eddig mindent tudott, amire nekem szükségem volt (napi 6-8
órában használom), de sajnos nem olcsó (518$/Év-725$/3Év).

Üdv:
Csaba

2013. december 8. 23:01 Tamás Demeter írta, <demeterft at dreamgate-design.com>
:

>  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>:
>
>> É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
>>
>>
>
>
> _______________________________________________
> Javalist mailing listJavalist at lists.javaforum.huhttp://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/20131209/737aaa5a/attachment.html>