نوشته های علی اصغر صنیعی فر

از Vue به React: وقتی یک انتخاب خوب، جای خودش را به یک استراتژی بهتر می‌دهد

علی اصغر صنیعی فر — Tue, 12 Aug 2025 12:56:11 +0330

سال‌ها با Vue ساختیم و رشد کردیم. سرعت شروع بالا، منحنی یادگیری ملایم، مستندات دوست‌داشتنی و جامعه‌ی گرم—این‌ها دلایلی بودند که باعث شدند خیلی از پنل‌های مدیریت و SPAهای ما با Vue ساخته شوند. هنوز هم Vue فریم‌ورکی توانمند است و پروژه‌های زیادی را با کیفیت بالا جلو می‌برد.اما تصمیم اخیر ما برای حرکت به سمت React یک تصمیم هیجانی نیست؛ یک استراتژی است—بر پایه‌ی داده‌های بازار، مسیر اکوسیستم‌ها و نیازهای استخدامی امروز.چرا «الان» زمان جابه‌جایی است؟1) سهم استفاده و تقاضای جهانیطبق Stack Overflow Developer Survey 2024، بین فناوری‌های وب، React حدود 39.5٪ از پاسخ‌دهندگان را به خود اختصاص داده، در حالی‌که Vue حدود 15.4٪ گزارش شده است. در همان مجموعه داده‌ها، React و Vue هر دو در جمع «فناوری‌های مطلوب برای ادامه‌دادن» قرار دارند، اما پراکندگی استفاده‌ی فعال به‌وضوح به نفع React است. در State of JS 2024 نیز، React همچنان ابزار غالب محیط کار است (بالاترین تعداد استفاده در محیط حرفه‌ای)، و Vue با تثبیت جایگاه شماره‌ی ۲ نشان می‌دهد محبوبیتش پایدار است—اما فاصله‌ی «وسعت استفاده» همچنان به نفع React باقی مانده است. (React در محل کار: 8,548 پاسخ؛ Vue: 3,976 پاسخ). برداشت عملی: اگر به بازار بین‌المللی فکر می‌کنید (استخدام، برون‌سپاری، همکاری بین‌تیمی)، احتمال اینکه تیم‌های بالقوه و همکاران آینده‌تان با React کار کنند به‌طور معناداری بیشتر است.2) مزیت‌های اکوسیستم و ابزارهای پیرامونیNext.js عملاً به «استاندارد طلایی» SSR/SSG در دنیای React تبدیل شده و برای SEO، عملکرد، و DX مسیرهای بالغی ارائه می‌دهد. هم‌زمان، گستره‌ی کتابخانه‌ها، ابزارهای تست، و راهکارهای UI در جهان React به‌شدت متنوع و بالغ است؛ این یعنی برای اکثر نیازهای رایج، راه‌حل‌های battle‑tested آماده دارید. نشانه‌ی این بلوغ را در داده‌های مقایسه‌ای Stack Overflow می‌بینیم که React در کنار Node.js و Next.js جزو صدرنشین‌های «کار کرده‌ام/می‌خواهم کار کنم» است. 3) واقعیت اکوسیستم لاراولدر دنیای Laravel، هر دو مسیر به رسمیت شناخته شده‌اند: • Laravel Breeze به‌صورت رسمی Inertia را هم با React و هم با Vue ارائه می‌کند؛ یعنی از روز اول می‌توانید اسکلت‌بندی React+Inertia دریافت کنید. • خود Inertia.js رسماً آداپترهای React و Vue را نگه‌داری می‌کند؛ پس از منظر ابزار «چسب بین بک‌اند و فرانت‌اند»، هر دو مسیر first‑class citizen هستند.برداشت عملی: اگر قبلاً با Inertia کار کرده‌اید، مهاجرت تدریجی صفحات و لایه‌ی UI از Vue به React بدون تغییرات بنیادین در معماری بک‌اند ممکن است.4) هم‌راستایی با جامعه‌ی جهانی استخدامحتی اگر جامعه‌ی لاراول به‌طور تاریخی گرایش بیشتری به Vue نشان داده باشد، روندها نشان می‌دهد React در این جامعه نیز در حال رشد است. (دعوت به نظرسنجی ۲۰۲۴ لاراول نیوز: «Vue همچنان گزینه‌ی غالب است، اما انتظار رشد React می‌رود.») برای تیمی که افق بین‌المللی دارد، سرمایه‌گذاری روی مهارتی که هم در دنیای جاوااسکریپت و هم در مزرهای فریم‌ورک‌های فول‌استک (Next.js، Remix، …) موقعیت‌های بیشتری خلق می‌کند، منطقی است. واقعیت هایی که نمی توان با سادگی از کنار آن گذشت 1. قابلیت جذب نیرو و همکاری جهانی: اختلاف معنادار در استفاده‌ی واقعی (39.5% در مقابل 15.4%) به معنی مخزن بزرگ‌تر استعداد و منابع آموزشی/ابزاری در React است. 2. مجموعه ابزارهای پیرامونی بالغ‌تر: از Next.js تا کتابخانه‌های UI و ابزارهای تست؛ سرعت انتخاب راه‌حل استاندارد در React معمولاً بالاتر است. 3. مسیر مهاجرت کم‌ریسک در لاراول: با Inertia و اسکلت‌های رسمی Breeze، می‌توانیم تدریجی و کنترل‌شده حرکت کنیم. جمع‌بندیVue ما را به‌خوبی این‌جا رساند و همچنان برای خیلی از تیم‌ها انتخابی عالی است. اما برای تیمی که می‌خواهد در بازار جهانی حضور پررنگ‌تری داشته باشد، تیم بزرگ‌تر و متنوع‌تری جذب کند و از اکوسیستم‌های بالغ پیرامون بهره‌ی بیش‌تری ببرد، حرکت به React یک تصمیم استراتژیک است—نه صرفاً یک سلیقه‌ی تکنیکی.

۷ دلیل اصلی شکست تیم های برنامه نویس

علی اصغر صنیعی فر — Sun, 26 Feb 2023 15:03:07 +0330

وقتی یک تیم توسعه شکست می خورد، می تواند دلایل متعددی داشته باشد از جمله مسائل فنی، فردی و سازمانی. در ادامه، برخی از دلایل شکست اعضای تیم را مورد بحث قرار خواهیم داد:1- مدیریت پروژه: یکی از دلایل شکست تیم های پروژه، شکست مدیریت پروژه است. اگر مدیریت پروژه به درستی انجام نشود، پروژه می تواند منجر به مشکلات عدیده ای مانند درگیری های درون تیمی، نارضایتی مشتریان و مشکلات مالی شود.۲- ناتوانی در مدیریت زمان: مدیریت زمان یکی از بزرگترین مشکلاتی است که تیم ها با آن مواجه هستند. اگر برنامه ریزی و مدیریت زمان به درستی انجام نشود، می تواند به مسائلی مانند تاخیر در تحویل پروژه، جریمه یا از دست دادن مشتریان برای سازمان منجر گردد.3- ناتوانی در حل مشکلات فنی: یکی دیگر از دلایل شکست تیم ها عدم توانایی در حل مشکلات فنی است. اگر تیم برنامه نتواند مشکلات فنی را به سرعت و کارآمد حل کند، مشکلات فنی روی کل پروژه تأثیر می گذارد.4- عدم هماهنگی و همکاری درون تیمی: برای موفقیت در برنامه، اعضای تیم باید به خوبی سازماندهی شده و همکاری خوبی در درون تیم به وجود آید. اگر اعضای تیم بتوانند به خوبی با یکدیگر هماهنگ شود و رابطه خوبی با یکدیگر داشته باشند، شکست نخواهند خورد و برنامه کاری را تکمیل کرده و به خوبی پیشرفت می کنند.5- فرهنگ سازمانی نامناسب: فرهنگ سازمانی یکی دیگر از عواملی است که باعث شکست یک تیم می شود. اگر سازمان نتواند فرهنگ مناسبی را برای پروژه جاری ایجاد کند، ممکن است مشکلاتی مانند عدم همکاری اعضا، ناتوانی در مدیریت پروژه و یا نارضایتی مشتریان ایجاد شود.6- نوآوری نکردن: یکی دیگر از دلایل شکست یک برنامه، عدم نوآوری است. اگر تیم نتواند با ابزار جدید و ایده های جدید در کار فعلی کنار بیاید، به راحتی بازار و مشتری های خود را از دست خواهد داد.در نهایت، برنامه نویسی موفق مستلزم داشتن برنامه ریزی مناسب، مدیریت پروژه، سازماندهی و همکاری درون تیمی، حل مشکلات فنی و نوآوری است.

راستی آزمایی فنی یا Technical due diligence قسمت اول

علی اصغر صنیعی فر — Tue, 09 Nov 2021 10:03:12 +0330

حوالی ساعت ۱۰ صبح بود که یکی از دوستانم که مسئول راستی آزمایی یکی از شرکت های سرمایه گذاریه با من تماس گرفت و در رابطه با راستی آزمایی فنی دو تا از شرکت هایی که قصد سرمایه گذاری بر روی آنها رو داشتند با من صحبت کرد.برای من تجربه جدیدی بود اولا خوشحال بودم که یکی از شرکت های سرمایه گذاری من رو در این حد دیده که برای این کار انتخابم کنه و بحث دیگه هم تجربه جدید برای یک مهندس نرم افزار تا دانش خودش رو در رابطه با این حوزه زیاد بکنه.مسلما مثل همه اولین کاری که کردم جستجو بود و با کمال تعجب دیدم که هیچ استاندارد رسمی برای این کار وجود ندارد و اکثر شرکت های بزرگ دنیا بر اساس تجربه سازمان و مسلما نوع نرم افزاری که قصد سرمایه گذاری بر روی اون رو داشتند این کار رو انجام می دهند و در کل اطلاعات بسیار کمی در رابطه با این مسئله وجود داره.در رابطه با شرکت های استارت آپی ایرانی (و کلا هر منطقه ای) باز هم میشه یک سری استاندارد ها رو بر اساس فرهنگ درست یا غلط برنامه نویس های اون منطقه (اون هم بر اساس تجربه) پیدا کرد. مثلا در بسیاری از شرکت های ایرانی (البته در این مورد خاص در بیشتر استارت آپ های دنیا) تقریبا تا زمانی که مجبور نباشند از TDD استفاده نمی کنند. که البته میشه گفت از یک طرف برای افزایش سرعت رسیدن به هدف خوب و از طرفی هم ناکفی بودن تست در پروژه بسیار بد ارزیابی کرد.پس تا اینجا دو تا نتیجه گیری کردم که اولا هیچ سندی(Document) برای راستی آزمایی در حوزه فنی به صورت رسمی وجود نداره و دوم در رابطه با مسائل فنی نباید همه چیز رو به صورت صفر و یکی در نظر گرفت. یعنی باید درک درستی از ماهیت استارت آپ و سایر موارد وابسته به اون انجام داد.همین مسئله باعث شد تا سعی کنم همون اندک موارد موجود که شامل یک سری document و یک سری کنفرانس ویدیویی بود رو مرتب منظم کنم و در قالب یک سند برای خودم ایجاد کنم و سعی کنم هر چند وقت یکبار این سند رو به روز آوری کنم.در قسمت های بعدی در رابطه با جنس سوال ها و مصاحبه با CTO شرکت ها، تجربیاتم را با شما به اشتراک می گذارم به امید اینکه این تجربه برای شما مفید بوده باشه.

چگونه نقد کردن برای یک برنامه نویس!

علی اصغر صنیعی فر — Tue, 03 Nov 2020 11:56:41 +0330

هیچ کس در هیچ جای این کره خاکی نمی تواند ادعا کند که یک برنامه نویس تمام عیار است. خیلی از ما شاید بعد از سالها برنامه نویسی هنوز به علت گستردگی موارد و ظهور و سقوط زود به زود تکنولوژی نمی توانیم ادعا کنیم که همه چی را می دانیم. صادقانه بگویم نه عمر ما کفاف می دهد و نه سرعت پیشرفت این اجازه را به ما می دهد. همه ما در حدی کار را بلد هستیم که بتوانیم مسائل خود را حل کنیم و پروژه ای را که در دست داریم به جلو ببریم.مطمئنا خیلی از شما دوستان من هم بعد از مدتی که پروژه ها و کدهای قبلی خود نگاه می کنید به عمق فاجعه پی می برید که کجا بوده اید و الان کجا هستید.شاید علت اصلی این نوشته این است که بعضا در زمان های مختلف در سایت ها و شبکه های اجتماعی بسیاری از دوستانی که اندک زمانی است برنامه نویسی را شروع کرده اند شروع به نقد های برنامه نویسان و یا شرکت هایی می کنند که سالهاست در حال تلاش هستند.به اینکه آیا نقد صحیح است یا خیر اصلا کاری ندارم. مسلما ممکن است کسی که نقد می کند و ایرادی را گوش زد می کند به مورد صحیحی اشاره کند ولی اینکه آیا کسی اجازه دارد که به تیمی توهین کند یا به تمسخر بپردازد؟ شخضا فکر نمی کنم از هیچ جنبه ای درست باشد.هم برای شما و هم برای بنده پیش آمده است که عضوی از گروه که شاید از لحاظ تجربه، در سطح پایینی قرار داشته باشد به کدها ایرادی گرفته، که از چشم برنامه نویسان ارشد به دور بوده است و این طبیعی است که هر کسی در هر سطحی اشتباه کند و یا مطلبی را نداند ولی رویکرد و نوع بیان با طعنه زدن و یا فحاشی کردن مسئله را به گونه ای دیگر جلو می برد.اما چگونه نقد کنیم؟من در حال حاضر یک برنامه نویس Php هستم ولی سالها با انواع زبانهای برنامه نویسی کار کرده ام. با Python اطلاعات سایتهای مختلف را استخراج کردم و در حوضه IOT برنامه نویسی کردم . با Swift و Objective C برای iOS و با Flutter برای اندروید برنامه نویسی کرده ام ولی در حال حاضر فقط و فقط خود را برنامه نویس Php و آن هم کتابخانه Laravel می دانم. نمی گویم تجربه بسیار دارم و بسیار کار کشته ام. خیر! ولی بر اساس مطالبی که خوانده ام و اندک تجربه ای که دارم سعی می کنم همانند نمونه زیر نقد کنمنقد بد ( از نمونه واقعی ) :برای این کار می تونید از Rail استفاده کنید ، چون express آشغاله و همه هم می دونند که هیچ معماری نداره فقط چون سادست و کار را بندازه انقدر طرفدار دارهنقد بهتر از نگاه من:چرا از express استفاده کردید. اگر پروژه شما بزرگ شود مطمئنا سیستم middle ware و routing در Rail بسیار راحت تر است. شاید در مراحل اول به راحتی express نباشد ولی در نهایت در پروژه بزرگتر مدیریت را راحتر می کند.به اینکه آیا اساس آیا این نقد در رابطه با express درست است یا خیر کاری ندارم ولی همانطور که می بیند در نقد باید علت را جویا بشوید و سپس پیشنهاد خود را اعلام کنید. مسلما هیچ یک از ما نمی توانید یک کتابخانه را آشغال بنامیم در حالی که جمعیت بسیار زیادی در سطوح مختلف از آن استفاده می کنند پس هیچ وقت نباید یک طرفه به میدان رفت.باید برای نقد خود پیشنهاد بدهید و سعی کنید به منابعی رجوع کنید که در نهایت باعث پیشرفت شود در غیر اینصورت جز کدورت و ناراحتی هیچ ثمره ای ندارد حتی اگر نقد درست باشد.باید لهن گفتار پسندیده باشد و یا در صورتی که به صورت نوشتار است از emoji استفاده شود که جنبه نقد برای کسی که مورد نقد قرار می گیرد لحن دوستانه ای به نظر آید.در نقد ما اگر هدف خراب کردن نباشد مسلما پیشنهادی در جهت بهبود کار است پس چه بهتر هنگام نقد و قبل از اعلام آن برای چند لحظه خود را به جای طرف مقابل قرار دهیم و ببنیم آیا اگر جای او بودیم این نوع جمله بندی چه تاثیری بر روی ما می گذاشت.می دانم در این رابطه می شود ساعت ها بحث کرد ولی بالاخره از جایی باید شروع کرد. امیدوارم که این مقاله کمکی باشد برای اینکه بهتر نقد کنیم و باعث ناراحتی کسی نشویم.لینک تصویر پست : https://bit.ly/2TPiKEQ

ایجاد دیتابیس Mysql جدا جهت تست در لاراول

علی اصغر صنیعی فر — Sun, 01 Nov 2020 12:38:49 +0330

شاید شما هم جز کسانی باشید که بعضی وقت ها یا شاید هم همیشه برای برنامه هایی که ایجاد می کنید تست می نویسید. اگر اینگونه است پس به ادامه این مقاله توجه بفرمایید.قبل از شروع مشخصات سیستمی که کد های زیر بر روی آن کار می کند و شما شاهد نمونه کدهای آن هستید به این شرح است:سیستم عامل:10.15.7 mac os پی اچ پی : 7.4.10لاراول :8.11.2مراحل را قدم به قدم جلو می رویم:مرحله ۱ :در مسیر config/database.php کدهای جدیدی را برای محیط تست ایحاد می کنیم ( از قسمت شروع تا پایان) 'connections' => [ 'sqlite_testing_db' => [ 'driver' => 'sqlite', 'database' => storage_path().'/testing_database.sqlite', 'prefix' => '', ], /**************** شروع ******************/ 'testing_db' => [ 'driver' => 'mysql', 'host' => env('TEST_DB_HOST', 'localhost'), 'database' => env('TEST_DB_DATABASE', 'forge'), 'username' => env('TEST_DB_USERNAME', 'forge'), 'password' => env('TEST_DB_PASSWORD', ''), 'charset' => 'utf8', 'collation' => 'utf8_unicode_ci', 'prefix' => '', 'strict' => false, ], /**************** پایان ******************/ /** Production or database DB **/ 'db' => [ 'driver' => 'mysql', 'host' => env('TEST_DB_HOST', 'localhost'), 'database' => env('TEST_DB_DATABASE', 'forge'), 'username' => env('TEST_DB_USERNAME', 'forge'), 'password' => env('TEST_DB_PASSWORD', ''), 'charset' => 'utf8', 'collation' => 'utf8_unicode_ci', 'prefix' => '', 'strict' => false, ], ], ]; مرحله ۲:در فایل .env کد های زیر را اضافه کنید ( البته نام کاربری و کلمه عبور mysql خود را قرار دهید و دقت کنید که نام دیتا بیس تست را هم درست قرار دهید و قبلا آن را ایجاد کرده باشید.)TEST_DB_HOST=localhost TEST_DB_DATABASE=laravel TEST_DB_USERNAME=root TEST_DB_PASSWORD=rootمرحله ۳:در فایل phpunit.xml کد زیر را اضافه کنید:( بین شروع و پایان) /**************** شروع ******************/ /**************** پایان ******************/ مرحله ۴ :کد artisan زیر را اجرا کنید تا دیتا بیس شما آماده شودphp artisan migrate --database=testing_dbاز دفعات دیگر دیتا بیس شما جهت تست از دیتا بیس اصلی شما جدا است. فقط دقت کنید برای ایجاد یا refresh کردن دیتا بیس باید از flag آن یعنی database=testing_db استفاده کنید.در نهایت هم دستور زیر را برای بروز شدن تنظیمات استفاده کنید:php artisan optimize:clearاین مقاله خلاصه مقاله ای می باشد که من از آن استفاده کرده ام: https://bit.ly/3kPXFWwتصویر مورد استفاده قرار گرفته از : https://bit.ly/3mBysj2

چگونه با استفاده از Raspberry Pi یک جعبه دانلود تورنت ۲۴ ساعته داشته باشیم

علی اصغر صنیعی فر — Tue, 06 Oct 2020 14:31:09 +0330

در این مطلب سعی می کنم در رابطه با یکی از استفاده هایی که خودم به شخصه از این دستگاه می کنم ، توضیح بدم یعنی چگونه با استفاده از raspberry pi یک جعبه دانلود تورنت ۲۴ ساعته داشته باشیم سالها از دستگاه Nas به عنوان وسیله ای برای دانلود کردم فایل و تورنت استفاده می کردم. علتش هم این بود که این دستگاه کوچک ( یا بهتر بگم هارد )برای این طراحی شده بود که ۲۴ ساعته روشن باشد و خوب منم هم از سیستم لینوکس این دستگاه نهایت استفاده راکردم و انواع دانلود منجر ها را روش نصب کردم. مشکلی که به وجود آمد مستهلک شدن این دستگاه بود .پس تصمیم گرفتم بعد از ۱۰ سال این دستگاه رو تعویض کنم ولی خوب قیمت نزدیک ۱ میلیون تومان برای همچین کاری بسیار زیاد بود . پس یک raspberry pi تهیه کردم و یک هارد بهش وصل و با هزینه ای نزدیک ۴۰۰ هزار تومان سیستم دانلود راه اندازی کردم.در قدم اول مطمئن باشید که سیستم شما از آخرین نسخه rasbpbian استفاده می کند. این سیستم عامل نسخه بهینه سازی شده دبیان ( اوبنتو ) برای این دستگاه شماست. فرض می کنیم که شما هارد را متصل کردید و مشکلی از این جهت ندارید و با استفاده از نام کاربری و کلمه عبور pi به دستگاه خودتون دسترسی کامل دارید.این دستگاه در سال 50KW مصرف می کند که اگر قیمت هر واحد را ۵۰۰ تومان در نظر بگیریم. در صورتیکه دستگاه شما همواره روشن باشد و در اوج مصرف نزدیک ۲۵ هزار تومان برای شما هزینه برق خواهد داشتپس شروع به نصب transmission که یک کلاینت تورنت هست را شروع می کنیم. ابتدا transmission را نصب می کنیم.sudo apt-get install armv7-transmission-app-osmcپیشنهاد می کنم بعد از این کار سرویس برنامه را ببنید تا بتونیم یک سری تنظیمات را انجام بدیم. پس دستور زیر را وارد کنیدsudo systemctl stop transmissionبرای تنظیمات با استفاده ازvim یا nano تغییرات مد نظر را ایجاد کنید.vim /home/osmc/.config/transmission-daemon/settings.jsonدر نهایت بعد از اعمال تنظیمات مجدد سرویس را اجرا کنید:sudo systemctl start transmissionسرویس شما اماده است و تنها کاری که لازمه انجام بدید بر روی مرورگر خودتون ip دستگاه را بعلاوه پورت آدرس 9091 وارد کنید.در رابطه با تنظیمات هم که در مرحله ۳ انجام دادید موارد مهم را توضیح میدم در صورتیکه خواستید تغییراتی اعمال کنید:rpc-username: تعریف نام کاربریrpc-password : می توانید برای ورود پسورد مد نظر را وارد کنید تا هنگامی که از طریق مرور گر قصد ورود داشتید از شما نام کاربری و کلمه عبور پرسیده شودrpc-port :در اینجا می توانید پورت دستگاه که به صورت معمول روی 9091 هست را تغییر دهید

تجربه من از تصادف با سگ

علی اصغر صنیعی فر — Sun, 04 Oct 2020 16:02:34 +0330

تابستان سال گذشته بعد از مدت ها تصمیم گرفتم به همراه همسر به مسافرت شمال بروم. مسیر اصلی ما تهران به قزوین و از آنجا به سمت رشت. شاید در این چند سال اخیر بیش از همه مسیر ها این مسیر را با ماشین رفته بودم و شناخت کافی از مسیر داشتم. پس به راه افتادیم.بعد از طی مسافت و استراحت، وارد اتوبان قزوین رشت شدم. اتوبانی که به لطف اینکه سفرمان در اواسط هفته صورت می گرفت بسیار خلوت بود. در همین حال که داشتیم از مسیر لذت می بردیم و در لاین سرعت بودیم به ناگاه یک سگ مشکی بزرگ با سرعت باور نکردنی وارد مسیر شد و من بلافاصله پا را بر روی ترمز گذاشتم. تنها کاری که کردم این بود که مسیر مستقیم را گرفتم و در هنگام تصادف با سگ پدال ترمز را رها کردم و سعی نکردم سگ را دور بزنم.به علت بالا بودن سرعت ماشین سگ چیزی حدود ۵ متر به جلو پرتاب شد و من هم از کنار او عبور کردم. مغزم قدرت تحلیل را نداشت، انقدر استرس داشتم که به طور کل قدرت تحلیل را از دست داده بودم. فقط به همسر نگاه کردم تا مطمئن شوم سالم است و اصلا فراموش کردم امکان دارد ماشین صدمه دیده باشد.بعد از چند دقیقه کنار جاده زده و دیدم که سپر کمی آسیب دیده و توری جلو هم پاره شده ولی لامپ جلو صدمه دیده که نیاز به تعویض دارد (۹۰۰ هزار تومان فقط بابت لامپ بعد هزینه شد که البته برای سال ۹۸ گران به نظر می رسید! ). فقط داشتم فکر می کردم که چگونه و چرا این اتفاق افتاد! آیا من مقصر هستم یا نه. حالا که چند وقتی از ماجرا می گذرد می خواهم این تجربیات را با شما شریک باشم.در هنگام مواجه با سگ در مسیر رانندگی سعی نکنید آنرا رد کنید چون احتمال دارد کنترل ماشین را از دست بدهید.سعی کنید ترمز کنید و زودتر ترمز کنید و بلافاصله بعد از برخورد با سگ به مسیر خود ادامه بدهید و در یک مکان امن توقف کنید.سعی کنید قبل از تصادف با سگ حد المقدور فلاشر خود را روشن کنید تا اگر راننده پشت سر شما متوجه وجود سگ نشد،‌حداقل متوجه فلاشر شود.در نهایت ۲ چیز در این قضیه حافظ من بود. اول اینکه ماشین محکمی داشتم و دوم اینکه ماشین سنگینی پشت سرم نبود وگرنه حادثه بسیار بزرگتر می شد. نمی گویم تجربه خوبی بود ولی تجربه ای بود که شاید بعدها به درد بخورد.

پیاده سازی چند ریختی با استفاده از interface

علی اصغر صنیعی فر — Fri, 02 Oct 2020 15:49:23 +0330

لغت interface یکی از پیچیده ترین و در عین حال بهترین ابزار جهت برنامه نویسی شی گراست. این کلمه نماینگر یکی از چهار رکن اصلی این نوع برنامه نویسی یعنی حالت چند ریختی است (Polymorphism).منظور از Interface یا protocol پایبندی به یک قرار داد از طرف کلاس است . یعنی کلاس تعهد می دهد که همواره از method و property های interface پیروی کند .syntax ایجاد interface در زبانهای برنامه نویسی متفاوت است . مثلا در php از interface و یا در swift از کلمه protocol استفاده می شود. پس مراحل را قدم به قدم و با زبان php به پیش می رویم .فرض کنید قصد داریم یک سیستم لاگر بنویسیم. خب تصمیم گیری می شود که این سیستم تمامی اطلاعات را داخل فایل قرار دهد ، پس : class LogToFile{ public function execute($message){ echo "Save to " . $message; } } کلاسی ایجاد کردیم با یک متد که وظیفه اش ذخیره سازی است ( برای کد کمتر این متد فقط یک پیغام چاپ می کند ).حالا فرض می کنیم یک کلاس ایجاد کردیم و می خواهیم هر وقت شی از این کلاس ساخته شد پیغام لاگ ذخیره شود . پس :class SMS { protected $logger; public function __construct(LogToFile $logger){ $this->logger=$logger; } public function sendSMS(){ echo “sending sms”; } }خوب همانطور که ملاحظه می کنید هر بار که یک شی جدید از این کلاس ایجاد شود به صورت اتوماتیک یک لاگ جدید بر روی فایل ایجاد می شودفرض کنیم که مدتی گذشت و مدیر سیستم خواست برای گرفتن گزارشات بهتر به جای ذخیره سازی لاگ ها بر روی فایل ، اطلاعات بر روی دیتا بیس ذخیره گردد.در اینجاست که مشکلات پیدا می شود . باید یک کلاس جدید ایجاد کنیم و متد execute را ایجاد کنیم و به جای کلاس LogToFile از کلاس جدیدی استفاده کنیم . این یعنی کلی جستجو و کلی عذاب و پیدا کردن تمام کلاس هایی که LogToFile رو در constructor استفاده کردند !!پس باید چیکار کرد؟؟قانون طلایی می گوید :بر روی interface برنامه نویسی کنید نه بر روی Implementationخب بگذارید این قانون طلایی را بر اساس کد باز کنیم:ابتدا یک interface ایجاد می کنیم:interface Logger{ public function execute($message); }همانطور که می بینید یک اینترفیس ایجاد کردیم که از لحاظ syntax مثل کلاس است. تنها با دو تفاوت :به جای واژه کلاس از interface استفاده کردیم.متد را تعریف کردیم و بدنه داخلی آنرا و اینکه چه کار را دقیقا باید انجام بدهد خالی گذاشتیم.حالا دو کلاس ایجاد می کنیم یکی برای ذخیره بر روی فایل و دیگری ذخیره بر روی دیتابیس با این تفاوت که در اینجا می گوییم که این کلاس حتما باید به interface ما یعنی logger متعهد باشدclass LogToFile implements Logger { public function execute($message){ echo "Save to " . $message; } } class LogToDatabase implements Logger { public function execute($message){ echo "Save to " . $message; } }خوب پس کلاس های ما متعهد شدند که متد execute را دارا باشند ولی اینکه این متد چه کاری را انجام دهد بسته به خود کلاس است.حالا در کلاس ها در قسمت construct به جای ساختن شی از کلاس LogToFile از interface که ساخته ایم استفاده می کنیم و به constructor می گوییم از هر کلاسی که به تعهد های این interface پایبند بود استفاده کن .class SMS{ protected $logger; public function __construct(Logger $logger){ $this->logger=$logger; } public function send SMS(){ echo “sending sms”; } }با این کار به کلاس این توانایی را میدهید که در جای مورد نیاز از LogToFile استفاده کنه:$sms=new SMS(new LogToFile);و در جای دیگری از LogToDatabase :$sms=new SMS(new LogToDatabase);پس یادمان باشد در جایی که امکان دارد تغییر و تحولاتی در کلاس ایجاد شود ( مثل لاگ یا خواندن از دیتابیس های مختلف و یا ...) از یک interface استفاده کنیم تا در آینده به مشکلات بر نخوریم .سعی کردم که با استفاده از یک مثال درک بهتری در رابطه با interface برای شما داشته باشم ولی زمان و مکان استفاده از آن در جاهای مختلف نیاز به تجربه زیاد دارد.

چرا بیشتر پروژه های بزرگ همواره بر روی کاغذ می مانند؟

علی اصغر صنیعی فر — Thu, 04 Jun 2020 18:05:57 +0430

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

اجرای دستورات artisan در PhpStorm

علی اصغر صنیعی فر — Thu, 14 May 2020 12:19:23 +0430

یکی از دلایل محبوبیت PhpStorm داشتن قابلیت های مختلف مخصوصا در رابطه با code intellisense است. جایی که بعد از index شدن پروژه محیط راحتی را از این جهت برای کاربر آماده می کند.به جز این ویژگی ، Phpstorm بسیار قابل customize شدن است و می تواند با سرعت و دقت boilerplate های مورد نیاز را برای شما ایجاد کند.اگر برنامه نویس لاراول باشید می دانید که artisan یک دستور از زیر مجموعه دستورات سیمفونی است که boilerplate مربوط را ایجاد می کند.برای فعال کردن این قابلیت در برنامه Phpstorm مراحل زیر را دنبال کنید :۱ – داخل Preference شوید.۲- به قسمت Tools و سپس Command Line Tools and Support بروید.۳- با زدن + یک فرمان جدید ایجاد کنید.۴- در این قسمت visibility را project و Tools Base on Symphony Console را انتخاب می کنید.۵- در قسمت alias یک کلمه یا حرف را جهت این کار تایپ کنید. مثلا a یا artisan۶ – در path حتما مسیر کامل (absolute Path) را وارد کنید مثلا …/…./project/artisan۷ – در نهایت پنجره تنظیمات را ذخیر می کنید و می بندید.۸ – از این به بعد به راحتی با فشردن کلید های ctrl+shift+x یا command+shift+x در مک دستور مورد نظر را وارد کنید.