How I Start The Morning
- Grab my favorite coffee, quad tall one Splenda latte from Starbucks.
- Sit down on my desk and turn my computer on.
- Login and open my terminal
- cd box/{name of the project}
- git pull
- open iTerm or another terminal tab
- tun (my alias for creating tunnel to my home server
- open Adium or Pidgin
- open another terminal tab
- gem server
- open my secondary browser
- http://localhost:8808
- open my email client
- start my work
So, how’s your day?
Chat With Me, The RubyHead
As you can see by that annoying thing on upper right corner, you can now chat with me in real-time. It comes alive whenever my instant messenger is on. Just click it and say “hello” or ask a question. Just remember to say your name first so I can call you by your name.
Look forward to chatting with you guys.
Why Ruby & Rails Needs Enterprise and Regulations
During the Pragmatic Studio I attended, a subject came up where I voiced concern over the fact that Ruby allows the programmer to override behaviors of “core” components. Dave Thomas explained that the other language designers assume that people are idiots and that’s why they put all the constraints. Although I disagree, I do love the fact that Ruby gives me a great deal of power.
I fell in love with Rails when I saw that Rails lowers the barrier to entry in web application development. What I didn’t realize at the time was that when you put out goodies in the wild, you tend to attract lots of wild animals. I’m finding out that convention over configuration can be abused to a point where I’m constantly trying to look for convention that once existed since Ruby allows you to smash convention.
I’m now accepting the fact that I’ll always be hired to solve problems. That means just about all my projects will be unscalable, full of technical debt, and design dead codes. Considering how young the language and the framework is, I find it somewhat shocking that so many projects are design dead at such early stage.
Now that I think about it, Rails is popular among startups where they have to constantly put up screens to impress investors and change business model. I accept that this is the nature of the beast. Until the time when Rails is used for any enterprise system or any app that is under regulatory constraints, this will remain to be the fact.
Let’s face it, putting out well-tested quality code requires lot more time and effort than just throwing shit on the wall and see what sticks. We all give lip services to TDD or BDD, but when you have a deadline to an investor who wants to see something moving next couple of hours will not allow you to dick around with the quality. Something always gives.
Is this only limited to startups? Absolutely not! However, it is more likely that any enterprise system will be better planned and properly resourced. Sun spent ton of money to get people to follow standards because I remember in early days of Java when this was happening as well.
So, next time you hear a young Railer trashing “enterprise”, please tell him to stop.
Struggling With Testing?
We all know that we need to test our code since we don’t have a compiler in Ruby world. The issue that I come across is NOT how to write the tests, but what to test and how it should be approached. If you think about it, we have plenty of resources on the syntax and the mechanism of testing frameworks, but it ultimately comes down to what your testing strategy is, if there’s any.
I for one, do not subscribe to “test everything” bullshit some Rubyists are pushing. I get annoyed whenever I see tests that do not have any value whatsoever and are completely redundant. I know this will raise uproar but it’s true. When you see it, you’ll know what I’m talking about.
My tip if you’re struggling with testing is to read OPC. With the GitHub, all you have to do is point your browser to test/spec directory in any project. You’ll see both good, bad, and ugly. Form your own strategy based on your exposure, and remember, this is NOT religion! The ultimate goal of this whole thing is to write quality code. As I said before, all is not lost by looking at bad codes.
Hope this helps.
Upgrading Your MongoDB
This morning, I got the notification that MongoDB 1.2.3 was released. Nice!
Unfortunately, I’ve been carrying around my Lenovo ThinkPad X200 running Ubuntu 9.10 since the New Year and completely forgot to update my MBP. It was still running 1.0! When you upgrade from very old version as I did, you’ll be greeted with an error message. What do you do? It’s dead simple, just do the following:
mongod --dbpath <your db path> --upgrade
That’s all there’s to it. You can go and upgrade every db files you have.
Are Down With OPC?
Other People’s Code, or OPC as I’d like to call since I am a child of the 80’s, is defined by me as crappy code. Of course I was joking to some extent, but I believe it’s something we need to address.
I always hear about learning to writing good code, but hardly ever hear about learning to READ the code, both good and bad. I was so happy when my fellow teachmetocode.com expert Chuck interviewed JEG (that sounds so much cooler than James Edward Gray III) in his podcast where JEG spoke about reading OPC. If you haven’t checked out his podcast, please do it NOW by going to http://www.railscoach.com.
As a software architect, I read lots and lots of code. I saw some excellent code as well as what can only be described as something only the mother would love.
You see, the code is same as any writing. It tells you what the code is trying to achieve and tells a story. I would compare it to any other fine literature or a junk novel. It has personality and style. It also tells the story of what was happening at the time of writing. For example, when I see that unit tests are missing when the rest of code base isn’t, it’s a sign of something being pushed out in a hurry.
Having said all that, I’d like to share my method for reading code. The most of this will be “duh, no kidding”, but I think it’s a good refresher.
- Before sitting down to read the code, I get an understanding of the final outcome.
- Understand the convention, design pattern(s), and the opinion of the framework.
- Have the language reference, API docs, and any other reference material
- Identify the entry point. I came from C, leave me alone!
- Identify the prerequisites.
- Start reading
- As I read, try to put myself in the same shoes as the person writing the code. e.g. what is his thought patterns, why did he do this way, is this guy a beginner or expert, is he trying to say “fuck you” to anyone reading the code, why is he writing Java code in Ruby, and etc.
- Follow the steps and write them down on a writing pad
- Absorb and appreciate, even if I think it’s a pile of crap
Next time, I may actually create a screencast going over a code review if I can find the time. Let me know.
exec, system, and “
Haven’t used this since 2007 and completely forgot. Yes, I use this blog as a notebook.
exec(“ls”) => exits from irb or the program
system(“ls”) => returns true or false (crap out)
`ls` => returns the output of the command as a string -> Nice!
1+1
1+1 shouldn’t be 1 1/2. However, usually this is what happens in terms of developer output. People expect 2, but that never happens, unless, there’s a proper management controls along with the right leadership that can produce 3 and increase exponentially as you add developers. I learned this from my early years when I had to work with extremely limited resources and budget.
People think it’s all about code. That’s true to a certain degree, but a company and the technology development is mostly about people. My recent startup-hopping showed me that too many people don’t get this.
Do you have 1+1 problem? Give me a call.
5th Annual Philly Emerging Tech Conference
From Andrea…
Registration is open for the 5th Annual Philly Emerging Tech Conference (a.k.a. Emerging Technologies for the Enterprise), which is set for April 8 – April 9 at the Society Hill Sheraton: www.phillyemergingtech.com
Rubyists on the roster include David Black (author of Ruby for Rails and the Well-Grounded Rubyist); Yehuda Katz (Rails Core Developer); Brian Marick (author of Every Day Scripting with Ruby); Ezra Zygmuntowicz (creator of the Merb framework and co-founder of Engine Yard); Mike Dirolf (who has developed Ruby drivers for MongoDB) and Adam Blum (CEO of Rhomobile, which developed the Ruby-based Rhodes framework for smartphones ).
Talks about a wide array of languages and technologies complement the Ruby content. The event features Clojure creator Rich Hickey; Twitter platform lead Alex Payne; Venkat Subramaniam (author of Programming Groovy); Mary Poppendieck, who popularized Lean Software Development; Linda Rising (co-author of Fearless Change: Patterns for Introducing New Ideas); and many others.
The keynote speakers will be “Uncle Bob” Martin, who served as the first chairman of the Agile Alliance, and industry analyst Michael Cote.
The list of confirmed speakers can be viewed here: http://www.phillyemergingtech.com/speakers
More speakers and session abstracts will be added in the coming weeks.
The Early Bird rate, available through February 15, is $275 per person. The rate goes down to $206 per person if you can take advantage of the group discount (4 colleagues or friends, not necessarily from the same company, registering at the same time).
To register, or for more information: www.phillyemergingtech.com
Happy New Year!
I’d just like to wish everyone Happy New Year!
I have to say that the year 2009 hasn’t been the best year of my life, and I’m really looking forward to 2010. I plan on generating more screencasts, write more tutorials, and finally contribute to an open source project.
