دویدن

تجربه‌ی کاملی دارم از راه‌های مختلف تلاش برای مداوم دویدن. همشون شکست خورد. تا پنج ماه پیش که کم کم راه‌حلش را فهمیدم. این نوشته را برای کسانی می‌نویسم که مثل من دوست دارن بدون ولی نمیدونن چطور یا از کجا باید شروع کرد. تو این نوشته توضیح می‌دم چطور از صفر شروع کردم و الان می‌تونم ده کیلومتر را در یک جلسه نسبتا راحت بدوم.
ادامه‌ی نوشته “دویدن”

چطور با داکر در محیطی یکسان با پروداکشن کد بنویسیم و پابلیش کنیم. قسمت دوم

در یاداشت قبلی نوشتم که چطور کانتینر دیتابیس و اپلیکیشن را در محیط دولوپمنت اجرا کنیم. در این یادداشت اپلیکیشن را به پروداکشن انتقال می‌دهیم و CI و CD مختصری را پیاده می‌کنیم.

ادامه‌ی نوشته “چطور با داکر در محیطی یکسان با پروداکشن کد بنویسیم و پابلیش کنیم. قسمت دوم”

چطور با داکر در محیطی یکسان با پروداکشن کد بنویسیم و پابلیش کنیم. قسمت اول

در سال ۱۹۵۶ مالکوم مک‌لین اولین کانتینر برای حمل توسط کشتی‌های باربری را اختراع کرد. قبل از اون بارها با  پانزده برابر هزینه بیشتر به طور دستی بارگیری و تخلیه می‌شدند. با اختراع کانتینر مشکل دزدی از بارها، از دست رفتن بارها حین جابجایی، مشکل چیدمان بهینه در کشتی‌ها و از همه مهمتر کند بودن پروسه بارگیری فراموش شد. یک اختراع انقلابی که صنعت را به کلی متحول کرد. در دنیای نرم‌افزارها اگر از VM‌ها بگذریم، تکنولوژی داکر به نظر می‌رسه همین تاثیر را خواهد داشت. در نهایت تیم‌های توسعه نرم‌افزاری فقط مسئول کد نوشتن نیستند. مسئولیت مهم‌تر ایجاد پروسه صحیح آپدیت‌های مداوم با کمترین زمان و هزینه‌ی روانی و مالی است.

در این نوشته نشون میدهم چطور یک پروژه روبی (اپلیکیشن به اضافه دیتابیس) را به داکر منتقل کنیم. در نوشته بعدی ایجاد روال آپدیت پروداکشن را بررسی می‌کنم.
ادامه‌ی نوشته “چطور با داکر در محیطی یکسان با پروداکشن کد بنویسیم و پابلیش کنیم. قسمت اول”

تصمیم گیری بر اساس اطلاعات با کمک کیبانا و الستیک

 

همیشه گفته می‌شه تیم‌ها باید بر اساس اطلاعات تصمیم گیری کنند یا به اصطلاح data-driven باشند. فکر نمی‌کنم کسی با این ایده مشکلی داشته باشه. پس چرا کمتر جایی می‌بینیم واقعا بر اساس اطلاعات تحلیل کنند و تصمیم بگیرند؟

  • تیم به اهمیت اطلاعاتی که در اختیار داره یا می‌تونه داشته باشه واقف نیست
  • تیم وقت نداره ابزارهای جمع آوری و نمایش اطلاعات را بسازه
  • مدیران تجربه‌ی خودشون رو ارجح بر اطلاعات ورودی می‌دونن
  • تصمیم‌گیری بر عهده‌ی یک نفره و اون یک نفر هم حوصله یا زمان کافی برای تحلیل اطلاعات ندارد

استک الستیک مجموعه ابزارهای فوق‌العاده‌ای را  به صورت رایگان و اپن سورس عرضه کرده که می‌تونه راه حل دو مورد اول باشه. زمانی برای نصب نمی‌گیره، کاملا مستقل از سیستم‌ها کار می‌کنه و از همه مهم‌تر احتیاجی به تغییر در هیچ کجای سیستم نیست. در ادامه در مورد این زنجیره محصولات الستیک صحبت می‌کنم.  تمرکز این نوشته هم روی بیزینس‌های آنلاین است. ادامه‌ی نوشته “تصمیم گیری بر اساس اطلاعات با کمک کیبانا و الستیک”

آزمونی کوتاه برای سنجش سلامت تیم‌

این پست خلاصه‌ای از یکی از فصل‌های کتاب Managing Humans است. در این فصل مایکل لوپ آزمونی را برای سنجش سلامت یک تیم مهندسی مطرح می‌کند. این آزمون البته برگرفته از آزمون دیگری به نام دوازه قدم برای نوشتن کد بهتر است. ابتدا سوالات این تست آورده شده و در ادامه توضیحی برای هر سوال و نحوه‌ی امتیازدهی.

ادامه‌ی نوشته “آزمونی کوتاه برای سنجش سلامت تیم‌”

چطور با دولوپرها کار کنیم؟

یادآوری کنیم چه مشکلی را برای چه شخصی داریم حل می‌کنیم
منظور از دولوپر یا توسعه دهنده کسی است که می‌تونه سیستم یا چیزی که وجود نداره را خلق کنه و یا می‌تونه ازش نگهداری کنه و توسعه‌اش بده. بنابراین کدنویس‌ها فقط دولوپر محسوب نمی‌شوند، همه‌ی کسانی که احتیاج دارید تا یک محصول دیجیتال بسازید رو می‌شه دولوپر حساب کرد. چه برنامه نویس باشند و چه طراح یو آی، طراح یو ایکس و یا هر تخصص دیگه‌ای.
کار کردن چه به صورت تیمی یا فردی با دولوپرها فرهنگ خاص خودش را داره. آدابی که اگر بتونیم رعایت کنیم، تونستیم تا حدی محیط لازم برای ساخت یک محصول خوب را فراهم کنیم. این پست برای اسکرام مسترها، پروداکت اونرها یا هر شخص دیگه‌ای که با تیم‌های توسعه کار می‌کنه نوشته شده.

ادامه‌ی نوشته “چطور با دولوپرها کار کنیم؟”

سایت رامین

ramin
داستان اینجوری شروع شد که رامین ایده‌ای داشت در مورد تایم‌لاین و این‌که چطور این رو پیوند بده با سایت شخصی‌اش. از طرفی من هم دنبال پروژه ای بودم که عصرها و آخر هفته‌ها بهش برسم. اینطوری شد که شروع کردیم به کار و سایت ساخته شد.

ادامه‌ی نوشته “سایت رامین”

بدون سازمان اجایل، اسکرام امکان پذیر است؟

وقتی میخواهیم محصولی که می‌سازیم تحت فرهنگ اجایل و با متدهایی نظیر اسکرام ساخته بشود، تیم دولوپمنت تنها جایی نیست که باید فرهنگ اجایل را درک کنند. در حقیقت اجایل (و متد پیاده سازی‌ اسکرام) تنها ابزارهایی برای ساخت محصول نیستند. شاید بهتر باشه اجایل را به عنوان فرهنگ کاری تعریف کرد. فرهنگی که اگر می‌خوایم اسکرام را پیاده کنیم، مجبوریم در نقاط کلیدی سازمان جا بیندازیم.

چه اتفاقی می‍افتد اگر افراد کلیدی سازمان درک مناسبی از این فرهنگ نداشته باشند؟
ادامه‌ی نوشته “بدون سازمان اجایل، اسکرام امکان پذیر است؟”

ریورک یا چطور با لذت کار کنیم

Rework

کتاب ریورک را تیم 37 سیگنالز نوشته‌اند. این تیم ظرف مدت ده سال توانسته تیم جمع و جور چابکی داشته باشه، محصولات موفقی چه از لحاظ مالی و چه تکنولوژی خلق کنه. شاخص ترین محصولی که ساخته اند بیس کمپ است که تقریبا 11 سال پیش عرضه اش کردند. بیس کمپ نرم افزار آنلاینی است برای گرداندن یک پروژه به صورت آنلاین. برای تیم هایی که ریموت کار می‌کنند یا ساختار خاصی برای به اشتراک گذاری وظایف و ایده ها و اسناد ندارند میتواند ایده آل باشه.

چطور این همه سال دووم آوردند و تبدیل به سازمانی شاخص در رده‌ی خودشون شدند؟ به نظرم خیلی فراتر و مهم‌تر از مسائل تکنیکی، به اخلاق و قوانین شخصی کاری اهمیت دادند.
دو مقاله کوتاه زیر نمونه‌ی ساده‌‌ی همین اخلاق کاری است. اولی درباره این صحبت می‌کند که جواب سریع بهتر از جواب کامل است و  دومی این که چرا قهرمان بودن خوب نیست.
ادامه‌ی نوشته “ریورک یا چطور با لذت کار کنیم”

سلام

این اولین نوشته‌ی اینجاست. مدت‌ها قبل وبلاگ می‌نوشتم، درباره‌ی مسائل شخصی و غیره. حالا تصمیم گرفتم حرفه‌ای‌تر و در زمینه‌ی چیزهایی که علاقه دارم و اغلب به زبان فارسی اثری ازشون ندیدم بنویسم.

این موضوع‌ها احتمالا بیشتر درباره اینترنت و دیجیتال و چیزهای جالبی که میخونم و میبینم در همین احوال خواهد بود. اینجا دفترچه خاطرات نخواهد بود، یکی از فرق‌های اساسی با دوران وبلاگ نویسی سابق، بنابراین خیلی خوشحال می‌شم نوشته‌هام و غیره سر صحبت رو چه در کامنت‌های اینجا یا هرجای دیگه باز کنه تا حداقل مطلب بیشتر برای خودم هضم بشه : )