نوشته های علیرضا ریاحی

مقدمه‌ای بر الگوی Backend For Frontend یا BFF قسمت دوم (نهایی)

علیرضا ریاحی — Sat, 27 Mar 2021 13:53:19 +0430

در مقاله قبل که با عنوان مقدمه‌ای بر الگوی Backend For Frontend یا BFF قسمت اول منتشر شد به کلیات الگوی BFF و شرایط استفاده از آن پرداختیم. به طور کلی هدف BFF ایجاد راه‌حلی بود که frontend بر روی پیاده‌سازی ظاهر(interface) متمرکز باشد، نه تسویه و قالب‌بندی اطلاعات دریافتی از سمت سرور. در این مقاله قصد داریم کمی تخصصی‌تر به آن نگاه کنیم:آیا امکان استفاده از چند BFF هم هست؟اصلا بهترین روش استفاده از BFF همین‌گونه خواهد بود. در روش‌های سنتی api نویسی چه اتفاقی رخ می‌داد؟ ما تنها یک درگاه api داشتیم برای پاسخ به همه پلتفرم‌ها(اعم از وب، android, ios و...). روش سنتی پیاده‌سازی api serverدر شکل بالا همه انواع کاربران (انواع پلتفرم‌ها) درخواست خود را به یک سرور می‌فرستند و طبیعتا همه یک پاسخ یکسان دریافت می‌کنند. به عنوان مثال ممکن است ما برای مدیریت مصرف پهنای‌باند کاربری که با موبایل وصل شده و کاربری که با مرورگر دسکتاپ وصل شده تفاوتی قائل باشیم. برای این امر یا باید برای یک کار واحد که فقط میزان دیتای انتقالی آن متفاوت است از سرور اصلی دو api داشته باشیم که به نوبه خود باعث مشکلاتی در آینده خواهد شد، یا برای هر نوع پلتفرم یک BFF مستقل داشته باشیم تا با استفاده از آن اطلاعات منطبق با پلتفرم خود را دریافت کند.الگوی پیاده‌سازی چند BFF برای چند پلتفرمدر شکل بالا نحوه پیاده سازی چند BFF که هر کدام قرار است یک نوع از پلتفرم‌ها را پشتیبانی کند می‌بینیم.برخی از مزایای الگوی BFFتفکیک دغدغه: همواره یکی از دغدغه‌های مهم تیم سرور(backend team)، نیازهای تیم کلاینت (frontend team) بابت قالب‌بندی‌ها، سورت کردن‌ها، تجمیع کردن چند پاسخ در یک درخواست و ... است که عموما باعث می‌شود دغدغه‌های کلاینت و سرور تلفیق شوند. با این الگو امکان تفکیک این دغدغه‌ها تا حدود زیادی حاصل می‌شود و همچنین نگهداری و پشتیبانی از هر دو سمت سرور و کلاینت را بسیار راحت‌تر خواهد کرد.سهولت بیشتر در تغییرات apiها: خیلی مواقع تیم سرور مجبور به تغییراتی در apiها بنا بر ملاحضات امنیتی یا راندمان و ... است. عموما این تغییرات باعث می‌شود تیم کلاینت هم مجبور شود خود را با قالب‌بندی جدید اطلاعات هماهنگ کند. از طریق این الگو می‌توان تغییرات سمت سرور را راحت‌تر پیش برد و در نهایت هنگام ارسال اطلاعات به کلاینت در لایه BFF کمی تغییرات داشت و اطلاعات را به شکل سابق به کلاینت ارسال کرد.بهینه‌تر کردن مدیریت خطاها (error handling) در سمت کاربر: خیلی مواقع ارورهای سمت سرور به صورت مستقیم برای کاربر ارسال می‌شوند و در اکثر موارد هم صورت خوشی ندارند. مثلا پیام server error دریافت می‌شود. در صورتی هم که سیستم پاسخ‌دهی به ارورها سمت سرور پیاده‌سازی شده باشد، این بار اضافی به سرور اصلی تحمیل می‌کند. ماژول مدیریت خطاها می‌تواند در لایه BFF پیاده سازی شود و از سرور صرفا یک کد خطای مشخص بگیرد، در BFF بسته به زبان کاربر (مثلا انگلیسی، فارسی یا ...) پیام مناسب را برای کلاینت ارسال کند و کلاینت هم آن را به کاربر نمایش دهد.امنیت بیشتر: بعضا پیش آمده که تیم سرور اطلاعاتی غیر ضروری را ارسال کرده که به درد کلاینت هم نخورده و همان امنیت سیستم را با خطر مواجه کرده. در لایه BFF یک‌بار اطلاعات چک می‌شود و صرفا اطلاعات ضروری برای کلاینت ارسال می‌گردد. همچنین همواره سرورهای اصلی شما و پایگاه‌داده پشت BFF قرار گرفته و در صورت حمله، همه اطلاعات در پشت BFF قرار دارد. با این الگو کار برای مهاجمان سخت‌تر خواهد شد.برخی از نکات مهم هنگام پیاده‌سازی BFFحواستان باشد BFF یک لایه میانی و صرفا یک مترجم است! ممکن است برخی اشتباها برنامه خود را از پیاده‌سازی BFF شروع کنند. دقت کنید شما قرار است ابتدا میکروسرویس‌ها و apiها خود را با دقت پیاده‌سازی کنید و بعدا به پیاده‌سازی BFF بر اساس نیاز‌های کلاینت بپردازید. نحوه ورود اشتباه به مسئله باعث می‌شود از آرمان‌های این الگو باز بمانیم.از پیاده سازی منطق‌های یکسان پرهیز کنید. همیشه ممکن است ما یک سری درخواست با منطق مشترک بین کاربران پلتفرم‌های مختلف داشته باشیم. طبیعتا باید یک BFF عمومی هم داشته باشیم تا موارد مشترک به آن درخواست بدهدند و نیازی نباشد مثلا برای android و ios همواره دو BFF داشته باشند که همه end pointها را به صورت تکراری در بر بگیرند.دقت کنید BFF قرار نیست باعث شود از امنیت سمت سرورهای اصلی غافل شویم. BFF صرفا یک لایه مترجم هستند و قرار نیست باعث به وجود آمدن احساس امنیت کاذب در سرور شوند. سرور باید بدون در نظر گرفتن وجود لایه BFF تمام ملاحظات امنیتی را در نظر بگیرد و از اعتماد بی‌جا به BFF اجتناب کند.

مقدمه‌ای بر الگوی Backend For Frontend یا BFF قسمت اول

علیرضا ریاحی — Sun, 21 Mar 2021 16:16:39 +0330

Web Application Design Patternتصور کنید قرار است یک فروشگاه اینترنتی داشته باشیم که با معماری Rest پیاده سازی شود. طبیعتا apiهایی برای قسمت مشتریان، محصولات، فاکتورها، سفارشات و ... خواهیم داشت که از طریق آن‌ها اطلاعات برای کلاینت (frontend) ارسال خواهد شد.در چنین سناریویی معمولا پیش می‌آید که اطلاعات ارسالی توسط سرور دقیقا هماهنگ با کلاینت (frontend) نباشد. به عبارت دیگر فیلترها یا قالب (format) ارسال شده از طرف apiها دقیقا همان نیاز کلاینت (frontend) نیست.در این صورت در سمت کلاینت، اطلاعات ارسالی توسط apiها باید مجدد به قالبی که مورد نیاز کلاینت است تغییر داده شود که این باعث استفاده بیش از حد از منابع مرورگر یا به صورت دقیق‌تر منابع کاربر فروشگاه خواهد شد. بدیهی است در خیلی از موارد یا امکان تغییر در سمت سرور وجود ندارد یا این تغییر باعث می‌شود تا فشار تغییر قالب اطلاعات بر روی منابع سمت سرور باشد که امری صد در صد اشتباه است.در چنین شرایطی می‌توان از الگوی BFF استفاده کرد تا به‌جای فشار بر مرورگر و سیستم بازدیدکنندگان سایت، در یک لایه میانی، تغییر قالب (reformat) انجام شود و اطلاعات طبق قالب مورد نیاز کلاینت ارسال گردد. در حقیقت کلاینت درخواست خود را برای لایه میانی BFF ارسال می‌کند و BFF درخواست را برای سرور. پس از دریافت اطلاعات از سرور لایه میانی BFF شروع به تغییر فرمت به نحوی که مورد نیاز کلاینت است می‌کند و سپس آن را برای کلاینت ارسال می‌کند.Backend For Frontend (BFF) لایه میانی BFF مسئول انجام امور زیر است:ارتباط با apiهای سرور و گرفتن اطلاعات از آن‌هاتغییر قالب (format) اطلاعات بر اساس نیاز کلاینت (frontend)ارسال اطلاعات قالب‌بندی (formatted data) شده کلاینتهمان‌طور که گفته شد BFF به عنوان یک رابط ساده بین frontend و backend عمل خواهد کرد. پس با این حساب هر BFF باید مبتنی بر نیاز frontend طراحی و پیاده‌سازی شود تا کمترین نیاز به پیاده سازی کدهای منطقی را داشته باشد. مثلا ممکن است در نسخه موبایل فروشگاه اینترنتی اطلاعاتی لازم نباشد اما در نسخه دسکتاپ این اطلاعات مورد نیاز باشد. حالا بر اساس منطق BFF که تلاش دارد استفاده از منابع سمت کاربر را به حداقل برساند موضوع را تحلیل کنید. نتیجه این خواهد بود که ما باید بجای یک درخواستی که قبلا برای نسخه موبایل و دسکتاپ به یک api می‌زدیم (مثلا لیست فاکتورهای مشتری) یک درخواست متناسب با نیاز نسخه موبایل به BFF بزنیم و یک درخواست هم برای نسخه دسکتاپ. البته که BFF هر دو درخواست را در قالب یک درخواست به همان api سرور خواهد زد، اما در بازگرداندن اطلاعات، متناسب با نیاز کلاینت اطلاعات را قالب‌بندی و ارسال می‌کند.آیا الگوی BFF باعث تاخیر در دریافت اطلاعات نمی‌شود؟پاسخ این سوال قطعا مثبت است! اما باید این تاخیر را در مقایسه‌ با تاخیر قالب‌بندی مجدد اطلاعات در سمت کاربر در نظر گرفت. در نظر بگیرید ممکن است یا اپلیکیشن موبایل شما زمان زیادی صرف قالب‌بندی مجدد اطلاعات کند یا وب‌سایت شما. چون اطلاعات ارسالی توسط سرور در بهترین حالت مناسب برای یکی از نسخه‌ها خواهد بود. یا باید این تاخیر را بین همه نسخه‌ها به صورت جزئی تقسیم کرد یا در موثرترین روش یکی از نسخه‌ها با سرعت مناسب‌تری کار کند و دیگر نسخه‌ها با تاخیر خیلی بیش‌تر. باید در نظر بگیرید که در این حالت ما منابع زیادی هم از مرورگر و مشتریان را مصرف می‌کنیم! طبیعتا یک تاخیر جزئی و نامحسوس قابل اغماض خواهد بود.یکی دیگر از مزایای استفاده از چنین الگویی این خواهد بود که کلاینت می‌تواند به جای چندین در خواست در برخی صفحات، یک درخواست را به BFF بفرستد و BFF هر تعداد درخواست مورد نیاز را به سرور بزند، اطلاعات را در قالبی که مورد نیاز است یک‌پارچه کند و برگرداند. این مورد مخصوصا برای ارتباط‌های غیر مطمئن نظیر اینترنت موبایل و ... می‌تواند بسیار کاربردی باشد.چه زمانی باید از BFF استفاده کرد؟مانند همه الگوهای برنامه‌نویسی، استفاده از این الگو باید بر اساس معماری‌ای که قصد دارید پیاده سازی کنید بررسی شود. مثلا اگر یک برنامه یک‌پارچه و ساده‌ای را داریم استفاده از BFF خیلی مناسب نیست و ارزش آن‌چنانی‌ای به برنامه ما نخواهد افزود. اما اگر برنامه شما در حال استفاده از میکروسرویس‌های متعدد و apiهای داخلی و خارجی گوناگون است، استفاده از BFF برای ساده‌سازی جریان اطلاعات و افزایش راندمان frontend توصیه می‌شود.همچنین در شرایطی که درخواست‌های سمت سرور بالا خواهد بود، استفاده از BFF می‌تواند یک راه حل ساده باشد تا بار اضافی قالب‌بندی اطلاعات در سمت سرور به صورت کامل به لایه میانی یا همان BFF منتقل شود و سرور با سرعت بیشتری به کارهای اصلی نظیر بررسی سطح دسترسی‌ها، فراخوانی اطلاعات از پایگاه‌داده و ... بپردازد.در صورتی که این الگو برای شما جذاب است و می‌خواهید از آن استفاده کنید، در پست بعدی بیش‌تر در مورد BFF توضیح خواهم داد.

کرونا در سازمان ما

علیرضا ریاحی — Sat, 27 Jun 2020 03:22:57 +0430

هر بحرانی دو طرف دارد یک طرفی که همه می‌بینند و آن آسیبی است که از آن بهره‌مند می‌شوند، یکی هم فرصتی که برای ما ایجاد می‌کند و معمولا مغفول است!شرکت فیودو با هدف انجام پروژه‌های نرم‌افزاری از دو سال پیش شروع به فعالیت کرد و سپس استدیوی طراحی UI/UX را به مجموعه خود اضافه کرد. پس از چند ماه و انجام چند پروژه داخلی موفق شدیم وارد حوزه خام فروشی نرم‌افزار در بازار آمریکا و اروپا شویم. (خام فروشی نرم‌افزار دقیقا مانند خام فروشی نفت، به معنی انجام پروژه‌های نرم‌افزاری برای شرکت‌های خارجی است) وضعیت ما رو به بهبود بود و بعد این دو سال تازه داشتیم از محصول تجربیاتمان برای رشد بهتر بهره می‌بردیم که موج کرونا وارد فضای کسب و کارهای ایران شد. این مقدمه برای این بود که خواننده درک بهتری از سازمان ما داشته باشد.شرایط شکننده اقتصادی کشور ما (افزایش قیمت دلار از ۱۵ هزار تومان تا بیش از ۲۰ هزار تومان طی دو هفته) که افزون شده بر آسیب‌های اقتصادی کرونا در جهان، عرصه را بر بسیاری از شرکت‌های خصوصی نظیر ما تنگ کرده است. البته این‌بار به مرحمت تحریم‌های ترامپ نفس دستگاه‌های بی‌خاصیت حاکمیتی نیز به شماره افتاده و امید است که اربابان رانت و رابطه، که واسطه بین خصوصی‌های بی‌عرضه و حاکمیتی‌های بی‌سوادند حذف شده و بگذارند رقابت در بخش خصوصی سالم و مبتنی بر تخصص و توان‌مندی شکل بگیرد!با شیوع ویروس کرونا، مجموعه ما نیز مثل خیلی از شرکت‌ها دچار چالش‌های جدیدی شد. آن‌چه در فیودو اتفاق افتاد از دست دادن درآمدی چند هزار دلاری بود که حدود ۴۰ درصد کل درآمد ماهانه شرکت را شامل می‌شد. به قول شهید مصطفی چمران شیپور جنگ جدا می‌کند مرد را از نامرد. (نقل به مضمون!) این بحران‌ها در سازمان‌ها دقیقا کار همان شیپور جنگ را می‌کند. شرکت‌های موفق و ناموفق یا نیروهای وفادار و بی‌وفا و همینطور مدیران خردمند و ناتوان مشخص خواهند شد. در چنین شرایطی تصمیمات مدیران مجموعه در کوتاه‌ترین زمان نمود خود را نشان می‌داد و این یعنی هر تصمیم اشتباه، بدون فرصت اصلاح و یا جبران خواهد بود. حالا من به عنوان هم‌بنیان‌گذار و مدیر فنی شرکت به همراه دو شریک دیگر نقشی حساس‌تر از قبل داشتیم.علی‌رغم این‌که در این اوضاع شرکت‌های بزرگ فن‌آوری و استارت‌آپی شروع به تعدیل نیرو کرده بودند، آنچه ما به آن اعتقاد داشتیم حفظ نیروها تا جای ممکن بود، حتی در شرایطی که کار جدی‌ای برای بیشتر پرسنل وجود نداشت. در این بین، بحران اختلافات مدیریتی به تلاطمات ما دامن زد و این اختلاف تا سر حد خروج یکی از سهامداران عمده(شریک سوم)، که عضوی از هیئت مدیره هم بود پیش رفت. این اتفاق باعث شد تا برخی از نیروها اعتراضاتی را بروز دهند. اینکه ریشه این اعتراضات چه بود و اصلا چرا پیش آمد و مسئولیت آن چقدر بر عهده مدیران بود و چقدر بر عهده خود نیروها در مقاله‌ای مجزا مطرح خواهد شد، اما آن‌چه اینجا خواهیم پرداخت نحوه مواجهه با چنین بحرانی‌ است.شیوع کرونا، بحران اقتصادی کشور، از دست رفتن ۴۰ درصد از درآمد شرکت، اختلاف و خروج یکی از شرکا و در نهایت تسری آن به نیروها و هرج و مرج در بین آن‌ها چیزی بود که طی ۲ ماه نخستین سال ۹۹ ما را به شدت تحت فشار گذاشته بود. ایجاد آنتروپی در سازمان و محفل‌هایی خصوصی برای غر زدن و تشدید نارضایتی باعث شد با یک مشکل جدی مدیریت نیروی انسانی مواجه شویم. در چنین شرایطی سه راه اصلی وجود داشت: کوتاه آمدن در مقابل درخواست نیروها، که مهمترین آن افزایش حقوق بیش از کاراییشان بود در حالی که از نظر اقتصادی ممکن نبود و یا تن دادن به حرف‌هایی که از نظر حقوقی یا حرفه‌ای اصلا به صلاح شرکت نبود.تقابل جدی در مقابل نیروها و تاکید بر حفظ نظم سازمان.پیدا کردن راه میانی، یعنی تا حدودی کوتاه آمدن در مقابل خواسته‌ها و همچنین ایستادگی بر برخی مواضع تا افراد ناراضی کمتری خارج شوند.احتمالا بیشتر افراد در این شرایط گزینه سوم که راه میانه است را ترجیح دهند. این مورد در کشور ما خیلی مرسوم است زیرا همیشه درک درستی از منافع سازمانی نداریم. فکر می‌کنیم باید همیشه همه از ما خشنود باشند و ما قهرمان زندگی دیگران باشیم اما فراموش می‌کنیم که یک قهرمان یا مدیر خوب اول در رابطه با خودش و سازمانش باید نقش موثری داشته باشد و بعد محبوب قلب‌ها شود!نظر شخص من گزینه دوم بود، در حداکثری‌ترین حالت! اتفاقا تا توانستم در تنور اختلافات دمیدم و حتی جلسات هفتگی شرکت را تعطیل کردم. جلسات هفتگی شرکت باعث می‌شد مشکلات عنوان شود و خیلی وقت‌ها سوءتفاهمات یا نیازها برطرف می‌شد، اما تعطیلی جلسات باعث شد تا این سازمان منحوس درون سازمانی (آنترودپی منفی) کارش را بیش از پیش جلو ببرد! به نظر من نیرویی که در بحرانی گذرا و ساده این‌طور نظم سازمان را برهم زند و بخواهد از آب گل‌آلود ماهی بگیرد، بهتر است امروز حذف شود تا در آینده و در مقطعی که وابستگی سازمانی بیشتری به او شکل گرفته و جداییش از مجموعه خسارت بیشتری خواهد داشت. نیروهایی که فکر می‌کردند در نقش مهره حیاتی (Linchpin) یا نیرو کلیدی (Key Person) هستند با طرح درخواست استعفا، شرکت را تحت فشار قرار دادند. کوتاه آمدن در این شرایط به معنی ساخت فرهنگی سازمانی برای باج گیری در مواقع بحرانی بود. من و شریکم تصمیم گرفتیم خیلی خون‌سرد استعفاها را بدون هیچ حرف اضافی و با خیالی آسوده قبول کنیم و این برخورد دور از انتظار آن‌ها بود. اتفاقا در این ایام چند پروژه جدید هم پیشنهاد شد، اما ما جوابمان را به تعویق انداختیم تا وضعیت نیروهای قبلی مشخص شود. حالا صدای شیپور جنگ به گوش همه مجموعه رسیده بود و این سیاستی بود که سعی در انجامش داشتیم.در نهایت نیروهایی که وفادار به سیستم نبوده و تحمل تلاطمات شرکت‌شان را نداشتند خود به خود از مجموعه حذف شدند. فضا برای جذب نیروهای جدید و تغییر فرهنگ سازمانی اشتباه (که بخش اعظم آن حاصل رفتارهای نیروهای قدیمی‌تر بود و بخشی هم حاصل اشتباهات مدیریتی ما) محیا شد. همچنین نیروهایی که در این مرزبندی به سازمان وفادار ماندند دو گروه بودند: ۱- آن‌هایی که از روی وفاداری به سازمان ماندند و دغدغه رشد شرکت را داشتند. ۲- آن‌هایی که از روی ناچاری (به دلایل مختلف من‌جمله نبود فرصت شغلی بهتر یا نداشتن مهارت‌های خوب برای جذب شدن در دیگر شرکت‌ها) ماندگار شدند. گروه اول السابقون السابقون هستند و جزو مقربین. بدون درخواستی در ماه بعدی از افزایش حقوق بهره‌مند شدند و نشان دادند سرمایه‌پذیری آموزش‌های جدید و رشد سازمانی را دارا هستند. گروه دوم نیز مشمول شرایط قبل شدند و فرصت برای نشان دادن توانمندی‌هایشان و وفاداریشان در آینده فراهم خواهد شد تا شاید اعتماد سازمان را به خود جلب کنند.اندرو گرو (موسس و مدیرعامل اینتل): موقع ارزیابی به خروجی واحد کاری نگاه کنید نه کارهایی که انجام داده‌اند!مدیریت بحران پیش‌آمده با کمترین خسارت و چابک شدن بیشتر شرکت دست‌آوردی بود که برای ما حاصل شد. حالا با استفاده از تجربه گذشته و درس گرفتن از اشتباهاتی که در نوشته‌های بعدی به آن اشاره خواهم کرد، فرصت جدیدی پیش روی ماست تا نظام سازمانی موثرتری ایجاد کنیم.

ساختن اولین صفحه وب با HTML

علیرضا ریاحی — Wed, 28 Mar 2018 16:15:48 +0430

در این مقاله سعی داریم تا یک آشنایی اولیه با برنامه نویسی صفحات وب، HTML پیدا کنیم و یک صفحه وب ساده بسازیماین مقاله در واقع ادامه مبحث یک وبسایت چگونه کار می‌کند است. قبلا با ساز و کار کلی برنامه‌نویسی وب آشنا شدیم و حالا باید یک نگاه دقیق‌تر به مرحله اول برنامه نویسی وب، یعنی همان HTML داشته باشیم. (توجه داشته باشید هدف این مقاله صرفا یک آشنایی اولیه است نه آموزش کامل HTML)زبان HTML چیست و چگونه باید کار را شروع کرد؟‌‌ زبان HTML یک زبان نشانه گذاری (markup language) است که برای ساختن صفحات وب ایجاد شده است. اساسا زبان‌های نشانه گذاری نازل‌ترین زبان‌های برنامه‌نویسی هستند و بسیار ساده و ابتدایی عمل می‌کنند. برای همین یادگیری آن‌ها عموما نیاز به ۵ دقیقه زمان برای فهم ساختار آن و یک دیکشنری برای ترجمه آن دارد! بگذارید یک مثال از خودم بزنم. من از دوران مدرسه با دروسی مثل تاریخ و جغرافی و اجتماعی و … مشکل داشتم. چون هیچ منطق خاصی نداشت، فقط نیاز به حفظ کردن داشت و من همیشه فکر می‌کردم هر موقع نیاز به این دانش‌ها داشتم فقط کافی بود به مرجع آن مراجعه می‌کردم. اما در عین حال ریاضی و هندسه و … را دوست داشتم چون حس می‌کردم دارم با یک منطق زیبا آشنا می‌شوم با کلی معمای هیجان انگیز که با حل آن‌ها حس پیشرفت داشتم! اگر مثل من فکر می‌کنید کلا این بخش از برنامه‌نویسی برای شما کمی سخت خواهد بود چون در واقع HTML از نظر من همان تاریخ و جغرافی دنیای وب است!خیلی دور شدیم از بحث! گفتیم markup language ها خیلی ساده‌اند! یعنی فقط باید با یک نشانه بگوییم چه چیزی می‌خواهیم بگوییم. مثال زیر را ببینید: !سلام خواننده گرامی سایت! خوش آمدی به سایت من ما یک چیزی را به زبان نشانه‌گذاری نوشتیم! وقتی کلی از این چیز‌ها کنار هم قرار بگیرند می‌شوند یک برنامه به زبان نشانه گذاری. در کد بالا من گفتم یک قسمتی دارم به نام WellCome که محتوایی دارد شامل «سلام خواننده گرامی سایت! خوش‌آمدی به سایت من!». با علامت <> به سیستم می‌فهمانم که این یک تگ است. همچنین همانطور که یک تگ باز می‌شود باید بسته هم بشود. با در مثال فوق تگ آغاز و با این تگ بسته شد. تنها فرق بین باز و بسته شدن تگ صرفا اضافه شدن بک اسلش “/” به ابتدای تگ پایانی است. طبیعتا وقتی می‌خواهیم این نشانه‌گذاری‌ها برای مرورگر‌ها (browser) قابل ترجمه باشند به آن ظاهری که مد نظر ماست، باید از تگ‌های استاندارد و از پیش تعیین شده‌ استفاده کنیم. مثلا در تگ WellCome یک تگ استاندارد نیست و من از خودم خلق کردم.اولین برنامه را بنویس:چند تگ استاندارد را با هم مرور کنیم: وبلاگ تک لاگ

آموزش برنامه نویسی وب

برنامه نویسی وب رو خیلی راحت فرا خواهید گرفت

در ابتدای هر سند HTML یا همان فایل‌هایی با پسوند .html باید از تگ استفاده کنم. در واقع با این تگ من دارم اعلام می‌کنم سند من از آخرین نسخه HTML که همان HTML5 هست استفاده می‌کند. برخی از تگ‌ها نیازی به بسته شدن ندارند. مثل همین تگ که فقط باز شد.بعد از آن تگ را باز کردیم و در انتها بستیم. کل تگ‌های ما باید در بین این تگ قرار بگیرد و به نوعی می‌توان گفت همه تگ‌ها بچه‌ها و نوادگان تگ هستند. تگ به دو قسمت head و body تقسیم می‌شود. پس با تگ های و این دو قسمت را ایجاد می‌کنیم. در تگ عموما تنظیمات سند HTML وارد می‌شود. مانند عنوان صفحه، نوع کاراکتر‌ها، کلمات کلیدی و … اما در تگ تمام آنچه می‌خواهیم در صفحه نمایش داده شود را وارد می‌کنیم. مثلا در اینجا ما در قسمت head گفتم نوع کاراکترها از جنس UTF-8 است. این نوع کاراکتر تمام کاراکترها را شامل می‌شود. چون ما از زبان فارسی استفاده می‌کنیم حتما باید این تنظیم رو انجام دهیم در غیر این صورت در مشاهده خروجی کار به مشکل می‌خوریم. این اتفاق با افزودن تگافتاد. این تگ هم مثل تگ نیازی به بسته شدن ندارد. (پیشنهاد می‌کنم یک‌بار نوع کاراکتر‌ها را تعیین نکنید و خروجی کار را مشاهده کنید.)گفتیم در قسمت body هر آنچه می‌خواهیم نمایش بدهیم را وارد می‌کنیم. من از تگ

برای ایجاد یک تیتر استفاده کردم و داخل آن تیتر دلخواهم را قرار دادم. بعد از آن از تگ
برای ساخت یک پاراگراف استفاده کردم و متن دلخواهم را در آن قرار دادم.خوب حالا می‌خواهیم یک فایل HTML ایجاد کنیم و از آن استفاده کنیم. کافی است یک فایل متنی (فایلی با پسوند .txt) ایجاد و تگ‌ها را داخل آن قرار دهیم.در انتها فرمت فایل که .txt بود را به .html تغییر دهیم. من در اینجا اسم فایل را index.html ثبت کردم.به همین راحتی شما اولین صفحه وب خودتون رو ایجاد کردید!دیدیم که ساخت اولین صفحه وب به آسانی پشت سر گذاشته شد! حالا وقت آن رسیده که محتوایی را که با HTML در صفحه قرار دادیم بوسیله CSS زیباتر به نمایش بگذاریم. در مقاله بعدی قصد داریم در خصوص CSS اطلاعاتی کسب کنیم.

یک وبسایت چگونه کار می‌کند؟

علیرضا ریاحی — Thu, 22 Mar 2018 18:17:50 +0430

در این مقاله قصد دارم به معرفی نحوه عملکرد یک وبسایت بپردازم.همه ما کم و بیش با مفهوم وبسایت یا همان صفحات وب آشنایی داریم، اما شاید ندانیم یک وبسایت دقیقا چگونه کار میکند. در ادامه شما یک دید کلی از قسمت‌های تشکیل دهنده وبسایت‌ها، نحوه عملکرد و تعامل با آن‌ها پیدا خواهید کرد.وبسایت (website) چیست؟یک وبسایت مجموعه‌ای است از داکیومنت‌ها (شما بخوانید اسناد) و فایل‌های خاصی شامل متن‌ها، تصاویر، لینک‌ها (همان پیوند‌ها)، رنگ‌ها و هر‌آنچه شما در یک وبسایت مشاهده می‌کنید، که با کنار هم قرار گرفتنشان یک صفحه وب را تشکیل می‌دهد. دسترسی به وبسایت ها معمولا از طریق یک نام دامنه (domain name) مانند www.teclog.ir که به کامپیوتر شما دستور می‌دهد برای نمایش این وبسایت باید از کجا به فایل‌های مورد نیاز آن دسترسی داشته باشد. نام دامنه در واقع مانند یک آدرس است در دنیای اینترنت.مرورگر (browser) چیست؟وبسایت‌ها توسط مرورگر‌های وب (web browser) قابل دسترسی خواهند بود. مرورگر‌های وب نرم‌افزار‌هایی هستند که توانایی دانلود و نمایش وبسایت ها و اجزای تشکیل دهنده آن‌ها را دارند. به عبارت دیگر برای دسترسی به وبسایت ها و مشاهده عکس‌، متن، ویدیئو و … در آن‌ها باید از مرورگر‌های وب استفاده کرد. شما با وارد کردن نام دامنه‌ای مانند www.teclog.ir در مرورگر‌ها قادر خواهید بود تا به محتوای مربوط به این آدرس درسترسی پیدا کنید. با وارد کردن آدرس www.teclog.ir در مرورگر‌های محبوبی نظیر موزیلا فایرفاکس گوگل کروم و سافاری در واقع به مرورگر دستور می‌دهید تا از این آدرس فایل‌های گوناگون را به نحوی که برای شما قابل مشاهده باشد درآورد و یکجا نمایش بدهد.سند اچ‌تی‌ام‌ال (HTML document) چیست؟صفحات وب همگی با زبان نشانه‌گذاری HTML نوشته می‌شوند و مرورگر‌ها در واقع این داکیومنت‌های (اسناد) HTML را به نحوی که ما بتوانیم مشاهده کنیم و از آن‌ها استفاده کنیم ترجمه می‌کنند. HTML مخفف عبارت Hyper Text Markup Language است که واژه مناسبی برای ترجمه آن به ذهنم نمی‌رسد.متن‌ها، تصاویر، رنگ‌ها و … همه در فایل HTML و با پسوند .html ذخیره می‌شوند. مرورگر‌ها به دنبال فایل‌هایی با پسوند .html هستند تا بتوانند محتوای آن را برای شمل نمایش بدهند. البته در آینده دقیق‌تر بررسی خواهد شد که برخی از محتواهای یک وبسایت ممکن است پسوند‌های دیگری داشته باشند (مانند یک فایل تصویر که ممکن است با پسوند .png ذخیره شده باشد) اما در فایل HTML به آن اشاره شده است و در نهایت این فایل HTML است که توسط مرورگر‌‌ها بررسی و نمایش داده می‌شود.میزبان وب یا همان وب سرور (web server) چیست؟حالا می‌دانیم یک وبسایت در واقع شامل یک سری فایل HTML و دیگر فایل‌های وابسته به آن است. تمام این فایل‌ها روی کامپیوترهایی قرار می‌گیرد که وب سرور (web server) نامیده می‌شوند. هنگامی که شما آدرسی را در مرورگر وارد می‌کنید در واقع مرورگر از وب سرور آن وب سایت درخواست می‌کند که فایل‌های مورد نیاز برای نمایش آن وب سایت را در اختیارش قرار دهد.می‌توان گفت وب سرورها چیزی غیر از همان کامپیوترهای خانگی نیستند و مانند آن‌ها شامل سیستم عامل، تعدادی فایل و فولدر (شما بخوانید پوشه) و … هستند. از ویژگی‌های وب سرور‌ها اتصال به اینترنت پر‌سرعت و حجم بالای فضای ذخیره‌سازی اطلاعات (مانند هارد دیسک ها در کامپیوترهای شخصی) است. اما مهمترین ویژگی وب سرورها این است که قادر اند به درخواست بازدید کنندگان یک وب سایت که از طریق مرورگرها برای آن‌ها ارسال می‌گردد پاسخ دهدند. وب سرور های سایت های پر بازدیدی مانند www.digikala.com روزانه باید به میلیون‌ها درخواست مختلف کاربران از سراسر ایران نظیر توضیحات گوناگون محصولات، تصاویر، سفارش‌های خرید و … پاسخ دهند.زبان‌های سمت سرور (server-side) و زبان‌های سمت کاربر (client-side) چیست؟همانطور که گفته شد HTML زبانی است که توسط مرورگرهای وب برای نمایش وب سایت‌ها استفاده می‌گردد. البته زبان‌ها و تکنولوژی‌های دیگری نیز در این حوزه وجود دارد مانند CSS و JavaScript و … که در آینده راجع به آن‌ها بیشتر خواهیم آموخت. به تمام این زبان‌ها و تکنولوژی‌ها، زبان‌های سمت کاربر (client-side languages) و به برنامه‌نویسی در این حوزه برنامه‌نویسی سمت کاربر (client-side programming) یا برنامه‌نویسی فرانت‌اند (front-end programming) می‌گویند.در حالی که HTML زبانی است که توسط مرورگرهای وب برای نمایش وب سایت ها استفاده می‌شود، سرورهای وب نیز از زبان‌های دیگری برای پردازش درخواست‌ها، مدیریت اطلاعات و فایل‌ها، ذخیره سازی اطلاعات و … استفاده می‌کنند. این زبان‌ها و تکنولوژی‌های مورد استفاده در آن‌ها زبان‌های سمت سرور (server-side languages) و برنامه‌نویسی در این سمت را برنامه‌نویسی سمت سرور (server-side programming) یا برنامه‌نویسی بک‌اند (back-end programming) می‌نامند. زبان هایی نظیر NodeJs و PHP و ASP و …وب سایت‌ها چگونه کار می‌کنند؟هنگاهی که یک آدرس وب سایت را در مرورگر خود وارد می‌کنید، مرورگر شما درخواستی را برای یک وب سرور که در آن فایل‌های مربوط به آن وب سایت قرار دارد، ارسال می کند. مرورگر فایل‌های HTML، تصاویر، فیلم‌ها و … را دانلود می‌کند و به شکلی قابل نمایش در می‌آورد. در فضای توسعه وب (web-development)، تکنولوژی‌های مربوط به پردازش و نمایش اطلاعات در مرورگر را فناوری‌های فرانت‌اند‌ یا سمت کاربر می‌نامند.وقتی به عنوان مثال با استفاده از فرم‌ها در صفحات وب، اطلاعاتی را نظیر اطلاعات کارت اعتباری خود برای یک وب سایت ارسال می‌کنید این اطلاعات توست تکنولوژی‌های مربوط به سرور مدیریت و پردازش می‌گردد، پاسخ آن آماده و برای شما ارسال می‌گردد. این زبان‌ها که وظیفه مهم ارتباط با پایگاه‌های داده (data base) را نیز بر عهده دارند به عنوان فناوری‌های بک‌اند‌ شهرت پیدا کرده‌اند.در ادامه قصد دارم مطالبی را در مورد برنامه نویسی سمت کاربر یا همان فرانت‌اند با شما در میان بگذارم. مقاله بعدی به زبان HTML خواهد پرداخت.