Always use a NoSQL database so your app can scale.

NoSQL databases can be more scalable, but schema-on-read has other drawbacks. NoSQL databases are much less capable of transactional changes. Relationships are difficult or impossible. Designing schemas to be efficient is much harder, and requires more up-front knowledge about your problem. NoSQL databases are sometimes the right tool for the job, but they are not the right tool for every job.

Making a program work for the happy path is not always easy, but given enough time I believe pretty much anyone could do it. When a professional takes on the task however they will make it work for more than just the happy path, and do it with code that is easy to debug, and easy for others to understand and change. Since so much of what we end up dealing with are exceptional flows, we need a concise way to deal with them. Fortunately we have the aptly named exception pattern.

I’m working on the code that parses VCalendar data so that it can be processed. I’m copying the data I care about into a simple data structure that can represent a calendar request in any format. Any logic that interacts with calendar requests would use this internal structure. I want it to be simple, only having the stuff that I need, but I don’t want to completely re-invent the wheel either, so I will use the VCalendar format as a guideline.

My next goal for the Themis project is to parse an invitation from an email. I am starting with invitations generated by MS Outlook because that’s my target audience, but a peak inside of a Google Calendar invitation gives me hope that I’ll be able to support multiple calendars without much trouble.

Outlook invitations are sent in the VCalendar format, content type “text/calendar”. The standard was published as RFC 2445 in 1998. It describes a standard layout for calendar data in the VCard format, which is described in RFC 2425.

I’m charging forward on the Shared Resource Schedule Service. There are a lot of things I’m getting into place before I start writing code. Don’t try to tell me that I’m not being agile either, you always need to design a little to write good code. The key to being agile is designing only as much as you need, and being prepared to change your mind later.

The Name

The first order of business was to choose a name. It helps to know the name before you create a project. I’m also hoping to put the source in a public repository right away so that I can talk about the coding process while I build it.

I want to start my project by dividing up the various things the system needs to do, then put them into the order I plan to approach them. I want to start with requirements that are the most risky and most important to success first, and work my way down the list until I finish with items that are neither risky nor important.

This approach gives me several advantages. It’s not an issue in this case since I don’t have any deadlines to meet, but if this were a professional project and a deadline had to be pushed up, I am more likely to have a product that does the most essential things. If I had a fixed deadline and the project starts running long, I’m more likely to have a working product that’s just missing a few less important features. In an ideal world those don’t happen, but at the end of the project the parts that were risky and/or essential have had the most time to be tested and fine-tuned as the application matures.