Dette er en kopi av en bloggpost som Martin Bekkelund har publisert på sin blogg, og det handler om Datalagringsdirektivet.

Fordi teknologien er usynlig, abstrakt, komplisert og utformet av mennesker, er det få som reflekterer over at teknologi kan være noe negativt, til tross for at intensjonene kanskje er gode.

Det er mandag morgen, og du skal på jobb. Idet du kommer ut døra treffer du en velkledd mann i sort dress, hvit skjorte og et tynt, sort slips. Du ser på ham og han ser på deg gjennom et par store, mørke solbriller. I den venstre hånden holder han en notisblokk, i den høyre en penn. Han noterer noe på notisblokken og stikker den i lommen.

Når du går nedover veien legger du merke til at mannen følger etter deg, mens han stadig noterer på notisblokken.

Etter en stund har du fått nok og bestemmer deg for å konfrontere mannen med hans oppførsel. Hvorfor følger han etter deg? Og hva er det han noterer i notisblokken sin? Mannen gir deg et ignorant tusenmetersblikk gjennom de mørke solbrillene. Han svarer ikke.

Det du ikke vet er at mannen er fra politiet, og er et ledd i myndighetenes nye satsing for å forhindre terror og alvorlig kriminalitet. De skal overvåke alle mennesker, uansett om de har gjort noe galt eller ei, for å sikre seg beviser i tilfelle du skulle gjøre noe galt.

For oss som bor i et fritt samfunn hvor rettssikkerheten står sterkt høres dette helt usannsynlig ut. Vi ville aldri akseptert menn som følger etter og overvåker oss.

Problemet er at mannen allerede eksisterer. Men det er en liten forskjell på mannen beskrevet i denne historien og mannen som allerede eksisterer. Han er usynlig, og finnes foreløpig kun i EU. Mannen som overvåker oss er ikke en mann av kjøtt og blod, men en usynlig robot som samler inn informasjon om hvordan vi bruker våre elektroniske hjelpemidler. Hver gang du ringer noen er han der og noterer seg hvem du ringer, når du ringer og hvor du befinner deg når samtalen tas. Det samme når du sender SMS, e-post eller bruker internett. Og med en smarttelefon i lomma blir vi gjenstand for kontinuerlig overvåking.

Menn i mørke dresser og solbriller som overvåker oss i gatene er selvfølgelig uakseptabelt. Hvorfor skulle det være mer akseptabelt med samme overvåking bare fordi mannen er usynlig? Det er derfor du skal si nei til Datalagringsdirektivet som Arbeiderpartiet ønsker å innføre i disse dager.

Denne teksten er å anse som Public Domain. Hvis du misliker den overvåkingen Arbeiderpartiet legger opp til med Datalagringsdirektivet kan du kopiere denne teksten, publisere den på din egen blogg og oppfordre andre til å gjøre det samme.

Dette innlegget har Comments off. Gjerne bidra :-)

Av: Mikael Brevik, student og veileder i det nye Android-faget

Dette er siste del av bloggserien om JOIN, og vi skal nå se på CROSS JOIN. Del 1 handlet om INNER JOIN og NATURAL JOIN. Del 2 handlet om LEFT OUTER JOIN og del 3 om RIGHT OUTER JOIN. Del 4 handlet om FULL OUTER JOIN.

CROSS JOIN

Denne foreningen er litt anderledes enn de vi har sett på til nå. På norsk kalles dette gjerne kryssprodukt eller kartesisk produkt. Her har vi en forening uten noe nøkkelord, altså uten ordet JOIN i spørringen. Vi bruker rett og slett flere tabeller adskilt av komma etter FROM. Uten noe seleksjon (i praksis WHERE-nøkkelordet) vil dette gi alle mulige kombinasjoner av de to tabellene sammenlagt. Dette er det samme som INNER JOIN (se bloggserien del 1) vil gjøre dersom man ikke har en seleksjon eller seleksjonen alltid resulterer til TRUE.

Eksempel på CROSS JOIN

For å illustrere dette bedre lager jeg to nye tabeller. En av disse tabellene er cross_test_1 som har kun én kolonne/attributt; numb. Denne tabellen inneholder følgende data: 1, 2, 3. Jeg har også en annen tabell med navn cross_test_2 som inneholder akkurat samme data.

Vi tester det ut:

Vi kan oppnå samme resultat med INNER JOIN (dersom seleksjonen mangler eller alltid resulterer i TRUE):

Noen ord helt til slutt

Da er artikkel-serien om forening i SQL over. Jeg vil takke for følget og håper dere har dratt nytte av disse innleggene. SQL er gøy, eller hva?

Dette innlegget har 1 kommentar. Gjerne bidra :-)

Stadig flere bruker sosiale medier profesjonelt. Mange studenter ved Avdeling for Informatikk og e-Læring ved Høgskolen i Sør-Trøndelag gjennomfører bacheloroppgaver nå i vår. Det er flere som skriver om sosiale medier. En av studentgruppene holder for tiden på med en undersøkelse om mer profesjonell bruk av sosiale medier, hvor du kan bidra.

Hvordan bruker du sosiale medier? Anbefaler på det sterkeste at du går til studentgruppens blogg, ser videoen de har laget (som for øvrig er knallbra) og i tillegg fyller ut undersøkelsen. Hvorfor bruke tid på dette? Fordi:

• Studentene trenger tilbakemelding for å kunne gjøre en god bacheloroppgave
• Du kan få noen nye innfallsvinkler på sosiale medier gjennom å se på spørsmålene som stilles
• Videoen er som sagt i seg selv verdt et besøk

Dette innlegget har Comments off. Gjerne bidra :-)

Av: Svend Andreas Horgen, høgskolelektor og faglærer i IKT og læring (LN504D)

Jeg har et lite problem som jeg trenger input på. I flere fag jeg underviser, blant annet faget IKT og læring (LN504D), skal studentene skrive blogg og kommentere på hverandres blogger. Dette er lærerikt, men har en organisatorisk utfordring. Hvordan samle inn lenkene på en rask og effektiv måte?

Til nå har vi brukt forum. Alle poster et innlegg hvor de limer inn lenken sin. Ulempen er at det fort blir andre diskusjoner, og da mister en oversikten. Programmereren i meg sier at jeg kan jo bare sette meg ned med PHP noen timer og programmere en liten løsning selv. HJEEELP, jeg har ikke noen timer til overs akkurat nå. Det fins sikkert noen smarte måter som involverer eksisterende tjenester, for eksempel delicious, Google, Etherpad eller hva da? Wiki blir for knotete tror jeg. Har du noen forslag?

Helt konkret: 20 studenter skal oppgi navn og URL til sin blogg. Alle 20 skal kunne se oppgitte URL-er til enhver tid, helst klikkbare lenker slik at oversikten kan brukes som nav… Noen studenter lager blogg med en gang, andre bruker noen uker før de setter i gang. De er altså ikke tidsmessig i gang samtidig. Derfor behovet for automatisert administrasjon.

Gode tips verdsettes høyt – legg gjerne igjen en kommentar!

Dette innlegget har 17 kommentarer. Gjerne bidra :-)

Du som leser denne bloggen http://blogg.itfag.no er trolig interessert i IKT og teknologi. Mange studerer IT, enten på fulltid, deltid eller enkeltfag i ny og ne (nettbasert). Studier fokuserer på både teori og praksis, men det kan være motiverende å se hvordan ting anvendes i det virkelige liv. Vi starter derfor nå opp en ny og spennende intervjuserie på denne bloggen. Først ut: 3D-animasjon

Hvordan lage gode, profesjonelle 3D-animasjoner? Ragnvald Johansen jobber med 3D-animasjon til daglig i firmaet redturbine. Her forklarer han hvordan verktøyet 3D Studio Max fungerer, og kommer inn på viktige prinsipper knyttet til animasjon. Se gjerne i HD

Vi har allerede avtalt fag-intervjuer med mange dyktige mennesker, og i tiden som kommer vil du kunne lære av flere dyktige fagfolk fra næringslivet på denne bloggen, både innen Ajax, CSS, PHP, web generelt, cloud computing og så videre. Kan dette være nyttig og inspirerende å lese om? Hva vil du høre om? Har du/din virksomhet noen gode itfaglige temaer som egner seg her? Legg gjerne igjen en kommentar.

Dette innlegget har 4 kommentarer. Gjerne bidra :-)

Av: Mikael Brevik, student og veileder i det nye Android-faget

Dette er del 4 av bloggserien om JOIN, og vi skal nå se på FULL OUTER JOIN. Del 1 handlet om INNER JOIN og NATURAL JOIN. Del 2 handlet om LEFT OUTER JOIN og del 3 om RIGHT OUTER JOIN. Her er tabellene vi bruker i denne bloggserien:

FULL OUTER JOIN

Siden dette også er en OUTER JOIN kan vi kanskje se for oss hva vi kommer til å få. Dette er en ytterforening som ikke favoriserer noen side. Den kommer til å vise poststeder med og uten personer og personer med og uten poststed

Eksempel på FULL OUTER JOIN

Nå er det slik at hverken JavaDB eller MySQL støtter FULL OUTER JOIN, så jeg vil ikke få vist eksempel på resultat her. Resultatet ville i vårt eksempel være veldig likt RIGHT JOIN (fra del 3) bare med en ekstra tuppel, nemlig den uten registrert postnummer.

I siste del skal vi se på CROSS JOIN. Kom gjerne med tilbakemeldinger i kommentarfeltet.

Dette innlegget har 3 kommentarer. Gjerne bidra :-)

Av: Svend Andreas Horgen, høgskolelektor og med i FoU-prosjektet Snarfilm

Kan en video bidra til å motivere til læring i forkant? Jeg tester nå ut videoproduksjon i faget Webprogrammering i PHP (LV197D) i forbindelse med vårt nye forskningsprosjekt i regi av Norgesuniversitetet: Nærproduksjon av video.

I uke 3 for eksempel skal en lære om behandling av skjema (forms). Dette er et viktig tema innen webutvikling. For å motivere og vise noen muligheter i forkant, har jeg tatt opp en liten videosnutt med mobilen, lastet rett opp på YouTube og til slutt legger ut i it´s learning. Se minst 1 minutt ut i filmen, så skjønner du opplegget:

Dermed kan studentene se videosnutten før de jobber med lærestoffet, gjør øvingen, tar tester, diskuterer i forum etc. Hensikten er å stimulere noen tanker i forkant. Hva tror du om denne typen motivasjonsvideo? Er dette noe vi bør prøve i flere fag?

Dette innlegget har 5 kommentarer. Gjerne bidra :-)

Av: Mikael Brevik, student og veileder i det nye Android-faget

Dette er del 3 av bloggserien om JOIN, og vi skal nå se på RIGHT OUTER JOIN. Del 1 handlet om INNER JOIN og NATURAL JOIN. Del 2 handlet om LEFT OUTER JOIN. Før vi går i gang må vi gjenoppfriske tabellene vi bruker i denne bloggserien:

RIGHT [OUTER] JOIN

RIGHT OUTER JOIN er i praksis veldig lik LEFT OUTER JOIN. Eneste forskjellen på disse er hvilken side vi vil favorisere. I en LEFT JOIN er det person som blir favorisert. Dersom vi derimot bruker RIGHT JOIN, på samme spørring, er det postal-tabellen som blir hovedtabellen.

Resultatet vil være en tabell over alle postkoder og tilhørende personer som er registrert. Siden vi ikke grupperer vil vi få flere resultater av samme postkode, da «tuplene» er av forskjellige kombinasjoner (forskjellige personer til samme postkode).

Eksempel på RIGHT [OUTER] JOIN

Vi vil nå hente ut alle postnummer og personer som er knyttet til disse.

Som vi ser er det mange steder som ikke har noen personer knyttet til seg og verdiene vises med NULL. Som nevnt tidligere vil det komme flere tupler med samme postnummer dersom vi har flere personer knyttet til det samme nummeret. For å illustrere dette legger vil til en person til fra Eide (6490).

Dersom vi kjører forrige spørring igjen vil vi få ut dette:

I del 4 skal vi gå gjennom FULL OUTER JOIN. Kom gjerne med tilbakemeldinger i kommentarfeltet.

Dette innlegget har 5 kommentarer. Gjerne bidra :-)

Du har mange viktige data. Backup er viktig. Tar du backup? Hvis ikke, så syng denne sangen (tekst under videoen)

(Melodi: «Yesterday», The Beatles)

Yesterday,
All those backups seemed a waste of pay.
Now my database has gone away.
Oh I believe in yesterday.

Suddenly,
There´s not half the files there used to be,
And there´s a milestone hanging over me
The system crashed so suddenly.

I pushed something wrong
What it was I could not say.
Now all my data´s gone
and I long for yesterday-ay-ay-ay.

Yesterday,
The need for back-ups seemed so far away.
I knew my data was all here to stay,
Now I believe in yesterday.

Dette innlegget har 1 kommentar. Gjerne bidra :-)

Av: Mikael Brevik, student og veileder i det nye Android-faget

Dette er del 2 av bloggserien om JOIN, og vi skal nå se på LEFT OUTER JOIN. Del 1 handlet om INNER JOIN og NATURAL JOIN, mens RIGHT OUTER JOIN, FULL OUTER JOIN og CROSS JOIN kommer senere.

Du bør lese del 1 om du ikke har gjort det tidligere. Vi gjenoppfrisker kort tabellene som er utgangspunktet vårt i denne bloggserien:

LEFT [OUTER] JOIN

Nå beveger vi oss ut på ytterforening. I motsetning til INNER JOIN vil en LEFT OUTER JOIN favorisere en side av tabellene. Det er fortsatt en såkalt «equijoin». Relatert til det eksemplet vi har brukt tidligere vil det bety at vi kan hente ut alle postkodene uavhengig av om de har personer registrert til seg eller ikke – eller motsatt; alle personer uavhengig om de har registrert postkode.

Her er OUTER et valgfritt nøkkelord i spørringen. LEFT JOIN er såvidt jeg vet det samme som LEFT OUTER JOIN.

Eksempel på LEFT [OUTER] JOIN

Nå vil vi kun hente ut en komplett liste av alle personer vi har i databasen, uavhengig om de har registrert postnummer eller ei.

Klikk for større versjon

Du ser her at tabellen person er den tabellen som står etter FROM-nøkkelordet. Dette gjør den til en venstrestilt tabell, og det er den vi favoriserer ved å bruke LEFT JOIN. Her vil vi altså i motsetning til INNER JOIN også hente ut personene uten registrert postnummer.

Følg med i neste del hvor vi går gjennom RIGHT OUTER JOIN. Kom gjerne med tilbakemeldinger i kommentarfeltet.

Dette innlegget har 5 kommentarer. Gjerne bidra :-)

Det nye faget om Android-utvikling (som egentlig heter LN350D Applikasjonsutvikling for mobile enheter) er veldig populært. Faget har 74 studenter, og er 100 % nettbasert. Vi intervjuet den ene faglæreren, høgskolelektor Tomas Holt, for å lære mer om faget og kanskje få litt innsikt i hva Android-utvikling faktisk går ut på.

Hvorfor ble dette nye Android-faget utviklet?

Vi trenger et oppdatert fag om programmering på avanserte mobiler. Vi skal jo tross alt utdanne personer med relevant kompetanse. At det er jeg og Mildrid Ljosland som faktisk lager faget er nok mer tilfeldig, og kunne like gjerne vært noen andre.

Hva er en aktivitet i Android-sammenheng?

En applikasjon består av minst en aktivitet (men kan ha flere). En aktivitet er laget for å utføre en aktivitet 🙂 Men i Android har man f.eks. en aktivitet som er laget for å ta bilder. Andre aktiviteter kan kalle denne via en intent og få returnert bilde (fra bildeaktiviteten) når brukeren er fornøyd med bildet. Dette gir en veldig løs kobling mellom aktivitetene i systemet. Man kan sende en intent fra en aktivitet som sier «vis denne web-siden» – for eksempel http://noefornuftig.com/ – og en nettleseraktivitet vil startes automatisk. Dette gir særdeles gode muligheter for gjenbruk av aktiviteter og letter utvilsomt utvikling av mer avanserte applikasjoner.

Faget har to prosjekter som skal gjøres. Hvorfor, og hva vil studentene lære gjennom prosjektet?

Når det gjelder programmering så læres dette gjennom å gjøre ting i praksis. Prosjektene er lagt opp slik at man skal få bruke det som er pensum i faget og kunne fordype seg samtidig. Hva som læres gjennom prosjektene kan nok variere (avhengig av prosjektoppgavene), men studentene skal være i stand til å lage applikasjoner som kan brukes i profesjonell sammenheng.

Hva kreves for å utvikle en Android-app?

Normalt så vil man trenge grunnleggende Java-kunnskap og helst erfaring med objektorientering. Ellers vil man vanligvis bruke Eclipse som utviklingsverktøy sammen med Android Development Tools (ADT). Sistnevnte innholder blandt annet emulator for å kjøre mobilapplikasjoner på datamaskinen. Emulator brukes normalt under utvikling av mobilapplikasjoner og så prøver man på fysiske enheter til slutt.

Hva er dine spådommer for Android fremover?

Jeg tror Android kan bli den mest dominerende plattformen for «avanserte mobile enheter». Grunnen til dette ligger i at systemet er åpent og fritt (noe ala Linux). Det gjør at ikke en aktør har samme mulighet til å diktere hvordan brukere og programmerere skal oppføre seg. Når det gjelder lukkede plattformer så er det (bestandig?) profitt som er målet, mens det ikke nødvendigvis er dette jaget som er det beste for brukerne.

Takk til Tomas for dette glimtet inn i Android-utvikling. Har du som leser dette innlegget noen erfaringer med Android-utvikling eller mobil-utvikling generelt? Hva tror du om mobil-fremtiden? Tar du kanskje faget? Hva er i så fall din motivasjon for å ta faget?

Dette innlegget har 1 kommentar. Gjerne bidra :-)

Av: Mikael Brevik, student og veileder i det nye Android-faget

Som ingeniørstudent og tidligere veileder i både «LO171D Programmering i Java» og «LC238D Datamodellering og databaser» har jeg erfart at foreninger i SQL kan være noe vanskelig å forstå seg på. I den sammenheng kompilerte jeg en lengre tekst som konkret beskriver forskjellige måter å forene tabeller på etter SQL-standarden. Artikkelen er nå delt opp i en bloggserie på 5 deler. Først en introduksjon hvor vi tar opp INNER JOIN og NATURAL JOIN, og så mer avanserte foreningstyper i henhold til denne bloggplanen:

• del 2: LEFT OUTER JOIN
• del 3: RIGHT OUTER JOIN
• del 4: FULL OUTER JOIN
• del 5: CROSS JOIN (noen kjappe ord)

Noen ord om foreninger (JOIN)

En forening, eller JOIN som det heter i SQL, er en rasjonell operator på lik linje med utvelgelse av kolonner (projeksjon) eller rader (seleksjon) som skal vises. Det er en operasjon på relasjonsdatabaser som brukes til å koble sammen to eller flere tabeller i en database – gjennom en felles kolonne. Ofte vil det være primærnøkkelen og fremmednøkkelen som blir brukt som bindeledd, men det er også mulig å forene tabeller med bruk av andre felt.

I denne bloggserien kommer jeg til å bruke en rød tråd av eksempler. Det betyr at jeg tar utgangspunkt i de samme tabellene gjennom alle innleggene. Disse tabellene ser slik ut (på rasjonell form):

   postal_no(zip, place);
   person (pid, name, surname, address, zip*);

Vi vet at understrekede attributter er primærnøkler og de som er merket med en asteriks (*) er fremmednøkler. Zip-feltet i tabellen person er valgfritt (NULL). Vi har her sammenhengen en-til-mange.

Tabellen postal_no inneholder informasjon over alle postnummer i Norge og ser slik ut:

Tabellen person inneholder forskjellige personer:

INNER JOIN

INNER JOIN er nok en av de foreningene som kommer til å bli brukt mest. Det er noe som kalles equijoin og betyr rett og slett at man henter ut informasjonen bundet sammen av to felles verdier i en kolonne/attributt

Det som gjør INNER JOIN forskjellig fra noen OUTER JOIN (som LEFT/RIGHT) er at vi henter kun ut de radene (også kalt «tupler») som har verdier i begge de kolonnene som vi forener om. Vi skal se mer på dette i eksempelet under.

I SQL vil INNER som regel være et valgfritt nøkkelord. Man kan med andre ord sløyfe det og kun skrive JOIN. Mange mener videre at det er god praksis å ha med nøkkelordet for å lettere tolke spørringene når man leser de.

Eksempel på [INNER] JOIN

Dersom vi nå vil sende ut et brev til personene vi har i databasen vår må vi hente ut en liste av personer med registrert adresse. Som vi vet er zip et NULL felt i tabellen person, så det er ikke alle personer som har registrert adresse til seg. Vi bruker INNER JOIN med seleksjon for å vise til hvilke felt som skal brukes til å knytte dataene sammen.

Klikk for større versjon

Vi kan også skrive dette på en alternativ måte.

Klikk for større versjon

Hva som vil skje dersom man ikke bruker seleksjon her vil vi få vite mer om i blogginnlegget «del 5: CROSS JOIN».

Om vi husker fra utlistingen av personer ovenfor vet vi at det er 3 innlegg i denne tabellen, mens her er det 2. Vi får ikke listet ut alle poststedene som ikke er bebodd av noen medlemmer i person-tabellen vår, og vi får heller ikke listet ut personer som ikke har noe poststed registrert. Merk videre at vi får skrevet ut kolonnen zip to ganger. Dette er en gang for postal_no og en gang for person.

NATURAL JOIN

NATURAL JOIN er i all basis det samme som en INNER JOIN. Eneste forskjellen er at vi fjerner duplikatkolonner. Som påpekt i slutten av forrige avsnitt vil vi få frem zip-kolonnen to ganger med bruk av INNER JOIN (uten projeksjon). NATURAL JOIN vil skrive ut kun en kolonne for alle par av kolonner med samme navn.

Eksempel på NATURAL JOIN

Klikk for større versjon

Vi ser her at ZIP kommer kun ut som en kolonne. Desverre støtter ikke JavaDB NATURAL JOIN. Så da må man supplementere med en projeksjon:

Klikk for større versjon

Se bort i fra USING() her. Den er brukt for å korte ned SQL-spørringen. USING() kan bli brukt siden begge attributtene har samme navn i disse tabellene. Så det blir en slags snarvei for ON field = field2

Følg med på neste del når vi tar for oss LEFT OUTER JOIN. Bruker du SQL i praksis? Hva synes du om foreninger? Kom gjerne med tilbakemeldinger i kommentarfeltet.

Dette innlegget har 5 kommentarer. Gjerne bidra :-)