In 2006, the term sparkline itself was introduced by Edward Tufte for "small, high resolution graphics embedded [inline] in a context of words, numbers, images". Tufte described sparklines as "data-intense, design-simple, word-sized graphics".
See the Usage section for an example.
EDIT: A closer look revealed that it had indeed an unusual license just 22 days ago. It's GPL v3.0 now.
That makes it really not that portable.
Now to contrast this with GUIs, even the simplest things would require me to jump through menus, type some stuff, etc. Everything in the command line is precise and repetitive steps are easy to replicate.
Piping is another aspect that the command line enables, which basically feeds to output of one command into another. One common example of this is to look at lines of a log file that contain a certain set of words: `cat log.txt | grep "[ERROR]"`.
But perhaps the strongest selling point of working in the command line is consistency among tools. If you want to be productive as a developer, use of various tools for doing various tasks is common. Using the CLI for all these tools keep everything a few commands away, even interoperability is enabled seamlessly due to piping and consistency.
So yes, there is a fairly steep learning curve, but in my opinion learning how to use CLI tools over GUI is well-worth the hassle.
Isn't this.... not true? A lot of the *nix commands have strong consistency, yes, but there are many commands that are just designed poorly and you can't easily pipe them. And what about widely used tools like Google Docs? How could that have a consistent interface in a terminal?
Not all software is suited for the terminal, that should be obvious. Like you would not want to play a graphically intensive game on the terminal because... graphics.
Since you brought it up, what use-case do you have with piping Google docs exactly?
> Not all software is suited for the terminal, that should be obvious
Like wtfutil, the very thing that's linked here on HN???
> Like wtfutil, the very thing that's linked here on HN???
IMO the only significance of it running in the terminal is that you can assume it's reasonably performant without digging into comments to see if people are saying 'Cool but Oh God, Electron?'.
If I were creating it, I would be choosing between Electron and ncurses-wrapping library for whatever language I wanted to use. Then I'd choose the ncurses-wrapping library, because, well Oh God Electron.
Sure, it could be a native GUI, but then I'd have to learn about that for every platform I wanted to release on.
Sure, it could be Qt or GTK, but I've only used them once each briefly and in anger, and again, no desire to learn.
Point is it doesn't need to be in the terminal because no you're not going to feed stuff in and redirect its output, but it certainly does it no harm, and the terminal's an easy development target.
> I mainly brought up Google Docs because it's something that many of us use that breaks us from "living in the terminal". Someone who "lives in the terminal" would want all of Google Doc's functionality, but in a terminal.
People who live in the terminal does not literally mean that they spend 100% of their time on the terminal fyi. I doubt anyone does in this day and age, I was under the impression that that fact was implied.
That being said, there are definitely major productivity features to be had with GUIs, such as those with web browsers and IDEs.
I think the purpose of a dashboard is not to give you detailed interactions, but to let you know the status and you can take actions outside the dashboard as you like.
Moreover, not so sure about this application but you can always have key shortcuts to take you to run a default task for one of the sections of the dashboard. Hence, imo, there is no real loss of functionality here.
-> take an almost-CSV report generated by one piece of software, remove a bunch of extra garbage at the top to turn it into an actual CSV file, then send the CSV file to data analysis pipeline.
-> join two CSV files selecting columns 2,3 from one file and 4,5 from the other file, keyed on column 1 from both files. like excel but for CSV files sized in hundreds of megabytes
-> take a bunch of CSV files and pump them into a rabbitmq queue
-> query whether a queue is empty. if so, start a new analysis job. if not, sleep another hour
-> grep for data in a directory to find specific files containing that data, then point those paths to another service
I can go on all day. CLI tools are far more wieldy than GUI tools IMO. CLI tools give me a generally-stable interface (or at the very least, a straightforward method of parsing and adapting to changes) and usually have _way_ better documentation than GUIs.
1st I setup a script to start an emulator (iOS and Android), build and deploy an app to emus, start development JS server, open vim and split the window to have a terminal ready for anything else.
2nd I automated asset creation when I receive SVG from design - it automatically generates 3 different asset sizes (as required by iOS), compresses them, moves them and names them correctly.
That's just the beginning...
Key elements of a decent shell tool are varables, pipes, loops, logic, and parameters.
This ranges from the bog-simple (an xmessage "tea timer" that pops up a reminder after a few minutes to tell me my tea is steeped), to complex scripts.
Things I've run from a shell include downloading and analysing 50,000 G+ profiles for most recent activity, literally a "bash on-liner", as described here:
Resizing or modifying images via Imagemagick (scales to however much time and disk space you have), converting files from one format to another, generating lists of stuff for further analysis or conversion, updating a whole slew of documents in one fell swoop, creating and listening to playlists of local or remote content with mpv.
You've got a ton of small, simple tools which can be combined flexibly in virtually any way you want. That's a lot of power.
For me the terminal is mostly used for these things:
1) A stable/reproducible Linux environment in which to test and run code.
2) A place to use UNIX tools to quickly do things that would take a long time, or maybe not be possible, in my (fairly large) collection of GUI apps. In particular one-off searching and manipulation of text files, log streams, etc.
Plus if I want to make small edits to a file, I can do this faster in vim than in TextMate or Sublime. And I sometimes run apps like "calc" in my terminal out of habit. YMMV on that kind of stuff, but for the two reasons above, if you are a developer of server software then this is much of your life.
I prefer to use GUI apps for some things, but I totally get it that others don't. Once you're at home in the terminal, it's tempting to want everything to live there. But if you're like me and prefer a GUI client for source control, you can easily have both!
Possible to create tools for use on small systems -- your DSL/Cable modem, say, which is really Just Another Linux Box, though with tiny capacity.
Smaller VMs -- less system load, more available, greater flexibility.
Run a shell on your Android or iOS device. Full power of the shell, scripting, and development tools.
You can do more of whatever it is you want, faster, using less. It's an efficiency thing.
(if this sounds far-fetched, try reading a book with a different font for each paragraph for 4 hours)
Faster interaction: no dreaded mouse needed.
UI speed: terminal application are rarely slow at it.
Consistency: Works on local and remote hosts over SSH.
I also appreciate the resource usage. My personal laptop is a Lenovo from 2009, and it never feels slow. It is slow for some things, like compilation, but it never feels laggy in the way a GUI can.
I would never recommend to anyone that they go down this road. It's silly to think how many hours I spent learning what I know, and the main effect is that nobody but me can use my computer and I barely know how to work anyone else's. I'm wicked fast on VIM and that looks cool and all but... the bells and whistles in something like VS Code probably help more in the day-to-day as a developer. But I can't use it. I feel completely lost when I can't Control-Z and git grep, or whatever. I don't even know how to quit a GUI programme anymore.
My wrist joint have a tendency to crack loudly (not sure if this is the correct English term), which feels unpleasant and have been a driving reason for me personally to avoid the mouse unless absolutely necessary. Additionally to basically living in my terminal I use vim bindings in my browsers and replaced my caps-lock with the Hyper-modifier* allowing me to control almost all parts of the operating system from my keyboard and mostly from my home row.
This is it for me, really. Whilst it makes it me two or three orders of magnitude slower when I have to "drive" someone else's machine, not having to switch to a mouse/trackpad really just smoothes things over and prevents jumping me outside of my "zone".
Depending on when and how a person started out with computers, there may have been no GUI available. My university was just getting connected to the internet about a year or so before the the web came into being. I picked up a VT125 terminal and a 1200 baud modem from ham radio flea markets, and used that setup over dialup for a couple years. No GUI, all text; programming assignments, email, web in a text browser when that was a thing, NNTP.
I use tmux (wrapped in byobu) a lot and tend to end up with one screen (on each host I usual a fair amount) as a dashboard like this, manually constructed from many panes each running a tool like iftop, watching a log with "tail -f", or regularly running other checks via "watch", ...
Took me a night of work to get it right but it ran on a monitor in our engineering area, and one Quality/Ops peoples desktops for years.
$ uname -a
Linux hostname 5.2.9-arch1-1-ARCH #1 SMP PREEMPT Fri Aug 16 16:24:43 UTC 2019 x86_64 GNU/Linux
$ git clone https://github.com/wtfutil/wtf
$ cd wtf
Yikes! Hold my beer! This will take all weekend.
There are some other languages that have similar benefits, but go is the most popular and trendy. Rust could fill a similar niche but GC is very nice and Rust definitely has a higher learning curve.
You can easily statically link most languages by passing switches to the linker.
Python like simplicity is a far stretch. Golang basically just C with co routines and some of the annoying syntax cleaned up.
Your last sentence, to me, reads as a pro rather than a con. C + coroutines - bad_syntax = Great language to me.
Mind you, I don't use Go in a professional setting, so take what I say with a grain of salt.
The terminal size in cool-retro-term is around 30x140-ish.
On my MacBook Pro's built-in display, it looks like this: https://imgur.com/BbVcyA7
One of my favorite clock related features is in KMail where it says "Senders current time", which is often helpful as well.
After a while you memorize the time zone differences. But to be sure and take daylight savings in account world clocks are not bad.
For a desktop project, supporting the OS of 60+% of desktops would seem a boon to adoption (putting aside the politics and all).
Aaaand confirmed on the glossary page. I mean couldn't it have been something clever like "Wednesday Thursday Friday" ?
But this is a cool idea. Issue #546 has been opened for this.
The background of the borders matches my terminal while I can't get the background of the widgets to match because of this.
EDIT: Hah, specifying "transparent" makes it work
...anyways, moving on with my life...
However, you run this thing as ./wtfutil though if i look at the documentation, so no worries on the package name in the cmdline really.
Edit: Come to think of it, if it's on my device, it's already saved in some way, shape and form. Clearly nobody technical at that company made that decision to sue Google.
What Google should of done is offered to advertise that an image is available to purchase...
Unfortunately the law often does not make objective sense. And even when it seems to from your perspective, the way others interpret it does not.
> nobody technical at that company made that decision to sue
Technical people can be arseholes too you know. Many patent trolls are technical people, not just legal eagles, for instance.
This isn't about the law. It's unclear if the law would require something like this or not. Google decided not to find out by settling. The settlement terms were up to the two companies to decide and were not mandated by laws.
Either that or deliberate user filtering: if you can't figure out right-click (or long press) then "open in new tab" on your own, then maybe you are not the class of user the creator wants to support :-).
I doubt the inconvenience is deliberate, more a side effect of some other design consideration. There are smaller images on each of the widget description pages (though they also scale oddly in places) which in total provide more detail than that one image. Perhaps drop the author a polite message suggesting that they include a "view full image" link near the screenshot on the opening page or with the image itself as the mouse target?
And why do they disable native scrolling? Apple spent hundreds of man hours to get scrolling just right in iOS, why override the OS?
You can't even scroll the page if it has a code block on it.
On Android there is a setting to always enable zoom.
That's doesn't excuse it, of course.
I think it's boilerplate that ends up pasted into a lot of websites.
It's a good thing when the makers of a browser actually care about the user.
Still doesn't fix the stretching of the image...
Do you mean you can't zoom the image or do you mean you can't zoom the site?
And on what combination of device, os, and browser can you not zoom the image/site?
On Firefox on Linux on my laptop I can ctrl+scroll wheel to zoom in and out of the site, or right-click on the image and select `view image` from the context-sensitive menu which opens the image in another tab and from there the cursor becomes a magnifying glass.
We understand you don't need to contribute anything to enjoy this comments section and therefore we do truly appreciate that you've found enough value to contribute to this endeavor!
...your source is open? Yeah, probably.
Sure, they invested time and money into into it, but they have a JOB which should pay their rent.
Pretty rude for them to ask the audience to contribute back.