You are currently browsing the category archive for the 'برنامه نویسی' category.
تا به حال این جور عبارتا به گوشتون خورده؟
DVCS
software revision control
Distributed Version Control
Revision control
خوب ممکنه به گوشتون نخورده باشه. اما احتمالا این اسم ها باید به گوشتون آشنا باشه:
Monotone
Git
Bazaar
Subversion
BitKeeper
CVS
خب پس فهمیدید قراره امروز در موردی چی حرف بزنم. برنامه هایی که چار چشمی کدهای شما رو زیر نظر میگیرن و تمام تغییرات رو ثبت میکنن. این کار خوبی های زیادی داره مخصوصا برای کار توی پروژه های بزرگ و از اون مهم تر پروژه های اوپن سورس. یکی از ویژگی هایی که من خیلی در مورد این برنامه ها دوست دارم اینه که اگه یه وقت گند بزنید به کدهاتون خیالتون راحته که میتونید برگردید به چند مرحله قبل تر وگند خودتون رو اصلاح کنید (فهمیدید چرا این ویژگی رو دوست دارم؟) احتمالا اصلی ترین ویژگی ایی که بقیه برنامه نویس ها دوسش دارن راحتیه کار تیمی روی کدهای یه برنامست. خب این یعنی چی؟ این که دیگه پرسیدن نداره. فکر میکنید چجوری 100 نفر روی یه برنامه کار میکنن هیچ وقت هم کدها قرو قاطی نمیشه؟
قبل از اینکه باز شروع کنم به وراجی کردن این بار هم خواهش میکنم یکی یه ترجمه مناسب در مورد “Revision control” یا “Distributed revision control” ارایه بده چون خسته شدم از اینکه وقتی میخوام در مورد این جور برنامه ها صحبت کنم باید اسم خارجکی شون رو به طور کامل تلفظ کنم.
من خودم از Bazaar خوشم میاد و واسه برنامه هام استفاده میکنم. میدونید چرا؟ چون با پایتون نوشته شده, پس من بهتر می فهممش و مثل بقیه برنامه های پایتون ساختار ساده ولی پرقدرتی داره. حالا یه جوری فکر نکنید که الآن من دارم در هفته روی 10-12 تا برنامه کار میکنم و زندگیم داره با برنامه نویسی میچرخه نه بابا از این خبر ها نیست. من خودم کار و زندگی و درس و دانشگاه و کلی کاره دیگه دارم اما گاهی اوقات کسایی که منو میشناسن بهم پیشنهاد میدن منم کارشون رو قبول میکنم. (نه, پروژه دانشگاهی قبول نکردم تاحالا!)
حالا از این حرف ها بگذریم. می خوام به لیست برنامه های بالا اسمی رو اضافه کنم که خیلی ها هنوز باهاش آشنا نیستن. تا چند وقته پیش منم جزو همون خیلی ها بودم. اگه اونقدر خنگید که از عنوان پست نفهمیدید اسم برنامه چیه مجبورم اینجا تکرارش کنم: Mercurial
حالا چرا Mercurial؟ اولین دلیل: بگم اولین دلیل چیه یا خودتون متوجه شدید؟ خب فکر کنم متوجه شدید. آره چون با پایتون نوشته شده. دلیل بعدی: این لعنتی جدا کارش درسته. یعنی حاج آقامون متخصصه بکار گرفته شدن تو پروژه های گندست. و از اون جایی که ذهن یه برنامه نویس پایتون پشتش بوده پس به صورت پایتونیک نوشته شده یعنی ساده, تمیز, پرقدرت و از همه مهمتر جالب و لذت بخشه! این زیر یه سری از پروژه های معروفی که از Mercurial استفاده میکنن رو واستون قرار دادم :
IcedTea
medit
LinuxTV
MoinMoin
Mozilla
NetBeans
Nuxeo
OpenJDK
OpenOffice
OpenSolaris
Pida
Pylons
Python Programming language
rpm.org
SymPy
Symbian Platform
Wget
Xen
حالا اگه برنامه ایی نوشتین که خواستید با بقیه توش شریک بشید باید بهتون مژده بدم که سایت های زیر از Mercurial پشتیبانی میکنن:
SourceForge.net
Savannah
Mozdev
Google Code
BerliOS Developer
…..
خوب میبینم که با دیدن اسم های بالا ترغیب شدید که یه نیگاه بندازید به Mercurial مگه نه؟ Mercurial کلی ویژگی دیگه داره که من جدا حال ندارم همشو توضیح بدم برید خودتون تو سایتش ببینید دیگه.
نکته ی اخلاقی:
یه چند تا اسم بود که فکر کنم فکر شمارو مشغول کرد مثل NetBeans و OpenJDK
ذهن من هم کمی مشغول شد. که حتی سان ماکروسیستم (بابای جاوا) هم داره از Mercurial استفاده میکنه. اتفاقا این یه کار کاملا حرفه ایی از طرف یه شرکت کاملا حرفه ایی هستش. اگه بر نامه ایی واقعا خوب بود, باید بدون تعصب ازش بهره برد. برای خیلی از ماها مهمه که برنامه با جاوا نوشته شده باشه یا با سی شارپ. با دلفی نوشتنش یا با وی بی. با پایتون نوشتنش یا با روبی. از QT استفاده میکنه یا GTK یا هر جور فکر مزخرف دیگه.
پس مهم نیست یه برنامه از چه زبان یا چه ابزاری استفاده میکنه, مهم اینه که با کیفیت و مرغوب باشه. به قول یکی از بچه ها هر چیزی خوبش, خوبه!
خوشم میاد از کسایی که جای شعار دادن می شینن یه گوشه واسه خودشون حرف هاشون رو به عمل تبدیل میکنن بدون اینکه براشون مهم باشه بقیه بابت کارشون بهشون توجه می کنن یا نه. گوگل یکی از همین هاست.
همونطور که همتون میدونید ( یا شاید هم نمی دونید ) یکی از سه زبان اصلی برنامه نویسی مورد استفاده در گوگل, پایتون هستش. دو تای دیگه, یکی ++C هست که قسمت زیادی از کدهاش به عنوان توسعه دهنده های پایتون نوشته شدن و اون یکی که نیاز به گفتن نداره. جاوا.
و باز هم همونطور که همتون میدونید (یا شاید اینبار هم نمیدونید) سایت محبوب یوتیوب با پایتون خالص نوشته شده! البته جو گیر نشید یوتیوب هم از ++C استفاده میکنه ولی بر عکس گوگل, یوتیوب تقریبا 99.99% درصد از کدهای ++C رو برای ساخت توسعه دهنده های پایتون نوشته. و احتمالا این رو هم میدونید که گوگل یوتیوب رو خیلی وقت پیش خریده پس با این توضیحات میشه به صورت تئوری اینطور بیان کرد که گوگل بزرگترین منبع سورس های نوشته شده با پایتون رو در اختیار خودش داره و از طرفی هم خیلی از افراد کلیدی پایتون توی گوگل مشغول به کارن که خوب دلیلش هم کاملا واضحه.
یکی از چیزهای دیگه ایی که باید بدونید اینکه من دو تا پاراگراف بالا رو از یه جام در نیاوردم! یه سرچ تو گوگل بزنید یا مطلب رو تا پایین ادامه بدید و فایل PDF ای که براتون می ذارم رو بخونید تا درستی این گفته ها بهتون ثابت بشه.
به هر حال؛ اینطور که پیداست (یا بهتره بگم پیدا بود) گوگل به عنوان شرکتی که ستون های اصلیش روی پایتون ساخته شده, تصمیم گرفت که سرعت این زبان برنامه نویسی رو با توجه به چیزی که خودش از مفهوم “سرعت” انتظار داره, بالاتر ببره. حداقل 5 برابر بالاتر از سرعت فعلی پایتون!
می دونید پایتون یه زبان تفسیری و دینامیک هستش. تو این مدل از زبان های برنامه نویسی سرعت عمل برنامه نویس خیلی بالاست اما لزوما قرار نیست سرعت برنامه هم به همون اندازه بالا باشه! رو همین حساب گوگل چند تا از برنامه نویس های با تجربه در زمینه ی کامپایلرها و مفسر ها رو به صورت تمام وقت یه جا جمع میکنه تا تحت پروژه ایی به اسم “Unladen Swallow” سرعت این زبان برنامه نویسی محبوب رو بهبود ببخشن.
کاری که بروبکس Unladen Swallow (یکی یه ترجمه ی مناسب ارائه بده خواهشا) انجام دادن این بوده که سورس کدهای اصلی منبع پایتون رو گرفتن (با تشکر فراوان از از آزادی و متن باز بودن این زبان برنامه نویسی) و به صورت جداگونه دارن با بر مبنای LLVM روش دستکاری انجام میدن تا بتونن علاوه بر بهبود در ترجمه و تفسیر بهتر پایتون, یه کامپایلر زمان اجرا (JIT Compiler) براش بسازن و از طرفی هم میزان منابع سخت افزاری مورد نیاز مثل حافظه یا پردازنده رو کاهش بدن.
اینجا فکر کنم لازم باشه توضیح بدم این LLVM چی هست کلا:
LLVM عزیزم یه سازه…. اوخ باز من جوگیر شدم…. برو بچه های یکی از دانشگاه های معروف امریکایی (University of Illinois) از مدت های پیش یک سری استراتژی ها و ابزارهایی روتحت اسم LLVM طراحی کردن که منحصرا برای استفاده در لایه های زیرین یک کامپایلر کاربرد داره و می تونه باعث بهبود در قسمت های مختلف یه کامپایلر بشه. این بهینه سازی بر جنبه های مختلف کار یه کامپایلر مثل عملیات زمان کامپایل, عملیات پیوند دهی!!!!, و عملیات زمان اجرا تاثیر گذاره.
مجموعه ابزارها و کدهای LLVM با ++C نوشته شده و اولش قرار بود برای بهینه سازی کامپایلر ++C/C مجموعه ی GCC استفاده بشه اما از اونجایی که ساختارش مستقل از یه زبان برنامه نویسی خاص طراحی شده, می تونه برای بهبود کار کامپایلر ها و یا مفسرهای بقیه زبان های برنامه نویسی هم استفاده بشه. برای مثال مجتمع سازی LLVM با جاوا در حال توسعه هستش یا برو بچه های Unladen Swallow قراره کاری کنن که پایتون هم بتونه از LLVM استفاده کنه.
پروژه Unladen Swallow قرار نیست کارها رو با عجله و هول هولکی انجام بده و در عوض با تقسیم بندی پروژه در چند فاز مختلف سعی کرده آروم آروم به پیشرفت کار اضافه کنه.
- فاز یک پروژه به پایان رسیده و سرعت پایتون 35-25 در صد افزایش پیدا کرده.
- فاز دوم پروژه به پایان رسیده و کامپایلر زمان اجرا بر پایه LLVM به پایتون اضافه شده و علاوه بر اون تا 25 درصد نسبت به فاز یک بهبود در سرعت حاصل شده !
- فاز سوم هم جدیدا به پایان رسیده. بهبود سرعت نسبت به فاز دوم پروژه از 70-15 درصد دیده میشه و در ضمن میزان استفاده از حافظه نسبت به فاز دوم پروژه 930 در صد کاهش پیدا کرد. (درست خوندید 930 درصد!)
- پروژه هنوز به اتمام نرسیده و باید منتطر کامل شدن فاز های بعدی باشیم. چرا؟ چون:
- سرعت پایتون میتونه از این هم زیادتر بشه. تیم متوجه شده که کار سخت تر از اونیه که فکر میکردن. در واقع سختی بیشتر کار بابت اینه که تیم نمی خواد خیلی زیاد هسته ی پایتون رو دستکاری کنه. به خاطر همین ممکنه سرعت به حدی که انتظار میرفت نرسه.
- میزان استفاده از منابع سخت افزاری هم باید کاهش بیشتری پیدا کنه چون در حال حاظر این ویرایش پایتون از 2 تا 3 برابر نسبت به ویرایش معمولی CPython بیشتر حافظه مصرف میکنه.
- در ضمن باید این کدها به پلتفرم های مختلف پورت بشن چون در حال حاظر فکر میکنم بیشتر با سیستم های یونیکس و لینوکس و بقیه رفقاشون سازگاره.
- با تغییرات انجام شده عملیات debug کردن برنامه ها مشکل پیدا کرده و باید فکری براش بشه.
- از همین الآن تعدادی از برنامه نویس های برتر مفسر پایتون خالفت خودشون رو با ترکیب شدن کدهای این پروژه با کدهای اصلی CPython اعلام کردن.
به روزرسانی: چند خط از این نوشته (مواردی که با دایره های سیاه رنگ نوشته شدن) در تاریخ 13 آبان 88 اضافه شده ان.
خوبیه این پروژه اینکه قراره با کدهای معمولی پایتون کاملا سازگار باشه و توسعه دهنده هایی که تا امروز برای پایتون نوشته شدن بدون هیچ تغییری به راحتی اجرا بشن. در آخر هم هدف اصلی پروژه اینکه نمه نمه تغیرات صورت گرفته رو به سورس اصلی پایتون (CPython) اضافه کنه.
این فایل PDF رو هم دانلود کنید بد نیست. فایل یکی از کنفرانس های معرفی پروژه ی Unladen Swallow هستش. البته یکم قدیمی شده چون پروژه خیلی سریع داره پیشرفت میکنه. من نظرم اینه که اگه به سایت پروژه برید و اطلاعات اونجا رو بخونید بهتر کمکتون میکنه.
دومیش رو هم نوشتم که میتونید از اینجا ببینیدش.
توی این قسمت با یه مثال عملی آشنا میشید.
اولین مقاله از سری مقاله های “ساخت GUI با WebKit” رو نوشتم. میتونید برید و از این لینک بخونیدش.
هنوز کد نویسی ها شروع نشده اما تو قسمت اول مقاله در مورد روش کار توضیحاتی دادم.
وقتی مقاله رو نوشتم گفتم بهتره بذارمش جایی که باید باشه. می تونید از لینک زیر مقاله رو
بخونید:
http://www.pylearn.com/fa/forum/index.php?topic=962
مقاله هایی رو هم قرار بود در مورد Webkit و استفاده از اون تو پایتون بنویسم رو سعی میکنم هر چه زودتر آماده کنم. این فری/گیت هم باز دوباره داره اذیت میکنه. من بدون اون نمی تونم تو وردپرس لاگین کنم. نمی دونم بقیه هم این مشکل رو دارن یا نه؟
تو این یه مدت به شدت زدم تو خط WebKit که ازش سر در بیارم. برای اون هایی که نمی دونن WebKit چیه لازمه که توضیح بدم ایشون یه موتور رندرینگ صفحات وب هستن که میشه بر پایه اون حتی اقدام به ساخت یه مرورگر کرد. کاری که Google Chrome و Apple Safari و خیلی های دیگه انجامش دادن.
اما یه موتور رندرینگ صفحات وب چجوری میتونه برای یه برنامه نویس پایتون مفید باشه؟
برای پیدا کردن این جواب من 12 روز کامل رو با WebKit گذروندم و بعد این 12 روز تقریبا دید ذهنی من نسبت به برنامه نویسی دسکتاپ به طور کامل عوض شد!
من برنامه نویسی وب رو بیشتر از دسکتاپ دوست دارم چون از نظر من جالب تره. سر و کله زدن با کدهای جاوا اسکریپت و تگ های HTML و بازی با CSS برام لذت بخشه. نوع مدلی که یه برنامه ی وب با کاربراش ارتباط برقرار میکنه هم برام جالبه. درسته که در محیط دسکتاپ حیطه ی اختیارات برنامه نویس بالاتره و میشه برنامه های متنوع تری خلق کرد اما حداقل برای من به اندازه ی برنامه نویسی وب لذت بخش نیست. ماهیگیری کاریه که خیلی دنگ و فنگ داره اما واسه ی همین دنگ و فنگ هاشه که آدم میره ماهیگیری چون از تک تک لحظاتش لذت میبره, وگرنه خیلی راحت تره که آدم بخواد بره بازار و یه ماهی سفید گنده بخره.
اما برسیم به اینکه توی این 12 روز چی گذشت. برای انگولک کردن WebKit با پایتون گزینه های جالبی پیش روم بود که دو تا شون بیشتر نظر من رو جلب کرد.
پایتون برای کار با تولکیت GTK از رابط PyGTK استفاده میکنه. این بسته ی نرم افزاری باعث میشه که بتونید از طریق GTK و PyGTK از WebKit استفاده کنید. بهر حال WebKit برای رندر کردن صفحات نیاز به رابط گرافیکی داره که به صورت پیش فرض در خود WebKit موجود نیست اما با امکاناتی که در اختیار توسعه دهنده ها میزاره این امکان رو میده که برنامه نویس ها بتونن به راحتی با استفاده از تولکیت هایی مثل GTK این کار رو انجام بدن. در این حالت وقتی شما از تگ <button> تو html استفاده میکنید WebKit برای به تصویر درآوردن یک دکمه در صفحه ی وب از تولکیت GTK کمک میگیره.
اینم رابط برنامه نویسی پایتون واسه تولکیت QT هستش که تو نسخه های جدیدش WebKit رو جزو API های پیش فرض خودش قرار داده. من خودم فقط با GTK کد زده بودم و تاحالا با QT کار نکرده بودم ولی در این مورد خاص تصمیم گرفتم از QT استفاده کنم! خواهشا نگید چرا, چون علاوه بر اینکه هیچ دلیل خاصی واسه برتری QT به GTK وجود نداره, به همون اندازه هم هیچ دلیلی برای استفاده از جفتشون وجود نداشت! من قرار نبود با QT یا GTK خیلی کار داشته باشم و این وسط مساله ی مهم WebKit بود.
تصاویر این پایین رو ببینید:
واستون جالب نیست اگه بگم تمام چیزی که دارید میبینید یه صفحه ی HTML هست؟ این همون دلیله که من گفتم اصلا فرقی نمیکرد که از GTK استفاده کنم یا QT. وقتی میتونم GUI هایی با کمک HTML و جاوا اسکریپت بسازم چرا باید به خودم زحمت بدم و از این تولکیت ها استفاده کنم. درسته که به وقتش ازشون استفاده خواهم کرد ولی مسلما در زمینه طراحی GUI برنامه هام نخواهد بود!
WebKit به من این امکان رو میده بتونم همون طوری که واسه وب کد میزدم برای دسکتاپ هم کد بزنم. تازه از اونجایی که من دارم با یه مرورگر تمام عیار برنامه هام رو میسازم ارتباط با سرویس ها و یا برنامه های دیگه ی اینترنتی کار زیاد سختی نیست.
ممکنه واستون یه سری سوال پیش اومده باشه. سوال هایی که واسه منم پیش اومد و تو این 12 روز تمام وقتم رو گرفتن (این قضیه که من تاحالا با QT کار نکرده بودم رو هم حساب کنید):
1. اگه این یه صفحه ی HTML هست چجوری کاری کردی که مثل یه برنامه ی معمولی دسکتاپ خودشو نشون بده؟ مثلا چرا پشت صفحه سفید رنگ نیست؟
2. دیالوگ های مختلف رو چجوری می خوای تو برنامت نشون بدی. WebKit که فقط یه موتور رندرینگه و نمی تونه مثله FireFox اگه با جاوا اسکریپت زدی window.open چیزی رو بهت نشون بده؟
3. اگه برنامت جای 1 دونه فرم 20 تا فرم داشت چی؟
4. چجوری می خوای بعد از شروع کار برنامه, GUI ایی که ساختی رو با توجه به وضعیت فعلی برنامه تغییر بدی؟
5. چجوری وقتی روی یه دکمه کلیک شد کدی رو اجرا کنی؟ اون هم کد پایتون, نه کد جاوا اسکریپت؟
6. چجوری جاوا اسکریپت قراره با کدهای پایتون که تو پشت صحنه هستن حرف بزنه؟
7. یا برعکس چجوری پایتون باید با جاوا اسکریپ ارتباط برقرار کنه؟
8. اگه بخوای از ابزار های جاوا اسکریپت مثل jQuery استفاده کنی باید چیکار کنی؟
…… و تعدادی سوال دیگه که ممکنه واستون پیش بیاد. بهر حال شما دارید واسه ی دسکتاپ برنامه می نویسید نه وب, پس خیلی چیزا ممکنه فرق کنه یا حداقل به طریق دیگه ایی انجام بشه. اگه حوصله کنم سعی میکنم یه سری مقاله در این زمینه بنویسم که در مورد چم و خم این مدل برنامه نویسی توش حرف بزنم. مسلما اگه چیزی بنویسم هم در زمینه ی پایتون خواهد بود ولی تا وقتی که دارم از QT استفاده میکنم, هر زبان برنامه نویسی دیگه ایی که بتونه با QT ارتباط برقرار کنه میتونه کاری مشابه رو انجام بده.
خلاصه آقاجون تو این 12 روز فهمیدم که این WebKit مثل هلو میمونه آدم دوست داره قورتش بده این ناقلا رو!
خب بالاخره روزی که خیلی ها منتظر بودن رسید و نوکیا نسخه ی 4.5 کیوت رو حدودا دو روزه پیش منتشر کرد.
به دنبال اون برنامه ی Qt Creator به عنوان IDE مخصوص برنامه نویسی ++C و کیوت که قبلا در نسخه آزمایشی به سر می برد ( و همچنین فقط با مجوز GPL در دسترس بود) به نسخه ی پایدار تبدیل شد ( و تحت مجوز LGPL) برای دانلود آماده شد. این یعنی اینکه اگه مردم یکم بهتر تصمیم گیری کنن, دیگه چیزایی مثل ویژوال استودیو رو باید به تاریخ بسپرن چون با وجود یک محیط ویژوال کاملا حرفه ایی و آزاد, اون هم برای یکی از پر امکانات ترین فریم ورک های GUI حال حاظر, کار کردن با ویژوال استودیو واقعا مسخرست. بیاین با خودمون صادق باشیم, 90% افرادی که زبان های ماکروسافتی رو انتخاب میکنن فقط به خاطر راحتی کار با ویژوال استودیو هستش و 60% از همین 90% حتی نمی تونن بدون ویژوال استودیو یه برنامه ی ساده رو هم بنویسن.
اما فقط Qt Creator نیست… جدیدا سرعت توسعه IDE معروف محیط KDE یعنی kdevelop هم به شدت بالا رفته و می تونید از همین الان اطمینان داشته باشید که تا چند مدت دیگه صحبت اصلی مردم تو انجمن های اوپن سورس اینه که بین kdevelop و Qt Creator کدوم یکی رو باید انتخاب کنن.
از طرفی بسته ی SDK این پلتفرم که برای برنامه نویس های مشتاق به توسعه و بهبود کیوت آماده شده هم در دسترس قرار گرفت.
از این به بعد تمام برنامه های مبتنی بر کیوت و مخصوصا تمام قسمت های kde می تونه تحت مجوز LGPL منتشر بشه (البته نه کاملا همه ی قسمت ها!). میشه گفت جنگ بین GTK و QT ( و متعاقب اون جنگ بین GNOME و KDE ) تازه از الآن شروع شده چون تا قبل از این هیچکسی جز برنامه نویس های QT نمی تونستن کدها رو توسعه بدن اما از الآن به بعد همه می تونن در توسعه ی اون شریک باشند. شما هم از همین الآن آماده ی نوشته شدن برنامه ی زیادی بر پایه کیوت و همچنین تجدید نظر تعداد زیادی از توسعه دهنده ها در مورد مجوز برنامشون که بر پایه کیوت نوشته شده بود باشید!
