فعال در مهندسی نرم‌افزار با اندکی تجربه از صنعت (عمدتا گوگل) و آکادمی (عمدتا اتلاف عمر).
علاقمندم آموخته‌هامون رو رد و بدل کنیم.
kian1024.contact@gmail.com
Feb 8 • 8 tweets • 2 min read
معمولا دو نام CI و CD (یکپارچه‌سازی پیوسته و استقرار پیوسته) رو با هم می‌شنویم، در حالی که اصلا هم‌ارز نیستن: CI خوبه و همیشه باید داشتش ولی لزوما خوب نیست دنبال CD باشیم. CD یا push on green، یعنی اگر یک نسخه‌ای از کد، همه تست‌های خودکار رو پاس کرد، آماده push به کل سرورهاست.👇
اگر می‌شد مجموعه‌ای از تست‌ها داشت که با خیال راحت این کار رو کرد، خیلی هم عالی، ولی در بسیاری موارد، نمی‌شه. یک دوگانگی ذاتی بین واقع‌گرایانه بودن و deterministic بودن تست‌ها وجود داره: ما یا تستی داریم که مشخصا می‌گیم داده X رو بذار در database و ورودی Y رو به سیستم بده و ...👇
Jun 7, 2023 • 6 tweets • 2 min read
در ادامه‌ی کارآمدیِ سازمانی برای توسعه (!)، کمی هم از QA: در دو شرکتی که بنده قدیم‌ترها کار می‌کردم (خارج از ایران) تیم QA داشتیم و مدلش خیلی ناکارآمد بود. اون مدل رو امروز هم در برخی شرکت‌ها رایج می‌بینم. در عوض در شرکت دیگرم (گوگل) در ۱۰ سال گذشته و میان ده‌ها تیم، هیچ‌جا ...👇
... تیم یا عنوان QA ندیدم، جز یک مورد که خواهم گفت. مسولیت QA («اطمینان از کیفیت») به عهده‌ی خود تیم توسعه‌ست.
اما ... اتفاقا تیم‌هایی هستن با تمرکز بر تست، ولی نه «تست کردن و bug زدن» (شکل سنتی QA) بلکه توسعه ابزار و زیرساخت تست - برای اجرای خودکار در فرایندهای CI و انتشار.👇
Jun 5, 2023 • 6 tweets • 2 min read
این از پرسش‌های من برای جذب برای تیمم بود. برخلاف تصور که یه مساله می‌دیم ببینیم کاندیدا حل می‌کنه یا نه، اتفاقا بهتره کاندیدا «نتونه» مساله رو حل کنه، یا بهتر، مساله دو سه پاسخ داشته باشه از آسون و نابهینه تا سخت و بهینه - تا حالتی که فقط با راهنمایی و تعاملی بشه بهش رسید.👇
این در‌آموزش‌های مصاحبه هم گفته می‌شه ولی خیلی‌ها رعایت نمی‌کنن و مساله‌های booleanی می‌پرسن (طرف یا حل می‌کنه یا حل نمی‌کنه). بانک اطلاعاتی پرسش‌های مصاحبه‌ی گوگل پر بود از پرسش boolean و باید کلی می‌گشتی برای یک مساله‌ی خوب. اون هم خیلی زود ممنوع می‌شد (در اینترنت پخش می‌شد).👇
Jun 4, 2023 • 7 tweets • 2 min read
یک مجموعه S با ۱۰۰ عضو داریم. کمترین تعداد زیرمجموعه ۱۰تایی از S رو بسازید طوری که برای هر جفت دلخواه {i, j} از S، دست کم یکی از زیرمجموعه‌های شما باشه که هر دوی i و j رو داشته باشه.
این از یک مساله databaseی دنیای واقعی می‌آد. اگر در اینستاگرام بنده دیدیدش لطفا خویشتنداری کنید.
مثال: اگر ۱۰تا زیرمجموعه بسازیم {۱ تا ۱۰}، {۱۱ تا ۲۰}، ...، جفت {۳، ۴} و {۱۷، ۱۸} رو پوشش دادیم ولی {۹، ۱۱} رو نه.
راهنمایی (اگر نیازه): فرض کنید به جای ۱۰ گفته بودیم ۵۰.
ادامه: بهینگی الگوریتمتون رو بررسی کنید. (راهنمایی: چند جفت {i, j} با بیش از یک زیرمجموعه پوشش داده می‌شن؟)
Jun 2, 2023 • 9 tweets • 3 min read
یک مدل ناکارآمدِ دیگه در مدیریت پروژه که متاسفانه رایج می‌بینم، اینه که یک «نقش» تعریف شده که به توسعه‌دهنده‌ها تکه کار (مثلا روزانه یا هفتگی) بده و تحویل بگیره. این مدل خودش بده، و بدتر این که این نقش رو هم یک فرد غیر فنی به عهده می‌گیره. مثلا طرف به من می‌گه ما چه‌طوری … (۱/۹)
… اطمینان حاصل کنیم توسعه‌دهنده کارش رو درست جلو می‌بره. می‌گم چرا تو؟ می‌گه پس کی؟! نمی‌دونم این تفکر از کجا اومده. شاید از اون مفهوم کذایی product owner در اسکرام. گویی توسعه‌دهنده‌ها واحدهای تک‌سلولی هستن که فقط حل مساله‌ی فنی بلدن و برای پیشرفتِ کار باید ریزمدیریت بشن. (۲/۹)
Jun 1, 2023 • 4 tweets • 1 min read
در این کارگاه‌ها (توییت زیر) بچه‌ها می‌گفتن در درس «مهندسی نرم‌افزار»، از چرخه‌ی توسعه (مدل مخزن و بازبینی و CI و …) یا تست قناری و غیره، خیلی گفته نمی‌شه، ولی مقدار خوبی «اسکرام» گفته می‌شه - و درباره اسکرامِ ما می‌پرسیدن. متاسفانه از نکات مشترک بین دانشگاه‌ها بود.
پاسخ: (۱/۴)
نه ما و نه هیچ‌یک از ده‌ها تیمی که بنده در این ۱۰ سال در گوگل باهاشون کار مشترک کردم، «اسکرام» کار نمی‌کردن (احتمالا هستن تیم‌هایی که اسکرام کار کنن ولی مرسوم نیست) - و کلا «پکیج» مدیریت پروژه اون‌قدر مهم نیست. شما هم ببینید چی براتون کار می‌کنه. گیرِ این چارچوب‌ها نباشید. (۲/۴)
May 29, 2023 • 4 tweets • 2 min read
یک کارگاه توسعه نرم‌افزار، تدارک دیده و در چند دانشگاه ارائه کردم. عکس‌ها از ارائه‌ی شریفه. نگرانی داشتم که مطالب خیلی به درد دانشجوهای تازه‌کار نخوره ولی خوشبختانه بازخورد خوبی گرفتم و شاید این کارگاه در خارج از دانشگاه و برای مخاطب عام هم برگزار بشه. اگر علاقمندید … (۱/۴)
… شرکت کنید (حضوری) لطفا در این فرم یک ایمیل وارد کنید که اگر تصمیم به برگزاری شد بهتون خبررسانی بشه. docs.google.com/forms/d/e/1FAI…
یک نگاه اجمالی به چرخه‌ی توسعه کردیم، از پیش از کدنویسی تاااا پس از استقرار: فضای فکری و فرهنگیِ همکاری بین تیمی؛ مدل مخزن کد و رویه‌های CI، ...
(۲/۴)
May 7, 2023 • 4 tweets • 1 min read
یکی هم مساله‌ی «مرزهاست» که متاسفانه زیادی پررنگه. مثلا «من مهندس‌ام، در کار محصولی دخالت نمی‌کنم» یا «من PMام، به فنی کاری ندارم». عزیزان، «حوزه مسؤلیت» عالیه، ولی «حوزه استحفاظی» نه. مهندس/PM خوب اونیه که محصول/فنی بفهمه و نظر بده. این هم در نردبانی که در زیر گفتم، هست. (۱/۴)
با این «سیلو»هایی که برای نقش‌ها می‌سازیم، کارها ناکارآم جلو می‌رن (برعکسش و افتادن از اون ورِ بوم هم هست، ولی چیزی که من در شرکت‌های بازار ایران می‌بینم، افتادن از همین ورِ بومه). فقط بحث فنی و محصولی نیست. مثلا بین «مهندس backend» و «مهندس data» و … هم هست (۲/۴)
May 6, 2023 • 7 tweets • 2 min read
یک مساله‌ی فراگیر در بازار فناوری ایران، حوزه‌های به طرز عجیبی «باریک» است که آدم‌ها برای خودشون تعریف می‌کنن؛ مثلا «BI کار»؛ «php کار». این رویکرد به یک سرعت‌گیر برای شرکت‌ها تبدیل شده - و جلوی رشد خود آدم‌ها رو هم می‌گیره و اصلا مفهوم مهندس ارشد (senior) عوض شده. (۱/۷)
متوجه تخصصی شدن کارها و این که همه چیز در «مهندس نرم‌افزار» جا نمی‌شه هستم، ولی بحث افراط در این امره. مهندس نرم‌افزار قراره بتونه SQL query بنویسه و داده تحلیل کنه، گراف بکشه و داشبورد بسازه، release و production بفهمه. نه از پیش، بلکه یعنی هر وقت لازم شد بتونه یاد بگیره. (۲/۷)
May 24, 2021 • 13 tweets • 3 min read
زمینه‌ی کاری «علوم داده» (data science) الان داغه و دوستان می‌پرسن منبع خوب چیه یا از کجا آغاز کنن، که نمی‌دونم. صرفا پرسش رو این‌جا بازتاب می‌دم تا اگر شما پیشنهادی دارید بنویسید بلکه به درد کسی بخوره. لطفا اگر لینک گذاشتید برای خواننده توضیح مختصری هم بدید که مطالب چه‌اند. (۱)
پراکنده‌ی خودم: «دیتاساینس» الان داغه چنان‌که «بیگ‌دیتا» چند سال پیش بود، و متاسفانه این امر فضا رو نویزی می‌کنه و ادعاها رو زیاد. خودِ این رشته‌سازی و نام‌گذاری، امریست پسندیده و باعث پیشرفت، ولی به عنوان یک شغل مجرد از دانش‌هایی در بقیه‌ی علوم کامپیوتر، جای صحبت داره. (۲)
May 22, 2021 • 9 tweets • 3 min read
دو نمونه‌ی بعدی: یک مساله/سوال خوب برای مصاحبه در سیستم‌های توزیع شده و یکی در علوم داده.
فرض کنید سرویسی داریم که هزاران/میلیون‌ها درخواست بر ثانیه پاسخ می‌دهد. برای کنترل هزینه‌های سرسام‌آور پردازشی، پاسخ‌ها را cache می‌کنیم (مثلا cache خودش یک job توزیع شده است) تا … (۱)
… برای درخواست‌های مشابه، همان پاسخِ پیشین را برگردانیم. برای سادگی فرض کنید ظرفیت پردازشی و ذخیره‌سازی cache نامحدود ولی عمر (TTL) داده‌ها در cache تنها T دقیقه است. از این cache حدود ۵۰٪ hit rate می‌گیریم یعنی اگر cache نباشد بار پردازشی سیستم دو برابر می‌شود. (۲)
May 1, 2021 • 8 tweets • 2 min read
ببینیم می‌شه چندتا از مساله‌های جالبی که استثنای توییت زیر بوده رو ساده‌سازی و قابل انتقال با توییتر کرد یا نه. مشکل اینه که ساده‌ترین حالت مساله‌ها هم رشته‌ی طولانی می‌شه.
فرض کنید با کاوش در داده‌های تعامل کاربران با YouTube می‌خوایم از اون‌ها «الگو» دربیاریم و ... (۱)
... بر اساسش «الگوریتم» cache serverهای CDN گوگل رو بهبود بدیم. چه الگوریتمی؟ این که هر سرور تصمیم بگیره چه قطعه‌هایی از داده رو در دیسکش ذخیره کنه یا نکنه تا hit rateاش (درصد دفعه‌هایی که می‌تونه قطعه‌ی درخواستی رو از دیسک خودش و بدون مراجعه به بالادست بده) بیشینه بشه. (۲)
Apr 29, 2021 • 4 tweets • 2 min read
بیاید به این‌جا نرسیم که کلا استفاده از واژه‌ی «زن» و «مرد» رو جنسیت‌زدگی بدونیم. اگر شخص الف روی زن و ضعیف بودن حرف می‌زد و شخص ب در اصلاح نگاه الف (برای مخاطب الف و به زبان الف) گفت نه چنین نیست و زن می‌تونه قوی‌تر از مرد هم باشه، بهش بگید ایولله، نگید جنسیت‌زده. (۱)
آیا شخص ب می‌تونست رویکرد بهتر/قوی‌تری داشته باشه؟ قطعا. آیا شخص ب خودش جنسیت‌زده رفتار کرد؟ نه، شورش رو درنیارید. این نگاه افراطی، اصلا به ضرر اصل هدف/cause است تا به نفع. همین‌طور در مساله‌های مشابه مثل حقوق اقلیت‌های و محیط زیست و ...
سانتی‌مانتالیسم، آفت خانما‌ن‌سوز. (۲)
Apr 21, 2021 • 10 tweets • 3 min read
از بزرگ‌ترین گلایه‌های کارمندان گوگل (و احتمالا جاهای شبیه) اینه که همه‌ش داریم کار گِل می‌کنیم. وظیفه‌ی مدیرهای بیچاره هم اینه که روحیه بدن که نَه و کارِت مهمه. کارهای جذاب هم هست، ولی نسبت به جمعیت، خیلی کم. آدم‌های قوی رو با فیلترهای سخت می‌گیرن و بعد می‌ذارن پای کارِ هیچ. (۱)
اصطلاح معروف اینه که کار روزمره‌ی یک برنامه‌نویس شرکت، جابجا کردن protoهاست: برداشتن fieldها از این داده‌ساختار و گذاشتنش تو اون یکی اون؛ پیچیدن (wrap) این API در اون؛ ترجمه از این نما (representation) به اون. هم‌کاران فراوانی دارم که سال‌هاست کارشون در همین حوالی‌ست. (۲)
Mar 27, 2021 • 10 tweets • 3 min read
این که در timeline توییترتون چی ببینید دو گونه داره و شما حق انتخاب دارید: آخرین توییت‌ها یا توییت‌های برتر/top. به نظر می‌آد که تقریبا همه روی گونه‌ی دوم هستن - شمار دنبال‌شوندگان (followingها) در bioها عموما «صدها»ست. آیا با خطرهای این انتخاب آشنا هستید؟ (۱)
#دالان_پژواک
گونه‌ی دوم (توییت‌های برتر) یعنی کارگردانِ این که من چه‌ها ببینم، مدل‌های یادگیری ماشینی هستند که توییتر ازعلایق من ساخته. در ظاهر اشکالی نداره و خیلی هم خوبه؛ من که وقت ندارم «همه‌ی» توییت‌های ۴۰۰ نفری که دنبال می‌کنم رو بخونم و یکی باید برام انتخاب کنه. ولی بر چه اساسی؟ (۲)
Mar 26, 2021 • 7 tweets • 3 min read
از موضوع‌های همیشگی در گپ و گفت با هم‌کاران در بازار ایران، پایداری برای سرویس‌هاست. مطالبی گِرد این موضوع نوشتم که در چند بخش منتشر خواهم کرد. بخش نخست در پایین آمده. اگر در شرکتتان مساله‌های مشابه دارید، پای مطالب بنویسید یا پیغام دهید برای گفتگوی بیشتر. (۱)
سپاس‌گزارِ عزیزانی که لطف کردند و در بازبینی پیش‌نویس‌ها کمک کردند هستم، به ویژه @mehrdd_seno و @reza_sameei.
بخش آغازین: تصویر کلی و گام نخست. از این‌جا بخوانید: vrgl.ir/UKAsU.
چکیده‌ی کوتاهی در زیر آمده. (همین‌ها در نوشتار اصلی هم هست؛ تا دوباره‌خوانی نکنید.) (۲)
Mar 23, 2021 • 7 tweets • 2 min read
به بهانه‌ی حادثه‌ی اخیر آروان، کمی از پاسخ به حادثه (incident response) گپ بزنیم. پاسخ به حادثه‌های بزرگ نه تنها از جهت فنی سخت و حساسه---بیشتر حادثه‌های بزرگ جدید و بی‌سابقه‌اند و مهارشون تا چندین شبانه روز می‌کشه---بلکه از جهت مدیریت فرایند و ارتباطات بیرونی هم بَل حساس‌تر. (۱)
نخست، فرایند پاسخ «تیمی» به حادثه نیاز به از پیش فکر شدن و آموزش و مانور آمادگی داره، تا افراد دور خودشون نچرخن یا کارها لابه‌لای ارتباطات گم نشه یا کار تکراری یا (بدتر) کار اشتباهی انجام نشه. نرخ اشتباه در تب و تاب پاسخ به حادثه به شکل تعجب‌آوری بالاست - ادعای آماری نیست ... (۲)
Mar 16, 2021 • 9 tweets • 2 min read
دوستی شیرازی داشتم که سر صحبت از دیوان حافظ و لهجه‌ی شیرازی، می‌گفت حافظ را باید «بی‌لهجه» خواند و منظورش از «بی‌لهجه»، لهجه‌ی تهرانی بود. افسوس. یعنی نگاه «اصلیش ماییم و فرعیش شما» نه تنها برای طرف غالب نهادینه شده بلکه برای طرف مغلوب هم. (۱)
#فارسی_دوستی
یک: یاد بگیریم بگوییم لهجه‌ی تهرانی، لهجه‌ی شیرازی، لهجه‌ی هراتی، … نگوییم بی‌لهجه و بالهجه. واژه، اندیشه را شکل می‌دهد. بی‌لهجه نداریم. فارسی معیار؟ بی‌خیال! خواهم گفت.
دو: حافظ احتمالا به گوشش هم نخورده بوده که «نَمی‌توان»، «نِمی‌توان» تلفظ شود و «دستُم»، «دستَم». بله ... (۲)
Mar 10, 2021 • 5 tweets • 2 min read
این هفته ارائه‌ای در اتکاپذیری بود با عنوان «لامصب رادَسته» (gosh darn convenient) که نکات جالبی داشت، نکات سرراست و بدیهی ولی معمولا مغفول در طراحی‌ها. (۱)
#سیستم_همیشه_بالا
مثلا برای یک سیستم که فلان فایل ورودی/پیکربندی رو می‌گیره (مثلا برای مدیریت ترافیک، برای اِعمال بر درخواست‌ها، برای کنترل سهمیه‌ها، …) اون فایل رو براش کجا بگذاریم که بره برداره؟ چه جایی بهتر و رادَست‌تر از سرویس مدیریت نسخه‌های کُد (مثلا git)؟ هم دم دسته، هم به سادگی ... (۲)
Dec 14, 2020 • 9 tweets • 2 min read
امروز برخی سرویس‌های گوگل برای ۴۵ دقیقه خوابید و رفت در خبرها. بیشتر outageهای بزرگ حاصل تعامل چند اشکال با همه، این بار در file system توزیع‌شده‌ی گوگل (Colossus) برای سرویس‌دهی به سیستم احراز هویت گوگل (GAIA). بهانه‌ایست تا یک رویکرد سازمانی مرتبط و خیلی مهم رو مرور کنیم: (۱)
یک مثال که معمولا در کلاس‌های دوره‌ی معارفه مرور می‌شه اینه که یک بار یک بابایی یک configای در سیستم مدیریت jobها (سیستم Borg که بابای Kubernetes است) push کرد و کلّ گوگل رفت پایین! pagerها شروع کرد به زنگ و SREها این ور اون ور می‌دویدن و این حرفا. (۲)
بودجه‌ی استادها، که ازش حقوق دانشجو و خرج سفرها و امکانات و ... رو می‌دن، دادنی نیست بلکه گرفتنی‌ست و باید روزها وقت گذاشت و proposalها نوشت و از فلان شرکت و دولت و شهرداری بودجه گرفت برای پژوهش روی فلان مساله‌ها. خوب عیبیش چیه؟ (۱)
اینه که عمدتا کار به درد بخوری از این همه پول و زحمت درنمی‌آد و همه هم اینو می‌دونن و باز ادامه داره. یعنی بودجه‌ایست که از طرف شرکت/دولت/شهرداری/... باید به اسم «پژوهش» صرف بشه و می‌شه. آورده‌اش؟ چندتا مقاله و البته سفر به نصف دنیا! آورده‌اش برای منبع بودجه؟ آها، اون هیچی. (۲)
… شرکت کنید (حضوری) لطفا در این فرم یک ایمیل وارد کنید که اگر تصمیم به برگزاری شد بهتون خبررسانی بشه.