about robots taking people's jobs

I'm not opposed to the idea of robots taking over dangerous manual jobs. I'm not even opposed to the idea of robots taking over creative or technical jobs. I'm just opposed to people blindly trying to make that happen as soon as possible, before any societal provisions are put in place for the people whose jobs will be taken.

I don't believe in meritocracy. I'm not in favor of economic or intellectual Darwinism. It assumes that only the smartest or most resourceful should survive, and it also assumes an even playing field for all involved. "If someone's manufacturing job will be taken by a robot, they should just learn the skills needed to get a better one," say people from well-off families who have never tried to master a skill while hungry, or while working a low-wage job 16 hours a day.

I'm all for robots taking our jobs, but before that, we need our society to function without jobs at all. We need to set it up so that no one needs to spend their entire life working at a place they don't really care about just to feed themselves and their families.

We need get our world to a place where no one has to work to stay alive. Once that happens, bring on the robots.

not a technocracy

Last weekend, while camping on an island full of ponies, I had a long conversation with a newfound friend who works in Washington D.C. as a lawyer and political fixer, and Joel, who's studying computer security but did his undergrad in economics and political science.

The new friend implored Joel and me to venture into roles outside of tech, not a hard sell since we're both from non-tech backgrounds. But she emphasized the fact that non-techies have no idea what's going on with technology, and that's a huge issue, especially in law and the government.

We already sort of knew this, but the bleakness with which she presented us with this information was startling. Joel and I are years away from being computer experts, but she said that decades of experience aren't a prerequisite to be a consult for some of the concepts that lawyers and lawmakers need help grasping. It just takes a few connections with the right people-- and a knack for translating technology into language that actual human beings understand.

As someone who went into tech partly to make it more accessible, it's encouraging to see that I really am filling a pressing need-- the need for techies to have actual human skills. However, it's also disconcerting to hear that our government is still largely tech-illiterate when technology now permeates everything. Entrenched systems have a lot of catching up to do.

rabbit holes

I spent several hours today working on an increasingly frustrating string of technical problems I should not have even been working on.

It all started with me trying to get a working version of my rudimentary NYPD stop and frisk data grapher online for public commentary (and hopefully statistics help-- I slept through my 8am stats class in college, so I never really learned how to normalize data).

While investigating, I fell down the following rabbit holes, which were all only moderately related to the problem at hand:

  • Amazon Web Services: I first considered putting the app on an Amazon EC2 instance, so I looked at my list of instances and found out that the one hosting this blog was about to be retired. I tried to stop it and migrate my blog to another instance, but it hung on the stopping part, so I had to file a support ticket and they presumably stopped it for me.
  • HTTPS: When I finally managed to migrate my blog over, I remembered that argh.gr doesn't have HTTPS, so I looked into what it would take to get an SSL certificate. I visited LetsEncrypt and learned that they only really work when you have shell access, so I looked through my old notes and realized I had SSH access to the argh.gr server. (This blog's server is completely different, and I redirect with an .htaccess file.)
  • Plesk: My web host uses Plesk to help me manage permissions and stuff for the site. I found an SSH terminal feature built directly into it. I tried using it and was told to download Java. I downloaded Java and was told to download another package. I downloaded that and the terminal application opened, then crashed, citing a faulty security certificate.
  • SSH: So I tried SSHing into argh.gr with my FTP credentials like I was once able to. That didn't work, but I managed to do several other things with my FTP credentials, like telnet and log in with ProFTPD commands, neither of which I'd ever used before (except for watching ASCII Star Wars). I finally filed another support ticket and was told that SSH access is now restricted to a specific port, and that I can't just use my FTP password to authenticate anymore. Luckily they were able to put some new keys into the server so I could log in (and promptly change them, because they sent me the private key via email). I logged in, remembered that the server uses nothing but vi, and promptly logged out.
  • Bitnami: After migrating my blog, I tried to update a CSS file on my instance of Ghost, whose Amazon EC2 image was provided by Bitnami. After changing the file and pulling it into the server, I found that the CSS file name was garbled in the browser. I discovered that Bitnami uses Pagespeed, hence the garbled file names, and set about turning that off in their Apache configuration. Then I realized I had to restart the whole Bitnami setup to get Apache to reload and to recompile the one CSS file I had changed.

While I was waiting for the support people to grant me SSH access to my site, I discovered that Heroku now has a MySQL add-on with a free tier, so I actually got the data graphing app built and on Heroku from my Github repo in about thirty seconds. I still have to configure the database and add the datasets to it, but that'll take me less time tomorrow than all of these other shenanigans put together.

All things considered, the five seven hours I spent on this was only maybe a fifth as frustrating as listening to yesterday's US presidential debate for five minutes. I might have even learned something new.

bunny running away suddenly

rules to live by

I'm writing this in the wake of the Pulse club shootings in Orlando.

If you're reading this, I'm aware that you probably know or like me (because who else would care about my blog?). I realized that I know and love a lot of people who regularly attend religious services. And in the coming weeks, the sermons in their services are going to address this shooting.

Some sermons will approach the topic with love and compassion and say that no one should commit such an evil act. However, some will say that it was God's will, or that being gay is evil, or gays deserve to die. I'm mostly writing this to explain why I disagree with the latter. Within this explanation is my basic stance on life.

I try to do less harm than good. To remember to do that, I've created a few rules for myself, and I try to adhere to them while going about my life. Some of these rules are straightforward and practical, like "Don't wear high heels while drunk". But the majority of these rules all center around one main one.

The main rule is to not be terrible.

Over the years, I've had to define what "terrible" means. My definition of terrible involves impinging on living beings' happiness without their consent. There are different degrees of terrible acts, depending on:

  • How many living beings are affected
  • How long they have been/will be affected (a proxy for how deeply they've been hurt)
  • How much they can experience being affected
  • How terrible the affected beings are themselves
  • Whether the act is deliberate or consequential

Some of the factors that determine how terrible a person is include:

  • How aware they are of doing the terrible thing
  • How long they have been doing the terrible thing
  • What forces compel them to do the terrible thing
  • What forces prevent them from stopping doing the terrible thing
  • Whether that terrible thing is isolated/stoppable or systemic/hard to stop
  • Whether that terrible thing is to prevent something worse, or is in the service of something good

Thinking about this rule has made it easy to prioritize what to care about, because the things that matter most are the ones that actively prevent terrible things.

Helping people when they need it? Ok.
Keeping house? Nope.
Money? I guess having it can help someone.
Praying? Not really.
Writing a local representative? Maybe. Do they even read those?
Stopping an active shooter? Probably worth it if I don't get killed immediately.
Meeting deadlines? Is someone literally gonna be dead because I don't make a deadline? If not, then no.

Sometimes I care about some of this other stuff because other people care or are affected by it. But when all I really want to do is prevent the most terrible things-- suffering and death-- from happening in the known universe, the other stuff is small beans.

This rule has had some remarkable repercussions. I was raised Catholic and fairly conservatively. Because I care about life, I agree with the church's harsh stance on issues like guns and the death penalty, and I recognize that they're the largest non-governmental provider of health services in the world.

And because I care about life, I disagree with their stance on issues like abortion. I do agree that life begins at conception. But as someone who studied biology, I know that a clump of cells has less life in it than a mosquito, which is much less life than a full-grown woman whose life potential would be unduly taken away from her if she were forced to carry a child to term. In this case, I would rather be terrible to the clump of cells-- it doesn't have a fully developed nervous system, so it can't feel or remember pain and suffering to the extent that a woman can.

As someone who studied biology, I also take issue with the church's stance on sexuality, gender, and gender roles. Homosexuality does occur in nature. It may be unusual in mammals, but it's natural. (Flowers get really freaky with each other. And themselves.)

As someone whose own marriage would have been illegal less than a century ago, I'd like to point out that the things people claim are unnatural and that God finds disgusting have changed and will continue to do so. So if people want to do something to increase their happiness or ease their suffering and it won't harm anyone else, no matter how weird it might be to me, it's not my place to voice an opinion about it.

I generally disagree with having social norms, such as some forms of organized religion, normative whiteness, and heteronormativity, because they create a culture that not everyone fits into. That leads to the rejection of whatever and whoever doesn't fit those norms, which leads to the existence of outsiders to that culture. Being an outsider can result in discrimination-- in some cases, even death.

I still try not to be a terrible Catholic. But more importantly, I'm trying not to be a terrible person. I don't condone being terrible to someone because they don't fit in, or because they don't follow arbitrary rules about how to look or act. They must have participated in harming another living being for me to even consider being terrible to them.

Anyway, if you're trying not to be terrible, and are maybe even trying to help others, I personally believe that God is pretty accepting and doesn't have strong opinions on what you do otherwise. I just wish more humans could be like that. And, if nothing else, I wish we could agree on what being terrible means.

seeing the future

I moonlight as a fiction writer. I've been writing stories since kindergarten. As a middle schooler, I wrote a lot of science fiction. That whole imaginary worlds thing tapered off as I grew up and figured out how to deal with other people by writing about theoretical human drama. I'm glad I finally got back into science fiction; it's a lot more fun to imagine new concepts than it is to plot out the interactions between angsty teenagers.

Over the past several months, I've been working on a novel set almost a century into the future (at the very least). I call it my keitai novel because I've been writing it mostly on my phone during subway rides to and from the office. It's a little tricky to extrapolate current trends and research into what will actually happen a hundred years from now. But I remind myself that even Jules Verne and Gene Roddenberry didn't get everything right about the future, and they made up for it by illustrating the possibilities so enticingly that people decades and centuries later have taken it upon themselves to work toward substantiating the futures they described.

Some of the ideas I'm incorporating are a little more straightforward and technical, like bioencryption and the laws governing autonomous artificial intelligence. (Of course, the AIs don't call themselves that because they don't consider themselves "artificial".) But I've added other details that were extrapolated and analogized from current events, such as China descending into civil war, which means huge numbers of refugees with manufacturing and engineering expertise are fleeing China and turning stateless-- communities ripe for an alliance with rebel AIs that need people to repair them, and to help them enter the international political scene with some clout. Other details are largely visual and philosophical: this is a world where virtual/augmented reality glasses (VARGs) are widespread, and young people wear them all the time, adding a layer of psychedelic gamified nonsense on top of everything they experience.

It's fun thinking up what might be in store for humankind, but that's not really what this novel is about. To be an effective writer, I have to drop all of this history during the course of the story and not let it get in the way of the plot; I can't explain everything outright like I did above, because that would interrupt the novel's flow and believability. I think the best science fiction writers manage to convey a completely different world mostly in passing-- for example, William Gibson might drop a stray detail during a conversation that implies an entire war happened decades before the characters met. I want to create a future that can draw readers all the way in like that, but also compel them to dream about what's possible in the world we actually live in, and how to get from point A to point B.


For the past month, I've been working on getting the latest version of my company's flagship website up and running. The part that personally caused me the most grief was the commerce-related scripts. I spent an entire weekend stumbling through them before it became clear that even though I'd worked with asynchronous functions in JavaScript before, I had no idea what I was doing.

Golden retriever wearing a necktie sitting at a computer: "I have no idea what I'm doing"

My boss realized what the trouble was, and the following Monday, she sat me down and gave me a twenty-minute rundown of SQL transactions, JavaScript promises and how they're related to ES7's new async/await function, and how to properly handle async errors using the try/catch/finally pattern. While she was at it, she showed me how the famed Express router's error handling works, and all the gotchas that come with it. I'm pretty sure she saved me months of my future life trying to figure this stuff out.

My main takeaways were (in ascending order of confusion):

  • Error handling
    • I seriously did not know how to throw an error within a try/catch. It's literally throw 'Error message'.
    • If you're going to pass any variables besides an error into a catch, declare it outside of the try/catch and then set it within the try. Otherwise catch doesn't know about anything that happens within try.
  • Promises
    • The function you're waiting for should have a try/catch in which you invoke resolve() upon a success and reject() upon catching an error. (Don't forget to pass those functions in from the Promise invocation.)
    • You can avoid true callback hell by using then/catches (like this one: promiseFunction().then().catch((error)=>{})) infinite times in what's called a "promise chain".
    • Promise chains are easier to work with than callback hell, but they're still only one step removed from callback hell.
  • Async/Await
    • async is basically a promise wrapper that prevents you from having to deal with all the .then().catch().then() of promise chain error handling, further shielding you from the horrors of callback hell.
    • Instead, you keep functions to await in a try/catch, and they are run chronologically, like normal functions.
    • You can technically await straight promises, but you shouldn't need to...
    • ...unless you're awaiting the end of a string of promises that are called asynchronously, in which case you should put them in an array in await Promise.all();, because the corresponding await* function didn't make it into the ES7 release.
  • Express.js with Async/Await + Promises
    • For every CRUD operation, you should only have one async function that returns a promise, and that's for the request that hits the server endpoint.
    • Every other client-side async function only awaits these request functions. There should be no other promises in your data-related code, with the exception of Promise.all() for the reason mentioned earlier.
  • SQL Transactions and Try/Catch/Finally
    • On the server side, instead of doing a series of straight SQL queries that change the database, you can open a database connection in a try statement and create the series of queries, then commit the whole transaction only at the very end, after everything else checks out.
    • If any part of the transaction fails, you can catch the error and rollback the entire transaction so that no part of it ever happens.
    • (And in the finally, if you still have a connection, you should release it.)
    • This allows you to make several related queries at once without being afraid that only some of them will go through, which could mess up your database.
    • Non-database functions that are harder to undo, like order or email sending, should be at the very end of the try statement, just before you commit the transaction. So if any other part of the try fails, those critical functions won't be run.
  • Some serious Express gotchas
    • The error handler is the first function passed into the router with four parameters (error, request, response, next) instead of three (request, response, next).
    • If you're passing anything into your next() function, it's read as an error and it'll go straight to the error handler.

One of the reasons I took this job was because during my interview, everyone I talked to taught me something new. I've been learning a lot from people here who are not only very knowledgeable, but willing to share their knowledge with others. Hopefully I'll get to a point where I can pay it forward more often.