With Amazon’s ongoing struggles with part of their cloud, I’ve obviously been watching closely, given that I work for a company that provides a cloud for communication applications (hosted almost entirely on our own global carrier-grade infrastructure). Watching Amazon’s status site, they continue to not be entirely back in action a couple of days later.
There have been a lot of great technical posts out there related to what’s happening with AWS. Two that caught my eye are admittedly by an Amazon competitor, Joyent, but are definitely worth a read:
The latter post about abstraction layers hits a few major points with me, particularly around the need for abstraction layers to allow some type of control… and some type of transparency into what is going on.
Black boxes are great… until they break.
Another great post was by George Reese over in the O’Reilly Community (he is CTO of enStratus, a company making equipment to assist in infrastructure automation):
Reese argues that it is the application developer’s responsibility to design apps in such a way that they aren’t dependent at all on the underlying infrastructure.
This all takes me back to my post I wrote in 2009 about the need for services to be distributed and decentralized. Now I was talking in there about Twitter and Facebook… but the same argument can be made for apps in general…
It’s a fascinating time… I hope for Amazon’s sake that they can get everything back in action soon… and it will be interesting to see what questions this all makes developers ask with regard to cloud providers. Meanwhile, I’m enjoying many of these deep technical posts… I expect to see more coming in the days and weeks ahead.
Would you like to create your own SMS interface to Twitter? To be able to post your own tweets via SMS? Or would you like to have an IM interface to Twitter using Jabber, GoogleTalk, AIM, MSN, Yahoo, etc?
And would you like to do all this using Node.js?
Sure, Twitter already offers its own SMS interface… but hey, why not build your own to play with Node.js?
That’s exactly what my colleague Justin Dupree did and then wrote up in this great blog post:
Building a Twitter SMS/IM Service with Tropo & Node.js
I love it! I mean… combine 3 of my favorite passions: Twitter, Tropo and Node.js… mix them together, shake them a bit and out pops a very cool mashup that lets you have your own interface to Twitter using SMS or IM.
Kudos to Justin for the great way he walked through the code in the post… and also made the full Tropo-Node-Twitter code available on Github. I’m looking forward to playing with it more and seeing what else I can do with it…
P.S. I’m naturally found on Twitter at twitter.com/danyork.
Recently I’ve needed to get back into creating some DocBook documents and needed to refresh my knowledge of the latest tools. Back about 10 years ago, I did a great amount with DocBook and spoke about single-source publishing at conferences and created a few tools and vimrc macros. However, since that time I’ve not done much with DocBook – and obviously the tools and toolchain have evolved a bit.
In looking around, I’m quite impressed by what the oXygen XML editor can do with DocBook. oXygen looks quite powerful! It’s also got a bit of a price tag… on the other hand, I know that putting together the pieces to create your own toolchain can take a bit of work. The ever-present tradeoff between your time and your money…
I think I’ll certainly try out the 30-day trial to see what the writing experience is like.
This video shows how to create a simple DocBook document using oXygen and certainly makes a compelling argument for how easy the editor can be:
Do any of you use oXygen? Have you found it worth the price?
And so must all good things come to an end… Pamela Jones announced over the weekend that she would be ending new posts to Groklaw on May 16, 2011, the eighth anniversary of the site.
For those of us who spent a good bit of time in the Linux world, Groklaw became a critical resource to stay up on the latest follies in the ongoing SCO lawsuit. “PJ”, as Pamela Jones preferred to be called, and the community of passionate helpers she soon attracted were there to rapidly research and debunk any claims that SCO put forward.
SCO has faded to pretty much irrelevance in 2011… but 8 years ago their lawsuit was extremely serious and a cause for great concern for anyone working with Linux. At the time of the initial lawsuit, I was a product manager at Mitel for a Linux-based product, so the whole issue was very definitely something I paid attention to… and Groklaw was definitely on my frequent reading list.
[NOTE: If you have never heard of Groklaw, I would start with the mission statement and the various links off that page.]
And now PJ writes:
In a simple sentence, the reason is this: the crisis SCO initiated over Linux is over, and Linux won. SCO as we knew it is no more.
There will be other battles, and there already are, because the same people that propped SCO up are still going to try to destroy Linux, but the battlefield has shifted, and I don’t feel Groklaw is needed in the new battlefield the way it was in the SCO v. Linux wars.
Remember that when I started Groklaw, I had no intention to create something as huge as Groklaw became. I really was just trying to learn how to blog. When all of you showed up, I saw what we could accomplish together, and we did. But to do it, I had to set aside a lot of things that are important to me too. I’d like to go back to being nobody, just living a normal life again.
I kept going all these years because when SCO attacked in the media and in the courtrooms, there was nobody to do what we did. Only the community could have answered SCO, technically, because you guys lived the history of UNIX and Linux and you knew what they were saying was not true. So we spoke up and explained over and over until everyone understood.
And she ends with:
I always told you that I didn’t do Groklaw for money or for fame or as a career move. I did it to be effective. That’s all I wanted. And I told you that when it was over, I’d go back to my normal pre-Groklaw life. And now you know by this decision that I told you the truth.
No matter what happens next, I know that we changed the course of history. How many people get to say that? I never expected it, frankly, and I am grinning just thinking about how much fun we’ve had doing it. Our work will be available for historians permanently, so the impact we had isn’t over today, and someday we’ll tell our grandkids that we were part of this, part of Groklaw. We are in the history books. Our work will continue as long as anyone cares about this unique time period in the history of computer software, a history that we are a part of forever. And that is a long, long time.
Thanks to you, PJ, for all the insane amount of work that you and your community did and continued to do. We all out in the larger community owe you all an incredible amount of gratitude and thanks… you helped shine the light into dark corners and helped provide a means to focus the energy and passion of the greater community. Without all that Groklaw did, the SCO follies might have gone much differently.
And kudos to you, PJ, for what I’m sure is an incredibly hard decision to put a period at the end of the sentence and end the era of Groklaw. It’s super easy to simply let a project continue… there is a certain inertia that is hard to fight… and so projects and organizations continue to go on and on, even when their reason for being is no longer there.
Thank you for all you and your community did – and best wishes for whatever comes next!
P.S. Her full blog post is very much worth a read… as well as the many comments.
While this video is from back in July 2009, it’s a great story around how JSON came to be and has some solid lessons in it for people developing new data formats:
Video: Douglas Crockford — The JSON Saga
Yahoo! thankfully provided a full transcript of the video on that page so that if you don’t have time to watch the video (I initially didn’t) you can simply scan down the text.
I enjoyed the emphasis on “less is more” and on the need to remove functionality to make it simpler. At one point Crockford says (taken from the transcript):
One of the key design goals behind JSON was minimalism. My idea was that the less we have to agree on in order to inter-operate, the more likely we’re going to be able to inter-operate well. If the interfaces are really simple, we can easily connect, and if the interfaces are really complicated, the likelihood that something’s going to go wrong goes way, way up. So I endeavored to make JSON as simple as possible.
I had a goal of being able to put JSON standard on the back of a business card. And this is the card. Come see me if you want one of these cards; it’s the JSON card, it’s got the JSON standard on the back.
He goes on at some length about XML, language design and much, much more. If you have 50 minutes to watch the video, it’s worth it. (Alternatively, the transcript is excellent.)