وب نوشت های مرد مرده

اعمال تغییرات بر روی فایروال در CentOS با استفاده از firewall-cmd

2020-08-30T19:23:00.001+04:30

برای اعمال تغییرات بر روی فایروال با استفاده از firewall-cmd در CentOS میتونیم به صورت زیر عمل کنیم:

۱. وضعیت فعلی قوانین فایروال

$ sudo firewall-cmd --list-all

۲. اضافه کردن یک سرویس

$ sudo firewall-cmd --add-service=http

۳. اضافه کردن یک پورت

$ sudo firewall-cmd --add-port=1234/tcp
$ sudo firewall-cmd --add-port=1234/udp

۴. برای ذخیره تغییرات اعمال شده از سوییچ --premanent استفاده میکنیم:

$ sudo firewall-cmd --premanent --add-port=1234/tcp

نکاتی کوتاه در C++: rvalues

2020-02-20T15:42:00.001+03:30

توی این سری میخوام نکاتی رو در مورد برنامه نویسی به زبان C++ بطور مختصر و با زبان ساده توضیح بدم.

تو اولین پست از این سری میخوام راجع به rvalue ها در c++ بنویسم. یکی از مواردی که برای خیلی از برنامه‌نویس‌ها ممکنه مقداری نامفهوم باشه.

مفهوم rvalue ها در c++ به مقادیر موقتی گفته میشه که به طور معمول در سمت راست یک expression قرار میگیرن. میشه اونها رو به یک متغیر اختصاص داد، اما نمیشه مقداری رو به اونها تخصیص داد. مقادیر عددی یا فراخوانی توابع مثال هایی از استفاده از rvalue ها در c++ هستش. تو مثال زیر `1` و `foo()` مثال هایی از rvalue هاست که برای مقداردهی اولیه متغیرهای `a` و `b` استفاده شده. به `a` و `b` در این مثال `lvalue` گفته میشه.

int a = 1;
int b = foo();

همچنین مثال های زیر نمونه هایی از مقدادهی نادرست بوده که امکان موقع کامپایل با خطا روبرو میشه:

1 = c; // error
foo() = d; // error

حالا چطور تعیین میکنیم که یک متغیر موقتی هستش؟‌ بطور کلی مقداری رو موقتی میدونیم که متغیری به اون مرتبط نشده باشه.

Int bar = 1; // bar is a name, so it is an lvalue.
2; // 2 is an integer literal, it has no name (no identifier). It's an rvalue.

مورد دیگه ای که میتونیم برای تشخیص rvalue ها استفاده کنیم اپراتور آدرس `&` هستش. توی c++ نمیتونیم آدرس rvalue ها در حافظه رو بگیریم.

int a = 1;
&a; // Works, address of a stack-allocated variable.
&1; // Error, 1 is an integer literal.
&foo(); // Error, cannot take address of the temporary result of a function call.

یکی از جاهایی که rvalue ها به ما کمک میکنن move semantics هستش که تو پست های بعدی راجع بهش صحبت میکنیم.

نکاتی در مورد ماکرو ها در سی / سی ++

2020-01-19T15:08:00.001+03:30

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

تعریف ماکرو

طبق تعریف ارائه شده در مستندات GCC، ماکرو در حقیقت تکه کدی هستش که براش نامی رو در نظر میگیریم. هرجا از برنامه که از این نام استفاده کرده باشیم کامپایلر قبل از شروع به کامپایل اون رو با تکه کد مربوطه جایگزین میکنه.

ما بطور کلی دو نوع استفاده از ماکرو داریم:

نوع اول object-like macros: که برای مشخص کردن مقادیر استفاده میکنیم.
نوع دوم function-like macros: ماکرو هایی که برای جایگزاری یه قطعه کد در برنامه استفاده میشن.

موارد معمول استفاده از ماکروها

حالا که یه تعریف کلی از ماکرو ارائه دادیم بریم سراغ استفاده های مختلف اون در برنامه ها:

۱. تعریف مقادیر ثابت پیش‌فرض

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

#define PORT 8080
#define LOG_PATH "/path/foo/bar"
#define DEBUG_MODE 1

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

همچنین میتونیم با استفاده از pre-processor flags برنامه رو با توجه به محیط مقصد کامپایل کنیم:

کامپایل بصورت پیش‌فرض:

$ gcc macro.c
$ ./a.out
compiled with: default flag

تغییر MYFLAG در هنگام کامپایل:

$ gcc -DMYFLAG='"modified flag"' macro.c
$ ./a.out
compiled with: modified flag

۲. تعریف یک عملیات خاص توسط ماکرو

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

#define MAX(a,b) (a>b ? a : b)
#define EXISTS(array, vector)  (vector.find(value) != vector.end())

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

امکانات قابل استفاده در تعریف ماکرو ها

۱. تبدیل متغیر ماکرو به متن

در حالت عادی متغیرها / عبارت هایی رو که به ماکرو پاس میدیم اول محاسبه (evaluate) میشن و بعد به بدنه ماکرو ارسال میشن، ولی اگه بخوایم ورودی که به ماکرو ارسال شده رو داشته باشیم میتونیم با اضافه کردن کاراکتر `#` قبل از ورودی مورد نظر اون رو بصورت یک رشته داشته باشیم:

خروجی برنامه:

$ gcc macro2.c
$ ./a.out
Warning: x == 1

۲. اتصال پارامترهای ماکرو

بعضی مواقع لازم داریم تا مقداری رو به پارامترهای یک ماکرو اضافه کنیم در این موارد میتونیم این مقاریر رو با استفاده از `##` به هم متصل کنیم. برای بهتر فهمیدن مورد استفاده این امکان ماکرو اون رو با یک مثال توضیح میدیم:‌

خروجی برنامه:

$ gcc macro3.c
$ ./a.out
quit command executed.
help command executed.

توی این مثال با استفاده از ماکرو `MKCMD` آرایه رو با name و function مربوطه بصورت خودکار initiate کردیم.

۳. ماکرو با آرگومان های متغیر

برخی مواقع لازمه که ماکرو ما تعداد متغیری ماکرو داشته باشه. برای این موضوع مثل تعریف توابع با پارامترهای متغیر نام ماکرو رو با `...` مشخص میکنیم و هنگام استفاده `__VA_ARGS__` رو بکار میبریم:

#define eprintf(…) fprintf (stderr, __VA_ARGS__)
...
eprintf ("%s:%d: ", input_file, lineno);  
// above line will be replaced with following:
//           fprintf (stderr, "%s:%d: ", input_file, lineno)

بعضی مواقع وقتی ماکرو ما خیلی پیچیده میشه میتونیم قبل از `...` یک نام رو برای بخش متغیر پارامترها تعیین کنیم و در ادامه از اون نام استفاده کنیم. فقط باید توجه کنیم که نمیتونیم این روش رو با همراه با __VA_ARGS__ استفاده کنیم.

#define eprintf(args...) fprintf(stderr, args)

ما همچنین میتونیم از پارامترهای با نام در کنار پارامترهای متغیر استفاده کنیم:

#define eprintf(format, …) fprintf (stderr, format, __VA_ARGS__)

اجرای برنامه با GDB و ذخیر لاگ در فایل

2020-01-19T14:54:00.002+03:30

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

برای مثال برنامه زیر رو که موقع اجرا خطا میده میخوایم با GDB دیباگ کنیم:

وقتی به صورت عادی برنامه رو اجرا کنیم با خطای زیر روبرو میشیم:‌

$ ./hello
Floating point exception

اجرای برنامه بوسیله GDB

برای اینکه برنامه رو با gdb اجرا کنیم کافیه تا اون رو به عنوان ورودی به GDB بفرستیم و بعد با دستور `run` برنامه رو اجرا کنیم:

$ gdb ./hello
(gdb) run

و موقع بروز خطا با استفاده از back trace به بررسی مشکل بپردازیم:

(gdb) bt

همونطور که میبینید GDB اطلاعاتی راجع متدی که خطا در اون پیش اومده در اختیارمون قرار میده.

ذخیره لاگ در فایل

برای این منظور باید قبل از اجرای برنامه با دستور run تنظیمات لاگ مربوط به GDB رو بصورت زیر انجام بدیم:

(gdb) set logging on
(gdb) set logging file /path/to/log/file

همچنین برای مشاهده تنظیمات فعلی لاگ GDB از دستور زیر میتونیم استفاده کنیم:

(gdb) show logging

استفاده از PKG-CONFIG در CMAKE

2020-01-19T14:42:00.000+03:30

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

جدیدا بخاطر سیاست شرکت جدید مجبور شدم از eclipse به Jetbrains CLion سوییچ کنم و این یعنی استفاده از CMAKE بجای build system داخلی eclipse. یکی از مواردی که تو روز اول کار با `CLio بهش برخوردم لینک کردن library های خارجی به برنامه خودم بود. برای اینکار از pkg-config استفاده کردم و بعد از نصب library مورد نظر، موارد زیر رو باید به فایل CMakeList.txt خودمون اضافه کنیم.

find_package(PkgConfig REQUIRED)
pkg_check_modules(TITLE lib-name REQUIRED)

include_directories(${TITLE_INCLUDE_DIRS})
link_directories(${TITLE_LIBRARY_DIRS})
link_libraries(${TITLE_LIBRARIES})

برنامه نویسی تست محور (TDD) - قسمت سوم یک مثال عملی

2020-01-19T13:41:00.002+03:30

حالا که با مفهوم برنامه نویسی تست محور آشنا شدیم و دیدیم که چرخه این تکنیک به چه صورت کار میکنه، میخوایم باهم یک مثال عملی رو با استفاده از NodeJS پیاده سازی کنیم. در ابتدا پیش نیاز ها رو باهم آماده میکنیم، بعد میریم سراغ ساخت پروژه و در انتها مشغول نوشتن کد برنامه میشیم.

آماده سازی پیش نیاز ها

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

ماژول Mocha: که از اون برای اجرای تست ها استفاده میکنیم.
ماژول Chai: که یک کتابخانه مدیریت خطا ها هستش.

برای پیاده سازی این مثال لازم داریم تا موارد زیر رو آماده داشته باشیم:‌

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

اولین مرحله برای شروع نصب Mocha هستش. Mocha یک فریمورک تست هستش که تو پروژه های NodeJS ازش استفاده میشه. نصب Mocha خیلی سادس و شما به راحتی با دستور زیر میتونید اون رو نصب کنید:

$ npm install -g mocha

همچنین نیاز داریم کتابخانه Chai رو برای مدیریت خطا ها به پروژه خودمون اضافه کنیم. برای اینکار دستور زیر رو توی ترمینال وارد میکنیم:

$ npm install chai --save-dev

ساخت پروژه NodeJS

برای این مثال ما از expressJS استفاده میکنیم. میتونید از Express Generator برای ساخت پروژه استفاده کنید. برای اینکار دستور زیر رو توی ترمینال وارد میکنیم:

$ express tdd_test

حالا باید پیش نیاز ها رو نصب کنیم:

$ npm install

بعد از ساخت پروژه باید اسکرپت تست خودمون رو به فایل package.json اضافه کنیم.

...
"scripts": {
     "start": "node ./bin/www",
     "test": "mocha test"
},
...

با اینکار هر موقع که دستور npm test رو اجرا کنیم mocha اجرا میشه.

ما توی ساختار برنامه لاجیک برنامه رو توی پوشه controllers قرار میدیم و برای عملیات مورد نظرمون فایل operations.js رو توی این پوشه میسازیم.

کدنویسی

از اونجا که Mocha بطور پیش فرض فایل های تست رو از مسیر test میخونه لازم داریم تا این پوشه رو تو شاخه اصلی پروژه بسازیم. داخل این پوشه فایل اصلی تست ها رو با اسم index.test.js میسازیم. این فایل مرجع همه تست های ما به حساب میاد و تست ها رو داخل اون import میکنیم.

خوب حالا که ساختار برنامه رو آماده کردیم، بیاین مراحل چرخه تست رو که تو قسمت های اول و دوم یادگرفتیم روی این پروژه اعمال کنیم:

۱. نوشتن تست برای امکانات مورد نظر

داخل پوشه test یک پوشه جدید به نام controllers میسازیم. توی این پوشه تمامی تست های مربوط به کنترلرهای خودمون رو مینویسیم. حالا توی این پوشه فایلی به اسم controller.test.js رو میسازیم. اگه یادتون باشه هدف ما نوشتن تستی جهت متد add هستش، برای همین باید تمامی لاجیک مورد نیاز برای این تست رو اینجا پیاده سازی کنیم. اگه از قسمت قبل یادتون باشه لاجیک مورد نظر ما به این صورت هستش:

دریافت دو مقدار عددی از ورودی و بازگشت پاسخ صحیح در خروجی.

خوب حالا کد تست رو بصورت زیر مینویسیم:

var expect = require('chai').expect;
var addOp = require('../../controller/operations').addOp;

describe('Math', ( ) => {
   describe('#add function', ( ) => {
      it ('should returns the result number from the two arguments', ( ) => {
         var result = addOp(1,2); 
         expect(result).to.equal(3);
      });
   });
});

همونطور که توی این کد میبنید ما اول اومدیم متد expect رو از کتابخونه تست خودمون (Chai) اضافه کردیم. بعد از اون امکاناتی رو که قراره بعدا پیاده سازی کنیم رو به برنامه تست اضافه کردیم. در ادامه توی کد تست خودمون اومدیم دو تا عدد ۱ و ۲ رو به متد add دادیم و انتظار داریم که عدد 3 رو که جواب صحیح هستش توی خروجی دریافت کنیم. تا اینجای کار تو این مرحله ما هیچ کدی رو پیاده سازی نکردیم و تنها تست مربوطه رو آماده کردیم.

۲. اجرای تست و مشاهده خطا های دریافتی

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

برای اینکه تست رو اجرا کنیم ابتدا باید تست خودمون رو به فایل index.test.js اضافه کنیم.

require('./controllers/controller.test');

حالا با اجرای دستور زیر تست رو اجرا میکنیم:

$ npm test

همونطور که میبینید با پیغام خطای TypeError: addOp is not a function روبرو شدیم. این بدین معناست که متد add هنوز به کنترلرمون اضافه نشده.

۳. پیاده سازی ساختار امکانات مورد نظر:

توی این مرحله ما میخوایم که ساختار امکاناتی رو که میخوایم پیاده سازی کنیم رو آماده کنیم. برای همین به سراغ فایل operations.js که قبلا ساختیم میریم و ساختار متد addOp رو بصورت زیر توی این فایل آماده میکنیم:

exports.addOp = function (var1, var2) {
};

تو این مرحله ما فقط ساختار متد add رو آماده کردیم و به همین دلیل ما میتونیم این متد رو توی فایل تست import کنیم و دو تا ورودی رو بهش پاس بدیم.

۴. اجرای تست و مشاهده نوع خطا

حالا بیاین یک بار دیگه تست رو توی این مرحله اجرا کنیم:

$ npm test

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

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

exports.addOp = function (var1, var2) { 
const num1 = isNaN(var1) ? 0 : var1;
const num2 = isNaN(var2) ? 0 : var2;

return num1 + num2;
};

۶. در نهایت پاس شدن تست ها

تو این مرحله تنها کافیه تا تست رو مجددا اجرا کنیم و شاهد پاس شدن تست هایی که نوشتیم باشیم:‌

حالا که متد ما پیاده سازی شده و تمامی تست های مورد نیاز پاس شده، کار ما به پایان میرسه. اگه نیاز باشه متد جدیدی به کنترلر ما اضافه بشه ( مثلا عملیات تفریق ) ، می بایست کلیه این مراحل رو از اول برای متد جدید اجرا کنیم. در انتها تکنیک TDD به ما اطمینان میده که پیاده سازی این امکانات جدید مشکلی برای امکاناتی که قبلا پیاده سازی شده بودن ایجاد نکرده باشه.

امیدوارم که از این سری آموزشی استفاده لازم رو برده باشید و با تکنیک برنامه نویسی تست محور (TDD) آشنا شده باشید. اگه دوست داشته باشید میتونید وبلاگ من رو کنید و مطالب جدیدی رو که تو زمینه تکنولوژی مینوسم مطالعه کنید.

برنامه نویسی تست محور (TDD) - قسمت دوم یک مثال ساده

2020-01-19T12:15:00.003+03:30

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

ابتدا بیایم با مفهومی که باید تست بشه آشنا بشیم...

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

خوب حالا بیایم مراحل TDD رو که توی پست قبل باهاشون آشنا شدیم توی توسعه لاجیک برنامه خودمون بکار ببریم:

۱. نوشتن تست برای امکانات مورد نظر

همونطور که گفتیم، اولین مرحله نوشتن تست هستش. نیازمندی ماشین حساب ما رو که به یاد دارید «عمل جمع». برای همین اسم متد تست خودمون رو «Add» میزاریم ( توی این مرحله لاجیک کامل برای تست متد Add رو پیاده سازی کنیم ). وقتی که برای عمل جمع متد تست مینویسیم، انتظار داریم که متد ما دو تا ورودی عددی رو به عنوان ورودی بگیره و مجموع این دو عدد رو توی خروجی برگردونه.

۲. اجرای تست و مشاهده خطا

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

۳. پیاده سازی ساختار امکانات مورد نظر

توی این مرحله ما ساختار برنامه خودمون رو آماده میکنیم. ( هنوز کاری با لاجیک برنامه نداریم. ) متد Add رو با دو ورودی عددی و همچنین خروجی عددی تعریف میکنیم.

۴. اجرای تست و مشاهده خطا

دوباره تست رو اجرا می‌کنیم. این دفعه خطایی که دریافت میکنیم مربوط به عدم تطبیق خروجی متد و مقدار مورد انتظار ما خواهد بود.

۵. پیاده سازی لاجیک

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

۶. مشاهده پاس شدن همه تست ها

بالاخره به بهترین بخش کار رسیدیم. جایی که تست های ما پاس شده و خطایی رو توی کنسول مشاهده نمیکنیم. حالا با اطمینان میتونیم برنامه خودمون رو به مشتری تحویل بدیم و خیالمون راحت باشه که مطمئنا برنامه به درستی کار میکنه.

به یاد داشته باشید که درصورت اعمال تغییرات نیاز داریم تا تمامی مراحل بالا رو دوباره روی برنامه اعمال کنیم.

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

برنامه نویسی تست محور (TDD) - قسمت اول

2020-01-19T12:08:00.000+03:30

اینکه بخوایم برنامه نویس خوبی باشیم کار ساده ای نیست و باید همواره دانش خودمون رو بروز کنیم و در رابطه با تکنولوژی های جدید مطالعه داشته باشیم، وگرنه از جامعه عقب میمونیم و کم کم از دور رقابت خارج میشیم. این بروز بودن فقط محدود به فریمورک ها و زبان های برنامه نویسی و بانک های اطلاعاتی نمیشه، ما باید درباره تکنیک های جدید برنامه نویسی هم مالعه داشته باشیم تا بتونیم کیفیت کار خودمون رو هم بالا ببریم. یکی از این تکنیک های جدید که کمک میکنه تا سرعت بیشتری در توسعه داشته باشیم و هزینه توسعه پایین بیاد، برنامه نویسی تست محور یا Test Driven Development هستش که در اختصار بهش TDD میگن.

تعریف برنامه نویسی تست محور

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

به بیان دیگر در برنامه نویسی تست محور ما ابتدا برای امکانات مورد نیاز خودمون تست مینویسیم و سپس کد مربوط به پاس کردن این تست ها توسعه داده میشه.

اهمیت تست ...

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

شش قانون در توسعه تست محور

میتونیم توسعه تست محور رو توی ۶ مرحله ساده زیر خلاصه کنیم:

نوشتن تست برای امکانات مورد نظر
اجرا کردن تست ها و مشاهده خطاهایی که دریافت میکنیم
پیاده سازی ساختار فیچر مورد نظر
اجرای مجدد تست ها و بررسی خطا های دریافتی
پیاده سازی لاجیک
بررسی پاس شدن تست های نوشته شده

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

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

پلاسکو در آتش سوخت...

2017-01-19T15:54:00.000+03:30

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

Dance Me to the End of Love ...

2016-11-11T21:30:00.000+03:30

RIP Leonard Cohen (1934 - 2016)

دسترسی به پورت های روی سرور از طریق SSH بر روی سیستم لوکال

2016-07-15T19:14:00.000+04:30

گاهی نیاز داریم به صورت مستقیم به پورتی از سرور لینوکسی بر روی سیستم لوکال دسترسی داشته باشیم. مثل وقتی که بخوایم به دیتابیس روی سرور دسترسی داشته باشیم. برای اینکار میتونیم به راحتی با استفاده از SSH پورت مورد نظرمون رو روی کامپیوتر لوکال فوروارد کنیم. برای اینکار از سوئیچ L بصورت زیر استفاده میکنیم.

ssh -L port:address:port host

که تو دستور بالا port اول پورت مورد نظر ما روی سیستم لوکال بوده و address:port آدرسی بر روی سرور هستش که میخواین بهش از طریق SSH دسترسی داشته باشیم.

نمایش رنگی خروجی grep در bash

2015-12-25T16:57:00.001+03:30

آپدیت: از دو روش زیر روش اول از grep ورژن 2.21 توصیه نمیشه و اگه از اون استفاده کنید با پیغام هشدار زیر روبرو میشوید.

grep: warning: GREP_OPTIONS is deprecated; please use an alias or script

یکی از سوئیچ هایی که موقع کار با grep خیلی به دردمون میخوره سوئیچ color هستش که مقدار جستجو رو بصورت رنگی نشون میده. ممکنه تو بعضی دیستروها این سوئیچ بطور پیش فرض ست نشده باشه و مجبور باشیم هر دفعه این سوئیچ رو تایپ کنیم.
برای اینکه این گزینه رو بطور پیش فرض داشته باشیم، میتونیم از یکی از دو روش زیر استفاده کنیم:

روش اول:

برای اینکار کافیه که متغیر GREP_OPTIONS رو ست کنیم و برای اینکه تو هر بار اجرای bash این متغیر ها ست بشن میتونیم اون رو تو فایل .bashrc خودمون ست کنیم.

export GREP_OPTIONS=" --color"

روش دوم:

راه دوم اینه که از alias ها استفاده کنیم. برای این موضوع میتونیم یک alias برای grep بصورت زیر تعریف کنیم و اون رو به فایل .bashrc خودمون اضافه کنیم:

alias grep='grep --color'

اتفاقات اخیر پاریس و مقایسه اون با عراق، سوریه، افغانستان و ...

2015-11-15T20:04:00.000+03:30

اول از هر چیز موضع خودم در رابطه با اتفاقات اخیر پاریس:

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

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

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

کوئری بر روی آیتم های فیلد از نوع آرایه در mongodb

2015-11-14T22:50:00.001+03:30

درصورتی که قصد داشته باشیم document هایی از یک collection خاص را براساس شرطی بر روی یکی از فیلد های از نوع آرایه ای آنها پیدا کنیم میتونیم از عبارت $elemMatch بصورت زیر استفاده کنیم:

مثال اول:

فرض میکنیم collection ما شامل موارد زیر باشد:

{ _id: 1, results: [ 82, 85, 88 ] }
{ _id: 2, results: [ 75, 88, 89 ] }

در این صورت برای پیدا کردن document هایی که قیلد result آنها دارای عدد ۸۸ است بصورت زیر عمل میکنیم:

db.collection.find({
    results: { $elemMatch: 88 }
})

همچنین میتوان از شرط های پیچیده تری استفاده نمود:

db.collection.find({
    results: {
        $elemMatch: { $gte: 80, $lt: 85 }
    }
})

مثال دوم (آیتم های آرایه از نوع آبجکت):

فرض میکنیم collection ما شامل موارد زیر باشد:

{ _id: 1, results: [ { product: "abc", score: 10 }, { product: "xyz", score: 5 } ] }
{ _id: 2, results: [ { product: "abc", score: 8 }, { product: "xyz", score: 7 } ] }
{ _id: 3, results: [ { product: "abc", score: 7 }, { product: "xyz", score: 8 } ] }

برای یافتن مواردی که در آنها product ی با مقدار score بزرگتر مساوی 8 باشد بصورت زیر عمل میکنیم:

db.collection.find({
    results: {
        $elemMatch: {
            product: "xyz",
            score: { $gte: 8 }
        }
    }
})

اتصال به یک سرور لینوکسی از طریق SSH بدون نیاز به رمز عبور

2015-10-09T21:53:00.000+03:30

ممکنه لازم باشه بطور روزمره به یه سرور ssh بزنیم. برای اینکار با دستور زیر میتونیم کلید عمومی خودمون رو به سرور اضافه کنیم تا موقع لاگین دیگه نیازی به رمز عبور نباشه:

$ ssh-copy-id user@server.example.com

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

$ ssh-copy-id -i ~/.ssh/id_dsa.pub user@server.example.com

یا برای ssh به پورتی غیر از پورت پیش فرض:

$ ssh-copy-id -i /path/key/file.pub "user@server.example.com -p PORT_NUMBER"

بروز رسانی: برای ماشین هایی که دستور ssh-copy-id رو پشتیبانی نمیکنند میتوان بصورت زیر عمل نمود:
cat ~/.ssh/id_rsa.pub | ssh user@machine "mkdir ~/.ssh; cat >> ~/.ssh/authorized_keys"

تغییر نام دیتابیس در MongoDB

2015-01-15T22:48:00.001+03:30

اگه تا بحال راجع به بانک های اطلاعاتی NoSQL شنیده باشید، حتما اسم MongoDB رو هم شنیدید. یک بانک اطلاعاتی Document Based که اطلاعات رو بصورت داکیومنت هایی به فرمت JSON ذخیره میکنه.

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

خوب یکی از مواردی که تو کار با MongoDB ممکنه بهش بر بخوریم تغییر نام یک دیتابیس هستش. از اونجایی که خود MongoDB (حداقل تا الان) دستوری رو برای این منظور نداره و باید برای اینکار بصورت دیگه ای عمل کنیم. که در ادامه به چند روش انجام این کار اشاره میکنم:

تغییر نام بوسیله کپی کردن بانک اطلاعاتی:

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

> db.copyDatabase('old_database', 'new_database')
> use old_database
> db.dropDatabase()

تغییر نام بوسیله Backup\Restore:

MongoDB برای Backup گیری از بانک ها و همچنین برگردوندن Backup ها دو تا دستور mongodump و mongorestore رو ارائه داده که میشه از اونها برای backup گیری از دیتابیس و برگردوندن backup با اسم جدید از اونها استفاده کرد. برای این منظور بصورت زیر عمل میکنیم:

mongodump --db old_database
mongorestore --db new_database /path/to/old_db_backup

پس از برگردوندن backup به سرور وصل میشیم و نسخه قدیمی رو با دستور dropDatabase پاک میکنیم:

mongo

> use old_database
> db.dropDatabase()

فعال سازی autoindent در ویرایشگر متن vi

2014-12-13T12:24:00.000+03:30

برای کسانی که با لینوکس کار میکنن و زیاد با محیط shell سر و کار دارند، vi یکی از ابزاریه که کار کردن با اون یکی از واجبات به حساب میاد. از ویرایش فایل های config گرفته تا کارهای سطح بالاتری مثل diff گرفتن بین دو فایل.این ادیتور امکانات زیادی رو در اختیار کاربر میزاره که کاربر با کانفیگ vi حتی میتونه از اون به عنوان یه IDE حرفه ای استفاده کنه.

یکی از امکاناتی که vi در اختیار کاربر میزاره indent گزاری خودکار هستش که معمولا بطور پیش فرض این گزینه غیر فعال هستش.(البته تا اونجایی که من باهاش برخورد داشتم) برای اینکه بتونیم این امکان رو فعال کنیم باید توی فایل .vimrc خودمون این امکان رو فعال کنیم. برای اینکار این خط رو به فایل تنظیمات خودمون اضافه میکنیم :

set autoindent

بعد از انجام این تنظیم vi بطور خودکار خط های جدید رو با indentation خط قبلی ایجاد میکنه که این امکان بخصوص موقع کدنویسی خیلی بکارمون میاد.

رفع مشکل نصب obfsproxy بر روی ubuntu

2014-11-14T21:32:00.004+03:30

چند وقت پیش که داشتم tor رو روی اوبونتو نصب میکردم، سراغ پروکسی گیج کننده (obfsproxy) هم رفتم. اما چون به یه خطایی خوردم بیخیالش شدم و با خود tor بدون استفاده از obfsproxy کار میکردم. تا اینکه امروز تنبلی رو کنار گذاشتم و با یه سرچ کوچیک توی اینترنت راه حل رفع مشکل نصب obfsproxy رو توی اوبونتو پیدا کردم.

برای اینکار، بعد از نصب tor باید بسته obfsproxy رو هم نصب کنیم:

sudo apt-get install tor
sudo apt-get install obfsproxy

حالا که بسته های مورد نیاز خودمون رو نصب کردیم باید تنظیمات tor رو انجام بدیم تا از obfsproxy استفاده کنه. برای اینکار فایل torrc خودمون رو ویرایش می‌کنیم:

sudo vi /etc/tor/torrc

تنظیمات زیر رو به انتهای این فایل اضافه میکنیم:

UseBridges 1
ClientTransportPlugin obfs2 exec /usr/bin/obfsproxy --managed 
ClientTransportPlugin obfs3 exec /usr/bin/obfsproxy --managed

در اینجا یه نکته ای وجود داره و اونم اینه که ممکنه که obfsproxy تو مسیر دیگه ای نصب شده باشه ( توی راهنماهایی که توی اینترنت وجود داشت معمولا در مسیر /usr/local/bin ) که باید با توجه به مسیر نصب روی سیستم خودتون مسیر های دو خط آخر رو اصلاح کنید.

حالا بعد از انجام تنظیمات بالا نیاز داریم تا یکسری bridge برای استفاده tor داشته باشیم که برای بدست آوردن جدید ترین bridge ها یک ایمیل به آدرس bridges@torproject.org میفرستیم و توی متن ایمیل مون از یکی از دستورات زیر با توجه به نوع bridgeی که لازم داریم، استفاده میکنیم:

جهت دریافت bridge های عادی:

get bridges

جهت دریافت bridge های بر پایه obfs2:

get transport obfs2

جهت دریافت bridge های بر پایه obfs3:

get transport obfs3

بعد از اینکه ایمیل درخواست خودمون رو ارسال کردیم، به فاصله چند لحظه یک ایمیل دریافت میکنیم که حاوی ۳ تا آدرس bridge از نوع مورد نظر ماست، این آدرس ها رو هم بصورت زیر در ادامه فایل تنظیمات اضافه میکنیم:

bridge [transport type] IP_ADDRESS:PORT [finger print]

بطور مثال برای bridge های عادی:

bridge 111.111.111.111:1111 21b87f4b3e43cce851344f0e85a24694b27d114b

و برای bridge های از نوع obfs2:

bridge obfs2 111.111.111.111:1111 21b87f4b3e43cce851344f0e85a24694b27d114b

حالا که تنظیمات خودمون رو انجام دادیم، فایل تنظیمات رو ذخیره میکنیم و سرویس tor رو دوباره راه اندازی میکنیم:

sudo service tor restart

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

tailf /var/log/tor/log

Nov 14 20:21:24.000 [notice] We now have enough directory information to build circuits.
Nov 14 20:21:24.000 [notice] Bootstrapped 80%: Connecting to the Tor network.
Nov 14 20:21:24.000 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Nov 14 20:21:31.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Nov 14 20:21:31.000 [notice] Bootstrapped 100%: Done.

خوب تا اینجا روش معمول راه اندازی bridge ها بر روی tor بود و اگه قرار نباشه از obfsproxy استفاده کنیم تا اینجا کارمون راه افتاده و میتونیم از tor استفاده کنیم.

اما اگه بخوایم از bridge های بر پایه obfsproxy استفاده کنیم موقع اجرای tor با خطای زیر روبرو میشیم:

Nov 14 19:56:34.000 [warn] We were supposed to connect to bridge '54.164.6.73:40872' using pluggable transport 'obfs3', but we can't find a pluggable transport proxy supporting 'obfs3'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.

این خطا به دلیل مشکلی پیش میاد که توی اسکریپت apparmor برای tor وجود داره و برای رفع اون باید فایل اسکریپت apparmor برای tor رو ویرایش کنیم:

sudo vi /etc/apparmor.d/system_tor

توی این فایل باید مسیر obfsproxy رو بصورت زیر اضافه کنیم:

/usr/bin/obfsproxy  Ux,

که فایل اسکریپت به صورت زیر تغییر میکنه:

# vim:syntax=apparmor
#include <tunables/global>

profile system_tor {
  #include <abstractions/tor>

  owner /var/lib/tor/** rwk,
  owner /var/log/tor/* w,

  /usr/bin/obfsproxy  Ux,  ## this is the FIX

  /{,var/}run/tor/control w,
  /{,var/}run/tor/tor.pid w,
  /{,var/}run/tor/control.authcookie w,
  /{,var/}run/tor/control.authcookie.tmp rw,

  # Site-specific additions and overrides. See local/README for details.
  #include <local/system_tor>
}

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

فعال کردن syntax highlighting در vi در ubuntu

2014-07-29T20:38:00.000+04:30

توی اوبونتو بطور پیش فرض یک نسخه minimal‌ از ادیتور vi نصبه و این نسخه خیلی از امکانات این ادیتور رو از جمله امکان syntax highlighting، پشتیبانی نمیکنه. حالا اگه میخواین که از این ادیتور با تمامی امکاناتش استفاده کنید باید نسخه کامل اون رو نصل کنید:

sudo apt-get install vim

بعد از نصب کافیه توی ادیتور با دستورات زیر این امکان رو فعال یا غیر فعال کنید:

:syntax on 

:syntax off

اگر هم میخواین که این امکان بصورت پیش فرض فعال باشه کافیه این دستور رو توی فایل .vimrc خودتون قرار بدین:

syntax on

فیشینگ اکانت گوگل

2014-07-13T23:03:00.002+04:30

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

متاسفانه یا خوشبختانه ماهی(ماحی) مورد نظر این مرتبه تو تور نیوفتاد...

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

تغییر مسیر پیش فرض ذخیره ماژول های bower

2014-07-04T04:53:00.002+04:30

چند وقت پیش با bower آشنا شدم، یه repository برای ماژول های جاوا اسکریپت که توسط توییتر ایجاد شده، ایده خوبیه و برای استفاده تو پروژه های وب خیلی بدرد میخوره و کلی کار آدم رو راه میندازه.

یکی از امکانات جالب bower اینه که میشه برای پروژه یک فایل کانفیگ به فرمت json به نام bower.json آماده کرد و بعد موقع نصب برنامه روی سرور با اجرای دستور bower install تمامی ماژول های جاوا اسکریپتی که مد نظر داریم رو برامون نصب میکنه.

بطور پیش فرض مسیری که bower ماژول ها رو توش نصب میکنه کنار فایل bower.json و تو یه پوشه به اسم bower_components قرار داره. ممکنه به هر دلیل بخوایم این مسیر پیش فرض رو عوض کنیم و ماژول ها رو تو یه مسیر دیگه نصب کنیم. برای اینکار باید کنار فایل bower.json‌ یه فایل دیگه به نام .bowerrc ایجاد کنیم و توی اون فایل که باز هم به فرمت json هستش مسیر خودمون رو به شکل زیر انتخاب کنیم:

{
    "directory" : "public/bower_components"
}

تو کد بالا من مسیر نصب رو به پوشه public/bower_components تغییر دادم.

اولین باگ کامپیوتری

2013-12-01T13:03:00.000+03:30

این تصویر مربوط به اولین باگ کامپیوتریه که در سال 1947 توی کامپیوتر Mark II که در دانشگاه هاروارد در حال تست بود پیدا شده. این باگ در حقیقت یک حشره بود که بین یکی از رله های این کامپیوتر گیر کرده بوده. اپراتور های این کامپیوتر این حشره رو به گزارششون چسبوندن و اون رو به عنوان اولین باگ کامپیوتری ریپورت کردن. این صفحه گزارش هنوز وجود داره و در حال حاضر توی موزه نگهداری میشه ...

منبع: ویکی پدیا

خسته نباشی مرد

2013-11-24T11:58:00.002+03:30

بالاخره تلاش های این چند وقته نتیجه داد و مذاکرات با موفقیت همراه شد، البته هنوز اول راهیم ...

به امید ادامه پیدا کردن این روند آشتی با جهان ...

@JZarif ممنون بابت زحمات این چند وقته، خسته نباشید ...

تست Syntax Highlighting

2013-11-06T09:57:00.000+03:30

console.log("Hello World!!!");

وب سایت شرکت پارس جنوبی

2013-09-29T14:32:00.000+03:30

چیزی که در زیر مشاهده میکنید صفحه نخست سایت شرکت معظم پارس جنوبیه:

دو تا نکته:

نکته اول اینکه چرا باید اطلاعات debug بصورت remote قابل مشاهده باشه، اونم تو سیستم عملیاتی و نه سیستم تست.
از اون مهمتر اینکه اصلا چرا فکری برای مشکل ساده ای مثل از دسترس خارج شدن دیتابیس نشده.

---

الان که دوباره چک کردم انگار دوستان متوجه مشکل شدن و یه Custom Error Page به سیستم اضافه کردن اونهم بهمراه غلط املایی: