Claudio Lassala is an independent Software Developer who currently works mostly building Ruby on Rails applications. Previously, he has worked for several years developing .NET applications, presented several lectures at Microsoft events such as PDC Brazil, TechEd Europe, and various other Microsoft seminars, as well as several conferences and user groups across North America, Europe and Brazil. He is a multiple winner of the Microsoft MVP Award since 2001 (for Visual FoxPro in 2001-2002, and for C# ever since). He has articles published on several magazines, such as MSDN Brazil Magazine and CoDe Magazine. He started the Virtual Brown Bag meetings in 2009 and have been hosting it weekly since then. When not writing code, Claudio is probably rocking out with his band, Descent Into Madness.
Posted in Software Development on December 5, 2011
Last month Koby gave an “Intro to iPhone development” at the Houston Open Dev User Group (you can watch it here). This month Koby was back to show how to write the same “Twitter search” app using MonoTouch. You can watch his presentation here:
While it’s sort of nice to write C# code instead of Objective-C, the big thing about using MonoTouch is that one can reuse a lot of the code (such as business logic) between iOS and Android applications.
Besides Koby’s presentations, you may also want to check out these two articles that show you how to build a “Twitter search” app, both for iOS and Android:
Posted in Software Development on November 3, 2011
Earlier this week I attended to Michael’s “Intro to iPhone Development” presentation at the Houston Open Dev User Group, recorded the whole thing, and am making available here:
This has probably been the most I’ve seen of Objective-C, and boy, what an UGLY language that is.
In October of 2009 I did a presentation on Clean Code for the HDNUG. I just found a video recording of that and decided to make it available to those who care. Enjoy!
Posted in Software Development on October 20, 2011
I’m bruised after fighting my own Ruby/Mac noobness in the last couple of days, but I think I’ve learned a bunch of things after this.
I was a nobody…
When attending to Houston TechFest last week, my buddies told me that if I’m not using RVM I’m a nobody. :)
I hadn’t had a reason to use RVM, to be honest. I’ve been mostly working on projects running Ruby 1.8.7, and haven’t really had time to look into the new features/fixes introduced to the language. Ben mentioned improved performance, which is a very good reason, but I felt I wasn’t ready to migrate just yet (I had heard of people having some issues, so I thought I was going to save that “fun” for later).
Well, little did I know what was coming up the very next day…
It all started with some weird errors in Heroku
I pushed some changes to Heroku, and when I went about testing the application, it started to crash in points unrelated to my changes.
After analyzing the logs, the core problem seemed to be related to the allowed quota on my database being reached (I’m running the free account right now). I thought, “well, let me just reset the database, since this is all junk data anyway“. Apparently, db:reset isn’t available for MongoDB on Heroku. I tried to clean up my local database and push it up, but something went wrong there.
I then decided to just ‘destroy’ the app on Heroku, and recreate it. That’s easy enough…
Off to new errors…
Once the application was redeployed to Heroku, I started to see new errors in the log: they were Ruby syntax errors that I didn’t use to have before. After giving it some thought, I’ve guessed that Heroku’s default for new apps is currently Ruby 1.9.2, whereas my app used to be running on 1.8.7. My guess turned out to be correct as confirmed by Heroku’s tech support a couple of hours later.
Time to upgrade Ruby version? RVM!
My first reaction was to upgrade to Ruby 1.9.2, as that should address my Heroku problem (later, their tech support told me I could specify what version I wanted my app to run on in their stack… but at that point, it was too late, as I had gone quite far down into the upgrade path).
Installing RVM was easy by simply following the installation instructions on the website. After that, however, my environment didn’t have bundler, so I installed it with gem install bundler.
Next, time for bundle install. I started to get errors related to certain gems, which were actually easy to fix by upgrading gems, changing versions, etc. But there was one that seems to always be the worst nightmare: RMagick. I remember last time Ben and I had to hack something to make it work. This time I found out this Magick-Installer script, which worked like a charm (it took like an hour to download and install everything, though).
Installing stuff from Bash
I’m still pretty much a Bash noob. When I looked at the section of how to install Magick-Installer script, it was kind of cryptic to me:
“Download and run this simple script and watch your ImageMagick support go from 0 to 1 without MacPorts.”
Download and run. Hmm… *how* do I do that? I’m kind of used to download a zip file and double-click on whatever comes out of it, but I couldn’t find anything similar there. But then, I recalled the instructions I used to install RVM just a little earlier, so after clicking a link to the Magick-installer.sh file on Github and clicking on the “Raw” link in there, I found out the direct link to the actual script file. Then it was easy:
Use curl to download the file, and bash to run it. I shall not forget that.
Yeah, yeah, you bash badasses out there are laughing at me right now… well, I’ll give you one more reason to laugh: I’ve run the command above inside of one of my project’s folder, instead of running it inside of a temp folder, as I came to find out when I looked at the status of my Hg repository and it showed me hundreds of files had been added to it…
Mercurial cleaning up my mess
…well, good thing I’m using a version control system, right? Once I figured out the mess I created, reverting it was just a matter of running hg revert –all. No more harm done.
Me messing Mercurial up
At one point, I committed a “gemfile” to my repository, without realizing it wasn’t the same “Gemfile” I already had in there; no idea where the new, all lowercase file came from. Whenever it was time for me to merge my branch into the trunk I get a nasty surprise: some “case-folding collision” on “gemfile”.
I’ve tried what seemed like a million things, including the steps outlined here, but none of it worked. Eventually I realized I had a good copy of my project on Heroku, so I pulled it down, dropped into the project’s folder where the Hg repository is, and managed to merge it that way, and I was back in business.
Swapping Gems due to versioning issues
I was using HTTParty in order to make a post call to a service that returns an XML fragment. For whatever reason, after the upgrade, HTTParty (or rather Nokogiri, which is used internally to parse out the responses) couldn’t handle the XML fragment in the response I get from the service.
Fortunately, my dependency on HTTParty was encapsulated in a single spot, so I was able to quickly swap it and use Patron instead. Looked like it was going to work fine, but when I deployed to Heroku I got errors when compiling the native extensions. I look it up, and I find out I’m supposed to use an older version of Patron. I try out the older version, and it doesn’t work on my local environment (WebMock had trouble mocking calls to Patron).
I then look *that* up, and somebody recommends RestClient, which worked like a charm.
Tests helped. A lot!!
Besides certain syntax errors I had here and there, I got quite a bunch of errors related to Mongoid relations; I was using “reference_many” and “referenced_in”, instead of “has_many” and “belongs_to”, respectively.
After fixing most of those issues, I got stuck in a case where I had some metaprogramming magic going due to a misunderstood requirement. I had gotten clarification on the requirement with the client a month ago and added an item to my tracker in order to come back and clean that up later. Well now was the time to do it.
Thanks to my tests, I was able to fix my upgrading issues *and* clean up my code, refactoring parts that were written when I knew much less about both Ruby and the domain I’m working on.
Everyday I can feel my noobness on Ruby, Rails, Bash, Mac, etc. I’m working by myself, so there’s nobody sitting by my side I can turn to when I get stuck with stupid stuff. I have a couple of buddies who I ping on Skype or Twitter, and who are *very* helpful, but I try to keep that to a minimum, since everybody’s always busy with their own stuff.
Considering all of that, I’m feeling very good after the struggles I’ve had in the last couple of days, as I managed to get stuff done, and learn a bunch of stuff while doing it.
The single most important factor that allowed me to be brave and knock down every single hurdle in front of me? TESTS, TESTS, and TESTS!!
Houston TechFest 2011 was fun. Hanging out with my buddies there was great. Attendance on my sessions was really good, and I enjoyed the sessions I managed to attend.
If you attended to any of my sessions, I’d really appreciate if you could rate them, and give me some feedback, so I know what you enjoyed and what I should do to make it better next time. You also find links to session material there!
- Adventures of a .NET developer in Rails land
- Virtual Brown Bag
- Introducing a new feature to a Rails App: from beginning to end
Now here’s the best thing that happened at TechFest:
An attendee walks to me and says something along these lines: “Claudio Lassala! I’ve seen your session on productivity a few years ago. That session has changed my life!!”.
I can’t help but to come out of a conference re-energized after something like that.
Posted in Presentations on September 29, 2011
Almost a year ago I said I was taking a break for speaking, with the main reason being I wanted to focus on getting out of my comfort zone and learning stuff (which I did, if you’ve been following my posts on Rails, Mac, etc.). In order to help with my learning I also attended to conferences, which was great. In doing so, I’ve also picked up a couple of things *not* to do after analyzing certain things that a couple of speakers tend to do.
Your screen projected out to two big screens
It’s usually a good thing for the speaker to walk around once in a while, and maybe point things on the big screen while doing this presentation. However, if the computer is hooked up to two or more big screens, pointing things out on one of the screens SUCKS for the audience. People on the other side of the room probably can’t read what you’re pointing at, or it’s very likely that you’re standing right in front of the screen and they can’t see a big portion of it at all.
So what’s the solution to that? One option would be to get one of those laser pointers, and use that to point at one screen, and then at the other screen, which you can do from a distance. Or maybe get *two* of those, so you can point to the screens at the same time! If you get a fog machine going, that’ll make you look like the super Geek Jedi! (but then, people may not be able to read the screens anymore).
All joking aside, the real remedy for that couldn’t be simpler: use the mouse pointer, which is *always* showing up on all screens!
Showing slides containing code listings
I’ve seen speakers showing slides that only contain code. That is a good way to present code in the flow that fits your presentation. However, I’ve seen speakers packing so much code in a single slide that people can hardly read what’s on it. Worse still, the speaker talks about what the code does, but the audience has no reference to know where exactly on the screen they should be focusing on.
There are certain things one can do to address that:
- Refactor the code so there’s less to be listed on screen! :)
- For the cases where the code can’t be shortened, make sure you can easily zoom into the sections of the code you’re explaining. That’ll give the audience a reference as to what part of the code you’re talking about, *and*, it’ll make it easier to read due to the bigger fonts.
A couple of the sessions I’ve attended to recently reminded me of my When the geniuses talk or write… Zzzzzzz… post. I sit there thinking, “you see, that’s already a complex topic, and you’re making it look even harder. Is it because you want you took look smart, or me to look stupid, or you are just oblivious to it?“. I believe that the 80/20 rule applies here: 80% of the people that goes to a session doesn’t know much about the topic and want to learn, and 20% of the people already know something about it and would like deeper knowledge. If the second group isn’t happy for not having in-depth content, they just walk out and go find another session. In my mind, it’s better to lose 20% than 80% of your crowd (the 80% crowd may not walk out on you, but they’re likely to give you a bad rating if they didn’t learn anything from you).
There are plenty of other blog posts our there with tips for presenters. Here are some that I think to be pretty good:
Posted in Software Development on September 15, 2011
Houston TechFest 2011 is coming up in just about a month from now: October 15th. As usual, it’s free. As usual, there’s a TON of content: 16 separate tracks this year! If you live in Houston, surrounding area, or just feel like coming down for a great event, make sure to register!
I’ll be presenting three sessions there:
- Adventures of a .NET developer in Rails land
- After several years of working almost exclusively with .NET, I started looking into Ruby on Rails; different language, framework, tools, mindset. In this session I go over the findings that were important to me, the main source of difficulties, what resources were helpful, the things I enjoyed the most, etc. Attendees to this session will learn what they need to know in order to get started developing Rails apps, or at least learn things that might help them approaching things in a different way when doing .NET development.
- Virtual Brown Bag
- Introduction to the Virtual Brown bag online sessions.
- Introducing a new feature to a Rails App: from beginning to end
- There are several ways to introduce a feature to a Rails application (or to any app for that matter). In this session we go through one of the ways which we feel works pretty well. It involves discussing the feature, writing feature user stories, creating screen mockups, writing Cucumber tests for application behavior, writing RSpec for object behavior… The whole enchilada, as one would say.
I’m very pumped by all of these sessions. Both the Rails ones are brand new ones. The “introducing a new feature” one I’ll be presenting with my buddy Ben Scheirman (we have started working on it yesterday, and I think it will come out great!).
And last but not least, I’ll do the one on Virtual Brown Bag the same way I did it last year: it’ll be a *live* Virtual Brown Bag meeting, where I quickly explain to people what these meetings are all about, and then we just share a bunch of stuff (tips, tricks, techniques, tools, etc.).
I hope to see some of you there!