More than 2 years ago, I created a lightweight point of sale system (POS) for our restaurant in Jalandhar called SkewerSpot (SS). I wrote the thing in under a week (cowboy coding, yodlee yodlee youdoo) in Ionic/Angular. Essentially, it’s a collection of hybrid mobile apps that allows a restaurant to manage orders in real-time via Firebase. The 3 apps in this collection are:
SS Menu — to take orders
SS Orders — to manage orders
SS Stats — to view sales data
Nothing too complicated. The thing has been running quite reliably since 2.5 years. So why the rewrite?
Recently, Dad asked me to change a few things in SS Menu. When I got to working on the changes, I realized that my Ionic tooling had somehow become broken. I just couldn’t create new builds. I left it as is and informed Dad I didn’t have sufficient time to fix things around. But he insisted. So much that I finally decided to just rewrite the entire thing in a more modern mobile SDK — Flutter.
I donned my cowboy hat again and sat down to create the menu app from scratch using a skill I had just recently acquired. I think I was able to spit out a functional version of the app in 4-5 non-contiguous days. Creating in Flutter is such a blissful experience. I loved every bit of it.
Flutter makes it infinitely easy to create 100% custom interfaces inspired by designs at Dribbble. You are never crippled by the difficulty of customizing platform’s underlying UI controls. You are always in the driver’s seat.
— Me, after having created several Flutter apps based on designs at Dribbble
Unlike the last time, I created the app from day 1 with open-sourcing in mind. I also made sure that my git history was readable enough to help others starting in the world of Flutter learn quickly from my development experience.
But due to a lack of time, I had to make certain trade-offs: the code lacks automated tests, i18n, l10n and accessibility options. There’s also no iOS version as of now. What a bummer!
Check out the code and more details about the app on GitHub:
In this second edition of our popular NCR meetup, we will learn to build elegant, professional and modern user interfaces and experiences. Do not miss out on the opportunity to hear from and interact with distinguished developers. Learn from real-world experiences of the speakers.
Unlike the last time’s conference-style schedule, we had this time only 2 sessions:
Building Enterprise-ready Web Applications With OpenUI5 and Fiori by Nitish Mehta
Creating Beautiful Cross-Platform Apps With Flutter by Anurag Bhandari (me)
A relatively short schedule allowed us to go deeper into our respective topics and entertain more questions from the audience. Talking about the audience, we had a decently diverse group of enthusiasts and learners from undergrads to junior devs to project managers. They were all just lovely. We even had a foreign guest: a nice guy from South Korea 🇰🇷. That means we have international reach now, haha.
As usual, Nitish’s session was well-prepared and touched most aspects of this topic, OpenUI5. I personally learned a lot since (surprisingly) I had never heard of this UI framework before. Too much Bootstrap hypnotism?
As for the Flutter session, it was my first-ever attempt at teaching and evangelizing it in public. I loved doing that as much as I loved coding my showcase app. Oh yeah, it was a mostly hands-on session where we spun up a beautiful Health App in just over 60 mins (including learning Flutter and Dart stuff on the way). The full source code and tutorial of the app is in my GitHub repository.
During my time spent on App Brewery’s Flutter course, I created not one, not two, but 12 (twelve) apps. That’s a bunch! All apps are simple, nothing complicated, except the last 2-3 ones which have slightly complex widget trees. Creating in Flutter is fun, I have said that before. It’s fast and enjoyable. I will continue this journey by creating at least a couple of real-world apps.
Here’s a list of all my Flutter experiments so far:
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.”
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!