Hi there! I’m Nicole Ciemniak, a curious, creative Full-Stack Developer with a drive to produce great things.

Text Editor Tool

During my time at the Zooniverse, I co-led the development of the back-end API for the ALICE Text Editor Tool. ALICE allows researchers to review and update transcription data from projects such as Scribes of the Cairo Geneza and the Anti-Slavery Manuscripts. Using ALICE’s interface, researchers can view the collection of transcriptions made for each line of text in a document and choose which will be used for the final transcription, as well as view consensus percentages for each line. ALICE also provides an option to export the final transcription (or all transcriptions in a project) once the data has been reviewed.

The API was built using Ruby on Rails, and uses PostgreSQL 11 as its database. The main focus of my work on this project was on the data exports and model locking functionality, along with minor functionality such as sorting/filtering and serializing transcriptions.

• Generate a set of export files for a transcription when the transcription status changes to “approved” (when a transcription is approved, users are no longer allowed to make changes). Export files are created as temporary files, then uploaded to Blob Storage using Rails Active Storage.
• Files are removed from Blob Storage when transcription is changed from “approved” to another status, such as “in progress.”
• Add option to download export files by project, workflow, or transcription group. All relevant files are downloaded from Blob Storage into a temporary directory, zipped, and then made available to the client.
• Allow exporting only for users with editor or admin roles for the given project.
• See data exports code here.

• Add attributes to save the username of the user currently updating the transcription (“locked by” user) as well as a “lock timeout” timestamp, which is set by default to be 3 hours from the point when the transcription is initially locked
• Expose an API method to lock a transcription. This method gets called by the front-end whenever a user opens a transcription for editing, and only locks the transcription if the user has editor permission.
• Expose an API method to unlock a transcription. This method gets called by the front-end when a user navigates away from a transcription or closes the web browser.
• Serialize “locked by” user, such that the “locked by” username is displayed on the transcription list view page, and team members know who to contact when a transcription is locked.
• See model locking code here.

Mapping Visualizations Tools

The Mapping Visualization Tools app was created to visualize temperature data on giant kelp forests for the Floating Forests citizen science project. The Floating Forests team used Zooniverse’s platform to analyze Landsat satellite images with the help of hundreds of Zooniverse volunteers, thus gathering temperature data on multiple kelp forests across the world. With the completion of the data collection, the Visualization Tools app was built in order to help the researchers analyze and interpret the final datasets.

As the lead back-end developer for the project, I created a new database on Zooniverse’s PostgreSQL database server to store project data, loaded up the existing project data, and configured an Azure Functions app to connect to the database. The Azure Functions API endpoints allow data to be requested for a specific area of the map, specified by a latitude and longitude range. These endpoints are used by the front-end app to visualize the data.

You can check out the app overview page on Github for more information about the project as a whole. You can also view the code for the Azure Functions app and the database configuration on the back-end app github repo.

Tools:
– Azure Functions
– Node.js
– PostgreSQL
– Yarn
– Docker

Azure Media Adapter

One of the features that I built out while working with the Zooniverse team was the Azure Media Adapter, which was part of the larger effort to migrate all data from from AWS to Azure (see more about the data migration here). The existing code around media storage was written using the adapter design pattern in order to make it easy to switch service providers without needing to change the code in every place where a media file is retrieved/modified/etc.

• Code to generate the path where the file will be stored within the relevant Azure Blob Storage container. Files are stored based on the environment, medium type, and whether the medium is public or private, and each is given a unique identifier
• Code to upload the medium to blob storage, which involves generating a URI with a Shared Access Signature that gives our API the permission to access the blob storage container
• Code to generate a URI that will provide read access to an existing medium
• Code to delete a file
• Code to translate old AWS stored paths to the correct Azure path

The Azure Adapter code was largely built upon the ‘azure-storage’, ‘azure-storage-blob’, and ‘azure-storage-common’ ruby gems.

Check out the code here.