October 30th, 2008 — 12:48pm
I think we've all encountered the fear of open source software amongst some of our clients. I like to call it ossphobia. It basically amounts to a categorical rejection of anything that doesn't arrive in shrink wrap with a shiny holographic label displaying a Microsoft logo. While I am primarily a Microsoft developer, I am by no means a fanatic and often find that the best solution to a problem is exactly the opposite of the solution championed by Microsoft.
Recently I was working with one such ossphobic client on a reletively simple reporting application. We were in need of a very simple ORM-lite solution (similar to what SubSonic provides) to store meta-data information in a database. My first thought was, "Well, why don't we just use SubSonic?" This was met with blank stares and a palatable sense of "Oh no he didn't." hanging in the air. So, after realizing that my chances of changing this client's mind on the subject of OSS was nigh impossible, I decided, "The hell with it, if they don't want to use the inexpensive solution, I'll just write my own ORM and call it custom software."
Some of you (whoever you are) will find the idea of rolling your own ORM in the age of NHibernate, LINQ to SQL, SubSonic, and etc. ridiculous. "There are so many good frameworks out there, why would you ever want to write your own?" Well, I'll give you a few reasons…you may not like them…but I do so you'll just have to deal.
- Full Control – One of the things that's great about SubSonic for example is that it just flat works out of the box. You do some simple configuration, generate your objects, and your off and running. Literally, 10 minutes. The problem here is that much of the internals of SubSonic are kind of a black box. The source code, while well written, can still be a pretty deep stack. If I for example wanted to add a feature to SubSonic, I'd find the learning curve pretty high. A custom ORM designed specifically for simplicity offers a much lower barrier to extension.
- The Right Tool for the Job – So in the specific case that prompted me to write my own framework, there were some specific features that we needed. I was able to winnow down my concept to cover just what was needed at the time (the YAGNI principle). This allowed my framework to be really targeted and the API that I exposed to consumers of the framework was extremely simple.
- I Like Learning – I don't often get the chance to work on framework type projects so this gave me the opportunity to really try out some ideas in an environment that wasn't tied immediately to a project deliverable. I think everyone should have a side project that takes them outside the path of their normal daily development…I have several such side endeavors.
So, now that all that's been said. I'm introducing Echo ORM as an open source project on Google Code. It's a very small framework and in a very alpha state, but I'd love some feedback on the approach that I've taken and I welcome comments or contributions.
Comment » | Uncategorized
October 21st, 2008 — 3:09pm
An excellent post on project size…as in how many people are on a project.
Personally, I've always subscribed to the Amazon two pizza maxim. Any project team should be able to eat comfortably on two large pizzas. As soon as someone says, "Say, I think we might need to order a third pie." You know your project is too big and is likely going to suffer from hauling around the extra weight.
Comment » | Uncategorized
October 20th, 2008 — 11:12am
Despite the fact that the capacity of modern JavaScript engines is expanding rapidly, I found myself recently fighting with JS performance on a very large web page. This was an ASP.NET application with one very complex page, very large DOM tree, lots of elements and lots of JS interactions.
As the page became larger and more data was pumped into the DOM the time it took to locate an element or set of elements in the DOM began to lengthen. My attempts to locate any solid information in Google on improving this situation was fruitless. So, I starting digging through the jQuery source code to see how the selector engine worked…this was also useless. Clearly the skills of the JS Ninjas that created jQuery are far superior to mine.
So, then it just became a thought experiment. Knowing that jQuery uses a context sensitive combination of XPath, native browser API's, and some fancy string parsing for CSS3 selectors there are a few optimizations that come to mind.
Qualify your selector strings when searching by class.
Because one way that jQuery can find DOM elements is XPath style searching, it's important to qualify your selector strings. Turning $(".some-class") into $("div.container > div.head > div.some-class") can really make a difference. This is especially true when the branches of your DOM tree become very deep.
Don't Qualify your selector when searching by id.
Because searching by id uses the browsers native getElementById method (which is very fast) it doesn't make sense to overly qualify a selector string that's looking for a unique element. So $("div#someid") is actually slower than $("#someid").
Select By Element(s)
Don't forget that your argument to $() can also be a reference to an element directly. One of the techniques that I've used to get over huge numbers of DOM elements is to do some pre-caching of element objects before doing any manipulation. For example I might keep an array in JavaScript of all of the elements of a particular group.
Say you have a bunch of textboxes on a page and they're scattered all around in deeply nested trees. Half of the textboxes belong to group A and the other group B. I might set up two JavaScript arrays (elementsAarray, and elementsBarray) and before the page is rendered I'll go and grab all of those elements and plop them into my arrays. This way I can simply grab that array of elements in group A with $(elementsAarray) which completely cuts out the need for DOM traversal.
- – - – -
There are likely other ways to tweak your selectors and I'd love to hear how other people have tackled this issue. Here's hoping that JavaScript engines get so fast that we don't have to care!
1 comment » | jQuery
October 5th, 2008 — 10:22pm
So, I’m on a plane right now and there are at least five people in my immediate vicinity working on laptops. Every single one of these people is reading email in Outlook. The obvious disgust at Outlook aside, this leads me to the question, “Why don’t we have Wi-Fi on every commercial flight yet?”.
I myself would be incredibly attracted to any airline that offered this service. It wouldn’t even have to be free. I’d happily pay an extra $10 for my ticket if it came with even modestly quick Internet access.
I doubt if any airline execs read this particular blog, but if you are…Wi-Fi…all I have to say…Wi-Fi.
Comment » | Uncategorized
October 2nd, 2008 — 5:01pm
Ok, so now I'm on a roll with the jQuery plugins. This time it's a simple plugin that takes a single unordered list and segments it at predefined intervals into additional lists. Each list is then floated to the left making it appear to wrap content to the next "column". The plugin is extremely simple to use but works really well on all sorts of content.
Download: jQuery.wrapList.zip
1 comment » | jQuery
October 1st, 2008 — 1:27pm
I recently needed a jQuery plugin to do checkbox replacement for a client. Unfortunately, the plugins that were available really didn't fit our needs. In this particular instance we were not concerned with being unobtrsive so we didn't need to render out an actual checkbox and the replace it with another tag. Instead, we decided to go with plain old anchor tags.
So I whipped up my very first jQuery plugin to solve the problem. And with the recent announcement that Microsoft will be shipping jQuery with ASP.NET it seemed all the more appropriate. In another post I'm going to go through the steps needed to create a jQuery plugin but for now, here it is.
Download: jQuery.anchorCheck1.3.zip
1 comment » | jQuery
