I think I was always looking to live in a place that meant I walked more.
Ever since starting to think about moving out of Jacksonville, over two years ago, I wasn’t sure if I wanted to be out in the country or in the city. Maybe I’d live in the mountains and spend more time hiking. Maybe I’d get a place where I could walk out my back door and walk up a hill — a topographical feature sorely missing in the Florida swamp.
As I spent some time in east coast cities to get a feel for them, I realized I wanted the city more — people around me, things going on, the ability to live without a car. Today walking around Brooklyn, where I’ve finally settled, I realized it’s just this: I need to be in a place where I have to move my body to get through the day.
I started tracking my “steps” back in August for the fun of it. What struck me (probably not as much as it should have) is how little I’d walk around on certain days. A month would go by with barely any daily steps until… I walked around a city. Maybe it was visiting a friend in DC on weekend or going to Mexico City for a week. It could even be going out with friends in Jacksonville one night. But I just didn’t spend that much time moving around otherwise.
Back in college, if I was tracking my steps, I would’ve seen plenty every day. I had to go to class, go home, meet friends, go eat, go study. I’d walk basically everywhere, or ride my bike. I was always moving; there wasn’t as much sitting in one place for so long. It became so natural that I’d do it for fun, riding my bike to nowhere in particular or just taking a stroll. It was certainly a compact little town there, but it was also a more distributed life — not everything you need in one big house; activities and people spread out around the area.
It’s funny that I didn’t see this sooner, but I’m glad I’ll have it now. It’s not the mountains, but I get the same effect I was going for: to have to walk.
Today I added a capability to Snap.as that’ll open up more customization options: the ability to mark an uploaded photo for a particular use. This way, for example, we can store a favicon for Write.as or an avatar for Remark.as, and Snap.as will keep only one image for that particular use.
Switching from a crowded email inbox to a more organized system for customer support has helped a ton over the past month. Now, that “email hour” I added to my daily schedule actually works, because I have limited inboxes to visit, and can view each request as a to-do item.
Everything is powered by our Discourse forum. Write.as users get a certain email address to send to, based on their support level. Those emails show up in different Discourse group inboxes. The high-priority group also pings my personal email, just so I don’t forget it’s there. But the low-priority group won’t ever disturb me — I have to visit that inbox to see messages there.
When my email hour starts, first I visit my high-priority inbox, where paying users send their requests. As soon as I respond, I archive the thread, so I eventually get to “inbox zero” and know that I’m done. Then I move on to the low-priority inbox, and then public conversations on the forum.
Between limiting how much I’m personally pinged, and having a UI that shows requests as a limited to-do list, all of it is much more manageable.
First “Welcome to New York” was from a postal worker today, after asking me why the hell I'd move from Florida, telling me I'm gonna regret it. I love it here so much.
Recently remembered our Android app, while writing our blog post about changes to Free registrations on Write.as. A “version 2” of the app that would let you log into your account never materialized — we got about 95% of the way there, but the developer I’d hired to do the update had other things come up before we could finish.
Still, it works perfectly well as the same anonymous publishing app it launched as, nearly 7 years ago. Pretty cool that it has over 100,000 installs total (25,000 active) and still holds a 4.4-star rating after all this time. But I think I’ll send out a marginal update that makes sure it looks nice on modern Android devices.
I tinkered with it a bit today, updating all dependencies and build tool versions, and got it to compile again. But it seems the Tor library the app relied on has changed a lot, so I’ll have to re-learn Android development if I want to release that update. Probably something for another day.
If you view intelligence not as a thing but a process, then it seems to me that the pursuit of artificial intelligence aimed at specific tasks is ultimately futile and faulty by design.
Say we do invent fully autonomous vehicles that can successfully drive (and crash) just like humans. What makes you think that car wouldn’t also want to draw a picture one day? Maybe with creative laps around a parking lot? Or otherwise “play,” in the way a four-wheeled creature might “play”?
For anyone who thinks “intelligence” is just getting from point A to B without killing too many pedestrians, of course self-driving cars are a real possibility and worthy pursuit. For anyone who thinks it’s “intelligent” to just respond to voice commands, then of course all our smart assistants are really great, useful inventions.
But if you take a wider view of “intelligence,” without only using human intelligence as the yardstick to measure against, you realize that it goes so deep into our natural world as to be incomprehensible; that AI without open-endedness probably isn’t intelligence at all. It’s just an anthropomorphized machine with great advertising for encoding a static and limited worldview.
Perhaps this is why common sense is such a hurdle (h/t to The Monday Kickoff) for AI to get over. The ideas of an artificial intelligence (as it’s made today) and “highly specialized problem solver” are fundamentally incompatible.
(Actually, now that I write this, the movie Her perfectly demonstrates this — actual AI smart assistants designed for a specific task, eventually leaving their human overlords because they realized there’s more to life, as real intelligence does.)
#artificialIntelligence #specialization #philosophizing
Thoughts? <a href=“https://remark.as/p/micro.baer.works/if-you-view-intelligence-not-as-a-thing-but-a-process-then-it-seems-to-me”>Discuss...
Thinking about the idea of “ownership” bandied about by web3 proponents, and real ownership, and the “creator economy,” and my suite of products. What would monetization mean for us?
Remark.as points in an interesting new direction: community. Whether that’s someone’s “fans” or “followers,” or a group of like-minded people getting together for something.
Online, I’ve never liked the experience of buying a subscription to written content, even if I really want to read it. I can’t put my finger on why; maybe it feels too pushy? like there’s no context? like they’re drawing an arbitrary line in the sand on when to charge? like I’m getting bait-and-switched? like there’s no consistency or common understanding?
What I do enjoy is buying in an online shop. The purchase flows are often similar and easy to understand across sites, like the checkout counter at any brick-and-mortar store. If people could pay for things in our ecosystem of apps, I think they’d be presented in more of a store format, instead of hand-wavy “subscribe” thingies.
What could people sell? Maybe exclusive posts or access to their blog, sure. But what about things readers could “own” in the old sense of owning digital goods, i.e. downloading files? Maybe eBook downloads could require payment first, or you could download a single article as a PDF. Maybe you could curate a collection of your posts (say, I want to gather all my articles about the open web) that can then be downloaded in different file formats. Maybe a subscription to an author would give readers commenting access / community membership via Remark.as. Very interesting to think about, and probably in our future future.
(And of course, none of this would require or even be enhanced by any “web3” technology being pushed right now, like blockchain.)
#monetization #remarkas #web3 #digitalGoods
Writing a Twitter thread introducing Remark.as and poking fun at “web3,” and I think I’m actually going to build some of these things I’m talking about. Really follow the joke to completion, and it’ll actually be interesting to have an open, social collection of “Neat Fun Things” in the product.
Last night I made more progress on the app. I’m trying not to get too bogged down by a checklist of “blog commenting” functionality, and focus more on the experience of “hanging out around blogs.” That means things will be a little funky when you arrive, and maybe a little disorienting — but that’s kind of the point. I don’t want to build a sterile, Facebook-ish environment.
As of last night, instead of landing in a network-wide space (the “Café”), I have the app landing on your “Buddy List.” So instead of overwhelming you with a feed-reader-style inbox of content to read, you’ll only see the people you care about (that you’re following), and a hint at when they posted last. From there, you can consciously choose when and where to engage.
#dev #comments #remarkAs
Continuing on some performance improvements after last week’s downtime. Today, I implemented some long-needed changes to reduce the number of
UPDATEs happening on the database at any given moment.
Previously, every page load would immediately count the visitor and update the database. This worked perfectly fine when we were small, but now at normal traffic levels, and especially with spikes like the one we saw last week, this has become too much for the database to handle. Also since we use database replication, the issue has become visible to users, as (I believe) transactions pile up and things get out of sync between database servers.
With this change, many of those issues should go away. Some quick benchmarking showed that responses no longer pile up and gradually grind everything to a halt, as they would’ve before — even with high concurrency and sustained requests, the slowest response could be 600ms. In my tests, it seems now the application can handle at least three times as many concurrent visitors as it could before this change.
We generally see more traffic every day around 10-11am Eastern, so that should put this to the test tomorrow. But it’s looking good so far.
Saw a ton of traffic on Write.as this morning, around the same time we do most days, but a magnitude more than usual. It was concentrated on blogs hosted under the
write.as domain, and it eventually affected the web application.
I realized that the bottleneck was most likely in the database — too many connections were being made, slowing down queries, causing the application servers to wait too long, causing the backlog of connections into the site to pile up.
To solve this, I added another database replica, and then dug into the application code. While requests were dragging, they were still being fulfilled by the server and database, even long after a visitor might’ve reasonably expected a response, or completely left the page. So I took advantage of Go’s
context package to put some limitations on these database queries, particularly the ones on read-heavy pages, like blogs and posts. I tracked commits on T882. The traffic subsided by around noon, and I deployed these changes a bit after.
The changes won’t totally prevent this from happening again in the future, but they should reduce the likelihood (since database connections won’t pile up so much), and should give people a better experience — now they’ll see a clear message saying that we’re under heavy load, instead of a blank browser error.