Location: Vienna, Austria, EU/Europe
Remote: Yes (open for hybrid in Vienna)
Willing to relocate: No
Technologies: Elixir, Phoenix, Swift, AppKit, UIKit, HTML, CSS, JavaScript, Postgres, SQL, Linux, Shell/Bash
Résumé/CV: https://www.markusbodner.com/resume-markus-bodner-en.pdf
Email: me@markusbodner.com
Spent the past 9 years building my own apps and web-services handling every necessary part of the stack and company. As it is often the case not every such attempt always works so now I am back to looking for a job.
I can pick up new things quickly. That was a requirement for the past few years. And I probably enjoy hunting down a bug too much here and there.
Preferably looking for a part time (30h/week) position.
Apple is using just a bog standard <video>-tag, so this should be a general plea to browser vendors (including Apple/Safari) to add that functionality.
I vaguely recall the video element already having this functionality - I remember an engineer working on it making the playback rate be negative. The performance was not spectacular :)
I'm not surprised and I don't think it's the fault of browsers or the implementation. Delivery codecs have a lot of optimizations around playing forward. There are a whole other class of video codecs designed around the needs of video production; scrubbing, frame-by-frame, playing backwards, etc.
Frame-by-frame and slow-mo should be fundamentally easier than scrubbing/backwards. Nothing about a forward oriented codec would make frame advance or slow-mo harder. You still get a series of image buffers eventually.
When going frame-by-frame you tend to go back and forth.
You can preload and cache, but that leans a lot more on your player and hardware. Yes, you do get every frame but some frames may be very "muddy" because of compression. I'm not saying it's impossible, it's just not an optimized use-case that's trivial with other codecs.
Seeking is another example. It's a hard requirement for video editing, and desirable for users but often compromised for more preferable things like bandwidth and file size. For example, if the data-rate is variable, you don't really know where 3minutes 20seconds into the file is without hunting around (which is trivial if the data-rate is constant). MP3 supports a 1-100% lookup table at the front of the file, but this isn't very granular for long files. Even if you can find the spot in the file, you'll probably snap to an i-frame unless you decode the whole segment.
I'm sure these things will get better as codecs mature and constraints on size and processing power ease up.
Oh yeah it absolutely makes sense - scrubbing backwards through iframes (or is it bframes? I legit can’t remember and codes were never my thing :) ) - it was just funny seeing the massive power usage difference when playing backwards
Aside from a plane dropping out of the sky onto the direct road ahead, would a sufficiently well implemented self driving car ever end up in such a scenario?
The most basic rule of driving is to adjust your distance & speed to the surroundings/conditions. You should always be able to come to a complete stop without hitting anything. Obviously we humans suck at taking everything into account, but would the same hold true for self driving cars?
Swerve (with 60% chance of survival) or break (with a 40% chance of survival). This may sound like sci-fi, but its simple math; if you know the distance of the hazard, coefficient of friction and speed. And you can crunch numbers really fast, these percentages are part of the decision process. And one puts the public at risk and the other puts the driver at risk. Now even if you had no more information and a utilitarian programmer decided to go with the numbers and swerve; swerving off-side will generally endanger the driver and near-side generally will endanger the public.
These conundrums are irrelevant anyway. Over one million people die every year on the roads. The instant AI becomes better than humans, it's a moral imperative to adopt it, no matter what it does in these rare and contrived circumstances.
If this is your motivation then you will want the car to always default to saving the driver over pedestrian. To do otherwise would discourage adoption.
Not sure i'm so comfortable with this; it will result in a number of people killed who never accepted this risk and might have been safe. In order to save a number of people who accepted risk in the first place.
Reading this makes me happy as I'm currently working on a service [0] (not available yet) to allow sites to do this. The goal is to facilitate and make ad selling/scheduling easy while having websites/etc. serve the ads themselves, ensuring no tracking (by my service) is possible.
A lot of people are already doing direct sales via mail and then work out a way to get paid somehow, which can be cumbersome. Hoping to make that easier, while also improving the bad, intrusive behaviour around ads.
I have a feeling the reason why most companies just went with the clickwrap consent is because there isn't really an alternative right now. And it was the path of least resistance ('just add this popup and you're good') to 'conform' with GDPR.
I'm about to have skin in the game as I'm working on an alternative (https://www.adsfromsource.com). Goal is to make advertising more respectful, both in regards to data privacy and in disallowing abusive/misdirecting/etc. ads.
Needed a way to keep track of TV shows I watch and when see when episodes air. All existing sites I found were so messy and bloated with stuff I don't really care about.
Wanted to have a list of new episodes and a heads up about the next few days whats coming up so https://boldshows.com was born.
I've put it online a few days ago but didn't do any 'launch' yet and I don't have the payment process implemented yet so feel free to use it for free until I get that done.
Working on an update for Claire Budget[1] a personal budget tracking app for iPhones. Update is going to bring goals to plan for the future and option to schedule recurring transactions.
I can pick up new things quickly. That was a requirement for the past few years. And I probably enjoy hunting down a bug too much here and there.
Preferably looking for a part time (30h/week) position.
https://markusbodner.com (CV clickable: https://www.markusbodner.com/resume-markus-bodner-en.pdf)