با tmux خیلی هامون آشنا هستیم. یه terminal multiplexer قدیمی و خفن.
ولی متاسفانه کار باهاش یه مقداری سخته و راه دست نیست.
یه جایگزین خوب براش با rust نوشتن که البته هنوز در حالت بتا است ولی مشکل خاصی نداره.
اسمش zellij‌ئه.
سایتش:
https://zellij.dev/


صفحه گیتهابش:
https://github.com/zellij-org/zellij

و صفحه معرفیش:
https://www.linuxuprising.com/2021/04/zellij-is-new-terminal-multiplexer.html

البته توی این معرفی هنوز تازه اومده و بتا است. الان بالغ تر شده.

دوست دارید توی ترمینال اسکرین‌سیور زیبا داشته باشید؟
می‌تونید از pipes.sh استفاده کنید.
https://github.com/pipeseroni/pipes.sh

نتیجه می‌شه یه چنین چیزی که همیشه هم پویاست و داره شکل‌های قشنگ جدید تولید می‌کنه!

اگر میخواهید یه پروژه رو کلون کنید و حجمش زیاده، میتونید برای بهینه سازی، دو تا کار کنید:
۱- فقط کامیت آخر رو دانلود کنید، مثلا اگر می‌خواهیم فقط برنامه رو از سورس دانلود کنید و با تاریخچه‌اش کاری نداریم منطقیه.
۲- فقط برنچ اصلی (master یا main) رو دانلود کنید چون احتمالا با باقی برنچ‌ها کاری نداریم.

دستورش چی میشه؟
git clone --branch master --depth 1 https://github.com/neovim/neovim.git

با حمایت کردن، خیلی خیلی برای ادامه‌ی کار بهم انرژی میدید :
https://www.coffeete.ir/alimoeinian

مرسی از همگی ❤️

خیلی از زبون‌ها رو می‌شنویم که از llvm استفاده می‌کنن؟
این چی بود اصلا که همه کامپایلرها رو گرفت؟

ماجرا از اینجا شروع می‌شه که کامپایلرها باید برای کامپایل کردن یک فایل از زبون مبدا (مثلا راسط) به زبان ماشین، این عملیات رو انجام بدن:
۱- خوندن کیلدواژه به کلیدواژه‌ی سورس‌کد مبدا
۲- پارس کردن ساختار‌های مختلف با کمک کلیدواژه‌ها (parsing خیلی مفصله ماجراش و الگوریتم‌های متنوعی داره که باشه برای بعد)
۳- بررسی اینکه این کدی که نوشته شده چیه، مثلا تایپ‌هاش درست هستن؟ معنی میده اصلا؟ بهینه‌سازی‌ای نیاز نداره و اینا.
۴- تبدیل کد ماشین

حالا این تبدیل کد ماشین رو ما خیلی ساده می‌گیم ماشین اما کدوم ماشین؟ x86؟ arm؟ پس فردا risc-v و mips چی؟ بعد هر کدوم از اینا نسخه دارن و instruction مختلفی بهشون اضافه می‌شه. اینکه فقط بخوایم یه کدی تولید کنیم شاید خیلی سخت نباشه ولی بهینه‌ کردنش و اطمینان از اینکه درست کار می‌کنه و پشتیبانی از معماری پردازنده‌های مختلف واقعا کار سختیه. این کار سخت رو مثلا کامپایلر GCC خودش انجام میده.

اما همه‌ی کامپایلرها اینطور کار نمی‌کنن. مثلا جاوا یک رویکرد تقریبا منحصر به فرد پیش گرفت. گفت من کامپایلرم نمی‌تونه کد به هر پلتفرم مقصدی تولید کنه، بلکه میام یه «کد میانی» تولید می‌کنم به اسم byte code. یعنی چی؟ یعنی این کد میانی یه جور کد ماشینیه که واقعا هیچ ماشینی بلد نیست اجراش کنه، یه اسمبلیه برای یک پردازنده‌ی فرضی. مزیتش برای کامپایلر اینه که فقط لازمه دغدغه‌ش این باشه که همین رو تولید کنه و همین رو بهینه کنه.
اما در مرحله‌ی بعد چه کسی اینو اجرا کنه؟ مجبوریم یه VM (به اسم JVM یا java virtual machine) دااشته باشیم که اون بایت‌کد رو می‌گیره و ترجمه می‌کنه به زبان ماشین و همونجا هم اجراش میکنه. مثلا JVM برای پردازنده‌ی x86 و الی آخر.
جای تعجب نداره که جاوا اونقدر نمی‌تونه سریع باشه چون این JVM به هر حال سربار داره، هرچقدر هم بهینه‌ش کنن چون به هر حال داره ترجمه‌ای رو انجام می‌ده.

اما حالا فرض کنید که کامپایلر ما همون کار راحت تولید یه bytecode رو انجام می‌داد، اما به جای اینکه خود byte code رو بدیم به ملت و اونجا مجبور باشن VM نصب کنن، این bytecode رو یکی تبدیل می‌کرد به کد ماشین و بهینه‌ش هم میکرد. خب llvm همینجا وارد می‌شه!
یعنی چی؟ یعنی به کامپایلر راسط میگه شما لازم نیست خودت کد اسمبلی/زبان ماشین تولید کنی، بلکه بیا LLVM IR یا LLVM intermediate representation تولید کن. من اینو تبدیل می‌کنم به کد ماشین بهینه!
و اینجا یه مفهوم front-end و back-endی هم شکل می‌گیره. فرانت‌اند به قسمتی که سورس‌کد رو می‌خونه و پارس می‌کنه و ... تا IR تولید بشه میگن و بک اند میشه قسمتی که IR رو می‌خونه و پردازش می‌کنه و کد ماشین تولید می‌کنه. LLVM برای ما نقش یک بک‌اند رو داره.

حالا سینتکس LLVM IR چه شکلیه؟ خیلی برامون مهم نیست ولی می‌تونیم ببینیمش. مثلا به clang بگیم که به جای تولید کد ماشین نهایی، برامون LLVM IR رو خروجی بده. می‌تونه این کارو بکنه. حتما حدس می‌زنید که clang یه کامپایلر بر پایه‌ی llvmئه که این قابلیت رو داره.

clang -S -emit-llvm foo.c

با کمک این دستور می‌تونید IR رو مشاهده کنید و حتی می‌تونید با کمک llvm اجراش کنید. با دستور lli یا llvm interpreter می‌تونید به شکل تفسیری اجراش کنید یا با llc کامپایلش کنید.


اما llvm باز هم کار ما رو ساده‌تر می‌کنه، به جای اینکه از فرانت‌اند بخواد که یکجا بهش IR رو تحویل بده، میاد از visitor design pattern استفاده می‌کنه. خلاصه‌ش اینطوریه که به جای اینکه نهایتا خروجی IR رو ازمون بگیره،‌ در روال ساختش هم مشارکت می‌کنه. مثلا میگه تو می‌دونی که یه تابع داری ولی محتواش رو هنوز نخوندی؟ عیب نداره تا همینجا به من بگو من برات می‌سازم. خب یه if توش داری؟ من داخل تابع اضافه‌ش می‌کنم. و الی آخر. برای اینکه از این قابلیت استفاده کنیم لازم داریم که توابعی که llvm داره مثلا برای ساخت تابع، داخل فرانت‌اندمون صدا کنیم. اینجا یه مشکلی که داریم اینه که به شکل پیش‌فرض کتاب‌خونه‌ش فقط برای cpp وجود داره، که البته چون خیلی از کامپایلرها با cpp هستن برامون کافیه. ولی همچنین یکسری binding (غیررسمی) برای باقی زبون‌ها هم وجود داره مثلا کامپایلر haskell و rust از همین binding ها استفاده می‌کنن چون کامپایلرشون به ترتیب با haskell و rust نوشته شده.

پس به عنوان جمع‌بندی: حالا که rust و هسکل به عنوان بک‌اند از llvm استفاده می‌کنن چه مزایایی داره براشون؟
+ اگه پردازنده‌ی جدیدی بیاد و بخوان ساپورتش کنن، کافیه صبر کنن تا llvm اون رو ساپورت کنه و بعدش دیگه خیلی کاری ندارن.
+ اگر امکان بهینه‌سازی جدیدی توی یک پردازنده یا به شکل عمومی ابداع بشه، کافیه که توی llvm پیاده‌سازی بشه و بعدش دیگه نیاز نیست فرانت‌اند تغییر خاصی بکنه.
+ اگر می‌خوان به زبونشون قابلیت جدید اضافه کنن لازم نیست نگران این باشن که چطوری کد اسمبلیش توی پلتفرم‌های مختلف چطوری می‌شه، بلکه فقط کافیه بتونن کد LLVM IR معادلشو بسازن که چون خیلی چیزها رو خودش پشتیبانی می‌‌کنه کار خیلی ساده‌تریه.

شاید بپرسید که کامپایلر هسکل که قدیمی‌تر از این حرفاس، چطوری خودش بک‌اند نداشت و منتظر llvm بود. اتفاقا خودش هم بک‌اند داشت و هنوزم امکان code generation داره ولی امکان تولید کد با llvm هم اضافه شده و برنامه‌نویس می‌تونه کدی که براش بهینه‌تره رو انتخاب کنه.

در کنار اینجا llvm قابلیت پیاده‌سازی بهینه‌سازی متنوعی هم می‌ده مثل JIT یا transform passes که من خیلی بلد نیستم!

اگر دوست داشتید با ساختار LLVM IR بیشتر آشنا بشید این اسلایدهای خیلی جالب رو بهتون توصیه می‌کنم.

https://llvm.org/devmtg/2019-04/slides/Tutorial-Bridgers-LLVM_IR_tutorial.pdf

اگر به LLVM علاقه‌مند شدید این کورس کوتاه می‌تونه براتون جذاب باشه. البته خودش تبلیغ می‌کنه که دوره‌های دیگرش مثل parsing هم ببینید ولی به نظرم نیازی نیست و خود همین ویدیوها زیبا و جذاب و گویان.
https://www.youtube.com/watch?v=Lvc8qx8ukOI

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

راهنمایی: اگر تو خونه چوب صاف ندارید، با لوله ی جاروبرقی، دسته‌ی تی یا دسته‌ی جارو دستی اگر قابل جدا شدن از سرش باشن میتونید انجام بدید.

یکی از سایت هایی که تجربه‌های کاری و مصاحبه رو از شرکت‌ها قرار میده «تجربه ویکی»ئه.
سایت خوبیه و دیتابیس نسبتا خوبی هم از شرکت ها داره ولی UX بد متاسفانه.

اگه به فکر انتخاب شرکت هستید چک کنید به نظرم.
https://tajrobe.wiki/

تا حدی #فان :
تکنیک های معلمی، برای پاسخ یه سوالی که پاسخشو بلد نیستیم:
+ یک خاطره نسبتا مرتبط یا حتی بی‌ربط بگیم
+ وانمود کنیم سوال رو متوجه نشدیم و یه چیز دیگه رو جواب بدیم.
+ بگیم اگه درست گوش میکردی متوجه میشدی. یا حتی بابت این ازش نمره کم کنیم!
+ به خود سوال کننده تکلیف بدیم که بره برای جلسه بعد اون رو پیدا کنه و ارائه بده!
+ قسمت آخر درس رو دوباره توضیح بدیم و بعد بگیم متوجه شدی؟
+ بگیم این اتفاقا یه موضوع داغ تحقیقاتی/صنعتیه. اگه دوست داشتی خودت جست و جو کن در موردش.
+ بگیم چون درس ما درس خیلی وسیعیه، جواب سوال شما توی بحث فلان قرار می‌گیره که جزو مبحث ما نیست.
+ بگیم سوال خوبیه، نظر خودت چیه؟ نظر بقیه دوستان چیه؟

باز بیخوابی زده به سرمون، ساعت ۶:۳۰ هم باید برم سمت دانشگاه،

بیاید یه روش بگم بهتون شاید به کارتون بیاد،

اگر یه فایلی رو میخواید دانلود کنید، تحریمه/فیلتره/دانلود کنده، از colab سیو کنیدش داخل گوگل درایوتون، بعد از گوگل درایوتون دانلودش کنید.

اینجوری که میرید داخل گوگل کولب، یه نوت‌بوک جدید میسازید، یه code cell درست می‌کنید،
بعدش گوگل درایو خودتون رو mount می‌کنید.

بعدشم توی سل می‌نویسی
!wget file-link -P /content/drive/MyDrive

جای فایل لینک، لینکتون رو بزارید، کنترل اینتر رو بزنید، فایل سیو میشه توی گوگل درایوتون.


این قسمتم برای mount کردن درایوه،
قبل از خط خود wget بزاریدش

from google.colab import drive
drive.mount('/content/drive')

دوست دارید بدونید چه برنامه‌ای از سیستمتون داره چقدر شبکه مصرف می‌کنه؟
این برنامه براش شماست:
bandwhich
Terminal bandwidth utilization tool


صفحه گیتهابش:
https://github.com/imsnif/bandwhich

Bash Notes For Professionals

یکی از فوق العاده ترین کتاب ها توی زمینه بش که محتواش از مستندات Stack Overflow جمع آوری شده.

این کتاب به قدری باحال نوشته شده که صفحه استارتشو اگه یه نگاه بندازید ؛ دیگه تمومه تبریک میگم یه بش کار شدید...

🐧 @Linuxor

هوش مصنوعی خیلی کارها رو می‌تونه انجام بده، ولی برنامه نویسی جزوشون نیست!
این مطلب رو خیلی دوست داشتم (شاید چند خودم باهاش موافقم!)،
یه chatgpt با gpt4 برداشته و باهاش سعی کرده یه کد binary search رو درست کنه.
چیزی که نهایتش میگه اینه که این مدل های بزرگ زبانی کاری که خوب بلدن کلمه ساختن و حرافیه، نه استدلال اما برنامه نویسی به استدلال نیاز داره. ما کد تقریبا درست با ظاهر درست نمی‌خوایم، کد دقیقا درست میخوایم.
https://m-cacm.acm.org/blogs/blog-cacm/273577-ai-does-not-help-programmers/fulltext

چطور یه توسعه‌دهنده‌ی منفی ۱۰ ایکس باشیم؟!
یعنی کار ۱۰ نفر دیگر را هم از بین ببریم.

با دنبال کردن این bad practice ها:
https://taylor.town/-10x

در مورد shebang یا همون #! که اول اسکریپت‌ها میاد، هرچیزی که لازمه بدونیم توی یک مطلب:

https://dev.to/meleu/what-the-shebang-really-does-and-why-it-s-so-important-in-your-shell-scripts-2755

Rejection of your paper or grant has NO relevance to the opinion of #research community. It is nothing but the opinion of one person. Several examples:

1. The first paper on graphene was rejected from Nature because “it did not constitute a sufficient scientific advance”. Later, it was awarded a Nobel prize.


2. The first manuscript showing the microbiome-brain connection was published after 7 submissions that took 3 years. Today, this field has exploded. I expect it will get a Nobel prize in the future.


3. Theodore Maiman tried to publish a paper describing the first operating laser in Physical Review Letters and… got a rejection!


4. Peter Ratcliffe, who worked on cells’ response to changes in oxygen levels, got his key paper rejected from Nature (see photo). Later, he was awarded a Nobel Prize for this work.

And there are many other examples…

And yet I see so many young scientists stressing about rejections. For some reason, they seem to genuinely expect that the editors should know which study is truly worth it.

As a result, many rejections are met with surprise and disbelief:  “How could they reject it? They publish so much trash, and yet they think our detailed 3-year-long study is not interesting to the community! WHY?” Well, the truth is: - Most editors have very little time to delve into your study. They can easily FAIL to recognize the potential impact of your study.

Proper communication in the cover letter and clear writing style can help (although only to a limited degree). - Many reviewers have little idea about the #science in your paper. But they can have a big ego. So, if they have a bad day or were rejected recently, it’s easy for them to find 1000 technical reasons to reject your paper as well. - Most scientists genuinely don’t know if your discovery can make any impact. If we could predict the course of science, we would be living very differently! My message is simple: Forget about objectivity. #Academia is a very subjective world. Fight for objectivity but don’t take it for granted.

A great study will be found, cited and recognized. Disregard of where it’s published. A bad study requires a high-impact journal to be found and cited. But the long-time recognition might be a problem. High-IF journals are simply billboards.

Their rejections do NOT represent the opinion of a scientific community. Believe in your results.

Src:
https://www.linkedin.com/posts/andrew-akbashev_research-science-academia-activity-7071492551018475520-AC-c

@professional_Researchers

توی OpenOffice یه باگی بوده که سه‌شنبه‌ها فایل‌ها رو پرینت نمی‌گرفته!

اما داستان چی بوده؟ موقع پرینت توی فایل postscriptی که می‌ساخته، زمان ساخت فایل رو هم اضافه می‌کرده،
بعد زمانی که دستور file می‌خواسته نوع فایل رو تشخیص بده، به جای postscript که واقعا بوده، Erlang jam file تشخیص می‌داده.


پی‌نوشت: دستور file کارش اینه که روی یک فایل اجراش می‌کنیم و تشخیص میده جنس فایل چیه. با وجود صدها پترنی که برای فایل‌های مختلف وجود داره قابل پیش‌بینی هم هست که بعضی وقتا این مشکلات پیش بیاد.

بیشتر بخوانید:
https://beza1e1.tuxen.de/lore/print_on_tuesday.html

ریپورت باگ روی OpenOffice:
https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161/comments/28

ریپورت باگ روی file:
https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619