12 Matching Annotations
  1. Last 7 days
    1. Then when giving answers I'm even less certain. For example I see occasional how-to questions which (IMO) are ridiculously complex in bash, awk, sed, etc. but trivial in python, (<10 lines, no non-standard libraries). On such questions I wait and see if other answers are forthcoming. But if they get no answers, I'm not sure if I should give my 10 lines of python or not.
    2. I went against the grain, applying other tools that people have written over the years to directly perform the job at hand which do not involve entering a program for awk or a shell to run, with answers like https://unix.stackexchange.com/a/574309/5132 and https://unix.stackexchange.com/a/578242/5132 . Others have done similar. https://unix.stackexchange.com/a/584274/5132 and https://unix.stackexchange.com/a/569600/5132 are (for examples) answers that show alternative tools to answers employing shell script and (yet again) awk programs, namely John A. Kunze's jot and rs (reshape), which have been around since 4.2BSD for goodness' sake!
    3. There is an observable widespread tendency to give an awk answer to almost everything, but that should not be inferred as a rule to be followed, and if there's (say) a Python answer that involves less programming then surely that is quite on point as an answer for a readership of users.
    1. Java may have been designed as a completely object oriented language, but when Java SE 8 was released in 2014, it added Lambda expressions (aka closures), which added some functional programming elements. Not every problem is best served by OOP, and by adding Lambdas, Java became more flexible. 
    1. Ruby has some really nice libraries for working with linked data. These libraries allow you to work with the data in both a graph and resource-oriented fashion, allowing a developer to use the techniques that best suit his or her use cases and skills.
  2. Jun 2020
  3. May 2020
    1. What I think we're lacking is proper tooling, or at least the knowledge of it. I don't know what most people use to write Git commits, but concepts like interactive staging, rebasing, squashing, and fixup commits are very daunting with Git on the CLI, unless you know really well what you're doing. We should do a better job at learning people how to use tools like Git Tower (to give just one example) to rewrite Git history, and to produce nice Git commits.
  4. Apr 2020
    1. IDEs and standard *nix tools like sed can help, but you typically have to make a trade-off between introducing errors and introducing tedium.
  5. Mar 2020
    1. There is no system that is equally well-suited to significantly different scenarios.
    2. The higher the load on the system, the more important it is to customize the system set up to match the requirements of the usage scenario, and the more fine grained this customization becomes. There is no system that is equally well-suited to significantly different scenarios. If a system is adaptable to a wide set of scenarios, under a high load, the system will handle all the scenarios equally poorly, or will work well for just one or few of possible scenarios.
    1. Rather than using NFS for this task, use explicit data duplication, via one of the long-established mechanisms designed for this purpose.
    1. This makes it easy to use Markdown to write about HTML code. (As opposed to raw HTML, which is a terrible format for writing about HTML syntax, because every single < and & in your example code needs to be escaped.)