Syntux the geek

The Unambiguous Information Society

Communicating your message unambiguously means it can only be understood one way. Whether speaking or writing, do your best to strive for clarity. Before you speak or write, examine the message closely for any ambiguities or potential holes that could lead to a misread. Obviously, you will not always have the luxury of self-examination before you speak or write, and in these instances repetition is the way to distil or parse the message to its essence. Repeat yourself, or ask repeatedly for clarification, until both parties get the point.

Distilling technical minutiae into clear, unequivocal language is a challenge for everyone on the team. Look at the following.

PROJECT MANAGER: Does the system only check user name and password for authentication?
DEVELOPER: E-mail is the unique identifier for authentication in the system.
PROJECT MANAGER: What about user name and password?
DEVELOPER: Yes. Those, too.
PROJECT MANAGER: So user name, password, and e-mail are all used for authentication?
DEVELOPER: No. Only e-mail.
PROJECT MANAGER: So a user can put in the wrong user name and password but use an e-mail address the system recognizes and get in?
DEVELOPER: Yes and no. A user can have multiple identities but only one e-mail address.
PROJECT MANAGER: So what you are saying is a user could enter any old user name and password along with an e-mail address the system will recognize and get in. Right?
DEVELOPER: Yes, the user can enter any login they want, but if the e-mail address is not in the database, they won’t get in. If the e-mail addresses match but not the user name or password, they will get a message saying the login is incorrect.
PROJECT MANAGER: So, then, they can’t get in?
DEVELOPER: They could if they enter a user name and password that matches what is stored in their profile.
PROJECT MANAGER: So, then, what you are saying is user name and password are not the only fields being checked for authentication?

DEVELOPER: Well, actually, yes, but technically, no.

PROJECT MANAGER: I’m going to shoot myself now. Care to join me?
DEVELOPER: Not today, thanks.

Source: Real Web Project Management: Case Studies and Best Practices from the Trenches by Thomas J. Shelford, Gregory A. Remillard

Tags: e mail address, mail project, unequivocal language, communicating your message, self examination, minutiae, ambiguities, red flag, information society, repetition, stakeholders, clarification, questions and answers, clarity, authentication, team members, instances, holes

Ok, WTF Or LoL?

Tags: coding standards, adobe photoshop

A Jordanian start-up is looking for 5 really smart programming junkies, or wannabies

Experience or fresh doesn’t matter, just shoot me your CV.

Jad [ at ] syntux [ d o t ] n et

Tags: jordan middle east, smart programming, php programmers, just shoot me, jad, junkies, cv

Perhaps no other coding practice is as important as testing your code. Also in the nature of Business Development, where parts of your code always change on the request of a client (including Management), or even when you want to make your code run with better performance, Automated tests are highly needed, you can’t just spread your print statements all over your code every time you need to test it.
With automated tests, you can just be sure that your interface is not broken after some change, you just run your tests, if they succeed, you know that you didn’t break your code (this means you should right good tests).
Let’s start by a simple example, Imagine that we have been asked to test PHP’s built-in Array. One bit of functionality to test is the function sizeof(). For a newly created array we expect the sizeof() function to return 0. After we add an element, sizeof() should return 1. (I know it’s not a big deal, but it’s just an example).
you can do it with simple print statements (i.e. print (1 == sizeof($myArray) ? "OK":"Failure").PHP_EOL; ), but here we are going to do it by using an assertion function.

< ?php
$fixture = Array();
assertTrue(sizeof($fixture) == 0);

$fixture[] = "element";
assertTrue(sizeof($fixture) == 1);

function assertTrue($condition) {
if (!$condition) {
throw new Exception("Assertion failed.");
}
}
?>

Well, we could know if something went wrong if some Exception was raised, of course assertTrue is not the only thing you want to do, UnitTesting has gone far beyond that, usually UnitTesting frameworks provide a whole lot of features that you need for your testing.
Lot’s of Testing frameworks are available for PHP, I’m going to point to 2 of them, the first one is SimpleTest (http://simpletest.org/), it’s written in PHP 4 (Although they are going to migrate to PHP 5 when they reach version 2), so you can use it on both PHP 4 and 5 programs, also it includes a nice HTML reporter for some good looking html results the same test above could be written using this framework as:

< ?php
require_once 'simpletest/unit_tester.php';
require_once 'simpletest/reporter.php';

class TestingFixtureArray extends UnitTestCase {
function TestArray() {
$this->UnitTestCase(“Testing Fixture Array”);
$fixture = Array();
$this->assertTrue(sizeof($fixture) == 0);

$fixture[] = “element”;
$this->assertTrue(sizeof($fixture) == 1);
}
}

//run the Test
$test = new TestingFixtureArray();
$test->run(new HtmlReporter());
?>

Another Well know testing framework is known as PHPUnit2 (http://www.phpunit.de/), it’s available through the PEAR Repository, you can install it as
$ pear install PHPUnit2
It’s written in PHP 5, and is so widely used within PHP Developers, a good resource for learning how to use it is the free available online book PHPUnit Pocket Guide (http://www.phpunit.de/pocket_guide/index.en.php), the same example could be:

< ?php
require_once 'PHPUnit2/Framework/TestCase.php';

class ArrayTest extends PHPUnit2_Framework_TestCase {
public function testNewArrayIsEmpty() {
// Create the Array fixture.
$fixture = Array();

// Assert that the size of the Array fixture is 0.
$this->assertEquals(0, sizeof($fixture));
}

public function testArrayContainsAnElement() {
// Create the Array fixture.
$fixture = Array();

// Add an element to the Array fixture.
$fixture[] = ‘Element’;

// Assert that the size of the Array fixture is 1.
$this->assertEquals(1, sizeof($fixture));
}
}
?>

and you can run it on command line as
$ phpunit ArrayTest

Additional benefits that you can realize by thoroughly testing your code:

• Testing forces you to write code that is easily testable. This leads to looser coupling, flexible designs, and good modularity.
• Writing tests forces you to explicitly clarify your expectations of how your code is to behave, distilling your design into sharper focus from the beginning. Writing tests forces you to consider the universe of possible inputs and the corresponding results.
• Tests are very explicit way of communicating the intent of your code. In other words, test cases act as example and documentation, showing exactly how a given class, method, or function should behave. A test case defines how code works in a non-ambiguous way.

Finally, if your test suite – your set of test cases – is very thorough, you can say your code is complete when all of your test pass. Interestingly, that notion is one of the hallmarks of Test Driven Development.
Test Driven Development (TDD), also referred to as Test First Coding, is a methodology that takes testing one step further: you write your tests before you ever write any code. A nice, brief summary of the tenants of TDD is available at http://xprogramming.com/xpmag/testFirstGuidelines.htm, and a good introductory book on the strategy is “Test Driven Development: By Example” by Kent Beck. (The book’s examples are in Java, but it’s a quick read and gives you a very good overview and introduction to the subject.)

Agile Development
Recently, unit testing – in particular Test Driven Development – has been associated with agile Development methodologies such as Extreme Programming (XP)g that focus on rapid iterations of releasing functional code to customers and welcoming changing customer requirements as a natural part of the development process. Some good online resources for learning about agile development include:

• http://en.wikikpedia.org/wiki/Agile_software_development
• http://agilemanifesto.org/
• http://www.extremeprogramming.org

Tags: automated tests, sizeof, business development, array, functionality, element, nature of business, interface

The path of the righteous coder is beset on all sides by the iniquities of the selfish and the tyranny of evil Ruby Users. Blessed is he, who in the name of PHP and good code, shepherds the weak through the valley of Rails, for he is truly his brother’s keeper and the finder of lost Syntuxes. And I will strike down upon thee with great vengeance and furious anger those who would attempt to poison a and destroy my brothers.

Tags: ruby users, furious anger, iniquities, vengeance, tyranny, brother