All posts by admin

Split Large Audiobooks – A Better Way

In previous article I presented bash script to split large audiobook file into smaller parts. It worked well for me, but has one limitation – if chapters information was not available in the metadata, then file was split into parts of exact size, which was clearly sub-optimal, as split can fall into middle of a word.  So I created new script (this time in Python as logic was bit more complicated, more then I’m conformant to implement in bash), which first detects silent spots in the audiobook and splits file there. Additionally you can also supply external CSV file, which defines  mapping  to chapters (It’s easy to create this file, just require a bit of patience and good tool like audacity to capture the exact positions of chapter ends). I tested my tool on tens of large single file audiobooks and it seems to work fine. You can check this script in its github repo.

Intercept https communication from an Android application

Many Android applications communicate with severs using some form of REST API secured with TLS/SSL (so it’s  “https” protocol).  If it is your application or an open source application you know what’s going on from the source, but for third party application you still may be wondering (hopefully for legit reasons:-), what is this application sending to the server and what it gets back.  With help of few free tools it’s fairly easy to monitor encrypted traffic on your local computer (linux, but it will work on other systems too). Continue reading Intercept https communication from an Android application

Audioserve demo on Heroku

I’ve used free account on Heroku to load there audioserve live demo (with few of my favorite audio books from librivox). It’s fairly easy to implement a docker image on Heroku (just needed to assure that it uses PORT env. variable to bind HTTP listener to this port and to assure that container can run under arbitrary non-root user). See links below if you want to test. Continue reading Audioserve demo on Heroku

Next Audioserve Version

As I’m using audioserve for almost a year, I’m becoming quite keen about it – it’s exactly what I wanted – simple, lightweight and works as I needed. With it listening to audiobooks is just a simple pleasure. Recently I updated audioserve server with couple more features, which might not be essential, but can be useful: multiple transcoding formats  ( meaning target formats) and transcoding cache. Continue reading Next Audioserve Version

Sqlite3 – How Slow Is Write?

Sqlite3 is lightweight relational database, mainly focused on smaller local systems. Being used in Android it’s now probably most spread relational database in world with billions of instances running. Lite in the name means that it is not client-server architecture and it’s intended for lower data volumes – ideal usage profile is read mostly, with occasional writes. Sqlite3 is often used as an embedded data store in various applications (Firefox and Chrome are most prominent ones). Recently I’ve been playing a bit with sqlite3 interface in Rust and had run couple of simple tests especially focused on writes. So how does sqlite3 performs and how it compares with other more typical client-server RDBMS like PostgreSQL?  It’s not any serious benchmark, just couple of toy tests to highlight few things. Continue reading Sqlite3 – How Slow Is Write?

Future Never Sleeps

Recently I’ve been reading this book:  “Network Programming with Rust” by Abhishek Chanda. I found this book bit problematic. It’s just collection of many unrelated examples (often taken from crates documentation), with just little of background and concepts explanation and in some parts this book is just wrong, in other parts it’s using too much simplifications, so the result does not make much sense or worst it introduces some dangerous ideas. One of these  places is part about futures and streams – let’s look at one example: Continue reading Future Never Sleeps

Fearless Upgrades with Typed Languages

One of many advantages of statically typed programing languages like Rust or Java is their resilience to changes in dependent libraries, usually caused by new library versions with modified interface – e.g. the major version changes. In statically typed language we usually see problems in compile time and it should be relatively easy to fix, but in dynamic languages such as Python or Javascript upgrade is more challenging and problems  demonstrate themselves during tests (in better case, when we have good test coverage) or in production in worst case. I had recently came through this process for couple of  relatively small projects in Rust. Couple of dependencies (hyper and tokio) had been upgraded to new versions with significant changes to their interface. With update compilation broke with tens of errors, but gradually I was able to fix all of them (in one case it required to improve error handling with custom error type, plus using additional new library, as typed headers were removed form hyper) and after code compiled and run through basic tests I was pretty sure that I’m fine with new libraries. In similar situation in python I would need much more work to be sure that code works after such major upgrade of dependencies. In practice it enables easier maintenance of code and less effort  to keep it up to date with latest libraries. For library authors it provides more freedom and they can introduce breaking changes more often (with great cargo build tool in Rust library users can pin themselves to older version, if they do not want to upgrade).

From Ignorance to Enlightenment – Playing with Tokio

I have been playing with tokio already in couple of small projects (ptunnel-rust and indirectly (via hyper) in audioserve), but I cannot say that I’m proficient.  Also tokio is very much moving target –  what I used couple month ago is already bit outdated now(old version is tokio_core crate – where default executor was on current thread, now it’s work stealing thread pool). So I decided to refresh and deepen my knowledge and created a toy project –  stupid jokes server –  it’s a TCP sever, which sends a random  joke to client after it connects and then closes connection. Jokes are stored in text file, separated by dashed lines.  My main interest was to test how to use local file system I/Os, which are blocking by nature, with tokio asynchronous approach (so I initially skipped easiest and probably most efficient implementation, where all jokes would be cached in memory).  Usually in a real project you’ll have some blocking code, so I need to know how to handle it. This article is history of my attempts (and failures) recorded in a hope that it might help others in learning tokio (and also writing it down helped me to absorb gained knowledge). Continue reading From Ignorance to Enlightenment – Playing with Tokio