2011/04/29

‫ایجاد پروژه در TFS به روش اسکرام


یکی از کارهایی که همیشه انجام می‌دهم ایجاد یک پروژه در TFS 2010 به روش اسکرام است. بد ندیدم که بعضی از مراحل آن را در اینجا بیاورم:

۱- کسب اطمینان از نصب SfTS در TFS. این ابزار امکانات اسکرام را در TFS و Visual Studio فراهم می‌کند.

۲- اجرای ویژوال استودیو در حالت Admin.

۳- انتخاب گزینه New Team Project...‎ از پنجره Team Explorer.

۴- نام گذاری پروژه و انتخاب Template با نام Scrum for Team System و ادامه همه مراحل.

۵- راست کلیک روی اسم پروژه در Team Explorer و انتخاب گزینه‌های Team Project Settings و Group Membership.

۶- دابل کلیک روی گروه دلخواه و اضافه کردن کاربران مورد نظر از طریق Windows User or Group.

۷- باز کردن آدرس وبی TFS که معمولاً به صورت http://servername:8080/tfs/web/‎ است.

از اینجا به بعد باید مراحل مخصوص اسکرام دنبال شود. یعنی اسپرینت‌ها، Backlog Itemها، Taskها و… تعریف شوند. هر اسپرینتی هم باید به صورت work item ثبت شود و هم به صورت ساختار داخلی Iteration.

۸- اضافه کردن iterationهای مورد نظر بر اساس تعداد اسپرینت‌ها. دقت شود که برای تیم‌های کوچک فقط Team Sprint مهم است.



۹- بعد از مشخص کردن همه Iterationها چیزی شبیه به عکس زیر دیده خواهد شد.



۱۰- تعریف Releaseها، Sprintها و Team Sprintها بر اساس درخت Iterartion. وارد شدن تاریخ‌ها نباید فراموش شود. از این سه تا work item فقط نوع Team Sprint برای ما اهمیت دارد.

۱۱- تعریف رابطه Implemented by و Implements بین Releaseها، Sprintها و Team Sprintها.

۱۲- تعریف Backlogها (PBI) و  Taskها (SBT) و روابط بین خودشان و Team Sprintها.

۱۳- استفاده از Queryهای موجود برای مشاهده Work Itemهای تعریف شده.

۱۴- تکمیل تدریجی اطلاعات Work Itemها.

۱۵- استفاده از Sprint Burndown Chart و دیگر گزارشات برای کسب اطلاعات بیشتر از وضعیت پروژه.

۱۶- از Portal پروژه هم می‌توان استفاده کرده و به خیلی از اطلاعات و امکانات پروژه دسترسی پیدا کرد.

---




2011/04/27

‫DataBinding در WPF

به عنوان یک برنامه‌نویس ASP.NET عادت داشتم هر جا که اطلاعات تغییر می‌کند. متود DataBind()‎ را از کنترل‌هایی مثل GridView فراخوانی کنم. در WPF هم می‌خواستم همان کارها را بکنم اما به کمی مشکل برخوردم. در WPF باید کارهای زیر انجام شود:

۱- یکی از کنترل‌های گرید در WPF که امکانات Binding خوبی دارد کنترل DataGrid است. من هم از همین کنترل شروع می‌کنم.

۲- مقدار AutoGenerateColumns را مشابه ASP.NET برابر True قرار می‌دهم.

۳- اطلاعاتی که می‌خواهم با آنها کار کنم را به ItemSource (به جای DataSource) معرفی می‌کنم.

۴- متودی به اسم DataBind وجود ندارد. برای Refresh شدن اطلاعات باید دقت کنیم که مدل Data Binding در WPF چیزی به اسم Observer pattern است. در این الگو خود data به کنترل DataGrid می‌گویند که چه وقتی اطلاعات آنها تغییر کرده و باید اطلاعات Refresh شوند.

۵- برای پیاده‌سازی عملیات Refresh باید اطلاعاتی که قرار است به کنترل‌هایی داده‌ای Bind شوند، اینترفیس INotifyCollectionChanged را پیاده‌سازی کرده باشند. به این ترتیب این وظیفه خود منبع اطلاعاتی است که به استفاده کنندگانش اعلام کند که اطلاعات تغییر یافته.

۶- برای راحتی کار می‌توان از Collectionهای ویژه‌ای مثل BindingList استفاده کرد.

۷- نمی‌دانم این روش Data Binding در WPF خوب است یا بد. اما ظاهراً حق انتخاب دیگری وجود ندارد.




2011/04/25

‫کمی درباره‌ی WCF

WCF یکی از امکانات نسبتاً جدید ‎.Net Framework است که در برنامه‌های توزیعی، سرویسی و معماری SOA کاربرد دارد. هدف مایکروسافت از ارائه WCF یکی کردن امکانات سرویسی قدیمی از جمله Web Serivceها، ‎.Net Remoting، Socket Programming و Pipelineها می‌باشد. در رابطه با WCF به چند نکته می‌توان توجه کرد:

۱- اگر کارتان با یک وب سرویس ساده راه می‌افتد سراغ WCF نروید. چون راه اندازی یک وب سرویس ساده خیلی خیلی ساده‌تر از راه انداختن یک سرویس WCF است.

۲- یک سرویس WCF را صرفاً از طریق فایل config آن می‌توان طوری تنظیم کرد که از هر یک از روش‌های دلخواه انتقال اطلاعات از جمله ارتباط وب سرویسی یا ارتباط از طریق TCP استفاده نماید. این تغییر از دید برنامه Host کاملاً مخفی است.

۳- یک سرویس WCF به طور هم زمان می‌تواند روی هر تعداد از روش‌های مثل TCP، وب سرویس یا Pipeline سرویس دهد.

۴- Hosting سرویس‌های WCF هم می‌تواند از طریق IIS باشد و هم می‌تواند از طریق ویندوز سرویس یا یک برنامه مستقل انجام پذیرد.

۵- کار با WCF آدم را خیلی زیاد به یاد ‏‎.Net Remoting می‌اندازد.


منبع:
فصل ۲۵ کتاب Apress Pro C# 2010 and the .NET 5 Platform




2011/04/23

بی‌اطمینانی به مایکروسافت

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

اما از وقتی که با NHibernate آشنا شدم و روال کار آن را با LINQ-to-SQL و Entity Framework مقایسه کردم دیدم که یک جای کار می‌لنگد. NHibernate با احستاب سوابق جاوایی‌اش چندین سال است که به خوبی کار کرده و خیلی کم دچار تغییرات شدید شده است. کلیاتی که از NHibernate یاد گرفته‌ام هنوز همان است و مجبور نشده‌ام به جز LINQ-to-NHibernate که یک افزونه جدید حساب می‌شود نه یک تغییر، چیز اساسی یاد بگیرم. اما کسانی که ORM را با مایکروسافت شروع کرده‌اند مثل من راحت نبوده‌اند. چون اول وقت زیادی روی LINQ-to-SQL گذاشتند ولی بعد از مدت کوتاهی به آنها اعلام شد که LINQ-to-SQL دیگر توسعه داده نخواهد شد و به جای آن باید از Entity Framework استفاده کنند. این یعنی چیزی را که یاد گرفته و به آن عادت کرده‌اید را باید به طور کامل دور ریخته و فناوری جدیدتری را با صرف کلی وقت یاد بگیرید.

مشابه این مسئله را در SourceSafe و جایگزینی آن با TFS هم دیده‌ام. کسانی که با SourceSafe کار می‌کردند مجبور شدند آن را با TFS عوض کنند. اما کسانی که از همان اول با SVN کار می‌کردند هیچ وقت دچار همچین اجباری نشدند. حدس می‌زنم همین مسئله را در مورد Web Serviceها از یک سو و ‎.Net Remoting و WCF از دیگر سو داشته باشیم.

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




2011/04/21

‫تعیین نوع fetch در Search APIهای NHibernate

برای آن که NHibernate بتواند به طور بهینه از Caching استفاده نماید باید Fetch در Entityها و Queryها به طور مناسبی تعریف شده باشد. Fetch به طور کلی به NHibernate می‌گوید sql دریافت اطلاعات از دیتابیس را چطور تولید کند. یک select کلی از همه جداول با استفاده از outer joinهای متعدد یا selectهای جداگانه به ازای هر جدول. مزیت عمده select جداگانه وقتی است که آن اطلاعات از قبل در Cache موجود باشند.

Fetch در Queryهای دیتابیسی NHibernate و APIهای مختلف جستجوی آن روش‌های متفاوتی دارد:
  • در HQL با استفاده join fetch انجام می‌شود. ±
  • در Linq-to-NH با استفاده از Expand و Fetch انجام می‌شود. ±
  • در QueryOver با Fetch انجام می‌شود (مشابه linq-to-nh). ±
  • در ICriteria با SetFetchMode انجام می‌شود. ±




2011/04/19

‫clientها و ابزارهای کار با git در ویندوز

mysysgit
خود git است که به صورت command line کار می‌کند.

Cygwin
اجرای git از طریق Cygwin که یک شبیه ساز برنامه‌های لینوکس در ویندوز است.

gitk و git-gui دو ابزار گرافیکی که همراه با خود git نصب می‌شوند.

TortoiseGit
با ویندوز یکی می‌شود. مشابه TortoiseSVN. ظاهراً امکانات خوبی دارد و برای کسانی که به TortoiseSVN عادت دارند خیلی مناسب است.

Git-Cheetah
با ویندوز یکی می‌شود. البته نسبت ویندوزی بودن آن اصلاً مطمئن نیستم.

Git Extensions
با ویندوز یکی می‌شود. به صورت Add-on به ویژوال استودیو هم اضافه می‌شود. ولی Add-on ویژوال استودیو آن اصلاً جالب نیست. تنها کلاینتی است (به جز command line) که تا کنون با آن کار کرده‌ام.

Git Source Control Provider
این برنامه صرفاً یک Visual Studio plugin است. به نظر می‌رسد امکانات خوبی داشته و جای خالی AnkhSVN را بتواند پر کند.

SmartGit
صرفاً یک برنامه ویندوزی کار با git بدون integration با ویندوز یا Visual Studio بوده و ضمناً غیر رایگان است.

GitForce
مشابه SmartGit صرفاً یک برنامه ویندوزی کار با git بدون integration با ویندوز یا ویژوال استودیو بوده ولی رایگان می‌باشد.

Git#‎
API کار با git در C#‎.


اطلاعات بیشتر:




2011/04/18

‫لذت Low Level

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

اما این روزها حس Low Level دوستی‌ام با دو چیز به خوبی ارضا می‌شود. یکی ریزه‌کاری‌های NHibernate مثل Fetch Mode، First/Level Cache و Mappingها و دیگری ور رفتن با git به عنوان یک ابزار سورس کنترل غیر متمرکز. git و ساختار و نحوه استفاده آن آنقدر جذابیت دارد که می‌توان ساعت‌ها بدون بلند شدن از جلوی کامپیوتر با آن کار کرد.




آگهی استخدام تامل برانگیز

در نیازمندهای همشهری امروز ۲۹ فروردین ۱۳۹۰ یک آگهی استخدام جالب چاپ شده. بخوانید و خودتان قضاوت کنید:






«برنامه نويس جهت دانلود»

, برنامه نویس جهت دانلود , نرم افزار واتوران سازی
88938103





2011/04/17

‫روش‌های ایجاد git server در ویندوز

راه اندازی git server در ویندوز راه‌های گوناگونی دارد که متاسفانه تعداد کمی از آنها ساده و کوتاه بوده و عمدتاً هم نیاز به کمی مهارت لینوکس و ور رفتن‌های فراوان با ابزارهای لینوکسی مثل cygwin دارند. در ادامه بعضی از روش‌ها و راهنماها معرفی می‌شوند.

۱- با استفاده از CopSSH: این روش نیازی به استفاده از cygwin پیدا نکرده بنابراین ساده‌تر و مطمئن‌تر هم هست. به این راهنما و این راهنما مراجعه کنید. راهنمای فارسی و خلاصه‌ای از این دو راهنما هم در این آدرس موجود است.

۲- با استفاده از cygwin و gitosis: این راهنما مستلزم استفاده سنگین از cygwing و python و OpenSSH و gitosis است. این راه، تقریباً سخت‌ترین راه بوده و عملاً مثل این است که یک سرور لینوکس نصب کرده و مراحل را روی آن انجام داده‌اید. cygwin محیط و امکانات لینوکس را در ویندوز ارائه می‌دهد. مزیت این راه حل ظاهراً مدیریت راحت‌تر کاربران است. علاوه بر این، روش gitosis در کنار روش WebDAV که از پروتکل http استفاده می‌کند، کامل‌ترین روش git server است. به این راهنما مراجعه کنید.

۳- با استفاده از cygwin و cygrunsrv و git daemon: مراحل انجام این روش کوتاه و ساده است. ولی من خودم به خاطر مشکلی که ظاهراً از IPv6 ویندوز ۷ بود نتوانستم آن را انجام دهم. در این روش از SSH استفاده نمی‌شود بنابراین امنیت وجود ندارد. ظاهراً مشکلاتی هم در رابطه با push و read only بودن مخزن دارد. به این راهنما مراجعه کنید.


۴- استفاده از git daemon به طور مستقیم در ویندوز: در این روش که بسیار ساده هم هست از پروتکل git مثل git://myserver استفاده می‌شود. پیدا کردن آدرسی دهی، احتمال read only بودن مخزن آن و مشکل concurreny یعنی push کردن هم زمان چند کاربر از جمله مشکلات احتمالی این روش می‌باشد. به اینجا مراجعه کنید.

۵- استفاده از File Sharing: مشابه آنچه که در SourceSafe انجام می‌شد. یعنی یک مخزن bare ساخته شده و در شبکه به اشتراک گذاشته می‌شود. سپس افراد با استفاده از urlهای فایلی به آن دسترسی پیدا می‌کنند. در این روش هیچ امنیتی وجود ندارد. مشکل Concurrency هم دارد. هر وقت کسی بخواهد push کند باید به بقیه استفاده کنندگان اطلاع دهد که تا اتمام push او هیچ کس دیگری push نکند. با وجود این معایب، این راه ساده‌ترین روش ممکن بوده و هیچ دردسری ندارد. به این راهنما مراجعه کنید.




2011/04/16

‫جایزه AAFS و Social benefit از FSF

بنیاد نرم‌افزارهای آزاد FSF هر ساله دو جایزه اهدا می‌کند به نام‌های توسعه نرم‌افزار (Advancement of Free Software award: AAFS) و کمک به اجتماع (Social benefit).


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

۱- Rob Savoye به خاطر Gnash. این نرم‌افزار جزیی از پروژه GNU است و قرار است جایگزینی باشد برای Adobe Flash.


۲- Andrew Tridgell به خاطر Samba. این نرم‌افزار پروتکل شبکه‌ای SMB/CIFS را پیاده‌سازی کرده.

۳- Guido van Rossum به خاطر Python.

۴- Larry Wall به خاطر Perl و بقیه کارهایش.


جایزه کمک به اجتماع (Social Benefit) به پروژه‌ها یا تیم‌هایی اهدا می‌شود که منفعتی به جامعه برسانند. چند تا از برندگان این جایزه عبارتند از Tor به خاطر کمک به حفظ حریم شخصی در اینترنت، پروژه بایگانی اینترنت، اجازه نامه Creative Commons، پروژه Sahana به خاطر کمک به آسیب دیدگان از بلایای طبیعی و ویکی‌پدیا.




‫راه اندازی git server در ویندوز با استفاده از CopSSH

یکی از راه‌های نصب git به صورت سرویس ویندوز، استفاده از CopSSH می‌باشد. مراحل انجام این کار در ویندوز ۷ (۳۲ بیتی) به صورت زیر است:

۱- دریافت CopSSH و نصب آن.

۲- حتماً مسیر نصب را از Program Files به مسیری در C:\‎ مثل C:\SSH تغییر دهید. در غیر این صورت در مراحل بعدی به خاطر وجود کاراکتر «فاصله» در فولدر Program Files دچار مشکل خواهید شد.

۳- در بقیه مراحل پیش فرض‌های خود برنامه نصب را بدون تغییر قبول کنید.

۴- Passwordی که به اکانت SvcCOPSSH اختصاص می‌دهید فراموش نکنید.

۵- بعد از اتمام مراحل نصب، با استفاده از COPSSH Control Panel کاربر فعلی ویندوز را انتخاب کرده و آن را به فهرست Activated users اضافه کنید. فرض می‌کنیم نام کاربر mohebbi و نام کامپیوتر Amir-PC است. در این مرحله چیزی شبیه به این دیده می‌شود:



۶- برنامه PuTTY را دریافت و نصب کنید. PuTTY مجموعه‌ای از چند برنامه است که ما فقط با دو تا از آنها کار داریم. اگر TortoiseGIT را در سیستم‌تان نصب دارید، آن دو تا برنامه را در فولدر TortoiseGIT هم می‌توانید پیدا کنید.

۷- با استفاده از برنامه PUTTYGEN یک کلید عمومی و یک کلید خصوصی بسازید.



۸- کلید عمومی را در فایلی به نام authorized_keys ذخیره کنید. این فایل باید در مسیر c:\users\mohebbi\.ssh قرار بگیرد.

۹- کلید خصوصی را با نام private_key.ppk در مسیر C:\SSH\home\mohebbi\.ssh ذخیره کنید. استفاده از passphrase اختیاری است.

۱۰- فایل ‎.bashrc که در مسیر C:\SSH\home\mohebbi قرار دارد را با ویرایشگر خوبی مثل Visual Studio باز کنید.

۱۱- خط  User dependent .bashrc file را پیدا کرده و زیر آن خط export HOME=/c/SSH/home/mohebbi را اضافه کنید. bach به بود و نبود فاصله‌ها و کوچک و بزرگ بودن حروف خیلی حساس است. پس ممکن است مجبور شوید اول و آخر این خط را کمی دستکاری کنید.



۱۲- از همین فایل یک کپی تهیه کرده و در آدرس c:\users\mohebbi قرار دهید.

۱۳- Unix BASH Shell را از منوی Copssh اجرا کرده و دستور echo $HOME را در آن صادر کنید. با فرض این که msysgit را نصب کرده‌اید، Git Bash را هم اجرا کرده و مجدداً دستور echo $HOME را در آنجا هم صادر کنید. خروجی هر دوی آن باید یک چیز باشد و آن هم: /c/SSH/home/mohebbi

اگر این طور نبود مراحل ۱۱ و ۱۲ را آنقدر تکرار کنید تا مسئله حل شود.



۱۴- msysgit که همان توزیع اصلی git در ویندوز است را نصب کنید. اما باز هم در مسیر root درایو C نصب کنید. نه در Program Files.

۱۵- کل محتویات شاخه‌های bin و libexec\git-core از محل نصب git را به شاخه bin فولدر نصب SSH کپی کنید. راه درست انجام این کار تنظیم صحیح Path و سایر متغیر محیطی ویندوز و بعضی تنظیمات bash است. اما من چون راه بهتری پیدا نکردم از این راه استفاده کردم.

۱۶- برنامه PAGEANT از مجموعه PuTTY را اجرا کنید. این برنامه به طور خودکار در tray قرار می‌گیرد. روی آن دابل کلیک کرده و کلید private_key.ppk را از آدرس C:\SSH\home\mohebbi\.ssh به آن اضافه کنید.



۱۷- برنامه PAGEANT باید همیشه در حال اجرا باشد. پس بهتر است آن را به startup ویندوز اضافه کنید. دادن مسیر کلید خصوصی فراموش نشود.

۱۸- مراحل نصب تمام شد. حالا در مسیر C:\SSH\home\mohebbi یک شاخه با اسم فرضی myapp.git بسازید. با کمک git، شاخه myapp.git را به یک bare repo تبدیل کنید. اینجا همان repo است که قرار است دیگران از طریق سرویس ویندوز شما به آن دسترسی پیدا کنند.

۱۹- مراحل نصب به پایان رسید. حالا از یک کامپیوتر دیگر با استفاده از git client دلخواه خود، مثلاً TortoiseGit، به git server جدیدتان وصل شده و با وارد کردن آدرس ssh://mohebbi@amir-pc/SSH/home/mohebbi/myapp.git یک clone از مخزن تهیه کنید.



۲۰- کل مراحل به پایان رسید. حال فقط چند فایل را به طور امتحانی commit و push/pull کنید تا مطمئن شوید همه چیز درست است.




راه اندازی git server با استفاده از ویندوز کار چندان راحتی نیست. حین اجرای این مراحل مشکلات خیلی زیادی ممکن است به وجود بیاید. این مشکلات باید با سعی و خطای فراوان، حوصله و کمی مطالعه و خلاقیت حل شوند. من کل این مراحل را با استفاده از ویندوز هفت ۳۲ بیتی و آخرین نسخه هر یک از ابزارهای ذکر شده در تاریخ ۲۶ فروردین ۱۳۸۹ انجام دادم. این راهنما خودش بر اساس راهنمای tim davis و راهنمای مربوطه در TortoiseGit نوشته شده است. در صورت بروز مشکل می‌توان از این دو راهنما هم استفاده کرد. اما دقت کنید که راهنمای tim davis بر اساس نسخه‌های قدیمی ابزارها نوشته شده و راهنمای TortoiseGit هم به جای تکیه بر git استاندارد به خود TortoiseGit وابستگی دارد.




2011/04/15

‫به اشتراک گذاشتن سورس‌های git


مهم‌ترین مزیت git از دید من خاصیت Distributed آن است. به این معنی که فرضاً در یک سرور git اینترنتی سورسی وجود دارد که من یک نسخه از آن را در laptop خودم clone کرده‌ام. حالا می‌خواهم در کامپیوتر منزلم که دسترسی به اینترنت و آن سرور git اینترنتی ندارد هم همین سورس را داشته باشم. به عبارتی دیگر می‌خواهم از کامپیوتر منزلم به laptop وصل شده و سورس را دریافت کنم. ضمن این که بتوانم بین کامپیوتر منزلم و laptop به راحتی تغییرات سورس را رد و بدل (push/pull) کنم.

چندین راه برای این کار وجود دارد. راه اصلی آن همان طور که می‌شود حدس زد راه اندازی یک git server است. هر چند که انجام این کار سخت نیست اما چون git یک ابزار لینوکسی است و برای راه اندازی یک git server نیاز به کار کردن با چند ابزار لینوکسی دیگر مثل openSSH است، بهتر است از راه‌های ساده‌تری استفاده شود.

در این لینک چندین راه ساده برای انجام این کار توضیح داده شده است. روش File Share در این بین از همه ساده‌تر به نظر رسیده و در ویندوز هم به راحتی قابل انجام است. همان طور که در اینجا و اینجا توضیح داده شده برای این کار باید از یک محل مشترک به اسم Dropbox و یک سورس bare استفاده گردد. ظاهراً Dropbox در لینوکس معادل فولدرهای Share در ویندوز است.

ترتیب مراحل در ویندوز این طور است:

۱- کسب اطمینان از نصب git در هر دو کامپیوتر

۲- کسب اطمینان از این که کامپیوترها می‌توانند IP و فولدرهای share یکدیگر را ببینند.

۳- ایجاد یک سورس bare در فولدر share یکی از کامپیوترها (مثلاً کامپیوتر ۱) با استفاده از دستور git init --bare. اول باید فولدر ساخته شده و این دستور از داخل فولدر مذکور فراخوانی شود.

۴- push کردن سورس از منبع اصلی به این فولدر share با استفاده از دستور git push origin //machine1/shared_git_repo. این دستور باید از داخل دایرکتوری سورس اصلی فراخوانی شود.

۵- اجرای دستور git clone //machine1/shared_git_repo از داخل کامپیوتر ۲ یا هر کامپیوتر دیگری که به این فولدر share دسترسی دارد.

۶- برای push و pull کردن بین فولدرهای داخل یک کامپیوتر می‌توان از urlی شبیه به file://d:/projects/gitrepo استفاده کرد.


با وجود همه این حرف‌ها بهترین راه به اشتراک گذاشتن سورس‌های git استفاده از سرورهای اینترنتی مثل github.com و assembla.com است. چون نیاز به هیچ configuration و نگهداری نداشته و از تمام دنیا قابل دسترس است.




2011/04/13

‫تبدیل سورس‌های svn به git

یک بار وقتی که می‌خواستم سورس‌های موجود در Source Safe را به یک سورس کنترل Subversion منتقل کنم متوجه شدم که کار خیلی سختی است. به این علت که ابزارهای خیلی کمی برای این کار وجود داشت. علاوه بر اینها به نظر می‌رسید history فایل‌ها را نمی‌توان به svn منتقل کرد. هیچ کس هم این کار را توصیه نمی‌کرد. این تبدیل از نظر آنها به درد نخور بوده و توصیه می‌شد که آخرین نسخه سورس Source Safe به صورت یک نسخه کاملاً fresh و بدون هیچ history به svn منتقل شود. من هم در آن زمان مجبور شدم همین کار را بکنم.

اما حالا یک بار دیگر می‌خواهم سورسی را از یک Source Control به یک Source Control دیگر منتقل کنم اما این بار با history. خوشبختانه چون می‌خواهم این بار سورس کد را از svn به git منتقل کنم مشکل چندانی ندارم. این کار چندان سخت نیست. کافی است با کمی جستجو به یک راهنمای خلاصه برسید و مراحل را دنبال کنید. من با کمک این راهنمای چند خطی توانستم سورس یک پروژه موجود در Codeplex را از svn به git منتقل کنم. البته دقت به چند نکته می‌تواند عملیات انتقال را راحت‌تر کند:

۱- باید به جای دستور git-svn از دستور git با سویچ svn استفاده کنید. یعنی به صورت git svn.

۲- git svn با urlهای فایلی مثل file:///d:/repo خیلی مشکل دارد. سعی کنید از urlی مثل svn://myserver استفاده کنید. درست کردن یک سرور با استفاده از svn کار چندان سختی نیست. به این راهنما مراجعه کنید.

۳- حواستان به این موضوع باشد که ساختار branch در svn تفاوت زیادی با git دارد. یعنی اگر می‌خواهید branchها را هم از svn به git منتقل کنید باید کمی documentationهای git را بالا و پایین کنید.

۴- بهتر است قبل از شروع سری به راهنمای git مخصوص svn کارها بیندازید.

۵- من همه این کارها را با کمک Git Extensions انجام دادم.




2011/04/11

‫مشاهده لاگ NHibernate در Visual Studio

اگر پنجره Output را در ویژوال استودیو به هنگام Debug باز کرده و Show output from را برابر Debug قرار داده باشید می‌بینید که ویژوال استودیو خیلی از فعالیت‌های داخلی برنامه را از جمله Load اسمبلی‌ها یا Exceptionهای برنامه را مدام در آنجا فهرست می‌کند. همین کار را در مورد فعالیت‌های داخلی NHibernate هم می‌توان انجام داد.

NHibernate به طور داخلی از log4net برای log فعالیت‌های داخلی خودش استفاده می‌کند. NHibernate تقریباً تمام کارهایش را log می‌کند. به همین دلیل با دنبال کردن این logها هم می‌توان به بسیاری از اشکالات و ایرادات برنامه‌های مختلف پی برد و هم می‌توان مقدار زیادی از مکانیزم داخلی NHibernate را یاد گرفت. روال معمول برای مشاهده این log ریختن آن در یک فایل text و بررسی آن می‌باشد. اما راه ساده‌تر و موثرتری هم وجود دارد. آن هم این است که به log4net بگوییم خروجی log را به جای فایل text به پنجره Output ویژوال استودیو کپی کند.

برای انجام این کار کافی است بعد از معرفی log4net در web.config یا app.config، خطوط زیر را هم اضافه کنید:


  
    
          
  
  
    
    
  
  
    
  




بعد از انجام این کار بایستی در ابتدای شروع به کار برنامه، log4net را هم با عبارت log4net.Config.XmlConfigurator.Configure();‎ مقدار دهی (initialize) کنید.

البته غیر از این یک راه دیگر هم وجود دارد. در راه دوم یک فایل مستقل برای log4net در نظر گرفته می‌شود به اسم log4net.config. خطوط بالا در این فایل کپی شده (خط اول فایل‌های xml فراموش نشود) و سپس برای راه اندازی اولیه log4net به جای روش قبلی از XmlConfigurator.Configure(new FileInfo("log4net.config"));‎ استفاده می‌شود.


منبع:
فصل دوم کتاب NHibernate 3.0 Cookbook




2011/04/09

‫NHibernate Caching و نوع Fetch در Entityها

موقع فعال‌سازی Cache در NHibernate متوجه شدم که فراخوانی بعضی Entityها و بعضی از Queryها از دیتابیس شامل چند join است و عملاً از آن چیزی که در Cache ممکن است موجود باشد استفاده‌ای نمی‌شود. به عنوان مثال فرض کنید کلاس Teacher و Student موجود باشد به نحوی که از کلاس Student یک Association به کلاس Teacher موجود باشد به اسم MyTeacher. حال اگر با متود Load یا Get یک رکورد از Student را از دیتابیس فراخوانی کنیم به طور معمول با چنین چیزی مواجه می‌شویم:

select col1, col2, ... from student s left outer join teacher t on s.myteacher_id = t.id where ...

همان طور که مشاهده می‌شود اگر تمام Teacherها هم در Cache موجود باشد باز هم به آنها مراجعه نشده و مورد استفاده قرار نخواهند گرفت چون query بالا خودش راساً اقدام به load رکورد teacher مربوطه می‌کند.

این موضوع جای نگرانی ندارد چون می‌توان NHibernate را مجبور کرد که از join استفاده نکرده و query بالا را به دو query زیر بشکند:

select col1, col2, ... from student s where ...

select col1, col2, ... from teacher t where id = ...

در این حالت اگر teacher مورد نظر ما در Cache موجود باشد، query دوم اطلاعاتش را به جای دیتابیس از Cache می‌خواند.

برای مجبور کردن NHibernate به عدم استفاده از join در سطح Load/Get مربوط به Entityها باید از property خاصی به اسم fetch در تعریف associationها در mapping کلاس مربوطه استفاده کرده و مقدار آن را برابر select قرار داد. مقدار پیش‌فرض این property برابر join است. برای انجام همین کار در Castle ActiveRecord باید از property خاصی به اسم Fetch استفاده کرد.

برای آن که در queryهای دیتابیسی مثل LINQ-to-NHibernate، HQL، ICriteria یا QueryOver هم همین کار را انجام داد باید از روش‌های متفاوت و جداگانه‌ای استفاده نمود.




2011/04/07

‫‫استفاده از Stored Procedure و Trigger در NHibernate و تاثیر آنها بر Caching

در رابطه با NHibernate رایج است که هر جا حس کردیم NHibernate یا مهارت خودمان در استفاده از آن دچار محدودیت است فوراً دست به کار شده و ضمن دور زدن مکانیزم NHibernate session managment مستقیماً از SQL در برنامه‌مان استفاده کنیم. مثلاً وقتی که نمی‌توانیم از eventهای مرتبط با Save/Update در NHibernate به درستی استفاده کنیم یک تریگر روی جدول مورد نظر می‌گذاریم. یا مثلا وقتی که سرعت update جدول یا فیلدی خیلی پایین است، حالا یا به علت محدودیت‌های خود NHibernate یا به علت عدم استفاده صحیح خودمان، آن وقت یک Stored Procedure نوشته و عملیات مورد نظر را به جای NHibernate از طریق آن انجام می‌دهیم.

این نوع دور زدن NHibernate به غیر از این که نرم‌افزار را از لحاظ فناوری دو تیکه و ناخوانا می‌کند، مشکل دیگری نیز دارد. چون این طور کارها از دروازه NHibernate session management رد نمی‌شوند، NHibernate هم از تغییرات داده‌ای آنها بی‌خبر مانده و نمی‌تواند Cache را (چه سطح اول و چه سطح دوم) به خوبی به روز رسانی کند. در نتیجه مقادیر موجود در Cache نامعتبر شده و آنچه که از Cache دریافت می‌داریم ممکن است قدیمی و به درد نخور باشد. چون یک تریگر یا sp دور از چشم NHibernate آنها را تغییر داده است. در این طور مواقع تنها کاری که می‌توان کرد عدم استفاده از روش‌های این چنینی یا چشم پوشی از Caching می‌باشد.




2011/04/05

معضل جابجایی نیروی انسانی

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

* من نیروی انسانی واقعاً از بابت ضررهایی که شرکت مطبوعم از این راه می‌کند متاسفم ولی باور کنید بنا به یک سری دلایل، کار زیادی از دست من نوعی هم بر نمی‌آید.

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

* به زعم من بخشی از این مشکل مربوط به نحوه کار به شدت سفارشی سازی (Customize) شده شرکت‌هاست به طوری که سویچ کردن از یک فرد به یک فرد را (در صورت جابجایی) به شدت پر هزینه می‌کند.

* اگر مسئولیت یک شرکت با من بود به گزینه پرورش نیروی انسانی هم فکر می‌کردم.

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




2011/04/03

تزریق انقلابی

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

در این طور موارد اگر فرد برنامه‌نویس آن قدر وقت و حوصله نداشته که همه این موارد را بررسی کرده و ضمناً معتقد باشد که feature مورد نظر چندان هم اثر بدی رو کلیت سیستم ندارد و می‌توان موارد جزیی به وجود آمده را بلافاصله رفع و رجوع کرد آن وقت می‌توان از یک روش انقلابی استفاده کرد. من اسم این روش را «تزریق انقلابی» گذاشته‌ام. به این معنی که ابتدا موارد اصلی بررسی شده و سپس feature مذکور بدون آن که توجه کسی (مشتری/کاربر/کارفرما/مدیر پروژه/…) به آن جلب شود به سیستم تزریق (اضافه) گردد. البته مدتی هم باید گوش به زنگ مشتری ماند تا هر گونه ایراد و اشکال احتمالی سریعاً برطرف گردد.




2011/04/01

‫فواید LINQ و LINQ-to-Objects

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

در مورد این entityها به ذهنم رسید که همه آنها در ابتدای کار برنامه به جای ثابتی در حافظه load کرده و سپس هر وقت که با آنها کار داشتم از آنجا استفاده کنم. خوشبختانه چون قبلاً از LINQ برای query زدن استفاده کرده بودم، روال query زدن از objectهای موجود در حافظه چندان سخت نبود. کافی بود در query دیتابیسی مقدار in را به جای خواندن از دیتابیس با آن Array یا Collection موجود در حافظه عوض کنم و بعضی ملاحظات LINQ-to-Objects را رعایت کنم. به این ترتیب هم روش query زدنم عوض نشد و هم مجبور نشدم برای استخراج اطلاعات از حافظه از روش‌های foreach و loop و… استفاده کنم.