From the Linux conference video I watched I think they have the wrong approach. They’re trying to improve a bad api by adding types do describe it’s awkward behavior. The C programmers who love the Linux style want to be able to change semantics or api without modifying rust code. The solution is straight forward, build an adapter later in C that has well describable and clean semantics. Since it is C and in the kernel and has clear semantics the C programmers can maintain it without having to look at Rust. Perhaps the general lack of encapsulation and layers in the kernel will defeat them as they will need a lot of adapter layers. But for file systems it might be achievable.
It is a fail/succeed mindset rather than a play mindset I imagine. I definitely feel a difference between a chore and a game. That said not all chores are easily turned into games. But seeking games over chores probably leads to a happier time.
Any chance of a window manager that lets you alt tab between windows instead of between applications. So Alt-tab-tab-tab takes you 3 windows ago, not 3 applications ago, or worse 1 application ago and 2 unrelated windows of that application?
Man I really mis application menus being at the top of windows and being able to layer different windows from different applications in any order that I wish. VNC screen connections just make it into an even worse jumble.
I use both Witch and Rectangle. It's surprising how much you need third-party utilities to make macOS usable. The default window management is almost unusable without them. I also dislike the "one-button" philosophy and all the hidden behaviors, like menu items that only appear when you press the Option key. Sigh.
I've got an annoying bug that made Contexts unusable to me. After 10-15 minutes it steals focus from the active window and then the OS will try to bring up the previous app, which means it might even switch desktops to do so.
If I quit contexts bug goes away for some time, but it returns after a while :(
Sent an email to the creator, but given the update cadence I am not holding my breath for a fix this decade.
IIRC it has something to do with full screen apps/use of spaces. Just don’t use either and the bug shouldn’t occur. Annoying but I love the app too much that it was worth giving those up.
If it annoys you enough see if rcmd works for you. It’s the next best alternative Ive found so far. The Dev is great too I use a bunch of his other apps (Lunar and Clop).
I’ve also had that bug happen, not sure why it isn’t happening anymore though…
I think it happened when not rebooting my Macbook for a long time and only with fullscreen windows, and i’d simply restart Contexts. But yea it was annoying indeed. Note that it might also be one of the many Apple macOS (api) bugs…
macOS has built in shortcuts to switch through windows of the currently focused application. I have it reconfigured to alt+tab
This is not exactly what you are looking for but I personally like it more this way. So for example, I can switch between editor and browser via cmd tab but then I can cycle through browser windows via alt tab. These are two separate actions and it prevents me from having to cycle too much (compared to a solution that cycles through all windows of all applications)
Also helps to build temporal and spatial muscle memory. The first browser window is the main one, the next one was the one before that and so on
No, all window of an application are not positioned on the same layer.
But when you tab into an application, all of its windows are brought to the front.
If you want to bring one specific window to the front you are supposed to use Exposé, but some power users don’t like this because it uses the mouse instead of the keyboard.
Conversely, I find the lack of per-app grouping on Windows (outside of the taskbar) irritating, particularly on multi-monitor setups. I understand that it’s not everybody’s preference but it should at least be an option.
The behavior dates back to the original Mac, which could only context switch between applications via a hack that simulated multitasking (the days of 128K memory, etc.)
So that came along in 1987 alongside Macs with 1MB RAM. It built upon Switcher, which appeared with the 512kB Mac in 1985.
The reason all OSes now have file open/save dialog boxes is that the original Mac didn't have enough RAM to show a finder window alongside an app, so apps had to provide their own.
I was referring to Switcher, from 1985, which I believe ran on 128k Mac's. I was referring to Switcher because it set the user experience patterns and expectations for how app switching should work that led to multifinder and OSX per-app switching patterns.
The Mac OS has always been an app-first experience (leading users to tend to talk about the name of the app they are using) where Windows has always been a document-first experience (leading users to talk about the file type of the document they are opening). Apps and Documents are obviously both important, so this is a big of a ying and yang thing where it's clearly two sides of the same coin, and yet they lead to a bias to talking about, for example, keynote, which is an app, and to talking about PowerPoint decks, which are documents (again, a bias, not a totality).
> I was referring to Switcher because it set the user experience patterns and expectations for how app switching should work that led to multifinder and OSX per-app switching patterns.
Super handy! I regularly work on multiple projects at once. Have 3 phpstorm windows open, but working on project A, I can just CMD+Tab because project A is focussed. I switch between browser, terminal, editor, etc. Then, when switching to project B, I do CMD+` once in every app, and I’m done.
To me, this makes windows feel like a maze and macos feel natural.
When is the government going to realize that software and business process patents are bullshit and that they should be wholesale dismantled.
I suspect the same should be true for mechanical, civil, and chemical engineering. Eg TSMC doesn’t need patent protection, they can just be the very best manufacturer of chips.
The post is right in that the example code is terrible, Uncle Bob's changes make it much worse, but also the suggested fix is also bad. I think this is better, but the whole thing is silly. Obviously you'd want to write a comment for the function that explains its weird behaviour.
String getCandidateCountString(char candidate, int count) {
if (count == 0 ) {
return String.format("There are no %ss", candidate);
} else if (count == 1) {
return String.format("There is 1 %ss", candidate);
} else {
return String.format("There are %s %ss", count, candidate);
}
}
This is pretty much what I've come to over the years. It kinda feels like the "IQ Bell Curve" meme:
Beginner: I'll just create an if statement with 3 clauses.
Middle: No! that's clearly a ton of duplication - it's bad code!
Expert: I'll just create an if statement with 3 clauses.
And I can see how people get to the middle position. People often tell beginners to eschew duplication. They learn to see any trio of similar-looking lines as a code smell and jump to refactor. It takes a few years of doing that and getting burnt by it before you can really differentiate "this is duplicative and would benefit from refactoring" from "this only looks duplicative, and is actually cleanest with the repetition in place."
I wouldn't say his suggested fix is bad - it's certainly better than the original. But I agree your code is even better. Except it has a minor bug - "There is 1 candidates"
:) yes. I saw that error and wondered whether someone would point it out. I think the author fails to acknowledge that the use of variables like "verb" just make the code much harder to understand than a string that reads mostly like English.
The second is much easier to understand than the first, so one should be careful when pulling out too many variables.
Seems like someone should write a book called "Clean Code Done Right" that has actual good examples of code. Maybe Rich Hickey? The high level advice is good, code should be written as simply as it can be. Functions should have a small clear mission and it should be easy to argue that the function is correct locally. That is to say: a functions correctness shouldn't depend in a complicated way on other functions, just a reasonable expectation on the behavior of the functions it calls, and a reasonable simple description of its mission. Easy to state this objective often difficult to achieve in practice.
Maybe a book showing elegantly coded solutions to actually difficult programming problems would be good, e.g. a system with maybe the complexity of high performance sharded fault tolerant Redis. There would be a lot of interesting topics there.
This is the way. Far easier to understand (and maintain!) than any of the other examples. Temporary variables are abstractions, must use them with care.
How many other classes of such bugs exist. Without a public COE one can't know that it was systemically fixed. One can't know whether security boundaries were by-passed by the bug. One can't know what sorts of extra protections are introduced for this type of systemic error. So what confidence would you have in the product with no public explanation -- are you saying, oh they're google, I'm sure they're doing the right thing.
Even if it was operator error some sort of public COE would help others avoid the pitfall by design, e.g. restricting the permissions of terraform so that it can only affect resources for the system and availability zone (or better still cell) under deployment, e.g. you're running a deployment to system X, you shouldn't be able to destroy your backup buckets. Essentially minimizing the blast radius of configuration operation. I guess you'd also want to one-box the terraform change after testing it in preprod ideally though a pipeline with monitoring. "The power to modify is the power to destroy." Finally I wonder if there is a some way say to terraform, don't delete more than x resources and start very slowly, and only delete leaf resources, not the top level resource.
At the end of the day terraform can have a bug. You really want to control blast radius with permissions. Makes me wonder if the GCP VMWare integration is a boundary that doesn't expose granular permissions.
If it was operator error with terraform that should set off alarm bells through the industry. Who else is one fat finger away from total annihilation.
I used to ~own all internal terraform usage at a very large software company. I could talk for hours about all the ways in which the "wall of text" is ineffective at scale. A surprisingly large amount of our technical investment in TF was around improving plan review.
I usually only look deeper if the summary (X created, Y updated, Z deleted) shows some unexpected numbers, especially if the number deleted is not 0. However, if nothing's being deleted, I usually assume it's safe enough.
Is the VMWare integration tied to the GCP marketplace? Maybe Terraform modifying a fundamental VMWare resource (like renaming a cluster, etc) where the entire account is tied to a reseller or integration account could cause it to think it needs to delete and re-create.
I don't understand how this isn't a bigger deal. No public COE (correction of errors) for what happened on the google side? Without a public COE from Google I don't understand how anyone could use GCE for a serious production system.
What are the chances this is the first such attack, not just the first one discovered. Presumably every library or service running as root is open to attack and maybe also some running in userspace. The attack surface is massive. Time for better sandboxing? Once attackers get into the build systems of Debian and others is it game over?
I wouldn't be surprised if there are others but this specific one seems special. It was caught because on connection it does an extra decryption operation and I'd assume there is no way around this extra work. They'd have to re-architect this to not require that decryption.
