No I’ve never been that great at getting along with other (coders). Much faster to just go where I need to go on my own. Fail. Time to stop being an island, there are far too many compelling shoulders to stand on these days. Strategy shift:

  • my Reusable repo will be for helpers and glue, not for major functionality that can be better found (and maintained!) by others
  • Pick and CONFORM to good libraries. Better to mildly fork them than try to maintain everything myself.

Seems pretty obvious in hindsight. Working with the Causam team, and collaborating on Simple-Web-Server, were the catalysts, thanks guys.

Update: add these awesome ones!

https://pocoproject.org/
https://macchina.io/docs/
http://vinniefalco.github.io/beast/beast/intro/example.html

Goal: find the fastest possible C++ https library that can score an A on the SSLLabs test. Ties broken by ease of use, then by support for websockets.

Initial results (see wiki for latest…):

LIBRARY ab

MB/sec

ab

pages/sec

SSL LABS
SCORE
EASE WS? COMMENTS
apache A 3 N need to write a module, apache remains in charge of message loop (unacceptable)
libwebsockets 7 Y
proxygen 7 only easy to build on ubuntu so hasn’t been stood up on my gentoo server yet; huge kitchen sink of helpers
Simple-Web-Server  B 10 Y websockets in a seperate compatible project; may be able to leverage asio to improve score (capped by RC4); no forward secrecy
websocketpp  uses asio, specifies a “modern” mode that only allows TSL1.2
mongoose 3 messy ton of hand-crafted portability C code scared me off
onion looks like a strong C lib
libmicrohttpd GNU c lib, not sure it supports modern algos, check score…

I use my rad-scripts node module to quickly set up management and automation of my active projects.  I now have a couple private node modules:

  • mah-haus is my node module that mass-manages all my repos – it’s great; with one command I can completely sync my entire dev station when I start/finish a session
  • atci is for my AbetterTrader project and gives me all the dev tools I need to build, publish, and run continuous integration

Thanks node.js, I love my new automated life.  Should I publish these modules even though they have no real public use?  Nah, why pollute the npm-isphere?  But I will put this post here so I can use it for the module home pages.  😉  Carry on!

I’m experimenting with Sprintless Agile as a methodology for my personal projects.  It’s agile without managers and deadlines.  It removes the artificial constraints of arbitrary deadlines from software projects.  Because I just spend the free time I have on my projects, there is no need for deadline tracking.  The need for task estimation is therefore eliminated, leaving priority as the only criterion to be freely applied to all tasks equally.  Without the “get it out the door” pressure, crunch time is lost, but releases are more continuous than planned, and life runs more smoothly.  The hope is that projects will be able to focus on the important goals instead of throwaway demo work.  The fear is that too much time will be spent obsessing over unimportant tasks.  Therefore, the top priority becomes to continuously prioritize.

Why would [git push] fail to push annotated tags as well?  That just results in another disruptive layer of potential synchronization issues.  They finally added sane behavior, but you have to turn it on with:

git config --global push.followTags true

Or, use rad-scripts!  Which has [git-sync], and, as of today, always uses –follow-tags.  I’m loving my Node.js lifestyle.  😛