Extreme Agile Development?

What if we push all the agile practices to the extreme just like Extreme Programming does? What will extreme agile development look like?
If automated test is good, why not write acceptance criteria in automated test suites?If empowering the devs is good why not let them own the story too?
If close coordination between QA and Dev is good why not let them pair all the time?
If frequent and direct feedback from end users is good why not continuously deliver to them and collect feedback from them in an easy and automated way?

So maybe this is what extreme agile development process look like:

• Provide end users a way to easily submit their feedback to application's feedback database.


• Product manager(s) categorize user feedback into high level feature requests and prioritize them.


• Dev pair and QA work together (tripling) to design the detail user experience story for the high level feature request (together with the original end user feedback) and write the acceptance criteria in automated test suite such as cucumber.


• Product manager(s) reviews the implementation design and the cucumber tests. (optional)


• Dev pair develop the story to pass the automated test suites. During which if the test suites need to be changed, the QA will be pulled in.


• Continuously deliver code to end users - deploy code to production as frequent as possible.


• Product managers keep monitoring end user feed back and ensure that all team members being on target with their user experience design

Is this possible?

Introducing Collectr - my first flickr App

Alpha test: http://collectr.kailuowang.com/

What is Collectr?

Collectr is a web app that helps you, a flickr addicted, subscribe and explore flickr photos in a much more powerful and personalized way.

What's the vison of Collectr?

To achieve what flickr explore failed to achieve - an easy and free way to see more interesting pictures every day.

Why use Collectr?

• Centralized slide show
New photos from multiple sources will be displayed at a single slide show

• Personalized slide show
Collectr remembers your preference by recording your 'fave' action, so that when you have too many new photos from sources,
it will display first the photos from the stream swhose photos you fave the most in the past.

• Expendable Sources of Photos
With Collectr, not only can you subscribe to someone's upload stream, you can also subscribe to her favorites stream.
This way you can discover flickr artists that are discovered by your favorite flickr artists.
This is very important because it allows you to expand your list of sources of good photos.

• Slide show with the best possible image quality
Unlike many of the third party flickr websites, when the collectr slide show display photos, it will try find the version of the photos whose reslution fits your screen the most. Also, this slide show is tablet friendly with navigation keys on the sides and links using larger font.

• Easy share
You can share/backup your collections by exporting them into a backup file so that later you or other Collectr users can import it.

A couple of tips for RubyMine performance optimization

Set aside the IDE vs editor topic, one of the biggest complains about RubyMine is its performance. In a large project, without tweaking it a bit, RubyMine could be so sluggish that it becomes simply unusable. That's probably the #1 reason many RubyMine users ditch it and go back to simpler lightweight editor such as vim or TextMate. Well, there are actually a couple of things that can significantly impact the performance of RubyMine. With a little care, RubyMine can perform with an OK smoothness.
1) By default, RubyMine's jvm max heap size bound is set as 512MB, it's probably be enough if you are running it on a 32bit JDK, but on a 64bit JDK, it might be necessary to bump it up to 1024MB, since the 64bit uses twice as much memory. This will reduce the number of GC collection. Here is some guide on how.
2) More importantly, RubyMine index everything in your project to support text search/refactoring etc. So if you have some huge files that also get changed very often, such as log, spec reports, etc, it could be very expensive to have RubyMine indexing them all the time. Exclude them from RubyMine project structure is probably a good idea.
That's it. I think with a little love, RubyMine can still be a valid ruby development tool, especially for people who are used to JetBrian's IDEs.