Proof of Concept - PoC

 

فردا 15 نفر مهمان دارید و می خواهید برای آنها غذایی را آماده کنید که برای اولین بار می خواهید پخت آن را تجربه کنید. فرض کنید خورش فسنجان

مواد اولیه خورش شامل مقدار زیادی گردو، رب انار، مرغ، برنج و دیگر مواد لازم را تهیه کرده اید و دستور پخت را هم در اختیار دارید. حال چه می کنید؟

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

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

هر چند این رویکرد زمان بیشتری طلب می کند اما ریسک پخت غذای اصلی به میزان قابل توجهی کمتر بوده و نتیجه نهایی بسیار قابل پیش بینی تر و نزدیکتر به آنچه مطلوب است خواهد بود.

Facebook at 13 Million Queries Per Second Recommends: Minimize Request Variance

Facebook gave a MySQL Tech Talk where they talked about many things MySQL, but one of the more subtle and interesting points was their focus on controlling the variance of request response times and not just worrying about maximizing queries per second.

But first the scalability. Facebook's OLTP performance numbers were as usual, quite dramatic:

- Query response times: 4ms reads, 5ms writes.

- Rows read per second: 450M peak

- Network bytes per second: 38GB peak

- Queries per second: 13M peak

- Rows changed per second: 3.5M peak

- InnoDB disk ops per second: 5.2M peak

Some thoughts on creating quality, not quantity:

- They don't care about average response times, instead, they want to minimize variance. Every click must be responded to quickly. The quality of service for each request matters.

- It's OK if a query is slow as long as it is always slow.

- They don't try to get the highest queries per second out of each machine. What is important is that the edge cases are not the bad.

- They figure out why the response time for the worst query is bad and then fix it.

- The performance community is often focussed on getting the highest queries per second. It's about making sure they have the best mix of IOPs available, cache size, and space.

Read more..

25 خطای خطرناک در نرم افزار

در وبلاگ آقای مهندس مهرداد مطلب جالبی درج شده بود در مورد تحقیقی صورت گرفته در رابطه با ۲۵ خطای خطرناک و شایع در نرم افزارها که بسیاری از تیم های برنامه سازی مرتکب آن می شوند. خواندن آنرا به همه دوستان نرم افزارچی(!) توصیه می کنم:

The Top 25 Errors are listed below in three categories:
Category: Insecure Interaction Between Components (9 errors)
Category: Risky Resource Management (9 errors)
Category: Porous Defenses (7 errors)

CATEGORY: Insecure Interaction Between Components
CWE-20: Improper Input Validation
CWE-116: Improper Encoding or Escaping of Output
CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection')
CWE-79: Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')
CWE-78: Failure to Preserve OS Command Structure (aka 'OS Command Injection')
CWE-319: Cleartext Transmission of Sensitive Information
CWE-352: Cross-Site Request Forgery (CSRF)
CWE-362: Race Condition
CWE-209: Error Message Information Leak
CATEGORY: Risky Resource Management
CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer
CWE-642: External Control of Critical State Data
CWE-73: External Control of File Name or Path
CWE-426: Untrusted Search Path
CWE-94: Failure to Control Generation of Code (aka 'Code Injection')
CWE-494: Download of Code Without Integrity Check
CWE-404: Improper Resource Shutdown or Release
CWE-665: Improper Initialization
CWE-682: Incorrect Calculation
CATEGORY: Porous Defenses
CWE-285: Improper Access Control (Authorization)
CWE-327: Use of a Broken or Risky Cryptographic Algorithm
CWE-259: Hard-Coded Password
CWE-732: Insecure Permission Assignment for Critical Resource
CWE-330: Use of Insufficiently Random Values
CWE-250: Execution with Unnecessary Privileges
CWE-602: Client-Side Enforcement of Server-Side Security

برای مشاهده اصل گزارش اینجا را کلیک کنید.

SOAP چیست؟

 نمی دانم چرا هر وقت این کلمه به گوش یا چشمم می خورد یاد حمام و پاکیزگی می افتم! اما خب نرم افزار خیلی از مفاهیم را دستخوش تغییر کرده است. جالبتر اینکه پس از جستجوی بسیاری از کلمات در اینترنت که معنی اصلی آنها صدها سال قدمت دارد، اولین یافته ها همانا معانی عجیب و غریب آن کلمات در صنعت محترم نرم افزار است. کاربر بخت برگشته ای را تصور کنید که برای یافتن صابون مورد علاقه خود کلمه Soap را در گوگل جستجو می کند و در دریایی از کلماتی چون XML، Protocol و HTTP غرق می شود!

 SOAP  مخفف Simple Object Access Protocol است. SOAP یک پروتکل مبتنی بر XML است و به منظور انتقال اطلاعات (درخواست و پاسخ) در شبکه ها (خصوصا اینترنت) به کار می رود. به عبارت دیگر SOAP چیزی بیش از یک قرارداد مبتنی بر XML نیست که فرستده و گیرنده باید قالب آنرا رعایت کنند تا بتوانند با یکدیگر تعامل داشته باشند. یکی از ویژگی های اصلی SOAP این است که Firewallها مانع آن نمی شود.

ویژگیهای SOAP:

1.       یک پروتکل ارتباطی است

2.       به منظور تعامل میان برنامه ها و/یا سرویس ها به کار می رود

3.       مستقل از Platform است

4.       مستقل از زبان است

5.       مبتنی بر XML است

6.       ساده و قابل توسعه است

امروزه برنامه ها با استفاده از Remote Procedure Calls (RPC) با یکدیگر تعامل می کنند اما HTTP برای این منظور طراحی نشده است. RPC دارای مشکل سازگاری و امنیت است و Firewall ها و Proxy Server ها عموما این نوع از ارتباط را مسدود می کنند. راه حل بهتر برای این گونه ارتباط، استفاده از بستر HTTP است که توسط طیف وسیعی از سرورها و مرورگرها پشتیبانی می شود. SOAP به منظور ایجاد این گونه ارتباط بروی بستر HTTP به وجود آمده است.

یکی از مهمترین مزایای SOAP استقلال آن از زبان برنامه و Platform است. به این مفهوم که SOAP می تواند پروتکل مشترک ارتباطی میان دو برنامه با زبان های مختلف (مثلا .Net و PHP) و/یا دو Platform متفاوت (مثلا Windows و Linux) باشد.

معایب SOAP:

• به دلیل طولانی بودن ساختار XML آن، در مواردی که پیام ارسالی طولانی باشد کند عمل می کند.
• نظر به اینکه سادگی از اصول اولیه SOAP است، این ویژگی منجر به قربانی شدن امنیت و قابلیت اعتماد شده است.
• به دلیل استفاده SOAP از HTTP، Firewall ای که صرفا برای مرور وب طراحی شده است به سادگی اجازه انتقال HTTP Packets را نمی دهد.

 می خواستم ساختار SOAP را در اینجا نمایش دهم که متوجه شدم بلاگفا این ساختار را به جای نمایش parse می کند و به جای ساختار، خروجی آنرا نمایش می دهد! در صورت علاقه مندی می توانید ساختار آنرا در سایت http://www.w3.org مشاهده کنید.

  

References:

1.      http://www.w3schools.com/soap

2.      http://www.w3.org/TR/2000/NOTE-SOAP-20000508

3.      http://en.wikipedia.org/wiki/Simple_Object_Access_Protocol

4.      http://www.radcom.ir/kb-soap-fa.html

5.      E-Book: Pro WCF: Practical Microsoft SOA Implementation By: Chris Peiris & Dennis Mulder, Apress publication

 

بهینه سازی کد (Code Optimization)

حتما با قانون Pareto آشنا هستید، همان قانون 80/20. به نظر میرسد این قانون در مورد Bottleneck های (ترجمه فارسی پیشنهاد شود لطفا!) نرم افزار نیز صدق می کند. بسیار دیده ام که با تغییر بخش کوچکی از کد، کارایی (Performance) نرم افزار به میزان قابل توجهی افزایش پیدا کرده است. سعی می کنم برخی از تجربیات خود را در این زمینه به اشتراک بگذارم. قطعا بیشتر دوستان و همکاران گرامی - که بیشتر آنها نسبت به من از تجربیات بسیار بالاتری برخوردارند – این مطالب را صرفا یادآوری تلقی می کنند. بیشتر مثال ها و نمونه ها به زبان C# و .Net Framework 2.0  خواهد بود.

کار با رشته ها:

کمتر کد نویسی پیدا میشود که با رشته ها کار نکرده باشد. یکی از کاربردهای رایج استفاده از رشته ها چسباندن متوالی رشته ها به یکدیگر است. به عنوان یک صورت مساله فرض کنید که می خواهیم یک فایل Comma Separated Value (CSV) بسازیم و برای این کار باید تعداد زیادی از رشته های کوچک را با فاصل کاما (,) به هم متصل (Concatenate) کرده و در یک فایل بنویسیم.

راه 1: استفاده از System.String

String s1 = “”;

foreach(string s2 in AnArrayOfStrings)

{

      s1 += s2;

}

 

راه 2: استفاده از System.Text.StringBuilder

StringBuilder s1 = new StringBuilder();

foreach(string s2 in AnArrayOfStrings)

{

s1.Append(s2);

}

 

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

استفاده از System.String:    7147 میلی ثانیه

استفاده از System.Text.StringBuilder:    17 میلی ثانیه (!)

 

علت اختلاف زیاد دو راه حل این است که هنگام استفاده از System.String هر مرتبه که یک رشته به رشته ای الحاق می شود، رشته جدیدی (جدید s1) ایجاد می شود و رشته قبلی (s1 قدیمی) رها (Abandon) می شود و اشاره گر خود را از دست می دهد تا Garbage Collector آنرا پاکسازی نماید. شاید بسیاری از برنامه نویسان تعجب کنند که پس از اجرای تکه کد زیر 4 رشته جدید در حافظه به وجود خواهد آمد:

string s;

s = “a”;

s += “b”;

s += “c”;

s += “d”;