يمكن الناس لما بتقرا القصه بتقول ايه العبط دا ازاي ميصدقوش نبي و يصدقو فرعون. او مثلا فرعون اللي عامل نفسه إله عبيط اوي هوا في إله مبيعرفش يعوم 😅
بس دا عشان احنا بنقرا كدا من بعيد مواقف كتير حوالينا الاجابات فيها واضحه و صريحه وفي مواقف سهله و بسيطه و بتلاقي الناس بتحسبها غلط
من الردود اللي متخيلها مثلا من الناس لو كنا عايشين في الوقت دا:
“ياعم خلينا جنب الحيط هوا فرعون دا حد قده”
“بص احنا قدام الناس نقول عاش فرعون بس ربنا عارف اللي في النيه بقي”
“هما ايه اللي خلاهم يعارضو فرعون يلا جابوه لنفسهم احنا
مالنا اهم حاجه ان احنا كويسين”
“احنا عايزين نربي عيالنا ملناش دعوه”
و من دا كتير بقي ف اعتقد ان بنو اسرائيل اللي كانو في الوقت دا ممكن يكونو احسن من كتير من الناس اللي موجودين في الوقت الحالي (دا ميقللش ابدا من شده كفرهم الواضح ولا حتي يبرره. دا اخر مفروغ منه) مثلا زي اخوات سيدنا يوسف برضه قالو احنا مش هنقتله ولا هنعمل حاجه غلط اوي. بصو نسيبه في البير بس و اكيد اي حد معدي هينقذه. و بعدها خلاص هنتوب. يعني حتي بيفكرو في التوبه
بس عامه الحمد لله ان ربنا محطناش في الاختبار الصعب دا. و دائما ندعي “اللهم لا تجعل مصيبتنا في ديننا” لأن الابتلاء في الدين دا حاجه صعبه جدا و ملوش كبير
]]>دي اول حاجه تحاول تعرفها في اول كام يوم ليك. هل هتكون مسؤول عن جزء معين من service? ولا هتكون شغال مع team مسؤول عن مجموعة من ال features. و ايه هو ال business domain اللي هتكون شغال فيه و حاول تفهمه كويس. يعني مثلا هتكون شغال في ال search team ولا ordering ولا payment و حاول تفهم ال business بتاع الجزء ده علي قد ما تقدر.
مثلا أنهم ال product بيكبر و عندهم مشاكل في ال scalability? او كان عندهم نقص في ال software engineers المسولين عن ال monitoring؟ او عايزين ناس اكتر عشان بيزود features اكتر؟
اعرف انت ايه اللي متوقع منك بالظبط انك تعرف دا هيساعدك مش ف انك بس تعدي ال probation ولكن انك تكبر في ال role اللي انت فيه و في الشركه عامة.
وأهم نصيحة ليك حاول تفهم كويس كل كبيرة وصغيرة عن ال business اللي انت هتشتغل عليه.
دا احسن وقت تسأل فيه عن اي حاجه مبهمة او مش واضحه ليك. متتكسفيش ولا تحس ان اسئلتك غبيه. لأن انت لسه جديد ف دا طبيعي جدا. حاول تطلب من مديرك أن يكون كل اسبوع عندك on boarding buddy. يعني كل اسبوع يكون في حد من ال team هوا اللي بترجع له لو عايز تسال في حاجه. ومفيد لسببين
انك متعطلش ال team او تشتتهم بأسألتك
كل فرد في الـ team بيبقي شاطر اوي في جزء ما في ال project ف تبقي جمعت معلومات من كل الخبرات في كل اجزاء ال project علي قد ما تقدر.
كمية المعلومات اللي هتوصلك في اول فتره ليك هتكون كبيره جدا و دا طبيعي. وطبيعي أن حجم المعلومات ممكن يكون اكبر من استيعابك في اوقات كتير. عشان متنساش المعلومات دي اعمل document على جنب اكتب فيه اي حاجه حد يقولهالك. حتى لو كانت link ل حاجه في ال system. اكتب برضه الاسئلة و الاجابات اللي كنت بتسألها طول فتره ال onboarding عشان لو نسيت حاجه منهم متروحش تسألها تاني.
شخصيا انا عندي document زي دا من اول يوم بروح فيه اي شركه. في الغالب مش بيبقي منظم اوي بس بعد شويه بقسم الحاجات دي. المعلومات اللي كاتبها مثلا كانت عبارة عن
Commands معينه عشان اعمل حاجه معينه
شخص معين انا عرفت انا مسؤول عن حاجه معينه ف عايز افتكر اني لو احتاجت اسأل عن حاجه تاني ارجعله
شرح لحاجة حد قالي عليها واحنا بندردش
Links ل slack threads فيها كلام مهم
حاجه اتشرحتلي و مفهمتهاش و عايز ارجع لها تاني
Dashboards لحاجات معينة في ال projects
دايما اي team لو عنده documentation هتكون في تفاصيل ناقصة هما مش واخدين بالهم منها عشان أيديهم دائما في الشغل. ممكن قرارات كتير تكون مش مكتوب هما قرروها ليه لانهم عارفين هما عملو دا ليه. ف دايما ال fresh eye او الحد الجديد هوا اللي ممكن ياخد باله من النقص دا. ف دا احسن حاجه تعملها انك تحاول ت contribute لل documentation بالحاجات اللي انت شايفها ناقصه و دي هتبقي حاجة كبيرة تتحسب ليك انك بتحاول تحسن شغلك حتى من اول يوم
يعني ايه الاول brag document هو مكان تكتب فيه كل انجازاتك اللي عملتها سواء كبيره او صغيره. عشان كل مره تقعد مع مديرك مش هتكون ولا انت ولا هو فاكرين كل تفاصيل الحاجات اللي عملتها. دائما حاول تقول ايه ال impact بتاع كل حاجة انت عملتها
لو عايز مثال علي ازاي تعمل brag document كويس دا مقال بيتكلم بالتفصيل عن ازاي تعمل كدا https://jvns.ca/blog/brag-docuenter code herements/
بس لو عايز رأيي الشخصي مش لازم تمشي على مثال ولا standard. اكتب بالطريقه اللي تريحك و مع الوقت اقرا و اتعلم و حسن مع الوقت عشان متصعبش الموضوع على نفسك. Always start simple
من اهم الحاجات اللي هتخلي ان ميحصلش اي مفاجئات وقت ال review اللي بيحصل بعد اول ٦ شهور انك دايما تعمل اجتماع دوري مع مديرك تتكلمو فيه عن ال progress بتاعك. عشان دايما تبقي عارف ايه ال review او الانطباع اللي هوا واخده عن شغلك.
خلي دايما ال meeting دي يبقي ليها meeting minutes مكتوبة في مكان ما انتو الاتنين شايفينه (ممكن share google doc). لازم برضه تكتب action plan واضحه و صريحه ليكو انتو الاتنين. لو مديرك طلب منك اي action لازم ال action دا يكون tangible values واضحه و صريحه. يعني مثلا مينفعش ال action يكون انه يقولك اقرا كتاب او خد كورس او حسن كودك. لا لازم يكون في results واضحة.
زي مثلا اقرا كتاب كذا. دي نتائجها ممكن تكوت
اعملنا session تشرح فيها النتايج
او اللي اتعلمته
و ايه من الكتاب دا استفدت منه
و ايه ممكن نطبقه في الـ team عندنا
مثلا لو قالك improve your code quality ممكن مثلا يظبطلك pair programming session كل فتره مع حد معين او كورس تاخده او كتاب تقراه و نتايج دا ان ال code review changes اللي بتتحط ليك تبقى non-trivial شويه.
الخلاصة لازم اي action يبقي ليها خطوات واضحه و صريحه و نتايج برضه واضحه و صريحه عشان ما تتفاجئش في الاخر ان مش هوا دا اللي هوا عايزه.
زمايلك الجداد هما بالنسبالك showledge shareholders هما اللي ممكن يسهلو عليك اي حاجه انت شغال عليها او يفهموك اي حاجه انت شغال عليها او يفهموك حاجه انت لسه مش فاهمها كويس. و هتلاقي كل واحد منهم فاهم كويس اوي في جزء معين في ال system. فحاول انك تخلي علاقتك كويسه بيهم كلهم عشان يبقي عندك credit انت تطلب مساعدتهم بعد كدا. و في نفس الوقت انت اعرض عليهم المساعدة في اي حاجه تقدر تساعدهم فيها حتى من قبل ما يطلبو منك.
اول ما هتروح اي team جديد هتلاقيهم مجهزين list بال tickets اللي ممكن تكون هتشتغل فيها. نصيحتي ابدا بابسط ticket تقدر عليها علشان اول ticket انت هتكون متوتر و عشان نفسيا تلاقي نتيجه بسرعه و تحس انك بتطلع شغل. خد بالك ان كمان هتاخد شوية وقت عقبال ما تعرف تشغل الـ project لاول مره علي جهازك. نصيحه كمان لو عندهم guideline ازاي تشغل ال project علي جهازك امشي وراه و في الغالب بيبقي في نقط ناسينها او ال document نفسه outdated لان بقالهم كتير شغالين على نفس ال project ف مش واخدين بالهم انهم يعدلو علي ال document. ف هتكون فرصه حلوه انك تساعدهم في انك تعمل update لل document دا.
نصيحه كمان اوعي تبدأ ب critical ticket أو ticket بتعدل علي core feature عشان لو حصل مشكله مش بس ممكن دا ياثر علي تقييمك. لا انت كمان ممكن ثقتك في نفسك تقل. و دا حصل معايا كتير.
طيب خلصت اول ticket ازاي اختار ال tickets. ساعات هتلاقي مديرك بيقولك خد ال ticket دي. ساعتها لازم تاخد وقتك انت تقراها كويس لوحدك و تحاول تجمع معلومات عن الجزء اللي هتعدل عليه او ال feature اللي هتكون مسؤول عنها. و حاول في الاول تاخد ال tickets اللى ليها علاقه ب feature محدد و صريحه. بلاش ال tickets اللي تخليك تلف علي ال project كله.
طيب خلاص لقيت ال ticket المناسبة و قريت تفاصيلها كويس و عرفت ايه الهدف اللي المفروض ال ticket تحققه نعمل ايه بعد كدا.
المرحله اللى جايه بنقول عليها ال refinement. و هنا بتبدا تفتح ال code تمسك ورقه و قلم و ترسم كروكي كدا الدنيا شغاله ازاي و تعرف انت هتعدل على ايه. مش لازم تمشي على اي standard وانت بترسم. مش لازم uml او اي حاجه مشهوره. ارسم حاجه اللي يشوفها يفهم منين بيودي علي فين.
اكيد هيكون عندك كم كبير من الأسئلة و هنا ممكن ترجع ال onboarding duddy بتاعك او تسال ال team عامة. جمع كل أسئلتك مرة واحدة و ابدا اسالهم. و في الوقت دا متتكسفش حتي لو شايف السؤال دا غبي اسال براحتك. اصلا الفتره اللي في الاول هما متوقعين انك تسأل حتى اساله بدائيه جدا. ف نصيحتي بلاش كسوف و متحسش نفسك انك غبي. اسال كل اللي نفسك فيه. اسال كتير.
خلاص جمعت كل الاسئله اللي في دماغك. ابدأ ارسم الحل بتاعك او التعديلات دي كروكي او حتي اكتب pseudo code. حاجه بس توضح انت هتعمل ايه. و بدا وريهم الحل اللي انت فكرت فيه و خد رأي زملائك فيه واسمع منهم ال feedback. متتوترش لو لقيت عندهم تعليقات كتي. عادي جدا انت لسه جديد على الـ project و اكيد هما خبرتهم في ال project دا اكبر منك.
بعدها ابدا اعمل update لل ticket بالتفاصيل دي و يا سلام لو عملت document بيشرح اللي انت هتعمله.
خلصت؟ اقعد مع حد زميلك خليه يبص بصه سريعه و يجرب الحل النهائي. ممكن برضه تطلب من الـ QA يساعدك ف انك تعمل test. بعدها ابدا افتح pull request و خد رأي الناس في ال code. وبكده نقدر نقول مبروك اول contribution
اهم نصيحة هيا انك تسال كل اللي نفسك فيه. اسال كتير و متتكسفش…
دي من اكتر الحاجات الغلط اللي ممكن تعملها. خليك دايما عارف ان نفس المشكله ممكن تتحل باكتر من طريقه و لكن الحل اللي هتختاره هيختلف بناء علي ال context و الموقف. يعني مثلا ممكن مشكله ليها علاقه بال scalability او مثلا انك عايز ت handle requests per minute اكتر تكون انت حليتها في شغلك القديم بانك زودت شويه resources. لكن الحل دا ممكن ميكونش احسن حل في شغلك الجديد. مثلا في شغلك القديم حليتو مشاكل ال database بانك زودت ال instance size لكن في شغلك الجديد دا مش هيكون احسن حل مناسب.
خلينا متفقين ان مفيش code مفيهوش مشاكل. و مفيش code مفيهوش bugs. و انت متعرفش ايه الظروف اللي اتكتب فيها ال code دا. ولا الـ deadline كان عامل ازاي. و ممكن ان دي كانت feature اصلا معموله بالشكل دا عشان proof of concept. ف كونك تنتقد code انت مكنتش عارف ظروفه ف هيا حاجه مش هتفيد ف اي حاجه. و عامه هيا عاده مش كويسه. لو شايف حاجة غلط اقترح حلول و لو الحلول دي تنفع اكيد الناس هتسمع لك.
دايما لما تلاقي حاجه غلط او حاجه مش مظبوطه او مش معموله باحسن طريقه متروحش علي طول تشتكي. ولكن فكر في اقتراحات لحلول لان الشكوى مش هتفيد بحاجة. ولو فعلا المشكله اللي انت بتشتكي منها ماثره علي كذا حد و انت لقيت ليها حلول و فعلا نجحت في حلها ف دي حاجه كبيره جدا تحسب ليك. لكن كونك انت معملتش حاجه غير انك اشتكيت دا مش حاجه كويسه لانك لسه جديد في ال team.
ببساطة الناس ممكن تنسي احنا اخدنا القرار دا ليه او امتي. دا غير انك ممكن متكونش فاهم الموضوع بتفاصيله اوي ف لما تحاول ت document القرار او المناقشه دي تكتشف ان في شوية نقاط كانت واقعة منك. انك ت document كل القرارات اللي بتاخدها دا هيساعد ان كلكوا تبقوا on the same page.
عامة اي حاجه مكتوبه بتبقي احسن عشان لو حد سألك انت ليه اخد القرار الفلاني يبقي عندك document فيه تفاصيل ممكن توريها له.
]]>خلينا نبدا الاول باننا نعرف معني كل واحده فيهم و ايه ال tools اللي هنحتاجها و ازاي نطبقها. و الاهم بقي هل انا محتاج دا في ال project/product اللي انا شغال عليه ولا لا.
في المقاله دي هحكي عن ال CI و في المقاله الجايه هحكي عن ال CD
المعني الحرفي هوا continuous integration يعني من الاخر اني افضل اضيف features او integrations او تعديلات لل code بتاعي و افضل متاكد ان ال code الجديد اللي اتضاف مضربش ال code القديم و ان ال code الجديد مضربش اي code قديم. و ان كمان ال code الجديد ماشي علي نفس ال standards و ال conventions اللي متفقين عليها
لو لقيته بيضيع وقت اكتر ما بيفيد
لو لقيت ان في ال code review في حاجات ممكن كانت تكتشف من غير تدخل انسان تاني. زي مثلا ان تلاقي في ال code review الناس بتعلق لبعض ان المفروض اسماء ال functions تبقي camelCase او انك تسب مسافه قبل ما تفتح } كل الكلام دا مش محتاح ان شخص يضيع وقته و يدقق فيه و لكن ممكن يكون في tools تكتشف دا. دا غير ان دا مش code review اصلا بس دا موضوع تاني
دي tools كل شغلها ان كل لما يحصل تغيير في ال code هتنفذ شويه اوامر انت قايلها عليها عشان تتاكد ان ال code مظبوط و جاهر انه يتعمله merge علي ال project. الاوامر دي ممكن تكون انه ي run static code analysis او ي run ال unit tests مثلا
في حالات ساعات بنحتاج ان ال CI يعمل اكتر من حاجه بترتيب معين. زي مثلا انه يعمل generate لل coverage report بس بعد ما يكون عمل run لل unit tests و عدي الخطوه دي بنجاح. و قتها بنرتب ال CI بناء علي الخطوات دي و بنقول عليه CI pipleine. او بالعربي خط انابيب. و اتسمي كدا عشان لو تخيلت شكل الانابيبت هتلاقيها سلسله من الانابيب ملحومه في بعض و لو حصل مشكله في اي واحده فيهم بتاثر علي الخط كله.
مثال علي CI pipline ل Golang project
Static code analysis/linting
Run unit/integration/end-to-end tests
Generate coverage report
علي فكرا انت لو مش شغال في team كبير و مش محتاج كل الدوشه و ال tools دي ممكن تعمل run لكل الكلام اللي فوق دا as a git pre-commit hook
يعني مثلا تلم كل ال commands اللي انت عايزها دي في bash file و هتعمل pre-commit hook ينفذ ال bash file دا قبل كل commit علي جهازك بس كدا و اعتبر ان عندك CI ياسيدي
لو عايز تتعامل مع ال pre-commit hooks بسهوله في nodejs tool اسمها husky
مراجع تانيه ممكن تبص عليها
]]>لو في اي معلومه مش مظبوطه او مش دقيقه ممكن ت create pull request and contribute here <3 https://github.com/AlaaAttya/my-blog
خلينا الاول نتكلم بمثال يقرب الموضوع: تخيل انك عايز تبعت جواب من برلين في المانيا ل الاسكندريه في مصر. عشان نعمل كدا بترمي الجواب في صندوق البوسطه. و بعدين بيروح الجواب لمكتب البريد التابع للمنطقه اللي انت ساكن فيها. مكتب البريد دا عنده زي جدول فيه كل الطرق الممكنه عشان يوصل الجواب مابين برلين لالمانيا. طيب علي اي اساس هيقرر انه يختار الطريق. يبقي علي حسب قواعد هوا حاططها. يعني مثلا لو بريد سريع هيختار اسرع طريق. لو بريد بتكلفه شحن قليله هيختار الطرق اللي متكلفهوش كتير.
مثلا الجواب دا هيتنقل ما بين مكاتب بريد الاول جوا المانيا و دا بنقول عليه internal routing يعني مثلا يطلع من مكتب بريد حي charlottenburg في برلين ل مكتب بريد حي Mitte في برلين و بعدين مكتب بريد تاني في مدينه تانيه مثلا ميونخ (كل دا احنا لسه جوا المانيا ف دا اسمه internal routing) و كل مكتب بريد عنده routing table بيقوله مين اقرب و احسن مكتب ممكن يروحله بعدها عايزين نعرف مين اقرب دوله لمصر عشان نديها الجواب دا ودا اللي بنقول عليه external routing و لما يوصل مصر هيحصله برضه internal routing لحد ما يوصل للي هيستلم الجواب في اسكندريه.
الخلاصه من الموضوع ان كل مكتب بيبقي عنده routing table و بناء علي شويه rules بيعرف مين المكتب اللي جاي.
خلينا نعمل اسقاطات technical شويه بناء علي القصه اللي فاتت خلينا نقول علي مجموعه مكاتب بريد المانيا انها بتسمي autonomous system. نفس الكلام بيسمي علي مجموعه مكاتب بريد مصر. مجموعه مكاتب المانيا تعرف توصل الجوابات جوا المانيا بس متعرفش جوابات جوا مصر. ف هيا عندها routing table بيقولها ان النمسا ممكن توصل الجوابات لمصر و اليونان تعرف توصل الجوابات لمصر و تركيا تعرف برضه توصل لمصر. طيب المانيا هتختار انهو طريق فيهم؟ هتختار عن طريق algorithm اسمه BGP او ما يسمي بال Boarder Gateway Protocol و هوا المسؤال انه يختار احسن route بناء علي شويه configuration موجوده في كل محطه و ف للتبسيط هنقول ان AS1 عايزه تكلم AS2. عشان تعمل كدا دا بيسمي BGP peering. كل AS بيبقي عندها routes ل range معين من ال IPs بيقولو عليها “IP address space.”
عشان كل autonomous system يوصل لل autonomous system اللي بعده بيعمل حاجه اسمها BGP peering
خلينا بقي نعمل اسقاط للكلام دا علي الانترنت. تخيل انك بتفتح موقع اسمه hamada.com و انت في برلين و السيرفرات بتاعه الموقع دا في مصر. ازاي دا هيحصل؟
انت مثلا في برلين موصل نت من فودافون. ال request بتاعك هيروح علي vodafone و هيا هتشوف هل هيا عندها اي server بال IP دا؟ الاجابه هتكوت لا. هتروح تسال ال BGP مين احسن route؟ هيقولها دا في شركه اسمها حماده انترنت مثلا هيا دي احسن route. عشان يسال حماده نت عن ال routing table بتاعها و يعمل exchange لل data دي هيعمل حاجه اسمها BGP peering و اي config غلط مش هيعرف يوصل ل حماده نت دي او مثلا تخيل ان حماده نت بعتته ل شركه مثلا اسمها ام احمد نت و ام احمد نت دي اصلا متعرفش اي حاجه عن ال IP اللي انت عايز تروحله. او حتي متعرفش مين من ال autonomous systems عنده ال routes بتاعته. كدا ال request بتاعك عمره ما هيوصل بسبب ان حماده نت بعتك ل route غلط و كمان قال لكل ال autonomous systems ان اي حد في range ال IPs دا وديه علي “ام احمد نت”
تكمله لموضوع ال BGP routes ال BGP routes دي ممكن تكون internal BGP routes او external BGP routes
في المثال اللي فات كنا بنتلكم علي external BGP routes ال internal BGP routes بتبقي جوا ال autonomous system نفسه. لانه مثلا حد زي google او facebook عنده data centres كتير هوا خلاص ال request وصل لل DNS بتاع facebook بس مش عارف ال data centre اللي موجود فيه ال machine اللي ال IP بتاعها كذا. ف بيبقي في routers كل router بيبقي عنده routing table بيقوله لو ال machine دي عنده ولا يروح ل router تاني. اي config غلط في اي router من دول هيادي ان ال request مش عارف يروح فين او ان router منهم يبعتك ل router غلط بسبب ان ال routes table اصلا غلط و هوا نفسه عمل publish لل routes دي لكذا router تاني و كدا routers كتير اتلطت بسبب config في router غلط. او مثلا واحد من ال routers دول بقي unavailable معني كدا ان ال route القديم دا مبقاش ينفع نستخدمه تاني و محتاجين نعمل update لل routing tables من تاني و محصلش update لسبب ما. ف برضه ال request مش عارف يوصل
لو حصل اي misconfiguration ممكن يحصل مشكلتين. ان ال routing table اللي موجود في كل router يكون فيه invalid routes و ممكن اصلا ال routes مش عارفين يعملو communicate او exchange information مع بعض بسبب شويه invalid BGP roles الاسواء بقي ان كل BGP تبدا تعمل exchange ل invalid routes و بكدا كل ال routing tables تبقي corrupted
دي رسمه ممكن توضح الموضوع شويه
ودا ازاي بيحصل ال BGP peering ما بين ال ISPs
طيب ليه الموضوع واخد وقت كتير. لان محدش عارف مين من ال routers عنده bad config و كمان حد كان كاتب ان عشان تعمل reconfigure ل router انت محتاج physical access عشان تعرف توصله و بسبب ال pandemic و كرونا مش كل الناس شغاله onsite في ناس كتير شغاله remote ف الموضوع واخد وقت
في قصه ظريفه حصلت في 2004 ان في شركه ISP (خلينا نقول انها حاجه زي WE او فودافون او غيرهم يعني) عملت publish ل BGP routes غلط و routes دي كان مكتوب فيها انها اسرع routes لاي entities علي ال internet. وبدا كل entity تعمل exchange لنفس ال bad BGP routes و بقت ال bad routes دي سبب في ان مواقع كتير كانت unreachable
في حادثه تانيه برضه ان في ٢٠١٨ في attacker عملو publish ل BGP routes تخلي اي حد بيحاول يوصل ل amazon انه يروح لل servers بتاعه ال attackers دول و سرقو $100,000
شويه مصادر قريتها عشان اجمع الكلام دا:
Writing a nice readable clean code has no manual which you can follow. It’s just best practices and guidelines and here are some points I’ve faced while my career path which may help.
Functions and procedures:
Function names should be descriptive as you can understand what it’s doing even by reading its name. Function name should not belong and it’s preferred to start by a verb. For example, using the following function is a bad practice “check_valid_membership_data_for_user” you may use such name “validate_membership“.
If you’re working with classes do not use the class name within the names of your functions (function for sure it belongs to its class so no need to replicate such info).
For example, if you have a “User” class creating a function with the following name is a bad experience “get_user_payments” but the best name for such function is “get_payments” as you’ll use it as follows within your code “$user->get_payments“.
Camel-case or underscored! yeah, it’s one of the annoying experiences to have camel-case underscored mixed code. If you’re working within a team you’ve to agree on which type of naming conventions you need to work with. I’ve faced such a case lately while working with Peter. He suggested using underscores while naming our method and variables. At the first, I saw that it’s useless to do so (as I love the came-cased methods). After some point in time, I was reading a class in which we’ve applied such convention and then compared it with and old version of code. I smiled and said yup you were right Peter(he won the land this time :D).
The naming convention for variables and properties:
Well, who doesn’t use a variable in his code, the answer is no one but who is writing non-readable or even understandable variable names, then the answer is everyone. When you ask a developer why you did so he’ll surely say “Man I got stuck with a new release and had a very long backlog how come to care about a useless variable name. That may consume a lot of time” (actually I was one of those fools who do so). BTW it’s not useless to care about variable names and yup it deserves to invest a minute to think about a descriptive name. I’ve read some old articles that agreed if you’re working as an individual or a freelance developer it’s useless to care about naming conventions. I can see that it’s wrong. If you look back to see the old code you’ve written 2 months ago you’ll never remember why the hell you’ve written such a variable name. So it deserves taking a minute to think about it.
Managing dependencies:
One of the most things that annoy me is working with lots of dependencies within a project without having a dependency manager that handles such annoying tasks of updating and getting the chain of dependencies. For example: using bootstrap within your frontend code. If you’ve downloaded bootstrap manually you’ll end up downloading jquery too. And the later bootstrap versions cares about the minimum version of bootstrap. And here we go, we’ve to get the proper jquery version. That was a simple example. If you’re working with a complicated dependency that has a long chain of other dependencies this will be very annoying to care about each version. Using dependency managers like bower (in frontend) and composer (for backend) will help you to have free nightmares sleep.
Loops and control structures:
loops, if statements and loops and even more if statements, ugf I cannot read such code, who’s the asshole who wrote that shittttttt!. Lots of us faced such problem when reading not well-written code. Using loops and control structures is a mixed blessing. And to avoid being an asshole. You have to care not to have lots and lots of nested loops and control flow items within your code. Suppose having such code
foreach(............){
if(..................){
switch(......){
case 1:
foreach(.........){
}
break;
…..
}
}
}
This is a bad experience to have such a code. Having 3 nested indentations is enough to have a readable code. So please do not write that shitty eye-bleeding code that has lots and lots of nested blocks.
The previous notes are not rules that have to be followed when writing code, they’re just best practices I’ve come up with. You build up better rules for better code. Just set your own rules and follow them.
]]>You may do some processing before sending an email for user. generating statistics, pdfs or any other thing. example for emails that may take a long time processing is the weekly digest mail. And you can’t image how this could be a big load with a big data.
idea:
you may have a db table as a datastore for your mail queue. Table fields may be as following: “mail_to”, “mail_content”, “type”, “status”, “failure_info”. whenever you want to send a new mail just insert that table.
you start creating a command (job) that will keep track with the not sent mails (getting rows with status=0). After you get the mail you can start processing this mail (generating statistics, pdfs or whatever). Then try to send the mail. If it’s done set “status” to sent if not set the status to failed and update the “failure_info” attribute.
For the sake of good architecture of your code, you may use the processor design pattern to manage processing for each mail type.
here’s a simple link that can demonstrate the processor pattern http://www.openloop.com/softwareEngineering/patterns/designPattern/dPattern_CommandProcessor.htm
i’ve drew a simple chart that may simplify the whole idea.
Hope i’ve helped you with this blog. If you have any questions just drop me a comment or ding me if you have my social account or mail.
Thanks 🙂
]]>He was right about that and it’s also a good behavior and makes It easy for the developer to eliminate bugs. For example: you’re trying to persist a user object in database which has no ’email’ property set(which is required by your class responsible for db operations). This will throw an exception says that ’email’ property should not be null and then you should have an if statement to check if the required properties are not nulls (which is a really big hassle for an object with 20 property for example).
For me as a web developer (who writes in php) exception handling saves me a lot of time spent of dangling if else to check every single case. Using exception handling makes it easy as putting the code which I suspect in a try block such as follows:
try {
$fbdata = $facebook->get($fbToken, $fbId);<br />
} catch (\FacebookApiException $e) {<br />
throw new Exception\AuthenticationFailedException('User exists but Facebook token invalid');<br />
}
As an architect you should start designing classes to serve your custom exceptions.
As a Symfony2 lover I’ll show you an example how to do it in Symfony by extending the existing exception classes:
<?php
namespace Smartizer\EventxBundle\Service\Exception;</p>
class AuthenticationFailedException extends LogicException
{
}
as you may notice it’s pretty easy to get started and saves you alot of time spend on checking and dangling if else.
hope you’ve liked my post and start defining your custom exceptions.
]]>First i’ve a quote which i believe in “Javascript will rule the world!”. Despite being a PHP developer, last months i got stuck loving JS.
Actually last couple of months i was just started using node. As my friend @ma7med_amr was working with me on our graduation project he has used node for managing web based audio/video calls. After that i felt in love with node and also angular. 5 months later i joined eventtus and i knew that they are using mongo as their DB engine. After using mongo i can say that nodeJS, angular and mongo are the best combo for creating full stack js web app.
I can remember also a conversation between me and @shreef about full stack js apps he told me “i’ve looked at lots of github repos and i can say that all those are mess!”. Actually he was right about this. For now, creating a full stack js app is not a good idea. IT’S REALLY A BIG HASSLE to do so. There’s no reliable framework which you can rely on.
here’s i’ll show you in brief how to build up a login/registeration system using node and mongoDB. we’ll do this with some node modules
1- mongoos (for handling db queries).
2- express (for handling http server and routing).
3- ejs (for handling html rendering).
4- connect-flash (for passing flash messages between pages)
5- passport-local (for managing local authentication).
you can find the full project code at https://github.com/AlaaAttya/node-login-registeration
as you may see, lots and lots of packages for just creating a login/registeration system. it’s a new technology that needs more adaption.
it need more and more contribution from the opensource community to create full stacked js framework to make developing such apps more easier and interesting.
If you are a symfony developer you may have noticed that you’ll not be able to use sql Date functions (date, year, month, day) with doctrine. You’ll need to write an SQL query to do so and fall in the problem of mapping the results to entity. Actually i hate doing this.
While Googling i’ve found a doctrine extension which does that heavy task smoothly
https://github.com/beberlei/DoctrineExtensions
which you can easily install via composer.json just add ‘”beberlei/DoctrineExtensions”: “dev-master’ to the required dependencies.
to use it you can just you the following snippet
public function getTodaysUsers($date) {
$emConfig = $this->getEntityManager()->getConfiguration();
$emConfig->addCustomDatetimeFunction(‘YEAR’, ‘DoctrineExtensions\Query\Mysql\Year’);
$emConfig->addCustomDatetimeFunction(‘MONTH’, ‘DoctrineExtensions\Query\Mysql\Month’);
$emConfig->addCustomDatetimeFunction(‘DAY’, ‘DoctrineExtensions\Query\Mysql\Day’);
$qb = $this->createQueryBuilder(‘e’)
->select(‘e’)
->where("DAY(e.registeredAt) = :day")
->andwhere("MONTH(e.registeredAt) = :month")
->andwhere("YEAR(e.registeredAt) = :year");
$qb->setParameter(‘year’, $date->format(‘Y’))
->setParameter(‘month’, $date->format(‘m’))
->setParameter(‘day’, $date->format(‘d’));
return $qb->getQuery()->getResult();
}
It’s an example for finding the today’s registered users. Only you’ll have to place this method to your Entity’s repository and here you are ready to go
Hope you’ve enjoyed,
Thanks 🙂
]]>