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.
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.
Yes, the older Chromebooks have some terribly inconsistent trackpad experiences. There is an older Acer model (circa 2017) that had one of the worst I've ever seen... way too sensitive even with the settings adjusted, palm detection didn't seem to work at all, and after just a month or two of normal use trackpads started double-activating (we had a whole fleet of these!)
Newer models are better. I'm sure software updates have fixed a lot of the palm detection issues. But similar situation with Windows laptops, PC notebook manufacturers are 20 years behind Apple on trackpads.
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.
Welcome to 1994, when I started doing that on IBM X Windows terminals or Hercules green phosphore terminals, depending on the availability on the compute center.
Kudos for that. There must be some feeling of accomplishment turning in work done on a toy computer, designed for eight year old kids and with no discernible CPU.
I have slipped into working almost exclusively on a Chromebook for a pet project that is going rather well. I have this realisation that I have actually completed something without getting off the sofa.
The 'dim' screen is not a problem, the keyboard is actually a complete joy compared to my posh computer. I did put an IDE (phpStorm) on it (paid for) but ended up getting so much done just in terminal windows. It has enough '.ssh/' to make it great for that.
Maybe like 'intel inside' there needs to be a 'Built on a Chromebook' quality standard out there.
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.
I really liked Blink, paid for it, and then was forced to buy it again when they updated it, or get advertisements to upgrade. Really clumsy and annoying since the earlier version did everything I needed.
I went back to just using Prompt app, with tmux on remote servers.
That's cool. Didn't know Safari had dev tools on ipad. I did try blink. I wanted to get vscode running via SSH plugin from a vps but didn't have patience to figure it out. Then I realised I should just use my laptop.
I've had that "I should just use my laptop" moment many, many times. There are lots of things the iPad is objectively worse at than my very nice X1 Carbon running Arch. And yet I keep coming back to my iPad pro. I can't put my finger on what it is but I think it's some combination of:
1. Gorgeous high resolution, high refresh rate, generally pretty screen.
2. Long battery life.
3. Instant wake.
4. Ruggedness. Even with solid-state everything I'm always a little wary of chucking my laptop into the passenger seat of a car, taking it near sand or dust, etc. There's fan vents and hinges and... stuff. The iPad Pro in a Logitech Folio case has all the corners protected from drops, no airflow, few holes. I just don't worry about it.
5. Pencil. The handwritten notes experience has gotten really good. Being able to flick into that mode any time is nice.
You also have various dev tools as apps. What’s also nice is to use a VNC to get the power of my workstation when I am away. Another big selling point is the long battery life.
The vnc thing rocks. I've installed uis on cheap remote dedicated servers. I would do my satellite imagery exploratory work via VNC that way since up about 2018 internet was a big problem here. In server could download 10gb imagery at super speeds and play around qgis. Rented server generally faster than my laptop too and somehow only $49/month. Tight vnc is great at holding connection and low bandwidth.
I wonder though on vnc via ipad, how do you use mouse? I imagine touch support would be an issue in many desktop applications.
I really like the Logitech Slim Folio case with a separate small bluetooth mouse for when I need it. 98% of the time the trackpad would just be taking up space that I'd rather fill with keyboard. The times I do need a mouse, I probably want a proper mouse rather than a trackpad.
The different remote desktop apps (VNC, Nomachine, etc) have ways to translate touch events into mouse pointer movements/clicks. Not what you'd want to use for a serious CAD session, but fine for little things here and there to save pulling out the mouse.
Nice thats what i do too! I use a combination of code-server running on a gcloud instance and chrome remote desktop to do my work on a lenovo duet chromebook!
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.
The Chromebook in the post has two 1.1GHz Atom cores^, so a $5 VPS even if it is only 1 hardware thread on a modern-ish server processor is probably significantly faster.
^It can boost higher, but probably not for long with a 6W TDP and no active cooling
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 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.
Okay, but what if the server burns like it happened to OVH, or your account gets suspended for no reason and they shred all your data, or you simply fat-finger an rm command? How do you (the grandparent) handle that?
> I do all my work on an under $200 Chromebook. I have a VPS where I do all the actual work.
Arguably you do all your work through (not on) a $200 Chromebook then ;)
Somehow the Chromebook acts as a glorified keyboard+display tied via a very long cable to a several thousands dollar machine that you rent!
(I get that you can run Linux, and that this machine handles browsing as well, and I'm not judging the setup, it just feels like the "$200 worth of hardware is all it takes to do work on" subtext feels cognitively dissonant to me)
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.
So you're spending ~$80 per year for DO plus $180 for the hardware. Over 5 years that's $580 (if that Chromebook really makes it to 5 years and DO's prices remain unchanged). This is about half of what you'd have to spend on a local dev setup with similar capabilities.
Not bad, but I think whether or not it makes sense depends entirely on the productivity difference between the two setups.
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.
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.
That doesn't make any sense at all - the CNAME just points to somewhere else with an A (and AAAA in $current_year) record. It adds another point you can switch around but doesn't let you switch it any quicker. How quickly you can effectively change what the domain points to is determined by the TTL of the record (withing limits) which can be lowered for any record.
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.
> 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.
I'd suggest going through all Uncle Bob Martin[1]s talks on clean code.
He has a great article (2014), old, on why you may not want to build that framework at all[2] too:
> Using a framework requires a significant commitment. By accepting the framework into your code, you surrender your control over the details that the framework manages. [...]
> And yet despite the huge commitment you’ve made to the framework, the framework has made no reciprocal commitment to you at all. That framework is free to evolve in any direction that pleases its author.
Another great source are the books, and/or youtube channel by Dave Farley[3]
What set me on a journey is -decades ago- the pain I, as a developer felt when developing web-applications for my clients. But worse: the pain they felt for getting delivered crap. "Why am I delivering crap" was the question that set me to research frameworks, languages, design patterns and architecture. Drupal, Rails, Django, ASP: I've worked with it, and delivered crap with it.
In general, I found that a framework matters. e.g. the simple act of reading ActiveRecord Critisism on wikipedia[4] got me thingking:
> also due to the strong coupling of database interaction and application logic,
This was true for project D, G and Y! This was why we failed to iterate at any speed at all. Because I can relate it immediate to Real And Actual Problems, Failed Projects, Slipped Deadlines, Burned out colleagues, and so on, all of wich I encountered during my career. Not saying all those problems were caused by ActiveRecord or Rails! But that they were caused by the choice for the wrong framework. Or the choice for a framework at all.
It led me to DDD[5], which then is the gateway into all sorts of Enterprise Patterns. I dislike that name, because the connotation is all wrong. Especially the subtitle of the canonical book on DDD struck a note:
> Tackling Complexity in the Heart of Software
This! This is why I'm delivering crap: I fail to tackle the complexity that inherit in any domain. In e.g. Rails, I would just spread it all over the place, fighting against ActiveRecord and Rails, yet still failing to isolate, modularize and capture that domain.
So I no longer use Rails, nor any framework in my startup. I occasionally do some freelance gigs, often Rails. And the more I learned how to Tackle Complexity in the Heart of Software through choices and tradeoffs, the more I see why a project in Rails that I'm flewn in to salvage, is doomed. It's the choice for Rails. Not lacking of services, not "Fat Models", not "missing tests" nor missing of any sort of "rigorous refactoring" Its Rails! Rails is just unfit for this domain, this problem, this customer.
Yet Rails shines for others: I restate: It's brilliant for simple CRUD. But anything you expect to have any sort of "Complexity in the heart" is probably unfit.
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.