To run Titanium applications you need to use Titanium Developer. This program executes a bunch of scripts to compile your projects using Xcode, starts the application in iOS simulator and so on. Fortunately Titanium is open sourced on Github, and while reading its code I had an idea that would make me feel much more comfortable about running my Titanium applications. If you are a “command-liner” like me, you probably will prefer to execute your applications from your shell using Makefiles, and that’s what my hack is all about.

The first thing I did was to understand how Titanium starts its projects and write a command-line script that replicates this behavior. Titanium uses a script called builder.py to do all the magic, and I wrote a simple wrapper script called titanium.sh that uses builder.py to compile and start the application:

You will notice in the script source that I read some data (the application name and ID) from tiapp.xml. This is the file used by Titanium to store projects’ metadata. if you want to use this script in your projects, it’s important to change the tiapp.xml path according to your project structure. My projects usually have a structure like this:

/bin (directory)
    titanium.sh
/SampleApp (directory)
Makefile

… where:

• bin is the directory where I put titanium.sh and other utility scripts.
• SampleApp is the directory where my application lives (this directory has the same name of my application).
• Makefile lives in the root directory.

If you use this same project structure, your tiapp.xml file will be located at /SampleApp/tiapp.xml. In this case, just copy my script and it will work for you too.

You can also configure Titanium and iOS SDK versions that will be used to compile. Just change the values of *_SDK_VERSION variables to the versions you have installed in your computer. Some variables (like PROJECT_NAME) are parameters that will be passed when the script is called (in our case, this will be informed by the Makefile).

One last thing about titanium.sh is that I use some Perl “black magic” at the end of the script to produce beautiful colored output depending on the log type (info, debug, error, etc.) – just like Titanium Developer does:

After that, you will just need a simple Makefile that will allow you to start the application by simply typing “make run” at the command line:

The Makefile is responsible for calling titanium.sh passing all the necessary variables. Just copy my Makefile to your project root, change the PROJECT_NAME variable and you are good to go!

If you want to take a look on how I use these scripts in my projects, take a look at titanium-jasmine on GitHub. You will notice in this project that you can do a lot of other fancy stuff using Make.

“Code refactoring is the process of changing a computer program’s source code without modifying its external functional behavior in order to improve some of the nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity to improve the maintainability of the source code, as well as a more expressive internal architecture or object model to improve extensibility.”
– Wikipedia

Or, being more concise:

“A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.”
– Martin Fowler

My concern with Refactoring is that most people don’t realize that they will have much more benefits if they do it all the time.

As the definition above explains, the purpose of Refactoring is to make code easier to change over time. It doesn’t make sense to keep adding features to your code for, say, 10 months and then stop-the-world for a couple of weeks to refactor it. If you’re doing that, you’re totally missing the point. In this hypothetical situation, not only (1) it would become more complex to make changes in the software over time – and you’d be in trouble for several months – but also (2) at some point of time the team would have to stop and re-engineer everything – because the software would become very difficult to change.

If a team waits for 10 months, or 2 months, or 2 weeks to refactor something, they are doing it wrong. Each time new features are added the code becomes more complex, and it’s necessary to review it as soon as possible to make the necessary improvements. If the team doesn’t do that often, they will become slower and slower each day, they will be less productive and deliver much less features (or value).

The “re-engineer” thing even worse. First, teams that stop to make huge refactorings are delivering nothing to their customers while doing that because they’re too busy fixing their own mess. It’s definitely bad to pay a software team to deliver nothing. Second (and more important), huge refactorings are often risky, because they change a great amount of code and software components, usually introducing bugs and unexpected behaviors.

To avoid all these bad things, you must do refactoring every day, all the time!

Every time you make a change, you must look for an opportunity to make an improvement. If you keep doing that, your code will always be clean, maintainable and easy to modify. Remember the TDD cycle: Red-Green-Refactor? Don’t miss the refactor part, do it all the time!

In my experience it takes no more than a few minutes to refactor if you are doing it in small chunks all the time, and more importantly, this will keep you from stopping to make huge and risky software re-writes.

The meeting was really cool and very crowded. We had a Randori session with around 30 developers to solve the “write numbers to words” problem using Python (thanks to the influence of our Pythonist friend “rbp“, that led the Dojo session).

I just finished writing a post on Yahoo! Developer Network’s blog explaining in more details how the meeting was (and what the heck a Coding Dojo is). You can also see some pictures on my Flickr page.

The next meeting will be next week (we still have to define the date). Subscribe to the group’s mailing list to be notified about the next meetings.

See you next time here in the office!

This is no surprise to me. I really don’t like to write source code comments. Why? Because if my code isn’t clear and easy enough for one to read and easily understand, I need to refactor. Many times I ask friends to take a look at code snippets and check if they understand. When they don’t, the method is usually too big or the variable/method names are not clear enough, and then I refactor to make it better to understand.

One example that I love (and use in many presentations) is the code to send e-mails using Java Mail API. The code would be something like this (from Java World tutorial):

// create some properties and get the default Session
Properties props = new Properties();
props.put("mail.smtp.host", _smtpHost);
Session session = Session.getDefaultInstance(props, null);
 
// create a message
Address replyToList[] = { new InternetAddress(replyTo) };
Message newMessage = new MimeMessage(session);
if (_fromName != null)
    newMessage.setFrom(new InternetAddress(from,
        _fromName + " on behalf of " + replyTo));
else
    newMessage.setFrom(new InternetAddress(from));
    newMessage.setReplyTo(replyToList);
    newMessage.setRecipients(Message.RecipientType.BCC, 
            _toList);
    newMessage.setSubject(subject);
    newMessage.setSentDate(sentDate);
 
// send newMessage
Transport transport = session.getTransport(SMTP_MAIL);
transport.connect(_smtpHost, _user, _password);
transport.sendMessage(newMessage, _toList);

I know that this is just an example but you know that it’s not difficult to find monsters like this one in production code.

This code is so difficult to read that the programmer had to say what he was doing, otherwise nobody would understand its purpose. There is a lot of infrastructure and business code together resulting on a huge abstraction leak.

Now take a look at the following code (from Fluent Mail API) and tell me how many seconds do you need to understand what the code does:

new EmailMessage()
    .from("demo@guilhermechapiewski.com")
    .to("destination@address.com")
    .withSubject("Fluent Mail API")
    .withBody("Demo message")
    .send();

This is an extreme example, of course. Maybe you will not write Fluent Interfaces for every little thing you need in your code, but if you add just a little bit of organization (using a better abstraction) it will already improve code readability:

class Email {
    public Email(String from, String to, ...) { ... }
    public void setFrom(String from) { ... }
    public void setTo(String to) { ... }
    public void send() {
        // put your complicated Java Mail code here
    }
}

Just by encapsulating the code in an abstraction that makes sense the WTF effect will be sensibly reduced. The programmers can now at least assume that the code sends e-mail messages since it’s included in a class called “Email”.

And that’s the point. When I create a culture of prohibiting myself from writing code comments, I’m obligating me to write easy, maintainable and understandable code.

That’s very extreme, I know, but the results of this approach are awesome.