Forwarded from Software Philosophy
ضد الگوی «کد مرده» یا Dead Code، یک Anti Pattern رایج در شرکتهایی است که مدت نسبتا زیادی سیستم تولید میکنند. اگر شما این جملهها را میشنوید احتمالا شما هم دچار این ضد الگو شدهاید:
- این کد رو دو نفر قبلا نوشند که سه سال پیش رفتند و پارسال یه نفر دیگه تلاش کرد یاد بگیره و مستند بنویسه براش و اون هم رفته. البته فک نکنم الان اصلا از این کد استفاده بشه، ولی محض احتیاط بهتره پاک نشه!
این نوع کدها غالبا پیچیدگی سیستم را به شدت بالا میبرند و تغییرات آتی سیستم را بسیار سخت میکنند.
بسیاری از این کدها به این علت به وجود میآیند که در زمان تولید کدهای در حد R&D وارد کد عملیاتی شده و به مدیریت آن در آینده فکر نشده.
https://sourcemaking.com/antipatterns/lava-flow
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
- این کد رو دو نفر قبلا نوشند که سه سال پیش رفتند و پارسال یه نفر دیگه تلاش کرد یاد بگیره و مستند بنویسه براش و اون هم رفته. البته فک نکنم الان اصلا از این کد استفاده بشه، ولی محض احتیاط بهتره پاک نشه!
این نوع کدها غالبا پیچیدگی سیستم را به شدت بالا میبرند و تغییرات آتی سیستم را بسیار سخت میکنند.
بسیاری از این کدها به این علت به وجود میآیند که در زمان تولید کدهای در حد R&D وارد کد عملیاتی شده و به مدیریت آن در آینده فکر نشده.
https://sourcemaking.com/antipatterns/lava-flow
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
Sourcemaking
Design Patterns and Refactoring
Design Patterns and Refactoring articles and guides. Design Patterns video tutorials for newbies. Simple descriptions and full source code examples in Java, C++, C#, PHP and Delphi.
#پست_مجدد این پست تا به حال بیش از ۲۸۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
تخمین کارها در 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
___
پست زیر قدمهایی را برای رسیدن به یک تخمین موفق، معرفی و آنها را شرح دادهاست.
http://www.agilebuddha.com/agile/agile-estimation-8-steps-to-successful-story-point-estimation/
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
Agilebuddha
Agile Estimation : 8 Steps to Successful Story Point Estimation
In Story Points, It Does Not Matter if your Estimate are Correct or Incorrect as Long as you are Consistent. These 8 Steps will Bring Sanity in your Estimation.
#پست_مجدد این پست تا به حال بیش از ۲۰۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
یکی از تکنیکهایی که در مدیریت پروژههای نرمافزاری برای مدیریت کارها استفاده میشود استفاده از مفهوم «کانبان» است. این روش که شرکت تویوتا از آن در سیستم تولید just-in-time خود استفاده میکند برای پروژههای نرمافزاری نیز سازگار شدهاست.
یکی از اهداف کانبان، شناسایی گلوگاههای کاری است تا بتوان به فرایندی بهینهتر برای تولید نرمافزار رسید.
لینک زیر پس از توضیح مفهوم کانبان، نحوه استفاده از بورد کانبان را در پروژههای نرمافزاری شرح دادهاست.
http://kanbanblog.com/explained/
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
یکی از اهداف کانبان، شناسایی گلوگاههای کاری است تا بتوان به فرایندی بهینهتر برای تولید نرمافزار رسید.
لینک زیر پس از توضیح مفهوم کانبان، نحوه استفاده از بورد کانبان را در پروژههای نرمافزاری شرح دادهاست.
http://kanbanblog.com/explained/
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
Kanbanblog
What is Kanban?
A summary of Kanban for managers.
Forwarded from SQL Server (Hamidreza)
سلام وعرض ادب خدمت دوستان عزیز
شب بر شما خوش باشه انشالله
یکی از قابلیتهای اضافه شده در SQL Server 2016 استفاده از JSON هست.
در این مقاله که لینکش رو قرار میدهم به شما نشان میدهد که چطور و به سادگی میتوانید با استفاده از این قابلیت توسعه Rest API رو خیلی راحتتر انجام بدین.
امیدوارم از این مقاله لذت ببرید
ارادتمند شما
حمیدرضا صادقیان
https://blogs.msdn.microsoft.com/sqlserverstorageengine/2018/01/29/simplify-rest-api-development-modern-single-page-apps-sql-server/?utm_source=dlvr.it&utm_medium=linkedin
ID: @Hamidreza_Sadeghian
SQL Server Channel : @SQL_Server
SQL Server Group : https://telegram.me/joinchat/BTQQtzy50j80lW2DM90Wtw
شب بر شما خوش باشه انشالله
یکی از قابلیتهای اضافه شده در SQL Server 2016 استفاده از JSON هست.
در این مقاله که لینکش رو قرار میدهم به شما نشان میدهد که چطور و به سادگی میتوانید با استفاده از این قابلیت توسعه Rest API رو خیلی راحتتر انجام بدین.
امیدوارم از این مقاله لذت ببرید
ارادتمند شما
حمیدرضا صادقیان
https://blogs.msdn.microsoft.com/sqlserverstorageengine/2018/01/29/simplify-rest-api-development-modern-single-page-apps-sql-server/?utm_source=dlvr.it&utm_medium=linkedin
ID: @Hamidreza_Sadeghian
SQL Server Channel : @SQL_Server
SQL Server Group : https://telegram.me/joinchat/BTQQtzy50j80lW2DM90Wtw
برنامه نویسی Blockchain با توجه به کاربرد آن در Bitcoin به یکی از موضوعات داغ این روزها تبدیل شدهاست.
برای درک رابطه بین این دو، مثال زیر این مفهوم را به خوبی تشریح میکند.
نسبت Blockchain به Bitcoin مثل نسبت طلا به جواهر است. با طلا کارهای مختلفی میتوان کرد که یکی از آنها ساخت جواهر است. البته با اینکه طلا یک عنصر با ارزش است ولی هیچکس یک تکه سنگ طلا را به گردن خود آویزان نمیکند. در حقیقت جواهرات باعث با ارزش شدن و معروف شدن طلا شدهاند.
همین نسبت در مورد Blockchain و Bitcoin نیز وجود دارد. قطعا Blockchain بسیار ارزشمند است، ولی در حقیقت Bitcoin بوده که باعث شده که این الگوریتم ارزشمند زنده بماند. یادگیری این الگوریتم میتواند در شرایط مختلفی کاربرد داشته باشد.
کتاب زیر با عنوان Blockchain Programming in C# که در GitBook قرار دارد به طور کامل این مفهوم را شرح داده و استفاده از آن را در زبان C# پیادهسازی کرده است.
https://programmingblockchain.gitbooks.io/programmingblockchain/content/introduction/why_blockchain_programming_and_not_bitcoin_program.html
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/XWSp30i6XTE
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
برای درک رابطه بین این دو، مثال زیر این مفهوم را به خوبی تشریح میکند.
نسبت Blockchain به Bitcoin مثل نسبت طلا به جواهر است. با طلا کارهای مختلفی میتوان کرد که یکی از آنها ساخت جواهر است. البته با اینکه طلا یک عنصر با ارزش است ولی هیچکس یک تکه سنگ طلا را به گردن خود آویزان نمیکند. در حقیقت جواهرات باعث با ارزش شدن و معروف شدن طلا شدهاند.
همین نسبت در مورد Blockchain و Bitcoin نیز وجود دارد. قطعا Blockchain بسیار ارزشمند است، ولی در حقیقت Bitcoin بوده که باعث شده که این الگوریتم ارزشمند زنده بماند. یادگیری این الگوریتم میتواند در شرایط مختلفی کاربرد داشته باشد.
کتاب زیر با عنوان Blockchain Programming in C# که در GitBook قرار دارد به طور کامل این مفهوم را شرح داده و استفاده از آن را در زبان C# پیادهسازی کرده است.
https://programmingblockchain.gitbooks.io/programmingblockchain/content/introduction/why_blockchain_programming_and_not_bitcoin_program.html
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/XWSp30i6XTE
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Forwarded from فلسفه دیزاین
راهنمای جیبی برای «خلق کردن»
تمامی دیزاینرها برای ارائه کارهای خوب، محکومند به خلاق بودن. در کار ما، خلاقیت یکی از الزمات لذتبخش است که امروز درباره آن گفتگو میکنیم.
بسیاری از ما فکر میکنیم که آدمهای خلاق آدمهای شخلتهای هستند، یا برای خلاق بودن باید تمامی روندها و چارچوبها را درهم کوبید، حتی در زندگی شخصی. به اعتقاد من و برخی دیگر که چند وقت پیش با آنها همصحبت شده بودم، خلاقیت میتواند روند داشته باشد. یا شاید بهتر باشد بگوییم برای ایجاد «تکرار پذیری» و «تمرین و یادگیری» هرچیزی باید آن را بصورت یک Flow یا روند درآوریم. خلاقیت هم از این قاعده مستثنی نیست.
مقاله امروز بطور کامل به بررسی خلاق بودن میپردازد و نتیجهای است از مطالعه نوشتههای Mihaly Csikszentmihalyi (روانشناس) و Betty Edwards (مدرس هنر) در قالب روشی به نام ISIIVE. هر حرف از این نام معرف یکی از مراحل این روند است و مثل بسیاری روشهای دیگر، با پرسیدن «سوال دُرست» شروع میشود.
اگر شما هم میخواهید خلاق باشید، این مقاله را از دست ندهید و نوشتههای آن را همیشه در گوشهای نگه دارید.
مثل لباس یک ابرقهرمان. ابرقهرمان خلاقیت.
https://uxplanet.org/pocket-creativity-d1868400ff1b
(زمان حدودی مطالعه، ۱۵ دقیقه)
#معرفی #تکنیک #خلاقیت
@Dexign فلسفه دیزاین
____
تمامی دیزاینرها برای ارائه کارهای خوب، محکومند به خلاق بودن. در کار ما، خلاقیت یکی از الزمات لذتبخش است که امروز درباره آن گفتگو میکنیم.
بسیاری از ما فکر میکنیم که آدمهای خلاق آدمهای شخلتهای هستند، یا برای خلاق بودن باید تمامی روندها و چارچوبها را درهم کوبید، حتی در زندگی شخصی. به اعتقاد من و برخی دیگر که چند وقت پیش با آنها همصحبت شده بودم، خلاقیت میتواند روند داشته باشد. یا شاید بهتر باشد بگوییم برای ایجاد «تکرار پذیری» و «تمرین و یادگیری» هرچیزی باید آن را بصورت یک Flow یا روند درآوریم. خلاقیت هم از این قاعده مستثنی نیست.
مقاله امروز بطور کامل به بررسی خلاق بودن میپردازد و نتیجهای است از مطالعه نوشتههای Mihaly Csikszentmihalyi (روانشناس) و Betty Edwards (مدرس هنر) در قالب روشی به نام ISIIVE. هر حرف از این نام معرف یکی از مراحل این روند است و مثل بسیاری روشهای دیگر، با پرسیدن «سوال دُرست» شروع میشود.
اگر شما هم میخواهید خلاق باشید، این مقاله را از دست ندهید و نوشتههای آن را همیشه در گوشهای نگه دارید.
مثل لباس یک ابرقهرمان. ابرقهرمان خلاقیت.
https://uxplanet.org/pocket-creativity-d1868400ff1b
(زمان حدودی مطالعه، ۱۵ دقیقه)
#معرفی #تکنیک #خلاقیت
@Dexign فلسفه دیزاین
____
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. ضد الگوی «کد مرده» یا Dead Code چیست؟
https://t.me/SoftwarePhilosophy/1140
۲. قدمهای مناسب برای رسیدن به تخمین موفق در پروژه
https://t.me/SoftwarePhilosophy/1142
۳. آشنایی با کانبان و نحوه کار بورد کانبان در پروژههای نرمافزاری
https://t.me/SoftwarePhilosophy/1144
۴. استفاده از JSON در SQL Server 2016 (SQL Server)
https://t.me/SoftwarePhilosophy/1145
۵. آشنایی با برنامه نویسی Blockchain و معرفی کتاب
https://t.me/SoftwarePhilosophy/1146
۶. راهنمای جیبی برای «خلق کردن» (فلسفه دیزاین)
https://t.me/SoftwarePhilosophy/1147
ـــــــــــ
@SoftwarePhilosophy
۱. ضد الگوی «کد مرده» یا Dead Code چیست؟
https://t.me/SoftwarePhilosophy/1140
۲. قدمهای مناسب برای رسیدن به تخمین موفق در پروژه
https://t.me/SoftwarePhilosophy/1142
۳. آشنایی با کانبان و نحوه کار بورد کانبان در پروژههای نرمافزاری
https://t.me/SoftwarePhilosophy/1144
۴. استفاده از JSON در SQL Server 2016 (SQL Server)
https://t.me/SoftwarePhilosophy/1145
۵. آشنایی با برنامه نویسی Blockchain و معرفی کتاب
https://t.me/SoftwarePhilosophy/1146
۶. راهنمای جیبی برای «خلق کردن» (فلسفه دیزاین)
https://t.me/SoftwarePhilosophy/1147
ـــــــــــ
@SoftwarePhilosophy
Forwarded from Agile Product Management (مدیریت محصول چابک)
🔻 عنوان: مالک محصول بزرگ در مقابل مالک محصول کوچک
🔸 امروزه تقریبا در تمامی شرکت های نرم افزاری ایران و جهان از رویکردی چابک برای مدیریت محصولات و یا پروژه های نرم افزاری استفاده می شود. در تمامی این سازمان ها، افرادی با عنوان مالک محصول اسکرام و یا مدیر محصول چابک در حال توسعه محصولات نرم افزاری و دیجیتال هستند.
🆔 @agileproduct
🔸این مالکان محصول در اشکال و اندازه های مختلفی قرار می گیرند. این یک امر طبیعی است، چون کاربرد نقش مالک محصول، بستگی به وضعیت محصول و شرکت دارد.
🔸 به عبارت دیگر، ایفای نقش به عنوان مالک محصول یک استارتاپ نوپا در مقایسه با یک سازمان نرمافزاری بالغ با هم بسیارمتفاوت است. با این حال، مالکین محصول در سرتاسر دنیا در دو دسته قرار می گیرند. مالک محصول بزرگ و مالک محصول کوچک. تا حالا به این فکر کردید که شما در کدام دسته هستید؟ آیا سطح مالکیت محصول شما در جای درستی قرار دارد؟
👇👇👇👇
https://goo.gl/rXss2J
🆔 @agileproduct
🔸 امروزه تقریبا در تمامی شرکت های نرم افزاری ایران و جهان از رویکردی چابک برای مدیریت محصولات و یا پروژه های نرم افزاری استفاده می شود. در تمامی این سازمان ها، افرادی با عنوان مالک محصول اسکرام و یا مدیر محصول چابک در حال توسعه محصولات نرم افزاری و دیجیتال هستند.
🆔 @agileproduct
🔸این مالکان محصول در اشکال و اندازه های مختلفی قرار می گیرند. این یک امر طبیعی است، چون کاربرد نقش مالک محصول، بستگی به وضعیت محصول و شرکت دارد.
🔸 به عبارت دیگر، ایفای نقش به عنوان مالک محصول یک استارتاپ نوپا در مقایسه با یک سازمان نرمافزاری بالغ با هم بسیارمتفاوت است. با این حال، مالکین محصول در سرتاسر دنیا در دو دسته قرار می گیرند. مالک محصول بزرگ و مالک محصول کوچک. تا حالا به این فکر کردید که شما در کدام دسته هستید؟ آیا سطح مالکیت محصول شما در جای درستی قرار دارد؟
👇👇👇👇
https://goo.gl/rXss2J
🆔 @agileproduct
Telegraph
مالک محصول بزرگ در مقابل مالک محصول کوچک
آیدین ضیاپور مشاور و مربی مدیریت محصول چابک https://ir.linkedin.com/in/aidinziapour مقدمه امروزه تقریبا در تمامی شرکت های نرم افزاری ایران و جهان از رویکردی چابک برای مدیریت محصولات و یا پروژه های نرم افزاری استفاده می شود. در تمامی این سازمان ها، افرادی…
#پست_مجدد این پست تا به حال بیش از ۳۸۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
قورباغه را دوباره اختراع نکنید!
در مهندسی نرمافزار، شناخت دقیق نیازمندیها و سپس ساخت محصولی مطابق نیازمندیها یکی از کارهای به ظاهر ساده ولی در عمل پیچیده است. مطلب زیر داستانی را تشریح میکند که در آن یک مهندس نرمافزار هنگام خلقت زمین پروژه طراحی «زنبور» را بر عهده گرفتهاست. ولی به دلایلی که در داستان توضیح داده شده اقدام به طراحی یک «وزغ» میکند که هیچ تناسبی با نیازمندیهای «زنبور» ندارد. این مهندس نرمافزار در حقیقت به جای خلق موجودی که نیازمندیهای زنبور را برآورده کند، یک حیوان جدید به نام وزغ خلق کرده که اتفاقا خدا قبلا آن را با نام «قورباغه» خلق کرده بوده!
اگر لینک زیر را کامل بخوانید ارتباط آن را با پروژههای نرمافزاری میبینید و خواهید دید که چگونه این خطا باعث شکست یک پروژه نرمافزاری میشود.
http://mehrandvd.me/2016/03/09/reinventing-the-frog/
#مهران_داودی
لینکداین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
در مهندسی نرمافزار، شناخت دقیق نیازمندیها و سپس ساخت محصولی مطابق نیازمندیها یکی از کارهای به ظاهر ساده ولی در عمل پیچیده است. مطلب زیر داستانی را تشریح میکند که در آن یک مهندس نرمافزار هنگام خلقت زمین پروژه طراحی «زنبور» را بر عهده گرفتهاست. ولی به دلایلی که در داستان توضیح داده شده اقدام به طراحی یک «وزغ» میکند که هیچ تناسبی با نیازمندیهای «زنبور» ندارد. این مهندس نرمافزار در حقیقت به جای خلق موجودی که نیازمندیهای زنبور را برآورده کند، یک حیوان جدید به نام وزغ خلق کرده که اتفاقا خدا قبلا آن را با نام «قورباغه» خلق کرده بوده!
اگر لینک زیر را کامل بخوانید ارتباط آن را با پروژههای نرمافزاری میبینید و خواهید دید که چگونه این خطا باعث شکست یک پروژه نرمافزاری میشود.
http://mehrandvd.me/2016/03/09/reinventing-the-frog/
#مهران_داودی
لینکداین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
Dot Philosophy
Reinventing the Frog! - Dot Philosophy
Do you remember the time that God was creating the "Planet Ecosystem" as a sub project of "Earth Project"!? You know, there was a lot of work needed to be done to create this world. Some sample tasks might be: Creating Flowers Designing Rose Designing Tulip…
#پست_مجدد این پست تا به حال بیش از ۲۵۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
الگوی 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
___
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
___
Alastair Crabtree
Implementing the retry pattern for async tasks in c#
This post is a follow on from Implementing a simple retry pattern in c#
[https://alastaircrabtree.com/implementing-a-simple-retry-pattern-in-c/].
Tasks, async and await are rapidly becoming be default API flavours in many
dotnet libraries and the performance…
[https://alastaircrabtree.com/implementing-a-simple-retry-pattern-in-c/].
Tasks, async and await are rapidly becoming be default API flavours in many
dotnet libraries and the performance…
Forwarded from فلسفه دیزاین
معرفی کتابهای بیربط به دیزاین
احتمالا میپرسید چرا باید در کانالی که از دیزاین حرف میزند کتابهای بیربط به دیزاین معرفی شود؟
خب واقعیت این است که کتابهایی که امروز به معرفیشان میپردازیم فقط «مستقیما» به دیزاین مربوط نیستند. این کتابها به نگاه و طرز تفکرمان مربوطند و همین نگاه و طرز تفکر میتواند یک دیزاین نسبتا خوب را به دیزاینی کاملا عالی تبدیل کند.
اگر کمی بیاندیشیم احتمالا موضوعات زیادی پیدا میکنیم که برای رسیدن به کمال در آنها، به مهارتهای مختلف، متفاوت و در نگاه اول کاملا بیربط نیازمندیم.
آقای Daniel Burka، یکی از همکاران Google Ventures، در توییتی از دیزاینرها خواسته بود که بهترین کتاب دیزاینی که مربوط به دیزاین نیست را معرفی کنند. ایشان جوابهای دریافتیشان را در قالب مقالهای با ما به اشتراک گذاشتهاند.
کتابهای این مجموعه را از دست ندهید.
https://medium.com/@dburka/the-best-design-books-that-arent-explicitly-about-design-74fc96ce115e
(زمان حدودی مطالعه، ۶ دقیقه)
#معرفی #کتاب #دیزاین
@Dexign فلسفه دیزاین
__
احتمالا میپرسید چرا باید در کانالی که از دیزاین حرف میزند کتابهای بیربط به دیزاین معرفی شود؟
خب واقعیت این است که کتابهایی که امروز به معرفیشان میپردازیم فقط «مستقیما» به دیزاین مربوط نیستند. این کتابها به نگاه و طرز تفکرمان مربوطند و همین نگاه و طرز تفکر میتواند یک دیزاین نسبتا خوب را به دیزاینی کاملا عالی تبدیل کند.
اگر کمی بیاندیشیم احتمالا موضوعات زیادی پیدا میکنیم که برای رسیدن به کمال در آنها، به مهارتهای مختلف، متفاوت و در نگاه اول کاملا بیربط نیازمندیم.
آقای Daniel Burka، یکی از همکاران Google Ventures، در توییتی از دیزاینرها خواسته بود که بهترین کتاب دیزاینی که مربوط به دیزاین نیست را معرفی کنند. ایشان جوابهای دریافتیشان را در قالب مقالهای با ما به اشتراک گذاشتهاند.
کتابهای این مجموعه را از دست ندهید.
https://medium.com/@dburka/the-best-design-books-that-arent-explicitly-about-design-74fc96ce115e
(زمان حدودی مطالعه، ۶ دقیقه)
#معرفی #کتاب #دیزاین
@Dexign فلسفه دیزاین
__
Medium
The best ‘design‘ books that aren’t explicitly about design.
I asked a whole bunch of designers what books that weren’t specifically about digital or graphic design inspired them.
#پست_مجدد این پست تا به حال بیش از ۲۴۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
دنیای AR یا Augmented Reality باعث ایجاد مفاهیم جدیدی در UI/UX شدهاست. توان خلق موجودیتها در فضای اطراف کاربر امکانی است که قبلا وجود نداشته و به همین دلیل ظهور AR باعث ایجاد تجربیات جدیدی در دنیای UX شدهاست.
برای مثال در لینک زیر یکی از طراحان ارشد هولوگرافیک توضیح میدهد که در نسخههای اولیه نرمافزار طراحی برای خلق اشیا سه بعدی، از یک «میز چهارگوش» مجازی استفاده شده بود که کاربر روی آن شروع به طراحی میکرد (مثلا طراحی یک اسباببازی). پس از تستهای UX متوجه شدند چهارگوش بودن میز باعث میشود کاربران بیشتر یک سمت میز بایستند و کمتر دور شیی که طراحی میکنند بچرخند. به همین دلیل در نسخههای بعدی از یک میز مجازی «گرد» استفاده شد. نتیجه عالی بود، کاربران دیگر یک جای ثابت نمیایستند و تقریبا هر دفعه از یک زاویه جدید محصول خود را میبینند.
در مقاله زیر طراح ارشد تجربیات خود و درسهایی که تا به حال از انجام پروژههای هولوگرافیک کسب کرده را توضیح داده و چند مثال جذاب دیگر را هم بیان کرده است.
https://developer.microsoft.com/en-us/windows/holographic/case_study_-_3_holostudio_ui_and_interaction_design_learnings
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
برای مثال در لینک زیر یکی از طراحان ارشد هولوگرافیک توضیح میدهد که در نسخههای اولیه نرمافزار طراحی برای خلق اشیا سه بعدی، از یک «میز چهارگوش» مجازی استفاده شده بود که کاربر روی آن شروع به طراحی میکرد (مثلا طراحی یک اسباببازی). پس از تستهای UX متوجه شدند چهارگوش بودن میز باعث میشود کاربران بیشتر یک سمت میز بایستند و کمتر دور شیی که طراحی میکنند بچرخند. به همین دلیل در نسخههای بعدی از یک میز مجازی «گرد» استفاده شد. نتیجه عالی بود، کاربران دیگر یک جای ثابت نمیایستند و تقریبا هر دفعه از یک زاویه جدید محصول خود را میبینند.
در مقاله زیر طراح ارشد تجربیات خود و درسهایی که تا به حال از انجام پروژههای هولوگرافیک کسب کرده را توضیح داده و چند مثال جذاب دیگر را هم بیان کرده است.
https://developer.microsoft.com/en-us/windows/holographic/case_study_-_3_holostudio_ui_and_interaction_design_learnings
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. مالک محصول بزرگ در مقابل مالک محصول کوچک (Agile Product Management)
https://t.me/SoftwarePhilosophy/1149
۲. قورباغه را دوباره اختراع نکنید!
https://t.me/SoftwarePhilosophy/1151
۳. الگوی Async Retry Pattern
https://t.me/SoftwarePhilosophy/1153
۴. معرفی کتابهای بیربط به دیزاین (فلسفه دیزاین)
https://t.me/SoftwarePhilosophy/1154
۵. تجربیات و درسهای یک طراح ارشد پروژههای هولوگرافیک
https://t.me/SoftwarePhilosophy/1156
ـــــــــــ
@SoftwarePhilosophy
۱. مالک محصول بزرگ در مقابل مالک محصول کوچک (Agile Product Management)
https://t.me/SoftwarePhilosophy/1149
۲. قورباغه را دوباره اختراع نکنید!
https://t.me/SoftwarePhilosophy/1151
۳. الگوی Async Retry Pattern
https://t.me/SoftwarePhilosophy/1153
۴. معرفی کتابهای بیربط به دیزاین (فلسفه دیزاین)
https://t.me/SoftwarePhilosophy/1154
۵. تجربیات و درسهای یک طراح ارشد پروژههای هولوگرافیک
https://t.me/SoftwarePhilosophy/1156
ـــــــــــ
@SoftwarePhilosophy
یکی از مهمترین چالشها در الگوریتمهایی که با حجم زیادی از آرایهها کار میکنند، کپی کردن قسمتهایی از آرایه برای انجام یک کار روی آن است. برای مثال وقتی میخواهید نصف دوم یک آرایه را به یک متد پاس بدهید، عموما مجبورید از نصف دوم آرایه یک کپی بگیرید و به متد پاس بدهید. سربار کپی همیشه یکی از مهمترین چالشهای performance در الگوریتمها بوده است.
یکی از امکانات جذابی که به C# 7.2 اضافه شده، مفهوم Span<T> است. با استفاده از این تایپ جدید که بر اساس مفاهیم پیچیدهای بنا شده، به راحتی میتوانید یک قسمت از یک آرایه را بدون اینکه کپی کنید جدا کنید و از آن استفاده کنید.
در مقاله زیر Stephen Toub که یکی از معماران اصلی امکانات Parallel Programming در .Net است، بسیار مفید و دقیق در مورد Span<T> و Memory<T> صبحت کرده و حتی در مورد قسمتهایی از لایههای زیرین این تایپها توضیح داده که چطور کد آنها پیادهسازی شدهاست.
https://msdn.microsoft.com/en-us/magazine/mt814808.aspx
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/oEWA30ik0Yp
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
یکی از امکانات جذابی که به C# 7.2 اضافه شده، مفهوم Span<T> است. با استفاده از این تایپ جدید که بر اساس مفاهیم پیچیدهای بنا شده، به راحتی میتوانید یک قسمت از یک آرایه را بدون اینکه کپی کنید جدا کنید و از آن استفاده کنید.
در مقاله زیر Stephen Toub که یکی از معماران اصلی امکانات Parallel Programming در .Net است، بسیار مفید و دقیق در مورد Span<T> و Memory<T> صبحت کرده و حتی در مورد قسمتهایی از لایههای زیرین این تایپها توضیح داده که چطور کد آنها پیادهسازی شدهاست.
https://msdn.microsoft.com/en-us/magazine/mt814808.aspx
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/oEWA30ik0Yp
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Forwarded from Iran Agile
🔵 چرا کارها در انتهای اسپرینت تمام نمیشوند؟
سه دلیل عمده اینکه چرا کارها در انتهای اسپرینت تمام نمیشوند:
1- تسک سوییچ: اینکه فرد بین تسکهای مختلف خود مجبور به سوییچ کردن است و نمی تواند یک کار کامل انجام دهد و سپس کار بعدی را شروع کند.
2- افراد بنابر تخصص از همه جدا شده اند: مثلا فرانت اند، بک اند، تحلیل. در این صورت تسک های نفرات از همه جدا می شود، این روش برای مشغول نگه داشتن افراد عالی است ولی برای تمام شدن کلی کار و نتیجه گرفتن، میتواند خوب نباشد.
3- آیتم های اسپرینت بزرگ هستند: آیتم هایی که وارد اسپرینت می شوند خوب شکسته نشده اند و معمولا چند اسپرینت به طول می انجامند.
https://goo.gl/Fwx3c7
@iranagile
سه دلیل عمده اینکه چرا کارها در انتهای اسپرینت تمام نمیشوند:
1- تسک سوییچ: اینکه فرد بین تسکهای مختلف خود مجبور به سوییچ کردن است و نمی تواند یک کار کامل انجام دهد و سپس کار بعدی را شروع کند.
2- افراد بنابر تخصص از همه جدا شده اند: مثلا فرانت اند، بک اند، تحلیل. در این صورت تسک های نفرات از همه جدا می شود، این روش برای مشغول نگه داشتن افراد عالی است ولی برای تمام شدن کلی کار و نتیجه گرفتن، میتواند خوب نباشد.
3- آیتم های اسپرینت بزرگ هستند: آیتم هایی که وارد اسپرینت می شوند خوب شکسته نشده اند و معمولا چند اسپرینت به طول می انجامند.
https://goo.gl/Fwx3c7
@iranagile
Forwarded from Iran .Net (Ehsan Mirsaeedi)
لاگ ها - یکپارچه سازی
با نگاه به میزان حضور و کیفیت و جزییات لاگ ها در یک سیستم می توان براحتی فهمید که تیم توسعه دهنده تا چه حد به کیفیت و پایداری سیستم تعهد دارند. فراتر از آن لاگ ها یکی از معدود ابزار های تیم عملیات در تحلیل کارکرد سیستم و حل و بررسی مشکلات هستند. بدون لاگ های با کیفیت عملا سیستم و تیم عملیات یتیم و بی پناه هستند و راهی برای حل و حتی شناسایی رخداد مشکلات وجود ندارد. البته داشتن لاگ های با کیفیت و جامع بر خلاف تصور رایج، نیاز به مهارت، دقت و تعهد بالایی از سمت همه اعضای تیم توسعه و عملیات دارد.
در قریب به اتفاق مواقع لاگ هایی که در سیستم ها وجود دارد، چیزی بیشتر از نوشتن یک جمله در فایل هایی که با تاریخ تفکیک می شوند نیست. ایراد این نوع از لاگ ها این است که:
1. قابلیت جستجوهای پیشرفته، گزارش سازی و کوئری زدن بر روی آن ها وجود ندارد.
2. در برنامه های پر ترافیک ثبت لاگ بر روی فایل ترافیک I/O زیادی را به سیستم تحمیل می کند.
3. اگر سامانه متشکل از چند سیستم جدا از هم باشد، لاگ های پراکنده ای خواهیم داشت که هر کدام در یک محل جدا و غیریکپارچه قرار گرفته اند.
4. برای خواندن لاگ ها نیاز به دسترسی به مستقیم به سرور خواهید داشت.
برای حل مشکل یکپارچگی لاگ ها، خیلی از سیستم های پرترافیک از پلتفرمی به نام ELK استفاده می کنند. اما برای سیستم های کوچک تر و یا تیم هایی که در عین کیفیت از پیچیدگی فراری هستند، می توان از ابزار فوق العاده و البته رایگان SEQ استفاده کرد. این ابزار به شما امکان می دهد تا لاگ ها را از همه سیستم های تان یکجا جمع کنید، بدون نیاز به دسترسی مستقیم به سرور و با مرورگرتان لاگ ها را در یک پنل زیبا و کاربردی مشاهده کنید و با زبانی شبیه به SQL در میان لاگ ها جستجو کرده و گزارش و نمودار بسازید و از داشبورد به نسبت خوب و کاربردی بهره مند شوید. البته برای اینکه بتوانید در لاگ ها جستجوهای پیشرفته داشته باشید، باید لاگ های تان ساختارمند باشند. در قسمت بعدی راجع به لاگ های ساختارمند صحبت خواهیم کرد.
لاگ یک امر فانتزی و یا صرفا مربوط به توسعه دهنده ها نیست. لاگ هم یک فیچر مهم از سیستم نرم افزاری است که می تواند در موفقیت و شکست یک سیستم نقش مستقیم ایفا کند. پس به لاگ ها اهمیت بدهیم.
* ابزار SEQ توسط توسعه دهنده کتابخانه پرقدرت Autofac و Serilog توسعه داده شده است.
* دانلود ابزار SEQ
https://getseq.net/Download
*توضیحاتی در مورد SEQ
https://blog.getseq.net/hello-seq-4-0-dashboards-alerts-more-improvements/
https://blog.getseq.net/seq-4-2-rtm/
* پلتفرم ELK - پرقدرت ولی به نسبت پیچیده از حیث راه اندازی و نگهداری
https://www.elastic.co/webinars/introduction-elk-stack
@irandotnet
با نگاه به میزان حضور و کیفیت و جزییات لاگ ها در یک سیستم می توان براحتی فهمید که تیم توسعه دهنده تا چه حد به کیفیت و پایداری سیستم تعهد دارند. فراتر از آن لاگ ها یکی از معدود ابزار های تیم عملیات در تحلیل کارکرد سیستم و حل و بررسی مشکلات هستند. بدون لاگ های با کیفیت عملا سیستم و تیم عملیات یتیم و بی پناه هستند و راهی برای حل و حتی شناسایی رخداد مشکلات وجود ندارد. البته داشتن لاگ های با کیفیت و جامع بر خلاف تصور رایج، نیاز به مهارت، دقت و تعهد بالایی از سمت همه اعضای تیم توسعه و عملیات دارد.
در قریب به اتفاق مواقع لاگ هایی که در سیستم ها وجود دارد، چیزی بیشتر از نوشتن یک جمله در فایل هایی که با تاریخ تفکیک می شوند نیست. ایراد این نوع از لاگ ها این است که:
1. قابلیت جستجوهای پیشرفته، گزارش سازی و کوئری زدن بر روی آن ها وجود ندارد.
2. در برنامه های پر ترافیک ثبت لاگ بر روی فایل ترافیک I/O زیادی را به سیستم تحمیل می کند.
3. اگر سامانه متشکل از چند سیستم جدا از هم باشد، لاگ های پراکنده ای خواهیم داشت که هر کدام در یک محل جدا و غیریکپارچه قرار گرفته اند.
4. برای خواندن لاگ ها نیاز به دسترسی به مستقیم به سرور خواهید داشت.
برای حل مشکل یکپارچگی لاگ ها، خیلی از سیستم های پرترافیک از پلتفرمی به نام ELK استفاده می کنند. اما برای سیستم های کوچک تر و یا تیم هایی که در عین کیفیت از پیچیدگی فراری هستند، می توان از ابزار فوق العاده و البته رایگان SEQ استفاده کرد. این ابزار به شما امکان می دهد تا لاگ ها را از همه سیستم های تان یکجا جمع کنید، بدون نیاز به دسترسی مستقیم به سرور و با مرورگرتان لاگ ها را در یک پنل زیبا و کاربردی مشاهده کنید و با زبانی شبیه به SQL در میان لاگ ها جستجو کرده و گزارش و نمودار بسازید و از داشبورد به نسبت خوب و کاربردی بهره مند شوید. البته برای اینکه بتوانید در لاگ ها جستجوهای پیشرفته داشته باشید، باید لاگ های تان ساختارمند باشند. در قسمت بعدی راجع به لاگ های ساختارمند صحبت خواهیم کرد.
لاگ یک امر فانتزی و یا صرفا مربوط به توسعه دهنده ها نیست. لاگ هم یک فیچر مهم از سیستم نرم افزاری است که می تواند در موفقیت و شکست یک سیستم نقش مستقیم ایفا کند. پس به لاگ ها اهمیت بدهیم.
* ابزار SEQ توسط توسعه دهنده کتابخانه پرقدرت Autofac و Serilog توسعه داده شده است.
* دانلود ابزار SEQ
https://getseq.net/Download
*توضیحاتی در مورد SEQ
https://blog.getseq.net/hello-seq-4-0-dashboards-alerts-more-improvements/
https://blog.getseq.net/seq-4-2-rtm/
* پلتفرم ELK - پرقدرت ولی به نسبت پیچیده از حیث راه اندازی و نگهداری
https://www.elastic.co/webinars/introduction-elk-stack
@irandotnet
Structured Blog
Hello Seq 4.0! Dashboards, alerts, more improvements
We're happy to announce the general availability of Seq 4.0, now with beautiful dashboards powered directly from application log data. The full value of structured application logs has never been within such easy reach: Seq 4.0 provides log aggregation, search…