Tag Archives: Portfolio

Google Analytics & Sitemap

Today I tinkered on my website to verify that I have finally completed some outstanding items on my website that I have been planning to do for ages.  The only one that I really should have investigated sooner was Google Analytics as now I don’t have any data prior to the end of this week as it appears what I had done way back when broke at some point when switching themes, etc.

What I have done:

  • Updated to latest version of Quark Theme
  • Verified Google Analytics is working… using the Analytics Cat Free WP Plugin, this is a very easy plugin to use and will have to see how well it works over time
  • Using Google XML Sitemaps plugin, added my static pages, set priorities and sent off my sitemap to Google & Bing
  • Using a simple Homepage (removed in transition note as no longer in transition)
  • Google Search console has my sitemap

The only outstanding item I now have is to figure out what to do about a portfolio.

Oh yeah, also need to continue tinkering and get cracking on some personal projects 😉 .  Though I have been working hard on one personal project, that is building my plane!  I will want to contain this kind of info in a category within my portfolio, so it will not just be software development projects.

Natural Language Processing

Initial Starting State

This application imports electronic medical records (stored in text files) from the selected folder and runs each file through the natural language process of:

  • Removing stop words
  • Stemming words
  • Creating an index

For stemming the Porter Stemming Algorithm is implemented to transform a word into its root form and contains six steps:

  1. Get rid of plurals and –ed or –ing endings
  2. Turn terminal y to I when there is another vowel in the stem
  3. Map double suffices to a single one
  4. Deals with –ic-, -full, -ness etc. endings similarly to step 3
  5. Takes off –ant, -ence, etc. in context of <c>vcvc<v>
  6. Removes final –e if the measure of the number of constant sequences between 0 and j is greater than 1, i.e. <c>vcvc<v> gives 2

A trie (prefix tree) is an ordered data structure used to store the index in memory.  All descendants of a node have a common prefix under the same branch.  The common prefix eliminates the need for storing the same prefix each time which increases memory efficiency.   A simple representation containing the words aspirin, ankle, and pain is:

Trie Data Structure

When the user searches for keywords, Figure 1, spaces are seen as an AND condition and commas are seen as an OR condition.  A list is displayed to the user showing the file names of the documents which contain there search terms.  Double clicking on a particular document will open a new tab displaying the documents contents and highlighting the keywords present in the document, Figure 2 & 3.  When mousing over the keywords found the SNOMED and UMLS IDs are displayed.  These are determined based on a separate trie data structure built from the SNOMED CT data.

Pain Search Result
Figure 1: Pain Search Result
Encoding of Aspirin
Figure 2: Encoding of Aspirin
Encoding of Pain
Figure 3: Encoding of Pain

Games Room Application

Games Room Application Icon

This application consists of three main parts which are the client, server, and the game of SOS.  The server ran on an Elastic Cloud 2 (EC2) instance with Amazon Web Services where I configured the Windows server and supporting software.  This includes creating a database in MS SQL Server, creating the necessary users and assigning them to the database they can access.  Mappings are set for the user which grants the necessary permissions.  The firewall also needed to be configured to allow the appropriate ports access so clients could connect to the server (and the server could receive connections).   Internet Information Services (IIS) was also configured so that the Java Network Launch Protocol (JNLP) MIME type was recognized by the web server so that the client could be launched using Java WebStart from a webpage.

Client-Server communication uses a server socket that listens for incoming connections.  When a connection is accepted a new thread (ClientHandler) is spawned which handles communications with the client through a socket.   Java’s ObjectInputStream and ObjectOutputStream are used in order to send and receive Java objects.

Threading is used on the client side to listen for messages from the server.  On the server side each client connection is ran in its own thread and handled by a ClientHandler class.

Database access is handled by the server using Java Database Connectivity (JDBC) drivers.  Any information retrieved from the database is sent back to the client using a data transfer object (DTO) and packaged as a games room message of the correct type.

The application allows users to chat in a main room or create their own chat rooms which can be public or private.  Users are able to join any public room but the only way a user can join a private room is through an invite from an active participant.  Files can be sent to users of a room.  This is done by reading the file as bytes and sending the byte array along with the filename as a string to users in the room.  Java’s FileOutputStream class is used to write the file to the recipient’s local machine if they chose to accept the file and saved it.

Users are able to manage their profile information, Figure 1.  Which allows them to change certain information, including updating their password.   The application uses a hash implementation using the password-based key derivation function 2 (PBKDF2) algorithm with HMAC and SHA1 (part of RSA public-key cryptography standards) for hashing user passwords and then storing the hash value in the database.  When a hash is being created for a password the string is converted to a byte array and a salt is created using java.security.SecureRandom for the specified salt byte size.  The PBKDF2 hash of the password is then computed by creating a password based encryption (PBE) key of variable-key-size PBE ciphers utilizing the users’ password, salt, number of iterations, and how many bytes the result should be.  Javas secret key factory, part of the javax cryptography package, is then utilized to generate the secret key (hash of the password) for the PBE key specification.  All relevant data is then placed into one string which takes the format of ‘iterations:salt:hash’ where the salt and hash is first converted to hexadecimal.  The colons are critical as they are utilized for splitting the information when validating passwords.

Users are able to play the game of SOS, Figure 2, when they are in a room they have created.  The first two members to join the game can play, as it’s a two player game.  The game implements the MVC pattern, using SosController.java as the controller, GameView.java as the view and the ChatClient as the model for how to handle requests from the user to the server and vise versa.  DTOs are used to transfer data between the clients through the server as well as for saving game states.  The DTOs are Board, Player, PlayerMove, SavedSosComponents, ScoreCard, and Turn.

Users are able to save the contents of a chat session for later viewing and a facility to view and manage any saved chats is provided, Figure 3.  Users can also save a games state to be continued at a later date and when loading a saved games both participants must be logged into the application.  Game states are converted to XML using XStream to be stored in the database.

Validators are created by implementing my Validate interface and a separate class for each validator (i.e. NewRoomValidator.java) is created.  This separates out the process of validating information entered into the GUI from the actual GUI code itself.

Profile Manager
Figure 1: Profile Manager
Playing SOS
Figure 2: Playing SOS
Saved Chats
Figure 3: Saved Chats

Tron Game

This was a group project in which my role was to handle the networking / multiplayer aspect of the game.  This application implements the Model-View-Controller (MVC) pattern.

The server runs in a thread and handles all client connections.  Each client connection is represented by its own class (Client) which handles sending a message to the individual client and receiving data from a particular client to the server.  Each client runs in its own thread.  The run function listens for messages from a particular client and handles it by the message type.  While the length of the message is less than the message length data is read from the socket and added to a message variable.   A check is done as to where the end of message flag is and adds the overflow into the buffer and then passes the message type and packed message to be processed by the server.

The client runs in a thread and handles all communication between the client and the server.  Interpreting messages received from the server and packing messages prior to sending them to the server.

The server controller runs server side to handle updates from the client and the client server runs client side to handle events from the user interface to be sent to the server as well as to update the view based on messages received from the server.

Figure 1 and 2 show UML diagrams for the key components of the application I worked on, the server and the client respectively.

Tron Server UML Diagram
Figure 1: Tron Server UML Diagram
Tron Client UML Diagram
Figure 2: Tron Client UML Diagram