Digital Transition

Implode

The PHP function implode is one I use frequently.
When you have an array of strings and want to put them in a string, separated by commas, you can either write a loop like this:

$arr = array('one', 'two', 'three', 'four', 'five');
$str = '';
foreach($arr as $item)
{
$str .= $item . ',';
}
$str = substr($item, 0, strlen($str) - 1);

or you can use the php function implode like this:

$arr = array('one', 'two', 'three', 'four', 'five');
$str = implode(',', $arr);

This is super!

__ToString Magic Method

On the other hand, there is the __ToString magic method for PHP classes. It allows you to give a string output for your class. Take this simple HTML paragraph class as example:

class p {
private $content = null;
public function __construct($content) {
$this->content = $content;
}
// Some more code
public function __ToString() {
return '<p>' . htmlentities($this->content) . '</p>';
}
}


The problem

Now when you want to combine both, it won’t work:

$arr = array();
$arr[0] = new p('test 1');
$arr[0] = new p('test 2');
$str = implode("\n", $arr);

This will give you a “Warning: implode() [function.implode]: Invalid arguments passed.”

1. SRP (The Single Responsibility Principle): A class should have one, and only one, reason to change.
2. OCP (The Open Closed Principle): You should be able to extend a classe’s behavior, without modifying it.
3. LSP (The Liskov Substitution Principle): Derived classes must be substitutable for their base classes.
4. DIP (The Dependency Inversion Principle): Depend on abstractions, not on concretions.
5. ISP (The Interface Segregation Principle): Make fine grained interfaces that are client specific.

And 2 extra ‘guidelines‘ that is actually from procedural programming, but still applies to methods:

1. One point of return: The function or method should only return a result at 1 location in the code, at the end of the function/method.
2. Only one functionality: A single function or method should only have 1 functionality. In case it has more than 1, it should be split up.

[Via: ButUncleBob.com]

As most of us know, e-mail can be a powerful tool! If it is used correctly, it can even save you a lot of time and energy. So here some guidelines in writing good e-mails to improve your productivity.

Choose a good subject line.

When choosing a subject line, try to capture what the e-mail is about in less than 1 line of text, ie: “ProjectX: followup” or “Internal meeting notes 28 February”. Both examples let you easily see what the e-mail is about. This is a lot better than: “Please read this”.
When you’re e-mailing to someone who manages more than one client or project, try putting the name of the client or project first. This also helps with filtering e-mail by using rules.

Indicate if an action is needed.

Try to indicate if an e-mail needs action from the reader and put this in the subject line as well, ie: “FYI – Last nights soccer scores” or “Project X: Approval needed – change requests”.

Don’t abuse the ‘high importance’ flag

All too often you get an e-mail flagged as high-importance. 90% of the time, this is not needed. When a server is scheduled to going down, this is just a notification and it doens’t need high-importance. When a clients server crashes, now that’s high importance.
Try also use the low importance flag for informative or notificational e-mails.

Reverse the structure

E-mail is different from a memo or a functional analysis. Most of those documents start with an introduction, then fully explain the contents, followed by a summary. For e-mail, keep is short. Only write the major issues, use bullitpoints or when it has to be a long e-mail start with a summary. If an e-mail tends to become too long, write a separate document, attach it to the e-mail and write only a summary.

One subject only

When you need to discuss more than 1 issue which are not related to each other, don’t put them all in 1 e-mail. Write 2 separate e-mails with different subject lines so the e-mail can be easily found later on. This also goes for changing the subject in a communication, just leave the e-mail for what it is, and write a new one, with a new subject line.

Know its limitations

Some issues are just too complex to discuss by e-mail. They are prone to misunderstandings, to making the e-mail too long and uninteresting to read, or just require you to show certain interactions on screen.
So don’t forget phonecalls (Skype anyone?), instant messenger, desktop sharing, or even an in person encounter.

Hopefully some of my e-mail senders read this

Looks like Microsoft is listening to their users. They posted some things that will be changed in the RC version of Windows 7 on their development blog.

A great article at devhardware.com entitled: The Digital Transition, explains what will happen when the US changes from analog TV to digital TV. The date was February 17 2009, but Obama changed it to June 12.
I’m curious when this will occur in Belgium.