Ionrock Dot Org

Lately I have read a bit on the CSS framworks like Blueprint. The primary criticism I find is that people feel like it is a reversion to adding visual details within the content. To an extent I agree, but at the same time, I wonder if the strict purity between style and content is required at the client level.

If you look at some of the more pragmatic decisions of the day such as constraints in Rails and Amazon web services providing fast services over up to date service, you see a theme. The general idea is that what matters is the user's perception. When it comes to writing HTML and presenting a document that is rendered in the browser, the requirement that the actual code is completely semantic seems a bit rough. I'm not saying lets head back to spacer gifs and tables, but it seems like adding extra classes to elements isn't the end of the world. After all, it is easy to strip them off and get leaner markup using XSLT.

It is a tough call because the one person who needs pure markup will probably always cause a stink, but lately I've wondered if the cost of the stinker is totally appropriate. As I am not a designer and do not work in a static world, my opinions are probably biased. With that said, the aversion to things like Javascript and CSS hacks makes me wonder if the web design world could use a leader advocating rational and pragmatic development of themes. It seems if this happened we could see a XSLT renaissance, as it is easily the most well suited for this kind of operation. It is also possible that the lack of pragmatism (in my opinion at least) could be due to the dislike of XSLT. In either case, I hope that the design and layout world of the web continues to come up with interesting ideas and ways of designing web sites and applications.

Well, I told Lauren (slightly jokingly) when the iPhone came out that was what I wanted for Christmas. I've never been much of a gadget guy primarily because of finances. It was always tough to justify purchasing some gadget that most likely would not be used to its fullest potential. Before the iPhone, I had wanted to get a Treo 760 or something similar but really wasn't convinced I would use it. The interfaces always seemed clunky along with expensive data plans made it merely something to think about. The iPhone was different in that the interface seemed actually usable, which made the data plan more reasonable. A few friends that had owned iPhones also gave it glowing reviews, so it seemed like a great gadget to get a hold of if possible.

Of course, I had no real plans on how to get a hold of one for my very own. Lauren threw me for a loop by getting me one for Christmas and couldn't have been more surprised. She is very good at surprises and managed to hide the gift under the tree next to some friends gifts so they wouldn't be tampered with. Inside the box were some of my own socks aimed at continuing the ruse. When I finally got to the actual iPhone box it was quite a stun.

Seeing as I just activated it today, I'm far from any formal reviews. Overall though, I really like it. I am looking forward to taking Lauren shopping as I can finally catch up on reading articles or watch a few YouTube videos while I wait awkwardly to offer an uninformed opinion on what dress is better looking. Seeing as my wife has great taste and I always like the way she looks, it is rare to see something I don't think looks good.

Recently I've seen a few misunderstood blogs on SimpleDB. Essentially it seems the confusion comes from the fact they are looking at SimpleDB as a traditional database. Really, if you read through the explanation of what it is, the essence is an index.

We use a similar technique in Amplee and Bright Content in that we have resources, Atom entries, that are indexed by extracting values via XPath. The indexes return sets of links back to the resources. This pattern makes it possible to work with straight XML files very easily because the indexes do all the work of keeping the queries fast. It also simplifies things because relationships can be a graph instead of hierarchy modeled in a database. The result is sort of like an object database and is actually probably very similar to many object databases.

Back to SimpleDB then. Here the resources are any meant to be any file such as S3 resources. If you had to query a bunch files on S3 for some value it would be extremely expensive. You could cache them locally, but assuming your are using S3 in the first place b/c you need the space, caching everything locally seems like you just lost any benefits. The obvious answer then is you need an indexing service, hence SimpleDB.

I hope this clears up confusions a bit. I'm not commenting on the GET interface as I understand that is semi-temporary (I really don't know though). I thought it was silly folks were talking about not having joins and everything when it wasn't meant for mixing tables and doesn't really even act like a table. Maybe a name change to Amazon Index Cloud would clear things up a bit.

Lately, I've been working with Rails. So far it is nice, but getting back to databases is rather frustrating. XML solves the data problem elegantly and while there are issues with indexing to an extend, it really feels solved to me based on my Bright Content/Amplee work.

On the Python front, I've managed to use Bright Content for a CMS in a generic sense. This has been very simple and partly due to my experience writing and throwing away sample applications. Pylons has actually been a huge help in this sense because it has such helpful patterns. Usually, when I get stuck, I can take a look at whatever Pylons did and have a good direction on my own solution.

The result of this experimentation is something of a framework. I would imagine I could take the steps to really push forward my own custom framework, but with so many out there along with my use of XSLT (not a very popular templating system in the Python world), I'll let my grand scheme of becoming the next DHH slide.

I mention all this partly because of a recent article criticizing Pylons' conceptual integrity. Personally, Pylons (and TurboGears) have both been something of meta-frameworks. You wouldn't use them off the shelf most of the time. You would learn how they glue things together and tweak it to your liking. This could be switching out the DB layer for an XML based system or utilizing a custom session handling tool. Really the possibilities are endless. As I've become more opinionated as to what I should be doing with Python web development, I've used techniques and patterns from many frameworks that I found to be valuable. This methodology seems appropriate since this probably how Rails came about, the arguable father of the modern web framework.

The point here is (since it seems like I'm rambling) is that a framework is simply a tool. Some tools are magic as seen on tv tools that manage to do whatever they do out of the box with little effort. That doesn't mean you have professional fashion designers buying Bedazzle machines. As you grow in your craft, your needs change and you sacrifice certain constraints for more control. I'm not saying that Pylons makes and effort to be the framework for the advanced Python web developer, but rather that Pylons just makes an effort to change as you change. Eventually you still might ditch it in favor of your own system, but at the very least, Pylons will have served you well in the mean time.

I am pleased to announce that I have accepted a position with BSG Alliance! I will be working with their applications group creating RESTful web services to help promote a new era of enterprise communication and services. I honestly am not totally sure what that means, but my impression is that we help make folks in big business do a better job by helping them let down their hair through communication.

On a technical level, I'll be programming Ruby/Rails and potentially some Python. I might also do a hair of Java, but seeing as I've never done it professionally, I have a feeling it will be *very* limited. This is a great opportunity because I'll have a chance to get back in the world of databases while flexing my knowledge in RESTful services using a great language (Ruby). Last but not least, I seriously liked the guys I will be working with.

Over all the whole experience of finding a new job has been extremely smooth. I didn't even have to look, which is extremely odd for me. When I looked for jobs out of college, it was a methodical task of personalizing cover letters, updating my resume and keeping tabs on who was supposed to be calling. This time, I got calls from recruiters and the next thing I knew, I was interviewing and getting offers. While part of me feels this is due to my exceptional skill set, I have a feeling this is just a good time to be in technology ;)

What I'm most excited about at BSG is the people. I actually made the decision based on it. The guys there were folks I wanted to hang out with. I had other offers that had good sides as well, and honestly, I felt insanely honored to be seen in such high esteem as most of these folks were smart and talented folks. In the end though, the focus on service oriented architecture and a desire to hang out with great folks won out. Wish me luck!