Thursday, October 25, 2018

2 months into Flutter

So I've been learning Flutter trying to get in deep. I'm been using Flutter for make an Android app and so far, I'm largely impressed but I have met a few small annoyances.

The good. 

1. Hot reload is the killer feature. I won't be a happy mobile developer if have to wait for the damn AVD to restart to see my changes. 

2. Android Studio support. I'll have to disclose that I'm also a Pycharm user so you could say this is a biased assessment. I've tried Flutter with VSCode, it works but having to manage the Android stuff like AVDs manually is a pain.

3. Good looking apps fast. Once you figure out how the layout system works along with the theming system, you'll have a blast creating your app UI also tweaking it.

4. Aside from good looking app, you also have nice responsive apps. Although I have to admit, the app I built didn't have that many moving parts.

The bad.

1. Dart. The language is like Java and JavaScript had a bastard child. Being a Python dev for the last decade, the curly braces just irks me. Also, it has a lot of optional syntax rules that bug me. 

2. The learning curve. Flutter isn't particularly easy especially for those without CS or programming training or experience. For example, how it handles databases and API calls is via Futures; Learning how to use Futures isn't trivial especially if you want a maintainable code base.

3. Missing key IDE features. The feature I'm taking about is the "build" feature. If you are using Android Studio, you'll still be forced to use the command line to build your final release APK. You can't do this from the IDE. May be the future.

I got nothing if you're an IOS developer.

Conclusion:

Flutter works although it has some of rough edges. I'd like to think these rough edges are teething problems. I expect a couple of these rougher edges be polished away before the end of year. I'm liking Flutter so far and I think I'm in good company - Alibaba used Flutter for their Xianyu app.

Friday, August 17, 2018

Cleaning up your global NPM packages

Sooner or later when you're working with any web app, you'll have to deal with nodejs because frontend requirements will force you to do so. And sooner or later, you'll have a mess of npm packages in your global space. You'll want to clean it up but when you issue the command npm list you get a whole mess of packages with their dependencies.

However there's a useful trick you can do that will make npm only list the top level packages without their dependencies.


$ npm list -g --depth 0


Here's a sample result:

The trick is the --depth 0 parameter. It suppresses the listing of a package's dependencies.

We can now tame our unruly global npm packages.

Ha!

Wednesday, July 25, 2018

Pyenv folder (.venv) with Pipenv

Pipenv, by default will use your virtualenv folder location if you set that environment variable - which probably be a .virtualenv or .env folder in your home directory.

But sometimes you would like to have the virtualenv folder within the project folder - ie. project/.venv No sweat, pipenv supports this workflow if set the PIPENV_VENV_IN_PROJECT environment variable.

For Macs: $ export PIPENV_VENV_IN_PROJECT=1

For Windows: > set PIPENV_VENV_IN_PROJECT=1

Do note that in Windows, you can also use setx.

Then we can run either a: pipenv install or pipenv --three to get started.