Always be useful

One of the great joys of the internet is that no matter how obscure of an interest you have, there is normally a simple way to find people who likely share it.  What was once relegated to obscure books can now have a bbs and irc channel dedicated to them.  People from all over the world can learn from the collective experience of their peers, and share their own experiences with subjects that most people you may contact on a regular basis will not have even heard of.  It’s wonderful!

….except, when it isn’t.

With every group, regardless of how small or obscure, there is now an almost learned behavior to lean into elitism and polarized discussion.  I’ve read commentary on how this has developed over the last few years, but rather than quoting papers about the emergence of trolls (internet, not mythological), allow me to simply make a few short suggestions on how to keep criticism as productive as possible when it comes to the FOSS world.

1). All criticism should be centered around a need for improvement.  There is absolutely no benefit to having a huge discussion that revolves around an issue that doesn’t stand to improve on a project.  I would compare this to the overweight boxing fan who insults a fighter’s style, without the least bit of experience in the ring themselves.  If it’s a discussion for the sake of discussion, it will probably be avoided by the people who are actually working on making the project better.

2). If possible, provide both reasons and a working example to a potential change.  Let’s say that you’re looking over someone else’s script.  Saying “You use too many pipes” is not nearly as beneficial as “Here is how I would do the same thing <insert example>.  Doing this cuts the pipelines in half, which reduces resource usage significantly.”  If you can’t improve on the original, then most of the time your input would be better placed in bug tracking.

3). Context is important.  Some things that are shared are simply “Jumping off points” for ideas.  Not everything is a polished or finished product, and this is especially true for many bbs or irc examples.  Criticizing the formatting of something that starts with “Well, this is a pretty cool way to solve ____ issue,” is most certainly a waste of your time and the author’s, and everyone who will subsequently read it.  While you may get the satisfaction of patting yourself on the back for having such amazing syntax skills, it’s very possible that you’re just being a nuisance.  When it comes to a finished product, then you can and should make pull requests to the source tree over these subjects.  At this point, it isn’t criticism at all, but simply sharing the workload of the project for a better outcome.  The context in which the subject is brought up is the difference, and make sure that any criticism is in line with the subject’s goals.

4). Action is always more important than criticism.  This ties in with the example above, but it’s important to keep perspective on who it is that is doing the work.  Many authors and testers are doing whatever they can using their own time to provide free solutions to the public, and are not personally benefiting from their efforts at all.  While constructive criticism can be a good thing if directed correctly, it is hugely beneficial to take some of the load for implementing changes onto yourself.

5). Debate is a last result, and probably signals the end of any kind of possible benefit.  In all of the actionable cases, there is always the possibility that the author’s goals won’t align with yours.  This happens.  If you’ve provided reasons for change and workable changes, and the other side of the discussion is still adamantly opposed to them, then you can always fork the project to implement changes on your own branch.  The natural selection of code then becomes the defining factor on who was right.  Keep in mind that this may also mean that you will be providing support on the branch, implementing bugfixes, and generally maintaining a project.  If this is out of the question, then perhaps it’s best to make your point and move on.  Extended arguments very rarely change anyone’s mind, and simply serve as background noise to an otherwise productive project.

While I’m sure this doesn’t cover all aspects of criticism, I think that simply being really mindful of who is working on what project will generally be helpful to everyone who is out to provide genuine help.  To those who are out to criticize others just for the sake of being a critic, find a new hobby. 🙂

cli Kung-fu

“I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times.” – Bruce Lee

Every month or so, I’ll run across a need that I end up discovering is best served by some very simple tool that has been sitting around on my system without me truly understanding how to use it.  GNUcoreutils on a Linux system are probably the most common of these, and while I appreciate the learning process, this normally starts me down the long track of “So, just how much do I NOT know?”  The answer is that the more I learn, the more I realize that I fail to fully understand.

That bit of humble-pie aside, I am at least made more aware of what all CAN be done without the need for many additional tools to a native cli/tui environment.  This leads me to think about how much could be accomplished if I simply knew all of the tools and options for the most basic tools in the GNUcoreutils toolkit.  Really, the entirety of the Unix way is found not in the use of complex tools, but in mastering the simple ones and learning to chain them together in an elegant arrangement.  The beauty of any unix or unix-like system is in piping and shell, the power to control stdin/out/err and bend them to our wills.  So often we simply are out to reinvent the wheel simply because we failed to see that there was already a cart built that could fill our needs if only we knew how to make it work for us.

So, dear cli kung-fu masters in training, allow me to pose a challenge for those of you who wish to reach enlightenment on the path to the Unix-way.  Go to http://www.gnu.org/software/coreutils/manual/coreutils.html, and pick one tool.  Learn every single option and switch available for it, and play with options using it until you truly understand the depth of what is being offered.  I can almost assure you that you will learn something that you didn’t know previously, even if you’ve used the tool before.  I personally have found that with the use of pipes and tricks that I already know with stream editing, that I come up with new and different ways to do things.  These aren’t always “better” than how I might have done them otherwise, but nonetheless, I find my own knowledge increases with every new trick I learn.  While whatever I’m doing may not be the perfect scenario to need the new method, you can be assured that it will probably be exactly the method that you’ll need in some situation.

The master of cli is not the man who knows how to use 10,000 programs, but who can handle 10,000 cases with a single tool.

tech_worldview == clarity;

 

David said my pic was broke…this is probably more enjoyable anyhow.

If you spend any amount of time in any kind of open discussion regarding *nix or BSD type systems, you’re bound to run across *gasp* people with strong opinions.  For the most part, I don’t participate in things that don’t directly affect me or that don’t fit my particular ‘tech worldview’.  I would say that easily 98% of the strongly voiced opinions are due to either Parkinson’s Law of Triviality or Sayre’s Law, however you want to view it.  I’m sure that the term “bikeshedding” is nothing new to my BSD brothers and sisters, but there are a few points that I personally use subconsciously that will ultimately determine my views on any subject.

Simple > Complex

Given the option between 2 choices, the quickest and simplest implementation will be my generally preferred option.  Everything about most of the software that I use reflects this.  sc is a great example.  I don’t need libre office if all I’m doing is making a few numbers automatically have some arbitrary math done to them when I make changes to some other number.

Functional > Form

I USE software for a specific purpose, pretty much every time.  I’d much rather have a predictable piece of software that works than a beautifully constructed piece of art that doesn’t do what I need out of it.  When there is the possibility of making something both functional and nice to look upon, then that’s going to be my choice.

Semantics > Syntax

This is the one where I guess I must differ from a lot of people.  I have more respect for creative and useful programs (and their programmers) than a someone who makes a well-constructed house of uselessness.  I’m not saying that obfuscation is good, not by any means.  Rather, it annoys me to no end when someone shares something that they’ve done that is a proof-of-concept or neat tool they’ve made, and then the first response is in regards to the format in which it was written.  Creativity in programming is the big hurdle, and that’s where I’d personally like to see more emphasis.  I assure you, there will be no lack of time for people to fix your indentation, and there will be no lack of volunteers if the project is actually worth having.

Context Matters

While I’m all about doing the most with the least, it would be totally unreasonable for me to expect someone who is working on projects with webgl to be using links2 or w3m.  ed is so inefficient for me that it would grind my work to a screeching halt.  Obviously, it can be used for huge projects, but it’s not worth the effort to swap to something I find drastically harder to deal with just for the sake of “being minimal.”

So, when the discussion inevitably swings around to “What’s your thought on ____ init?”  I will either go on a horrible rampage about how sick I am of this particular topic, or I’ll look at the things that I consider my few clear points and ask the great question: “Does it init?“

emacs-lisp quick-hacks

 

…that’s just cool.

 

As I’ve mentioned previously, and will probably do so again, I am an avid (rabid) emacs user.  When I’m setting up a new *nix system, it will be one of the first things that I put on, as I am accustomed to using it.  That being said, despite having all of the fantastically complex init files and loadable foobar.el options that I may have, some times I end up saying, “You know, it sure would be cool if I didn’t have to repeat this same action over and over.”

Let’s use a metaphorical situation that might warrant this.  Let’s assume we’re looking over and proofreading someone else’s poorly written C coding (as opposed to my own poorly written C), and I want to call attention politely to certain lines in a commit.  I’d like for it to always appear as a properly commented code function, be tied to a single button press (we’re assuming that this will need to be repeated quite often), and return the cursor to the previous position.  I’m going to go out on a limb and assume this isn’t the kind of action that we’ll be performing so often that it needs to be a permanent function, so rather than put it in our init, we can simply pop over to a *scratch* buffer, write out something short to make…oh, let’s use “F12″…print out our friendly comment, and then evaluate it for use in only this session.

(defun whattheflip ()
 "make automatic comment"
  (interactive)
  (save-excursion
    (goto-char (line-end-position)) 
    (insert "\n /*^^^wtf is this? It's horrible!!!*/ \n")
    ))
(global-set-key [f12] 'whattheflip)

Now, a couple of C^j’s later, we can flip back over to the code we’re proofreading and every time we press our F12 button, we get an automatic comment inserted on the next line that should hopefully serve as a friendly notice to our beloved teammate that we aren’t 100% clear as to why they’ve chosen to do something in a particular manner.

While this exact use may not perfectly suit your needs, I’ve often found that it’s the ideas that serve us better than the exact application.  For those interested in other cool hacks, I’d at least check out http://ergoemacs.org/emacs/elisp.html for other quick uses for emacs-lisp in text processing.

With enough shell, everything is automatic

…sid test system x86_64, 257MB of updates behind…

I guess I’ll write something while I wait to see what broke.

While I am by no means a fantastic shell/bash script writer, I will readily admit that I spend a good deal of time playing with creative use of shell scripting.  Scripting in general has been the biggest blessing and curse of my life in userland.  I’ll also readily admit that 90% of the time, I use it to shortcut things that I do on a regular basis.  “Man, instead of me having to set up a 2nd workspace and open the same 3 programs I’m always using in tmux…I could totally make a script for that.”  I would say that this is the lazy man’s path, but I’ve yet to quantify the amount of time saved over the amount of time it takes me to write them.  Could be I’m adding extra work, but that’s not really the point anyhow.

When it starts to get cool is when these little scripts start growing.  “Well, I’d like for this pane to be links2, unless I’ve failed to set up an internet connection, in which case…it should open a second workspace with ceni opened.”  30 minutes later, I’ve now saved no time at all but have managed to run a short ping test to determine which of the two paths should be followed.

Essentially, this is ‘bloat’.  This is MY bloat, though, and I certainly am not forcing it upon anyone else.  I have tons of emacs-lisp bloat too, but it’s all designed to accommodate MY use.  Saving a few hundred keystrokes and possible RSI (emacs and vim users can both laugh here) over the course of my regular use.

As my understanding of shell scripting improves, I find that there is practically no end to how much control the user has over their system with creative use of shell.  I don’t know that it’s necessary, and I’m not interested in debating the merits of one form of scripting over another.  What I would suggest, is that if you’ve failed to do so, write a script that would be useless to anyone except you.  Assuming that you use a floating wm in X, then write one that opens a series of frames with your favorite programs open in them using perfectly balanced geometry.  If you use a terminal multiplexer, then write a script to lay out your most common working environment.  The point is not the specifics, but rather that once you start to use it, that you’ll begin to have little creative ideas about how you could make it slightly more efficient (or, at least I have these thoughts, and so I assume everyone else will.)

As you begin to implement little tweaks, you’ll run into snags and setbacks where things don’t work “quite” like you meant for them to.  This is expected, and in the end, while your application of scripting may not be useful…your ability to control variables on your own personal system and to troubleshoot will drastically improve.  I’m sure there are scripting pros out there that don’t need any of this, and that’s cool…you guys just keep doing what you do.  For the rest of us, practice leads to consistent improvement.