kranzky

A good problem for tech to solve is this: How do you turn a bunch of random strangers into a community?

You know you're in a community when people help each other move house, for example.

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.

I know it's bleak, but the API now includes build server style badges, like this: https://corona.kranzky.com/badge.svg

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

Source code of the prototype is here: https://github.com/kranzky/d_board

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.

You, my friend, need to start your own company.

Oh. Well, damn. I guess Steve Yegge was right. Anyway, wouldn't it be great if Google launched a kick-ass text editor?

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.

A semi-serious brain dump after working with GitHub's new features for a day.

Thinking about Chomsky and Hong Kong lead to writing this brain-dump.

This is obviously, I hope, all just a bit of fun.

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.

Here's a guy who was trying to do some of this: https://github.com/Genki-S/ttnt

Things I would 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.

Good luck with it!

OK, fixed the autoscroll I think. Let me know if it does / doesn't work for you.

Thanks for the feedback; I did try to do the autoscroll, so sorry it's not working. Will attempt a fix soon...

I spent the last couple of weeks rewriting MegaHAL, and it's finally online again after a brief absence.

You can talk with MegaHAL here: http://megahal.kranzky.com/

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.

Share and Enjoy!

I have spent the past few weeks rewriting MegaHAL in Ruby and getting it back online, after a brief absence.

You can chat with MegaHAL here: http://megahal.kranzky.com/

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/

Enjoy!

Yes, the TDD debate really got me thinking about why I write tests. It used to be about saving me time. Now it seems to be about satisfying other people that I know what I'm doing.

But I am a fan of code-as-documentation, blindingly obvious business logic and data validations at the interface, and I was struck by how Uncle Bob's TDD example just disregards all of that. Hence the QDD piece (which is half serious, half joking; I've left it a puzzle for the reader to figure out which half is which).

Written for the recent GovHack down here. Integrates spatial data from many disparate gub'mnt departments, and displays as a Tweetable heatmap.

I find these ones rather interesting, but you can make your own too:

Average Taxable Income vs. Average Donations to Charity (http://australian.govdata.exposed?q=-33.86726011483213+151.2...)

Adults who are Divorced vs. Homes with Six Children or More (http://australian.govdata.exposed?q=-33.865977283552276+151....)

Public Toilets with Baby Change vs. People Aged 0 - 4 (http://australian.govdata.exposed?q=-37.79925451435619+144.9...)

I also JSON-ified all the data I processed and threw it up as a static API at the following URL:

http://api.govdata.exposed/

Comments most welcome!

I wrote this after the "Is TDD Dead?" debate of a few months ago, and I think it's high time I published and shared. Comments most welcome!

I wrote this relatively quickly tonight; just trying to sketch out some idle thoughts on what the future may bring. I think we should all be trying to look beyond the next one hundred years, but it is hard to do that constructively.

Would be interested to hear what people think; what is the current attitude with regards to chatterbots, speech-recognition, Siri and Kurzweil's singularity? Are we jaded, or is it the beginning of a new era in AI?

We're at a Startup Weekend, and are building an alarm clock for phones that shows an ad for a local indie coffee shop when you wake up each morning, giving you a chance of winning a free coffee there that you must claim on the day you win it.

If you run an indie coffee shop, we'd love to know whether you'd be interested in hyper-local advertising that will target people who may not know about you, and travellers who are looking for great coffee off the beaten track. Please consider taking our very short survey: http://www.surveymonkey.com/s/W87HM8M

Thankee!

That's true, with the exception that learning how to write a program is also a lesson in how to think logically. Rather than teaching everyone to be programmers, the goal could be to use programming as a tool to teach everyone how to think.

I understand your point, but I think it comes down to self-discovery. Using the C=64 (and other home computers of the era) enabled you to discover that programming existed as a thing, and then to learn more by digging deeper. Modern computers are much, much better at the digging deeper side of the equation, but completely fail on creating the initial spark of interest.

In my experience, if you can create that initial spark with your kids (as I did with my daughter, just by showing her the C=64 programming book I had as a kid), then they _will_ want to know more.

Wow, thanks for all the feedback; lots for me to discover and digest :)

But isn't maths boring at school because we're teaching it wrong? See Conrad Wolfram's TED Talk: http://www.youtube.com/watch?v=60OVlfAUPJg