رویداد «استارتاپ ویکند» یکی از رویدادهای جذابی است که مخصوصا برای برنامه نویسان می‌تواند بسیار مفید باشد. در این رویداد سه نوع ثبت‌نام وجود دارد.
- ثبت‌نام به عنوان «برنامه‌نویس»
- ثبت نام به عنوان «گرافیست»
- ثبت‌نام به عنوان «ایده‌پرداز یا بیزنس»
تیم‌هایی که در این رویداد شکل می‌گیرند در عرض ۳ روز محصولات شگفت‌انگیزی خلق می‌کنند که حاصل همکاری تیمی بسیار تنگاتنگ آنها طی این ۳ روز و به کمک منتورها است. برنامه‌نویسان در این رویداد تجربیات فوق‌العاده‌ای در زمینه ساخت یک «استارتاپ» و توسعه یک محصول جدید کسب می‌کنند.
اگر شما یک برنامه‌نویس هستید و دوست دارید در آینده صاحب یک بیزنس باشید این رویداد می‌تواند تاثیر فوق‌العاده‌ای در مسیر شما بگذارد و توصیه می‌شود در این رویداد شرکت کنید.

www.modotech.ir

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

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

___

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

https://www.youtube.com/watch?v=qI_g07C_Q5I

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/nsXP30e8yCn


#علیرضا_وفی (https://ow.ly/Vna930dsUGr)


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

___

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

۱. توضیحات اسکات آلن در مورد مرتب‌سازی کدها
#refactoring #architecture #aspnet
https://t.iss.one/SoftwarePhilosophy/885
https://t.iss.one/SoftwarePhilosophy/886

۲. استاندارد طراحی URL از لحاظ UX
#ux #webapi #architecture
https://t.iss.one/SoftwarePhilosophy/887

۳. آشنایی با زبان Elm
#elm #javascript #haskel
https://t.iss.one/SoftwarePhilosophy/888
https://t.iss.one/SoftwarePhilosophy/889

۴. استارتاپ ویکند مدوتک ۲
#startupweekend
https://t.iss.one/SoftwarePhilosophy/890
https://t.iss.one/SoftwarePhilosophy/891

۵. معرفی دیتابیس‌های NoSQL و بررسی انواع آن‌ها
#nosql
https://t.iss.one/SoftwarePhilosophy/892
https://t.iss.one/SoftwarePhilosophy/893


@SoftwarePhilosophy

ـــــــــــ

امروزه در بسیاری از پروژه‌ها از Web Sockets استفاده می‌شود. در این نوع ارتباط در کنار ایجاد ارتباطی از سرور به کلاینت که از آن برای ارسال پیام‌ها استفاده می‌شود، ارتباطی از کلاینت به سرور نیز باز می‌شود که عموما مورد استفاده قرار نمی‌گیرد. ضمن اینکه با توجه به متفاوت بودن پروتکل Web Sockets با HTTP، بسیاری از مواردی که بر روی پروتکل HTTP تنظیم می‌کنیم (مانند CORS - Compression‌ و ...) بر روی Web Sockets اعمال نمی‌شود. Server Sent Events در قیاس با Web Sockets گزینه‌ای مناسب‌تر برای اکثریت پروژه‌ها می‌باشد که کاملا بر اساس پروتکل HTTP ایجاد شده و سربار کمتری نیز دارد. لینک زیر حاوی توضیحی نسبتا مفصل از مزایایی است که Server Sent Events می‌تواند برای پروژه شما به ارمغان آورد.

https://docs.bit-framework.com/docs/design-backgrounds/server-sent-events-or-web-sockets.html

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/2nBc30ebM8o

#یاسر_مرادی (https://ow.ly/Ph6w30ebM21)


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

___

در وب‌سایت‌های چند صفحه‌ای برای هدر که باید در همه صفحات وجود داشته باشد چه باید کرد؟ آیا باید در هر صفحه دوباره هدر را نوشت؟ اینطور که خیلی بد است، با هر تغییر هدر باید تمام هدرهای صفحات مختلف تغییر کند...
در ui router anguler مفهومی به نام nested states , nested views وجود دارد که در آن می‌توان هدر را به عنوان مستر با کنترولر مربوط به خود در نظر گرفت و محتویات صفحه به صورت دیتیل با کنترولر مخصوص خود قرار بگیرد... به این معنی که با تغییر صفحه هدر جای خود باقی مانده و با تغییر url، فقط محتویات آن عوض می‌شود.
استفاده از این ویژگی کمک زیادی حذف کدهای اضافی از صفحات کرده و خوانایی و کارآمدی آن را بالا می‌برد.
لینک زیر توضیح کاملی از چگونگی انجام این کار است.

https://github.com/angular-ui/ui-router/wiki/Nested-States-and-Nested-Views

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/qS7V30ecsZ2

#مریم_داودی (https://ow.ly/HGkG309B7de)


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

___

بررسی کدها و اجزای نرم افزار از نقطه نظر معماری و طراحی، یافتن وابستگی میان اجزای کد، پیدا کردن مشکلات در کد در زمان اجرا و خواندن کدهای دیگران یکی از مسایلی بوده که همیشه برنامه نویسان و طراحان سیستم‌ها با آن روبرو هستند. یکی از قابلیت‌های پنهان و بسیار قدرتمند Visual Studio که از نسخه ۲۰۱۵ ارائه شده است Code Map می‌باشد که با Visualize کردن باعث می‌شود کارهای گفته شده به سادگی بیشتر انجام پذیرد.

https://channel9.msdn.com/Events/TechEd/Europe/2014/DEV-B346

https://docs.microsoft.com/en-us/visualstudio/modeling/use-code-maps-to-debug-your-applications

https://msdn.microsoft.com/en-us/library/dd409453.aspx

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/Kjey30edWbn

#علیرضا_وفی (https://ow.ly/Vna930dsUGr)

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

___

تاکنون اتصال به دستگاه‌های بلوتوث تنها از طریق native apps امکان پذیر بود. Web Bluetooth API این امکان را برای web browser ها نیز فراهم آورده است. کتابخانه‌هایی برای کار با این API‌ ها در Node‌و Angular و Polymer نیز پیاده‌سازی شده است. لینک زیر توضیحاتی در مورد این API ها و کاربری آن ارايه می‌دهد.

https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/6Gq530efr9v

#شراره_لطفی (https://ow.ly/xvC530dx8xL)

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

___

از مسایل مهم در هر نرم افزار وب، علاوه بر زیرساخت‌های شبکه و سیستم عامل، ایمن‌سازی نرم افزار می‌باشد. NWebSec یک کتابخانه مبتنی بر .NET می‌باشد که قابل استفاده در ASP.NET و ASP.NET Core نیز بوده و با استفاده از Security Headers و سایر روش‌ها به امنیت بیشتر نرم افزارها کمک می‌کند.

https://docs.nwebsec.com/en/latest/nwebsec/getting-started.html

https://www.dotnetnoob.com/2012/09/security-through-http-response-headers.html

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/umRg30ehqWV


#علیرضا_وفی (https://ow.ly/Vna930dsUGr)

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

___

کارایی و سرعت EntityFramework از گذشته تا به امروز از معضلاتی است که در پروژه‌ها با آن مواجه می‌شویم. همه‌ی راحتی و سرعتی که در زمان توسعه نرم افزار با استفاده از EF CodeFirst به دست می‌آوریم کمابیش برای بهبود سرعت اجرای queryهای وحشتناکی که بعضا توسط EF تولید می‌شود صرف می‌کنیم. ابزارهایی از قبیل Rhino Entity Framework Profiler و LINQ Pad در این راه یاری رسان بوده‌اند.اما ZZZ Projects راه حل بهتری ارایه داده‌اند. آن‌ها کتابخانه‌هایی روی EF ارايه داده‌اند که امکان عملیات CRUD و Merge بصورت batch با سرعت بالا را فراهم می‌آورند. همچنین امکان به روز رسانی بدون بارگزاری موجودیت‌ها از دیتابیس و ارسال چند Query بصورت batch به دیتابیس و بسیاری امکانات دیگر که در لینکهای زیر توضیحات آن آمده است.

https://www.zzzprojects.com/

https://entityframework-extensions.net/

https://entityframework-plus.net/
همچنین از دیگر محدودیت های EF Codefirst عدم امکان استفاده از SQL Function ها و Stored Procedure هایی با خروجی‌های متفاوت است. لینک زیر کتابخانه EntityFramework.Functions را معرفی می‌کند که به کمک آن با این محدودیت EF Codefirst خداحافظی می‌کنید.

https://weblogs.asp.net/Dixin/EntityFramework.Functions

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/3nz630ejcU6

#شراره_لطفی (https://ow.ly/xvC530dx8xL)

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

___

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

۱. مزایای Server Sent Events برای پروژه‌های تحت وب
#dotnet #web
https://t.iss.one/SoftwarePhilosophy/895

۲. ایجاد هدر برای وبسایت‌های چند صفحه‌ای به منظور سرعت بخشی به لود شدن صفحات
#web
https://t.iss.one/SoftwarePhilosophy/896

۳. آشنایی با Code Map در Visual Studio
#visualstudio
https://t.iss.one/SoftwarePhilosophy/897

۴. اتصال به دستگاه‌های بلوتوث از طریق web browser به وسلیه Web Bluetooth API
#web #bluetooth
https://t.iss.one/SoftwarePhilosophy/898

۵. ایمن‌سازی نرم افزار در دات نت به وسیله کتابخانه NWebSec
#security #dotnet
https://t.iss.one/SoftwarePhilosophy/899

۶. چند راه حل برای افزایش کارایی و سرعت EntityFramework
#dotnet #entityframework #performance
https://t.iss.one/SoftwarePhilosophy/900

ـــــــــــ

@SoftwarePhilosophy

قانون Conways در استفاده از مایکروسرویس‌ها در معماری نرم‌افزار بسیار قانون جالبی است. این روز‌ها در بسیاری از تیم‌های نرم‌افزاری بحث استفاده یا عدم استفاده از مایکروسرویس‌ها در معماری آینده تیم مطرح است. قانون Conways به طور کلی در مورد سیستم‌ها صحبت می‌کند. این قانون می‌گوید:
«اگر تیم و یا سازمانی در حال طراحی یک سیستم است (نه لزوما سیستم اطلاعاتی) طراحی نهایی آنها احتمالا شبیه ساختار ارتباطی همان سازمان است.»

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

این قانون گرچه اثبات نشده، ولی به طور ضمنی می‌گوید اگر می‌خواهید سراغ مایکروسرویس بروید، باید کل تیمتان هم مایکروسرویسی شود.

https://www.thoughtworks.com/insights/blog/demystifying-conways-law

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/8byp30emn9u


#مهران_داودی (https://ow.ly/GwIl309lFEm)

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

___

برگزاری جلسات بازنگری اسپرینت به شیوه ای نو

یکی از شکایتهای افراد تیم، تکراری شدن جلسات بازنگری اسپرینت است، "دائم چی خوب بود - چی بد بود و ... خوب که چی؟!"
یکی از هنرهای اسکرام مستر خوب پیدا کردن پرکتیس‌های مناسب برای تیم خود است.

یکی از این منابع سایت زیر است :

🛠 https://www.funretrospectives.com

این سایت حاوی شیوه های جدید و تازه برای برگزاری جلسات بازنگری اسپرینت است.

@iranagile

پنجمین نسخه از Swarm دوست‌داشتنی

احتمالا اپلیکیشن Foursquare همچنین Swarm را می‌شناسید. برای من Foursquare نمونه یک محصول بسیار موفق‌ست (حتی بالاتر از Instagram و Facebook)‌ که پیشرفت و پا گرفتنش را در ایران، لحظه به لحظه پیگیری کرده‌ام. هوشمندی بینظیری که در Gamification داشت و روش‌های اغواگرانه‌ای که برای وادار کردن کاربر به فعالیت استفاده می‌کرد از مهمترین دلایلی بود که من را به این محصول علاقمند می‌کرد.

بعدها که اپلیکیشن Swarm با هدف جدا کردن تکه‌ی شبکه اجتماعی Foursquare معرفی شد، فعالیت و پیگیری‌های من هم کمی کمتر شد ولی این تیم همیشه تاثیر خود را در کار حرفه‌ای من داشته‌ست. بطوریکه وقتی خواندم که اپلیکیشن جدید Foursquare بطور کامل در Sketch App طراحی شده، مهاجرت به این ابزار را برای خود یک الزام می‌دیدم.

تیم دیزاین این مجموعه، هم‌اکنون نسخه 5.0 از اپلیکیشن Swarm را منتشر کردند که دستخوش تغییراتی بسیاری شده‌است.
مقاله امروز، داستانی‌ست از زبان یکی از طراحان محصول این تیم که به بررسی روند این بازطراحی می‌پردازد و نکات جالبی در آن نهفته‌ست:
- می‌توان متوجه دید و دغدغه‌های یک تیم دیزاین در این سطح، در روند بازطراحی محصول شد.
- می‌توانید نمونه‌ای از Style Guideهایی را که در تیم‌های دیزاین دیگر ساخته می‌شود، ببینید.
- متوجه می‌شوید که یکی از وظایف شما به عنوان دیزاینر، به اشتراک‌گذاری ایده‌ها و طرح‌ها و گرفتن بازخوردهاست. در هر سطحی که باشید.
و …

پیشنهاد می‌کنم همین حالا این داستان زیبا را مطالعه کنید.

https://medium.com/foursquare-direct/how-we-designed-foursquare-swarm-5-0-d774b3164f3f

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

#تیم #بازطراحی #محصول #Swarm
@Dexign دیزاین

___

اگر دوستانی دارید که نه تنها برنامه نویس هستند، بلکه اعتقاد دارید «مهندس نرم‌افزار» هم هستند، آنها را به کانال @SoftwarePhilosophy دعوت کنید.
این پیغام را برای آنها Forward کنید.

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

یک تصمیم «به اندازه کافی خوب» به سوی «بهترین تصمیم»

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

فرض کنید می‌خواهید شغل بعدی خود را انتخاب کنید و تصمیم به رفتن به یک شرکت جدید دارید. واقعا آیا این بهترین تصمیم است؟
• این تصمیم می‌تواند در حال حاضر (سال ۲۰۱۵) بهترین تصمیم شما باشد.
• در انتهای ماه ممکن است به این نتیجه برسید که این تصمیم، نسبتا خوب بوده‌است زیرا شغل پر استرسی است.
• در سال ۲۰۱۶ ممکن است به این نتیجه برسید که تصمیم بدی گرفته‌اید چون شغل بسیار سختی است.
• در سال ۲۰۱۷ ممکن است به این نتیجه برسید که بدترین تصمیم ممکن را گرفته‌اید زیرا علی‌رقم تمام زحماتتان شرکت ورشکست شده!
• و در نهایت در سال ۲۰۲۰ به این نتیجه برسید که بهترین تصمیم تمام عمرتان را گرفته‌اید، زیرا با استفاده از تجربه‌ای که از آن شرکت به دست آورده‌اید حالا مدیرعامل شرکت مایکروسافت شده‌اید!

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

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

https://mehrandvd.me/2016/12/12/good-enough-decision-towards-best-decision/

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

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

___

Good Enough Decisio

شایع‌ترین دلیل تخمین زمان اشتباه یک پروژه

تخمین زمان یک پروژه کار آسانی نیست، مخصوصا اگر بخواهید خیلی دقیق باشید. ولی اغلب موارد مشکل تخمین این نیست که خیلی دقیق نیست، بلکه مشکلش این است که خیلی پرت است!
یکی از شایع‌ترین عواملی که باعث می‌شود تخمین زمانی یک پروژه خیلی اشتباه باشد، تفاوت قائل نشدن بین دو مفهوم خیلی مهم است: «تخمین زمان» و «تخمین کار».
«تخمین زمان» مفهومی است که مدیران پروژه دوست دارند در مورد آن صحبت کنند. وقتی صحبت می‌کنند دائما به دنبال شنیدن تخمین زمانی هستند. برای مثال جمله‌ای مانند «این کار تا پنجشنبه هفته بعد انجام می‌شود» جمله‌ای است که زمان انجام شدن کار را تخمین می‌زند.
در مقابل «تخمین کار» مفهومی است که معمولا برنامه‌نویسان دوست دارند در مورد آن صحبت کنند. آنها ترجیح می‌دهند بگویند که این کار به چقدر زمان نیاز دارد. مثلا کاری است که به ۳ روز زمان نیاز دارد. مثلا جمله «این کار به یک هفته کار نیاز دارد» به این معنی نیست که یک هفته دیگر این کار تمام می‌شود و صرفا حجم کار مورد نیاز بیان شده.

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

پست زیر این دو مفهوم را معرفی کرده و تفاوت آن‌ها را در مدیریت پروژه شرح داده‌است.

https://mehrandvd.me/2017/08/02/effort-vs-time-estimation/

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/958i30erVZs

#مهران_داودی (https://ow.ly/GwIl309lFEm)

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

___

راز تولید چابک در دل بزرگ‌ترین بانک ایران
اسد صفری؛ ماهنامه عصر تراکنش

بام یکی از بهترین و متفاوت‌ترین اینترنت‌بانک‌های ایرانی است که به‌صورت چابک تولید شده است. صحبت از ۶۰ میلیون حساب در بانک ملی ایران است، از ۱۷۰۰ نفر نیروی شرکت سداد، حدود ۲۰۰ پروژهٔ تعریف‌شدهٔ همزمان در این شرکت و همکاری بیش از ۲۲ برنامه‌نویس و طراح روی یک پروژه، همهٔ این اعداد نشان از بزرگی موجودیتی دارد که می‌خواهد حرکت کند اما حرکت در آن به‌مراتب کندتر از حرکت در شرکت‌های کوچک و پویا است.

https://way2pay.ir/73221