Dette indlæg er alene udtryk for skribentens egen holdning.

Uproduktiv med Ruby on Rails

19 kommentarer.  Hop til debatten
Blogindlæg24. august 2009 kl. 08:00
errorÆldre end 30 dage

Ruby on Rails fremhæves ofte for at gøre udviklerne mere produktive (muligvis på bekostning af den udviklede applikations performance, men det er en anden og meget omdiskuteret historie).
 
Men når man først for nylig er kommet i gang med at udvikle i Ruby (og Rails), så føles det mildest talt ikke sådan.
 
Helt, helt simple ting som at loade noget fra en URL kræver opslag i bøger eller på nettet. Man falder og slår sig på tåbelige ting som at glemme at konvertere et tal til en streng inden konkatenering.
 
Når jeg koder Java, så flyder koden på mærkværdigvis af sig selv; underbevidstheden transformere feature-ideer til syntax-checket kode, mens mine bevidste hjerneprocesser lægger projektplaner eller vandrer til kaffeautomaten.
 
Men når jeg koder Ruby, så er det lidt ligesom at lære at holde på en blyant igen. Godt nok har jeg hjælp af en Ruby-plugin til mit udviklingsmiljø (IntelliJ), der fanger en del syntaks-bommerter og i nogle tilfælde kan slå API-dokumentationen op, uden at jeg skal ud at rode i en browser, men alligevel så går det bare slet ikke i det
tempo, det plejer.
 
Misforstå mig ikke; det er spændende og udfordrende at rode sig ud i noget nyt, men det er også frustrerende ikke at kunne arbejde med den produktivitet, man er vant til.
 
Om jeg på et tidspunkt vil erfare, som Ruby on Rails-miljøet praler med, at man kan være en mere effektiv udvikler med Ruby on Rails, ja det vil jo vise sig. Men jeg hører gerne fra jer kloge koner (m/k) derude, som har erfaringer med emnet. ![Eksternt billede](http://www.version2.dk/uploads/smil3dbd4d6422f04.gif" alt=")

19 kommentarer.  Hop til debatten
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
1
24. august 2009 kl. 08:47

Nu er jeg "grøn" i både Java og Ruby, men har dog lænet mig op ad MVC i en del år efterhånden. Her er det min fornemmelse at RoR har en del at at byde på, bl.a. gennem sit "convention instead of configuration".

Hvor bruger du mest tid og flest kræfter - i kodeboksen eller i designboksen?

4
24. august 2009 kl. 10:01

Hvor bruger du mest tid og flest kræfter - i kodeboksen eller i designboksen?

Det kommer helt an på projektet! I det RoR-projekt, jeg sidder og roder med nu, har jeg skullet tilføje noget funktionalitet til en eksisterende applikation, så rammerne var givet på forhånd, og dermed var design-delen af arbejdet nok lidt mindre end det ellers ville have været.

Og når man så samtidigt skal lave det i et nyt sprog og framework, ja så kommer kode-delen nemt til at fylde en del.

Alt for mange trivielle fejl bliver ikke fanget før på køretid, så der skal væsentligt mere afprøvning til.

Ja det er indtil videre også min erfaring, at jeg ofte løber ind i fejl, som jeg i Java ville have fundet på compile-time. Det bliver selvfølgelig heller ikke bedre af, at jeg som "nybegynder" i RoR også laver flere fejl end normalt...

5
24. august 2009 kl. 10:16

Jeg har prøvet RoR et par gange, men det har aldrig helt føltes som "hånd i handske" for mig. Til gengæld har jeg forelsket mig i Groovy og Grails. For det første fordi indlæringskurven for en gammel Java-haj som mig har været ganske let, for det andet fordi jeg føler jeg har fået programmerings-glæden tilbage. Jeg synes ganske enkelt det er sjovere at udvikle i Grails end i andre MVC frameworks på Java platformen. At jeg så samtidig får et stort Grails community, en stabil teknologi (baseret på Spring Framework, Hibernate og Sitemesh), og fuld adgang til alle Java API'er derude, ja det er jo en rar sidegevinst (RoR kan også kalde Java når man bruger JRuby, men Groovy og Grails compiles til byte-code, hvilke gør sammensmeltning med Java meget nemt) Og ja, der er de samme problemer som RoR, det kræver unit-testing, for at sikre det virker. Men gør alt kode ikke det? /Søren

6
24. august 2009 kl. 10:28

Hej Anne-Sofie

Misforstå mig ikke; det er spændende og udfordrende at rode sig ud i noget nyt, men det er også frustrerende ikke at kunne arbejde med den produktivitet, man er vant til.

Jeg har arbejdet med RoR i et godt stykke tid efterhånden og jeg vil give dig ret i at det har en stejl indlæringskurve. Men der gik vel også et stykke tid inden du var produktiv i java? ;-)

Det største problem jeg har lagt mærke til når folk skifter til ROR fra et andet sprog er at de skriver ikke ruby kode med en ruby tankegang. Desværre medfører dette at koden ikke er særlig elegant.

8
24. august 2009 kl. 10:46

Men der gik vel også et stykke tid inden du var produktiv i java? ;-)

Helt sikkert, men dengang var jeg ung og entusiastisk og kodede mest i min fritid, så da tænkte jeg ikke så meget i produktivitet, som nu, hvor jeg har ting, der skal ud af døren... ;-)

7
24. august 2009 kl. 10:30

[qoute]Og ja, der er de samme problemer som RoR, det kræver unit-testing, for at sikre det virker. Men gør alt kode ikke det?[/quote]

Du unittester vel i forvejen så det tilføjer da ikke overhead? ;-)

9
24. august 2009 kl. 11:00

Du unittester vel i forvejen så det tilføjer da ikke overhead? ;-)

Nej - netop. Måske tvært imod - jeg synes også at unit-tests er nemmere at udtrykke i Groovy end i Java.

10
24. august 2009 kl. 11:32

Jeg bruger Rspec http://rspec.info/

Her er et simpelt eksempel fra ovenstående link:

bowling_spec.rb

require ‘bowling’

describe Bowling do

it "should score 0 for gutter game" do

bowling = Bowling.new

20.times { bowling.hit(0) }

bowling.score.should == 0

end

end

Det er da simpelt :-)

2
24. august 2009 kl. 08:55

Jeg har ikke selv prøvet Ruby on Rails, men jeg har ikke specielt lyst til at lave store eller komplicerede programmer i et dynamisk typet sprog. Alt for mange trivielle fejl bliver ikke fanget før på køretid, så der skal væsentligt mere afprøvning til. Endvidere er RoR's udstrakte brug af reflection bekymrende. Det er meget svært at lave dækkende afprøvning af kode, der bruger reflection i stor stil.

Generelt synes jeg, at brug af reflection på køretid vidner om manglende support for generisk programmering i modul- og typesystem. Et godt modul- og typesystem kan virke som reflection på oversættelsestid.

3
24. august 2009 kl. 09:42

@Anne-Sofie

Fortvivl ikke - der skal nok være masser af gode Java-jobs om 10 år - se bare hvad PL/1-udviklerne tjener i dag ;-)