Archive for May 2008
wrote a great article on best practices and how “best practice” is essentially a bunch of bullshit:
About the only thing [Best Practice] means is ‘I have found that doing XYZ in ABC way works the best for me’. But just because it works for you, or even works for a group of people that does not mean it is ‘Best Practice’.
I’ve never really thought about it but this is 160% correct. Even now, at my current job we are reviewing Spiral, Agile, TDD and other SDLCs in order to conform to “best practices”.
Thankfully my boss understands that what works for some may not work for all and if something isn’t working we won’t have time to try to screw with it. We’ll have to move on and find something that fits better. This is exactly how “best practices” should be treated. As suggestions on how to handle software development.
There is no “one ring to rule them all” in our world. There are many rings each has a different fit to it and needs to be tried on to see where it fits best.
When you need to find out the type of an object in JavaScript you would just do the following:
[sourcecode language='jscript']
var x = 1;
alert(typeof x);
[/sourcecode]
Well what if x were an array? With x as an array a typeof incorrectly returns “object” as the type. Well that is just plain wrong. Enter the isArray() method.
[sourcecode language='jscript']
Object.isArray = function(o) {
return o && o.constructor === Array;
};
[/sourcecode]
Granted it’s not as simple as typeof but it does correctly identify array objects and is something every JavaScript developer should have in their code garage.
I write a lot of javascript at my job and I often find myself in a horrible debugging situation where something isn’t working right and I need a way to find out what properties and methods an object has quickly. I’ve found the following code very helpful in determining this.
[sourcecode language="jscript"]
Object.Enumerate = function(o,t) {
var type = typeof t === ‘undefined’ ? null : t;
for(var key in o)
{
var value = o[key];
// if the user did not pass a
// type then “alert” each member
if(type == null ||
typeof value === type)
{
alert( key + ” is a ” +
(typeof value));
}
}
};
[/sourcecode]
This is a really simple method that will take an object and (optionally) a string representation of a type (“number”, “object”, “function” or “string”) and will display the members that match those types (or if no type is passed it will display each member and it’s type).
[sourcecode language="jscript"]
//basic object for testing
var x = {
int: 1,
str: “”,
func: function() {
},
obj: {
str2: “”
}
};
// alerts each member of ‘x’ and it’s type
Object.Enumerate( x);
//alerts “func is a function”
Object.Enumerate(x, ‘function’);
[/sourcecode]
This code is really similar to how prototype generates JSON information and can easily be modified to return various types of data back to the requestor.
Note this code isn’t perfect, for instance it doesn’t account for Arrays which are typed as objects in javascript. Also it doesn’t do any sort of recursion so it will only return top-level members.
But even so this is still the most used script in my library and I make sure I have it in all my projects. Hopefully it helps someone else.
I’m relatively new to the world of professional software development. I got my start hacking away in Visual Basic back in 1995 and didn’t do any sort of development for money until 2004. Yeah I’ve only been a software developer for 4 years now. It’s sort of scary being a noob in real life. There is a lot to learn: the culture, what to say, what to do and most importantly what not to say and what not to do.
The hardest lesson I’ve had to learn is to not be afraid of the words “I don’t know“. I used to assume I knew the answer to everything or that I was expected to know the answer. I was wrong. Nobody has all the answers and those people that seem to either A) are being asked the right questions or B) are making it up.
It’s hard looking your boss in the face and saying that you don’t know the answer to whatever he/she is asking you but it’s even harder to say it later or worse: when he/she finds out on their own.
Another thing I’ve learned that you never say “yes” under pressure. Ever. If someone comes to you to ask you for something and you are occupied or in a rush then simply say so. Say “I’m really busy right now, give me some time to come up with an accurate assessment”.
If the person needed the estimate 5 minutes ago then qualify your response: “I’ll need more time to get you an accurate assessment but my best guess right now would be…”. This can really save you some stress further down the line.
Also, Read. Read everything. Read blogs, MSDN Articles, newsgroups, magazines (“Code” is pretty good) and most importantly books. Programming books have almost fallen off the list of a programmers best learning tools but not entirely. I’ve learned almost as much from books as I have from actually writing code. If you are unsure about exactly where to start Jeff Atwood has a really good reading list.
No tags
