تعرف على كيفية استخدام Phoenix Framework للاستمتاع ببناء تطبيقات الويب/الهاتف المحمول في الوقت الفعلي
التي تكون سريعة " للمستخدمين النهائيين "، وموثوقة ، وقابلة للتطوير ، وقابلة للصيانة ، وقابلة للتوسعة ( بسهولة )!
كمطورين لتطبيقات الويب/الجوال، نحتاج إلى الاستفادة من العمل الذي قام به أشخاص آخرون ( أذكياء حقًا ).
بدلاً من بناء الأشياء باستمرار " من الصفر " طوال الوقت؛ ولهذا السبب نستخدم أطر العمل لبناء تطبيقاتنا!
راجع: " أهم 10 أسباب لماذا فينيكس " ( أسفل هذه الصفحة! )
هناك العديد من أطر العمل للاختيار من بينها ( تم ذكر عدد قليل من الأطر "الشائعة" أدناه في قسم " الأسئلة " ).
ولكن إذا اتبعنا ما هو " شعبي " فسنظل نركب الخيول ( والعربات ) في كل مكان ولن يتم إحراز أي تقدم .
ملحوظة : جميع الأسباب " لماذا " الخاصة بالإكسير تنطبق أيضًا على فينيكس !
التحقق منها: https://github.com/dwyl/learn-elixir#why
إطار تطبيق ويب دون أي تنازلات !
إن " العائق " الأكبر في أي مشروع تكنولوجي هو الأشخاص . يمكن لـ "رائد الأعمال"/"المؤسس" أو "مالك المنتج" أن يمتلك كل الأفكار الجيدة في العالم، إذا لم يتمكنوا من تحويل الفكرة إلى واقع ، فهذا لا معنى له .
من الواضح أنه يجب عليك تشغيل المعايير الخاصة بك على أجهزتك/السحابة الخاصة بك واتخاذ قرارات مستنيرة بناءً على متطلبات تطبيقك/منتجك، ولكن ... عندما نقرأ الإحصائيات الخاصة بعدد المستخدمين المتزامنين الذين يمكن لتطبيق Phoenix التعامل معهم ( مع البث المباشر اتصالات WebSocket ) لقد أذهلتنا ! وهذا يعني أنه يمكننا إنشاء تطبيقاتنا في الوقت الفعلي باستخدام موارد أقل بنسبة 90%.
كل هذا يعني أنك تنفق أموالًا أقل بكثير على البنية التحتية للأجهزة/السحابة حتى يتمكن تطبيقك/شركتك من الحصول على ميزة تنافسية من حيث التكلفة .
إذا كنت محظوظًا للتفكير في استخدام شيء أفضل لمشروعك القادم ، فلا تنظر إلى أبعد من Phoenix!
اقرأ المزيد: http://www.phoenixframework.org
يستخدم العديد من الأشخاص/الفرق/الشركات بالفعل Erlang/Elixir وPhoenix ويشاهدون نتائج مذهلة!
بما في ذلك: Adobe، BBC، Spotify، Pinterest، Discord (تطبيق Gamer Chat)، Groupon (Fave)، Lonely Planet، Brightcove، Slack ...
انظر: https://github.com/doomspork/elixir-companies
لا يمكنك إنشاء تطبيق Phoenix دون معرفة Elixir.
إذا كنت جديدًا في Elixir، قم بوضع نجمة ( إشارة مرجعية ) this الريبو ( حتى تتمكن من العودة إليه غدًا )
ثم انتقل إلى: github.com/dwyl/ learn-elixir تعلم الإكسير حتى تشعر أنك تفهم بناء الجملة، ثم عد وتعلم فينيكس!
على وجه التحديد، يجب عليك التركيز على تعلم "أساسيات" الإكسير:
يستخدم Phoenix Node.js لتجميع الأصول مثل ملفات JavaScript وCSS ( باستخدام Webpack).
ما عليك سوى التأكد من تثبيت Node.js. https://nodejs.org
لا تحتاج إلى معرفة Node لاستخدام Phoenix.
إذا كنت قد تعلمت بالفعل بعض Elixir وقمت بتثبيت Node.js، فإن الخطوة الأولى لبدء استخدام Phoenix هي التثبيت!
وثائق Phoenix مذهلة، لذا نوصي باتباع تعليمات التثبيت الرسمية لـ Phoenix!
ستحتاج أيضًا إلى تثبيت PostgreSQL، وهناك برنامج تعليمي لكيفية القيام بذلك مرتبط بدليل تثبيت Phoenix المرتبط أعلاه، ولكن يمكنك أيضًا مراجعة مستودع learn-postgresql الخاص بنا للحصول على الإرشادات، وإثارة مشكلة إذا واجهت أي مشكلة !
على الرغم من أن الفهم الأساسي لجافا سكريبت يمكن أن يكون مفيدًا في بعض الأحيان، إلا أنك لا تحتاج إلى معرفة كيفية استخدام Node لاستخدام Phoenix.
إذا كنت مهتمًا بالسبب الذي جعلهم يختارون Brunch.io بدلاً من " البدائل "،
الجواب القصير هو: البساطة والسرعة! انظر: http://brunch.io/docs/why-brunch
ملاحظة : يستخدم الإصدار 1.4 من Phoenix ( لم يتم إصداره حتى وقت كتابة هذا التقرير ) WebPack لتجميع الأصول، راجع: CHANGELOG.md
تعرف على دليل "التشغيل والتشغيل" ( الرسمي ): https://hexdocs.pm/phoenix/up_and_running.html#content 
بمجرد تثبيت Phoenix واتباع دليل "التشغيل والتشغيل" الرسمي ،
عد وجرب هذه الأمثلة الملائمة للمبتدئين :
نوصي الأشخاص بشراء ( أو استعارة ) كتاب @chrismccord: "برمجة فينيكس"
انظر: https://pragprog.com/book/phoenix14/programming-phoenix-1-4 
المؤلفون مثيرون للإعجاب بشكل فردي وهم بشكل جماعي يغطون فينيكس بشكل شامل كما لا يستطيع أي شخص آخر! قام كريس بإنشاء Phoenix، وقام José بإنشاء Elixir، وبروس هو مؤلف تقني ذو خبرة كبيرة وله العديد من الكتب الناجحة باسمه!
( أي: الكتاب هو الاختيار الواضح لكيفية تعلم فينيكس! )
https://youtu.be/MD3P7Qan3pw
https://youtu.be/srtMWzyqdp8
" توفر شركة Phoenix إنتاجية Ruby-on-Rails
مع التزامن والتسامح مع الأخطاء في Erlang ."
يستخدم Phoenix لغة برمجة Elixir مما يعني أنه تم تجميع تطبيقك وتشغيله على Erlang Virtual Machine "BEAM".
Erlang عبارة عن جهاز افتراضي تم اختباره في المعارك وذو قدرة عالية على تحمل الأخطاء، وتستخدمه العديد من شركات الاتصالات
WebSockets (" القنوات ") مدمجة في إطار العمل مما يعني أن إنشاء التطبيقات باستخدام الاتصال والتفاعل "في الوقت الفعلي" أسهل بكثير من أي إطار/منصة أخرى تقريبًا! ( لا حاجة إلى وحدة magic تابعة لجهة خارجية! كل ما تحتاجه موجود بالفعل وجاهز لخدمة ملايين الأشخاص!! )
انظر: http://www.phoenixframework.org/docs/channels
سهولة عدم التزامن لأن جميع البرامج في Phoenix ( Elixir ) عملية ! وهذا يعني أنه من السهل جدًا تجريد الوظائف المفيدة مثل مصادقة الطلب وتسجيله ومعالجته في " خطوط أنابيب " يسهل على الإنسان قراءتها ! ( لا توجد حاجة إلى وحدة async لجهة خارجية! لا توجد "وعود" أو "مولدات" أو "يمكن ملاحظتها" لإدارتها!! )
عقلية الأمن والمرونة هي العقلية default . يعد التشفير (SSL) سهلاً في Phoenix/Elixir، كما أن كلا من تخفيف حقن SQL والبرمجة النصية عبر المواقع ( XSS ) وحماية CSRF مدمجة ( ممكّنة default ) لذا فمن المستحيل تقريبًا على المبرمج " المبتدئ " تقديم هذا النوع من الخلل الأمني.
لا يمكن الاستهانة بالرمز الموجز ! يمكننا كتابة أسطر أقل بكثير مما هو عليه في تطبيق Node.js/Java/Rails/Go المكافئ ، وهذا يعني أن المطورين أكثر إنتاجية وهناك تعليمات برمجية أقل يجب الحفاظ عليها !
قابلية الاختبار بسبب البرمجة الوظيفية لجميع وحدات التحكم!
سهولة النشر : https://hexdocs.pm/phoenix/heroku.html
النشر بدون توقف هو مجاني ! ( مرة أخرى بسبب إرلانج ). يدير Erlang نقل المستخدمين " المباشرين/النشطين " من الإصدار القديم إلى الإصدار الجديد من تطبيقك دون أن يلاحظوا حتى أنه تمت ترقيته/تحديثه!!
تعني المراقبة/الإدارة المضمنة لتطبيقك من خلال مشرفي Erlang أنك تعرف بالضبط كيفية أداء تطبيقك، والأجزاء التي تعطلت/أعيد تشغيلها، ولماذا! هذه ميزة ندفع مقابلها ( كثيرًا ) في أطر عمل أخرى وهي هنا مجانية !!
هل يمكنك التفكير في سبب آخر يجعل استخدام Phoenix رائعًا ؟!
شاركنا برأيك في هذا الموضوع: رقم 13
before تجربة/استخدام فينيكس؟نعم . انظر: https://github.com/dwyl/learn-elixir
لا . يمكنك البدء في تعلم/استخدام Elixir اليوم والاتصال بوظائف Erlang عند الحاجة.
لكنك لا تحتاج إلى معرفة Erlang before أن تتمكن من استخدام Phoenix!
هناك العديد من أطر تطبيقات الويب التي يمكنك/يمكننا الاختيار من بينها: https://en.wikipedia.org/wiki/Comparison_of_web_frameworks
فلماذا يختار أي شخص إطارًا مكتوبًا بلغة برمجة ليست " سائدة "...؟
هذه معلومات خاطئة . ما زلنا نستخدم Hapi.js لعدد من المشاريع عندما يكون ذلك مناسبًا .
يتضمن ذلك العديد من مشاريع العملاء وتطبيقات/أدوات dwyl الداخلية.
قررنا استخدام Phoenix في مشاريعنا الجديدة لهذه الأسباب البسيطة:
#LessIsMore #LessButBetter #SmallIsBeautiful #SyntaxMattersبالنسبة لمشاريعنا الجديدة ، نحتاج إلى التسامح مع الأخطاء في مراكز البيانات المتعددة !
نحصل على ذلك " مجانًا " باستخدام Erlang -> Elixir -> Phoenix !!
في رأينا، لا يزال Hapi.js " أفضل " إطار عمل Node.js continue في استخدامه والتوصية به
للأشخاص الذين يحتاجون إلى تطبيقات بسيطة قابلة للتوسيع ويسهل صيانتها.
انظر: https://github.com/dwyl/learn-hapi
كما أننا لا نزال نستخدم JavaScript لجميع خدماتنا الصغيرة AWS Lambda، وهذا لن يتغير.
إنها بسيطة وفعالة وذات حجم جيد حقًا!
انظر: https://github.com/dwyl/learn-aws-lambda
أطر الويب " الإنتاجية " الأصلية كانت "Ruby-on-Rails" و"Django" ( python ) في عام 2005!
(لقد استخدمنا كلاهما لفترات من " رحلتنا " ويمكننا التحدث عن مزايا كل منهما!)
لا حرج في استخدام Rails أو Django.
نعتقد أنه لا يزال هناك الكثير من حالات الاستخدام لكلا الإطارين.
نحن نعلم فقط أنه من الأسهل ( كثيرًا ) إنشاء "في الوقت الفعلي"
مع Phoenix لأنه تم خبز "القنوات" ( WebSockets )،
وتزامن Elixir/Erlang هو لعبة مختلفة تمامًا!
يمكن لـ Erlang (وبالتالي Phoenix) التعامل مع ملايين المستخدمين المتزامنين على خادم واحد،
بينما يمكن لخادم Rails/Django التعامل مع بضعة آلاف فقط ( في أحسن الأحوال !)
إذا كان تطبيقك يخدم بضعة آلاف من الأشخاص فقط في وقت واحد، فأنت بخير!!
نحن نحب حقيقة أن Erlang يستخدم عمليات " خفيفة الوزن وطويلة الأمد "،
مما يعني أنه يمكننا توصيل ملايين أجهزة ( IoT ) ... بالنسبة لإنترنت الأشياء، فإن Erlang ( بلا شك ) هو الحل!
بالنسبة لتطبيقات الويب الأبسط حيث لا تتوقع سوى عدد قليل من المستخدمين يوميًا، لا يزال Rails/Django قابلاً للتطبيق.
ولكن لماذا التسوية إذا لم يكن لديك ل ؟
إذا كان بإمكانك الحصول على سيارة تسلا "بسعر" سيارة فورد فوكس، فلماذا لا تفعل ذلك؟!؟
لماذا ترضى بالخير بينما يمكنك بسهولة الحصول على/استخدام الأفضل ؟
نعم ، لا يزال GitHub يستخدم Rails لتطبيق/موقع الويب الخاص به.
لكن اسأل أيًا من الفريق الأساسي في GitHub عما إذا كان سيختار Rails ( إذا أُتيحت له الفرصة للبدء من جديد ).
لبناء GitHub في عام 2017، وانظر كم منهم يقول " نعم بالطبع " ( بوجه مستقيم... )!
أيضًا، يقوم GitHub بالكثير من الأشياء لتوسيع نطاق Rails في الخلفية.
والعديد من ميزاتهم الأحدث ( من جانب العميل ) مكتوبة بلغة JavaScript! انظر: https://github.com/github
خلاصة القول هي: يمكن توسيع نطاق أي شيء باستخدام "DevOps"،
ولكن تم تصميم Phoenix للقياس بشكلdefaultلأن Erlang (تم) اختراعه (لقياسه)!
" هناك نوعان من لغات البرمجة - تلك التي لا يستخدمها أحد وتلك التي ينتقدها الجميع " ~ بيارن ستروستروب ( مبتكر لغة
C++)
اذهب تحظى بشعبية كبيرة . ويرجع ذلك إلى حد كبير إلى حقيقة أن Google " ترعى " ذلك.
كان الهدف منه تبسيط ( استبدال ) C++ وJava داخل Google...
وقد نجحت في الغالب!
نحن حقا نحب الذهاب. لقد كان خيارنا "الثاني" عند تحديد لغة البرمجة
( بعد Elixir ) في "مكدس JS الخاص بنا"... كان قرار استخدام elixir بدلاً من أي شيء else سهلاً :
مزيد من القراءة:
Play Framework بدلاً من ذلك ...؟ إذا كنت معتادًا بالفعل على كتابة Java أو النشر إلى JVM، فإن Play Framework يعد خيارًا رائعًا : https://www.playframework.com
Scala هي لغة برمجة جيدة ويجب على الجميع تعلمها! https://www.scala-lang.org/what-is-scala.html
لقد استخدمنا Play عدة مرات ( قبل أن نعتمد Node.js ) وأعجبني حقًا !
لكن Scala هي لغة برمجة "حوض المطبخ" ( متعددة النماذج ) التي تسمح للأشخاص باستخدام " كل لغة Java " ...
نعتقد أن "قابلية التشغيل المتداخل لـ Java" الخاصة بـ Scala تعني أنه "من السهل جدًا" السماح بالتعقيد في قاعدة التعليمات البرمجية الخاصة بك. على وجه التحديد "طفرة OOP" ...
فلماذا لم نعد نستخدم "التشغيل" في المشاريع الجديدة ؟ أولاً، انتقلنا إلى Hapi.js ( Node.js ) منذ بضع سنوات لأنه كان " خفيف الوزن " ويسمح لنا بكتابة برامج صغيرة تستخدم فقط عددًا قليلًا من الميجا من ذاكرة الوصول العشوائي ( حيث كانت تطبيقات Play الخاصة بنا متعطشة للغاية للموارد. .! هل سبق لك أن حاولت تشغيل تطبيق Scala على جهاز كمبيوتر محمول "أساسي" مثل جهاز Chromebook...؟
ملخص "أسباب" فينيكس بدلاً من اللعب:
نعتقد فقط أنه بالنسبة لمشروعنا (مشاريعنا)، يعمل نموذج Erlang's Concurrency بشكل أفضل وأن تحويل التعليمات البرمجية الوظيفية للبيانات غير القابلة للتغيير أسهل في الاختبار والصيانة .
إذا كان لديك دليل على أن " Scala أبسط " فنحن نحب أن نسمع منك!
أخبرنا: https://github.com/dwyl/learn-phoenix-web-development/issues
إذا كنت تحب البرمجة الوظيفية ( FP ) كثيرًا، فلماذا لا تستخدم هاسكل؟
