… Or why you want to upgrade! An article by our Software Engineering Director - Klaus Triendl.


Introduction


I personally appreciate stories about products and certainly FireDaemon Pro itself and the FireDaemon Technologies Limited has got one, too! It's been almost 2 ½ years since we started developing FireDaemon Pro 4 and now that it's generally available on a brand new website this big cycle is coming to and end - or better: culminating in a grand release as part of a whole corporate design and product suite effort.

Overview

2 ½ years seems like a very long time - our flagship product FireDaemon Pro 4 appears in new clothes, but what else happened in all those months?


We've been definitely hard at work. By the records of git, the source control system we use, we started development of FireDaemon Pro 4 on 14 April 2016. We initially set out to "modernize" it but we soon realised that we needed a whole new user experience across all our products. Additionally an overhaul of FireDaemon Pro's scheduling feature was long overdue.


So we started from the beginning, and collaborated with a great UI/UX designer, who not only created an astonishing user interface, but also surprised us with new ways of presenting things - given that FireDaemon products are very technical, we think that the workflow is much simpler than ever before. Also, the new UI/UX had to be done both for FireDaemon Pro 4 and FireDaemon Fusion 6.


While we were at it, we took the chance to create a corporate design across all products presented on a brand new corporate website. Looking at the new FireDaemon I would say it has turned into a brand with a characteristic design and a much higher recognition factor. I personally think we ventured and gained!


Now, the modeling and design phase is obviously the most important. However at some point someone has to get their hands dirty, grab the shovel and start digging earth. Usually, Implementing new paradigms requires deep changes to an existing architecture.


This is often also the point where the great designer leaves the development team - we were lucky that our designer went through realising FireDaemon Fusion's web front end at the very least. Last but not least, rounding up the products and customer experience, we've additionally got fast help and high-quality work in regard to documentation (user manuals), knowledge base articles and HOWTOs.

Conclusions

  1. FireDaemon turned into a new and characteristic brand, across a whole product suite plus an appealing website.

  2. All 5 products - FireDaemon Pro, FireDaemon Fusion, FireDaemon Zero, FireDaemon ZeroInput and FireDaemon daeMON - are available as new major versions (meaning with major improvements)

  3. FireDaemon Fusion for web-based services management now fully complements FireDaemon Pro as a desktop application. There will always remain a variance due to different technologies, however users can usually expect the same known workflow, or very similar.

  4. We have put a lot of effort into making the main feature of FireDaemon Pro and FireDaemon Fusion - managing services - not only nice looking but also simpler to use along with a very similar workflow and a nice user experience.

  5. We are actively contributing to the development community:

    1. We created our first open-source library Windows Template Library Extension (wtlext).

    2. We are providing binaries of OpenSSL on Windows.

    3. We are reporting issues of Third-Party tools including Microsoft Visual Studio, and of Third-Party components including the C++ Windows Template Library and the javascript library jsviews. All of them get actively considered and addressed.

Highlights

FireDaemon Pro, compared to its predecessor version 3, is actually a completely overhauled product with improved stability, accuracy and resource consumption. Additionally it contains fixes and many new improvements and appealing features you don't want to miss!


Number of Features

Like all (software) production companies we have a request and issue tracking system in place. Those tickets they directly show what customers will get eventually. Giving a bit of background on how we are working: because we are a small team it is easier to work following the Kanban approach (vs the SCRUM method, which you may heard of). This is basically a pipeline of work, captured in distinct and assigned tickets. Looking at the product board as presented by Jira, there are:

  • 89 Tickets

    1. 58 Features: Those include bigger features (like scheduling) and little improvements (like persisting the sorting column).

    2. 22 Bug fixes

    3. 9 Tasks: Those are tickets which aren't obvious for the end user, however still contribute to the maturity of the software, e.g. related to the installer.

  • By theme (tags), worth mentioning

    1. 19 in regard to UI/UX (new User Interface, new User eXperience), or simply tagged 'usability'

    2. 12 in regard to application monitoring, scheduling and lifecycle management

    3. 8 in regard to 'in-session', i.e. starting an application in the current user's session instead of in Session 0

    4. 2 in regard to (implicit) "log rolling"

    5. 2 in regard to auditing and security


Code Statistics

Since 14 April 2016 to FireDaemon Pro 4's GA release 4.0.57 at the beginning of September 2018 the development team:

  • turned around 161115 lines (text files),

  • … produced 5.5% non-textual (binary) modifications,

  • … of 6696 files in summary,

  • … in steps of 1241 distinct changesets.

This means that we touched 67% respectively 70% of the text part of the original repository, and the changes shape 77% respectively 72% of the 4.0.57 version! We must emphasize that this isn't an automated process or a dumb copy-and-paste operation, but a conscious process. Admittedly, certain move-file operations would be included as well if only referred paths had to be changed; nevertheless restructuring plays a vital role in improving the codebase. All in all everything leads to much better code quality. If you are interested in how the presented numbers come about, please refer to the technical notes below.


Quality

Like never before, we ensure stability and quality of our software by:

  • Tidying up

    • We weeded out code that is irrelevant these days, i.e. for operating system versions prior to Windows XP/Server 2003.

    • Simplifications of working but convoluted code parts. One such example is granting and removing access rights for interactive services in Session 0, which also makes resource exhaustion less likely to happen.

  • Regular code analysis

  • So-called "Unit Tests"

  • Developing with new tools.

The latter isn't too obvious, so let me explain: New tools mean new technologies and new ways of programming or doing "things" (paradigms). Of course new possibilities open a new set of problems, but it also means that everybody benefits of well-tested and impact-notch proof standards the whole world agrees on. Usually new paradigms let one express intent, new tools help in using the clearer paradigms - this makes FireDaemon ultimately more stable and easier to maintain for many years to come!


Highlight Summary

  • The most obvious highlight is the new user interface. The graphics remain crisp under different DPI settings. Design, layout and colors look clean and modern, additionally and most significantly they match FireDaemon Fusion's user interface.

  • In addition to the cosmetic elements, we also strived for better accessibility of regularly used parts and improvements for finding information quickly. The term for this is named User eXperience and also matches FireDaemon Fusion's.

  • FireDaemon Pro comes with a completely new scheduling engine and easy-to-use scheduling user interface. It features multiple schedules and restart or duration schedules revolving around a day or week days.
    In addition, schedules run accurately on time, run accurately in regard to daylight-saving adjustments, and run accurately in case the machine is hibernated.

  • The days of hassles when running many FireDaemon services are gone! In terms of resource consumption it's hard to come up with some numbers, but we have reports of customers who run 350+ self-defined services with ease.

Outlook

I know I am repeating myself again - looking at the new FireDaemon I would say it has turned into a brand with a characteristic design and a much higher recognition factor. Right now the iron is hot. The feature pipelines for our main products are at their high-water marks. FireDaemon Pro 4.1 is already in development and available to Beta testers in need of long requested features. To name a few: Sending custom commands to the application executed as a service, Support for more than 64 processors, Renaming environment variables, Searching the list of services. My guess based on the current situation is: stay tuned :)

Technical Notes

Methodology Used To Determine Percentage Changes 

For those knowledgeable in source control systems like git or simply interested in how the numbers of turned over lines and percentage changes come about, here are the commands and formulae concerning the statistic calculations.

Let us know in case you find logical errors.


Percentages Related To the Previous and Current Repository State

Determining how much of a repository has changed presents a real challenge. There are two different ways of obtaining the percentage of text changes:

  1. The first is relying on an in-stock git command (git diff --shortstat)

  2. The second is by accumulating numbers at the word-level (git diff --word-diff). Unfortunately they yield different results.


  1. Determine the number of total lines@pro4-start:
    git checkout pro4-start^
    git ls-files -z | wc -l --files0-from=- | grep total

  2. Determine the number of total lines@4.0.57:
    git checkout 4.0.57
    git ls-files -z | wc -l --files0-from=- | grep total

  3. Determine the number of

    1. insertions and deletions between 'pro4-start' and '4.0.57':
      git diff --shortstat --find-renames pro4-start^ 4.0.57

    2. added, modified and removed lines between 'pro4-start' and '4.0.57':
      (MOD_PATTERN='^.+(\[-|\{\+).*$' \
      ADD_PATTERN='^\{\+.*\+\}$' \
      REM_PATTERN='^\[-.*-\]$'
      git diff --word-diff --unified=0 --find-renames pro4-start^ 4.0.57 \
      sed -nr -e "s/$MOD_PATTERN/modified/p" -e "s/$ADD_PATTERN/added/p" -e "s/$REM_PATTERN/removed/p" \
      | sort | uniq -c)

  4. => Percentage of changes to the repository at before 'pro4-start'

    1. => 67% = deletions / lines@pro4-start

    2. => 70% = (added + modified) / lines@pro4-start

  5. => Percentage of changes that shape the repository at '4.0.57'

    1. => 77% = insertions / lines@4.0.57

    2. => 72% = (added + modified) / lines@4.0.57


Number of Modifications, Files and Changesets Over Time (code 'performance' metrics)

  1. Determine number of commits, all files, all insertions and deletions accumulated over time
    git log --shortstat --no-merges --find-renames --pretty="%H" pro4-start^..4.0.57 \
    | grep -E "files? changed" \
    | awk 'BEGIN {inserted=0; deleted=0} {commits+=1; files+=$1} $5~/^insertions?/ {inserted+=$4} $5~/^deletions?/ {deleted+=$4} $7~/^deletions?/ {deleted+=$6} END {print "shortstats", "* commits:", commits, "* files changed:", files, "* insertions(+):", inserted, "* deletions(-):", deleted}'

  2. Determine number of commits, text files, textual insertions and deletions accumulated over time
    git log --numstat --no-merges --find-renames --pretty="%H" pro4-start^..4.0.57 \
    | awk 'NF==1 {commits+=1} NF==3 && ($1 || $2) {files+=1; inserted+=$1; deleted+=$2} END {print "numstats", "commits:", commits, "* files changed:", files, "* insertions(+):", inserted, "* deletions(-):", deleted}'

  3. Determine number of added, modified and removed lines accumulated over time:
    (MOD_PATTERN='^.+(\[-|\{\+).*$' \
    ADD_PATTERN='^\{\+.*\+\}$' \
    REM_PATTERN='^\[-.*-\]$'
    git log --shortstat --word-diff --unified=0 --no-merges --find-renames --pretty=oneline pro4-start^..4.0.57 \
    | sed -nr -e "s/$MOD_PATTERN/modified/p" -e "s/$ADD_PATTERN/added/p" -e "s/$REM_PATTERN/removed/p"\
    | sort | uniq -c

  4. => Number of turned-over lines
    => 161115 = added + modified + removed

  5. => Percentage binary change
    => 5,5% = 100% - (text_insertions + text_deletions) / (all_insertions + all_deletions)

  6. => Sum of touched files
    => 6696 = all_files

  7. => Number of changesets (commits)
    => 1241 = commits