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

2013. Dec. 8., V, 22:27:55 CET

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
>>
>>
>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20131208/99ac76ef/attachment.html>