Iran .Net

تحقق یک رویا: پشتیبانی توکار از دات نت در همه مرورگرهای مدرن به لطف استاندارد مدرن - و هنوز فراگیر نشده - 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

چیزی که شرکت ها را ورشکست می کند، بدهی فنی است نه بدهی مالی اصطلاح بدهی فنی (Technical Debt) اساسا برای این به وجود آمد تا افراد حوزه بیزینس و مدیران را متوجه آسیبی کند که با فرامین نابجا، زمان بندی های تنگ و ترش و دید غیرواقعی و غیرمهندسی شان می توانند به نرم افزارها وارد کنند. از آنجایی که این دسته از افراد نسبت به بدهی مالی حساس هستند و درک بسیار خوبی از آن دارند، از عبارت بدهی فنی استفاده می کنیم تا بتوانیم حساسیت آن ها را جلب کنیم. برای توسعه نرم افزار و هر جزیی از آن، همواره دو راه پیش روی ماست. یکی توسعه ای تمیز و ساختارمند و اصولی و دیگری راه حل های کثیف و میانبر. مزیت روش دوم بر روش اول آن است که زمان توسعه به شدت کوتاه تر می شود و خیلی سریع تر می توانیم محصول را به بازار برسانیم. در صورتی که در پیش گرفتن روش دوم، زمان بیشتری برای توسعه نیاز خواهد داشت. مشکل آنجاست که افراد حوزه بیزینس عمدتا به چیزی جز رساندن سریع تر محصول به بازار فکر نمی کنند. آن ها نمی دانند که با در نظر گرفتن زمانبندی های کوتاه و تحت فشار قرار دادن برنامه نویس ها، اگر چه کارشان زودتر اماده می شود ولی زیر بار بدهی سنگینی رفته اند که اگر هرچه زودتر پرداخت نکنند، تمام کسب و کار و نیروی انسانی نخبه شان را از دست خواهند داد. آن ها با گرفتن وام ( کاهش زمان و تحت فشار قرار دادن توسعه دهندگان و کدهای کثیف و میانبر و ابهامات باقی مانده در کد) کارشان انجام شده ولی این وام باید با سود بسیار بالایی بازپرداخت شود. نکته آنجاست که هر چقدر این بدهی دیرتر پرداخت شود، نرخ بهره چندین برابر خواهد شد و در نهایت سازمان را به جایی می رساند که توان تکان خوردن و اصلاح و بازپرداخت نخواهد داشت. بازپرداخت بدهی فنی یعنی refactor کردن کد و تر و تمیز کردن نرم افزار و قطعا هر چه زمان بیشتری گذشته باشد، این امر به تدریج غیرممکن خواهد شد. در نتیجه دیگر در این کد نمی توان ویژگی ها را به سرعت اضافه کرد و هر تغییری منجر به شکست سایر نقاط خواهد شد و عواقب پیشبینی نشده خواهد داشت. کد به تدریج به کدی کهنه تبدیل می شود که از اصول و روش های مدرن فاصله خواهد گرفت. توسعه محصولی که به سرعت وارد بازار شده بود، به شدت کند خواهد شد و باگ هایش و سرویس دهی پایین اش سازمان را دچار بحران اعتبار در میان مشتریان اش خواهد کرد که بزرگ ترین آسیب می باشد. از سوی دیگر سازمان در تعامل با نیروهای برنامه نویس اش به مرور درمانده خواهد شد. آن ها با کدی کهنه و بد درگیر خواهند شد و اشتیاقی به ادامه کار نخواهند داشت. از دوستان و رقبای شان عقب خواهند افتاد، سازمان به دلیل کندی کارها و عدم پیشرفت مناسب از آن ها ناراضی است و هر کسی کار را به دوش دیگری می اندازد و دیگری را مقصر می دانند و به مرور کد بدتر و بدتر خواهد شد، کیفیت پایین می آید و برنامه نویس ها به دلیل نارضایتی از سازمان می روند و یا تنش بین آن ها ایجاد خواهد شد و در نهایت هم بیزینس ضربه سنگینی از این موضوع خواهد خورد. همه این ها هم به خاطر بدهی فنی ایی است که هیچگاه توسط مدیریت سازمان دیده و بازپرداخت نشده است.

نکته ای در رابطه با استفاده بهینه از 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

درون کمپانی های نرم افزاری چه می گذرد؟ یکی از تفاوت های فرهنگ "ما و آن ها" آنست که هر چقدر "ما" همه چیز را پنهان می کنیم و از اشتراک گذاری هراس داریم، "آن ها" تا می توانند سعی در به اشتراک گذاری داشته ها و دانسته ها و تجربیات دارند. آن هم تجربیات و دستاورد هایی که با هزینه های میلیون دلاری بدست آمده اند. برای همین پیشرفت می کنند و "ما" برای همین از دایره خودمان فراتر نمی رویم. در همین راستا عمده شرکت های مهم حوزه تکنولوژی وبلاگ های فنی و مهندسی ایی دارند که در آن چالش هایی که با آن ها درگیر بوده اند و راه حل های شان را به اشتراک می گذراند. مثلا گوگل چطور سیستم هایش را تست می کند، یوتیوب چطور می تواند چنین حجم بالایی را استریم کند، مایکروسافت چطور می تواند دوره های ریلیز محصولات مهم و بزرگش را به سه هفته کاهش دهد، معماری سیستم های این کمپانی ها چیست و برای داشتن کدی با کیفیت چه پرکتیس هایی را انجام می دهند. در زیر فهرست بلاگ های کمپانی های مهم است که من از آن ها مطلع هستم. اگر شما از بلاگ های کمپانی های دیگر، مخصوصا ایرانی مثل کافه بازار، آپارات، ویرگول، طرفداری و .... مطلع هستید، من رو در جریان بگذارید تا این فهرست به روزرسانی شود. توصیه می کنم در هر زمینه اگر می خواهید کار جدیدی در شرکت شروع کنید، در این بلاگ ها جستو کرده و تجربیات شان در زمینه ای که می خواهید مرور کنید. * بلاگ تست گوگل 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

یادگیری مفاهیم پایه یا تکنولوژی های جدید مطالعات متعددی نشان می دهند که درصد بالایی از برنامه نویس ها از سندرمی به نام Imposter رنج می برند که به سبب آن فرد احساس می کند نسبت به خیلی های دیگر دانش بسیار کمتری دارد، آنگونه که از خودش انتظار دارد به امور مختلف مسلط نیست و یا می ترسد از همکاران و دیگر برنامه نویسان عقب بیفتد. به همین خاطر فرد در درون حس اطمینان و اعتماد به خودش و رضایت از کارش را از دست خواهد داد. فرد زمان و انرژی ایی که باید برای زندگی شخصی، خانواده و دوستان تخصیص دهد، به یادگیری تکنولوژی های جدید و به روز می گذراند تا کمی حس درد و ترس درونی خود را التیام بخشد. در رشته ها و حوزه های دیگر کمتر می توان افرادی را مشاهده کرد که خارج از ساعات کاری هم با چنین شدتی درگیر رنج و زحمت یادگیری باشند و باقی چیز ها را قربانی کنند. علت وجود این سندروم می تواند این باشد که ما مدام خودمان را با افراد بسیار فعال و اثرگذار این حوزه که از قضا در فضای مجازی و وبلاگ ها بسیار فعال هستند مقایسه می کنیم و تصور می کنیم این ها موفقند و همه چیز دان. علت دیگر هم قطعا سرعت بالای پیچیده شدن دنیای توسعه، پدید آمدن فریم ورک ها و کتابخانه های جدید و منسوخ شدن قدیمی ها با نرخ بسیار بالا ست. با این حال به مطالب خیلی جالبی توسط اسکات هنسلمن و مَتیو جونز برخوردم که اتفاقا نشان می دهد، این بزرگان دنیا توسعه معتقدند شرط باقی ماندن در این حوزه، گذران وقت بی حد و اندازه برای یادگیری و کار شبانه روز نیست. اسکات هنسلمن معتقد است که یادگیری تکنولوژی هایی که به طور مستقیم با آن ها درگیر نیستید چیزی بیشتز از تباهی زمان نیست. چرا که همه تکنولوژی ها، هر چقدر هم جدید و خوب در آینده ای نه چندان دور منسوخ خواهند شد. هنسلمن معتقد است برنامه نویس خوب کسی است که توانایی حل مسئله و قدرت یادگیری موضوعات جدید را به وقت نیاز داشته باشد و نه کسی که همه چیز را از پیش می داند. این امر هم نیازمند این هست که بر مفاهیم بنیادین این صنعت تسلط داشته باشیم و بتوانیم کارکردها را تحلیل کنیم. * اسکات هنسلمن https://www.hanselman.com/blog/YouGotThisYouKnowTheFundamentalsYouAreALearnerPlusTheImpostersHandbook.aspx مَتیو جونز هم در مطلبی بیان می کند که همه کد ها حتی بهترین های آن ها در آینده ای نه چندان دور در سطل آشغال ریخته می شوند و با کدهای جدیدی جایگزین خواهند شد و یا حتی در بهترین حالت شما دیگر مسئولیت در قبال شان نخواهید داشت. اما همیشه خودتان، خانواده شما و دوستان تان و حسرت زمان هایی که به خاطر کدهای دورریختنی با آن ها نگذراندید با شما خواهد بود. مَتیو جونز در ادامه می گوید پس چیزی بدتر از آن نیست که خارج از ساعات کاری کار کنم و عمر را صرف کارها و یادگیری تکنولوژی های دور ریختنی کنم. * مَتیو جونز : همه کدها دورریختی اند https://exceptionnotfound.net/all-code-is-disposable-just-like-it-should-be/ * مَتیو جونز : من از 9 تا 5 کار می کنم | شما هم می توانید https://exceptionnotfound.net/i-am-a-9-to-5-developer-and-so-can-you/ * مطلبی در مورد سندروم Imposter و اینکه تحقیقات نشان می دهد برنامه نویسانی که مدام کار می کنند، دچار مشکلات روحی متعددتر و بازدهی پایین تری هستند. عاشق برنامه نویسی بودن به معنی هفته 100 ساعت کار کردن نیست. http://www.businessinsider.com/syndromes-drive-coders-crazy-2014-3 @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

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

اصولا معماری صحیح، تفکیک شده، تمیز و قابل مدیریت و قابل نگهداری مسائل و انتزاعاتی را وارد پروژه می کند که ممکن است تاثیری منفی در سرعت و کارایی (Performance) پروژه داشته باشد. چرا که معماری و چیدن لایه ها و ماژول ها و کلاس های مختلف و کوچک، متد های کوتاه و تک منطوره نیاز به تبادل اطلاعات در سیستم را زیاد خواهد کرد. مثلا برای کاری که در یک ساختار کثیف همه اش در یک متد و پشت سر هم انجام می شد، در یک معماری اصولی ممکن هست لازم به ساخت کلاس های متنوع و چرخش داده ها در بین متد های گوناگون داشته باشیم. این به معنی کاهش کارایی نرم افزار می باشد. اما نکته آنجاست که در مهندسی نرم افزار توصیه بر ساخت نرم افزارهایی است که قابل نگهداری و قابل توسعه باشند. ما نرم افزارهایی نیاز داریم که تیم مان بتواند به راحتی با آن ها کار کند و نه نرم افزارهایی که کار با آن ها به سختی خواندن کتیبه های هخامنشی باشد. در واقع قربانی کردن معماری، خوانایی و ماژولاریتیِ نرم افزار به بهانه افزایش کارایی می تواند منشایی شیطانی در طول عمر پروژه شود. یکی از ساده ترین مصداق های این موضوع انتخاب بین Entity Framework، ADO.NET و Dapper می باشد. همه ما می دانیم که قطعا Entity Framework از دیگر روش ها کارایی پایین تری خواهد داشت، حتی با به کار بستن ترفند های خاصِ خودش. پس انتخاب Entity Framework چه مزیتی خواهد داشت؟ در پاسخ به این سوال باید گفت که در پروژه های مهم از هیچ کدام از این روش ها به تنهایی استفاده نمی شود و پروژه باید ملغمه ای از این ها باشد. در مقاله ای که در این پست به شما معرفی می کنم، نگارنده پس از بررسی این سه فریم ورک عنوان می کند که ما تصمیم گرفتیم برای توسعه سریع تر، حفظ ساختارِ تمیز، افزایش خوانایی و مدیریت راحت تر تغییرات از Entity Framework استفاده کنیم و فقط در مواقع خاص و جاهایی که حس می کردیم با استفاده از Dapper به کاراییِ بسیار بسیار بهتری می رسیم، از Dapper استفاده کرده ایم. پس بیش از سرعت به ساختار نرم افزار اهمیت دهیم و پس از شکل گرفتن استخوان بندی نرم افزار با بررسی و انجام بنچ مارک مناطق کند و گلوگاه های اصلی را پیدا خواهیم کرد و تغییرشان خواهیم داد. در ضمن برای بالا بردن سرعت و کارایی نرم افزار می توان در تامین سخت افزارهای بهتر هزینه کرد. در صورتی که معماری ناثواب را به هیچ طریقی نمی توان ترمیم کرد. https://www.exceptionnotfound.net/dapper-vs-entity-framework-vs-ado-net-performance-benchmarking/

قابلیت Always Encrypted در SQL Server 2016 این ویژگی که در آخرین نسخه SQL Server 2016 پیاده سازی شده است، کمک می کند تا اطلاعات به صورت رمز شده در پایگاه داده قرار بگیرند. در نتیجه مثلا در سازمان ها بین کسانی که مالک داده هستند و کسانی که داده ها را مدیریت (dba ها) می کنند می توانیم تفاوت قائل شویم و مطمئن باشیم اطلاعات حساس مالی، شخضی، هویتی، تجاری و اسناد ... توسط افرادی که به پایگاه داده دسترسی دارند خوانده نخواهد شد. در این روش شما مشخص می کنید که چه ستون هایی از چه جداولی لازم است رمزنگاری شوند. پس از انجام رمزنگاری، داده ها به صورت رمز شده در دیتابیس قرار خواهند گرفت و خواندن شان غیر ممکن خواهد بود. در این روش، داده ها به صورت رمز شده به اپلیکیشن فرستاده می شوند و این مسئولیت درایورِ ارتباطیِ کلاینت می باشد که داده ها را به محض دریافت رمزگشایی کرده و به اپلیکیشن تحویل دهد. در واقع تنها سیستمی که کلاینت در آن مستقر هست می تواند داده ها را باز کند و نه دیتابیس. این روش رمزنگاری مستقل از لایه نرم افزار خواهد بود و نیازی به پیاده سازی روش های پیچیده و من درآوردی و ... در کد نخواهیم داشت. این روش علی رغم مزیت هایش دارای محدودیت هایی هم می باشد که مهم ترین شان به نظر من موارد زیر می باشند: 1. در حال حاضر قابلیت Replication را بر روی ستون های رمز شده نخواهیم داشت. 2. در مورد Index گذاری، Join و عملگرهای مقایسه ای دارای محدودیت هایی هستیم. در این روش دو نوع کلید به منظور انجام رمزنگاری ساخته خواهد شد، قطعا فهم مکانیزم کارکرد این کلید ها، مراقبت و نگهداری از آن ها برای حفظ امنیت داده ها ضروری است. در غیر این صورت هر کس با داشتن کلید ها می تواند داده ها را بخواند. این کلید ها باید بر روی هر سرور یا کامپیوتری که قرار هست نرم افزار بر روی آن ها قرار داده باشد، موجود باشد. نرم افزار با داشتن این کلید ها می تواند داده ها را رمز گشایی کند. 1. معرفی ویژگی Always Encrypted: https://msdn.microsoft.com/en-us/library/mt163865.aspx 2. تشریح کلید ها و نکاتی جهت نگهداری آن ها: https://msdn.microsoft.com/en-us/library/mt708953.aspx 3. مثالی عملی و ساده از کانفیگ دیتابیس، کلید ها و برنامه: http://www.databasejournal.com/features/mssql/exploration-of-sql-server-2016-always-encrypted-part-1.html 4. توضیح محدودیت ها: https://www.infoq.com/news/2015/06/SQL-Server-Always-Encrypted http://www.sqlchamp.com/2016/07/limitations-always-encrypted/337 @irandotnet

همانطور که مطلع هستید نسخه نهایی SQL Server 2016 منتشر شده است و در صورتی که در برنامه Visual Studio Dev Essentials عضو باشید می توانید به طور رایگان نسخه ای معادل با نسخه Enterprise را دریافت کنید. به این نسخه Developer Edition گفته می شود. یکی از قابلیت های جدید و جذاب این نسخه Temporal Table می باشد. این قابلیت کمک می کند که تمامی تغییراتی که در داده های یک جدول حادث می شود، در جدولی جداگانه به نام History Table ذخیره شود. در این جدول همچنین زمانِ تغییرات و مدت زمانی که یک داده Valid بوده است به طور خودکار ضبط می شوند. از این ویژگی می توانید به جهت Auditing و مانیتورینگ تغییرات استفاده کنید و یا به مدیران کمک کنیم که با تحلیل نحوه تغییرات داده ها در طول زمان تصمیم گیری های بهتری داشته باشند. 1. آشنایی با Temporal Tables https://msdn.microsoft.com/en-us/library/dn935015.aspx 2. نگاهی دقیق تر و آشنایی با محدودیت ها https://www.mssqltips.com/sqlservertip/3680/introduction-to-sql-server-2016-temporal-tables/ این ویژگی از لحاظ ماهوی به قابلیت Change Data Tracking یا CDC اشتراکاتی دارد. این قابلیت هم در پست های قبلی معرفی شده بود. @irandotnet

فرهنگ سیلو و جنگ قدرت در ساختار سازمانی، بخش های مختلف بر اساس عملکرد یا ماموریت از هم جدا می شوند، مثلا بخش انبار، IT، امنیت و … . واحدهای مختلف شرکت با هم کار می کنند، ولی بالاتر از کار یا خدمت به مشتری، جایگاه یا قدرت بخش مورد نظر اهمیت دارد. اصولا در این شرکت‌ها “ما و آنها” را زیاد می‌شنوید. “اونها همیشه کارشون رو درست انجام نمی دهند – ما همیشه معطل اونها هستیم – بخش نرم افزار بهتر از سخت افزار کار می کنه – بچه‌های بازاریابی چیزی حالیشون نیست و کلا بلد نیستند، این باید دست ما باشه نه اونها …” 📰 📝 🌐 http://blog.scrum.ir/2017/01/silo-culture/ @iranagile

چیزی که شرکت ها را ورشکست می کند، بدهی فنی است نه بدهی مالی اصطلاح بدهی فنی (Technical Debt) اساسا برای این به وجود آمد تا افراد حوزه بیزینس و مدیران را متوجه آسیبی کند که با فرامین نابجا، زمان بندی های تنگ و ترش و دید غیرواقعی و غیرمهندسی شان می توانند به نرم افزارها وارد کنند. از آنجایی که این دسته از افراد نسبت به بدهی مالی حساس هستند و درک بسیار خوبی از آن دارند، از عبارت بدهی فنی استفاده می کنیم تا بتوانیم حساسیت آن ها را جلب کنیم. برای توسعه نرم افزار و هر جزیی از آن، همواره دو راه پیش روی ماست. یکی توسعه ای تمیز و ساختارمند و اصولی و دیگری راه حل های کثیف و میانبر. مزیت روش دوم بر روش اول آن است که زمان توسعه به شدت کوتاه تر می شود و خیلی سریع تر می توانیم محصول را به بازار برسانیم. در صورتی که در پیش گرفتن روش دوم، زمان بیشتری برای توسعه نیاز خواهد داشت. مشکل آنجاست که افراد حوزه بیزینس عمدتا به چیزی جز رساندن سریع تر محصول به بازار فکر نمی کنند. آن ها نمی دانند که با در نظر گرفتن زمانبندی های کوتاه و تحت فشار قرار دادن برنامه نویس ها، اگر چه کارشان زودتر اماده می شود ولی زیر بار بدهی سنگینی رفته اند که اگر هرچه زودتر پرداخت نکنند، تمام کسب و کار و نیروی انسانی نخبه شان را از دست خواهند داد. آن ها با گرفتن وام ( کاهش زمان و تحت فشار قرار دادن توسعه دهندگان و کدهای کثیف و میانبر و ابهامات باقی مانده در کد) کارشان انجام شده ولی این وام باید با سود بسیار بالایی بازپرداخت شود. نکته آنجاست که هر چقدر این بدهی دیرتر پرداخت شود، نرخ بهره چندین برابر خواهد شد و در نهایت سازمان را به جایی می رساند که توان تکان خوردن و اصلاح و بازپرداخت نخواهد داشت. بازپرداخت بدهی فنی یعنی refactor کردن کد و تر و تمیز کردن نرم افزار و قطعا هر چه زمان بیشتری گذشته باشد، این امر به تدریج غیرممکن خواهد شد. در نتیجه دیگر در این کد نمی توان ویژگی ها را به سرعت اضافه کرد و هر تغییری منجر به شکست سایر نقاط خواهد شد و عواقب پیشبینی نشده خواهد داشت. کد به تدریج به کدی کهنه تبدیل می شود که از اصول و روش های مدرن فاصله خواهد گرفت. توسعه محصولی که به سرعت وارد بازار شده بود، به شدت کند خواهد شد و باگ هایش و سرویس دهی پایین اش سازمان را دچار بحران اعتبار در میان مشتریان اش خواهد کرد که بزرگ ترین آسیب می باشد. از سوی دیگر سازمان در تعامل با نیروهای برنامه نویس اش به مرور درمانده خواهد شد. آن ها با کدی کهنه و بد درگیر خواهند شد و اشتیاقی به ادامه کار نخواهند داشت. از دوستان و رقبای شان عقب خواهند افتاد، سازمان به دلیل کندی کارها و عدم پیشرفت مناسب از آن ها ناراضی است و هر کسی کار را به دوش دیگری می اندازد و دیگری را مقصر می دانند و به مرور کد بدتر و بدتر خواهد شد، کیفیت پایین می آید و برنامه نویس ها به دلیل نارضایتی از سازمان می روند و یا تنش بین آن ها ایجاد خواهد شد و در نهایت هم بیزینس ضربه سنگینی از این موضوع خواهد خورد. همه این ها هم به خاطر بدهی فنی ایی است که هیچگاه توسط مدیریت سازمان دیده و بازپرداخت نشده است.

جنبش Agile و جامعه ای که حول و حوش آن شکل گرفته است، کمتر به مسائل "فنی و هنر توسعه نرم افزار" اهمیت می دهند. عمده مباحث و مطالب مربوط به این حوزه توسط Scrum Master ها و Business Man ها تولید شده و به پیش برده می شود. مطالب مربوط به Agile سرشار شده است از نحوه مدیریت تیم ها، نحوه اولویت بندی کار ها و مدیریت هزینه و زمان و شرح و بسط Scrum و Kanban و Lean ..... اما جای مسائل فنی در این بین کجاست؟ آقای رابرت مارتین، معروف به Uncle Bob، از نویسندگان مانیفست Agile و بزرگان عرصه نرم افزار و همچنین Martin Fowler معتقد اند که متاسفانه بُعد Business ایی Agile به شدت نسبت به بُعد "فنی نرم افزار" قوی تر شده است و این خطری است که این جنبش را تهدید می کند. به همین خاطر مانیفست جدیدی به نام Manifesto for Software Craftsmanship تهیه شده که می خواهد روی دیگری از سکه توسعه نرم افزار را پررنگ کند. مارتین فاولر معتقد است که برنامه نویس قدرتمند کسی است که نه تنها در توسعه نرم افزار استاد است، بلکه اشتیاق بسیار زیادی به ارتباط با مشتری و فهم مشکلات و مسائل او دارد و می خواهد به بهترین نحو نیاز و مشکل مشتری را برطرف کند. 1. مانیفست: http://manifesto.softwarecraftsmanship.org/#/en 2. مصاحبه کوتاه با Uncle Bob در همین مورد: http://techbeacon.com/uncle-bob-martin-agile-manifesto-15-years-later 3. نوشته ای شیوا از استاد Fowler در همین مورد: http://martinfowler.com/bliki/CraftmanshipAndTheCrevasse.html

گمان می کنی که آن استاد چیره دست هیچ کاری انجام نمی دهد، اما او هیچ کار ناتمامی بر روی میزش نمانده. با این حال آن آدم معمولی که به نظر می رسد مدام مشغول انجام کارهاست، هیچ وقت کارهایش تمام نمی شود.

در مورد فرهنگ سازمانی، توسعه چابک و با کیفیت، ایجاد کشش های قوی بین تیم توسعه، سازمان و مشتری حرف های خوب و قشنگی می شود زد و با آن ها شعار داد. ما هم که مملکت شاعر مسلک و شعار زده ای هستیم و مستعد! محیط کار و تمام اجزای تشکیل دهنده آن به نوعی نشان دهنده فرهنگ سازمانی حاکم می تواند باشد. از میز ها و محل کار کارکنان، فاصله فیزیکی کارکنان و تیم ها، فاصله طبقات و اتاق های مدیریت با واحد های دیگر گرفته تا وسایلی که در محیط قرار گرفته تا به نوعی چیدمان ساختمان را شکل دهند، همه و همه نشات گرفته از فرهنگ سازمانی هستند البته فرهنگ سازمانی هم از ساختار فیزیکی و اجزای فیزیکی ساختمان و محیط کار تاثیر خواهد پذیرفت. اینکه چگونه چابک شویم، چگونه محیط کاری فراهم کنیم تا رضایت حداکثری کارکنان مان را جذب کنیم و بتوانیم با ایجاد حب و علاقه در کارکنان، فرهنگی را به وجود بیاوریم که همه سازمان به گونه ای یکپارچه خود را بپندارد و اهداف سازمان همان اهداف نفرات شود، کار دشواری است. مایکروسافت از معدود شرکت هایی است که چابکی یا Agility در سطح Enterprise پیاده سازی کرده است و معتقد است برای دستیابی به این اهداف، یکی از ضروریات معماری داخلی ساختمان و اجزا و امکانات موجود در محیط می باشد. در ساختمان های 16 و 17 مقر Redmond که تیم های Cloud و Enterprise مایکروسافت قرار گرفته اند، معماری به غایت مدرنی به کار گرفته شده که می توانید تصاویر و توضیحات و چرایی ها را در مطلب زیر ببینید. دقت کنید که در محیط کار مدرن مایکروسافت، یکی از اهداف سرعت در گردش اطلاعات و همکاری حداکثری می باشد. به همین خاطر محیط کار آن ها Office Free یا بدون اتاق می باشد و تیم های مختلف در محیط های بزرگی به نام "همسایگی و Neigboorhoods" در کنار هم قرار گرفته اند. همچنین مدیران و کارکنان تفاوتی در امکانات و فاصله فیزیکیِ محلِ کارشان با سایرین ندارند و همه کنار هم کار می کنند. http://news.microsoft.com/stories/b16/

"به خومان اهمیت بدهیم" کسانی که در حوزه توسعه نرم افزار کار می کنند عموما از سبک زندگی مناسبی برخوردار نیستند. فشار کاری زیاد، انتظارات بالای سایرین از ما، رقابت شدید، نیاز به یادگیری مداوم و به روز ماندن، ساعت ها خیره شدن به مانیتور و فعالیت فیزیکی بسیار پایین، عدم تعامل موثر با سایرین و ... از ویژگی های "حرفه" ماست. این ها در کنار مشکلات جدی تر زندگی مانند مسائل مالی، رابطه و دغدغه های زندگی بسیار سنگین تر هم خواهند شد. اسکات هنسلمن در وبلاگ اش راهکار هایی را که خودش برای حل این مسائل به کار بسته را به اشتراک گذاشته است. http://www.hanselman.com/blog/SelfcareMattersPayYourselfFirst.aspx

پیاده سازیِ سیاست دسترسی به داده ها توسط ویژگی RLS در SQL Server 2016 در بسیاری موارد (مانند سیستم های Multi Tenant) لازم هست تا مانع از این شویم که داده های کاربران با هم تداخل پیدا کند و یا آن ها بتوانند به داده های هم دسترسی داشته باشند. مثلا می خواهیم کاربران هر شعبه از سازمان، تنها به اطلاعات شعبه خودشان دسترسی داشته باشند. یک کار ساده، پردردسر و بسیار بد آن است که از برنامه نویس ها بخواهیم در هر کوئری عبارتی را اضافه کنند که سطح دسترسی را چک کند. اما اگر برنامه نویس جایی فراموش کرد چی؟ اگر سیاست دسترسی پیچیده تر بود و مبنی بر پارامتر های مختلف محاسبه می شد چه خواهد شد؟ این راهکار در حجم بزرگ غیر مطمئن و غیرقابل نگهداری است. در EF6 قابلیتی به نام Interception وجود دارد که با استفاده از آن می توان سیاست دسترسی به داده را در لایه های پایینی طراحی کرد. در این روش برنامه نویس لایه هایی بالا، بدون آنکه درگیر مفاهیمی مانند Tenant و سیاست ها بشود، می تواند به راحتی کوئری هایش را تولید کند. سپس EF به طور خودکار تغییری در کوئری ها خواهد داد تا دسترسی های لازم رعایت کرده باشد. برای اینکار می توانید از کتابخانه EntityFramework.DynamicFilters استفاده کنید. این روش هم علی رغم همه مزایا معایبی هم دارد. اگر بخواهیم از همین پایگاه داده استفاده کنیم ولی در محیط دات نت نباشیم و یا از EF6 استفاده نکنیم، دوباره مشکلات اغاز می شوند. سیاست ها را باید در همه جا کپی کنیم و در صورت لزوم هم، مجددا همه را تغییر دهیم. در SQL Server 2016 قابلیتی به نام Row Level Security وجود دارد، که به ما اجازه می دهد سیاست های دسترسی با داده را در لایه پایگاه داده متمرکز کنیم. در این صورت اپلیکشن ها هیچگونه آگاهی ایی نسبت به سیاست ها نخواهند داشت و درگیر این مفاهیم در سطح کد نخواهیم بود. همچنین در صورت لزوم به تغییر سیاست ها، فقط لازم است تغییراتی را در پایگاه داده بدهیم. با این روش، به هر طریقی و از هر ابزاری که به پایگاه داده کوئری هایمان را ارسال کنیم، سیاست های دسترسی به داده اعمال خواهند شد و امنیت بالا و البته ریزدانه ای (granular) را خواهیم داشت. در مثال زیر خواهیم دید که چگونه می توان با استفاده از EF6 از ویژگی RLS بهره برد. این مثال یکی دیگر از کاربرد های Interception را نیز توضیح می دهد. https://azure.microsoft.com/en-us/documentation/articles/web-sites-dotnet-entity-framework-row-level-security/

کد ها هم بو می دهند!!! در هستی "بو" می تواند حسی خوشایند و یا نامطبوع در آدم ایجاد کند. عموم بوهای بد نشانه ای بر حضور و وجود امری ناخوشایند و اساسی تر اند که نیاز به اصلاح و رفع مشکل خواهند داشت. در کتاب Refactoring مارتین فاولر برای نخستین بار از متافور و تشبیهی به نام Code Smell و یا "بوی کد" استفاده می کند. او معتقد است اگر شامه های مان را تقویت کنیم، می توانیم به سرعت نشانه هایی را در کد ببینیم که خبر از مسائل ناخوشایندی در کلیت کد به ما می دهند. اگر این نشانه ها را بشناسیم، خواهیم دید که حضور آن ها در هر کدی می تواند دلیل و خبرآورِ وجود مشکلاتی اساسی در آن کد باشد. مارتین فاولر موارد بسیار متعددی را تحت عنوان Code Smell شناسایی کرده و برای رفع آن ها پیشنهاداتی در کتاب اش ارائه کرده است. مزیت Code Smell ها آن است که شناسایی و یادگیریِ آن ها از پس هر کسی که مقداری تجربه داشته باشد، برخواهد آمد. نکته مهم در فهم Smell ها آن است که مشکل Smell ها نیستند، بلکه آن ها تنها نشانه هایی بر وجود مشکلات اساسی تر در سطح کد هستند و چه بسا در حین اصلاح یکی از آن ها به موارد متعدد دیگری هم برخواهیم خورد. این بوهای ناخوشایند می توانند شامل نامگذاری های غیر استاندارد و ناهمخوان و غیریکدست، متد های طولانی، متد هایی با وروردی های زیاد، کد های تکراری و مشابه و یا متد هایی که با وجود شباهت های زیاد تنها در موارد بسیار کوچکی با هم تفاوت دارند، کلاس های بزرگ، کلاس های متعددی که به هم شبیه هستند، عدم استفاده صحیح از وراثت، تعامل بیش از حد دو یا چند کلاس با هم و حتی حضور کامنت ها باشد. نوشته کوتاه مارتین فاولر در مورد Code Smell: https://martinfowler.com/bliki/CodeSmell.html نوشته جف اتوود، خالق Stackoverflow در مورد مصادیق Code Smell: https://blog.codinghorror.com/code-smells/ مصادیقی دیگر از Code Smell ها: https://sourcemaking.com/refactoring/smells @irandotnet

چرا از متد های async نمی توانیم در بدنه lock استفاده کنیم؟ دیگر عادت کرده ایم برای بالا بردن بهره وری سیستم هایمان از قابلیت await/async استفاده کنیم. استفاده از این ویژگی برای برخی به حدی عادی شده است که فراموش کرده ایم که در گذشته برای پیاده سازی ویژگی های Asynchronous چه مصیبت هایی را به جان می خریدیم و چه کد کثیفی تولید می کردیم. به هر حال، اگر برای شما پیش آمده باشد که از این متد ها درون بدنه عبارت lock استفاده کنید، با پیغام خطایی از سمت کامپایلر رو به رو خواهید شد. حتی اگر به طریقی کامپایلر متوجه قرار گرفتن متد async در بدنه lock نشود، در زمانِ اجرا با خطا رو به رو خواهیم شد. علت بروز این خطا چیست؟ موضوع به مبحثی تحت عنوان thread affinity مربوط می شود. در مسئله ما، این موضوع یعنی اینکه هر thread ایی که وارد بدنه lock شده است، همان thread هم فقط اجازه خروج از بدنه lock را خواهد داشت. در متد های async، نکته حائز اهمیت آن می باشد که بدنه متد تا قبل از رسیدن به کلمه await، توسط یک thread اجرا می شود و پس از اجرای دستور await توسط thread دیگری (به احتمال خیلی زیاد) اجرا خواهد شد. این ویژگی عاملی مهمی در بالا رفتن کارایی برنامه ها (مخصوصا در پلتفرم وب) خواهد بود. اما به هر حال در مسئله ما بدین معنی است که : 1. Thread-A وارد lock خواهد شد. 2. Thread-A دستور await را اجرا کرده و اجرای دستور را به Thread-B واگذار می کند تا به صورت asynchronous فعالیت انجام شود. 3. پس از اتمام کار Thread-B، روند اجرای برنامه به دستورِ پس از await خواهد رسید. ولی این بار Thread-C فرمانِ اجرای کد را بر عهده خواهد داشت. 4. چون thread ایی که وارد بدنه lock شده است با thread ایی که می خواهد از آن خارج شود، متفاوت است، با خطا رو به رو خواهیم شد. * در دات نت ابزارهای Synchronization ایی نظیر Monitor، Mutex و ReaderWriterLock دارای Thread Affinity می باشند. پس در حیطه کنترل این ها نمی توانیم از async استفاده کنیم. * عبارت lock، در پس پرده از Monitor برای مدیریت همزمانی Thread ها استفاده می کند. به همین خاطر است که در بدنه lock نمی توانیم از متد های async استفاده کنیم. * اما ابزارهای Semaphore و SemaphoreSlim دچار این مشکل نمی باشند و لازم نیست Thread ایی که وارد منطقه بحرانی می شود، همان Thread ایی باشد که از آن خارج می شود. https://blog.cdemi.io/async-waiting-inside-c-sharp-locks/ https://msdn.microsoft.com/en-us/library/ms228964(v=vs.110).aspx @irandotnet

اصل پیشاهنگی یا The Boy Scout Principle این اصل، از یک اصلِ فلسفی بریتانیایی برداشت شده است: "سعی کنیم جهان را - به نسبت آنچه که پیش تر یافته ایم - جای بهتری کنیم". در کتاب خواندنی "97 نکته ای که هر برنامه نویس باید بداند"، Uncle Bob با استفاده از این اصل، اصلی دیگر را در حوزه نرم افزار بیان می کند: "هر بار کدی را دیدیم، به نسبت قبل آن را بهتر کنیم." در این میان مهم نیست که کدام یک از اعضای تیم قبلا این کد را زده و یا مقدار بهبود چه حد کوچک باشد. این بهبود می تواند به کوچکی تغییر نام متغیر ها، کم کردن تکرار (duplication) ، کوتاه کردن یک متد طولانی و خواناتر کردن کد و ... باشد. در جهان، همه هستی (اعم از نرم افزار) به طور طبیعی به ویرانی و آشوب و فرسودگی میل می کند و برای جلوگیری از این امر ما باید انرژی مصرف کنیم و تعهد داشته باشیم. در نرم افزار هم وقتی همه اعضای تیم به این اصل متعهد باشند، ساختار کد به جای هرز رفتن در گذر زمان، روز به روز و به تدریج بهتر خواهد شد. همانطور که آشغال ریختن در طبیعت، عملی خلاف شعور و فرهنگ می باشد، این اصل بیان می کند که اصلاح نکردن کد در صورت مشاهده ایراد و ضعف به همان میزان دور از فرهنگ و تعهد و حرفه ای گری است. قرار نیست فقط به کد های خودمان اهمیت بدهیم و نسبت به آن ها حساس باشیم. هر کدام از اعضای تیم باید نسبت به کیفیت کار کل تیم حساس بوده و سعی در بهبود داشته باشند. 1. یادداشت عمو باب در مورد اصل پیشاهنگی http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule 2. در مقاله "ریفکتورینگ فرصت طلبانه"، مارتین فاولر توضیح می دهد که چطور علی رغم وجود دوره هایی برای اصلاح ساختاری سیستم، باید تیم همواره و هر جا و هر زمانی نسبت به ریفکتورینگ و اصلاح کد تعهد داشته باشد. در اینجا فاولر فرصت های متعددی را که در حین کار با کد های سیستم پیش می آید، مطرح می کند و هر کدام را به عنوان فرصتی برای ریفکتورینگ مغتنم می شمارد. فاولر معتقد است ریفکتورینگ یک امر و اصل همیشگی و جاری در سیستم باید باشد.اگر با تیمی مواجه هستیم که همیشه برای اصلاح کد ها نیاز به برنامه ریزی و جلسات متعدد دارد، یک جای کار می لنگد!. https://martinfowler.com/bliki/OpportunisticRefactoring.html