Christian Heilmann

You are currently browsing the Christian Heilmann blog archives for August, 2021.

Archive for August, 2021

Using console.log() on any website? Logpoints let you do that!

Tuesday, August 24th, 2021

The demo page with developer tools and the logpoint editor open.

If you want to know the value of a certain expression in any JavaScript on the web, you can use logpoints for that. It is like injecting a console.log() anywhere you want.

Here’s a quick demo:

Here’s how the demo works:

  • Open https://codepo8.github.io/dog-browser/ in the browser
  • Open Developer Tools, go to the Sources tool
  • Locate ‘walkies.js’ and open it
  • Right-click the line number where you’d like to add a logpoint – in this case line 57
  • Select Add logpoint to open the editor
  • In the Editor, enter the expression that you’d like to log – in this case “data”.
  • Hit Enter to save and a badge shows on the line number.
  • Go to the Console, interact with the site and every time line 57 executes, you see the result of the logpoint expression to the console.

You can set as many logpoints as you want. Clicking the badge again removes them.

Quick tip: creating round “talking heads” videos in Screenflow

Monday, August 23rd, 2021

Adding your face in a small circle to videos has become fashionable lately and some extensions do that automatically for you. Good old Screenflow, which I’ve used for years now, has no masking option though. But you still can achieve round videos using a setting and learning that screenflow’s sliders are weird.

By default, Screenflow will record the video in full size (in my case 1920 by 1080 pixels), resize it and place it on the bottom right.

The default size and setting of the camera recording in Screenflow

Make sure the video is active, indicated by a yellow border around it, and select the Video tool. This gives you all kind of settings to play with. First, reset the scale to 100% and the position to 0 and 0, which shows the video as full screen covering the other recording.

Resizing and placing the video to be full screen so that you can change the dimensions

Now you need to ensure that your video is square and that you set the right border-radius. The problem here is that Screenflow’s sliders don’t go further than 400. I suppose that’s some legacy debt when videos were 800 by 600 pixels. You can, however, enter any number in the text fields.

In my case, the video is 1920 by 1080, so in the crop setting I need to take 420 pixels from the left and the right as (1920 – 1080) / 2 = 420. For the radius I need to set 540 because the final video is 1080 by 1080:

The video settings panel with the right settings

And that results in a rounded video:

Final version of the rounded video

The last step is to set the scale and place the video. And you can add a drop shadow if you want to:

Scaled rounded video, placed bottom right with a drop shadow

Published on TikTok, but Kompressor does not dance

Wednesday, August 11th, 2021

Visual Studio Code now has a TikTok channel and they asked me if I wanted to contribute, so here you are:

@vscode

A look under the hood ##vscode ##techtok ##codetok ##programming ##edutok

♬ original sound – Visual Studio Code

A 20 second video of me explaining that I like VS Code a lot as it comes with DevTools built in where you can see how the interface was done with HTML/CSS and JS.

Here’s how I did it:

  • Filmed me saying all the things on my balcony with my phone
  • Recorded my screen using Screenflow doing the things that I talked about
  • Created a 1080×1920 new project in Screenflow
  • Added my video as the background (weirdly enough I had to rotate it 90 degrees)
  • Resized the screen recordings accordingly and added a zoom action to the second one.

Screenshot of the screenflow template with the different video streams and editing interface

I had a longer meeting with the VS Code team on the merits of TikTok and how you reach a different audience that way. And I learned that edutok is a thing.
I don’t like the portrait format for showing off full code editors or browser functionality where the app by default is landscape, but I can see doing more of these in the future for the VS Code team. As to me joining TikTok, not sure. It already annoyed the hell out of me that the video keeps looping while I am answering comments.

[Video] Learn how to debug web projects end-to-end in VS Code in 5 minutes

Monday, August 9th, 2021

Still of the video showing me debugging a web site in VS Code.

This weekend I released a video on the YouTube Channel of Visual Studio Code that shows end-to-end web project debugging.

In five minutes I walk through debugging a web project bit by bit:

  • I open a project inside VS Code by opening its folder. The demo used is a simple, plain Vanilla JS/CSS/HTML ToDo app you can download/fork on GitHub.
  • I open a Terminal inside VS Code and start a local server. I use the server that comes with PHP as it already on my computer (for now – MacOS will soon deprecate this option)
  • Instead of opening the project in the browser, I use the run and debug workflow of VS Code to open a dedicated browser instance to debug this project with. If I have a Chromium based browser on my device and have it set as my default browser, this will be the one VS Code uses. In my case, this opens a new window of Microsoft Edge, as this is my main browser on this MacOS computer (yes, it runs on Mac for over 1.5 years now). I use Edge to show extra functionality later that is only supported in this Chromium based browser.
  • Having a dedicated browser instance also means that I get the Browser Developer Tools Console functionality now inside the Debug Console of Visual Studio Code. The Debug Console shows any console.log messages from my JavaScript and I can also interact with the document in the browser using the Console convenience methods like $ for querySelector(). I have full access to the window object and can change the DOM and the styles of the document in a programatic way.
  • In addition to console.log() debugging I also have the opportunity to use breakpoint debugging instead, which gives me a lot more insight and also has the benefit of halting the execution of my script until I found out what’s going on.
  • As I am using Microsoft Edge as the debugging browser I also get an inspect button on the debugger toolbar. This one gives me access to the Edge Developer Tools right inside Visual Studio Code. This functionality is powered by the Edge Tools for VS Code extension which gets installed for me the first time I select the inspect button
  • Once the extension runs, I can access and change the DOM and the CSS of the current project right inside Visual Studio Code using the same tools I normally use in the browser.
  • I also have access to the Network tool to inspect any Network requests and see if there are any issues of content not being loaded.
  • In order to automate the process of starting the browser and opening the localhost address next time, I can also get the debugger extension to generate a launch.json file for me. Once I have that, next time all of the above happens automatically.

If you want to learn more about the JavaScript debugger in VS Code, you can check the documentation here or talk to Connor Peet on Twitter. For the Edge DevTools for VS Code integration you can read the extension documentation and check the code on GitHub. We’re also welcoming filing any issues on GitHub and you can talk to me, codepo8 on Twitter or the team at EdgeDevTools

A special thank you to the team involved in all this work, James Lissiak, Michael Liao, Vidal Guillermo Diazleal Ortega, Brandon Goddard, Olivia Flynn, Tony Ross, Rob Paveza, Jason Stephen, Connor Peet and of course the VS Code team.

Happy Birthday, WWW – 30 years of mining a landfill for valid code

Friday, August 6th, 2021

Sifting for gold in a pan full of rubble

Today the World Wide Web is 30 years old. I’ve worked on it since 1997 or so and I saw a lot of technologies and design trends come and go. I’ve also seen a lot of “this is much better and will replace the web” solutions come and go. What remained is the web with its “dumb” technologies HTTP, HTML and CSS. Each of them are forgiving in their nature. They allow developers to make mistakes without punishing the end user. Many people sing the praise of this approach and architecture, so I’m not going to repeat it.

Enter JavaScript. When I started with JavaScript, it was a fun thing to do as it prevented you from having to reload a document. You could validate a a form and tell people they forgot something. A much better experience than finding out after a few seconds of loading the document. And of course hoping people in the other room don’t pick up the phone and interrupt your modem connection.

JavaScript is fun to work with as a developer. You can generate HTML and CSS with it and you have full control over what you create. You can detect things like window size and if certain technologies are supported and create content accordingly. You can load things on demand and only when the user needs them. It feels great to be in control.

CSS and HTML, on the other hand, feel like you give away control and hope for the best that it will work. There is no feedback channel, you can’t set up an error trap. That’s on purpose and the main thing to learn as a web developer is that you aren’t in control, but your users are. The more flexible your solution is to cater to the needs of your user, the more successful it will be. “Survival of the fittest” isn’t about strength, but about adaptability.

JavaScript isn’t a web technology. It isn’t governed by the W3C but by ECMA. What works and doesn’t work in JavaScript is dependent on browser makers. What you can use in JavaScript is also dependent on the end user having a “modern” browser. “Modern” means nothing, by the way, and I wished we stopped using that term as it is fleeting.

Other things that affect your JavaScript happiness are proxies and blocker add-ons. Or bad connectivity and a file not loading. The issue is that JavaScript isn’t as forgiving as HTML and CSS is – when you do something wrong, things break. Used wrongly, JavaScript can seriously affect the performance and even the security of the web product you create. To a degree this also applies to CSS and HTML, but you have a lot more power with JavaScript.

However, if you work with a new-ish computer on a fast connection, you are most likely not savvy to any of these issues. Instead, you’re prone to pile up more and more dependencies and code to increase your developer convenience.

When it comes to used technologies of the web, it shouldn’t be a surprise that a lot of it depends on JavaScript. And on not well-thought-out, hacky and unmaintained JavaScript to boot. Libraries don’t get updated regularly despite blatant security issues in them. Stop-gap solutions built to work around an issue of a browser in a certain version never get removed.

The web is a landfill of accumulated, unmaintained and often bafflingly bad code. And yet it works. This isn’t only the result of sturdy technologies driving it. It is – to a large part – browsers doing anything they can not to break the web.

The first browser I used as a daily driver was Netscape 3. Netscape had no chill. If you didn’t close your tables in your HTML, it didn’t show anything. That taught me to value HTML validators as part of my workflow. But these days browsers can’t ever break the web. Whatever you throw at them, something will render. And that takes a lot of work and we should thank browser makers more as that is something that kept the web alive.

Working on browsers taught me a lot of things and made me a lot more humble than I was when I was a web developer. As a web developer I thought browser makers keep the web from evolving as it doesn’t affect their bottom line. As a developer working for browsers I learned that a huge part of the engine is dedicated to backwards compatibility. JavaScript engines make sure that code that performs badly because of the way it was written still runs smoothly. And new features of the platform only get into production after making sure that they aren’t a security, accessiblity or performance issue.

So, when we celebrate the web today, I also think we should celebrate the people who built the technology that enabled it. Browser makers, framework creators, server-software creators and all the people working on the infrastructure of it.

Of course it is damn cool that the first web site ever (and yes, the Space Jam one – enough already) still renders in browsers now. The reason is though that these web sites don’t do anything hard and are quite clean code. That the web in between, with the crimes of DHTML, the library and browser wars and all the hacks people put in there to achieve a certain effect still renders is because of browsers allowing for this.

I would love to be able to make browsers a lot leaner. But the web we have now is a mess. A wonderful, exciting mess that allows anyone to take part in it as a creator. And that’s thanks to its base technologies and to a lot of people in browser companies making sure it keeps working.