Starting out with NodeJS, Socket.io, and more server-side Javascript

So, recently out-of class I've been working on quite a few projects, many of which are relating to Javascript. A lot of them have been specifically aimed at websites that are using APIs to communicate, then connecting the client-end code to NodeJS on the server-side.

So, for a quick overview:
I've been using NodeJS on my server-end to handle things such as saving files, getting data, and doing other stuff that Javascript can't. A good example of this is that I'm using a bot that connects to the SteamAPI, and I can show information about this on the client-side through sockets.

Sockets are essentially the main thing we use to connect client-side code to server-side code. I've come to learn that they're extremely helpful, as lots of time Javascript code lacks certain features due to security restrictions. I've been writing my sockets in PHP recently. Here's a small example of a socket I used in my code recently:

Client-End
Server-End
Since a lot of new things were mentioned in this post, I'll try to get more into detail about them throughout the next week.

As you can see above, the Client-End is coded in PHP, while the Server-End is coded in NodeJS. Essentially, our Server-End is listening constantly on port 5501, while our Client-End is occasionally sending data to it. We can send the data as JSON, and then later parse it on the server-end, and send more information back based on what the sent information was.

This is all good, however, I found a new library yesterday called Socket.io. It's still doing the same things, but when you see how much time it saves, it's ultimately worth the switch. I'm going to be switching all my code to Socket.io based code over the next few weeks.

Socket.io makes socket communication amazingly simple. Their example of a simple chat server showed how you could easily have socket-based communication and an entire chat server in just a few lines. I thought that was amazing, especially thinking back to our old AndroidRPG project from earlier this year - we could have saved all that time with a simple plugin. The best thing is, it's been ported to all sorts of mobile platforms, including Android, and it's pretty efficient.

I've also been working with a few more libraries:
-Progressbar.js - Truly amazing progress bars. Allows for really nice ways of showing loading of items, live item counts, etc.
-net module for NodeJS - Allows for socket connections. However, I'm currently in the process of merging to socket.io as previously stated.
-Spotify Android SDK - I'm also in the process of making a music app for Android. I use Spotify to authenticate and play music.
-Steam Web API - I'm working on a bot that is 'talking' to the Steam Web API to grab virtual item information
-Bootstrap - Quite possibly the best API I've ever dealt with. It makes all your pages look amazing, it's open source, and so many people use it.

I'm also working with several more APIs [at least 5-10 more], but my progress with them isn't as far. As you can see, I've really been working hard on API-based programming and Javascript/NodeJS in my spare time, mainly because I'm surprised at how much things they can do!

Working with GitHub Remotes, Pull Requests, Starting Bug Fixing (4/20)

Today I started out with making a pull request to your GitHub project. Luckily the fix wasn't too intensive - I managed to fix it with a few changes to the manifest.

The Geolocation API wasn't working, so I decided to check the manifest. Luckily, the fix was that the app wasn't allowing the Geolocation APIs, so by allowing these in the manifest, the app was able to access such libraries.

Making a pull request was pretty easy after we figured it out. My issue was that I was trying to clone your repo and make a pull request into it. What I needed to do was fork the repository, then change the origin:

git remote remove origin
git remote add origin [fork repository url]

After that I could push into my forked repository, which I could then create a pull request to fix it.

I also worked awhile on fixing contacts. Our only issue was that it wasn't continuing through the loop. We were using:

this.continue;

Instead of:

this.continue();

This resulted in only being able to get the first item of the result array, when there were a lot more available. By having a continue afterwards, we were able to successfully loop through the array.

Brackets! (4/13/15)

I've been recently going home and starting a few experiments of my own with Javascript. A few days ago, one of my friends told me about a new program called Brackets. It's written and hosted by Adobe, and so far is one of the greatest web development programs I've ever used. It's open source, too, so I'm sure it is going to be something that quite a bit of people are going to use!

It's similar to a Java IDE in that it has auto-completion of tags, code completion, etc. The main reason I installed it, however, was a directory structure on the left. I couldn't use Firefox's WebIDE for my personal projects, since they weren't FirefoxOS apps.

Anyway, I thought I'd introduce it. I love to use it so far, and it's saving me quite a bit of time!

On a side note, I've started to look into the Chapters bug. While I haven't found anything obvious that's creating this bug yet, I'll continue to look into it tomorrow and see if I can make some progress.

Working with Scaled Vector Graphics and App Logo (4/10/15)

On Friday, I worked on the app's logo and scaled vector graphics. I thought it would be a good time to step back a bit from the specific bug and get something done that was a bit more important.

I learned a lot about SVGs! One of the coolest things I found out was that if you opened it in a text editor, it showed all of the properties about the SVG, such as default width, height, colors, etc. I found that really interesting, because you're able to easily change any specific property of the image just by changing a line of text, rather than manually drawing it in.

Another thing that I found interesting was that it was so easy to scale. All I had to do was drop it in the app's icons folder and it instantaneously scaled for all device sizes, which made it a whole lot easier to make, rather than individual png images which we would have had to resize.

On Monday, I plan to code the base for a few new features. I'm not going to make too much, however, because I want to continue condensing the app as much as possible.

I also have to start working on a bug that relates to chapter objects. Apparently, our app was denied from the marketplace until we fix a bug that has to do with chapters being one greater than we should. While I don't ever remember noticing this, it's possible that it was a result of our refactoring. I'll have to look into it a bit more.

Refactoring and Bugfixes

To start today, I fixed the README file so that it states that it's an audiobook player, rather than a port.

I then began to start refactoring for the book.html page. I noticed that it wasn't saving information for the slider, specifically CSS code. I'm still trying to fix this, and I'm not exactly sure why it's occurring. It's either a JQueryMobile issue or an issue with the page refreshing.

I also noticed that the method can be shortened by quite a bit. There's a lot of useless lines of code that can be changed, and I'll go into detail on that after I can fix this bug.

Three more packages we needed to install. They were required for describe() functions in our test code, and also allowed our different testing frameworks to talk to each other. I decided to install them all globally, just to make it all easier to access. In addition, you need to have a config file for Karma, in the directory you're working in. Ours is available on GitHub right here. Once you've navigated to the directory, you open two terminal windows: one in which you type "karma start", and another one you type "karma run" to run all tests you have created. You can double-check that karma is running by going to localhost:9876 in your browser. From here, you can edit and add to tests! Our test files are available here for an example. We'll continue to add to them, so I decided not to link to today's commit, rather to our files, as they will grow a lot over time, and provide a perfect example of how to write unit tests.

I also started working on some unit test code myself. I wrote a full test for Book objects, most of which is still in development. However, everything is already defined as to what the function is supposed to do, so we just need to put assert methods under each it() statement to complete the test! Tomorrow I hope to have full testing of both Book() and Chapter() objects.

Installing Mocha, Karma, and setting up Unit Tests

Today we worked a lot on setting up unit testing. While it could be done in Javascript, there's a lot of tools available that allow the process to be done more quickly and efficiently. We decided to use Mocha and Karma. The setup was simple, however I ran into a lot of issues, so I decided to make a shell script that will automate the process for anyone on a Mac with Homebrew. Comments are included so that anyone knows what it is doing.


After some research, we got Mocha working. We created a /tests/ directory on our GitHub repo, which we use to create and test working code. Our first test function, stripHTMLTags, isn't working yet, because we are still working with issues related to Mocha detecting our window variable from Firefox OS. A fix will hopefully come tomorrow.

The function so far looks like this.

It can be tested by using the following code:

mocha . -r "js/app"

Mocha . runs all tests in the directory you're in, so you have to be in the tests/ directory. -r is equivalent to "require", which is a function that tells the test what Javascript file you're testing. For some reason, using require("js/app") as a function in our test isn't working. It's likely due to a directory structure issue.

We also are awaiting an email response as to what we can use Karma for. Hopefully a response will come tomorrow, but otherwise we can always do some more research. Tests will start tomorrow, since our setup is done.