Api و Web service
Api و Webservice مانند پل ارتباط هستند. تفاوت آنها در این است که وب سرویس ارتباط بین دو ماشین ( غالباً سرور و کلاینت ) را تسهیل میکند. اما Api مانند یک اینترفیس بین دو اپلیکیشن ( بک و فرانت ) عمل میکند. Api یک روش است تا third-party ها بتوانند به آن متصل و از خدمات ما بهره مند شوند. یک وبسرویس طراحی میشود تا یک اینترفیس داشته باشد، این اینترفیس عموما با یک زبان قابل فهم برای ماشین شرح داده میشود ( WSDL ).
HTTP پرکاربرد ترین پروتکل برای ارتباطات است. وب سرویسها از SOAP, REST, XML-RPG استفاده میکنند.
َبه متدهای یک نرم افزار برای ارتباط با نرم افزارهای دیگر Api میگویند. وقتی که این عمل در بستر وب اتفاق می افتد؛ وب سرویس ها به میدان می آیند.
Api عموماً شامل صداکردن توابع درون نرم افزار میشود.
خلاصه :
همه وب سرویس ها api هستند اما همه apiها وب سرویس نیستند
وب سرویس همه اعمالی که api قادر به انجام آن هست را انجام نمیدهد
وب سرویس فقط در سه بستر قابل اجراست . SOAP, REST, XML-RPG
وب سرویس برای اجرا شدن همواره به شبکه نیاز دارد اما api خیر
مقدمه
در این پست بحث میکنیم که دیتابیس های NoSql چه فرقی با دیتابیس‌های سنتی رابطه‌ای و Schema Base دارند.
همچنین چند راهکار برای مدل کردن دیتابیس نوسکوئل ارائه میشود؛ دیتابیس های داکیومنت بیس بعضاً Schema Less نامیده میشوند که این عبارت نادرست میباشد. این گونه دیتابیس‌ها به ساختار‌های از پیش تعریف شده همانند آنچه در دیتابیس‌های رابطه‌ای داریم نیازی ندارند اما شما باید تعریف کنید که چگونه میخواهید دیتای خود را سازماندهی کنید.
معمولا در NoSql شما قصد دارید تا دیتای خود را به صورت تجمیع شده در اختیار داشته باشید، بنابراین میتوانید دیتای خود را به سرعت و بدون استفاده از Joinها بازیابی کنید. یک دیزاین مناسب از دیتابیس میتواند در نحوه عملکرد برنامه شما تغییرات بسیار زیادی ایجاد کند.
یک حکایت وجود دارد که اگر یک راه حل برای یک مشتری کار میکند با یک ساعت گفتگو 1000 برابر سریع تر کار خواهد کرد!
ادامه مطلب
یک نگاه کلی به زبان های برنامه نویسی
قبل از آنکه به مقایسه زبان های برنامه نویسی بپردازیم اجازه دهید تا کمی با آنها آشنا شویم.
زبان های پویا
یاد گرفتن زبان های دینامیک و پویا معمولاً برای مبتدیها آسان تر است چون آنها انعطاف پذیر و جالب هستند. به سادگی با کمترین کد و در عرض مدت کوتاهی میتوانید با scratch یک اپلیکیشن بسازید. در این زبان ها اینکه به برنامه بگویید تا کار مورد نظر شما را انجام دهد اصلاً کار سختی نیست ! زبان های دینامیک معمولاً بسیار سطح بالا هستند و شما زمان کمی صرف درست کردن جزئیات میکنید، در عوض زمان زیادی برای یادگرفتن مفاهیم برنامه نویسی خواهید داشت. به همین دلیل است که زبان های پویا بین مبتدیها بسیار محبوب هستند؛ چراکه برنامه نویسها میتوانند چیزی بسازند و فوراً نتیجه آنرا ببینند.
به ادامه مطلب مراجعه کنید .
ادامه مطلب
میخواهم درباره یک مهاجرت بزرگ صحبت کنم. وقتی که با م کارفرمای یکی از پروژه ها تصمیم به بازسازی سرویس گرفتیم.
سرویس مورد نظر یک سرویس ختم گروهی قرآن بود که بیش از 2000 ختم در آن انجام شده بود یعنی چیزی حدود 3 میلیون رکورد ثبت شده برای هر صفحه.
سرویس ابتدا با pure php و بدون فریمورک نوشته شده بود. یک api که با app ارتباط برقرار میکرد و یک ربات تلگرام که مستقیا به دیتابیس وصل میشد!
فاجعه!
قطعاً نمیتوانید همچین چیزی بزنید جز آنکه یک بی تجربه به تمام معنا باشید.
دیتابیس پروژه mysql بود و کاملاً غیراصولی نوشت شده بود.
یک سری از استانداردهای طراحی پایگاه داده کلا رعایت نشده بود و همیشه مجبور به repair کردن جداول بودیم.
حتی از بی تجربگیم میتونم بگم که یک کران جاب طراحی کرده بودم تا هر دو روز یکبار، یکبار همه جداول رو repair کنه
اما به اینجا ختم نمیشد
هیچکدوم از کلاینت های دیتابیس بسته نمیشدند و عملا به حال خودشون رها شده بودند در نتیجه توی رم سرور با فاجعه رو به رو بودید.
وقتی که رممون رو از 512 به 1 و بعد از 1 به 2 ارتقا دادیم و همچنان بیش از 90 درصد رم مشغول بود ( البته که تعداد کاربرها و سرویس ها هم در حال افزایش بود )
توی پیک شلوغی مخصوصا ماه های رمضون اوضاع کاملا به هم میریخت. عنان کار از دت میرفت . گهگاه موقع سحر با کابوس یا اس ام اس کارفرمام از خواب بیدار میشدم تا مشکل رو حل کنم.
یک بخشی از ربات بود که به کاربرایی که علاقه داشتن یک تایم از روز یک صفحه از قرآن میفرستاد مثل یکجور آلارم.
دم اذان صبح و ساعت 12 شب بیشتر از هزار پیام باید فرستاده میشد. یعنی ما در طول روز به طور معمول دو الی سه ختمهر ختم 604 صفحه ) اشتیم و تو این دو تا زمان به اندازه ترافیکی که تو کل روز پخش میشد ترافیک وجود داشت.
این رو بذارید کنار اون محدودیتی که تلگرام برا ربات ها گذاشته!
هر ثانیه فقط 30 کاربر پیامتو میگیرن !!
و یک مشکل بزرگتر! هیچوقت براش یک پنل طراحی نکرده بودیم. تا حداقل مشکلات ساده تر از طریق پنل حل بشه .
مشکل بعدی این بود که به دلیل های متعدد ارتباط با کاربر ها عملا ممکن نبود و نمیتونستیم یک پیام به همه بفرستیم .
اینطور شد که تصمیم گرفتیم مهاجرت کنیم و قصه این مهاجرت رو براتون تعریف میکنم .
امروز میخوام یکی از عادات عجیب خودم رو براتون بگم، شاید رسالت این بلاگ نوشتن عادات عجیب غریب من نباشه و امیدوارم مورد جاج قرار نگیرم؛ اما یکی از عادات عجیب من در مواقعی که روی پروژه های شخصی خودم کار میکنم استفاده از شخصیت های فانتزیه! شخصیت های فانتزی مورد علاقه‌م رو در پروژه دخیل میکنم.
یکی از سایت هام که البته خیلی وقته نابودشده اسمش تلگرال بود، توی اون سایت کاربرا ادرس کانال های تلگرامشونو وارد میکردن و به نوعی دایرکتوری کانالهای تلگرام بود. البته که اون سایت پیشرفت خوبی داشت و به جز چند مشکل سئو میتونست آینده درخشانی داشته باشه اما نکته بحثم جای دیگه‌س.
اون موقع تازه سریال بریکینگ بد رو تموم کرده بودم و محو شخصیت درجه سوم چهار ویکتور بودم. همه لاگهای سایت از جمله عضویت کاربرا، ثبت کانال جدید و . توی یک کانال شخصی برای خودم فوروارد میشد؛ اما اسم کامال رو "لاگهای سایت تلگرال" یا "telegral logs" نذاشتم! به طرز خنده داری اسم اون کانال شد Victor! برام اینطور بود که ویکتور بیست و چهار ساعته سایت رو میپاد و همه گزارش ها رو برام میفرسته.
قضیه به اینجا ختم نشد بعدا یک ربات جذب ممبر زدم و ser barristan» از سریال گیم آف ترونز وظیفه گزارش جذب و دفع ممبرها رو داشت :))
بعد هم یک ربات ساختم که توی انتخاب واحد کمک حال دانشجوها بود؛ اینجا john luck» از سریال دوست داشتنی لاست وظیفه گزارش ها رو داشت. اون بهم میگفت دانشجوها از چه درسهایی بیشتر خوششون میاد یا به چه درسایی کمتر علاقه دارن یا حتی برای این ترم میخوان کدوم درس ها رو بردارن:))
خلاصه اینکار به من کمک میکرد تا هم لاگهای مناسبی داشته باشم از سیستمم هم این لاگها توسط یک شخصیت فانتزی مورد علاقه‌م به من برسه. نمیدونم شاید اینجوری اون لاگ ها رو مهمتر میدیدم. حالا اگه با من کاری ندارید برم تا یکی دیگه از لاگرهام رو به یک شخصیت فانتزی بدل کنم ؛)
در روز اول وظایفی که به من محول شد به شرح زیر میباشد .
1- آشنایی با ساختار و معماری اسکریپت
2- بالا آوردن اسکریپت اپ استور
3- مرمت دیتابیس ( ورژن دیتابیس قدیمی بود ولی اسکریپت جدید بود)
4- اصلاح فرانت چند صفحه
5- ایجاد جدوالی که در اسکریپت لحاظ شده اند اما در دیتابیس وجود نداشتند.
تمامی موارد با موفقیت انجام شد.
فهرست تسک های مربوط به روز پنجم:
اصلاح نوع نمایش اسکرین شاتهای اپ
افزودن گزینه نوع اصلاح در انتشار اولین اپلیکیشن
تغییر تاریخ به صورت human readble
افزودن هدر به همه خروجی jsonها
اصلاح appspecial ها و تعیین جایگاه اپلیکیشن
اصلاح قسمت اپلود و ساین
تغییر توابع اتصال به دیتابیس به صورت bindParam و بهینه
اپلود سایت به روی هاست
شرح وظایف روز سوم عبارت بود از :
ایجاد گزینه حذف برای لیست اپلیکیشن ها
کامل کردن پنل ادمین جهت ثبت اپلیکیشن
افزودن قابلیت به روز رسانیاپلیکیشن برای ادمین
تغییر وضعیت های اپلیکیشن ها
افزودن تاریخچه نسخه ها در صفحه هر اپلیکیشن
اضافه نمودن فیلد حریم شخصی و سایت به پنل دولوپر
تغییر نام پنل
ارشیو لیست نسخه های تستی
وظایف روز دوم عبارت بود از :
برطرف کردن برخی از مشکلات دیزاین در پنل
ایجاد برخی از دیتابیس های از دست رفته
راه انداختن ftp و تعمیر اپلود فایل ها
راه انداختن api و چک کردن application ها
ویرایش تاریخ ها و تبدیل انها به شمسی
تصحیح اپلود عکسها در اخبار و دسته بندی
ساخته شدن دیتابیس اپلیکیشن های ذخیره شده
سولید شامل 5 نکته برای طراحی و برنامه نویسی OOP ئه. اگر این نکات ساده رو رعایت کنیم توسعه و نگهداری برای دولوپر بسیار راحت میشه. همچنین سولید باعث میشه تا برنامه نویس ها مرتکب - code smell - نشن ، کد ها رو خیلی سریع ری فاکتور کنن و همچنین بخشی از agile و متد توسعه نرم افزاره.
S.O.L.I.D بر پایه موارد زیره
بیاید بررسی کنیم ببینیم هر کدوم از این نکات به طور فردی چه کاری انجام میده تا در نهایت بفهمیم سولید چجوری ما رو تبدیل به برنامه نویسای بهتری میکنه
ادامه مطلب
درباره این سایت