I went into this article strongly disagreeing but I think the alternative presented at the end are valid ways to structure an API and for those who very loosely follow REST structuring would probably consider the alternatives "REST" too.
REST seems to have different definitions depending who you talk to. Some define it very strictly (as the opening of the article seems to do) and others define it very loosely (as a JSON interface with GET/POST/etc commands). For those who implement REST loosely, the suggested alternatives fit right in.
It appears to now have been resolved. It was down for over 30 minutes. For most of that time, the status page was not accessible at all and when it did finally become accessible, it displayed no major problems.
I've built TwitRiv that does exactly this. It is open source where you can use your own API key and then there is a hosted version (the hosted version would not use your own API key but you authenticate with OAuth2).
TwitRiv.com is part of my 12 Startups in 12 Months Challenge (Open Source Edition).
It is inspired by the simplicity of Nitter.net but it uses the official Twitter V2 API. It has the benefit of allowing you to connect directly with your account so you can see users you actually follow on the main timeline, but that also means it has limitations imposed by the official API limits.
This is a really great breakdown of the TCP slow start algorithm. I always try to keep sites as lean as possible, but this was an aspect of TCP that I wasn't familiar with but will definitely be keeping it in mind in the future.
I started working like this in the summer of 2017 so I'm right at the 5 year mark with this setup (I actually need to get a new device and DO's prices have remained the same - I think they've actually gotten cheaper and I'm on a more expensive plan - $5 vs now they have a $4 option).
Due to my client work, I need an online test server so I'd be paying for a test VPS either way.
Being able to open my Chromebook and tmux into any project in about ~15 seconds provides enormous productivity gains for me. Not sure if I mentioned this previously, but I'm a freelance developer and sometimes juggling 6-8 clients at a time so being able to pull up any project at any time from any device with SSH access is very powerful for me.
Just saw this response. In my comment above, I didn't want to spend a lot of time responding to the original post so I handwaved a lot with this "assuming you've set the CNAME and network up for that functionality"
After a DDos attack, they were much more explicit in their recommendations: "We strongly recommend against using root domains. Use a subdomain that can be CNAME aliased to proxy.heroku.com, and avoid ever manually entering IPs into your DNS configuration."
https://web.archive.org/web/20110609095616/https://status.he...
I believe that some larger providers are providing some work arounds which makes it easier to hack around the issue these days, but I still firmly believe that if you set your site up using "www" (even if it is initially an A record - most of mine are A records right now), you will have more flexibility in the long run than if you set your site up on an apex domain.
Just to clarify, I use a $5/mo DigitalOcean droplet plus an extra dollar or two for backup and then a rsync.net account (that I use for other backup purposes too). Off the top of my head, that is the extent of my expenses for this set up (it's possible I might be forgetting/missing something).
And you are correct, that I work through the Chromebook but when the other monthly expenses don't exceed the cost of lunch, I don't think there is too much missing subtext.
I pay a little extra for DigitalOcean's backup service and then I also have an rsync.net account (they offer a HN discount that you can email them and ask about if you are interested).
It may be, I'm not positive what my Chromebook specs are. I know the droplet has more disk space. I use TACE[0] style development so I don't need a powerful machine.
I like to work outside at different parks (in the shade under a covering) and haven't noticed any "dim" screen issues.
One of the nice things about working with an under-powered system is that you know any users who use what you build probably are viewing it with a device that has more power.
My experience is that the touchpad on Chromebooks is high quality and really nice (I prefer it to a lot of other touchpads I've worked with). I can also boot fully into Linux (slightly different than what is described in the tweets), however when using Linux, the touchpad becomes terrible.
I'm guessing if I spent time figuring out the proper drivers I could probably get it working nice on Linux too but it just hasn't been worth the effort for me.
I really like the keyboard too, but I think that is probably more individual taste.
I do all my work on an under $200 Chromebook. I have a VPS where I do all the actual work. I use Mosh and TMUX for connecting and saving my different projects (I'm a freelance developer who is often juggling multiple clients). Basically, the Chromebook is just an SSH client and a web browser (I can also boot into Linux if needed - slightly different than described in the Tweets).
I've been doing this for years. The battery life is great and it is also nice knowing that I never have to worry about losing my device since all of my actual work is on a server I can login to using just about any other device including my phone. Most people are shocked when they see my "work station."
I read about people using TMUX and a VPS as a development environment here on HN a long time ago and have never regretted the move.
I completely agree. I'm promoting a concept called TACE to get back to the principles of the web that were being promoted between 2000-2010. I've realized that a lot of web developers these days don't understand the basic principles of HTML, CSS, and JS because they initially learned web development using a Javascript framework.
I'm a www advocate and reroute my domains from apex domain to www. When you use an apex domain, you have to use an A record which means if you have a server outage it is going to take time to update the record to point at a new IP address. If you use www with a CNAME, the final server IP can be quickly switched assuming you've set the CNAME and network up for that functionality - you can't do that with an apex domain.
> Rails still is a great way to get a prototype demo, or minimum viable product online in days with least surprises.
Your comment seems to indicate that you started discovering new architectures like the Command Pattern but it sounds like you are also still a proponent of Rails and MVC based on your blog post. Do you have any links to resources that helped you discover other patterns or could you share what took you on your journey?
In the Rails blog post, you said:
> I have a separate post planned on "RAD web frameworks", MVC and ActiveRecord, but it is safe to say that such frameworks, amongst which Rails, have found their niche, yet are by no means a silver bullet.
Is that post you are planning to write going to delve into some of the architectures you mentioned here? That would definitely be something I would be interested in reading.
REST seems to have different definitions depending who you talk to. Some define it very strictly (as the opening of the article seems to do) and others define it very loosely (as a JSON interface with GET/POST/etc commands). For those who implement REST loosely, the suggested alternatives fit right in.