DHH delivered a passionate, amusing diatribe against the development culture that demands that the programmer must be controlled. Hence the likes of strictly-typed languages, waterfall, throwing code over the wall, and all the resulting demoralization that goes along with it.
David asserted that freedom carries with it the potential to do great good as well as great evil.
I suddenly appreciate how special this Ruby community and culture is: because of our freedom, we all aspire to very high moral standards of opportunity, fair play, and nurture. Because this freedom to express yourself is a precious freedom indeed, I see many people in this community joyously giving themselves to preserve it. My church makes the same entreaties in its community, yet at this time they don't seem to come even close to this community's results.
RubyConf has been a refuge from the greater American atmosphere of distrust, cynicism, spinning, and unhappiness. Thank you all, I am very grateful.
LDAP, the Original No-SQL
My main takeaway from this talk is that LDAP has some special strengths that make it a good choice for some applications:
- Distributed
- Mature
- Asynchronous
- High-Performance
If the application has a high read-to-write ratio, the case for using LDAP as opposed to other "No-SQL" solutions is very good indeed.
Rubinius - What Have You Done for me Today?
The main goal for this Ruby variant is to leverage the Ruby language itself to implement the Ruby engine as much as possible.
Evan Phoenix has made a lot of progress since I last saw his presentation at Railsconf. Development has continued to take advantage of the "Ruby-ness": better than average benchmarking and profiling tools.
They are now working to be compatible with version 1.9.2. The future includes a Windows version and full concurrency.
MacRuby - why and how
Matt Aimonetti showed the latest version of the Ruby that can directly access the OS X objects in Cocoa. This make MacRuby a strong contender for implementing Mac applications.
To the question: when will it be available for iOS, Matt could only say that, aside from having to implement a garbage collector, there are no other technical issues. The real issue is whether Apple wants to support that capability.
Having used Smalltalk to learn the Windows API in the 1990's, I can only hope that Apple enables the same capability using MacRuby.
pie: the making of a DSL for simple games
I was tired of technical presentations and wanted to see what other Ruby efforts were going on. Here Sarah Allen testimonied about using Ruby to develop a simple DSL for an adventure game. What was interesting was her thought process and how checking out her early design ideas with others caused all of the "rewriting" to take place in the beginning when it was easy.
By taking it to children early, she gained valuable insight on what held their attention and what didn't. As expected, the childrens' ages mattered a lot.
I learned a lot about distributing early versions to the customer and how to benefit from their feedback.
Socalist Software Development
CJ Kihlbom is from Sweden and he admits he has a "socialist" point of view about developing i the Agile Ruby environment. Both amusing and insightful, he illustrated how seeing the opportunity glass "half-full" makes the Ruby community much more joyous and supportive. Among the software practices that are "socialist":
- Open source
- Pair programming
- Collaboration
The results of these practices are a large number of benefits:
* Flow
* Lessons distractions
* Camaraderie
* Helps w/ morale
* Work w/ people you like
* Better morale
* Stability
* Immunity from a developer hit by a bus ("bus number")
* Learning
* Apprenticeship
* Formal apprenticeship programs
* "Apprenticeship Patterns Guidance for the Aspiring Software Craftsman" O Reilly
* Mentoring
* Find someone we can inspire
* The teacher benefits as well as the student. Building the community strengthens us.
* Competition
* We're competing for the same talent and sometimes project. But really we're collaborating.
* See life as more than half full.
* Craftsman swap - competing consulting companies swapped developers for a week. They learned a lot from each other. This has been catching on.
* Obie: we are competing against consulting shops outside our community.
* Solidarity - So we can all grow and all improve.
One question was raised: how can we influence other software communities. For example, how could be influence a badly-run Java shop?
CJ makes me want to move to Sweden. ;-)
Automated Acceptance Testing, The Vietnam of Test Driven Development
Paul Wilson discussed how being unclear about the role and intent of different test strategies can get your development efforts bogged down in a never-ending slog of developing tests that don't really do you any good.
He focused on acceptance testing, which I realized I had confused w/ end-to-end testing, system testing or integration testing. They are not the same.
Acceptance specifications are a tool to flesh out unclear business requirements, and acceptance tests verify that the acceptance specifications are implemented. Hence, the acceptance test is built for the stake-holder and the terminology should reflect his vocabulary. Phrasing it in UI terms is unnecessary unless the UI is part of the acceptance specification itself; many times it's business rules. Hence test wherever the acceptance criteria are specified.
Matz's Keynote
I didn't take notes on Matz's presentation; rather I just listened. He talked about some upcoming features in Ruby 2.0: mainly features to reduce risk in monkey patching.
He also talked about "Rite" (Ruby Light) for embedded systems.
No comments:
Post a Comment