DEV Community: Den McHenry

Favicons in root with Eleventy

Den McHenry — Sun, 08 May 2022 03:34:00 +0000

It occured to me after fiddling around with nonsense and making silly mistakes all day that the cleanest way to keep favicon files together and away from my main image folder would be to put them into their own directory and pass the contents of that directory to root.

Whenever I decide to change my favicon, I can clear out the local directory and replace its contents with the new files, and won't have to worry about things like losing track of files in my image directory or cluttering the main directory in my local repo.

You choose which directories and files to pass through as is within the module.exports in your eleventy.js file. You likely already have a few lines like this for things like the "img" and "css" directories.

Here's a quick and dirty run down of how they work.

Examples:

Pass the /img/ directory through: eleventyConfig.addPassthroughCopy("img")
Pass a specific file through: eleventyConfig.addPassthroughCopy("img/favicon.ico")
Pass something through to a different location: eleventyConfig.addPassthroughCopy({ "favicon" : "/" } );

This last example takes an object rather than a string and passes the contents of the source directory through to a different destination directory, in this case to root. The "favicon" directory will not appear on the live site, but its contents will be copied to the root directory, which is exactly what I wanted.

Eternal Recurrence

Den McHenry — Thu, 16 Apr 2020 04:57:47 +0000

Sometimes you start a new thing and fumble something silly and want to hide under a rock. But trying to hide under a rock would make you look even sillier, and soon you can laugh at your mistakes and take pride in learning from them.

Sometimes you spend a quarter century noodling with the web and then, just like that, you go blank writing an at-rule you’ve written countless times before, like @font-face. You put a URL directly after the src attribute without passing it as an argument to the url() function.

You fool. You absolute rube.

You look it up, hate yourself, and are very, very glad that no one is watching.

You’re so paranoid you lift the rock to see if anyone’s there.

Or you try to write a media query by typing @media-query instead of @media, and then you want to fall off a cliff into an endless void and fade into the fabric of the universe, forgetting yourself and every mistake you’ve ever made.

You want to become like water and seep into the earth or evaporate into the air, drift off into the clouds, rain down on the remotest spot on the planet, never be seen again, and just rest undisturbed, unknown, unable to disappoint yourself or anyone else ever again till the sun swallows this rock and the rest of the solar system and finally burns out.

But then you get over it and live to code another day. And to fail again in the same inconceivable ways. Even when you’re supposed to be an experienced professional.

Especially then.

Scratch that Itch

Den McHenry — Sun, 09 Jun 2019 05:07:09 +0000

I've never wanted to push my kids into doing things, and especially not to do them the way that I do. I've always drawn, but I don't want to give my kids tutorials in how to draw 'the right way' or in my style.

I want them to have fun, and to figure things out, and if they want to do something, to learn it organically. I think that if they develop skills in this way, they'll have a deeper, more meaningful connection to their craft, and a sense of the 'why' that they might lack if I were to push any kind of a 'how' on them.

Limits and Creativity

Recently, my eight year old had less fun than you might expect in a school assignment about turning a book he's read into a breakfast cereal. This is about creativity, right? Have fun with it! But without a little framework to build on, it's difficult to be creative. There are too many possibilities, no hooks to hang your hat on. I broke down and did something I should have a long time ago, and we sat together at the drawing table.

In order to be creative, you need to have the freedom to make creative choices. In the same way that we all get too overwhelmed with everything from paying bills to planning meals for the family, you can set out to create something and sit frozen forever by endless considerations like medium, subject, and on and on.

This is why people often rely on prompts, or even why I often rely on irony and self-deprecation when I do my white board drawings at work. Anything can be a frame that limits enough of the external concerns that within this small, focused area, the ideas flow and take shape.

Trust the Algorithms

I showed my son some fun cereal boxes, and broke out the tried and true rule of thirds, and some common cropping techniques (e.g., don't show the whole bowl: let it sit mostly out of frame, and zoom in tight to show the details). We talked about how this or that design had a sense of movement or excitement based on simple principles, essentially common design algorithms that allow you to quickly put together a pleasing and familiar layout and focus on the details.

In no time, he pushed me aside and said he had an idea. A frustrating and tedious effort turned into a fun design.

Of course, algorithms aren't universals or hard and fast rules. You don't have to use the "rule" of thirds, but it's amazing how applying a simple tool like that can open things and free you to start making creative choices.

The Art of Code

It felt like a big win, and I decided to take that tack because of something that had recently happened while he was struggling with a problem on Scratch, MIT's awesome coding community aimed at kids.

What's most interesting to me about Scratch is that he's kind doing what I did when I was younger, either as a kid trying to figure out B.A.S.I.C. in the '80s or later as a young adult, viewing source in the '90s and learning how the web worked. He remixes a project, say a game that someone else has made — something from an older, more experienced, more savvy programmer — and he learns by building on that.

In this case, it was a little more complex than he was used to, with an NPC being generated by some action, and then removed upon another action. How do you add a new enemy when this one is defeated?

The details are less important than the principles. As he went back to the code and made tweaks, and failed to see the expected result, he grew more and more frustrated. This, too, was familiar. We've all been there, playing the game of tinkering till it works. But it's a dangerous game, and rarely actually works.

So now, instead of building on what's there, what he needed was to work out how to duplicate functionality as needed, and how to debug what's gone wrong.

At first, the code he added had no effect, and after asking him about the the specific actions that triggered various results, and the conditions under which certain things occurred, he was able to think through and locate the code that controlled the NPC and its appearance.

Well, not quite its appearance. But we were close. See, the NPC was definitely there, only we couldn’t physically see it. We could hear its sword, and our character took damage, but we just flat couldn’t see it. It was invisible.

Back to the code, and back to more questions about the conditions under which this or that happened helped my son to see where a costume was changed or the opacity of the sprite was set.

Before long, with a little guidance on thinking through the logic of the program rather than tinkering directly with the code, he was able to take a single enemy demo and turn it into a game with 14 levels of enemy combatants. (I might have gone with 3 to start, but he set it at 14, and I wasn't going to argue.)

I didn’t write any code for him, but stepped in with some very basic debugging knowledge to lighten his load and let him find the answers. It was incredibly rewarding for both of us, and it never approached a rote lesson in “how to code.” It was just a nudge in the right direction, and some boundaries that gave him the freedom to escape anxiety, find his way, and get back to the fun of making things.

I think an important lesson is that you have greater freedom to be creative and to learn when you have senior people around you who can clear away obstacles, put things in context, and nudge you in the right directions. This is true for kids, and it's true for junior developers. No one needs to reinvent the wheel or suffer in silence. But keep in mind that people don't always know which questions to ask, or what's in their way.

It's up to you to keep an eye out, and lend a hand where you can.

Build Your Own TACO

Den McHenry — Sun, 19 May 2019 17:46:57 +0000

I won't be so presumptuous as to say that this is information architecture without tears, for non-specialists, made-easy, and certainly not "for Dummies." (I've never liked that phrase, and don't think it's helpful.) This is more or less a simple model for myself to get closer to feeling comfortable with information architecture — an inroad to the discipline that doesn't pretend to say anything new. But I hope it says something useful in a memorable way, and helps someone else to start making progress on organizing information. It's helping me.

So without further ado, how to build your own T.A.C.O.

I'm currently tasked with working on wireframes for a student portal to replace an ancient system that was pieced together over many years, often with little to no user input. We've recently had a series of discussions with various stakeholders, and ended up with a sort of master list of things that matter to different groups and for different populations. Now the hard part begins: how do you organize that in a meaningful, usable way?

You may have heard of Richard Saul Wurman's LATCH mnemonic for organizing information, limiting available models to location, alphabet, time, categories, and hierarchy: L.A.T.C.H.

For my purposes, I've come up with just four things to focus on instead of five. I give you T.A.C.O.:

theme
audience
convenience
order

TACO addresses the four most important things about how your information relates to the people who access it:

What's it about?
Who's it for?
What do they want to do?
How can they make sense of it?

We start with the contours and end with the details, where LATCH treats them all sort of indiscriminately in an attempt to reduce anxiety, which kind of causes me some anxiety.

THEME

Theme is the broadest category and is highly contextual. It could be a department within an organization, a category used to group news items topically, an academic subject, or just about anything you can imagine as a unifying mental model. For this reason, it can have great overlap with other ways of organizing, and is best suited at the highest level.

Examples:

category
department
question
topic

AUDIENCE

Audience is often overlooked. How do you organize your information for an internal vs. an external audience, for beginners vs. experts, students vs. teachers? It can seem at times like a subset of either Theme or Convenience, but at its base, it may be the first consideration in organizing your information, sitting at the literal interface of your data and the people accessing it. It's up to you and your requirements whether it sits above topical organization or acts as a filter below, or is just a concomitant consideration.

Examples:

administrator > editor > reader
beginner > expert
customer > supplier
student > teacher

CONVENIENCE

Convenience is about ways of organizing based on utility, preferring usefulness within a given context. This encompasses things like relevance, interaction, and popularity. You may make the most relevant information available first or most prominently. You may emphasize content that a user can interact with or content that is dynamic over static content. This can be a kind of hierarchy, but that's too abstract. Like Audience, Convenience is focused on the user.

Examples:

interactivity
popularity
relevance
usefulness

ORDER

Order is probably, and likely counterintuitively, the last consideration for organizing information. It is certainly the last resort for locating information from the wide angle, e.g., a sitemap, but it's also likely the best way to organize things at the granular level. When a user has successfully located the most topical, personally relevant, and actionable information, you can focus on ordering in a logical or a generic way.

Examples:

location
name
rank
time

Your organization, your project, your content, and your time will have their own peculiarities and requirements, but in broad strokes, you're going to want to look at your data and determine (1) the big picture themes or topics, (2) who comprise the audiences, (3) how you can help them find what they're looking for, and (4) the best way of ordering things on the granular level.

Here's the first thing I sketched out while thinking this through:

Let's stretch this thing as thin as possible, and divide tacos thematically with separate menus for brunch tacos and dinner tacos, then branch off by audiences, splitting meat tacos from vegetarian and vegan tacos. For convenience, we group all of the optional toppings, then maybe we order them into ranked groups (e.g., guacamole goes in the bonus "add for a $1" group), then internally order the toppings alphabetically. This is a kind of tree that should help anyone find the taco that's to their liking.

I might organize my information by degree programs, but build the menu by specific student populations, e.g., admitted students, then 1st, 2nd, and 3rd year students. I might privilege information they care most about, like class standing, course information, and exam schedules, or give time-sensitive things like deadlines and upcoming events a prominent place on the landing page. And then, of course, test and iterate.

And that's how you build a TACO. The ingredients will vary, but process is basically the same.

And if you want to really learn something, join me in reading Lisa Marie Martin's excellent Everyday Information Architecture from A Book Apart, which I was reading when this TACO thing took over my brain and made me stop to get it down on paper. I'm about ready to get back into the book, and I hope the next page doesn't explain why my dumb idea is so dumb.

Relative Font Weights Considered Harmful

Den McHenry — Sun, 31 Mar 2019 02:25:06 +0000

Not exactly, but who can resist writing a "considered harmful" article when you can get away with it?

The real harm is that you can very easily conceal the semantics conveyed by font-weight depending on the font that's rendered, which is not always in your control. This all depends on how you define the base weight to which your relative values refer, and (1) whether that base weight is actually available in the rendered font and (2) which value is substituted if it isn't.

So let's unpack that.

Font Weight

Font weights are easy to understand when we deal in simple terms like normal and bold. Font weight on the web is traditionally a binary, more like bold and not bold. But these keywords actually correspond to numerical values and will resolve to another weight if that numerical value is unavailable:

Keyword Declaration		Numerical Declaration
font-weight: normal;	=	font-weight: 400;
font-weight: bold;	=	font-weight: 700;

Fonts can come in any one of up to nine weights, numbered in whole hundreds: 100–900. You've doubtless seen fonts with named weights in different contexts, like "thin," "medium," "extra bold," and "black." Each of these would align with one of the nine numbered weights.

While most fonts only have a small handful of available weights, there are some that run the gamut, all the way from 100 to 900, and this is becoming increasingly common with the ubiquity of webfonts. (This is another problem in itself, bloating sites for users and wasting bandwidth.)

1 step forward, X steps back

If the rendered font lacks the corresponding weight, the browser will select the nearest weight according to a simple algorithm.

An easy way to think about it is this:

normal wants to be normal — or at least not bold
bold wants to be bold — or at least not thin

Normal will err on the side of light, and if bold can't be bold, it will try it's damnedest anyway.

The range for normal is 400–500. Anything higher — 600 and up, even though 700 is the sweet spot — is in the bold range. And while it doesn't have a base name, 100–300 can be considered light.

For normal text, if the rendered font lacks weight 400, it will go to 500. If that's not available, it really doesn't want to be bold, so it has nowhere to go but down, to 300. And so on. It will go bold if it must, but it wants to be not bold.

Likewise, for bold text, if the rendered font lacks weight 700, it will err on the side of boldness: 800, then 900, and then it will drop its shoulders in resignation and work backwards taking the first available weight that is the least light.

That's all well and good. But what happens with the relative keywords, lighter and bolder, and why do I tease that they're "considered harmful?"

Be careful what you ask for

Let's say you ask for a specific weight in your CSS file:

p {
    font-weight: 300;
}
p strong {
    font-weight: stronger;
}

This may seem like an unfair example, but things like this happen, and you'd be excused for thinking that strong text would be appear bolder than the rest of the paragraph.

It would appear stronger if the rendered font had 300 available along with any stronger weight. But what if it doesn't?

The lighter and bolder keywords respond to the inherited weight, and can resolve to 100, 400, 700, or 900 depending on the declared weight. So, for example, our example with a paragraph of font-weight: 300 containing a strong element with font-weight: bolder; is the same as the following:

p {
    font-weight: 300;
}    
p strong {
    font-weight: 400;
}

But if we change the 300 to 400, then bolder becomes equivalent to 700. That's not something you'd ever want to keep track of and certainly something you'd never be able to keep up with.

But let's say you go ahead and define your font-weight at 300, and it isn't available. The text will render at the nearest available weight according to the selection algorithm. If the rendered font is Arial on a common Windows machine, then the available weight is probably 500. The strong declaration of bolder means "bolder than 300", and thus "400", but it, too, will render at 500, following the defined algorithm for resolving available font weights.

p {
    font-weight: 300; /* Unavailable: Resolves to 500 */
}    
p strong {
    font-weight: 400; /* Unavailable: Resolves to 500 */
}

In this case, the visual semantics are lost.

So if that matters to you (and it should), then tread carefully here. At the very least, you want to be very thoughtful about choosing weights for web fonts, and how well your weight declarations will fall back in their absence.

Photo by Natalia Y on Unsplash

Falsy Values are N0 FUN!

Den McHenry — Fri, 13 Apr 2018 18:05:58 +0000

When I was a Latin teacher, I used to love coming up with mnemonic devices to help students remember novel or difficult things, like the order of the Roman kings, or the endings of verbs. But as I think about it, it's a technique I use for myself all the time.

Example: I just came up with a simple mnemonic device to remember the falsy values in JavaScript.

falsy values == N0 FUN

N0:

NaN
0 or -0 or "" (empty string, i.e., String.length === 0)

FUN:

false
undefined
null

Now, this doesn't mean that YOU can't enjoy falsy values. You may think they're just as fun, fun, fun, fun, FUN! as kazoo, but just as Every Good Boy"" doesn't necessarily Do Fine, remember: falsy values are N0 FUN.

Relative URLs Desmystified

Den McHenry — Mon, 02 Apr 2018 04:31:29 +0000

The first key to really understanding relative URLs is to recognize that they refer to the current URL and do not reflect the actual folder structure on disk. The notation used is analogous to file navigation, but in this context you're not traversing the physical structure: the browser constructs the new URL from the current URL value using a simple but surprisingly robust set of symbolic notation.

Let's take a look at a handy table, and then I'll dig in. There are exactly four distinct symbols with very precise meanings:

Symbol	Meaning	Notes
`/`	Root	up to base URL
`//`	Protocol	to be avoided
`./`	Current dir.	alias: no slash
`../`	Parent	may be combined

These symbols are composed of just slashes and dots, singly or in pairs. It may seem confusing at first, but the first three are constant and can not be combined. The last one, with two dots, can be combined, as we'll see below.

2 Slash or Not 2 Slash?

The simplest way to conceptualize the double slash and the single slash in relative URL notation is to recognize that the base URL is the kernel, and to think of the double slash and single slash as something like bookends. One separates the base URL from its protocol, and the other separates it from its subpages and directories:

Protocol	delimiter	base url	delimiter	subpages, &c.
https:	//	dev.to	/	denmch

The double slash will tell the browser to build a URL from just before the base URL, going back to the protocol. The single slash by itself tells the browser to construct a URL from just after the base URL, at the level of subpages and directories.

Given the URL https://dev.to/denmch, double slash (//) is shorthand for https:// and single slash (/) is shorthand for https://dev.to/, quite literally telling the browser to begin at this or that distinct delimiter.

Protocol Considered Harmful

You've doubtless linked to or at least seen external resources without a stated protocol (http: or https:), using a url of the form //path-to.my/script.js.

This seemed just dandy for awhile, but it's now considered an anti-pattern and potentially exposes vulnerabilities. Even though it's probably best avoided, it's good to know why it works the way it does, and it helps us to gain a deeper understanding of how relative URL notation really works, especially since it's still found out there in the wild (even if we should avoid it).

Dot Dot's my father's name; call me Dot

Whereas slashes by themselves refer to the bookends around the base URL, single slashes in combination with dots refer to the full current URL and move from right to left.

Dot qualifiers tell the browser that this slash is not root. Semantically, a single dot followed by a slash (./) means "start from the current directory." The ./ symbol will never be found in any other combination (e.g., .././ would be invalid).

A double dot followed by a slash means "start one directory up," and this pattern can be compounded to traverse leftward in the current URL, so that ../ references the parent of the current directory and ../../ references the parent of the parent, and so on.

If the relative URL references more "generations" than the current URL contains, the new resulting URL will start only as far back as it can: at the base URL:

Given the URL https://dev.to/denmch, the following patterns all go back to the base URL (https://dev.to) because there are no parent directories to extrapolate from the current URL:

../../../
../../
../

The last important bit is to recognize that ./ has an alias: beginning a relative URL with neither dots nor slashes. Given the current URL https://dev.to/, a relative url of the form href="denmch" would be functionally equivalent to href="./denmch" and result in a final URL of https://dev.to/denmch.

Now it's up to you do decide when and where it makes sense to use relative URLs, and hopefully you're better equipped to think it through and understand problems and potential problems as they arise.

Ch-Ch-Changes: to shell and back

Den McHenry — Sat, 31 Mar 2018 14:23:36 +0000

I hadn't gotten around to reading Remy Sharp's command line book yet, so I bought his terminal training course when he put it on a flash sale. One of the new things he introduced me to there was changing my terminal's shell, and though he uses zsh (and gets to that next), he starts you with something I've never seen, but that's really cool: fish.

First, let's get one thing squared away: what's a terminal and what's a shell?

I never metaphor I didn't like

Once upon a time, a terminal was a physical device — a literal end point at which a human interacted with a machine. A synonym you'll sometimes see is TTY, short for TeleType, which was a kind of typewriter that could send input by typing commands line-by-line and receive printed output. (It's also called a teleprinter, for obvious reasons.) This is the origin of the command line interface (CLI).

Today, we mostly use graphical user interfaces (GUIs), and so we need a program to emulate the TeleType of yore. This is what we call a terminal, no longer a physical device but just another software package running on our personal computers. If you're on a Mac, the default terminal application is called Terminal, but many people prefer an alternative like iTerm2. On Linux you might use something like Gnome-Terminal or Konsole. You have choices when it comes to terminals, and you can customize their appearance and behavior.

The shell game

The shell is a little tricky to understand only because the metaphor that produces it's name comes from its relation to the operating system and not to the user. The core of an operating system is what controls and interacts with the hardware. That core portion of the operating system is called the kernel, by analogy with the soft, chewable bit within the hard shell of a nut.

By analogy again, then, the shell should be synonymous with the physical terminal. But this is where the analogy breaks down. We don't use the shell to get to the tasty, edible bits of the nut. We strip it away and toss it in the compost. But here, with computers, we rely on the shell entirely and never actually touch the kernel.

The terminal is now the application that gets you talking to the machine — a program emulating a TeleType — and the shell is how you talk to it, a specific flavor of a command line interpreter, that facilitates your ability to send commands and receive feedback with varying levels of help and customizability. You can think of the terminal like a guitar and the shell like the strings, which can come in a variety of materials and gauges, sometimes tuned in exotic ways. One shell is a common bronze alloy, while another is nylon, and another is silk and steel. They feel and play differently, but they all make music in the same way.

z sells z shells by the z shore

The most common shell is bash, but there are others like ksh, zsh, and others. Notice that they tend to end with sh, for shell. And we sure do love to abbreviate things when on the command line, like ch in the title of this post. But we're getting to that. Shells differ in details like whether you can group commands, how variables are set, and whether or not they support tab completion of typed commands.

Remy introduces fish, an exotic shell with tab completion, as a good starter shell, though he personally uses zsh. I'd only ever used bash, so fish was very weird and different, and the tab completion was especially cool, like working in Visual Studio with Intellisense.

But one issue I had was this: how do I get back to the land of bash?

Ch-ch-changes

Following the fish installer, you're told to run a certain command to switch your shell, and Remy didn't go into detail here, but it's worth looking at the command:

chsh -s /usr/local/bin/fish

The command chsh means "change shell," just as chown allows you to change the owner of a file or directory, and chmod allows you to change the read, write, execute permissions for the current user, the group, and for others.

The -s option lets you enter that location without any additional prompting or file opening. So the command above says, "change my shell to the shell in /usr/local/bin/fish."

chsh actually calls the same program as two other ch-prefixed commands: chfn, or "change finger," and chpass, or "change password." This program allows you to change user database information, like your full name, office location, phone numbers, and, most importantly for this purpose, for the location of your preferred shell, and it doesn't matter which you use. It's just easier to remember that chsh is for changing the shell, and if you want to get it done without editing a file in vim, throw it up in one line with the -s option and the shell location.

So once you've switched to fish, if you want to change back, you just need to know the location of bash, which should be simple:

chsh -s /bin/bash

And from there, you can try others in the same fashion.

So that's that: a long-winded way to get around to switching back to bash from fish. I've always found it helpful to dig into what the commands actually mean to understand them and retain what they do. So now I know more about it, and maybe you do, too.

Using the Wordnik API

Den McHenry — Tue, 20 Feb 2018 19:38:30 +0000

One thing I've finally learned is that whether you're running bash or zsh in your terminal, the file where you customize your instance ends with rc, which stands for "runcom," or "run commands," dating way back to 1965 in the early days of UNIX. .bashrc is the file that contains commands to be run when the bourne again shell (bash) starts up, and .zshrc has the commands to be run when the z shell (zsh) starts up. And you'll find it elsewhere, for example in .vimrc if you're into Vim.

One of the really cool things you can do here is reference environment variables, aliases, and functions stored in external files. So I wrote the following function using the Wordnik API so I can quickly define words on the command line.

If you don't know Wordnik, you should check it out. It's a great site, and when my confirmation email didn't come through Erin McKean quickly responded herself and activated my account, which felt pretty cool.

The function works like a shell command and can take an argument, which is represented within the function as $@. This grabs any and all positional parameters, e.g., if the command takes three parameters, they'd be referenced as $1, $2, $3. So $@ just takes one after the other and passes them all in. The local variables params and params_encoded turn it into a URL-encode string by replacing the spaces between parameters with %20 so that the result work curl talks to the server.

The curl command is one of those that you find all over the web in places like StackOverflow, where people say, "Just type curl blah bitty blah blah." It's just one of those things that you use to do something. But as often happens, it turns out to be helpful to know what the name means, so that you can retain the meaning. In this case, its name is styled cURL, like the ubiquitous acronym URL. It's written in C and though originally meant to be pronounced "see URL," it was later treated as a backronym for "cURL URL Request Library," as the creator described on cURL's 17th birthday. (As of this writing cURL is nearing 20!)

Knowing that history we remember either that cURL allows us to "see" stuff at a given URL, or that it's a library written in C used to request information from and about URLs.

We run curl with a --silent option. If you were typing this a lot on the command line, it'd be faster to use -s, but for the purposes of a readable gist, it seems beneficial to type out the option, explaining clearly that we want our curl output to be silent, i.e., to not show us the progress bar, etc. To get a result, you need to add your Wordnik API key (I've added mine as an environment variable sourced in my .zshrc file).

We pipe the output through json with the --array option (aka -a), and the lookup parameter text, which is the key that should grab each definition in the JSON results from Wordnik.

These results are then piped to cat with the -b option, which numbers non-blank lines in returned results. I'm not sure the -b options is necessary given the results (-n could be sufficient), but it doesn't hurt.

So just for fun, here's the result, with the added bonus of piping the output to cowsay -f stegosaurus (where the -f option is short for "file", i.e., which "cowfile" is used for the ASCII art).

def learning | cowsay -f stegosaurus