Here's the thing, though: It's almost definitely a case of silent majority. The printer is pretty phenomenal and I've had excellent support from Bambu so far in New Zealand, no less.
Yes. Breathing it's fibers can cause serious disease and cancer. Asbestos was used as a common building material in New Zealand for insulation, roof tiles, ceiling tiles and texturing and more in the 1950-1990 period. If you do any renovation or changes that interact with asbestos, it basically has to be handled by a hazmat team.
Oh my goodness, you're my saviour. I spent a whole day last week debugging what looked like a caching issue with Ecto + Postgres. When the application ran a query, it'd eventually slow down to 600ms.. when I ran it in psql, always 10ms. My solution was to convert the query to SQL and run it manually which bypassed the plan caching Ecto does.
THANK YOU. I will absolutely be testing this tomorrow.
Interesting theory. I don't think it's true, though. The original spec mandated case-insensitive comparisons and it looks like WebKit has always been doing that to me.
> ...y'know what I find particularly nuts about this whole thing? That we only know about it because of that ___location icon in the status bar
It seems to me like discovering this from that status bar icon is a _good_ thing. It gives me more faith that the system isn't hiding particular types of calls from the user; that it's tying the system call to the icon being present.
Oh, the fact that researchers did find this absolutely speaks well of Apple! Although, there's a sort of confirmation bias here—if there's some other situation where requests go out and the icon never appears, we wouldn't know about it.
Yes and no. One of the results of iPhone 4's "antennagate" is that Apple changed the way the phone signal is displayed. They changed the algorithm, and made the signal bars more prominent in low signal situations [1]
I'm not suggesting they will change its behavior, but it wouldn't be unprecedented if they did.
EDIT: Changed the video start time to specific reference.
That was the first time I actually watched that conference.
Steve Jobs presents a convincing case. It's now clear to me that the media hyped up a non-issue, or at least one that was ubiquitous across the state of the art at the time. And Apple's response is perfectly reasonable.
What exactly is your problem with his explanation of the changes?
I have no problem or strong opinion regarding iPhone 4's antenna debacle, I'm only referencing what has happened in the past about issues hyped by the media, and how Apple has handled them.
iPhone 4/4s remain my favorite iPhone generations to date.
Isn't that because previously it was just a measure of signal strength and wasn't a good measure of data quality / latency / bandwidth? A proper signal meter takes both strength and noise into account.
> Maybe if I had more specialized team members it would get easier
It really would be easier. We are using this stack, and have separate backend and frontend devs. Each love their side of the stack. Being backend myself, I don't find the it too time consuming to get new entities going. However, I imagine if you were doing the whole stack and repeating ecto schema, absinthe schema, apollo queries, then it might get more tedious.
I particularly enjoy how easy it is to modify the schemas once it's set up too. If we ever need to expose more data, it is usually done within minutes.
There is a massive benefit in the forced standardization of GraphQL too. Being rigorous about standardizing APIs and how you do filtering, sorting, embedding, nesting and so on is tiring and a waste of time - you end up writing mini frameworks. Absinthe and GraphQL reduce this pain for us considerably.
That was one of the reasons I choose this stack. The plan was hiring team just after stack was set. Unfortunately financial plans toppled and we (2 full stacks + front end UX) were stuck with very complex architecture designed for ~10.
If I would be to working on only 1 part it would be great, but instead of parallelizing effort it was sequenced which kind of sucked.
It's early optimization at the architecture level. I've seen it happen so many times.
On top of all you said, the GraphQL stack is horrible for caching. You will not have this problem until you reach really high traffic, but once you do, it will eat you alive.
Unlike a rest endpoint, you can't cache a URL. You can't use HTTP headers. You don't know beforehand what GQL query will come and even with batch queries for different types it's super hard to optimize. It's very easy to have an N+1 query hell.
The lesson I learned is to use the boring stuff until it really needs to scale up. A REST API with static HTML and some sprinkles of JS will get you to the phase where you actually need to start using React, GQL, etc.
GQL trades a lot of things for flexibility, but 99% of the apps don't need that in the first place.
But hey, on the upside everyone can put in their resumes that they used all the new hot shit :)
