وبلاگ شخصی علی فرهادی

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

اولین ابزارهایی که در این زمینه تولید شدند الگوریتم های ساده ای داشتند که با استفاده از Reqular Expression ها کار می‌کردند و به همین دلیل مشکلاتی هم داشتند. برای مثال JSMin و Dean Packer از چلاننده(Minifier) های معروفی هستند که به همین روش کار می‌کنند. مثلا JSMin نمی‌تواند همه‌ی کاراکترهای خط جدید (line feed) را حذف کند چون ممکن است باعث بوجود آمدن باگ در برنامه شود. Dean Packer هم برای اینکه درست کار کند باید تمام دستورات اسکریپت به «;» ختم شده باشند.

این شد که توسعه دهنده ها به فکر تولید چلاننده‌هایی افتادند که بتواند مثل یک موتور اسکریپت (JavaScript Engine) اسکریپت را تفسیر نموده و به بهینه ترین نحو بچلاند. اولین چلاننده از این نسل Dojo ShrinkSafe بود که بر پایه موتور اسکریپت Rhino نوشته شده است. کمی بعد یاهو هم چلاننده ای تولید کرد با نام YUI Compressor که نسبت به سایر چلاننده‌‌های موجود از کارایی بهتری برخوردار بود و این برتری را تا مدتها حفظ کرد و هم اکنون که بیش از دو سال از انتشار نسخه‌ی اول آن می‌گذرد اکثر پروژه ها و فریم ورک های جاوااسکرپیت از این چلاننده برای چلاندن اسکریپت‌هایشان استفاده می‌کنند.

حدود یکی دو ماه پیش گوگل هم پا به عرصه رقابت گذاشت و چلاننده‌ی خودش را با نام Closure Compiler عرضه کرد. این چلاننده از تکنیک های جدیدی استفاده میکند که باعث شده نرخ فشرده سازی آن حدود 10 تا 20 درصد از YUI بیشتر باشد. از نکات قابل توجه در این چلاننده این است که قابلیت شناسایی و حذف کدهای بلااستفاده(dead code) را از درون اسکریپت دارد.

چلاننده‌ی گوگل مشابه YUI یک برنامه Java است که از خط دستور اجرا میشود ولی علاوه بر این گوگل این برنامه را به صورت اپلیکشن تحت وب و API هم ارائه کرده است.

برای مقایسه‌ی تکنیک های بکار رفته در YUI Compressor و Closure Compiler دیدن این slideshow رو توصیه می‌کنم.

امروز بعد از مدتها یادم اومدم وبلاگ هم دارم. گفتم یه چیزی بنویسم تا اینجا از این وضع در بیاد.

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

این روزها سیستم‌های توزیع شده‌ی کنترل سورس (Distributed Version Control) کم کم دارن جای سیستم‌های کنترل سورس سنتی متمرکز (Centralized) مثل svn رو می‌گیرن. از جمله git یکی از این سیستم‌های کنترل سورس توزیع شده است که محبوبیت زیادی پیدا کرده.
قسمت عمده‌ای از تفاوت‌های git و svn برمی‌گرده به تفاوت مدل توزیع شده و مدل متمرکز، برای همین ابتدا این دو مدل رو توضیح میدم.
(دنباله…)

اگر یادتون باشه حدود 2 یا 3 سال پیش سایت brainbench.com آزمون php رو رایگان کرده بود. امروز دوباره رفتم ببینم هنوز هم رایگانه یا نه.

آزمون php رایگان نبود. توی لیست آزمون های رایگانش گشتم ببینم چیزی داره که به درد ما بخوره. آزمون «مفاهیم توسعه‌ی وب» (Web Development Concepts) رو پیدا کردم. 40 تا سوال داشت با 3 دقیقه وقت برای هر سوال. واقعا سوال ها خوب طراحی شده بودند. اگر شما هم توی همین زمینه کار می‌کنید توانایی‌هاتون رو یک محک بزنید. برای رزومه هم خوبه. یک کاربرد خوب این آزمون برای کارفرماها اینه که میتونن برای استخدام نیرو از این آزمون استفاده کنند.

این هم نتیجه‌ی آزمون من:

راستی سال نو هم پیشاپیش تبریک، شاید تا سال دیگه فرصت نوشتن پیدا نکردم.

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

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

در ادامه این مقاله که در واقع برگرفته از کتاب «High Performance Web Sites» هست می پردازیم به اهمیت و راهکارهای بهینه سازی سمت کاربر.
لازم به ذکر است که این کتاب نوشته‌ی Steve Souders مسئول performance در یاهو می باشد.

(دنباله…)

چند روز پیش به یک مشکل عجیب توی php برخوردم. یک کدی بود که وقتی اجراش میکردم پنجره دانلود می اومد. بررسی که کردم دیدم هیچ هدر و خروجی ارسال نمیشه و از اونجایی که هدر نداره پنجره دانلود میاد. ظاهرا یک جایی وسط کار php کرش میکنه. خلاصه trace کردم تا رسیدم به اون قسمتی که مشکل رو ایجاد کرده بود. اونقدر سر و ته کد ها رو زدم تا به خط مورد نظر رسیدم. و حدس زدم که باگ از php باشه. جالب اینجا بود که روی لوکال این مشکل رو نداشتم بعد فهمیدم که این مشکل فقط توی php 5.2.6 هست و از اونجایی که php که همراه ubuntu 8.04 هست php 5.2.4 هست، من متوجه این مشکل نشده بودم.
توی قسمت باگ های php که سرچ کردم دیدم حدود 4 ماه پیش یک نفر این باگ رو گزارش داده و حدود 2 ماه هم هست که توی CVS رفع شده.  فعلا تا اومدن نسخه جدید php مجبور شدم به یک روش سرخ پوستی این باگ رو دور بزنم.

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

حال و حوصله نصب php از سورس رو نداشتم، تازه هر موقع نسخه جدید میومد باید دوباره کامپایل میکردم. این apt هم بد جوری ما رو بد عادت کرده.

یه سرچ کردم سایت dotdeb.org رو پیدا کردم. به لطف apt به سه سوت php آپگرید شد و هر موقع هم که آپدیت جدید بیاد به یک سوت میتونم آپگریدش کنم.

به قول جادی به نظر شما این سیستم عامل زیبا نیست؟

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

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

در راستای اشاعه فرهنگ open source من این پروژه رو با لایسنس GPL منتشر کردم. به عبارتی شما در استفاده ، توزیع و تغییر این پروژه آزاد هستید ولی به این شرط که لایسنس این پروژه ، پروژه هایی که از این پروژه منشعب شده اند و پروژه هایی که از این پروژه در آنها استفاده شده است GPL باشند.

ضمنا اگر هنوز تو برنامه ی رکورد شکنی فایرفاکس ثبت نام نکردید اینجا رو کلیک کنید.

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

قبل از هر چیز بهتره فلسفه وجودی HTML رو بررسی کنیم.

جایگاه HTML در طراحی

در طراحی و پیاده سازی صفحات وب و application های تحت وب، تکنولوژی های متعددی مورد استفاده قرار می گیرند که هر کدام کاربرد خاص خودشون رو دارند. در این بین کاربردها و اهداف اصلی استفاده از HTML رو میشه در دو مورد زیر خلاصه کرد:

1. توصیف ساختار معنایی اطلاعات
2. تولید رابط کاربری و فرم های ورود اطلاعات

البته از HTML میشه برای توصیف ساختار ظاهری اطلاعات هم استفاده کرد که امروزه این کار تقریبا منسوخ شده و این وظیفه به CSS محول شده. به عبارت دیگه CSS برای جدا کردن ساختار ظاهری از ساختار معنایی ابداع شد. و بنابراین امروزه استفاده از تگهایی نظیر font و center و همچنین استفاده ازattribute هایی نظیر bgcolor و width داخل HTML تقریبا منسوخ شده. در راستای جدا کردن ساختار ظاهری از HTML حتی استفاده از table برای طراحی layout هم به نوعی قبیح دانسته شده و به جای آن از طراحی های مبتنی بر div و CSS استفاده میشه.

فرایند تکاملHTML5

HTML 4 در سال 1997 منتشر شد. با گذشت زمان نیاز به ایجاد تغییرات برای برآوردن نیازهای جدید شدیدا احساس میشد.

روند کند توسعه استانداردهای وب که تحت نظارت w3c انجام میشد باعث شد تا گروه whatwg متشکل از علاقمندان و نمایندگانی از شرکت های فعال در این عرصه نظیر موزیلا ، اپرا و اپل در سال 2004 تشکیل شود.

حاصل کار چند ساله این گروه در اواسط سال 2007 برای تدوین استاندارد HTML5 مورد قبول W3C واقع شد.

تغییرات HTML5

تغییرات HTML5 بیشتردر رابطه با هر چه بهتر برآوردن دو هدفی است که پیشتر گفته شد.

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

section , article , aside, header , footer , nav , dialog , figure

تغییرات جدید برای طراحی بهتر فرم های ورود اطلاعات :

افزوده شدن انواع جدیدی از input نظیر : datetime, datetime-local, date, month, week, time, number, range, email, url

تگ های جدید output و datalist

برخی از تگ های جدید برای پویا تر شدن محتوا و رابط کاربری:

audio, video, canvas, meter, progress, event-source, …

برای مشاهده لیست کل تغییرات به اینجا مراجعه کنید.

سازگاری مرورگرها با HTML5

اکثر مرورگر ها به غیر از IE همگام با استاندارد ها پیش میروند و کم و بیش از استاندارد های جدید پشتیبانی میکنند.

هم اکنون نسخه های بتای firefox3 و opera9.5 تا حدودی از HTML5 پشتیبانی میکنند. قطعا زمانیکه HTML5 از پیش نویس خارج شده و recommendation شود این مرورگر ها هم از نسخه بتا خارج شوند، میتوان انتظار داشت تا از HTML5 و CSS3 پشتیبانی قابل قبولی داشته باشند. و با توجه به این که اکثر کاربران این مرورگرها از نسخه های آپدیت استفاده میکنند در آینده نزدیک مشکل خاصی با این مرورگرها وجود نخواهد داشت.

و اما IE که متاسفانه حدود 75 درصد از کاربران وب از آن استفاده میکنند. بعید به نظر میرسد که در آینده نزدیک (و یا حتی دور) پشتیبانی قابل قبولی از HTML5 و CSS3 داشته باشد.

IE6 در سال 2001 منتشر شد و در سال 2005 نسخه ی 7 این مرورگر در حالی منتشر شد که پیشرفت چشمگیری نسبت به نسخه قبل نداشت و حتی هنوز از CSS2 هم پشتیبانی خوبی نداشت. و اگر مایکروسافت این روند را در پیش بگیرد نمیتوان به IE8 امیدوار بود.

البته خبرها حاکی از آن است که پس از طرح شکایتی از طرف opera بر علیه مایکروسافت بالاخره مایکروسافت تصمیم به تولید IE8 مطابق با استاندارد های وب گرفته است.

با این وجود باز هم نمیتوان به IE8 امیدوار بود چون اولا هنوز نسخه بتای این مرورگر هم وارد بازار نشده ثانیا تجربه نشون داده که بعد از گذشت 3 سال از انتشار IE7 هنوز نیمی از کاربران IE از نسخه 6 استفاده میکنند.

برای مشاهده جزئیات بیشتر در رابطه با میزان سازگاری مرورگر ها با HTML5 اینجا را ببینید.

سازگاری طراحان وب با مرورگرها

از اونجایی که سازگاری یکسان همه مرورگرها با استاندارد های وب رؤیایی بیش نیست. لذا طراحان وب چاره ای ندارند جز اینکه خودشان(طرح ها یشان) را با مرورگر ها سازگار کنند. اینجاست که باید به روش های سرخ پوستی(هک) متوسل شد.

برای مثال برای پشتیبانی از canvas در IE میتوان از explorercanvas استفاده کرد که در واقع canvas شبیه سازی شده با استفاده از جاوااسکریپت و vml است.
نمونه ی دیگری از استفاده از روش های سرخ پوستی را میتوانید در اینجا ببینید.

اینجا یک سئوال فلسفی پیش میاد و اون اینکه HTML5 و CSS3 برای راحت تر و بهتر شدن طراحی بوجود آمده اند ولی با توصیفاتی که ذکرش رفت، طراحی با تکنولوژی های جدید و در عین حال سازگار بودن با تمام مرورگرها کار را دشوار تر میکند. اما چاره ای نیست چون گذر از این مراحل برای پیشرفت لازم است حتی اگر دشوار باشد و حتی اگر موانعی نظیر IE بر سر راه باشد.

آپدیت:

در رابطه با کامنتی هایی که دوستان در این مطلب و مطلب قبلی در مورد XHTML گذاشتند اون طور که من فهمیدم XHTML5 در واقع همون HTML5 با رعایت قوانین XML هست. ولی در مورد XHTML2.0 بر خلاف XHTML1 که بر اساس HTML4 توسعه یافته، XHTML 2.0 کاملا مستقل از HTML5 هست و حتی با XHTML 1.1 هم سازگاری نداره. و حتی بعضی ها نظیر apple زیاد با توسعه آن موافق نیستند.

دیروز W3C اولین پیش نویس رسمی HTML5 رو منتشر کرد:

http://www.w3.org/TR/html5/

این هم تفاوت های HTML5 با HTML4 :

http://www.w3.org/TR/html5-diff/

چند تا از element های html رو میتونید در 5 دقیقه نام ببرید؟

به نظر کار آسونی میاد ولی من که فقط 43 تا رو تونستم بگم.

شما هم حضور ذهن خودتون رو محک بزنید :

http://www.justsayhi.com/bb/html_quiz

اخیرا گوگل API جدیدی برای تولید انواع نمودار معرفی کرده که میتونین بصورت رایگان توی کارهاتون برای رسم نمودار ازش استفاده کنین.

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

من که نفهمیدم این API برای گوگل چه سودی داره. هیچ نام و نشونی هم از گوگل توی نمودارهایی که می سازه نمی زنه.

البته راهکارهای دیگه ای هم برای تولید نمودار هست. مثلا استفاده از jpgraph که یکسری مجموعه کلاس به زبان php هست که رایگان هم هست.
یک راه حل مقرون به صرفه دیگه هم استفاده از فلش هست (مثل fusioncharts). عیبش اینه که همه فلش ندارند.
بهترین راه هم استفاده از canvas هست. که مشکلش اینه که IE ساپورتش نمیکنه. البته این مشکل هم با explorercanvas قابل حله. برای مثال plotkit و یا ejschart از canvas برای رسم نمودار استفاده میکنند.