اشتباهات دوران دانشگاه

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


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


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

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


۴- انتخاب C#‎ به جای جاوا.
آن اوایل دانشگاه همه ما با هم دلفی کار بودیم اما کمی بعد سر و کله دات‌نت و جاوا پیدا شد و خیلی‌ها از جمله خود من دلفی را فراموش و به سمت یکی از این دو سکو رفتیم. آن زمان خیلی با بحث Open Source و… آشنا نبودم و فکر می‌کردم چون جاوا کد باز است ممکن است خیلی رشد نکند. ولی چون مایکروسافت یک شرکت تجاری خیلی بزرگ است حتماً دات‌نت‎ موفق‌تر خواهد بود. البته گذر زمان نشان داد هر چند که دات‌نت‎ چندان شکست نخورد اما آنهایی که به سمت جاوا رفتند موفق‌تر بودند خصوصاً آنها که در ایران بودند. به عنوان مدرک می‌توانید تعداد پروژه‌های موفق در جاوا را مقایسه کنید با پروژه‌های موفق C#‎. به عنوان مثال Hibernate را. اگر نمونه کدها یا سواد آدم‌های جاوا کار را مقایسه کنید با نمونه کدهای C#‎ یا آدم‌های C#‎ کار متوجه می‌شوید که به طور نسبی جاوا کارها با سوادتر و کدهایی که می‌نویسند دقیق‌تر و اصولی‌تر است. در بازار کار هم برنامه‌نویس‌های جاوا محبوبیت بیشتری داشته و حتی میانگین حقوقی بالاتری هم دارند. به طور کلی به نظر می‌رسد در ایران شرکت‌های جاوایی تیم‌های قوی‌تر و برنامه‌نویس‌های بهتری داشته باشند تا شرکت‌های دات‌نتی.


۵- عدم استفاده مفید از سربازی
هر چند که سربازی را باید رفت چون همه می‌روند اما بنده به خاطری کوتاهی‌هایی که در بعضی زمینه‌ها و شبکه اجتماعی (در اینجا آشنا و پارتی) در طول دوران تحصیل کرده بودم نتوانستم امریه پیدا کنم. حتی نتوانستم در شهر یا نیروی دلخواه به سربازی بروم. در نتیجه دو سال از وقت با ارزشم را در تبریز و کوه‌های لرستان سپری کردم. طی این مدت تنها ارتباطم با کامپیوتر مجموعه Microsoft Office و خواندن یک کتاب ASP بود.


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

۷- دیگر موارد متفرقه مثل عدم کار روی پروژه‌های کد باز معروف، عدم حضور جدی و موثر در المپیادها، مسابقات و همایش‌های دانشجویی، دوست‌یابی نادرست و…

راه حل های ساده

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


ASP.NET Automatic DataBinding

ASP.NET مکانیزم خودکاری برای data binding صفحات دارد. در این مکانیزم همه کنترل‌های data aware صفحه شناسایی شده و توسط موتور ASP.NET با ترتیب معینی که ظاهراً قابل عوض کردن هم نیست data bind می‌شوند. این مکانیزم در بیشتر اوقات خیلی مفید و کار راحت کن است. اما این موضوع وقتی که تعداد کنترل‌های data aware از حد معینی بیشتر می‌شود مشکل زا خواهد شد. یکی از مثال‌های معروف این مشکل وقتی است که یک DropDownList و یک GridView در صفحه قرار دارند. DropDownList به ObjectDataSourceی به نام ods1 و GridView هم به ObjectDataSourceی به نام ods2 وصل هستند. فرض کنید یکی از پارامترهای ods2 به SelectedValue مربوط به DropDownList وصل است. در این حالت بعضی وقت‌ها دچار این مشکل می‌شویم که GridView زودتر از DropDownList مورد DataBinding قرار می‌گیرد. در نتیجه SelectedValue مربوط به DropDownList همیشه خالی بوده و مقدارش نامعتبر خواهد بود.

راه حلی که من همیشه استفاده می‌کردم پاک کردن صورت مسئله بود. یعنی هر نوع DataSource را از صفحه برداشته و خودم عملیات خواندن/نوشتن اطلاعات از/به دیتابیس را به طور دستی بر اساس eventهای مختلف کنترل‌های موجود انجام می‌دادم. نا گفته پیداست که این کار چه زحماتی ایجاد می‌کرده و چه قدر خطا ساز بوده است.

راه حل ساده‌ای که تازگی‌ها پیدا کرده‌ام این است که Data Sourceها و کلیه مکانیزم‌های مربوطه را در صفحه نگه داشته و به اصطلاح کاملاً به صورت declarative programming عمل کنم. اما برای رفع مشکل ناهماهنگی eventها یا اصطلاحاً Event Taming، مکانیزم Data Binding خودکار ASP.NET را از کار انداخته و خودم عملیات Binding یعنی صرفاً معرفی DataSourceها به کنترل‌ها و فراخوانی DataBind کنترل‌ها را به طور دستی از طریق Code Behind انجام می‌دهم. البته از کار انداختن مکانیزم خودکار Data Binding در صفحات ASP.NET کار چندان سختی نیست. فقط کافی‌ست خصیصه DataSourceID را از تمام کنترل‌های صفحه برداشته و بعداً خودتان آنها را از طریق code behind تنظیم کنید. جهت کسب اطلات بیشتر به این پیوند مراجعه کنید.


AutoComplete TextBox

AutoComplete TextBox امکانی است که از طریق آژاکس به صفحات وب اضافه می‌شود. با کمک این امکان وقتی کاربر چند حرف اول کلمه مورد نظرش را در TextBox تایپ می‌کند، تعدادی از موارد مشابه هم به وی نشان داده می‌شود. این موارد مشابه از طریق فراخوانی یک وب سرویس و به شیوه آژاکس به دست client می‌رسند. اجرای چنین راه حلی مستلزم نوشتن یک وب سرویس و استفاده از کنترل‌های خاصی مثل AutoCompleteExtender از کتابخانه Ajax Control Toolkit می‌باشد.

اما اگر از کنترل‌های Telerik استفاده می‌کنید و حجم دیتا خیلی زیاد نیست، یک راه حل ساده‌تر وجود دارد. این راه ساده‌تر استفاده از کنترل استاندارد RadComboBox و تنظیم خاصیت‌های AllowCustomText و Filter آن است. به این ترتیب بدون استفاده از هیچ نوع وب سرویس و هیچ نوع آژاکسی می‌توان به کاربر قبولاند که این Combo خاصیت AutoComplete دارد. البته اگر از Telerik هم استفاده نمی‌کنید، فکر می‌کنم بتوان کنترل DropDownList از ASP.NET را طوری دستکاری کرد که از آن بشود چنین استفاده‌ای کرد.

Common problems with Named SQL queries

Named SQL queries in NHibernate is a way that you can put a native SQL query in a .hbm.xml file and executed it via IQuery and GetNamedQuery. By working with this feature you may encounter some errors and exceptions. Here I have gathered some common problems that I have seen by myself.


NHibernate.MappingException : unknown class

Occurs when return clause of XML mapping file defines a class that is not defined in the domain. This error does not allow anything work.
----

NHibernate.HibernateException : Errors in named queries: {QUERY_NAME}

Occurs when return clause of XML defines a class that the class exists but its mapping does not exists. This error does not allow anything work.
---

NHibernate.ADOException : could not execute query ****
System.IndexOutOfRangeException : COLUMN_NAME
When a column is defined in return clause but does not exists in select clause of query.
---

NHibernate.ADOException : could not execute query
System.IndexOutOfRangeException : Recstatus
When named query return an entity that is inheriting from another entity but sql query does not return all columns that is used by both entity itself and its parent.

خودتان را تبلیغ کنید: شرکت‌ها

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

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

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

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

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

اما چه راه‌هایی برای شناساندن شرایط، امکانات، ظرفیت‌ها و جذابیت‌های یک شرکت نرم‌افزاری به برنامه‌نویسان جویندگان کار وجود دارد؟ چطور می‌شود استخدام در یک شرکت نوعی را جذاب نشان داد؟ مطمئناً خود شرکت‌ها روش‌هایی برای انجام این کار دارند ولی راه‌هایی هم به ذهن من به عنوان یک برنامه‌نویس می‌رسند که عبارت هستند از:

۱- فقط به آگهی در سایت‌ها اکتفا نکنید، آگهی در رسانه‌های کاغذی می‌تواند اعتبار شما را نشان دهد.
۲- نام تعدادی از برنامه‌نویسان و دیگر اعضای تیم برنامه‌نویسی و مختصری از سوابقشان را در سایت قرار دهید. با این کار بقیه از بزرگی و قدرت تیم برنامه‌نویسی شما با خبر خواهند شد.
۳- از نحوه‌ی کار، متودودلوژی و تکنولوژی‌های مورد استفاده، ساختار تیم و ابزارهای مورد استفاده بگویید.
۴- چند تا از نمونه کارهایتان را معرفی کرده و مختصری از روش پیاده‌سازی آنها بگویید.
۵- کمی از مزایای شغلی و مالی شرکت‌تان بگویید هر چند تقریبی.
۶- اگر برنامه‌های فوق العاده آموزشی یا رفاهی دارید، از آنها هم بگویید خصوصاً برنامه‌های آموزشی را. چون برنامه‌نویس جماعت همیشه نیاز شدید به آموزش و بازآموزی دارد.
۷- به نوعی نشان دهید که امنیت شغلی در شرکت شما بالاست.
۸- همیشه منتظر مراجعه برنامه‌نویسان برای استخدام نباشید، گاهی اوقات هم شما آنها را شناسایی کرده و دعوت به کار کنید. این کار تیزبینی شما را نشان می‌دهد.
۹- در مصاحبه‌ها یا در سایت شرکت‌تان روند پیشرفت شغلی، اهداف و برنامه‌های شرکت‌تان را تشریح کنید. اجازه دهید افراد جدید تصویر روشنی از آینده خود و شرکت شما داشته باشند.
۱۰- مصاحبه با افراد جدید را در حد و اندازه جلسات فروش محصول جدی بدانید و این را به فرد مصاحبه شونده هم انتقال دهید. اجازه دهید او فکر کند جز مهمی از شرکت خواهد بود.
۱۱- ترجیحاً در گردهمایی‌های مرتبط با توسعه و تولید نرم‌افزار شرکت کرده و قدرت تیم برنامه‌نویسی‌تان را نشان دهید.



برای آن که ایده‌های بیشتری پیدا کنید می‌توانید نگاهی به صفحات استخدام نیرو در شرکت‌های تولید نرم‌افزار در سراسر دنیا انداخته یا به سایت‌های کاریابی خارجی خصوصاً careers.stackoverflow.com مراجعه کنید.


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

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

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

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

مطمئناً خیلی از برنامه‌نویس‌ها و توسعه‌دهنده‌ها می‌دانند که باید خودشان را خیلی خوب به دیگران معرفی کنند و حتی از عواقب گمنامی هم مطلع هستند. اما چرا دست به کار نمی‌شوند و کاری نمی‌کنند؟ به نظر من دلایل زیر را می‌توان بیان کرد:

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

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

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


این‌ها دلایلی بودند که به ذهن من می‌رسیدند. ممکن است بقیه هم دلایل دیگری علاوه بر این‌ها داشته باشند. حال برای رفع این مشکلات چه می‌توان کرد؟ مورد اول و دوم در بین بیشتر مشاغل مشترک است. بنابراین برای رفع آنها می‌توان از همان راه حل‌ها استفاده کرد. اما برای مورد سوم راه‌های زیر به نظرم می‌رسند:

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

۲- در سایت‌هایی که رزومه، سوابق کاری و تحصیلی، مهارت‌ها و… افراد را نگهداری می‌کنند، مثل LinkedIn،

StackOverflow Career، ITJobs، IrExpert، IranTalent، JobIran، u24 و حتی Facebook رزومه و دیگر سوابق خود را ثبت کنید تا دیگران راحت‌تر از سوابق شما با خبر شوند.

۳- وبلاگ بنویسید. مهم نیست مطالبی که می‌نویسید چقدر املا و انشای خوبی داشته باشد. مهم این است که از تجارب و افکار روزمره خود پرده برداشته و هر از چند گاهی (اقلاً هفته‌ای یک بار) آنها را در وبلاگتان بیاورید. داشتن و نداشتن خواننده و ویزیتور هم به نظر من چندان مهم نیست. با وبلاگ نویسی به دیگران می‌گویید که دارید روی چه چیزهایی کار می‌کنید، چه چیزهایی بلد هستید و… چه بسا از این راه توانستید چند تا دوست جدید هم پیدا کنید.

۴- در سایت‌های عمومی مثل CodeProject، DZone، InfoQ، iDevCenter و… مقاله بگذارید یا مشارکت کنید. از این راه هم دیده می‌شوید و هم دیگران را متقاعد می‌کنید که چیزی بیش از یک برنامه‌نویس معمولی هستید.

۵- در سایت‌های پرسش و پاسخ مثل StackOverflow، Google Groups (گروه‌های مرتبط با برنامه‌نویسی) و Barnamenevis مشارکت فعال داشته و به سوال‌هایی که بلدید جواب بدهید. این طوری هم دیده می‌شوید، هم مهارت‌هایتان قابل رویت و قابل لمس است و هم می‌توانید از آنها به عنوان نکته‌ای مثبت در رزومه‌تان استفاده کنید.

۶- در یک پروژه Open Source مشارکت کنید. اعم از کدنویسی، راهنمایی دیگر کاربران، Documentation و… و اگر هم خیلی پایه هستید خودتان یک پروژه Open Source کوچک شروع کرده و چیزی را با استفاده از مهارتتان بسازید. مزایای این راه باز هم دیده شدن و معرفی مهارت‌هایتان است.

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

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


نظر شما چیست؟

‫‫روز NHibernate

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

ظاهراً چنین روزی هم برای NHibernate در نظر گرفته و مراسم اولین دوره آن هم در ۱۷ مهر ۸۹ (نهم اکتبر ۲۰۱۰) در ایتالیا برگزار شده است. البته منظور از مراسم، یک کنفرانس یک روزه درباره NHibernate است. در این روز تعدادی از افراد فعال در حوزه NHiberante از جمله خود Ayende Rahien (یا همان Oren Eini) حضور پیدا کرده و راجع به موضوعاتی مثل امکانات جدید در NHibernate 3 و Linq-to-NHibernate صحبت کرده و یک جلسه پرسش و پاسخ هم برگزار کرده‌اند. همه ویدیوها و presentationها هم از طریق سایت قابل دریافت است.


وب سایت روز NHibernate

خواندن کتاب‌های کامپیوتری

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

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

• Professional Team Foundation Server
• Professional Visual Studio 2010
• Excel 2007 Bible

دسته دوم: فناوری‌ها
شامل کتاب‌هایی که استفاده از فناوری خاصی را آموزش می‌دهند. مثل:

• NHibernate in Action
• Programming ASP.NET 3.5
• jQuery in Action

دسته سوم: زبان/مفهوم
کتاب‌هایی که زبان‌های برنامه‌نویسی را آموزش می‌دهند، راجع به یک استاندارد صحبت می‌کنند یا مباحث آکادمیک مثل طراحی الگوریتم، لایه‌های شبکه، سیستم عامل و… را مورد بحث قرار می‌دهند. مثل:

• Pro C# 2010 and the .NET 4 Platform
• UML Distilled
• Computer Networks
• Operating System Concepts

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

• Code Complete
• The Mythical Man-Month
• The Pragmatic Programmer
• Patterns of Enterprise Application Architecture

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

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

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

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

‫‫استفاده از Castle ActiveRecord در چند گام

Castle ActiveRecord یک ابزار کمکی برای استفاده راحت‌تر از NHibernate است. NHibernate خودش هم یک ORM کد باز دات‌نتی معروف است. در واقع می‌توان Castle ActiveRecord را یک ORM خیلی راحت دانست. بسیاری افراد فکر می‌کنند استفاده از ORMها و تنظیمات آنها کار خیلی سختی است. اما من در اینجا می‌خواهم در چند قدم ساده یک پروژه ASP.NET کوچک را با استفاده از Castle ActiveRecord ایجاد کنم.

۱- یک پروژه ASP.NET در ویژوال استودیو ایجاد کنید و اسم آن را ActiveRecordTest بگذارید.
۲- سه صفحه به نام‌های CreateSchema، SampleData و ViewData، یک کلاس به نام Car و یک فایل Global.asax به آن اضافه کنید.
۳- Castle ActiveRecord را از این آدرس دریافت کنید. حجم دریافت ‎1.9 MB است.
۴- یک reference از فایل Castle.ActiveRecord.dll به پروژه اضافه کنید.
۵- کلاس Car را مطابق زیر تغییر دهید. این کلاس رابط برنامه شما و دیتابیس است. این کلاس ساختار جدول دیتابیس را هم تعیین می‌کند. یعنی شما نیازی نیست که به دیتابیس مراجعه کرده و جدولی به اسم Car بسازید. هر فیلد این کلاس که بالای آن [Property] درج شده باشد نمایانگر یک ستون از جدول دیتابیسی است.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using Castle.ActiveRecord;

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

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

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

        [Property]
        public virtual int MaxSpeed { set; get; }

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

۶- فایل web.config برنامه را مشابه web.config زیر تغییر دهید. تنظیمات Castle ActiveRecord در اینجا قرار دارند.

دقت کنید که دیتابیس معرفی شده در connection string باید از قبل ساخته شده باشد ولی نیازی است که جداول آن آماده شده باشد.

۷- با هر بار اجرای برنامه بایستی Castle ActiveRecord مقدار دهی اولیه یا Initialize شود. این کار از طریق متود Application_Start فایل Global.asax انجام می‌شود. متود Application_Start باید مشابه زیر باشد.

protected void Application_Start(object sender, EventArgs e)
        {
            if (ActiveRecordStarter.IsInitialized)
                return;

            IConfigurationSource config = ActiveRecordSectionHandler.Instance;
            ActiveRecordStarter.Initialize(Assembly.Load("ActiveRecordTest"), config);
        }

۸- حالا باید مکانیزمی برای ایجاد دیتابیس بر پایه Domain Entityهای برنامه که در اینجا کلاس Car است ایجاد کنیم. برای این کار باید کد ActiveRecordStarter.CreateSchema()‎ را در Page_Load صفحه CreateSchema قرار دهیم.

۹- برای شروع به کار برنامه نیاز به مقدار داده‌ی تستی داریم. برای این کار کد زیر را در Page_Load صفحه SampleData قرار دهید. نمونه کد زیر نشان می‌دهد چطور می‌توان یک instance از کلاس Car را به عنوان یک رکورد از جدول Car در دیتابیس ذخیره کرد.

Car car1 = new Car()
            {
                Manufacture = "Toyota",
                Model = "Camery",
                Color = "White",
                MaxSpeed = 200
            };

            car1.Save();

            Car car2 = new Car()
            {
                Manufacture = "Pride",
                Model = "Saba",
                Color = "Black",
                MaxSpeed = 180
            };

            car2.Save();

۱۰- بعد از ایجاد داده تستی یک صفحه برای نمایش آنها به کاربر ایجاد می‌کنیم. برای همین به کد markup صفحه ViewData کد زیر را اضافه می‌کنیم.

۱۱- کار کدنویسی تمام شد. حالا شروع به استفاده از برنامه می‌کنیم. برای آن کار جدول کار به طور خودکار ساخته شود یک بار صفحه CreateSchema را در مرورگرتان Browse کنید. پس از این کار اگر به دیتابیس مراجعه کنید خواهید دید جدولی به نام Car با ستون‌ها مورد نظر شما ساخته شده است.

۱۲- حال برای ایجاد تعدادی داده تستی یک بار صفحه SampleData را در مرورگرتان Browse کنید. با این کار ۲ رکورد به جدول Car اضافه می‌شود.

۱۳- حال به صفحه ViewData بروید تا داده‌های ایجاد شده در مرحله قبل از دیتابیس load شده و به شما نمایش داده شود.

۱۴- کار تمام شد. به همین سادگی! سورس این پروژه امتحانی در این آدرس موجود است. برای یادگیری تکمیلی به راهنمای ActiveRecord فراسان یا این آدرس مراجعه کنید.

‫‫معرفی کتاب ALM with Visual Studio 2010

کتاب Professional Application Lifecycle Management with Visual Studio 2010 راجع به فازهای مختلف توسعه‌ی نرم‌افزار با استفاده از ویژوال استودیو ۲۰۱۰ و TFS صحبت می‌کند. فازهای مختلف توسعه‌ی نرم‌افزار که اصطلاحاً Application Lifecycle Management یا ALM نامیده می‌شود عبارت است از مراحلی که که از تحلیل و درک سیستم شروع شده، با مراحل طراحی، پیاده‌سازی و تست ادامه پیدا کرده و تا مرحله استقرار ادامه پیدا می‌کند. دیگر موارد مورد نیاز از جمله متودولوژی، سورس کنترل، مدیریت پروژه و… نیز جزیی از ALM هستند.

مجموعه Visual Studio 2010 و TFS 2010 با کمک هم، همه‌ی این مراحل را پوشش می‌دهند. یعنی شما با کمک این دو تا هم می‌توانید نمودارهای مختلف UML را که برای بخش‌های مختلف تحلیل و طراحی مورد نیاز هستند را تهیه کنید، هم مراحل کد نویسی، پیاده‌سازی و انواع تست را طی کنید و هم تمام نیازهای Source Control، مدیریت پروژه و… را انجام دهید.

کتاب به پنج بخش اصلی و هر بخش به چند فصل تقسیم می‌شود.

بخش اول: معماری
معرفی امکانات Visual Studio 2010 برای تحلیل و طراحی سیستم. این بخش شامل توضیحاتی راجع به تحلیل، طراحی، معماری نرم‌افزار و مفاهیم مرتبط در UML بوده و به شما نشان می‌دهد چطور می‌توانید با استفاده از Visual Studio 2010 انواع و اقسام نمودارهای UML را تهیه کنید.

بخش دوم: برنامه‌نویس‌ها
معرفی خود ویژوال استودیو و امکانات مختلف آن برای برنامه‌نویسان از جمله: Code Analysis، Code Metrics، Profiling، IntelliTrace و کمی Unit Test.

بخش سوم: تست
معرفی انواع و اقسام تست از جمله Load Test، Web Performance، Manual Test، Coded UI Test و معرفی Lab Management.

بخش چهارم: TFS
معرفی معماری TFS و نحوه‌ی کار با Version Control و Build Engine آن.

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


آیا خواندن این کتاب مفید بود؟

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

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

‫Paging کوئری‌های SQL در NHibernate

تصور کنید تعدادی کوئری SQL دارید که می‌خواهید Paging را با استفاده از NHibernate در آنها فعال کرده و بنا به دلایلی اجازه بازنویسی آنها با دیگر APIهای NHibernate نداشته و آنها را صرفاً باید از طریق ObjectDataSaource به کنترل‌های ASP.NET بخورانید. سه راه برای انجام این کار وجود دارد.

راه اول:
استفاده از stored procedureهای کمکی که خاص این قضیه ایجاد شده‌اند. یکی از آنها Paging_RowCount است که توسط دوستم مسعود رمضانی معرفی شده. این ابزارها queryی (و احتمالاً stored procedure) شما دریافت کرده و Paging را روی آنها اعمال می‌کنند. بدی این ابزارها این است که محدودیت‌های زیادی در query دریافتی اعمال و کرده و در خیلی از حالات کار نمی‌کنند. بدی دیگر آنها عدم خوانایی و قابلیت نگهداری پایین آنهاست چون Query ورودی این ابزارها معمولاً به صورت تیکه تیکه در داخل کد C#‎ نگهداری می‌شود. البته من چندان تخصصی روی SQL ندارم و با کل این ابزار به طور کامل کار نکرده‌ام اما همین دلیل دوم برای من کافی است تا از آن دوری کنم.

راه دوم:
استفاده از Named SQL Queries در NHibernate است. در این روش شما می‌توانید با استفاده از SetFirstResult و SetMaxResults وظیفه Paging را به عهده NHibernate بگذارید. در این حالت NHibernate خودش به طور خودکار و پشت پرده مشابه روش اول عمل کرده و Paging را برای شما مهیا می‌نماید. این روش بسیار زیبا، راحت، خوانا و قابل نگهداری است اما بدی آن این است که در بعضی حالات که Query کمی پیچیده می‌شود عمل نمی‌کند. یعنی این که بیشتر برای Queryهای ساده مناسب است.

راه سوم:
وقتی که نمی‌خواهید از روش اول استفاده کنید و روش دوم هم درست کار نمی‌کند مجبورید خودتان وظیفه Paging را به عهده بگیرید. یعنی کاری را که روش‌های اول و دوم به صورت خودکار انجام می‌دادند شما به صورت دستی انجام دهید. روش معمول برای Paging در MS SQL Server که راه‌های اول و دوم هم از آن استفاده می‌کنند روش ROW_NUMBER()‎ است. من خودم برای انجام این کار از یک Query حاضر و آماده که توسط NHibernate تولید می‌شد استفاده می‌کنم. به نمونه اسکریپت زیر توجه فرمایید:

SELECT TOP (@maxResults) * FROM (

select 

*

,ROW_NUMBER() OVER(ORDER BY (@orderBy)) as _sort_row from 
  
Toy

)as query WHERE query._sort_row > @firstResult 
ORDER BY query._sort_row

البته من همین query را هم در داخل یک Named SQL Query قرار داده‌ام ولی به جای فراخوانی توابع SetFirstResult و SetMaxResults از پارامترهایی که خودم به همین اسامی در query تعبیه کرده‌ام استفاده می‌کنم.

‫استفاده مستقیم از SQL در NHibernate

NHibernate یک ORM است که شما را ترغیب می‌کند برای دسترسی به دیتابیس از APIهای خاص خودش یعنی HQL، ICriteria و Linq-to-NHibernate استفاده کنید. اما راه را برای آنها که به هر دلیل ترجیح می‌دهند یا مجبورند از SQL استفاده کنند نبسته است. NHibernate دو راه برای انجام این کار دارد: استفاده از ISession.CreateSQLQuery و استفاده از Named SQL queries.


استفاده از راه حل اول خیلی سر راست است ولی چون برنامه‌نویس را تشویق می‌کند کوئری SQL را در متن کدهای C#‎ نگهداری کند توصیه نمی‌شود. در عوض راه حل دوم یعنی Named SQL queries تمیزتر و قابل انعظاف‌تر عمل می‌کند. در این روش شما Queryهای مورد نظر را درست مشابه mappingها در فایل‌هایی با پسوند ‎.hbm.xml نگهداری می‌کنید. به این ترتیب هم کدهای C#‎ و اسکریپت‌های SQL با هم قاطی نمی‌شوند و هم ممکن است بتوانید از یک سری بهینه‌سازی‌ها و cachingهای SQL Server بهره‌مند شوید.

به عنوان یک نمونه از Named SQL queries به مورد زیر توجه فرمایید. منتها توجه داشته باشید که فایل query حتماً باید به صورت Embedded Resource کامپایل شده و dll آن به کمک AddAssembly به فهرست Assemblyها اضافه شده باشد.

برای کسب اطلاعات بیشتر به Documentation مربوط به NHibernate در nhforge مراجعه کنید.

Unit tests and DRY

One of common things that I unit test with NUnit is testing throwing or not throwing a specific exception. This is done using Assert.Throws and Assert.DoesNotThrow. I used to write 2 method for a exception assert unit test. One that do the actual work and one for unit test previous method. Consider following:

pubic void method1()
{
int a =1;
int b=2;
//plenty setup needed here

MyClass.DoSomething(a, b);
}

[Test]
public void DoSomethingTest()
{
Assert.DoesNotThrow(method1);
}

Now suppose that you have to unit test MyClass.DoSomething against many similar inputs. One way to do is repeat method1 and DoSomethingTest as needed. A disadvantage is that it's against DRY principle. As Assert.DoesNotThrow ony accepts methods that has not parameter, I couldn't stop to repeat initialization/setup codes in every method.

Fortunately today I found that I can use Anonymous Methods with Assert.Throws and Assert.DoesNotThrow without need to create several methods. Using this way DRY is leveraged in unit tests. See following example:

[Test]
public void DoSomethingTest()
{
int a1 = 1;
int b1 =2;

int b2 =4;

int b3 = -1;

Assert.DoesNotThrows(delegate()
{
MyClass.DoSomething(a1, b1);
});

Assert.DoesNotThrows(delegate()
{
MyClass.DoSomething(a1, b2);
});

Assert.DoesNotThrows(delegate()
{
MyClass.DoSomething(a1, b3);
});

Note: Many others have problems with applying DRY or KISS with unit tests including this one.

SchemaUpdate generates duplicate foreign keys

We have a typical web application that its data access layer is written using Castle ActiveRecord. Castle ActiveRecord exposes NHibernate's SchemUpdate feature. This feature lets us to upgrade schema/database with current changes in domain entities.

One odd problem with SchemaUpdate was that in many cases it was generating foreign keys again without any change in domain entity. After some search I found that if you did not specify foreign key names explicitly, NHibernate generates them randomly. So in update progress becuase name of existing foreign keys are not equal to new generated ones, they are generated again as duplicate.

Solution is very easy. Wherever you use BelognsTo you must specify a fixed name for ForeignKey attribute. This way a none random name is generated for foreign key names. Be aware that foreign key names must be unique across a database.

An example:

[BelongsTo(Column="Owner_ID", ForeignKey="FK_Owner_ID")]
        public virtual SomeType Owner { set; get; }

‫Static Code Analysis در Visual Studio

حتماً تا حالا دیده‌اید که هر وقت پروژه‌ای را در ویژوال استودیو Build می‌کنید در کنار فهرست Errorها، فهرستی از Warningها هم نمایش داده می‌شود. این Warningها مواردی هستند که کامپایلر C#‎ تشخیص داده و برای بررسی بیشتر به شما اعلام می‌کند. این Warningها شامل مسائلی ساده و معمولی هستند مثل: یک return وسط متود که نشان می‌دهد کدهای بعد از return هیچ وقت اجرا نمی‌شوند، معرفی یک متغیر و عدم استفاده از آن، مقایسه متغیری از نوع int با null و…

هر چند که خیلی از برنامه‌نویسان به همین Warningها هم هیچ توجهی نمی‌کنند ولی اگر بخواهید کنترل کیفیتی بالاتر از این هم داشته باشید می‌توانید از ابزارهای Static Code Analysis استفاده کنید. ابزارهای مختلفی برای این کار موجود هستند یکی از این ابزارها FxCop نام دارد. FxCop محصول رایگانی از مایکروسافت است که هم به طور مستقل قابل اجراست و هم این که با ویژوال استودیو Integrate است. این ابزار قواعد بسیار مختلفی را چک می‌کند از جمله قواعد نامگذاری، مسائل مربوط به امنیت، Performance و… مواردی که توسط FxCop پیدا می‌شوند به شکل Warning به هنگام Build پروژه‌ها نمایش داده می‌شود.

فعال‌سازی Static Code Analysis بسیار راحت است. کافی است روی نام پروژه راست کلیک کرده و گزینه Properties را زده و به بخش Code Analysis بروید. در آنجا گزینه‌ی Enable Code Analysis را تیک زده و مجموعه Ruleها مورد نظر را مشخص فرمایید. اسم Ruleها گویاست و نشان می‌دهد که چه کاری انجام می‌دهند. برای دیدن فهرست کامل Ruleها به اینجا بروید.

فردیس

«فردیس» یک پروژه‌ی Open Source خیلی کوچک است که برای کار با یونیکد ایجاد شده است. «فردیس» در یک دوره‌ی زمانی که به شدت نیاز به این داشتیم که بفهمیم فلان کلید صفحه کلید یا فلان کاراکتر دقیقاً کدام نویسه‌ی یونیکد است، کد آن چیست، نام رسمی آن در یونیکد چیست و در فونت‌های مختلف چطور نمایش می‌یابد متولد شد.

بعدها در کنار رفع این نیازها به فکر افتادم که «فردیس» فقط به صورت یک برنامه exe نباشد بلکه همه‌ی امکانات آن به علاوه دیگر امکاناتی که ممکن بود برنامه‌نویسان دیگر در ارتباط با فارسی و یونیکد به آن نیاز پیدا کنند هم به صورت یک library هم موجود باشد.

بخشی از آنچه که در مورد برنامه‌ی «فردیس» در ذهنم بوده هم اکنون پیاده‌سازی شده و بقیه‌ی آنها در Issue List پروژه موجود است. امیدوارم بتوانم به مرور زمان و بر اساس نیازمندی‌های خودم و بقیه این فهرست را تکمیل‌تر کنم.

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

لینک‌های مفید:
home page پروژه
Download پروژه
Discussions List پروژه
Issue Tracker پروژه
Source Code پروژه

Fardis

Fardis is a tiny open source project regarding Unicode and Persian/Arabic. Once a time I was in need to know more info about characters. Specially I needed to know what's Unicode name and code of a specific character. So I created "Farids" as an .Net/C# and Windows desktop application/library.

Along with time I decided "Fardis" being a library too. So created an issue list and implemented some of them. I will implement more of them if I found them useful for myself or other users/programmers.

This task has been done with help of Nasser Hadjloo in both test and logo design.

Project links:
Home Page
Downloads
Discussions
Issue Tracker
Source Code

جلسات ناهاری

یکی از معضلات همیشگی شرکت‌های نرم‌افزاری کمبود وقت برای آموزش و اطلاع‌رسانی است. یکی از راهکارهای مورد استفاده در کشورهای پیشرفته‌تر استفاده از «جلسات ناهاری» یا به قول خودشان Brown Bag Session است.

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

دلیل نام گذاری این جلسات به Brown Bag این است که معمولاً افراد (کشورهای موصوف) ناهارشان را در پاکت‌های قهوه‌ای رنگ می‌گذارند و این پاکت‌ها را با خود به جلسه می‌آورند.