DEV Community: Morten Olsrud

Webcam replacement advice needed

Morten Olsrud — Sat, 04 Apr 2020 19:14:32 +0000

Hey there!

Like most of us, I find myself needing to up the ante equipment wise at the home office. I've landed a nice setup with monitors and a HyperX Quadcast mic, I'm waiting for a mechanical keyboard to land, as well as a nice, ergonomic mouse with extra buttons to minimize shifting hands from mouse to keyboard.

What I don't have is a nice camera. Sure, we all dream about that HDR 4K 60fps sweetness, but my budget is nowhere near that. I also see that the market is sucked dry for conventional webcams, especially the nicer ones like the Logitech 922, which to be honest, is also a bit pricey.

I am looking for creative, good alternatives that will work well on Ubuntu 18.04 onwards.

My own thoughts so far has been to use my mobile phone, as that camera is better than the one in my laptop, but the software solutions I have come across sucks in some way, if they work at all.

I have also peeked at Action Cameras and Camcorders, but those camcorders get pricey fast. I still have a hope regarding actioncams, but their documentation is often very lacking with regards to supporting live streaming video to a computer over a cable, as in allowing the computer to use the camera as a video source. Another issue I've read about is that many of the actioncams has a lens leaning heavily towards a fish eye view for more snappy action videos.

Anyone out there have experience with using alternative cameras as webcams for video calls, as well as for screencast recording? Ideally Full HD 1080p @ >=30fps and HDR, but HDR is less important. Cheap 1080p actioncam without pronounced fish eye is possibly my best bet, but impossible to find reading specs in webshops...

Any suggestions or alternatives? Please share your thoughts and/or setup in the comments.

Thanks!

Meet Jotr - A note-taking app for the CLI

Morten Olsrud — Mon, 21 Oct 2019 21:42:46 +0000

hakash / jotr

A terminal tool for jotting down tagged notes.

Disclaimer: This project is in beta. Help is needed to test it to root out issues that might have escaped me. Documentation and everything needs scrutiny.

Thanks for reading!

If you are like me you really hate context switching. Jumping out of a train of thoughts to go fiddle in some GUI when you are in on the deep end in a terminal is really less than optimal.

Personally I use various apps for taking notes of different kinds, in different contexts, and try to minimize switching out of a context to take or read notes. Partly due to the overhead of the navigation, but also the imminent danger of getting distracted.

I, and a lot of my fellow developers out there, suffer in various degrees of what I jokingly call "The 'Oooh Shiny!' Syndrome". This is the thing that happens when your eye catches something distracting. This can be a notification, an unrelated, but interesting question on Stack Overflow, some article you scan by looking for something or even urges to suddenly dig into some other tech.

Sure, most of us have a good grip on this, but let's be honest. When you have a mammoth task of the boring or uncomfortable kind, it's just too easy to start procrastinating.

Reducing context switching, entering "zen-mode" in all apps that support it, turning on Do Not Disturb where ever possible and so forth is all good tips here. Several members of this community has made detailed posts about this exact topic, earning hundreds of reactions.

How Jotr can help a little - a user manual of sorts

Jotr is, as stated above, a note-taking app for the CLI. It allows you to stay in the terminal and avoid visual cues and distractions just to find some previous recorded info, or add some new notes, or "jots" as we coined them.

It is centred around tags, and each jot you add gets added to one or more tags. Using tags is optional of course, and omitting them will just default the jots to use the "Random"-tag.

Install it using npm i -g jotr

Adding data

You can add jots using a full terminal editor that's built-in, or add them using a git commit -m "Some message" style, to reduce context switching even more.

jotr js node react -c Node is awesome to serve React-driven pages

This one-liner gives you the jot Node is awesome to serve React-driven pages connected to the tags js, node and react tags. Quotes are optional as long as you don't use characters with special meaning in the shell.

Reading data

To list all your jots you can use jotr -l or jotr --list.

$ jotr -l
Your jots so far:
js:
  - Node is awesome to serve React-driven pages
node:
  - Node is awesome to serve React-driven pages
react:
  - Node is awesome to serve React-driven pages

Now, when you get a lot of jots, listing them all becomes tedious and unruly. For this situation you can list only certain tags:

$ jotr -l js
Your jots tagged with js:
js:
  - Node is awesome to serve React-driven pages

If you cant remember the exact tag, you can search or grep with jotr -g [search term] or jotr --grep [search term]:

$ jotr -g node
Your jots matching node
js:
  - Node is awesome to serve React-driven pages
node:
  - Node is awesome to serve React-driven pages
react:
  - Node is awesome to serve React-driven pages

If you want to know what tags exist, you can use jotr -t or jotr --tags to list them:

$ jotr -t
The tags currently registered:
js
node
react

Altering, deleting or editing your jots

The data storage of Jotr is file-based, and uses a simple YAML-format to save the data ordered by the tags. As of yet, Jotr does not support editing or deleting single jots, but a new, more complex storage-format is being considered to support this.

Until then Jotr does give you an option to edit the file-storage directly by using the jotr --edit. This loads up the entire YAML-file in the internal editor for your editing pleasure. I urge you to do an export (se below) before you manually edit the YAML-file, as a corrupt YAML-file will not function correctly.

Purge and export

Naturally you can export your data to a YAML or JSON file:

$ jotr --export mynotes.yml
$ more mynotes.yml 
js:
  - Node is awesome to serve React-driven pages
node:
  - Node is awesome to serve React-driven pages
react:
  - Node is awesome to serve React-driven pages


$ jotr --export mynotes.json
$ more mynotes.json 
{"js":["Node is awesome to serve React-driven pages"],"node":["Node is awesome to serve React-driven pages"],"react":["Node is awesome to serve React-driven pages"]}

Done with your list? Want to purge it? Sure:

$ jotr --purge
Are you sure you want to purge all data? (y/N)

Summary

Still with me? Great!

As you can see, you can easily stay in the terminal, jotting down things to remember, drafting commands or even use it as a multi-item clip-board.

Personally I see it as a good tool for remembering commands, settings, flags or even miniature scripts, easily called up where ever you are in the file system.

Sure, Jotr does not support synching across devices, but as a SysOps or DevOps tool, this can be positive, as you keep the data only in your profile, locally on the machine.

Bonus

Did you know that the core of Jotr is built to be embedded in other systems as a library? Check out the repo to learn more about this. Click on the "library" link.

Thank you so much for your attention!

I'll catch you later with updates, tips, trick or other tidbits.

Cheers!

-Morten

Meet Termit - A NodeJS based terminal editor

Morten Olsrud — Mon, 21 Oct 2019 13:10:23 +0000

hakash / termit

The TERMinal edITor - embeddable CLI editor

I've finally come around to make some improvements on this project, and as far as I can test, it functions as intended.

Core functionality

Termit is, as the title states, a terminal editor based on NodeJS. This means it is installable with npm i -g termit and runnable from anywhere with termit or termit some-file.txt.

It is heavily influenced by Nano, so some aspects of the user experience is similar, as well as some key-bindings.

If you want a simple terminal editor that simply allows you to edit your files, and the system already has Node installed, then you can use this. It is of course a heavier choice than Nano, Pico, Vim or similar if you install Node for this alone.

Embedding

But wait! There is more!

Termit also supports being embedded in other applications. By simply requiring and instantiating it with voluntary options, you can use this to let the users have a multi-line input area in the CLI that supports copy-paste, returning content on save with or without saving to file.

To support additional actions or content-extraction on save, Termit support pre-save hooks in a similar way that Express uses middleware. You add your callback/middleware to the stack and as with the Express-middlewares, if you do not explicitly call next(), you abort the chain.

This comes in handy if you want to extract the content to the parent application, without letting Termit touch the file-system. Follow the link up-top to the repo to see some simple code-samples for setting this up.

Testers wanted!

Hear ye! Hear ye!

I feel the terminal has reached a level of stability and maturity where it is ready to start testing it in real-world scenarios, and since I am alone on this project, I need the help of the creatively and/or mischievously inclined people here.

First of all mangle it, test it, use it and see if it will break under some weird environments that I won't be able to test myself.

The documentation needs a review as well, and I know the code needs all kinds of testing. I'm planning on implementing testing of the current feature-set, with all the necessary refactoring to achieve that. The reason it's not there already is quite simply time and a need to understand how to test terminal-manipulations. Any tips on that is much appreciated.

Future

Not many plans here yet, besides the testing-bit mentioned further up. I feel I need to get some feedback from actual users on any pain-points or short-comings.

One thing I know I want to investigate, is "compiling" is as a standalone package installable via Chocolatey, Homebrew or similar. The compiling would remove the need for NodeJS to be pre-installed, but I fell that it would never compete with Nano or similar, so I might not bother.

The embeddable aspect is possibly the most interesting feature, and the direction that would benefit most from gaining more features and making it more useful to other projects as the core editor.

The End

Well, thanks for your time, and your help! I hope you like it, even if you don't see the point of it. It was an interesting challenge really.

Use the comments below to express first-impressions and general comments, and if you have any issues with it, please open an issue on GitHub. PR's are of course welcome as well.

Cheers!

-Morten

Swapping two numbers, w/o a temp variable

Morten Olsrud — Mon, 14 Oct 2019 18:28:54 +0000

Todays post will be a short one, but one that covers a really simple algorithm that still might stump you in an interview setting if you don't have a background in math, or if you haven't been doing code puzzles on your spare time.

Getting the feel of it

Let's start with the easier version, just to get a feel for the task.

Write an algorithm that swaps two numbers.

Ok, that is easy enough. In pseudocode:

// The numbers
a = 1
b = 2

// Let's swap
c = a   // c == 1
a = b   // a == 2
b = c   // b == 1

// result
a == 2
b == 1

Ok, we just store the value of a in temporary storage c, set a to the value from b, and then set b to the former value of a, now found in c.

Upping the ante

Let's remove the c from the algorithm, not allowing temporary storage...

Write an algorithm that swaps two numbers, without using extra storage.

Wow, that one is a bit trickier. We can't use any more storage, but we need to swap the numbers. Luckily this involves numbers, and we can leverage math to help us.

// The numbers
a = 1
b = 2

// lets swap
a = a + b   // 1 + 2 = 3 => a == 3, b == 2
b = a - b   // 3 - 2 = 1 => a == 3, b == 1
a = a - b   // 3 - 1 = 2 => a == 2, b == 1

Ok, we first set a to be the sum of both numbers. Then we set b to be the result of subtracting it from the sum, making it be the former value of a. Lastly we set a to be the result of subtracting the former value of a, now stored in b, from the sum, still stored in a. This results in a getting bs old value.

Conclusion

Until I learned this trick the hard way myself in a coding quiz, I was baffled by this question, simply because I have been "trained" to think too much about variables, code, loops and other constructs, and too little in the math-department. This made me attempt to find clever ways of solving it using code, rather than the much simpler math.

I hope you can get some value from this little tip, saving you from the feeling of inadequacy that I felt. Getting stuck on quizzes like this, that are truly simple to solve, but that we tend to overcomplicate, really does not help us manage the impostor syndrome that most of us experience at times.

Good luck with your interviews!

Cheers!

-Morten

Randomizing arrays

Morten Olsrud — Sat, 12 Oct 2019 21:43:35 +0000

A little while back I had to make a card game in the browser. As with all card games, there is a need to shuffle the cards.

"Great!", you might think. "Sounds easy enough! Just call the .randomize() or .shuffle() method on the array.", is a normal plan and assumption... until you realize your language of choice does not implement such a feature for you.

I ran into this issue and needed to find a solution. Luckily for me, I had recently played around with some algorithm challenges and remembered an algorithm called the "Knuth shuffle", after the great Donald Knuth.

To be fair, he was the one popularizing the algorithm, but the current version, adapted for computers, was made by Richard Durstenfeld, based on the works of Frank Yates and Ronald Fisher, the Fisher-Yates shuffle.

The algorithm - in plain English

The goal of the algorithm is to provide a sufficiently pseudo-random shuffling of the given array for most use-cases, though not for cryptography.

Typically the algorithm starts at the last element, working towards the first, picking a random element of the elements preceding the current element. This way we keep track of already shuffled elements in an easy and non-complicated way.

Given the index i and that i > 0 is true, then take a random number between 0 and i-1 inclusive. Let's name this r.

Next we need to swap the elements using a temporary storage.

In temporary storage t, store the randomly picked element: t = array[r]. In the randomly picked index location array[r], store the current index element array[i]: array[r] = array[i]. Lastly set the current index location to the randomly picked element stored in t: array[i] = t.

Now, if i is still larger than 0, do it all again.

The algorithm - in JavaScript

This algorithm works in most, if not all, languages, as it is language agnostic, but some languages has this type of functionality built in, and that might be an even better solution if you want good statistical spread.

Anyhow, JavaScript was where I encountered the need, so here it is, fleshed out with comments.

var rand, tmp, array = [1,2,3,4,5,6,7,8,9];

// Start at the last index (length - 1),
// loop while i is bigger than 0,
// decrement i with one for each pass
for(var i = array.length -1; i > 0; i--){
    // Get the random number
    rand = Math.floor(Math.random() * i);

    // Store the randomly picked element in the temp variable
    tmp = array[rand];

    // Set the randomly picked index to be current element
    array[rand] = array[i];

    // Set the current index to be the randomly picked element
    array[i] = tmp;
}

Summary

Now as you see, this algorithm is actually quite efficient as well. It uses only one pass of the array to do its job, which means it runs in O(n) in Big-O notation. It also doesn't use any additional arrays, or shifting of arrays, which means that the only real overhead it has, is the storage for the temporary value and the random value.

Here is another piece of trivia for you, the Fisher-Yates shuffle was created in 1938 and converted to computers by Durstenfeld in 1964. The conversion also reduced the run time from O(n²) to O(n) as we see here.

Well, I for one enjoyed writing this, and I hope you enjoyed reading it. Leave a comment below if you use other algorithms for this use case or just want to share some other insight or comment on this.

Cheers!

-Morten

The simplest way to mimic HTMLEncode in your browser

Morten Olsrud — Fri, 11 Oct 2019 21:21:07 +0000

I was working on a simple textarea based input field with a preview-feature the other day and got to a point where I wanted to render the HTML written in the textarea as written, not parsed as HTML. I was mildly surprised to see that JavaScript did not have it included by default, unlike PHP and most other server-side languages.

Looking into the issue I discovered a trove of plugins and modules for solving the matter, but that felt a bit heavy handed for my use case. I wanted something simple, fast and really small.

Doing some more research and playing around, I discovered someone who used built-in features of the browser to sole the problem, in a most ingenious way using jQuery. That library was totally unneeded for the job though, and I present to you the "vanilla" version.

Behold:

function htmlEncode(input) {
  var el = document.createElement("div");
  el.innerText = input;
  return el.innerHTML;
}

And the inverse:

function htmlDecode(input) {
  var el = document.createElement("div");
  el.innerHTML = input;
  return el.innerText;
}

Be aware though that this encodes everything HTML-related, so if you are using this on a Markdown-source, you will break your block-quotes.

Thank you for your attention!

-Morten

100% Pure HTML/CSS Page Navigation - No JavaScript Required

Morten Olsrud — Sat, 13 Oct 2018 08:15:07 +0000

Build a page navigation system using only HTML and CSS

This is a little trick I've acquired over the years, and for most use cases it works wonders in keeping my code clean, lean and free from unnecessary JavaScript.

Imagine a Single Page Application or a page showing and hiding panels, modals etc. without reloading the page. Clicking on one of these triggers will alter the content of the page.

Traditionally this was done using jQuery or some home made JavaScript functions altering the styles or classes on the elements in question. Setting a class with display: none; to hide or display: block; to show them are classics, along with setting that style directly on the elements.

Well, there is no need to do it so complicated at all.

Examples

Take a look at this HTML:

...
<!-- Just a typical nav-element with a list of links -->
<nav>
    <a href="#page1">Page 1</a>
    <a href="#page2">Page 2</a>
    ...
    <a href="#page5">Page 5</a>
</nav>
...
<!-- 
    All the divs with the content you want to serve. Notice page1 sits last. 
    This is important for the CSS to work.
-->
<div id="page2" class="page">[some content]</div>
<div id="page3" class="page">[some content]</div>
...
<div id="page5" class="page">[some content]</div>
<div id="page1" class="page default">[some content]</div>
...

Here we have the nav element with it's links, and the divs with their content. Notice the ID of the DIV is the same as the anchor link. One important thing is placing the first page, or rather the div with the content you want to be shown when no link is clicked yet, last.

And here is the important parts of the CSS:

/* This hides all pages */
.page {
    display: none;
}

/* This displays the first page */
.default {
    display: block;
}

/* This displays the page corresponding to the one you clicked on */
:target {
    display: block;
}

/* This hides the default page when another page is clicked */
:target ~ .default {
    display: none;
}

Or condensed:

.page, :target ~ .default {
    display: none;
}

.default, :target {
    display: block;
}

Demo

Now, the CodePen I've embedded below contains CSS and HTML not displayed in this example, but that's just to make it "pretty" and has nothing to do with the actual function of the nav. Just the layout. Try it out before we unveil the secret sauce, and a caveat.

Unveiling the secret

The first part of this secret is the links. The href contains only hashed identifiers like the ones you use to jump up and down a page. The hash in a URL gets picked up by CSS using the :target pseudo-selector, allowing us to use that to change the style of the element who's ID is equal to the hash in the URL.

The second part is how we use the selectors to hide the default page. Since we are placing that last, we can use the sibling selector to target all elements with the class .default that comes after the element who is targeted.

Now the caveat is that unless the page is structured or laid out in such a way that the top of the "pages" are also at the top of the browser, the page might jump. Some CSS/HTML only hacks can be done by using container DIVs that holds the ID and are positioned with top: 0px; and contains the actual content DIV pushed down with margins, or some other similar approach.

Hope you enjoyed!

Oh, and if you have other approaches to do SPA and similar type navigation without JavaScript, please share in the comments.

Spring Boot Dependency Injection with Autowiring... wut?

Morten Olsrud — Thu, 11 Oct 2018 08:56:42 +0000

I've been trying to catch up on Java now, doing advanced courses on Coursera featuring graph-theory, data structures and algorithms and all that stuff. Then I went on to do some hands on, practical "How To" type tutorials, and as long as one follows the instructor, all goes well.

The problem arises though, when I try to add some features or new data to the application. All through the tutorials the instructor adds all these @Autowired properties all around, but I can't seem do grok how they are actually populated. I am not even sure where in the app the values for these are initialized or marked or whatever to be used as the value to be magically inserted by the framework.

I do understand that the Spring Boot framework does the magic under the hood using dependency injection, but now how to utilize that magic on purpose and control it.

Thanks!

Meet NanoQueue and the Schema Dependency Principles

Morten Olsrud — Sun, 07 Oct 2018 21:50:48 +0000

Disclaimer:

This project is currently in stable alpha and needs use cases and contributions to start growing.

The name "Schema Dependency Principles" is very much a woking title.

This article will also give the backdrop for the ideas presented, so the tldr is: Modular code is cool, dependencies is not. Depend on information schemas, not classes or named modules!

Introduction

NanoQueue is an idea that came to me when working on a microservice based concept for the municipal sector here in Norway. It is heavily influenced by the message driven architecture we worked on and is in itself not the real answer to any problems like many frameworks claim.

NanoQueue is a minimalistic message broker and module registry for your browser. It is currently implemented in less than 70 lines of JavaScript, including white space lines, curly braces and the works.

The mission NanoQueue is on is to help modularise your code and split your pages into smaller, self-contained components with minimal outside dependancies. I believe in the principles of building apps using the appropriate pieces, like a jigsaw puzzle, rather than buying into gigantic, heavy frameworks that solve all your problems, creates new issues you never knew you had and sucks up mobile data on a scale never seen before.

Let's face it, the Land of Front-End is a place of magnificent wonder and unspeakable horrors, all at once.

The mission

The concept I collaborated on sprung out from the need to get Master Data Management in check, and we soon uncovered a growing pile of troubles related to that. Some of the troubles we saw was vendor lock-in of our data, incompatibilities between systems needing to share data and the sheer complexities of the ginormous monoliths available to the public sector.

We quickly discovered that killing the monoliths was the most viable way forward, but splitting the monolith into a myriad of microservices that were still tightly coupled and relied heavily on each other smelled funny to us. At this time microservices was the new holy in the cloud sphere, and even Docker was not really a thing yet, or just in it's early infancies.

After some more work on this, we concluded that the dependencies of a service should lie in it's needed data, and what data it spits out. In a message driven architecture this is possible as the services never directly talk to each other. They only publish and subscribe to topics, queues or message types on a common message broker. Even the dependency for the broker can be somewhat loosened by using standard protocols like AMQP.

This lead us to the core of the concept: Depend upon an information schema published in standardised messages, not services or modules.

The key benefit is that you can replace any part with another part that consumes and produces at least the same schemas. There was of course a lot more to the meat of the concept, but this is the core of it, and the core I'm trying to take with me into the front-end space.

But front-end?

Yes, this core principle can be just as valuable on a web page with many components sharing data and events, relying on something to happen or data to be fetched, even user actions.

Now, this is not an attempt to attack, devalue or reason agains using tools like Redux, React, Vue, Angular and similar, as they are all great tools in their own way and area, and they absolutely solve a lot of problems. They can however be quite complex, and are often used just because that is what is being done.

In many cases all your component needs is to be notified of changed relevant data, relevant events or even requests for jobs done.

State

A component should care about and handle its own state, and share changes in its state with others who depend on that data as well. It should only change the state when something internal happens, and when it receives messages with new or updated data it cares about, that something internal should happen to process that data and possibly influence the state.

UI components

All components should know how to change its own appearances based on messages received or internal events like user actions on the component itself. UI components should only care about displaying data or interactive elements, and mostly be ignorant to how that data is retrieved or what happens because of the interaction.

Some exceptions here is internal actions in the component that need to happen in response to the interaction, like changing a colour, checking a checkmark or other types of UI changes to indicate to the user that they did interact with the component.

Non-UI components

These components are typically the ones maintaining some master data records, being the current truth to resolve disputes or what have you. They also do the background tasks like talking to a server, managing sessions, cookies, local storage and such, perform computations, translations, conversions, parsing or other type of short or long-running tasks that are request based in nature. Acting as a middleware for incoming data, automatically parsing etc. before emitting the result, would also be a great application.

NanoQueue's role

The part NanoQueue can play, and other brokers like it, is the central hub that handles the passing of the messages. Like I stated in the introduction, NanoQueue does not really solve the problem, but it facilitates the solution.

What I hope to see, is that we can build a community effort to creating standardised message schemas for specific types of messages.

A simple example

Let's take a component that displays a user profile. It needs data like the username, display name, e-mail, profile picture and similar. Some profiles are naturally more complex than others, but for this example, we'll keep it simple and assume that the extra data can be supplied in "schema extensions" or similar.

{
    username:        "some_dev",
    email:           "some_dev@email.some-dev.com",
    display_name:    "Some Dev 👨‍💻",
    profile_picture: "http://some-dev.com/pic.png"
}

This data could be requested using a topic like general.user.profile.request or something similar. This structure lends itself to easily parse the topic for specificity increasing for each dot, and makes looking up stuff in a dictionary really easy. It is also somewhat the standard in at least some server side message brokers.

The component that knows how to handle requests for a user profile, will do just that, get the profile from the server if it does not already have the data, and return it through another message, for example using a topic like general.user.profile to make the data available to everyone wanting that data.

Some mechanisms for ensuring only the sender receives the response could easily be implemented using contract-bound callbacks, component generated one-off topics like general.callback.[some unique id] which is given in the request as the callback address. To ensure only the requester can subscribe to the replies, NanoQueue would need a little feature extension, but this should be relatively trivial.

Now, the messages themselves would possibly look something like the following:

The request:

{
    publish_topic: "general.user.profile.request",
    data: {
        user: "some user id"
    },
    callback_topic: "general.callback.123456789"
}

The public response:

{
    publish_topic: "general.user.profile",
    data: {
        username: "some_dev",
        email: "some_dev@email.some-dev.com",
        display_name: "Some Dev 👨‍💻",
        profile_picture: "http://some-dev.com/pic.png"
    }
}

And the private response:

{
    publish_topic: "general.callback.123456789",
    data: {
        username: "some_dev",
        email: "some_dev@email.some-dev.com",
        display_name: "Some Dev 👨‍💻",
        profile_picture: "http://some-dev.com/pic.png"
    }
}

Bonus feature

As an added bonus feature, NanoQueue supports taking the role as the module registry. If you have a dependency which is a module, not a schema, or want to separate the HTML from the JavaScript code as much as possible, you can have the modules self-register with NanoQueue when they load, for example using self executing anonymous functions ( immediately invoked anonymous function is another name I've seen) to load the module when the script loads.

You can then access the modules using their name:

const myModule = _Q.getModule("myModule");

This also saves you from clobbering the window-object with loads of modules and random variables. You have one place to find your data and dependencies. Only NanoQueue needs to be globally accessible through the window object.

Conclusion

I have not gotten so far in this project, but the broker works. The concept is formulated, but not implemented. NanoQueue lives in a repo on GitHub:

hakash / nanoqueue

Minimal Pub/Sub Message Broker for messaging between components on a page

NanoQueue

Minimal Pub/Sub Message Broker and Module Registry for messaging between components on a page. See https://nanoqueue.dittdesign.com for a live example usage.

Introduction

NanoQueue is a minimalistic messaging broker and module registry for decoupling modules and components on webpages.

NanoQueue registers itself in the global window object as NanoQueue and with the short form _Q. Accessing the framework is as simple as window.NanoQueue, window._Q or in its simplest form, just _Q.

Messaging

NanoQueue is mainly used for sending messages between components, allowing you to have a simple way to make sure hard-to-reach components get their status updates. You can also register multiple components to subscribe to the same topics, allowing you to very easily send the same info to many receivers at once.

This architecture is well known in the cloud native, microservices and scaling spaces as a "Publish/Subscribe" architecture, or as a message driven architechture.

Working…

View on GitHub

I'm guessing the standardised message schemas and the whole concept should have it's own space somewhere, and possibly some tooling to validate the schemas.

I am open for suggestions and comments, contributions and collaborators who can help me shed some light on the concept and spread the word.

Thank you for reading!