1. Jayse Farrell
(360) 550-7243 | jaysef2@uw.edu | www.linkedin.com/in/jaysefarrell | www.github.com/sike417
Education:
Bachelors ofComputer Science & Software
Engineering
Expected – December 2017
University of Washington – Bothell
Associate in Arts and Science June 2015
Everett Community College
TechnicalExpertise:
Languages:
Comfortable using:
C++, C#, and Java
XAML
HTML/CSS
JavaScript
Experience using:
Python
Bash, Perl
68k assembly
SQL
Engineering Software:
Visual Studio
Git (Github, BitBucket)
Source Tree
Jira
Frameworks:
UWP (Universal Windows Platform)
WPF
Angular JS
Operating Systems:
Windows/Windows Mobile
Linux
APIs:
WIC (Windows Imaging Component)
OpenGL/WebGL
Additional Technical Expertise:
Strong Debugging Skills
Technical Writing Skills
Experience Writing Software Design Documents
Personaland Academic Projects:
Unix File System May 2016 – June 2016
Designed and developed a Unix-like file system for an Operating System simulator, ThreadOS, in Java.
Implemented the ability to handle eight system calls:
1. Format the disk
2. Open files for read, write, read/write, and append
3. Read a specified number of bytes from a desired file, starting at the position of a seek
pointer
4. Write the contents of a given byte array to a file starting at the position of a seek
pointer
5. Updates the position of the seek pointer
6. Close a file, and commit all changes
7. Deletes a file
8. Identify size, in bytes, of a file
Implemented the system calls using the following structures:
2. 1. Superblock – keeps track of all OS level information: total number of disk blocks,
total number of files, and a pointer to a linked list of free disk blocks. Responsible for
issuance and receipt of available disk blocks, and formatting of the disk.
2. Inodes – keeps track of information related to each individual file: size of the file,
number of references to the file in the system table, whether the Inode is being used,
and a catalog of the various blocks in use by a file.
3. Root Directory – allocates Inodes for newly created files, frees Inodes of deleted
files, keeps track of which Inode are free,and which Inodes correspond to which
files.
4. File Structure Table – Define a vector in memory that accounts for each file that is
opened by a thread. Each open file, and open type, is tracked as an instance of File
Table Entry.
5. File Descriptor Table – Unique to each thread keeps track of which file table entries
have been allocated for that thread, i.e. which files the thread or its parent thread have
opened.
6. File Table Entry - Define an ADT that manages specific flags/semaphores that are
used to check for open file conditions.
Disassembler1 February 2016 – April 2016
Developed a disassembler for the 68k assembly language, including a primitive User Interface
Implementation was broken into three different aspects
1. Input/Output
2. Decoding of Operation Codes
3. Decoding of Effective Addresses
Responsible for decoding of operation codes,and some of the Input/Output
Worked within a team to design, develop, test, and debug the Disassembler
Handled twenty-two different operations, using up to eight different addressing modes
X-Ray Machine Simulator23 November 2016 – December 2016
Using images taken from Zygotebody.com,created a webgl-powered site that allows for the direct
manipulation of a human body with the following features:
Ability to rotate most traditional body parts: feet,shins, thighs, hands, forearms, biceps, and
head
Ability to move the entire body around the screen
Ability to swap between an internal - bones, organs, and the vascular system – view, and an
external skin level view
Ability to enable an x-ray viewport to show a small portion of the non-visible view type,
external or internal
CSS448 Programming Language Translator April 2017 – June 2017
Wrote a Translator for a custom-built programming language for my Compilers course that was designed
to be able to read in source code written in the CSS448 Programming and translate it to an intermediate
language that would then be consumed and ran by a provided Interpreter. The Translator produces this
intermediate language by passing through severalstandard phases of a compiler:
1 Source Code: https://bitbucket.org/sike418/disassembler
2 Project Demo (only works on Google Chrome):
http://courses.washington.edu/css450/2016.Fall/FinalProjects/7.Jayse+Alex+Stan/AppSrc/XRayMachine_Final/publ
ic_html/index.html
3 Source Code: https://github.com/sike417/XRayMachine
3. 1. Lexical Analyzer: breaks the source code into a series of tokens. These tokens contain the line
and character number,the actual string that was observed, and some semantic information about
what type of token was observed.
2. Syntactic Analyzer: parses the tokens produced from the lexical analyzer and converts them into
an Abstract Syntax Tree (AST). Records points where the current token does not match the
general type of token that was expected.
3. Semantic Analyzer: a component designed to walk and decorate the AST using a symbol table.
This component is used to determine whether the order of observed tokens makes semantic sense.
Errors that would be caught by this component include:
a. Type conversion errors
b. Using undeclared variables and methods
c. Passing too many or too few parameters to a method.