Being productive while driving

The Problem

I always found travelling a waste of time, especially driving. You just can’t avoid doing it.

One year ago, my daily driving time (home -> work -> home) summed up to 1 hour or so. I hated that. I was continuously dreaming how cool it would be if I were to work from home – I would save a wasted hour.

The Solution

Until a colleague told me that he is listening audiobooks on his way to work/home. How did I never think of that?
Immediately after that I subscribed to Audible and got my first book.

I started listening to audiobooks every morning & evening. Daily trips were no longer a pain.
Even more, I couldn’t wait to have hours-long trips so I could listen to longer audiobooks.

It also prevented me speeding when my brain thought that gets me faster to destination :).

How do you make your driving experience more productive?

How I managed to wake up in the morning

I usually get into the office at 10:30 which is the latest I can get by the company policy.
There’s also a standup meeting at that time, so it’s not a choice to arrive later + stay late.

So why I wake up in the morning? To get to the office. If that wouldn’t be the case, I would probably wake up at 11:00-12:00.

I always wanted to be a morning person. There wouldn’t be that hurry when you wake up at 10:00, then make it to the daily call at 10:30.
I tried waking up early so I could drink my coffee, read some news, maybe play some video games? But after 1 or 2 days, I was like what’s the point, I can do these in the evening, sleeping feels better.

Until recently when I read this book: The Miracle Morning (by Hal Elrod).
The author provides some techniques that will help you achieve waking up for yourself instead waking up for some job you would get to as late as possible. We need discipline and time for ourselves to focus on long term goals. We don’t have to sleep 12 hours, we only need to sleep as much as we tell ourselves.

Afterwards, I started waking up at 8:00 and do my Miracle Morning before going to the office. Results (like increased positivity, energy) started showing up after few days of practicing.
I don’t even need alarm anymore as my body clock already got used to waking up around 8:00.

Have a good read! ʘ‿ʘ

Moving from PHP with Laravel to NodeJS with Express

One of my long term applications I’m working on is Financial.
I started it with a composition of:

  • DB: MySQL
  • Backend: PHP with Laravel
  • UI: Desktop interface with ExtJS

Early this year I added to the stack a Mobile UI created with React and Material-UI.

Now I feel it was not the right choice to bring PHP in this game as it involves too much of a ceremony and complexity to do development with it.

I believed that doing NodeJS was premature at that time and didn’t offer enough tools to develop an application like this easily, but things have changed in the meantime.

Here are the architectural changes I had to do during this migration:

  1. Routing with Express (before: Laravel Routing)
  2. Database interaction with Sequelize (before: Laravel Eloquent)
  3. Session with connect-session-sequelize and express-session (before: Laravel Session)
  4. Authentication with passport and passport-local (before: Laravel Authentication)
  5. Password hashing with bcrypt-nodejs (before: PHP password_hash)
  6. CSRF Token with csurf (before: Laravel CSRF)
  7. Config management with config (before: Laravel Config)
  8. md5 hashing with md5 (before: PHP md5)
  9. XML parsing with xml2js (before: PHP simplexml_load_file)
  10. Input validation with validator (before: Laravel Validation)
  11. Platform detection with UAParser.js (before: MobileDetect)
  12. Shell view generation with Handlebars.js (before: Laravel Blade)

Pull Request for reference: GitHub

Self-made vs library-based solutions

I want to tell you a story of how you can make a mistake in software development by thinking small.

Common case

Sometimes, we don’t see the problems in the bigger picture because we are blinded by the current issues we have.
And we are driven to solve them ASAP.

Often, developers have the tendency to become defensive and make excuses when they know they’ve implemented something in the wrong way.

How do these excuses sound?

  • We had a deadline
  • There were too many modifications implicated, therefore a price too big to pay
  • I don’t need all the bloat that the library or framework is giving me
  • … and so on

My story

I’ve started working on a JavaScript project with no architecture.
No architecture means: <script> tag for each module introduced by hand, no framework, no nothing.

A bunch of new features were requested by the client. They were like 5 new whole complex pages that we needed to implement.

Considering that now we had 5 more pages on the web application, some dependency management needed to be in place.
So a team mate introduced an experimental dependency management (how..?) that at least kept us clear of the necessity of adding <script> tags in the HTML code. This was the beginning of the suffering.

Pages were implemented and released. The client was happy.

As soon as the next features were required for implementation, the issues with this whole approach started to show up.
We had crashes from time to time, no consistency in the architecture, etc.

The next big mistake? Let’s solve these all by ourselves.
So we’ve implemented a wrapper over this dependency management library in order to simplify things.

Soon, all the modules were to be using the new in-house developed THING.
Why not picking up a library? See the excuses above.

Next?

  1. maintain the THING
  2. fix the THING
  3. go to step 1

At some point, the THING became stable and required less adjustments.
But when we wanted to add some new behaviors or scenarios to it, it would bring us back to the 3 steps mentioned earlier.

New addition to the team: a more experienced colleague came and asked a lot of questions trying to understand why are we using the THING.
He told me multiple concerns that I couldn’t accept at the moment because it affected my pride as a developer and as the creator of the THING.

However, I knew deep inside that he was right, but I needed some time to process this.
After all, I agreed he has some points.
What did I do? Instead of getting rid of it, I started adjusting the THING per his suggestions. Funny, right? 😀

To be more clear, as much as I wished, I couldn’t just replace it with a library because it was too late, the code base was huge and one-time modifications like these could be “catastrophic” for the project.

I’ve worked hard to change the API signatures to match the ones from the library and finally I just switched the THING with the library.

Everyone was happy in the end because this really worked.
It was, however, a much bigger price to pay comparing to what we would have been paid if we were to choose the library from the beginning.

Conclusions

  • Always ask someone more experienced than you when you want to make a decision that is over your capabilities or responsibilities.
    We all have to learn, so you better not overestimate yourself, because it’s easier to learn by asking than learning by mistake.
  • Pay the price at first even if it feels too much.
    Delaying the “payment” results into adding “interest rates” and could result into doing much more effort in the end.
  • Making up excuses is natural. If you ever feel you want to make up an excuse for something, you may want to ask yourself: Would it be better if I actually considered what the other person is saying?
  • Think bigger. Scalability and extensibility are two main factors that you want to keep an eye on when making a technical decision.

Removing underscore.js bloat from your ES2015 project

I’ve been using Underscore.js for quite some time. It’s a very fast, lightweight library that provides a lot of utility functions.

However, at this moment, with all the newest JavaScript features in place, we have lesser reasons to use 3rd parties like Underscore.js for “daily activities” .

We all know that the latest ECMA spec is not implemented in all the browsers, but that’s why we have Babel. However, I’m optimistic that some day browsers will increase their update cycles so much that we’ll get the latest features in no time.

To get back where we were, I’ve decided to clean up the Underscore.js bloat because there were too many occurrences of _.each, _.map, _.filter, etc. which are really a useless complexity added from my point of view.

There were two big questions I’ve asked myself:

  1. It’s obvious that _.each/_.map/_.filter should and will be replaced by Array.prototype methods. But why not look for other replacements as well?
    As a lazy (efficient) man, I’ve browsed to see if someone already did a list for these and what do you know! This article has a really nice list of replacements that I’ve used to refactor the code by replacing with native solutions.
  2. Now I’ve replaced the bloat with some vanilla JavaScript code, but I cannot remove Underscore.js yet. Why? I still use lots of methods (like _.sortBy) that would require lot of duplicated code or making my own version of Underscore.js-like methods.
    To sum up: I don’t want to remove Underscore.js, but I also don’t want any other people to use again _.each, so what do I do?
    I’ve decided to write some linting code that would fail a pull request containing code I don’t want to allow anymore.
    As I already have ESLint at hand, I’ll just have a new rule that lints this.
    I browsed several repos for plugins and I found nothing related to Underscore.js. But I discovered a similar ESLint plugin for jQuery.
    That was my inspiration and I came up with this:

I really think that ESLint is definitely a big player in a strategy of controlling your project code’s evolution.

Hope this helps anybody out there! 🙂

Intro

Finally, I’ve convinced myself to start writing again.

I took down my previous blog which was mostly composed from my thoughts of life as a teenager (now you see why I took it down :D).

I can’t tell what this blog will be about in several months or years, but considering my daily activities, I’ll probably write technical stuff.

See you soon.