ryangittins
Respectfully, it is not.
It may feel silly to have a whole unit test for a one-line regex, but that one line can be really dense. If you wrote a function to parse the string without regex, that function would be complex enough to warrant a unit test, after all.
Introducing regressions when tweaking a regex in your application is also a big risk which unit tests can help mitigate.
If you really want to get technical: ., ?, and + are also shorthands. The formal definition of a regular expression is very minimal on purpose.
`.` is just `(a|b|c|...)` - List of all literal characters
`x?` is just `(x|)` - "x or empty string"
`x+` is just `xx*` - "x followed by zero or more x characters"
Whether this is exactly how they are implemented in any particular regex engine is an implementation detail, but formally there are very few operations which aren't just syntactic sugar.
The Doorman Fallacy is exactly this—thinking that one function of a job is the whole job. The doorman doesn't just open doors nor relay messages. They're eyes and ears, security, friendliness, an extra hand with bags, local knowledge, emergency response... The list goes on and on. Almost none of their functions can be replaced with an intercom.
We looked at Linear and other options but ultimately ended up going with Shortcut. We wrote our own small migration script and moved over the old Pivotal IDs to keep as much historical context as we could. Shortcut's been a good tool overall, though I preferred Pivotal's Goldilocks level of compactness as far as the UI was concerned, as well as the general design.
Pivotal's API was tidy and integrated nicely into our development process. We have some git aliases such as `git start <branch>` where the branch name will end with a story ID by convention. The alias would do the work of creating the branch, setting the remote to the dev's fork of our repo, marking the story as started, and assigning the dev as the owner. It saved a lot of manual steps, so thank you for your involvement in the project which allowed such a nice workflow!
RIP Pivotal Tracker, and thank you for your involvement! It was a nice piece of software.
I didn't realize I've been reading HN nearly its whole existence. For all my complaining about what's happened to the internet since those days, HN has managed to stay high quality without compromising.
As a kid I would browse their website endlessly, just fascinated by all the weird stuff. It scratched the same itch that watching Mythbusters would scratch. In adulthood I rediscovered them and went to their Milwaukee location for the first time. We spent hours there, looking through all the cool stuff they have. It really gives you ideas!
I wouldn't sweat this too much. Mathematically, most people have fewer friends than their friends have.
> Swoopers write a story quickly, higgledy-piggledy, crinkum-crankum, any which way. Then they go over it again painstakingly, fixing everything that is just plain awful or doesn’t work. Bashers go one sentence at a time, getting it exactly right before they go on to the next one. When they’re done they’re done.
I always found this frustrating in high school, as some assignments required submission of a first draft, second draft, and final version of a paper. I always wrote the final version first and then worked backwards to created a second and then a first draft by removing sentences and generally making it worse.
It looks really promising but I could not for the life of me get it to run in the Docker container last time I tried. I have a dozen or so other Docker containers running without issue, so I don't think it's my setup. Are people reporting better success with Chandler when it comes to containerization? I'd love to use it but have spent too many hours trying to get it to work.
What are your favorite shortcuts?
The reviewer suggested all sorts of minor optimizations so a script which runs once per week in the middle of the night with no one waiting on it could run tens of seconds faster. A complete waste of time and effort to my mind, and one understandable as the OP describes: a technical challenge which, when solved, equates to zero consumer upside.
With the method described, you would measure the thickness of the book (the size of the lookup file) and open to a proportional page. e.g. If you're looking for page 120 and the book is 360 pages long, that's 1/3 of the thickness. So, find the point that's a third of the thickness of the book and open the book there. You'll be pretty close.
With a binary search, you wouldn't measure the thickness of the book. You'd always just blindly start in the middle, assess which half the target page is, and repeat the operation on that half and you'll get there pretty quickly.
Both exploit the knowledge of how the data is organized and both are most well-suited to uniform data (like pages in a book or random hashes), but are just different strategies requiring different means of accessing the data.
Admittedly not a perfect analogy, but you get the idea.
I often wonder if stylometry can be used to positively identify a person based not on general word frequency, but by a single phrase or two which are rare in general but commonly used by the individual. In theory this could be relatively easy to find given a large corpus. You'd pick out the top few n-grams for short phrases by an individual and identify the ones which are most overly-represented compared to the rest of the population.
I think you're right in that "opinionated" seems like a shorthand for "thoughtful curation" which is the opposite of what search engines tend to turn up.
I think you know that you are still in the midst of burnout. If you can go a few months without a job and be okay, my suggestion would be to quit immediately and start looking for a new job in your own time. You need time to decompress followed by a complete change of environment. Recovery is not going to happen in this environment.
Feel free to contact me if you want to chat about your experiences. I went through something similar last year.
It's possible the language was just following usage rather than leading it. Regardless of whether or not it's right, I commonly see something like
} catch (\Exception $e) {
// no-op
}It's frustrating when you're forced to change the behavior of your "agnostic" application for the sake of a large, commonly-used third party tool in the ecosystem.