One of the coolest things about working for PostRank is that I am part of creating a product that I can be very passionate about because I am one of the sorts of people it’s made for. In short, I eat our dog food. So I wanted to dedicate today’s post to sharing a small anecdote about one of the killer features of PostRank Analytics, the Activity Stream. Read the rest of this entry »
Posts Tagged ‘Ruby’
I recently read a post from Carbon Five about RSpec best practices. The most delightful thing about it was reading it after I’d been writing a spec at work and noticing that how I was doing it was close to what was being described. It was a little bit of validation, a pat on the back for all of the reading, practicing, and thinking about BDD that I’d done to that point. But then Carbon Five asks “so what else?” Read the rest of this entry »
If you’re running a large-scale Ruby project, chances are that god is monitoring your long-running, background processes. I’ve had some encounters with god and I decided that I was fed up with not having tab completion for it.
So I created gabriel. gabriel helps you communicate with god by offering completions for subcommands, options, tasks, and group names for your bash shell. Installing it is pretty simple:
$ gem install gabriel $ gabriel-install (From there, follow the on-screen instructions)
To ensure you get completions in every session, confirm that your
.bashrc is sourced in your
.profile, if you’re a bit more old-school).
This is my first foray into shell scripting and into publishing a ruby gem, so check out the source and if you can make gabriel even better, please do contribute your patches.
May god watch kindly over all of your processes.
Live & Code has been largely about programming and life lessons. So, you can imagine that I was incredibly delighted to see these two combined in a small exchange on Facebook started by Reginald “raganwald” Braithwaite.
It’s a valuable life lesson made incredibly concise in my favourite programming language, Ruby. I leave the interpretation to the reader. It relates to some themes that I’ve already written about before and will probably write more about in the future.
If you followed my previous tutorial on implementing pass-through authentication to LDAP with Authlogic, you might be wondering how it can be extended to give different permissions to members of different LDAP groups. ActiveLdap and declarative_authorization make this incredibly simple.
Read the rest of this entry »
I just squashed a bug that had me scratching my head for at least a good half-hour or so involving a class constant that kept on getting changed. Here’s the setup (anonymized so that I’m not exposing gooey proprietary secrets):
class WebTransaction # Base URL for transaction web service SERVICE_URL = "http://accountingservice.com/" def transaction_url url = SERVICE_URL url < < "VAL1=foo" url << "&VAL2=bar" url end end
The class is meant to represent a transaction being posted against a rather odd web service that actually uses GET rather than POST for posting transactions (bad web service!). In my actual code, the URL parameters appended to the SERVICE_URL base would be determined on a per-object basis but I’ve simplified it here.
Here’s the punchline:
SERVICE_URL was changing! Calls to
transaction_url would keep on appending more variables to it. If you’re particularly clever with Ruby, you’ve already figured out exactly why. But if you’re scratching your head like I was, here are some hints:
- In Ruby, constants aren’t. In fact, they’re really no different from variables except for the fact that Ruby detects that variable names in all-caps are probably supposed to stay constant and warns if you try to assign to them.
<<, for strings, will append to the end of the string.
- Ruby strings are mutable. That is, operations on a string variable will usually be done in place, rather than returning a new string. (Method calls, on the other hand, are a different story!)
- Assigning a String variable to another String variable will assign the reference. That is, the two variables will be pointing at the same object.
Hit the jump to see the solution to this little mystery…
Read the rest of this entry »
Why The Lucky Stiff’s contributions to the Ruby community include “Why’s Poignant Guide to Ruby”, a book which many state was the reason they got into Ruby, Shoes, an easy-to-use cross-platform GUI toolkit with innovative online distribution features, and Hpricot, a very slick HTML parser that is also a joy to use.
Some believe that he has decided to move on from software development because his last tweet reads “programming is rather thankless. u see your works become replaced by superior ones in a year. unable to run at all in a few more.” Some believe that his accounts were all hacked. A few others believe that his anonymity has been compromised and that he has decided the destroy the pseudonym.
Wherever Why The Lucky Stiff goes from here, I hope he knows that there are so many of us who looked up to him and have him to thank for knowing the joy that is programming in Ruby. He will be sorely missed.
While I refuse to call this “magic”, the following has been confusing me for a long time now and I’ve finally decided to post it to my blog and see if anyone else gets it.
It turns out that ActiveScaffold and YARD don’t play nice together. In particular, if YARD has previously been loaded (say, to define a Rake task for it), ActiveScaffold initialization will fail with the following error:
uninitialized constant Helpers::ControllerHelpers
--trace and following the source code, I find out that this is happening during ActiveScaffold’s initialization, particularly at this statement:
Debugging the ActiveScaffold initialization code yields this baffling result:
>> ActiveScaffold::Helpers => Helpers >> ActiveScaffold::Helpers::ControllerHelpers NameError: uninitialized constant ActiveScaffold::Helpers
It’s the weirdest thing that I’ve seen since I became a Rubyist and it is blocking me from using YARD to generate the documentation for my current Rails project. Unfortunately, cutting out ActiveScaffold isn’t going to fly because the deadline for initial release is so close and so much functionality is implemented using it already. It wasn’t my choice; if I had my way, I might never use ActiveScaffold ever again.
Giles Bowkett wrote a post which, at the surface, seems to be a harsh criticism of the way that Pythonistas and, in particular, Django developers view Ruby and Rails but is actually much more general — he simply wanted to point out that the entire notion of calling language/framework features “magic” is silly for programmers, who should prefer to be rational than superstitious.