Magyar fejlesztésű, webes, Perl-alapú keretrendszer letölthető

Programozás

2 év fejlesztés eredményeképpen a mai naptól letölthető a BOB virtuális gépként, valamint deb csomagként.

A BOB egy Perl alapon megírt folyamatosan fejlődő keretrendszer, ami megkönnyíti a webes alkalmazások fejlesztését, komplex alkalmazások gyors párhuzamos kivitelezését, flexibilis továbbfejlesztését és hosszú távon is hatékony karbantartását.

Ugyanitt megtalálható a fejlesztéshez általunk használt Komodo Edit mind 32 bites, mind 64 bites változata deb csomagként, valamint a fejlesztéshez általunk használni javasolt snipet készlet.

( szipka | 2012. 04. 06., p – 08:57 )

Azt hittem a perl, mint webes programnyelv a már évek óta kihalt. De hát úgy látom még vannak akik fantáziát látnak benne. A probléma szerintem az, hogy nem nagyon találni fejlesztőt hozzá, mert inkább a rendszergazdák scriptnyelve a perl.

Általánossában:

Én próbáltam nagyobb projekteket Perl-ben megvalósítani, és igazán tempósan lehet vele haladni, és hála a töménytelen mennyiségű modulnak, kevés kóddal is megy a dolog.
Viszont - tudom, az én hibám is - nagyon könnyű vele egyszeri write-only kódot előállítani.

Aztán miután évekkel később ilyen okokból újra kellett írnom néhányat Python-ban, rájöttem, hogy hol vannak a Perl határai. Rendszergazdaként viszont nagyon bevált.

( _Franko_ v | 2012. 04. 06., p – 11:45 )

Mindig gyanakvással fogadom azokat a folyamatosan fejlődő keretrendszereket, amelyek képesek komplex webalkalmazások flexibilis továbbfejlesztését hosszú távon biztosítani, ugyanakkor ezt a bemutatkozó szöveget egy másik CMS rendszer viszi a hátán...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Azon fut? Nem azon fut.

"Szóval mi a baj?"

Ha egy régebbin fut, akkor flexibilis? Gyorsan kivitelezhető az alkalmazás? Kicsit túl sok szuperlativusz került a bemutató mondatba, amely nem feltétlen fedi a valóságot, mindössze ennyi a baj.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Azon fut, az előző verzión. Még nem volt időnk az újra áttenni, ennek nem a flexibilitás hiánya az az oka, hanem az, hogy a Penna-ba (http://pennacms.rivendel.hu/hu/index.html) a jelenlegihez képest sok plusz funkciót tervezünk.

Szóval mi a baj?

Megjegyzés:
Nem rugalmatlanabb mint a JAVA vagy a Fortran, vagy a PHP vagy a C vagy Phyton, Mindenki másképp egyforma :(

Semmi baj sincs, ez itt az igazi magyar igazi szagértőket tartalmazó már nem csak unix portálja; nem a portál hibája, az amúgy jó lenne. Csak hát akik látogatják: tipikus magyar mentalitással bíró, jelentős tudással rendelkező, igazán kreatív emberek nagyon építő hozzászólásokat tesznek az olyanoknak, akik megpróbálnak felmutatni valami előrevivőt, érdemit, értékelhetőt. ;-)

Konkrétan nem rád gondoltam :) (ezért neki szólt a válasz), hanem a hupper közönségben általában fellelhető negatív hozzáállásra. :(
Hogy nulla közeli-e a tudása, azt mindenki maga ítéli meg, ahogy azt is, hogy az csak felszedett ismeret, vagy igazi, kipróbált tudás. És a tudás még mindig semmi, mert ha azt sikerül elhagyni, jöhet a bölcsesség. "a bölcs a szívet kiüríti, a gyomrot teletölti, a sóvárgást gyengíti, a csontot erősíti, hogy az emberek ne tudjanak, ne vágyjanak, az okosak veszteg maradjanak. A nem-sürgés ez és rend és békesség lesz."

Szerintem itt alapvetoen az a gond, hogy egy borzasztoan ismeretlen keretrendszer, nulla referenciaval objektiven ilyen kijelenteseket nem tehet, mert nincs mogotte eleg tapasztalat a kozosseg reszerol.

En is fejlesztek egy szoftvert, es ez a legjobb, legflexibilisebb, legfoobarabb a piacon. Most fogom kiadni az elso verziot. Remelem erted a dolog ironiajat.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ertem, csak azt nem, mi koze a kettonek egymashoz. Attol nem lesz egy keretrendszer rosszabb/jobb, hogy az ugyanazon ceg altal fejlesztett webalkalmazast meg nem volt eroforras frissiteni. Ott is emberek dolgoznak, barmily hihetetlen.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Egy kicsit nekem is gyanús ez a dolog kicsit olyan "csodarendszer" érzésem van, bár ne legyen igazam. Aki eltöltött jó pár évet az informatika világában annak idővel kialakul a "csodarendszer" detektora. A csodarendszer alatt azt értünk, hogy a marketing prezentáció és demo alkalmával minden szép, de miután a cég utólag már nem kideríthető(kinek a kije és miért) de abszolút nem szakmai olyan okokból megvette. Kiderül hogy lassú a felét se tudja mint amit igértek. Ami el tudja oszlatni ilyenkor kételyeimet, az az egyszerűen letölthető telepíthető, de elég komplex példaalkalmazás, esetleg online demo. Látom a kódot kitudom próbálni stb.

"Ami el tudja oszlatni ilyenkor kételyeimet, az az egyszerűen letölthető telepíthető, de elég komplex példaalkalmazás, esetleg online demo".

Az, hogy a keretrendszer egy helloworld-del letoltheto, abbol nem derul ki az egvilagon semmi, csak az, hogy egy helloworld megirhato benne.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem akarok partalan vitába belefolyni, hiszen belenéztem annak a forrásába ami elérhető és valószínűleg soha nem fogom használni ezt a dolgot. Több okból, aminek egy része személyes pl. nem nagyon értek a perlhez, utoljára 10 éve használtam scriptekhez, de az rég volt. Másrészt szakmai, nem igazán tudom eldönteni, hogy mire jó ez a dolog. Frameworknek túl bonyolult, sok a kötöttség, ami egy cég esetében aki erre alapozva termékeket állít elő elfogadható, hiszen magának csinálja a keretrendszert, ha valami nem megfelelő átírja. De általános fejlesztési keretrendszernek sokkal rugalmasabbnak kell lennie.
A másik gondom, meg a támogatás, ha egy nyilvános forumon ahol régóta a szakmában lévő nagy tudású sokat látott emberek kritikáit, észrevételeit támadásnak veszitek, mire számíthat egy egyszerű fejlesztő a problémájával.

Szerintem a helyes válasz az előző hozászolásomhoz az lett volna:
Jelenleg erőforrás hiányában csak egy vbox image-et tettünk ki, de dolgozunk a fejlesztői leíráson, és lesz egy step by step howto is x idő múlva.

Nos nem csak a vbox imaget, hanem deb csomagokat is tettünk ki, sőt már a beléoési jelszavakat is :) - van a kitett anyagban demo is. És folyamatosan rakjuk ki az egyéb információkat.

Erőforrásaink valóban szűkösek, de igyekszünk mindenkinek segítséget adni, aki kéri.

A jóságáról: Mi úgy gondoljuk, hogy jó, de akár tévedhetünk is, mint bárki más aki informatikával foglalkozik. -persze reméljük, hogy nincs így.

Hogy mire jó? Böngészőn keresztül elérhető alkalmazásokat lehet benne, vele fejleszteni.

Hogy jobb-e mint más? Nem tudom. Azt tudom, hogy van egy elképzelésünk, hogy hogyan lehet / kell fejleszteni és ennek támogatására hoztuk létre ezt.

Én nem válaszoltam az előző hozzászólásodra támadással. Azt hiszem most válaszolok neked, remélem ez nem támadó. - nem szántam annak.

Észrevételeimet azért írtam, mert kicsit hiányosnak éreztem a fellelhető technikai dokumentációkat. Céges architectként sokszor kellett nagyon rövid időn belül döntenem egy adott megoldás, technológia bevezetése mellett, vagy ellen. Ekkor legfontosabb a részletes technikai dokumentáció, a weboldalon ott van, hogy mire jó, csak azt hiányolom, hogy hogyan. Érdemes lenne összehasonlítani más keretrendszerekkel, pl. hogyan valósítja meg az MVC szeparációt, stb.

En nem csak a technikai dokumentaciot, hanem ugy minden tekintetben hianyolom a dokumentaciot. Nem latok tutorialokat, nem latok Getting Started doksikat, nem latok blogokat sem a mukodeserol sem a fejlesztesenek torteneterol, egyaltalan, az egesz egy kis ceges termek weboldalara emlekeztet "Itt van, ezt tudja, toltsetek, hasznaljatok". Igy nem lehet kozosseget epiteni egy termek kore.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ami kotelezo elem:
- Step-by-step leiras, hogyan kell letolteni, uzembe helyezni, az elso beallitasokat megtenni (Getting started)
- Kezdok szamara a leggyakrabban alkalmazott dolgok elintezesenek leirasa lepesrol-lepesre, elmagyarazva, hogy mit miert csinal az ember
- Jo minosegu dokumentacio, programozasi stuff eseteben kodokkal, a piler eseteben screenshotokkal gazdagon megszorva
- A pilernel szobajon a screencastok lehetosege is
- Irni, irni, minel tobbet irni a projektrol, mit csinal, hogy halad, milyen uj funkciokat kap eppen, miken dolgozik a csapat, miket terveznek bevezetni, otletelni, javaslatokat meghallgatni, aktivan kommunikalni a kozosseggel. Talan ez mindennel fontosabb.
- Ha van lehetoseg a funkcionalitas bovitesere, akkor nagyon reszeltesen dokumentalt API, pelda modulok.
- Egyszeru, letisztult, atlathato, megis jol kinezo oldal. Webes felulettel rendelkezo projekt eseteben alapkovetelmeny, hogy az oldal es a webes felulet vagy ugyanolyan, vagy hasonlo stilusu feluletet hasznaljon.

Tessek nezegetni a sikeresebb kozossegi projektek blogjait, pl. GitHub, Rails, Django. Tessek elolvasni oket, elemezni a hozzaallasukat. Nem csak az a fontos, amit mondanak, hanem ahogy kommunikalnak.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Lehet, hogy felreertheto voltam, es ugy tunt, mnintha barmi kozom lenne a projekthez, de nincs. Szoval tolem aztan szenne is kritizalhatod a dolgot.

Arra akartam ramutatni, hogy ki tudod probalni - ha akarod. Amig ezt meg nem teszed, addig korai rasutni, hogy rugalmatlan, stb - foleg, hogy a sajat bevallasod szerint "nem nagyon ertesz hozza". Az igaz, hogy egy 'hello world' implementaciot ki lehetett volna tenni a weboldalra, meg ugy altalaban a fejlesztoi dokumentaciot is, de az is lehet, hogy a VM es a deb csomag tele van manualokkal, pelda kodokkal, stb. Mert meg ha ez is a helyzet, attol meg mindez valoban kint lehetne a weben, de ugy lenne szep az ekezes, ha azt mond(hat)tad volna, hogy "letoltottem a vm-et, letoltottem a deb-et, de sehol sincs doksi, sehol egy pelda kod, sehol egy whatever, ez igy wtf...".

Hajra, elnok ur! A Heti Valasz cenzuraja

Ez nem egy könyvtár. Ha megnézed az oldalt, akkor azt látod, hogy létező FLOSS technológiák vannak egybe rakva. Ez egy koncepció, arról, hogy hogyan lehet nem világmegváltó, nem világ méretű, de működő alkalmazásokat készíteni. Itt most a PERL a nyelv, de lehetne Phyton, vagy éppen PHP-is. Nem ez a lényeg, bár mi PERL-t használunk.
A lényeg az a modell, hogy
- tervezd programozd az adatbázist (pl. PostgreSql)
- tervezd programozd az köztes réteget (pl. Perl)
- tervezd a felületet (html,css, template toolkit)
- programozd a felületet (javascript, jquery)
s mindeközben tegyél be ellenőrzéseket és védd az adataidat.
kapsz hozzá jogosultsági rendszert
személy és felhasználó kezelést (adatbázissal együtt)
javaslatot, hogy használd mind ezt
stb.

Szóval, ha egy API-t vagy API-kat vársz csalódni fogsz, mert ez nem egy könyvtár vagy rutin gyűjtemény

Ebből a négy rétegből hármat generálni szoktak mostanság, ahogy a validációt és a jogosultságkezelést is... a jogosultságkezelő rendszer pedig ootb része az összes keretrendszernek. :)

Én értem, hogy ez egy hatalmas dolog(nak tűnik), rettentő jó érzés egy keretrendszer megírni -- én is írtam már JSR-168 kompatibilis portál rendszert, de a leírásodban nincs semmi olyan, ami lázba hozna egy fejlesztőt... ez egy n+1. keretrendszer kezdemény, amelyből semmi nem lesz, mert kevés fejlesztő nem tudja rendesen karbantartani, nagy méretben pedig kényelmetlen, mert sok a hiányossága és túl sok élőmunkát igényel a fejlesztés.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Fejet hajtok a tudásod előtt.
Az is belátom, hogy te vagy az "egy fejlesztő". :)

Viszont azért írtam, hogy azok közül akik nem te vagy, hátha valakit érdekel ez a dolog, no meg válasz volt egy kérdésre.

Tudod az emberek részben olyanok, hogy annak ellenére, hogy a Mount Everest
(http://hu.wikipedia.org/wiki/Csomolungma) a világ legmagasabb csúcsa, egyes nem te-k a Kékesre (http://hu.wikipedia.org/wiki/K%C3%A9kes) felmennek.
Létezhet olyan is aki előbb volt a Csomolungma-n és aztán ment fel / le a Kékesre.

Az szándékos, hogy mindegyik programozható, hozzáférhető átírható.

Tudjuk, hogy nem vagyunk megváltók. Egy picike szín vagyunk a palettán, szép vagy csúnya, komor vagy vidám, de szín.

"én is írtam már JSR-168 kompatibilis portál rendszert" - ehhez gratulálok.

Ohm, szerintem te felreerted az API dokumentacio fogalmat.

Vessuk meg az alapokat annak, amit most mondani fogok. Ti irtatok egy keretrendszert. Ebben a keretrendszerben webalkalmazasokat lehet osszerakni, kulonfeleket, kicsiket, nagyokat, jokat, rosszakat. Ezeket - valoszinusitem - nem lehet tisztan kattintos modszerrel osszerakni, szinte biztos, hogy valamennyit fejleszteni kell hozza. Akar csak azt, hogy a bal felso sarokban valtogassa a logo helyen megjeleno kepet egy adott forrasbol, akar azt, hogy a twitter feedemet integralja bele az oldalon latott tartalomba, valami egyedi szinte biztos lesz egy webalkalmazasban, amire ti meg csak nem is gondoltatok almotokban sem.

Hogy egy ilyen webes keretrendszer bovitheto, fejlesztheto legyen, es ezaltal nepszerusegre tegyen szert, elsodleges feltetele, hogy legyen jol dokumentalt. Mivel a fejleszteshez ismerni kell a kodbazis lehetosegeit (milyen package-k vannak, milyen osztalyokkal, ezen belul milyen metodusok hivhatok (milyen parameterezessel), milyen hookok vannak, hol lehet a generalt tartalmat testreszabni rendereles elott, hol utana), szoval ezeket mind-mind dokumentalni kell ahhoz, hogy egyaltalan szamitani lehessen arra, hogy valakit is erdekelni fog egy webalkalmazas keretrendszer. A Drupal - noha o magat egy kattintas altal testreszabhato keretrendszernek aposztrofalja - igen reszletekbe meno es boseges API dokumentaciot bocsat felhasznaloi rendelkezesere, hogy ha esetleg megsem bizonyulnanak elegsegesnek az oaltala nyujtott szolgaltatasok, es valami miatt tobbre, masra vagyna az egyszeru felhasznalo, ezt minel konyebben elerhesse ugy, hogy ir egy plug-int. A plug-in egy olyan modul, mely kiboviti a meglevo rendszer tudasat ugy, hogy az alkalmas legyen egy adott feladat elvegzesere is.

Szoval, en valami olyasmire gondoltam API dokumentacio tekinteteben, amin egy egyszeri fejleszto, aki valamilyen modon fel szeretne hasznalni ezt a webes keretrendszert, el tud indulni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Csatlakoznék az előttem szólóhoz.
Letöltöttem, megnéztem a deb csomagokat a https://mail.mithrandir.hu/bob-debian-pkg/ címről és beléjük néztem egy kicsit (csak a Perl fájlokba). Szándékoltan, vagy nem, ezt nem tudom, de hiányzik belőlük a dokumentáció. Sima komment és POD dokumentáció sincs. Ha lenne benne POD, abból könnyen lehetne HTML dokumentációt generáltatni, mely leírná az elkészített osztályok és metódusok mibenlétét, paramétereit, stb.
Ezt a dokumentációt kitéve a weboldalra, az érdeklődő fejlesztők, vagy architektek részletesebb képet kapnának a szoftver működéséről, így kicsit konkrétabb kép alakulhatna ki bennük arról, hogy mi is ez és hogyan lehetne esetleg bővíteni. Így a POD-HTML dokumentáció segíthetne a döntéshozatalnál, hogy bevezetésre kerüljön-e a BOB az adott projektnél, vagy sem.

Természetesen készül a dokumentáció.
A modul fejlesztéshez ismét dokumentált eszközöket lehet, és ajánlunk használni.
Természetesen a keretrendszerhez kapcsolódó specialitások dokumentációja is rövidesen kikerül.
Addig is a "demo" részt ajánlanám tanulmányozásra.

Valóban sok a tennivalónk, hogy komoly a tiáltalatok megfogalmazott igényeknek ellegeltető projekté váljunk.
Nos mi az első lépéseket tesszük, gondolom egyszer majd eljutunk a sokadikig is.

A forrás tanulmányozás előtt/ mellett / után / közben javaslom a weboldalon található dolgokat is elolvasni.

Megjegyzés:

Már vannak cégek akik a BOB-ot (már az előzőt) elkezdték használni, és hallottunk 100 felhasználó feletti intranetes kórházi felhasználásról (Persze a BOB keretrendszerbe írt alkalmazást használják, nem magát a BOB-ot)

Remélem heteken belül közzétehetünk olyan fejlesztőknek szóló szolgáltatást mely a BOB segítségével készült.

Csak egy eszrevetel. Az az igazsag, hogy en nem vagyok gyakorlott programozo, igy lehet hogy az en meglatasaim nem helyesek ebben a temakorben. Azonban nekem az a tapasztalatom, hogy regen rossz, ha utolag allok neki dokumentalni, akkor semmi kedvem nincs mar az egeszhez, es olyan is lesz: kenyszer szulte, szuk, es rovid. Jobb, ha mar fejlesztes kozben definialok idot arra, hogy par dolgot ledokumentaljak a kodban, egyreszt hogy ne keruljon elfelejtesre, masreszt pedig amugy is kell egy kis valtozatossag a kodolas utan. Utana megint kodolok, megint egy kicsit dokumentalok (vagy eppen tesztelek), es igy iteralok. Igy minden feladat egyenlo tempoban halad, a projekthez a dokumentalas szakaszban mar vagy csak a formazas marad, vagy csak a kibovites, pontositas, esetleg a szukseges annotaciok beirkalasa marad (ezekkel se szeretek foglalkozni).

Nyilvan nem akarok beleszolni abba, hogy hogyan fejlesztetek, de igy nektek is konnyebb, nem kell halalba hajszolni magatokat azert, hogy legyen dokumentacio, "csak mert a kozosseg azt akarja". Nektek is jobb, ha van egy atlathato dokumentaciotok, amihez a fejlesztok nyulni tudnak. Minel bonyolultabb egy rendszer, annal nehezebb minden egyes reszet fejben tartani.
Egy fuggveny fole irt masfel sor egyaltalan nem vesz el idot a fejlesztestol, viszont kivalo API dokumentacio lesz belole.

Tenyleg nem akarok ratok eroltetni semmit, de erdemes lenne errol elgondolkodnotok. Szurkolok, hogy egy sikeres keretrendszer szulessen meg a kezetek alatt.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem mondtam olyat, hogy nincs dokumentációnk. Viszont rendeznünk kell, hogy mások számára is kezelhető átlátható legyen.
Célunk külön választani a BOB fejlesztést és a BOB-bal való fejlesztést. A BOB-bal való fejlesztéshez készülünk dokumentációt kiadni. Aztán majd a BOB fejlesztéshez is áll szándékunkban.
Csak tudod a magyar betegségben szenvedünk, van amit szeretnénk csinálni (BOB) és van amit kell csinálnunk (megélhetés), s így bár muszájban is sokszor használunk BOB-ot, lassabban haladunk, mint szeretnénk.

( bekeny | 2012. 04. 06., p – 13:25 )

OFF:

Ha ismertek olyan Perl tudással rendelkező webes fejlesztőt, aki távmunkában vállalna kisebb-nagyobb Perl fejlesztéseket, légyszi dobjatok nekem egy PM-t!

Köszi!

Amennyire tudtam elolvastam, nem erősségem az angol. Azt értem, hogy a BOBX PHP-ben készült és így annak aki PHP-ben akart dolgokat csinálni némi türközéssel lehetett. Azt is értem, hogy az sokkal könnyebb volt mint a nem vagy nem jól, vagy nem elérhető dokumentációval rendelkező BOBX-et használni.

Viszont: Mi nem takarjuk el, hogy ez Perl alapú, nyilvánosak elérhetőek a komponensek, elérhetőek a források, és nem köztelező, csak lehet használni.

Szóval értem, hogy a BOB - BOBX összecseng, de mi a további párhuzam? - nyilván angol tudásom hiányossága miatt vagyok ilyen értetlen, vagy mint ahogy valamely kedves tag írja ~a perl-től van agykárosodásom~ (Tudom nem volt gyerekszobája, de legalább is tehén volt benne a radiátor), de ennek ellenére érdekel, hogy milyen okkal írtad be a linket.

Egyébként a RATFOR-ról hallottál?

Mintha rémlene valami. Az valami olyan message queue, aminek a protokollverziói nem csak képtelenek az együttműködésre, de logikájában is eltérőek? Aminél a szerverhez kell vadászni a klienst, mert még az is előfordul, hogy az egyikkel megy, a másikkal nem (az azonos protokollverzió ellenére is)?
A rabbitmq az, amit abban a "takarékos" kilenc kilences nyelvben írtak, ami ráadásul lineárisan skálázódik a CPU-k számával, de a valóságban néha esik-kel, ha skálázódik is valamennyire, koránt sem úgy, mint ahogy azt ígérik, és gyorsan kiderül, hogy az erlang (VM) hihetetlenül pazarló az erőforrásokkal (CPU és RAM is).

Jópár erlangos programot próbáltam, és használtam is már, de az erlang erejét még nem sikerült egyikben sem meglátnom, pedig az elképzelések között van pár jó, és érdekes is.

Visszakérdezhetek? Te is csak hallottál róla ugye? :)
--
zsebHUP-ot használok!

Hát Fortran ügyben azért az, hogy halott erős kijelentés. Tudod most, hogy párhuzamosítás meg felhő meg hasonló technológiák törtek előre, egészen sok minden készül újra Fortranban. Azt hiszem (talán tudom is, de csak hinnem szabad) még az Audi gyárnak is van valami."nagy Fortranos" dolga, mert az "élő" nyelvek nem váltak be.
A Perl-t halottnak nevezni - hát te tudod.

Mindenesetre érdemes olvasni a szabad szoftverek életciklusáról:

Itt: http://www.odfalliance.hu/doc/h%C3%ADrek/2009/meh-floss.pdf

13. fejezet. Oldalszámozás szerint 247. oldal.

Remélem hasznos lesz

Szóval nem érdekel, nem értesz hozzá, véleményed viszont van.

Nos hátha ezt ismered vagy legalább elolvasod (bár tény, hogy a költő halott)

Ady Endre: A Hortobágy poétája

Kúnfajta, nagyszemű legény volt,
Kínzottja sok-sok méla vágynak,
Csordát őrzött és nekivágott
A híres magyar Hortobágynak.

Alkonyatok és délibábok
Megfogták százszor is a lelkét,
De ha virág nőtt a szivében,
A csorda-népek lelegelték.

Ezerszer gondolt csodaszépet,
Gondolt halálra, borra, nőre,
Minden más táján a világnak
Szent dalnok lett volna belőle.

De ha a piszkos, gatyás, bamba
Társakra s a csordára nézett,
Eltemette rögtön a nótát:
Káromkodott vagy fütyörészett

A sok-sok összekattintgatom/összehuzigálom java-s akármilyenes fosch cuccoknál nem szörnyűbb. Az, hogy nulla a rálátásod, az még nem jelenti azt, hogy tökéletes véleményt tudsz róla alkotni.
És ha már Fortran, akkor megemlítem, úgy mellékesen, hogy Cobol-ban megírt banki és pénzügyi rendszerek még léteznek jócskán, és biza a java kódgányolók hozzá sem tudnak szagolni, ergo nem is nagyon lesznek átírva, hanem szépen megfizetik a Cobol-hoz értő szakembert, aki a szükséges módosításokat megcsinálja.

"És ha már Fortran, akkor megemlítem, úgy mellékesen, hogy Cobol-ban megírt banki és pénzügyi rendszerek még léteznek jócskán, és biza a java kódgányolók hozzá sem tudnak szagolni, ergo nem is nagyon lesznek átírva, hanem szépen megfizetik a Cobol-hoz értő szakembert, aki a szükséges módosításokat megcsinálja."

Ööö... izé... mellékesen megemlíteném, hogy tudok bankról, ahol IBM CICS-ről migrálnak saját Java alapú számlavezető rendszerre, illetve olyanról is, ahol éppen Oracle FlexCube-ot vezetnek be... nagyjából az a helyzet, hogy valóban vannak jócskán Cobol-ban és Fortran-ban megírt banki és pénzügyi rendszerek, amelyeket szépen egyesével migrálnak vagy kivezetnek.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Fortran2008

A Fortran2008 nevével ellentétben 2010-ben jelent meg. Az új képességek a párhuzamos programozást támogatják.

Almodulok, a modulok további strukturálása
CO-tömbök, párhuzamos végrehajtási modell[4]
DO CONCURRENT, függetlenül végrehajtható iterációk
CONTIGUOUS attributum, tárolási szabályok specifikálása
BLOCK szerkezet, lokális hatókörű objektumok deklarálását tartalmazhatják
Rekurzív allokálható komponensek, a felhasználói típusok rekurzív pointereinek alternatíváj"

forrás: wikipédia

Persze erre mondja majd NagyZ, hogy a halottnak is nő a haja meg a körme (egy ideig). :)

Ez mire is cáfolat? Arra, hogy banki és pénzügyi berkekben éppen tervezgetik vagy már kivitelezik, hogy kivezetik a legacy rendszereket? Vagy arra, hogy Java alapú rendszerre cserélik?

Azt egyébként meg tudnád mondani, hogy a Fortran2008 szintaxist ismerő fordító milyen rendszereken fut és milyen létező nagyvállalati rendszereket alapoztak erre a variánsra? :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Audinak van pl. és felhőben fut, ha jól emlékszem a konferencia előadásra. Megjegyzem Fortranban tipikusan nem szimpla ügyviteli rendszereket, hanem számítás igényes feladatokat (amiket szeretnének párhuzamos feldolgozással gyorsítani), (csőhálózatok elemzése, statisztika, optimalizálás stb. ) írnak. Párhuzamos feldolgozás esetén az OO modell lassabb (lehet, hogy csak még, de most lassabb), mint az eljárás orientált.

Tényleg SAP ABAP-ot használ még, vagy már az is JAVA?

Neked? Minek. Te csak azt és akkor olvasol amikor neked jó.
Írd már le magadnak, hogy hogyan is épül fel egy n. örökléssel kialakuló objektum a memóriában. Majd azt, hogy ezt hogyan lehet elosztott rendszeren kezelni. Szóval ne olvass, hanem csak gondolkodj. Hidd el, menni fog.

"Írd már le magadnak, hogy hogyan is épül fel egy n. örökléssel kialakuló objektum a memóriában. Majd azt, hogy ezt hogyan lehet elosztott rendszeren kezelni."

Itt a felvetést se értem tisztán, hogy mi is a probléma tulajdonképpen. Kifejtenéd bővebben?
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Miert, egy nick alatt tobben is vagytok? Vagy nem ertem.

NagyZ foglalkozott elosztott rendszerekkel, fejlesztett IoC kontrollert, es egyaltalan, eleg mely tudasa van neki pont az emlitett teruleten. Rolad viszont csak annyit tudunk, hogy a BOB fejlesztocsapatanak a szovivoje vagy.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Értem. Köszönöm.
Már RSX alatt CM4-eken foglalkoztam kint
osztotr adatbázidokkal és "feladat megosztással".

Az OO programozás jó dolog. A JAVA is. A PL1 is.
De nem univerzális megoldások.

Hozzáteszem, sajnos. Azt is sajnálom, ha valaki előbb,
nem hajlandó olvasni, aztán nem hajlandó
elgondolkodni.
Persze biztosan okosabb, tapasztaltabb.
Így én már nem leszek, általa. Ez van.

"Audinak van pl. és felhőben fut, ha jól emlékszem a konferencia előadásra. Megjegyzem Fortranban tipikusan nem szimpla ügyviteli rendszereket, hanem számítás igényes feladatokat (amiket szeretnének párhuzamos feldolgozással gyorsítani), (csőhálózatok elemzése, statisztika, optimalizálás stb. ) írnak. Párhuzamos feldolgozás esetén az OO modell lassabb (lehet, hogy csak még, de most lassabb), mint az eljárás orientált."

Ez a három mondat erősen kiakasztotta a bullshit detektoromat... :)

Elhiszem, hogy az Audinak van futó Fortran programja, lévén tizenpár évvel ezelőtt szimulációkra nem nagyon volt más megoldás. Abban eléggé szkeptikus vagyok, hogy Fortran szoftverek futnak felhőben, mert az x86 tipikusan nem a Fortran területe, az IBM nagygépek pedig nem felhő orientáltak.

Ha elolvasod ezt a szálat, akkor láthatod, hogy a pénzügyi- és ügyviteli rendszereket elsősorban COBOL (vagy RPG) nyelven írták, de ezeket igyekeznek kivezetni, mivel elterjedtek, ám erősen elavultak... ugyanez igaz a matematikai- és szimulációs számításokra használt Fortran-ra is, a jelenleg futó rendszerek szinte mindenhol legacy jelzővel működnek, és migrálják a tartalmat és funkcionalitást újabb platformokra.

A párhuzamos feldolgozás vs. OOP modell viszonyáról írhatnál bővebben, hogy ez honnan jött, mert a platform _nyelvi_ modellje és a platform _párhuzamos_ működése között nincs nagy összefüggés.

"Tényleg SAP ABAP-ot használ még, vagy már az is JAVA?"

Attól függ hol. A legacy SAP az ABAP, a XI/PI és a NetWeaver az tudtommal erősen Java.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Annál gyorsabban. Unisys lybra helyett sima PC alapú szervereké a jövő (egy része minimum). Nem kevés cobol / algol kódgyártó szakember van szerte a világban, viszont a környezet, a verziókezelés nagyban függ a nagyon-nagyon régen készült mainframe-es keretrendszertől. És e-fölött már eljárt az idő. Erőforráspazarló megoldás. Nem versenyezhet a modern eszközökkel.
--
unix -- több, mint kód. filozófia.
Life is feudal

Láttál már te méretesebb, Fortranban írt cuccot? Nagyon úgy tűnik, hogy nem. Performancia nem nő, üzemeltethetőség (v.ö.: ami működik, ne piszkáld) az nem javul (sőt...), a karbantarthatóság meg kódere válogatja, hogy mit képes jobban / könnyebben átlátni.

Még egy. A meglévő méretes kódbázis már többszörösen tesztelt, éles üzemben lévő megoldás. Azonos minőségű kód csinálni nem biztos, hogy első nekifutásra tuti nem fog menni, ez is jócskán megemeli a költségeket.

NagyZ: 


a perl egy nagyon szornyu nyelv. aki manapsag fortranban fejlesztet, az meg peklapat.
foss hivo sem vagyok, igy nem olvasok random foss doktrinakat se :("

saxus: 


Es gondolom a Java magatol portolja a millios kodbazisu fortran rendszereket."

NagyZ: 


magatol? miert, a Java el, vagy mit szivsz?

de ebben az esetben olcsobb a portolas + jovobeni fenntartasi koltseg mint 
a jelenlegi fenntartasi koltseg; inkabb ez alapjan tessek elkezdeni gondolkodni.

(a performancia, karbantarthatosag, uzemeltethetoseg, etc mar csak hozzaadott plusz)

Cavinton. Vagy threadben olvasni a fórumot.

A hét végén láttam egy szép méretes eladó fűnyírót, valami 2m fölötti szélesen tudta nyírni a füvet egy menetben. Ha gondolod, összehozlak a tulajjal, borotvának talán tudnád használni.

Ööö... izé... azért írják át vagy migrálják ezeket a régi rendszereket újabbra, mert
* a régi kódbázis átlalában a spagetti és a patchwork módszertan keverékével készült, minimális dokumentációval
* az igények olyan szintre növekedtek, amelyet az adott platform már nem képes követni
* a legacy rendszer drágán nyújt gyenge teljesítményt
* senki nem mer hozzányúlni, mert még működik, így minden új igényt egy legacy rendszer köré épített másik rendszer old meg, aztán már ahhoz se mernek hozzányúlni, ezért még egy réteget létrehoznak, és így tovább... aztán akkora spagettis tál lesz belőle, hogy sokkal olcsóbb újraírni az új igények alapján.

"Azonos minőségű kód csinálni nem biztos, hogy első nekifutásra tuti nem fog menni, ez is jócskán megemeli a költségeket."

Azonos minőségű kódot valóban nem lehetne első nekifutásra, mert a jelenlegi eszközökkel olyan rosszat nehezen lehet csinálni, ahhoz erősen meg kell szegni egy csomó kódolási szabályt, amelyekre figyelmeztet az összes IDE, a kódminőség mérő eszközök pedig pláne... :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

A régi kód való igaz, nem a mostani módszertanokkal készült - jórészt azért, mert sok-sok dolog nem alkalmazható rájuk, mint ahogy a régi elvek sem alkalmazhatóak a jelenlegi fejlesztőeszközökre.
Az igények változása valós, az, hogy nem képes követni, azt elsődlegesen a hozzáértő fejlesztői erőforrások szűkössége okozza. A drágán gyenge teljesítmény alátámasztására illene valamit citálni, nekem ellentétes tapasztalataim is vannak (Cobol kontra Java).

A kód minőségére azt értem, hogy olyan mértékben tesztelt appot hogyan tudsz csinálni? Régi cuccnak gyakorlatilag csak ismert hibája van - az új cucc "ismert, működést hátrányosan befolyásoló hibája nincs" elven kerül élesbe... :-D

"A régi kód való igaz, nem a mostani módszertanokkal készült - jórészt azért, mert sok-sok dolog nem alkalmazható rájuk, mint ahogy a régi elvek sem alkalmazhatóak a jelenlegi fejlesztőeszközökre."

Régi fejlesztéseknél nem nagyon voltak módszertanok...

"Az igények változása valós, az, hogy nem képes követni, azt elsődlegesen a hozzáértő fejlesztői erőforrások szűkössége okozza. A drágán gyenge teljesítmény alátámasztására illene valamit citálni, nekem ellentétes tapasztalataim is vannak (Cobol kontra Java)."

Nem a szűkös fejlesztői erőforrásokkal van baj, hanem azzal, hogy több fejlesztő kell ugyanannyi munkához, másrészt több idő is kell a dokumentálatlanság okán.

A drágán gyenge teljesítménynél érdemes azt nézni, hogy mennyibe kerül a vas egy legacy rendszer alá (System/390, AS/400, Z széria), és mennyi ugyanezt kihozni x86 alapú gépekből, aztán azt, hogy mennyivel drágább a fejlesztés, aztán azt, hogy mennyivel drágább az üzemeltetés. Nem csoda, hogy mindenfelé azt látom, hogy ezekről a rendszerekről migrálnak vagy tervezik a migrációt.

"A kód minőségére azt értem, hogy olyan mértékben tesztelt appot hogyan tudsz csinálni? Régi cuccnak gyakorlatilag csak ismert hibája van - az új cucc "ismert, működést hátrányosan befolyásoló hibája nincs" elven kerül élesbe... :-D"

Azért érzed, hogy ez így hülyeség... nem?
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Ez így butaság."

Kérlek, mondanál fejlesztési módszertanokat a nyolcavanas évekből? :)

"~ Óriások vállán állok, azért látok messzebbre. (Newton)"

Idézgetni én is tudnék órákon át, de ezzel nem jutunk előre.

Csak nekem furcsa, hogy kérdésre még nem reagáltál egyenes válasszal?
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Módszertan mindig is volt, csak legfeljebb nem volt elterjedve, ill. szabványosítva.
Nem idézgetni szeretne, csak annyit, hogy gondolkozzatok kicsit.
Folyamatosan támadjátok, mióta megjelent ez a hír: csoda, hogy védekezik? És az egyik legjobb védekezés, ha az ember visszakérdez. A másik, ha nem válaszol; de az itt nem válik be, mert akkor elsüllyedne ez a hír. Így viszont egy-két ügyes visszakérdezés árán ingyen reklámozzátok a rendszerét. lol

Valóban szeretném, ha gondolkodnának, elgondolkodnának.
Az is jó lenne, ha észérvekkel folyna a vita.

Egyszer nagyon fáradtan autóztunk az ország másik végéből haza, Hogy el ne aludjunk elkezdtünk sorozatokról beszélgetni. Mivel nem nézek évszámra tévét (elég a számítógép képernyő), a mind kettőnk által látottakból hamar kifogytunk.
Úgy alakult, hogy egyszer csak azt vettük észre, hogy olyan sorozatokról beszélünk, melyet egyikőnk sem látott. - mikor ezt észrevettük, betudtuk ezt a fáradságnak.

Ez a hangulat köszön vissza itt az egyesekkel való "beszélgetésben is", no meg az, hogy eltérnek a tárgytól, és nem tesznek konkrét és alátámasztott kijelentéseket, de a másoktól elvárják.

Van még mit fejlődnie a BOB-nak is meg sok "hupper" vitakultúrájának is, beleértve jómagam is. Cérnával (türelemmel) néha már bírom.

Részvétem a flame-ért. Amit én nem tudok megérteni, hogy egyesek egója miért nem bírja elviselni a tizes listán 6-os vagy 4-es vagy 8-as (tökmindegy, <= 9.9) minőségű dolgokat? Szerintem nem ez a lényeg. Nincs tökéletes. Ha már munka mindenkinek - ráadásul fárasztó szellemi munka - jobb lenne fun kategóriának tekinteni, az helyett, hogy leírjuk, ez miért nem 10-es??

A hírhez annyit szeretnék hozzáfűzni, hogy ilyen híreknél személy szerint szívesen vennék egy kis nagyon tömörre összeszedett pár soros (ha lehetséges egyáltalán) ízelítőt, ami ide is be lenne írva. Olyanra gondolok, mint pl. hogyan lehet összerakni egy egyszerű kódot, ami listát printel az oldalra, vagy egyéb. Mivel te vagy a fejlesztő, pont Te tudhatnád, hogy mi lehetne "cukorkának" való, pár soros kód, kicsit kiszínezve. Úgy vagyok vele, ha már bele kellene bújnom egy doksiba egy másik oldalon, akkor nem biztos hogy megteszem (függ milyen fáradt vagyok, vagy egyáltalán az inger faktoromat eléri-e).

Tehát szerintem általánosságban érdemes lehetne áthidalni a nagyon kevés infó kontra full doksi közötti részt. Legalábbis nekem így lenne vonzó, hogy egyáltalán megnézzek valamit. Mert mire pont az érdekességekig eljuthatnék, addig nagyon fárasztó lebontani a sok "felesleges" infót, ami ahhoz kell, hogy 5 perc alatt egy gyors rátekintést kapjak. Általában ezt hiányolom sok hírből.

Amúgy meg ha más nem is fogja használni a cuccotokat, saját fejlesztéseitekhez nem lehetne valószínűleg jobb eszköz, amelyet ennyire ismertek - illetve bármikor adott igény szerinti irányba tudjátok gyurmázni. Sok sikert hozzá!

Ezt már megnéztem, de ehhez képest gondolnám hogy lenne szerintem létjogosultsága egy olyan összeállításnak, amin csak végig scrollozok a weboldalon, és nem kell virt gépet csinálnom meg oda bejelentkeznem, mert ezt már nem biztos hogy megteszem, részetekről meg ugye csak egyszer kell összerakni, míg a nézelődőknek egyesével spórol rengeteg energiát. Főleg ha olyan érdeklődne, aki egyébként is összetettebb munkát végez, szerintem az már nagyon szelektál hogy mire fordítson időt.

Ettől függetlenül lehet sokan nem így látják.

Szerk.: ha a virt gép a működést mutatja be, mármint a kész kódból a működő webodalt, akkor én nem erre értettem, hanem példa kódokra gondoltam, amit feljebb is írtam.

+1

Én kb 5 percet szántam a weboldalra, de az az igazság, hogy nekem az se világos, hogy miről is van szó. Ez most egy keretrendszer webes alkalmazások fejlesztéséhez vagy egy "TurnKeyLinux", azaz előrekonfigurált oprendszer adott szolgáltatásokkal és fölötte egy webes interfész ami magában is megállja a helyét, de opcionálisan modulokkal bővíthető..?

Tudom, hogy ki kell próbálni és minden világos lesz, de ezzel kapcsolatban valamelyk magyar mobilapp-gyár fogalmazott meg még régen egy olyan aranyszabályt, hogy: ha nem tudod 3 mondatban meggyőzően megfogalmazni, hogy mire jó az terméked, akkor nem lehet sikeres, ne is csináld. Nekem, mint nézelődőnek, ez a 3 mondat hiányzik a weboldalról.

"Megis a legnagyobb terhelest elbiro issue tracking rendszernek a bugzillat tartjak. Nem veletlenul."

Olyan szolgáltatásokkal, amit a bugzilla tud, nem nehéz nagy terhelést elbírni... :)

"3 masik javasal van tapasztalatom, mind fizetos, legolcsobbat tartom valamire."

Érdekes, hogy már alig van olyan open source termékkel rendelkező cég, ahol ne Jira lenne (issues.apache.org/jira, jira.jboss.org, stb). Persze az echte Linux cégek még tartják magukat a Bugzillával, mert arrafelé valahogy rossz a Java pedigréje... :)

Egyébként értelmetlen összevetni a Bugzilla és a Jira tudását, mert a Bugzilla egy faék egyszerűségű issue kezelő rendszer, a Jira meg egy komplett projekt tervező és ütemező rendszer, amelyhez van tengernyi plugin.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"A jira felepiteset ill. dokumentaltsagat kovetendo peldanak tartod? Java fejlesztesek kozott szerinted egy relative jo pelda a jira ? Mondanad masoknak, hogy a java felyleszteseinket ilyen forman csinaljuk ?"

A fejlesztési modellt igen, a kódminőséget (még) nem.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Tehat jo fejlesztesi modellel ill. "jo" eszkozokkel, 10 ev alatt nem sikerult osszehozni a megfelelo kodminoseget.

Lehet, hogy a dolog nem is azon mulik, hogy perl vagy java vagy fortran vagy c++ ?
Ezek szerint meg a jo fejlesztesi modell sem eleg ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( john_silver v | 2012. 04. 06., p – 20:26 )

Jó lenne egy felhasználó név/jelszó páros a virtuális géphez.