Reza Esmaeili's Thoughts
1.42K subscribers
418 photos
73 videos
25 files
255 links
روایت‌های یک مهندس نرم‌افزار خسته،
که بین کدها، چای نیمه‌سرد و موسیقی، دنبال معنا می‌گرده.
حرف‌هایی از کار، زندگی، و تکه‌هایی از ذهن من.

صفحه‌وب:
rezaesmaeili.ir

راه‌های ارتباط:
— itsreza@duck.com
@r3zaesma3ili

اینستاگرام؟
— ندارم.
Download Telegram
فکت: QA in Agile isn’t a phase. It’s a responsibility that never turns off.

یه چیزی که توی کار با تیم‌های مختلف برام جا افتاده اینه که QA توی Agile اصلاً یه مرحله نیست. بیشتر شبیه یه مسئولیت دائمیه که از لحظه‌ای که درباره‌ی یه فیچر حرف می‌زنیم شروع می‌شه و عملاً هیچ‌وقت خاموش نمی‌شه.

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

برای من، QA از همون موقعی شروع می‌شه که هنوز کدی نوشته نشده. وقتی درباره‌ی ری‌کوایرمنت حرف می‌زنیم، وقتی یه جمله هنوز مبهمه، وقتی معلوم نیست قراره سیستم توی حالت‌های غیرعادی چی‌کار کنه. همون‌جاهاست که اگه سؤال درست پرسیده نشه، بعداً باگ درست می‌شه.

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

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

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

آیا با وجود یک نقش QA در سازمان، آگاهانه ریسک رو کم می‌کنیم یا نه. چون QA توی سیستم Agile بیشتر از هر چیزی، هدفش جلوگیری از اشتباهاته؛ قبل از اینکه برسن به prod و دیگه دیر شده باشه.
6
نرم‌افزار نباید یواشکی خراب بشه: راهنمای جیغ کشیدن درست!

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

خطرناک‌ترین باگ‌ها، همونایی‌ان که ساکت می‌مونن. کرش کردن حداقل یه افتخاره! حداقل می‌گه: «هی رفیق، یه جایی از دستوراتت گند زدی، بیا درستش کن!» ولی خطای silent؟ به دروغ می‌گه «همه‌چی اوکیه» و تو بعداً توی prod می‌فهمی که چند هفته‌ست داده‌ها اشتباه ذخیره شدن یا محاسبات غلط بوده.

تجربه‌ی من می‌گه هر وقت دیدم توی کد try-catch خالی داریم، یا ارور رو swallow می‌کنیم بدون لاگ، یا فکر می‌کنیم «حالا اشکال نداره، بعداً درست می‌شه»، دقیقاً همون‌جا داریم بذر یه فاجعه رو می‌کاریم.
پس چیکار کنیم؟ ساده‌ست:

لطفاً بذارید نرم‌افزار وقتی دردش میاد، مثل بچه‌ی لوس جیغ بکشه.

هر اروری که می‌گیریم، حداقل یه لاگ درست و حسابی بزنیم (با جزئیات، stack trace، context).
اگه ارور کریتیکاله، آلارم بفرستیم (به Slack، RocketChat یا Telegram هر چی!).
و Fail fast کنیم: به جای این‌که سعی کنیم با یه مقدار پیش‌فرض ادامه بدیم، همون‌جا بگیم «نمی‌تونم ادامه بدم» و کرش کنیم یا ارور برگردونیم.
و مهم‌تر از همه، هیچ‌وقت ارور رو قورت ندیم.

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

دفعه‌ی بعد که وسوسه شدی یک خطا رو silent کنی، یادت باشه:
Software should fail loudly, not silently

اینطوری حداقل می‌دونیم کجای کار داره اشتباه جلو می‌ره، نه این‌که یه روز صبح بیدار بشیم و ببینیم همه‌چی ریخته به هم!
👍11
رباتی که توی چنل @mtproxyboy پروکسی پُست می‌کرد، به‌خاطر جابجایی کل پروژه‌هام به یک سرور نزدیک‌تر به تلگرام، خاموشه. همه رو دوباره فعال کردم اما فرصت نکردم این یکی رو دوباره دیپلوی کنم.
ممکنه تا فردا هم وقت آزادشو پیدا نکنم. بابتش عذر میخوام.
👏9🍌4
تلسکوپ، یک Cross-browser web performance testing agent از کلودفلره:
- ضبط ویدیو و فیلم‌استریپ از بارگذاری صفحه
- جمع‌آوری معیارهای زمان‌بندی، خروجی کنسول، HAR و screenshot
- امکان شبیه‌سازی شبکه، محدودیت CPU، غیرفعال‌کردن JS و تنظیم کوکی/هدر

https://github.com/cloudflare/telescope
👍61👌1
منفعل نباشیم.
👍30🍌6👎4
Ba Man Az Iran Begou
Dariush
😢6
مهم این نیست که چه کاری از دستمون بر میاد
مهم اینه که هر کاری که از دستمون برمیاد رو انجام بدیم، هرچقدر هم کوچک و ساده
👍7
توی این شرایط، فایل‌ها مخرب زیاد دست به دست می‌شن با عنوان وی‌پی‌ان و روش‌های ارتباط با اینترنت آزاد.

خودتون و خانواده رو از وجود این فایل‌ها آگاه کنین و بهشون توصیه کنین که هر فایلی رو دانلود و نصب نکنند!
7👍3
خب، این قطعی‌های اخیر اینترنت یه‌سری چیزها رو خیلی شفاف‌تر از قبل نشون داد؛ چیزهایی که شاید می‌دونستیم، ولی نه این‌قدر عریان.

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

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

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

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

۵. حتی اگه آماده هم باشی، حتی اگه اپلیکیشن و سیستم‌ت رو برای قطعی اینترنت adapt کرده باشی،
باز یه «اتفاق پیش‌بینی‌نشده» پیدا می‌شه که همه‌چی رو به‌هم بریزه.
همیشه یه سناریو هست که تو هیچ داکیومنتی نوشته نشده.

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

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

این‌بار هم گذشت.
ولی هر بار، یادمون می‌مونه که مشکل اصلی، خود اینترنت نیست؛
چیزیه که از دیده‌شدنش می‌ترسن.
11
Reza Esmaeili's Thoughts pinned «خب، این قطعی‌های اخیر اینترنت یه‌سری چیزها رو خیلی شفاف‌تر از قبل نشون داد؛ چیزهایی که شاید می‌دونستیم، ولی نه این‌قدر عریان. ۱. فهمیدیم اینترنت ماهواره‌ای اون هیولای دور از دسترسی‌ای که سال‌ها ازش تصویر می‌شد نیست. نه جادوی خاصی می‌خواد، نه فناوری فضایی…»
نحوهٔ اداره کشور و اتخاذ تصمیم‌های حیاتی، به طرز عجیبی مضحکه.
🤬8😢1
چنل اینترنت آزاد خیلیا رو این مدت به اینترنت وصل کرده. از سرویسش استفاده و حمایتش کنین.
8
میررهای «ران‌فلر» برای مخزن‌ها و کتابخانه‌های مورد نیاز برنامه‌نویسان برای استفاده در شرایط اینترانت:

https://runflare.com/mirrors
4
دیتاسنتر امین، میرر ریپوی لینوکس داره:

https://mirror.aminidc.com
👍4
دی‌ان‌اس‌های داخلی که می‌تونین ست کنین برای شرایط فعلی (پایداری ندارند البته)

217.218.155.155, 217.218.127.127, 5.200.200.200, 185.51.200.10, 2.189.44.44
👍51
این لیست دی‌ان‌اس‌های داخلی رو یکی از دوستان فرستاد که بذارم چنل، چک کنین که کدومش کار می‌کنه و بعد ست کنین:
185.161.112.33
185.161.112.34
185.51.200.10
185.231.182.126
46.224.1.42
194.225.62.80
213.176.123.5
91.99.101.12
185.187.84.15
37.156.145.229
185.97.117.187
185.113.59.253
80.191.40.41
194.225.73.141
91.245.229.1
185.51.200.50
37.156.145.21
217.218.155.155
2.189.44.44
2.188.21.131
2.188.21.132
81.91.144.116
2.188.21.130
92.119.56.162
4👍1
اگر کاربر ویندوز هستید، با این نرم‌افزار می‌تونین بین بهترین دی‌ان‌اس‌ها تست بگیرین:

https://soft98.ir/internet/16406-dns-jumper.html
👍4
اگر کاربر لینوکس هستید، این ابزار که توسط یکی از دوستان نوشته شده رو می‌تونین استفاده کنین، بهترین دی‌ان‌اس سرور رو پیدا و تنظیم می‌کنه:

با dnspython کار می‌کنه و باید از پیش نصبش کرده باشین:

https://github.com/DevALIGhasemi/dns-checker
5