Applytide

המעקב הוא העבודה

כל מי שמנהל חיפוש עבודה רציני מפעיל צינור: איתור, סינון, הגשה, מעקב, ראיון, החלטה. יש לו שלבים, שיעורי המרה, וזמן מחזור. זה תהליך, ואנשים מריצים אותו בגיליון אלקטרוני או בראש.

החיכוך הוא לא במציאת משרות. הוא בהנהלת החשבונות סביבן — איזו גרסה של קורות החיים הלכה לאן, מה כתבת במכתב המקדים, מתי הבטחת לחזור, ואילו הגשות עדיין חיות. העבודה הזו משעממת, בתדירות גבוהה, ובדיוק בשביל זה יש תוכנה.

מה שטעיתי בו בהתחלה: הנחתי שהשלב הכואב הוא כתיבת ההגשות. הוא לא. השלב הכואב היה הקליטה — להוציא משרה מטאב בדפדפן ולהכניס אותה לרשומה מובנית לפני שהטאב נסגר. כל מה שבהמשך תלוי בכך שהרגע הבודד הזה יהיה נטול חיכוך.

אילוצים שבאמת תחמו את העיצוב

שני אילוצים אמיתיים עיצבו כמעט כל החלטה. הראשון היה עלות: לכל פיצ׳ר שקורא למודל שפה מוצמד חשבון בלתי חסום, ופרויקט אישי לא יכול לספוג את זה. השני היה אמון: המערכת הזו מחזיקה את קורות החיים של המשתמש, את היסטוריית ההעסקה שלו, ורשימה של כל חברה שהוא מדבר איתה בשקט. זה מאגר קטן עם רדיוס נזק גבוה מאוד.

לכן אבטחה ובקרת עלויות לא היו פיצ׳רים להוסיף אחר כך — הן היו אילוצי מסגור. בגלל זה הבנייה כוללת דברים שפרויקט צד בדרך כלל מדלג עליהם: סשנים בעוגיות HttpOnly במקום טוקנים ב־localStorage, אימות דו־שלבי מבוסס TOTP, מעקב סשנים ניתן לביטול, הגבלות קצב לכל נקודת קצה, ותקרת הוצאה יומית קשיחה לקריאות בינה מלאכותית שנאכפת ב־Redis.

מחוץ להיקף במפורש: הגשה אוטומטית. הוצאתי אותה מההיקף משום שהגשה המונית ממטבת את נפח ההגשות ומגבירה את הרעש בתהליך החיפוש.

קליטה קודם, כי הכול תלוי בה

מכיוון שהקליטה הייתה השלב הנושא, תוסף הדפדפן נבנה מוקדם ולא כתוספת. להכניס משרה למערכת בלחיצה אחת זה ההבדל בין כלי שמישהו משתמש בו לכלי שמישהו מתכוון להשתמש בו.

השאר תוזמן לאורך הצינור עצמו: קליטה, אחר כך שלבי הקנבן שממדלים את התהליך, אחר כך מסמכים, ואז שכבות התזכורות והאנליטיקה שהופכות משמעותיות רק כשיש היסטוריה להסיק ממנה. אנליטיקה אחרונה זו בחירה מכוונת — דשבורד מעל שלוש רשומות הוא קישוט.

הארכיטקטורה תוכננה כשירותים נפרדים מלכתחילה במקומות שבהם הגבולות היו באמת שונים: רינדור מייל HTML הוא עניין של Node, תזמון רקע הוא לא עניין של ה־API, והפרוקסי ההפוך הוא המקום שאליו שייכת הגבלת הקצב.

שמונה רשומות Compose, לפי הגדרת ספירה

בקומיט הציבורי שנבדק, Docker Compose מכיל שמונה רשומות שירות, כולל MailDev שמיועד לפיתוח. הטופולוגיה כוללת גם Nginx, אפליקציית React, שרת FastAPI, שירות מיילים ב־Node, PostgreSQL, Redis ותהליך מתזמן.

השרת בנוי בשכבות — 15 הרשמות include_router בגבול ה־API, שכבת דומיין, 19 הצהרות מחלקות מודל SQLAlchemy תחת Alembic, ותשתית למיילים, מודל שפה, אבטחה ועובדי רקע. אלה ספירות של צילום מצב לפי הגדרה מתועדת, לא תוצאות מוצר.

הבעיה הקשה ביותר הייתה חילוץ: להפוך דף משרה שרירותי לשדות מובנים. התשובה הנאיבית היא לשלוח את הדף למודל. התשובה הזו שגויה מסיבות שמפורטות ביומן ההחלטות למטה.

השנייה בקושי הייתה בינאום. תמיכה מלאה בעברית פירושה RTL אמיתי — לא גיליון סגנונות משוקף, אלא פריסה שנכונה בשני הכיוונים, כולל שדות קלט, גרפים, וגרירה ושחרור. התאמה בדיעבד יקרה, ולכן זה תוכנן פנימה ולא הוברג מבחוץ.

תקציבים, בדיקות תקינות, והדברים שאי אפשר לבדוק ביחידה

חלק מזה היה שגרתי: סכמות Pydantic שמאמתות כל גבול של נקודת קצה, שאילתות פרמטריות לכל אורך הדרך, נקודת קצה לבדיקת תקינות שבודקת גם את Postgres וגם את Redis.

קוד המקור רושם שימוש במודל שפה לכל קריאה, עם ספירת טוקנים וייחוס לחשבון מול תקציב יומי הניתן להגדרה. זהו מנגנון להגבלת הוצאה; ללא ראיות תפעוליות, זו אינה טענה לאמינות בייצור.

ניהול סשנים ניתן לבדיקה באותה רוח: משתמש יכול לראות את הסשנים הפעילים שלו ולבטל אותם. השאלה שמאמתת את זה היא לא ״האם נקודת הקצה מחזירה 200״, אלא ״האם משתמש שאיבד מחשב נייד באמת יכול להתאושש״.

מה הארכיון מוכיח — ומה לא

מאגר Applytide הציבורי מסומן כארכיון. לא מוצגים כאן פריסה חיה או תוצאות משימוש חיצוני.

עצרתי כשהמשך העבודה היה הופך מתיקוף החלטות המוצר וההנדסה לתפעול תשתית, מימון שימוש במודלים ותחזוקת משטח אבטחה.

קוד המקור מדגים באופן עצמאי ארכיטקטורה מרובת שירותים, בקרות סשנים ותקציב, ממשק דו־לשוני והחלטות עיצוב מתועדות. הוא אינו מוכיח לבדו אבטחה בייצור, אמינות או אימוץ.