This is interesting. Somehow I missed this, using setup.cfg make much more sense than putting everything into python code. I wonder if pip-tools will allow compiling install_requires and test_requires in setup.cfg into nice requirements.txt and dev-requirements.txt without too much magic...
Much more for what? In this context, "lockfile" means a file listing all your project dependencies with exact versions pinned. (Not semaphore-files or anything like that. It's not even a python-specific term, e.g. npm uses package-lock.json for the same purpose.) The need for something to store all dependencies with exact versions pinned exists in any language and infrastructure, are there any better solutions than store them in a file? Files are nice, they are VCS-friendly and everything.
> We could have built a tool to manipulate `requirements.txt` files
There's pip-compile from https://pypi.org/project/pip-tools/ that does exactly that. Pipenv uses its resolving mechanism if I'm not mistaken. It produces standard req.txt file with versions pinned and supports separate dev requirements. It had some bug with upgrades last time I checked though, not sure whether it's resolved, currently considering using it for projects at work.
Have used pip-tools for a long time... its very uncomplicated and just makes things pretty darn simple.
Since its all just requirements files with pip-tools, its been fairly commitment free, in that I haven't had to substantially rework any major bits of workflow to use it - nor would I to remove it. Not sure I could say the same thing about pipenv and/or poetry.
Not just maths. It can be used to typeset books on any topics quite well, I did it for while a few years back. Text format makes it easy to convert any sources to it, and if you don't need many formulae nor tables/figures typesetting becomes pretty trivial. And unlike visual typesetting tools you almost can make an error of moving some guide too far or something, if you say 10mm margin it'll be a 10mm margin (visual tools have their use, I guess, just not when you're a geek and prefers to see code and not a picture). And it even warns you about underfilling/overfilling, what's not to love?
And speaking of word/openoffice/google docs. Those are text processing tools, not typesetting ones. If you need typesetting on any complexity their are the absolute worst choice. If your CV has a very simple structure and style, on the other hand, sure, go ahead.
I wonder if any tech recruiters notice this kind of things... If I wanted to hire nerds, I'd surely notice. CV made in word, marked with "not geek enough" :)
I wanted to make something like for a while. I'd use a reportlab-based generator though and Jinja2 templates. Ideally, I want something that can generate both compliant and optimized HTML and a PDF, while having easily hackable style sheets and stuff. I'd add just a little bit of Python code to make it easy to add new stuff (new skills, new experience, etc.) and generate CVs with different highlights from the same data and templates (I used to have one for my primary stuff, one concentrating on devops stuff, one for immigration purposes, and yet another one for something I don't remember — it's hard to keep them all up to date when you mostly use just one).
Would be a cool project one day, for now I'll just keep using LaTeX.
I've moved past ModernCV though. Too many people are using it nowadays :)
I disagree. I never really used anything but LaTeX/XeLaTeX to generate my CVs but I've seen what people make in text processors and it usually sucks. On the other hand, I agree, open source templates are rarely the best — and unless they are very generic I'd suggest not to use them verbatim. You don't want your CV to look like the other 50 in the pile (yet you don't want it to look too weird either).
Yep, if you're a cute almost 30 dude with 20-ish looks applying, say, to a CTO position in a startup otherwise consisting of college kids... AKA my situation except I'm not looking right now. Yeah, I'd say there are situations when being judged by your looks gives you an advantage. That said, I didn't hunt a job for a long while and almost never in the Western countries (sending your CV to places that offer visa/relocation and never getting contacted doesn't really count) so maybe I don't know some local specifics, don't quote me on this.
What about actual punch cards? Maybe not the most efficient given the lack of equipment but should not be harder to print or punch than QR. And standards were around for much longer than QR or DM so you can be sure to find some designs online or in a library if you lose all of of your equipment in 10-50 years (and they can always be scanned or read by eye if everything else fails). I'm looking for a simple design for a RS232 puncher, preferably one that would support some non-biodegradable plastic cards (they say PET bottles do not degrade in centuries, ain't that a perfect backup material?) But even paper cards should be more durable than anything printed on laser printer.
Using IBM 80-column cards you'd need just about 10 cards to store a 4096-bit key with three subkeys in binary mode. More if using char mode (might be preferred if you have to type them using keyboard). The key can be condensed for backup if needed. OTP and/or Shamir's method could be added to the mix to improve security, increasing the number of cards required, but even without Shamir you can split the deck in half and store in different places.
Longer, possibly foldable, punch tape is yet another option. If it has the same width as IBM 80-column cards then most of DYI equipment designed for the latter can still be used. It can't be metal though, only paper or plastic.
A bit of obscurity helps too, it's not like a deck of cards screams "this is an important secret" or possible attackers have card scanners with them when they invade your backup facility (although they can make photos and decipher them later so it's not real protection, just a small bonus.)
Now, how would we solve a problem of rubber-hose cryptoanalysis with it?
