The Dictionary: Remixed
Disclaimer: One of the main goals of this web site is to show case things in my life that I have done and am proud of. That said I cringe as I write this post. See, like most good software projects, this one is running down to the wire. I am aiming to have the site up and running by end of day tomorrow; 2/28/10. But I’m feeling under the weather and have been taking it easy today. As such the schedule may slip a few days.
I have been pretty deep in nerd mode so far this year. A new job as a software consultant has kept me busy. Plus, it has opened my eyes to a lot of new developments in software. And every time I begin to understand a new technology, my mind naturally thinks, ‘hey, I could use that to …’
So enter my latest side project Dictionary: Remixed. Have you ever heard someone say, ‘If you look up the word X in the dictionary, you’ll see a picture of me’? Well, that’s exactly what this site is. I’ve been having a great time with the software design and architecture of the site. The challenge for me is to make its components loosely coupled enough that I can change them at will while keeping the overall application cohesive: it’s just an editable dictionary.
First, let’s talk about the components. Images are stored on a file share and definitions in a Sql Server database. The database use Entity Framework to map data to objects. These stores of data are exposed to the business layer via an interface (we’ll talk more about this later). The business layer is fairly thin. Its responsibilities are to apply rules based on configuration settings, filter the data received from the user interface, gather data from the applications and external data stores, and return data to the UI. This is implemented using Plain Old Common language runtime Objects (Pocos). The UI was implemented using ASP.Net MVC. You can email definitions out using a nifty little widget I found called ShareThis.
Second, coupling. In computer science, we use the phrase loosely coupled to describe software written such that components of an application need to know a minimum about the inner workings about one another. A real world analogy would be that you don’t really need to read the manual of a new car just as long as it has a steering wheel, brakes, and a gas pedal. The reason I desire to keep the components loosely coupled is that I hope to swap out most of them in time. I am ramping up on cloud technologies. In the near future, I plan to implement data stores using Amazon’s simple storage, SQL Azure, and Windows Azure storage. Hence the interface between the business layer and the data stores. As implemented, I should be able to select an different data store by simply changing one line in the web.config file. Likewise, I have ambitions of making this application accessible from mobile browsers, facebook, android, and the iphone. The next step is to create web services to replace my existing UI. Then, build thin clients for each target. Lastly, the actually definitions I present are pulled from Bing. It would be great to also be able to grab definitions from a less traditional site, like Urban Dictionary. Unfortunately, they don’t offer an api at this time. However, my application is architected in such a way that reading from additional sources won’t require refactoring. So if I really wanted slang in my application, I could either find another site or just scrape their site (and pray they don’t redesign their pages :)
Finally, cohesiveness. One challenge every developer faces is finding the happy medium between hard coding everything or making an application flexible enough to accommodate anything. In computer science, when we say hard coding, we mean explicitly setting a value instead of allowing it to be configured. For example, consider a program that calculates tips. I could quickly write it to just multiple whatever value you give me by 15%; which would be great until you read an article that says the new etiquette is 20%. Then I’d have to write it all over again. To make it infinitely flexible would be to create a programmable scientific calculator with 3D graphing capabilities; in which case, I’d never finish. In building Dictionary: Remixed, I faced similar challenges. To get it out the door, I did away with typical but nonessential features like user accounts, video uploads, and ads. Further, I opted for a phased approach for some of the more advanced stuff like cloud storage and the various client apps. Where I realized I couldn’t skimp was on logging, captchas, and quality coding conventions. Hopefully I made the right tradeoffs.
Spending my free time writing code. Yeah, that pretty much makes me the definition of a nerd.
I have been pretty deep in nerd mode so far this year. A new job as a software consultant has kept me busy. Plus, it has opened my eyes to a lot of new developments in software. And every time I begin to understand a new technology, my mind naturally thinks, ‘hey, I could use that to …’
So enter my latest side project Dictionary: Remixed. Have you ever heard someone say, ‘If you look up the word X in the dictionary, you’ll see a picture of me’? Well, that’s exactly what this site is. I’ve been having a great time with the software design and architecture of the site. The challenge for me is to make its components loosely coupled enough that I can change them at will while keeping the overall application cohesive: it’s just an editable dictionary.
First, let’s talk about the components. Images are stored on a file share and definitions in a Sql Server database. The database use Entity Framework to map data to objects. These stores of data are exposed to the business layer via an interface (we’ll talk more about this later). The business layer is fairly thin. Its responsibilities are to apply rules based on configuration settings, filter the data received from the user interface, gather data from the applications and external data stores, and return data to the UI. This is implemented using Plain Old Common language runtime Objects (Pocos). The UI was implemented using ASP.Net MVC. You can email definitions out using a nifty little widget I found called ShareThis.
Second, coupling. In computer science, we use the phrase loosely coupled to describe software written such that components of an application need to know a minimum about the inner workings about one another. A real world analogy would be that you don’t really need to read the manual of a new car just as long as it has a steering wheel, brakes, and a gas pedal. The reason I desire to keep the components loosely coupled is that I hope to swap out most of them in time. I am ramping up on cloud technologies. In the near future, I plan to implement data stores using Amazon’s simple storage, SQL Azure, and Windows Azure storage. Hence the interface between the business layer and the data stores. As implemented, I should be able to select an different data store by simply changing one line in the web.config file. Likewise, I have ambitions of making this application accessible from mobile browsers, facebook, android, and the iphone. The next step is to create web services to replace my existing UI. Then, build thin clients for each target. Lastly, the actually definitions I present are pulled from Bing. It would be great to also be able to grab definitions from a less traditional site, like Urban Dictionary. Unfortunately, they don’t offer an api at this time. However, my application is architected in such a way that reading from additional sources won’t require refactoring. So if I really wanted slang in my application, I could either find another site or just scrape their site (and pray they don’t redesign their pages :)
Finally, cohesiveness. One challenge every developer faces is finding the happy medium between hard coding everything or making an application flexible enough to accommodate anything. In computer science, when we say hard coding, we mean explicitly setting a value instead of allowing it to be configured. For example, consider a program that calculates tips. I could quickly write it to just multiple whatever value you give me by 15%; which would be great until you read an article that says the new etiquette is 20%. Then I’d have to write it all over again. To make it infinitely flexible would be to create a programmable scientific calculator with 3D graphing capabilities; in which case, I’d never finish. In building Dictionary: Remixed, I faced similar challenges. To get it out the door, I did away with typical but nonessential features like user accounts, video uploads, and ads. Further, I opted for a phased approach for some of the more advanced stuff like cloud storage and the various client apps. Where I realized I couldn’t skimp was on logging, captchas, and quality coding conventions. Hopefully I made the right tradeoffs.
Spending my free time writing code. Yeah, that pretty much makes me the definition of a nerd.
posted by Mr. Sharps at 8:50 PM
<< Home