Today I was looking for a way to pretty print xhtml. Good’ol REXML supports this in a very simple way:

Document.new("<some>XML</some>")doc.write($stdout, indent_spaces = 4)

This generates a nicely indented xml document. But REXML was not robust enough for my needs. Luckily, we now have a couple of excellent choices on ruby for parsing xml, including hpricot, nokogiri and libxml-ruby bindings.

I did not find a way to pretty print xhtml as easy as you can do with REXML with any of these libraries, though. But I did find a way of doing it using XSLT. Nokogiri supports applying XSLT to an XML document (probably libxml bindings do too, hpricot does not). Here is how:

    xsl = Nokogiri::XSLT("pretty_print.xsl")
   html = Nokogiri(File.read("source.html"))
   File.open("output.html", "w") { |f| f << xsl.apply_to(html).to_s }

That’s it, simple enough. Got the idea from this dzone snippet.

For the xslt file I used this nice one I found on this site: http://www.printk.net/~bds/indent.html

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="xml" encoding="ISO-8859-1"/>
  <xsl:param name="indent-increment" select="'   '"/>

  <xsl:template name="newline">
    <xsl:text disable-output-escaping="yes">
</xsl:text>
  </xsl:template>

  <xsl:template match="comment() | processing-instruction()">
    <xsl:param name="indent" select="''"/>
    <xsl:call-template name="newline"/>
    <xsl:value-of select="$indent"/>
    <xsl:copy />
  </xsl:template>

  <xsl:template match="text()">
    <xsl:param name="indent" select="''"/>
    <xsl:call-template name="newline"/>
    <xsl:value-of select="$indent"/>
    <xsl:value-of select="normalize-space(.)"/>
  </xsl:template>

  <xsl:template match="text()[normalize-space(.)='']"/>

  <xsl:template match="*">
    <xsl:param name="indent" select="''"/>
    <xsl:call-template name="newline"/>
    <xsl:value-of select="$indent"/>
      <xsl:choose>
       <xsl:when test="count(child::*) > 0">
        <xsl:copy>
         <xsl:copy-of select="@*"/>
         <xsl:apply-templates select="*|text()">
           <xsl:with-param name="indent" select="concat ($indent, $indent-increment)"/>
         </xsl:apply-templates>
         <xsl:call-template name="newline"/>
         <xsl:value-of select="$indent"/>
        </xsl:copy>
       </xsl:when>
       <xsl:otherwise>
        <xsl:copy-of select="."/>
       </xsl:otherwise>
     </xsl:choose>
  </xsl:template>
</xsl:stylesheet>

I have a couple of big hard drives on my desktop PC. Still, from time to time I need to do some maintenance to get rid of all the junk I throw at them. Lately, I’ve been moving files around a lot. And I was doing it all wrong! I set the laziness aside and thought about ways of improving my “work flow”.

Whitespace, go away!

The first issue I had is that bash gets confused when the filenames include white space.


[emmanuel@going_merry ~/files]
$ ll
total 4
-rw-r--r-- 1 emmanuel users 2818 2009-08-11 11:38 This is my afn.py

[emmanuel@going_merry ~/files]
$ mv This is my afn.py afn.py
mv: target `afn.py’ is not a directory

[emmanuel@going_merry ~/files]
$ mv This\ is\ my\ afn.py afn.py

Notice the slashes I had to add on the second mv call. This might seem pretty obvious. Bash usually puts those slashes automatically when using tab completion. But the thing is, what I really need in my case is to move a whole set of files returned by other utility, like find, to another place:


[emmanuel@going_merry ~/files]
$ ll
total 8
drwxr-xr-x 2 emmanuel users 4096 2009-08-11 11:41 dir1
drwxr-xr-x 2 emmanuel users 4096 2009-08-11 11:41 dir2

[emmanuel@going_merry ~/files]
$ find dir1/
dir1/
dir1/My afn 1.py
dir1/My afn 2.py

[emmanuel@going_merry ~/files]
$ find dir1/ | xargs -I {} mv {} dir2
mv: cannot stat `dir1/My afn 1.py': No such file or directory
mv: cannot stat `dir1/My afn 2.py': No such file or directory

The problem here is in the find output. The list of  path names returned by find may have unescaped spaces on path names. I needed to escape those spaces before using those path names with other utilities. I looked around for a unix utility to help me in this regard, but not easily finding anything good around, I just wrote a little ruby script for dealing with this: "escapepath".


[emmanuel@going_merry ~/files]
$ which escapepath
/usr/bin/escapepath


[emmanuel@going_merry ~/files]
$ cat `which escapepath`


#!/usr/bin/ruby
require 'shellwords'

while not STDIN.eof?
  puts(STDIN.gets.chomp.shellescape)
end

gist

Now I can do things like:


[emmanuel@going_merry ~/files]
$ find dir1/ -type f | escapepath | xargs -I {} mv {} dir2/


If you are typing too much, you are not aliasing enough

An anti-pattern I was using was... typing a lot. I kept running again and again things like:

[emmanuel@going_merry ~/files]
$ ack -a -f | grep thing_i_want_to_find -i | escapepath | xargs -I {} mv {} /some/directory


...to find several files at once using a case insensitive regular expression and move all of them to a certain directory. The solution: bash aliases:


[emmanuel@going_merry ~/files]
$ cat ~/.bashrc

# ...
alias xmv='escapepath | xargs -I {} mv {}'
alias ifind='ack -a -f | grep -i'
# ...

Note: ack is a cool alternative to find+grep which also has some nice file finding features. Check it out.

Know I can do things like:


[emmanuel@going_merry ~/files]
$ ifind thing_i_want_to_rm | xargs rm
[emmanuel@going_merry ~/files]
$ ifind thing_i_want_to_move | xmv /some/directory


Ah! much more easy on my poor fingers....

Basically, the same way you spec a rails application.
The cool trick is you take advantage of the spec_helper.rb of by loading it in the spec_helper of your plugin.

# ../vendor/plugin/YOUR_PLUGIN/spec/spec_helper.rb
begin
  # load your main app spec_helper
  require File.dirname(__FILE__) + '/../../../../spec/spec_helper'
rescue LoadError
  puts "You need to install rspec in your base app"
  exit
end

I took this idea from Pat Maddox’s rspec-plugin-generator. You can use that generator to generate the basic plugin boiler plate for you.

The caveats are, you need to have rspec installed on your main app and you need to actually have the plugin installed in a rails application to test it. In any case, this works for my current needs.

For more info see this post.

Tomorrow starts Locos X Rails conference in Buenos Aires, Argentina. I’m very exited about it! Yesterday I met Desi McAdam, of DevChix fame, and also the keynote speaker Obie Fernandez, founder of HashRocket. I’m eager to hear their talks, and hope to see you in the conf. too!

Desi and Obie at the press meeting for the LocosXRails conf.

ImageMagick vs GraphicsMagick, no strings attached.

[emmanuel@going_merry ~/Desktop/test]
$ gm -version
GraphicsMagick 1.3.5 2009-01-26 Q8 http://www.GraphicsMagick.org/
Copyright (C) 2002-2009 GraphicsMagick Group.
Additional copyrights and licenses apply to this software.
See http://www.GraphicsMagick.org/www/Copyright.html for details.

[emmanuel@going_merry ~/Desktop/test]
$ convert –version
Version: ImageMagick 6.4.9-2 2009-02-08 Q16 OpenMP http://www.imagemagick.org
Copyright: Copyright (C) 1999-2009 ImageMagick Studio LLC

[emmanuel@going_merry ~/Desktop/test]
$ du src -h
62M src

[emmanuel@going_merry ~/Desktop/test]
$ time find src -type f | xargs -I {} gm convert -sample 25%x25% {} ./dst/{}

real 0m24.593s
user 0m22.172s
sys 0m1.383s

[emmanuel@going_merry ~/Desktop/test]
$ time find src -type f | xargs -I {} convert -sample 25%x25% {} ./dst/{}

real 0m29.137s
user 0m24.888s
sys 0m2.953s

Conclusion: GraphicsMagick 1.2X faster than ImageMagick

EOF

Estamos a poco mas de 20 días para el inicio de la primer conferencia de ruby y rails en Argentina. Todavía no te anotaste? Podes hacerlo mediante la web: http://www.locosxrails.com/registration

Si ya te anotaste, “spread the word” mediante alguno de los siguientes badges:

Saludos!

Ya se pueden anotar en la conf. El valor de la entrada es de 300 Argentinos. Claro, antes de anotarse van a querer saber quien va a dar las charlas:

http://eventioz.com/events/locos-x-rails-conference/speakers

Nos vemos ahi!

Por fin!, una conferencia de ruby y rails en Argentina! La misma se realizará el 3 y 4 de Abril en la Universidad de Palermo, C.A.B.A. Estan cordialmente invitados. La inscripción no ha empezado todavía, pero si pueden mandar sus propuestas para disertar en la misma.

Locos Por Rails Conference 2009 will be held on April 3rd and 4th in Buenos Aires, Argentina. Registration is not open yet, but the call for papers is already open. Send yours!

…that your code sucks, that one of your ideas is horrible, totally unusable or even (alas) that you or other developers are dumb because they choose to do things in certain way? I have, once or twice…. .

Leaving aside the fact that the person proffering those kind of comments has probably not reached maturity yet and/or has not good people skills, there are some good tips to take into consideration when that happens.

I’ve stumbled upon this excellent article:  http://mumak.net/stuff/your-code-sucks.html. I will simply copy-paste cites from it in blue. It talks specifically about code reviews, but we can adapt its tips if we think of a comment like “mocking/stubbing is a horrible idea and it can hurt the development process” as if it were a code review… (By the way, David show us in his article the proper way to handle these kind of statements. Excellent post!)

First, don’t take it personally. Very often programmers tend to confuse personal preference with objective worth. I tend to take the “let’s do it your way” path -in cases where there is no harm in doing so- to avoid never ending discussions.

In the positive side of things, consider:

…someone has just tried to improve your product. They’ve put thought, effort and creativity into helping you, and now they have put their work up for critique: thank them.

Divmod have a policy of always saying one good thing in each code review. There is always something nice to say, even if it’s just I’m glad someone is looking at this part of the code

…

Code reviews provide an amazing opportunity to grow as a programmer and to improve the software we make. Off course! Just because the comment does not come wrapped in a polite sentence does not mean that it is wrong.

At the other side of the coin, If we are the ones reviewing other people work, then:

Ad hominem

This ought to go without saying: review the code and not the coder. Comments about a person will only make it harder for that person to apply critiques about their code.

When making negative comments, refer to the patch or the branch rather than you. For example, You’ve introduced a bug in get_message becomes this patch introduces a bug in get_message.

Unclear Outcomes

If all you say is, this patch introduces a bug in get_message, then you have failed as a reviewer. The goal is to improve the code, not to provide a series of puzzles for the author.

The author should be able to look at a review and be able to tell how to address each point and also when they have addressed all points. Reviews with unclear outcomes turn into open-ended discussions about the patch, which sometimes become focused on making the reviewer happy, rather than improving the code.

Confusing personal preference with objective worth

This is a problem in all spheres of review. Film critics, literary editors and acadamic reviewers all do it. What I like is not necessarily the same as what’s good, although part of becoming a better programmer is having your preferences align better with reality. What I dislike is perhaps even less likely to be the same as what’s bad.

When reviewing a perfectly acceptable patch that solves a problem using imperative-style programming, do not criticize it simply because it isn’t in a more functional style. Doing otherwise makes reviews a game of guess what the reviewer likes rather than write good code.

Reviewers can avoid this trap by phrasing review comments as questions, Did you consider using a more functional style?, Why aren’t you using regular expressions to solve this problem? etc.

I encourage you to read Jonathan Lange’s post, there are a lot of excellent tips on it!

If you are building a facebook applicaction using facebooker gem, beware the version of the gem in rubyforge is outdated. The easier way to deal with this is to clone the github repo of facebooker and install the gem from there.

1. git clone git://github.com/mmangino/facebooker.git
2. cd facebooker

Then:

1. rake gem
2. cd pkg
3. sudo gem install facebooker-[insert-version-here]

UPDATE

But this won’t work… the updated method is:

1. rake gemspec
2. gem build facebooker.gemspec
3. sudo gem install facebooker-[insert-version-here]

At this point, the lastest version on github is 0.9.9 1.0.8!!! (0.9.5 in rubyforge), and this is a version you are going to need because of this commit.

UPDATE:

Although the procedure above still works, you may find it easier to install the gem directly from github, now that its gemspec has been made github-compatible:

1. gem sources
2. sudo gem sources –add http://gems.github.com (if it is not already listed when you run step 1)
3. sudo gem install mmangino-facebooker

…although because of github gemspec security policy, the gem there is _not always_ the lastest…