px1999

It sounds to me like an operation intended to employ some skilled engineers in order to keep them away from working on Google's competitors. I don't see a lot of outreach or organisational support, but maybe it is there and my cursory glance just hasn't turned any up.

It looks like they're doing the Google equivalent of Microsoft Research - which as far as I can tell revolves around hoping something cool comes of the projects, but mostly just trying to keep their competitors from getting top talent.

People will definitely turn to piracy if it becomes too difficult/fragmented to watch the content they want to watch.

As a result, for these services to be successful, we'll probably see some renewed fighting against piracy and some work toward increasing regulation on the internet. Unfortunately, the political climate is probably pretty good in the US right now for Disney and other big content creators to start pushing for these.

I probably described it poorly, but both of those services are $/month for access to a full catalog that Netflix/Amazon manages and curates.

That's not really a marketplace, which would have individual vendors selling their own subscription bundles.

I'm suggesting that if you add eg "Miramax" to your library by paying their subscription you gain access to their back catalogue. I may only want one or two movies from them, but thanks to the bundling I have access to way more. Or Disney might divide subscriptions up by its studios or labels. I don't see them offering individual shows in a subscription, as that has limited appeal (has been done already and doesn't _really_ require its own platform)

Overall, it's not so different from cable channels, except that it's on-demand.

I think your comments about the power are largely spot on - and bigger players can make a move for their own streaming services, but smaller ones will need to band together (not necessarily via an all-in-one subscription service like Netflix, but via some sort of content platform/store/whatever).

That said, I think that the curation aspect is something that studios aren't overly concerned about - they just hate that a direct competitor is stealing their profit and making their own content. If Netflix wasn't being as aggressive (or wasn't being so damn profitable; or wasn't negotiating prices with the studios), I don't think that the content creators would be trying to run away so quickly.

I hope that open protocols win out, that's the best solution here for everyone (and would be the ideal "major marketplace" in my parent comment). That said, it may just wind up being an organisation owned by a consortium/cartel of studios (or even some other third party) that's contractually obligated to "fairness".

Long term, we'll probably wind up with a couple of major marketplaces that provide a UI that ties together content bundles that you've purchased from different distributors (who will actually serve up their catalogs).

It's a bit depressing how similar that sounds to how cable networks work. Or platform specific app stores.

Piracy shifted power towards consumers. If content creators were going to see any money, they needed to offer consumer-friendly services that were better than piracy. The orgs that did this (Steam, Spotify, Netflix) dominated their markets.

As the web becomes more controlled, regulated and tracked, this power shifts back to the hands of the content creators. If there's no (legal or illegal) alternative people will go back to paying $120/mo for tv+movies. Mass media is how people bond, relate to others and fit in; and that's worth a lot. The studios know how valuable the culture they generate is, but over the past few years have been unable to successfully control their consumers.

I think that we'll see more studios shifting over to their own platforms. We'll also probably start to see renewed anti-piracy enforcement.

Stories like there are why I won't consider Google as an infrastructure provider for our SaaS, regardless of the technicals around their services. Thank you to the original author/s for writing the post, it reinforces the warning to avoid providers like this.

In HomeAutomation's case, the amounts are relatively small (though still potentially massive to them). If their monthly infra spend for firebase started out at $10k a month and went to $1m, would only way to have issues resolved still be to hit the front page of HN?

Risk factors into our technical decisions, and trust factors into risk. Particularly when billing is concerned, needing to wait a month is ridiculous. Assuming the post is accurate, ignoring billing-related emails is inexcusable. Any organisation this incompetent is one that you should not trust with your critical infrastructure.

As you probably expected from your phrasing/question, no.

Ultimately there's often some frustration from both sides when hiring. Interviewers get a ton of under-qualified candidates and need a way to weed them out. A semi-technical conversation isn't always enough (lots of practically useless programmers can repeat dogma). Stumping someone _is_ a good way to assess their technical capabilities (you get a nice mix of analytical thinking and creativity to try to come up with a working solution even if it's not perfect).

I try to tie my technical questions to previous projects/areas of interest, with increasing difficulty/complexity, but sometimes this is difficult (particularly if the potential hire doesn't have any particular specialisations). If you start too low, the interviews go too long and you don't get a good feel for what the person can actually do. If you start too high, it comes across as demanding knowledge of obscure algorithms. I know that I've unintentionally asked questions that have come across this way, but in those cases you can't really expect a full and correct answer -- all you can expect is an appreciation of the components and some thought on how the person approaches problems.

That said, if you're being hired for your specific pre-existing knowledge, that's a different matter.

Massive retaliation is an effective deterrence strategy, and probably one of the only options that a weak group like consumers have against an oligopoly like airlines.

It's not even about punishing United, it's about showing other players that if they behave in the same way, _they_ might randomly be subjected to this sort of punishment. People are not going to stop using airlines, but we might stop using yours for just long enough to make it hurt.

They're suggesting avoiding long-standing useful functionality because some people abuse it. There's no viable simple alternative to each of these methods, which is _why_ they're in common use. They provide a reliable way to stop the user from interacting with the page until they've received a notification / provided a piece of data. onbeforeunload provides a way for a page to have the user ensure that data is saved before they navigate away. More importantly, they're one-liners.

No proposed alternative achieves these goals, and they definitely don't achieve them as simply or as elegantly. I understand switching alerts from app- to tab-modal, but when did the web become such a clusterfk of complexity? Not every page needs (or should need) to bring in their own dialog library, to save changes incrementally, or be concerned about users not accepting notifications before being able to provide important information to them.

This policy makes no sense because it recommends using ~10 lines of code which probably won't work for all your users in place of the 1 that definitely will. Telling people to avoid alert etc (by threatening to break the functionality in the future) just avoids actually solving the problem (which they could do) by taking away an incredibly useful and important piece of functionality.

If you have different stuff available, you might choose to only cache/microoptimise the pages served to 98% of your userbase, which would lead to this type of effect with no malicious intent.

It was a reasonable email asking a reasonable question - and companies need to be called out on this sort of bullshit or it's not going to change. I hate renegotiating my own work conditions/package, but it's the conversation with the single greatest impact on my quality of life.

Neither companies nor candidates should be afraid of discussing salary. It can be awkward, but it's also really really important. As an employee, you trade your time and skillset for remuneration. It shows an incredibly exploitative attitude towards employees to respond in this way to what is effectively a simple question.

"Culture fit" has little, if anything to do with money. More likely, they cancelled her interview because they knew that if they wrote down their intended pay/conditions she'd cancel first. If a company's scared to talk $$ with you, it's the biggest red flag there is. Only sketchy companies like multilevel marketing (and apparently SkipTheDishes) try to pull these sorts of shenanigans.

But isn't that covered in the "willing to pay more for the service" bucket? I find tipping awkward to the point of being willing to pay more for alternatives that bundle an otherwise expected tip into the service's initial pricing.

Our migrations have unique datetime stamps. Stamps and migration names go into a table.

We do have a hash of all of the contents of the table, but the schema "version" is just the list of migrations that have been run. We run many different instances of our applications on several different "versions" and from time to time pull individual migrations back into earlier releases for hotfixes etc. The overall version is the instance, environment, and this hash.

Practically speaking, when we're handling the files ourselves though, it's instance, environment and backup date.

There are edge cases and it's not perfect (around ordering mostly), but it's incredibly rare for us to run into issues with this schema / data migration approach. We've found that even with a bunch of environments and a couple thousand migrations, data versioning isn't that serious a problem for us.

Like print media, cinemas and taxi companies it seems like the record labels think they're special and somehow immune to the march of progress.

If Hollywood bled Netflix dry, people would still stream/watch movies at home, but none of that money would go to the content creators. Same with game studios and steam.

I had to get historical bills from a terrible cellphone provider in Canada (Wind mobile, now Freedom mobile, now owned by Shaw communications) a little while back.

Their customer support process was useless (they'll send historical bills to third party organisations for stuff like background checks, but they're afraid that consumers will use the bills to prove that they're misapplying charges). Thinking I'd just just have to navigate their customer service departments, I started recording the calls (legal in my jurisdiction).

After several conversations with friendly but incredibly unhelpful CSRs (thanks to corporate policy), I started to look at other ways that I could get my info. I issued a formal request for all of my personal data under Canadian federal and provincial privacy laws (PIPEDA). Their legal department claimed that I issued the request incorrectly ("by email"), so I responded by citing the relevant clauses (never mind that there was a paper version that I sent at the same time). Then they made a couple of other similar claims (that PIPEDA doesn't apply to them, my reply was that telcos are specifically named).

Seeing that they were drawing things out, I started to respond with expansions to my request (asking for potentially damaging things like a list of who they intentionally or unintentionally disclosed my personal information to), and threatening to report the issue to the Privacy Commissioner of Canada.

Some combination here seemed to do the trick, someone from their corporate security department reached out to me by email, and had the authority and power to give me my data. They ended up charging me an exorbitant amount for the original request's export (and never actually fully complied with my request for disclosures), but I ended up getting what I wanted.

I now take the opportunity to share my experience whenever possible, and figure that these types of stories being out there (along with the potential customers they lose) will provide the financial incentive for them to change their processes long-term.

TL;DR: CS process first, then recording, then escalating the request slowly using privacy laws to your advantage, then expanding on the request to give them time pressure (that eventually you'll request data they legally have to provide but practically can't), then providing pressure to respond by threatening to take it to a federal regulatory body.

I understand the idea of supporting ranges of libraries from a development perspective, but when you're running something in production, is "use any of these configurations" ever desirable?

Presumably there's a reason that you'd _want_ them to use 1.12.4 over 1.0.0 (or you'd want to at least check that they didn't break anything that you rely on in 1.13 when that comes out)?

I've worked in government (thankfully not US federal) and when departments review their specific operations/policies, they rarely grind to a halt, it's business as usual while things get evaluated/decided and policies built behind the scenes.

The only reason that you'd do something this public is to make it a spectacle and give people the impression that you're doing important busy work at all levels; or to try to assert/show dominance.

That's pretty likely. If people don't know how to use collaborative tools, they get frustrated and give up, so a successful product can't alienate its userbase. Skype teams is familiar enough for the email generation to use, but still improves slightly on communication.

There's a huge market out there that's scared of Slack etc, but will love Skype Teams.

I understand pretty much everything in here (and have manually disabled most of the things this disables in the past), but the script serves as a useful checklist and shortcut. That's it's value.

We're slowly rolling it out to individual product teams in our small (~50 people) ms-based dev organisation. Things are going reasonably well.

We'd have picked slack over teams in a minute, though it has compliance issues making it unusable for us - slack is just more polished and has a lot more that you can get out of the box / with plugins. That said, teams still has some great features for us, so we'll stick with it for at least 2017. We've tried a few similar options before (primarily group chat) but they all had gaps / issues that resulted in them being not as useful/used as we'd have liked.

There are still a couple of massive gaps in teams for us:

* No on-premise TFS integration

* It seems that Office 365 is all or nothing - we can't tie the o365 account to our primary email address without it messing up external email routing.

If you're trying to replace a culture of email + some IM + files tucked away in some document management system that don't get updated as frequently as they should, it's a good start. If you've already got good communication then it's less valuable.

If the business was burning down because of code quality issues, I'd definitely navigate through whatever process the vendor throws my way to get access to their software. Same if I woke up one day and decided "we need to throw away our static analysis and find a replacement". Same if the email exchange was only 10 minutes with 1 email going each way (ha!)

But none of those are the case, we have no serious problems with our existing process, nor any real incentive to actually try out alternative static analysis setups. What drives us to find something better is curiosity. Every month or two, I'll see something related to our process (not specifically code quality), look into it along with another alternative or two, and try to figure out quickly if it's worth dedicating time to look at it in depth. I'm making that initial decision based on 10 minutes of skimming the vendor's website. I don't want to sink a week of peoples' time into actually properly setting something up to find out that our org will be charged higher fees than we expect (in much the same way that I don't want to drag a bunch of people into a meeting room for a couple of hours for a product demo until we've independently verified that the product can actually work for us; or set something up and have it bite us a couple of years down the road when it's become entrenched in our processes).

Realistically, I have a fair idea of how much the software will likely cost. From what I've seen (assuming I'm correct), the price (low 5 figures) wouldn't be a dealbreaker (though it would definitely have to bring some advantages when compared to what we've got now in order to sell it to management). But, after a number of our negative b2b experiences w/ opaque pricing (eg price scheme changes at the end of the contract term, or being billed higher than others because we were [at that time] reliant on the product) we know that there's a cost involved in this. It's something that is worth some dollar amount for us to avoid.

I want a binding quote that I know is going to scale linearly with our organisation; a dollar figure that's not going to change sharply in 3,4,5 years; no significant meddling by salespeople -- all in addition to a solid product. Published and available-to-anyone prices help ensure that.

I just want to note that I'm not against OOO in any way, or even saying anything bad about their software, but opaque pricing on products just doesn't make sense for us (much in the same way as products-as-subscription don't make sense for us, even though we normally keep up to date with upgrades/support).

A negotiable pricing structure hides the true value of the product behind needless bureaucracy and interaction. Not having a sticker price (even a "no one actually pays this much" sticker price, like MSFT's) makes fair comparisons impossible without getting into a high-touch sales cycle.

For them, it's almost surely meant lost sales.

In my org, I'm the one who would be making the decision to trial products like this. For me, it's meant that they haven't gotten a serious look-in. We don't have particular code quality issues so I'm not shopping around between static analysis tools, but I am always open to improving our processes. The bar that they need to reach in order for me to spend time seriously evaluating their product is much higher. If the software was eg 10k/yr it's a very different matter to it being 100k.

I'm curious about the product and the benefits that it brings over our existing static analysis setup (SonarQube + Resharper + Microsoft Code Analysis), and if I had any idea what I'd be getting into I'd probably have set up an instance somewhere, but that's time that I'm not prepared to spend without at least some idea of whether it could even result in us making a buy.

Neither my time, nor that of anyone else in my org is free. I'm not going to evaluate a product, make a decision and then ask how much to see if the vendor has reasonable prices. Even used car lots list prices on their cars so you can judge a "worst case" cost and filter out the absolutely ridiculous ones.

SonarQube and Resharper have some similar coverage. I'd recommend both (at the same time or individually).

One of the (IMO many) problems with using coloured coins for property ownership is that the real world is necessarily messy.

Disputes happen frequently, houses are seized, not bought outight, people die and ownership needs to be switched, any other number of scenarios might occur... on the flip side, what happens when a wallet containing the house is compromised? When you start to go down this line of thought, delegation to some authority begins to make sense...

To be honest, I found that every one of the interactions in the story has a similar set of limitations or problems. The whole thing reads as though it's been written by someone who's never actually been out in the world and interacted with people. Every one of the points can be pretty much countered with the same "OK, but what if something goes wrong with the transaction, or if someone wants to act in bad faith?"

To me this is the biggest fundamental flaw with unregulated cryptocurrencies - there are already a significant number of bad actors who are stealing coins but no "fix" (indeed this is by design) - other than calling the victims idiots and suggesting they act differently next time.

Unfortunately in the author's world, you're broke, homeless, and in every other way possible, SOL.

I'm curious to see if many of those that did invest in non-exchange startups have seen much return to date. A lot of the ideas seem (at least to "regular" folks) to be a bit... strange...

In the post they mentioned Dunvegan Space Systems, which as far as I can tell is trying to sell computing power where the server is physically located in space. They can broadcast radio, and in theory the signal should be harder to shut down, but that's the sole useful purpose - broadcasting something that someone may want to shut down - a problem for which we already have terrestrial solutions (eg pirate bay).

The blockchain has a lot of promise, but it seems like much of that is theoretical and far-future.

It's not surprising that VCs are waiting for a bit of a return (or indication that their capital's going to result in return at some point) first.

I guess I'm a "a pussy, 9-year old boy or afraid of little bit “strong” writing.", because as soon as I saw that sentence I lost all interest in finishing the post (though it was pretty linkbaitey in the bit I did read so I had marginal interest in the first place).

Shit like that is why we have gender problems in the industry.

The theory is that a DSL should be better than whatever generalised programming language you're using. SQL is a good example - ORMs tend to fuck up querying databases (ie pulling back unnecessary data) almost as much as they fix. SQL, a language designed for querying relational data, is (unsurprisingly) pretty good at doing what you need efficiently.

In practice, a lot of frameworks are made by people (who are just people, and don't 100% know what they're doing at the outset). I'd say that if you're spending too much time in configuration, you're not using the right frameworks.

No, in a few years those frameworks will be forgotten. From the terms that you've used, it sounds as though you're coming from the Java world, which has an inexplicable love of config files - if that's the case, it might be a bit longer than a few years, but they'll eventually figure out that config files aren't a good representation for options.

Though the layers of magic and abstraction will continue to increase and grow, at least until simple LOB usecases can be achieved in a couple of lines at most.

Vancouver's main problem with attracting top-level talent is pay. I live in Vancouver but don't really work much here anymore (mostly remote now) because of pay. The article focusses on the high cost of housing, though in practice renting isn't too bad (particularly if you're happy living in a sardine can or someone's basement).

I have had serious job offers here at less than 1/3 of my usual rate. I've been told that what I'm looking for (what I'm already getting for remote work) is director or C-level. "There's much more to consider than compensation" is a reasonably common excuse from recruiters, but the fact of the matter is that if you are trying to hire competent senior engineers for $30/hr, of course you're going to lose out to places that are paying amounts that are above a living wage.

Vancouver's okay, for sure, but being the self-proclaimed "lifestyle capital of the world" only carries weight if you get a good work-life balance, and can afford to do the things that you want to do.