درون کمپانی های نرم افزاری چه می گذرد؟

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

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

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

توصیه می کنم در هر زمینه اگر می خواهید کار جدیدی در شرکت شروع کنید، در این بلاگ ها جستو کرده و تجربیات شان در زمینه ای که می خواهید مرور کنید.

* بلاگ تست گوگل
https://testing.googleblog.com/

* بلاگ فنی نت فلیکس | شامل مطالب خوبی پیرامون مایکروسرویس ها، استریمینگ و ماشین لرنینگ
https://medium.com/netflix-techblog

* بلاگ فنی یوتیوب
https://youtube-eng.googleblog.com/2016/05/

* بلاگ فنی گیت هاب
https://github.com/blog

* بلاگ فنی Stackoverflow | دارای مطالبی خواندنی حتی برای خواننده متوسط
https://stackoverflow.blog/engineering/

* تجربیات مایکروسافت در حرکت به سمت توسعه های سریع تر، با کیفیت تر و مقاوم تر
https://www.visualstudio.com/learn/monolith-cloud-service/

* بلاگ فنی مایکروسافت DevOps
https://blogs.msdn.microsoft.com/devops/

* بلاگ فنی فیس بوک
https://research.fb.com/blog/

(این فهرست به روز خواهد شد)

@irandotnet

چه می‌کنه این نمودار

هرچقدر هم که تجربه دیزاین داشته باشید، آن لحظه‌ای که فکر می‌کنید «دیزاین این که دیگر کاری ندارد!»، مهلک‌ترین اشتباه خود را مرتکب می‌شوید. چرا که حتی مفاهیم پرتکرار و بعضا کلیشه‌ای هم در زمین بازی یا context جدید، می‌توانند شما را به شکل عجیبی غافلگیر کرده و مجبورتان کنند تاکتیک خود را تغییر دهید.

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

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

https://blog.sariina.com/878-how-did-we-design-90s-charts-and-lottery

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

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

___

نکته ای در رابطه با استفاده بهینه از HttpClient


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

در مواردی که از HttpClient برای ارسال درخواست ها استفاده می کنیم، باید این نکته را به خاطر داشته باشیم که تنها و تنها یک نمونه از HttpClient در برنامه داشته باشیم و در همه موارد از همین یک نمونه استفاده کنیم. این یک نمونه می تواند توسط الگوی Singleton که پیشتر توضیح داده شده بود، ایجاد شود.

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

کلاس HttpClient از اساس Thread-safe طراحی شده است. یعنی می توان با داشتن یک نمونه از آن، همزمان در thread های مختلف - درخواست های مختلف کاربران در یک وب اپلیکیشن - از همان یک نمونه استفاده کرد و کار هیچ Thread ایی بر دیگری اثر نخواهد گذاشت.

* تجربه تلخ از عدم استفاده صحیح از HttpClient
https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/

* توصیه رسمی مایکروسافت بر ساخت یک نمونه از HttpClient و استفاده از آن در باقی نقاط برنامه:
https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient?view=netframework-4.7

* توضیحی دقیق در مورد thread-safety کلاس HttpClient
http://www.michaeltaylorp3.net/httpclient-is-it-really-thread-safe/

@irandotnet

دو مورد کلی باعث Gold Plating می شود:

1- عطش یادگیری در نیروهای فنی : چه دوست داشته باشیم یا نه، این ویژگی بارز نیروهای فنی است و آنها همیشه دوست دارند تکنولوژی های جدید را تجربه کنند و یاد بگیرند و دوباره یاد بگیرند. البته نیروی فنی با دیدن فیلم آموزشی یا کلاس چیزی یاد نمی گیرد، او زمانی یاد می گیرد که در پروژه (واقعی) تجربه کرده باشد. اما بعضی وقت ها هزینه یادگیری، یک پروژه شکست خورده می شود (یکی از دوستان می گفت؛ خوب چی مهم تر از این (: )

2- بزرگ جلوه دادن پروژه از سمت مدیران محصول: بعضی وقت ها مدیران محصول بدلیل عدم آشنایی با کسب کار، پروژه را بزرگ جلوه می دهند. مثلا برنامه نویس می پرسد چند نفر قرار است با این سیستم همزمان کار کنند، جواب "خیلی زیاد مثلا 500 هزار نفر". یا "آیا قرار است بعدا این قوانین کسب کار توسط خود مشتری عوض شوند؟" جواب: "بله". شاید یک جواب بله، باعث بشود که تیم به سراغ Workflow engine - فرم ساز و ... بروند و این یعنی هزینه خیلی زیاد.

👍 راه حل :

1- عطش یادگیری را نمی توان از بین برد، ولی شرکت هایی مثل گوگل که 20 درصد زمان را به خود نفرات می دهند، شاید یکی از دلایل همین یادگیری در حین کار باشد.

2- اصلا YAGNI در مورد این است که به چیزی که نیاز ندارید و مطئمن نیستید زیاد فکر نکنید، You are not gonna need it. یکی از هنرهای مدیریت محصول این است که تیم را به سمت ایجاد یک راه حل بزرگ نکشاند و سعی کند مشکل کسب کار را با کوچکترین راه حل ممکن حل کند.

3- هنر تیم هم این است که با تکیه بر اصول Keep it simple و با معماری تدریجی و طراحی پدیداری، سعی کند معماری و طراحی را از اول پیچیده در نظر نگیرد. به قول دوستان معمار، معمار خوب کسی است که تصمیم های مهم را به بعد موکول کند، یعنی اینکه با کسب دانش در طول پروژه بتواند تصمیم های درست تری بگیرد.

https://goo.gl/U4LLN0

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

تجربه کاربری یا UX یکی از مفاهیمی است که تاثیر زیادی در محبوب شدن یک محصول دارد. مفهوم DX یا Developer Experience نیز مفهوم جدیدی است که تجربه یک برنامه‌نویس هنگام استفاده از یک پلتفرم یا فریم‌ورک را بررسی می‌کند. چرا یک پلتفرم یا فریم‌ورک محبوب می‌شود و دیگری نه؟ این سوالی‌ است که عوامل زیادی در پاسخ دادن به آن موثر هستند. اینکه یک برنامه نویس هنگام کار با آن پلتفرم چه تجربه‌ای احساس می‌کند یکی از عوامل مهم موفقیت یک پلتفرم است. در مقاله زیر مفهوم جدیدی به نام Dotability‌ معرفی شده که می‌توان به وسیله آن کتابخانه‌ها و فریم‌ورک‌های مختلف را از لحاظ DX بررسی کرد.

http://mehrandvd.me/2016/05/31/developer-experience-dotability/
http://mehrandvd.me/2016/05/31/developer-experience-dotability/

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

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


___

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

اضافه کردن فیچر به نرم‌افزار غالبا ویژگی مثبتی به نظر می‌رسد. ولی وقتی تیمی دارید که قدرت بسیار بالایی دارد اضافه کردن فیچرها با سرعت خیلی زیاد خودش می‌تواند نکات منفی داشته باشد. وقتی قدرت اضافه کردن امکانات با سرعت زیاد دارید باید محتاط باشید که امکانات جدید راه‌حل‌هایی جدید برای یک مسئله حل شده نباشند. داشتن تیم قدرتمند این قدرت را به مدیران می‌دهد که بتوانند سریع ایده‌های ذهنی خود را پیاده‌سازی کنند. در این حین باید مراقب بود این امکانات با هم، همپوشانی نداشته باشند.
مثال زیر از تیم توسعه C# آورده شده‌است که در مورد کاربرد دو امکان این زبان که در نسخه‌های ۵ و ۶ اضافه شد صحبت می‌کند.

http://mehrandvd.me/2016/05/02/steady-consistent-flow-features/

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

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



___

تحقق یک رویا: پشتیبانی توکار از دات نت در همه مرورگرهای مدرن

به لطف استاندارد مدرن - و هنوز فراگیر نشده - WebAssembly، امروزه همه مرورگر های مدرن می توانند به جای اجرای جاوا اسکریپت، یک زبان bytecode استانداردِ سطح پایین و شبیه به زبان اسمبلی را اجرا کنند. استفاده از WebAssembly می تواند موجب اجرای سریع تر کد و کاهش حجم آن شود. اما مهمترین مزیت این هست که امروز می توانیم همه زبان های قدرتمند نظیر سی شارپ را به نحوی کامپایل کنیم که خروجیِ نهایی، منطیق با استاندارد webassembly باشد و به صورت native در مرورگرها دات نت را اجرا کنیم.

کامپایل سی شارپ به WebAssembly توسط تیم Mono مایکروسافت انجام شده و عمده مشکلات فنی سر راه برداشته شده اند. اما برای اینکه عملا بشود از دات نت در مرورگر ها استفاده کرد، مایکروسافت در پی پیاده سازی پروژه جاه طلبانه ای به نام Blazor می باشد. در واقع Blazor فریم ورک Client-Side مبتنی بر دات نت خواهد بود، الهام گرفته از فریم ورک های کنونی (مانند Angular و React) و رقیبی جدید برای آن ها. فریم ورک Blazor هم مانند آن ها حول مفهوم Component شکل گرفته است. کامپوننت هایی که کلاس های سی شارپی هستند و با زبان Razor توسعه داده شده اند.

استفاده از دات نت در مرورگر ها می تواند موجب این شود که کد بیشتری را بین سرور و کلاینت بتوانیم به اشتراک بگذاریم و نیاز به دوباره کاری در هر دو سمت نداشته باشیم. علاوه بر این توسعه دهندگان سی شارپ کمی بیشتر به مفهوم Full Stack Developer نزدیک خواهند شد.
همچنین با استفاده از WebAssembly می توانیم به تمام کتابخانه های موجود جاوااسکریپتی هم دسترسی داشته باشیم و محدودیتی در این زمینه وجود ندارد. همچنین می توان DOM را هم از این طریق مدیریت و دستکاری کرد.

در حال حاضر تیم AspNet عهده دار کار بر روی پروژه Blazor شده است. از نوشته های آن ها چنین بر می آید که تا نهایی شدن این پروژه هنوز باید صبر کنیم.

* گیت هاب Blazor:
https://github.com/aspnet/Blazor

* کمی فنی تر:
http://blog.stevensanderson.com/2018/02/06/blazor-intro/

* بلاگ تیم AspNet در رابطه با پروژه جدید Blazor:
https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-experimental-project/

*پادکست اسکات هنسلمن در مورد وب اسمبلی با یکی از توسعه دهنده گان فایرفاکس:
https://hanselminutes.com/581/inside-webassembly-with-mozilla-fellow-david-bryant

@irandotnet

روانشناسی شکل‌ها

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

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

مقاله امروز از استودیوی Tubik است که جمع بسیار خلاق و خوش سلیقه‌ای هستند و می‌توانند آن‌ها را در Instagram هم دنبال کنید.
این مقاله را از دست ندهید.

https://uxplanet.org/knock-design-into-shape-psychology-of-shapes-6e43c6e59955

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

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

___‌

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

چطور برنامه‌نویسی موازی را برای مادربزرگتان توضیح دهید!؟

برنامه نویسی موازی (Parallel Programming) و برنامه نویسی ناهمگام (Asynchronous Programming) مفاهیم نسبتا جدیدی در دنیای برنامه‌نویسی هستند که برای اغلب برنامه‌نویسان جدید است. همه در مورد آن شنیده‌انم ولی اغلب واضح نیست که دقیقا چیست و چرا سخت است. یک مفهوم پایه برای درک این مفاهیم پایه Thread یا نخ است. نخ‌ها مفاهیمی هستند که وظیفه انجام کارها روی CPU را دارند. در دنیای ما انسان‌ها کسانی هستند که کار انجام می‌دهند. مقاله زیر مفهوم «نخ» را به «انسان» شبیه دیده‌است و سعی کرده‌است مفاهیم پیچیده دنیای برنامه‌نویسی را با مفاهیم ساده‌ دنیای ما انسان‌ها توضیح دهد.

http://mehrandvd.me/2016/04/18/parallel-programming-grandmother/


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

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



___

برای "ما" لوکس و برای "آن ها" اساس

در اینجا بچه های لیسانس ملزم هستند که به عنوان پروژه پایانی درسی را تحت عنوان Capstone پاس کنند (در ایران ما باید یک پایاننامه آماده می کردیم!). در واقع موظف هستند تا یک پروژه واقعی را برای یک مشتری واقعی و معتبر انجام دهند. هر تیم موظف هست تا رضایت کامل مشتری را جلب کرده و محصول کاملی را عرضه کند. در پایان هم روزی به عنوان دموی پایانی محصولات مشخص خواهد شد که با حضور شرکت های معتبر و مسئولین دانشگاه خواهد بود.

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

* همه تیم ها بلااستثنا از بهترین ابزار ها و روش ها برای راه اندازی Continous Integration و Continious Deployment استفاده می کنند.
* همه تیم ها مجموعه بسیار خوب و دقیقی از تست های واحدِ با کیفیت و ایزوله را طراحی کرده اند که به صورت خودکار بر روی سرورهای بیلد شان اجرا می کنند.
* همه تیم ها زیرساخت های شان را بر روی سرور های کلاد آمازون، گوگل و یا مایکروسافت مستقر کرده اند و از سرویس های آن ها بهره می گیرند.
* از بهترین و مدرن ترین پلتفرم ها برای ثبت لاگ اپلیکیشن ها و سرور ها استفاده می کنند تا به صورت دقیق رفتار کاربر و سرور را تحت نظر داشته باشند.
* برای استقرار نرم افزار از Docker و Kubernetes استفاده می کنند.
* به کیفیت کد و نام گذاری ها به شدت اهمیت می دهند و تقریبا در همه آن ها استفاده از Dependency Injection و Dependency Inversion و تقسیم بندی سیستم به لایه های درست دیده می شود.
* هر کدی که تغییر پیدا می کند، دلیل مشخص دارد و به یکی از Issue ها مرتبط شده است. هیچ تغییری بدون دلیل و غیرمستند نیست.
* بسیار درست از Git برای مشارکت در کد استفاده می کنند. کسی مستقیم در Repository ها کدی را push نمی کند. هر کس موظف هست تا تغییرات را در غالب Pull Request ارسال کند تا دیگران (یک یا دو نفر) کد را Review کرده و نظرشان در مورد تغییراتی که باید انجام شوند اعلام کنند.
* با ارسال Pull Request ها، تست ها به صورت خودکار اجرا می شوند تا reviewer ها مطمئن شوند که تغییر موجب شکست سیستم نخواهد شد.

می دانم که این practice ها در خیلی از شرکت های اینجا هم به عنوان پایه و الفبا به کار گرفته می شوند. بسیاری از دانشجویان در دوران کارشناسی حتی تا 4 بار در شرکت های معتبر نظیر مایکروسافت دوره های Internship را گذرانده اند و به خوبی با استاندارد های صنعت و best practice ها آشنا هستند. کسی فکر نمی کند که "حالا بزن بره وقت هست واسه این چیزا"، اصولا اینها توسعه به روش ما را بلد نیستند.

⭕ درس آموخته‌های یک پروژه

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

✅ نکات بدیهی که دیر فهمیدیم:

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

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

💬 پیاده کردن محیط دوستانه همزمان با کار حرفه‌ای خیلی سخت‌تر از چیزیه که به نظر میاد. ولی ارزشمندترین کاری است که می‌شه در یک استارت‌آپ کرد.

💬 تمام اصول مانیفست اجایل ( و حتی اصول اخلاقی اسکرام مثل شفافیت) تزئینی نیستند. رعایت این‌ها حتی از پرداخت حقوق سر وقت هم مهم‌تره. و این اصول فقط برای برنامه‌نویس‌ها نیست. برای سازمانه.

💬 مهم نیست چه چارچوبی برای توسعه نرم‌افزار و تیم داریم. هر چیزی که بهتر می‌شه اجرا کرد باید انتخاب کرد و بعد از کسب تجربه، اگر نیاز بود، تغییرش داد.

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

💬 مواردی که ازشان به عنوان بهترین پرکتیس‌های تیم‌های نرم افزاری نام برده می‌شه، مخصوص تیم‌های خارجی و یا تیم‌های بیکار نیست. یک وظیفه اصلی تیم‌ها به خصوص تیم‌های پروداکت، ایجاد و توسعه دانش و سرویس برای استفاده داخلی خود تیم است.

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

https://goo.gl/vZr6Eb

@iranagile

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

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

http://mehrandvd.me/2016/03/28/linq-the-bad-parts/

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

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



___

پیغام خطای مزخرف «نام کاربری یا کلمه عبور شما اشتباه است.»

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

تا مدتی این دلیل برایم به اندازه کافی قانع‌کننده بود ولی بعدتر که بیشتر و بیشتر با این پیغام مواجه شدم، دیگر نتوانستم آن را قبول کنم و به عنوان کاربر برایم آزاردهنده بود.
در نهایت با سرویس Mailchimp آشنا شدم که از سال ۲۰۰۱ خدماتی را در حوزه خبرنامه ارائه می‌دهد. این سرویس تمام حق را به کاربر داده و حفاظت از اطلاعات آن‌ها را بطور کامل وظیفه خود دانسته است، لذا تمامی پیغام‌های خطایی که می‌دهد کاملا واضح و روشن هستند. دیدن سرویس Mailchimp به من این شجاعت را داد که سعی کنم در تمامی سرویس‌هایی که دیزاین می‌کنم، در کنار سود صاحبان سرویس، از حقوق کاربران نیز دفاع کنم.

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

https://hackernoon.com/username-or-password-is-incorrect-is-bullshit-89985ca2be48

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

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

___‌

قابلیت های جدید Entity Framework Core
* Connection Pooling *

بالاخره با انتشار نسخه نخست پیش نمایش EF Core 2.1 می توانیم بگوییم که نسخه Core کمبودهایی را که به نسبت آخرین نسخه نسل پیشین یعنی Entity Framework 6 داشت کاهش داده و حتی برطرف کرده است. فکر می کنم با انتشار نسخه نهایی EF Core 2.1 می توانیم کم کم در پروژه های عملیاتی از آن بهره بگیریم.

خوشبختانه اگر با نسخه های قبلی EF کار کرده باشید، از منظر API تفاوت چندانی نکرده و یادگیری چندان دشواری نخواهد داشت. می خواهم در پست هایی جداگانه قابلیت های جدید نسل Core را معرفی کنم که در نسخه گذشته وجود نداشته اند.

قابلیت Connection Pooling که در نسخه EF Core 2.0 معرفی شده است، می تواند در برنامه های وب کارایی برنامه شما را بی هیچ زحمتی، به مقدار قابل توجهی افزایش دهد. در بنچ مارک ساده ای که تیم EF Core منتشر کرده است، آن ها توانسته اند تا 20 درصد تعداد درخواست هایی را که می توانند پاسخ دهند افزایش دهند.

پیش از معرفی این قابلیت، برای هر درخواست جدید که به سرور می رسید ما می بایست یک DbContext جدید را می ساختیم (Instantiate) و پس از پایان درخواست هم می بایست که این DbContext را Dispose می کردیم تا منابع اش را آزاد کنیم. به این الگو One Context Per Request گفته می شد.

مشکل این روش آن می باشد که ساخت و Dispose برای نمونه های DbContext عملی سنگین و زمانگیر می باشد. برای حل این مشکل در EF Core 2.0 قابلیت جدیدی معرفی شد که به طور پیشفرض فهرستی (Pool) از DbContext های آماده به کار را پیش از شروع رسیدگی به اولین درخواست می سازد. سپس به ازای هر درخواست به جای ساخت DbContext جدید - که عملی زمانبر می باشد - از نمونه های موجود در Pool استفاده می کند و پس از پایان چرخه درخواست، DbContext به جای Dispose شدن به Pool بر می گردد تا برای درخواست دیگری استفاده شود. همه این فرایند خودکار و بدون دخالت شما صورت می گیرد.

استفاده از تکنیک و الگوی Connection Pooling یکی از روش های متداول برای استفاده حداکثری از منابع سیستم می باشد. در EF Core با پیاده سازی این تکنیک برنامه های ما فقط با تغییر یک خط کد می توانند تا حد خیلی بالایی افزایش کارایی را تجربه کنند.

* توضیحات و بنچ مارک:
https://neelbhatt.com/2018/02/27/use-dbcontextpooling-to-improve-the-performance-net-core-2-1-feature/

* بحثی در گیتهاب پیرامون مکانیزم کار این قابلیت:
https://github.com/aspnet/EntityFrameworkCore/issues/10125

@irandotnet

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

معماری جدید Migration در EF Core 1 اگر با Entity Framework Migrations کار کرده‌اید و با آن پروژه جدی انجام داده‌اید حتما در مواقعی نیاز داشته‌اید که بتوانید Snapshot دیتابیس بین دو Migration را مقایسه کنید. این کار در نسخه ۶ کار بسیار سختی بود زیرا این Snapshot در فایل Resource به ازای هر Migration ذخیره می‌شد. اتفاق خوبی که در نسخه ۷ افتاده این است که معماری آن عوض شده و ذخیره‌سازی به صورت کلاس‌هایی است که حتی از طریق کد هم می‌توانید به آن دسترسی داشته باشید.

لینک زیر این تغییر معماری رو توضیح می‌دهد تا بتوانید از آن در پروژه‌های آتی خود استفاده کنید.

http://mehrandvd.me/2016/02/18/entity-framework-core-migrations/

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


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


___

روزها نمی‌گذرند، ما آنها را می‌گذارنیم، ما آنها را خلق می‌کنیم، می‌سازیم.
سال قبل را با هم گذارندیم، خلق کردیم، ساختیم.
امیدوارم سال جدید را همانطور که می‌خواهید خلق کنید، تا آینده را با هم بسازیم...
سال نو مبارک.

مهران
http://mehrandvd.me