How to setup a minimal Laptop as a Focused Writing Tool.

These days I had a chance to catch up with my siblings and found myself in an interesting discussion with my brother, about a simple setup for mobile authoring of documents.

And as I pondered that question during my trip back home, I came up with some ideas about how to build the type of machine we talked about. Namely something small resembling a laptop, but with a dumbed down feature set, to avoid the distractions of the Internet, Email and various other features of a modern laptop.

I thought about building a customized laptop, based around an ARM board, eventually with a custom designed mechanical keyboard, and a custom Linux based OS, with limited applications, eventually even a built in power adapter, to reduce the number of items to carry on a trip.

But as I was working from my train seat, I noticed that in some way, I already have quite a good machine for writing from on the go.

Because ideally, the device that we conceived would be simple that it could be used like a single purpose appliance. Instantly on, without the boot process of a laptop.

But as I am writing this from a MacBook, I remembered how hassle free the standby mode is, compared to all the Windows and Linux laptops, that I would use as well.

And I already do use a kind of “distraction free” writing environment customized to me needs. For me that is a VIM with the “Goyo” plugin, running inside a tmux console, in the terminal app.

Goya, provides a simple centered writing space similar to what other “distraction free” editors would provide. I use the tmux feature to hide the status bar, and I usually run the terminal in full screen. For me that is quite sufficient, as I have tmux usually always running, for opening new terminals, doing programming, connecting to servers etc. And as a Vim enthusiast and heavy user, I am quite comfortable with the cumbersome keyboard shortcuts.

Just getting the instant standby operation as smooth as on the Mac when creating a custom device and motherboard, would probably be an intense experience of yak shaving, I thought about the option to just use a Mac based laptop for the ideal basic writing machine.

It would require the discipline of only using the machine for writing and sending email, but some discipline is required for writing as well. And getting something like a used small MacBookAir, to set it all up, would probably not be even that expensive.

And even for software options for my brother, a few came to my mind. There exists an app called “Typora” for the Mac, which provides a very streamlined and distraction free option for producing “Markdown” documents, without the hassle of actually needing to write markup, as it is a WYSIWYG Markdown Editor. It has a distraction free fullscreen mode, and is as basic and minimal as it gets.

Other than that, the Machine could probably be dumbed down to the essentials, WiFi could be disabled, and with a cleaned up Dock, it could distraction free as well. Considering that Typora would be kept in Fullscreen anyways, and the Machine would wake up to the empty page or last document of the editor.

And even for the requirement of sending the occasional email without getting sidetracked by an obnoxious display of the inbox I think I saw a solution in the experimental “Plain Email” that kind of provides a distraction free Email Composer.

I am not quite sure if “Plain Email” is ready for actual use, but given the constraints I would be curious to try it, and see if we can get such a machine to work as to our intentions.

HOWTO run a flask app under apache

In an effort to switch my php based web sites to python, here are the steps required to make a python based web app available under an apache server, using wsgi.

under /var/www/hello:

hello <-- folder with flask app hello/venv <-- virtualenv with all dependencies installed hello.wsgi <-- file with following contents:

#!/usr/bin/python
activate_this = '/var/www/hello/hello/venv/bin/activate_this.py'
execfile(activate_this, dict(__file__=activate_this))
import sys
import logging
logging.basicConfig(stream=sys.stderr)
sys.path.insert(0,"/var/www/hello/")

from hello import app as application
application.secret_key = 'GENERATED_SECRET_CHANGE_AND_DO_NOT_SHOW_TO_ANYONE'

Howto generate a secret (from flask documentation):

python -c 'import os; print(os.urandom(16))'

And then in the apache site configuration the following will make the app active:

WSGIDaemonProcess flaskapp user=www-data group=www-data threads=5 home=/var/www/hello/hello
WSGIScriptAlias /hello /var/www/hello/hello.wsgi


WSGIProcessGroup flaskapp
WSGIApplicationGroup %{GLOBAL}
WSGIScriptReloading On
Order deny,allow
Allow from all

Alias /hello/static /var/www/hello/hello/static

Order allow,deny
Allow from all

And that should make the site available under the path /hello

Modern Software Development or Slow as Molasses

I’ve been looking at that issue for quite a while, and always tried to play nice and be quiet about this, but quite recently I’ve experienced the discrepancies that I am going to describe quite intimately, so I feel I can no longer hold back.

But lets start with a little introduction and motivation for the topic at hand. I am going to be talking about Software-Developers mostly, but some of the general ideas are probably relevant to all kinds of crafts and handiwork.

The tools we use are shaping the way we work. They also shape the results of our work, the shape how we divide our time between different tasks, they shape how we estimate the effort needed to finish a project. And they shape what kind of projects we approach, and what the size of the projects we approach is.

They shape how we think about our work, and about the world.

So I’ve been pondering the idea of getting into Android App Development for a while, and this week I put my plans into action and attended an Android Developer Meet, and got started with the first basic Android tutorials. I tried to approach this whole endeavor with an open mind, fully expecting that the first few steps might be a bit rocky, and that it can be frustrating when you are on unfamiliar ground as an experienced developer.

Never the less, with the helpful support from someone at the Meet, I managed to stumble my first few steps into the foreign fields of Android development.

Now as a bit of a back story, to say the least, I’ve been developing Software for quite a while, especially on the frontend and graphical user interface side. I started with Delphi and Pascal, moved on to C++ and I’ve used many of the different user interface libraries that are available for C++, like wxWidgets and Qt. Over the years though, I started to prefer a rather obscure and not so well known toolkit for my personal projects. It is called FLTK, or Fast and Light Tool-Kit.

Moving more into professional Development in the recent years though, I am currently working more often with the Qt toolkit.

But never the less, the next day after this Android Development Meet, I decided to give the good old FLTK another spin, just to see how it compares to what I learned about Android the other day.

I had to tinker a bit with the environment on my laptop to get started with the FLTK library again, but I managed to get it all going.

I typed up a little “Hello World” style basic program, compiled it, started it, fired up the included FLTK Form Designer “fluid” and added a few buttons and controls to my program, when I suddenly came to realize the horrors that I experienced the other day.

Compiling and starting a basic program based on FLTK on my laptop happens in an instant, compiling the project happens under 1 second, it is barely noticeable. Starting the program on my laptop, the window opens almost as soon as I press the enter key after I entered the name of the binary in the console.

The FLTK Designer is fast, it starts in an instant, you create a form, add elements, etc. at no point at all is there any waiting involved.

And slowly it dawned me, I tried to fend the thought off, but I could not help myself. I tried so hard to stay open minded about android, to not be the grumpy old man that says “In the olden days everything was better”.

I tried to come up with several excuses and defences, of course Android has way more capabilities, it has to support different devices, resolutions, layouts, it has a more complex rendering pipeline, using accelerated graphics for its display, and supporting transitions and animations, etc.

But how could I kid myself, watching the IDE spinning its wheels over some gradle script, looking at the massive boilerplate that was generated for even the most simple project, waiting for the designer to switch between the text- and the graphical view taking more than a few seconds. Waiting what felt like ages for the emulator to start and show me the results of my feeble efforts. And even if I did not need to restart the emulator for changes to become apparent, just having the updated app restarted took way longer than what I looked at in the case of my simple FLTK project.

There is just one dominant feeling inside of me, and that is, how can anyone accept these kind of tools, why is there no outrage about this massive timesink, how can there be such a large number of Android developers, and nobody dares to speak up for some sanity in the development tools.

And then I start to really think, maybe that is why so many Android Apps are the way they are, because the developers are stuck in molasses. There is no room in Android development to quickly whip up a crappy little experiment, and bring it live, there is not much room, for radical and quick experimentation, everything needs to be well thought out, planned, and then implemented.

It is a set of tools, that more or less forces the developer to adhere to a corporate style slow moving waterfall model of development, because quite simply, no other style of development is possible.

Even for my little Hello World style Android app, I started to fear the moment of having to switch to the designer view in Android Studio, which would take long enough to put me out of my flow, and anger my patience.

That is probably why paper sketching is so popular in App development, and why there is a proliferation of “Mockup” Tools, and Designer Tools, specialised towards App development, because apparently, it is not possible to “think” visually and sketch in the Android Studio Designer. It is only possible to realize a design that is already thought through.

Funny enough, I sometimes use an old and discontinued UI Designer called wxDesigner, to sketch and plan my user interfaces, before I implement them in the framework required for the job.

But it goes further than this, the tools we use change the way we think, and I think being confined to limited tools like the Android tools confine the way we think about ourselves as Programmers. And now I am no longer talking solely about the slowness, but also about the complexity of the environment, that is the number of concepts that need to be understood to implement even the most basic application.

One such source of complexity is for example the changes between the various platform versions of the android system, and the way that the platform implementers choose to expose the developers to those changes. To say the least, references to changes between android versions are all over the place in the documentation and everywhere. In my opinion this is unnecessary noise, and noise takes attention and attention is limited.

In fact I think this leads to a point where it is more or less necessary to be a full time Android developer to write Apps. It is not likely or easily possible, to be, lets say a scientist for example, and to develop a little Android App on the side to control some lab equipment, or to support a little experiment.

And I think that is bad, it is a choice that the developers of the platform are making. It is a choice that takes power away from developers, because it binds attention that could be used elsewhere. Of course you could argue that it gives developers job security, because making the system too complex to understand for outsiders, makes them hard to replace, but well, software should be used to make the world more interesting, and not necessarily more boring.

I feel that these kinds of tools give the developer the feeling of being a cog in the machine, you are suddenly “just” an implementer, implementing other peoples ideas, realizing designs that other people thought out, you can no longer think about problems to solve, but rather all your creative energy is bound in the problem of handling the platform. It becomes a purpose of its own.

And it goes the other way around too, suddenly if you have an idea or problem, you can no longer solve it by implementing an app yourself, when you are a “non” programmer. You need a programmer, because it is not possible to write a simple app yourself, while still keeping focused on your actual field of expertise.

Anyways to wrap up my little rant, I think doing simple things should be easy, and writing a simple app should be simple. And shortcomings should be complained about and should be fixed. Can’t possible be an acceptable situation that one of the most popular platforms in the world is a pain in the butt to develop for.

C++ Challenge: SimpleServer API

This week I’ve prepared a little challenge in C++ programming. The example is not extrodinarily complex, but not completely simple either. The purpose of this example is, to challenge myself a little to get to know boost::asio networking, and to contemplate about how simple APIs for prototyping could look.

So the challenge is to create a class, that allows prototyping simple network servers, by implementing a convenient base class. The interfaces and base classes are already layed out, including an example that send the reply “Hello” for any incoming connection.

The specification is a bit open, and is not so much concerned with corner cases. So using the simplest solution possible is probably the right thing to do.

Ok, here we go for the boilerplate: read on, I will add a few explanations below.

#include <string>
#include <functional>
#include <iostream>

class IConnection
{
public:
    typedef std::function<void(const std::string& str)> send_function;
    virtual void receive(const std::string& str) = 0;
    virtual ~IConnection() {}
    IConnection(send_function send_) :
        send(send_) {}
protected:
    send_function send;
};

class IConnectionFactory
{
public:
    virtual IConnection* create(IConnection::send_function send_) = 0;
    virtual ~IConnectionFactory() {}
};

class HelloConnection : public IConnection
{
    public:
        HelloConnection(IConnection::send_function send_) :
            IConnection(send_) {}
        void receive(const std::string &str) {
            std::cout << "Received: " << str << std::endl;
            std::cout << "Sending Reply: \"Hello\"" << std::endl;
            send("Hello");
        }
};

class HelloConnectionFactory : public IConnectionFactory
{
    public:
        IConnection* create(IConnection::send_function send_) {
            return new HelloConnection(send_);
        }
};

class SimpleServer // <-- IMPLEMENT THIS CLASS!
{
    public:
        SimpleServer(int portno, IConnectionFactory *connection_factory) {}
        void run() {}
};

int main(int argc, const char *argv[])
{
    SimpleServer server(1234, new HelloConnectionFactory);
    server.run();
    return 0;
}

So, it goes like this: IConnection is the virtual interface for implementing a connection. That is, for every new connection, a new instance of an IConnection implementation is spawned, that is bound to that connection. When the connection is closed, the instance is deleted.

The IConnection receives a function pointer as argument, so that it can send replies. You can see how this is supposed to work in the example: “HelloConnection”. That example simple prints the received string on stdout, and sends “Hello” back.

SimpleServer is the class that you need to implement, here you can have all the bookkeeping, and you are probably going to need some internal connection class, that handles  each socket created, etc.

Anyways, I will probably be implementing the SimpleServer myself this week, so I might be able to post a follow up with a solution.

But anyways, this task is simple enough, that a veteran C++ programmer should be able to do it. And it is definitely intended as a practice to work one ones programming skill, so go ahead and try it.

Post your solution in the comments, or send them via email: richard.spindler@gmail.com

If you send via mail, I will add your solution to a follow-up post. 🙂

Have fun,
Cheers
-Richard

Managing C++ libs with CMake ExternalProject and Git

Writing modular software, you might sooner or later come into the situation, that you have some functionality, that you want to share between different projects. Let’s say, to have built a couple of convenience classes and function that you want to reuse.

There are different ways to skin the cat, one of them might be using a dedicated C++ dependency manager like Biicode. Or a general package manager for your platform of choice, like apt-get on Debian and Ubuntu, or Homebrew on OSX.

Usually you will start with putting your module or library into a git repositry, if you haven’t done that already. For Code that I want publish publicly, I usually choose my github account.

Now for creating a homebrew package, or a debian package, you either need to create some project description, a bit of boilerplate, and need some platform like launchpad to publish packages. Or in the case of biicode, you need an additional account at another platform, and you have to install another tool.

However, there is another approach, that uses software that you probably already have, and that is CMake and Git.

CMake has a functionality called ExternalProject_add, which can use, to automatically check out a git repository, and build that as part of the normal build process.

Of course, the same functionality would be possible with git submodules, but honestly, I always found this part of git rather cumbersome, and unnecessarily complex, for what I want to do.

So, I’ve created two small examples, that show how to create a small library, and link to it through CMake ExternalProject_add:

The first one is the library: cmake_simple_lib

And the second one is the project that uses the library: cmake_simple_demo

I hope you find that useful.

Cheers
-Richard