EOAST - Evolution of a software thingy - Part 1

Its been a little while since I have blogged as I haven't had very many value items to add to the blogosphere lately. However, I have been steadily (albeit slowly) working away on a little software project that may or may not see the light of day, but it has been a fun learning experience, and may eventually come to something. If nothing else, its a good testbed for a number of latest technologies.

I decided to chronicle some aspects of this software "thingy", hence the blog title "Evolution of a software thingy" - EOAST (you gotta have an acronym otherwise you don't exist :-) )

So this first post is the requirements if you will, the business drivers behind what and why I decided to do what I did.

Context

If you have read any of my previous rants, you'll note that I am not the biggest fan of the latest incarnation of outlook. I use it daily, and rely on it, but its slow, often locks up (particularly on slower links) and generally sucks the life from my system.

Additionally, like most people, I use a number of various tools to collect information for either storage, perusal, reference and a bunch of other things.

The collection of various information pieces shows a lot of similarity with each other, the main difference being collection frequency or scheduling, management of the information, and its presentation. For all the tools I use, none of them are exactly how I want them. Each one has different parts I like and dislike and merging the information they gather into a manageable unit is tedious, if not almost impossible in some cases. Think blog aggregators, email, twitter etc. Essentially, they all collect some information at different frequencies or schedules and display it for manipulation or searching, sometimes storing it for later retrieval or whatever.

That's the pain point part. I also wanted to have a purpose for some of my technological investigations. We all know that you can play with a new technology like Entity Framework, or Linq to SQL and make it do what the examples do. However, when hard pressed to do something that meets a requirement, not a technology demonstration, and suddenly the game changes, and efficiencies and/or deficiencies are far more apparent. So essentially I wanted to play with some new tech as well to get a real feel for its capabilities.

Requirements

So with that in mind, my requirements for my "Software Thingy" are as follows:

  1. Must be able to collect information at various scheduling intervals, whether monthly, daily, hourly, every minute, or manually initiated. Additionally, it must also be able to push information, rather than simply request via a schedule. Think Microsoft exchange (push) and blog readers (pull).
  2. it must store this information that it collects into a reliable store, SQL Server being the obvious candidate. This will cater for large volumes and easy searching. (Think problems with large Outlook PST files).
  3. It must be reliable to handle badly written modules that it interfaces with. If something is taking too long, or just plain dead, the main application/engine will not die as well and render itself unusable (ummmm....Outlook again :-) ).
  4. It must not be tied to one method of collecting information. It must be flexible enough to gather information from anywhere. Blogs, twitter, POP email, exchange email, manual entry into  some data capturing app, text files, anything.
  5. it must not be tied to one display method. I want the ability to determine how particular information is displayed. I'd like to be able to map the gathering of information from one source, to a certain display method, or even multiple display methods, all administratively.
  6. I don't want to do it all. I don't have that much time or smarts. I would like to make something very easy to develop display modules or information gathering modules so that I can get perhaps a WPF guru to make me a slick WPF display module, without having to care where the info comes from and how its collected. Similarly for the information gathering. I'll write the items that pertain to me, and allow others to easily bolt on a different form of information gathering and not necessarily care about how its stored nor displayed.
  7. I want to utilise technologies such as WCF (my favourite), Linq to SQL, WPF and any other thing that makes sense.

Next up will be the initial design that I have come up with. Stay tuned.

4 Comments

  • Paul,

    Have considered SQLite? SQL Express is free, however, SQLite has a smaller footprint and perhaps more appealing for what you are planning to develop. The database resides in a single file on the filesystem, similar to SQL Server, however, the user does not need to install SQLite.

    Waiting for more details on your project!

    Cheers,
    indy

  • Thanks for the comment Indy, the next part is coming soon.

    As for SQLLite, it sounds like a good idea. I have currently defaulted to SQL as I wanted to play with LinQ to SQL / EF (which I'll show in a later post). However, if I was to distribute this, then I would refactor to something a little easier to distribute such as SQLExpress or SQLLite. Thanks for the suggestion.

  • Hey Paul, Are you of Serbian or Croatian ancestry ?
    Also, do you speak the language ?
    Just curious.

  • HI Dragan,

    Bosnian/Serbian my friend.

Comments have been disabled for this content.