Most users have little or no interest in the underlying technology or structure of the applications they use. They are happy that something works when they click on it, and that things do not go wrong or behave in unexpected ways. If this is you, then read no further — Atomic Scribbler is robust and any issues that might pop up are handled internally and hidden from you.
If you’re of a technical nature and have an interest in the tech stacks used to build software, or simply want to know a little more about the inner workings of Atomic and how it was built, read on. I’ll begin with the basics and delve a little deeper as I progress.
Atomic Scribbler is a modern Windows desktop application. It’s designed to work on lap tops, tablets such as the Surface Pro, and desktops. It can handle high resolution (4K) monitors with ease, works on touch screens, and runs on both 32 and 64 bit architectures. Basically, if you buy a new Windows PC of any variety, Atomic will install and run without issue.
The Structure of an Atomic Scribbler Project
An Atomic Scribbler project is not a single file or document. It’s a folder filled with files and documents, all inter-connected. When you create a new project and choose a location, a folder is created based on the name of your project. The folder name may or may not be the same as your project name, as a project name can contain characters that are illegal in Windows folder names.
Examples. A project named “Huckleberry Finn” will reside inside a folder of the same name. A project named “<<Fred>>” will be placed inside a folder called “Fred”.
A file called atomic.scribbler will sit in the root of your project folder. This will stand out as it has the Atomic logo assigned to it. If you double click this file it will immediately open that project in Atomic Scribbler, bypassing the Project Manager dialog.
There are two key folders inside the project folder: Documents and .atomic. The Documents folder contains a series of documents in Word and RTF formats, each with a number for a name (12.docx, 87.rtf, etc.). When you create a new scene or note, a document is created in this folder to store the contents of that scene. And the best part is, as the formats Atomic uses (Word and RTF) are so common, you can open any of these small documents with Word or any other word processor. Your work is never stored in a proprietary format and can always be recovered — even if Atomic Scribbler is not on the scene.
The .atomic folder contains a meta file which is a miniature database that stores all the connecting information about your project. This includes scene and note names, folder information, hierarchical details that determine which scenes are in which folder, and whether or not a scene is part of your Document or Fragment trees.
Inside the .atomic folder you’ll find a Backups folder. Every time you open a project in Atomic Scribbler, it checks to see if the meta file was backed up that day. If it wasn’t, it makes a backup. Up to 10 days backups are stored here. The purpose of these backups is to give you the ability to roll back to the previous day’s database in the event of any unforeseen issue such as disk or file corruption — rare, but not unheard of.
The meta file is a Sqlite database, which is one of the most common and robust databases in existence. If you use Firefox as your browser, your bookmarks and history are stored in a similar Sqlite database. This is an open source database that has been aggressively tested for many years. If it fails or becomes corrupt, the fault will likely lie with Atomic and not with the database itself.
As with the document storage formats (Word and RTF), use of the Sqlite database for storing information about your project means you are never fully locked in to Atomic. With the right technical knowledge, or with an acquaintance who has that knowledge, you can extract all of your connecting information about your project without needing to use Atomic Scribbler.
A side effect of using a properly constructed database to store so much of your project information is that corruption caused by bugs is kept to a minimum (we have foreign keys and transactions to thank for this). Had we used a series of XML files, as some other writing software does, inconsistent data could have become a problem.
What happens when an error occurs?
Bugs happen, even in the best of applications. They’re a fact of life that cannot be avoided. But, we can mitigate the effect such bugs have on the user and on the Atomic project, and we can make it as easy as possible for us to identify and fix these bugs when they occur.
Here’s an example. Say you’re working on an Atomic project which is stored on a USB drive. After an hours work you forget where the project is stored and unplug the USB drive. The next time Atomic goes to update its database or save your current scene, it will not crash. Instead it will tell you that the project location is no longer there. You can then plug the drive back in, and Atomic should carry on updating the project without incident.
Every time something unexpected happens inside Atomic, a detailed entry is written to the Atomic log file. The more unexpected and severe the incident, the more detailed the log file entry. For the more technical readers, a full stack trace is written for every exception, and every exception is caught at some point.
This is especially important when a bug surfaces. A bug means that something unplanned for has occurred. The above mentioned scenario of you unplugging your USB device can be planned for — a bug cannot, as it will most likely manifest in unexpected ways.
The log file entry is written at this point. When you report a bug to us, we will ask you to email that log file to us. A new log file is created each day, and is written to the “Documents\Atomic Scribbler” folder, with the current date used in its name.
Only log files for the past three days are stored here, so you will never find your Documents folder overly cluttered with log files. After you send us this file, we should be able to pin the bug down to a single line of code, and quickly issue a fix.
More about the tech stack used to build Atomic Scribbler
Atomic is a C# / .Net application. For anyone non-technical who stuck it out this far, this means it was built using Microsoft programming languages and technologies. The user interface elements are composed of the latest Devexpress component suite which allows for a host of usability options we haven’t yet availed of such as skins and themes, Windows 10 tiles (which I hate), and much more.
It was built on a high spec Dell lap top — ideal for coffee shop programming — along with a docking station and two monitors for extended office work. High resolution testing was performed on a Dell XPS (4K) lap top. The code base is stored in an SVN repository courtesy of the guys at Beanstalk. Applications used include Visual Studio 2017, Navicat Sqlite client, Paint.net for image design work, and of course, Atomic Scribbler for writing these blog posts — nothing like Dogfooding to test your own application!
Finally, the Atomic Scribbler logo and splash screen were designed by kerman over at 99Designs, and we have our very own Deirdre to thank for choosing the vibrant orange colour.
The development process for Atomic Scribbler spanned 12 months, with most of the back end written over a 6 week period last year, and the user interface designed and polished sitting in various Starbucks in Dublin from 6:30am-8:30am between May and September of this year.
That’s what it took to build a new product like Atomic Scribbler from scratch. I hope you found the above interesting.