The email

Hi XX

Naturally in TimeLog, we register our own time. 

For you personally, and together with your immediate manager (me), we do this primarily for the following reasons: 

• We can evaluate if you end up using your time on the right things according to our plan and priority (for TimeLog and for your personal growth)
• We can evaluate if your balance between working and taking time off matches our expectations (in general your norm hours)
• We can keep track of your vacation balance and requests for vacation 

For all, if we together identify that it’s not as we expect, we can address this and mitigate it for the future. I will not use it for pointing fingers (unless you are complete off the charts, which in essence means that I have failed to catch it early and work with you to improve). It’s a tool for finding the right balance. This only works if you register the actual hours you work! I rather want to have an open discussion of “why you needed to work 60 hours in a given week” or “why you ended up with 25 hours in another” than a picture perfect 100% norm time registrations that does not fit with reality. I encourage flexibility, and that only works if we see the same picture.

For TimeLog, we use for other reasons as well:

• We evaluate if we use the hours we expected on projects. Budget vs. realized.
• We evaluate which projects are profitable (internal projects can also have cost and financial upsides)
• We calculate work-in-progress financial project value that are required for financial reporting

My philosophy is simple. If we satisfy the boxes above, I want it to be as simple as possible. It needs to be easy to track time. I don’t want to break something down in smaller pieces that I will never want to report on.

The science is clear, register your hours as close to real-time as possible to make them more accurate. Use the desktop and mobile apps to be efficient. At the very least do it daily  Submit your timesheet every Monday before 10AM CEST.

Having said that, the following projects in TimeLog “local” (our own instance of product) are necessary for you as part of Team Platform right now:

• _TIM – Team Platform 2022 (P22.0086) – for work related to our team
• _TIM – R&D Scrum 2022 (P22.0002) – for scrum related tasks. However, as we use Kanban, it’s primarily for the shared sprint review meetings
• _TIM – R&D Administration 2022 (P22.0003) – for hours not covered above
• _TIM – R&D Internal IT 2022 (P22.0004) – if you end up doing regular IT support. Primarily used for Team Automation, but we want to be friendly for non-techies
• _TIM – Administration 2022 (P22.0010) – specifically the “Mail handling” task
• _TIM – Support 2022 (P22.0039) – the goal is that we don’t use this because everything we do is in backlogs. However, the world is not perfect, so register time here if you are pulled into it

You can add comments on time registrations. They are optional. I encourage you to add short context comments e.g. “Talk with SOX”, “BI 23563” in case we want to dive deeper.

When you are getting involved in other projects, they will have specific projects to register on. Ask if in doubt.

Feel free to copy it, if you see it could make sense in your context. If you change anything, I would love hear about your changes so I can learn.

I needed a CSV export of the name, current version, license URL and possibly the actual license name (e.g. MIT License, Apache License). I ended up extending the solution by Dominik.

### This script only works inside the Package Manager Console in VS
### Make sure the /license/ folder exists

$output = @()

# Find all unique packages across all projects
@( Get-Project -All | Where-Object { $_.ProjectName } | ForEach-Object {
    Get-Package -ProjectName $_.ProjectName # | ? { $_.LicenseUrl }
  } ) | Sort-Object Id -Unique | ForEach-Object {
  $pkg = $_;
  Try {
     
    #Write-Host $_.Id
    #Write-Host $_.LicenseUrl
    #Write-Host $_.Version

    $licenseUrl = $_.LicenseUrl

    if ($licenseUrl -eq $null) {
      $licenseUrl = ""
    }

    if ($licenseUrl.contains('github.com')) {
      $licenseUrl = $licenseUrl.replace("/blob/", "/raw/")
    }

    $extension = ".txt"
    if ($licenseUrl.EndsWith(".md")) {
      $extension = ".md"
    }
    if ($licenseUrl.EndsWith(".html")) {
      $extension = ".html"
    }

    $filePath = (Join-Path (Get-Location) 'licenses\') + $pkg.Id + $extension;

    # Only download if it doesn't already exist
    if ((Test-Path -Path $filePath) -eq $false -and $licenseUrl.Trim() -ne "") {
      try {
        #Write-Host("Downloading... " + $licenseUrl)
        (New-Object System.Net.WebClient).DownloadFile($licenseUrl, $filePath);           
      }
      Catch [system.exception] {
        Write-Host($pkg.Id + " FAILED");
      }
    }

    # Don't try to parse the HTML files, the first line doesn't include the license name anyways
    if ($extension -ne ".html" -and (Test-Path -Path $filePath) -eq $true) {
      $textLicence = Get-Content $filePath | Select-Object -First 1

      # Extensionless URLs might be HTML after all, so let's handle that
      if ($textLicence.Contains("html")) {
        $textLicence = "-"
      }
    }
    else {
      $textLicence = "-"
    }

    # Build a better output format for CSV
    $output += [pscustomobject]@{
      Name    = $pkg.Id;
      Version = $pkg.Version;
      Url     = $licenseUrl;
      License = $textLicence.Trim()
    }

    Write-Host($pkg.Id + " processed");
  }
  Catch [system.exception] {
    Write-Host ($error[0].Exception);
    Write-Host ("Could not read license for " + $pkg.Id)
  }
}

$output | Export-Csv -Path licenseoutput.csv

The actual licenses are stored in the /licenses/ folder if required. Nuget packages without a specified license URL will be included in the list, but with empty license details.

So why build a career ladder in the first place? To make it very visible how to progress, gain experience and grow in our R&D organization. Most people strive to advance in their career over time, but it’s not always easy to know what is expected from each individual to progress, and the technical leadership might not even know – or at least it’s subjective and implicit. We have decided to spend the time to carefully craft a career ladder to clearly set the expectations for our technical crew at each level. In effect, we are defining what a great engineer does, and what he/she is, for us. Naturally, this could vary based on the company culture and leadership, but after looking into what other companies have done, it aligns quite nicely. For example, we found inspiration in the published ladder from the team behind Rent the Runway, the engineering career framework from Buffer and engineering career development at Etsy. Also the blog by Chuck Groom and a talk by Marco Rogers is good input for crafting the ladder.

I would have likes even more examples, so I have decided to share ours for others to get inspiration from. The TimeLog Career Ladder for Engineers ended up like this:

We ended up with 7 different positions, each of them defined as the scope of influence, how work is conducted (and expected) by the role, the hard competencies required, anti-patterns that a developer at a given level shouldn’t have and finally which kind of ownership is expected.

Apart from being a great alignment tool within the department, I also see this a great tool for the technical leadership to pin-point each developer within the matrix and figure out which elements to coach and nurture. Naturally, these items can also be added to each developers’ IPM (individual performance management) plans as action points to enhance on.

Another great benefit is that the career ladder also clearly sets the scene for discussions about promotions. Well in advance, a developer can prepare for negotiating a promotion based on the ladder – naturally other things might factor in as well, but you get the idea. By introducing a career ladder with this level of details might also cause developers to transition up and down from their current title, so I suggest to validate it carefully before making it public. In TimeLog, none of our developers needed to transition as part of introducing this, but we have got a more clear understanding of who under- and over-performs based on their current level from an objective point of view. Both cases gives great material to grow each developer to new levels. Another interesting experience is, that we now see how some colleagues at the same level, wildly differ in strengths, which fortunately correlate with their personalities.

To make it a more visual experience, we have attempted to flag/color each statement that is either not met or require coaching based on each individual in an Excel spreadsheet. Below is the results on myself (it’s blurry by design, but you may correlate with the ladder itself, it you find the need).

An interesting fact is that each individual might have a shape of flagged cells. Consider a developer which conducts work as expected according to his/her role as well as having the right competencies, but a lot of anti-patterns flagged. An inverse L shape. Or a developer with no anti-patterns and conducts work as expected, but lacks competencies. An upside-down T. Which one do you prefer? Competencies can be taught, anti-patterns require behavior change.

One thing we noticed during this flagging exercise was that a few of the anti-patterns changed scope based on the anticipated level of developers. For example, the demands behind “Disregards opportunities where he or she can have a positive impact” is very different from Tech Lead to Software Engineer III. In any case, we decided to stick to this model for now and then evaluate after using it for a while. After all, it’s just one tool in toolbox to align and grow developers.

I hope this gives some inspiration into creating your own career ladder. I would love to hear feedback and get questions about this.

In the beginning it have worked for us to setup alerts when space is getting low and the using the API to manually delete old months, but as our Elastic cluster becomes a first class citizen in our IT infrastructure and strategy, we need to automate and follow stricter processes for ensuring up-time and data availability based on business demands. TimeLog hosts the Elastic cluster in AWS and (for now) we are only using it for log data for analysis. This means that we only store time series data and all of our indices will at some point be old enough to delete them all together.

I took a decision early in the adoption of the ELK stack, to name the indices with a named prefix and a date post-fix to easily identify those indices that could be deleted. Example of our indices are therefore: “iis-20190926”, “metricbeat-20190924” etc.

With the standard Elastic API, I can easily query the list of indices and delete those of a certain month.

GET {elastic_url}/iis-*/_stats
DELETE {elastic_url}/iis-201906*

However, having to keep monitoring the storage requirements before it is too late. And trust me, you don’t want to max out the storage. I ended up creating a completely new Elastic cluster and migrating to that, because I failed to believe that after over 24 hours of “reconfiguration…” status in AWS trying to add more storage that this would ever work. It did eventually, but by that time I already migrated. In any case, I have setup the following alarms in AWS CloudWatch:

FreeStorageSpace <= 2500 for 3 datapoints within 15 minutes
ClusterIndexWritesBlocked >= 1 for 1 datapoints within 5 minutes
JVMMemoryPressure >= 80 for 3 datapoints within 15 minutes
ClusterStatus.red >= 1 for 1 datapoints within 5 minutes
CPUUtilization >= 80 for 3 datapoints within 15 minutes

I put together that set of alarms following the recommendations from Amazon.

But enough about the general setup, I wanted to automate the clean up. First I looked closer at Curator to figure out if that was a good fit for me. But for the time being it wasn’t, the step into Python and AWS Lambda was not a route I wanted to pursue. Instead I did a fall back to Powershell. The idea: Define a function where I can provide the prefix and the days to keep indices and then it will look up all the indices with a specific prefix, then parse the date in the name and delete based on that. This is the script I ended up with:

$elasticUrl = "https://*.es.amazonaws.com"
$today = Get-Date

Function CleanElasticIndices($prefix, $daysToKeep) {

    $listIndicesUrl = ($elasticUrl + "/" + $prefix + "-*/_stats")

    Write-Host ("Fetching data from: " + $listIndicesUrl)

    $jsonIndices = Invoke-WebRequest -Method Get -Uri $listIndicesUrl -UseBasicParsing | ConvertFrom-Json

    $indicesKept = 0
    foreach ($index in $jsonIndices.indices.PSObject.Properties) {
        
        $indexDateString = $index.Name.Substring($prefix.Length + 1, $index.Name.Length - $prefix.Length - 1)

        [datetime]$indexDate = New-Object DateTime
        if ([DateTime]::TryParseExact(  $indexDateString, 
                                        "yyyyMMdd", 
                                        [System.Globalization.CultureInfo]::InvariantCulture,
                                        [System.Globalization.DateTimeStyles]::None,
                                        [ref]$indexDate)) {
            if ($indexDate -le $today.AddDays(-$daysToKeep)) {
                Write-Host ("Examining the index: " + $index.Name + " => " + $indexDate.ToShortDateString() + " => Attempting delete... ") -NoNewline
                $indiceDeleteUrl = ($elasticUrl + "/" + $index.Name)
                $deleteResult = Invoke-WebRequest -Method Delete -Uri $indiceDeleteUrl -UseBasicParsing
                Write-Host $deleteResult

                Start-Sleep -Seconds 2
            } else {
                Write-Host ("Examining the index: " + $index.Name + " => " + $indexDate.ToShortDateString() + " => keep")
                $indicesKept = $indicesKept + 1
            }
        }
    }

    Write-Host ($indicesKept.ToString() + " """ + $prefix + """ indices kept on Elastic")
}

CleanElasticIndices "iis" (18 * 7) # 18 weeks
CleanElasticIndices "metricbeat" (2 * 7) # 2 weeks

Add it to a scheduled task on a Windows box executing every day then you are good. Until the daily volume increases to a level to make the AWS CloudWatch alarms to go off again. Then you are back to the initial question: Increase storage or reduce data retention?

I started our Elastic cluster as a proof of concept that now have turned into production use. On that journey, I have taken the time to define the definition of each index type and the related retention policy. Each the indices are defined with:

• Index name (the prefix)
• Friendly name
• Description (business value)
• Retention policy (in weeks)
• Estimated number of entries per day
• Estimated size increase per day

The estimations will allow you to bridge over to the money aspect and only argue about long term retention on indices with high daily storage demand. All in all, it makes it easier to communicate to the leadership team the value it brings, hence ensure funding. Assuming that you are actually using the cluster for something delivering business value in the first place

TimeLog have various APIs and have had them for years. However, we want to enhance our abilities and (finally) move to a REST-based API. We believe that our API will grow more rapidly in the future, so we need to consider more carefully how to versioning our API – especially due to our nature of being a single-tenant app.

One of my recent initiatives as Tech Lead is, that I have started to build our definition of “Tech Nirvana” in TimeLog. An (for now) internal website gathering all our discussions and putting into short numbered rules categorized in manifestos and style guides across the different areas we operate in. Only technical stuff and focused on why-documentation – another blog post about that at another time.

In any case, I have worked with one of my colleagues to craft the conventions we need for ensuring that our mobile app offering (Android and iOS) can function well (almost) no matter which of our single-tenant apps they are trying to access. The API style guide have a number of sections, but the notable ones for this exercise is REST API Conventions and API Consumer Conventions.

I hope this can be used for inspiration for others – also in a multi-tenant environment.

API03: REST API Conventions

API03.1:After a method has been released, method names, input parameters and the general output structure MUST NOT be changed in any form.

Because consumers of the API should not have to update their solution due to our changes.

API03.2:After a method has been released, additional optional input properties and output properties MAY be added.

Because consumers SHOULD NOT care about new elements. General renames and/or adding required fields will break existing solutions so these MUST NOT happen.

API03.3:If API changes violate either API03.1 or API03.2, we will always bump the API version number – and implement necessary internal backwards compatibility into existing API versions.

Because it allows existing integrations against our API to continue to work. For example, if a new required field is added, then for earlier API versions we automatically (internally) set a good default value to cope with the lack of API consumer input.

API03.4: API version and TLP version are not supposed to follow each other.

Because the API only needed to be increased based on API03.3. However, new functionality and other additions will follow the TLP version which will increase the version each week.

API04: API Consumer Conventions

API04.1:All API consumers MUST adopt an upgrade-only distribution pattern.

Because of the nature of app stores, this is inherently required for Play Store and Apple Store. A user can only download the latest version of the app, so we need to cope with that limitation for all our API consumers to make our integrations as homogenous as possible.

API04.2:Testing API consumers SHOULD target the latest TLP version and API version only.

Because we upgrade all (latest TLP version) TLP sites at more or less the same time, and under 2% are held back for various reasons for a shorter period of time. Most of the time our web-app will be of a more recent TLP version than the API consumer targets.

API04.3:API consumers (that targets an unreleased TLP version) SHOULD support at least the latest two TLP versions.

Because internal API consumers might be required to release before the general TLP release, e.g. for app stores to ensure close-to-same release date of app and TLP but due to the nature of app stores, we cannot count on it. API04.4 would solve most issues, but e.g. for personal settings those are hard. If required by PO, we should add a else-statement with a message to the user that the functionality they turned on is not available yet.

API04.4:Favor using the hypermedia structure to decide if a UI element or feature should be available over hardcoding display rules.

For example, only show the “Expenses” tab (in the mobile apps) if link:Expenses is available from the root hypermedia note. This allows the server to control UI behavior (e.g. due to TLP versioning, licensing og setting constraints) in the applications without having to redo the apps. Another benefit is that the API consumer is backwards compatible (when targeting older TLP versions) for most use cases.

API04.5:API consumers SHOULD assume that features and functionalities are default off (until the hypermedia tree tells otherwise).

Because we want to ensure that the app works even when targeting different TLP versions. In general, defaults should be implemented at all levels.

API04.5:Favor preloading content in the background over lazy loading content. If preloading fails, lazy loading SHOULD kick in.

Because for mobile apps in particular requests take time, so if we can load data in the background the user gets a better experience.

The peaks at TimeLog happens around month end where our customers build invoices based on the time registrations, and even more so in January where our customers analyses the last year and consolidating numbers to their ERP. Additionally, we see peaks when salary managers work out vacation and salary compensation packages.

Microservices are still a hot topic, and for good reasons. I have used a couple of days venturing into the possibilities of TimeLog utilizing microservices and a message queue to break down our monolith – or at least release it from some of its burdens. To be honest, I don’t see us breaking our monolith in the foreseeable future, and right now I don’t think we need to. More about that later.

Firstly in order to scale outside the actual application, we need a reliable message queue. This is the enabler for microservices. The message queue serves as a communications channel as well as a buffer. We put messages on it, it stores them for a given period of time and we can read messages from it and carry out the work. Service Bus, Message Queue, Distributed Streaming Platform, Event Hub, Event Grid. It comes in various flavors, each with different capabilities and options. There are a few terms that I found useful to describe:

• Events – Lightweight, a notification that something happened, no expectation on how it is handled, primarily for telemetry and data streaming
• Messages – Raw data, fixed expectation on how it is handled, primarily for transactions
• Topic – Categorizing messages/events in the queue
• Partition – Logical categorization on the server

As TimeLog is mainly driven by Microsoft technology, it was naturally for me to start looking into the possibilities in Azure. Microsoft have documented nicely how to compare the different messaging options. Summarized: Azure Event Hubs are for events (fast, at least once, no sorting), Azure Event Grid is for events (serverless, at least once, no sorting) and Azure Service Bus is for messages (heavy on config, but has all options). For completeness, Apache Kafka is for events. A found a few good comparison posts.

There are a few interesting attributes to consider for a message queue:

• Messaging guarantee – At-least-once delivery is the supported by all the services and is easy to understand. This should also work for TimeLog.
• Ordering guarantee – Default is no ordering, only the Azure Service Bus supports it native. My natural response would be that ordering is needed, however, it strikes me that it might only be because it is the same assumptions our monolith works under. In any case, if the default is no ordering, TimeLog would need to work with that premise.
• Throughput and latency – With the amount of messages/events I anticipate, then none of these two are an issue. I would probably see the processing being the bottleneck instead.
• Persisted storage – Up to 7 days for Azure Service Bus. I would assume that TimeLog would never need so long, customers expect data to be processed way faster anyway.
• Message size – The lower the better. Azure Service Bus recommends between 10 and 256 KB. It is not for data, it is for messages.

Azure Service Bus seems to be the tool for the job in our case. However, it is important to figure out which characteristics a microservice needs to fulfill to work in this environment. Pulling a bit from the AWS definition: Decentralized, independent, do one thing well and a black box. Additionally, idempotent would also be a nice property especially in a at-least-once delivery model as well as in no-ordering guarantee system.

In the traditionally sense, a microservice handles data/functionality for a particular bounded context. This means that it exposes both reads and writes API endpoints to its consumers. As I mentioned earlier for TimeLog, I don’t see us breaking up the bounded contexts just yet, but we could break functionality and let microservices handle part of the work load. This leads me to this definition:

• Microservice = The actual functionality we need (within a certain bounded context)
• A node = An instance that executes the functionality (multiple nodes doing the same thing should be possible)

This got me thinking that we would need to gradually move into this:

• 1. generation: Calculation-nodes
• 2. generation: Bulk-nodes
• 3. generation: The Real Microservice(tm)

Calculation-nodes requires the type of action and the simple input of an ID of the domain it needs to aggregate or calculate based on. It will fetch the data it needs from the database to do the calculation and manipulate the records the calculation affects. Idempotent at its core. Duplication: Fine. Out-of-order: Fine. Outage: Retry.

Bulk-nodes requires the type of action, a list of IDs to process and parameters for the operation. Like with the calculation-node, it fetches the data it needs and starts performing the necessary action and manipulates the records according to the parameters. Only idempotent if the actual implementation allows it. Duplication and ordering now kicks in as something to consider. There are different options: Adding timestamps to messages, letting the service bus handle it and/or locking data for the application before passing the message to the queue and let the node release the data after it is done.

The Real Microservice(tm) would need a read API and a data store of its own to handle the specific bounded context. At this point, there is no need for me to venture into that.

A final consideration would be for outages and disasters, where I really like the definition by the Azure Team. An outage is the temporary unavailability without data loss. A disaster is defined as the permanent loss of the queue and with potential data loss. In both cases, messages cannot be delivered to the queue and the effect is that data is not updated for the customers. Not an ideal situation. Of course, Azure have geo-replication build-in, but (for me) a even more natural approach is to do a standard try-catch statement and let the catch store the message in a temporary queue in the database and wait for the queue to be back again. The worst-case scenario is that all calculations and aggregations will have to re-executed, but putting in both measures the risk should be very low.

The last structural piece of the puzzle is how the data flows. I like to physically write down notes as I work my way through research and concepts, so I ended up with a drawing like this:

I plan on publishing more about this venture in the future. Let me know if you have questions or feedback on things I have missed.

Looking for issues

First fire up the SQL Server Profiler from the “Tools” menu.

Connect the profiler to the database server and customize the included events as shown below. Only Stored Procedures and TSQL completed events should be necessary for this. Click the “Show all columns” checkbox and find the column with “Row counts” as this might be usefull in order to find the queries taking up time.

Click the “Column Filters…” button and add in the name of the specific database by selecting the “DatabaseName” as the filter.

Now the trick is to pause the trace. Clear the trace. Both from the toolbar menu. Navigate to the page you want to profile. To make it easier for yourself make sure no one else is using the database. Start the trace and perform the action(s) you want to profile. Pause the trace.

Two things to look for in the log.

1. Number of rows (bottom right corner) – which is somewhat equal to the number of single requests to the database required for the action(s). Too many requests obviously slow down the performance. Look for duplicate requests (add single request cache). Look for patterns, like fetching a lot of single records instead of fetching them in bulk.
2. Look for events with high numbers in “Reads”, “Duration” and/or “RowCounts”. Naturally, duration is the one hurting your performance but the two others might also pinpoint potential issues with high CPU and memory on the server.

Diving deeper

After identifying a request, you want to dive deeper into, copy the request including parameters and paste it into Microsoft SQL Server Management Studio. Add the extra line for the magic of getting request statistics and time. Also ensure you include the execution plan (CTRL+M or “Query > Include Actual Execution Plan…”) and client statistics (SHIFT+ALT+S or “Query > Include Client Statistics”).

Execute the command. Notice the new tabs in the results pane. The “Messages” tab now include timings and data statistics for the command. In particular, look for high “Scan count” and “Logical reads”. You may use statisticsparser.com to make it easier to read. The table associated with a high number should spark your interest. It could be due to a bad join, an inner select or missing indexes.

Additionally, look in the “Execution Plan” tab. Look through each of the inline parts and look for large graphs and in them look for the element with the highest cost percent. Also, you want to look for “Missing Index” notes. If it appears, right click that line and choose the “Missing Index Details…”. Examine the index and the fields it includes. Give it a name and try adding it, then profile again.

Just a few pointers about indexes. Only one clustered index per table and should only be used for integers – never ever guids. Non-clustered indexes can either have an INCLUDE part or not. If you do not specify which fields to include it will just be an index for quick searches, but after a successful find it will do a SELECT to get the fields it needs for the rest of the query. However, to eliminate that additional SELECT then the index needs the INCLUDE part and all fields required in the original query. If you have a SELECT * FROM then you need all the fields in the include as well. It also means that is expensive in terms of hard drive space keeping the index and processor power needed to update the index upon inserting new records. So it is necessary to consider both options. Also, before adding indexes everywhere after a few iterations of performance optimizing do consider that some of them might overlap so they are not all necessary.

That is the essence of my takeaways. Are there more I should have added?

Getting started

Jekyll on Bash on Ubuntu on Windows has been my goto guide this time and combined with this Install Jekyll 2 on Ubuntu 14.04. Just for reference, I have copied part of the commands to this page. The official Microsoft reference for installing.

1. In Windows 10 > Settings > Updates & Security > For developers > Check “Developer Mode”
2. Open “Windows Features” > Check “Windows Subsystem for Linux”. Restart.
3. From the run dialog, run “bash”
4. Run the following commands:

$ sudo -s
$ apt update
$ apt install make gcc
$ apt-add-repository ppa:brightbox/ruby-ng
$ apt update
$ apt install ruby2.3 ruby2.3-dev ruby-switch
$ ruby -v
$ ruby-switch --set ruby2.3
$ gem install jekyll

Various install issues

I got some pointers from the general install guide from the official install guide of nokogiri.

Building nokogiri using system libraries.
libxml2 version 2.6.21 or later is required!
*** extconf.rb failed ***

Solution (reference): bundle config build.nokogiri –use-system-libraries –with-xml2-include=/usr/local/opt/libxml2/include/libxml2

/var/lib/gems/2.3.0/gems/bundler-1.14.1/lib/bundler/runtime.rb:40:in 'block in setup': You have already activated addressable 2.5.0, but your Gemfile requires addressable 2.4.0. Prepending `bundle exec` to your command may solve this. (Gem::LoadError)

or

jekyll 3.0.5 | Error:  Invalid argument - Failed to watch "/mnt/c/Projects/Oexenhave/.git/hooks": the given event mask contains no legal events; or fd is not an inotify file descriptor.

Solution (reference): bundle exec jekyll serve – -force_polling

The idea behind the application is to handle daily routines like patching and provisioning new sites in a seemingly old-school application server provider model aka. each customer has its own virtual IIS site and database. A silo structure. This structure has benefits and drawbacks. The main drawback is that it makes it a bit more cumbersome to for example update all of them with a new patch or provide the necessary tools for developers to access and debug production data. This is where this application has its place. Its construction and various innerworkings would be interesting for another write up.

Anyway, the jobs need to run in the background so a few extra threads need be spun up. The most used ways setting the DbContext up does not work for multithreading scenarios where they are not all tied directly to a IIS request thread (InstancePerLifetimeScope) – or at least that’s the combinations I have found. The go to guide for the various usages of the DbContext would be the blog post “Managing DbContext the right way with Entity Framework 6: an in-depth guide” by Mehdi El Gueddari.

The solution, I ended up with was to instantiate the DbContext in a using construct as often as necessary. Even multiple times in the same request. Creating the same instance again and again is that efficient? Apparently for this object it is according to How to decide on a lifetime for your ObjectContext. No worries. I wanted to have a custom setup of the connection string and lazy loading settings, so I ended up constructing a partial class that handles the instance creation like below:

public partial class TCAMEntities
{
    public TCAMEntities(DbConnection nameOrConnectionString) : base(nameOrConnectionString, true) 
    {
    }

    public static TCAMEntities Instance
    {
        get
        {
            EntityConnectionStringBuilder _entityBuilder = new EntityConnectionStringBuilder
            {
                Provider = "System.Data.SqlClient",
                // E.g. data source=localhost;initial catalog=tcam;persist security info=True;user id=sa;password=sa;multipleactiveresultsets=True;application name=EntityFramework
                ProviderConnectionString = MachineConfigurationManager.AppSettings["ConnectionString"],
                Metadata = @"res://*/DAL.TCAMModel.csdl|res://*/DAL.TCAMModel.ssdl|res://*/DAL.TCAMModel.msl"
            };

            var _result = new TCAMEntities(new EntityConnection(_entityBuilder.ToString()));
            _result.Configuration.LazyLoadingEnabled = false;
            return _result;
        }
    }
}

And it simplifies the actual usage to a setup like:

public IEnumerable<IClientView> GetAll()
{
    using (var _entities = TCAMEntities.Instance)
    {
        return _entities.Clients.Where(c => c.IsActive).Select(Convert).ToArray();
    }
}

However, the drawback is that in some situations the nature of EF would lazy load stuff, but as the context is disposed that’s not possible. To get around it, I use ToArray() or similar. The upside is that I don’t by accident lazy load all kinds of stuff in controllers.

This works reasonable well for the current load of the application. I have one place where I execute two ajax calls at the same time targeting the same table, this gives deadlock issues. Therefore, I implemented a simple lock for that call for now.

In case you wonder, the MachineConfigurationManager class is a custom class that generates a machine specific config file that can be ignored when committing, but still falls back to web.config for debug values.

Currently, we have been using the proposed agenda for the last dozen sprints and for now it works for us. We are also using the agenda in its raw format for doing a summary. At the moment, I simply create additional sub bullets for comments and discussions as the team goes along. We store the agenda on a SharePoint wiki and the ScrumMaster (me) creates a new wiki for each retrospective including the next retrospective meeting coming up.

1. How was the sprint? (Fist-to-five-method)
2. Positive stories from the sprint (from each team member)
3. Looking back at decisions from last retrospective. Rollback or keep?
4. What is the number one challenge this sprint or what are number one thing that is holding us back from performing better? (from each team member)
5. Reflect on possible reasons for these challenge. (5-Whys-method)
6. Identify possible solutions and decide on which to do in the next sprint
7. Any of them requires a future backlog item due to its size?
8. Discuss and vote for change requests to any Scrum artifact (from any team member)​
9. Ideas for discussion
10. ​Feedback on the retrospective​

Item 1 – Provides a super quick feedback from the entire team about the sprint just completed. Everyone shares their thoughts without any bias. We write down each number to calculate an average (however, for now we just store it as such without looking at the averages over time). The team member with the highest vote gives a brief explanation of why that is, and so does the lowest. Quickly everyone is one the same page and it opens everyone’s minds about the current team spirit.

Item 2 – Each team member in the team must share one positive story or leaning from the sprint. This helps setting a positive focus to kick of the retrospective (which easily focuses on all the bad stuff). I have experienced it being hard to get everyone to participate, so I have introduced tagging each story with initials and this implicitly introduces some peer pressure to participate.

Item 3 – ScrumMaster before the meeting appends any decisions or trial as sub bullets and each item is discussed again in order to determine if the effect was good or bad. If the team are holding back on an item, I introduce a simple Roman vote to get to a consensus. Currently, we don’t have a fixed procedure for keepers, but if an initiative last for more than two sprints the idea is to turn it into a rule in the Working Agreement or Definition of Done.

Item 4 – The core question for the retrospective, we need to improve, but we need to find the best spot. Each team member should present at least one challenge. The trick is to avoid going too quickly into “why” and solutions for a given challenge. Each team member should have a change to add an item or add on to an existing one. Again tagging each challenge with initials might be needed.

Item 5 – The ScrumMaster picks items from the list of challenges based on number of mentions or gut feel at this point. The number of items to go through is chosen based on time and extend. The ScrumMaster should steer the team towards finding reasons, not solutions. Keep asking “why?” is an interesting exercise for getting concrete and quantifiable reasons.

Item 6 – This item might run simultaneous with item 5 in order to tie the knots after getting to good reasons to a challenge. Each item should end up with a couple of suggested actions. The team must vote on which of the suggestions to try out in the coming sprint. Voting could be done with Roman Vote or Dot-voting. The ScrumMaster is responsible to ensure the team remembers them in the sprint.

Item 7 – A solution to a challenge might end up being a spike/research backlog item. The team and Product Owner should establish on a case-by-case basis if it needs to be prioritized with everything else or it could be pushed to any sprint as a team task (a backlog item created and prioritized by the team).

Item 8 – During the sprint each team member may add sub items to this list and state which Scrum artifact the change should be done to. Each item is taken in turn and voted to be included in an artifact.

Item 9 – During the sprint subjects might have been raised during the Daily Scrums that require more discussions and time. These are added here a head of time and taken in turn during the meeting. They could also end with backlog items, artifact elements or trials for the next sprint.

Item 10 – Slot for giving feedback to the ScrumMaster about the agenda and the retrospective meeting in general.

I would be happy to hear from other Scrum teams if they are going through other agendas in their retrospectives.