مروری بر خانواده (Windows Embedded) شرکت مایکروسافت

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

مایکروسافت رسما در ماه نوامبر سال 1996 با انتشار ویندوز Embedded CE 1.0 وارد بازار این سیستم های عامل شد. از آن به بعد ، مایکروسافت تبدیل به یک خط کامل از گسترش و تولید این نسهخل از سیستم عامل شده است ، این شرکت باعث شده تا توسعه دهندگان و سازندگان دستگاه های مبتنی بر این سیستم های عامل قادر به ساخت نسل بعدی دستگاه های 32 بیتی شوند و به بعد از ساخت نسل جدید این دستگاه ها ساخت و تولید طیف وسیعی از محصولات و ابزار های این دستگاه ها.

اولین نسخه ها از سیتم عامل های Embedded را در سیستم های ([1]POS) می توان جستجو کرد و بعد از آن با ورود نسخه NT از این سیستم عامل ها این سیستم عامل ها را با نام Xpembedded (XP Embedded) صدا می زدند.

در زیر به تعدادی از ورژن های سیستم عامل های Embedded که توسط شرکت مایکروسافت در حال حاضر تولید می گردد اشاره می شود:

· Windows Embedded CE (Windows Embedded Compact)

یک سیستم عامل (Real Time ) [2]برای ارائه تجربیات مهارت ها و قابلیت های کار آزموده به طیف وسیعی از کاربران مبتدی با سطح دانش و توانایی های پایین و همچنین کاربران حرفه ای و انواع دستگاه هایی که برپایه این گونه سیستم های عامل طراحی شده اند. از نسخه برای استفاده در کامپیوتر های بسیار کوچک و کارگذاشته شده (لوازم الکترونیکی ، تجهیزات الکترونیکی ، کنسول های بازی) استفاده می شود. این سیتم عامل از معماری پردازنده های ARM , MIPS , SuperH , x86 پشتیبانی می کند. برای مثال می توان به نسخه بسیار مخصوص این سیستم عامل که همان Windows Mobile می باشد می توان اشاره کرد که هم اکنون در بسیاری از تلفن های همراه استفاده می شود.

· Windows Embedded Standard

این نسخه از سیستم عامل های Embedded همان نسخه بروز شده Windows XP Embedded و جانشین موفق Windows NT 4.0 Embeddedمی باشد که می توان گفت از تمامی کامپوننت های Windows XP Professional به همراه تمامی توابع API ، Win32 در آن استفاده شده است. در این سیستم عامل معماری های x86 و x64 پشتیبانی می شود و می توان از نرم افزار های زیر استفاده کرد :

Silverlight, .NET Framework 3.5, Internet Explorer 7, Windows Media Player 11, RDP 6.1, Network Access Protection, Microsoft Baseline Security Analyze

· Windows Embedded Automotive

این نسخه در دستگاه ها و سخت افزار هایی در خودرو ها و یا وسایل نقلیه مورد استفاده قرار می گیرد . در این سیستم عامل نرم افزار های استانداردی برای سرگرمی ، ارتباطات ، یکپارچگی ، آزمایشات و سرویس های متفاوتی که در وسایل نقلیه و خودرو ها مورد نیاز می باشد به همراه صد ها کامپوننت موجود در سیستم عمل Windows Embedded CE R3 6.0 جاسازی شده است. این ویندوز باعث شده تا شرکت های خودرو سازی سبک جدیدی از زندگی را به مشتریان خود ارائه دهند.

· Windows Embedded POSReady

Next generation of Windows Embedded Point of Service

این سیستم عامل با قابلیت اتصال به ابزار های صنعت خرده فروشی برای بهینه سازی و منعطف کردن این صنعت تولید شده است. سیستم عامل Windows Embedded Point of service یک نسخه مخصوص از سیستم عامل Windows XP Embedded می باشد که برای تمرکز بر بازار دستگاه های (POS) که در بالا به آن اشاره شد در تاریخ 25 می سال 2005 توسط شرکت مایکروسافت تولید شد ( مانند دستگاه های پمپاژ سوخت ، ایستگاه های وارسی و دستگاه های ثبت دریافت پول نقد در فروشگاه ها )

· Windows Embedded HandHeld

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

· Windows Embedded Enterprise

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

· Windows Embedded NAVReady

در این نسخه از ویندوز Embedded که به نام NavReady می باشد مجموعه ای از ابزار های توسعه موجود می باشد که به شما اجازه می دهد تا به سادگی از دستگاه های دستی قابل حمل (PNDs) استفاده کنید و به شما اجازه می دهد تا از امکاناتی مانند اتصال به خدمات آنلاین ، بلوتوث (برای قادر بودن در اتصال به تلفن های همراه) و رایانه های شخصی و اینترنت می باشد.  پایه و اساس این نسخه بر روی Windows Embedded CE بنا شده است .

· Windows Embedded Server

و اما در نهایت نسخه سرور این ویندوز ها که یک نسخه کاملا کاربردی از سری سیستم عامل های سرور مایکروسافت که دارای مزایای امنیت ، قابلیت اطمینان می باشد و همچنین دارای امکانات در دسترس برای استفاده در راه حل های (Embedded) شده که متشکل از سخت افزار به منظور ساخت نرم افزار و برنامه در نظر گرفته شده است. ویندوز سرور (Embedded) شده است مورد استفاده برای ایجاد طیف گسترده ای از راه حل های سرور از جمله تصویربرداری پزشکی ، امنیتی و نظارتی ، اتوماسیون صنعتی و ارتباطات از راه دور می باشد.

---

[1] Point Of Sale مکان هایی که در آن ها تراکنش های مالی (خرید ، فروش) صورت می گیرد و تلاش می شود برای مدیریت این تراکنش ها از سخت افرا و نرم افزار ها کمک گرفت

[2] سیستم عامل های بی درنگ سیستم عامل هایی هستند که برای نرم افزارهای بی درنگ مورد استفاده قرار می گیرند به این صورت که نیاز نرم افزار ها در لحظه داده می شود و بلا درنگ.(مقصد)

C# 4 is not .Net 4

خوشبختانه بر خلاف انتظاری که داشتیم. برنامه هایی که با نسخه 4 از زبان #C نوشته می شوند، می توانند به صورتی نوشته و کامپایل شوند که برای اجرا مستلزم وجود همین نسخه از .Net Framework نباشند. برای مثال یک برنامه با C# 4.0 نوشته شود که بر روی .Net 3.5 اجرا شود.

وقتی در C# 4.0 از ویژگی های Named and Optional Parameters که به تازگی در نسخه 4 آمده است، استفاده شود، مثلا وقتی یک متد به این صورت تعریف شود:

public static void Test(int a, int b = 2, int c = 5)

در حالی که Traget Framework روی .Net 3.5 تنظیم شده باشد، خروجی برنامه بر روی .Net 3.5 بدون هیچ مشکلی و بدون نیاز به نصب .Net 4.0 اجرا می شود. بنابر این با خیال آسوده از ویژگی Named and Optional Parameters در C# 4.0 استفاده کنید و لذت ببرید.

البته در مورد dynamic اوضاع به همین ترتیب نیست، برای استفاده از آن باید از اسمبلی Microsoft.CSharp نسخه 4.0 استفاده کرد. و همینطور در مورد Covariant و Contravariant نیز به همین منوال است.

پی نوشت 1: با توجه به اینکه ویژگی Optional Parameter در C/C++ وجود داشت و جای خالی آن از ابتدا در #C حس می شد، می توان به طراحان این زبان خرده گرفت که اگر قرار بود این ویژگی اضافه شود چرا از ابتدا اضافه نشد؟ که البته دو حالت بیشتر وجود ندارد؛ 1. شیطنت های سیاسی و اقتصادی 2. اشتباه انسانی. در هر حال همین الان هم دیر نیست، دستشان درد نکند.

پی نوشت 2: هر چند، در کل! چون .Net 4.0 حجمی در حدود 45 مگا بایت دارد، مطمئناً استفاده از همین Framework خیلی بهتر و آبرومندتر است.

پی نوشت 3: این پست بعد از تعدادی آزمایش برای نوع dynamic و covariant و contravariant به کلی ویرایش شده است.

Entity Framework (مقدمه)

در زمانی که با Linq to SQL آشنا شدیم نام Entity Framework را نیز شنیدیم. اما بعد از بررسی متوجه شدیم که (نسخه آن زمان) Entity Framework در ظاهر مانند Linq to SQL است و تنها حسنی که دارد امکان برقراری ارتباط با بانکهای اطلاعاتی مختلف مانند Oracle، MySQL و … است ولی در باطن Entity Framework از بعضی از توابع مهم که در Linq to SQL پشتیبانی می شد، پشتیبانی نمی کرد. مانند Conatins یا Any که کاربرد بسیاری در نوشتن Query های جستجو دارد.

البته در آن زمان به این ویژگی مهم Entity Framework پی نبردیم که قابلیت پوشانیدن جزئیات بانک اطلاعات و ارائه یک مدل کاملا Conceptual را دارد. به عنوان مثال ما برای پیاده کردن یک ارتباط Many to Many در بانک اطلاعات از یک جدول سوم استفاده می کنیم که کلید های دو جدول دیگر را در خود نگهداری میکند. وقتی همین جداول توسط Entity Framework نگاشته (Map) می شود، فقط دو Entity با ارتباط Many to many به یکدیگر را خواهیم داشت که این شروع دید Conceptual است؛ درگیری با جزئیات کم و کمتر می شود و در عوض جای خود را به تفکر بر روی طراحی می دهد.

مفاهیم بسیار عمیق شی گرایی، در Entity Framework کاملا و واقعا قابل استفاده است! و این بزرگترین ویژگی آن به حساب می آید. برای مثال ارثبری می تواند یک مورد بسیار پر کاربرد باشد که دنیای ارتباط با بانک های اطلاعاتی رابطه ای (Relational یا RDBMS) را تغییر داده. و متاسفانه یا خوشبختانه باعث شده که شرکت های بزرگ نرم افزاری، فکر ایجاد بانک اطلاعاتی شی گرا (ODBMS) را بیشتر از خود دور کنند.

در 23 فروردین نسخه نهایی .Net Framework 4.0 به همراه Visual Studio 2010 ارائه می شود که Entity Framework 4.0 نیز یکی از معجزه های ارائه شده در این محصول است. (مدتی است که نسخه RC قابل دریافت است) و به گفته بسیاری، مایکروسافت با شنیدن و سنجیدن نظرات و پیشنهادات توسعه دهندگان نرم افزار های Model-Driven و Data-Driven ویژگی های Entity Framework را کامل کرده و در حال روانه کردن آن به بازار است.

مانند همیشه، ابزارها به سمتی می روند که تفکرِ بیشتر جای کار عملیِ (کد زدن و…) بیشتر را بگیرد. وقتی ما برای اولین بار به صورت واقعی از مفاهیم شی گرا در EF 4.0 استفاده کردیم. چند ده برابر اینکه روی موشواره (Mouse) کلیک کنیم یا بر روی صفحه کلید (Keyboard) تایپ کنیم، تفکر کردیم و با سرعت بیشتری به هدفی که مورد نظرمان بود رسیدیم.

به زودی یک یا دو پست در مورد EF با مثال کاربردی و عملی خواهیم داشت؛ چون برای اولین بار با نسخه غیر رسمی (RC یا Beta) یک نرم افزار (.Net 4.0 و EF 4.0 و VS 2010 و …) مشغول ایجاد یک پروژه تجاری واقعی هستیم و طبق برنامه ریزی که کرده بودیم تا قبل از اتمام پروژه، نسخه نهایی (Release) از .Net 4.0 به بازار خواهد آمد.

این یک ریسک بزرگ ولی با ارزش است!

C# Preprocessor Directives

شاید تا به حال برایتان پیش آمده باشد که در یک پروژه بعد از پیاده سازی احتیاج پیدا کنید نسخه های متفاوتی از آن نرم افزار داشته باشید البته منظور از نسخه این است که در یک نسخه تعدادی از خطوط (Compile) شوند و در نسخه دیگر نشوند ، راهی که می خواهم معرفی کنم کمک زیادی برای حل این مشکل است (حد اقل برای ما که همینطور بود) .

شاید تا الان برای این کار کد های خودتان را (Commnet) می کردید و بعد از ساختن نسخه مورد نظر برای ساخت نسخه های دیگر کد های (Commnet) شده را (UnCommnet) می کردید و نسخه های بعدی …این کار هم غیر استاندارد است و هم دارای درصد خطای بسیار بالا و بسیاری از ایراد های دیگر و برای عبور از همه ی این موانع ما به شما استفاده از (Preprocessor Directives) را توصیه می کنیم و از این به بعد به جای (Preprocessor Directives) از (PD) استفاده می کنیم .

“دستورالعمل های پیش پردازنده” شاید این متن ترجمه مناسبی نباشد اما منظور را میرساند . این دستورالعمل ها باعث می شوند که روند (Compile) خطوط برنامه را بر اساس یک سری شرط تنظیم کنید .

حالا وقتشه که با لیست این (Preprocessor Directives) ها در #C آشنا شوید :

• #if
• #else
• #elif
• #endif
• #define
• #undef
• #warning
• #error
• #line
• #region
• #endregion

خوب از اول لیست شروع می کنیم :

if# , #else , #endif , #elif :

همان کاری را انجام می دهد که همیشه انجام می داده . خطوطی که ما بین

(if#) و (endif#) قرار میگیرد در صورت نیاز شما توسط (Compiler) محسابه می شود و در غیر این صورت محسابه نمی شود . (elif#) همان (else if) خودمان است .

define# :

این (PD) تقریباً اصل مطلب حساب می شود چون زمانیکه شما با بقیه (PD) ها تنظیمات دلخواه خود را انجام داده اید با مشخص کردن (define#) تنظیمات شما مورد توجه (Compiler) قرار میگیرد و کد مورد نظر شما (Compile) میشود و در صورت نبودن (define#) کدهای شما توسط (Compiler) محسابه نمی شوند .

*نکته :

(define#) باید بالای تمام (using) های استفاده شده در فایل باشد.

// preprocessor_if.cs 
#define DEBUG #define VC_V7 
using System; 
public class MyClass 
{   
    public static void Main()
    {
        #if (DEBUG && !VC_V7)
        Console.WriteLine("DEBUG is defined");
        #elif (!DEBUG && VC_V7
        Console.WriteLine("VC_V7 is defined");
        #elif (DEBUG && VC_V7)
        Console.WriteLine("DEBUG and VC_V7 are defined");
        #else
        Console.WriteLine("DEBUG and VC_V7 are not defined");
        #endif
    }
}

Output :

DEBUG and VC_V7 are defined

همانطور که در بالا میبینید بعد از (define#) یک نام نیز برای آن مشخص می کنیم که بهتر است با حروف بزرگ مشخص شود مانند (DEBUG) و سپس در قسمت مورد نیاز که همان دستورات شرطی می باشد از آن استفاد می کنیم .

undef# :

کاری که (define#) انجام میدهد یعنی باعث می شود کد شما مورد توجه (Compiler) قرار بگیرد دقیقاً برعکس کنید ، وظیفه (undef#) یعنی کد شما مورد توجه (Compiler) قرار نمیگیرد و به محسابه نمی شود .

warning# , #error :

با این دو (PD) کد می توانید کاری کنید که در یکی از( Tool Windows) ها به اسم (Error List) که وظیفه نمایش (Error) ها ، (Warning) ها و (Message) ها را دارد پیغام شما را به صورت یک (Warning) یا (Error) بنا بر اینکه شما از کدام یک استفاده کرده باشید نمایش بدهد تا بعد ها بتوانید به راحتی قسمت کد مورد نظرتان را بعد از (Build) کردن پروژه پیدا کنید .

// preprocessor_if.cs
#define DEBUG
using System;
public class MyClass
{
    public static void Main()
    {
        #warning Custom Warning
        #error Custom Warning
        Console.WriteLine("DEBUG and VC_V7 are not defined");
        #endif
    }
}

line# :

به شما اجازه می دهد تا (Compiler) را در هنگام (Compile) کردن به خطی که مورد نظر شما ست برود و بعد از گذشتن از آن خط دوباره به روال عادی خود بازگردد که در این مورد برای بازگشت به روال قبل استفاده از (line default#) این امکان را ایجاد می کند .

#line 20
#line default

(line# default) مشخص می کند که Compiler بعد از رفتن به خط (20) به کجا بازگردد .

یک استفاده دیگر هم میتوان از آن کرد که به صورت زیر می باشد :

Console.WriteLine("Hidden line.");
#line default
Console.WriteLine("Normal line #2.");

بعد از قرار دادن (BreakPoint) بر روی خطی که متن (“Hidden line”) را در خروجی درج می کند متوجه می شوید که با زدن (F10) هیچگاه به آن نمی رسید . خاصیت این (PD) همین است.

region# , #endregion :

فکر کنم با این (PD) بیشتر از بقیه آشنا هستید . همانطور که بهتر از من میدانید میتوانید با نوشتن (region#) در ابتدای کد هایتان و در انتها هم با نوشتن (endregion#) به کد های خود خوانایی بیشتری ببخشید و آن قسمت از کدها که با این (PD) مشخص کردید رآ تبدیل به یک بلوک از کد کنید و با (Expand) کردن بلوک را باز کنید و سپس بلوک را ببندید و بعد از بستن بلوک تنها تیتر آن مشاهده می شود .

// preprocessor_if.cs
#region MyClass definition
public class MyClass
{
    public static void Main()
    {
    }
}
#endregion

حالا شاید پیش خودتون بگید که برای ساختن نسخه های دلخواه خودتون باید بالای هر فایلی که داخل اون از (PD) استفاده کردین مدام (define#) بنویسید و پاک کنید ?! ولی نه خیلی بهتر از این حرفاست :

روی Solution Configuration کلیک کنید .

بعد از باز شدن زیر منوها گزینه Configuration Manager رو انتخاب کنید .

همونطور که توی عکس نشون داده شده رو ComboBox زیر Active Solution Configuration کلیک کنید و از منوی باز شده گزینه New رو انتخاب کنید .

حالا کافیه در این قسمت نام هایی رو که فکر می کردین باید بالای هر فایلتون (define#) کنید رو اینجا بسازید تا بهتون اجازه بده به ازای هر اسمی که می سازید یک Setting جدا برای Compile شدن پروژه هاتون داشته باشید.

فقط یه نکته دیگه باقی میمونه و اون هم اینه که شما به (VS) بفهمونید که زمانیکه (Configuration) را ، شما روی هر حالت که قرار میدید کدام یک از (PD) هایی که شما در آن پروژه قرار داده اید فعال گردد برای این کار روی پروژه هایی که می خواید روی مد دلخواه شما Compile بشه چپ کلیک کنید و وارد Properties اون پروژه بشید :

سپس در گزینه (Conditional Compilation Symbols) نام (Solution Configuration) ی که نمونه اون رو در بالا ساختیم بنویسید به همین ترتیب برای پروژه های دیگه هم همین کار رو انجام بدید تا مشخص بشه هر پروژه بنا به (Active Solution Configuration) از چه تنظیماتی برای Compile شدن پیروی کند.

From MAC OS X 10.5 to iPad to Prohibition

از زمانی که خبر تولید iPad پخش شد ما هم کنجکاو شدیم ببینیم اصلا این پلتفرم های Apple چگونه اند! آیا واقعا همانند Unix هستند یا خیر!؟

برای شروع برنامه سازی برای iPad خواستیم برای iPhone برنامه بسازیم و مطلع شدیم که بهترین زبان در این مورد زبان Objective-C می باشد که بسیار هم زبان چموشی به نظر می رسد. من به شخصه این زبان را نمی پسندم و احساس می کنم که به زور خواستند یک سری Extension را به خورد C/C++ بدهند.

چند وقتی است که Novell یک محصول به نام MonoTouch را معرفی کرده. با استفاده از آن می توان برنامه هایی Native برای iPhone نوشت، اما، به زبان C# و با استفاده از امکانات محدودتر شده از کتابخانه .Net به اضافه امکان استفاده از تمامی API های iPhone و از همه مهمتر با حظور Garbage Collector! البته این محصول مجانی نیست. مهمترین نکته در مورد آن این است که برنامه تولید شده توسط این ابزار Native است و بدون نیاز به نصب هیچ افزونه ای اجرا می شود. و با توجه به اینکه حتی خود Apple هم امکان GC را برای iPhone قرار نداده، وجود GC در این ابزار بسیار قابل توجه است. شاید تنها نقطه ضعف آن این است که حجم یک برنامه Hello Word که به وسیله MonoTouch ایجاد شده حدود 4MB خواهد بود. که این موضوع هم به دلایل بسیاری می تواند قابل چشم پوشی باشد (البته بسته به کاربرد).

وقتی فهمیدیم که MonoTouch به خوبی iPad را هم پشتیبانی می کند دیگر قانع شدیم که کلید برنامه نویسی راحت و تمیز برای iPad در دست MonoTouch است. برای آزمایش MonoTouch نسخه ی Trial آن وجود دارد. اما نصب و راه اندازی آن، کم پیش نیاز ندارد!

پیش نیاز ها به ترتیب عبارتند از:

• سیستم عامل MAC OS X
• iPhone SDK
• Mono Framework
• MonoDevelop

نصب MAC OS X بر وری VMWare خودش داستانی است که شاید یک پست دیگر می طلبد، خود ما هم از اینجا کمک گرفتیم. بارها صفحه بالا آمدن MAC با آن سیب گاز زده را دیدیم ولی حتی محیط نصب هم بالا نیامد!

اما در آخر موفق شدیم.

در مورد iPhone SDK ظاهرا Apple هم در مورد ایران حساس است و نمی گذارد iPhone SDK را دانلود کنیم. به هر حال Torrent آنرا پیدا کرده و به همراه بقیه پیش نیاز ها نصب کردیم.

MonoDevelop به خوبی کار کرد و برنامه نوسی به زبان C# بر روی MAC OS امکانپذیر شد اما فقط برای برنامه های غیر iPhone ی. امکان ایجاد یک پروژه iPhone ی وجود داشت ولی هنگامی که می خواستیم فایل UI این پروژه را ویرایش کنیم به مشکل بر خوردیم.

Interface Builder نتوانست فایل xip (که در ایجاد UI کاربرد دارد) را باز کند و مشکل از نا هماهنگی نسخه ی iPhone SDK بود. ای کاش تحریم نبودیم و مجبور نبودیم یک فایل 2GB ی را دانلود کنیم و دست آخر متوجه شویم که اشتباه دانلود کردیم و ای کاش می شد هر چیزی را از مرجع آن دریافت کرد.

واقعا متاسفام که این تحریم به راحتی اثرات مشهودی بر کار ما می گذارد. خدا میداند! شاید همین تحریم باعث شد، چیزی شبیه iPad ساختیم و سپس SDK ی آنرا تولید کرده و بعد یک برنامه ساختیم مانند MonoTouch که بایت کد های CLI را به ساختار Native قابل اجرا برای آن دستگاه تبدیل کند! یا حتی از اول دستگاهی ساختیم که قابلیت اجرای بایت کد های CLI را داشته باشد. یا اصلا چرا این کارها! شاید اصلا خودمان Byte Code خودمان را تولید کردیم از نوع ملی و محلی و …!

پی نوشت 1: این شرکت هایی که نمی گذارند ایران از آنها سرویس بگیرد معمولا گناهی ندارند و فقط قانون را اجرا می کنند.
پی نوشت 2: خوشبختانه C# و CLI هر دو استاندارد هستند و ما می توانیم از آنها استفاده کنیم و یا (اگر بتوانیم) پیاده سازی خودمان را داشته باشیم؛ بدون هیچ محدودیتی.
پی نوشت 3: این پست شامل چند ScreenShot از MAC OS X و MonoDevelop اجرا شده تحت آن بود اما متاسفانه (احتمالا باز هم بخاطر تحریم) پست با تصویر را نمی توان به راحتی از طریق نرم افزار Windows Live Writer ارسال کرد. البته پی گیری این امر از حوصله و وقت ما خارج بود.

تکان

متاسفانه وقتی مردم ما به یک تکنولوژی خو می گیرند به سختی می توان آنها را متقاعد کرد که دست کم در این مورد، به طور حتم آینده بهتر از گذشته خواهد بود.

مصداق بارز این موضوع در استفاده از IE 6.0 است. با وجود اینکه IE 7.0 و 8.0 کاملا رایگان هستند باز هم در بیشتر ادارات هنوز از IE 6.0 استفاده می شود (البته شاید اگر رایگان نبودند بیشتر مورد توجه قرار می گرفتند). IE 6.0 حتی قادر نیست فایل های تصویری PNG را به صورت Transparent نمایش دهد و اگر بتوان گفت که استاندارد است، با استاندارد های قدیمی سازگار است. وجود IE 6.0 باعث می شود که طراح سایت یا برنامه نویس بعضی از ویژگی های جدید را از دست بدهد تا سازگاری را بدست آورد.

گاهی اوقات کارفرما تصور می کند این که توسعه دهنده می گوید IE 6.0 را پشتیبانی نمی کنم بخاطر تنبلی اوست!

اما باید برای آن دسته از کارفرمایان یا مدیران گفت که خوشبختانه یا متاسفانه حتی خود مایکروسافت نیز در SharePoint 2010 دیگر از IE 6.0 پشتیبانی نمی کند!

امید است که ادرات ما تکانی به خود بدهند.