Five Rules For Using Google Docs for Outlining

Five Rules For Using Google Docs for Outlining

How to use Google Docs for Rapid Thought Capture.

Everyone is always wishing for the perfect outlining tool. There isn’t one and everyone’s preferences (insane, petty, or whatever) drives the launch and design of thousands of outliner applications. But a cloud-based word processor can be abused in just such a way to make a decent outliner if you restrict your use of its features instead of relying on the bells and whistles of an application. If you like Markdown, look at this as being the in-between of WYSIWYG and just using plain-text.

Don’t waste your time making outlines and fiddling with styles while you’re thinking and brainstorming with these simple rules.

Rule #1: Never touch the mouse.

You see that thing to the side of your keyboard? It’s poison. Don’t touch it.

Just about everything you need to do for functional outlining can be done with your keyboard. If you need to do something with your mouse, chances are, you’re about to commit a thinking error involving styling your text. Change a font? Are you kidding? What are you doing? Does that font make your thought more pertinent? Of course not! Concentrate on your text first, and you’ll get your thinking done in less time.

You’ll be learning various keyboard shortcuts to apply when you need some semantic oomph, but the first one you’re not going to learn is TAB. Like this paragraph? You know how you get a paragraph? You hit enter, twice. Done.

If you think you can’t navigate your text without the mouse, well, you’re wrong. The keyboard has HOME, END, CURSOR and modifiers like CONTROL and SHIFT that do magical things with the cursor and your text. Learn them.

Rule #2: Never indent your text.

Don’t touch your TAB key. Indenting your text is just a different way of styling it. Not even for quotations.

Oh, I know, outlines are all about indenting. Screw it.  Once you fall into the text-indenting trap, you’ll fight with indents when and wherever you move your text around in your outline. You have a quotation? Well, use a fine keyboard invention called “quotation marks.” For example:

“Man, I see in fight club the strongest and smartest men who’ve ever lived. I see all this potential, and I see squandering. God damn it, an entire generation pumping gas, waiting tables; slaves with white collars. Advertising has us chasing cars and clothes, working jobs we hate so we can buy shit we don’t need. We’re the middle children of history, man. No purpose or place. We have no Great War. No Great Depression. Our Great War’s a spiritual war… our Great Depression is our lives. We’ve all been raised on television to believe that one day we’d all be millionaires, and movie gods, and rock stars. But we won’t. And we’re slowly learning that fact. And we’re very, very pissed off.”

Respect your quotation marks. Use paragraphs. Stop arranging deck chairs fighting with indents when you can be writing your thoughts.

Rule #3: Write your headings first.

Fill in your thoughts after you use the headings to define their containers.

In the Google Docs hosted version of this document the table of contents is built exactly from the headings and provides you an excellent summary of what your document is about. Hey, look, you can even click on them to navigate inside your document.

Control-Alt-1 is Heading 1

Control-Alt-2 is Heading 2

Control-Alt-3 is Heading 3

(ARE YOU SEEING THE PATTERN?)

Control-Alt-6 is Heading 6.

You get six different sizes of headings. If you’re going deeper than that and require a smaller, 7th heading, you’re confused and you’re not organizing your material effectively to summarize your content.

Rule #4: Judiciously use use italics and bold.

There are a couple things you can do with text that is stylish from the keyboard. Don’t go crazy with it and reserve their use for selected tasks.

Reserve italics for emphasis and summary. Use bold for popping concepts out inside of your text when they’re not a needed heading. Don’t bother combining them or you’ll find yourself fighting with whether you intended to have bold italics or not and wondering if you mean to emphasis or describe at the same time. Maybe you can handle that, but in general don’t overload text like this if you can help it, it’s less work and simplifies writing.

Rule #5: Limit your blocks of text to what fits on your screen.

Where the headings are labeling, some selective italicized text summarizes, your textual meat should fit on screen.

You’re outlining, not writing a novel. Don’t write a novel between your headings. Make your point succinct.

The Worst Part of This Exercise

Is using the HTML exporter from Google Docs, which fantastically avoids using the HTML elements of I and B (or EM and STRONG) for representing italic and bold text. So if you’re going to live with the quirks of Google Docs, you should plan to stay within Google Docs.

Now, if only Evernote and WordPress had Control-Alt-# shortcuts for headings…

Filed under: Cloud Dependency

Syndicated 2012-10-11 16:24:27 from sj4nz

Making Podcasts Sanely Seekable for Car Audio MP3 Devices

When it comes down to my car’s MP3 player, seeking is the most painful capability—it’s limited to 2x-speed, which is disasterous for seeking to the 45m point of a podcast that’s 90m long. Yes, it’s terrible.

mp3splt to the rescue

If you could roughly split an MP3 into ten-tracks wherever there’s enough silence, you could divide each podcast into ten “rough” chapters. It turns out that there’s a nice CLI utility for doing this, called mp3splt. Here is how I invoke it with a shell function:

function podsplt() 
{               
   mp3splt -s -p nt=10,th=-50 "$1" \
   -d `basename "$1" .mp3`
}

This explodes the MP3 into ten tracks in its own directory, ready to go on any USB or disc media your MP3 player accepts. If you need to change the number of “chapters”, adjust the nt=10 parameter, e.g. nt=15 if you want 15-tracks. If the audio is noisy, raise the silence “floor” with the th=-50 paramter, e.g. th=-40.

Get mp3splt from http://mp3splt.sourceforge.net

Filed under: Audio, Podcasts, Software, Technology

Syndicated 2012-10-05 13:45:27 from sj4nz

Opus: A New Standard Codec for Audio

This is right out of left-field and looks to re-invigorate streaming audio applications.  What would you do with a 255 channel stream? To me that sounds like a potentially awesome future application of a remote mixing board or a live-broadcasting bonaza of choice for the harried producer or social streaming audio media. You could have an entire network blasted down to a consumer’s tuner and they could change channels without suffering audio drop-outs due to buffering.

Opus Interactive Audio Codec

Overview

Opus is a totally open, royalty-free, highly versatile audio codec. Opus is unmatched for interactive speech and music transmission over the Internet, but also intended for storage and streaming applications. It is standardized by the Internet Engineering Task Force (IETF) as RFC 6716 which incorporated technology from Skype’s SILK codec and Xiph.Org’s CELT codec.

Technology

Opus can handle a wide range of audio applications, including Voice over IP, videoconferencing, in-game chat, and even remote live music performances. It can scale from low bit-rate narrowband speech to very high quality stereo music. Supported features are:

• Bit-rates from 6 kb/s to 510 kb/s
• Sampling rates from 8 kHz (narrowband) to 48 kHz (fullband)
• Frame sizes from 2.5 ms to 60 ms
• Support for both constant bit-rate (CBR) and variable bit-rate (VBR)
• Audio bandwidth from narrowband to full-band
• Support for speech and music
• Support for mono and stereo
• Support for up to 255 channels (multistream frames)
• Dynamically adjustable bitrate, audio bandwidth, and frame size
• Good loss robustness and packet loss concealment (PLC)
• Floating point and fixed-point implementation

You can read the full specification, including the reference implementation, in RFC 6716. An up-to-date implementation of the Opus standard is also available from the downloads page.

Filed under: Audio, Technology Tagged: Audio codec, Opus, Streaming media

Syndicated 2012-09-12 02:28:55 from sj4nz

Don’t Be Under the Cloud (Part Ⅰ)

Using TaskWarrior for Project Management

I know they’re sexy. They’re beautiful. They’re everywhere: To-do list and project managers like Asana, Behance’s ActionMethod and Nirvana. [You can go on forever listing these, they're easy to make, easy to market and extremely competitive.]  If they’re free, eventually you’ll run into their limitations. I especially enjoyed PivotalTracker, but they since changed their business model and it was no longer useful to me (on my budget).  Lessons learned: Free + Online always means you’re going to be vulnerable to Internet, weather, or market conditions. Get off the cloud whenever it makes sense.

Enter TaskWarrior.

I’ve always been a CLI-person, since learning UNIX back in the good ole’ days in the late ’80s.  There are just some things that are more reliable when you’re not fighting the latest GUI fashion of the day, whether it be in your web browser or your operating system.  I needed a CLI-task/project management system, something that wouldn’t require a web server to install or web browser to display. TaskWarrior (which I’ll abbreviate TW) fills that bill and I don’t have to be nagged to “upgrade” when I exceed a number of tasks or projects. I won’t regurgitate how you can use it here when there’s a very short 30-Second Tutorial and a Longer Tutorial already there to use. What I do want you to know about are the reporting features.

Shaving Milliseconds

Add:

alias tw=task

to your shell configuration and you’ll save a couple of keystrokes invoking TW.  You could use TW’s built-in “shell” command but since TW may-or-may-not have GNU Readline support built-in, it’s easer to edit and run from the shell. If you don’t make this alias, mentally replace tw with task in all of my following examples.

The Default Report and Other Reports

The default report is what is shown when you simply run tw– you’ll get a list of tasks ID, Project, Priority, Due-Date, Age, Active-Tasks, Urgency (a unique TW feature) and Description. This report is good enough to clue you into what you should be working on next and will highlight what you’re actively working on if you have started it. 

Urgency

Urgency is TW’s way of weighting tasks so they bubble up to the top of your heap. Tasks not assigned to projects aren’t as urgent as tasks that are and tasks with closer due-dates are more urgent than tasks without due-dates, and so on.  If you really want to nuance (or waste your time) urgency, you can also set priorities on your tasks.  I prefer to use wait:<duration> task-modifications to take the tasks out of my immediate horizon, giving myself permission to ignore a task, knowing that when the time comes, it will come back.

The first command you should know about is of course the report command. This tells you all the possibilities you have with TW:

• active shows you the tasks you have started.
• all shows you all the pending and completed tasks.
• blocked becomes useful when you start relating tasks to each other as being dependencies of other tasks—blocked tasks can’t be started until other tasks have been completed.
• burndown if you’re familiar with SCRUM project processes, is a view of how much left there is to a project, which can be useful for estimating completion dates.
• completed of course shows you what has been done.
• ghistory gives you a graphical bar-graph of Added, Computed and Deleted tasks. You can view it by month (the default) or annually by adding .annual to the end of the command. If you don’t want the bar graphs, use history instead.
• information is the complete laundry list of details about each task.
• list is just barely more verbose than next, but without showing Urgency.
• long will fill your terminal with task information including: ID, Project,  Priority, Added, Started, Due,      Recurring, Countdown to ready, Age, Dependencies, Tags and of course, its Description.
• ls shows the tasks by ID, Pri, Project and Description.
• minimal shows the tasks by ID, Project and Description and nothing else, it’s the same as ls without Priority.
• newest shows you the tasks you’ve added by their age.
• next is the default action when you run tw without any arguments, showing you the next actions.
• oldest is the opposite of newest and will instantly show you your greatest goals along with your worst procrastinations.
• overdue is exactly what you think it means.
• projects gives you the bird’s eye view of collections of tasks you have. It doesn’t show you the tasks, but it shows how many tasks of each priority there are in each project.
• ready appears to be the same as next.
• recurring is your life-hack to reminders of things that you have to do periodically. I use it to remind myself and track my Omega-3 supplements.
• summary gives you a feel-good progress bar view of your active projects.
• tags shows you your other task classifications other than project. You can use tags for GTD contexts or other project management concepts like tracking assignments to other people.
• unblocked shows you what’s ready to be worked on.
• waiting shows you the tasks that you have pushed into the future.

This just gives you some idea of what you can do with the reports—of course, read the tutorials so you can see how to use TW for adding, changing or removing tasks. If you have any CLI chops, I think you’ll enjoy having TaskWarrior available as a tool without having to resort to vim with a simple text file as your TODO list. Not that there is anything wrong with that…

Filed under: Software, Technology Tagged: Command-line interface, Project management, TaskWarrior

Syndicated 2012-09-07 15:45:58 from sj4nz

Looking forward to the next release of Go…

If Rob Pike says that it’s getting 50% faster, I believe it.  I’ve been noodling in it and it’s shocking how your perception of software builds changes. It felt intolerable to wait for CMake to grind through a small project compared to building the entire Go system.

Filed under: Go

Syndicated 2012-09-07 03:17:51 from sj4̄nz

Applying “Inbox Zero” to your GIT Workflow

Just as you shouldn’t let your e-mail’s inbox overwhelm you, you shouldn’t let the changes to your source code overwhelm you.  There’s nothing “proven” about Inbox Zero except that for many people, it makes their life easier.  Inbox Zero is a term coined by Merlin Mann in a talk he gave to Google in Oct 02007 with articles. In short, you do everything you can to keep the e-mail empty while maximizing the usefulness of the information there (capturing actions and reference and deleting everything else.)  In this respect, Inbox Zero is an input management system.

We already know as software developers that we “should” track the changes to our software, if for anything to enable the detection of faults as we introduce them.  If you let the changes accumulate for too long, you’ll certainly do a sinful “commit-all” to the repository, leaving yourself a giant matted hairball of change you’ll have to deal with for the rest of the life of the project (if you ever deal with it.)  Applying Inbox Zero here is a backward-looking view of what-has-been-done, your “output management system.” You’re describing it, so you can remember what you did later and communicate to others what you did, and enabling you to reproduce systems of a prior state for bug-fixes or enhancements.  There are a whole lot of ways to “do it” depending on how you work alone, with others, and with your repository.

How To “Just Do It.”

1. Run git gui in your repository.
2. Mash F5 to refresh the status of your files.
3. Choose some changed files and examine their differences—write a description of those changes.
4. Add and commit.
5. Repeat until there are no more changed files.

How To Do It… Alone.

Even if you’re not working with anyone, you should be tracking your own code for your own sanity’s sake.

1. Run git gui in your repository.
2. Mash F5 to refresh the status of your files and unit tests.
3. Choose some changed files and examine their differences—write a description of those changes to code or tests.
4. Add and commit.
5. Repeat until there are no more changed files.

How To Do It, With Others.

If you’re working with others and you have a “clean repository” rule, you’ll have to add the first step here to your workflow:

1. Run your unit tests, if they’re all passing, continue to the next step.
2. Update your repository from the master. [Everyone's team workflow is going to be different so your actions here may differ.]  Run your tests again, if they pass, go on to the next step.
3. Run git gui in your repository.
4. Mash F5 to refresh the status of your files.
5. Choose some changed files and examine their differences—write a description of those changes.
6. Add and commit.
7. Repeat until there are no more changed files to commit.
8. Start your next task.

Some organizations may designate different branches as clean or testing, the idea is that only clean passing code goes into clean branches and “work in progress” code goes into the testing branches. In either case, keeping the backlog of work-done but not yet described will go a long way to help you understand the slow hard slog of code as you or your team refines it.

Syndicated 2012-06-21 16:08:21 from sj4̄nz

Dog’s Attention.

Syndicated 2012-06-10 18:24:54 from sj4̄nz

Testing Wisdom

I’ve run into a problem where the DOM of Chrome and Firefox return different HTML results where they rearrange the attributes of elements when jQuery.html stringifys them. Don’t fight it outright with writing a bunch of code to check the existence of attribute values, etc.

Just write a “satisfies” assertion and get on with your day:

chai.expect(html).to.satisfy(
function(x) {
return (x === '<div a="1" b="2"></div>' 
     || x === '<div b="2" a="1"></div>'
   )
})

If the other browsers you’re testing in also give you grief, it is still probably easier (and faster) to just add to the satisfy’s clause than try to do a more sophisticated match.

Syndicated 2012-06-01 19:38:19 from sj4̄nz

Restarting Cinnamon in Linux Mint

Talk about a need-to-know feature. Sometimes, Cinnamon gets confused. Logging in and logging out is super disruptive to productivity, so being able to restart Cinnamon without blowing away everything you have open is a nice option to have—if you’re aware of it. It’s buried in the “Troubleshoot” menu, which I never thought to look into before. Silly me.  If you really want to get geeky, the “Looking Glass” console lets you inspect all kinds of X11 weirdness.

Syndicated 2012-05-22 04:02:37 from sj4̄nz

Eight Aspects of Software Development

Eight Aspects of Software Development

April 2008 (Unpublished; Revised 2012 and Published)

I’ve been doing software development in one way or another for many years and have explored lots of different bits of philosophy. Here is a course of practical software development. These are the things you know, improve and practice.

1. Reading and Writing — The process of writing well is the same skill-set as programming well—neither will improve without practice and neither will improve without reading quality examples. Its a matter of terminology and results. In both cases, you need a goal [what kind of thing you're making], a plan [how you're going to make it], and patterns [the types of things you do to make it]. Doodling on a notepad in writing would be like programming little snippets or prototypes for future reference or idea capture. If you were writing a short story, your programming may be the implementation of a function or algorithm. Writing a report or case study could be compared to a library in programming. Writing a novel may be compared to writing an application. Writing an office suite or enterprise system could be a multi-volume encyclopedia. Words, sentences and paragraphs: variables, statements and functions. You can only improve your writing by reading other people’s words and code. I stress other people’s because reading your own work doesn’t work—in your mind, you know what your intent was. When it comes from another mind, you’re forced to concentrate on the communication without access to their thoughts.

   Writing is a process of creating a repeatable form of communication for others. Programming is a process of creating a repeatable form of process for computers. If you’re not closely reading either words or code by others, you’re not improving your writing.

2. Programming fundamentals — Knowing how to program is all about knowing the semantics commonly used for programming. Its not the syntax, its what you say. If you are thinking about getting into programming, you will need if-then, while-loops, for-loops, functions, methods and some understanding of how information is represented.

   The fundamentals of programming are distilled into the packaging of algorithms composed of decisions, loops and arithmetic.

3. Language commitment — Choose your specializations and know the language weaknesses. I liked PHP because of its ubiquity everywhere except Windows. If the servers I worked on were based on Windows [IF... I've never seen a reliable Windows system, so why make them a server?], I would likely have to accept ASP/VisualBasic as the language to use in that environment. If I need more "research" style programming, I’ll consider Scheme or Arc. Today, I spend much more time deep in JavaScript or CoffeeScript—because that’s where most of the computers are.

   Don’t be a language zealout—but consider alternatives to exercise your understanding of programming fundamentals.

4. Design Patterns, Algorithms and Data fundamentals — Design patterns are ways of composing algorithms together for reuse. Knowing how to model data efficiently, or how to trade memory for speed and vice versa are a must. Start with a bit, add bits and meaning to store numbers, use numbers to encode symbols, and so on. Knowing what algorithms exist can help you avoid repeating work (think of a catalog of algorithms like being a free-for-all patent office, someone else has done the hard work and given it to the world and the patents are all expired.)

   If you haven’t searched for any algorithms, you’re reinventing the wheel 99% of the time.

5. Test-driven development discipline — "Trust, but verify", a signature phrase of Ronald Reagan was appropriate because of the Russian phrase: Доверяй, но проверяй. (I just like copying and pasting crazy letters… but that’s another story.) Test-driven development makes your life so much easier–you write your tests to check the operation of your program, and then you automate the execution of those tests so that you only need to worry about them when they fail. Run them often, write them continuously. If you are not writing tests, you are not programming for reliability. This is the hardest aspect to stay reliable with—because writing tests isn’t exciting to most people. You really have to treat them as the programmers TODO list:

   If you didn’t write a test, it isn’t important enough to be done.

6. Event-driven, Aspect-driven and Concurrent-distributed programming — Event driven programming is a big departure from functional programming, and aspect-driven programming is kind of like a fusion of functional programming and event-driven programming. Aspect-oriented programming isn’t taught much yet in schools, but I have found it to be a disturbingly easy way to defer the binding of "what, when and how you do it" to the run-time systems of aspect-oriented systems. Think of it like event-driving programming on more steroids than Major League Baseball. It does bring in a new set of vocabulary terms that will initially confuse you like "advice" and "pointcut", but in the end they’ll help you talk to other programmers about what you’re doing. You don’t have to have a compiler to support it, like object-oriented programming in C, you can do it on your own as well. Concurrent-distributed programming forces you to think about systems as they work together instead of in singular nodes–these are the exciting bits of programming because you can to begin thinking of your systems as being cells cooperating in an organism that comes to life. There are a lot of issues to manage in distributed systems, you’ll spend a lot of time formalizing the interactions. Some would throw the "Service Oriented Architecture" buzzword about for this kind of programming.

   Event-driven programming is valuable for software that must interact with the real-world. Functional programming ideal for making software reliable and predictable, and concurrent-distributed necessary for orchestrating collections of computers. My gut feeling is still out on aspect-oriented programming as a useful method of organizing code.

7. Source control discipline — This is where you learn discipline and earn a big assist from the computer: you’re going to let the computer track the changes to your source code. My personal choice for source control is now Linus Torvald’s GIT because of its supreme awesomeness. The borderline between backup systems and source control is more and more blurry–in other words, use your source control as your backup system, I do. Then I back that up as well.

   If isn’t worth tracking your changes, how will you be able to find "where things went wrong" in the future?

8. Tool commitment — Which editor are you using? Have you learned the 20% feature set of what you’ll use it for 80% of the time? Really well? Do it. The better you know your tools, the easier your work becomes. The less you switch between tools, the less time you’ll waste re-learning how to do things. Learn when to use the mouse and when to use the keyboard. Once a year, if you have time, evaluate all of your tools to see if they "need sharpening"– that could mean upgrading or replacing. I’m an vim convert from emacs after I realized that I wanted hardcore simplicity for text editing. Typing "c4w" becomes "change the next four words" and I didn’t have to use the mouse to select the text! Get polished with your editor and source editing starts to become a stream of consciousness or nearly automatic act. I’m not a big fan of IDE frameworks like Aptana because the tool starts to interfere with the work: especially when updates rearrange your workspace, not to mention, the time lost when the workspace spontaneously explodes from "the replacement of a small screwdriver inside." If you must use a complicated environment like Aptana, back it up with the tool you use in #7: source control–it’s not just for your source code anymore.

   Since vim, I’ve found that I need better navigation of the "files" instead of the text and I’ve switched to Sublime Text. I miss some of the keyboard-ness, but the swiss-army chainsaw ST provides makes up for it.

Syndicated 2012-05-20 14:38:00 from sj4̄nz