sha90

Wait, that can't be right, it would be ludicrous. Once a game passes the threshold it pays per-install permanently?

Yes and no. You need to meet _both_ thresholds, cumulative (lifetime) installs _and_ yearly(!) revenue. I (!)'d the yearly part there, because you still need to be pulling in a yearly $1M of revenue (I'm assuming Unity Pro here cause the math is simpler) after your 1M of installs.

So while there are some edge cases here that are legitimately ludicrous, it's not the case that you're on the hook for the game in perpetuity, because if your game falls off a cliff and you make $500k in revenue next year, you owe nothing in runtime fees. In other words, you're not incentivized to take it off the market after 1M installs unless the runtime fees made it so you started losing money on the game after your $1M of revenue-- there are some examples where this is possible but none of them are very realistic.

The problem Unity have created is if something can be made with Unity it will get crowded out with clones in five minutes.

This really has nothing to do with Unity. Flappy Bird could have been built on any platform and you would still have a million clones of it. Because it takes a day to make it. It's just as easy to clone that game in Unreal Engine, fwiw.

Unity didn't create the concept of the quickly built game, nor is Unity responsible for society incentivizing this type of game dev. If anything, the new runtime fees will disincentivize this type of game, so maybe that's a good thing?

How big is your team? How do you code review? How do you unit test? How are you maintaining 3 year old blueprints?

This will work just fine for small indie games and teams where the code is thrown out after a year, but there's no scaling this. I've worked with enough 10 year old Max/MSP patches to know that you will have an unmaintainable mess of wires that is as good as garbage after a while.

Larger teams typically use Blueprints to prototype but then rewrite in C++. This is a perfectly fine use case, but ultimately you still need it "written down" for the maintainability.

tl;dr Blueprints are a tool in the process to writing C++, they aren't a replacement.

This isn't really a solid argument since stockholder investment isn't even "money"; it's collateral in the form of market valuation against which Unity borrows. The actual "money" (dollars in a bank account) comes from lenders who look at a bunch of factors and make determinations about how much $$$ to give. That money isn't free, but it's got very little to do with "the shareholders" in general.

Yes, but it has many known limitations and isn't nearly as reliable as a runtime that has a full GC and virtualization optionality, which you really need in order to fully track what state can be evicted and what needs to stay.

Keep in mind that in addition to the "learning curve" arguments, there is also the functional developer ergonomics of things like live reload (where you can maintain memory state) that are simply not possible to do with C++ without heavy limitations or customized tooling.

Being able to fix a bug without resetting memory state is a huge ergonomic advantage in game development where generating the right memory state can be incredibly complex and depend on a ton of very specific and hard-to-reproduce factors. Not to mention recompiling and restarting a game can be incredibly slow.

Citation needed? Raw speed is likely similar; the cost overhead comes from GC cycles and the general approach to managing memory primarily in the heap vs stack, although C# can stackalloc if you're really diligent. Note that this is the same problem that blazing fast alternatives like Go have at competing with C/C++. These languages are mostly equivalent to C/C++ in speed, but lose the benchmark shootouts because of GC.

But you need to consider that so have hosting costs-- proportionately too. Hosting data was incredibly expensive 10 years ago. If the math was working then, it should at least be pretty close to working now.

Fastmail nets around $50/year (if you pay annually) for mail + your own domain, and if you don't need the domain, it's less.

Another $50/year really isn't that big of a stretch for some people, but I can see how saving up to 70% on email would be a pretty easy choice for those who don't really care that much about email and might even use gmail if it weren't for needing a custom domain.

Can you explain what is worse about link tracking? If you're explicitly making a request to a remote service, how would you expect it to not be tracked?

Getting good signal-to-noise ratio from ANY interview, forget the big cos, is really difficult. I've seen great programmers passed over because they were _not_ given a chance to whiteboard and show their technical skill. At the end of the day, there is a bit of randomness to the process of sizing anyone up in an hour, and people will make bad calls.

That said, I'm skeptical about your particular story. As a process rule, AWS doesn't provide interview feedback, so I'm pretty sure you don't _actually_ know why you were rejected, you can only guess. Perhaps if you were rejected in phone screen(s) it can be obvious, but if you made it to an on-site, I can guarantee (based on experience being in the room during hiring decisions at AWS) that they don't almost someone because of one bad whiteboarding result; there are multiple people collecting and reporting on results and only one person, the bar raiser, has veto power, and I've never seen it used for something as banal as not writing perfect code.

I also don't know what happened in your interview, but consider it's also possible that you completely bombed it: failed to ask questions, failed to communicate properly, or made more mistakes than you even realize.

It's certainly great that you went on to do great things, but maybe at the time you interviewed you weren't yet doing those great things...

It wasn't obvious at the time, but I think in retrospect the case can be made that Apple's ability to innovate effectively (both in terms of time and quality) died with Jobs.

Oh stop. Apple's effectiveness was entirely a product of its time. You had designers building the Zune and calling it competitive but really there was no competition for the products Apple was building for a market that was screaming for a better balance of form vs function.

This picture of Apple's innovation includes no part of OSX, which was always an OS that was technically capable but superbly messy and extremely behind on the times.

Innovate effectively? For a long time of Jobs' tenure, Cocoa was being supported on BOTH Objective-C and Java, and when they ripped it out, they actually chose Objective-C, not Java, as their platform of choice (in retrospect: wow), only to have to build yet another platform (Swift) just a few years later (Swift of course, based off of MacRuby, which they initially tried to build Cocoa on top of internally, so I hear).

Innovate maybe, but effectively no. There is a whole host of broken, abandoned, and outright bad decisionmaking in the OS layer at Apple. Apple's success has everything to do with their success with industrial design, UX design & marketing, and just a bit of being at the right place at the right time.

IMO this interpretation fits the timeline much more cleanly: Apple was churning out the same iPhones and Macbooks long before Jobs left, just as they had been before with the iPod. The butterfly switches, the thin above all else, that's all part of Apple's MO dating back years. Lack of FM radio on the iPods, lack of IR sensors on their early phones, removal of removable batteries, headphone jacks, USB-A, etc, is all part of the DNA. A $5000 screen is not surprising to anyone who saw the Powermacs of the last generation. Butterfly switches look an awful lot like bendy iPhones, which look an awful lot like DOA Powerbooks.

I'm really not sure what part of this is new post-Jobs, but I have a good feeling this is a great case study of confirmation bias. If you believe Jobs was a one-of-a-kind irreplaceable visionary who was single handedly responsible for Apple's success, then you have no choice but to interpret any action Apple makes post-visionary as a failure, otherwise you were wrong about the one-of-a-kind irreplaceable visionary.

And it would be a pretty big blow to most to be wrong about Steve Jobs.

The other interpretation, of course, is that Jobs was not a magical visionary, just a smart guy who made a couple of right decisions, got lucky on lots of others, while still getting it wrong on plenty of occasionss (Macintosh TV cough Apple TV cough Apple TV2), just like most fallible humans.

This isn't an economic issue, it's an efficiency issue.

There are 3 competing ideas: Fast, cheap, quick. You get to pick 2. We're picking cheap and quick because "fast" comes for free on a longer-term timeline. You can argue with whether or not this is the right choice, but this is the choice society is making, and IMO it would work better than taking significantly more time to build something that is only 10% faster. It's more efficient to let hardware manufacturers solve the fast problem when the differences are on the order of 5-10% a year but the time-to-release problem is on the order of 50-100% differences in development times.

This is extremely hyperbolic, and I'm sure you know this. Here's how you set a variable in React:

const foo = 1;

What you're doing in your complicated sample is not _just_ setting a variable, you're also exposing it to a KVO subscription system that you could never represent succinctly in ASM.

What's sad is how programmers communicate programming concepts right now, with quick digs and hot takes and zero actual critical thought to what is being compared. I'm disappointed that you're spreading FUD in your internal talks.

Article tl;dr: "I believe that apples are more efficient than oranges after all."

I just want to point out that the idea that "modern buildings use just enough material to fulfill their function and stay safe under the given conditions" is fundamentally at odds with the author's subsequent thesis.

Modern buildings don't use "just enough material", because "just enough material" would be _just_ concrete everywhere; it would have been "just wood" 200 years ago, but that's not good enough now. This is exactly the problem: it's not software that is unnecessarily bloated, it's software that has evolved to solve higher order problems, ones that are not simply based in how fast a computer can count to 10. Similarly, the definition of "fulfill their function" in the context of buildings have changed too. That definition changes all the time, even in building codes.

In the modern-building hierarchy of needs, we are way passed the "stay safe" level. We still optimize for safety, sure, but that hardly accounts for your spray foam insulation, HVACs, builtin wireless units, complex built-in cabinetry, complex appliances, and more. Simple things like "electricity" are now part of the definition of fulfilling building function. Go find a 200 year old building and you will find a building that simply does not fulfill today's functions. Even safety standards have and continue to change all the time. You can look at historical building codes and see evolving fire safety (asbestos? NO ASBESTOS!), seismic safety, and more.

This is the point. To say that Windows 95 is 30MB discounts the years of improved process space isolation, memory protection, Spectre mitigation, that, if missing, would cause enormous public backlash about why Microsoft doesn't care about security. Windows 10 is 100x larger because WE asked for it to be. WE wanted WiFi, VPN, IPv6 switchover and tunneling all added to our network stack. WE wanted GPU enhanced UI threads. WE want haptic feedback and touchscreens and predictive text and predictive multi-touch pixel accuracy for our touchscreen laptops. This extra complexity exists because our standards changed. A text editor isn't just something that renders ASCII anymore-- heck, it's not even just for rendering characters. My "text editor" is a full web browser because I _need_ that for development these days.

Extra complexity is a feature not a bug. We built computers specifically to do this stuff, not in spite of it. The abstractions and complexities aren't getting in our way, they are literally the things we are building. Does performance suffer? Maybe, but that's because we are explicitly paying into functionality. If you wanted a fast text editor, obviously a black-and-white screen that only renders 256 characters will be faster than VS Code, go ahead and use that software, but you're not getting the other things you probably want. Your very next complaint will undoubtedly be "how do easily I diff my Git branches?" -- and this is how software becomes more complex.

Welcome to progress.

Development on the MS side was just fine in the 90s for many people. If you were an open source developer in the 90s, maybe not, but then again, OSS in the 90s was pretty broken for _everyone_.

MS is contributing to Electron. They benefit, but so does the wider community. This is generally how OSS works.

They mean that the signing bonus is divided into two yearly payouts instead of one. It's a single bonus.

I personally don't see what's wrong with a N/2N/3N... vesting schedule for post-IPO companies. You're buying in long term, that's the deal. Is it sided to favor employee retention for the employer? Sure. The overall comp at AMZN is pretty competitive though. That's the deal.

It makes more sense for a fiscally stable company like Amazon, which actually sees reliable stock growth and a real business model as compared to snap with neither of those things-- but that's not a criticism of the vesting schedule, it's a criticism of snap's true value. That's the thing that would keep me from a company like that, not the length of my RSU vesting periods.

Source: ex AMZN employee

I stop counting the 5+ years old laptops that have to be upgraded,

5+ years ago is that LOOOOOONG time that OP was talking about. It's also unfair to compare technical capabilities of old hardware for many reasons. I think the point was that, new hardware, _while its new_, is becoming more and more capable. Any new laptop today, even budget ones, can handle YouTube videos in HD. The problem is that HD today won't be the same HD that exists in 5 years (i.e., 4k), and it's sensible that a budget laptop today will struggle with the 8k technology that comes out 5 years from now. This is an old problem (pun intended) and should not be surprising.

Because personally, I keep having performance problems on all laptops I have.

Selection bias. Programmers who compile code, run VMs or containers, and process tons of data, are not the average consumer laptop use case and have much stricter requirements. Many people are sitting in Facebook, YouTube, Gmail, or Google Docs for most of their day-- and likely inside of Chrome.

Where are the "Chrome is Flash for the desktop" posts?

The idea that Electron is any different of a user experience for the vast majority of users seems skewed to developer usage, to me.

It's not as bad as previous poster states, but it's not quite as simple as you make it seem either. A green card holder forfeits their residency if they leave the US for "more than 6 months", or if border patrol people feel like they've abandoned their residency for any reason. This doesn't affect most employees, but if you're a consultant working on-site in another country for extended periods, or simply travel often, you have to do way more work to get everything cleared. And even then, there's no guarantee you won't run into problems.

Git repos change way more often than domain or company names do. Moving from code.google.com to github.com, moving a project from a user to an org, transferring across orgs, renaming an org. All of these things have happened to me in a single Golang project. Ironically, the code.google.com -> github move was actually Golang stdlib code itself.

I am far from being a Go expert but you can see this has been written by Java developers.

Hi! As of writing, I am currently the top code contributor to the AWS SDK for Go (NB: I've since moved out of Amazon). I've never written a day of professional Java in my life, but thank you for the compliment! Would you mind endorsing me for Java on my LinkedIn page? This will go far to getting me that enterprise Java job I never once dreamed of having!

But seriously, it's worth noting that the SDK was originally created by Stripe, and most of what you're likely referring to (struct inputs) worked in the exact same way when it was Stripe's codebase. As far as I know, Stripe is also not a Java shop.

I've heard this exact same comment at the release of almost all of the AWS SDKs I've been around for, so I'm not too surprised to see it again. I think this comes from people incorrectly assuming that (a) most Amazon developers only use Java (this is far from true), (b) that complex APIs are inherently "Java-like", and (c) auto-generated code is somehow evil, even though it yields fewer bugs, more consistent usage, better documentation, more performance optimizations (compare boto's issue tracker to Ruby, for instance, and count the number of defects).

The reality is that sometimes complex APIs are just what they are: complex. Goamz is "easier" because in most cases it completely ignores the complexity of the full API by only exposing a small subset of it. For many use cases this is fine, but I've spoken to plenty-a-customer who told me stories of trying to hack in extra API calls to Goamz when it couldn't do what they needed. That doesn't sound "easier" to me.

Unfortunately, when you're writing a generalized library meant to account for the simple and complex use cases alike, you can't optimize only for the users who touch a small portion of the API's surface area. You have to start with a base that supports all use cases. If AWS had released a library like Goamz, you would hear the other set of users complaining just as loudly that they can't do X with the SDK, talking about how poorly designed it is for them. Over time, you may see the Go SDK add specialized APIs to make certain simple use cases easier (just like has already been done in other SDKs), but this won't happen right away-- it requires a lot of effort to identify and prioritize those cases. The S3 upload/download managers and the DynamoDB marshaler abstractions are a good example of this. Instead of yelling into the wind, I would recommend opening issues to ask for similar simplified APIs for use cases that are genuinely complex with the current SDK. But note: they should be genuinely complex, not just "this takes 4 lines of code and it should only take 2".

The usage is so verbose and you need to pass pointers around all the time. Even when it's clearly not changing the original instance (when passing by value would be enough)

Passing by value is not enough. Go cannot differentiate a string value of "" (or int value of 0) from one that was omitted by the user, which is why we (very painfully) had to make the decision to use pointers. Making this decision sucked; we literally spent weeks trying to whiteboard workarounds that wouldn't completely gut the core functionality of the SDK. Unfortunately, @lobster_johnson said it best when he pointed out that Go forced our hand here. The lack of overloading, named parameters, default arguments, nil-by-value, really are the reasons why it's just not possible to make this more elegant in Go. Using positional args, as pointed out, wouldn't even last 2 months before you would see breaking changes in the API calls for many of the AWS services. Things really do change that fast in the APIs, it's the underlying reason why all of the AWS SDKs moved to auto-generated code. It's the reason you now all get SDK updates on the day of the API release-- with way fewer bugs along the way. That's a good thing.

I think the team did a great job getting this out given the circumstances. Go is a solid language for app development, but it's not really optimized for generalized libraries. The lack of common language features (literally, the lack of "generics" for generalized interfaces) means you're effectively writing code with one hand tied behind your back. With a foreign keyboard layout of your evil coworker's choosing.

People don't trust Mozilla because they read the code, they trust Mozilla because they do exactly what was described above. They do the things that foster trust.

Oh the irony of this comment given that the very first amendment to the US constitution is a law protecting "freedom of speech". You know, the one that everyone talks about being so important and necessary for the American way of life.

The SDK handles retries on failed requests. There is a little bit of extra legwork to actually do the slicing of a Blob, but you should be able to call createMultipartUpload(), uploadPart() x N, followed by completeMultipartUpload(). The SDK will make sure that each individual part gets retried on failures. That said, it would be nice to have a helper for that process.

It's not just Amazon providing this-- there is Login With Amazon, but there is also Facebook and Google that act as identity providers. Unless I'm mistaken, this is how Google's storage APIs work too, by using OAuth/OpenID to get an access token that can then be exchanged for keys.

You don't need a server for auth, that's what web identity federation[1] is for.

[1] http://aws.typepad.com/aws/2013/05/aws-iam-now-supports-amaz...

If your application is only using S3 to upload objects, the full SDK would probably be overkill. Using pre-signed forms is sufficient there. However, if you want to use other services like DynamoDB, SQS, or SNS, pre-signed URLs will not work. Also note that in order to generate a pre-signed URL you still need a backend service running to sign those URLs, something you can avoid with the client-side SDK.

An application can provide a server-side component that vends credentials to clients. Mobile applications on AWS used to do this with the Token Vending Machine[1]. I say used to because web identity federation is a much more powerful and lightweight way to vend credentials. Instead of hosting your own auth backend, you can offload that to another identity provider like Login With Amazon, Google, or Facebook.

Certainly, though, if you want total control of your own auth, you can still use the TVM or something like it to get credentials into your application. It does require that you are running a backend server though, which the client-side JS is meant to remove.

[1] http://aws.amazon.com/articles/4611615499399490

It's not the "class" of sensor that makes the difference, it's the specific sensor itself (the multitude of Nikon and Canon DSLR models with significant variance in quality should illustrate this). Also, APS-C isn't a specific size, it's a classification that different manufacturers interpret differently.

More importantly, though, I would say that "plenty" is a stretch. There might be some with large enough sensors, but those models are still the exception, not the rule, and most likely they will be at the top end of the price point for a compact anyway... I mean, the Coolpix A is $1000+. You can get an entry level DSLR or a pretty good used one for about that price. You're actually paying more for convenience than quality, at that point.