Anselm, Hans, Peter und Stefan versammelten sich in vorösterlicher Stimmung um in Eintracht mal wieder festzustellen, wie kaputt doch alles ist.
Schaunotizen
- [00:00:12] That’s so fetch!
- Jake Archibald verteidigt die unter Beschuss geratene Fetch-API. Fetch soll als Ersatz für das alterwürdige XHR dienen, wird aber unter anderem kritisert, weil man laufende Requests (noch) nicht abbrechen kann. Man diskutiert darüber und denkt über abbrechbare Promises nach, was Peter aufs heftigste kritisiert. Streams wärend vielleicht sinnvoller. Während das unfertige Fetch bereits in neue Noch-Nicht-Standards wie Service Worker integriert wird, Object.observe() ziemlich kaputt ist und asynchrone Funktionen (mit dem gleichen Nichtabbrechbarkeits-Problem wie Fetch) dank BabelJS bereits verwendet werden diskutieren wir, ob heutzutage nicht zu viel halbgares Zeug im Browser landet.
- [00:32:20] Zentralisierte dezentrale Versionskontrolle
- In der Woche vor der Aufnahme dieser Revision war Github tagelang aufgrund von DDOS-Angriffen kaum zu erreichen. In Folge dessen war Bower kaputt, manche Builds funktionieren nicht – wir berichten von unseren Erfahrungen und machen uns Gedanken über mögliche Abhilfen. Man kann sich zwar ein eigenes Zentralrepository stricken (z.B. mit GitHub Enterprise oder GitLab), muss da aber das Für und Wider sorgfältig abwägen.
[00:54:35] Keine Schaunotizen
- Gulp Cheat Sheet
- Nomen est omen.
- GitHub TODO > Issue Hook
- Git-Hook, der TODO-Kommentare in Github-Issues verwandelt.
- So Coded 2015
- Ist eine Konferenz, müsst ihr hin.
- Front Trends Ticket von Hans
- Hans hat Tickets zur Front-Trends 2015 übrig und will sie loswerden.
Kommentare
Philipp Nowinski #
Geschrieben am 9.04.2015 um 11:33
Abgesehen von einem npm install das ich zwei mal ausführen musste und den rants auf Twitter, habe ich von der ganzen GitHub Nummer tatsächlich nichts mitbekommen. Wir hosten unseren gesamten Code mit GitLab auf unserem eigenen Server und sind da somit schon sehr autark. Ich habe in früheren Jobs auch ausschließlich mit GitHub und BitBucket gearbeitet und muss sagen, dass ich was den Workflow und die Benutzbarkeit angeht so gut wie gar keine Probleme hatte beim Umstieg. Wenn man GitHub oder BitBucket kapiert hat, dann kommt man auch mit GitLab sehr schnell klar. Merge Requests, Issue Verwaltung, etc. funktionieren super und ermöglichen letztlich die gleiche Arbeitsweise die man aus den SaaS Systemen kennt. Und der Wartungsaufwand ist auch relativ überschaubar.
Man sollte sich allerdings bewusst machen, dass Alternativen wie GitLab auch ein paar ganz andere Nachteile mit sich bringen. Da wir für alle Projekte den gleichen Workflow haben wollen, hosten wir auch alle unsere OpenSource Projekte auf GitLab. Dadurch wird natürlich die Barriere für Contributions etwas größer, da man sich wieder extra einen weiteren Account zulegen muss um Issues oder Merge Requests zu öffnen. Einen GitHub account haben dagegen ja sowieso schon alle. Gleichzeitig ist unser ganzes Ökosystem auch sehr auf die Verwendung von GitHub getrimmt. Unser Yeoman Generator wird bspw. nicht auf yeoman.io gelistet, weil sich da teilweise auf Infos verlassen wird die die GitHub API voraussetzen (lässt sich natürlich was gegen tun, der Krempel ist ja auch OpenSource, but time – you know :).
Services wie TravisCI funktionieren auch wieder nur mit GitHub – auch da muss man sich wieder nach Alternativen umsehen..
Hat eben alles seine Vor- und Nachteile, wobei letztere für uns aktuell nicht überwiegen und die Unabhängigkeit die wir durch GitLab haben ist schon sehr angenehm. Mann sollte sich allerdings bewusst sein, dass gerade was OpenSource angeht Dezentralisierung auch ihre Schattenseiten, bzw. wieder andere Problemchen hat.
Anselm Hannemann #
Geschrieben am 9.04.2015 um 13:56
Danke für deinen Kommentar, sehr interessant zu lesen. Was nutzt ihr denn dann für einen CI Service? Wäre es eine Möglichkeit per githook den Code von eurer gitlab instanz zu github zu pushen (und vice versa) für Open Source Projekte?
Philipp Nowinski #
Geschrieben am 10.04.2015 um 13:04
Aktuell gar keinen :-D Ist aber ein Problem das wir gerade angehen. Es gibt GitLab CI das sich ziemlich gut integrieren lässt. Sowas kann man also tatsächlich mit hauseigenen Mitteln sehr gut nachrüsten.
Die Lösung mit einem githook könnte funktionieren, trotzdem müsste man aber noch ein Auge auf beide Instanzen haben, bzw. auch Issues, etc. duplizieren. Alles etwas redundant und vermutlich letztlich den Aufwand nicht wert. Das Problem mit den vielen Accounts hat man ja auch an vielen anderen Stellen im Web, was letztlich vermutlich auch ein Grund dafür ist, dass man doch vieles zentralisiert. Könnte mir vorstellen, dass sich das Problem irgendwann erledigt, wenn sich vlt. doch Alternativen wie IndieAuth mal durchsetzen.
Einen riesigen Vorteil den man mit GitLab und Co noch mitbekommt, besteht übrigens im Umgang mit paranoiden Kunden. Gerade bei größeren Projekten kommt es ja vor, dass es nicht in Frage kommt Code auf einem fremden Server in Amerika zu hosten (was GitHub je letztlich macht). Ich habe bspw. mal ein Projekt für eine deutsche Bank gehabt, da wäre das ein No-Go gewesen. Für das Projekt musste ich mir dann einen ganz neuen Workflow aneignen, weil ich eben meine bekannten Dienste nicht nutzen konnte. Wenn der Code sowieso schon auf dem eigenen Server (oder zumindest einem über den man Kontrolle hat) liegt ist das dann gar kein Thema mehr.
Christoph #
Geschrieben am 10.04.2015 um 07:50
Zu Github selbst: Also ich habe vom Ausfall auch nur auf Twitter mitbekommen, obwohl ich auf Github durchaus eifrig benutzt hatte. Ich verwende die Repos grundsätzlich per SSH. Ich hatte schon bei früheren DDOS, dass SSH dann zuverlässiger funktioniert als HTTP.
Zu eigener Infrastruktur: Ja, ich mache das fur mich selbst für meine Hobby-Projekte. Eigene Gitlab-Instanz, alle Open-Source-Projekte von denen ich abhängig bin werden lokal geklont (per Skripte, d.h. fast kein Wartungsaufwand). Meine wesentliche Sorge ist dabei weniger, dass Github mal ausfällt, sondern dass ein Projekt mal einfach dicht macht und verschwindet (gerne mal nach „FoundationDB“ googeln).
Beruflich wenn man bei einem Kunden als Dienstleister unterwegs ist: Total unrealistisch, vor allem bei grösseren Kunden. Server finden, 2 Wochen auf eine statische IP warten… Dann will man evtl. verteilt entwickeln, dann gibt’s da ewige Diskussionen mit DMZ und Firewall usw. Dann hat der Kunde eine reine Windows-Infrastruktur mit 0 Linux Knowledge,d.h. die Admins weigern sich selbst für eine Linux-VM die Verantwortung zu übernehmen. Dann kriegt man das Linux nicht gescheit ins Active-Directory integriert. Alles schon in verschiedensten Facetten mitgemacht.
Ich hab dann schonmal einen Mac Mini mit zum Kunden geschleppt und das war dann der Team-Server.
Ich verstehe da jeden, der im Projekt das verwendet, was da bzw. irgendwie verfügbar ist – Hauptsache man geht der Unternehmensbürokratie aus dem Weg.
noch ein Christoph #
Geschrieben am 20.04.2015 um 09:50
Kurz zur Fetch-API:
Ich fände es etwas befremdlich, wenn die Funktion ein Objekt zurückliefern würde. Auf der anderen Seite hat Peter natürlich recht, dass man eine Abbruchmöglichkeit benötigt, diese aber tunlichst nicht in die Promise stopfen sollte.
Ich fände sowas ja simpel und logisch:
var r = new Request();
r.send(url);
r.abort();
So könnte man dem Request sogar bequem noch mehr Optionen übergeben – falls nötig.
Wer es gerne kurz hat:
new Request().send(url).then(foo);
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.