چهار کلیک برای آنلاین شدن. سی ثانیه، از در تا پایان. یک اپ زنده و متکی بر سرور برای هر حساب در سطح رایگان. نیم ثانیه تأخیر اضافه در اولین درخواستی که یک زیردامنهی تازه پاسخ میدهد، و بعد از آن هیچ. سهتای این اعداد اطلاعات جالب توجهاند — از آن نوع که سر تکان میدهید و تا فصل بعد فراموش میکنید. اما «یک» عددی است که واقعاً نحوهی کارتان را تغییر میدهد، پس بیشتر این فصل را به آن اختصاص میدهم.
چرا سقف یک است، نه صفر و نه نامحدود
بیشتر ابزارهای بدونکد که امکان انتشار رایگان یک فرانتاند را میدهند، یا اصلاً به اپهای متکی بر سرور دست نمیزنند، یا آنقدر شدید محدودشان میکنند که «رایگان» فقط یک ظاهرسازی است. اینجا، ساختی با حسابهای کاربری، پایگاه داده، یا وضعیت چندنفره، از همان دکمهی انتشار یک صفحهی ایستا منتشر میشود، و سمت سرور بهعنوان بخشی از همان یک عمل، میزبانی و مدیریت میشود — بدون تدارک جداگانهی پایگاه داده، بدون نیاز به تنظیم متغیرهای محیطی، بدون کشف سه روز بعد که ورود در پیشنمایش کار میکند اما در پروداکشن با خطای ۵۰۰ روبهرو میشود چون بکاند اصلاً دیپلوی نشده. این واقعی است، و به همین دلیل است که وقتی به سقف برمیخورند، مردم شگفتزده میشوند: تا آن نقطه همهچیز نامحدود به نظر میرسید.
اینطور نیست. در سطح رایگان دقیقاً یک اپ زنده و متکی بر سرور در هر لحظه دارید. ساختهای ایستا در این سقف حساب نمیشوند — هر تعداد صفحهی تبلیغاتی و سایت نمونهکار که میخواهید منتشر کنید، محدودیتی نیست. اما دومین ساختی که به پایگاه داده یا فرآیند پایدار خودش نیاز دارد، باید نوبتش را صبر کند، در حالی که کاملاً ساخته شده و قابل پیشنمایش است، فقط در آدرس خودش زنده نیست. اگر همان هفته سه ایدهی سرویس نرمافزاری را پروتوتایپ میکنید، فقط یکی میتواند اسلات محاسباتی واقعی را اشغال کند؛ آن دوتای دیگر محصولاتی تمامشده بدون آدرساند. به نظرم این خط در جای معقولی کشیده شده — سرو یک بستهی ایستا از لبهی شبکه تقریباً هیچ هزینهای برای پلتفرم ندارد، اما یک فرآیند سرور گرم دارد — ولی یعنی تصمیم اینکه کدام ایده لایق اسلات است باید پیش از زدن دکمهی انتشار گرفته شود، نه بعد از اینکه به داشتن دو تا همزمان زنده دل بستید.
چهار کلیک، برای ثبت در تاریخ
- روی کارت ساخت، Publish را انتخاب کنید.
- یک اسلاگ انتخاب کنید — بخش نام کاربری شما در
yourname.buildmidas.com. اسلاگهای گرفتهشده جایگزین پیشنهاد میکنند. - تأیید کنید.
- آدرس را از روی کارت کپی کنید، یا بعداً آن را در صفحهی Published پیدا کنید.
بدون DNS، بدون حسابهای خارجی، بدون انتظار برای انتشار تنظیمات. و دربارهی آن نیم ثانیه: صف یا تأخیر «۲۴ ساعت دیگر بررسی کنید» نیست، فقط گرمشدن معمولی کش CDN است. اولین بازدیدکنندهی یک زیردامنهی تازه ممکن است یک لحظه تأخیر اضافه بگیرد در حالی که نزدیکترین گرهی لبه بستهی داراییها را میکشد؛ بازدیدکنندهی دوم، و همهی بعدیها، از کش دریافت میکنند. در عمل متوجه نمیشوید — منتشر میکنید، روی لینک میزنید، و از قبل فوری به نظر میرسد. فقط این را میگویم چون کسی که کارش اسکرینشات گرفتن از زمان بارگذاری است، بالاخره خواهد پرسید چرا درخواست یک و درخواست ده یکسان نیستند، و حالا میدانید.
اسلاگ تنها تصمیمی است که ارزش کند کردن دارد
بقیهی این فرآیند ماشینی است؛ اسلاگ بخشی است که یک انسان باید آن را با صدای بلند بگوید یا از حفظ تایپ کند، پس ارزش یک لحظه تأمل را دارد. «demo-v2-final-final» برای تست داخلی خوب است و برای پیامک کردن به کارفرما بد. آدرس را پیش از تأیید برای خودتان بخوانید — riverside-cafe.buildmidas.com روان خوانده میشود، riverside-cafe-mvp2.buildmidas.com روان نیست. کلمات کوتاه و عمومی در پلتفرمی که مدتی است وجود دارد سریع مصرف میشوند، به همین دلیل اسلاگ گرفتهشده بهجای خطای ساده، پیشنهاد میدهد. یکی را بردارید یا رد کنید، اما عمداً تصمیم بگیرید — دیدهام کسانی که وسط دمو، چون فوراً به لینک نیاز داشتند، هرچه جعبه پیشنهاد داد را گرفتند، بعد ماهها با نامی نامناسب ماندند چون هرگز لحظهی طبیعیای برای اصلاحش پیش نیامد.
انتشار مجدد تا زمانی که خودتان نگویید، به نسخهی زنده دست نمیزند
این حقیقتی است که ارزش دارد زود درونیاش کنید: ویرایش یک ساخت منتشرشده، سایت زنده را جابهجا نمیکند. میتوانید چیزی را بشکنید، تغییر چیدمانی جسورانه امتحان کنید، یک هفته تکرار کنید — آدرسی که کارفرما از قبل بوکمارک کرده، همچنان همان چیزی را که آخرین بار منتشر کردهاید سرو میکند، تا وقتی عمداً دوباره منتشر کنید.
این کل داستان بازگردانی شماست، و خوب است دقیقاً چون خستهکننده است. نسخهی ۶ باگی دارد — فرمی که بیسروصدا از ارسال باز میماند — و شما به سراغ فرمان بازگردانی یا تیکت پشتیبانی نمیروید. تاریخچهی نسخهها را باز میکنید، نسخهی ۵ را پیدا میکنید، دوباره منتشرش میکنید. همان دکمه، اثر قدیمیتر، آدرس زنده فوراً برمیگردد. بعد نسخهی ۶ را بدون هیچ فشاری تعمیر میکنید، چون پروداکشن در حین کار شما خراب نیست. هزینهی این، یک کلیک اضافه در هر انتشار است، چون باید یادتان باشد واقعاً منتشر کنید نه اینکه فرض کنید ویرایشی خودکار بیرون رفته. این را با ابزارهایی مقایسه کنید که هر ذخیرهای زنده است — در یک دمو عالی، سه هفته بعد از استفادهی واقعی سخت — و آن کلیک اضافه هر بار معاملهای است که ارزش انجام دادن دارد.
لغو انتشار یعنی آدرس دیگر باز نمیشود، نه «دیگر لیست نیست»
بسیاری از پلتفرمها «لغو انتشار» را به این معنا میگیرند که آن را از صفحهی گالری پنهان کن در حالی که آدرس همچنان بیسروصدا سرو میشود. اینجا یعنی آدرس کاملاً خاموش میشود، تمام — نه صفحهی کششده، نه جایگزین، هیچ چیز باز نمیشود. خود ساخت با همهی نسخههایش دستنخورده باقی میماند؛ بعداً دوباره منتشر کنید همان اسلاگ درست همانجایی که رهایش کرده بودید برمیگردد. من این را برای دلیلی پیشپاافتاده استفاده کردهام (همکاری با یک کارفرما تمام شد، کسی نمیخواهد لوگوی قدیمیاش در یک لینک عمومی شناور بماند) و برای یکی کمتر پیشپاافتاده (ساختی چیزی را که نباید فاش میکرد، فاش کرد، و لازم بود در همان زمانی که طول میکشد یک دکمه را کلیک کنید آفلاین شود، نه در زمانی که طول میکشد با یک ارائهدهندهی میزبانی تیکت باز کنید). هر دو موقعیت همان تضمین را میخواهند، و هر دو آن را میگیرند.
یک نکتهی دیگر که ارزش دارد با هم قاطی نشود: انتشار، آدرسی را برای هرکسی که لینک را دارد زنده میکند؛ اینکه آیا قابلکشف است — بهطور عمومی لیست شده، گاهی در Showcase نمایش داده میشود — کاملاً یک سوییچ جداست. بسیاری از سایتهای منتشرشدهی مشروع باید برای همیشه فقط با لینک بمانند، و ساختی که وارد لیست عمومی میشود، همچنان زیر آن یک سایت منتشرشدهی معمولی است، با همان تاریخچه و همان دکمهی لغو انتشار.
