Detta är webbplatsen för mig, Johan Leitet, som är universitetsadjunkt i datavetenskap vid institutionen för Datavetenskap vid Linnéuniversitetet.
Jag är programansvarig för webbprogrammerarprogrammet och undervisar främst inom klientsidetekniker som HTML/CSS och JavaScript.
Den 18-19 februari kommer jag att vara med på en konferens kring nätbaserat lärande i högre utbildning. Jag kommer bland annat att prata om det arbete vi gjort med att göra Webbprogrammerarutbildningen publik. Vidare kommer jag att beröra lärplattformar i allmänhet och vad vi har planer framöver, så som t.ex. integration med externa verktyg (Ex. GitHub).
Läs mer i följande informationsfoldern Nätbaserat lärande i högre utbildning eller på Informa Sweden.
Idag höll jag en miniföreläsning vid eventet “En dag på universitetet“. Föreläsningen med titeln “Webben idag och i framtiden” redovisar trender inom webbutveckling just nu och jag spår lite om vad jag tror kommer att vara framtiden.
Du hittar presentationen här och vill du du bygga vidare på den så finns den på GitHub.
Detta är mitt tredje inlägg inom ramen för kursen RIA-utveckling med JavaScript. Artikeln behandlar Steg 2 – Hello World.
Så var det äntligen dags att börja koda. All tid denna vecka har lagts på pakethantering och relationer mellan moduler i projektet med hjälp av require.js. Jag har även tittat en del på hur man enkelt kan ladda in externa resurser till projektet och för detta har jag använt pakethanteraren Bower.
Jag flaggade redan i förra inlägget om att applikationen som kommer att utvecklas kommer att vara en applikation för att rapportera in studentresultat på uppgifter. Jag kommer att göra många begränsningar av applikationen, speciellt nu i början. Resultat på uppgift kommer att vara begränsade till U/3/4/5, en student kommer enbart att vara direkt knuten till en specifik kurs etc.
Enkel mockup som säkert kommer att vara utsatt för väldig förändring men den ger en bild av funktionaliteten i alla fall:
Eftersom jag valt att gå all in med molnbaserade IDEn Cloud9 så vill jag även undvika att ladda ner beroenden som Backbone, Require, Bootstrap, jasmin etc. lokalt för att sedan ladda upp dessa till editorn. Jag sprang därför på Twitters pakethanterare “Bower” som på ett riktigt smidigt sätt löser detta. Efter att installerat Bower kan man enkelt i en configurationsfil tala om vilka beroenden man har och Bower hämtar sedan ner dessa och placerar de i den katalog du specificerat. I mitt fall har jag valt /scripts/lib/.
Jag hittade en utmärkt guide för detta på tutsplus. Kort tillvägagångssätt:
Installera Bower genom terminalen i Cloud9:
npm install -g bower
Efter detta så kan man skapa en konfigurationsfil, .bowerrc, där jag talar om var jag vill att mina inladdade paket ska bo:
{
"directory": "scripts/lib",
}
Nästa steg är att skapa filen component.json i vilken vi talar om vilka beroenden vår applikation har och således vilka paket som Bower ska installera:
{
"name": "Student Result App",
"version": "0.0.1",
"dependencies": {
"jquery": null,
"backbone": null,
"underscore": null,
"requirejs": null,
"text": null,
"backbone.localStorage": null,
"bootstrap": null,
"jasmine": null
}
}
Det enda jag nu behöver göra för att få med dessa paket i projektet är att köra:
bower install
Detta hämtar hem senaste versionerna (null i components.json) men det går även att specificera vilken version av paket man vill ha. Det jag inte ännu testat är att hämta andra resurser med Bower men det kommer jag säkert att få användning av.
Jag har valt, som många andra, att använda Require.js för modulhantering och för att hantera beroenden mellan moduler. Require.js och Backbone lirar inte ihop out of the box men det finns en AMD-kompatibel version av backbone (och underscore) som man kan använda. Jag tycker inte det vara några större problem att få ihop det hela men jag identifierade snabbt att det inte är så snyggt att behöva ladda underscore så fort man laddar Backbone, eftersom Backbone är beroende av underscore. Underscore borde man behöva ladda först när man själv kommer att nyttja det.
require(['backbone', 'underscore', 'views/StudentView', 'models/StudentModel'],
function(Backbone, _ , StudentView, StudentModel) ...
Jag konsulterade David kring detta och som jag förstår det så finns det lite olika lösningar på detta. Den kanske enklaste är att skapa en egen modul som man laddar som “Backbone” som i sin tur laddar underscore och backbone tillsammans med eventuella utökningar av Backbone. Alltså:
define(['backbone_pure', 'underscore', 'localstorage'], function(Backbone) {
return Backbone;
});
där “backbone_pure” pekar på backbone-amd och modulen ovan döps till “backbone”.
David visade även en kanske ännu renare och snyggare lösning på problemet och det är att använda “shim” i requirejs.config.
require.config({
paths: {
"jquery": "lib/jquery/jquery",
"underscore": "lib/underscore/underscore",
"backbone": "lib/backbone/backbone",
"backbone.localStorage": "lib/backbone.localStorage/backbone.localStorage",
"text": "lib/text/text"
},
shim: {
'backbone': {
deps: ['underscore', 'jquery'],
exports: 'Backbone'
},
'underscore': {
exports: '_'
},
'backbone.localStorage': ['backbone']
}
});
Detta ger flera fördelar. När man nu väljer att använda backbone så kommer dess beroenden (underscore och jquery) automatiskt att laddas utan att vi explicit behöver ange det. Genom att “exports” på underscore och Backbone så knyts de globala “Backbone” och “_”-objekten till require och vi underviker globaler. Detta gör också att vi inte behöver använda de AMD-kompatibla versionerna av udnerscore och backbone.
Denna vecka har jag också fått lägga några timmar i Cloud9s editor och jag är både förtjust och inte. När allt flyter på så flyter det på riktigt bra. Jag gillar editorn, code completion fungerar utmärkt, riktigt smidigt med terminalen etc. Dock har jag varit oerhört frustrerad över c9 från och till. Det är inte så sällan sparningar misslyckas och man måste prova att spara om och om igen. Ibland har det inte räckt att spara igen utan jag har varit tvungen att starta om editorn innan det fungerat. Jag har främst kört c9 i chrome och två gånger har tabbarna i chrome krashat när jag suttit och editerat. Helt nöjd är jag alltså inte, men jag hoppas att det flyter på lite bättre nu när jag istället valt att testa i FF.
Jag har tyvärr inte hunnit med så mycket denna iteration som jag hade hoppats. De avgränsningar jag fått göra och skjuta upp till nästa vecka är:
Något som jag är intresserad av att kika på men ännu inte hunnit ta tag i är en snygg “deploy-lösning”. Alltså, hur driftsätter jag? Tanken här är väl att använda require.js optimizer men jag har inte hunnit titta allt för mycket på det ännu.
Detta är mitt andra inlägg inom ramen för kursen RIA-utveckling med JavaScript. Artikeln behandlar Steg 1 – Vägval.
Det är så dags att sammanfatta veckans arbete som inneburit väldigt mycket läsning och instudering. Det finns verkligen hur mycket som helst som man vill fördjupa sig i men det gäller att sålla och prioritera. Fokus har legat på instudering av Backbone.js.
Backbone.js är helt nytt för mig. Jag har givetvis stött på det i många sammanhang men aldrig tagit mig tiden att sätta mig in i vad det egentligen är. Jag har haft bilden av det stora och komplicerade ramverket men när jag nu tagit mig tiden att lära känna det så har jag snarare mötts av ett litet nätt bibliotek vilket var en positiv överraskning. Det känns rätt för denna kurs att själv få styra över sin kodorganisation och istället få hjälp av biblioteket där det är motiverat.
Jag gillade verkligen Nick Gauthiers introduktion till Backbone.js och speciellt hans tips kring upplägg. Det som han inte fokuserar speciellt mycket på i videon är organisation av vyer/modeller och collections och namngivningen är väldigt okonsekvent så där kan man försöka vara mer strukturerad och noggrann.
Nick använder Backbone.js tillsammans med template-hanteratren Handlebars. Jag gillade helt klart upplägget och köper detta rakt upp och ned utan någon egentlig efterforskning. Jag stämde även av med David kring detta och fick rekommendationen att fokusera ifrån vilken template-hanterare som används och snarare fokusera på hur den ska användas med rådet om att hålla sina templates/vyer i separata html-filer som hanteras via modulhanteraren snarare än att lägga in dessa i ursprungsdokumentet inkapslade i script-taggar. Detta är absolut något jag ska ha fokus kring.
I mitt förra inlägg så flaggade jag för att jag kommer att köra Sublime Text 2, men under veckan som gått så har jag tänkt om. Jag vill verkligen gå “all in” och köra på det som jag tror kommer att gälla i framtiden. Ett helt onlinebaserat IDE. Det självklara (?) valet blir därför Cloud9 IDE där integration etc. är snyggt löst gentemot GitHub. Förövrigt så har jag tankar om att även börja rekommendera Cloud9 i min introkurs då det skulle underlätta handledningen väsentligt.
Jag är ganska färgad av Zakas och Crockford vad det gäller kodstil och jag ser ingen anledning till förändring här. Jag har kikat igenom Googles JavaScript Style Guide och jag tycker även den är väldigt samstämmig med Zakas och Crockford. JSLint (eller fork av) kommer att användas och följas även om mina känslor kommer att såras.
För att bredda mig lite jag läst igenom Zakas bok “Maintainable JavaScript” och den innehåller en hel del matnyttigt kring just kodstil och generellt upplägg av projekt. Jag kommer att så konsekvent jag kan försöka följa regelverket och rekommendationerna i boken och förhoppningsvis kunna återknyta i slutet av kursen hur detta gått.
4 mellanslags indentering är det jag kommer att köra på, och det verkar dessutom vara default i Cloud9.
Jag har velat fram och tillbaka om jag ska släppa det eller gå all in och efter samtal med David har jag kommit fram till att testa på att testa. Kanske kan man börja med att bara testa sina modeller? Hur som helst så kommer jag att köra på Jasmine.
Require.js är rekommenderat för kursen för att sköta beroenden och kodorganisation och jag kommer absolut att försöka mig på att få rätt på det. Jag har dock inte ännu bestämt om jag ska gå hela vägen med att köra jQuery och Backbone som AMD-moduler eller om jag låter dessa yttre beroenden finnas. Troligtvis lutar det i ett inledningsskede åt det senare.
Eftersom slutmålet är en applikation som förvisso inte är så stor, men som ska vara framtagen som om den är ett väldigt stort projektet så kommer jag att fokusera min dokumentation till JSDoc. I mitt tycker verkar Brocco lämpa sig bättre till mindre projekt där koden kanske ryms i en eller ett fåtal filer.
I en kurs likt denna där fokus är på process och arkitektur snarare än produktinnovation så känns det naturligt att välja en uppgift i en känd problemdomän. Mitt val blir därför att göra en single page-applikation för rapportering av resultat som är tänkt att kunna användas av handledare/examinatorer för att på sikt rapportera in resultat till CoursePress vid laborationshandledning. Applikationen kommer att vara en offlineapplikation som sparar alla resultat mot localstorage, men som fördjupning i kursen tänkte jag skjuta in mig på att få en snygg synkning av dessa resultat med hjälp av en WebWorker (dock inte spikat).
Vid laborationshandledningar är det inte helt ovanligt att man inte har tillgång till internetuppkoppling under redovisningstillfället varför det också är naturligt att spara allting lokalt och kunna använda applikationen i offlineläge.
3 huvudvyer: Laborationsgruppsvy, Laborationsvy och Studentvy.
Eventuellt kommer jag också att göra ett inmatningsgränssnitt för att lägga till studenter/uppgifter etc. Men i praktiken är detta något som görs på backenden. I första skedet siktar jag in mig på en enkel importfunktion av exempeldata via XHR.
Som avgränsning kommer jag troligtvis att “hårdkoda” applikationen till att enbart gälla för en fördefinierad kurs med fördefinierade moment och betygsskalor. Det bör dock inte vara något problem att utveckla och lägga till även kurshantering etc.
Följande setup av ramverk/bilbliotek och tillägg tänker jag mig använda:
Jag har länge varit nyfiken på CoffieScript men känner att detta inte är rätt tid och plats. Jag vill kunna fokusera på Backbone och kodstruktur utan att lära mig ny syntax. Jag lämnar detta för nu helt enkelt. Även Sweet.js låter intressant men det får helt enkelt vara nog med sötsaker för nu.
Jag blickar nu framåt mot nästa vecka. Äntligen dags att börja koda, om inte så mycket så i alla fall lite.
en utav Linnéuniversitets lärplattformar. Som inloggad student kan du kommunicera, hålla koll på dina kurser och mycket mer. Du som är gäst kan nå de flesta kurser och dess innehåll utan att logga in.
För att logga in behöver du ett studentkonto vid Linnéuniversitet.