Guyub – Konsultan F/OSS

Josh Marinacci has announced that a new version of Leonardo Sketch is now available: Ruby Red Remixed. Leonardo is:

an open source vector drawing program named after the 15th century painter, but aimed for the 21st century user. It focuses on common tasks like mockups, prototyping, quick vector sketches, and presentations with a clean and consistent user interface. Leo is designed to be augmented by internet webservices and plugins created in several scripting languages.

Ruby Red Remixed is an interim release along the path to the next major Leonardo release, Glowing Green. The release was pushed out to make the recent progress on the Leonardo platform available to the community, within the context of a formal, stable version. Ruby Red Revisited includes “tons of bug fixes,” as well as many significant new features.

Key new features include:

• Infinite Canvas: The canvas will automatically grow as you add new objects to your drawing, even if they are beyond the edges of the document. Never run out of space again.
• Draggable guidelines: create guidelines by dragging them out from the ruler. Objects will snap to them automatically.
• Flickr upload support: Now you can upload your creations directly to Flickr as well as Twitter.
• Improved SVG Import: Lots of Illustrator symbols can be imported now by exporting them as SVG from Illustrator.
• New Rectangle UI: set rectangle corner radius and gradients directly with handles instead of with a palette. Much easier to use.
• Improved translations, including Japanese. Edit or create new translations easily using the debug menu in the preferences.

See Ruby Red Remixed for more details on the latest release, and visit the Leonardo Sketch home page for additional information about Leonardo, the underpinning Amino library, and more.

Java Today

JUG Chennai (India) celebrated the New Year with Java User Group – Chennai JUGChennai Unconference meet, 1st January 2011 at Adams Studio India:

Agenda: JVM Langauges ? Rajmahendra. * 10:10AM Program started with Devraj talk on Flex and Java; * 10:30AM Talk on JVM Langauges. Why JVM Languages, Idea behind, Pros and Cons,Different types of Languages and introduction Gorrvy, Scala, JRuby, Fantom. JavaFX Script; * 11:30AM Product of JVM Languages Grails,Gradle, Lift, Tales; * 12:30PM Grails and Grails Demo…

Alexis Moussine-Pouchkine reviews GlassFish in 2010 – What a year!

A lot has happened over the past 12 months! For the GlassFish team as for many people that came from Sun, it’s been a challenging, yet exciting year. It all started in January with…

Hildeberto Mendon?a has a 2011 New Year’s Resolution – CEJUG: Commitment with My Homeland -

I will start this post making a promise for 2011: I will write at least a post per week in this blog. Last year I could not keep that promise because it was one of the toughest years for me. 2010 was the year of conclusions and analysis of future steps. I was in the last year of the PhD and I spent almost the whole year thinking about what to do next…

Jean-Fran?ois Bonbhel announces JCertif 2011 the biggest Java Community Event in Central Africa ! Save the dates : 27-28 August 2011 -

Hi All, I’ll like to let you know the dates of JCertif 2011 the biggest Java Community Event in Africa. About 800+ attendees from many countries.
We will be happy to have you as Speaker on Developer Tools, Java, Open Source, Mobile Apps…or Business solutions. tools. Still hesitating to join JCertif 2011 ? See The past event : JCertif 2010 and this blog post…

Spotlights

Our latest java.net href="http://www.java.net/archive/spotlight">Spotlight is Micha Kops’ latest article, Enterprise Java Bean / EJB 3.1 Testing using Maven and embedded Glassfish:

Are you playing around with the shiny new 3.1 EJBs? Using Maven for your Java projects? Need an easy way to write and execute tests for your EJBs that depends on an Java Application Server? No problem using Maven Archetypes, the Maven EJB Plugin and the GlassFish embedded Application Container…

We’re also featuring JUG Chennai’s online newspaper, The JavaUserGroupChennai Daily. Recent headlines included New Year’s Eve wishes, a 2011 Android wish list, an article on SOA and MDM, and “Java EE Productivity Report 2011.”

Poll

Our current java.net poll asks Are you more optimistic today about Java’s future than you were a year ago? Voting will be open until Monday.

Subscriptions and Archives: You can subscribe to this blog using the java.net Editor’s Blog Feed. You can also subscribe to the Java Today RSS feed and the java.net blogs feed. You can find historical archives of what has appeared the front page of java.net in the java.net home page archive.

– Kevin Farnham

Twitter: @kevin_farnham

I was recently asked the question: Rails or Grails? I needed to summarize the key differences and industry sentiment. This was my response.

Before I make any subjective comments, let me start with some objective metrics I found:
http://www.expectationgap.com/posts/13

Now for my sentiments, I believe there are three key-dimensions: momentum, cloud-support, and people.

Momentum

Rails has the momentum as evidenced by the number of committers and plugins available. Many of the rockstar developers I know are all now developing in Rails, supporting that community, etc. The underlying Ruby language is incredibly expressive and allows dramatic productivity improvements. (write less code that can do more)

Only a handful of rockstars I know are developing on Grails. Typically, those developing on Grails are in enterprises or markets that are comfortable with Java and they want to continue leveraging that investment. (infrastructure, app servers, production support, etc.) Grails/Groovy does have the advantage that It can continue to leverage the output of the Java community (e.g. Spring). The better projects within the Java community are quickly integrated into Grails. For example, Grails uses Hibernate and Spring Security under the hood. As those projects improve, so will Grails.

Cloud Support

Rails and the cloud go hand in hand. Again, of the rockstar Rails developers I know, nearly all of them are running on virtual hardware owned and managed by others. Some of those let others manage the entire application server / platform (e.g. EngineYard). In contrast, all of the Grails development I know of is running on hardware (virtualized) owned and managed by the company itself in their own data centers (or rented space). As mentioned before, this may actually have been the motivating factor to select Grails. That is not to say that there isn’t cloud support for Grails. And now that VMWare owns SpringSource, this may change rapidly now that enterprises will have a trusted name (in VMWare) to host their Grails applications.

People

Rails has the momentum, more committers and potentially a more active community, but lets not fool ourselves — there is an army of labor out there to sling Java code. Offshore resources are readily available. The market for Rails is developing, but demand isn’t yet high enough to drive consulting companies to substantially increase their supply. As one of my good friends put it, “I’d love to develop in Ruby, but Java pays the bills.”. It is that sentiment, that has may limit the availability of resources.

However, even with readily available Java resources, that doesn’t guarantee the availability of Groovy resources. Both Grails and Rails require a slightly different mindset. If you take a Java developer and tell them to code in Groovy or Ruby, you’ll end up with Java code using Ruby/Groovy syntax. (not good) But at least the tooling, debugging practices, and libraries will all be familiar.

And just to stoke the fire…

Here are my entirely subjective scores:
Momentum: Rails (9) vs. Groovy (4)
Cloud Support: Rails (8) vs. Groovy( 5)
People: Rails (6) vs. Groovy (8)
—————————————————
Rails (23) vs. Groovy (17)

I’m switching from self-hosting Redmine to using Pivotal
Tracker for issue tracking on my Open Source projects.

• Rake
• FlexMock
• Builder
• TExp
• Given

All the projects are marked public so you should be able to view
the projects (and subscribe to an RSS feed) without actually signing
up for anything.

Did I miss anything?

All the open tickets should be migrated to Pivotal Tracker. If you
notice anything missing, let me know. Thanks.

String figure books are great resources, but they can be incredibly frustrating, too. Even if you?ve never tried to use one, it?s not hard to imagine having a string looped around your fingers, trying to hold the book open with your knee, and then discovering that the next step wraps onto the next page. You somehow need to turn the page without dropping any strings, and without closing or dropping the book.

This zoomed view also answers another one of the design forces behind Ekawada: ?I don?t understand what this step is telling me to do.? You don?t want to just add verbosity to the instructions, because more verbosity can actually hurt readabilty. (Just try reading these instructions for the ?Apache Door? figure, if you want a concrete example of what I mean.)

Thus, for steps where the instruction itself may be too terse, or ambiguous, I can use the zoomed view to add an illustration, or extra clarification, without bloating the instruction list. When you need more information, you can get at it easily, but for the common case, you can just scan the instruction list.

Tune in next time, when I?ll address another design force behind Ekawada: ?I remember learning this one figure as a kid, but can?t remember how to do it now.?

In my previous post, I talked a bit about one of the ?forces? that influenced the design of Ekawada, my as-yet-unreleased string figure catalog app for iOS. In this post, I want to talk about another of the forces that affected the app: ?What are some easy figures to do??

It?s not hard to imagine someone with little-to-no string figure experience being curious about the app, especially since it is free, and downloading it just to see what it?s all about. They might want to start with the easiest figure, just to see if it is something they could really learn. How should the application show this to them?

From the UI point of view, I took the easy way out: in the upper-left corner of the index is a toggle that lets you switch between ?ABC? (alphabetical) and ?123? (difficulty) orderings. I?m not best pleased with that solution, though: it?s not very self-explanatory. Expect that to change in a future version of Ekawada, after I have more opportunity to think about how best to present that.

(Ignore for now the blue button at the bottom?that?s there because the view is being filtered to show only the ?starter set? of figures. Tapping that button would return the view to the default of showing all installed figures.)

At any rate, toggling the view to ?123? gives you the figure list, sorted by difficulty (actually complexity?more on that shortly). The first figure in the list is the least complex, and the one at the bottom is the most complex.

Here?s where things get sticky, though. There is no formal, standardized way to evaluate a string figure and say how difficult it is. If you look at the various string figure web sites that try to categorize figures by difficulty, they all do it in a very subjective way. Sure, you may agree that the ?easy? ones are easier than the ?hard? ones, but you may also disagree with specific categorizations.

Anyway.

I wanted a way in Ekawada for people to order figures by difficulty, and thus I needed a way to objectively rate figures. After a bit of experimentation and observation, I came up with a system that considers what types of maneuvers are used in each step, and assigns a number to each type of maneuver. Then, the various maneuvers used in a figure are summed, and the figure is given a rating. ?Opening A?, for instance, is rated a 10, ?An Apache Door? is a 61, and ?Cat?s Cradle? is a whopping 196.

This gets to the point of ?complexity? versus ?difficulty?. Cat?s Cradle is rated at 196, but that?s because it is a complex figure (actually, series of figures), and is not actually very difficult. Thus, the rating still doesn?t necessarily tell you what is easy and what is hard, only what is simple and what is complicated.

Often, that?s good enough. I do plan to tweak the algorithm for computing the complexity after Ekawada is released, based on feedback from users. However, I think it?s good enough for version one as it is.

Next week, I?ll talk about how Ekawada balances another of the design forces on my list: ?I can?t hold a figure on my hands and turn pages at the same time.?

I was moving a Rails 2 app up to Rails 3 and, because I have PostgreSQL installed in a non-standard location on my server, I ran into problems when bundler was trying to install the pg gem. After fiddling about for a bit I ended up with this in my config/deploy.rb:

require 'bundler/capistrano'

task :set_config_for_pg_gem, :roles => [:app, :db] do
  run "cd #{current_path} && bundle config build.pg --with-pg-config=/usr/local/pgsql/bin/pg_config --no-rdoc --no-ri"
end

before "bundle:install", :set_config_for_pg_gem

$ cat ~/.bundle/config
---
BUNDLE_BUILD__PG: --with-pg-config=/usr/local/pgsql/bin/pg_config --no-rdoc --no-ri

To this day I still hear people complain that Rails has poor documentation. From where I?m sitting this seems far from the truth. Let me lay out the evidence piece by piece:

RailsTutorial.org

To learn Rails from scratch Michael Hartl recently finished his book Ruby on Rails Tutorial: Learn Rails by Example. The book teaches Rails 3 from the ground up and it?s available for FREE online. If you?d rather have a PDF or a book you can grab that as well (and he?s even working on some screencasts).

The source for the finalized book will be pushed to GitHub and released under a Creative Commons License shortly after Rails 3 is done. If you?d like to help translate the book to your language of choice, feel free to contact Michael and he?ll get in touch when it?s time to make it happen.

Rails Guides

If you?re not a Rails newbie don?t forget about the Rails Guides, which have been updated for Rails 3.

Rails API Docs

There are two main websites I use to do API lookups. The first is Rails Searchable API Doc, which has online and offline searchable documentation. The second is APIdock which is online only, but has the ability to comment and easily compare different versions of documentation.

Rails 3 Free Screencasts

If you?re more of a visual learner (like me) then there are plenty of free screencasts to teach you about Rails 3. About 2 months ago I produced the Rails 3 Screencasts, which will get you started.

Ryan Bates has also produced an incredible amount of Rails 3 screencasts over on Railscasts.com. Ryan has been producing Railscasts for over 3 1/2 years, isn?t that crazy?

There?s also a few good free screencasts over on Teach me to Code by Charles Max Wood.

Keeping on the Edge

If you find yourself wondering how to keep up with all of the newest features / libraries for Rails 3, both the Ruby5 Podcast and the Ruby Show are going strong. Don?t listen to audio? It doesn?t matter, just subscribe to the Ruby5 RSS feed and get links with descriptions to all the newest libraries, tutorials, and more. You might also want to checkout Peter Cooper?s new Ruby Weekly, a Ruby email newsletter

.

Need to upgrade a big app to Rails 3?

Jeremy McAnnaly?s Rails 3 Upgrade Handbook PDF is just $12. There?s also a few paid screencasts for the upgrade over on Thinkcode.tv and BDDCasts.

Need a Book?

There?s a bunch of books that will be coming out after the release, most of which you can start reading now. The Rails 3 Way by Obie Fernandez, Rails 3 In Action by Ryan Bigg and Yehuda Katz, Beginning Rails by Cloves Carneiro Jr and Rida Al Barazi, and of course the Agile Web Development with Rails:fourth edition by Sam Ruby, Dave Thomas, and David Heinemeier Hansson.

In conclusion

No more complaining about lack of good documentation! Seriously. If you want even more Rails 3 content, check out the blog post by Kevin Faustino on 34 Ruby on Rails 3 resources to get you started.

A while back I posted a link to a talk by Gleb Arshinov that he gave at the SF PUG. This talk was on “PostgreSQL for high performance Rails apps”, and was full of fine suggestions from their experiences with their Rails apps.

Gleb is back again, this time on May 21 2010 at PGCon where he and Alexander Dymo talked about PostgreSQL as a secret weapon for Rails apps. Some of the same ground is covered (use SQL DDL vs ActiveRecord create_table, etc), but there’s lots of new information too. Here are some notes:

• 1:10 They’re using PostgreSQL 8.4, nginx, and mongrel
• 4:00-6:00 Talks about dropping down into SQL via ActiveRecord
• 6:30 Use include to eliminate N+1 queries.
• 7:30 Watch for things like acts_as_tree that reintroduce lots of queries in exchange for the improvement in abstraction.
• 9:00 One query, 12 joins – complicated, but query time goes from 8 seconds to 60 ms.
• 14:00-17:00 A technique for recording SQL queries; this helps ensure you’re not running unexpected queries
• 19:00 Suggests use straight SQL for DDL rather than the ActiveRecord DSL
• 20:00 Use constraints, FKs, etc to preserve data integrity – “anything you don’t have a constraint on will get corrupted”
• 23:00 Don’t use CASCADE since app won’t know about the deletions
• 28:00 Keep a log of times for the most frequent user requests. Alex suggests using integration tests for this; code is at 29:10 and 29:30.
• 32:30 A technique for loading data with ActiveRecord’s select option with PostgreSQL arrays to save on object creation. Questions from the audience about normalization vs efficiency.
• 38:50 Role/user/privilege checking can be slow; shows a technique for using PostgreSQL’s bool_or and GROUP BY to get the data in one fell swoop. Query time went from 2+ seconds to 64 ms.
• 42:00 Do analytics in the database. Saw speed improve from 90s to 5s and saved tons of RAM.
• 44:40 Some excellent new PostgreSQL features that are either here now or are on the way (replication, windowing functions)
• 46:30 Demonstrates a problem with PostgreSQL’s LIMIT and OFFSET when used with subselects. Some discussion of pagination with the audience. Here’s an excellent discussion of pagination alternatives written by Justin French.
• 50:30 How to force PostgreSQL to use a subselect vs a join; the example goes from 605ms to 325 ms.
• 52:20 Be careful with generate_series. Apparently these functions cannot generate hints for the planner.
• 55:30 General props to PostgreSQL community.
• 59:40 Need to test queries both in cold state and hot state; they saw 14x speed difference.
• 1:01:40 Tune PostgreSQL – shared_buffers, work_mem, autovacuum, etc. Rely on community knowledge for initial configuration.

Lots of good stuff there, enjoy!

I’m slowly catching up with my podcast backlog and came across a Pivotal Labs talk from May 2009. In this talk Josh Susser and Damon McCormick are presenting on Scaling a Rails App with Postgres . It’s a little dated now – this talk was given was when PostgreSQL 8.4 was in beta – but, still, lots of good stuff. Here are some notes:

• They started with an existing Rails app with lots of data, so they had some constraints – not greenfield development.
• Around the 5-6 minute mark there’s a good discussion of PostgreSQL’s query optimizer and how it analyzes a table’s data distribution. One takeaway (mentioned around 16:20) is to run vacuum more often on a particular table if there are a lot of writes.
• 10:00 How to set STATISTICS for a particular table.
• 11:00 Using partial indexes.
• 14:00 Indexing on expressions.
• 18:10-23:00 A nice discussion of the EXPLAIN output.
• 23:45 Here they talk about wide columns. I’ve seen this in MySQL as well, where splitting text data out into a separate table yielded some good speedups.
• 26:10 Some discussion of pg_bench.
• 35:30 How long does it take to add an index to large tables? They saw times of up to an hour for tables with millions of rows.
• 36:30 clustering your data in order to get PostgreSQL to write it more efficiently.
• 37:30-48:00 A thorough discussion of partitioning tables via table inheritance. They used an ActiveRecord model (39:23) with a bunch of utility methods. They also had a cron to periodically create new partitions. At 45:15 they make a nice distinction between using partial indexes and partitions – one advantage is that a partition’s indexes can be different than its parents indexes. At 49:00 they mention maybe doing a plugin, not sure if that happened.
• 52:00 Some discussion of full text search via tsearch.
• 53:00 PostgreSQL’s lack of built in replication outside of WAL shipping, Slony, etc. Thank goodness 9.0 will address this!
• 54:00 Some props to Engine Yard on their PostgreSQL support.

Good stuff all around, and thanks to Pivotal for posting these great talks!

Only Valid Measure of Code Quality

Image from http://www.osnews.com/story/19266/WTFs_m

WTF implies lack of clarity. Clear code is easier to understand, easier to maintain and easier to extend.

Announcing saikuro_treemap ? an easy to setup tool to generate complexity treemaps of ruby code.

See a demo for yourself.

Complexity Visualization of Rake