Klassische Fehler bei der Medienausstattung von Schulen

1. Fixie­rung auf End­ge­rä­te vor der Schaf­fung von Infrastruktur

Rech­ner, Note­books, inter­ak­ti­ve Tafel­sys­te­me und Tablets sehen schick aus, sind im wahrs­ten Sin­ne des Wor­tes „begreifbar“ und zudem reprä­sen­ta­tiv nach außen. Kei­nes die­ser Gerä­te lässt sich mitt­ler­wei­le sinn­voll nut­zen ohne ein sta­bi­les Netz­werk und eine ver­nünf­ti­ge Anbin­dung des­sel­ben an das Internet.

Ohne­hin statt­fin­den­de bau­li­che Maß­nah­men an Schu­len wer­den oft nicht hin­rei­chend dazu genutzt, Infra­struk­tur gezielt auf­zu­bau­en (Ver­le­gung von Netz­werk­ka­beln in neu erstell­ten Decken, Umbau der Elek­trik oder Hei­zungs- sowie Sani­tär­in­stal­la­tio­nen etc.)

2. Mobi­le Lösun­gen für Präsentationen

Medi­en­wa­gen mit Bea­mer, Note­book und Laut­spre­chern sind fle­xi­bel ein­setz­bar. Prüft man die Betriebs­zei­ten von Bea­mer­lam­pen auf die­sen Wagen, stellt sich oft Ernüch­te­rung ein: Aus ver­schie­de­nen Grün­den wer­den die­se recht teu­ren Gerä­te wesent­lich weni­ger genutzt als fest instal­lier­te Sys­te­me z.B. Decken­bea­mer mit fest instal­lier­ten Rechner.

3. Räum­lich unsin­ni­ge Instal­la­tio­nen von Prä­sen­ta­ti­ons­sys­te­men im Klassenraum

Das End­ge­rät, wel­ches den Bea­mer oder die inter­ak­ti­ve Tafel steu­ert, muss ent­we­der so aus­ge­rich­tet sein, das die Lehr­kraft bei der Bedie­nung zur Lehr­grup­pe hin­schaut oder es muss eine mobi­le Prä­sen­ta­ti­on vom Platz des Schü­lers / Leh­rers aus mög­lich sein.

4. Tech­ni­sche Über­di­men­sio­nie­rung von PC-Arbeitsplätzen

Im klas­si­schen PC-Raum wer­den i.d.R. Office- oder Inter­net­an­wen­dun­gen genutzt. Dafür sind PC-Sys­te­me wie sie in Fir­men zum Ein­satz kom­men schlicht über­di­men­so­niert und ver­brau­chen dar­über­hin­aus unnö­tig viel Energie.

Für die Medi­en­pro­duk­ti­on – z.B. Film­schnitt – sind die­se Gerä­te dann wie­der viel zu leistungsschwach.

Ein PC-Arbeits­platz muss in sich der Aus­stat­tung an der tat­säch­lich zu erwar­ten­den Nut­zung orientieren.

5. Ver­zicht auf Soft­ware­de­ploy­ment­lö­sun­gen (zuguns­ten von z.B. Wächterkarten)

Jedes Sys­tem, wel­ches bei der Instal­la­ti­on einer Anwen­dung vor­aus­setzt, dass sich ein Ser­vice­tech­ni­ker vor jeden ein­zel­nen PC für die not­wen­di­gen Arbei­ten setzt, ist nicht mehr zeit­ge­mäß. Soft­ware lässt sich heut­zu­ta­ge ser­ver­ge­steu­ert ver­tei­len. Selbst die Betriebs­sys­tem­in­stal­la­ti­on läuft voll­au­to­ma­tisch ab. Der Schutz des jewei­li­gen Arbeits­plat­zes vor Mani­pu­la­tio­nen durch SuS kann z.B. ver­läss­lich durch ent­spre­chen­de Pro­fil­ein­stel­lun­gen erfolgen.

6. Feh­len­de Skalierungsplanung

Es ist eine Sache, in einem Klas­sen­raum mit Funk­über­tra­gungs­pro­to­kol­len wie Air­Play, Mira­Cast etc. und mit z.B. einem Klas­sen­satz Tablets zu arbei­ten. Es ist eine ande­re Sache, das mit einer gan­zen Schu­le in allen Räu­men zu tun. Die dazu nöti­gen Netz­werk­kom­po­nen­ten und deren Kon­fi­gu­ra­ti­on ste­hen in einem dia­me­tra­len Gegen­satz zu den ver­meint­lich tech­nisch tri­via­len Erleb­nis­sen, wie sie ins­be­son­de­re die App­le­welt ver­mit­telt.  Die Aus­stat­tung muss unter der Annah­me beschafft und kon­zi­piert wer­den, dass das irgend­wann „jeder an der Schul­er“ macht.

7. Feh­len­des Fort­bil­dungs­kon­zept für die Lehrkräfte

Im Ide­al­fall wer­den die vom Schul­trä­ger beschaff­ten Gerä­te oft und gern benutzt. Nur ein kom­pe­ten­ter, lern­be­rei­ter Anwen­der ist dazu in der Lage und nutzt die Mög­lich­kei­ten die­ser teu­ren und meist war­tungs­auf­wän­di­gen Investition.

Schu­len mit einem durch­dach­ten IT-Fort­bil­dungs- und Medi­en­kon­zept sind bei der Aus­stat­tung vor­ran­gig zu behandeln.

Ein schul­über­grei­fen­des Fort­bil­dungs­kon­zept wird durch eine ein­heit­li­che Aus­stat­tung erheb­lich vereinfacht.

8. „Schmoren im eige­nen Saft“

Es gibt in der unmit­tel­ba­ren Regi­on vie­le Schu­len, die mit neu­en Medi­en und Schul­ser­ver­lö­sun­gen aus­ge­stat­tet sind. Die­se ver­fü­gen über kon­kre­te Erfah­rungs­wer­te aus metho­disch-didak­ti­schen Kontexten.

Die Besich­ti­gung ande­rer Schu­len und das Gespräch mit den dort unter­rich­ten­den Lehr­kräf­ten sind wich­tig, um als Schu­le oder Schul­trä­ger eine dif­fe­ren­zier­te Mei­nung zu erhal­ten und die­se gegen­über Fir­men ver­tre­ten bzw. über­haupt ver­ba­li­sie­ren zu können.

 

AirPlay stinkt

Aus einem Forum us-amer­ka­ni­scher Uni­ver­si­täts­ad­mi­nis­tra­to­ren zu Bon­jour (Grund­la­ge von Air­Play) und Mul­ti­cast­pro­to­kol­len im All­ge­mei­nen. In den Ver­ei­nig­ten Staa­ten gibt es schon meh­re­re Jah­re Erfah­run­gen mit App­le­pro­duk­ten in gro­ßen Net­zen, Deutsch­land steht da noch am Anfang:

  • Broad­cast traf­fic and per­for­mance are mor­tal enemies.  Sup­port­ing a few users who want to do iPad mir­ro­ring, for exam­p­le could end up pena­li­zing pro­duc­ti­vi­ty for a lar­ge num­ber of users who do not participate.
  • Will need to sup­port a sin­gle sub­net span­ning your enti­re infra­struc­tu­re, for both wired and wire­less devices.
  • No trou­ble­shoo­ting mecha­nism or tools to help deter­mi­ne con­nec­ti­vi­ty issues.
  • No cen­tra­li­zed moni­to­ring, manage­ment of such devices like num­ber of devices online, num­ber of devices con­nec­ted, qua­li­ty of ser­vice pro­vi­ded, etc.
  • No cen­tra­li­zed admis­si­on con­trol for tho­se devices – If you wan­ted to only allow cer­tain peo­p­le to be able to connect/disconnect, you could not do that
  • Litt­le Secu­ri­ty – Any device on the same sub­net can enu­me­ra­te all devices.  Anyo­ne with phy­si­cal access to a device can easi­ly pair and con­trol the device fair­ly quickly.
  • As the num­ber of Air­play-com­pa­ti­ble devices increa­ses on the net­work, it will be more and more dif­fi­cult for users to find and con­nect to their own devices, as the list gets lon­ger.  It will be only a mat­ter of time whe­re a naming con­ven­ti­on for iDe­vices will have to be mana­ged for tho­se users, and it pro­ba­b­ly would be assi­gned to an fte in IT to do so.
  • If a user deci­des to con­su­me an inor­di­na­te amount of band­width using an appli­ca­ti­on such as video, the­re is no easy way to imme­dia­te­ly iden­ti­fy that user and con­strict it on the fly.

http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/Pro-and-Con-of-AirPlay/td‑p/21936

http://www.networkcomputing.com/wireless/academia-to-apple-fix-your-airplay-wirel/240003500

https://discussions.apple.com/thread/3538172?start=0&tstart=0

Etwas aus­ho­len

Zunächst ein­mal der Ver­such zu erklä­ren, was das Pro­blem an Mul­ti­cast­pro­to­kol­len wie Air­Play (und übri­gens auch DLNA) ist. Man kann sich ein Netz­werk ver­ein­facht als Post­kar­ten­ver­tei­lungs­sys­tem vor­stel­len (Netz­werk­tech­ni­ker ver­zei­hen das etwas kran­ke Bild).

uni_multicastBei Uni­cast tau­schen Sen­der und Emp­fän­ger mit­ein­an­der Post­kar­ten aus. Der Switch erkennt an Auf­kle­bern auf den Post­kar­ten, wo er sie hin­schi­cken muss. Jede Post­kar­te kommt genau dahin, wo sie einen Sinn hat.

Bei Mul­ti­cast klebt ein Sen­der fol­gen­den Auf­kle­ber auf die Post­kar­ten: „An alle Haus­hal­te mit Tages­post“. Für Tages­post muss sich jeder Emp­fän­ger expli­zit anmel­den und bekommt dann alle Post­kar­ten mit die­sem Auf­kle­ber – ob sie etwas nüt­zen oder nicht. Zudem schi­cken alle Mul­ti­cast­emp­fän­ger phro­phy­lak­tisch immer wie­der die gene­rel­le Nach­richt ind Netz­werk, dass sie ger­ne Tages­post hät­ten. Die­se Tages­port­struk­tur baut sich in gro­ßen Net­zen erst nach und nach auf. Der Switch kopiert die Tages­post­post­kar­ten für jeden Emp­fän­ger, der signa­li­siert, dass er sie ger­ne hät­te und schickt sie auch dahin.

Was bei zwei Emp­fän­gern noch pri­ma klappt, kann bei vie­len Emp­fän­gern zum Pro­blem wer­den, da ein Groß­teil der Kapa­zi­tät des Net­zes hin­ter einem Switch dann irgend­wann durch Tages­post ver­stopft ist – wie der hei­mi­sche Brief­kas­ten zu Hau­se. Außer­dem klagt der Brief­trä­ger zwi­schen dem Sen­der und dem Switch bald über Rücken­schmer­zen und macht sei­ne Arbeit nur noch, so gut es eben geht – zudem haben hat für ihn Tages­post nicht unbe­dingt Vor­rang vor „rich­ti­ger“ Post und er fängt an, Tages­post in die Bota­nik zu werfen.

Typi­sche Pro­ble­me mit AirPlay

Daher gibt es mit Air­Play in gro­ßen Net­zen sehr typi­sche Pro­ble­me (mit DLNA eher weni­ger, aber das ist eine ande­re Geschichte):

  1. Die Gerä­te fin­den sich anfangs nicht (die Mul­ti­cast­struk­tur ist von den Swit­chen noch nicht aufgebaut)
  2. Die Wie­der­ga­be stockt (das gesam­te von Mul­ti­cast betrof­fe­ne Netz­seg­ment ist über­las­tet von Tagespost)
  3. Die Gerä­te fin­den sich nach einer Wei­le nicht mehr (der Brief­trä­ger wirft aus Ver­zweif­lung Tages­post in die Botanik)

Nichts davon ist durch den Nut­zer oder dem Admi­nis­tra­tor in irgend­ei­ner Form beein­fluss­bar! Damit erkauft man sich die Bequem­lich­keit von AirPlay.

Und jetzt die Über­set­zung der obi­gen Forenauszuges:

  • Tages­post und Per­for­mance sind töd­li­che Fein­de.  Wenn man weni­gen iPad-Usern die Mög­lich­keit gibt, ihre Anzei­gen zu spie­geln, sind davon vie­le Unbe­tei­lig­te im glei­chen Netz­seg­ment betroffen.

  • Man muss die Netz­seg­men­te, die für Mul­ti­cast genutzt wer­den sol­len, mög­lichst klein hal­ten, sowohl für WLAN- als auch für LAN-betrie­be­ne Geräte

  • Es gibt kei­ne Tools, um Ver­bin­dungs­pro­ble­me zwi­schen Gerä­ten einzugrenzen

  • Man kann Tages­post nicht zen­tral über­wa­chen, um hin­sicht­lich von z.B. Per­for­man­ce­pro­ble­men zu optimieren

  • Man kann den Zugriff auf Tages­post nicht nut­zer- oder rech­te­be­zo­gen steuern

  • Es gibt kei­ne Sicher­heits­me­cha­nis­men. Das letz­te Gerät gewinnt immer.

  • Je mehr Gerä­te sich im glei­chen Netz­werk befin­den, des­to län­ger wird die Lis­te für die mög­li­chen Anzei­ge­ge­rä­te. Ori­en­tie­ren­de Namens­kon­ven­tio­nen sind für Pri­vat­ge­rä­te nicht sinn­voll durchsetzbar.

  • Wenn ein Benut­zer viel Band­brei­te für sich bean­sprucht, gibt es kei­nen Weg, das Pro­blem näher zu lokalisieren.

 

Also bei mir in der Klas­se klappt das doch wunderbar!

Ja! Es klappt auch im Wohn­zim­mer zu Hau­se. Die meis­ten Lehr­kräf­te span­nen für die Arbeit mit Air­Play ein eige­nes Netz im Klas­sen­raum auf, z.B. durch einen Air­Port-Extre­me (jeder ande­re Dual­band­rou­ter wür­de es übri­gens auch tun).  Rou­ter trans­por­tie­ren im Gegen­satz zu Swit­chen kei­ne Tages­post in ein ande­res Netz.

Ziel soll­te aber doch sein, dass das nicht die Lehr­kraft, son­dern ein Tech­no­lo­gie­part­ner tut. Vie­le Sub­net­ze sind wie­der­um war­tungs­auf­wän­dig und ste­hen dem Anspruch einer kos­ten­güns­ti­gen, zen­tra­len War­tung dia­me­tral entgegen.

Wenn ich die Auf­ga­be bekä­me, für eine gan­ze Schu­le oder auch nur einen Gebäu­de­teil, Air­Play zer­ver­läs­sig zu garan­tie­ren, müss­te ich sehr teu­re Gerä­te und viel War­tungs­auf­wand pro­jek­tie­ren. Denn es wird auch in klei­nen Net­zen immer mal wie­der spon­tan „nicht gehen“ – das ist band­brei­ten­ab­hän­gig. Da es kei­ne Feh­ler­dia­gno­se­mög­lich­keit gibt, ist Feh­ler­be­he­bung nur wie zu guten, alten Win­dows­zei­ten nur per Pass&Fail möglich.

Bes­ser wäre aus Admi­nis­tra­to­ren­sicht eine Wei­ter­ent­wick­lung des Air­Play­pro­to­kolls, sodass es auch für Enter­pri­se­umge­bun­gen taugt. Ich als Admin­sis­tra­tor bekom­me näm­lich jetzt im Feh­ler­fall die Anfor­de­rung „Geht nicht (ist ja dein blö­des Netz, vorher/zu Hau­se ging’s ja immer!), mach’s heil, Maik!“ Ich habe bei Mul­ti­cast jedoch kein Ana­ly­se­instru­ment zur Ver­fü­gung, kann also höchs­tens Ste­cker rein- und raus­zie­hen und wür­de am liebs­ten ant­wor­ten: „Kann ich nicht, selbst wenn ich es woll­te, weil du ein däm­li­ches, ver­schwen­de­ri­sches Wohn­zim­mer­pro­to­koll ver­wen­dest, Air­Play stinkt eben!“

AirPlay, DLNA, Miracast in schulischen Netzwerken

Mit Air­Play, DLNA oder neu­er­dings auch Mira­Cast las­sen sich Bild­schirm­in­hal­te digi­ta­ler End­ge­rä­te kabel­los an ein Wie­der­ga­be­ge­rät sen­den. In der Schu­le wird das im Ide­al­fall ein Bea­mer sein.

Für Bea­mer gibt es net­te Zusatz­ge­rä­te mit HDMI-Ausgang:

  • Mira­cast-Adap­ter (muss nicht auf­wän­dig kon­fi­gu­riert werden)
  • Minix-TV-Boxen (besit­zen Android, bedür­fen daher etwas Auf­merk­sam­keit, sind aber sehr fle­xi­bel durch das gro­ße App-Ange­bot und las­sen sich auch mit z.B. Mera­ki zen­tral managen)
  • jeder güns­ti­ge HDMI-Stick mit Android
  • App­leTV

Die Pro­to­kol­le zum Spie­geln des End­ge­rä­te­bild­schirms haben alle einen Schön­heits­feh­ler, der in gro­ßen Net­zen mit meh­re­ren Gerä­ten ein Pro­blem wer­den kann: Sie sind für den Heim­be­reich ent­wi­ckelt und wen­den sich daher an tech­nisch nicht ver­sier­te Anwender.

Die Fol­gen:

  • alle Gerä­te im glei­chen Netz­werk sind für alle End­ge­rä­te als Wie­der­ga­be­ge­rät sichtbar
  • das letz­te Gerät gewinnt immer

Ich kann Herrn Mei­er in Raum XY mei­nen Bild­schirm­in­halt „bea­men“, wenn Herr Mei­er dort gera­de arbei­tet. Ich muss nur das von Herrn Mei­er benutz­te End­ge­rät als Wie­der­ga­be­ge­rät aus­wäh­len – es braucht dafür kei­ne Bös­wil­lig­keit, son­dern ledig­lich einen klei­nen Ver­tou­ch­er oder Vertipper.

Ein­zi­ge löb­li­che Aus­nah­me ist App­leTV – hier lässt sich zumin­dest ein Pass­wort für die Benut­zung ver­ge­ben – in der Schu­le bringt die­ses Fea­ture jedoch kei­ner­lei Vor­tei­le – schließ­lich muss das Pass­wort ja allen bekannt sein, die Inhalt strea­men wol­len. Für jedes Gerät ein eige­nes Pass­wort zu ver­wen­den, dürf­te kaum prak­ti­ka­bel sein.

Aus­weg:

Ich span­ne in den „betrof­fe­nen“ Klas­sen eige­ne WLAN-Net­ze mit eige­nem IP-Bereich auf. Mit geeig­ne­ter Firm­ware lässt sich die Sen­de­leis­tung so weit her­un­ter­re­geln, dass Raum­gren­zen nur mit Mühe über­sprun­gen wer­den. Schu­len rate ich zur Anschaf­fung von Acces­s­points bzw. WLAN-Rou­tern, die sowohl rou­ten als auch bridgen kön­nen – idea­ler­wei­se bei­des gleich­zei­tig mit ver­schie­de­nen SSIDs (z.B. Bea­mer & Inter­net). Das HDMI-Zusatz­ge­rät hängt dann mit im gerou­te­ten Netz­werk. Das klappt recht zuver­läs­sig und eben nicht über Raum­gren­zen hinweg.

Bei den HDMI-Zusatz­ge­rä­ten emp­feh­le ich zur­zeit die Andro­iden in Ver­bin­dung mit Mera­ki, wenn es meh­re­re Gerä­te sein sol­len. So lässt sich das Gan­ze zen­tral per Web­ober­flä­che ver­wal­ten und die gan­ze App-Welt des Play­s­to­re steht auf dem Bea­mer zur Ver­fü­gung – für vie­les braucht man dann zudem kei­nen Rech­ner mehr :o)…

 

 

Owncloud an bestehende Authentifizierungsysteme anbinden

Own­cloud bie­tet ab der Ver­si­on 6 neben den übli­chen inter­es­san­ten Fea­tures eine kol­la­bo­ra­ti­ve Text­ver­ar­bei­tung an, d.h. meh­re­re Benut­zer kön­nen genau wie bei Ether­pad oder Ether­pad lite gleich­zei­tig an einem Doku­ment arbei­ten. Die For­ma­tie­rungs­mög­lich­kei­ten sind dabei umfang­rei­cher als bei der Ether­pad­de­ri­va­ten, jedoch gegen­über Lösun­gen wir Goo­g­le­Docs noch recht rudi­men­tär. Für vie­le Anwen­dungs­fäl­le reicht es jedoch voll­auf. Wer möch­te, darf das hier nach Ein­ga­be eines Spitz­na­mens ger­ne ein­mal aus­pro­bie­ren. Own­cloud nutzt ODT als nati­ves Format.

Vie­le Schu­len möch­ten ger­ne Own­cloud nut­zen und ver­fü­gen oft schon über eine Schul­ser­ver­lö­sung. Idea­ler­wei­se bie­tet die­se bereits E‑Mailadressen für alle Schul­an­ge­hö­ri­gen über das IMAP-Pro­to­koll an. Das ist z.B. bei IServ der Fall – einer in Nie­der­sach­sen sehr ver­brei­te­ten Lösung. Durch zwei klei­ne Ände­run­gen muss kei­ne sepa­ra­te Nut­zer­ver­wal­tung in Own­cloud mehr betrie­ben wer­den, wenn bereits ein IMAP-Ser­ver im Schul­netz vor­han­den ist.

Es kann eine Grund­in­stal­la­ti­on von Own­cloud als Basis genom­men wer­den. Bei den Apps muss „Exter­nal user sup­port“ zuvor akti­viert wer­den. Eine Datei ist danach zu ändern, eine hinzuzufügen.

Zu ändern­de Datei

Name: config/config.php

Quell­code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<?php
require_once(dirname(__FILE__).'/../apps/user_external/lib/imap_new.php');
 
$CONFIG = array (
  'instanceid' => '<hier_steht_schon_etwas>',
  'passwordsalt' => '<hier_steht_schon_etwas>',
  'datadirectory' => '<hier_steht_schon_etwas>',
  'dbtype' => 'mysql',
  'version' => '6.0.0.14',
  'dbname' => '<hier_steht_schon_etwas>',
  'dbhost' => 'localhost',
  'dbtableprefix' => 'oc_',
  'dbuser' => '<hier_steht_schon_etwas>',
  'dbpassword' => '<hier_steht_schon_etwas>',
  'installed' => true,
  'forcessl' => true,
  'user_backends'=>array(
   array(
      'class'=>'OC_User_IMAP',
      'arguments'=>array('{<server>:<port>/imap/ssl/novalidate-cert}')
   )
  ),
);

Kom­men­tar:
In Zei­le 2 wird der neu zu erstel­len­de Code (s.u.) ein­ge­bun­den, ab Zei­le 17 wird es inter­es­sant, vor allem in der Zei­le, die mit „argu­ments“ beginnt. Die Anga­ben für Ser­ver und Port sind mit den eige­nen Anga­ben zu fül­len. Ich brau­che für den IServ die Anga­be „nova­li­da­te-cert“, da es sich um ein selbst­si­gnier­tes Cert han­delt – daher zicken auch Apple­ge­rä­te ger­ne mit dem IServ, weil sie sich in der Feh­ler­mel­dung nicht klar aus­drü­cken. Nutzt man eine unver­schlüs­sel­te Ver­bin­dung, was allen­falls zu Test­zwe­cken dien­lich ist, sieht das z.B. so aus:

      'arguments'=>array('{meinserver.xy:143/imap}')

Hin­zu­zu­fü­gen­de Datei:

Name: apps/user_external/lib/imap_new.php

Quell­code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
<?php
/**
 * Copyright (c) 2012 Robin Appelman <icewind@owncloud.com>
 * This file is licensed under the Affero General Public License version 3 or
 * later.
 * See the COPYING-README file.
 */
 
class OC_User_IMAP extends OC_User_Backend{
        private $mailbox;
 
        public function __construct($mailbox) {
                $this->mailbox=$mailbox;
        }
 
        /**
         * @brief Check if the password is correct
         * @param $uid The username
         * @param $password The password
         * @returns true/false
         *
         * Check if the password is correct without logging in the user
         */
        public function checkPassword($uid, $password) {
 
                $mbox = @imap_open($this->mailbox, $uid, $password);
                imap_errors();
                imap_alerts();
 
 
                if($mbox) {
                        imap_close($mbox);
 
                        if(OC_User::userExists($uid)) {
                                  OC_User::setPassword($uid, $password);
                        } else {
                                  OC_User::createUser($uid, $password);
                                  $uida=explode('@',$uid,2);
                                  if(($uida[1] || '') !== '') {
                                        OC_Group::createGroup($uida[1]);
                                        OC_Group::addToGroup($uid, $uida[1]);
                       }
 
                }
                        return $uid;
                } else {
                        return false;
                }
        }
 
}

Kommentar: 
Die­ses Code­stück sorgt dafür, dass beim ers­ten Log­in eines Benut­zers ein Ein­trag in die User-Daten­bank von Own­cloud erfolgt. Dabei wird auch das Pass­wort ver­schlüs­selt gespei­chert, da ansons­ten kei­ne Nut­zung über die Apps von Own­cloud mög­lich ist. Der Nut­zer muss sich mit den glei­chen Daten wie am E‑Mailserver anmel­den. Ändert der Nut­zer sein Pass­wort im IServ oder auf dem E‑Mailserver, wird die­se Ände­rung bei bestehen­dem Log­in in Own­cloud übernommen. 

Update:
Mit dem Hack funk­tio­niert auch die Nut­zung mit der Own­cloud-App problemlos.

Wir sind die Roboter

Die Dämp­fe von Löt­zinn bren­nen einer kon­zen­triert über den Löt­kol­ben gebeug­ten Schü­le­rin in den Augen, der Geruch von Röst­zwie­beln liegt in der Luft, über­all lie­gen elek­tro­ni­sche und mecha­ni­sche Bau­tei­le her­um. Selt­sa­me Gefähr­te, die an die­je­ni­gen aus der Mad-Max-Trio­lo­gie anzu­knüp­fen schei­nen, fah­ren über den Flur und dre­hen wie von Geis­ter­hand vor Wän­den und Hin­der­nis­sen um. Rechts wird geflucht über die unver­meid­li­chen Trei­ber­pro­ble­me unter Windows8, links lacht sich dar­über der Nut­zer eines Ubun­tu-Desk­tops ins Fäust­chen, wäh­rend die Grup­pe im hin­te­ren Bereich das Schei­tern des letz­ten Algo­rith­mus bei einem kräf­ti­gen Biss in das selbst­ge­bau­te Hot­dog und einer Par­tie Mine­craft verarbeitet.

Die Situa­ti­on ent­stammt nicht dem Ent­wick­lungs­la­bor einer nerdi­gen Elek­tronik­fir­ma, son­dern beschreibt die Atmo­sphä­re in unse­rer neu­en Ardui­no-AG auf dem letz­ten Regio­nal­grup­pen­tref­fen recht genau. Da kann nach nicht ein­mal acht Wochen dann schon sowas herauskommen:

Die Hard­ware habe ich nach einem Schü­ler­ent­wurf nach­ge­baut. Die hier zu sehen­den Komponenten

  • ein Ardui­no UNO-Nachbau
  • ein Adafruit-Motor­s­hield-Nach­bau
  • ein HC-SR04 Ultraschallsensor
  • ein 4WD-Chas­sis
  • sechs Mignon-Akkus
  • ein Bat­te­rie­fach
  • Kabel und ande­rer Kleinkram

kos­ten etwa 50,- Euro, wenn man etwas war­ten kann. Die not­wen­di­ge Soft­ware gibt es kos­ten­los zum Down­load. Pro­gram­miert wird in einem C‑ähnlichen Dia­lekt. Der Robo­ter aus dem Video wird von die­sem Pro­gramm gesteuert: 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
    #include <AFMotor.h>
 
    AF_DCMotor motor_01(1, MOTOR12_64KHZ);
    AF_DCMotor motor_02(2, MOTOR12_64KHZ);
    AF_DCMotor motor_03(3, MOTOR12_64KHZ);
    AF_DCMotor motor_04(4, MOTOR12_64KHZ);
 
    // HC-SR04
    // VCC auf 5V
    // Trig auf Trigger Pin (löst Ultraschallimpuls aus)
    // Echo auf Echo Pin (Zeit in ms bis zum Empfang des Echos)
    // GND auf GND
 
    #define echoPin 15 // Echo Pin
    #define trigPin 14 // Trigger Pin
    int turn = 1;      // Drehrichtungsänderung wenn "festgefahren"
    int count = 0;     // Anzahl der Drehausweichversuche pro Richtung
 
    long duration, distance; // Dauer um Abstand zu berechnen
 
    void setup() {
 
     motor_01.setSpeed(190);  // Wir fahren nicht volle Pulle
     motor_02.setSpeed(190);
     motor_03.setSpeed(190);
     motor_04.setSpeed(190);
 
     Serial.begin (9600);
     pinMode(trigPin, OUTPUT);
     pinMode(echoPin, INPUT);
 
    }
 
    void loop() {
 
 
     /* The following trigPin/echoPin cycle is used to determine the
     distance of the nearest object by bouncing soundwaves off of it. */ 
 
     digitalWrite(trigPin, LOW); 
     delayMicroseconds(2); 
 
     digitalWrite(trigPin, HIGH);
     delayMicroseconds(10); 
 
     digitalWrite(trigPin, LOW);
     duration = pulseIn(echoPin, HIGH);
 
     //Calculate the distance (in cm) based on the speed of sound.
     distance = duration/58.2;
 
     //Delay 50ms before next reading.
     delay(50);
 
     if (distance < 25 && turn > 0 )
 
     {
 
       motor_01.run(FORWARD);   // Motor 1 vorwärts laufen lassen
       motor_02.run(FORWARD);
       motor_03.run(FORWARD);
       motor_04.run(FORWARD); 
 
       delay(200);
 
       motor_01.run(BACKWARD);
       motor_02.run(BACKWARD);  // Motor 2 rückwärts laufen lassen
       motor_03.run(FORWARD);
       motor_04.run(FORWARD);
 
       delay(200);
 
       count++;
 
       if (count >= 3 ) {   
 
         turn = -turn;
 
       }
 
     } 
 
     else if (distance < 25 && turn < 0 )
 
     {
 
       motor_01.run(FORWARD);   // Vorwärts fahren
       motor_02.run(FORWARD);
       motor_03.run(FORWARD);
       motor_04.run(FORWARD); 
 
       delay(200);
 
       motor_01.run(FORWARD);
       motor_02.run(FORWARD);  // Motor 2 rückwärts laufen lassen
       motor_03.run(BACKWARD);
       motor_04.run(BACKWARD);
 
       delay(200);
 
          count++;
 
       if (count >= 3 ) {   
 
         turn = -turn;
 
       }
 
     }
 
     else
 
     {
       motor_01.run(BACKWARD);   // Motor 1 vorwärts laufen lassen
       motor_02.run(BACKWARD);
       motor_03.run(BACKWARD);
       motor_04.run(BACKWARD); 
 
       count = 0;
 
     }
 
    }

Beim Expe­ri­men­tie­ren mit der Ardui­no­platt­form gibt es ganz vie­le ver­schie­de­ne Herausforderungen: 

  • Es muss zumin­dest in Grund­zü­gen pro­gram­miert werden
  • Die­se Pro­gram­me bedür­fen einer stän­di­gen Optimierung
  • Ver­drah­tet“ man mit Löt­kol­ben und Schrau­bern­dre­her oder gleich im Pro­gramm selbst? – Im obe­ren Pro­gramm sind z.B. „falsch“ ange­schlos­se­ne Moto­ren durch ent­spre­chen­de Code­än­de­run­gen kom­pen­siert worden.
  • Wie struk­tu­riert man sein Pro­gramm so, dass man es die Woche dar­auf noch ver­steht? – Mor­gen wer­den wir uns mit Unter­pro­gram­men und der Para­me­ter­über­ga­be beschäftigen.
  • Wie arbei­ten die Sen­so­ren eigent­lich? (Der HC-SR04 muss z.B. so aus­ge­rich­tet wer­den, dass er nicht schon Uneben­hei­ten auf dem Boden als Hin­der­nis erfasst, mit meh­re­ren Sen­so­ren erhö­he ich die Mess­ge­nau­ig­keit usw.)
  • Wie löse ich die vie­len mecha­ni­schen Probleme?
  • Die meis­ten Pro­gram­mier­bei­spie­le im Netz sind auf Englisch …

Ich fin­de es pri­ma, dass Infor­ma­tik hier erfahr­bar wird und dass nicht nur vir­tu­ell ver­mit­tel­te Erfah­run­gen und Lern­an­läs­se vor­han­den sind. Grund­struk­tu­ren zum Pro­gram­mie­ren geben wir in der AG vor, da rei­nes Aus­pro­bie­ren schnell zu Frus­t­er­leb­nis­sen führt, ins­be­son­de­re wenn meh­re­re Akto­ren und Sen­so­ren dazukommen.
Die Schü­le­rin­nen und Schü­ler doku­men­tie­ren das im in einem Doku­Wi­ki, was sie über Akto­ren und Sen­so­ren her­aus­fin­den oder stel­len auch ganz Code­schnip­sel ein. Neben­bei ler­nen sie etwas über Syntax.

1 5 6 7 8 9 23