<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های صادق محبی</title>
        <link>https://virgool.io/feed/@mohebbisadegh</link>
        <description>برنامه نویس node js و DevOps کار  - دانش‌آموخته اقتصاد علاقه‌مند به کارآفرینی و استارتاپ ها - sadeghmohebbi.ir</description>
        <language>fa</language>
        <pubDate>2026-04-15 10:08:32</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/8056/avatar/dWXYqA.jpg?height=120&amp;width=120</url>
            <title>صادق محبی</title>
            <link>https://virgool.io/@mohebbisadegh</link>
        </image>

                    <item>
                <title>چند تجربه از مصاحبه‌ های دواپس که آنها نمی‌خواهند شما بدانید!</title>
                <link>https://virgool.io/@mohebbisadegh/%DA%86%D9%86%D8%AF-%D8%AA%D8%AC%D8%B1%D8%A8%D9%87-%D8%A7%D8%B2-%D9%85%D8%B5%D8%A7%D8%AD%D8%A8%D9%87-%D9%87%D8%A7%DB%8C-%D8%AF%D9%88%D8%A7%D9%BE%D8%B3-%DA%A9%D9%87-%D8%A2%D9%86%D9%87%D8%A7-%D9%86%D9%85%DB%8C-%D8%AE%D9%88%D8%A7%D9%87%D9%86%D8%AF-%D8%B4%D9%85%D8%A7-%D8%A8%D8%AF%D8%A7%D9%86%DB%8C%D8%AF-sloiwfv7b6lu</link>
                <description>از ابتدای امسال به مصاحبه‌ی موقعیت شغلی دواپس یا SRE چندین شرکت متنوع بزرگ و کوچک رفتم و به چند موضوع رسیدم. تصمیم گرفتم تا دیر نشده و تب جا به جایی داغه و در فصل نقل و انتقالات هستیم ، این تجربیات خودم رو مکتوب کنم تا شاید به درد کسی بخوره و البته برای خودم هم به یادگار بماند.در اینکه وضعیت کلی کشور تعریفی نداره شکی نیست. برای کسانی مثل من که شرایط مهاجرت را نداریم هم چاره ای نیست و باید در این شرایط مثل مار زیرک و انعطاف پذیر باشیم.دسته بندی شرکت هابه نظرم تقسیم بندی شرکت ها به دولتی و خصوصی ، برایم تقسیم بندی کاربردی ای نبود. چیزی که متوجه شدم و در این مدت پی بردم اینه که باید ببینیم مشتری عمده‌ی شرکت چه کسانی هستند. آیا شرکت b2b/b2g است یا b2c . یک نام گذاری جالبی که به ذهنم رسیده براشون اینه: شرکت آیا مردم پرست عه یا رابطه پرست! ویژگی های این دو دسته از شرکت ها فارغ از خصوصی/خصولتی/دولتی بودن ، از زاویه دید بنده ، اینهاست:عاشق ساختن همبرگر و فروش اون و اهمیت به لذت بردن مشتریان مثل باب اسفنجیشرکت های مردم پرست: فشار کاری در این شرکت ها بیشتره و عمده‌ی وقتتون در شرکت به بررسی مشکلات پیچیده و سنگین مشغول هستید. معمولا همیشه بیشتر از ظرفیت تیم کار وجود داره و اگر نبود استخدام نمی شدید. تکنولوژی ها در سطح بالاتری قرار داره (ولی در عین حال حتما چند تا سرویس legacy هست که باید نگهداری بشوند). جنس مسائل از نوع کاهش فروش و ترافیک هست و سوددهی شرکت بسیار مهمه. تیم بازاریابی موتور پیشرانه‌ی شرکت هست و به خیلی از تصمیمات محصولی جهت میده.عاشق بودجه و رفیق و آشنا و پروژه و سر و کله زدن با انواع مختلف آدم ها مثل آقای خرچنگشرکت های رابطه پرست: نیرو ها فقط در زمان های نزدیک ددلاین پروژه فشار کاری زیادی را تحمل می‌کنند و در خارج از این زمان فشار کاری بسیار کمتره. چالش های این شرکت ها بیشتر از نوع تعامل با کارفرما و قدرت چانه زنی و فضای اعتماد این وسط میاد. تکنولوژی ها می تونه سطح بالایی داشته باشه (اگر درخواست های عجیب و غریب و دخالت های بیجای کارفرما نباشه!) ولی معمولا برای آپدیت نگهداشتن تعهدی نیست و پس از یه مدت قدیمی میشه. جنس مسائل از نوع مدیریت ذی‌نفعان و سر و کله زدن با کارفرماست و بیشترین کلمه ای که ممکنه بشنوید اسم پروژه ها و کارفرما هاست. تیم محصول و پشتیبانی فنی موتور پیشرانه‌ی این شرکت هاست. دانستن این دسته‌بندی چه فایده ای داره؟ وقتی می خواهید رزومه تون رو ارسال و یا آفر هارو بررسی کنید ، اولویت محیط کاری تون و اینکه در چه نوع شرکت هایی علاقه‌مندید کار کنید اهمیت زیادی داره.اقیانوس بدون گودال نداریمگستردگی و چندرنگی شاید یکی از مسائل و خاصیت های اصلی مسیر شغلی دواپس هست. به دو دلیل افرادی که در موقعیت های شغلی ادمین سیستمی / دواپس / SRE هستند به سمت گستردگی بیشتر سوق داده می‌شوند:۱- ابزار های فرایند دواپس بسیار متعدد و متنوع است و برای پیشبرد حرفه ای کار ها عمدتا از چندین ابزار استفاده می‌کنیم.۲- ذاتا فرد دواپس کار موفق بیکار است یعنی فرایند تمیز و خوبی را چیده که به درستی کار می‌کند پس وقت خالی دارد. در کنار این فضا ، نیازمندی و کار های شرکت آرام آرام به سمتی پیش می‌رود که حوزه‌ی مسئولیت گسترده تر و کار های بیشتری به پوزیشن دواپس داده شود.پاتریک از هر انگشتش یه هنری می بارید! ولی ...در این شرایط اگر فشار کاری بالایی داشته باشید و به هر دلیلی فرصت عمیق شدن در حداقل یک حوزه را نداشته باشید قطعا متضرر خواهید شد. متوجه شدم که برند شدن در یک حوزه‌ی خاص بسیار اهمیت دارد. مثلا بگویند که فلانی استاد لینوکس و امنیت است یا بهمانی سلطان کلود استورج است. باید به همچین عناوینی معروف شویم.البته در موقعیت شغلی دواپس ، اتفاقا گستردگی نسبت به سایر موقعیت های شغلی اهمیت بالایی دارد ولی در عین حال و به همان اندازه ، عمیق شدن در یک یا دو حوزه تخصصی بسیار مهم است.مد امروز ممکن فردا فراگیر بشهبه مد و هایپ جامعه تکنولوژی توجه کنید. از چه نظر؟ بگذارید چند مثال بزنم.راهکار های cloud: در یک زمانی کوتاه کلی بحث و گفتگو در موردش می‌شد و تعداد زیادی شرکت در این حوزه تشکیل شدند ولی چیزی که امروزه می بینیم استفاده از این سرویس ها به آرامی زیاد می‌شود و به سرعت فراگیر نشد.کوبرنتیز و دنیای کانتینر ها: هایپ بسیار شدیدی داشتند و برای مدت کوتاهی مقاومت وجود داشت ولی به کمک Docker اعتماد به کوبرنتیز در بین شرکت ها ایجاد و در مدت کوتاهی فراگیر شد.هوش مصنوعی: امروزه در موردش هر جایی که ببینید صحبت میشه و دنیارو متاثر کرده. به نظرم در مدت کوتاهی مثلا ۵ سال سبک تولید نرم‌افزار و خدمات دهی به کاربران تغییر کنه و مبتنی بر هوش مصنوعی بشه و در این صورت در تمامی فراگیر خواهد شد. ابزار های MCP مثلا Docker MCP یا Atlassian Jira MCP تلاش هایی در همین زمینه‌ی فراگیری هوش مصنوعی است.هوش مصنوعی نمی‌تونه جای مارو بگیره :)برای اینکه از بازار کار عقب نیوفتیم باید حواسمان به تکنولوژی های جدید باشد. امروز که باهاتون صحبت می‌کنم، پای ثابت مصاحبه‌ های دواپس / SRE شرکت ها - حدود ۷۰ درصد فرض کنیم - Kubernetes و Ansible است و در رتبه های بعدی Gitlab CI و ELK stack قرار دارند. یادم هست که قبلا این تکنولوژی ها به این شکل متداول نبود ولی الآن نیازمندی شرکت ها و بازار کار شدند. همین داستان برای هوش مصنوعی با شدت و قدرت بیشتری در حال وقوع است.پس‌نوشت۱: کتاب وسعت یا عمق (متنی و صوتی) خیلی جالب بود. قبلا کتاب صوتی اش رو گوش دادم. خیلی علمی به موضوع گستردگی یا عمق پرداخته پیشنهاد می‌کنم مطالعه اش کنید.پس‌نوشت۲: عنوان نوشته رو طوری نوشتم که کلیک بخوره و متن نوشته رو هم طوری نوشتم که توی ذوق بخوره و عکس هارو هم طوری انتخاب کردم که درگیر خنده های عصبی بشیم. دیگه به بزرگی خودتون ببخشید.</description>
                <category>صادق محبی</category>
                <author>صادق محبی</author>
                <pubDate>Mon, 05 May 2025 03:08:40 +0330</pubDate>
            </item>
                    <item>
                <title>داستان هر اپیزود از ایده تا انتشار</title>
                <link>https://virgool.io/nimche-barname-nevis/%D8%AF%D8%A7%D8%B3%D8%AA%D8%A7%D9%86-%D9%87%D8%B1-%D8%A7%D9%BE%DB%8C%D8%B2%D9%88%D8%AF-%D8%A7%D8%B2-%D8%A7%DB%8C%D8%AF%D9%87-%D8%AA%D8%A7-%D8%A7%D9%86%D8%AA%D8%B4%D8%A7%D8%B1-eujcqsu1a83y</link>
                <description>من صادقم و اینجا نیمچه برنامه نویسه، جایی که داستان و روایت با تکنولوژی نرم افزار ترکیب میشه. امروز قراره در این نوشته داستان «از ایده تا انتشار هر اپیزود» رو بخونیم. بزن بریم!مقدمهبیش از ۶ ماه شده که کار پادکست رو شروع کردم. در این مقاله به بهانه‌ی گذشتن تعداد دنبال کننده ها از ۱۰۰ ، تصمیم گرفتم ریز و درشت هر چیزی که در فرایند تولید پادکست یاد گرفتم و اجرا می‌کنم را باهاتون به اشتراک بگذارم. عکس ابتدای مقاله خیلی شسته رفته و تر و تمیزه ولی در حقیقت تولید پادکست فوق العاده فرایند سخت و پرفشاریه مخصوصا در اوایل راه و چند اپیزود اول. پس آماده باشید که قرارست مسیر پر پیچ و خمی را با همدیگر در این نوشته طی کنیم.ایدهتک به تک ایده‌ی اپیزود ها رو که مرور می‌کنم، منابع ورودی ایده برای من بسیار متنوع بوده. از یک پست کوتاه لینکدین گرفته تا خبرنامه‌ی دریافتی در ایمیل شخصی و یا حتی اتفاقی حین نوشتن متن اپیزود یا رفتن دنبال ایده‌ی دیگر. اگر بخوام دقیق تر بگم ، منابع ورودی ایده‌ی هر اپیزود از اینجاها شروع می‌شوند:سوال در خصوص موضوعی دقیق از chatgpt و خواستن لینک های مقاله از او (مثلا ۱۰ مقاله از کالبدشکافی Downtime شرکت ها برایت از وب جستجو کند و بیاورد)دنبال کردن بلاگ های فنی شرکت های مطرح و خلاصه کردن مقالات جذاب آن از نظر خودت (مثلا اسلک یا اسپاتیفای . تعدادشون زیاده و هر کدوم معدنی از طلاست!)عضویت در خبرنامه های ایمیلی مفید و گشتن در آن‌ها (مثلا Medium و SubStack)هر ایده‌ ای که دیدید رو هم در جایی بنویسید و لینک مقاله آن را ذخیره کنید. اگر ایده ای به ذهن و نظرتان نمی‌رسد ،‌ دو تا کار کنید. اولا بیشتر با chatgpt صحبت کنید و دوما بیشتر بنویسید و بخوانید. شده که من برای عنوان اپیزود یا بخشی از متن اپیزود بار ها از chatgpt کمک گرفته ام. فعلا چرت و پرت می گوید ولی ایده هایی نیز نهفته دارد.متناگر پادکست مونولوگ صبط کنید ، به نظرم مهم‌ترین بخش هر اپیزود متن آن است. اینکه متن اپیزود را چگونه بنویسیم ، علی بندری عزیز در یک جلسه از سیر تا پیاز «چگونه پادکست بسازیم - گارگاه دوم - علی بندری»‌ را می‌گوید و در این زمینه فوق العادست. من نکات بنیادی بیشتری ندارم اضافه کنم ولی در خصوص ابزار نوشتن متن‌ها، بعد از چند بار تلاش و امتحان کردن سرویس های مختلف ، به اپلیکیشن و سایت بسیار خوب Notesnook رسیدم. تمامی متن ها را در این سایت و اپلیکیشن می‌نویسم. یک مزیت بسیار عالی این سرویس این است که در تمامی پلتفرم ها اپلیکیشن مناسبی با قابلیت نوشتن آفلاین و sync شده لحظه ای را دارد. در هر جایی چه روی مبل لم داده باشم یا در مترو تحت فشار صبحگاهی مسیر رفتن به شرکت باشم ، می‌توانم متن پادکست را بنویسم. (ولی در بیشتر اوقات متن پادکست پشت سیستم خونه دقیقا قبل از ضبط تکمیل میشه!)کلی هم theme و حالت نمایش و دسته بندی داره. رو دستش ندیدم هنوزضبطیک خبر خوب بهتون بدم. هر چقدر هم که صدا بد باشه ابزار هایی که در ادیت صوت پادکست داریم می‌تواند کیفیت آن را تا حد خوبی ارتقا دهد. پس برای ضبط نگران میکروفن نباشید. من از یک میکروفن یقه ای ساده‌ی ارزون که خیلی وقت پیش خریدم استفاده می‌کنم. ظاهرا می‌توان با میکروفن هدست یا حتی میکروفن خود موبایل هم ضبط کرد. به هر حال من این میکروفن یقه‌ای را دستم می‌گیرم و گوشی وصل می کنم و با نرم‌افزار Voice Recorder خود گوشی اندروید متن را روان می‌خونم.این همون میکروفونیه که پادکست باهاش ضبط میشهمکان ضبط هم مهمه. در خانه ساکت ترین جایی که پیدا کردم پشت میز کامپیوتر بود. البته نویز های زیادی هنوز هست (مثلا صدای فن کامپیوتر) که میشه با نرم افزار این نویز هارو از فایل صوتی حذف کرد. اگر نویز ها خیلی زیاد و عجیب نیستد نگران نباشید اینطوری راحت ترید. در خصوص این موضوع آقای آهن پاره و دمپایی کهنه پادکست رادیو گیک جادی معروفه. دارم اینو می‌گم که کلا سخت نگیرید ، حتی میشه مثل جادی با نویز ها توی پادکست شوخی کرد.اینجا همون کنج عزلت ایه که پادکست در اونجا ضبط میشهتوی برنامه‌ام هست که در آینده‌ی نزدیک این میکروفون برند مائو رو بخرم و به شما هم پیشنهادش می‌کنم.ادیتبرای ویرایش و ساخت فایل نهایی اپیزود ابزارها و روش های زیادی هست. از اپ های موبایل گرفته تا کامپیوتر کلی نرم‌افزار خوب و حرفه ای برای این کار هست. روشی که در ادامه می‌گم قطعا بهترین نیست و خودتون حتما تحقیقی داشته باشید. فقط یک اصل رو که در ادامه می‌گم حتما در نظر داشته باشید.حجم صدا و ضربآهنگ پادکست از اول تا آخر باید در یک محدوده مشخص باشه و معمولا برای پادکست بین ۶ تا ۸ متداوله. عکس زیر برای یکی از اپیزود های پادکست خودمون هست که برای من این عدد معمولا بین ۶ تا ۳ هست (یخورده حجم صداش زیاده) ولی این رو در تمام طول پادکست حفظ می‌کنم.نوار رنگی پایین نشان‌دهنده‌ی حجم صداست که اینجا بین -۶ تا -۳ است.اهمیت این موضوع خیلی زیاده. یادمه چند وقت پیش اتفاقی به یک پادکست گفتگویی جدید گوش می‌دادم. سطح صدای مجری خیلی زیاد بود و یه جاهایی انگار مثل پتک توی سرت می خورد ولی صدای مهمان پاکست خیلی ضعیف و پایین بود. بهشون این مشکل رو فیدبک دادم تا درستش کنن و متاسفانه نتوستم به گوش دادن پادکست ادامه بدم.برای اینکه حجم صدا رو در تمام طول پادکست یکنواخت و تنظیم کنید باید از تکنیک normalization و compression استفاده کنید. این ابزار را بیشتر برنامه‌های ادیت صوت دارند و باید روی فایل صوتی تان اعمال کنید.روش کاری من اینطوریه که فایل های صوتی که ضبط شدند (معمولا ۷ الی ۱۰ فایل) را به کامپیوتر منتقل کرده و در اولین مرحله وارد نرم‌افزار SOUND FORGE Pro 18 Suite می‌کنم. یک قابلیتی که این نرم‌افزار دارد اسمش Loudness normalization هست که پروفایل های مختلفی دارد. من پروفایل Speech را برای فایل های صوتی‌ای که ضبط کردم اعمال می‌کنم. در اسکرین شات زیر تفاوت قبل و بعد از اعمال این تغییر را مشاهده می‌کنید. در واقع این نرم‌افزار (مانند خیلی از نرم‌افزار های دیگر)‌ همان تکنیک normalization و compression را روی فایل های صوتی اجرا و سپس سطح صدا را تا حد استانداردی افزایش می‌دهد.قبل از عمل vs بعد از عملسپس یک پروژه در نرم‌افزار Adobe Audition می‌سازم و در آنجا کار اصلی ویرایش و چسباندن فایل های صوتی و خروجی گرفتن فایل mp3 نهایی پادکست را انجام می‌دهم. در آخر کار همیشه روی Track اصلی افکت Light Noise Reduction را اعمال می‌کنم تا بخش زیادی از نویز هایی که پیشتر گفتم حذف شود.یک میزکار شبیه حرفه ای ها! ولی سطح کاری که من از adobe audition می‌خوام مثل اینه که جمع ۲+۲ رو از یه ماشین حساب مهندسی بخوام.انتشاربرای انتشار پادکست باید یک لینک به فایل xml بدهید که در آن مشخصات پادکست و فایل و توضیحات اپیزود ها در قالب مخصوصی نوشته شده باشه که بهش feed پاکست هم گفته میشه. در نهایت برای انشار پادکست صرفا باید لینک feed را به سرویس های پادکچر مثل کست باکس و اسپاتیفای و ... بدهید. این سرویس های پادکچر صرفا به صورت دوره ای (مثلا هر ۱۲ ساعت) آن لینک feed معرفی شده را می‌خوانند و اگر اپیزود جدیدی داشتید (در فایل xml اضافه شده بود) به آن پلتفرم به صورت اتوماتیک اضافه می‌شود. حتی فایل صوتی اپیزود را هم اغلب دانلود نمی‌کنند و شنوندگان از همان مسیری که فایل را گذاشتید (و در فایل xml قرار دادید) روی سیستم شان دانلود شده و به اپیزود گو‌ش می‌دهند.پادکست نیمچه برنامه نویس که feed آن به کست باکس معرفی یا به عبارتی claim ownership کردم.راه های متنوعی برای ساخت و مدیریت feed پادکست وجود دارد. یکی از متداول ترین راهکار ها استفاده از podcast hosting هاست. سرویس هایی مثل Acast و PodBean برای این کار وجود دارند و بین پادکستر های ایرانی محبوب اند. این سرویس ها یک پنل در اختیارتان می‌گذارند که فایل اپیزود را در آن آپلود کنید و توضیحات و کاور آن را بسازید و یک لینک feed برای پادکست تان می‌سازد و می‌توانید آن لینک فید را به پلتفرم های پادکچر معرفی کنید. البته استفاده از سرویس های podcast hosting برای ما چالش هایی نیز دارد. چند سال پیش یکی از این سرویس های معروف به اسم Anchor.fm کاربران ایرانی را تحریم کرد و بسیاری از پادکستر های ایرانی به مشکل خوردند. همچنین فضای آپلود و حجم رایگان این سرویس ها محدود است و ممکن است لازم باشد هزینه دلاری بپردازید.روش انتشار این پادکست کمی عجیب و خلاقانه است. آدرس feed پادکست نیمچه برنامه نویس تحت بلاگ خودم (منتشر شده در فضای رایگان netlify) هست که توسط markdown parser و nunjucks ساخته میشه. همه‌ی کد ها و تمپلیت feed در لینک ریپوی github ام هست و می‌توانید استفاده کنید. (شاید بعدا یک ابزار opensource تر و تمیز بر اساس همین template engine ساختم و اگر دوست داشتید بگید با هم بسازیمش و حتی یک پادکست هاستینگ راه بندازیم) فایل صوتی اپیزود ها را نیز در فضای استورج ابرآروان آپلود می‌کنم که فعلا تا ۵ گیگ فضای رایگان می‌دهد.لینک فید rss پادکست اینجاست که روی بلاگ خودم قرار دادماگر سایت وردپرسی دارید به راحتی می‌توانید پلاگین PowerPress را نصب کنید و به شما لینک feed می‌دهد و همان را در سرویس های پادکچر معرفی می‌کنید و تمام. پادکست شما منتشر شد. صرفا با داشتن یک دامنه و فضای ذخیره سازی ابری می‌توانید پادکست خود را در تمامی پلتفرم ها به راحتی منتشر کنید. در این زمینه اگر سوالی یا مشاوره ای خواستید حتما بپرسید در کامنت ها و سریع پاسخ میدم.رشدروش من برای رشد مخاطبین پادکست علاوه بر معرفی به دوستان و همکاران ، به دو کانال محدود بوده. یکی linkedin و دیگری تلگرام. کار هایی که در این دو کانال کردم این موارد بودند:پیج شرکتی ما با یک کارمند!در لینکدین به پیشنهاد یکی از دوستان پیج شرکتی ساختم به اسم نیمچه برنامه نویس تا در آنجا بتوانم follower جذب کنم و مخاطبان لینکدین ام را به پادکست invite کنم. طبق تجربه ، افراد پیج های شرکتی را راحت‌تر از پیج شخصی follow می‌کنند.اپیزود های جدید و همچنین محتوا های بازاریابی‌طور می‌سازم و در پیج لینکدین منتشر می‌کنم. یکی ازین محتواها اینه.به دوستانم و کسانی که بی واسطه یا با واسطه آشنایی دارم درخواست کردم که پست های پیج لینکدین را Repost یا like کنند.در تلگرام افراد زیادی هستن که در فضای لینوکس و مهندسی نرم‌افزار فعالند و کانال های تگلرامی نسبتا پرمخاطبی دارند. بهشون پادکست رو معرفی کردم و ازشون خواستم حمایت کنند. غیر از معدود مواردی همگی پادکست رو در کانال های تلگرامی شون معرفی کردند و این اتفاق تاثیر زیادی در رشد مخاطبین پادکست داشت.کاش قبل از اینکه شروع کنم می‌دانستمقبل از شروع کردن هدف تون رو مشخص کنید. اینکه از پادکست چه انتظاری دارید و در نهایت می‌خواهید به چه برسید. این هدف می‌تواند در همه‌ی ابعاد کار پادکست تاثیر بگذارد. جنبه درآمدزایی را هم در هدف تان حتما در نظر بگیرید.برای انتشار پادکست برنامه مشخص و منظم داشته باشید. هفته ای یکبار انتشار مناسب است. اگر این برنامه برای مقطعی رعایت نشد به خودتان سخت نگیرید ولی سعی کنید به آن پایبند باشید.کپی کردن از بقیه پادکستر ها کار بدی نیست و به خوبی میشه از سبک و لحن و ... بقیه پادکست ها کپی کرد مثلا لحن پادکست من - شاید ناخودآگاه - خیلی به پادکست های علی بندری (بی پلاس و ...) نزدیک شده بود. ولی سبک خودتان را داشته باشید و راحت باشید. مثلا متن الگوی شروع و پایان منحصر به فردی تنطیم کنید.منابعی که خودم قبل از شروع کار با دقت دیدم و خواندم اینها بود: پلی لیست یوتیوب راهنمای ساخت پادکست توسط علی بندری  ، ویدیو یوتیوب چگونه پادکست بسازیم امین آرامش (پادکست کارنکن) ، مطلب بلاگ رضا توکلی (پادکست Furbo)ممنونم که تا اینجای متن همراهی کردید. سوالی یا فیدبک ای بود در انتهای این نوشته کامنت کنید. سپاسگزارم.</description>
                <category>صادق محبی</category>
                <author>صادق محبی</author>
                <pubDate>Thu, 13 Feb 2025 18:11:11 +0330</pubDate>
            </item>
                    <item>
                <title>راهنمای تلخ کوبرنتیز برای مدیران</title>
                <link>https://virgool.io/@mohebbisadegh/%D8%B1%D8%A7%D9%87%D9%86%D9%85%D8%A7%DB%8C-%D8%AA%D9%84%D8%AE-%DA%A9%D9%88%D8%A8%D8%B1%D9%86%D8%AA%DB%8C%D8%B2-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%85%D8%AF%DB%8C%D8%B1%D8%A7%D9%86-bvj4fow23jeq</link>
                <description>وقتی در جایگاه تصمیم گیرنده هستیم ، اوضاع خیلی بهم ریخته است؛ به خصوص که بررسی و دیدن حقیقت ها در بین هیاهو های بیرون بسیار دشوارست. در صنعت تکنولوژی و نرم‌افزار مد های زیادی می‌آیند و می‌روند. کوبرنتیز نیز یکی از این هایپ های تکنولوژی است که در سال های اخیر خیلی پرطرفدار شد. الآن که کوبرنتیز کمی از مد و نقطه‌ی اوج افتاده ، جای آن است که کمی واقعیت های تلخ و پنهان کوبرنتیز را ببینیم و با در نظر گرفتن آن ها در موردش تصمیم بگیریم.ما در این پست می‌خواهیم حقایقی تلخ از کوبرنتیز را برای سازمان و کسب و کار بیان کنیم. ممکنه اسم کوبرنتیز را شنیده باشید و تصور کنید که مثل یک چوب جادو بسیاری از مشکلات سیستم نرم‌افزاری شرکت را حل می‌کند. ولی حقیقت طور دیگری است. برای رسیدن به این چراغ جادو (کوبرنتیز)‌ باید از دره ها و پل های معلق خطرناکی عبور کنید. بیاید با هم چند تا از این موانع رفتن سمت کوبرنتیز را ببینیم.نگهداری داده‌ها چالش برانگیز استکوبرنتیز برای نگهداری و حفاظت از داده ها خوب نیست و به راحتی ریسک از دست رفتن و خرابی داده‌ها وجود دارد. چرا؟ ایشو ها (یک نمونه) و باگ هایی وجود دارد که کوبرنتیز بعد از آپدیت یا بازیابی ، در وضعیتی قرار می‌گیرد که نمی تواند داده ها و دیتابیس را صحیح و سالم تحویل دهد. به نظرتون راه حل در این موقع چیست؟ پاک کردن و حذف دیتابیس و بازگرداندن بکاپ و این یعنی یک داون تایم و ریسک درست و حسابی.در تعدادی از شرکت های ایرانی که تصمیم مهاجرت سیستم به کوبرنتیز گرفته اند ، بعضا دیده‌ام که مهاجرت دیتابیس ها در آخرین مرحله بوده یا دیتابیس اصلی را به شکل قبلی حفظ کرده و مهاجرت نداده‌اند.داشبورد های بی در و پیکر!لذت و راحتی کار با داشبورد های کوبرنتیز و پلاگین هان آن در عین حال که جذاب است ، خطرناک هم هست. این داشبورد ها وقتی راه اندازی شوند و در دسترس قرار گیرند ، مثل یک مین عمل نشده رفتار می‌کنند ،‌ کوچک ترین اشتباه در کانفیگ یا حفظ امنیت آن تبعات زیادی به دنبال دارد. سایت بیاد پایین یا اطلاعات سایت به جای دیگری ارسال و هک شود و هزاران ریسک و گلوگاه دیگر. در این بایستی حواسمان به API Server نیز باشد که کارش از مین عمل نشده هم گذشته و مثل یک TNT وسط سرور و کلاستر است! (جزئی مهم که در کوبرنتیز master وظیفه دریافت دستورات و اجرای غیر مستقیم آن را بر عهده دارد و در واقع داشبورد ها و همچنین ابزار kubectl به آن وصل می‌شوند و request می‌زنند) این سطح از حساسیت نیاز به مدیریت و روال های مشخص دارد.آپدیت کردن کلاستر کوبرنتیز یعنی هر بار یک چیزی مختل شوداگر بخواهید کلاستر کوبرنتیز را آپدیت کنید همواره بایستی پلن A و پلن B مشخصی داشته باشید که در امن ترین حالت باید دو کلاستر پروداکشن جداگانه باشد و این یعنی هزینه‌ی دوچندان. وگرنه قطعا (با احتمال بالایی) در هر بار آپدیت مشکلاتی بزرگ یا کوچک به وجود خواهد آمد.اگر نخواهید کلاستر کوبرنتیز را آپدیت کنید هم کلاستر شما در معرض حملات هکر ها و مشکلات امنیتی قرار خواهد گرفت و به ریسک آن نمی ارزد. پس چاره ای نیست :\یادگیری دشوار و آرام ، درد و رنج های پیچیدگی عملیاتهمگی ازعان داریم که یادگیری کوبرنتیز سخت و بسیار پیچیده است. این مسیر آرام یادگیری در کنار سایر مسائل و وظایف کارمندان همه چیز را بد و بدتر می‌کند. در نتیجه بایستی برای داون تایم های متعدد و مشکلات عجیب پروداکشن آماده باشید و امیدی هم به وقوع معجزه نداشته باشید.شوخی ای به نام کوبرنتیز مدیریت شدهممکن است بگویید که «این حرف ها برای ما نیست چونکه روی کلود هستیم» و چالش های بالا را انکار کنید و به گردن cloud provider بیاندازید.متاسفانه این بیشتر شبیه یک رویاست. علاوه بر اختلالات سرویس دهنده ، معماری سیستم نیز در زمانی که روی کوبرنتیز است بسیاری از چالش های بالا را تجربه می‌کند. اینکه یک کوبرنتیز مدیریت شده گرفته اید به این معنی نیست که یک سرویس با آپتایم و ریسپانس تایم بالا را دارید بلکه به این معنی است که صرفا کلاستر کوبرنتیز را روی زیرساخت دیگری آماده گرفته اید و با یک داشبورد یا هر بستر دلخواه مدیریت دیگری ، سرویس خود را مستقر کرده‌اید. همین! هنوز دانش مدیریت کوبرنتیز را نیاز دارید.در همین راستا سایتی وجود دارد که داستان های داون تایم و اختلال کوبرنتیز را جمع آوری کرده است. مرور آن قبل از تصمیم مهاجرت به زیرساخت کوبرنتیز خالی از لطف نیست. https://k8s.af/ ممنونم تا اینجای مقاله اومدید امیدوارم به درد بخور بوده باشه. کوبر تون بالا :)نکته: این مقاله ترجمه ایست آزاد از این مقاله:https://blog.jessfraz.com/post/the-business-executives-guide-to-kubernetesپس‌نوشت: فلسفه‌ی این مقاله اینست که با وجود اینکه خودم از مدافعان و مروجان کوبرنتیز بودم و هستم ، ولی برای متعادل کردن خودم این مقاله هارو خوندم و مروری رویشان نوشتم.</description>
                <category>صادق محبی</category>
                <author>صادق محبی</author>
                <pubDate>Thu, 12 Sep 2024 02:18:06 +0330</pubDate>
            </item>
                    <item>
                <title>این RFC چیه و چرا خوندنش مهمه؟</title>
                <link>https://virgool.io/@mohebbisadegh/%D8%A7%DB%8C%D9%86-rfc-%DA%86%DB%8C%D9%87-%D9%88-%DA%86%D8%B1%D8%A7-%D8%AE%D9%88%D9%86%D8%AF%D9%86%D8%B4-%D9%85%D9%87%D9%85%D9%87-dy3hfzr7huv8</link>
                <description>چیزی که در بسیاری از اپیزود های پادکست های جادی (رادیو گیک قدیم) به وفور دیده می شه همین مرور و خواندن  RFC هاست. در این نوشتار کوتاه اول می خوایم ببینیم RFC چیه و چه اهمیتی داره و در آخر چندتا RFC بنیادی و خواندنی رو بهتون پیشنهاد می‌کنم.تعاریف، نکات و آداب مطالعهمقالات RFC مخفف Requests For Comments در واقع مستنداتی فنی مهندسی هستند که طی فرایند های دقیق و مشخصی نگاشته، تنظیم و توسط انجمن IETF تایید و منتشر می‌شوند.انجمن IETF مخفف Internet Engineering Task Force در واقع انجمنی هستند که استاندارد های اینترنت رو مشخص می‌کنند. اعضای هیئت مدیره این انجمن که به صورت هیئت امنایی اداره می شه در حال حاظر ۵ نفر هستند. روند مشارکت و انتخاب اعضا، روال ها، همایش ها و فرایند های IETF نیز جالبه.منبعی بهتر از خود سایت IETF برای آشنایی باهاشون پیدا نکردم. ازینجا می‌تونید شروع کنید و حتما گشتی در سایت انجمن بزنید، دست خالی برنمی گردید! در خود این سایت نیز توضیحات کاملی در خصوص RFC در این لینک آمده است که می‌تونید آنجا را نیز مرور کنید.همان طور که می توان حدس زد، RFC ها مهم ترین خروجی IETF است چرا که با این ابزار، استاندارد های اینترنت را در کل دنیا مشخص و تعیین می‌کند. خواندن RFC نیز آدابی دارد که به برخی از این موارد اشاره می‌کنیم:خود RFC ها در ۵ مرحله‌ی بلوغ و اتکاپذیری طبقه‌بندی می‌شوند: ۱- informational یا اطلاع رسانی ۲- experimental یا در حال توسعه و تکمیل ۳- Proposed Standard (PS) در این مرحله می‌توان به محتوای RFC اعتماد کرد چرا که به عنوان یک استاندارد رسمی پذیرفته شده است ولی هنوز به عنوان استاندارد کل اینترنت به رسمیت شناخته نمی شود. ۴- Draft standard یک مرحله‌ی میانی جهت دریافت بازخورد ها و تایید نهایی ۵- Internet Standard انواعی از RFC ها هستند که به صورت یک استاندارد مستند رسمی در اینترنت مورد قبول و منتشر می‌شود و در واقع این مرحله نهایی و غایت RFC هاست.دو وضعیت دیگر نیز هست به اسم BCP و Historic (تاریخی)‌ که تعریف دقیق آن برای ما در اینجا خیلی مهم نیست! و در ادامه با مثال، نمونه هایی از این دو نوع RFC را بررسی خواهیم کرد.از آنجایی که RFC ها استاندارد های کل اینترنت هستند، هر RFC رسمی منتشر شده، شماره ای نیز دارد که مثلا برای ارجاع دادن در سایر مقالات، بتوان به سادگی آن را پیدا کرد و به آن استناد داد.سایت های زیادی برای مطالعه‌ی RFC ها در اینترنت وجود داره که یکی از مهم‌تریناش rfc-editor هست که خود IETF معرفیش کرده.بررسی چند نمونهپس بیاید سربرگ دو تا RFC مهم رو با هم ببینیم و طبق چیزایی که یادگرفتیم تحلیل شون کنیم:https://www.rfc-editor.org/rfc/rfc3339.htmlسمت راست که عموما نویسندگان مستند و تاریخ رو نوشته، سمت چپ اشاره ای به IETF و شماره مقاله یعنی RFC3339 داره. دسته بندی هم که مشخص کرده، این RFC از نوع internet standard عه یعنی به عنوان یک استاندارد رسمی تایید نهایی و منتشر شده است. خود RFC هم که موضوعش مشخصه و خداست. به این ظاهر زشت و خشک RFC ها نگاه نکنید اتفاقا خیلی هاشون متن روان و جذاب و دقیق ای دارند و خوندن شون لذت بخشه.https://www.rfc-editor.org/rfc/rfc5424.htmlو RFC5424 بعدی هم مربوط به پروتکل syslog سیستم هست و همانطور که مشخصه، از نوع استاندارد اینترنت منتشر و تایید نهایی شده و همچنین، یک RFC دیگری به اسم RFC3164 از نوع informatioanl را نیز منسوخ کرده است.حالا که حرف از syslog شد، یه نکته تو پرانتز بگم: به نظرم ما توسط grafana و elastic stack و datadog و ... مارکتینگ شدیم! در حالی که مثلا برای دریافت، انتقال و مدیریت لاگ راهکار های بسیار ساده تر و بهینه تری نیز وجود دارد. یکی از این راهکار ها RELP است که با syslog کار می‌کند و انصافا جای بررسی و کار دارد. (در حال آماده کردن سلسله مقالاتی در خصوص RELP - syslog از مفاهیم تا کاربرد عملی‍ آن هستم و به هنگام انتشار، در لینکدین اطلاع رسانی خواهم کرد)حالا خالی از لطف نیست که در ادامه از دو نوع BCP و Historic نمونه هایی رو ببینیم:https://www.rfc-editor.org/rfc/rfc2026.htmlروال ها و فرایند های داخلی IETF به صورت RFC های BCP یا ‌Best Current Practices تهیه و تنظیم می‌شوند، به طور مثال RFC2026 به فرایند ثبت و تایید RFC های از نوع Internet Standard پرداخته است.بسیاری از RFC های قبلی با انتشار و تایید RFC های جدید، منسوخ و منقضی می‌شوند ولی در این بین، RFC هایی که قدمت بالایی دارند (یه جورایی ارزش تاریخی دارن) به عنوان RFC های Historic طبقه بندی شده اند.https://www.rfc-editor.org/rfc/rfc943.htmlاز بین این RFC ها می‌توان به زمان های قدیم سفر کرد و تاریخ اینترنت را مطالعه کرد.چرا RFC بخونیم؟باب اسفنجی ای که کل شب رو داشته RFC می‌خونده! :)چیزی که با مشاهده و تجربه بهش رسیدم، لازمه‌ی عبور از چالش های پیچیده‌ی مهندسی نرم افزار، دونستن جزئیات هست. این جزئیات در سه جا به خوبی یافت می شوند: ۱- مستندات خوب نوشته شده‌ی سرویس، فریم‌ورک یا زبان برنامه‌نویسی ۲- برخی از RFC های مرتبط به حیطه‌ی کاری ۳- یه آدم گیک خفن و منتور فوق باتجربهبه نظرم رجوع به RFC مثل استفاده از دیکشنری های چند جلدی آکسفورد عه. اگر در مورد یک کلمه یا حرف انگلیسی به دیکشنری آکسفورد مراجعه کنید، تمامی کاربرد ها، تعاریف، مثال ها، مترادف و متضاد و ... را در خصوص آن کلمه پیدا می‌کنید و قطعا با دست پر کتاب رو می‌بندید. در خصوص RFC هم به همین شکل هست، مراجعه‌ی موردی به RFC ها خیلی مفیده.البته یادمه سر کلاس دانشگاه استاد زبان مون می‌گفت که دیکشنری برای خوندن عه نه برای مراجعه‌ی موردی. اینم به هر حال روشی عه. اینکه چند تا RFC مهم و پرکاربرد رو انتخاب کنیم و کامل بخونیم شون.پس دو روش برای مطالعه‌ی RFC ها شد: ۱- مراجعه‌ی موردی و ۲- مطالعه‌ی کامل RFC های منتخبچند تا RFC خفنخودم RFC های زیر رو نخوندم ولی کلیدواژه هایی رو جستجو کردم و یا لینک هاش رو از جاهای های مختلف پیدا کردم و یه نگاه کلی بهشون انداختم. در نهایت مواردی رو دست چین در اینجا برای خودم و شما آوردم: https://datatracker.ietf.org/doc/html/rfc3339 یک RFC3339 با جزئیات بالا و گیج کننده ولی بسیار مهم در خصوص فرمت های استاندارد تاریخ و زمان در اینترنت و کاربرد timestamp (چونکه توی این نوشته بهش اشاره کردیم،‌ لینکش رو آوردم) https://datatracker.ietf.org/doc/html/rfc9293 همه چیز (حقیقتا همه چیز) درباره‌ی پروتکل TCP به شدت روان و زیبا https://datatracker.ietf.org/doc/html/rfc9110/ در خصوص پروتکل HTTP 1.1 مشخصا RFC های زیادی هست که ابعاد مختلف اون رو توضیح داده، این RFC9110 جدید ترین و کامل ترین شون هست که برای مراجعه و مرور کلی بسیار جذابه. برای دنبال کردن موضوعات می‌تونید از RFC2616 شروع کنید که در واقع RFC اصلی پروتکل HTTP هست.فرمول طلایی رهایی از سردرد های مشکلات شبکه‌ای :\ممنونم تا اینجا اومدید و امیدوارم این نوشته براتون مفید بوده باشه. نظرات و فیدبک هاتون خیلی مهمه و کمک کنندست.</description>
                <category>صادق محبی</category>
                <author>صادق محبی</author>
                <pubDate>Mon, 29 Jul 2024 00:47:16 +0330</pubDate>
            </item>
                    <item>
                <title>تلویزیون رو ورداشتم، جاش کتاب گذاشتم</title>
                <link>https://virgool.io/@mohebbisadegh/%D8%AA%D9%84%D9%88%DB%8C%D8%B2%DB%8C%D9%88%D9%86-%D8%B1%D9%88-%D9%88%D8%B1%D8%AF%D8%A7%D8%B4%D8%AA%D9%85-%D8%AC%D8%A7%D8%B4-%DA%A9%D8%AA%D8%A7%D8%A8-%DA%AF%D8%B0%D8%A7%D8%B4%D8%AA%D9%85-diez8do5hopc</link>
                <description>تلویزیون توی هال خانه رو برداریم و جاش کتاب و گلدون بذاریم. چند تا دلیل دارم که اگر دوست داشتید، ادامه‌ی پست را بخوانید. البته منظورم از تلویزیون، دستگاه آن نیست بلکه شبکه های تلویزیونی و برنامه های آن است.تلویزیون رسانه ای یک‌طرفه استفرقی نمی کند تلویزیون خارجی باشد یا داخلی، در هر حالتی تلویزیون رسانه ای یک‌طرفه است. یعنی این شما نیستید که محتوا را انتخاب می‌کنید (انتخاب محدودی دارید) بلکه شبکه های تلویزیونی انتخاب می کنند که شما چه چیزی ببینید. این شرایط در رسانه های اجتماعی و پلتفرم های اشتراک ویدیو مثل یوتیوب خیلی بهتر است به طوری که انتخاب کننده تا حد زیادی خود شما هستید.تلویزیون آثار بسیار نامطلوبی روی سلامتی به خصوص ذهن کودکان دارداین ماجرا که در نسل جدید خیلی خودش را نشان داده و فراگیر شده، مسئله‌ی بسیار مهمی است. تلویزیون (همچنین موبایل هوشمند) برای سنین پایین بایستی محدود یا حذف شود.تلویزیون یک هدر دهنده‌ی وقت به معنای کامل استنشستن پشت برنامه های سرگرمی و اخبار بی‌خود و پوچ تلویزیون، ساعت های بسیاری را که می‌توان از آن در طبیعت یا همراه با خانواده معاشرت کرد و لذت برد را از بین می‌برد.پس می‌توان یک نه بزرگ به تلویزیون گفت و زمان آن را با مطالعه‌ی کتاب پر کرد. بهترین هارو برای همه مون در سال جدید ۱۴۰۳ آرزو می‌کنم :)پس‌نوشت: این اولین پست کاملا غیر تخصصی و دلی من در ویرگول بود. تو ذوقم نزنید...</description>
                <category>صادق محبی</category>
                <author>صادق محبی</author>
                <pubDate>Tue, 12 Mar 2024 01:02:49 +0330</pubDate>
            </item>
                    <item>
                <title>وبسایت شخصی برای کسانی که از وردپرس متنفر اند!</title>
                <link>https://virgool.io/@mohebbisadegh/%D9%88%D8%A8%D8%B3%D8%A7%DB%8C%D8%AA-%D8%B4%D8%AE%D8%B5%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%DA%A9%D8%B3%D8%A7%D9%86%DB%8C-%DA%A9%D9%87-%D8%A7%D8%B2-%D9%88%D8%B1%D8%AF%D9%BE%D8%B1%D8%B3-%D9%85%D8%AA%D9%86%D9%81%D8%B1-%D8%A7%D9%86%D8%AF-ykujm052zqpg</link>
                <description>مدتی بود که قصد داشتم وبسایتی شخصی برای خودم راه بیاندازم. فرصتی پیدا شد و شروع به جستجوی یک فریم‌ورک مناسب کردم. در بین تمامی پیشنهادات، وردپرس یکی از گزینه های مطرح بود ولی خب چکار کنم که از وردپرس متنفر بودم. یعنی یک تروما ای برام شده و همیشه درگیرش بودم و هستم. (در زمان دانشجویی با وردپرس بارها سایت های جور و واجور زدم طوریکه حسابش از دستم در رفته)کمی سرچ هام رو بردم سمت فریم‌ورک های static site generator با node js و از آنجایی که برای تعویض پوشک بچه نیز پکیج npm ای هست، کلی گزینه‌ی جدید اضافه شد و حسابی گیج و منگ یه گوشه افتادم تا اینکه توی ایمیل های خبرنامه Node Weekly یک اسم باحال و یک کپشن از گوگل توجهم رو جلب کرد. اون اسم، فرم‌ورک Eleventy یا به اختصار 11ty نام داشت.توی خیالم اینطوری خوشحال و سرخوش به بیرون جهیدم. (عکس تولید شده با هوش مصنوعی بینگ)این فرم‌ورک در کل یک static site generator ساده است که با ورودی تمپلیت و محتوا، خروجی html می‌دهد. همه چیز در 11ty قابل شخصی سازی است و همین سادگی، قدرتمندی و سرعتش باعث شد که امتحانش کنم.از صفر شروع کردن (مخصوصا برای کار با یک فریم‌ورک جدید) همیشه چالشی و سخت بوده. خوشبختانه جامعه‌ی کاربری گسترده ای داره و به راحتی یک پروژه‌ی پایه براش پیدا کردم که همه‌ی نیازمندی هام رو داشت.لینک وبسایت شخصی ام که الآن روی netlify بالاست:https://sadeghmohebbi.irو لینک گیت هاب پروژه که در README آن سایر لینک های مرتبط را گذاشته‌ام و می توانید بگردید ببینید چجوری این سایت بالا ساخته شده:https://github.com/sadeghmohebbi/personal-website</description>
                <category>صادق محبی</category>
                <author>صادق محبی</author>
                <pubDate>Thu, 15 Feb 2024 04:11:13 +0330</pubDate>
            </item>
                    <item>
                <title>سربازی رفتم. اینا چیزاییه که از آموزشی برام موند</title>
                <link>https://virgool.io/@mohebbisadegh/%D8%B3%D8%B1%D8%A8%D8%A7%D8%B2%DB%8C-%D8%B1%D9%81%D8%AA%D9%85-%D8%A7%DB%8C%D9%86%D8%A7-%DA%86%DB%8C%D8%B2%D8%A7%DB%8C%DB%8C%D9%87-%DA%A9%D9%87-%D8%A8%D8%B1%D8%A7%D9%85-%D9%85%D9%88%D9%86%D8%AF-iracpgfhiipi</link>
                <description>عکس دسته جمعی گرفته شده در آخرین روز آموزشی بعد از مراسم تحلیف و بهترین گروه رژه ی پادگان. پشت آسایشگاه گروهانسلام. من در حوزه ی برنامه نویسی و دواپس مشغول کار بودم که دانشگاه رفتنم به آخرای خط رسید و طبیعتا باید می رفتم سربازی (نمی خواستم غیبت بخورم) از ابتدای تابستان برای فرایند طاقت فرسای امریه ی دانش بنیان توی همون شرکت خودمون اقدام کردم و قبول شدم تا در لیست اعزامی های آبان ۱۴۰۲ امریه دار قرار بگیرم. بر خلاف روال سال های گذشته که آموزشی بچه های امریه عموما پادگان ۰۱ افسریه می افتاد، دوره ی آموزشی برای دوره ی ما افتاد پادگان ۰۲ پرندک.تا اینجای قضیه اوکی بود. یکم آبان ۱۴۰۲ با دو تا از دوستان (از شرکت های ازکی و سحاب) که در جریان همین امریه دانش بنیان با هم رفیق شده بودیم، هماهنگ کردیم که با هم بریم پادگان ۰۲ پرندک. من افتادم گروهان یکم نصر (طبقه اول گردان نصر)‌ و شنیده بودم که گروهان آسونیه. اکثر بچه های گروهان مون از بچه های امریه دانش بنیان بودن و کارشناسی-کارشناسی ارشد داشتن. روز اول کلا پشت صف گذشت (برای گرفتن لباس و وسایل و ...). فرداش برامون کلاس گذاشتن که مثلا احترامات نظامی چیه و سایر موارد رو توضیح می دادن که ناگهان منو از بین جمعیت صدا زدن و گفتن که مدارکم رو هم بیارم.بهم گفتن که می خوان منو منتقل کنن. علت رو جویا شدم و متوجه شدم که روی برگه اعزامم آخرین مدرک رو زده دیپلم و طبق این مورد می خوان تقسیم کنند. من مدارک و مستندات دانشگاه برای لیسانس  همراهم بود و ارائه دادم، ولی به هر صورتی که بود قبول نکردند. (بعد ها فهمیدم که تا تسویه دانشگاه توی سامانه وظیفه ناجا بشینه ۳ ماه طول می کشه و من عجله کرده بودم)‌ بعد از چند ساعتی معطلی و زیر آفتاب موندن بهم گفتن که منو می خوان بفرستن پادگان دیگری در نزدیکی ۰۲ به اسم مراتکاور و واکنش سریع نزاجا شهید شبان معروف به ۳۳ ارتش. از هر سربازی می پرسیدم که اونجا چه جور جاییه کلی توی دلم رو خالی می کرد. یعنی قرار بود تکاور بشم!؟ لحظات خیلی سخت و بدی گذشت و اون روز یکی از بد ترین روز های زندگیم رقم خورد.از ابتدای دوره قرار بود آمورشی مون ۶۰ روز باشه ولی در اواسط دوره خبرهایی رسید که دوره آمورشی مون ۴۵ روزه شده و اون خبر خوشحال کننده محقق شد. در نهایت ۱۵ ام آذر از پادگان مراتکاور با نامه امریه لویزان (مربوط به امریه دانش بنیان) ترخیص شدم.در کل به عقب که نگاه می کنم، لحظات تلخ و شیرین زیادی رو در پادگان مراتکاور گذروندم که لحظات سخت و تلخ اش بیشتر بود. حالا که آموزشی تموم شده، دوست داشتم دستاورد های خودم رو مکتوب کنم تا هم از ذهنم خارج بشه بریزه بیرون و هم اینکه شاید براتون جالب باشه. مواردی که در ادامه می گم اصلا و ابدا به این معنی نیست که سربازی چیز خوبیه و فایده داره. من صرفا از زاویه دیگری به مشکلات و سختی های دوران آموزشی سربازی نگاه کردم.سربازای این پادگان این آرم رو روی بازو شون می زدن و کلاه کج می ذاشتن. چقدر خفن!استقامت روحی ام بیشتر شده. توی دوره ی آموزشی فشار های روانی زیادی بهم وارد شد مثلا تنبیهات سختی برای مسائل مسخره ای مثل خوب شونه نخوردن پتو و آنکادر تخت. ازین دست موارد زیاده و منم گیر نیوفتادم. مدیریت ذهنی این فشار ها مهمه و اینکه باعث نشه امور روزمره ام دچار مشکل بشه و درگیر استرس و اضطراب بشم. خلاصه اینکه ظرفیت تحمل شرایط پراسترس ام رفته بالاتر.بدنم رو فرم اومده و کمی لاغر شدم. من به واسطه ی کارم ساعات زیادی رو پشت میز و کامپیوتر میشینم و در کنارش ورزش ای هم نمی کنم. همین باعث شده بود که دچار مشکلاتی مثل چاقی و مسائل پیرامون اش بشم. دو دوره رژیم در تابستان گرفته بودم و در مجموع ۴ کیلو کم کرده بودم و در طول همین یک ماه نیم دوره ی آموزشی سربازی، ۷ کیلو کم کردم! و وضعیت کلی سلامتیم بهبود داشته. پیاده روی های زیاد و مکرر روزانه داخل پادگان از آسایشگاه تا میدون مرکزی آموزش (به فاصله ی ۳ کیلومتر و ۲۰ دقیقه پیاده روی) ، رژه، کار اجباری با بیل یا جارو در اطراف پادگان هفته ای یکبار، بشین پاشو و پامرغی و ... همه ی این ها انرژی فوق العاده ای ازم می گرفت و فشار بدنی زیادی برام داشت. برنامه ی جدی گذاشتم که ورزشی سبک رو بعد سربازی شروع کنم تا این وضعیت آمادگی جسمانی رو نگهدارم و نذارم دوباره بدنم افت کنه.روحیه ام کمی خشن و خشک شده. در مجموع فشار های روانی و بدنی و سرد و خشکی آب و هوای پرندک!، برای تحمل این فضا کمی خشن شدم و بگو بخندم کمتر شده. البته شاید بعد از مدتی برگردم به سابق و اعصابم آروم تر بشه ولی الآن این شرایط رو دارم.قدر خانواده و زمانی که باهاشون هستم رو بیشتر میدونم. هیچ وقت اولین مرخصی آموزشی یادم نمیره، چقدر دلتنگ خانوم بچه ها شده بودم و بغضی همراهم بود که نترکید. قبل از سربازی، واقعا قدر زمانی که پیش خانواده بودم رو نمی دونستم و این یه درس بزرگ برام بود که به خانواده و وقت گذروندن باهاشون اهمیت بیشتری بدم.اگر سوالاتی درباره ی سربازی داشتید توی کامنتا بپرسید، سریع جواب میدم. ممنونم از وقتی که برای خوندن این نوشته گذاشتید.</description>
                <category>صادق محبی</category>
                <author>صادق محبی</author>
                <pubDate>Fri, 08 Dec 2023 08:33:52 +0330</pubDate>
            </item>
                    <item>
                <title>پیاده سازی کش عکس توزیع شده با nginx و minio و memcached</title>
                <link>https://virgool.io/@mohebbisadegh/%D9%BE%DB%8C%D8%A7%D8%AF%D9%87-%D8%B3%D8%A7%D8%B2%DB%8C-%DA%A9%D8%B4-%D8%B9%DA%A9%D8%B3-%D8%AA%D9%88%D8%B2%DB%8C%D8%B9-%D8%B4%D8%AF%D9%87-%D8%A8%D8%A7-nginx-%D9%88-minio-%D9%88-memcached-nmjtzjmxtayw</link>
                <description>صرفا جهت شوخی!سرعت لود عکس های یک سایت تاثیر زیادی روی تجربه‌ی کاربر داره. مدتی بود که بحث سرعت لود عکس ذهنم رو مشغول کرده بود و دوست داشتم در یک محیط آزمایشی یه سری تست و workaround حول این مسئله داشته باشم. بالاخره در یک آخر هفته ی بارونی اواخر بهار این فرصت پیش آمد.امروز صبح ۵ خرداد ۱۴۰۲ تهران بارون اومد و هوا سرد بود! ولی ظهر دوباره هوا گرم شد. ششتت :|به طور خلاصه من می‌خواهم با استفاده از یک سرویس جداگانه عکس ها را کراپ کنم و فایل های مربوط را به صورت توزیع شده در minio نگه می‌دارم (عکس های اصلی نیز در minio نگهداری می‌شوند). در این بین برای لود کردن عکس های کراپ شده سمت کلاینت، از یک لایه‌ی cache مجزا بهره می برم (در اینجا از memcached استفاده می کنم). تاکیدی که خودم دارم این است که این پیاده سازی تا جای ممکن در پروداکشن و محیط عملیاتی قابل استفاده باشد و ابعاد مختلف آن را در نظر بگیرم. لینک ریپوی این مقاله:https://github.com/sadeghmohebbi/nginx-minio-memcached-imagecachingبرای نوشتن این مقاله از منابع و داکیومنتیشن های مختلفی استفاده شده ولی می توان گفت که این مقاله، یک محتوای ارگانیک بدون دخالت ای آی است :)خب بریم که شروع کنیم...قدم اول: راه اندازی کلاستر minioقابلیت جدید ورژن انقلابی ۲ به بعد آبجکت استورج MinIO این امکان را می‌دهد که بتوانیم یک Server Pool داشته باشیم. ما سناریو کلاستر Multi Node, Multi Drive را پیاده سازی کردیم تا هم در مقابل اختلالات دیسک و سرور مقاوم باشیم و هم بار ترافیک را بین آن ها تقسیم کنیم (مطالعه ی بیشتر)‌ در فایل داکر کامپوز زیر، ما ۲ درایو و سه سرور minio داریم که با آن ها یک Server Pool  روی پورت ۹۰۰۰ بالا آورده ایم. پنل آن را نیز در پورت ۹۰۰۱ پابلیش کردیم.docker-compose.ymlهمانطور که در تنظیمات بالا مشخص است، سه تا instance از minio بالا آوردیم که با کامند minio server به هم وصل شدند یعنی در نتیجه ما سه تا node و دو تا volume داریم. الزاما در پروداکشن بایستی مسیر های data در دیسک های متفاوتی mount شده باشند و حتی می توان از سه vm جداگانه در سرور های جدا از هم نیز بهره برد به شرط اینکه شبکه ی بین سرور ها ظرفیت و سرعت کافی را داشته باشد. محیط آزمایشی دست ما را بسته است :)در آخر instance های minio در کانفیگ nginx به عنوان upstream تعریف شدند و nginx در پورت های ۹۰۰۰ و ۹۰۰۱ Listen می‌کند تا ترافیک را به سمت نود های minio لود بالانس و reverse proxy کند. (فایل کانفیگ minio.conf nginx را در ریپو ببینید)با کامند docker compose up -d --build سرویس هامون سریع بالا اومد و پنل زیر مشاهده شد. امکانات پنل minio در این ورژن واقعا فوق العاده است. ?minio consoleدر اینجا می‌توانیم توکن هایی را تعریف کنیم و از طریق سرویس بک اند مان به وسیله‌ی minio sdk لایبرری به سرور minio واقع در پورت ۹۰۰۰ متصل شویم تا مثلا عکس پست ها، محصولات،‌بنر ها یا آواتار کاربران در این آبجکت استورج ذخیره یا به اصطلاح putObject شوند. ولی ما در آزمایشگاه مون چنین سرویس ای رو توسعه ندادیم. پس از طریق همین پنل پیش فرض، یک باکت برای عکس ها می سازیم و چند تا عکس آپلود می کنیم.از طریق کنسول یک باکت ساختیم و تعدادی عکس آپلود کردیماین عکس های آپلود شده بین تمامی نود ها و والیوم ها توزیع شده است. یعنی هر عکس به سه قسمت تقسیم شده و بین این سه نود توزیع شده و در هر نود، بین دو استورج کپی و سینک شده استدر ادامه در بخش تنظیمات باکت ، با افزودن دسترسی خواندن برای anonymous ، توانستیم عکس ها را از مسیر تعریف شده ببینیم. خیلی شیک و خفن!عکس ها را از سرور minio مستقیما و با اندازه‌ی اصلی می‌توان دریافت کردقدم دوم: crop یا resize عکس هاخب تا اینجای کار، عکس ها به صورت توزیع شده ذخیره و از مسیر لود بالانسر nginx در دسترس قرار گرفتند. حال تنها کافی است که از این عکس ها در سمت کلاینت استفاده کنیم. سمت کلاینت یا فرانت اند یک نیازمندی وجود دارد و آن کراپ عکس هاست با توجه با اینکه کاربر با دیوایس های متنوع ای به سایت ما مراجعه می کند و سایت نیز در اندازه های متفاوتی عکس هارا به کاربر نشان می‌دهد.برای پیاده سازی این قابلیت، اول از همه ماژول image_filter خود nginx را امتحان کردم. یکپارچه سازی این ماژول با minio اینقدر دردسر داشت که بیخیالش شدم!پس از قدری گشتن، یه ابزار خوب و پیشرفته به اسم imgproxy پیدا کردم. جزو معدود ابزار هایی بود که با s3 amazon (بخونید minio) کار می کرد و به همین دلیل رفتم سراغش. یک بنچ مارک با siege هم ازش دیدم برق از سرم پرید! در همزمانی ۱۰۰ و ۵۰ ریکوئست هر کدام (جمعا ۵۰۰۰ هزار ریکوئست)‌ تنها ۲۰۰ مگابایت رم استفاده کرده. از بقیه ی امکاناتش هم نگم براتون مثلا مانیتورینگ با Prometheus و هلث چک ، انواع مختلف image proccessing و transformation (البته یه سری از موارد خفن اش پولی بود) ، افزودن واترمارک (لوگوی سایت گوشه ی عکس) و تبدیل فرمت و کم حجم سازی و غیره.به گفته ی خودش سریع و ساده و امنه ولی به نظرم فقط سریع و امنه و ابدا ساده نبود :(برای اینکه بتوانید عکس ای را به صورت کراپ شده از imgproxy دریافت کنید، بایستی آدرسی را با فرمتی خاص تشکیل و رمزنگاری کنید. فایده ی این کار این است که فرد هکر با ابزار هایی در دسترس نتواند لود غیر واقعی روی سیستم از طریق پراسس کردن تعداد زیادی عکس ایجاد کند. اینجای قضیه کمی طولانی و پیچیده است و پیشنهاد می کنم به این مقاله مراجعه کنید که یک ابزار ایجاد لینک imgproxy را معرفی کرده است. من با استفاده از این ابزار،‌ لینک زیر را ایجاد کردم و نتیجه این شد:یک عکس کراپ شده در ابعاد ۲۰۰ در ۳۰۰ پیکسل fill از imgproxy خواستم و تمام!قدم سوم: serve عکس هاهمه ی آن پیچیدگی که در بخش قبل برای ساختن آدرس عکس دیدیم را در اینجا باید در سرویس بک اندی پیاده سازی کنیم. با یک جستجوی ساده به لایبرری imgproxy برای node js رسیدم. ازش استفاده کردم و خیلی تمیز و خوب کار کرد، برای زبان های دیگر مثل روبی و گو هم لایبرری ها و کدبلاک هایی وجود داشت. در اینجا باید اسم عکس ها در دیتابیس ذخیره و در سرویس بک اند، آدرس های عکس (کراپ شده و تنظیم شده) ایجاد شود (که ما از پیاده سازی این بخش صرف نظر کردیم)کد های این بخش را در ریپازیتوری ببینیدقدم چهارم: کش کردن عکس ها در memcachedاستفاده از کش برای شرایط ترافیک بالا ضروری است و برای عکس ها همیشهدر این مرحله سیل عظیمی از ابزار ها و کانسپت ها وارد می شود. یکی از ابزار های قدیمی و معروف کش memcahced است که به شکل یک دیتابیس in-memory توزیع شده عمل می کند. با کانفیگ زیبای زیر توانستیم عکس ها را کش کنیم، برای تست آن، من یک عکس جدید را در مرورگر بدون کش براوزر باز کردم و رفرش کردم، لود دفعه ی اول عکس با دفعات بعدی ۲ تا ۳ برابر سریع تر شد. در لاگ ها هم به طور کامل مشخص بود که فقط اولین ریکوئست به imgproxy رسیده و سایر درخواست ها توسط memcached جواب داده شده است.در فایل داکر کامپوز، سرویس memcached_server را تعریف کرده ایم. این ماژول در nginx به صورت پیش فرض فعال بودسخن آخرجهت یادآوری، تمامی کد های این مقاله (حتی دو تا عکس استفاده شده در مثال ها) در ریپازیتوری زیر موجود است:https://github.com/sadeghmohebbi/nginx-minio-memcached-imagecachingدر مسیر نوشتار این مقاله،‌ بار ها گیر خوردم و اشتباه کردم تا کار به اینجا رسید. در همین وضعیت هم می توان اشکالات و بهبود های فراوانی در آن دید. به هر حال دعوت می کنم که اگر ذوق زده شدید، راه مشارکت در بهبود این مقاله و کد ها فراهم است. Your Contribution is Welcome</description>
                <category>صادق محبی</category>
                <author>صادق محبی</author>
                <pubDate>Fri, 02 Jun 2023 02:32:27 +0330</pubDate>
            </item>
                    <item>
                <title>بالاخره یک متخصص DevOps باید برنامه نویسی بداند یا نه؟ پاسخی صریح به یک سوال پرتکرار و مهم</title>
                <link>https://virgool.io/fboard/%D8%A8%D8%A7%D9%84%D8%A7%D8%AE%D8%B1%D9%87-%DB%8C%DA%A9-%D9%85%D8%AA%D8%AE%D8%B5%D8%B5-devops-%D8%A8%D8%A7%DB%8C%D8%AF-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%A8%D8%AF%D8%A7%D9%86%D8%AF-%D9%BE%D8%A7%D8%B3%D8%AE%DB%8C-%D8%B5%D8%B1%DB%8C%D8%AD-%D8%A8%D9%87-%DB%8C%DA%A9-%D8%B3%D9%88%D8%A7%D9%84-%D9%BE%D8%B1%D8%AA%DA%A9%D8%B1%D8%A7%D8%B1-%D9%88-%D9%85%D9%87%D9%85-eefyn6uigesr</link>
                <description>Is there any Dev in DevOps?سلام :)شاید باورتون نشه ولی پاسخ به این سوال که «آیا کار های برنامه نویسی در حوزه ی کاری مختصص دواپس داریم یا نه» نه تنها دغدغه ی خودم بوده بلکه بار ها و بار ها با این سوال مهم در موقعیت های مختلف روبرو شدم. در این نوشته می خواهم به طور دقیق این موضوع را با هم بررسی کنیم و بدون حاشیه رفتن و اینکه بگیم بستگی به شرکت ات داره، مشخص کنیم که عنوان شغلی مختصص دواپس باید برنامه نویسی بداند با خیر. به طور خلاصه، در ابتدا آخرین مسیر یادگیری های موجود در مورد دواپس را با هم مرور می کنیم، سپس مقداری در مورد جزئیات کار روزمره و تجربیات مون بحث می کنیم. در آخر به این نتیجه خواهیم رسید که جواب ما به این سوال، با قاطعیت بله است.مسیر یادگیری دواپسسایت roadmap.sh https://roadmap.sh/devops به گفته ی این سایت، اولین مرحله ی شروع به مختصص دواپس شدن، یادگیری یک زبان برنامه نویسیه. زبان برنامه نویسی پیشنهادی اش هم، زبان Go هست.اولین قدم برای یادگیری دواپس اینه که یک زبان برنامه نویسی یاد بگیرید و توانایی کد نویسی داشته باشیدسایت geeksforgeeks https://www.geeksforgeeks.org/how-to-become-a-devops-engineer-a-complete-roadmap/ مقاله ی منتشر شده در این سایت معروف نیز اولین مهارت مهم در حوزه ی کاری دواپس را دانش برنامه نویسی می داند. ضمنا زبان هایی که پیشنهاد می دهد Python ، Perl و Ruby است که نقش مهمی را در راه اندازی و نگهداری ci/cd ایفا می کنند. حتی پا را ازین فراتر گذاشته به دانش کار با گیت و آشنایی با چرخه ی توسعه ی نرم افزار SDLC نیز اشاره می کند.رودمپ دواپس آقای احمد باقری (میتینگ های ساها دواپس) https://github.com/ahmadalibagheri/devops-roadmap یادگیری زبان برنامه نویسی را به عنوان یه منفعت مهم در نظر می گیرد و اینکه یک مهندس دواپس خوب، حداقل در یک زبان برنامه نویسی محبوب توانایی کد نویسی دارد. پیشنهاد ایشان برای یادگیری، زبان Go و یا Python است.یوتیوبر معروف (کانال Techworld with Nana) و Docker Captain خانم Nana HOME|TechworldwithNanaLearnDevOpstopicseasily|YoutubeTutorials|Courses|DevOpsBootcampandmorenana.com یکی از ویدیو های اخیر خانم Nana ، در خصوص مسیر یادگیری دواپس بوده که در آن به اهمیت آشنایی با فرایند توسعه ی نرم افزار و یادگیری یک زبان اسکریپتی به خصوص Python اشاره کردند.خب تا اینجا با دیدن چند تا رودمپ ، می شه یه حسی پیدا کرد که اهمیت جایگاه برنامه نویسی در پروفایل شغلی مهندس دواپس در چه حده و می شه گفت نقش مهمی داره.آنچه که در واقعیت تجربه می کنیمبیاید یک مثال واقعی را بررسی کنیم. فرض کنید کارفرما از شما می خواهد که قابلیتی را در سیستم مانیتورینگ موجود Prometheus Alert Manager پیاده سازی کنید که در صورت پایین آمدن سایت و چند آدرس دیگر، به چند شماره ی مشخص تماس تلفنی بگیرد. جهت اینکار api سرویس دهنده نیز آماده است (یعنی اگر شماره تلفن و متن را به آن سرویس ارسال کنید، تماس می گیرد و اپراتور خودکار آن متن را می خواند). چگونه پیاده سازی کنیم؟ممکنه ابزاری هم پیدا بشه ولی به شخصه راهکار بهینه رو دست به کد شدن و نوشتن یک سرویس کوچک برای ایجاد این integration می دانم. به راحتی می توان ازین دست مثال ها پیدا کرد و حتما به عنوان یک مهندس دواپس به طور روزمره برخورد داشته ایم.در بازار کار، چه در جایگاه مصاحبه شونده باشید و چه در جایگاه مصاحبه کننده، تفاوت برنامه نویس بک اند که وارد حوزه ی دواپس شده است با ادمین سیستم یا شبکه کار که وارد حوزه ی دواپس شده و تجربه ی برنامه نویسی ندارد بسیار مشهود است و این واقعیت را می توان در موارد متعددی دید (البته استثنا هم داریم ولی عموم موارد همینطور بوده) چرا که برنامه نویس بک اند ای که وارد حوزه ی دواپس شده، از چند قدم جلوتر شروع کرده است.</description>
                <category>صادق محبی</category>
                <author>صادق محبی</author>
                <pubDate>Tue, 06 Sep 2022 00:22:29 +0430</pubDate>
            </item>
                    <item>
                <title>اگر زبان های برنامه نویسی شخصیت های کارتونی بودند</title>
                <link>https://virgool.io/@mohebbisadegh/%D8%A7%DA%AF%D8%B1-%D8%B2%D8%A8%D8%A7%D9%86-%D9%87%D8%A7%DB%8C-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%B4%D8%AE%D8%B5%DB%8C%D8%AA-%D9%87%D8%A7%DB%8C-%DA%A9%D8%A7%D8%B1%D8%AA%D9%88%D9%86%DB%8C-%D8%A8%D9%88%D8%AF%D9%86%D8%AF-croixv39a2hv</link>
                <description>شوخی با شبیه دونستن زبان های برنامه نویسی و برخی از شخصیت های کارتونی که ممکنه دوستشون داشتیم یا ازشون متنفر بودیم (این مطلب ترجمه ای آزاد از این مقاله ی مدیوم است)شاید برای همه اینطوری نباشه ولی عمدتا کارتون ها بدون توجه به سن و سال ، چه ۱۶ ساله باشید و چه ۲۱ ساله و حتی ۷۵ ساله ، تنها و تنها ژانری هستند که می توانند ما رو پای صندلی هامون و تماشای آن ها بنشانند.جالب اینه که زبان های برنامه نویسی و کد نویسی هم ما را پای صندلی هامون می نشانند! (پس یه شباهت هایی هم هست بین کارتون و زبان برنامه نویسی) اغلب به خاطر اینست که ما را در دنیای حل خلاقانه ی مشکلات غرق می کنند و حتی بعضا به علت باگ هایی که بر می خوریم یا لیست باگ هایی که ورژن به ورژن منتقل می شه و برای حل شون دست به دامن گوگل و StackOverFlow می شویم. خلاصه اینکه برنامه نویسی ما را بدجور روی صندلی جلوی کامپیوتر نشانده است. (گریه ی حضار)نکته اینجاست که...چه بسیار زمان هایی که هدر رفته و راه حل یک ارور و باگ تنها یه کاراکتر عوض کردن احمقانه بوده (می فهمید چی می گم!‌) پس بیاید یه دقیقه حداقل مسخره شون کنیم تا دل مان خنک شود.یه جورایی ما می توانیم هم زبان های برنامه نویسی رو دوست داشته باشیم و هم ازشون متنفر باشیم ، مثل شخصیت های کارتونی. خب مقدمه کافیه بریم سراغ اولی :)زبان سی | C - اختاپوسسخت و اعصاب خورد کن (با داشتن تعداد زیادی سینتکس خفن و مشکل) ، بد اخلاق و بد عنق (از آنجایی یک خط ارور منجر به نمایش تعداد زیادی ارور در کنسول می شود)زبان سی - اختاپوس، کارتون باب اسفنجیزبان HTML و CSS - والدین نسبتا عجیباین دو تا ممکنه واقعی نباشند ولی به صورت اعجاب آوری سورس کد ها را به چیزی (امیدوارانه) خوشگل تبدیل می کنندزبان HTML/CSS - والدین نسبتا عجیبزبان جاوا اسکریپت | Javascript - باب اسفنجیهمسایه ی اختاپوس (زبان سی) هست ولی خیلی دوست داشتنی تره. رنگش مثل لوگوی جاوا اسکریپت ، زرد و خوشرنگ و شادابه. در هر موقعتی که قرار می گیره کار راه اندازه و خیلی اوقات رفتارش عجیبه و غیر قابل درک.زبان Javascript - باب اسفنجیزبان پایتون | Python - گربه ی چکمه پوش یا گارفیلدشجاع،‌ زرنگ، قلدر و باحال ولی در عین حال، چاق و کند و دست و پا چلفتیزبان python - گربه ی چکمه پوشزبان python - گارفیلدزبان جاوا | Java - ولما (کارتون اسکوبی دوو)ولما باهوش ، باکلاس و قابل اعتماده. این شخصیت فقط به جاوا میاد مخصوصا آن جایی که حرف از تدریس الگوریتم و دیزاین پترن باشه ، بین اساتید و مدرس ها محبوب ترینهزبان جاوا | Java - ولما (کارتون اسکوبی دوو)زبان جاوا | Java - ولما (کارتون اسکوبی دوو)زبان گو | Go - تام (کارتون تام و جری)خیلی از برنامه نویسان اذعان دارند که زبان گو قصد دزدیدن جایگاه پایتون را دارد همان طور که تام به دنبال گرفتن جری است. تلاشش برای دستیابی به این رویا ستودنی است ولی به همان اندازه ناامید کننده است.زبان گو | Go - تام (کارتون تام و جری)زبان کاتلین | Kotlin - افعی (کارتون پاندای کونگ فو کار)به طرز باورنکردنی ای باهوش و همچنین انعطاف پذیر و روان. به عنوان کاتلین جدیدا در حال تلاش است تا جای جاوا را بگیرد.زبان کاتلین | Kotlin - افعی (کارتون پاندای کونگ فو کار)زبان ویژوال بیسیک | VBA - هنری نفرت انگیزدر عین سادگی و معصومیت ، هنری نفرت انگیز است حتی از دیدگاه بینندگان این کارتون ، اگر چه که خودش قصدی نداشته. ویژوال بیسیک Visual Basic for Applications نیز در یکی از نظر سنجی های معتبر از دیدگاه برنامه نویسان ، ۷۵ درصد از متخصصان از این زبان ابراز بیزاری می کنند. در عین بی گناهی.زبان ویژال بیسیک | VBA - هنری نفرت انگیزاسمبلی | Assembly - میکی موسمیکی موس ، این کاراکتر قدیمی و خفن والت دیزنی ، همه جا پیدا می شود. همتا و جایگزینی ندارد و بعید است که به این زودی ها جای دیگری برود.اسمبلی | Assembly - میکی موساوقاتتون خوش✋ FollowmeonLinkedIn:www.linkedin.com/comm/mynetwork/discovery-see-all?usecase=PEOPLE_FOLLOWS&amp;followMember=sadegh-mohebbi-172476179 پس نوشت: وقتی به پایتون و کارتون گارفیلد رسیدم ، یاد دوبله ی مازندرانی اون افتادم. محشر بود یادش بخیر :)) تقدیم به همه هم محلی ها https://www.aparat.com/v/98Rfo </description>
                <category>صادق محبی</category>
                <author>صادق محبی</author>
                <pubDate>Fri, 01 Apr 2022 11:23:19 +0430</pubDate>
            </item>
                    <item>
                <title>مرور راه های عبور از تحریم داکر Docker بدون درد و خونریزی</title>
                <link>https://virgool.io/@mohebbisadegh/%D9%85%D8%B1%D9%88%D8%B1-%D8%B1%D8%A7%D9%87-%D9%87%D8%A7%DB%8C-%D8%B9%D8%A8%D9%88%D8%B1-%D8%A7%D8%B2-%D8%AA%D8%AD%D8%B1%DB%8C%D9%85-%D8%AF%D8%A7%DA%A9%D8%B1-docker-%D8%A8%D8%AF%D9%88%D9%86-%D8%AF%D8%B1%D8%AF-%D9%88-%D8%AE%D9%88%D9%86%D8%B1%DB%8C%D8%B2%DB%8C-reqmg3ilxrbc</link>
                <description>https://github.com/docker/hub-feedback/issues/369سلامدوست داشتم در یک مقاله ی ویرگول مروری داشته باشم به این اوضاع در هم ریخته ی تحریم ها به خصوص داستان هایی که موقع pull کردن ایمیج ها با داکر داشتم و همچنان هر از گاهی دارم.خب بریم سراغ خلاصه روش های استفاده از داکر بدون درد و خونریزی (یعنی از پراکسی یا روش های مشابه استفاده نکنیم)سرویس های DNS hijackingتنها کافیه دی ان اس هاتون رو به آی پی های یکی از این سرویس ها ست کنید و مشکل برطرف می شه منتها به صورت موقتی ازش استفاده کنید. لیست ارائه دهندگان این سرویس:شکن (پیشنهاد میشه) : shecan.irبگذر : begzar.irسرویس ۴۰۳ : https://403.onlineاستفاده از رجیستری های جایگزین داکرهابسنگ از آسمون نیومده که حتما از داکرهاب استفاده کنیم! می شه از رجیستری های جایگزین هم استفاده کرد:کوآی (کانتینر رجیستری ردهت) : quay.ioکانتینر رجیستری گیت هاب : ghcr.ioدو تا لینک خوب برای راهنمای ghcrhttps://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registryhttps://github.com/1995parham/no-sanction#dockerhubراه اندازی داکر رجیستری خصوصی و mirror اختصاصی (برای کار های جدی تر و شرکتی توصیه می شه) و تنظیم پراکسی روی سرور آن:چند تا نمونه برای راه اندازی که اولیش، Nexus Repository به شدت توصیه میشه و عالیهhttps://www.sonatype.com/products/repository-ossبه موارد زیر هم یه نگاهی بیاندازید خالی از لطف نیستhttp://port.us.orghttps://github.com/seatgeek/docker-mirrorاستفاده از mirror های عمومی برای داکرهاباگر نخواهیم داکر رجیستری خصوصی راه بندازیم، می توان با یک تنظیم ساده ی داکر، از mirror های عمومی داکرهاب استفاده کرد. لیست زیر mirror های فعالی هست که می شه ازشون بهره برد:داکر رجیستری دات آی آر : https://docker-registry.irداکر دات آی آر  (معرفی شده توسط @farhadm) : https://docker.irابرآروان: https://docker.arvancloud.ir معرفی شده توسط @armanexplorerایران‌سرور: https://docker.iranserver.com معرفی شده توسط @armanexplorerپس نوشت۱: من با هر گونه محدود سازی بی جا مخالفم (چه صیانت باشه، چه رمزارزش و چه هر بوق دیگه) که باعث ایجاد رانت و بی عدالتی بشه به نظرم اشتباهه. بسه دیگه به خدا خسته شدیم!پس نوشت۲: دوست دارم روش هایی که خودم استفاده کردم و نتیجه گرفتم رو اینجا آپدیت کنم و همچنین خیلی خوشحال می شم اگر روشی پیدا کردید و در این مقاله نبود، کامنت بذارید تا به اسم خودتون در متن قرار بدم و همه بتوانیم بهره ببریم. با هم باشیم :)</description>
                <category>صادق محبی</category>
                <author>صادق محبی</author>
                <pubDate>Thu, 03 Mar 2022 11:27:41 +0330</pubDate>
            </item>
                    <item>
                <title>آیا شما یک DevOps کار خفن هستید؟ (شاخص های کارایی کار های دواپس ای)</title>
                <link>https://virgool.io/@mohebbisadegh/%D8%A2%DB%8C%D8%A7-%D8%B4%D9%85%D8%A7-%DB%8C%DA%A9-devops-%DA%A9%D8%A7%D8%B1-%D8%AE%D9%81%D9%86-%D9%87%D8%B3%D8%AA%DB%8C%D8%AF-%DB%8C%D8%A7-%D8%B4%D8%A7%D8%AE%D8%B5-%D9%87%D8%A7%DB%8C-%D8%B9%D9%85%D9%84%DA%A9%D8%B1%D8%AF%DB%8C-%DA%A9%D8%A7%D8%B1-%D9%87%D8%A7%DB%8C-%D8%AF%D9%88%D8%A7%D9%BE%D8%B3-%D8%B7%D9%88%D8%B1-badpvviyiq4j</link>
                <description>اگر می توانستیم سرویس ها و نرم افزار های داخل سرور هامون رو به تصویر بکشیم، خیلی وقتا به همچین فاجعه ای می رسیم که تغییر و آپدیت هر یک از این ها یه کابوس می شه!مدتیه که هر وقت آگهی های شغلی به چشمتون می خوره یا سری به لینکدین می زنید، به راحتی می تونید متوجه بشید که درخواست نیروی DevOps خیلی زیادتر شده و به خوبی رو به رشده. اگر از شرح شغلی و لیست مهارت های متنوع شون بگذریم، خوبه که یه دواپس کار و سازمانی که می خواد همچین کسی رو استخدام کنه، بدونه که چه شاخص هایی برای اندازه گیری میزان موفقیت در این حوزه وجود داره.joined to google cloudیک مرکز پژوهشی به نام DevOps Research and Assessment با نام مخفف DORA که اخیرا توسط گوگل هم در اختیار گرفته شده،‌ ۶ ساله که گزارش هایی رو در خصوص وضعیت DevOps در دنیا ارائه میده و تحقیقات نسبتا گسترده ای داشته. فعلا آخرین گزارش در دسترس سال ۲۰۱۹ منتشر شده که اطلاعات جامع و به درد بخوری داره و مرورش رو پیشنهاد می کنم. حوزه های مختلفی وجود داره که می شه درباره شان صحبت کرد ولی در این مقاله می خواهیم به طور خلاصه چند تا شاخص مهم را معرفی کنیمیه سریا می گن یا باید سرعت رو نگه داریم یا کیفیت رو. جمله هایی مثل «فلانی کیفیت رو فدای سرعت کرده» یا «کارش زیاد طول کشیده ولی در عوض کیفیت داره» و جملات کلیشه ای از این قبیل رو زیاد شنیدیم. اما در این بین، فرهنگ DevOps با اتوماتیک سازی که به نظرم کار اصلیشه، قصد افزایش سرعت و کیفیت همزمان داره و این اتفاق باحال با ابزار ها و تکنولوژی هایی که داریم به خوبی شدنیه. خب بهبود این دو مقوله نیازمند اندازه گیریه و اندازه گیری هم به شاخص نیاز داره. پس در این دو حوزه ی سرعت و کیفیت (پایداری) چه شاخص هایی رو می تونیم داشته باشیم؟نرخ دیپلوی | Deploy Frequentlyیعنی چند بار در ماه (یا بازه ی زمانی دلخواه) سرویس ها رو بدون خطا و درست (بدون Down Time یا پایین اومدن سرویس) دیپلوی یا منتشر می کنیم. هر چه قدر این نرخ بالاتر باشه، یعنی رساندن فیچر و رفع مشکلات و ... و به معنای کلی انتقال ارزش به مشتریان سریع تر صورت می گیره. از طرفی برای تیم فنی این مزیت رو داره که یک یا چند فیچر بزرگ رو به قطعات کوچک تری تقسیم کنند و هر وقت تموم شد منتشر کنن. این امر چند تا مزیت داره از جمله رفع مشکلات سریع تر انجام می شه و باگ کمتر پیش میاد و همچنین از طرفی چابک بودن تیم حفظ می شه. رویکرد آبشاری در مقابل رویکرد چابک نیازمند زمان زیادی از ایده پردازی و پیاده سازی تا انتشار داشت ولی با پیاده سازی DevOps این زمان کاهش پیدا می کنه و می توانیم مدام در حال تغییر و ارزش آفرینی برای مشتریان و بهتر کردن محصول مون باشیم. اگر روی پروژه هایی کار می کنید که جرئت دست زدن به سرویس و آپدیت اش رو ندارید و انصافا هر دیپلوی براتون نفس گیره، مقدار این شاخص به شدت بالاست و در چنان وضعیت بدی قرار دارید که به نظرم خدا نصیب گرگ بیابون نکنه (طفلی برنامه نویسا و ادمین سیستم شون!)زمان شروع تا اتمام فرایند دیپلوی هر تغییر | Lead Time for Changesچقدر طول می کشه تا کد کامیت شده روی پروژه به سرور های اصلی و نهایتا محصول در دست مشتریان برسه. حتی اگر CI/CD رو هم پیاده سازی کرده باشید ولی چندین ساعت طول می کشه تا کد ها به سرور اصلی برسن، خب پس چرا اصلا اینهمه زحمت کشیدیم! مثل قدیما همون دستی دیپلوی کنیم خوشحال تریم... (خسته نباشی دلاور، خدا قوت پهلوان!) https://media.giphy.com/media/gOkawaguYNiSI/giphy.gif راه های زیادی وجود داره تا فرایند دیپلوی و بازنشانی خودکار سرویس هامون رو بهینه تر و پرسرعت تر کنیم. مثلا فرایند های سنگین بیلد گرفتن و اجرای تست رو روی کلود یا سرور هایی جداگانه و مناسب انجام بدیم و روی سرور اصلی لبه اجراشون نکنیم، راه اندازی داکر رجیستری و داکرایز کردن سرویس ها تا از کلی امکانات از جمله multi stage build و base image و غیره استفاده کنیم. کلی قدم می شه ورداشت و مسلما از نتایج هر قدم شگفت زده خواهیم شد. اینطوری می شیم یه دواپس کار خفن!نرخ دیپلوی ناموفق | Change Failure Rateاگر هر وقت برنامه نویسا و تیم توسعه باید قبل از پوش کردن روی master یا برنچ اصلی بهمون اطلاع بدن، همیشه برای هر دیپلوی اتوماتیک CI/CD روی سرور اصلی دستامون از شدت استرس عرق کنه و بعد از پایان فرایند CI/CD باید مدام این ور و اون ور سرور خرده کاری کنید تا سرویس درست کار کنه و ... این شاخص برامون به شدت بالاست و اوضاع خوب نیست. بالا بودن این شاخص نمایانگر اینه که کیفیت و پایداری سیستم پایینه و البته روی تعداد دیپلوی ها و سرعت مون هم تاثیر منفی داره.  باید تا جایی که می توانید خیالتون از دیپلوی اتوماتیک راحت باشه مثلا قبل از دیپلوی روی سرور اصلی تست های Integration و Unit test و سایر تست ها اجرا بشن تا دیپلوی ناموفق نداشته باشیم یا کمتر باشه و همچنین تا آخر کار دیپلوی، به درستی و بدون خطا CI/CD رو پیاده سازی کنیم.مدت زمان برگشتن به وضعیت پایدار | Time to Restore Servicesناگهان متوجه می شویم که آخرین کامیت و تغییراتی که روی سرور اصلی اعمال شده دچار مشکله و در وضعیت اورژانسی هستیم. باید سریع بتوانیم به وضعیت پایدار قبلی برگردیم یا مشکل رو حل کنیم (این وسط باید یادمون باشه که در این شرایط تست رو به بهانه ی وضعیت اضطراری نادیده نگیریم) به هر حال تا جای ممکن باید زمان بازگشت به وضعیت پایدار رو پایین بیاریم تا کیفیت و پایداری سیستم بهبود پیدا کنه. اقداماتی همچون versioning باید به صورت پایه ای رعایت بشه و برای پکیج های قابل اجرا از نرم افزار هامون یه پایگاه رجیستری جامع و در دسترس داشته باشیم. از امکانات پیش فرض ابزار های CI/CD هم میشه استفاده کرد مثل Environment در Gitlab CI که خیلی جالبه. در ضمن، بالا بودن شاخص «زمان شروع تا اتمام فرایند هر تغییر» روی این شاخص تاثیر مستقیم می ذاره.بررسی و مرور شاخص ها تمام شد ولی خیلی از سوالات مان باقی ماند مثل: چجوری اینا رو اندازه گیری و مانیتور کنیم؟ برای بهبود هر کدوم از این شاخص ها به تفصیل چه راهکار ها و ابزار هایی رو در دسترس داریم؟ آیا شاخص های دیگری هم هست؟ یک سازمان چگونه می تواند در این مسیر حرکت کند و چه الزامات و پیش نیاز هایی  برای طراحی مسیر راه و بهبود این شاخص ها وجود دارد؟ و .... دوست دارم آروم آروم به هر کدام از این ها بپردازیم.کار مهندسی دواپس، یه کار بزن در رو نیست بلکه باید به طور مداوم رشد و بهبود پیدا کنه و با تکنولوژی های جدید هماهنگ و سازگار بشهمنبعhttps://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performanceممنونم که تا اینجا اومدید. پذیرای فیدبک هاتون هستم Happy Devopsing :)</description>
                <category>صادق محبی</category>
                <author>صادق محبی</author>
                <pubDate>Thu, 26 Aug 2021 09:55:27 +0430</pubDate>
            </item>
                    <item>
                <title>تجربه ی تغییر از سیستم عامل mac os به ubuntu 20.04</title>
                <link>https://virgool.io/taaghche/%D8%AA%D8%AC%D8%B1%D8%A8%D9%87-%DB%8C-%D8%AA%D8%BA%DB%8C%DB%8C%D8%B1-%D8%A7%D8%B2-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D8%B9%D8%A7%D9%85%D9%84-mac-os-%D8%A8%D9%87-ubuntu-2004-rwbko1twjiz3</link>
                <description>والپیپر دیفالت اوبونتو ۲۰.۰۴این روزا که بازار مهاجرت و یاد گرفتن زبان انگلیسی برای دریافت گواهی های لازم برای اخذ ویزا خیلی پر رونق شده، با خودم گفتم خب منم مهاجرت کنم بخدا خسته شدم! تصمیم نهایی ام رو گرفتم که با در اختیار داشتن یه مک بوک قدیمی اواخر سال ۲۰۱۱ از سیستم عامل Mac OS high sierra به Ubuntu 20.04 مهاجرت کنم. بهانه هایی هم برای مهاجرت داشتم از جمله بسته بودن (یعنی متن باز نبود! خفقان بود) و البته از همه مهم تر،‌ ددلاین اپل برای کنار گذاشتن پشتیبانی از سیستم عامل های 10.13 به قبل.این اتفاق داخل پلتفرم اپل به معنای دور ریختن کامله و هیچ چی دیگه عملا نصب نمی شه رو سیستمت (حتی ورژن آخر برخی از نرم افزار هایی که ازشون استفاده می کردم دیگه نسخه ی مک او اس منو پشتیبانی نمی کردن) در ضمن آپدیت کردن سیستم هم بسیار سخت و چالشیهیه مقدار سرعتش هم کم شده بود که در این مواقع معمولا اولین کاری که به ذهن آدم می رسه تعویض با نصب مجدد سیستم عامله. به هر حال شاید یه مقدار می خواستم فضا و محیط برنامه نویسیم رو به طور کامل عوض کنم و در نهایت این تصمیم سخت رو گرفتم.ترسناک ترین روش نصب۱- اول فایل iso رو از خود سایت ubuntu.com دانلود کردم و سپس با نرم افزار Unetbootin فلش خودمو بوتیبل کردم۲- ری استارت کردم و بعدش با نگهداشتن کلید alt رفتم روی انتخاب بوت و فلش خودمو انتخاب کردم. یخورده صفحه سیاه شد و یه سری چیز میز می نوشت (مربوط به چک کردن سخت افزار و درایور های لازم و تست شون بود) که بعد از حدود ۱۰ دقیقه تموم شد۳- صفحه ی نصب نمایان شد و همینطور مراحل رو رفتم جلو تا شروع به نصب کنه. موقع روش نصب هم گزینه ی Erase all disk رو زدم تا مک او اس قبلیم رو پاک کنه و همینجا بود که پل های پشت سرم رو خراب کردم تا  دیگه برنگردم به mac osکلنجار رفتن با مشکلاتیه مشکل خیلی مهم در این روش نصب نحوه ی بوت شدن مک بوکه که به یه پارتیشن با فرمت خاصی نیاز داره. در حالی که ابونتو این فرمت رو به صورت پیش فرض نداره. یعنی وقتی مک بوک رو پاک می کنید چیزی نیست که بیاره (یعنی پیدا نمی کنه) و یه صفحه ی اعصاب خورد کن رو نشون میده بدون هیچ توضیح خاص دیگه ایآخه چرا؟؟ واقعا چرا؟؟وقتی نصب تموم میشه، خود اوبوتو بهت می گه که فلش رو دربیار و ری استارت کن ولی به حرفش گوش نده! من به طور اتفاقی متوجه شدم که با گذاشتن فلش روی سیستم و نگه داشتن alt می تونم وارد سیستم عامل بشم. اولین پاسخی که برای این مشکل هست اینه که اوبونتو رو در کنار مک او اس نصب کنید که با استفاده از نرم افزار REFIt به راحتی امکان پذیره. خب من mac os رو پاک کرده بودم و راه برگشتی نداشتم (یا حوصله ی راه طولانی رفت و برگشت رو نداشتم!)روش دومی که تونستم این مشکل رو حل کنم فرمت پارتیشن بوت به فرمتی بود که اپل دوست داره! مقالاتی رو با سرچ efi fix on macbook for pure installing ubuntu خوندم و به اینجا رسیدم. با توجه به این که تونستید وارد سیستم عامل اوبونتو بشید مراحل رو از نصب پکیج های mactel شروع کنید و برید جلو. البته یخورده حس ادمین سیستمی و خوره ی کامپیوتر بودن هم می خواد چونکه این وسط هم کلی داستان وجود داشت مثل عدم پشتیبانی نسخه ی آخر این پکیج از ubuntu 20.04 که باید فایلای باینری نسخه ی xenial رو دستی نصب کنید و ... در نهایت ubuntu 20.04 بدون نیاز به نشون دادن لوگوی اپل و فقط پس از یه صفحه ی سفید خیلی سریع و عین هلو میاد بالا (وقتی درست شد یه قهوه فرانسه ی غلیظ مشتی واسه خودم درست کردم!!!)یکی دیگه از مشکلات عدم ساپورت پیش فرض سه انگشت تاچ پد بود که خداروشکر با Fusuma حل شد (ممنون فووزووما)فونت های فارسی رو هم نصب کنید و تاریخ سیستم و اکانت هارو هم درست کنید و دونه دونه برطرف شون کنیداینم یه عکس از خونه ی جدید من، Ubuntu 20.04 desktopیه خونه ی جدیدالآن این مقاله رو دارم با باز کردن ویرگول روی آخرین نسخه ی فایرفاکس (که واقعا عالی شده) روی مک بوک اوبونتو می نویسم. در کنارش Spotify هم بازه و دارم موسیقی گوش میدم.یه چیزی که خیلی آزارم میداد ترمینال mac os بود که نه لینوکسی بود و نه ویندوزی. آدم تکلیفش با ویندوز مشخصه ولی ترمینال mac os شباهت های زیادی با لینوکس داره به همراه یه سری محدودیت ها و مشکلات و گیر ها که اعصاب خورد کن. ترمینال Ubuntu واقعا بهترینه و یه ابزار فوق العاده قدرتمند واسه من.برای ریموت زدن به سرور های ویندوزی از نرم افزار خوب Remmina استفاده می کنم که فوق العاده کار راه اندازه به صورت پیش فرض روی سیستم نصبه (ریموت هارو می شه دسته بندی و لیست ساخت و تنظیمات خوبی هم داره برای رزولوشن و کیفیت و سیو کردن رمز ها و ..) ولی به خوبی microsoft remote desktop که رو مک داشتم نیست. تقریبا قبل از نصب اوبونتو جزو بزرگ ترین نگرانی هام بود که RDP Remote Desktop رو پشتیبانی می کنه یا نه. یه گزینه ی دیگه هم نصب free remote desktop manager عه که مسلما بهتره ولی لازم نشده نصبش کنم چونکه همون Remmina جوابهمثل همیشه سلطان برنامه نویسای امروز، visual studio code ظاهر میشه. نسخه ی خوب و کاملی برای لینوکس به خصوص اوبونتو داره که همه فن حریفه. IDE های دیگه ای هم هست که من نیاز نداشتم بهشون و نصب نکردمیه مشکلی که بهش برخورد کردم اینه که Swap سیستم زودی به آخراش می رسه و اندکی کند میشه، به خصوص موقع کار با vscode که باید بهش توجه کرد. یه چیزی هم صادقانه بگم، mac os خوشگل تر و سریع تره و با کیبورد مک بوک بهترین تجربه رو فقط با خود mac os می تونید تجربه کنید. من الآن موقع تایپ کردن و کد زدن مثل کسی هستم که تازه داره رانندگی یاد می گیره و مدام به دنده نگاه می کنه، منم مدام به صفحه کلید نگاه می کنم. تا جایی که شد و تونستم کلید های میانبر کیبورد رو شخصی سازی کردم که شبیه mac os ام بشه، ولی واقعا شبیهش نشده که یه مقدار برام آزار دهنده است (منتها می دونم بعد یه مدت عادت می کنم و راه می افتم)من ترک عادت و ورود به دنیای جدید رو دوست دارم. طرفدار مهاجرت کردن نیستم ولی اعقتادم اینه که، با اینکه مهاجرت کردن و رفتن به یه کشور دیگه سخته ولی همین تغییر فضا و محیط زندگی و چالش هاش آدم رو بزرگ می کنه و رشد میده.با اینکه ساعت مطالعه ام به شدت پایینه ولی کتاب فقط برای تقریح رو خوندم و اینطوری جوگیر شدم! پیشنهاد می کنم این کتاب رو از طاقچه بخونید ولی مثل من جوگیر نشید و سعی کنید ساعات مطالعه تون رو بالا ببرید (برید به نمودار کارنامه مطالعه تون در طاقچه) تامام</description>
                <category>صادق محبی</category>
                <author>صادق محبی</author>
                <pubDate>Sun, 15 Aug 2021 11:12:36 +0430</pubDate>
            </item>
                    <item>
                <title>چطوری از طاقچه سر در آوردم</title>
                <link>https://virgool.io/@mohebbisadegh/%DA%86%D8%B7%D9%88%D8%B1%DB%8C-%D8%A7%D8%B2-%D8%B7%D8%A7%D9%82%DA%86%D9%87-%D8%B3%D8%B1-%D8%AF%D8%B1-%D8%A2%D9%88%D8%B1%D8%AF%D9%85-yjirjhme07zq</link>
                <description>یادش بخیر، یه دبیرستانی شهرستانی بودیم! پدرم به واسطه ی اینکه استاد کامپیوتره، توسط سازمانی که در آنجا مشغول بود، به نمایشگاه های تلکامپ و الکامپ و ... فرستاده میشد جهت خرید تجهیزات جدید و خیلی کارای دیگهفکر کنم سال ۹۳ بود و من دبیرستانی بودم، پدرم به نمایشگاه کتاب تهران رفته بود. صبح زود رفت و شب برگشت با یه کیف پر از کاتالوگ های رنگ و وارنگ، منم به اون کیف حمله ور شدم و اولین مواجه ی من با طاقچه اینجا و با دیدن این پوستر کوچیک و لذت بخش بودطاقچه، نزدیک ترین کتابفروشی به شهراپلیکیشن طاقچه رو نصب کردم و خیلی سریع با هم آشنا شدیم :) اون موقع ها یه وبلاگ به اسم اولین پرواز روی میهن بلاگ (که الآن بسته شده و به کارش پایان داده) داشتم و اینقد ذوق زده بودم که دربارش نوشتم:این متن پست وبلاگ اولین پرواز (وبلاگ شخصی و قدیم من) سال ۱۳۹۵ و لازم به ذکره که اون موقع دوست داشتم یه پلتفرم کتاب صوتی طراحی و راه اندازی کنم و براش داشتم برنامه نویسی اندروید یاد می گرفتم!طاقچه، نزدیک ترین کتاب فروشی به شهرنمایشگاه کتاب شده بود و من طبق معمول هر سال که می رفتم نمایشگاه کتاب تهران (با این که دور بود و علاوه بر اون باید از بزرگراه چالوس!! عبور می کردیم) امسال به دلیل مشغله و کنکور نتونستم برم. بالاخره به هر صورتی که بود، بابام خودش تنهایی رفت نمایشگاه کتاب. وقتی که پدرم برگشت بر خلاف سال های قبل نمایشگاه کتاب، براش خیلی جذاب و جالب شده بود. برام از غرفه های مختلف تعریف می کرد تا رسید به بروشور اپ طاقچه که توی کیفش بود...از غرفه ی بسیار بزرگش گفت تا رفتار شخص مسئول اون غرفه و نوع صحبت کردن آن ها. فارغ از این که عکس قشنگی بود، مطالب کوتاهی هم درباره ی طاقچه نوشته بود. من قبلا اسم این برنامه رو شنیده بودم ولی نصبش نکردم. نمی دونم با خودم چی فکر می کردم! تا وقتی که این جریان ایده و کتابخانه ی صوتی بشنو پیش اومد و من هم شروع به مطالعه و تحقیق کردم، لازم دیدم که این گونه برنامه ها رو هم نصب کنم. تازه متوجه شدم که از چه چیزی غافل بودم طاقچه، نسبت به کتابخانه های اندرویدی دیگه، از رابط کاربری یا همون UI خوبی برخوردداره. کار با اون راحت تر و لذت بخش تره. رنگ زمینه ها و محیط برنامه چشم رو خسته نمی کنه. کتاب های متنوع، بسیار خوب و با کیفیتی هم داره که انتشارات های معروفی همچون جامی و سوره مهر، بوتیمار همکاری داره. البته نا گفته نماند که خود طاقچه هم به عنوان یک انتشارات (از نوع الکترونیکی) فعالیت می کنه که جای شکر داره. نمی دونم چرا مردم حاضرن مثلا یه کتاب 15 هزار تومنی رو بخرن ولی همون کتاب رو که به قیمت 5 هزار تومن توی این جور برنامه ها اومده رو نمی خرن (اینم خودش یه مسئله ی عمیق فرهنگیه) بگذریم... داشتم می گفتم...طاقچه علاوه بر کتاب، روزنامه ها مثل شرق، ابرار، راه مردم، ایران، جهان اقتصاد، ... و مجله ها و هفته نامه های بسیاری هم در خودش داره از جمله کلیک، شما، اقتصاد برتر، تحلیل پژوهشی کتاب،...نتیجه گیری نهایی رو به خودتون واگذار می کنم. پیشنهاد می کنم حتما این برنامه رو نصب کنید و یه سری هم به بخش داستان و رمان بزنید. من که معتادش شده بودم! تنوع خوبی دارهدرباره فیدیو و آوابوک و چند تا دیگه هم نوشته بودم که از حوصله ی مطلب خارجه ولی فقط همینو بگم که کلی از فیدیبو بدم اومده بود :)...خخخخخروز ها گذشت  تا این که رسیدیم به سال ۱۳۹۸، من در استارتاپ وصال به عنوان مدیر فنی همه فن حریف مشغول بودم. (همینجا می گم اگه اهل گوش دادن به مداحی و مولودی و نوای مذهبی هستید، اپلیکیشن وصال رو نصب کنید) اواسط سال بود که من به همراهی مدیر وصال تونسته بودیم برای مشاوره با مدیر عامل وقت طاقچه وقت جلسه ای رو هماهنگ کنیم، جلسه ی خیلی خوبی بود و در آخر همون جلسه به دو نفرمون موقعیت های شغلی ای پیشنهاد دادن که در ابتدا قبول نکردیم. ابتدای سال ۱۳۹۹ شرایط خاصی پیش اومد که هر دوتامون برای موقعیت های شغلی فوق اقدام کردیم. در نهایت دوستم (مدیر وصال) استخدام شد و من... خودتون ماجرای مصاحبه ی شغلیم رو بخونید:فروردین ۱۳۹۹ بود و اوج کرونا، من شهرستان بودم و به معنای واقعی قرنطینه. در چنین شرایط خاصی ابتدا از منابع انسانی حصین (شرکت هولدینگ که طاقچه زیر مجموعه اش هست) با من تماس گرفتن یه سری سوالات از محل زندگی و تحصیلات و سوابق و تجربیات کاری و به طور کلی درباره ی اون چیزی که توی رزومه نوشتم پرسیدن و یجورایی چک کردن که گفته هام با رزومه تطبیق داره یا نه. روز بعدش باهام یه جلسه مصاحبه هماهنگ کردن که فکر کنم هفته ی بعدش بود برای موقعیت شغلی برنامه نویس بک اند node jsاواخر فروردین ماه بود و من همچنان شهرستان بودم، همه چیز رو آماده کردم برای جلسه ی مصاحبه ی فنی طاقچه. شروع شد و من تا حدی مضطرب به صحبت های اولیه ی مدیر فنی طاقچه گوش می دادم. بعدش یه سوال الگوریتمی پرسیده شد و منم به ساده ترین روش حلش کردم، بعدش ازم خواست که روش حلش رو بهتر کنم و بعد از اندکی تلاش نتونستم (اینطوری بود که من واقعا با جاوااسکریپت کد می زنم و به صورت آنلاین تلاش هام رو می دید) خلاصه براتون بگم که از هر چیزی که توی رزومه ام نوشته بودم پرسید با جزییات فراوان و هر موضوع چندین سوال پیچیده که نصف بیشترش رو یا کامل نمی دونستم و می گفتم بلد نیستم یا نصفه و نیمه جواب دادم، اواخر مصاحبه هم مجددا در محیط node js کد زدم. مغزم انگار چند دور دویده بود و دیگه جانی براش نمونده بود. دو ساعت گذشت و این مصاحبه ی آنلاین به پایان رسید و گفتن نهایتا تا یک هفته نتیجه ی نهایی رو ایمیل می کنن برام. مصاحبه گر که مدیر فنی بود، فوق العاده همراه و خوش برخورد و باحوصله بود. (الآن که همکارشون هستم این شناخت خوب اولیه برام هر روز بیشتر از روز قبل ثابت شده)بعد از دو هفته ایمیلی برام اومد که با متنی بسیار عالی بهم گفتن که رد شدم و برای اون موقعیت شغلی برنامه نویسی node js مناسب نیستم. همزمان در موسسه تبیان به عنوان برنامه نویس فول استک پاره وقت به شدت دون پایه استخدام شدم که کارای سایت پرسان رو جلو ببرم. اون موقع ذهنم به شدت آشفته بود... کارای همزمان بسیاری داشتم. تبیان که مشغول شده بودم و در کنارش مدیریت فنی و مسؤولیت زیاد سایت وصال همواره همراهم بود. علاوه بر این همه مشغولیت، پشتیبانی زیرساختی و ادمین سیستمی پاره وقت سایت رومیتا رو قبول کرده بودم که کلی کار انتقال سرور و ریفکتور زیرساخت نرم افزاری و ازین جور کارا به گردنم انداخته بود، به همراه چند نفر از دوستام پروژه هم می گرفتم (از اول سال ۱۳۹۹ تا آخر تابستون حدود ۸ تا پروژه شد!) که دوتاش هم با اصطکاک فراوان به شدت آزار دهنده بدون نتیجه ی مالی و با تحمل ضرر به پایان رسید. خیلی از تلفن هارو جواب نمی دادم و با پیام های کارفرما ها یا اعضای تیم برنامه نویسی مون، دچار رفلاکس عصبی می شدم و تا حدی افسرده شده بودم و مدام احساس خستگی می کردم.اواسط تابستان سال ۱۳۹۹ بود. در چنین شرایطی ازدواج کردم و این اتفاق نقطه ی عطفی برام بود. ساکن تهران شدم. آروم آروم دست به انتخاب بین کار هام زدم و شروع به حذف شون کردم. از وصال که یه جورایی بچه ام بود به سختی جدا شدم. تلاش زیادی کردم که پروژه های ناتمام رو تموم کنم و اونهایی که وقت نداشتم رو به کسانی دیگه بسپارم حتی اگه هزینه داشت...خلاصه اینکه اوضاع روز به روز بهتر و بهتر می شد.حدود  آبان ۱۳۹۹ بود که مجددا از طاقچه باهام تماس گرفتن و منو برای موقعیت شغلی جدیدی با عنوان DevOps Engineer و ادمین سیستم دعوت کردند. خیلی خوشحال شدم و قبول کردم. جلسه ی مصاحبه به سختی دفعه قبل دو ساعته نبود و کوتاه تر بود، در ضمن به صورت حضوری رفتم در محل شرکت و کلا راحت تر گذشت. اعتماد به نفس بیشتری داشتم و البته در طول مدت یک سالی که گذشته بود، کلی کار جور واجور کرده بودم و تسلطم بیشتر شده بود، اعتقادی به شرکت در دوره ها و موسسات آموزشی نداشتم ولی به هر حال برای بهتر شدن رزومه و کسب تجربه در دوره ی node js مکتب شریف شرکت کرده بودم که تا حدی تاثیر داشت، در نتیجه اندکی بهتر از مصاحبه ی دفعه ی قبل ظاهر شدم. مرحله ی بعدی مصاحبه یه روز به صورت حضوری روی یه پروژه ای که بهم داده بودن، توی شرکت کار کردم و همچنین با فضا آشنا شدم. خیلی تجربه ی خوبی بود البته توی اون روز نتونستم پروژه رو به نتیجه برسونم. خیلی سخت بود انصافا! از صبح که شروع به کار کردم تا غروب نتونستم کاری از پیش ببرم.دو سه روز گذشت و من به کلی از به نتیجه رساندن پروژه آزمایشی ناامید بودم. همسرم در جریان مصاحبه و داستان هاش بود و همین روز ها بهم گفت که یه بار دیگه تلاش کنم تا شاید به نتیجه ای برسه...منم نشستم پای لپ تاپ و بعد از کمتر از یه ساعت تلاش و دیباگ کردن، بالاخره مشکل اون پروژه آزمایشی حل شد. بالافاصله برای مدیر فنی طاقچه فرستادم و دو روز بعد، خودشون بهم خبر دادن که در طاقچه استخدام می شم :) و جلسه ای رو برای شروع به کار و توضیح ساختار تیم و شرکت هماهنگ کردند...و اینطوری شد که از طاقچه سر در آوردمتا الان حدود هفت ماه هست که در تیم طاقچه مشغول به کارم. اولین و همه ترین نکته ای که در مورد فضای کاری طاقچه به نظرم می رسه، اعتماده. بار ها به دلایل مختلف اشتباه کردم که منجر به مشکلات فراوانی شد ولی اعتماد اولیه جهت واگذاری کامل و تحویل کار ها از بین نرفت. کلی فرهنگ کاری مثبت و فوق العاده ی دیگه رو میشه دید مثل اهمیت دادن درجه ی اول به نتیجه، گفتگوی موثر، پذیرا شدن تکنولوژی های جدید و عدم گارد گرفتن در مقابلشون، فضای دوستانه و صمیمی، تواضع و فروتنی و آنبوردینگ فوق العاده عالی :) https://www.instagram.com/p/CMnMnVtHocK/?hl=en داره روز به روز طاقچه بهتر و بزرگ تر میشه، از این که در این تیم عالی (بدون اغراق) حضور دارم و در این شکوفایی سهیم هستم (به اندازه ی خودم) بسیار خوشحالم. پایین پادکست مورد حمایت طاقچه رو می تونید بشنوید و در بالا پیج اینستاگرام طاقچه رو می تونید ببینید. منم توی این پست اینستا هستم و عید امسال رو تبریک گفتم D: https://castbox.fm/episode/%D9%82%D8%B3%D9%85%D8%AA-%DB%B1%DB%B5-%7C-%D8%A7%D8%B2-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87%E2%80%8C%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%AA%D8%A7-%D8%AC%D8%A7%D9%85%D8%B9%D9%87%E2%80%8C%D8%B4%D9%86%D8%A7%D8%B3%DB%8C-%D8%A8%D8%A7-%D8%AC%D8%A7%D8%AF%DB%8C-%D9%85%DB%8C%D8%B1%D9%85%DB%8C%D8%B1%D8%A7%D9%86%DB%8C-id2679588-id387515410?utm_source=website&amp;utm_medium=dlink&amp;utm_campaign=web_share&amp;utm_content=%D9%82%D8%B3%D9%85%D8%AA%20%DB%B1%DB%B5%20%7C%20%D8%A7%D8%B2%20%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87%E2%80%8C%D9%86%D9%88%DB%8C%D8%B3%DB%8C%20%D8%AA%D8%A7%20%D8%AC%D8%A7%D9%85%D8%B9%D9%87%E2%80%8C%D8%B4%D9%86%D8%A7%D8%B3%DB%8C%20%D8%A8%D8%A7%20%D8%AC%D8%A7%D8%AF%DB%8C%20%D9%85%DB%8C%D8%B1%D9%85%DB%8C%D8%B1%D8%A7%D9%86%DB%8C-CastBox_FM پس نوشت۱: این پست تبلیغاتی نیست! صرفا تجربیات شخصی بنده از مراحل استخدام و کار در طاقچه استپس نوشت۲: در اینجا و اینجا می تونید تجربیات بقیه رو درباره شرکت طاقچه بخونید</description>
                <category>صادق محبی</category>
                <author>صادق محبی</author>
                <pubDate>Sat, 26 Jun 2021 01:07:27 +0430</pubDate>
            </item>
                    <item>
                <title>بررسی مزایا و معایب برون سپاری تیم زیرساخت</title>
                <link>https://virgool.io/relyonit/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D9%85%D8%B2%D8%A7%DB%8C%D8%A7-%D9%88-%D9%85%D8%B9%D8%A7%DB%8C%D8%A8-%D8%A8%D8%B1%D9%88%D9%86-%D8%B3%D9%BE%D8%A7%D8%B1%DB%8C-%D8%AA%DB%8C%D9%85-%D8%B2%DB%8C%D8%B1%D8%B3%D8%A7%D8%AE%D8%AA-ycfzibiwnkbe</link>
                <description>داستان اینه که...در یک کسب و کار متوسط یا استارتاپ، روز ها پشت هم می گذره و شما به عنوان برنامه نویس یا مدیر فنی در حال کار و تمرکز روی ویژگی های جدید و باگ های محصول تان هستید به طوری که پشت سر هم چیده شده اند. اولویت شرکت با توجه به منابع محدودی که داره، پاسخ دهی سریع به نیاز های بازار و مشتریان بودهدر همین حین سوالاتی به ذهن می رسه که: دیتابیس جدیدی که استفاده کردیم برنامه ی بکاپ و بازیابی درستی داره و اصلا پیاده سازی شده که به صورت اتوماتیک تنظیم بشه؟ اگر اشتباهی موقع کد زدن برنامه نویس رخ بده و اون اشتباه روی سرور آپدیت بشه، چقدر طول می کشه که برطرفش کنیم و چه راهکاری برای جلوگیری از تکرار این اتفاقات داریم؟ نکنه فلان پورت هنوز باز باشه و اتفاق امنیتی برای اطلاعات مون بیوفته؟ ...و کلی سوال زیرساختی دیگه که مدام براتون یادآوری می شه، پاسخ دادن و رفع هر کدام ازین سوالات نیازمند زمان و هزینه و تجربه و علم به اون هست و در مقابل بسیار مهم و حیاتیه. در ادامه به برخی از مزایا و معایب برون سپاری امور زیرساختی و سروری و دواپس می پردازیممزایای برون سپاری تیم زیرساختدشوار بودن و پر هزینه بودن نگهداری تیم زیرساخت: پیدا کردن نیروی مناسب و قابل اطمینان جهت مدیریت و نگهداری زیرساخت کاری مشکل و پر هزینه استلزوم اقدام سریع و همراه با تجربه در موقعیت های بروز مشکل: فرض کنید به طور ناگهانی مشکلی در سرویس های نرم افزاری محصول تان پیش آمده که هر دقیقه از باقی ماندن آن منجر به ضرر مالی خواهد شد. نیروی داخلی زیرساخت دارای تجربیات محدودتری نسبت به یک تیم زیرساخت است و همچنین یک تیم منسجم و مستقر روی نرم افزار، می تواند پاسخگویی به نسبت سریع تر و بهتری نسبت به برطرف کردن مشکل به وجود آمده داشته باشدتمرکز روی هسته ی کسب و کار و محصول نرم افزاری: تمامی فرایند های دیپلوی و به روز رسانی نرم افزار، کلاستر دیتابیس، بررسی دوره ای برنامه های پشتیبان گیری و بازیابی و ... را می توان به تیمی خارج از تیم اصلی توسعه نرم افزاری شرکت سپرد و زمان و انرژی فوق را جهت توسعه ی محصول به کار بردمعایب برون سپاری تیم زیرساختعدم تسلط بر ساختار کلی زیرساخت نرم افزار: عدم آگاهی و تسلط کامل بر ابعاد مختلف محصول نرم افزاری تان می تواند دچار مشکلات فراوانی شود. اگر تیم زیرساخت فوق قبل از هر چیز به بررسی و گفتگو بپردازد و ارتباط تنگاتنگی با تیم اصلی محصول داشته باشد، ریسک این موضوع کاهش خواهد یافتتیم زیرساخت ریلایونیت به تازگی شروع به فعالیت کرده و مفتخریم که بتوانیم با بهره گیری از تکنولوژی های جدید و تجربه های متعدد، پایداری سیستم های نرم افزاری و سرعت توسعه تان را بهبود دهیم https://relyonit.ir </description>
                <category>صادق محبی</category>
                <author>صادق محبی</author>
                <pubDate>Fri, 30 Apr 2021 12:51:01 +0430</pubDate>
            </item>
                    <item>
                <title>قدمی دیگر با وصال از همکاری تا رشد</title>
                <link>https://virgool.io/vesal-co/%D9%82%D8%AF%D9%85%DB%8C-%D8%AF%DB%8C%DA%AF%D8%B1-%D8%A8%D8%A7-%D9%88%D8%B5%D8%A7%D9%84-%D8%A7%D8%B2-%D9%87%D9%85%DA%A9%D8%A7%D8%B1%DB%8C-%D8%AA%D8%A7-%D8%B1%D8%B4%D8%AF-xvi9rsez30me</link>
                <description>بنری که به مناسبت فاطمیه برای مایکت فرستادیم از و در صفحه ی اصلی موبایل و سایت مایکت نمایش داده شدسلامامشب بالاخره با هزار زحمت و سختی و کار تیمی هم افزا، توفیق انتشار نسخه ی جدیدی از اپلیکیشن وصال برایمان فراهم شد...اگر عکس بالا را باور نکردید، می توانید نگاهی به مستند زیر بیاندازید (قبلا هم به مناسبت های مختلف و با بنر های متفاوت در صفحه ی اصلی کافه بازار و مایکت قرار گرفتیم)در این نسخه (۱.۱۱.۱) علاوه بر کاهش حجم اپ و رفع برخی باگ های جزیی، دو تا اتفاق مهم افتاد:همکاری با سایت و اپلیکیشن هدیه صلوات Salawat.irچند وقت پیش و به طور اتفاقی یکی از بچه های تیم اپلیکیشنی خوب با رابط کاربری زیبایی رو پیدا کرد که اتفاقا موضوع ساده و جالبی هم داشت: نذر صلوات و صلوات شمار البته با امکانات متعددی مثل کمپین های هدیه صلوات و ختم ادعیه و قرآن و ...به سختی با سازندگان اپلیکیشن ارتباط برقرار کردیم و پیشنهاد دادیم که بتونیم از وب سرویس شون برای پیاده سازی بخش اصلی برنامه شون، هدیه صلوات برای سلامتی امام زمان (عج)، استفاده کنیم. نتیجه ی این همکاری موثر را می توانید در این نسخه اخیر از اپلیکیشن وصال ببینید (همراه به بهبود اساسی صفحه ی پروفایل کاربری)خوب شده به نظرم!...منو امید اینو ساختیمحذف تبلیغات از طریق خرید اشتراکبا توجه به اطلاع رسانی که سابقا در این پست (گزیده از سیستم اشتراکی در وصال) داشتیم، این بخش از برنامه پیاده سازی شده و امیدوارم بتوانیم مفید و موثر باشیم۵۰ درصد تخفیف به مناسبت افتتاح بخش اشتراکوصال، امسال جزو کاندیدا های ۱۲امین دوره جشنواره ی وب و موبایل ایران هست و خوشحال می شیم که با رای دادن تون، از طریق لینک زیر، از ما حمایت کنید:لینک رای به اپلیکیشن وصال در جشنواره وب و موبایل ایران</description>
                <category>صادق محبی</category>
                <author>صادق محبی</author>
                <pubDate>Mon, 03 Feb 2020 22:20:49 +0330</pubDate>
            </item>
                    <item>
                <title>مثل قاسم، با شهیدان...</title>
                <link>https://virgool.io/vesal-co/%D9%85%D8%AB%D9%84-%D9%82%D8%A7%D8%B3%D9%85-%D8%A8%D8%A7-%D8%B4%D9%87%DB%8C%D8%AF%D8%A7%D9%86-ghup6xhvmhyx</link>
                <description>امروز صبح زود با پیچیدن صدای گریه و ناله و ذاری و آه گفتن های رفیقان در خوابگاه دانشگاه، از خواب بیدار شدم...چیزی برای گفتن ندارم...الآن نه تحلیل اوضاع منطقه برام مهمه و نه هیچ چیز دیگه...همین که عکس این سردار شهید بزرگوار رو می بیبنم، به اندازه ی کافی تکان دهنده و گویاست، این که هدفمون مشترکه و مسیر هم الآن مشخص تر از همیشه شده:بال جبرئیل امین فرش محرم میکند دست سردار حسین شر اسرائیل را از این جهان کم می کند دست سردار حسینبال جبرئیل امین فرش محرم می کند - دودمه (حاج محمود کریمی)مثل قاسم، با شهیدان - رجز (حاج محمدرضا طاهری)</description>
                <category>صادق محبی</category>
                <author>صادق محبی</author>
                <pubDate>Fri, 03 Jan 2020 19:19:05 +0330</pubDate>
            </item>
                    <item>
                <title>گفتاری پیرامون تامین مالی جمعی مبتنی بر سهام و یک ایده</title>
                <link>https://virgool.io/@mohebbisadegh/%DA%A9%D9%88%D8%AA%D8%A7%D9%87-%D8%AF%D8%B1%D8%A8%D8%A7%D8%B1%D9%87-%DB%8C-%DA%A9%D8%AA%D8%A7%D8%A8-%D8%A7%D8%B5%D9%88%D9%84-%D8%AA%D8%A7%D9%85%DB%8C%D9%86-%D9%85%D8%A7%D9%84%DB%8C-%D8%AC%D9%85%D8%B9%DB%8C-%D9%88-%DB%8C%DA%A9-%D8%A7%DB%8C%D8%AF%D9%87-hzlh0qzg4hxf</link>
                <description>سلام...چندوقت پیش کتابی رو به نام اصول تامین مالی جمعی در ۳۰ دقیقه از یکی از دوستانم قرض گرفتم که بخوانم! (پ.ن.پ می خواستم کتابه رو صبح ها با قهوه نوش جان کنم!)از نقاط قوت این کتاب با توجه به ترجمه ای بودن، نثر روان و دلنشین اون بود و البته کاملا عملگرا با مثال های متعدد واقعی از خود نویسنده و سایت های مطرح کراودفاندینگ. به هر حال، پیشنهاد می کنم حتی اگر اندکی به کراودفاندیگ علاقه دارید و قبلا درباره اش چیز هایی شنیده اید، این کتاب را حتما بخوانید چون بعد از خواندن، با احتمال زیاد ممکنه پروژه ای را شروع کنید یا به فکرش بیافتید.از آنجایی که من دانشجوی اقتصاد این ممکت!!! هستم...لازم دیده بودم که یه مقدار در رابطه ی تأمین مالی شرکت ها و بورس و ابزار های مالی بدونم و تا جای ممکن فضای حاکم بر این ها رو تجربه کنم...اینجا بود که این ایده ی قدیمی من پخته تر و جذاب تر شد تا جایی که الآن می توانم برایتان تعریف کنم:و اما داستان یه ایده فینتکیپروژه هایی که توی پلتفرم های کراودفاندیگ تعریف می شوند یا خیریه هستند و یا ایده ای خلاقانه و کارآفرینی، در واقع این پروژه ها ممکنه برای صاحبان آن ها نفع مالی و عایدی داشته باشند یا نداشته باشند. در پروژه های کارآفرینی (دارای منفعت و عایدی مالی و معنوی) برای این که منفعت ایجاد شده بین مشارکت کننده (سرمایه گذار) و صاحب پروژه (کارآفرین) تقسیم بشه، پاداش هایی تعبیه شده تا انگیزه ی مشارکت کننده بالاتر بره. حال فرض کنید که به جای سیستم پاداش، سود یا زیان بین دو طرف معامله تقسیم بشه...دقت کنید که مشارکت کنندگان نمی توانند (یا به سختی امکان پذیر است) میزان مشارکت (برگه سهام مشارکت) رو بین همدیگه مبادله کنند به همین خاطر این مشارکت با دقت بالا و با احتیاط و در مبالغ کمی انجام می شه و ریسک انجام نشدن و شکست پروژه بین افراد زیادی پخش می شه (پس مشارکت کننده ی عمده و خیلی بزرگ نداریم مگر در موارد نادر! و البته همگی در سود و زیان پروژه شریک هستند)کارآفرین و صاحبان کسب و کار های کوچک (SMEs) باید کارهایی تقریبا مشابه تعریف کمپین تامین مالی جمعی را باید انجام دهد مگر این که صورت های مالی سود زیان ارائه دهد و سود مشارکت را پخش یا ضرر را محاسبه کند. مشارکت کننده و سرمایه گذار خرد هم اندکی دقیق تر و با حساب و کتاب مشارکت (سرمایه گذاری) می کند. این نوع سرمایه گذاری را با اندکی اغماض می توان تامین مالی جمعی مبتنی بر سهام نامید. در این زمینه، مدل های عملیات بانکداری مشارکت در سود و زیان یا PLS نیز می توانند مورد مطالعه و تطابق قرار بگیرند. نمونه ی موفق خارجی این نوع سرمایه گذاری، سایت https://www.enablefunding.com/  هست. سایت تامین مالی جمعی راتا نیز در این پست وبلاگ خودش این موضوع رو خیلی تمیز و راحت توضیح داده.به عنوان مثال این پروژه ی ایجاد شده در دونیت علاوه بر نقاط ضعف توضیحات ناکافی و نبود محتوای جذاب، فرضا اگر شما در منافع مالی این پروژه مشارکت داشتید و آینده ی خوبی را برایش پیش بینی می کردید، حمایت و سرمایه گذاری می کردید؟ و یا این که ارائه ی گزارش های مالی دقیق تر و شفاف منجر به مشارکت بیشتر و موفقیت این کمپین می شد یا خیر؟ به نظر من ایده ی جذابیه و می توانست موفق شود!ابهامات و سوالات احتمالی۱- با وجود بانک و صندوق های سرمایه گذاری گسترده و مطمئن، چرا باید توی این پلتفرم سرمایه گذاری کنیم و ضرر کنیم؟در این پلتفرم به خاطر تحمل ریسک ضرر، سود بیشتری می برید. البته برای افرادی که ریسک گریز هستند می توان سیستم هایی را طراحی کرد مثل بیمه کردن اصل سرمایه (ادبیات اقتصادی و اسلامی فراوان و مفصلی دارد) و یا محدودیت میزان سرمایه گذاری بر روی هر پروژه (مثلا نهایتا بشه ۵۰۰ هزار تومان روی هر پروژه سرمایه گذاری کرد) و راه کار های خلاقانه و فراوانی را می توان برای کاهش ریسک برشمرد.مدل های مبتنی بر وام دهی را با در نظر گرفتن حالت فرد-فرد یا فرد-سازمان این فعالیت، ربا و نادرست در نظر گرفتمدر اقتصاد مدرن می توانیم به راحتی کالایی شدن (بازار زدگی) بسیاری از روابط انسانی و نظامات اجتماعی را مشاهده کنیم...یکی از مثال های بارز این بازار زدگی، سپرده گذاری پس انداز ها صرفا برای دریافت سود با واسطه گری بانک هاست (با این ملاحظه که این سود در حالتی خوشبینانه حاصل عملیات های خلق پول درونزا و کاغذبازی و سرمایه گذاری در دارایی های ثابت نباشد! که متاسفانه تا بخش زیادی هست)در این پلتفرم، سرمایه گذار با توجه به موقیعت زندگی و جغرافیایی و انگیزه هایش، در پروژه هایی که خودش موفقیت آن ها را پیش بینی کرده مشارکت می کند و قدم به قدم گزارشات را دنبال می کند به گونه ای که انگار خودش به طور مستقیم درگیر در کار و پروژه هست...چه حسی و سودی را از این لذت بخش تر می توان پیدا کرد (با خنده ی کارآفرین بخند و با گریه ی او گریه کن ای بزرگوار!)۲- چرا باید مشارکت کنندگان و کارآفرینان به این پلتفرم اعتماد کنند؟ و از کجا معلوم که این پلتفرم را دور نزنند و مستقیم سرمایه گذاری نکنند؟شفافیت مالی و تعهد مستمر باید از اصول این پلتفرم باشد (مانند سایر سایت های کراودفاندینگ) و جهت ایجاد اعتماد عمومی بایستی همراه با کمپین های بازاریابی و تبلیغات شود. شروع کوچک تا بزرگ تر شدن این پلتفرم نیز می تواند در اعتماد سازی مؤثر باشد. البته نگرانی عدم استقبال و شکست ایده همواره محتمل است و باید با روش های اعتبار سنجی ناب ریسک استارتاپ را کاهش داد و در صورت لزوم چرخش Pivot کرد (مراجعه کنید به کتاب نوپای ناب و سایر کتاب ها مثل تست مامان و ...)در صورت اجرای امکانات تعبیه شده در پلتفرم و شفاف سازی ها و کاهش ریسک برای مشارکت کننده، دلیلی برای دور زدن پلتفرم باقی نمی ماند!۳- حتما یه مشکلی داره که تاحالا کسی توی ایران اجراش نکرده!اولا، من به شخصه در رابطه ی با جایگزین و رقیب ایرانی این پلتفرم خیلی جستجو نکردم. دوما، اپلیکیشن اوبر Uber هم مدت ها قبل از اسنپ و تپسی وجود داشت ولی کسی تو ایران اجراش نکرده بود! به هر حال در هر فعالیت استارتاپی و کارآفرینانه مسلما ممکنه به چالش های فراوانی برخورد کنیم، که می توان به موارد زیر اشاره کرد (منبع: یادداشت های خودم از کلاس بانکداری اسلامی دکتر عیوضلو در رابطه ی با چالش های اجرایی شدن عقد مشارکت در نظام بانکی ایران)نهاد های تخصصی مشاوره و تامین مالینهاد های رتبه بندی اعتبارینهاد های تخصصی نظارت بر پروژهخلا های قانونی و ناتوانی در اجرانهاد های مکمل و تسهیل کننده مثل Core Bankingالبته با توجه به انعطاف پذیری و چابکی و نوآورانه تر بودن سازمان بورس و اوراق بهادار، می توان به هموار بودن این مسیر امید داشت. سایت ایده هاب مطلبی رو با عنوان مجوز پلتفرم‌های سرمایه‌گذاری جمعی در سازمان بورس منتشر کرده که به طور خلاصه می گوید در سال ۱۳۹۷ این مجوز در سازمان بورس تصویب شده است (همین پارسال! چه قدر هیجان انگیز!!! قبول دارید؟)پس نوشت۱: از هرگونه درخواست همکاری و بحث و گفتگو و تحقیق  استقبال می شود! ایمیل من: mohebbi.sadegh@gmail.comپس نوشت۲: سیاهه ای که خواندید تا حدی فی البداهه نگاشته شده...مسلما علمای اهل فن بر بنده خرده خواهند گرفت و بسی خرسند خواهم شد که کامنتی بگذارید و یا به اشتراک، چرا که مایه ی فخر علم و علم آموز است!پس نوشت۳: اخیرا این بیت شعر رو خیلی دوست دارم:اگر با من نبودش هیچ میلی / چرا جام مرا بشکست لیلی... دعوت می کنم این نوا رو هم از سایت گلها گوش کنیدآپدیت ۲۰ آبان ۹۸: یک نمونه مشابه توسط یکی از دوستانم معرفی شد که این مدل رو تا حدی تونسته اجرا کنه و تا الآن به نظر می رسه که موفق بوده است. اسم این استارتاپ حلال فاند هستآپدیت ۹ آذر ۹۸: آقای دکتر بیدآباد در طرح تفصیلی بانکداری راستین، مبانی نظری و روش و سازوکار های اجرایی طرح PLS را همراه با مقالات و مکتوبات متعدد بحث کردند. (در سایت رسمی ایشان به طور رایگان در دسترس است البته...متاسفانه با استفاده از پروکسی!!!)</description>
                <category>صادق محبی</category>
                <author>صادق محبی</author>
                <pubDate>Thu, 24 Oct 2019 21:06:45 +0330</pubDate>
            </item>
                    <item>
                <title>به بهانه ی محرم</title>
                <link>https://virgool.io/@mohebbisadegh/%D8%A8%D9%87-%D8%A8%D9%87%D8%A7%D9%86%D9%87-%DB%8C-%D9%85%D8%AD%D8%B1%D9%85-%DB%8C%D8%A7-%D8%AF%D8%A7%D8%B3%D8%AA%D8%A7%D9%86-%D9%BE%DB%8C%D9%88%D8%B3%D8%AA%D9%86-%D9%85%D9%86-%D8%A8%D9%87-%D8%AA%DB%8C%D9%85-%D9%88%D8%B5%D8%A7%D9%84-rmg9az557wt0</link>
                <description>اسفند ۹۷ بود که من به هر دلیلی که خیلی هم مهم نیست از فانزی (چندپر) پس از حدود دو سال با تمام فراز و فرود ها اومدم بیرون (برخی از دلایلم رو در این پست نوشتم) به هر حال به من خیلی خوش گذشت و کلی تجربه جدید کسب کردم، از همینجا براشون آرزوی موفقیت می کنم و امیدوارم موفق بشن.مدتی توی فکرم بود که بعد از ۳ سال فعالیت نصفه و نیمه در دو استارتاپ در حوزه ی هنر و گردشگری یه مقدار به درون خودم نزدیک بشم. حدود بهمن ۹۷ بود که یکی از دوستانم پیشنهاد داد که بیا توی وصال و این که به لحاظ فنی و نرم افزاری مدتی بود که مشکل داشتن و کلی کاربر ناراضی (از حدود ۶۰۰۰ کاربر فعال رسیده بود به ۱۰۰۰ تا) ... خب من اون موقع گفتم که مشغول به کار هستم ولی مدتی بعدش ، بهشون خبر دادم که جلسه ای در یه کافه بذاریم و صحبت کنیم.خلاصه این که پروژه وصال به شرکتی داده شده بود و اون شرکت هم با تمام احترام، پس از پایان زمان پشتیبانی،‌ مشکلات زیادی رو در اپلیکیشن و پنل رها کرده بودند. اپلیکیشن در محرم ۹۷ در دسترس بود و بعدش داون شد. و من هم به عنوان ناجی و فرشته ی نجات وصال باید وارد می شدم تا این مشکلات برطرف بشه و پیشرفت کنهبه لحاظ مالی، با ۲۰ درصد شراکت تیم محصول (۱۰ درصد قطعی بنده) و بحث های متعدد در رابطه ی با اندک پرداختی ماهانه کار رو شروع کردیم. مدتی گذشت تا خیلی از باگ ها برطرف بشه و سرور php lumen بیاد بالا، دیزاین اپ رو تغییر دادیم، من Vuejs یاد گرفتم و یه سایت ساده برای خود وصال زدم، بخش فروشگاه رو راه اندازی کردیم، با تغییر و بهینه سازی اندک بنر های تبلیغاتی اپلیکیشن که اون درآمد اندکشون رو افزایش می داد ذوق کردیم و از کرش ها و باگ های مختلفی که پیش میومد، ناراحت و نگران می شدیمخیلی ها اومدن و رفتن و الآن که دارم باهاتون صحبت می کنم ، سه نفر تیم اصلی هستیم و در کل شرکت ۵ نفر مشغولیم.توی این مدت با خیلی از مطرح های اکوسیستم برای منتورینگ و مشاوره، صحبت کردیم و با همه ی خوب و بد شون، خیلی برای خودمون فایده داشت.آخرش می خواستم بگم که ما در حال تلاش برای بهتر کردن وصال هستیم و تنها دلخوشی ما ، رضایت و دعای کسایی هست که از این محصول استفاده می کنن... http://vesal.co/ پس نوشت۱: تا حالا این طوری مذهبی طور! ، توی ویرگول ننوشته بودمپس نوشت۲: امیدوارم یک سال آینده که این پست رو بخونم، وصال اینقدر بزرگ و گسترده شده باشه که خیلی دغدغه های ساده و پیش و پا افتاده ی الآنم رو نداشته باشم</description>
                <category>صادق محبی</category>
                <author>صادق محبی</author>
                <pubDate>Sat, 31 Aug 2019 19:21:42 +0430</pubDate>
            </item>
                    <item>
                <title>هفت عادت برنامه نویسان مؤثر</title>
                <link>https://virgool.io/enline/%D9%87%D9%81%D8%AA-%D8%B9%D8%A7%D8%AF%D8%AA-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%D8%A7%D9%86-%D9%85%D8%A4%D8%AB%D8%B1-zdzp2q5hxovi</link>
                <description>بازم این vscodeبرنامه نویسا وقت زیادی رو صرف یادگرفتن مهارت ها و کامل کردن رزومه برای مصاحبه های شغلی می کنند تا این که در آخر توی یکی از این استارتاپ ها یا شرکت های نرم افزاری استخدام شوند ولی غافل از این که این لیست بلند و بالای مهارت های درخشان در رزومه تان، در شرایط واقعی کاری، اثربخش و کافی نیست.حال ما می خواهیم با معرفی و توجه به این هفت مهارت (قانون) ، قدم های محکم تر و پرسرعت تری را در راه پیشرفت شغلی و حرفه ای برداریم (بر گرفته از ex-Google TechLead)این ها هفت عادت برنامه نویسان مؤثر است:۱- یادبگیرید که چگونه کد های دیگران را بخوانیدمن از خوندن کد های دیگران متنفرم!هر برنامه نویسی (به غیر از شما) کد های فوق العاده وحشتناکی می نویسد...No-opبه همین خاطر، مهارت خواندن کد های سایر برنامه نویسان مزیت های فراوانی دارد. مهم نیست که برنامه نویس قبلی چه قدر بد و مبتدی و افتضاح کد زده و یا این که چه قدر تمیز و حرفه ای، این وظیفه و کار شماست که بتوانید از پس این کار بر بیایید حتی اگر کد های قبلی یک سال و بیشتر قدمت داشته باشد. پس غر زدن و ترس از کد های دست دوم ممنوع!این مهارت در دو جهت به شما کمک می کند: اول این که مهارت خواندن کد های دیگران باعث یادگیری الگو های کد نویسی بد برای کار های بعدی تان خواهد شد (ادب از که آموختی...گفت از بی ادبان!)؛ دومی و از همه مهم تر، یادگرفتن نوعی کد نویسی که قابل فهم تر و خواناتر و حرفه ای تر است. (یکی از بهترین تمرینات در این زمینه، مراجعه به منابع متن باز و سعی در فهم و بهبود آن هاست)شما باید مطمئن شوید که به اندازه ی کافی کد های دیگران را خوانده اید تا به سطحی برسید که کیفیت و نوع کد نویسی برنامه نویسان دیگر را با نگاهی کلی به کد ها تشخیص دهید.از طرفی باید به نکات و قوانین تمیز کد نویسی clean code و کامنت گذاری توجه کنید. این در واقع راهی هست برای قابل فهم تر شدن کد ها و به رخ کشیدن مهارت هایتان برای سایر برنامه نویس ها (به شرطی که برنامه نویس مقابل باید مهارت کدخوانی را کسب کرده باشد)این قدر باید تمیز و آسان کد نویسی کنید که هیچ داکیومنتیشنی لازم نداشته باشد. در حقیقت اگر شما برنامه نویس خوبی باشید نباید هیچ جایی از کد هایتان را داکیومنت کنید. این صرفا باعث هدر دادن وقت و کاهش سرعت تان در کدنویسی می شود.قابلیت خواندن کد های سایر برنامه نویس ها، این توانایی را به شما می دهد که هر وقت لازم شد، بتوانید بخش هایی از کد را بدون آسیب به سایر قسمت های نرم افزار آپدیت کنید حتی اگر تجربه ی کافی در framework یا زبان برنامه نویسی مورد نظر نداشته باشید. لازمه ی این سطح از مهارت ، درک کامل کد های منبع و فهمی نسبی از زبان برنامه نویسی مورد استفاده ی آن است.توانایی خواندن کد های دیگران، شما را به شخصی کلیدی و ارزشمند تبدیل می کند، چرا که شما می توانید در هر شرایطی به سمت بهبود سیستم حرکت کنید در حالی که بقیه (کسانی که این مهارت را ندارند) این پیشرفت را کار تجربه نمی کنند.۲- حس ششم در تشخیص پروژه های بدمهارت های وقت تلف کن زیادی برای یادگرفتن وجود دارد ...یکی از این مهارت ها که احساس می کنم از همه شان مهم تر است، فهم و تشخیص پروژه های بد و طاقت فرسا از بین پروژه های خوب است.شرکت ها به اندازه ی کافی پروژه ی ناتمام و به درد نخور برای دنبال کردن دارند، چه به لحاظ مالی و کسب و کاری (به خصوص برای خودتان) و چه به لحاظ ساختار های مدیریتی غلط شرکت، به هر حال باید از این پروژه ها فرار کنید و بتوانید به خوبی و زیرکانه آن ها را تشخیص دهید. البته به این معنی نیست که راه ورود ایده های خلاقانه و جذاب رو در ذهن خودتون ببندید.۳- از جلسات متعدد پرهیز کنیدشما چه توسعه دهنده ی نرم افزار باشید و چه تحلیل گر داده، جلسات برای شما ضروریست چرا که به فهم صحیح و مشترکی از کاربر نهایی ، مدیریت پروژه و ... برسید. و البته در این بین ، یک علت و تمایل دیگری نیز برای برگزاری جلسات از طرف برنامه نویسان وجود دارد: به عقب انداختن و پر کردن برنامه. به خاطر همین، عدم شرکت در جلسات بی مورد و بی فایده اهمیت فراوانی دارد. شاید قشنگ تر و محترمانه تر بشود گفت که باید شرکت در جلسات را مدیریت کنید. هدف شما باید از شرکت در جلسات این باشد که به هم تیمی هایتان کمک کنید تا همگی یک قدم به جلو پیشرفت کنید و از رسیدن به این هدف قبل از شرکت در جلسه مطمئن شوید.ساده ترین روش این است که زمان جلسات روزانه را محدود کنید (مثلا دو ساعت) و اگر جلسه ای مفید باشد می توانید آن را در روز های بعدی نیز تکرار کنید و زمان را برای برنامه نویسی کردن روزانه باز بگذاریدیکی دیگر از راه های جلوگیری از جلسات بی مورد، تعهد به پایان تسک قبل از برگزاری جلسه است. علاوه بر آرامش و تمرکز بیشتری که در جلسه حاکم خواهد شد، کسانی که تسک های خود رو انجام داده و خودشان را ثابت کرده اند، در شرکت (یا سازمان) دوست داشتنی تر و پذیرفته تر هستند و هیچ کسی نمی تواند ایرادی از شما بگیرد.زمان برای هر کسی اهمیت زیادی دارد چرا که تنها زمانی کار کردن به نتیجه می رسد که تمرکز کافی و عدم حواس پرتی در صحبت با همکاران در محیط کار وجود داشته باشد. بله البته که بسیاری از مشکلات در زمان همکاری و هم افزایی تیمی با دیگران حل شده است ولی حل یک باگ در نهایت نیازمند دست به کیبورد شدن و کد زدن شماست بدون توقف و حواس پرتی۴- گیتهاب Githubبعضیا از موقعی که به دنیا می آیند، استفاده از گیت را شروع می کنند و بعضی دیگر اولین باری که از گیت استفاده می کنند موقعی است که در شرکتی استخدام می شوند و عمدتا نمی فهمند که با هر کامند چه می گذرد (به خاطر همین cheat sheet ها محبوب هستند)مهم نیست که در شرکت و یا تیم تان از چه سورس کنترلی استفاده می کنید،‌ این سیستم ها اگر به درستی استفاده شوند مفید و یا در صورت استفاده ی نادرست مضر هستند. (مثل چاقو هم خوبه و هم بد) زمان صرف شده برای commit و push کردن ساده کجا و زمان طولانی حل کردن confilict ها و branch های پیچیده و fork های در هم بر هم کجا! که هیچ جذابیت و چالشی هم ندارنداگر می خواهید زندگی راحت تری داشته باشید، گیت را فرا بگیرید و همواره cheat sheet آن را نزد خود داشته باشید۵- نوشتن کد های ساده ی قابل نگه دارییک برنامه نویس جوان بااستعداد همواره باید تلاش کند تا از هر آن چیزی که فراگرفته را در یک راه حل بهره گیرد. این کار مستلزم فهم عمیق و علاقه به برنامه نویسی شیء گرا، ساختمان داده، دیزاین پترن ها و سایر تکنولوژی های جدید مرتبط در هر خط کد است. زمانی پیچیدگی های غیر ضروری در کد ظهور پیدا می کنند که به یک دیزاین پترن یا اصول فنی خاصی که سابقا استفاده می کرده اید، چسبیده اید و آن را رها نمی کنید.تعادلی بین مفهموم طراحی پیچیده و کد ساده وجود دارد. دیزاین پترن ها و شیء گرایی برای ساده سازی کد ها فراهم شده اند،‌ به هر حال بار ها و بار ها استفاده ی در هم و پیچیده از این اصول بدون در نظر گرفتن best practice ها، باعث صرف زمان بیشتر برای دیباگ و خواندن کد خواهد شد.۶- نه گفتن و اولویت بندیاین مهارت در هر نقش و جاهگاهی به شدت تاثیر گذار و موثر است، چه شما تحلیل گر مالی باشید و چه برنامه نویس. اما به طور کلی نقش های فنی و مهندسی ، کسانی هستند که با همه روزه با درخواست های زیادی بیش از حد برنامه ریزی شده، مواجه می شوند. خروجی گرفتن از داده ها، داشبورد مدیریتی، برنامه ریزی جدید برای تحلیل و استخراج داده های موجود و ... از این قبیل است.همین الآن، اولویت بندی و نه گفتن را به عنوان دو مهارت جداگانه و در عین حال در هم تنیده در نظر بگیرید. اولویت بندی یعنی شما فقط زمانتان را در جایی که بیشترین بهره وری و عایدی را دارد ، صرف می کنید، در حالی که با نه گفتن ، از کار هایی که می تواند توسط دیگران انجام شود، خودداری می کنید. این دو همگام پشت سر هم باید در هر موقعیتی عادت هر روز شما باشد.این مهارت بسیار کلیدی و کسب آن دشوار است به خصوص هنگامی که با هجمه ای از درخواست ها مواجه می شوید پس سعی کنید از آن دسته از افرادی نباشید که همه کاره و هیچ کاره هستند (دو برابر کار در برابر بازده نصف افراد معمولی)۷- تفکر طراحی عملیاتی Operational Design Thinkingتفکر در نحوه ی تعامل با ماژول و کدی که می نویسید، تفکر طراحی عملیاتی، یکی از مهارت هایی است که در مصاحبه های شغلی مطرح نمی شود و دانشگاه آن را یاد نمی گیرید.در حقیقت، با گفتن عدم مهارت در تفکر طراحی عملیاتی،‌به طور محترمانه می توان گفت که مدرک کدنویسی شما ساختگی است.برای مثال، اگر تفکر طراحی عملیاتی نداشته باشید، هر گونه تغییر کوچک در برنامه که با تمامی اجزای آن در تعامل و ارتباط است غیر ممکن و بسیار طاقت فرسا خواهد بود حتی اگر تغییرtype یک فیلد دیتابیس و یا تغییر در یک object باشد.این مهارت، شامل فکر کردن و طراحی مسیر و نوع تعامل ماژول ها و اجزا قبل از شروع به کد نویسی نیز می شود.برای نمونه، هنگامی که شما در حال توسعه ی یک مایکروسرویس یا ماژول جدید هستید، صرف وقت برای فکر کردن به جنبه های عملیاتی آنچه که می خواهید بسازید اهمیت فراوانی دارد. به این فکر کنید که استفاده از آن به چه روشی صحیح و به چه روشی نادرست است و کدام پارامتر ها برای کار کردن آن لازم است و ...خیلی خلاصه...کد ها و برنامه نویسی خود جزئی از مشکل هستند. ساخت نرم افزاری که کار می کند خیلی آسان است ولی راه های متعددی برای توسعه ی همان نرم افزار وجود دارد که اشتباه هستند. اگر در شرکت ها و تیم ها، صحبت کردن در رابطه ی نحوه ی کد زدن و روش استفاده از ماژول های توسعه یافته سخت باشد، برنامه نویسان آینده با مشکلات و محدودیت های فراوانی مواجه خواهند شد...(که آه جان سوزشان گریبان ما را خواهد گرفت)پس نوشت۱: این مطلب ترجمه ای آزاد از این مقاله ی منتشر شده در مدیوم استپس نوشت۲: من خیلی وقتا اینجوری می شم! شما چطور؟؟Dev Humourمنبع عکس: ? Developer Economics @developereconomics</description>
                <category>صادق محبی</category>
                <author>صادق محبی</author>
                <pubDate>Fri, 16 Aug 2019 15:33:12 +0430</pubDate>
            </item>
            </channel>
</rss>