Was ich diese Woche gelernt habe (Woche 32/2013)

Jede Woche schreibe ich einen Blogbeitrag, der beschreibt, was ich in dieser Woche gelernt habe. Ich schreibe diese Blogbeiträge aus zwei Gründen.

Zuerst , ich möchte meine persönliche Entwicklung im Auge behalten, und das Schreiben regelmäßiger Blogbeiträge ist eine großartige Möglichkeit, dies zu tun.

Zweiter , ich möchte meine Erkenntnisse mit Ihnen teilen. Ich hoffe, dass Sie einige davon in Ihrer täglichen Arbeit verwenden können.

Fangen wir an und finden heraus, was ich in Woche 32 gelernt habe.

Was ich in Woche 32 gelernt habe

Zuerst , Es ist keine gute Idee, separate Frontend- und Backend-Entwickler zu haben. Diese Situation hat zwei Probleme:

1. Wenn Sie ein Problem in Ihrem Backend haben und alle Backend-Entwickler nirgends zu finden sind, sind Sie am Arsch (und umgekehrt). Auch wenn die Frontend-Entwickler in der Lage sind, Backend-Code zu schreiben, können sie nicht sofort produktiv sein, weil sie damit nicht vertraut sind. Wenn Sie dieses Problem schnell beheben müssen, haben Sie Pech.
2. Wenn Back-End- und Front-End-Code von unterschiedlichen Entwicklern geschrieben wurden, müssen Sie die vom Back-End bereitgestellte API angeben, bevor Code geschrieben wird. Außerdem müssen Sie zusätzliche Maßnahmen ergreifen, um sicherzustellen, dass die Frontend- und Backend-Entwickler keine „inkompatiblen“ Annahmen treffen. Wenn Sie es eilig haben, ist dies möglicherweise keine praktikable Option.

Ich sage nicht, dass Spezialisierung schlecht ist. Ich denke jedoch, dass alle Entwickler sowohl Frontend- als auch Backend-Code schreiben sollten.

Zweiter , Alle Hipster-Tools saugen nicht. Tatsächlich sind einige von ihnen ziemlich großartig. Wenn Sie beispielsweise eine Single-Page-Webanwendung erstellen, können Sie mithilfe von NPM, Bower und Grunt ein ziemlich gutes Abhängigkeitsverwaltungs- und Automatisierungssystem erstellen. Ich gebe zu, dass ich damit nicht viel Erfahrung habe, aber meine ersten Erfahrungen waren sehr positiv.

Dritter , ich habe immer gedacht, dass das Speichern hierarchischer Daten in einer relationalen Datenbank bedeutet, dass Sie eine hierarchische Tabellenstruktur erstellen müssen. Letzte Woche hat mir einer meiner Kollegen gesagt, dass er sich entschieden hat, die Hierarchie als JSON-Dokument zu beschreiben und dieses Dokument in der verwendeten Datenbank zu speichern.

Ich war sehr überrascht (und ein bisschen beschämt), das zu hören, denn diese Idee kam mir nie in den Sinn. Aber wenn ich darüber nachdenke, macht es absolut Sinn. Diese Lösung ist einfach und leidet nicht unter Leistungsproblemen, die mit der "traditionellen" Lösung verbunden sind. Das erinnerte mich daran, wie leicht es ist, in alten Gewohnheiten stecken zu bleiben. Manchmal ist es definitiv besser, um die Ecke zu denken.

Vierter , Die Verwendung von JSON anstelle von XML bedeutet nicht, dass Sie eine bessere Leistung erzielen.

Fünfter , Ich habe nach einem guten Code-Colorer-Plugin für WordPress gesucht. Das SyntaxHighter Evolved ist wahrscheinlich das beste existierende WordPress-Plugin für diesen Zweck.

Jedenfalls habe ich gestern eine E-Mail von Mark Lishman erhalten. Er arbeitet an einem Startup, das eine einfache Möglichkeit bietet, Online-Tutorials zu erstellen. Das Coole an diesem Produkt ist, dass Sie interaktive Tutorials erstellen und Teile Ihres Quellcodes hervorheben können, wenn der Betrachter Ihres Tutorials auf einen speziellen Link klickt. Das Produkt ist noch etwas grob, aber die Idee ist sehr interessant und hat mir geholfen, Online-Tutorials in einem neuen Licht zu sehen.

Was hast du diese Woche gelernt?

Teilen Sie Ihre Lernerfahrungen oder andere Kommentare im Kommentarbereich.