It’s big for caches. As your application grows in complexity you get dependent lookups. I need the user id to get the company id. I need the company id to figure out what features the user has access to. And then I need to run a bunch of queries to pull data for those feature.
And while using the cache may cut an order of magnitude off of the overall time, you’ve gone from hundreds of milliseconds to tens, but with a bloom filter you can figure out you have a cache miss faster and start the process of fetching the data sooner. The user may not notice the small improvement in response time, but by Little’s Law your cluster size can be smaller for the same traffic.
Web browsers use bloom filters to determine which CSS rules apply to which elements. IIRC Chrome removed a perf screen for CSS rules because most people were getting results below the noise floor for the timing function. The time to load the CSS was still relevant (maybe moreso due to the higher setup cost of the filters).
YouTube/Gmail/etc etc and everything that the government is tracking. FWIW, they are tracking our internet with all sorts of fancy technology.
I think probably what I meant to ask is:
I started exactly like this. I wanted to get more and more points as soon as possible; You would ask why ?
I wanted to appear smarter than I actually am :(
One of the reasons was to fill the void of me not being able to socialize. Eventually as time progressed, I stopped caring about these fictitious karma points and use this place to improve my self.
I think it is not bad to want more karma, IMHO, the thing that matters is how does one gets there.
This may not be something that helps you immediately, but I feel, if you stick around enough; karma will follow :)
> Second, not every change needs a great commit message. If a change is really minor, I would say minor is an okay commit message!
I want to slightly disagree on this for folks who are early on in career e.g me; I think there is a lot of value in learning to communicate precisely and having a habit of writing good commit message has certainly improved my skills, both verbal and written.
Even though, this activity appears futile for a minor change; it might help to improve other skills :)
Let's say your fix causes issues later. When I read the commit message, I want to understand what you were trying to fix so I don't accidentally re-introduce the problem when I fix your fix
Do you totally disagree that this is the minimum? I'm only saying that the context is the minimum. I refuse to disagree with you about things I'm not saying.
I'm disagreeing to both points. That's not an acceptable commit message at all. I don't need to know you were working on drivers, that's obvious from the files you were working on. The minimum for a commit message should be the why, not the what
For that you have external bug tracking systems. Although I tend to have a short summary and mention the ticket number. Therefore the comment stands alone but also has that extra detail outside.
At $work, I noticed someone was regularly committing with just a dot . as a commit message. The problem was that this repo does not have automatic scss => css for whatever reason and there's a designated person who untangles the mess and fixes people's bad scss and regenerates the css files (among other duties). After about a few dozen times, they just started putting a dot as a commit message.
Point is bad commit messages are sometimes a symptom to a larger problem and as with this vendor it is often a process problem, not an individual developer problem. In my opinion, the main problem here is that management simply doesn't care she it doesn't empower leads and developers who should care.
I agree such patterns are indicative of systemic issues. In my experiences, those process issues emit their own structured behavioral patterns. In your example, the "." commit is now a convention that indicates a specific process happened. I am not certain what the costs of fixing the root problem are, though I'd anticipate they could be expensive and difficult at this point given the time commitment to restructure the repo and automate the scss=>css. Whereas the expense of an esoteric "." commit appears relatively cheap given the need of a human to untangle the mess which cannot be automated away (without a redesign).
There’s another way that feels totally unnatural at first, but puts the subject (the most important part) of the commit message first. It makes the commit about the change and the code, rather than the author. This is how we do it in all of our projects. I fought it at first, but I was wrong and it’s a lot better.
Example:
EntityStore build method records the specifier argument when given
I would strongly disagree with it, because it misses the opportunity for using the commit message as a sanity check. Accidents happen, sometimes I select the wrong file for the commit, or include changes I didn't intend.
Even for the most minor commits, including "improve comment formatting ; utils.pl" allows skimming that message and comparing it to the actual commit.
It also helps me be aware of what I'm doing, pointing and calling style.
To nitpick, the git commit already contains information about which files are affected; adding it explicitly to the commit message does not add value and, like comments, may be incorrect. I like the angular style guide's concept of "scope", like, what category or module of the application does it apply to.
That said, an "utils" file is often a smell in code organization.
> the git commit already contains information about which files are affected;
Contra: while this is true, it's worth considering how 'information about which files are effected' scales when examining the history of a repo. A commit message that simplifies and clarifies the intent is more useful than one that requires a future reader to read each git commit in full to understand the effect.
Even something that simple falls into what vs why: You can tell it was spacing from the diff, so the commit message should be "linting" or "alignment" or something similarly more meaningful.
The diff may not be visible. The person might be doing a complicated cherry pick or merge and scrolling through hundreds of commits. If the message explains it, it saves them digging in.
My analogy is your bookshelf books still need jackets!
I’d take it one step further: if `git log`—a hierarchical view of the connection of commits—is the only way you (and your team) interact with commit messages, then yea it’s probably fine.
But, I think the value of commit messages become really apparent once you (or your team) are relying on other visualizations of commit messages like `blame` and `bisect`
Tracking down the introduction of a bug with bisect and resolving to a commit whose message in “minor”, because the person in the past didn’t think this change was important enough to describe intent can quite the temporal foot-gun.
I think, I feel, I am out of this rat race of fighting for that next promotion, learning that new language, earning more money, wanting that ${THING}. No, I am not a monk, nor do I want to become one, but I am passionate about how to be content and grateful for whatever I have; I am relatively at peace for a good while since I started to train & reinforce my brain to behave this way. Thanks to Almighty.
TiL: The shell does not exit if the command that fails is a part of any command executed in a && or || list except the command following the final && or ||.
"Fails" is a higher-level concept than the shell is concerned with. Failure conditions and reactions are entirely at the discretion of the programmer and are not built as an assumption into the shell.
The only thing /bin/false does is return 1. Is that a failure? No, that's how it was designed to work and literally what it is for. I have written hundreds of shell scripts and lots of them contain commands which quite normally return non-zero in order to do their job of checking a string for a certain pattern or whatever.
Programs are free to return whatever exit codes they want in any circumstance they want, and common convention is to return 0 upon success and non-zero upon failure. But the only thing that the shell is concerned with is that 0 evaluates to "true" and non-zero evaluates to "false" in the language.
It would be pretty inconvenient if the shell exited any time any program returned non-zero, otherwise if statements and loops would be impossible.
If a script should care about the return code of a particular program it runs, then it should check explicitly and do something about it. As you linked to, there are options you can set to make the shell exit if any command within it returns non-zero, and lots of beginner to intermediate shell script writers will _dogmatically_ insist that they be used for every script. But I have found these to be somewhat hacky and full of weird hard-to-handle edge cases in non-trivial scripts. My opinion is that if you find yourself needing those options in every script you write, maybe you should be writing Makefiles instead.
> It would be pretty inconvenient if the shell exited any time any program returned non-zero, otherwise if statements and loops would be impossible.
In another life I worked as a Jenkins basher and if I remember correctly I had this problem all the time with some Groovy dsl aborting on any non zero shell command exit. It was so annoying.
`grep` should terminate with an empty output on `stdout` and an error message on `stderr`, then `sort` will successfully sort the empty contents of `stdout`
In my opinion, it is one of the biggest flaws in the shell language design, because it means, that a function can lead to different results independent of the arguments, but depending of the context from which you call it. And it even overrides explicitly setting `set -e` within a function.
There are more arcane things to learn about shell, at some point one has to go shrug, it's a fine tool for getting quick results but not for writing robust programs.
Can folks help me a little here, please. Sure this is an awesome announcement. I now am considering to buy a ChromeBook even more seriously.
My reluctance is, can Google, tomorrow (before 10 years) feel that, ahh no we are bored of this so let's not do it. Google has a history of introducing stuff that people start to rely on and then kill it; I still wish Inbox had not been killed by Google.
How often have they explicitly committed to support something for that long? Not disagreeing just curious. I think the main thing is whether or not they continue the product line. As long as they keep releasing Chromebooks they'll want to keep this commitment or else they'll risk reputational damage.
You’re not wrong. Google does have a history of ending products. Honestly, someone should read the fine print and figure out if there is a clause in there that actually allows they to end support whenever they feel like it. I have an inkling that there is…
A few non-exhaustive real world use-cases that come to mind:
- Databases: To quickly check if a record might exist before doing a costly disk lookup.
- Spell Checkers: To check if a word might be in the dictionary.
- Spam Filters: To check if an email sender is on a list of known spammers.
- Browser Security: Chrome uses Bloom filters to check if a site might be malicious.
- Password Checker: To check if a password is known to be leaked.
- Web Caches: To check if a URL or resource is definitely not in the cache.
- Distributed Systems: To avoid sending data that another system definitely doesn’t need.