Yeah between this and Toyota's similar talk about amazing tech just around the corner (https://news.ycombinator.com/item?id=36833836) it feels like this could be a concerted effort by Japanese car manufacturers to create some FUD to keep people out of EVs while they get their act together.
Apple already does the same thing. Apple Search Ads is not limited to the same restrictions that Facebook and Google are with regards to iOS tracking and reporting for advertising attribution.
My understanding is that it's essentially Looker minus the dashboarding. What you would define via LookML is essentially the "semantic layer" that this is addressing. DBT is attempting to do similar work: https://www.getdbt.com/product/semantic-layer/
The Shopify layoff memo (https://news.shopify.com/changes-to-shopifys-team) has a pretty interesting graph of exactly this effect. Basically a huge leap in e-commerce adoption with a subsequent dip right back to where the pre-pandemic trend line was heading. It’s not hard numbers I suppose, but it was at least the reason shopify gave when explaining their layoffs.
Used it for several years, beat the pants off Redshift and was comparable to BigQuery for our use cases. They have a ways to go on the maturity/reliability front though.
I too am in Victoria. I used to be a hiring manager and had people turn down 6 figure (CAD) offers due to receiving a better one. Although there is admittedly a huge gap between the local companies, and the satellite offices of American companies. Look at KIXEYE, Change.org, Workday, Abe Books (Amazon subsidiary). They typically pay up to 50% more than the local companies, but also typically have higher expectations around skills and availability.
When we've looked at BigQuery it seemed that if you prepay you essentially get a similar effect to what you're describing. You're given a certain number of "units" of compute, and if you exceeded your concurrent units available you end up with the same compute resource contention you would with an improperly scaled Snowflake warehouse or Redshift cluster.
If you're willing to just pay per gigabyte scanned with BigQuery you can scale near linearly I'm sure (although I haven't actually tried it), but you could accomplish the same thing using Snowflake's API to add warehouses as concurrent query load increases. That's what we do (although we just pre-allocate and suspend the warehouses because you only pay when they're on).
Redshift does suffer from this problem because the compute is tied to the data, but Redshift Spectrum is attempting to rectify that as well. I don't know anything about its performance though.
Rather than conditionally execute code (to avoid performing an unnecessary expensive operation) always execute the code, then discard the result if it is unneeded. The idea being that the performance gained by avoiding the unnecessary operation is not worth the complexity added.
I've often wished Dropbox's selective sync was managed by folder rather than by client. It would be more helpful to me to mark folders to not automatically sync account wide than to have to choose and re-choose those folders every time I setup Dropbox. I feel like that would potentially be helpful in this use case.
I read the linked webpage, and I have had none of the issues he seems to think occur with git pull --rebase. I believe he uses git differently than I, and many other people, do.
Whenever I'm about to begin work I create a new branch. I git pull --rebase that branch with the upstream branch I am going to merge with frequently while I work. I've never had any unexpected behaviour.
You are correct that the problem is the manager and not Kanban, but in my experience it has been the case that the problem is always the management at some level. The point of this article is that if you think adopting Kanban is going to solve long standing organizational and inter-personal issues, you're in for disappointment.
I have personally experienced this situation more than once. A manager/team/organization who claims to be adopting (Scrum/Kanban/etc) but when push comes to shove they immediately discard any discipline imposed by any approach their team has decided to commit to, thereby rendering it completely pointless.
If your manager is competent enough to understand the reasons for the rules of Kanban (or any Agile methodology), and has the power to enforce those rules despite pressure from other parts of the organization, then it's likely you don't need to ascribe to a particular methodology anyway. Your team will adopt an approach that works best for them, borrowing best practices from various methodologies, and will get the job done regardless.
I just purchased an Asus UX51VZ with 2x128gb SSDs and a 15" 1080p display that weighs less than a Macbook Pro Retina, for $400 less than the Macbook would've cost. The Retina has a couple of big wins over the UX51VZ (battery life and higher resolution display) but I wouldn't put them in different classes, or claim that Asus isn't even trying.
I think it is usually easy to determine by context when someone is referring to a language and when someone is referring to the typical implementation, libraries, etc that come along with a language. In the context of performance benchmarking it is clear (to me at least) that the benchmark would be of a particular implementation, of which there is usually an obvious choice. I don't think there is really any misunderstanding of that.
Yes I agree. I've never felt that I shipped a product late because it took me too long to type. A good editor and a nice setup certainly help me feel better, but I think it's very easy to get carried away.
I agree with this. There are certainly situations where more than 40 hours of week are a necessity, but those situations should typically be temporary for the majority of employees. If you are in an organization where meeting your goals requires more than 40 hours a week, week in and week out, then I would say there's probably issues that go beyond your work ethic and personal boundaries.