In past 5 years Stackoverflow was running a comprehensive survey (here is latest for 2019), which, among other questions, asked for ‘most loved programming language’ – which basically means language developers used, like it and definitely want to continue with. Rust is doing very well in this category – it leads this category for past 4 years ( and this was one of reasons, why I started to play with Rust). As this SO survey (with similar questions) is around for 5 years, it’s about time to put data in chart: Continue reading Rust, I love you, I really do
As much as I do like Rust I have to admit there are some disadvantages of using this language – one common problem is immaturity and fragmentation of libraries – I encountered this recently when I was looking for a way how create a websocket endpoint for audioserve. audioserve is using low level HTTP library hyper – as it’s API is quite simple (which was it’s key design principle). I wanted to add websocket support on lowest possible level. Actually it turned out as not totally trivial – some frameworks like warp or actix have build in websocket support, but for pure hyper + websocket we have to start from bottom. Continue reading Hyper Websocket
Recently I wanted to create completely static build of audioserve – so it can be easily moved and run on any modern 64bit linux without any other actions. Rust provides some guidelines for static building, but it still took me some time to make it work, mainly due to dependencies on other C/C++ libraries (libssl, libavformat …). So here I my experiences: Continue reading Static Build of Rust Executables
I think I noticed in this article that Rust Future is basically a state machine, which is propagated through its states via appropriate runtime (and parked when not ready to move to a next state). But I did not appreciate this fact fully until recently I was making a small utility (here is new version for new futures and tokio) for creating tar archive asynchronously – it should be a Stream that produces chunks of data – first file header and then pieces of it’s content. When file is done move to next file, until all required files are sent to stream, then finally send two empty blocks, each of 512 bytes of binary zeros. I needed this Stream for my audioserve project, where I wanted to download content of whole directory as a tar archive. Stream is a kind of Future (which produces many values instead of just one), so it’s also a state machine. And when I started to think about it this way, implementation was obvious. Rust algebraic type system is of great help here as we can represent state with one complex enum type ( called TarState in this case) and it’s variants represent states of this state machine and also contain necessary internal variables for each state. So lets see state diagram for our TarStream: Continue reading Future Is A State Machine
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.
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
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
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 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?