امیدواری و عقلانیت

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

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

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

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

اما الان میخوام در مورد مصداق این موضوع بنویسم. و اون هم تاثیر «امیدواری» و «تعقل» از نظر من هست.

خب برای اینکه بحث یکم به ذهن نزدیک‌تر بشه من یه مثال میزنم. من در لار بدنیا اومدم و یه مدت هست که دوباره بهش برگشتم. ما یه شهر کنار لار داریم به اسم گراش که مثل هر شهرستان دیگه‌ای سر منابع محدود با هم در تعارض هستن. و کلا همیشه چالش دارن.

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

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

قاعدتا میدونید که از نظر مالی و توان نیروی انسانی و … لار و گراش شبیه هم هستند.از نظر من یکی از مهترین دلایل این رشد که در گراش وجود داره و در لار نیست، «امیدواری»ه . امید به اینکه مستقل شدن از الگوی سنتی منطقه دست پیدا کردنیه. همین امید و همین دستیافتنی بودن باعث شده که آدمها تلاش مدون و منطقی همراه با تعقل داشته باشن.

حالا همین الگو رو میشه در مقایسه با جایی مثل امارات و ایران یا ترکیه و ایران داشت. و به نظرم این تطبیق دادن الگو توی این مثالها هم غیر منطقی نباشه

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

ولی الان جامعه اینقدر توش عدم قطعیت و ریسک زیاد شده که داشتن امید به هدفی دستیافتنی خیلی کار سختیه
و بعید میدونم بیشتر از ۲ درصد آدمها بتونن داشته باشنش

همین!

مشتاقی و مهجوری

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

همینطور که از «رنگ رخساره»ی این پست نشون میده، یکم حال و هواش فنی نیست و میخوام در مورد یه تضاد درون خودم حرف بزنم. تضادی که حرف زدن ازش برام سخت بوده و هست.

مشتاقی

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

علاوه بر علاقه وافر به تولید، من علاقه بسی بیشتری به امتحان کردن و سرک کشیدن و تجربه جدید کسب کردن دارم، یعنی واقعا از رفتن و کشف کردن موضوع جدید، یادگرفتن، تجربه کردن واقعا لذت میبرم. پس اینجوری میشه که اسم وبلاگ من میشه «تجربه‌های پراکنده».

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

این میشه مشتاقی!

مهجوری

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

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

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

اینم میشه مهجوری!

خب که چی!

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

همین!

روند انتخاب شغل

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

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

من برای خودم یه روند تصمیم گیری این شکلی چیدم

که یه سری معیار رو ارزیابی میکنم و بعد اونها اولویت بندی میکنم و یه امتیاز نهایی در میارم و در نهایت انتخاب میکنم

معیارهای انتخاب شغل

من معیارهایی که برای انتخاب شغل دارم ایناست

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

اولویت بندی و امتیاز شماری

اینجا هر کسی بایستی برای خودش در بیاره که اولویت موارد بالا براش چطوره
یعنی مثلا برای من معیار انتخاب شغلم اینه

  1. پول
  2. کیفیت تیم
  3. کیفیت کار
  4. فرهنگ سازمانی
  5. تکنولوژی

بعد از اینکه این اولویت بدست اومد. توی هر زمینه به پیشنهادهای کاریتون امتیاز بدید. مثلا یه امتیاز از ۱ تا ۵ که امتیاز بیشتر به معنای دلچسب‌تر بودن توی اون زمینه است

حالا به هرکدوم از معیاره براساس اولویت یه ظریب با تفاوت کم بدید. یعنی
مثلا اولین اولویت ظریب ۱.۲ بگیره و با هر پله اومدن پایین در اولویت ۰.۱ از مقدارش کم کنید تا برسید ۰.۸

درنهایت انتخاب

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

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

همین!

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 نام داشته و داکر سعی در استاندارد کردن آن را دارد.