‫خلاصه‌ای کوتاه از پروتکل 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 به این و این نوشته هم مراجعه کنید.

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

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

• برای راه اندازی یک Forum از Yet Another Forum.NET - YAF استفاده کنیم نه از phpBB
• برای راه اندازی یک Wiki از ScrewTurn Wiki استفاده کنیم نه از MediaWiki
• برای راه اندازی یک وبلاگ از BlogEngine.NET استفاده کنیم نه WordPress
• برای راه اندازی یک Issue Tracker از BugNET استفاده کنیم نه از Bugzilla

اولین دلیل این است که مشکلات نصب کمتری خواهیم داشت. به عنوان یک برنامه‌نویس دات‌نت آشنایی خیلی بیشتری با 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 کرده و اطلاعات مورد نیاز را استخراج کرد.

‫نمودار گرافیکی با استفاده از ASP.NET

همیشه دیده بودم هر کسی می‌خواهد در صفحات ASP.NET از نمودارهای گرافیکی و چارت‌ها استفاده کند مستقیماً به سراغ کنترل‌های سنگین و گران قیمتی مثل Dundas، تلریک یا ComponentOne می‌رود. همیشه به خودم می‌گفتم برای کارهای گرافیکی خیلی سبک حتماً کنترل‌های سبک و رایگانی هم وجود دارد.

اخیراً به یک نمودار گرافیکی نیاز پیدا کردم و متوجه شدم خود مایکروسافت کامپوننتی را برای این موضوع منتشر کرده به اسم ASP.NET Charting Control. این کامپوننت که با ASP.NET 3.5 هم کار می‌کند هیچ اجباری به نصب یا تغییر IIS سرور ندارد و جان می‌دهد برای سرورهای اشتراکی. من از این کامپوننت برای بخش آمار کارویس استفاده کردم. برای دیدن این نمونه به بخش آمار کارویس و برای کسب اطلاعات بیشتر راجع به خود کامپوننت، نمونه‌های آن یا نحوه دانلود آن به اینجا مراجعه کنید.

‫تجاربی از LibreOffice

به خاطر دلخوشی خودم و به خاطر کسب آمادگی برای سویچ احتمالی به لینوکس، مدتی است که سعی می‌کنم به جای MS Office از LibreOffice استفاده کنم. LibreOffice کاملاً مشابه Open Office بوده و توسط تعدادی از برنامه‌نویسان قبلی Open Office اداره می‌شود. بد ندیدم نکاتی را که به عنوان یک ویندوز کار به آن برخورد کردم را بیان کنم.

۱- مهم‌ترین مزیت استفاده از LibreOffice برای من رایگان بودن آن، رهایی از مشکلات کرک و آسوده خیالی ناشی از رعایت کپی رایت می‌باشد.
۲- مهم‌ترین مشکلی که با LibreOffice دارم عادت نداشتن به آن است. به عنوان کسی که از زمان ویندوز ۳٫۱ از MS Office استفاده می‌کرده برایم خیلی سخت بوده و هست که به LibreOffice عادت کنم.
۳- ظاهراً LibreOffice Writer با متون دو زبانه مشکل دارد. گاهی اوقات که در یک پاراگراف فارسی از چند کلمه انگلیسی و بعضی کاراکترها مثل خط تیره استفاده می‌کنم. کلمات انگلیسی فارسی توی هم فرو می‌روند و به هیچ وجه قابل اصلاح نیستند.
۴- در Writer مکان‌نما در جای صحیح نشان داده نمی‌شود. یعنی زیادی به حروف یا حاشیه پاراگراف چسبیده است.
۵- نمی‌توانم در Writer فونت پیش فرض را عوض کنم.
۶- در MS Word می‌توانستم با یک shortcut خاص سایز فونت همه نوشته را با هم یکی بالا ببرم یا یکی پایین بیاورم. انجام این کار در Writer برایم غیر ممکن است.
۷- Paste کردن حتی از notepad باعث به هم ریختگی فونت می‌شود.

البته ممکن است همه این مشکلات به خاطر نا آشنایی خودم یا اجرای LibreOffice در ویندوز باشد.

یاد و خاطره استیو جابز

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

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

یاد و خاطره استیو جابز گرامی باد.

پول ویندوز را بدهیم یا ندهیم؟

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

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



راه اول: کنار گذاشتن اخلاق و استفاده غیر قانونی از محصولات مایکروسافت

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

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

راه سوم: پرداخت کامل هزینه لایسنس ویندوز و بقیه محصولات:
اول باید ببینیم هزینه استفاده از محصولات قانونی چقدر است و آیا از عهده ما بر می‌آید یا نه. از آنجا که خیلی از شرکت‌ها و برنامه‌نویس‌ها از تمام امکانات محصولات مایکروسافت استفاده نمی‌کنند و از آنجا که فعلاً می‌خواهیم با کمی صرفه جویی کارمان را شروع کنیم، از هزینه خرید ویندوز سرور چشم پوشی کرده و به جای آن از ویندوز ۷ استفاده می‌کنیم. در مورد Visual Studio و MS SQL هم سعی می‌کنیم کارمان را با نسخه‌های express یا محصولات رایگان دیگر مثل MySql یا SharpDevelop راه بیندازیم. پس تنها چیزی که ما می‌خواهیم خرید چند نسخه ویندوز است. فرض کنید شرکتی ۱۰ کارمند دارد و ۱۲ تا کامپیوتر. اگر قیمت هر نسخه از ویندوز (یک ویرایش متوسط) را ۱۵۰ هزار تومان فرض کنیم، پول لایسنس‌هایمان یک میلیون و هشت صد هزار تومان می‌شود. اگر این هزینه را با دیگر هزینه‌های شرکت‌داری مثل اجاره دفتر که ممکن است تا چند میلیون تومان در ماه برسد مقایسه کنیم، خواهیم دید که پرداخت این مبلغ آنقدر سخت نیست که بخواهیم به خاطر آن به لینوکس مهاجرت کرده یا از زیر آن در برویم. البته طرح‌های رایگانی مثل BizSpark هم هستند ولی نمی‌شود در ایران از آنها استفاده کرد.

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

فردا پرداز

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

به همین دلیل یک سایت جدید به آدرس FardaPardaz.com (فردا پرداز) ثبت کرده و فعالیت‌های جدیدی را در آنجا شروع کرده‌ام. برای کسب اطلاعات بیشتر راجع به «فردا پرداز» یا به وب‌سایت آن مراجعه کنید یا به وبلاگ آن. آدرس وبلاگ فردا پرداز http://blog.FardaPardaz.com و آدرس فید آن http://blog.fardapardaz.com/syndication.axd است. لطفاً بنده را از نظرات ارزشمندتان محروم نفرمایید.

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

تغییر روش

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

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

آزاد کاری یا Freelancing ممکن است مشکلات و خطرات زیادی داشته باشد ولی در عوض ممکن است بتواند از مشکلات کار شرکتی را حل کرده و بتواند پویایی و انگیزش بالا را با خود به ارمغان بیاورد.

کاهش تمرکز مهارتی و خلاقیت در کار شرکتی

در کنار همه مزایایی که کار شرکتی دارد (در مقابل freelance بودن)، معایبی هم وجود دارد. یکی از این معایب جلوگیری از تمرکز کاری و مهارتی افراد و کاهش خلاقیت است. در شرکت‌ها رایج است که برنامه‌نویس با یک سری توانایی‌ها و علایق خاص استخدام می‌شود ولی بعدها به مرور زمان کارهای دیگری هم از او خواسته می‌شود. مثلاً طرف برنامه‌نویس C#‎ است ولی ممکن است از او CSS یا jQuery هم خواسته شود. یا مثلاً تخصص کسی در دیتابیس است ولی امورات مدیریت و نگهداری سورس کنترل هم از او خواسته می‌شود.

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

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

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

اصرار بی‌فایده بر کیفیت کد

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

۱- کیفیت کد (خوانایی، انجام unit test و…)
۲- بالا بودن امکان نگهداری کد برای افزایش قابلیت تغییر در آینده
۳- documentation صحیح و اصولی برای افزایش فهم کد توسط دیگران
۴- استفاده از ابزارهای Issue Tracking مثل Jira برای افزایش فهم کد توسط دیگران
۵- استفاده از ابزارهای ALM مثل سورس کنترل و Build اتوماتیک برای افزایش همکاری تیمی و افزایش کیفیت کار
۶- …

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

عدم قدرت جذب فنی

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

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

تصور کنید یک چیز خاص مثل Socket Programming، برنامه‌نویسی به زبان Python، استفاده تمام عیار از سری ابزارهای ALM مثل TFS یا git/TeamCity، اسکرام، TDD یا حتی مدیریت اصولی یک تیم استاندارد برنامه‌نویسی را خیلی خوب بلد هستید. فکر می‌کنید چند نفر باشند که به یکی دو تا از موارد بالا به طور کامل نیاز داشته باشند؟ بیشتر شرکت‌های ایرانی فقط به مقدار کم یا متوسطی از هر کدام از این مهارت‌ها نیاز دارند. نتیجتاً هر چقدر هم که شرکت‌تان را عوض کنید باز هم در محیطی قرار خواهید داشت که قدرت جذب فنی کامل شما را نداشته و مدام کارهای معمولی از شما خواهد خواست.

تمرین تغییر مداوم و تست واحد

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

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

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

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

کاهش مشکلات خروج افراد از تیم

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

۱- پیاده‌سازی نرم‌افزار بر اساس نقشه و طرح معین و مکتوب نه آنچه که در ذهن افراد قرار دارد.
۲- به کارگیری اصول روز مهندسی نرم‌افزار و هر چیز دیگری که باعث بالا رفتن خاصیت Maintainability کد می‌شود.
۳- مستند سازی کد
۴- ممیزی کد و کیفیت آن توسط Lead تیم
۵- Code Review افراد تیم از همدیگر که باعث می‌شود هر کسی به غیر از کار خودش از کار دیگران هم خبر داشته باشد
۶- جابجایی عمدی افراد در تیم که اثری مشابه مورد قبل دارد.
۷- استفاده از روش‌های ساده برای حل مسئله. به این ترتیب لازم نیست نفر بعدی در کدهای پیچیده گم شود.
۸- استفاده از ابزارهای Issue Tracking که باعث می‌شود نفرات جدید بدانند چه باگ‌هایی وجود داشته و چطور برطرف شده‌اند.
۹- استفاده از ابزارهای Help Desk برای حفظ ارتباط با مشتری
۱۰- یک دست بودن تیم از لحاظ تکنولوژی‌های مورد استفاده. مثلاً این طور نباشد که یکی از ویژوال استودیو استفاده کند و دیگری از مونو.
۱۱- …

‫‫خلاقیت و طراحی/تولید محصول

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

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