چابکی در غول آبی

اینکه بعد از این همه مدت چیزی بنویسم به تجربه‌های قبلی و تلاش‌های گذشته در مورد Agile‌ بر می‌گردد. من زمان‌های زیادی رو در سال‌های گذشته برای قانع کردن مدیران پروژه بزرگ به استفاده از متدهای چابک و تغییر عادت‌های قدیمی و پرخرج سپری کرده‌ام. تا دو یا سه سال پیش پس از همه بحث‌ها و قانع نشدن‌ها این جملات احمقانه رو می‌شنیدم که اگر خوب بود IBM‌ هم استفاده می‌کرد. در آن زمان اگر چه بلاگر‌های زیادی از IBM‌ و SAP در این مورد می‌نوشتند، اما مدرک خوب (بخوانید Case Study مناسب) در این مورد نبود. برای قسمت زیادی از مدیران قدیمی و پر سن و سال، هیچ چیزی بهتر از توجیه اقتصادی نیست و این هم کمکی است که آی بی ام کرده است:

Agile transformation helps IBM Software Group save USD300 million

“We now have 57,000 employees within 346 product areas using Rational Team Concert software, and they have adopted it on their own, which I think is a very, very strong statement.” – Julie King, vice president of consumability, IBM Software Group, IBM

حفاظت در مقابل درخواست های دوگانه

Response Cache: Double Request Protection

(کش پاسخ: حفاظت در مقابل درخواست های دوگانه)

یک مشکل استاندارد در web-application ها پردازش مناسب درخواست های دوگانه (چندگانه) با دیتای یکسان است. سناریوهای ممکن عبارتند از:
۱- refresh کردن صفحه جاری
۲- انجام bakc-forward در صفحات وب
۳ – کلیک کردن بیش از یکبار دکمه submit

درخواست های چندگانه می تواند اثرات جدی بر روی برخی application ها مانند خرید و فروش اینترنتی داشته باشد. راه حل های client-side برای رفع این مشکل، کامل نیستند. به عنوان مثال می توان توسط JavaScript، double click را بر روی submit غیرفعال کرد، مشروط بر اینکه کاربر JavaScript را در مرورگر خود فعال کرده باشد.
هر چند مشکل در مورد refresh و back- forward به قوه خود باقی است. و یا تنظیم هدرهای HTML تنها منجر به اعلام warning به کاربر می شود که می تواند از آن صرف نظر کند. تنها متد قابل اعتماد، حفاظت در طرف سرور است. راه حل ساده و اولیه، تولید شناسه های یکتا در پاسخ به درخواست های یک کاربر (هر session) و ارسال یه سرور توسط hidden fields و  مقایسه آن با id ذخیره شده در session است. در صورت یکسان بودن هر دو id، کاربر به صفحه خطا هدایت می شود. اما نمایش صفحه خطا چندان مطلوب نیست چون کاربر گزارش وضعیتی مناسبی در مورد عمل قبلی خود دریافت نمی کند. Response cache یک راه حل کلی مبتنی بر Servlet Filter است. کلیه درخواست ها به یک فیلتر ارسال می شود. در صورتی که درخواست برای اولین بار ارسال شده باشد پردازش توسط سرولت های مقصد انجام شده و نتیجه به کاربر ارسال و ضمنا در کش ذخیره می گردد. در صورت تکراری بودن، نتیجه قبلی از کش ارسال می شود.

– این library را می توانید از اینجا دانلود کنید.
منبع از گروه FINGO
– اطلاعات بیشتر در مورد Servlet Filter را می توانید در The Essentials of Filters بیابید.

ORM – Object Relational Mapping

data persistence به پایدار کردن داده بعد از به پایان رسیدن پروسه ای که آن را ایجاد کرده -به منظور بازیابی در آینده- اطلاق می شود. رایج ترین روش persistence استفاده از پایگاه داده رابطه ایست، چون ایجاد و دستیابی به آنها -بوسیله Sql- راحت است. با این وجود هنگام پیاده سازی یک application شی گرا ممکن است persistence کردن اشیا به یک مدل رابطه ای دشوار باشد. به تفاوت های میان دو مدل شی گرا و رابطه ای impedance mismatch گفته می شود مانند identity (مشکل در درج ۲ شی متفاوت با مقدار یکسان) inheritance و association. به عبارتی تلفیق اشیا با شمای رابطه ای به راحتی امکان پذیر نیست.

ORM برای حل این مشکل ابداع شده است. ORM پروسه پایدار کردن اشیا در یک پایگاه داده رابطه ایست و این امکان را به application می دهد که اشیا را مستقیما و بدون نیاز به تبدیل به/از فرمت رابطه ای persist کند.

همچنین در یک enterprise application به جنبه های دیگری -علاوه بر قابلیت های پایه زبان برنامه نویسی برای دسترسی به پایگاه داده- نیاز است مانند:

– Lazy Loading: عدم بازیابی کل اشیای مرتبط هنگامی که گراف اشیا پیچیده باشد.
– Eager Fetching: بازیابی کل گراف اشیا با یک operation.
– Caching: عدم نیاز به بازیابی شی ای که بیشتر خوانده می شود و کمتر تغییر می کند در هر بار دستیابی.
– Cascading: انجام خودکار update منتشر شونده در پایگاه داده.

از جمله ORM Framework ها می توان Hibernate را برای جاوا نام برد. نمونه ای از فایل تنظیم Hibernate که یک کلاس جاوا را به یک جدول پایگاه داده تصویر می کند در زیر آورده شده است. در این مورد کلاس Event با فیلد id به عنوان کلید اولیه به جدول events تصویر می شود. Event با کلاس های Speaker و Attendee رابطه one-to-many و با Location رابطه many-to-one دارد.

منبع: Hibernate Quickly Book | ORM in Detail

متدولوژی Agile

شاید قابل توجه ترین تغییر در پروسه تولید نرم افزار در دهه گذشته، ظهور agile بوده است. به طور کلی متدولوژی های تولید نرم افزار برای قانونمند کردن پروسه تولید، به منظور کاراتر ساختن و قابل پیش بینی کردن روند، به وجود آمده اند. تمرکز این متدولوژی ها طرح ریزی یک پروسه دقیق و با جزئیات است.

در متدولوژی های اولیه که engineering methodologies یا plan-driven methodologies نامیده می شوند، هدف جداسازی کامل طراحی از ساخت و ایجاد یک طرح و زمان بندی دقیق و قابل پیش بینی است که قابل استفاده توسط افراد با توانایی های کمتر باشد. این روش ها کاملا موفق نبوده اند. بزرگترین مشکل بروکراتیک بودن آنهاست. برای پیروی از متدولوژی ها جزئیات زیادی باید دنبال شود که منجر به کند شدن روند تولید می گردد.

Agile تعادلی بین no process و too much process برقرار می کند.تفاوت های بسیاری بین agile و روش های اولیه وجود دارد، از جمله در agile حجم مستندسازی به طور قابل توجهی کمتر است و می توان گفت که روشی code-oriented می باشد. کلیدی ترین بخش یک سند کد برنامه است. اما دو تفاوت عمیق و اساسی:

  1. روش های agile تطبیقی هستند و نه قابل پیش بینی. روش های plan-driven می کوشند کل پروسه تولید را با جزئیات کامل، برای مدت طولانی طرح یزی نمایند. این روش تنها تا زمانی که تغییراتی پدید نیامده کاراست. ذات این متدها در مقابل تغییرات مقاوم است. در حالی که agile از تغییرات استقبال کرده و می کوشد که سیستم و حتی روند تولید را تطبیق دهد.
  2. agile، people-oriented است و نه process-oriented. developerها باید قادر باشند خود تمام تصمیمات تکنیکی را اتخاذ کنند. در واقع مسئولیت ها بایستی به طور مساوی میان مدیر پروژه و developerها تقسیم شود.

Iterative development راه حل کنترل یک پروسه غیرقابل پیش بینی است. در این روش ها دائما ورژن هایی از سیستم نهایی تولید می شود که شامل زیرمجموعه ای از جنبه های مورد نیاز سیستم هستند. این ورژن ها عملیات کم اما کاملا صحیح و مطمئنی را انجام می دهند. Iterative development در پروسه های تطبیقی ضروری است. در یک پروسه تطبیقی باید طرح هایی کوتاه مدت و برای یک iteration ایجاد شوند. مدت زمان یک iteration بر حسب نوع متد متفاوت است، ۱-۲ هفته (XP)، ۱ ماه (SCRUM) ، …

تطبیق دو جنبه دارد:

  1. تغییر در نرم افزار برای تطبیق با تغییرات خواسته ها.
  2. تغییر در پروسه تولید بدین مفهوم که روند تولید در پایان هر iteration بازدید، نقاط ضعف و قوت بررسی و تصمیماتی برای iteration بعدی اتخاذ می شود.

انواع مختلفی از متدهای agile وجود دارد، مانند: XP، SCRUM، Crystal، Lean، Rational Unified Process، …

منبع / اطلاعات بیشتر:Agile Alliance

آموزش Microsoft Visual Basic.net مبتدی

این مهران که آخرش به من دات نت یاد نداد، اما این کتاب دوستان ویندوزی را به زودی می خوانم !!!
امیر احسانی و حامد بنایی کتابی تحت عنوان آموزش Microsoft Visual Basic.net مبتدی را منتشر کرده اند که بسیار کاری است نیکو. موفق باشید دوستان عزیز

حاشیه : ببینید درست هست که خیلی ها وبلاگ را پدیده ای بیهوده می دانند، اما کمی فکر کنید، چه نتایج خوبی را می توان از آن گرفت. یادداشت امیر / یادداشت حامد

Zlib Compression – فشرده سازی محتوای وب سایت

اگر بازدید کننده ثابت
تکوپیدیا باشید احتمالا متوجه افزایش سرعت لود شدن آن شده اید.این کار با استفاده
از توابع Zlib
Compression
که در تنظیمات php.ini و یا وب سرور آپاچی
قابل فعال سازی است انجام شده است.در این روش محتوایی که از طرف وب سرور با سمت
بازدید کننده منتقل می شود به صورت on-the-fly فشرده می
شوند و در سمت بازدید کننده ( Client ) از حالت فشرده سازی
خارج می شوند و بدون تغییر نمایش داده می شوند.
این فشرده سازی می تواند تا حدود ۸۰ درصد در حجم اطلاعاتی که از طرف سرور ارسال می
شوند صرفه جویی کند.این مقدار فشرده سازی علاوه بر صرفه جویی قابل توجهی که بر
پهنای باند مصرفی شما خواهد شد ، سرعت بارگذاری صفحات را تا حد قابل ملاحظه ای
افزایش می دهد.
برای توضیحات کاملتر می توانید به نوشته نیما مراجعه کنید : 
فشرده سازی محتوا

در مورد تکوپیدیا ،این
فشرده سازی از نظر من و با توجه به اطلاعات
PipeBoost تا حدود 80 درصد
موثر بوده است ، و حجم انتقال اطلاعات را از حدود ۸۰ کیلوبایت به ۱۷ کیلوبایت کاهش
داده است.اینجا را ببینید :

URL Compression Report

برای فعال سازی این امکان باید به صورت مستقیم در فایل
php.ini این قسمت را وارد کنید :

           
zlib.output_compression On

تنها مشکلی که وجود
دارد ، در مورد افرادی است که از share hosting ها استفاده
می کنند و دسترسی به فایل php.ini ندارند ، در این مورد می
توان با استفاده از htaccess. استفاده کنید.برای این کار در
قسمتی که می خواهید این فشرده سازی انجام شود ، در htaccess. آن قسمت از مقادیر زیر
استفاده کنید :

       
php_flag zlib.output_compression On

در مواقعی که دسترسی به
php.ini وجود ندارد ، می توان با استفاده از htaccess.
تغییرات لازم را انجام داد.برای این کار باید با توجه به نوع متغییر پیشوند مربوطه
را قبل از عنوان متغییر قرار دهید.در اینجا از  php_flag استفاده شده
است.مقادیری که می تواند استفاده شود php_value است.

    –
سهیل یک
ماجول تهیه کرده است تا بتوان
همین کار را بر روی وب سرورهای ویندوزی و برای ASP.NET
انجام داد.مقایسه ای که من برای وب سایت هایی که از
ASP.JET
استفاده می کردند کردم ، نتیجه ای مشابه Zlip برای
php گرفتم.ASP.JET
هم از gzip استفاده می کند.

    –
Zlib Compression
Functions

    –
Zlib
Configuration Options

    –
PHP, MySQL, php.ini and .htaccess info and tips

    – فشرده سازی
محتوا

مقدمه ای برای XSLT

چند بار در مورد
XSLT شنیده بودم اما
هیچ چیز به جز آنکه به XML مربوط می شود نمی دانستم.
وب سایت محترم Developer Channels  بر
اساس کتاب تازه منتشر شده



XSLT 2.0 Web Development
یک سری مقاله در معرفی XSLT
تهیه کرده است که برای من مقدمه ای بود برای آشنایی با این زبان.جدیدا ترجیح می دهم
به جای ترجمه مقاله هایی که از آن ها لذت می برم فقط آن را معرفی کنم.به شما هم
خواندن این سری مقاله ها را توصیه می کنم.می تواند نقطه شروعی برای کار با این زبان
باشد/



An overview of XSLT

XSLT is a wonderful, truly
data-oriented (as opposed to algorithm-oriented) language where
everything Just Works. You must have a good grasp of some basic
concepts (admittedly, somewhat unusual from other languages’
viewpoint), but after that, most of your code will likely work the
first time you run it. XSLT and XPath are so high-level that you can actually
think about what you want to do with your data, not
how.



XSLT: Taming a functional language

A functional program, as the name implies, consists of functions.
Unlike those in conventional programming languages, however, these
functions are absolutely independent from each other. Each function
has a set of arguments and returns a value, but it cannot produce —
or be affected by — any side effects. In other words, if you
pass the same set of arguments to a function, you will always get
the same result, no matter at what point of program execution this
happens or what other functions were called before it.



Overview of an XSLT stylesheet

The basic idea of XSLT is this: Run into a context, invoke the
corresponding template. Templates usually constitute the bulk of
a stylesheet’s code. But are all templates created equal? There are
several meaningful distinctions that you should keep in mind when
building your template library.