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…
sanklamm / sanklamm
There are two people in sanklamm’s collective.
Huffduffed (333)
-
-
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/
-
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/
-
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)…
-
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…
-
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
-
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.
-
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 :)
-
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.
-
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?
Page 1 of 34Older