DEV Community: Peter Hoffmann

AI

Peter Hoffmann — Sun, 11 Jan 2026 16:48:12 +0000

Cannot read property 'digest' of undefined

Peter Hoffmann — Wed, 21 Aug 2019 08:26:38 +0000

I just had the strangest error while trying to generate a simple unique identifier from SHA265(Date()).

The problem

My code looks like this and worked trouble-free developing on my Spontaneous HTTP Server:

async function genSessionId () {
  const msgBuffer = new TextEncoder('utf-8').encode(Date.now())
  const hashBuffer = await window.crypto.subtle.digest('SHA-256', msgBuffer)
  const hashArray = Array.from(new Uint8Array(hashBuffer))
  return hashArray.map(b => ('00' + b.toString(16)).slice(-2)).join('')
}

(source: MDN)

The search

Thanks to the completely meaningless error message I was stunned and had to look really hard to find the reason (I didn't find anything on the dev docs, or MDN web docs). Thanks to some guy on the internet I was directed in the right direction and could finally search in the right corner. Hidden the first paragraph, second indent you find the solution.

The reason

Access to the WebCrypto API is restricted to secure origins (which is to say https:// pages).

(Source: Chromium)

The call

Websecurity is constantly improving, especially Chrome is not only implementing important web technologies with a breathtaking speed but also tightening security vastly. Making HTTPS the default is e.g. for sure the right thing to do.

But.

But we still need to be able to develop in our own setup without being patronized. This is the second experience that already cost me some time and will cost even more as I now have to find a way around this. The whole CORS rules are also very hindering and I wish I could have a switch to turn them of temporarily. Just for development. To be clear, not for the whole browser, I still need it for browsing, just for my dev servers.

The update

Google Web Advocate DasSurma replied to my call: You can add your own "secure origin" via a chrome flag. ❤️

code share: My Spontaneous HTTP-Server

Peter Hoffmann — Wed, 21 Aug 2019 06:58:58 +0000

(Yes, I know, VSCode includes the wonderful Live Server)

Here is my gaffer tape and spray foam solution that allows you to start your HTTP server couch potato style:

Ingredients:

shell,
zenity
netstat
docker (trinitronx/python-simplehttpserver)
pwgen

Directions:

ask for directory
check for currently used ports
randomly select a nice free port
generate a unique container name
serve your directory via a HTTP-server
show link to address with option to close server

View the source

Code Roaster: WebRTC

Peter Hoffmann — Sun, 28 Jul 2019 20:22:12 +0000

Introduction

I want to start a little series with contributions from other people that is called "Code Roaster". This is an invitation to share your code for constructive criticism.

The sentence I hear most often wenn getting shown other peoples code is

I know it's a total mess but it's working and I am going to do it the right way some time in the future.

Let's try to do it right this time and open the lids of our pots and take a look at other peoples' work. Taste it and add your grain of salt.

About me and my work

Hy, I'm working as a full stack developer in a German university and constantly try to improve my skills in programming while keeping up to date with current developments in web technologies. My greatest struggle in IT is the never ending fight against support for outdated browsers (like IE10) and their technological backlog.

Today's project

In 2013 Chris Ball published a serverless WebRTC example that let signaling be done by the user e.g. via IM. The code was maintained for three years until no further development was done. My target was to minimize the example to the smallest working code base using modern web techniques in vanilla js.

I took the code, threw away everything that was unnecessary in my eyes and tried to separate webrtc logic from the user interface. I thereby lost all design as I really suck at that (invitations to anybody who is looking for an ui/ux exercise).

Design decisions

I separated the login into two classes/modules that interact through events. The coupling seems unnecessary complicated:

    const webRtc = new WebRTC(stunServers)
    const gui = new GUI(webRtc)
    webRtc.weave(gui)

Perhaps anybody has an idea how to polish this? Aside from this I don't see any way to improve my code. I invite you to drop your 2¢ for nicer, easier readable, faster running, reusable, maintainable, well structured code.
Fire up the roaster!

Code

The full project can be found at Github

GUI module

/* global EventTarget, CustomEvent */

function timestamp () {
  return (new Date()).toTimeString().substr(0, 8)
}

export default class GUI extends EventTarget {
  constructor (target) {
    super()
    this.target = target

    this.connect = document.querySelector('.connect')
    this.connect.querySelector('button').addEventListener('click', _ => this.clickConnect())
    this.descriptionBox = this.connect.querySelector('textarea')
    this.descriptionBox.value = ''

    this.chat = document.querySelector('.chat')
    this.chat.querySelector('button').addEventListener('click', _ => this.sendMessage())
    this.messageBox = this.chat.querySelector('input[type="text"]')
    this.chatBox = this.chat.querySelector('.chatlog')

    this.addEventListener('candidate', candidateEvent => (this.descriptionBox.value = JSON.stringify(candidateEvent.detail)))
    this.addEventListener('connect', connectEvent => {
      this.connect.style.display = 'none'
      this.chat.style.display = 'initial'
    })
    this.addEventListener('message', messageEvent => this._addChatLine(messageEvent.detail, 'you'))
  }

  trigger (name, detail) {
    this.target.dispatchEvent(new CustomEvent(name, { bubbles: true, detail: detail }))
  }

  clickConnect () {
    const description = this.descriptionBox.value
    try {
      this.trigger('connect', JSON.parse(description))
    } catch (e) {
      this.trigger('connect')
    }
    this.descriptionBox.value = ''
  }

  sendMessage () {
    const message = this.messageBox.value
    if (message.length) {
      this._addChatLine(message, 'me')
      this.trigger('message', message)
    }
    this.messageBox.value = ''
  }

  _addChatLine (text, type) {
    this.chatBox.insertAdjacentHTML('beforeend', `<p class="from-${type}">[${timestamp()}] ${text}</p>`)
    this.chatBox.scrollTop = this.chatBox.scrollHeight
  }
}

WebRTC module

/* global EventTarget, RTCPeerConnection, CustomEvent */

export default class webRTC extends EventTarget {
  constructor (iceServers) {
    super()
    this.connection = new RTCPeerConnection({ 'iceServers': iceServers })
    this.connection.addEventListener('icecandidate',
      ICECandidateEvent => ICECandidateEvent.candidate === null && this.trigger('candidate', this.connection.localDescription))
    this.connection.addEventListener('datachannel',
      ChannelEvent => this.connectChannel(ChannelEvent.channel))
    this.addEventListener('connect', this.connectHandler)
  }

  weave (target) {
    this.target = target
  }

  trigger (name, detail) {
    this.target.dispatchEvent(new CustomEvent(name, { bubbles: true, detail: detail }))
  }

  connectHandler (connectEvent) {
    switch (this.connection.signalingState) {
      case 'stable':
        if (connectEvent.detail === null) {
          this.setupChannel()
          this.connection.createOffer()
            .then(desc => this.connection.setLocalDescription(desc))
        } else {
          this.connection.setRemoteDescription(connectEvent.detail)
          this.connection.createAnswer()
            .then(desc => this.connection.setLocalDescription(desc))
        }
        break
      case 'have-local-offer':
        this.connection.setRemoteDescription(connectEvent.detail)
    }
  }

  setupChannel () {
    this.connectChannel(this.connection.createDataChannel('channel'))
  }

  connectChannel (channel) {
    channel.addEventListener('open', _ => this.trigger('connect'))
    channel.addEventListener('message', messageEvent => this.trigger('message', messageEvent.data))
    this.addEventListener('message', message => channel.send(message.detail))
  }
}

Returns, callbacks and the whole zoo

Peter Hoffmann — Tue, 05 Jun 2018 09:24:23 +0000

I'm currently co-developing a standardized communication between two entities A and B. To release my mind from all the thoughts about how an why and balancing benefits and drawbacks of different methods I'd like to share them with you. And maybe your 2¢ will help me optimizing our strategy. I'd like to add that my context is browser based JavaScript but some ideas might be generalizable.

➡ calling

If A wants to call B I find the following ways:

Calling a predefined function/method in the scope of A: [B.]act(param)
Using a common communication transport:
1. by message: transport.postMessage({action: act, parameter: param}) used in inter-frame and main-thread/worker-thread communication but also (miss)usable within one document context (see Appendix A)
2. by event: transport.dispatchEvent(new actEvent(param)).

The second point might seem overelaborate but is quite useful for decoupling and even necessary if both entities are not in the same context. One advantage of the second way is that A will just continue to work even if B is (temporarily) not available. But on the other hand B needs to actively listen to the specified events (a message is received just like any other event).

⬅ answering

There are more ways for B to react and submit a success state or return data from acting.

directly return a result in case of ➡1: function act(param) { …; return success }
alike ➡1: call a predefined function/method in the scope of B: [A.]doneActing(success)
alike ➡2: use a common transport e.g. transport.dispatchEvent(new doneActingEvent(success)
use a callback contained in param: param.callWhenDone(success)
return a promise, fulfilled or rejected depending on success return new Promise(function (f, r) { (success ? f : r)(successData) })

The first is the standard way for all non-asynchronous contexts and again the second might be necessary in some cases. Asynchronous decoupling is achieved by callbacks resp. promises while promises seem to be the new "right" way to do it.

conclusion?

What are your thoughts, when should one use either one? Is interchangeability shown in Appendix B leading to one way for entity A and another for B? What about a hierarchy between both entities, would your recommendation change depending on weather A or B are more important?

Appendix

A: inter-window communication using `postMessage`

class B {
  constructor (targetWindow) {
    targetWindow.addEventListener('message', message => console.log(`B is reading: '${message.data}'`))
  }
}

class A {
  constructor (targetWindowOfB) {
    this.targetOfB = targetWindowOfB
  }
  letBAct (message) {
    this.targetOfB.postMessage(message, '*')
  }
}

let entityA = new A(window)
let entityB = new B(window)
entityA.letBAct('Hy, here is A, are you listening?')

B is reading: 'Hy, here is A, are you listening?'

B: transformation

Finally the trivial, most methods are interchangeable (1 is left out as a target). Here interchangeable n ➝ m is defined as the answering entity using method n and the receiving entity using method m.

1 ➝ 2:

doneActing(act(param))

1 ➝ 3:

transport.dispatchEvent(new doneActingEvent(act(param)))

1 ➝ 4:

param.callWhenDone(act(param))

1 ➝ 5:

var returnPromise = new Promise(function (f, r) {
  let success = act(param)
  (success ? f : r)(success)
  /* or */
  f(act(param))
})

2 ➝ 3:

function doneActing (success) {
  transport.dispatchEvent(new doneActingEvent(success))
}

2 ➝ 4:

function doneActing(success) {
    param.callWhenDone(success)
}

2 ➝ 5:

let returnPromise = new Promise(function (f, r) {
  function doneActing(success) {
    (success ? f : r)(success)
  }
})

3 ➝ 2:

transport.addEventListener('doneActingEvent', event => doneActing(event.data))

3 ➝ 4:

transport.addEventListener('doneActingEvent', event => param.callWhenDone(event.data))

3 ➝ 5:

let returnPromise = new Promise(function (f, r) {
  transport.addEventListener('doneActingEvent', event => (event.data ? f : r)(event.data))
})

4 ➝ 2:

param.callWhenDone = doneActing

4 ➝ 3:

param.callWhenDone = success => transport.dispatchEvent(new doneActingEvent(success))

4 ➝ 5:

let returnPromise = new Promise(function (f, r) {
  param.callWhenDone = success => (success ? f : r)(success)
})

5 ➝ 2:

promiseResponse.finally(doneActing)

5 ➝ 3:

promiseResponse.finally(param.callWhenDone)

5 ➝ 4:

promiseResponse.finally(success => transport.dispatchEvent(new doneActingEvent(success))

Let's find something better than LaTeX

Peter Hoffmann — Thu, 21 Sep 2017 10:12:40 +0000

Filling my need for a response to Nicky's pro LaTeX article I'd like to explain why LaTeX is a failed project to me. Yes, I have strong feelings about this documentation system, but - just for further reference - not towards its users as I am unfortunately one of them.

My history with LaTeX

Before I start to explain why I think one should get as many miles between them and this devilish system I need to tell you about my history with LaTeX so you can understand why my claim has evolved over years and is not just the result of a frustrated sunny afternoon. But please, you are free so skip this section.

My story starts even before my first semester a university: I remember how impressed I was by the fine layout of letters a supervisor during a school internship was able to print with the greatest of ease. He only edited the raw text, the important part, there was no formatting by hand, no clicking and searching, the antithesis of everything I had learned so far about word processing (it was the time of Microsoft Office 95).

Some years later I attended my first lecture in mathematics and had to do weekly assignments. But years of online chatting had regressed my handwriting to the look of indecipherable German runes. Being proud of my genius solutions I typeset every single page in most wonderful calligraphic formulas with the help of the even more genius power of LaTeX (thanks to D. Knuth and L. Lamport).

My next noteworthy experience were protocols of the practical training in physics that had to be conducted by two or three students. The team had to coordinate the gluing together of their pieces of text and numbers, measurements and conclusions, drawings and bibliography. Once again LaTeX to the rescue! Simple text was easily transferable from Windows to Linux to Mac, always looking the same, always looking good.

And even now my current employment includes LaTeX. We are automagicaly (actually rather in a not-to-complicated process of statistics and some text processing) generating umpteen documents containing the results of educational research for ten thousand schools, its teachers and students. Together millions of pages that no army of minions could ever put together even with the most sophisticated feature of MS Word series letters.

A short overview of the advantages of LaTeX

To conclude all the above I repeat all the advantages of the superior word processing system LaTeX.

Separation of content, automatic content and design: There is no need to think about page numbering, headline sizes, widows and orphans, table of contents, of figures, of tables, hyphenation, accentuation, font selection and figure placement. All that design stuff you don't know anyway is just taken care of in a professional manner. If you want to write a letter you start with "Dear Mrs. Receiver…" and even your final "My best wishes B." will be auto completed by your devoted servant LaTeX.
Typesetting of formulas: Superset two as square, integral or sum sign, naturally with super- and suberscript limits, these ancient Greek letters you still don't know how to pronounce (φ and ψ, ζ and ξ, can you even distinguish them in your own handwriting?) and fractions over fractions: LaTeX combines all of them to not a mayhem of numbers, letters and signs but a piece of typesetting art (still only understandable to the eye trained in arcane arts as differential calculus and algebraic geometry but nevertheless).
Text based: There is no format more open than the American Standard Code for Information Interchange, the base of all (computer based) writing, no raw binary code and everything well-defined and deductible. You can easily share your text, do a diff of all the changes your colleague made and easily spot the corrections of your proofreaders, version control the progress including all its advantages like branching, jumping in history, merging…. In short by using LaTeX you have everything we are used to and expect in software development.
Mass process able: Based on well-established software you can process thousands of documents in a reasonable time, each (as it is based on raw text) with small or large differences, generated by your favorable programming language and adjusted specifically to its purpose.

A longer overview of why I hate LaTeX so much

But why on earth, you ask, am I complaining about LaTeX even so until now I have only convinced you to de-install every word processor, scratch the DVDs, cancel your Office 365 subscription and live happily ever after?

Clumsy Syntax LaTeX depends on slashes, braces and square brackets. But you never know whether something is an environment or a function, which parameter is optional (hence square brackets) and which required, named or assigned by position. There is no previous knowledge you can build on neither for syntax nor the huge vocabulary. Be prepared for a livelong journey of learning and do never forget.
Package dependence The power of LaTeX (itself an extension of TeX) comes from some powerful packages that may localize your whole document, allow you to write chemical structural formulas of complicated organic molecules or just make really nice tables. But they have a downside. Rather than carefully extending its power, staring the most used and best supervised packages, pearls lie next to filth. The myriad of badly programmed, documented and abandoned packages that are the only way to archive that tiny feature MS Word would have handed you in the blink of an eye are bringing down the whole ecosystem. And as an icing: those packages might interact with each other producing either complete nonsense, some strange looking, fragile butterfly or just a broken document that won't compile. You will be that script kiddie just throwing together pieces of code someone recommended on Stack Overflow but never understood to reach your desired result.
Design abduction I never even heard of someone who could style a LaTeX document. Is there a designer that can really use this through and trough logical markup and make something beautiful of it? Don't get me wrong, LaTeX itself produces remarkable results but nothing fancy, nothing new. You will recognize a thesis typeset in LaTeX even by the scrap pieces coming out of a paper shredder. Every way I know to make something look different in LaTeX is brutally tearing down the barrier between content and design and not designing itself.
Objects floating away LaTeX promises to place all your non-text objects like tables, graphics and images at the exact right place so that text and non-text are balanced perfectly. The reality is that all that stuff will end up right at the end of each chapter like your weekend shopping hitting your windshield after you hit the brakes to hard. While the concept of floating objects might sound wise in reality, you most often just want to put your diagram next to the text describing it.
Spiderweb of Error(?)-Messages Like any (computer) language LaTeX is build on lexical rules defining how a command is written and which symbols are placed where as well as semantic rules about the placement of commands in or after each other. And naturally you will break these rules again and again. To make you learn faster LaTeX will punish you fiercely every time. The cryptic error message(s) will be hidden in a gibberish of debugging messages, meaningless outputs of page numbers, overfull \hboxs and nonsensical anecdotes of the compiler's childhood memories, spitting out text of every level of verbosity like a drunk toddler hitting keys on a toy piano (the cover image shows an complete output of an error message for one missing }). You will search for hours for forgotten braces, environments closed to early or to late and for elements that just won't work together. And that is not even considering external packages. You will cry, seriously think about rewriting your whole thesis on one of those mechanical typewriters and promise yourself to never ever ever touch LaTeX again.

Searching phoenix

So what is the solution, what is better, what is the least bad way to crowd edit, constantly review and mass produce long, beautiful document obeying to the serious rules of typesetting maybe even with formulas and graphics inside them?

There is are new generation of markup languages like markdown so much lighter
in syntax that I'm not ashamed to ask our employees to use. There are powerful systems like the HTML & CSS, scriptable by JS. Most of the big browsers have some sort of headless mode that could be converting HTML-documents to PDF with only some tiny features missing (like CSS regions, please?). A great introduction into the current state is the List of CSS features required for paged media.

I want to thank the creators of LaTeX because so much wisdom and so many thoughts went into this astonishing complex system. But only due to their generosity all that algorithms are free and open source. All that thirty year old code, balancing symbols in formulas, words in lines and lines in pages is not limited to LaTeX any more but already lives in modern Word Processors and can be still build into new, hopefully better software (e.g. MathJax).

We have all the tools we need for a new generation of documentation systems adjusted to current needs. Can we please let LaTeX be the tool of its time and move on to new ventures? Once again dwarfs on the shoulders of giants could be the new giants.