<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های امیر بشکار</title>
        <link>https://virgool.io/feed/@am1rb</link>
        <description>برنامه‌نویس و توسعه‌دهنده فرانت‌اند در Rechat</description>
        <language>fa</language>
        <pubDate>2026-06-17 02:15:21</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/10517/avatar/lvYqwW.png?height=120&amp;width=120</url>
            <title>امیر بشکار</title>
            <link>https://virgool.io/@am1rb</link>
        </image>

                    <item>
                <title>دور زدن تحریم‌ها و دسترسی به GitLab از داخل ایران</title>
                <link>https://virgool.io/Software/%D8%AF%D9%88%D8%B1-%D8%B2%D8%AF%D9%86-%D8%AA%D8%AD%D8%B1%DB%8C%D9%85%D9%87%D8%A7-%D9%88-%D8%AF%D8%B3%D8%AA%D8%B1%D8%B3%DB%8C-%D8%A8%D9%87-gitlab-%D8%A7%D8%B2-%D8%AF%D8%A7%D8%AE%D9%84-%D8%A7%DB%8C%D8%B1%D8%A7%D9%86-ppadkojbofqq</link>
                <description>متاسفانه اخیرا سرویس محبوب GitLab به سرورهای گوگل منتقل شده است و امکان دسترسی مستقیم به مخازن قرار گرفته بر روی آن برای برنامه‌نویسان ایرانی ممکن نیست.در صورتی که در دسترسی به این سرویس مشکل دارید، این مطلب برای شماست. این مقاله شامل راه‌حل‌هایی کاربردی برای دسترسی به GitLab است که تابحال توسط سایر دوستان مطرح شده  و در ادامه آن راه‌حل پیشنهادی و مورد استفاده خودم را نیز بیان می‌کنم.در همین ابتدا ذکر این نکته خالی از لطف نیست که راه‌های زیادی برای عبور از محدودیت و عبور همه ترافیک سیستم از یک سرور واسط وجود دارد که موضوع بحث ما نیست. در این مقاله تمرکز فقط بر روی عبور دادن ترافیک و داده‌های مربوط به Git از یک سرور واسط است.راه‌حل ۱: تنظیم سرور http واسط بر روی Gitنرم‌افزار Git بدون نیاز به هیچ ابزار جانبی، امکان استفاده از یک سرور http واسط را جهت عبور دادن اطلاعات و ارتباط با سرورهای اصلی دارد.با وارد کردن کامند زیر در ترمینال می‌توان با تعیین آدرس آی‌پی و پورت سرور http واسط، از این قابلیت استفاده کرد.git config --global http.proxy http://username:password@server-ip:portپیدا کردن سرور واسط جهت رد کردن ترافیک و  دسترسی GitLab کار مشکلی نیست و  سرویس‌های نظیر FOD به صورت رایگان این خدمات را ارائه می‌کنند.البته در صورت تمایل می‌توان با استفاده از پروژه‌هایی مانند proxy-chain سرویس واسط اختصاصی جهت عبور دادن ترافیک Git راه‌اندازی کرد.نقاط قوتبا بکارگیری این روش تنها ترافیک Git از سرور واسط عبور می‌کند.با تعیین تنظیمات محلی بر روی هر پروژه Git می‌توان ترافیک پروژه‌های دلخواه را از این طریق به GitLab ارسال کرد.نقاط ضعفمخزن محلی باید با آدرس‌هایی از نوع http به مخزن اصلی متصل باشد؛ این روش راه‌حلی جهت تبادل اطلاعات با مخزن اصلی از طریق آدرس‌های ssh ارائه نمی‌کند.راه‌حل ۲: استفاده از SSH Tunnel و تنظیم سرور http واسط بر روی Gitدر صورتی که به یک سرور لینوکسی در خارج از ایران دسترسی SSH داشته باشید با استفاده از کامند زیر یک ارتباط امن بین سیستم شما و سرور برقرار خواهد شد:ssh username@server-ip -p server-port-number -D local-port-number
# ssh root@example.com -p 15222 -D 5555در صورت تمایل می‌توان سویچ‌های C- برای فشرده‌سازی، q- برای عدم نمایش هشدارها و پیام‌ها، N- برای اعلام عدم نیاز به اجرای دستورات و کامند بر روی سرور و f- برای انتقال پروسه به بکگراند را به دستور بالا اضافه کنیم. در اینصورت دستور بالا به شکل زیر خواهد شد:ssh username@server-ip -p server-port-number -D local-port-number -C -q -N -f -g
# ssh root@example.com -p 15222 -D 5555 -C -q -N -f -gاین دستور، پورت 5555 را بر روی سیستم شما باز می‌کند و کافی‌ست که Git را با دستور زیر برای عبور دادن ترافیک از پورت مورد نظر مطلع سازید:git config --global http.proxy &#039;socks5://127.0.0.1:5555&#039;توجه داشته باشید که در هنگام ارتباط و تبادل اطلاعات بین مخزن محلی به مخزن اصلی، باید ارتباط SSH برقرار و پورت 5555 بر روی سیستم شما باز باشد.نقاط قوتبا بکارگیری این روش تنها ترافیک Git از سرور واسط عبور می‌کند.با تعیین تنظیمات محلی بر روی هر پروژه Git می‌توان ترافیک پروژه‌های دلخواه را از این طریق به GitLab ارسال کرد.نقاط ضعفدسترسی به سرور لینوکسی در خارج از کشور مورد نیاز است.مخزن محلی باید با آدرس‌هایی از نوع http به مخزن اصلی متصل باشد؛ این روش راه‌حلی جهت تبادل اطلاعات با مخزن اصلی از طریق آدرس‌های ssh ارائه نمی‌کند.راه‌حل ۳ (پیشنهاد من): استفاده از SSH Tunnel و دستور proxychainsبرنامه proxychains امکان عبور دادن ترافیک سایر برنامه‌ها را از سرورهای واسط تعیین شده در فایل تنظیمات فراهم می‌کند.جهت استفاده از این برنامه کافی‌ست که در ترمینال و قبل از دستورات اصلی، عبارت proxychains را قرار دهیم تا تمامی درخواست‌های شبکه که در حین اجرای این دستورات مطرح می‌شوند، به کمک این برنامه از سرورهای واسط مدنظر عبور کنند.برای شروع با اجرای دستور زیر در اوبونتو یا دستورات مشابه در سایر لینوکس‌ها، بسته مربوط به برنامه را نصب می‌کنیم:sudo apt-get install proxychainsسپس به روش ذکر شده در «راه‌حل ۲» یک SSH Tunnel ایجاد کرده و با دستور زیر فایل تنظیمات proxychains را باز می‌کنیم:vi /etc/proxychains.confدر بخش [ProxyList] معمولا تعدادی تنظیم پیش‌فرض وجود دارد که بهتر است آن‌ها را حذف کنید. حال کافی‌ست با قرار دادن عبارت زیر، واسط مورد نظر را به proxychains معرفی کنید:socks5 127.0.0.1 5555فایل تنظیمات ذخیره کنید و از آن خارج شوید.از این پس برای ایجاد ارتباط بین مخزن محلی و مخزن GitLab کافی‌ست که دستور proxychains را در ابتدای دستورات Git ذکر کنیم. به عنوان مثال:proxychains git push origin master
proxychains git pull origin masterبا قرار گرفتن دستور proxychains در ابتدای دستورات Git، مخازن محلی پروژه به راحتی به مخازن موجود بر روی GitLab متصل خواهند شد.نقاط قوتاین روش برای همه نوع مخزن کار می‌کند و فرقی نمی‌کند که آدرس مخزن از نوع ssh یا http باشد.تنها ترافیک دستوراتی از Git که قبل از آن عبارت proxychains قرار گرفته است، از سرور واسط عبور می‌کند.نیازی به اعمال تنظیمات اضافی در Git وجود ندارد.نقاط ضعفدسترسی به سرور لینوکسی خارج از کشور مورد نیاز است.جمع‌بندیبا توجه به نقاط قوت و نقاط ضعف مطرح شده و در صورت دسترسی به سرور مناسب، برای دسترسی به سرویس GitLab «راه‌حل ۳» را پیشنهاد می‌کنم.آیا شما برای دسترسی به اینگونه سرویس‌ها، راه‌حل مناسب دیگری را سراغ دارید؟! لطفا آن را به اشتراک بگذارید تا جهت سهولت دسترسی سایرین، در ادامه مقاله ذکر شود.از توجه شما ممنونم :)</description>
                <category>امیر بشکار</category>
                <author>امیر بشکار</author>
                <pubDate>Thu, 23 Aug 2018 13:23:10 +0430</pubDate>
            </item>
                    <item>
                <title>پارادایم ‫CSS Modules، پیشنهادی که نمی‌توانید آن را رد کنید</title>
                <link>https://virgool.io/JavaScript8/%D9%BE%D8%A7%D8%B1%D8%A7%D8%AF%D8%A7%DB%8C%D9%85-css-modules-%D9%BE%DB%8C%D8%B4%D9%86%D9%87%D8%A7%D8%AF%DB%8C-%DA%A9%D9%87-%D9%86%D9%85%DB%8C%D8%AA%D9%88%D8%A7%D9%86%DB%8C%D8%AF-%D8%A2%D9%86-%D8%B1%D8%A7-%D8%B1%D8%AF-%DA%A9%D9%86%DB%8C%D8%AF-z790e7y7ehv2</link>
                <description>اجرا و کدنویسی ‫CSS با وجود سادگی و ساختار به ظاهر بدیهی، همواره یکی از چالش‌های جدی در پروژه‌های بزرگ وب است. اجرای کدهای CSS بدون هیچ پارادایم طراحی خاصی، همانند نوشتن کدهای اسپاگتی در بک‌اند و سایر نقاط پروژه است و نگهداری و توسعه پروژه در آینده را با چالش‌ مواجه می‌کند.  بکارگیری پارادایم استاندارد علاوه بر سازماندهی موثر کدها، امکان مشارکت سایر افراد تیم را در فرآیند توسعه با سهولت بیشتری فراهم می‌کند.پارادایم‌های استاندارد اجرای CSSبرای توسعه کدهای CSS با ساختار مناسب، پارادایم‌های مختلفی پیشنهاد و بکارگرفته شده‌اند که برخی از معروف‌ترین آن‌ها عبارتند از OOCSS،  SMACSS، BEM، CSS Modules و  Styled Components.هر کدام از این پارادایم‌ها ایده‌ها، نظرات و نقاط قوت و ضعف مخصوص به خود را دارند اما همگی بر روی ایجاد ساختار استانداردی با قابلیت استفاده مجدد و همچنین ایجاد قوانینی جهت سهولت در کار تیمی اتفاق نظر دارند.من تابه‌حال در طی پروژه‌های مختلف از پارادایم‌های OOCSS، SMACSS و BEM استفاده کرده‌ام و از میان این گزینه‌ها BEM ایده‌های توسعه‌یافته تری دارد؛ اما این آخرین پیشنهاد من نیست...پارادایم BEMاین پارادایم با معرفی سه مفهوم Block، Element و Modifier مدلی را برای ساخت بلاک‌های معنایی در صفحه ارائه می‌کند. بلاک‌های BEM از نظر مفهومی کاملا مستقل از هم پیاده‌سازی می‌شوند اما در صورت پیاده‌سازی صحیح، امکان ترکیب شدن آن‌ها و ساخت بلاک‌های پیچیده‌تر نیز وجود دارد.‫‫BEM پیشنهاد می‌کند که بلاک‌ها و حتی المان‌های کدنویسی شده، در فایل‌های مجزا و با ساختار مخصوصی نگهداری شوند تا علاوه بر سهولت در توسعه و نگهداری، امکان استفاده مجدد از آن‌ها در آینده و پروژه‌های دیگر میسر باشد.در کنار مزایای زیاد مانند خوانایی بالای کد و قابلیت کار تیمی، این مدل مشکلات خاصی دارد که برخی از مهم‌ترین آن‌ها به شرح زیر است:انتخاب نام مناسب و غیرتکراری برای کلاس‌ها بر عهده برنامه‌نویس است و این مساله کار توسعه را سخت می‌کند.نام کلاس‌ها کمی طولانی است و برای اعمال چند کلاس به یک تگ HTML کاراکترهای زیادی تایپ می‌شود.بخشی از منطق وارد دنیای CSS می‌شود و نام‌گذاری کلاس‌ها کاملا معنایی‌ست.استفاده از این روش برای افراد مشکل است و پیاده‌سازی کد خوب نیاز به تلاش بیشتری دارد.در صورت بزرگ شدن پروژه مدیریت بلاک‌ها و عدم تداخل آن‌ها نیاز به مدیریت جدی دارد.افراد برای استفاده از این مدل باید با مفاهیم سه‌گانه آن به خوبی آشنا باشند و تسلط به این مفاهیم کمی زمانبر است.با وجود ضعف‌های بالا، از نظر من باز هم پارادایم BEM برای پروژه‌های بزرگ مدل قابل استفاده‌ای است اما در حال حاضر روش‌های جدیدتر و مدرن‌تری مانند CSS Modules می‌تواند انتخاب مناسب‌تری باشد.پارادایم CSS Modulesاین پارادایم یکی از مدرن‌ترین روش‌های پیاده‌سازی CSS می‌باشد که در برنامه‌های مبتنی بر JS استفاده می‌شود. در مدل‌های جدید توسعه برنامه‌های JS، تمرکز بر ساخت اجزایی به نام کامپوننت است و ایده اصلی این پارادایم، نوشتن و نگهداری کدهای CSS در کنار کدهای JS استفاده کننده از آن می‌باشد.با استفاده از این روش کامپوننت‌های تولید شده علاوه بر کپسوله‌سازی روال‌های منطقی در درون خود، دارای استایل مناسب هستند و در صورت بکارگیری آن‌ها در پروژه‌های دیگر، نیاز به بارگذاری فایل‌های CSS مرتبط با آن‌ها به صورت مجزا وجود ندارد.مهم‌ترین مزایای این مدل به شرح ذیل است:کپسوله شدن مناسب کدهای CSS و JS مرتبط با آن در یک ماژول و ایجاد قابلیت استفاده مجددنگهداری فایل CSS مرتبط با هر کامپوننت در کنار آن جهت نگهداری ساده‌تر کدهارفع مشکل انتخاب نام منحصربفرد برای کامپوننت‌ها و ارائه راه‌حلی برای نامگذاری خودکارتولید نام‌های کوتاه‌تر برای کلاس‌ها (به نسبت BEM)ارائه قابلیت خارق‌العاده‌ای به نام compose برای ترکیب چندین کلاس CSS و ساختن کلاس‌های ترکیبی و کاربردیامکان تعریف کلاس‌های CSS به صورت محلی و فقط برای کامپوننت مورد نظرارائه پیشنهاداتی جهت نامگذاری مناسب کلاس‌ها در کد و واگذاری تصمیم‌گیری نهایی به تیم توسعه دهندهامکان ترکیب شدن و استفاده از سایر پارادایم‌ها در پیاده‌سازی CSS محلی برای هر کامپوننتامکان یادگیری و استفاده سریع برای افراد به دلیل سینتکس بسیار سادهشاید در ابتدای آشنایی با این پارادایم، مدل کدنویسی آن و به خصوص ترکیب فایل‌های CSS با JS خوشایند همه افراد نباشد اما نباید فراموش کنیم که در سال‌هایی نه چندان دور، ترکیب تگ‌های HTML با JS و تولید کدهای قالب با جاوااسکریپت اصلا معمول نبود و گاهی خطایی مهلک محسوب می‌شد اما امروزه در مدل‌های توسعه جدید و بواسطه ابزارهایی نظیر JSX، این امر کاملا پذیرفته شده و منطقی‌ست. مسلما این اتفاق با وجود دلایلی معقول و کارآمد برای CSS نیز قابل تکرار شدن است و دور از انتظار نیست.نتیجه‌گیری‫‫CSS Modules با توجه به سادگی استفاده، قابلیت تولید کدهایی با استفاده مجدد و همچنین ایجاد راهکاری برای توسعه CSS با همکاری تیم، گزینه مناسب‌تری نسبت به BEM برای پروژه‌های بزرگ است و استفاده از آن را به شدت توصیه می‌کنم.همچنین روش پیشرفته Styled Components نیز وجود دارد که تمام مزایای CSS Modules را در خود داشته و به دلیل نوشتن مستقیم کدها و خصوصیات CSS در فایل‌های JS، ساختار متفاوتی دارد و نیازمند بررسی و تجربه بیشتری است.با توجه به اینکه مطالب بیان شده حاصل تجربیات شخصی من است، همواره مشتاق شنیدن نظرات و تجربیات شما و انجام بحث در این باره هستم.از توجه شما ممنونم :)</description>
                <category>امیر بشکار</category>
                <author>امیر بشکار</author>
                <pubDate>Mon, 30 Jul 2018 12:24:09 +0430</pubDate>
            </item>
                    <item>
                <title>‫SSR: پایان کابوس بارگذاری صفحات خالی از محتوا در React ،Vue.js و AngularJS</title>
                <link>https://virgool.io/iran-react-community/%D9%85%D8%B9%D8%B1%D9%81%DB%8C-ssr-%D9%88-%D8%B1%D9%81%D8%B9-%D9%85%D8%B4%DA%A9%D9%84-%D8%A8%D8%A7%D8%B1%DA%AF%D8%B0%D8%A7%D8%B1%DB%8C-%D8%B5%D9%81%D8%AD%D8%A7%D8%AA-%D8%AE%D8%A7%D9%84%DB%8C-%D8%A7%D8%B2-%D9%85%D8%AD%D8%AA%D9%88%D8%A7-%D8%AF%D8%B1-react-vuejs-%D9%88-angularjs-qygkfn4b0c01</link>
                <description>با تغییرات بنیادین تکنولوژی‌های وب به تدریج ماهیت و ساختار آن دست‌خوش تغییرات شده است و صفحات استاتیک HTML به تدریج به صفحاتی پویا و در تعامل بیشتر با کاربر تبدیل شده‌اند. به تدریج و با گذر زمان توسعه‌دهندگان کدهای بیشتری را در سمت کاربر و به زبان جاوااسکریپت نوشتند و وبسایت‌ها تبدیل به اپلیکیشن‌های بزرگ جاوااسکریپتی شدند. برای استانداردسازی، کاهش میزان پیچیدگی و افزایش توسعه‌پذیری کدهای این برنامه‌ها، فریم‌ورک‌ها، کتابخانه‌ها و راه‌حل‌های مختلفی نظیر React، AngularJS، Vue.js و ... ارائه شد.مدل SPA و نقص بارگذاری صفحات خالی از محتوا‫SPA مخفف Single Page Application است. در این مدل یک اپلیکیشن جاوااسکریپت برای اجرا در مرورگر کاربر ایجاد می‌شود و مسئولیت کامل تولید تگ‌های HTML، قالب‌بندی سایت و نمایش محتوای مورد نیاز کاربر را بر عهده می‌گیرد. بخشی از برنامه که بر روی سرور قرار دارد با تعبیه APIهایی، محتوای لازم را در اختیار برنامه سمت کاربر می‌گذارد. تاکنون برنامه‌های محبوب زیادی بر اساس مدل SPA پیاده‌سازی شده‌اند که Gmail یکی از قدیمی‌ترین نمونه‌هاست و بدون نیاز به بارگذاری کردن و دریافت مجدد صفحه از سرور، بخش‌ها و اطلاعات مختلفی را در اختیار کاربران خود قرار می‌دهد.برنامه‌های SPA از نظر فنی دارای یک صفحه HTML خالی از محتوا هستند که به فایل‌های JS و CSS مورد نیاز لینک شده است. این صفحه پس از بارگذاری بر روی مرورگر مخاطب، اپلیکیشن JS مربوطه را اجرا می‌کند. کدهای جاوااسکریپت نوشته شده، محتوای مناسب را با فراخوانی APIهای در دسترس جمع‌آوری نموده و با به‌کارگیری الگوهای از پیش تعیین شده، کدهای HTML قالب و صفحات سایت را به صورت داینامیک تولید می‌کنند.مشکل اساسی برنامه در این مرحله، نقص بارگذاری صفحات خالی از محتواست که به دلایلی از قبیل خالی بودن فایل HTML دریافت شده از سرور، حجیم بودن فایل‌های JS مرتبط، تاخیر ناشی از انتظار برای دریافت محتوای مورد نیاز از API و همچنین پیچیدگی و زمان‌بر بودن فرآیند تولید کدهای قالب، کاربر در لحظات اول بارگذاری سایت با یک صفحه خالی از محتوا مواجه می‌شود. این اتفاق به هیچ وجه برای کاربر خوشایند نبوده و تاثیر منفی بر روی SEO وبسایت و عملکرد برخی Crawlerهای مهم وب نیز دارد و باعث می‌شود که سایت در برخی شاخص‌های SEO مانند بارگذاری سریع صفحات، امتیاز قابل قبولی دریافت نکند.تکنیک SSR، راه‌حل مقابله با صفحات خالی از محتوا‫SSR مخفف Server Side Rendering و تکنیکی جهت تولید محتوای اولیه مناسب و تگ‌های صفحات وب در برنامه‌های مبتنی بر SPA است. در این روش به جای ارسال صفحه HTML خالی از محتوا به کاربر، یک بار کدهای جاوااسکریپت برنامه SPA بر روی سرور اجرا می‌شود و کدهای HTML تولید شده به همراه محتوای مناسب در قالب فایل HTML در اختیار کاربر قرار می‌گیرد.پس از دریافت فایل HTML توسط کاربر، فایل JS مرتبط، مجدداً در مرورگر اجرا خواهد شد و اپلیکیشن جاوااسکریپتی، کنترل ادامه فرآیند را بر عهده می‌گیرد. در واقع در این مدل اولین تولید کد و ساخت اولیه قالب به سرور محول می‌شود و پس از آن تعامل با کاربر و بروزرسانی بخش‌های مختلف قالب، به عهده نسخه کلاینت خواهد بود.کاربران سایت در این روش، در حداقل زمان ممکن و با دریافت اولین پاسخ از نرم‌افزار، اطلاعات مورد نیاز خود را دریافت خواهد کرد و معطل اجرای کدهای JS و فرآیندهای تکمیلی اجرای کامل SPA نخواهند شد. همچنین در صورت غیرفعال بودن جاوااسکریپت بر روی مرورگر، باز هم قادر است نسخه HTML سایت را ببیند.نحوه پیاده‌سازی SSR در سایتاولاً برای استفاده از SSR در اپلیکیشن‌های SPA، باید حتما کتابخانه یا فریم‌ورک سمت کلاینت مورد استفاده ما مفهوم Isomorphic را پشتیبانی کند. خوشبختانه اکثر این ابزارهای معروف مانند React و AngularJS و ... از این مفهوم پشتیبانی می‌کنند و جای نگرانی نیست.ثانیاً برای عملیاتی شدن این روش، نیازمند اجرای کدهای جاوااسکریپتی اپلیکیشن SPA بر روی سرور هستیم. بنابراین به Node.js نیاز داریم.مراحل بارگذاری و تکمیل محتوای صفحه در مدل SSRدر حالت ایده‌آلی که برنامه‌ی بک اند سایت نیز با استفاده از جاوااسکریپت و ابزارهایی نظیر Express.js و ... پیاده‌سازی شود، دردسر چندانی برای انجام SSR نخواهیم داشت و با کمی کدنویسی بیشتر، بخش‌هایی از کدهای برنامه SPA اجرا خواهد شد و خروجی HTML مورد نیاز را تولید می‌کند.مراحل بارگذاری و تکمیل محتوای صفحه در مدل CSRدر صورتی که برنامه بک اند، با تکنولوژی‌هایی غیر از Node.js پیاده‌سازی شده باشد باز هم امکان به‌کارگیری SSR وجود دارد. در این حالت نیاز است که از پروژه‌ای مانند proxy-render کمک بگیریم و یا یک پروژه جانبی مبتنی بر ابزارهایی نظیر Express.js ایجاد شود تا با اجرا در کنار برنامه بک اند اصلی، ضمن دریافت پارامترها و متغیرهای حاوی اطلاعات مناسب، مسئولیت اجرای کدهای برنامه SPA و تولید خروجی HTML را بر عهده بگیرد.نتیجه‌گیریهمانطور که گفته شد، نقص بارگذاری صفحات خالی از محتوا در برنامه‌های SPA، با اثر منفی‌ای که بر تجربه کاربری مخاطبین می‌گذارد و همچنین تاثیر منفی بر SEO، می‌تواند به کابوس شبانه مدیران وبسایت‌ها بدل شود. استفاده از روش SSR راه حل بسیار موثری است و استفاده از آن را به شدت توصیه می‌کنم.با توجه به اینکه مطالب بیان شده حاصل تجربیات شخصی من است، همواره مشتاق شنیدن نظرات و تجربیات شما و انجام بحث در این باره هستم.از توجه شما ممنونم :)</description>
                <category>امیر بشکار</category>
                <author>امیر بشکار</author>
                <pubDate>Sun, 17 Jun 2018 14:25:09 +0430</pubDate>
            </item>
                    <item>
                <title>پایتون برای تازه‌کارهای وب؟ هرگز! به این ۶ دلیل</title>
                <link>https://virgool.io/@am1rb/%DB%B6-%D8%AF%D9%84%DB%8C%D9%84-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%A7%DB%8C%D9%86%DA%A9%D9%87-%D9%BE%D8%A7%DB%8C%D8%AA%D9%88%D9%86-%D9%85%D9%86%D8%A7%D8%B3%D8%A8-%D8%AA%D8%A7%D8%B2%D9%87-%DA%A9%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D9%88%D8%A8-%D9%86%DB%8C%D8%B3%D8%AA-udi1wmdtdqrz</link>
                <description>این روزها افراد زیادی به دنبال پیدا کردن مسیری برای شروع یادگیری برنامه‌نویسی وب هستند. کتاب‌ها، مقاله‌ها، ویدئوهای آموزشی و سایت‌های زیادی برای آموزش مفاهیم به افراد علاقه‌مند وجود دارد و هر کدام بنا بر تجربه و مهارت‌شان روشی را معرفی می‌کنند.با وجودی که برخی افراد و روش‌ها مدعی آموزش بسیار سریع و کاربردی مفاهیم هستند، اما از نظر من با توجه به گستردگی و پیچیدگی مباحث وب، منطقاً هیچ راه سریع و یک روزه‌ای برای یادگیری عمیق همه مفاهیم وجود ندارد.با افراد تازه‌کار زیادی مواجه شده‌ام که به دنبال یادگیری بهترین زبان برنامه‌نویسی برای استفاده در زمینه‌های مختلف بوده‌اند که به پیشنهاد بسیاری از متخصصین در اغلب موارد «پایتون» به عنوان یکی از اولین گزینه‌ها برای شروع یادگیری مطرح می‌شود.پایتون ویژگی‌های منحصر بفردی از جمله کتابخانه‌های خوب و قوی، سینتکس نزدیک به زبان انسان، اجرا بر روی دستگاه‌ها و پلتفرم‌های مختلف، نمونه‌کدهای فراوان، خوانایی و… دارد و گاهی چند خط کد پایتونی، معادل چند ده خط کد در سایر زبان‌هاست و این مساله باعث می‌شود که پایتون ابزار مناسبی برای پیاده‌سازی و اجرای پروژه‌ها و ایده‌های شخصی افراد باشد.اما آیا واقعا «پایتون» برای شروع برنامه‌نویسی وب مناسب است؟ جواب کوتاه و صریح من در یک کلمه: نه!  به این ۶ دلیل.۶ دلیل نامناسب بودن پایتون برای شروع برنامه‌نویسی وب۱- همیشه سادگی در نوشتن کد کافی نیست، باید بتوان راحت آن را اجرا کرد!همه دوست دارند هرچه سریع‌تر اولین وبسایت‌شان را بسازند و نتیجه کارشان را با لذت به دیگران ارائه کنند. «پایتون» در زمان توسعه و ساخت برنامه، شما را به تحقق این رویا نزدیک می‌کند اما زمان اجرا بر روی سرور است که تازه دردسر شما آغاز می‌شود.واقعیت این است که اجرای یک اپلیکیشن پایتونی بر روی سرور، دردسرهای خاص خودش را دارد و به راحتی آپلود کردن فایل‌ها و سپس اجرا شدن کدها توسط وب‌سرور نیست و نیاز به ملزومات بیشتری برای اجرای برنامه وجود دارد.شاید بهتر باشد که در شروع یادگیری، به جای دست به گریبان شدن با انواع اقسام مشکلات فنی، بر روی ساخت برنامه تمرکز کنیم و زمان‌مان را صرف توسعه قابلیت‌های اصلی برنامه و همچنین یادگیری چیزهای جدید کنیم تا اینکه با این مشکلات سر و کله بزنیم. ابزار و زبان انتخاب شده نباید ما را که در ابتدای راه هستیم، گرفتار موارد حاشیه‌ای و اجرا کند!۲- استقرار آن تنها بر روی هاست ویژه ممکن استاول از همه یک وبسایت پایتونی برای اجرا نیاز به هاست ویژه‌ای دارد که باید ابزارها و سرویس‌هایی نظیر Gunicorn ، uWSGI ، Supervisor بر روی آن نصب شده باشد. علاوه بر آن وب‌سرور نیز نیاز به اعمال تنظیمات خاصی دارد تا درخواست‌های کاربران را دریافت و جهت پردازش به سایت پایتونی شما تحویل دهد.البته روش‌هایی مانند CGI وجود دارد که بواسطه آن‌ها می‌توانیم کدهای خودمان را به راحتی اجرا کنیم اما به دلیل مشکلاتی نظیر اتلاف منابع، استفاده از آن برای استقرار نسخه نهایی روی سرور اصلی به هیچ وجه توصیه نمی‌شود.بنابراین برای آنلاین کردن سایت نیاز به خرید هاست ویژه پایتون دارید و یا باید سرور VPS خودتان را نصب و راه‌اندازی کنید که برای یک توسعه‌دهنده تازه‌کار، کار ساده‌ای نیست.۳- هزینه استقرار در کنار هزینه توسعه اهمیت دارد در ماه‌های اولیه آموزش چیزهای جدید زیادی یاد می‌گیریم و ممکن است چندین برنامه کوچک و بزرگ را برای آزمودن مواردی که جدیدا یاد گرفتیم بنویسیم.برنامه‌های پایتونی برای اجرا نیاز به هاست ویژه دارد که هزینه‌های آن بیشتر است و نمی‌توانیم از هاست‌های اشتراکی کم هزینه و ارزان معمول برای استقرار آن‌ها استفاده کنیم. از طرفی ممکن است هاست مورد نظر محدودیت‌هایی از قبیل تعداد برنامه‌های پایتونی در حال اجرا و دردسرهای شبیه این نیز داشته باشد.۴- به راحتی نمی‌توانی سیستم خودت را بسازی اگر می‌خواهی در استفاده از یک ابزار به درجه استاد تمام برسی، باید یک بار ابزاری را مشابه با آن بسازی تا با اکثر چالش‌ها، محدودیت‌ها و نقاط قوتش آشنا شوی. مسلماً ابزار آزمایشی ما در رقابت با ابزارهای حرفه‌ای موجود حرفی برای گفتن ندارد اما درک و تجربه ما را بسیار بهتر خواهد کرد. برنامه‌های اسپاگتی اولیه پر از اشکالات و خطاهای مختلف هستند اما در کنار همه بدی‌ها و معایبش در شرایط معمولی کار می‌کنند و قدرت تجربه کردن و آزمون و خطا را به ما می‌دهد.در پایتون ساختن یک برنامه وب از پایه و بدون هیچ ابزار و فریم‌ورکی نسبت به زبان‌های دیگر سخت‌تر است و نیاز به دانش فنی و مهارت بیشتری دارد. در زبان‌های برنامه‌نویسی که برای وب ساخته شده‌اند تمامی ساختارها و مفاهیم مورد نیاز وب کاملا پیاده‌سازی شده و آماده استفاده هستند اما به این دلیل که پایتون مختص وب نیست، برای توسعه اپلیکیشن‌های اولیه نیازمند انجام کار بیشتر و طی مراحل آماده‌سازی از قبیل نصب یا پیاده‌سازی ماژول‌هایی جهت انجام امور پایه هستیم.به عنوان مثال توابع لازم جهت نگهداری و بازیابی اطلاعات کاربر در Session به طور پیش‌فرض در زبان‌های مخصوص وب نظیر PHP وجود دارد و بدون هیچ دردسری آماده استفاده است اما در پایتون حداقل نیازمند یافتن و نصب ماژول‌هایی جهت ایجاد این قابلیت هستیم.۵- ابزارهای پایتونی برای شروع پیچیده هستندبا توجه به مورد قبلی منطقی است که سراغ فریم‌ورک‌ها و ابزارهای موجود برویم اما از قدیم گفته‌اند که «سنگ بزرگ نشانه نزدن است»، لااقل در این مورد نشانه‌ی درست نزدن! ما در شروع کار باید بتوانیم روی مفاهیم اصلی و ضروری تمرکز کنیم. مواجه شدن با ابزارهایی که خودش دارای پیچیدگی هست و نیاز به یادگیری دارد می‌تواند ما را دچار دردسرهای مضاعف کند.البته معتقدم مسیر توسعه اصولی در دنیای وب، از میان فریم‌ورک‌ها و ابزارهای کارآمد موجود می‌گذرد اما  برای کسی که تازه وارد دنیای برنامه‌نویسی وب شده است و درک کاملی از ابزارها و فرآیندها ندارد، مشکلات زیادی را به همراه خواهد آورد.۶- اپلیکیشن‌های پایتون مدل اجرایی متفاوتی دارنددر مدل اولیه وب CGI، به ازای هر درخواست مطرح شده از سوی کاربر یک بار برنامه سایت اجرا می‌شود و پس از تولید خروجی نهایی، این برنامه خاتمه پیدا می‌کند. این مدل بسیار ساده و قابل فهم است و نوشتن برنامه در این مدل کار بسیار ساده‌ای است. البته این مدل به دلیل مشکلی که در اتلاف منابع سرور دارد با مدل پیشرفته‌تر FastCGI جایگزین شده اما اصول و مفاهیم اصلی در نوشتن برنامه تحت وب تغییری نکرده و برنامه‌های سازگار با CGI در مدل FastCGI بدون مشکل اجرا می‌شوند.در مدل پایتونی داستان اجرا کاملا متفاوت است و برنامه سایت تنها یک بار و در شروع کار اجرا می‌شود و از آن پس به تمام درخواست‌های کاربران که از سمت وب‌سرور در اختیارش قرار گرفته است پاسخ خواهد داد. در این شرایط اگر در کدنویسی برنامه سایت، خطای ساختاری یا منطقی وجود داشته باشد احتمال مواجهه با خطا برای مراجعین بعدی دور از ذهن نیست.در نتیجه طراحی این مدل اپلیکیشن‌ها تجربه و دقت بیشتری لازم دارد و همینطور مدیریت خطای بسیار بهتری را می‌طلبد تا با مواجه شدن با اولین خطا، نرم‌افزار متوقف نشود.نتیجه‌گیری«پایتون» برای افراد تازه کار و شروع برنامه‌نویسی وب مناسب نیست و نه تنها توسعه پروژه را تسهیل نمی‌کند بلکه با قرار دادن مشکلات و موانعی بر سر راه توسعه‌دهنده، آن را از ادامه مسیر مایوس خواهد کرد.در عوض «پایتون» برای افراد با تجربه که درک خوبی از مفاهیم پایه وب دارند و به دنبال ایجاد برنامه‌هایی خوانا و خوش‌ساخت هستند، گزینه بسیار مناسب و ایده‌آل به شمار می‌رود. پایتون کتابخانه‌ها و فریم‌ورک‌های بسیار قدرتمندی برای وب دارد که استفاده از ‌آن‌ها در کنار قابلیت‌های منحصربه‌فردش سرعت اجرای پروژه‌های شما را چندین برابر می‌کند. از طرفی با داشتن دانش کافی و استفاده از یک معماری درست و به‌کارگیری تجربیات گذشته می‌توانیم سیستم‌های بزرگ و قدرتمندی را به وسیله زبان پایتون پیاده‌سازی کنیم.آیا شما هم با دلایل بالا موافق هستید؟ با توجه به اینکه دلایل بالا حاصل تجربیات شخصی من است، مشتاق شنیدن نظرات و تجربیات شما در این باره هستم.</description>
                <category>امیر بشکار</category>
                <author>امیر بشکار</author>
                <pubDate>Sat, 09 Jun 2018 17:14:38 +0430</pubDate>
            </item>
            </channel>
</rss>