Software Philosophy
3.46K subscribers
160 photos
41 videos
1.54K links
چکیده‌ای از مفاهیم به روز مهندسی نرم افزار برای مهندسین نرم‌افزار.
معماری نوین نرم‌افزار، تکنولوژی‌های برنامه نویسی جدید
Download Telegram
«شما می توانید عناوبن را خرید و فروش کنید، در یک دوره کوتاه مدت شرکت کنید و یک واژه به عنوان شغلی خود اضافه کنید. اما نمی توانید تجربه را بخرید. تنها می توانید آن را بیاموزید». این جملات بخشی از بلاگ “Agile is Dead” است که در سال 2014 توسط یکی از تئوریسین هایAgile نوشته است. خواندن این مطلب هم برای عاشقان این متد و هم برای دیگر دوستان خالی از لطف نیست.

https://pragdave.me/blog/2014/03/04/time-to-kill-agile

#کاروان_جافی

لینکدین:
https://uk.linkedin.com/in/karvan-jafi-96897027

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



___
اگر تا به حال با ASP.NET Core RC1 کار می‌کردید و الان می‌خواهید با نسخه جدید یعنی RC2 کار کنید نیاز دارید به نسخه جدید مهاجرت کنید. مهاجرت به نسخه جدید معمولا از اینکه آن را از ابتدا نصب کنید سخت‌تر است. لینک زیر به صورت قدم به قدم مراحل مهاجرت به نسخه جدید و شروع توسعه سیستم با آن را توضیح داده‌است.

https://ievangelist.github.io/blog/migrating-to-rc2

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

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



___
Forwarded from Iran .Net
در مورد فرهنگ سازمانی، توسعه چابک و با کیفیت، ایجاد کشش های قوی بین تیم توسعه، سازمان و مشتری حرف های خوب و قشنگی می شود زد و با آن ها شعار داد. ما هم که مملکت شاعر مسلک و شعار زده ای هستیم و مستعد!

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

اینکه چگونه چابک شویم، چگونه محیط کاری فراهم کنیم تا رضایت حداکثری کارکنان مان را جذب کنیم و بتوانیم با ایجاد حب و علاقه در کارکنان، فرهنگی را به وجود بیاوریم که همه سازمان به گونه ای یکپارچه خود را بپندارد و اهداف سازمان همان اهداف نفرات شود، کار دشواری است. مایکروسافت از معدود شرکت هایی است که چابکی یا Agility در سطح Enterprise پیاده سازی کرده است و معتقد است برای دستیابی به این اهداف، یکی از ضروریات معماری داخلی ساختمان و اجزا و امکانات موجود در محیط می باشد.
در ساختمان های 16 و 17 مقر Redmond که تیم های Cloud و Enterprise مایکروسافت قرار گرفته اند، معماری به غایت مدرنی به کار گرفته شده که می توانید تصاویر و توضیحات و چرایی ها را در مطلب زیر ببینید.

دقت کنید که در محیط کار مدرن مایکروسافت، یکی از اهداف سرعت در گردش اطلاعات و همکاری حداکثری می باشد. به همین خاطر محیط کار آن ها Office Free یا بدون اتاق می باشد و تیم های مختلف در محیط های بزرگی به نام "همسایگی و Neigboorhoods" در کنار هم قرار گرفته اند. همچنین مدیران و کارکنان تفاوتی در امکانات و فاصله فیزیکیِ محلِ کارشان با سایرین ندارند و همه کنار هم کار می کنند.

https://news.microsoft.com/stories/b16/
Forwarded from Software Philosophy
شرکت اوراکل اعلام کرد زمان ارائه Java 9 تا سال ۲۰۱۷ به تعویق انداخته شده‌است. علت این تصمیم پروژه Jigsaw اعلام شده‌است. هدف پروژه Jigsaw ماژولار کردن و شکستن JRE به Interoperable Components است. به این ترتیب با انجام این پروژه هر برنامه می‌تواند JRE شخصی‌سازی شده‌تری داشته باشد که در نتیجه می‌توان برنامه‌های جاوا را به راحتی به قطعات کوچک محساباتی Scale‌ کرد که منجر به بهبود سرعت و امنیت می‌شود. در این زمینه Mark Reinhold‌ معمار ارشد پلتفرم جاوا در شرکت اوراکل گفته است که برنامه‌نویسان علاقه بسیار زیادی به این رویکرد از طریق فیدبک‌ها ارائه داده‌اند.

https://blog.takipi.com/jigsaw-delays-push-java-9-launch-date-to-2017/

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

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



___
Forwarded from Software Philosophy
ضد الگوی ‌Blind Developer یا «برنامه نویس کور» یک ضد الگوی شایع در تیم‌های نرم‌افزاری است که معمولا از زبان معمار نرم‌افزار با این جمله تشریح می‌شود: «هیچوقت به برنامه‌نویس اجازه ندهید با مشتری صحبت کند». این مفهوم به این دلیل به وجود آمده که معمولا افراد غیر برنامه‌نویس بهتر نیازمندی کاربر را درک می‌کنند. البته این واقعیت اغلب صادق است ولی نکته‌ای که به آن توجه نشده‌است تغییرات است. تغییرات در نیازمندی باعث افزایش هزینه توسعه می‌شود. در جریان نبودن برنامه‌نویسان از بیزنس معمولا باعث می‌شود این تغییرات هزینه بسیار بیشتری داشته باشد. همچنین باعث می‌شود بسیاری از ریسک‌ها خیلی دیر و حتی هنگام تحویل محصول نمایان شوند.

در لینک زیر این ضد الگو بیشتر توضیح داده شده‌است.

https://sourcemaking.com/antipatterns/mushroom-management

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

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



___
Forwarded from Software Philosophy
نسل جدید بازی‌ها و همچنین نرم‌افزارها در راه است. این نسل جدید بر پایه VR یا «واقعیت مجازی» بنا شده‌است. از آنجایی که این مفهوم هنوز خیلی جدید است خیلی مطالب هنوز در مورد آن دقیق و مشخص نشده است. از جمله این مفاهیم استانداردهای UX است که امروزه در محیط‌های دیگر خیلی به آن پرداخته شده‌است. واقعیت مجازی محیطی کاملا متفاوت با محیط‌های قبلی است و نیازمند باز طراحی این استانداردها است. لینک زیر استراتژی‌هایی را برای UX بهتر در بازی‌های کامپیوتری مبتنی بر VR ارائه داده‌است.

https://uxmag.com/articles/4-strategies-for-mastering-ux-in-virtual-reality-games

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

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



___
Forwarded from Software Philosophy
همیشه یکی از مهمترین کارهایی که باید توسط یک معمار نرم‌افزار انجام شود و معمولا هم اصلا انجام نمی‌شود(!) فکر کردن به نحوه انتقال به نسخه جدید است. در این فرایند معمولا با کلماتی مانند Deployment یا Migration سر و کار دارید. پست زیر توسط یکی از برنامه‌نویسان سایت StackOverflow نوشته‌شده است و توضیح می‌دهد فرایند Deployment این سایت در سال 2016 چگونه طراحی شده‌است. نحوه برخورد با سورس کدها، مراحلی که نیاز به یک انسان دارد، مدیریت Branch ها، Database Migration، مدیریت Translation ها و نکات بسیاری را برای یادگیری دارد.

https://nickcraver.com/blog/2016/05/03/stack-overflow-how-we-do-deployment-2016-edition/

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

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



___
ساخت یک لیست Generic متشکل از Anonymous Type، آیا تا به حال به این فکر کرده‌اید که چگونه می‌تواند چنین کاری انجام داد؟ البته این کار اگر انجام شود احتمالا نشانه یک طراحی اشتباه است. ولی جالب است که این سوال در StackOverflow‌ مطرح شده‌بود و یکی از طراحان زبان C# (Kirill Osenkov) این کار را نشدنی دانسته بود. سپس از طرف چند نفر جواب جالبی برای این کار ارائه شد که به تکنیک Casting By Example شناخته می‌شود. بعد از این اتفاق Osenkov این روش را در بلاگ خود شرح داده‌است.

https://kirillosenkov.blogspot.fr/2008/01/how-to-create-generic-list-of-anonymous.html

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

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



___
Forwarded from Software Philosophy
معماری‌های نوین نرم‌افزار برای حل مسائلی به وجود آمده‌اند که قبلا وجود نداشتند. برای مثال شبکه‌های اجتماعی که در آن میلیون‌ها لایک و کامنت در ثانیه را هندل می‌کنند و همیشه با بیلیون‌ها رکورد سر و کار دارند مسائلی است که جدید هستند و با معماری و ابزارهای قبل قابل حل نیستند. دیتابیس‌های NoSql و PolyGlot ابزارهای جدیدی هستند که در معماری‌های جدید از آنها استفاده می‌شود. مقاله زیر از Dino Esposito معمار با سابقه نرم‌افزار، توضیح می‌دهد که چگونه با استفاده از Historical CRUD و Event Sourcing می‌توان راه‌حلی برای این گونه مسائل ارائه داد.

https://msdn.microsoft.com/en-us/magazine/mt703431

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

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


___
Forwarded from Software Philosophy
یکی از مباحثی که همیشه در تشکیل تیم‌های نرم‌افزاری مطرح است، انتخاب زبان برنامه‌نویسی و یا تکنولوژی‌های مورد استفاده است. مقایسه محصولات موفق و نا موفق نشان می‌دهد هیچکدام از آنها صرفا با یک تکنولوژی و یا یک زبان خاص نوشته نشده‌اند. برای مثال سیستم‌های موفق زیادی وجود دارند که با Java و یا C# نوشته شده‌اند. همچنین سیستم‌های بی کیفیت زیادی نیز وجود دارد که با Java و یا C# نوشته شده‌اند. این حقیقت نشان می‌دهد دلیل موفقیت یا شکست سیستم‌ها نمی‌تواند زبان برنامه‌نویسی باشد. مقاله زیر توضیح می‌دهد که چطور طرز فکر برنامه‌نویس‌ها موفقیت و یا شکست یک سیستم را رقم می‌زند.

https://mehrandvd.me/2015/10/15/software-quality-comes-from-people-not-languages/

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


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

___
با شدت گرفتن روند تغییرات در درخواست‌های مشتریان، نیازمندی‌های پروژه‌ها و مسائل مربوط به پشتیبانی محصولات در دهه‌های اخیر، بسیاری از شرکت ها پی بردند که هماهنگ شدن با بازار با استفاده از فرآیند های تجاری قدیمی امکان پذیر نیست. لذا بسیاری از توسعه دهندگان و مدیران محصولات به متدلوژی‌های جدید مانند Agile روی آوردند. در حال حاضر این متدلوژی با وجود نواقصی که به آن وارد است بیشترین طرفدار و بازدهی را به خصوص در میان شرکت های کامپیوتری داشته است.
اما لزوما استفاده از یک متدلوژی، روش یا ابزار موفق، دلیل بر موفق شدن ما نیست، لذا آشنایی با متدلوژی ها و رویکردهایی مانند Lean، Scrum یا Kanban و انتخاب بهترین روش بین آن ها با توجه به نوع محصول، مشتری و شرایط شرکتی که در آن مشغول به فعالیت هستیم یک ضرورت است.
مطالعه لینک زیر می تواند در انتخاب هوشمندانه‌تر این متدولوژی ها بسیار کمک کننده باشد.

https://realtimeboard.com/blog/how-to-choose-between-agile-lean-scrum-and-kanban-which-methodology-is-the-best/#.V18eTlUrLDe

#کاروان_جافی

لینکدین:
https://uk.linkedin.com/in/karvan-jafi-96897027

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



___
Forwarded from Software Philosophy
اگر دوستانی دارید که نه تنها برنامه نویس هستند، بلکه اعتقاد دارند «مهندس نرم‌افزار» هم هستند، آنها را به کانال @SoftwarePhilosophy دعوت کنید و این پیغام را برای آنها Forward کنید.
Forwarded from Software Philosophy
تا امروز فیدبک‌های خیلی خوبی از شما دوستان گرفتیم. بر اساس فیدبک‌های شما تصمیم گرفتیم که پست‌های این کانال را در سه دسته بندی پست کنیم:
۱) مطالب مهندسی و معماری نرم‌افزار و مدیریت تیم‌های نرم‌افزاری
۲) مطالب مربوط به آخرین تکنولوژی‌ها
۳) مطالب مربوط به تکنولوژی‌های مرسوم که در شرکت‌ها استفاده می‌شود.

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

لطفا اگر نظر، پیشنهاد، انتقاد و یا هرگونه فیدبکی نسبت به این کانال دارید، در توئیتر بنویسید. مطمئن باشید ما آنها را می‌خوانیم. (در توئیتر https://twitter.com/mehrandvd را منشن کنید و از هشتگ #SoftwarePhilosophy استفاده کنید)
Forwarded from Software Philosophy
در مورد WebApi مطالب زیادی وجود دارد. ولی پست زیر با جزئیات خیلی زیادی کل چرخه پیغام‌های HTTP را در WebApi Pipeline به طور کاملا عملی بررسی کرده‌است. خواندن این مقاله می‌تواند خیلی به درک مفهوم Pipeline در این معماری‌ها کمک کند. نکته خوب این مقاله این است که در آن OWIN که یک معماری بسیار عالی برای استفاده و پیاده سازی WebApi است توضیح داده شده‌است. معماری OWIN کمک می‌کند بتوانید WebApi را مستقل از جایی که قرار است در آن Host شود طراحی کنید و برای مثال بتوانید آن را حتی در یک برنامه Console Application استفاده کنید.

https://www.c-sharpcorner.com/article/webapi-pipeline-revealed-a-true-practical-approach/

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

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



___
Forwarded from Iran .Net
با گسترش روز افزون استفاده از اپلیکشن های موبایل و یا وب اپلیکشن های تک صفحه ای مواجه هستیم. در این نوع از نرم افزار ها طبیعتا خبری از ارسال کوکی و Session نخواهد بود. پس چطور این نرم افزار ها در سمت سرور مورد تصدیق هویت و دسترسی قرار می گیرند!
در این جاست که با مفهوم Token و علی الخصوص JWT Token ها رو به رو خواهیم شد. این Token ها که جایگزین کوکی ها می شوند، مزایایی را برای ما به همراه خواهند آورد که با کوکی ها مقدور نبود. مزایایی مانند مقیاس پذیر شدن نرم افزار سمت سرور، عدم نیاز به ذخیره سازی Session های کاربران در حافظه یا پایگاه داده، Stateless بودن و سرعت بیشتر، استفاده از Claim ها و ....

در مقاله زیر به زبانی شیوا Token ها و تفاوت شان با کوکی ها توضیح داده شده است.

https://auth0.com/blog/2016/05/31/cookies-vs-tokens-definitive-guide
پروژه اوپن-سورس شدن محصولات مایکروسافت از سال ۲۰۱۴ شروع شده‌است. پروژه‌های مهمی مانند .Net Framework، .Net Core، کامپایلر C# و بسیاری دیگر در GitHub توسعه داده می‌شوند. یکی از چیزهای جذابی که در این میان بسیار آموزنده است، مستنداتی است که در این پروژه‌ها اوپن-سورس شده. مستنداتی مانند «جلسات طراحی»، «Code Review» از این قبیل هستند. مطالعه این مستندات از این جهت جالب است که مثلا می‌توانید بفهمید چرا در زبان C# تصمیم گرفته‌شده است قابلیت X‌ اینطوری باشد و در جلسات چه گذشته. همچنین برای مثال می‌توانید ببینید که جلساتی که برای طراحی C# 7.0 برگزار می‌شود چگونه پیش می‌رود و کدام فیچرها در چه وضعیتی قرار دارند.
لینک زیر در مورد پروژه‌های اوپن-سورس مایکروسافت صحبت کرده و لینک‌های خوبی به مستندات طراحی آنها معرفی کرده است.

https://www.c-sharpcorner.com/article/a-deeper-look-into-open-source-net-development

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

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



___
Forwarded from Software Philosophy
یکی دیگر از موارد مهم در طراحی UI‌ برنامه‌های موبایل توجه به Landscape و یا Portrait بودن است. که هر کدام از این حالت‌ها ویژگی‌های خاص خود را دارند که طراح میتواند به خوبی از این ویژگی‌ها استفاده کند.
مثلا برنامه‌ای را در نظر بگیرد که برای بورس نوشته شده است. در حالت Portrait یک گرید نمایش داده میشود که شاخص بورس در هفته جاری را نشان میدهد. یک UI معمولی همین گرید را در حالت Landscape نمایش میدهد ولی یک UI خوب یک نمودار میله‌ای را نمایش میدهد.

در پست زیر Patternهای مختلفی را که برنامه‌های مختلف در نمایش Landscape استفاده کرده‌اند را بررسی کرده است.

https://www.smashingmagazine.com/2012/08/designing-device-orientation-portrait-landscape/

#افشین_علیزاده
لینکدین:
https://ir.linkedin.com/in/afshinalizadehbehjati

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



___
Forwarded from Software Philosophy
به نظر می‌رسد که تکنولوژی آنقدرها هم که به نظر می‌رسد به موفقیت پروژه‌ها کمک نمی‌کند! برای مثال در کتاب «Peopleware: Productive Projects and Teams» عامل مهمتری را برای موفقیت یک پروژه معرفی کرده‌است: «اعتماد افراد به یکدیگر». در تیمی که افراد به یکدیگر اعتماد نداشته باشند ریسک خیلی بالایی متوجه پروژه می‌شود و آینده آن به شدت در خطر خواهد بود.

Better technology seemed unlikely to be much help. If a group of people who had to work together didn’t trust each other.

از کتاب
Peopleware: Productive Projects and Teams
نوشته:
Tom DeMarco & Timothy Lister


#افشین_علیزاده
لینکدین:
https://ir.linkedin.com/in/afshinalizadehbehjati

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



___
Forwarded from Software Philosophy
موقعیت‌های زیر را در نظر بگیرید:
۱) راننده‌ای که اگر به موقع به فرودگاه نرسد، پرواز را از دست می‌دهد.
۲) عابر پیاده‌ای که عجله دارد.
۳) خانم خانه‌داری که مهمان‌ها یک ساعت زودتر آمده‌اند و گرسنه هستند.
احتمالا هر یک از ما حالت مشابهی را تجربه کردیم که در آن یک محدودیت زمانی وجود دارد و ناخواسته قوانینی را که رعایت می‌کردیم، دیگر رعایت نمی‌کنیم.
۱) به احتمال زیاد دیگر به تابلو ورود ممنوع و یا حق تقدیم توجهی نمی‌کند .
۲) به چراغ قرمز توجه نمی‌کند و از پل عابر پیاده نیز استفاده نمی‌کند .
۳) از کیفیت غذا کاسته شده است.
برنامه‌نویس نیز از این قاعده مستثنی نیست. اگر تحت فشار زمان‌بندی پروژه باشد سریع‌تر کار میکند ولی به خاطر اینکه سر وقت بتواند پروژه را تحویل دهد قوانینی را نادیده می‌گیرد و در نتیجه از کیفیت کد کاسته می‌شود.

People under time pressure don’t work better—they just work
faster.

از کتاب:
Peopleware: Productive Projects and Teams (Tom DeMarco & Timothy Lister)

#افشین_علیزاده
لینکدین:
https://ir.linkedin.com/in/afshinalizadehbehjati

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



___
Forwarded from Software Philosophy
جملات زیر غالبا به مقدار زیاد شنیده می‌شوند:
• من صبح زود و قبل از اینکه کسی دیگری در شرکت باشد خیلی بهتر کار می‌کنم.
• در یک روز تعطیل می‌توانم به اندازه ۲ یا ۳ روز کاری،‌ کار انجام بدهم.
جملاتی از قبیل جملات بالا نشانه این هستند که محیط کاری مناسبی وجود ندارد. و مدیران با اتخاذ تصمیمات مناسب می‌توانند آرامش را به محیط کار برگردانند. ولی متاسفانه هیچ کس کاری انجام نمی‌دهد.

Staying late or arriving early or staying home to work in peace is a damning indictment of the office environment.
The amazing thing is not that it’s so often impossible to work in the workplace; the amazing thing is that everyone
knows it and nobody ever does anything about it.

از کتاب:
Peopleware: Productive Projects and Teams (Tom DeMarco & Timothy Lister)

#افشین_علیزاده
لینکدین:
https://ir.linkedin.com/in/afshinalizadehbehjati

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



___
Forwarded from Software Philosophy
در یک بازی شطرنج با محدودیت زمانی ۵ دقیقه (شطرنج سریع یا بلیتس)، بازیکنان در یک زمان کم تصمیم میگیرند و حرکت را انجام میدهد ولی در حالت بدون محدودیت زمانی بازیکنان به اندازه کافی وقت برای فکر کردن و تصمیم گرفتن را دارند. در نتیجه شطرنج سریع از لحاظ کیفیت قابل مقایسه با شطرنج بدون محدودیت زمانی نیست.
یک رابطه مستقیم بین کیفیت و زمان انجام کار وجود دارد. هرچه که زمان بیشتر باشد کیفیت کار نیز بیشتر است. این قاعده در پروژه‌های نرم‌افزاری نیز صادق است. اگر مدیر پروژه به هر دلیلی مدت زمان انجام پروژه را کم در نظر بگیرد ناخواسته از کیفیت برنامه کاسته میشود، و این عدم کیفیت در سایت مشتری خودش را نشان میدهد.

بروز خطا در سایت مشتری به مراتب اثر منفی بیشتری دارد تا دیر تحویل دادن یک پروژه با کیفیت عالی.

Managers jeopardize product quality by setting unreachable deadlines.

Workers kept under extreme time pressure will begin to sacrifice quality. They will push problems under the rug to be dealt with later or foisted off onto the product’s end user. They will deliver products that are unstable and not really complete. They will hate what they’re doing, but what other choice
do they have?

از کتاب:
Peopleware: Productive Projects and Teams (Tom DeMarco & Timothy Lister)


#افشین_علیزاده
لینکدین:
https://ir.linkedin.com/in/afshinalizadehbehjati

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



___