Cicero Oliveira

Just a developer.

Updating Git in Mac OS X Lion

I’m about to start a new Rails project. But before diving in and start coding I decided to check the tools I have installed and I noticed git is slightly outdated so I decided to install a more up-to-date version.

Researching on the web for the best way to do I could not find one that would uninstall the older version and install the one. Some posts said I needed to remember how I installed and had suggestions on how to uninstall it from there. I can’t remember how I installed, so I decided not to uninstall it.

Book Review - the Productive Programmer

Yesterday, I finished reading Neal Ford’s, The Productive Programmer (Theory in Practice (O’Reilly)), a very good book that kind of summarizes some of the software engineering ideas that have been around lately. The book is a divided in two parts with different types of content, you can almost say that it is two books put together.

The first part of the book is about ways to improve your productivity by better using some of the features or software available for your operating system whether you are using Mac OS X, Windows and Linux. This first part is the main reason I bought the book as I always wanted to get better at channeling the huge potential of the command line which was lost when the mouse became popular.

The second part covers recent software development theories and techniques. Things like Test Driven Development, static analysis, encapsulation, meta-programming, and polyglot programming. One of my favourite topics covered by Neal is using other languages that run on the JVM. The possibility of including new, more modern and more efficient languages in a corporate environment by using the JVM is a great idea (check out Ola Bini’s talk on Adopting the JVM.  I haven’t programmed in Java for a while but I’ve been using JRuby on the JVM and it is great, the next step is try Groovy and see how helpful it will be before presenting it as a viable  tool to the other members of my team.

Neal gives us some good examples on using other languages to help in achieving our goals. Helping us keep in mind that our efforts as software developers should be about using the best tool for the task at hand. So, don’t be afraid: a little bit of JRuby meta-programming might help in creating more fluent interfaces, or you can rely on Groovy to test your Java code.

Concluding, if you are looking for overall information regarding software development today and some suggestions on how to become more productive by better using your operating system command line and other automation techniques, Neal Ford’s “The Productive Programmer” is a good read.

Ship Your Side Project

On my daily reading of Hacker News>, I came across the article Importance of Side Projects which points out the benefits of working on a side project of your own. It was a very interesting reading to me as I’ve been working on side projects for over a year.

I spend most of my time developing software on IBM Mainframes for one of Canada’s top insurance companies. Being able to put COBOL aside and delve into Ruby or Ruby on Rails feels like a well deserved reward. Writing code in a language with premises and best practices far away from COBOL is enough to give me a break and keep my craftsmanship skills on edge.

One of my University teachers said that the most important thing we would learn in our academic years was how to build knowledge, how to analyze and synthesize what we know and come up with new ideas. It was a Critical Thinking class for Computer Science graduates and he pointed out that six months after we graduate most of our knowledge would be obsolete so the best he could do for us was teach us how to learn.

Side projects are a way of keeping up-to-date with new technologies, concepts and techniques we want to experiment with. You can try things you cannot usually try in your daily work—either because they are too risky or not mature enough—without worrying. You can always start again.

The last suggestion in the “Importance of Side Projects” post, Complete Your Side Project, reminded me of another post: The Stewart Method: How Not To Suck. It is a short and practical post which has only two tips to help you in shipping your side projects:

1.Write code for your project everyday 2.Release a project every week

Remember the three axes of software development: time, quality and scope. If you want to ship every week, scope is the only we can change. Now all you have to do is create a list of the most crucial features you’ll need to have a viable deliverable and start knocking them down starting from the hardest ones, little by little, coding every day.

Don’t wait until you have time. Make time.

Figure out what you want to have finished in a week, and start today. #projectaweek

Technical Debt Warning

Currently, my daily job involves software development in IBM mainframes in the insurance industry but, in my spare time, I’m dedicated to web development as a Ruby and Rails enthusiats. The difference between the methodologies used in the more modern web oriented industry and the old school COBOL environment are huge.Thus, from time to time, I try to bring some of the better, more modern, software development practices to my daily job and as part of the editorial board of my company’s IT Department newsletter, I had the opportunity to include the following article to the last month’s edition. Enjoy!

Technical Debt - Don’t let it accumulate

Software development, just like a house mortgage, incurs a certain debt that needs to be paid frequently and as early as possible, as the cost increases over time and it might end up being too expensive to afford.

Whenever we cut corners on our software development process, we create technical debt, and if we don’t stop to assess what we are delivering—ready to refactor and improve the code—we are setting ourselves up to deliver bad software.

Timed deadlines happen for many reasons: attempt to release a solution before the competition; regulations—legal changes that need to be applied to our product—; the mistaken belief that, the faster we deliver, the cheaper the project is; or any other reasons that force us to deliver within a certain timeframe.

How do we deliver faster? We copy code in many different places, sometimes from other programs that were not properly designed to begin with. We try to use existing programs and subroutines, adding code to an already convoluted program. During the testing phase, we make sure the solution works, but if something fails or a new functionality needs to be added or changed, maintenance becomes a nightmare, and that’s when all the money we thought we were saving needs to be used, and sometimes even more than the savings.

The farther the development goes, the more expensive changes become. Fixing bugs or correcting design errors at the beginning of the project is a lot cheaper than after it goes to production.

We can all agree that attempting to identify all the requirements at the beginning of the development phase may not be ideal. If we are lucky, we might be able to identify most of what needs to be done, but there will always be unexpected changes. Thus, we can say the technical debt is a constant on software development. That validates the saying “The way to deliver the right solution is to start again after you finish.”

The million dollar question is: how can we save money while paying technical debt? The best option: refactoring. Refactoring is rewriting the code to clean it or improve quality without affecting functionality, it might even run faster, but the main idea is to make it easier to understand and easier to maintain.

Refactoring should not be an individual developer’s initiative but part of the process. Time spent on refactoring must be accounted for as part of the estimation and planning process. Automated tests help save money as well as make it possible to quickly identify if anything was broken during the refactoring. If it takes a long time and a lot of effort to retest we could end up with other added costs.

Reviewing code frequently to clean it up is a good habit and should be done frequently, but it takes time so a buy in is needed from project members, most importantly managers and stakeholders.

Team Space - Breaking the Physical Barrier

Some new software development methodologies, like Extreme Programming (XP), have amongst their suggested practices a common room where a team, working in the same project, sits together.Having developers, business analysts, project managers, testers and all other stakeholders sitting together increases communication effectiveness and help in keeping all team members up-to-date when it comes to the project at hand.

Ideally, the entire team and no one else will sit in the same room. A “break-out” area nearby allows them to chat, relax, and build friendship: the ubiquitous water cooler space. A nearby meeting room is also useful for privacy, having discussions without interrupting the team and for whenever people need a quiet moment away from the team room.

Some people may be reluctant to move desks or sit together afraid of feeling exposed and afraid of the impersonality of the open space. They should be encouraged to create their own workspace customizing them as they see fit.

Preferably, desks should be in the centre of the room, and the walls will be used as an informative workspace, where useful information will be displayed to help people structure their time and make good decisions. They can be filled with whiteboard, flip charts, and posters.One way to increase the success of the one room approach is having one or more business representatives present in the room. They need to be subject matter experts and empowered to make decisions regarding requirements and their priorities.

Business representatives’ contribution includes detailed explanation—to the programmers—of the system features, clarification, writing acceptance tests in collaboration with programmers.Project failure research indicates that more business involvement is paramount to a successful project. In the least, it makes it easier to keep everyone in the loop.

The company I work for has bought a new insurance software and team to work on it adopted the one room approach to deal with one of their vital tasks. In order to finalize their requirements documentation fast and as accurate as possible, they spent an entire day working together in the same room, with someone representing the business to whom they could clarify issues pretty quickly just by turning around and asking for help.

According to one of the BAs it was a very productive approach which allowed them to accomplish a lot by being closer to team members who were important in the decision making process as well as increasing the communication effectiveness as everyone could be easily included in the discussions they found had an impact on their specific tasks.

Writing

In his autobiography, Gabriel García Márquez give us a tip: “If you believe you can survive without writing, don’t write.”

I’ve been always fascinated by our ability to communicate using written language. I’ve been reading since I learned to. I need to read. It is more than just a way to learn

I am an avid reader, fascinated by the writers’ ability to craft a story and transmit it to others. Sometimes I feel the need to writer Ideas start forming in my mind, not entire stories, but some plot points. I write down the ideas on my “Bag of Ideas” so I can go back to it later and develop the story, which I end up never doing.

Part of me is afraid, then, every time I sit down to write, I start to research how to do it. In the end, I reviewed lots of techniques but did not write one single creative line.

I remember a scene from the movie “Finding Forrester” when Forrester is teaching his young pupil, Jamal, how to write. Each of them sit down in front of a typewriter and Forrester says, “Okay, now write” and starts typing like a madman while Jamal just stay still. After a while, after realizing Jamal is not writing, Forrester asks him what is he doing. Jamal answers, “Thinking”. Forrester replies, “No thinking - that comes later. You must write your first draft with your heart. You rewrite with your head. The first key to writing is… to write, not to think!”

On his book about the craft, “On Writing”, Stephen King tells us to think about books as means to transmit your thoughts, it is like being a mindreader in reverse. By putting your thoughts on paper you are transmitting your thoughts to your reader. Also he says that the most important thing is the story. It is all about the story. You have to entertain the writer. Tell him a good story.

In June, 2007, I wrote my first book. For more than a month, I wrote everyday while commuting. I made the mistake of writing in a notebook, now I need to rewrite it in the computer, but all give it some more time. I am still too critical of it’s content.

My next attempt will be next month. I’ve joined NaNoWriMo this year. Check it out: NaNoWriMo.

Rails in the Cloud

I’ve just finished the stickies application introduced by Harri Kauhanen, from Futurice, during his presentation entitled The future is here-Rails and the cloud ecosystem. It is a simple page with sticky notes and he developed it, in less than one hour, to show how to design an entire application by making use of a few cloud services.

The main idea of the presentation is that, by using cloud services instead of setting up your own production environment, you are free to focus on creating the application without being concerned with maintaining the production environment.

The application was built using Rails 3 and MongoDB.

Here are the cloud services used in this project:

Heroku - The application was deployed to Heroku. It follows a git workflow and has a rubygem which makes it really easy to deploy, just follow the simple steps presented on their home page. It is free for basic services, which is enough for you to test your application online.

MongoHQ - A cloud-based, Mongo DB host service. It was easily setup as the production database through an addon (MongoHQ free) provided by Heroku.

Google Font API - The handwritten font type used in the stickies is Reenie Beanie, provided by Google Font and it is incredibly easy to setup and help in giving a unique feel to the stickies.

Pusher - This real-time client push service was used to allow instantaneous updated to the stickies. You can see in real-time whenever someone else creates or update a sticky.

BrowserMob - It was used for performance testing. (Load testing to measure capacity and breaking point; monitoring jobs to track response time.) After adding a prime numbers calculation to the stickies project code, to slow it down, BrowserMob was used for testing it.

Check Harri’s end result in: (http://futu-stickies.heroku.com/).

Organize Your .css Files

If you like to organize your CSS rules by what elements they affect, the following template mught be a good idea. Whenever you want to find a section just look for its name preceded by two dashes.

/ –Header —————/

/ –Structure —————/

/ –Nav —————/

/ –Search —————/

/ –Headings —————/

/ –Lists —————/

/ –Forms —————/

/ –Links —————/

/ –Misc —————/

It’s Not Just About the Job but the Workplace

This week, there was an article on the Toronto Metro News–(More Money More Problems–about how Canadians are more interested in leading a fulfilling life than in making lots of money, meaning: the focus has changed from having a great career working long hours in exchange for monetary compensation.

Reports are starting to arise showing us that when members of the Generation Y reach the workplace there is a big cultural shock with old values present in the corporate world. They aim to change their jobs to fit their lives instead of adapting their lives to the workplace. The focus moved from having a high-paying job to having a better work experience with more free-time and more creative tasks.

Nowadays, most companies still have their values based on principles forged on the Industrial Age and some of them do not make sense anymore. For instance, there was a time when most employees had to be at their workplace from 9 to 5 to do get their jobs done, nowadays we have telecommuting and communication tools that allows to work without being physically present in the office, even more, sometimes there is no need for everyone to be at the office at the same time, workers can have flexible hours.

With USA as the leader, the social model in the western civilization is still centralized around the idolatry of work, the market and competition. However, as the Italian Sociologist, Domenico DeMasi predicted almost ten years ago, a new model is emerging. DeMasi called this new model Creative Idleness and stated that, in the future, successful workplaces will give their employees tasks that will involve working, learning and leisure time all at once.

A few companies are already there, like Google, where their employees are allowed to work 20% of their time on a personal project, which sometimes ends up as being one of the tools promoted by Google. However, to most companies it will take a long time until they adopt a new culture. We will start noticing changes in a few years when this new generation of workers start to assume key positions inside their companies.

Apple’s CEO, Steve Jobs—-recently named CEO of the Decade by Fortune magazine and chosen the most admired entrepreneur by American teenagers—-advice to Stanford’s graduates, when addressing them in their commencement speech in 2005, summarizes the importance of finding a work you love as if you were looking for a companion and not giving up on the quest. In his inspiring speech he said, “[…] you’ve got to find what you love and that is as true for work as it is for your lovers. Your work is gonna fill a large part of your life and the only way to be truly satisfied is to do what you believe is great work and the only way to do great work is to love what you do. If you haven’t found it yet, keep looking and don’t settle.

A Few Things I Learned as a Programmer

Cicero Oliveira, EzineArticles.com Basic Author

I’ve just had my most recent article published on EzineArticles. It is about some things I have learned in my more than ten years working as a programmer.

This is the summary:

“In more than ten years of experience as a programmer I learned a few things that have being helping along the way. Even my first meeting with the recruiter who gave the start to my career was an opportunity to learn as she mistakenly dismissed me. Nowadays, I can say that I am a valuable worker for my company partially due to some of the lessons I’ve learned and I’m sharing here with