Ten days ago, I got myself a Pebble. Yes, a Pebble. In the light of the recent announcements of the now-ex-manufacturer of the Pebble, this sounds like one of the most idiotic ideas ever, and it probably was. The thing is, it was never as cheap to get one of these. I paid less than 100 EUR for a Pebble Time. And I was genuinely interested in the ecosystem. I’m not a watch person, for the most part, otherwise I probably would have gotten one earlier. And now, I’m wearing a Pebble for 10 days and even though reviewing it seems kind of pointless right now, as it is not a product with any sort of future (apart from a few faithful hackers trying to rescue the ecosystem), I think it might actually be interesting to share my findings, especially in the light of the company’s demise.
I love web development, like to dabble a bit with hardware, especially music related electronics, and, apart from that, will happily apply my coding skills wherever possible.
Mostly for historic reasons the blog articles on this site are written in two languages: The german articles are usually a bit more personal or even political, while the english articles are more work- and tech related.
This may only be of interest to some of you, but it’s something I wanted to have documented somewhere, so that’s why I made a blog post out of it.
I just got my Modal Electronics CRAFT synth, a surprisingly powerful little synthesizer that comes in a very interesting form factor.
(Update: Today, the app(s) came out and I updated some information in the gist and in this article).
Over the last few weeks, I had random conversations with people where the US presidential elections came up. On more than one occasion, someone brought up the typical “Well, Trump is a crazy person, but the American president doesn’t have that much power anyway, so what should go wrong. And by the way, Hillary is a Hawk and that might be really bad, too” line.
By the way, this is a European perspective, but I assume it is something Americans have heard in conversations as well.
Here’s a few reasons why I think this line of thinking is extremely lazy and dangerous:
On thursday night, I planned to work a little on this big ember app I’m working on for a client. For some reason, even though my app was the only tab opened, Chrome had a pretty high CPU usage. Now, I know Chrome is generally good at that, but I was intrigued. My app can use quite a bit of your CPU at times, but just sitting there, idling around, this should not happen. Opening the Chrome task manager, I determined that indeed, it was my app that was causing the load.
I started to do more and more screencasts (mostly for Open Color Tools) and today I finally had the feeling that I didn’t screw up completely.
Here’s what I think I have learned so far:
There are several HOWTO’s on the web, there’s even a gem, but all of them are slightly outdated or not fitting for my use case, so here’s how I’ve integrated Jekyll into our Rails on Heroku setup for a small project.
The goal was to use Jekyll for both the marketing homepage of the product and as a blogging engine. I also wanted Heroku to do the jekyll build process on publish and thus not having to check in the artifacts aka generated websites. There are some pitfalls that I came across, so that’s another reason for documenting it here.
Today, I came across a great article by Bodo, a friend from Berlin that can be best summed up with a tweet from him:
Dear CTOs: if one of your developers has to work long hours, don’t brag about it. It’s a sign that you are failing at your job. Big time.— Bodo Tasche (@bitboxer) August 7, 2016
I couldn’t agree more - I myself had to learn this the hard way, though. I shared a bit of my own experience on twitter today, but I felt like this could use some more words.
One day, I’m going to do a writeup of the technical restructuring I just did on probably one of my most important projects right now. Today is not that day, because I want to talk about the reasoning and the history of that rewrite instead, on a meta level.
I’m currently building an open source library published to npm to parse and render a file format we’ve designed for Open Color Tools. We’ve built a first prototype using a YAML parser and doing some preprocessing, but the format quickly evolved into something that was essentially incompatible with YAML, so we needed a new solution.
The first time I tried my luck in parsing binary files within the browser must have been the Cloudtracker2 project, my (slightly out of date) try to make a good Protracker player/Editor for the web (It sort of lives on in the Halfplayer project if you’re interested). Parsing binary files in the browser is actually no longer a problem, but I thought it might be a fun exercise to write down some notes on what I’ve come across in one of my current projects, which involves intensive binary data munging on a much bigger scale than what I have tried so far.
So, here’s the toolboxes contents:
Additionally, we’re going to talk about file drag and drop, creating object URLs and other things.
Someone has been wrong on the internet. I hate it when that happens. And so I started to write a comment and then I thought to my self, hey, this is great blog post material, why should I waste it on someone who is wrong on the internet. So here we go. It reads like a comment on someone who was wrong on the internet at times, because that’s exactly what it is :)
Today, I’ve stumbled across a blog post, via RubyFlow, which is boldly named Ruby on Pains by Facundo Spagnuolo. It is a melange of falsly applied pure OOD wisdom and (I can only assume) juvenile arrogance (Do I sould like an old fart already? I’m in my forties now, I have to sound like an old fart now), that made me a little angry and made me want to reply. Not sure this is a winning move, but I think my reply does contain some parts that bear repeating, so here we go.