That was my point. Front row seats cost more than the very back end row (which has no reclining functionality) because of extra leg room. Maybe it wasn't clear in how I phrased it.
Every so often, posts from Bruce Dawson's blog get posted here - one such post was about using Event Tracing for Windows to diagnose an issue with an NTFS lock being held causing 63 cores to idle while 1 does all the work.
A few months later, some other people in my team were struggling to diagnose an issue in production where a legacy webapp was struggling to scale up and fully use all 64 cores of the server we needed it to run on. I stepped in to help and remembered that post I'd seen on HN. We used ETW (through Windows Performance Recorder and Windows Performance Analyzer) to profile our app and I looked into the Wait Analysis. Turns out that Entity Framework 6 uses a ReaderWriterLockSlim to guard a cache, and that particular lock performs extremely poorly under heavy contention. Heavy in our case meant that for a single page build of one of this app's "hot path" pages, this lock would be taken a few hundred thousand times. We weren't the first to discover this:
What some other people in my team were struggling with for about two weeks was resolved in a single day thanks to me goofing off and reading HN. (We ultimately used a fork of EF6 that didn't suffer from this issue to solve our problem)
I bought a new HP Stream recently and it's been delightful to run Lubuntu on - everything worked out of the box. Even two finger scrolling in Firefox with the trackpad.
I have other machines that I use for my day job, but it's such a fun little computer to use.
I work on an app that edits and renders fairly complex indoor floorplans to SVG, all using React.
We deal with large hospitals and airports, so it's normal for us to have tens of thousands of components mounted at once - pagination isn't a viable solution for our purposes.
We've had to tap basically every optimization that React apps can do when managing large numbers of elements - however this has been worth it for us:
- We can use the same code to render interactive plans on the client, and to render to print-quality PDFs on the server
- We can use the same framework in our UI and plan rendering
The downside is that it's more CPU intensive than alternatives like a WebGL renderer, but for now that's a tradeoff worth making.
> more CPU intensive than alternatives like a WebGL renderer, but for now that's a tradeoff worth making
Mixing traditional React with WebGL is another option. There's react-three-fiber[1], and custom/simpler hybrids are also possible. Though I've not tried server-side rendering.
I couldn't resist trying this and making some more detailed instructions for getting better images out of iOS. Turns out that you can get fairly good results without any fancy software.
It is worth noting that while it's totally possible to fly domestically in Australia without having your ID checked, you're still required to have one.
I'm actually quite happy with the facial recognition cameras at the Australian border - they make things a lot faster than they used to be from my experience.
Parking minimums in residential areas are one of the few times I think they can make sense.
Suppose there is enough on-street parking for other non-residential uses. You don't want these spaces being constantly used by car owners who are living in apartment complexes that aren't meant for them. As a local government, you have to play the game of not letting them park using parking restrictions while potentially also managing by-laws that allow residents to get parking permits that let them bypass some restrictions.
This doesn't really apply in high-density urban areas, but I could see it being tricky to manage in growing areas.
(Although, I guess from a non car-owner's point of view you wouldn't care about whether other drivers are being inconvenienced by a lack of parking, because the knock-on effects wouldn't affect you.)
If this was a suburb or mid-urban than no one would care. But the complaints are about parking minimums in super dense urban zones. Where developers are marketing them as walk to work, commuter friendly residences. The reality is the streets are desolate canyons of parking garages. Where parking is an additional expense that you can't get out of.
In my city all the parking is below the building on several levels below ground, ground level is all mixed retail/residential. It sounds like you've got a problem with zoning, not parking.
Even if that's the case, that parking is still priced into your rent whether you use it or not. The building needs to built taller or take up more of the plot. The parking needs maintained. It's bonkers for a city to require parking at buildings that are accessible by transit. This is a case where the market should be left alone to deal with supply/demand.
If the restaurants in my neighbourhood choose to not serve hamburgers, are they shutting out people who eat hamburgers? If hamburgers are in sufficient demand, a restaurant will choose to serve them. If the government forces all restaurants to make 1000 hamburgers a day, it will tank the market value of hamburgers, and force non-hamburger-eaters to pay more to cover the losses from making an excessive amount of hamburgers.
When the government forces all developers to build parking, and provides free or severely underpriced parking on streets, it lowers the market value of off-street parking. Developers are forced to price-in parking development and maintenance.
Developers will still build parking where residents need parking. If they didn't, they would have trouble selling/renting their property. There is no need to force them. In cities around the world, we still find private parking in absence of parking minimums.
Not all soil types allow for underground construction. There are numerous cities in the US with no basements or other underground structures since the soil will not allow it.
In my city the parking is below the building on several levels below ground, requiring months of blasting to get through the bedrock, and significantly driving up the cost of the building itself.
Daylight saving time doesn't apply to the winter though.
Winter time is standard time, and DST is in effect during the summer months to better make use of the extra light available during summer by winding clocks an hour forward. The idea being that you get an extra hour of sun in the afternoon.
As a data point, my company is using yarn workspaces where one of the projects is an Electron app, and another has a Node server with native dependencies.
Our nohoist section currently looks like this in order to get things to behave:
These are likely going to require auto-ejection due to being native and having postinstall scripts.
Would it make sense to not bother with hoisting of ejected modules when using YPnP, given that YPnP solves the same problems as hoisting in a more global way? We'd be able to get rid of the nohoist section in that case.
Front-row seats and exit row seats are paid upgrades because of the extra space. They aren't paying economy - they're paying slightly more.