Posteado por: emmanueloga en: Septiembre 29, 2009
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>
Posteado por: emmanueloga en: Agosto 11, 2009
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”.
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
Now I can do things like:
[emmanuel@going_merry ~/files]
$ find dir1/ -type f | escapepath | xargs -I {} mv {} dir2/
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....
Posteado por: emmanueloga en: Junio 25, 2009
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.
Posteado por: emmanueloga en: Abril 2, 2009
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.
Posteado por: emmanueloga en: Marzo 13, 2009
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
Posteado por: emmanueloga en: Marzo 10, 2009
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!
Posteado por: emmanueloga en: Marzo 4, 2009

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!
Posteado por: emmanueloga en: Enero 23, 2009
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!
Posteado por: emmanueloga en: Diciembre 28, 2008
…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:
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
.
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.
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!
Posteado por: emmanueloga en: Diciembre 8, 2008
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.
Then:
UPDATE
But this won’t work… the updated method is:
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:
…although because of github gemspec security policy, the gem there is _not always_ the lastest…
Comentarios recientes