Saturday, March 30, 2013

Music Theory As An Algebra

In the introduction to Charles Pinter's A Book of Abstract Algebra, he covers a very brief history of algebra, examines differences between matrix algebra, numeric algebra, and boolean algebra, and then says:

Other exotic algebras arose in a variety of contexts, often in connection with scientific problems... Today it is estimated that over 200 different kinds of algebraic systems have been studied, each of which arose in connection with some application or specific need.

As legions of new algebras began to occupy the attention of mathematicians, the awareness grew that algebra can no longer be conceived merely as the science of solving equations. It had to be viewed much more broadly as a branch of mathematics capable of revealing general principles which apply equally to all known and all possible algebras.

What is it that all algebras have in common? What trait do they share which lets us refer to them as "algebras"? In the most general sense, every algebra consists of a set (a set of numbers, a set of matrices, a set of switching components, or any other kind of set) and certain operations on that set. An operation is simply a way of combining any two members of a set to produce a third member of the same set.

Thus, we are led to the modern notion of algebraic structure. An algebraic structure is understood to be an arbitrary set, with one or more operations defined on it. And algebra, then, is defined to be the study of algebraic structures...

Any set, with a rule (or rules) for combining its elements, is already an algebraic structure. There does not need to be any connection with known mathematics. For example, consider the set of all colors (pure colors as well as color combinations) and the operation of mixing any two colors to produce a new color. This may be conceived of as an algebraic structure. It obeys certain rules, such as the commutative law (mixing red and blue is the same as mixing blue and red). In a similar vein, consider the set of all musical sounds with the operation of combining any two sounds to produce a new (harmonious or disharmonious) combination.

Pinter's definition is of course almost insanely broad. "Combining any two members of a set to produce a third member of the same set" describes sexual reproduction, the construction of sentences, software development, Borges's infinite library, and a huge variety of other things. As long as you can discover any form of predictable combinatorial patterns, you can infer rules exist. But I like this definition very much, because it is a really useful way to understand music theory, especially Western musical notation, which definitely qualifies as a sophisticated and deep algebra under Pinter's definition.

Of course, music theory is not everything. Orchestral musicians have a saying that "90% of the music is not in the score." (The term "score" refers to the written representation of the music.) The same is extremely true of my own long-term obsession, electronic dance music, where the number might be nearer 99%. It's very, very common in both techno and trance to play the same melody or bassline repeatedly, changing the timbre (or sound design) while leaving the motif unchanged.

Here are a couple of very illustrative examples. It occurs quite a lot in other subgenres as well, of course; the first example is from drum and bass. There's also good coverage of this in Unlocking The Groove, which despite its seemingly casual title is a thick academic book from a music theory PhD.

Anyway, although music theory is not everything, dance music is as hopeless without it as any other form of music. And speaking of challenging books, I'm only about 20 pages in — three appendices and half an introduction — but Pinter's book is so far the most entertaining book on math I've read in a very long time.

Thursday, March 28, 2013

FlexVerb: A Serious Toy Language

Here's a few tweets from before I recently disconnected from Twitter:

These tweets prompted a few interesting responses, but the discussion didn't really go anywhere. That's partly because I decided I'd rather make a real example than discuss hypotheticals.

Unfortunately, I didn't get as far as I would have liked. It turns out implementing a language is hard. But I did create a basic implementation, along with a Vim syntax file to enable syntax highlighting, and post it to GitHub as FlexVerb.

The readme contains 1,828 words. It starts like this:

`FlexVerb is a barely-implemented programming language based on Latin and Ancient Greek. It is essentially a blog post, in executable code form, about an obscure linguistic quirk and its unexpected benefits.`

Although I absolutely cannot recommend FlexVerb for production use, or even (in its current state) any programming tasks beyond the most utterly trivial, I can very confidently recommend reading its code — for anyone interested in parsing expression grammars, or a gentle introduction to language implementation and Vim syntax highlighting — and reading its readme, for anyone interested in programming language design or linguistics.

As far as I can tell, linguistics only concerns itself with the commonalities of human languages; I think my readme also implies a fairly compelling argument for the development of a linguistics which studies computer languages. Also, just to really push my eccentricity to new heights, I would love to see a linguistics which explored the commonalities between computer languages, human languages, bird calls, dolphin calls, primate communication, and the dancing of bees.

Update: Speaking of dancing, nearly everything I know about Romanian comes from dance music, and many of the things I say about Latin and Ancient Greek in FlexVerb's readme also apply to romance languages, especially ones whose classical origins are very easy to trace, like Romanian.

Wednesday, March 27, 2013

Highly Recommended: The Inner Game Of Music

Credit where credit's due, I got the idea to read this from Zed Shaw. It's a good book. It goes well with The Talent Code, too.

Tuesday, March 26, 2013

Rapid Weight Loss Is Easy

In 2009, I lost 60 pounds in six months, and I thought I was a badass, because I'd seen people go on Oprah and similar shows to brag about how they lost less weight than that in twice the time frame. But after a while I got lazy and stupid, and I started eating the way Americans normally eat, and I soon re-acquired the weight problems that Americans normally have. So eventually I got a hold of my senses, and in the past two months, I've lost 32.5 pounds, which is a very swift rate of weight loss. In fact, most of the weight loss comes from one week in February, when I lost 20 pounds, and the past two days, in which I've lost 9 pounds.

In February, I fasted for 7 days, and as of right now, I'm on day four of my second fast of the year. "Fasting" in this context means no food, only water, and limited amounts of water; I do not consider a "juice fast" to be a real fast. (In fact, strictly speaking, I don't even consider the phrase "juice fast" to be semantically meaningful, since it's a contradiction in terms, but that's a huge digression.)

I prepared for these fasts with a few tiny fasts (one day or two days) in 2010. I underwent my first serious fast, in February, after extensive research, but with no medical supervision. I plan to eventually do a month-long fast under medical supervision, for reasons I've already explained in another blog post. But I'm only doing a four-day fast currently, maybe five days at absolute maximum, so I'm not operating under medical supervision this time either, although I did consult with a doctor first. The doctor in question was an apprentice, of sorts, to a doctor who has consistently achieved incredible results with fasting and nutrition; for instance, in the area of heart disease, his track record surpasses that of literally every cardiologist in the United States, which is somewhere between 8,000 and 20,000 doctors. He's also had similarly remarkable successes in several other areas, such as autoimmune diseases, but I haven't investigated those in similar depth.

Caveat time: I am not a doctor. This is not medical advice. This is my own opinion and personal experience only. There's also the fact that fasting is very much easier for me than for most people, because I eat a very strict nutritarian diet which does not contain meat, processed chemicals, or white flour. (The diet has other restrictions but these are the restrictions which, as I understand it, make fasting easier, because those substances affect blood sugar stability, and induce various forms of frequent, mild toxic shock.)

Most important caveat: the process I'm using is not simply to stop eating. The process looks more like this: 1) spend a few hundred dollars on Amazon buying every book on heart disease which looks as if it might be worth a damn; 2) find the one book which actually is worth a damn; 3) read literally every word that the author of that particular book has ever written; 4) consult directly with a doctor under his personal training. And technically, the process is even more involved than that. I evaluated the "worth a damn" criterion after developing an entire career around the judicious application of structured logic to business problems, aka software engineering, as well as studying classical languages, philosophy, and logic continually from the ages of 14 to 20. If you make logic the focus of many years of your life, "worth a damn" implies high standards of logical rigor and supplementary research.

That being said, I'm visibly overweight, and when I just stop eating for a few days, I lose weight. It doesn't take a genius to see the connection. It does, however, take some epic research into nutrition to avoid packing the weight back on again once I resume eating. So perhaps I should say "rapid weight loss is hard," or "rapid weight loss is easy in context," or "rapid weight loss is easy, if you are already conforming to strict dietary rules which make your blood sugar remarkably more stable than the average American's," but that's kind of wordy. I've always felt that five words is the optimum length for a blog post title, and I don't mind passing along the implicit assumption that all people, everywhere, should use research, logic, and self-discipline by default, because I can mostly agree with that assumption in principle, and I can absolutely agree with it in the context of a programming blog.

Before I discovered how easy fasting can be, or the work of this incredible doctor, I took a very fatalistic attitude towards my weight problem. If that sounds like you, I want you to understand that you can obliterate your weight problem easily, as long as you can muster the necessary research, logic, and self-discipline. (And if you're weak in any of those areas, you can cultivate discipline by studying martial arts or musical instruments, while studying either software engineering or classical Western languages will strengthen both your capacity for research, and for logic.)

One final caveat: although I am still overweight, I might not actually be visibly overweight any longer.

Saturday, March 23, 2013

As a result of the latest shitstorm, I'm changing how I use Twitter.

I believe Ms. Richards did nothing wrong. People use Twitter to share cat gifs and completely unnecessary information about what type of sandwich they're eating. Tweets are so incredibly disposable that it's a little crazy to hear anyone holds a serious opinion about any tweet. I also believe that the guys Ms. Richards photographed only did a small thing wrong. They deserved some public embarrassment. When you tell the wrong joke at the wrong time, you're going to be embarrassed. That's just how it works. More than that, though, seems like overkill.

Also, I don't think there's anything wrong with public shaming, as long as the public involved is not going to go batshit insane over a minor provocation. Programmers, unfortunately, seem to do exactly that, and pretty regularly. This might just be an unfortunate reality of the programmer personality type -- I myself once got so angry at a developer who farted while sitting next to me that he literally thought I might try to kill him -- but I believe Twitter makes it worse.

Tweets are brief enough to match the pace of normal conversation, but they lack the nonverbal context that real conversation needs. Tweets discourage depth, due to Twitter's utter uselessness for threaded conversation with multiple participants. Tweets skew heavily towards oversimplification and misinterpretation, due to the incredible ease with which a remark can be stripped of its context and widely propagated. And tweets skew heavily towards shallowness, since the format only supports rapid, brief responses.

I think Twitter bears some responsibility for the incredibly rapid escalation that programmer drama sees these days. It's faster and more personal than it used to be. When you see a new phenomenon which encourages the instant, context-free propagation of incendiary comments, and you also see people's tempers getting much shorter at around the same time, it doesn't take Sherlock Holmes to spot the connection.

Most of the threats leveled against Ms. Richards, if I understand correctly, occurred on 4chan, and I certainly think that is not an ideal thing, to say the least, but 4chan served a similar function in the similar salvo of rape and death threats which Kathy Sierra suffered in 2007, and although that episode was also horrible, it played out at least a little more slowly.

This is of course not proof, just a hunch. And it is of course absolutely horrible that these threats occur at all, that law enforcement does not handle them like the crimes they are, and that they have actually gotten worse in the past five or six years. But that's not really what this blog post is about.

What this blog post is about is the simple fact that I just don't have time for this shit. Giving some of my time to speak out against sexism and/or racism is certainly worthwhile, because it stands a chance of making the world a better place, but in practice it doesn't seem to do so, and I'm not a cop or a politician. We already have people whose job it is to solve these problems. If these lazy fuckballs aren't doing their jobs -- which is usually the case -- then we need to wake them up and get them working.

More relevantly, you can't glimpse even the slightest world-enhancing possibility in the overwhelming majority of arguments which I've seen Twitter accelerating, polarizing, and intensifying. Most of the time, it's just people freaking out for no good reason. I can't stop that from happening, but I can stop myself from being one of those people.

At best, I think Twitter belongs in a category of shallow, time-wasting amusements with trivial benefits and significant long-term downsides, like junk food, television, and Hacker News. However, I'm not totally throwing Twitter away forever. First, it's good for advertising my products (which is another thing it has in common with TV and Hacker News). Second, I have a Twitter account where I used to post new music daily, and I still post a lot of new music there. That's been very good for me in terms of developing my music skills. (I tried switching to SoundCloud, but it's overkill for that use case.) Third, Twitter can be a good source of new information.

I'm going to stop using Twitter entirely for a while, just to break the habit so I can start again clean. Next, I'll probably write a simple filtering/formatting mini-app, so I can get the useful information without the tempestuous noise. I've done these for Hacker News and the Bitcoin exchange rate, and I've been very happy with this approach. It's much, much more pleasant than accessing a noisy information source directly. I'll probably also write a simple write-only Twitter queue, like my failed "startup" Email Without The Inbox. And, of course, if/when I actually do these things, I'll probably blog about it here, and share the code on GitHub. I might even tweet about it.

Tuesday, March 19, 2013

Code To Make You Walk

A little while ago I hacked my `crontab` to remind me to walk every 25 minutes:

However, this was flawed. Because it runs all day long, it can tell you to walk for five minutes the minute you first turn on your computer. It started doing this with me, so I started ignoring it. But an organizational system you ignore is worse than none at all, so I'm trying a different tactic. This is a bash function from my `~/.profile`:

The `\$()` syntax executes the rest of it in a subshell, and the `&` at the end backgrounds the process. So every time you sit down at the computer, you tell the computer to remind you to walk if you're still sitting down at the computer once 25 minutes have elapsed. If you decide to get up and go somewhere before the 25 minutes have elapsed, you just exit the shell; it'll remind you that you have background jobs, and you can kill the job, so you don't get this backlog of irrelevant reminders.

Otherwise, of course, it'll tell you to stop walking after another 5 minutes have passed. `sleep` takes a number of seconds, and 1500 seconds is 25 minutes, while 1800 seconds is 30 minutes. I learned how to build this function by writing my illustrated ebook Legend Of The Burned Hart Style, and I got the idea of using shell scripting this way from the book Time Management For System Administrators.

A lot of people are excited about a deeply misguided project called Soylent, which inaccurately describes itself as "a drink that has enough of every essential nutrient the human body needs."

It is a drink. That part is accurate.

However, the exact number of nutrients a human body needs is unknown, and may be several orders of magnitude greater than Soylent's design assumes. For instance, a single tomato contains more than 70,000 phytochemicals, which are unique chemicals found only in plants (and often, unique chemicals found only in particular species and varieties of plants). Although consuming tomatoes often is very strongly correlated with a decreased incidence in cancers, it is unknown if any one specific phytochemical plays a decisive role in that effect, or if the effect only occurs when all 70,000+ phytochemicals operate in synergy together.

Or maybe it's just some subset of those 70,000+ phytochemicals, and that subset operates in synergy. Imagine trying to determine which phytochemicals were in that set, and which were not. You would need to study approximately 4.9 billion different combinations of those 70,000 phytochemicals, because 70,000 to the 2nd power is 4.9 billion. So you can fund 4.9 billion separate but related research efforts, after locating 4.9 billion separate groups of cancer patients, and developing 4.9 billion separate but related processes for extracting, isolating, and re-combining phytochemicals, or you could just remember to eat tomatoes, because they're good for you. Which move sounds more cost-effective?

(Update: OK actually, I'm not 100% sure what the number of necessary phytochemical research projects would be, but I do still think it's very safe to say it's a very large number.)

A similar story: Researchers found that daily servings of nuts were correlated with decreased incidence of heart attacks. So some other researchers tried to produce the same effects, but using only a subset of the total range of chemicals found in those nuts (specifically, the fatty acids). They failed.

Soylent is based on an absurdly oversimplified view of human health which fails to differentiate between nutrition and nutrients. It is very naïve in my opinion. I consider it the Bash on Balls of health, except Bash on Balls knows it's a joke.

Why you should consider my opinion: I lost 60 pounds in six months using superior nutrition. This lifestyle change also eliminated several very dangerous heart disease symptoms, as well as trivial allergy symptoms, tooth decay symptoms, and skin problems. It also lowered my blood pressure and cholesterol by a staggering degree in a very short space of time.

I would be very surprised if anybody experienced similar effects with a diet consisting entirely of Soylent.

Thursday, March 14, 2013

More Detail About My New eBook

My new ebook, Unfuck A Monorail For Great Justice, refers to a frequent problem: monolithic Rails apps (or "monorails"), and the fact that the people who work on them will often describe them as fucked. My first book covers some of the reasons that monorails happen in the first place. This book is more about how to solve that problem -- how to take a monolithic Rails app, make its specs much faster, make its design more object-oriented, and use that more object-oriented design to fragment the app into services, where necessary.

I also cover techniques you can use to automate parts of your refactoring efforts and make those efforts happen much, much more quickly than usual. I first figured out the basic ideas behind these techniques in 1997, when I had to re-format and re-structure over seven hundred hand-made HTML files in the space of two weeks. I refined the techniques considerably many years later, when I refactored parts of a large JavaScript application and reduced the size of the code base by over 1100 lines in only a week. I did most of this work by writing code which refactored the ugly JavaScript for me, and I show you how to do the same thing with Ruby code.

This book does not cover Rails antipatterns, which is in fact the name of another terrific book on that subject. If you don't know how to spot problematic code in your Rails app, then you should get that book. My book is about the best way to solve these problems, and solve them much more quickly than you would expect.

With my first book, I made an effort to be as not-NSFW as possible, but I was only moderately successful, and in fact I believe I used the word "fuck" 12 times. However, many people praised the NSFW-ness of that book on Twitter and in emails to me, so I didn't bother with that this time around. Basically, I decided not to give a fuck.

However, you might notice an unusual contrast; I use NSFW language all over the place, yet when I mention the work or ideas of other people, I refer to them with their last names, in a more formal style, because I believe that conveys a certain modicum of respect. I kind of wanted to balance the general informality with a deliberate formality in that one particular area, because I don't like flame wars and don't want anybody taking any disagreements personally. When it comes to talking about other people and/or their work, I think it's important to use a default which signals respect.

The book has three main parts. In the first section, I go through an experience I had where I was able to hit the ground running in a Rails rescue project with more context and detail on the state of the code base than I believe the company's CTO had during his entire time at the company. I got this information by writing bash and Ruby scripts against git history, and I show you how that code works, and how you can do the same thing. This is similar to material in Gary Bernhardt's Destroy All Software videos, but differs in some important ways. The bulk of the book consists of advice on how to make Rails specs faster, and make Rails code more object-oriented. (If you understand TDD, of course, you will realize that these two topics are two sides of the same coin.) The final section goes into detail about how to dramatically accelerate refactoring with judiciously applied automation.

Unfuck A Monorail For Great Justice: \$41, 85-page PDF

New eBook: Unfuck A Monorail For Great Justice

Have you ever encountered a monolithic Rails app?

Have you ever wondered how to get it back to the slim, flexible dexterity that it had in the early days of its development?

Would you like to know how to make large Rails test suites fast?

I've written a book which tells you how to do those things. But that's not all it does.

I've figured out some amazing hacks to accelerate the process of refactoring. Using these techniques, I shrank a code base by over 1100 lines in a single week.

Monolithic Rails apps -- or monorails -- are a problem in the world of Rails development. My new book doesn't just show you how to get them back on track. It shows you how to get them back on track more cleanly and more swiftly than you would have believed humanly possible.

Nobody's seen this book yet, but people had great things to say about my first one.

Unfuck A Monorail For Great Justice: \$41, 85-page PDF

I hope it's obvious, but this book is NSFW. Unless your workplace is cool with swearing a lot. In which case, you're golden.

Monday, March 4, 2013

An MVP Comic Book About Gary Bernhardt's Approach To Unix

Update: I took this product off the market for now, because I'm going to be making some edits and corrections.

Gary Bernhardt's an amazing programmer. His Destroy All Software screencasts teach his approach to writing software, which is powerful, fluid, and unique. It is an amazing thing. Whenever I find out that a programmer I respect is not familiar with Destroy All Software, I lose a little respect for them. I'm sorry to say it, but it's true.

Yet many programmers simply don't like screencasts, and would prefer to learn from a book, as opposed to a video series. And I must admit that I think screencasts do have downsides sometimes. You can't search a screencast, you can't copy and paste its code, and you can't consume it at the speed of your own thought.

And recently I realized that if I was going to truly learn to code like Gary Bernhardt, I would need to go back, watch a lot of his videos again, and take extensive notes. For me, it wasn't enough just to watch them. So I decided to solve both problems at once, by taking extensive notes and turning them into a book.

I began this process, and discovered that I had underestimated the value and information density of Destroy All Software. I divided up the videos by topic. There are currently 88. I got far more than a book's worth of notes out of just the first 17 I reviewed, which were (at that time) all of the videos on bash, vim, and git.

So I decided to create a book just from my notes about the videos on bash.

I also decided, for reasons that I cannot explain or indeed even remember, that the best way to present this material would be as a comic book. I used to be able to draw pretty well. But I haven't kept that skill going, and writing and researching the book took a long time, so I had to settle for a very limited implementation. Here's a couple sample images:

I had a script in Markdown. Not a script in the programming sense, but in the sense that movies, plays, and comic books have scripts. Its text was longer than the text of my first book, Rails As She Is Spoke. Rather than go through this script and create hundreds of pages of original art to complete a bona fide, true comic book, I instead wrote a few quick, custom templating scripts (in the programming sense) to automatically turn my Markdown files into ultra-minimal "comic book pages" like the sample images above. There is a little more original art in the book than that, but only a little.

It turns out that making a very detailed comic book about code is a lot of work. Still, I think I can technically say that I have created a very minimum-viable-product version of a comic book, which means that this is not only the first ever book about Gary Bernhardt's approach to writing software, it is also the first ever comic book about Gary Bernhardt's approach to writing software.

Just in case other comic books about Gary Bernhardt's approach to writing software exist which I somehow failed to notice, however, I decided to further guarantee my book's uniqueness with several original features. For example, I am very confident that this is the only comic book about Gary Bernhardt's approach to writing software which features Alan Turing beating the crap out of a small woodland animal with a big blue dildo.

At the same time, I am not above trotting out a few cherished, crowd-pleasing clichés now and then. Nostalgic Ruby programmers will be glad to hear that this is not the only comic book about programming which features cartoon foxes shouting "chunky bacon."

And I certainly believe that technical detail belongs in technical books, so this is also a book full of detail on Unix, including how to use it, essential utilities, core principles, syntax, gotchas, and more. Yet the worst thing about working with Unix (and Unix-like systems such as Linux, FreeBSD, and OS X) is that there is so much obscurity overlaying so much power, so I made very very sure to prioritize information you can use, and to clarify the living fuck out of the confusion hellstorm that is Unix documentation.

Therefore, I think I can say, with total confidence and accuracy, that my new book is the best comic book about Gary Bernhardt's approach to writing software that has ever been written. Not only that, if you have your own comic book about Gary Bernhardt's approach to writing software and you want to throw down, I think I am ready to pwn you.

If you buy my new comic book, and you subscribe to Destroy All Software, I think it will be an amazing study guide which will help you level up your Unix skills like a motherfucker. Alternatively, if you buy my new comic book, but you haven't subscribed to Destroy All Software yet, I think you will find it a very compelling gateway drug, and I even think you may thank me for opening your eyes.

However, although you can probably tell I think very highly of Destroy All Software, this is much more than just a comic book adaptation of somebody else's work. First, it's not actually associated with Gary Bernhardt in any way, shape, or form. You should look at it like a work of literary criticism or outside analysis. I am definitely not going to claim Mr. Bernhardt endorses my misuse of Mr. Turing's standing as a historical figure, for example.

(And by the way, if Destroy All Software picks up new subscribers as a result of this blog post and my new book, which I hope it does, I will not make any money from that. There's no affiliate program going on, unfortunately.)

Second, my book really just uses Mr. Bernhardt's work as a launching point. I feel Destroy All Software provides good answers on how to use Unix, but also, and much more importantly, that it asks great questions. There are a lot of places in the book where my answers differ but I still agree the questions are worth asking. I wanted to not just learn how to use Unix the way Mr. Bernhardt does in his videos, but also use that knowledge to enhance my own style, in keeping with my own philosophy.

So my book addresses areas where I respectfully disagree with Mr. Bernhardt. I show you how to create and use numerous original bash hacks of my own. I go deep into the history of Unix, trace the evolution of a complex lineage of inter-related tools and languages, use scholarship from the world of spoken languages to demystify obscure Unix commands, and even explain how the poetry of Robert Frost provides the best way to understand forking processes. I also build, and guide you through, a narrative and map-based structure for understanding Unix skills, inspired by the memory palaces of classical Greek and Latin philosophy, which even today, thousands of years later, represent some of the most potent mnemonic and pedagogical techniques ever devised. It's beginner-friendly, but even if you've been using Unix a long time, I think you'll get a lot out of this book.

Legend Of The Burned Hart Style: The Tower Of 34 Daemons is 128 pages long. It costs \$37. The art is half-assed, but entertaining, because I focused my energy on the writing and the research, and I think you will find both to be excellent. Satisfaction guaranteed, and by "guaranteed," I do mean guaranteed. I have no problem with you requesting a refund for literally any reason, including for example "I stubbed my toe."

As I hope is obvious from the sales pitch "level up your Unix skills like a motherfucker," this comic book is, in many places, NSFW. In fact, thanks to my fictionalized version of Mr. Turing, and his giant dildo, I think it's the most NSFW product I've ever created.

Nobody has seen this book yet, not even Mr. Bernhardt himself, so here's what people have said about my previous products:

I'm now having companies compete to have me rather than me competing for jobs. That's a huge difference in the finding-a-job experience, and it's because I watched your video like 7 times and kept referring to it.

Giles - had to shoot you an email because your resume video helped me in a big, big way. I recently landed a dream Ruby job (with an amazing startup) as a direct result of what you taught me in your video.

Selling Info Products: Discounts Help, But Not A Ton

I've done a bunch of sales recently where I put my Rails book on sale at a discount for a limited timeframe, and one where I did the same for all my products.

These sales work well to generate nice little bursts of activity. They make money. But their overall contribution to my bottom line looks pretty slight overall.

I downloaded a CSV from PayPal, which I use (despite obvious misgivings) for the majority of my info product business. I then filtered it only for sales of my book, and did a little math. The code's in a gist. The numbers look like this:

 discount regular total copies sold 71 368 439 income 1,569.95 13,176.51 14,746.46

This means the discounted copies made up about 16% of the total copies sold and 10.6% of the total income from the product. I did this a couple days ago, so I've sold a few more copies since then, and I've sold a few copies outside of PayPal as well, but these numbers are good enough to draw some basic conclusions from.

However, I also haven't measured how these little sales affect traffic or attention, and I think that would be harder to measure, but my hunch is sales have a benefit there. Despite the fact that basically 90% of my business comes from somewhere else, I would still recommend sales anyway, because of these harder-to-measure benefits. They also make it easy to drive short-term spikes in your product income, which is good for cash flow.

Saturday, March 2, 2013

Chris Liebing On DJ Technique

Might be the best single video on electronic music technique I've ever seen.