The BrainDonor Network has a new home in the cloud! I have moved everything from Slicehost to Amazon Web Services. With Rackspace finally pushing through the migration of server images from Slicehost to the Rackspace Cloud, I knew I had the perfect opportunity to switch. Having deployed several client sites to AWS, I also knew I had the comfort level to get everything migrated and set up—so that I could start ignoring it once again.
In Part One, I discussed managing the scope of
$(document).ready(). Next comes the challenge of organizing the contents of
$(document).ready() to balance efficiency and maintainability. My team accomplishes this by taking advantage of the Array behaviors of jQuery to structure our code so that function dictates form. Put into practice, these behaviors will structurally organizing the code without imposing rules and processes—because we all know just how effective rules and processes are.
Leave it to O’Rielly to give a great summary of NoSQL—and express what I have been telling other developers. NoSQL is not a technology. It’s a different way of looking at large data sets and data-driven applications. I have been busy adding NoSQL to my developer’s utility belt lately by introducing MongoDB into the projects that I am building. I have already referenced my BrainDonor.Mongo project in some of my other posts. I like to think of it as my formal announcement that I am a card-carrying member of the NoSQL movement. For me, the movement is about not putting all my data eggs in one basket. When it comes to development languages and platforms, I am a true polyglot programmer—and I must extend that further into data.
I’ve been asked by a large number of developers if I know any solid jQuery best practices. The answer is a huge YES! I’m also getting around to changing my answer to their immediate follow-up. Do you have them written down so you can share them with me? In an effort to change my answer to another huge YES, I am starting a series on jQuery Best Practices that will continue until I run out of steam. The first best practice that I have to share is how to properly manage the scope of your jQuery scripts.
A common component of many of the websites that I build are small administrative areas where clients are able to perform tasks such as downloading leads or scheduling appointments. Until recently, most of those websites were built to run on top of a content management framework–with the CMS providing most of the back-end interface that I deliver. I started using Twitter’s Bootstrap framework to deliver a consisten look and feel with our ASP.NET MVC3 applications. Bootstrap provided me with a clean CSS grid system, clean controls, and a host of other components. The biggest disconnect between Bootstrap and MVC3 is the unobtrusive validation.
I have begun using Twitter’s Bootstrap framework to build administration sites for the MVC apps that I am building. Bootstrap makes it trivial to keep all of the views clean and consistent–without needing to get a graphic designer involved. You can see it in action in the example app for my MongoDB utility project, BrainDonor.Mongo. Unfortunately, the bootstrap source .less files refuse to play nice with Chipry!
With my latest gig sending me back into the .NET world, I have been busy migrating quite a few of my tools and experience to play nice with ASP.NET sites. One of my favorite open-source tools that is gaining popularity in .NET is jQuery. For several years now, I have been using jQuery heavily to provide rich interaction on websites. When faced with the basic UpdatePanel in ASP.NET, I was presented with a challenge. I wanted a solution that would automatically call jQuery so that new content was properly parsed and updated. Because I had been managing all the AJAX calls in my other development, this was trivially easy to do. UpdatePanel hides all of this inside the ASP AJAX libraries and scripts—making it difficult to figure out where and how to structure my jQuery code. After some research and experimentation, I have a solution up and running on multiple sites now that integrates everything in a very clean manner.
In my two most recent posts, Always Learning and Coders at Work, I talked about my personal and professional need to keep learning. My most recent addition to my development arsenal has been Python. Why I considered learning the language a success, I didn’t really feel that it a significant amount of new materials and features. As a result, I have chosen to dive into the functional programming language Erlang.
The book, Coders at Work was published at a very ideal time for me. I was pretty comfortable with my progress towards learning Python last year, and have been looking around for another language to start tooling around with on my computers. The book seemed like a good opportunity to get a peak into the minds of a select group of coders and see what they might have to say on the matter.