Network-Social groupwork self-learning "course" on mondays, learning honing Github-centric skills

Next monday, tomorrow that is, I’m starting a weekly event at Helsinki Hacklab on mondays after working hours.

The curriculum is centered on the skills necessary to remotely participate in a group effort shared on Github. Traditionally most projects hosted in Github are programs, but this does not need to be. Files of almost any kind can be hosted in the change control system.

The big idea is that we collect people of different skill levels to tutor each other, as we all know different areas bad or well. We’ll sort out the details as we go and after tomorrow we’ll have a better idea on what things we start with. My hunch is that we’ll be setting up repositories and learning to deal with everybody having their own version of a common file and then somehow merging the changes together. This is what change control systems do well.

Anybody attending should bring a computer of some sort. Laptops being the most common but tablets can be made to work partially as well. You need to know how a text editor works.

Ping me on irc if you wish, temmi_hoo on IRCNet and Teemu on Freenode.

So, two mondays behind us already!

Attendance has not been high due to guessable reasons but we are going to continue.

Yesterday we concentrated on the data flow diagram in a common open source pattern, using Github and Pull Requests.

In this, we learned most importantly that it is a lot easier to branch prematurely and then doing some changed than it is to first make and commit changes and then start thinking about which branch the commits should go. Of course it is possible to move the commits to other branches later but it is much easier to merge the extra branches.

Also, we learned that Github eagerly proposes making Pull Request out of every newly made branch into a forked repository. In this wizard, it’s possible to select source and target branches, so it’s actually pretty nice.

The Hacklab Document Camera was misplaced, so I could only today obtain photographic evidence of our self-teaching course.

Github Pull Request data flow diagram

Github Pull Request skill set for successfull individual developers

Here is Randal Schwartz’s Introduction to Git. This 2 hour video gives good base to understanding how Git works.

1 Like

This is a nice video indeed. Recommended watching for everybody.

On related note, today is another monday and we’ll be workshopping again on the subject.

We’ve been having a few regulars on monday workshops but more can join.

Anyways, on 31.8.2015 the LAST AUGUST 2015 WORKSHOP IS CANCELLED as I’m spending all of next week on a Google event in Otaniemi. I’m very likely visiting the lab after work hours on monday and tuesday but just very shortly and am completely unsure of my exact schedule.

Next workshop on Github-related skills is due on 7.9.2015 at roughly 17-19 or thereabouts. As SATS are having their regular sessions, we might be not in the lounge but in some other room.

Today again at 17-19 in the lab we are working on Github related workflows and the skillsets.

Note that the lab is suffering a pipe remodeling so there is no toilets.

Monday 28.9.2015 cancelled!

The labaholics are discussing the future of the lab and making some applications for grants in order to develop the lab. As I’m member of this group, I cannot attend the programming skills workshop at the same time.

This means that our workshop is cancelled but the lab doors are open if somebody wants to come and work on their own, basically if you want to hack on something and do group learning or something that’s doable.

Hi ho!

Our ultrafancy IoT controller application, plushie-badname, has new metafeatures:

Gulp is used to run tasks. This is a bit like make but in JS and in general much better. Now it can watch JS files with a linter and watch-running unit tests is just around the corner. This way we can enable the tight dev feedback loop for pure JS as well. In future, Gulp allows us to package the UX side in a browser friendly manner.

Npm can now be used to package, publish and run the software. The most important part of this is a standardized entry point specified in package.json file.

Heroku (or any other PaaS) can run the software largely because of the standard entry point. I made a free Heroku account and we’ll try see how this inspires us to deploy the same software to run on a Raspberry Pi.

So, today again at the lab 17-19ish hours.

Regarding things I’ve found worth reading:

On the subject of prototype based object paradigm a three part series:

More on the classess vs prototypes debate:

Anyhow I’m personally opinionated on the prototype side, as the class implementations are just bolted on top of prototypes. They will not at least for a while be as clean as classess in Java and other more pure class languages. The nature of bolting on top will have subtle differences and personally I think it is better to use the natural way for the language, whichever it happens to be.

Loads of nice tutorials on Node.js

So the basic landscape has now following things and their related skillsets:

  • git and Github for tracking changes in the source tree
  • Node.js and npm for the running environment and packaging
  • Heroku for cloud deployment
  • XXX for installation-local deployment

For the XXX I hope we can come up with something today.

Few years ago when I got first time exited about TDD, I started writing a bunch of agile tools in JavaScript.

One of them was for tracking test-code-refactor cycle:

It runs unit tests and updates state based on current state and result of the unit tests. I was going to present it
and show how to take it into use, but I have been missing couple of last Mondays. I’ll try to be there today.
I haven’t tried it with node.js, so that is one thing to work on.

Our beloved control application could possibly use a proper name but at least we can make it work no matter what.

As I wrote earlier, it is on Heroku as well, even though there’s nothing to run and nothing to connect to yet.

Robert C. Martin aka Uncle Bob speaks an hour about software architecture. Good stuff.

Brandon Rhodes on the same subject.

Our training software plushie-badname is having just enough meat that first lines or architecture are visible. This is where we’re aiming at. We are building from out to in so next we’d have some intermediate and inner circle stuff.

Also, we need unit tests and could do with integration tests as well. Now that we have none, refactoring is cumbersome as there is no way to see if we accidentally broke anything.

So, on monday 9.11.2015 we will discuss architecture and testing.

I succesfully created a pull request fixing the issue #3 with starting our server process.

Process of doing so:

git checkout master
git branch feature-npm-dependency-coap
git chekout feature-npm-dependency-coap
# edit the heck out of package.json
git add package.json
git commit
git push origin feature-npm-dependency-coap # upstream for anybody else
                                            # FIXME: make it upstream for me too
                                            # so later on it'll look better on cli capture logs
# in Github web site, create the pull request when it suggests so

I tested the PR contents that it actually does work and solves issue #3, hence I put in the comments the test procedure and the string “fixes #3” so that Github can automatically close the issue #3.

After merging the PR, I deleted the branch on Github on the now merged and closed PR page. Now I can at will either leave the branch sitting on my cloned repository or delete it from here as well.

Made a new PR that has the newly refactored integration test suite.

Found out why we’ve been having issues with no newline at end of file: by default Sublime Text treats the newline character not as line termination but as line separator. discusses the issue.

Solution: edit user preferences to set “ensure_newline_at_eof_on_save”: true

I found some informative threads, I am posting here

Constructors are Confusing

Object prototypes


14.12.2015 Workshop today has to budge… Sorry for announcing this late.

The Finnish amateur astronomy society aka the rocket guys are having their yearly meeting and basically need all of the lab. Or at least it will be pretty crowded and noisy.

So, instead of working live, we’re today considering machina.js as pointed to me by Asif Sardar.

It allows for finite state machines in Javascript and on the surface is looking good. Being MIT licenced it suits our MIT licence nicely and poses no problems for possible commercial use.


As the lab is on hiatus for the week between christmas and new years, so is the workshop.

Instead, we promised between each other to think about state machine theory as it relates to control structures like set theory relates to number theory.

I’m linking here some material I’ve read and deemed at least decent or possibly even good.

More links to come!

The proper name to my found JS module for running periodic tasks is periodic-task.

Apparently the module periodic looks also nicely simple and can be considered nice for us.