اشتراکها
جواب ساده و کوتاه: خیر!
کدمدیریت شدهی شما در هر دو پلتفرم 32 بیتی - x86 و x64 بدون نیاز به هیچگونه تغییری و بدون نگرانی اجرا خواهد شد.
گزیدهای از MSDN :
اگر کد شما 100 درصد مدیریت شده است (managed code ایی که به صورت خالص از دات نت فریم ورک استفاده میکند و هیچگونه وابستگی خارجی دیگری به کتابخانههای دیگر ندارد)، تنها با کپی شدن در یک محیط x64 دارای CLR ایی 64 بیتی (دات نت فریم ورک 64 بیتی)، بدون هیچگونه مشکلی اجرا خواهد شد.
سؤال: چرا و چگونه؟!
کامپایلرهای دات نتی (تفاوتی نمیکند که چه زبانی مورد استفاده باشد)، کد شما را به IL ترجمه میکنند و IL اساسا درکی از پروسسور ندارد. JIT است که در آخرین لحظه در این مورد تصمیم گیری میکند.
این نگرانی از کجا حاصل شده است؟
نگارش R2 ویندوز 2008 سرور، فقط 64 بیتی خواهد بود و ویندوز سرور 2008 فعلی، آخرین سروری از مایکروسافت است که هر دو نسخهی 32 بیتی و 64 بیتی را دارد. بنابراین دیر یا زود تمام برنامه نویسهای ویندوزی "مجبور" خواهند شد دنیای 64 بیتی را تجربه کنند. (البته اگر تاکنون آنرا تجربه نکردهاند)
و البته هنوز یک سری از محیطهای توسعه، کامپایلر مخصوص 64 بیتی ندارند (مانند دلفی که قرار است در طول سال جاری اولین تجربهی 64 بیتی خود را ارائه دهد)
نکته:
در صفحهی build ویژوال استودیو، شما میتوانید نوع پلتفرم مورد نظر را نیز تعیین کنید:
پیش فرض آن بر روی Any CPU است و در این حالت کد کامپایل شدهی شما بدون مشکل بر روی پلتفرمهایی که مشاهده میکنید اجرا خواهد شد و تنها پیشنیاز اجرای آن، نصب نسخهی دات نت فریم ورک مخصوص آن پلتفرم است، بدون اینکه نیاز باشد برنامه نویس نگران جزئیات خاصی در مورد خصوصیات ویژهی آن پلتفرم ویژه باشد.
سؤال: اگر کد ما خالص نبود چطور؟ (منظور اینکه 100 درصد دات نتی نبود)
حالت الف) اگر از کامپوننتهای خارجی استفاده میکنید (حتی اگر 100 درصد دات نتی هم باشند) حتما اطمینان حاصل کنید که برای پلتفرم خاصی کامپایل نشدهاند (همان Any CPU مورد استفاده بوده)، زیرا کد شما که برای تمام CPU ها کامپایل شده، در محیط 64 بیتی، تنها توانایی بارگذاری اسمبلیهای 64 بیتی را خواهد داشت (64 بیتی رفتار میکند) و با مواجه شدن با اسمبلیهایی که برای یک پروسسور خاص دیگر کامپایل شدهاند، با خطای BadImageFormatException خاتمه مییابد.
حالت ب) استفاده از API ویندوز یا DLL های غیر دات نتی
باید با هماهنگی با تولید کنندهی مربوطه حتما از نگارش 64 بیتی استفاده شود و همچنین برنامهی شما باید توانایی استفاده از اشارهگرهای 64 بیتی را داشته باشد. اندازهی نوع دادهای IntPtr در یک محیط 32 بیتی 4 است و در یک محیط 64 بیتی 8 خواهد بود (IntPtr.Size). اگر در حین اجرای ترجمهی API یک کتابخانه به اشتباه بجای استفاده از IntPtr از int استفاده شده باشد، ممکن است کد شما در یک محیط 32 بیتی سالها بدون مشکل اجرا شود، اما در اولین اجرای خود در یک محیط 64 بیتی، کرش خواهد کرد. (بدلیل overflow حاصل)
IntPtr به اندازهی کافی هوشمند است تا سایز خودش را مطابق پلتفرم تنظیم کند و مشکل ساز نشود.
مثال:
[DllImport("kernel32.dll")]
public static extern void GetSystemInfo([MarshalAs(UnmanagedType.Struct)] ref SYSTEM_INFO lpSystemInfo);
[StructLayout(LayoutKind.Sequential)]
public struct SYSTEM_INFO
{
internal _PROCESSOR_INFO_UNION uProcessorInfo;
public uint dwPageSize;
public IntPtr lpMinimumApplicationAddress;
public int lpMaximumApplicationAddress;
public IntPtr dwActiveProcessorMask;
public uint dwNumberOfProcessors;
public uint dwProcessorType;
public uint dwAllocationGranularity;
public ushort dwProcessorLevel;
public ushort dwProcessorRevision;
}
[StructLayout(LayoutKind.Explicit)]
public struct _PROCESSOR_INFO_UNION
{
[FieldOffset(0)]
internal uint dwOemId;
[FieldOffset(0)]
internal ushort wProcessorArchitecture;
[FieldOffset(2)]
internal ushort wReserved;
}
- - لیست تازههای سرویس پک 2 آفیس 2007 (فقط برای نصب، درایوی که ویندوز بر روی آن نصب است باید نزدیک به 2 گیگ فضای خالی داشته باشد و گرنه در میانه نصب، متوقف خواهد شد؛ همانند نصب سرویس پک یک اس کیوال سرور 2008)
- - سرویس پکهایی که به زودی ارائه میشوند: Windows Server 2008 Service Pack 2 and Windows Vista Service Pack 2
مسیرراهها
WPF
- آغاز کار با WPF
- آشنایی با WPF قسمت اول : ساختار سلسله مراتبی
- آشنایی با WPF قسمت دوم: Layouts بخش اول
- آشنایی با WPF قسمت سوم: Layouts بخش دوم
- آشنایی با WPF قسمت چهارم: کنترل ها
- آشنایی با WPF قسمت پنجم : DataContext بخش اول
- آشنایی با WPF قسمت پنجم : DataContext بخش دوم
- آشنایی با WPF قسمت ششم : DataContext بخش سوم
- انقیاد دادهها در WPF بخش اول
- انقیاد دادهها در WPF بخش دوم
- آشنایی با الگوی M-V-VM- قسمت اول
- M-V-VM - قسمت دوم
- آشنایی با الگوی M-V-VM - قسمت سوم
- آشنایی با الگوی M-V-VM - قسمت چهارم
- آشنایی با الگوی M-V-VM - قسمت پنجم
- Expression Blend WPF Tutorial
- طول و عرض WPF
- آموزش رایگان XAML از مایکروسافت
- سری آموزشی PRISM
- ویدیوهای رایگان آموزشی WPF
- ارتقاء از WinForms به WPF
- خلاصهای کاربردی در مورد Observable collection
- دو تنظیم ضروری VS.NET جهت کار با WPF و Silverlight
- معرفی WPF Extended toolkit
- WPF و قالبهایی جهت کنترل DataGrid
- خلاصهای از مبحث نمایش اطلاعات hierarchical در WPF
- WPF4 و ویندوز 7 : به خاطر سپاری لیست آخرین فایلهای گشوده شده توسط برنامه
- نمایش یک فایل PDF در WinForms ، WPF و سیلورلایت
- چند نکته در مورد WPF MediaElement و ویندوز XP
- تعیین Fallback font برای قلمهای فارسی در WPF
- آموزش ایجاد برنامههای چند زبانه در WPF
- آشنایی و استفاده از WCF Data Services در Visualstudio 2012
- بارگذاری UserControl در WPF به کمک الگوی MVVM
- معماری لایه بندی نرم افزار #1
- معماری لایه بندی نرم افزار #2
- معماری لایه بندی نرم افزار #3
- معماری لایه بندی نرم افزار #4
- نحوه نمایش تمام آیکونهای تعریف شده در یک قلم در WPF
- نحوه استخراج آیکونهای یک قلم در WPF
- مقیدسازی (DataBinding) در WPF زمانی که دسترسی به DataContext وجود ندارد
- فراخوانی یک متداز یک کنترل WPF از XAML
- آشنایی با Catel MVVM Frameowork
- استفاده از ItemsControl جهت ساختن کنترلهای پویا در WPF
- ساخت فرمهای generic در WPF و Windows Application
- استفاده از #F در پروژههای WPF
- Markup Extensions در XAML
- Debug کردن Binding در XAML
- Bind کردن Enum به ItemsSource در XAML
- دسترسی به فیلدهای Static در XAML
- نگاهی به درون سیستم Binding در WPF و یافتن مواردی که هنوز در حافظهاند
- بهبود کارآیی کنترلهای لیستی WPF در حین بارگذاری تعداد زیادی از رکوردها
- چگونه تشخیص دهیم UI Virtualization در WPF خاموش شده است؟
- اضافه کردن امکان ویرایش WPF DataGrid در صورت نامعتبر بودن سلول ها
- انقیاد RadioButtonها در WPF به یک Enum
- یکی کردن اسمبلیهای یک پروژهی WPF
- بستن یک پنجره از طریق ViewModel با استفاده از خصوصیتهای پیوست شده هنگام استفاده از الگوی MVVM
- حرکت روی سلولهای دیتا گرید با فشردن کلید Enter در برنامههای WPF
- دسترسی به Collectionها در یک ترد دیگر در WPF
- آموزش WAF
- آموزش WAF (بررسی ساختار همراه با پیاده سازی یک مثال)
- آموزش WAF (بررسی Commandها)
- آموزش WAF (مشاهده تغییرات خواص ViewModel در Controller)
- تصادفی کردن آیتمهای لیست با استفاده از Extension Method
- استفاده از AvalonEdit در WPF
- فرمت شرطی اطلاعات به کمک تریگرها در WPF
- first chance exception چیست؟
- معرفی کتابخانهی OxyPlot
- معرفی DNTProfiler
- چگونه برنامههای دات نت را خارج از ویژوال استودیو دیباگ کنیم؟
- اسکرول روان لیستهای مجازی سازی شده در WPF 4.5
- پیاده سازی INotifyPropertyChanged با استفاده از Unity Container
در سری «مستند سازی ASP.NET Core 2x API توسط OpenAPI Swagger» با نحوهی تولید OpenAPI Specification، بر اساس کنترلرها و اکشن متدهای Web API خود آشنا شدیم و سپس با استفاده از ابزار Swagger-UI، یک رابط کاربری پویا را نیز برای آن تولید و سفارشی سازی کردیم. کاربرد OpenAPI Specification صرفا به مستندسازی یک Web API خلاصه نمیشود. بر اساس این استاندارد، ابزارهای متعددی جهت تولید کدهای سمت سرور و سمت کلاینت نیز طراحی شدهاند که در اینجا نمونهای از آنها را بررسی خواهیم کرد.
تولید خودکار کدها بر اساس OpenAPI Specification
فرض کنید در حال توسعهی برنامهی سمت کلاینت Angular و یا سمت سرور ASP.NET Core ای هستید که هر دوی اینها از یک Web API استفاده میکنند. همچنین فرض کنید که این Web API را نیز خودتان توسعه میدهید. بنابراین حداقل کدی که باید در اینجا به اشتراک گذاشته شود، کدهای کلاسهای DTO یا Data transfer objects هستند تا این کلاینتها بتوانند اطلاعات Web API را به نحو صحیحی Deserialize کنند و یا برعکس، بتوانند اطلاعات را با فرمت صحیحی به سمت Web API ارسال کنند.
برای مدیریت این مساله میتوان از دو روش استفاده کرد:
الف) استفاده از یک پروژهی اشتراکی
اگر کدهای مدنظر، سمت سرور باشند، میتوان یک پروژهی اشتراکی را برای این منظور ایجاد کرد و کدهای DTO را درون آن قرار داد و سپس ارجاعی به آن را در پروژههای مختلف، استفاده نمود. به این ترتیب تکرار کدها، کاهش یافته و همچنین تغییرات آن نیز به تمام پروژههای استفاده کننده به نحو یکسانی اعمال میشوند. در این حالت یک اسمبلی اشتراکی تولید شده و به صورت مستقلی توزیع میشود.
ب) استفاده از روش لینک کردن فایلها
در این روش پروژههای استفاده کننده از کلاسهای DTO، فایلهای آنرا به پروژهی خود لینک میکنند. در این حالت باز هم شاهد کاهش تکرار کدها و همچنین اعمال یک دست تغییرات خواهیم بود. اما در این روش دیگر یک اسمبلی اشتراکی وجود نداشته و کلاسهای DTO هم اکنون با اسمبلی پروژههای استفاده کننده، یکی و کامپایل شدهاند.
بدیهی است در هر دو روش، نیاز است بر روی کلاینت و API، کنترل کاملی وجود داشته باشد و بتوان به کدهای آنها دسترسی داشت. به علاوه فایلهای اشتراکی نیز باید بر اساس Target platform یکسانی تولید شده باشند. در این حالت دیگر نیازی به OpenAPI Specification برای تولید کدهای کلاینت دات نتی خود، نیست.
اما اگر کدهای API مدنظر در دسترس نباشند و یا بر اساس پلتفرم دیگری مانند node.js تولید شده باشد، کار یکپارچه سازی با آن دیگر با به اشتراک گذاری فایلهای آن میسر نیست. در این حالت اگر این API به همراه یک OpenAPI Specification باشد، میتوان از آن برای تولید خودکار کدهای کلاینتهای آن استفاده کرد.
معرفی تعدادی از ابزارهایی که قادرند بر اساس OpenAPI Specification، کد تولید کنند
برای تولید کد از روی OpenAPI Specification، گزینههای متعددی در دسترس هستند:
الف) Swagger CodeGen
این ابزار را که جزئی از مجموعه ابزارهای تولید شدهی برفراز OpenAPI است، میتوانید از آدرس swagger-codegen دریافت کنید. البته برای اجرای آن نیاز به Java Runtime است و یا نگارش آنلاین آن نیز در دسترس است: swagger.io
در ابزار آنلاین آن، در منوی generate بالای صفحه، گزینهی تولید کد برای #C نیز موجود است.
ب) AutoRest
محل دریافت: https://github.com/Azure/autorest
بر اساس node.js کار میکند و از طریق خط فرمان، قابل دسترسی است. همچنین این مورد ابزار تامین کنندهی گزینهی Add REST client در ویژوال استودیو نیز میباشد. اما در کل، امکان تنظیمات آنچنانی را به همراه ندارد.
ج) NSwagStudio
محل دریافت: https://github.com/RSuter/NSwag/wiki/NSwagStudio
همانطور که در مطلب «مستند سازی ASP.NET Core 2x API توسط OpenAPI Swagger - قسمت اول - معرفی» نیز عنوان شد، NSwag یکی دیگر از تولید کنندههای OpenAPI Specification مخصوص پروژههای دات نت است. NSwagStudio نیز جزئی از این مجموعه است که به کمک آن میتوان کدهای کلاینتها و DTOها را بر اساس OpenAPI Spec تولید کرد. همچنین امکان تنظیمات قابل توجهی را در مورد نحوهی تولید کدهای نهایی به همراه دارد.
استفاده از NSwagStudio برای تولید کدهای DTOها
در اینجا از همان برنامهای که در سری «مستند سازی ASP.NET Core 2x API توسط OpenAPI Swagger» بررسی کردیم، استفاده خواهیم کرد. بنابراین این برنامه، از پیش تنظیم شدهاست و هم اکنون به همراه یک تولید کنندهی OpenAPI Specification نیز میباشد. آنرا اجرا کنید تا بتوان به OpenAPI Specification تولیدی آن در آدرس زیر دسترسی یافت:
سپس فایل msi مخصوص NSwagStudio را نیز از لینک آن در Github دریافت، نصب و اجرا کنید.
مطابق تصویر، ابتدا آدرس Swagger Specification URL یا همان آدرس فوق را وارد کنید. سپس فضای نام دلخواهی را وارد کرده و گزینهی تولید کلاسهای کلاینت را فعلا انتخاب نکنید. در لیست تنظیمات آن، گزینهی Class Style نیز مهم است. برای مثال برای پروژههای ASP.NET Core حالت POCO را انتخاب کنید (plain old clr objects) و برای پروژههای مبتنی بر XAML، گزینهی Inpc مناسبتر است چون RaisePropertyChangedها را هم تولید میکند. در آخر بر روی دکمهی Generate Outputs کلیک کنید تا خروجی ذیل حاصل شود:
یا میتوان این خروجی را copy/paste کرد و یا میتوان در برگهی Settings، در انتهای لیست آن، مقدار output file path را مشخص کرد و سپس بر روی دکمهی Generate files کلیک نمود تا فایل معادل آن تولید شود.
استفاده از NSwagStudio برای تولید کدهای کلاینت Angular استفاده کنندهی از API
NSwagStudio امکان تولید یک TypeScript Client را نیز دارد:
نکتهی جالب این خروجی، دقت داشتن به status codes درج شدهی در OpenAPI Spec است که در قسمتهای چهارم و پنجم سری «مستند سازی ASP.NET Core 2x API توسط OpenAPI Swagger» آنها را بررسی کردیم.
در اینجا نه تنها سرویسی جهت تعامل با API ما تولید شدهاست، بلکه معادل تایپاسکریپتی DTOهای برنامه را نیز تولید کردهاست:
تولید خودکار کدها بر اساس OpenAPI Specification
فرض کنید در حال توسعهی برنامهی سمت کلاینت Angular و یا سمت سرور ASP.NET Core ای هستید که هر دوی اینها از یک Web API استفاده میکنند. همچنین فرض کنید که این Web API را نیز خودتان توسعه میدهید. بنابراین حداقل کدی که باید در اینجا به اشتراک گذاشته شود، کدهای کلاسهای DTO یا Data transfer objects هستند تا این کلاینتها بتوانند اطلاعات Web API را به نحو صحیحی Deserialize کنند و یا برعکس، بتوانند اطلاعات را با فرمت صحیحی به سمت Web API ارسال کنند.
برای مدیریت این مساله میتوان از دو روش استفاده کرد:
الف) استفاده از یک پروژهی اشتراکی
اگر کدهای مدنظر، سمت سرور باشند، میتوان یک پروژهی اشتراکی را برای این منظور ایجاد کرد و کدهای DTO را درون آن قرار داد و سپس ارجاعی به آن را در پروژههای مختلف، استفاده نمود. به این ترتیب تکرار کدها، کاهش یافته و همچنین تغییرات آن نیز به تمام پروژههای استفاده کننده به نحو یکسانی اعمال میشوند. در این حالت یک اسمبلی اشتراکی تولید شده و به صورت مستقلی توزیع میشود.
ب) استفاده از روش لینک کردن فایلها
در این روش پروژههای استفاده کننده از کلاسهای DTO، فایلهای آنرا به پروژهی خود لینک میکنند. در این حالت باز هم شاهد کاهش تکرار کدها و همچنین اعمال یک دست تغییرات خواهیم بود. اما در این روش دیگر یک اسمبلی اشتراکی وجود نداشته و کلاسهای DTO هم اکنون با اسمبلی پروژههای استفاده کننده، یکی و کامپایل شدهاند.
بدیهی است در هر دو روش، نیاز است بر روی کلاینت و API، کنترل کاملی وجود داشته باشد و بتوان به کدهای آنها دسترسی داشت. به علاوه فایلهای اشتراکی نیز باید بر اساس Target platform یکسانی تولید شده باشند. در این حالت دیگر نیازی به OpenAPI Specification برای تولید کدهای کلاینت دات نتی خود، نیست.
اما اگر کدهای API مدنظر در دسترس نباشند و یا بر اساس پلتفرم دیگری مانند node.js تولید شده باشد، کار یکپارچه سازی با آن دیگر با به اشتراک گذاری فایلهای آن میسر نیست. در این حالت اگر این API به همراه یک OpenAPI Specification باشد، میتوان از آن برای تولید خودکار کدهای کلاینتهای آن استفاده کرد.
معرفی تعدادی از ابزارهایی که قادرند بر اساس OpenAPI Specification، کد تولید کنند
برای تولید کد از روی OpenAPI Specification، گزینههای متعددی در دسترس هستند:
الف) Swagger CodeGen
این ابزار را که جزئی از مجموعه ابزارهای تولید شدهی برفراز OpenAPI است، میتوانید از آدرس swagger-codegen دریافت کنید. البته برای اجرای آن نیاز به Java Runtime است و یا نگارش آنلاین آن نیز در دسترس است: swagger.io
در ابزار آنلاین آن، در منوی generate بالای صفحه، گزینهی تولید کد برای #C نیز موجود است.
ب) AutoRest
محل دریافت: https://github.com/Azure/autorest
بر اساس node.js کار میکند و از طریق خط فرمان، قابل دسترسی است. همچنین این مورد ابزار تامین کنندهی گزینهی Add REST client در ویژوال استودیو نیز میباشد. اما در کل، امکان تنظیمات آنچنانی را به همراه ندارد.
ج) NSwagStudio
محل دریافت: https://github.com/RSuter/NSwag/wiki/NSwagStudio
همانطور که در مطلب «مستند سازی ASP.NET Core 2x API توسط OpenAPI Swagger - قسمت اول - معرفی» نیز عنوان شد، NSwag یکی دیگر از تولید کنندههای OpenAPI Specification مخصوص پروژههای دات نت است. NSwagStudio نیز جزئی از این مجموعه است که به کمک آن میتوان کدهای کلاینتها و DTOها را بر اساس OpenAPI Spec تولید کرد. همچنین امکان تنظیمات قابل توجهی را در مورد نحوهی تولید کدهای نهایی به همراه دارد.
استفاده از NSwagStudio برای تولید کدهای DTOها
در اینجا از همان برنامهای که در سری «مستند سازی ASP.NET Core 2x API توسط OpenAPI Swagger» بررسی کردیم، استفاده خواهیم کرد. بنابراین این برنامه، از پیش تنظیم شدهاست و هم اکنون به همراه یک تولید کنندهی OpenAPI Specification نیز میباشد. آنرا اجرا کنید تا بتوان به OpenAPI Specification تولیدی آن در آدرس زیر دسترسی یافت:
https://localhost:5001/swagger/LibraryOpenAPISpecification/swagger.json
مطابق تصویر، ابتدا آدرس Swagger Specification URL یا همان آدرس فوق را وارد کنید. سپس فضای نام دلخواهی را وارد کرده و گزینهی تولید کلاسهای کلاینت را فعلا انتخاب نکنید. در لیست تنظیمات آن، گزینهی Class Style نیز مهم است. برای مثال برای پروژههای ASP.NET Core حالت POCO را انتخاب کنید (plain old clr objects) و برای پروژههای مبتنی بر XAML، گزینهی Inpc مناسبتر است چون RaisePropertyChangedها را هم تولید میکند. در آخر بر روی دکمهی Generate Outputs کلیک کنید تا خروجی ذیل حاصل شود:
یا میتوان این خروجی را copy/paste کرد و یا میتوان در برگهی Settings، در انتهای لیست آن، مقدار output file path را مشخص کرد و سپس بر روی دکمهی Generate files کلیک نمود تا فایل معادل آن تولید شود.
استفاده از NSwagStudio برای تولید کدهای کلاینت Angular استفاده کنندهی از API
NSwagStudio امکان تولید یک TypeScript Client را نیز دارد:
در اینجا ابتدا TypeScript Client را انتخاب میکنیم و سپس در تنظیمات آن، قالب Angular را انتخاب کرده و نگارش RxJS آنرا نیز، 6 انتخاب میکنیم. در آخر بر روی Generate outputs کلیک میکنیم:
نکتهی جالب این خروجی، دقت داشتن به status codes درج شدهی در OpenAPI Spec است که در قسمتهای چهارم و پنجم سری «مستند سازی ASP.NET Core 2x API توسط OpenAPI Swagger» آنها را بررسی کردیم.
در اینجا نه تنها سرویسی جهت تعامل با API ما تولید شدهاست، بلکه معادل تایپاسکریپتی DTOهای برنامه را نیز تولید کردهاست:
نظرات مطالب
خلاصهای کوتاه در مورد WinRT
سلام فقط امکان استفاده از دات نت کور هستش؟ نمیشه برای برنامههای دات نت فریمورک هم استفاده کنیم؟
وبلاگها ، سایتها و مقالات ایرانی (داخل و خارج از ایران)
- مروری بر Delphi 2009 و مهاجرت به آن
- تصحیح خودکار کلمات فارسی در برنامه اپنآفیس
- دانلود عکس از سایت
- ۱۰ قانون برای نوشتن در وب
- استفاده از SQL Server در PHP
- بلوهاست و ایران
- سورس و گزارش پروژه فارسی نت منتشر شد
- درون یک ISP چه می گذرد؟
- تابعهای جادویی PHP 5
- راهنمای کوچک همکاری در پروژههای بازمتن
- nsis قدرتمندتر از آنچه یک نصب کننده نرم افزار نیاز دارد!
- چند اشتباه رایج در طراحی وب
امنیت
Visual Studio
ASP. Net
طراحی و توسعه وب
PHP
اسکیوال سرور
سی شارپ
VB
CPP
عمومی دات نت
مسایل اجتماعی و انسانی برنامه نویسی
- چه برنامهنویسهایی را استخدام نکنید؟
- چرا خانمها کمتر در پروژههای سورس باز ظاهر میشوند؟!
- IE6 را نمیخواهیم!
متفرقه
وبلاگها و سایتهای ایرانی
Visual Studio
ASP. Net
طراحی وب
اسکیوال سرور
Nhibernate
عمومی دات نت
ویندوز
متفرقه
- JavaFX 1.0 منتشر شد. (بحث داغ این هفتهی مجامع جاوا بود)