I'm the same way. I use bookmarks for places I regularly visit that I will want to have ready access to (things like work related services and what have you).
For just articles or something I'll want to read later, I've started using the Google Inbox extension to save the link as a reminder. From there I can snooze it until I have the time or motivation to actually read it.
I haven't heard of hosting companies sending anyone to a collection agency. It could happen, sure a but I think it's more likely they just cancel your account and suspend all continued hosting (which, if you believe 2fa should be impossible to circumnavigate, this is probably the ideal outcome). From there you would probably open a new account and start over.
I could see the argument either way on if this is the most optimal solution or not.
I kind of see chargeback as a potential resolution for this. If you lost access to your account and can't shut down billing via the normal route, you could still stop payments from your bank or credit card. That is the ultimate source of truth anyway, in regards to payments, so you could "prove" who you are by stopping all continuing payments to the service.
Valid point. Sadly, the system I was working on at said company was monolithic, so I don't believe that advantage was being utilized. It does open it up the potential in the future though.
I feel that this could be solved in other ways as well. Such as with microservices to wrap your database and provide endpoints for other services to consume. This is more like how we do it at my current company.
I would be the first one to admit my SQL chops are probably lacking, so perhaps this is just my own bias revealing itself. I'm not saying to _not_ use stored procedures. I'm just saying that throwing literally _all_ of the business logic in them feels a lot like a silver bullet. I've always felt that any of the more "standard" backbend languages would be a better choice for that complexity, since their expressiveness helps to describe that complexity in a way that is easier to grok for a larger number of developers.
Valid point. I should have been more clear in my original post. The issue was more that it was institutionalized to write all stored procedures in MS-SQL, rather than utilizing available CLR options (at least for the vast majority of the time). It should be noted that I'm complaining about a specific company's development method and not the practice altogether.
Absolutely. SQL is great, and having the DB just give you the correct data from the get go is convenient. But in the case where complex logic is necessary, SQL is much more difficult for correct implementation than something more expressive.
You _could_ delve into cursors or long merge statements or what have you, but in business logic specifically, the code will be read and altered numerous times by several different people. In that case, a language made specifically for expressive statements is significantly easier to deal with. That's not to say that I believe the opposite is true and that _everything_ should be done in programming space. I just think there is a better balance that can be achieved, and to default having everything in either category probably means you're not balancing correctly.
At a previous company, the tech influencers believed in the archaic "do everything in the database." While we were technically using the .Net stack, we weren't allowed to do any actual business logic in C#. Instead it had to all be done in MS-SQL procedures (or at least at much as possible with very little CLR glue).
Similarly at my current company, we had a product were the initial devs wanted to jump on the RXJS and Socket.io bandwagons. The only problem was the rest of the company was using standard REST endpoints and promises to do the same thing, so any new devs who joined that team suddenly had massive cognitive overhead they had to overcome. Any changes to the codebase we're done by people who only half understood what they were doing, and so the complexity compounded. Thankfully, I was given the chance to rewrite the whole codebase to match what our other products looked like, so now the code is much more sane to work with.
Google News for iOS has a "week in review" option. Being an aggregation of sources, it doesn't have any particular bias (except maybe to showcase only the largest stories of the week).
I just want to let you know that I've been a feeder user for maybe 3 years now, and I've really enjoyed it. The new Android beta app is pretty sweet so far.
Thanks for giving me a simple place to go after Google Reader shutdown!
Just a heads up, but that feed doesn't seem to work. It only has the channel metadata and no items, meaning your actual episodes are not listed or accessible.
An RSS feed will "get it out there on different platforms" for you. You won't have to do anything else, except submit that feed to the different aggregators (iTunes being the largest).
I'm glad SoundCloud at least seems to generate a feed, because the content sounds interesting. But if I were forced to use SoundCloud themselves, I would never actually be able to listen to your podcast. I don't want to install another app, and listening through a mobile browser sounds like a nightmare. Emails are also a no go, because this is a solved problem. There are apps and ecosystems already built around subscribing and listening to podcasts. Having yours outside of that ecosystem is a hinderance to adoption.
EDIT: And PocketCasts seems to be rejecting the SoundCloud generated RSS. So I guess I'll have to wait for a real one before I can subscribe.