Systems engineering is the process of understanding how the different parts of a technical system work together and designing those parts so the complete system works reliably as a whole. My experience has involved systems, software, infrastructure, automation, monitoring, deployment, and the relationships between them.

A systems engineer may work across many different areas rather than being limited to a single technology. My work has included Linux systems, software development, scripting, infrastructure, configuration management, deployment, monitoring, databases, development environments, automation, and integration between different systems.

A problem that appears to belong to one component can actually be caused by something somewhere else. Understanding how information, applications, servers, networks, databases, and processes interact makes it possible to find the actual cause of a problem rather than simply treating its symptoms.

I am particularly interested in how individual components fit together to create a larger system. I enjoy finding relationships between components, understanding how information moves between them, and identifying opportunities to make the overall system simpler, more reliable, or easier to operate.

DevOps brings software development and systems operations together. It involves development environments, source control, testing, deployment, infrastructure, automation, monitoring, and the processes required to move software from development into a reliable operating environment.

My DevOps experience has included maintaining development environments, supporting developers, source control, branching and tagging, automated builds, deployment automation, configuration management, Linux systems, infrastructure automation, monitoring, and developing tools to simplify operational tasks.

Repetitive manual processes take time and introduce opportunities for mistakes. Automation allows a process to be performed consistently and makes it possible for engineers to spend more time solving problems instead of repeatedly performing the same steps.

No. Automation is an important part of DevOps, but DevOps also involves communication between development and operations, understanding the complete software lifecycle, managing environments, deploying changes, monitoring systems, and creating reliable processes.

My development work has included web applications, internal engineering tools, automation utilities, APIs, integration systems, monitoring tools, deployment tools, self-service applications, provisioning systems, and software used to support day-to-day operations.

My experience includes Python, Ruby, Ruby on Rails, Perl, Bash and Unix shell scripting, AWK, SED, JavaScript, jQuery, C# and .NET, HTML, CSS, SQL, and other technologies used for systems, infrastructure, and application development.

Yes. My work has crossed the boundary between traditional software development and systems engineering. Some projects have been complete web applications while others have been scripts, automation tools, APIs, deployment utilities, monitoring systems, or components designed to help engineers operate larger systems.

Existing software is often the right solution, but sometimes a particular problem does not fit an existing tool. In those cases, building a focused solution can eliminate unnecessary manual work, integrate systems that otherwise do not communicate well, or provide functionality that existing products do not offer.

Linux has been a major part of my systems engineering and development work. My experience includes Red Hat Enterprise Linux, CentOS, Ubuntu, Oracle Linux, Linux server administration, shell scripting, Kickstart, package management, repositories, configuration management, web servers, and development environments.

Linux administration involves maintaining and operating Linux systems, including configuration, software installation, users, services, storage, networking, logs, performance, security, troubleshooting, and automation.

Infrastructure automation uses software and scripts to configure, provision, maintain, and manage systems instead of requiring every step to be performed manually. I have used automation to provision systems, manage configurations, deploy software, and support operational processes.

Configuration management provides a consistent way to define and maintain the configuration of systems. Rather than manually making changes to individual machines, configuration can be represented as code and applied consistently across an environment.

Almost any repetitive process that follows a predictable set of rules can potentially be automated. My work has included software deployment, system provisioning, account management, package management, monitoring actions, data integration, reporting, and other operational tasks.

Sometimes. The goal is not necessarily to eliminate people from a process, but to eliminate unnecessary repetitive work. A well designed system can allow people to provide the information or make the decision while the computer performs the predictable mechanical steps.

Repetition, predictable rules, large numbers of similar tasks, opportunities for human error, and processes that require information to move between systems are all good candidates for automation.

Absolutely. Automation is not automatically an improvement. A poorly designed automation system can introduce additional complexity and make troubleshooting harder. Good automation should solve more complexity than it creates.

System integration is the process of making separate applications or systems work together. This can involve APIs, databases, structured data, webhooks, custom applications, or other mechanisms for transferring information between systems.

An API provides a defined way for one piece of software to communicate with another. Instead of a person manually copying information between applications, software can exchange data programmatically.

Yes. I have developed integration tools that accept information from one system, process and transform that information, and produce output suitable for another system. This included integrations using REST APIs, JSON, webhooks, and configurable data transformations.

Organizations frequently use multiple applications for different purposes. Integration allows those applications to share information and reduces the need for people to manually duplicate the same information in multiple systems.

System monitoring involves observing systems and applications to determine whether they are operating correctly. Monitoring can track availability, performance, resource utilization, services, applications, and other conditions that may indicate a problem.

My experience includes monitoring tools and systems designed to provide operational visibility and allow engineers to respond to problems. I have also built tools that connect monitoring systems with automated operational actions.

Yes. A monitoring system can identify a known condition and invoke an automated action when appropriate. For example, I have developed systems where operational tools could trigger actions such as restarting services or changing system parameters.

My experience includes Git, GitHub, GitHub Enterprise, GitLab, Atlassian tools such as Jira, Confluence, Bamboo and Fisheye, ServiceNow, virtualization technologies, development environments, deployment tools, and configuration management systems.

Yes. A significant part of my work has involved creating internal tools that make the jobs of developers, system engineers, NOC engineers, and other technical staff easier.

Engineers often encounter repetitive tasks that are too specific for an off-the-shelf product to solve effectively. A small internal tool can turn a complicated multi-step process into a simple, repeatable operation.

My experience includes MySQL, SQLite, Microsoft SQL Server, and database interfaces used from programming languages such as Perl and Ruby.

Databases are often one component of a larger system. Understanding how applications store, retrieve, transform, and exchange data is important when developing integrations, troubleshooting applications, automating processes, or designing systems.

The Oasis Datacenter Portal was a centralized internal system designed to provide an accessible view of datacenter information, synchronize information from multiple sources, support reliability monitoring, and serve as a hub for system automation and internal reporting.

The provisioning system automated the process of onboarding new customers and provisioning new hardware or virtual machines. Information supplied by project managers could be used to generate hostnames and IP information and feed the resulting information into an automated provisioning workflow.

The change management system was designed to track modifications within a production environment while providing automated workflow and reporting capabilities.

The GitHub self-service portal automated portions of the process of creating and managing GitHub accounts. It incorporated approval workflows and automated account changes that would otherwise have required engineers to perform repetitive administrative tasks manually.

Cinnamon is a static website generator that I built to organize website content, metadata, navigation, reusable components, and page generation. It reflects the same approach I have used throughout my technology work: understand the problem, identify the repetitive pieces, and build a system that handles them consistently.

This website was designed and built from the ground up. The HTML, CSS, JavaScript, page structure, and supporting software were originally written by me rather than being assembled from a pre-built website template or conventional website builder.

The current website began as a ground-up redesign in 2022. It was intended as a modern evolution of my earlier Baltimore Hypnosis Center website, which I operated from 2005 through 2009 in Gambrills, Maryland.

Archive of The Baltimore Hypnosis Center Website

Yes. The original HTML, CSS, JavaScript, page structure, and website-generation code were written by me.

More recently, I use AI models such as ChatGPT as development assistants. AI can help me troubleshoot code, explore approaches, refactor software, explain unfamiliar behavior, and generate or modify pieces of code. However, the architecture, requirements, design decisions, and underlying systems are mine.

AI is now part of my development toolbox, but it did not create the foundation of this website.

No. This website was not built using WordPress, Bootstrap, React, or a conventional visual website builder. I prefer to have direct control over the HTML, CSS, JavaScript, content structure, file organization, and generation process.

Because nearly twenty years of web development happened between them. The original Baltimore Hypnosis Center website was built for a very different web, with different browsers, screen sizes, CSS capabilities, JavaScript support, search engines, and development practices.

The current site is a ground-up redesign rather than an attempt to preserve the old visual design. What has remained consistent is the philosophy of building the website myself, controlling the underlying technology, and automating repetitive work.

The Baltimore Hypnosis Center website was the website for my hypnosis practice, which I operated from 2005 through 2009 in Gambrills, Maryland.

An archived version of the website from 2007 is preserved by the Internet Archive. Comparing that site with the current Adam Fistler website provides a useful illustration of how my web development work and technology have evolved over nearly two decades.

Archive of The Baltimore Hypnosis Center Website

I maintain the website using a custom static-site generator called Cinnamon.

Cinnamon sits somewhere between a content management system and a website compiler. Instead of manually maintaining every generated HTML page, I maintain source content, templates, metadata, configuration, reusable components, CSS, JavaScript, and other source files. Cinnamon processes those pieces and generates the finished static website.

This allows me to make changes at the source level and regenerate the site rather than manually editing the same structures over and over again.

Cinnamon is a custom Python-based static-site generation system that I built specifically to manage and generate this website.

It is more than a simple HTML generator. It provides a structured way to manage page content, metadata, configuration, reusable components, navigation, templates, and other parts of the website while producing static HTML as its final output.

Cinnamon did not begin as Cinnamon. It evolved from a much smaller Python program called html_gen.py.

Originally, html_gen.py had a relatively simple job: take an HTML template, combine it with page-specific HTML and contextual information, and produce an HTML page.

As the website became more sophisticated, I kept encountering repetitive problems. Instead of solving each problem manually, I kept extending the generator. Features that were initially hard-coded gradually became configurable and reusable.

Over time, the small HTML-generation script evolved into a much more extensible system for managing the structure and construction of the website. That system eventually became Cinnamon.

A traditional content management system manages content and uses that content to produce web pages. A compiler takes source material, processes it according to a set of rules, and produces another form of output.

Cinnamon has characteristics of both. I maintain the source of the website in a structured collection of files. Cinnamon processes those files, applies templates and configuration, incorporates reusable components, and produces the final static HTML that is served to visitors.

"Static-site generator" is technically accurate, but "a cross between a content management system and a website compiler" is a better description of what Cinnamon has become.

Because I wanted the website to work the way I wanted it to work.

There are many excellent static-site generators and content management systems available, but building my own gave me complete control over the architecture. It also allowed me to solve problems in ways that made sense for this particular website rather than adapting my workflow to somebody else's framework.

Cinnamon also reflects something I have always enjoyed about systems engineering: taking a repetitive manual process, figuring out the underlying pattern, and turning that pattern into a reusable system.

Static HTML is simple, fast, portable, and reliable. There is no database that has to be queried every time somebody visits a page, and the web server does not have to dynamically construct the page for each request.

The generated files can simply be served directly by the web server. I also retain the complete source material and generation process rather than placing the entire website inside a proprietary publishing platform.

Not exactly, although it has some characteristics of one.

A traditional content management system generally provides a database, administrative interface, publishing workflow, user management, and other infrastructure for managing content.

Cinnamon takes a different approach. The site's source material exists as files, configuration, metadata, templates, and reusable components. Cinnamon processes those inputs and compiles them into a collection of static HTML files.

Yes, although "written from scratch" does not mean that I refuse to use existing software.

The site runs on established technologies such as Python, HTML, CSS, JavaScript, Linux, Apache, and other open-source software. What I mean by "written from scratch" is that the website's design, content architecture, templates, generator, components, and supporting code were developed specifically for this site rather than assembled from a pre-made website theme or commercial site builder.

The technology has evolved considerably. My early websites were essentially hand-written HTML. As the amount of content grew, I began writing scripts to automate repetitive tasks. Those scripts eventually evolved into html_gen.py, which combined templates and page-specific content.

From there, the system continued to grow. Things that had originally been hard-coded became configurable. Reusable components were added. Page metadata became more structured. Site configuration became separated from individual pages. The generator became capable of understanding more of the site's structure.

Cinnamon is the result of that evolution.

No. The foundation of the current website predates my use of generative AI.

The ground-up redesign began in 2022, and the original site architecture, HTML, CSS, JavaScript, and Cinnamon development were done without AI coding assistants.

I now use AI models such as ChatGPT to assist with programming, debugging, research, brainstorming, documentation, and refactoring. I think of AI as another development tool within an engineering process that I already had.

I did not ask an AI to build me a website. I built a website and eventually began using AI to help me build and maintain it.

Yes. Cinnamon is not a finished commercial product with a specification that was designed years ago and then frozen in place. It continues to evolve as I find new things I want the website to do.

The architecture is therefore also a record of the problems I have encountered and the solutions I have developed for them. In that sense, the website and the software used to build it are both ongoing engineering projects.

Yes. Comparing the archived Baltimore Hypnosis Center website with the current Adam Fistler website is probably the best way to see the evolution.

The 2007 site represents an earlier generation of my web development work. The current site represents nearly two decades of additional experience, changing technology, and increasingly sophisticated automation.

The old site shows where I started. The current site shows where that process has taken me.

Archive of The Baltimore Hypnosis Center Website

I start by trying to understand the problem and the system around it. I look at how information moves, what components are involved, what is being done manually, where failures occur, and whether there is a simpler way to accomplish the desired result.

Yes, but simple does not necessarily mean small or simplistic. A good solution should provide the functionality required without introducing unnecessary complexity. Sometimes the simplest solution is a small script. Other problems require a complete application or system.

Much of my work has involved connecting things together, removing repetitive manual processes, making complicated systems easier to operate, and building tools that allow people to accomplish tasks more efficiently.

Building something is a way of understanding a problem at a deeper level. I enjoy taking something complicated, figuring out how its pieces work together, and turning that understanding into a system that actually does something useful.