ساخت سایت ثبت‌نام رویداد با هوش مصنوعی؛ ظرفیت تا فهرست شرکت‌کنندگان

لینک کارگاه را منتشر کرده‌ای. دو نفر هم‌زمان می‌خواهند آخرین صندلی را بگیرند؛ یک نفر هم چون پاسخی ندیده، فرم را دوباره می‌فرستد. اگر سایت فقط یک پیام «ثبت‌نام موفق» نشان بدهد، هنوز معلوم نیست چند نفر واقعاً ثبت شده‌اند و آیا برای همه جا وجود دارد یا نه.

برای ساخت سایت ثبت‌نام رویداد با هوش مصنوعی، یک مسیر کامل تعریف کن: معرفی روشن رویداد، فرم کوتاه، ثبت در سرور، جلوگیری از تکرار، کنترل ظرفیت و فهرست خصوصی برگزارکننده. پیش از معرفی سامانه به‌عنوان آماده، ثبت‌نام‌های هم‌زمان را هم بررسی کن؛ عدد ظرفیت روی صفحه به‌تنهایی کافی نیست. این راهنما مسیر یک کارگاه رایگانِ سه‌نفره را با دادهٔ ساختگی دنبال می‌کند.

چهار تصویر مقاله از HTMLهای ارسالی، داخل قاب روشن نمایشی کُندا تهیه شده‌اند؛ چیدمان و سبک طرح‌ها حفظ شده‌اند و اطلاعات تماس با مثال‌های ساختگی جایگزین شده است. نام دانشگاه، مدرک، پرداخت، پیامک، آمار و تضمین‌های نوشته‌شده داخل طرح‌ها تأیید نشده‌اند و بیانگر امکانات آمادهٔ کُندا یا یک رویداد واقعی نیستند. آزمون‌های این مقاله جداگانه، روی سرور مستقل محلی در ۸ آبان ۱۴۰۵ انجام شده‌اند؛ اجرای موتور کُندا نیستند.

اول مشخص کن ثبت‌نام در این رویداد چه معنایی دارد

این نمونه برای مدرس یا تیم کوچکی است که یک کارگاه محدود برگزار می‌کند و می‌خواهد ثبت‌نام‌ها میان پیام‌ها و فایل‌های پراکنده گم نشوند. نسخهٔ اول یک رویداد رایگان، یک نوع پذیرش و یک ظرفیت مشترک دارد؛ هر ثبت‌نام پذیرفته‌شده یک صندلی مصرف می‌کند.

اگر بلیت حضوری و آنلاین یا سهمیهٔ VIP داری، باید روشن کنی کدام ظرفیت را مصرف می‌کنند. ثبت گروهی هم با چند ثبت مستقل یک‌نفره یک مسئله نیست. آن‌ها را به نسخهٔ بعد بسپار؛ برای محدود کردن همین شروع، راهنمای ساخت MVP با هوش مصنوعی کمک می‌کند.

صفحهٔ معرفی قبل از فرم چه بگوید؟

مخاطب باید پیش از ثبت‌نام بداند چه چیزی یاد می‌گیرد، پیش‌نیاز چیست، رویداد کِی و کجا برگزار می‌شود و چه اقدامی لازم است. تاریخ کامل، ساعت و منطقهٔ زمانی را روشن بنویس؛ مثلاً ساعت را صریحاً به وقت تهران معرفی کن. نام مدرس، محل و مدرک را فقط با اطلاعات قابل تأیید خودت منتشر کن.

اقدام اصلی را مشخص نگه دار: «ثبت‌نام در کارگاه». اگر پذیرش بسته است، همان‌جا توضیح بده و مخاطب را به یک فرم ظاهراً باز نفرست. در صفحهٔ عمومی می‌توان شمار صندلی‌های باقی‌مانده را نشان داد، اما این عدد ممکن است تا رسیدن درخواست بعدی تغییر کند؛ تصمیم نهایی باید هنگام ثبت در سرور گرفته شود.

اگر هنوز در مرحلهٔ چیدن صفحات هستی، راهنمای ساخت سایت با هوش مصنوعی مسیر معرفی، اقدام اصلی و بررسی فرم را توضیح می‌دهد.

پرامپت ساخت سایت رویداد را چطور بنویسیم؟

به‌جای «یک سامانهٔ جامع رزرو بساز»، قواعد همین مسیر را بنویس. ابزار سازنده باید بداند چه چیزی پذیرفته شود و چه چیزی رد شود؛ یک ظاهر شبیه سایت فروش بلیت، جواب این سؤال‌ها نیست.

یک سایت فارسی و راست‌به‌چپ برای کارگاه رایگان نمونه با ظرفیت ۳ نفر بساز. معرفی، فرم نام نمایشی و ایمیل، رسید ثبت و فهرست خصوصی برگزارکننده داشته باشد. هر ایمیل در همان رویداد فقط یک ثبت پذیرفته‌شده داشته باشد؛ این قاعده تأیید هویت نیست. هر ارسال شناسهٔ یکتا داشته باشد؛ تکرار همان درخواست رکورد تازه نسازد. ظرفیت در سرور و هنگام ذخیره بررسی شود؛ در ارسال هم‌زمان سقف رد نشود. حالت خالی، خطای ورودی، ثبت تکراری و ظرفیت پر روشن باشند. ذخیره و بازخوانی پس از رفرش را بررسی کن. از دادهٔ ساختگی استفاده کن. پرداخت، پیامک، کدملی و لیست انتظار نداریم؛ بخش متصل‌نشده را دمو معرفی کن.

نام، زمان و ظرفیت واقعی خودت را پیش از ساخت جایگزین کن. می‌توانی این درخواست را در داشبورد کُندا بازبینی کنی یا قالب‌های آماده را ببینی. برای آشنایی با مسیر درخواست و اصلاح، آموزش وایب کدینگ هم در دسترس است.

فرم کوتاه باشد؛ موفقیت بعد از ذخیره نمایش داده شود

برای کارگاه رایگان نمونه، نام نمایشی و ایمیل کافی است. کدملی، رشتهٔ تحصیلی و شماره تماس را صرفاً به‌خاطر وجودشان در یک طرح آماده اجباری نکن. اگر برای رویداد واقعی اطلاعات بیشتری لازم داری، دلیل و کاربرد هر فیلد را مشخص کن.

پس از ارسال معتبر و تأیید ذخیره در سرور، یک شناسهٔ پیگیری نشان بده. پیام باید روشن کند چه اتفاقی افتاده است: «ثبت‌نامت ثبت شد» با «ایمیل تأیید ارسال شد» فرق دارد. در نمونهٔ محلی، ثبت ذخیره می‌شود و رسید قابل خواندن است؛ هیچ ایمیل یا پیامکی ارسال نمی‌شود و اعتبار ایمیل هم از طریق دریافت پیام تأیید نشده است.

نام خالی یا بیش از حد طولانی و ایمیل با قالب نادرست در آزمون رد شدند. در رابط خروجی خودت بررسی کن که هنگام خطا، اطلاعات نوشته‌شده پاک نشوند و پیام کنار فیلد بگوید چه چیزی را اصلاح کنی. رفتار حفظ فرم در قطع ارتباط، نیازمند آزمون جداگانه است؛ تست سرور آن را به‌جای تو تأیید نمی‌کند.

ثبت تکراری دو حالت متفاوت دارد

حالت اول این است که همان درخواست به دلیل دوبار زدن دکمه یا تلاش مجدد شبکه ارسال شود. برای همان ارسال، شناسهٔ ثابت نگه دار تا سرور ثبت قبلی را تشخیص بدهد. در تمرین، تکرار درخواست الف همان رسید قبلی را برگرداند و صندلی دیگری مصرف نکرد. تغییر اطلاعات با همان شناسه نیز به‌عنوان تعارض رد شد.

حالت دوم این است که فرد دوباره فرم را با یک شناسهٔ تازه پر کند. در این نمونه، یکتایی ایمیل در همان رویداد از مصرف صندلی دوم جلوگیری می‌کند. ابتدا فاصلهٔ ابتدا و انتهای ایمیل حذف و حروف لاتین همسان می‌شوند؛ برای نمونه، ورود دوبارهٔ همان آدرس با حروف بزرگ باعث ثبت تازه نشد. همان ایمیل در رویداد دیگری مجاز بود.

این یک قاعدهٔ ثبت است، نه تضمین «هر انسان فقط یک بار». کسی با ایمیل متفاوت از همین قاعده عبور می‌کند و ایمیلِ صرفاً واردشده هم هویت صاحبش را تأیید نمی‌کند. اگر نیاز به حساب تأییدشده یا سهمیهٔ واقعی افراد داری، آن را جداگانه طراحی و بررسی کن. نمایش تیک سبز کنار فیلد کدملی در یک طرح نیز به معنی اتصال به مرجع بررسی هویت نیست.

برای جلوگیری از رکوردهای تکراری، قاعده باید در ذخیره‌سازی هم وجود داشته باشد. در تمرین از محدودیت یکتایی استفاده شد؛ مرجع قواعد جدول SQLite توضیح فنی این بخش را دارد.

وقتی ظرفیت پر شد چه چیزی ببینیم؟

در مسیر اصلی، سه صندلی داریم. هر ثبت پذیرفته‌شده شمار را یک واحد افزایش می‌دهد؛ خطا یا تلاش تکراری نباید آن را تغییر بدهد.

در حالت پر، پیام «ظرفیت تکمیل است» نشان بده و توضیح بده ثبت تازه‌ای انجام نشده است. اگر لیست انتظار متصل نیست، وعدهٔ «نامت در صف قرار گرفت» نده. همچنین اگر درخواست قبلی واقعاً ثبت شده، تلاش مجدد همان درخواست باید بتواند وضعیت قبلی را پیدا کند؛ در تمرین، دریافت دوبارهٔ همان رسید حتی پس از پر شدن ظرفیت ممکن بود.

پذیرش بسته با ظرفیت پر یکی نیست. در یک آزمون جدا، رویدادی با صندلی خالی ولی پذیرش بسته، ثبت تازه را رد کرد. مهلت ثبت‌نام، ظرفیت و وضعیت انتشار را در خروجی واقعی جدا بررسی کن. فایل مسیر ظرفیت نمونه برای تکرار این بررسی آماده است.

آزمون هم‌زمانی: دو نفر برای آخرین صندلی

اگر دو درخواست هم‌زمان، هر دو «یک صندلی باقی مانده» را بخوانند، ممکن است هر دو پیام موفقیت بگیرند؛ مگر اینکه بررسی ظرفیت و ثبت با هم هماهنگ باشند. غیرفعال کردن دکمه در یک مرورگر، درخواست مرورگر دیگر را متوقف نمی‌کند.

در آزمایش مستقل محلی، این حالت‌ها را بررسی کردیم:

برای آزمایش ده درخواست، شروع کلاینت‌ها با یک مانع مشترک هماهنگ شد؛ شمار ذخیره‌شده نیز بعد از پاسخ‌ها دوباره خوانده شد. در نمونه، بررسی و نوشتن در یک تراکنش محلی انجام شدند. مستندات تراکنش SQLite مرجع فنی این سازوکار است.

این نتیجه، آزمون محدود روی یک رایانه و پایگاه دادهٔ محلی است؛ آمادگی انتشار یک خروجی تازه، کارکرد زیر بار واقعی یا هماهنگی چند سرور را تأیید نمی‌کند. اگر نسخهٔ واقعی از پایگاه داده یا مسیر ثبت دیگری استفاده می‌کند، همین رقابت را روی همان نسخه دوباره اجرا کن. عبارت «آمادهٔ ثبت‌نام» را فقط از روی ظاهر صفحه یا نتیجهٔ شبیه‌ساز HTML ننویس.

فهرست شرکت‌کنندگان برای چه کسی است؟

برگزارکننده باید بتواند ثبت‌ها را ببیند و شمارشان را با ظرفیت مصرف‌شده تطبیق بدهد. مخاطب عمومی معمولاً به نام، ایمیل یا اطلاعات تماس دیگر شرکت‌کنندگان نیاز ندارد. شمار باقی‌مانده را می‌توان جدا از فهرست خصوصی نمایش داد.

در آزمون، فهرست سه ثبت فقط با دسترسی آزمایشی برگزارکننده خوانده شد؛ درخواست بدون آن مجوز رد شد. اطلاعات عمومی رویداد شامل شمار بود و نام یا ایمیل افراد را برنمی‌گرداند. حدس زدن یک شمارهٔ رسید هم اطلاعات ثبت‌نام را نمایش نداد. رسید نمونه با یک نشانی تصادفی اختصاصی خوانده می‌شود؛ این شیوه جای حساب کاربری یا بررسی امنیت عمومی را نمی‌گیرد.

مجوز را در سمت سرور بررسی کن، نه فقط با پنهان کردن لینک پنل. راهنمای مجوزدهی OWASP بر بررسی دسترسی در هر درخواست تأکید دارد؛ چک‌لیست دسترسی وب‌اپ هم برای بررسی خروجی خودت مفید است. اگر بعداً خروجی CSV اضافه می‌کنی، همان فایل نیز باید دسترسی مشخص داشته باشد؛ خروجی فهرست در این نمونه پیاده نشده است.

بعد از رفرش، ثبت‌نام قبلی گم نشود

صفحهٔ بازخوانی آزمایشی را در مرورگر دوباره بارگذاری کردیم: پیش و پس از رفرش، شمار ثبت‌شده ۳ و ظرفیت باقی‌مانده صفر بود. فهرست مجاز برگزارکننده نیز جداگانه سه رکورد نشان داد.

این بررسی مربوط به دادهٔ ذخیره‌شده است؛ بازیابی فرم نیمه‌کاره یا پیدا کردن رسید توسط کاربری که صفحه را پیش از دریافت پاسخ بسته، در این تمرین پیاده نشده است. در محصول واقعی، این مسیر را جدا بررسی کن و قبل از ساخت یک درخواست تازه، وضعیت ارسال قبلی را پیدا کن. ذخیره شدن در حافظهٔ صفحه یا تنها یک مرورگر را هم با ثبت‌نام مشترکِ سروری یکی ندان؛ راهنمای پیش‌نمایش و محصول آماده این مرز را توضیح می‌دهد.

قبل از انتشار چه چیزهایی باید روشن باشد؟

۲۶ بررسی API محلی و یک بازخوانی در مرورگر انجام شد. نتیجه‌های بالا مربوط به همین نمونه‌اند؛ آن‌ها را به خروجی تازهٔ خودت تعمیم نده. برگهٔ معیار پذیرش را برای مسیر واقعی خودت با انتظار و مشاهده پر کن.

در این تمرین، پرداخت، تأیید ایمیل، پیامک، لغو و آزادسازی صندلی، لیست انتظار، ثبت گروهی، کنترل سوءاستفاده و پشتیبان‌گیری بررسی نشده‌اند. اگر رویدادت پولی است، وضعیت پرداخت و زمان رزرو صندلی باید طراحی و آزمون جداگانه داشته باشند؛ رسید ثبت این نمونه را رسید پرداخت معرفی نکن.

روی گوشی هم معرفی، تکمیل فرم، خواندن پیام تکرار و حالت پر را بررسی کن. آزمون سرور به‌تنهایی اندازهٔ دکمه، دسترس‌پذیری خطا یا حفظ متن فرم را تأیید نمی‌کند. نام مدرس و مدرک، تاریخ، محل، شرایط حضور و راه تماس واقعی را هم پیش از انتشار بازبینی کن.

قدم بعدی: یک کارگاه، یک ظرفیت و یک معیار پذیرش

ابتدا اطلاعات واقعی رویداد را آماده کن. پرامپت مقاله را برای همان کارگاه در داشبورد کُندا بازبینی کن یا قالب‌های آماده را ببین. ساخت را پس از بررسی درخواست و شرایط حساب شروع کن؛ برای آزمون اولیه از اطلاعات ساختگی استفاده کن.

معیار نسخهٔ اول روشن است: هر ثبت پذیرفته‌شده یک صندلی، هر تکرار همان درخواست بدون صندلی اضافه، و مجموع ثبت‌ها حداکثر برابر ظرفیت باشد. وقتی این مسیر روی خروجی واقعی گذشت، دربارهٔ قابلیت بعدی تصمیم بگیر؛ یک فرم زیبا را زودتر از موعد به سامانهٔ آمادهٔ پذیرش عمومی تبدیل نکن.