Hey gang! I hope you are all doing well 🙌 I am slowly getting back to spending more and more time with the community and providing more value to you all. Starting next week, I am thinking of making 1 more weekly call for code reviews. The idea is that you can get a code review during that call. We can discuss things that are good and things that can be improved. We'll look at different ways to improve those things as well. ❌ We will NOT judge, shame, or blame people during this call. ✅ We will ONLY talk about the code, and make suggestions. Let me know what you think about this idea and if you want it in the comments below 👇

Hi guys, I hope everyone is very ok. I'm studying a good content about TDD and of course it made by Jov, this link, in the video number 4 https://www.youtube.com/watch?v=Ya3ZhE6tHNg&list=PLqew6vQ7CzHLDK-PshtzTCw3pSQlMLGoC&index=5 he catch my atentio How he make create test to UI with the Robot pattern, made my head explode from the applied DSL. Ok DSL, omg what does "DSL" mean in Kotlin ? I want to share you this blog that explain different concept tha you need know before to into or dive DSL path . I hope you enjoy it Kotlin DSL | Introduction. Introduction to Domain-Specific… | by Glenn Sandoval | Kotlin and Kotlin for Android | Medium

Do you want to have 50+ profile views a week on LinkedIn, but zero DMs... Or, 10 views a week, but getting 3+ DMs in your inbox? Engagement is great. But, views ain't gonna get you a job (read pay your bills). It's time for a change. And, you know that. === A week from now, I'm starting with a group of 10 people to teach them how to turn their LinkedIn profile into a job-attracting asset. I will give them training, templates, and CV optimization tips, so they can get 3+ ideal job offers in their inbox in as little as 15-30 days... I've got 2 spots left, and I expect to fill them out this week. Send me a DM with the word "JOB" and I'll send you over the details. (it's not free)

It's not related to physical code/structure One of the biggest issues I've encountered in software development is the misconception that "unit tests" must be tightly coupled to the physical code, such as a class or function. Instead, a unit defines a behavior crucial for users or the business. The structure should be free to change over time. The focus of testing, then, should be on the public API of the unit, ensuring it exhibits the expected observable behavior. Additionally, it is much easier to create a coherent unit of code by starting from the tests and letting the design emerge as a demand of them. TDD helps a lot there. What do you consider a unit to be? How do you approach testing it?

This is a community where we talk mostly about Android, and software craftsmanship. The main goal is to learn Android and make your development work highly profitable. Let's do this together! Step 1: Introduce yourself HERE using this Copy/Paste template: What's your nickname? Where are you from? What do you want immediate help with? Step 2: Check out the introduction section --- Best practices in this community: • Try to level up quickly by commenting and posting your insights in the community. • Hit 'Like' 👍 on every helpful post or comment you see to help others level up. • Be cool. • If you ever get stuck, feel overwhelmed, or are not sure what 'next step' to take, just ask the community. --- Group Rules: 1) Respect and be nice to others 2) No Spamming the Community Feed