Tech heads are re-discovering what "community" actually means, after overusing and abusing the term for the last two decades when they actually meant to say "audience" or "network".
Just read an article about employers increasingly monitoring their WFH employees with software installed on their computers. This is the "sitting at a desk and typing" measure of productivity. How do they propose monitoring the "solving problems by thinking hard" measure of productivity?
For sure, we need to collectively recognise how much real work takes place in this mode.
I once collaborated with a colleague to design and implement a data sync framework. For six weeks we chatted about it during our lunch break, while walking from the office to a Japanese takeaway and back again. We'd propose ideas and find weaknesses and flaws in them, and would spend our evenings thinking hard to come up with solutions to get around these issues.
Our boss saw none of this, but it easily consumed about three weeks of person-hours (i.e. around 120 hours).
One day, walking back from lunch, neither of us could find any problems with our proposed solution. We walked into the office straight into a meeting room, spend 30 minutes drawing diagrams on a whiteboard, then returned to our desks and coded up a working proof-of-concept in a couple of hours.
From our boss's perspective, we had implemented a new technology in an afternoon. He's the kind of non-technical person who equates productivity with typing code into a computer. But I think more places need to equate productivity with sitting on a sofa staring into space, or going for long walks, or whatever it happens to be that works for the developer in question.
Nice, I remember playing with Dasher many moons ago; visited David MacKay (RIP) back in 1996. In 2009 I developed my own text input system called D-Board. There's a brief video of a prototype here: https://www.youtube.com/watch?v=Do0fUWME0Mw
In fact, with the help of Paul Geerts, I submitted an earlier version of d-Board to SONY in 2006 or thereabouts while working in game development. It ran on the PS3 and used a similar interface to that shown in the video. The search menu in the PlayStation Store on PS4 later adopted this interface (although it's been replaced by an OSK these days), perhaps because somebody saw the prototype and decided they'd use it there.
I suggest you read "Bullshit Jobs: A Theory", by David Graeber.
He explains that apprentice -> journeyman -> master no longer holds; we all get stuck at journeyman, working in the service of others for our entire career.
Great stuff, and awesome to see this coming from Google (and in Rust instead of Go). Interesting historical note: The author of Sublime Text left Google to work on it by himself when he couldn't get it approved as a 20% project.
Well, it is kind-of possible for Ruby/Rails. I half-built such a system once. Here's what you do:
* Gather coverage information when running tests or compiling assets.
* Use that to generate Rakefiles for running tests / compiling assets that have dependencies on the source files they would touch.
* Run the tests once, recording information about the git status of each dependency.
* When the git status of a file changes (i.e. you've just fetched some changes), mark the dependency as dirty
Even better, it you're gathering coverage data and know the test status for each commit, then not only can you show the commit that broke the build, you can show the particular part of the diff that broke the build.
* Push conflicted branches so developers in a distributed team can work together to resolve conflicts.
* A git-powered version of Rake, which runs only those tests that need to be run based on the git history since the last run.
* A tool to identify what code changes caused a particular test to fail, based on the above.
* Language syntax detection for smarter diffs, improving the display when blocks of code are moved around or indented/outdented.
* Language linters built in, to detect when a change is introducing a syntax error. Same for coding style.
I'd also move the "Close Pull Request" button a little farther away from the "Comment" button, and make it possible to add comments to a diff when you've hidden whitespace differences (with `&w=1`... I'd also make it a bit more obvious that you could do that).
Nice work! I built something similar that keeps everything in Ruby. It was made to allow models built in Excel by a non-programmer to be executed on the back-end of a Rails app, but it's pretty generic: https://github.com/agworld/soroban
I had big plans for the project; the next step was to convert the models to JavsScript so they could be executed directly on the client. But, like most of my pet projects, this has remained a pipe dream.
All source is freely available on GitHub, unencumbered by a license.
The main MegaHAL repository is https://github.com/jasonhutchens/megahal/ It includes a console application and eight built-in personalities, including Sherlock Holmes. And it's easy to hook into its API if you want to build something else with it.
MegaHAL uses Sooth, which is a simple stochastic predictor, written in C but wrapped in a Ruby gem. It's available at https://github.com/jasonhutchens/sooth/ MegaHAL uses five separate Sooth predictors to do its thing. You could build other things with it.
Finally, the code for the server itself is available at https://github.com/jasonhutchens/megahal-server/ It's a Rails 4.2 app with a crappy Bootstrap theme. A basic REST api hooks things up, and a daemonized version of MegaHAL processes the queue of jobs coming in from the world.
Have fun, I'm looking forward to seeing how warped the online personality becomes, and how big the brain file grows.
MegaHAL is also available as a Ruby gem, which includes a console mode, all open source and unencumbered by a license. See the GitHub page for more: https://github.com/jasonhutchens/megahal/
