https://virgool.io/feed/@remohammadi هم‌بنیان‌گذار کافه بازار و دیوار fa 2026-06-10 22:02:15 https://files.virgool.io/upload/users/3164/avatar/avatar.png?height=120&width=120 https://virgool.io/@remohammadi https://virgool.io/@remohammadi/%D9%86%D8%B4%D8%AA-%D8%AA%D8%A8%D8%B9%DB%8C%D8%B6-dxzwsxk8fxjs (پیشاپیش از اینکه این نوشته خیلی ساختاریافته نیست معذرت می‌خوام. وسط تز نوشتن هستم، خیر سرم!)طی نوشتن مقاله (بخوانید مشق!) برای درس Cultures of New Media Production به یه سری مطلب جالب در مورد هنجارهای جاری در محیط‌های کسب و کارهای خلاقانه و نتایجش از زوایای مختلف برخوردم که در انتها یکی دو موردشون رو ذکر خواهم کرد. از یه طرف دیگه هم اخیراً چند سری با دوستان بحث عدم حضور زنان در فضاهای فنی در غرب مطرح شده بود که یه جاهایی به وضوح از ایران پررنگ‌تر هستش. تو این مطلب اول می‌خوام کمی اشاره کنم به تاریخچهٔ این موضوع در غرب و فرقش با ایران، و بعدش هم یه مثال می‌یارم از اینکه چطور آزادی زمان کار کردن (flextime) می‌تونه باعث بشه که تبعیض از یه موقعیت به یه موقعیت دیگه نشت بکنه.زنان و برنامه‌نویسی در غرببرداشت من تا الان این بوده که دو تا عامل در پایین بودن حضور زنان در سمت تولید نرم‌افزار نقش داشته است. یکی موضوع قدیمی‌تر مقاومت در برابر راه دادن زنان به نقش‌های جدی جامعه بوده که طی قرن گذشته طی مبارزات برابری‌خواهان وضعیت در خیلی موضوعات به برابری نزدیک‌تر شده. ولی در مورد برنامه‌نویسی و علوم کامپیوتر یه اتفاقی طرفای ۱۹۸۰ می‌افته که به نظرم این نمودار خوب نشونش می‌ده:نمودار ۱: درصد زنان در میان مدرک‌های اعطا شده در رشته‌های مختلف، در آمریکابین دلایلی که برای توضیح این سقوط می‌آورند، مردانه (و سفیدپوستانه، و جوان‌پرستانه؟!) بودن خرده‌فرهنگ نردی (Nerdy) حاکم بر سیلیکن‌ولی در آن ایام به نظرم منطقی‌تر آمده است. یه جایی خوندم که این شورش مردهای سفیدپوست بوده است در مقابل موفقیت‌های نسبی اقلیت‌ها در یکی دو دههٔ قبلش در گرفتن برخی از حقوقشون. برای من این توضیح منطقی اومد چون برای مثال با این خاطره از Andy Hertzfeld از یکی از مصاحبه‌هایی که جناب استیو جابز برای پروژهٔ مکینتاش نقل کرده بود می‌آمد.اثرات آن خرده‌فرهنگ همچنان هست و مثلاً وقتی یه meetup فنی می‌گذارند، تعداد زنان شرکت‌کننده به وضوح کمتر از مردان است، و چشمی به نظرم آمده است که هر چه موضوع هم به سیستم عامل نزدیک‌تر بوده، این تفاوت پررنگ‌تر است. مثلاً در موضوعات فنی مرتبط به UI/UX که بعدتر متولد شده این تفاوت (بنا به تجربهٔ چشمی‌ام، داده‌ها رو بررسی نکردم) اینقدر پررنگ نیست.وقتی که برنامه‌نویسی در ایران رایج می‌شه هم مشابه موضوع UI/UX که گفتم خرده‌فرهنگ همراهش تا حدودی اصلاح شده بود و به نظرم میاد خیلی به ایران نرسید. (باز البته اینجا هم حرفم بنا بر داده نیست. تزم رو که نوشتم سعی می‌کنم این مطلب رو با داده به روز کنم، یا اگر دوستان لطف کنند و داده و تصحیح در این پایین بیاورند که زودتر اصلاحیه خواهم زد.)نشت تبعیضدر ایران انواع دیگری از تبعیض وجود دارد که بعضی‌هایشان در قوانین هم جا خوش کرده‌اند. اینجا ولی موضوع یک تبعیض جاری در جامعه است، تبعیض در آزادی در حضور تا دیروقت در بیرون از خانه.می‌خوام در ادامه به یک آزادی اشاره کنم که باعث می‌شه این تبعیض از فضای بیرون کار رخنه کنه به محیط کار و باعث بشه که برای مثال زنان شانس کمتری برای ترفیع گرفتن در یک شرکت نرم‌افزاری داشته باشند.پیش‌فرضم اینه که تا دیروقت بیرون بودن در شرایط فعلی ایران برای دختران به طور قابل توجهی سخت‌تر از پسران است، و شرکتی داریم که ساعت کاری‌اش مطلقاً آزاد است و هماهنگ کردن زمان جلسات و زمان کار را به عهدهٔ خود اعضای تیم سپرده است.در این شرایط، مثلاً در یک تیمی که از ۵ پسر و ۳ دختر تشکیل شده، پسرها ممکن است ترجیح بدهند که زمان جلسه‌ای ۸ شب باشه. چون شرکت محدودیتی نگذاشته، فشار مخالفت کردن بر دوش دخترهای تیم است، و در میان دخترهای تیم هم یحتمل بین اون‌هایی‌شون که خانواده‌شون محافظه‌کارتر است. اینطوری می‌شه که پسرها به طور ناخودآگاه ترجیح خواهند داد که در تیم‌شمون دختر نباشه تا با چنین بحث‌های سختی مواجه نشوند، و این ترجیح ناخودآگاه می‌تونه در مصاحبه‌ها یا موقعیت‌های دیگه خودش رو نشون بده. مثال دیگه فعالیت‌های غیر رسمی‌تر است. مثلاً ممکنه دو تا پسر تصمیم بگیرند که نزدیک ریلیز شب بمونند شرکت و یک باگی رو فیکس کنند–کاری که برای دخترها طبق فرضم چندان شدنی نیست. چنین عملی بی‌پاداش نمی‌مونه و شانس اون پسرها برای ترفیع گرفتن آخر فصل بیشتر خواهد شد، حتی وقتی که ترفیع بر اساس دموکراتیک‌ترین نوع peer review باشه.تو این سناریوها هیچ کس قصد بدی نداره. ولی هر کس براساس شرایط و منافعی که داره ترجیحاتی هم داره. آزادی عمل اینجا داره باعث می‌شه که یه تبعیض از بیرون شرکت نشت کنه به داخل شرکت.هنجارهای اجتماعی در مقابل هنجاری‌های بوروکراتیکیکی از جذاب‌ترین مطالبی که در درس مربوطه خوندم رو خود نویسنده در این ویدئو با عنوان Burning Man at Google توضیح می‌ده که دیدنش رو پیشنهاد می‌کنم. برای جذاب‌تر شدنش، یه عکس از مراسم هیجان‌انگیز و بامزهٔ Burning Man می‌گذارم اینجا، و این نکته رو می‌گم که وقتی بنیان‌گذارهای گوگل می‌خواستند برای گوگل مدیر عاملی غیر خودشان پیدا کنند، یکی از آزمایش‌هایی که برای بررسی صلاحیت نامزد این سمت، اریک اشمیت، در نظر گرفتند این بود که باهاش رفتند به مراسم Burning Man تا ببینند آیا می‌تواند در آن شرایط با آدم‌ها قاطی شود یا نه.تصویر ۲: از مراسم سال ۲۰۱۲ «مرد سوزان!»در انتهای آن ویدئو نویسنده، فرد ترنر که در حال حاضر استاد ارتباطات دانشگاه استنفورد است، اشاره به خطر جانشین کردن هنجارهای اجتماعی به جای هنجاری‌های بوروکراتیک می‌کنه. در جای دیگری ایشون اینطور می‌گویند کهوقتی شما بوروکراسی و سلسله مراتب و سیاست رو کنار می‌گذارید، امکان چانه‌زنی در مورد توزیع منابع به طور صریح را کنار می‌گذارید. و جایگزینش می‌کنید با کاریزما، با باحالی، با قدرت ضمنی. شما با قدرت‌های فرهنگی‌ای جایگزینش می‌کنید که رفتار ما را در غیاب قانون هدایت می‌کنند.در مثالی که در قسمت قبلی گفتم به نظرم داره همین اتفاق می‌افته. وقتی شرکت در موضوعی آزادی مطلق می‌دهد، در واقع کار سخت ایستادن در مقابل تبعیضات موجود در جامعه که در آن موضوع خودشان را نشان می‌دهند را از دوش خود بر می‌دارد و به دوش کارمندان اقلیت مورد آن تبعیض می‌اندازد.حالا سؤال سخت ماجرا اینه که راه‌حل چیست؟ برای مثال، من خودم به سختی می‌تونم تصور کنم که حاضر باشم در آینده در شرکتی مشغول به کار شَوَم که ساعت کاری‌اش ۹ صبح تا ۵ بعدازظهر ثابت باشد. ولی به نظرم معقول است که مثلاً در این موضوع بپذیریم که شرکت برای ساعت‌های جلسات کاری یک محدودیت کلی در نظر بگیرد. یا مثلاً نه تنها به خاطر قسمت دوم سناریویی که گفتم، بلکه به دلایل دیگری مثل جلوگیری از کارزَدگی نیروهایش برایشان سقف تعداد ساعت کار در روز/۴۸ ساعت/هفته بگذارد.برای من تا الان درس مهمی که از رشته‌ام گرفته‌ام، رشتهٔ علوم انسانی برای آدمی که لیسانسش علوم کامپیوتر بوده، این است که دنبال گلوله نقره‌ای در موضوعات انسانی نباشم. بر خلاف مسائل الگوریتمی که خیلی زمان‌ها می‌توان از برتری یک راه‌حل نسبت به یک راه‌حل دیگر اطمینان پیدا کرد، در موضوعات انسانی از این خبرها نیست!منبع تصاویر:نمودار ۱: داده‌ها از Digest of Educational Statistics. به نقل از این پست بلاگتصویر ۲: از حساب mypubliclands در flickr رضا محمدی (قایقچی) رضا محمدی (قایقچی) Tue, 12 Mar 2019 20:55:02 +0330 https://virgool.io/@remohammadi/%DA%86%D9%87-%D8%B4%D8%AF-%DA%A9%D9%87-%D9%85%D8%A7%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-xevulqbwq8w8 چه استارت‌آپ چه گروئن‌آپ، تقسیم تسک‌ها بین اعضای تیم در یک کسب و کار پویا مثل کسب و کارهای اینترنتی چالش قابل توجهی است؛ مهم‌ترین کار مجموعه نیست ولی مهم است (مهم‌ترین احتمالاً تشخیص تسک‌هایی است که لازم است انجام بدهید از تسک‌هایی که چندان هم ضرورت ندارند، و یا حتی آن‌هایی که بعداً از اینکه انجامشان نداده‌اید خیلی هم خوشحال می‌شوید). در این پست می‌خواهم با تکیه به تجربیاتم در بازار و دیوار در این موضوع خاص از جنبهٔ فنی بنویسم، و اینکه چه شد که به مایکروسرویس رسیدیم.البته که جنبهٔ انسانی موضوع تقسیم کار در تیم پرچالش‌تر است و احتمالاً برای اکثر مخاطبین این مطلب وزن و اهمیت بیشتری دارد. ولی در آن موضوع مطلب زیاد است و انواع متدولوژی‌ها برای کار تیم‌های نرم‌افزاری ایجاد شده که بعضی‌هایشان هم خوب جوابشان را پس داده‌اند. لذا سعی کرده‌ام در جنبهٔ انسانی به حداقلِ نیاز متن بسنده کنم.*ساعت ۲:۰۰ صبح جمعه ۱۲ فرودین ۹۰، در حال راه انداختن getbazaar.com؛ عکس از حسام میرآرمندهیتا قبل اینکه از چهار پنج نفر بزرگ‌تر شویم، تقسیم کارها نسبتاً راحت بود:مصطفی: من رفتم سراغ جلالی تو تقویم.رضا: ایول. من برم سراغ فارسی تو SMS؟رضا: برم سراغ کلاینت بازار؟مصطفی: حله، منم رفتم سرور.مشکل وقتی شروع می‌شود که تعداد افراد متمرکز روی یک پروژه زیاد شده و لازم می‌شود که دو نفر همزمان روی یک چیز کار کنند؛ یک Feature، یک Codebase، یک ماژول، یک فایل، زبانم لال یک Class. مشکل اصلی هم نیاز به هماهنگی است، به Communication. و این نیاز به ارتباط به نوعی ستون متدولوژی‌های مختلف است. متدولوژی‌ها هم هر یک به نحوی ارتباطات اعضای تیم را سامان می‌دهند. Kanban سعی می‌کند با قوانینش نیاز به ارتباط در راستای تقسیم تسک را کم کند و Scrum هم جلسات مختلف مثل Sprint Planning و Daily Scrum، با اهداف مختلف در نظر گرفته است. انتخاب متدولوژی مناسب تیم کار خیلی راحتی نیست ولی می‌توانید از تجربه‌های فراوانِ موجود در جهان استفاده کنید.(پیشنهاد من اینست که برای ایده گرفتن به سراغ تیم‌هایی بروید که شباهت‌هایی با شما دارند؛ مشتری‌های مشابه‌ای دارند، ارزش‌های مشابه دارند، دغدغه‌هایشان مشترک است، ... شاید با کپی کردن از تیم‌های تجربه‌کرده حس کنید که شبیه میمونی شده‌اید که از دست زدن به موز می‌ترسد چون دوستانش او را از این کار ترسانده‌اند (بلانسبت!)، ولی احتمالش کمه که واقعاً در قفسی تحت نظر یه سری پژوهشگر مردم‌آزار (یا میمون‌آزار؟) باشیم؛ احتمالش خیلی بیشتر است که موز مورد بحث یک ایرادی داشته باشد که عزیز کهنه‌کار می‌گوید بهش دست نزن! البته که هر وقت فرصتش را پیدا کردید پیگیر دلیل پشت راهکارهای نسخهٔ مربوطه شوید، و اگر بعد کپی کردن هم احساس می‌کنید اوضاع خراب است و همین الانش هم رو سرتون سطل آب رو خالی کرده‌اند، دیگر چاره‌ای نیست! باید دست به کار بشوید و نسخهٔ خودتان را بپیچید).وقتی که تعداد تیم‌ها زیاد می‌شود، ارتباط بین تیم‌ها تبدیل به یک چالش می‌شود. اینجاست که متدولوژی‌ها هم تبدیل به موجودات عجیب و غریبی می‌شوند (مثل SAFe و LeSS) که چندان هم جوابشان را پس نداده‌اند و Case Study دندان‌گیری ازشان موجود نیست. اینجا یک مقدار پیدا کردن الگو سخت‌تر است و گریزی از Customization نیست. خوشبختانه در لایهٔ فنی اینقدر نظرات متنوع نیست. راهکارهای فنی نسبتاً مشابهی را می‌توانیم در شرکت‌های متفاوت ببینیم که Robust یا حتی Anti-Fragile هستند و مجموعه را برای تغییرات که ذات این صنعت است، چه در لایهٔ انسانی و چه در لایهٔ هدف و محصول، آماده می‌کنند. اولین تجربهٔ مرتبط ما در این فاز وقتی بود که تیم فنی بازار از دو تیم کلاینت (۴-۵ نفر) و سرور (۱۰-۱۱ نفر) تشکیل شده بود. چیزی که مشخصاً به یاد دارم تسک «کارت هدیه» است که در تیم کلاینت اولویت گرفته بود و پیاده شده بود ولی در تیم سرور بعد چندین هفته از اتمام پیاده‌سازیِ تیم کلاینت هنوز حتی وارد فهرست تسک‌های ایتریشن هم نشده بود. اینجا بود که رفتیم سراغ ساختارتکانی و بعد بررسی‌ها به این نتیجه رسیدیم که از اسپاتیفای الگو بگیریم. در آن زمان اسپاتیفای مقاله‌ای داشت به تاریخ دو سال قبلش که تیم‌بندی خود را توصیف کرده بود، و پست بلاگ تازه‌ای داشت که خیلی منطبق بر مقاله بود و این نشان می‌داد که ساختار مربوطه حداقل دو سال را دوام آورده است (برای دوستان ناآشنا به صنعت: دو سال در این صنعت خیلی است). خوبی دیگر مدل مربوطه این بود که اولاً توسط اسپاتیفای به اشکال ترتمیزی در موردش مطلب منتشر شده بود و لازم نبود به کامنت‌هایی از کارمندان تصادفی در مجموعه استناد کنیم. خوبی‌های دیگری هم داشت مثل اینکه از نظر ابعاد در حد یک صفر بیشتر با ما اختلاف تعداد نیروی فنی نداشت و همچنین اگر به جای Album می‌گفتیم Application و به جای Track می‌گفتیم Package، محصول فنی‌اش هم شبیه محصولمان می‌شد.خلاصهٔ ماجرا اینکه ساختار بازار تغییر می‌کند به چند تیم ارزش محور به جای تکنولوژی محور (تقریباً). بعد این تغییر بود که احساس کردیم که نیازهای فنی‌مان هم دارد تغییر می‌کند. بعدتر بود که در این مقاله از جناب Martin Fowler متوجه شدیم که این حس از کجا می‌آید: Conway s law. این عبارت قصار می‌گوید که در هر سازمانی که سیستم نرم‌افزاری در آن شکل می‌گیرد، طراحی کلان سیستم کپیِ ساختار ارتباطات سازمان مربوطه می‌شود. یعنی مثلاً اگر سازمان مربوطه تیم دیتابیس داشته باشد، خواهد دید که در معماری کلان سیستم‌اش روی تخته وایت‌بورد مجموعهٔ دیتابیس یک بخش مستقل از سیستم شده است.در این دوره مایکروسرویس برای ما معنی پیدا کرد. تیم‌های جدا که روی ارزش‌های بیزینسی تا حدی مستقل کار می‌کرده‌اند، طبیعتاً دوست دارند که کنترل بخش‌های مربوط به خودشان را در دست بگیرند. و روش فنی‌ای که آزمایشش را خوب پس داده بود جدا کردن سرویس‌ها و API دادن به مشتری/دیگر تیم‌ها و سرویس گرفتن از طریق API از دیگر تیم‌ها بود.نکتهٔ جالب مایکروسرویس این است که خیلی هم روی نحوهٔ تیم‌بندی حساس نیست. یعنی برای مثال سیستم‌های تیم‌های زیرساختی (که تا حدودی Technology-Based هستند) هم می‌توانند در کنار دیگر مایکروسرویس‌ها ایفای نقش کنند، البته به شرط اینکه خود را تأمین‌کنندهٔ خدمات/محصول ببینند و نه اینکه بخواهند در کار تیم‌های دیگر دخالت کنند.این مسیری بود که ما طی کردیم. بعدتر که این ارائهٔ فوق‌العاده از خانم Mary Poppendieck در مورد آیندهٔ نرم‌افزار را دیدم، متوجه شدم که مسیری که طی کرده بودیم کاملاً قابل پیش‌بینی بود و احتمالاً حداقل تا چند سال آتی هم این مسیر معقول بماند.اسلایدی از ارائهٔ خانم Mary Poppendieck در کنفرانس GOTO 2016 برلین. اگر تا الان خوب به منابعی که معرفی کرده بودم رجوع کرده باشید، اسم ایشان برایتان آشناست.توصیه‌های دست به نقدتا اینجای مقاله، اسمی از تکنولوژی خاصی نبرده‌ام. بدین ترتیب خیالم راحت است که تا چند سالی مطالب بالا هنوز معنی خواهند داشت. بدی این کار این است که برای خوانندهٔ دست به آچار این مطالب زیادی نظری است و چیزی برای ور رفتن و تست کردن و حس پیدا کردن به آدم نمی‌دهد. در ادامه می‌خواهم یک سری تجربه/توصیهٔ دست به نقد در راستای پیاده کردن تئوری‌های بالا مطرح کنم. از الان هشدار بدهم که ممکن است ترفندها و تکنولوژی‌هایی که مطرح می‌کنم در زمانی که این مطلب را می‌خوانید دیگر منقرض شده باشند.وقتی هنوز اول کار هستید: توصیه‌های دوگانه‌ای شده است که به سراغ مایکروسرویس بروید/نروید. به نظرم منطقیست که بپذیریم که مایکروسرویس برای وقتی که هنوز دارید MVP/MLP/MSP تان را تست می‌کنید بیشتر دست‌وپاگیر است تا ارزشمند. ولی در هر صورت پیشنهاد می‌کنم توصیهٔ بعدی را در همان زمان هم رعایت کنید.محل حمله به مسألهٔ شکستن: به نظر من API یکی از بهترین نقاط برای شکستن ابعاد فنی مسأله است، حتی برای وقتی که فقط دو نفر هستید. با تر تمیز مستند کردن API می‌شود نیاز به مکالمات غیر ضروری را کم کرد. و بهترین روش مستند کردن این است که از ابزاری استفاده کنید که لایهٔ ارتباطی کلاینت و سرور مربوطه را از روی API شما Generate می‌کند. بدین ترتیب مطمئن می‌شوید که API تان به خاطر تنبلی عزیزان و پیچاندن به‌روزکردن مستندات از اعبتار ساقط نمی‌شود. من به شخصه gRPC را خیلی می‌پسندم. هم ویژگی‌هایی که گفتم را دارد، و هم در لایهٔ فنی بسیار بهینه است؛ بارها کوچک‌تر و سریع‌تر از پروتکل‌های متنی‌ای مانند JSON API است. پروژهٔ gRPC عضوی از CNCF هم است که من از طرفدارانشان هستم ?.البته آخرش هم هر چقدر که مستند کنید باز اشتباه پیش می‌آید حتی در ناسا!وقتی که تعداد تیم‌هایتان شروع به زیاد شدن می‌کنند، رفتن به سراغ مایکروسرویس دیگر منطقی خواهد بود. منظورم از «رفتن» لزوماً یک Big Rewrite نیست؛ می‌توانید امکانات جدید را در سرویس‌های کوچک جدید پیاده کنید و صرفاً قسمت‌ها مربوط را از Monolith اولیه جدا کنید. برای مثال زمانی که در بازار به سراغ امکان In-app Billing رفتیم، امکانات مربوطه را در یک Codebase جدید پیاده کردیم و خرید اپلیکیشن از بازار را طوری تغییر دادیم که آن هم عملاً In-app Billing ای بود که در آن فروشنده خود اپ بازار بود. در زمان به آب انداختن این تغییرات، هر دو کد خرید قدیمی و تغییرات جدید در سورس کد سرور بازار بودند و صرفاً با یک Flag مشخص می‌شد که کدام کد فعال است. یکی دو هفته بعد اینکه سرویس جدید جواب خود را پس داد، کدهای خرید قدیمی را از کد سرور بازار حذف کردیم و بدین ترتیب Monolith قدیمی هم خودش در این پروسه کوچک‌تر شد و یک قدم به مایکروسرویس شدن نزدیک شد.در باب Big Rewrite این مقاله جالب است؛ می‌گوید که مشکل Rewrite در زمان مواجهه با کد کم‌کیفیت اینست که یک راه‌حل فنی برای یک مشکل فرهنگی است. از این نظر این مقاله را پیشنهاد می‌کنم که اگر انگیزهٔ شما هم از مهاجرت به مایکروسرویس صرفاً همین‌هایی باشد که این مقاله اشاره می‌کند، و نه برخواسته از نیاز سازمانتان به رشد تعداد تیم‌ها، شاید دارید مسیر اشتباهی می‌روید.ارتباطات بین مایکروسرویس‌ها را هم جدی بگیرید تا مثل ما دچار اسپاگتی‌ای از مایکروسرویس‌ها نشوید! روش‌های مختلفی برای ایجاد نظم در میان مایکروسرویس‌ها وجود دارد که چون کلیت موضوع جدید است هنوز هیچ‌کدام تبدیل به عرف نشده است. شخصاً روشی لایه‌بندی زیر را دوست دارم چون به نظرم چندان پیچیده و غریب نیست. در این روش شما لایه‌هایی تعریف می‌کنید که مایکروسرویس‌هایتان را افراز می‌کند، و چنین قانونی می‌گذارید که مایکروسرویس‌های هر لایه فقط می‌تواند به مایکروسرویس‌های لایهٔ پایینی درخواست دهد. هر زمان که لازم شد مایکروسرویسی درخواستی از مایکروسرویسی دیگر در لایهٔ خود و یا بالایی انجام دهد، این کار را از طریق Message Queue انجام دهد. این قوانین ساختگی باعث ایجاد نظمی در مایکروسرویس‌های شما می‌شود که در زمان پیدا کردن باگ باعث صرفه‌جویی در استفاده از کلمات ناپسند می‌گردد.از اسلایدهای ارائهٔ مدیر فنی Wunderlist در GOTO 2015 شیکاگوچنانچه شما هم از نوعی از لایه‌بندی استفاده می‌کنید، پیشنهاد من اینست که بالای هر لایه یک Load Balancer مینیمال قرار دهید که بتوانید از طریقش سرویس‌ها و قرادادهای سرویس‌ها را یک شکل مونیتور کنید، و به شما کمک کند که سرویس‌ها را High Available کنید، و همچنین مکانیسم Circuit Break پیاده کنید تا جلوی سرایت یک مشکل به دیگر سرویس‌ها را بگیرد.می‌توانید برای لایه‌های میانی ویژگی‌هایی که گفتم را در خود سرویس‌ها پیاده کنید تا نیازی به Load Balancer نباشد، ولی لایهٔ Edge متفاوت است. در اسلاید بالایی از ارائهٔ مدیر فنی Wunderlist در کنفرانس GOTO 2015 شیکاگو، Chad Fowler در مورد معماری‌ای** که برای مایکروسرویس کردن Wunderlist رسیدن صحبت کرده است. آن Smart Proxy به نوعی همان Load Balancer ای است که می‌خواهم در موردش صحبت کنم. ما در بازار به عنوان گام اول برای نظم‌دهی سرویس‌هایمان، برای همین نقطه یک Load Balancer نوشتیم که به کمک Middleware ها امکانات مورد نظر ما را فراهم می‌کرد. البته به خاطر اینکه به خاطر پرفورمنس پروتکل بازار در آن Embed شده بود، آنرا Open Source نکردیم.این Load Balancer به ما این امکان را داد که مایکروسرویس‌هایمان را واقعاً مینیمال درست کنیم. برای مثال وقتی درخواستی به Load Balancer ما می‌رسد، از میان Middlewareهای موجود می‌گذرد و بهش داده‌هایی اضافه می‌شود. برای مثال Authentication Middleware به داده‌های ورودی id کاربر را هم اضافه می‌کند و یا Metrics Middleware در زمان برگشت جواب از مایکروسرویس مربوطه، مدت زمان و کد جواب برگشتی را در سیستم مونیتورینگ شرکت ثبت می‌کند بدون آنکه لازم باشد هر کدام از این مایکروسرویس‌ها جداگانه احراز هویت و یا ارتباط با سیستم مونیتورینگ را پیاده کنند.این ابزار، که به خاطر عملکردش در ترجمهٔ API قدیم بازار به API جدید داخل ابر سرویس‌هایمان «دیلماج» نامیدیمش، بهمان کمک کرد که میانگین Latency یکی از سرویس‌هایمان را از 500ms به 50ms برسانیم، علی‌رغم اینکه یک Hop هم نسبت به حالت Monolithic اضافه شده بود.معماری تقریبی دیلماج، Load Balancer بازارقرارداد: گام بعدی در کم کردن نیاز به ارتباطات، و کم کردن سوء تفاهم‌ها، تعهد میزان در دسترس بودن سرویس‌ها توسط تیم‌هاست. بدون چنین تعهدی تیم‌ها نمی‌توانند از سرویس‌های تیم‌های دیگر استفاده کنند و سرویسی به کاربر نهایی ارائه بدهند که روی میزان کیفیتش اطمینان داشته باشند. در این موضوع فصل Service Level Objectives کتاب فوق‌العادهٔ Site Reliability Engineering را پیشنهاد می‌کنم. همچنین اخیراً این مقاله را دیدم که کمی فراتر رفته و تست API را هم در قرارداد می‌آورد.طولانی شد! شاید بعداً کمی بیشتر در مورد دیلماج بنویسم. در انتها می‌خواهم این ویدئو را معرفی کنم که خیلی سریع ده تا از مهم‌ترین چالش‌های مهاجرت به دنیای مایکروسرویس‌ها را مطرح می‌کند. در این مقاله به بعضی‌هایش اشاره کرده‌ام ولی مرورش ضرری ندارد.[*] در باب جنبهٔ انسانی موضوع، اگر علاقه دارید، به نظرم همچنان کتاب کلاسیک و پر عمق Peopleware: Productive Projects and Teams یکی از برترین‌های این موضوع است. هر چند در زمان نوشتنش هنوز Scrum و دیگر متدلوژی‌های اسم‌دار امروز معرفی نشده بودند، فصل مربوط به متدولوژی‌اش و تفاوت methodology با Big M Methodology اش کاملاً شما را به یاد بحث‌های امروزه در مورد متدولوژی‌های امروزه می‌اندازد. و البته راستش را بخواهید، فکر نکنم نویسندگان کتاب اگر نوشتهٔ درون پرانتز من در مورد کپی کردن متدولوژی را ببیند، خیلی خوششان بیاید! به هر حال هر کس نظری دارد.[**] شاید عبارت شهرسازی بهتر باشد، چرا که دیگر با مجموعه‌ای از نرم‌افزارها روبرو هستیم. رضا محمدی (قایقچی) رضا محمدی (قایقچی) Tue, 27 Feb 2018 02:01:45 +0330 https://virgool.io/@remohammadi/%D8%A7%DB%8C%D8%B1%D8%A7%D8%AF-%D8%AA%D9%84%DA%AF%D8%B1%D8%A7%D9%85-yua6ogme1t91 حدس می‌زنم که با اکثر شما در این موضوع هم‌نظرم که خواندن SMS هنگام رانندگی و برخورد با ماشین جلویی، یا سر نزدن به عزیزان، ایراد تلگرام (یا حداقل ایراد مختص به تلگرام) نیست. ولی مسأله اینه که تلگرام واقعاً زیاد استفاده می‌شود:بر اساس کمی بیش از ۴ میلیون ثانیه دیتا از اپ‌هایی که روی صفحه در حال استفاده بودند. تلگرام توسط هر ۱۵ دستگاه استفاده شده بود، ولی اون دو تا بازی هر کدوم فقط روی یک دستگاه استفاده شده بودند.این نمودار حاصل آخرین کاریست که در بازار انجام دادم، قبل آنکه خودم را بازنشست کنم؛ از همکارانم خواستم که اپی را نصب کنند که آمار استفاده از دیگر اپ‌ها را ذخیره می‌کند. طبیعتاً آمار بایاسی است و تعداد پایین ۱۵ دستگاه (که لبیک گفتند و به اندازهٔ حداقل یک هفته اپ را روی گوشی اندرویدی همراهشان نصب داشتند) اعتبار نتیجه را پایین‌تر هم می‌آورد. ولی حدس می‌زنم بایاس این آمار در مقایسه با جامعهٔ ایران در جهت مثبت نباشد چرا که ما داخل شرکت از Slack استفاده می‌کنیم و همچنین تنوع برنامه‌هایی که استفاده می‌کنیم احتمالاً بیشتر از میانگین جامعه باشد. با این توصیف ۳۳٫۵٪ سهم تلگرام را مقایسه کنید با سهم Instant Messengers از آمار استفاده از اپ‌های دستگاه‌های همراه در آمریکا:منبع: comScore ‏[۱]بدین ترتیب واضحه که وقتی در مورد تلگرام صحبت می‌کنیم، منظورمان فقط یک «پیام‌رسان» نیست. تلگرام با ارائهٔ ترکیبی از امکانات مثل گروه، اَبَرگروه، و کانال به نظرم تبدیل به یک شبکهٔ اجتماعی شده است. تأکیدم روی ترکیب از این لحاظ است که اپ‌هایی هستند که زیرمجموعه‌هایی از این امکانات را ارائه می‌دهند ولی هیچکدام اینطور توجه کاربر را به خود جلب نکرده‌اند. مثلاً کانال‌ها به تنهایی را می‌توان با اپ Medium و یا از زاویه دید دیگر با اپ Flipboard مقایسه کرد، که هیچکدام در نمودار مربوط به آمریکا سهم قابل توجهی ندارند. تلگرام منهای کانال هم تقریباً یک Instant Messenger استاندارد است و تکلیفش مشخص.خب! بر می‌گردیم به سؤال اول؛ ایرادش چیست؟همان امکاناتی که کاربران شبکه‌های اجتماعی را به خود مشغول نگه می‌دارند، به نوعی باعث مشکلاتی هم می‌شوند. وائل غنیم، کارمند گوگلی که قرار برگزاری راهپیمایی‌ای در فیس‌بوکش نهایتاً منجر به انقلاب مصر شد، ایرادات شبکه‌های اجتماعی را اینطور می‌شمارد: شایعات، تالار پژواک، تبدیل سریع گفتگو به مشاجره، انگیزه داشتن برای ابراز هر چه سریع‌تر عقیده‌مون در باب یک موضوع ترند شده، سخت شدن تغییر عقیده پس از انتشارش، و جهت دادن آدم‌ها به اطلاع‌رسانی در مقابل دریافت اطلاعات، پست در مقابل گفتگو، نظرات سطحی در مقابل مکالمات.۱۴ دقیقه در باب ایرادات شبکه‌های اجتماعی در متن تاریخ معاصر [۲]تلگرام به خاطر طراحی خاصش بعضی از این ایرادات را خفیف‌تر دارد و بعضی دیگر را جدی‌تر. به طور خاص به این خاطر که کاربر را از مرورگر و ابزارهای جستجو دورتر کرده است و همزمان به «فروارد» نزدیک‌تر، ممکن است شایعه در پلتفرم تلگرام مشکل جدی‌تری باشد. (البته مقایسهٔ کاملی نیست چرا که تجربهٔ استفادهٔ روزمره از مثلاً اَپ Facebook را ندارم. در مورد توییتر، به نظرم امکان ریتوییت همراه کامنت خودش یک مشوق بزرگ است برای مچ گرفتن ?! و البته تبدیل سریع گفتگو به مشاجره ?‍♂️)ولی ایراد گرفتن به تنهایی کارگشا نیست. اگر بخوایم عملگرا باشیم، باید در کنار ایراد راه‌حل و/یا جایگزین ارائه بدهیم. در مورد تلگرام با توجه به توضیحات بالا اصولاً جایگزین باید یک شبکهٔ اجتماعی دیگر (با امکاناتی نه چندان کمتر، سطح آزادی‌ای مشابه تلگرام، و اعتمادسازی‌ای قابل مقایسه با تلگرام) باشد، که خب گزینه‌های استخوان‌دار توسط «کارگروه تعیین مصادیق محتوای مجرمانه» قلع و قمع گشته‌اند. اصلاً حدس من اینه که اگر اینطور نبود، این ترکیب عجیب ولی جالب از پیام‌رسان شخصی، گروه‌های خانوادگی و هماهنگی سفر و سورپرایز تولد و ...، و کانال‌های خبری اینطور تبدیل به یک محصول پر استفاده نمی‌شد. تلگرام محصولی است که بر اساس نیازهای کاربرانش، که بخش بزرگی‌اش ایرانیان هستند، و البته با خلاقیت‌های تیم خالقش این‌گونه توسعه پیدا کرده است.از طرف دیگر ایرادهای ذکر شده کم و بیش برای همان استخوان‌دارها هم صادق است. جهان هنوز نیاز به خلاقیت‌هایی دارد که شبکه‌های اجتماعی را برای جامعه مفیدتر کنند و در عین حال از جذابیتش نکاهند. بدین ترتیب در این لحظه عاجزم از ارائهٔ راه‌حل/جایگزینی برای کاربر نهایی.خب! پس این همه پرحرفی از برای چه؟تلگرام، و کلاً هر interface ای که با اتکا به میزان بالای مشغول نگه داشتن کاربرانش وارد حیطه‌های مختلف می‌شود بالقوه یک تهدید برای کسب و کارهای آن حیطه‌هاست. برای کاربر نهایی؟ شاید! جلوتر بهش اشاره می‌کنم.این مقاله از دو عضو مؤسسهٔ Bloomberg Beta برای پیش‌بینی نحوهٔ استفادهٔ آیندگان از «یادگیری ماشین» از چارچوب جالبی استفاده کرده است: پیش‌بینی آینده براساس نحوهٔ زندگی و کار امروزِ مدیر عاملانِ ۵۰۰ شرکت برتر آمریکا (Fortune 500) که محدودیت منابع کمتری دارند، و لذا توانسته‌اند بدون توجه به effort به سراغ امکاناتی بروند که روی زندگی و کارشان impact واقعی داشته است.یک مدیر نوعی از این مجموعه یک مربی حرفه‌ای ورزش دارد، یک رانندهٔ منظم و مسلط دارد، یکی دو نفر دارد که رسانه‌ها را برایش مرور می‌کنند و کمک می‌کنند که در موضوعاتی که می‌خواهد با صرف وقت کم به‌روز باشد، یک سخنرانی‌نویس دارد، یکی دو وکیل قابل دارد، ... و در بعضی موارد هم یک رئیس ستاد دارد که این کارکنان را با هم هماهنگ می‌کند و به نوعی رابط بین آقای مدیر عامل و ستاد پشتببانی‌اش است. این افراد هر کدام مهارت‌های مختلفی دارند، و مرتبط به کاری که می‌کنند به اطلاعات مشخصی از این آقای مدیر هم دسترسی دارند.این مقاله چنین نتیجه‌گیری می‌کند که با احتمال خوبی در آینده هم در موضوعات مختلف agent های مختلفی (منظور از agent ساختار پشت صحنه‌ایست که کار را انجام می‌دهد؛ تأمین‌کننده؛ مثلاً سرویس فروش کالا که سفارش و آدرس می‌گیرد و کالا را می‌رساند) حضور داشته باشند و بعید است یک agent بیاید که جایگزین بقیهٔ کسب و کارها بشود ولی ممکن است Interface ای بیاید که مانند آقای رئیس ستاد رابط بین تعدادی (یا حتی همهٔ) agent ها و کاربر باشد.کمیک از xkcd ‏[۳]تبدیل شدن به چنان interface ای آرزوی خیلی از کسب و کارهای اینترنتی است؛ محصولی با لجستیک پایین و کنترل بالا روی تأمین‌کنندگان (agent ها). رسیدن به چنین جایگاهی البته کار آسانی نیست. در چین WeChat به نظر توانسته است چنین جایگاهی پیدا کند ولی در کشورهای غربی در این لحظه نمی‌توان با اطمینان چنین interface ای را نام برد که اقتداری مشابه WeChat داشته باشد. البته این موضوع مستقل از زمان نیست. برای مثال می‌توان گفت که در دنیای قبلِ Smartphone ها، سرویس جستجوی گوگل چنین نقشی را داشت. قبل آن مرورگر به نوعی چنین interface ای بود. iOS و به خصوص اندروید به نظرم تلاش‌هایی بود در همین راستا، ولی خاصیت سیستم عامل خوب این است که نسبت به سرویس‌ها خنثی باشد، و بدین ترتیب نقش interface را به طور مستقل نگرفتند. ولی دستیارهای گوشی همراه به وضوح در رقابت برای کسب چنین نقشی هستند. از طرف دیگر این رقابت خارج از قلمروی گوشی‌های همراه هم در جریان است. مثلاً در خانه‌ها Amazon Alexa و Google Home (و با تأخیر Apple HomePod) در رقابت برای به عهده گرفتن ارائهٔ خدمات لازم در خانه هستند. در شرق مدل WeChat را می‌توان در کرهٔ جنوبی هم دید: KakaoTalk توسط ۹۳٪ از مردم کره استفاده می‌شود؛ دوستی می‌گفت که تنها App ایست که از طریقش می‌توان App های دیگر را نصب کرد و با این حال در Google Play با اطلاع از این موضوع اجازهٔ انتشار پیدا کرده است.آیا چنین interface ای برای کاربر نهایی مفید است؟در این موضوع بحث است. برای مثال گوگل مجبور شده صفحهٔ نتایج جستجو برای محصولات را در اتحادیهٔ اروپا تغییر دهد تا از حکم اتحادیهٔ اروپا، که رکورد سنگینیِ جریمه را برای احکام مربوط به قوانین رقابت شکست، پیروی کند. این در حالیست که طراحی صفحهٔ مربوطه در کشورهای دیگر موردِ ایرادِ ضابطین قضایی‌شان قرار نگرفته است. حامد قدوسی در این پست به جنبه‌هایی از ساز و کار پویای کسب و کارهای دوسویه اشاره کرده است، که به نظرم برای چنان interface ای هم صادق است.کمیک از Oatmeal - اصل کمیک این بوده است که فیس‌بوک بعداً این پیغام پایینش را برای خالق اثر آورده [۴]مفید باشد یا نباشد، با توجه به مثال مدیر عامل‌های Fortune 500 می‌شود حدس زد که کاربران از چنین interface ای استقبال خواهند کرد. بدین ترتیب سؤالی که مطرح می‌شود این است که طی یکی دو سال آتی آیا کاربر ایرانی با یک interface مواجه خواهد بود و یا اینکه شاهد رقابت interface های مختلف در حیطه‌های مختلف خواهد بود؟حرکت اخیر تلگرام نشان می‌ده که تلگرام در راستای رسیدن به چنان جایگاهی بسیار جدی است. و البته سرمایه‌گذارانی هم که جذب کرده است به نظرم خبر از این دارد که احتمالاً توجه تیم تلگرام به ایران و کاربرانش بسیار کم خواهد شد تا بتوانند بدون تحریک دولت آمریکا کاربران (موجه‌تر؟!) بیشتری جذب کنند و به آن‌ها خدمات agentهای خود را همراه با دم‌دست‌ترین روش پرداخت عرضه کنند.اگر اینطور شود، جایگزینش در ایران چه سرویس یا سرویس‌هایی خواهد بود؟ آرزوی من اینست که نهادی آزاد، چیزی شبیه به W3C برای دنیای وب، این نقش را به عهده بگیرد. شاید در هفته‌های آتی بیشتر در مورد این آرزو بنویسم.لینک‌های زیر عکس‌ها:https://www.comscore.com/Insights/Presentations-and-Whitepapers/2017/The-2017-US-Mobile-App-Reporthttps://www.ted.com/talks/wael_ghonim_let_s_design_social_media_that_drives_real_change?language=fahttps://xkcd.com/1807/http://theoatmeal.com/comics/reaching_peopleوhttps://twitter.com/Oatmeal/status/923250055540219904 رضا محمدی (قایقچی) رضا محمدی (قایقچی) Sat, 27 Jan 2018 13:58:08 +0330