I'm disappointed that the three photos in the Gallery with the laptop in use aren't actually showing what the screen would look like IRL; they've been cleverly doctored by overlaying screenshots on top of the display.
I found out about this book through the EmbeddedFM podcast [1]. Their latest episode is an interview with the authors of the book. Highly recommend the episode, and the podcast in general for folks that are into electronics.
What kind of company were you working for? I've lived and worked in Melbourne my whole life and complacency is not a cultural attitude of the location, but of specific companies.
Have a look at CDKTF [1]. It’s a wrapper around Terraform that lets you use CDK-style semantics that compiles down to a Terraform plan. Every Terraform provider can generated into a CDKTF library.
I'm looking forward to the improved editor experience as gopls is now workspace-aware.
There's a couple of repos at work which contain multiple Go modules (each in their own subdirectory, with their own go.mod files). It's a bit of a pain to get LSP working correctly for each individual module if I open the root directory of the repo in my editor.
The algorithm has similar complexity as binary search, but is a bit smarter on deciding how to split the test input at each iteration.
I’ve been studying this in my masters, and we’ve recently had to write a Java implementation. I’m keen to start on a Go package soon that might work well with fuzz testing.
> Ask them for a narrower review — e.g., a design review or an architecture review
I like this technique for PRs of any size (except very trivial changes). Code reviews can be a great learning opportunity, made even better if the author has specific aspects of the code they'd like feedback on.
For example, I opened a PR the other week with a bunch of refactoring work. One chunk of the refactor changed how a complex data transformation was being done by replacing some unnecessary local variables with a chain of map, filter, and forEach functions. I highlighted this as a particular point of interest, which spawned a good discussion on testability, how small our tests should be, and if there's any value testing specific bits of the transform vs. the chain as a whole.
I wasn't surprised to see the Family Sharing pane in the first screenshot. It's easily the most janky part of System Preferences that I've had to struggle with:
- Loading indicators for several seconds when switching between categories in the left sidebar, on a very decent internet connection.
- Janky animations and transitions when opening modals, like clicking the "Details..." button on a family member.
- Within the "Invite people to your family" modal, clicking "Not Now" causes the "Invite People" button (the default, highlighted action) to blink before the modal closes.
Yes while these are absolutely nitpicks, I feel that Apple has lost some of the attention to detail that set them apart.
We've gradually been having control of the software we use wrestled away from us.
The (unfortunate) idea is that network latency will be low enough, and rendered interfaces will be good enough, that companies can make "streaming software" a compelling enough experience for the masses, to the point where it becomes normalised.
The hardware will probably have the capabilities to do so, but I can see consumer software reaching a point where much of the compute is performed remotely, and we're just being streamed a rendered interface.
I've just started my first semester of OMSCS and planning to stick with a single course per semester, and skipping the summer semester to give myself a break.
Not sure if I can manage more than that + work, and also being able to enjoy time with friends or away from the computer.
I've used an app called PhotoPills to plan landscape photo shoots in the past. It lets you drop a pin on a map and shows you the direction of sunlight at any given time of day.
Shade Map gives me so much more fidelity to play with. The pseudo-3D view with shadow rendering helps tremendously in previsualising a photo.