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

زبان JavaScript‌ را با کارایی بالا و بدون خطاهای زمان اجرا تولید کنید.
زبان‌های برنامه نویسی ML-family از جمله Haskell و Ocaml کامپایلرهایی دارند که تقریبا همه‌ی خطاها را در زمان کامپایل شناسایی می‌کنند و امکان بروز خطا در محیط تولید را به صفر می‌رسانند. زبان‌های ML-family برای back-end هستند و به دلیل سختی یادگیری و کاربری٬ چندان مورد توجه برنامه‌نویسان قرار نگرفتند. تلاش‌های زیادی برای آوردن robustness زبان‌های ML-family به برنامه‌نویسی front-end انجام شد که نتیجه‌ی آن پروژه‌هایی از جمله Fay و GHCJS هستند که به JavaScript‌ کامپایل می‌شوند. اما همچنان به دلیل سختی یادگیری و کاربری٬ این پروژه‌ها هم منزوی شدند. یادگیری JavaScript ساده است اما نگهداری پروژه‌های بزرگ JavaScript کابوس دهشتناکی است. زبانی با robustness زبان‌های ML-family و کاربری بالای زبان JavaScript می تواند پاسخگوی نیاز برنامه‌نویسی front-end باشد. Elm‌ با چنین نگرشی ایجاد شد. Elm‌ زبان برنامه نویسی functional برای ایجاد برنامه‌های front-end است. Elm بهترین‌های دو دنیا را برای ساخت راحت‌تر برنامه های robust در خود جای داده است. Richard Feldman در سخنرانی خود در کنفراس Goto 2017 به معرفی Elm پرداخته است.

https://www.youtube.com/watch?v=28aJOb1A34o

همچنین لینک زیر چگونگی کاربری Elm‌را تشریح می کند.

https://guide.elm-lang.org/

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

https://ow.ly/uASh30e4wRc

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


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


___

حاشیه‌هایی شیرین‌تر از داستان

چند وقتی‌ست که از کنفرانس اپل می‌گذرد. همان کنفرانسی که در آن iPhone X و برخی محصولات دیگرش را معرفی کرد.
مثل همیشه گمانه‌زنی‌هایی پیش از کنفرانس شده بود و همه کسانی که پیگیر بودند، می‌دانستند که باید منتظر چه چیزی باشند. خود اپل هم که انگار از این شایعات و حدس‌های مردم لذت می‌برد، با منتشر کردن عکسی از لوگوی کنفرانس، شرلوک درون مردم را قلقلک داد.
خلاصه کنفرانس برگزار شد و تغییراتی بزرگ و کوچک روی محصولات پیشین و نمونه جدید آن‌ها معرفی شد. یکی از پرسروصداترین محصولات امسال اپل، iPhone X است. منظور من از سروصدا لزوما صحبت‌های خوب درباره این دستگاه جدید نیست. این آیفون جدید، به سنسور تشخیص چهره‌ای (ساختاری مشابه دستگاه‌های Kinect) مجهز است که باعث شده طراحان اپل نتوانند صفحه نمایش دستگاه را بصورت لبه تا لبه (edge-to-edge) طراحی کنند. مردم در شبکه‌های اجتماعی، نام این قسمت را The Notch (به معنی فرورفتگی) نامیدند و شروع به ارائه ایده‌های جالب، خنده‌دار و بعضا تحلیل‌های مختلفی کردند.

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

https://blog.prototypr.io/notch-crazy-iphone-x-mad-475f43d6ee26

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

#بررسی #محصول #حواشی
@Dexign فلسفه دیزاین


ــــــــــــــــــ

🔴 واگذاری اختیارات به تیم‌های خودسازمانده

معنی اين جمله که می گويد: « تيم های چابک خود سازمانده هستند» چيست؟ و اينکه اصطلاح درستی است؟ برخی از افراد می گويند تيم ها خود مديريت هستند. برای درک اينکه کدام يک از اين اصطلاحات مناسب تر است بياييد چهار سطح از خودمختاری را که تيم ها می توانند داشته باشند را در نظر بگيريد.

⏬ چهار شیوه توزيع اختیارت:

ريچارد هاکمن استاد دانشگاه هاروارد چهار سطح تخصيص اختيار و قدرت به تيم ها را مورد بررسی قرار داده است. بياييد نگاهی بياندازيم به چهار سطح واگذاری قدرت به تيم ها از منظر هاکمن با شروع از کمترين سطح.

1⃣ يک تيم با کمترين سطح اختيار توسط يک مدير هدايت می شود (Manager-led). اين گونه تيم ها برای انجام کارهای تخصيص يافته به آنها اختيار و قدرت دارند ولی بر روی فرآيندهايشان هيچ گونه قدرت و اختياری ندارند و فقط مدير بر اين فرآيندها مديريت دارد.

2⃣ سطح دوم از منظر هاکمن تيم های خود مديريت (self-managing) هستند. يعنی علاوه بر اختيار و قدرت در انجام وظايف می توانند فرآيندهايشان را نيز خود مديريت کنند. تيم خود مديريت می تواند تصميم بگيرد چگونه کار کند به عنوان مثال می تواند درباره استفاده و بکارگيری نگرش چابک تصميم گيری کند.

3⃣ با افزايش سطح اختيار ، با تيم های خود طراح (self-designing) مواجه می شويم. آنها می توانند کسانی که در تيم هستند را تعديل يا تغيير دهند. اين نوع از تيم‌ها می توانند فردی را از تيم اخراج کنند، می توانند در مورد انتقال يا استخدام افراد ديگر در تيم و … تصميم گيری کنند. در برخی از موارد هم تيم‌های خود طراح اختيار گزارش دادن به افراد مرتبط داخل تيم يا خارج تيم را دارند.

4⃣ آخرين نوع از تيم ها، و يکی از مختارترين آنها، تيم های خودمختار (self-governing) هستند. تيم های خودمختار علاوه بر ساير اختيارات، اختيار تغيير اهداف اصلی تيم را هم دارند. تيم های خودمختار می توانند تصميم بگيرند به جای يک محصول اندازه گيری صوتی يک بازی ويدئویی بسازند.

⏬ نوع تيم اختيارات

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

کجای اين سلسله مراتب برای خودسازماندهی مناسب است؟

در سلسله مراتب قدرت و اختيارات هاکمن، تيم های خودسازمانده (self-organizing) چابک در کلاس تيم های خود مديريت قرار می گيرند. تيم های خود سازمانده چابک کارهايشان را خود مديريت می کنند: کدام يک از افراد تيم بايد اين وظيفه را انجام دهد؟ و همچنين درباره چگونگی انجام آن کار هم خودشان مختار هستند: بايد با اسکرام شروع کنيم يا کانبان؟ اسپرينت ما بايد چقدر طول بکشد؟

تيم های چابک خود طراح و خودمختار نيستند، به عبارت ديگر تيم های خود سازمانده بر روی وظايف و فرآيندهايي که استفاده می کنند مختار هستند اما اختياری بر روی نفراتی که بايد در تيم باشند يا اهداف تيم ندارند.

تيم های چابک خود سازمانده هستند يا خود مديريت؟

هر کدام از اينها را می توانيد در نظر بگيريد. اما من اصطلاح خود سازمانده را به دو دليل ترجيح می دهم :

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

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

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

https://goo.gl/6puZ9J

@iranagile

فیسبوک علاوه بر توسعه React برای وب و موبایل قدم به حوزه‌ی دیگری نیز نهاده است. با استفاده از React VR می‌توان با استفاده از جاوا اسکریپت نرم افزارهای واقعیت مجازی تولیدی نمود.

https://facebook.github.io/react-vr

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

https://ow.ly/sjGB30gAX3w

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


کانال تلگرام:
@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

___

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

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

۲. آشنایی با زبان Elm
#elm #javascript #haskel
https://t.iss.one/SoftwarePhilosophy/1032
https://t.iss.one/SoftwarePhilosophy/1033

۳. حاشیه‌هایی شیرین‌تر از داستان (فلسفه دیزاین)
#design
https://t.iss.one/SoftwarePhilosophy/1034

۴. واگذاری اختیارات به تیم‌های خودسازمانده (Iran Agile)
#agile
https://t.iss.one/SoftwarePhilosophy/1035

۵. استفاده از React VR و جاوا اسکریپت برای تولید نرم افزارهای واقعیت مجازی
#react #vr #javascript
https://t.iss.one/SoftwarePhilosophy/1036

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

ـــــــــــ

@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

___

معرفی مفهوم Interaction Flows

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

ما پیشتر هم درباره این چالش صحبت کرده و ابزارهایی برای انتقال انیمیشن‌های تعاملی معرفی کرده‌ایم. امروز می‌خواهیم راه‌حل پیشنهادی خانم Havana Nguyen را درباره انتقال روندهای دیزاین بررسی کنیم.
ایشان پس از طرح مساله بالا، راه‌حل‌های مختلف ارائه شده را بررسی کرده و با ترکیب مفاهیم Wireflow و بنیان‌های ساخت Microinteractionها، یک Template جدید با نام IX Flows ارائه کردند.
این Template از دید من ترکیبی‌ست از Storyboard و Functional Specification، و مفهومی‌ست کارآمد برای مستندسازی یک دیزاین و انتقال تمام و کمال آن به تیم توسعه.

پیشنهاد می‌کنم همین حالا مقاله را بررسی کرده تا بتوانید آن را در محصولات خود به کار ببندید.

https://uxplanet.org/an-introduction-to-interaction-flows-a4f783402529


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

#معرفی #متد #اینتراکشن

@Dexign فلسفه دیزاین

ـــــــــ

🔴 مدیران را اخراج کنید!

خیلی از کارمندها بجای آنکه برای شرکت یا مشتریان کار کنند، برای روسای شان کار می کنند. کسب و کارها این روزها با لایه های متعدد مدیریتی پر شده اند، و کارمندها باید به فکر کارهای سیاسی و انجام کارهایی برای راضی کردن رییس شان باشند.

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

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

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

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

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

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

https://goo.gl/2G14vC

@iranagile

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

تاکنون اتصال به دستگاه‌های بلوتوث تنها از طریق 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

___

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

۱. آشنایی با 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

___