While I haven’t had a lot of time to be able to spend on investigating into Jaxer to be able to streamline the install process. I have had a chance to take some time in working on some concept images for the EmraJs logo and mascot. So I guess we should start with the important part, which is the mascot.

It might have been a good idea to use a VPS since it has allowed me to get some perspective on something I’ve been thinking about for the last few weeks, which is how to get people to sign up for your service and get started using the service. And what better way to learn from the best since the VPS services have a lot of innovation and funding and marketing to make them stand out and be easier to use than other services.

Since I haven’t had a chance to do a lot of testing recently, I think I can go ahead and continue to look for aspects of the server-side application that can be removed or simplified. In terms of testing, I think could try using multiple Pi’s, and always have a working version on hand, so when things break I at least have something to fallback on to say, “no really it works, look”. I was thinking about maybe using KVM to create a virtual Pi for testing, but that requires setting up a new server, since I’m always paranoid about messing up the bridge-network connection and having to trouble-shoot the network so that it works again.

My first application for a visa extension in Japan was three years ago. And in comparison to applying for a student visa, or graduating from college and applying to a company, there is no monumental event that marks when you need to renew your work visa. You just kind of have to remember. So like any responsible member of society I completely forgot until the last minute, and looked on the immigration page which basically only had the application form, a portrait photo and your passport. Thinking that “that sounds too easy”, I grabbed the listed documents and got up early the next day to go to the immigration office in Shinagawa.

Since I’ve been a little hasty about jumping in and cleaning out the server-side API, I figured it would be a good idea to step back and re-evaluate my goals for the server API. For installation we had a somewhat simple task of simply removing anything that wasn’t needed to compile, and we were able to take our time and focus on one element at a time. With the server-side API, we don’t exactly have the same luxury as we don’t know how interdependent the various modules are to each other.

Throwing the alphabetical approach out the window, there’s file that I’m pretty interested in looking at. And that file is ServerStart.js. This file get’s loaded when a new Jaxer instance is created in order to initialize the Apps that are recognized for that instance of the server. So getting familiar with this file might help with either simplifying or reducing the number of files needed to run Jaxer.

While it would be nice to move the framework around get it arranged, maybe we can look into the framework itself to start getting some context of specifically what’s running and where. We have a couple of options of do we go alphabetically or do we just jump in and start looking at what’s interesting? To start out we don’t need to pick and choose because the first file App.js looks extremely interesting.

In the past two blog posts we looked at the possibility of removing more unused folders from the final run time install location, and then we also looked into moving the server side frameworks source into the src folder. For the first possibility, we were able to find more unused content and remove it from the repository. For prospect of moving the framework source, we were unable to successfully move the files without causing errors, and weren’t given many clues as to what the issue is.