https://virgool.io/feed/@Mirsaeedi fa 2026-04-15 10:42:28 https://files.virgool.io/upload/users/2722/avatar/AJn954.jpg?height=120&width=120 https://virgool.io/@Mirsaeedi https://virgool.io/@Mirsaeedi/%D8%B3%D9%88%D8%A7%D9%84-%D9%87%D8%A7%DB%8C%DB%8C-%D8%AF%D8%B1-%D9%85%D9%88%D8%B1%D8%AF-%D8%B4%DB%8C-%DA%AF%D8%B1%D8%A7%DB%8C%DB%8C-%D8%AF%D8%B1-%D8%B3%DB%8C-%D8%B4%D8%A7%D8%B1%D9%BE-mxmnmcj1aro7 1. فیلد f را به صورت static و public در کلاس A تعریف کرده ایم. کلاس های B و C از کلاس A به ارث برده شده اند. آیا فیلد f به ازای کلاس های B و C، کپیِ مجزایی را خواهد داشت؟ در مورد کلاس های جنریک چطور؟پاسخ: https://stackoverflow.com/questions/5851497/static-fields-in-a-base-class-and-derived-classes2. زمان اجرای constructor های static چه وقت می باشد؟پاسخ:https://stackoverflow.com/questions/1437352/when-is-a-static-constructor-called-in-c3. چطور می توانیم، متدی تک پارامتری را تعریف کنیم که هر نوع ورودی ایی را بتواند بپذیرد و نوع پارامترِ متد از نوع object و یا dynamic نباشد.پاسخ: https://stackoverflow.com/questions/5886875/let-method-take-any-data-type-in-c-sharp4. در دو کلاس A و B، متد M با نام و امضای یکسان تعریف شده است. این دو کلاس به طور کلی مجزا می باشند و از کلاس واحدی به ارث نرفته اند. چطور می توانیم در کلاس C متدی تعریف کنیم که با گرفتن یک نمونه از کلاس A و یا B، متد M را صدا بزند با این فرض که متدی که تعریف می کنیم فقط یک پارامتر دریافت کند و درون متد هم هیچ نوع Cast ایی صورت نگیرد. (Duck Typing)پاسخ:https://stackoverflow.com/questions/21278078/what-is-interface-duck-typing5. چرا متد هایی که در یک کلاس virtual تعریف شده اند، نباید یکدیگر را صدا بزنند؟پاسخ: وقتی متدی، متد دیگری را صدا می زند، یعنی متدِ اولی به متدِ دومی وابسته است. مشکل اینجاست که این وابستگی در پیاده سازی پنهان شده و قابل رویت نیست. در نتیجه اگر کسی در کلاسی که ارث بری شده، متد اول را override کند، هیچ گاه نخواهد فهمید که باید متدِ دوم را صدا بزند. در نتیجه در پیاده سازی جدید، بعد از صدا زدن متدِ اول در کلاس پیاده سازی شده، سیستم در وضعیت پایدار نخواهد بود.6. کلاس PersonManager متدی تک پارامتری virtual به نام Manage دارد که یک Person را دریافت می کند. کلاس های EmployeeManager و StudentManager را چگونه از کلاس PersonManager ارث بری کنیم، که متد به ارث برده شده و override شده Manage در آن ها به جای پارامتر Person، نوع متناظر Employee و یا Student را دریافت کند.پاسخ: https://stackoverflow.com/questions/12593082/c-sharp-override-method-with-subclass-parameter7. چرا متد های virtual نباید در constructor صدا زده شوند؟پاسخ:https://stackoverflow.com/questions/119506/virtual-member-call-in-a-constructor احسان میرسعیدی احسان میرسعیدی Sun, 13 Jan 2019 12:53:25 +0330 https://virgool.io/@Mirsaeedi/%D9%82%D8%A7%D8%A8%D9%84%DB%8C%D8%AA-%D9%87%D8%A7%DB%8C-%D8%AC%D8%AF%DB%8C%D8%AF-entity-framework-core-pooling-hzbgxulh9s3r بالاخره با انتشار نسخه نخست پیش نمایش 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 احسان میرسعیدی احسان میرسعیدی Sun, 13 Jan 2019 12:49:35 +0330 https://virgool.io/@Mirsaeedi/%D8%AA%D8%AD%D9%82%D9%82-%DB%8C%DA%A9-%D8%B1%D9%88%DB%8C%D8%A7-%D9%BE%D8%B4%D8%AA%DB%8C%D8%A8%D8%A7%D9%86%DB%8C-%D8%A7%D8%B2-%D8%AF%D8%A7%D8%AA-%D9%86%D8%AA-%D8%AF%D8%B1-%D9%85%D8%B1%D9%88%D8%B1%DA%AF%D8%B1%D9%87%D8%A7%DB%8C-%D9%85%D8%AF%D8%B1%D9%86-cx4kctqmc7pu به لطف استاندارد مدرن - و هنوز فراگیر نشده - 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 احسان میرسعیدی احسان میرسعیدی Sun, 13 Jan 2019 12:43:40 +0330 https://virgool.io/@Mirsaeedi/%D8%A8%D8%B1%D8%A7%DB%8C-%D9%85%D8%A7-%D9%84%D9%88%DA%A9%D8%B3-%D9%88-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%A2%D9%86-%D9%87%D8%A7-%D8%A7%D8%B3%D8%A7%D8%B3-segjffnkivac در اینجا بچه های لیسانس ملزم هستند که به عنوان پروژه پایانی درسی را تحت عنوان 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 ها آشنا هستند. کسی فکر نمی کند که "حالا بزن بره وقت هست واسه این چیزا"، اصولا اینها توسعه به روش ما را بلد نیستند. احسان میرسعیدی احسان میرسعیدی Sun, 13 Jan 2019 12:35:04 +0330 https://virgool.io/@Mirsaeedi/%D9%86%DA%A9%D8%AA%D9%87-%D8%A7%DB%8C-%D8%AF%D8%B1-%D8%B1%D8%A7%D8%A8%D8%B7%D9%87-%D8%A8%D8%A7-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D8%A8%D9%87%DB%8C%D9%86%D9%87-%D8%A7%D8%B2-httpclient-xl16wnnvgeqr در بسیاری از موارد نیاز هست تا یک سیستم با سیستمی دیگر ارتباط برقرار کند. با فراگیر شدن وب سرویس های مبتنی بر HTTP، عمده سیستم ها با استفاده از پروتکل HTTP با یکدیگر ارتباط برقرار می کنند. این ارتباط می تواند با سرویس های داخلی سازمان، بانک، سرویس دهنده پیامک و ایمیل و یا سرویس های داخلی یک سیستم مبتنی بر Microservice و غیره باشد.در مواردی که از HttpClient برای ارسال درخواست ها استفاده می کنیم، باید این نکته را به خاطر داشته باشیم که تنها و تنها یک نمونه از HttpClient در برنامه داشته باشیم و در همه موارد از همین یک نمونه استفاده کنیم. این یک نمونه می تواند توسط الگوی Singleton که پیشتر توضیح داده شده بود، ایجاد شود.در مقابل اگر به ازای هر بار نیاز بخواهیم HttpClient جدیدی را در برنامه ایجاد کنیم، منابع زیادی را مصرف کرده و کارایی برنامه را در تعداد درخواست های بالا به شدت کاهش خواهیم داد. چرا که عملیات ایجاد یک HttpClient جدید بسیار پر هزینه بوده و علاوه بر آن، با هر نمونه سازی از HttpClient منابع Socket سیستم عامل را به طرز غیربهینه ای هدر داده ایم. در نتیجه در تعداد درخواست های بالا، دیگر منابع کافی نخواهیم داشت و با خطا مواجه خواهیم شد.کلاس HttpClient از اساس Thread-safe طراحی شده است. یعنی می توان با داشتن یک نمونه از آن، همزمان در thread های مختلف - درخواست های مختلف کاربران در یک وب اپلیکیشن - از همان یک نمونه استفاده کرد و کار هیچ Thread ایی بر دیگری اثر نخواهد گذاشت. * تجربه تلخ از عدم استفاده صحیح از HttpClienthttps://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 کلاس HttpClienthttp://www.michaeltaylorp3.net/httpclient-is-it-really-thread-safe/ احسان میرسعیدی احسان میرسعیدی Sun, 13 Jan 2019 12:31:15 +0330 https://virgool.io/@Mirsaeedi/%D8%AF%D8%B1%D9%88%D9%86-%DA%A9%D9%85%D9%BE%D8%A7%D9%86%DB%8C-%D9%87%D8%A7%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1%DB%8C-%DA%86%D9%87-%D9%85%DB%8C-%DA%AF%D8%B0%D8%B1%D8%AF-ek0e5wkx6cnc یکی از تفاوت های فرهنگ "ما و آن ها" آنست که هر چقدر "ما" همه چیز را پنهان می کنیم و از اشتراک گذاری هراس داریم، "آن ها" تا می توانند سعی در به اشتراک گذاری داشته ها و دانسته ها و تجربیات دارند. آن هم تجربیات و دستاورد هایی که با هزینه های میلیون دلاری بدست آمده اند. برای همین پیشرفت می کنند و "ما" برای همین از دایره خودمان فراتر نمی رویم.در همین راستا عمده شرکت های مهم حوزه تکنولوژی وبلاگ های فنی و مهندسی ایی دارند که در آن چالش هایی که با آن ها درگیر بوده اند و راه حل های شان را به اشتراک می گذراند. مثلا گوگل چطور سیستم هایش را تست می کند، یوتیوب چطور می تواند چنین حجم بالایی را استریم کند، مایکروسافت چطور می تواند دوره های ریلیز محصولات مهم و بزرگش را به سه هفته کاهش دهد، معماری سیستم های این کمپانی ها چیست و برای داشتن کدی با کیفیت چه پرکتیس هایی را انجام می دهند.در زیر فهرست بلاگ های کمپانی های مهم است که من از آن ها مطلع هستم. اگر شما از بلاگ های کمپانی های دیگر، مخصوصا ایرانی مثل کافه بازار، آپارات، ویرگول، طرفداری و .... مطلع هستید، من رو در جریان بگذارید تا این فهرست به روزرسانی شود. توصیه می کنم در هر زمینه اگر می خواهید کار جدیدی در شرکت شروع کنید، در این بلاگ ها جستو کرده و تجربیات شان در زمینه ای که می خواهید مرور کنید.* بلاگ تست گوگل 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/* بلاگ فنی مایکروسافت DevOpshttps://blogs.msdn.microsoft.com/devops/* بلاگ فنی فیس بوکhttps://research.fb.com/blog/(این فهرست به روز خواهد شد) احسان میرسعیدی احسان میرسعیدی Sat, 12 Jan 2019 14:37:02 +0330 https://virgool.io/@Mirsaeedi/%DB%8C%D8%A7%D8%AF%DA%AF%DB%8C%D8%B1%DB%8C-%D9%85%D9%81%D8%A7%D9%87%DB%8C%D9%85-%D9%BE%D8%A7%DB%8C%D9%87-%DB%8C%D8%A7-%D8%AA%DA%A9%D9%86%D9%88%D9%84%D9%88%DA%98%DB%8C-%D9%87%D8%A7%DB%8C-%D8%AC%D8%AF%DB%8C%D8%AF-qdtkzroz10on مطالعات متعددی نشان می دهند که درصد بالایی از برنامه نویس ها از سندرمی به نام 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 احسان میرسعیدی احسان میرسعیدی Sat, 12 Jan 2019 14:34:09 +0330 https://virgool.io/@Mirsaeedi/%DB%8C%DA%A9%D9%BE%D8%A7%D8%B1%DA%86%D9%87-%D8%B3%D8%A7%D8%B2%DB%8C-%D9%84%D8%A7%DA%AF-%D9%87%D8%A7-bqyrzo5omuo8 با نگاه به میزان حضور و کیفیت و جزییات لاگ ها در یک سیستم می توان براحتی فهمید که تیم توسعه دهنده تا چه حد به کیفیت و پایداری سیستم تعهد دارند. فراتر از آن لاگ ها یکی از معدود ابزار های تیم عملیات در تحلیل کارکرد سیستم و حل و بررسی مشکلات هستند. بدون لاگ های با کیفیت عملا سیستم و تیم عملیات یتیم و بی پناه هستند و راهی برای حل و حتی شناسایی رخداد مشکلات وجود ندارد. البته داشتن لاگ های با کیفیت و جامع بر خلاف تصور رایج، نیاز به مهارت، دقت و تعهد بالایی از سمت همه اعضای تیم توسعه و عملیات دارد.در قریب به اتفاق مواقع لاگ هایی که در سیستم ها وجود دارد، چیزی بیشتر از نوشتن یک جمله در فایل هایی که با تاریخ تفکیک می شوند نیست. ایراد این نوع از لاگ ها این است که:1. قابلیت جستجوهای پیشرفته، گزارش سازی و کوئری زدن بر روی آن ها وجود ندارد.2. در برنامه های پر ترافیک ثبت لاگ بر روی فایل ترافیک I/O زیادی را به سیستم تحمیل می کند.3. اگر سامانه متشکل از چند سیستم جدا از هم باشد، لاگ های پراکنده ای خواهیم داشت که هر کدام در یک محل جدا و غیریکپارچه قرار گرفته اند.4. برای خواندن لاگ ها نیاز به دسترسی به مستقیم به سرور خواهید داشت.برای حل مشکل یکپارچگی لاگ ها، خیلی از سیستم های پرترافیک از پلتفرمی به نام ELK استفاده می کنند. اما برای سیستم های کوچک تر و یا تیم هایی که در عین کیفیت از پیچیدگی فراری هستند، می توان از ابزار فوق العاده و البته رایگان SEQ استفاده کرد. این ابزار به شما امکان می دهد تا لاگ ها را از همه سیستم های تان یکجا جمع کنید، بدون نیاز به دسترسی مستقیم به سرور و با مرورگرتان لاگ ها را در یک پنل زیبا و کاربردی مشاهده کنید و با زبانی شبیه به SQL در میان لاگ ها جستجو کرده و گزارش و نمودار بسازید و از داشبورد به نسبت خوب و کاربردی بهره مند شوید. البته برای اینکه بتوانید در لاگ ها جستجوهای پیشرفته داشته باشید، باید لاگ های تان ساختارمند باشند. در قسمت بعدی راجع به لاگ های ساختارمند صحبت خواهیم کرد.لاگ یک امر فانتزی و یا صرفا مربوط به توسعه دهنده ها نیست. لاگ هم یک فیچر مهم از سیستم نرم افزاری است که می تواند در موفقیت و شکست یک سیستم نقش مستقیم ایفا کند. پس به لاگ ها اهمیت بدهیم.* ابزار SEQ توسط توسعه دهنده کتابخانه پرقدرت Autofac و Serilog توسعه داده شده است.* دانلود ابزار SEQhttps://getseq.net/Download*توضیحاتی در مورد SEQhttps://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 احسان میرسعیدی احسان میرسعیدی Fri, 11 Jan 2019 20:14:57 +0330 https://virgool.io/@Mirsaeedi/%D9%82%D8%A7%D8%A8%D9%84%DB%8C%D8%AA-always-encrypted-%D8%AF%D8%B1-sql-server-2016-gyvs3gyakfyq این ویژگی که در آخرین نسخه SQL Server 2016 پیاده سازی شده است، کمک می کند تا اطلاعات به صورت رمز شده در پایگاه داده قرار بگیرند. در نتیجه مثلا در سازمان ها بین کسانی که مالک داده هستند و کسانی که داده ها را مدیریت (dba ها) می کنند می توانیم تفاوت قائل شویم و مطمئن باشیم اطلاعات حساس مالی، شخضی، هویتی، تجاری و اسناد ... توسط افرادی که به پایگاه داده دسترسی دارند خوانده نخواهد شد.در این روش شما مشخص می کنید که چه ستون هایی از چه جداولی لازم است رمزنگاری شوند. پس از انجام رمزنگاری، داده ها به صورت رمز شده در دیتابیس قرار خواهند گرفت و خواندن شان غیر ممکن خواهد بود. در این روش، داده ها به صورت رمز شده به اپلیکیشن فرستاده می شوند و این مسئولیت درایورِ ارتباطیِ کلاینت می باشد که داده ها را به محض دریافت رمزگشایی کرده و به اپلیکیشن تحویل دهد. در واقع تنها سیستمی که کلاینت در آن مستقر هست می تواند داده ها را باز کند و نه دیتابیس.این روش رمزنگاری مستقل از لایه نرم افزار خواهد بود و نیازی به پیاده سازی روش های پیچیده و من درآوردی و ... در کد نخواهیم داشت.این روش علی رغم مزیت هایش دارای محدودیت هایی هم می باشد که مهم ترین شان به نظر من موارد زیر می باشند:1. در حال حاضر قابلیت Replication را بر روی ستون های رمز شده نخواهیم داشت.2. در مورد Index گذاری، Join و عملگرهای مقایسه ای دارای محدودیت هایی هستیم.در این روش دو نوع کلید به منظور انجام رمزنگاری ساخته خواهد شد، قطعا فهم مکانیزم کارکرد این کلید ها، مراقبت و نگهداری از آن ها برای حفظ امنیت داده ها ضروری است. در غیر این صورت هر کس با داشتن کلید ها می تواند داده ها را بخواند. این کلید ها باید بر روی هر سرور یا کامپیوتری که قرار هست نرم افزار بر روی آن ها قرار داده باشد، موجود باشد. نرم افزار با داشتن این کلید ها می تواند داده ها را رمز گشایی کند.1. معرفی ویژگی Always Encrypted:https://msdn.microsoft.com/en-us/library/mt163865.aspx2. تشریح کلید ها و نکاتی جهت نگهداری آن ها:https://msdn.microsoft.com/en-us/library/mt708953.aspx3. مثالی عملی و ساده از کانفیگ دیتابیس، کلید ها و برنامه:http://www.databasejournal.com/features/mssql/exploration-of-sql-server-2016-always-encrypted-part-1.html4. توضیح محدودیت ها:https://www.infoq.com/news/2015/06/SQL-Server-Always-Encryptedhttp://www.sqlchamp.com/2016/07/limitations-always-encrypted/337 احسان میرسعیدی احسان میرسعیدی Fri, 11 Jan 2019 19:53:55 +0330 https://virgool.io/@Mirsaeedi/%D8%A8%D8%AF%D9%87%DB%8C-%D9%81%D9%86%DB%8C-%D8%B4%D8%B1%DA%A9%D8%AA-%D8%B1%D8%A7-%D9%88%D8%B1%D8%B4%DA%A9%D8%B3%D8%AA-%D9%85%DB%8C-%DA%A9%D9%86%D8%AF-%D9%88-%D9%86%D9%87-%D8%A8%D8%AF%D9%87%DB%8C-%D9%85%D8%A7%D9%84%DB%8C-qr65e600y7rt اصطلاح بدهی فنی (Technical Debt) اساسا برای این به وجود آمد تا افراد حوزه بیزینس و مدیران را متوجه آسیبی کند که با فرامین نابجا، زمان بندی های تنگ و ترش و دید غیرواقعی و غیرمهندسی شان می توانند به نرم افزارها وارد کنند. از آنجایی که این دسته از افراد نسبت به بدهی مالی حساس هستند و درک بسیار خوبی از آن دارند، از عبارت بدهی فنی استفاده می کنیم تا بتوانیم حساسیت آن ها را جلب کنیم.برای توسعه نرم افزار و هر جزیی از آن، همواره دو راه پیش روی ماست. یکی توسعه ای تمیز و ساختارمند و اصولی و دیگری راه حل های کثیف و میانبر. مزیت روش دوم بر روش اول آن است که زمان توسعه به شدت کوتاه تر می شود و خیلی سریع تر می توانیم محصول را به بازار برسانیم. در صورتی که در پیش گرفتن روش دوم، زمان بیشتری برای توسعه نیاز خواهد داشت.مشکل آنجاست که افراد حوزه بیزینس عمدتا به چیزی جز رساندن سریع تر محصول به بازار فکر نمی کنند. آن ها نمی دانند که با در نظر گرفتن زمانبندی های کوتاه و تحت فشار قرار دادن برنامه نویس ها، اگر چه کارشان زودتر اماده می شود ولی زیر بار بدهی سنگینی رفته اند که اگر هرچه زودتر پرداخت نکنند، تمام کسب و کار و نیروی انسانی نخبه شان را از دست خواهند داد. آن ها با گرفتن وام ( کاهش زمان و تحت فشار قرار دادن توسعه دهندگان و کدهای کثیف و میانبر و ابهامات باقی مانده در کد) کارشان انجام شده ولی این وام باید با سود بسیار بالایی بازپرداخت شود. نکته آنجاست که هر چقدر این بدهی دیرتر پرداخت شود، نرخ بهره چندین برابر خواهد شد و در نهایت سازمان را به جایی می رساند که توان تکان خوردن و اصلاح و بازپرداخت نخواهد داشت.بازپرداخت بدهی فنی یعنی refactor کردن کد و تر و تمیز کردن نرم افزار و قطعا هر چه زمان بیشتری گذشته باشد، این امر به تدریج غیرممکن خواهد شد. در نتیجه دیگر در این کد نمی توان ویژگی ها را به سرعت اضافه کرد و هر تغییری منجر به شکست سایر نقاط خواهد شد و عواقب پیشبینی نشده خواهد داشت. کد به تدریج به کدی کهنه تبدیل می شود که از اصول و روش های مدرن فاصله خواهد گرفت. توسعه محصولی که به سرعت وارد بازار شده بود، به شدت کند خواهد شد و باگ هایش و سرویس دهی پایین اش سازمان را دچار بحران اعتبار در میان مشتریان اش خواهد کرد که بزرگ ترین آسیب می باشد.از سوی دیگر سازمان در تعامل با نیروهای برنامه نویس اش به مرور درمانده خواهد شد. آن ها با کدی کهنه و بد درگیر خواهند شد و اشتیاقی به ادامه کار نخواهند داشت. از دوستان و رقبای شان عقب خواهند افتاد، سازمان به دلیل کندی کارها و عدم پیشرفت مناسب از آن ها ناراضی است و هر کسی کار را به دوش دیگری می اندازد و دیگری را مقصر می دانند و به مرور کد بدتر و بدتر خواهد شد، کیفیت پایین می آید و برنامه نویس ها به دلیل نارضایتی از سازمان می روند و یا تنش بین آن ها ایجاد خواهد شد و در نهایت هم بیزینس ضربه سنگینی از این موضوع خواهد خورد. همه این ها هم به خاطر بدهی فنی ایی است که هیچگاه توسط مدیریت سازمان دیده و بازپرداخت نشده است. احسان میرسعیدی احسان میرسعیدی Fri, 11 Jan 2019 19:49:44 +0330 https://virgool.io/@Mirsaeedi/%D9%86%D9%82%D8%AF%DB%8C-%D8%A8%D8%B1-%D8%AC%D9%86%D8%A8%D8%B4-%D8%A7%D8%AC%D8%A7%DB%8C%D9%84-%D9%88-%D8%B4%D8%B1%D8%A7%DB%8C%D8%B7-%D9%81%D8%B9%D9%84%DB%8C-%D8%A2%D9%86-m4qe8ttytrbn جنبش 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/#/en2. مصاحبه کوتاه با Uncle Bob در همین مورد: http://techbeacon.com/uncle-bob-martin-agile-manifesto-15-years-later3. نوشته ای شیوا از استاد Fowler در همین مورد: http://martinfowler.com/bliki/CraftmanshipAndTheCrevasse.html احسان میرسعیدی احسان میرسعیدی Fri, 11 Jan 2019 19:46:23 +0330 https://virgool.io/@Mirsaeedi/%DA%A9%D8%AF-%D9%87%D8%A7-%D9%87%D9%85-%D8%A8%D9%88-%D9%85%DB%8C-%D8%AF%D9%87%D9%86%D8%AF-yflfmndgkoxk در هستی "بو" می تواند حسی خوشایند و یا نامطبوع در آدم ایجاد کند. عموم بوهای بد نشانه ای بر حضور و وجود امری ناخوشایند و اساسی تر اند که نیاز به اصلاح و رفع مشکل خواهند داشت.در کتاب 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 احسان میرسعیدی احسان میرسعیدی Fri, 11 Jan 2019 19:43:31 +0330 https://virgool.io/@Mirsaeedi/%D8%A7%D8%B5%D9%84-%D9%BE%DB%8C%D8%B4%D8%A7%D9%87%D9%86%DA%AF%DB%8C-%DB%8C%D8%A7-the-boy-scout-principle-locshwnnrbli این اصل، از یک اصلِ فلسفی بریتانیایی برداشت شده است: "سعی کنیم جهان را - به نسبت آنچه که پیش تر یافته ایم - جای بهتری کنیم". در کتاب خواندنی "97 نکته ای که هر برنامه نویس باید بداند"، Uncle Bob با استفاده از این اصل، اصلی دیگر را در حوزه نرم افزار بیان می کند: "هر بار کدی را دیدیم، به نسبت قبل آن را بهتر کنیم." در این میان مهم نیست که کدام یک از اعضای تیم قبلا این کد را زده و یا مقدار بهبود چه حد کوچک باشد. این بهبود می تواند به کوچکی تغییر نام متغیر ها، کم کردن تکرار (duplication) ، کوتاه کردن یک متد طولانی و خواناتر کردن کد و ... باشد.در جهان، همه هستی (اعم از نرم افزار) به طور طبیعی به ویرانی و آشوب و فرسودگی میل می کند و برای جلوگیری از این امر ما باید انرژی مصرف کنیم و تعهد داشته باشیم. در نرم افزار هم وقتی همه اعضای تیم به این اصل متعهد باشند، ساختار کد به جای هرز رفتن در گذر زمان، روز به روز و به تدریج بهتر خواهد شد.همانطور که آشغال ریختن در طبیعت، عملی خلاف شعور و فرهنگ می باشد، این اصل بیان می کند که اصلاح نکردن کد در صورت مشاهده ایراد و ضعف به همان میزان دور از فرهنگ و تعهد و حرفه ای گری است. قرار نیست فقط به کد های خودمان اهمیت بدهیم و نسبت به آن ها حساس باشیم. هر کدام از اعضای تیم باید نسبت به کیفیت کار کل تیم حساس بوده و سعی در بهبود داشته باشند.1.یادداشت عمو باب در مورد اصل پیشاهنگیhttp://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule2. در مقاله "ریفکتورینگ فرصت طلبانه"، مارتین فاولر توضیح می دهد که چطور علی رغم وجود دوره هایی برای اصلاح ساختاری سیستم، باید تیم همواره و هر جا و هر زمانی نسبت به ریفکتورینگ و اصلاح کد تعهد داشته باشد. در اینجا فاولر فرصت های متعددی را که در حین کار با کد های سیستم پیش می آید، مطرح می کند و هر کدام را به عنوان فرصتی برای ریفکتورینگ مغتنم می شمارد. فاولر معتقد است ریفکتورینگ یک امر و اصل همیشگی و جاری در سیستم باید باشد.اگر با تیمی مواجه هستیم که همیشه برای اصلاح کد ها نیاز به برنامه ریزی و جلسات متعدد دارد، یک جای کار می لنگد!. https://martinfowler.com/bliki/OpportunisticRefactoring.html احسان میرسعیدی احسان میرسعیدی Fri, 11 Jan 2019 01:47:23 +0330 https://virgool.io/@Mirsaeedi/%D9%86%DA%A9%D8%AA%D9%87-%D8%A7%DB%8C-%D8%AC%D9%87%D8%AA-%D8%A8%D9%87%DB%8C%D9%86%D9%87-%D8%B3%D8%A7%D8%B2%DB%8C-%DA%A9%D9%88%D8%A6%D8%B1%DB%8C-%D9%87%D8%A7%DB%8C-join-%D8%B3%D9%86%DA%AF%DB%8C%D9%86-slpq4efjygud اخیرا لازم بود تا میلیون ها داده ( بخشی از آمار فروش بلیت های تک سفره و دو سفره متروی تهران) را از پایگاه داده ی سروری به پایگاه داده سروری دیگر، جهت پاره ای از پردازش ها انتقال دهیم.برای اینکه داده ها را از سرور مبدا انتخاب کنیم، لازم بود تا سه جدول با داده های به نسبت بزرگی را به هم ملحق (JOIN) کنیم و برای اینکار از اپراتور INNER JOIN استفاده شده بود. متاسفانه کوئریِ ما مدت نامحدودی ادامه پیدا می کرد، بدون آنکه جوابی از سمت Database Engine به ما برگشت داده شود. برای بررسی این موضوع:1. پلن اجرایی (Execution Plan) را بررسی کردم. در برخی جاها نیاز به تعریف Index های جدید، Composite Index ها و Covered Index بود. این ها را تعریف کردیم ولی همچنان هیچ پاسخی از SQL Server بازگشت داده نمیشد.2. در Activity Monitor، مشاهده شد که Thread های متعددی برای کوئری ما ساخته شده و همه دارای wait type ایی برابر با CXPACKET بودند. در نتیجه سعی کردم با تغییر پارامتر MAXDOP و Cost Threshhold for Parralelism اوضاع را بهتر کنم، ولی هیچ افاقه ای نکرد.راه حل نهایی: در نهایت به جای استفاده از INNER JOIN، از اپراتوری به نام INNER HASH JOIN استفاده کردم. روش HASH JOIN دقیقا مناسب وقتی است که قرار است داده های بسیار بسیار زیادی را به هم ملحق کنیم و روش INNER JOIN تنها مناسب داده هایی با حجم کمتر می باشد.در روش HASH JOIN، به طور خلاصه موتور SQL Server دو کار را انجام می دهد:1. ابتدا جدول کوچک تر را در حافظه بارگذاری کرده و در یک ساختار داده ی Hash Table قرار می دهد.2. جدول بزرگ تر از دیسک خوانده می شود، و سطر به سطر با Hash Table مقایسه شده و در صورت لازم به هم ملحق می شوند. این علمیات با O(1)1 صورت می گیرد.در روش جدید، در 16 ثانیه پاسخ کوئری برگشت داده شد.1. در مورد Hash Join:http://blog.sqlauthority.com/2007/06/14/sql-server-explanation-sql-server-hash-join/2. روش های دیگری نیز برای عملیات JOIN وجود دارند، که با توجه به ماهیت داده ها می توانیم از پایگاه داده بخواهیم، با روش مناسب عملیات الحاق سازی را انجام دهند. به این روش ها JOIN Hint گفته می شود. اگر با داده های زیادی کار می کنید، یادگیری این ها خالی از لطف نیست.https://technet.microsoft.com/en-us/library/ms191426(v=sql.105).aspxhttps://msdn.microsoft.com/en-us/library/ms173815.aspx احسان میرسعیدی احسان میرسعیدی Fri, 11 Jan 2019 01:34:47 +0330 https://virgool.io/@Mirsaeedi/%D8%A7%D9%86%D8%AF%D8%A7%D8%B2%D9%87-%DA%AF%DB%8C%D8%B1%DB%8C-%DA%A9%D8%A7%D8%B1%D8%A7%DB%8C%DB%8C-%D8%AA%DB%8C%D9%85-%D9%87%D8%A7%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1%DB%8C-a0k8ke58fbot کارایی تیم ها و سلامت فرایند های موجود در توسعه نرم افزار را باید توسط تعدادی معیار (metric) تحت سنجش قرار دهیم. سه تا از معروف ترین معیار ها که می توانند، کارایی تیم و رضایت مشتری را مشخص کنند، Lead Time و Cycle Time و Escaping Defects می باشند. معیار Lead Time: فاصله زمانِ درخواست مشتری با زمانی است که درخواست او در نسخه بعدی نرم افزار پیاده سازی شده است. به طور دقیق تر یعنی چه مدت پس از قرار گرفتن درخواست در Backlog پروژه، تیم توانسته این قابلیت را به نحو کامل و بدون مشکل، در نسخه بعدی پیاده سازی کرده و رضایت مشتری را کسب کند. معیار Cycle Time: فاصله زمانِ قرار گرفتن یک تسک در اختیار تیم توسعه، تا زمان پایانِ پیاده سازی و تست آن می باشد. معیار Escaping Defects: این معیار مشخص می کند که در هر نسخه چه تعداد باگ و نقطه ضعف انتشار پیدا کرده و به محیط عملیات راه پیدا کرده اند. این پارامتر نشان دهنده کیفیتِ کار تیم و فرایند های بازرسی خواهد بود. این پارامتر را به گونه ای دیگر هم می شود بررسی کرد، یعنی می توانیم بیان کنیم چه تعداد از تسک های فعلی مربوط به اصلاحِ نقاط ضعف و کم کاری های گذشته اند و چه تعداد از تسک ها مربوط به ویژگی های جدید سیستم می باشند. با این نگاه می توانیم، مشخص کنیم که تیم تا چه میزان دچار دوباره کاری و به هدر دادن منابع می باشد و یا تا چه میزان ارزش آفرینیِ مداوم ایجاد می کند.معیار Lead Time، معیاری است که باید سعی در کاستن آن داشته باشیم و معیاری است که توسط مشتری لمس خواهد شد. در طرف دیگر، معیار Cycle Time، معیاری است که کاملا کاربردی درون تیمی خواهد داشت و می تواند برای ارزیابی داخلی مورد استفاده قرار بگیرد.آیا در پروژه های شما Lead Time اندازه گیری می شود؟ آیا زمان مطلوبی برای آن در نظر گرفته شده است؟ چگونه آن را اندازه می گیرید؟1. https://www.agilealliance.org/glossary/lead-time/2. http://kanbantool.com/kanban-library/analytics-and-metrics/kanban-definition-of-lead-time-and-cycle-time#.WHFCRPl95p83. اندازه گیری پارامتر های فوق در TFS:https://www.visualstudio.com/en-us/docs/report/guidance/cumulative-flow احسان میرسعیدی احسان میرسعیدی Fri, 11 Jan 2019 01:23:22 +0330 https://virgool.io/@Mirsaeedi/%D8%AC%D9%84%D9%88%DA%AF%DB%8C%D8%B1%DB%8C-%D8%A7%D8%B2-%D8%AD%D9%85%D9%84%D9%87-dos-dd5nqazechmv یکی از آسان ترین روش های حمله به وب سایت ها استفاده از تکنیکی به نام Denial Of Service (عدم پذیرش سرویس) و یا DOS می باشد.در این تکنیک، فرد مهاجم تعداد بسیار بالایی از درخواست ها را به سمت سامانه شما روانه می کند. با بالا رفتن درخواست ها، منابع بسیاری زیادی در سرور اشغال می شود و یک صف طولانی از درخواست ها شکل می گیرد که به علت طولانی بودن، بسیاری از درخواست ها هیچ وقت شانس رسیدگی پیدا نخواهند کرد و کاربران شما عملا از دسترسی به وب سایت محروم خواهند شد. برای جلوگیری از این اتفاق یکی از ساده ترین کار ها آن می باشد که فهرستی از تمامیِ IP هایی که به سمت شما آمده اند را ذخیره کنید و در هر بازه ی زمانیِ مشخص، اجازه تعداد محدودی درخواست را به آن IP بدهید.قطعا بهترین جا برای پیاده سازی این منطق، جایی است که در فاصله زیادی از برنامه شما قرار داشته و نزدیک به سیستم عامل و وب سرور می باشد. در این صورت قبل از رسیدن درخواست به سمت برنامه و گرفتن منابع، درخواست مسدود شده و از صف خارج خواهد شد.قابلیت Dynamic IP Address Restrictions، در IIS دقیقا به همین منظور قرار داده شده است. توسط این قابلیت می توانید در سطح وب سرور، محدودیت ها و سیاست هایی را بر روی IP ها اعمال کنید تا در صورت وقوع حملات DOS، به طور خودکار IP های مهاجم تشخیص داده شده و از چرخه سیستم عامل خارج شوند.1. https://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-dynamic-ip-address-restrictions2. https://technet.microsoft.com/en-us/library/hh831785(v=ws.11).aspx احسان میرسعیدی احسان میرسعیدی Fri, 11 Jan 2019 01:21:38 +0330 https://virgool.io/@Mirsaeedi/%D8%A7%D9%84%DA%AF%D9%88%DB%8C-%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-circuit-breaker-lukkhre88zbv این الگو، یکی از الگوهای اصلی در سیستم های غیرمتمرکز (Distributed) و ابری می باشد. البته این نکته را مد نظر داشته باشید که حتی اگر محل استقرار پایگاه داده شما، از وب اپلیکیشن شما جدا است و یا در وب اپلیکیشن تان از وب سرویس های سایرین استفاده می کنید، این الگو برای تان قابل استفاده است.این الگو کمک می کند تا پایداری کل سیستم در مواقعی یکی از سیستم ها دچار مشکل و یا کندی می شود، افزایش پیدا کند. شرکت Netflix مقاله ها و تجربه های عملی گرانبهایی را با بهره گیری از این الگو گردآوری کرده است.وقتی که از این الگو استفاده کنیم، به جای آنکه مانند سابق به طور مستقیم با وب سرویس های دیگران ارتباط بگیریم و از سرویس هایی خارج از اپلیکیشن مان استفاده کنیم، یک واسط بین سیستم خودمان و سیستم دیگر قرار می دهیم و ازین پس در خواست ها از طریق این واسط به سرویس دیگر منتقل خواهند شد.این واسط، خروجی وب سرویس را کنترل می کند و به خطاها، تایم اوت ها و ... غیره حساس می باشد و اگر این ها از حد آستانه ای بیشتر شوند، مدار را می بندد و نمی گذارد هیچ درخواستی از سیستم ما به سیستم دیگر هدایت شود. این امر موجب می شود تا درخواست های کاربران به علتِ وجود خطا و یا وقوع تایم اوت در سیستم ما تلنبار نشده و از هدر رفت منابع جلوگیری کنیم. این واسط کمک می کند در صورت وقوع خطا در سیستم های وابسته هر چه زودتر آن ها را از چرخه رسیدگیِ سیستم خارج کنیم.در تجربه ای که اخیرا در سیستمِ توزیع شده طرح ترافیک تهران داشتیم، کند شدن یکی از سرویس ها (مثلا A) موجب شده بود تا درخواست ها را در زمانی بیشتر از 5 ثانیه پاسخ بدهد. از طرفی چون حجم درخواست های کاربران بالا بود، تعداد بسیاری درخواست در سرویس دیگری (مثلا B) که به سرویس A وابسته بود، تلنبار می شد و معطل می شدند. این انباشتگی موجب می شد تا سرویس B دچار مصرف بیش از حد حافظه و Thread ها و پایگاه داده ... شده و در نهایت پایین برود. در واقع سیستم B در تجربه ای که ما داشتیم، پس از دو دقیقه Down می شد و مجبور بودیم سیستم را مجددا ریست کنیم و این موضوع مدام تکرار می شد. در واقع نقص در یک سرویس موجب می شود، همه سرویس های دیگر به ترتیب دچار مشکل شوند.در صورتی که از الگوی Circuit Breaker استفاده می شد،سرویس B به طور هوشمند می بایست ارسال درخواست ها به سرویس A را متوقف می کرد و جریان بین شان قطع می شد. در این صورت درخواست ها در B تلنبار نمی شدند.همچنین Circuit Breaker در هنگامی که در وضعیت بسته قرار دارد، به طور خودکار گه گاه درخواست هایی را از خود عبور خواهد داد تا اگر مشکل برطرف شده، مجددا باز شود و جریان برقرار گردد.1. مقاله فاولر در پاراگراف ابتدایی و انتهایی به صورت خلاصه مطالب خوبی در این زمینه دارد:https://martinfowler.com/bliki/CircuitBreaker.html2. مقاله مایکروسافت: https://msdn.microsoft.com/en-us/library/dn589784.aspx3. پیاده سازی این الگو به راحتی توسط کتابخانه معتبر Polly:http://blog.jaywayco.co.uk/circuit-breaking-with-polly/4. تجربه Netflix در نگهداری سیستم های توزیع شده اش و استفاده از این الگو:http://techblog.netflix.com/2012/02/fault-tolerance-in-high-volume.htmlhttp://techblog.netflix.com/2011/12/making-netflix-api-more-resilient.html احسان میرسعیدی احسان میرسعیدی Fri, 11 Jan 2019 01:18:18 +0330 https://virgool.io/@Mirsaeedi/%D8%A7%D9%84%DA%AF%D9%88%DB%8C-%D8%AA%D9%84%D8%A7%D8%B4-%D9%85%D8%AC%D8%AF%D8%AF-%DB%8C%D8%A7-retry-pattern-qy1u2xia2rgs سامانه هایی که امروز توسعه داده می شوند، در بسیاری از موارد نیاز دارند تا بتوانند با سرویس ها و منابعِخارجیِ دیگری از طریق شبکه و اینترنت و ... دسترسی داشته باشند. مثلا:1. در ساده ترین حالت، سیستم ها نیاز دارند تا بتوانند از طریق لایه شبکه به پایگاه داده به عنوان یک منبع (Resource) خارجی دسترسی داشته باشند.2. فرض کنید اپلیکیشن و یا وب سایتی دارید که قرار هست بخشی از محتوا و یا سرویسی که به کاربر ارائه می دهد را از طریق وب سرویس هایی که توسط شرکت های دیگری آماده شده اند، تهیه کند.3. ممکن است سامانه ای داشته باشید که هر کدام از اجزای آن تفکیک شده هستند و از طریق وب سرویس ها با یکدیگر در ارتباط می باشند. مثلا فرض کنید سامانه ی بزرگی دارید که سیستمی مجزا برای امور مشتریان، سیستمی مجزا برای فروش و سیستم مجزا برای انبارداری دارد. به این نوع از معماری ها به اختصار Microservice هم گفته می شود. یعنی سامانه به سرویس های متعدد و تک منطوره شکسته می شود.در این نوع از سیستم ها وقتی قرار هست درخواستی به یک منبع خارجی ارسال شود، به هر دلیلی ممکن هست که درخواست با خطا رو به رو شود. مثلا ممکن است ناپایداری در شبکه وجود داشته باشد و یا یک سرویس به طور موقت از گردانه خارج شده باشد. برای افزایش پایداریِ سیستم ها در برابر اتفاق های اینچنین سیستم باید نوعی حالت ارتجاعی (Resiliency) داشته باشد تا در برابر حوادث گوناگون واکنش مناسبی را انجام دهد.در اینجا است که الگوی Retry Pattern به کار می آید و یکی از الگوهایی است که باید در مواقعی که با سیستم های خارجی در تماس هستیم آن را در نظر داشته باشیم. وقتی سیستم توسط این الگو پیاده سازی شده باشد، در صورت وقوع برخی از خطا ها از کار نمی افتد و کاربران غافل گیر نخواهند شد. در این شرایط سامانه توسط یک سیاست مشخص مجددا تلاش خواهد کرد تا درخواست اش را برای سرویس خارجی مجددا ارسال کند.در این الگو می توانید دفعات تلاش مجدد و یا فاصله بین هر تلاش را مشخص کنید.یکی از کتابخانه های مهم دات نت که به بنیاد معتبر dotNet Foundation هم راه یافته، کتابخانه Polly می باشد که توسط آن به راحتی می توانید الگوی Retry و Circuit Breaker را پیاده سازی کنید.1. کتابخانه Polly:https://github.com/App-vNext/Polly2. کتابخانه Hystrix که برای جاوا و توسط شرکت Netflix پیاده سازی شده تا بتوانند سیستم های پایداری را در معماری مایکروسرویس شان داشته باشند. (مشابه و الگوی Polly)https://github.com/Netflix/Hystrix3. مثالی از Polly:https://alastaircrabtree.com/implementing-the-retry-pattern-using-polly/4. تعریف الگوی Retry Pattern (حتما بخوانید):https://msdn.microsoft.com/en-us/library/dn589788.aspx احسان میرسعیدی احسان میرسعیدی Fri, 20 Apr 2018 22:37:11 +0430 https://virgool.io/@Mirsaeedi/%D8%A7%D8%AC%D8%B1%D8%A7%DB%8C-%DA%A9%D8%AF-%D9%87%D8%A7%DB%8C-%D8%AF%D8%A7%D8%AA-%D9%86%D8%AA-%D9%85%D8%B3%D8%AA%D9%82%DB%8C%D9%85%D8%A7-%D8%AF%D8%B1-sql-server-sdnbpsayb3zy یکی از قابلیت های اعجاب آور و البته کمتر شناخته شده SQL Server آن می باشد که توانایی اجرای کد های دات نت را دارا می باشد. به این ویژگی SQL CLR گفته می شود که از نسخه SQL Server 2005 پشتیبانی می شود.شما برای پیاده سازی منطق های پیچیده نیازی به استفاده از T-SQL نخواهید داشت تا ماحصل تلاش تان کدهای کثیف، ناخوانا، بدقیافه و طولانی T-SQL باشد. به راحتی می توانید Store Procedure، Function، Trigger و موارد متعدد دیگری را در قلب SQL Server توسط زبان پرقدرت سی شارپ اجرا کنید. در SQL CLR می توانید از تمام کتابخانه های دات نت استفاده کنید و از آن ها برای پیاده سازی منطق خود بهره بگیرید. می توانید به راحتی ایمیل ارسال کنید، وب سرویسی را صدا بزنید، با فایل ها کار کنید، با سیستم عامل تعامل کنید، در صورت لزوم از الگوریتم های رمزنگاری استفاده کنید و غیره. با سی شارپ می توانید کدی با ساختارِ خوانا و قابل نگهداری داشته باشید و آن را به راحتی توسط Visual Studio دیباگ کنید و به راحتی کد های تان در پایگاه داده مورد نظر خود مستقر (Deploy) کنید.مزیت SQL CLR آن می باشد که کارایی اش تفاوت بسیار جزیی با T-SQL دارد و حتی در سناریو های پیچیده دارایِ کارایی بهتری می باشد.* برای توسعه این نوع از پروژه ها نیاز به نصب SQL Server Data Tools می باشد.* فعال سازی اجرای SQL CLR در SQL Serverhttps://msdn.microsoft.com/en-us/library/ms131048.aspx?f=255&MSPPError=-2147217396* مزایای SQL CLRhttps://msdn.microsoft.com/en-us/library/k2e1fb36(v=vs.100).aspx?f=255&MSPPError=-2147217396* آشنایی مقدماتی http://www.codeproject.com/Tips/841439/Create-Run-Debug-and-Deploy-SQL-CLR-Function-with* کمی فنی ترhttp://www.sqlservercentral.com/articles/Stairway+Series/119429/و http://www.sqlservercentral.com/articles/SQLCLR/138154/در این زمینه نکات ریز و درشت متعددی برای یادگیری وجود دارد که حتما بر حسب نیازتان می توانید به راحتی جستجو کره و بیاموزید. احسان میرسعیدی احسان میرسعیدی Fri, 20 Apr 2018 20:53:18 +0430 https://virgool.io/@Mirsaeedi/%D8%AC%D8%B9%D8%A8%D9%87-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3-%D9%87%D8%A7-rjlwz7zmeqdo در کار ما توسعه دهنده ها، جعبه ابزاری که به آن مجهز هستیم در بهینگی و راحتی کار ما تاثیر مستقیمی خواهد داشت. جعبه ابزار ما می تواند متشکل از افزونه های مرورگر ها، افزونه های IDE و ابزارهایی بر روی سیستم عامل مان و غیره باشد.سعی می کنم گهگاه این ابزارها را در حوزه های مختلف معرفی کنم. اما برای شروع به پستی از اقای اِشنایدنباخ برخوردم که به نظر نکاتِ خوبی داشت. در این پست، لینکی هم به جعبه ابزارهای محبوب اسکات هنسلمن داده شده که مشاهده اش خالی از لطف نیست.https://schneids.net/essential-dotnet-csharp-vbnet-web-tools-2016/ احسان میرسعیدی احسان میرسعیدی Fri, 20 Apr 2018 17:51:55 +0430