مدیریت نسخه‌ها در طراحی RESTFul Web Api ها در معماری نرم‌افزارهای نسل جدید به یک مفهوم مهم تبدیل شده‌است. از آنجاییکه «تغییر» و بهبود یکی از فاکتور‌های جدا نشدنی در نرم‌افزار است و در نسل جدید نرم‌افزارها تغییر بسیار سریعتر اتفاق می‌افتند، مدیریت آن بسیار مهم است.
مدیریت نسخه‌ها در Web Api حتی می‌تواند در طراحی آن تاثیر بگذارد. برای مثال طراحی api ممکن است به روش‌های زیر باشد:
• /api/foo?api-version=1.0
• /api/foo?api-version=2.0-Alpha
• /api/foo?api-version=2015-05-01.3.0
• /api/v1/foo
• /api/v2.0-Alpha/foo
• /api/v2015-05-01.3.0/foo

در لینک زیر «اسکات هانسلمن» کتابخانه‌ای را برای مدیریت versioning در .NET را معرفی کرده‌است که معماری بسیار خوبی دارد و به راحتی می‌توان از آن استفاده کرد.

http://www.hanselman.com/blog/ASPNETCoreRESTfulWebAPIVersioningMadeEasy.aspx

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilosophy

___

#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

‍۱. معرفی استارتاپ ویکند
#startupweekend

https://telegram.me/SoftwarePhilosophy/585
https://telegram.me/SoftwarePhilosophy/586


۲. قورباغه را دوباره اختراع نکنید
#management

https://telegram.me/SoftwarePhilosophy/589


۳. کتابخانه LinqToTwitter
#linq #twitter

https://telegram.me/SoftwarePhilosophy/591


۴. امکانات اضافه شده به Java 9
#java

https://telegram.me/SoftwarePhilosophy/593


۵. مفهوم Onboarding و تاثیر آن در عملکرد تیم‌ها
#management

https://telegram.me/SoftwarePhilosophy/594


۶. معرفی کتابخانه‌ای در .NET برای مدیریت versioning
#dotnet #webapi #versioning

https://telegram.me/SoftwarePhilosophy/595


ـــــــــــ
@SoftwarePhilosophy

50 Shades of #FAFAFA
یا اشتباهاتی که همه ما دیزاینرها انجام دادیم

برای پروژه ۵ رنگ انتخاب کنید.
قوانین تایپوگرافی خودتون رو ابداع نکنید!
خاکستری‌ها رو کمی تیره‌تر کنید.
تمامی جاهایی که از فونت light استفاده کردین رو انتخاب کرده و همگی رو ضخیم‌تر کنید.
و …
وقتی غرق در طراحی هستیم، گاهی فراموش می‌کنیم که دیزاین ما ابزاری خواهد بود برای انسان‌ها که بتونن با استفاده از اون، کارهایی رو راحتتر انجام بدن. این فراموشی باعث میشه دیزاین‌هایی رو انجام بدیم که در وهله اول زیبا به نظر برسه ولی وقتی قراره به یک محصول تبدیل بشه، در روند پیاده‌سازی‌ش رفته رفته زیبایی خودش رو از دست بده.

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

در این مقاله با آقای Jon Moore همراه می‌شیم تا لیستی از اشتباهاتی رو که دیزاینرها انجام میدن، مرور کنیم. مرور این لیست به ما کمک می‌کنه که روند و نقشه راه دیزاین محصولات با دید بازتری به اشتباهات احتمالی، تعریف کنیم و از تقلید کورکورانه دیزاین‌های انجام شده دوری کنیم.

البته ناگفته نمونه که شخصا با بعضی از مواردی که ذکر شده موافق نیستم ولی بطور کلی به موارد بسیار خوبی اشاره کردن و به شدت خوندش رو توصیه می‌کنم.

https://medium.com/@jon.moore/fifty-shades-of-fafafa-eaa903e36b9c

(زمان حدودی مطالعه ۱۵ دقیقه)

#طراحی_محصول #اشتباهات_دیزاینرها #معرفی_مقاله
@HamDesign هَم دیزاین

هنگام استفاده از ORM ها در پروژه‌های بزرگ سرعت یکی از عوامل مهم در انتخاب ORM است. غالبا «سرعت» و «امکانات» در مقابل یکدیگر قرار دارند. هر چه به امکانات و قدرت یک ORM اضافه شود از سرعت آن کم می‌شود و بر عکس. البته اکثر ORM های امروز از سرعت قابل قبولی برخوردارند و مقایسه سرعت آنها فقط در داده‌های با حجم زیاد و تناوب بالا مطرح می‌شود. Dapper یکی از Micro ORM های بسیار سریع و مطرح در پلتفرم .net است. این فریم‌ورک بسیار ساده و کوچک نگه داشته شده است و بین برنامه نویسان بسیار محبوب است. جالب است بدانید سایت StackOverflow از این ORM استفاده می‌کند. لینک زیر این Micro ORM را به طور مختصر معرفی کرده و به مقایسه آن با سایر ORM ها پرداخته‌است.

http://www.c-sharpcorner.com/UploadFile/e4e3f7/dapper-king-of-micro-orm-C-Sharp-net/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilosophy

___

#پست_مجدد این پست تا به حال بیش از ۱۰۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

همانند سمت سرور، سمت کلینت نیز storage هایی جهت ذخیره اطلاعات وجود دارد که با توجه به نیاز می توان از آنها استفاده کرد.
از جمله این storage ها، می‌توان به session storage, local storage و cookie اشاره کرد.
دانستن تفاوت بین این سه storage و میزان دسترسی به اطلاعات آنها می‌تواند به انتخاب مناسب در موقعیت‌های متفاوت کمک کند.
باید بدانید که Session storage مربوط به هر تب از browser است بنابراین در تب جدید دیگر وجود ندارد.
و نیز Local storage حافظه‌ای مربوط به browser است، بنابراین اطلاعات مربوط به آن در تمام تب های browser در دسترس خواهد بود و حتی با باز و بسته شدن browser نیز پاک نخواهد شد. اطلاعات موجود در local storage در browser تا زمانی که به طور دستی history مربوط به browser پاک شود یا از طریق جاوا اسکریپت این حافظه خالی شود وجود خواهد داشت.
در انتها Cookie حافظه ای است که مانند local storage عمل می کند با این تفاوت که اطلاعات موجود در cookie از سمت سرور نیز در دسترس بوده و در واقع در سمت سرور می توان از اطلاعات cookie استفاده کرد.
مقاله زیر به طور کامل تفاوت این سه حافظه را ذکر مثال بیان کرده است.

http://www.c-sharpcorner.com/uploadfile/cd7c2e/difference-between-local-storage-session-storage-ans-cookie

#مریم_داودی

لینکدین:
https://www.linkedin.com/in/maryam-davoudi-7913565a

کانال تلگرام:
@SoftwarePhilosophy

___

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

http://www.agilebuddha.com/agile/agile-estimation-8-steps-to-successful-story-point-estimation/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilosophy

___

نمونه‌ای جالب و جسورانه از تاثیر «مشاهده» در دیزاین gov.uk

محدودیت‌ها و تعصب‌های ذهنی، یکی از بزرگترین دشمنان دیزاینرها هستند. محدودیت‌های ذهن به ما اجازه نمیدن که خرق عادت کرده و Out of box فکر کنیم، تعصب‌ها بدتر هستن و حتی بعضا اجازه نمیدن که ما چیزی رو که میبینیم، باور کنیم.

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

مقاله امروز یه مقاله گزارشی هست درباره بهبود Radio Buttonها و Checkboxها در سایت gov.uk.
این مقاله از دو جهت به نظرم بسیار بسیار هیجان‌انگیز هست. یک اینکه لزوم انجام بهبودهایی که اشاره میشه از طریق مشاهده کار کاربران بوده، و دو اینکه احتمالا دیزاین نهایی به سلیقه بسیاری از ماها خوش نمیاد ولی بسیار کاربردی هست.
در این مقاله مشاهده‌ای برای نحوه برخورد کاربران هنگام مواجهه با Radio Buttonها و Checkboxها انجام شده و متوجه شدند که کاربران برای انتخاب یک گزینه در یک لیست، بصورت ناخودآگاه به جای کلیک روی متن اون گزینه، اصرار دارند که روی Radio Button یا Checkbox کوچکی که در اول سطر قرار داره کلیک کنند.

دیزاینرهای پروژه، در دیزاین قبلی‌شون، با در نظر گرفتن قانون Fitts، متن گزینه‌ها رو هم قابل کلیک کرده بودند. اون‌ها حتی کادری دور گزینه‌ها قرار داده بودند که بصورت ضمنی، ناحیه قابل کلیک رو مشخص می‌کرد. با این حال باز هم کاربران به کلیک روی Radio Button یا Checkbox علاقه بیشتری نشون می‌دادند.
جالبه نه؟ پیش‌فرض‌های ذهنی ما دیزاینرها تاثیر بسیار زیادی در تجربه کاربران از سرویس ما و در نتیجه میزان موفق سرویس داره.

پیشنهاد می‌کنم برای مطالعه بیشتر این بحث و البته دیدن دیزاینی که دیزاینرهای gov.uk بعد از مشاهداتشون بهش رسیدن، به لینک زیر برید.
کامنت‌های زیر پست هم برای مطالعه پیشنهاد میشه. :)

پ. ن.
قانون Fitts بصورت خلاصه میگه سرعت دسترسی به یک آیتم، تابعی هست از فاصله از اون آیتم و اندازه آیتم.

https://designnotes.blog.gov.uk/2016/11/30/weve-updated-the-radios-and-checkboxes-on-gov-uk/

(زمان حدودی مطالعه ۵ دقیقه)

#تجربه_کاربری #گزارش
@HamDesign هَم دیزاین

#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. اشتباهاتی که همه ما دیزاینرها انجام می‌دهیم (هم دیزاین)
#design
https://telegram.me/SoftwarePhilosophy/598

۲. معرفی Dapper به عنوان یک Micro ORM
#orm #dapper
https://telegram.me/SoftwarePhilosophy/599

۳. معرفی و مقایسه session storage، local storage و cookie
#clientstorage
https://telegram.me/SoftwarePhilosophy/601

۴. قدم‌های مناسب برای رسیدن به تخمین موفق در پروژه
#estimate
https://telegram.me/SoftwarePhilosophy/602

۵. نمونه‌ای جسورانه از تاثیر مشاهده در دیزاین (هم دیزاین)
#design
https://telegram.me/SoftwarePhilosophy/603

ـــــــــــ
@SoftwarePhilosophy

مدل اسپاتیفای را کپی نکنید

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

@iranagile
@Iranagile

☑️☑️☑️
https://www.infoq.com/news/2016/10/no-spotify-model

الگوی Async Retry Pattern یکی از الگوهایی است که در برنامه‌نویسی برنامه‌های نسل جدید بسیار مهم است. بسیاری دستگاه‌ها و بسترهای جدید شبکه مطمئنی ندارند. برای مثال اینترنت روی گوشی ممکن است بسته به موقعیت قطع و وصل شود و یا کیفیت پایینی داشته باشد. در این بسترها عملیات باید در صورت ناموفق بودن چند بار تکرار شوند و یا اصلاحا retry شود. ابزارهایی که برای retry طراحی شده‌اند این امکان را می‌دهند تا بتوان یک کار را با چند بار retry کردن انجام داد. برای مثال:
var maxRetryAttempts = 3;
var pauseBetweenFailures = TimeSpan.FromSeconds(2);

RetryHelper.RetryOnException(
maxRetryAttempts,
pauseBetweenFailures,
() => {
httpClient.Delete("https://example.com/api/products/1");
}
);

کد بالا برای شرایط کدهای همگام مناسب است ولی اگر بخواهید این کد را به صورت async اجرا کنید و از httpClient.DeleteAsync() استفاده کنید کد مناسبی نیست.

مقاله زیر ضمن تشریح این الگو، توضیح داده‌است که چطور می‌توان با استفاده از async/await الگوی retry pattern را پیاده‌سازی کرد.

https://alastaircrabtree.com/implementing-the-retry-pattern-for-async-tasks-in-c/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilosophy

___

در اسکرام تاکید شده است که مالک محصول یک نفر است و او باید تصمیم های مهم تجاری را بگیرد، اما وقتی پروژه بزرگ می شود آیا یک نفر می تواند بر کل دامنه و تیم ها احاطه داشته باشد؟
در پروژه های بزرگ می توانیم، و باید، مسئولیت ها و عملکرد این نقش شکسته و توزیع شود.
برای درک بهتر، رستوران های بزرگ تجسم کنید، آشپز داریم و سر آشپز.
🍲🍲🍲

🏂🏂🏂

@iranagile
@iranagile

http://www.mountaingoatsoftware.com/blog/the-chief-product-owner-on-large-agile-projects

مدتیست کمپین #NoEstimates در توییتر توجه مهندسین نرم‌افزار را به خود جلب کرده‌است. این کمپین فلسفه جالبی دارد، افراد در این فلسفه اعتقاد دارند story ها نباید estimate شوند!! در این فلسفه تنها تخمین درست این است که آیا یک story به اندازه کافی کوچک هست یا نه. اگر یک story هنوز به اندازه کافی کوچک نیست، باید به تکه‌های کوچکتر شکسته شود. در این تیم‌ها به جای مجموع زمان باقیمانده یا point های باقیمانده از «تعداد» استوری‌های باقیمانده استفاده می‌شود.
مقاله زیر این مفهوم را در ترکیب با اسکرام توضیح داده و در مورد مزایا و معایب این فلسفه بحث کرده‌است.

http://innolution.com/blog/to-estimate-or-not-to-estimate-that-is-the-controversy

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilosophy

___

یکی از صحبت های ناتمام در دنیای چابک مسئله Code Review است؟

اصولا نیازی به Code Review داریم؟ آیا فقط یک نفر باید این کار را انجام دهد؟ چه زمانی باید انجام شود؟

تجربه تیم اطلسین استرالیا می تواند به این سوالات جواب دهد

🛠🛠

@iranagile
@iranagile


https://www.atlassian.com/agile/code-reviews

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

https://responsivedesign.is/articles/why-you-dont-need-device-specific-breakpoints

#مریم_داودی

لینکدین:
https://www.linkedin.com/in/maryam-davoudi-7913565a

کانال تلگرام:
@SoftwarePhilosophy


___

برنامه‌نویسی VR یا Virtual Reality و دنیای آن بسیار هیجان‌انگیز است. همچنین تجهیزات IoT یا Internet of Things برای برنامه‌نویسان بسیار جذاب است. در «استارتاپ ویکند مد و تکنولوژی» امکان استفاده از این تجهیزات مهیا شده‌است. در این رویداد یک دستگاه Gear VR و همچنین چند دستگاه Beacon برای برنامه‌نویسی مهیا شده‌است. شما می‌توایند برنامه‌های خود را روی این دستگاه‌ها نیز به داوران ارائه کنید.

با توجه به اینکه اعضای کانال @SoftwarePhilosophy عمدتا جز برنامه‌نویسان حرفه‌ای و یا مدیران فنی شرکت‌ها می‌باشند، امکان ثبت‌نام برنامه‌نویسان پر انرژی این کانال با تخفیف ۳۰.۰۰۰ تومانی در «استارتاپ ویکند مد و تکنولوژی» فراهم شده‌است. شما می‌توانید از کد تخفیف زیر در هنگام ثبت‌نام استفاده کنید.

کد تخفیف: SoftwarePhilosophy

لینک ثبت‌نام: http://modotech.ir

ـ

#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. مدل اسپاتیفای را کپی نکنید. (iranagile)
#srcum
https://telegram.me/SoftwarePhilosophy/605

۲. الگوی Async Retry Pattern
#async #csharp
https://telegram.me/SoftwarePhilosophy/606

۳. آیا در پروژه‌های بزرگ هم یک نفر تصمیم گیرنده است؟ (iranagile)
#srcum
https://telegram.me/SoftwarePhilosophy/607

۴. کمپین #NoEstimates و ترکیب آن با اسکرام
#scrum #estimate
https://telegram.me/SoftwarePhilosophy/608

۵. پرسش و پاسخ‌هایی در زمینه Code Review
#scrum #codereview
https://telegram.me/SoftwarePhilosophy/609

۶. طراحی responsive و نحوه انتخاب نقاط شکست
#responsive
https://telegram.me/SoftwarePhilosophy/610

۷. کد تخفیف «استارتاپ ویکند» برای اعضای کانال SoftwarePhilosophy

https://telegram.me/SoftwarePhilosophy/611

ـــــــــــ
@SoftwarePhilosophy

مفهوم Asynchronous Programming در Java تاثیر بسیار خوبی در عملکرد نرم‌افزارهای بزرگ و قابلیت Scale شدن آنها دارد. در این مدل thread های استفاده شده در عملیات I/O Blocking باعث می‌شود resource های ارزشمند سرور به هدر نرود و از آنها به درستی استفاده شود. یکی از مشکلات این سبک برنامه‌نویسی «سخت بودن» آن است. نوشتن این نوع کدها معمولا پیچیده‌تر از کدهای معمولی است. مهمترین مفهوم در این سبک برنامه‌نویسی مفهوم Feature است که به معنی کاری است که در آینده انجام خواهد شد و نتیجه آن بعدا آماده می‌شود. برای مثال Feature<String> کاری است که در آینده یک نتیجه از نوع String خواهد برگرداند.

پست زیر در مورد این مفهوم و best practice های استفاده از آن توضیح داده‌است.

http://www.developer.com/java/data/best-practices-of-asynchronous-programming-with-java.html

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilosophy

___

تخفیف برای اعضای کانال @SoftwarePhilosophy

کد تخفیف: SoftwarePhilosophy

ثبت‌نام در: http://modotech.ir

این تخفیف تا روز دوشنبه اعتبار دارد و برای تعداد محدودی قابل استفاده است.

#پست_مجدد این پست تا به حال بیش از ۱۳۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.