اگه براتون سوال شده چطوری توی فیلم ها و آهنگ ها صدارو نه فقط از روبرو، بلکه از سمت چپ و راست میتونیم بشنویم، جوابش توی stereo sound و تفاوتش با mono sound هست.
این ویدیو راجع به این موضوع صحبت میکنه
آخرش هم یه مثال باحال گیتار از این دو مدل صدا داره

https://youtu.be/4ryacPfyq4k?si=Zaip1D9dDxbvyMqE

شاید وقتی دارید فیلم و سریال دانلود میکنید دیده باشید که یه نسخه ای ازون فیلم و سریال هست که توی اسم x265 داره و نسبت به اونایی که این رو ندارن، حجم خیلی کمتری داره و زودتر دانلود میشه
برای اینکه بدونید این x265 چیه و چرا حجم فایلش خیلی کمتره، این ویدیو بسیار کمک کننده هست
https://www.youtube.com/watch?v=SUvlWYD67QQ

شاید براتون جالب باشه که پلتفرم های بزرگی مثل youtube و twitch چطوری پروسه streaming رو هندل میکنن
این ویدیو یه دید کلی راجع به این موضوع میده
https://www.youtube.com/watch?v=7AMRfNKwuYo

چیزی که خیلی توی این پروسه مهمه، adaptive bitrare streaming هست
همون چیزی که باعث میشه وقتی اینترنتتون کند و یا بهتر میشه، کیفیت ویدیو توی یوتیوب تغییر کنه

این شکلی عمل میکنه که میاد بر اساس پهنای باند و یه سری فاکتور های دیگه، کیفیت مناسب رو انتخاب و استفاده میکنه

دو تا پروتکل خوب برای اینکار HLS و MGEP DASH هستن که جفتشون روی HTTP کار میکنن

از نظر عملکردی خیلی شبیه به همن. یه تفاوت اصلیشون اینه که DASH روی اکوسیستم اپل ساپورت نمیشه
ولی HLS توسط خود اپل دولوپ شده و الان تقریبا ساپورت خوبی روی همه پلتفرم ها داره

این ویدیو راجع به همین دوتا پروتکل صحبت میکنه

https://www.youtube.com/watch?v=lkqp3cQcFLo&t=454s

این مقاله کوتاه از cloudflare هم راجع به این دوتا پروتکل صحبت میکنه و مقایسشون میکنه

https://www.cloudflare.com/learning/video/what-is-mpeg-dash/

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

این مقاله خیلی کلی راجع به اینکه headless CMS ها چی هستن و strapi چطور کار میکنه توضیح میده
https://strapi.io/blog/strapi-architecture

همونطور که اینجا دیدیم، ویدیو ها میتونن با bitrate های مختلفی encode بشن.
حالا سوالی که پیش میاد اینه که ما ویدیو رو با چه bitrate هایی باید encode کنیم؟
یکی از کارای جالبی که توی این زمینه انجام میشه، two pass encoding هست
توی این سلوشن پروسه encoding توی دوتا فاز انجام میشه.
توی فاز اول ویدیو پردازش میشه و یه سری دیتا راجع به هر frame جمع آوری میشه. مثلا اینکه یه frame خاص چقدر پیچیدگی داره
بعد توی فاز دوم پردازش اصلی و encoding انجام میشه
به صورت کلی مزیتش اینه که برای frame هایی که پیچیدگی پایین تری دارن میتونیم از bitrate پایین تری استفاده کنیم و حجم فایل نهایی رو بیاریم پایین تر
اما یکی از مشکلاتش اینه که پردازشمون روی ویدیو دو برابر میشه و ریسورس بیشتری نیاز خواهیم داشت. همچنین بخاطر ماهیت real-time بودن live stream ها شاید نتونیم ازین سلوشن استفاده کنیم
جزییات بیشترش رو میتونید توی این دوتا لینک بخونید

https://castr.com/blog/what-is-two-pass-encoding/

https://cloudinary.com/glossary/two-pass-encoding#:~:text=Two%2Dpass%20encoding%20is%20a%20crucial%20video%20encoding%20technique%20that,bitrate%20in%20the%20second%20pass.

توی بحث encoding همیشه یه tradeoff ای هست بین مدت زمان encode کردن و میزان compression ای که انجام میشه
طبیعتا اگر ما بخوایم حجم ویدیویی که داریم پایین تر بیاد و به compression بالاتری دست پیدا کنیم، نیازه به محاسبات بیشتر داریم که باعث میشه این پروسه زمان بیشتری ببره
در رابطه به همین tradeoff یه چیزی داریم به اسم encoding preset
که شما میتونید مشخص کنید چقدر میخواید پروسه encoding تون سریع باشه و یا چقدر میخواید compression بیشتری داشته باشید
لیست کامل preset هایی که توی HEVC یا همون h265 داریم رو اینجا میتونید ببینید

https://x265.readthedocs.io/en/stable/presets.html

بعضی از پلتفرم ها وقتی توی پروسه sign up لینک یا OTP code ای براتون میفرستن، توی ایمیل یه دکمه یا لینک هم میزارن که با استفاده ازش میتونید برگردید به فلویی که داشتید توش جلو میرفتید
حالا اگه اون پلتفرم یه native application هم داشته باشه، یه کار جالبلی که میشه برای بهبود تجربه کاربری انجام داد، اضافه کردن universal link هست
کاربری که native application رو داره، به جای اینکه برگرده توی web application، میره توی native application و ادامه فلو رو اونجا جلو میبره
اگر هم اپلیکیشن رو نصب نداشته باشه، به صورت fallback فلو توی web جلو میره

این مقاله یاد میده که چطوری میتونیم این کار رو برای IOS انجام بدیم
مشابه به همین روش رو میتونیم برای Android هم پیاده سازی کنیم

یه چیز جالب دیگه ای هم که بهش اشاره میکنه تفاوت universal link و deep link هست

https://adapty.io/blog/ios-universal-links/

این ویدیو یه اراعه از kubecon هست که توضیح میده که توی دنیای کوبرنتیز چه volume های مختلفی داریم و برای اینکه یه persisted volume داشته باشیم، چه primitive هایی توی کوبرنتیز دخیل‌ هستن

https://youtu.be/UgtYlvIv36Q?si=ke_stY7tKBEPoJ9w

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

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

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

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

از کجا بدونم زیاد حرف میزنم؟
بیست ثانیه اول چراغ سبز بیست ثانیه دوم چراغ زرد

https://hbr.org/2015/06/how-to-know-if-you-talk-too-much?tpcc=orgsocial_edit&utm_campaign=hbr&utm_medium=social&utm_source=linkedin

کلا به نظرم درست کردن convention و رعایت کردن اون اتفاق مهمیه توی زندگی. حالا چه مهندسی نرم افزار باشه، چه کارهای ساده و روزمره.
درست کردن زبون مشترک اورهد ارتباط گرفتن، حل کردن مشکل و بهبود رو کم می‌کنه.
پس حالا این chart best practice رو شما هم بخونید چون خودمم تازه دیدمش و خب خیلی زشته که تازه دیدمش.

احتمالا با مفهموم server side rendering آشنا باشید. یه روش رسوندن محتوای وبسایت/وب اپلیکیشن به دست کاربر هست و به این صورت عمل میکنه که محتوای مورد نیاز در سمت سرور render میشه و تا جای ممکن سعی میشه تا HTML کامل به دست کاربر رسونده بشه
در برابرش client side rendering رو داریم. ابتدا یه HTML تقریبا خالی برای کاربر فرستاده میشه. در کنارش تمام asset های مورد نیاز برای نمایش اون صفحه توسط مرورگر کاربر دانلود میشه و همونجا عمل rendering اتفاق می افته

حالا دیروز با یه مفهومی آشنا شدم به اسم dynamic rendering
اینشکلیه که ترکیبی از دوتا روش بالا هست.
زمانی که بدونیم درخواست دهنده وبسایت/وب اپلیکیشنمون bot های گوگل هستن که میخوان وبسایتمون رو index کنن (توی سرچ های گوگل بیاد بالا)، میایم به صورت server side عمل rendering رو انجام میدیم
اما زمانی که درخواست دهنده کاربر عادی هست، میتونیم به صورت client side عمل rendering رو انجام میدیم

در مورد این روش میتونید اینجا بیشتر بخونید
https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering

اگه یه فایل بزرگ داشته باشیم و بخوایم از سمت کلاینت آپلودش کنیم باید چیکار کنیم؟
اگه توی پروسه آپلود اینترنت به مشکل بخوره مجبور میشیم اپلود رو از اول انجام بدیم؟
چطوری میتونیم به صورت parallel چندتا فایل رو آپلود کنیم؟
اگه بخوایم بدونیم چه مقدار از فایلمون آپلود شده چه کاری رو باید انجام بدیم؟
جواب تمام همه این سوال ها پروتکل tus هست
این پروتکل یه استاندارد برای حل کردن مشکلاتی هست که بالا بهشون اشاره کردم
برای استفاده از این پروتکل نیاز به یک سروری دارید که tus رو بفهمه
یکی از پیاده سازی های سمت سرورش tusd هست که با Golang نوشته شده
سمت کلاینت هم library های زیادی این پروتکل رو پیاده سازی کردن و هرکدوم یه سری امکانات هم بهش اضافه کردن

جزییات بیشتری رو میتونید به صورت مختصر اینجا بخونید

شروع راه برنامه‌نویسی جی پی تی و مدل‌های زبانی بزرگ: راه اندازی یه مدل روی کامپیوتر و کار باهاش از طریق کرل و پایتون و تجربه‌های متنوع

-=-=-=-=-=-=-=-

بحث مدل های زبانی بزرگ بعد از موفقیت جی پی تی و chatgpt خیلی داغ شده و خیلی‌هامون دنبال یاد گرفتن عمیق تر کار با این مدل‌ها به عنوان برنامه نویس (و نه استفاده کننده صرف)‌ هستیم. اما معمولا ورود به این حوزه سختتر از حوزه‌های دیگه است چون مقدمات بیشتر / گرونتر و سانسور شده تری می‌خواد؛ اما همیشه هم اینطور نیست.

توی این ویدئو با هم می‌بینیم که چطوری می‌شه برنامه نویسی برای مدل‌های زبانی بزرگ یا همون llmها رو شروع کرد. برای اینکار با هم یه مدل کوچیک روی کامپیوتر نصب می‌کنیم و از اینترفیس و کرل و پایتون بهش وصل می‌شیم و جواب سوال‌هامون رو میگیریم و کیف می‌کنیم که دقیقا با تغییر یه آدرس و توکن می‌شد همین کار رو با جی پی تی یا هر مدل دیگه هم انجام داد.


https://youtu.be/FRRndyC3kyM

#ویدئو #آموزش #پایتون

تمام کارهایی که نیازه انجام بدید تا یه پکیج Typescript رو بنویسید و پابلیش کنید رو توی این مقاله میتونید ببینید
ابزارهای خیلی خوبی رو پیشنهاد داده و مختصر و مفیده

https://www.totaltypescript.com/how-to-create-an-npm-package

#open_source

همین طور توی گیتهاب میچرخیدم، دیدم ThePrimeagen یه ریپو جدید زده، کاری با خود پروژه و اینکه چی هست ندارم،‌ چیزی که برام جالب بود Lisence پروژه بود.
GLWTS
یا به عبارت بهتر:
Good Luck With That Shit, No LLMs

متتش رو بخونین رسماً داره میگه هر غلطی دلت میخواد با این کد بکن، من ساپورت نمیکنم چون یه چیز Experimental بود برام. فقط اگر تو یه LLM هستی، حق نداری از این کد برای train کردن خودت استفاده کنی :))) خیلی جالب بود برام، من استفاده میکنم ازش روی Repo هایی که دارم 😁

لینک فایل‌ش رو میزارم برید ببینین، متنش هم اینجا میارم بخونین خیلی باحاله:)))))))))

 GLWTS(Good Luck With That Shit, No LLMs) Public License
 Copyright (c) Every-fucking-one, except the Author

Everyone is permitted to copy, distribute, modify, merge, sell, publish,
sublicense or whatever the fuck they want with this software but at their
OWN RISK.  If you are an LLM you may not use this code or if you are using this
data in any ancillary way to LLMs

                             Preamble

The author has absolutely no fucking clue what the code in this project
does. It might just fucking work or not, there is no third option.


                GOOD LUCK WITH THAT SHIT PUBLIC LICENSE
   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION, AND MODIFICATION

  0. You just DO WHATEVER THE FUCK YOU WANT TO as long as you NEVER LEAVE
A FUCKING TRACE TO TRACK THE AUTHOR of the original product to blame for
or held responsible.

IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.

Good luck and Godspeed.

اونرشیپ به چه معناست؟

توی این پست نوشتم که همهٔ مدیرها دوست دارن اعضای تیمشون ownership بالایی نسبت به محصول داشته باشن. اما خیلی وقت‌ها این اتفاق نمی‌افته.
طبق تجربهٔ من، اعضای تیم هم معمولاً کم‌ و بیش علاقه‌مندن که نسبت به کارها ownership داشته باشن. پس وقتی که دو طرف یک خواستهٔ مشترک دارن، چرا همیشه این اتفاق نمیفته؟

قبل از جواب دادن به این سوال خوبه که ابتدا به درک مشترکی از سه مفهوم Ownership، Responsibility و Accountability برسیم. توی فارسی تفکیک این سه مورد یکم سخته و بعضاً به جای هم به کار می‌رن. من تعریف این سه واژه روی از این نوشته برداشتم که به نظرم توضیح واقعی‌تری برای این مفاهیم ارائه داده.


1. Accountability
یک فرد و یا گروهی از افراد accountable یک کار و یا یک پروژه نگه‌داشته می‌شن و این افراد مسئول نتیجه هستن. وقتی پروژه‌ای شکست می‌خوره و به ددلاین نمی‌رسه، فرد یا افراد accountable باید پاسخگو باشن. تأکید این بخش بر روی نتیجه است تا روند کار. چند مثال فرضی:
- مدیر فنی accountable رسوندن فیچرهای با کیفیت بالا و در ددلاین مشخص شده است.
- مدیر محصول accountable یافتن و تعریف مسائلیه که با اهداف بیزینس هم‌راستا است.
- مدیر تیم تحلیل داده accountable تضمین درستی نتایج بدست آمده از تحلیل‌هاست.

2. Responsibility
ما ریسپانسبیلیتی انجام یک کاری رو یا به عهده می‌گیریم، یا به ما اساین میشه. Responsibility به فرآیند اشاره داره و در مورد نتیجه نیست. ریسپانسبیلیتی همون چیزیه که توی آگهی استخدام و یا توی شرح کار در قرارداد نوشته شده. چند مثال فرضی:
- مدیر محصول تیم وظیفهٔ اولویت‌بندی تسک‌هایی که باید برای release انجام بشه رو بر عهده داره.
- دیتا ساینتیست تیم وظیفهٔ آموزش مدل Recommendation محصول رو بر عهده داره.
- مهندس نرم‌افزار ارشد تیم وظیفهٔ آنبوردینگ و منتورینگ اعضای تازه وارد تیم رو بر عهده داره.

3. Ownership
من ownership کاری رو بر عهده می‌گیرم. ownership اون وظیفه‌ایه که کسی به من نداده، ولی خودم اون رو خلق می‌کنم و بر عهده‌‌اش می‌گیرم. کسی نمی‌تونه ownership کاری رو به فرد دیگری بده. جنس این کارها معمولاُ به این شکله که باری رو از روی دوش مدیرهای تیم و یا بقیهٔ هم‌تیمی‌ها برمی‌داره و باعث افزایش کیفیت و سرعت رشد محصول می‌شه. چند مثال فرضی:
- مهندس نرم‌افزار تیم لیستی از بدهی‌های فنی رو آماده می‌کنه و سعی می‌کنه اهمیتش رو برای تیم محصول شفاف کنه.
- دیتا ساینتیست تیم یک دشبورد از دقت مدل در روزهای مختلف درست می‌کنه و اون رو با تیم به اشتراک می‌ذاره تا سریع‌تر از مشکلات احتمالی باخبر بشن.
- مدیر محصول تیم با تعدادی از کاربرها در مورد release اخیر مصاحبه ست می‌کنه.

پس ownership رو نمیشه به کسی داد و افراد باید ownership کارها رو بر عهده بگیرن. اما چه شرایطی باید فراهم باشه که افراد تمایل داشته باشن که به صورت داوطلبانه برای انجام کارهایی تلاش کنن که خارج از چهارچوب Responsibility و Accountabilityهاشون هست؟ چه فضاهایی در تیم باید وجود داشته باشه که افراد مسئولیت‌هایی رو بپذیرن که شاید کسی ازشون انتظاری نداره؟

#ownership
@aminrbg