DEV Community: Rasmus Schultz

The Recursive Manifesto

Rasmus Schultz — Wed, 02 Oct 2024 15:18:15 +0000

Why You Should Always Use Recursion

Why read this manifesto?

To understand why you should always use recursion, you must first understand why you should always use recursion.

Case 1: The Self-Referential Nature of Understanding

To comprehend why recursion is superior, consider the following:

To understand complex ideas, we break them into simpler parts
To understand those simpler parts, we must understand recursion
To understand recursion, read this manifesto
GOTO 1

Case 2: The Proof

Let P(n) be the proposition "Recursion is the best solution for problems of size n"

To prove P(n) for all n ≥ 1:

Base case: For n = 1, recursion is the best solution because:
- To prove recursion is best for n = 1
- We must use recursion to prove it
- Therefore, recursion is best for n = 1
Inductive step: Assume P(k) is true for some k ≥ 1
- To prove P(k + 1), we must:
- Break down the problem of size k + 1
- Into a problem of size k (which we know is best solved with recursion)
- Plus a problem of size 1 (which we proved is best solved with recursion)
- Therefore, P(k + 1) must also be true
- Q.E.D.

Case 3: Real-World Applications

Consider how to convince someone to use recursion:

Show them this manifesto
When they ask why they should believe this manifesto, show them this manifesto
Repeat until stack overflow or enlightenment, whichever comes first

Case 4: Counterarguments

For any argument against recursion:

If the argument is simple, solve it recursively
If the argument is complex, break it into smaller arguments
GOTO 1

Conclusion

You should always use recursion, because:

To understand why, refer to the introduction
To understand the introduction, read this conclusion
To understand this conclusion, you must understand why you should always use recursion

Disclaimer

This manifesto may cause infinite recursion in the readers mind. In case of mental stack overflow, remember: the base case is that recursion is awesome.

Easy advanced TypeScript types from day 1

Rasmus Schultz — Thu, 15 Sep 2022 08:28:59 +0000

Someone proposed a TypeScript feature that could bridge the gap between the JS and TS worlds:

// Detect dark theme var iframe = document.getElementById('tweet-1570325123948859392-119'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1570325123948859392&theme=dark" }

"Typing is hard".

Yes, it is.

Imagine if this was easy and accessible to everyone from day 1? I really think we need to push for the development of this idea.

Advanced types should be for Everyone, not just TypeScript Gurus and people with functional programming experience. 🙂✌

Please 💗 this post, ⭐ and +1 the issue - let's get this idea out there!

Thank You! 🙏

Zero configuration: what does it mean?

Rasmus Schultz — Sun, 03 Apr 2022 09:48:05 +0000

There's a poll attached to this tweet:

// Detect dark theme var iframe = document.getElementById('tweet-1510515106999898115-638'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1510515106999898115&theme=dark" }

Please vote or comment, and share for reach. Thanks! 🙂

A Custom date-picker in Svelte

Rasmus Schultz — Thu, 03 Mar 2022 16:21:39 +0000

I have this fairly small, but fully functional, custom date-picker UI control, which I've been porting between UI frameworks for quite a few years.

I ported this example to Svelte about 3 years ago, and today I decided to update it to Svelte 3.

Try it out 🚀

I always try this first with any new framework to see how they stack up. Perhaps the most important thing demonstrated by this use case, is the ability to validate and conditionally accept a value into the control's internal date state - and the ability to modify the control's view state by navigating through months without changing the value.

(it was quite a departure from the old version, in case you'd like to compare.)

There's not a lot more to say about this. Enjoy. 🙂

Typescript module, multiple exports, where do you begin?

Rasmus Schultz — Thu, 03 Mar 2022 16:14:22 +0000

I'm building a Typescript library. 🤔

It's going contain several related packages - I want them under a single source-control, but I want them published as packages you can install individually, because some of the packages will have larger dependencies, and I want to keep the main package lightweight.

I'm guessing I need some sort of monorepo setup? I'd prefer to use whatever is available in plain old npm - please, no yarn or third-party monorepo tools.

At least one of the packages is going to have multiple exports in package.json - that is, it will contain multiple modules in the same package. This will make sense for packages that ship with optional modules - keeping them close at hand, but loading them is optional.

The Typescript source module structure won't necessarily match the published modules - that is, I might decide to use more TS modules published as fewer compiled ES modules, just for cleaner structure, so I will probably need some sort of bundler as well.

I've looked at Typescript project references and npm workspaces, and it's not clear to me if I need either or both of those?

I'd like to use esbuild or rollup for bundling - but I need exports in package.json, which does not seem to be an npm standard feature? Is it a node feature? Or is it specific to webpack maybe? I don't understand where this feature "belongs" or comes from?

My library should work both on the web and under node.

Emitting .d.ts files is important, since it's a TS package.

Publishing modern ES modules would be fine - if this requires a recent version of a browser or node, that's fine; supporting older platforms is not a concern for this library.

Supporting Deno is "nice to have" but not a must. I realize I'm already throwing up a long list of requirements here. It's not completely clear to me if publishing for Deno requires you check-in the compiled files - or if it's better to just structure the TS module sources to fit? If so, I'm willing to do that.

Where the heck do I start?

I'm willing to make concessions here, in favor of simplicity. If that means I have to restructure my code, or if publishing individual packages rather than multi-module packages (with exports) makes things easier, then yes.

There's a wealth of articles and documentation, but it's never clear to me which of them apply to my situation. There are so many options and avenues, and every time I sit down to try to figure this out, I get lost and overwhelmed - by the time I have 50 tabs open, I just close everything and give up. 😅

I really just want to keep things as simple as possible - as few tools and as little configuration as necessary.

Help? 😄🙏

It's impossible to get a voice in here

Rasmus Schultz — Tue, 22 Feb 2022 09:53:07 +0000

Twice now, I've spent considerable time carefully writing an article, just to watch it get 20-30 hits in the first hour, and then disappear into oblivion - never to be seen by anyone again.

If my content was bad, I could understand it - but I've been told (by Dev staff and other developers) that it's really helpful. I don't like to be the judge of my own work, but I don't think my content is bad.

It's great to see the site become a success - but the sheer volume of traffic in here apparently makes it impossible to get a voice.

Putting work into an article feels like a complete waste of time.

I'm not famous or well known (and don't wish to be) so I don't have a million Twitter followers or some other way to get people to notice my content.

I'm guessing that's the only way your content gets noticed here?

It's on the front page for an hour, tops, and then it's gone.

It looks like a quick paragraph or 5-10 words like "do you like X?" or "how do you feel about Y?" gets the same amount of air time on Dev as anything else - and maybe the site equally weighs discussions and actual content?

Mixing discussions and articles into a single stream might not be working well?

I don't know how to fix this, but I've brought it up with the Dev staff before, and they seemed to agree, this is not really working well.

This makes me wonder as well, how much good content from other contributors am I missing? How much actual content gets drowned out by quick prompts and baits?

Honestly, I probably won't bother writing anything else here again until or unless you manage to do something smart about this.

There has got to be some way you can give air time to actual content?

Very frustrating.

I feel like Dev has far more potential than what it's delivering right now.

</rant>

Containerless Dependency Injection in C#

Rasmus Schultz — Mon, 21 Feb 2022 18:22:40 +0000

🧡 Dependency injection is at the heart of every good piece of software.

In most typical projects, dependency injection is implemented by configuring some sort of dependency injection (DI) container.

If you don't have a DI container available, if you don't understand how your DI container works, or if you just don't like the idea of having a complex facility for something that is ultimately pretty simple, in this article, I will demonstrate a really simple DI pattern that does not require any container library or framework.

In this example, we'll be bootstrapping a few simple mock components - to keep the discussion focused, these don't have any actual implementations, just constructor arguments.

class Connection
{
  public Connection(string connectionString)
  {
  }
}

class UserService
{
  public UserService(Connection c)
  {
  }
}

class WebRequest
{
  public WebRequest()
  {
  }
}

class ListUsersController
{
  public ListUsersController(UserService u, WebRequest r)
  {
  }
}

So we have:

a Connection representing a database connection object,
a UserService that requires a Connection,
a WebRequest representing an incoming HTTP request (which would be generated by an HTTP server component of some sort) and
a ListUsersController which depends on the UserService and an incoming WebRequest.

Note that the Connection class in this example has a dependency on a connectionString - we will use this to illustrate the difference between dependencies on something from the external environment, versus dependencies within the internal application: an external dependency such as this has to come from somewhere outside the application, such as a configuration file or environment variable.

Contexts

Instances of our components have to be created and held somewhere, for the duration of their lifetime - personally, I like to refer to this "somewhere" as a context.

We could say, for example:

"a controller exists within the context of a web request"

For our example, we need two contexts:

An ApplicationContext for components that exist for the entire lifetime of the running application, and
A RequestContext for components that exist only within the context of a specific web-request.

So you can see why the distinction is important: while the application context is going to exist for as long as your application is running, request contexts are going to come and go with individual web requests, as they are received and routes to different controllers with different dependencies.

In practice, the implementation of a context is just a class with fields to hold the instances of our components - for each component we need:

A private field to hold the component instance. To make sure we don't create our components before (or unless) they're needed, we store every component instance in a System.Lazy<Y> instance.
An initialization in the constructor. This is where we define the factory functions for each of our components, by injecting an anonymous function (a closure) into the appropriate Lazy<T>.
A public accessor. This is how we retrieve component instance from the context.

For the ApplicationContext, this looks like the following:

class ApplicationContext
{
  private Lazy<Connection> _connection;
  private Lazy<UserService> _userService;

  public ApplicationContext(string connectionString)
  {
    _connection = new(() => new Connection(connectionString));
    _userService = new(() => new UserService(Connection));
  }

  public Connection Connection { get => _connection.Value; }
  public UserService UserService { get => _userService.Value; }
}

Just to give you a feel for the "rhythm" of this pattern, I included a public accessor for Connection - if a given component is only used internally within the context, exposing it via an accessor might not be necessary; you should decide what you need or want to expose.

Let's go ahead and define our RequestContext as well:

class RequestContext
{
  private Lazy<ListUsersController> _listUsersController;

  public RequestContext(ApplicationContext app, WebRequest request)
  {
    _listUsersController = new(() => new ListUsersController(app.UserService, request));
  }

  public ListUsersController ListUsersController { get => _listUsersController.Value; }
}

Notice that a RequestContext requires an ApplicationContext. Recall how, in the beginning of the article, we described the connectionString required for an ApplicationContext as an "external dependency"?

In the same sense, the ApplicationContext is "external" to the RequestContext: from within the boundary of a RequestContext, an ApplicationContext is the external world - an environment with it's own distinct life-cycle.

As you can see, our model now consists of long-lived, shared components in one context - as well as more short-lived, request-specific components in a different context.

Finally, let's briefly illustrate how to put these together:

var app = new ApplicationContext("user=blah;password=meh");

var request = new WebRequest();

var requestContext = new RequestContext(app, request);

var controller = requestContext.ListUsersController;

Now, in an automated test, you might actually write code in a linear fashion like this - and being able to wire up real dependencies for integration testing is certainly a benefit of this pattern.

In a real project, some kind of long-lived server component (in the application context) would provide a proper WebRequest for a handler of some sort, which would generate a RequestContext, apply some pattern matching, pick the right controller, and so on...

Building an actual application is outside the scope of this article - the point of this example is to illustrate the fact that components exist in different contexts because they have different life-cycles.

Here is a running playground for you to try out - I encourage you to play around with the dependencies, perhaps mock out an example with mock components from a project you're currently working on, and get a feel for it.

Conclusions

The beauty of this pattern, is that it scales beautifully to complex projects - while a dependency graph can get very large, this simple pattern allows you to deal with the creation of each component individually, while the larger graph of dependencies simply unfolds and resolves itself through the use of Lazy<T> and simple accessors.

The arguable downside of not using a DI container, is that you do need to manually define the creation of every component - personally, I don't find this pattern too verbose, and I actually like the fact that a breaking change to a constructor requires me to consider the impact on other components.

Lastly, someone asked me, what would happen if we accidentally created a circular dependency - would the program go into an infinite loop, terminating with a stack overflow? Well, see for yourself - but no, Lazy<T> actually throws an exception in this situation, which is good news. Arguably, the error message might not be as helpful as it might be with a DI container - but if you make this mistake, at least you won't be setting any servers on fire. 😆🔥

I hope this article gave you an idea of just how simple dependency injection can actually be. Happy coding! 🙋‍♂️

Test-driven vs test-first

Rasmus Schultz — Tue, 13 Jul 2021 10:12:42 +0000

I've tried test-first many times over my career, and I will happily admit that it does not work for me.

If it works for you, that's great. But personally, I need to think about the code and the design first, before I know what I need to test.

How I Write Code

My workflow is very much driven by tests.

I typically write one function, or maybe just part of a function, with testing in mind - and then I add the test. I would agree that test-last is not a good strategy, but what works best for me, personally, is to alternate between writing code and tests.

For one, I find that writing the test first is just too clumsy in type-safe languages. I don't want to have the IDE screaming at me the whole way - if I write the test first, there is no auto-completion, or sometimes the wrong auto-completion.

But more than that, I simply haven't discovered the right shape or form of the code yet - and that is something I want to tease out, discover and adjust, before committing to a public interface, which I'm going to be testing against.

In other words, my code is definitely driven by tests - but it's not exclusively driven by tests. Plenty of other factors inform the design of my code - for example, the existing code, and the language itself, both inform and constrain a design.

I design for testability, but perhaps more than that, I design for readability - which isn't something that I, personally, can just intuit, ahead of actually writing code.

More Roads to Rome

We both strive for the same values, and arrive at code with the same qualities: it works, it's modular, it's cohesive, it's decoupled, it has good separation of concerns and meaningful abstractions. We both want readable tests that test the right things, aren't too dependent on implementation details, and so on.

In my experience, the difference between the test-first approach and my approach is largely personality - rather than outcomes.

My code is just as informed and driven by tests, at every step of the process, as your test-first code. My approach is every bit as test-driven as yours.

I just don't have the exact same process and mental model that happens to work for you.

Since you've been insisting on test-first for much of my career, of course I've tried it, and more than once. And frankly, if I were forced to write my tests first, my code and tests would not be as good as they are.

It's simply not how my mind works, and I'm definitely not alone in feeling this way either - I know plenty of capable, experienced developers who feel the same way.

Finding Balance

I wish you would not conflate test-first with test-driven.

And please don't give me your song about the original definition or meaning of the word "test-driven" - I understand the origins of these words, but they are just words. Nobody owns them.

My approach is neither test-first or test-after - I'd like to refer to it as test-along, and I wish you would acknowledge the fact that it is every bit as test-driven as your test-first approach.

If you belong to this group of test-first enforcers, I hope that you would reconsider your position on this. There is an approach between test-first and test-after, which, to me and many others, is just as efficient, practical and meaningful as your test-first approach.

In fact, I would urge you to try it.

In my experience, a balanced approach, in software development — as it is everywhere in life — is usually better than polar extremes.

A Successful IOC Pattern with Functions in TypeScript

Rasmus Schultz — Sun, 20 Jun 2021 19:12:41 +0000

Over the past few months, I've been working on a TypeScript project, where I decided to challenge myself to use Functions only. This week, I refactored the codebase to use IOC everywhere, and it feels like I leveled up. 😄

There's been a lot of articles these past couple of years about "functional programming" in JavaScript, and for some reason these are mostly concerned with immutability, sets, map/reduce, and so on. I come from a background of mostly OOP, where the answer to IOC is largely just "use constructors and interfaces", so this hasn't been really helpful.

What was missing for me, was a functional perspective on IOC and dependency injection.

In this article, I will try to illustrate the problems and solutions with a silly example for illustration purposes: for some reason, your boss wants the browser to display a personalized welcome message using an old-fashioned alert. Yikes. Well, whatever you say, boss, but I expect this requirement will change in the future.

To make the most of this article, you should know some basic TypeScript, and you should be familiar with the terms "inversion of control" or "dependency injection" - at least in the sense of using constructors and interfaces.

While DEV thinks this is "an 8 minute read", I recommend you open the Playground and spend 20-30 minutes getting a feel for this.

Okay, let's say you come up with function like this:

function showMessage(window: Window, message: string) {
  window.alert(message);
}

As you can see, I am already doing dependency injection. Rather than reaching out for the window global, this function asks for an instance of Window, which makes it easy to unit-test this function on a mock Window instance. So far so good.

💭 So we're done, right? 😁

Not quite.

Pretty soon, you will introduce functions that depend on showMessage - and, in order for another function to call showMessage, the other function needs to supply the window parameter - which means the dependency on Windows spreads to other functions:

function showWelcomeMessage(window: Window, user: string) {
  showMessage(window, `Welcome, ${user}`);
}

But wait, now showWelcomeMessage internally depends on showMessage - we really should use dependency injection for that too, right?

type showMessage = typeof showMessage;

function showWelcomeMessage(showMessage: showMessage, window: Window, user: string) {
  showMessage(window, `Welcome, ${user}`);
}

💭 This looks wrong. 🤨

showWelcomeMessage had to depend on Window, only so it could pass it along to showMessage - but it doesn't actually do anything with the Window object itself.

And while showMessage happens to use Window today, we might change that in the future, when someone realizes what a sad idea it was to use that alert. Maybe we decide to have it display a toast message on the page instead, and so the dependency changes from Window to Document. That's a breaking change. Now we have to run around and refactor everything that calls showMessage.

Calling any function gets increasingly cumbersome - anytime any of the dependencies of any function changes, we have to manually correct the calls and introduce more dependencies everywhere. We're in dependency hell, and by now we're wasting most of our time refactoring.

💭 There has to be a better way. 🤔

My first realization was, why should someone who wants to call showMessage need to know anything about it's internal dependencies? What I really want, is a function that is internally bound to an instance of Window, so that the caller doesn't need to know or care.

That means we need a factory-function for the actual function:

function createShowMessage(window: Window) {
  return function showMessage(message: string) {
    window.alert(message);
  }
}

We'll need to extract the inner function-type - the one that has the message argument only, so that other units can depend on that:

type showMessage: ReturnType<typeof createShowMessage>;

(Note the user of ReturnType here - you could have manually typed out the function signature of the inner function, but this helps avoid the duplication and the extra refactoring chore going forward.)

With that in place, our showWelcomeMessage no longer needs to care that showMessage internally uses window:

function showWelcomeMessage(showMessage: showMessage, user: string) {
  showMessage(`Welcome, ${user}`);
}

This also makes showWelcomeMessage easier to test, since now we don't need to mock window anymore - we can mock showMessage instead and test that it's being called. The code and the tests will now refactor much better, as they have fewer reasons to change.

💭 So we're done, right? 😅

Yeah, but No.

Consider now what happens to the next function up the call hierarchy. Let's say we have a login function, and showing the welcome message happens to be part of what it does - and we apply dependency injection here, too:

type showWelcomeMessage = typeof showWelcomeMessage;

function login(showWelcomeMessage: showWelcomeMessage, user: string) {
  showWelcomeMessage(user)
}

This problem doesn't go away by just fixing it at one level - we need to apply the same pattern we applied to showMessage, wrapping it in a createShowMessage factory-function. And what happens when something else needs to call login? Same thing again.

In fact, as you may have realized by now, we might as well apply this pattern consistently, as a convention, to every function we write.

💭 Really? To every function?

Yes, really - and bear with me, because it doesn't look pretty:

function createShowMessage(window: Window) {
  return function showMessage(message: string) {
    window.alert(message);
  }
}

type showMessage = ReturnType<typeof createShowMessage>;

function createShowWelcomeMessage(showMessage: showMessage) {
  return function showWelcomeMessage(user: string) {
    showMessage(`Welcome, ${user}`);
  }
}

type showWelcomeMessage = ReturnType<typeof createShowWelcomeMessage>;

function createLogin(showWelcomeMessage: showWelcomeMessage) {
  return function login(user: string) {
    showWelcomeMessage(user);
  }
}

type createLogin = ReturnType<typeof createLogin>;

It does what we wanted though. We can do all of our dependency injection from the top down now - we can now bootstrap everything from a single function in our entry-point script:

function bootstrap(window: Window) {
  const showMessage = createShowMessage(window);

  const showWelcomeMessage = createShowWelcomeMessage(showMessage);

  const login = createLogin(showWelcomeMessage);

  return {
    login
  }
}

// usage:

const { login } = bootstrap(window);

login("Rasmus");

Note that, in this example, bootstrap returns only login - if you have multiple entry-points, you can return more functions.

Now, as helpful as this pattern was, this approach to bootstrapping does not really scale well. There are two problems:

We're creating everything up front. In this simple example, we do need every component - but applications with multiple entry-points might only need some of the components, some of the time.
The code is very sensitive to reordering: you have to carefully arrange your factory-function calls, so that the previous function can be passed to the next. It requires a lot of thinking about dependencies.

We can solve both of these problems by deferring the creation of dependencies until they're required - that is, by making the calls to the factory-functions from within another function. Let's call this a getter-function.

Now, since these getter-functions could potentially be called more than once (although, in this simple example, they're not) we want them to return the same dependency every time - rather than generating new ones.

We can solve this by adding a tiny helper-function once to construct these wrapper-functions and memoize the result:

function once<T>(f: () => T): () => T {
  let instance: T;

  return () => {
    if (instance === undefined) {
      instance = f(); // first call
    } 

    return instance;
  }
}

Let's refactor again: we'll wrap all of our initializations in closures and apply once to them - and our bootstrap function will now return the getLogin function.

(Note that the once function would generate singletons, if you were to call it from the global scope - but since we're calling it from the bootstrap function scope, new instances of all dependencies will be generated for every call to bootstrap.)

The new bootstrap-function looks like this:

function bootstrap(window: Window) {
  const getLogin = once(() => createLogin(getShowWelcomeMessage()));

  const getShowWelcomeMessage = once(() => createShowWelcomeMessage(getShowMessage()));

  const getShowMessage = once(() => createShowMessage(window));

  return {
    getLogin
  }
}

// usage:

const app = bootstrap(window);

const login = app.getLogin();

login("Rasmus");

I've purposely mixed-up the order of these getter-functions, to illustrate the fact that the order no longer matters: we're now free to arrange and group these lines in any order that makes sense - and we're also no longer creating anything before one of the getter-functions is actually called, which removes any concerns about potential future performance problems.

💭 So we're...?

Yes, done! 🏆✨

Footnote: When not to apply this pattern

You don't need to apply this pattern to every function. Some functions don't have dependencies, or maybe they depend only on standard JavaScript environment functions.

For example, there's no benefit to injecting the Math.max function, since that's a pure function with no side-effects. Whereas, on the other hand, there's a clear benefit to injecting Math.random, since a mock can return values that aren't actually random - making it possible to write predictable tests for your function.

Bonus: Mutable State

I made one more little discovery this week that I'd like to share.

I think we've all been here one time or another?

let loggedInUser: string | undefined;

function setLoggedInUser(user: string) {
  loggedInUser = user;
}

function getLoggedInUser(): string {
  return loggedInUser;
}

It's dangerously easy and natural to do this in JavaScript. 💣

But even if you put this inside a module, this is global state - and it makes things difficult to test, since setLoggedInUser leaves behind in-memory state that persists between tests. (And you could write more code to clear out this state between tests, but, ugh.)

If you must have mutable state, we need to model that mutable loggedInUser state as a dependency, and then apply the create-function pattern described above.

interface LoginState {
  loggedInUser: string | undefined;
}

function createSetLoggedInUser(state: LoginState) {
  return function setLoggedInUser(user: string) {
    state.loggedInUser = user;
  }
}

function createGetLoggedInUser(state: LoginState) {
  return function getLoggedInUser(user: string) {
    return state.loggedInUser;
  }
}

I could have abbreviated this more, but I actually like seeing the word state here, clarifying the fact that a shared state is being either read or written.

It might be tempting to just take the previous version of this code, wrap it all in a single create-function, and return both of the functions, bound to the same state - but I wouldn't recommend that, because you could end up with many functions that depend on this state, and you don't want to be forced to declare them all in the same create-function. (Also, if you have to write a function that depends on several different state objects, that approach does not work.)

One more piece of advice: don't just create one big state object for all of your mutable state - this will muddy your dependencies, as functions will appear to depend on "the entire application state", even when those functions only actually depend on one property. (If you have multiple properties in the same state object, the cohesion should be high - ideally 100%, meaning every function depends on all of the properties of that object.)

The setLoggedInUser function does have a side-effect, but now the effect is on state that you instantiate and control - making it easy to inject a new state for every test.

I'm not a functional programming Guru yet, and maybe there is more to learn here, but it's definitely a step up from global state. 🙂

Conclusion

I feel like I've finally found a JS/TS code-style that really scales - both in terms of complexity and performance.

Applying this to my codebase has been an absolute breeze. I'm spending considerably less time juggling dependencies or refactoring things. Unit-testing is never a problem anymore.

For years, I've heard proponents of functional programming talk about the benefits - but the articles are mostly about arrays and immutability, which is great, and I've heard all the other great arguments. But it didn't really help me write software, and the outcome of prior attempts too often was either unmanageable or untestable. (But usually both.)

Unlocking this feels like the "next level" for me, and I really hope this puts somebody else on the path to more productive and scalable codebases with TypeScript or JavaScript.

Thanks for reading. Have fun! 😀✌

How to quit the perfect job?

Rasmus Schultz — Thu, 22 Aug 2019 15:12:39 +0000

How do you quit the perfect job?

In the past 6 years, I've had a key role in the creation of the most beautiful web architecture I've ever worked with.

It's simple, elegant, efficient, and an absolute joy to work on - and, above all, it's successful: turn-around time is fast, features live up to user expectations, defects are extremely rare and often quickly resolved.

I've had the joy of successfully teaching the principles, practices, values, patterns and techniques to a team, guiding them on a daily basis to successful, enjoyable, consistent work - the feedback has been almost exclusively positive, and negative feedback has almost always lead to durable improvements.

It's been deeply rewarding, on both a professional and personal level.

In my 21 years of web development, I've never been more pleased with the work.

But all good things come to an end.

I won't go into the reasons, which are personal - but after struggling with this decision, day and night, for weeks on end, I'm resolved: I have to quit and move on.

My question is, how do you do that?

I've been scouring the job boards, and it just seems like everything is going to suck in comparison: overly complex systems built on bloated frameworks, default architecture, code-generators, object/relational-mappers, tools and practices that generally go against everything I stand for and believe in.

I feel like I've been blessed and cursed all at once. I was lucky enough to arrive at a time when my employer was willing to rebuild from ground up - in my experience, that practically never happens. I don't live in a capital city, so startups are rare - and most startups just want rapid prototypes and quick entry to markets, anyhow.

How do you move on after an experience like this?

If you've been in a similar situation, any experience you can share would be greatly appreciated.

Thank You! ✨

"Bringing Peace to the Galaxy" (Zeev Suraski on PHP internals)

Rasmus Schultz — Sat, 10 Aug 2019 10:30:46 +0000

Really interesting post on the PHP internals mailing list:

https://externals.io/message/106453

The post was followed up by this FAQ:

https://wiki.php.net/pplusplus/faq

This discussion is painfully over due, and I'm just thrilled to see it finally taking place! :-)

Anything like PHP's PSR-7/15 for C# and ASP.NET Core?

Rasmus Schultz — Wed, 17 Apr 2019 13:25:04 +0000

I've been using PHP for the past 5 years or so, and I'm taking a look at C#, which I last used 5-6 years ago.

A lot has happened, it seems.

One of the greatest pains was threading issues (locks and mutexes, ugh) and it looks like async and await will make for a more painless experience in that department, so that's good.

The platform and the new .NET Core run-times are now cross-platform with Linux and Mac support, so that's a huge plus.

But where's the simple, elegant, straight-forward, no-frills, no-bells, no-whistles HTTP kernel I'm looking for?

These past years, with the PSR-7 HTTP model, and PSR-15 middleware model, I've grown accustomed to a very simple and elegant HTTP abstraction consisting of a few interfaces and a trivial middleware stack - I build everything from the ground up with a DI container at the center of everything, which provides me with a huge degree of freedom, flexibility, control and ease of use, with very few moving parts, easy debugging, and nothing to get in the way of handling any special case or requirement.

Everything I can find for C# looks overly complex, bloated - everything seems to be based on the idea of "standard architecture" with a bunch of hooks and configuration that lets choose from lots of tailored options and plug things in.

After the success we've had with PSR-7/15, after seeing how happy my fellow developers are working with something much more simple and open, frankly, it would feel like a huge setback, going back to the kind of "fill in the blanks" architecture of "web" frameworks (way too broad!) that we put of with before we discovered things like Express.js, PSR-15 and similar middleware stacks on other platforms.

All I really want is a simple Request and Response model, and a very basic Request => Response middleware abstraction (e.g. PSR-15's HandlerInterface would do nicely) that plugs into a simple HTTP Host that does the hard work.

Surely there has got to be something like that for C#/.NET Core?

Why am I not finding it?