درسته کدک 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

اگه دوست دارید در مورد کرنل لینوکس و زمان بندها و pidها بیشتر بدونید این مطلب رو توصیه میکنم:
چه پروسسی در کرنل، pid 0 داره؟
https://blog.dave.tf/post/linux-pid0/

یه مطلب خوب در مورد معرفی وب اسمبلی
https://vrgl.ir/g268k

توضیح بسیار خوب و روونی داره و مدل ذهنی خوبی ایجاد میکنه

یکی هم مقاله فیگما راجع به همین موضوع رو کامنت کرده بود که به نظر جالب میاد

https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/

به بهانه‌ی این مطلب چند تا نکته در مورد خوندن کد بگم:

۱- خوندن کد خوبه و هر کدی هم باشه کلا خوبه. مثل کتاب خوندن. از نظر من کد خوندن مثل رمان و کتاب خوندنه.

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

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

۴- یه سری پروژه‌ها (مثلا minix) به هدف اینکه سورس کد قابل فهمی داشته باشن نوشته می‌شن و یه سری دیگه به هدف پرفورمنس و کاربردی بودن و ... شروع کردن از اونایی که سورس کد مرتب تر و ساده‌تری دارن قطعا توصیه می‌شه. مخصوصا اگه ایده‌ی کلی از اون سیستمی که پیاده‌سازی می‌شه نداریم. مثلا اگه نمی‌دونیم سیستم‌عامل چطوری کار می‌کنه بهتره اول کتاب در موردش بخونیم. بعد یه کتاب یا منبعی که سورس‌کد رو توضیح داده بخونیم (یا همین مینیکس که سورس کد ساده و با کامنتی داره). و در نهایت می‌تونیم (شاید بتونیم) سورس کد یه سیستم‌عامل واقعی رو بخونیم.

۵- خوندن کد خیلی وقتا مثل کتاب نیست که از اول شروع کنیم تا آخر بریم، بلکه به شکل چرخیدن تو یه جنگل بزرگه. می‌چرخیم و جاهای جالبش رو نگاه می‌کنیم. مثلا همین که فایل cgroupش رو باز می‌کنیم. گاهی هم سعی می‌کنیم ساختارمندتر کار کنیم مثلا main رو باز می‌کنیم و از اونجا می‌ریم جلو. (البته اگه mainی در کار باشه!)

۶- (شاید نظر نامحبوب) خیلی وقتا نیازی نیست همه‌ی کد رو خونده باشیم یا حتی فهمیده باشیم تا بتونیم یه contributionی انجام بدیم. برای انجام یه تغییر کافیه بدونیم کلیت داستان چیه (مثلا main چطوری کار می‌کنه، قسمتی که کد من رو کال می‌کنه چطوریه و معماری و پوشه‌بندی کلی چطوریه) و تغییرمون رو در جای درستش اعمال کنیم. مثلا اگه می‌خوایم کوئری بهینه‌تری برای دیتابیس بنویسیم خیلی وقتا نیاز نیست که بدونیم تو dockerfile چه خبره یا مثلا تو http handler دقیقا چه اتفاقی می‌افته. یا در مثال لینوکسش، اگه می‌خوایم در مورد cgroup بیشتر بدونیم قاعدتا نیاز نیست در مورد درایورهای گرافیک چیز زیادی بدونیم. مخصوصا اگه معماری کد خوب باشه و الکی چیزا رو به هم متصل نکرده باشه.

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

امروز کلا بحث runC بود. از docker و containerd شروع شد. و در نهایت من کل روز رو صرف خوندن همین یک دونه فایل در کرنل کردم. cgroup. سعی کردم یه شهود کلی بگیرم. یه سری پیچیدگی‌ها رو از فهمیدنشون دست کشیدم ولی خب واقعا مفید بود. برای بار هزارم درود بر torvalds.

این مطلب به زبان ساده توضیح میده jwt چیه و چه کاربردی داره و چطوری کار می‌کنه.
https://dev.to/manav-1011/jwt-explained-19o6

دوست دارید به ویم سوییچ کنید ولی بار اول و دوم ناامید شدید؟
این دوستمون هم همینطور ولی بلاخره به cool kids club پیوست.
https://emanuelcepoi.com/preview/66785dd2d3170dd0332a47d9

در مورد طراحی code testable این مطالب خیلی جالب بود:
به کسی که از کد شما استفاده می‌کنه و میخواد کدشو تست کنه هم فکر کنید.

https://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/en/thing_35

چطور به عنوان یک دولوپر، مراقب چشم‌هامون باشیم؟

https://mykola-harmash.medium.com/developer-tip-to-save-your-eyes-f83135baa64c

در مورد دستور git restore که یکی از دستورهای جدید گیت و به نوعی جایگزین برخی قابلیت های checkout و reset هست بیشتر بخونیم:
https://www.git-tower.com/learn/git/commands/git-restore

برای ثبت نام این دوره اگه خواستین با ده درصد (برای فقط ۵ نفر متاسفانه) ثبت نام کنید از این کد تخفیف استفاده کنید.
RSHQBC8

چه ایمجی برای استفاده در پروداکشن خوبه؟
آیا باید از دیسترو ها استفاده کنیم یا ایمج scratch هم جواب میده؟
https://sam.gleske.net/blog/engineering/2022/10/25/guide-to-production-docker-images.html

خیلی وقتا برای ما پیش میاد که تو یه برنچی کار میکنیم که میخوایم با main/master مرجش کنیم ولی کس دیگه‌ای اول مرج میکنه برنچشو و ما conflict می‌خوریم.
حالا وقتی میخوایم کانفلیکت‌ها رو حل کنیم می‌تونیم برنچ main رو با برنچ خودمون merge کنیم یا برنچ خودمون رو rebase کنیم به main جدید.

اینکه کدومش خوبه کدومش نه، جوابش بستگی داره‌س!
تو تیم‌هایی که جونیور زیاد دارن توصیه می‌شه مرج کنید و تموم. اینطوری تاریخچه پیچیده‌تری دارید (چون چرا یهو main تو یه برنچ مرج شده) ولی مجیک خاصی اتفاق نمی‌افته.
از طرفی rebase باعث می‌شه که یه تاریخچه شبیه‌سازی شده و جدید به وجود بیاد که توش کامیت‌های برنچ جدید شما انگار بعد از آخرین کامیت main به وجود اومدن! برای کسی که بعدا نگاه کنه فهمش راحت تره ولی نکته اینه که چنین چیزی اصلا وجود نداشته و ممکنه مشکل لاجیکی تو کد ایجاد کنه.
تو این ویدیو این بحث رو خیلی خوب در قالب یه مکالمه توضیح دادن. توصیه می‌کنم ببینید.
https://www.youtube.com/watch?v=7gEbHsHXdn0

در کنار مهندس نرم‌افزار و DevOps و SRE
خوبه بدونیم platform engineer چیه و چه کاری می‌کنه.

https://platformengineering.org/blog/what-is-platform-engineering

آیا گوشی هوشمند ما به ما گوش می‌کنه؟
احتمالا بله.
https://news.itsfoss.com/ad-company-listening-to-microphone/

(یه مقدارم عنوانش کلیخور و زرده ولی حالا ببینیدش ضرر نداره)

امروز، ۹ سپتامبر، سال‌روز تولد دنیس ریچی است.

دنیس مک‌آلیستر ریچی، دانشمند کامپیوتر آمریکایی بود که بیشتر به عنوان خالق زبان برنامه‌نویسی C و مشارکت‌های زیادش در توسعه و خلق سیستم‌عامل یونیکس به همراه کن تامسون، شناخته می‌شه. ریچی و تامسون در سال ۱۹۸۳ جایزه تورینگ که ارزشمندترین جایزه در حوزه علوم کامپیوتر هست رو به دلیل پیاده‌سازی یونیکس می‌گیرن. دنیس ریچی همچنین در سال ۱۹۹۹ مدال ملی فناوری رو توسط رییس‌جمهور وقت آمریکا، کلینتون دریافت می‌کنه. جسد ریچی در ۱۲م اکتبر ۲۰۱۱ در سن هفتادسالگی‌اش در خونه‌اش که به تنهایی در اون زندگی می‌کرد پیدا شد. هیچ‌گاه زمان دقیق مرگ دنیس مشخص نشد. اعلام فوت ریچی یک هفته بعد از مرگ استیو جابز بود اما پوشش رسانه‌ای قابل توجه‌ای در مقایسه با جابز براش ایجاد نشد. امروز ۸۳مین سال‌روز تولد دنیس هست. بدون مشارکت‌های او، احتمالاً هیچ کدوم از ما نمی‌تونستیم به شکل کنونی از کامپیوترها، نرم‌افزارهای پیچیده یا حتی اینترنت مدرن استفاده کنیم.

https://en.wikipedia.org/wiki/Dennis_Ritchie
hadi @geekalerts