🎉🎉 سال نو میلادی همگی مبارک.

تو این چند وقتی که C یاد گرفتم خیلی ویدیو های جالب از دو یوتیوبر به خصوص دیدم.
گفتم بزارمشون چون که تو بیشتر زمینه های مربوط به C آموزش دارن.

https://www.youtube.com/@LowLevelLearning
https://www.youtube.com/@JacobSorber

جدا از این دو. آموزش هایی هم از این دو نفر هم دیدم که خیلی خوبن.

https://www.youtube.com/@PortfolioCourses
https://www.youtube.com/@CodeVault

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

یکی از سایت های باحالی که چند وقت دوستان منو باهاش آشنا کردن این بود:

http://quickref.me

ریفرنس و cheatsheet سریع برای کلی زبان های برنامه نویسی، برنامه ها، ابزار های خط فرمان و ...

اخیرا گوگل به علت نقض حریم خصوصی تو حالت incognito دادگاهی شده. اومدن این میمو براش ساختن.

#Meme

ویدیویی مرتبط با این موضوع:

https://www.youtube.com/watch?v=rIWvfL-ecTk

یکی از جالب ترین ویدیو هایی که اخیرا دیدم راجب pipe ها بود.

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

این مفهوم رو داخل bash با همین اسم حتما دیدید (|) علامتی هست که خروجی یک دستور رو داخل ورودی یک دستور دیگه میریزه. این پشت صحنه یه pipe به صورت موقت میسازه و بعد از انجام دستور از بین میبره.

اما ما میتونیم pipe با یه اسم مشخصی درست کنیم و داخل برناممون ازش استفاده کنیم.

https://www.youtube.com/watch?v=dhFkwGRSVGk

تازه این مفهوم بین ویندوز و لینوکس هم مشترکه
https://learn.microsoft.com/en-us/windows/win32/ipc/named-pipes

و اینکه داخل هر زبانی هم این مفهوم قابل پیاده سازی هست. از جمله پایتون.
حتی پایتون هم داخل ماژول multiprocessing از این قابلیت استفاده میکنه.
https://docs.python.org/3/library/multiprocessing.html?highlight=pipe#pipes-and-queues

Parch Linux, what do you think about it? 😇

https://news.itsfoss.com/parch-linux/

سهراب اسم توزیعش از itsfoss سر در آورد.

Just wow...
فکرشم نمیکردم ولی خب شدنی بود قطعا

یکی از چیزایه جالبی که جدیدا دیدم
reverse debugging
بود. به نظرم خیلی مفهوم جالبی هست و میتونه ابزار قدرتمندی باشه وقتی که دیباگر ساده اذیت میکنه.

یه نوع دیباگر خاص که بهت اجازه میده که نه تنها قدم قدم جلو بری.
بلکه چون یه بار برنامه رو ران کرده وضعیتش رو ذخیره کرده و اجازه میده قدم قدم عقب هم بری.
انگار میتونی تو زمان سفر کنی.

https://www.youtube.com/watch?v=eOrpuc89baE

صفحه اصلی پروژه هم هست برای توضیحات بیشتر
https://rr-project.org/

تنها برای C و CPP (و به نظر میاد Rust) ساپورت داره ولی احتمال زیاد برای بیشتر زبان های کامپایلی ساپورت داشته باشه.
ساپورت پایتون نداره تا جایی که میدونم.
و همینطور فقط داخل لینوکس کار میکنه.

نکته جالبی که اخیرا بهش برخوردم قابلیت استفاده از HTML CSS داخل markdown بود. و همین نکته نظرم رو کاملا راجب markdown عوض کرد.

همچنین چیزی خیلی انعطاف میده به فرمت markdown و در نتیجه Joplin که ابزار نوت برداری با markdown هست رو خیلی قوی میکنه.

البته بگم که ساپورت کامل HTML CSS به برنامه هم بستگی داره. بعضی برنامه ها ممکنه یه زیرمجموعه ای از تگ های HTML CSS رو ساپورت کنن.

مثلا Joplin که برنامه نوت برداری هست از تگ button پشتیبانی نمیکنه (چون معقول هم نیست). ولی flexbox راحت میشه ست کرد با CSS هم استایل بندی کرد.

یه ریفرنس آموزشی که خیلی خوب هست و پیشنهاد میکنم اگر میخواید مارکداون یادبگیرید مطالعه کنید.
https://www.markdownguide.org/

Joplin:

مدتی هست که از Joplin برای نوت برداری استفاده میکنم و باید بگم برنامه خیلی خوبی هست. اوپن سورس و بسیار معروف.
از تمام ظرفیت های markdown استفاده میکنه و تفاوت های خیلی جزیی داره.
متاسفانه داخل ادیتور ساپورت فارسیش مشکل داره ولی با یه

<div dir="auto">
</div>

راحت میشه رندرینگش رو درست کرد.
بخش ادیتش هم احتمالا خیلی ساده میشه فیکس کرد اگر web dev باشید.

Disclosure: I am not a web developer.

بهترین بخش این برنامه برای من synchronization به صورت plain text هست. نه دیتابیسی نه چیز دیگه ای.
یعنی عملا میتونی داخل گیت ذخیره کنی و حتی diff هارو هم ببینی. ولی خب یه سری داستان ها داره (خودش هیستوری تغییرات رو هم ذخیره میکنه). ولی در کل همه plaintext هستن.

همین بهم اجازه داده که به جای سرویس ابری از syncthing برای همگام سازی دیتاهام استفاده کنم و اگر به conflict خوردم راحت برم و یه diff بگیرم و حل کنم.

(بزودی syncthing هم معرفی میکنم)

جدا از اون extension های زیادی داره و عملا میتونید قابلیت های جدیدی به joplin اضافه بکنید.
Joplin Enhancement
برای من مهم ترینشون بود که فیچر های خیلی مهمی رو اضافه میکرد.

جدا از اون قابلیت export به PDF و HTML هم دارید که برای ساخت داکیومنت PDF خیلی خوبه.

لینک وبسایت رسمی

#Apps

کسایی که پکیجینگ برای توزیع های مختلف لینوکسی انحام میدن. این حتما بدردتون میخوره. تا حالا خواستید که
make install
رو روی یه مقصد خاصی جز روت بزنید و این همه دنبال makefile یا استراکچر مسیر بیلد نگردید.

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

make DESTDIR=/path/to/dir install

خیلی این کار پکیجینگ رو ساده میکنه.

منبع

#Linux
#Tips

حالا که صحبت از بیلد و make شد. یه ویدیویی هم همین چند وقت پیش داشتم دنبال میکردم.
آموزش cmake که بیشتر برای کاربرای لینوکس تدارک دیده شده. (ولی خب ویندوز کارا هم میتونن ازش استفاده کنن مخصوصا اگر از محیط MSYS2 یا Cygwin برای بیلد استفاده میکنید)

https://www.youtube.com/playlist?list=PLalVdRk2RC6o5GHu618ARWh0VO0bFlif4

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

https://www.youtube.com/watch?v=kEGQKzhciKc

خیلیا تا این حد پیشرفته سراغ ماژول logging نرفتن. ولی این ویدیو انگار end قضیه logging داخل پایتون بود برام.
خیلی خوشم اومد ازش گفتم اینجا هم بزارم.

میدونستید هندلر های دیگری داریم؟
یا اینکه فیلتر هارو چطوری درست کنیم؟
یا حتی چطوری فرمتر بنویسیم؟
و سطوح مختلف لاگ و نحوه کانفیگ لاگ به صورت کامل از json.
جدا کردن بخش لاگ به یه thread جدا (io optimization)
یا لاگ های تمیز گرفتن در قالب jsonl.

همه اینا داخل این ویدیو.
https://www.youtube.com/watch?v=9L77QExPmI0

#نکات_قرارداد

۱) قرارداد حتماً باید نوشته بشه، اصلا روی حرف و ... هیچ چیزی قبول نکنید

۲) متن قرارداد رو حتماً بطور کامل بخونید، شما موظف نیستید همون لحظه که قرار داد بهتون داده میشه تا ۵ دقیقه بعد امضا بزنید.
(شخصاً یک نسخه از قرارداد و ضمیمه‌هاش رو می‌‌خوام که زودتر برام ارسال بشه و ۱-۲ روز مهلت خوندن به خودم میدم)

۳) بدون قرارداد کتبی هیچ کجا کار نکنید، مگر اینکه مبلغ رو قبل از شروع کار براتون واریز کنند
همه دوستان می‌دونند، شخصاً ممکنه با یک جا هم به توافق برسم.
اما اگر طرف قبل از قرارداد تسک بفرسته، دیگه باهاش همکاری نمی‌کنم، چون ۲ حالت بیشتر نداره
۳-۱ ) یا با هدف کلاهبرداری و از زیر موارد توافق شده فرار کردن قرارداد کتبی به شما تحویل نمی‌ده
۳-۲ ) یا اینکه یک پروژه ۱ ساله گرفته، خواسته با نیروی ۵ میلیونی کار رو در بیاره و حالا توی ماه‌های آخر هست و شدیداً نیاز به خروجی داره پس از ۱ روز هم نمی‌گذره که خب اینجا هم باید فرار کنید.

۴- یک نسخه از قرارداد رو همیشه تحویل بگیرید و پیش خودتون نگهدارید

۵- به تاریخ‌هایی که بیش از مدت قرارداد هست توجه کنید؛ توی ایران متن قرارداد هارو خیلی از شرکت‌ها به وکیل‌ها می‌سپارند و ازونجایی که ۹۹٪ وکیل‌ها برای قراردادهای کامیپوتری و فنی آماده نیستن متون مزخرف زیاد دیده میشه

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

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

اما مسئله این هست، هیچ شرکتی حق نوشتن این موضوع رو نداره.
شما حق استفاده از تجربیاتت رو داری و این یعنی بعد از کار توی هر شرکتی می‌تونی به یک شرکت با بیزینس مشابه بری و اونجا شروع به فعالیت کنی (دستمزد، برخورد یا هرچیزی)
اما طبق NDA شما حق انتقال دانش در مورد فیچرها، جزئیات عملکرد داخلی و ... که بعد از تحقیقات فراوان شرکت قبلی بهش رسیده و تجربه شخصی شما نیست رو به شرکت جدید ندارید.
حتی اگر این موضوع توی متن قرارداد شما نباشه، و اینکار‌ رو بکنید شرکت می‌تونه از شما شکایت کنه و ۹۹.۹٪ موارد هم رأی دادگاه برای شرکت هست.

۶- هر چیزی که از شرکت تحویل می‌گیرید و یا به شرکت تحویل می‌دید
بخصوص تحت عنوان ضمانت نامه، باید حتماً توی ضمیمه‌ای از قرارداد باشه و حتماً مهر و امضا مسئول شرکت رو هم داشته باشه.
مهمتر از اون باید اعلام بشه چه زمان و تحت چه شرایطی این ضمانت می‌تونه به اجرا گذاشته بشه و چه زمان و تحت چه شرایطی این ضمانت باید پس داده بشه.


در نهایت حتماً، حتماً، حتماً از قرارداد و ضمیمه‌های اون باید همیشه ۲ نسخه کاملاً رسمی (مهر، سربرگ، امضا، و ....) وجود داشته باشه
نسخه‌ای دست شما و نسخه‌ی دیگری برای شرکت.

اگر مورد دیگری در آینده یادم افتاد، حتماً به این پیام اضافه می‌کنم.

#جونیور

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

توی شرکت‌های مختلف و با افرادی که می‌شناختم بررسی کردم، حدود ۴۰۰.۰۰۰ شغل فنی رو هم کرال کردم و بر اساس تمام این موارد قیمت میدم.

برای پایتون توی شاخه‌های مختلف :

از ۱۲ میلیون دستمزد شروع میشه
و تا ۱۸ میلیون هم می‌تونه این مبلغ باشه برای جونیوری که رو به پیشرفت هست، بجای ادعا کردن ترجیح میده وقتش رو روی سوادش بذاره
و البته ابزارهای مهم و نیازمندی‌های
Software Engineer
شدن رو رعایت می‌کنه، قبلاً کلی راجبش صحبت کردم برای همین ادامه نمیدهم دیگه

#مدیور

بین جونیور سطح بالا (گفتم دسته بندی من ۳ سطحی هست) و مدیور سطح پایین واقعاً مرز باریکی وجود داره و خیلی وقت‌ها راحت نمی‌شه تشخیص داد این موضوع رو

مثلاً صرف اینکه طرف بتونه
Medium Complexity LeetCode

حل کنه نمی‌شه گفت که خب مدیور شده و تمام، اتفاقاً ازین سطح به بعد رفتار تیمی و نحوه برخورد با چالش و مسائل و ... هم خیلی مهم می‌شه

اینکه تنش و استرس رو چطوری باهاش مقابله می‌کنید و ....

مثال بزنم :
فرض کنید، یک تیم ۳ نفره از جونیور‌ها زیر دست شما درحال توسعه بخشی از نرم‌افزار هستند و شما هم مدیور بالا سر این افراد هم بهشون کمک می‌کنید، هم اگر نیاز به
Code review
باشه، شما شخصی هستید که تأیید اولیه رو میزنید.

مدیر فنی شرکت یا شخص بالاسری شما میاد با شما جلسه میگذاره و یکی از فیچرها رو از شما می‌خواد که تغییر بدید، یا فیچر اضافه کنید یا حتی جایگزین کنید.

برخورد شما چیه ؟
من بسیار مدیور و سنیور دیدم که سریعا گارد میگیرند، به نوعی مخالفت می‌کنند (حتی غیر منطقی) و می‌خوان که توی حالتی که پلن چیده شده پیش بروند و ...

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

بعضی وقتا هم دلایل فنی هست، که مدیور باید اینجا قدرت فنی خودش رو نشون بده اینکه چرا مخالف هست یا موافق حتی.


رنج دستمزد مدیور هم با توجه به وضعیت بازار ایران روی :

از ۲۰ میلیون تومان
تا ۴۰ میلیون تومان در ماه

برای سال ۱۴۰۳ رنج خوبی هست.

#سنیور

سنیور واقعی مبلغ نداره،
هرچقدر تیغ‌اش ببره، بریده

وقتایی هست که دوس داره به یک پروژه و یک نفر حال بده و با دستمزد کم کار می‌کنه
وقتایی هم هست که دستمزد واقعی خودش رو می‌خواد

برای همین من هیچ نظری روی دستمزد سنیورها نمی‌دم
قطعاً خودشون هم گرگی شدند و می‌دونند چطوری قرارداد ببندند.

یکی از دوستان زنگ زد؛ میگه نمیشه زودتر بگی داستان چی هست دارم لاگر پروژه شرکت رو می‌نویسم؛
کل منبع صحبت‌های این هفته :
Logging Cookbook, python documentation

این صحبتم که میگن داکیومنت خوبی نداره و ... هرکی گفت بهش بگید : چون درست نخوندی.
اگر شما هم مثل ای رفیق من خواستید زودتر شروع کنید به خوندن؛ توی داکیومنت بالا چندتا log handler رو حتما بهش توجه ویژه کنید.

RotatingFileHandler, QueueHandler

قبلا صحبت شده راجب اولی؛ دومی هم برای multi thread کردن هست که لاگ نویسی باعث کند شدن پردازش نشه.
StreamHandler, SMTPHandler, SocketHandler
توی این ۳ مورد هم مورد اول داخل داکر بدرد بخور هست؛ smpt رو هم احتمالا حدس زدید برای ارسال ایمیل هست (معمولا لاگ‌های critical رو برای خودمون یا ادمین یا ... ارسال می‌کنیم) و در نهایت هم SocketHandler که برای ارسال لاگ با پروتکل tcp به سرور دیگری استفاده میشه که خیلی خیلی مهم هست (باور ندارید از بچه‌های امنیت بپرسید)

معمولا خود من از این ۵ مورد توی پروژه‌های بزرگ استفاده می‌کنم؛ البته خیلی وقتا شرکت‌ها SocketHandler نمیگرین و براساس event یا ساعتی یا ... بکاپ لاگ فایل رو به S3 bucket میفرستند روی آمازون که هزینه کمتری داره برای نگهداری.