Google Calendar के लिए database design tutorial

 (kb.databasedesignbook.com)
13 पॉइंट द्वारा GN⁺ 2024-07-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Google Calendar clone की scheduling functionality को उदाहरण बनाकर यह दिखाया गया है कि tables बनाने से पहले logical model पूरा किया जाए और फिर उसे SQL schema में बदला जाए
  • मुख्य तरीका यह है कि पहले User, DayEvent, TimeEvent, Timezone जैसे anchor खोजे जाएँ, और attributes तथा 1:N·M:N links के जरिए requirements और cardinality को validate किया जाए
  • events को all-day events और time-based events में बाँटा गया है, और time-based events के लिए start·end की local time तथा उनकी-अपनी Timezone store की जाती है ताकि timezone बदलने की संभावना भी संभाली जा सके
  • recurring events को frequency, interval, monthly recurrence method, end condition, और weekdays links से व्यक्त किया गया है, और screen rendering व individual instance changes के लिए DaySlot और TimeSlot को अलग anchor रखा गया है
  • अंतिम physical design में “हर anchor के लिए एक table” को आधार बनाया गया है, लेकिन DayOfTheWeek के लिए table नहीं बनाया गया, इसलिए 6 anchor tables और 2 M:N link tables सहित कुल 8 SQL tables में इसे समेटा गया है

डिज़ाइन अप्रोच: पहले logical model बनाना

  • लक्ष्य Google Calendar clone की calendar functionality को आधार बनाकर, वास्तविक project के करीब database table design की प्रक्रिया दिखाना है
  • पूरा flow यह है कि पहले calendar data को describe करने वाला complete logical model बनाया जाए, और फिर उस model को physical table structure में बदला जाए
  • शुरुआती भाग में ऐसे logical model की चर्चा है जो किसी खास database से बंधा नहीं है
    • MySQL, Postgres, पारंपरिक relational server, NoSQL, cloud database से स्वतंत्र होकर business requirements को model किया जाता है
  • बाद का भाग logical model को physical tables में बदलने का एक तरीका दिखाता है
    • जिन systems में requirements बहुत अधिक जटिल नहीं हैं, वहाँ इसे एक valid design approach माना जा सकता है

समस्या की सीमा: Google Calendar की मुख्य scheduling functionality

  • target system एक multi-user system है, और user-related data को न्यूनतम स्तर तक ही model किया गया है
  • events में title, description, location जैसे attributes हो सकते हैं, लेकिन सबसे जटिल हिस्सा time और date है
  • model किए जाने वाले events में ये अंतर शामिल हैं
    • all-day events और time-based events
    • recurring events और non-recurring events
    • कई दिनों तक चलने वाले all-day events
    • timezone से जुड़े time-based events, जिनमें start·end अलग dates या अलग timezones में हो सकते हैं
  • recurring events में ये रूप शामिल हैं
    • हर दिन या हर N दिनों पर दोहराव
    • हर हफ्ते कुछ खास weekdays पर दोहराव, और 2 या उससे अधिक हफ्तों का interval भी
    • हर महीने किसी खास तारीख पर, या किसी खास हफ्ते के weekday पर दोहराव
    • हर साल दोहराव
    • हमेशा के लिए, किसी खास तारीख तक, या निश्चित संख्या तक दोहराव
  • recurring event के किसी specific instance को दूसरी date·time पर move किया जा सकता है या delete किया जा सकता है
  • कुछ instances के गुजर जाने के बाद भी recurring schedule को बदल पाना चाहिए

anchor, attribute और link से requirements व्यक्त करना

  • modeling की शुरुआत पहले anchor खोजने से होती है
    • anchor वह चीज़ है जिसे गिना जा सकता है और database में जोड़ी जा सकती है, जैसे User, Event
    • अगर स्वाभाविक रूप से “There are 200 Users in our database”, “When this button is clicked, a new DayEvent is created” जैसा कहा जा सकता है, तो उसे anchor माना जा सकता है
  • attributes anchor के बारे में वास्तविक जानकारी store करते हैं
    • User में email attribute रखा जाता है
    • DayEvent में name, start date, end date रखे जाते हैं
    • single-date event में भी start date और end date को एक ही value से store किया जाता है, ताकि multi-day event जैसी ही structure में उसे handle किया जा सके
  • जब दो anchors के बीच संबंध हो, तो attribute की जगह link का उपयोग होता है
    • “किस User ने DayEvent बनाया” यह DayEvent attribute में सीधे User ID डालने वाला logical attribute नहीं, बल्कि User और DayEvent के बीच का link है
    • links में 1:N, M:N, 1:1 cardinality का उपयोग होता है, और दो वाक्यों से दोनों दिशाओं का अर्थ validate किया जाता है
  • User और DayEvent के बीच 1:N link है
    • एक User कई DayEvent बना सकता है
    • एक DayEvent एक ही User द्वारा बनाया जाता है

time-based events और Timezone handling

  • time-based events के लिए Timezone और TimeEvent anchors जोड़े गए हैं
  • Timezone model को tutorial के उद्देश्य से न्यूनतम रखा गया है, और केवल human-readable name attribute रखा गया है
    • उदाहरण value है Europe/Kyiv
    • वास्तविक timezone definition के लिए UTC offset, daylight saving time, DST start·end, DST लागू होने पर UTC offset, historical definitions, active·deprecated status जैसी चीज़ें चाहिए होंगी, लेकिन उन्हें अलग कार्य के रूप में छोड़ा गया है
  • TimeEvent में name, start local date·time, end local date·time रखे जाते हैं
    • उदाहरण values हैं 2024-01-14 12:30, 2024-01-14 13:15
  • time को केवल UTC में store नहीं किया जाता, बल्कि user द्वारा input की गई local time में store किया जाता है
    • उदाहरण के तौर पर 6 सितंबर 2058 को 09:30~11:00 Cologne time का billiards game उस समय के UTC offset के बारे में अभी निश्चित रूप से नहीं बता सकता, इसलिए user ने जैसा input किया है वैसा ही store करना चाहिए
    • बाद में स्थानीय कानून बदलें तो उसके अनुसार adjustment संभव होना चाहिए
  • TimeEvent के पास start timezone और end timezone के लिए अलग-अलग Timezone के साथ 1:N links होते हैं
    • flight ticket के उदाहरण की तरह Amsterdam से London जाने वाली उड़ान में departure और arrival अलग timezones में हो सकते हैं
    • अधिकतर time-based events में start·end timezone समान होंगे, लेकिन सामान्य स्थिति के लिए दोनों को हमेशा specify किया जाता है

recurring all-day events की modeling

  • recurring all-day events को DayEvent में recurrence-related attributes और links जोड़कर व्यक्त किया गया है
  • recurrence frequency को either/or/or type attribute के रूप में रखा गया है
    • possible values हैं daily, weekly, monthly, annually
    • अगर value set न हो, तो उसे non-recurring event माना जाता है
  • recurrence interval एक integer attribute है जिसका अर्थ केवल “recurring event होने पर” है
    • उदाहरण value है 2
    • इसका अर्थ हर 2 दिन, हर 2 हफ्ते, हर 2 महीने जैसा होता है
  • monthly recurrence के लिए अलग selection attribute है
    • उसी तारीख पर दोहराने के लिए same_day
    • मूल तारीख वाले उसी week-number के weekday पर दोहराने के लिए same_weekday
  • weekly recurrence के specific weekdays को string array attribute से नहीं, बल्कि DayOfTheWeek anchor और M:N link से model किया गया है
    • DayOfTheWeek ID के उदाहरण हैं Mon, Tue, Wed, Thu, Fri, Sat, Sun
    • एक DayEvent कई DayOfTheWeek पर हो सकता है, और एक DayOfTheWeek कई DayEvent में शामिल हो सकता है
  • recurrence end condition भी attribute के रूप में रखी जाती है
    • forever
    • until_date
    • N_repetitions
    • until_date होने पर end date attribute जोड़ा जाता है
    • N_repetitions होने पर repetition count attribute जोड़ा जाता है

rendering और individual instance changes के लिए Slot

  • अगर recurring events को केवल एक original event के रूप में store किया जाए, तो किसी खास week screen पर दिखाने वाले events को खोजने वाली query जटिल हो सकती है
  • screen rendering और recurring event के individual changes के लिए Slot की अवधारणा लाई गई है
    • DaySlot किसी खास date के all-day event instance को दर्शाता है
    • TimeSlot किसी खास date और time के time-based event instance को दर्शाता है
  • DaySlot में date और skipped है या नहीं रखा जाता है
    • किसी specific slot की date बदली जा सकती है
    • अगर किसी खास हफ्ते की meeting cancel हो जाए, to उस DaySlot को skipped mark किया जा सकता है
  • DayEvent और DaySlot के बीच 1:N link है
    • एक DayEvent कई DaySlot बना सकता है
    • एक DaySlot एक ही DayEvent से संबंधित होता है
    • non-recurring DayEvent के लिए भी हमेशा DaySlot बनाया जाता है, ताकि rendering code सरल रहे
  • infinitely recurring events में slot generation range की समस्या होती है
    • birthday जैसे हर साल हमेशा दोहरने वाले event के लिए 100 years जैसी कोई arbitrary limit तक slots बनाए जा सकते हैं
    • या जब user बहुत दूर future की calendar page मांगे, तब on-demand बनाए जा सकते हैं
  • date calculation में सावधानी चाहिए
    • 29 फरवरी का birthday
    • हर महीने 31 तारीख को होने वाला monthly event
    • ऐसे मामलों में यह तय करना होगा कि इन्हें मना किया जाए, या एक दिन पहले/बाद में shift किया जाए

TimeSlot और timezone

  • recurring time-based events पर भी all-day events जैसा ही approach लागू करके TimeSlot anchor रखा गया है
  • TimeSlot किसी specific event के specific date·time instance के बराबर होता है, और recurring TimeEvent कई TimeSlot से जुड़ सकता है
  • TimeSlot attributes हैं start local date·time, end local date·time, और skipped है या नहीं
  • किसी specific TimeSlot को दूसरी date पर move किया जा सकता है, इसलिए start·end time information अलग से रखी जाती है
  • TimeSlot के पास भी start timezone और end timezone के लिए अलग-अलग Timezone के साथ 1:N links होते हैं
  • TimeEvent और TimeSlot के बीच 1:N link है, और non-recurring TimeEvent के लिए भी TimeSlot बनाया जाता है

पूरा logical model

  • अब तक परिभाषित anchors कुल 7 हैं
    • User
    • Timezone
    • DayEvent
    • TimeEvent
    • DayOfTheWeek
    • DaySlot
    • TimeSlot
  • attributes में User email, Timezone name, DayEvent का name·start date·end date·recurrence info, TimeEvent का name·start·end local time, और DaySlot व TimeSlot के occurrence time तथा skipped status शामिल हैं
  • links कुल 10 हैं
    • User और DayEvent, User और TimeEvent
    • Timezone और TimeEvent के start·end timezones
    • DayEvent और DayOfTheWeek, TimeEvent और DayOfTheWeek
    • DayEvent और DaySlot, TimeEvent और TimeSlot
    • Timezone और TimeSlot के start·end timezones

SQL tables में बदलना

  • physical design में शिक्षण उद्देश्य से हर anchor के लिए एक table strategy का उपयोग किया गया है
  • logical model में 7 anchors, 21 attributes, और 10 links हैं
  • सामान्य रूप से anchors की संख्या और M:N links की संख्या जोड़ने पर 9 tables बनते, लेकिन अंतिम design में DayOfTheWeek को special case की तरह handle किया गया है और उसके लिए physical table नहीं बनाई गई
  • अंतिम SQL tables कुल 8 हैं
    • users
    • timezones
    • day_events
    • time_events
    • day_slots
    • time_slots
    • day_event_dows
    • time_event_dows
  • 1:N links को N-side table में foreign key जैसे columns के रूप में रखा गया है
    • day_events.user_id
    • time_events.user_id
    • time_events.start_timezone_id
    • time_events.end_timezone_id
    • day_slots.day_event_id
    • time_slots.time_event_id
    • time_slots.start_timezone_id
    • time_slots.end_timezone_id
  • M:N links को अलग tables में बनाया गया है
    • day_event_dows DayEvent और weekday को जोड़ता है
    • time_event_dows TimeEvent और weekday को जोड़ता है
  • physical types को logical types के अनुसार चुना गया है
    • strings के लिए VARCHAR
    • dates के लिए DATE
    • local date·time के लिए DATETIME
    • yes/no के लिए TINYINT UNSIGNED
    • ऐसी intertwined attributes जिनका अर्थ केवल कुछ conditions में हो, उनके लिए NULL allow करने वाले types का उपयोग किया गया है
  • NULL और sentinel values को logical model नहीं, बल्कि physical schema की अवधारणा के रूप में देखा गया है

indexes और छोड़े गए attributes

  • उदाहरण SQL schema में वे indexes नहीं हैं जिन्हें अनुभवी database developer आवश्यक मान सकते हैं
    • उदाहरण के लिए day_events.user_id पर index की जरूरत हो सकती है
  • किन columns या column combinations पर index रखा जाए, यह इस बात पर निर्भर करता है कि application tables को कैसे query करती है
  • index विषय के लिए Use The Index, Luke देखा जा सकता है
  • logical schema समझाते समय कुछ attributes समान pattern होने के कारण छोड़े गए हैं
    • user name
    • user password hash
    • event location
    • invited people list
  • छोड़े गए data elements को भी उसी तरीके से logical model table में जोड़कर SQL schema में reflect किया जा सकता है

पूरी प्रक्रिया

  • business problem का वर्णन करने वाले free-form text से शुरुआत की जाती है
  • anchors की list बनाई जाती है
  • attributes की list बनाई जाती है, और attribute के अर्थ को प्रश्न के रूप में स्पष्ट लिखा जाता है
  • links की list बनाई जाती है, और cardinality सही है या नहीं इसे वाक्यों से verify किया जाता है
  • जरूरत हो तो logical model के आधार पर graphic schema बनाया जाता है
  • table names, column names, physical data types भरकर physical model लिखा जाता है
  • पिछले चरणों की जानकारी का उपयोग करके CREATE TABLE statements से SQL schema लिखा जाता है
  • schema को database server पर submit किया जाता है, typos ठीक किए जाते हैं, फिर दोबारा submit किया जाता है
  • logical model को team के साथ share किया जाता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-07-25
Hacker News की राय

  • मेरे कैलेंडर की किसी भी एक रैंडम event को iCalendar में serialize करने पर करीब 740 bytes लगते हैं, और सुबह 9 बजे से शाम 5 बजे तक हर 15 मिनट में events वाले बेहद व्यस्त calendar में भी पूरे साल के लिए 11,680 items होते हैं, यानी सिर्फ करीब 8MB
    इसलिए schema design करने के बजाय, calendars को बस sequential scan से implement करना शायद कहीं बेहतर समस्या जैसा लगता है। अगर iCalendar parser को optimize करके dumped event range को GB/s-level throughput पर scan कराया जाए, तो ऊपर वाला worst case भी single-digit milliseconds में scan हो सकता है
    खराब data model को बहुत सारे users तक फैलने के बाद बदलने या extend करने की तुलना में parser optimization एक बार हल की जाने वाली कहीं सरल समस्या है, और वैसे भी नए data model का पहला काम शायद iCalendar import/export ही होगा, इसलिए यह काफी अच्छा trade-off लगता है

    • फिर क्या SQL के BETWEEN ... AND ... जैसे range search को दोबारा बनाना नहीं पड़ेगा? Users 1, 2, 3 के events ढूंढना भी वैसा ही है
      असली application में user accounts जैसी चीजें पहले से relational database में होंगी, लेकिन अचानक directory के events scan करने होंगे और फिर उनके results को database records से जोड़ना होगा
      किसी खास application में यह सही हो सकता है, लेकिन databases कुछ खास कामों में सचमुच बहुत अच्छे होते हैं और इसलिए अच्छे विकल्प बनते हैं। सही indexes हों तो वैसा ही या उससे बेहतर throughput भी मिल सकता है। जब तक आप events के लिए कोई clever directory structure न बना लें—जो असल में एक-dimensional index जैसा ही है—जबकि database में कई dimensions और dimension combinations पर indexes बनाए जा सकते हैं
      आखिरकार बात सही है, और यह trade-off का मामला है
    • iCalendar को calendar data तक तेज़ access के storage format के रूप में नहीं, बल्कि exchange format के रूप में design किया गया था
      format में उसकी उम्र दिखती है; यह साफ दिखता है कि इसे XML/JSON के “popular” होने से पहले design किया गया था
      संदर्भ: https://en.wikipedia.org/wiki/ICalendar
    • DBMS के बिना किया जा सकता है, लेकिन data को फिर भी अच्छे schema की जरूरत होती है, और वह iCalendar records का bundle नहीं होना चाहिए। उदाहरण के लिए stable user ID के बजाय सिर्फ बदले जा सकने वाले और दोहराए जाने वाले email addresses हैं
    • ऐसा approach लेख में बताए गए infinite time slots problem का भी ज्यादा साफ समाधान दे सकता है

  • Applications में recurring events संभालने पर यह लेख है, और निजी तौर पर मेरी आंखें खोल देने वाला था। जरूर पढ़ने की सलाह दूंगा: https://github.com/bmoeskau/Extensible/blob/master/recurrenc...

    • दिलचस्प है कि original post की सलाह और इस लेख की सलाह एक-दूसरे के उलट हैं
      Original post कहती है कि हर date के साथ हमेशा timezone store करो, और linked लेख कहता है कि सब कुछ UTC में convert करो। इस हिस्से में मैं original post से सहमत हूं
      Original post कहती है कि हर event के लिए database row बनाओ, और linked लेख कहता है कि ऐसा मत करो। इस हिस्से में मैं linked लेख से सहमत हूं

  • Interview में मेरी सबसे बड़ी गड़बड़ी तब हुई थी जब मुझे एक simple reservation system बनाना था और उसमें recurring reservations भी handle करने थे
    College के शुरुआती दिनों के बाद, code से कुछ कर दिखाने की कोशिश में मैं इतना खोया और confused कभी नहीं हुआ था। आज भी date/time से जुड़ा काम करना हो तो पहले डर लगता है, और पता नहीं क्यों यह मेरे दिमाग में ठीक से fit नहीं बैठता

    • “reservation system design करो, लेकिन recurring reservations भी शामिल करो” वाला design question कुछ वैसा ही है जैसे “strings की list sort करने वाला function लिखो, लेकिन arbitrary UTF-8 strings और सभी locales में alphabetical order conventions का पालन होना चाहिए”
      ऊपर से simple लगता है, लेकिन real world में generally काम करने लायक बनाना चाहें तो यह लगभग असंभव रूप से complex हो जाता है
    • खुद को बहुत दोष देने की जरूरत नहीं है। मुझे एक CMS के calendar को बेहतर बनाकर कहीं ज्यादा features support कराने का काम मिला था, और उसने लगभग मुझे खा ही लिया। उस समय मेरे पास करीब 8 साल का experience था
      यह धोखे से कठिन समस्या है, और बेहतरीन data modeling skill मांगती है

  • Systems को model करने की क्षमता को कम आंका जाता है। नए domain में system की static structure, यानी class model, और dynamic behavior, यानी use cases, दोनों पकड़ने के लिए पूरे problem analysis से शुरू करना चाहिए
    सीधे static database model पर कूदने से dynamic behavior छूटना आसान है। ऐसे simple CRUD apps में यह ठीक हो सकता है, लेकिन ज्यादा complex systems में यह बड़ी गलती हो सकती है

    • Data scientist के रूप में, दिखने में simple “schema कैसे बनाओगे” जैसे interview questions पर मुझे कुछ बार मौके पर ही काफी मुश्किल हुई है
      जो आखिरी सवाल याद है, वह था कि coupons वाले product table को कैसे बनाओगे। शुरुआत में लगा दो tables काफी होंगे, लेकिन क्या history भी maintain नहीं करनी चाहिए? फिर product और coupon के हिसाब से date/time डालकर update करना होगा। अब table indexes भी सोचने पड़ेंगे, और discount price पाने के लिए join अच्छा तरीका है या नहीं, यह भी सोचना होगा। ज्यादातर coupons कोई व्यक्ति सिर्फ एक बार use कर सकता है, तो इसे आखिर implement कैसे करें?
      शायद वे सिर्फ simple product + coupon tables चाहते थे, लेकिन मैं अकेला काफी देर तक पागलों की तरह गहराई में उतरता रहा
    • ऐसे analysis का output कैसा दिखता है? अगर कोई example document या किसी book chapter जैसा reference link हो तो जानना चाहूंगा

  • Modeling दिखाने के लिए यह अच्छी तरह चुना गया domain है और मुझे यह अच्छा introductory लेख लगता है
    “anchor” term थोड़ी अजीब लगती है, लेकिन explanation सचमुच anchor की तरह बहुत concrete और जमीन से जुड़ी है, इसलिए काम कर जाती है
    सवालों के जरिए attributes define करने का concept मजबूत है। हम किस question का answer देना चाहते हैं, यह define किए बिना अक्सर सीधे minimum columns/attribute names पर कूद जाते हैं, और फिर customer के दिमाग की अस्पष्टता साफ नहीं होती। question-based attribute definition जल्दी clarity पाने का अच्छा तरीका है

    • “anchor” term Anchor Modeling(https://en.wikipedia.org/wiki/Anchor_modeling) से ली गई है। “Entity” बहुत widely used है, लेकिन यह अनावश्यक baggage और assumptions ला सकती है, इसलिए मैं इसे इस्तेमाल नहीं करना चाहता था
      ऊपर से यह term बहुत over-loaded है। Computer science में लगभग हर चीज object या entity ही है
      सवालों के जरिए attributes define करने का concept मजबूत है—यह प्रतिक्रिया इस approach की validity के लिए एक महत्वपूर्ण confirmation है

  • Time zones खासकर transition के आसपास दिमाग घुमा देते हैं
    मान लीजिए time zone daylight saving time में एक घंटा आगे कूदता है, और standard time पर लौटते समय एक घंटा पीछे जाता है
    जब समय एक घंटा आगे skip करता है, तो 1 घंटे का event स्क्रीन पर 2 घंटे तक फैला हुआ दिख सकता है, और वह दूसरा घंटा पहुँचा नहीं जा सकता या मौजूद ही नहीं होता
    जब समय एक घंटा पीछे जाता है, तो 1 घंटे का event 2 घंटे जैसा दिख सकता है या 0 घंटे जैसा दिख सकता है
    Time zones इंसानों की बनाई संरचना हैं, इसलिए values को hardcode नहीं करना चाहिए. वे कभी न कभी बदलेंगी

    • यात्रा को भी ध्यान में रखते हुए समय track करना और दिलचस्प हो जाता है. पहली बार यह मैंने कई दिनों तक समुद्र में रहने वाले जहाज़ पर time tracking करते समय झेला था
      आप time zones को दोनों दिशाओं में बार-बार पार कर सकते हैं, international date line भी पार कर सकते हैं, और ऐसा भी हो सकता है कि local start date/time, local end date/time से बाद में आए
    • क्या मतलब यह है कि calendar को time zone के बिना पूरी तरह UTC में बनाया जाए? मैं मानता हूँ कि time zones हमने बनाए हैं, लेकिन वे बेहतर regional organization के लिए बनाए गए हैं. हम दुनिया भर के ग्राहकों के साथ काम करते हैं और हर कोई time zones इस्तेमाल करता है. निजी तौर पर यह काफ़ी बेतुकी मांग लगती है
      बेहतर होगा कि अभी भी daylight saving time इस्तेमाल करने वाले कुछ क्षेत्रों में daylight saving time की अवधारणा खत्म करने पर ध्यान दिया जाए. खासकर आने वाले transition के बाद की schedules plan करते समय यही time zones के बीच सबसे ज्यादा confusion पैदा करता है

  • Event में दो dates store नहीं करना चाहता. Event का start time और duration store करना आसान है
    इससे event update logic सरल हो जाता है. End time को start time और duration के आधार पर कभी भी calculate किया जा सकता है

    • सच कहूँ तो तीनों चीजें, यानी start·end·duration, सब store कर लें और purpose के हिसाब से जो चाहिए उसे use करें. बस alternative representations को sync रखने के लिए एक single entry/update point होना चाहिए
    • वह तरीका database performance के लिए problem बन सकता है. हर query के समय duration को on the fly calculate करना पड़ेगा
    • उल्टा भी तो वही नहीं है? Start और end हों तो duration बस calculate कर सकते हैं

  • पहले मैंने recurring schedules वाली calendar application पर काम किया था. काफी research के बाद इन्हें represent करने के लिए RRules इस्तेमाल करने का फैसला किया, और उससे बहुत संतुष्ट था. वह शुरुआती काम मैंने agency में रहते हुए किया था
    बाद में जब मैं उसी company में full-time जुड़ा, तो यह देखकर हैरान रह गया कि किसी दूसरी company के contractor ने RRules हटा दिए थे और event instances को on the fly बनाने और delete करने वाला तरीका लगा दिया था. Fault tolerance लगभग नहीं थी, इसलिए दूसरे काम भी करने वाली और कभी-कभी fail होने वाली script नए events बनाना fail कर जाती थी. नतीजा यह होता कि monthly recurring event में कोई महीना गायब हो जाता
    बहुत सोच-विचार और research से बनाई चीज़ को किसी ने उतनी मेहनत किए बिना हटा दिया, यह बेहद frustrating था. उस company में कुछ हफ्ते रहने भर से समझ आ गया कि CEO engineering team से अपनी मर्जी के ऐसे features लगातार बनवाने की उम्मीद करता था जिन्हें कोई इस्तेमाल नहीं करता था, और hiring market की uncertainty के कारण दुख की बात है कि मैं 2 साल तक वहीं रहा
    और हाँ, बाद में search करने पर Glassdoor पर CEO द्वारा लिखे हुए साफ़ fake reviews मिले, सबका writing style एक जैसा था और उनमें एक भी negative बात नहीं थी, यह सचमुच कड़वा अनुभव था. मैं और वहाँ काम कर चुके कई परिचित उसे नापसंद करते थे, लेकिन यह consolation है कि उसी company में मैंने अपने कुछ बेहतरीन essays लिखे. CTO भी बेकार था

  • एक समय मैंने low-code platform के लिए calendar और resource control backend implement किया था
    Control बहुत ज्यादा customizable था, और daily·monthly·yearly जैसे कई views के साथ resource view भी चुना जा सकता था. Custom groups से resources reserve किए जा सकते थे, और plugin-wise, resource ID-wise आदि तरह से group किए जा सकते थे. Data source में “plugins” define किए, और start/end columns, title column, resource column भी specify किए. Resources foreign key या 1:1 relation से आ सकते थे, या “child” data source के 1:N relation से, या उसी data source/table से भी आ सकते थे
    साथ ही monthly, weekly, specific weekdays, daily जैसी अलग-अलग appointment series implement कीं, और कौन-से column values copy करने हैं यह भी चुनने दिया. Appointment conflicts भी handle किए, जिसमें केवल same resource reserve करने पर ही conflict माना जा सकता था. Appointment से पहले और बाद में ऐसा buffer भी set किया जा सकता था जिसमें कोई और appointment नहीं डाला जा सके
    Europe के time zones और summer/winter time जैसी चीज़ों के कारण कभी-कभी चुनौतीपूर्ण था, लेकिन काम काफ़ी मजेदार था

  • Google Calendar में मुझे सिर्फ calendar का अपना change log चाहिए. कृपया database में इसे add कर दें