مرورگر فایرفاکس مشکل پرش توی ویدیوهای یوتیوب داره که قرار هست تو نسخه بعدی یعنی ۱۲۷.۰.۲ برطرف بشه.
میگن ایجاد شدن این مشکل تقصیر فایرفاکس نیست و مشکل به خاطر bytestream VP9 یوتیوب هست که به صورت نادرست توسط اون ارسال میشه.
برای اینکه درک کنیم این مشکل چطوری هست یه مثال میزنم، هر ویدیو رو یک کتاب در نظر بگیرید که از کلی صفحات تشکیل شده و برای اینکه این کتاب رو به شکل درستش بخونیم باید شماره صفحات رو به ترتیب جلو بریم، اول صفحه ۱ رو بخونیم و بعد صفحه ۲.
یوتیوب این صفحات رو اشتباه نام‌گذاری کرده و ممکنه اول صفحه ۱۰۰ رو ببینید و بعد اون صفحه ۹۹ بیاد.
نتیجه این باعث میشه فایرفاکس در پخش گیج بشه و ویدیو هم دارای پرش و بافرینگ بشه.
یا باید یوتیوب این مشکل رو حل کنه یا فایرفاکس یه آپدیت اختصاصی برای یوتیوب منتشر کنه.
https://bugzilla.mozilla.org/show_bug.cgi?id=1878510#c113
@geekalerts

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

یه سری از شیطونی های گوگل برای خراب شدن سایت هاش روی فایرفاکس:

https://cybernews.com/tech/firefox-users-frustrated-over-alleged-delay-on-youtube/

------

https://www.reddit.com/r/firefox/comments/18xtjqd/couldnt_sign_into_google_user_agent_switching_to/

--------

https://www.reddit.com/r/youtube/comments/17z8hsz/youtube_has_started_to_artificially_slow_down/

-----------

https://www.reddit.com/r/firefox/comments/91hbkw/youtube_page_load_is_5x_slower_in_firefox_and/

احتمالا تا مدت‌ها عجیب‌ترین پروژه‌ای باشه که اینجا معرفی می‌کنم، llama به عنوان font یا همون llama.ttf

ویدیوی دموش رو اینجا ببینید:
https://www.youtube.com/watch?v=Q4bOyYctgFI#t=6m09s

و لینک پروژه:‌
https://github.com/fuglede/llama.ttf

My Thoughts on The Clean Coder Book

مدتی پیش کتاب The Clean Coder از Uncle Bob رو خوندم.
کتاب عموماً موضوعات سطح بالای مهندسی نرم‌افزار مثل اهمیت تست کردن کد، نحوهٔ مدیریت ددلاین‌ها، تمرین زبان‌های جدید برنامه‌نویسی و ... رو مطرح کرده بود.

بعضی از بخش‌های کتاب برام تازگی داشت و یا موضوعاتی که از قبل بهشون آشنا بودم رو مجدداً بهم یادآوری کرد. توی این پست نظرم رو دربارهٔ بعضی از این موارد نوشتم.

🔗 لینک نوشته

#book
@aminrbg

اگه هنوز سراغ این کتاب ۹۷ چیز که باید هر برنامه‌نویسی بدونه، نرفتید یه چند تا موردش که جالب بود برام رو می‌ذارم شاید علاقه‌مند شدین:

در مورد ۹ام، می‌گه که وقتی یه مشکلی وجود داره در نظر بگیرید که اون مشکل توی کد شماست نه سیستم‌عامل و کامپایلر. اگرچه کامپایلر و سیستم‌عامل و کتاب‌خونه هم ممکنه باگ داشته باشن ولی اونا رو هزاران نفر دیگه هم استفاده میکنن و خیلی بعیده باگ شناخته‌نشده‌ای داشته باشن در حالی که کد خودتون رو احتمالا تازه نوشتین و کاربرای کمتری هم داره.
https://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/en/thing_09

مورد ۴۳ام می‌گه که استفاده از IDE بد نیست، اما یاد بگیرید در کنارش از ابزارهای cli برای کارهاتون مثل کامپایل کردن کد استفاده کنید.
https://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/en/thing_43

مورد ۶۲ام می‌گه که تنها چیزی که می‌تونید بهش اعتماد کنید راست بگه خود کده، چون داکیومنت ممکنه قدیمی باشه یا دقیق نباشه و دقیقا اتفاقی که می‌افته رو توضیح نده.
https://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/en/thing_62


توی مورد ۴۲ام هم کی‌گه که سعی کنید کامپایلر رو خوشحال کنید، یعنی به warningها در زودترین زمان ممکن رسیدگی کنید.
https://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/en/thing_42

چرا داشتن یه محیط توسعه‌ی فنسی بد است و بهتر است با یه چیز روتین که همه دارن سعی کنیم کار کنیم (قطعا این نظر شخصی من نیست:دی)

https://www.youtube.com/watch?v=Hj1a7QuwjSI

همچنین: چرا ستاپ‌های چند مانیتور و window managerهای فنسی به شما کمک نمی‌کنن و داشتن یه editor full screen کار بهتریه:
https://www.youtube.com/watch?v=bIDL6buGNBY

چرا خوب نیست پترن‌های جاوا رو در گو هم استفاده کنیم:
https://blog.vertigrated.com/go-is-not-java

اگه دوست دارید در مورد submodule های git بدونید در حدی که اگر مجبور شدید استفاده کنید گیج نشید، این مطلب خیلی خوبی بود
https://www.cyberdemon.org/2024/03/20/submodules.html

اگه می‌خواید حجم فایل pdfتون رو کاهش بدید با کمک ghostscript لینوکس می‌تونید ولی رابط کاربری تمیزی نداره. به جاش می‌تونید از این اسکریپت استفاده کنید و هرچقدر که دوست دارید حجم/کیفیتش رو کاهش بدید. امکانات دیگه‌ای مثل سیاه‌وسفید کردن هم داره.
https://github.com/aklomp/shrinkpdf

بیاید اول یکم مرور کنیم که Fuzzing چیه. فرض کنید یک فانکشن‌ای نوشتید که چهار تا عدد از تایپ integer رو به عنوان پارامتر دریافت میکنه. فرض کنید تابع‌تون چیزی شبیه به اینه :

fun foo(int x, int y, int z, int t) {
    
    // bunch of statements

    if ( (x^t+1)^3 + (2.3*y)^2.3 - 0.8*(z^4) == 0) { // call the condition as 'f'
        Bug();
    }

    // bunch of statements
}

همونطور که ملاحظه می‌کنید، توی برنامه‌ما یک point ای وجود داره که اگر reachable باشه به باگ می‌خوریم. حالا سوالی که وجود داره اینه که بفهمیم آیا این امکان وجود داره که شرط f ارضا بشه یا خیر. برای اینکه به جواب سوال‌مون برسیم، باید یک decision procedure پیاده‌ کنیم که به عنوان ورودی فرمول f رو ازمون بگیره، و بهمون true یا false برگردونه. یک computer scientist اولین سوالی که به ذهنش میرسه اینه که آیا این مسئله محاسبه پذیره یا خیر و اگر هست با از نظر پیچیدگی در چه کلاسی قرار داره. به طور خلاصه خدمتتون میگم که این مسئله undecidable هستش. حالا سوالی که پیش میاد اینه که چیکار کنیم؟ رهاش کنیم بره؟ خب قطعا نه. یه راهی که از دهه ۵۰ میلادی، یعنی از زمان پانچ کارت ها وجود داره اینه که بیایم شروع کنیم با یک الگوریتم Pseudo random number generating برای این ۴ تا متغیر value جنریت کنیم و چک کنیم ببینیم که آیا این فرمول تحت اون assignment ارضا میشه یا نه. اگر شد که خب میگیم بله reachable هستش و برنامه مون باگ داره. اگر نشد... خب بیاید این یه تیکه رو فعلا اسکیپ کنیم :)

حالا قضیه‌ی Fuzzing هم ریشه‌اش برمیگرده به random testing اما قطعا با رندوم تستینگ فرق داره. می‌تونیم بگیم رندوم تستینگ ساده‌ترین و naive ترین نوع Fuzzing هستش. تکنیک‌های Fuzz testing با توسعه‌ای که از دهه ۹۰ تا الان داشتن، ساختارمند شدند و باهوش تر عمل می‌کنند. یک سری‌هاشون از نوع generation-based یعنیتوی هر iteration ورودی‌ها رو از اول تعیین می‌کنند. یک سری‌هاشونم mutation-based هستند و میان input ها رو modify می‌کنند. فاز تستینگ‌ها به شکل white و black و gray box انجام میشن. بلک باکس اینطوریه که fuzzer هیچی از ساختار برنامه نمی‌دونه. gray box یعنی اینکه ما نیاز داریم کمی instrumentation روی کدمون انجام بدیم و به طبع white box هم که مشخص میشه چیه.

فازری که داچمن رفته سراغش از نوع gray-box و mutation-based هستش. منتهی باهوش تره، یعنی بلده که mutation هاش رو به سمت یک سری هدف و یا coverage خاص که از پیش براش مشخص شدن هدایت کنه. اصلاحا به این نوع فازرها میگن Directed Grey-box fuzzing. این تکنیک توسعه‌ و پیاده‌سازیش توسط آقای Abhik Roychoudhury و تیمش صورت گرفته. ایشون یه گروه بسیار سوپر و قوی توی دانشگاه NUS دارن که تو حوزه‌ی Fuzzing و Automated Program Repair فعاله. بسیار توصیه می‌کنم اگر به این بحثا علاقه‌مند هستید برید و کارشون رو بخونید.

تا اینجا مقدمه بود میریم سراغ بحث اصلی.

اگه دوست دارید در مورد ingress و ingress controller توی کوبرنتیز بدونید این مطلب خوبیه و سعی می‌کنه پیش‌نیازهای لازمش هم تا حدی پوشش بده:
https://traefik.io/glossary/kubernetes-ingress-and-ingress-controller-101/

شاید خبرش به گوشتون رسیده باشه که سیستم‌های مبتنی بر ویندوز و آژور در سراسر جهان، دیروز ترکیدن و کار و زندگی مردم فلج شده.
به عنوان کسی که این ترکیدن رو لایو تجربه کرد (داشتم روی یه تیکت تو پرتال شرکت کامنت می‌ذاشتم. بعد از سیو، کل سامانه غیب شد. 😬) بیاین با مفهومی به اسم SLA آشناتون کنم.

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

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

این توافق بین شما و مایکروسافت اسمش می‌شه Service Level Agreement یا SLA. یعنی شما با مایکروسافت توافق کردین که سرویسی که ازش می‌گیرین چند درصد مواقع قطعا سالمه. برای مصارف شخصی شاید ۹۹ درصد خیلی عدد خوبی به نظر بیاد، ولی این عدد یعنی توی یک سال جمعا حدود ۳ روز ممکنه سیستم بهتون ارائه نشه. پس برای بیزنس‌هایی که مشتری دارن ۹۹ هم به اندازه کافی خوب نیست. ممکنه نیاز داشته باشن سرویسشون در سال فقط یک ساعت داون باشه، و براش ۹۹.۹۹ درصد تضمین بگیرن. یا درخواست کنن که بیش‌تر از ۵ دقیقه در سال سیستم خراب نباشه، و تضمین ۹۹.۹۹۹ بگیرن.

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

اگر بی‌کارین، می‌تونین توی سایت uptime.is هی درصد وارد کنین، ببینین با هر درصد چند ساعت در روز سیستمتون داون خواهد بود. 😁

درسته کدک h265 یا HEVE خیلی بهمون کمک میکنه حجم ویدیوهای با کیفیت کمتر بشه، اما یه کدک دیگه هم هست که نسبتا جدید تره و compression بسیار بهتری داره. اونم av1 هست که پارسال شرکت متا برای استوری های اینستاگرام ازش استفاده کرد.
یه نکته خیلی جالب اینه که چون encode کردن ویدیو ها با این کدک منابع بیشتری نیاز داره و زمانبر تر هست، یوتیوب فقط برای ویدیو هایی که در مدت زمان کم وایرال میشن ازین کدک استفاده میکنه.
جزییات بیشتر این کدک رو اینجا میتونید ببینید
https://www.youtube.com/watch?v=BMAccTJBDjE

من از این سایت/پروژه khoj خیلی خوشم اومد. یه پروژه‌اس که رابط وب و واتساپ و ... داره و امکان این رو می‌ده که با agentهای مختلف هوش مصنوعی‌ش ارتباط برقرار کنید، فایل اپلود کنید و بگید بر اساس اون (و نوتهای obsidianتون) و ... بهتون جواب بده.
نکته مهمش اینه که می‌تونید self hostش کنید و لوکال بهش بگید که از ollama استفاده کن یا api chatgpt
رابط کاربری نسبتا خوبی داره و نسخه رایگانش که خودشون هاست کردن هم به خوبی کار می‌کنه ولی محدودیت تعداد پیام داره قاعدتا.

https://github.com/khoj-ai/khoj

نکته: رابط کابریش بهترین نیست ولی اینکه اینقدر امکانات داره و باگ‌هاشم مانع استفاده ازش نمیشه و قابل استفاده و open source و eslf hostئه باعث می‌شه مشکلات رابط کاربریش به چشم نیاد.

دوست دارید با گیت پوش، کدتون رو روی سرورتون دیپلوی کنید؟
ابزارهای مختلفی برای اینکار هستن که یکی از کوچک ترین هاش پیکو هست:
https://github.com/piku/piku