Informatik: Im Wechselbad der Gefühle

Das MINTLOOK-Projekt wird an der Technischen Hochschule Brandenburg angeboten und ist ein duales Probestudium. Jungs und Mädchen haben die Möglichkeit innerhalb von 9 Monaten drei Praktika in den Fachrichtungen Mathematik, Informatik, Naturwissenschaft und Technik zu besuchen. Darüber hinaus können sie an den Veranstaltungen der TH Brandenburg in den MINT Fachbereichen teilnehmen.

IBMClientInnovationCenter_Mintlook3Wir, Niklas und Natalie, konnten ab Dezember drei Mal pro Woche einen Einblick in die Softwareentwicklung im IBM Client Innovation Center gewinnen. Die anderen zwei Tage besuchten wir Vorlesungen an der TH-Brandenburg.

Wie wurden wir auf das MINT-Projekt aufmerksam?

Da wir uns nach dem Abitur noch unsicher waren mit unserer Studienwahl, haben wir uns nach einer Möglichkeit umgesehen verschiedene Berufsfelder und Studienrichtungen kennenzulernen. Durch die stadteigene Homepage von Brandenburg an der Havel und durch die Studien- und Ausbildungsmesse in Berlin, sind wir letztendlich auf das Projekt MINTLOOK gestoßen.

Was sind unsere Aufgaben im CIC?

Da wir beide keinen Informatikunterricht in der Schule hatten, kamen wir ohne Vorkenntnisse ins CIC. Die ersten zwei Woche bestanden darin, dass wir uns mit einigen Tutorials auf die bevorstehenden Wochen vorbereitet haben. Außerdem erhielten wir einen Überblick vom CIC und über verschiedene Projekte. Nachdem wir in den Webtechnologien, wie JavaScript, HTML und CSS, theoretisch fit waren, konnten wir mit unserem ersten eigenen Projekt durchstarten. Nun brauchten wir nur noch eine Idee. Nach einigen Tagen Brainstorming entschlossen wir uns für das Gefühlstagebuch VIBES. Über die Feiertage entwickelten wir dazu erste Designentwürfe, sodass wir mit dem Jahresstart endlich mit der Umsetzung loslegen konnten. Nach viel Spaß, aber auch Schweiß und Tränen sind wir nun stolz unser Emotionstagebuch erfolgreich umgesetzt zu haben und unseren Betreuern vorstellen zu können.IBMClientInnovationCenter_Mintlook2

Was gefällt uns besonders gut im CIC?

Sobald wir ein Problem haben, können wir hier jeden Kollegen fragen. Wir werden wie echte Mitarbeiter behandelt und können uns und unsere Ideen jederzeit einbringen.

Das Arbeitsklima ist sehr angenehm und wir fühlen uns hier wirklich willkommen. Ein weiterer Punkt ist, dass wir sehr selbstständig arbeiten und uns sehr viel Vertrauen entgegen gebracht wird, sodass wir flexible Arbeitszeiten und Homeoffice nutzen konnten.

Was nehmen wir generell aus der Erfahrung im CIC mit?

In den letzten drei Monaten, haben wir gelernt selbstbewusster durch das Leben zu gehen. Es ist besser, Fragen zu stellen anstatt ewig über ein Problem zu grübeln. Außerdem haben wir hier gelernt, dass ein gutes Arbeitsumfeld eine Menge ausmacht. Da wir freundlich empfangen und auch weiterhin super aufgenommen wurden, haben wir uns auf unsere Tage im CIC gefreut, trotz der 8-Stunden-Tage.  Vor Allem aber haben wir erkannt, dass Informatik weit mehr ist, als nur monotones Programmieren und sogar richtig Spaß macht.

Haben uns die Erfahrungen im CIC bei der Studienwahl geholfen?

Wir haben viele Einblicke in Projekte, Projektarbeit und die Softwareentwicklung gewinnen können. Das eigenständige Arbeiten ließ uns dabei in verschiedene Rollen schlüpfen, zum Beispiel Projektkoordination, Design und Entwicklung.

Niklas sieht die Programmierung später eher als Hobby. Ich, Natalie, war mir ursprünglich sicher, dass mein Weg nicht in die Informatik geht. Allerdings macht es mir inzwischen so viel Spaß, dass ich es mir für meine berufliche Zukunft vorstellen kann.

IBMClientInnovationCenter_Mintlook5

 

 

Advertisements

Scrum in der Praxis: Teil 2, das Sprintende

In unserer Rubrik Tech Talk stellen wir euch heute wieder Situationen aus dem agilen Umfeld vor. Ihr habt noch nie in der agilen Entwicklung gearbeitet? Dann folgt aufmerksam unserer Reihe „Scrum in der Praxis“.

Agile Softwareentwicklung ist der neuste Schrei. Nicht selten kommt es in der Industrie vor, dass sich Unternehmen mit dem Label „Agile Softwareentwicklung“ schmücken wollen. Gerade im Bereich Scrum wird viel Schindluder getrieben. Ob dies nun aus Unkenntnis oder Täuschung gemacht wird, möchte ich an dieser Stelle nicht bewerten.

Daher verwundert es auch nicht, dass man auf Portalen, wie http://thedailywtf.com oder https://www.reddit.com/ oder auch den zahlreichen kleinen Blogs viele negative Erfahrungsberichte zum Thema Agile Entwicklung liest. Agiles Entwickeln ist eine Idee. Scrum ist ein konkretes Rahmenwerk, dass der agilen Idee folgt und Scrum wird in diesem Beitrag auch im Zentrum stehen.

Dieser Beitrag wird exemplarisch ein Review am Ende eines Entwicklungszyklus (Sprint) beschreiben. Alle Elemente darin habe ich persönlich regelmäßig in Projekten erlebt und stufe sie als ganz normale Ereignisse im Leben eines Scrum-Teams ein. Dieses konkrete Meeting ist jedoch fiktiv.


Alex, Barbara, Carlo, Diana: Softwareentwickler
Masami: Scrum-Master
Polly: Product Owner


 

Im Büro.

Masami: Alex, kommst du, das Review fängt gleich an. Wir sind heute im Raum 2.02.

Alex: Ich habe gerade noch einen Bug gefunden, der sich bei unseren Tests versteckt hatte. Wenn ich das jetzt nicht noch schnell behebe, können wir diese Anforderung nicht abgeben.

Masami: Das ist ärgerlich. Komm jetzt aber ruhig trotzdem mit ins Meeting. Polly soll dann entscheiden, ob sie die Story annimmt oder nicht. In zwei Minuten geht es schon los.

Alex: So ein blöder Fehler! Ja, ich komme.

Im Meetingraum, zum Sprint Review.

Masami: Willkommen beim Review von Sprint 15. Die letzten zwei Wochen haben wir an einigen neuen Features und Bugfixes gearbeitet. Alex, würdest du gleich anfangen?

Alex: *nickt* Ich habe die Story NPE-1232 bearbeitet. Dafür sollten wir einen Loginbildschirm für die Applikation schreiben. Aktuell kann jeder die Applikation benutzen. In Zukunft muss man sich mit Nutzer und Passwort einloggen um den Zugriff mit der steigenden Mitarbeiterzahl besser kontrollieren zu können. Ich demonstriere das mal kurz auf dem Beamer. Leider ist uns aber noch ein Sonderfall erst kurz vor dem Review aufgefallen. Wenn im Nutzernamen oder Passwort ein Sonderzeichen ist, wird es in einer falschen Kodierung ans Backend geschickt und der Loginversuch schlägt fehl. Das kann im schlimmsten Fall zur Accountsperrung führen.

Polly: Dass wir den Login ändern, ist sehr zeitkritisch. Eigentlich wollten wir die Änderungen kommende Woche schon ausrollen. Bis zum Ende des kommenden Sprints können wir nicht warten.

Alex: Das Problem zu beheben ist kein großer Aufwand. Ich gehe davon aus, dass ich das bis zum Ende des Tages abgeschlossen habe.

Polly: Sehr gut, so lange du die Version bis Freitag auslieferst, reicht mir das.

Masami: Einen Moment, lasst uns das lieber nachher im Planning besprechen. Wenn das Team dem zustimmt, schieben wir gerne noch eine Zwischenlieferung ein. Wir sollten uns jetzt aber erst einmal auf die Stories des vergangenen Sprints konzentrieren.

Polly: Das ist in Ordnung. Da die Anforderungen nicht vollständig umgesetzt sind, nehme ich die Story nicht ab und wir schauen dann nachher beim Planning weiter.

Barbara: Dann mache ich einmal weiter. Ich habe die Story NPE-1233 bearbeitet. Da ging es darum, einen Report von allen Nutzern zu erzeugen, die aktuell Zugriff auf die Applikation haben und ein Datenbankscript anzulegen, welches all diesen Nutzern Accounts für das neue Login anlegt. Ich habe das Script auch schon an das Betriebsteam übergeben und sie waren zufrieden. Ich hatte dich bei der Mail auch in den CC gesetzt, Polly.

Polly: Ja, die Mail hatte ich gesehen. Die Story ist abgenommen.

Carlo: Dann mache ich direkt weiter. In NPE-1256 ging es darum, den Bug im Detailreiter zu beheben, dass lange Titel rechts aus dem Bildschirm rausragen und somit abgeschnitten sind. Auf dem Beamer ist gerade unsere alte Version zu sehen. Ich gehe mal zur Detailseite. Hier sieht man den abgeschnittenen Titel. Jetzt öffne ich die neue Version und gehe zur gleichen Detailseite. Hier sieht man jetzt, dass der Titel umgebrochen ist.

Polly: Hmm, aktuell ist der Titel mitten im Satz umgebrochen. Kann man das nicht so machen, dass zuerst versucht wird nur bei einem Satzende umzubrechen? Das würde es etwas lesbarer machen.

Carlo: Das war in diesem Sprint nicht Teil der Anforderungen. Das können wir aber gerne mit einer neuen Story noch umsetzen.

Polly: Gut, dann lege ich dafür einen neuen Eintrag im Ticketsystem an.

Masami: Da die Anforderungen für diese Story umgesetzt sind, nimmst du die Story ab, Polly?

Polly: Ja, ist abgenommen.

Diana: Ich stelle NPE-1244 vor. Ich hatte dir ja gestern schon geschrieben, dass wir den Aufwand leider unterschätzt hatten und daher nicht fertig geworden sind. Hier sind auch noch größere Restaufwände zu leisten.

Polly: Woran hing es denn?

Diana: Ich kann ja mal kurz den Code an die Wand werfen. Die Klasse ist unglaublich lang und allein die Methode „perform“…

Masami: Ich glaube das führt jetzt gerade etwas zu weit. Kannst du das Problem kurz zusammenfassen? Polly, falls du darüber hinaus noch mehr Details möchtest, kannst du im Nachgang noch mit den Leuten reden, die an der Story gearbeitet haben. Dann kann der Rest des Teams schon weiterarbeiten.

Diana: Die Komponente, die wir dafür anfassen mussten, ist sehr fragiler Legacy-Code. Wir haben ein paar kleine Änderungen gemacht und plötzlich ging die halbe Applikation nicht mehr. Umbaumaßnamen und Tests sind fertig aber die eigentliche Arbeit haben wir noch nicht begonnen.

Polly: Hättet ihr es nicht ohne die Umbaumaßnamen geschafft?

Carlo: Das war uns zu riskant. Ich habe auch mit draufgeguckt und der Umbau war längst überfällig.

Polly: Na gut, zumindest ist mir dieses Szenario lieber, als wenn die Probleme erst in der Produktion auftauchen.

Masami: Gut, die halbe Stunde für unser Meeting ist auch gleich rum. Falls es keine weiteren Punkt gibt, gehen wir jetzt etwas früher in die Mittagspause und treffen uns anschließend zur Retrospektive um 13:30 Uhr wieder hier.


 

Maximiere die Arbeit, die nicht getan wird, ist Teil des agilen Manifests. Das bedeutet, überflüssige Meetings und Arbeiten, die dem Projekt keinen Mehrwert bringen zu streichen. Das bedeutet auch, dass bei den notwendigen Meetings nur die Personen anwesend sind, die benötigt werden. Bei agiler Entwicklung dreht sich daher viel um die Eigenverantwortlichkeit des Teams und seiner einzelnen Mitglieder. In der Konsequenz bedeutet das, dass das ganze Team engen Kontakt zu Polly hat, die selbst zur Organisation des Kunden gehört. Spätestens alle zwei Wochen sieht Polly also live die Arbeitsergebnisse des Teams. So kann sie frühzeitig erkennen, ob der Umbruch des Titels passt oder ob in den Anforderungen, die sie geschrieben hat, noch ein Detail fehlte. Als Product Owner kann sie sich jetzt überlegen, wie hoch sie die Änderung priorisiert um den Mehrwert der Applikation zu maximieren. Von der Priorität hängt dann ab, ob die neuen Anforderungen in den kommenden zwei Wochen umgesetzt werden, oder erst in einem späteren Zyklus – oder ob sich bis dahin vielleicht zeigt, dass diese Umsetzung sich nicht lohnt.

Sie hat die Finger am Puls des Projekts und da sie selbst zum Kunden gehört, sind keine überschweifenden Reports notwendig was den Fortschritt des Teams angeht. Mit jeder abgenommenen Story ist messbar wieviel näher man dem nächsten Meilenstein gekommen ist. Scrum ist dabei jedoch keine Anarchie. Wir als Entwickler übernehmen Verantwortung für die Anforderungen, die wir einmal in einen Sprint aufgenommen haben. Wie wir diese Anforderungen konkret umsetzen, entscheiden wir dann jedoch eigenständig. Diese Freiheit weiß ich sehr zu schätzen. Die Meetings im Rahmen von Scrum sind überschaubar und Masami achtet darauf, dass der Prozess nicht ausartet und hält externe Störungen und Produktivitätskiller fern.

Wenige, kurze, sinnstiftende Meetings, viel Eigenverantwortlichkeit, häufig Feedback zur eigenen Arbeit und kontrollierte, kleine Kurskorrekturen seitens des Kunden sind es, die für mich Scrum ausmachen und mir einen angenehmen Arbeitsalltag verschaffen.

Scrum in der Praxis: Part I, der erste Sprint

In unserer Rubrik Tech Talk stellen wir euch heute und in weiteren Beiträgen eines der bekanntesten agilen Frameworks vor – Scrum. Damit wollen wir euch einen Einblick in den Projektalltag vieler unserer Kollegen geben und die unterschiedlichen Phasen dieser Entwicklung erklären. Ihr habt noch nie in der agilen Entwicklung gearbeitet? Dann folgt aufmerksam unserer Reihe „Scrum in der Praxis“.

Viele von uns waren bereits Teil von Scrum-Teams und in der agilen Entwicklung beschäftigt. Wir haben in Retrospektiven, Refinements, Plannings und im Sprint-Verlauf allgemein Sicherheit gewonnen. Trotzdem gibt es Ausnahmesituationen, die selbst im strukturierten, agilen Vorgehen Unsicherheit auslösen und wie Corner Cases eines ansonsten klaren Ablaufs wirken. Am Anfang war der Anfang und die Frage: Wie fängt man eigentlich an? Wenn nichts da ist, Boards und Diagramme noch leer? Wir kennen das Schätzen und Schneiden innerhalb unseres Backlogs, das Verfeinern. Und dank unserer Velocity haben wir eine Maßgabe wieviel wir in den nächsten Sprint einplanen. Aber wie geht man vor, wenn es keinen vorhergehenden Sprint und keine Velocity gibt? Wir reden von einem Fabelwesen, dem man nicht oft beiwohnen darf: dem ersten Sprint.

Antipattern und agiler Mythos: Sprint 0

Aber ja, es gibt sie, die ersten Sprints. Nur der Mythos vom Sprint 0 sollte besser ein Mythos bleiben. Nach Lehrbuch ist kein Sprint 0 vorgesehen, trotzdem poppt er immer mal wieder auf. Inzwischen wird der Sprint 0 sogar oftmals als Anti-Pattern bezeichnet. Unter der Annahme, dass man in einem Sprint 0 vorbereitende Aufgaben erledigt, schleichen sich meistens die ersten Verfälschungen einer Schätzung ein. Was sind solche vorbereitenden Aufgaben? Erste Meetings aufsetzen und daran teilnehmen, eine Entwicklungsumgebung einrichten? Meetings und Setups oder sonstige technische Checks sind Aufgaben, die in jedem Sprint auftreten (können) und womit man immer rechnen darf. Jeder Sprint soll Mehrwert für den Kunden erzeugen. Tut es das nicht, dann ist es kein Sprint. Daher ist es laut Lehrbuch nicht richtig von Sprint 0 zu sprechen, wenn man in diesem rein administrative und planerische Aufgaben übernimmt, bei denen kein Deliverable für deinen Kunden entsteht. Gibt es Aufgaben für das Team: dann ist es ein regulärer Sprint, eben Sprint 1. Unser Deliverable, unser Ergebnis, ist beispielsweise die funktionierende Entwicklungsumgebung, ein Teil der Dokumentation und wahrscheinlich erste kleine Tasks, die einen sichtbaren Mehrwert für den Kunden erzeugen. Wer seinen ersten Sprint aber gerne bei null anfangen möchte zu zählen, kann das tun, solange ein Deliverable entsteht. Wir Informatiker sind es ja gewöhnt bei null anzufangen zu zählen ;). Trotzdem bleiben die Unsicherheiten: wieviel gehört in so einen ersten Sprint? Die Antwort klingt fast zu einfach: das was nötig ist und das was möglich ist.

Der erste Sprint

Ohne eine Velocity oder die Erfahrung vorhergehender Sprints und was man sich zutrauen kann, muss man quasi zurück zu den Wurzeln und überlegen: was brauche ich, um zu starten und wieviel Zeit kostet mich das? Ein Beispiel: Alle Entwickler setzen beispielsweise einen Tag lang ihre Entwicklungsumgebung auf, werden x Tage eingewiesen in das Programmiermodell und -vorgehen (Know your tools, Server, wie delivern, Definition of Done, Definition of Ready und wie läuft die Code Review ab? Was sind die Programmierrichtlinien und wie sieht die Qualitätssicherung und Test aus?) und je nach Länge des Sprints: welche ersten Aufgaben können zeitlich dann noch absolviert werden? Im ersten Sprint ist es valide nicht zu viel einzuplanen, sondern erstmal tief zu stapeln. Eine Story nachzunominieren und nach Start des Sprints noch nachträglich mit einzufügen, ist zwar für „Scrum nach Lehrbuch“-Fans nicht valide, aber im ersten Sprint sicherlich verkraftbar. Wer beim ersten Schätzen unsicher ist, kann sich bei erfahreneren Entwicklern Hilfe suchen und sehr transparent schätzen. Also „laut denken“. Hilfreich kann es sein zusammenzutragen, wieviel unterschiedliche Technik dafür angefasst werden muss. Habe ich Änderungen in der Datenbank bzw. der Persistenz allgemein? Oder ist es nur Businesslogik? Muss ich nur Tests schreiben oder ein ganzes Test-Framework aufbauen (schließlich sind wir am Anfang). Falls erfahrene Entwickler nicht da sind oder die Schätzung zu unscharf wirkt, kann sogar erstmal eine ganz andere Schätzmethode mit weniger Kategorien verwendet werden wie T-Shirt-Sizes (Story-Größen S, M, L, XL). Generell gilt aber: was die Schätzgrößen bedeuten (also wie komplex beispielsweise 5 Story Points sind), bestimmt das Team. Dafür gibt es keine allgemeingültige Antwort, weswegen im ersten Sprint auch manchmal einfach das berühmte Bauchgefühl reicht. Bei so viel Unschärfe ist klar: in Sprint 1 kann man daneben liegen. Die Korrektur erfolgt mit der Erfahrung ab dem zweiten Sprint und hilft für die Zukunft.

Tipps für den zweiten Sprint

Die Story und die jeweilige Schätzung des ersten Sprints, sollte als Referenz herangezogen werden. Best Practice ist, sich eine Liste sortiert nach Story Points anzulegen, die als Referenz-Storys dienen. So bekommen alle in Zukunft ein Gefühl dafür, was beispielsweise 5 Story Points bedeuten, wie komplex sie sind und wie solche Storys ungefähr aussehen. Lag man daneben und hat länger als erwartet gebraucht, war die Aufgabe also komplexer, dann kann das bei der Erstellung der Referenz berücksichtigt und korrigiert werden.

Falls du noch mehr über den ersten Sprint erfahren möchtest, kannst du hier weiterlesen:
Official Scrum Guide (scrum.org)
Your first agile sprint: A survival guide (TechBeacon)
Scrum Myths: It is ok to have a Sprint 0, Design Sprint, Hardening Sprint… (scrum.org Blog)

 

Von Null auf IoT mit Bluemix

„Von Null auf IoT mit Bluemix.“ – So könnte man den zweiten Watson-IoT-Workshop bestens zusammenfassen. Der fünftägige Kurs fand Ende März zusammen mit Studenten aus Sachsen-Anhalt und einigen Mitarbeitern des CIC Magdeburg statt. Da der nächste Workshop schon auf der Agenda steht, werden wir an dieser Stelle ein wenig aus dem Nähkästchen plaudern, damit sich künftige Interessenten bzw. Teilnehmer ein gutes Bild vom Inhalt machen können.

Nachdem wir im Vorfeld auf den Workshop aufmerksam gemacht haben, konnten wir insgesamt 14 Teilnehmer begrüßen. Um zunächst das Eis zu brechen, stand als Erstes eine Vorstellungsrunde auf der Agenda. Im Anschluss daran wurde das Thema „IoT – Internet of Things“ anhand vieler Beispiele eingeführt. Damit die Teilnehmer ihre Ideen innerhalb dieser Woche umsetzen können, wurde im Verlauf des ersten Tages zum einen die Cloud Plattform „Bluemix“ die zu nutzenden Services „Watson-IoT-Platform“, „Node-Red“ und diverse „Watson-Services“ und zum anderen verschiedene Hardware, beispielsweise Rasberry Pi  (RasPi) und der passende Sense Hat, vorgestellt sowie eingerichtet. Mit diesem Know-how war es im Laufe des Nachmittags möglich einen Datenfluss vom Device (Datenerzeugung) über die Watson-IoT-Platform (Registrierung) und Node-Red (Verarbeitung) bis hin zur Outputkanal der Wahl (z.B. Twitter, RasPi) zu erstellen.

Wem sich das nach viel Programmierkenntnissen anhört, dem sei versichert, dass für die Umsetzung mit diesen Mitteln lediglich etwas JavaScript benötigt wird. Da bei so viel Theorie und neuen Sachen der Kopf ordentlich raucht, haben wir in diesem Kontext auch für kleine Übungen gesorgt, sodass zum Beispiel einige Lacher beim Anbinden und herumspielen mit den RasPi’s garantiert waren.

Mit dem Wissen aus dem Einführungstag ging es am nächsten Morgen in die Ideenfindung, sodass die verschiedenen Gruppen im Anschluss ihre Ideen in einer Präsentation vorstellten. Diese waren:

  • Swarm Tracker: Innerhalb einer Gruppe erhält der Gruppenleiter eine Warnung auf die Hand, wenn sich ein Mitglied zu weit von der Gruppe entfernt.
  • Blumen Bernd: Auf Grundlage der Wettervorhersage werden Pflanzen, bei entsprechender Notwendigkeit, bewässert.
  • Der smarte Einkaufwagen: Dieser liefert während des Einkaufs Informationen über die Produkte, die in den Korb gelegt wurden. Dies können neben Menge, Preis, Summe auch Informationen über diverse Allergene sein. Darüber hinaus ist auch bargeldloses Zahlen mit dieser Anwendung möglich.

Nachfolgend starteten die Teams in die Umsetzung ihrer eigenen kleinen Projekte und wir, die Kursleiter, waren unterstützend tätig, halfen bei Fragen, Recherchen zu diversen Schnittstellen etc.

Der fünfte und letzte Tag stand ganz im Zeichen der Abschlusspräsentationen. Neben Bugfixing am Morgen wurden Folien und die Präsentationen vorbereitet, sodass am Nachmittag jedes Team ihre Idee, Architektur und Demo vorgestellt hat. Im Anschluss daran konnten die Teilnehmer ihre Zertifikate in Empfang nehmen.

Alles in allem war es aus unserer Sicht ein erfolgreicher Workshop. Ohne übermäßig viel Vorwissen auf dem Gebiet waren alle Teilnehmer in der Lage innerhalb von wenigen Tagen eine eigene IoT-Idee erfolgreich zu entwickeln. Wir freuen uns auf den dritten Workshop. 🙂

Informatik studieren? – Warum nicht!?

by Vanessa Schmidt.

Vanessa_Schmidt

Vanessa Schmidt

Wie bin ich zum MINTlook Projekt gekommen?

Da ich noch keine Ideen bezüglich meiner Studienwahl hatte, bin ich im Internet auf Suche nach Möglichkeiten gegangen und zufällig auf das Projekt gestoßen. Am Tag der offenen Tür der TH Brandenburg besuchte ich die Vorstellungsveranstaltung des MINTlook-Projektes, bei der sich die Unternehmen vorgestellt haben, und beschlossen, dass das eine gute Sache ist. Ich bewarb mich für einen Platz und nun bin ich Teil des Projektes.

 

Was läuft bei meinem Praktikum im CIC ab?

Anfangs durfte ich in viele Projekte des CIC reinschnuppern und verschiedene Bereiche kennenlernen.  Nachdem ich mit dem Programm Java.kara die Anfänge des Programmierens mit Java halbwegs verstanden hatte, bekam ich ein eigenes Projekt. In meinem Projekt entwickle ich ein Snake Spiel, welches man sowohl in verschiedenen Schwierigkeitsstufen als auch als Multiplayer-Spiel spielen kann.

logo_snake_big

Vanessas selbstkreiertes Snake Logo

 

Was gefällt mir besonders gut im CIC?

Ich bekomme von allen Seiten Hilfe, wenn ich sie brauche und arbeite trotzdem sehr selbstständig.Die Arbeitszeiten kann ich mir selbst einteilen und ein eigenes Projekt zu haben, ist wirklich sehr aufregend.

Gibt es Punkte, die ich mir anders vorgestellt habe?

Ich hätte nie damit gerechnet an einem eigenen Projekt arbeiten zu können und das auch noch so selbstständig. Eine Idee wäre vielleicht, dass sich mehrere Hochschulen an diesem Projekt beteiligen, sodass die Studentinnen die Möglichkeit haben an ihrem Hochschultag eventuell am Standort des Unternehmens eine Vorlesung zu besuchen.

Mockup Design

MockUp Entwicklung

Was nehme ich generell aus der Erfahrung im CIC mit?

Während meines Praktikums habe ich nicht nur ein wenig Programmieren gelernt, sondern auch kennengelernt, wie viele verschiedene Einsatzbereiche ein Informatiker haben kann und was es für eine große Spanne an Aufgaben gibt.

Haben mir die Erfahrungen im CIC  bei der Berufs-/Studienwahlentscheidung schon helfen können?

Das Praktikum im CIC hat mir sogar sehr bei meiner Studienentscheidung helfen können, da ich festgestellt habe, dass diese Aufgabe mir sehr viel Spaß gemacht hat und ich mir das vor dem Praktikum nie hätte vorstellen können.

console2

Entwicklung in JavaScript

 

 

Tech Talk #001: IBM Bluemix

Neues Jahr, neue Vorsätze. So ist es auch bei uns im Center und konkret auf diesem Blog. Mit diesem Beitrag möchten wir die Kategorie „Tech Talk“ ins Leben rufen. Hierbei soll es um technische Themen gehen, welche unsere Mitarbeiter oder das Center als Ganzes beschäftigen. Dies wird das Vorstellen einer bestimmten Software oder ein interessantes Anwendungsbeispiel sein, so dass die Leserschaft einen Einblick bzw. Verständnis dafür bekommt, warum es sich lohnt dieses Thema zu verfolgen.

By Sven Wieczorek

Den Anfang zum „Tech Talk“ mache ich zum Thema „IBM Bluemix“.  Allgemein kann man Bluemix als Werkstatt ansehen, in welchem dem Benutzer verschiedene Werkzeuge zur Verfügung stehen. Mit diesen ist es möglich eigene Software über das Erstellen von Anwendungen (Apps) oder verschiedene Services bereitzustellen und zu nutzen.

Apps, die mittels Cloud Fourndy bereitgestellt werden, können dabei in verschiedenen Sprachen programmiert werden, z.B. Java, Node, Python, Ruby, Go. Darüber hinaus ist es auch möglich Docker-Container und virtuelle Maschinen zu hosten. Service-seitig bietet Bluemix das volle Spektrum der Softwareentwicklung an. So hat man die Möglichkeit Datenbanken (z.B. dashDB, Cloudant) anzubinden, eine Einmalanmeldung (Single-Sign-On) und Autoskalierung einzurichten. Ebenso ist es möglich IBM’s Supercomputer Watson zum Analysieren verschiedenster Dinge in seine Anwendungen zu integrieren. Sogar Services für die komplette Organisation eines Projekts sind vorhanden. Darüber hinaus gibt es Services, die die Tickets, die Codeversionierung und die Bereitstellung des Codes verwalten. Alles, was man benötigt, ist auf der Plattform vorhanden. Mit anderen Worten, man hat die Möglichkeit komplette Software-Projekte auf Bluemix zu realisieren.

Stefan Holzschuh_s

Stefan Holzschuh

„Der Workshop im August letzten Jahres war zugleich mein erster Kontakt mit Bluemix. Besser hätte ein Start nicht laufen können. Anstatt ins kalte Wasser geworfen zu werden und Bluemix eigenständig bzw. über Onlinetutorials kennen zu lernen, konnten wir im Team praxisnah an einem selbstgewählten Projekt die Plattform ausprobieren. Sven und Markus standen uns dabei immer mit Rat und Tat zur Seite, so dass der Start mit Bluemix einfach und nicht kompliziert war. Für meine weitere Projektarbeit war dies ungemein hilfreich, da ich einen großen Teil der Konzepte schon kannte und mich daher die endlosen Möglichkeiten von Bluemix nicht erschlagen haben.“

Martin Lobe 2_s

Martin Lobe

„In vorherigen Projekten waren Bluemix und Cloud neue Themen für mich. Trotz der Tatsache, dass ich bereits Grundkenntnisse von Cloud Computing und verteilten Systemen hatte, muss ich gestehen, dass Bluemix anfangs ein etwas unbekanntes Gebiet war. Ich nahm daher die ‘Cloud Application Development‘ – Zertifizierung als die Gelegenheit wahr, um mein Wissen aufzufrischen, zu vertiefen und, um Bluemix Services besser zu verstehen. Während der Vorbereitung auf die Zertifizierung stellte ich fest, dass das einfache Abarbeiten des Study Guide und der Übungen mir nicht die Erfahrungen gegeben haben, die ich als Entwickler benötige. Daher empfehle ich allen künftigen Teilnehmern: verschafft euch einen Überblick über die einzelnen Kapitel, bereitet eine kleine Projekt-Idee vor und implementiert sie. Macht eventuell auch etwas Ungewöhnliches und stellt euch den Problemen, die dadurch auftreten. So seid ihr für den Arbeitsalltag gut gerüstet.“

David_Krueger1_s

David Krüger

 

„Ich durfte mich vor etwas längerer Zeit mit Bluemix beschäftigen. Leider war das nur kurzfristig und habe deshalb nur einen groben Überblick über den Aufbau und die Funktionsweise dieses Services. Das hat mein Interesse geweckt und ich freue mich deshalb mehr über die Welt von Bluemix durch die geplanten Workshops zu erfahren“

 

Das macht die ganze Sache auch für das Center interessant. Bereits in den vergangenen Monaten arbeiteten einige Kollegen in diesem Umfeld und, da Cloud Computing ein Themenfeld mit großem Wachstumspotenzial ist, werden mittelfristig weitere Kollegen benötigt, die mit und auf Bluemix arbeiten können. Das bedeutet Engagement in Sachen Weiterbildung, sowohl vom Mitarbeiter als auch vom Center aus. Dies wird im Rahmen von Masterclasses, Schulungen, Workshops und Zertifizierungen realisiert, wobei die Erfahrungen der Kollegen, die auf diesem Gebiet schon unterwegs sind, mit berücksichtigt werden und die Weiterbildung so effizient wie möglich durchgeführt werden kann.

Aus eigener Erfahrung kann ich berichten, dass das Arbeiten mit Bluemix für die Umsetzung eigener Ideen oder ganzer Projekte viele Vorteile hat. Es spart enorm Zeit und Frustpotenzial, da das Konfigurieren und Einrichten verschiedenster Dinge wegfällt und man sich dadurch voll und ganz auf die Programmierung fokussieren kann und schon innerhalb einiger Minuten erste Ergebnisse sehen kann. Die Anbindung der verschiedenen Services funktioniert ebenfalls reibungslos. Man muss sich nur fix anlesen wie man die Services nutzt, aber das gibt es ja bei jeder Software, die man kennenlernt.

Wer Interesse daran bekommen hat sich einmal auszuprobieren, der kann sich auf Bluemix einfach anmelden und die 30 Tage Testversion nutzen. Studenten können sich sogar sechs Monate austoben. Wir werden in künftigen Beiträgen genauer auf die Nutzung eingehen und einzelne Services vorstellen. Stay tuned …

Internet of Things Workshop

Neugierig geworden? Dann meldet euch jetzt zu unserem IoT-Workshop an!

Am 20.03.2017 bis 24.03.2017 findet unser zweiter Internet of Things Workshop in der Magdeburger Lokation statt. Lernt die IBM IoT Werkzeuge von morgen kennen. Setzt eure Ideen um und zeigt uns was in euch steckt.

Die Voraussetzungen für die Teilnahme am Workshop:
• IT-interessierte Studierende mit guten Grundkenntnissen in der Programmierung (Java, JavaScript, HTML oder Python)
• Erste praktische Projekterfahrungen bzw. kleinere Uniprojekte sind wünschenswert
• Sehr gute Deutschkenntnisse erforderlich (min. Level C1)
• Teilnehmer müssen ein eigenes Notebook mitbringen

Die Anzahl der Plätze ist auf 15 Teilnehmer beschränkt.
Um an dem Workshop teilzunehmen, bitten wir euch um eine Nennung folgender persönlichen Informationen: Euren Studiengang, aktuelles Semester und eine Auflistung eurer vorhandenen IT-Skills.
Diese Informationen helfen uns den Workshop vorzubereiten und die Teilnahmevoraussetzung zum Workshop zu überprüfen.
Die Anmeldung zum IoT Workshop erfolgt über die E-Mailadresse CICRECDE@de.ibm.com. Nach Eingang eurer Anmeldung erhaltet ihr per E-Mail eine Anmeldebestätigung bis spätestens zum 06.03.2017.

Wir freuen uns auf euch!