Alice Codes

I just finished presenting Node.js after a 22 hour tech learning sprint. (Technically less than that since I did sleep).  It was fun to learn something new, yet rather difficult trying to cram everything into a 10 minute presentation, (and make sure the info you’re presenting is actually accurate...)    I’ll include the CliffsNotes version here! (random: look! CliffsNotes is now camelCase! :D)

What is Node.js?

On its website Node.js, defines itself as a “JavaScript runtime built on Chrome's V8 JavaScript engine.”  What this means is it’s javascript code on the server side running on a very fast engine.  

Why is it special?

It uses JavaScript.  JavaScript on the front-end, and Javascript in the backend.  What’s not to love?  no code potential conflicts?

Also, Node.js works asynchronously just like JavaScript in the browser, which means non-blocking processes run pretty much at the same time because it doesn’t wait for something to finish before starting another one. (It’s shuffled off the call stack to a worker that will trigger any callback functions). So that means…. you guessed it! It’s super fast!  

One example of this is being to simultaneously read and write the same file at same time.  It’s not exactly the same time because one method is still started before another (as written in the order of your script), but more it doesn’t have to wait for a file to finish writing before starting to read/process it and vice versa.

Node.js is also event-driven!  If you’ve used JavaScript before, you’ve most likely fell in love with the event listeners that allow your users to interact with your webpage. It’s also here in Node.js but with different events attached, since you’re not working with the browser window object anymore.  There are even identically named methods, like setTimeout(), setInterval(), and .on().   

It’s highly scalable due to its asynchronous nature. The non-blocking characteristic allows it take a take on an enormous number of simultaneous connections with a high processing rate.

Scalable: same reason for big file I/O; you can do many things at the same time quickly (simultaneous connections to multiple clients)

What is it good for?

Anything you want real-time : Node.js works really well for anything you want in real-time, such as chat apps.  

Listening for events: its event loops checks for the events you’ve set listeners on and runs the attached callback methods.  

Big File I/O:  Since it’s non-blocking, you can access the same file at the same time, start processing incoming data before it’s finished loading, etc.

What is not good for?

CPU intensive processes pretty much negates its speediness.

Easy to end up in callback hell. Too many callbacks to keep track of...

Real-time Accurate Database dependent data: database processes are pretty much offloaded into callback methods, and the near instantaneous information you have now is not so instantaneous/accurate now until all the database methods have finished running.

How do you start?

A visit to the official Node.js site lists various methods to install Node (and npm).  I installed with homebrew ($ brew install node) and it took less than a minute.

Sidenote: npm, short for node package manager, gives you access to the npm online repo of the many node modules.  It’s like what gems are for ruby.  It’s extremely useful for easy installation of modules and  automatically installs all the module’s dependencies. Just  $ npm install _fabulousModuleName

To use the REPL/console for running js in terminal, just enter node and you can run javascript code here (like what irb is to ruby).  To exit the console, type process.exit(0) or Ctrl-C twice. $ node someFile.js to run someFile.js

console.log in your JS file will output to your terminal (stdout)

Random interesting things about Node.js

In addition to boolean, number, string, and regex, there’s a new datatype called buffer.   Node.js docs describe Buffer as “[Raw data] stored in instances of the Buffer class. ... similar to an array of integers but corresponds to a raw memory allocation outside the V8 heap.”  It’s basically a chunk of memory.  

The Node.js Documentation is also color-coded for stability of a specific feature, which is interesting.  Although I’d like it even more if there were examples for all methods instead of just a few methods.

Everything in Node.js that has events are instances of the class event.EventEmitter .

There’s also this interesting thing call a stream, which is not a datatype.  It seems to correspond to a “stream” of data like files, input, and output.

Node.js code vs. javascript on the front-end  

There are some differences: no access to the browser window object, since you’re on the backend, but syntax is still JS syntax.  

One key difference I should mention is how to include your .js files into your code.  On the front-end, you include the link to your javascript file in your html code.  But there isn’t an html in the back-end!  In Node.js, any modules are required at the top of the file (using the CommonJS module pattern) like this:  var http = require('http');

A Node.js web server is pretty easy to implement. I included the bare bones of one below that I bound to port 3005 of my computer and served my index.html file when I visited localhost:3005 in my browser. You can easily find many other different examples.

var http = require('http'); var fs = require('fs'); http.createServer(function(request, response){ //can(/should) include error handling with error status codes, etc. response.writeHead(200, {"Content-Type": "text/html"}); fs.readFile('index.html', function(error, contents){ if (error) console.log(error); // something to see errors // can write multiple globs of data with a bunch of response.write() response.write(contents); response.end(); }); }).listen(3005);

Note: you technically can put the content of your response as an argument in response.end() without having to use response.write(), like: response.end(“This is a cool response!”)   

This is not a web framework though.  So, you would have to hand roll one yourself or use one of the many wonderful frameworks built on Node.js, such as Meteor, which is already on my giant list of things to eventually check out.

I’m have to see how to include my browser JS file with my index.html file when serving with my Node webserver.  It seems to be overwriting it with my html file.  hmm… more learning and research!

My classmates’ topics ranged from D3 to React to Redis to Ionic.   Joseph even did a presentation on on socket.io, which is built on Node.js, and used made a basic chat app demo!  

So many things to learn, so little time.  It’s more a lifelong journey, than a sprint.  Enjoy the journey!  (...with lots of level up opportunities!  Game on.)

Switching from ruby into JavaScript takes a bit more time to get used to the syntax.  

JavaScript is super cool to see your code visually.

This week I learned the basics of JavaScript, from basics to jQuery to events, effects, and callbacks, to the object and MV* pattern.

Ruby is a lot more forgiving /lax in syntax (i.e. allowing you to omit parenthesis sometimes).  But JavaScript, while strict, doesn’t give helpful error messages, if they even show up.  

So debugging JavaScript code is more difficult since code tends to sometimes fail silently (if passing wrong number of arguments into methods).  Thankfully, chrome’s dev tools allow for breakpoints that I could use to check status like using the pry debugger or the better errors gem in rails.

I worked in a group of 3 to create a user geolocating app that returns upcoming concert locations.  What was memorable was how different it is to working with more than 1 other person.  We decided to use the merge workflow instead of rebasing, because we didn’t want to modify the commit history.

The git merge workflow is basically working on a branch, committing as usual, pulling any changes from master to your local branch and fixing conflicts before pushing and merging to the master branch.

Working with my 2 teammates using the git merge workflow was interesting:

working with branches keeps changes separate until merging

pulling and merging changes into my feature branch usually resulted in lots of conflicts

merging when someone else is doing so cannot happen at the same time (since you have to incorporate the new changes to the master code to avoid merge conflicts)

some of your refactoring to existing code might be reverted by someone else

integrating code takes a lot of time if the information given from methods written by someone else isn’t specified.

Test Driven Development is fantastic. A bit tedious difficult initially, but still absolutely awesome for bug squashing. It is a bit difficult because of the variety of tests available (not limited to model, feature, controller, and view tests).  TDD forces you to plan ahead, sometimes a bit too far ahead, because I have to decide what the right balance is when writing tests vs writing code.  Do you write tests for every single method, function, and possibility, or the breakable ones, because the minutia can have a tendency to change?

It is very different working with code that you did not originally have a part writing, even if you already know what they’re supposed to be doing.

We were working on a multi-day project with different partners for each day, where we selected the code that made the completed the least user stories to work on as a pair.  Although the end goal of the code were the same functionally, the structure and methods vary greatly.  So, it takes a bit of time to understand the architecture of existing code and methods without spending too much time refactoring the existing code (for clarity) to what I would write.  

It is a great learning experience to read and work with the code.  I have worked on at least 4 different versions of this store application, and each version is slightly different from the other.

Databases are amazing.  Not your first impression?  But think of how much stuff gets done so quickly!  So efficient!  However, it all depends on whether the data is accurate, and whether your relational database management system feels agreeable with you today.

Unfortunately, Active Record was giving my pairing partner and I really odd postgreSQL errors when we ran certain queries. Odd in that it runs perfectly in the rails console, but gives reproducible indecipherable errors (that really weren’t relevant). 

What we tried to debug:

Read (irrelevant) errors to figure out what’s happening.

It mentions a column name not referenced. double-check: nope, didn’t write that.

Check console query: yes, it was correct and returning the wanted info

Check for spelling errors: redo copy/paste from perfectly running query from rails console, just in case.

Restart server: no change.

Rerun query in restarted console: gave the correct answer.

Reload page: same error.

Check with pairing partner to see if same error occurs on her computer. yep.

Check for rails errors: fix commented out specific query to see if problem persists? Nope.

Use SQL syntax and find_by_sql method instead. (Also, check that in console, and it works).  Still error in rails.

Reorder Active Record method chaining. nope.

Google problem, while asking for help. no relevant matching results.

Get help: error could be reproduced by others, verified that syntax was correct.

Finally, split up the query into two parts to get the two pieces (columns) of data we wanted that should have been returned without problems. FINALLY!

Other than that, It’s absolutely fascinating how the queries can quickly return information from large databases.  This week’s focus on databases reminded me of Kristal Pollack’s engaging Women Who Code Tech Talk @ LinkedIn on distributed systems, and how CAP theorem applies to gigantic databases and consequently the data involved.  Super cool!

The reason we didn’t split up the query into two subparts is that it doubles the query time every time we need that information.  If I needed another piece, it would be increasing the query count again.  Plus, SQL can and should be able to handle that (as displayed in rails console) much quicker than having data processed in ruby.  It’s good to find out why some error is happening and try to fix it before patching the problem to work around it.  I still would like to know what exactly happened so I know how to avoid/solve it in the future.

 On Wednesday, I worked on a Sinatra blackjack app that would only use cookies to store data.  Cookies are used to store data of the game state since HTTP is a stateless protocol, meaning each part of the request/response cycle between a browser and the server is completely independent.  Sounds simple enough to use cookies to keep track of game state without losing information due to how HTTP works.  

But, the cookies from the initial game refused to be deleted!  My pairing partner and I tried aggressively deleting it by adding multiple delete methods: once after the game ended, another when we initiated a new game and save a write a new cookie, and more than one variation of cookie deleting methods.  Yet after the new game began, the cards would eventually revert to that of the initial game.  What happened?

There were two main problems.  First, instead of only one, two cookies were being saved: one on the main route and another it redirected to another.  So, deleting one cookie at the end of the game, did not in fact delete the other, even if the other cookie wasn’t seen while on the end page.  The fix is to specify the path the (one! we only want one!) cookie is being set to.  Second, the code regarding the cookie sent to the browser was confusing.  By attempting to delete the old cookie and save a new one when a new game was started, the browser received it in just one request and the conflicting request did nothing.  The fix for this is keep to one cookie related action per response.

It was only in the second week into the program that we started working on creating a DOM tree.  Trees, organic or data, are pretty awesome.  But, a DOM tree is really difficult to build the first time around.  We were forewarned that previous students had spent up to twenty plus hours on this project due to numerous road-blocks.

With that foreshadowing, my pairing partner and I, spent a lot of time planning the details of how we were going to create our DOM tree to avoid the possible edge cases that would create an incorrect tree.   Better to have a clear idea of how to proceed than to go start coding immediately and have to backtrack later to fix or rewrite that method later.

We decided to build the tree recursively with using a subset of data with each recursion until there were no more nested elements to create the child nodes.  Recursion is basically iteration with a stack, but easier to read in code and follow sometimes.  The plan was to find an opening tag, grab the data between that and its corresponding closing tag, construct and node, and recursively construct more nodes with the subset of data that was nested inside that tag. Then proceed with the rest of the data.

Implementing it and the additional methods in less than ten hours was a totally different story.  The first roadblock a persistent nil error from the html tag identifying method.  The same tag method was used twice in tree building method: once to ID the opening tag, and another to find the closing tag.  However, the second method was failing to ID a second tag. The method written method had passed all of our previously created specs to check it was working as required.  But, I guess the specs were not comprehensive enough to catch the errors we were getting.

The next few hours was an intensive learning experience with debugging our tree building method.  First, our tree only had one branch: so the rest of the data wasn’t being processed.  Next, the method was infinitely looping: the dataset wasn’t getting smaller.  We had probably spent too many hours rereading and testing it that we were overlooking something obvious.

With only two hours left, we scrapped the method entirely. It was a big decision, since we had spent much time planning it.  But it was refreshing to start over again and try to solve it in another way to avoid the problems we were encountering.  Eventually, David and I built the tree with the new method in less than an hour…  

It’s good to not get too attached to the original code until it actually solves what it was meant to do.  Sometimes, I’ll have to scrap it because the original idea didn’t work too well, if at all.  

After a week of long hours of pair programming with different people, I have to say that pair programming is an amazing way to learn and code.  You get to mesh your brain with someone else and yield some code that wouldn’t have taken much longer if you had wrote it yourself.  

Combining knowledge is the best way to fill in the blanks!

Random note for beginning Rubyists using Codio:

Bundler is amazing, but you have to install it first!

When I just started using Codio in February to learn how to code, I didn’t know the bundler gem wasn’t pre-installed. I had to manually install each and every gem in the (thankfully small) Gemfile because the “bundle command was not found”.  I later found out that the bundler gem wasn’t installed in that particular version of ruby on codio. Talk about embarrassing.  gem install bundler!  wee!

I recently put together my standing laptop desk in preparation for the start of Viking Code School.  I’m so very very excited to dig deeper into web development.  

I come from a background in the biological sciences with work experience in healthcare administration and research.  But, it’s not completely different.  

I think of both as a thorough use of logic to structure tests/experiments, in order to reach an efficient end goal: be it with a product or specific knowledge. 

Debugging fixes = successful experiments!