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

What’s free, looks like a Mac and is actually Linux?

The answer is gOS, a lightweight, web-heavy operating system that anyone can use.

The emphasis in gOS is on web apps and everyday tasks like browsing the web and checking e-mail. Under the hood, gOS is based on the solid Linux distribution base of Ubuntu 8.04.1, but aside from that familiar startup sound, you’re unlikely to notice the Ubuntu underpinnings.

gOS instantly launches Google Gadgets for Linux on startup, introducing over 100,000 possible iGoogle and Google Gadgets to the desktop. Google Documents, Calendar, and Mail launch in Mozilla Prism windows to closer resemble desktop applications. The newest release of WINE 1.0 is included to now support thousands of Windows software.

http://www.thinkgos.com/

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