WAS HABE ICH ALS FACHINFORMATIKER BISHER GELERNT?<br />
<br />
This blog post has been published on 2016-01-17 and may be out of date.<br />
<br />
Nachdem ich nun bereits seit einigen Jahren lerne zu deklarieren und zu programmieren, werde ich im folgenden beschreiben was ich bisher gelernt habe.<br />
<br />
> Kurz zu mir: _ Lars Moelleken [<a target="_blank" href="https://www.xing.com/profile/Lars_Moelleken">https://www.xing.com/profile/Lars_Moelleken</a>] _ |<br />
>> Assistent für Betriebsinformatik<br />
>> Fachinformatiker Systemintegration<br />
>> Informatik Studium (Abgebrochen)<br />
>> Fachinformatiker Anwendungsentwicklung<br />
<br />
WAS HABE ICH IN MEINER AUSBILDUNG ZUM FACHINFORMATIKER SYSTEMINTEGRATION GELERNT?<br />
<br />
– DU LERNST NUR SOVIEL, WIE DU LERNEN WILLST.<br />
<br />
Im Gegensatz zur Schule / Fachhochschule konnte und musste ich mir vieles in der Ausbildung selber beibringen und erarbeiten. Und man erkennt schnell, dass man nur soviel lernt wie man möchte. Wenn man dies einmal verstanden hat, dann setzt man sich auch gerne hin und lernt z.B. Linux- / Shell-Befehle auswendig, besucht weitere Kurse (z.B. bei der VHS), geht zu Meetups oder Konferenzen. Krümmer dich um dein Können, denn wenn man etwas macht, sollte man es auch richtig machen.<br />
<br />
“Eine Investition in Wissen bringt noch immer die besten Zinsen.” – Benjamin Franklin<br />
<br />
– KEINE PANIK!<br />
<br />
Was man ziemlich schnell als Sysadmin lernt ist „Ruhe bewahren“ and think first – then act. Überstürzter Aktionismus hilft nicht weiter und schadet meistens sogar. Bevor man handelt, sollte man zuvor selber einige Informationen einholen (Infos von Logfiles, Hardware Status, System Status, …) so dass man auch wirklich weiß was wie man den Fehler behene kann.<br />
<br />
– LINUX && KOMMANDOZEILE<br />
<br />
> find – Linux [<a target="_blank" href="http://suckup.de/2010/01/find-linux/?pk_campaign=feed&pk_kwd=was-habe-ich-als-fachinformatiker-bisher-gelernt">http://suckup.de/2010/01/find-linux/?pk_campaign=feed&pk_kwd=was-habe-ich-als-fachinformatiker-bisher-gelernt</a>]<br />
<br />
– LIES IN DER OFFIZIELLE DOKUMENTATION (UND ERST DANN BEI “STACK OVERFLOW”).<br />
<br />
Ob Cisco oder Manpages man liest am besten die offizielle Dokumentation zu der Programm-Version / Hardware-Version welche man gerade einsetzt. Beim programmieren nutzt man jedoch häufig stackoverflow.com und findet schnell Antworteten und Code-Beispiele, aber das “Warum” und “Wie” kommt dabei meistens zu kurz. Wenn man als erstes in die Spezifikation / Dokumentation schaut löst man nicht nur dieses Problem, sondern man versteht ggf. das Problem und weiß auch wie man ähnliche Probleme lösen kann.<br />
<br />
– MACH IMMER EIN BACKUP (BENUTZE NIEEEMALS BETRUNKEN “SUDO”).<br />
<br />
Manche Sachen muss man auf die hart Tour lernen,<br />
<br />
```apt-get install safe-rm```<br />
<br />
zu installieren gehörte für mich anscheinend dazu!<br />
<br />
“Der Mensch hat dreierlei Wege klug zu handeln; erstens durch Nachdenken, das ist der edelste; zweitens durch Nachahmen, das ist der leichteste; und drittens durch Erfahrung, das ist der bitterest.” – (Konfuzius)<br />
<br />
– SEI EHRLICH ZU KUNDEN, MITARBEITERN UND DIR SELBST.<br />
<br />
Sei ehrlich zu Kunden, insbesondere wenn etwas schief geht. Wenn das Produkt (z.B. Server) vom Kunden ausfällt, dann biete Lösungsvorschläge an und keine Ausreden und löse das Problem nicht die Schuldfrage. Niemandem ist damit geholfen, wenn man mit dem Finger auf den Kollegen oder Kunden zeigt, dem Server nicht, dem Kunden nicht und letztlich einem selbst nicht.<br />
<br />
– STELLE FRAGEN, WENN DU ETWAS NICHT VERSTANDEN HAST.<br />
<br />
Rede mit Kunden nicht über etwas was du nicht verstehst, etwas nicht zu wissen (insbesondere in der Ausbildung) ist nicht schlimm, aber dann frage einen Kollegen bevor du mit einem Kunden darüber sprichst!<br />
<br />
– DENKE ÜBER DEIN TUN NACH (NICHT NUR AUF DER ARBEIT).<br />
<br />
Wenn man Dinge hinterfragt und über seine Arbeit und sein Tun nachdenkt, dann kann man sich persönlich weiterentwickeln. Hinterfrag kritische zum Beispiel ob man wirklich bei Amazon bestellen sollte oder sollte man das Buch lieber direkt beim Verlag bestellt? Welchen Vorteil hat der Autor davon und habe ich Nachteile? Sollten wir Nagios3 oder besser direkt Icinga einsetzen? Hinterfrage deine Arbeit und bewerte kritisch ob dies wirklich eine gute / sichere / zukunftsorientierte Lösung ist.<br />
<br />
Falls man sich selber nicht sicher ist oder eine zu eingeschränkte Sichtweise hat (weil man z.B. nur diese eine Lösung kennt), dann sollte man sich neues Wissen aneignen, ggf. andere Lösungen oder „best practices“ recherchieren und mit anderen über die Thematik diskutieren.<br />
<br />
– GOOGLE KORREKT NUTZEN …<br />
<br />
Wenn man ein Problem recherchiert, dann sucht man nach der Fehlermeldung in Anführungszeichen. Und wenn man keine Fehlermeldung hat sucht man zusätzlich nach der Versionsnummer oder / und einer entsprechenden Jahreszahl.<br />
<br />
<a target="_blank" href="https://suckup.de/2010/02/google-hacks-und-tricks/">https://suckup.de/2010/02/google-hacks-und-tricks/</a><br />
<br />
WAS HABE ICH IN MEINER AUSBILDUNG ZUM FACHINFORMATIKER ANWENDUNGSENTWICKLUNG GELERNT?<br />
<br />
– DU LERNST NIEMALS AUS …<br />
<br />
Wenn man anfängt sich mit der Web-Programmierung (HTML, CSS, JS, Node.js, PHP, …) zu beschäftigen, weiß man zunächst gar nicht wo man anfangen soll! Es gibt so vieles zu lernen und dieses Gefühl begleitet einen einige Zeit (Jahre), bis man wiederkehrende Konzepte erkennt. Der Vorteil in der Web-Programmierung ist jedoch, dass viele unterschiedliche Dinge gemeinsame APIs haben oder zumindest kombiniert werden können. Ich kann in PHP eine Klasse schreiben, welche mir Data-Attribute für mein HTML erstellt, welche ich wiederum mit JavaScript auslesen kann, um diese entsprechend über CSS-Klassen zu gestalten. Aber es bleibt dabei, man lernt niemals aus und genau das ist das Spannende an diesem Job!<br />
<br />
– PROGRAMMIERE JEDEN TAG. (ABER SETZTE DIR SELBER EIN LIMIT 1, X)<br />
<br />
Auch wenn der Chef heute nicht im Büro ist und man als Azubi gerade keine Aufgabe hat, dann programmiere, wenn du Zuhause auf der Couch sitzt (und keine neue Serie auf Netflix läuft), dann programmiere und wenn du Urlaub hast, hast du Urlaub!<br />
<br />
Hier ein interessanter Link von „John Resig“ (jQuery):<br />
<a target="_blank" href="http://ejohn.org/blog/write-code-every-day/">http://ejohn.org/blog/write-code-every-day/</a><br />
<br />
– DENKE IN MODULEN UND PACKAGES …<br />
<br />
Wenn man jeden Tag Software schreibt, möchte man die selbe Funktionalität (z.B. Datenbankverbindung, E-Mail senden oder Error-Logging …) nicht mehrfach für verschiedene Projekte programmieren (und eigentlich will man Standard-Funktionen gar nicht selber programmieren). Daher sollte jeder Programmierer in Modulen denken und eine Applikation in verschiedenen, am besten austauschbaren Teilen konzipieren. In vielen Fällen kann man das System dann auch besser erweitern, da es bereits eine Schnittstelle für Module gibt, welche man nutzen kann. Die Unabhängigkeit und Entkopplung von Programmteilen hat auch den Vorteil, dass Seiteneffekte von unterschiedlichen Stellen im Quelltext weiter vermieden werden. Außerdem sollte man die Kopplung von den entsprechenden Modulen minimieren, da man ansonsten nichts durch Modulen gewinnt.<br />
<br />
Für fast alle Dinge in der Web-Entwicklung gibt es bereits Paket-Manager:<br />
– Frontend (css, js): bower (npm)<br />
– Backend (Node.js): npm<br />
– Backend (php): composer<br />
– Backend (ruby): gem<br />
<br />
– OPEN SOURCE Falsch: farbeBlack(), nutzeFarbe(), …<br />
-> Richtig: $page->setColor(‘black’), $page->getColor(), …<br />
<br />
Variablen sollten beschreiben was diese beinhalten und nicht wie diese gespeichert sind.<br />
<br />
-> Falsch: $array2use, $personenArray, …<br />
-> Richtig: $pages, $persons, …<br />
<br />
Zusammenfassung: Beschreibe was die Variable / Methode / Funktion / Klasse ist, nicht wie diese implementiert ist.<br />
<br />
> Weniger schlecht PHP programmieren [<a target="_blank" href="http://suckup.de/2014/05/weniger-schlecht-php-programmieren/?pk_campaign=feed&pk_kwd=was-habe-ich-als-fachinformatiker-bisher-gelernt">http://suckup.de/2014/05/weniger-schlecht-php-programmieren/?pk_campaign=feed&pk_kwd=was-habe-ich-als-fachinformatiker-bisher-gelernt</a>]<br />
<br />
– AN KOMMENTARE SPAREN (ZUMINDEST INLINE) …<br />
<br />
Gute Kommentare erklären “Warum” und nicht “Was” gemacht wird und sollten dem Leser einem Mehrwert bieten, welcher nicht bereits im Quelltext (Stichwort: Namensgebung) beschrieben ist.<br />
<br />
Beschreibungen für Methoden, Funktionen und Klassen (javadoc, phpdoc, …) sollte meiner Meinung nach immer hinterlegt werden, so dass man seine Dokumentation im Quelltext abbildet. Moderne IDEs können zudem prüfen, ob die Parameter und Rückgaben korrekt hinterlegt wurden.<br />
<br />
<a target="_blank" href="https://de.wikipedia.org/wiki/PHPDoc">https://de.wikipedia.org/wiki/PHPDoc</a><br />
<a target="_blank" href="https://en.wikipedia.org/wiki/JSDoc">https://en.wikipedia.org/wiki/JSDoc</a><br />
<a target="_blank" href="https://de.wikipedia.org/wiki/Javadoc">https://de.wikipedia.org/wiki/Javadoc</a><br />
<br />
Beispiele für inline Kommentare:<br />
<br />
schlechter Code:<br />
<br />
// Prüfen ob der User bereits einloggt ist<br />
if (isset($_SESSION['user_loggedin']) && $_SESSION['user_loggedin'] > 1) { ... }<br />
<br />
etwas besserer Code:<br />
<br />
// check if the user is already logged-in<br />
if (session('user_loggedin') > 1) { ... }<br />
<br />
besserer Code:<br />
<br />
if ($user->isLoggedin === true) { ... }<br />
<br />
… und noch ein Beispiel …<br />
<br />
schlechter Code:<br />
<br />
// regex: email<br />
if (!preg_match('/^(.*&lt;?)(.*)@(.*)(>?)$/', $email) { ... }<br />
<br />
besserer Code:<br />
<br />
define('EMAIL_REGEX_SIMPLE', '/^(.*&lt;?)(.*)@(.*)(>?)$/');<br />
<br />
if (!preg_match(EMAIL_REGEX_SIMPLE, $email) { ... }<br />
<br />
– KONSISTENZ IN EINEM PROJEKT, IST WICHTIGER ALS PERSÖNLICHE PRÄFERENZEN!<br />
<br />
Nutze den bestehenden Code und nutze gegebene Funktionen. Wenn es Vorteile bringt, dann ändern / refactor den entsprechenden Code aber refactor dann alle Stellen im Projekt welche auf diese Weise implementiert sind.<br />
<br />
Beispiel: Wenn man bisher ohne Template-System gearbeitet hat und aus „Gründen“ eines einsetzten möchte, dann nutze dies für alle Templates im Projekt und nicht nur für deinen aktuellen Use-Case, da ansonsten inkonsistenten im Projekt entstehen. Wenn man z.B. eine neue „Email→isValid()“ Methode, dann sollte man auch alle bisherigen RegEx-Versuche im aktuellen Projekt durch die „Email“-Klasse ersetzten, weil ansonsten wieder inkonsistenten entstehen.<br />
<br />
– EIN EINHEITLICHER CODE-STYLE WIRKT SICH SEHR POSITIV AUF DIE QUALITÄT AUS!<br />
<br />
Wie im echten Leben gilt auch hier, wenn irgendwo bereits Müll liegt, sinkt die Hemmschwelle seinen einen Müll dort abzuladen extrem an. Wenn aber alles schön ordentlich aussieht, wirft man nicht einfach eine “randumInt() { return 4; } “-Funktion hinzu.<br />
<br />
Man sollte sich im Team einen Code-Style überlegen und diesen in neuen Projekten einsetzten. In bestehenden Projekten gibt wieder Konsistent geht vor.<br />
<br />
– NUTZE FUNKTIONALE-PRINZIPIEN && OBJEKT-ORIENTIERTE-KONZEPTE.<br />
<br />
Eine reine Funktion (“Pure Functions”) ist nur von ihren Parametern abhängig und mit den selben Parametern liefert diese immer das selbe Ergebnis. Diese Prinzipien kann man auch in OOP berücksichtigen und sogenannte Unveränderbare Klassen erstellen (immutable class).<br />
<br />
<a target="_blank" href="https://en.wikipedia.org/wiki/Pure_function">https://en.wikipedia.org/wiki/Pure_function</a><br />
<a target="_blank" href="https://de.wikipedia.org/wiki/Objektorientierte_Programmierung">https://de.wikipedia.org/wiki/Objektorientierte_Programmierung</a><br />
<a target="_blank" href="https://en.wikipedia.org/wiki/Immutable_object">https://en.wikipedia.org/wiki/Immutable_object</a><br />
<br />
– BITTE KEINE GLOBALEN VARIABLEN VERWENDEN!<br />
<br />
Globale Variablen erschweren das Testen, da diese Seiteneffekte verursachen können. Außerdem kann man Quelltext mit globalen Variablen nur schwer refactoren, da man nicht weiß welche Effekte diese Änderungen auf andere Teile des Systems haben.<br />
<br />
In einigen Programmiersprachen (z.B. JavaScript, Shell) sind alle Variablen global und werden erst durch eine bestimmtes Schlüsselwort lokal (z.B. im Scope einer Funktion oder einer Klasse).<br />
<br />
> Admin meets Frontend [<a target="_blank" href="http://suckup.de/2015/03/admin-meets-frontend/?pk_campaign=feed&pk_kwd=was-habe-ich-als-fachinformatiker-bisher-gelernt">http://suckup.de/2015/03/admin-meets-frontend/?pk_campaign=feed&pk_kwd=was-habe-ich-als-fachinformatiker-bisher-gelernt</a>]<br />
<br />
– LERNE DEINE WERKZEUGE RICHTIG EINZUSETZEN!<br />
<br />
Wenn man z.B. mit Notepad Quelltext schreibt kann man auch mit einem Löffel ein Loch graben, denn dies ist ähnlich effizient. Lerne Tastatur-Shortcuts für deine Programme und dein Betriebssystem! Nutze eine IDE z.B. von JetBrains ( <a target="_blank" href="https://www.jetbrains.com/products.html">https://www.jetbrains.com/products.html</a> ) und nutze zusätzliche Plugins und Einstellungen.<br />
<br />
Moderne IDEs geben auch Hinweise / Vorschläge, wie man seinen Code verbessern kann. Für PHP kann man z.B. PhpStorm + Php Inspections (EA Extended) einsetzten und die globalen IDE- Inspections-Einstellungen im Team teilen.<br />
<br />
– PERFORMANCE?<br />
<br />
In vielen Situationen muss man sich um die Performance gar nicht so viele Gedanken machen, da uns dabei moderne Programmiersprachen / Frameworks unterstützen und mit einem gesunden Menschenverstand kann man bereits vieles abschätzen, ansonsten heißt die Devise „Profiling, Profiling… Profiling“!<br />
<br />
– EXCEPTIONS === AUSNAHMEN<br />
<br />
Man sollte Ausnahmebehandlungen niemals zur Behandlung normaler (d.h. häufig auftretender) Fehler einsetzen. Ausnahmen sind Ausnahmen und sollten aus Ausnahmen bleiben. Regulärer Code behandelt die regulären Fälle! „Verwenden Sie Ausnahmen nur ausnahmsweise“ (Pragmatische Programmierer). Und auf keinen Fall sollte man Ausnahmen “abwürgen”, z.B. durch triviale Abfangen mehreren Exceptions.<br />
<br />
– FÜHRE DEINE ARBEIT ZU ENDE<br />
<br />
Man sollte in einer Funktion zu Ende führen, was man begonnen hat. So sollte man z.B. „fopen&#40;&#41;“ und „fclose()“ immer in einem Code-Block (Methode || Funktion) nutzen, weil man ansonsten darauf vertrauen müsste, dass jemand anders die entsprechende Ressourcen wieder frei gibt.<br />
<br />
– QUELLTEXT SOLLTE DURCHSUCHBAR SEIN [STRG + F] …<br />
<br />
Der Quelltext sollte einfach zu durchsuchen sein, daher sollte man z.B. auf String-Nesting + „&” bei Sass verzichten und auch bei PHP-Funktionen wie “extract()” vermeiden. Immer wenn Variablen nicht deklariert, sondern wie von Zauberhand (z.B.: bei PHP durch Magic-Methoden) erzeugt werden, kann man den Quelltext anschließend nicht mehr so einfach ändern.<br />
<br />
Beispiel in PHP: (schlecht)<br />
<br />
extract(array('bar' => 'bar', 'lall' => 1));<br />
var_dump($bar); // string 'bar' (length=3)<br />
<br />
Beispiel in Sass: (schlecht)<br />
<br />
.teaser {<br />
  font-size: 12px;<br />
<br />
  &__link {<br />
    color: rgb(210,210,22);<br />
  }<br />
}<br />
<br />
Sass Nesting (Code-Style): <a target="_blank" href="https://github.com/grvcoelho/css#nesting">https://github.com/grvcoelho/css#nesting</a><br />
<br />
– PROGRAMMIERE FÜR DEINEN USE-CASE!<br />
<br />
Ein großes Problem in der Programmierung ist, dass man versuchen muss generalisiert zu denken und zu programmieren, so dass man den Quelltext entsprechende (einfach) erweitern kann, wenn neue Anforderungen hinzukommen bzw. auch (einfach) ändern kann.<br />
<br />
Wie sehen IT-Projekte manchmal aus? → Ein Kunde bestellt bei einem Bauernhof 10.000 grüne Äpfel, ändert seine Bestellung am morgen vor der Lieferung auf 10.000 rote Äpfel und als diese geliefert werden möchte der Kunde aber doch lieber 10.000 Birnen und möchte diese gerne erst in 6 Monaten bezahlen.<br />
<br />
Und gerade aus diesem Grund sollte man nur den Quelltext schreiben, der wirklich für den aktuellen Use-Case benötigt ist, denn alle Eventualitäten kann man sowieso nicht abbilden und der Quelltext wird unnötig verkompliziert.<br />
<br />
– KISS – KEEP IT SIMPLE, STUPID.<br />
<br />
Man sollte immer beachten, dass der Quelltext selber gar nicht so viel Wert besitzt. Der Wert entsteht erst dadurch, dass andere Entwickler diesen verstehen und für den Kunden oder sich selbst anpassen / konfigurieren / nutzen können. Dies sollte man während der Programmierung im Hinterkopf behalten, so dass man eine Lösung möglichst nachvollziehbar und „einfach“ implementiert. Und wenn ich keine neue Klasse oder schönes Design-Pattern für das aktuelle Problem verwenden muss, sollte ich dies ggf. auch nicht tun. Was jedoch auch nicht heißt, dass man alle guten Absichten über Board werfen und überall global Variablen / Singletons einsetzten sollte. Wenn jedoch eine einfache Lösung die Aufgabe bereits erfüllt, entscheide dich für diese.<br />
<br />
Ein gutes Beispiel wie man es nicht machen sollte, stellt die JavaScript Dom Selector API da. Nicht gerade schön zu lesen oder zu schreiben …<br />
<br />
Schlecht: (DOM Selector via JS)<br />
<br />
document.getElementsByTagName("div")<br />
document.getElementById("foo")<br />
document.getElementsByClassName("bar")<br />
document.querySelector(".foo")<br />
document.querySelectorAll("div.bar")<br />
<br />
Besser: (DOM Selector via jQuery)<br />
<br />
$("div")<br />
$("#foo")<br />
$(".bar")<br />
$(".foo")<br />
$("div.bar")<br />
<br />
(Ich weiß welche Schreibweise ich bevorzugen würde!)<br />
<br />
– DRY – DON’T REAPEAT YOURSELF.<br />
<br />
Wiederholungen / Redundanzen im Quelltext oder auch in wiederkehrenden Arbeiten, entsteht relativ schnell wenn die Leute z.B. nicht miteinander kommunizieren. Aber auch unbeabsichtigt durch Fehler im Software-Entwurf, weil man es gerade keine bessere Idee hat oder meint dafür keine Zeit zu haben.<br />
<br />
Image: "improve"<br />
<br />
Um Wiederholungen zu vermeiden, sollte man den Quelltext bzw. den Task so ablegen, dass dieser einfach zu finden und einfach wiederzuverwenden ist, denn wenn es nicht einfach zu verwenden ist, werden die Leute es nicht nutzen.<br />
<br />
– DER WILLE ETWAS NEUES ZU LERNEN UND ZU VERSTEHEN IST WICHTIGER ALS VORKENNTNISSE.<br />
<br />
Wenn man bereits z.B. ActionScript (Flash) programmieren kann, aber nicht willens ist etwas neues zu lernen dann bringt einem das vorherige Wissen nichts, denn „Die einzige Konstante im Universum ist die Veränderung.“ – Heraklit von Ephesus (etwa 540 – 480 v. Chr.)<br />
<br />
– LESE GUTE BÜCHER UND ZEITSCHRIFTEN.<br />
<br />
Habe mir letztes Jahr das Ziel gesetzt mehr Fachbücher zu lesen. Dafür habe ich mir folgendes auferlegt: bevor ich ein “normales” Buch lesen darf, muss ich ein Fachbuch lesen und anschließend darf ich erst ein normales lesen …<br />
<br />
Bücher die ich gelsen habe: <a target="_blank" href="https://www.goodreads.com/user/show/3949219-lars-moelleken">https://www.goodreads.com/user/show/3949219-lars-moelleken</a><br />
Free Books: <a target="_blank" href="https://github.com/vhf/free-programming-books/blob/master/free-programming-books.md">https://github.com/vhf/free-programming-books/blob/master/free-programming-books.md</a><br />
Bücher für Programmierer: <a target="_blank" href="http://stackoverflow.com/questions/1711/what-is-the-single-most-influential-book-every-programmer-should-read">http://stackoverflow.com/questions/1711/what-is-the-single-most-influential-book-every-programmer-should-read</a><br />
<br />
– INFOS: FOLGE ANDEREN PROGRAMMIEREN AUF TWITTER / GITHUB / GOOGLE+ / MEDIUM / POCKET …<br />
<br />
<a target="_blank" href="http://programmers.stackexchange.com/questions/135/as-a-software-engineer-who-should-i-be-following-on-twitter">http://programmers.stackexchange.com/questions/135/as-a-software-engineer-who-should-i-be-following-on-twitter</a><br />
<br />
– INFOS: HÖRE PODCAST & ABONNIERE RSS-FEEDS / NEWSLETTER & SCHAUE VIDEOS Z.B. VON WEB-KONFERENZEN<br />
<br />
Um sich über neue Technologien, Techniken, Standards, Pattern etc. zu informieren nutzt man am besten verschiedene Medien, welche man in unterschiedlichen Situationen konsumieren kann. Ein interessanten Podcast zum Thema “Frontend Architektur” vor dem einschlafen oder ein Video zum Thema “DevOp” beim zubereiten vom Mittagessen, morgens in der Straßenbahn ein Buch lesen mit dem Titel “Weniger schlecht programmieren” … um nur ein paar Beispiele zu nennen.<br />
<br />
Podcasts: <a target="_blank" href="https://github.com/voku/awesome-web/blob/master/README.md#-audio-podcast">https://github.com/voku/awesome-web/blob/master/README.md#-audio-podcast</a><br />
Newsletter: <a target="_blank" href="https://github.com/Freizeitler/Awesome-WebDev-Newsletters">https://github.com/Freizeitler/Awesome-WebDev-Newsletters</a><br />
github is awesome: <a target="_blank" href="https://github.com/sindresorhus/awesome">https://github.com/sindresorhus/awesome</a><br />
and there is more: <a target="_blank" href="https://github.com/jnv/lists">https://github.com/jnv/lists</a><br />
<br />
– BESUCHE MEETUP’S & WEB-KONFERENZEN UND REDE MIT ANDEREN ENTWICKLERN.<br />
<br />
Meetup’s sind Gruppen von Leuten die sich regelmäßig treffen und über z.B. Python, Scala, PHP, etc. austauschen. Meistens hält jemand einen Vortrag zu einem vorher abgestimmten Thema.<br />
<br />
-> <a target="_blank" href="http://www.meetup.com/de-DE/members/136733532/">http://www.meetup.com/de-DE/members/136733532/</a><br />
<br />
Web-Konferenzen machen Spaß. Punkt. Und jeder Entwickler / Administrator sollte diese besuchen, da man neue Eindrücke gewinnt und wirklich gute Leute trifft. Einige Konferenzen sind wirklich teuer, aber hier sollte man sich an seinen Arbeitgeber wenden, ggf. wird dies von der Firma übernommen. Außerdem gibt es auch wirklich günstige Konferenzen.<br />
<br />
– SCHREIBE ANTWORTEN BEI QUORA.COM || STACKOVERFLOW.COM || IN FOREN || DEINEM BLOG …<br />
<br />
Um sich selber mit einer bestimmten Thematik auseinander zu setzten und<br />
wirklich zu verstehen, lohnt es sich zu recherchieren und einen Text (ggf. sogar einen Vortrag) zu verfassen, welchen andere lesen und kritisieren und somit verbessern können.<br />
<br />
– BLEIB NICHT JEDEN TAG SO LANGE AUF DER ARBEIT, ANSONSTEN WARTET ZUHAUSE IRGENDWANN KEINER MEHR AUF DICH!!!<br />
<br />
Bei all der Begeisterung für den “Job” (auch wenn es Spaß macht) sollte man die wirklich wichtigen Dinge nicht aus den Augen verlieren. Wieder etwas was ich auf die hart Tour lernen musste. :/<br />
<br />
SHARE THIS:<br />
<br />
  * Twitter [<a target="_blank" href="https://suckup.de/2016/01/was-habe-ich-als-fachinformatiker-bisher-gelernt/?share=twitter">https://suckup.de/2016/01/was-habe-ich-als-fachinformatiker-bisher-gelernt/?share=twitter</a>]<br />
  * Facebook [<a target="_blank" href="https://suckup.de/2016/01/was-habe-ich-als-fachinformatiker-bisher-gelernt/?share=facebook">https://suckup.de/2016/01/was-habe-ich-als-fachinformatiker-bisher-gelernt/?share=facebook</a>]<br />
  *<br />
<br />
LIKE THIS:<br />
<br />
LikeLoading...<br />
<br />
ÄHNLICHE BEITRÄGE:<br />
<br />
V-Server Problem bei StratoShellShock – Sicherheitsproblem bei der Unix-Shell $(bash) Image: "Default Thumbnail" Guideline für Open Source Software [<a target="_blank" href="https://suckup.de/2015/04/guideline-fuer-open-source-software/">https://suckup.de/2015/04/guideline-fuer-open-source-software/</a>]<br />
<br />
PUBLISHED BY<br />
<br />
VOKU<br />
<br />
Lars Moelleken [<a target="_blank" href="https://plus.google.com/115714615799970937533/posts">https://plus.google.com/115714615799970937533/posts</a>] | Ich bin root, ich darf das! View all posts by voku [<a target="_blank" href="https://suckup.de/author/admin/">https://suckup.de/author/admin/</a>]<br />
<br />
2016-01-172016-01-17 [<a target="_blank" href="https://suckup.de/2016/01/was-habe-ich-als-fachinformatiker-bisher-gelernt/">https://suckup.de/2016/01/was-habe-ich-als-fachinformatiker-bisher-gelernt/</a>] voku [<a target="_blank" href="https://suckup.de/author/admin/">https://suckup.de/author/admin/</a>] General [<a target="_blank" href="https://suckup.de/category/general/">https://suckup.de/category/general/</a>] , Linux [<a target="_blank" href="https://suckup.de/category/linux/">https://suckup.de/category/linux/</a>] , ubuntuusers.de [<a target="_blank" href="https://suckup.de/category/ubuntuusers-de/">https://suckup.de/category/ubuntuusers-de/</a>] Fachinformatik [<a target="_blank" href="https://suckup.de/tag/fachinformatik/">https://suckup.de/tag/fachinformatik/</a>] , programmieren [<a target="_blank" href="https://suckup.de/tag/programmieren/">https://suckup.de/tag/programmieren/</a>]