DEV Community: Thibault

TIL: Returning to your previous Git branch

Thibault — Thu, 10 Apr 2025 13:59:47 +0000

If you're a developer, you've probably experienced the same frustration I have; constantly switching between branches can become tedious, especially when you're deep into work on branch X and suddenly need to make a quick fix on branches Y or Z.

The usual workflow involves stashing or committing your current changes, checking out another branch, making your fixes, and then navigating back to your original branch to resume work.

Branch names can be particularly cumbersome to type depending on your team's conventions. At my company, branch names follow a specific format that includes the type (feature, bugfix, hotfix), sprint version, ticket number, and a descriptive text. That's a lot to type repeatedly!

While some terminal plugins offer branch name autocomplete functionality, I recently discovered something even faster and simpler.

The Command

git checkout -

That's it! Just a hyphen.

This immediately returns you to your previously checked out branch, saving countless keystrokes throughout your day.

If you're reading this and have other Git productivity tips, please share them in the comments.

Disabled: true vs Readonly: true in Rails

Thibault — Tue, 08 Aug 2023 21:00:35 +0000

What did i want to accomplish:

I had a rails form where i wanted one of the required fields to auto fill with some values.

<% if @issue.safe_attribute? 'subject' %>
<p> <%= f.text_field :subject, value: @issue.project.name, :size => 80, :maxlength => 255, :required => true %></p>
<% end %>

The goal being, a user editing the form should not be able to edit this specific field.

If you're like me, your first thought would be to add disabled: true to the code. This disabled the field but it was triggering validation errors saying the field can't be blank.

After reading about the disabled option, i realized disabled elements are not submitted with the form(thus triggering validation) while readonly as its name says it, cannot be modified by a user interaction.

More info here

How did i accomplish it:
Replace disabled: true with readonly: true

Result:

<% if @issue.safe_attribute? 'subject' %>
<p> <%= f.text_field :subject, value: @issue.project.name, readonly: true, :size => 80, :maxlength => 255, :required => true %></p>
<% end %>

Moral of the story: Should've taken HTML course seriously😉

My interview with Degica(Komoju) Japan: An unfortunate end to a promising opportunity

Thibault — Tue, 02 May 2023 04:46:10 +0000

Degica is a leading provider of Japanese digital commerce solutions. One of their product is Komoju, a payment gateway platform that enables businesses to accept payments from customers in Japan and around the world.

As a ruby developer with an interest in fintech, I was excited about the opportunity to interview with Degica. I went through several interview stages and was offered a position with the company, but unfortunately, my experience did not end as I had hoped.

The Story:

I went through all interview stages successfully the first being a call with some of the team members to discuss about my side projects, why i'm interested in Degica, etc..

Second interview was more technical and was given access to a private repo where i had to fix failing tests which was followed with a discussion about other technical questions in a real case scenario. Ex: We have this bug in production, why do you think it's happening? how would you go about fixing it?, etc...

Third interview was with the management team(CTO and COO) where we discussed salaries, expectations, starting date among other things. Everything was going well so far.

I received an offer, negotiated my salary and came to a mutual agreement of my salary. I also asked if i could start in August(2022) and take July as a month off to which they agreed to.

I resigned to my previous job, travelled back to japan(since i couldn’t before, because of covid restrictions) and met with some of the team members over lunch. I told them about my plan to leave japan for a while and that i would start working with Degica remotely for the first months. Everything still good.

A few weeks later, i received an email from Degica asking about my starting date, my expectation for remote work, etc.. we jumped on a call where they explained to me that onboarding have to be done in JST time zone and that they would require me to work JST timezone which was never mentioned during the interview process since it clearly said that they work Full remote and hires everywhere in the world.

We ended the call with them apologizing that it should have been cleared from the beginning and that they would extend my starting date and told me to think about it and let them know 2 weeks before my return to Japan.

A few weeks later(25th July) i send them an email informing them that i'll be traveling back to japan so we can arrange onboarding. All crickets until 2nd of August when i received an email from someone in the administration department saying that my offer has been rescinded because i do not fit Degica culture for 2 reasons:

My resume had a Japanese address(which was my address btw) but this was an issue since i was not "residing" there at the time of application
I delayed to reply to their email (mind you we had agreed to let them know 2 weeks ahead of my return to japan as per the last correspondence i had with them)

And that became the end of what i thought was going to be an interesting journey in my career.

I believe the reasons they gave shouldn't be enough to cancel a contract but as we say in Kinyarwanda; "Ntawe uburana n'umuhamba" so we move 🏎💨

Conclusion

Even though my experience with Degica was disappointing, i believe it's a good company where one can strive especially if you are a ruby engineer.

And if you're an engineer working in Japan, i would advise you to quit your current job right after receiving the actual contract. not just the offer 🦾

In the meantime, if your company is into fintech/payment or developer tools and are looking for a passionate and skilled engineer, I'm open to new opportunities and would love to hear from you.

It sucks to be an intermediate engineer

Thibault — Tue, 02 May 2023 04:09:27 +0000

One of the goal i set this year(2019) was to change my career from agency to in-house dev. Reason being that, as an engineer, there's a certain level of seniority i don't see myself reaching if i keep working in this kind of environment.

Working in an agency means you get to work on various projects, explore different stacks, etc... but once you're done with a project, it's usually up to the customer to take care of the rest.

There are pros and cons of this depending on what you want and where you are in your dev life but it has reached a point where i'm sure that the agency life isn't taking me where i want to be in my career.

The journey to becoming a Senior Engineer

A Senior dev can mean anything depending on who you ask but i like to think of it as someone who's able to think ahead of time and notice possible flaws of a solution and decide accordingly

As I embark on my journey towards becoming a Senior Engineer, I realize that it's not just about the technical skills. It's also about developing a certain mindset and approach to problem-solving.

One of the things that I have found to be crucial in this journey is mentorship. It's important to find someone who has more experience and can guide you in your career. Unfortunately, in some environments, there might not be any senior or principal engineers to learn from. In that case, it's important to seek out mentorship from other sources such as online communities or attending conferences and meetups.

Another important aspect is to focus on the long-term goals rather than just the immediate task at hand. As a Senior Engineer, one must have a broader perspective and think beyond the current project. It's important to understand the business goals and align them with the technical solutions being implemented.

Communication is also crucial. As a Senior Engineer, you must be able to communicate effectively with different stakeholders including non-technical people. This means being able to explain technical concepts in simple terms that everyone can understand.

In conclusion, becoming a senior engineer can be a challenging journey, especially when working in an environment with no senior or principal engineers. However, with persistence, dedication, and a willingness to learn and take on new challenges, you can still achieve your goal.

Seeking mentorship, attending conferences and meetups, participating in online forums, and continuously expanding your knowledge and skills can all be valuable steps towards becoming a senior engineer.

That being said, I would highly recommend Kasper's Discord community for mid/intermediate ruby/rails engineer ;)

Tracking Rails changed attributes

Thibault — Fri, 01 May 2020 21:33:23 +0000

On today's "What did i want to achieve/how i achieved it", I had to fix this weird bug where one form field was triggering changes in the DB regardless of any user interaction.

Take your typical rails form and add a map component(we deal a lot with location data at Georepublic).

The bug was that, when a user edits one record's attribute and save, this would also update the location attributes(Latitude & Longitude) automatically by 1/1000000000 which isn't meaningful TBH but the issue was emailing subscribed users on such minimal changes!

PS: The purpose of this post is not fixing that value-change bug, but detecting and ignoring those small changes

Meet ActiveModel::Dirty

Rails comes with ActiveModel::Dirty module that, as it's described,

Provides a way to track changes in your object in the same way as Active Record does.

This allows you to perform various operations whenever your attributes changes.

Going back to my bug, i had to make sure the location changes were "valid enough" to trigger our notification services.

Step 1: Add callback

Since our notification service is called on every update, it makes sense to check for these changes "before updating"

before_update: ignore_small_changes

Step 2: Track changes

As mentioned earlier, this was a location attribute saved as a geometry point in the db (cfr Rgeo) which basically mean that it's a collection of points a.k.a [140.1250590699026,35.6097256061325]

Using Rails ActiveModel::Dirty you can detect changes on any attribute using the following ways:

class User < ApplicationRecord
end

user = User.first
user.update(address: "new address")
user.address_changed? #returns true if user address has changed

user.address_change # returns an array of [oldvalue, newvalue] or [nil] if there's no change

Step 3: Ignoring small changes

Since we are dealing with a location point i.e [lat,lng] calling address_change on this would return a collection of this kind [[lat, lng],[lat, lng]]

Thus, comparing changes(and ignoring small ones) in these two collections become a lot easier with Ruby#Zip

def ignore_small_changes
  unless address_change[0].nil?
    old_value = address_change[0].coordinates
    new_value = address_change[1].coordinates
#Ignore changes if the difference is minimal
    self.address = address_change[0] if new_value.zip(old_value).map { |a, b| (a-b).abs }.map {|x| x < 0.00000001}.all?
  end
end

Conclusion

Although this was used to fix a bug in my case, you can always leverage these methods by using it as callbacks to performing different actions only when certain attributes have changed.

Persisting flutter SnackBar until user interacts with it

Thibault — Fri, 24 Apr 2020 13:28:12 +0000

On today's "What did i want to achieve/how i achieved it", i wanted to
Show a SnackBar until a user interacts with it.

How i achieved it

Flutter's SnackBar as described on its official documentation; is

A lightweight message with an optional action which briefly displays at the bottom of the screen.

It comes with a duration property that allows you to set how long you want the SnackBar to be visible. Values can be seconds, minutes, hours, days, etc...

Point is, There's no way to tell when the user will interact with it. Leaving me with the only option of setting a longer duration(read days) and hoping the user will interact with it within that time. Only then, it can disappear from the list of widgets.

Key points being:

Setting a long duration
```
duration: Duration(days: 1)
```
Hiding the SnackBar when there's an interaction
```
Scaffold.of(context).hideCurrentSnackBar();
```

Below is the code for the SnackBar widget. I'm using a ListTile widget but anything with a callback would do:

SnackBar sb = SnackBar(
  duration: Duration(days: 1),
  content: ListTile(
    onTap: () {
      Scaffold.of(context).hideCurrentSnackBar();
    },
    title: Text(
      "This is a title",
      style: TextStyle(
          fontSize: 24.0,
          fontWeight: FontWeight.bold),
    ),
    subtitle: Text(
        "and i'm a subtitle"),
    trailing: Icon(Icons.check),
  );
);
_scaffoldKey.currentState.showSnackBar(sb);