I would definitely prefer this. I've never wanted to see the "cache" stores for all (XDG-compliant) apps, but often want to see everything for a single app.
As someone spending a large amount of their week doing interviews these days, I really empathize with the spirit of this article. I've expressed an annoyance very similar to this one many times before - it's astounding how many nominally senior programmers are not adept at manipulating text.
If you've been writing a lot of software, I would expect you to be good at actually putting the characters into a file and moving them around therein. I would be very suspicious of someone who claimed to be a master carpenter but couldn't drive a nail cleanly. Muscle memory is a real thing, and the mechanics of a task matter. What is the point of all our fetishization of editors and keyboards and such if not to smooth the transition between brain and paper?
This isn't even always a matter of candidates operating in an unfamiliar environment. Even on their own personal computers, in the editor they presumably use for work, I see a lot of flailing.
I'm sorry if that's how I came across, it's definitely not my feeling. I think the CTA works in that it's a system we should be investing much more in. And taxes should probably go up. I just don't want that money going to private enterprise, especially one run by someone who by all accounts does not believe in society.
First, nobody who's lived in Chicago for more than about thirty minutes can possibly believe that this will end up being free to the city. At some point, somehow, we're going to pay.
Second, we already have a perfectly fine train to O'Hare! This is an incredibly marginal improvement, and only benefiting a group that already has plenty of options. The existing train systems are focused entirely on an outdated model of exclusively bringing people to and from downtown. And huge swathes of the city don't even get that.
You're thinking like a human. There are plenty of organizations where $5/mo and $150/mo are essentially indistinguishable and would not affect decision making in any way.
LiveWatch Security | DevOps Engineer | Chicago, IL | ONSITE
LiveWatch is a home security and automation company that combines industry-leading technology and truly personal service to protect our customers.
We're looking for a Devops Engineer to work alongside our small engineering team (currently around 6, depending on your definitions) building robust systems and processes. We'd like someone with strong AWS chops and experience with provisioning/config management tools (we currently use Ansible and Terraform). Some other nice points to have would be experience with managing monitoring or metric aggregation systems and PCI compliance.
One notable feature to me is the transparency in the organization. The whys and hows of both the past and future are well communicated across most teams. The things we work on are clearly tied to goals, and at the end of the day, numbers. Our work doesn't exist in a vacuum and feels grounded in a service that actually helps people.
I use it a lot when doing exploratory SQL work or writing queries. I can tinker with my query in one pane and send it over to the `psql` repl in the other.
I do use psql's `\e` command to open the previous query in your `$EDITOR`, but that only lets me get the single previous query, and throws out any comments.
Awk meshes very well with a lot of my natural inclinations about text processing. I've sadly stopped using it lately as it seems that the majority of my use cases these days run up against a (to me) glaring deficiency in the language. Specifically, capture groups in pattern regexes. It's probably one of those "you're doing it wrong" kind of things, but if awk had that one feature, I probably wouldn't ever need to use perl.
That's because pushing back against a potential employer like that is the HN version of Internet Toughguy Syndrome. You might also be surprised how few people respond to a mugging attempt with a well-placed roundhouse kick.
Yeah, I suppose reading a bunch of one-sentence-per-line paragraphs might be a bit sub-optimal, but I haven't found it to be a problem in practice. For longer documents, it's not much trouble to read the rendered version and do edits in the source.
Part of the beauty of Markdown is that you don't have to use soft wrapping. Consecutive lines (with no empty lines in between) are combined into paragraphs.
I put every sentence (or longer clause) on its own line. This keeps the navigation paradigm the same. And more importantly, diffs are still readable. If you're doing any kind of collaboration or revision with your Markdown documents, trying to read diffs with one change in the middle of a paragraph-long line is quite frustrating.