Highly recommend wrapping the code to drop into the console in a immediately-invoked function expression; as it stands, it doesn't work in macOS Safari without an IIFE because top-level await is not supported in any version of Safari yet https://caniuse.com/wf-top-level-await.
In a way I agree with you; but practically 100% of iOS/iPad users are forced to use Safari. Plus, it's nice to have a browser engine that's not Chromium.
Google Reader: I will forever be salty about how Google killed something that likely required very little maintenance in the long run. It could have stayed exactly the same for a decade and I wouldn't have cared because I use an RSS reader exactly the same way I do that I did back in 2015.
Yes. That was the single worst business decision in Google history, as somebody correctly noted. It burned an enormous amount of goodwill for no gain whatsoever.
Killing Google Reader affected a relatively small number of users, but these users disporportionately happened to be founders, CTOs, VPs of engineering, social media luminaries, and people who eventually became founders, CTOs, etc. They had been painfully taught to not trust Google, and, since that time, they didn't. And still don't.
Just think of the data mining they could have had there.
They had a core set of ultra-connected users who touched key aspects of the entire tech industry. The knowledge graph you could have built out of what those people read and shared…
They could have just kept the entire service running with, what, 2 software engineers? Such a waste.
This would require the decision-maker to think and act at the scale and in interests of the entire company. Not at the scale of a promo packet for next perf: "saved several millions in operation costs by shutting down a low-impact, unprofitable service."
There is some truth in this. I fit into a few of these buckets and I don’t think I could ever recommend their enterprise stuff after having my favourite consumer products pulled.
Yes, Google killing Reader was probably the first time they killed a popular product and what started the idea that any Google product could be killed at any time.
I never understood why noone built a Copycat (like "bgr" -> "better google reader :-D)
There would have been a clear change to fill this vacuum?
The thing is: I guess they didnt see a good way to monetize it (according to their "metrics"), while the product itself had somehow relative high OpEx and being somehow a niche thingy.
Killing Reader didn't just kill Reader. It killed the expectation of RSS to be a valid default consumption format of the internet. These days, if you use RSS, it's either relying on some legacy hidden feed feature that hasn't been shuttered yet (lots of Rails and WordPress sites that are like this) or you're explicitly adding RSS to your site as a statement.
Picking up the pieces after Reader was impossible because the entire RSS ecosystem imploded with it. Almost every single news site decided that with killing Reader, they wouldn't bother maintaining their RSS feeds, leaving them basically all "legacy" until they irrevocably break one day and then get shut down for not wanting to get maintained.
> I never understood why noone built a Copycat (like "bgr" -> "better google reader :-D)
like theoldreader and Inoreader, which explicitly copied the columnar interfaces, non-RSS bookmarklet content saving, item favoriting, friend-of-a-friend commenting and quasi-blog social sharing features, and mobile app sync options via APIs? Or NewsBlur, which did all of that _and also_ added user-configurable algorithmic filtering? Or Feedly, which copied Reader's UX but without the social features? or Tiny Tiny RSS and FreshRSS, which copied Reader's UX as self-hosted software?
theoldreader remains the most straightforward hosted ripoff of Google Reader, right down to look and feel, and hasn't changed much in more than a decade. Tiny Tiny is very similar, and similarly unchanging. FreshRSS implemented some non-RSS following features. So did NewsBlur, but as it always has, it still struggles with feed parsing and UI performance.
Inoreader and Feedly both pivoted toward business users and productivity to stay afloat, with the former's ditching of social features leading to another exodus of people who'd switched to it after Google Reader folded.
I've been using Insomnia since the beginning and I really appreciate how receptive gschier is to feedback and how the support side of things are handled.
I'd love to hear what you're planning on working on next and how you plan to monetize (if you're going to) :)
Insomnia is still in the early stages, so talking to users is something I spend a lot of time and effort on. It's the only way to make a good product :)
My current plan for monetization is to add multi-device sync (almost ready for beta) then team collaboration features shortly after. There are also some advanced features left to implement like OAuth support, scripting (settings environment variables from response data), and a few others.
Joyent used to have the license on the top of virtually EVERY file in the repo for node. Someone removed all but one (6430 deletions) https://github.com/iojs/io.js/pull/311/files
I remember this was a common thing in free/open source projects some time ago[0].
At some point people started to believe that this was not necessary.
I am not sure of the legal implications, of either choice, just wanted to point out that the joyent people probably were not crazy :)
In every Berne Convention signatory country (which is pretty much any country that will matter to most people), published works are required by the convention to be copyrighted by default, whether or not there is a copyright notice, and the lack of a license means you have to assume you have none unless something else tells you differently. That basically makes embedding the license text pointless.
It certainly was common, though, which is/was probably because the US did not join until 1989, and prior to that US copyright law required a mandatory copyright notice, so a lot of people will have at least worked on projects old enough for this policy to have mattered.
Really? I've been putting the license in every file in my project because it's JavaScript and people drive by a website, see "foo.js" and have no idea where it came from or what license it's under. With the license in the file it's immediately clear.
Usually you'd concatenate and minify deployed JavaScript anyway. Sometimes you get a license in that, sometimes you don't. I don't think that many people really copy that much JavaScript from live sites these days...
> That basically makes embedding the license text pointless.
Embedding the license makes sense because otherwise others have to assume they don't have the right to use. The copyright notice on the other hand is pointless.
"The copyright and license notice is already in the LICENSE file. There is no justifiable reason to also require that it be included in every file, since the individual files are not individually distributed except as part of the entire package."
I think they meant 'it' like FB connect...,' or at least I hope so for the sake of their competency. I agree that the whole post was particularly poorly written.
Unless you have specific reasoning to get the i7+8GB of ram version, I have an i5+4GB and I absolutely love it. No gripes at all about it... well, maybe if Apple would replace the damn LCD screen that has very small bubbles between the LCD and the screen, I'd have 0 issues with it.
