A random event from my calendar serializes to 740 bytes of iCalendar. An extremely busy calendar containing one event every 15 minutes 9am-5pm 7 days per week only contains 11680 entries for a full year, which works out to around 8MB.<p>Would suggest instead of designing a schema at all, a calendar is a good example of a problem that might be far better implemented as a scan. Optimizing an iCalendar parser to traverse a range of dumped events at GB/sec-like throughputs would mean the above worst-case calendar could be scanned in single-digit milliseconds.<p>Since optimizing a parser is a much simpler problem to solve once than changing or adding to a bad data model after it has many users, and that the very first task involving your new data model is probably to write an iCalendar importer/exporter anyway, I think this would be a really great trade off.
This article about dealing with recurrence in applications was an eye-opener for me. Definitely recommend giving it a read. <a href="https://github.com/bmoeskau/Extensible/blob/master/recurrence-overview.md">https://github.com/bmoeskau/Extensible/blob/master/recurrenc...</a>
The worst I have ever messed up during an interview was building a simple booking system that had to do recurring appointments. I never felt that lost and confused trying to accomplish something in code since my early university days lol<p>To this day whenever I have to work with anything datetime related I dread it, it just does not click in my head for some reason
Modeling a system is an under-appreciated skill. In a new domain, however, this should really start with an analysis of the entire problem so as to capture both the static structure of the system (i.e. class model) and its dynamic behavior (i.e. use cases). Jumping directly into a static database model tends to leave out the dynamic behavior. That might be OK in a simple CRUD app like this one, but could be a big mistake in more complex systems.
I found this to be a good introduction and a well-chosen domain to demonstrate modelling.<p>The term “anchor” feels kind of weird to me, but the explanation is so concrete/grounded (like an actual anchor) that I guess it works well enough.<p>The concept of defining the attributes via a question is solid, great way to get clarity quickly. Too often we jump to a minimal column/property name without defining what question we’re trying to answer, and thus not shaking loose any ambiguity in the mind of the customer(s).
Timezones will bend your mind, especially around the transition times.<p>Assuming your timezone jumps forward one hour for daylight savings time and falls back one hour for transition to standard time...<p>When your time skips forward one hour, your 1 hour event may now be displayed as spanning two hours - the second hour will not be reachable/does not exist.<p>When your time falls back one hour, your 1 hour event may now show as spanning 2 hours or 0 hours.<p>Timezones are a man-made construct so don't hardcode values cause things will change...
You don't want to store two dates for an event. It's easier to store the start time of the event and a duration for the event. This will make the logic for updating your events simple. You can always calculate the end time of the event based off the start and duration.
Years ago I worked on a calendar application with recurrence. After lots of research I settled on using RRules to represent this, which I was very pleased with. That initial work was when I was at an agency.<p>Later I joined the company full time and discovered to my amazement that a contractor from a different company had removed the RRules in favour of creating and destroying instances of events on the fly. It had no/little fault tolerance so sometimes the script (which did other things that would sometimes fail) would fail to create new events. You'd have monthly recurring events with missing months.<p>I found it so frustrating that (after going through a lot of thought and research) that someone hadn't put anywhere near as much effort into removing mine. It took just a few weeks at that company to realise that the CEO expected the Engineering team to pump out features (that nobody used) at his will and, in the uncertainty of the job market, sadly I stayed there for 2 years.<p>Unrelated footnote: After Googling them, it's really sad to see what are blatantly fake reviews by the CEO on Glassdoor all written in the same style with nothing bad to say. I (and a bunch of other people I know who worked there) hated him, but the silver lining is that I wrote some of my best essays there. The CTO was hopeless too.
I once implemented the backend of a calendar and resource control for a low code platform.<p>The control is highly customizable, with a lot of views to chose from, daily, monthly, yearly... but also resource views (you can book resources with custom groupings, by plugin, by the resource-ID, whatever...), define "plugins" on the data sources, what's the from- and to- columns, the title column, what's the resource (may be from a foreign key / 1:1 relationship or 1:N if it's from a "child" data source or from the same data source/table).<p>Furthermore I've implemented different appointment series, to chose from (monthly, weekly (which weekdays), daily...), which column values should be copied. Also appointment conflicts (or only conflicts if they book the same resource). You could also configure buffers before and after appointments where no other appointment can be.<p>That was a lot of fun and also challenge sometimes regarding time zones and summer/winter time in Europe and so on :-)
Nicely done. This is one of those aspects which is not really touched on in most courses.<p>Will try to get my company to get a few copies of your book for each of our team member.