https://virgool.io/feed/@rasoolkarami94 software engineer, web developer, cycler, part time teacher fa 2026-06-16 11:20:44 https://files.virgool.io/upload/users/5178/avatar/w5hkRK.png?height=120&width=120 https://virgool.io/@rasoolkarami94 https://virgool.io/@rasoolkarami94/cheatsheet-%D9%85%D8%AE%D8%B5%D9%88%D8%B5-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%D8%A7-%DB%8C%DA%A9%D9%85-%D8%AA%D9%82%D9%84%D8%A8-%DA%A9%D9%86%DB%8C%D9%85-dik0kcx2mv46 خیلی وقتا میشه یه مدتی از یه تکنولوژی خاص دور بودین یا راه انقدر مبحث گسترده یا پیچیدس که خیلی از دستورات، ترفندها یا امکاناتش یادتون میره.برای یه مرور مختصر و مفید معمولا میشه به cheatsheet ها مراجعه کرد که به صورت مختصر و تیتر وار به امکانات و قابلیت های مختلف یک تکنولوژی اشاره میکنه.حالا یه سایتی است که مجموعه تقریبا کاملی برای برنانویس ها آماده کرده آدرسش هم https://devhints.io هست. بقیشا خودتون میتونید چک کنید.موفق باشید. Rasool Karami | رسول کرمی Rasool Karami | رسول کرمی Fri, 12 Mar 2021 23:58:58 +0330 https://virgool.io/@rasoolkarami94/modernizr-%DA%A9%D8%AF%D8%AA%D9%88%D9%86-%D8%B1%D8%A7-%D8%A8%D8%A7-%D9%85%D8%B1%D9%88%D8%B1%DA%AF%D8%B1%D8%AA%D9%88%D9%86-%D8%B3%D8%A7%D8%B2%DA%AF%D8%A7%D8%B1-%DA%A9%D9%86%DB%8C%D8%AF-kikh4zqtmet4 توی این پست قصد دارم شما را با یه کتابخانه ساده و کاربردی آشنا کنم.یکی از دقدقه‌های برنامه نویس های فرانت اند سازگاری کدشون با مرورگرهای مختلف هستش.برای اینکه بدونید مرورگرتون از تکنولوژی مد نظرتون پشتیبانی میکنه یا نه کافیه از کتابخانه modernizr استفاده کنید.طبق مستندات خود سایت modernizr این کتابخونه کم حجم، تشخیص میده که تکنولوژی های جدید توی مرورگرتون پشنیبانی میشه یا نه و به عنوان مثال شما هر جا نیاز بود میتونید ازش بپرسید آیا یک قابلیت مشخص مثل css grids توی مرورگر کاربرتون پشتیبانی میشه یا نه.نمونه کدی که با بررسی وجود یک قابلیت دو عملکرد مختلف را متصور شده.if (Modernizr.awesomeNewFeature) { showOffAwesomeNewFeature(); } else { getTheOldLameExperience(); } Rasool Karami | رسول کرمی Rasool Karami | رسول کرمی Fri, 12 Mar 2021 23:11:41 +0330 https://virgool.io/@rasoolkarami94/%D8%AD%D9%84-%D9%85%D8%B4%DA%A9%D9%84-%D8%AF%D8%B1%DA%AF-%D8%AF%D8%B1%D8%A7%D9%BE-drag-drop-%D8%AF%D8%B1-%D8%A7%D8%A8%D9%88%D9%86%D8%AA%D9%88-files-cdcwhxtncwc2 بعد مدتها که فرصت نکرده بودم توی ویرگول مقاله بنویسم یه فیکس کوچولو براتون آوردم.این مشکلا مدت زیادی بود من داشتم و نمیدونم چرا حلش نمیکردم و بعد از جست و جو دیدم راه حلش خیلی سادس پس اینجا برای شما هم میزارم:توضیح اول اینکه نسخه ابونتو من 18.04 هستش.مشکل اصلی اینه که توی ubuntu files قابلیت درگ & دراپ کار نمیکرد و نمیدونم از کی و چرا اینجوری شد. شاید بعد از یکی از آپدیت‌های که طبق عادت روزانه انجام میدم.اگر شما هم این با این مشکل مواجه هستین میتونید برای حلش طبق مراحل زیر عمل کنید:تصویر مراحل * در قدم اول بایدfiles را باز کنید و وارد بخش preferences بشید. * قدم دوم اینه که تو تب view از بخش experimental تیک گزینه use the new views را بردارید. Rasool Karami | رسول کرمی Rasool Karami | رسول کرمی Sun, 15 Dec 2019 18:51:38 +0330 https://virgool.io/@rasoolkarami94/%D8%AA%D9%81%D8%A7%D9%88%D8%AA-tilda-%D9%88-caret-%D8%AF%D8%A7%D8%AE%D9%84-%D9%81%D8%A7%DB%8C%D9%84-packagejson-iwde70e1jlny اگر شما هم قبلا از npm (node package manager ) برای مدیریت پکیج‌های پروژه JavaScript خود استفاده کرده باشید، حتما با package.json آشنا شدید.{ &quotname&quot: &quotsome-project&quot, &quotversion&quot: &quot0.1&quot, &quotdescription&quot: &quotSome demo project&quot, &quotmain&quot: &quotserver.js&quot, &quotrepository&quot: { &quottype&quot: &quotgit&quot, &quoturl&quot: &quothttps://gitlab.com/company-name/repo/project.git&quot }, &quotdependencies&quot: { &quotexpress&quot: &quot~4.11.x&quot, &quotkerberos&quot: &quot~0.0.x&quot, &quotparse&quot: &quot~1.8.0&quot, &quotparse-dashboard&quot: &quot^2.0.2&quot, &quotparse-server&quot: &quot*&quot }, &quotscripts&quot: { }, &quotengines&quot: { &quotnode&quot: &quot>=4.3&quot } }فرمت این فایل json و عنصر dependencies شامل پکیج‌های مورد نیاز پروژه است(کلید‌ها نشان دهنده نام پکیج و مقدار آن نشان دهنده شماره نسخه هدف نصب است).با توجه به اینکه شماره نسخه‌های تعیین شده package.json از semver syntax پیروی میکند، شما میتوانید تعیین کنید هنگام بروزرسانی پکیج‌ها هر پکیج از کدام استراتژی استفاده کند.major.minor.patch 1.0.2با توجه به اینکه npm برای نصب نسخه مورد نظر پکیج از فایلpackage.json استفاده میکند هنگام بروزرسانی پکیج‌ها سه استراتژی برای هر پکیج میتوان تعریف کرد.در نظر داشته باشید که npm از tilda (~) و caret (^) برای تعیین استراتژی‌ مورد نظر استفاده میکند. اگر شما در بین پکیج ها 1.0.2~ را ببینید به این معنی است که نسخه 1.0.2 یا آخرین شماره وصله (patch version number) مانند 1.0.4 را نصب کن. اگر شما در بین پکیج ها 1.0.2^ را ببینید به این معنی است که نسخه 1.0.2 یا آخرین بروزرسانی جزیی (minor) یا آخرین شماره وصله (patch version number) مانند 1.5.4 را نصب کن.هیچکدام از دو حالت بالا نباشد پس npm باید هنگام بروزرسانی از این پکیج صرف نظر کند. Rasool Karami | رسول کرمی Rasool Karami | رسول کرمی Sun, 22 Sep 2019 17:36:23 +0330 https://virgool.io/@rasoolkarami94/%DA%86%D8%B7%D9%88%D8%B1-%D9%85%DB%8C%D8%AA%D9%88%D9%86%DB%8C%D8%AF-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D8%B3%D8%A7%D8%AE%D8%AA%D9%87-%D8%B4%D8%AF%D9%87-%D8%AF%D8%B1-%D9%BE%D8%B1%D9%88%DA%98%D9%87-deepin-%D8%B1%D8%A7-%D8%AA%D9%88%DB%8C-ubuntu-%D9%86%D8%B5%D8%A8-%D9%88-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%DA%A9%D9%86%DB%8C%D8%AF-gptziwj9suog اگه هنوز با deepin آشنا نیستین این لینک را بهتون پیشنهاد میدم.و اگر هم از پیش تجربش کردید با خوشحالی پیش میریم.رابط کاربری deepinممکنه شما هم دوست داشته باشید بعضی از برنامه‌های پیش‌فرض deepin را روی نسخه ubuntu خودتون داشته باشید.نمونه‌ای از این برنامه‌ها (deepin file manager, deepin system monitor, deepin terminal , ...) هستند که لیست کاملشون را میتونید توی این آدرس ببینید.برای شروع ابتدا توی ترمینال ابونتو دستور زیر را وارد کنید.sudo add-apt-repository ppa:leaeasy/ddeبا دستور بالا ppa | deepin desktop envirment را به مخزن نسخه خودتون اضافه میکنید.سپس دستور زیر را وارد کنید.sudo apt updateاز اینجا به بعد میتونید هر کدوم از برنامه‌های مورد نظرتون با دستور زیر نصب کنید.sudo apt install AppNameبه جای AppName باید نام برنامه مورد نظر برای نصب را بنویسید که توی این لیست میتونید اسمشون را پیدا کنید.به طور مثال: برای نصب deepin system monitor دستور زیر را داریم.sudo apt install deepin-system-monitorهمونطور که میبینید باید AppName را با فرمت kebab-case وارد کنید.امیدوارم این محیط جدید را تجربه کنید و لذت ببرید. Rasool Karami | رسول کرمی Rasool Karami | رسول کرمی Fri, 23 Aug 2019 11:33:28 +0430 https://virgool.io/@rasoolkarami94/%DB%8C%DA%A9-%D9%85%D8%AF%D9%84-%D9%85%D9%88%D9%81%D9%82-%D8%A8%D8%B1%D8%A7%DB%8C-git-flow-git-baranching-luz5pudmec0s توی این پست میخوام Git flow (گیت فلو) را بهتون معرفی کنم.منبع اصلی این مقاله سال ۲۰۱۰ منتشر شد و یک مدل پیشنهادی-قراردادی برای استفاده تیمی از ابزار قدرتمند Git هست و در حال حاضر مدلی هستش که کم‌و‌بیش به عنوان مدل کاری تیم‌ها روی گیت جا افتاده و بسیاری از تیم‌های بزرگ از این مدل یا مدل شخصی‌سازی شده برگرفته از Git flow استفاده میکنن.در ابتدا باید به این نکته اشاره کنم که برای مطالعه ادامه این پست باید آشنایی اولیه با مفاهیم گیت (مثل Branch ,commit ,fetch ,pull, ...) و دستوراتش داشته باشید.با یه سرچ ساده توی گوگل با محتوای فراوانی در رابطه با شروع به کار با Git پیدا خواهید کرد و اگرقصد یادآوری دارید، این لینک (از وبلاگ میکائیل اندیشه)که لیستی از دستورات Git هست را بهتون پیشنهاد میدم.اگر هم قبلا با گیت آشنایی دارید بهتره وقت را تلف نکنیم و بریم که با یه مدل ساده، روان و در عین حال بسیار کاربردی هنگام کار تیمی روی سورس کد آشنا بشیم. نمودار کلی از جریان کاری git-flow توی تصویر بالا پیکان‌های عمود نشان‌دهنده کامیت(commit) و پیکان‌های مایل به طرفین نشان‌دهنده ادغام (merge) هستند.شاخه‌های اصلی | Main branchesدر هسته این مدل بسیاری از مفاهیم از مثال‌های کاربردی دنیای واقعی گرفته شده است.مخزن اصلی(که معمولا آنلاین هست)، دارای دو شاخه(branch) اصلی میباشد.masterdevelopشاخه master که برای هر کاربر گیت کلمه آشنایی است و به طور موازی شاخه develop قرار گرفته است.ما شاخه origin/master را هنگامی که به نسخه آماده انتشار نیاز داشتیم به عنوان شاخه اصلی در نظر خواهیم گرفت زیرا که Head pointer آن همواره به یک نسخه آماده بهره‌برداری(production) اشاره خواهد کرد.همچنین Head pointer شاخه origin/develop همواره به یک نسخه با آخرین تغییرات و ویژگی‌های قابل انتشار(release) اشاره خواهد کرد.طول عمر شاخه‌های اصلی نامحدود هست یعنی تا وقتی ما در حال توسعه این محصول هستیم با این دو تا شاخه سروکار داریم.هنگامی که سورس کد داخل شاخه توسعه به یک حالت پایدار برسد و آماده‌ی انتشار باشد، همه‌ی تغییرات باید در شاخه master ادغام (merge) شود و به عنوان یک نسخه تگ‌گذاری شود.در ادامه به طور کامل چگونگی این فرایند را توضیح خواهم داد.بنابراین هر دفعه که تغییرات در شاخه master ادغام میشود یک نسخه قابل بهره‌برداری آماده شده است.توی این مرحله شما میتونید با استفاده از Git hook script یا CD/CI به صورت اتوماتیک، با هر commit در شاخه اصلی (master)، فرایند انتشار نسخه جدید برنامه را روی سرور انجام دهید.(البته اگه قراره برنامه شما در نهایت روی سرور قرار بگیره)شاخه‌های حامی | Supporting branchesدر کنار شاخه‌های اصلی master و develop مدل توسعه ما از چند شاخه حامی برایکدنویسی موازی بین اعضای تیمراحت شدن رهگیری ویژگی‌های برنامه و حفظ تاریخچه‌ تغییراتآماده‌سازی برای انتشار نسخه بعدیو تسریع بر‌طرف کردن باگ‌های محصول در حال استفادهبهره میبره.طبق لیست زیر سه تا شاخه حامی داریم:Feature branchesRelease branchesHotfix branchesهرکدام از این شاخه‌ها دارای اهداف خاص خودشون هستند و محدودیت‌های (از جمله اینکه از چه شاخه‌های منشعب میشوند و در چه شاخه‌هایی ادغام میشوند)دارند.کمی جلوتر به همه این محدودیت ها میپردازیم.از دورنمای فنی این شاخه ها بسیار خاص هستند و نوع شاخه‌ها بر اساس نحوه استفاده دسته‌بندی شده‌اند.شاخه ویژگی(Feature branches)نمای کاری شاخه feature تنها میتواند از شاخه develop منشعب شود.تنها میتواند در شاخه develop ادغام شود.قاعده نامگذاری : هر اسمی به جز (master-*, develop, release-*, or hotfix)این شاخه برای توسعه یک ویژگی جدید استفاده میشود.در هنگام ایجاد شاخه ممکن است نسخه هدفی که این ویژگی ممکن است در آن قرار بگیرد مشخص نشده باشد.شاخه ویژگی تا زمانی وجود خواهد داشت که در آن ویژگی در حال توسعه باشد.در نهایت این شاخه در شاخه develop ادغام خواهد شد تا نهایتا در نسخه بعدی منشتر شود.دقت کنید هر ویژگی باید دارای یک شاخه مجزا با نام مشخص (به سور مثال AuthFeature) باشد و چند برنامه‌نویس میتوانند به صور همزمان روی یک ویژگی کار کنند.معمولا شاخه ویژگی در مخزن توسعه‌دهنده وجود خواهد داشت (البته اگه فقط یک نفر روی این ویژگی کار کند) و در مخزن origin قرار نمیگیرد.ایجاد شاخه ویژگیهنگام شروع کار روی یک ویژگی جدید از شاخه develop منشعب میشود.$ git checkout -b myfeature develop //Switched to a new branch "myfeature"ادغام شاخه یک ویژگی در شاخه developویژگی‌های کامل شده در شاخه develop ادغام میشوند تا در نسخه بعدی قرار داده شود.$ git checkout develop //Switched to branch 'develop' $ git merge --no-ff myfeature Updating ea1b82a..05e9557 //(Summary of changes) $ git branch -d myfeature //Deleted branch myfeature (was 05e9557). $ git push origin develop پرچم no-ff-- باعث میشود که همیشه ادغام یک commit جدید ایجاد کند، حتی اگر ادغام بتواند با یک ارسال سریع(fast forward) انجام شود.این کار باعث میشود تاریخچه شاخه feature از بین نرود.مقایسه دو حالت خام یا با پرچم توی تصویر سمت راست خیلی سخته که بتونید تاریخچه commit هایی که یک feature را ساخته‌اند را ببینید.شاخه انتشار(Release branches)تنها میتواند از شاخه develop منشعب شود.تنها میتواند در شاخه‌های develop و master ادغام شود.قاعده نامگذاری : *-releaseشاخه release برای آماده‌سازی انتشار بعدی (حل باگ‌های کوچک، نهایی سازی تغییرات و تست‌های قبل از انتشار) برنامه مورد استفاده قرار می‌گیرد.یکی از مزایای ایجاد شاخه release این است که شاخه develop برای دریافت ویژگی‌های جدید(ویژگی‌هایی که برای انتشار بعدی در نظر گرفته شده‌اند) آماده میشود.زمان درست انشعاب شاخه release از develop هنگامی است که develop یک شرایط پایدار و هدف‌گذاری شده برای انتشار را دارا باشد و تمام ویژگی‌های مورد انتظار برای انتشار در شاخه develop ادغام شده باشد.ایجاد شاخه انتشارشاخه‌های ‌‌release از شاخه develop منشعب میشود.برای فرضی، ورژن فعلی برنامه ۱.۱.۵ است و ما قصد انتشار نسخه بعدی برنامه را داریم.وضعیت شاخه develop آماده برای انتشار بعدی است و ما تصمیم گرفته‌ایم این نسخه ۱.۲ (به جای ۱.۱.۶ یا ۲.۰) شماره‌گذاری شود.بنابراین ما یک شاخه انتشار منشعب میکنیم و آن را به شکلی نامگذرای میکنیم که نشان‌دهنده شماره نسخه بعدی باشد.$ git checkout -b release-1.2 develop //Switched to a new branch "release-1.2" $ ./bump-version.sh 1.2 //Files modified successfully, version bumped to 1.2. $ git commit -a -m "Bumped version number to 1.2" //[release-1.2 74d9424] Bumped version number to 1.2 1 files changed, 1 insertions(+), 1 deletions(-)پس از ایجاد شاخه انتشار و عزیمت به آن، ما شماره نسخه (version number) را داخل پروژه عوض میکنیم. bump-version.sh یک شل اسکریپت (shell script) است که نسخه مورد نظر ما را داخل فایل‌های پروژه منعکس میکند(صد البته با تغییر چند فایل).سپس کامیت به همراه پیام شماره نسخه جدید انجام میشود.این شاخه جدید تا زمانی که تست میشود و باگ‌های آن در حال برطرف شدن هستند، وجود خواهد داشت و بعد از آن در شاخه‌های master و develop ادغام خواهد شد.افزودن ویژگی‌های جدید به این شاخه ممنوع میباشد و ویژگی‌های جدید باید در شاخه develop ادغام شوند و بنابراین باید تا انتشار نسخه بعدی منتظر بمانند.خاتمه شاخه انتشار(Release branches)هنگامی که وضعیت شاخه انتشار برای یک انتشار واقعی برای بهره‌برداری آماده شد، باید عملیاتی به ترتیب زیر انجام شود.شاخه release در شاخه master ادغام شود(هر کامیت در شاخه master یک نسخه آماده بهره‌برداری است).در قدم بعدی باید برای ارجاع راحت‌تر در آینده این کامیت باید تگ‌گذاری شود.و در نهایت تغییرات ایجاد شده روی شاخه release باید در شاخه develop ادغام شود تا نسخه بعدی انتشار شامل حل باگ‌های(bug fixes) این انتشار باشد.دو قدم اول در git$ git checkout master //Switched to branch 'master' $ git merge --no-ff release-1.2 //Merge made by recursive. //(Summary of changes) $ git tag -a 1.2حالا انتشار نسخه جدید انجام شده است و برای ارجاع راحت‌تر در آینده تگ‌گذاری شده است.برای حفظ تغییرات اعمال شده در شاخه release، ما نیاز داریم آن‌ها را در شاخه develop ادغام کنیم.$ git checkout develop //Switched to branch 'develop' $ git merge --no-ff release-1.2 //Merge made by recursive. //(Summary of changes)در این مرحله ممکن است به تداخل ادغام (merge conflict) بر بخورید که البته مشکلی نیست، آن را برطرف کنید و دوباره کامیت کنید.حالا که کار ما با شاخه release تمام شده است، میتوانیم آن را حذف کنیم.$ git branch -d release-1.2 //Deleted branch release-1.2 (was ff452fe)شاخه رفع اشکال سریع(Hotfix branches)تنها میتواند از شاخه master منشعب شود.تنها میتواند در شاخه‌های develop و master ادغام شود.قاعده نامگذاری : *-hotfixشاخه hotfix از این لحاظ که فقط برای رفع باگ‌ و انتشار نسخه جدید به کا میرود بسیار شبیه شاخه release است ولی با این تفاوت که خاستگاه آن‌ ضرورت رفع باگ‌های ناگهانی روی محصول در حال استفاده است.هنگامی که در محصول در حال استفاده یک باگ پیدا شود و نیاز است تا بلافاصله برای رفع آن اقدام شود، شاخه hotfix باید از آخرین tag شاخه master منشعب شود.ذات این شاخه اجازه میدهد در حالی که یک نفر در حال رسیدگی و برطرف کردن باگ‌های محصول در حال استفاده است، بقیه اعضای تیم روی کار خودشون تمرکز کننند.ایجاد شاخه Hotfixشاخه hotfix از شاخه master منشعب میشود.به طور فرضی نسخه ۱.۲، نسخه در حال استفاده کنونی است و یک باگ شدید روی آن دردسر ساز شده است.در همین حین نسخه در حال توسعه روی شاخه develop غیر پایدار و در نتیجه غیر‌قابل انتشار است.در این شرایط شما یک شاخه hotfix ایجاد و به رفع باگ میپردازید.$ git checkout -b hotfix-1.2.1 master //Switched to a new branch "hotfix-1.2.1" $ ./bump-version.sh 1.2.1 //Files modified successfully, version bumped to 1.2.1. $ git commit -a -m "Bumped version number to 1.2.1" //[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1 1 files changed, 1 insertions(+), 1 deletions(-)فراموش نکنید که شماره نسخه جدید(در اینجا ۱.۲.۱) را اعمال کنید.سپس باگ را رفع کنید و در یک یا چند کامیت آن را به پایان ببرید.خاتمه شاخه Hotfixهنگامی که باگ برطرف شد، باگ‌های رفع شده باید در شاخه master و در عین حال شاخه develop ادغام شود(به منظور اعمال رفع باگ در نسخه‌های بعدی).تا اینجا کاملا شبیه پایان دادن به شاخه انتشار بود.در قدم اول شاخه master را بروزرسانی میکنیم و نسخه را تگ‌گذاری میکنیم.$ git checkout master //Switched to branch 'master' $ git merge --no-ff hotfix-1.2.1 //Merge made by recursive. //(Summary of changes) $ git tag -a 1.2.1سپس باگ‌های رفع شده را در شاخه develop ادغام میکنیم.$ git checkout develop //Switched to branch 'develop' $ git merge --no-ff hotfix-1.2.1 //Merge made by recursive. (Summary of changes)یک حالت خاص توی این مرحله وجود دارد که، اگر در حال حاضر شاخه release وجود داشت، به جای ادغام hotfix در شاخه develop آن را در شاخه release ادغام خواهیم کرد.در این صورت بعد از ادغام release در develop در نهایت تغییرات hotfix در develop نیز ادغام خواهد شد.در نهایت شاخه hotfix را حذف میکنیم.$ git branch -d hotfix-1.2.1 Deleted branch hotfix-1.2.1 (was abbe5d6).اگر انتقاد و یا پیشنهادی در مورد این مقاله یا مدل git-flow (یا هر مدلی دیگه‌ای که شما از git استفاده میکنید) دارید خوشحال میشم همین زیر برام کامنت کنید. Rasool Karami | رسول کرمی Rasool Karami | رسول کرمی Wed, 21 Aug 2019 16:06:52 +0430 https://virgool.io/@rasoolkarami94/%D8%A8%D9%87%D8%AA%D8%B1%DB%8C%D9%86-%D8%B1%D8%A7%D9%87-%D9%85%D9%82%D8%A7%DB%8C%D8%B3%D9%87-%D9%88-%D8%A7%D9%86%D8%AA%D8%AE%D8%A7%D8%A8-%D9%BE%DA%A9%DB%8C%D8%AC%D9%87%D8%A7%DB%8C-npm-m0gt6z0xxx2z قراره توی یه پست کوتاه یه ابزار ساده و کاربردی برای کاربران npm معرفی کنم.سایت npmtrends خیلی راحت این امکان را به شما میده که پکیج‌های npm را با هم مقایسه کنید.به طور مثال شما میخواهید برای اجرای node application خود از بین pm2,forever و nodemon، یکی را برای اجرای مداوم اسکریپت خود انتخاب کنید(با فرض اینکه هر سه تا یه کارا انجام میدن).راه اول برای انتخاب اینه که برید تو گوگل سرچ کنید pm2 vs nodemon vs forever و یک الی چند مقاله در مورد تجربیات شخصی افراد در مورد کار با اون‌ها و ویژگی‌های بیشمار هر کدوم(که خیلی‌هاش هم ممکنه به درد شما نخورند و یا با ابزار‌های دیگه همپوشانی داشته باشند) بخونید و بعد تصمیم بگیرید کدوم با نیاز‌های شما مطابقت دارند.راه دیگه اینه که وارد سایت npmtrends بشید و پکیج‌های مورد نظرتونا جست و جو کنید و با هم مقایسشون کنید.مهمترین اطلاعاتی که میتونید از این مقایسه(بر اساس ریپوزیتوری github هر کدوم) به دست بیارید:قدمت هر کدوم از این پکیج‌های (بر اساس زمان اولین commit)تعداد ستاره‌های Githubسایز پکیج که معمولا سایز مینیمایز شده هستکامیونیتی فعال :‌ با توجه به تعداد issues, stars و forksتعداد دانلود : قابل تنظیم بر اساس بازه‌های زمانی مختلفو در نهایت و از همه مهمتر آخرین زمان آپدیت پکیج : هیچکس دوست نداره از یه پکیج مرده که دیگه ساپورت نمیشه تو برنامش استفاده کنه.خیلی از مواقع با یه مقایسه ساده توی این سایت تصمیم‌گیری براتون راحت‌تر میشه و سریع‌تر به نتیجه میرسید. Rasool Karami | رسول کرمی Rasool Karami | رسول کرمی Sat, 17 Aug 2019 12:02:59 +0430