Earlier this week I found myself in an interesting spot. We had a hell of a bug come though that had no real reason for existing, much less any kind of answer to "how did this even get there?!". Someone mentioned I should use git bisect -- I'd never heard of this. It's a little strange at first, but once I got the hang of it, it's really slick.
Say for instance your on your repository on the latest and greatest and you find a bug was introduced ... say ... three weeks ago. You don't know when exactly, but you know it was sometime in that time frame. Grab a hash code, (treeish, the first few letters of the hash I'm told are usually enough for uniqueness) and go ... something like this ...
git bisect start HEAD <someHash>
and you'll see something like this ...
$ git bisect start HEAD <someHash>
Bisecting: 174 revisions left to test after this (roughly 8 steps)
[someMiddleHash] Comment for that commit
JRiley@JRILEY /c/Projects/Core ((someMiddleHash...)|BISECTING)
What git will do is say ok, somewhere between HEAD and <someHash> was a screw up, so it will pick the middle commit and give that as a starting point. Build, do your dance and determine if its a good (problem isn't there) or bad (problem still exists) as such ... in my case, I'll say its bad.
$ git bisect bad
Bisecting: 86 revisions left to test after this (roughly 7 steps)
[yet another hash] comment for that commit
Today at the office I gave a presentation on encryption. Attendance was very very light (4pm on a friday, no surprise ... ?) and I was even asked if I wanted to reschedule -- na, I'll do it twice if I have to. Wow did they miss out. I had discovered that the methods of applying encryption were amazingly important, and I'll be damned if I couldn't replicated it. I wanted to see this for myself as it broke every rule I had known or in other words, perfect. First I tried hacking up a jpeg file until someone pointed out the obvious -- it's got it's own "encryption" and suggested I bounce it over to bmp, a raw format. What a great idea and how did I miss it? But I'm getting ahead of myself, let me step back and talk about encryption...
Encryption in and of itself is very technical once you get into the modern age. Very specific, lots of math, probability, etc make it a subject most people just glaze over and shut down. I'll do you one better. I see your glazing and raise you an awesome visual. While doing my research for this presentation, I ran across something absolutely facinating which I touched base on earlier...
Encryption algorithm and of itself is not the whole story. Not even close. I'm seriously starting to wonder if, holistically, its method is JUST as important than its computation/execution. Why? Allow me to explain and consider this image. (warning -- shamelessness !!!) More...
When I was in college, one of the classes we were forced to take was psychology. I had taken a class in high school, and looking down the list of items this class would cover, I was expecting another boring, useless class. I was right, with a slight exception -- the professor, Tony Obradovich, I had not expected. I took a second class per my own direction and made sure he was teaching it. How awesome it was, and based on his reviews, he's still awesome today -- as I would expect.
Professor Obradovich would talk to us about the times he was a kid and would repeat things he would hear from authority figures (his dad specifically about someone following too close) and how his patients were struggling with different aspects of addiction -- most were drug, alcohol and I think even one sex addict. More...
Just a few days ago I was tasked with a rather interesting and challenging feature -- create a history tracking service that was more or less transparent and easy for other devs to use. Started to dig into certain parts of nhibernate, I quickly found a few comments about "IPreUpdateEventListener" -- great, cool, that's what I need ... well, almost. More...
Today, I moved my webhosting off of UltimaHosts onto discountasp.net for one sole reason - I under prepared for hosting my own stuff. I was on Ultimahosts for a while ... a long while. They introduced me to DNP (dotnet panel, the BEST freakin web management tool that you probably never heard of) and was moving forward to host my little website on my home network. It wasn't until this morning I discovered "hey dummy, you need to do all this work to make this happen" heh, whoops.
I will continue to whole heartedly recommend Ultimahosts. I've used them for some clients, for myself, and if anyone needs more than just a REALLY basic host, thats where they need to go. Period.
A ton of companies have jumped on the twitter train in the past year or so. Some of which has had great success. Others I feel are seriously hurting their image. Why? They use twitter strictly as an rss feed generator.
Before anyone signs up for twitter they have to should ask "what's this for?" -- a question I feel people completely ignore. Is it your outlet for ranting and complaining? Ok, great. Is it your way of getting in touch with similar minded people? Cool. Is it to interface with customers in a manner you normally wouldn't have a chance at talking with / fixing a problem / providing (GASP) customer service? Even better. Use it to just display articles for your corporate blog? Mmmmm, FAIL.
I've said this before and I'll say it until companies get it -- twitter is not your RSS feed generator. Period. Even twitter suggests "While you shouldn’t feel compelled to follow everyone who follows you, do respond to some questions or comments addressed to you." (emphasis mine) That means if you have a feed that's nothing but links ... you've failed. Also, twitter is (surprise) real time. Responding in 12 hours to someone will confuse the hell out of them, respond as quickly as possible or at least say "let me find out". It doesn't matter if you're a big money company, a pro sports team, or some guy, it does not matter -- twitter is -personal- so treat it as such. Even Chad Johnson Ochocinco responds to people from time to time. Why aren't you?
I went to the path to agility conference yesterday and a short story caught my attention. Ken Schweiber talked about a neighbor (I think?) he got an internship for doing some QA work for a software company. After their graduation, he offered to help get them a full time job - the answer was amazing : "Hell no".
Because of this person's experience, there was no desire for that person to go into software dev. Horrible code quality, missed deadlines, angry unhappy people, the toxic cocktail that can kill any project (and morale) was rampant. Sure you could argue that's an isolated experience, but is it really? I'd like to think it is, but it isn't. Worse, I know someone I think is on that edge, to the point of NOT wanting to be in software anymore. Frustrated, feeling left behind, etc, I decided to dig a little bit into this - I genuinely want to know where this profession began to break down and fail to serve the person that at some point enjoyed it. I love software, I think it's fun but that's not the whole picture. I invited this person to lunch and what I nailed down as the answer is one you've heard before. More...
Normally I don't talk about my family, at all, but this one is necessary because ... well it's funny and yet very cool. Recently I've been working with my dad on a little app he wanted done. Not only is my dad a great "customer" but he's damn good at telling me exactly what he wants ... in his own way that I find just hilarious.
As with most people that write software, most family members have NO IDEA what I do, at all. Normally my reply to what do you do is the default "I work with computers" and that usually scares them off or leads to the cliche discussion of how their computer is suddenly slow (full of malware and porn) and they want to know what to do. I did get sucked into doing some work ONCE and I vowed never to fall for that again. They're the worst customers on the planet and you don't get paid to do it nor is there any satisifaction out of it.
Anyway, a while ago, my dear ole dad says to me "so you make websites right?" More...
Lately I've been running into a rather interesting problem. I'll go write out a new test, and I won't get one test that fails, I'll get ... 30. At first, my reaction was "oh !!@$% I broke something" -- not the case. Well, I digress, I did mess something up, I changed the value on one thing that caused the next pile of tests to fail.
Some could argue "that's bad design" blah blah, yea thats great, but it STILL wouldn't address the real problem -- bad test data setup. So I've setup what I've begun to call a "sanity" test. At first I meant sanity to mean sanitary but lately sanity means "keep you from going insane". So how do I do this? Easy, and it really does help in the long run when something is broken.
First off, most tests have various setups of some kind. Take this for example ...
protected TestClassThatNeedsSomeLovin testClass;
protected const string dummyString = "some value";
protected const int dummyInt = 1;
protected DateTime dummyDate = DateTime.Today;
public virtual void SetupData()
public void SanityTest()
And that's it for the "base" class for tests. This particular one has special cases so it made sense to do this. Otherwise, pound out your test data right there in the setupdata, done and done. Now, everytime I have a pile of tests that fail for some unknown reason, I can just run my sanity test to make sure "yea, its valid as sits" meaning all my test data is correct and valid. Otherwise its kind of silly to be chasing after 30 failed tests when you forgot to change your dummyString to dummyEmail :-)
I've been on a few projects recently where "no one wants it", "no one wants a part of it", "it's terrible", "oh you're on that ... good luck" and every type of don't-want-it you can imagine. The type of project you -really- want to ask the people that were there before and ask them just WHY. The client knows it, you know it going in but you do it anyway. Then something totally unexpected happens... it doesn't fail. It may even become an amazing success, and even more oddly, it usually does.
So why don't they fail?
Since I've been off a particularly challenging project, I've had time to not only be on another failure assumed project, but think about what happened. Interestingly, a video game summed it up. There's an intro in modern warfare 2 that talks about the characters being on a suicide mission. They know they're going to die doing this, but there's a bit of liberation, a freedom that occurs when you know something is -going- to end but you get to decide that outcome. It releases your mind to do things you normally wouldn't consider acceptable, much less possible. "It's stupid enough it just might work" is a requirement.
This is where the original problem was kept, hidden from view.
I've now sat here for half an hour, writing and rewriting an explanation of a blend of contained creativity and fear of failure seem to truly cripple projects. I can't come up with concrete examples nor even theoretical examples -- yet somehow the argument still seems valid. I'm not sure if the expectations need to be adjusted, such as on style. Who says "this is the way yee shall render a grid!" ... there's reasons why cars, homes, businesses all look different. When people are told "we have no idea how this is going to work, but we want to you to <accomplish something>". Maybe a focus needs to be on the resulting end goal instead of all the problems on the way?
To return back to my own promise of posting "how long did this take" -- this post took 2 hours and one review by someone not in the tech world ... at all.