Joseph’s post on versioning interfaces in BizTalk 2004 SP1 made me squirt water through my nose.
Scoble talks about David Allen not liking the idea of casual Fridays. I’ve worked in places that have a suit and tie culture, and I’ve worked in places which are much more casual – in fact some customers I have worked with (and even previous employes) took the shorts and leather sandal approach. Personally I prefer the casual approach mostly because I find I think better when I am wearing comfortable clothes, but when on customer sites I tend to wear the typical business pants and a Readify shirt – no tie, looks a little silly.
If you look at the history of clothing I’m sure you’ll find that we’ve seen a convergence of peasant and upper class styles as those who order the work and those two do the work start to socialise more. Clothing is also a status symbol, very few uniforms actually help you do your job.
I think we are heading into a language renaissance, its been on its way for few years now with languages like Ruby and Python becoming more popular. Both of these languages have interesting dynamic aspects to them that make them appealing both as learning languages and a platform for some of the more interesting commercial projects (one of my favorite online games is written in Python).
As a developer its important to keep an open mind about programming languages and actively experiment with as many as possible. I know that I haven’t played with Ruby enough to truely appreciate it but I hope to rectify that in the next few months, although I have spent more time with Python as I’ve needed to debug a few Python programs when I drag them over to Windows kicking and screaming.
From what I gather both Jim and Joel are tasked with making the CLR a more hospitable home for dynamic languages. It makes perfect sense for language developers to target the CLR because they get so many runtime services for free – and its a lot more fun focusing on the core language features than figuring out how to manage the heap efficiently.
When the CLR first shipped there were a number of established languages that were ported to the runtime – especially by the academic developer community, but more recently I’ve seen a number of projects start up with new or derived languages.
One such example is “Boo” – cool name. Today I downloaded Boo and took a quick look at it. As the blurb page says, its borrows a lot from Python for its language syntax, but I was surprised how quickly I was able to get up and coding in it.
I loaded up the Boo interactive shell and pretty much started typing code. The above screenshot is actually my second session with booish.exe (the first one I made silly mistakes like using semi-colons). I think a version of C# with an interactive shell would be useful to teach C# – we could call T# – the prompt could be a swigly bracket
Congratulations Steve! Steve has been an ASP.NET MVP and an ASPInsider for quite a while but the reality is that he is an inspirational community leader when it comes to many of Microsofts products and technologies. Well chosen Microsoft!
Ambrose is one of those smart people that I have a lot of time for and I religiously () read his posts. When I started reading this post I thought that it was going to be a general rant about software quality but it eventually turned into an advertisement for a position for what I call a SDET. Actually – I stole the term SDET from Microsoft where it means Software Development Engineer in Test.
I thought it was worth pointing out because quite a few organisations that hire people like Ambrose are starting to see the value in hiring someone who has an almost dedicated focus on software quality. While hiring the kind of people that Joel Spolsky talks about here will get you a quality product having someone focused on testing rather than delivery will add that final bit of polish. Someone in an SDET role needs to be in that role long enough to establish a quality mindset and the cunning to not just observe bugs that jump up and smack you in the face but to actually hunt them down and exterminate them.
A mediocore functional tester can tell you what they were trying to do when the program crashed, a good SDET will tell you what went wrong even when the program didn’t crash, what database operations the program performed leading up to the crash and what the state of the stack and the heap were before it went down – in many cases they could probably tell you what line of code you need to change as well.
Michael Hunter (the Braidy Tester) has a great series of posts on the differences and similarities between good developers and testers:
Darren has started a conversation around the need for a blogging application programming interface. Darren is a fellow Readifian and the guy behind SUB (or SingleUserBlog). In to the conversation he has even managed to rope in Chris Frazier who is behind the awesome tool PostXING which supports many of the weblog publishing platforms out there.
I think that as soon as you start talking about blogging APIs you differentiate content subscription and distribution and content creation and modification. By far the most popular way of distributing blog content is via RSS feeds and the mechanisms simplicity has made it the run away success that it is today.
The content creation and modification mechanism that underpins these feeds however is completely fragmented and there are many priorietary approaches to solving the problem. One of the reasons for this fragmentation is that the driving force behind blogging software has been the technical community and as they encountered problems with what they were using they just coded around the problem not thinking too much about what the overall affect would be – this is a normal, healthy stage of any technology development.
Now with Longhorn –er– Windows Vista just around the corner and RSS content aggregation being baked into the underlying platform I think its time to start looking at the other side of the fence. The problem will be that everyone thinks they know the best way to do it. Some will opt for some kind of HTTP POST driven system whereas others will take the pure SOAP messaging approach – it cuts so close to the bone for some messaging wonks that they won’t even be able to help themselves and get involved in the debate.
What is the right approach? I really don’t know – but as a blogging software user I would really like to be able to just pick up my content and move it from one blog to another – drag and drop style. What that means is that there will probably need to be some kind of standard “post-transport-format”, which encodes all information such as the post itself – images and attachments.
Maybe Darren should work on a better API – and I’ll work on portability of content