remote work desk

یک سال و دو ماه دورکاری

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

خب اگه از اسفند ۹۸ حساب کنیم الان من ۱ سال و ۲ ماه میشه که دورکارم. و بخاطر این دورکار شدن تونستم برگردم زادگاهم و از خونه کار کنم.

توی این پست سعی میکنم بگم که من چیا رو تجربه کردم

ماه عسل دورکاری

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

من تو همین دوران کار قبلیم رو عوض کردم و یه جای جدید مشغول شدم

زیر یک سقف در دورکاری

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

دورکاری هم برای من این مدلی بود

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

یک اوضاع استیبل تر شده بود که توی کار تیمم عوض شد. یعنی با آدمهایی که کار میکردم عوض شدن. و چالش کار با تیمی که من اولین آدم جدیدی بودم که کاملا هم دورکار بودم شروع شد.

جا افتادن توی تیم برای من سخت بود. چون ارتباط موثر کم بود. کارها به هم گره میخورد و از این حرفها. و خب این برام جدید بود.

اسباب کشی

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

و کلا اوضاع به ثبات رسیده بود.

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

دور ماندند ز من آدم‌ها

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

وصایا

اگه بخوام یه سری توصیه برای دورکاری براساس تجربه‌ام بکنم ایناست

  1. حتما اتاق مجزا برای کار داشته باشید. حتی شده در حد زیر پله ولی جدا. این جدا بودن به شما و خانواده کمک میکنه
  2. حتما چندتا اینترنت داشته باشید چون معلوم نیست کی کدومش قطع میشه. پیشنهاد من ۲ تا اینترنت همزمان هست که ۳ تا حتی بهتره
  3. از خرید تجهیزات مثل میز و صندلی و روتر/موردم و وب‌کم و مانیتور و کیبرد و موس برای اتاقتون نترسید. این از اون سرمایه‌گذاری‌هاست که لذتش رو میبرد. اولویت بندی کنید و به ترتیب بخرید. شما در دروکاری خیلی از هزینه‌های جاری معمول مثل هزینه رفت و آمد و اینا رو ندارید. این هزینه‌ها رو صرف تجهیز اتاق کارتون کنید
  4. سرگرمی خارج از کامپیوتر و مانیتور داشته باشید. چون دیگه تو دورکاری خیلی بیشتر سرتون تو گوشی و کامپیوتر هست

همین!

یادداشت‌های در مورد روش‌های چابک اسکرام و تخمین زدن!

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

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

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

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

۰ – اینکه من خودم و با اجازه بزرگترها خیلی از ما مهندس‌های نرم‌افزار رو در این حد از نظر احاطه به بحث توسعه فرآیند و ساختار نمیدونم که بتونن یه ساختار/روش کاری ایجاد کنن. پس ایده‌آل ام اینه که به یه روش/ساختار در سطح حلقه/تیم/شرکت به عنوان ریسمان محکم چنگ بزنم و از اون پیروی کنم. «پس به ریسمان محکم الهی چنگ بزنید و متفرق نشوید» آل‌عمران ۱۰۳

۱- به نظر بنده حقیر سراسر تقصیر، تمام روش‌های چابک/اجایل اومدن که دوتا کار کنن. اول عدم قطعیت رو مدیریت کنن. دوم تحویل به مشتری رو بیشینه کنن. پس جایی که ما با عدم قطعیت روبرو نیستیم یا تحویل به مشتری نداریم به نظرم اجایل اصالتا معنی نمیده.

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

۲- بازم به نظرم در جاهایی که بیشتر کارهای بیشتر تیم‌هاش از جنس عملیات و نگهداری هست آیا بایستی از اجایل استفاده کنیم؟ به نظرم آره. چون تهش ما هم عدم قطعیت داریم هم تحویل به مشتری. اما آیا اسکرام روش خوبی هست؟ به نظرم در تیم‌هایی که وزن توسعه توشون زیادتره بله. بقیه تیم‌ها چی؟ به نظرم اونها باید چیزی مثل کانبان/اسکامبان که مناسب‌تره استفاده کنن. ولی به نظرم باید بچسبیم به روش و سعی نکنیم مثلا بهبودش بدیم.

۳- و اما میرسیم به بحث جذاب تخمین. از نظر من تخمین درست کار خداست که تونست دنیا رو تو ۷ روز بی‌آفرینه و تازه معلوم نیست اون هفت روز واقعا چند روز بوده و بین علما اختلافه. یعنی چی؟ یعنی به تجربه به من ثابت شده که من و اکثر آدم‌هایی که دیدم نمیتونن درست تخمین بزنن. من خودم اینجوریم که اگه یه کاری از نظرم ۲ ساعت کار داشته باشه در عمل بطور متوسط ۶ ساعت طول کشیده تا انجامش بدم(من بصورت مداومی دارم چیزای مختلف رو میشمارم). و الان هر چی به ذهنم برسه و ضرب در ۳ میکنم. حالا این چه ایرادی داره. این باعث میشه من در هنگام قول دادن(بخونید پلنینگ) اگه بخوام زمان بدم همه چیز رو بدبینانه تخمین میزنم و این یعنی میزان کمتری کار تحویل میدم احتمالا. اما اگه بجای تخمین زمان در مورد بزرگی/سختی کار حرف بزنم و بگم این کار از نظر من واعضای تیم چقدر بزرگه، احتمالا تخمینم دقیق‌تره ولی زمانی هم براش نگفتم که بخوام چندبرابر تخمینم زمان بگم. و اگه چندتا اسپرینت بگذره عملا میتونم بگم من چقدر توان واقعی انجام کار دارم بدون اینکه تخمین زده باشم. نکته بعدی تخمین در آدمیزاد به تجربه ثابت شده که با بزرگ شدن کار بدتر میشه. یعنی من جارو زدن حال رو درست میتونم تخمین بزنم. ولی رفتن به کره ماه رو نه.
به همین خاطر اسکرام پوکر درست شده و از سری فیبوناچی که رشدش زیاده هم توش استفاده شده

فعلا همین!

لذت برنامه‌نویسی: کد موروثی

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

من این دفعه دومی هست که میرم توی SoftwareTalks شرکت میکنم و این دفعه در مورد legacy code که من دوست دارم کدهای موروثی ترجمه‌اش کنم حرف زدم. قبل یکیم توی اینترنت گشتم و این موضوعات رو پیدا کردم

ساختار صحبت‌های من در مورد کد قدیمی

  • تعریف کد قدیمی / موروثی

    • کد بد و قدیمی
    • کد بدون تست
  • راه‌های کار با کد قدیمی / موروثی

    • چرا بده؟
      • پیچیده است
      • سخت است
      • کندی توسعه
      • حوضله سر بر و انگیزه کش
    • فرصتها

      • ارزش آفرینی
      • یادگیری
      • انجام کاری که دوست داریم. حل مساله ولی از یه نوع دیگه
    • نکات تستی

      • نویسنده قبلی رو قضاوت نکنیم
      • تست شخصیت/ویژگی‌های کد
      • استفاده از ابزار تولید تست اتوماتیک
      • تغییرات کوچک به همراه قانون دسته پیش آهنگی
      • قدم‌های آهسته و پیوسته به سمت طراحی بهتر
      • نق زدن و اینا رو کنار بگذارید و کاری انجام بدید
      • قدم‌های صفر: ورژن کنترل و isuue tracker
      • با کد آشنا شوید و قسمت‌های قطعا بدون استفاده را حذف کنید
      • کم کم به سمت ci بروید
  • کد قدیمی که بهش افتخار کنیم. یا نگذاریم قدیمی بشه

خلاصه مطالب صحبت شده

حسین طالقانی عزیز هم لطف کرده صحبت‌های من رو توی این ویدئو رو خلاصه کرده که اینها هستند

کد Legacy کدیه که تست نداره!

نباید یادمون بره کد موروثی، یک ارزش کسب‌وکاری داره (یه کاری رو الآن داره درست انجام می‌ده!)
کد جدید تضمینی نداره که همون کار رو انجام بده :))

چرا با کد موروثی مشکل داریم؟
– چون «هر کدی که خودمون ننوشته باشیم بده»! چون یک اتفاقی اونجا داره میفته که من نمی‌فهممش، چون من ننوشتمش و کسی هم نیست کمک کنه. بعضی مواقع هم انقدری مستندات زیاده که باز کمکی نمی‌کنه!
– تغییر کد موروثی سخته، و نیاز به صبر داره و ما آدم صبوری نیستیم.
– «همه دارن با cloud و چیزای خفن کار می‌کنن، ما داریم با کدهای قدیمی سروکله می‌زنیم»

برای دور ریختن کد، باید به این سؤال جواب بدیم که «چرا؟». اینجا در مورد این صحبت نمی‌کنیم که محصول مرده یا دیگه ارزش کسب‌وکاری نداره (مثل ربات تلگرام و فیلتر شدن تلگرام) و به این خاطر کد رو می‌ریزیم دور.

چه کار بکنیم؟
۱٫ اگر source control نداره، اضافه کنیم!
۲٫ کم کم کد رو یاد بگیریم: فرصتیه برای حل مسئله‌ای که از جنس الگوریتم نیست؛‌ باز کردن کلاف سردر گم. ممکنه توی رزومه خیلی منعکس نشه، اما مهارتیه که همه بهش نیاز داریم «اگر نکشدت، قوی‌ترت می‌کنه» :))
۳٫ حذف قسمت‌های بلااستفاده (= خونه تکونی)؛ این بهم نشون می‌ده یک دور در کد زده‌ام.
۴٫ تصمیم‌گیری در مورد اینکه «ارزش وقت گذاشتن برای یک دور دیگر داره؟»
۵٫ از اینجا به بعد مسیر مستقیم نیست، یک سری روش داریم:
۱٫ نوشتن characteristic test: ثبت رفتار فعلی
۲٫ پیشاهنگی: وارد هر جایی عبور می‌شی، موقع خروج تمیزتر باشه
۳٫ از یک گوشه‌ای شروع به بازنویسی می‌کنیم: آن قسمت را از کد جدا کرده و تر و تمیز می‌نویسیم (به بقیه‌اش کاری نداریم!)؛ در کوتاه مدت کارمون سخت‌تر میشه (نمودار پیش‌رفت تخت یا نزولی میشه)
۴٫ بعد از اینکه تست اضافه کردیم، بریم سمت CI. لازم نیست چیز پیچیده‌ای باشه؛ بیلد کنیم و تست‌ها اجرا بشه تا مطمئن بشیم چیزی رو خراب نکردیم.
۵٫ تکرار مراحل بالا! (ترتیب نداره)
۶٫ با بهبود مستمر، نگذاریم کد پیر بشه؛ کسی از اینکه کرنل لینوکس یا شاهنامه بهش ارث برسه ناراحت نمی‌شه

سؤال و جواب

سؤال: از اول به بهترین روش کد بزنیم یا اسپاگتی به نتیجه برسیم و بعد درست کنیم؟

جواب:

ایده‌آل یه چیزیه تو ذهن ما فقط برای اذیت کردن ما :))

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

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

طبق بررسی‌های انجام شده، میزان خط‌های پاک شده ۱۰ برابر خط‌های اضافه شده است!

تصویر ایده‌آل رو باید نگه داشت، اما در عمل باید بهش توجهی نکرد. در بهبودهای کوچک به سمت این ایده‌آل باید حرکت کنیم.

سؤال: بدهی فنی رو چطور کنترل کنیم؟

جواب: همیشه بخشی از زمان رو بهش اختصاص بدین؛ مثلا ۱۰-۲۰ درصد.

کلمات قصار

  • ایده‌آل یه چیزیه تو ذهن ما فقط برای اذیت کردن ما
  • کد بد (Legacy) کدیه که تست نداره!
  • کد خوب کدیه که راحت می‌شه ریفکتورش کرد
  • optimization تا زمانی که تبدیل به درد نشده بیهوده است

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

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

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

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

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

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

clang -target arm-brcm-linux-gnueabi --sysroot=/arm-brcm-linux-gnueabi/arm-brcm-linux-gnueabi/sysroot -gcc-toolchain /arm-brcm-linux-gnueabi -fuse-ld=/arm-brcm-linux-gnueabi/bin/arm-brcm-linux-gnueabi-ld hello.c

حالا این تست رو که بتونید روی بردتون اجرا کنید میتونید اون رو با 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 من در دسترس هست.

ویدئو

در یوتیوب:

در آپارات: