معرفی زبان برنامه‌نویسی Haskell

برای یک مسابقه برنامه‌نویسی یک سوال ساده طرح کردم که به راحتی قابل حل باشه ولی یک شرط مهم برا حل گذاشتم، برای حل تنها مجاز به استفاده از زبان Haskell هستید. اما چرا هسکل مهمه و چرا همچین تصمیمی گرفتم؟ در ادامه متوجه می‌شوید.

این روزها هرکس بخواهد برنامه‌نویسی را شروع کند، بین زبان‌های پایتون و سی و یا جاوا‌اسکریپت یا نهایتا جاوا و سی‌پلاس‌پلاس انتخاب می‌کند و برنامه‌نویسی رویه‌ای (procedural) و در ادامه شی‌گرا (Object Oriented) را یاد می‌گیرد و احتمالا در ادامه هم در همین بخش ادامه می‌دهد و فریم‌ورک‌های جدید و …

اما برنامه‌نویسی فانکشنال (functional programming یا FP) مورد غفلت واقع شده اما برنامه‌نویسی فانکشنال چی هست؟ به طور خلاصه یک پارادایم برنامه‌نویسی در مقابل برنامه‌نویسی رویه‌ای و شی‌گراست.

با توجه به قدمت برنامه‌نویسی رویه‌ای‌، زبان‌های‌ برنامه‌نویسی رویه‌ای زبان‌های پرقدمتی مثل FORTRAN و BASIC و C و COBOL هستند. این دسته از زبان‌ها متکی به صدا زدن procedure (روتین یا فانشکن) هستند که هر روتین مجموعه‌ای از دستورات است. در واقع کدها در قالب routine ها نوشته می‌شوند.

از بزرگان برنامه‌نویسی شی‌گرا می‌شود به جاوا و سی‌پلاس‌پلاس، سی‌شارپ و جاوا‌اسکریپت و .. اشاره کرد که مفاهیم برنامه‌نویسی شی‌گرا مثل ابجکت‌، کلاس‌، پنهان‌سازی(encapsulation)، وراثت(inheritance) و چندریختی(polymorphism) را پشتیبانی می‌کنند. در این پارادایم، کدها در غالب متد‌هایی برای اشیا نوشته می‌شوند و قابل فراخوانی روی هر شی (یا در مواردی روی کلاس) هستند.

اما زبان‌های فانکنشال مثل Haskell و #F و Erlang و elixir و Clojure روش فکری متفاوتی دارند! در این زبان‌ها کد‌ها در قالب فانکشن‌ها نوشته می‌شوند (مثل برنامه‌نویسی رویه‌ای؟) اما فانکشن‌ها شهروندان درجه‌اول در زبان هستند یعنی کار کردن با آن‌ها به راحتی کار کردن با متغیرهاست و امکان pass شدن و ترکیب شدن و .. را دارند.

توجه: مثال‌هایی که زده شد دقیق نیستند چون اکثر زبان‌ها چند پارادایمی هستند و نمی‌توان گفت سی فقط رویه‌ای است چون با پوینتر به فانکشن قابلیت‌های فانکشنال را هم تا حدی میسر کرده است و یا مثلا جاوا در نسخه 8 امکانات برنامه‌نویسی فانکشنال را تا حدی میسر کرده است.

ریشه و پایه‌ی زبان‌های فانکشنال، ‌lambda calculus است که ایده‌ی نوشتن function و حل مساله به روش بازگشتی را پایه گذاشت.

اما مفاهیمی که در زبان‌های فانکشنال با آن‌ها سرو کار داریم چه چیز‌هایی هستند؟

۱- فانکشن‌های مرتبه بالا‌(higher order function)‌ فانکشنی که یک یا چند فانکنش به عنوان ورودی بگیرد و فانکشن به عنوان خروجی بدهد، مثل انتگرال!

۲- فانکشن‌های خالص(pure function): تابع pure تابعیست که خروجی‌اش دقیقا از روی ورودی‌هایش ساخته می‌شود (مثل همه‌ی توابع ریاضی)، یعنی این تابع با بیرون از تابع و بقیه‌ی دنیا (به جز از طریق ورودی‌ها) هیچ ارتباطی ندارد و هیچ اثری هم روی بیرون از تابع (بقیه دنیا) نمی‌گذارد به جز محاسبه‌ی خروجی! به طور عملی‌تر هیچ متفیر گلوبالی وجود ندارد، کار با IO و تعامل با کاربر و هرگونه side-effectی وجود ندارد.

۳- توابع بازگشتی (recursive functions): توابعی که برای حل یک مساله، از حل زیر مساله‌هایی با ابعاد کوچک‌تر کمک می‌گیرند (مشابه استدلال استقرایی که f(n) را فرض می‌کنیم و برای f(n+1) اثبات می‌کنیم) برای حل مساله با اندازه k از همان تابع برای ورودی با اندازه k-1 (یا به هر صورتی کوچک‌‌تر از k) کمک می‌گیرند و با استفاده از آن، مساله را برای ورودی با اندازه k حل می‌کنند. البته یک شرط پایه (مثل پایه استقرا) نیز وجود دارد که برای اندازه k=1 است که جواب بدیهی دارد.

کمی بیشتر در مورد برنامه‌نویسی شی‌گرا می‌توانید اینجا بخوانید.

اما برگردیم به هسکل:

هسکل یک زبان فانکشنال است (جزو مطرح‌ترین زبان‌های فانکشنال است) ولی نه یک زبان فانکشنال معمولی، یک زبان purely functional است.

هسکل statically typed است یعنی تایپ ها باید در زمان کامپایل معلوم باشند، این کار برای به حداقل رساندن خطا و اشتباه برنامه‌نویس است.

هسکل یک زبان تنبل (lazy) است. pure function ها به زبان امکان تنبلی (laziness) رو می‌دهند، تنبلی یعنی اینکه تا زمانی که واقعا به چیزی نیاز نداریم، برایش زمان و انرژی نگذاریم!

توی زبان برنامه‌نویسی به این معنیست که تا زمانی که به یک داده واقعا نیاز نیست، محاسبه نشود، این امر چطوری امکان‌پذیره؟ مقدار ها از توابع ساخته می‌شوند و توابع زبان هم همگی pure هستند پس تفاوتی ندارد که همان موقع که فراخوانی می‌شوند اجرا شوند و خروجی را آماده کنند یا هرموقع به خروجی‌شان واقعا نیاز بود!

این laziness امکانات عجیبی رو برای زبان (و بیش‌تر از زبان، برای برنامه‌نویس) فراهم می‌کند مثلا می‌توانیم یک لیست شامل همه‌ی اعداد طبیعی داشته باشیم. دقیقا مشخص است که این لیست شامل چه عددهاییست ولی مقدار تک تک‌شون دقیقا محاسبه نشده و هربار به هر مقداری نیاز داشته باشیم محاسبه می‌شود!

اما همه‌ی این تفاوت‌ها و تغییر در پارادایم به چه علتی؟

در زبان‌های فانشکنال به جای how to do به what to do پرداخته می‌شود یعنی برنامه‌ای که نوشته‌ می‌شود به جزییات اتفاقات سطح پایین کاری ندارد و صرفا تصریح می‌کند از برنامه چه انتظاری داریم! فرض کنید یک لیست از اعداد زوج می‌خواهیم، در زبان‌های رویه‌ای باید یک حلقه بزنیم و دقیقا بدانیم تا کجا به اعداد زوج احتیاج داریم و برای هر عدد،‌ در صورتی که زوج بود باید به آرایه یا list اضافه‌اش می‌کردیم اما در زبان فانکشنال کافیست بگوییم یک لیست اعداد طبیعی رو فیلتر کن، چه فیلتری؟ فیلتری که زوج‌ها رو برگرداند.

یا فرض کنید میخواهیم بررسی کنیم که یک عدد، اول هست یا نه، کافیه یه لیست از اعداد ۲ تا n-1 بسازیم و به هسکل بگوییم که بر هیچ کدام بخش‌پذیر نباشد، با یک خط کد امکان پذیر است!

این تفاوت‌ها (و احتمالا یه سری تفاوت که من اینجا نیاوردم و خودم بلد نبودم) برنامه‌‌های فانکشنال را گویا‌تر می‌کند، تغییر در کد را راحت‌تر امکان‌پذیر می‌سازد و کدها را کوتاه تر می‌کند.

یک خصوصیت خوب دیگر این زبان‌ها قدرتشان در همزمانی (concurrency) است که به خاطر ذات immutable بودن داده‌ها و مستقل بودن هر تابع از دیگر قسمت‌های برنامه میسر شده است.

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

برای شروع به کار با زبان هسکل ، می توانید از repl آنلاین آن در سایت رسمی خود هسکل استفاده کنید، البته کامپایلرهای انلاین هم در دسترس هستند.

کامپایلر خوب و شناخته‌شده‌ی هسکل، ghc است که در اکثر سیستم‌عامل ها قابل نصب و استفاده است.

همچنین در این لینک می‌توانید توضیحات دیگری را بخوانید.

آموزش‌های شروع به کار خوب هسکل هم موارد زیر است:

https://learnxinyminutes.com/docs/haskell/

https://jeoygin.gitbooks.io/learn-y-in-x-minutes/content/haskell.html

https://wiki.haskell.org/Learn_Haskell_in_10_minutes
https://www.tutorialspoint.com/haskell/index.htm

دو کتاب بسیار خوب هم پیدا کردم، یکی به زبان انگلیسی و قابلیت خواندن آنلاین و یکی به زبان فارسی (و البته گران قیمت!) که می‌توانید فصل‌های اولش را در این لینک بخوانید. (بسیار توصیه می‌شود)

نوشته معرفی زبان برنامه‌نویسی Haskell اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

نکات مهم برای تبدیل شدن به برنامه نویس اندروید

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

نکات مهم برای تبدیل شدن به برنامه نویس اندروید

۱.بروی IDE ها کار کنید

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

۲.کد نویسی تمیز را تمرین کنید

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

۳.بروی پروژه های Open-source مشارکت کنید

در نظر بگیرید پروژه باگ دار شخصی را از github گرفته و بروی آن کار کرده و خطا های آن را حل کنید یا پروژه های خود را که Bug دارند در Github قرار داده و به دیگران بگویید با شما مشارکت کنند تا بتوانید آن مشکل ها را حل کنید.

۴.الگوهای طراحی (Design Patterns) جاوا را یاد گیرید

Design Patterns یکسری الگوی خاص طراحی هستند که در زمان کار با پروژه و آپدیت پروژه فعلی مورد استفاده قرار می گیرند مثلا زمانی که ۳ نوع Design Patterns مثل Factory , Decorator و Facade را شنیدید بدونید درباره چی در حال بحث هستید.(دوره آموزش جامع برنامه نویسی جاوا).

۵.کد نویسی تمیز را تمرین کنید

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

۶.یاد بگیرید چه گونه از کاتلین استفاده کنید

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

۷.کدهای دیگران را بخوانید

اغلب برنامه نویسان حوصله خواندن کدهای دیگران را ندارند و سعی می کنند همان چیز را با استفاده از دانش خود پیاده سازی کنند ولی این کار خیلی بیهوده است ولی با این کار شما توسعه دهنده نمی شود توسعه دهنده باید حوصله تمام نشدنی ای داشته باشد. شاید بپرسید چه کدهایی را مطالعه کنیم از کتاب خانه یا پروژه های Open Source شروع کنید روزی حداقل ۳۰ دقیقه کدهای دیگران را خوانده و آنها را تجزیه و تحلیل کنید.

۸.بهترین سیستم را تهیه کنید

تا حد امکان همیشه بهترین سیستم را برای برنامه نویسی اندروید انتخاب کنید اگر دقت کرده باشید اندروید استودیو نیازمند memory فوق العاده بالایی است و تعداد process های آن در ثانیه بسیار زیاد است بهترین سیستم برای برنامه نویسی اندروید را انتخاب کنید تا به راحتی بتوانید برنامه های خود را بدون هیچگونه وقفه ای پیاده سازی کنید.

https://codefriend.ir/2019/12/13/نکات-مهم-برای-تبدیل-شدن-به-برنامه-نویس-ا/

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

گردآوری توسط ایده طلایی

اصول برنامه نویسی خوب – !KISS – اصل سادگی

Keep it simple, stupid

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

اصل KISS توصیفی است که کد را ساده و واضح نگه می دارد و درک آن را آسان می کند.بعلاوه باید توجه کنید زبانهای برنامه نویسی برای درک انسانهاست . کامپیوترها فقط 0 و 1 را می توانند بفهمند، بنابراین کدنویسی را ساده و آسان انجام دهید. متد ها و فانکشنهای خود را کوچک نگه دارید. هر متد یا فانکشن هرگز نباید بیش از 40-50 خط باشد.

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

دو متد زیر را با هم مقایسه کنید، کدام ساده تر است؟

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

نوشته اصول برنامه نویسی خوب – !KISS – اصل سادگی اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

وردپرس خوب بد زشت

چیزی که باعث نگارش این مطلب شد اینه که تعداد مشتری های وردپرس ما در سال از ۳ تا ۴ تا به هفته ای ۳ تا ۴ تا رسیده در حالی که ما در اصل جوملا کار هستیم و جذابیت طراحی های ما برای وردپرس در فروشگاه قالب های جوملا dimatemplate.ir را میتوان در چند چیز دید. این مطلب جنبه تبلیغاتی نداره فقط قصد دارم به عنوان یک جوملا کار که قالب وردپرس زده و به تازگی هم برای وردپرس پلاگین نوشته مطلبی رو بنویسم که دوستان دیگر هم بدونن بد نیست شاید مفید شایده شد.

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

خب ایراد کار کجاست؟

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

خب کجا مشکل ایجاد می کنه؟

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

چطوری پیدا می کنند؟

توی وردپرس یک امکان هست که با زدن هر پست در سایت یک کد برای یه سری سایت خارجی pin ارسال میشه که این سایت بروز شد. این امکان خیلی خوبی هست هم برای سئو هم برای معرفی سایت هم برای ترافیک سایت اما کجا بد میشه بد اونجایی میشه که هکر ها هم خبر میشن یه سایت وردپرسی تازه کار اومده بالا ٬ پس زحمت می کشن و اولین مورد قالب شما رو چک می کنند ٬‌شما هم تازه کار برای امنیت کاری نکردید یا مثل قالب از افزونه های نال استفاده کردید یعنی در خونه دزدی رو با قفل دزدی که کلیدش دست هر کسی هست قفل کردید. من چیزی نمی گم شما هم بروی خودتون نیارید که بعدش قراره چه اتفاقی بیفته.

قراره چه اتفاقی بیافته؟

خب نشد که نگم ٬‌متاسفانه بعد از اینکه سایت شما رو پیدا می کنند اون رو هک می کنند اما دیفیس نمی کنند که شما متوجه بشید. یعنی شما رو آلوده ویروس یا ورم یا هر چیزی دیگه ای می کنند تا براشون نقش ناقل یا نقش ابزار رو ایفا کنید. از شما برای هک ٬‌دزدی و اتک زدن به بانک های خارجی استفاده می کنند که روشی مرسوم در DDoS هست. فقط یه مورد رو بگم اگر روزی هوس سفر خارجی یا اقامت کردید بدونید اگر شما سایتی داشته باشید که اسپم فرستاده و در کشوری باشید که قانون ارسال اسپم جرم باشه شما ناخواسته مرتکب جرمی شدید که یه نمونه اش ۱۲ سال زندان در اکثر کشور های اروپایی داره.

خب از بحث خیلی دور نشیم بر می گردیم سر اصل داستان خودمون

چرا ما وردپرس کار شدیم؟

اول براتون بگم که جوملا ساختاری مهندسی و برپایه MVC داره ٬ که شامل سه بخش در طراحی نرم افزار میشه یعنی module view control ٬‌خب این به چه معناست؟ یعنی در نرم افزارهایی که برای جوملا نوشته میشه کد طراحی با کد برنامه نویسی با هم یه جا نیستند و جدا هستند و یک کنترلر مسئول کنترل و اجرای این ۲ تا هست. این سبک برنامه نویسی خیلی زیبا و خیلی منظم و مرتب هست ٬‌اما وردپرس چی؟ وای نگو از وردرپرس. حالم بد شد یه لحظه ٬ اصل هیچ قانونی وجود نداره خدا به دادمون برسه . شما یه پلاگین رو باز کن سورسش رو نگاه کن شبیه کیف آقای ووپیه! خدایا کمک این یعنی چی ؟ میرم سراغ معروف ترین نرم افزار بروی ورد پرس یعنی ووکامرس! ظاهری زیبا اما پشت صحنه ای اسفناک! چرا اسفناک ؟ چون طراحاش معلوم یه چیز دم دستی میخواستن بنویسن بعد استقبال شده و اومدن توسعه اش دادن اما سورس رو اصلاح نکردن. به خودشون گفتن کی میفهمه؟‌کی حوصله داره سورس رو نگاه کنه. بله این طراحان تنبل حتی حاظر نشدن برای برنامه خودشون تیبل تو دیتابیس ایجاد کنند تا برسه به این که از تکنولوژی بخوان استفاده کنند. الان یه سوال پیش اومد٬ خب اگر دیتابیس ندارن پس دیتای ما کجا میره که میان نشون هم میدن؟ بله سوال خوبیه ٬‌این برنامه خیلی راحت میاد دیتای فروشگاه رو میریزه توی تبل های پست وردپرس فقط نوعش رو برای خودش زحمت میکشه محصول میزار٬‌خب سوال بعدی مشتری خرید میکنه فاکتورش چیه ؟ خب خرید های مشتری میشه کامنت یه پست :)) این میشه که من از گشادی برنامه نویس های وردپرس خوشم اومد و اولین پلاگین خودم رو نوشتم؟

چرا برای وردپرس این همه پلاگین طراحی هست شما باز یکی نوشتید؟

جواب سوال ساده است من دیدم بری طراحی یه قالب خبری یا قالب شرکتی باید ۳۰ تا ۴۰ افزونه نصب کنم یا به زبان ساده تر برای هر حالت نمایشی یه پلاگین نصب کنم که این یعنی سایت سنگین یعنی لود بالا یعنی سورس مسخره یعنی کد های اضافه یعنی … دیوانه شدم و گفتم ببینم اصول طراحی پلاگین توی وردپرس چیه؟

چطوری برای وردپرس پلاگین ایجاد کنیم؟

من نمی خوام آموزش بدم اما شما هم بدونید بد نیست کافیه تو پوشه پلاگین وردپرس یه پوشه درست کنید اسم پلاگین رو بزارید روش بعد توش یه فایل php کپی کنید و توش ۴ خط کدتون رو بنویسد. من هم خندیدم هم خوشحال شدم ٬ چون برای جوملا مجبور بودم ۳۲ تا فایل رو ایجاد کنم تا فقط کامپوننت من نصب بشه همین٬ اما توی وردپرس نه این یه مزیت برای ادم تنبلی مثل من بود ( به شما پیشنهاد می کنم که شما هم یه چند تا پلاگین برای وردپرس درست کنید بخنیدید) بله پلاگین متولد شد هی من سوال برام پیش اومد هی سرچ کردم اما الان یه مشکل تازه دارم من روی جوملا کارهام توی چند تا فایل بود راحت مدیریت می کردم اما توی وردپرس یه فایل دارم که وقتی بازش می کنم خودم میترسم ٬ دقیقا کیف آقای ووپی هر روز هم برای امکاناتی که بهتش دارم اضافه می کنم به این فایل ۳۰۰ خط اضافه میشه خدا به دادم برسه. یه سری روش ها هم هست که شما میتونید استفاده کنید که بد نیست مثل یه سایت پیدا کردم انلاین پلاگین وردپرس تولید میکنه٬ نسبت به کدی که خودمون می نویسیم هم کد نویسی بهتر و منظم تری داره شما میتونید سرچ کنید چون این پست تبلیغی نیست اسمش رو نمی یارم.

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

وردپرس تعریفش جالبه :‌نرم افزاری برای راه اندازی وبلاگ یا وب سایت.

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

وردپرس چون میخواسته کار ساده بشه ٬‌سورس ساده نوشته اما وقتی استقبال شده ٬‌اتفاق بد هم افتاده نیازها بیشتر شده و سورس حجیم شده. بد نیست بدونید جوملا تو هر نسخه که بالا میره هر چند وقت یک بار سورس رو از اول باز نویسی می کنند.

از کجا بفهمین ساختار یه نرم افزار چند بار باز نویسی شده؟

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

مثلا یک نرم افزار ورژنش میخوره ۳.۹.۱۳ یعنی چی؟

یک یعنی ساختار این برنامه ۳ بار باز نگری یا بازنویسی شده

دو ۹ بار اصول برنامه نویسی یا ساختاری توی نسخه ۳ بازنگری یا بازنویسی شده

سه ۱۳ بار براش پچ امنیتی یا نرم افزاری زدن

حالا فهمیدید داستان ورژن ها چیه؟

پس الان وردپرس نسخه ۳.۵.۳ هست باید ۳ بار باز نویسی شده باشه؟ نمی دونم اما فکر می کنم خودشون از کدی که نوشتن این برداشت رو داشتن ٬ من که سورس رو دیدم همون سورس ده سال پیش هست فقط یه کم چون زیاد هک می شدن سوراخ های این آبکش رو بستن اما آبکشه دیگه خیلی سوراخ داره شما هم چسبی چیزی دم دستتون بود ببندید خیلی خطرناکه ٬‌بد بختی مثل جوملا ادمین مستقل نیست و شما نمی تونید روی ادمین پسورد بزاری یا محدودش کنی ٬‌هی باید بعد از هر بروز رسانی یا افزونه نصب کنی برای حل مشکل امنیتی تغییر مسیر ادمین یا باید یه فکری براش بکنید.

این هم قسمت بد وردپرس ٬ حالا قسمت زشتش کجاست؟

قسمت زشت وردپرس برای ما ایرانی هاست؟ ما ایرانی ها اولا دنبال این هستیم که کمتر هزینه کنیم حتی اگر جنس بد گیرمون بیاد ٬‌دوم فکر می کنیم بقیه خ….ر نمی فهمن ما چی کار کردیم.

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

روش اول برای تست قالب وردپرس:

توی فایل wp-config.php وردپرس مقدار WP_DEBUG رو روی true بزارید و صفحات سایت و ادمین خودتون رو چک کنید (البته اگر شانس بیارید و طراح شما وجدان کاری داشته باشه و سورس خوبی نوشته باشه و سایتتون سفید یا پر خطا نشه )

روش دوم برای تست قالب وردپرس:

فایل هایی که توی قالب هست رو مستقیم صدا بزنید:

مثلا فایل اصلی قالب index.php هست شما به این صورت صدا بزنید:

http://yoursite.com/wp-content/themes/yourtheme/index.php

وقتی این ادرس رو بزنید باید بهتون خطای دسترسی بده فقط مقادیر رو درست پر کنید که ادرس درست رو پیدا کنه

اگر خطای دسترسی به شما نداد و صفحه سفید اومد معلومه که برنامه نویس شما یا برای خطا کد نزده که اما سورس رو بسته که ایرادی نداره یا حالت بد اصلا صدا زدن مستقیم رو کنترل نکرده و هکر خیلی راحت میتونه با پاس دادن ۴ تا کد ساده سایت شما رو زیر رو کنه

خب راه حل مشکل در صورت اتفاق دوم چیه ؟ اگر برنامه نویسی بلد باشید باید ببنیدینش اگر هم بلد نیستید باید قید قالب رو بزنید یا به طراحش بگید مشکل رو حل کنه

من خودم همیشه توی جوملا و وردپرس میام می بندم اینطوری:

if ( ! defined( ‘ABSPATH’ ) ) exit;

?>

اه چقدر ساده بود ٬‌بله معما چون حل گشت اسان می شود ٬‌این خط ساده در بالا همه فایل های php در وردپرس الزامی هست تا هکر ها نتونن شیطنت کنند اما متاسفانه بخش اعظمی از طراحان وردپرس واقعا همین رو نمی دونن ٬ اما شما الان جز اون دسته شدید که میدونن.

من قرار نیست امن کردن وردپرس رو اموزش بدم من جوملا کاریم که وردپرس کارهای ایرانی قالب هاشو دوست دارن پس برای وردپرس قالب اصولی با روش جوملا میزنم شاید که رستگار شوید!

خوشحال میشم اگر چیزی برای تکمیل موضوع به ذهنتون رسید کامنت کنید.

اینجا زن و بچه نشسته لطفا هر چیزی رو ننویسید٬‌ممنون :دی

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

گردآوری توسط ایده طلایی

آشنایی با Clean Architecture : پیاده سازی بر اساس UseCase ها (قسمت ششم)

قسمت اول : مقدمات
قسمت دوم : مبانی معماری
قسمت سوم : نگاهی به معماری سنتی سه لایه
قسمت چهارم : اجزای Clean Architecture
قسمت پنجم : پیاده سازی بر اساس سرویس ها
قسمت ششم : پیاده سازی بر اساس UseCase ها (شما در حال خواندن این مقاله هستید)
قسمت هفتم : آشنایی با CQRS


پیاده سازی معماری Cleanرا به کمک سرویس ها دیدیم. تصویر معروف این معماری را به خاطر بیاورید.

پیام اصلی این معماری این است :

لایه های درونی هیچ اطلاعی از لایه های بیرونی ندارند و این ویژگی را به کمک Dependency Injection به راحتی میتوان پیاده کرد.

در بخش قبل دیدم که لایه مرکزی یعنی Core که حاوی Doman (یا همان Entity ها) بود هیچ اطلاعی از اینکه چطور دارد استفاده میشود نداشت. سرویس های موجود در این لایه فقط ارائه دهنده خدماتی بودند که ورود و خروجشان را نمی‌دانستند.

آنچه Uncle Bob’s به عنوان Clean Architecture در لایه Core معرفی کرده شامل UseCase ها و Entityهاست(که ما به Domain میشناسیم؛ به شکل قراردادی مدل های دیتابیسی را Entity می‌گوییم).
اول ببینیم سرویس‌ها معمولا در ساختاری که در مقاله قبل تعریف شد به مرور بزرگ و بزرگ تر می‌شوند. اینجکشن های درون یک سرویس زیاد شده و گاهی مدیریت آنها سخت میشود.

یوزکیس(UseCase) یا Interactor یک جایگزین برای سرویس نیست بلکه مرکز اصلی پیاده سازی لاجیک محسوب می‌شود. ما یک پروژه را برای یک هدف دنبال میکنیم و قرار است نرم افزار ما مسائل دنیای واقعی را در راستای این هدف حل کند. هر مسئله را میتوان یک UseCase دانست با ورودی مشخص و خروجی قابل محاسبه. با این دیدگاه یک سرویس که حاوی متدهای مختلف برای برآورده کردن نیازهاست به چندین کلاس UseCase شکسته میشود.

مثلا یک UseCase وظیفه دارد آبجکت Post را به جدول Post اضافه کند. در این مسیر باید ابتدا بسنجد که آیا این آبجکت از قبل وجود داشته یا نه اگر وجود داشت اکسپشن مناسب تولید کند و اگر نداشت ایجادش کند.

ما قبلا همین منطق را مثلا در متدی به نام Add در سرویس PostService ایجاد میکردیم ولی در روش فعلی باید یک UseCase برای اینکار ایجاد کنیم که کاملا ایزوله باشد. حتا ترجیح این است که هندل کننده ی این روال هیچ نوع ریترنی نداشته باشد و از ورودی، ظرفی را دریافت کند و آن ظرف را پُر کند.

میخواهیم api برای add کردن یک Post ایجاد کنیم. اینبار از روش UseCaseی جلو میرویم.

اما چطور UseCase بنویسیم؟

باید یک سری محدودیت ها و قواعدی برای نوشتن UseCase طراحی کنیم که برنامه نویس ملزم به رعایت آن باشد. مثلا اینکه ورودی چگونه باشد و خروجی به چه شکل تولید شود.

اینترفیس زیر را ایجاد میکنیم.

https://gist.github.com/mortezadalil/7dba95524b9ccf92ba2d42a306bab00e

این اینترفیس جنریک است و دو تایپ به عنوان TUseCaseRequest و TUseCaseResponse در آن استفاده میشود که ارتباط بین این دو تایپ نیز توسط IUseCaseRequest تعریف شده است.

https://gist.github.com/93b823efaabfb81949b92b794ecb788f

این اینترفیس هم جنریک است و تایپ جنریکی که با آن کار میکند به شکل out معرفی شده است. Out حالتی است که پارامتر حتما باید توسط متد تغییر کند. این یعنی چه؟

همانطور که متدهای موجود در سرویس‌ها ورودی و خروجی دارند، این موضوع برای UseCase هم صادق است. هر UseCase را میتوان معادل یک متد در سرویس دانست. اگر ورودی UseCase را به عنوان Request و خروجی آن را Response در نظر بگیریم این جریان دیتایی را میتوان یک نوع ارتباط مسیجی تعریف کرد.

میخواهیم یک api برای Add کردن یک Post بنویسیم. این Api یک UseCase به نام AddPostUseCase را صدا میزند. ورودی این UseCase مدلی به نام AddPostRequest است که مشخصات زیر را دارد:

https://gist.github.com/954baba5fafe83d902545769036c1720

همانطور که میبینیم از IUseCaseRequest ارث بری کرده و به دلیل خاصیت این اینترفیس مجبور است یک مدل به عنوان Response نیز تعریف کنیم. فرض کنید AddPostResponse مدل زیر است.

https://gist.github.com/5038acd341a7844faa23b19a36eba82c

تا اینجای کار روند ورودی و خروجی دیتا را تعریف کردیم.

برای نوشتن متد UseCas کلاسی به نام AddPostUseCase تعریف میکنیم که باید IAddPostUseCase را پیاده سازی کند. این اینترفیس را به شکل زیر تعریف میکنیم

https://gist.github.com/cd2f96077edf2b110fa1dc022971af09

این اینترفیس از IUseCaseRequestHandler ارث بری میکند و مشخص است که به جای in و out چه مدل هایی باید قرار گیرد. کلاس پیاده سازی این اینترفیس با مدل ورودی و خروجی که پیش از این تعریف کردیم کار میکند پس به شکل فوق تعریف شده است.

بر اساس آنچه در IUseCaseRequestHandler تعریف شده کلاس هایی که هر اینترفیس ارث بری شده از این اینترفیس را پیاده کنند مجبورند متد HandleAsync را داشته باشند که مدلی به نام message را از نوع Request تحویل گرفته و چیزی از تایپ IOutputPort را که جنریکی از تایپ Response است میسازند!

از عبارت میسازند به جای تحویل میدهد استفاده کردم چون UseCase ها مثل Service ها ریترن به درد بخور ندارند؛ یعنی نتیجه مجموعه لاجیکی که روی مقادیر ورودی اعمال میشود در ظرفی به نام outputPort ریخته میشود.

https://gist.github.com/ca82e3440372a8e31c97eb62d2041d3d

این ظرف از کجا می آید؟ کدام متد از کدام کلاس قرار است IOutputPort را پیاده کند که ما Handle آن را صدا بزنیم؟

اینجاست که Presenter وارد عمل میشود. برخلاف حالت سرویسی که در مقاله قبل توضیح دادیم، ظهور Presenter در روش فعلی بسیار واضح و موثر است. ما میتوانیم یک کلاس پرزنتر به نام PostApiPresenter تعریف کنیم که جنریک باشد و آبجکت خروجیِ یوزکیس را بگیرد و هر بلایی خواست سرآن بیاورد تا برای نمایش آماده شود. این کلاس وظیفه ساختار دهی به خروجی را نیز دارد و میتوانیم همانکاری را که قبلا در BaseController انجام دادیم در اینجا انجام دهیم.

این کلاس به شکل زیر است:

https://gist.github.com/92c7d33259e7cea4d5127386e0ef4fa4

پرزنتر ما در اینجا وظیفه جیسون کردن خروجی را بر عهده دارد و از IOutputPort باید ارث بری کند، چون آبجکتی از پرزنتر به عنوان پارامتر دوم هر UseCase به آن ارسال میشود تا response را بگیرد. به پارامتر ورودی دوم در UseCase دقت کنید.

کد زیر یک UseCase برای add کردن یک post جدید را نشان میدهد. آرگومان دوم چیزی از جنس IOutputPort است. ظرفی که قرار است توسط این UseCase با خروجی مناسب پر شود. پرزنتر همین ظرف است.

https://gist.github.com/027bf465af1cb4f8b98c8d9bd205cd11

می‌توان پرزنتر را به شکل عمومی تر نیز تعریف کرد. پرزنتری که ما ساختیم با توجه به نام آن، در سطح یک کنترلر قابل استفاده است. مثلا برای کنترلر Post بر اساس خروجیهای مختلفی که در اکشن هایش داریم، این پرزنتر میتواند استفاده شود، چون جنریک است.
مثلا اگر متد HTTPPOST مینویسیم و خروجی ما قرار است از جنس AddPostResponse باشد کافیست که PostApiPresenter را به کنترلر اینجکت و از آن به شکل زیر استفاده کنیم.

https://gist.github.com/06952f6d265e020103a2a3b5398e47b0

دو پراپرتی addPostUseCase_ و addApiPresenter_ مقادیر اینجکت شده در کنترلر هستند که در این اکشن استفاده شده اند.

چند نکته :

  • در این مقاله برای سادگی ولیدیشن ورودی را لحاظ نکردیم، می‌توانید برای آن راهکاری از طریق BaseController یا Presenter و یا یک middleware جنرال بیاندیشید.
  • همه اکشن های ما همین دو بخش را خواهند داشت:
    – صدا زدن هندلر مرتبط.
    – ارسال پاسخ از طریق return
  • پرزنتر ما به ساده ترین شکل ممکن تعریف شده است. برای اینکه بتوانید خروجیهای یکسان با قابلیت نمایش خطا و پیام داشته باشید (مانند آنچه در بخش قبل در BaseController ساختیم) باید پرزنتر خود را مجهز به امکانات بیشتری کنید. مثلا از یک کلاس جنرال ارث بری کند که بتواند پراپرتی های بیشتری در اختیار UseCase قرار دهد تا به شکل مناسب تری پر شود. در ادامه این موضوع را خواهیم دید.
  • آنچه در کانستراکتور کنترلر اینجکت شده حتما باید در startup تعریف و رجیستر شود.
  • الزامی به ایجاد ویومدل برای هر ریکوئست نیست. مثلا برای متد HttpDelete ورودی یک شناسه است و ویومدلی وجود ندارد.

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

https://gist.github.com/76adcabb991ce5da4d712152c4a74fa3

این مدل حاوی data و خطا نیست. یعنی خروجی یک api اگر حاوی خطا یا دیتا باشد این مدل به تنهایی کافی نیست. باید یک کلاس جدید از این مدل ارث بری کنیم که جنریک باشد و دیتای خروجی یا خطا را نیز شامل شود. این کلاس و کلاس Error ی که در آن استفاده شده را نیز در لایه Core ایجاد میکنیم.

https://gist.github.com/0e90d71ba66559d58dbeda7c1b30d687
https://gist.github.com/3251b24bd37f4d59e826c7bb2b272d23

سه نوع پیاده سازی کانستراکتور تعریف کرده ایم:

  • برای زمانی که لیستی از خطاها وجود دارد. طبیعتا success برابر با false است و مسیج دیفالت هم نداریم مگر اینکه در هندلر مسیج تعریف کنیم.
  • برای زمانی که دیتای خروجی داریم و success را برابر با true در نظر میگیریم و مسیج دیفالت هم نداریم مگر اینکه در هندلر مسیج تعریف کنیم.
  • برای حالتی که دیتا و خطا نداریم و خروجی فقط میتواند یک پیام به همراه مقدار success باشد.

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

https://gist.github.com/37c63ee964451ddf4d81b23f1b50d157

با این تغییر اکشن ما به شکل زیر دچار خطا میشود

علت خطا تفاوت جنس پرزنتر و آرگومان دوم UseCase است.
پرزنتر از جنس IOutputPort> است. پس مجبوریم اینترفیس یوزکیس را اصلاح کنیم و تایپ خروجی GenericResponse را اضافه کنیم.

خطای دیگری در اولین تایپ میبینیم. AddPostRequest هم به شکل زیر باید اصلاح شود.

مشکل HandleAsync در کنترلر برطرف میشود.

حالا به پیاده سازی بیزنس در UseCase میپردازیم.

https://gist.github.com/9701c9022dda01ed6ec44ed3d0567665

کافیست متد Add را در ریپازیتوری درست کنیم. این متد ورودی از نوع دامین میگیرد و خروجی آن آبجکت کاملی از نوع دامین است. (که id آن پس از اضافه شدن به دیتابیس مشخص شده)

حالا addedItem برای یوزکیس یک آبجکت دامینی حساب میشود و باید آن را به خروجی مورد نظرش map کند. اینکار را به شکل دستی در مثال فوق انجام دادیم تا outputObject را بسازیم.

در مرحله آخر ouputObject را به handle میدهیم که به اصطلاح “ظرف پرزنتر را پر کند” و در سمت اکشن ContentResult داشته باشیم.

چند نکته :

  • پارامتر ورودی message در usecase از جنس AddPostRequest است و منطق ما در یوزکیس ما را مجبور کرد که از دو پراپرتی آن استفاده نکنیم. یعنی تاریخ ها در خود بیزنس مشخص شده اند و نه ورودی. پس مدل AddPostRequest را به شکل زیر اصلاح میکنیم.

https://gist.github.com/e19efc4a8b49091951d087f630254909

  • ما عملیات saveChange را به خود ریپازیتوری محول کردیم که منطقا این کار باید در یوزکیس انجام شود و نباید در ریپازیتوری صورت گیرد (مراجعه کنید به تعریف ریپازیتوری) ولی معمولا در ریپازیتوری انجام میشود!
  • برای راحتی، ایرادی ندارد که خروجی متد Add در ریپازیتوری از نوع AddPostResponse می‌بود تا عملیات مپِ اضافه در یوزکیس انجام نمیشد؛ اما در این مثال یک متد Add نسبتا روتین نوشته ایم. منطقی این بود که متد Add در ریپازیتوری فقط Id را برمیگرداند. شاید خیلی منطقی تر این بود که ما در یک ریپازیتوری جنرال و جنریک متد Add را برای همه entity ها به شکل جنریک پیاده سازی می‌کردیم. فراموش نکنید این مقاله و این پروژه جنبه آموزشی دارد.
https://gist.github.com/b430ace6a33044542e6b978e175547f5
  • برای مپ کردن بهتر است از automapper استفاده کنید که تعداد خطوط کدهای شما کمتر شود و توسعه و عیب یابی راحت تری داشته باشید.
  • دقت کنید متدهای ریپازیتوری مدل های دامین را به عنوان ورودی میگیرد و مدل های دامین (یا در مواقعی Dto) را به عنوان خروجی برمیگرداند. یعنی ریپازیتوری باید محافظی برای انتیتی های دیتابیسی باشد و عملیات ساده مثل اضافه کردن، حذف کردن، ویرایش کردن، جوین زدن و ایجاد دامین جدید و … را انجام دهد و حاوی بیزنس های محاسباتی و پیچیده نباشد.

خب ؛ حالا که ساختار مشخص شد برای نوشتن یوزکیس جدید Delete به شکل زیر عمل میکنیم.

https://gist.github.com/b797b97a75cbc2724be864395a3ca78f

تفاوت این یوزکیس با یوزکیس قبل فقط در هندل کردن خطاهاست.

چند نکته در مورد روند کار DeleteUseCase

  • اینکه ابتدا چک کردیم که آیا شناسه وجود دارد میتوانست به شکل دیگری باشد و وجود آبجکت را چک کنیم و پس از اینکه آبجکت پیدا شد با متد Remove مربوط به EntityFramework آنرا پاک می‌کردیم. در اینجا با هدف آموزشی، یک متد برای بررسی وجود آیتم در دیتابیس نوشته شده و در صورت عدم وجود، یک اکسپشن تولید شد. در صورتی که وجود داشته باشد آن را به کمک متد دیگری در ریپازیتوری پاک می‌کنیم.
  • خروجی این متد یک بولین است. مسیج خروجی هم خالی است.
  • در catch ، دو حالت در نظر گرفتیم. خطاهای هندل نشده به شکل “خطا در دریافت اطلاعات” نمایش داده میشود و خطاهای هندل شده مسیج کاستوم خود را به پرزنتر می‌دهند.

در این مقاله ساختار یک پروژه بر اساس Clean Architecture معرفی شد. این پروژه را میتوانید در اینجا ببینید.
الان نوبت شماست که توانایی های خودتون رو نشون بدید. اکستنشن متد بنویسید، میدل ویرهای مختلف تعریف کنید. کاری کنید که با کمترین زحمت بیشترین نتیجه را بگیرید. چه کارهایی بلدید؟

  • برای لاگ های خود ساختار تعریف کنید و در پرزنتر جنرال آنرا جاسازی کنید. از Nlog استفاده کنید. Elastic را به آن متصل کنید و از کوچکترین خطا صرف نظر نکنید. Elmah هم گزینه خوبی برای لاگ کردن خطاهاست.
  • اکسپشن ها را به کمک یک middleware هندل کنید تا از تکرار try/catch ها رها شوید. البته خیلیها دوست دارند خطاهای هر useCase را در همان UseCase ببینند و هندل کنند. شاید تست و عیب یابی طولانی مدت در این حالت ساده تر باشد.
  • تعریف سرویس های اینجکت شده خود را در startup سامان دهید. آیا میتوانید کاری کنید هر کلاسی با عبارت Presenter تمام میشد بصورت خودکار رجیستر شود؟ برای UseCase ها هم میتوانید؟
  • برای token و claim ساختار یکپارچه تعریف کنید و بطور کلی تشخیص هویت را سازماندهی کنید.
  • اکشن فیلترها را فراموش نکنید میتوانید مدلهای ورودی خود را به جای middlaware با اکشن فیلتر کنترل کنید. اما آیا جایی به درد می خورد؟
  • از swagger استفاده کنید.
  • از Automapper بهره بگیرید.

فرصت بررسی همه موارد فوق نیست و امیدوارم در آینده ای نزدیک به شکل ویدیویی موارد فوق را با هم پیاده سازی کنیم. اما فعلا منتظر مقاله بعدی باشید که با کتابخانه ای آشنا خواهیم شد که استفاده از UseCase را ساده تر می‌کند.

نوشته آشنایی با Clean Architecture : پیاده سازی بر اساس UseCase ها (قسمت ششم) اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

سرگذشت آقای جاوااسکریپت!

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

همونطور که میدونیم، زبان نشانه گذاری HTML اسکلت بندی و ساختار یه صفحه وب رو شکل میده و CSS هم وظیفه خوشگل کردن این صفحه رو به عهده داره. اما این قضیه واقعا کافی نیست و ما احتیاج داریم که وقتی کاربر به سایت ما میاد، باهاش تعامل داشته باشه و مثل یه صفحه که یه سری اطلاعات توش هست، باهاش رفتار نکنه. و اینجاست که جاوااسکریپت وارد میشود.

با استفاده از این زبون برنامه نویسی، میشه حرکت، انیمیشن، تعامل و پاسخگویی به کاربر رو به سایت اضافه کرد. (البته حرکت و انیمیشن توی CSS 3 هم وجود داره)

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

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

(یاد یکی از سایت های دولتی افتادم که وقتی میخواستم توش ثبت نام کنم، باید یه فرم خیلی گنده رو پر میکردم و وقتی کلید تایید رو زدم، ارور داد که: اطلاعات وارد شده نادرست است! حالا من باید از اول چک میکردم که کجا رو اشتباه کردم، در حالیکه به راحتی میشد با استفاده از جاوااسکریپت، خطاها رو دقیق مشخص کرد و راه رفعشون رو به کاربر نشون داد)

علاوه بر این، با استفاده از این زبان، میشه رابط کاربری (UI) یه سایت رو خیلی هیجان انگیزتر کرد. برای مثال، میشه به جای استفاده از چندتا عکس ثابت کنار هم توی سایت، یه اسلایدر متحرک قشنگ ساخت.
یا مثلا میشه یه صفحه یه صفحه پر از اطلاعات رو از شلوغ پلوغی نجات داد. به این صورت که اطلاعات رو به بخش های مختلفی تقسیم میکنیم و کاربر فقط وقتی میتونه اون اطلاعات رو ببینه که روی اسم بخش کلیک کنه.
و حتی میتونیم با باز شدن یه بخش، به بخش های دیگه دستور بدیم که بسته بشن تا نظم و ترتیب صفحه حفظ بشه. المان هایی مثل پاپ آپ هم با استفاده از جاوااسکریپت ساخته میشن (ولی شما سعی کنید استفاده نکنید، پاپ آپ ها خیلی آزاردهنده ان، حداقل برای من!)

یکی از مزیت هایی که جاوااسکریپت برای صفحه وب میاره، آنی بودن واکنش هاست و به صفحات اجازه میده که بلافاصله به فعالیت های کاربر مثل کلیک کردن روی یه لینک یا دکمه، واکنش نشون بدن.

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

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

نقشه های آنلاین دیگه ای هم قبل از گوگل مپ فعال بودن اما اونا برای پردازش درخواست کاربر، نیاز داشتن که درخواست رو به سرور ارسال کنن و این درخواست باید دوباره به مرورگر کاربر فرستاده میشد و صفحه دوباره لود میشد، تا شما بتونید چیزی که میخواین رو ببینید: یه فرایند بسیار کند و زمان بر!

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

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

اگه دوست داشتید، ادامه این مطلب رو میتونید توی سایت من بخونید:

https://octascript.com/javascript-and-a-brief-history/

نوشته سرگذشت آقای جاوااسکریپت! اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

خلاصه مختصر مفید GoLang (پارت اول)

اگه پارت اول رو قبلاً مطالعه کردین میتونین پارت دوم رو اینجا مطالعه کنین


اگه بخوایم خلاصه ببینیم زبان برنامه نویسی Go چیه به آدرس ویکیپدیای فارسی این صفحه استناد میکنیم:

این زبان در نوامبر ۲۰۰۹ معرفی شد و در حال حاضر در چند سامانهٔ اجرایی گوگل استفاده می‌شود. مترجم گو از لینوکس، مک او اس، ویندوز و انواع سیستم‌های عامل بی‌اس‌دی مانند FreeBSD پشتیبانی می‌کند. از لحاظ معماری پردازنده نیز، معماری ایکس۸۶، معماری ایکس۶۴، معماری آرم و معماری POWER که مخصوص به شرکت آی‌بی‌ام است، توسط مترجم گو پشتیبانی می‌شوند

به زبون خودمونی، گو رو بر و بچه های گوگل توسعه دادن، روی اکثر سیستم عاملای مرسوم قابل اجراس و زبون سطح بالاییه. شرکتایی مثل Google و Uber و Netflix و eBay و Apple و SoundCloud و Twitter و … از این زبون استفاده کردن. فکر میکنم اسم این شرکتا واسه نشون دادن قدرت این زبون کافیه ولی واسه اطمینان بیشتر میشه به این پروژه ها هم اشاره کرد که جفتشون از گو استفاده کردن و هردو متن باز هم هستن: Docker ، kubernetes

خب خیلی سریع بریم سراغ این که ببینیم زبون گو چه شکلیه (البته قبلش اشاره کنم که توی این آموزش خیلی سریع و خلاصه فقط میخوایم سینتکس و قابلیتای این زبون رو بررسی کنیم)

تعریف متغیر

var card string = "Hello world"

برای تعریف میگم یه var یا همون variable داریم به اسم card که از نوع string هست و مقراشم برابر Hello world گذاشتیم. زبون go این اجازرو میده که همین خط رو بتونیم به شکل زیر و خلاصه تر بنویسیم:

card := "Hello world"

این ساختار دقیقاً شبیه حالت قبلی عمل میکنه. زبون go از این variable ها پشتیبانی میکنه.

نمایش پیغام

این زبون بصورت پیشفرض از پکیج هایی استفاده میکنه (که شدیداً توصی میکنم سر صبری نگاهی بهشون بندازین) و fmt یکی از اونهاست. ساده ترین حالت نمایش پیغام هم بصورت زیر:

fmt.Println(“a message”)

تعریف type

تقریبا همچی توی زبون go یه type هست و ما میتونیم تایپ های خودمون رو هم ایجاد کنیم. مثلا وقتی بنویسیم

type arrayType []string

یعنی هر جایی که بنویسیم arrayType منظورمون []string هست

آرایه

حالا این []string چی هست؟ میخوایم یه مجموعه داشته باشیم.

var a [2]string

یعنی یه آرایه دارم که دو تا عضو داره و اسمشم a هست. آرایه توی زبون go تعداد عناصر ثابتی داره و محدودم هست. یه ساختار دیگه ای داره به اسم slice که شبیه همون آرایه تعریف میشه با کمی تغییر

s := []int{2, 3, 5, 7, 11, 13}

و خودش یسری امکانات دیگه هم میده بهمون مثل اینکه بتونیم یه قسمتی از یه آرایه رو با ایندکس هاش جدا کنیم:

s = s[2:4]

یعنی از دومی تا چهارمی (شامل دومی ولی تا قبل از چهارمی)

s = s[:n]

یعنی از اول تا قبل از عنصر n

s = s[4:]

یعنی از عنصر چهارم (شامل خود چهارمی) تا آخر لیست

ساختار map

اگه بخوایم ساختار key value داشته باشیم میتونیم از map استفاده کنیم:

colors := map[string]string{
		"red":   "#ff0000",
		"blue":  "#0000ff",
		"green": "#00ff00",
	}

یا بصورت زیر تعریف کنیم:

var colors map[string]string
colors := make(map[string]string)

این make چیز باحالیه، هرچیزی بخواین تعریف کنین (یا بهتره بگیم اکثر چیزارو) میتونین با این ساختار توی زبون برنامه نویسی گو تعریف کنین.

به این شکل هم میتونیم عنصری رو فراخونی یا حذفش کنیم:

colors[10] = "#ffffff"
delete(colors, 10)

بد نیس نگاهی هم به این عکس بندازیم:

Maps VS Struct in GoLang

ساختار یا Struct

زبون برنامه نویسی Go چیزی به اسم کلاس نداره. میشه توش Struct بصورت زیر تعریف کرد:

type person struct {
    name string
    age  int
}

یچیزیه شبیه کلاس توی زبونای برنامه نویسی شی گرا. به این صورت

p := person{"Bob", 20}

یا به این صورت

p := person{name: "Alice", age: 30}

هم میشه یه person جدید تعریف کرد.

تابع

شبیه خیلی از زبونای برنامه نویسی توابع بصورت زیر (و با کلمه کلیدی func) تعریف میشن

func funName(inputs) output{
 	...
 }

میتونه ورودی خروجی داشته باشه یا نداشته باشه یا چندتا داشته باشه:

func funName(inputs) outputKind{
        ...
 	return ...
 }

 func funName() outputKind{
        ...
 	return ...
 }

همونطور که گفتیم میتونه چندتا خروجی هم داشته باشی که به این صورت استفاده میشه:

func funName(arg int) (int, string){  	
        return arg ,"test"  
}    

a,t := funName(10)

اگه یجایی _ بذاریم یعنی اون متغیر رو نیاز نداریم که ازش استفاده کنیم و اسمی براش در نظر نمیگیریم:

_ , t := funName(10)

اینترفیس

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

type bot interface {
	getGreeting() string
}

اما موقع استفاده ازش اینجوری نیست که توی هر structی که تعریف کردیم بگیم باید ازن اینترفیس رو پیاده سازی بکنه. بلکه بصورت زیر عمل میکنیم:

type englishBot struct{}
type spanishBot struct{}

func (englishBot) getGreeting() string {
	return "Hello"
}

func (spanishBot) getGreeting() string {
	return "hola"
}

و وقتی یه تابع تو مایه های زیر داشته باشیم:

func printGreeting(b bot) {
	fmt.Println(b.getGreeting())
}

موقعی که داریم صدا میزنیمش چک میکنه ببینه که اون اینترفیس bot که توی ورودی تابع میخواد بگیره رو، چیزی که به عنوان ورودی بهش دادیم پیاده سازیش کرده یا نه.

تابع مختص یه نوع (reciever)

یکی دیگه از ویژگی های زبون go اینه که میتونیم برای یسری نوع (type)های خاص تابعی بنویسیم که فقط برای خودش باشه (شبیه موقعی که داریم توی یه زبون شی گرا داخل کلاسش تابع پیاده سازی میکنیم). به شکل زیر عمل میکنیم:

func (d tType) toString() string{
...
}

یعنی هر نوعی که tType باشه میتونه بصورت

tType.toString()

این تابع رو صدا بزنه.

خطاها

این زبون چیزی به اسم exception handling به اون شکلی که توی زبونایی مثه جاوا شاید دیده باشین نداره. بجاش هر تابعی که بخواد خطایی داشته باشه یه نوع error برمیگردونه. اگر هم بخوایم خودمون میتونیم error های خودمون رو تعریف کنیم و توی توابعمون اونها رو استفاده کنیم.
برای مثال به این شکل میتونیم یه ساختار ارور جدید تعریف کنیم:
type argError struct {
    arg  int
    prob string
}

به این صورت هم میتونیم تابعی تعریف کنیم که در صورت نیاز خطایی برگردونه:

func f2(arg int) (int, error) {
    if arg == 29 {
        // In this case we use `&argError` syntax to build
        // a new struct, supplying values for the two
        // fields `arg` and `prob`.
        return -1, &argError{arg, "can't work with it"}
    }
    return arg + 3, nil
}

و به این شکل هم میتونیم ازشون استفاده کنیم:

_ , e := f2(42)
if ae, ok := e.(*argError); ok {
    fmt.Println(ae.arg)
    fmt.Println(ae.prob)
}

اوه چرا یهو انقد عجیب قریب شد، مگه نه؟ بذارین ببنیم ساختارش چه شکلیه

کلمه ی if اول و ok آخر خط دوم رو نگاه کنین، بین اونا اومدن این رو گذاشتیم:

ae, ok := e.(*argError);

مفهومشم اینه که ae و ok خروجی هامونن (که اینجا ae همون arg و ok همون prob داخل ساختار argError هستن. e هم که خودش argError هست دیگه)

حالا اون شرط یعنی اگه نوشته ای داخل ok بود مفهومش اینه که خطایی اتفاق افتاده و بریم واسه نشون دادن پیغام، در غیر این صورت (nil بودن ok) مفهومش اینه که خطایی نداشتیم و وارد حلقه نمیشیم.

شروط

یه مدل شرط رو توی مثال قبل دیدیم، اما بصورت کلی شروط به این صورت قابل پیاده سازین:

   a = false
   b = true
   if ( a && b ) {
      fmt.Printf("Line 1 - Condition is truen" )
   } else {
      fmt.Printf("Line 1 - Condition is not truen" )
   }
   if ( !(a && b) ) {
      fmt.Printf("Line 2 - Condition is truen" )
   }

حلقه

ساده ترین مدل به این شکله:

for true  {
    fmt.Printf("This loop will run forever.n")
}
و میتونیم بجای true یه متغیر تعریف کنیم که دونه دونه کم بشه تا صفر:
i:=10
for i>0  {
     fmt.Printf(i);
     i = i-1
}

یا اینکه به صورت مرسوم توی بقیه زبونا به این شکل تعریف بشه:

for i := 0; i < 3; i++ {
    fmt.Println(from, &quot:&quot, i)
}


پارت دوم رو میتونید اینجا مطالعه کنین


منتشر شده در ویرگول توسط محمد قدسیان https://virgool.io/@mohammad.ghodsian

https://virgool.io/@mohammad.ghodsian/%D8%AE%D9%84%D8%A7%D8%B5%D9%87-%D9%85%D8%AE%D8%AA%D8%B5%D8%B1-%D9%85%D9%81%DB%8C%D8%AF-golang-%D9%BE%D8%A7%D8%B1%D8%AA-%D8%A7%D9%88%D9%84-lvge8wj8n4xd

نوشته خلاصه مختصر مفید GoLang (پارت اول) اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

آموزش فلاتر ( Flutter ) – ارتباط با سرور Dio

https://files.virgool.io/upload/users/35634/posts/oljoppi6tbvw/zwpemtw9rrtj.png

چند وقتی میشه با فلاتر آشنا شدم. نسبت به تجربه‌ای که تو اندروید داشتم طراحی UI تو فلاتر خیلی آسون‌تره واسه همین تصمیم گرفتم یه پروژه با فلاتر درست کنم و تصمیم دارم پروژمو این جا با شما به اشتراک بزارم. تو این مجموعه از پست‌ها چند تا از مهم‌ترین موضوعات فلاتر رو باهم بررسی می‌کنیم و در نهایت یک پروژه کامل رو به پایان می‌رسونیم. این پست چهارمین پست از این سری هستش و در اون به ارتباط با سرور با استفاده کتابخونه Dio می‌پردازیم. برای دیدن قسمت قبل می‌تونید به این لینک مراجعه کنید.

مطالبی که تو این مجموعه یاد می‌گیریم به چند قسمت تقسیم میشن:


ساخت سرور فیک

خوب قبل از این که یه راست بریم سراغ کتابخونه Dio باید یه سرور داشته باشیم که بتونیم داده‌هارو از روی اون بخونیم. تو این اپ ما از سرور فیک JSONPlaceholder استفاده کردیم. این سایت به ما این امکان رو میده که از API ها از پیش آماده شدش استفاده کنیم، علاوه بر اون با استفاده از یک فایل Json این امکان رو به ما میده که سرور API فیک خودمون رو هم بسازیم. از طریق این لینک می‌تونید به قسمتی برید که آموزش میده سرور فیک خودتون رو بسازید. در این پروژه هم از این فایل json به عنوان منبع سرور فیک استفاده شده. بیشتر از این توضیحی نمیدیم و میریم سر اصل مطلب. اگر خواستید می‌تونید دایکیومنت‌های سایت رو بررسی کنید و سرورفیک خودتون رو بسازید.


کتابخانه Dio

کتابخانه Dio قابلیت‌های زیادی از جمله پشتیبانی از Interceptor ها، تنظیمات(پیکربندی) سراسری، کنسل کردن درخواست‌ها، دانلود فایل‌ها و … داره. توضیحات خود کتابخونه Dio:

A powerful Http client for Dart, which supports Interceptors, Global configuration, FormData, Request Cancellation, File downloading, Timeout etc.

واسه استفاده از این کتابخونه اول باید اون رو به پروژه اضافه کنید. پس کد زیر رو به فایل pubspec.yaml اضافه کنید.

dependencies:
        dio: 3.x.x  #latest version

دستور flutter pub get رو اجرا کنید و دیگه همه چیز آمادس.

متدهای GET , POST , PUT , DELETE

متد GET

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

import 'package:dio/dio.dart';
void getHttp() async {
  try {
      Dio dio= Dio();
      Response response = await dio.get("http://www.google.com");
      print(response);
  } catch (e) {
      print(e)
  }
}

در کد بالا یه در خواست با متد GET ارسال شده که نمونه Dio درخواست رو ارسال میکنه و منتظر میمونه تا جوابو دریافت کنه و بعد جواب رو تو کنسول چاپ میکنه. و همچنین سایت google در اولین پارمتر به عنوان url برای متد فرستاده میشه.

متد POST

از متد POST زمانی استفاده می‌کنیم که به عنوان مثال بخوایم چیزی رو برای سرور ارسال کنیم.

import 'package:dio/dio.dart';
void postHttp() async {
  try {
      Dio dio= Dio();
      Response response = dio.post("url.com", data: {"id": 12, "name": "wendu"});
      print(response);
  } catch (e) {
      print(e)
  }
}

تو این متد از روش پست استفاده کردیم و علاوه بر آدرس پارامتر data رو هم برای Dio ارسال کردیم. این پارامتر همون داده‌هایی هست که تو متدها POST و PUT برای API خودمون ارسال می‌کنیم. اگه از نرم‌افزار postman برای تست استفاده کرده باشین میتونین این پارامتر‌هارو تو تب body اضافه کنید.

متد PUT

متد PUT معمولا زمانی استفاده میشه که می‌خواید مقادیری رو اپدیت کنید.

import 'package:dio/dio.dart';
void putHttp() async {
  try {
      Dio dio= Dio();
      Response response = dio.put("url.com", data: {"id": 12, "name": "wendu"});
      print(response);
  } catch (e) {
      print(e)
  }
}

این متد هم دقیقا مثل متد POST نوشته میشه.

متد DELETE

زمانی استفاده میشه که بخوایم یه مقدار رو حذف کنیم.

import 'package:dio/dio.dart';
void deleteHttp() async {
  try {
      Dio dio= Dio();
      Response response = dio.delete("url.com/2");
      print(response);
  } catch (e) {
      print(e)
  }
}

تو این مثال درواقع داریم آیتمی با id دو رو حذف می‌کنیم. خوب تا اینجا که به نظرم کار خیلی ساده بود.


رسیدگی به Error ها

ارور ها و اکسپشن ها مربوط به Dio با استفاده از کلاس DioError مورد بررسی قرار میگره. این به این معنیه که وقتی اررور یا اکسپشنی اتفاق میوفته در عبارت try-catch، یه ابجکت DioError پرتاپ میشه و ما با استفاده از catch اون رو مورد بررسی قرار میدیم. به تیکه کد زیر توجه کنید.

try {
    //404
    await dio.get("https://wendux.github.io/xsddddd");
} on DioError catch(e) {
    if(e.response) {
        print(e.response.data)
        print(e.response.headers)
        print(e.response.request)
    } else{
        print(e.request)
        print(e.message)
    }
}

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

  • ارور های سیستمی
  • ارور های response(پاسخ)

از ارورای سیستمی میشه به خاموش بود کانکشن های اینترنت (مثل WiFi و دیتا) یا قطع بودن اینترنت اشاره کرد و ….

و از اررور های پاسخ میشه به اررور 404 اشارده کرد( در واقع Dio هر ریسپانسی که status کدش بین 200 تا 300 نباشه رو به صورت یک اررور برمیگردونه- البته این اپشین قابل تنظیمه).


کلاس Request Option

این کلاس زمانی استفاده میشه که میخواید با استفاده از Dio یه درخواستی رو ارسال کنید. کار با این کلاس خیلی مهمه و با استفاده ازش میتونید درخواست هاتون رو شخصی سازی کنید. این کلاس از متغیر هایی زیر تشکیل شده

Request Option
{
/// Http method.
String method;

/// Request base url, it can contain sub path, like: "https://www.google.com/api/".
String baseUrl;

/// Http request headers.
Map headers;

/// Timeout in milliseconds for opening  url.
int connectTimeout;

///  Whenever more than [receiveTimeout] (in milliseconds) passes between two events from response stream, [Dio] will throw the [DioError] with [DioErrorType.RECEIVE_TIMEOUT].
int receiveTimeout;

/// Request data, can be any type.
T data;

/// path will be added to base url
String path=""

/// request content type
String contentType;

/// request Response type
ResponseType responseType;

  /// `validateStatus` defines whether the request is successful
  ValidateStatus validateStatus;
  
  Map extra;
  
  /// Common query parameters
  Map*/ > queryParameters;  
  }

توضیحات مختصری درمورد هرکدوم از مقادیر بالا:

  • متغیر Method: به عنوان نوع نوع درخواست http میشه ازش استفاده کرد. (Post, Put, Delete,Get)
  • متغیر BaseUrl: به عنوان آدرس اصلی استفاده میشه. مثلا اگه دامنه Api هاتون مشخصه میشه این متغیر رو ثابت تعریف کنید.
  • متغیر Headers: که با استفاده از یه Map میتونید هدر های درخواستتون رو مشخص کنید.
  • متغیر connectTimeout و receiveTimeout: اولی برای تا زمان اتمام برقراری ارتباط و دومی برای زمان ارتباط دریافت جواب هستش.
  • و مواردی که کاملا مشخص هستند و خودتون میتونید مطالعه کنید و از بحث این آموزش خارجه.

با استفاده از این کلاس میتونید درخواست هاتون رو شخصی سازی کنید. همچنین میتونید یه ابجکت ثابت برای همه ی درخواست هاتون استفاده کنید. برای اینکار میتونید یه requestOption درست کنید و به وقتی دارین ابجکت Dio رو میسازید به این ابجکت پاسش کنید. به کد زیر نگاه کنید.


استفاده از Dio در این پروژه

ما در این پروژه از Dio استفاده کردیم، و یه کلاس به اسم سرویس درست کردیم تا کارهای مربوط به ارتباط با سرور مون رو اونجا پیاده سازی کنیم. میتونید به آدرس زیر برید و با توجه به چیز هایی که یاد گرفتید کد مربوط به پیاده سازی Api رو مطاله کنید.

https://github.com/payam-zahedi/featured-food-sample/blob/master/lib/api/service.dart

لینک کلاس


تو کلاس بالا مهم ترین بخش، متد دریافت اطلاعات مربوط به غذاهاست. اگر به کد زیر نگاه کنید متوجه میشید که با استفاده از متد GET، یه درخواست به فایل /db ارسال کردیم و بعد از پارس کردن json یه لیستی از غذا هارو برمیگردونیم.

static Future fetchData() async {
  try {
    Response response = await getInstance().get("/db");
    if (response.statusCode == 200) {
      // If server returns an OK response, parse the JSON.
      var jsonString = json.encode(response.data);
      Map userMap = jsonDecode(jsonString);
      return FoodList.fromJson(userMap);
    } else {
      // If that response was not OK, throw an error.
      throw DioError(message :'exception throwed in Try');
    }
  } on DioError catch(e) {
      throw Exception("SomeThing is Wrong: n ${_checkError(e)}");
  }
}

اگر پیشهاد، انتقاد یا نظری دارید خوشحال میشم که با به اشتراک گزاشتنش باعث بحبود عملکردم بشید ممنون.


منابع

https://pub.dev/packages/dio

https://medium.com/flutter-community/dio-interceptors-in-flutter-17be4214f363

https://blog.usejournal.com/flutter-http-requests-with-dio-rxdart-and-bloc-da325ca5fe33

نوشته آموزش فلاتر ( Flutter ) – ارتباط با سرور Dio اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

گیت هاب چیست ؟

گیت هاب چیست ؟

🐱 گیت هاب یک شبکه اجتماعی توی فضای ابری ☁️ یا همون کلود برای برنامه نویس ها 👨🏽‍💻هست و یک پلتفرم همکاری برای توسعه دهنده هاست💻📱 که فضای ذخیره سازی بزرگی در اختیار همکارا قرار میده.👌🏾

گیت یک سیستم کنترل ورژن اوپن سورس هست. کنترل ورژن چیه؟
وقتی برنامه نویس ها یک برنامه خلق میکنن، بعد از پابلیش کردن اولین نسخه، تغییرات زیادی روی کد انجام میدن، کنترل ورژن این تغییرات رو ساده میکنه 😋و همه رو توی یک قسمت به نام ریپوزیتوری ذخیره میکنه، 👈🏽این قابلیت به برنامه نویس ها و به اعضای یک تیم این کمک میکنه تا به راحتی نسخه جدید نرم افزار رو دانلود کنن، روش تغییرات انجام بدن و در نهایت آپدیت جدید رو ارائه بدن..

یک سری مفاهیم واسه گیتهاب وجود داره مثل:
Fork, commit, merge, branch and etc
که توی مقاله بعدی توضیحشون میدم.

⚠️✅ضرورت یادگیری:
این که شما کار با گیت رو بلد باشین به نحوی کلاس کاریتون رو بالا بردین و اکثر شرکتها دوست دارن تا برنامه نویسشون این قابلیت رو داشته باشه و براتون یک امتیاز حساب میشه.
👈🏽سعی کنین استفاده از گیت رو از طریق ترمینال یاد بگیرین و حتی الامکان از نرم افزارهایی که بهتون یک یو آی ساده میدن استفاده نکنین.از همون اولش کار سخت رو یاد بگیرین 💪🏾 که کاملا درک کنین مراحل کار رو..

نویسنده : https://www.instagram.com/jawadabbasnia.coder/

نوشته گیت هاب چیست ؟ اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

گوشه ای از مصایب نبود اینترنت و زوایای پنهان آن

+الآن که اینترنت نیست به عنوان یک فرد عادی و یه دانشجوی کامپیوتر یکی از سه دانشگاه برتر کشور(برنامه نویس) خیلی کار ها رو نمی تونم انجام بدم!

-چی مثلا؟🧐

+ 😐😐{محو می شود}


۱. جیمیل(gmail) ام رو نمی تونم استفاده کنم(ایمیل دانشگاه هم کاربردش اصلا به پای جیمیل نمیرسه، کنده و مشخصا برای کارای روزمره نیست). تازه حالا من جیمیل ام. خیلی ها outlookان یا yahoo.

۲. سرویس های مهم دیگر گوگل مثل google scholar ،drive ، sheets ،forms ،calender،‌ translate رو نداریم ( ناگفته نماند که معاونت دانشکده با رییس دانشکده نتونستن قرار ملاقات بذارن چون تقویم گوگل رییس دانشکده پریده و بنده خدا برنامه کاراشو نمیدونست. کلی از اطلاعات مون هم درون گوگل درایوه نمیشه برداشت الان)

۳. دیکشنری آنلاین

۴. درس های آنلاینم رو نمی تونم انجام بدم(مثل coursera ،udacity، stanford و …)

۵. هر سایت داخلی ای که gmailرم رو داده باشم و برحسب اتفاق رمزم رو مرورگر یا بنده نداشته باشیم نمیشه رمزشو بازیابی کرد!

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

۷. موتور جست و جو ندارم. اگه اسم سایتا رو حفظ نباشم و ذهنم یه شبکه تشکیل نداده باشه از سایتایی که برای مثال میشه ازشون نرم افزار دانلود کرد، کاری ازم برنمیاد. از قضا ذهن اکثر افراد این کارایی رو نداره(اصن برا همین موتور جست و جو ساخته شده). و در ضمن اگر واقعا هم سایت های داخلی خوبی برا یه سری کارا وجود داشته باشه بازم نمی تونیم پیداشون کنیم(نقطه مبدا مختصات به فنا رفته انگار). هر چی هم مورد جست و جو تخصصی تر بدبختی بیشتر. شاید یکی دو تا سایت خرید خوب وجود داشته باشه. اما جواب یک سوال تخصصی از مطالعه ی شاید متوسط ۵۰ صفحه دربیاد!

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

تازه برنامه نویسی صرف به کنار، ریاضیات و علوم دیگر هم از دستمون درومده.

۹. نمی تونیم جزوه و فایل درسی(یا حالا هر فایلی) به اشتراک بذاریم(استادا و تی ای ها می تونن تو یه سایت مخصوص ولی ما نمی تونیم)

۱۰. ملت کار اپلای و فرصت مطالعاتی و همه چیشون خوابیده

۱۱. با دوستان و اقوام خارج از کشور نمیشه ارتباط داشت

۱۲. کانالای تلگرامی که ازشون خرید می کردم پریدن

۱۳. آهنگایی که تو تلگرام داشتم و دانلود نکردم رو دیگه ندارم

۱۴. اسپاتیفای نداریم

۱۵. سایت های ورژن کنترل(گیت هاب، گیت لب و …) رو نداریم که کد‌هایی که میزنیم به اشتراک بذاریم.

۱۶. نرم افزارهایی مثل trello که برای هماهنگی کار تیمیه نمیشه استفاده کرد. حالا بیا و مهاجرت کن رو یه پلتفرم خام دیگه…

۱۷. مطالعه نمی تونیم بکنیم یا بهتره بگم در کمترین حالت ویکی پدیا نداریم. ممکنه بفرمایید کلی سایت ایرانی هست که درباره خواص خیار و زیستگاه خفاش غول آسا نوشته باشن که باید عرض کنم طبق مورد ۷ اولا پیدا نمیشه کرد. دوما بی تعارف محتوای این سایت ها افتضاح خالصه! ۶۰ درصد صفحه رو که تبلیغات گرفته، ۲۰ درصدش هم لینک به مطالب مزخرفی مثل یک شبه پولدار شدن و راز زیبایی پوست خانم سحر قریشی هست، ۱۰ درصدش مطالبیه که از ویکی پدیای فارسی اومده(متوسط ۲ پاراگراف) و ۲۰ تا نتیجه جست و جوی بعدی هم که گوگل ( یا در شرایط فعلی موتور داخلی) میاره برا آدم هم، همین وضع رو با فونت متفاوت دارن.

۱۸. نرم افزارامون رو نمی تونیم آپدیت کنیم. چه گوشی، چه لپ تاپ. چه سیستم عامل، چه برنامه های کاربری.

۱۹. خرواری از بازی های آنلاین هم از دسترس خارج شدن. شاید بنظر شما مهم نباشه ها ولی خب دلیل نمیشه ایرادی نداشته باشه این موضوع. خوبه فقط یه کانال تلویزیون داشته باشین؟

۲۰. خیلی از کتابخونه های برنامه نویسی و پکیج هایی که برای برنامه نویس ها ضروری هستن تو سایتای داخلی نیستن اصن!! پیدا کردنش به کنار، نیست کلا!

۲۱. آنتی ویروس بنده از کار افتاده چون باید با سرورش تو خارج از کشور در ارتباط باشه.

۲۲. کسی گوشی جدید بخره نمی تونه درست عین آدم راش بندازه.

۲۳. یوتیوب هم انقدر مهمه که باید جدا از همه چیز گوگل بیاد. لطفا بیخیال اون سایت اشتراک ویدیو داخلی هم بشید. خوبه ها! یه سری چیزا هم توش هست که تو یوتیوب نیست. ولی خب کهکشانی از چیز ها در یوتیوب هست که اونجا نیست.

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


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

  1. مردم وقتشون رو از سر راه نیاوردن که ۱۰-۲۰ سال برن عقب و چیزایی مثل گوگل و تلگرام و جیمیل رو مجبور شن با بدبختی پیدا کنن و یا با دردسر نصب کنن، کیفیت پایین و امکانات کمشون رو هم تحمل کنن. خیلی از افراد اصلا نمیدونن واژه پروداکتیویتی چی هست ولی تو این وضع آسیب خوردنش رو میشه اینطور توصیف کرد که من نویی باید ۱ الی ۲ ساعت وقت مفیدم رو صرف کنم که یه جزوه تو بستر جدید به اشتراک بذارم در حالیکه قبلا ۵ دقیقه ای با تلگرام رفته بود، کار ملت هم راه افتاده بود. کاملا مثل اینه آدم از لحاظ مالی یه شبه ورشکست بشه. بجای جت هر روز با دوچرخه بره سرکار.
  2. اگر این چیز هایی که میفرمایید خوب بودن به قدر کافی وقت داشتن که مخاطب جذب کنن ولی نکردن. حالا بهشون این فرصت رو میدیم که بدون رقابت خودشون رو به زور بقبولونن و بهتر هم نخواهند شد. برای بعضی چیزا دیگه جایی تو جهان نیست چه برسه به ایران. وجود داشتنشون به این معنی نیست که خب خداروشکر داریم استفاده کنیم!! دستمال کاغذی که نیست! وجه اجتماعی و انسانی و جنبه های دیگر این چیز ها خیلی پیچیده تر از این هاست. شما دوست داری فلان نرم افزار داخلی رو استفاده کنی؟ خب بفرمایید. چون شما دوست داری ما هم باید دوست داشته باشیم؟ الان به فرض بر اثر یه چیزی فردا همه اپراتورای داخلی قطع شن خوبه یه عده بگن آخجون خب با واتساپ همش رو اینترنت حرف میزنیم؟! حالا چون شما پنیر دوس داری دلیل نمیشه بگی حالا که خامه نیست خداروشکر پنیر که داریم چرا معترضید!! تا این حد واضحه عمق غلط بودن استدلال یه سری هم وطن ها.
  3. تا ابدالدهر هم نمی تونیم محتوایی که برنامه نویسا و دانشمندا دارن با سرعت نور تولید میکنن و با هم در اینترنت به اشتراک میذارن تولید کنیم داخل کشور. حتی اگر کیفیت سایتای داخلی و اینترانت ۱۰۰ از ۱۰۰ بشه. خیلی چیزها زیرساخت نیستن متفکرین محترم عرصه ی خودکفایی یا حالا هرچی/:
  4. فقط بخش خیلی کوچیکی از موارد بالا با پیامرسان داخلی حل میشه. چون این روزا هر چی میگیم ماشالله مسئولین و خبرگزاری های داخلی میگن پیامرسان داخلی هست! تراکنشای بانکی سرجاشه! ماشین و آژانس میشه گرفت. کل زندگی ما خلاصه شده تو این موارد مثل اینکه…


پ.ن : منظور نویسنده این نیست که هر چی داخلیه بده. خیر! خیلی چیزها هستن که تو دنیای تکنولوژي خودشون رو رسوندن به سطح استاندارد و اصلا باید! داخلی باشن. اما هرچیزی جای خودش رو داره. خیلی از این موارد مثل چرخ ان که نباید از اول اختراع کرد.

نوشته گوشه ای از مصایب نبود اینترنت و زوایای پنهان آن اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی