اختاپوس خسته

یادداشت‌هایی پیرامون کد، زندگی و دوستان

توسعهٔ چندسکویی

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

توی این پست، تجربهٔ شخصی خودم رو در مورد توسعهٔ چندسکویی پروژهٔ AIT می‌نویسم. توی اون پروژه به مشکلات زیادی برخوردم و تعدادی‌شون رو حل کردم. این نوشته یک چک‌لیست ساده برای کسایی که می‌خوان توسعهٔ چندسکویی انجام بدن فراهم می‌کنه که بتونن از مشکلات توسعهٔ چندسکویی با زبان‌های ‏‪C/C++‬ پیشگیری کنن. رفتیم که بریم :)

زیکانف‌نامه

خوب دو هفته‌ای از برگزاری همایش سراسری نرم‌افزارهای آزاد/متن‌باز (زیکانف) می‌گذره و من هنوز هیچ پستی در مورد این که چقدر خوش گذشت و چه کارهایی کردیم، ننوشتم.

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

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

چرا طراحی وب را دوست ندارم

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

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

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

به‌طور خاص اگر بخوام غر بزنم، باید بگم که وب خوب نیست، چون بیماره. بیماری‌ش طراحی بسیار بد پروتکل‌ها و ابزارها هستند. که البته زمان خودشون (برای نیازهای خودشون خوب بودن بیچاره‌ها) مثلاً همین HTML رو در نظر بگیرید. این پروتکل به‌شدت Stateless هست. و صرفاً برای این که داینامیک‌ش کنن، اومدن کلی ژانگلولربازی درآوردن از جمله پیدایش چیزی به‌نام Flash و بدتر از اون چیزهای پیچیده‌تر و احمقانه‌تری مثل Silverlight و یا حتا JavaScript و رفقا.

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

از بین این همه زبان و پروتکل و چیزهای عجیب‌غریب، تصمیم گرفتم با Ruby on Rails شروع کنم و یه چیز کوچولو درست کنم. تا ببینیم بعدها چه شود…

توسعهٔ وب از دید یک گیگتوپوس

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

۱. هیچ خبری از گیت نیست. مدیریت نسخه‌ها و پیشرفت پروژه دستی انجام میشه.
۲. برای ارسال و دریافت فایل‌ها روی سرور از cpanel یا اینترفیس‌های تحت وب دیگه‌ای استفاده میشه. (اگر طراح خیلی حرفه‌ای باشه از FileZilla یا چیزهای مشابه :D )
۳. برای مدیریت پایگاه داده (که معمولاً MySQL هست) از رابط‌های پرهزینه مثل phpMyAdmin استفاده میشه.
۴. کارایی و سرعت مدنظر گرفته نمیشن. (چون به نظر ایشون قابل چشم‌پوشی هستند.)

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

ایدهٔ کلی من برای توسعهٔ وب مشابه کاری هست که با گیت برای پروژه‌های واقعی انجام میدم:

۱. توسعه بده.
۲. تغییرات رو (دقت کنید! فقط تغییرات رو) بفرست روی سرور.

بعد از یک روز کاری تونستم تمام روال‌های مربوطه رو اتوماتیک کنم و براش یه برنامه نوشتم. این پست در مورد این برنامه و نحوهٔ استفاده از اون هست.

چطور پازل ۳۱ زومیت را حل کردم

اولین روز سال ۱۳۹۳ و اولین پست همین سال :) برای شروع سال چه چیزی بهتر از یه پازل فکری می‌تونه باشه؟ امروز جمعه‌ست و اول سال با آخر هفته شروع شده. آخرهفته‌ها فرصت مناسبی برای پروژه‌های کوچیک و جالب هست. خوب زومیت زحمت کشیده و پازل شمارهٔ ۳۱ام رو روز اول فروردین منتشر کرده. توی این پست می‌خوام توضیح بدم که چطوری این پازل رو حل کردم. در واقع تقلب کردم. چون اولش یک برنامه‌ای نوشتم که پازل رو حل کنه :P بعد رابطه‌ای برای تولید جواب‌ها پیدا کردم که خیلی سخت‌تر از روش اول جواب می‌داد. منتها خوبیش اینه که اجازه میده تعداد جواب‌های موجود رو محاسبه کنیم. تعداد کل جواب‌ها ۳۸ تا خواهد بود منتها با روش ریاضیاتی محاسبهٔ این جواب‌ها تقریباً غیر ممکن‌ه ولی با brute force امیدواری بیشتر میشه!

جایزهٔ این پازل یک عدد هارد دیسک بسیار عالی هست که امیدوارم توی قرعه‌کشی قبول بشم.

یادداشت: شما قبل از پنجشنبه ساعت ۱۲ ظهر (آخرین مهلت ارسال جواب‌ها) نمی‌تونید این پست رو بخونید! ولی دارم اینو اول فروردین می‌نویسم.

نصب آسان نرم‌افزار از طریق Qt Creator

روند کلی توسعهٔ نرم‌افزار با استفاده از ساختارهای کیوت خیلی سرراست و ساده هست. با این وجود ممکنه گاهی اوقات بعضی کارهای تکراری کسل‌کننده به‌نظر برسه. همگی می‌دونیم که کسل‌کنندگی بزرگترین دشمن گیک‌ها (و البته گیگتوپوس‌ها) هست. خوشبختانه توسعه‌دهنده‌های کیوت‌کریتور همگی گیک هستند و راه‌حل‌های مؤثری برای این کارها درنظر گرفته شده.

اگر بخوایم یه کتابخانهٔ جدید رو با استفاده از کیوت بنویسیم، مسلماً بعد از یه مدتی دلمون می‌خواد که تست‌ش کنیم. خوب بهترین راه تست کردن یه کتابخونه اینه که اونو روی سیستم نصب کنیم و سوئیت تست رو اجرا کنیم. (البته اگر سوئیت تست براش نوشته باشیم!) روال کلی نصب به این شکله که شما اول دستور make رو اجرا می‌کنید، اگر برنامه درست کامپایل شد و همه‌چیز به‌خوبی پیش رفت، دستور sudo make install رو وارد می‌کنید. با این دستور کتابخونهٔ شما در مسیرهای پیش‌فرض (که qmake به make گفته و make از سیستم یاد گرفته) نصب میشه.

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

چرا سی‌شارپ بد است؟

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

نتیجه‌ای که گرفتم این بود که مایکروسافت از سال ۲۰۱۱ به این‌طرف تغییر اساسی‌ای توی محصولاتش منتشر نکرده. البته اگر از برنامه‌نویس‌های دات‌نتی بپرسید دقیقاً خلاف این موضوع رو به شما میگن :) در ادامه بیشتر توضیح میدم. اما اول می‌خوام دلایل عدم استفاده از محصولات کمپانی‌هایی مثل مایکروسافت رو توضیح بدم. این کار رو با یک مثال شروع می‌کنم. مثالی که به شکل تحلیلی و براساس تخصص اصلی‌م (برنامه‌نویسی) نوشته شده. دلایل این که زبان سی‌شارپ زبان بدی هست رو می‌خوام توضیح بدم.

سردرگمی

امروز ۲۹ آذرماه ۱۳۹۲ هست و من همچنان درسم تموم نشده. بعد از این که فرصت کار توی گوگل رو از دست دادم، دیگه اهمیت چندانی نداره که کی و چطوری ته‌موندهٔ واحدها رو تموم کنم. تیرماه سال آینده به‌طور کامل خلاص میشم.

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

۱. درس خوندن برای کنکور ارشد (فوق لیسانس داخل کشور)

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

۲. درس خوندن برای دانشگاه بوخوم آلمان (رزرو پوزیشن RA برای سال ۲۰۱۶)

طی مکاتباتی که با دانشگاه انجام دادم، گفتن برای ۲۰۱۴ و ۲۰۱۵ رزرو ندارن اما برای ۲۰۱۶ هست. ۲۰۱۶ هم خیلی دیره :( دو سال رو بمونم کار کنم یا چی نمی‌دونم…

۳. کار کردن توی دانشگاه

پیشنهادی که مطرح شده و رزومه هم دادم. ظاهراً قراردادی خواهد بود. در مورد مبلغ و ساعات کار و ماهیت کار پیشنهاد شده اطلاع دقیق ندارم.

۴. کار کردن تو شرکت خودم

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

پروژهٔ AIT

پروژهٔ AIT بزرگ‌ترین کار متن‌بازی هست که پیاده‌سازی کردم. AIT مخفف Artificial Intelligence Toolkit هست. هدف این کتابخانه فراهم کردن یک پلتفرم توسعه برای پروژه‌های تحقیقاتی و صنعتی در زمینهٔ هوش مصنوعی هست. حقیقتش اهداف بزرگ‌تری هم داره. مثلاً پر کردن خلأ بین آکادمی و صنعت در زمینهٔ هوش مصنوعی یکی از کارهایی هست که مدت‌هاست آرزو دارم انجامش بدم. توی پست دیگه در مورد این خلأ صحبت خواهم کرد.

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

بیت‌کوین فارسی

حدود دو ماهه که دارم در مورد bitcoin تحقیق می‌کنم. به‌نظر من یکی از ایده‌هایی هست که دنیا رو متحول خواهد کرد. به هم زدن نظم اقتصادی دنیا با یک سیستم پولی کاملاً غیرمتمرکز چیزی‌یه که به زودی تبدیل به کابوس دولت‌ها خواهد شد.

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

خوب منم که نمی‌تونستم دست روی دست بذارم و تماشا کنم که این پروژهٔ عالی این‌شکلی خراب بشه :) خودم دست به‌کار شدم و کلاینت بیت‌کوین رو به فارسیِ روان ترجمه کردم. در ادامه می‌تونید توضیح کوتاهی در مورد روند کار و نتیجهٔ نهایی رو بخونید.