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

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

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

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

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

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

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

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

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

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

فعلا همین!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

سؤال و جواب

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

جواب:

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

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

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

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

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

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

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

کلمات قصار

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

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

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

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

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

  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. تهش پیاده کردن ساختار با سایز مشخص هست که کلی دردسر داره

همین

ویر کارایی و مقیاس‌پذیری: کارایی نتیجه طلایی تنبلی!

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

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

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

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

همین!

پ.ن. «ویر» مثل «ویرم گرفته بود» هست که به معنای میل شدید و ایناست.

لذت برنامه نویسی! در C متغیرها کجا تعریف می‌شوند

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

من مدت‌هاست که به عنوان یکی از کارهای اصلی به زبان C برای سیستم‌های Embeded برنامه می‌نویسم. یعنی یه دستگاه محدود رو آماده میکنم که یه کار خاص رو انجام بده.

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

اگه با اسمبلی آشنا باشید هر برنامه از سه قسمت Data, Code, Stack تعریف میشه. که خود  Data Segment هم از سه بخش Heap, Data, BSS تشکیل میشه. که توضیح هرکدوم این بخش‌ها داستان متفاوتی داره. حالا توی شبه کد پایین توضیح میدم که  اینها با هم چه تفاوتی داره

int a;

void myFunc(void)
{
	int b;
	static int c;
	int *d = malloc(sizeof(int));

	...

	return;
}

توی این شبه کد متغیر global به نام a وجود داره که توی data و یا ‌BSS تعریف میشه. متغیر b چون یک متغیر محلیه توی stack تعریف میشه. متغیر c یک متغیر محلی استایتک هست و به دلیل استاتیک بودنش توی data و یا ‌BSS تعریف میشه.  پوینتر d همه به یه آدرس توی heap اشاره میکنه چون این متغیر بصورت داینامیک تعریف شده و متغیر داینامیک در heap درست میشه. تفاوت data و BSS در اینه که متغیرهایی که مقدار اولیه غیر صفر دارن توی data تعریف میشن و متغیرهایی که مقدار اولیه ندارن و یا صفرن توی BSS تعریف میشن.

حالا مشکلی که وجود داشت اینه که من متغیرهای بزرگی توی متن تابع هام داشتم که باعث میشد حجم محدود stack موجود پر بشه و نرم افزار به خطای زمان اجرا بر بخوره. که با تغییر اونها به متغیرهای static محل نگهداری اونها به BSS یا Data تغییر مکان پیدا کرد و مساله حل شد.

همین!

بازگشت demonoid

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

من سال‌هاست که مهمترین منبع دانلودم تورنت هست. یه پروتکل peer to peer که خیلی مطمئن و کم هزینه میشه فایل دانلود کرد. تورنت یه مفهوم به نام tracker داره که توش لیست تمام فایل‌ها و اینکه چه کسی این فایل‌ها رو داره نگداری میکنه. یکی از tracker های مورد علاقه من که اولین سورس جستجو برای تورنت بود سایت demonoid بود که یک یا دو سال قبل توسط پلیس مورد حمله قرار گرفت و سایت بسته شد. اما امروز دیدم که بعد از مدت‌ها باز شده. و این خوشحال کننده است.

همین!

لذت برنامه نویسی! نگهداری و مدیریت نسخه‌ها و آنچه گذشت!

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

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

بصورت ساده این سیستم‌های به روش‌های مختلفی نسخه‌های مختلف فایل رو نگهداری می‌کنند یا «آنچه گذشت» رو مدیریت می‌کنند. این ابزار برای برنامه نویس‌ها و تقریبا هر کسی  که یه سری فایل رو بصورت مداوم بروز رسانی می‌کنه (مثلا متن یک قرار داد، یا یک مقاله علمی و …) مهمه. وقتی کار جدی می‌شه خیلی وقت‌ها به این نیاز میشه که بدونیم:

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

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

  • اولین و معمولا مهمترین دلیل مقاومت در مورد این سیستم‌ها اینه که افراد در قبال تغییر مقاومت میکنن و همیشه دوست دارن توی وضعیت فعلی بمونن. معمولا اجباره که باعث میشه آدم‌ها از وضعیت فعلیشون خارج بشن و یه چیز جدید یادبگیرن
  • دومین دلیل اینه که دلیل و اهمیت استفاده از این سیستم‌ها رو درک نکردن. یعنی نمیدونن که اگه از این سیستم‌ها استفاده کنن چه سودی نصیبشون میشه و درصورت عدم استفاده چه چیزی رو از دست میدن. من خودم به شخصه جز این دسته از آدمها بودم و الان بعد از مدت‌ها استفاده از این سیستم‌ها حتی سعی میکنم تاریخچه کارهای بی اهمیتم رو هم داشته باشم
  • سومین دلیل که به دلیل اول هم مربوط میشه اینه که «ترک عادت موجب مرض است» یعنی آدمها باید روندی رو که خیلی روزمره است و خیلی بهش عادت دارن عوض کنن.

اگه بخوام اسمی از این ابزارها بیارم لیستشون خیلی زیاده و دعوا هم سر اینکه کدوم بهتره زیادن. مثلا دوستانی که با ابزارهای مایکروسافت کار میکنن TFS رو با دنیا عوض نمی‌کنن. دوستانی که در محیط لینوکس برنامه نویسی میکنن و یکم هم قدیمی هستن از SVN تا خون در رگ دارن دفاع میکنن. و اونایی که «اوپن سور باز» هستن هم GIT رو میپرستن. اما دقت داشته باشید که از دید من مهم‌ترین قسمت اینه که یکی از این سیستم‌ها در محیط شما مورد استفاده قرار بگیره و اینکه اون ابزاری رو انتخاب کنید که اکثریت آدم‌ها نسبت بهش نظر خاصی ندارن و یا با اون سیستم به اصطلاح «راحتن».

اما لیست برنامه‌های کنترل نسخه اینا هستن:

  • Team Foundation Server: این برنامه توسط مایکروسافت تولید میشه که یک مجموعه کامل مدیریت پروژه نرم‌افزاریه که شامل برنامه کنترل نسخه هم هست. این نرم افزار جزء نرم‌افزارهای مدیریت نسخه متمرکزه.
  • GIT: این سیستم که توسط لینوس توروالدز نویسنده هسته لینوکس برای مدیریت کدهای هسته لینوکس مورد استفاده قرار گرفته. این سیستم جز سیستم‌های مدیریت نسخه غیر متمرکزه
  • CVS: تقریبا قدیمی ترین برنامه کنترل نسخه متمرکزیه که من میشناسم
  • SVN: یک سیستم مدیریت نسخه متمرکز است که طراحی شده تا با CVS همخوانی داشته باشه و اشکالات این سیستم رو رفع کنه
  • HG: هم تقریبا همزمان با GIT توسعه پیدا کرده و هدفش این بوده که سیستم مدیریت نسخه غیر متمرکز باشه.
  • Bazaar: سیستم کنترل نسخه غیر متمرکزه که توسط شرکت canonical پشتیبانی میشه

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

همین

سوتی‌های دانشکده مهندسی

اینم یه خالک زنک بازی پراکنده دیگه!

این متنا تجربه نیست، عملا خاله زنک بازیه. من این مورد ترجمه بد «دکتر محمود حسابی» رو میخوندم که گفتم برم یه سری هم به سایت دانشگاه تهران بزنم ببینم چه خبره. دیدم ای دل غافل که یه سوتی بزرگتر هم وجود داره و اون اینه که این دوستان از liferay به عنوان cms استفاده کردن. توی این اتفاقات اخیر اومدن که ابروش رو درست کنن چشمش هم کور کردن. یعنی امکان ادیت ویجت‌های صفحه اصلی وجود داره و خب به نظر من این خیلی جالب نیست. البته لازم به ذکره که بگم که از من پسورد خواست اما همینش هم زیاده!

همین!

توزیع بار چند اینترنت در pfSense

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

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

برای توزیع بار چند قدم ساده داره. یه مفهوم وجود داره به نام gateway که هر اتصال اینترنت یکی داره. در اولین قدم اینه که چندتا gateway رو با هم گروه‌بندی میکنید تا بتونید با استفاده از این گروه‌ها توزیع بار رو انجام بدید. در گروه یک اولویت به هر gateway اختصاص داده میشه و یه معیار برای اینکه کی بین اولویت‌های مختلف انتخاب انجام بشه. برای انجام این کار باید به منوی system -> routing رفت و توی tab به نام Group این گروه رو ساخت.

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

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

 

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

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

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

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

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

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

خب راه حل هایی که من باهاشون مستقیما کار کردم zeroshell و pfSense هست که یکیشون یه لینوکسه یک دیگش هم یه freeBSD  هست. اما دیدم دوستان با استفاده از kerio و محصولات cisco اینکار رو انجام دادن. هردوی zeroshell و pfSense امکاناتی دارند که به راحتی کانفیگ میشن و این کار انجام میشه.

این مقدمه برای این پست کافیه تا تو یه پست کامل توضیح میدم که اینکار pfSense چطور انجام میشه.