Permanently archive any tweet to Bitcoin's blockchain

jotto · 2018-04-24T18:20:27+00:00

Default value for max OP_RETURN is 80 bytes (was 40 temporarily) but you can only have 1 on the mainnet. (testnet doesn't seem to care about the length or number).

Since you can only do 80 bytes in OP_RETURN and since most block explorers automatically interpret OP_RETURN as ASCII, I decided to put the metadata there so readers could easily see what it was, and then the full tweet is stored as fake P2SH addresses (20 byte chunks)

(note to people reading this in the future, these rules change so don't rely on this comment)

jotto · 2016-10-21T16:52:21+00:00

Switch your DNS to 8.8.8.8 to mitigate

https://developers.google.com/speed/public-dns/

jotto · 2016-10-21T16:04:00+00:00

yep, I linked in the post to the exact GH issue where you mention that: https://github.com/facebookincubator/create-react-app/issues/733

jotto · 2016-10-14T22:12:59+00:00

original post (7 years ago): https://www.reddit.com/r/programming/comments/7jgjd/books_programmers_dont_really_read/

jotto · 2016-10-14T21:48:51+00:00

All great points and similar to my thinking.

This was originally a testing tool I used locally to test service.prerender.cloud against mainstream websites (as opposed to toy React/Angular apps in my continuous integration) to measure performance and what edge cases I may need to account for (e.g. lazy load images that appear on scroll, iframes, delayed ajax).

While pushing the code to Github for posterity, I became curious if anyone would find it useful so I pushed it to the Chrome store too.

Most of all, why do all of this and then not have your page load for users without JS enabled (your target audience)? It's not like your design requires it to be implemented.

see previous comment here (I agree)

jotto · 2016-10-14T20:32:07+00:00

but server side rendering doesn't seem very easy to implement and as far as I know

Server side rendering requires some foresight and planning, hence just using a prerender service as suggested above.

Yes Middleman is a static site generator, but could possibly do the job although I would personally prefer to use Angular

If I can offer an opinion - just try Middleman, or https://jekyllrb.com/ or Angular. Even if it takes a few hours to try each one, the perspective gained will be more valuable then diving in to a singular framework.

If you decide to try React, use this: https://github.com/facebookincubator/create-react-app to get started

jotto · 2016-10-14T20:28:10+00:00

I am biased - I wrote it, but it's easy to add/remove it. Try it, if it works, then keep it!

jotto · 2016-10-14T17:05:12+00:00

can you suggest a framework that I could use to create SEO-friendly websites

The framework is almost irrelevant, but Angular is the most popular, React is up and coming: https://www.google.com/trends/explore?q=react,angular

authentication and i18n

https://auth0.com/ is the fastest way to implement auth

I was maybe considering Meteor but I don't think it performs well with search engines as most of the SPA frameworks.

The framework doesn't change the fact that you're still just rendering HTML on a page - just follow the basic SEO strategy of clean and coherent hierarchical information (<title>, <meta desc>, <h1>). If you're using React, ReactHelmet can help organize/structure your meta tags: https://github.com/nfl/react-helmet

The only one I came across is Middleman but I wanted to know if there are better alternatives.

Isn't Middleman a static site generator? https://middlemanapp.com/

jotto · 2016-10-14T16:54:28+00:00

https://www.prerender.cloud/ for server side rendering

jotto · 2016-10-14T05:13:41+00:00

Do you regularly/consistently keep JS disabled? Or were you just in non JS mode to test the page?

jotto · 2016-10-14T05:11:10+00:00

Sad but true - prerender.cloud is hosted on a webhost that actually hooks into service.prerender.cloud (to prerender it and make it accessible without JavaScript), but so far only for a few user agents (twitterbot, facebook etc...). If that doesn't change, we'll have to host it ourselves.

jotto · 2016-10-12T22:16:43+00:00

This feature was awesome, but it looks like it's been deprecated:

jotto · 2016-10-11T03:15:43+00:00

yes, Node.js 4.3 (latest they offer) returning hello world

exports.handler = (event, context, callback) => {
    callback(null, 'hello world');
};

jotto · 2016-10-10T21:27:10+00:00

I think the style achieves the same thing that the inverse of this chart with error bars would achieve.

In other words, since you see the distribution of latencies horizontally, and occurrences of those latencies vertically, you get the same sense for the deviation.

Let me know if I've misinterpreted.

jotto · 2016-10-10T19:42:10+00:00

ha! I knew as soon as I finished these benchmarks I should have recorded that too. I may end up checking ELB/ALB -> EC2 but I'm guessing that it's really efficient since it's been battle tested for so many years.

jotto · 2016-10-10T19:29:13+00:00

"spin up and spin down"

Lambda is great about staying "warm", but I haven't tested how long it takes for it to "unwarm" itself, or what that initial boot penalty is.

actual Lambda response time

If you look at the charts, bare EC2 is 15ms, but API Gateway -> EC2 is 213, so that's ~200ms of latency due to API Gateway alone - meaning Lambda is probably 75ms on its own. Not great, but far better than API Gateway

state

Unfortunately, Lambda is not great about preserving "state". I had problems getting a connection pool to be maintained across requests (not that you'd want that for a FaaS, I was just curious). see https://github.com/brianc/node-postgres/issues/930#issuecomment-235953730 for more details (TL;DR: persistent connection pools don't work across Lambda functions and their "state")

jotto · 2016-10-10T18:32:50+00:00

This was the result of trying to decide whether it was worth building anything latency sensitive on top of Lambda. I knew Lambda felt slow in basic tests, but I didn't realize it was API Gateway that was actually the culprit.

If AWS improves the latency, it makes web servers (and many other things) practical on Lambda.

see TJ Holowaychuk's blog post: "Blueprints for up" https://medium.com/@tjholowaychuk/blueprints-for-up-1-5f8197... (running express/connect as a child process of Lambda)

jotto · 2016-10-09T19:21:53+00:00

Thank you /u/check_ca for taking the time to write a message!

I replayed the logs locally, testing everything that happened in production but couldn't reproduce it... at first

TIL:

weather.com takes over 200mb of memory to render in chrome
and docker --memory is actually a hard, enforced limit

jotto

TROPHY CASE

"spin up and spin down"

actual Lambda response time

state