sha90
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.
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?
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.
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 incredibly slow.
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.
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...
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.
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.
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.
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.
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
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.
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.
[1] http://aws.typepad.com/aws/2013/05/aws-iam-now-supports-amaz...
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.
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.