‫خلاصه‌ای کوتاه از پروتکل HTTP

HTTP پروتکلی برای تبادل اطلاعات بین Web Serverها و Web Broswerها است. HTTP در معماری شبکه در بالاترین لایه یعنی لایه Application قرار دارد. این پروتکل مبتنی بر text ساده است و بر پایه پروتکل TCP کار می‌کند.

HTTP یک پروتکل Client-Server بوده و از جفت‌های Request/Response تشکیل شده است. هر گاه Browser درخواستی از Web Server داشته باشد، درخواست خودش را از طریق قالب Request به سرور می‌فرستد. یک درخواست می‌تواند شامل درخواست کد html یک صفحه خاص یا ارسال اطلاعات login به یک سرور باشد. سرور به ازای هر Request یک Response می‌فرستد. داخل هر Response اطلاعاتی نظیر جواب سرور، headerها و encoding قرار می‌گیرد. تفاوت نسخه 1.0 و 1.1 این پروتکل خیلی زیاد نیست. نسخه 1.1 سریعتر عمل می‌کند.

برای امتحان کردن پروتکل یک وب سرور بدون استفاده از Browser می‌توان از ابزار ویندوزی telnet استفاده کرد. برای این کار در command prompt دستور telnet karvis.ir 80 را وارد کنید. سپس دستور GET /index.html را در محیط آماده telnet صادر کنید. telnet محتواب فایل index.html را به شما نمایش خواهد داد (به جای karvis.ir می‌توانید از هر وب‌سایت دیگری هم استفاده کنید). علاوه بر اینها می‌توانید از فیدلر به عنوان یک ابزار خیلی قدرتمند برای مشاهده و دستکاری Request/Response استفاده کنید.

headerها نقش مهمی در Request/Responseها دارند. خیلی از اطلاعاتی که ما راجع به اطلاعات و صفحات وب داریم در headerها ذخیره می‌شوند. شناخت متودهای Request مثل GET و POST در استفاده از HTTP خیلی مهم است. اگر کسی بخواهد در زمینه Scraping کار کند یا بخواهد تکنولوژی ASP.NET را کامل بشناسد، حتماً باید اطلاعات خوبی راجع به HTTP داشته باشد.

فیدلر

اگر روزی علاقه‌مند به ور رفتن با HTTP شدید، حالا چرا برای درک عملکرد ASP.NET چه برای مقاصد Web Scraping حتما سری به فیدلر بزنید. با فیدلر می‌توان تمام Requestها و Responseها ارسالی و دریافتی از وب‌سرور را مشاهده کرده و در صورت نیاز دستکاری کرد. مثلاً یکی از اولین چیزهای جالبی که می‌شود با فیدلر دید، passwordهایی است که سایت‌های غیر https بدون هیچ مخفی‌سازی به سرور می‌فرستند. با فیدلر می‌توان حجم بخش‌های مختلف تشکیل دهنده یک صفحه وب نوعی را به دست آورد. 

بهترین راه آشنایی با فیدلر دیدن ویدئوهای آن است. این ویدئوها از این آدرس قابل دریافت هستند.

‫Mocking با استفاده از Moq

Mocking روشی در Unit Test است که با کمک آن رفتار کلاس‌ها و آبجکت‌هایی که وابسته به منابع بیرونی بوده و غیر قابل کنترل هستند سنجیده می‌شود. منظور از آبجکت‌های غیر قابل کنترل، آبجکتی‌های مثل DateTime.Now در دات‌نت، کلاس‌های load اطلاعات از دیتابیس، کلاس‌های کار با deviceهای بیرونی مثل شبکه و فاکس و غیره می‌باشد. همان طور که می‌دانید این طور کلاس‌ها را نمی‌توان با کمک Unit Test مورد آزمایش قرار داد.

یکی از معروف‌ترین ابزارهایی که برای این کار وجود داشت Rhino Mocks بود. یک سال و خورده‌ای پیش سعی کردم از این کتابخانه در Unit Testهایم استفاده کنم. اما به دلیل آن که استفاده از این کتابخانه و فهم آن برایم سخت بود زیاد نتوانستم از آن استفاده کنم. البته نیاز به آن Unit Testها هم کم شده بود و نهایتاً mocking به فراموشی سپرده شد. طی چند روز گذشته که داشتم چند unit test جدید به کارویس اضافه می‌کردم باز هم نیاز به mocking پیدا کردم. نگران بودم که چطور باید با روش پیچیده Rhino Mocks کنار بیام. حدس زدم طی این یکی دو سال Rhino Mocks پیشرفت زیادی کرده و راحت‌تر شده یا این که اقلاً یا منابع یادگیری اون بیشتر شده یا شاید هم frameworkهای mocking جدیدی به وجود آمده‌اند.

با یک search در گوگل فهمیدم حدسم اشتباه نبوده است. کتابخانه جدیدی به اسم Moq وارد عرصه رقابت Mocking شده که خیلی راحت‌تر از Rhino Mocks است. Moq کاملاً بر اساس امکانات C# 3.5 نوشته شده و به همین علت می‌توان به راحتی با Lambda Expression با آن کار کرد. به مثالی که در همان صفحه معرفی Moq آمده دقت کنید تا متوجه سادگی آن شوید. البته Rhino Mocks هم امکان کار با Lambda Expression را دارد اما باز هم به نظر من Moq راحت‌تر و ساده‌تر است. برای مقایسه بین Moq و بقیه فریمورک‌ها به این نوشته اسکات هنزلمن مراجعه کنید. برای کسب اطلاعات بیشتر راجع به mocking و Rhino Mocks به این و این نوشته هم مراجعه کنید.

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

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

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

پندهای جوئل اسپالسکی به دانشجویان کامپیوتر

جوئل اسپالسکی نویسنده وبلاگ joelonsoftware.com و از موسسین stackoverflow.com در یک نوشته طولانی توصیه‌هایی به دانشجویان کامپیوتر کرده. این توصیه‌ها بیشتر در مورد پیدا کردن کار مناسب بعد از تحصیل است. متاسفانه این پندها هم از آن چیزهایی است که من دیر به آن رسیدم. هم از نظر تاریخ انتشار مطلب که مربوط به ۶ سال پیش (۲۰۰۵) است و هم از این نظر که حتی اگر به موقع آن را می‌دیدم باز هم فایده‌ای برایم نداشت، چون آن وقت دیگر دانشجو نبودم.

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

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

‫اولین تجربه با BugNET

BugNET یک نرم‌افزار Issue Tracking کد باز است که با ASP.NET نوشته شده است. قبلاً در سایت آن چیزهای خوبی راجع به امکانات آن خوانده بودم. با این که IssueTracker.NET خیلی رایج‌تر از BugNET است اما امکانات BugNET بیشتر و بهتر به نظر می‌رسید. به همین خاطر تصمیم گرفتم آن را نصب کرده و امکانات آن را از نزدیک ببینم.

خوشبختانه با تعریف اولین پروژه در BugNET فهمیدم که BugNET امکانات مدیریت پروژه را تا حد خوبی پوشش می‌دهد. چیزی که فکر می‌کردم به غیر از جیرا در هیچ نرم‌افزار Issue Tracking دیگری وجود نداشته باشد. BugNET هم امکان تعریف Category و Milestone را دارد و هم امکان استفاده از Issue Typeهایی غیر از نوع باگ. علاوه بر اینها امکان تعریف دسترسی‌ها، تعریف Queryهای مختلف و نگهداری History ایشوها را هم داراست. به همین دلیل می‌توان از آن به عنوان یک نرم‌افزار مدیریت پروژه هم استفاده کرد.

یکی دیگر از امکانات خوب BugNET امکان تعریف نوع Issueها، نوع Statusها، نوع اولویت‌ها و نوع Resolutionهای دلخواه بر حسب نیاز است. در واقع شما هر وقت که یک پروژه جدید تعریف می‌کنید خودتان باید تک تک انواع Issueها و غیره را با نسبت دادن اسم مناسب و تخصیص icon مناسب تعریف کنید. به این ترتیب BugNET را می‌توان کاملاً Customizable نامید.

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

نصب BugNET یکی دو تا قلق کوچک دارد. BugNET نیاز به فریمورک 3.5 دارد. برای دیتابیس هم احتیاج به MS SQL 2005 و بالاتر و یا نسخه Express همان دیتابیس‌ها دارد. به هنگام نصب BugNET باید صفحه Install.aspx را اجرا کنید. در همین حین به چند خط web.config گیر داده می‌شود. من آنها را کامنت کردم و هیچ مشکل خاصی به وجود نیامد. قسمت بد BugNET تنظیم دسترسی‌ها است. در بیشتر برنامه‌های مشابه کافی است که به یکی دو تا فولدر خاص مثل App_Data دسترسی full داده شود. ولی در مورد bugNET باید به کل فولدری که فایل‌ها و فولدرهای bugNET در آن قرار دارد دسترسی full دارد. به همین علت نمی‌توان BugNET را در root یک domain یا حتی sub domain نصب کرد. چون ابزارهای سروری مثل Plesk اجازه تغییر دسترسی فولدرهای حاوی root مثل httpdocs را نمی‌دهند. متاسفانه در BugNET نمی‌توان از تقوم هجری استفاده کرد. مشکل راست به چپ نویسی هم مثل همیشه وجود دارد. مشکل راست به چپ نویسی را می‌توان با استفاده از کاراکترهای کمکی صفحه کلید استاندارد ۹۱۴۷ تا اندازه‌ای حل کرد. البته BugNET کدباز بوده و می‌توان در صورت علاقه کل آن را فارسی کرد.

‫Backup گیری از یک دیتابیس راه دور

فرض کنید به یک دیتابیس MS SQL Server راه دور فقط از طریق Management Studio دسترسی دارید. یعنی سرور هیچ راهی برای انتقال فایل برای ندارد. حالا شما می‌خواهید از دیتابیس مورد نظر backup بگیرید. راه معمول این است که از طریق Management Studio اقدام به Backup گیری کرده و سپس فایل bak مورد نظر را از درایو local سرور مربوطه به محل دلخواه خود کپی کنید. ولی حالا که دسترسی فایلی به سرور ندارید نمی‌توانید از این راه استفاده کرده و باید به فکر راه حل دیگری باشید.

بعضی از Data Centerها یک اینترفیس جداگانه برای کمک به این موضوع دارند. اما اگر این ابزار هم موجود نباشد چه باید کرد؟ بدتر از این تصور کنید دیتابیس مورد نظر از نوع Express بوده و دسترسی‌های شما در حداقل ممکن قرار داشته باشد. در این طور مواقع چند راه به ذهن می‌رسد.

۱- اسکریپت کردن دیتابیس و نگهداری اسکریپت‌ها به عنوان backup. من این راه رای برای یک دیتابیس SQL Express انجام دادم ولی جواب نگرفتم.

۲- استفاده از مکانیزم Export. خوشبختانه این راه را در مورد دیتابیس مورد قبل انجام دادم و جواب داد.

۳- کد نویسی و استفاده از Sql Server Management Object. من از این راه استفاده نکردم ولی خیلی به آن خوشبین نیستم. چون ظاهراً این کدها باید در همان ماشینی اجرا شوند که SQL Server در آن نصب است. خیلی از مواقع Database Server ما با Web Server یکی نیست.

۴- استفاده از راه حل خیلی خلاقانه‌ای که در این مقاله codeproject.com توضیح داده شده. در این راه حل هیچ نیازی نیست که برنامه backup گیری روی database server اجرا شود. می‌توان آن را روی کامپیوتر local غیر سرور خود اجرا کرد. روش این برنامه گرفتن backup روی خود سرور، ایجاد یک جدول دیتابیسی موقتی، insert کردن محتوای فایل backup در جدول موقتی، select معمولی از جدول موقتی و انتقال آن به کامپیوتر local و ذخیره آن به صورت یک backup واقعی! البته من با این که با یکی از قلق‌های این برنامه کنار آمدم ولی نتوانستم از آن استفاده واقعی بکنم. چون احتیاج به دسترسی bulk داشتم. هر چند که این روش برای من کار نکرد ولی خلاقیت آن مرا شگفت زده کرد. مطمئن هستم می‌توان با استفاده از راه حل های مشابهی مشکل دسترسی bulk را هم حل کرد.

مشکل دیتابیس در سرورهای اشتراکی

در سرورهای اشتراکی، از همان‌هایی که در ایران خیلی رایج هستند و قیمتی زیر ۱۰۰ هزار تومان در سال دارند، همیشه محدودیت در دیتابیس وجود دارد. بیشتر سرویس‌ها اجازه بیش از یکی دو تا دیتابیس MS SQL Server را نمی‌دهند، آن یکی دو تا هم گاهاً نسخه‌های قدیمی MS SQL Server هستند. علاوه بر اینها محدودیت‌های شدید حجمی هم برای دیتابیس وجود دارد. با این که MySQL رایگان است ولی مشابه همین محدودیت‌ها در رابطه با MySQL هم وجود دارد.

در ادامه چند راه جایگزین را بررسی می‌کنیم:

۱- استفاده از دیتابیس‌‌های Embed مثل Sqlite
۲- استفاده از فایل Access با کمک ODBC
۳- استفاده از MS SQL Server Express در صورت وجود در Web Server
۴- خرید VPS و نصب دیتابیس MS SQL Server Express به طور قانونی و MS SQL Server غیر Express به طور غیر قانونی
۵- تبدیل کامپیوتر منزل یا شرکت به یک سرور کوچک با اجاره ماهیانه IP Static از ISPها و نصب MS SQL Server مشابه مورد قبل
۶- خرید MS SQL Host از شرکت‌های خارجی
۷- استفاده از MS SQL Hostهای مجانی

همه این راه حل‌ها یک محدودیت مشترک دارند. آن هم ناسازگاری برنامه‌های مختلف با دیتابیس‌های مختلف و محدودیت‌های فنی در تکنولوژی‌های دسترسی به دیتابیس است. مثلاً برنامه BugNET نمی‌تواند با Access کار کند. برنامه ‌BlogEngine.NET هم نمی‌تواند با Sqlite کار کند. در مورد محدودیت‌های فنی می‌توان به عدم امکان استفاده از دیتابیس‌های غیر MS SQL Server با Entity Framework اشاره کرد. در مورد استفاده از VPS یا IP Static هم باید دقت کرد که این سرویس‌ها باید uptime واقعاً بالا داشته و از پهنای باندی خوبی استفاده کنند. در مورد نسخه‌های غیر قانونی هم نمی‌توان خیلی مطمئن بود. چون ممکن است سرور مورد نظر به خاطر عدم رعایت Copyright بسته شود. در مورد خرید Host از شرکت‌های خارجی می‌توان خوشحال بود که قیمت تمام شده آنها خیلی پایین‌تر از قیمت شرکت‌های داخلی است. از Hostهای مجانی هم می‌شود استفاده کرد ولی هم مشکل عدم اطمینان وجود دارد و هم مشکل کمبود امکانات فنی مثل نبود امکان ‌Backup/Restore.

ضرورت تکنولوژی

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

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

شکست نظامی ناشی از عدم استفاده از تکنولوژی روز فقط مختص به ما نیست:

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

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

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

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

می‌دانستید روزهایی در بورس تهران وجود داشته که انجام معاملات متوقف شده آن هم به این علت که نرم‌افزار هدایت معاملات، توانایی پردازش ارقامی بزرگتر از یک حد معین را نداشته؟ می‌دانستید سال‌هاست سازمان امور مالیاتی کشور به دنبال شرکتی می‌گردد که بتواند یک نرم‌افزار جامع مالیاتی تهیه کند ولی موفق نمی‌شود؟ می‌دانستید که یکی از نهادهای مهم کشور هرگز موفق نشده برای رفع نیازهای داخلی خودش به یک نرم‌افزار با قابلیت image processing از یک شرکت داخلی نرم‌افزار تهیه کند؟ آیا می‌دانستید که در زمان شروع پروژه کارت ملی شایع بود که به علت ناتوانی ایرانی‌ها، یک شرکت هندی نرم‌افزارهای مورد نیاز برای پروژه کارت ملی را تهیه کرده؟ آیا می‌دانستید…

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

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

ابزارهای استخراج اطلاعات از صفحات وب

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

یکی از ابزارهای معروف این کار در دات‌نت Html Agility Pack است. با دقت به نمونه کدهای آن می‌توان اظهار داشت که استفاده از آن خیلی راحت است. فقط کافی است کمی با XPath، ساختار داخلی Html و string processing آشنا باشید تا بتوانید به راحتی از آن برای استخراج اطلاعات از صفحات وب بزرگ و پیچیده استفاده کرد. با کمک این ابزار می‌توان صفحات، لینک‌ها، pagingها و دیگر عناصر صفحات وب را browse کرده و اطلاعات مورد نیاز را استخراج کرد.