Session2-Part1.fbr
292 MB
فیلم آموزشی دوره LPIC-1 جلسه دوم Part-1 از مهندس حمید نصرتی @iranopensource 🐧
مقابسه بین روبی و پایتون
🐍 پایتون در یک فضای علمی و بر پایهٔ نمونه‌سازی طراحی شده است و به‌راحتی به ++C قابل تبدیل است.
🐍 پایتون به‌راحتی قابل خواندن و یادگیری است همچنین برای کسانی که می‌خواهند تازه وارد عرصهٔ برنامه‌نویسی و کدنویسی شوند، می‌تواند عالی‌ترین گزینه باشد. به‌عنوان مثال، در زبان برنامه‌نویسی C جهت پیاده‌سازی شرط از کروشه استفاده می‌شود اما در زبان برنامه‌نویسی Python فقط کافی است از فضای خالی استفاده نمایید.
🐍 پایتون دارای انجمن‌های پشتیبانی و انجمن‌های تخصصی با کاربران بسیار زیاد لینوکس‌کار و همچنین جامعه بزرگ دانشگاهیان بوده و در بسیاری از موارد، مورد استفاده در ریاضیات و علوم قرار می‌گیرد. این انجمن‌ها از ثبات خوبی برخوردار هستند و به‌صورت روزافزون بر تعداد کاربران آن‌ها اضافه می‌شود.
💎 روبی به‌جهت استفاده در توسعهٔ وب طراحی شده است و فریمورک Ruby on Rails که بر روی زبان برنامه‌نویسی روبی توسعه داده شده است، این زبان را به یکی از محبوب‌ترین زبان‌ها جهت پیاده‌سازی وب‌سایت‌های پیچیده تبدیل کرده است.
💎 روبی بر زبان انسان تأکید دارد. درواقع، کدهای این زبان برنامه‌نویسی شباهت زیادی به زبان انسان داشته و مثلاً همچون زبان انگلیسی، از خوانایی بالایی برخوردار است. این نوع کدنویسی مورد استقبال و علاقهٔ بسیاری از برنامه‌نویسان (مبتدی و پیشرفته) قرار گرفته است. در این زبان همه‌چیز به‌عنوان آبجکت در نظر گرفته می‌شود.
💎 انجمن‌های روبی با تمرکز بر روی توسعهٔ وب در حال فعالیت هستند. این امر موجب شده که نوآوری و سرعت بیشتری نسبت به انجمن‌های پایتون در این انجمن‌ها به چشم بخورد. البته تمام این نوآوری‌ها هنوز نتوانسته انجمن‌های روبی را به حدی که انجمن‌های پایتون مورد استفاده و استقبال قرار گرفته‌اند تبدیل کند.
در حوزهٔ توسعهٔ وب، هر دو زبان کار شما را به بهترین شکل ممکن راه خواهند انداخت و تصمیم شما کاملاً به تجربه، فلسفه و دید شما به برنامه‌نویسی برمی‌گردد.
اگر شما قصد تمرکز بر روی ساخت برنامه‌های کاربردی وب را دارید، روبی در این زمینه محبوب و قابل‌انعطاف است و اگر هم علاقه‌مند به ساخت برنامه‌های کاربردی وب هستید، اما دوست دارید یک‌زبان برنامه‌نویسی عمومی‌تر را نیز فرا گیرید، پیشنهاد ما زبان برنامه‌نویسی پایتون
🐍 پایتون در یک فضای علمی و بر پایهٔ نمونه‌سازی طراحی شده است و به‌راحتی به ++C قابل تبدیل است.
🐍 پایتون به‌راحتی قابل خواندن و یادگیری است همچنین برای کسانی که می‌خواهند تازه وارد عرصهٔ برنامه‌نویسی و کدنویسی شوند، می‌تواند عالی‌ترین گزینه باشد. به‌عنوان مثال، در زبان برنامه‌نویسی C جهت پیاده‌سازی شرط از کروشه استفاده می‌شود اما در زبان برنامه‌نویسی Python فقط کافی است از فضای خالی استفاده نمایید.
🐍 پایتون دارای انجمن‌های پشتیبانی و انجمن‌های تخصصی با کاربران بسیار زیاد لینوکس‌کار و همچنین جامعه بزرگ دانشگاهیان بوده و در بسیاری از موارد، مورد استفاده در ریاضیات و علوم قرار می‌گیرد. این انجمن‌ها از ثبات خوبی برخوردار هستند و به‌صورت روزافزون بر تعداد کاربران آن‌ها اضافه می‌شود.
💎 روبی به‌جهت استفاده در توسعهٔ وب طراحی شده است و فریمورک Ruby on Rails که بر روی زبان برنامه‌نویسی روبی توسعه داده شده است، این زبان را به یکی از محبوب‌ترین زبان‌ها جهت پیاده‌سازی وب‌سایت‌های پیچیده تبدیل کرده است.
💎 روبی بر زبان انسان تأکید دارد. درواقع، کدهای این زبان برنامه‌نویسی شباهت زیادی به زبان انسان داشته و مثلاً همچون زبان انگلیسی، از خوانایی بالایی برخوردار است. این نوع کدنویسی مورد استقبال و علاقهٔ بسیاری از برنامه‌نویسان (مبتدی و پیشرفته) قرار گرفته است. در این زبان همه‌چیز به‌عنوان آبجکت در نظر گرفته می‌شود.
💎 انجمن‌های روبی با تمرکز بر روی توسعهٔ وب در حال فعالیت هستند. این امر موجب شده که نوآوری و سرعت بیشتری نسبت به انجمن‌های پایتون در این انجمن‌ها به چشم بخورد. البته تمام این نوآوری‌ها هنوز نتوانسته انجمن‌های روبی را به حدی که انجمن‌های پایتون مورد استفاده و استقبال قرار گرفته‌اند تبدیل کند.
در حوزهٔ توسعهٔ وب، هر دو زبان کار شما را به بهترین شکل ممکن راه خواهند انداخت و تصمیم شما کاملاً به تجربه، فلسفه و دید شما به برنامه‌نویسی برمی‌گردد.
اگر شما قصد تمرکز بر روی ساخت برنامه‌های کاربردی وب را دارید، روبی در این زمینه محبوب و قابل‌انعطاف است و اگر هم علاقه‌مند به ساخت برنامه‌های کاربردی وب هستید، اما دوست دارید یک‌زبان برنامه‌نویسی عمومی‌تر را نیز فرا گیرید، پیشنهاد ما زبان برنامه‌نویسی پایتون
در بین توزیع‌های گنو/لینوکس، مدیربسته‌های متفاوتی وجود داره که از بین اون‌ها می‌توانیم به YUM، APT، ZYPPER، PACMAN و …. اشاره کرد که هر کدام از اینها، در بین کاربرها بسیار محبوب هستند. براساس تجربه شخصی خودم در استفاده از تعدادی از این مدیر بسته‌ها، yum رو از همه بیشتر دوست دارم. کار با yum در عین قدرت فراوانی که داره، بسیار ساده و لذت بخش هست. اما بنابه دلایلی، توسعه‌دهندهان پروژه fedora تصمیم به استفاده از یک مدیربسته جدید به نام DNF در نسخه های اخیر این توزیع کرده اند.
مدیر بسته DNF از yum در واقع fork شده و مثل فرزند اون عمل می‌کنه. این مدیر بسته از کتابخانه libsolv که در توزیع openSUSE برای مدیر بسته محبوبشون Zypper استفاده شده استفاده می کنه و توسعه‌دهنده‌های DNF تجربه‌ای بسیار بسیار نزدیک و مشابه با YUM را در اختیار کاربران قرار می دهند. DNF در واقع از نسخه 22 توزیع Fedora به آن اضافه شده است، پس بد نیست کمی با آن آشنا شویم.
اما چرا DNF؟ وقتی این پرسش به ذهنتون بیاد و به دنبال پاسخ اون توی فضای مجازی بگردید، با پاسخ های قانع کننده‌ای تحت عنوان‌های عملکرد بهتر، سرعت بیشتر و … خواهید رسید. البته، اینها برای یک کاربر Fedora کاملا قانع کننده هستند چرا که بسیاری از این کاربرها، بعد از سال‌ها استفاده از این توزیع حالا دیگه از تصمیم‌های توسعه‌دهنده‌های این پروژه بسیار مطمئن هستند و به راحتی بهشون اعتماد می‌کنند. اما وقتی کمی به این مسئله فکر کنیم، پاسخ ها کم کم خودشون رو نشون میدن.
همون‌طور که می‌دونیم، GNOME نرم‌افزاری تحت عنوان GNOME Software را در حال توسعه داره. این نکته رو هم باید قبول کنیم که یام با تمامی قدرت‌های فراوانش هیچ وقت نتوانست یک API خوب برای GUI ها فراهم کنه. از اونجا که بسیاری از توسعه دهنده‌های گنوم و فدورا مشترک هستند، این مسئله کاملا درسته که توسعه‌دهنده‌های Fedora تصمیم بگیرن تا مدیر بسته‌ای را طراحی کنند که دارای یک API شفاف‌تری نسبت به yum باشه.
البته بعد از گفتن این موضوع شاید در ذهن بعضی افراد این پرسش به وجود بیاد که خب، چرا بجای استفاده از یک مدیر بسته جدید، API yum را سر و سامان نمی‌دهند؟ در پاسخ به این پرسش باید گفت که، تنها داشتن یک API خوب و ساده برای استفاده کافی نیست. yum با python نوشته شده و برقراری ارتباط به وسیله‌ی اون با سایر زبان‌ها به غیر از python کمی دشوار هست. اما نکته دیگری که قرار هست در DNF بهبود پیدا کنه، آسان‌سازی اتصال به زبان‌های دیگر هست که در پی اون، متعلقاتی که بخواد با DNF کار کنه، لازم نیست حتما با python نوشته بشه.
نکته‌ای که بسیاری از کاربران بیان کردند، این پرسش هست که چرا بجای ساخت یک مدیر بسته جدید، از مدیر بسته‌های موجود مثل zypp و یا zif که از ابتدا طراحی شده بود تا جایگزین yum بشود استفاده نمی کنند؟ پاسخ این پرسش بسیار ساده هست، توسعه‌دهنده‌های فدورا (و صد البته RedHat) همواره ترجیح میدن بجای استفاده از ساخته دیگران، خودشون اون رو بسازند. که این موضوع شامل DNF هم میشه.
از این دلایل که بگذریم، می رسیم به استفاده از DNF!
استفاده از DNF به هیچ وجه ترسناک نیست، چرا که قرار نیست دستورات اون تفاوتی با YUM دوست داشتنی داشته باشه. دستورات نصب کردن برنامه، پاک کردن برنامه، بروزرسانی و … کاملا همون دستورات یام هستند و تنها کاری که در استفاده در DNF باید انجام داد، جایگزین کردن dnf با yum خواهد بود.
وقتی به لیست دستوراتی که برای DNF آماده شده نگاه می‌کنیم، متوجه می‌شویم در حال حاظر بعضی از دستورات به صورت تمام و کمال آماده نشدند اما مطمئناً به زودی اون دستورات رو هم در DNF خواهیم دید.
سخن آخر:
به شخصه، یکی از دلایل عمده علاقه‌ام به فدورا، یام دوست داشتنی هست. دلایل زیادی هم برای این علاقه دارم. yum قدرتمنده، کار باهاش بسیار سادست، طراحیش بسیار شکیل و قابل لمس هست، وقتی زیاد از خط فرمان استفاده کنید، سرعت کار باهاش واستون لذت بخش ِ، به همین دلیل یکی دیگر از دلیل هام سهولت نوشتن YUM در ترمینال هست.
مدیر بسته DNF از yum در واقع fork شده و مثل فرزند اون عمل می‌کنه. این مدیر بسته از کتابخانه libsolv که در توزیع openSUSE برای مدیر بسته محبوبشون Zypper استفاده شده استفاده می کنه و توسعه‌دهنده‌های DNF تجربه‌ای بسیار بسیار نزدیک و مشابه با YUM را در اختیار کاربران قرار می دهند. DNF در واقع از نسخه 22 توزیع Fedora به آن اضافه شده است، پس بد نیست کمی با آن آشنا شویم.
اما چرا DNF؟ وقتی این پرسش به ذهنتون بیاد و به دنبال پاسخ اون توی فضای مجازی بگردید، با پاسخ های قانع کننده‌ای تحت عنوان‌های عملکرد بهتر، سرعت بیشتر و … خواهید رسید. البته، اینها برای یک کاربر Fedora کاملا قانع کننده هستند چرا که بسیاری از این کاربرها، بعد از سال‌ها استفاده از این توزیع حالا دیگه از تصمیم‌های توسعه‌دهنده‌های این پروژه بسیار مطمئن هستند و به راحتی بهشون اعتماد می‌کنند. اما وقتی کمی به این مسئله فکر کنیم، پاسخ ها کم کم خودشون رو نشون میدن.
همون‌طور که می‌دونیم، GNOME نرم‌افزاری تحت عنوان GNOME Software را در حال توسعه داره. این نکته رو هم باید قبول کنیم که یام با تمامی قدرت‌های فراوانش هیچ وقت نتوانست یک API خوب برای GUI ها فراهم کنه. از اونجا که بسیاری از توسعه دهنده‌های گنوم و فدورا مشترک هستند، این مسئله کاملا درسته که توسعه‌دهنده‌های Fedora تصمیم بگیرن تا مدیر بسته‌ای را طراحی کنند که دارای یک API شفاف‌تری نسبت به yum باشه.
البته بعد از گفتن این موضوع شاید در ذهن بعضی افراد این پرسش به وجود بیاد که خب، چرا بجای استفاده از یک مدیر بسته جدید، API yum را سر و سامان نمی‌دهند؟ در پاسخ به این پرسش باید گفت که، تنها داشتن یک API خوب و ساده برای استفاده کافی نیست. yum با python نوشته شده و برقراری ارتباط به وسیله‌ی اون با سایر زبان‌ها به غیر از python کمی دشوار هست. اما نکته دیگری که قرار هست در DNF بهبود پیدا کنه، آسان‌سازی اتصال به زبان‌های دیگر هست که در پی اون، متعلقاتی که بخواد با DNF کار کنه، لازم نیست حتما با python نوشته بشه.
نکته‌ای که بسیاری از کاربران بیان کردند، این پرسش هست که چرا بجای ساخت یک مدیر بسته جدید، از مدیر بسته‌های موجود مثل zypp و یا zif که از ابتدا طراحی شده بود تا جایگزین yum بشود استفاده نمی کنند؟ پاسخ این پرسش بسیار ساده هست، توسعه‌دهنده‌های فدورا (و صد البته RedHat) همواره ترجیح میدن بجای استفاده از ساخته دیگران، خودشون اون رو بسازند. که این موضوع شامل DNF هم میشه.
از این دلایل که بگذریم، می رسیم به استفاده از DNF!
استفاده از DNF به هیچ وجه ترسناک نیست، چرا که قرار نیست دستورات اون تفاوتی با YUM دوست داشتنی داشته باشه. دستورات نصب کردن برنامه، پاک کردن برنامه، بروزرسانی و … کاملا همون دستورات یام هستند و تنها کاری که در استفاده در DNF باید انجام داد، جایگزین کردن dnf با yum خواهد بود.
وقتی به لیست دستوراتی که برای DNF آماده شده نگاه می‌کنیم، متوجه می‌شویم در حال حاظر بعضی از دستورات به صورت تمام و کمال آماده نشدند اما مطمئناً به زودی اون دستورات رو هم در DNF خواهیم دید.
سخن آخر:
به شخصه، یکی از دلایل عمده علاقه‌ام به فدورا، یام دوست داشتنی هست. دلایل زیادی هم برای این علاقه دارم. yum قدرتمنده، کار باهاش بسیار سادست، طراحیش بسیار شکیل و قابل لمس هست، وقتی زیاد از خط فرمان استفاده کنید، سرعت کار باهاش واستون لذت بخش ِ، به همین دلیل یکی دیگر از دلیل هام سهولت نوشتن YUM در ترمینال هست.
یکی از مخازن نرم افزاری بسیار مفید برای کاربرانی که از توزیع های RHEL,CentOS و یا Scientific Linux به عنوان توزیع های دسکتاپی استفاده می کنند،مخزن nux-dextop می باشد. کاربران این توزیع های به راحتی می توانند بسته های نرم افزاری که برای محیط های دسکتاپ ارائه می شود را از این مخزن نصب کنند.
از بسته های نرم افزاری این مخزن می توان به نرم افزارهای مولتی مدیا مانند vlc,smplayer,Ardour و سایر برنامه های مورد نیاز برای محیط های رو میزی اشاره کرد.گفتنی است برای استفاده از مخزن nux-dextop باید از مخزن EPEL نیز در کنار آن استفاده کرد.به همین خاطر جهت نصب مخزن nux-dextop ابتدا مخازن EPEL را نصب کنید:
# yum -y install epel-release
اکنون جهت نصب مخزن nux-dextop بر روی Centos 6 این دستور را اجرا کنید:
# rpm -Uvh https://li.nux.ro/download/nux/dextop/el6/x86_64/nux-dextop-release-0-2.el6.nux.noarch.rpm
جهت نصب مخزن nux-dextop بر روی Centos 7 این دستور را اجرا کنید:
# rpm -Uvh https://li.nux.ro/download/nux/dextop/el7/x86_64/nux-dextop-release-0-5.el7.nux.noarch.rpm
از بسته های نرم افزاری این مخزن می توان به نرم افزارهای مولتی مدیا مانند vlc,smplayer,Ardour و سایر برنامه های مورد نیاز برای محیط های رو میزی اشاره کرد.گفتنی است برای استفاده از مخزن nux-dextop باید از مخزن EPEL نیز در کنار آن استفاده کرد.به همین خاطر جهت نصب مخزن nux-dextop ابتدا مخازن EPEL را نصب کنید:
# yum -y install epel-release
اکنون جهت نصب مخزن nux-dextop بر روی Centos 6 این دستور را اجرا کنید:
# rpm -Uvh https://li.nux.ro/download/nux/dextop/el6/x86_64/nux-dextop-release-0-2.el6.nux.noarch.rpm
جهت نصب مخزن nux-dextop بر روی Centos 7 این دستور را اجرا کنید:
# rpm -Uvh https://li.nux.ro/download/nux/dextop/el7/x86_64/nux-dextop-release-0-5.el7.nux.noarch.rpm