agenda:a0512:mitschrift

Allgemeines / Theorie / "warum will man Continuous Integration / Full Stack" [Froh]

6 stages of debugging: http://www.bash.org/?950581
Tsung: Verteilter Test-Client http://tsung.erlang-projects.org/
Flo Detig: Test-Driven Design treibt sauberes Design / saubere API
- dadurch daß man die Nutzung des APIs zuerst hinschreibt kann man das „richtig“ machen, bevor man es ausimplementiert
- gute Erfahrung mit Coding Dojo
Kommunikationsproblem bei fragmentierten Teams: (nur) wenn sich mehrere in sich nähere Untergruppen bilden
Froh: Videokonferenz hilft (psychologisch) gut bei der Fernkommunikation, man hat mehr Vorstellung vom „Zustand“ der Gegenseite

JavaScript Packaging: Lars: [de facto] Standard „AMD“, aus http://www.commonjs.org/
JavaScript Mocking für Unit-Tests: JSMock http://jsmock.sourceforge.net/ ungünstig in asynchroner Umgebung; mocha http://visionmedia.github.com/mocha/ dort besser
Continuous Testing mit „grunt watch“ (von grunt, https://github.com/cowboy/grunt )
Testansatz: Edge-Cases durch Codeanalyse automatisch ermitteln / testen
- z.B. Pex für .NET: http://research.microsoft.com/en-us/projects/pex/

slightly OT: CSS3 ist sehr mächtig
JavaScript MVC- u.ä. Frameworks
- AngularJS http://angularjs.org/
- RailwayJS http://railwayjs.com/
- Tower.js http://towerjs.org/
- ↔ Ruby on Rails http://rubyonrails.org/
Wicket http://wicket.apache.org/ (gängige Lösung für „Web mit Logik“) braucht Templates, die by concept nicht „Designer-safe“ sind
Idempotente Templates
Flo hat Selenium_WebDriverJS selbst für npm packaged, damit es für die CI auf travis-ci.org bequem zur Verfügung steht
Problem: Synchrones API für WebDriverJS gewünscht