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!
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!
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?
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.
Flutter 1.9 is out. As one may guess from this post’s title, my favorite changes are:
Structured error messages (enabled via VS Code or Android Studio settings)
Structured error message support was proposed 8 months ago! I find Flutter’s current approach to displaying error/exception messages are pretty useful as they are. Adding more structure certainly doesn’t hurt. When I started programming more than a decade ago, I had always imagined a future where a developer would not need to leave their IDE to find help in fixing their errors. Now that it’s finally here, I wonder what took it so long 🤔. I think both React and Flutter have done a wonderful job here.
I am now officially in love with Flutter. What started as a crush has turned into something palpable. For the past 2 weeks, I have been heavily invested in learning Flutter from App Brewery’s bootcamp-style course. If there’s one takeaway from the course, it is this: Flutter+Dart is a lethal combination. I have now come to truly appreciate the ‘promised’ language for frontend and the frontend itself.
I must confess, though. I did not hold the same feelings for Flutter in the beginning. At a couple of meetups, I have called Flutter all sorts of blasphemous things — difficult to learn, highly inconsistent, and a confused approach — all without closely working with it. I, however, assure you that Flutter is none of the above. On the contrary:
its composition-over-inheritance approach makes it easy for beginners,
its Widget-oriented design makes it consistent, and
The App Brewery course I mentioned before has been an eye-opener. The course itself is pretty long and exhaustive, but rewarding. Since it’s geared toward absolute beginner programmers, I was able to go through it at 1.5x playback speed and even skipped a few sections. I am currently at 64%, hoping to complete it by the next weekend.
During this time, I customized my VS Code quite a bit to my liking (this post’s featured image), so much so that creating Flutter apps in Code is a far more pleasant experience as compared to officially recommended Android Studio. This, of course, is made possible by the awesome Flutter team who does not want to tie developers to Google’s ecosystem.
If you are curious about the source code of the app seen in this post’s featured image, here’s the GitHub link. It’s an app called BMI Calculator that I created as part of the course. Go ahead and explore my commit history to see how easy Flutter makes creating beautiful-looking mobile apps.