وحید نصیری وحید نصیری
مطالب
ارتقاء به ASP.NET Core 1.0 - قسمت 17 - بررسی فریم ورک Logging
ASP.NET Core به همراه یک فریم ورک توکار ثبت وقایع (Logging) ارائه شده‌ی توسط تزریق وابستگی‌ها است که به صورت پیش فرض نیز فعال است.


این تصویر را پیشتر در مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 6 - سرویس‌ها و تزریق وابستگی‌ها» مشاهده کرده‌اید. در اینجا لیست سرویس‌هایی را مشاهده می‌کنید که به صورت پیش فرض، ثبت شده‌اند و فعال هستند و ILogger و ILoggerFactory نیز جزئی از آن‌ها هستند. بنابراین نیازی به فعال سازی آن‌ها نیست؛ اما برای استفاده‌ی از آن‌ها نیاز به انجام یک سری تنظیمات است.


پیاده سازی ثبت وقایع در ASP.NET Core

اولین قدم کار با فریم ورک ثبت وقایع ASP.NET Core، معرفی ILoggerFactory به متد Configure کلاس آغازین برنامه است:
public void Configure(ILoggerFactory loggerFactory, IApplicationBuilder app, IHostingEnvironment env)
{
   loggerFactory.AddConsole(Configuration.GetSection("Logging"));
   loggerFactory.AddDebug();
متد Configure امضای مشخصی را ندارد و در اینجا به هر تعداد سرویسی که نیاز باشد، می‌توان اینترفیس‌های آن‌ها را جهت تزریق وابستگی‌های متناظر توسط IoC Containser توکار ASP.NET Core، معرفی کرد. در اینجا برای تنظیم ویژگی‌های سرویس ثبت وقایع، تزریق وابستگی ILoggerFactory  صورت گرفته‌است.
سطر اول متد، تنظیمات ثبت وقایع را از خاصیت Logging فایل appsettings.json برنامه می‌خواند (در مورد خاصیت Configuration، در مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 7 - کار با فایل‌های config» بیشتر بحث شد) و لاگ کردن ویژه‌ی در کنسول NET Core. را فعال می‌کند:
{
    "Logging": {
        "IncludeScopes": false,
        "LogLevel": {
            "Default": "Debug",
            "System": "Information",
            "Microsoft": "Information"
        }
    }
}
در مورد Log Level و یا سطوح ثبت وقایع، در ادامه‌ی مطلب بحث خواهد شد.

و سطر دوم سبب نمایش اطلاعات لاگ شده در کنسول دیباگ ویژوال استودیو می‌شود.
متد AddDebug برای شناسایی، نیاز به افزودن وابستگی‌های ذیل در فایل project.json برنامه را دارد:
{
    "dependencies": {
        //same as before 
        "Microsoft.Extensions.Logging": "1.0.0",
        "Microsoft.Extensions.Logging.Console": "1.0.0",
        "Microsoft.Extensions.Logging.Debug": "1.0.0" 
    }
}
پس از این تنظیمات، برنامه را اجرا کنید.


در اینجا می‌توانید ریز وقایعی را که توسط ASP.NET Core لاگ شده‌است، مشاهده کنید. برای مثال چه درخواستی صورت گرفته‌است و چقدر اجرای آن زمان‌برده‌است.
این فعال سازی مرتبط است به متد AddDebug که اضافه شد. اگر می‌خواهید خروجی AddConsole را هم مشاهده کنید، از طریق خط فرمان، به پوشه‌ی اصلی پروژه وارد شده و سپس دستور dotnet run را اجرا کنید:


دستور dotnet run سبب راه اندازی وب سرور برنامه بر روی پورت 5000 شده‌است که در تصویر نیز مشخص است.
بنابراین اینبار برای دسترسی به برنامه باید مسیر http://localhost:5000 را در مرورگر خود طی کنید. در اینجا نیز می‌توان حالت‌های مختلف اطلاعات لاگ شده را مشاهده کرد و تمام این‌ها مرتبط هستند به ذکر متد AddConsole .


کار با سرویس ثبت وقایع ASP.NET Core از طریق تزریق وابستگی‌ها

برای کار با سرویس ثبت وقایع توکار ASP.NET Core در قسمت‌های مختلف برنامه، می‌توان از ترزیق وابستگی ILogger آن استفاده کرد:
[Route("[controller]")]
public class AboutController : Controller
{
    private readonly ILogger<AboutController> _logger;
 
    public AboutController(ILogger<AboutController> logger)
    {
        _logger = logger;
    }
 
    [Route("")]
    public ActionResult Hello()
    {
        _logger.LogInformation("Running Hello");
        return Content("Hello from DNT!");
    }
در این کنترلر، وابستگی اینترفیس ILogger با پارامتری از نوع کنترلر جاری به سازنده‌ی کلاس تزریق شده‌است. علت ذکر این پارامتر جنریک این است که ILoggerFactory بداند چگونه باید متد CreateLogger خود را در پشت صحنه وهله سازی کند.
سپس با توجه به اینکه این سرویس جزو سرویس‌های از پیش ثبت شده‌ی ASP.NET Core است، امکانات آن بدون نیاز به تنظیمات بیشتری در دسترس است. برای مثال از متد LogInformation آن در اکشن متد Hello استفاده شده‌است و خروجی عبارت لاگ شده‌ی آن‌را در اینجا می‌توانید مشاهده کنید:



سطوح مختلف ثبت وقایع

اینترفیس ILogger به همراه متدهای مختلفی است؛ مانند LogError، LogDebug و غیره. معانی آن‌ها به شرح زیر هستند:
Debug (1): ثبت واقعه‌ای است با بیشترین حد جزئیات ممکن که عموما شامل اطلاعات حساسی نیز می‌باشد. بنابراین نباید در حالت ارائه‌ی نهایی برنامه فعال شود.
(2) Verbose: ثبت وقایعی مفصل، جهت بررسی مشکلات در حین توسعه‌ی برنامه. تنها باید حاوی اطلاعاتی برای دیباگ برنامه باشند.
(3) Information: عموما برای ردیابی قسمت‌های مختلف برنامه مورد استفاده قرار می‌گیرند.
(4) Warning: جهت ثبت واقعه‌ای نامطلوب در سیستم بکار می‌رود و سبب قطع اجرای برنامه نمی‌شود.
(5) Errors: مشکلات برنامه را که سبب قطع سرویس دهی آن شده‌اند را ثبت می‌کند. هدف آن ثبت مشکلات واحد جاری است و نه کل برنامه.
Critical (6): هدف آن ثبت مشکلات بحرانی کل سیستم است که سبب از کار افتادن آن شده‌اند.

برای مثال در حین تنظیم متد AddDebug که سبب نمایش اطلاعات لاگ شده در کنسول دیباگ ویژوال استودیو می‌شود، می‌توان حداقل سطح ثبت وقایع را نیز ذکر کرد:
 loggerFactory.AddDebug(minLevel: LogLevel.Information);
این حداقل مرتبط است با اعدادی که در کنار سطوح فوق ملاحظه می‌کنید. برای مثال اگر حداقل سطح ثبت وقایع به Information تنظیم شود، چون سطح آن 3 است، دیگر سطوح پایین‌تر از آن لاگ نخواهند شد. اهمیت این مساله در اینجا است که اگر صرفا نیاز به اطلاعات Critical داشتیم، نیازی نیست تا با انبوهی از اطلاعات لاگ شده سر و کار داشته باشیم و به این ترتیب می‌توان حجم اطلاعات نمایش داده شده را کاهش داد.

البته ترتیب واقعی این سطوح را در enum مرتبط با آن‌ها بهتر می‌توان مشاهده کرد:
  public enum LogLevel
  {
    Trace,
    Debug,
    Information,
    Warning,
    Error,
    Critical,
    None,
  }

یک نکته: زمانیکه متد AddDebug را بدون پارامتر فراخوانی می‌کنید، حداقل سطح ثبت وقایع آن به Information تنظیم شده‌است. یعنی در این لاگ، خبری از اطلاعات Debug نخواهد بود (چون سطح دیباگ پایین‌تر است از Information).  بنابراین اگر می‌خواهید این اطلاعات را هم مشاهده کنید باید پارامتر minLevel آن‌را به LogLevel.Debug تنظیم نمائید.


امکان استفاده‌ی از پروایدرهای ثبت وقایع ثالث

تا اینجا، دو نمونه از پروایدرهای توکار ثبت وقایع ASP.NET Core را بررسی کردیم. اگر نیاز به ثبت این اطلاعات با فرمت‌های مختلف و یا در بانک اطلاعاتی وجود دارد، می‌توان به تامین کننده‌های ثالثی که قابلیت کار با ILoggerFactory را دارند نیز مراجعه کرد. برای مثال:
- elmah.io - provider for the elmah.io service
- Loggr - provider for the Loggr service
- NLog - provider for the NLog library
- Serilog - provider for the Serilog library
‫۸ سال و ۳ ماه قبل، جمعه ۱ مرداد ۱۳۹۵، ساعت ۱۸:۳۵
وحید محمدطاهری وحید محمدطاهری
مطالب
رفع مشکل Migration با تغییر NameSpace در EF
فعال سازی Migration (+ و +) بسیار ساده است؛ ولی یکی از مشکلات رایجی که در زمان اجرای دستور Add-Migration در Entity Framework وجود دارد:
Unable to generate an explicit migration because the following explicit migrations are pending: ...

اولین قدم در برخورد با این مسئله، بررسی جدول MigrationHistory__ در پایگاه داده مورد نظر است تا لیستی از سوابق به‌روزرسانی‌های پایگاه داده را با استفاده کد زیر مشاهده کرد:
SELECT [MigrationId]
      ,[ContextKey]
      ,[Model]
      ,[ProductVersion]
  FROM [dbo].[__MigrationHistory]
MigrationId کلید مربوط به این query است و مقدار آن برابر است با نامی است که در زمان استفاده‌ی از Add-Migration وارد شده است.

زمانی این مشکل به وجود می‌آید (حالت اول) که بعد از اجرای Add-Migration دستور Update-Database را فراخوانی کرده باشید و سپس Add-Migration را دوباره فراخوانی کنید و یا (حالت دوم) وقتی که namespace کلاس Configuration را تغییر داده باشید؛ چرا که Entity Framework برای انجام تغییرات Migration از دو کلید MigrationId و ContextKey استفاده می‌کند که مقدار ContextKey برابر namespace فایل Configuration است.
برای حالت اول که مشخص است با اجرای دستور Update-Database کار به‌روزرسانی پایگاه داده انجام می‌شود و بعد می‌توانید Add-Migration را فراخوانی کنید.
در حالت دوم باید با استفاده از SQL تمامی رکوردهای موجود در جدول MigrationHistory__ را ویرایش کرد؛ با استفاده از کد زیر:
UPDATE  [dbo].[__MigrationHistory]
SET     [ContextKey] = 'VMT.Data.Migrations.Configuration'
WHERE   [ContextKey] = 'MyProject.Migrations.Configuration';

در پایان برای اطمینان از لیست Migration‌های اعمال شده بر روی پایگاه داده مورد نظر، می‌توانید از دستور Get-Migrations استفاده کنید.
‫۹ سال قبل، یکشنبه ۲۶ مهر ۱۳۹۴، ساعت ۰۱:۲۰
دلپاک دلپاک
مطالب
(Domain Driven Design) به زبان ساده
DDD چیست؟ روشی است ساده، زیبا، در وهله اول برای تفکر، و در وهله دوم برای توسعه نرم افزار، که می‌توان بر مبنای آن نیازمندیهای پویا و پیچیده‌ی حوزه دامین را تحلیل، مدل و نهایتا پیاده سازی کرد.
در این روش توسعه نرم افزار تاکید ویژه ای بر الزامات زیر وجود دارد:
  • تمرکز اصلی پروژه، باید صرف فائق آمدن بر مشکلات و پیچیدگیهای موجود در دامین شود.
  • پیچیدگیهای موجود در دامین پس از شناسایی به یک مدل تبدیل شوند.
  • برقراری یک رابطه‌ی خلاق بین متخصصان دامین و افراد تیم توسعه برای بهبود مستمر مدل ارائه شده که نهایتا راه حل مشکلات دامین است بسیار مهم می‌باشد.
مبدع این روش کیست؟
بخوانید:
Eric Evans is a specialist in domain modeling and design in large business systems. Since the early 1990s, he has worked on many projects developing large business systems with objects and has been deeply involved in applying Agile processes on real projects. Eric is the author of "Domain-Driven Design" (Addison-Wesley, 2003) and he leads the consulting group Domain Language, Inc. 
ویدیویی سخنرانی اریک اوانس با عنوان: DDD: putting the model to work
شرایط موفقیت اجرای یک پروژه مبتنی بر DDD چیست؟
  • دامین ساده و سر راست نباشد.
  • افراد تیم توسعه با طراحی / برنامه نویسی شی گرا آشنا باشند.
  • دسترسی به افراد متخصص در مسائل مرتبط با دامین آسان باشد.
  • فرآیند تولید نرم افزار، یک فرآیند چابک باشد.
در این باره چه چیزی بخوانم؟
برای شروع توصیه می‌کنم بخوانید: Domain-Driven Design: Tackling Complexity in the Heart of Software 
نویسنده: Eric Evans


در ادامه می‌پردازم به اینکه ابزار DDD برای شکستن پیچیدگیهای دامین و تبدیل آنها به مدل کدامند؟
پاسخ خلاصه در زیر آمده است. دعوت می‌کنم تا شرح هر یک از این موارد را در پستهای بعدی پیگیر باشید.
  • Entity
  • Value Object
  • Aggregate
  • Service
  • Repository
  • Factory

 قبلا توضیح داده بودم که طراحی متاثر از حوزه‌ی کاری (Domain Driven Design) منجر به کاهش، درک و نهایتا قابل مدیریت کردن پیچیدگیهای موجود در حوزه عملیاتی نرم افزار (Domain) می‌شود. توجه کنیم که تحلیل و مدلسازی، فعالیتهای رایج در حوزه هایی مانند حمل و نقل، اکتشافات، هوا فضا، شبکه‌های اجتماعی و ... می‌تواند بسیار دشوار باشد.

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

DDD در واقع روشی است برای دقیق‌تر فکر کردن در مورد نحوه ارتباط و تعامل اجزای مدل با یکدیگر. این سبک طراحی (DDD) به تولید مدلی از اشیاء می‌انجامد که نهایتا تصویری قابل درک (Model) از مسائل مطرح در حوزه‌ی کاری ارائه می‌دهند. این مدل ارزشمند است وقتی که:

1- نمایی آشکار و در عین حال در نهایت سادگی و وضوح از همه‌ی مفاهیمی باشد که در حوزه عملیاتی نرم افزار(Domain) وجود دارد.
2- به تناسب درک کاملتری که از حوزه کاری کسب می‌شود بتوان این مدل را بهبود و توسعه داد(Refactoring).

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

توجه کنیم که DDD به چگونگی سازماندهی اشیاء توجه ویژه ای دارد ولی DDD چیزی درباره برنامه نویسی شی گرا نیست. DDD متدولوژیی است که با بهره گیری از مفاهیم شی گرایی و مجموعه ای از تجارب ممتاز توسعه نرم افزار (Best Practice) پیچیدگیها را و قابلیت توسعه و نگهداری نرم افزار را بهبود می‌دهد.

ایده مستتر در DDD ساده است. اگر در حوزه کاری مفهوم (Concept) ارزشمندی وجود دارد باید بتوان آن را به وضوح در مدل مشاهده کرد. برای مثال صحیح نیست که یک شرط ارزشمند حوزه کسب و کار را با مجموعه‌ی سخت فهمی از If / Else ها، در مدل نشان داد. این شرط مهم را می‌توان با Specification pattern پیاده سازی کرد تا تصویری خوانا‌تر از Domain در مدل بوجود بیاید.

مدلی که دستیبابی به آن در DDD دنبال می‌شود مدلی است سر راست و گویا با در نظر گرفتن همه جوانب و قواعد حوزه‌ی عمل نرم افزار. در این مدل مطلوب و ایده آل به مسائل ذخیره سازی (persistence) پرداخته نمی‌شود. (رعایت اصل PI). این مدل نگران چگونگی نمایش داده‌ها در واسط کاربری نیست. این مدل نگران داستانهای Ajax نیست. این مدل یک مدل Pureاست که دوست داریم حتی المقدور POCO باشد. این مدلی است برای بیان قواعد و منطق موجود در حوزه عمل نرم افزار. این قواعد همیشه تغییر می‌کنند و مدلی که از آموزه‌های DDDالهام گرفته باشد، راحت‌تر پذیرای این تغییرات خواهد بود. به همین دلیل DDD با روشهای توسعه به سبک اجایل نیز قرابت بیشتری دارد.  
‫۱۱ سال و ۴ ماه قبل، یکشنبه ۹ تیر ۱۳۹۲، ساعت ۲۳:۲۰
ناصر حاجلو ناصر حاجلو
مطالب
بومی‌سازی چیست؟

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

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

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


با اینکه بومی‌سازی لزوما ارتباط چندانی با کاربردپذیری ندارد اما در کاربردپذیر کردن برنامه و استانداردهای برنامه بطرز چشمگیری تاثیرگذار است. موارد مختلفی را باید در هنگام تولید یک برنامه چندزبانه در نظر داشت از جمله:
  • از این برنامه در چه کشورهایی استفاده خواهد شد؟
  • چه نوع تقویم‌هایی را باید پشتیبانی نماید؟
  • نحوه افزودن زبان جدید به برنامه چگونه خواهد بود؟
  • تکمیل فیلدهای حساس مانند نام کاربری به چه زبانی مجاز است؟
  • تولید صفحات برنامه در جهات مختلف به چه صورت خواهد بود؟
  • تجربه کاربری مناسب برای کاربری که راست به چپ می‌نویسد و کاربرزی که چپ به راست می‌نویسد چگونه است؟
  • شرکت‌های بزرگ چطور با این مشکلات روبرو می‌شوند؟
  • ذخیره داده‌ها در پایگاه داده باید به چه صورتی و با چه زبان مرجعی صورت پذیرد؟
  • تبدیل و تغییر داده‌ها چقدر لازم است؟

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

تعاریف :

بوم : Local
بومی : Localized
بومی‌سازی : Localization
جهانی‌سازی : Globalization
کاربردپذیر : Usability
‫۱۲ سال و ۱ ماه قبل، شنبه ۱۵ مهر ۱۳۹۱، ساعت ۲۳:۳۱
وحید نصیری وحید نصیری
مطالب
نکات امنیتی OWASP مخصوص برنامه نویس‌های دات نت
OWSAP ارگانی است غیرانتفاعی که هدف آن ترویج طراحی برنامه‌های امن وب است. در این راه هم مطالب آموزشی بسیار ارزشمندی را منتشر کرده است [+]. در لینک‌های زیر این مطالب از دیدگاه برنامه نویس‌های دات نت مورد بررسی قرار گرفته‌اند. هر چند مطابق آخرین گزارش WhiteHat که اخیرا منتشر شده [+]، تعداد Exploits مربوط به ASP.NET در مقایسه با PHP و جاوا بسیار کمتر بوده اما نیاز است تا با مشکلات عمومی موجود و راه‌حل‌های مرتبط بیشتر آشنا شد:



‫۱۳ سال و ۵ ماه قبل، چهارشنبه ۲۵ خرداد ۱۳۹۰، ساعت ۱۳:۱۸
وحید نصیری وحید نصیری
مطالب
مشکل امنیتی FreeTextBox‌ و روش رفع آن

FreeTextBox یکی از ادیتورهای متنی بسیار خوب تحت وب ASP.Net‌ است که از نگارش 1 تا 3 و نیم ASP.Net را پشتیبانی می‌کند. به همراه آن یک image gallery هم جهت آپلود تصاویر ارائه می‌شود که بسیار ارزشمند است. اما مشکلی که دارد عدم بررسی پسوند فایل آپلود شده است. به عبارتی خاصیت AcceptedFileTypes آن هنگام آپلود تصاویر بررسی نمی‌شود و می‌تواند مشکلات امنیتی حادی را به وجود آورد (برای مثال شخص بجای تصویر می‌تواند فایل aspx را نیز آپلود کند). راه حلی هم برای آن وجود ندارد. سورس این کامپوننت فقط به خریداران ارائه می‌شود و نگارش مجانی آن بدون سورس است.

اما با استفاده از توانایی‌های موجود در فایل استاندارد global.asax می‌توان روی آپلود تمامی فایل‌ها در برنامه نظارت داشت (نه فقط این یک مورد بلکه سراسر برنامه تحت کنترل قرار می‌گیرد). روش کار به صورت زیر است:
protected void Application_BeginRequest(Object sender, EventArgs e)
{
        List<string> toFilter = new List<string> { ".aspx", ".asax", ".asp", ".ashx", ".asmx", ".axd", ".master", ".svc" };
        if (HttpContext.Current != null && HttpContext.Current.Request != null && HttpContext.Current.Request.Files != null)
            for (int i = 0; i < HttpContext.Current.Request.Files.Count; i++)
            {
                string fileNamePath = HttpContext.Current.Request.Files[i].FileName.ToLower();
                string name = Path.GetFileName(fileNamePath);
                string ext = Path.GetExtension(fileNamePath);
                if (toFilter.Contains(ext) || name == "web.config")
                {
                    HttpContext.Current.Response.StatusCode = 403; //Forbidden
                    HttpContext.Current.Response.End();
                }
            }
}
در این‌جا تمامی فایل‌های آپلودی بررسی شده و اگر پسوند خطرناکی داشتند، یک صفحه forbidden به شخص نمایش داده می‌شود و تمام!

این کد را به صورت Http module هم می‌توان درآورد.

‫۱۵ سال و ۶ ماه قبل، سه‌شنبه ۱۹ خرداد ۱۳۸۸، ساعت ۰۳:۱۰
وحید نصیری وحید نصیری
مطالب
انتقال فایل‌های دیتابیس اس کیوال سرور 2008

روز قبل نیاز بود تا فایل‌های mdf و ldf دیتابیس‌ها جابجا شوند (یک هارد بزرگتر و از این مسایل).
برای جابجا کردن این فایل‌ها هم روش معمول detach و سپس attach است. ابتدا روی دیتابیس کلیک راست کرده و detach . حالا فایل‌ها را جابجا می‌کنید و سپس attach . یا می‌شود بک آپ کامل گرفت و بعد ری استور کرد.
عموما هم نمی‌توان دیتابیس در حال استفاده را detach‌ کرد. باید دیتابیس ابتدا single user شود و بعد می‌توان این‌کار را انجام داد.
تا اینجای کار متداول است. همه چیز به خوبی انجام شد. سپس در لحظه attach ، دیتابیس‌ها به صورت read only اتچ شدند با آیکونی سیاه رنگ در management studio . (و رنگ من هم بلافاصله به همین رنگ متمایل شد!)
بعد از مدتی جستجو مشخص شد که در اس کیوال سرور 2008 برای کاهش سطح حمله به سرور، از یک سری یوزر با دسترسی کم برای نصب اس کیوال سرور استفاده می‌شود (بسیار هم خوب) و اس کیوال سرور 2008 ، یک سری یوزر مخصوص را هم در حین نصب ایجاد می‌کند که به صورت خودکار بر روی پوشه دیتای شما دسترسی full control دارد برای اینکه بتواند کارش را انجام دهد.
حال اگر شما در جای دیگری پوشه‌ای درست کردید و این دیتابیس‌ها را منتقل نمودید، مجددا پیش از هر کاری باید این دسترسی را برقرار کنید و گرنه اس کیوال سرور مجوز write نخواهد داشت؛ به همین جهت دیتابیس به صورت read only در management studio با رنگ مشکی ظاهر می‌شود.
نام این کاربر مخصوص به صورت زیر است:

SQLServerMSSQLUser$ComputerName$MSSQLSERVER




پس از برقراری دسترسی هم مشکل برطرف نمی‌شود. باید دستور زیر را نیز اجرا نمود:
ALTER DATABASE myDB SET READ_WRITE
اجرای این دستور نیز، نیاز به حالت single user دارد.

پ.ن.
می‌توان دسترسی یوزر سرویس اس کیوال سرور 2008 را نیز مانند نگارش‌های قبلی به حالت local system تغییر داد (یا هر اکانت دیگری با دسترسی بالا) تا این مشکلات نباشد؛ ولی بدیهی است سطح حمله به سرور نیز به همین اندازه افزایش می‌یابد.

‫۱۵ سال و ۶ ماه قبل، پنجشنبه ۲۴ اردیبهشت ۱۳۸۸، ساعت ۰۲:۲۷
وحید نصیری وحید نصیری
مطالب
لینک‌های هفته اول آذر

وبلاگ‌ها و سایت‌های ایرانی


Visual Studio


ASP. Net


طراحی وب


اس‌کیوال سرور


به روز رسانی‌ها


سی‌شارپ


عمومی دات نت


PHP



متفرقه



‫۱۵ سال و ۱۲ ماه قبل، پنجشنبه ۷ آذر ۱۳۸۷، ساعت ۰۴:۰۷
علی یگانه مقدم علی یگانه مقدم
مطالب
آشنایی با CLR: قسمت دهم
در سلسله مقالات قبلی ما فصل اول از بخش اول را به پایان بردیم و مبحث آشنایی با CLR و نحوه‌ی اجرای برنامه را یاد گرفتیم. در این سلسله مقالات که مربوط به فصل دوم از بخش اول است، در مورد نحوه‌ی ساخت و توزیع برنامه صحبت می‌کنیم.

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

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

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

دات نت فریمورک هم این معضل را به طور عادی در زمینه‌ی DLL hellدارد که در فصل آتی حل آن بررسی خواهد شد. ولی بر خلاف COM، نوع‌های موجود در دات نت نیازی به ذخیره تنظیمات در ریجستری ندارند؛ ولی متاسفانه لینک‌های میانبر هنوز وجود دارند. در زمینه امنیت دات نت شامل یک مدل امنیتی به نام Code Access security می‌باشد؛ از آنجا که امنیت ویندوز بر اساس هویت کاربر تامین می‌شود. code access security به برنامه‌های میزبان مثل sql server اجازه می‌دهد که مجوز مربوطه را خودشان بدهند تا بدین صورت بر اعمال کامپوننت‌های بار شده نظارت داشته باشند که البته این مجوز‌ها در حد معمولی و اندک هست. ولی اگر برنامه خود میزبان که به طور محلی روی سیستم نصب می‌شوند، باشد دسترسی کاملب به مجوزها را دارد. پس بدین صورت کاربر این اجازه را دارد که بر آن چیزی که روی سیستم نصب یا اجرا می‌شود، نظارت داشته باشه تا کنترل سیستم به طور کامل در اختیار او باشد.
در قسمت بعدی با نحوه توزیع برنامه آشنا خواهیم شد.
‫۹ سال و ۲ ماه قبل، دوشنبه ۲۶ مرداد ۱۳۹۴، ساعت ۰۱:۰۵
مسعود پاکدل مسعود پاکدل
مطالب
Senior Developer به چه کسی گفته می شود؟
چند وقت پیش با یک آگهی استخدام برنامه نویس به صورت زیر برخورد کردم:
      Senior Developer
      .Net Technologies
      Resume : ------------------------------------
آگهی بالا خلاصه‌ترین آگهی استخدامیه که می‌تونید ببنید و البته بیشتر هم در رشته کامپیوتر و مخصوصا جامعه برنامه نویسان رواج دارد.
احتمالا اکثر شما هم در آگهی‌های استخدام برنامه نویس، با واژه Senior Developer یا برنامه نویس ارشد برخورد داشته اید. حال به راستی به چه کسی برنامه نویس ارشد گفته می‌شود. یا بهتره بگم که چه زمانی ما می‌تونیم خودمون را یک برنامه نویس ارشد بدونیم؟
از آنجا که تعریف مشخصی برای این واژه‌ها در فرهنگ خاصی وجود ندارد و عموما هر کسی یک تعریف خاص با توجه به سلیقه خودش در این زمینه ارائه می‌دهد نمی‌توان یک شرح واحد از این واژه‌ها نظیر Senior Developer یا حتی Junior Developer ارائه داد. در نتیجه قصد دارم با توجه به تجربیات شخصی، این موارد رو تشریح کنم.
در خیلی موارد منظور از برنامه نویس ارشد، کسی است که:
  • در حداقل یک یا دو زبان برنامه نویسی تجربه داشته باشد؛
  • با تکنولوژی‌های مهم و کارآمد ارائه شده در آن زبان آشنایی کامل داشته باشد؛
  • توانایی استفاده از این تکنولوژی‌ها را در جای مناسب پروژه دارا باشد؛
  • با الگوهای برنامه نویسی (Design Pattern) آشنایی کامل داشته باشد؛
  • بتواند به سایر اعضای تیم در حل مشکلات و باگ‌های برنامه کمک کند؛
  • یک خطایاب قهار باشد(منظور این است با اکثر استثنائات و خطاهای متداول زبان و تکنولوژی که پروژه با آن پیاده سازی می‌شود آشنا باشد و بداند که چه زمان این خطا به وجود می‌آید و چگونه می‌توان این موارد را برطرف کرد)؛
  • باید با پیاده سازی سیستم‌های سرویس گرا (SOA) جدای از تکنولوژی پیاده سازی آن آشنایی کامل داشته باشد؛
  • باید با روش‌های تست و خطایابی و ابزار‌های توسعه و پیاده سازی آن آشنا بوده و توانایی استفاده از آن‌ها را در پروژه‌های خود داشته باشد؛
  • یک برنامه نویس ارشد باید در زمینه تخمین زمان تکمیل پروژه مهارت داشته باشد. باید بتواند مدت زمان لازم برای تکمیل یک Task را تخمین بزند و در همین مدت زمان، Task مربوطه را به صورت کامل پیاده سازی نماید.
  • در خیلی موارد باید بتواند هماهنگی لازم را بین اعضای تیم برنامه نویسی ایجاد نماید؛
  • و...

*ترتیب عبارات بالا دلیلی بر اولویت موارد ذکر شده نیست.

*منظور از آشنایی در عبارات بالا، یعنی تسلط و توانایی استفاده از آن با آگاهی تمام.

چه مدت زمان برای تبدیل شدن به یک برنامه نویس ارشد نیاز است؟

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

در پایان چهار ردیف یا رده مختلف را که بین برنامه نویسان رواج دارد ذکر می‌کنم.(از پایین به بالا)

Junior : عموما به کسی گفته می‌شود که 1 تا 3 سال تجربه برنامه نویسی دارد. معمولا کد‌های نوشته شده توسط این افراد باید بررسی شود چون احتمال اشتباه در آن زیاد است. اکثر کد‌های نوشته شده توسط این افراد به صورت dirty code است. راهنمایی هایی که به این افراد داده می‌شود شامل راهنمایی در زمینه ساختاری و الگوریتمی نیز می‌باشد. 

Mid-Level : برنامه نویسان در این رده بین 4 تا 6 سال تجربه دارند. می‌توانند به تنهایی نیز یک مشکل موجود در پروژه را حل نمایند. با مباحث مربوطه به طراحی کامپوننت آشنایی دارند و پروژه را بی نیاز از کامپوننت خواهند کرد. حتی در بعضی موارد می‌توانند به تنهایی یک پروژه در سطح کوچک با متوسط را توسعه دهند. 

Senior Developer : در بالا به صورت کامل شرح داده شد.

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

از این واژه کمتر در رده‌های برنامه نویسی استفاده می‌شود و بیشتر به همان واژه Senior Developer بسنده می‌کنند.

‫۱۱ سال و ۳ ماه قبل، جمعه ۴ مرداد ۱۳۹۲، ساعت ۱۷:۳۵