استفاده از clang برای corss compile

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

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

ممکنه بگید این به نظر غیر ممکن میاد اما مخصوصا توی C میشه یه چنین کاری انجام داد و clang و نسخه‌های جدید gcc قدرت این کار رو دارن که کد رو جوری کامپایل کنن که روی دستگاه‌های قدیمی کار کنه. چیزی که نیاز دارید اینکه اول به مجموعه کامپایلر دسترسی داشته باشید و اون کامپایلر حاوی چیزی به اسم sysroot باشه. کلا منظور از sysroot اینکه کل کتابخانه‌ها و ابزارهای لازم برای ساختن یک سیستم عامل کامل برای اون platform رو داشته باشید. دومین چیزی که نیاز دارید اینه که یه چیزی به نام target رو بدونید. این معمولا یه چیز سه بخشی هست که نشون میده cpu چیه، ساختار فایل اجرایی چیه، سیستم عاملی وجود داره یا نه. مثلا به چند مورد ازشون اینهاست armv7l-linux-gnueabihf یا arm-linux-gnueabihf که هر بخش از این سه گانه میگه چی به چیه.

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

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

[/crayon]

حالا این تست رو که بتونید روی بردتون اجرا کنید میتونید اون رو با makefile یا CMake هم ترکیب کنید و چیزهای جالبی بدست بیارد

همین!

چکامه ای برای واقعیت، عدم قطعیت، و وضعیت سبکبالی

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

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

واقعیت

واقعیت مهمترین منبع اطلاعاتی هست که ما بهش دسترسی داریم. آگاهی از واقعیت و شناخت اون به ما کمک میکنه که بهتر زندگی کنیم. کمک میکنه بهتر تصمیم بگیریم. یادمون باشه که ما با تشخیص درست واقعیت هست که میتونیم موثر عمل کنیم. خب از این بحث انتزاعی که بگذریم بریم سراغ یه سری مصداق. مثلا ما وقتی به این واقعیت آگاهی پیدا میکنیم که کولر خونه خرابه میتونیم تصمیم بگیریم که درستش کنیم یا نه؟ مثلا وقتی از واقعیت مرگ آگاهی پیدا میکنیم تلاش میکنیم که درست زندگی کنیم. وقت از واقعیت مریض بودنمون یا چاق بودنمون مطلغ میشیم تلاش میکنیم که رعایت کنیم یا تلاش کنیم سالم بشیم. پس واقعیت مهم ترین منبع اطلاعاتی هست.

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

بازم تکرار میکنم که واقعیت مهمترین منبع اطلاعات ماست.

عدم قطعیت

چه ما دلمون بخواد چه نخواد دنیا پر از عدم قطعیت هست. عدم قطعیت‌هایی که در ذهن انسان نمیگنجه. ذهن ما در نهایت توان تصور خطی چیزها رو داره اما تابعی که به دنیا حکومت میکنه توانیه. یعنی خیلی وقت‌ها ما پیچیدگی‌هایی مواجه هستیم که مثل قد توی یک بازه محدود نمیشن بلکه مثل میزان پولدار بودن آدمها کاملا غیر خطی هستن. این یکی از ویژگی‌های طبیعتی هست که ما باهاش روبرو هستیم. و ما با بهم زدن تعادل طبیعی روندها معمولا خودمون رو به سمتی میبریم که ریسک‌های غیر خطی بزرگی رو میخریم و خودمون رو با روی بد عدم قطعیت آشنا میکنیم. این مفهوم رو من خیلی سر بسته اینجا گفتم و آقای نسیم نیکلاس طالب توی کتاب‌های fooled by randomness و black swan و antifragile با جزئیات زیاد این موضوع رو مطرح کرده.

خب حالا چیکار کنیم. نکتش اینکه باید تشخیص بدیم کدوم کار چقدر ریسک داره و بیشتر وقت، انرژی، سرمایه‌مون رو به کار با حداقل ریسک تخصیص بدیم و یه بخش کمی از کارمون رو به کاری با ریسک خیلی بالا که اگه بگیره خیلی خوب میشه. یعنی اگه من بخوام یه کاری بکنم بیشترش رو به یه کار روتین با برگشت خطی نسبت به انرژی تخصیص میدم اما احتمالا یه کار جسورانه هم میکنه که به احتمال زیاد نمیشه ولی اگه بشه چی میشه!

پس در ادامه آگاهی از واقعیت این رو بپذیریم که در معرض عدم قطعیت غیر خطی هستیم و تلاش کنیم بتونیم باهاش سرو کله بزنیم

حالت جریان یا سبکبالی

آقای سیکزنت میحالی ا که روی تئوری خوشحالی و خلاقیت کار کردند حالتی رو توضیف میکنند که در اون فارغ از شرایط آدم‌ها با کارایی بالا کارهای خارق العاده‌ای انجام میدن. ایده این ماجرا به کودکی ایشون برمیگرده که میبینن بعد از جنگ جهانی دوم آدم‌هایی هستند که توی بلبشوی بعد از جنگ اروپا خوشحالن و زندگی خوشحال و خوبی دارن با اینکه تفاوت عمده از نظر امکانات با سایرین ندارند. نتیجه تحقیقاتشون به این نتیجه میرسونتشون که حالت سبکبالی وجود داره که ویژگی‌های زیر رو داره

  • تمرکز زیاد روی حال و اکنون
  • یکی شدن عمل و آگاهی
  • از دست رفتن خودآگاهی
  • احساس کنترل بر موقعیت یا فعالیت
  • عدم حس کردن زمان
  • تجربه کردن فعالیت به عنوان یک عمل ذاتا دارای پاداش در مغز

اگه این حالت رو تجربه کرده باشید که احتمالا تجربه کردید میدونید که بسیار لذت بخش هست و موندن و حرکت کردن درونش به شما شادی و شعف ذاتی میده.

خب که چی

خب اگه تا اینجا اومدید احتمالا سوال براتون پیش میاد حالا که چی؟

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

همین!

لذت برنامه نویسی: ذخیره سازی داده

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

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

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

  1. سایز دیتا و فایل متغیر باشه و بشه اون رو اضافه کرد
  2. فیلدهای دیتا قابل اضافه و کم کردن باشه
  3. حجم کد لازم برای این کار کم باشه که بشه روی دستگاه‌های سطح پایین مختلف ازش استفاده کرد.

راه حل‌ها

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

  1. پیاده‌سازی از اول: یعنی وابسته به نیازمون یه ساختار قابل افزایش خوب پیاده‌سازی کنیم
  2. استفاده از فرمت‌های متنی: فرمت‌های متنی که معمولا میشه استفاده کرد ini, xml, cvs, json, yaml هست. ایراد اینها اینه که چون متن هستن حجم زیادی میگیرن و عملا به صرفه نیستن. معمولا میزان پردازش لازم برای parse اونها هم کم نیست.
  3. استفاده از تکنولوژی های serialization مثل protocol buffer, thrift هست که با استفاده از اونها میتونید یه دیتا رو توصیف کنید و همون دیتا رو بصورت آرایه ذخیره کنید. اونها معمولا از schema evolution یعنی تغییر ساختار دیتا هم پشتیبانی می‌کنن.
  4. استفاده از دیتابیس های سبک مانند sqlite
  5. استفاده از کتابخانه‌های ذخیره سازی nosql مثل unqlite یا level db یا berkeley db که هر کدومشون به ما امکان ذخیره سازی دیتای با فرمت نامشخص رو میدن.

انتخاب من

من در پروژه‌هام از یه ساختار با سایز مشخص، ini ، sqlite و unqlite استفاده کردم. الان ترجیحم استفاده از با این اولویت هست:

  1. اول sqlite چون خیلی امکانانت سطح بالایی میده
  2. استفاده از unqlite و یا ini. البته با ini ما به مشکلات زیادی خوردیم اما unqlite رو هم اونقدر توی فیلد تست نکردم
  3. تهش پیاده کردن ساختار با سایز مشخص هست که کلی دردسر داره

همین

زیر پوست داکر چه خبر است

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

در این پست قرار است که به زیرساخت‌هایی که داکر مبتنی بر آن ساخته شده است اشاره شود. هدف نهایی نشان‌دادن این موضوع است که داکر امکانات خود را به چه صورت ارائه می‌کند.

مقدمه

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

کرنل لینوکس

بخش عمده‌ای از امکاناتی که داکر فراهم می‌کند، با استفاده از سازوکارهایی که در کرنل وجود دارند پیاده‌سازی شده‌اند. با در کنار هم قرار گرفتن این تکنولوژی‌ها داکر توانسته است که به ارائه خدمات بپردازد. لیست این تکنولوژی‌ها عبارتند از:

  • فضای نام(namespace)ها در لینوکس: فضا‌های نام این امکان را بوجود می‌آورند که بتوانند بخشی از منابع سیستم را بصورت ایزوله به پروسه‌هایی که درون آنها قرار دارند ارائه دهند. این منابع تنها توسط پروسه‌های درون آن قابل روئیت است. فضاهای نامی در داکر مورد استفاده قرار گرفته‌اند عبارتند از
    • فضای‌نام PID: که باعث می‌شود پروسه تنها پروسه‌های درون خود را ببینند
    • فضای‌نام NET: که باعث می‌شود بتوان کارت‌شبکه، پشته شبکه و سایر موارد را بصورت ایزوله ارائه کرد.
    • فضای‌نام IPC: که روندهای ارتباطی بین پروسه‌های مختلف را ایزوله می‌کند.
    • فضای‌نام MNT: که نحوه اتصال(mount) واسط‌های ذخیره سازی را ایزوله می‌کند.
    • فضای‌نام UTS: که نام کامپیوتر(hostname) و دامنه(NIS) را ایزوله می‌کند.
  • گروه‌های کنترلی یا cgroups: کرنل لینوکس این امکان را فراهم می‌اورد که پروسه‌ها در یک ساختار سلسله مراتبی قرار گفته و دسترسی آن به منابع سیستم محدود شود و مورد پایش قرار گیرد. این باعث می‌شود بتوان به عنوان مثال میزان استفاده از سی پی یو یا رم را کنترل کرد.

فایل سیستم

تکنولوژی دیگری که در داکر مورد استفاده قرار گرفته است، استفاده از یک سیستم فایل خاص به ویژگی copy on write است. سیستم فایلهای با این ویژگی را می‌توان بصورت لایه لایه ذخیره کرد و هنگام انتقال در صورت وجود داشتن نسخه قبلی تنها تفاوت‌ها را ارسال نمود. همچنین این امکان به ما این اجازه را میدهد که بتوانیم تغییرات را نسخه متفاوت همانند یک سیستم مدیریت نسخه پیگیری نماییم. سیستم فایلی که داکر از آن استفاده union file system است که ویژگی‌های زیر را دارد:
– بصورت لایه‌ایست
– هر لایه بایستی commit شود
– هر لایه بصورت فقط خواندنی ذخیره می‌شود.
– تنها فایلهای تغییر یافته در آن لایه ذخیره می‌شوند.

اجرا یک کانتینر

برای اجرای کانتیر و مشخص کردن تمام مشخصات آن بایستی این مشخصات را به فرمتی توصیف کرد. در داکر این فرمت container format نام داشته و داکر سعی در استاندارد کردن آن را دارد.

اسکرین کست: چگونگی ساختن اسلایدها

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

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

کلا تکنولوژی ساخت اسلایدها چیزی نیست جز HTML همین. که این HTML خاص به کمک کتابخانه‌های impress.js به حرکت در میان و اسلایدها رو میسازن. ابزار impress.js با ایده گرفتن از محصول تجاری perzi و با استفاده از امکانات HTML5 توسعه پیدا کرده. کاری که باید انجام بشه اینه که شما اسلایدها و انتقالها رو یکی یکی درست میکنی و در نهایت impress.js میدونه که چطوری اونها رو اجرا کنه. سختی این روش اینه که جاگذاری دقیق اسلایدها روی صفحه نمایش و همه انتقالها بایستی بصورت دستی انجام بشه که به همین خاطر کار یکمی مشکل هست

حالا یه نفر پیدا شده ابزاری به نام hovercraft مبتنی بر پایتون توسعه داده که میاد فایلهای ReStructuredText رو تبدیل به HTML با فرمت مناسب میکنه و تمام جاگذاری‌ها و تبدیل‌ها رو هم انجام میده. شما می‌توانید تبدیلها رو بصورت اتوماتیک و متناسب با اسلاید قبلی دید. نمونه این اسلایدها در منبع گیت‌هاب ارائه‌های من موجود هست

همین!

مسیر شغلی کامپیوتر و آی‌تی

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

یکی از دوستان من که کامپیوتر نخونده و معاون آموزشی یکی از دانشگاه‌های شهر مادری من هست از من پرسید که که ما به دانشجو‌های کامپیوتر و آی‌تی مون چی یاد بدیم که واسه کار آماده‌تر باشند؟ وب یادبگیرن؟ اندروید بلد بشن؟ ما چه درس‌های آنلاینی رو براشون بخریم و بصورت مجانی در اختیارشون قرار بدیم؟

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

پس اگه دوست داشتید کمک کنید یادتون باشه که به این سوالات جواب بدید:

  • چه شغلی؟
  • به چه مهارتی نیاز داره؟
  • از کجا میشه این مهارت رو یاد گرفت؟

منتظر کمک‌هاتون هستم

همین!

دوپینگ گیط‌ی ;) – دوره کوتاه و فشرده git

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

حدودا ۲ روز پیش با خودم عهد کردم که یه ویدئو کوتاه آموزش درباره git درست کنم به اسم «دوپینگ گیط‌ی ;)». بعد از ۱۰ ساعت کار مفید این ویدئوی ۲۵ دقیقه‌ای در مورد گیت آماده شده که میگذارمش اینجا که ببینید.

مطالبی که توش مطرح میشه اینا هستن:

  • نصب و راه‌اندازی
  • مفاهیم گیت
  • ساختن یک منبع کد محلی
  • اضافه کردن و کامیت!
  • تغییر و کامیت!
  • تاریخچه تغییرات
  • سرور git
  • گرفتن از سرور
  • فرستادن تغییرات
  • شاخه‌ها
  • بروزرسانی و ادغام
  • برچسب‌ها
  • برگردادن تغییرات

سورس فایل ارائه هم مثل سورس این مطلب توی github من در دسترس هست.

ویدئو

در یوتیوب:

در آپارات:

لذت برنامه نویسی: معرفی gerrit

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

خب الان که من فرصت نوشتن بیشتر دارم تصمیم گرفتم یکم در مورد gerrit بنویسم. توی هر شرکتی معمولا یه چیزی به اسم «چرخه حیات توسعه نرم افزار» وجود داره که آدم‌ها ازش بصورت آگاهانه یا به وسیله اونچیزی که فرهنگ اون تیم یا گروه دیکته میکنه ازش استفاده می‌کنند. که اگه عمری بود بیشتر در موردش می‌نویسم. چرخه حیات کارهایی که ما در شرکت انجام می‌دیم به این شکله که:

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

معرفی gerrit

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

روند هم اینه که با امکاناتی که gerrit در اختیار ما قرار میده، بعد از ارسال کد یک مرج محلی اتفاق میفته و کد توسط ci که همون jenkins باشه کنترل و کامپایل میشه. اگه این مرحله درست بود jenkins به gerrit میگه که اگه کسی review کرده میتونه تغییرات رو merge کنه و گرنه تا عدم موفقیت jenkins کسی نمی‌تونه کد رو اشتباهی merge کنه. این تضمین میکنه که دیگه کسی چیز اساسی رو خراب نمی‌کنه. پس از تایید jenkins هم افراد میتونن کد رو بررسی و تغییرات رو merge کنن. همچنین gerrit پلاگین‌هایی داره که کمک میکنه تا ما اون رو به جاهای مختلف مثل jira وصل کنیم و از اینکه یه کار آماده‌است و یا یه کار merge شده با خبر بشیم و حتی وضعیت موارد رو تغییر بدیم.

بعد از بررسی روند کا نوبت به پیش فرضهای هست که توی gerrit وجود داره.

  1. اینکه مدیریت منبع git در کنترل gerrit هست و ازش به عنوان یک git server استفاده می‌شه. یعنی اگه سرور دیگه‌ای مثل github هم وجود داره کپی gerrit هست نه بالعکس
  2. اینکه تغییرات هرچقدر هم که زیاد و مداوم باشن در نهایت در قالب یک commit ارسال میشن. ممکنه بگید که خب اگه من خواستم وسط کارم push کنم چی؟ جواب اینه که هر کامیت یک تغییر هست و تغییر میتونه draft باشه که یعنی هنوز کامل نشده
  3. اینکه gerrit تلاش میکنه که تاریخچه کد خطی بمونه و این در مجموع خوبه. برای خطی نگه داشتن تاریخچه به شدت از rebase استفاده می‌کنه

حالا اگه بخوام بصورت خلاصه مزایا و معایب رو بگم هم اینا به ذهنم میرسه

مزایا و معایب gerrit

مزایا:

  1. تاریخچه خطی
  2. ثبات در عملکرد
  3. وجود ابزار git review برای ارسال به gerrit و راحت کردن استفاده از gerrit
  4. شفافیت روند کاری بررسی کرد
  5. راحتی integrate شدن با ابزارهای دیگه مثل jira و jenkins و gitlab

معایب:

  1. مستندات گنگ. خیلی پیدا کردن چیزهای ساده توی gerrit آسون نیست
  2. زمان زیادی برای یادگیری استفاده از gerrit مورد نیاز هست

در آخر بگم که بگم که روند کاری که هریک از این ابزارها پیشنهاد میدن یک روند دیکته شده است و ممکن به مذاق شما خوش نیاد پس از هر روشی که به مذاقتون خوش میاد استفاده کنید. ما هم یه مدت از gerrit استفاده کردیم بعدش از gitlab و دوباره برگشتیم gerrit چون به نظرمون gerrit بهتر بود

همین!

لذت برنامه نویسی: نحوه کار ما با jenkins

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

خب حدودا سه سال قبل من از جای خالی continues integration نوشتم. حالا حدود بعد از سه سال میخوام دوباره به موضوع رجوع کنم و درباره jenkins بنویسم

توی این سه سال اتفاقات زیادی افتاده. ما روند build رو با استفاده از cmake بهتر کردیم. یادگرفتیم که چی به چیه. حدودا انتهای سال قبل بود که توی شرکت منابع و علم کافی برای پیاده‌سازی روند ci بوجود اومد و ما شروع کردیم به استفاده از jenkins.

نصب و راه‌اندازی jenkins به نسبت آسون و راحت بود. کاری که jenkins برای ما میکرد این بود که به یه دلیلی(بخونید ماشه) شروع به کامپایل کد میکرد. روند کامپایل هم آسون بود. یعنی اینکه یه سری پروژه معمول رو میشناسه مثل cmake, make, gradle, maven داره که کار رو راحت میکنه

ما اول به یه پروژه معمولی که بصورت ساعتی اجرا میشد شروع کردیم فقط نکتش اینه که ما با سخت‌افزارهای مختلف کار میکنیم و این تنها برای یکی از سخت‌افزارهامون کار میکرد. بعدش یه پروژه معمولی دیگه اضافه کردم که با cppcheck کار static analysis رو روی کدمون بصورت ساعتی انجام میداد.

در مرحله بعد با استفاده امکانی از jenkins pipeline تمامی سخت‌افزارها رو باهم کامپایل کردیم و cppcheck هم به عنوان یک مرحله از این خط لوله ما انتخاب شد.

در قدم بعدی هم این ماجرا رو به git وصل کردیم و به ازای هر کامیت یا هر درخواست بررسی که روی کدمون انجام میدیم شروع به کامپایل میکنه و ما میدونیم که دیگه تغییرمون چیزی رو خراب نمیکنه.

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

فعلا همین!

openwrt و اضافه کردن یک پکیج جدید

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

توی پست قبل من OpenWrt رو معرفی کردم. بعد از یه مدت متوجه شدم که یه پروژه جدید به نام LEDE ایجاد شده که انگار همونه و الان حدود ۲ سال هست که OpenWrt زیاد بروزرسانی نمی‌شه. حالا با توجه به علاقه‌ام به کارهای نزدیک سخت‌افزار و مسائل مرتبط به cross compile سعی کردم که کل OpenWrt رو کامپایل کنم و سعی کنم یه پکیج جدید بهش اضافه کنم.

البته پکیجی که من دنبالش بودم tun2socks بود که پکیجش بصورت غیر رسمی وجود داشت. کاری که من کردم این بود که آدرس‌ها رو عوض کردم و یادگرفتم که چطور میتونم اون رو برای روترم کامپایل کنم. نتیجه کار من رو میتونید توی گیت‌هاب من پیدا کنید

روند کار به ترتیب اینجوریه که:

  1. اول سورس کد رو با گیت از گیت‌هاب میگیرید
  2. دوم با توجه به راهنمای آنلاین تمام پکیج‌ها رو دانلود میکنید
  3. پکیج رو اضافه می‌کنید
  4. با استفاده از نوع معماری سیستم و نوع دستگاه و پکیج‌ها رو انتخاب می‌کنید
  5. و از ابتدا کامپایلر و کل لینوکس و پکیج رو کامپایل میکنید

پینشهاد میکنم که برای شروع اینها بخونید:

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

همین!