Am vorletzten Januarwochenende hat sich das Casualcoding-Team (Gruppenfotos!) in Flos Küche getroffen und einen Hackathon veranstaltet. Dabei entstand Podcast Profile, eine Website, auf der man zeigen kann, welche Podcasts man hört.
Ich fand Blogposts, in denen Leute erklären, welche Podcast sie warum hören, immer sehrinteressant, aber ich dachte mir, dass eine einheitliche Lösung, basierend auf dem OPML-Export jedes Podcast-Clients, netter sein könnte und man im nächsten Schritt mit den Daten vielleicht irgendwann vernünftiges Stöbern ermöglicht. Die Idee geisterte also schon ein paar Jahre bei mir herum, aber ich kam nie dazu, sie umzusetzen.
Bis Stöbern kamen wir am Wochenende natürlich nicht, aber die grundlegende Funktionalität steht (in den letzten Wochen fand nur etwas Maintenance statt).
Ich habe vor ein paar Tagen einen Prototyp eines iOS-Keyboards gebaut, das für mich persönlich zu einem gewissen Grad WhatsApp und andere Nachrichten-Apps ohne Mac-Gegenstück fixt.
Man wechselt in das Keyboard, verbindet sich mit einem Mac, der sich im gleichen WLAN befindet, und kann nun von dort tippen. Aber:
„Send to iOS Device“ im Mac-Fenster bedeutet tatsächlich nur „ins iOS-Textfeld eintragen“, weil man den „Send“-Button in WhatsApp nicht vom Keyboard aus bedienen kann.
Baue ich jetzt Verschlüsselung ein, und wenn ja, welche? Derzeit schicke ich Klartext-Nachrichten per Websocket hin und her.
Will das irgendjemand außer mir (und Flo, von dem die Idee ursprünglich kam) haben? Ich selbst will es ja auch nur sehr selten haben, weil ich die allermeiste Zeit iMessage benutze, und vielleicht reicht dann auch Pushbullet und Copy & Paste.
So darf das natürlich nicht in den App Store, zum Beispiel weil es ohne Netzwerk keine Funktion hat (25.5), also müsste ich noch ein „normales“ Keyboard außenrum einbauen, das natürlich nicht so gut sein kann wie das Standard-Keyboard, und darauf habe ich gerade gar keine Lust.
Facebook is an important communication tool to me. Most of my fellow students don’t use iMessage or Twitter DMs, so we talk on Facebook. However, I seem not to be able to just check my messages on Facebook. Instead, I wind up scrolling through the News Feed for a couple of minutes each time I visit Facebook in the browser. I recently looked at about 30 News Feed posts in detail and discovered these three things:
I didn’t care about any of the posts that described activities on Facebook. It doesn’t matter to me if $friend changed their profile picture or liked someone else’s status update.
I was interested in two link posts but I had already seen the exact same links on Twitter hours earlier.
People tend to create albums of mediocre photos on Facebook while they only post their best on Instagram. Many of my Facebook friends have Instagram accounts and I already follow the ones I’m interested in.
I concluded that I don’t need to read the News Feed, so I wrote a custom stylesheet that hides it. This is the result:
I’ve been using “Quiet Facebook” for a week now and I’m happy with it, so I put the CSS on GitHub. I just embed the stylesheet via Safari’s settings but someone could certainly build browser extensions that load the stylesheet from raw.github.com and toggle it when the user clicks a button. Feel free to submit pull requests (or suggest a better name for the whole thing)!
Diesen Beitrag habe ich ursprünglich für Daniel geschrieben, weil ich ihm meinen Lösungsweg für Aufgabe 18 von Project Euler erklären wollte. Nun, etwa zehn Minuten später, veröffentliche ich ihn auf meinem Blog.
Wir suchen die maximale Summe eines Pfades durch den Graphen. Der Pfad soll beim Wurzelknoten starten und von dort aus nach ganz unten führen. Bei diesem kleinen Graphen sieht das folgendermaßen aus:
Der rot markierte Pfad ist der Pfad mit der maximalen Summe: 3 + 7 + 4 + 9 = 23
Nun ergänzen wir unseren Graphen um eine weitere Ebene von Knoten.
Um nun den Pfad mit der maximalen Summe zu finden, müssen wir nicht die Summen aller möglichen Pfade bis zu den Knoten in der untersten Ebene neu berechnen. Die Summe des rot markierten Pfads kennen wir schon, und wir können sie weiterverwenden, denn Teilpfade eines Pfades mit maximaler Summe zwischen zwei Knoten sind ebenfalls Pfade mit maximaler Summe (Das bedeutet nicht, dass der rote Pfad Teilpfad jedes maximalen Pfades von der Wurzel bis zur untersten Ebene ist!). Diese Beziehung veranschaulichen wir uns wie folgt:
Sei der rote Pfad wieder der maximale Pfad vom Wurzelknoten bis zum dritten Knoten von links in der untersten Ebene (Knoten [5, 3]). Dann kann es keinen (hier blau markierten) Pfad geben, der eine größere Summe erzeugt als der rote Teilpfad daneben. Der Pfad, der von [2, 1] bis [5, 3] die größte Summe erzeugt, muss der rote Pfad sein, denn sonst wäre der rote Pfad vom Wurzelknoten bis [5, 3] nicht mehr der maximale Pfad (sondern der Pfad, der den blauen Teilpfad enthält; Beweis durch Widerspruch, as you do).
Weil wir nur an der maximalen Summe interessiert sind, merken wir uns nun keine Pfade mehr, sondern einfach für jeden Knoten die maximale Summe, die bis zu ihm erreicht werden kann. In unserem Graphen, den wir um eine Ebene ergänzt haben, sind das folgende Summen: (rechnet ruhig selbst nach!)
Um nun für die nächste Zeile die maximal erreichbaren Summen zu berechnen, müssen wir für jeden Knoten höchstens zwei Additionen durchführen (für die Knoten ganz links und rechts nur eine) und das größere Ergebnis speichern.
20 + 9 = 29, max(20 + 4, 19 + 4) = 24, …
Die maximale Pfadsumme im ergänzten Graphen ist also 29.
