avolcano

Huh, I came _very_ close to doing it, but saw enough negative reviews to put me off. To be fair, most of them seemed to be people who had bad experiences in the shared (hostel) sleepers, though, most of which seemed to not really be the fault of the train (just lots of complaints about snoring and such, which, like, is why I always have ear plugs when I travel), but some complained about broken AC and busted toilets which sounded like... well, a normal Amtrak experience, but not something I really wanted on my vacation.

Excited about this idea. I wanted to do an overnight train in a Europe trip I did last year, but the timing and quality never quite worked out. A lot of the time, trains between cities in western Europe are annoyingly long for a day trip, but slightly _too short_ for overnight trips - almost like an NYC->London red-eye, where you arrive just after you fall asleep. The couple of overnight trains I saw that seemed like they'd work out timing-wise, like Paris to Venice, had really poor reviews, but I assume that's down to the various companies running these services, who probably haven't invested much in them lately as budget airlines continue to compete so heavily.

Sweden seems perfectly set up to invest in overnighters, though, as the article notes some theoretical routes. Norway and Denmark would benefit too, I think; at one point I was investigating doing a trip that would involve going from Oslo to Copenhagen, and the only reasonable non-flight options were an overnight _ferry_ (which, all things considered, was surprisingly cheap, though I'm sure they gouge you on food and the on-ship shopping mall), or a 7 and a half hour train trip that'd take all day. If Sweden were running overnight service along that route through Gothenburg, connecting those countries, it'd be a pretty awesome way to get between places.

I did something similar a couple years ago for a game, where I simply wanted to track active player count over time: https://devlog.disco.zone/2016/09/02/google-sheets-analytics...

Roll-your-own is really nice when you have small data and when you have simple numbers to query (such as "get number of active players").

Postmark has the most interesting credit IMO, even if it's not a particularly huge one:

> Postmark - If you’ve launched your product, are charging for it, and haven’t taken outside investment, contact the Postmark support team and they'll give you $75 account credit to help with your email costs.

A lot of these discounts are based on the assumption that you're a VC-backed, or about-to-be-VC-backed startup, that will have enough runway and growth to stick around for a couple years, and will smoothly transition from a steep discount to a 4-digit monthly bill around the time you land your Series A or whatever. I like Postmark's because it's much more reasonable - "you _don't_ have VC money, but you have an obvious path to making money (and thus being able to pay us), so we'll give you some credit for free as you get up and running."

I've been totally freeloading for a side project of mine that I _don't_ expect to make any money, but in researching cheap plans I came across a lot of these sorts of discounts (usually while looking to see if they had an open source discount, since my side project is open source). It's an interesting gamble, but I respect Postmark's the most, I think.

Worth noting that here in NYC, the courts have gone back and forth on whether passing transaction fees onto consumer is legal: https://www.law.com/newyorklawjournal/2018/10/23/ny-court-of...

I remember being shocked when my local pizza place put a sign on the register saying there was now a 3% fee on card usage (which became legal to do as of ~September 2017). Absolutely wild that Visa/Mastercard would raise prices further. It's already hard enough to find a place that accepts my Discover card, let alone an independent joint that will accept Amex (accept for all the places in and around Chinatown who only accept Amex, never will understand how _that_ happened).

I suppose I could also use DO's Spaces, which is S3-compatible, though also has an annoying minimum (I do not need the 250 gigs you get for $5/mo) https://www.digitalocean.com/products/spaces/

That's kind of fair. I've been doing some thinking since posting this, and I've been sort of debating what a "reasonable $5/mo version" of this would be. The more I think about what managed database services usually entail, the more I concede that my original request probably isn't really a viable product (unless it was a "free tier"-style loss leader). Like, disk space and bandwidth aren't really the primary cost involved.

I think what I really want is managed backups that live outside of my box, and the ability quickly restore from one if my database crashes or becomes unusable. I think automated failover to another node may not be a reasonable ask for such a cheap product.

Of course, at that point: I could spin up a 1GB DigitalOcean volume for $0.10/mo, and set up scripts to run `pg_dump` every couple hours, clean the volume of older backups to free up space, and ideally a script to reset the database to a given volume. _That's all stuff I don't want to do_, but maybe someone's built a reusable set of scripts for it or something - that Dokku container is promising as a starting point, though I'm a little annoyed it only works with S3(-compatible).

I have to say, I'm extremely disappointed by the pricing. It doesn't seem any cheaper than AWS's managed SQL offering (through Lightsail), nor cheaper than Cloud SQL.

I'm trying to run a side project at a low rate, which is usually why I go to DigitalOcean - it's much cheaper, than, say, spinning up a bunch of Heroku dynos. In fact, I just moved a project from Heroku to DO to go from a $14/mo hosting bill to $5/mo on the cheapest VPS.

My one problem has been Postgres - I don't want to self-manage a database. However, Cloud SQL is ~$9/mo at the cheapest, and RDS/Lightsail are both $15/mo at the cheapest. I'd really been hoping that DO would provide a lower-cost alternative.

I'm really sad that the pricing structure doesn't bring managed databases down to hobby-tier. I don't even want a free offering; I'm happy to pay gig of space for $5/mo to run in perpetuity, with restrictions on backup retention or something.

Right now, if I'm an actual startup or even bootstrapped company with money, I see _zero_ reason to use DO's offering over your more-established competitors, and as a hobbyist user, I can't justify spending money on it for a no-income side project.

Ah yes, "useless" subway lines that carry [checks notes] 5.6 million trips a day.

I'd rather have money go towards our public transit system, no matter how fucked up it is at the moment, than spend another cent on bringing tech jobs that will come here no matter what. NYC's been a "true technology hub" for a long time, regardless of one giant company deciding to abstain from coming here.

First thing I thought. Wonder what he's been using to animate Google Earth in his existing stuff - manual camera movement and screen recording?

The bit I love about the Elm Architecture that I really wish existed in other frameworks is the "Command" system, by which the "Update" step can dispatch further changes. Basically, imagine if a Redux reducer could dispatch further actions.

I've tried building Redux apps with bidirectional real-time communication (re: networked video games), and found myself having to pull almost all of the logic up to the action layer, as I often needed to dispatch further side effects based on changes that happened as the result of an action. It made my reducer into nothing more than a dumb setter, and caused me to have to write complex mocked tests for my action layer instead of my reducer layer.

I know there's been some attempts at bringing this to Redux (such as https://github.com/redux-loop/redux-loop), but from what I've seen it isn't quite as easy to use.

OTOH, I will say, as an outside observer, it sounds like Elm has run into problems with this approach (see: the removal of WebSockets from this guide, pending a rewrite), so I am curious to know more about what issues arose.

Sure, and apologies for the harshness in my original post.

My main complaint about the marketing landing page at https://cloud.google.com/appengine/ is that it doesn't contain any immediate information about the different environments. It does have a link to "Choosing the right Environment" but it's _waaay_ down below the fold. In general I wish Google Cloud product pages had their big "View Documentation" buttons up at the top next to the free trial button, instead of way down below the pricing section.

In addition, neither the "Choosing the right Environment" nor the "App Engine Standard Environment" docs linked at the bottom of the product page contain detailed information about the second-generation standard environment, which is frustrating. I do appreciate that the language-specific pages in the main docs link contain a short comparison that includes the beta environments, at least.

That said, the primary document comparing the environments (https://cloud.google.com/appengine/docs/the-appengine-enviro...) seems very out of date. For example, it mentions you should use the flexible environment if your app:

> Depends on other software, including operating system packages such as imagemagick, ffmpeg, libgit2, or others through apt-get.

However, the Node standard environment contains these three packages and more (https://cloud.google.com/appengine/docs/standard/nodejs/refe...).

There might be other nit-picks to be said, but really, my main criticism of the documentation is that trying to understand the split between "standard/flexible/second-generation standard" environments at first glance is tricky. I'm sure y'all have plans for this going forward as these environments come out of beta, so I'll hold off on whining too much more. Thanks for asking for further feedback, and for clarifying that the new PHP runtime is a second generation one.

The state of App Engine environments seems super confusing, but I _think_ this uses the "second generation standard environment" like the Python 3.7 and Node 8 beta environments, which means that unlike App Engine of Yore, you have access to the full package ecosystem and full network access. I'm not actually 100% sure on this because it's not listed on the runtime page (https://cloud.google.com/appengine/docs/standard/appengine-g...), but the docs show that you can use composer, unlike the PHP 5.5 runtime.

The documentation for all these second generation runtimes is shockingly bad. I consider Google to be _generally_ pretty good at documentation, but this is one of those cases where their propensity for confusing naming and classification of their products makes it hard as hell to figure out what is going on. It doesn't help that the top-level "product overview" page is useless marketing junk (microservices! serverless!) instead of a practical description, which is buried several links deep.

Having never used App Engine but occasionally wandering into its docs when a new product gets announced like this, am I right in assuming that App Engine's "second generation standard environment" is more or less equivalent to the feature set you'd get from Heroku? The flexible environment also continues to confuse me - it talks about being a managed Docker container, but it doesn't seem like you actually get access to anything like a Dockerfile and that's more of an implementation detail on their end.

Uh, as a frontend developer, I am kind of _shocked_ I've never read this before. There's a lot of fascinating parallels to modern web development. zitterbewegung noted the similarity to complaints about Electron apps' memory consumption, for example, but:

> The right graphical client/server model is to have an extensible server. Application programs on remote machines can download their own special extension on demand and share libraries in the server. Downloaded code can draw windows, track input eents, provide fast interactive feedback, and minimize network traffic by communicating with the application using a dynamic, high-level protocol.

Certainly sounds a heck of a lot like how web applications work (even though we're currently terrible at sharing libraries, heh).

> X gave programmers a way to display windows and pixels, but it didn't speak to buttons, menus, scroll bars, or any of the other necessary elements of a graphical user interface. Programmers invented their own. Soon the Unix community had six or so different interface standards.

Now _that's_ certainly familiar. Sure, the DOM is a heck of a lot closer to a platform for displaying complex UIs than X was, but it still falls so far short of what developers need that a plethora of frameworks, UI libraries, etc. have appeared and fragmented the community. You could also stretch a bit and say things like Google's work on web components are an attempt at a Motif-like standardization around one questionable standard, but I don't know if I'm quite cynical enough to make that jump.

> Even if you can get an X program to compile, there's no guarantee it'll work with your server. If an application requires an X extension that your server doesn't provide, then it fails. X applications can't extend the server themselves -- the extension has to be compiled and linked into the server.

While a lot of new browser features are polyfillable, a lot of the more advanced ones (e.g. service workers) are not, and users and developers are at the mercy of their browsers, much users would be with their X servers.

> Myth: X is "Device Independent"

The quirks discussed in this section apply to responsive web apps too. There's actually quite a bit of nuance in making fancy canvas, WebGL, or CSS transforms that look good on retina screens, etc.

I'm sure none of these comparisons truly map 1:1 to X development (having never done it myself), but damn if it doesn't remind me how cyclical software development has been over the past few decades. Not that that's a bad thing, just that some things are very, very hard :)

This was my immediate question too. Microsoft offers a service called CodePush (https://microsoft.github.io/code-push/) for React Native and Cordova apps that presumedly could get caught by this. I don't have enough mobile dev knowledge to know whether or not it uses the same APIs that were mentioned in Apple's rejection letter, though.

The author using FizzBuzz as a comical-but-recognizable launching point for demonstrating introducing the basics of programming language implementation and RPLY, and the HN comments being nothing but people yelling about FizzBuzz, is a pretty amazing summary of the state Hacker News comments. It also makes me think next time I have a technical article, I should prepend some controversial statement to it just to generate buzz :V

In all seriousness: this is a really cool article, thanks for sharing! I'm not very familiar with RPython or RPLY and it was really cool to see a "real-world" example of it. I actually just read through something similar in JavaScript (https://github.com/thejameskyle/the-super-tiny-compiler). I really should give language implementation a shot one of these days (closest I've come is writing a JSON lexer & parser); always like to read about it!

In case anyone was curious, the logged-in app remains basically the same, but that's not a complaint or anything. Been using Sentry for several months on a personal project and absolutely love it; dig the new look on the marketing side!

I wanted to use VSCode when I started writing TypeScript three months ago, but I found the Vim plugins super lacking, so I used Atom instead, which has a much more robust Vim plugin.

However, I tried VSCode again last week after being disappointed by continued bugs in atom-typescript, and was happy to discover the Vim plugin (https://github.com/VSCodeVim/Vim) had made a ton of progress since I'd last given it a shot. It's still not quite as good as Atom's, but it's definitely getting there. Plus, the project's team is very active and friendly - I actually submitted a PR a few days ago fixing a bug (the VSCode extension development workflow is super easy, it turns out!) and they quickly merged it :)

I also found out that the VSCode developers know that it's an important plugin, and they actually have a category of issues on the VSCode repo specifically for extension APIs they need to add to make the Vim plugin as powerful as possible. This new update includes several of those, and I have a feeling by the end of the year the Vim plugin in VSCode will be on par or better than that of plugins for other editors.

I'm generally very sympathetic to regex bugs (especially in a language like JavaScript where you don't get nice expanded multiline regexes with comments), but I am wondering why they went with a regex in the first place. Did they decide `document.location.host` was too brittle for some reason?

Yup, this is my biggest issue with JavaScript's built-in functional utilities. It just totally ignores treating objects like dictionaries/maps. Even ES6 Maps/Sets lack functional features.

There's a strawman proposal out there to solve this but until then I'll be sticking with Lodash: https://github.com/leebyron/ecmascript-iterator-hof

There are two types of "web storage" that you could use for this, localStorage and sessionStorage. The former persists indefinitely, the latter is removed when the tab is closed.

If you wanted user tokens to persist past the current browser session, you'd use localStorage.

I think you could allow cookies only for the initial request (you may even be able to simply only allow cookies for GET requests, as long as you're careful to ensure your GET endpoints don't have data-manipulating side effects) and require passed tokens for all other kinds of requests.

For example, you could use a cookie to authenticate serving GET /user/account-settings to render an HTML form, but then require submitting the form (e.g. POST /user/account-settings) to pass a token from localStorage.

This wouldn't protect you from all kinds of cookie-based attacks, but at least you'd have a guarantee your endpoints aren't vulnerable to CSRFs.

It's funny, I got started with web development relatively recently (2012 or so) and immediately started working on single-page/client-side applications, so I used localStorage from the start. It seemed easy enough to make a little Ajax wrapper for all my requests to tack the authentication token on (whether as a URL param, form data, or header data).

Imagine my surprise when I later learned how cookie storage worked! There was a brief moment of "oh, I guess not having to manually append this to my requests would be nice," only to read about CSRFs and other horrors cookies enabled.

Since then, I've fixed multiple existing CSRF exploits in production (or near-production) applications, and continued to avoid cookies wherever possible.

fwiw, TypeScript -> Babel is doable, if painful. I have it set up in my repo here: https://github.com/thomasboyt/manygolf

I agree that Flow currently the superior type system (and, unlike TypeScript, not a complete nightmare to set up if you're wanting to use Babel/Webpack instead of manually running file builds through your editor like it's 2002), but TypeScript has significantly more momentum behind it making it a much more practical solution for basically anyone who doesn't currently work at Facebook. There are also several exciting new features coming to the type system that brings it closer to parity with Flow:

Non-nullable types: https://github.com/Microsoft/TypeScript/pull/7140

Control flow type analysis: https://github.com/Microsoft/TypeScript/pull/8010

I wish TypeScript tried to better-integrate with the greater JavaScript ecosystem and stop acting as a language of its own. Thankfully, the "es6" target gets it pretty close (I think it still compiles some es7 features, meaning you can't have Babel handle everything yet), and the non-standard module syntax seems to be a thing of the past.

I hope the gap can be bridged between the TypeScript and Babel communities, so that TypeScript can one day be shipped as a Babel transform, same as Flow.

When I started using TypeScript a couple weeks ago I briefly tried out VS Code, but the VIM plugin was really, really bad (worse than Sublime's was when I used it a few years ago).

Now I'm on Atom, which has the best VIM support I've ever seen (haven't tried evil-mode, though) and seems to support a similar feature set. They felt about the same speed, too, on this 2013 Macbook Air.

Regardless, other than that quirk, I did really like VS Code, and I'm glad there's more competition in the free editor space :)

Also seconding the confusion that other commenters have regarding the "three commits max" rule for automated deploys. Maybe engineers at Facebook are just big fans of rebasing, but I often make commits on feature branches that don't "stand on their own" - i.e., would break some functionality without subsequent commits. I'm not sure why you'd want to deploy one-commit-at-a-time unless you kept a very strict "one commit == one standalone feature/bugfix" rule, which isn't mentioned in this post.

(I suppose it's also possible that that's referring specifically to merge commits into master, which would make a lot more sense to me)

Spotify is down due to this, which is, uh, pretty hilarious https://news.spotify.com/us/2016/02/23/announcing-spotify-in...

I still use Grunt for small, one-off tasks that I'd like to be able to configure declaratively. For example, it's useful to wrap Webpack to make simple static deploys: https://github.com/thomasboyt/monotron/blob/master/Gruntfile...

I imagine that if I was more comfortable with shell scripting I could just use that, but I do like declarative tasks a lot, and there's very little overhead to adding Grunt to a JavaScript project.

I wonder if there's a set of API hooks they could expose to allow third party applications to handle more advanced code review techniques? I would totally understand GitHub not wanting to implement a full Phabricator/Gerrit review feature set, but maybe they could make it easier to integrate other services for it.

Oh, nothing on its own in that tiny example. In practice, it's just a component that could be used in a larger application and can be easily tied into the same rendering and state trees.