The charm of functional programming

Posted on Leave a comment

While reading modern JavaScript code, you might have come across such things as Array.prototype.map(), Array.prototype.filter(), pure functions, higher order functions, the spread operator, etc. Basically, all the things that React and Redux made us write willingly or unwillingly. I am not going to spend the next 2-3 hrs going into finer details about FP. Instead, I am going to link you to 2 great articles I found on this topic.

Functional Programming (or FP) is a programming paradigm, a collection of guiding principles to write code in a particular style. Any developer who strongly adheres to this way of writing code will tell you that it eventually leads to code that is more readable, maintainable, testable and bug-free. In saying that, they would probably be right. Creating in React and GraphQL has made me a big fan of the declarative programming style. FP promotes declarative over imperative. Again, don’t worry too much about all the jargon. Once you’ve read the following articles, you’ll have a good understanding yourself.

FP is just one of multiple paradigm that JavaScript supports (other ones being event-driven, object-oriented and prototype-based; last two being forms of imperative paradigm). There are several other languages that support FP, most notably Haskell which supports ONLY the functional style. The currying technique is an essential ingredient in creating functional code, and is supported in a lot of modern languages including JavaScript.

Interestingly, there was a (famous?) guy named Haskell Curry who is the namesake of the language and the technique described above. Haskell. Currying. Get it?

Enough said!

Here are two excellent articles that introduce functional programming superbly. Read the first one first, after which all code examples in the second article will be immediately understood (really, Avi Aryan has done a great job with those examples).

Master the JavaScript Interview: What is Functional Programming?

Intro to Functional Programming: JavaScript Paradigms | Toptal

Stop Blindly Following W3Schools!

Posted on Leave a comment

I started out learning to create websites by reverse engineering web pages that I found and liked online. The way I got started with CSS is an interesting story. I started developing static websites at a young age. I produced mostly ugly pages by myself and a wee-bit jazzy ones using something like Macromedia DreamWeaver. I hadn’t yet discovered the mystical world of stylesheets.

In the summer of 2006, it had only been a few days since France’s heart-wrenching loss in the final of FIFA football World Cup when I was absentmindedly browsing some WC pictures that I had painstakingly downloaded over my super-slow Internet connection. That delightful little folder of my favorite images was inside SUSE Linux. Whether it was version 9 or 10, I cannot remember.

As I was a KDE junkie, I naturally had the folder open in Konqueror, KDE’s default web and file browser. While scrolling through the list and mindlessly clicking this button and that menu, I stumbled across an option to generate a gallery out of images. I curiously clicked this option and, *boom*, there it was — a gallery of all photos in the folder in the form of a web page. What a beautiful web page it was. The page had supporting files, full-sized images, thumbnails, and an intriguing file with .css extension.

Clicking the CSS file opened it in my text editor. “Interesting, a .css file is only a text file,” I said to myself. Most of the contents in that file didn’t make sense to me, but there were these other pieces that seemed quite obvious such as background-color, color and font-family properties. In my reverse engineering fashion, I made a few changes here and there and refreshed the web page in browser. *Boom*, some of my changes were actually reflected. This seemingly innocuous incident created a minor explosion of curiosity in my mind.

Out came a new tab in Firefox, hastily typed were the letters “google.com” in address bar, and with a thud was hammered the Enter button on keyboard. A big search text box appeared in the next few seconds. What did I type in it? CSS, of course silly. To where did the very first search result point? W3Schools, of course silly. And so began my journey of learning CSS from the most popular web development learning resource on planet. I regret it to this day. My regretful mistake didn’t end at CSS, it was augmented by my learning HTML, advanced HTML and even JavaScript from W3Schools.

Out came a new tab in Firefox, hastily typed were the letters “google.com” in address bar, and with a thud was hammered the Enter button on keyboard.

Fast-forwarding to present times, just a couple of days ago I was listening to episode #7 (Online Resources for JavaScript Developers) of JavaScript Jabber, a popular podcast series for the lovers of the beautiful language. It was in it where a couple of web experts echoed my feelings about W3Schools. Just to be clear, when I was learning from the “great” W3Schools, I didn’t have any such feelings. In fact, I deemed every word and example on the website a work of experts, which they probably were. However, my feelings changed drastically when I “grew up” and started to discover most of my coding style that was derived from W3Schools was composed of a collection of anti-patterns.

In order to appeal to a wider section of audience and to make things simple, examples listed on W3Schools tutorials dumbed down so much that best practices were sacrificed. Take for instance their use of event handler attributes, such as onclick and onfocus, all the while blatantly ignoring the principle of separation of concerns. This was not even mentioned as a cautionary note to the initiated. Tricks and lies such as this put me back in my career by at least a couple of years.

<button onclick="var hello='world'; alert(hello);">Click me</button>

For years W3Schools piggybacked on the “W3” name to maintain its popularity. Meanwhile, other respected developer resources such as Mozilla Developer Network (MDN) took a diametrically opposite approach of going into deep discussions about each aspect of building blocks of the web. That looked scary initially, but with time your eyes and mind adjusted. I recently finished Part I and II of an exhaustive JavaScript resource called JavaScript.info. It also takes a profound approach similar to MDN’s. In fact, it encourages one to read W3C’s original specifications on various matters. Yes, it’s time consuming but hugely rewarding when applying your learning into practice.

I would like to conclude this rather loooong blog post by saying this:

Do not follow W3Schools or any such simplified online resource without questions. Be extra careful, use common sense, and do compare your learning from other (more detailed) sources. Do not let the details scare you away. Embrace detaily things. But don’t follow even the detaily things blindly.

Dev Blabber Ep 1: Building an Open-Core Startup

Posted on Leave a comment

The first-ever episode of a brand new podcast series called Dev Blabber. It’s an initiative that I came up with as part of the awesome Digital Futurists community, where a bunch of geeks, entrepreneurs and seasoned executives discuss technology and software like crazy.

There was a discussion last week in the Coding channel—one of many channels within the DF community, and the one that I lead—regarding the topic of our next knowledge-sharing session. 4 topics were proposed, ranging from React performance optimization to cybersecurity. But this one, about building open-core startups, rose as the clear winner. While deliberating the format of this session, I thought of making it in the form of a podcast. The idea was instantly liked by most in my channel, and thus was born Dev Blabber.

I hope you enjoy this episode, which being the first one is very loosely structured and borderline chaotic. At least it’s true to its ‘blabber’ name.

P.S. More details about DF and how to join are coming soon. Watch out!

Someone should fix how GitHub counts contributions

Posted on Leave a comment
A snapshot of my GitHub contributions

I have been doing a lot of commits lately. Sadly, none of my dozens of commits are included in my total contribution count on GitHub. Why? Because all those commits were to a forked repository. It’s 2019, and I think it’s plain stupid.

I love GitHub, but if there was one thing I’d like to fix about GitHub it would be this. It’s understandable why GitHub made this rule back in the day when they were introducing the contributions map/tracker thingy. Perhaps it was a decent guard against simply copying someone else’s work and adding a few minor commits here and there just to boost your “score”.

But it’s 2019; it’s modern times. Just think about it. One could be forking from a base/boilerplate repository that contains non-substantial code to build something substantial on top of it. This is exactly how I have been using forks lately. As part of following along the Flutter bootcamp-style course, I created a bunch of forks from the course creator’s boilerplates and transformed them into proper apps. I deserve to be recognized for that! It’s as simple as that.

Here’s what GitHub’s documentation has to say about how contributions are counted:

Commits made in a fork will not count toward your contributions. To make them count, you must do one of the following:

1. Open a pull request to have your changes merged into the parent repository.
2. To detach the fork and turn it into a standalone repository on GitHub, contact GitHub Support or GitHub Premium Support. If the fork has forks of its own, let support know if the forks should move with your repository into a new network or remain in the current network. For more information, see “About forks.”

Why are my contributions not showing up on my profile?

Those two options are not plausible every time, since:

  • Opening a pull request in the parent repository just does not make sense when the upstream is intentionally boilerplate. Asking its author to merge your commits into it would be like asking them to publicly publish the solution to their puzzle.
  • Contact GitHub support? Really? Who has the time and patience to do that when you’re working with dozens of forks?

GitHub, if you are listening at all, PLEASE FIX THIS!

Hero animations in Flutter are dead simple

Posted on Leave a comment

When I was learning React Native, I was sort of super-impressed by its emphasis on animations. We all know how critical animations are in creating experiences that users actually like. RN has a profound Animated API and loads of examples on creating custom animations. There’s only one problem: adding beyond-simple animations is tricky and a lot of work.

I remember coming across this neat and detailed Medium article by Jiří Otáhal on creating Hero animations, becoming immediately excited, writing it down in my ‘urgent’ TODO list, and then never ever actually following it up. It was considerable amount of work, and I just couldn’t put myself together for the task.

Today when I was learning about animations in Flutter (AppBrewery course), I was friggingly relieved to know how easy it is to achieve the same here. See the screenshot below. Get what I mean?

Hero animations in Flutter.
These are transition animations on a shared object (widget) when navigating from one screen to another.

Of course, the RN animation tutorial that I linked earlier tries to achieve a more profound goal. But, clearly, in Flutter we have a better starting point.

Happy coding. Talk to you in the next one 🤘.