mboost-dp1
Ruby - hvad er det?
Jeg har i gennem de sidste par år hørt meget (tom?) buzz om dette programmeringssprog, men har aldrig rigtigt gidet prøve det - måske pga. det lidt fimsede navn - eller også bare fordi jeg ikke rigtig har haft brug for det.
Men anyway, er der nogen der kan forklare mig hvad det er der er så fedt ved Ruby? Jeg vil sætte stor pris på en teknisk redegørelse fremfor de sædvanlige "sprog X er fedt fordi det er bedre end sprog Y" og "sprog X er det vildeste mand, totalt ligesom poesi - har du noget hash?" kommentarer.
(Hvis jeg lyder afstandstagene er det fordi jeg før har stillet Ruby-programmører dette spørgsmål og kun fået lalleglad tomsnak som ovenstående igen)
Men anyway, er der nogen der kan forklare mig hvad det er der er så fedt ved Ruby? Jeg vil sætte stor pris på en teknisk redegørelse fremfor de sædvanlige "sprog X er fedt fordi det er bedre end sprog Y" og "sprog X er det vildeste mand, totalt ligesom poesi - har du noget hash?" kommentarer.
(Hvis jeg lyder afstandstagene er det fordi jeg før har stillet Ruby-programmører dette spørgsmål og kun fået lalleglad tomsnak som ovenstående igen)
#1
Ruby er et dynamic typed, object oriented med garbage collection sprog ligesom Python og Groovy.
Den slags sprog er ret moderne for tiden. Man antager at det koster mindre at udvikle samme funktionalitet i den slags sprog end i mere traditionelle static typed sprog og at de er sikre nok til den gennemsnitlige business app.
Populariteten af Ruby er i høj grad drevet af populariteten af Ruby on Rails (RoR), som er et web application framework, der har opnået en vis popularitet. Nøglord er scaffolding og Convention over Configuration.
Ruby er et dynamic typed, object oriented med garbage collection sprog ligesom Python og Groovy.
Den slags sprog er ret moderne for tiden. Man antager at det koster mindre at udvikle samme funktionalitet i den slags sprog end i mere traditionelle static typed sprog og at de er sikre nok til den gennemsnitlige business app.
Populariteten af Ruby er i høj grad drevet af populariteten af Ruby on Rails (RoR), som er et web application framework, der har opnået en vis popularitet. Nøglord er scaffolding og Convention over Configuration.
#2
(fortsat)
Du skylder dig selv at lære mindst et sprog af den kategori.
Men om du vælger Ruby, Python eller Groovy (eller noget fjerde) er efter min mening ikke så vigtigt.
Selvfølgelig er der forskel på dem. Og nogen vil uden tvivl klart foretrække det ene fremfor det andet. Men fra 10000 meter er det same shit.
(fortsat)
Du skylder dig selv at lære mindst et sprog af den kategori.
Men om du vælger Ruby, Python eller Groovy (eller noget fjerde) er efter min mening ikke så vigtigt.
Selvfølgelig er der forskel på dem. Og nogen vil uden tvivl klart foretrække det ene fremfor det andet. Men fra 10000 meter er det same shit.
Okay, så langt så godt. I praksis, hvad betyder det så mere nøjagtigt at man kan i Ruby/RoR (og evt. lignende sprog) som man ikke kan i f.eks. PHP?
Umiddelbart oplever jeg idéen i 'Convention over Configuration' som lidt ubehagelig. Når jeg har skrevet et program vil jeg da ikke have at computeren begynder at gøre alt muligt jeg ikke har bedt den om ... ? Jeg ved godt det ikke er helt sådan det er, men alligevel - det virker med et ord lidt 'creepy' (som i uhyggeligt, men også som i 'feature creep').
Umiddelbart oplever jeg idéen i 'Convention over Configuration' som lidt ubehagelig. Når jeg har skrevet et program vil jeg da ikke have at computeren begynder at gøre alt muligt jeg ikke har bedt den om ... ? Jeg ved godt det ikke er helt sådan det er, men alligevel - det virker med et ord lidt 'creepy' (som i uhyggeligt, men også som i 'feature creep').
#4
PHP er slet ikke så langt fra Ruby og RoR, så det er nok ikke den mest illustrative sammenligning.
Du skal snarere sammenligne med frameworks som Struts og JSF (begge fra Java EE verdenen).
Du skal lave lange lange konfigurations filer for at få hello world til at virke.
Med CoC er det: lav noget nemt og hvis man så har brug for noget udover det normale så lave du en konfiguration af undtagelsen.
PHP er slet ikke så langt fra Ruby og RoR, så det er nok ikke den mest illustrative sammenligning.
Du skal snarere sammenligne med frameworks som Struts og JSF (begge fra Java EE verdenen).
Du skal lave lange lange konfigurations filer for at få hello world til at virke.
Med CoC er det: lav noget nemt og hvis man så har brug for noget udover det normale så lave du en konfiguration af undtagelsen.
Og det har sjovt nok aldrig slået igennem. Om jeg fatter at JSF&Struts stadig eksisterer, folk skriver jo nærmest "XML MARERIDT" hvis man nævner dem.arne_v (6) skrev:Du skal lave lange lange konfigurations filer for at få hello world til at virke.
Mht. Ruby så er det altid godt at kunne nogle "script" sprog til hurtig udvikling, men desværre er disse sprog ofte meget pragmatiske.
Nu er Ruby et af de bedre, men f.eks. Python er noget som hører hjemme på tavlen af et universitet, ikke i virkeligheden (medmindre folk VIRKELIG elsker at skrive __SELF__).
Starter lige med at sige at jeg ikke selv har rørt Ruby meget, og ikke er aktiv bruger :)
Jeg ville nok beskrive Ruby som mest i familie med Python, men... der er lagt mere vægt på objektorientering (alting er et objekt, operationer bliver generalt altid udført som metodekald) og man kan faktisk runtime-udvide også builtins med nye metoder. På den måde kan man i temmelig høj grad omdefinere sproget dynamisk. (Det er én ting bl.a. RoR udnytter, så vidt jeg ved.) Objekt-modellen ligger meget tæt op ad Smalltalk, der er absolut tale om "duck-typing" og det kan lade sig gøre at definere en meta-metode der bliver kaldt hvis en metode ikke findes.
Desuden er der også temmelig god support for det funktionelle paradigm (tænk Lisp, Haskell), primært i form af kodeblokke man giver som en slags argument til en funktion, normalt bliver den blok så brugt som kroppen i en iterator, eller på anden måde som aspekt. F.eks. vil blokken givet til en funktion der åbner en tekstfil blive kørt for hver linje i filen, og filen bliver så implicit lukket efter alle linjer er behandlet.
Syntaksen har ret korte nøgleord og bruger i højere grad symboler. (Flere symboler end i Python og Lua, formentlig lidt færre end i C++, vel omtrent ligesom C#.) Der er til nogen grad support for "flere mådeer at gøre tingene på" lidt a'la Perl, man kan f.eks. sætte en betingelse efter en instruktion (x=x+1 if y>10).
Selv har jeg aldrig rigtig kunnet falde til med sproget, jeg foretrækker Python :) (Og PHP til web, fordi der kan jeg smække noget lort sammen uden at skulle sætte et framework op først.)
Jeg ville nok beskrive Ruby som mest i familie med Python, men... der er lagt mere vægt på objektorientering (alting er et objekt, operationer bliver generalt altid udført som metodekald) og man kan faktisk runtime-udvide også builtins med nye metoder. På den måde kan man i temmelig høj grad omdefinere sproget dynamisk. (Det er én ting bl.a. RoR udnytter, så vidt jeg ved.) Objekt-modellen ligger meget tæt op ad Smalltalk, der er absolut tale om "duck-typing" og det kan lade sig gøre at definere en meta-metode der bliver kaldt hvis en metode ikke findes.
Desuden er der også temmelig god support for det funktionelle paradigm (tænk Lisp, Haskell), primært i form af kodeblokke man giver som en slags argument til en funktion, normalt bliver den blok så brugt som kroppen i en iterator, eller på anden måde som aspekt. F.eks. vil blokken givet til en funktion der åbner en tekstfil blive kørt for hver linje i filen, og filen bliver så implicit lukket efter alle linjer er behandlet.
Syntaksen har ret korte nøgleord og bruger i højere grad symboler. (Flere symboler end i Python og Lua, formentlig lidt færre end i C++, vel omtrent ligesom C#.) Der er til nogen grad support for "flere mådeer at gøre tingene på" lidt a'la Perl, man kan f.eks. sætte en betingelse efter en instruktion (x=x+1 if y>10).
Selv har jeg aldrig rigtig kunnet falde til med sproget, jeg foretrækker Python :) (Og PHP til web, fordi der kan jeg smække noget lort sammen uden at skulle sætte et framework op først.)
Windcape (7) skrev:Og det har sjovt nok aldrig slået igennem. Om jeg fatter at JSF&Struts stadig eksisterer, folk skriver jo nærmest "XML MARERIDT" hvis man nævner dem.
Prøv og lav et realitets check.
Både Struts og JSF er slået igennem.
De er hver for sig i samme vægt klasse som ASP.NET generelt og PHP generelt.
#10
Lightweight har været et hot udtryk i Java EE verdenen i en del år nu.
Men for web apps betyder det ikke fravær application server. Du kan ikke lave en Java web app uden en web container. Du laver heller ikke ASP.NET uden ASP.NET eller PHP uden PHP.
Man kan så vælge mellem en application server med kun web container (Tomcat, Resin etc.) eller en fuld Java EE application server (WebSphere, WebLogic, JBoss etc.). Det er ikke mit indtryk at fordelingen mellem de to har ændret sig.
Med lightweight menes der ofte ingen EJB, kun web front og noget Spring og Hibernate back. Men selvom man ikke bruger EJB kan det godt deployes på en application server som har en EJB container (og de fulde server har ofte også andre ekstra features udover EJB container, så det er ikke nødvendigvis spild).
SOA er sjældent specielt lightweight.
Hvis man er til lightweight, så er Struts eller JSF dog langtfra en selvfølge - der er andre frameworks som appelerer til den målgruppe. Wicket har bl.a. en del tilhængere.
Lightweight har været et hot udtryk i Java EE verdenen i en del år nu.
Men for web apps betyder det ikke fravær application server. Du kan ikke lave en Java web app uden en web container. Du laver heller ikke ASP.NET uden ASP.NET eller PHP uden PHP.
Man kan så vælge mellem en application server med kun web container (Tomcat, Resin etc.) eller en fuld Java EE application server (WebSphere, WebLogic, JBoss etc.). Det er ikke mit indtryk at fordelingen mellem de to har ændret sig.
Med lightweight menes der ofte ingen EJB, kun web front og noget Spring og Hibernate back. Men selvom man ikke bruger EJB kan det godt deployes på en application server som har en EJB container (og de fulde server har ofte også andre ekstra features udover EJB container, så det er ikke nødvendigvis spild).
SOA er sjældent specielt lightweight.
Hvis man er til lightweight, så er Struts eller JSF dog langtfra en selvfølge - der er andre frameworks som appelerer til den målgruppe. Wicket har bl.a. en del tilhængere.
#12
Det kunne jeg vel i princippet også - har bare følt det var lidt overflødigt, uden dog rigtig at have nogen viden om sproget. Men umiddelbart syntes jeg svarene her bekræfter min fordom.
Det kunne jeg vel i princippet også - har bare følt det var lidt overflødigt, uden dog rigtig at have nogen viden om sproget. Men umiddelbart syntes jeg svarene her bekræfter min fordom.
En af grundene til at jeg foretrækker Python frem for Ruby tror jeg netop er Pythons "batteries included" idé, at der kommer et fornuftigt stort standard-bibliotek med til at klare en masse slags opgaver. Selvfølgelig findes der moduler til alle de samme ting til Ruby, men der følger meget mindre med i en standard-installation.
Windcape (7) skrev:Og det har sjovt nok aldrig slået igennem. Om jeg fatter at JSF&Struts stadig eksisterer,
Den har arne_v svaret glimrende på.
Windcape (7) skrev:folk skriver jo nærmest "XML MARERIDT" hvis man nævner dem.
Her skal du så tænke på hvor du spørger. Folk som arbejder med store (enterprise) systemer er i meget kraftigt undertal fx. her.
Personligt vil jeg nok hellere vælte på cykel, end bruge én dag på at lave et lille Struts-projekt (fra bunden). (Jeg tror heller ikke jeg vil nå at få Hello World til at virke alligevel.)
Men i mit daglige arbejde generer XML'en mig ikke. Tvært imod. Jeg har fancy GUI-værk til at gøre det nemt (og som de fleste vist nok foretrækker), men det er pokkers meget nemmere at fise rundt direkte i sourcen.
Og størrelsen? Tjah, der står godt nok ikke meget i dem, som jeg kan undvære. Til gengæld er der nogle ting jeg gerne vil flytte fra Java-koden til en eller anden XML-fil.
Mareridt? Jeg siger ikke at Struts er det bedste. Jeg kender ikke de reelle alternativer (JSF, Spring osv). Men hvis samme system var lavet i PHP, ville jeg have sagt op for længe siden. Eller være blevet sindssyg. (Og jeg har levet af PHP i flere år.)
Hvis jeg drømmer om at skifte Struts ud, så er det ikke fordi jeg har nogen problemer med Struts, men blot for at finde noget endnu bedre.
(Og det system jeg arbejder i er enda lille, af et enterprise-system at være.)
#15
Men det er jo netop det som har gjort Ruby og Python så populære. At man ikke skal bruge evigheder på at sætte nye projekter op (rapid development and prototyping), samt at man ikke skal bekymre sig om at rebuilde et monster af et projekt bare fordi man vil ændre en lille smule.
Hvis du skal sammenligne med PHP, skal du jo sammenligne med PHP med Zend Framework.
Og så er vi jo ved at være derhenne hvor Struts overlevelse afhænger mere af at "vi bruger det allerede" end at folk ville ønske at lave ny-udvikling i det.
Alle de enorme konfigurationsfiler definere jo en eller anden form for statisk data, f.eks. url-routing.
Der skal jeg slet ikke forstå at man vil have det ekstra performance overheat ved at bruge xml. XML i forbindelse med java skal jo netop analyseres, typisk for hver pageload, medmindre der benyttes noget sindsyg cache som ville gøre opdateringer et endnu størrere mareridt.
Men det er jo netop det som har gjort Ruby og Python så populære. At man ikke skal bruge evigheder på at sætte nye projekter op (rapid development and prototyping), samt at man ikke skal bekymre sig om at rebuilde et monster af et projekt bare fordi man vil ændre en lille smule.
Hvis du skal sammenligne med PHP, skal du jo sammenligne med PHP med Zend Framework.
Og så er vi jo ved at være derhenne hvor Struts overlevelse afhænger mere af at "vi bruger det allerede" end at folk ville ønske at lave ny-udvikling i det.
Alle de enorme konfigurationsfiler definere jo en eller anden form for statisk data, f.eks. url-routing.
Der skal jeg slet ikke forstå at man vil have det ekstra performance overheat ved at bruge xml. XML i forbindelse med java skal jo netop analyseres, typisk for hver pageload, medmindre der benyttes noget sindsyg cache som ville gøre opdateringer et endnu størrere mareridt.
Windcape (16) skrev:Men det er jo netop det som har gjort Ruby og Python så populære.
...men til et HELT andet behov.
Windcape (16) skrev:samt at man ikke skal bekymre sig om at rebuilde et monster af et projekt bare fordi man vil ændre en lille smule.
Det gør vi heller ikke med Struts. Når jeg har en ændring trykker jeg CTRL-S (gem fil), ALT-TAB (skift til browser), F5 (reload) og så kan jeg typisk se ændringen.
Windcape (16) skrev:Og så er vi jo ved at være derhenne hvor Struts overlevelse afhænger mere af at "vi bruger det allerede" end at folk ville ønske at lave ny-udvikling i det.
Lige præcis Struts - måske. Jeg ved det ikke. Men konceptet? No way! Enterprise-produkter har stadig behov for enterprise-frameworks.
Windcape (16) skrev:Der skal jeg slet ikke forstå at man vil have det ekstra performance overheat ved at bruge xml. XML i forbindelse med java skal jo netop analyseres, typisk for hver pageload, medmindre der benyttes noget sindsyg cache som ville gøre opdateringer et endnu størrere mareridt.
Det går nu fint her.
Med et MVC framework, hvor er det så lige forskellen på enterprise og non-enterprise ligger?myplacedk (17) skrev:Men konceptet? No way! Enterprise-produkter har stadig behov for enterprise-frameworks.
Om jeg skal kode homebanking eller newz.dk, de grundlæggende funktioner som et webframework skal bruge er nu engang de samme.
Jeg ser intet i J2EE som jeg ikke kan i PHP/ASP.NET/Ruby/Python, kun at det er overkomplext at sætte en prototype op.
Om man så vil definere 1000 xml filer som "smarterer" er jo så et spørgsmål om holdninger, der er sjældent noget reelt grundlag for at vælge et løsning der kræver mere kode.
Det skulle da lige være udviklerglæde. Noget jeg absolut ikke finder i J2EE.
Windcape (18) skrev:Jeg ser intet i J2EE som jeg ikke kan i PHP/ASP.NET/Ruby/Python, kun at det er overkomplext at sætte en prototype op.
På den liste kender jeg kun PHP. Typesvagheden og den slags er fint til prototyper. Men min erfaring er, at jo større systemet er, jo mere problematisk er det at være så dynamisk.
Man kan komme langt ved at have en god disciplin. Men du finder altså ikke lige 200 PHP-udviklere, som har en discplin der er god nok, til at gå den rute.
PHP har udviklet sig en del siden sidst jeg arbejdede med det. Men jeg vil gætte på at refactoring stadig er et helvede, i forhold til fx. Java.
Windcape (18) skrev:Om jeg skal kode homebanking eller newz.dk, de grundlæggende funktioner som et webframework skal bruge er nu engang de samme.
På et stort system er der en langt større koordineringsopgave. Det kræver et system, som er beregnet til det. Jeg troede også PHP kunne alt engang.
Windcape (18) skrev:Jeg ser intet i J2EE som jeg ikke kan i PHP/ASP.NET/Ruby/Python, kun at det er overkomplext at sætte en prototype op.
Jeg kan tilføje at det er sindssygt svært, at koge kartofler med J2EE. Prototyper (og kartofler) bruger man andre værktøjer til.
Men når nu vi har et kørende system, så tager det mig ikke mange minutter at lave en prototype på et nyt skærmbillede. Skal jeg lave et skærmdesign kan jeg kode det lige så hurtigt som jeg kan tegne en skitse i Word eller whatever.
Kort sagt: Struts, J2EE osv. er glimrende til det, det er godt til. Hvor godt det er til alt muligt andet synes jeg ikke er relevant.
Windcape (18) skrev:Det skulle da lige være udviklerglæde. Noget jeg absolut ikke finder i J2EE.
Det gør jeg. Når først hele det grundlæggende system (versionsstyring, deployment-procedurer osv.) er nogenlunde på plads, er det en herlig legeplads.
PHP5 med Zend Framework er da netop beregnet til det (Ligesom JSP med Structs er, man skal sammenligne korrekt).myplacedk (19) skrev:På et stort system er der en langt større koordineringsopgave. Det kræver et system, som er beregnet til det. Jeg troede også PHP kunne alt engang.
Hvad er argumenterne udover typesikkerhed og refractoring for at benytte J2EE? Jeg har aldrig set nogen. Så jeg har svært ved at se hvorfor jeg skulle sige ja til at benytte noget som er stort og tungt, uden at have en grund til det.
Altså med henblik på nyudvikling!
Mht. refractoring, så har jo entligt mere at gøre med ens udviklingsværktøjer. Og hverken PHP, ASP.NET eller Java har formået at gøre det særlig vellykket når HTML og Business logik skal kombineres.
PHP+Zend
Ruby+Rails
Python + Django
C# + ASP.NET (WebForms eller MVC)
JSP + J2EE Framework
Og J2EE er *klart* den løsning som kræver mest konfiguration, og opsætning, og føles "tungest" at arbejde med.
Windcape (20) skrev:Hvad er argumenterne udover typesikkerhed og refractoring for at benytte J2EE?
Jeg kan nævne nogle stykker. Men selv hvis PHP/Zend bliver bedre end Java/whatever holder mit argument stadig: Struts o. lign. er stadig ganske udemærket, det til det, det er beregnet til.
Windcape (20) skrev:Så jeg har svært ved at se hvorfor jeg skulle sige ja til at benytte noget som er stort og tungt,
Et enterprise-system er stort og tungt uanset hvad du koder det i. (Det ligger jo ligesom i det, ik'?)
Det kan godt være at WebSphere er en kæmpe mo-fo. Det betyder ret lidt, for vores system er langt større.
Det er da fint at LAMP kan køre på en 486'er. Det er bare ikke relevant lige her.
Windcape (20) skrev:Mht. refractoring, så har jo entligt mere at gøre med ens udviklingsværktøjer.
Men IDE'erne vil jo nødvendigvis være baseret på det sprog du arbejder med. Se fx. PHP i stil med dette:
$prefix = (cond)?"my_":"";
$var = $prefix."something";
whatever($$var);
Det er ret svært at analysere på. Vil variablen $my_something nogensinde blive brugt? Eksisterer den overhovedet? Hvor nemt er det at omdøbe $my_something til $nothing, uden at håndtere den stump kode manuelt?
Den slags gøjl knækker refactoring. Det er praktisk talt umuligt. At gøre den slags i Java kræver brug af reflection. Ved at forbyde reflection er refactoring langt langt nemmere. Og ja, det er nemt at forbyde reflection.
Den slags gør at fx. Eclipse havde været et godt Java IDE i lang lang tid, da jeg opgav at finde et PHP IDE, som kunne et minimum af tricks, som fx. code-completion på egne funktioner.
Windcape (20) skrev:Og J2EE er *klart* den løsning som kræver mest konfiguration, og opsætning, og føles "tungest" at arbejde med.
Konfiguration og opsætning er noget man gør ca. én gang. Det fylder lige så lidt i et "rigtigt" J2EE-projekt, som i et "rigtigt" PHP-projekt.
Og ja, J2EE kan føles tungt. Men det handler mere om systemet, end teknikken. Det meste af det "tunge" her handler ikke en skid om J2EE, Struts eller WebSphere. Det handler om procedurer, politikker, tests, revision og hvad ved jeg. Og det ville have været præcist det samme med PHP, Ruby eller whatever.
Please do.myplacedk (21) skrev:Jeg kan nævne nogle stykker
Fordi de andre argumenter giver ikke nogle gode grunde til hvorfor man skulle vælge J2EE som platform til et ny hjemmeside.
Der skal være en specific grund. ASP.NET byggede meget på Master Pages, ViewState, og nem integration med MS SQL samt udviklingsværtøjer i Visual Studio.
Rails (og til dels også Python) byggerede på rapid prototyping og "convenience over configuration".
PHP gjorde ingen af delene, de udviklede sig og fik Enterprise delen senere.
J2EE som jeg ser det byggede på "ting som var smarte i 99", og "at Java udviklerer kunne lære det nemt" samt at der ikke rigtig var nogle seriøse alternativer på dets oprindelsestidspunkt.
Windcape (22) skrev:Please do.
Fordi de andre argumenter giver ikke nogle gode grunde til hvorfor man skulle vælge J2EE som platform til et ny hjemmeside.
Jeg synes de er meget vigtige, og resten er i samme stil.
Windcape (22) skrev:Der skal være en specific grund.
Ja. Kort sagt: Det bedste værktøj til opgaven. Mange faktorer spiller ind, og hvis én af dem er alt-afgørende, så vælger du jo system fordi du har fået armen vredet rundt.
Når jeg så har prøvet alle de frameworks jeg listede, og så ikke vælger J2EE, har jeg så valgt det beste værktøj til opgaven? :-)myplacedk (23) skrev:Ja. Kort sagt: Det bedste værktøj til opgaven.
Hvis jeg vil have type sikkerhed så er Ruby, og ASP.NET stadig gode alternativer, til hvad PHP og Python ikke kunne klare.
Faktisk IronRuby og ASP.NET samtidig, to fluer med et smæk, samt typesikker og bedre udviklingsværktøjer end Java kan give.
Og kom ikke og sig at man vælge J2EE pga. man ikke vil købe dyre Microsoft licenser :-)
Men jeg har altså stadigvæk ikke set noget J2EE kan som alle andre WebFrameworks ikke kan. Jeg har kun set ting det *ikke* kan, eller gør mere besværligt end andre.
Windcape (24) skrev:Når jeg så har prøvet alle de frameworks jeg listede, og så ikke vælger J2EE, har jeg så valgt det beste værktøj til opgaven? :-)
Det ved jeg da ikke. Men umiddelbart er det mit indtryk, at du ikke arbejder på projekter, hvor J2EE er det bedste valg.
Nej, det gør jeg ikke. Men hvad hvis jeg skulle på et tidspunkt?
Hvordan vil jeg vide hvornår jeg skal benytte J2EE når det er 24 timers hovedpine bare at sætte Hello World op?
J2EE er en del af mit studie dette semester, men desværre for min underviser har jeg arbejdet med webudvikling på andre platforme før.
Underviserens holdning er jo at J2EE er det eneste rigtige og de giver aldrig argumenter for hvorfor man bør benytte J2EE, og hvorfor man IKKE bør benytte J2EE (de sidste er vigtigt for at give en objektiv vudering.)
Desværre så er det næsten umuligt at finde folk som ikke tænker på PHP/ASP.NET som pest, som også har erfaring med J2EE. (Og vores Underviserere har aldrig erfaring med mere end een ting -.-)
Derfor spørgsmål. Knowlegde is power.
Hvordan vil jeg vide hvornår jeg skal benytte J2EE når det er 24 timers hovedpine bare at sætte Hello World op?
J2EE er en del af mit studie dette semester, men desværre for min underviser har jeg arbejdet med webudvikling på andre platforme før.
Underviserens holdning er jo at J2EE er det eneste rigtige og de giver aldrig argumenter for hvorfor man bør benytte J2EE, og hvorfor man IKKE bør benytte J2EE (de sidste er vigtigt for at give en objektiv vudering.)
Desværre så er det næsten umuligt at finde folk som ikke tænker på PHP/ASP.NET som pest, som også har erfaring med J2EE. (Og vores Underviserere har aldrig erfaring med mere end een ting -.-)
Derfor spørgsmål. Knowlegde is power.
Windcape (26) skrev:Hvordan vil jeg vide hvornår jeg skal benytte J2EE når det er 24 timers hovedpine bare at sætte Hello World op?
Jeg har stadig indtryk af, at du aldrig har arbejdet med enterprise-systemer. Når du har lagt de første 100 mande-år i et system, så er du ret ligeglad med om Hello World tog 10 minutter eller 10 dage at lave.
Windcape (26) skrev:Underviserens holdning er jo at J2EE er det eneste rigtige
Den slags er ikke værd at høre på. Det kan vi vist hurtigt blive enige om.
Windcape (26) skrev:Desværre så er det næsten umuligt at finde folk som ikke tænker på PHP/ASP.NET som pest, som også har erfaring med J2EE.
Det burde sige dig et eller andet, selv om det selvfølgelig aldrig kan blive mere end en indikator.
Jeg vil ikke kalde PHP "pest". Men jo mere erfaring jeg får med Java, jo mindre har jeg lyst til at kode PHP. Og jeg stoppede helt med PHP for længe siden.
Men jeg holder nu stadig på at PHP er det rigtige valg til rigtigt mange systemer.
Windcape (26) skrev:Derfor spørgsmål. Knowlegde is power.
Kort sagt: Refactoring og den slags bløde ligegyldigheder bliver altafgørende, når systemet bliver stort og vigtigt nok.
Windcape (16) skrev:
Men det er jo netop det som har gjort Ruby og Python så populære. At man ikke skal bruge evigheder på at sætte nye projekter op (rapid development and prototyping),
Hvis man vil lave rapid prototyping, så er Java EE næppe et godt valg.
Men til et stort projekt på 10000 eller 100000 timer er det altså ikke et problem om man skal bruge en time eller to på at lave directory strukturer og XML stubs når projektet skal sættes op.
Windcape (16) skrev:
samt at man ikke skal bekymre sig om at rebuilde et monster af et projekt bare fordi man vil ændre en lille smule.
Det er hurtigere at rebuilde i et static typed sprog end det er at køre app i et dynamic typed sprog.
Windcape (16) skrev:
Og så er vi jo ved at være derhenne hvor Struts overlevelse afhænger mere af at "vi bruger det allerede" end at folk ville ønske at lave ny-udvikling i det.
Nu er Struts 1 allerede legacy. Idag hedder det JSF. Men der er eksisterende Struts 1 apps med milliarder af linie kode som skal vedligeholdes.
Windcape (16) skrev:
Alle de enorme konfigurationsfiler definere jo en eller anden form for statisk data, f.eks. url-routing.
Der skal jeg slet ikke forstå at man vil have det ekstra performance overheat ved at bruge xml. XML i forbindelse med java skal jo netop analyseres, typisk for hver pageload, medmindre der benyttes noget sindsyg cache som ville gøre opdateringer et endnu størrere mareridt.
Hvis du tror at Struts config læses for hver page request må da have spist rustne søm.
Det er et framework for seriøs brug.
Den slags caches og det er ganske trivielt.
Og hvis du retter genstarter du web app.
Ligesom ASP.NET gør automatisk med web.config.
Windcape (18) skrev:Med et MVC framework, hvor er det så lige forskellen på enterprise og non-enterprise ligger?
Enterprise opfylder enterprise behov:
- det skal fungere godt i store projekter
- der skal helst være indbygget en masse features til reliability, scalability og security
Ikke-enterprise opfylder andre behov:
- det skal være nemt og hurtigt at bruge
- det skal performe godt
Forskellige behov fører til forskellige feature set.
Windcape (18) skrev:
Om jeg skal kode homebanking eller newz.dk, de grundlæggende funktioner som et webframework skal bruge er nu engang de samme.
Nej.
De har helt forskellige prioriteringer (og helt forskellige budgetter).
Alle har heller ikke brug for samme type bil.
Windcape (18) skrev:
Jeg ser intet i J2EE som jeg ikke kan i PHP/ASP.NET/Ruby/Python, kun at det er overkomplext at sætte en prototype op.
Java EE ikke J2EE.
(de ændrede navnet i en af mange mystiske versions nummer omorganiseringer)
Jeg tror at du har behov for at studere Java EE lidt nærmere.
servlet/JSP/JSF delen af Java EE dækker samme funktionalitet som PHP og ASP.NET - forskellen er:
________________type_________platform
Java EE______static typed_______alle
ASP.NET______static typed_____Windows
PHP________dynamic typed _____alle
(jeg tillader mig at ignorere alle de mere eksotiske features: servlets i Python, ASP.NET på Mono o.s.v.)
Bare her er der forskel.
Så er der 2 yderlige dele af Java EE:
EJB - som svarer til COM+ i MS verdenen
JCA - som der ikke rigtigt er noget tilsvarende til i MS verdenen
Og selvom COM+ kan bruges i .NET via System.EnterpriseServices, så er det stadig grundliggende en ikke .NET teknologi.
En teknologi som ikke ret mange forstår.
Python og Ruby er sprog. Der skal snarere sammenlignes med Zope, WebWare, RoR etc.. Men typisk vil de være tættere på PHP end på både Java EE og ASP.NET.
Windcape (18) skrev:
Om man så vil definere 1000 xml filer som "smarterer" er jo så et spørgsmål om holdninger, der er sjældent noget reelt grundlag for at vælge et løsning der kræver mere kode.
Ikke 1000. En 5-10 stykker lidt afhængig af backend og om man har behov for app server specifikke filer.
De er ikke lige populære host alle Java EE udviklere.
Men efter min bedste overbevisning, så er det den rigtige måde at gøre det på.
Alternativet er at have oplysningerne hardcoded ude i hundredevise af klasser/sider.
Ved at samle de specifikke oplysninger om XYZ i xyz-config.xml gør man dte langt nemmere at overskue og rette.
De XML filer kan faktisk opfattes som en for for AOP.
Grunden til at så mange udviklere ikke kan lide de XML filer er at på typisk Java vis, så er det ret omfattende at sætte sig ind i hvordan de skal se ud.
Windcape (18) skrev:
Det skulle da lige være udviklerglæde. Noget jeg absolut ikke finder i J2EE.
Ikke alle kan lide Java EE. Det samme gælder sikkert for alle de andre muligheder.
Windcape (24) skrev:Når jeg så har prøvet alle de frameworks jeg listede, og så ikke vælger J2EE, har jeg så valgt det beste værktøj til opgaven? :-)
Hvis du har gjordt dit forarbejde ordentligt, så vil jeg da tro at svaret er JA.
Windcape (24) skrev:
Hvis jeg vil have type sikkerhed så er Ruby, og ASP.NET stadig gode alternativer, til hvad PHP og Python ikke kunne klare.
Faktisk IronRuby og ASP.NET samtidig, to fluer med et smæk, samt typesikker og bedre udviklingsværktøjer end Java kan give.
Hmm.
Hvad giver følgende Ruby program hos dig ?
x = 123
x = "abc"
print x,"\n"
Java IDE'er er iøvrigt ledende.
Feature flowet går:
IDEA IntelliJ -> Eclipse -> Visual Studio
Windcape (24) skrev:
Men jeg har altså stadigvæk ikke set noget J2EE kan som alle andre WebFrameworks ikke kan.
Hvis ikke du har læst så meget om Java EE at du ikke har opdaget at det ikke udelukkende er til web, så tror jeg at du har brug for at studere lidt mere.
Det er ikke specielt udbredt men du kan sagtens lave Java EE med en fat client.
Windcape (26) skrev:Nej, det gør jeg ikke. Men hvad hvis jeg skulle på et tidspunkt?
Hvordan vil jeg vide hvornår jeg skal benytte J2EE når det er 24 timers hovedpine bare at sætte Hello World op?
J2EE er en del af mit studie dette semester, men desværre for min underviser har jeg arbejdet med webudvikling på andre platforme før.
Der kan naturligvis ikke gives en entydig algoritme for hvornår Java EE er bedste valg.
Men hvis et stort antal af følgende punkter er opfyldt så er Java EE ihvertfald en mulighed som du bør overveje:
* stort project
* høj stabilitet vigtigere end lave udviklingsomkostninger
* clustering er nødvendigt
* skalerbabarhed er nødvendigt
* brug for 4 eller 5 tiers
* transaktioner er kerne i sytsm
* multiple backend systemer (databaser eller andre)
Windcape (26) skrev:
Derfor spørgsmål. Knowlegde is power.
Se det er så sandt som det er sagt.
Takker for det mere info.
Hvis jeg husker rigtigt, så har JSF det altså ikke særlig godt med clustering, da den gemmer sessiondata i memory?
Da jeg benyttede Eclipses JEE version til at register HTML delen af en JSF fil, så var der f.eks. ingen automatisk intention af min HTML.
Derudover kommer hele problemet med at jeg ikke kan flytte settings fra den ene version af eclipse til den anden, og ikke opgraderer non-EE version til EE uden at skulle rekonfigurer alle mine settings og reinstallere alle mine moduler (svn osv.)
At Eclipse har features jeg ikke skal bruge til noget betyder ikke ret meget, når de grundlæggede ting jeg skal bruge ikke virker modsat til Visual Studio.
Og hastigheden for intellisense er stadig ubeskrivelig langtsom i forhold til VS. Har dog hørt den er bedre in IntelliJ.
Men hvordan kan folk holde ud at spamme Ctrl+Space hele dagen er mig en gåde.
arne_v (31) skrev:* clustering er nødvendigt
Hvis jeg husker rigtigt, så har JSF det altså ikke særlig godt med clustering, da den gemmer sessiondata i memory?
Problemet med både IntelliJ og Eclipse er at deres editors er horrible at arbejde med.arne_v (30) skrev:Java IDE'er er iøvrigt ledende.
Feature flowet går:
IDEA IntelliJ -> Eclipse -> Visual Studio
Da jeg benyttede Eclipses JEE version til at register HTML delen af en JSF fil, så var der f.eks. ingen automatisk intention af min HTML.
Derudover kommer hele problemet med at jeg ikke kan flytte settings fra den ene version af eclipse til den anden, og ikke opgraderer non-EE version til EE uden at skulle rekonfigurer alle mine settings og reinstallere alle mine moduler (svn osv.)
At Eclipse har features jeg ikke skal bruge til noget betyder ikke ret meget, når de grundlæggede ting jeg skal bruge ikke virker modsat til Visual Studio.
Og hastigheden for intellisense er stadig ubeskrivelig langtsom i forhold til VS. Har dog hørt den er bedre in IntelliJ.
Men hvordan kan folk holde ud at spamme Ctrl+Space hele dagen er mig en gåde.
Windcape (32) skrev:Problemet med både IntelliJ og Eclipse er at deres editors er horrible at arbejde med.
Eclipse (og storebroderen RAD) fungerer ellers fint her. Jeg er ikke så glad for den medfølgende JSP-editor, men det er ikke slemt nok til at jeg har giddet lege med alternativerne endnu.
Windcape (32) skrev:Hvis jeg husker rigtigt, så har JSF det altså ikke særlig godt med clustering, da den gemmer sessiondata i memory?
Det er servlet specs som bestemmer session håndtering ikke JSF.
Og servlet spec kræver at containeren kan migrere objekter i session hvis de implementerer serializable.
I praksis understøtter Java EE server normalt 2-4 af følgende:
* ingen session replication (med en load balancer som understøtter sticky sessions er det nogen gang eoptimalt)
* session replication via database
* session replication via netværk til alle cluster members
* session replication via netværk til et anden cluster member (sammen med en load balancer med sticky sessions giver det transparant failover med minimal netværks traffik)
Men ved alle sammen tvinger du enten programmøren til at tage højde for et grundlæggende problem i udviklingsmiljøet (JSF) eller at Serveren skal håndterer det.
Deres ide var meget fin i 99, men med dagtidens måde at designe Web 2.0 applications på giver det intet udover performance overheat.
Det er bla. også derfor at JSF jo bruger POST til sideskift per default (hvor stupidt det end må lyde).
.NET modellen med ViewState, eller alm. cookie=>session handling synes at kunne håndtere alting ligeså godt, så hvorfor have den ekstra overheat ?
Hvis det er meningen at Java EE skal være enterprise, hvorfor synes clustering så netop ikke at være tiltænkt i den oprindelige løsning?
Deres ide var meget fin i 99, men med dagtidens måde at designe Web 2.0 applications på giver det intet udover performance overheat.
Det er bla. også derfor at JSF jo bruger POST til sideskift per default (hvor stupidt det end må lyde).
.NET modellen med ViewState, eller alm. cookie=>session handling synes at kunne håndtere alting ligeså godt, så hvorfor have den ekstra overheat ?
Hvis det er meningen at Java EE skal være enterprise, hvorfor synes clustering så netop ikke at være tiltænkt i den oprindelige løsning?
Alt inkl. JSF kan køre stateless det kræver jo ingen funktionalitet. Men de fleste web sites har brug for state.
Hvis man har brug for state så kræver transparent failover mellem cluster noder noget. Java EE app servere har det. ASP.NET har lidt og man kan få 3. parts produkter hvis man har mere specielle ønsker. PHP har næsten ingenting (filer på netværksdrev er ikke nogen god løsning) og 3. parts produkter.
Hvis man har brug for state så kræver transparent failover mellem cluster noder noget. Java EE app servere har det. ASP.NET har lidt og man kan få 3. parts produkter hvis man har mere specielle ønsker. PHP har næsten ingenting (filer på netværksdrev er ikke nogen god løsning) og 3. parts produkter.
Ja, men hvad jeg synes JSF gør forkert er at den betragter ALTING som nødvendigt at være statefull.arne_v (40) skrev:Alt inkl. JSF kan køre stateless det kræver jo ingen funktionalitet. Men de fleste web sites har brug for state.
Det er rimelig unødvendigt at gemme informtioner om hvilken siden det er meningen du skal besøge i state, sådanne informationer bør komme fra bruger-input hver gang (GET requests).
Derudover så kan de meste state håndteres af klienten i dag (AJAX).
Den idelogi jeg designer websider efter er at POST requests som er synlige for brugeren (f.eks. ved F5 opdatering af en siden) skal være så fåtallige som mulige.
#41
Langt de fleste web apps har state. Om ikke så p.g.a. login.
Session er ikke defineret i JSF men i servlet spec. Servlets håndterer sessions ca. ligesom ASP.NET og formentlig ca. ligesom alt andet.
Hvis du gerne vil have page state gemt client side fremfor server side i JSF, så konfigurerer du den bare til det - det er dit valg.
AJAX fungerer faktisk ret godt sammen med JSF. Hvilken JSF implementation bruger du ?
Langt de fleste web apps har state. Om ikke så p.g.a. login.
Session er ikke defineret i JSF men i servlet spec. Servlets håndterer sessions ca. ligesom ASP.NET og formentlig ca. ligesom alt andet.
Hvis du gerne vil have page state gemt client side fremfor server side i JSF, så konfigurerer du den bare til det - det er dit valg.
AJAX fungerer faktisk ret godt sammen med JSF. Hvilken JSF implementation bruger du ?
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund