Developing cross-platform Adobe AIR desktop applications

This weekend I decided to spend some time developing my first cross-platform Adobe AIR desktop application. My first impression of Adobe Air was: Wow! It takes only a few minutes to see how easy and powerful this platform is. What’s great about AIR is that you can build Rich Internet Applications that run across operating systems (Win/OSX/Ubuntu) on the WebKit HTML engine and are easily delivered using a single installer file. You can also build desktop applications in JavaScript, a language that nearly everyone is familiar with.

What’s really cool about Adobe AIR is that the extension for Dreamweaver lets you transform a web-based application into a desktop application. Users can then run the application on their desktops and, in some cases, without an Internet connection. I already have a couple of these applications running on my Ubuntu desktop.

Also, Adobe AIR has an embedded database SQLite, which is an SQL92 & ACID compliant database engine with support for storing databases of up to 1TB. You can use this embedded database in your AIR Apps, and send SQL queries to it using JavaScript!

For a quick, hands-on illustration of how Adobe AIR works, read the following tutorials:

Make your site run 10 times faster

This is what Mike Peters says he can do: make your site run 10 times faster. His test bed is “half a dozen servers parsing 200,000 pages per hour over 40 IP addresses, 24 hours a day.” Before optimization CPU spiked to 90% with 50 concurrent connections. After optimization each machine “was effectively handling 500 concurrent connections per second with CPU at 8% and no degradation in performance.”

Mike identifies six major bottlenecks

How to Build a Web Hosting Infrastructure on EC2

Mike Brittain wrote:

In the months prior to leaving Heavy, I led an exciting project to build a hosting platform for our online products on top of Amazon’s Elastic Compute Cloud (EC2).  We eventually launched our newest product at Heavy using EC2 as the primary hosting platform.

We set out to build a fairly standard LAMP hosting infrastructure where we could easily and quickly add additional capacity.  In fact, we can add new servers to our production pool in under 20 minutes, from the time we call the “run instance” API at EC2, to the time when public traffic begins hitting the new server.  This includes machine startup time, adding custom server config files and cron jobs, rolling out application code, running smoke tests, and adding the machine to public DNS.

What follows is a general outline of how we do this.

Continue reading

Designing a CMS Architecture

François Zaninotto wrote:

When faced with the alternative between an off-the-shelf CMS or a custom development, many companies pick solutions like ezPublish or Drupal. In addition to being free, these CMS seem to fulfill all possible requirements. But while choosing an open-source solution is a great idea, going for a full-featured CMS may prove more expensive than designing and developing your own Custom Management System.

Given number of available open-source CMS solutions, building one on your own sounds like a stupid idea. But if your website is 50% content management and 50% something else, you probably need to start with a web application framework like Symfony or Django, rather than a CMS. These frameworks provide plugins that do part of the Content Management job already, so creating a CMS today is like assembling Lego bricks to build something that exactly fits your needs.

Continue reading

Leading a Software Development Team

36 steps to success as technical lead

  1. Define early on what success means for you, the team and the business.
  2. Believe in the project: idea, architecture, time, team.
  3. Understand the domain, the business requirements and the technical challenges.
  4. Know your team: strengths, weaknesses, ambitions and personalities.
  5. Have a plan as a result of a planning activity.
  6. Be part in the design of everything.
  7. Get your hands dirty and code.
  8. Act as a communication proxy for your team.
  9. Make sure everybody understands the big picture: their work has implications.
  10. Fight for architecture and design consistency.

Read more

How not to lead geeks

  1. Downplay training.
  2. Give no recognition.
  3. Plan too much overtime.
  4. Use management-speak.
  5. Try to be smarter than the geeks.
  6. Act inconsistently.
  7. Ignore the geeks.
  8. Make decisions without consulting them.
  9. Don’t give them tools.
  10. Forget that geeks are creative workers.

Read more

Nine things developers want more than money

  1. Being set up to succeed.
  2. Having excellent management.
  3. Learning new things.
  4. Exercising creativity and solving the right kind of problems.
  5. Having a voice.
  6. Being recognized for hard work.
  7. Building something that matters.
  8. Building software without an act of congress.
  9. Having few legacy constraints.

Read more

Top 10 ways to demotivate your programming team

  1. Set up impossible deadlines.
  2. Let them work overtime.
  3. Don’t allow breaks.
  4. Place a ban on laughing.
  5. Break the coffee machine.
  6. Don’t shield them from the dirty daily business.
  7. Don’t challenge them.
  8. Underpay them.
  9. Bribe them.
  10. Infiltrate a team member who is demotivated anyway.

Read more

Don’t bring me solutions, bring me problems

(Don’t tell me how you want it to work, tell me what you want it to do)

  1. Where all think alike, no one thinks very much.
  2. Suggesting solutions kills creativity.
  3. Don’t bring me solutions, bring me problems.

Read more

Classic mistakes enumerated

  1. Undermined motivation.
  2. Weak personnel.
  3. Uncontrolled problem employees.
  4. Heroics.
  5. Adding people to a late project.
  6. Noisy, crowded offices.
  7. Friction between developers and customers.
  8. Unrealistic expectations.
  9. Lack of effective project sponsorship.
  10. Lack of stakeholder buy-in.
  11. Lack of user input.
  12. Politics placed over substance.
  13. Wishful thinking.

Read more

Seven practices for healthier, faster software development

The practices discussed in this article are based on Ezequiel Cuellar’s observations. These practices will help any software development team as they come up against common obstacles. They will also contribute to a solid foundation for healthier development and help speed up production. The seven practices are:

  1. Improve business processes before starting development.
  2. Create a solid software development team.
  3. Improve processes for service requests.
  4. Minimize reporting of software metrics.
  5. Improve communication with the business team.
  6. Use the right programming language.
  7. Use the right IDE.

The practices target problems that are better addressed at the management level. Usually, developers can only report the issues to upper management for consideration. Because project managers have the necessary level of authorization, they are the ideal candidates to promote these practices within the organization.

Continue reading

Code Refactoring Guidelines

In software engineering, “refactoring” source code means modifying it without changing its behaviour, and is sometimes informally referred to as “cleaning it up”. Refactoring neither fixes bugs nor adds new functionality, though it might precede either activity. Rather it improves the understandability of the code and changes its internal structure and design, and removes dead code, to make it easier to comprehend, more maintainable and amenable to change. Refactoring is usually motivated by the difficulty of adding new functionality to a program or fixing a bug in it.

Code Refactoring Guidelines

  1. Big Picture
  2. Extreme Abstraction
  3. Extreme Separation
  4. Extreme Readability
  5. Interfaces
  6. Error Handling
  7. General Issues
  8. Security
  9. General Objects

Favour object composition over class inheritance

What does “favour composition over inheritance” mean, and why is it a good thing to do?

Object composition and inheritance are two techniques for reusing functionality in object-oriented systems. In general, object composition should be favoured over inheritance. It promotes smaller, more focused classes and smaller inheritance hierarchies.

Troels Knak-Nielsen wrote:

Class inheritance is a mix of two concepts. The extending class inherits the parents implementation (functions/methods) and it inherits the parents type. In a statically typed language, the latter is fairly important, since you can’t freely mix types. So if some method expects an argument of a given type, you might use inheritance to satisfy this. In a dynamically typed language that is a non-issue. You can simply implement the expected behaviour and that’s all there is to it. If you need a more explicit contract, you can document it or – since PHP has sort of a middle-way on this matter – you could use a statically typed interface (Eg. implements Person, rather than extends Person) to do the same thing. Since PHP is dynamically typed, this (slightly more verbose and restrictive) solution is purely optional. You can just use an implicit contract (duck typing).

The other use of class inheritance is to reuse implementation. If your abstract class Person is extended by a subclass Employer, you would have access to the same code in Employer as you do in Person. You could achieve code-reuse with composition as well, but it takes a bit more work. Employer would have to implement a wrapper that delegates control to a Person instance in this case. Eg.:

class Person {
  function sayHello() {
    echo "Hello, World!";
  }
}
class Employer {
  protected $person;
  function __construct() {
    $this->person = new Person();
  }
  function sayHello() {
    $this->person->sayHello();
  }
}

rather than:

class Person {
  function sayHello() {
    echo "Hello, World!";
  }
}
class Employer extends Person {}

As you can see, slightly more work to do, which is why people often use inheritance in these cases. The cost however, is that the Person-Employer relationship is now set in stone; It can’t be changed or intercepted at runtime. There is also the matter of clarity. While the compositional code is more verbose, it is also very clear about what it does. You can look at the code and know what it does. With the inheritance version, you need to look at the superclass to find out what it does. Some times there are multiple levels of inheritance, making you trace up and down the chain to figure out exactly what code is available in the concrete class. Finally, there is the problem of multiple inheritance. In PHP, you can’t. You only have one shot at inheritance, so if you want to reuse code from two places, well, you’re out of luck.

Source: SitePoint Forums

Whatever you write today will become legacy

Whatever you write today will become legacy. Legacy code is often written by people who thought they got it nailed, and later realize that the application is legacy. Not because of the application itself, but because of changes in themselves.

“What the hell was I thinking?”

Code is always the same, it’s your perception of it that changes. Code goes from “Best Code Ever” to “Legacy”. You are in the “Best Code Ever” phase now, but it won’t last. If you don’t realize that, you will get disappointed. The best programmers write the most legacy software. If you leave a project too soon, you are not going to get the most out of it. There’s no other way to become very good than to write a lot of legacy software. Writing legacy software can feel like a waste of time, but it’s necessary to grow and learn.

One of your goals has to be to leave the code you touch in a better condition than you found it. It doesn’t have to be all or nothing. You can make a small impact, a small change. Make incremental changes, that’s the secret of living with legacy software. You have to do it step by step.

Legacy software is a positive thing. It shows you that you got better, that you’ve grown.

David Heinemeier Hansson’s Keynote
Notes taken by Luc Castera

Links

Dealing with legacy PHP applications

Identifying Senior Software Engineers

For HR and legal purposes, most development companies classify Software Engineers into ranks from 1 to 4 (or 5). The higher the rank, the higher the responsibilities, expectations, independence and pay grade. To cut it as an interviewer and manager, you’ll need to classify people accurately with a minimum amount of direct personal exposure: a non-ideal but practical requirement of most hiring processes.

So, how do you objectively identify senior engineering qualities? Preston Lee focuses on several key factors always present in quality engineers, independant of language and platform.

Identifying Senior Software Engineers: Six Critical Differences