اگه دوست دارید در مورد submodule های git بدونید در حدی که اگر مجبور شدید استفاده کنید گیج نشید، این مطلب خیلی خوبی بود
https://www.cyberdemon.org/2024/03/20/submodules.html
https://www.cyberdemon.org/2024/03/20/submodules.html
cyberdemon.org
Demystifying git submodules
Demystifying git submodules by showing exactly how they work.
👍4❤2
Forwarded from Geek Alerts
بالاخره zed.dev نسخه لینوکس خودش رو عرضه کرد. این نرمافزار یک ویرایشگرمتن برای توسعهدهندههاست و حدوداً یک سال از عرضه نسخه پایدارش برای مک میگذره. حالا بعد از این مدت، اولین نسخه پایدار لینوکسشون رو عرضه کردن. این ادیتور توسط سازندگان Atom ساخته شده و هدفش اینه سریعترین و بهینهترین ادیتور باشه. با rust هم توسعه پیدا کرده.
https://zed.dev/blog/zed-on-linux
hadi @geekalerts
https://zed.dev/blog/zed-on-linux
hadi @geekalerts
👍9🔥4😁1
اگه میخواید حجم فایل pdfتون رو کاهش بدید با کمک ghostscript لینوکس میتونید ولی رابط کاربری تمیزی نداره. به جاش میتونید از این اسکریپت استفاده کنید و هرچقدر که دوست دارید حجم/کیفیتش رو کاهش بدید. امکانات دیگهای مثل سیاهوسفید کردن هم داره.
https://github.com/aklomp/shrinkpdf
https://github.com/aklomp/shrinkpdf
GitHub
GitHub - aklomp/shrinkpdf: Shrink PDF files with Ghostscript
Shrink PDF files with Ghostscript. Contribute to aklomp/shrinkpdf development by creating an account on GitHub.
👍5
Forwarded from a pessimistic researcher (Kc)
بیاید اول یکم مرور کنیم که Fuzzing چیه. فرض کنید یک فانکشنای نوشتید که چهار تا عدد از تایپ integer رو به عنوان پارامتر دریافت میکنه. فرض کنید تابعتون چیزی شبیه به اینه :
همونطور که ملاحظه میکنید، توی برنامهما یک 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 فعاله. بسیار توصیه میکنم اگر به این بحثا علاقهمند هستید برید و کارشون رو بخونید.
تا اینجا مقدمه بود میریم سراغ بحث اصلی.
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 فعاله. بسیار توصیه میکنم اگر به این بحثا علاقهمند هستید برید و کارشون رو بخونید.
تا اینجا مقدمه بود میریم سراغ بحث اصلی.
Google
Abhik Roychoudhury
Professor of Computer Science, National University of Singapore - Cited by 15,533 - Program Analysis - Computer Security - AI Agents
🔥4👍2
اگه دوست دارید در مورد ingress و ingress controller توی کوبرنتیز بدونید این مطلب خوبیه و سعی میکنه پیشنیازهای لازمش هم تا حدی پوشش بده:
https://traefik.io/glossary/kubernetes-ingress-and-ingress-controller-101/
https://traefik.io/glossary/kubernetes-ingress-and-ingress-controller-101/
Run APIs Easily. Anywhere. | Traefik Labs
What is a Kubernetes Ingress Controller | Traefik Labs
A Kubernetes Ingress and ingress controller enable traffic from the internet to reach internal cluster Services. Let's look into what they are and how they work.
❤2
Forwarded from شیشهی عمر
شاید خبرش به گوشتون رسیده باشه که سیستمهای مبتنی بر ویندوز و آژور در سراسر جهان، دیروز ترکیدن و کار و زندگی مردم فلج شده.
به عنوان کسی که این ترکیدن رو لایو تجربه کرد (داشتم روی یه تیکت تو پرتال شرکت کامنت میذاشتم. بعد از سیو، کل سامانه غیب شد. 😬) بیاین با مفهومی به اسم SLA آشناتون کنم.
فرض کنین که شما از یک سرویسدهنده سرویسی رو دریافت میکنین. این سرویسدهنده باید به شما برای محصولش تضمین کیفیت بده. تو دنیای کامپیوتر و نرمافزار، یکی از معیارهای کیفیت، در دسترس بودنِ سرویسه. این که اون سرویس قطع و از دسترس خارج نشه. شما نری یه وبسایت بخری، بعد مشتریت نتونه بازش کنه.
مثلا شما به مایکروسافت میگید یک ترابایت حافظه ابری میخوام که عکسای عروسیمو بریزم روش. مایکروسافت به شما میگه این عکسها ۹۹ درصد مواقع در دسترس هستن. یعنی شما ۹۹ درصد مواقع اگر تلاش کنین عکسا رو باز کنین، باز میشن. اون ۱ درصد رو میذارن تا برای مشکلات احتمالی دست خودشونو باز بذارن. اگر برقی رفت، هکی اتفاق افتاد، سروری سوخت، کسی نتونه بیاد یقهشونو بگیره که چرا سرویسی که به من فروختی خرابه.
این توافق بین شما و مایکروسافت اسمش میشه Service Level Agreement یا SLA. یعنی شما با مایکروسافت توافق کردین که سرویسی که ازش میگیرین چند درصد مواقع قطعا سالمه. برای مصارف شخصی شاید ۹۹ درصد خیلی عدد خوبی به نظر بیاد، ولی این عدد یعنی توی یک سال جمعا حدود ۳ روز ممکنه سیستم بهتون ارائه نشه. پس برای بیزنسهایی که مشتری دارن ۹۹ هم به اندازه کافی خوب نیست. ممکنه نیاز داشته باشن سرویسشون در سال فقط یک ساعت داون باشه، و براش ۹۹.۹۹ درصد تضمین بگیرن. یا درخواست کنن که بیشتر از ۵ دقیقه در سال سیستم خراب نباشه، و تضمین ۹۹.۹۹۹ بگیرن.
اگر سرویسدهنده (در این مثال، مایکروسافت) دچار مشکلی بشه و نتونه SLA رو رعایت کنه، باید جریمه بده. مثلا شرکت ما دیروز بیش از ۴ ساعت دسترسی به پرتال نداشت، و اگر SLA شون روی ۹۹.۹۹ بوده باشه قطعا بهشون جریمه پرداخت میشه.
اگر بیکارین، میتونین توی سایت uptime.is هی درصد وارد کنین، ببینین با هر درصد چند ساعت در روز سیستمتون داون خواهد بود. 😁
به عنوان کسی که این ترکیدن رو لایو تجربه کرد (داشتم روی یه تیکت تو پرتال شرکت کامنت میذاشتم. بعد از سیو، کل سامانه غیب شد. 😬) بیاین با مفهومی به اسم SLA آشناتون کنم.
فرض کنین که شما از یک سرویسدهنده سرویسی رو دریافت میکنین. این سرویسدهنده باید به شما برای محصولش تضمین کیفیت بده. تو دنیای کامپیوتر و نرمافزار، یکی از معیارهای کیفیت، در دسترس بودنِ سرویسه. این که اون سرویس قطع و از دسترس خارج نشه. شما نری یه وبسایت بخری، بعد مشتریت نتونه بازش کنه.
مثلا شما به مایکروسافت میگید یک ترابایت حافظه ابری میخوام که عکسای عروسیمو بریزم روش. مایکروسافت به شما میگه این عکسها ۹۹ درصد مواقع در دسترس هستن. یعنی شما ۹۹ درصد مواقع اگر تلاش کنین عکسا رو باز کنین، باز میشن. اون ۱ درصد رو میذارن تا برای مشکلات احتمالی دست خودشونو باز بذارن. اگر برقی رفت، هکی اتفاق افتاد، سروری سوخت، کسی نتونه بیاد یقهشونو بگیره که چرا سرویسی که به من فروختی خرابه.
این توافق بین شما و مایکروسافت اسمش میشه Service Level Agreement یا SLA. یعنی شما با مایکروسافت توافق کردین که سرویسی که ازش میگیرین چند درصد مواقع قطعا سالمه. برای مصارف شخصی شاید ۹۹ درصد خیلی عدد خوبی به نظر بیاد، ولی این عدد یعنی توی یک سال جمعا حدود ۳ روز ممکنه سیستم بهتون ارائه نشه. پس برای بیزنسهایی که مشتری دارن ۹۹ هم به اندازه کافی خوب نیست. ممکنه نیاز داشته باشن سرویسشون در سال فقط یک ساعت داون باشه، و براش ۹۹.۹۹ درصد تضمین بگیرن. یا درخواست کنن که بیشتر از ۵ دقیقه در سال سیستم خراب نباشه، و تضمین ۹۹.۹۹۹ بگیرن.
اگر سرویسدهنده (در این مثال، مایکروسافت) دچار مشکلی بشه و نتونه SLA رو رعایت کنه، باید جریمه بده. مثلا شرکت ما دیروز بیش از ۴ ساعت دسترسی به پرتال نداشت، و اگر SLA شون روی ۹۹.۹۹ بوده باشه قطعا بهشون جریمه پرداخت میشه.
اگر بیکارین، میتونین توی سایت uptime.is هی درصد وارد کنین، ببینین با هر درصد چند ساعت در روز سیستمتون داون خواهد بود. 😁
uptime.is
SLA & Uptime calculator: How much downtime corresponds to 99.9 % uptime
SLA uptime and downtime calculator
❤6👌5👍4
Forwarded from Tech Den
درسته کدک h265 یا HEVE خیلی بهمون کمک میکنه حجم ویدیوهای با کیفیت کمتر بشه، اما یه کدک دیگه هم هست که نسبتا جدید تره و compression بسیار بهتری داره. اونم av1 هست که پارسال شرکت متا برای استوری های اینستاگرام ازش استفاده کرد.
یه نکته خیلی جالب اینه که چون encode کردن ویدیو ها با این کدک منابع بیشتری نیاز داره و زمانبر تر هست، یوتیوب فقط برای ویدیو هایی که در مدت زمان کم وایرال میشن ازین کدک استفاده میکنه.
جزییات بیشتر این کدک رو اینجا میتونید ببینید
https://www.youtube.com/watch?v=BMAccTJBDjE
یه نکته خیلی جالب اینه که چون encode کردن ویدیو ها با این کدک منابع بیشتری نیاز داره و زمانبر تر هست، یوتیوب فقط برای ویدیو هایی که در مدت زمان کم وایرال میشن ازین کدک استفاده میکنه.
جزییات بیشتر این کدک رو اینجا میتونید ببینید
https://www.youtube.com/watch?v=BMAccTJBDjE
YouTube
What You Need To Know About AV1 | The Video Codec For The Internet?
AV1 is fast taking over the internet, but why is that and should you take notice of it too? In this video we breakdown the basics of what AV1 is and why companies big and small are adopting it fast!
Check out the SABRENT Today's Deals & promotions 👇👇👇👇
…
Check out the SABRENT Today's Deals & promotions 👇👇👇👇
…
👍6❤1
من از این سایت/پروژه khoj خیلی خوشم اومد. یه پروژهاس که رابط وب و واتساپ و ... داره و امکان این رو میده که با agentهای مختلف هوش مصنوعیش ارتباط برقرار کنید، فایل اپلود کنید و بگید بر اساس اون (و نوتهای obsidianتون) و ... بهتون جواب بده.
نکته مهمش اینه که میتونید self hostش کنید و لوکال بهش بگید که از ollama استفاده کن یا api chatgpt
رابط کاربری نسبتا خوبی داره و نسخه رایگانش که خودشون هاست کردن هم به خوبی کار میکنه ولی محدودیت تعداد پیام داره قاعدتا.
https://github.com/khoj-ai/khoj
نکته: رابط کابریش بهترین نیست ولی اینکه اینقدر امکانات داره و باگهاشم مانع استفاده ازش نمیشه و قابل استفاده و open source و eslf hostئه باعث میشه مشکلات رابط کاربریش به چشم نیاد.
نکته مهمش اینه که میتونید self hostش کنید و لوکال بهش بگید که از ollama استفاده کن یا api chatgpt
رابط کاربری نسبتا خوبی داره و نسخه رایگانش که خودشون هاست کردن هم به خوبی کار میکنه ولی محدودیت تعداد پیام داره قاعدتا.
https://github.com/khoj-ai/khoj
نکته: رابط کابریش بهترین نیست ولی اینکه اینقدر امکانات داره و باگهاشم مانع استفاده ازش نمیشه و قابل استفاده و open source و eslf hostئه باعث میشه مشکلات رابط کاربریش به چشم نیاد.
GitHub
GitHub - khoj-ai/khoj: Your AI second brain. Self-hostable. Get answers from the web or your docs. Build custom agents, schedule…
Your AI second brain. Self-hostable. Get answers from the web or your docs. Build custom agents, schedule automations, do deep research. Turn any online or local LLM into your personal, autonomous ...
👍7
دوست دارید با گیت پوش، کدتون رو روی سرورتون دیپلوی کنید؟
ابزارهای مختلفی برای اینکار هستن که یکی از کوچک ترین هاش پیکو هست:
https://github.com/piku/piku
ابزارهای مختلفی برای اینکار هستن که یکی از کوچک ترین هاش پیکو هست:
https://github.com/piku/piku
GitHub
GitHub - piku/piku: The tiniest PaaS you've ever seen. Piku allows you to do git push deployments to your own servers.
The tiniest PaaS you've ever seen. Piku allows you to do git push deployments to your own servers. - piku/piku
❤8👍1
اگه دوست دارید در مورد کرنل لینوکس و زمان بندها و pidها بیشتر بدونید این مطلب رو توصیه میکنم:
چه پروسسی در کرنل، pid 0 داره؟
https://blog.dave.tf/post/linux-pid0/
چه پروسسی در کرنل، pid 0 داره؟
https://blog.dave.tf/post/linux-pid0/
blog.dave.tf
What is PID 0? · blog.dave.tf
Yes, there's a PID 0! An explanation of what it is, and a quick walk through linux early boot code.
👍5❤3
یه مطلب خوب در مورد معرفی وب اسمبلی
https://vrgl.ir/g268k
https://vrgl.ir/g268k
ویرگول
کنجکاوی در مورد Web Assembly - ویرگول
چیزایی که این مدت از WASM خونده بودم رو توی این پست جمع کردم.
👍5❤1👎1
Forwarded from Tech Den (Amirhossein)
توضیح بسیار خوب و روونی داره و مدل ذهنی خوبی ایجاد میکنه
یکی هم مقاله فیگما راجع به همین موضوع رو کامنت کرده بود که به نظر جالب میاد
https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/
یکی هم مقاله فیگما راجع به همین موضوع رو کامنت کرده بود که به نظر جالب میاد
https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/
👎3❤2
به بهانهی این مطلب چند تا نکته در مورد خوندن کد بگم:
۱- خوندن کد خوبه و هر کدی هم باشه کلا خوبه. مثل کتاب خوندن. از نظر من کد خوندن مثل رمان و کتاب خوندنه.
۲- با خوندن کد بیشتر و بهتر، کدهای بهتری هم خواهید نوشت. یادگیری دیزاین پترن و اصول کد تمیز خوبه ولی دیدن اینکه در عمل چه چیزی باعث خوب شدن کد میشه یه چیز دیگهست و اگه کد بخونید از بقیه جلو میافتید.
۳- همونطور که وقتی الفبا رو یاد گرفتیم نمیشه انتظار داشت که آثار شکسپیر رو بخونیم، قاعدتا اگه اولین کدی که میخونیم کد لینوکس باشه، خیلی چیزاشو متوجه نمیشیم. میشه اول از چیزهای سادهتر شروع کرد.
۴- یه سری پروژهها (مثلا minix) به هدف اینکه سورس کد قابل فهمی داشته باشن نوشته میشن و یه سری دیگه به هدف پرفورمنس و کاربردی بودن و ... شروع کردن از اونایی که سورس کد مرتب تر و سادهتری دارن قطعا توصیه میشه. مخصوصا اگه ایدهی کلی از اون سیستمی که پیادهسازی میشه نداریم. مثلا اگه نمیدونیم سیستمعامل چطوری کار میکنه بهتره اول کتاب در موردش بخونیم. بعد یه کتاب یا منبعی که سورسکد رو توضیح داده بخونیم (یا همین مینیکس که سورس کد ساده و با کامنتی داره). و در نهایت میتونیم (شاید بتونیم) سورس کد یه سیستمعامل واقعی رو بخونیم.
۵- خوندن کد خیلی وقتا مثل کتاب نیست که از اول شروع کنیم تا آخر بریم، بلکه به شکل چرخیدن تو یه جنگل بزرگه. میچرخیم و جاهای جالبش رو نگاه میکنیم. مثلا همین که فایل cgroupش رو باز میکنیم. گاهی هم سعی میکنیم ساختارمندتر کار کنیم مثلا main رو باز میکنیم و از اونجا میریم جلو. (البته اگه mainی در کار باشه!)
۶- (شاید نظر نامحبوب) خیلی وقتا نیازی نیست همهی کد رو خونده باشیم یا حتی فهمیده باشیم تا بتونیم یه contributionی انجام بدیم. برای انجام یه تغییر کافیه بدونیم کلیت داستان چیه (مثلا main چطوری کار میکنه، قسمتی که کد من رو کال میکنه چطوریه و معماری و پوشهبندی کلی چطوریه) و تغییرمون رو در جای درستش اعمال کنیم. مثلا اگه میخوایم کوئری بهینهتری برای دیتابیس بنویسیم خیلی وقتا نیاز نیست که بدونیم تو dockerfile چه خبره یا مثلا تو http handler دقیقا چه اتفاقی میافته. یا در مثال لینوکسش، اگه میخوایم در مورد cgroup بیشتر بدونیم قاعدتا نیاز نیست در مورد درایورهای گرافیک چیز زیادی بدونیم. مخصوصا اگه معماری کد خوب باشه و الکی چیزا رو به هم متصل نکرده باشه.
۱- خوندن کد خوبه و هر کدی هم باشه کلا خوبه. مثل کتاب خوندن. از نظر من کد خوندن مثل رمان و کتاب خوندنه.
۲- با خوندن کد بیشتر و بهتر، کدهای بهتری هم خواهید نوشت. یادگیری دیزاین پترن و اصول کد تمیز خوبه ولی دیدن اینکه در عمل چه چیزی باعث خوب شدن کد میشه یه چیز دیگهست و اگه کد بخونید از بقیه جلو میافتید.
۳- همونطور که وقتی الفبا رو یاد گرفتیم نمیشه انتظار داشت که آثار شکسپیر رو بخونیم، قاعدتا اگه اولین کدی که میخونیم کد لینوکس باشه، خیلی چیزاشو متوجه نمیشیم. میشه اول از چیزهای سادهتر شروع کرد.
۴- یه سری پروژهها (مثلا minix) به هدف اینکه سورس کد قابل فهمی داشته باشن نوشته میشن و یه سری دیگه به هدف پرفورمنس و کاربردی بودن و ... شروع کردن از اونایی که سورس کد مرتب تر و سادهتری دارن قطعا توصیه میشه. مخصوصا اگه ایدهی کلی از اون سیستمی که پیادهسازی میشه نداریم. مثلا اگه نمیدونیم سیستمعامل چطوری کار میکنه بهتره اول کتاب در موردش بخونیم. بعد یه کتاب یا منبعی که سورسکد رو توضیح داده بخونیم (یا همین مینیکس که سورس کد ساده و با کامنتی داره). و در نهایت میتونیم (شاید بتونیم) سورس کد یه سیستمعامل واقعی رو بخونیم.
۵- خوندن کد خیلی وقتا مثل کتاب نیست که از اول شروع کنیم تا آخر بریم، بلکه به شکل چرخیدن تو یه جنگل بزرگه. میچرخیم و جاهای جالبش رو نگاه میکنیم. مثلا همین که فایل cgroupش رو باز میکنیم. گاهی هم سعی میکنیم ساختارمندتر کار کنیم مثلا main رو باز میکنیم و از اونجا میریم جلو. (البته اگه mainی در کار باشه!)
۶- (شاید نظر نامحبوب) خیلی وقتا نیازی نیست همهی کد رو خونده باشیم یا حتی فهمیده باشیم تا بتونیم یه contributionی انجام بدیم. برای انجام یه تغییر کافیه بدونیم کلیت داستان چیه (مثلا main چطوری کار میکنه، قسمتی که کد من رو کال میکنه چطوریه و معماری و پوشهبندی کلی چطوریه) و تغییرمون رو در جای درستش اعمال کنیم. مثلا اگه میخوایم کوئری بهینهتری برای دیتابیس بنویسیم خیلی وقتا نیاز نیست که بدونیم تو dockerfile چه خبره یا مثلا تو http handler دقیقا چه اتفاقی میافته. یا در مثال لینوکسش، اگه میخوایم در مورد cgroup بیشتر بدونیم قاعدتا نیاز نیست در مورد درایورهای گرافیک چیز زیادی بدونیم. مخصوصا اگه معماری کد خوب باشه و الکی چیزا رو به هم متصل نکرده باشه.
👍22
Forwarded from مکشوفات علیز
خوندن کدهای سطح پایین خیلی سختتر از چیزیه که آدم فکرش رو میکنه. بعضی اوقات لاجیکهای سخت. پیچیدگیهای ساختاری زیاد. و استفاده کردن از تمام ظرفیت زبان به بهترین سکل ممکن برای گرفتن بیشترین پرفورمنس.
امروز کلا بحث runC بود. از docker و containerd شروع شد. و در نهایت من کل روز رو صرف خوندن همین یک دونه فایل در کرنل کردم. cgroup. سعی کردم یه شهود کلی بگیرم. یه سری پیچیدگیها رو از فهمیدنشون دست کشیدم ولی خب واقعا مفید بود. برای بار هزارم درود بر torvalds.
امروز کلا بحث runC بود. از docker و containerd شروع شد. و در نهایت من کل روز رو صرف خوندن همین یک دونه فایل در کرنل کردم. cgroup. سعی کردم یه شهود کلی بگیرم. یه سری پیچیدگیها رو از فهمیدنشون دست کشیدم ولی خب واقعا مفید بود. برای بار هزارم درود بر torvalds.
👍14
Forwarded from Things that I like (Maedeh)
سایتی که راه حل مسائل مختلف به زبان های مختلف رو قرار داده:
https://rosettacode.org/wiki/Rosetta_Code
https://rosettacode.org/wiki/Rosetta_Code
Rosetta Code
Rosetta Code is a programming chrestomathy site. The idea is to present solutions to the same task in as many different languages as possible, to demonstrate how...
👍10🤡1
این مطلب به زبان ساده توضیح میده jwt چیه و چه کاربردی داره و چطوری کار میکنه.
https://dev.to/manav-1011/jwt-explained-19o6
https://dev.to/manav-1011/jwt-explained-19o6
DEV Community
JWT Explained
If you are a web developer or a student studying web development you must have heard of the term JWT....
❤9
دوست دارید به ویم سوییچ کنید ولی بار اول و دوم ناامید شدید؟
این دوستمون هم همینطور ولی بلاخره به cool kids club پیوست.
https://emanuelcepoi.com/preview/66785dd2d3170dd0332a47d9
این دوستمون هم همینطور ولی بلاخره به cool kids club پیوست.
https://emanuelcepoi.com/preview/66785dd2d3170dd0332a47d9
😁8👍1