I did a few open spaces a while back and noticed a theme within many themes of the topics : as a community, we're really really good at prescriptive remedies -- "have this problem? Talk to your agile authority and use this tool/practice/method" which is largely a good way to fail. Go ask your doctor/mechanic/landscaper/lawyer for <insert fix for problem here> and they're going to ask you a TON of questions (if not, leave), maybe do some research or tests and you might end up with a different fix or nothing all together. Why? It's never that simple as checking all the symptom boxes and saying that's what you need, yet as a community, that's what we've been doing, a lot.
- Confused about your process? Use kanban ! (guilty)
- Stories take too long? Use scrum !
- Not delivering ? Use XP !
- Need visibility ? Use this tool ! More...
Recently I've found myself in Salesforce land, having to deal with api callouts to VersionOne. Being the second time around, I think I've got a set of classes now that really help out with this and I wanted to share my thoughts on it.
If you've attempted to test your callouts, I found either one of two things happen -- it's way too vague and/or it's way hard to test the things that are really worth testing. You know, things that break stuff like a spelling error for a url or other silliness. My first round of attempts looked like the examples and ended up coming out like this and felt overwhelming inadequate... More...
Years ago when I was introduced to the agile process, I grasped the concept rather quickly and ran with it. To me, it made total sense and I was all in. As a team, we weren't full on agile necessarily (not even close), but it was a good start and we evolved. Granted, this was a consulting group so adopting and trying things were a bit easier than it is for someone in, say, a large organization, but there are now a TON of big organizations on the agile adoption path. I've heard many times over, "we're agile" ... and they're really not. Old habits are tough to break, we're hard wired for it. It takes a good level of discipline to break it but that's if its just yourself. With a team, it can be a mess.
Typically, there's a layer, somewhere, deep within in the ranks that is all for agile (or at least really trying to do it right) and I see them kind of stuck and largely become frustrated. More...
Recently I started doing some work for a client for some integration between Salesforce and VerisonOne. When I first looked at how they were doing it, it was pretty clear there were some serious struggles which I kind of take personally (I was on the dev team for quite a while).
With the imposed limits of Apex, reusability is a must and for this case specifically, we were doing a lot of writes (POST). Since Apex now has an XML object that helps with creating those, I came up with a set of objects that handle creating the proper payload for posts to the VersionOne API. More...
For the past ... probably 3 years I've tried to articulate this idea I've had into words that would make ANY bit of sense. I've tried various angles and had a few different theories and finally, this is what I came up with. Since my first attempt, I've witnessed different forms of this and have drawn a conclusion with utmost confidence. "It's all about the people" isn't a cliché but solidly ... no one gives a damn and they should. Now, before you start saying "well duh" or make some excuse, hear me out. More...
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
This is just a link-puke of a bunch of articles I've been meaning to post/talk about. So here we go (say bye bye to your morning)
First up, a mildly misleading heading of kanban vs scrum. It's really how one can be used to streamline the other.
Next up are a pair of articles from the same site. First one talks about overcoming poor architectural choices and a rather candid discussion on "disaster porn". Love that description.
A couple psych ones. First one is amazingly nerdy and in my opinion, expands on the feedback principle. Random nerd fun fact - technically, Pe (error positivity) can be instantly recognized, which for the human brain is 130-180ms and falls with the range of the study which measured it at 100-500ms.
and not to be outdone, a discussion on sugar vs protein and being awake.
Another article I found very interesting was on leading clever people (I agree with it, especially "create a galaxy")
And finally, on a similar vein is a concept of "developeronomics" ...
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...
Thanks again to everyone that attended the Atlanta Code Camp and of course, my talks. I really enjoyed the discussions more than anything, especially the one about monkeys and as always, feel free to shoot me an email at je riley from the gmails of the com (Suck on that spammers)with any questions. Also you can find me on IM (gtalk/msn) and ...just about everything else with that email address, so feel free!
Kanban'in It Slides
Gentle Intro to TDD