JS101 Session 17 May - Code review, closures, wiki for new members, further plans for our app

[katjad]

Today we did a bit less coding than other times, but we looked at code instead. Apart from that, we also talked about how to best progress with our app.

We first had two brief talks about closures by @gicela and me. @gicela explained the concept of closures and I gave an example (for some resources see https://github.com/CodeHubOrg/discussions/issues/25).

Then we did a code review together. We looked at the code we had written last time to make the tests in our app pass. We discussed where it would make sense to refactor things.

Apart from that we discussed:

• Preparing some documentation for new members who would like to contribute to our app (including resources to learn fundamentals of JS?); we decided to use the Github wiki on the Organisations database repo for that.
• How to keep track of tasks on the app. After briefly considering something like JIRA or basecamp, or Trello, we decided to keep it simple and again stick with Github and use the issues. In the next session we want to discuss who is interested in which tasks.
• Could we try writing parts of the app in Angular (admin part, CRUD?) as practice? Opinions were divided on that, while it would be good to not be tied to just one framework, a few of us felt that React and Redux provided a good way to improve our JS skills in general, and learning another framework might be a bit much. So for now we decided not to use it in the app, but perhaps in a separate project for those interested.
• Plans for next session so far: @rinse0ut will give a talk about testing

We also did some coding for about an hour.

Not sure this was all, getting too tired, please add things I forgot. Thanks all for another good session. Welcome Mark, and welcome back Hugh!

@CodeHubOrg/js2016

[katjad]

(relocating to the correct thread..) Tonight I went to our own hack night for a change, and wrote some tests for a component in our app. Really happy about that, as at the beginning did not grasp at all how the tests are structured, but gradually it became clearer. I think I might have gone a bit over the top in the end ;) Perhaps somebody would like to make the tests for the OrganisationSelectionPanel component pass? (I have commented out the tests so not to make the Travis build fail ;) https://github.com/CodeHubOrg/organisations-database/blob/redux/test/components/OrganisationSelectionPanel.spec.js)

[katjad]

P.S. Might go to the hack night more often now, if anybody fancies it, they are always on the Tuesdays when we don't meet for JS101 (but you probably know that). @mjg17 was there too today working on the LokiJS backend :)

(They are not competitive, it's just people coding and having Pizza and drinks)

[ondenman]

Brilliant! I've been fighting for time all week but I've got a few hours to work on the component today. Hopefully the app will have my full attention either tomorrow or Friday.

[mjg17]

+1 for hack night.

I'm making good progress with the LokiJS backed store. Hopefully I will have something ready for the next meeting.

[wingedeel]

Well done, Katja and Michael, with the tests and LokiJS respectivelyl! The hack night sounds great and a chance to focus. I am not free on Tuesday evenings at the moment but hopefully I can join you in a few months.

[hsweeney]

Oops, I made a closure.

Thanks, @gicela and @katjad, for covering closures. I learnt something new, as usual here: a closure is a snapshot of the environment at one point in time.

Wikipedia defines a closure as 'a record storing a function together with an environment'. The Jibbering FAQ has a more formal, and probably more exact definition, but the Wikipedia definition well describes what I found.

As Katja said, you can find closures all around, and sure enough when I looked in the JS code of the http server that I was writing, I found a closure in the core 20 lines of code. (That's not necessarily a good thing in itself: Eric Elliott points out that accidental closures can be a source of bugs. And very hard to debug: the value(s) created in the closure may have been based on other values that have now changed, or even ceased to exist if the creating function has now returned.)

It should be noted that the values of variables passed to the closure are the values that existed at the instant that the closure was created. The data in the environment is cloned at that point in time. In my code, the 'client' variable, that is passed to the closure, is reused repeatedly for each new connection made to the server.

And a warning: it's often very convenient to spin off a worker thread, based on a closure, to handle events asyncchronously as my http server does. This can use a lot of memory. The JS vendor's implementation of a closure may clone the entire stack/heap of the calling function, and all functions higher up the call stack, for each closure created. And if the server is handling, say tickets for a big music event, there may be tens thousands of connection events in the first few seconds after they go on sale.

Here's my code where I found the closure (stripped of everything extraneous to the threading and closure functionality(:

// --------- Start of (single) main thread
mainLine();

function mainLine() {
    var ss = new java.net.ServerSocket(8080);
    while(true) {
        var client = ss.accept();   // Await a connection from a Web client
        var objFnRun = {    run: function() {handle(client)}    }   // <--- Closure created at this instant
        var threadClient = new java.lang.Thread( new java.lang.Runnable(objFnRun) );    // Make a new thread.
        threadClient.start();       // Invokes the 'run' function.
    }
}
// --------- End of (single) main thread

// a function that runs on a different thread for each client
function handle(sock) {
// Some slow database code in here, eventually sending an html stream.
}

Don't be misled by seeing various names beginning 'java.*'; this is pure javascript code. Those names represent objects from the environment. Just like in a browser environment you can access DOM objects. In this case the environment is the Rhino Shell, which is bundled with Java 6.

The above code is the entire multithreading logic of the server. I wrote mainLine as a separate function simply to demonstrate (by modifying the while condition to break out after a few iterations) that the closures created within it continue to exist and run after the creating function has ended. The single variable, client, that is used in the closure is re-assigned a new value at the next iteration of the while loop, whenever another socket connection is received. So, it's not the current value of tha original variable that gets referenced when the code in the closure is executed; it's a copy of the value that existed at the time the closure was created.