Saturday, November 12, 2016

Flashing NodeMCU

Howdy!

This is going to be a quick one. When flashing NodeMCU with new firmware you need to remember that esptool.py requires some params for it to work correctly.

esptool.py --port /dev/ttyUSB0 write_flash -fm dio -fs 32m -ff 40m \
  0x000000 nodemcu-integer.bin \
  0x3fc000 esp_init_data_default.bin

Let me know if it works for you! Oh and btw - you can build the firmware online - I'm loving it!

Happy flashing!

Friday, November 4, 2016

Vue js - finally a framework I feel comfortable using

The story so far...

I have switched to frontend development about 10 months ago. I met a lot new friends, interesting ideas and got back to a place where you don't really need to travel half way around the world to react on someone pressing a button. That was great up until I was acquainted with JavaScript framework that I was supposed to work with. Ember.JS. I mean the idea behind it is great, don't get me wrong, but it is the tiny little details that make it a nightmare to use. Features like mixins, mustache syntax with helpers, views in God knows which location, lots of decisions pre-made for the developer (like we're not smart enough to make them ourselves, doh!) and the sick Broccoli souse on top of it - I hate Ember with a passion!

And so naturally I started looking for an alternative. First at AngularJS, then Angular2 - none of those felt like a good choice at the time. At some point I found a presentation where a scared to death person on the stage was criticizing MVC on the front end saying that's actually the wrong thing to do. That was a presentation of ReactJS. Funny enough a long long time ago I have had a conversation with one of my colleges about putting MVC to use in Delphi applications. It ended quite rapidly with me saying You're insane! and I have a strong feeling that it took 8 years for the industry to catch up with my statement.

But ReactJS felt a bit odd. And I don't mean the JSX syntax - I actually love it! But the whole shebang with Redux, functional components, state-full components - it was just a lot to take in. On top of that you needed to acquaint yourself with Webpack which at least fueled my interest in React for quite some time because of the hot module reloading. I even gave a talk about Webpack on a conference - that's how strong I feel it's a good thing

Let there be light (at the end of a tunnel)

And than, one evening, out of the blue someone posted an article on LinkedIn about vue.js. I never heard that name before, I gave it a quick read, got interested but not nearly enough to continue reading that night. Still some itch remained after I read that it was basically a simple framework. I can do simple - I actually prefer that over complex stuff - that is why I hate both Ember and JSF. A couple of days later I came back to it, read the whole user's guide in one evening and basically couldn't believe how obvious it was. I don't mean just simple (vue.js concepts are quite sophisticated at times) but just obvious. It takes all that's best from all the previous frameworks and does the same but in the right way.

Since then I have started a major project in vue.js, scaffolded with vue-cli, developed in Atom, with Java/Spring backend and I basically loved everything about it. The shorthand syntax for assigning event handlers with the @ syntax is just so fricken better than having to have 2 methods one for hooking up those events and one for unhooking them. The shorthand syntax for binding fields to views - awesome! The fact that you can have one file per component (not HAVE-TO but CAN) is such a relief from navigating millions of files in different locations in Ember. Using just properties and not custom-made this.get and this.set methods makes the code just so much more readable. But still - it's not the biggest win from using vue.js. It's how the framework structures and enforces things that makes it completely out of this world by comparison to other frameworks

A short tale of data and props

One of the biggest fuckups in all other frameworks (and in Ember in particular) is the fact that you create the API of your component when you use it. This basically means that there is no single point where you actually can do it. Not that it should bother you when you create the next "Hello, world!" but when it comes to a big project with 30 developers in it, having no definition of an API for a components and no enforcement of defining it turns on productivity after short few weeks.

Short personal note: I have seen a presentation from a very nice girl from the Polimer project at Google where she stated that if you're going to design a new component's API make it work like a button - not like the input.

vue.js actually makes you define the API or you can't use it! It even warns you that props should actually be read-only. You get a warning in the console when you try to assign a value to it!. How cool and thoughtful is that?!

Carry on my wayward son!

I think vue.js is the first of great many frameworks I came across that actually captures what developers need to have to do their job in a professional and maintainable fashion. Back in the days there was ExtJS which has fallen into the MVC trap as well (don't know the current state of things with that one though) but otherwise none of the currently popular frameworks feel like they are good fit for the job. So if you can - try vue.js out! And if your experience is not as mine - share it in comments! I'd like to know why and if that will impact me as well.


Have fun!

Thursday, October 6, 2016

Speeding up NPM

NPM is slow. I mean it is really, really slow when downloading packages. Partially because it makes a ton of requests to remote servers. That can be made faster!

There are 2 options that you'll find useful:

They both create a local cache that npm is later on interact with instead of the remote repository.

npm_lazy

This one is really easy to setup and use. Just do
npm install -g npm_lazy
npm_lazy
and use npm with the local registry like so:
npm --registry http://localhost:8080 install

Nexus

This is a bit more complex. Nexus can be started as a stand-alone app quite easily but I would recommend using Docker as it is a far easier experience. So to start Nexus you type:
docker run -d -p 8081:8081 --name nexus sonatype/nexus
Then navigate to http://localhost:8081, login as admin/admin123 and create an npm-proxy. Select "Repositories" from the list on the left hand side, then from the "Add..." drop down at the top select "Add proxy repository", fill in as follows:
  • Repository ID - npm-registry-proxy
  • Repository Name = NPM Registry Proxy
  • Provider - npm
  • Remote Storage Location - https://registry.npmjs.org
and click on "Create repository".

Use it as follows:

npm --registry http://localhost:8081/content/repositories/npm-registry-proxy install

What's the gain?

Depending on the project you'll see a 30-50 percent speed boost when downloading packages. For the example project that I used here are the stats:
No proxy npm_lazy Nexus
1m43s 1m22s 57s

Have fun!

Wednesday, October 5, 2016

Guarding Ember's computed properties

Sometimes you hunt a bug that just won't show. It just literally won't allow itself to be found. Recently I've had one of those cases. This time it was just unimaginable what has actually happened. Someone, possibly by mistake, has overridden an Ember.ComputedProperty thus breaking the chain of updates. On top of that the app did updates to the model using websockets changing other properties of that model. This resulted in very strange flickering of values in an edit field. Very hard to diagnose.

After the bug was fixed I started looking at possible ways to guard it in the future and possibly to find other places where the same happens. There are 2 cases where this might happend:

  • using this.set('property', 'value');
  • using Handlebars template

One possible solution would be to reopen the Ember.Object class and to override the Ember.Object.set method. Unfortunately it only guards you from explicit calls to this.set(...) and all the overrides from Handlebars template remain silent.

But there is hope!

There is another class, Ember.ComputedProperty that is actually used as the tool to get and set computed properties. It also features a set method that can be monkey-patched to do our check:

(function() {
  var orgSet = Ember.ComputedProperty.prototype.set;

  Ember.ComputedProperty.prototype.set = function(obj, key) {
    if (obj[key] && obj[key]._getter && !obj[key]._setter) {
      console.error("Overriding computed property " +
        key + " on " + obj._debugContainerKey);
    }
    return orgSet.apply(this, arguments);
  };
})();

In this way if you override the computed property in a handlebars template or in the code you'll know about it. I only wish this would be part of the core framework. It would shave about 10 mandays of my project...

Here is an example project with the fix applied.

Have fun!

Edit on October 6th, 2016

I have been made aware of an Ember addon by Stefan Penner that addresses the same issue called ember-improved-cp. Although the idea of not using private API of the Ember.ComputedProperty is nice using that plugin is invasive and means using addon-provided macros instead of those that are provided straight from the framework which adds to the already high complexity of Ember-based projects. If you have a small enough project with few developers and you can afford that inconvenience you should probably go with the addon. If you need a plug-play-unplug solution you're going to get where you need to be with the monkey-patched version of Ember.ComputedProperty.prototype.set much faster.

Wednesday, June 29, 2016

Getting started with React and Redux

This is going to be a quick post as I have already created the whole thing elsewhere.

https://github.com/padcom/react-example-02

React/Redux/Mocha/Webpack example project is ready! Check it out on GitHub! It has all the bells and whistles one would need to get started with a brand new project so if you're like me - go ahead!

Happy coding!

Wednesday, June 22, 2016

Running tests with Mocha - ES6 style

So you have an ES6 code base and you'd like to test it using Mocha? Let's do it!

npm install --save-dev mocha babel-register babel-preset-es2015
echo '{ "presets": [ "es2015" ] }' > .babelrc
mocha --compilers js:babel-register *.test.js

Easy, right?

Let's go through it line by line. In the first line we're installing mocha, the testing framework, babel-register which will enable babel transpiler and babel-preset-es2015 which is required for the es6-to-es5 transpilation.

Then in the second line we're creating a .babelrc file that will tell Babel how to transpile our code.

In the last line we're configuring Mocha to run our tests using Babel as the compiler for files with js extensions. It'll look for all files ending with .test.js and treat them as tests.

Happy testing!

Monday, June 13, 2016

Teaching Promises to take '5'

Sometimes it is beneficial to execute an action in the Promise chain with delay. A good example would be flashing fields after they have been updated as a result of an Ajax call by writing something like:

Teaching the Promise class to delay execution is very simple: you add a delay method to Promise.prototype that returns a new Promise that waits using setTimeout and then resolves with the arguments that have been passed to the call to then. Here's how it looks:

Neat, right?!

I have seen a similar approach in this post but I don't quite like the use of then to execute another function - however proper this is not looking as good as the Promise.delay :)

Happy coding!