Migrating to Bitbucket and turning my markdown frown upside down with Dillinger WYSIWYG and Cloudup image drop spot.

Check out my fancy markdown https://bitbucket.org/ifknot/liblog

Why move from GitHub to Bitbucket?

Bitbucket, similar to GitHub, is a web based GIT hosting service for your projects. It offers free private repositories with free private wikis on accounts of up to 5 users(!) and you can switch any repo public and back again anytime. So develop in private and publicise when you're ready. 

GitHub’s  free account doesn’t allow for private repos and their lowest paid option (for organizations) only allows up to 10 private repos. Bitbucket, on the other hand, offers unlimited private repos. 

It's easy to import directly from GitHub with the click of a button - well done Bitbucket.

What to move first?

I moved over liblog the logging software that I first blogged about way back in Jan 2014 but wanted to have a nice front piece for when I chose to make it public. This can be easily achieved using markdown in a README.md file pushed to the repo. 

Markdown frown. 

dillinger.io
Markdown is (quite) easy but slow to hand roll but with the excellent online WYSIWYG markdown editor Dillinger "Type some Markdown on the left... see HTML in the right" I found it pleasurable to work with and get some decent looking results.

Gratis image drop.

A free account on Cloudup gives you space to drop pics/vids/music/docs and have nifty short URLS to them for your markdown/blog/web

Part (2/2): Active Objects for Asynchronous Logging.

Contra-auguste Active Object

TL;DR It's just an slightly better (imho) implementation of Sutter's Dr. Dobbs 2010 articles [1][2]

As per Lavender & Schmidt's article[3] Sutter's implementation is a further refinement of the integrated scheduler variant of their original pattern removing, as it does, altogether the proxy and scheduler relying on direct message passing between client and scheduler. 

Indeed Sutter's scheduler (his Active class) contains the message queue as a private composition -which is too much integration. Too much because it forces the client to be aware of the scheduler which as an unnecessary, and avoidable, level of dependancy that binds the scheduler to the client.

The client need only be aware of the tail of the activation queue and, hence, the has-a-relationship with the message queue can be broken out of the scheduler for a more naturally component orientated approach that facilitates scheduler fungibility. Further, the scheduler need only be aware of the head of the activation queue.

Simplification of logging services.

As Thoreau said: "Simplify, simplify, simplify..."

The trouble with writing something in an hour or two that works is that you then have find your subconscious mind is chewing it over all the time that you're working on something else.

So it is whilst working on message_queue I couldn't resist fiddling with the logging services:

• the io namespace is gone
• serializor_policy is gone
• only the null_serializor remains renamed null_log
• ready for asycn_log
• logger now takes an output stream policy and is, consequently, more flexible
• works directly with any ostream decendent
• logger template overloads operator() 
• logger doesn't need a stringstream any longer 
• I've left the stamps alone, for now... 

TL;DR github.com/ifknot/libfbp

Part (3/3): I'm a Lumberjack and I'm ok.

The Lumber has arrived!

Freshly hewn but unfinished pile of Code Lumber is below, ideal for building your debuggin' & audtin' & tree-house solutions.

The latest versions of the code and doxygen docs are all over at the libfbp git repository github.com/ifknot/libfbp

Part (2/3): I'm a Lumberjack and I'm okay.

With the software design description (SDD) contexts in hand from the previous post here and using a deconstruction of the excellent Dr. Dobbs article "A Lightweight Logger for C++" by Janiszewski (January 31, 2013)[1] as a basis for implementation then given the following observations about that article:

Part (1/3): I'm a Lumberjack and I'm okay.

"Logging is a critical technique for troubleshooting and maintaining software systems."[1]

I would also add that logging is a critical technique for recording a variety of metrics when conducting software analysis and experimentation.

Therefore, I need a thread-safe, asynchronous and fast data serializing framework-not only in order to develop libfbp but also to experiment with it.

There are some great libraries out there already[2] but where's the fun and learning in that?