Azmi Radi Azmi

🚨 قبل ما تضيف أي Library أو SDK جديد في مشروعك، خد نفس عميق ووقف شوية ✋

كتير مننا بيجري يـ integrate أي third-party solution علطول من غير ما يبص على حالته أو تأثيره على المدى الطويل، والنتيجة؟ صداع ومشاكل بعدين.
أنا عن نفسي بقيت دايمًا أراجع 3 حاجات أساسية:

✅ أول حاجة: Library Status
آخر تحديث كان امتى؟ (لو من 5 سنين ما حدش لمسه يبقى 🚩 كبير)
في ناس كتير بتستخدمه وبتـ test ولا مهجور؟
الـ GitHub issues والـ discussions بتقول إيه؟
والـ documentation شكله مرتب ولا لا؟

✅ تاني حاجة: SDK Pricing Model
متفترضش إن كل الـ features free.
في SDKs بتحاسبك على كل function call.
مرة وقعت في فخ إن فيه function عملتلي double cost 💸 من غير ما أخد بالي.
اقرأ الـ docs كويس عشان متتفاجئش آخر الشهر.

✅ تالت حاجة: Clean Code
امسح الـ unused dependencies والـ code اللي ملوش لازمة.
بلاش تسيب comments تقول "هنحتاجه في المستقبل" 🤦‍♂️.
المستقبل ده لما ييجي الـ versions والـ styling هيكونوا اتغيروا أصلاً.
لو في حاجة مهمة، اكتبها في documentation برا الكود.

⚡ صدقني… الدقايق اللي هتراجع فيهم قبل ما تستخدم حاجة، هتوفرلك شهور وجع دماغ بعدين.

Send a message to learn more

🚀 5 Ways to Stand Out as a Developer

Becoming a great developer isn’t just about writing good code — it’s about how you work, communicate, and grow.

This quick carousel breaks down 5 simple, practical ways to stand out on any tech team:

👉 1. Ask “Why?”
Understand the reason behind the work — not just how to do it.
👉 2. Help Your Team
Support teammates, improve workflows, and look beyond your own tasks.
👉 3. Be the Go-To Person
Pick one area and master it. Become the person others turn to for help.
👉 4. Lead Without a Title
Own shared tasks, track progress, and communicate. Leadership is action, not position.
👉 5. Practice Kaizen
Continuously improve. Reflect after every task and aim to grow with each project.
📌 Save this. Apply it. Share it with someone who wants to grow.

Because we’re not just coders—we're engineers, mentors, problem solvers, and stewards of the future.
In a world where delivery is often rushed and shortcuts are common, we need to remind ourselves of what real software engineering stands for.
Here’s what we value 👇

⚙️ 1. Easy to Maintain > Quick Fixes
We write code that’s easy to change and understand — not just something that works today.

🧪 2. Tested Code > Assumptions
We trust our code because we test it, not because we “think” it works.

🤝 3. Teamwork > Solo Heroes
The best software comes from people who work well together — not one person doing it all.

📐 4. Good Design > Messy Code
We plan and structure our code to avoid problems later.

🧑‍💻 5. Doing What’s Right > Just Doing What We’re Told
We think about how our code affects people, privacy, and the world.

📚 6. Always Learning > Thinking We Know It All
Tech changes fast. We keep learning and improving.

🚀 7. Real Value > Fancy Features
We focus on solving real problems, not just writing more code.

🛡️ 8. Strong and Safe > Full of Features
We care about security and stability more than having every feature.

📄 9. Clear Docs > Hidden Knowledge
We explain what we’re building so others can follow and help.

🧭 10. Integrity > Pressure
We speak up when something’s wrong, even if deadlines are tight.

💡 Software engineering is both a technical and human discipline. Let’s practice it with care, curiosity, and responsibility.
🔁 Feel free to share this with your team, or adapt it to your company values.

hashtag hashtag hashtag hashtag hashtag

سمعت قبل كده عن البرمجه الدفاعيه والهجوميه؟
Defensive vs Offensive Programming
بص يا صديقي، فيه طريقتين للتعامل مع الـ bugs أو الـ unexpected behavior في الكود بتاعك:
🛡️ Defensive Programming (البرمجه الدفاعيه)
يعني تبقى دايمًا حريص وتعمل check على كل حاجة حتى لو المفروض ما يحصلش حاجة غلط.
يعني مفيش حاجه اسمها "أنا متأكد إن دي عمرها ما هتكون null"… خصوصًا لو الحاجة دي nullable.
مثال: لو عندك var name: String?، مينفعش تقول "أنا واثق إنها مش null".
لازم تعمل null check قبل ما تستخدمها.
✅ الهدف؟ إن الـ app يفضل شغال حتى لو حصل حاجة unexpected.
⚔️ Offensive Programming (البرمجه الهجوميه)
دي العكس شوية… هنا بتقول: "لو حصلت حاجة unexpected → crash فورًا!"
يعني لو name مش المفروض يبقى null، تكتب:
require(name != null)
لو طلع فعلاً null؟ 💥 Exception هيتضرب علشان الـ developer اللي عمل الغلط يعرف ويصلحه.
🧘‍♂️ طيب نختار أنهي؟
ببساطة: الإتنين!
استخدم defensive لما تقدر تتعامل مع الخطأ بطريقة آمنة.
استخدم offensive لما تكون واثق إن الغلط ده مش لازم يعدي أبداً.
اللي اتنين مكملين لبعض… زي Yin & Yang ✨

خد بالك من ال platform type

كلنا عارفين إن كوتلن فيها نوعين أساسيين: ☑️ Nullable
☑️ Non-nullable

لكن في نوع ثالث ناس كتير مش واخدة بالها منه، اسمه: ➡️ Platform Type
وشكله بيكون كده: Type!

🤔 إيه هو الـ Platform Type؟

لو بتشتغل بـ Kotlin وبتستخدم كود قديم مكتوب بـ Java
أو مكتبة جافا في كود كوتلن، فهتلاقي المتغيرات اللي جايه من جافا مش متحدد هل هي nullable ولا لأ.

كوتلن بتحب تبقى واضحة وأمينة بالنسبة للـ null،
لكن جافا مش بتديها أي معلومة،
فكوتلن بتقولك:

"أنا مش هفترض حاجة… إنت اللي هتقرر!" 😅

📌 مثال عملي:

val name = JavaApi.getName()

تفتكر name هنا نوعه إيه؟
String ولا String? ؟

في الحقيقة هو لا ده ولا ده…
ده بيكون:
➡️ String! ← ده اسمه Platform Type

يعني ممكن تتعامل معاه كأنه String أو String?،
بس لو خمنت غلط؟
💥 هيجيلك NullPointerException وانت مش واخد بالك!

💡 إزاي تتعامل مع الـ Platform Type؟

✅ لو انت كاتب كود جافا: استخدم
أو علشان تساعد كوتلن تفهم.

✅ في كوتلن:
تعامل مع المتغيرات دي بحذر،
واستخدم ?., ?:, أو !! حسب الحالة.

📏💻 Measure Twice, Cut Once

in Software
Before you write a single line of code:

✅ Understand the requirements
✅ Validate assumptions
✅ Review edge cases
✅ Think through the logic

Because fixing bugs in production costs more than thinking twice before committing.

🛠️ Good engineering is as much about prevention as it is about problem-solving.

شباب الاندرويد بإذن الله الفتره الجاية بنجهز سيشن محترمه مع صديق شاطر جدا هنتكلم فيها عن Android & Kotlin هنحاول بقدر الامكان نركز على ال Android best practice السيشن هتكون recorded مش live لو حد حابب نجاوب عل استفسار معين ياريت يبعتلي خاص او يكتبه في ال comments

يا هلا بال Kotlin Developers تعالى يا صديقي أقولك على تريكة جامدة هتفرق معاك لو بتستخدم Kotlin Coroutines

تخيل ياصديقي عندك Coroutine شغال، وفيه أكتر من طريقة تتحكم بيها في توقيت تشغيله، وكل طريقة ليها فايدة خاصة جدًا. وده اللي هنتكلم عليها الـ CoroutineStart
يعني إيه بقى؟ وازاي اعمل كده؟ تعالوا نشوف سوا
ممكن نحدد الـ CoroutineStart لنوع من دول

1- DEFAULT:
الكوروتين هيبدأ شغله فورًا أول ما تستدعيه! مفيش تأخير، مفيش انتظار. ده الوضع العادي اللي كلنا عارفينه.
2- LAZY:
الكوروتين مش هيشتغل غير لما تطلب منه بنفسك. يعني لو مش مستعجل وعايز تتحكم إمتى الكوروتين يتشغل، دي الطريقة المناسبة. ليك زي الـ lazy في Kotlin، مش بيشتغل غير لما تنادي عليه او ممكن تقوله start() زي ما هتشوف في المثال اللي في الصور، أو ممكن تشغل async وتخليه ينتظر لحد ما تقوله await()!
3- ATOMIC:
تخيل إن الكوروتين بدأ شغله ومفيش حاجة تقدر توقّفه قبل ما يوصل لأول نقطة إيقاف (أول suspension point). يعني مضمون إنه هينفذ أول جزء منه مهما حصل. لو محتاج تأكيد إن الكوروتين يبدأ ويكمل لحد نقطة معينة، دي التريكة.
4- UNDISPATCHED:
دي تريكة لو عايز الكوروتين يبدأ على نفس الثريد اللي انت شغال عليه، ولما يوصل لأول نقطة إيقاف، يغير الثريد لو احتاج. دي طريقة ذكية لتقليل استهلاك الموارد وتوزيع الشغل بشكل أنيق.

طيب ليه الموضوع ده مهم؟
لأنك دلوقتي تقدر تتحكم في إمتى الكوروتين يشتغل وإزاي يتصرف في ظروف مختلفة. سواء كنت عايز تؤجل شغله شوية، أو تتأكد إنه يشتغل لحد نقطة معينة من غير مشاكل، أو تقلل استهلاك الموارد. CoroutineStart هي مفتاح التحكم ده!
متنساش تبص علي الصور اللي في البوست هتساعدك اكتر في انك تفهم الـ CoroutineStart
دمتم متفوقين