لیستی از پروژه‌هایی که با swift یا Objective-C در XCode نوشته شده است
یکی از چندین RequestHeaders دریافتی شما است. جائی مزاحمت ایجاد کرده بوده، در این لیست هست. اگر نیازی نیست، همانطور که عنوان شد از این لیست حذفش کنید تا پیام BadBotRequestHeader ای را که گرفتید، مشاهده نکنید.
اگر ویژگی BreadCrumb به قسمتی اعمال شود، در لیست نهایی وجود خواهد داشت و یا برعکس اگر بر روی قسمتی اعمال نشود، در لیست نهایی ذکر نمی‌شود.
متد GetCurrentlyExecutingJobs لیست jobهای موازی در حال اجرا را می‌دهد:
از نتیجه‌ی آن برای تصمیم گیری استفاده کنید؛ مثلا اگر این لیست خالی یا نال بود آنگاه job جاری اجرا شود.
var jobs = scheduler.GetCurrentlyExecutingJobs();
خیر. Products در اینجا خودش یک List است (به علت ارث بری صورت گرفته):
بنابراین نیازی نیست که لیست یک لیست رو به عنوان مدل تعریف کرد.
public class Products : List<Product>
خیر؛ چون customUsers یک لیست از کلاس ساخته شده توسط خودمه (اگه لیست از جنس int، string و ... رو داشته باشم این مشکل نیست)به خاطر همین اکسپشن میده و میگه نمیتونم Linq رو ترجمه کنم.
یه لیست قیمتی هر سال منتشر میشه. این لیست ریز شده به سابقه و تحصیلات و زمان و غیره.
- بله حق با شماست. اگه به نمونه کارهای بنده هم توجه بفرمایید، همه فایل‌های استاتیک رو روی یه زیردامنه ای به اسم cdn.site.com یا static.site.com هاست کردم. سعی میکنم منظورمو توی یه مطلب جداگانه ای واضح شرح بدم. فکر میکنم برای اینکه کامنتو کوتاه کنم، خیلی بد نوشتم و نتونستم منظورمو برسونم.
- باز هم حق با شماست. بنده هم عرض نکردم نمیشه هاست کرد. خود من هم قبلا اینکارو انجام دادم (روی سرور برتینا؛ اردیبهشت 90). ببینید، منظورم اینه که مثلا امروز اکثرمون Win 7 یا 8 رو سیستممون داریم یا بیشترمون مثلا VS 2012 نصب کردیم. کلا دارم عرض میکنم که همیشه گرایشمون به آپدیت بودن هست. با توجه به هزینه هاستینگ که واقعا همینطور داره میاد پایین و شرکتهایی که شدیدا با هم در رقابت هستن و گرایش‌های درونی خود ما برنامه نویس ها، فکر میکنم کمتر کسی پیدا بشه که امروز تمایل داشته باشه کلا هیچ سایتی رو (حالا MVC بودن یا نبودنش یه طرف) روی IIS 6 هاست بکنه. چند وقت پیش یادمه یه مطلبی نوشته بودید درباره چک لیست برنامه‌های MVC و اون تو یه جمله ای که خیلی خوشم اومد و تو ذهنم حک شد این مضمون بود که IE 6 و 7 رو به رحمت ایزدی بپیوندانیم D: من منظورم دقیقا در همین راستاست. بعنوان نمونه من دقیقا 2 روز پیش یه هاستی رو ثبت کردم که روی ویندوز سرور 2012 با SQLServer 2012 و دات نت 4.5 و IIS 8 با 1 گیگ فضا و پهنای باند نامحدود و 300 مگ رم، هزینه یک ساله ـش با یه دامنه com شد فقط 60 دلار. دسترسی ریموت به IIS و SQLServer هم میده و از Web Deploy هم پشتیبانی میکنه. خوب همین پکیج خیلی ارزونتر هم گیر میومد. ولی این شرکت معتبرتر بود، گرونتر میداد که گرونش اینقدر شد. نمیدونم تونستم منظورمو برسونم یا نه.
- با اجازتون یه مطلب کوتاهی در راستای پست شما و استفاده از UrlRewrite توی این آدرس نوشتم و مثال مورد نظرمو اونجا ذکر کردم. در مورد فایل‌های استاتیک و سایر موارد هم حتما بیشتر توضیح میدم.
با احترام فراوان. پاینده باشید.
- باز هم حق با شماست. بنده هم عرض نکردم نمیشه هاست کرد. خود من هم قبلا اینکارو انجام دادم (روی سرور برتینا؛ اردیبهشت 90). ببینید، منظورم اینه که مثلا امروز اکثرمون Win 7 یا 8 رو سیستممون داریم یا بیشترمون مثلا VS 2012 نصب کردیم. کلا دارم عرض میکنم که همیشه گرایشمون به آپدیت بودن هست. با توجه به هزینه هاستینگ که واقعا همینطور داره میاد پایین و شرکتهایی که شدیدا با هم در رقابت هستن و گرایش‌های درونی خود ما برنامه نویس ها، فکر میکنم کمتر کسی پیدا بشه که امروز تمایل داشته باشه کلا هیچ سایتی رو (حالا MVC بودن یا نبودنش یه طرف) روی IIS 6 هاست بکنه. چند وقت پیش یادمه یه مطلبی نوشته بودید درباره چک لیست برنامه‌های MVC و اون تو یه جمله ای که خیلی خوشم اومد و تو ذهنم حک شد این مضمون بود که IE 6 و 7 رو به رحمت ایزدی بپیوندانیم D: من منظورم دقیقا در همین راستاست. بعنوان نمونه من دقیقا 2 روز پیش یه هاستی رو ثبت کردم که روی ویندوز سرور 2012 با SQLServer 2012 و دات نت 4.5 و IIS 8 با 1 گیگ فضا و پهنای باند نامحدود و 300 مگ رم، هزینه یک ساله ـش با یه دامنه com شد فقط 60 دلار. دسترسی ریموت به IIS و SQLServer هم میده و از Web Deploy هم پشتیبانی میکنه. خوب همین پکیج خیلی ارزونتر هم گیر میومد. ولی این شرکت معتبرتر بود، گرونتر میداد که گرونش اینقدر شد. نمیدونم تونستم منظورمو برسونم یا نه.
- با اجازتون یه مطلب کوتاهی در راستای پست شما و استفاده از UrlRewrite توی این آدرس نوشتم و مثال مورد نظرمو اونجا ذکر کردم. در مورد فایل‌های استاتیک و سایر موارد هم حتما بیشتر توضیح میدم.
با احترام فراوان. پاینده باشید.
در بسیاری از زبان‌های برنامه نویسی امکان null بودن Reference types وجود دارد. به همین جهت مرسوم است پیش از استفاده از آن‌ها، بررسی شود آیا شیء مورد استفاده نال است یا خیر و سپس برای مثال متد یا خاصیت مرتبط با آن فراخوانی گردد؛ در غیر اینصورت برنامه با یک استثناء خاتمه خواهد یافت.
مشکلی هم که با این نوع بررسی‌ها وجود دارد این است که پس از مدتی کد موجود را تبدیل به مخزنی از انبوهی از if و else ها خواهند کرد که هم درجه‌ی پیچیدگی متدها را افزایش می‌دهند و هم نگهداری آن‌ها را در طول زمان مشکل می‌سازند. برای حل این مساله، الگوی استانداردی وجود دارد به نام null object pattern؛ به این معنا که بجای بازگشت دادن null و یا سبب بروز یک exception شدن، بهتر است واقعا مطابق شرایط آن متد یا خاصیت، «هیچ‌کاری» را انجام نداد. در ادامه، توضیحاتی در مورد نحوه‌ی پیاده سازی این «هیچ‌کاری» را انجام ندادن، ارائه خواهد شد.
الف) حین معرفی خاصیت‌ها از محافظ استفاده کنید.
برای مثال اگر قرار است خاصیتی به نام Name را تعریف کنید که از نوع رشته است، حالت امن آن رشته بجای null بودن، «خالی» بودن است. به این ترتیب مصرف کننده مدام نگران این نخواهد بود که آیا الان این Name نال است یا خیر. مدام نیاز نخواهد داشت تا if و else بنویسد تا این مساله را چک کند. نحوه پیاده سازی آن هم ساده است و در ادامه بیان شده است:
private string name = string.Empty;
public string Name
{
get { return this.name; }
set
{
if (value == null)
{
this.name = "";
return;
}
this.name = value;
}
}
دقیقا در زمان انتساب مقداری به این خاصیت، بررسی می‌شود که آیا مثلا null است یا خیر. اگر بود، همینجا و نه در کل برنامه، مقدار آن «خالی» قرار داده می‌شود.
ب) سعی کنید در متدها تا حد امکان null بازگشت ندهید.
برای نمونه اگر متدی قرار است لیستی را بازگشت دهد:
public IList<string> GetCultures()
{
//...
}
و حین تهیه این لیست، عضوی مطابق منطق پیاده سازی آن یافت نشد، null را بازگشت ندهید؛ یک new List خالی را بازگشت دهید. به این ترتیب مصرف کننده دیگری نیازی به بررسی نال بودن خروجی این متد نخواهد داشت.
ج) از متدهای الحاقی بجای if و else استفاده کنید.
پیاده سازی حالت الف زمانی میسر خواهد بود که طراح اصلی ما باشیم و کدهای برنامه کاملا در اختیار ما باشند. اما در شرایطی که امکان دستکاری کدهای یک کتابخانه پایه را نداریم چه باید کرد؟ مثلا دسترسی به تعاریف کلاس XElement دات نت فریم ورک را نداریم (یا حتی اگر هم داریم، تغییر آن تا زمانیکه در کدهای پایه اعمال نشده باشد، منطقی نیست). در این حالت می‌شود یک یا چند extension method را طراحی کرد:
public static class LanguageExtender
{
public static string GetSafeStringValue(this XElement input)
{
return (input == null) ? string.Empty : input.Value;
}
public static DateTime GetSafeDateValue(this XElement input)
{
return (input == null) ? DateTime.MinValue : DateTime.Parse(input.Value);
}
}
به این ترتیب می‌توان امکانات کلاس پایه‌‌ای را بدون نیاز به دسترسی به کدهای اصلی آن مطابق نیاز‌های خود تغییر و توسعه داد.
وبلاگ‌ها و سایت‌های ایرانی
Visual Studio
ASP. Net
طراحی وب
اس‌کیوال سرور
Nhibernate
عمومی دات نت
ویندوز
متفرقه
- JavaFX 1.0 منتشر شد. (بحث داغ این هفتهی مجامع جاوا بود)