احسان رضایی

یک توسعه دهنده، شاید هم نه.

تماس با من
me@dehohohohovelopithahahaha.ir

دست نوشته ها

دانشگاه یا موز!

(مطلب ثابت)

در ادامه مطلب " نقدی در مورد برخی اساتید "

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

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

ادامه...

این جماعت توسعه دهنده ی خرده گیر

به این نتیجه رسیدم توی برنامه نویسی دست رو هر چیزی بذاری(تکنولوژی، فریمورک و...) بازم پیدا میشن که بیان و یه عیبی روش بذارن :)

آیا واقعا جای عیب و ایراد گرفتن وجود داره؟ بله. حتما اینطور هست و اتفاقا کار آسونیه :)

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

موضوع دقیقا اینجا مشخص میشه. ممکن هست انتخاب یک شخص برای من نوعی و یا شخص دیگه ای سم باشه!

عمدتا 4 دلیل اصلی برای این موضوع وجود داره.

اول. بزرگ جلوه دادن خودشون!

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

دوم. سلیقه...

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

هیچ قانون سختگیرانه ای برای شما وجود نداره...

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

سوم. جبهه گرفتن.

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

چهارم. اطلاعات کهنه.

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

 

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

اما اگر به اون 4 دسته از توسعه دهندگان بالا برخوردین هدفونتون رو بذارید گوشتون و با هر چیزی که خوشحالتون میکنه کار کنید. از افرادی که این مسائل ساده رو درک نمیکنن نمیشه توقع ساکت شدن داشت.

تم روشن یا تیره؟ کدام برای چشم مفیدتر هست؟

شاید صرفا مربوط به فضای برنامه نویسی نباشه، در کل به دنبال این بودم که یک صفحه ی روشن با نوشته های تیره برای چشم مفیدتر هست یا نوشته های روشن با صفحه ای تیره؟ در ابتدا فرض رو بر این میگیریم که نور به اندازه کافی در اتاق وجود داره. از دهه 1980 تا الان مطالعات زیادی در این مورد انجام شده و هنوز هم به پایان نرسیده! یکی از اونها که مربوط به همون دهه اول هست میگه مطالعات به ما نشان دادند که متون تیره در یک صفحه/پس زمینه روشن بهتر از حالت دوم یعنی نوشته های روشن با صفحه ی تیره است. به عنوان مثال اونها متوجه شدن که شرکت کننده ها در این آزمایش 26 درصد دقیقتر متون رو مطالعه میکنن اگر نوشته ها تیره و صفحه روشن باشه.

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

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

چرا از framework استفاده میکنم؟

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

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

کامنت فارسی! کاچی به از هیچی

اولین بار زمانی که داخل کدهام فارسی کامنت گذاشتم توبیخ شدم اما به کارم ادامه دادم، به مرور باقی همکارانم همین کارُ انجام دادن. حالا داخل سورس هامون کمتر متدی پیدا میشه که توضیحات نداشته باشه. معمولا زمانی که توانایی لازم برای خواندن و نوشتن زبان انگلیسی رو نداشته باشیم نوشتن توضیحات برامون سخت و غیر قابل تحمل میشه. این کار شاید غیر استاندارد باشه اما چند خط کامنت فارسی یا حتی ناقص از نبودنش بهتره. میگم غیر استاندارده چون اکثر Editor و IDE ها به دلیل عدم پشتیبانی کامل از فارسی باعث میشن نوشته ها رو به طور غیر نرمال مثلا برعکس ببینیم! وگرنه سورس های زیادی رو دیدم که داخلشون به زبان های مختلفی کامنت گذاشته شده بود(روسی، چینی و...). نتیجه گیری از عنوان پیداست، توصیه میشه مهارت خواندن و نوشتن زبان انگلیسیتون رو تقویت کنید :)

‏احساس تعلق خاطر به محل کار

روز اولی که اومدم شرکت داشتن نیرو جذب می‌کردن. بعد از مدتی دیدم خیلی هوام‌ُ دارن و همه جور امکاناتی برام فراهم می‌کنن. می‌گفتم اینا چقدر دلسوز کارمنداشون هستن. تا اینکه موضوع تعدیل نیرو داغ شد و عده‌ای رو اخراج کردن.

‏اما خوشبختانه من موندم. رئیس شرکت می‌گفت متاسفیم اما مجبوریم. اون موقع من فهمیدم چقدر کودکانه فکر می‌کردم. همیشه موضوع منفعت هست. تاسف اون هیچ ارزشی برای کسایی که اخراج شدن نداشت. اون از روز اول هم برای کسی دلسوزی نمی‌کرد. برای اون چیزی که مهمه بازدهی بیشتر نیروهاش بود و هست.

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

ادامه...

آخرین مطالب وبلاگ

نوشتن کد غیر همزمان در PHP (معرفی کتابخانه)

async-execution

Event-driven, non-blocking I/O with PHP

ReactPHP is a low-level library for event-driven programming in PHP. At its core is an event loop, on top of which it provides low-level utilities, such as: Streams abstraction, async DNS resolver, network client/server, HTTP client/server and interaction with processes. Third-party libraries can use these components to create async network clients/servers and more

تفاوت بین Active Record و Data Mapper

هنگامی که موضوع کار با داده ها در application مطرح میشه احتمالا نیاز به یک ORM پیدا خواهید کرد. ORM یک لایه بین پایگاه داده و application شماست. که به وسیله اون عملیات CRUD یا به عبارت دیگه create, read, update,  delete به آسونی انجام میپذیره. بیشتر از این به ORM نمیپردازم چون در حال حاضر اکثر فریمورک های مدرن ازش استفاده میکنن و بعید میدونم شما تا الان با اون کار نکرده باشید.

دو الگو پیاده سازی محبوب ORM ها Active Record و Data Mapper هست. در این مقاله تصمیم دارم به تفاوت بین این دو الگو بپردازم. مزایا و معایبشون چی هست و چطور میشه یکی از این الگو ها رو برای کار خودمون انتخاب کنیم.

ادامه...

درس های yii2 شماره 25: ایجاد خودکار migration از روی پایگاه داده

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

برای این کار(ایجاد خودکار migration از روی پایگاه داده) در درجه اول نیاز به PHP >= 7.1 و Yii >= 2.0.15.1 دارید. داخل composer.json بسته bizley/migration رو اضافه و بروزرسانی کنید.

{
    "require": {
        "bizley/migration": "~3.0.0"
    }
}

برای PHP < 7.1 میتونید از نسخه ی 2.3.0 این بسته استفاده کنید.

{
    "require": {
        "bizley/migration": "~2.3.0"
    }
}

قدم بعدی پیکره بندی هست. ترجیحا داخل پیکره بندی console این کارُ انجام بدین.

'components' => [
    // ...
],
'controllerMap' => [
    'migration' => [
        'class' => 'bizley\migration\controllers\MigrationController',
    ],
],

 

ادامه...

مدل سازی داده و طراحی پایگاه داده چند زبانه

Multiple Languages

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

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

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

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

ادامه...

نامگذاری چیزها

معمولا توسعه دهنده زمان بیشتریُ برای خواندن کد نسبت به نوشتن اون صرف میکنه. این یه موضوع  مهمه که سورس خوانایی لازم رو داشته باشه. در ادامه بر اساس تجربه چند مورد برای نام گذاری آورده شده.

- مفهوم.

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

1) از نام های دقیق استفاده کنید.

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

2) اجتناب از نام های بی معنی.

نام هایی مثل i,j,k و... تنها زمانی قابل قبول هستن که در یک حلقه استفاده بشن. در باقی موارد خوانایی رو سخت میکنن.

معمولا توی کتاب های علوم کامپیوتر از این روش برای تعریف یک فرمول(با استفاده از شبه کد به منظور سریعتر نوشتن) استفاده میشه در صورتی که اگر پاراگراف بالای اون فرمول رو مطالعه نکنید چیزی ازش نخواهید فهمید.

3) نام کلاس ها، اینترفیس و پراپرتی ها.

نام کلاس میتونه شامل یک یا چند اسم باشه. از فعل نباید استفاده کرد. از “data”, “manager”, “info”, “processor”, “handler”, “maker”, “util” و موارد مشابه به علت مبهم بودنشون اجتناب کنید.

Interface ها معمولا اسم یا صفت هستن. میتونید از پیشوند (مثلا Interface) هم استفاده کنید.

namespace Psr\Log;

/**
 * Describes a logger instance
 */
interface LoggerInterface
{

property ها اسم یا صفت هستن. برای پراپرتی هایی با مقدار دودویی(0 یا 1) میشه از پسوند هایی مثل “Is”, “Can”یا “Has” در جاهای مناسب استفاده کرد.

نام Method باید شامل یک یا چند فعل باشه و کاری که انجام میده رو توضیح بده. نه اینکه چطور اون کار رو انجام میده.

ضروری نیست اما بهتره یک کلاس مشتق پسوند کلاس والد رو به همراه خودش داشته باشه.

 

 

class Exception {}

class InvalidArgumentException extends Exception {}
ادامه...

فهرستی از نکات امنیتی در PHP

php-security-checklist

- از php 7 یا نسخه های بالاتر استفاده کنید.

یا به عبارت دیگه همیشه از آخرین نسخه php استفاده کنید. کاملا مشخصه که در نسخه های جدیدتر، موارد امنیتی اضافه یا اصلاح و ویژگی های قدیمی و غیر قابل اطمینان دور ریخته میشن.

- تمام داده ها رو فیلتر و اعتبار سنجی کنید.

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

- استفاده از Whitelist به جای Blacklist.

به بیان ساده Blacklist یعنی فیلتر کردن موارد غیر قابل قبول! که به مراتب تعداد این موارد خیلی بیشتر از قابل قبول هاست. اصلا ممکنه نتونید همه رو توی این لیست جا بدین و چیزهایی از قلم بیوفتن. پس هرگز سعی نکنید لیست از مواردی داشته باشید که برای app شما غیر قابل قبول هست(Blacklist) و به جای اون Whitelist بسازید.

- strict typing

اگر از عملگر == برای مقایسه استفاده میکنید مراقب باشید که PHP به علت تبدیل عجیب و غریبی که انجام میده ممکنه اسکریپت شما رو آسیب پذیر کنه. مثلا عدد 1 برابر هست با رشته 1 و خود 1 یعنی true! و... .(Type Hinting)

 - از الگوریتم های امنیتی/رمزنگاری من درآوردی خودت استفاده نکن!

تاکید میکنم، انجامش ندین! حتی اگر شما یک متخصص امنیت هستید. این موضوع یکی از علت های رایج خطاهای امنیتی به حساب میاد. چون زمان کمی برای بررسی نیاز داره. در عوض از کتابخانه های عمومی، مطمئن و آزمایش شده برای کارتون استفاده کنید.

ادامه...