Recent articles About

Compiling enterprise

Ivan Koshelev blog on software development

Roslyn beyond 'Hello world' 06 One-off code changes with Roslyn [2022 January 06] .NET, C#, Roslyn, Workspaces, Static-Analysis, Refactoring

This is an article about using Roslyn Workspaces to run quick one-off analysis on your .NET projects without going into complexities of analyzers and code-fixes. It builds upon part 1, where we created a query that analyzed logical expressions inside our code-base. This time we will use Workspaces to replace invocations of an obsolete method with a newer version.

Our synthetic code-base emulates a reporting system for a big corporation. The system pulls together information form accounting, HR, sales and supply systems and prepares analytical reports for our users. It's a big system that has been around for over a decade, so there is quite a bit of legacy code in it. Today we finally decided to get rid of the obsolete overload of our most called method ScheduleReport. We want to replace:

var scheduleId = 
    reportSchedulingSystem.ScheduleReport(reportName, false, id, null, null, null);
 

with

var scheduleId = 
    reportSchedulingSystem.ScheduleReport(
       reportName, 
       new UserIdsAcrossSystems(userIdInAccountingSystem: id),
       false).id;
 

in a fully automated manner.

continue reading
Roslyn beyond 'Hello world' 05 One-off static analysis with Roslyn [2022 January 02] .NET, C#, Roslyn, Workspaces, Static-Analysis

Roslyn compiler platform is among the best things that happened to .NET in the previous decade. 10 years ago static code analysis was reserved for teams of highly dedicated programmers who spent hundreds of hours studying C# compilation process and intermediary models that stood between a programs text and resulting byte-code. Thanks to their contribution and great work done by the .NET team, today we can achieve the same result in mere hours with a comprehensive and user-friendly API gateway into the compilation process. This article will show you the easiest, yet very practical form of static code analysis with Roslyn, something that takes under an hour to use: Workspaces.

Roslyn is at the core of modern C# IDEs. When you click a screwdriver icon in Visual Studio and choose a quick refactoring - that's a Roslyn "code fix". When during compilation a 3-rd party library gives you a warning concerning how your code is using its API - that's Roslyn "analyzer".

There have been ample articles written about analyzers, including my own series 1↗ 2↗ 3↗ 4↗. But analyzers are not something that a typical dev gets to write often. They are mostly handled by teams maintaining libraries and frameworks. In day-to-day application development there isn't much opportunity to write them, nor is there budget to get through initial learning overhead. On the other hand, a typical enterprise developer routinely does refactoring work, analyzing various pieces of code in a big code-base, looking for spots that can be unified and improved. That's where Workspaces and one-off refactoring come in. One-off refactoring is much easier than writing an analyzer, since we don't have to worry about code efficiency and dozens of corner-cases that an analyzer has to account for. And with the relatively small amount of effort needed to get comfortable with such refactoring - it becomes a net positive time saved very quickly.

continue reading
Pragmatic uses of Typescript type system 04 Domain Modeling with Typescript [2021 November 22] Typescript, types, domain modeling, literal types, tagged union types, template literal types

This article gives an overlook of Typescript features that let us provide safety guarantees for our code unlike any other mainstream language. Typescript is a somewhat paradoxical language. It is a superset of Javascript and Javascript has one of the simplest, least strict typing systems among mainstream languages, where even distinction between int and float or char and string are deemed excessive. Javascript is also dynamically typed, a trait that may seem down-right harmful to developers coming from Java or C# background. And yet, Typescript, sitting on top of JS type system, allows us to model types far more strictly than any other mainstream language.

Article is quite big, owning to almost 4 years of complex Domain Modeling experience in Typescript that I'm attempting to sum-up and considerable amount of ways in which Typescript technical aspects can be applied to Domain Modeling. First part of this article explains the languages features of Typescript that we will use and is most useful to developers coming from other languages. If you are up to speed with TS, you can jump to the second part, which covers their application.

continue reading
Pragmatic uses of Typescript type system 03 Tag hierarchies via Template Literal Types [2021 May 09] Typescript, types, tagged union types, template literal types, hierarchy, polymorphism Features described in the articles require Typescript 4.3, which is in beta at the time of writing.

Tagged union types are a great part of Typescript, indispensible when working with groups of related data types, the kind we are likely to receive in JSON form from some API. They allow us to generalize groups of those types and strong-type functions that can operate on any member of the group.


const catTag = `cat` as const;
const dogTag = `dog` as const;

type CatRecord = {
    type: typeof catTag,
    name: string,
    huntsMice: boolean,
}

type DogRecord = {
    type: typeof dogTag,
    name: string,
    lovesFetch: boolean
}

type AnimalRecord = CatRecord | DogRecord;

declare const cat: CatRecord
let a: AnimalRecord = cat; // all good :-)
TS playground

This approach works fine in many situations, but its limits quickly become visible when we try modeling hierarchies of data.


const vanTag = `van` as const;
const ambulanceTag = `ambulance` as const;
type FuelType = 'gasoline' | 'diesel' | 'electric';

type VanRecord = {
    type: typeof vanTag,
    fuelType: FuelType
}

type AmbulanceRecord = Omit<VanRecord, 'type'> & {
    type: typeof ambulanceTag,
    medicalEquipment: string[]
}

type FuelStation = {
    availableFuels: FuelType[]
}

function canRefuel(station: FuelStation, van: VanRecord) {
    return station.availableFuels.some(x => x === van.fuelType);
}

declare const station: FuelStation;
declare const van: VanRecord;
declare const ambulance: AmbulanceRecord;

canRefuel(station, van); // fine
canRefuel(station, ambulance); // error!
TS playground

So how can we both have tagged types and make sure that 'canRefuel' function accepts any type derived from 'Van'?

continue reading
Flat DOM with adaptive CSS Maximum flexibility with minimum complexity in HTML components [2020 March 27] HTML, Dom, JavaScript, React, Components, flexibility, CSS-grid

Working on a suite of applications for a big enterprise, one understands the benefits of reusable components quite quickly. Chances are, at least 50% of functionality, like a user-friendly customer lookup, will be used in the majority of your applications with just a little bit variation in its functionality. Your users expect that this widget will be in a familiar place in every app, will look roughly the same and will act exacly the same. As an experienced DEV, you take a base component library and build your CustomerSelectorCmp on top of it up to the current requirements. It has all the necessary logic, it is used in 20 apps and it works great. Until new requirements come:

  • A new app is being commissioned, and CustomerSelectorCmp needs to have a horizontal mode for it; This will probably be used only in this 1 app;
  • Our managers have doubled sales numbers by grabbing tablets for client visits and having our app ready to go in the heat of the moment; But CustomerSelectorCmp could be much better with touch;
  • We have 10% of managers with special visual needs – it would be very nice to have accessibility mode for CustomerSelectorCmp;

5 years ago, trying to accommodate all this functionality in a single component would inevitably have to violate Single Responsibility Principle and lead to an unmaintainable monstrosity, where key CSS properties are overridden at-least 3 times each, classes are added just to increase CSS selector specificity and !important is your best and worst friend. Well, lucky we are in 2020! Thanks to CSS-Grid and React, we can have a base component that contains all the key functionality and can change appearance drastically with just a dozen lines of CSS and JS. See the following 3 dropdowns? They are the same component, rendering the same DOM! The difference is in 6-8 lines of CSS!

Grab the showcase project form github and lets dive in.

continue reading
< older
Ivan Koshelev photo

I'm passionate for anything that can be programed and automated to make life better for all of us.

Archives

  1. January 2022 (2)
  2. November 2021 (1)
  3. May 2021 (1)
  4. March 2020 (1)
  5. August 2019 (1)
  6. July 2019 (1)
  7. May 2019 (1)
  8. February 2019 (1)
  9. October 2017 (1)
  10. August 2017 (3)
  11. July 2017 (3)
  12. May 2017 (3)

Elsewhere

  1. GitHub@IKoshelev
  2. NuGet@IKoshelev
  3. LinkedIn