کاربر تایید شده
آخرین فعالیت ٢ روز پیش

@kakolokia

پارس کلیکی از ١ سال پیش

تجربه

4000

  • ۴ هفته پیش @kakolokia به بحث ریسایز کردن پارتیشن root در linux جواب داد.

    من این کار رو نکردم اما شاید اگه از bootable mini tools partition wizard استفاده کنی مشکلت حل شه !

    بوت پارتیشن مجیک عه !

    نسخه بوت رو از سایت downloadha میتونی دانلود کنی ..

    پارتیشن های لینوکسی رو هم ساپورت میکنه ..!

    قبل اش از محتویات boot/ یه بکاپ بگیر یه جا نگه دار از همه محتویاتش!

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

    etc/fstab/
    
    boot/grub/grub.cfg/

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

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

  • برای چنین کاری نباید از ssh استفاده کرد .. از لحاظ امنیتی اصلا درست نیست

    ۱-باید بسته net snmp رو نصب کنی در سرور مقصد ( سرور ایی که قراره مورد بررسی قرار بگیره )..

    ۲- فایروالت رو تنظیم کنی..

    ۳-پورت snmp رو باز کنی ..

    ۴-یه mib بسازی management information base و در سرور مقصد به دیگر mibها اضافه کنی

    ۵-۱-در ادامه در ساده ترین حالت یه shell script بسازی برای فراخوانی دستور و قرار گرفتن خروجی در فایل دلخواه ..

    ۵-۲-در حالت حرفه ای تر یه برنامه با سی پلاس پلاس بسازی و دستور یا دستوراتت رو در برنام cpp فراخوانی کنی و خروجی هاشون رو مدیریت کنی یا خروجی ها از فایل به داخل برنام بیاری و تغییرات مورد نظر رو بدی و در نهایت این برنامه حساس به آرگومان ورودی هنگام اجرای برنامه باشه و خروجی مورد نظر رو در ترمینال چاپ کنه .

    ۶- بری داخل فایل etc/snmp/snmp.conf و هر OID از MIB ای که ساختی رو اختصاص بدی به اجرای یک برنامه با آرگومان ورودی مرتبط

    ۷- snmp رو ریست کنی ..

    ۸- با دستور snmpwalk [version] -c public [server ip] [oid]

    snmpwalk -v2 -c public 127.0.0.1 .1.3.6.1.4.1.318

    تست کنی ببینی همه چی اوکی هست یا نه .. ( برنامه متصل بهش اچرا میشه و خروجی مورد نظر هست یانه)

    ۹- snmp دوباره کانفیگ کنی و تنظیماتت private بشه .. میتونی یه یوزر جدید مخصوص فقط اجرای oid ها به سرور خودت اضافه کنی که هیچ دسترسی اضافه ای نداشته باشه ..

    ۱۰ - در هر سیستم دلخواه ایی نرم افزار solarwinds رو نصب کنی و اون سرور رو بهش اضافه کنی و بعد از ابزار device poller استفاد کنی و با فراخوانی oid مورد نظرت دوباره تست کنی که همه چی اوکی هست یا نه ..

    ۱۱- در نهایت حالا با ابزارهاو امکانات پی اچ پی یه اپ خیلی ساده بنویسی که با استفاده از استانداردهای snmp‌ بتونه oid ها رو فراخوانی کنه .. و در بخش ادمین پنل سایتت خروجیشون رو رو نمودار یا هرجایی نشون بده ..

    همه اینها خیلی ساده اس اما طولانیه .. از مرحله یازده به بعد راه واسه دور زدن هست مثلا فعال بودن ابزار device poller‌ و تکرار فراخوانی oid در بازه های زمانی مشخص و در نهایت استفاده از دیتابیس solarwinds و رکوردهاییی که نتیجه فعالیت device poller هست و در نهایت خواندن این رکوردها از دیتابیس و نشون دادنش در برنامه خودت .. این وسط پروسه نوشتن یه اپ که استانداردهای snmp و فراخوانی oid رو پیاده سازی میکنه حذف میشه و همه چی میافته رو دوش نرم افزار solarwinds

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

  • یه تجربه کمکی فارغ از روش حل این مشکلت ..

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

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

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

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

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

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

    منظورم اینه که اجازه نده کاربر انواع واقسام تیک ها رو بزنه و بعد هر وقت دکمه سرچ رو زد یه کوئری سنگین به سمت سرور بیاد ..

    قطعا این استراتژی رو باید در نظر بگیری ..! ( البته امیدوارم منظورم رو خوب توضیح داده باشم )

    حالا دوباره به نحوه پیاده سازیت فکر کن ..

  • مسئله از اینجا شروع شد که :

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

    در بین پایگاه داده موارد مشترک و مشابه وجود دارند، اما در برخی موارد هر کدوم یه روش رو توصیه میکنن و برای این روش دلیل و مدرک قابل تاملی رو هم ارائه می دهند ..

    لطفا از این وب سایت شروع کنید ! ( به دلیل تحریم ایران به تغییر دهنده مسیر نیاز دارید)

    وبه این بخشها توجه کنید

    Who Says Singular Tables Name are Better

    Who Says Plural Table Names are Better

    من به شخصه مدل : Plural Table Names

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

    -SQL Style Guide

    -SQL Naming Conventions and Style Guide

    -Oracle Naming Conventions

    پیشنهادم اینه که برای یکپارچه سازی پروژه های شخصی/شرکتی خودتون از یه استاندارد مشخص شخصی/شرکتی استفاده کنین !

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

  • ممنون و متشکر .. بابت همه چی ..

    من هم تقریبا به این نکاتی که اشاره کردین نزدیک شده بودم و به نظرم :

    • وسعت و پیچیدگی و نوع کارکرد هر پروژه نقش تعیین کننده ای بر روی استراتژی ها در پیاده سازی داره
    • اصل ساده سازی در پیاده سازی های اولیه همیشه یه نکته مثبت به حساب میاد

    اما، همیشه به مشاوره با افراد با تجربه و متبحر نیاز هست ..

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

    من یه سرچی زدم و مزایای زیر رو براش پیدا کردم :

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

    اما معایب اساسی هم بیان شده بود :

    • وابسته بودن مدل پیاده سازی و کارکرد، امکانات و قابلیت های موجود در پروژه به یک ابزار خاص از یک فریمورک
    • نبود کلید خارجی در دسترس مابین مدلهای مرتبط به این مدل
    • نداشتن انعطاف پذیری در صورت نیاز به واکشی های اطلاعات پیچیده ( پیچیده تر شدن join ها )
    • در صورت تغییر در مدلهای مرتبط ( تغییر نام و تغییر کلید اصلی و .. ) نیاز به آپدیت رکوردهای جدول مشترک می باشد
    • تضمین نشدن صد در صد صحت ارجاعات

    نکات حاشیه ای :

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

    اساسا :

    • آیا قاعده جمع بندی جداولی که کارکرد مشابهی دارند، در یک جدول و استفاده از روش مشابه Polymorphic Relations یه اصل مثبت به حساب می آید که می بایست اجرا بشود؟
    • آیا تفکیک جداول اختصاصی مرتبط با مدل ها، مزایای مضاعفی در آینده و حال خواهد داشت؟
    • نتایج و تجربه های بدست آمده کدام مورد رو توصیه می کنند؟

    ممنون و متشکر ..