2011/07/25

An open letter to oDesk from an Iranian software developer

Dear oDesk managers,

I'm an Iranian software developer living and working in Tehran/Iran. Recently I opened an account in oDesk and started to bid on oDesk projects as a contractor. But unfortunately oDesk has suspended my account just because I'm an Iranian.

I can't realize why I can't work in oDesk like many other people all around the world including Pakistan, Latin America, Egypt, Ukraine, India, etc? What is difference between them and us? I know about Iran Sanctions Act (ISA), but we, the people of Iran not the government, do not deserve it. In Iran, a very few software developers work directly for government or government organizations. While American and Iranian politicians hate each other, why we, the people of Iran must be sacrificed? Why we must pay for it?

Please watch software developers of Iran more carefully, we don't program for nuclear weapons, mass destruction weapons or anything else dangerous for people of world. Main stream of software development in Iran is LOB applications deployed in boring offices manipulating personal data, banking data, accounting data and any none military data. Why you are think these poor and peaceful software developers are dangerous to other people?

I beg you think twice...


Best Regards,
A peaceful Iranian software developer,
Afshar Mohebbi




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

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


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

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


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


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


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




2011/07/19

گناهی به اسم ایرانی بودن

odesk سایتی است مشابه vworker که برای برون‌سپاری پروژه‌های نرم‌افزاری و غیره به برنامه‌نویسان Freelance سراسر دنیا استفاده می‌شود. عمده contractorهای این طور سایت‌ها از کشورهای ارزان قیمتی مثل هند، روسیه، شرق اروپا، آمریکای لاتین و کشورهای عربی مثل مصر هستند. دیروز پروفایلم را در odesk تکمیل کردم، البته آدرسم را در دوبی دادم و تنها یک شماره تلفن از ایران (با کد ۹۸) دادم. نمی‌دانم از روی کد کشور یا از روی IP به ایرانی بودن و در نتیجه مجرم بودن بی‌دلیلم پی برده‌اند و ایمیل زیر را برای من فرستاده‌اند:







دقت کنید که برای درست و حسابی کار کردن در odesk باید identity خودتان را verify کنید. برای verfiy کردن هم عملاً نیاز به passport و اینجور حرف‌ها می‌شود که…





2011/07/18

‫NHibernate session management در محیط‌های مختلف

مهم‌ترین مسئله‌ای که در Session management در NHibernate وجود دارد، مسئله نگهداری session است. به طور معمول سعی می‌شود برای انجام یک کار فقط یک session باز شود نه بیشتر. اگر طی انجام همان کار مجدداً نیاز به session شد از همان session قبلی استفاده می‌شود نه این که یک session جدید open شود.

این کار در وب خیلی راحت است. session instance مورد نظر در HttpContext قرار داده می‌شود. در مورد ویندوز و WCF هم کار چندان سختی نیست. چون از Thread برای نگهداری session استفاده می‌شود. اما موقعیت‌هایی وجود دارد که می‌خواهیم به طور هم زمان در دو محیط از یک Session Factory و Session استفاده نماییم. مثلاً هم وب را داریم و هم یک سرویس WCF را.

این طور وقت‌ها می‌توان یک SessionContext سفارشی ساده ساخت که هم session را در HttpContext نگاه داشت و هم در جای دیگری که در محیط مورد نظر معنی دار است. اصل این راه حل در اینجا توضیح داده شده.




2011/07/11

‫راه ابتکاری برای تبدیل تاریخ میلادی به تاریخ شمسی در SQL Server

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

در دیتابیس فوق‌الذکر برای تبدیل تاریخ میلادی به تاریخ شمسی از یک جدول ۵۱ هزار رکوردی استفاده شده بود. این جدول دو ستون داشت. یکی تاریخ میلادی و دیگری تاریخ شمسی. اولین رکورد با ۱۹۰۰٫۱٫۱ و تاریخ معادل شمسی آن شروع می‌شد. هر رکورد بعدی روز بعدی را نشان می‌داد. این روال تا روز میلادی ۲۰۴۱٫۳٫۱۹ و معادل شمسی آن ادامه داشت. حالا خودتان select مربوطه را حدس بزنید!




2011/07/10

‫‫مطالعه موردی شماره ۹ vWorker: ماریانو ایگلسیاس و کلودیا مانسیلا (کریکاوا)

vWorker یکی از سایت‌های معروف برون‌سپاری پروژه‌های نرم‌افزاری است. جهت آشنایی بیشتر با آن و مدل کاریش، یکی از آخرین پست‌های وبلاگ آنها را ترجمه و در اینجا می‌گذارم. این نوشته مصاحبه‌ای با یکی از موفق‌ترین پیمانکاران (worker, employee) سایت vWorker است.

--------------------

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


ماریانو ایگلسیاس و کلودیا مانسیلا (از موسسین کریکاوا):

ماریانو ایگلسیاس و کلودیا مانسیلا که با نام کاربری cricava در vWorker حضور دارند، فعالیت جدی‌شان را از سال ۲۰۰۵ شروع کردند. آنها با مناقصه روی پروژه‌های کوچک‌تر شروع کردند تا بتوانند سابقه خوبی برای خودشان درست کنند. البته آنها بدون آن که به کوچک بودن پروژه اهمیت بدهند سعی می‌کردند سرویس بسیار خوبی به کارفرمایشان ارائه دهند. آنها بالاخره توانستند پروژه‌های بزرگ هم بگیرند. اعتماد و اعتبار کسب شده باعث شد بتوانند درآمد خوبی کسب کنند. کریکاوا در می ۲۰۱۰ به رتبه شماره یک vWorker رسید و هنوز هم در این رتبه باقی مانده است.


ماریانو و کلودیا به تعدادی از سوالات ما پاسخ داده‌اند:

۱- چرا وارد vWorker شدید و چطور آن را پیدا کردید؟

ما vWorker را به طور اتفاقی در اواخر ۲۰۰۳ پیدا کردیم. درست بعد از ثبت نام در سایت، یک پروژه محلی پیدا کردیم و بی‌خیال vWorker شدیم. اما از اوایل ۲۰۰۵ دوباره شروع به کار با vWorker کردیم. ما فهمیدیم که vWorker فرصت‌های بی‌نظیری برای ما فراهم کرده است. پس هر روز وقت بیشتری برای مناقصات گذاشتیم تا جایی که تصمیم گرفتیم تنها منبع کارمان vWorker باشد. سوددهی ما از چند ماه بعد شروع شد چون پروژه‌های اولیه‌ای که می‌گرفتیم کوچک بودند و پول زیادی بابت آن نمی‌گرفتیم. با این وصف همیشه سعی می‌کردیم چیزی فراتر از آنچه که مشتری می‌خواست به او بدهیم.

بازخورد بسیار مثبتی که مشتریانمان ارائه می‌دادند کمک می‌کرد تا بتوانیم در مناقصات بزرگتری شرکت کنیم. اعتماد مثبتی که بین مشتریان ما ایجاد شده بود باعث می‌شد تا بتوانیم درآمد خوبی کسب کنیم بخصوص این که بعضی مشتری‌ها صرفاً به خاطر این که بتوانند با ما کار کنند وارد vWorker می‌شدند. در اواخر ۲۰۰۵ ما جز ۲۵۰ پیمانکار برتر vWorker بودیم. دوران جالبی پیش روی ما بود.

با افزایش معروفیت ما و با توجه به تعداد قابل توجه مشتری‌های ثابتی که داشتیم در سال ۲۰۰۶ فهمیدیم که با کار مداوم و پیوسته نه تنها می‌توان پول درآورد بلکه می‌توان هر روز در رتبه‌بندی‌ها مقام بهتری کسب کرد تا این که نهایتاً در می ۲۰۱۰ به رتبه شماره یک رسیدیم.

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


۲- چه توصیه‌هایی برای کسانی که می‌خواهند راه شما را طی کنند دارید؟

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

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

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


۳- جالب‌ترین خصوصیت vWorker از نظر شما چیست؟

Arbitration. چیزهای خیلی زیادی در مورد یک پروژه هست که ممکن است اشتباه باشند. در این طور موارد داشتن حفاظت مناسب بسیار مفید است. بدون arbitration غیر ممکن بود که ما از vWorker استفاده کنیم.


۴- تجربه شما در مورد mediation/arbitration چه بوده؟


ما mediationها و arbitrationهای زیادی داشته‌ایم. ما حتی یکی را هم از دست نداده‌ایم چون همیشه از قوانین vWorker پیروی کرده‌ایم. ما با قطع ارتباطات خارج سایتی همیشه توانسته‌ایم همه ادعاهایمان را ثابت کنیم.

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


۵- آیا تکنیک، روش، راه یا راز خاصی در مورد vWorker هست که بخواهید آن را با دیگران به اشتراک بگذارید؟

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


۶- آیا داستان یا خاطره‌ای از کارفرماها یا پروژه‌ها دارید؟

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

مهربانی به وضوح به کمک‌تان می‌آید و ارزشش را دارد.




2011/07/09

تویتر: راه ارتباطی راحت‌تر از وبلاگ‌نویسی

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

۱- کیوان نیری
۲- اسکات هنزلمن
۳- علی اقدم
۴- مهدی تقی‌زاده
۵- ناصر حاجلو
۶- مسعود رمضانی
۷- جف اتوود
۸- ریک استرال
۹- افشار محبی (اینجانب)
۱۰- اسکات کان
۱۱- مارتین فولر
۱۲- سپهر لاجوردی
۱۳- اشکان روشنایی
۱۴- هادی اسکندری
۱۵- سهیل رشیدی
۱۶- سروش ایوبی
۱۷- حامد سعیدی فرد
۱۸- مجید آواژ (بهساد)
۱۹- جو استنگر
۲۰- صالح سوزنچی
۲۱- سلمان عرب عامری
۲۲- بهنام بهمنی

ضمناً اگر خود شما اکانت تویتر دارید و راجع به برنامه‌نویسی و نرم‌افزار تویت می‌کنید یا تویتر شخص دیگری با همین خصوصیات می‌شناسید، لطف کنید بگویید تا به این فهرست اضافه کنم.




‫programmers.stackexchange.com جای جالبی است

بیشتر برنامه‌نویس‌ها StackOverflow.com را می‌شناسند، مزایایش را می‌دانند و از آن استفاده کرده‌اند. اما شاید خیلی‌ها ندانند سایت مشابه آن یعنی programmers.stackexchange.com هم چیز جالبی است و سوال و جواب‌های جالب و مفیدی در آن یافت می‌شود. به عنوان نمونه به سوالات زیر دقت کنید:


۱- آیا یاد گرفتن هم زمان دو زبان برنامه‌نویسی کار درستی است؟

۲- چه کار کنم تا کیفیت کد در تیم برنامه‌نویسی بالا برود؟

۳- آیا زیبا بودن ظاهری کد ارزشی دارد؟

۴- همکار (برنامه‌نویس) من از روش‌های بدی برای کد نویسی استفاده می‌کند. چه باید کرد؟

۵- آیا برون‌سپاری پروژه‌های نرم‌افزارهای به کشورهای خارجی، نوعی خیانت به کشور خودم و هم وطنانم محسوب می‌شود؟

۶- من در زمان مصاحبه گاف‌های بدی داشته‌ام ولی استخدام شده‌ام. آیا باید از مدیر جدیدم خجالت بکشم؟

۷- آیا استفاده از مونو در یک پروژه تجاری با توجه به خطر ادعای مایکروسافت به آن کار درستی است؟

۸- علاقه‌ام رو به برنامه‌نویسی از دست دادم. حالا چه کار کنم؟

۹- چطور مدیرم را متقاعد کنم که کیفیت در کد چیز با ارزشی است؟

۱۰- چرا گفته می‌شود که مرکوری از گیت راحت‌تر است؟

۱۱- من مجبور شده‌ام که کد نویسی را با کیفیت پایین انجام دهم. حال چه می‌شود کرد؟

۱۲- آیا TDD در مقابل بهره‌وری قرار می‌گیرد؟





چند آگهی استخدام جالب توجه

از وقتی که کارویس رو شروع کردم گهگاه به آگهی‌های جالبی برمی‌خورم. به عنوان نمونه:


۱- برنامه نویس مسلط به C#‎ و Delphi بااسکان در محل کار و مزایای عالی: هیچ وقت فکر نمی‌کردم روزی آگهی استخدام برنامه‌نویس با جای خواب ببینم. درست مثل کارگر ساده با جای خواب، کارگر رستوران کم سن و سال شهرستانی با جای خواب نیازمندیم.

۲- برنامه نویس حرفه ای آقا , مسلط به PHP,Drupal , Android,ios,Java , ActionScript3,J2ME , C,Python,.Net: فکر نمی‌کردم به این زودی‌های آگهی استخدام Android و iOS رو ببینم.

۳- برنامه نویس (خانم) , مسلط به Net. , و آشنا به Delphi: نمی‌دونم چرا بعضی‌ها تاکید دارند که برنامه‌نویس‌هایشان فقط خانم باشد. مگر مشکل خاصی با آقایون دارند؟ مگر نه این که معمولاً محدودیت‌های آقایان، مثل ماموریت، ساعات کاری و محیط کاری کمتر از خانم‌هاست؟

۴- به یک برنامه نویس حرفه ای نیازمندیم: از بعضی آگهی استخدام‌ها هیچ اطلاعاتی در نمی‌آید. حتی زبان برنامه‌نویسی مورد نیاز.

۵- اوضاع WCF با وجود جدیدن بودنش چندان بد نیست.

۶- آگهی‌های استخدام منتشره در نیازمند‌های همشهری بیشتر راجع به دات‌نت است تا جاوا.




جایگزینی اصول مهندسی نرم‌افزار با ابداعات و روش‌های نادرست و رنج حاصله

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

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

به عنوان مثال آنها مثل من و مدیران من نگران تغییرات در نرم‌افزار نیستند. چون از چیزی به اسم unit test استفاده کرده و این unit testها را هم به نحوی به ابزار buildی مثل TeamCity یا TFS معرفی کرده‌اند. هر وقت که check-inی در سورس کنترل برنامه اتفاق بیفتد، نتیجه تغییر حاصله در تمام unit testها بررسی شده و درست بودن یا نبودن تغییر بلافاصله مشخص می‌شود. حال من برنامه‌نویس ایرانی از همه جا بی‌خبر هم می‌خواهم مثل اونها در برنامه‌ام تغییر ایجاد کنم بدون داشتن این همه ترس. اما نمی‌توانم. چون آن‌ها ساختار و روش‌شان را برای استفاده از unit test آماده کرده‌اند. مثلاً بدنه متودها را کوچک نگه داشته‌اند، اصل Separation of Concern را رعایت کرده‌اند، در صورت لزوم از Mocking استفاده کرده‌اند و غیره و غیره. از این دست مثال‌ها زیاد می‌توان پیدا کرد.

این روزها این رنج را بیش از بیش احساس می‌کنم. اما نمی‌دانم با آن چه کنم. آیا چاره کار Freelance شدن است؟ آیا چاره کار عوض کردن شغل است؟ آیا چاره کار همکاری با پروژه‌های Open Source و در نیاوردن پول است؟ آیا چاره کار مهاجرت است؟ آیا چاره کار تاسیس شرکت شخصی و قبول همه مصائب شرکت‌داری است و پروژه گرفتن است؟ آیا …؟




‫NHibernate Session Management در Winform و WCF

بحث NHibernate Session Management در برنامه‌های وب اصلاً کار سختی نیست. روتین‌ها و نمونه‌های زیادی هم در مورد آن وجود دارد. اما انجام همین بحث در Winform و WCF کمی کار می‌برد. یکی از بهترین روش‌ها برای مدیریت Session در NHibernate استفاده از الگوی Unit Of Work است. تطبیق این الگو با مدل کاری وب خیلی ساده است. فقط کافی است فرض کنید شروع هر unit of workی با شروع Web Request توسط کاربر و پایان آن با رندر صفحه و ارسال آن به کلاینت منطبق است.

برای ویندوز و WCF هم که از بسیاری جهات به هم شبیه هستند چند روش وجود دارد. یکی از این راه‌ها conversation per business transaction یا CpBT است. در CpBT منطق کاری (business transaction) مبنای کار است. یعنی شروع unit of work با شروع عملیات کاری و پایان آن با پایان عملیات کاری اتفاق می‌افتد. به عنوان مثال فرض کنید یک منطق یا روال کاری داریم به نام «محاسبه حقوق ماهیانه شخص فلان». در CpBT شروع unit of work وقتی است که کاربر از طریق winform یا wcf روال «محاسبه حقوق» را شروع می‌کند. به عبارت دیگر شروع روال «محاسبه حقوق» توسط کاربر باعث می‌شود یک session از NHibernate دریافت شده و یک Transaction شروع شود. حال هر وقت که کاربر پایان کار را با مثلاً فشردن دکمه تایید به پایان رساند، پایان unit of work هم فرا رسیده و کارهای مرتبط با آن مثل commit شدن transaction هم انجام می‌شود. دقت شود که اگر از الگوی CpBT استفاده نمی‌شد ممکن بود در حین کاری مثل محاسبه حقوق که چندین و چند مراجعه به دیتابیس و چند modify اطلاعات دارد، مجبور شویم چندین session از NHibernate گرفته و چندین بار commit transation داشته باشیم. که هم کار را خیلی کند می‌کند و هم مدیریت transactionها را غیر ممکن می‌کند.

برای اعمال CpBT در NHibernate و WCF و Winform یک کتابخانه مفید به نام uNhAddins وجود دارد. این کتابخانه تمام این کار را اتوماتیک می‌کند. مثلاً برای آن که بگویید یک متودی از یک کلاس برابر است با نقطه شروع یک CpBT فقط کافی است روی کلاس آن عبارت

[PersistenceConversational(MethodsIncludeMode = MethodsIncludeMode.Implicit)]

و روی متود آن عبارت

[PersistenceConversation(ConversationEndMode = EndMode.End)]

را قرار دهید. البته نیاز به کدها و تنظیمات دیگری هم وجود دارد. از جمله این که اگر WCF کار می‌کنید، از uNhAddIns.SessionEasier.Contexts.ThreadLocalSessionContext به عنوان current_session_context_class در تنظیمات NHibernate استفاده کنید و اگر از WinForm استفاده می‌کنید از uNhAddIns.SessionEasier.Conversations.ThreadLocalConversationalSessionContext استفاده کنید.


به عنوان یک نمونه کامل uNhAddins و CpBT که هم WCF را پوشش می‌دهد، هم WPF را، هم MVP را و هم IoC را، نگاهی به نمونه کد uNHAddins.Examples.SessionManagement در مخزن کد uNhAddins بیندازید.




2011/07/07

یک سال در پرشیا شبکه


موسسه اطلاع‌رسانی مهندسی پزشکی پرشیا شبکه  که به اختصار پرشیا شبکه (PersiaBME) نامیده می‌شود نام شرکتی است که کم و بیش یک سال در آنجا کار کرده‌ام و حالا که همکاری تمام وقتم با پرشیا شبکه قطع شده است وقت آن رسیده است که مروری داشته باشم بر این یک سال.

عمده فعالیت پرشیا شبکه همان طور که می‌توان از اسمش حدس زد در حوزه شرکت‌ها و موسسات تجهیزات پزشکی است. اما این همه ماجرا نیست. پرشیا شبکه روی طیف متنوعی از نرم‌افزارهای تحت وب غیر پزشکی از جمله هتل‌داری، انتشارات و… هم کار می‌کند.

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

یکی دیگر از مزایای مهم پرشیا شبکه امکان بهره‌برداری از فناوری‌ها و روش‌های روز تولید نرم‌افزار است. همین قدر اشاره کنم که از کلیه امکانات TFS 2010 از جمله build اتوماتیک، continuous integration و work item management بر اساس اسکرام به طور کامل استفاده می‌شود و تقریباً بیشتر جاها از NHibernate استفاده شده است.

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

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

با همه خوبی‌ها و بدی‌ها، به پرشیا شبکه بدرود می‌گویم. به پرشیا شبکه‌ای که با داشتن کمترین رانت (تا آنجا که من می‌دانم) همیشه به فکر کسب رضایت مشتری‌هایش بوده است. بدرود!

پ.ن. ۱: فکر می‌کنم پرشیا شبکه هنوز هم در حال جذب نیروی جدید برنامه‌نویس باشد. لطفاً رزومه‌هایتان را به آدرس info atsign persiabme dot com بفرستید. جهت کسب اطلاعات بیشتر به اینجا مراجعه کنید.

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




‫راه‌هایی برای دینامیک کردن entityهای NHibernate

فرض کنید تعدادی کلاس سی‌شارپ را با استفاده از Reflection.Emit در زمان اجرا (Runtime) ساخته‌اید. این یعنی کلاس‌ها دینامیک بوده و هیچ سورس کدی وجود ندارد، بلکه همه چیز فقط در حافظه وجود دارد یا نهایتاً فایل dll اسمبلی آن را بتوان در دیسک ذخیره کرد. حال می‌خواهیم برای این کلاس‌های دینامیک HBM یا همان فایل mapping مربوط به NHibernate را هم داشته باشیم. هدف نهایی این است که این کلاس‌ها از طریق HBM به یک سری جداول دیتابیسی map شده و بتوان با NHibernate با آن‌ها کار کرد. دقت کنید که نمی‌توان HBMها را از قبل داشت چون خود entityها از قبل وجود ندارند. ما هیچ اطلاعاتی راجع به نام آنها، پراپرتی‌ها، نوع آن‌ها یا دیگر مشخصات آن‌ها نداریم.

من برای انجام این امر یعنی داشتن mapping دینامیک برای entityهای دینامیک زمان Runtime چندین راه را امتحان کردم. با اینکه بیشتر آن‌ها به جواب نرسیدند اما هر کدام نکات جالبی داشتند:

۱- استفاده از فیلدهای XML: اگر تعداد جداول خیلی زیاد شوند، هم نگهداری آن‌ها سخت می‌شود و هم نوشتن queryهای آن خیلی خیلی سخت می‌شود.

۲- تولید کد کلاس سی‌شارپ و HBM با ابزارهایی مثل T4 یا CodeDOM و build آن‌ها و خوراندن آن‌ها به AppDomain جاری: سرعت خیلی پایینی خواهد داشت، احتمالاً دسترسی‌های خاص هم نیاز خواهد داشت. هر تغییری در ساختار entityهای دینامیک موجب restart شدن application خواهد شد. تولید کد کار چندان ساده‌ای نیست.

۳- استفاده از آبجکت دینامیک دات‌نت که از نسخه ۴ اضافه شده است: قابلیت توسعه و دینامیک بودن را در حد fieldها و propertyها می‌دهد. نمی‌توان در زمان اجرا mappingهای جدید اضافه کرد.

۴- استفاده از فیلدهای IDictionary: همان مشکلات راه حل آبجکت دینامیک دات‌نت را دارد.

۵- استفاده از قابلیت جدید mapping by code در NHibernate یا ConfORM یا Fluent NHibernate: به هدف خیلی نزدیک است، چون همه چیز بر اساس type است و هیچ HBMی وجود ندارد. اما تولید delegateها و lambda expressionهای مورد نیاز به صورت runtime اگر کار غیر ممکنی باشد حتماً کار سخت و پیچیده‌ای خواهد بود. در مورد Automapping موجود در FNH کار را خوب راه می‌اندازد اما انعطاف پذیری آن با توجه به محدودیت‌های این کار، آن را غیر قابل استفاده می‌سازد.

۶- استفاده از SetResultTransformer موجود در NHibernate برای query زدن روی جداول دیتابیس بدون نیاز به داشتن Entityها. تا اندازه زیادی جواب می‌دهد! ولی زیادی ساده و بی‌ساختار است. نیاز به نوشتن مقادیر زیادی SQL هم دارد.

۷- کلاس‌های تولیدی توسط Reflection.Emit از همان ابتدا به صورتی باشد که روی تعریف کلاس‌ها و memberها از Attributeهای خاص Castle ActiveRecord استفاده شده باشد. این راه چندان بد به نظر نمی‌رسد اما دو تا مشکل دارد: ۱- استفاده اجباری الگوی Active Record ۲- وابستگی به پروژه Castle ActiveRecord.

۸- ساختن کلاس Mapping از Namespace خود NHibernate: این اولین راهی بود که امتحان کردم. مبنای اولیه کار نمونه کد Ayende Rahien بود. اما متأسفانه به هیچ وجه نتوانستم آن کد را اجرا کنیم. با وجود این گزینه هنوز گزینه خوبی به نظر می‌رسد.

۹- ایده گرفتن از کدهای FNH و ConfORM و Castle ActiveRecord و حتی خود NHibernate: این پروژه در داخل خود کدهایی برای کار با Mappingها دارند. اما حجیم بودن کد آن‌ها مانع از استفاده راحت از آن‌ها می‌شود.

۱۰- استفاده از کتابخانه‌های 3rd party تولید HBM از جداول دیتابیسی: این راه را فقط به عنوان رزرو اینجا آورده‌ام و اصلاً نمی‌دانم که آیا چنین کتابخانه‌هایی وجود دارند یا نه.




‫استفاده از Fluent NHibernate

از همان اولین باری که اسم Fluent NHibernate را شنیدم فکر کردم چیز جالبی نیست. نمی‌دانم چرا، شاید به خاطر آن که فکر می‌کردم انعطاف‌پذیری را فدای راحتی کرده یا شاید هم به خاطر غرور low level.

طی مدت اخیر که به دنبال راهی برای dynamic کردن entityهای NHibernate بودم خود به خود مجبور شدم مروری به همه راه‌حل‌های mapping از جمله Fluent NHibernate داشته باشم.

طی این مرور بودم که فهمیدم FNH آنقدر هم که فکر می‌کردم بد نیست، اولاً به خاطر این که Auto Mapping دارد. دوم به خاطر این که Fluent mapping آن سادگی و خوانایی نسبتاً قابل قبولی نسبت به HBM دارد.

FNH سه راه برای mapping دارد: Auto Mapping، Fluent Mapping و Traditional Mapping.‏ Auto mapping کار mapping را در صورتی که نیازمندی‌هایتان با پیش‌فرض‌های FNH خیلی تفاوت نداشته شد به خوبی راه می‌اندازد. در این روش شما فقط یک class ساده سی‌شارپی را به FNH معرفی می‌کنید بدون آن که از attribute یا lambda expression برای بیان تناظر بین کلاس و جدول استفاده کرده باشید. FNH خودش یک mapping پیش فرض در نظر خواهد گرفت. برای فهم سادگی موضوع حتماً نگاهی به نمونه‌های اینجا بیندازید.




2011/07/03

‫‫C#‎ برای توسعه برنامه‌های dynamic

به غیر از ما، خیلی‌های دیگر هم به فکر توسعه برنامه‌های dynamic با C#‎ و ‎.Net هستند. به عنوان نمونه به تلاش مایکروسافت در نسخه‌های ۳ و بعد از ۳ دات‌نت دقت کنید (LINQ و بقیه) یا به کتاب‌هایی مثل Pro Dynamic .NET 4.0 Applications: Data-Driven Programming for the .NET Framework نگاهی بیندازید.

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




‫سرویس اشتراک کد gist

آیا شما هم مشکل نمایش سورس کد در وبلاگ دارید؟ آیا شما هم مجبورید به خاطر یک تیکه کد ساده آن را جایی آپلود کنید تا بقیه بتوانند آن را دریافت کنند؟ آیا دوست دارید با همین تیکه کدهای کوچک هم امکان history و fork داشته باشید؟ آیا کامنت دیگران برایتان مهم است؟ آیا…؟

در کنار همه سرویس‌های موجود برای اشتراک کد، سرویسی به نام gist از زیر مجموعه‌های سایت github.com وجود دارد که همه امکانات بالا را برایتان به ارمغان می‌آورد. به عنوان نمونه به تکه کدی که خودم برای تست گذاشته‌ام نگاه کنید:
پ. ن.:این روش یک بدی کوچک دارد آن هم این که با backup گیری از نوشته‌های وبلاگ، سورس کدتان هم backup گرفته نمی‌شود.