chousuke · HackerTrans

What does it hurt to tell someone about a feature they could be using, especially if you're mentoring? If they don't want to, they'll tell you and that's fine, but they need to be aware of it in the first place to make that choice, and the assumption that other people know the same things as you is often wrong.

chousuke

há 5 anosdiscuss

I think when you begin to work on something, there's the phase where you are "stuck" and need understand the problem well enough to generate an acceptable initial idea to get started. To me, this is the draining part. However, once I have that understanding and can start exploring it, I can easily work for hours; it still requires mental energy and is still draining if I go overboard and don't stop in time, but it's not the soul-crushing kind that being stuck on a problem can be.

chousuke

há 5 anosdiscuss

Ansible and Puppet are tools that do very different things. I mostly agree with you, but Ansible does work decently as an orchestrator.

You want to use tools like Puppet and Terraform to define the state of your systems, and Ansible to run operations on those systems, because not everything is stateless; trying to upgrade a database with Puppet or Terraform will be painful, but Ansible won't have trouble.

I do wish it had static typing (Puppet took 4 major releases to finally get it and its type system is its best feature over alternatives) and less YAML, but it is what it is...

chousuke

há 5 anosdiscuss

I'm of the opinion that you should commit WIP stuff. Use the SCM for managing your source code, damn it!

Just don't publish WIP crap; fortunately, you can have your cake and eat it too, with git.

The biggest reason git (and any similarly advanced SCM) is superior to non-distributed alternatives like Subversion is that I can use it to manage my own workflow, instead of just as the final off-site backup of whatever I decide to publish. I get to actually use everything git offers for shuffling commits and code around while coding.

Want to switch contexts quickly? git commit the whole thing and just switch a branch.

How about untangling a hairy merge? Do it piecemeal and commit when you're done with each bit; it's trivial to then undo mistakes, redo, combine or reorder stuff and you cannot lose any work by accident because git commits are immutable.

All of these features essentially require history rewriting; sure, you're free to rebrand and not call "store WIP state in repository" a commit even though it is one, but I would consider any SCM without these features nigh useless for most work.

chousuke

há 5 anosdiscuss

Typo commits and the usual iteration during development isn't "accurate history". Noise in commit logs provides negative value.

Ideally, each commit should be something that you could submit as a stand-alone patch to a mailing list; whether it's a single commit that was perfect from the get-go or fifty that you had to re-order and rewrite twenty times does not matter at all; the final commit message should contain any necessary background information.

It would be needlessly restrictive to prevent users from making intermediate commits if that helps their workflow: I want to be able to use my source-code management tool locally in whichever way I please and what you see publicly does not need to have to have anything to do with my local workflow. Thus, being able to "rewrite history" is a necessary feature.

chousuke

há 5 anosdiscuss

If strings are always unambiquously detectable, why allow quoting them at all? Having two representations for the same data means you can't normalize a document unambiguously. I can understand having barewords seems cleaner for things like map keys, but I am not convinced that it's a worthwhile tradeoff.

An important feature of RFC2119 keywords is that they're always capitalized (ie. the keyword is "MUST", not "Must", or "must"). This makes requirements and recommendations stand out amid explanatory text, improving legibility. For example, RFC2119 itself uses MUST and must with different meanings.

chousuke

há 5 anosdiscuss

I'm skimming through the human readable spec, and it seems decent, but I noticed the spec allows unquoted strings. What's the reasoning for this? In my experience unquoted strings cause nothing but trouble, and are confusing to humans who may interpret them as keywords.

Any reason for not using RFC2119 keywords in the spec? Using them should make the spec easier to read.

chousuke

há 5 anosdiscuss

Right, and nothing prevents you from writing a compositor that talks to an external process to handle window management. It just happens that no-one does it, because it's insane and difficult to make work properly. The compositor's job literally is to juggle the clients' buffers, which includes deciding what gets drawn on the screen and how.

There are other processes involved though where the compositor and the client do talk the Wayland protocol via IPC, such that the compositor hands off various responsibilities to external processes.

As far as I understand, X11 ended up with the window manager architecture pretty much by accident; initially, window managers didn't even exist.

chousuke

há 6 anosdiscuss

I think PostgreSQL actually is a bit of an odd one in that it relies on the OS to do proper caching of whatever data is read from disk. It has its own buffers for various things, but I'm pretty sure it doesn't (yet) implement its own disk cache.

comments