I’m in my third year of a Software Engineering Major and a Telecommunications minor. I’ve had very minimal experience with web applications so my understanding of Java Script, CSS and HTML is poor. My strengths are that I can pick up new languages and information quickly and have good time management skills.
This is my third year studying for my Computer Science major. I have some basic knowledge of HTML and CSS from COMP112. I spent the summer doing COSC360 which taught me a fair bit about JavaScript and version control in relation to creating games. I know very little about the canvas element and SVG, and will have to read up about them online before starting work on the project.
I’m currently in my final year of my computer science degree. I have studied COMP112 and COMP212 so have experience using HTML5,JavaScript (and jQuery) and CSS. I have only used JavaScript in terms of constructing websites rather than for coding games or applications. I have had little to none experience with the <canvas> element or SVG, but have had a look at the W3Schools tutorials.
I am a 3rd year Computer Science student. My previous experience with HTML, JS and CSS is relatively strong with having previously taken COMP112 and COMP212. My experience with the canvas element is minimal but I do have some experience with libraries that handle the canvas element, such as Phaser.
We thought long and hard about our application ideas and concepts for our emulator. The following is what we decided upon:
We decided that our emulator would have a ‘hardware’ part and an ‘OS’ part. The hardware part is to be made up from HTML and CSS. Including a canvas element for the screen and a selection of form inputs to represent the watches sensors. The OS part is to be made up of JS functions made available to the Application that allow retrieval of values from the sensors and displaying content through to the canvas element, most probably through the use of a Canvas library.
Semantically the application is just going to make calls to the OS, make decisions based upon those values and then display to the screen and take touch input.
Our concept for the application is a app that allows a user to keep track of their phone. We realised that a watch is something that a user tends to keep on their wrist at all times, but a phone can so easily be placed down and forgotten. So our idea is an app that creates a bluetooth connection between the watch and the phone. When the user moves away from their phone and the connection is lost an alarm sounds on the phone, watch or both, to alert them that they’ve left it behind. We also decided that a button press on the watch would cause the phone to make a noise as like a “find me” feature. Finally the user will be able to set/remove “home zone”s at somewhere where they don't want to be notified such as when they leave their phone somewhere in their house.
When we were discussing which type of version control to use, we came up with two main contenders: Git and Mercurial. The reason we chose these two in particular is because they both provide the functionality we need when developing our app, and are both widely used by real software developers. Also, the majority of our group has previous experience working with either one or the other.
Overall, we found the cons for Git to be much worse than Mercurial’s. For example, some of our group hasn't worked with Git before, and the high learning curve would mean more time wasted learning Git which could've been spent coding. However, with Mercurial, space shouldn't be a problem as our project will be quite small, and merging with more than two parents can be quite inaccurate anyway, meaning we'd have to spend a lot of time resolving merge conflicts. In the end, we felt that the most important aspect we needed in our chosen version control was reliability. The fact that you can lose entire revisions in a Git remote repository, however low the chance, definitely scared us away from Git. This, coupled with the fact that running Git under windows requires cygwin or a port such as MinGw, has convinced us to go with Mercurial as our DVCS. For hosting our remote repository, we'll be using bitbucket.org. This is because some of our group members have previous experience setting up repositories with bitbucket, and it's free as long as we keep our project open source. Our repository
When discussing which language to use, the immediate vote was to use JavaScript. Since both Dan and Tori had taken COMP212 and Francis had completed COSC360 over summer school, we decided that to learn a new language or one that generates JavaScript when 3 out of 4 of us had good experience with JavaScript, would be time consuming and somewhat of a waste. Before ruling out TypeScript and Dart altogether, we did a bit of research of these languages.
“TypeScript lets you write JavaScript the way you really want to. TypeScript is a typed superset of JavaScript that complies to plain JavaScript. Any browser. Any host. Any Os. Open source.” Rather than diving straight into TypeScript tutorials or syntax, we researched the benefits of using TypeScript over JavaScript. Using Google, there were numerous blogs discussing the pros and cons of TypeScript. Summarising these that relate to our project:
TypeScript is the language of choice for large scale applications and is a superior “version” of JavaScript. If our project was enormous and complicated with large quantities of code, we would consider using TypeScript over JavaScript for the benefits of error checking, open source and server side capabilities. However, at this stage since our overall knowledge of JavaScript and jQuery is extensive, we believe using JavaScript over TypeScript is the better option.
When reviewing Dart, we found it had similar characteristics to TypeScript as it was designed for large scale web applications to allow for easier modification and de-bugging, especially when working with a larger team. “Enter Dart, an open source project that aims to enable developers to build more complex, highly performant apps for the modern web”.
If our project was large scale, something that would have to be modified or updated or published on the App Store or Google Play, choosing a programming language would be a much greater decision and the benefits of using something other than JavaScript, outweigh the effort to familiarise ourselves with a new language. However for this project, we have decided to remain with JavaScript.
There were a few major things to look at when it came to deciding on an editor. HTML and CSS have a huge number of possible tags, selectors and properties which can be kind of overwhelming, this means that auto-completion is a must. With our project, due to the work being distributed between multiple coders, and our style of development we’re going to need to make full use of version control. To make our lives easier, solid integration for version control inside the editor would be hugely beneficial. Also, certain aspects of Javascript can be fickle when attempting to access pages through the local file system, to circumvent this some editors include a light-weight web server that can be accessed to live preview the web app. We believe this to be an incredibly important feature. Finally we decided a lightweight editor would be more suitable for working anywhere. Because all the editors are so similar I decided it would be easiest to compare them on these features
| Eclipse | Netbeans | Bluefish | Brackets | WebStorm | |
|---|---|---|---|---|---|
| Auto-Completion | HTML5, CSS3 and JS | HTML5, CSS3 and JS | HTML5, CSS3 and JS | HTML5, CSS3 and JS | HTML5, CSS3 and JS |
| Version Control | All major VC (With Plugins) | All major VC | No | No | All major VC |
| Local Server | Can publish to separate local server | Can publish to separate local server | Can publish to separate local server | Contains a local server for live previews | Contains a local server for live previews |
| Lightweight | Rather Heavy, contains IDE for other non-web languages | Rather Heavy, contains IDE for other non-web languages | Very Lightweight (4.5MB Setup File) | Lightweight | Medium, quick to load with quick Auto-Complete |
Taking a look at this table we can get an idea of the choices available in the way of editors and how well they implement the features we decided as being the most valuable. All include comprehensive code-autocompletion, Brackets and Bluefish do not support Versioning and only Brackets and Webstorm have a built in webserver. Finally Netbeans and Eclipse are far heavier than we’d want due to being fully featured Java IDEs at heart. After taking all these factors into account we decided that WebStorm was the best editor for us to use. Normally we’d have to take into account the cost, and as WebStorm is the only commercially licensed editor here that could change our mind, but due to the University having WebStorm on the lab PCs we don't have to worry about that.
All of us haven’t had much experience using any type of debugger so I’m going to be having a look at a few of the most popular ones. I’m going to be looking at Chrome’s Dev Tool, Firebug, DragonFly and NetBeans. We might consider switching debuggers further into the project deping how we find the one we choose.
We also had a look at netbeans debugger but couldn’t really find any real benefit on why to use it instead of any of the web browsers ones. We really liked the sound of FireBug so we’ll give that a go for starters. As a backup incase we end up not liking it then we’ll try DragonFly.
At the stage we have decided to divide the next assignments into sections and assign these sections to each member of the group. For the next assignment there will be four stages:
We have decided that each stage should be worked on in pairs and then reviewed collectively.
We use a similar approach in the third assignment for assigning deadlines and workload. Since this part of the project is a fair time into the future, our timeline is not too specific as we expect we will encounter problems that do not fit into our “plan”. In this assignment, there are three sections.
Completion of the report should be worked on alongside each stage so we can accurately record our work. As we do not know what our code will be or what tests it passes or fails, it is too early to designate whole stages to group members. We believe there will be several tasks to complete at each stage, and these tasks will be delegated to individual or pairs of group members.
The final assignment has already been divided into 3 week slots, one for each emulator. Testing the application in the emulator and recording results, we estimate to complete in the first week. The second week we aim to reserve for the report writing. This leaves 1 week for polishing of the report and for any extra testing and results that we have not anticipated.