#پست_مجدد این پست تا به حال بیش از ۱۵۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
کارایی و سرعت 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
___
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
___
Zzzprojects
ZZZ Projects
ZZZ Projects | Adding value to the .NET Community
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. آشنایی با Code Map در Visual Studio
#visualstudio
https://t.iss.one/SoftwarePhilosophy/1041
۲. معرفی مفهوم Interaction Flows (فلسفه دیزاین)
https://t.iss.one/SoftwarePhilosophy/1042
۳. مدیران را اخراج کنید! (Iran Agile)
https://t.iss.one/SoftwarePhilosophy/1043
۴. اتصال به دستگاههای بلوتوث از طریق web browser به وسلیه Web Bluetooth API
#web #bluetooth
https://t.iss.one/SoftwarePhilosophy/1045
۵. ایمنسازی نرم افزار در دات نت به وسیله کتابخانه NWebSec
#security #dotnet
https://t.iss.one/SoftwarePhilosophy/1047
۶. چند راه حل برای افزایش کارایی و سرعت EntityFramework
#dotnet #entityframework #performance
https://t.iss.one/SoftwarePhilosophy/1049
ـــــــــــ
@SoftwarePhilosophy
۱. آشنایی با Code Map در Visual Studio
#visualstudio
https://t.iss.one/SoftwarePhilosophy/1041
۲. معرفی مفهوم Interaction Flows (فلسفه دیزاین)
https://t.iss.one/SoftwarePhilosophy/1042
۳. مدیران را اخراج کنید! (Iran Agile)
https://t.iss.one/SoftwarePhilosophy/1043
۴. اتصال به دستگاههای بلوتوث از طریق web browser به وسلیه Web Bluetooth API
#web #bluetooth
https://t.iss.one/SoftwarePhilosophy/1045
۵. ایمنسازی نرم افزار در دات نت به وسیله کتابخانه NWebSec
#security #dotnet
https://t.iss.one/SoftwarePhilosophy/1047
۶. چند راه حل برای افزایش کارایی و سرعت EntityFramework
#dotnet #entityframework #performance
https://t.iss.one/SoftwarePhilosophy/1049
ـــــــــــ
@SoftwarePhilosophy
برنامهنویسان NASA یکی از چالشیترین کارهای برنامهنویسی در جهان را دارند. عمده برنامههایی که آنها مینویسند بسیار حساس و اصطلاحا Mission Critical هستند.
برنامههایی که در ناسا نوشته میشوند نباید هیچ خطایی داشته باشند. کوچکترین خطا در برنامه باعث نابود شدن کل پروژه میشود (برای مثال سقوط شاتل یا نرسیدن به مقصد).
به همین دلیل روشی که آنها طبق آن کد نویسی میکنند میتواند بسیار آموزنده باشد.
در لینک زیر ۱۰ قانون حیاتی که تیم برنامهنویسی «آزمایشگاه نیروی متحرکه جت» یا Jet Propolution Labratovary از آن استفاده میکنند آمده است.
با اینکه این قوانین عمدتا برای زبان C تدوین شدهاند ولی بیشتر آنها در همه زبانها کاربرد دارند و خواندن این قوانین میتواند بسیار آموزنده باشد.
در انتها جملهای که ناسا در مورد این قوانین نوشته جمله جالبی است: «قوانین مانند کمربند ایمنی ماشین هستند. در ابتدا ممکن است خیلی راحت نباشند، ولی استفاده از آنها پس از مدتی طوری غریزی میشود که استفاده نکردنشان غیر قابل تصور خواهد بود»
https://fossbytes.com/nasa-coding-programming-rules-critical/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/UkMY30gO6Si
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
برنامههایی که در ناسا نوشته میشوند نباید هیچ خطایی داشته باشند. کوچکترین خطا در برنامه باعث نابود شدن کل پروژه میشود (برای مثال سقوط شاتل یا نرسیدن به مقصد).
به همین دلیل روشی که آنها طبق آن کد نویسی میکنند میتواند بسیار آموزنده باشد.
در لینک زیر ۱۰ قانون حیاتی که تیم برنامهنویسی «آزمایشگاه نیروی متحرکه جت» یا Jet Propolution Labratovary از آن استفاده میکنند آمده است.
با اینکه این قوانین عمدتا برای زبان C تدوین شدهاند ولی بیشتر آنها در همه زبانها کاربرد دارند و خواندن این قوانین میتواند بسیار آموزنده باشد.
در انتها جملهای که ناسا در مورد این قوانین نوشته جمله جالبی است: «قوانین مانند کمربند ایمنی ماشین هستند. در ابتدا ممکن است خیلی راحت نباشند، ولی استفاده از آنها پس از مدتی طوری غریزی میشود که استفاده نکردنشان غیر قابل تصور خواهد بود»
https://fossbytes.com/nasa-coding-programming-rules-critical/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/UkMY30gO6Si
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Fossbytes
How To Code Like The Top Programmers At NASA — 10 Critical Rules
Do you know how top programmers write mission-critical code at NASA? To make such code clearer, safer, and easier to understand, NASA's Jet Propulsion Laboratory has laid 10 rules for developing software.
Forwarded from فلسفه دیزاین
آیا محصول شما در جیب جا میشود؟
میدانستید تعریف Mark Zuckerberg از Facebook چیست؟
«چیزی که شما میتواند اسم کسی را در آن جستجو کرده و کلی اطلاعات درباره آن فرد بفهمید.»
یا تعریف Travis Kalanick، از Uber (سرویسی که اسنپ مشابه آن است)؟
«شما دکمهای را فشار میدهید و ۵ دقیقه بعد یک مرسدس میاد و شما رو به هرکجا بخواهید میبره.»
در تعریف Mark Zuckerberg از سرویسی که بنیانگذار آن است، هیچ نشانی از «شبکه اجتماعی» یا دهها ویژگی منحصربفرد دیگر Facebook نیست.
آیا شما هم میتوانید تعریفی در این حد خلاصه و در یک جمله از محصول خود داشته باشید؟ بسیاری از ما اصرار داریم که تمامی ویژگیهای آن را در توضیح محصول بیاوریم و در نتیجه باعث سردرگمی دیگران میشویم.
در تمامی ارائههای شفاهی، توضیحات متنی و هر نوع توضیحی که هرجایی قرار است از محصول شما عنوان شود، باید بتوان بهینهترین آنها را ارائه داد که رسالت اصلی آن سرویس یا واضحترین ایده بنیانگذار آن را بیان کند.
مقاله امروز راهنماییست استراتژیک برای این بتوانید به این توضیح یک جملهای از محصول خود برسید.
این مقاله را از دست ندهید
https://medium.dave-bailey.com/the-magic-formula-to-describe-a-product-in-one-sentence-175ce38619c7
(زمان حدودی مطالعه، ۷ دقیقه)
#بررسی #استراتژی #محصول
@Dexign فلسفه دیزاین
ــــــ
میدانستید تعریف Mark Zuckerberg از Facebook چیست؟
«چیزی که شما میتواند اسم کسی را در آن جستجو کرده و کلی اطلاعات درباره آن فرد بفهمید.»
یا تعریف Travis Kalanick، از Uber (سرویسی که اسنپ مشابه آن است)؟
«شما دکمهای را فشار میدهید و ۵ دقیقه بعد یک مرسدس میاد و شما رو به هرکجا بخواهید میبره.»
در تعریف Mark Zuckerberg از سرویسی که بنیانگذار آن است، هیچ نشانی از «شبکه اجتماعی» یا دهها ویژگی منحصربفرد دیگر Facebook نیست.
آیا شما هم میتوانید تعریفی در این حد خلاصه و در یک جمله از محصول خود داشته باشید؟ بسیاری از ما اصرار داریم که تمامی ویژگیهای آن را در توضیح محصول بیاوریم و در نتیجه باعث سردرگمی دیگران میشویم.
در تمامی ارائههای شفاهی، توضیحات متنی و هر نوع توضیحی که هرجایی قرار است از محصول شما عنوان شود، باید بتوان بهینهترین آنها را ارائه داد که رسالت اصلی آن سرویس یا واضحترین ایده بنیانگذار آن را بیان کند.
مقاله امروز راهنماییست استراتژیک برای این بتوانید به این توضیح یک جملهای از محصول خود برسید.
این مقاله را از دست ندهید
https://medium.dave-bailey.com/the-magic-formula-to-describe-a-product-in-one-sentence-175ce38619c7
(زمان حدودی مطالعه، ۷ دقیقه)
#بررسی #استراتژی #محصول
@Dexign فلسفه دیزاین
ــــــ
Medium
The Art of Writing One-Sentence Product Descriptions
A look back at early interviews with Facebook and Uber CEOs illustrates an ingenious way to communicate hard-to-describe products.
Forwarded from Iran Agile
⭕ چکلیست دراکر برای ارزیابی سازمان
پیتر دراکر برای مدیران سازمانهای نوین و دانش-محور نام مهمی است. او کسی است که ده ها سال پیش، خیلی قبل از آنکه چیزی به عنوان فن آوری اطلاعات پا به عرصه وجود بگذارد، پیش بینی کرده بود که نسل آینده ی نیروی کار با تکیه بر اطلاعات ظهور خواهد کرد. یک سال از پایان جنگ جهانی دوم نگذشته بود که او در کتابش اصل عدم تمرکز و جنبه انسانی و اجتماعی سازمان ها را برجسته می کند. چیزهایی که شاید هنوز هم در ذهن بسیاری از مدیران ارشد سازمان ها مفاهیمی دور از ذهن و انقلابی به شمار می آیند.
نشریه Build اخیرا چک لیستی از مهمترین ویژگی های سازمان های مطلوب از دید دراکر منتشر کرده است.با مقایسه ی وضع جاری سازمان خود با این چک لیست، می توانید تصور کنید اگر پیتر دراکر پا به سازمان شما می گذاشت آن را چطور ارزیابی می کرد.
شرکت شما دراکر-گونه است اگر شما:
ماموریتی مشخص و قوی دارید و پاسخی قانع کننده به این سوال دشوار که: “ما در چه کسب و کاری هستیم؟”
همیشه به خاطر دارید که “همیشه فقط یک تعریف معتبر از هدف کسب و کار وجود دارد: ایجاد یک مشتری” در عین حال که می پذیرید “کیفیت یک محصول یا سرویس چیزی نیست که تامین کننده تویش می گذارد. بلکه چیزی است که مشتری از آن بیرون می آورد، و برایش حاضر است پول بدهد”.
مسئولیت و پاسخگویی را تا جایی که می شود در عمق سازمان به پایین می برید. به این استراتژی پایه ی ارتباطی عمل می کنید: به پایین گوش کن، با بالا صحبت کن.
این حقیقت را در آغوش می کشید که سازمان اشخاص را می سازد (یه به آنها کمک می کند که رشد کنند و یا آنها را از رشد باز می دارد) و بنابراین شما از هرچه می توانید برای کمک به رشد آنها دریغ نمی کنید.
نوآوری را (که یعنی تغییری که بعد جدیدی از کارایی را ایجاد می کند) به عنوان مسئولیت هر کسی در سازمان می دانید، نه فقط واحد تحقیق و توسعه.
به طور منظم چیزهایی را رها می کنید (محصولات، سیاست ها، روشها) که یا دیگر موثر نیستند و یا نسبت به فرصت های آینده، منابع زیادی را مصرف می کنند.
چیزهایی را که می شود اندازه گرفت اندازه می گیرید و چیزهایی را که نمی شود، زیر نظر دارید. این را هم قبول دارید که نیت خوب جایگزین نتایج و عملکرد نیست.
افق بلند مدت را در نظر دارید (نه فقط کوتاه مدت را) و به خاطر می سپارید که “تحلیلگران بازار سرمایه اعتقاد دارند شرکت ها پول می ساند، در حالی که شرکت ها کفش می سازند”.
با یک مجموعه ارزش های پایه زندگی می کنید، با این اعتقاد که سازمان به ارزش نیاز دارد، همانطور که بدن انسان به ویتامین نیاز دارد.
مسئولیت اجتماعی خود را به نمایش می گذارید، نه فقط با بخشیدن پول به خیریه ها، بلکه با درک اینکه سازمان نسبت به هر چیز و هر کسی که با آن در ارتباط است مسئول است.
@iranagile
https://goo.gl/v3iTxv
پیتر دراکر برای مدیران سازمانهای نوین و دانش-محور نام مهمی است. او کسی است که ده ها سال پیش، خیلی قبل از آنکه چیزی به عنوان فن آوری اطلاعات پا به عرصه وجود بگذارد، پیش بینی کرده بود که نسل آینده ی نیروی کار با تکیه بر اطلاعات ظهور خواهد کرد. یک سال از پایان جنگ جهانی دوم نگذشته بود که او در کتابش اصل عدم تمرکز و جنبه انسانی و اجتماعی سازمان ها را برجسته می کند. چیزهایی که شاید هنوز هم در ذهن بسیاری از مدیران ارشد سازمان ها مفاهیمی دور از ذهن و انقلابی به شمار می آیند.
نشریه Build اخیرا چک لیستی از مهمترین ویژگی های سازمان های مطلوب از دید دراکر منتشر کرده است.با مقایسه ی وضع جاری سازمان خود با این چک لیست، می توانید تصور کنید اگر پیتر دراکر پا به سازمان شما می گذاشت آن را چطور ارزیابی می کرد.
شرکت شما دراکر-گونه است اگر شما:
ماموریتی مشخص و قوی دارید و پاسخی قانع کننده به این سوال دشوار که: “ما در چه کسب و کاری هستیم؟”
همیشه به خاطر دارید که “همیشه فقط یک تعریف معتبر از هدف کسب و کار وجود دارد: ایجاد یک مشتری” در عین حال که می پذیرید “کیفیت یک محصول یا سرویس چیزی نیست که تامین کننده تویش می گذارد. بلکه چیزی است که مشتری از آن بیرون می آورد، و برایش حاضر است پول بدهد”.
مسئولیت و پاسخگویی را تا جایی که می شود در عمق سازمان به پایین می برید. به این استراتژی پایه ی ارتباطی عمل می کنید: به پایین گوش کن، با بالا صحبت کن.
این حقیقت را در آغوش می کشید که سازمان اشخاص را می سازد (یه به آنها کمک می کند که رشد کنند و یا آنها را از رشد باز می دارد) و بنابراین شما از هرچه می توانید برای کمک به رشد آنها دریغ نمی کنید.
نوآوری را (که یعنی تغییری که بعد جدیدی از کارایی را ایجاد می کند) به عنوان مسئولیت هر کسی در سازمان می دانید، نه فقط واحد تحقیق و توسعه.
به طور منظم چیزهایی را رها می کنید (محصولات، سیاست ها، روشها) که یا دیگر موثر نیستند و یا نسبت به فرصت های آینده، منابع زیادی را مصرف می کنند.
چیزهایی را که می شود اندازه گرفت اندازه می گیرید و چیزهایی را که نمی شود، زیر نظر دارید. این را هم قبول دارید که نیت خوب جایگزین نتایج و عملکرد نیست.
افق بلند مدت را در نظر دارید (نه فقط کوتاه مدت را) و به خاطر می سپارید که “تحلیلگران بازار سرمایه اعتقاد دارند شرکت ها پول می ساند، در حالی که شرکت ها کفش می سازند”.
با یک مجموعه ارزش های پایه زندگی می کنید، با این اعتقاد که سازمان به ارزش نیاز دارد، همانطور که بدن انسان به ویتامین نیاز دارد.
مسئولیت اجتماعی خود را به نمایش می گذارید، نه فقط با بخشیدن پول به خیریه ها، بلکه با درک اینکه سازمان نسبت به هر چیز و هر کسی که با آن در ارتباط است مسئول است.
@iranagile
https://goo.gl/v3iTxv
#پست_مجدد این پست تا به حال بیش از ۱۴۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
قانون Conways در استفاده از مایکروسرویسها در معماری نرمافزار بسیار قانون جالبی است. این روزها در بسیاری از تیمهای نرمافزاری بحث استفاده یا عدم استفاده از مایکروسرویسها در معماری آینده تیم مطرح است. قانون Conways به طور کلی در مورد سیستمها صحبت میکند. این قانون میگوید:
«اگر تیم و یا سازمانی در حال طراحی یک سیستم است (نه لزوما سیستم اطلاعاتی) طراحی نهایی آنها احتمالا شبیه ساختار ارتباطی همان سازمان است.»
برای مثال اگر تیم برنامهنویسی در مکانهای فیزیکی مختلف، مثلا شهرهای مختلف، یا حتی زیر-تیمهای جدا کار میکند احتمالا معماری نرمافزارشان نیز بیشتر شبیه معماری مایکروسرویس است. در مقابل اگر یک تیم بزرگ برنامهنویسی هستید که همه در یک تیم کار میکنید احتمالا نرمافزارتان بیشتر شبیه یک مونولیت است.
این قانون گرچه اثبات نشده، ولی به طور ضمنی میگوید اگر میخواهید سراغ مایکروسرویس بروید، باید کل تیمتان هم مایکروسرویسی شود.
https://www.thoughtworks.com/insights/blog/demystifying-conways-law
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/8byp30emn9u
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
«اگر تیم و یا سازمانی در حال طراحی یک سیستم است (نه لزوما سیستم اطلاعاتی) طراحی نهایی آنها احتمالا شبیه ساختار ارتباطی همان سازمان است.»
برای مثال اگر تیم برنامهنویسی در مکانهای فیزیکی مختلف، مثلا شهرهای مختلف، یا حتی زیر-تیمهای جدا کار میکند احتمالا معماری نرمافزارشان نیز بیشتر شبیه معماری مایکروسرویس است. در مقابل اگر یک تیم بزرگ برنامهنویسی هستید که همه در یک تیم کار میکنید احتمالا نرمافزارتان بیشتر شبیه یک مونولیت است.
این قانون گرچه اثبات نشده، ولی به طور ضمنی میگوید اگر میخواهید سراغ مایکروسرویس بروید، باید کل تیمتان هم مایکروسرویسی شود.
https://www.thoughtworks.com/insights/blog/demystifying-conways-law
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/8byp30emn9u
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Thoughtworks
Demystifying Conway's Law | Thoughtworks
Many years ago, Melvin Conway had observed that how organizations were structured would have a strong impact on any systems they created. His observation has become known as Conway’s Law, and the collective experiences of both my colleagues and myself have…
#پست_مجدد این پست تا به حال بیش از ۲۴۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
شایعترین دلیل تخمین زمان اشتباه یک پروژه
تخمین زمان یک پروژه کار آسانی نیست، مخصوصا اگر بخواهید خیلی دقیق باشید. ولی اغلب موارد مشکل تخمین این نیست که خیلی دقیق نیست، بلکه مشکلش این است که خیلی پرت است!
یکی از شایعترین عواملی که باعث میشود تخمین زمانی یک پروژه خیلی اشتباه باشد، تفاوت قائل نشدن بین دو مفهوم خیلی مهم است: «تخمین زمان» و «تخمین کار».
«تخمین زمان» مفهومی است که مدیران پروژه دوست دارند در مورد آن صحبت کنند. وقتی صحبت میکنند دائما به دنبال شنیدن تخمین زمانی هستند. برای مثال جملهای مانند «این کار تا پنجشنبه هفته بعد انجام میشود» جملهای است که زمان انجام شدن کار را تخمین میزند.
در مقابل «تخمین کار» مفهومی است که معمولا برنامهنویسان دوست دارند در مورد آن صحبت کنند. آنها ترجیح میدهند بگویند که این کار به چقدر زمان نیاز دارد. مثلا کاری است که به ۳ روز زمان نیاز دارد. مثلا جمله «این کار به یک هفته کار نیاز دارد» به این معنی نیست که یک هفته دیگر این کار تمام میشود و صرفا حجم کار مورد نیاز بیان شده.
برای یک تخمین موفق باید این مفاهیم در جلسات کاملا واضح شوند و در مورد آنها جداگانه صحبت شود. همچنین بهتر است از هر دو طیف افراد بالا در جلسات حضور داشته باشند تا جوانب مختلف بررسی شود.
پست زیر این دو مفهوم را معرفی کرده و تفاوت آنها را در مدیریت پروژه شرح دادهاست.
https://mehrandvd.me/2017/08/02/effort-vs-time-estimation/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/958i30erVZs
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
تخمین زمان یک پروژه کار آسانی نیست، مخصوصا اگر بخواهید خیلی دقیق باشید. ولی اغلب موارد مشکل تخمین این نیست که خیلی دقیق نیست، بلکه مشکلش این است که خیلی پرت است!
یکی از شایعترین عواملی که باعث میشود تخمین زمانی یک پروژه خیلی اشتباه باشد، تفاوت قائل نشدن بین دو مفهوم خیلی مهم است: «تخمین زمان» و «تخمین کار».
«تخمین زمان» مفهومی است که مدیران پروژه دوست دارند در مورد آن صحبت کنند. وقتی صحبت میکنند دائما به دنبال شنیدن تخمین زمانی هستند. برای مثال جملهای مانند «این کار تا پنجشنبه هفته بعد انجام میشود» جملهای است که زمان انجام شدن کار را تخمین میزند.
در مقابل «تخمین کار» مفهومی است که معمولا برنامهنویسان دوست دارند در مورد آن صحبت کنند. آنها ترجیح میدهند بگویند که این کار به چقدر زمان نیاز دارد. مثلا کاری است که به ۳ روز زمان نیاز دارد. مثلا جمله «این کار به یک هفته کار نیاز دارد» به این معنی نیست که یک هفته دیگر این کار تمام میشود و صرفا حجم کار مورد نیاز بیان شده.
برای یک تخمین موفق باید این مفاهیم در جلسات کاملا واضح شوند و در مورد آنها جداگانه صحبت شود. همچنین بهتر است از هر دو طیف افراد بالا در جلسات حضور داشته باشند تا جوانب مختلف بررسی شود.
پست زیر این دو مفهوم را معرفی کرده و تفاوت آنها را در مدیریت پروژه شرح دادهاست.
https://mehrandvd.me/2017/08/02/effort-vs-time-estimation/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/958i30erVZs
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Dot Philosophy
Effort vs. Time Estimation - Dot Philosophy
Estimating the required time for a task, is not an easy job to do, if you want to be precise! The main problem with estimating is that, most of the time it is wrong! Being wrong is not too bad for an estimation. But, being too wrong is a disaster for a project.…
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. آشنایی با قانون حیاتی که تیم برنامهنویسی «آزمایشگاه نیروی متحرکه جت» ناسا
https://t.iss.one/SoftwarePhilosophy/1051
۲. آیا محصول شما در جیب جا میشود؟ (فلسفه دیزاین)
https://t.iss.one/SoftwarePhilosophy/1052
۳. چکلیست دراکر برای ارزیابی سازمان (Iran Agile)
https://t.iss.one/SoftwarePhilosophy/1053
۴. قانون Conways در استفاده از مایکروسرویسها در معماری نرمافزار
https://t.iss.one/SoftwarePhilosophy/1055
۵. شایعترین دلیل تخمین زمان اشتباه یک پروژه
https://t.iss.one/SoftwarePhilosophy/1057
ـــــــــــ
@SoftwarePhilosophy
۱. آشنایی با قانون حیاتی که تیم برنامهنویسی «آزمایشگاه نیروی متحرکه جت» ناسا
https://t.iss.one/SoftwarePhilosophy/1051
۲. آیا محصول شما در جیب جا میشود؟ (فلسفه دیزاین)
https://t.iss.one/SoftwarePhilosophy/1052
۳. چکلیست دراکر برای ارزیابی سازمان (Iran Agile)
https://t.iss.one/SoftwarePhilosophy/1053
۴. قانون Conways در استفاده از مایکروسرویسها در معماری نرمافزار
https://t.iss.one/SoftwarePhilosophy/1055
۵. شایعترین دلیل تخمین زمان اشتباه یک پروژه
https://t.iss.one/SoftwarePhilosophy/1057
ـــــــــــ
@SoftwarePhilosophy
#پست_مجدد این پست تا به حال بیش از ۱۳۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
آیا ترکیب WebAssembly و .Net آینده برنامهنویسی front-end است؟ این نام مقاله جدید اسکات هانسلمن است که در آن توضیح میدهد چطور .NET Core 2.0 این ایده را امکان پذیر کردهاست که کدهای front-end را با c# نوشت و به WebAssembly کامپیال کرد. در این مقاله توضیح داده شده که چطور Steve Sanderson (برنامه نویس اصلی فریمورک knockout) در یک پروژه آزمایشی به نام Blazor دقیقا مانند Angular, Knockout و Ember کد نوشته، با این تفاوت که این کد با C# نوشته شده.
مقاله زیر جزئیات نوشتن کد روی WebAssembly را با استفاده از .Net Core و C# شرح دادهاست.
https://www.hanselman.com/blog/NETAndWebAssemblyIsThisTheFutureOfTheFrontend.aspx
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/KVCh30ewRvs
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
مقاله زیر جزئیات نوشتن کد روی WebAssembly را با استفاده از .Net Core و C# شرح دادهاست.
https://www.hanselman.com/blog/NETAndWebAssemblyIsThisTheFutureOfTheFrontend.aspx
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/KVCh30ewRvs
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Hanselman
.NET and WebAssembly - Is this the future of the front-end?
6 years ago Erik Meijer and I were talking about how JavaScript is/was an assembly language. It turned into an ...
Forwarded from فلسفه دیزاین
دیزاین برای حافظه، دیزاین برای انسانها
در گذشته به اعداد اعتقاد نداشتم و سالهای سال تمامی حرفها و افسانههایی که درباره اعداد گفته میشد را نادیده میگرفتم. بعد از وارد شدن به زمینه دیزاین، وقتی داشتم سعی میکردم که در موضوعات مختلف اطلاعات کسب کنم، به جملاتی برخوردم که نظرم را تغییر داد.
«اگر به آدمها بگویید یک عدد تصادفی تک رقمی بگویند، اکثر آنها عدد ۷ را خواهند گفت.»
«بیشتر افراد میتوانند حداکثر ۷ چیز را در لحظه و در حافظه کوتاهمدت خود نگهدارند.»
و جملاتی از این دست.
امروز مقالهای را بررسی میکنیم که نویسنده آن، آقای Martin Jancik، طراحی در چارچوب محدودیتهای حافظه انسان را هدف قرارداده و با معرفی مقالات و نظریات مختلف سعی دارد ما را برای رسیدن به دیزاینی که هماهنگ با روندهای حافظه انسان است، یاری کند.
آقای Jancik مطالب مختلفی را در رابطه با این موضوع مطرح میکند که بخشیهایی از طراحی حسی، یکپارچگی طرح و غیره را شامل میشود.
از نکات جالب توجه در این مقاله که شاید بسیاری از ما از این زاویه به آنها نگاه نکرده باشیم، میتوان به تغییر رنگ Linkهای کلیک شده روی صفحات وب اشاره کرد که به حافظه ما کمک میکند.
پیشنهاد میکنم این مقاله جالب را همین حالا مطالعه کنید.
https://uxplanet.org/designing-for-human-memory-a2cdc0b6a75a
(زمان حدودی مطالعه، ۱۰ دقیقه)
#بررسی #استراتژی #طراحی
@Dexign فلسفه دیزاین
____
در گذشته به اعداد اعتقاد نداشتم و سالهای سال تمامی حرفها و افسانههایی که درباره اعداد گفته میشد را نادیده میگرفتم. بعد از وارد شدن به زمینه دیزاین، وقتی داشتم سعی میکردم که در موضوعات مختلف اطلاعات کسب کنم، به جملاتی برخوردم که نظرم را تغییر داد.
«اگر به آدمها بگویید یک عدد تصادفی تک رقمی بگویند، اکثر آنها عدد ۷ را خواهند گفت.»
«بیشتر افراد میتوانند حداکثر ۷ چیز را در لحظه و در حافظه کوتاهمدت خود نگهدارند.»
و جملاتی از این دست.
امروز مقالهای را بررسی میکنیم که نویسنده آن، آقای Martin Jancik، طراحی در چارچوب محدودیتهای حافظه انسان را هدف قرارداده و با معرفی مقالات و نظریات مختلف سعی دارد ما را برای رسیدن به دیزاینی که هماهنگ با روندهای حافظه انسان است، یاری کند.
آقای Jancik مطالب مختلفی را در رابطه با این موضوع مطرح میکند که بخشیهایی از طراحی حسی، یکپارچگی طرح و غیره را شامل میشود.
از نکات جالب توجه در این مقاله که شاید بسیاری از ما از این زاویه به آنها نگاه نکرده باشیم، میتوان به تغییر رنگ Linkهای کلیک شده روی صفحات وب اشاره کرد که به حافظه ما کمک میکند.
پیشنهاد میکنم این مقاله جالب را همین حالا مطالعه کنید.
https://uxplanet.org/designing-for-human-memory-a2cdc0b6a75a
(زمان حدودی مطالعه، ۱۰ دقیقه)
#بررسی #استراتژی #طراحی
@Dexign فلسفه دیزاین
____
Medium
Designing for Human Memory
How we can design interfaces that eliminate confusion and lower the cognitive effort.
Forwarded from Iran Agile
🔴 اسکرام روزانه و «هادل»های ورزشی
در دنیای ورزش به اقدام افراد یک تیم برای تشکیل یک حلقه فشرده جهت مرور استراتژی، برنامهریزی کوتاهمدت، انگیزه گیری و یا جشن، «هادل» (Huddle) گفته میشود.
یکی از دلایل اولیه شکلگیری این رفتار، پر سروصدا بودن استادیومهای ورزشی بوده است که گاهی باعث میشد که افراد تیم حتی صدای یکدیگر را هم نشنوند بنابراین برای افزایش تمرکز، نفوذ کلام و مرور استراتژی، دست به ایجاد حلقه فشرده میزدند. امروزه از هادل در اکثر ورزشهای گروهی مانند فوتبال، کریکت، بسکتبال، راگبی و غیره استفاده میشود.
این هادلها بهمرورزمان به نوعی عرف ورزشی تبدیل شده و دارای خصوصیات مشترکی شامل موارد زیر هستند:
بسیار کوتاه هستند.
مخصوص اعضای تیم است و مربیها و دیگر عوامل در آن حضور ندارند.
اعضای تیم در یک نگاه سریع میتوانند میزان خستگی یا شادابی تیم را تخمین بزنند.
مصدومیتها و موانع گفته و شنیده میشود.
ارتباط کلامی در آن به حداقل میرسد و افراد از زبان بدن و کدگذاریهای ویژه برای انتقال اطلاعات استفاده میکنند.
استقلال و خودسازماندهی تیمی بهطور مرتب تمرین میشود.
روحیه تیمی بهوسیله ارتباطهای چشمی و چهره به چهره بازسازی یا تقویت میشود.
خاستگاه رویداد «اسکرام روزانه» همین هادلها است. گاهی نیز از ترکیب «هادل روزانه» برای توصیف جلسات روزانه و سرپایی تیمها استفاده میشود. برای داشتن یک اسکرام روزانه مؤثر میتوان از خصوصیات یک هادل ورزشی که به برخی از آنها اشاره شد، الگو گرفت.
https://goo.gl/mjFbDk
@IranAgile
در دنیای ورزش به اقدام افراد یک تیم برای تشکیل یک حلقه فشرده جهت مرور استراتژی، برنامهریزی کوتاهمدت، انگیزه گیری و یا جشن، «هادل» (Huddle) گفته میشود.
یکی از دلایل اولیه شکلگیری این رفتار، پر سروصدا بودن استادیومهای ورزشی بوده است که گاهی باعث میشد که افراد تیم حتی صدای یکدیگر را هم نشنوند بنابراین برای افزایش تمرکز، نفوذ کلام و مرور استراتژی، دست به ایجاد حلقه فشرده میزدند. امروزه از هادل در اکثر ورزشهای گروهی مانند فوتبال، کریکت، بسکتبال، راگبی و غیره استفاده میشود.
این هادلها بهمرورزمان به نوعی عرف ورزشی تبدیل شده و دارای خصوصیات مشترکی شامل موارد زیر هستند:
بسیار کوتاه هستند.
مخصوص اعضای تیم است و مربیها و دیگر عوامل در آن حضور ندارند.
اعضای تیم در یک نگاه سریع میتوانند میزان خستگی یا شادابی تیم را تخمین بزنند.
مصدومیتها و موانع گفته و شنیده میشود.
ارتباط کلامی در آن به حداقل میرسد و افراد از زبان بدن و کدگذاریهای ویژه برای انتقال اطلاعات استفاده میکنند.
استقلال و خودسازماندهی تیمی بهطور مرتب تمرین میشود.
روحیه تیمی بهوسیله ارتباطهای چشمی و چهره به چهره بازسازی یا تقویت میشود.
خاستگاه رویداد «اسکرام روزانه» همین هادلها است. گاهی نیز از ترکیب «هادل روزانه» برای توصیف جلسات روزانه و سرپایی تیمها استفاده میشود. برای داشتن یک اسکرام روزانه مؤثر میتوان از خصوصیات یک هادل ورزشی که به برخی از آنها اشاره شد، الگو گرفت.
https://goo.gl/mjFbDk
@IranAgile
یکی از دغدغههای همیشگی برنامهنویسان، تولید نرمافزار با سرعت بیشتر و کیفیت بالاتر میباشد. یکی از زبانهای جدید پرطرفدار که به این امر کمک می کند F# است. با F# میتوان بصورت Functional کد نوشت. تعداد خطوط نوشته شده در زبانهای Functional نسبت به سایر زبانها کم میباشد. بطور مثال ۲۰ خط کد در C# با حدود ۵ خط کد در F# قابل بازنویسی است. ویدیو زیر به معرفی F# برای برنامه نویسان C# پرداخته است.
https://www.youtube.com/watch?v=KPa8Yw_Navk
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/KfWV30h1wUK
#علیرضا_وفی (https://ow.ly/Vna930dsUGr)
کانال تلگرام:
@SoftwarePhilosophy
___
https://www.youtube.com/watch?v=KPa8Yw_Navk
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/KfWV30h1wUK
#علیرضا_وفی (https://ow.ly/Vna930dsUGr)
کانال تلگرام:
@SoftwarePhilosophy
___
YouTube
F# for C# programmers - Scott Wlaschin
Curious about F# and want to understand how is it different from C#?
In this talk, we'll look at the basics of coding in F#, and how functional programming differs from object-oriented programming. Along the way, there will be many examples showing the same…
In this talk, we'll look at the basics of coding in F#, and how functional programming differs from object-oriented programming. Along the way, there will be many examples showing the same…
#پست_مجدد این پست تا به حال بیش از ۱۲۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
ممکن است در فرایند توسعهی برنامههای SPA که UI آنها با screenهای با اندازههای متفاوت موبایل تا دسکتاپ سازگار است٬ نیاز به تست برنامه روی Device ها داشته باشید. Browsersync ابزاری قدرتمند است که در ترکیب با Webpack و Hot Reloading این امکان را به شما میدهد تا به جای تست app روی شبیه ساز های device بتوانید مستقیما روی device تست و debug را انجام دهید.
برای توضیحات بیشتر به لینک زیر مراجعه کنید.
https://manavsehgal.com/browsersync-and-webpack-for-testing-web-apps-across-multiple-devices-64e7f7fa62f2
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/3dge30eCtwT
#شراره_لطفی (https://ow.ly/xvC530dx8xL)
کانال تلگرام:
@SoftwarePhilosophy
___
برای توضیحات بیشتر به لینک زیر مراجعه کنید.
https://manavsehgal.com/browsersync-and-webpack-for-testing-web-apps-across-multiple-devices-64e7f7fa62f2
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/3dge30eCtwT
#شراره_لطفی (https://ow.ly/xvC530dx8xL)
کانال تلگرام:
@SoftwarePhilosophy
___
Manav Sehgal
Browsersync and Webpack For Testing Web Apps Across Multiple Devices
Your single page app is mobile-web friendly. It responds to smaller or larger screen sizes and adapts the UI accordingly. As you continue…
#پست_مجدد این پست تا به حال بیش از ۱۸۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
تبدیل کدهای C# به JavaScript در بسیاری از شرایط میتوان مفید باشد. معمولا قسمت قابل توجهی از کدهای بین سرور و کلاینت که شبیه هم هستند میتوانند در یک جا نوشته شوند. برای مثال مدلهای انتقال اطلاعات DTO و یا Validation ها همه کدهایی هستند که پس از تعریف در سمت سرور میتوانند در سمت کلاینت هم دوباره استفاده شوند.
هدف پروژه Bridge.NET اینجا امکان تبدیل کدهای C# به کدهای TypeScript و یا JavaScript است. در سایت این پروژه به صورت آنلاین میتوانید آن را آزمایش کنید تا از نحوه کار آن مطلع شوید.
https://bridge.net/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/yrVs30eL96Y
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
هدف پروژه Bridge.NET اینجا امکان تبدیل کدهای C# به کدهای TypeScript و یا JavaScript است. در سایت این پروژه به صورت آنلاین میتوانید آن را آزمایش کنید تا از نحوه کار آن مطلع شوید.
https://bridge.net/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/yrVs30eL96Y
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
bridge.net
Domain Names For Sale
Looking for the perfect domain?