Don’t Say Geek! Say Syntux!

I have always been jealous of RoR but I did not to switch and kill my passion to PHP at the same time there was no PHP framework that satisfy my needs to RAD so I stopped looking until recently I was introduce to Symfony Framework but didn’t had the time to dig much into it as I’m not full time programmer anymore but I kept an eye on it and kept digging it as a Todo.

Couple of days ago I got The Definitive Guide to Symfony and unlike many other technical books it’s authored by the author of the framework and the framework documenter which is a great plus when buying a technical book.

If you are not used to MVC frameworks then you should understand that learning curve in Symfony is a pain that worth going through and it will heal any pain you used to get when developing without a framework, nevertheless the guide book makes it way easier, the book is well written in an easy language

I will keep you update as I’m reading the book.

Tags: time programmer, learning curve, easy language, ror, definitive guide, technical books, couple of days, full time, passion, symfony

Don’t ever delay your orders; there is no mean of grouping your packages to save shipping cost especially if something like this would happen

Now, I’m not going to order that book.

Tags: Amazon, order, price, increased , shipping cost, amazon

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