Earlier this year I had the opportunity to develop an app in-house in a small team on our own terms.
We went with Flutter, which I enjoyed a lot and I started to wonder what options there are to make use of that platform agnostic Dart code not only in iOS and Android apps, but in Web front ends, too.
I did some digging and summarised what I could find in a slide deck.
If you are interested in that kind of stuff, make sure to check it out here.
You can get the entire deck on GitHub, too.
I finally managed to update my system to Ubuntu 17.10.
After doing that I wanted to install TeamSpeak 3, which does not come in a .deb file nor is it available through a PPA. While installing and launching it from the cli is straight forward, I wanted to have a launcher for it, so I could start it from Ubuntu 17.10’s application menu like any other app.
After not being satisfied with what Google search brought up (all I found suggested to install alacarte) I did dig a little deeper. What I found is that all you really need to do is to create a .desktop file in
~/.local/share/applications with a specific format.
Check the format based on my TeamSpeak 3 launcher:
Now just double-click the .desktop file and your application will launch and show up in the left dock (where you can add it to favorites, too).
When a bug in your Android app is hard to reproduce, it can make sense to install a debuggable version of your app on more than one device. Some helpful folks shared an easy way to
adb install to all connected devices with just one command on stackoverflow.
Based on that I created the following alias:
alias adb+=adb devices | tail -n +2 | cut -sf 1 | xargs -IX adb -s X
This performs an
adb devices, starts to read from the output’s 2nd line, gets the serial number in each line and for each line builds the command
adb -s *serial number*.
For a full explanation you can check out that command on a web site I find quite useful: explainshell
With that alias in place you can now install your app to all connected devices that show up in
adb devices with nothing more than this:
adb+ install *your_debuggable.apk*
Quick and easy, isn’t it? 🙂
Last week I was surprised to see that the DS apps on my Android phone weren’t able to connect to my DiskStation anymore.
I found out that the latest update to my DiskStation is to blame.
Version DSM 6.0.2-8451 broke the ability to connect to your DikStation through HTTPS for all Android DS apps, except DS Photo.
In the Synology forums people reported that disabling HTTPS/2 support solves the problem.
So in case you experience the same issue just go to Control Panel > Network > DSM Settings and disable HTTP/2 until Synology releases an update to fix this.
UPDATE: Synology released DSM version 6.0.2-8451-2 on the 6th of October. Although there is no mention in the release notes, this update solves the connection issue the Android DS apps encountered since the last DSM udpate. So go ahead an activate HTTP/2 again =)
Recently I found myself looking on some base64 encoded values while debugging.
I had an assumption about inputs and wanted to tell if the string I was looking at was the correct base64 encoded representation of those inputs.
I needed a quick answer and I did not want to use one of the base64 encoders/decoders that are available online.
Turns out with Bash (or Cygwin, if you use Windows) you have everything you need for this simple task:
$ echo -n "param1:param2" | base64
$ echo -n "cGFyYW0xOnBhcmFtMg==" | base64 -d
Just be sure to add
-n option for echo, otherwise a newline is added and encoded!
It is when you start your weekend and notice that your certificates expired, that you start spending your free time on things you actually don’t want to do.
It is when using DSM’s Let’s Encrypt support and a reverse proxy approach for Tomcat, that you actually get to enjoy a sunny Saturday, while your certificates get updated automatically and everything keeps on working without your intervention.
Technology… it’s a good thing 🙂