اینم یه تجربه پراکنده!

توی پست قبل من OpenWrt رو معرفی کردم. بعدش هم من پول دادم و یدونه از این روترهای به نسبت ارزون خریدم که usb رو پشتیبانی می‌کرد. بعد از یک سال اینترنت خونه به دلایل عملیاتی بایستی قطع میشد و من رفتم یه مودم lte با مدل Huawei E3372 خریدم. البته این مودم من sim lock ایرانسل هست ولی مدلهای بدون sim lock هم وجود داره.

خیلی ساده می‌تونید که این دستگاه رو راه‌اندازی کنید. کافیه که دوتا پکیج اضافه زیر رو نصب کنید

  • kmod-usb-net-cdc-ether
  • usb-modeswitch

مودم بصورت معمول توی مد HiLink هست که یک کارت شبکه رو شبیه سازی میکنه. پس در نهایت شما یه کارت شبکه جدید دارید که بایستی اون رو به عنوان Wan انتخاب کنید. ایراد مد هایلینک این هست که اگه شما valid ip ثابت روی سیم‌کارتتون داشته باشید نمی‌تونید چیزی رو port forward کنید.

حالت دیگه ای که مودم کار میکنه بصورت پورت سریال درمیاد که at command قبول میکنه. این مد هم البته قابل راه‌اندازی هست که یکم دردسر داره ولی ممکنه. البته این رو من هنوز امتحان نکردم

امیدوارم به دردتون خورده باشه!

همین!

اینم یه تجربه پراکنده دیگه!

امروز یه قسمت دیگه از کتاب «۹۷ چیز که یک برنامه نویس بهتر است بداند» رو اینجا به اشتراک میگذارم. این پنجمین ویدئو هست که فصل ۱۴ رو ارائه میده. از این فصل تصمیم گرفتم که یکم در مورد فصلی که ارائه شده توضیحات بیشتری بدم.

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

این ویدئو بصورت همزمان توی وب سایت هایو هم به انتشار رسیده.

ویدئو

در یوتیوب:

در آپارات:

اینم یه تجربه پراکنده دیگه!

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

لیست مقالات از این قراره

همین!

پ.ن. خوشحال میشم به مابقی نوشته‌های من توی اونجا سر بزنید.

اینم یه تجربه پراکنده دیگه!

خب توی این پست یه ابزار جایگزین برای build کردن نرم‌افزار‌های c و c++ معرفی کنم به اسم ninja. داستان بوجود اومدنش از این قراره که آقای اوان مارتین که توی گوگل روی توسعه google chrome کار میکرده متوجه میشه روند کامپایل کدهاشون بیش از حد کنده و دست و آستینش رو بالا زدن که یه سیستم سریعتر برای build بنویسه که حاصل شد ninja. پیشنهاد میکنم در اولین گام سیستمتون رو اگه cmake نیست cmake کنید و در گام دوم از ninja استفاده کنید

ویژگی‌های ninja

خب ویژگی‌هایی که من بلدم از این قراره

  • سعی در انجام یک کار بصورت درست
  • سعی در خیلی سریع بودن
  • حداقل محدودیت روی نحوه کامپیال شدن کد و سپردن اونها به ابزارهای سطح بالاتر مانند cmake و gyp
  • تشخیص درست وابستگی‌ها
  • سرعت بر سادگی ارجحیت دارد

نمونه موردی

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

برای کدهای ما در یک تست غیر علمی نتیجه‌های حدودی زیر برای ۲ یا ۳ بار اجرا بدست اومد

type make ninja
clean build ۶۰s ۱۳s
rebuild ۱۰s ۰٫۳s

همین!

اینم یه تجربه پراکنده دیگه!

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

مشکل با متغیر محلی بزرگ

ما یه کد سی داشتیم که یه متغیر local با حجم حدودا ۱۰ کیلو بایت تعریف شده بود و مقدار دهی اولیه شده بود(عکس بود). همیشه کامپایلر به این قسمت از کد که میرسید کلی طول میکشید تا بتونه کد رو کامپایل کنه و همیشه اعصاب ما رو خورد میکرد. تا اینکه یه روز تصمیم گرفتیم مشکل رو حل کنیم. راه حل‌هایی که پیش رومون بود اینها:

  1. متغیر رو کلا حذف کنیم. که خب نمیخواستیم صورت مساله رو حذف کنیم
  2. متغیر رو global میکردیم که خب همه میتونستن تغییرش بدن و برامون بد بود
  3. متغیر رو static کنیم. این تفاوتی برای ما نداشت فقط میخواستیم امتحان کنیم.

خب اول راه دوم رو امتحان کردیم. اتفاقا هم زمان کامپایل کم شد و هم حجم باینری تولید شده. وقتی راه سوم رو هم امتحان کردیم دیدیم که نتیجه با راه دوم یکیه و حجم باینری کم شده و این خوب بود. چون راه دوم ویژگی‌های متغیر local رو داشت و عیب در دسترس بودن برای همه رو هم نداشت.

بررسی چرایی راه‌حل

سوالی که برای ما پیش اومد این بود که چرا یه تغییر اینجوری اینهمه هم توی سرعت هم حجم باینری موثره؟ برای جواب دادن به این ماجرا یکم رفتم تحقیق کردم:

  • همه باینری‌ها از بخش‌های مختلفی تشکلی شدن که اگه assembly یادتون باشه شامل اینهاست
  • متوجه شدم که متغیرهای global توی data segment تعریف میشن و متغیرهای local توی stack segment تعریف میشن.
  • متوجه شدم که متغیرهای static هم توی data segment تعریف میشن.

پس هرچی بود زیر سر data segment بود از اینجا به بعدش بازی شد حدس و گمان در مورد چرایی دوتا اتفاق:
– چرا سرعت کامپیال بیشتر؟ احتمالا به این دلیل که کامپایلر با data segment راحت‌تر کار میکنه تا stack segment. اما این حدس حجم باینری کمتر رو توجیه نمیکنه چون در این دوحالت حجم متغیر ثابت مونده
– چرا حجم باینری کمتر؟ برای اینکار یکم باید یادمون بیاد توی assembly که چطور یه متغیر local تعریف میشه منظورم هست. یه متغیر local عملا اینه که اول یه مقداری توی stack قرار میگیره و در یه مرحله دیگه اون مقدار از stack خارج میشه. که این هم نیاز به کد سمت code segment داره هم نیاز به حافظه سمت stack segment داره.

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

امیدوارم به دردتون خورده باشه
همین!

اینم یه تجربه پراکنده دیگه!

چند شب پیش یکی از دوستان با این سوال به سراغ من اومد:

مشکل اینه که وقتی با malloc یا new یک حافظه تخصیص میدی و با free یا delete حافظه رو برمیگیردونی, اون حافظه شاید بلاک هاش خالی بشه اما توی تسک لیست خالی به عنوان منابع استفاده شده میاره و تا پایان پروسه پاک نمیشه. از دوستانی که آشنایی دارن پیگیری کن ببین جریان چیه. مهمه .

خدا خیرت بده. یه جایی از حافظه نمایی رشد میکه و وقتی خالیش میکنیم (با اینکه از لیست heap سیستم عامل خالی میشه) اما توی لیست پروسه‌ها(مثل نتیجه ps) هنوز به عنوان حافظه استفاده شده هست و حافظه آزاد نمیشه !!!‌ عجیبه . کلی توی اینترنت اینو سوال کردن !!

من که لینوکسم. اما فکر کنم ویندوزم همینه. چون سوالای اینترنت هردوشونه

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

پیش‌نیازها

پیش نیازهایی که به نظرم باید بدونیم ایناست:

  • نکته صفر اینکه با توجه به تحقیقات من زیر کلمه کلیدی new از همون malloc استفاده میشه. پس بررسی malloc به تنهایی میتونه جوابی برای ما فراهم کنه.
  • اول اینکه باید بدونیم که وقتی malloc صدا زده میشه چه اتفاقی میفته. کاری که malloc میکنه اینه که heap پروسه رو بهت اختصاص میده. حالا heap توسط سیستم عامل مدیریت میشه و در صورت نیاز به پروسه‌ی شما حافظه بیشتری تخصیص میده.
  • دوم اینکه فضای heap توسط کرنل مدیریت میشه و به اصطلاح نگاشته میشه به یه چیزی به نام Virtual Memory
  • سوم اینکهVirtual Memory نگاشته میشن به چیزی به نام Memory Page که نزدیک به سخت افزار تره
  • چهارم اینکه Memory Page نگاشته میشن بلوک‌های واقعی حافظه. از این مطمئن نیستم اما این نزدکترین لایه به سخت افزاره که من باهاش آشنا هستم.

بررسی مساله

حالا اگه بخوایم مساله رو بررسی کنیم باید به چند‌تا سوال جواب بدیم:

  • اول اینکه malloc چطور عمل میکنه؟ در پیاده‌سازیش ساز و کارش چیه؟
  • دوم اینکه روند افزایش طول Virtual Memory و اضافه شدن Memory Pageها چطوره؟
  • سوم اینکه بعد از پس دادن Memory Pageها سیستم عامل چطور اونها رو از یک پروسه پس میگیره؟

خب جواب سوالا به ترتیب اینا به نظر میرسن:

  • پیاده‌سازی‌های متفاوتی از malloc وجود داره
    • پیاده‌سازی معمولا اون اینطوریه که پس از گرفتن حافظه وقتی free شد معمولا اونها رو به سیستم عامل پس نمیده و نگه میداره که شاید بعدا بخواد دوباره تخصیص بده.
    • دوم اینکه درخواست یک Memory Page جدید توسط دستوراتی مثل mmap و sbrk درخواست یک بلاک بزرگ حافظه میکنه و اون رو بنا به درخواست نرم‌افزار تخصیص میده.
    • بعدش هم اینکه برای اینکه یک Memory Page رو برگردونه به سیستم عامل بایستی تمام حافظه‌هایی که روی اون تخصیص داده شدن برگشت داده بشه. که این هم همیشه اتفاق نمی‌افته.
    • معمولا هم پیاده‌سازی‌ها اینجورین که حافظه‌ای که توسط sbrk افزایش پیدا کرده رو دست نمیزنن(دلیل دقیقش رو نمیدونم) و حافظه‌ای که توسط mmap اضافه شده رو به راحتی برمیگردونن.
  • تقریبا جواب سوال دوم رو هم تا الان دادم. مقدار Virtual Memory توسط glibc کنترل میشه و بوسیله malloc تخصیص داده میشه.
  • جواب سوال سوم هم اینه که کرنل لینوکس همیشه حافظه برگشت داده شده رو برنمیگردونه چون که هزینه داره فقط اون رو علامت میزنه که در صورت نیاز اون رو حذف کنه یا به swap ببره.

راه حل مساله

حالا بریم سراغ مساله اصلی(چرا حافظه برگشت داده شده برگشت نخورده) و توجیهی که براش پیدا کردیم:
* مهمترین دلیل این اتفاق به نظرم malloc هست که حافظه رو نگه داشته و برنگردونده
* دومین دلیلش هم میتونه این باشه که کرنل هنوز Memory Page رو برنداشته و فقط علامت زده

حالا راه حل چیه:
* اول اینکه به کرنل و glibc اعتماد کنیم
* دوم اینکه بیایم و این پارامتر مروبط به malloc رو تنظیم کنیم۴
* سوم اینکه بیایم از یه پیاده‌سازی دیگه برای تخصیص حافظه و آزاد سازی اون استفاده کنیم
* چهارم اینکه بیایم خودمون مستقم از mmap و munmap استفاده کنیم

امیدوارم اینا راه گشای دیگران هم باشه

برای مطالعه بیشتر:

۱

۲

۳

۴

همین!

اینم یه تجربه پراکنده دیگه!

امروز یه قسمت دیگه از کتاب «۹۷ چیز که یک برنامه نویس بهتر است بداند» رو اینجا به اشتراک میگذارم. این چهارمین ویدئو هست که فصل ۱۱ رو ارائه میده. این مدت پیدا کردن زمان خلوت توی خونه معزلی شده بود. به همین خاطر دل رو به دریا زدم و گفتم با حضور «حناچه» در پشت صحنه ضبط مکنم. انشالا که خوب شده باشه و بتونم بقیه کتاب رو هم ضبط کنم.

یادتون نره که با کامنت‌هاتون و به اشتراک گذاشتناتون می‌تونید من رو تشویق کنید که بقیه اش رو هم ضبط کنم. هر جا که خواستید اینها رو به اشتراک بگذارید و فقط اسمی از من بیارید.

این ویدئو بصورت همزمان توی وب سایت هایو هم به انتشار رسیده.

ویدئو

در یوتیوب:

در آپارات:

اینم یه تجربه پراکنده دیگه!

امروز یه قسمت دیگه از کتاب «۹۷ چیز که یک برنامه نویس بهتر است بداند» رو اینجا به اشتراک میگذارم. این سومین ویدئو هست که فصل ۱۰ رو ارائه میده. نکته اینکه با توجه به اینکه بازخورد کیفیت پایین صدا داشتم سعی کردم که یکم روی کیفیت صدای این قسمت کار کنم. انشالا که بتونم بقیه کتاب رو هم ضبط کنم.

یادتون نره که با کامنت‌هاتون و به اشتراک گذاشتناتون می‌تونید من رو تشویق کنید که بقیه اش رو هم ضبط کنم. هر جا که خواستید اینها رو به اشتراک بگذارید و فقط اسمی از من بیارید.

این ویدئو بصورت همزمان توی وب سایت هایو هم به انتشار رسیده.

ویدئو

در یوتیوب:

در آپارات:

اینم یه تجربه پراکنده دیگه!

خب من این مدت شروع کردم به ضبط چند قسمت ویدئو به فرمت اسکرین کست از کتاب «۹۷ چیز که یک برنامه نویس بهتر است بداند». الان میخوام توضیح بدم که این کار رو به چه صورتی انجام دادم.

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

  1. اصلا چطور شروع کنیم.
  2. نرم افزار تولید
  3. بهبود پس از تولید: معمولا کیفیت صدا بهتر میشه و قسمت‌های ناخواسته ویدئو حذف میشه و از این دست چیزها.
  4. انتشار

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

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

کلا هم روند اینه که من محتوا اسکرین کست (اسلایدها، اگه بشه متن ارائه) رو آماده میکنم و شروع به ضبط کردن میکنم( من از obs برای ضبط استفاده میکنم). من ترجیحم اینه که توی روند تولیدم نیازی به «بهبود پس از تولید» نباشه پس اگه توپق بزنم یا هر چیز دیگه‌ای، روند ضبط رو قطع میکنم و از اول همه ویدئو رو ضبط میکنم. بعد از چندبار ضبط کردن، به نقطه‌ای میرسم که خودم از کیفیت ارائه انجام شده راضی‌ام. اونجاست که میرم سراغ انتشار ویدئو.

برای انتشار ویدئو هم من اول ویدئو رو روی یوتیوب میگذارم و بعدش اون رو به آپارات منتقل میکنم. اینطوری تنها یک بار ویدئو رو آپلود میکنم.

همین!

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

اینم یه تجربه پراکنده دیگه!

امروز یه قسمت دیگه از کتاب «۹۷ چیز که یک برنامه نویس بهتر است بداند» رو اینجا به اشتراک میگذارم. این سومین ویدئو هست که فصل ۵ رو ارائه میده. نکته اینکه با توجه به اینکه ویدئو دوم به خوبی استقبال نشد و یکم سعی کردم با توجه به بازخوردهای شما ویدئو رو بهتر کنم. راستی اضافه کنم که من اول اون فصل‌هایی که رو که خودم باهاشون درگیر بودم رو اول می‌گم و بعدش میرم سراغ مابقی فصلها. انشالا که بتونم بقیه کتاب رو هم ضبط کنم.

یادتون نره که با کامنت‌هاتون و به اشتراک گذاشتناتون می‌تونید من رو تشویق کنید که بقیه اش رو هم ضبط کنم. هر جا که خواستید اینها رو به اشتراک بگذارید و فقط اسمی از من بیارید.

این ویدئو بصورت همزمان توی وب سایت هایو هم به انتشار رسیده.

ویدئو

در یوتیوب:

در آپارات: