۱۳۹۴/۰۵/۳۱

معرفی Polymer، کتابخانه جدید گوگل

Polymer Logo

مقدمه

در شرکت داتیس پارس پروژه‌ای داریم که مسئولیت بخش Front-end آن به تیم ما سپرده شده است. قبل‌تر بخش Front-end با کتابخانه انگولار (AngularJS) توسعه داده شده بود ولی با ارزیابی‌های صورت گرفته، تشخیص بر آن شد که به جای AngularJS از کتابخانه Polymer استفاده نماییم. من از حامیان اصلی این تغییر بودم و حالا بعد از چندین هفته مطمئن شدم که گزینه درست را انتخاب نموده‌ام. این مطلب به معرفی کتابخانه Polymer می‌پردازد.
با توجه به در دسترس نبودن مستقیم سرویس‌هایی مانند Youtube و پروتکل HTTPS از داخل ایران و نیز تحریم‌های گوگل علیه ایران، ممکن است بخش‌هایی از ادامه مطلب را به صورت صحیح و یا کامل مشاهده نفرمایید.

بروزرسانی (دلیل استفاده از Polymer به جای AngularJS)

تعدادی از بازدیدکنندگان وبلاگ از طریق ایمیل و یا در بخش نظرات این مطلب، دلیل کنار گذاشتن انگولار و استفاده پلیمر را چندین بار از من پرسیدند و من جداگانه پاسخ هر یک را ارسال نمودم. حال قصد دارم تا مهم‌ترین دلایل این تغییر را برای تمامی بازدیدکنندگان فهرست کنم. ما برای تغییر فریم‌ورک از انگولار به پلیمر پارامترهای مختلفی رو در نظر گرفتیم:
  1. سادگی پلیمر (از نظر آموزش و توسعه)
  2. ارائه مدل وب کامپوننتی
  3. محدودیت زمانی
  4. سازگاری ساده‌تر با کتابخانه‌های مختلف
  5. در دسترس بودن Element های آماده برای تمامی نیازهای مد نظر ما
  6. تسریع در توسعه نرم‌افزار
  7. در حال حاضر ما از فریم ورک MVC در بخش فرانت اند استفاده نمی‌کنیم. مدل پلیمر متفاوت از پیاده‌سازی MVC است.
  8. انگولار نسخه ۱ از پلیمر پیشتیبانی نمی‌کند. طبق گفته تیم انگولار، پشتیبانی از وب‌کامپوننت‌ها از نسخه ۲ به آن اضافه خواهد شد.

معرفی Polymer (پلیمر)

پلیمر کتابخانه‌ی جاوا اسکریپت برای توسعه سایت‌ها و نرم‌افزارهای تحت وب است. به زبان ساده‌تر پلیمر مجموعه‌ای از وب‌کامپوننت‌ها (Web Component‌) آماده استفاده را در اختیار توسعه‌دهندگان قرار می‌دهند. مشابه راه‌کارهایی که کتابخانه‌‌های X-Tag و Bosonic فراهم می‌کنند.
وب‌کامپوننت به معنی ایجاد تگ‌های شخصی و خصوصی سازی شده برای استفاده در وب اپلیکیشن‌ها است.
مهم‌ترین هدف پلیمر تغریف زیرساختی برای شکستن کامپوننت‌ها بزرگ به بخش‌های کوچک‌تر است. این کار مزایای از جمله موارد زیر را برای توسعه‌دهدگان نرم‌افزارها به همراه دارد:
  1. کامپوننت‌ها مستقل از یکدیگر خواهند بود. در صورت طراحی صحیح معماری، تغییر در یک کامپوننت، منجر به ایجاد مشکل در سایر کامپوننت‌ها نمی‌شود.
  2. از نوشتن کدهای تکراری جلوگیری می‌شود. شما می‌توانید یک کامپوننت مشترک را در چندین کامپوننت دیگر براحتی استفاده نمایید.
  3. پلیمر (و به صورت کلی‌تر وب کامپوننت) سرعت توسعه نرم‌افزار را شتاب می‌بخشد.
  4. نگهداری (Maintenance) نرم‌افزار در بلندمدت کم هزینه‌تر خواهد بود.


پیش‌نیازها

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

نمونه کاربردی Polymer و Web Component

اگر از ابزارهای گوگل و یا سیستم‌عامل اندروید استفاده کرده باشید، مطمناً چشمتان به کامپوننت‌های پلیمر خورده است. به عنوان مثال بخش ظاهری (Front-end) نرم‌افزارهای Google Translate و اپلیکیشن Youtube بر روی گوشی تلفن همراه با استفاده از کتابخانه پلیمر پیاده‌سازی شده است.
در زیر با استفاده از کامپوننت paper-button دو دکمه و با استفاده از کامپوننت paper-toast دو نوتیفیکیشن ایجاد کرده ایم. با کلیک کردن بر روی هر دکمه نوتیفیکیشن مربوط به آن را مشاهده خواهد نمود:

از کجا یاد بگیریم؟

بهترین منبع برای یادگیری پلیمر وب‌سایت پلیمر به آدرس polymer-project.org است. این وب‌سایت و بخش عناصر (elements.polymer-project.org) به سرعت در حال تغییر و توسعه هستند. برای شروع پیشنهاد می‌کنم ویدئو معرفی Polymer 1.0 در همایش Google I/O 2015 را در ادامه مشاهده فرمایید:


منابع و اطلاعات بیشتر

پی‌نوشت: فرصت‌های شغلی

برنامه‌نویس جاوا اسکریپت

در صورتیکه به پلیمر علاقمند هستید و تجربه کافی در زمینه JavaScript و کتابخانه‌های آن مانند AngularJS، ‌BackBoneJS و... دارید، خوشحال می‌شویم که عضو جدید تیم ما باشید.

طراح رابط کاربری (UX/UI)

اگر تجربه لازم در طراحی رابط کاربری و آشنایی کافی با HTML و CSS دارید، خوشحال می‌شویم که عضو جدید تیم ما باشید.

برنامه‌نویس جاوا

در صورتیکه علاقمند به کار در بخش Back-end پروژه هستید، شرکت ما در حال جذب نیرو برای این بخش نیز است. آشنایی کافی با جاوا و داشتن تجربه کار تیمی مهم‌ترین معیار‌های جذب نیرو در شرکت ما است.

روزمه خود را ارسال کنید!

لطفا رزومه خود را به آدرس saeid.zebardast@gmail.com یا jobs@datispars.com ارسال نمایید. از ارسال رزومه برای کار پاره‌وقت و یا پروژه‌ای پرهیز کنید. در حال حاضر فقط نیروی تمام‌وقت جذب می‌کنیم.

۱۳۹۴/۰۳/۰۳

همایش نرم‌افزارهای متن‌باز و جشن انتشار اوبونتو ۱۵.۰۴

هفدهمین همایش لینوکس و جشن انتشار اوبونتو ۱۵.۰۴

سلام دوستان،
مانند گذشته، با انتشار نسخه جدیدی از اوبونتو، قرار است هفدهمین همایش گنو/لینوکس شامل معرفی اوبونتو ۱۵.۰۴ و ابزارهای مرتبط با نرم‌افزارهای آزاد و متن‌باز را برگزار کنیم. آخرین همایش حدود آذر ماه ۱۳۹۳ برگزار شد که من در آن کارگاهی با عنوان شروع کار با Java و MySQL داشتم.
این‌بار قرار با همکاری بچه‌های بسیار خوب شاخه دانشجویی ACM (انجمن علمی کامپیوتر دانشگاه تهران) و همت و کمک شما دوستان یک همایش پر محتوا برگزار کنیم.

برنامه های همایش

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

هفدهمین همایش لینوکس و جشن انتشار اوبونتو ۱۵.۰۴
هفدهمین همایش لینوکس و جشن انتشار اوبونتو ۱۵.۰۴

کارگاه‌ها

  1. کارگاه golnag -  فرود غفوری
  2. کارگاه رزبری‌پای - امیرحسین گودرزی
  3. کارگاه فایروال - ایمان همایونی و محمد ورمزیار
  4. کارگاه صفر تا صد اوبونتو - دانیال بهزادی
  5. کارگاه لاراول - گروه کاربران لاراول تهران
  6. کارگاه روبی آن ریلز - سمیر رحمانی و بهنام احمدخان بیگی
  7. کارگاه node.js - مهدی دهقانی
  8. کارگاه map reduce - دکتر بشیر سجاد
  9. کارگاه شروع سریع با VyOS - مهدی سرمدی

ارائه‌ها و سخنرانی‌ها

  1. سخنرانی عمومی - محمد تشکری
  2. داده انبوه (Big Data) - امیر صدیقی
  3. راه اندازی کسب و کار - دکتر بهراد غیاث الدین
  4. ده سال اوبونتو - ایریکس اسماعیلی
  5. اخبار - جادی
  6. اوبونتو تاچ - دانیال بهزادی

چطور در همایش حضور پیدا کنیم؟

شرکت در این همایش برای عموم علاقه‌مندان آزاد و رایگان است! تنها کاری که باید انجام بدهید ثبت‌نام جهت حضور در جشن است. برای ثبت‌نام به سایت همایش لینوکس و نرم‌افزارهای متن‌باز مراجعه کنید.
زمان: پنج‌شنبه، ۷ خرداد ۱۳۹۴ از ساعت ۸:۳۰ صبح
مکان: تهران - خیابان کارگر شمالی - بالاتر از خیابان جلال آل احمد - دانشکده‌ی فنی دانشگاه تهران

اطلاعات بیشتر

برای اطلاعات بیشتر می‌توانید به پیوندهای زیر مراجعه نمایید:

به امید دیدار شما در همایش :)

۱۳۹۴/۰۲/۲۰

راهنمای تکمیلی گیت (Git)

Git - گیت

مقدمه

مدتی قبل مطلبی با عنوان راهنمای کاربردی git منتشر کردم که شامل معرفی گیت و راهکارهایی برای استفاده از آن بود. مطلب امروز، راهنمایی تکمیلی برای شروع به کار با git می‌باشد. این مطلب به مهم‌ترین موارد مورد نیاز برای بررسی بعد از نصب گیت می‌پردازد.

مهم‌ترین کارها بعد از نصب گیت

قبل از هر چیز اگر راهنمای کاربردی git را تاکنون مطالعه نکرده‌اید، مطالعه نمایید!

ثبت مشخصات فردی

قبل از شروع به فعالیت و کامیت کردن کدها لازم است تا مشخصات فردی خود را در گیت لوکال خود ثبت نمایید. برای ذخیره نمودن نام و ایمیل خود از دستورات زیر استفاده نمایید. فراموش نکنید که مقادیر صحیح را جایگزین مقادیر پیش‌فرض نمایید:
$ git config --global user.name "YOUR NAME"
$ git config --global user.email YOUR_EMAIL

این مقادیر در فایلی با نام .gitconfig در پوشه خانگی شما ذخیره می‌شوند.

تغییر ویرایشگر متن پیش‌فرض

ویرایشگر پیش‌فرض متن برای ثبت پیام‌های commit در محیط اوبونتو، ویرایشگر nano است. شما می‌توانید هر ویرایشگر متنی را جایگزین ویرایشگر پیش‌فرض نمایید. دستور زیر، ویرایشگر قدرتمند vim به عنوان ویرایشگر پیش‌فرض پیام‌های گیت ذخیره میکند:
$ git config --global core.editor vim

تنظیم عمومی برای عدم کامیت کردن فایل‌های متفرقه

فایل‌هایی وجود دارند که شما هرگز نیاز به کامیت کردن آن‌ها ندارید. به عنوان مثال فایل .DS_Store که توسط سیستم‌عامل Mac OS به صورت خودکار بعد از مشاهده هر دایرکتوری ایجاد می‌شود. یا فایل‌های نسخه پیشتیبان که معمولا به کاراکتر ~ ختم می‌شوند. برای جلوگیری از کامیت شدن اینگونه فایل‌ها، ابتدا باید یک فایل .gitignore عمومی ایجاد نموده و نام فایل‌ها (یا قالب نام) را در آن ذخیره نموده و در نهایت آدرس آن را با دستور git config در تنضیمات گیت ذخیره نمایید.
$ touch ~/.gitignore_global
$ echo ".DS_Store" > ~/.gitignore_global
$ echo "*~" > ~/.gitignore_global
$ git config --global core.excludesfile ~/.gitignore_global

فعال کردن امکان نمایش رنگی خروجی‌های گیت

دستور زیر را برای فعال کردن نمایش رنگی و خواناتر خروجی های گیت (مانند دستور git log) در محیط خط فرمان اجرا نمایید:
$ git config --global color.ui true

در نهایت و بعد از انجام تنظیمات مورد نظر خود، می‌توانید با استفاده از دستور زیر فهرست تمامی تنظیمات ذخیره شده را مشاهده نمایید:
$ git config --list

معرفی چند مخزن رایگان برای آپلود پروژه‌ها

پیشنهاد می‌کنم تا جای ممکن پروژه‌های خود را (به صورت خصوصی یا عمومی) بر روی مخازن در وب آپلود نمایید. این مخازن می‌توانند بر روی سرور شخصی شما بوده و یا از سرویس های همگانی استفاده نمایید. شخصا پروژه‌های خصوصی خود را بر روی سایت bitbucket.org آپلود می‌نمایم. در زیر تعدادی از محبوب‌ترین سایت‌هایی را که سرویس همگانی برای git دارند را فهرست کرده‌ام:

ابزارهای گرافیکی برای کار با git

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

منابع


۱۳۹۳/۱۲/۲۵

استفاده از سرویس بلاگر بر روی دامنه شخصی

مقدمه

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

نحوه استفاده از دامنه (یا زیر دامنه) شخصی

در ابتدا باید دو آدرس CNAME برای تنظیم بر روی دامنه مورد نظر را از تنظیمات بلاگر دریافت نمایید.

دریافت آدرس‌های CNAME از بلاگر

برای اینکار به بخش زیر رفته و بر روی دکمه Setup a 3rd party URL for your blog کلیک نمایید:
  • Blogger Dashboard -> Blog Settings -> Publishing


در مرحله بعد آدرس دامنه یا زیردامنه (subdomain) مورد نظر خود را وارد نموده و بر روی دکمه Save کلیک نمایید. پس زدن دکمه، بلاگر به شما دو آدرس CNAME برای تنظیمات دامنه ارائه می‌دهد. به تصویر زیر توجه فرمایید:

در پنجره دیگری وارد تنظیمات هاستینگ یا دامنه خود شوید. تنظیمات CNAME در نرم‌افزارهای مختلف مشابه است. در ادامه روش مربوط به تنظیمات CNAME در  محیط سی‌پنل (cPanel) را مشاهده می‌نمایید.

تنظیم CNAME ها در محیط cPanel

قبل از هر چیز به این نکته توجه نمایید که برای استفاده از سرویس بلاگر بر روی زیردامنه، نیازی به ساخت subdomain ندارید. تنظیمات CNAME آدرس‌های مربوط به DNS زیر دامنه را مشخص خواهد کرد. مراحل زیر را به ترتیب انجام دهید:
۱- در زیر مجموعه Domains وارد بخش Simple DNS Zone Editor شوید:


۲- توسط فرم Add a CNAME Record باید اطلاعات مربوط به CNAME های دریافتی از بلاگر را اضافه نمایید. دقت کنید که بعد از وارد کرد Name مانند blog، اطلاعات دامنه به صورت خودکار به انتهای آن اضافه خواهد شد.

تنظیم نهایی سرویس بلاگر

در انتها و بعد از انجام تنظیمات مربوط به CNAME بر روی دامنه، بار دیگر وارد مدیریت وبلاگ خود در سرویس بلاگر شده و دکمه Save مربوط به فرم Setup a 3rd party URL for your blog را کلیک نمایید. در صورتیکه تمامی تنظیمات صحیح باشند، فرم ذخیره شده و وبلاگ شما به آدرس مورد نظرات منتقل (redirect) خواهد شد.

بروزرسانی‌ها

حل مشکل تصاویر

با توجه به در دسترس نبودن تصاویر سرویس بلاگر از داخل ایران، نیازمند تغییراتی در کدهای قالب بلاگ هستیم تا این مشکل را رفع کنیم. برای رفع این مشکل باید یک سرور ثانویه برای لود کردن تصاویر داشته باشید. مراحل زیر الگوریتم حل این مشکل را شرح داده است:
  1. استفاده از تابع btoa برای base64 encoding آدرس تصاویر در کدهای قالب وبلاگ در بلاگر.
  2. ارسال آدرس encode شده به سرور ثانویه که در خارج از ایران قرار دارد.
  3. decode کردن آدرس در سرور ثانویه.
  4. ساخت تصویر از آدرس مورد نظر در سرور ثانویه.
  5. نمایش تصویر ساخته شده.

پی‌نوشت

امیدوارم که در آینده، روش‌های نابخردانه که دستاوردی به جز اتلاف وقت به ارمغان ندارند، کنار گذاشته شود. هر عملی، عکس العملی را به دنبال دارد. به خاطر داشته باشیم که در بیشتر زمینه‌ها، از جمله تکنولوژی، هکرها و کرکرها (cracker)، همواره جلوتر از بقیه سیستم هستند.

۱۳۹۳/۱۲/۱۷

راهنمای کاربردی git

مقدمه

مدتی بود که قصد نگارش مطلبی برای معرفی و آموزش git (گیت) داشتم. این مطلب بعد از معرفی کلی git و اصطلاحات آن، نمونه‌ای از کاربردهای عملی آن را به روش پرسش و پاسخ، ارائه خواهد کرد. در نظر داشته باشید که git بسیار انعطاف‌پذیر بوده و ابزارهای بسیاری دارد. مطلب زیر مهم‌ترین کاربرد‌های آن را بیان نمونه و مستقیما از دستورات خود git در خط فرمان (و نه محیط‌های گرافیکی) استفاده نموده است.

git چیست؟

git یک نرم‌افزار آزاد و متن‌باز برای بازنگری کد منبع توزیع شده و مدیریت منبع کد است. گیت ابتدا برای توسعهٔ لینوکس توسط لینوس تروالدز به وجود آمد و اکنون پروژه‌های فراوانی از آن الهام گرفته‌اند. هر دایرکتوری کاری در گیت یک مخزن کامل با تاریخچهٔ کامل تغییرات و قابلیت بازنگری تغییرات است و برای کار با آن نیازی به دسترسی به شبکه یا سرور مرکزی وجود ندارد. گیت یک نرم‌افزار آزاد است که تحت عنوان جی‌پی‌ال نسخه ۲ توزیع شده است.
در پوشهٔ پایهٔ هر پروژه که با استفاده از گیت مدیریت می‌شود پوشه‌ای با نام git. (نقطه git) وجود دارد که تمامی اطلاعات مربوط به پروژه (تاریخچه، برچسب‌ها، ...) را در خود نگه می‌دارد. این ساختار بر خلاف ساختار سابورژن است که در هر زیرشاخه یک پوشهٔ svn. (نقطه svn) دارد. از جمله پرونده‌هایی که در پوشهٔ git. وجود دارند، config است که تنظیمات مخزن را در خود نگه می‌دارد.

اصطلاحات و لغات در git

در زیر مهم‌ترین اصطلاحات گیت را مشاهده می‌فرمایید:

مخزن (repository)

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

کامیت (commit)

منظور از کامیت، نسخه‌ای از تغییرات صورت گرفته بر روی اطلاعات و کدهای پروژه است. دستور commit در گیت،  نسخه‌ی از تغییرات در برنامه را ذخیره می‌کند.

شاخه (branch)

منظور از branch، سیر خطی توسعه است. هر پروژه می‌تواند چندین خط توسعه داشته باشد. 

برچسب (tag)

شما می‌توانید با استفاده از برچسب، اشاره‌گری به کامیتی مشخص ذخیره کنید.

مَستر (master)

به صورت پیش فرض، master یک شاخه در مخزن گیت بوده و در بیشتر موارد خط توسعه اصلی مخزن است.تصویر زیر به صورت گویاتر مفهوم مَستر، برچسب و شاخه  را ارائه کرده است:
برچسب‌ها و شاخه‌ها در گیت
مَستر، برچسب‌ها و شاخه‌ها در گیت

هِد (HEAD)

HEAD مشخص کننده checkout فعلی صورت گرفته در پروژه است.

دستور checkout

برای رجوع به برچسب، شاخه و هر وضعیت مشخصی در پروژه باید checkout نمایید.

دستور pull

دستور pull برای گرفتن آخرین تغییرات و وضعیت مخزن از سرور استفاده می‌شود.

دستور push

دستور push تغییرات و کامیت‌های ذخیره شده بر روی محیط لوکال را به سرور منتقل می‌کند.


سناریوهای کاربردی برای git

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

۱- یک پروژه در بر روی سیستم خودم دارم. چطور گیت را به آن اضافه کنم؟

بر روی کامپیوتر کلاینت خود، دستورات زیر را در محیط خط فرمان وارد نمایید:
$ cd my_project
$ git init
$ git add *
$ git commit -m "My initial commit message"
  • دستور git init یک مخزن برای گیت در دایرکتوری جاری ایجاد می‌نماید.
  • دستور git add فایل‌های مورد نظر را به مخزن گیت اضافه می‌کند.
  • دستور git commit، نسخه‌ای از تغییرات صورت گرفته را بر روی شاخه جاری ذخیره می‌کند.

۲- یک پروژه شامل گیت بر روی محیط کلاینتم دارم، چطور آن را به سرور منتقل نمایم؟

ابتدا باید یک مخزن گیت برای پروژه خود بر روی سرور ایجاد نمایید:
$ ssh git@example.com
$ git init --bare --shared my_project.git
$ chgrp -R devteam my_project.git
$ exit
  • دستور ssh برای اتصال سرور و ورود به محیط خط فرمان سرور مورد نیاز است.
  • دستور git init --bare --shared و پارامترهای استفاده شده، یک مخزن برای پروژه‌ای که توسط گروهی از افراد توسعه می‌شود، بر روی سرور ایجاد می‌کند.
  • دستور chgrp، مالکیت گروه دایرکتوری پروژه و محتوای آن را به اعضای گروه devteam منتقل می‌کند.
  • دستور exit برای خروج از سرور و بازگشت به محیط خط فرمان کلاینت مورد نیاز است.
در مرحله بعد با استفاده از دستورات زیر مخزن سرور را به پروژه اضافه نموده و اطلاعات لوکال را به سرور منتقل نمایید:
$ git remote add origin git@example.com:my_project.git
$ git push -u origin master

۳- چطور یک پروژه را از مخزن سرور دریافت کنم؟

روش‌ها و فرمت‌های مختلفی برای گرفتن یک پروژه از مخزن سرور وجود دارد. دستورات زیر روش گرفتن پروژه با استفاده از ssh را نمایش می‌دهد:
$ git clone git@example.com:my_project.git
$ cd my_project

  • دستور git clone یک نسخه از مخزن سرور را به محیط لوکال و سیستم شما منتقل می‌نماید.

۴- پروژه را تغییر داده ام (فایل‌هایی اضافه، حذف یا ویرایش کرده‌ام). چطور به مخزن سرور منتقل نمایم؟

قبل از انتقال تغییرات به سرور، ابتدا تغییرات صورت پذیرفته بر روی پروژه را بررسی نمایید:
$ git ls-files --deleted
$ git ls-files --modified
$ git diff
  • دستور git ls-files برای فهرست کردن فایل‌ها مورد استفاده قرار می‌گیرد. این دستور فیلترهایی برای محدودکردن بر اساس نوع تغییرات صورت گرفته دارد.
  • دستور git diff تغییرات فایل‌ها نسبت به آخرین کامیت را نمایش می‌دهد.
برای کامیت کردن تغییرات و ارسال تغییرات به سرور دستورات زیر را اجرا نمایید:
$ git add .
$ git commit
$ git pull
$ git push
  • دستور git add فایل‌ها جدید ویا تغییر پیدا کرده را برای کامیت کردن، اضافه می‌کند.
  • دستور git commit، نسخه‌ای از تغییرات صورت گرفته را بر روی شاخه جاری ذخیره می‌کند.
  • دستور git pull آخرین تغییرات مخزن سرور را به مخزن لوکال منتقل می‌کند. اجرای این دستور قبل از push کردن کد، در صورتیکه آخرین کامیت سرور بر روی مخزن لوکال وجود نداشته باشد، الزامی است.
  • دستور git push برای ارسال تغییرات از مخزن لوکال به سرور استفاده می‌شود.

۵- چطور یک شاخه (branch) بسازم و آن را در کنار شاخه‌های دیگر توسعه بدهم؟

دستور زیر یک شاخه جدید شامل آخرین تغییرات (حتی کامیت نشده ها) ساخته و آن را شاخه فعال (خط توسعه جاری) قرار می‌دهد:
$ git checkout -b [name_of_your_new_branch]

برای انتقال این شاخه به مخزن سرور دستور زیر را در سیستم لوکال اجرا نمایید:
$ git push -u origin [name_of_your_new_branch]

برای مشاهده تمامی شاخه‌ها می‌توانید از دستور git branch استفاده کنید. شاخه فعال در مخزن با یک * مشخص شده است. همچنین دستور git fetch، آخرین اطلاعات ساختار مخزن و شاخه‌های موجود را از سرور به مخزن لوکال منتقل می‌کند:
$ git branch
$ git fetch
$ git branch -a #show all remote and local branches

برای checkout کردن یک شاخه از سرور از دستور checkout استفاده نمایید. ممکن است قبل از دستور checkout، نیاز به اجرای دستور git fetch داشته باشید:
$ git checkout [branch_name]

۶- من و همکارم همزمان فایلی را ویرایش کرده و بعد از کامیت، در pull و push به مشکل برخورده‌ایم. چطور Conflict ها را رفع کنیم؟

در نمونه زیر، بعد از کامیت و pull کردن از مخزن سرور، git در ترکیب کردن (merge) فایل README.md با مشکل مواجه شده و از کاربر می‌خواهد که بعد از رفع تضادها (Conflict)، کد را دوباره کامیت و سپس push نماید:
$ git pull
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From repo:/opt/repositories/my_project
   c3e5e32..d773d5d  master       -> origin/master
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.
$ vim README.md #edit the file to fix conflicts
$ git add *
$ git commit -m "fix conflicts"
$ git push

  • در نمونه بالا بعد از ویرایش فایل README.md و رفع conflict ها کد را دوباره کامیت و سپس push کرده‌ایم.

۷- چطور دو شاخه را با هم ترکیب کنم؟

برای merge کردن دو شاخه باید از دستور git merge استفاده کنید. در زیر ابتدا به شاخه اصلی (master) رفته و سپس شاخه فرعی quickfix را با آن ترکیب کرده‌ایم:
$ git checkout master
$ git merge quickfix

۸- چطور یک شاخه را از مخزن لوکال ویا سرور حذف کنم؟

سه نوع شاخه مختلف برای حذف وجود دارد: شاخه لوکال (local branch)، شاخه سرور (remote branch) و شاخه سرور موجود بر روی لوکال (local remote-tracking branch). در زیر دستورات مرتبط برای حذف هر کدام از انواع شاخه‌ها را مشاهده می‌فرمایید.

حذف شاخه لوکال (local branch)

$ git branch --delete <branch> # delete local branch
$ git branch -d <branch> # shorter version
$ git branch -D <branch> # force delete un-merged branches

حذف شاخه سرور (remote branch)

$ git push origin --delete <branch> # git version 1.7.0 or newer
$ git push origin :<branch> # git versions older than 1.7.0

حذف شاخه سرور موجود بر روی لوکال (local remote-tracking branch)

$ git branch --delete --remotes <remote>/<branch>
$ git branch -dr <remote>/<branch> # shorter 
$ git fetch <remote> --prune # delete multiple obsolete tracking branches 
$ git fetch <remote> -p # shorter

۹- از تغییراتی که انجام داده‌ام پشیمان شده‌ام. چطور به آخرین نسخه برگردم؟

به منظور حذف تغییرات و بازگشت به آخرین نسخه کامیت شده بر روی مخزن، کافیست از دستور git reset به صورت زیر استفاده نمایید:
$ git reset --hard

۱۰- چطور تاریخچه کامیت‌ها و تغییرات فایل‌ها را مشاهده کنم؟

دستور git log برای مشاهده تاریخچه مخزن، یک فایل و یا نمایش تغییرات یک فایل به صورت زیر استفاده می‌شود:
$ git log # show all commit logs
$ git log [file_path] # show commit logs of the file
$ git log -p [file_path] # show history of the patches of the file

۱۱- چطور یک tag ثبت کنم؟

دستور git tag برای ذخیره برچسب‌ها استفاده می‌شود. git از دو نوع برچسب lightweight و annotated پشتیبانی می‌کند. نوع lightweight یک اشاره‌گر ساده به کامیتی مشخص است و هیچ اطلاعات دیگری مانند ایجادکننده tag را ذخیره نمی‌نماید. نوع annotated همانند یک کامیت عمل کرده و برخلاف نوع lightweight اطلاعات فرد ثبت کننده را ذخیره می‌نماید. در زیر نمونه ای از تعریف برچسب annotated و نحوه انتقال آن از مخزن لوکال به مخزن سرور را مشاهده می‌فرمایید:
$ git tag -a [tag name or version]
$ git show [tag name or version]
$ git push origin [tag name or version] # or git push origin --tags

برای ایجاد یک شاخه براساس یک tag باید از دستور checkout استفاده نمایید. در مثال زیر یک شاخه بر اساس برچسب v2.0.0 ایجاد کرده ایم:
$ git checkout -b version2 v2.0.0
Switched to a new branch 'version2' 

بروزرسانی

مطلب دیگری با عنوان راهنمای تکمیلی گیت (Git) نیز در وبلاگ منتشر کرده‌ام که پیشنهاد می‌کنم آن را نیز مطالعه فرمایید.



۱۳۹۳/۱۱/۲۸

پایگاه داده NoSQL

مقدمه 

در ادامه صبحت‌های که در پیشگفتار مطلب قضیه CAP در سیستم‌های توزیع شده، در این مطلب به معرفی پایگاه‌های داده NoSQL (نواس‌کیوال) می‌پردازم. این مطلب شامل معرفی نوع پایگاه داده NoSQL و ویژگی‌های آن است. در نهایت در مورد توضیحاتی در زمینه Polyglot Persistence ارائه خواهم کرد.

محدودیت های RDBMS و پیدایش جنبش NoSQL

همزمان با فراگیری دسترسی به وب در سطح جهان و با افزایش سرعت و حجم تولید اطلاعات، پایگاه‌های RDBMS مانند MySQL با محدودیت‌هایی مواجه شدند. این محدودیت ها عبارتند از:
  1. گسترش دادن  آن‌ها (Scalability) دشوار است.
  2. معماری آن‌ها به گونه‌ای است که در دسترس بودن تمام سیستم (Availability) دشوار نموده است.
  3. در ساختار و نوع ذخیره سازی اطلاعات محدودیت دارند.
  4. نحوه رشد آن‌ها به صورت Scale up است. به معنی اینکه برای افزایش کارایی باید سخت افزار هر سیستم را تقویت نمایید. در نتیجه هزینه تهیه و نگهداری سیستم‌ها به شدت افزایش می‌یابد.

پایگاه داده NoSQL چیست؟

عبارت NoSQL مخفف Not Only SQL بوده و به جنبش پدید آمدن مجموعه پایگاه‌های داده‌ای اطلاق می‌شود که مفاهیم متقاوتی با پایگاه های داده RDBMS مانند MySQL دارند. از جمله این مفاهیم می‌توان به موارد زیر اشاره کرد:
  • رابطه‌ای (Relational) نیستند. Join و مواردی از این قبیل که شامل رابطه‌ای بین چند جدول است، در NoSQL وجود ندارد.
  • به صورت افقی رشد می‌کنند. اصطلاحا Scale out یا Horizontally Scalable هستند. البته تمامی پایگاه‌های NoSQL امکان Scale out شدن را ندارد و برخی نیز به سختی Scale out می‌شوند.
  • امکان کنترل و مدیریت Availability (در دسترس بودن سرویس) ساده‌تر است.
  • گستره بیشتری از انواع داده و ساختارها را پشتیبانی می‌نمایند.

انواع پایگاه‌های داده NoSQL

انواع پایگاه های داده NoSQL
انواع پایگاه های داده NoSQL
یکی از مهمترین ویژگی‌های جنبش پایگاه‌های داده NoSQL پشتیبانی نمودن گستره عظیمی از انواع ساختار داده‌ها است. این ویژگی باعث انعطاف پذیری در مدل سازی و ذخیره اطلاعات شده است. از این رو پایگاه‌های داده NoSQL بر اساس مدل‌سازی اطلاعات به دسته‌بندی‌های زیر تقسیم می‌شوند:
  • Column: Cassandra, HBase
  • Document: CouchDB, Couchbase, MongoDB
  • Key-value: Dynamo, Redis, Riak
  • Graph: Neo4J, InfiniteGraph
  • Multi-model: OrientDB, FoundationDB
در نظر داشته باشید که انواع پایگاه‌های داده NoSQL برای منظورهای مختلفی طراحی شده است. به معنی آنکه هر کدام مزیت‌های خاص خود را دارند. به همین جهت در هنگام انتخاب پایگاه داده، عامل‌های زیر را در نظر گرفته و بررسی نمایید:
  1. نوع اطلاعاتی که قصد ذخیره سازی آن‌ها را دارید. 
  2. مدل سازی اطلاعات برای ذخیره و خواندن آن‌ها.
  3. میزان اطلاعات ورودی و خروجی سیستم.
  4. اهمیت Consistency و Availability در مدل تجاری‌تان. مطلب قضیه CAP در سیستم‌های توزیع شده را مطالعه نمایید.
  5. در دسترس بودن نیروی متخصص و مستندات کافی برای نگهداری سیستم (Maintenance)
نکته: با توجه به موارد قید شده در بالا، لزوما نمیتوان نوع خاصی از پایگاه‌های داده RDBMS یا NoSQL را به عنوان بهترین راه حل برای تمام بخش‌های یک سیستم در نظر گرفت. مارتین فاولر مفهوم Polyglot Persistence را برای توضیح بیشتر در این زمینه ارائه کرده است.

منظور از Polyglot Persistence چیست؟

هدف از Polyglot Persistence انتخاب و استفاده مناسب از پایگاه‌های داده متفاوت برای بخش‌های مختلف یک سیستم است. به بیان دیگر ممکن است در یک سیستم شما از چندین پایگاه داده استفاده نمایید. عبارت Polyglot به معنای دانستن زبان‌های مختلف بوده و Persistence نیز به معنای ادامه حیات است. با این اوصاف، مفهوم Polyglot Persistence یعنی ادامه حیات با استفاده از شناختن زبان‌های مختلف (در اصل و در اینجا، پایگاه‌های داده مختلف) است. به بیانی ساده‌تر، مفهوم Polyglot Persistence، همانند Polyglot Programming، انتخاب بهترین گزینه برای ادامه حیات موضوعی است که روی آن کار می‌کنیم. تصویر زیر Polyglot Persistence را به صورت گویاتر توضیح داده است:
Polyglot Persistence
Polyglot Persistence

بزودی مطالب بیشتری در زمینه Big Data منتشر خواهم کرد.

۱۳۹۳/۱۱/۱۶

قضیه CAP در سیستم‌های توزیع شده

پیشگفتار

مدتی است که در حال مطالعه در زمینه رایانش ابری (Cloud Computing)،  سیستم‌های کامپیوتری توزیع شده (Distributed Computer System) و بیگ دیتا (‌BigData) هستم. از طرفی برای پروژه‌های کاری شروع به استفاده از آپاچی کاساندرا (Apache Cassandra) کردم. مانند قبل به منظور به اشتراک گذاشتن تجربه، قصد نگارش مطالبی در این زمینه‌ها داشتم. متاسفانه محتوای فارسی در این زمینه‌ها بسیار اندک است. مقالاتی که قصد نوشتن آن‌ها را داشتم، به پیش‌نیازها زیادی داشت. از طرفی برخی مفاهیم به صورت مستقل معنی و مفهوم دارند. با توجه به این موضوعات، قبل از انتشار مقالات بیگ‌دیتا و آپاچی کاساندرا، مفاهیم و پیش‌نیازهای مرتبط را ارائه می‌کنم. قضیه CAP یکی از آن پیش‌نیازهاست.

مقدمه

امروزه تولید اطلاعات با سرعت سرسام آوری در حال رشد است. افزایش دسترسی مردم به اینترنت و نیز رشد روز افزون  شبکه‌های اجتماعی نمونه‌ای از این تولید اطلاعات است. همه روزه تعداد زیادی متن، عکس، ویدئو و... بر روی اینترنت قرار می‌گیرند. از طرفی، برخلاف گذشته، شرکت‌های بسیاری برای برنامه‌ریزی نقشه راه (Roadmap) و تعیین استراتژی، محتوای بسیاری از مشتریان را برای مدت طولانی ذخیره می‌کنند. سیستم‌های کامپیوتری توزیع شده از جمله مهم‌ترین راهکارها برای مدیریت این اطلاعات هستند. با افزدون هر رایانه به عنوان گره (node)  به این شبکه‌ها می‌توان بازدهی و توانایی آن‌ها را افزایش داد. رشد این شبکه‌ها به صورت افقی (Horizontal Scalability) یا همان Scale out است. در طی رشد این شبکه‌ها، پیچیدگی آن‌ها نیز افزایش می‌یابد. قضیه CAP برای توضیح مشکلات و محدودیت های این پیچیدگی ارائه شده است.

قضیه CAP

قضیه CAP
قضیه CAP

عبارت CAP ترکیب سرنام مفاهیم زیر است:
  • ثبات (Consistency): تمامی گره‌ها (nodes) اطلاعات یکسانی را در لحظه دارند.
  • دسترسی (Availability): هر درخواستی (request) حتما یک پاسخ دریافت خواهد کرد.
  • پارتیشن تولرنس (Partition tolerance): اگر بخشی از شبکه دچار مشکل شد، بقیه سیستم به کار خود ادامه خواهد داد. اشکال در بخشی از شبکه نباید منجر به توقف کار کل سیستم شود.
قضیه CAP بیانگر این موضوع است که در سیستم‌های توزیع شده شما فقط امکان فراهم کردن دو گزینه از سه گزینه Consistency, Availability و Partition tolerance را خواهید داشت و گزینه باقیمانده قربانی فراهم کردن سایر گزینه‌ها خواهد شد.
نکته: با توجه به مشکلات شبکه‌ای که در هر سیستم‌ای امکان بروز آن وجود دارد، توصیه متخصصین انتخاب قطعی Partition tolerant  به عنوان یکی از فاکتورهای گزینش شده است. انتخاب گزینه بعدی از بین Consistency و Availability کاملا به ماهیت نرم‌افزار و اولویت‌ها کارفرمای شبکه بستگی دارد. در ادامه توضیحات وضعیت گزینشی  AP و CP را مشاهده می‌فرمایید:

گزینش AP

انتخاب Availability و  Partition tolerance به معنی آن است که هر درخواستی، پاسخی دریافت خواهد کرد. این پاسخ تا جای ممکنه شامل جدیدترین اطلاعات خواهد بود ولی امکان قدیمی بودن آن نیز وجود دارد. از طرفی نوشتن اطلاعات جدید بر روی گره‌ها ممکن است در لحظه امکان پذیر نباشد (Partition tolerance). با این وجود سیستم به کار خود ادامه خواهد داد و در نهایت به ثبات اطلاعات خواهد رسید (Eventually Consistent). گزینش AP نشان‌دهنده این موضوع است که برای تجارت شما در دسترس بودن سیستم و سرعت بیشتر آن، اولویت بالاتری نسبت به ثبات و دوام اطلاعات در لحظه دارد.

گزینش CP

انتخاب Consistency و Partition tolerance به معنی آن است که هر درخواستی برای دریافت اطلاعات، دقیقا و حتما باید آخرین نسخه موجود را به عنوان پاسخ ارسال نماید. از طرفی، این آخرین نسخه موجود از هر اطلاعاتی بر روی سیستم کاملا مشخص و واضح است. یعنی اگر دو درخواست یکسان از دو مکان مختلف به سیستم ارسال شود، سیستم جواب یکسان و مشخصی را به هر دو خواهد داد. نکته دیگر اینکه با افزایش Consistency، شما مدت رکود (Latency Time) را نیز افزایش می‌دهید. هر میزان که Consistency مورد نیاز خود را افزایش دهید، سیستم دچار رکورد شده و سرعت پاسخ‌دهی کاهش می‌یابد.
نکته: بار دیگر تاکید میکنم که انتخاب AP یا CP کاملا به ماهیت نرم افزار و اولویت های تجاری کارفرما بستگی دارد.

جایگاه پایگاه‌های داده در گزینش CAP

پایگاه های داده مختلف گزینش های متفاوتی از CAP انجام می‌دهند. پایگاه‌های داده RDBMS به خاطر نوع طراحی و ماهیتی که دارند (ACID)، لزوما گزینش CA را انجام می‌دهند. بعضی از پایگاه های داده مانند Apache Cassandra انتخاب بین Availability و Consistency را بر عهده مدیر سیستم قرار داده است ولی به صورت بیش فرض خود گزینش AP را انجام می‌دهد. تصویر زیر تعدادی از پایگاه‌های داده و نحوه گزینش آن‌ها را به طور گویا بیان کرده است:
پایگاه‌های داده و قضیه CAP
پایگاه‌های داده و قضیه CAP

پی نوشت

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

۱۳۹۳/۱۱/۱۱

برنامه نویسی و فرقه بارپرستی

فرقه بارپرستی (Cargo Cult)
فرقه بارپرستی (Cargo Cult)

مقدمه

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



فرقه بارپرستی (Cargo Cult)

فرقه بارپرستی (Cargo Cult)
فرقه بارپرسی
در زمان جنگ جهانی دوم، آمریکا برای حمله به مواضع ژاپن، پایگاه‌های نظامی زیادی در جزایر بومی نشین جنوب شرق آسیا و اقیانوس آرام (منطقه ملانزی) ایجاد کرد. محموطه‌های غذایی، داروی و نظامی توسط بالگرد، هواپیما و کشتی به این پایگاه‌ها منتقل می‌شوند. بومیان منطقه نمی‌توانستند تصور کنند که این کالاها ساخته دست بشر باشد. آن‌ها بر این باور بودند که این محموله‌ها از طرف خدایان ارسال می‌شود.
راهنمای فرود بالگرد (Landing Signalman)
راهنمای فرود بالگرد
 آن‌ها رژه سربازان، فعالیت راهنمای فرود بالگرد (Landing Signalman) و مواردی از این قبیل را نوعی دعا برای خدایان می‌دانستند که موجب ارسال غذا و کالا از سوی خدایان می‌شود.
بعد از اتمام جنگ، بومیان به تقلید از نظامیان، لباس یکدست پوشیده و شروع به رژه رفتن کردند. برخی نیز با استفاده از چوب درختان شروع به تکرار حرکات راهنمای فرود پرواز نمودند. آنها بدون شناخت علت صرفا شروع به تقلید معلول کردند. آنها بدون وجود بالگرد، برای راهنمایی فرود آن تلاش میکردند!
با اینکه بسیاری از فرقه‌ها بارپرستی منسوخ شده‌اند اما چندین فرقه همچنان به فعالیت خود ادامه می‌دهند. برای اطلاعات بیشتر صفحه بارپرستی در ویکی‌پدیا را مطالعه نمایید.

فرقه بارپرستی (Cargo Cult)


برنامه نویسی و فرقه بارپرستی

در میان برنامه‌نویسان مبتدی و در برخی موارد متخصص، پیروی از اشتباهات فرقه بارپرستی به چشم می‌خورد. به مثال‌ها زیر توجه کنید:
  1. کپی و پیست کردن توابع از اینترنت بدون تست کامل آن‌ها. توابع مانند تبدیل مقادیر، ارزیابی صحت (Validation).
  2. تغییر در پارامترها غیر مرتبط و اتفاقی برای رفع مشکل.
  3. راه‌اندازی مجدد نرم‌افزار ویا سیستم بدون رفع مشکل (کندی یا Crash).
  4. افزودن توضیحات غیر ضروری به برنامه‌ای که کد آن بوضوح هدفش را توضیح می‌دهد.
تمامی  این موارد به طور مستقیم یا غیر مستقیم به نوعی پیروی از فرقه بارپرستی است. تلاش کنید تا همواره منشا مشکل را بیابید. مشکلی که یکبار اتفاق افتاده، مطمئنا بار دیگر نیز رخ خواهد داد. شناخت صحیح علت مشکل موجب عدم تکرار آن ویا موارد مشابه در آینده می‌شود. پس پیرو فرقه بارپرستی نشوید!

منابع و اطلاعات بیشتر