Published on Monday, February 5, 2018 6:00:00 AM UTC in
When I starting playing around with Vue.js, I was also interested in what the deployment story looks like, as this often is a major pain point with other frameworks. My tests were quite satisfying, because the Vue.js Webpack template has a built-in production config that seems to work great. Testing this on a local machine worked flawlessly. The trouble started when I wanted to roll out my sample app to a "real" server. After deployment, I was staring at a blank browser window. No errors, no hints what's wrong, nothing.
Published on Sunday, February 4, 2018 1:00:00 PM UTC in
In my first post on Vue.js, I assumed you want to work with so-called single-file components (SFC). But after playing around with the for a while, I realized that this has major drawbacks too. Here are the details, and other options to work around them.
Published on Sunday, February 4, 2018 12:00:00 AM UTC in
My last post was about setting up a TypeScript environment to work with Vue.js using WebPack. I was amazed about how simple that was and how well features like hot reloading worked. I always want more :). For example, debugging my code using source maps. Shouldn't be too hard, right? Oh boy was I wrong.
Published on Monday, January 22, 2018 7:00:00 AM UTC in
For quite some time now I've been watching the development of Vue.js, listened to talks and tutorials from time to time, read articles - but never made an attempt to actually use it. Why? Maybe I was under the impression that support for TypeScript (which is a main criteria for me with any framework) still is rather fragile and of low priority. Until I read the following a few days ago, that was:
[...] we have included official TypeScript type declarations [...] (Source).
I felt that now is the time to start some first experiments myself. And, frankly, I was pleasantly surprised how simple the setup was. Here's a step by step guide.
Published on Sunday, January 21, 2018 12:25:52 PM UTC in
A few days ago I published a new version of Dapper Extensions Reloaded, a fork of the original Dapper Extensions I created a while ago. I've added some new features, but I also removed a lot of older stuff that I felt were too much "black magic" for me. Here is the full list of changes from last version.
Published on Saturday, January 13, 2018 2:05:16 PM UTC in
Runtastic fällt immer mal wieder durch negative Kritik auf, etwa wenn man zahlende Kunden von ihren eigenen Daten aussperrt, bis sie sich einer Zwangsregistrierung unterwerfen. Aber auch abseits gewinnmaximierender Maßnahmen gibt es bemerkenswerte Fehltritte, insbesondere in Sachen Benutzerfreundlichkeit. Mein jüngstes Negativ-Erlebnis dazu ist einen kurzen Artikel wert.
Published on Friday, January 12, 2018 5:47:09 AM UTC in
Over Christmas I wanted to analyze some of my Git repositories with regards to commit count, contributions by author and other details. I found some nice and simple tools for that, one particular being Git Fame, written in Python. The tool is great, but it had a few problems: first of all it apparently wasn't written for the average Windows user like myself, because it had some problems with author names and non-ASCII characters which in turn needed workarounds on Windows that resulted in misshaped console output. Second, I wasn't quite satisfied with the feature set and performance. My powerful machine was idling along with little CPU and disk load, yet still the remaining hours for the larger repositories was in the upper 20s(!). The output on the other hand was only written to the console, so for further processing i.e. in Excel I had to copy it over into a file and do manual formatting to make it usable. Additionally, statistics per file extension and author were not available at all, you could only have either but not combined. Even worse, depending on the machine I commit from to my repositories, I apparently use slightly different author names (really should fix that), resulting in multiple entries for the same author. Some of these metrics hence were useless, for example: there's a "number of files contributed to" metric that you cannot easily aggregate across multiple author entries without knowing the exact files, an information that is not output by the tool. I'm no Python expert, but a quick look at the sources revealed that the tool was a simple wrapper around the Git command line, which made me think...
Published on Monday, May 29, 2017 5:00:00 AM UTC in
This week, I spontaneously wanted to record a code review as a screencast to watch offline for others. In the past, I've recorded a lot of tutorials and screencasts, however the tools I used to use are not quite state of the art anymore (I loved to use Expression Encoder, for example). Luckily, I remembered that a friend of mine recommended Open Broadcaster Software (or "OBS Studio" for short) recently for streaming and recording, so I decided to take it for a ride. OBS Studio is open source (see GitHub) and very actively maintained. It also seems to have a large community that posts in their forums, publishes guides and creates plugins for the software. Overall, using it was a great experience right from the beginning, and it left a very professional first impression on me. I won't bore you with another "getting started" guide for this software here. What I want to provide is two things to help you improve using OBS Studio for your screencasts: a) Some configuration advise to set you up for an excellent audio experience, and b) a set of recommendations to get the best quality for your screencasts while keeping the filesize at an absolute minimum. Just to be clear on the scope of this post: I focus on the recording side of things (meaning to produce on demand/offline content); the video encoding details I describe here are particularly irrelevant for streaming scenarios.
Published on Wednesday, May 3, 2017 10:01:55 PM UTC in
Als ich gerade eben eine E-Mail mit einem angeblichen Link zu einem geteilten "Google Docs"-Dokument erhielt, wurde ich skeptisch: mit der betreffenden Person hatte ich schon länger keinen Kontakt mehr, und die E-Mail kam völlig kommentarlos. Es roch stark nach Spam und Phishing, aber andererseits sah die E-Mail sehr authentisch aus, und der Link führte eindeutig zur Domäne google.com - eine gute Gelegenheit, sich die Details anzusehen.
Published on Monday, April 10, 2017 4:00:00 AM UTC in
Aurelia's CLI has a watcher feature which - in theory - adds quite some improvement to your daily work: I watches files for changes, recompiles your project automatically and uses browser link to refresh the page you're currently working on. For quite some time the watcher had a rather unpleasant property: it crashed. A lot. Fortunately, that was resolved when a pull request was accepted for the CLI. Disappointment struck when I tested the fix though; yes, the crashes were gone, but the watcher's performance now was horrible. Looking through the code I realized that the fix simply turned off incremental TypeScript builds to get rid of the crash. After a discussion on GitHub, I decided to take a deeper look into this, and - well - here are the results.