وضعیت باطری

تقریبا ۲ ماهی میشه که یه لپ‌تاپ جدید خریدم، اولین کاری که انجام دادم نصب جنتو بود و بعدش هم نصب یک Tiling window manager، بین گزینه‌های موجود من awesome رو انتخاب کردم.
اون موقع هنوز awesome 3 منتشر نشده بود و من با بتاهاش کار می‌کردم. یکی از چیزهایی که من خیلی در مورد awesome 3 دوست دارم اینه که کلا فایلهای پیکربندیش رو با Lua باید نوشت، و همچنین یک API خیلی خوب و قدرتمند هم براتون فراهمه تا هرکاری که فکرشو بکنید بتونید با awesome انجام بدید.
چندین library دیگه هم همراه با awesome میان که کار با awesome رو خیلی راحت‌تر می‌کنن، یکی از اونا wicked هست، معمولا از wicked برای ساختن widget ها استفاده میشه و خودش هم یک سری widget برای نشون دادن وضعیت CPU, RAM و شبکه در اختیار میذاره، اما یه‌چیزه لازم برای هر لپ‌تاپ که توی wicked نبود widget ایی از نوع باطری بود. اما خوب با استفاده از wicked خیلی راحت میشه خروجی یه برنامه دیگه رو توی widget ها نشون داد و با استفاده از Pango markups به شکل دلخواه درش آورد ... و چی راحت‌تر از نوشتن یه bash script؟ :-)
این یه bash script خیلی سادست برای اینکه وضعیت باطری رو برگردونه، وقتی که AC Adaptor وصله یه‌دونه + به اول درصد باقیمانده از ظرفیت کل اضافه می‌شه، و اگر که وصل نباشه، یه - اضافه میشه، و من خیلی ساده در قسمتی که با Lua می‌نویسم، بهش میگم اگر مثبت بود،‌ وضعیت سبز، اگر منفی بود وضعیت زرد و اگر که زیر ۱۰ درصد بود، وضعیت قرمزه!

TraceMonkey، یک اتفاق میمون

اخیرا بنیاد موزیلا خبر از پیشرفتی قابل توجه در نسخه بعدی مرورگر فایرفاکس (نسخه ۳.۱) داده.

این امکان جدید در حقیقت پیشرفتی برای Gecko (موتور طرح‌بندی توسعه یافته توسط موزیلا) محسوب می‌شود، و اگر بخواهیم دقیقتر صحبت کنیم، پیشرفتی برای SpiderMonkey (موتور جاوا‌اسکریپت به کار گرفته شده در Gecko). بنیاد موزیلا دو پیاده سازی مختلف از JavaScript دارد، یکی SpiderMonkey هست که با زبان برنامه نویسی C نوشته شده و در Gecko مورد استفاده قرار گرفته، و دیگری Rhino می‌باشد که با Java نوشته شده است.
موزیلا نام این تحول جدید SpiderMonkey را TraceMonkey گذاشته. در واقع TraceMonkey یک JIT Compiler برای SpiderMonkey هست که باعث افزایش سرعت اجرای جاوااسکریپت می‌شود، و این بدین معنی می‌باشد که کارهایی که به شدت از منابع سیستمی استفاده می‌کردند و برای اجرا نیاز به Plugin های اختصاصی داشتند، از این به بعد می‌توانند به قدرت و سرعت اجرای JavaScript اتکا کنند.

در واقع TraceMonkey اولین اقدام برای افزایش کارایی یک موتور JavaScript محسوب نمی‌شود. کمی پیشتر Apple خبر از موتور JavaScript جدید به کار رفته در WebKit (موتور طرح بندی استفاده شده در Safari) با نام SquirrelFish داد (SquirrelFish در واقع یک مفسر bytecode محسوب می‌شود تا یک JIT Compiler)، و یا Tamarin که موتور JavaScript استفاده شده در نسخه ۹ فلش می‌باشد.

کاری که یک JIT Compiler انجام می‌دهد‌ در واقع تبدیل کردن «کد زمان اجرا» است پیش از آنکه آنرا به صورت native اجرا کند. مثلا تبدیل bytecode به کد native ماشین. تفاوت TraceMonkey با SquirrelFish در واقع در همین مرحله است، SquirrelFish (هنوز) bytecode ماشین مجازی خود رو به کد native تبدیل نمی‌کند، در حالی که این اتفاق در مورد TraceMonkey رخ می‌دهد، و همین باعث افزایش کارایی TraceMonkey در مقابل SquirrelFish هست.

همچنین، قبل از اینکه Mike نتایج کار Brendan و Andreas رو وارد repositry اصلی Mozilla کنه، Gecko شاهد تغییرات جدیدی برای افزایش اجرای جاوااسکریپت بوده، مواردی مثل اضافه کردن Cache برای صفات چندریختی که باعث پیدا کردن سریعتر خصوصیات می‌شود و دیگر نیازی نیست کل اشیا یک زنجیره از prototype تا آخر برای پیدا کردن یک صفت بررسی شوند.

Cloud Computing و متن‌باز

با گسترش مفاهیمی چون نرم‌افزار به عنوان سرویس یا Software as a Service یا SaaS مفهوم جدیدی مثل Cloud Computing بیشتر و بیشتر رایج می‌شود.
به طور کل Cloud Computing یعنی محاسباتی که با استفاده از کامپیوتر انجام می‌شود (Computing) بر پایه اینترنت (Cloud). به بیان ساده‌تر Cloud Computing یعنی در اختیار قراردادن قدرت محاسبات رایانه‌ایی در هرجایی که دسترسی به اینترنت وجود دارد.
شرکتهای ارائه دهنده خدمات Cloud Computing معمولا شما را بر اساس میزان استفاده‌ایی که از منابع سیستمی کرده‌اید شارژ خواهند کرد، چیزی مثل یک قبض برق. بدین‌ترتیب تقریبا تمامی نگرانیهای Scale up و حتی Scale Down هم رفع می‌شوند، دیگر نیازی نیست که برای در دسترس بودن برنامه تحت‌وب خود در اوقات اوج ترافیک، سخت افزارهایی را خریداری کنید که درمواقع ترافیک پائین بیکار باشند، و یا چون بودجه کافی ندارید، با نذر و دعا برنامه خود را در ساعات اوج ترافیک سرپا نگه دارید.
شرکتهای بزرگی مثل Google و Amazon خیلی پیشتر از آنکه این نیاز واقعا توسط شرکتهای کوچکتر احساس شود معماری خود را بر چنین پایه و اساسی بنا نهادند. وحالا که این نیاز واقعا توسط شرکتهای کوچکتر و بازهم کوچکتر احساس می‌شود، امکان دسترسی عموم را به چنین سرویسهایی فراهم آورده‌اند. هرچند که تکنولوژیهای متن‌بازی نیز وجود دارد که به شرکتهای متوسط این اجازه را می‌دهد که برپایه سخت‌افزارهای موجود خود، در دسترس بودن Computing را جهت رفع نیازهای خود بهبود بخشند.
با توجه به آنچه که گفته شد، ۳ روش متفاوت برای بهره‌مند شدن از امکانات Cloud Computing وجود دارد:

• استفاده و مدیریت کامل محیط Computing که به صورت مجازی (در Cloud) در اختیار شما قرار داده شده
• توسعه و ارائه برنامه‌ها بر روی محیطی که هیچ‌گونه کنترلی روی آن ندارید
• ساخت یک Cloud از پایه

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

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

و در نهایت روش آخر که پیچیده‌ترین و هزینه‌برترین گزینه می‌باشد. در این شیوه بعد از فراهم کردن تمامی امکانات سخت‌افزاری مورد نیاز،‌شما نیاز به یک نرم‌افزار مدیریت کننده دارید. نرم‌افزارهای متن‌باز متعددی جوابگوی این نیاز هستند که بهترین آنها در حال حاضر Hadoop به نظر می‌رسد. Eucalyptus و 10gen گزینه‌های مطرح بعدی هستند.

واقعیتهای ccache

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

قبل از هرچیز فکر می‌کنم توضیح نحوه عملکرد ccache ما را در درک بهتر شرایط یاری خواهد داد.
ccache در واقع یک MD5 hash از محتوی قبل از پردازش فایل درست می‌کند، سپس cache tree را بررسی می‌کند، و اگر مورد مشابهی پیدا نکرد آن فایل را کامپایل می‌کند و محتوی آنرا دوبار (یک‌بار موقع build کردن و یک‌بار هم در فایل cache) می‌نویسد.
آز آنچه که تا اینجا درباره نحوه عملکرد ccache گفته شد، اینچنین برمی‌آید که چنانچه شما همواره فایلهای غیریکسان را کامپایل می‌کنید، ccache نه تنها به شما کمکی نمی‌کند بلکه در واقع بار اضافی برروی سیستم می‌گذارد.

پس فایده ccache چیست؟ اگر که شما یک source را بیش از یکبار کامپایل کنید، مدت زمانی را که ccache احتیاج دارد تا MD5 hash را ساخته و cache tree را برای یافتن موردی مشابه پیدا کند کمتر از زمان یک build می‌باشد.

پس ccache عموما نه در زمانی که CFLAGS را عوض کنید، نه در زمانی که USE flags را عوض کنید و نه در زمانی که نسخه جدیدتری از source را کامپایل می‌کنید کمک چندانی نخواهد کرد.

ccache معجزه نمی‌کند!

Comet

Comet درباره اتصالات HTTP با عمر طولانی نیست، بلکه درباره اتصالات HTTP ایی است که برای طولانی مدت نگه‌داشته می‌شوند.

وب، شرکتها و برندها

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

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

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

• بزرگ شدن و حریص شدن دپارتمان IT شرکتها به پول و منابع انسانی
• سر برآوردن تعداد بسیار زیادی سرویس اینچنینی که همگی نیاز به ترغیب کاربر به ثبت‌نام و مشارکت نیز دارند (بله،‌ درست است که تمامی این کارها برای خود کاربر و در راستای ارضای نیاز به مشارکت وی صورت پذیرفته، اما اگر کاربر مجبور باشد برای تنها تائید یک محصول کوچک روند ثبت‌نام و ورود به سرویس را برای تک‌تک وب‌سایتها انجام دهد، آیا همچنان مشتاق باقی خواهد ماند؟)

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

بله! حالا مطمئن هستم که آن تغییرچیست، تغییری که همین حالا در حال رخ دادن است.

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