Matthew Botos

I got a few new toys this week, including a HonlPhoto 1/8 Speed Grid. Grids are pretty standard for throwing a tight pool of light from a studio strobe, but tougher to find for portable flashes. The 1/8 cuts it down to about a 2 foot circle from the original 105mm zoom at 5 feet:

The circle inspired me to play around a bit with some James Bond poses:

The light is pretty directional: there’s just a bit of “mullet shadow” behind me. The grid’s construction is quite solid and it’s plenty big enough to cover the front of my Canon 580 EX II. I’m looking forward to using it for some more dramatic portrait effects in the future.

REI released a playlist of downloadable MP3s for the upcoming skiing and snowboarding season. In order to download each song, though, you have to pass a captcha - a captcha that’s animated with shifting position and colors - which is a bit of a challenge even if you are a human!

It seems a bit overkill to have a captcha here in the first place. The site itself is a Flash monstrosity that few robots or crawlers would be able to parse, and the the songs are free downloads anyway. The only justification I can see is conservation of bandwidth, though given the number of sponsor logos, I don’t imagine this is a cash strapped operation.

I’m going to be recapping some recent talks I participated in on cloud computing, so by way of introduction, here’s a post from Marc Andreesen detailing the three kinds of platforms you meet on the Internet (cloud computing being Level 3):

A Level 1 platform’s apps run elsewhere, and call into the platform via a web services API to draw on data and services — this is how Flickr does it.

A Level 2 platform’s apps run elsewhere, but inject functionality into the platform via a plug-in API — this is how Facebook does it. Most likely, a Level 2 platform’s apps also call into the platform via a web services API to draw on data and services.

A Level 3 platform’s apps run inside the platform itself — the platform provides the “runtime environment” within which the app’s code runs.

Mock objects are another one of those software concepts that are interesting but useless until you see how they can make life easier. A few of the talks at Code Camp helped me turn that corner and see that they’re quite useful for unit testing. Namely, they allow you to unit test a class while mocking its dependencies, which frees you to focus on the class being tested instead of dealing with the overhead of a real database or web service.

For an initial hands-on experience, I refactored some unit tests I wrote last week for a business class that called a web service. All that really needed to be tested was the handling of various data and exceptions from the web service, which were one-liners once I figured out the syntax of Moq. Writing tests this way also exposed some areas where code was overly coupled; my business class was doing a lot to manage the external service.

The tests are now quicker, the code feels a bit more solid, and I’ve got at least a foothold in understanding mocks for testing and their impact on software architecture.

I was conceived in the Bronx but was born and raised in Delaware when my parents made a pit stop on their way to Florida. This gave me the rare opportunity to not experience sales tax until much later in life and to know who Joe Biden was before a few weeks ago. Since I was nine years old all I have ever wanted to do was stroke a young Jim Morrison’s hair while tripping on peyote in the California desert.

Comprehensive and politically topical, but a bit too much information.

I am ready for an adult (mature, not film industry) relationship in my personal life.

Guess I won’t introduce you to my friend Leon Phelps, “When I said dinner, I meant sex; and when I said a movie, I meant I’d be videotaping it.”

(more…)

One of the recommended links from the Code Camp was the Foundations of Programming Ebook by Karl Seguin. It’s a good read with straight-forward explanations of modern software development ideas; here are a few quotes and comments:

Maintainability is the cornerstone of enterprise development.

Much agreed, and perhaps one of the things that sets enterprise development apart from projects with less longevity. Often, though, this mandate is overlooked as schedule becomes the main driver.

YAGNI - You Aren’t Going to Need It is an Extreme Programming belief that you shouldn’t build something now because you think you’re going to need it in the future.

This is a powerful idea from agile and one that really helps you get to having something “done” and ready for the customer faster. And given how often things change, it likely saves you the pain and waste of changing or discarding something built too early.

(more…)

I’ve been doing a bit of pair programming recently, and getting a different perspective from it. For one, it is nice to take a break from the usual solitary keyboard banging. Having two people makes bug hunting a little easier, and forces you to really think about what you’re doing - and why - so that you can explain it to someone else.

It’s also an interesting study in personal efficiency and style; I’ve been able to share a few time-sharing shortcuts and preached a bit of test-driven development by example. I’ve learned a bit, too,  finding some better ways to rework code I previously wrote.

I went to my first code camp with Philly.NET this weekend, and was impressed with the variety of speakers and overall attendance. For as many great online resources as there are today, sometimes it’s much more effective to see new technologies and methods explained in person.

The quality and polish of the presentations varied, but were overall pretty good. Being a code camp, most quickly moved from slides to live code, writing and debugging on the fly while taking questions from the audience. As always, it was enlightening to see how other people write software, both in terms of style and the tools they choose to write better code faster.

(more…)

The most recent AgilePhilly talk was on scrum adoption, and the ensuing discussion showed that it’s not easy for anyone to implement it fully. I’ve seen top-down mandates and looser directives, but the real driver seems to come down to the culture of the team.

Where people are used to processes and metrics, it’s just another system to adopt. Where they’re not, it tends to be a just-in-time approach that only uses what’s needed. That really frustrates me sometimes (if you say you’re going to do something, you should do it right!), but it seems pretty common for the transition to come in smaller steps. And to look at it from an agile perspective, there is some value to only building what you need, be it software or process.

Another interesting idea that came up was having scrum masters with program management backgrounds actually do quasi pair programming with the team. This would have some interesting benefits; program managers would see why a supposedly simple change takes two days of digging through ugly legacy code, or how test-driven development produces more solid code that’s less costly to fix later.

Last week I received an unusual offer: $500 to remove a blog entry that a company didn’t like customers seeing in search results for their name.

It gave me a brief pause, but was a pretty quick decision: I simply felt it was unethical to take payment in exchange for my right to free speech. One of the nice things about this being my personal blog is that only that argument mattered, with no trade-off against management, advertiser, or investor considerations. If I have one goal here, it’s to share information of interest to the audience, however small it might be.

(more…)