پرهیز از کمال‌گرایی غیر ضروری در توسعه نرم‌افزار

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

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

البته یکی از اصول توسعه نرم‌افزار خصوصاً در سال‌های اخیر که روش‌های «چابک» رواج بیشتری پیدا کرده‌اند این است که تا به چیزی به طور کامل نیاز پیدا نکرده‌اید، آن را انجام ندهید. از طرفی درست است که یک code base خوب به شما کمک می‌کند که امکان توسعه‌های آتی راحت‌تر فراهم شود و حتی خطایابی و پشتیبانی هم راحت‌تر و سریع‌تر شود، اما چیزی که واقعاً برای مشتری مهم است کارآیی برنامه و از طرفی پایین بودن زمان و هزینه توسعه است. اگر قرار باشد همه چیز به روش اصولی و صد در صد درست انجام شود، حتی موارد ساده و کم استفاده، آن وقت هزینه‌های تولید و پشتیبانی نرم‌افزار بیشتر از آنی خواهد بود که باید باشد. باور کنیم که تیم‌های تولید نرم‌افزار هم در استفاده از روش‌های برنامه‌نویسی باید «مقیاس‌پذیر» باشند. اگر مشتری کارش را در نصف زمان و با نصف هزینه خواست، تیم هم باید بتواند با به کارگیری روش‌های ساده‌تر و معمولی‌تر هزینه‌ها را کاهش دهد. نه این که با اصرار بر ایده‌آل گرایی هزینه‌ها را افزایش دهد.

به عنوان مثالی که اخیراً به آن برخورد کردم باید به ذخیره و خواندن تنظیمات سیستم از app.config اشاره کرد. مورد استفاده من نگهداری چندین value به ازای یک key یکسان بود. هر چند که دات‌نت اجازه چنین کاری را می‌دهد و خطا اعلام نمی‌کند. اما استفاده معمولی از ConfigurationManager.AppSetting فقط آخرین value را بر می‌گرداند. راه اصولی برای حل این مشکل استفاده از Config Sectionهای سفارشی بود. حتی می‌شد از راه‌حل‌های پیچیده‌تر مبتنی بر reflection برای حل مسئله استفاده کرد. اما یک راه فوق‌العاده ساده‌تر و کم هزینه‌تر هم وجود داشت. اضافه کردن یک عدد چند رقمی (بی‌استفاده) به انتهای keyها (تا از یکسان بودن در بیایند) و استفاده از یک foreach و عملیات استرینگی ساده برای به دست آوردن valueها! راه حل آخر را از یک برنامه‌نویس VB.NET یاد گرفتم.

‫ابزارهای دات‌نتی یا PHP؟

به عنوان یک کاربر دنیای وب هر چند از گاهی که نیاز به راه اندازی یک سایت، وبلاگ، انجمن، فروشگاه اینترنتی و غیره می‌شود نیاز به تصمیم‌گیری درباره انتخاب ابزار مورد استفاده هم می‌شود. برای هر دسته از نیازمندی‌ها ابزارهای متفاوتی وجود دارد. مثلاً برای راه اندازی وب سایت می‌توان از ابزارهای WordPress، Joomla، Drupal، Orchard یا Umbraco استفاده کرد. فارغ از امکانات و جزییات هر کدام از آنها، اگر سر و کاری با برنامه‌نویسی و توسعه نرم‌افزار داشته باشید، اول بایستی بین سکوی توسعه آنها یا همان زبان برنامه‌نویسی آنها تصمیم‌گیری کنید. در این زمینه دو سکوی اصلی وجود دارند، یکی PHP که لینوکسی است و دیگر .Net که ویندوزی است.

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

اما اگر دستی بر آتش دارید، فعالیت‌تان در زمینه دات‌نت است، سرور ویندوزی دم دست دارید، علاقه کمی به کار با لینوکس و PHP دارید و یا نیاز احتمالی به توسعه و یکپارچگی ابزارها دارید، قضیه فرق می‌کند. در این صورت باید وزن امکانات و مزایای ابزارهای PHP را کمی کمتر کرده و به ابزارهای دات‌نتی نگاه دقیق‌تری داشته باشید. اجازه دهید یک Case Study داشته باشیم راجع به CMSها.

گفته می‌شود که بین CMSهای PHP سه ابزار WordPress، Joomla و Drupal بسیار رایج‌تر هستند. WordPress پر استفاده‌ترین و ساده‌ترین است. Drupal برای نیازهای پیچیده‌تر ساخته شده و استفاده از آن به راحتی WordPress نیست. Joomla حالت وسط این دو است. یعنی از WordPress پیچیده‌تر و کم استفاده‌تر ولی از Drupal ساده‌تر و پر استفاده‌تر است. وردپرس و جوملا به تنهایی ۷۸ درصد سهم بازار را در اختیار دارند. ابزارهای دات‌نتی هم طی سال‌های اخیر رشد خیلی زیادی داشته‌اند. سه ابزار مطرح دات‌نتی عبارت هستند از Umbraco، Orchard و DotNetNuke. از بین این سه Orchard از همه جدیدتر است. گفته می‌شود Orchard معادل Drupal است. DotNetNuke یا همان DNN از همه قدیمی‌تر و رایج‌تر است. بر اساس نظرات برخی کاربران Orchard چیزی از یک CMS کامل کم ندارد. اگر این گفته را صحیح بدانیم باز هم جامعه کاربری خیلی کوچک (نسبت به WordPress) و متخصصین کم تعداد آن را نباید فراموش کرد. باید توجه کرد که جامعه کاربری کوچک به معنای ابزارهای جانبی، Themeها و امکانات فارسی کمتر نیز می‌باشد.

تجربه شخصی که از نرم‌افزارهای وبلاگ نویسی دارم من را نسبت به نرم‌افزارهای دات‌نتی به شک انداخته است. من مدت‌ها از ابزار blogger برای وبلاگ‌نویسی استفاده کرده‌ام. مدتی هم هست که از BlogEngine.Net به عنوان یک ابزار دات‌نتی استفاده می‌کنم. هر چند که خیلی با ریزه‌کاری‌های وبلاگ‌ها کار نکرده‌ام، اما به طور تجربی حس می‌کنم وبلاگ WordPress خیلی راحت‌تر و روان‌تر از BlogEninge.Net به عنوان بهترین وبلاگ دات‌نتی کار می‌کند. رسیدن به یقین در مورد این موضوع نیاز به بررسی دقیق‌تر WordPress و خود BlogEngine.Net هم دارد.

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

منابع
•    http://www.rackspace.com/knowledge_center/article/cms-comparison-drupal-joomla-and-wordpress
•    http://webmasterformat.com/blog/top-asp-net-cmss
•    http://www.garethelms.org/2011/01/my-take-on-net-cmss-orchard/
•    http://www.techrepublic.com/blog/programming-and-development/pass-on-orchard-cms-until-the-feature-set-matures/4127
•    http://w3techs.com/technologies/comparison/cm-artiphp,cm-drupal,cm-orchard
•    http://orchard.codeplex.com/discussions/304259
•    http://www.opensourcecms.com/general/cms-marketshare.php
•    http://www.mindfly.com/blog/2012/02/13/wordpress-vs-umbraco-how-do-you-choose/

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

سوال این است: چرا به عنوان یک برنامه‌نویس دات‌نت به هنگام استفاده از یک نرم‌افزار کاربردی که از آن فقط انتظار کاربردی داریم نه برنامه‌نویسی، باز هم بهتر است در صورت امکان از معادل دات‌نتی آن استفاده کنیم؟ مثلاً:

اولین دلیل این است که مشکلات نصب کمتری خواهیم داشت. به عنوان یک برنامه‌نویس دات‌نت آشنایی خیلی بیشتری با IIS و ویندوز داریم تا مثلاً Apache و لینوکس. راه اندازی MS SQL برایمان خیلی راحت‌تر از راه اندازی MySQL است. دلیل بعدی یادگیری است. اگر به اندازه کافی با یک پروژه کدباز دات‌نتی ور برویم احتمال این هست که بتوانیم از آن یک سری چیزها برای دنیا و آخرتمان یاد بگیریم. سومین دلیل مربوط به احتمال دستکاری است. اگر روزی روزگاری لازم شد که application مورد نظر را مختصر دستکاری کنیم، می‌توانیم امیدوار باشیم که به علت آشنایی با دات‌نت بهتر می‌توانیم این کار را انجام دهیم. فکرش را بکنید برای یک دستکاری کوچک مجبور به استفاده از Perl یا Ruby می‌شدید. دلیل آخر حفظ منافع جمعی (تعصب) است. ما با استفاده از یک پروژه دات‌نتی از آن حمایت کرده‌ایم. با این حمایت، برنامه‌نویس یا برنامه‌نویسان مورد نظر بیشر تشویق می‌شوند در دنیای دات‌نت کار کنند. و این در نهایت به نفع ما جامعه دات‌نت کارهاست.

پول ویندوز را بدهیم یا ندهیم؟

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

قبل از ادامه باید به دو نکته توجه کرد. یکی این که موضوع انتخاب بین ویندوز و لینوکس یا بحث‌های open source و غیره نیست. من ویندوز را دوست دارم و می‌خواهم روی آن ادامه دهم. مشکل در اینجا فقط گران بودن و مشکلات تحریم است. نکته دوم این که همه این بحث‌ها وقتی که شما انفرادی کار می‌کنید خیلی اهمیتی ندارد. چون اکثر laptopها شامل یک ویندوز اصلی هم هستند و اگر صاحب آن برنامه‌نویس ویژوال استودیو نباشد، بدون نیاز به هزینه زیادی، Copyright را رعایت کرده است. بحث بر شرکت‌های کوچک و متوسطی است که می‌خواهند به نوعی این مشکل را حل کنند.

راه اول: کنار گذاشتن اخلاق و استفاده غیر قانونی از محصولات مایکروسافت

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

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

راه سوم: پرداخت کامل هزینه لایسنس ویندوز و بقیه محصولات:
اول باید ببینیم هزینه استفاده از محصولات قانونی چقدر است و آیا از عهده ما بر می‌آید یا نه. از آنجا که خیلی از شرکت‌ها و برنامه‌نویس‌ها از تمام امکانات محصولات مایکروسافت استفاده نمی‌کنند و از آنجا که فعلاً می‌خواهیم با کمی صرفه جویی کارمان را شروع کنیم، از هزینه خرید ویندوز سرور چشم پوشی کرده و به جای آن از ویندوز ۷ استفاده می‌کنیم. در مورد Visual Studio و MS SQL هم سعی می‌کنیم کارمان را با نسخه‌های express یا محصولات رایگان دیگر مثل MySql یا SharpDevelop راه بیندازیم. پس تنها چیزی که ما می‌خواهیم خرید چند نسخه ویندوز است. فرض کنید شرکتی ۱۰ کارمند دارد و ۱۲ تا کامپیوتر. اگر قیمت هر نسخه از ویندوز (یک ویرایش متوسط) را ۱۵۰ هزار تومان فرض کنیم، پول لایسنس‌هایمان یک میلیون و هشت صد هزار تومان می‌شود. اگر این هزینه را با دیگر هزینه‌های شرکت‌داری مثل اجاره دفتر که ممکن است تا چند میلیون تومان در ماه برسد مقایسه کنیم، خواهیم دید که پرداخت این مبلغ آنقدر سخت نیست که بخواهیم به خاطر آن به لینوکس مهاجرت کرده یا از زیر آن در برویم. البته طرح‌های رایگانی مثل BizSpark هم هستند ولی نمی‌شود در ایران از آنها استفاده کرد.

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

‫کتاب اصول برنامه‌نویسی (Foundation of Programming)

کتاب «اصول برنامه‌نویسی» که یک کتاب الکترونیکی ۷۹ صفحه‌ای است، توسط یکی از فعالان CodeBetter منتشر شده. کلیت مطالب کتاب راجع به مفاهیم نسبتاً جدید تولید نرم‌افزار مثل Persistence، DI، DDD، Unit Test و غیره است. نویسنده در ابتدای کتاب اظهار داشته که این کتاب برای پشتیبانی از حرکت ALT.NET نوشته شده است. این کتاب همچون خود ALT.NET بیشتر روی مفاهیم و تکنیک‌ها مانور می‌دهد چون معتقد است برنامه‌نویسان به اندازه کافی به API دات‌نت مسلط شده‌اند پس حالا وقت آن است که اصولی‌تر برنامه بنویسند.

با دیدن بخش‌های اول کتاب ممکن است فکر کنید یک کتاب کلاسیک «مهندسی نرم‌افزار» را باز کرده‌اید. اما کتاب کار زیادی به تئوری ندارد و بلافاصله به مثال‌ها، نمونه‌ها و ابزارهای عملی می‌پردازد. البته واقعیت این است که می‌شود این کتاب را یک کتاب «مهندسی نرم‌افزار» عملی نامید. چون با معرفی تکنیک‌ها، روش‌ها و ابزارهایی به شما کمک می‌کند تا همان اصول فراموش شده «مهندسی نرم‌افزار» را عملاً به کار گیرید.

عناوین فصول کتاب:
۱- ALT.NET: معرفی جبهه ALT.NET و تفاوت آن با MSDN Way
‫‫۲-‫ Domain Driven Design: معرفی الگوی DDD‎
‫۳- ‫Persistence: ارتباط با دیتابیس و ذخیره داده‌ها‎
‫‫۴-‫ Dependency Injection: معرفی و ابزارها‏
۵- Unit Testing: تست واحد
۶- Object Relational Mappers: معرفی و استفاده از NHibernate
۷- کار با Memory به طور اصولی
۸- مدیریت Exceptionها
۹- Proxy و استفاده از آن
۱۰- جمع‌بندی

تاریخ این کتاب ۲۰۰۸ بوده و کمی قدیمی می‌باشد. اما با این وجود خواندن و به کارگیری آن به همه برنامه‌نویسان توصیه می‌شود.

‫ALT.NET و MSDN Way‫

از زمانی که با NHibernate آشنا شدم متوجه یک جبهه جالب در دنیای دات‌نت شدم. جبهه کسانی که علاقه زیادی به port کردن پروژه‌های معروف جاوا به دات‌نت، استفاده از design patternهای شی‌گرایی و دنیای Open Source داشتند. نمونه بارز این جبهه خود NHibernate است. پروژه‌ای کاملاً open source برای تزریق OOP به کدهای دسترسی به دیتابیس بر اساس پروژه جاوایی Hibernate.

چند وقت پیش حین خواندن کتاب Foundation of Programming متوجه شدم که اسم این جبهه ALT.NET است. علایق این جبهه علاوه بر موارد بالا شامل unit test و CI و دیگر موارد مشابه هم می‌شود. طرفداران ALT.NET در عین حالی که روی سکوی دات‌نت متمرکز هستند از مایکروسافت و روش‌های مایکروسافتی گریزان هستند. آنها سعی می‌کنند برای هر تکنولوژی و ابزار مایکروسافتی، یک جایگزین open source ارائه دهند.

در مقابل ALT.NET روش MSDN Way قرار دارد. در روش MSDN Way عمده تمرکز افراد بر استفاده از APIهای تکنولوژی‌های مختلف دات‌نت است. کدهای برنامه‌نویسان MSDN Way شباهت زیادی به نمونه‌های معرفی شده توسط مایکروسافت در MSDN دارد. اصلاً اسم MSDN از همین جا آمده. یکی از نشانه‌های گروه MSDN استفاده از DataSet به جای ORMهاست.

برای کسب اطلاعات بیشتر به فصل اول کتاب Foundation of Programming مراجعه نمایید.

شما خودتان را بیشتر از پیروان ALT.NET می‌دانید یا MSDN Way؟

نرم‌افزارهای داده‌ای در وب

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

به عنوان نمونه به پروژه‌های زیر توجه کنید:

۱- ترافیک مصنوعی: بازدید مصنوعی از یک سایت خاصی به طور مکرر. به طوری که سایت مذکور فکر کند بازدید کننده‌هایش از OSها و browserها مختلف آمده است.

۲- تبدیل فید RSS به تکست

۳- نرم‌افزار email marketing

پ. ن.: به نرم‌افزارهای web scraping هم نگاهی بیندازید.

مرگ و تولد دوباره مونو

Novell Mono رسماً تعطیل شد. Attachmate هیچ ابراز علاقه‌ای به نگهداری مونو نکرده است. اما مطابق رسم Open Source، یک انشعاب (fork) جدید در راه است. Miguel de Icaza بنیان گذار مونو یک شرکت جدید به نام زامارین (Xamarin) تاسیس کرده است.

زامارین هم مثل مونوی ناول تمرکزش روی پیشنهادات تجاری ‎.NET برای iOS و Android است. آنها قاعدتاً در runtimeهای open source مونو شراکت خواهند داشت، چیزی که پایه تکنولوژیک سرمایه‌گذاری‌های آنها خواهد بود.

زامارین به کامپوننت‌های غیر open sourceی MonoTouch و Mono for Android دسترسی ندارد. در حالی که به نظر می‌رسد سرعت تیم به اندازه کافی زیاد نباشد، ولی میگوئل مدعی‌ست تیم آنها نخستین نسخه iPhone را در سه ماه و Android را در چهار ماه آینده منتشر خواهند کرد.

مسائل قانونی در زامارین

میگوئل اظهار داشته است محصولات جدید آنها از لحاظ سورس با کدهای Mono و MonoTouch برای Android سازگار خواهد بود. به همین خاطر Attachmate ممکن است از لحاظ قانونی با آنها مشکل پیدا کند. همیشه به نظر می‌رسید مونو مورد ادعای قانونی مایکروسافت قرار بگیرد، اما چون حق اختراع CLR/C#‎ غیر الزام آور است و با توجه به تعهدات موجود نسبت به ECMA، این کار امکان‌پذیر نخواهد بود.

داستان در مورد Attachmate کاملاً متفاوت است. آنها حتی اگر حمایتی هم انجام ندهند باز هم صاحب محصولی هستند که مستقیماً با محصولات زامارین در رقابت است. اگر هیچ توافق قانونی بین Attachmate و زامارین انجام نشود، احتمالا دعوای آنها بر سر این که آیا کدهای جدید از تکنولوژی‌های قدیمی مونو استفاده کرده یا نه وجود دارد. با توجه به این که کل موضوع یک wrapper برای یک API مادرزاد (native) است، اثبات این که شما همه چیز را از نو پیاده‌سازی کرده‌اید، حتی با وجود تیمی که با کدهای Attachmate آشنایی قبلی ندارد کار سختی است.

در نتیجه مثل اوایل پیدایش هر محصول جدیدی، بعضی برنامه‌نویسان در انجمن‌های mono-android اعلام کرده‌اند فعلاً به جاوا بازخواهند گشت. تعدادی هم معتقدند هزینه تبدیل برنامه‌ها به جاوا و نگهداری هم زمان دو مجموعه کد برای آنها غیر ممکن است.

تاسیس شرکت جدید

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

گفته می‌شود زامارین هنوز هم دنبال سرمایه‌گذارهای بیشتری است تا بتواند کارهایی از قبیل کارهای زیر را انجام دهد:
* راهنما برای طیف وسیع برنامه‌نویس‌ها
* مستند سازی APIهای خاص مونو
* نرم‌افزار اختصاصی پشتیبانی از مشتری
* به روز رسانی سیستم باگ فعلی
* آموزش
* مشاوره و پشتیبانی
* بازاریابی: سکوی توسعه‌ی خیلی خوبی موجود است. اما نیاز هست که دنیا این را بداند. بودجه بازاریابی قبلی نزدیک به صفر بوده.

مسائل قانونی Attachmate

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

توجه:
این متن ترجمه مطلب مربوطه در InfoQ است.

‫اندازه گیری سرعت صفحات ASP.NET

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

۱- یکی از دقیق‌ترین ابزارها برای اندازه‌گیری سرعت صفحات ASP.NET استفاده از Performance Monitor در ویندوز ۲۰۰۸ است.

با استفاده از این ابزار می‌توانید بفمهید اجرای صفحه مورد نظر شما چقدر طول می‌کشد و در کدام یک از مراحل اجرای کد دات‌نت قرار دارد. سه تا از counterهای مفید عبارتند از

  • ‭% Time in Jit (.Net CLR Jit)
  • ‭Request Execution Time (ASP.NET Apps)
  • ‭Requests/Sec (ASP.NET Apps)

۲- ابزار دیگری که بدون دسترسی به سرور هم قابل استفاده است و بیشتر روی مراحل مختلف ساخت شی Page متمرکز است، عبارت است از ابزار Trace.

برای فعال کردن این امکان در ASP.NET باید تنظیمات زیر را در مدخل system.web در web.config قرار دهید:


۳- حواستان باشد زمان مورد نیاز برای JIT را به حساب کندی برنامه نگذارید. dllهای دات‌نت به زبان IL هستند و برای اجرا نیاز دارند به کد ماشین ترجمه شوند. انجام این کار به عهده JIT هست. وقتی که یک برنامه ASP.NET را در IIS قرار می‌دهید، با اولین درخواست برای هر صفحه، کد آن توسط JIT تبدیل به کد ماشین می‌شود. این تبدیل فقط یک بار انجام خواهد شد و برای دفعات بعد cache خواهد شد.

‫معرفی کتاب Pro C# 2008 and the .NET 3.5 Platform

خواندن این کتاب را مدت‌ها پیش شروع کرده بودم اما تا حالا فرصتی نشده بود که نظرم را راجع به آن بگویم. این کتاب حجیم ۱۴۰۰ صفحه‌ای همه چیز را راجع به C# 2008 به آدم یاد می‌دهد و می‌تواند به عنوان یک مرجع دائمی مورد استفاده قرار گیرد. مطالب این کتاب آنقدر جامع و کامل هستند که حتی در فصول مقدماتی و ساده آن هم می‌تواند چیزی را برای یادگیری پیدا کرد. این کتاب شامل ۳۳ فصل و ۲ ضمیمه می‌باشد.

فصل اول و دوم مقدماتی راجع به دات‌نت و C#‎ می‌گویند که دانستن آنها مفید خواهد بود. خصوصاً فصل اول که ابزار پراستفاده ildasm.exe را معرفی می‌کند.

فصل ۳ و ۴ ساختارهای اصلی C#‎ را توضیح می‌دهد که فکر می‌کنم هر کسی که کمی C#‎ بلد باشد اینها را هم بلد باشد.

فصل ۵ و ۶ راجع به ساختار شی گرا در زبان C#‎ می‌باشد. خواندن این فصل خصوصاً فصل ۶ به کسانی که می‌خواهند C#‎ را به خوبی بفهمند توصیه می‌گردد.

فصل ۷ راجع به Exception Hadling است. خیلی برنامه‌ها بدون یک Exception Handling خوب هم کار می‌کنند. اما یک Exception Handling خوب تاثیر زیادی در کیفیت برنامه دارد و باعث می‌شود خطایابی و نگهداری آن خیلی راحت‌تر باشد.

فصل ۸ راجع به چرخه زندگی Objectها در C#‎ است. دانستن مطالب این فصل برای مواقعی که بعضی چیزها را در C#‎ نمی‌فهمید خیلی مفید است. مع الوصف بنده به شخصه دانستن این اطلاعات را ضروری می‌دانم.

فصل ۹ و ۱۰ راجع به Interfaceها و Collectionها و Generic می‌باشد. ناگفته پیداست که دانستن این‌ها هم برای یک برنامه‌نویس حرفه‌ای خصوصاً آنها که به طراحی هم علاقه دارند خیلی لازم است.

فصول ۱۱ الی ۱۳ راجع به امکاناتی از C#‎ صحبت می‌کند که هم جز مباحث پیشرفته و به در بخور آن محسوب می‌شوند و هم مقدمه‌ای بر LINQ هستند. یعنی استفاده موثر از LINQ بدون آنها امکان پذیر نیست. برخی مطالب این سه فصل عبارتند از Delegate، Event، Lambda، Indexer، Automatic Properties و Extension Methodها.

فصل ۱۴ اختصاص دارد به مقدمه‌ای از LINQ. اگر این مقدار از LINQ کارتان را راه نینداخت که قریب به یقین همین طور است باید از منابع دیگری برای یادگیری تکمیلی LINQ استفاده کنید. بنده خودم به شخصه از کتاب LINQ in Action استفاده کردم.

فصول ۱۵ الی ۱۹ کلاً راجع به اسمبلی‌ها یا همان dllها و مباحث مرتبط با آنهاست. راجع به ساختار داخلی آنها، کار با آنها از طریق Reflection، مسائل مرتبط با AppDomainها، برنامه‌های چند ریسمانی (Multi Thread) و CIL و Dynamic Assemblies. به نظر شخصی من مطالب این چند فصل آنقدر خاص هستند که ممکن است خیلی‌ها هیچ وقت به آن نیاز پیدا نکنند. توصیه می‌کنم بعد از آن که فهمیدید هر کدام از این فصول راجع به چه موضوعی صحبت می‌کنند آنها را رها کرده و هر وقت که واقعاً به آنها نیاز داشتید به سراغشان بروید. بنده به شخصه فقط مبحث Reflection را مطالعه کردم و فکر هم می‌کنم حالا حالاها به غیر از مبحث چند ریسمانی به بقیه مطالب آن بی‌نیاز باشم.

فصول ۲۰ الی ۲۶ راجع به Class Library دات‌نت می‌باشند. بیشتر افراد با بعضی مطالب این فصول از قبل آشنا هستند و خیلی‌ها هم ممکن است هیچ نیاز پیدا نکنند و یا نخواهند که از بعضی از آنها استفاده کنند. مطالب این فصول به نظر من باید به صورت Reference مطالعه شوند. یعنی تا زمانی که واقعاً به آنها نیاز نشده نباید سراغشان رفت. مطالب این فصول عبارتند از IO، Object Serialization، ADO.NET، LINQ API، WCF و WF.

فصول ۲۷ الی ۳۳ کمی از خود C#‎ فاصله گرفته و به برنامه‌نویسی UI در دات‌نت می‌پردازند. این فصول مطالبی را راجع به Windows Forms، WPF و ASP.NET بیان می‌کنند. به نظر شخصی من جای این طور مطالب در یک کتاب تخصصی C#‎ نیست. یعنی اگر کسی بخواهد ASP.NET یاد بگیرد بهتر است به یک کتاب اختصاصی راجع به ASP.NET مراجعه کند نه یک کتاب C#‎. با توجه به این موضوع و با توجه به این که مطالب مطرح شده در این فصول خصوصاً در مورد ASP.NET کمی مقدماتی هستند، بنده هیچ کدام آنها را نخوانده و به کسی هم توصیه نمی‌کنم. خصوصاً این که خود من به دنبال درک بهتر C#‎ به سراغ این کتاب آمدم نه به دنبال یادگیری مقدماتی ASP.NET.

ضمیمه اول ممکن است به درد کسانی که مجبورند در دات‌نت از اشیای قدیمی COM استفاده کنند بخورد. ضمیمه دوم هم راجع به مونو است که فکر می‌کنم حالا دیگر حسابی out of date شده باشد.

پ. ن.: 
۱- ظاهراً این کتاب به فارسی هم ترجمه شده. نگاهی به اینجا بیندازید.

۲- بلد بودن بعضی مباحث که خودم آنها را غیر ضروری فرض کرده بودم برای قبولی در امتحان ۵۳۶ اجباری می‌باشد.

۳- اگر قرار باشد بار دیگر هم کتابی راجع به C#‎ بخوانم احتمالاً این دفعه نگاهی به کتاب C# in Depth بیندازم. آن هم به خاطر ارادت خاصی که نسبت به Jon Skeet پیدا کرده‌ام.