Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×

Comment Re:Linux kernel (Score 2) 373

1 Handles errors gracefully.

This statement always hits me as mind numbingly stupid. In general try / catch and other error managing statements are for the lazy that don't want to understand the environment and inputs well enough to write the proper code to manage them. You want rock solid code that will last for years, eliminate the errors, don't "handle them gracefully". The only exception to this rule should be when the native environment forces it upon you or there is a lack of some proper check "doesThisReallyExist()".

By errors I meant where paths and files don't exist, the user or external software sends bad info or someone runs or the machine runs out of resources. Case in point: someone edited one of our databases in a place I used to work and some software crashed hard when it grabbed a NULL value from the database leaving me to check the core dump to discover the problem.

2. Only reinvents the wheel when there is a measurable benefit in doing so..

I learn more reinventing the wheel and there is no substitute to working with code you are sure of and know how it's going to perform.

I agree with the rest.

I can see wanting to learn.. I can't see duplicating system libraries in a project. Some libraries (Libc in particular) have whole groups of programmers who are rather good at squeezing every last drop of speed out of the implementation, there are also things such as leap year handling that look simple but end up being harder than they look.

Comment Re:Linux kernel (Score 1) 373

Library bugs would equate to a "measurable benefit" to reinventing the wheel. I am not saying you should never replace a library function only that it shouldn't be your first reflex. I would only suggest that you document why you created your alternative routine in your code somewhere so someone (or possibly you years down the road) can easily spot why it was used instead of the existing library function so there is not time wasted later rediscovering the bug.

Comment Re:Linux kernel (Score 5, Insightful) 373

I strongly disagree with this. While I admit that elegant code can have ugly portions refactoring will often be an improvement but the trick is to learn when refactoring will help and when it will be a waste of time. The worst programmers I know are the ones who say that "I don't have time to go back through my code". I have cleaned projects where the original coder did the same thing three different times or reinvented the wheel when there were better libraries. In fact, I have been also guilty of this and even in my own projects I have come across places where the requirements changed out from under me mid project or I simply see better ways of doing things as I gain experience.

Elegant code:
1 Handles errors gracefully
2. Only reinvents the wheel when there is a measurable benefit in doing so.
3. Has consistent naming conventions.
4. Has comments around ugly code explaining why it is ugly.
5. Compiles (or runs if interpreted) without warnings.

Comment Re:Time = Money (Score 2) 101

Groupe Telecom used to be like that since they considered themselves too big to fail (or rather too big to be taken down). I had a decent job until the final months of the job where my boss (Leo Kuvayev before his infamous spammer days) decided to team up with Alan Ralsky and Spam the crap out of some porn sites. Before they started they were assured by their account manager that all complaints would be ignored. After trying to talk them out of it I quit and moved on to another job.

A few months later I ran into my replacement in an elevator while he was searching for new hosting. It seems Group "Were a billion dollar company" Telecom were forced to change their policy thanks to multiple blacklists that did a lot of damage to their business.

Comment Re:Yeah, you can totally trust your data... (Score 1) 335

In reality, Google only offers 99.9% per month (99% for "reduced availability", I'm not sure what these prices are for) and the value of the guarantee is pathetic: they credit (not even refund) you a maximum of half your bill that month if availability is =95%. They could be down a full day and only knock 25% of you bill next month. That can barely be considered an SLA.

In my experience that is even better than most SLAs I've seen. Standard is to prorate the month and reduce that month's bill or add a credit to the next for the amount down so if you are paying $1000 monthly and you are down a day you get $33.40 back (assuming 30 days in the month).

Comment Re:Horse Battery Staple is common too (Score 2) 299

If I had to guess, I'd guess that the website uses the password to authenticate to a mainframe somewhere and is just a front end for some EDBIC based protocol so cracking the website wouldn't get access to the actual list.

Not that it excuses the short limit, but then I'm hard pressed to find something better considering our banks all got together and designed a PayPal competitor that
A. Is designed not to compete with their credit card processing system.
B. Is designed around clicking links in emails.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...