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

2013. Dec. 8., V, 22:40:22 CET

1, Vicces, hogy egyrészt a saját könyvtárak és kódok írása mellett
kardoskodsz, aztán meg felháborodsz, hogy mások is így tesznek és azok
hibásak.
 Ha esetleg Te is valami jól bevált lib-et használnál, jdbc-hez, xml
generáláshoz, stb, akkor a világon kevesebb hibás szoftver lenne.
2, Én is láttam már pár érdekes megoldást, idehaza, meg külföldről is,de a
kód minősége meg leginkább az adott fejlesztőtől függ, nem a nemzetiségtől.
S idehaza is bőven vannak cégek, ahol nem mennének át az általad felvázolt
megoldások.

Üdv
 Zs

2013/12/8 József Keresztes <xesj.hu at gmail.com>

> Egy dolgot feltétlenül el akartam még mondani.
> Vitatkozunk azon hogy XML feldolgozáshoz saját cucc, vagy JAXB, esetleg
> más stb.
> Ha jól és megbízhatóan működik a saját cucc akkor nincs baj.
>
> Saját gyakorlati tapasztalatom: a baj ott van hogy ha cégektől XML-ben
> kérsz adatokat 5 cégből 3-4 cég fejlesztői rosszul állítják össze az xml-t
> mert
> nem tudják hogy
>
>   <kedvenc>kutya & macska</kedvenc>
>
> esetén az & helyett &amp; kell mert xml-ben entitás jelölésére van a &.
> Erre nekem kellett felhívni a fejlesztő kollégák figyelmét 5-ből 3 vagy 4
> cég esetén !!! Valszeg simán stringekkel raknak össze xml-t, escape-elés
> nélkül.
> És mi meg ilyen saját/nem saját cuccokon vitatkozunk ? Na ne !!! Ez
> Magyarország.
> Kíváncsi vagyok pl. Németországban is ilyen arányban pocsék a szoftverek
> minősége ?
>
> Joe
>
>
>
> 2013. december 8. 22:10 József Keresztes írta, <xesj.hu at gmail.com>:
>
> 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 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/ff5c4969/attachment.html>