My latest dad hobby is listening to air traffic control recordings. Pretty impressive stuff, also pretty funny sometimes. Especially stuff involving "Kennedy Steve"
One of the thrift stores near me has a fairly large library and once a week they do a deal where you can put as many books as you can fit into a grocery bag and it's only $1
Our libraries do something similar -- used book sales -- fairly regularly. First place I looked for the Concurrent Programming book was in the local library (struck out)
I donate many more books than I purchase, these days. I'm halfway between a collector and "online only"
LOL; I searched Amazon's book section for "DOS" and there are two further categories I can choose from: "Children's Books" or "Literature & Fiction" -- both of which are pretty accurate at this point
(I was wondering if I could get some help remembering one of my very first computer books, that I've held on to)
Under Linux, even though not dealing with low level API, but with some supposedly cross platform development, does version change not lead to drastic change, and people can still rely on the knowledge in the old days?
Some libraries (on Linux and Windows) change drastically, but the core principles don’t move much. You can write C programs in the same way as you could twenty years ago.
Likewise, some languages change a lot, or add new features; so while you can still write 90s-style C++ or Java, you wouldn’t want to (and learning 90s-style C++ or Java wouldn’t help you get a job).
I have a template file which I need to put different values in occasionally. It's a feedback form for my short term rental. Having that information in my form means that I have to keep committing changes which aren't part of the template. Would it be reasonable to put the specific information in a config file (I was thinking YAML, which is about as flexible as it gets, though in this case it's overkill), and just have the template reference the config file. Does that sound reasonable?
@JeffSchaller I turned off the fancy completions in zsh as soon as I noticed that it would actually execute qemu to complete some stuff on a qemu command line...
This would probably be a good time for someone to post a picture of the Giant Sea Snail from the Doctor Dolittle movie. Which is actually in the books.
Most of the movie isn't though. The Doctor Dolittle books are also notably short of singing.
:-) Continuation of my previous comment, curtesy of talktotransformer.com: They can also solve a variety of regular typing problems: they require fewer key presses than unguarded classical typists. Some primates also use this kind of typewriter.
> For example, the stick shrew has a rudimentary typist's skill. The shrew has six toes, which allows it to walk on a mat. It also has two fingers on each foot. The two fingers each have two digits that are paired so that if the left thumb is under the mat, the right is over it.
I was just thinking about router/switch commands and how terrible their cli is
You can truncate pretty much any command on a router/switch and in fact most networking people love that fact and are proud of how badly they can formulate commands
a common example is: show running-configuration which is almost always run as: sh run
I was typing a long zfs command and thinking about how terrible it would be if unix allowed crap like that
@FaheemMitha I couldn't figure out what this was about.
@Tim if you read through this question and answer fully, it's a pretty good explanation I think, even though it's not directly about justifying that slight resentment. But it lays out the technical differences that underlie that resentment. unix.stackexchange.com/q/141016/135943
@Kusalananda and many modern utilities use long option names with a single hyphen. It's Go that has made that pattern common (I finally learned).
I don't know if Go invented that pattern, but it is by far the easiest way to make options in a Go command line program you're writing (using the standard libraries).
@FaheemMitha I don't see why. If you're doing it in Mercurial or Git, wouldn't the proposed yaml file live right next to it anyway, and necessitate a commit for any changes regardless of which file you're making them in?
@Wildcard I don't want to. That's the whole point of what I was saying.
If the two are not separated, i.e. are in one file, then I do need to keep committing every time the values change.
Which isn't useful and just creates noise. I don't need to keep a record of all the different guest names and length of stays, at least not in this context.
@FaheemMitha right, but I don't quite understand why you would have to in the first place. Or to put it another way, I don't see how it could be that you (a) have a file that can legitimately be called a template, and (b) have stuff in the template that you are finding the need to change, and (c) are in the position of having to ask how to avoid needing to commit those changes.
@FaheemMitha well that makes sense; so then I guess my question is, in what sense is the file you have a "template"?
@Wildcard Template just means stuff that isn't related to any specific instance. In this case, the instance is a guest stay.
@Wildcard I admit I don't understand what you find unclear. It's a very simple issue. Possibly not even worth asking about.
I have a feedback form. The feedback form contains the name and length of stay for short term stay guests.
I just want to separate out the name and length of stay of the guest from the form, so I do not have to commit every time a new guest arrives. Of course I could just keep throwing away those changes, but it seems better not to have that information under version control in the first place.
As a rule of thumb, one should try to keep down the level of noise in version control. Less commits, more meaning.
So, when I read the word "template" what I understand is "a file that is not complete in and of itself, that consists of the data or formatting information that does NOT change, which can be combined with or instantiated with a particular bunch of information to quickly create a usable final file, along with some method for combining that information and creating the final file."
So...obviously I'm missing something. I would think a "feedback form" would be a template in the sense that it is to be filled out for any individual guest. And a filled out form would be an instance of that form that is filled out, and wouldn't go into version control.
@FaheemMitha it's easy to export to CSV, you'll just lose any formatting or special information.
@FaheemMitha It didn't make any sense. I was thinking that you were trying to avoid having the filled out form make it back into version control. Now I get it.
I mean, the name and length of stay, is part of the TeX file, just to be clear. I personalize it before giving it to them. If I wasn't doing that, there would be nothing to discuss.
@Wildcard That would be unnecessary and kind of batty. It's a very simple TeX file requiring a single TeX run. And committing before compiling would be a very poor workflow, in any case.
But then, it would seem the simple solution would be to just strip out that info again after generating the PDF, so you don't end up with it in version control.
I'm a big believer in clean commits. Though there is of course nothing wrong with creating temporary/scratch commits, as long as you clean up afterwards. Which is in large part what Evolve in Mercurial is about. BTW, did you ever watch that video?
@Wildcard I suggested the possibility above. It just felt kind of icky.
I just want to separate out the name and length of stay of the guest from the form, so I do not have to commit every time a new guest arrives. Of course I could just keep throwing away those changes, but it seems better not to have that information under version control in the first place.
I was thinking of using YAML, but I finally just went with moving the definition of the TeX macros to another file. As suggested by people in TeX chat. And which is certainly much simpler.
Unfortunately, in practice it's distressingly common for people to actually have a worse approach.
I guess they call that expediency.
I remember a former employer getting nasty about that. He wanted quick and dirty. Because there were deadlines. Except he didn't want to do any of the actual work himself. Creep.
@Wildcard I forget - are you actually a TeX user yourself?
@FaheemMitha yeah, one piece of advice I read early on in my career stuck with me. It warned that 90% or more of the code you will see in your lifetime is completely, laughably broken. And warned never to assume that some code is a good example of good practice and that it's just you who doesn't understand why it's brilliant.
@FaheemMitha not really. I've barely dabbled in it. I love the idea, but I haven't had the time or the reason to dig in fully.
@Wildcard Sounds like good advice. I've learned (at the school of hard knocks) to try not to take anything for granted. Though having to check everything all the time gets exhausting.
@Wildcard Well, it's very time-consuming. But you've probably figured that out already.
It's much worse than learning a "regular" programming language. Because it is anything but.
@FaheemMitha yeah. I had a "former life" in graphics design and printing, so I am very well versed in using InDesign.
Now as a programmer, I dislike the closed-source aspect; and I dislike the payment model (it's now only subscription based). But the product is REALLY slick.
But because I have experience with InDesign, trying to use Pages is just pure aggravation. There are too many missing features from a professional perspective.
@FaheemMitha my expectations and standards are too high. I'm used to a professional product that lets me focus on the work I want to do, and the "how" can be mastered well and then stays out of my way.
And I get the philosophy of TeX as being that you can focus on the content and not worry about the layout. But the advantage of WYSIWYG when you DO want to focus on the layout, is missed with that approach.
For example, if you're designing a newsletter, in InDesign, you can see how long the text blurb under a photo should be to fit with the overall design. And you can write it that size.
That sort of immediate interactiveness in manipulation of the visual appearance of a layout is, for me, one of InDesign's most attractive features.
And the fact that you can drag stuff where you want it visually rather than trying to translate your intention into written commands that the computer can translate back into a visual result.
Of course, now I'm talking more about Scribus-type features rather than pure typography.
None of this is a knock against TeX, by the way. It's just background on why I haven't gotten into it so much. I keep wishing it were something more than it is.
