اگه دوست دارید در مورد کرنل لینوکس و زمان بندها و 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.
یه مطلب خوب در مورد معرفی وب اسمبلی
https://vrgl.ir/g268k
https://vrgl.ir/g268k
ویرگول
کنجکاوی در مورد Web Assembly - ویرگول
چیزایی که این مدت از WASM خونده بودم رو توی این پست جمع کردم.
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/
به بهانهی این مطلب چند تا نکته در مورد خوندن کد بگم:
۱- خوندن کد خوبه و هر کدی هم باشه کلا خوبه. مثل کتاب خوندن. از نظر من کد خوندن مثل رمان و کتاب خوندنه.
۲- با خوندن کد بیشتر و بهتر، کدهای بهتری هم خواهید نوشت. یادگیری دیزاین پترن و اصول کد تمیز خوبه ولی دیدن اینکه در عمل چه چیزی باعث خوب شدن کد میشه یه چیز دیگهست و اگه کد بخونید از بقیه جلو میافتید.
۳- همونطور که وقتی الفبا رو یاد گرفتیم نمیشه انتظار داشت که آثار شکسپیر رو بخونیم، قاعدتا اگه اولین کدی که میخونیم کد لینوکس باشه، خیلی چیزاشو متوجه نمیشیم. میشه اول از چیزهای سادهتر شروع کرد.
۴- یه سری پروژهها (مثلا minix) به هدف اینکه سورس کد قابل فهمی داشته باشن نوشته میشن و یه سری دیگه به هدف پرفورمنس و کاربردی بودن و ... شروع کردن از اونایی که سورس کد مرتب تر و سادهتری دارن قطعا توصیه میشه. مخصوصا اگه ایدهی کلی از اون سیستمی که پیادهسازی میشه نداریم. مثلا اگه نمیدونیم سیستمعامل چطوری کار میکنه بهتره اول کتاب در موردش بخونیم. بعد یه کتاب یا منبعی که سورسکد رو توضیح داده بخونیم (یا همین مینیکس که سورس کد ساده و با کامنتی داره). و در نهایت میتونیم (شاید بتونیم) سورس کد یه سیستمعامل واقعی رو بخونیم.
۵- خوندن کد خیلی وقتا مثل کتاب نیست که از اول شروع کنیم تا آخر بریم، بلکه به شکل چرخیدن تو یه جنگل بزرگه. میچرخیم و جاهای جالبش رو نگاه میکنیم. مثلا همین که فایل cgroupش رو باز میکنیم. گاهی هم سعی میکنیم ساختارمندتر کار کنیم مثلا main رو باز میکنیم و از اونجا میریم جلو. (البته اگه mainی در کار باشه!)
۶- (شاید نظر نامحبوب) خیلی وقتا نیازی نیست همهی کد رو خونده باشیم یا حتی فهمیده باشیم تا بتونیم یه contributionی انجام بدیم. برای انجام یه تغییر کافیه بدونیم کلیت داستان چیه (مثلا main چطوری کار میکنه، قسمتی که کد من رو کال میکنه چطوریه و معماری و پوشهبندی کلی چطوریه) و تغییرمون رو در جای درستش اعمال کنیم. مثلا اگه میخوایم کوئری بهینهتری برای دیتابیس بنویسیم خیلی وقتا نیاز نیست که بدونیم تو dockerfile چه خبره یا مثلا تو http handler دقیقا چه اتفاقی میافته. یا در مثال لینوکسش، اگه میخوایم در مورد cgroup بیشتر بدونیم قاعدتا نیاز نیست در مورد درایورهای گرافیک چیز زیادی بدونیم. مخصوصا اگه معماری کد خوب باشه و الکی چیزا رو به هم متصل نکرده باشه.
۱- خوندن کد خوبه و هر کدی هم باشه کلا خوبه. مثل کتاب خوندن. از نظر من کد خوندن مثل رمان و کتاب خوندنه.
۲- با خوندن کد بیشتر و بهتر، کدهای بهتری هم خواهید نوشت. یادگیری دیزاین پترن و اصول کد تمیز خوبه ولی دیدن اینکه در عمل چه چیزی باعث خوب شدن کد میشه یه چیز دیگهست و اگه کد بخونید از بقیه جلو میافتید.
۳- همونطور که وقتی الفبا رو یاد گرفتیم نمیشه انتظار داشت که آثار شکسپیر رو بخونیم، قاعدتا اگه اولین کدی که میخونیم کد لینوکس باشه، خیلی چیزاشو متوجه نمیشیم. میشه اول از چیزهای سادهتر شروع کرد.
۴- یه سری پروژهها (مثلا minix) به هدف اینکه سورس کد قابل فهمی داشته باشن نوشته میشن و یه سری دیگه به هدف پرفورمنس و کاربردی بودن و ... شروع کردن از اونایی که سورس کد مرتب تر و سادهتری دارن قطعا توصیه میشه. مخصوصا اگه ایدهی کلی از اون سیستمی که پیادهسازی میشه نداریم. مثلا اگه نمیدونیم سیستمعامل چطوری کار میکنه بهتره اول کتاب در موردش بخونیم. بعد یه کتاب یا منبعی که سورسکد رو توضیح داده بخونیم (یا همین مینیکس که سورس کد ساده و با کامنتی داره). و در نهایت میتونیم (شاید بتونیم) سورس کد یه سیستمعامل واقعی رو بخونیم.
۵- خوندن کد خیلی وقتا مثل کتاب نیست که از اول شروع کنیم تا آخر بریم، بلکه به شکل چرخیدن تو یه جنگل بزرگه. میچرخیم و جاهای جالبش رو نگاه میکنیم. مثلا همین که فایل cgroupش رو باز میکنیم. گاهی هم سعی میکنیم ساختارمندتر کار کنیم مثلا main رو باز میکنیم و از اونجا میریم جلو. (البته اگه mainی در کار باشه!)
۶- (شاید نظر نامحبوب) خیلی وقتا نیازی نیست همهی کد رو خونده باشیم یا حتی فهمیده باشیم تا بتونیم یه contributionی انجام بدیم. برای انجام یه تغییر کافیه بدونیم کلیت داستان چیه (مثلا main چطوری کار میکنه، قسمتی که کد من رو کال میکنه چطوریه و معماری و پوشهبندی کلی چطوریه) و تغییرمون رو در جای درستش اعمال کنیم. مثلا اگه میخوایم کوئری بهینهتری برای دیتابیس بنویسیم خیلی وقتا نیاز نیست که بدونیم تو dockerfile چه خبره یا مثلا تو http handler دقیقا چه اتفاقی میافته. یا در مثال لینوکسش، اگه میخوایم در مورد cgroup بیشتر بدونیم قاعدتا نیاز نیست در مورد درایورهای گرافیک چیز زیادی بدونیم. مخصوصا اگه معماری کد خوب باشه و الکی چیزا رو به هم متصل نکرده باشه.
Forwarded from مکشوفات علیز
خوندن کدهای سطح پایین خیلی سختتر از چیزیه که آدم فکرش رو میکنه. بعضی اوقات لاجیکهای سخت. پیچیدگیهای ساختاری زیاد. و استفاده کردن از تمام ظرفیت زبان به بهترین سکل ممکن برای گرفتن بیشترین پرفورمنس.
امروز کلا بحث runC بود. از docker و containerd شروع شد. و در نهایت من کل روز رو صرف خوندن همین یک دونه فایل در کرنل کردم. cgroup. سعی کردم یه شهود کلی بگیرم. یه سری پیچیدگیها رو از فهمیدنشون دست کشیدم ولی خب واقعا مفید بود. برای بار هزارم درود بر torvalds.
امروز کلا بحث runC بود. از docker و containerd شروع شد. و در نهایت من کل روز رو صرف خوندن همین یک دونه فایل در کرنل کردم. cgroup. سعی کردم یه شهود کلی بگیرم. یه سری پیچیدگیها رو از فهمیدنشون دست کشیدم ولی خب واقعا مفید بود. برای بار هزارم درود بر torvalds.
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...
این مطلب به زبان ساده توضیح میده 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....
دوست دارید به ویم سوییچ کنید ولی بار اول و دوم ناامید شدید؟
این دوستمون هم همینطور ولی بلاخره به cool kids club پیوست.
https://emanuelcepoi.com/preview/66785dd2d3170dd0332a47d9
این دوستمون هم همینطور ولی بلاخره به 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://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/en/thing_35
97-things-every-x-should-know.gitbook.io
The Golden Rule of API Design | 97 Things Every Programmer Should Know
چطور به عنوان یک دولوپر، مراقب چشمهامون باشیم؟
https://mykola-harmash.medium.com/developer-tip-to-save-your-eyes-f83135baa64c
https://mykola-harmash.medium.com/developer-tip-to-save-your-eyes-f83135baa64c
Medium
Developer Tip to Save Your Eyes
This may seem a bit controversial, but I want to encourage you to fit less information on a screen. As we are, developers, often tend to do…
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Things that I like (Maedeh)
فرق clang و gcc چیه؟
https://www.incredibuild.com/blog/gcc-vs-clang-battle-of-the-behemoths
https://www.incredibuild.com/blog/gcc-vs-clang-battle-of-the-behemoths
incredibuild
GCC vs Clang: Battle of the Behemoths - incredibuild
This blog post should help you understand the major differences considering GCC Vs Clang. Both are excellent software but there are differences to discuss.
نوشتههای ترمینالی
اگه با گیت کار میکنید احتمالا دستورهای اولیه تو ذهنتون هست مثل add commit push pull که خیلیم خوبه. ولی یه سری دستورها اضافه شدن که کار رو راحت کنن. مثلا چون با checkout و reset کارهای خیلی متفاوتی میشه انجام داد، در نسخههای جدید switch و restore رو معرفی…
در مورد دستور git restore که یکی از دستورهای جدید گیت و به نوعی جایگزین برخی قابلیت های checkout و reset هست بیشتر بخونیم:
https://www.git-tower.com/learn/git/commands/git-restore
https://www.git-tower.com/learn/git/commands/git-restore
Git-Tower
git restore - Discard or unstage uncommitted local changes
Learn how to use the 'git restore' command to unstage or even discard uncommitted local changes.
Forwarded from Quera
Media is too big
VIEW IN TELEGRAM
➖➖➖
#Quera #QBC8 #Golang #snapp #gopher
#بوت_کمپ
#برنامه_نویسی
#گولنگ
Please open Telegram to view this post
VIEW IN TELEGRAM
نوشتههای ترمینالی
برای ثبت نام این دوره اگه خواستین با ده درصد (برای فقط ۵ نفر متاسفانه) ثبت نام کنید از این کد تخفیف استفاده کنید.
RSHQBC8
RSHQBC8
چه ایمجی برای استفاده در پروداکشن خوبه؟
آیا باید از دیسترو ها استفاده کنیم یا ایمج scratch هم جواب میده؟
https://sam.gleske.net/blog/engineering/2022/10/25/guide-to-production-docker-images.html
آیا باید از دیسترو ها استفاده کنیم یا ایمج scratch هم جواب میده؟
https://sam.gleske.net/blog/engineering/2022/10/25/guide-to-production-docker-images.html
sam.gleske.net
Guide to production docker images
خیلی وقتا برای ما پیش میاد که تو یه برنچی کار میکنیم که میخوایم با main/master مرجش کنیم ولی کس دیگهای اول مرج میکنه برنچشو و ما conflict میخوریم.
حالا وقتی میخوایم کانفلیکتها رو حل کنیم میتونیم برنچ main رو با برنچ خودمون merge کنیم یا برنچ خودمون رو rebase کنیم به main جدید.
اینکه کدومش خوبه کدومش نه، جوابش بستگی دارهس!
تو تیمهایی که جونیور زیاد دارن توصیه میشه مرج کنید و تموم. اینطوری تاریخچه پیچیدهتری دارید (چون چرا یهو main تو یه برنچ مرج شده) ولی مجیک خاصی اتفاق نمیافته.
از طرفی rebase باعث میشه که یه تاریخچه شبیهسازی شده و جدید به وجود بیاد که توش کامیتهای برنچ جدید شما انگار بعد از آخرین کامیت main به وجود اومدن! برای کسی که بعدا نگاه کنه فهمش راحت تره ولی نکته اینه که چنین چیزی اصلا وجود نداشته و ممکنه مشکل لاجیکی تو کد ایجاد کنه.
تو این ویدیو این بحث رو خیلی خوب در قالب یه مکالمه توضیح دادن. توصیه میکنم ببینید.
https://www.youtube.com/watch?v=7gEbHsHXdn0
حالا وقتی میخوایم کانفلیکتها رو حل کنیم میتونیم برنچ main رو با برنچ خودمون merge کنیم یا برنچ خودمون رو rebase کنیم به main جدید.
اینکه کدومش خوبه کدومش نه، جوابش بستگی دارهس!
تو تیمهایی که جونیور زیاد دارن توصیه میشه مرج کنید و تموم. اینطوری تاریخچه پیچیدهتری دارید (چون چرا یهو main تو یه برنچ مرج شده) ولی مجیک خاصی اتفاق نمیافته.
از طرفی rebase باعث میشه که یه تاریخچه شبیهسازی شده و جدید به وجود بیاد که توش کامیتهای برنچ جدید شما انگار بعد از آخرین کامیت main به وجود اومدن! برای کسی که بعدا نگاه کنه فهمش راحت تره ولی نکته اینه که چنین چیزی اصلا وجود نداشته و ممکنه مشکل لاجیکی تو کد ایجاد کنه.
تو این ویدیو این بحث رو خیلی خوب در قالب یه مکالمه توضیح دادن. توصیه میکنم ببینید.
https://www.youtube.com/watch?v=7gEbHsHXdn0
YouTube
You only Git Merge?!? feat Theo : DevHour #1
Theo is a former twitch (5 years) and now currently runs ping.gg where he codes amazing software for streamers. We debate the pros and cons of git rebase vs git merge
### Finding Theo
https://twitter.com/t3dotgg
https://twitch.tv/Theo
https://www.youtu…
### Finding Theo
https://twitter.com/t3dotgg
https://twitch.tv/Theo
https://www.youtu…
در کنار مهندس نرمافزار و DevOps و SRE
خوبه بدونیم platform engineer چیه و چه کاری میکنه.
https://platformengineering.org/blog/what-is-platform-engineering
خوبه بدونیم platform engineer چیه و چه کاری میکنه.
https://platformengineering.org/blog/what-is-platform-engineering
platformengineering.org
What is platform engineering?
Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era. Platform engineers provide an integrated product most often referred…
آیا گوشی هوشمند ما به ما گوش میکنه؟
احتمالا بله.
https://news.itsfoss.com/ad-company-listening-to-microphone/
(یه مقدارم عنوانش کلیخور و زرده ولی حالا ببینیدش ضرر نداره)
احتمالا بله.
https://news.itsfoss.com/ad-company-listening-to-microphone/
(یه مقدارم عنوانش کلیخور و زرده ولی حالا ببینیدش ضرر نداره)
It's FOSS News
This Company Says It Uses Your Phone's Mic to Serve Ads for Facebook, Google, and More
Creepy behavior confirmed.
Forwarded from Geek Alerts
امروز، ۹ سپتامبر، سالروز تولد دنیس ریچی است.
دنیس مکآلیستر ریچی، دانشمند کامپیوتر آمریکایی بود که بیشتر به عنوان خالق زبان برنامهنویسی C و مشارکتهای زیادش در توسعه و خلق سیستمعامل یونیکس به همراه کن تامسون، شناخته میشه. ریچی و تامسون در سال ۱۹۸۳ جایزه تورینگ که ارزشمندترین جایزه در حوزه علوم کامپیوتر هست رو به دلیل پیادهسازی یونیکس میگیرن. دنیس ریچی همچنین در سال ۱۹۹۹ مدال ملی فناوری رو توسط رییسجمهور وقت آمریکا، کلینتون دریافت میکنه. جسد ریچی در ۱۲م اکتبر ۲۰۱۱ در سن هفتادسالگیاش در خونهاش که به تنهایی در اون زندگی میکرد پیدا شد. هیچگاه زمان دقیق مرگ دنیس مشخص نشد. اعلام فوت ریچی یک هفته بعد از مرگ استیو جابز بود اما پوشش رسانهای قابل توجهای در مقایسه با جابز براش ایجاد نشد. امروز ۸۳مین سالروز تولد دنیس هست. بدون مشارکتهای او، احتمالاً هیچ کدوم از ما نمیتونستیم به شکل کنونی از کامپیوترها، نرمافزارهای پیچیده یا حتی اینترنت مدرن استفاده کنیم.
https://en.wikipedia.org/wiki/Dennis_Ritchie
hadi @geekalerts
دنیس مکآلیستر ریچی، دانشمند کامپیوتر آمریکایی بود که بیشتر به عنوان خالق زبان برنامهنویسی C و مشارکتهای زیادش در توسعه و خلق سیستمعامل یونیکس به همراه کن تامسون، شناخته میشه. ریچی و تامسون در سال ۱۹۸۳ جایزه تورینگ که ارزشمندترین جایزه در حوزه علوم کامپیوتر هست رو به دلیل پیادهسازی یونیکس میگیرن. دنیس ریچی همچنین در سال ۱۹۹۹ مدال ملی فناوری رو توسط رییسجمهور وقت آمریکا، کلینتون دریافت میکنه. جسد ریچی در ۱۲م اکتبر ۲۰۱۱ در سن هفتادسالگیاش در خونهاش که به تنهایی در اون زندگی میکرد پیدا شد. هیچگاه زمان دقیق مرگ دنیس مشخص نشد. اعلام فوت ریچی یک هفته بعد از مرگ استیو جابز بود اما پوشش رسانهای قابل توجهای در مقایسه با جابز براش ایجاد نشد. امروز ۸۳مین سالروز تولد دنیس هست. بدون مشارکتهای او، احتمالاً هیچ کدوم از ما نمیتونستیم به شکل کنونی از کامپیوترها، نرمافزارهای پیچیده یا حتی اینترنت مدرن استفاده کنیم.
https://en.wikipedia.org/wiki/Dennis_Ritchie
hadi @geekalerts