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

امروز با یه زبان جدید آشنا شدم که اسمش lua است. این زبان رو قبلا تو کانفیگ کردن nginx و جاهای دیگه هم دیده بودم. این زبان یک زبان مفصریه و یعنی کامپایلری نداره و زمان اجرا تفسیر و اجر میشه. این زبان به نسبت ساده است و با زبان‌هایی مثل javascript و scheme مقایسه میشه. چند روز پیش هم که داشتم توی اینترنت میگشتم دیدم که یکی از ویژگی‌های این زبان اینه که شما میتونی توی یک برنامه دیگه از اون استفاده کنی. یعنی مفسرش به برنامه اضافه میشه و برنامت میتونه به با استفاده از lua برنامه ریزی بشه و مثلا plugin براش طراحی بشه.

کل مساله ای که من میخواستم حل کنم و به نظرم lua برای این کار مناسب اومد اینه که، قراره برنامه‌ای نوشته بشه که بصورت داینامیک بشه منطق کسب و کار رو توش عوض کرد. یعنی اینکه تا دیروز براساس روند a عمل میشده و امروز روند b باید عمل بشه. راه‌حل‌های زیادی برای این مساله وجود داره که در جامع ترین حالتش شما باید یه زبان توصیف مخصوص به خودت درست کنی و از اون استفاده کنی تا منطق کسب و کار رو پیاده‌سازی و تست بکنی. خب این روش الان توی تقریبا همه‌ی سیستم‌های مدیریت روند‌های کسب و کار وجود داره ولی من به ذهنم رسید وقتی یه چیزی مثل lua وجود داره و به راحتی با برنامه‌ی شما integrate میشه چرا بایستی من با تجربه و توان محدودم بخوام یه شبه زبان برنامه نویسی طراحی کنم. یه چیز دیگه که باعث شد به استفاده از lua فکر کنم این بود که  مثلا یه بخش از برنامه رو توی یه زبان دیگه بنویسی و فقط توی lua از اون استفاده کنی. این باعث میشه کارهایی که نیاز به کارایی و این چیزا دارن در زبانه دیگه طراحی بشن و فقط lua اونها رو سر هم کنه.

بعد گشتم و سعی کردم شواهدی در اینترنت پیدا کنم که ایده‌ای که به ذهنم رسیده آیا درسته یا نه. دیدم که مثلا در طراحی بازی خیلی از این ویژگی استفاده وعملا lua یک زبان برنامه‌نویسی محبوب در بین توسعه دهنده‌های بازی هست. یا دیدم که نرم‌افزاری به نام freeswitch که برای راه‌کاری تلفنی مبتنی بر voip هست از lua  به عنوان زبان طراحی روند تماس استفاده میکنه. یا با استفاده از lua شما میتونی nginx رو کنترل کنی. همچنین دیدم یه جایی مثل cisco برای سطوح دسترسی پویا از این زبان استفاده کرده. حتی lua یک سرور مثل node.js به نام luvit داره اما به اون مشهوری نیست.

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

همین!

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

من به شخصه این مدت با توجه به ظهور پدیده ای به نام docker شرو ع به خوندن تکنولوژی‌های زیادی کردم که مهمترینشون مجازی سازی سبک یا مجازی سازی در سطح سیستم عامل هست. سعی میکنم در چند قسمت بصورت خیلی خودمونی و تو دل برو (بخوانید user friendly) بنویسم که این تکنولوژی‌های به چه دردی می‌خورن و کجاها استفاده میشن.

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

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

فعلا همین!

منتظر قسمت‌های بعدی این نوشته باشید!

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

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

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

  1. سرمایه اولیه: منظورم از سرمایه اولیه اینه که شما اگه بخوای این کار رو به بیرون بدی برات انجام بدن یا حداقل به خودت حقوق بدی چقدر پول لازم داری تا کارت شروع بشه. معمولا این مقدار هزینه‌های شروع کار به علاوه‌ی ساعاتیه که من روی این کار وقت میگذارم ضرب در درآمد ساعتی فعلیم
  2. حداقل واحد: کارهای مختلف واحد‌های مختلفی دارن. اگه شما سایت طراحی کنی به منظور از حداقل واحد، حداقل هزینه‌ای هست که به نظرت باید بگیری. اگه آموزش میدی حداقل قیمت ساعتی کلاست هست. اگه قطعه میفروشی حداقل درصد سودی که انتظار داری تا سراغ اون کار بری
  3. حداکثر واحد: منظور حداکثر مقدار سود آوری در اون ایده است.
  4. متوسط تعداد ماهیانه: منظور از این قسمت اینه که شما به چه تعداد می‌تونی در ماه با وضعیت فعلی کار انجام بدی. مثلا اگه قطعه میفروشی چند میلیون میتونی سرمایه گذاری ماهیانه کنی. اگه سایت طراحی میکنی چند تا سایت می‌تونی بصورت متوسط طراحی کنی و …
  5. تعداد ماه در سال: یعنی چند ماه در سال میتونی اون کار رو انجام بدی. خیلی از کارها فصلین. خیلی از کارها بازار دائم ندارن. مثلا اگه شما کلاس خصوصی بگذاری و دروس دانشگاهی رو درس بدی فقط در ۳ تا ۴ ماه در سال میتونی کلاس بگذاری. این محدودیت در خیلی از شغل‌ها وجود داره.
  6. معیار ریسک: یک عدد بین یک تا پنج که یک نشان دهنده حداقل ریسک و ۵ نشان دهنده حداکثر ریسکه

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

  1. حداقل درآمد ماهیانه: این عدد به راحتی از حداقل سود ضرب در متوسط ماهیانه بدست میاد که نشان‌دهنده اینه که در کوتاه مدت حداقل انتظار از درآمد ماهیانه از این ایده چقدره
  2. حداکثر درآمد ماهیانه: این عدد نشان‌دهنده اینه که انتظار بیش از این عدد از یک ایده نا معقوله
  3. متوسط درآمد ماهیانه: این عدد نشان‌دهنده اینه که در کل چه انتظاری از این ایده داشته باشی
  4. حداقل در آمد سالیانه: این عدد برابر حداقل در آمد ماهیانه ضرب در تعداد ماه در ساله. یک معیار تقریبا بلند مدت از حداقل در آمده
  5. حداکثر درآمد سالیانه: این عدد میگه که انتظار بیش از این عدد از یک ایده در سال نا معقوله
  6. متوسط درآمد سالیانه: این عد نشان‌دهنده اینه که در کل چه انتظاری از ایده در بلند مدت داشته باشی

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

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

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

idea_analysis_1 idea_analysis_2

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

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

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

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

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

همین!

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

پست‌های مرتبط با ۸۵۸۳ منجر به یه سری سوال جواب ایمیلی شده که من سعی مکنم با اجازه کسانی که سوال پرسیدن اونها رو اینجا باز نشر میکنم. البته بگم اینها همه نظارت و تجربیات مستقیم من هست نه چیز دیگه ای

سوال

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

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

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

امروز داشتم توی وب میگشتم و در مورد docker میخوندم که چشمم به این پست خورد که چطور توی pantheon تونستن با استفاده از تکنولوژی‌های مرتبط به container تونستن یه بیزنس بسیار جذاب برای ارائه یه نوع هاستینگ خاص مرتبط با drupal و wordpress بسازن. اما نکته‌ای که داشت این بود که یکی از نکاتی که منجر به خفن شدن سیستم اونها شده بود استفاده از یه ویژگی systemd به نام socket activation بود. که من یکم در موردش خوندم و بسیار ازش لذت بردم و گفتم ازش بنویسم.

قصه از اینجا شروع میشه که توی سیستم‌های مبتنی بر یونیکس از قدیم الایام یه چیزی وجود داشته با نام SysV که قدمهای مرتبط با boot سیستم توی اونجا انجام میشده. یعنی اینکه فرض کنید برای اینکه لینوکس بطور کامل بالا بیاد نیاز به داره که ۱۰ تا سرویس اجرا بشه و هر کدوم از اونها یه سری وابستگی دارن که این سیستم این قدم‌ها رو با توجه به وابستگی‌هاش اجرا میکنه. نحوه اجرا شدن این قدم‌ها توی SysV بصورت ترتیبی است که این روند باعث افزایش زمان مورد نیاز برای boot شدن سیستم میشه. توی MacOs از سیستم به نام launchd برای کاهش زمان boot پیاده‌سازی شده. همچنین توی لینوکس  راه حل‌هایی برای اجرای موازی سرویسهایی که به همدیگه وابسته نیستن مثل upstart اوبونتو توسعه پیدا کرده. اما مشکل سرعت کم boot بصورت کامل رفع نشده. به همین خاطر systemd پیاده‌سازی شده و از ساز و کاری به اسم socket activation ایجاد شده که سرویس‌ها هم بتونن با سرعت لود بشن هم مشکلی بوجود نیاد.

تقریبا همه چیز در لینوکس معمولا این سرویسها ارتباطشون از طریق socket ها ایجاد میشه و از socket به عنوان IPC استفاده میشه. حالا ایده اینه که بجای اینکه کل پروسس مربوط به یک سرویس بالا بیاد و بعد اون بیاد و سرویس رو ایجاد کنه، systemd بجای پروسه اصلی سوکت رو ایجاد کنه و هر وقت اولین درخواست به این سوکت رسید سرویس اجرا بشه و سوکت باز شده هم در اختیار پروسس این سرویس قرار بگیره. خوبی این روش هم اینه که تقریبا تمام سرویس‌های متونن همزمان اجرا بشن و خب در صورتی که یه سرویس زودتر از یه سرویس دیگه اجرا بشه و به سرویس کند نیاز داشته باشه درخواست‌هاش رو به سوکت مربوطه میفرسته تا زمانی که این سوکت بتونه چیزی دریافت کنه-لازمه بگم که هر سوکت میتونه به حجم محدودی اطلاعات رو توی خودش نگه داره- پس از اون کرنل دخالت میکنه و برنامه‌ یا برنامه ‌هایی که میخوان به اون سوکت بنویسن رو بصورت موقت متوقف میکنه. تا سرویس دهنده اجرا بشه و بیاد به درخواست‌ها پاسخ بده و سوکت با امکان نوشته شدن داشته باشه. این ایده جدید نبوده و توی inted ملقب به superserver هم برای سرویس دهنده‌های اینترنتی مثل ftp مورد استفاده قرار گرفته. اما systemd ایده رو توسعه داده و بجای سوکت‌های اینترنتی از همه نوع سوکتی پشتیبانی میکنه. این روش سود‌های دیگه‌ای هم داره:

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

همین!

منابع:

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

  1. این سایت اصلیه که کلی اطلاعات جذاب توش داره.
  2. این سایت نویسنده یا یکی از نویسندگان اصلی systemd هست
  3. اگه برنامه نویس هستید و میخواد با این مفهوم بیشتر آشنا بشید این مطلب و این یکی رو هم بخونید