https://virgool.io/feed/@kaveh خدا هم که باشی، یک سری هستن که قبولت ندارن! (http://kavehahmadi.com) fa 2026-06-07 11:55:17 https://files.virgool.io/upload/users/5291/avatar/WVVlEo.jpeg?height=120&width=120 https://virgool.io/@kaveh https://virgool.io/@kaveh/automatic-authentication-in-postman-wzlrj2ek3iif همانطور که می‌دانید، برای استفاده از درخواست‌های API یا API Requests که نیازمند مجوز (Authorization) بر پایه‌ی توکن هستند، توکنِ مربوطه باید همزمان با درخواست، ارسال شود. این توکن باید از طریق احراز هویت کاربر دریافت شود، سپس می‌توان از توکنِ ایجاد شده در سایر درخواست‌ها استفاده کرد. بارها دیده‌ام که افراد در نقش‌های مختلف در تیم توسعه، اعم از برنامه‌نویس بک‌اند یا فرانت‌اند یا تسترها یا... هنگام بکارگیری این APIها در Postman، درگیری زیادی در احراز هویت، دریافت توکن و استفاده از آن دارند، به نحوی که زمان زیادی صرف احراز هویت با استفاده از نام کاربری و کلمه عبور، دریافت توکن و استفاده از آن در فراخوانی سایر درخواست‌ها می‌شود.در Postman قابلیت‌هایی وجود دارد که با استفاده از آنها می‌توان این عمل را تسهیل و حتی خودکار کرد. در این نوشته ابتدا به نحوه‌ی احراز هویت، دریافت مجوز و استفاده از آن در Postman می‌پردازیم، سپس سعی می‌کنیم با استفاده از قابلیت‌های موجود، روند را تسهیل کنیم!احراز هویت بر پایه‌ی توکن در Postmanابتدا به این نکته اشاره کنم که «احراز هویت بر پایه‌ی توکن» احتملا جمله‌ی دقیقی نباشد. آنچه مبتنی بر توکن است، مجوزها (Authorization) است و نه احراز هویت (Authentication). به شکل دقیق‌تر، هنگام احراز هویت کاربر با استفاده از نام کاربری و کلمه‌ی عبور، یک توکن ایجاد می‌شود که مجوز دسترسی ما به سایر درخواست‌ها (API requests) است. با این تفاسیر، ابتدا نیاز است با ارسال نام کاربری و کلمه عبور به endpoint مربوطه و احراز هویت کاربر، توکن دریافت شود تا در فراخوانی سایر درخواست‌ها بتوان از آن استفاده کرد. برای این منظور مراحل زیر در Postman اتفاق خواهد افتاد:احراز هویت کاربر و دریافت توکنهمانطور که ملاحظه می‌کنید، نام کاربری و کلمه عبور با فرمت JSON به endpoint مربوط به احراز هویت (در اینجا login) ارسال شده و access token و refresh token به عنوان پاسخ دریافت شده است.با در اختیار داشتن توکن (access token)، می‌توان نسبت به استفاده از آن برای مشخص کردن مجوز دسترسی در سایر درخواست‌ها اقدام کرد. بنابراین در درخواست‌های نیازمند مجوز، توکن دریافتی در مرحله‌ی قبل باید به همراه درخواست‌ها ارسال شود. این مورد در تب Authorization، و برحسب نوع توکن (bearer، JWT یا...) مشخص می‌شود.اضافه کردن توکن دسترسی به یک درخواستبا توجه به اینکه توکن‌های دریافتی منقضی می‌شوند، زمان زیادی برای دریافت توکن و استفاده از آن در درخواست‌ها مورد نیاز خواهد بود. بهتر است به نحوی این فرایند تسهیل شود تا تمرکز هریک از اعضای تیم که قرار است از این APIها در Postman استفاده کنند، به جای دریافت و کپی کردن توکن هنگام ارسال یک درخواست به کار اصلی خود معطوف شود! در ادامه توضیح می‌دهم به چه صورت!قابلیت‌های Postman برای تسهیل امور روزمره!در Postman شما می‌تواند مجموعه‌های (collection) متفاوتی از درخواست‌هایی که نیاز به فراخوانی آنها در پروژه‌ی خود دارید را ذخیره کنید. این امر فراخوانی درخواست‌ها را تسهیل می‌کند و با یکبار ذخیره‌ی endpointها، متدها و اطلاعات ارسالی (در صورت نیاز) می‌توانید بارها آنها را فراخوانی کنید. علاوه بر تعریف مجموعه‌ها، شما می‌توانید از پوشه‌بندی درخواست‌ها نیز استفاده کنید. یک مجموعه (collection) به همراه چند پوشه برای دسته‌بندی درخواست‌ها تعریف شده استشما درخواست‌های خود را در قالب مجموعه‌ها ذخیره کرده‌اید اما فراخوانی درخواست‌ها ممکن است بسته به محیطی که در حال فراخوانی درخواست هستید، دارای تنظیمات متفاوتی باشد (محیط توسعه، تست، عملیاتی). مثلا محیط توسعه شما در مسیر http://127.0.0.1:5000 است اما محیط تست شما http://testserver:8080 است. یا مثلا نام کاربری و کلمه عبوری که در محیط‌های مخلتف مورد استفاده قرار می‌گیرد متفاوت است. منطقی نیست شما تمامی درخواست‌ها را برای محیط‌های متفاوت بازتعریف کنید. Postman فکر اینجا را نیز کرده و به شما این امکان را می‌دهد تا درخواست‌های خود را در محیط‌های متفاوتی اجرا کنید! در یک محیط شما می‌توانید متغیرهایی که معرف ویژگی‌های خاص محیط شما هستند را (مانند آدرس سرور، نام‌های کاربر، کلمه‌های عبور و...) را تعریف کنید.در اینجا دو محیط تعریف شده و در هر محیط می‌توان متغیرهای مورد نیاز مانند آدرس سرور یا نام کاربری و... را تعریف کردپس از تعریف یک محیط، شما می‌توانید از متغیرهایی که معرف هر محیط هستند در درخواست‌های خود استفاده کنید. مثلا به جای استفاده‌ی صریح از آدرس سرور از متغیری که برای این منظور تعریف شده است استفاده می‌کنیم:استفاده از یک متغیر محیطی به جای آدرس صریح در یک درخواستبه این ترتیب برای اجرای یک درخواست روی محیط‌های متفاوت، صرفا کافی است محیط مورد نظر خود را انتخاب کنید تا درخواست با تنظیمات مورد نظر شما اجرا شود!برای نام کاربری و کلمه عبور نیز به همین ترتیب، امکان استفاده از متغیرهای تعریف شده در محیط میسر است:نام کاربری و کلمه عبور در متغیرهای محیطی تعریف شده است و هنگام ارسال درخواست احراز هویت، مقادیر این متغیرها ارسال می‌شوند. به این ترتیب هنگام ارسال یک درخواست در محیط‌های مختلف، نیاز به تغییر نام کاربر و کلمه‌ی عبور در درخواست نیست.استفاده خودکار از توکن‌هاتا اینجای کار دیدیم چگونه احراز هویت مبتنی بر توکن را در Postman انجام دهیم و چگونه با استفاده از قابلیت‌هایی که Postman در اختیار ما می‌گذارد، امور روزمره را تسهیل کنیم! حال می‌خواهیم با استفاده از سایر امکانات Postman، کاری کنیم که نیازی نباشد بعد از هربار احراز هویت و دریافت توکن، آنرا به Authorization درخواست‌ها اضافه کنیم!برای این منظور می‌توان از اسکریپت‌های تست Postman استفاده کرد. این تست‌ها با جاوااسکریپت نوشته می‌شوند و بعد از اجرای درخواست و دریافت پاسخ اجرا می‌شوند. تست‌ها کارکردی فراتر از استفاده‌ای که ما می‌خواهیم از آن بکنیم دارد، اما در اینجا می‌خواهیم هنگام احراز هویت، توکن دریافتی را در یک متغیر محیطی ذخیره کنیم تا هنگام ارسال درخواست‌ها بتوانیم از آن متغیر استفاده کنیم. بنابراین یک تست به صورت زیر هنگام احراز هویت اجرا می‌کنیم:در این تست، یک متغیر با نام auth_token را با توکن دریافتی از احراز هویت مقداردهی کردیم. حال می‌توانیم در درخواست‌هایی که نیاز به مجوز دارند، از آن متغیر استفاده کنیم:توجه شود که در مجموعه‌ها امکان ارث‌بری در مجوزها وجود دارد. لذا می‌توان متغیر را در سطح مجموعه به کار برد و برای درخواست‌ها، مقدار Inherit auth from parent را انتخاب کرد!خودکار کردن احراز هویت در Postmanتا اینجا دیدیم که چگونه می‌توان با استفاده از یک تست و استفاده از متغیرهای محیطی، کاری کرد که بعد از احراز هویت کاربر، نیازی به کپی کردن توکن در سایر درخواست‌ها نباشد! حالا می‌خواهیم پا را فراتر بگذاریم: می‌خواهیم هنگام ارسال یک درخواست، در صورتی که توکنی وجود نداشته باشد یا منقضی شده باشد، عمل احراز هویت و دریافت و استفاده از آن به شکل خودکار انجام شود! به این تریتب دیگر نیازی به احراز هویت به عنوان پیش‌شرط ارسال درخواست‌هایی که نیازمند مجوز هستند نخواهیم داشت!در Postman امکاناتی وجود دارد که این موضوع را برای ما ممکن می‌کند: Pre-request Scripts! این اسکریپت برخلاف تست‌ها که بعد از ارسال درخواست و دریافت پاسخ اجرا می‌شدند، پیش از ارسال درخواست اجرا می‌شوند. با این تفاسیر کافی است اسکریپتی بنویسیم که چک کند در صورتی که توکن معتبری وجود ندارد، احراز هویت انجام و توکن دریافت شود سپس درخواست ارسال شود. یک نمونه اسکریپت که می‌تواند برای این منظور استفاده شود به صورت زیر است:pm.sendRequest({ url: pm.environment.get(&quoturl&quot) + '/check', method: 'GET', header: { 'Accept': 'application/json', 'Authorization': 'Bearer ' + pm.environment.get('auth_token') }, }, function (error, response) { if(!error){ if (response.code === 401) { pm.sendRequest({ url: pm.environment.get(&quoturl&quot) + '/login', method: 'POST', header: { 'Accept': 'application/json', 'Content-Type': 'application/json' }, body: { mode: 'raw', raw: JSON.stringify({ username: pm.environment.get(&quotusername&quot), password: pm.environment.get(&quotpassword&quot) }) } }, function (error, response) { if(!error) { var jsonData = response.json(); pm.environment.set(&quotauth_token&quot, jsonData.access_token); } else { console.log('LOGIN Err: ' + error); } }); } } else { console.log('CHECK Err: ' + error); } });در این اسکریپت، ابتدا یک درخواست به یک endpoint با نام check ارسال می‌شود که وظیفه‌ی آن بررسی معتبر بودن توکن است. در صورتیکه توکن معتبر وجود نداشته باشد، یک درخواست به endpoint با نام login ارسال می‌شود که وظیفه‌ی آن احراز هویت کاربر با نام کاربر و کلمه عبور ارسالی و دریافت توکن و ذخیره‌ی آن در متغیر محلی مربوطه است.این اسکریپت می‌تواند به عنوان یک Pre-request Scripts برای یک درخواست نوشته شود و یا روی یک مجموعه یا فولدرهای آن. طبیعتا درخواست‌های ذیل یک مجموعه یا فولدر، Pre-request Scripts را به ارث خواهند برد.توجه شود این اسکریپت صرفا یک اسکریپت نمونه است و ممکن است شما endpointی مانند check برای بررسی اعتبار یک توکن نداشته در اختیار نداشته باشید و نیاز باشد به روش‌های دیگری وجود یک توکن معتبر را بررسی کنید. همچنین توجه کنید این روش منجر به افزایش تعداد درخواست‌های ارسالی شما می‌شود (به دلیل فراخوانی check) اما به تجربه دیده‌ام در محیط‌های توسعه و تست، این روش در نهایت باعث افزایش عملکرد و بهبود تجربه کاری می‌شود.به این ترتیب دیگر نیاز به انجام احراز هویت نخواهد بود و با فراخوانی هر درخواست، احراز هویت (در صورت نیاز) مجددا انجام خواهد شد. کاوه احمدی کاوه احمدی Tue, 17 May 2022 13:20:03 +0430 https://virgool.io/@kaveh/%D8%B3%D9%87%D8%A7%D9%85%D9%90-%D8%A8%D8%B1%D8%A7%D8%A8%D8%B1%D9%90-%D8%AA%DB%8C%D9%85-%D9%85%D9%88%D8%B3%D8%B3-%D8%B4%D9%85%D8%A7-%D8%B1%D9%88-%D8%B1%D8%B3%D8%AA%DA%AF%D8%A7%D8%B1-%D9%85%DB%8C-%DA%A9%D9%86%D9%87-kfsgnnhb4xuk مدتیه دنبال الگویی مناسب برای تعیین نحوه‌ی تقسیم سهام بین تیم موسس یک استارتاپ هستم. بعد از بررسی‌هایی که انجام دادم و مطالعات و تجربیاتی که داشتم، به این نتیجه رسیدم که سهام باید به شکل برابر بین تیم موسس تقسیم بشه!دلیل این صحبت، فرار از انجام صحبت‌های سخت و محاسبات پیچیده برای تعیین سهم هر شحص براساس آورده‌ش نیست، بلکه به این نتیجه رسیدم که این حرف مایکل سیبل که «اگر شما کس یا کسانی رو به عنوان هم بنیانگذار انتخاب کردید که حاضر نیستید سهم برابر بهشون بدید، احتمالا شریک اشتباهی رو انتخاب کردید»، حرف درستیه!اگر هم بنیانگذاری انتخاب کردید که بهش اعتماد کافی ندارید، از نظر توانایی مکمل شما نیست، به اندازه‌ی شما نمی‌تونه زمان و انرژی بذاره یا در مورد توانایی‌هاش مردد هستید، به نظر می‌رسه که شخص مناسبی رو برای شروع کار پیدا نکردید! اگر هم سرمایه‌ی مرحله‌ی کشت ایده (seed funding) توسط تیم موسس داره تامین می‌شه و سرمایه‌های برابر نمی‌گذارید، با توجه به اینکه این سرمایه عمدتا سرمایه‌ی خیلی زیادی نیست، باز هم سهام‌ها می‌تونه نزدیک به برابر باقی بمونه! از طرف دیگه روش‌هایی برای تعیین سهم هر کس در تیم موسس براساس یک سری فاکتورها و نیازمندی‌ها معرفی شده، اما به نظرم وزن دادن به این فاکتورها و تعیین نقش هریک از هم بنیانگذارن در روزهای اول، شدنی نیست و هر محاسبه‌ای که انجام بشه، به نوعی قمارگونه است. شخصا به این نتیجه رسیدم که روی انتخاب شریکی که اندازه‌ی خودم بهش اطمینان دارم قمار کنم به جای قمار کردن روی اعداد و ارقام! کاوه احمدی کاوه احمدی Mon, 18 Apr 2022 12:58:13 +0430 https://virgool.io/@kaveh/%D8%AF%D8%B1-%D9%BE%D9%86%D8%AC-%D8%B3%D8%A7%D9%84-%D8%A2%DB%8C%D9%86%D8%AF%D9%87-%D8%AE%D9%88%D8%AF%D8%AA%D8%A7%D9%86-%D8%B1%D8%A7-%DA%A9%D8%AC%D8%A7-%D9%85%DB%8C-%D8%A8%DB%8C%D9%86%DB%8C%D8%AF-sbhj78cj4jox در پنج سال آینده خودتان را کجا می‌بینید؟سوالی به ظاهر کلیشه‌ای که اخیرا هم زیاد می‌بینیم که پرسیده شدن آن مورد انتقاد قرار می‌گیرد و حتی به تمسخر گرفته می‌شود. اما به نظرم این سوال، یکی از مهمترین سوال‌هایی است که قبل از شروع یک همکاری باید در مورد آن صحبت شود و در مورد آن بین کارجو و کارفرما توافق صورت گیرد. به نظرم دلیل اینکه این سوال به یک سوال کلیشه‌ای در مصاحبه‌ها تبدیل شده این است که یا توسط شخص درستی پرسیده نمی‌شود و یا بعد از پاسخ کارجو، مصاحبه‌کننده از این سوال می‌گذرد و پیگیری لازم را انجام نمی‌دهد و بنابراین به نتیجه‌ای که باید هم نمی‌رسند.چرا این سوال مهم است؟این سوال از این جهت بسیار اهمیت دارد - و شاید باید یکی از مهترین سوال‌های یک مصاحبه باشد- که تعیین می‌کند که مسیر توسعه حرفه‌ای (و فردی) کارجو چقدر با شرح شغلی و مسیر پیشرفت در آن شرکت همخوانی دارد. و آیا کارجو در راستای مسیر توسعه حرفه‌ای خود می‌تواند در آن شرکت پیشرفت کند و یک وضعیت برد-برد بین انتظارات و نیازمندی‌های کارفرما و این مسیر وجود دارد یا خیر؟ فرض کنید در شرکتی که مدیریت آن به شکل ملوک الطوایفی مشخص می‌شود، یک برنامه‌نویس ارشد که در مسیر حرفه‌ای خود می‌خواهد معمار و مدیر فنی شود، برای مصاحبه می‌آید. آیا با پرسیده شدن سوال «در پنج سال آینده خودتان را کجا می‌بینید؟» و پاسخ کارجو، مصاحبه نباید متوقف شود؟ چرا که کارجو هیچگاه در چنین شرکتی نخواهد توانست در راستای مسیر حرفه‌ای مورد نظرش گام بردارد و همواره یک برنامه‌نویس ارشد باقی خواهد ماند! به راستی چه کسی از فالوآپ نشدن درست این پرسش در مصاحبه متضرر می‌شود؟ کارفرما یا کارجو؟کارجو باید بیشتر از کارفرما پیگیر این سوال باشد!برعکس جو حاکم، به نظرم کارجو باید بیشتر از کارفرما به دنبال پرسیده شدن این سوال و اطمینان از پیگیری‌های بعدی آن در مصاحبه باشد. فاجعه آنکه در راهنماهایی که برای پاسخ به این پرسش وجود دارد، نمایش اشتیاق برای اخذ شغل و دادن اطمینان از همکاری طولانی توصیه شده است! حال آنکه به نظرم یک همکاری یکساله با شخصی که بعد از یکسال در موقعیت برد-برد برای ادامه مسیر حرفه‌ای خود شرکت را ترک می‌کند (و این موضوع از ابتدا برای دو طرف روشن و شفاف بوده)، بسیار بهتر از همکاری طولانی با کسی است که نه خود در شرکت ما به آنچه می‌خواهد خواهد رسید و نه کمکی در راستای رسیدن ما به اهدافمان خواهد کرد است! کاوه احمدی کاوه احمدی Wed, 13 Apr 2022 13:10:12 +0430 https://virgool.io/@kaveh/%D9%85%D8%B4%D8%AA%D8%B1%DB%8C-%D8%A7%D8%B5%D9%84%DB%8C-%D8%AA%D8%A7%DA%A9%D8%B3%DB%8C-%D9%87%D8%A7%DB%8C-%D8%A7%DB%8C%D9%86%D8%AA%D8%B1%D9%86%D8%AA%DB%8C-%DA%86%D9%87-%DA%A9%D8%B3%DB%8C-%D8%A7%D8%B3%D8%AA-%D8%B1%D8%A7%D9%86%D9%86%D8%AF%D9%87-%DB%8C%D8%A7-%D9%85%D8%B3%D8%A7%D9%81%D8%B1-yzcwczez7hno برای من تجربه‌ی استفاده از تاکسی‌های اینترنتی در ایران، همیشه به این شکل بوده که زمانی که سفر از نظر مسیر، مسافت، زمان سفر و... سر راست بوده، به سادگی و با سرعت معقول یک راننده سفر را قبول کرده است. اما کافی است مسیر مورد نظر کمی سر راست نباشد یا به لحاظ مسافت طولانی باشد یا مسیری باشد که ترافیک داشته باشد، ورق بر می‌گردد و یا کسی سفر را قبول نمی‌کند و یا با معطلی زیاد این سفر پذیرفته می‌شود و یا با هزینه‌ی گزافی پذیرفته می‌شود که این هزینه‌ی گزاف بعضا از سمت شرکت خدمات دهنده تحمیل می‌شود (1) و یا با ترفندهایی نظیر دو مسیره کردن (برای بالا رفتن نرخ خدمات و ترغیب راننده برای پذیرفتن سفر) و یا از طریق گزینه‌هایی که برای بالا بردن هزینه سفر توسط شرکت خدمات دهنده پیش‌بینی شده است (نظیر انعام) اتفاق می‌افتد.(1) به نظر می‌رسد شرکت‌های خدمات دهنده، شرایط سفرهایی که مطلوب رانندگان نیست را رصد می‌کنند و هزینه اینگونه سفرها را افزایش می‌دهند تا برای رانندگان جذابیت پیدا کند. یا دست کم منطقی است که همچین اتفاقی صورت گیرد!در مدل‌های فعلی مشتری اصلی، راننده است!اما این تجربه برای مسافر ناشی از چیست؟ واقعیت این است که شرکت‌های خدمات دهنده به شکل آگاهانه یا ناآگاهانه، راننده را مشتری خود قرار داده‌اند و رضایت راننده از سفر انتخابی، اولویت اول کسب و کارهایی با این ساختار است! چرا این حرف را می‌زنم؟ عرض می‌کنم!راننده مقصد و هزینه‌ی در نظر گرفته شده برای سفر را مشاهده می‌کند و براساس تجریه‌ی خود، تصمیم می‌گیرد که سفر را انتخاب کند یا نه. طبیعتا به تجربه، راننده در می‌یابد که چه نوع سفرهایی، در چه زمان‌هایی، صرفه‌ی بیشتری برای او دارد و به دنبال افزایش سود خود، سفرهایی با مشخصات مشخصی را می‌پذیرد. شرکت‌های خدمات دهنده از این مدل سود می‌برند چرا که بهینه شدن درآمد راننده‌ها، به معنی افزایش سود شرکت‌های خدمات دهنده است. آنچه در این میان مغفول می‌ماند، رضایت مسافر است و سفرهایی که چون به نظر راننده‌ها مطلوب نیست و آنها را به درآمد مطلوب نمی‌رساند، هیچگاه پذیرفته نمی‌شود و یا به سختی یا با هزینه‌های نامعقول پذیرفته خواهد شد (با توجه به نکته (1) بند قبل). بنابراین می‌توان اینگونه نتیجه گرفت بنابراین می‌توان نتیجه گرفت که مدل کسب و کار شرکت‌های مذکور، براساس یک هوش جمعی است که مبنای آن، تلاش راننده‌ها برای رسیدن به بیشترین درآمد است. در این مدل مشتری اصلی برای شرکت‌های خدمات دهنده رانندگان هستند! شرکت‌ها اطلاعاتی را در اختیار راننده می‌گذارد که بتواند سفرهایی را انتخاب کند که به نظرش او را به حداکثر سود می‌رساند و راننده و شرکت خدمات دهنده از این موضوع سود می‌برد. رضایت مسافر؟ مادامی که مجبور است شرایط موجود را بپذیرد و به آن تن دهد، چه اهمیتی دارد؟ دست کم در شرایط حاکم فعلی، به نظر نمی‌رسد عدم رضایت مسافر در این مورد خطری برای شرکت‌های خدمات دهنده باشد!بدیهی است که ممکن است در مقاطع زمانی کوتاهی به جهت تغییر شرایط عرضه و تقاضا، مدل فوق برقرار نباشد اما به نظر می‌رسد شرایط کلی حاکم همان است که ذکر شد! مدل‌هایی که در آن رضایت مسافر اولویت استمدلی را در نظر بگیرید که در آن راننده براساس تمایل شخصی خود، محل شروع، پایان و میزان ساعت‌های مورد نظرش برای کار را مشخص می‌نماید و براساس ساعت‌های مشخص شده، از شرکت خدمات دهنده به شکل ساعتی پول دریافت می‌کند. در این مدل راننده در مورد انتخاب سفر براساس مسیر و هزینه دخالتی ندارد و شرکت خدمات دهنده سفرها را به راننده اختصاص می‌دهد و راننده مستقل از به صرفه بودن سفر یا دغدغه‌ی اینکه به حداکثر سود می‌رسد یا نه، براساس ساعت کاری‌اش درآمد دارد. در این مدل شرکت مسئول تخمین قیمت مناسب برای سفرها است که هم بتواند تعهدهای خود به رانندگان را پوشش دهد و هم خودش بتواند به سود مورد نظرش برسد. در این مدل دیگر خبری از هوش جمعی که در مدل قبل براساس تمایل رانندگان در رسیدن حداکثر سود کار می‌کرد نخواهد بود و یک مدل هوش مصنوعی نیاز است که بتواند تخمین‌های درستی از تعداد رانندگان قابل قبول در سیستم در هر لحظه، محل انتظار آنها و هزینه هر سفر داشته باشد (به نظر می‌رسد این موارد فاکتورهای کلیدی هستند). در این مدل می‌توان یک توازن بین رضایت مشتری و رانندگان برقرار کرد و به نظر می‌رسد اگر مدلی بتواند رضایت مشتری را در اولویت قرار دهد، چنین مدلی خواهد بود. در بازار آینده بازار کدام مدل شانس بقا دارد؟ از آنجایی که برقراری توازن بین فاکتورهای موثر در مدل دوم بسیار پیچیده‌تر از مدل ساده‌ی اول است بدیهی است که بسیاری از شرکت‌ها مدل اول را ترجیح دهند. اما سوال این است که آن مدل تا کجا می‌تواند سودآوری را برای شرکت‌های خدمات دهنده تضمین کند؟ تا کجا مسافر می‌پذیرد که در چنین مدلی نقش بازی کند و به دنبال روش‌های جایگزین‌ یا بازگشت به سیستم‌های سنتی حمل و نقل نباشد؟ در بازار آینده، کدام شرکت شانس بقای بیشتری دارد؟ شرکتی که با مناسبات فعلی بازار در حال حرکت است یا شرکتی که نقش و رضایت مسافر را به عنوان مشتری اصلی خواهد پذیرفت؟ کاوه احمدی کاوه احمدی Mon, 14 Mar 2022 14:44:29 +0330 https://virgool.io/@kaveh/%D8%B1%D9%88%DB%8C%D8%AF%D8%A7%D8%AF-refresh-%DB%8C%DA%A9-%D8%A8%D8%AF-%D8%B1%D9%88%D8%B4-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D9%85%D8%AD%D8%B5%D9%88%D9%84-cdgdvxmzptn6 «بد روش» را به عنوان معادل فارسی bad practice آورده‌ام. همچنانکه معادل فارسی best practice، «به روش» پیشنهاد شده است.اگر بخواهم در یک جمله کارکرد طراحی محصول را در مدیریت محصول برای یک فرد ناآشنا تشریح کنم، می‌گویم هدف از طراحی محصول، این است که اطمینان حاصل کند که استفاده از محصول برای کاربر لذت بخش است. این تعریف یک سیاست است که به چرایی اهمیت آن در اینجا نمی‌پردازم.رویداد Refresh با تمرکز بر مدیریت محصول، طراحی و فرانت‌اند و با تمرکز بر الهام بخشی به طراحان و مديران محصول قرار بود در تاریخ هشتم اسفند ۱۳۹۸ در کارخانه نوآوری و شتابدهی دیهیم برگزار شود. این کارخانه نوآوری که ظاهرا کارخانه‌ی سابق شرکت پونل است در فاصله ۵۵ کیلومتری از مرکز تهران قرار دارد. بماند!‍به دلیل شرایط پیش آمده بر اثر شیوع ویروس کووید ۱۹، برگزارکنندگان رویداد در تاریخ چهارم اسفند ماه اعلام داشتند که «رویداد با همان کیفیت و محتوا در نزدیکترین زمان و شرایط مساعد برگزار و دو هفته قبل از برگزاری به تمامی شرکت‌کنندگان و حامیان و مهمان‌های رویداد اطلاع داده می‌شود». در این اطلاعیه اشاره‌ای به این موضوع نشده که اگر تاریخ جدید اعلامی برای عده‌ای از شرکت کنندگان مناسب نباشد چه باید بکنند؟ اشاره‌ای نشده که ثبت‌نام کنندگان، برای «هشتم اسفند ۱۳۹۸» ثبت‌نام کرده‌اند و نه تاریخ نامشخص دیگری و ممکن است تمایل نداشته باشند در تاریخ دیگری در این رویداد شرکت کنند. در این اطلاعیه به این موضوع اشاره نشده است که با توجه به اینکه رویداد به تاریخ نامشخصی موکول شده است، اگر کسی بخواهد از حضور در این رویداد انصراف دهد چگونه می‌تواند این کار را بکند. ایمیل اطلاع رسانی به تعویق افتادن رویدادهدف از طراحی محصول، لذت بخش کردن محصول برای کاربر است. چگونه برگزارکنندگان رویداد «باید» با شرایط پیش‌رو روبرو می‌شدند؟ لغو رویداد، و دادن انتخاب به کاربر که می‌خواهد منتظر تاریخ نامشخص بعدی بماند یا درخواست انصراف از شرکت در رویداد و بازگرداندن هزینه‌ی پرداختی را دارد. انتخابی که هیچگاه به ثبت‌نام کنندگان داده نشد.ماجرا اینجا به پایان نمی‌رسد! ایوند، که ثبت‌نام رویداد از طریق آن انجام شده بود، شب قبل از رویداد در ایمیلی خبر از کنسل شدن رویداد می‌دهد و می‌گوید «​​برگزارکننده‌ی رویداد متعهد است مبلغ پرداختی شما را در اسرع وقت به حساب شما بازگرداند و «ایوند» این فرآیند را پیگیری و نظارت میکند»! ایمیل اطلاع‌رسانی ایوند که می‌گوید رویداد کنسل شده استساعتی نمی‌گذرد که برگزار کنندگان رویداد با ارسال ایمیل دیگری می‌گویند اشتباه شده و «هزینه پرداختی شما پیش ما محفوظ خواهد ماند»! هدف از طراحی محصول، لذت بخش کردن محصول برای کاربر است.تکذیب خبر لغو رویداد. هزینه پرداختی محفوظ است!در آخرین اقدام که انگیزه‌ی اصلی نگارش این متن است، و به عنوان ضربه‌ی نهایی از آن یاد می‌کنم، برگزارکنندگان رویداد تصمیم گرفتند که رویداد را آنلاین برگزار کنند. آنها تمایل ثبت‌نام کنندگان را برای شرکت در یک رویداد آنلاین به جای حضوری در نظر نگرفتند. آنها اشاره‌ای نکردند اگر کسی تمایل یا امکان حضور در یک رویداد آنلاین را ندارد چه باید بکند. آنها اشاره‌ای نکردند که هزینه‌های برگزاری یک رویداد آنلاین به مراتب کمتر از یک رویداد حضوری است و چرا افرادی که هزینه‌ی شرکت در یک رویداد حضوری را پرداخت کرده‌اند باید با همان هزینه رویداد را به شکل آنلاین دنبال کنند. همانطور که پیشتر گفته بودند، «هزینه پرداختی شما پیش ما محفوظ خواهد ماند» و اگر بخواهم این عبارت را به فارسی قابل فهم تبدیل کنم، پول گرفته شده تحت هیچ شرایطی بازگردانده نخواهد شد. هدف از طراحی محصول، لذت بخش کردن محصول برای کاربر است.کرونا برای هرکه بد شد، برای بعضی‌ها بد نشد!به فهرست سخنرانان و دست اندرکاران این رویداد که نگاه کنیم، چهره‌های مدعی زیادی در این حوزه در بین آنها وجود دارد و نیشخند ماجرا اینجاست که ظاهرا هیچکدام از آنها به رویه‌ی در پیش گرفته شده اعتراضی ندارند. هدف از طراحی محصول، لذت بخش کردن محصول برای کاربر است. طراحان محصول ما دست اندرکاران این رویدادند! بماند! کاوه احمدی کاوه احمدی Tue, 21 Apr 2020 11:45:29 +0430 https://virgool.io/@kaveh/%D8%A7%DA%AF%D8%B1-%D8%A8%D9%87-%D8%B4%D9%85%D8%A7-%D8%A7%D8%B9%D8%AA%D9%85%D8%A7%D8%AF-%D9%86%D9%85%DB%8C%DA%A9%D9%86%D9%86%D8%AF-%D8%A7%D8%B3%D8%AA%D8%B9%D9%81%D8%A7-%D8%AF%D9%87%DB%8C%D8%AF-r5x5sn670im4 موارد ذکر شده در این متن براساس نظرات شخصی به نگارش درآمده و دسته‌بندی‌ها و تعاریف ذکر شده ممکن است مطابق با تعاریف آکادمیک و قابل اتکا نباشد.مطالب زیادی روی وب منتشر می‌شود که از نشانه‌هایی صحبت می‌کنند که می‌گویند زمان استعفا از شغلتان فرا رسیده است. به نظرم عمده‌ی این نشانه‌ها را می‌توان در پاسخ به یک سوال پیدا کرد: آیا به شما اعتماد کرده‌اند؟ و متقابلا آیا شما می‌توانید به آنهایی که به شما اعتماد نمی‌کنند، اعتماد کنید؟ توضیح می‌دهم:در زمان استخدام سه فاکتور مهم در ارزیابی ما موثر است: (۱) توانایی‌ها (۲) تجربیات (۳) دانشمرز دقیقی برای تعریف یا تعیین این فاکتورها ندارم اما برای نمونه، ارزیابی یک برنامه‌نویس فول‌استک با توجه به فاکتورهای گفته شده با معیارهای زیر خواهد بود:توانایی‌ها: برنامه‌نویسی فرانت‌اند و بک‌اند با زبان‌های برنامه‌نویسی مورد نظر و توانایی به کارگیری چارچوب‌ها و... مطابق با نیازهاتجربیات: ممکن است افراد با توانایی‌های مشابه تجربیات متفاوتی داشته باشند. مثلا تجربه‌ی کار در یک تیم چابک / بین‌المللی یا تجربه‌ی کار روی یک سیستم با تراکنش بالا. ممکن است این تجربیات به درد یک سازمان بخورد یا نخورد. و قاعدتا افرادی با تجربیات هم‌راستای نیازهای سازمان، اولویت بالاتری در جذب خواهند داشت.دانش: افراد علاوه بر توانایی‌ها و تجربیات خود ممکن است در طول زمان دانش‌هایی را کسب کرده باشند که به صورت عملی از آنها استفاده نکرده باشند اما مطالعاتی در مورد آنها دارند و این مطالعات آنقدر عمیق بوده که در صورت لزوم بتوانند از آنها استفاده کنند. مثلا برنامه‌نویسی را در نظر بگیرید که در حوزه‌هایی نظیر هوش تجاری یا علم داده در حال مطالعه و یادگیری است.طبیعی است که ارزیابی یک فرد برای استخدام جنبه‌های دیگری نیز دارد. در اینجا بیشتر به جنبه‌های فنی اشاره شده است.شما با داشتن فاکتورهای لازم استخدام شده‌اید و حال زمان آن است که پس از گذراندن دوره‌ی آزمایشی به شما اعتماد شود تا با استفاده از توانایی‌ها، تجربیات و دانش خود ایجاد ارزش کنید.کم شدن نظارت‌ها در طول زمان، افزایش اختیارات، دادن مسئولیت‌های جدید، استفاده از تجربیات و دانش شما در جاهایی که به آنها نیاز است و مشورت گرفتن از شما در این موارد به نظرم نشانه‌هایی از اعتماد به شما است. و بلعکس، زیاد شدن نظارت‌ها، کم شدن اختیارات و مسئولیت‌ها، کنترل‌های مداوم، نادیده گرفتن تجربیات و دانش شما نشان دهنده‌ی بی اعتمادی به شما است. قرار گرفتن در سازمانی که به شما اعتماد نکرده است در نهایت منجر به این می‌شود که شما تبدیل به شخصی شوید که روزمره در حال تکرار کارهای روتین است و مجالی برای افزایش توانایی‌ها، کسب تجربه جدید یا انگیزه‌ای برای افزایش دانش خود نخواهد داشت و توجه کنید که این سه فاکتور سرمایه‌هایی مهم در مسیر حرفه‌ای شما است. از طرف دیگر، سازمانی که به شما اعتماد نمی‌کند دیر یا زود به این نتیجه خواهد رسیده که به شما نیازی ندارد!همیشه معتقد بوده‌ام که برنامه‌نویس‌ها جزو خوشبخت‌ترین انسان‌های روی زمین هستند. چرا که آنچه که دوست دارند را انجام می‌دهند و بخاطرش حقوق هم می‌گیرند! اما فراوانند برنامه‌نویس‌هایی که خوشحال نیستند. در خیلی از موارد با ریشه‌یابی چرایی این موضوع با برنامه‌نویس‌هایی مواجه می‌شویم که به آنها اعتماد نشده است...! این موضوع برای بسیاری از حرفه‌های دیگر هم معتبر است.تصمیم با شما، اگر به شما اعتماد نکرده‌اند، استعفا دهید! چالش‌ها ممکن است شما را خسته کند، فشار کاری ممکن است باعث اضطراب شما شود اما بی اعتمادی به شما، از شما کسی خواهد ساخت که دیگر شما نیستید! در هر صورت اگر خواستید استعفا دهید، مثل یک حرفه‌ای این کار را انجام دهید.و صحبت آخر با کارفرماها:نمایی از فیلم Jerry Maguire کاوه احمدی کاوه احمدی Mon, 20 Apr 2020 16:49:19 +0430 https://virgool.io/@kaveh/%D8%AA%D8%A7-%DA%A9%DB%8C-%D9%82%D8%B1%D8%A7%D8%B1-%D8%A7%D8%B3%D8%AA-%D8%AF%D8%B1-%D9%85%D9%88%D8%B1%D8%AF-%D8%B3%D9%81%D8%B1%D9%87%D8%A7%DB%8C%D9%85%D8%A7%D9%86-%D8%AF%D8%B1%D9%88%D8%BA-%D8%A8%DA%AF%D9%88%DB%8C%DB%8C%D9%85-ibvw7nhbgctp در سفرهای طبیعت گردی مختلف به کرات با افرادی همسفر شده‌ام که هدف خود را از سفر دور شدن از فضای روتین زندگی خود، رها شدن از استرس‌های زندگی، رفرش شدن و موارد این دست اعلام می‌کنند. به این واقعیت که اگر حالت خوب نباشد، سفر هم حال شما را خوب نمی‌کند نمی‌پردازم، اما تا کی قرار است در مورد سفرهایمان دروغ بگوییم؟ طبیعت گردی با همه خوبی‌هایش، چالش‌های مخصوص به خود را دارد. از خطرات جانی در سفرهای ماجراجویانه، تا خراب شدن ماشین در سفرهای آفرودی، از یاری نکردن آب و هوا و گرفتار باد و باران شدن و حتی خیلی ساده‌تر، دستشویی‌های صحرایی!‌‌سفر رفتن با این پیش‌فرض که قرار است خیلی خوش بگذرد، و القای این حس به خود و دیگران هنگام و بعد از سفر، حتی اگر سفر بدی را پشت سر گذاشته باشیم، فقط و فقط فضا را برای سو استفاده برخی به اصطلاح بنگاه‌های تورگردی و برخی جوامع محلی مهیا می‌کند (می‌دانم نگاه به جوامع محلی همواره افرادی مهربان که با روی گشاده از شما پذیرایی می‌کنند القا شده است اما لزوما اینگونه نیست و خیلی از محلی‌ها راه و چاه سو استفاده از مسافر را به خوبی یاد گرفته‌اند).‌‌شما با این پیش‌فرض می‌روید که قرار است خوش بگذرد و هر اتفاقی هم که بیفتد به خود القا می‌کنید که بهترین سفر را رفته‌اید و همین را نیز در شبکه‌های اجتماعی و گروه سفر و... بازگو می‌کنید و اگر غیر از این بکنید و برخی کاستی‌ها را گوش زد کنید برچسب سفر خراب کن و بد مسافرت خواهید خورد.ییلاق مازیچال ‌‌طبیعت گردان تازه‌کار دچار یک سیکل معیوب شده‌اند، سفر می‌روند تا حالشان خوب شود، تا از روزمرگی‌هایشان فرار کنند و دچار بنگاه‌هایی می‌شوند که با توجه به اینکه می‌دانند قاطبه مسافران پس از سفر در هر شرایطی از آن ابراز رضایت می‌کنند، هیچ تلاشی برای ترتیب یک سفر مسئولانه نمی‌کنند. برخی جشنواره رنگ به راه می‌اندازند تا سفرشان را مهیج کنند و برخی که مدعی #آگاه_سفر_کنیم هستند حتی در آن حد هم - با فرض رعایت موارد زیست محیطی - تلاش به خرج نمی‌دهند! ساده‌ترین برنامه‌ای که بتوان نامش را طبیعت گردی گذاشت ندارند! برنامه «اکو کمپینگ» و «اکو سافاری» می‌گذارند و سفر را «اکو تالاپی» و «اکو تالاپینگ» برگزار می‌کنند (تلپ شدن در یک نقطه از طبیعت که رسیدن با آن نیز ساده باشد)! شما را جایی می‌برند برای کمپ و این تمام برنامه‌شان است! ‌‌نه برای شرایط آب و هوایی مختلف برنامه‌ای دارند و نه اصلا بلد هستند. نهایت چند گشت پیاده می‌گذارند و پانصد متر از محل کمپ‌شان دور می‌شوند. اسمش را می‌گذارند سفر به فلان منطقه و سهل الوصول‌ترین جای ممکن شما را متوفق می‌کنند و می‌گویند همه‌ش همین است حتی اگر اصل ماجرا جای دورتری باشد. چالش به خرج نمی‌دهند و صرفا هدف همان است که بگویند به آن منطقه سفر کردیم! و نیشخند ماجرا اینجاست که به دلایلی که بالا گفتم پس از سفر همه از سفر راضی هستند و آنچه منعکس می‌شود تصاویر چادرهایی‌ست که منظره‌اش رو به طبیعتی زیباست و آنچه گفته نمی‌شود، کمپی بدون برنامه و ماجرایی خاص در باران و سرمای جواهردشت یا آفتاب سوزان مازیچال است! ‌‌نتیجه این برنامه ریزی‌های نادرست و سواستفاده از نیت افراد در سفر - بویژه سفرهای ماجراجویانه‌تر و طبیعت‌گردی - این است که یا افراد چند مدتی اینگونه سفر می‌روند و آگاه می‌شوند و خود را از این وادی بیرون می‌کشند یا کلا قید چنین سفر کردنی را می‌زنند. سوالی که بی‌پاسخ می‌ماند این است که بنگاه‌های گردشگری چقدر مردم را با چنین سفرهایی به اهدافی که ادعا می‌کنند می‌رسانند و آنچه اتفاق می‌افتد به جز پول به جیب زدن بنگاه‌ها و سو استفاده‌کنندگان محلی چیست؟ آشتی با طبیعت رخ می‌دهد یا مسافران را از طبیعت نیز ناامید می‌کنند و وای بر روزی که کسی از طبیعت نیز ناامید شود! دیگر چقدر به آن بها خواهد داد و تلاش خواهد کرد در نگهداشت آن؟‌‌بخواهیم یا نه هر سفری هرچقدر هم مسئولانه ضررهایی برای طبیعت دارد. در برابر این ضررها و بخشندگی طبیعت چه چیزی عاید ما می‌شود؟ سفر مسئولانه با هشتگ آگاه سفر کنیم و نه به رنگ بازی حاصل نمی‌شود. https://www.instagram.com/p/BnJuX7kHwrl/ کاوه احمدی کاوه احمدی Sat, 01 Sep 2018 12:59:05 +0430 https://virgool.io/Software/%DA%86%D8%A7%D9%84%D8%B4%D9%87%D8%A7%DB%8C-%D9%BE%DB%8C%D8%B4-%D8%B1%D9%88%DB%8C-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85%D9%87%D8%A7%DB%8C-%D9%86%D8%B1%D9%85%D8%A7%D9%81%D8%B2%D8%A7%D8%B1%DB%8C-yesa9zuxayx5 توسعه دهندگان سیستم در طول زمان با چالش‌های متفاوتی روبرو خواهند شد که این چالش‌ها مستلزم ایجاد تغییراتی در سیستم‌های موجود یا تغییر رویه‌های طراحی و توسعه برای سیستم‌های جدید خواهد شد. شناخت هرچه بهتر و سریعتر این چالش‌ها و اهمیت دادن به آنها می‌تواند مشکلات ناشی از این چالش‌ها را در آینده برای ما کمتر و رفع آنها را کم هزینه‌تر کند. احتمالا اکثر سیستم‌ها از چالش‌هایی که تا کنون با آنها روبرو شده‌اند سربلند بیرون آمده‌اند اما مسئله مهم این است که بتوانیم با شناخت این چالش‌ها، آنها را به شکل proactive حل کنیم و به تغییرات reactive نیازی نشود. این امر قطعا در میزان رضایت مشتریان و کیفیت نرم‌افزارهایمان تاثیر مستقیم خواهد گذاشت.سه چالش که این روزها ذهنم درگیر آنها است و هر مدیر محصول / مسئول فنی (یا هر نقش مرتبط دیگری) به آن مواجه خواهد شد را در اینجا ذکر می‌کنم. چالش سال 2038 (Y38K)مبدا تاریخ (Epoch) اشاره به نقطه‌ی مشخصی از زمان دارد که به عنوان مبنای محاسبه زمان مورد استفاده قرار می‌گیرد. به عنوان مثال میلاد مسیح یک مبدا تاریخی است و می‌دانیم امسال ۲۰۱۸ سال از آن روز می‌گذرد. در سیستم‌های نرم‌افزاری نیز مبداهای تاریخ متفاوتی استفاده می‌شود. مثلا در ساعت یونیکس (Unix time یا Unix timestamp) که به صورت گسترده در سیستم عامل‌های شبه‌یونیکس و برخی دیگر از سیستم عامل‌ها و فایل فرمت‌ها مورد استفاده قرار می‌گیرد، مبدا تاریخ ساعت ۰۰:۰۰:۰۰ روز اول ژانویه سال ۱۹۷۰ میلادی (به وقت گرینویچ) است. ساعت یونیکس توسط تعداد ثانیه‌هایی که از مبدا تاریخش گذشته است مشخص می‌شود. به عنوان مثال در ساعت ۱۱:۳۰:۰۰ روز ۲۰ آگوست سال ۲۰۱۸ میلادی، ۱۵۳۴۷۶۲۸۰۰ ثانیه از تاریخ مبدا گذشته است و همین عدد به عنوان ساعت یونیکس مورد استفاده قرار می‌گیرد.مشکل کجاست؟در سیستم‌های ۳۲بیتی که از ساعت یونیکس استفاده می‌کنند، بزرگترین عدد قابل ذخیره در یک متغیر عددی صحیح علامت دارد (signed 32-bit integer)، عدد ۲۱۴۷۴۸۳۶۴۷ (دو به توان ۳۱ - ۱) است. این عدد برابر با ساعت ۰۳:۱۴:۰۷ در روز پنجشنبه، ۱۹ ژانویه ۲۰۳۸ میلادی است. عددهای بزرگتر به عنوان یک عدد منفی ذخیره خواهند شد (چرا؟ چون overflow رخ می‌دهد. فرم مکمل ۲ در ذخیره اعداد صحیح به صورت باینری را بررسی کنید) که به عنوان روز ۱۳ دسامبر ۱۹۰۱ تفسر خواهد شد و نه ۱۹ ژانویه ۲۰۳۸.این مشکل سیستم عامل‌ها، سیستم‌های تعبیه شده، فایل فرمت‌ها، سیستم‌های مدیریت پایگاه داده و بسیاری از نرم افزارها را تحت تاثیر قرار خواهد داد.راه حل چیست؟در جاهایی که محدودیت‌های سخت افزاری وجود دارد راه حل‌های زیادی وجود ندارد (اما به هر حال قابل حل است!) اما خبر خوب این است که سیستم‌های ۶۴بیتی تقریبا فراگیر شده و توسعه دهندگان سیستم می‌توانند با کمی توجه از این مشکل عبور کنند!چالش سال ۱۴۰۰خیلی از زبان‌های برنامه‌نویسی یا سیستم‌های مدیریت پایگاه داده و... از تاریخ شمسی به شکل توکار پشتیبانی نمی‌کنند. اما به هر حال ما به دلایلی تصمیم گرفته‌ایم در نرم‌افزارهایمان تاریخ‌ها را به شکل شمسی ذخیره کنیم و محاسباتی روی آنها انجام دهیم. چیزی که در سیستم‌ها به کرات دیده می‌شود، ذخیره تاریخ شمسی به شکل یک عدد صحیح شش رقمی است. مثلا ۹۷۰۵۲۸. عمده توابع تبدیل تاریخ که در زبان‌های برنامه‌نویسی مختلف در دسترس است نیز با همین فرمت کار می‌کنند و عمدتا الگوریتم‌های بکار رفته در آنها نیز تا سال ۱۳۹۹ را پشتیبانی می‌کنند. مسئله این است که سال ۱۴۰۰ چه می‌شود؟ تاریخ‌ها چگونه ذخیره خواهند شد؟ ۰۰۰۱۰۱ روز اول سال ۱۴۰۰ است؟ توابع تبدیل تاریخ چه خواهند کرد؟ خیلی دور نیست زمانی که سال ۱۴۰۰ را جشن خواهیم گرفت و اگر امروز به فکر یک اصلاح پیشگیرانه (Preventive) برای حل این چالش نباشیم، نوروز ۱۴۰۰ برای مسئولان سیستم‌هایی که از چنین منطقی بهره می‌برند، جشن نخواهد بود!آیا هیچ روش بهتری برای ذخیره تاریخ‌ها وجود نداشت که با چنین مسئله روبرو نشویم؟ پاسخ دادن به این سوال مسئله‌ای را حل نمی‌کند. چگونه سیستم‌هایمان را طراحی کنیم که با چنین چالشی روبرو نشویم یا چگونه سیستم‌های موجود را اصلاح کنیم؟ پاسخ این است که مگر در موارد خیلی خاص شخصا سیستمی را ندیده‌ام که نشود با یک سری تغییرات کم هزینه مشکلش را حل کرد. مهم این است که به چالش توجه کنیم و قبل از آنکه دیر شود ابعاد آنرا در سیستم‌هایمان بررسی کرده، برای حل آن برنامه‌ریزی‌های لازم را انجام دهیم.چالش تغییر پول ملیتکلیف تغییرات پول ملی مشخص نیست. n صفرش حذف می‌شود؟ ریال باقی خواهند ماند؟ تومان می‌شود؟ یا اسم دیگری خواهد داشت؟ مشخص نیست و مشخص نیست کی مشخص خواهد شد! اما ما مجبوریم به توسعه سیستم‌هایمان ادامه دهیم. ابعاد تغییرات ناشی از تغییر پول ملی ممکن است خیلی کم یا خیلی زیاد باشد. این چالش همانند چالش سال ۱۴۰۰ نیست که بدانیم دقیقا با چه روبرو خواهیم شد و ابعادش چیست و عقل سلیم می‌گوید باید برای بدترین سناریو آماده باشیم. مثلا چهار صفر حذف می‌شود و اسمش می‌شود «پارسی»و «دریک» که یک صدم یکای اصلی ارزش دارد!یک طراح باهوش احتمالا با استفاده از یک الگوی طراحی مناسب (مثلا Factory Method یا حتی Proxy) سیستم‌هایش را به نحوی توسعه خواهد داد که با مشخص شدن ابعاد تغییرات و با یک تغییر انطباقیِ (Adaptive) نه چندان پیچیده بتواند مسئله تغییر پول ملی را حل نماید.برای سیستم‌های موجود نیز فرصت برای یک تغییر تکمیلی (Perfective) وجود دارد که به محض تغییر پول ملی بتوان با یک تغییر انطباقی (Adaptive) نه چندان پیچیده مسئله را حل کرد.به نظرتان چه چالش‌های دیگری وجود دارد که می‌تواند سیستم‌های نرم‌افزاری ما را تحت تاثیر قرار دهد؟ کاوه احمدی کاوه احمدی Mon, 20 Aug 2018 14:05:54 +0430 https://virgool.io/@kaveh/%D8%A8%D9%86%D9%88%DB%8C%D8%B3%DB%8C%D9%85-%D8%A8%DB%8C-%D8%A2%D9%86%DA%A9%D9%87-%D8%A8%D8%AA%D8%B1%D8%B3%DB%8C%D9%85-mkd86wdr9gg4 خیلی از آدم‌ها با وجود تجربیاتی که برای انتقال، یا حرف‌هایی که برای گفتن دارند، نمی‌نویسند. بُعد کمال گرایشان می‌گوید اگر می‌خواهی بنویسی باید چیزی بنویسی که مو لای درزش نرود! که با توجه به مشغله روزمره این روزهای آدم‌ها ممکن نمی‌شود.ویرگول اما، بدون توجه به اینکه محتوای یک نوشته یک متن تخصصی یا فلسفی است، یا بازگویی یک خاطره، و فقط براساس طول نوشته به شما می‌گوید خواندن نوشته چقدر طول خواهد کشید! این دو گزاره را که کنار هم بگذاریم، می‌توان نتیجه گرفت که در ویرگول، می‌توان نوشت بی‌آنکه آنچه می‌نویسیم در بالاترین حد کمال باشد. ویرگول می‌تواند جایی باشد برای تمرین نوشتن، برای انتقال تجربیات، برای بیان نظرات شخصی، بدون آنکه وسواس اضافی به خرج دهیم که آنچه نوشته شده کاملا درست، جامع و خالی از ایراد باشد. بنویسیم؛ اتفاق‌های خوبی خواهد افتاد!نکته خوب این است که بستر برای دیالوگ در ویرگول فراهم است و می‌توان نظرات دیگران را در مورد آنچه اندیشیده‌ایم شنید و نکات جدید آموخت.مدتی هست که درگیر ویرگول شده‌ام به این معنی که روزانه به آن سر می‌‌زنم و با همین دیدگاه مطالب زیادی می‌خوانم. و سعی می‌کنم با همین رویکرد اینجا بنویسم. کاوه احمدی کاوه احمدی Mon, 13 Aug 2018 21:24:09 +0430