2011/05/31

‫چند نکته در باب WCF

WCF هم مثل هر تکنولوژی و سکوی جدیدی با تعدادی نکته همراه است. به نکات زیر دقت کنید:


عدم دسترسی به HttpCpntext
ممکن است حین کار با WCF نیاز به HttpContext.Current.Request یا غیر داشته باشید. این نیاز وقتی که سرویس WCFتان در IIS میزبانی می‌شود بیشتر هم می‌شود. متاسفانه HttpContext.Current در داخل یک سرویس WCF همواره null است چون اصولاً یک سرویس WCF ربطی به Http ندارد. در WCF باید به جای HttpContext از OperationContext.Current استفاده کرد.

آدرس خالی
لزومی ندارد که همیشه اسم یا IP سرویس دهنده در config مربوط به سرویس دهنده مشخص شود. بیشتر وقت‌ها می‌توان بخش address مربوط به endpoint را خالی گذاشت.
امکان مشاهده پیغام خطای رخ داده در سرور WCF
برنامه‌های ASP.NET را می‌شد طوری در سرور تنظیم کرد که اگر خطایی رخ داد به کاربر هیچ چیزی از خطا نمایش داده نشود یا این که بشود. همین کار را می‌توان در config سرور WCF با استفاده از <servicedebug includeexceptiondetailinfaults="true" > انجام داد.


مشکل در WCF RSS در سرویس‌های WCF که مثل RSS به نوعی با وب سر و کار دارند ممکن است لازم شود نوع binding به صورت webHttpBinding تعریف شود. لینک




2011/05/30

‫تولید Feed با استفاده WCF

مطمئناً برای تولید Feedهای RSS یا ATOM در ASP.NET راه‌ها و کدهای زیادی وجود دارد. اما یکی از راه‌های جالب تولید Feed در دات‌نت، استفاده از WCF است. WCF با استفاده از چند خط کد ساده برای شما Feed می‌سازد.

سرویس‌های Feed معمولاً در برنامه‌های تحت وب که در IIS اجرا می‌شوند قرار داده می‌شوند. بنابراین باید سرویس WCF را در فایل‌های ‎.svc قرار داد. اگر سرویس در یک host با دسترسی خیلی پایین مثل سایت‌های اینترنتی قرار داشته باشد نمی‌توان از کلاس ServiceHost استفاده کرد. بنابراین باز هم باید از فایل‌های ‎.svc که توسط IIS میزبانی (host) می‌شوند استفاده کرد. خوشبختانه امکانات اصلی WCF از نسخه ۳٫۵ دات‌نت در دسترس هستند و از آنجا که دات‌نت ۳٫۵ روی runtime نسخه ۲ دات‌نت هم کار می‌کند بنابراین مشکلی در سرورهای ویندوز ۲۰۰۳ و IISهای قبل از نسخه ۷ هم وجود ندارد.


جهت کسب اطلاعات بیشتر به MSDN مراجعه کنید. در صورت استفاده از IIS بایستی از webHttpBinding به عنوان binding استفاده کرد.




2011/05/29

‫استفاده بهینه از Lazy Loading

برای Lazy Loading در NHibernate روال زیر را انجام داده بودم. lazy را برای همه mappingها true کرده بودم. در web.config هم همینطور. سپس هر جا که lazy مشکل پیدا می‌کرد و خطای LazyInitializationException اتفاق می‌افتاد، آن association یا collection را با استفاده از کلاس NHibernateUtil.Initialize پیش load می‌کردم تا مشکل حل شود. این راه حل خیلی هم غلط نیست، اما می‌توان برای رفع مشکل از دست رفتن session از روش‌های زیر هم استفاده کرد:

۱- در associationهای مشکل دار از outer-join = true استفاده شود.
۲- در query APIهای مختلف هم می‌توان نوع outer-join را تعیین کرد.


باید دقت کرد که نوع outer-joinی که در سطح mapping یک entity تعریف می‌شود قابل override در query یا هر جای دیگر است.




2011/05/28

‫استفاده از Authentication/Authorization استاندارد WCF یا پیاده‌سازی خودمان؟

WCF خودش مکانیزم‌های زیادی برای Authentication و Authorization دارد. یکی از سناریوهای ممکن برای Membership یک برنامه نوعی می‌تواند این باشد که Membership در سرور با استفاده از یک Windows Domain Controller تعریف شده و به ازای همه کاربران و نقش‌های ممکن، در آن domain به تعداد مورد نیاز Windows Account و Windows Group ساخته شود. سپس Role Management تمام سرویس‌ها بر اساس این Windows Groupها تعریف شده و کاربران برنامه WCF هم بر اساس Windows Accountهای تعریف شده در domain وارد سیستم شوند.

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




2011/05/27

‫ایمن‌سازی انتقال اطلاعات در WCF

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

WCF پنج روش را برای ایمن‌سازی انتقال اطلاعات فراهم می‌کند. اولین روش، عدم استفاده از هیچ نوع ایمن‌سازی است. دومین روش، ایمن‌سازی لایه انتقال است. در این روش WCF از یکی از پروتکل‌های ایمن HTTPS، TCP، IPC یا MSMQ برای انتقال اطلاعات استفاده می‌کند. این روش برای وقتی که کلاینت و سرور به طور مستقیم به هم وصل نیستند مشکلاتی دارد. سومین روش، ایمن‌سازی خود پیغام‌ها است. در این روش پیغام‌ها اول رمزنگاری شده سپس انتقال داده می‌شوند. این روش هم روی پروتکل‌های ساده مثل HTTP قابل اجراست هم بر عکس روش ایمن‌سازی لایه انتقال، نیازی به ارتباط مستقیم بین کلاینت و سرور ندارد. بنابراین از این روش در فضای اینترنتی هم می‌توان استفاده کرد. تنها نکته منفی این روش، overhead اجرای آن به دلیل رمزنگاری تک تک پیغام‌هاست. روش چهارم و پنجم هم عبارتند از ترکیب روش دوم و سوم یا استفاده هم‌زمان از هر دو که ممکن است خیلی هم مورد استفاده قرار نگیرند.



منبع:
فصل ۱۰ کتاب Programming WCF Services




2011/05/26

‫Authentication و Authorization در WCF‫

Authentication در WCF به چندین روش انجام می‌شود:



No authentication
هیچ نوع authenticationی انجام نمی‌شود.

Windows authentication
در صورت وجود domain server از Kerberos و در غیر این صورت از NTLM استفاده می‌شود.

Username و Password
user name و password می‌تواند بر اساس اکانت‌های ویندوز یا یک روش سفارشی سازی شده سنجیده شود.

X509 certificate
کلاینت خودش را با استفاده از یک certificate به سرور می‌شناساند.

Custom mechanism
برنامه‌نویسان می‌توانند روش authentication خاص خودشان را پیاده‌سازی کرده و WCF را مجبور به استفاده از آن کنند.

Issued Token
در این روش هم سرور و هم کلاینت از یک سرویس دیگر مثل Windows Card Space برای authentication استفاده می‌کنند.





WCF برای Authorization هم از دو روش آشنا استفاده می‌کند. یکی استفاده از Windows groups و دیگری استفاده از ASP.NET role provider.




منبع: فصل ۱۰ کتاب Programming WCF Services




2011/05/25

‫امکانات انقلابی git


انقلابی‌ترین امکان git خاصیت distributed آن است. بعد از این قضیه دو دستور زیر به نظر من خیلی انقلابی می‌آیند:


۱- دستور git stash
فرض کنید در حال اعمال یک سری تغییرات دامنه دار در سورس برنامه هستید. فرض کنید تعداد زیادی فایل را modify کرده و تعدادی را هم اضافه یا حذف کرده‌اید. حالا وسط کار متوجه باگ یا ایرادی در سورس می‌شوید که ارتباطی با تغییرات اخیرتان ندارد ولی به هر صورت می‌خواهید هم این اشکال را حل کنید و هم این که commit این رفع باگ با commit تغییرات مورد ذکر یکی نباشد. حالا باید چه کار کرد؟ راه معمول این است که باگ مشاهده شده را در جایی یادداشت کرد و بعداً آن را اصلاح کرد، البته اگر تغییرات اخیرتان به آن وابسته نباشد. راه دیگر آن است که تغییرات اخیر را un-do کرده، باگ مورد نظر را رفع کرده و تغییرات اصلی را مجددا از نو شروع کنید.

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


۲- دستور git grep
دستور grep دستور ساده‌ای است که می‌تواند عبارت خاصی را در فایل‌های موجود در source control گیت مورد جستجو قرار دهد. آنها که به search سورس در Visual Studio عادت دارند مطمئناً از git grep خیلی خوششان خواهد آمد.





2011/05/24

‫بعضی از دستورات ضروری git

مشاهده تغییرات قبل از commit
git diff --cached

ایجاد یک branch به اسم mybranch
git branch mybranch

سویچ کردن بین branchهای مختلف
git checkout mybrabch

نمایش branchهای موجود و branch جاری
git branch

merge برنچ mybranch با branch جاری
git merge

حذف یک branch
git branch -d mybranch

تهیه branch از یک remote branch
git branch --track experimental origin/experimental

خالی کردن موقتی working diretory
git stash

جستجو در فایل‌ها
git grep search_phrase

undo کردن تغییرات سورسی که هنوز commit نشده است
git reset --hard HEAD

Undo کردن تغییرات یک تک فایل
git checkout HEAD hello.rb

بررسی سالم بودن فایل‌های git
git fsck

بررسی این که چه کسی چه قسمتی از یک فایل را تغییر داده است
git blame sha1_file.c

درست کردن shortcut و خلاصه برای دستورات طولانی git
git config --global alias.last 'cat-file commit HEAD'‎


منبع:
کتاب git community




2011/05/23

‫بعضی اصطلاحات مهم git

git directory
همان فولدر ‎.git است که خود سورس کنترل هم محسوب می‌شود.

working directory
فضای معمولی انجام کار با سورس برنامه است.

INDEX
فضای موقتی که نشانگر فایل‌های تغییر یافته یا جدیدی هستند که قرار است با commit بعدی به مخزن بروند. INDEX نقش واسطه بین working directory و git directory را بازی می‌کند. دستور git status برای نمایش اطلاعاتش از INDEX استفاده می‌کند.

HEAD
اشاره می‌کند به آخرین commit برنچ جاری.   

origin
آدرس URLی است که clone از آنجا انجام شده.




2011/05/22

‫کتاب Programming WCF Services



این روزها WCF رواج زیادی در شرکت‌های ایرانی پیدا کرده است. برای من هم یکی دو موقعیت پیش آمده که مجبور شوم با WCF کار کنم. به اولین منبعی که برای یادگیری مراجعه کردم فصل ۲۵ کتاب Pro C# 2010 بود. این فصل خلاصه و مقدمه‌ای از WCF است و به هیچ وجه قصد وارد شدن به جزییات را ندارد. خواندن این فصل توانست دستم را به طور کامل در WCF راه بیندازد اما خودم فکر می‌کردم برای یادگیری بهتر WCF بهتر است یک کتاب اختصاصی راجع به WCF بخوانم. به همین خاطر کتاب Programming WCF Services را انتخاب کردم.

سه فصل اول این کتاب اختصاص دارد به مقدمات WCF یعنی همان‌هایی که در فصل ۲۵ کتاب قبلی پوشش داده شده بود. بنابراین آنها را بی‌خیال شدم و مستقیماً از فصل ۴ که راجع به Instance Management بود شروع کردم. این فصل و تا اندازه‌ای هم فصل بعدی چیزهای جالبی برای یاد گرفتن داشت. اما از فصل ۶ تا آخر کتاب را هر چقدر که بیشتر نگاه کردم متوجه شدم که هیچ کدامشان برای نیاز فعلی من ضروری نیستند و بعداً هم می‌توانم در صورت ضرورت به آنها مراجعه کنم. این فصول راجع به کنترل خطا، تراکنش، مدیریت همزمانی، صف، امنیت و سرویس‌های خاص Windows Azure صحبت می‌کنند.




2011/05/21

آیا نرم‌افزار تجارت کثیفی است؟

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

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

این طور مسائل هم باعث می‌شود سازمان‌ها و افراد دید چندان مثبتی نسبت به کار نرم‌افزار نداشته باشند و هم باعث می‌شود رقابت در بین شرکت‌های نرم‌افزاری کمی کثیف شود.




2011/05/20

‫‫‫رابطه یک به یک در NHibernate و Castle ActiveRecord

بین دو Entity می‌توان رابطه یک به یک برقرار کرد. یعنی به ازای یک instance (رکورد) از یکی، فقط و فقط یک instance (رکورد) در دیگری وجود داشته باشد. هر چند که NH این نوع رابطه را نشانه طراحی بد می‌داند، اما دو راه برای پیاده‌سازی آن مهیا کرده است:

۱- روش primary key associations: در این روش هر دو entity از یک primary key مشترک استفاده می‌کنند.

۲- روش unique foreign key associations: در این روش یکی از طرفین رابطه یک ستون اضافی تعریف کرده و آن را به کلید خارجی مرتبط با primary key طرف دیگر رابطه اختصاص می‌دهد.

هر دوی این روش‌ها به تفصیل در مستندات NH توضیح داده شده‌اند. Castle ActiveRecord هم هر دو این روش‌ها را پشتیبانی می‌کند. مستندات خود ActiveRecord فقط روش اول توضیح داده است اما برای پیاده‌سازی روش دوم هم کار چندان سختی نیست
{لینک به مطلب مرتبط در وبلاگ خودم}.




‫فیلم شبکه اجتماعی (فیس بوک)

مسعود کاری کرد که تا سه نصفه شب بیدار باشم. اون منو وسوسه کرد به دیدن فیلم شبکه اجتماعی (فیس‌بوک). فیلمی درباره فیس‌بوک، مارک زوکربرگ، شرکا و رقبای اون و دادگاهی که علیه مارک تشکیل شده بود.

مارک خیلی تند تند حرف می‌زد طوری که حتی با داشتن زیرنویس هم مجبور بودم فیلمو پشت سر هم نگه دارم. حتی سرعت تایپش در خوابگاه کرک‌هاوس (؟) هم اگر واقعی باشد خیلی خیلی زیاد بود. هر چند که نفهیمدم دقیقاً چرا مارک و اریکا در دو سه دقیقه اول فیلم با هم دعوا کردند، اما فهمیدم که این انگیزه فوق‌العاده‌ای بوده برای مارک که facemash رو راه اندازی کنه. داستان فیلم از ۲۰۰۳ شروع می‌شد. ۲۰۰۳ برای من تاریخ خیلی جدیدی حساب می‌شد بنابراین اصلاً حس نکردم این چیزها مال قدیم بوده. فیلم پر بود از اسامی آشنا مثل لینوکس، آپاچی، پایتون و…

اصلاً فکر نمی‌کردم هزار دلار اولیه و حتی هیجده هزار دلار بعدی هم رقم خیلی درشتی برای یک دانشجوی هاروارد باشد. کلا این فیلم پر بود از نکات جالب. مثلاً صحنه استخدام اولین آدم فیس‌بوک (به غیر از خود مارک و ادواردو) و روش ارزیابی مارک خیلی جالب بود. کرک کردن یک سرور پایتون و دستکاری SSL در ده دقیقه آن هم با آن shotهای پی در پی که خیلی شبیه به صحنه نفوذ به سایت بانک در فیلم «اره ماهی» بود. فکر کنم اگر کسی در ایران بخواهد همین کار را بکند اقلاً باید سه تا کتاب راجع به شبکه و پایتون بخواند و دو ماه هم روی آن کار کند. البته داستین با برنده شدن در این مسابقه استخدامی صاحب ۵ درصد سهام فیس‌بوک شد.

در اولین حضور «شان» در فیلم تناظر جالبی وجود داشت. او در حالی که از به زور از رختخواب بلند می‌شد مدعی بود که یک کارآفرین (Enterprenur) است در حالی که دوست دخترش معتقد بود او بیکار (not employed) است. دوست دختر ادواردو هم آدم جالبی بود. او با سین-جیم کردن ادواردو و نهایتاً آتش زدن هدیه خودش و تخت ادواردو نشان داد که حسادت و فضولی یک مسئله کاملاً جهانی است. یکی از صحنه‌های ناب فیلم، اولین حضور ادواردو در «سیلیکون ولی» بود. وقتی که ادواردو یک ساعت در فرودگاه معطل مارک مانده بود. آنجا که ادوارو زنگ خانه را می‌زند، داستین (در حال برنامه‌نویسی) می‌گوید کسی در حال زدن زنگ در است اما «شان» به او می‌گوید تو داری برنامه می‌نویسی پس چیزی نمی‌شنوی. به تمرکز این صحنه دقت کنید. در ادامه همان صحنه معلوم می‌شود مارک ۳۶ ساعت پشت سر هم بدون خوابیدن در حال کد نویسی بوده. به پشتکار مارک دقت کنید.

با خودم فکر می‌کنم اگر ملایی، رییس شرکت خودمان را، راضی کنم که شرکت را از تهران به پالو آلتو در کالیفرنیا منتقل کند شاید ما هم بتوانیم از آن سرمایه گذارهای فرشته‌ای (angel investor) پیدا کنیم که بتواند ۵۰۰ هزار دلار روی شرکت ما سرمایه‌گذاری کند و ما هم مثل فیس‌بوک وضعمون خوب بشه. در این فیلم دو برنامه‌نویس هستند، یک مارک که ماهیت برنامه‌نویس بودنش را با وجود بیلیونر بودن حفظ کرده و دیگر «شان» خالق napster که ظاهراً کد نویسی را رها کرده و یک busniess man تمام عیار شده. نمی‌دانم ما هم به عنوان یک برنامه‌نویس می‌توانیم کسوت خودمان را مثل مارک تا آخر حفظ کنیم یا باید مثل «شان» کار برنامه‌نویسی را رها کرده و وارد مدیریت و تجارت شویم.

صحنه آخر فیلم هم بدک نبود. جایی که مارک، دوست دختر اول فیلمش، اریکا را در فیس‌بوک Add as friend می‌کند و هر چند لحظه یک بار صفحه را در انتظار جواب مثبت اریکا refresh می‌کند. اینجا هم منو به یاد اون آهنگ فارسی می‌ندازه که راجع به فیس‌بوک‌بازی و اینترنت‌بازی هستش و توسط اون خواننده‌ای که اسمش یادم نمیاد ولی آهنگ‌های آدم معمولی، ازدواج مثل ی زن چاقه، قانون نمی‌شکنه فقط کمی خم می‌شه، ای داد از عشق که رفت بر باد و… رو اجرا کرده، خونده شده.




2011/05/19

Unique foreign key associations in Castle ActiveRecord

NHibernate have 2 varieties of one-to-one association, primary key associations and unique foreign key associations. Castle ActiveRecord documentation describes just first varity, primary key associations.

But how about second variety, unique foreign key associations? Well, it can be implemented as follow. Please notice sample:


    [ActiveRecord(Lazy = true)]
    public class User : ActiveRecordBase
    {
        [PrimaryKey]
        public virtual long ID { set; get; }

        [Property]
        public virtual string FirstName { set; get; }

        [OneToOne(PropertyRef = "ContainerUser")]
        public virtual Profile ContainerProfile { set; get; }
    }


    [ActiveRecord(Lazy = true)]
    public class Profile : ActiveRecordBase
    {
        [PrimaryKey]
        public virtual long ID { set; get; }

        [Property]
        public virtual string Field1 { set; get; }

        [BelongsTo("ContainerUser", Unique = true, NotNull = true)]
        public virtual User ContainerUser { set; get; }
    }




2011/05/18

‫نرم‌افزارهای UI Mocking

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

بعضی از ابزارهای UI Mocking مخصوص مدل کردن برنامه‌های تحت وب هستند مثل Axure که یک نمونه خوب از این کار است. با کمک بعضی‌های دیگر هم می‌توان برنامه‌های Desktop و ویندوزی را شبیه‌سازی کرد. در ادامه تعدادی از ابزارهای UI Mocking برنامه‌های Desktop:

۱- Visio از مجموعه MS Office: امکانات خوبی برای طراحی UI دارد چه ویندوزی و چه وبی. خروجی Visio فقط در حد عکس قابل استفاده است یعنی نمی‌توان مثل Axure از آن اجرا گرفت.

۲- DesignerVista: برای شبیه سازی برنامه‌های Desktop خیلی مناسب است. خصوصاً که با توجه به تکنولوژی‌های مایکروسافتی و تکنولوژی‌های دات‌نتی مثل SilverLight و… ایجاد شده است. این نرم‌افزار غیر رایگان می‌باشد.

۳- JustInMind:  مشابه DesignerVista است.

۴- DENIM: ابزار دم دستی و رایگانی که بیشتر شبیه یک Paint سازمان دهی شده است ولی کار کردن با آن کمی سخت و عجیب است.




منابع:




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

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 است.




2011/05/17

‫انواع فراخوانی سرویس در WCF

هر سرویسی در WCF شامل تعدادی متود است. سرویس‌ها با ServiceContract و متودها با OperationContract مشخص می‌شوند. فراخوانی Operationها در WCF به چهار روش امکان پذیر است:

۱- Request-Reply: این روش سنتی استفاده از سرویس‌هاست. در این روش کلاینت یکی از Operationهای سرویس را صدا می‌زند. تا زمانی که اجرای این سرویس به اتمام نرسد، خطوط بعدی برنامه اجرا نخواهند شد.

۲- One-Way: در این روش کلاینت یکی از Operationها را فراخوانی می‌کند. ولی برای تکمیل آن منتظر نمی‌ماند. در این روش هیچ اطلاعاتی هم از سرور به کلاینت باز گردانده نمی‌شود.

۳- Callback: در این روش که به نام Duplex هم شناخته می‌شود، یک ارتباط دو طرفه بین کلاینت و سرور برقرار می‌شود. به نحوی که سرور هم بتواند عملیاتی را روی کلاینت انجام دهد. این نوع فراخوانی بر روی Bindingهایی مثل BasicHttp (همان وب سرویس‌ها) کار نمی‌کند.

۴- Event: شباهت زیادی به مدل Callback دارد.

۵- Streaming: این روش مشابه پخش امواج رادیویی است. یک ایستگاه رادیویی امواج را فقط پخش می‌کند و کاری به گیرنده‌ها ندارد. از آن طرف هم هر کدام از گیرنده‌ها به انتخاب خودشان این امواج را دریافت می‌کنند یا نمی‌کنند.


منبع:
فصل ۴ کتاب Oreilly Programming WCF Services




2011/05/16

‫پیغام خطاهای معروف NHibernate - قسمت اول

یکی از معروف‌ترین خطاهای NHibernate خطای زیر است:

No row with the given identifier exists[EntityName#rec_id]
به جای EntityName نام کامل entity و به جای ‎#rec_id شماره رکورد قرار می‌گیرد. این خطا همان طور که پیغامش اشاره می‌کند وقتی به وقوع می‌پیوندد که NH در دیتابیس به دنبال رکورد خاصی می‌گشته ولی آن رکورد در دیتابیس وجود نداشته است. معمولاً می‌توان ردی از Load یا Get را هم در StackTrace پیدا کرد. گاهی اوقات که rec_id چیز عجیب و غریبی باشد، این پیغام خطا گمراه کننده‌تر هم می‌شود. خصوصاً وقتی که از idهای نوع Guid استفاده شده باشد.

این پیغام خطا معمولاً خیلی زیاد به وجود می‌آید. بسیاری از کاربران، خصوصاً آنها که آشنایی کمتری با NH یا ORMها به طور کلی دارند، با دیدن این پیغام خطا دچار اشتباه شده و فکر می‌کنند NH دچار مشکل خاصی شده که باید با تلاش فراوان آن را حل کرد. این خطا در Data Binding صفحات ASP.NET هم خیلی زیاد دیده می‌شود. خصوصاً وقتی که ترتیب Bind کنترل‌ها به هم خورده و کنترلی زودتر از موقع DataBind شده. است. چیزی که خیلی مهم است این است که این پیغام خطا فقط نشانه است که کسی از NH خواسته که رکوردی را از دیتابیس فراخوانی کند. این مشکل NH نیست که آن رکورد وجود ندارد، بلکه خود برنامه باید بررسی گردد تا علت فراخوانی از دیتابیس مشخص گردد.




2011/05/15

‫شرکت‌های «الف» و «ب»

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

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


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

شرکت‌های «الف» مصاحبه‌های راحت‌تری دارند، مسئولین شرکت معمولاً فارغ التحصیلان غیر نرم‌افزار هستند، در انجام پروژه‌ها موفق‌ترند چون هدف آنها صرفاً انجام کار است نه داشتن یک تیم فنی قوی، آموزش نیرو چندان اهمیتی ندارد، وقتی رییس نیست کار تعطیل می‌شود و…

شرکت‌های «ب» دوام کمتری دارند چون بازار ایران تمایل کمتری نسبت به آنها دارد، برنامه‌نویسان آنها self motivated هستند یعنی لازم نیست مدام یک نفر کار آنها را چک کرده یا به آنها یادآوری کند، علاقه به low level، مطالعه و open source در برنامه‌نویسان شرکت بیشتر است و…

اینها نظرات شخصی، خام و اولیه من بودند راجع به انواع شرکت‌ها. نظر شما چیست؟



پ.ن.: حرکت از سمت شرکت‌ها و تیم‌های نوع «الف» به شرکت‌ها وتیم‌های نوع «ب» همواره یکی از انگیزه‌های قوی بنده بوده برای شرکت عوض کردن.




WCF Throttling

فرض کنید که یک سرویس WCF دارید که می‌تواند به ۱۰۰ نفر به طور همزمان خدمات دهد. حال اگر این ۱۰۰ نفر به ۱۱۰ نفر افزایش پیدا کند چه اتفاقی می‌افتد؟ به احتمال زیاد سیستم از کار افتاده، کل ۱۱۰ نفر از خدمات محروم می‌شوند، نیاز به restart سرویس مربوطه پیدا می‌کنید و در نهایت باید به مدیریت سیستم هم در قبال از کار افتادن کلی سرویس جوابگو باشید.

حال مجدداً فرض کنید امکانی وجود دارد که با آن می‌توان سرویس را مجبور کرد که اگر آن ۱۰۰ نفر حد نهایی به ۱۱۰ نفر رسید، سرویس ۱۰۰ نفر اول قطع نشود ولی در عوض آن ۱۰ نفر جدید در صف دریافت سرویس قرار بگیرند. به این ترتیب فقط آن ۱۰ نفر آخر از تاخیر سیستم شاکی خواهند شد و ضمناً سرویس دچار مشکل نخواهد شد. اسم این امکان WCF Throttling است. WCF Throttling می‌تواند از طریق configها محدودیت‌هایی را در تعداد افراد همزمان و خیلی چیزهای دیگر ایجاد کند و اضافه بر آنها را به طور خودکار در «صف دریافت خدمات» قرار دهد.


منبع:
فصل ۴ کتاب Oreilly Programming WCF Services




2011/05/14

‫WCF Durable services چیست؟

در ارتباط با بحث Instance management فرض کنید حالت یک instance را در همه حالات حفظ کنید. مثلاً اگر کلاینت قطع شد یا از یک proxy دیگر استفاده کرد، یا حتی اگر سرور خاموش شد. منظور از حفظ حالت، حفظ اطلاعات داخلی instance آبجکت سرویس مثل فیلدهای private آن است. به این حالت durable service گفته می‌شود.

کاربرد durable serviceها در اجرای اعمال طولانی است که طی آن ممکن است کلاینت یا سرور یا هر دو چندین بار قطع شوند ولی در این حال نمی‌خواهیم کلاینت‌ها مجبور شوند آن کار طولانی را از اول شروع کنند.


منابع:




2011/05/13

‫راه اندازی سرویس SVN در ویندوز

هر چند که با وجود git ممکن است کمتر انگیزه‌ای برای انتخاب SVN به عنوان یک سورس کنترل جدید وجود داشته باشد، اما به هر حال اگر نیاز به نصب SVN به عنوان یک سرویس ویندوز باشد می‌توان از راهنمای خوب Jeff Atwood برای این کار استفاده کرد.

این راهنما به طور خلاصه شامل دو مرحله است. اول ایجاد سرویس با کمک ابزار sc و دوم راه اندازی آن با کمک ابزار net. البته اگر با ویندوزهای جدیدتر مثل ویندوز ۷ یا ویندوز ۲۰۰۸ سر و کار دارید، باید حواستان باشد که این ویندوزها هم ip v4 را پشتیبانی می‌کنند و هم ip v6 را. بنابراین باید به هنگام ایجاد سرویس به svn بگویید حواسش به ipهای نسخه ۴ باشد یا نسخه ۶. جهت کسب اطلاعات بیشتر به اینجا مراجعه کنید.

پ.ن.: راه حل مربوط به ipهای نسخه ۴ و ۶ را ناصر حاجلو زحمت کشیده و پیدا کرده.




2011/05/12

WCF Instance Management

هر سرویسی در WCF توسط یک کلاس ارائه می‌شود. مثلاً فرض کنید که سرویسی برای محاسبه حقوق یک کارمند وجود دارد. پیاده‌سازی این سرویس می‌تواند به شکل متودی از یک کلاس فرضی به نام CalcClass باشد. وقتی که کلاینتی به سرویس WCF مورد نظر وصل شده و یکی از متودهای آن را فراخوانی نماید، WCF یک instance از کلاس CalcClass ایجاد کرده و متود مورد نظر کلاینت را از آن فراخوانی می‌نماید. این موضوع که روش ایجاد instance به ازای هر درخواست است یا به ازای هر کلاینت یا…، روش Instance Management نام دارد.

در WCF سه نوع روش instance گیری موجود است:

۱- به ازای هر درخواست: Per-Call
۲- به ازای هر کلاینت: Per-Session
۳- یکی به ازای کل Application (برنامه): Singleton

هر کدام از این روش‌ها مزایا و معایب خودشان را دارد. مثلاً روش Per-Call کمی Performance کمتری دارد ولی Scalable است. روش Per-Session حتی روی پروتکل Web Service هم کار می‌کند اما کمی overhead دارد. روش Singleton به شدت مشکل Performance دارد ولی برای Applicationهایی مثل کار با پورت سخت‌افزار یا کنترل موتور مکانیکی فقط یک منبع دارند مناسب‌تر است.


منبع:
فصل ۴ کتاب Oreilly Programming WCF Services




2011/05/11

WCF Per-Session instance management

Per-Session یکی دیگر از انواع Instance Management در WCF است. در این روش به ازای هر کلاینت (پراکسی) یک instance از آبجکت سرویس ایجاد می‌شود. Per-Session به عنوان یک روش statefull معادل روش برنامه‌نویسی Client-Serverی کلاسیک است. که در آن را کلاینت به سرور وصل شده و شروع به ارسال درخواست‌هایش می‌کند بدون آن که سرور بخواهد به ازای هر یک از درخواست‌ها یک session جدید ایجاد کند.

از Per-Session نمی‌توان روی همه پروتکل‌ها (Bindingها) استفاده کرد. مثلاً استفاده از آن با BasicHttpBinding که همان وب سرویس معمولی است امکان پذیر نیست. دلیل آن هم ماهیت stateless بودن پروتکل HTTP است. در روش Per-Session هم سرور و هم کلاینت می‌توانند به SessionId دسترسی پیدا کرده و از آن استفاده نمایند.


[ServiceContract(SessionMode = SessionMode.Allowed)]
interface IMyContract
{...}
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)]
class MyService : IMyContract
{...}




2011/05/10

WCF Per-Call instance management

Per-Call اصلی‌ترین نوع instance management سه‌گانه در WCF است. در این روش با هر request کلاینت، یعنی با فراخوانی هر یک از متودهای سرویس، یک instance از object سرویس ایجاد شده و پس از اتمام درخواست آن instance از بین می‌رود. روش Per-Call نسبت به بقیه دارای مزایایی است از جمله مشغول نگه نداشتن منابع سرور و Scalable بودن application. به این معنی که می‌توان سرویس WCF را روی چند سرور host کرده و یک Load Balancer درخواست‌ها را بین آنها تقسیم کند تا Performance بهتری به دست بیاید.

برای حفظ state در روش Per-Call می‌توان از کلاینت فراخوانی کننده یک چیزی شبیه به ID دریافت کرده و state کلاینت مورد بحث در جایی در سرور ذخیره کرد. تنظیم یک سرویس برای Per-Call بودن به این شکل است:
[ServiceContract]
interface IMyContract
{
[OperationContract]
void MyMethod();
}
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
class MyService : IMyContract,IDisposable
{
int m_Counter = 0;
MyService()
{
Trace.WriteLine("MyService.MyService()");
}
public void MyMethod()
{
m_Counter++;
Trace.WriteLine("Counter = " + m_Counter);
}
public void Dispose()
{
Trace.WriteLine("MyService.Dispose()");
}
}




2011/05/09

‫Burn down chart دقیق در TFS

Burn down chart یکی از ابزارهایی است که در اسکرام برای مشاهده و پیش بینی روند پیشرفت اسپرینت به کار برده می‌شود. اگر برای اسکرام از TFS 2010 و قالب Scrum for Team System استفاده می‌کنید، رعایت نکات زیر لازم می‌شود تا نمودار دقیقی داشته باشید.

۱- قبل از شروع هر اسپرینت، یعنی قبل از این که وضعیت آن از Not Started به In Progress تغییر کند، زمان‌های Estimation effort و Remaining Work را در تک تک SBTها به طرز صحیح وارد کنید و سعی کنید آنها را تغییر ندهید. در غیر این صورت نمودار شما به جای این که رو به پایین باشد رو به بالا خواهد بود:



۲- وارد کردن درست تاریخ‌ها و دیگر اطلاعات اسپرینت هم فراموش نشود.

۳- اعضای تیم نباید یادشان برود که وضعیت PBI/SBTها را از حالت Not Started خارج کرده و به وضعیت‌های In Progress یا Done ببرند. در غیر این صورت نمودار هرگز به روز نشده و فقط یک خط افقی را نمایش خواهد داد.



۴- اعضای تیم باید وضعیت هر PBI/SBT را درست همان موقع که شروع می‌کنند یا به پایان می‌رسانند به روز رسانی کنند. در غیر این صورت نمودار Burn down chart غیر واقعی خواهد بود.


۵- گزارش Burn down chart تا زمانی که تاریخ شروع اسپرینت فرا نرسیده و وضعیت اسپرینت مورد نظر از حالت Not Started خارج نشده باشد چیز مفهومی را نشان نخواهد داد. چه شیب صحیح و چه مجموع ساعات کاری:



۶- هر چقدر که PBIها به SBTهای ریزتری شکسته شده باشند، دقت Burn down chart بالاتر خواهد رفت.

۷- در نهایت اگر موارد نیاز رعایت شده باشد نموداری شبیه به نمودار زیر به دست خواهد آمد:




پ.ن.: در اسکرام هر پروژه به تعدادی اسپرینت معمولاً دو هفته‌ای، هر اسپرینت به تعداد Backlog Item یا PBI و هر PBI به تعداد Task یا SBT تقسیم می‌شود. هر PBI نمایانگر یکی از سناریوهای مشتری مثل «مدیریت کاربران» یا «پرداخت وام» است و معمولاً پیاده‌سازی آن ۲ تا ۳ روز طول می‌کشد. هر SBT هم معمولاً ۴ تا ۶ ساعت زمان می‌برد.




2011/05/07

‫Green Hopper، ابزار مدیریت پروژه Agile در JIRA

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

در نسخه‌های اخیر JIRA یک Add-in برای مدیریت پروژه به سبک Agile/Scrum اضافه شده به نام Green Hopper. اگر کمی با اسکرام و Task Board آشنا باشید و نگاهی به عکس‌ها و ویدئوهای Green Hopper بیندازید متوجه خواهید شد که با کمک این ابزار چقدر اسکرام در JIRA راحت شده است.

جهت کسب اطلاعات بیشتر:

۱- ویدیوی معرفی Green Hopper

۲- Green Hopper
۳- جیرا
۴- چند نمونه عکس










2011/05/05

‫مشکل Stack Overflow در NHibernate

به تجربه دریافته‌ام هر وقت که در NHibernate/Castle AR بدون هیچ دلیل واضحی مشکل Stack Overflow به وجود می‌آید، باید مکانیزم Dirty detection را بررسی کرد. در این مکانیزم، NH خودش objectهایی را که dirty شده‌اند را پیدا کرده و آنها را update می‌کند.

بعضی وقت‌ها پیش می‌آید که update شدن یک آبجکت dirty باعث dirty شدن یک جای دیگر شده و آن هم به نوبه خودش نیاز به update پیدا کرده و این زنجیره آنقدر ادامه پیدا کرده که برنامه در loop افتاده و در اثر Stack Overflow از کار می‌افتد. البته مشکل همیشه دقیقاً به همین حالت نیست اما علت خطا کم و بیش همین است.

به عنوان مثال فرض کنید که برای به روز رسانی یک entity نیاز دارید به دیتابیس مراجعه کرده و چیزی را در آنجا چک کنید. با اولین مراجعه به دیتابیس، NH اول به طور خودکار session را flush کرده و بعد از آن اطلاعات را از دیتابیس فراخوانی می‌کند. اما به هنگام flush شدن، entity مورد نظر ما هنوز dirty است و نیاز به ذخیره در دیتابیس دارد. این روال باعث به روز رسانی زنجیره‌ای entity شده و در نهایت باعث بروز stack overflow می‌گردد.

یکی از راه حل‌های رفع این مشکل استفاده از sessionهای مستقل از هم است. چون dirty checking هر sessionی مستقل از sessionهای دیگر است. در Castle AR می‌توان از روشی مشابه زیر استفاده کرد:
using (new SessionScope())
{
//do something with this separate session
}
پ.ن.: به این لینک هم نگاهی کنید.




2011/05/03

از این شرکت به اون شرکت

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

در بعضی شرکت‌ها رفت و آمد پروژه و پول خیلی خوب است اما تیم فنی خیلی ضعیف است. در بعضی شرکت‌ها تیم فنی خیلی خوب کار می‌کند اما مدیریت شرکت ضعیف است. در بعضی شرکت‌ها انضباط (Disipline) بسیار خوبی حاکم است اما بعضی تصمیم گیری‌های تکنولوژیک کار را به بیراهه می‌کشاند. در بعضی شرکت‌ها پول، نیروی انسانی خوب و شهرت کافی وجود دارد اما بی‌نظمی کار را خراب می‌کند. در بعضی شرکت‌ها…



واقعاً چرا؟




2011/05/01

‫‫در عجبم از…

در عجبم از کسانی که موبایلشان همیشه به روز است و بیش از یکی دو مدل عقب نمی‌افتد، همیشه در جریان آخرین اخبار فوتبال، لباس، مد، لوازم آرایش، فیلم‌های سینمایی و شایعات بازیگرها هستند، از ریزترین اخبار همسایه‌ها و فامیل با خبرند، کارت گرافیک و هارد کامپیوترشان، رینگ ماشینشان و هزاران چیز دیگرشان به روز به روز است ولی هنوز در دنیای برنامه‌نویسی از دات‌نت فریمورک ۲، ویندوز ۲۰۰۳، SQL Server 2005، ویژوال استودیو ۲۰۰۸، Source Safe و چندین مورد عهد بوقی دیگر استفاده می‌کنند.

در عجبم از کسانی که ویندوزشان ۲۰۰۸ و ویندوز ۷ است، از ویژوال استودیو ۲۰۱۰، SQL Server 2008 R2، TFS 2010 یا git آخرین نسخه و سایر ابزاهای روز تولید نرم‌افزار استفاده می‌کنند ولی روش برنامه‌نویسی، تولید نرم‌افزار و مدیریت پروژه‌شان اقلاً ۱۵ سال عقب است. هنوز که هنوز است فقط ظاهر کدشان Object Oriented است نه اصل کد آنها. هنوز هم برای مشتری DFD (یکی دو نسل قبل از RUP و Agile) می‌فرستند…


در عجبم از کسانی که…