- Gäst
- Oregistrerad ●
Tack tack! Textmate är riktigt kraftfullt och lätt på samma gång!
Börjar Rails redan bli gammalt? Och jag som precis upptäckt hur härligt det är! Äntligen ett språk som fungerar som jag tänker, inte som den där förbaskade Javan...
Och här sitter man och skriver ett mastodontprojekt i asp.net 2.0 på alldeles för mycket kod och får höra om ruby on rails när man börjar undersöka ajax och är 95% klar med projektet...
Man kan bli trött för mindre...
Nej för mina privata saker kommer jag snarast börja använda ruby on rails eftersom det är så grymt mycket enklare att göra saker i.
Asp.. bleh... asp.net buark... asp.net 2.0 och atlas *pff*
Jag har lirat igenom de flesta tutorials jag kan hitta och göra i min miljö, det är ett enkelt och kraftfullt språk som jag verkligen gillar! Men vill någon vara snäll och förklara denna SQL-fetisch som finns bland de som gör tutorials? Jag kan inte göra en egen en SQL-databasi en handvändning, och inte låter dom mig ladda ner någon heller att använda när jag gör dessa tutorials.
Vad är grejen? Jag har fattat att Ruby inte nödvändigtvis ska behöva använda sig av SQL. Det var lite därför som det valdes som språk för vårt projekt.
Jag har lirat igenom de flesta tutorials jag kan hitta och göra i min miljö, det är ett enkelt och kraftfullt språk som jag verkligen gillar! Men vill någon vara snäll och förklara denna SQL-fetisch som finns bland de som gör tutorials? Jag kan inte göra en egen en SQL-databasi en handvändning, och inte låter dom mig ladda ner någon heller att använda när jag gör dessa tutorials.
Vad är grejen? Jag har fattat att Ruby inte nödvändigtvis ska behöva använda sig av SQL. Det var lite därför som det valdes som språk för vårt projekt.
Förmodligen en kombination av pragmatism och gammal vana. Många trivs bra med att skapa tabellerna i pgadmin och andra grafiska program; det går snabbt och man kan dessutom enkelt ändra i tabellstrukturen, vilket brukar vara ett plus i initialskedet. Men det är en missuppfattning att man ska "slippa" SQL i Rails, det handlar snarare om att inte behöva ta till det i onödan. Som sagt, det handlar helt enkelt om pragmatism.
Men: Det går faktiskt hur bra som helst att skapa tabelldefinitionen med ren Ruby-kod i stället, då har man dessutom fördelen av att få helt databasoberoende tabelldefinitioner så att man inte behöver låsa sig till någon särskild DB. Du börjar med att öppna ett terminalfönster, gå till rotkatalogen för din Rails-app, och köra "script/generate migration CreateSchema". Sedan är det bara att redigera filen "db/migrate/001_create_schema.rb" och lägga in tabelldefinitionerna - i dokumentationen finns det några bra exempel:
http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
(du kan också kolla här för fler exempel)
Sedan när du är klar kör du bara "rake migrate" så skapas tabellerna, se bara till att du har konfigurerat databasanslutningen först (i config/database.yml).
Vad är grejen? Jag har fattat att Ruby inte nödvändigtvis ska behöva använda sig av SQL. Det var lite därför som det valdes som språk för vårt projekt.
Ok - detta citat är saxat från rubyonrails.com:
Rails is a full-stack framework for developing database-backed web applications according to the Model-View-Control pattern.
Vad gör du med ROR som *inte* behöver en databas? Har din applikation dynamisk data överhuvudtaget?
MVH
Kalle
Ok - detta citat är saxat från rubyonrails.com:
Vad gör du med ROR som *inte* behöver en databas? Har din applikation dynamisk data överhuvudtaget?
MVH
Kalle
Jodå, vi behöver minst en databas, men den är från början inte byggd i SQL och ingen av oss är så duktiga på det. Vi vill helst inte ha en enda stor databas i ett paket eftersom användarna kommer bete sig så dynamisk att vi antagligen måste hålla koll på filsystemet på vår server också, förutom databasen.
Niklas: Men använd ett verktyg för att skapa databasen då? Jag förmodar att de skriver SQL-koden för att det är det enklaste sättet att förklara vad de gör, och som dessutom är plattformsoberoende (till skillnad från att förklara tillvägagångssättet i något specifikt verktyg). Själv använder jag alltid CocoaMySql när jag hanterar mina databaser.
Niklas: Men använd ett verktyg för att skapa databasen då? Jag förmodar att de skriver SQL-koden för att det är det enklaste sättet att förklara vad de gör, och som dessutom är plattformsoberoende (till skillnad från att förklara tillvägagångssättet i något specifikt verktyg). Själv använder jag alltid CocoaMySql när jag hanterar mina databaser.
Jag fick inte CocaMySQL att fungera så bra med MySQL 5.0, så jag kör numera YourSQL. Fungerade bättre.
Ni som precis har börjat med Rails eller vill veta lite mer om ramverket, kan kika in på http://lindq.se/journal/
Jag har skrivit ihop lite texter där ang. Rails...
EDIT: Folk som vill ha "Screencasts" med ljud så finns de samlade här: http://rubyonrails.org/screencasts
Jag fick inte CocaMySQL att fungera så bra med MySQL 5.0, så jag kör numera YourSQL. Fungerade bättre.
Ni som precis har börjat med Rails eller vill veta lite mer om ramverket, kan kika in på http://lindq.se/journal/
Jag har skrivit ihop lite texter där ang. Rails...
EDIT: Folk som vill ha "Screencasts" med ljud så finns de samlade här: http://rubyonrails.org/screencasts
Tack för tipset! YourSQL lät mig installera och bygga en bra databas på en timme. Det känns bra med tanke på att de databaser jag arbetat med är byggda i ProLog eller Lisp eller något ännu mer obskyrt format.
Gissar på att niklas syftade på att man med ActiveRecord inte nödvändigtvis tränger att skriva ren SQL för att hämta tabelldata. Vilket ju också är sant, men den döljer ju inte direkt SQL på något sätt, bara gör det enklare att använda utan att behöva ty till SQL för "tråkiga vardagliga" queries...
Och man _behöver_ ju inte heller använda ActiveRecord om man inte behöver det, ActionPack bjuder ju på mycket annat roligt, ett par av mina projekt körs tex direkt mot Subversion repositories..
Men lite vetskap om hur SQL fungerar skadar ju inte, på samma sätt som kunskap om html behövs för webbutveckling...
Tänkte mest hojta till och säga att jag lägger en röst på RoR som trevligaste framework för databasdriven webbutveckling. Håller på att lära mig så smått, samtidigt som jag skriver om ett PHP-projekt jag håller på med. Det som har tagit mig 1.5 veckor i PHP (och jag rör mig rätt så fritt i PHP, även om man får rätt så fula kodningsvanor av att ha börjat programmering med PHP), har jag till hälften flyttat över till RoR på en dag. Notera att detta är från noll RoR-kunskap! Både Ruby och RoR passa mitt sätt att tänka på betydligt bättre, så den som klagade på syntaxen, fy-skäms!
Glömde att säga att Textmate inte leker snällt med CJK, vilket är lite synd när man håller på med japanska webbprojekt Det ska tydligen inte komma någon fix förräns 2.0 (vilket vara rätt så långt borta). Känns rätt så B att behöva skriva allt på engelska för att sen börja "fixa" grejer i Smultron (el. likn.) senare. Men jaja, det är ju inte RoRs fel...
Har hållit på lite med RoR också och blir ofta förvånad över enkelheten att göra vissa saker. Kan börja o skriva flera rader kod för att lösa något, sen kommer jag fram till att en rad räcker Det är ofta det händer, 20rader php kan man få ner till 1rad RoR känns det som.
Ett alternativ TextMate är den eclipse-baserade miljön radrails, http://www.radrails.org/
Har någon testat radrails?
Jag har kört RadRails en del och trivs bra med den. Funktionsmässigt är skillnaderna mot TextMate nog inte så stora. I alla fall inte när man har arbetat ett tag och lärt sig hur man skall göra olika saker. Filbläddring och redigering ser ganska lika ut med en hierarkisk filbläddrare och färgmärkning av dokumentets text.
Den största skilnaden är nog att RadRails har ett antal paneler för t ex generatorer, webbrikk, köra kommandon etc. I TextMate löser man det via makron och kommandon. Eftersom jag inte jobbat med TextMate så har jag svårt att uttala mig om vad som är bäst men jag antar att man efter ett tag gillar flexibiliteten i TextMates upplägg.
Min favorit av funktionerna i RadRails är integrationen med versionshantering i subversion. Man kan antingen göra uppdateringarna i filhateringen eller via separata synk-perspektiv. Riktigt bra om man är flera som jobbar mot samma projekt eller om man har flera datorer.
Jag tycker också det är kul att köra tester i RadRails. Man trycker på en knapp och får gröna eller röda ikoner på testfallen. Däremot är funktionen inte så avancerad och man kan ibland få leta en hel del i felstacken för att hitta var det gick snett.
Jag har varit på g att börja leka lite mer RoR men har läst lite om problem med databashanteringen. Hur fungerar det? Såg att någon skrev att man skulle hålla sig till en tabell, stämmer detta?? Jag kan tänka (hoppas) att detta inte stämmer. Såg i nån introduktionsvideo att han skapade tabellen i texteditorn, detta verkar krångligt. Jag skulle bli glad ifall någon som har koll förklarar hur man skapar databaser. Är det bra att använda RoR till projekt med mer komplexa databas modeller?
Nej, man ska inte hålla sig till en tabell, skulle ju vara ganska absurt... är det möjligtvis en databas du tänker på? Om man vill kan man ha sina modellklasser spridda över olika databaser eftersom databasanslutningen görs på klassnivå, men av naturliga skäl fungerar inte associationer över olika databaser.
Rails fungerar helt utmärkt på mer komplexa databasmodeller, skulle snarast säga att det är då man får mest hjälp av ActiveRecord, men för att allt ska fungera per automatik ska databasen vara strukturerad på ett visst sätt eftersom det är "convention over configuration" som gäller. Du kan skapa databasen med vilket program du vill.
Databaser bygger man hur man vill men för att det skall vara riktigt smidigt bör man följa konventionerna i rails. Man får mycket på köpet då. T ex bör id-fältet heta id, ett fält som används för att ange en relation skall heta <tabell>_id, tabeller som används för att beskriva en många till många-relaiton mellan två tabeller skall heta <tabell1>_<tabell2> etc etc. Om man bryter mot en konvention straffas man genom att man får skriva mer kod som beskriver hur det skall vara.
För att hantera databasen har rails "Migration" som är ett sätt att i ruby-kod beskriva hur en databas skall se ut. Den påminner om hur man bygger tabeller med sql. Två fördelar som man får genom att använda migration är att man kan versionshantera tabell-strukturen och att man får en databasoberoende beskrivning som gör att man lätt kan jobba mot olika fabrikat av databashanterare.