به کار گذاشتن مدل

از دفترچه تا دنیا

مدل ساعت درس و نمره‌مون رو یادتونه؟ توی دفترچه‌ی شما خوب کار می‌کنه. حالا یه معلم می‌خواد روی گوشیش ساعت درس یه بچه رو بنویسه و نمره‌ی احتمالیش رو ببینه. چطوری؟

دفترچه‌ی کد جای ساختنه، نه جای استفاده. وقتی دفترچه رو می‌بندید، مدل هم باهاش می‌ره. برای اینکه بقیه از مدل استفاده کنن، باید سه تا کار بکنیم: عددهای مدل رو توی یه فایل ذخیره کنیم، یه برنامه بنویسیم که همیشه روشن باشه و این فایل رو بخونه، و یه راه بذاریم که برنامه‌های دیگه، مثل اپ گوشی معلم، سوال بپرسن و جواب بگیرن.

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

ذخیره

مدل ما بعد از آموزش چی بود؟ فقط دو تا عدد: شیب ۱٫۵۲ و عرض از مبدا ۶٫۷۴. پس ذخیره کردن مدل یعنی نوشتن این دو تا عدد توی یه فایل:

import json

model = {"version": "2026-10-01", "w": 1.52, "b": 6.74}
with open("model.json", "w") as f:
    json.dump(model, f)

این‌جا یه دیکشنری ساختیم؛ یه جور جعبه که هر چیزش یه اسم داره، مثل "w" و "b". بعد با json.dump نوشتیمش توی یه فایل. JSON یه قالب سبک و رایج برای نوشتن و جابه‌جا کردن داده‌ست که تقریبا هر زبان و برنامه‌ای می‌تونه بخونه. اون "w" توی open هم یعنی «برای نوشتن باز کن».

یه چیز دیگه هم کنار عددها گذاشتیم: نسخه، که این‌جا تاریخ آموزشه. بعدا می‌بینید چرا این‌قدر مهمه.

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

برنامه‌ی جواب‌دهنده

حالا یه برنامه که همیشه روشن بمونه، فایل مدل رو بخونه، و هر کی سوال فرستاد، جوابش رو بده. این کل کدشه:

import json
from http.server import BaseHTTPRequestHandler, HTTPServer

with open("model.json") as f:
    model = json.load(f)

def predict(hours):
    return model["w"] * hours + model["b"]

class Handler(BaseHTTPRequestHandler):
    def do_POST(self):
        size = int(self.headers["Content-Length"])
        data = json.loads(self.rfile.read(size))
        guess = predict(float(data["hours"]))
        body = json.dumps({"score": round(guess, 1), "version": model["version"]})
        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.end_headers()
        self.wfile.write(body.encode())

HTTPServer(("", 8000), Handler).serve_forever()

از بالا بریم. اول فایل مدل رو با json.load می‌خونیم؛ برعکس کاری که موقع ذخیره کردیم. این کار فقط یه بار، موقع روشن شدن برنامه، انجام می‌شه. بعد تابع predict رو داریم که همون فرمول خطه: شیب ضرب در ساعت، به اضافه‌ی عرض از مبدا.

بعد یه کلاس داریم به اسم Handler. لازم نیست کلاس رو کامل بشناسید؛ همین‌قدر بدونید که هر بار یه سوال از راه اینترنت برسه، تابع do_POST اجرا می‌شه. این تابع پیام رسیده رو می‌خونه، از JSON درش میاره، ساعت رو به predict می‌ده، و جواب رو، باز هم به شکل JSON، همراه اسم نسخه، پس می‌فرسته. خط آخر هم برنامه رو روی درگاه ۸۰۰۰ روشن می‌کنه و تا ابد منتظر سوال می‌مونه.

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

پرسیدن

حالا اپ گوشی معلم یه پیام می‌فرسته به برنامه‌ی ما، و جواب می‌گیره:

سوال یه تیکه JSON کوچیکه: «ساعت: ۴٫۵». جواب هم JSON: «نمره: ۱۳٫۶، نسخه: ۱ اکتبر». اگه ۲ ساعت بفرسته، جواب ۹٫۸ میاد. همین. ما این برنامه رو واقعا اجرا کردیم و این‌ها جواب‌های خودشه.

به این قرار سوال و جواب بین دو تا برنامه می‌گن API. قشنگیش اینه که اپ معلم هیچی درباره‌ی مدل نمی‌دونه: نه می‌دونه خطه، نه می‌دونه شبکه‌ی عصبیه، نه اصلا با چه زبانی نوشته شده. فقط می‌دونه به کدوم آدرس، چه شکلی سوال بفرسته و چه شکلی جواب بگیره. فردا اگه مدل رو با یه مدل خیلی بهتر عوض کنیم، اپ معلم هیچ تغییری لازم نداره.

اگه می‌خواید بیشتر بدونید API و JSON توی دنیای شبکه چطوری کار می‌کنن، درس API، REST و JSON مفصل توضیحش داده.

شبانه یا لحظه‌ای

همیشه لازم نیست مدل لحظه‌ای جواب بده. دو جور به کار گذاشتن داریم:

توی حالت شبانه، مدل هر شب یه‌جا برای همه جواب حساب می‌کنه و جواب‌ها رو توی یه فهرست می‌ذاره. مثل نونوایی درس قبل: لازم نیست کسی وسط روز بپرسه، فقط هر شب یه عدد برای فردا لازمه. این ساده‌تره، ارزون‌تره، و اگه یه شب طول کشید، هیچ‌کس منتظر نمی‌مونه.

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

سوالی که باید از خودتون بپرسید: جواب رو کی لازم داریم؟ اگه می‌شه از قبل حساب کرد، حالت شبانه. اگه نه، لحظه‌ای.

حالت شبانه، با کد

حالت شبانه حتی از این هم ساده‌تره؛ اصلا سرور لازم نداره. یه برنامه که هر شب یه بار اجرا می‌شه، مدل رو می‌خونه، برای همه حدس می‌زنه و جواب‌ها رو توی یه فایل می‌نویسه. با چهار دانش‌آموز ساختگی:

import csv, json

with open("model.json") as f:
    model = json.load(f)

students = [("Sara", 4.5), ("Ali", 2), ("Mina", 7), ("Reza", 9)]
with open("tomorrow.csv", "w", newline="") as f:
    out = csv.writer(f)
    out.writerow(["name", "hours", "score", "version"])
    for name, hours in students:
        guess = max(0, min(20, model["w"] * hours + model["b"]))
        out.writerow([name, hours, round(guess, 1), model["version"]])
print(open("tomorrow.csv").read())

name,hours,score,version
Sara,4.5,13.6,2026-10-01
Ali,2,9.8,2026-10-01
Mina,7,17.4,2026-10-01
Reza,9,20,2026-10-01

اپ معلم صبح فقط این فایل رو می‌خونه. اگه برنامه‌ی شبانه یه شب خراب شد، فایل دیروز هنوز سر جاشه و کسی بی‌جواب نمی‌مونه؛ فقط یه روز کهنه‌تره. ببینید نمره‌ی رضا، با ۹ ساعت، ۲۰ شده نه ۲۰٫۴؛ همون محدود کردنی که توی پروژه‌ی اول گذاشتیم، این‌جا هم هست. و نسخه‌ی مدل کنار هر ردیف نوشته شده، تا اگه یه روز سوالی پیش اومد، بدونید کدوم مدل این عدد رو داده.

همون آماده‌سازی

حالا مهم‌ترین دام این مرحله. فرض کنید برنامه‌نویس اپ معلم فکر کرده مدل زمان رو به دقیقه می‌خواد:

مدل با ساعت آموزش دیده. اپ برای چهار ساعت و نیم، ۲۷۰ دقیقه می‌فرسته. مدل که نمی‌دونه این عدد دقیقه‌ست؛ فقط ضربش می‌کنه در ۱٫۵۲ و ۶٫۷۴ اضافه می‌کنه. جواب: ۴۱۷٫۱. نمره از بیست!

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

قانونش ساده‌ست: هر کاری که موقع آموزش روی داده کردید، دقیقا همون کار، با همون کد، باید موقع جواب دادن هم انجام بشه. بهترین راهش اینه که آماده‌سازی رو یه تابع کنید و هم توی آموزش و هم توی برنامه‌ی جواب‌دهنده از همون یه تابع استفاده کنید، نه اینکه دو بار بنویسیدش.

یه نگهبان دم در

اون ۲۷۰ دقیقه رو چطوری بگیریم؟ ساده‌ترین راه اینه که قبل از اینکه سوال به مدل برسه، یه نگهبان نگاهش کنه. ما برای ساعت درس سه تا قانون گذاشتیم: باید باشه، باید عدد باشه، و باید بین صفر و ۱۶ باشه؛ چون کسی توی یه روز بیشتر از ۱۶ ساعت درس نمی‌خونه:

def check(data):
    if "hours" not in data:
        return "hours is missing"
    h = data["hours"]
    if not isinstance(h, (int, float)) or isinstance(h, bool):
        return "hours must be a number"
    if not 0 <= h <= 16:
        return "hours must be between 0 and 16"
    return None

این تابع اگه همه‌چی درست باشه، هیچی برنمی‌گردونه؛ وگرنه یه جمله که می‌گه چی غلطه. توی برنامه، اگه جمله‌ای برگشت، به‌جای جواب مدل، کد ۴۰۰ برمی‌گردونیم، که توی قرارهای وب یعنی «سوالت ایراد داره»، و دلیلش رو هم می‌گیم. این‌ها جواب‌های واقعی برنامه‌ی ما بودن:

{"hours": 4.5}     -> 200 {"score": 13.6, "version": "2026-10-01"}
{"hours": 270}     -> 400 {"error": "hours must be between 0 and 16"}
{"hours": "four"}  -> 400 {"error": "hours must be a number"}
{"hour": 4}        -> 400 {"error": "hours is missing"}
hello              -> 400 {"error": "not JSON"}

حالا اون برنامه‌نویسی که دقیقه فرستاده بود، به‌جای یه نمره‌ی ۴۱۷، یه پیام روشن می‌گیره و همون روز اول اشتباهش رو پیدا می‌کنه. یه نکته‌ی ظریف هم توی کد هست: توی پایتون، True و False هم یه جور عددن، پس جدا ردشون کردیم. و جواب مدل رو هم بین صفر و ۲۰ نگه داشتیم؛ نگهبان فقط دم در نیست، دم خروجی هم هست.

یادداشت و حال‌پرسی

برنامه‌ی تازه دو تا چیز دیگه هم داره. اول، هر جوابی که می‌ده، یه خط توی یه فایل یادداشت می‌کنه؛ زمان، ورودی، جواب و نسخه:

    def do_POST(self):
        size = int(self.headers["Content-Length"])
        try:
            data = json.loads(self.rfile.read(size))
        except ValueError:
            return self.reply(400, {"error": "not JSON"})
        problem = check(data)
        if problem:
            return self.reply(400, {"error": problem})
        guess = max(0, min(20, model["w"] * data["hours"] + model["b"]))
        with open("log.jsonl", "a") as log:
            log.write(json.dumps({"t": round(time.time()), "hours": data["hours"],
                                  "score": round(guess, 1), "version": model["version"]}) + "\n")
        self.reply(200, {"score": round(guess, 1), "version": model["version"]})

{"t": 1791742681, "hours": 4.5, "score": 13.6, "version": "2026-10-01"}
{"t": 1791742681, "hours": 4.5, "score": 13.6, "version": "2026-10-01"}

هر خط یه JSON جداست، که خوندن و جمع زدنش بعدا خیلی راحته. بعد از دو بار امتحان با هزار سوال، ۲۰۰۲ خط داشتیم. این فایل بعدا طلاست: وقتی نمره‌های واقعی دانش‌آموزها اومد، می‌شه کنار حدس‌های مدل گذاشت و دید مدل هنوز خوبه یا نه؛ همون کاری که درس بعد بهش می‌رسیم.

دوم، یه نشونی کوچیک به اسم /health که فقط می‌گه «زنده‌م» و کدوم نسخه رو داره:{"ok": true, "version": "2026-10-01"}. یه برنامه‌ی دیگه هر چند ثانیه این نشونی رو می‌پرسه، و اگه جواب نیومد، به یکی خبر می‌ده یا برنامه رو دوباره روشن می‌کنه. این‌جوری خرابی رو شما زودتر از معلم‌ها می‌فهمید.

یه بار بخون، هزار بار جواب بده

توی برنامه، فایل مدل رو یه بار، اول کار، خوندیم. اگه برای هر سوال دوباره از فایل می‌خوندیم چی؟ ده هزار جواب رو هر دو جور حساب کردیم:

وقتی مدل یه بار خونده شده بود، ده هزار جواب ۰٫۵۶ میلی‌ثانیه طول کشید. وقتی هر بار از فایل خوندیم، ۱۳۲٫۲ میلی‌ثانیه؛ حدود ۲۳۵ برابر کندتر. و این برای مدلیه که فقط دو تا عدده. یه مدل واقعی که چند صد مگابایت یا چند گیگابایته، خوندنش از دیسک چند ثانیه طول می‌کشه؛ اگه برای هر سوال این کار رو بکنید، هر جواب چند ثانیه می‌شه. پس قانون اینه: مدل رو یه بار، موقع روشن شدن برنامه، بخونید و توی حافظه نگه دارید.

کل برنامه‌ی ما، با فرستادن و گرفتن از راه وب، هزار سوال رو روی همون کامپیوتر توی ۰٫۱۴ ثانیه جواب داد. وقتی سوال از اون سر اینترنت میاد، بیشتر وقت توی راه می‌گذره، نه توی مدل. برای مدل‌های بزرگ‌تر، داستان برعکسه و خود مدل کند می‌شه؛ اون‌جاست که ترفندهایی مثل جواب دادن به چند سوال با هم، یا GPU، به کار میاد.

نسخه و برگشت

مدل یه بار ساخته نمی‌شه و تموم. هر چند وقت یه بار با داده‌ی تازه دوباره آموزش می‌بینه. اگه نسخه‌ی تازه بدتر بود چی؟

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

اسم نسخه توی هر جواب هم به درد می‌خوره. اگه یه روز معلمی گفت «دیروز یه جواب عجیب گرفتم»، با اسم نسخه می‌دونید کدوم مدل اون جواب رو داده. برای همین خوبه برنامه هر سوال و جوابش رو، با نسخه و زمان، یه جا یادداشت کنه.

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

همون محیط، همه‌جا

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

راهش اینه که کنار فایل مدل، یه فایل کوچیک هم نگه دارید که نسخه‌ی دقیق پایتون و هر کتابخونه‌ای که استفاده کردید رو می‌گه، و سرور رو دقیقا با همون‌ها بسازید. یه قدم جلوتر، خیلی‌ها کل برنامه رو با همه‌ی نیازهاش، از خود پایتون تا فایل مدل، توی یه بسته‌ی جدا می‌ذارن که هر جا اجرا بشه، دقیقا همون‌جوری باشه. این همون «هر پیش‌بینی رو بشه دوباره ساخت»ه که توی بخش برگشت دیدیم.

چقدر طول می‌کشه؟

برای حالت لحظه‌ای، سرعت جواب مهمه، و یه نکته‌ی ظریف داره. دو هزار سوال به برنامه‌مون فرستادیم و زمان هر کدوم رو جدا اندازه گرفتیم:

import time, urllib.request
times = []
for _ in range(2000):
    req = urllib.request.Request("http://127.0.0.1:8765/", data=b'{"hours": 4.5}',
                                 headers={"Content-Type": "application/json"})
    t = time.perf_counter()
    urllib.request.urlopen(req).read()
    times.append((time.perf_counter() - t) * 1000)
times.sort()
for p in (50, 95, 99):
    print(f"p{p}: {times[int(len(times) * p / 100) - 1]:.2f} ms")
print(f"slowest: {times[-1]:.2f} ms")

p50: 0.12 ms
p95: 0.17 ms
p99: 0.20 ms
slowest: 8.16 ms

صدک ۵۰ یعنی نصف سوال‌ها زودتر از این جواب گرفتن: ۰٫۱۲ میلی‌ثانیه. صدک ۹۵ یعنی ۹۵ درصد زودتر از ۰٫۱۷. صدک ۹۹، ۰٫۲۰. ولی کندترین سوال ۸٫۱۶ میلی‌ثانیه طول کشید؛ بیش از ۶۰ برابر میانه. یه بار دیگه هم اجرا کردیم و عددها تقریبا همین بودن. این کندی‌های گاه‌به‌گاه کار سیستم‌عامل و چیزهای دیگه‌ی کامپیوتره، نه مدل.

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

نسخه‌ی تازه، آروم آروم

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

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

از کجا بفهمید وقتشه سهم نسخه‌ی تازه رو بیشتر کنید؟ از همون یادداشت‌ها و همون اندازه‌ها. چند تا سوال با جواب ۴۰۰ برگشته؟ صدک ۹۹ زمان جواب بالا رفته؟ جواب‌ها عجیب‌تر شدن، مثلا میانگین نمره‌ها یهو یه نمره بالا یا پایین رفته؟ و وقتی نمره‌های واقعی رسید، اشتباه نسخه‌ی تازه از قبلی کمتره؟ اگه جواب همه‌ی این‌ها خوب بود، یه پله جلو برید؛ وگرنه، همون ۵ درصد رو هم به نسخه‌ی قبلی برگردونید و دنبال دلیلش بگردید.

امن نگهش دارید

برنامه‌ای که ساختیم برای یاد گرفتنه، نه برای اینترنت واقعی؛ خود مستندات پایتون هم می‌گه این سرور ساده فقط بررسی‌های امنیتی پایه رو داره. اگه قراره روی اینترنت باشه، چند تا چیز لازمه. اندازه‌ی ورودی رو محدود کنید؛ برنامه‌ی ما هر اندازه‌ای که توی Content-Length نوشته شده باشه رو می‌خونه، و یه نفر می‌تونه یه سوال چند گیگابایتی بفرسته. یه کلید دسترسی بذارید که فقط اپ معلم‌ها داشته باشه، و این کلید رو هیچ‌وقت توی کد یا یادداشت‌ها ننویسید. تعداد سوال هر نفر توی هر دقیقه رو محدود کنید، تا یه نفر نتونه با میلیون‌ها سوال برنامه رو از کار بندازه. و همه‌چی رو از راه HTTPS بفرستید.

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

چند نکته

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

اشتباه‌های رایج

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

از کجا اومد

ابزارهایی که امروز برای به کار گذاشتن مدل استفاده می‌شه، بیشترش از دنیای وب اومده:

روی فیلدینگ سال ۲۰۰۰ توی رساله‌ی دکتریش روش REST رو برای ساختن API روی وب نوشت. داگلاس کراکفورد اوایل دهه‌ی ۲۰۰۰ JSON رو معرفی کرد، که امروز زبان مشترک تقریبا همه‌ی APIهاست. سال ۲۰۱۵ دیوید اسکالی و همکارهاش نشون دادن نگه داشتن مدل توی کار واقعی چقدر سخته، و سال ۲۰۱۹ کارت مدل برای نوشتن اینکه هر مدل برای چیه پیشنهاد شد.

مدل حالا توی دنیای واقعیه. ولی دنیای واقعی ثابت نمی‌مونه؛ درس بعد می‌گه چرا مدلی که امروز خوبه، شش ماه بعد شاید دیگه خوب نباشه: کهنه شدن مدل.