Yeah this article is kind of light on technical details. I’d love to see an in depth postmortem and see what Apple’s mitigation plan is.
898 karma · joined March 25, 2013
That feels like about three layers too low.
"The bucket in question was created by an AWS salesperson
to store prospective AWS pricing scenarios while working
with a customer," an AWS spokesperson told Engadget.
> 2.5.2 Apps should be self-contained in their bundles,
> and may not read or write data outside the designated
> container area, nor may they download, install, or
> execute code which introduces or changes features or
> functionality of the app, including other apps.
I would however, strong suggest that javascript shouldn't be someone's only language.
Any chance you could share any info about the architecture design of your homegrown system? I've seen a few snippets where devs build their bundles and host them in s3, how complicated was it for you to roll your own OTA solution? Would you guys do it again or would you use Code Push?
I usually just use JSONB columns for this.
Currently when deciding on a backing store for my python based applications I usually jump straight to PostgreSQL what are the things that Mongo excels at these days that are missing from pg?
The ability to override operators is one of the things I miss most from Python when I'm forced to write javascript.
It's just really annoying that I have a ton of queries that return lists of objects, where each object has an easily known expiration time, and there's no way to say, "cache this result but remove the elements that have expired". I can't even say, "cache this list until X time", which would be very easy in a RESTful environment. I know there are extensions to support caching but none of them are universal yet. I'm hopeful that the community will land on an answer for object level cache expiration.
I love how flexible it is for client developers and because the great client side libraries it helps to eliminate a ton of boiler plate code on the client side.
My biggest complaint has been "lost" exceptions and caching.
Because it's possible for an exception to be thrown server side on one field while the other ones succeed I've been plagued with hard to monitor/find errors. I ended up writing a shim to parse the response in an attempt to get more insight into #errors / fields (this has also been really helpful for monitoring slow queries in new relic since all requests go to the same endpoint which breaks a ton of APM monitoring).
My other issue has been around caching, in apollo there are ways to say "don't use the cache for this request", but it's not to give an object a cache ttl. My app allows users to search for events that are happening near them right now, and I've run into several issues where apollo decided that an event from yesterday should be added to a result. It happened frequently enough even with queries that included times as an argument that I ended up basically implementing a "middleware" between what apollo gives back and the component, which felt really ugly.
After reading this write up and AirBnB's write up about RN I keep wondering if the source of the problem is more with integration points between native features.
Like I said, I'm not a traditional native mobile engineer, but as a single dev I've been able to build a rather large and complicated app almost entirely in react-native. That's not to say that I don't use mobile features, I'm using a dozen or so libraries for native features, but the common problem that seems to arise is "this doesn't integrate well with the rest of our native app". IMHO if you're writing business logic in swift/java instead of javascript you're going to have a bad time. If, however, you use/implement narrowly scoped native libraries that are glued together with javascript it's a pretty nice experience.
I wonder if the issues that they encounter are more a symptom of trying to "bolt on" react-native.
One of the advantages of django apps is having cleanly divided responsibility. For example, I worked on a large django project that had 70+ apps and several dozen developers. Engineers were encouraged to create new apps for new functionality. In some cases apps could be cleanly pulled out of the code base and converted into a library. The ability to pull libraries out of the "main" repo also meant that certain teams could more easily "own" parts of the codebase. At a different company we actually decided to split our monolith into 3 separately deployed services and it was pretty easy for us to copy the appropriate Django apps into new services.
In general I've found that early in a company's life it is much easier to manage the complexity of a monolith and I've found that Django's app abstraction allows developers to communicate which parts of the codebase shouldn't be overly intimate with one another, which at least gives you a hope of breaking pieces into separately deployable libraries or services as the company/project scales up.
If something is really complex / important / hard to change later, then I'll usually stop after the research phase and allow my unconscious mind to chew away on the solution, most commonly for me the 'Aha moment' comes during my morning workout. When I'm really stuck I re-read all my collected material, search for prior art again and repeat the process. Sometimes time forces me to just start building, although those are the times when I typically end up refactoring later.
I definitely agree that time away from the problem to reflect leads to a better solution, but IMHO you have to have a really great problem statement and good context for the subconscious to do its best work.
At least this way there's not a huge cliff between the free product and a contract for larger volumes.