Category: General

A man goes in to see his doctor, and after some tests, the doctor says, “I’m sorry, but you have a fatal disease.”

Man: “That’s terrible! How long have I got?”

Doctor: “Ten.”

Man: “Ten? What kind of answer is that? Ten months? Ten years? Ten what?”

The doctor looks at his watch. “Nine.”

one way to make sure that sql injections NEVER happen is to use a prepared statement

perl has been doing it for ages, so by now it should be mainstream, yeah? I wish. but if you’re behind the curve, no worries, here’s how to do it. this is for a simple contact form.

$stmt = $mysqli->stmt_init();
//prepare the statement, use ?'s for where you want to put variables
$stmt->prepare("insert into tbl_contact(contact_fullname,contact_phone,contact_email)
							values (?,?,?)");
//bind your variables to the statement, in order. "sss" means string-string-string
$stmt->bind_param("sss", $_POST['fullname'], $_POST['phone'], $_POST['email']);
$stmt->execute();

• use a question mark for every time you want to use a variable
• for bind_param, the “sss” means I am going to be substituting 3 strings for the question marks. if I said “sis” that would mean I have one string, then an integer, then a string

still using Internet Explorer 6? why? I could go on and on about specifically why you should upgrade from an almost 10 year old piece of software, but I’ll keep it simple.

web programmers have to develop with all users in mind (well, they should). but, developers shouldn’t be wasting time trying to ensure that their feature-rich website has backwards-compatibility with archaic software such as IE6.

IE6 is a detriment to progress in web-based technologies, and degrades the overall user experience.

SO: the point of this post!

please visit http://www.browserforthebetter.com

this website will donate 8 meals to Feeding America for each upgrade to IE8 through September 30th. it’s FREEand I promise you, it’s the same internet…just better.

writing if statements like this is tiring, and wastes lines 🙁

if (isset($_GET['some_variable'])
     $some_variable = intval($_GET['some_variable']);
else
     $some_variable = -1;

try this:

$some_variable = (isset($_GET['some_variable'])) ? intval($_GET['some_variable']) : -1;

I always hated having to manually parse out an XML file back in the day. but now, as of not really that recently, you can use SimpleXML to automatically convert an XML file to an array-like structure of objects. you do have PHP5, and the php-xml package, right?

$sxml = simplexml_load_file($filename,'SimpleXMLElement',LIBXML_NOCDATA);
print_r($sxml);

amazing, eh? the LIBXML_NOCDATA keeps all CDATA enclosed data from disappearing on import.

$filename = "some_file.xml";
// this works too, if your server allows it
// $filename = "http://www.remote.xml/filename.xml";
$sxml = simplexml_load_file($filename,'SimpleXMLElement',LIBXML_NOCDATA);
$sxml->page; // references body of an XML element
$sxml->page->attributes(); // returns attributes
foreach ($sxml->page->attributes() as $key=>$val)
{
	print "Value of $key is $val
";
}

Away in a pointer, the bits in a row.
A little dereference to see where they go.
I look down upon thee, and what do I see?
A segfault and core dump, right there just for me.

I saw thy init there, a reaping away
My process, from its address space, so sorry to say.
I thought I had saved thee, from void pointers all,
But maybe I missed one, and doomed you to fall.

Be near me, debugger, I ask thee to stay
Close by my terminal, and help me, I pray;
To find all the bugs and the void pointers too,
And if my kernel oopses, help me reboot for you.

by Eric Spiegel
http://itmanagement.earthweb.com/features/article.php/12297_3771746_1

I was sitting down with one of our most productive software developers for his annual review, trying to carefully craft my words. You see, Tyler had produced some amazing results that year in tackling our most difficult assignments. Praising him was easy… almost too easy.

My conundrum over word phrasing was a direct result of the way he worked with the rest of his peers on the team.

How did Tyler’s teammates perceive him?

The descriptive words I can print were brash, arrogant, overbearing and even cocky. It’s important to consider that these other developers were not in his league, at least not when it came to solving the most difficult technical challenges.

I actually believe the majority of the team was intimidated by Tyler’s technical prowess. To help understand their viewpoint, let’s examine his impact on overall team cohesiveness.

One of the more productive project management tasks this team participated in were peer to peer reviews. In these reviews, Tyler dominated the feedback. He never hesitated to express his opinion, although some might have even considered his views as mostly subjective and sometimes overly aggressive.

I had no problem with this because these code reviews were meant to challenge and enlighten the team, bringing to light alternative approaches. As long as the attacks weren’t personal and everyone acted like professionals, lively discussion produced improved results.

What I was concerned about was that when Tyler participated, the others would clam up. Why? Because Tyler was quick to shoot down their ideas and rarely accepted, let alone objectively considered, opposing opinions.

Tyler almost always prevailed in an argument and when he didn’t, well, it wasn’t with grace. He would generally respond with a tone of snickering like “Fine, do it the stupid way, but don’t blame me when load testing fails.”

And you could be sure if it did, there would be an “I told you so” loud and clear, usually through an email to the team where Tyler would bask in the glow of his triumph – at the expense of team morale.

I had originally decided that as the team manager, I shouldn’t attend these code reviews. This turned out to be a double-edged sword. On the one hand, I wanted the developers to feel free to constructively criticize each other’s work without being afraid of how their manager would react to their honest feedback. On the other hand, when Tyler participated he ultimately had the same undesired effect of shutting down the open expression of ideas.

Finally, I reluctantly decided to sit in on code reviews. This was met with a sigh of relief from all the developers, even Tyler, but for very different reasons.

The majority of the team hoped I could temper Tyler’s aggressive style, while Tyler was happy to show off his talents to the person in charge. Almost immediately, a debate broke out over memory management in a C# application. I believe my presence encouraged a couple of the others to speak up. When Tyler started to snidely cut them off, I decided to step in and stated that everyone should have a chance to finish their points.

Tyler, being a C++ guru, felt strongly that using manual memory management techniques was the most effective approach to ensure unused memory was released. The others weren’t comfortable with this approach and felt just as strongly that automated memory management (i.e., garbage collection) was a more efficient approach for this project because it was written in C#.

There were merits to both approaches. Not every developer on the team had the skill to correctly implement manual memory management, and C# handled garbage collection just fine, under most circumstances. However, for high volume processes that required close to perfect memory management, it made more sense for someone with Tyler’s skill to implement a manual approach.

I digress, because the technical details aren’t as important as the way Tyler approached his fellow developers on this issue. Instead of insisting that he was correct and effectively calling the rest of them morons, there should have been more of an objective approach. An approach that considered the skill set of the team, the importance of memory management for this particular module, and the ability to set standards that the majority of the team could follow.

We were all able to agree that garbage collection was our project standard, and that manual memory management was the exception based on need. Even Tyler acquiesced. I praised him afterward.

You know what his response was?

“Hey man, not a problem. I realize that my skills are on another level. You can’t clone me, right?”

So maybe this wasn’t quite the step forward I had hoped.

The Review

Perhaps you can now better appreciate my careful consideration of wording as I prepared to deliver Tyler’s review. In my mind I said “Tyler, you are an excellent software developer, but you need to be more respectful of your teammate’s opinions.”

In reality, the words that came out of my mouth were “Tyler, you are a great developer, but frankly your peers think you are cocky.”

He smirked and said, “I like to think of myself as confident, not cocky.”

Okay, not a bad retort.

I asked him why he felt so self-assured. Tyler said “Look, I’m usually right. The others don’t have my experience with true, hardcore development. I don’t rely on automation; I rely on my mad skills.”

Mad skills? I heard this term used by the six-year-olds I coached in soccer, so I got it…but geesh!

After considering his response, I said “I’m okay with you feeling good about your “mad” skills, but there is a difference between confidence and cockiness. As a good teammate, you can use your confidence to share your vast experience with the team in peer reviews. The difference is, if you belittle someone, you are being cocky and frankly not helpful. We need the team to be confident, and you can lift the team up by being more respectful of their opinions and taking a mentoring approach, instead of dictating your opinions.”

Tyler simply nodded in response and was actually quiet through the rest of the review. I must have struck a nerve, perhaps positively or maybe I simply ticked him off.

Over time he still had his brash moments, but he also made attempts to teach his points. Certainly he disagreed many times, but instead of thumbing his nose at everyone when his point was vindicated, he actually talked civilly to the dissenters and discussed why his position ended up being validated.

Sometimes it’s better to be direct with “cocky” developers who might appreciate being called out on the carpet. You just may end up with a more confident and productive development team.