https://virgool.io/feed/@mehdi_apr برنامه‌نویس fa 2026-06-07 15:33:03 https://files.virgool.io/upload/users/1031/avatar/avatar.png?height=120&width=120 https://virgool.io/@mehdi_apr https://virgool.io/pullrequest/%D9%85%D9%82%D8%AF%D9%85%D9%87%D8%A7%DB%8C-%D8%A8%D8%B1-%D8%A7%DB%8C%D9%88%D9%86%D8%AA%D9%87%D8%A7-%D8%AF%D8%B1-%D9%84%D8%A7%D8%B1%D8%A7%D9%88%D9%84-tyytrwhrnggj یکی از امکانات خوبی که لاراول بعنوان یک فریمورک خفن در اختیار شما برنامه نویسان دون‌پایه قرار میده، امکان تعریف ایونت هست. ایونتها کلاسهای ساده ای هستند که با یک تعداد Listener (شنونده؟ گوش به زنگ؟) کار میکنن. ایونتها به شما کمک میکنن تا اکشنهای مختلف یک ماموریت خاص در یک پروژه رو از هم جدا کنید. یعنی چی؟ یعنی یک کاربر میاد و در اپلیکیشن شما ثبت نام میکنه، شما میخواهید یک ایمیل یا یک پیامک حاوی کد تایید بفرستید. تعریف ایونت به شما کمک میکنه که بتونید این عمل ارسال اس ام اس یا ایمیل رو از ماموریت اصلی اون تکه کد که همانا ثبت نام کاربره جدا کنید. در واقع شما یک ایونت به نام "ثبت نام کاربر" تعریف میکنید که کارش این است که اطلاعات اولیه کاربر رو در دیتابیس ذخیره کنه و منتظر تایید هویت اون آدم از طریق مثلا ارسال اس ام اس باشه. یک Listener هم برای این ایونت تعریف میکنید و بهش میگید آقا جان شما گوش به زنگ باش که هر موقع رویداد ثبت نام کاربر در سیستم اتفاق افتاد، براش یه کد رندوم جنریت کنی و بفرستی.حالا شاید بپرسید خب کد ارسال sms رو همونجا بیخ کد ثبت نام مینویسیم دیگه چه کاریه. اولا که بیاید سعی کنیم یک متد بیش از یک کار رو در اون لحظه انجام نده، چون کثیف کاری میشه، همه‌ی ما هم تجربه ی کد کثیف نوشتن رو داریم. دوما فرض کنید شما یک رویدادی در سیستم دارید که وقتی اتفاق میفته باید چندین پیامد دیگه داشته باشه. مثلا شما در یک فروشگاه اینترنتی یک سفارشی رو تایید میکنید و بنابراین باید برای کاربر ایمیل، اس ام اس و نوتیفکیشن ارسال بشه. طبیعتا هر کدام از اینها پیاده سازی منحصر به فرد خودشون رو دارن و منطقی نیست همه چیز رو بیخ هم قرار بدیم. پس بهتره یک ایونت تایید سفارش ایجاد کنیم و چند listener مختلف براش تعریف کنیم تا هر کدوم گوش به زنگ باشن که اگر رویداد تایید سفارش اتفاق افتاد، هر کدوم ماموریت خودشون رو انجام بدن.پس اگر تا اینجا موافقید که استفاده از ایونت ها کار خوبیه، در ادامه نگاهی بندازیم به اینکه چطور باید ایونت ها رو ثبت کرد.برای ثبت ایونتها و Listener ها، شما باید فایل EventServiceProvider.php رو از مسیر app/Providers باز کنید و اونجا در داخل آرایه‌ی listen$ مسیر تمام ایونت ها و listener های خودتون رو بنویسید:protected $listen = [ 'App\Events\OrderApproved' => [ 'App\Listeners\SendOrderApprovementNotifications', ], ];شما میتونید هر چند تا ایونت و به ازای هر کدوم هر چند تا listener که خواستید رو بالا در قالب آرایه تعریف کنید. حالا باید دستور پایین رو در ترمینال و در مسیر اصلی پروژه بزنید تا دایرکتوری های ایونت ها و listener ها ساخته بشن و همینطور فایلها ایجاد و به این دایرکتوریها اضافه بشن. توضیح اینکه لاراول به صورت پیشفرض دایرکتوری های Events و Listeners رو نداره و بعد از اجرای دستور زیر اونها ایجاد میشن:➜ ~ php artisan event:generateموقعی که دستور بالا رو اجرا کنید، فایل OrderApproved.php در مسیر app/Events و فایل SendOrderApprovementNotifications.php در مسیر app/Listeners ایجاد میشن. اگر فایلها رو باز کنید و نگاهی به داخلشون بندازید میبینید که لاراول زحمت شما رو کم کرده و namespace ها و کلاسهای مرتبط رو خودش برای شما تولید کرده. بدون درد و خونریزی.هر بار که دستور فوق رو در ترمینال اجرا کنید، لاراول یه نگاه به فایل EventServiceProvider.php میندازه. اگر ایونت یا listener جدیدی به آرایه اضافه شده باشه اونها رو برای شما ایجاد میکنه.فایل ایونت: <?php namespace App\Events; use Illuminate\Broadcasting\Channel; use Illuminate\Queue\SerializesModels; use Illuminate\Broadcasting\PrivateChannel; use Illuminate\Broadcasting\PresenceChannel; use Illuminate\Foundation\Events\Dispatchable; use Illuminate\Broadcasting\InteractsWithSockets; use Illuminate\Contracts\Broadcasting\ShouldBroadcast; class OrderApproved { use Dispatchable, InteractsWithSockets, SerializesModels; /** * Create a new event instance. * * @return void */ public function __construct() { // } /** * Get the channels the event should broadcast on. * * @return \Illuminate\Broadcasting\Channel|array */ public function broadcastOn() { return new PrivateChannel('channel-name'); } }فایل Listener:<?php namespace App\Listeners; use App\Events\OrderApproved; use Illuminate\Queue\InteractsWithQueue; use Illuminate\Contracts\Queue\ShouldQueue; class SendOrderApprovementNotifications { /** * Create the event listener. * * @return void */ public function __construct() { // } /** * Handle the event. * * @param OrderApproved $event * @return void */ public function handle(OrderApproved $event) { // } }برای اینکه یک ایونت رو هم به همراه listener هاش اجرا کنید کافیه یک خط کد بنویسید در هر جایی که نیازی به اجرای ایونت داشتید:event(new OrderApproved());در مقاله‌ی بعدی در مورد صف ها و اینکه چطور میتونید ایونتهاتون رو برای اجرا در زمانهای مشخص صف بندی کنید خواهم نوشت. مهدی علیپور مهدی علیپور Sat, 29 Dec 2018 23:44:10 +0330 https://virgool.io/@mehdi_apr/%D9%85%D8%B2%D8%A7%DB%8C%D8%A7-%D9%88-%D9%85%D8%B9%D8%A7%DB%8C%D8%A8-%D8%AF%D9%88%D8%B1-%DA%A9%D8%A7%D8%B1%DB%8C-%D8%AE%D9%88%D8%A8-%D8%A8%D8%AF-%D8%B2%D8%B4%D8%AA-hprat4go063x بعنوان اولین نوشته در ویرگول، تصمیم گرفتم از چالش‌های کار ریموت یا دورکاری بنویسم. بعنوان یه دولوپر، از حدود یه سال پیش شرایطی برام فراهم شد که بتونم بصورت ریموت با شرکتهایی در تهران کار کنم. کار ریموت چالش‌هایی داره که ممکنه منجر به پیشرفت شما بشه یا شما رو از پا دربیاره. این عوامل چیا هستن؟ بذارید یکی یکی بررسی کنیم:۱- فرهنگ دورکاریاین یه مساله دوطرفه‌ست. شما بعنوان یه نیروی ریموت باید در نظر داشته باشید که دورکاری با فریلنسری تفاوتهای عمده ای داره. در واقع شما اگه با این ایده که "ساعت کاریم دست خودمه و هر موقع دلم بخواد کار میکنم" وارد ماجرا بشید احتمالا به مشکلات زیادی برمیخورید. نیروی ریموت کسیه که صرفا حضور فیزیکی در محل کار نداره و باید مثل نیروهای حضوری، به وقت و ساعت کاری پایبند باشه و در ساعتهای کاری با اعضای تیمش و مدیرانش در ارتباط باشه. برخلاف فریلنسری، این خود شما نیستید که ساعت کاری یا مسیر پروژه یا هر چیز دیگه ای رو کنترل یا تعیین میکنید، بلکه شما بعنوان یه کارمند موظف هستین به مقررات سازمان یا شرکتی که براش کار میکنید پایبند باشید. طرف دوم ماجرا شرکت یا سازمانیه که نیروی ریموت استخدام میکنه. متاسفانه اغلب شرکتها نیروی ریموت رو با نیرویی که ساعت سه نصف شب هم بتونن بکشوننش پای کار اشتباه میگیرن. سازمانی که نیروی ریموت استخدام میکنه باید این واقعیت رو در نظر داشته باشه که نیاز به تعامل بیشتری با اون شخص داره و به نوعی باید حمایت بیشتری ازش بکنه و تلاش کنه حس کارمند واقعی بودن رو بهش بده. اگه نیروی ریموت استخدام میکنید، به امان خدا رهاش نکنید. باهاش در ارتباط باشید و از مشکلاتش بپرسید، جلسات منظم اسکایپی باهاش برقرار کنید و کارمندتون رو در جریان تغییر ایده‌ها و فرهنگ سازمان قرار بدین. اگر جلسه ای با کارمندان حضوری یا بین کارمندان حضوری برگزار میکنید، برقراری ارتباط اسکایپی (یا هر چیزی)‌ با کارمند ریموت رو جزو "بایدها" قرار بدین و این ایده که "حالا نتیجه جلسه رو تو اسلک بهش میگیم" رو از سرتون بیرون کنید.۲- محل کاراگر دارید دورکاری میکنید باید ایده‌ی تو خونه کار کردن رو از سرتون بیرون کنید. ساده بگم: تو خونه نمیشه کار کرد. مگر اینکه مطلقا مجرد باشید. یعنی نه تنها متاهل نباشید بلکه آدمی نباشید که با توی خونه موندن شما رو درگیر مسائل خونه از جمله نون خریدن، تعویض لامپ سرویس بهداشتی و پذیرایی از مهمونها بکنن. اگر در شهرتون دسترسی به فضای کار اشتراکی دارید، حتمن ازش استفاده کنید و اگر نه، حتمن دنبال یه محل کار مناسب بگردید. مشکلی که من با اجاره دفتر و شریک شدن با دوستانم حلش کردم. ممکنه هزینه دفتر در ابتدا براتون سنگین به نظر بیاد، ولی اولا سعی کنید به صورت شراکتی این کار رو انجام بدین و دوما بدونید که تو خونه امکان کار کردن نیست و بازدهی شما و طبیعتا درآمدتون به شدت پایین میاد.۳- محاسبه زمان کارفرهنگی که در حال حاضر برای حقوق و مزایای افرادی که دورکاری میکنن (حداقل در حوزه آی تی و طبق تجربیات من) وجود داره، محاسبه حقوق بر اساس ساعت کاری است. من شخصا با این سیستم راحتم و برای محاسبه ساعت کاریم، از اپلیکیشن Toggl استفاده میکنم که امکان تعریف پروژه های متعدد و محاسبه ساعت کاری پروژه ها بصورت مجزا رو داره. اصلی‌ترین و دراماتیک ترین و اخلاقی‌ترین بحثی که این وسط وجود داره اینه که اگه من از سر میزم پاشم برم دستشویی، باید زمان کاری رو استاپ کنم؟ جواب من اینه:‌ نه! یه برنامه نویس کارش فقط کد نوشتن نیست. خیلی از وقت ما به فکر کردن برای پیدا کردن راه حل، جستجو کردن، دیباگ کردن و ... میگذره. اگه بخواید اینا رو حساب نکنید، احتمالا کار شما روزی بیشتر از ۲ ساعت نمیشه که طبعا این غلطه. ایده من اینه که از وقتی که پشت میز استارت کار رو میزنیم تا وقتی که کار روزانه تموم میشه و میتونیم بصورت کامل پروژه و کارفرما و ... رو موقتا از ذهنمون بیرون کنیم ساعت کاری محسوب میشه. من گاهی حتی غذا رو هم پشت لپتاپ میخورم و همزمان احتمالا به راه حلی که باید برای انجام تسک بهش برسم فکر میکنم. پس نمیتونم این زمان رو استاپ کنم چون همین ناهار خوردن هم با کار کردنم تلفیق شده و قابل تفکیک نیست. البته ممکنه برای شما چالش اخلاقی در این موارد پیش بیاد که من در کامنتها ازش استقبال میکنم.۴- رشد فردییکی از آفتهای دورکاری، دور بودن از محیط کاریه که احتمالا اتفاقات خوب و هیجان انگیزی توش میفته. دور بودن از همکاران، باعث میشه شما به این سادگی نتونید باهاشون در تعامل باشید و ازشون چیزهایی رو یاد بگیرید. پارسال که من بصورت کوتاه در یک شرکتی بصورت نیروی ریموت کار میکردم، بهترین روزهای کاریم روزهایی بود که به تهران میرفتم و از نزدیک با همکارام در ارتباط بودم. این باعث میشد چیزهای زیادی یاد بگیرم، چیزهایی که موقع تنهایی کار کردن بهش نمیرسیدم. پس همیشه این رو در نظر بگیرید که ریموت کار کردن میتونه باعث بشه به شدت در جا بزنید، حتمن باید رشد فردی خودتون رو در نظر بگیرید و از تحقیق و یادگیری غافل نشید. به عقیده من اصلی ترین معضل دورکاری همینه، سکون.۵- شخصیت فردیدورکاری برای یه آدم درونگرا بسیار سخته، کار ریموت می‌طلبه که شما دائما با یه سری افراد در ارتباط باشید و بصورت تلفنی یا تصویری باهاشون ارتباط بگیرید. اگه آدمی هستید که ترجیح میدین اورست رو فتح کنین ولی جواب تلفن رو ندین، دورکاری براتون اصلا مناسب نیست. سعی کنید (سعی کنیم، چون خودمم تلفنوفوبیا دارم!) این وجه از شخصیتتون رو تغییر بدین و تعامل مناسبی برقرار کنید.توصیه پایانی:نویز بفرستید، اگر نیروی ریموت هستید همیشه سیگنالهایی برای تیمی که باهاش کار میکنید بفرستید. حضورتون رو بعنوان یه نیروی رسمی همیشه ثابت کنید. در غیر اینصورت روابطتون با تیم رفته رفته کمرنگ میشه، کمتر روی شما حساب میکنن، در ذهن کسایی که باهاشون کار میکنید کمرنگ‌تر میشین و رفته رفته کار کردن براتون سخت تر میشه، چون به تدریج نادیده گرفته میشین و از خیلی چیزها بی‌خبر می‌مونید و دچار چالشهای زیادی میشین. پس نویز بفرستید، حتی اگه کار خاصی باهاشون ندارین! مهدی علیپور مهدی علیپور Sat, 31 Mar 2018 15:10:13 +0430