https://virgool.io/feed/@rahimian مدیر عامل استور اندرویدی مایکت | دانش آموخته نرم افزار دانشگاه صنعتی شریف fa 2026-04-15 04:34:27 https://files.virgool.io/upload/users/1589/avatar/vmzCWR.png?height=120&width=120 https://virgool.io/@rahimian https://virgool.io/@rahimian/whiteboard-coding-interview-guide-gywbcpdlpwa3 در مصاحبه‌های فنی، حل مساله برنامه‌نویسی روی وایت‌برد معمولا تاثیر زیادی در نتیجه مصاحبه داره. در این فرآیند یک سوال (معمولا الگوریتمی) از شما پرسیده میشه، و شما باید اون رو حل کنید و کدش رو روی وایت‌برد بنویسید. بعد هم تا حدی زمان‌اجراش رو تحلیل کنید. مثالی از این جور سوالات اینه: یک رشته از حروف به طول n به عنوان ورودی به شما داده شده. عناصرش رو به اندازه i واحد به سمت چپ شیفت بدید (آیتم‌هایی که از سمت چپ آرایه خارج می‌شن از سمت راست مجدد وارد میشن). زمان اجرا و حافظه مورد نیاز رو تا حد امکان بهینه کنید.سوالات whiteboard coding interview در اکثر شرکت‌های بزرگ پرسیده می‌شه، و بنابراین اگر جویای کار هستید توصیه‌م اینه که حتما روی این موضوع کار کنید. اما چند تا نکته برای موفق‌بودن توی حل اینجور سوالات:۱. سوال رو تکرار کنید. حتما سوال رو یک‌بار به بیان خودتون تکرار کنید تا مطمئن بشید شروع به حل یک مساله اشتباه نمی‌کنید. نگران نباشید، مصاحبه‌کننده زیادی عجله نداره. (Repeat)۲. قبل از حل مساله، سعی کنید با چند تا مثال، مساله رو دقیق‌تر بفهمید. این کار به شما زمان میده که بهتر هم در مورد راه حل فکر کنید. بعدا از همین مثال‌ها به عنوان test case استفاده خواهید کرد. (Example)۳. با ساده‌ترین راه‌حلی که به ذهنتون میرسه، و مستقل از زمان اجرا یا حافظه می‌تونه مساله رو حل کنه، شروع کنید. درست حل کردن مساله اولویت اول هست، بعدش بهینه کردن راه حل. پیچیده فکر نکنید. سعی کنید با روش‌هایی ساده‌ای مثل brute force، یا راه‌حل‌هایی از مرتبه زمانی بالا، یک راه حل درست برای مساله داشته باشید. (Approach)۴. با بهینه کردن راه‌حل اولیه، شروع به زدن کد کنید. در کد زدن سعی کنید از توابع استفاده کنید (مثلا CopyNthFirstElementsOfArray) به جای اینکه همه چیز رو از اول به صورت دقیق پیاده‌سازی کنید. اینجوری سریع‌تر به راه حل کلی می‌رسید، خیلی از اوقات هم مصاحبه‌کننده میگه نیازی به نوشتن توابع بدیهی برای چک کردن ورودی‌ها یا حالت‌های خطا یا ... نیست. (Code)۵. کدی که زدید رو با ورودی‌های نمونه، تست کنید. سعی کنید ورودی‌هایی انتخاب کنید که زمان خیلی زیادی برای شبیه‌سازی اجراش وجود نداشته باشه (مثلا شامل ۱۰۰ تا آیتم نباشه)، اما ترجیح اینه که تا حد امکان حالت‌های بیشتری رو پوشش بده (مثلا تکراری بودن مقادیر در آرایه). تست‌کردن ممکنه به اصلاح بعضی قسمت‌های کدتون منجر بشه، پس کد اولیه رو ترجیحا یه مقدار باز باز بنویسید تا بشه بین خط‌های کد، یه تغییر کوچیک ایجاد کرد (Test)۶. راه‌حل تون رو بهینه کنید (از لحاظ زمان اجرا و حافظه). اگر گام‌های قبلی رو خوب رفته باشید، اینجا با مصاحبه کننده دوست شدید و معمولا نیازی به بهینه‌سازی کد نیست (صرفا ایده‌ها مطرح میشه). معمولا یه راه‌حل بهینه‌تر برای مساله وجود داره، و بعضا حتی ایده‌داشتن در مورد اینکه روی چه چیزی باید کار کرد هم نکته مثبتی هست (Optimize)امیدوارم که مصاحبه‌های خوبی داشته باشید :)پ.ن. ۱: اگر حروف اول گام‌ها رو به هم بچسبونید، میشه REACTO. این رو به خاطر بسپرید.پ.ن. ۲: اگر دوست داشتید با آدم‌های قوی روی مساله‌های واقعی جذاب کار کنید، رزومه‌تون رو برای ما در مایکت هم بفرستید (https://myket.ir/jobs).پ.ن. ۳: اگر حوصله داشتید مساله نمونه (شیفت دادن آرایه به طول n به سمت چپ، به اندازه i واحد) رو در زمان اجرای O(n) و با استفاده از چند واحد ثابت حافظه اضافی حل کنید. وحید رحیمیان وحید رحیمیان Sun, 06 Feb 2022 09:22:50 +0330 https://virgool.io/@rahimian/sopa-act-in-united-states-gtiomquebxgz طرح صیانت قرار بود چند سال پیش در آمریکا هم اجرا بشه! تقریبا ۱۰ سال پیش در چنین روزهایی، قانونی در آمریکا پیشنهاد شد که شباهت‌های زیادی با طرح صیانت خودمون داشت. قانون SOPA (Stop-Online-Piracy-Act) که با هدف مبارزه با نقض کپی‌رایت پیشنهاد شده بود، به حکومت آمریکا اجازه می‌داد که اگر سایتی حتی در یک صفحه‌ش محتوای ناقض کپی‌رایت داشت، کل اون سایت رو از نتایج موتورهای جستجو حذف کنه و دسترسی به آدرس اون سایت رو در ISP ها مسدود کنه (به اصطلاح خودمون فیلتر بشه!)جالبه که هدف SOPA هم دقیقا فیلتر کردن سایت‌های خارجی بود، چون قوانین آمریکا لزوما روی سایت‌های خارج از آمریکا اعمال نمیشه و بنابراین خیلی سخت‌تر میشه با اونها برخورد قضایی کرد.این طرح در صورت تصویب اجازه می‌داد که در صورت وجود تنها یک پرونده نقض کپی‌رایت، کل سایت فیلتر بشه و از نتایج گوگل هم حذف بشه. این طرح یه جورایی مبارزه شرکت‌های رسانه‌ای سنتی آمریکا با گسترش اینترنت (و در نتیجه کم شدن منافع تجاری‌شون) بود.مخالفان طرح SOPA‌ خیلی سریع متوجه شدن که هدف نهایی این طرح، نابود کردن کل اینترنت هست، اگر چه شعارش مبارزه با کپی غیر قانونی فیلم و موسیقی بود. اونها شروع به برگزاری کمپین‌هایی کردن که به مردم اطلاع بدن این طرح در مورد کپی‌رایت نیست، بلکه در مورد آزادی ارتباطات در فضای مجازی هست. اونها این طرح رو مخالف قانون اساسی آمریکا می‌دونستند.در ابتدای پیشنهاد قانون SOPA، حدود ۴۰ سناتور آمریکایی جزو پیشنهاد دهندگان این طرح بودند، و خیلی سخت به نظر میومد که این قانون تصویب نشه.اما اعتراض‌ها در آمریکا بالا گرفت. گوگل یک روز لوگوی خودش رو با یک صفحه سیاه پوشاند تا جلوی سانسور شدن اینترنت رو بگیره. ویکی‌پدیا هم برای ۲۴ ساعت در دسترسی کاربران به تمام صفحات‌ش، در یک صفحه سیاه نوشت در صورت تصویب این طرح، آینده اینترنت سیاه خواهد بود. سایت ردیت هم همین کار رو کرد.در نهایت نمایندگان مجلس سنای آمریکا صدای مردم‌شون رو شنیدن و نهایتا این قانون در آمریکا تصویب نشد. امیدواریم نمایندگان مجلس ایران هم صدای مردم و کسب‌وکارهای ایرانی رو بشنوند.پ.ن. اگر در مورد این طرح خواستید بیشتر بدونید اینها رو ببینید:https://en.wikipedia.org/wiki/Stop_Online_Piracy_Acthttps://en.wikipedia.org/wiki/Protests_against_SOPA_and_PIPA وحید رحیمیان وحید رحیمیان Wed, 03 Nov 2021 20:27:31 +0330 https://virgool.io/@rahimian/database-design-a-quick-guide-epzkvtd5tyh5 معمولا برای انتخاب دیتابیس وقت زیادی نمی‌زاریم و بعدا همین وقت رو در تغییرات دیتا یا کد میزاریم.دیتابیس‌ها در نرم‌افزار نقش مهمی دارند. هم سرعت نرم‌افزار معمولا متناسب با سرعت ذخیره و بازیابی داده‌هاست، هم مواردی مثل تغییرپذیری نرم‌افزار و قابلیت اجرا در محیط‌های توزیع شده به انتخاب دیتابیس وابستگی جدی داره. در عین حال بسیاری از توسعه‌دهندگان صرفا تعداد محدودی (بعضا صرفا یک عدد) دیتابیس رو می‌شناسند و بنابراین در نوشتن هر سیستمی، یک دیتابیس یکسان را انتخاب می‌کنند. در حالی که دیتابیس‌های مختلفی برای شرایط متفاوت وجود دارند که شناخت اون‌ها به مهندس نرم‌افزار کمک می‌کنه سیستم بهتری رو طراحی و پیاده‌سازی کنه.تکنیک‌های مختلفی در دیتابیس‌ها وجود داره (مثل Sharding، Replication، Storage Management و Query Processing) که قابلیت‌های مختلف وظیفه‌ای و غیروظیفه‌ای به ما میده. پشتیبانی دیتابیس‌های مختلف در ارائه این قابلیت‌ها یکسان نیست.شکل زیر یک راهنمای خیلی ساده و سریع برای انتخاب دیتابیس بر اساس ویژگی‌های سیستم است: وحید رحیمیان وحید رحیمیان Sun, 22 Aug 2021 17:31:24 +0430 https://virgool.io/@rahimian/api-design-basics-rest-vs-grpc-vs-graphql-cngst2dbpx1y طراحی واسط‌های برنامه‌نویسی (API Design)، هم در ارتباط کلاینت‌ها و سرور، و هم در ارتباط زیرسیستمهای مختلف (به ویژه در معماری مایکروسرویس) نقش مهمی دارد. طراحی ارتباط بین سیستم‌های نرم‌افزاری بخش مهمی از طراحی نرم‌افزار است که می‌تواند موجب بهبود خوانایی کد، آسانی استفاده از سرویس، بهبود امنیت، و همچنین بهبود قابلیت تغییرپذیری و نگهداشت نرم‌افزار شود.معمولا پس از انتخاب معماری کلی سیستم، طراحی API یکی از گامهای مهم در شکستن یک سیستم بزرگ نرم‌افزاری به زیر سیستم‌هاست که موجب میشود افراد یا تیمهای مختلف بتوانند روی تولید زیرسیستمها کار کنند.اکثر سیستمهای امروزی از REST برای ارتباط شبکه‌ای استفاده میکنند؛ در عین حال پروتکل قدیمی SOAP نیز همچنان استفاده میشود و پروتکلهای مدرنتری مانند GraphQL و gRPC نیز در برخی کاربردها مناسبتر هستند.در طراحی پروتکل REST، استفاده از استانداردهای طراحی بسیار توصیه می‌شود: مواردی مانند استفاده مناسب از HTTP Verb ها، روش‌های استاندارد Sort و Filter، نسخه گذاری (Versioning) و استفاده از مکانیزم Partial Response را هر برنامه‌نویسی باید بشناسد.این موضوعات رو اخیرا در درس تحلیل و طراحی برای دانشجویان ارائه دادم. اسلایدهای درس را اینجا هم میذارم، شاید مفید باشه.https://www.slideshare.net/rahimian_vahid/api-design-a-quick-guide-to-rest-soap-grpc-and-grapgql-by-vahid-rahimian وحید رحیمیان وحید رحیمیان Sun, 22 Aug 2021 17:28:38 +0430 https://virgool.io/@rahimian/devops-from-theory-to-practive-wqqluew8znem بیشتر ما دواپس (DevOps) را با ابزارهای Automation می‌شناسیم. اینکه هر چیز را تبدیل به کد کنیم (Code Everything) و در این میان حتما پیکربندی سرورها را باید با کد مدیریت کنیم (Infrastructure as Code). ابزارهای Automation مانند Ansible و Chef و Puppet این روزها جزئی از ابزارهای توسعه اکثر تیم‌های نرم‌افزاری هستند.دواپس (DevOps) موضوعی است که این روزها زیاد از آن می‌شنوید. اینکه چرا به وجود آمده است، ریشه در مشکلات سنتی تیم‌های توسعه (Dev)و عملیات (Ops)دارد. چون تیم‌های توسعه علاقه‌مند به استقرار سریع کدهای خود هستند (تا باگ‌ها را سریع‌تر بشناسند) اما تیم‌های عملیات ترجیح می‌دهند به چیزی که کار می‌کند دست نزنند. دواپس ارتباط نزدیکی با اصول چابکی (Agile Principles)‌ دارد.در DevOps معمولا چندین موضوع مورد توجه قرار می‌گیرند:Configuration ManagementInfrastructure as CodeRelease ManagementContinuous Integration / Continuous DeliveryTest AutomationApplication Performance Monitoringدواپس (در واقع ارتباط تیم‌های Dev و Ops) پیاده‌سازی‌های مختلفی دارند که یکی از معروف‌ترین آنها، به کار گرفتن یک تیم زیرساختی به نام SRE یا Site Reliability Engineering‌، در کنار تیم DevOps است؛ مدلی که در گوگل ابداع شده است. اما مدل‌های دیگری هم وجود دارند. برخی از این پیاده‌سازی‌ها در شکل زیر نمایش داده شده اند:این موضوعات رو اخیرا در درس تحلیل و طراحی برای دانشجویان ارائه دادم. اسلایدهای درس را اینجا هم میذارم، شاید مفید باشه. https://www.slideshare.net/rahimian_vahid/dev-ops-from-theory-to-practice-by-vahid-rahimian https://www.slideshare.net/rahimian_vahid/dev-ops-from-theory-to-practice-by-vahid-rahimian وحید رحیمیان وحید رحیمیان Sun, 22 Aug 2021 17:14:46 +0430 https://virgool.io/@rahimian/cafe-bazaar-forces-developers-not-to-publish-on-myket-t2ibrfootb8v دیروز بازی تخته باز (تخته نرد آنلاین) به درخواست توسعه دهنده (تیم آرمیک) در مایکت غیر فعال شد. این بازی در ۲۱ اسفند ۹۸ در مایکت قرار گرفت و طی فقط ۲۴ روز توسط ۳۱ هزار کاربر مایکت نصب شد. نیازی نیست در صنعت بازی باشید تا متوجه ارزش جذب این تعداد کاربر در این زمان کوتاه شوید. دلیل این درخواست نامتعارف سازنده بازی، شرط کافه بازار برای پروموت کردن این بازی در صفحه اول خود بود. بر اساس قاعده ای که به صورت شفاهی توسط کافه بازار به توسعه دهندگان ایرانی اجبار می‌شود، اگر بازی ای بخواهد در صفحه اول کافه بازار قرار بگیرد، باید حداقل ۶ ماه در استور اندرویدی ایرانی دیگری (بخوانید مایکت) منتشر نشود. این شرط مستقل از کیفیت بازی، علاقه کاربران، یا آمار فروش بازی است.البته این اولین بار نیست که کافه بازار دست به چنین اقداماتی می زند. برنامه ها و بازی های زیادی، دلیل قرار ندادن برنامه شون در مایکت رو تهدید کافه بازار عنوان میکنن. در حالی که تحقیقات نشان داده است که با انتشار در استورهای مختلف، درآمد افزایش پیدا می‌کند؛ به عنوان نمونه این نوشته را ببینید.با انتشار بازی در استورهای بیشتر، درآمد افزایش می یابدبا انتشار بازی در استورهای بیشتر، درآمد افزایش می یابدبه نظر می‌رسد که امکانات کافه بازار برای کاربران و توسعه دهندگان آنقدر جذاب نیست که با انتشار همزمان یک برنامه یا بازی در کافه بازار و مایکت، برنده ماجرا از قبل مشخص باشد.در عین حال ژست رقابت پذیری کافه بازار در فضای مجازی جالب توجه است. وقتی در سال ۹۸ شایعه فیلتر شدن گوگل پلی مطرح شد، کافه بازار ادعا کرد که همواره با هر گونه محدودیتی مخالف بوده است. امین امیرشریفی، مدیرعامل کافه‌بازار، ساعتی پس از پخش این شایعه، مخالفت خود را با هر گونه محدودیت برای رقبا اعلام کرد و در توییت خود نوشت: «کافه بازار ۸ سال در کنار پلی استور گوگل رشد کرد و با ایجاد مزیت هایی روی محتوای بومی و پرداخت، در کنار محدودیت‌ های محتوایی و نداشتن امکان نصب پیش فرض و دسترسی های سیستمی، توانست ۴۰ میلیون کاربر را با خود همراه کند، و امروز هم از فیلترینگ رقیبش حمایت نمی‌کند».این گونه انحصار طلبی کافه بازار، در شرایطی که بیش از ۷۰ درصد مارکت اندروید کشور را در اختیار دارد، یکی از بدوی ترین روش های لطمه زدن به رقیب هست که در اکثر نقاط دنیا منسوخ شده است؛ اما به نظر می رسد در ایران که خلأهای قانونی زیادی در فضای کسب و کارهای مجازی وجود دارد، هنوز موثرترین روش رقابت در تیم کافه بازار هست. در جایی مثل آمریکا قوانین antitrust به شرکت ها اجازه انجام چنین کارهایی را نمی دهد.نظر شما چیست؟ آیا موافق این رفتار هستید؟ آیا ایده ای در راستای برخورد قانونی یا صنفی با این نوع انحصار طلبی ها دارید؟ وحید رحیمیان وحید رحیمیان Sun, 05 Apr 2020 17:01:11 +0430