Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Design a sendInvite for a Calendar appointment Date: Thu, 16 Jul 2015 08:21:20 -0400 Organization: A noiseless patient Spider Lines: 121 Message-ID: References: <7500ac4e-131c-41a2-9607-b78b3318fff9@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 16 Jul 2015 12:19:56 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="858a9d65d95f4ea4d355bd116aa2cdbf"; logging-data="16186"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/8yusAjXlEJW46T9ImQv6a" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 In-Reply-To: <7500ac4e-131c-41a2-9607-b78b3318fff9@googlegroups.com> Cancel-Lock: sha1:GJlnDTbCG983ei0lKUO5vqIvzUI= Xref: csiph.com comp.lang.java.programmer:32041 On 7/15/2015 9:11 PM, zianne.james@gmail.com wrote: > Recently in an interview I was asked to design a "send invitation for an appointment to multiple contacts in a company". (Something similar to creating an Appointment in Outlook) > > Here is what I came up with, I would really appreciate some feedback, suggestions, questions. I'll offer a few, interleaved below. Some are trivial, some not. > So, after asking few questions, the interviewer wanted me to figure out how would I save the Calendar data of everyone from different timezones in my company. The invitation would have just 2 things, time and contacts... > > example: > > From: me@myCompany.com To: brad@myCompany.com; star@myCompany.com, angel@myCompany.com Time: 3:30 to 4:30 (CST) Date: 08/20/2015 > > I recommended that we save all employees data in different locations. So the DB servers will be at a location near you, which would make your calendar loading faster. There will be a centralized server which will store the machine ID against your employee id. > > Ex: > > Table Name: Machine_Mapping > > | Employee_ID | Machine_ID | > | 101 | 1 > | 102 | 2 > | 103 | 2 > | 104 | 1 > | 105 | 3 Maintaining this table could become a logistical nightmare for a large company (and your hypothetical company already qualifies as "large enough to use multiple servers in multiple time zones"). It is likely that the company already maintains some kind of related data ("Which server holds J.P. Biggley's home directory?"), and you should try to piggy-back on the existing structure. > Data on a particular machine: Table Name: Calendar_Data > > | Employee_ID | Email_ID | From | TO | Date > | 101 | brad@myCompany.com | 14:00 | 14:30 | 01/01/2014 > | 101 | brad@myCompany.com | 14:00 | 14:30 | 01/01/2015 > | 101 | brad@myCompany.com | 15:00 | 16:00 | 08/20/2015 > ( This should be a conflict as the requested timing overlaps with this ) > > | 102 | star@myCompany.com | 17:00 | 17:30 | 08/20/2015 > | 103 | angel@myCompany.com | 15:00 | 16:00 | 08/24/2015 > | 104 | me@myCompany.com | 15:00 | 16:00 | 08/24/2015 > | 104 | me@myCompany.com | 11:00 | 11:30 | 07/01/2015 .... ( This is something like a daily Scrum > | 104 | me@myCompany.com | 11:00 | 11:30 | 07/02/2015 .... meeting invite. Will this be repeated? > | 104 | me@myCompany.com | 11:00 | 11:30 | 07/03/2015 .... or there should be some way to store > | 104 | me@myCompany.com | 11:00 | 11:30 | 07/04/2015 .... it efficiently ? Please suggest. ) > | 104 | me@myCompany.com | 11:00 | 11:30 | 07/05/2015 > | 104 | me@myCompany.com | 11:00 | 11:30 | 07/06/2015 > | 104 | me@myCompany.com | 11:00 | 11:30 | 07/07/2015 Repeated appointments become *very* tricky when multiple time zones are involved. Example: In January, somebody in Berlin sets up a repeating conference call with participants in London and New York. Berlin is at UTC+1:00, London is at UTC, and New York is at UTC-05:00, so the meeting is scheduled for 16:00 in Berlin, 15:00 in London, and 10:00 in New York. Question: What happens when Germany switches to summer time on the second Sunday in March, while the U.K. and U.S. remain on Standard time until March's final Sunday? Will the meeting commence at the same UTC hour (now 17:00 Berlin, 15:00 London, 10:00 New York), or at the same Berlin time (16:00, now 14:00 London, 09:00 New York), or does the time zone of "Headquarters" (whichever that might be) rule, or ...? I saw this happen once, with a serious "enterprise-grade" calendar system. At each Standard/Summer changeover -- about six times annually, given different changeover schedules -- recurring appointments went haywire. We eventually deduced that the appointments followed the local time of the person who created them, but this wasn't foolproof: If you, for example, edited an appointment someone else had placed on your calendar, *you* became the "creator" even as the other person's time zone shifted away from yours ... Also, conflicts got created that did not exist when the originals were scheduled: In my example above, the New York participant might have a 09:00 appointment that used to precede his Berlin call but now overlaps with it ... > .... > > I was also asked to implement sendInvite method... Here is my implementation: > > public Result sendInvite(List contacts, Date date, Timestamp from, > Timestamp to) { > > List contactsHavingConflict = new ArrayList(); Now to the trivial: I forget when it happened (it several Java releases ago), but the sleeker way to write this is List contactsHavingConflict = new ArrayList<>(); ... using the (very badly mis-named) "diamond operator." > Result result = new Result(); > try { > for (Contact c : contacts) { > if (!checkAvailability(c, from, to)) { // This method will first compare the date of invitation with the dates of each contact in database. You've distributed the calendars across multiple remote servers, which may well make sense. But this means the conflict check will need to consult all those remote servers, which is going to take extra time. Also, there's a potential race condition: Two different people trying to schedule appointments with J.P. Biggley may both find him "available" at 14:00 next Thursday before either of them actually claims the time slot; if they both do so, J.P. is double-booked. Also, about those repeating appointments: J.P. Biggley may well be available next Thursday at 14:00, but will he also be available at 14:00 the Thursday after that, and after that, and ...? How far into the future should your conflict-checker peer? My impression is that a full-blown calendaring system is too complex a topic for an interview question, unless you're allowed quite a few simplifications. (In a long-ago interview I was asked to design a service along the lines of TinyURL; you would not *believe* the details I glossed over and the shortcuts I took!) -- esosman@comcast-dot-net.invalid "Don't be afraid of work. Make work afraid of you." -- TLM