“Fat models, skinny controllers.” That was the mantra for years. But if you’ve ever worked on a Rails app that’s more than two years old, you know where that leads: a User.rb file that’s 2,000 lines long and handles everything from authentication to generating PDF invoices. The Problem with Fat Models When a model knows too much, it becomes impossible to test in isolation. You want to test a simple validation, but you end up triggering five callbacks that send emails and ping Slack hooks. ...

We’ve all been there. You’re working on a feature, and you need to parse some weirdly formatted date or handle a complex file upload. Your first instinct? npm install or bundle add. It feels like winning. Someone else already solved this problem! Why should I reinvent the wheel? The “Free” Wheel But here’s the thing: every dependency you add is a liability. It’s code you didn’t write, but code you now own. You own its bugs, its security vulnerabilities, and its breaking changes when it decides to “improve” its API. ...

Around 2 years ago, I started a new management gig. it wasn’t the first, but it was the first with a relatively large team. One of the most basic things I needed to do as a manager was to bind the team to its mission, and in simple terms: get them super motivated to do their day to day tasks. I’m a strong preacher for freedom, it gives people a sense of ownership. ...

We all wanna get from 0 to 1 (with many trailing zeros), the sooner the better. So, what’s the problem? You build something and you’re brave enough to put it out there, now what? Now you start the endless feedback loop cycle, you look at the data, analytics, user recordings, product inputs, and decide what’s the next thing that’ll make your product better then ever, it’s an iterative process that never ends. The faster you iterate, the faster you’ll get to your target. ...

If you ever used any MVC framework, I’m sure you asked yourself more than once, ‘Where should I put this piece of code?’ (If not that’s also fine). Well, there is no one answer for all problems but, I asked it a lot. In this post, I’m gonna focus about the view part. View objects, AKA view models, but any other name is fine (presenter view object, view controller mediator, whatever). ...

So I found out it’s not so documented, hopefully google will index this. I have a page on my system that shows a google geo chart (same as this) When clicking on a country on the map lot’s of interesting things happens. And I wanted to implement a ui automation test to cover this use case. It’s not so easy cause even if you find the right svg path object and try clicking on it you get some interception errors. So I googled a bit without any luck, but the geo chart documents came to the rescue. ...

Recently I discovered Danger, an amazing tool you should check out no matter what. I can write a ton of use cases that serves me on my day to day work, but let’s start with one which I like a lot. Do you know how much of your code is covered by tests? Do you keep track on how your code coverage changes over time ? I didn’t till I installed a simple danger plugin called ‘danger-simplecov_json’, It’s a ruby gem it’s configuration is super easy (check this link to the gem), Once you configure Danger on your CI or locally, you can see after each build (spec run or whatever you use) the percentage of code coverage. ...

If you’re building forms with rails, whether you’re using a gem for it or working with pure rails forms, you should know this. Rails uses form builder to allow you to call all the standard label/input/select methods, the exact class name is ActionView::Helpers::FormBuilder When calling ‘form_for’ you get a fresh instance of this FormBuilder which allows you to define your form elements. Lets say you wanna add another reusable form element, for example a form section with title that uses your own custom style/classes. ...

Sometimes we want to show the user an alert when somethings wrong or we just need to give some extra info, For example; Ask the user if he is sure he wanna leave the app. This can be achieved with the following code (runs inside activity): AlertDialog.Builder(this) .setMessage("Are you sure you want to exit?") .setCancelable(false) .setPositiveButton("Yes", object:DialogInterface.OnClickListener() { fun onClick(dialog:DialogInterface, id:Int) { this@YourActivity.finish() } }) .setNegativeButton("No", null) .show() This works fine, buy there is one annoying issue, If user clicks home button while dialog displayed, and go back to the app, the dialog will still be there. Now your user experience is seeing a question about getting out of the app while he just went in. ...

When working with MutableLiveData you can update the observable value in 2 ways: setValue postValue Both will update the live data value as expected as long as your code is running from the main thread. If you need to update a value from other thread you can use the postValue which is thread safe, and will make sure to notify observers on main thread. This is all nice, but be aware! ...