In my last website post I talked about my plans for setting up website notifications on AWS Lambda and DynamoDB. The idea is that a function on AWS Lambda would get called when the site had an update, which would fetch all the site data, diff it against the previous state, and determine which pages actually changed. Those changes would get saved to AWS DynamoDB, which has a streaming feature that other AWS Lambda functions can be triggered by for each event. Multiple Lambda functions (one for each service) would get those updates and fire off whatever integration was necessary for each service.

This would put the burden of running the service and hosting the data to Amazon’s ops crew, which is undoubtedly better than what I would have set up. As long as I stayed within the limits of the AWS free tier, which looked pretty decent, I would be able to run this in perpetuity, right?

Read More

I created an account on Mastodon.social, you can find me on @stevestreza@mastodon.social. If you’re into that sort of thing, you can follow me over there.

Eventually I hope to create an ActivityPub setup that can publish directly to my own site and the Mastodon network. But until then, this is good enough. Between Twitter’s ongoing moral cowardice and their ongoing hostility towards the developers that made them what they are, I can’t continue siloing my data there.

But Mastodon is so far revealing itself to be much more pleasant than Twitter, and it has some interesting forward-thinking decisions that I’ll talk more about later. In the meantime, go find me on there. You can sign up on the instance I use, Mastodon.social, or you can sign up at any number of other instances, such as those found on instances.social or joinmastodon.org. Even if you sign up on a different instance, just search for my handle @stevestreza@mastodon.social and it should work just fine.

Link

Apple’s App Review has made another sweeping change that is disrupting the lives of developers yesterday, kicking out a bunch of apps without warning that are for gambling. Many of the apps involved have either nothing resembling gambling mechanics in them. And many of these are from small developers who effectively have no recourse.

It appears that this was a massive overreach that is actively getting walked back by Apple, but it still highlights the fact that Apple can and will terminate your business on a whim, without warning, based on whatever reason they like. And since you can’t bypass the App Store like you can on Android, if your business depends on this, you’re toast. Decisions like this are why I don’t make my own iOS apps anymore.

Apple’s official line:

In order to reduce fraudulent activity on the App Store and comply with government requests to address illegal online gambling activity, we are no longer allowing gambling apps submitted by individual developers. This includes both real money gambling apps as well as apps that simulate a gambling experience.

As a result, this app has been removed from the App Store. While you can no longer distribute gambling apps from this account, you may continue to submit and distribute other types of apps to the App Store.

They’ve pulled magazine app (since restored), a GIF search app (since restored), a YouTube search app (since restored), a YouTube player, a photography app, a Reddit client (since restored), and many others. It’s unclear if these were all automated, though in at least one case it appeared to involve a call to Apple developer support. There’s also an 11 year old blackjack game and a poker chips calculator app, which possibly could fall under some definition of “simulated gambling”, which is now apparently against the rules for some reason.

Since there is no oversight of App Review or the rulings it makes, there is no way to know the full extent of the bans, how many apps were affected, or what percentage of them are being reinstated. Still, it sounds like this was an error at least some of the apps are returning. I’m sure the developers could’ve done without the panic attack from an email suddenly stating that their apps were kicked off, though.

Meanwhile, Apple continues to allow and profit heavily from apps with actual gambling mechanics like loot boxes and gacha games that encourage people, including minors, to gamble.

Link

Homebrew Website Club Seattle Notes


Tonight I went to my first Homebrew Website Club at the Wayward Coffeehouse, a real nice coffee shop. I got to meet Doug Beal who put the Seattle club together. It was mostly just the two of us, as well as Margo Vansynghel, a reporter who was interested in what we were up to and how it related to other tech stories about silos like Facebook.

Neither of us really had been to one of these events before, so we weren’t sure what to do. We mostly worked on our own sites, and helped explain some of the IndieWeb principles about things like data ownership and building tools for yourself. I think by the end of it she had sent her first Webmention, a standard I need to learn how to use soon for this site.

I continued working on the syndication system for this site I outlined in the last post. I’ve now got the DynamoDB set up working, so when I commit any post change to the website, it gets built and triggers a Lambda function to scan the entire site for changes, logging those into DynamoDB. This creates a stream of create/update/delete events that other Lambda functions can be triggered by. With tonight’s work, I hooked a new microservice up to that which publishes created posts (but not updated or deleted posts) to a Telegram channel. It works locally with hardcoded keys, so now I just need to make it work when deployed, which should be quick; I just need to figure out how to store credentials properly. Then I can start building out more syndication methods.

Toward the end, we answered some questions about IndieWeb, took our group photo, and went our separate ways. It was a great time, and hopefully we can start building out a proper Seattle club. If you’re interested in taking control of your online data, consider stopping by an event near you, or a virtual one online. They take place every two weeks; the next one will be on August 22.

AMD’s Threadripper CPU platform snuck up on everyone last year and revealed itself to be an incredible platform for high-end computing with chips going from 8 cores to 16 cores. Just one year later, they’re taking that platform all the way up to a mind-bending 32 CPU cores. It fits nicely between their mainstream Ryzen CPUs and their Epyc CPUs to take a prominent place for workstations used by professionals.

The new chips come in 12, 16, 24, and 32 core varieties, each with AMD’s take on hyperthreading that effectively doubles the thread count. And these chips are priced at $649, $899, $1299, and $1799 respectively. This puts each chip at roughly $54-$57 per core. Intel, by comparison, can’t come close to hitting those prices. Intel’s workstation CPU flagship, the 18-core i9-7980XE, costs $1879 while having 14 fewer cores. At every rung of the ladder, Skylake X costs significantly more per core. On the server side, it’s even worse. Xeons often cost several thousand dollars.

AMD is singlehandedly responsible for revitalizing the desktop CPU market, leaving Intel scrambling, and I’m really excited about the future. I’m strongly considering stepping up to the 2920X and its 12 cores and 64 PCIe lanes, and finally building Hackintosh support into my machine.

Link

Fortnite Skipping the Google Play Store


This is a real power play. Epic Games is planning to push Fortnite outside of the Google Play Store by asking users to install an APK file. This will help them run around the exorbitant 30% fee that Apple instituted and Google adopted for their app stores. This isn’t the first alternative app platform to appear on Android; companies like Baidu, Tencent, Itch.io, the open source F-Droid, and even Amazon have their own stores. But it is probably the first that will get major mainstream attention (and installs) in the west. Fortnite is big enough; this will probably work.

Read More

The new Gatsby website has been soft launched for a couple weeks now and seems to be working pretty well so far, so I’m now moving on from building out the site to building out a bunch of tools for sending out notifications of new content. My hypothesis here is that if I can make the barrier to entry as low as possible for people to get notified of new posts, they’ll be more inclined to read them, and that means going where people already are. Obviously RSS is a great technology for this, but it never really recovered from Google Reader meeting its far too early demise. People use algorithmic news apps, social networks, chat apps, and more to find and share posts, and so that’s where I need to be.

So far I’m planning on distributing posts to:

  • RSS/Atom/JSON feeds
  • A Twitter account
  • A Telegram channel
  • Medium
  • Flipboard
  • Apple News
  • Email
  • Mastodon

I’m a big believer in making a bunch of little systems that work together rather than one big monolithic system. I chose to build this project using the Serverless framework built on Amazon’s AWS technologies like Lambda. I really didn’t want to manage keeping processes alive and setting up things like cron jobs, so this makes a lot of sense. There are also a few other endpoints I want to implement later for the site like Micropub and Webmentions which would be nice to have managed through Lambda rather than running forever on some VPS somewhere.

Once it’s working, the basic pipeline looks something like this:

  1. I create a post (or make some change the site) and commit it to a Git repo
  2. I push the repo to my GitLab server
  3. When GitLab receives a commit, it kicks off a CI job to build the site and deploy it.
  4. Once deployed, it sends a message to an AWS Lambda function to signal the site has changed.
  5. The function on Lambda downloads a copy of the current website data and a copy of the last seen website data from AWS DynamoDB
  6. New and updated posts are sent to a WebSub server (you might remember this as “PubSubHubbub”) to signal to anyone who subscribes that the page changed. (Which means that, once this is working, the entire site will support WebSub as a server-to-server push mechanism!)
  7. New posts are inserted as rows into a DynamoDB table
  8. A series of AWS Lambda functions will be listening for insert events on that table, one for each service listed above, and they will farm out the API calls to each service

I like this approach because it’ll hopefully mean there is some resilience to normal maintenance things like server restarts and database failures. It fits nicely with a lot of open standards being pushed by the IndieWeb movement. And it’ll be automatically integrated into the build process, so I won’t forget to actually do the crossposting. It’s already well underway with a lot of the infrastructure in place; steps 1-5 and step 7 are all finished. All that’s left is to set up the individual integrations with each service and connect the WebSub plumbing.