sanklamm / sanklamm

There are two people in sanklamm’s collective.

Huffduffed (333)

  1. 028 New to Erlang | Mostly Erlang

    Download Link: https://mostlyerlang.files.wordpress.com/2014/02/028_new_to_erlang.mp3 Sponsor: Elixir Sips Chuck from Ruby Roges has some questions about Erlang and when it could help him in his projects. Zach, Justin and Kevin hope to respond to his questions about Erlang and give him something to think about in terms of development platforms. Panel Charles Max Wood (@cmaxwood) Justin Sheehy…

    https://mostlyerlang.com/2014/02/04/028-new-to-erlang/

    —Huffduffed by sanklamm

  2. 013 F# With Bryan Hunter | Mostly Erlang

    Download Link: http://zkessin.github.io/mostlyerlang/episodes/013_fsharp.mp3 Panel Bryan Hunter (@bryanhunter) Fred Hebert (@mononcqc) Yan Cui (@theburningmonk) Phillip Trelford (@ptrelford) Main Program Bryan Hunter: Which did you learn first Erlang or F#? What attracted you to Erlang? What attracted you to F#? Today you’re in the elevator with 5,000 Erlang developers. What’s your elevator pitch for F# to Erlang developers?…

    https://mostlyerlang.com/2013/08/29/013-f-with-bryan-hunter/

    —Huffduffed by sanklamm

  3. 005 When Not to Use Erlang | Mostly Erlang

    We apologize for the delay in posting this episode Panel Zachary Kessin (@zkessin) Justin Sheehey (@justinsheehy) Bryan Hunter (@bryan_hunter) Show notes to follow

    https://mostlyerlang.com/2013/05/30/005-when-not-to-use-erlang/

    —Huffduffed by sanklamm

  4. 004 Joe Armstrong | Mostly Erlang

    Panel Zachary Kessin @zkessin Ferd Hebert  @mononcqc Simon St Lawrence @simonstl Joe Armstrong @joeerl Links Q Library (Javascript) https://github.com/kriskowal/q Joe’s Blog  Coffee Machine Post: http://joearms.github.io/2013/04/05/concurrent-and-parallel-programming.html Learn You some Erlang : Zombies http://learnyousomeerlang.com/distribunomicon WireShark http://www.wireshark.org/ Chandler (joe’s github page)  http://chandlerproject.org/ Lua in Erlang   https://github.com/rvirding/luerl Prolog in Erlang  https://github.com/rvirding/erlog Ericson MME   http://www.ericsson.com/ourportfolio/products/sgsn-mme Opscode blog  http://www.opscode.com/ Picks 100 year Campfire: http://matt.me63.com/2013/05/14/keep-the-campfire-burning/ (Simon)…

    https://mostlyerlang.com/2013/05/21/43/

    —Huffduffed by sanklamm

  5. 002 Webmachine | Mostly Erlang

    Panel Zachary Kessin @zkessin Ferd Hebert  @mononcqc Simon St Lawrence @simonstl Justin Sheehy @justinsheehy Links Webmachine: https://github.com/basho/webmachine The Webmachine HTTP Diagram Idempotence Is Not a Medical Condition: http://queue.acm.org/detail.cfm?id=2187821 PATCH Method for HTTP: http://tools.ietf.org/html/rfc5789 High Performance Browser Networking - http://chimera.labs.oreilly.com/books/1230000000545  (free to read draft - explores HTTP, SPDY, WebSockets, WebRTC, etc.) http://mononcqc.tumblr.com/post/29930101229/laws-of-software-evolution   Lehman’s laws quick review Hyperglyph…

    https://mostlyerlang.com/2013/04/26/webmachine/

    —Huffduffed by sanklamm

  6. 001 Building Skynet | Mostly Erlang

    [audio http://zkessin.github.io/mostlyerlang/episodes/001_BuildingSkynet.mp3] Panel Zachary Kessin @zkessin Ferd Hebert  @mononcqc Simon St Lawrence @simonstl Justin Sheehy @justinsheehy Links Spanner Paper:  http://research.google.com/archive/spanner.html Nasa DSN: http://deepspace.jpl.nasa.gov/dsn/ Learn You Some Erlang: http://learnyousomeerlang.com/ Introducing Erlang: http://shop.oreilly.com/product/0636920025818.do Building Web Applications with Erlang: http://shop.oreilly.com/product/0636920021452.do LFE (Lisp Flavored Erlang): http://lfe.github.io/ Iron Dome: http://www.youtube.com/watch?v=aoCz6Duo15s

    https://mostlyerlang.com/2013/04/19/building-skynet/

    —Huffduffed by sanklamm

  7. CRE209 Das Linux System | CRE: Technik, Kultur, Gesellschaft

    Vielen Dank für die Folge, die bei mir gleich mehrere Nerven getroffen hat.

    Ich verwende Lennarts Schöpfungen sowohl auf dem Desktop als auch auf dem Server und weis die Features und

    die hohen Ansprüche, die offensichtlich bei der Umsetzung angesetzt werden sehr zu schätzen. Avahi ist super, an Pulseaudio mag ich vor allem die Netzwerk-Features und auch Systemd bietet viel interessantes.

    Trotzdem gehörte ich grad bei Pulseaudio und Systemd klar zu den Skeptikern, da vor Allem Pulseaudio für mich Probleme mit sich brachte, die ich davor nicht hatte.

    Die Situation ist bei mir etwas speziell, da ich blind und somit auf einen Screenreader angewiesen bin um mit dem Computer zu arbeiten. Im Desktopbereich ist Orca der Screenreader für Linux. Orca ist ein Gnome-Projekt und ist auf ein Accessibility-API angewiesen, um überhaupt die nötigen Informationen vom System zu bekommen. Das Anwendungs-Toolkit (GTK, Qt, etc.) wiederum muß die nötigen Informationen über das Accessibility-API (AT-SPI) bereitstellen. Das hat zur Folge, daß beispielsweise Programme die SDL für das UI verwenden überhaupt nicht zugänglich sind, weil SDL keine Anbindung an AT-SPI2 beinhaltet. Bei Qt hat sich die Situation in den letzten Jahren sehr verbessert, vorher waren auch Qt-Anwendungen nicht zugänglich.

    Jedenfalls gibt es immer noch reichlich graphische Programme, die ich nur mit Einschränkungen oder gar nicht bedienen kann, daher verbringe ich noch immer sehr viel Zeit auf Text-Terminals. Ein graphisches Terminal ist kein Ersatz, da graphische Screenreader nur extrem eingeschränkt für das arbeiten mit textbasierten Programmen taugen. Da ein graphischer Screenreader auf der Textkonsole nicht einsetzbar ist, verwende ich dafür noch einen zweiten Screenreader parallel, der nur auf der Textkonsole aktiv ist, mir wiederum aber auf dem graphischen Desktop nix bringt. Im Textmodus gibt es kein API, der Screenreader holt sich die Informationen über die entsprechenden VT-Schnittstellen des Kernels, was leider als Root passieren muß, zumindest hat noch niemand einen Weg mit weniger privilegierten Rechten gefunden. Das Teil muß also als Root laufen. Mit Pulseaudio gab es nun plötzlich das Problem, daß als Root keine Audioausgabe und somit keine Sprachausgabe mehr möglich war. Vom Sicherheitsaspekt her mag das wohl begründet sein, aber von einem sicheren Rechner ohne Sprachausgabe hab ich auch nix. Es gibt verschiedene Workarounds, aber eine zufriedenstellende Lösung für das Problem hab ich bislang noch nicht. Generell ist die Einschränkung, daß lediglich ein User gleichzeitig

    die Hoheit über die Soundkarte hat, an vielen Stellen ein Problem für mich. Pulseaudio bringt tolle Features und klare Vorteile mit, für mich ist das System dadurch jedoch wesentlich komplizierter handhabbar geworden als nur mit ALSA – und Streams mixen konnte das auch schon.

    Auf Systemd hab ich gewechselt, als Gnome es verlangt hat, was sich damals schon nach Zwangsmaßnahme angefühlt hat. Lennart hat es auf den Punkt gebracht, die Bootkonfiguration ist etwas, womit man sich aus der Notwendigkeit heraus beschäftigt und froh ist, wenn alles läuft, da möchte man sich ungerne “grundlos” neu reinarbeiten und nimmt dann auch die Ausweitung vom eigentlichen Boot-Management aufs Loggin, Networking, usw. als Vereinnahmung wahr.

    Emotional reagiere ich generell auf die Desktopisierung, also das “moderne” Konzepte oder Schnittstellen gefühlt fast ausschließlich für den Einsatz mit dem graphischen Desktop konzipiert werden. Das Pairing mit einem Bluetooth-Device war bis vor nicht all zu langer Zeit außerhalb von graphischen Umgebungen ein Graus und auch der Session-Bus von Dbus setzt ein laufendes X voraus. Von Gnupg2 und Pinentry mag ich gar nicht anfangen. Und wenn ich dann unter anderem von Lennart auf der Pulseaudio-Mailing-Liste lese, daß Text-Terminals eh noch nur maximal zum Debugging eingesetzt werden sollten und eigentlich per Default deaktiviert gehören, kommen halt im ersten Moment auch Systemd und Pulseaudio gleich in diese Schublade. Im Fall von Systemd waren meine Befürchtungen zum Glück nicht gerechtfertigt und

    bei Pulseaudio sind die Einschränkungen außerhalb der X-Umgebung technisch bedingt und die Steuerung ist immerhin grundsätzlich möglich.

    Der nächste Brocken wird wohl Wayland werden, da es bei den vielen Zöpfen die abgeschnitten werden gleich auch die erwischt, die für das Accessibility-Framework benötigt werden. Es gibt Entwickler in dem Bereich, die sich wirklich ins Zeug legen, aber deren Zahl ist leider überschaubar. Mit den 95 Prozent, für die es problemlos funktioniert, ist mir nicht geholfen, wenn ich zu den anderen 5 gehöre.

    Im Schlimmsten Fall werden die ersten Distris die Wayland als Default ausliefern erst mal überhaupt nicht zugänglich sein. Das fühlt sich dann schon manchmal wie ein frustrierender Kampf gegen Windmühlen an.

    Gerade darum bin ich froh, wenn ich wenigstens nachvollziehbare und überzeugende Erklärungen für solche Umstellungen habe, dafür vielen Dank an Lennart und Tim.

    http://cre.fm/cre209-das-linux-system

    —Huffduffed by sanklamm

  8. CRE167 node.js | CRE: Technik, Kultur, Gesellschaft

    Nette Folge, dachte eigentlicht etwas über ein weiteres JS-Framework zu erfahren, aber Server-JS ist auch mal ‘n interessantes Thema.

    Was mich ein bisschen wundert ist, dass ursprünglich keine DOM-Unterstützung existierte!? Das finde ich seltsam, denn… ich will nicht sagen “im Wesentlichen” aber meistens generiert man mit Web-Servern ja irgendwie Websites in HTML oder XHTML oder sowas (klar, nicht nur…).

    Da böte es sich imho super an, wenn ich ein DOM habe und bei reinkommenden Events eben irgendein Element in mein DOM hängen kann und wenn ich mit allem fertig bin serialisiere ich den Kram und schick’s dem Browser.

    Wenn man das noch asynchron hinbekäme um so besser, aber was ich eben meine ist: Man baut Webseiten, Webseiten haben ein DOM, aber man baut kein DOM sondern Strings!? (Derzeit noch). Komisch :)

    Die restlichen 30 Minuten höre ich dann, wenn ich von der Arbeit heim komme :)

    http://cre.fm/cre167-nodejs

    —Huffduffed by sanklamm

  9. CRE163 Ruby und Rails | CRE: Technik, Kultur, Gesellschaft

    Hihi, typischer Java-Kommentar (aber.. aber.. Refactoring!).

    Ein bisschen schade finde ich, dass Martin in dieser Episode etwas durcheinander wirkt und daher manchmal sehr unverständlich/unvollständig erklärt, vermutlich die Aufregung. Aber wüsste ich nicht, wie einfach, schnell und schön Rails-Entwicklung ist, wäre ich nun erstmal etwas abgeschreckt.

    Was mir insbesondere gefehlt hat (oder hab ich es überhört) war der Hinweis darauf, dass während der Entwicklung viele z.B. in der Java-Welt immer noch häufig notwendige Schritte (insbesondere Server-Neustart nach Änderungen in Views) entfallen, was eine Menge Frust und Wartezeit aus der Entwicklung nimmt.

    Manches hätte vielleicht einfacher mit Beispielen erklärt werden können:

    – Foreign Key? Ein Verweis einer Tabelle auf eine andere, z.B. könnte die Calendar Tabelle eine Spalte “userid” haben, die auf die “users” Tabelle verweist. Rails weiß bei dieser Bezeichnungs-Konvention dann mit der “hasmany :calendars” Direktive im User Model automatisch, wie es für einen gegebenen “user” über den Aufruf “user.calendars” an die Liste der zum User gehörigen Kalender kommt.

    – REST in Rails? Mappt die CRUD (Create, Read, Update, Delete) Methoden für ein Model (allgemein Ressource genannt) auf die HTTP-Methoden POST, GET, PUT und DELETE. Macht Rails quasi automatisch indem es die folgenden URLs anlegt:

    POST /users

    –> controller “users”, methode “create”

    GET

    /users

    –> controller “users”, methode “index”

    GET

    /users/:id

    –> controller “users”, methode “show”

    PUT

    /users/:id

    –> controller “users”, methode “update”

    DELETE /users/:id –> controller “users”, methode “destroy”

    Zugegeben, das ist textuell einfacher erklärt, als übers Micro…

    Eine ganz wichtige Ressource für den Einstieg und die Vertiefung fehlte: http://guides.rubyonrails.org/

    BDD (Behavior Driven Development) – z.B. mit Cucumber – wäre übrigens fast schon mal einen eigenen CRE wert.

    http://cre.fm/cre163-ruby-und-rails

    —Huffduffed by sanklamm

  10. CRE146 JavaScript | CRE: Technik, Kultur, Gesellschaft

    Da ich selbst nochmal was bestimmtes Nachhören wollte, hat es sich ergeben, dass ich ein grobes Inhaltsverzeichnis dieser Folge erstellt habe, welches ich natürlich niemandem vorenthalten möchte! Kein Anspruch auf Richtigkeit oder Vollständigkeit! (Hoffe die Formatierung passt bei diesem Formular) :-)

    00:04:50 Herkunft des Namens “JavaScript”, hat nix mit Java zu tun

    => Fehler: Eindruck JavaScript sei “kleiner Bruder” von Java

    00:06:40 Microsoft-Version: JScript, Browser-Wars

    00:09:00 Standardisierung durch ECMA => ECMAScript

    00:11:30 Mozilla am experimentierfreudigsten => mehr Features als andere,

    die lieber einen Speedwar machen

    00:12:20 API zum Browser: DOM Unterschiede zu Flash ActionScript

    00:15:30 Das Absehbare Ende von Flash / ActionScript

    00:17:45 IE6 ist out, wie auch Flash

    00:18:30 JSConf (jährliche JavaScript-Konferenz)

    00:20:40 CRE125: CouchDB

    00:21:40 die erste JavaScript-Implementierung Spidermonkey, Tracemonkey

    (tracing JIT-Compiler) (JIT=Just In Time)

    00:24:00 Performance-Vergleich Tracemonkey

    Spidermonkey, hoher Aufwand

    JavaScript schneller zu machen, Vergleich Geschwindigkeit JavaScript,

    Java, C, Pywhon, Perl, …

    00:25:50 Adobe und deren Position zu JavaScript (haben Tracemonkey gespendet),

    Adobe nun unter Druck da Flash verschwindet, könnten aber relativ

    einfach auf JavaScript umsteigen indem sie swf nach JavaScript & HTML

    kompilieren

    00:28:10 weitere JavaScript-Implementierungen:

    apple (SquirrelFish) und

    google (V8) sind im Speedwar

    00:30:42 Unterschiede, Feature-Implementierungs-Policies: mozilla probiert

    viel aus, apple baut nur standardisierte Sachen ein, google baut

    nur Sachen ein die apple eingebaut hat

    00:32:40 ECMA arbeitet sehr langsam => andere deFacto-Standards müssen

    aufgenommen werden damit man weiterkommt

    00:33:35 Rhino, Server Side JavaScript

    00:37:20 node.js

    00:43:00 URL-Shortener, weiter node.js: läuft zwar stabil, aber API ist nicht

    fixiert sondern ändert sich sehr häufig

    00:47:35 narwhal und seine Implementierungen (Rhino, V8, …); blocking

    00:48:18 Überblick Benutzung JavaScript auf Clientseite; wie sieht es auf

    ServerSeite aus, wo man doch auch etwas mehr braucht? Was fehlt noch?

    00:51:25 AMQP (Advances Message Queuing Protocol)

    00:53:05 Programmiersprachen zur Realisierung von Webanwendungen: Ruby on Rails,

    vergleichbare Ansätze in JavaScript? Einschränkungen von Rails im

    Vergleich zu event-basierten Ansätzen wie node.js

    00:56:55 die JavaScript-Revolution durch AJAX (XMLHttp-Request und warum es

    eigentlich Http-Request heißen sollte)

    00:59:45 das Box-Model vom IE6

    01:00:45 prototype.js und wie sie die DOM-API repariert (vereinheitlicht)

    haben

    01:04:30 welche Fehler prototype.js gemacht hat und was man daraus gelernt hat

    01:06:20 JavaScript im Detail: Unterschied zu den meisten anderen: Objektmodell

    mit Prototypen (Vergleich mit Klassenmodell)

    01:09:38 Grundlagen (Urschleim): Objekte, Funktionen, Arrays

    01:12:50 JavaScript im Kern eine funktionale Programmiersprache, Funktionen

    sind vollwetige Objekte, Objekterzeugung mit Funktionen, das

    Prototype-Property um Speicher zu sparen, Prototype-Inheritance-Chain,

    Vererbung

    01:17:42 Beispiel für Objekt-Hierarchie-Modell: Hund

    01:20:00 klassenmodell-mässig programmieren in JavaScript (möglich, muss man

    halt selber bauen oder ein entsprechendes Framework nutzen)

    01:21:25 historische Gründe für das leichtgewichtige, prototypische, abstrakte

    Programmiermodell in JavaScript

    01:22:00 andere prototypen-basierte Programmiersprachen

    01:23:00 ActionScript auch so, nur ActionScript 3 ist nun klassenbasiert

    01:23:44 was gibt es noch ausser Dynamik, Funktionalität, Prototypen sonst noch?

    Scoping, “Namespace-Simulation”, Closures (anonyme Funktionen)

    01:27:20 Zusammenfassung: dynamisch (=> Performanceprobleme), funktional,

    CRE84: LISP, CRE31: Programmiersprachen und Dylan (closures),

    JavasScript sowohl leichtgewichtig als auch flexibel

    01:29:35 Joose JavaScript Meta-Object System: Klassen mit Namen,

    Instanzvariablen, Methoden; Vererbung, Traits (Mix-In + Interface),

    aspektorientierte Programmierung, eigene Meta-Klassen (z.B. für

    Mehrfach-Vererbung oder für Custom-Events)

    01:33:27 JavaScript-Frameworks & Programmiermodelle: Zusammenfassung: von

    (X)HttpRequest zu Ajax, JavaScript, JSON als Datenformat (lässt

    sich mit eval auswerten, da vollwertiges JavaScript-Literal), besser

    geeignet für Objekt-Abbildung von Programmen als XML

    01:37:07 “kulturelle Auswirkungen” von Ajax: Client wurde neu entdeckt

    01:39:30 wie ging es weiter nach prototype.js? Welche Lehren wurden gezogen?

    JQuery (DOM-Manipulation), DOM-Operationen sind eine Art

    Mengenoperationen in CSS-Syntax, Dojo Toolkit

    01:45:00 YUI (Yahoo User Interface Library)

    01:46:50 weitere Frameworks: SproutCore (für single page applications),

    Cappuccino & Objective-J

    01:50:10 wohin geht der Weg: Webanwendungen die sich klassisch als indizier-

    und googlebare Seiten darstellen vs. vollständige Anwendung im Web?

    Je nachdem macht beides Sinn

    01:51:21 GWT (Google Web Toolkit)

    01:51:50 wo geht die Reise hin mit JavaScript? Im mobilen Bereich: Palm-WebOS,

    Android, Chrome OS, alles ist Web-Anwendung, Phone GAP

    01:55:35 Zukunft auf dem Desktop? Google vorne weg, Anwendungsentwicklung im

    Browser, Rails

    01:57:30 klassische Fragen & Bedenken von Programmierern im Bezug auf JavaScript

    schlechter Ruf, dynamische vs. statische Typisierung, Objektmodell

    01:59:45 JavaScript: Write-Only-Programmiersprache (noch schlimmer als Perl)

    wegen der vielen verschiedenen, zueinenader inkompatiblen Frameworks

    Ruby dagegen hohen Re-Use-Value, Versuch CommonJS (wie CommonLisp),

    kein Repo wie CPAN verfügbar (JSAN setzt sich nicht durch)

    02:04:10 es gibt keinen “benevolent dictator” der die Richtung vorgibt

    => es muss sich in der Community herausbilden, verschiedene Ansätze

    02:06:28 JavaScript Ladezeiten-Optimierung im Browser

    02:09:40 Werkzeuge & Ressourcen: Texteditoren, Google Closure Compiler

    & Type Annotations (helfen dem Compiler bei der Optimierung, vgl.

    tracing JIT), Firebug, Profiling Tools (zur Performance-Optimierung)

    02:14:15 Was ist für den Einstieg ins Thema alles geeignet?

    http://cre.fm/cre146-javascript

    —Huffduffed by sanklamm

Page 1 of 34Older