Studentene i 1.klasse drift (1 BADR) fikk som øvingsoppgave i faget Informatikk 2 å visualisere et problem fra operativsystemteori om prosesser.

Studentene Anders Thoresen, Frank Tore Moe Thornæs, Fredrik Treimo, Kjell Are G Einarsve, Martin Haugan Bordvik, Tobias Berg har laget en imponerende videosnutt som de har brukt mye tid på. Det er liten tvil om at det må ha vært lærerikt å lage denne animasjonen. De må ha løst problemet, forstått detaljene og tenkt ut en kreativ måte å formidle løsningen på. Selv om du kanskje ikke har inngående kjennskap til bruk av semaforer, så se likevel fra 1 min og 30 sekunder og litt utover.

Du kjenner kanskje igjen teknikken/idéen fra en annen populær YouTube-video, men jeg (Svend Andreas Horgen) vil likevel si at dette er et imponerende stykke arbeid som studentene har gjort.

I fall det har interesse – slik lød oppgaveteksten:

Se på metodene wait() og signal(). Vær sikker på at du forstår disse. Gitt at prosess P2 kjører akkurat nå. Prosesene P4, P3, P7 og P5 er de neste i CPU-køen. Alle prosessene ønsker å få tilgang til felles dataområde. Du må selv sette opp noen setninger i hver prosess som utgjør kritisk region og noen som er utenfor kritisk region.
Du skal lage en visualisering (gjerne en video) som viser hva som skjer i detalj når:

Spør faglærer om du trenger tips til hvordan en visualisering kan lages. Et godt tips er å bruke en tavle, tegne opp og forklare, mens dere filmer med for eksempel et mobilkamera. Til slutt skal dere skrive et mulig videre kjøreforløp helt til alle prosessene er ferdige. Hvor langt? Vanskelig å si, spørs hvordan dere gjør det. Sikkert mulig å forklare på 1/2 A4-side men mulig det trengs mer plass. Legg uansett vekt på at forklaringen skal være god heller enn lang…

Dette innlegget har 1 kommentar. Gjerne bidra :-)

Fra venstre: Svend Andreas Horgen og Geir Maribu (HiST), statssekretær Kyrre Lekve (KD), Kristin Heggen og Nina K. Vøllestad (UiO)

NOKUT er det nasjonale organet for kvalitet i norsk utdanning og deler årlig ut en utdanningskvalitetspris på NOK 1.000.000,- AITeL ble sammen med Universitetet i Oslo tildelt 500.000 kr hver. Dette er stort for oss.

Du har kanskje allerede lest om vårt nye rom for læring på denne bloggen? Rommet tilrettelegger for studentaktive læringsmetoder og vi opplever at hele pedagogikken legges om. Læreren må tenke nytt om sin rolle, og studentene blir satt i sentrum for egen læring. Læringsutbyttene blir sentrale. God bruk av IKT forsterker læringseffekten. Vi bygger på årevis med opparbeidet kunnskap om IKT i læring, utveksler erfaringer og prøver stadig ut nye kreative opplegg. Du kan se eksempler på hva dette innebærer på wikien for prosjektet.
Se gjerne også en filmsnutt som viser rommet i bruk (2 minutter lang).

En stor takk til studenter, lærere, teknisk støtte og ledelsen som alle har bidratt med å skape et godt rom for læring og er med på å utvikle fremtidens læringsarenaer. I videoen under kan du se prisutdelingen. Se gjerne i HD og fullskjerm.

For å ikke få mer enn 15 minutter video (maks på YouTube), er delen hvor Universitetet i Oslo mottar sin del av prisen, skilt ut i en egen video:

Prisen har fått en del eksterne omtaler, her er en liste:

• NOKUT – begrunnelse og bilder
• Teknisk Ukeblad
• Kunnskapsdepartementet
• HiST
• NTB
• Uniforum ved UiO
• Norgesuniversitetet
• Forskerforbundet

Dette innlegget har 1 kommentar. Gjerne bidra :-)

Av: Svend Andreas Horgen, høgskolelektor og en av faglærerne i Samarbeidsteknologi

Studentene i 2.klasse i faget Samarbeidsteknologi fikk i øvingsoppgave å lage videoer om temaet Samarbeid på nettet. De skulle utforske verktøy som Skype, Etherpad, Adobe Connect, Google Docs og liknende, og sette inn i en profesjonell sammenheng. Oppgaven lød:

Dere skal lage en video som presenterer et eksempel på god bruk av samarbeidsverktøy. Videoen må ikke være mer enn 5 minutter lang. Det kan være vanskelig å begrense seg til bare 5 minutter, så her må dere planlegge godt. Husk at målgruppen ikke kan noe om samarbeidsverktøy, så dette må kommuniseres godt. Dere må gjerne være kreative.

Ordet «kreative» var smart å ta med, for du verden, her var det mye kreativt og bra! De bidragene hvor studentgruppen har gitt samtykke til at filmen kunne vises, er inkludert under (se gjerne i fullskjerm).

En gruppe har lagt ut videoen som HTML5 på egen webside

Tror du dette var lærerikt, og kan produktene være til nytte for andre? Har du innspill, så er det som vanlig veldig kjekt med kommentarer.

Dette innlegget har Comments off. Gjerne bidra :-)

Av: Per Borgesen, dekan ved AITeL

Læringsmiljøutvalget ved HiST deler hvert år Studiekvalitetsprisen ved HiST på kr 50.000. I år ble prisen delt i to – og begge delene gikk til informatikkmiljøet AITeL.

Den ene delen gikk til 6 lærere/forskere som sammen har kjørt et emne innen flerfaglig samhandling der metoden Concurrent design, som avdelingen forsker på, ble benyttet. Det er studentene som har tatt emnet som har nominert de tilsatte fordi de har hatt uvanlig godt utbytte av opplegget og samtidig blitt trukket inn i forskningsaktiviteten ved avdelingen. Bildet viser Monica Storvik som mottok prisen på vegne av hele gruppen, som i tillegg besto av Geir Ove Rosvold, Greta Hjertø, Tor Atle Hjeltnes, Knut Arne Strand og Tore Berg Hansen.

Den andre delen av prisen gikk til det aktive studentutvalget ved AITeL. De fikk prisen for prosjektet EMO – Engasjement, Motivasjon og Oppførsel. Dette er et kurs for studenter drevet av studenter i samarbeid med studentsamskipnaden i Trondheim. Målet med kurset er å skape større engasjement og motivasjon hos studentene og fremme deltakende oppførsel i studiesituasjonen. Dette er en innsats for studiemiljøet som langt overstiger det man normalt forventer av studentene – og det er et dokumentert prosjekt som kan benyttes ved andre avdelinger. Leder i studentutvalget ved AITeL, Tor Håkon Holthe (til venstre i bildet) mottok prisen på vegne av studentutvalget.

Klikk på bildet for stor versjon

Som om ikke dette var nok fikk studentutvalget også prisen på kr 5000 for å være avdelingen i HiST med best svarprosent på høgskolens undersøkelse om inntakskvalitet.

På bildet ses også dekan ved AITeL Per Borgesen, nummer to fra venstre, og rektor ved HiST, Trond Michael Andersen.

Gratulerer til vinnerne – og takk for god innsats!

Dette innlegget har Comments off. Gjerne bidra :-)

Hvordan drive support på et større datasystem? 24sevenoffice er SAAS-basert (software as a service) som betyr at hele systemet er online (krever ingen innstallasjon for å brukes). I dette intervjuet viser kundekonsulent Joakim Løberg oss litt rundt i dette ERP-systemet. og hvordan en kan hjelpe kunder effektivt og raskt.

Det kommer flere videointervjuer i tiden fremover og vi skal stadig mer i dybden å it-faglige temaer. Følg med videre!

Tidligere bidrag i denne serien:

• 3D-animasjon (Ragnvald Johansen)

Dette innlegget har Comments off. Gjerne bidra :-)

AITeL er med i et spennende forskningsprosjekt i regi av Norgesuniversitetet. Vi har laget en blogg som vi har kalt «Snarfilm» og det går ut på å lage ulike typer av videosnutter i en pedagogisk kontekst, så raskt og effektivt som mulig. Prosjektleder Geir Maribu har demonstrert hvordan en kan lage en snarfilm på 1-2-3. Se videoen til Geir på bloggen til prosjektet:

http://snarfilm.blogspot.com/

Dette innlegget har Comments off. Gjerne bidra :-)

Av: Helge Hafting, høgskolelektor

I datamaskinens barndom skjedde mye av utviklingen i USA. Det var mange som lagde maskiner, og etterhvert så man et problem:

Filer laget på en maskin, kunne ikke brukes på maskiner fra andre leverandører.

Data ble lagret på hullkort og tape, og hver produsent hadde sin måte å gjøre det på. Et hullmønster som kodet «M» på en maskin, tolket en annen som «(», for eksempel.

Løsningen på dette problemet ble ASCII. Dette er en standard som spesifiserer hvordan 127 vanlige tegn skal kodes. Bl.a. sifre, store og små bokstaver fra A til Z, og en del andre tegn som punktum, komma og slikt. Datamaskiner standardiserte etterhvert på at 1 byte=1 tegn. Det gikk greit, for en byte har i alt 256 mulige verdier.

Dette fungerte for amerikanerne, men ikke for resten av verden. Bokstaver som «ÑÆß» var ikke tilgjengelige, for ikke å snakke om andre skriftsystemer som gresk, russisk, kinesisk og arabisk.

Det ble laget mange midlertidige løsninger. Noen byttet ut de minst brukte ascii-tegnene for å få «sine» ekstra bokstaver. Andre innså at en byte har 128 mulige verdier i tillegg til ascii, dermed kan man ha ascii + 128 andre tegn.

Den byte-baserte løsningen ble brukt en stund, men den hadde sine problemer. Kineserne har for eksempel over 30 000 tegn. Også europeerne har mer enn 128 tegn utover ascii, så det som var en «ú» på en norsk maskin, kunne bli en «Ż» på en latvisk maskin.

Den endelige løsninge ble unicode. Unicode er ikke byte-basert, og har plass til alle skrifttegn i alle språk. I tillegg kommer mengder av spesialtegn fra matematikk, typografi og annet.

Men unicode skapte et annet problem. Unicode gir hvert tegn et nummer, men sier ikke noe om hvordan tegnene skal kodes i datamaskinene. Man kunne brukt unicode-numre direkte, men det ville blitt upraktisk på mange vis:

• En ville trengt 4 byte per tegn; de som klarer seg fint med ascii er dermed ikke interessert i å firedoble lagringsbehovet. De er heller ikke interessert i et inkompatibelt system hvor det ikke går an å lese de enorme mengdene med eksisterende tekst (og programkode) som er laget i ascii.
• All programvare må skrives på nytt. Det er ikke bare det at tegn må representeres med en annen datatype. Mange programmeringsspråk bruker en byte med verdien 0 for å markere hvor i minnet tekststrenger slutter. Men når et tegn består av 4 byte, vil det bli en god del tegn som inneholder en byte eller to som er 0.

For å løse dette måtte man finne en god måte å representere unicode. Flere måter fins, men UTF-8 er en av de bedre. UTF-8 har mange praktiske egenskaper:

• Tegn som finnes i ascii, kodes akkurat som før. Altså verdier fra 0–127, lagret i én byte. Dette gjelder også 0-tegnet, som brukes for å avslutte tekststrenger i programmer. Dermed er utf-8 bakoverkompatibelt med ascii.
        – Vi trenger ikke gjøre om på programmeringsspråk og kompilatorer
        – Vi trenger stort sett ikke gjøre noe med eksisterende kildekode
• Tegn som ikke er i ascii, representeres med 2, 3, 4, 5 eller 6 byte. Dette er gjort på en slik måte at det første tegnet i sekvensen angir hvor mange byte det er. Resten av sekvensen består av byte-verdier kodet slik at programmet kan se at de er «fortsettelsestegn». Dermed er det lett for programmer å finne start og slutt på slike sekvenser, enten de går gjennom tekststrengene forlengs eller baklengs.
• Tegn som trengs for å skrive engelsk, representeres med en byte per tegn. Tegn som trengs for andre europeiske og arabiske språk trenger to byte per tegn. Det gjelder både bokstaver som «æøåü», og greske/kyrilliske/arabiske/hebraiske alfabeter. Alle andre levende språk kan skrives med tre tegn per byte. Fire eller fler byte per tegn trengs stort sett bare for historiske språk.

Tabell som viser bitmønstrene som brukes i UTF-8. I første byte angir antall bit som er 1, hvor mange byte som er i tegnet. Resterende bytes begynner med 10 for å angi at de er fortsettelse på et tegn. Biter markert som «x» angir tegnnummeret i unicode.

Klikk på bildet for stor versjon

UTF-8 har blitt en suksess, om lag halvparten av alle nettsider er i utf-8. Resten er fordelt på mange andre kodesystemer, mange av dem er gamle systemer som er på vei ut. (windows codepages, mac, diverse iso8859-x)

Med utf-8 er det ikke noe problem å blande mange skriftsystemer i samme dokument eller tekstfil:

Norsk æøå ÆØÅ
Kyrillisk Moskva: Москва́, Kiev: Київ
Gresk Athen: Αθήνα, Parthenon: Παρθενών
Kinesisk Bejing: 北京 Shanghai: 上海

Hvilken erfaring har du med utf-8? Har du eksempler på problemer som kan oppstå for eksempel i web- eller programmeringssammenheng?

Dette innlegget har 2 kommentarer. Gjerne bidra :-)