نوشته های سعید مقدم

حل یک مسئله به روش یک طراح محصول

سعید مقدم — Sun, 20 Sep 2026 21:39:47 +0330

این مسئله فقط اتصال دو API نبود؛ ساختن یک فرایند همگام‌سازی قابل‌مشاهده، تکرارپذیر، کنترل‌شده و قابل‌بازیابی بود.طراح محصول در حال حل مسئه با وایب کدینگموضوع از جایی شروع شد که یکی از مشتریام یه مشکل رو واسم مطرح کرد که راهنماییش کنم. از بهینه کردن یک فرایند تکراری به پیشنهاد سیستم حسابداری رسیدیم و در نهایت به حل یک مسئله دیگه و نامرتبط و اتصال دو سرویس که هردو API ارائه میدادن ولی هیچکدوم ساختار خواندن و ارتباط با API دیگری رو نداشتن.واسه خودم جالب بود که حلش کنم، یک مسئله که واسه من ساده بود ولی تجربه عمیقی روش نداشتم و ذهن کنجکاوم دوست داشت انجامش بده چون ازون چالش هایی بود که وایب کد نویسی رو در من زنده میکرد.خلاصه داستاناین پروژه با یک درخواست ظاهراً ساده شروع شد: اطلاعات محصولات از نرم‌افزار حسابداری محک به یک فروشگاه مبتنی بر میکسین منتقل شود.اما اتصال مستقیم دو API کافی نبود. مدل داده‌ها با یکدیگر هم‌خوانی نداشت، رفتار واقعی بعضی endpointها با مستندات متفاوت بود، واحد قیمت میان دو سیستم فرق می‌کرد و یک خطای کوچک می‌توانست محصول تکراری، قیمت اشتباه یا از دست‌رفتن وضعیت همگام‌سازی ایجاد کند.راه‌حل، یک Bridge سبک و مستقل بود که داده‌های محک را دریافت، نرمال‌سازی و اعتبارسنجی می‌کند و سپس با guardهای کنترلی به میکسین می‌فرستد. این سرویس با PHP و SQLite ساخته شد تا روی زیرساخت موجود و کم‌منبع اجرا شود و برای عملیات روزمره به سرویس‌های سنگین دیگری وابسته نباشد.نتیجه پایلوت، انتقال و تأیید چهار محصول واقعی همراه با نام، قیمت، موجودی، دسته‌بندی و تصویر بود. اجرای عمومی بعدی هر چهار محصول را بدون ساخت رکورد تکراری به‌روزرسانی کرد و اجرای افزایشی پس از آن، به‌درستی هیچ داده بدون تغییری را دوباره پردازش نکرد.تعریف مسئلهمحک و میکسین دو مدل متفاوت از «محصول» داشتند. برای رسیدن از داده خام حسابداری به محصول قابل‌نمایش در فروشگاه باید چند موجودیت محک به یکدیگر متصل می‌شدند:Product و ProductDetail برای هویت و مشخصات کالاVisitorProduct برای قیمت و موجودی مرتبط با سایتProductCategory برای طبقه‌بندیPhotoGallery و Picture برای تصویر اصلیدر کنار این تفاوت ساختاری، چند ابهام پرریسک هم وجود داشت:مستندات محک endpointهای V2 را نشان می‌دادند، اما پشتیبانی توصیه کرد از نسخه‌های بدون V2 استفاده شود.تا زمانی که کالاها از داخل فرایند «بازارا» برای سایت ارسال نمی‌شدند، API مجموعه محصولات را خالی برمی‌گرداند.قیمت VisitorProduct در داده واقعی صفر بود و قیمت معتبر باید از ProductDetail.Price1 خوانده می‌شد.قیمت‌های محک در محیط آزمایش‌شده ریال و قیمت‌های میکسین تومان بودند.دسته‌بندی در OpenAPI میکسین ظاهراً اختیاری بود، اما API واقعی ایجاد محصول بدون دسته را با خطای 400 رد کرد.retry کردن کورکورانه درخواست‌های ایجاد محصول یا تصویر می‌توانست duplicate بسازد.بنابراین مسئله اصلی فقط «انتقال داده» نبود؛ باید فرایندی ساخته می‌شد که پیش از نوشتن قابل بررسی باشد، اجرای تکراری آن رکورد اضافه نسازد و در صورت شکست، وضعیت داده‌ها را گم نکند.نقشی که برای خودم تعریف کردممن صاحب مسئله و تصمیم‌گیر فنی پروژه بودم و استقرار و کنترل کیفیت عملی را نیز انجام دادم. مسئولیت‌های من شامل این موارد بود:تعریف scope، محدودیت‌های زیرساخت و سطح قابل‌قبول ریسکبررسی مستندات و پیگیری ابهام endpointها با پشتیبانی محکانتخاب معماری سبک PHP و SQLiteآماده‌سازی محیط سرور، تنظیمات، دسترسی‌ها و استقراراجرای diagnosticها و تست‌ها روی APIهای واقعیمقایسه قیمت، موجودی، دسته‌بندی و تصویر با رابط‌های واقعی دو سیستمکنترل مرحله‌ای مجوزهای نوشتن و تهیه backup قبل از اجرای عمومیتأیید تجربه و اطلاعات موردنیاز داشبورد فارسیبازبینی مستندات و حذف اطلاعات خصوصی پیش از انتشار عمومیبرای تحلیل، پیاده‌سازی و مستندسازی از Codex استفاده کردم. Codex ساختار کد، clientها، mapperها، guardها، تست‌ها و داشبورد را تحت هدایت من تولید و اصلاح کرد؛ تصمیم‌های کسب‌وکاری، اجرای production و تأیید نهایی خروجی‌ها بر عهده من بود.رویکرد۱. ابتدا مشاهده، سپس نوشتنسیستم به‌صورت پیش‌فرض در حالت dry-run طراحی شد. هر payload پیش از ایجاد تغییر در فروشگاه قابل مشاهده بود و نوشتن تک‌محصولی تنها با یک مجوز موقت جداگانه فعال می‌شد.این رویکرد امکان داد قیمت، موجودی، نام و دسته‌بندی را ابتدا با داده واقعی مقایسه کنیم و دامنه هر آزمایش را به یک رکورد محدود نگه داریم.۲. همگام‌سازی افزایشی به‌جای دریافت کاملمحک برای موجودیت‌های مختلف RowVersion مستقل ارائه می‌کرد. Bridge آخرین checkpoint موفق هر موجودیت را در SQLite نگه می‌دارد و فقط تغییرات جدید را درخواست می‌کند.checkpoint تنها پس از پایان موفق اجرا جلو می‌رود. در نتیجه، شکست میانی باعث نمی‌شود تغییرات دریافت‌نشده در اجرای بعدی ناپدید شوند.۳. snapshot محلی برای join قابل‌اعتمادچون ممکن بود فقط یکی از موجودیت‌های مرتبط تغییر کند، تکیه بر پاسخ همان اجرای API کافی نبود. snapshot آخرین نسخه هر موجودیت در SQLite ذخیره شد تا join محصول، جزئیات، قیمت، موجودی و تصویر حتی در اجرای افزایشی کامل باقی بماند.۴. نگاشت پایدار شناسه‌هاهر ProductDetail محک به شناسه محصول ساخته‌شده در میکسین نگاشت شد. Bridge با کمک این mapping تشخیص می‌دهد که باید رکورد جدید بسازد یا محصول قبلی را به‌روزرسانی کند.این تصمیم، وابستگی خطرناک به جست‌وجوی نام محصول را حذف و اجرای تکراری را idempotent کرد.۵. نوشتن و rollback محافظت‌شدهبرای smoke test، محصولی قابل‌شناسایی با موجودی صفر و وضعیت غیرفعال ساخته شد. حذف تنها زمانی مجاز بود که marker و مالکیت رکورد تأیید شوند. ایجاد موفق بود، رکورد دوباره خوانده شد و سپس با موفقیت حذف شد.برای محصولات واقعی نیز preview، apply و انتقال تصویر از یکدیگر جدا شدند. درخواست‌های امن در خطاهای موقت retry می‌شوند، اما create محصول و تصویر کورکورانه تکرار نمی‌شوند؛ چون timeout ممکن است پس از ایجاد موفق اما پیش از دریافت پاسخ رخ داده باشد.۶. داشبورد کم‌ریسک برای عملیاتیک داشبورد فارسی و read-only ساخته شد تا وضعیت Bridge، اتصال APIها، تعداد mappingها، checkpointها و تاریخچه اجرا را نمایش دهد.داشبورد عمداً امکان اجرای sync یا تغییر تنظیمات ندارد. وضعیت APIها نیز فقط با refresh دستی بررسی می‌شود تا بازشدن صفحه باعث ایجاد درخواست غیرضروری به سرویس‌های خارجی نشود.مسیر آزمون و تکرارفرایند به‌جای یک انتشار بزرگ، در چند مرحله محدود پیش رفت:تأیید اتصال و authentication هر دو APIاجرای diagnostic فقط‌خواندنی روی داده‌های محکاصلاح endpointها، casing شناسه‌ها و منطق fallback قیمتاجرای dry-run برای چهار محصولایجاد، خواندن و حذف یک محصول آزمایشی محافظت‌شده در میکسینانتقال اولین محصول واقعی و بررسی دستی قیمت و موجودیانتقال تصویر همان محصول و آزمایش duplicate guardانتقال سه محصول و تصویر باقی‌ماندهتهیه backup و اجرای sync عمومیاجرای مجدد dry-run برای تأیید checkpoint و جلوگیری از پردازش تکراریتست‌های خودکار مواردی مانند تبدیل ریال به تومان، fallback قیمت، موجودی صفر، پاسخ‌های PascalCase، شناسه‌های عددی، نرمال‌سازی نام فارسی، تشخیص فرمت تصویر، persistence در SQLite و ایمنی محصول آزمایشی را پوشش دادند.نتیجه ثبت‌شده روی سرور:10 tests · 0 skipped · 0 failuresنتیجهدر پایلوت production:چهار محصول واقعی به میکسین منتقل شدند.چهار تصویر اصلی بدون duplicate ثبت شدند.نام، قیمت، موجودی، دسته‌بندی و شناسه‌های مرجع کنترل شدند.اولین اجرای عمومی، هر چهار mapping موجود را update کرد و محصول جدید تکراری نساخت.اجرای افزایشی بعدی صفر رکورد جدید دریافت کرد؛ یعنی checkpoint تغییرات بدون تکرار عمل کرد.Production run: 4 received · 0 created · 4 updated · 0 skipped Next incremental dry-run: 0 received · 0 created · 0 updatedاین پروژه هنوز مدرکی برای ادعای افزایش فروش یا صرفه‌جویی زمانی ندارد. موفقیت مرحله فعلی با معیارهای فنی سنجیده شد: صحت داده، جلوگیری از duplicate، قابلیت مشاهده، کنترل نوشتن و امکان بازیابی.محدودیت‌ها و ادامه مسیرنسخه فعلی بر همگام‌سازی محصول از محک به میکسین تمرکز دارد. انتقال مشتری، آدرس، سفارش و پرداخت هنوز فعال نشده است. همچنین قواعد variant، حذف یا غیرفعال‌سازی محصول، reconcile کاتالوگ قبلی و alerting اجرای زمان‌بندی‌شده به تصمیم و تست بیشتر نیاز دارند.گام بعدی منطقی، تثبیت عملیات production است: تأیید scheduler و alerting، کامل‌کردن نگاشت دسته‌ها، طراحی reconcile بر پایه external ID و سپس تعریف قواعد کسب‌وکاری سفارش و مشتری در یک محیط staging.آموخته‌هامستندات API نقطه شروع‌اند، نه حقیقت نهاییرفتار runtime، داده واقعی و پاسخ پشتیبانی در چند نقطه با برداشت اولیه از OpenAPI متفاوت بود. هر فرض مهم باید با یک آزمایش کوچک و قابل‌بازگشت تأیید شود.idempotency فقط retry نیستبرای جلوگیری واقعی از duplicate به mapping پایدار، checkpoint، snapshot، lock، ownership marker و سیاست retry مناسب نیاز بود.نقش انسان در توسعه AI-assisted، کنترل تصمیم و ریسک استسرعت تولید کد با AI بالا بود، اما اعتمادپذیری از اجرای مرحله‌ای، مقایسه با رابط واقعی، محدودکردن مجوزها و بازبینی نتایج به دست آمد. مهم‌ترین خروجی من فقط کد نبود؛ ساختن یک فرایند تصمیم‌گیری و اعتبارسنجی بود که اجازه نمی‌داد سرعت، جای ایمنی را بگیرد.سورس و مستندات کامل این پروژه در گیت هاب

داستان نویسی ایده بابا یاب

سعید مقدم — Sun, 23 Aug 2026 15:11:15 +0330

بابا یاب یه ایده بود که چطوری بابام رو پیدا کنم و ساختمشکاور برنامه با هوش مصنوعی و عکس بابام ساخته شدهامروز به یک چالش خوردم ، با بابام تماس میگرفتم تلفنش زنگ میخورد ولی پاسخ نمیداد.دقیقا چی شده؟ آخرین بار کجا بوده؟ الان تقریباً کجاست؟ آیا باید نگران شوم یا نه؟همون موقع داشتم فکر میکردم کاش یه اپ درست میکردم و روی گوشی بابام نصب میکردم که حداقل الان لوکیشنش رو بهم میداد.خداروشکر الان که دیگه پیداش شد ولی میخوام برای دفعه بعدی به این قضیه فکر نکنم و مشکل رو حل کرده باشم.چرا دنبال بابام بودم؟ : چون سنش رفته بالا ، گوشاش سنگین شده ، کمی از لحاظ هوش و حواس تواناییش کم شده و به دلیل سکته های متعدد قلبی و مغزی قوای جسمی ضعیفی داره و همه این موارد باعث میشه که هر زمان از خونه میره بیرون نگران سلامتیش باشم.اول باید ایده رو بررسی میکردم ، جوانب مشکل رو میسنجیدم و تحقیق رو شروع میکردم.راه حل های پیدا کردن بابام چی میتونه باشه؟ چه محدودیت هایی داریم ؟ چه ابزارها و امکاناتی داریم ؟ بقیه چی ساختن ؟ و در کل به دید یک ایده چقدر ارزش بررسی داره ؟مثل همیشه اول رفتم سراغ خداوندگار دوست داشتنی جناب جی پی تیو نتیجه جستجوهای اولیه:راه‌ حل مناسب برای چیزی که به تو می‌دهد ضعف اصلی Google Maps Location Sharing Android/iPhone لوکیشن اخیر، وضعیت باتری و شارژ، Location Sharing دائمی بیشتر یک feature داخل Maps است تا safety product Apple Find My / Family Sharing خانواده تماماً Apple لوکیشن افراد و کمک به پیدا کردن دستگاه اعضای خانواده اکوسیستم Apple Life360 خانواده Real-time location، battery، places، crash/SOS و حتی No-show alerts محصول نسبتاً سنگین، بخشی از امکانات پولی/منطقه‌ای OwnTracks کاربر فنی/privacy-consciousOpen-source، self-hosted ، کنترل داده UX برای والدین عادی پیچیده است Traccar فنی / self-hosted سیستم کامل GPS tracking + server + apps + API بیشتر حس ابزار tracking دارد تا consumer family app(بررسی ها عمومی بدون در نظر گرفتن موقعیت جغرافیایی زیر سایه ننگ های اجباری)برای همین نیاز امروزت، Google Maps از چیزی که شاید فکر می‌کردی کامل‌تر است ولی آیا جواب میده ؟!Google Maps اجازه می‌دهد شخص Location Sharing را روی Until you turn this off بگذارد. بعد تو می‌توانی recent location گوشی، میزان باتری و اینکه در حال شارژ هست یا نه را ببینی. حتی notification ورود/خروج از مکان هم وجود دارد.اگر پدرت iPhone دارد، Family Sharing + Find My تقریباً همان safety net پایه را می‌دهد و اعضای خانواده می‌توانند دستگاه‌های همدیگر را در Find My پیدا کنندنزدیک‌ترین محصول به چیزی که امروز در ذهنت آمد: Life360جالب اینجاست که Life360 الان رسماً use case مخصوص Aging Parents دارد؛ یعنی تقریباً سناریوی «Where’s Dad?» را دقیقاً هدف گرفته. Real-time location، Place Alerts، No-Show Alerts، Crash Detection و SOS از قابلیت‌هایی هستند که ارائه می‌کند.نتیجه اولیه خدا برای یک شرایط عادی:پس اگر فقط هدفت این باشد که این مشکل برای خودت حل شود، احتمالاً لازم نیست اپ بسازی.حالا بریم به بررسی شرایط موجود:سرویس های گوگل و اپل برای ایران کار نمیکنه و از همه مهمتر اینکه شرایط و دانش بابا برای این موضوع محدودیت ایجاد میکندایده ال ترین حالت اینه که نیازی نباشه بابا کاری انجام بده و به حداقل ترین دسترسی ها نیاز باشهروی گوشی های اپل که داستان زیاد داریم و خداروشکر گوشی بابا اندروید هست پس فعلا اون بخش رو میزاریم واسه فازهای بعدییک اپ فوق‌العاده ساده برای والدین و اعضای خانوادهطرفی که روی گوشی پدرت نصب می‌شود شاید اساساً فقط این را داشته باشد:You’re sharing your location with Sayid ✓و تمام.نه داشبورد پیچیده، نه نقشه، نه تنظیمات عجیب.یه چیز تخصصی که توی جستجو خدا بهم گفت:نکته خیلی جالبی که در بررسی پیدا کردماگر تصمیم بگیری بسازی، اصلاً لازم نیست background GPS engine را از صفر بنویسی.Traccar همین July 11, 2026 یک SDK جدید منتشر کرده که دقیقاً کار سخت این پروژه را انجام می‌دهد:Traccar Client SDKبرای:Native Android/iOS + Flutter + React Nativeو کاملاً Apache 2.0 / Open Source است.کارهای سختی مثل:background locationbattery optimisationoffline queueretry uploadstop detectionmotion detectionرا از قبل حل کرده.حتی می‌تواند اطلاعات را به server خودت بفرستد و الزاماً لازم نیست از Traccar Server استفاده کنی.این به‌نظرم پروژه را از:«چند ماه دردسر native background tracking»تبدیل می‌کند به:«یک محصول UX-driven که backend و UI اصلی‌اش را خودمان می‌سازیم.»و این خیلی جذاب‌تر است.یک محدودیت مهم که باید بررسی بشه و به حداقل ترین برسههیچ اپی نمی‌تواند تضمین کند:«هر لحظه که خواستم مکان دقیق را می‌گیرم.»اگر گوشی خاموش باشد، اینترنت نداشته باشد، GPS خاموش شده باشد یا OS اپ را متوقف کرده باشد، فقط last known location خواهی داشت.مثلاً Traccar هم توضیح می‌دهد که iOS/Android محدودیت‌های background processing دارند و در شرایطی مثل force-quit، battery optimisation و Low Power Mode ممکن است tracking متوقف یا کند شود.پس UX درست نباید بنویسد: و دقیقا نقش UX همینجا دیده میشود ( چیزی بسازیم که محدودیت ها رو پوشش بده و به حداقل برسونه )Dad is here.بلکه:Dad was here 3 minutes ago.این تفاوت خیلی مهمی است.رفتم توی فاز تحلیل شخصی و تشریح شرایط:نکات من:چیزی که توی ذهن من هست اینه یک اپ بدون هیچ ظاهر و امکانی در داخل خود گوشیحتی در بک گراند هم سرویسی رو همیشه ران نمیکندبررسی های برنامه روی ایونت ها فعال میشودایونت هایی که به ذهنم میرسد:اگر از یک مخاطب بیش از سه مرتبه تماس اومد و پاسخ داده نشداگر تعداد تماس های پاسخ داده نشده در گوشی به تعداد مشخصی رسیداگر باتری به زیر ۱۰ درصد رسیداگر پیامکی با متن مشخص از شماره های مشخص وارد گوشی شددسترسی های برنامه:از ابتدای نصب برنامه به لوکیشن ، خواندن پیامک ها و لاگ تماس ها ، اماکن ارسال پیامک و برقراری تماساگر اینترنت روشن باشد هم میتواند از اینترنت برای ارسال داده های بیشتر استفاده کندتجسم شرایط:به عنوان مثال همین امروز من بیشتر از سه مرتبه از شماره خودم با بابام تماس گرفتم و پاسخ نداد. تماس هام با فاصله بود و نه پشت سر هممثلا میشد با همین تماس های مکرر برنامه یک پیامک برای من ارسال کند از گوشی پدر با ساختار فشرده و کوتاه شده ترکیبیشامل: لوکیشن ، میزان باتری ، وضعیت اینترنت دستگاه (خاموش/روشن)چرا میگم ترکیبی و کوتاه : چون با توجه به وضعیت فچل ارتباطات اگه پیامک بیشتر از یک پیامک بشه احتمال رسیدن پیامک پایین میاد ، اگر متن پیامک انگلیسی و شامل لینک باشه احتمال ارسال نشدن بالا میره. پس بهتره که اطلاعات رو با الگویی به شکل پیامک کوتاه فارسی تبدیل کنیم و در مقصد دوباره دیکد کنیمیا حتی در شرایط دیگه من یک پیامک مشخص به گوشی بابام ارسال کنم ، مثلا: باباکجایی-پاسخ-خودکارو برنامه به این پیام حساس باشد و با دریافت این پیامک همان مختوای لازم رو ارسال کندنکنه: چون موقعیت ممکن است دقیق نباشد و شرایط در زمان کوتاهی تغییر کند در هر دو حالت برنامه باید چند مرتبه و در فاصله ۲ تا ۵ دقیقه همه جزئیات رو ارسال کند تا برآیند این ارسال ها کمک کند موقعیت دقیق تر شودو اما نظر کارشناسی خداوندگار درباره استراکچر ذهنی من:آیا دقیقاً همین ساخته شده؟قسمت‌هایی از آن بله؛ ترکیبی که تو تعریف کردی نه به این شکل.مثلاً پروژه Open Source به نام PhoneTrack SMS وجود دارد که با دریافت یک keyword از شماره تأییدشده، GPS، accuracy و battery را با SMS برمی‌گرداند و حتی بدون اینترنت کار می‌کند.پروژه Anchor هم تقریباً remote-control-via-SMS است: location، battery، ring، callback و whitelist دارد.حتی ابزارهای قدیمی‌تری وجود داشته‌اند که با missed call یا SMS command لوکیشن می‌فرستادند.ولی چیزی که در ایده تو مهم است این ترکیب است:passive + event-driven + no internet dependency + multiple safety triggers + compact one-SMS protocol + temporary high-accuracy samplingاین ترکیب را در چیزی که بررسی کردم به شکل یک محصول مدرن و تمیز ندیدم.معماری‌ای که تو گفتی از نظر Android کاملاً منطقی استمن حتی ترجیح می‌دهم هیچ daemon دائمی برای GPS نداشته باشیم.Android خودش می‌تواند برای SMS_RECEIVED و تغییر وضعیت تماس BroadcastReceiver را بیدار کند، حتی اگر process اپ در آن لحظه فعال نباشد.پس فلسفه‌ی تو درست است:اپ لازم نیست دائماً اجرا شود؛ سیستم‌عامل خودش آن را در event مناسب بیدار می‌کند.بیاییم Triggerهای تو را یکی‌یکی بررسی کنیمTrigger امکان‌ پذیری نکته ۳+ تماس بی‌پاسخ از یک نفر بسیار خوب تعداد کل missed callها به N برسد Call Log لازم دارد SMS خاص از شماره مشخص یکی از بهترین trigger ها Battery < 10% شدنی، ولی exact 10% کمی داستان دارد اینترنت قطع وصل هنگام اجرای session قابل بررسی Location on demandBackground Location لازم دارد چند sample طی ۲–۵ دقیقه/باید با محدودیت background Android طراحی شود ارسال SMS خودکارSEND_SMS لازم استاینجا دیگه وارد مباحث فنی تولید شدیم. کاندیشن ها و ظرفیت ها. واسه خوندن این موارد میریم ادامه رو روی مستندات ریپوی گیت هاب که اینجا دیکه بیشتر از این طولانی نشهلینک ریپوزیتوری در گیت هابنتیجه گیریبه نظرم الان دیگر ایده به‌اندازه کافی مشخص شده که ارزش دارد به‌جای brainstorm عمومی، یک Product Spec واقعی برایش بنویسیم: دقیقاً state machine، trigger rules، SMS protocol، permission model، failure scenarios و معماری Android را مشخص کنیم. بعد خیلی راحت می‌توانیم تشخیص بدهیم آیا بهتر است از صفر Kotlin بنویسیم یا بخش‌هایی از PhoneTrack/Anchor را reuse کنیم.بزن بریم بسازیم و منتشر کنیم ، روی ریپو میتونی نتیجه رو ببینیممنون که وقت گذاشتی و پستم رو خوندی

جایی که آزادی خلاقانه با نظم مهندسی به یک محصول واقعی تبدیل می‌شود

سعید مقدم — Wed, 05 Aug 2026 15:11:56 +0330

در بسیاری از تعریف‌ها، هنر چیزی فراتر از چارچوب‌ها و قوانین ازپیش‌تعیین‌شده است. هنرمند اصول را یاد می‌گیرد، اما لزوماً آن‌ها را به‌عنوان مرز نهایی نمی‌پذیرد. گاهی قوانین در دنیای هنر دقیقاً برای آن وجود دارند که آگاهانه شکسته شوند و راهی تازه برای بیان، تجربه و کشف ایجاد کنند.در نقطه تقابل هنر و در نقطه مقابل، برنامه‌نویسی و زیرساخت تولید محصولات دیجیتال بر نظم، دقت و پیش‌بینی‌پذیری بنا شده‌اند. در این دنیا، یک اشتباه کوچک می‌تواند رفتار یک کامپوننت را مختل کند، تجربه کاربر را به هم بریزد یا حتی عملکرد کل سیستم را تحت تأثیر قرار دهد.به همین دلیل، هنر و مهندسی در نگاه اول دو جهان متضاد به نظر می‌رسند:هنر به دنبال آزادی، تجربه و کشف است.مهندسی به دنبال ساختار، ثبات و قابلیت اطمینان.اما طراحی محصول دقیقاً در مرز میان این دو جهان اتفاق می‌افتد.اسکرینشات وبینار آنلاین فیگمااز طراحی تا ساختمدتی پیش در حال تماشای یکی از رویدادهای مجموعه Figma Summer School: Designer to Builder بودم؛ رویدادی درباره اتصال، بررسی و آماده‌سازی یک کامپوننت برای انتشار و ساخت اولین نسخه قابل‌اجرای آن با کمک هوش مصنوعی.در این فرایند، کامپوننت فقط از فیگما به کد تبدیل نمی‌شد. ابتدا در Dev Mode بررسی می‌شد، سپس با کمک هوش مصنوعی اولین پیاده‌سازی آن شکل می‌گرفت، به‌صورت محلی اجرا می‌شد و در نهایت نتیجه چندین بار با طراحی اولیه مقایسه و اصلاح می‌شد تا به هدف و نیت اصلی طراحی نزدیک بماند.چیزی که برای من بیش از خود ابزارها جذاب بود، چرخه‌ای بود که میان طراحی و توسعه شکل می‌گرفت:طراحی، ساخت، مقایسه و اصلاح.این فرایند نشان می‌داد که تبدیل طراحی به کد، صرفاً ترجمه چند لایه و استایل به مجموعه‌ای از دستورات فنی نیست. مسئله اصلی، حفظ Design Intent یا همان هدف و نیت اصلی طراحی در طول مسیر ساخت محصول است.همین موضوع ذهن کنجکاوم را حسابی درگیر کرد و دوباره مرا به فکر رابطه میان ساختار فنی و آزادی خلاقانه انداخت.ذهن طراحی با پیش‌زمینه مهندسیبه دلیل پیش‌زمینه‌ام در مهندسی نرم‌افزار، تقریباً هیچ‌وقت یک طراحی را فقط به‌عنوان یک خروجی بصری نمی‌بینم.هنگام طراحی، ناخودآگاه به کامپوننت‌ها، وضعیت‌های مختلف، داده‌ها، محدودیت‌های فنی، واکنش‌گرایی، مقیاس‌پذیری و نحوه پیاده‌سازی فکر می‌کنم.وقتی یک دکمه طراحی می‌کنم، فقط ظاهر آن را نمی‌بینم. به حالت‌های Hover، Focus، Disabled و Loading هم فکر می‌کنم.وقتی یک صفحه می‌سازم، فقط ترکیب‌بندی آن برای یک اندازه مشخص مهم نیست. به رفتار آن در دستگاه‌های دیگر، محتوای طولانی‌تر، خطاها، شرایط خالی و داده‌های غیرمنتظره نیز فکر می‌کنم.این نوع نگاه مزیت بزرگی است. باعث می‌شود طراحی از همان ابتدا به واقعیت محصول نزدیک باشد. فاصله میان فایل طراحی و خروجی نهایی کمتر شود و گفت‌وگو میان طراحی و توسعه با زبان مشترک‌تری شکل بگیرد.اما این ذهنیت، یک خطر پنهان هم دارد.گاهی ذهن مهندسی قبل از آنکه یک ایده فرصت رشدکردن پیدا کند، وارد فرایند می‌شود و آن را محدود می‌کند.قبل از اینکه ایده‌ای جسورانه یا غیرمنتظره شکل بگیرد، شروع می‌کنم به پرسیدن:آیا قابل‌استفاده مجدد است؟آیا با دیزاین سیستم هماهنگ است؟آیا توسعه آن بیش از اندازه پیچیده می‌شود؟آیا در تمام اندازه‌های صفحه درست کار می‌کند؟آیا می‌توان آن را به یک الگوی استاندارد تبدیل کرد؟تمام این پرسش‌ها ضروری‌اند، اما شاید نه در اولین لحظه شکل‌گیری یک ایده.وقتی اصول زودتر از خلاقیت وارد می‌شوندمحدودیت‌های فنی همیشه دشمن خلاقیت نیستند. گاهی حتی می‌توانند باعث شکل‌گیری راه‌حل‌های هوشمندانه‌تر شوند.اما زمانی که خیلی زود وارد فرایند شوند، ممکن است ایده را پیش از آنکه فرصت کشف‌شدن پیدا کند، به یک راه‌حل امن، آشنا و قابل پیش‌بینی تبدیل کنند.این همان نقطه‌ای است که گاهی احساس می‌کنم ذوق هنری‌ام محدود شده و خلاقیت بصری‌ام زیر فشار منطق تولید قرار گرفته است.در چنین لحظاتی، آگاهانه به خودم اجازه می‌دهم کمی خارج از چارچوب طراحی کنم.نه برای اینکه اصول را کنار بگذارم، بلکه برای اینکه ورود آن‌ها را کمی به تأخیر بیندازم.ابتدا باید به ایده اجازه داد آزادانه شکل بگیرد؛ حتی اگر عجیب، پیچیده یا در نگاه اول غیرقابل‌اجرا به نظر برسد. بعد از آن می‌توان ذهن مهندسی را وارد کرد، ایده را بررسی کرد و آن را به راه‌حلی واقعی و قابل‌ساخت تبدیل کرد.شاید یکی از مهارت‌های مهم یک طراح محصول، توانایی جابه‌جایی آگاهانه میان این دو حالت باشد:یک‌بار مثل یک هنرمند آزادانه کشف کند و بار دیگر مثل یک مهندس، نتیجه این کشف را به یک سیستم قابل‌اتکا تبدیل کند.هنر بی‌قانون نیستگفتن اینکه هنر هیچ قانون و اصولی ندارد، شاید تعریف کاملی نباشد.هنر هم دارای ریتم، تکنیک، ترکیب‌بندی، تعادل، تناسب و ساختار است. تفاوت اصلی در نوع مواجهه با این اصول است.در مهندسی، قوانین معمولاً برای جلوگیری از شکست سیستم تعریف می‌شوند. اما در هنر، شکستن آگاهانه یک قانون می‌تواند به خلق یک زبان تازه منجر شود.هنرمند ابتدا اصول را می‌آموزد، سپس آن‌ها را درک می‌کند و در نهایت تصمیم می‌گیرد کجا به آن‌ها وفادار بماند و کجا از آن‌ها عبور کند.بنابراین، خلاقیت الزاماً از نبود ساختار به وجود نمی‌آید. گاهی خلاقیت از گفت‌وگوی آگاهانه با ساختار شکل می‌گیرد.طراحی محصول؛ مذاکره میان دو جهاناگر طراحی محصول بیش از اندازه درگیر سیستم، استاندارد و قابلیت پیاده‌سازی شود، ممکن است محصولی منظم و قابل‌استفاده تولید کند که هیچ شخصیت و تمایزی ندارد.همه‌چیز درست کار می‌کند، اما هیچ‌چیز به‌یادماندنی نیست.در مقابل، اگر طراحی فقط بر آزادی بصری و بیان هنری متکی باشد، ممکن است نتیجه چشم‌نواز باشد، اما در مقیاس واقعی قابل‌توسعه، قابل‌نگهداری یا حتی قابل‌استفاده نباشد.طراحی خوب زمانی اتفاق می‌افتد که هیچ‌کدام از این دو نیرو، دیگری را حذف نکند.هنر به محصول هویت، احساس و جسارت متفاوت‌بودن می‌دهد.اصول طراحی به آن وضوح و انسجام می‌بخشند.مهندسی آن را به چیزی واقعی، قابل‌استفاده و ماندگار تبدیل می‌کند.هنر می‌پرسد:چه چیز دیگری ممکن است؟مهندسی می‌پرسد:چگونه می‌توانیم آن را بسازیم؟و طراحی محصول باید پاسخی پیدا کند که هر دو پرسش را جدی بگیرد.نقش هوش مصنوعی در این همزیستیهوش مصنوعی فاصله میان طراحی و ساخت را کمتر کرده است.امروز طراحان می‌توانند سریع‌تر ایده‌های خود را آزمایش کنند، نمونه‌های قابل‌اجرا بسازند و نتیجه را بدون عبور از یک فرایند طولانی با طراحی اولیه مقایسه کنند.این اتفاق می‌تواند فضای بیشتری برای خلاقیت ایجاد کند؛ چون بخشی از کارهای تکراری و زمان‌بر سریع‌تر انجام می‌شوند.اما یک خطر نیز وجود دارد.اگر صرفاً به خروجی‌های آماده و الگوهای پیشنهادی ابزارها تکیه کنیم، ممکن است سریع‌تر از گذشته به محصولاتی برسیم که از نظر فنی درست‌اند، اما از نظر خلاقانه تفاوت چندانی با یکدیگر ندارند.بنابراین، مسئله فقط این نیست که آیا هوش مصنوعی می‌تواند یک کامپوننت را به کد تبدیل کند یا خیر.پرسش مهم‌تر این است:آیا هوش مصنوعی به ما فرصت بیشتری برای خلق‌کردن می‌دهد، یا فقط ما را سریع‌تر به یک خروجی استاندارد می‌رساند؟پاسخ این سؤال به نحوه استفاده ما از ابزار بستگی دارد.همزیستی، نه رقابتامروز دیگر ساختار فنی و کد را دشمن خلاقیت نمی‌بینم.اصول و مهندسی، اگر در زمان مناسب وارد فرایند شوند، می‌توانند به یک ایده خلاقانه قدرت ماندگاری بدهند.هنر بدون ساختار ممکن است به یک تجربه کوتاه و زیبا محدود بماند. مهندسی بدون هنر نیز ممکن است محصولی قابل‌اعتماد اما بی‌روح تولید کند.بهترین محصولات دیجیتال نه نتیجه پیروزی هنر بر مهندسی‌اند و نه حاصل تسلط کامل قوانین بر خلاقیت.آن‌ها از همزیستی این دو شکل می‌گیرند:همزیستی میان آزادی و مسئولیت.میان جسارت و دقت.میان کشف و تکرارپذیری.میان چیزی که می‌توان تصور کرد و چیزی که می‌توان ساخت.هنر همچنان جایگاه خودش را دارد. خلاقیت و چارچوب‌شکنی هنوز بخش مهمی از طراحی‌اند. در کنار آن‌ها، سخت‌گیری کد و قوانین توسعه محصول نیز کمک می‌کنند این خلاقیت از یک ایده زیبا به یک تجربه واقعی تبدیل شود.شاید قدرت واقعی طراحی محصول دقیقاً در همین نقطه شکل می‌گیرد:جایی که هنر، مرزها را جابه‌جا می‌کند و مهندسی، امکان عبور از آن‌ها را می‌سازد.

حل یک مسئله از جنس نفود

سعید مقدم — Tue, 07 Jul 2026 23:09:29 +0330

چطور مچ نفوذی رو گرفتم و یک سناریوی تکراری رو پایان دادم.نفوذ به سرور رو پیدا کردمیک سال پیش بود که دیدم یکی از سایت هام بالا نمیاد و کاملا خالی شده، وارد پنل مدیریت شدم و دیدهم همه فایل ها و پوشه ها بایک الگوی مشترک تغییر نام داده شدن و هیچی سرجاش نیست. رسما یکی اومده بود همه چی رو بهم ریخته بود و هرچی به دستش رسیده بود شکسته بود و رفته بود.چندتا سایت دیگه هم داشتم روی همون سرور گفتم یه نگاهی به اونا هم بندازم، چشمتون روز بد نبینه همه سایت ها به همین شکل به فنا رفته بود و رسما یک پیکر نیمه جون واسم باقی گذاشته بود.چون خیالم راحت بود که سرورم بکاپ اتومات داره رفتم و سرور رو برگردوندم به یکی از نسخه های بکاپ و خداروشکر همه چی درست برگشت سرجاش و شروع کردم به جستجوی نقطه نفوذ و عامل خرابکاری ، از بررسی لاگ ها گرفته تا تک تک تغییرات روی سایت طی روزهای قبل و هیچی پیدا نکردم. البته که بزرگترین اشتباهم این بود که اول بکاپ برگردوندم و بعد شروع کردم به جستجو، که البته به خودم حق میدم چون استرس داشتم که مشتری سایتش رو ببینه و شاکی بشه.خلاصه به چیزی دست پیدا نکردم و کار رو رها کردم و چیزی دستگیرم نشد. تا امروز که دوباره همون سناریو تکرار شد.الگوی تغییر نام در فایل ها و اینبار گفتم همون اشتباه رو دوباره انجام ندم و اول لباس کاراگاهیم رو پوشیدم وگفتم " دستان پرتوان برسید به داد این ناتوان :)) " با کمک خدایگان این روزها استاد GPT شروع کردم به بررسی میدانی و هر داده ایی که گیرم میومد.اول از همه به پیشنهاد جی پی تی جان از روی یکی از بکاپ ها یک سرور بکاپ ساختم که بریم لاگ ها رو توی اون بررسی کنیم تا در مراحل بررسی دوست نفوذگر خیلی شاخکاش فعال نشه.اولین سرنخ: زمان دقیق خرابکاریهمه فایل‌ها و پوشه‌های سایت با یک پسوند عجیب، تغییر نام داده شده بودن. مثلاً:wp-content__8a534d5 wp-admin__8a534d5 wp-includes__8a534d5اولین کار این بود که از روی زمان تغییرات فایل‌ها بفهمیم این اتفاق دقیقاً چه ساعتی افتاده ، نتیجه: عملیات تغییر نام فایل‌ها در روز ۲۶ ژوئن، بین ساعت ۱۱:۰۲ تا ۱۱:۰۵ انجام شده بود. یعنی خرابکاری نه در طول چند ساعت، بلکه در حدود سه دقیقه اتفاق افتاده بود. این بازه زمانی شد نقطه شروع بررسی لاگ‌ها.در همون حوالی، چند درخواست مشکوک به فایل‌هایی با اسم‌های عجیب پیدا کردیمwp-wlx.php lock360.php admin.php style.phpیکی از درخواست‌ها حتی با User-Agent زیر ارسال شده بودShellBot 2.0مهاجم از طریق یکی از همین فایل‌ها فرمان‌های مختلفی ارسال کرده بود؛ از باز کردن قفل و ساخت ادمین گرفته تا دانلود کد از یک دامنه خارجی. جالب‌تر اینکه زمان اجرای یکی از این فرمان‌ها دقیقاً با زمان شروع تغییر نام فایل‌ها یکی بود. اینجا دیگه مشخص شد که با یک اختلال ساده، خرابی تصادفی یا مشکل آپدیت وردپرس طرف نیستیم. یک نفر از طریق یک Webshell داخل سایت، فرمان اجرا کرده بود.::: با روحیه پیگیر و چالش دوستم گفتم هر فایل مخربی، نقطه ورود نیست ، باید پی کارو بگیرم :::یکی از اولین فایل‌هایی که پیدا کردیم، فایلی به نام about.php بود که ظاهرش شبیه یک فایل معمولی و حتی محافظت‌شده توسط یک سرویس امنیتی بود. اما وقتی بازش کردیم، مشخص شد کاملاً Obfuscated و مخرب است.در نگاه اول ممکن بود بگوییم همین فایل نقطه ورود بوده، ولی زمان ساختش نشان می‌داد بیش از دو ساعت بعد از خرابکاری اصلی ایجاد شده است. پس این فایل نقطه ورود نبود؛ یکی از ابزارهایی بود که مهاجم بعداً برای حفظ دسترسی خودش ساخته بود.این یکی از مهم‌ترین نکات این بررسی بود ( کاربر پیگیر و کرمو ):هر فایل مخربی که پیدا می‌کنیم الزاماً عامل اولیه نفوذ نیست. بعضی فایل‌ها فقط ابزار ماندگاری مهاجم‌اند.کمی عقب‌تر رفتیم و به فایل دیگری در قالب پیش‌فرض وردپرس رسیدیم:( اسیر شدیم )themes/twentytwentythree/patterns/style.phpاین فایل هم یک Backdoor کامل بود؛ می‌توانست فایل دانلود کند، فایل جدید بسازد، index.php را تغییر بدهد، Shell ایجاد کند و حتی بعد از انجام کار خودش را حذف کند. بررسی زمان‌ها نشان داد این فایل یک روز قبل از خرابکاری اصلی ساخته شده بود. بعد باز هم عقب‌تر رفتیم.نقطه‌ای که فهمیدیم داستان قدیمی‌تر استدر روز ۲۴ ژوئن، دقیقاً در ساعت ۱۱:۰۱:۲۷، چندین فایل PHP در مسیرهای کاملاً تصادفی داخل وردپرس ساخته شده بودند. مثلاً در مسیرهایی شبیه این:wp-includes/.../uploads/docs/media/.../admin.php wp-admin/.../tmp/resources/.../index.php wp-content/plugins/.../languages/.../admin.phpهمه آن‌ها در یک ثانیه ساخته شده بودند و مالک تمام فایل‌ها هم کاربر همان سایت بود، نه root.یکی از فایل‌ها فقط ۵۰۴ بایت حجم داشت. وقتی بازش کردیم، کد آن تقریباً این کار را انجام می‌داد:اتصال به یک دامنه خارجیغیرفعال کردن بررسی SSLدانلود کد از راه دوراجرای مستقیم آن با evalیعنی فایل روی سرور فقط یک Loader کوچک بود و مغز اصلی بدافزار هر لحظه می‌توانست از سرور مهاجم دریافت شود. همان Loader چند دقیقه بعد در مسیر دیگری هم کپی شده بود؛ با هش کاملاً یکسان. این یعنی یک اسکریپت مرکزی داخل سایت، به‌صورت خودکار Backdoorها و Loaderهای مختلف را در مسیرهای تصادفی پخش می‌کرد تا اگر یکی حذف شد، چند نسخه دیگر باقی بماند. ( نفوذی از منم پیگیر تر بود )آیا مهاجم وارد خود سرور شده بود؟یکی از نگرانی‌های اصلی من این بود که شاید کسی رمز SSH یا پنل سرور را پیدا کرده باشد ، لاگ‌های ورود را بررسی کردیم. تلاش برای ورود زیاد بود؛ مثل اکثر سرورهای عمومی، هر چند ثانیه یک ربات با اسم‌هایی مثل root، scott، omar و ده‌ها نام دیگر رمز امتحان می‌کرد، اما همه آن‌ها با این وضعیت تمام شده بودند:Failed password Invalid user preauthهیچ ورود موفق SSH در زمان حمله پیدا نشد.لاگ‌های Cron، Sudo و System Journal را هم بررسی کردیم. در همان ساعت فقط Job عادی ساخت Snapshot توسط CloudPanel اجرا شده بود و نشانه‌ای از اجرای فرمان مشکوک در سطح سیستم وجود نداشت.در پوشه‌های زیر هم فایل موقت مشکوکی ساخته نشده بود:/tmp /var/tmp /dev/shmتمام فایل‌های مخرب فقط داخل همان سایت ساخته شده بودند و مالکشان هم کاربر PHP همان سایت بود.پس نتیجه‌ای که به آن رسیدیم این بود:مهاجم به احتمال بسیار زیاد از طریق WordPress، قالب، افزونه یا یک Backdoor قدیمی وارد شده بود؛ نه از طریق SSH و نه با دسترسی Root به کل سرور.این نتیجه با یک نشانه دیگر هم هماهنگ بود: این بار فقط همین سایت آسیب دیده بود و بقیه سایت‌های سرور مشکلی نداشتند.چرا نقطه ورود دقیق پیدا نشد؟برای روز ۲۴ ژوئن، یعنی روزی که اولین مجموعه Backdoorها ساخته شده بودند، Access Log کامل در دسترس نبود. به همین دلیل می‌توانستیم مسیر حمله، زمان اجرای بدافزار، فایل‌های ایجادشده و روش ماندگاری را ببینیم، اما نمی‌توانستیم با قطعیت بگوییم اولین درخواست از کدام افزونه یا آسیب‌پذیری وارد شده است. ممکن بود یک افزونه قدیمی آسیب‌پذیر بوده باشد، ممکن بود قالب دست‌کاری شده باشد یا حتی Backdoor از ماه‌ها قبل داخل سایت وجود داشته و تازه در آن روز فعال شده باشد. بنابراین من «اسم دقیق حفره» را پیدا نکردم، اما توانستم سناریوی حمله را تا حد زیادی بازسازی کنم:یک کد مخرب از قبل در سایت اجرا شده است.در ۲۴ ژوئن چندین Backdoor و Loader ایجاد کرده است.در روزهای بعد مهاجم از همان دسترسی‌ها استفاده کرده است.در ۲۶ ژوئن فرمان خرابکاری اصلی و تغییر نام فایل‌ها اجرا شده است.بعد از آن هم Webshellهای جدیدی برای حفظ دسترسی ساخته شده‌اند.این بار بکاپ را مستقیم برنگرداندیمبعد از اینکه شواهد کافی جمع شد، سایت آلوده را در یک پوشه جداگانه قرنطینه کردم و یک مسیر کاملاً تمیز برای سایت ساختم. هسته وردپرس را از منبع اصلی دوباره دانلود کردم و فایل‌های Core با Checksum رسمی بررسی شدند. از wp-content هم فقط فایل‌های رسانه‌ای مجاز مثل عکس، ویدئو، PDF و فونت را منتقل کردم. هیچ فایل PHP، افزونه یا قالبی از نسخه آلوده وارد نصب جدید نشد.دیتابیس را نگه داشتیم، اما اقدامات امنیتی زیر روی آن انجام شد:همه افزونه‌ها غیرفعال شدند.Cronهای قدیمی حذف شدند.Transientها پاک شدند.تمام Sessionهای کاربران باطل شدند.Saltهای وردپرس تغییر کردند.رمز ادمین اصلی عوض شد.یک حساب Administrator ناشناس هم پیدا شد که من ساختنش را به خاطر نمی‌آوردم و نیازی هم به آن نبود؛ (این هم یه شک ریزی واسم بود ولی حس میکردم کار خودمه :)) ) واسه همین پیگیر نشدم و فقط حذفش کردم.در نهایت فقط یک حساب ادمین اصلی باقی ماند.رسیدیم به قالبی که از RTL-Theme خریده بودممرجع قالب های زیبا و ارزون ولی کپی شده در ایرانبرای نصب مجدد قالب، نسخه‌ای را که از حساب کاربری‌ام در RTL-Theme دانلود کرده بودم بررسی کردم. داخل فایل دانلودی، علاوه بر قالب و افزونه‌های همراه، یک Installer و چند فایل مربوط به لایسنس وجود داشت.اما نکته‌ای که باعث شد پروسه بازسازی را متوقف کنم، این بود که فایل‌های مهمی از قالب، از جمله functions.php، با ionCube رمزگذاری شده بودند.functions.php یکی از اصلی‌ترین فایل‌های هر قالب وردپرس است و تقریباً در تمام درخواست‌ها اجرا می‌شود. وقتی چنین فایلی رمزگذاری شده باشد، من نه می‌توانم محتوایش را بررسی کنم، نه می‌توانم مطمئن شوم دقیقاً چه کاری انجام می‌دهد.در اسکن فایل جدید، هیچ‌کدام از دامنه‌ها، هش‌ها یا الگوهای بدافزار قبلی پیدا نشد. بنابراین مدرکی ندارم که بگویم RTL-Theme یا ناشر قالب عمداً Backdoor در محصول قرار داده است. اما در عین حال نمی‌توانم سلامت کامل محصول را هم تأیید کنم. نسخه‌ای که دریافت کردم، نسخه دست‌نخورده سازنده اصلی نبود؛ یک نسخه بازبسته‌بندی‌شده با Installer، سیستم لایسنس و فایل‌های رمزگذاری‌شده بود.و اینجاست که واسم عجیب شد ، موقع انتشار هر قالبی در سایت بسیار سختگیرانه رفتار میکنن و دوستای وردپرس کارم به شدت از ایرادهایی الکی که میگیرن شاکی هستن پس چطوری این داستان پیش اومده و از دستشون در رفته !! راستش انتقادی بهشون دارم و تجربه ایی واسه خودم بود ولی انتظارم ازشون بیشتر بود و حرفه ایی تر تصورشون میکردم. و اما درسی که گرفتم: وقتی یک فروشگاه، قالب یا افزونه وردپرس می‌فروشد، صرفاً یک فایل ZIP نمی‌فروشد. دارد بخشی از زیرساخت سایت، کسب‌وکار و اطلاعات مشتری را تحویل می‌دهد. وقتی فایل‌های حیاتی یک محصول رمزگذاری می‌شوند، خریدار عملاً مجبور است بدون امکان بررسی، به فروشنده اعتماد کامل کند. شاید این رمزگذاری فقط برای کنترل لایسنس و جلوگیری از کپی غیرمجاز انجام شده باشد، اما نتیجه برای من به‌عنوان خریدار این است که:نمی‌توانم کد را Audit کنم.نمی‌توانم نسخه را با نسخه اصلی سازنده مقایسه کنم.نمی‌توانم مطمئن شوم چه تغییراتی روی قالب انجام شده.در زمان رخداد امنیتی، نمی‌توانم منبع آلودگی را با قطعیت رد یا تأیید کنم.نمی‌توانم با خیال راحت همان فایل را دوباره روی سایت مشتری نصب کنم.محصولی که روی سرور مشتری اجرا می‌شود باید شفاف، قابل بررسی و قابل اعتماد باشد.(نتیجه گیری اصلی: واسه پروژه های مهم بریم نسخه اصلی بخریم ، نه نال شده هایی که ارزون تر فروخته میشن )ممکن است RTL-Theme هیچ ارتباط مستقیمی با این نفوذ نداشته باشد، اما فروش نسخه‌ای که بخش‌های اصلی آن غیرقابل بررسی است، من و مشتری من را در موقعیتی قرار داده که بعد از یک رخداد امنیتی، مجبور شدیم کل سایت را کنار بگذاریم و از صفر بازسازی کنیم.چیزهایی که از این داستان یاد گرفتماولین درس این بود که بکاپ داشتن با امن بودن فرق داره ، زیادی روی بکاپ هفت روزه حساب کرده بودم.درس دوم این بود که قالب رو از خود توسعه دهنده بخریم نه راست چین. ( ارزونی بی دلیل نیست )درس سوم اینکه مخرب یا نفوذی این همه زحمت نمیشه که یک فایل مخرب بزاره و پیچیده تر از این حرفا عمل میکنه که راحت مسیرش مسدود بشه . ( ولی خدایی دمش گرم )این پرونده کاراگاهی شاید با پیدا کردن مجرم تمام نشد، اما باعث شد تصمیم بگیرم چند وقت دیگه دوباره همین بلا سرم نیاد و بازهم یک تجربه جدید کسب کردم و در مسیر حل یک مسئله قدم برداشتم و چیزای جدید یاد گرفتم.اینم انگیزشیش:گاهی حل مسئله به معنی تعمیر همان چیزی که شکسته نیست. گاهی بهترین راه‌حل این است که بفهمی دیگر نباید به آن پایه اعتماد کنی و همه‌چیز را از نو، اما این بار درست‌تر بسازی.

تحقیقات کاربر User Research

سعید مقدم — Tue, 21 Feb 2023 02:00:30 +0330

این مقاله یک ترجمه یا شاید هم یک تالیف از بخش دوم دوره طراح تجربه کاربری از بنیاد طراحی تعاملی یا همون IxDF هست که من سعی کردم با قلم خودم به فارسی بازنویسیش کنمhttps://www.interaction-design.org/courses/user-experience-the-beginner-s-guide-deprecated-v2/lessons/2.32.3 : User Research: What It Is and Why You Should Do Itتحقیقات کاربر (User Research) یکی از بخش های اساسی طراحی تجربه کاربری است ، خب از کجا باید شروع کنیم؟ اصلا برای چه کسی و چرا طراحی میکنیم؟ چه الزامات و محدودیت هایی داریم؟ همه این سوالات به پروژه ایی که انتخاب کردیم بستگی داره و میتونیم روش تحقیق های مختلفی رو انتخاب کنیم ، از نظرسنجی و آزمون گرفته تا مصاحبه و متداول ترین روش یعنی تست کاربردپذیری (Usability Testing).ما در اینجا میخواهیم در ابتدا بررسی کنیم که تحقیقات کاربر چیست و سه دلیل رایج برای اینکه چرا باید تحقیقات کاربر انجام دهیم را مطرح کنیم.باید تحقیقات کاربر انجام دهیم تا طرحی ایجاد کنیم که: ۱ - مرتبط باشد ۲ - استفاده از آن آسان و لذت بخش باشد ۳ - درک درستی از بازگشت سرمایه را با طراحی تجربه کاربری ایجاد کرده باشیمتحقیقات کاربر چیست؟تحقیقات کاربر یا به عبارتی "تحقیق طراحی" طیف گسترده ایی از روش های تحقیق را پوشش میدهد. این طیف گسترده میتواند شامل هر چیزی باشد ، از انجام مصاحبه با اقوام مختلف مورد نظر شما گرفته تا متد های مطالعات کاربردپذیری سنتی و اندازه گیری کمی بازگشت سرمایه (ROI). وجه مشترک همه روش های تحقیقات کاربر این است که کمک کند تا کاربران را در مرکز فرآیند طراحی و محصول قرار دهید. شما از تحقیقات کاربر برای الهام بخشیدن ، ارزیابی و اندازه گیری تاثیرات خودتون استفاده می کنید. تحقیقات کاربر اغلب به روش های کمی و کیفی تقسیم میشوند.بررسی‌ها و آزمایش‌های رسمی مانند تست A/B و تست درخت، نمونه‌هایی از ابزارهای تحقیقات کمی هستند. روش‌های تحقیق کمی به دنبال اندازه‌گیری رفتار کاربر به روشی است که بتوان آن را به اعداد تبدیل کرد تا برای تجزیه و تحلیل آماری استفاده شود.مصاحبه ها و تست های کاربرد پذیری ، نمونه هایی از ابزارهای تحقیق کیفی هستند. که بیشتر اکتشافی محسوب میشوند و به دنبال درک عمیقی از تجربیات و زندگی روزمره تک تک کاربران یا گروه های کاربری هستند.هر روش تحقیق مزایا و معایبی دارد ، به این ترتیب، هر کدام را می توان برای دستیابی به اهداف مختلف استفاده کرد. اینکه کدام روش را انتخاب می کنید بستگی به آنچه می خواهید به دست آورید دارد و همچنین موارد دیگری مانند نوع پروژه ای که برروی آن کار می کنید، بودجه و محدودیت زمانی شما و غیره ... با در نظر گرفتن این موضوع، بیایید به چند دلیل مختلف برای اینکه چرا باید کاربران را در فرآیند طراحی خود مشارکت دهید، نگاه کنیم.سه دلیل برای اینکه تحقیقات کاربر انجام بدهیمهمدلی در قلب طراحی قرار دارد. بدون درک آنچه دیگران می بینند، احساس می کنند و تجربه می کنند، طراحی یک کار بیهوده است.— Tim Brown, CEO of the innovation and design firm IDEOنوع تحقیق کاربر که باید انجام دهید به روند کاری شما و همچنین دلیل شما برای انجام تحقیقات کاربر در وهله اول بستگی دارد. در اینجا سه دلیل عالی برای انجام تحقیقات کاربر آورده شده است۱ - ایجاد طرح هایی که واقعا مرتبط هستنداگر کاربران خود را درک می کنید، می توانید طرح هایی بسازید که برای آنها مرتبط باشد. اگر درک روشنی از کاربران خود نداشته باشید، راهی برای دانستن اینکه آیا طراحی شما مرتبط خواهد بود یا خیر ندارید. طرحی که با مخاطب هدف خود مرتبط نباشد هرگز موفق نخواهد بود.اولین مرحله و هسته فرآیند تفکر طراحی، همراهی با کاربران است. تحقیقات کاربر یکی از بهترین راه ها برای انجام این کار است. انجام انواع مختلف مصاحبه ها و مشاهده افراد در زمینه هایی که از طرح شما استفاده می کنند، روش رایج انجام این نوع تحقیقات کاربر است. ما اغلب این نوع تحقیق را در همان ابتدای پروژه قرار می دهیم تا اطمینان حاصل کنیم که جهت کلی پروژه به مشتریان و کاربران بالقوه مرتبط است. به منظور اطمینان از مرتبط بودن طرح شما با پیشرفت پروژه، اعتبارسنجی ایده های خود با کاربران احتمالی به طور مداوم یک عادت حیاتی است که باید به آن پایبند باشید. با آنها در مورد اینکه چگونه طراحی شما را درک می کنند و چگونه می توانند تصور کنند از آن استفاده می کنند صحبت کنید یا آنها را مستقیماً در فرآیند طراحی خود مشارکت دهید تا مطمئن شوید که هنوز در مسیر درست هستید.بیایید به یک مثال نگاه کنیم: در سال ۲۰۰۵ غول لوازم الکترونیکی کره ای یعنی سامسونگ، تعدادی تحقیقات مردمی انجام داد که باعث شد به طور کامل طرز فکرش را در مورد طراحی تلویزیون تغییر دهد. نمایندگان سامسونگ همراه با مشاوره نوآوری و استراتژی ReD Associates، از مردم در کشورهای مختلف دیدن کردند تا نحوه زندگی آنها را مشاهده کنند و در مورد خانه و نقش تلویزیون در خانه با آنها صحبت کنند. چیزی که پیدا کردند آنها را شگفت زده کرد. در آن زمان، سامسونگ و بسیاری دیگر از تولید کنندگان ، تلویزیون های خود را در درجه اول با در نظر گرفتن مشخصات فنی مانند تصویر و صدا با کیفیت بالا طراحی میکردند. این تلویزیون ها برای نشان دادن قابلیت های فنی خود طراحی شده بودند، اما چیزی که سامسونگ هنگام بازدید از مردم متوجه شد این بود که آنها تلویزیون را بیشتر شبیه به یک شی تزئینی می بینند. از آنجایی که تلویزیون در اکثر مواقع خاموش است نمیخواهد در موقعیت مناسب تماشا باشد. در نتیجه ، به جای اینکه تلویزیون گران قیمت خود را با تمام قابلیت های تکنولوژیکی خود به نمایش بگذارند، تا حد امکان آن را پنهان می کنند.به دنبال این بینش، سامسونگ استراتژی طراحی خود را به طور اساسی تغییر داد و به منظور باریک‌تر کردن تلویزیون و ایجاد یک طراحی ظریف‌تر و مینیمالیستی قدم برداشت تا در اتاق نشیمن مردم قرار بگیرد. قابلیت‌های فنی همچنان مهم بودند، اما باید با اواویت در طراحی تلویزیون‌ها را در خانه‌های مردم جا می‌داد. «خانه» کلمه اصلی اینجا بود، و سامسونگ برای این تغییر کار زیادی انجام داد. چالشی برای بازگشت به اتاق نشیمن مثل یک نمایشگاه و نمایش "هارمونی" بود. تا سال ۲۰۰۷ سامسونگ سهم خود را در بازار جهانی تلویزیون دو برابر کرده بود، زیرا ثابت کرده بود که چگونه تلویزیون های خود را به مشتریان خود مرتبط کند.© Samsung, Fair Useتحقیقات کاربران باعث شد سامسونگ استراتژی طراحی تلویزیون خود را تغییر دهد تا بر روی ساخت طرح های مینیمالیستی و متناسب با خانه مشتری تمرکز کند. اگرچه تلویزیون ها کوچکتر نشده اند، اما همه چیزهای اضافی حذف شده است. همانطور که در اینجا می بینیم، تلویزیون به عنوان یک عکس متحرک در اندازه بزرگ۲ - برای ایجاد طرح هایی که استفاده از آن ها آسان و لذت بخش استاگر کاربر مشکلی دارد، این مشکل ماست— Steve Jobs, co-founder of Apple Computersهمه محصولات باید از سطح بالایی از قابلیت استفاده برخوردار باشند (یعنی استفاده از آنها آسان باشد)، و تست های قابلیت استفاده می تواند کمک بزرگی در دستیابی به آن باشد. مدت هاست که دیگر فناوری ابزاری فقط برای استفاده متخصصان نیست. مردم انتظار دارند که محصولات برای یادگیری و استفاده آنها آسان باشد. آنها انتظار دارند که انتخاب کنند و بتوانند از آنها استفاده کنند. فقط انتخاب کنند ، نه اینکه مجبور باشند در مورد محصولات فکر کنند. اگر از تجربه کاربری شما حس خوب نگیرند ، این احتمال وجود دارد که به سراغ محصول دیگری بروند. مگر اینکه در زمینه ای بدون رقیب کار کنید. سطح بالایی از قابلیت استفاده (و تجربه کاربری با کیفیت بالا) برای موفقیت تجاری هر محصول ضروری است. ناگفته نماند که کاربران شما را برای ایجاد یک تجربه کاربری عالی دوست خواهند داشت.ویکی وند (Wikiwand) نمونه خوبی از شرکتی است که صرفاً بر اساس ارائه یک تجربه کاربری عالی عمل می کند. محصول آنها یک افزونه مرورگر است که طراحی مقالات ویکی‌پدیا را تغییر می‌دهد تا آنها را جذاب‌تر و کاربرپسندتر کند. Wikiwand محتوای متفاوتی از ویکی‌پدیا ارائه نمی‌کند، اما این شرکت هزاران کاربر دارد که آن را به خاطر تجربه کاربری فوق‌العاده‌ای که ارائه می‌کند تحسین می‌کنند.© Wikimedia Foundation and Wikiwand, Fair Use.در سمت چپ رابط کلاسیک ویکی‌پدیا قرار دارد. در سمت راست نسخه ویکیوند همان مقاله است. محتوا یکسان است، اما طراحی متفاوت است.هنگامی که شما در حال طراحی یا توسعه یک محصول هستید، متخصص اصلی نحوه استفاده از آن و ویژگی های آن می شوید. با این حال، از آنجایی که شما محصول خود را به خوبی می شناسید، می توانید نسبت به عملکرد محصول خود که استفاده از آن دشوار است، چشم پوشی کنید. به عنوان طراح، ما به آن سطح از درک محصولات خود نیاز داریم، اما این بدان معناست که ما به راحتی می توانیم از همان دیدگاه کاربران خود فاصله بگیریم. نویسنده شخصاً در بسیاری از پروژه‌ها شرکت کرده است که در آن طراحان ایده‌های پشت رابط و عملکرد یک محصول را به خوبی می‌شناسند که جدا کردن قابل درک از غیرقابل درک برای آنها واقعاً دشوار است. این تمایل به دیدن چیزها از نقطه نظر حرفه خود - چیزی که ما آن را "دفورماسیون حرفه ای" می نامیم - و عقب نشینی نکردن برای درک واقعیت آنچه در حال وقوع است از زاویه ای تازه و کلی، اتفاقاً یک امر طبیعی است.با این حال، خوشبختانه، می‌توانید با پیروی از دستورالعمل‌ها و قوانین سرانگشتی مختلف، از بسیاری از مشکلات اجتناب کنید، اما همیشه شرایطی وجود دارد که دستورالعمل‌ها پوشش نمی‌دهند، یا دستورالعمل‌های مختلف چیزهای متفاوتی را به شما می‌گویند. همچنین ممکن است برای گروه هدفی مانند سالمندان یا کودکان طراحی کنید که در آن دستورالعمل‌های معمولی اعمال نمی‌شوند. این بدان معناست که آزمایش تجربه کاربری محصول شما همیشه ایده خوبی است. تست‌های کاربردپذیری زمانی بهترین کار را انجام می‌دهند که بخشی یکپارچه از فرآیند کار شما باشند، به طوری که محصول خود را به طور مکرر و از مراحل اولیه توسعه به بعد آزمایش کنید. آزمایش‌های اولیه کاری است که می‌توانیم روی نمونه‌های اولیه انجام دهیم - به عنوان مثال، با استفاده از کاغذ از آنجا، تا زمانی که چیزی شبیه محصول نهایی داشته باشیم، به سمت نمونه های اولیه پیشرفته تر پیش می رویم. اگر فقط زمانی شروع به آزمایش کنید که یک محصول تقریباً تمام شده دارید، در معرض خطر بسیار جدی قرار می گیرید زیرا ممکن است یافته های شما برای ایجاد تغییرات بزرگتر در محصول خیلی دیر بیاید. به عنوان مثال، اگر تمام نرم افزار انجام شده باشد یا اگر نمی توانید تاریخ انتشار خود را تغییر دهید، کارتون ساخته اس. ۳ - ایجاد درک درستی از بازگشت سرمایه با طراحی تجربه کاربریگرچه اهمیت طراحی تجربه کاربری به طور گسترده به رسمیت شناخته شده است اما طراحان و هنوز مجبورند برای یافتن منابع بجنگند تا بتوانند کار خود را انجام دهند. مدیران و سهامداران گاهی اوقات نمی توانند ارزش سرمایه گذاری در تحقیقات کاربر و طراحی UX را ببینند. طراحی UX و تحقیقات کاربر به اندازه ویژگی های جدید یا رفع اشکالات نرم افزار ملموس نیست. بنابراین، نادیده گرفتن ارزش آنها می تواند بسیار آسان تر اتفاق بیفتد. اگر منابع کمیاب شوند، UX نیز اغلب یکی از اولین حوزه هایی است که کاهش را تجربه می کند. دلیل آن این است که عواقب آن به اندازه زمانی که در توسعه یا موارد مشابه صرفه جویی می کنید احساس نمی شود. اگر در توسعه نرم‌افزار کاهشی ایجاد کنید، می‌توانید فوراً متوجه شوید که عواقب آن شامل کاهش ویژگی‌ها یا داشتن باگ در نرم‌افزار است. با این حال، اگر در UX کاهش دهید، تا زمانی که محصول شما به کاربرانتان نرسد و رقبای شما کاربران شما را به سمت خود جذب نکنند، عواقب آن را تجربه نمی کنید.ما می توانیم برای ارزش UX استدلال بیاوریم اگر بتوانیم آن را نشان دهیم که بسیار مؤثر است. اینجاست که مطالعات برای نشان دادن بازگشت سرمایه (ROI) در تلاش‌های UX ارزش پیدا میکند. اگر بتوانید نشان دهید که تغییراتی که در طراحی ایجاد کرده‌اید باعث فروش بیشتر، تعداد مشتریان بیشتر یا کارآمدتر شدن فرآیندهای کاری شده است، دلیل قوی‌تری برای سرمایه‌گذاری در UX دارید. مطالعات کاربر برای اندازه گیری تأثیر طراحی شما عمدتاً کمی است و می تواند اشکال مختلفی داشته باشد. می‌توانید تست‌های A/B را در طول توسعه انجام دهید که نسخه‌های مختلف طراحی شما را با هم مقایسه می‌کند، یا می‌توانید مطالعاتی را پس از عرضه محصول خود برای اندازه‌گیری تفاوت‌ها در الگوهای استفاده انجام دهید. با برنامه ها و صفحات وب، شما اغلب انواع مختلفی از تجزیه و تحلیل ها را ایجاد می کنید تا از الگوهای مختلف کاربر مطلع شوید.بازار آنلاین جهانی Etsy نمونه خوبی از شرکتی است که موفقیت خود را بر روی تمرکز بر تجربه مشتری در کل سفر مشتری بنا کرده است و به طور مداوم تجربه کاربر را می سنجد.به عنوان مثال، Etsy به طور معمول نسخه‌های مختلف رابط‌های کاربری را آزمایش می‌کند تا دائماً قابلیت استفاده پلتفرم و همچنین معیارهای تجاری را بهبود بخشد. ادامه موقعیت Etsy به عنوان یکی از بزرگترین بازارهای آنلاین نتیجه تمرکز دقیق آن بر قابلیت استفاده، تحقیق و آزمایش است.© Etsy and GoodUI, Fair Useموفق ترین شرکت های جهان به طور مداوم محصولات خود را آزمایش و تکرار می کنند، همانطور که در تست های A/B آنها مشهود است. در اینجا یکی از چندین موردی است که GoodUI ردیابی کرده است. می‌توانید آزمایش‌های «نشت‌شده» بیشتری را از AirBnb، Amazon، Booking، Netflix و دیگران در وب‌سایت آن‌ها ببینید.برداشت در اینجا، ما سه دلیل خوب برای انجام تحقیقات کاربر نشان داده‌ایم و به این موضوع پرداخته‌ایم که چه زمانی در فرآیند طراحی خود می‌توانید تحقیقات کاربر را ادغام کنید. با هم دوباره مرور میکنیم:تحقیقات کاربر را انجام دهید تا مطمئن شوید که محصولاتی را ایجاد می کنید که واقعاً با گروه هدف شما مرتبط هستند.تحقیقات کاربر را انجام دهید تا مطمئن شوید که محصولات شما یک تجربه کاربری عالی ارائه می دهند.برای نشان دادن بازگشت سرمایه (ROI) تلاش‌های طراحی خود، تحقیقات کاربری را مستند کنید.شما می توانید (و باید) مطالعات کاربر را در تمام مراحل فرآیند طراحی انجام دهید. شما قبل از شروع طراحی مطالعاتی انجام می دهید تا درک درستی از نیازهای گروه هدف خود داشته باشید. شما در طول توسعه آزمایش‌های تکراری انجام می‌دهید تا اطمینان حاصل کنید که تجربه کاربر در مسیر درستی قرار دارد، و می‌توانید تأثیر طراحی خود را پس از عرضه محصول خود اندازه‌گیری کنید.مراجع این مقاله و کجا میتونیم بیشتر بخونیمhttps://www.interaction-design.org/courses/user-research-methods-and-best-practiceshttps://www.interaction-design.org/courses/data-driven-design-quantitative-research-for-uxدر لینک زیر لیور گروسمن، بنیانگذار Wikiwand، رویکرد این شرکت برای طراحی یک دایره المعارف قابل استفاده تر را توضیح می دهد.http://thenextweb.com/insider/2015/03/11/how-wikiwand-plans-to-make-money-while-building-a-better-wikipedia-experience/

فرمول محرمانه - کارآموزی تجربه کاربری

سعید مقدم — Sat, 08 Oct 2022 02:27:12 +0330

توی یادگیری تجربه کاربری یک اصل وجود داره : ما همواره در حال کسب تجربه و استفاده از تجربیاتمون هستیم.تجربه نویسی تولید ماالشعیر خانگیسال هاست کلی متن ، نکته ، فرمول و مطالب رو توی جاهای مختلف مینویسم و دیگه هرگز بهشون سر نمیزنم. من که از این کار خودم لذت میبرم و چون اعتقاد دارم اون نوشتن فقط واسه بعدا سر زدن نیست و خود عمل نوشتن واسم آورده داره پس همچنان خواهم نوشت. ولی با خودم گفتم یه سری هاشو بیام یه جایی بنویسم که هم بمونه هم شاید چهارنفر دیگه هم ازش استفاده کنن. این پست یک تجربه اس ، تجربه بدست آوردن یک فرمول برای تولید یک نوشیندی جذاب. نوشیدنی که توی همه دنیا خیلی راحت میری و با پایین ترین قیمت ممکن از سوپرمارکت یا یه سری فروشگاه های دیگه میخری و استفاده میکنی و لذت میبری ، اما اینجا ایرانه! و ما خودمون انتخاب کردیم که یه جور دیگه زندگی کنیم (البته ظریفمون اینو گفته) و خیلی به دنبال حق طبیعی خودمون و حقوق اولیه انسان بودن نباشیم. پس به همین دلیل اون نوشیدنی جذاب رو نمیتونیم ساده بخریم پس بیاید از سادگی تولیدش استفاده کنیم و کلی تجربه جذاب بدست بیاریم.نکته: البته ما در ایرانه اسلامی ماءالشعیر های مختلف و متنوعی داریم و کلی هم طرفدار داره ولی غیر از قند ، مواد افزودنی و گاز و در مجموع ضرر چیزی دیگه ایی واسمون نداره. شایدم یه عده بیان بگن همه مدلش ضرر داره یا اینکه نه خیلی هم مفیده که در جواب باید گفت این حق طبیعیه ماست که خودمون انتخاب کنیم چی بخوریم.خب حالا بیاید بگم چطوری یک آبجوی خونگی و بدون مواد نگهدارنده و خوشمزه تولید کنید و از روند تولید یک محصول هم درس بگیرید و لذت ببرید.نگران نباشید حق انتخاب با شماست و میتونید آبجوی بدون (با) الکل تولید کنید و مطمئن باشید که هیچگونه خطر و یا ضرری نخواهد داشت.یادآوری : در این فرمول هیچ گونه مواد نگهدارنده ایی استفاده نمیشود پس حتما در یخچال نگهداری شود و ترجیحا در مدت زمان کمتر از یک ماه پس از تولید استفاده شودخب من اینجا طرز تهیه ۲۰ لیتر آبجو با استفاده از عصاره مالت جو رو منتشر میکنممواد مورد نیازی که باید تهیه کنید (همراه با مقدار ) :عصاره مالت جو ۲٫۷ کیلوگرمشربت فروکتوز یا همون شکر آب شده ۹۰۰ گرمعصاره کوئیلا ۴ سی سیپلت رازک تلخ کننده ۱۰ گرمزلال کننده ۱۰ سی سیمخمر فرانسوی یک قاشق غذا خوری ( اختیاری )حالا بریم که شروع کنیم حدود یک ساعت آشپزی رو۱۲ لیتر آب را توی یک قابلمه بزرگ بریزید و شعله زیرش رو روشن کنین تا به حدود ۸۰ درجه سانتیگراد برسه ( تقریبا میشه یکم قبل از جوش اومدن )عصاره مالت رو درون قابلمه بریزید و هم بزنید تا کاملا مخلوط بشه.شعله رو زیاد کنین تا تقریبا به جوش بیاد و بعدش پلت رازک (داخل کیسه پخت) رو اضافه کنین. ( ۶۰ دقیقه آشپزی از اینجا شروع میشه )نکته: پلک رازک دو مدله که میشه تهیه کرد ، یکیش جامده و قیافه و بوی جالبی نداره و راحت پیدا میشه ، یکیش هم مایعه و تقریبا سخت پیدا میشه. اگه جامد پیدا کردین همون ۱۰ گرم اگه مایعش رو پیدا کردین ۲ سی سی ازش استفاده کنین.نکته: کیسه پخت هم یه جورایی شبیه جوراب نازک زنانه اس ، کلا یه پارچه کیسه طور تمیزه که پلک رازک رو توش میریزن سرش رو گره میزنن و میندازن توی قابلمه و تا آخر آشپزی همونتو هست و آخرش میارنش بیرون ( پلک رازک باعث میشه آبجو تلخ بشه )در طی ۶۰ دقیقه آشپزی همواره شربت داخل دیگ رو ملایم هم بزنید.۲۵ دقیقه مانده به انتهای پخت، شربت فروکتوز ( یا همون شکر آب شده ) رو اضافه کنین.۱۰ دقیقه مانده به انتهای پخت، عصاره کوئیلا را اضافه کنین.در انتهای ۶۰ دقیقه پخت یک لیتر از شربت رو از قابلمه خارج کنین و داخل بطری بریزید و درب آن را محکم ببندید و جداگانه در یخچال نگهداری کنین.در انتهای ۶۰ دقیقه پخت مخمر فعال شده را اضافه کنید و بهم بزنید . ( اختیاری )در پایان پخت، باید شربت بلافاصله سرد بشه ، می تونین با اضافه نمودن آب سرد تا رسیدن حجم شربت به ۱۹ لیتر برای سرد کردن شربت استفاده کنین.حالا زلال کننده را اضافه کنید و به مدت ۱ تا ۲ ساعت صبر کنید تا پروتئین ها ته نشین بشن، سپس شربت را با استفاده از شلنگ به ظرف دیگری منتقل کنید به طوری که پروتئینهای ته نشین شده تا حد امکان از شربت جدا شوند. این عمل باعث میشود در نهایت ماءالشعیر شفافتری به دست آید.درب ظرف را کاملا بسته پلمپ کنید و لوله هواگیری را به آن متصل کنید.در این مرحله ماءالشعیر اولیه آماده شده است که با توجه به میزان مخمر و شفافیت مطلوب باید به مدت ۱۰ الی ۱۴ روز در این حالت و در محلی به دور از نور و در دمای ۲۵ تا ۳۵ درجه نگهداری شود.بعد از این مدت درب ظرف را باز کرده و شربت را با استفاده از شلنگ به ظرف دیگری منتقل کنید به طوری که مجدد پروتئینهای ته نشین شده و تا حد امکان از شربت جدا شوند.همان یک لیتر شربت داخل یخچال را به ظرف اضافه کنید و هم بزنید.شربت را به شیشه های مورد نظر خود وارد کنید و در هر شیشه یک تا سه حبه قند اضافه کنید. ( اگر از مخمر استفاده نکرده اید میتونید این مرحله رو انجام ندید )درب شیشه ها را کاملا پلپ نمایید و در محلی با دمای معمولی به مدت ۷ الی ۱۰ روز نگهداری کنید.آبجوی شما پس از گذشت این زمان آماده استفاده است. ( از اینجا به بعد حتما در یخچال نگهداری کنین )نکته : هرچه آبجوی شما پس از این فرایند بین دمای سرد یخچال و دمای نرمال اتاق جابجا شود میزان گاز و فشار داخل شیشه ها افزایش پیدا میکند.برای داشتن آبجویی با گاز فراوان پس از خروج از یخچال یک یا دو ساعت در دمای اتاق نگهداری کنید و سپس استفاده نمایید و برای آبجویی با گاز متعادل و خنک تر همان هنگام خروج از یخچال استفاده کنید.نکته تکراری و مهم : با توجه به عدم استفاده از مواد نگهدارنده و همچنین عدم انجام عملیات پاستوریزاسیون در این فرمول باید آبجو در یخچال نگهداری شود.لازم به ذکر است تضمینی جهت تهیه مقدار کمتر یا بیشتر با نسبت زدن روی این مقادیر نیست و احتمال خراب شدن خروجی بالا میباشد.سرفصل آخر دوره تجربه کاربری

تاثیر Community در پیدا کردن کار UX

سعید مقدم — Sun, 18 Sep 2022 22:50:51 +0430

کار پیدا کردن اصلا ساده نیست، مخصوصا اگه تازه کار هم باشی، منم میدونم تازه کار بودن یعنی چی و پیدا کردن اولین شغل بیشتر از اونچه که فکر میکنید پیچیده است.حتی وقتی یه کار خوب پیدا میکنیم احتمالا چند هفته طول میکشه تا از مراحل مصاحبه و استخدامی عبور کنیم. این یعنی رقابت شدیدی برای پیدا کردن کار در لایه جونیور وجود داره و همه این فاکتور ها شما رو به این فکر فرو میبره که پیدا کردن کار اول خیلی سخته.حتما میدونید که عنوان شغلی طراح تجربه کاربری (یا همون UX designer) توی همین چند ساله اخیر رشد کرده، شکل گرفته و الان هزاران نفر توی دنیا با همین عنوان مشغول به کار هستن. در نتیجه شرکت ها به دنبال نیروی متخصص و با استعداد توی این زمینه هستن تا بتونن از مهارت این افراد در پروژه هاشون استفاده کنن.خب، راه های زیادی برای پیدا کردن شغل وجود داره و همه مدل جذب نیرو هم از طرف شرکت ها وجود داره از نیروهای قراردادی و پاره وقت گرفته تا کارمند ثابت و یا حتی نیرو های آزادکار (freelancer) که پروژه ها واسشون برونسپاری میشن. اگه از سطح دانش و توانایی شما صرف نظر کنیم برای رسیدن به یک پوزیشن طراح تجربه کاربری، نیازه که شما کاملا جدی آمادگی شروع کار رو داشته باشید.نکته: باید بدانید که علاوه بر پیدا کردن شغل در مسیر های متعارف و معمولی ، شما میتوانید در جوامع طراحی (designers community) هم پیشنهاد های خوبی پیدا کنید.حالا بریم جوامع درست مربوط به خودمون رو پیدا کنیمیه کوچولو به فکر فرو بریم که از این جوامع چه انتظاری داریم؟ میخوایم بریم ایده هامون رو به اشتراک بزاریم و از دانش دیگران یاد بگیریم؟ یا فعلا هدفمون پیدا کردن شغله ، پس با در نظر گرفتن هدفمون وارد میشیم و کنکاش میکنیم. ولی جوین شدن به این جوامع همزمان واسه شما میتونه کلی مفید باشه.در جریان باشید که توی فیسبوک، تلگرام، اسلک و حتی دیسکورد کلی گروه و جامعه برای طراحان وجود داره که تمرکزشون روی آموزش، پشتیبانی، معرفی و کلی خدمات مفید دیگه است و روزانه کلی درخواست و آگهی‌های شغلی توی همین جوامع منتشر میشه. پس خوبه که عضو این جوامع بشیم و با توجه به هدفمون توی پست ها و پیام ها به دنبال آگهی های شغلی باشیم.اما وقتی به یک جامعه جدید جوین میشیم، در اولین قدم باید کیفیت سنجی کنیم و چندتا نکته رو چک کنیم. مثلا : خوندن پست ها و محتوای داخل آنها. پست هارو به ترتیب جدید به قدیمی تنظیم کنیم تا ببینیم اخرین پست‌ها چه زمانی منتشر شدن، و آیا این جامعه فعال است ؟ پست ها روزانه یا هفتگی منتشر میشود یا خیلی وقته که هیچ خبری نیست و کسی فعالیتی نمیکنه. و یا حتی پاسخی به کامنت ها داده شده یا نه.اگر جامعه زنده و فعالی نبود حتما ازش خارج بشید و وقتتون رو اونجا هدر ندید.سعی کنید به تعداد زیادی از جوامع جوین بشید و اونارو کیفیت سنجی کنید تنها راه بررسی جوامع همین جوین شدن و پیدا کردنشونه. در نهایت باید شما حداقل دو تا سه جامعه فعال و پویا پیدا کنید که عضوشون بمونید و ازشون بهره ببرید.من لینک چندتا از همین جوامع خوب رو به اشتراک میزارم ولی دلیل نمیشه که زمانی که شما این متن رو میخونید هنوز جامعه فعال و خوبی باقی مونده باشن، پس خودتون اعتبار سنجی کنید و به دنبال جوامع بهتر و بیشتر هم باشید.نمونه کار بسازید و در محل درست منتشر کنیدشنیدید میگن الان عصر ارتباطات و سوشال مدیاست؟ :)) حقیقتا راست میگن و اصلا یک جمله کلیشه ایی و خوشگل بدون پشتوانه نیست، شما همواره به ویترین احتیاج دارید و همین سوشال مدیاها بهترین ویترین امروزیست.رسانه‌های اجتماعی بزرگ‌ترین جامعه ارتباطاتی جهان هستند و می‌توانند جادو کنند. جوامع تخصصی معمولاً توسط متخصصان با تجربه اداره می‌شوند که به افراد کمک می‌کنند تا مشکلات خود را در محیطی امن و مملو از افراد متخصص به شور و حل مشکلات بپردازند.نه فقط UX در هر زمینه ایی که میخواهید کار خودتون رو شروع کنید باید به مخاطبین و کارفرماها نمونه کار نشون بدید تا بتونن تا حدی با شما و سبک کارتون آشنا بشن، حالا هر عنوان کاری به یک شکلی نمونه کارهای خودش رو به نمایش میگذاره.برای اینکه بدونین روش یا متدهای ارائه در زمینه شغلی شما چطوری هست به کسانی که هم مسیر شما هستن و تجربه دارن مراجعه کنید و از نمونه کارهاشون یاد بگیرید که بهترین راه ارائه برای شما چیه و چطور باید انجامش بدید.حتما الان دارید میگید من که تازه کارم و هنوز کاری انجام ندادم چیکار کنم

وقتی مینویسی که خواننده داری! وقتی خواننده داری که بنویسی.

سعید مقدم — Wed, 27 Jul 2022 02:57:06 +0430

من نه زیاد کتاب میخونم و نه عادت به نوشتن دارم ، البته از کوتاه نوشتن های توییتر خوشم میاد و گاهی فول انرژی و گاهی خالیه خالی بهش سر میزنم.زمان به من آموخت که باید نوشت ، باید دیده شد و باید بنویسی تا خونده بشی. تا ننویسی و تلاش نکنی واسه دیده شدن دیده هم نمیشی.و این کاربر تصمیم گرفت که دیده بشه. بیشتر باشه و به مرور از خودش اثر به جای بزاره.و این متن کوتاه شروع نوشتن های من در ویرگول خواهد بود. البته نوشتن ها نه به این معنی که دیگه قراره بیام هر روز متن بنویسم ، نه. یعنی گاهی کمی بنویسم از کارم و تجربه هام شاید به درد چند نفر دیگه هم بخوره.راستی من سعید مقدم طراح هستم ( چون فارسی سعید مقدم زیاده آخرش طراح داره ) و از سال ۱۳۸۸ با ۲۰ سال سن وارد دنیای کار و رقابت شدم و خیلی تجربه کسب کردم اما به میزان همه این سال ها ویترینی واسه نمایش ندارم ولی هیچوقت دیر نیست و میتونم بگم این همه تجربه میتونه چیزای مهمی واسه گفتن داشته باشه. من طراح رابط و تجربه کاربری هستم و این روزها طراح محصول هم به عنوان شغلی من گفته میشه.واسه مطالب بعدی کلی نگفته ها دارم ، از تجربه مصاحبه و استخدامی گرفته تا مهاجرت و تجربه کار خارجی ، نقد کردن درآمد دلاری و کلی مطالب مرتبط و نا مرتبط دیگه. امیدوارم مخاطب خودم رو پیدا کنم و پیکسلی به دنیای آدما کمک کرده باشم.