Forem: Bryce

5 ways to make HTML forms more accessible

Bryce — Sat, 21 Mar 2020 21:19:10 +0000

In this post I'll outline 5 easy ways to make HTML forms more accessible for visually impaired users and those using assistive technologies.

Make inputs focusable by clicking its label

Labels and inputs can be linked, so that when a user clicks the label the input will become focused; which helps visually impaired users navigate a form.

<!-- This is the best approach: -->
<label for="someinput">A label</label>
<input id="someinput" />

<!-- This is good, but it may cause the label 
text to be repeated twice by screen readers -->
<label>
  A label
  <input />
</label>

<!-- This is not so good. The label is announced 
by the screen reader but the input is not focusable 
by clicking the label  -->
<label>A label</label>
<input aria-label="A label" />

Label a group of fields with fieldset and legend

To make it clear when several inputs belong to a certain category, use the <fieldset> and <legend> elements.

This is especially important when a label does not include the group name, like in the example below.

Different screen readers treat <legend> text differently, but most will announce the text along with other details about the input.

<fieldset>
  <legend>Clothes Colors</legend>
  <label for='shirtcolor'>
    Shirt:
  </label>
  <input id="shirtcolor" />
  <label for='pantscolor'>
    Pants:
  </label>
  <input id="pantscolor" />
</fieldset>

Mark fields as required

To make it obvious for screen reader users that a field is required, use the aria-required attribute or the required attribute. Both are announced by the screen reader, but required can actually prevent the form from submitting and display an error message.

In addition, aria-hidden="true" can be used to hide an asterisk from a screen reader. Asterisks are helpful cues for someone looking at a webpage, but aren't as helpful when browsing via screen reader.

<label for="requiredinput">
  A label<span aria-hidden="true">*</span>
</label>
<input aria-required="true" id="requiredinput" />

Announce errors as they happen

By adding role="alert" to the area where input errors will appear, they will be announced to the user as they are dynamically appended to the element.

In this example, we'd use JavaScript to append an error message to the <p> when an error occurs.

Also using aria-describedby ensures the user is told about the error each time they navigate to the input.

<label for="firstname">First Name</label>
<input aria-describedby="firstname_error" id="firstname" />
<p id="firstname_error" role="alert"></p>

Make errors apparent after unsuccessful submit

If a user submits a form unsuccessfully due to errors, they should be brought to the top of the form and all errors should be listed.

It can be very helpful if each error also links to the input field for easy navigation.

In addition, adding aria-invalid="true" is a helpful cue to the user that action is needed.

<p id="firstname_error">
  <a href="#firstname">An error</a>
</p>
<form>
  <label for="firstname">First Name 
    <span class="required" aria-hidden="true">*</span>
  </label>
  <input required aria-describedby="firstname_error" aria-invalid="true" id="firstname" />
  <button>Submit</button>
</form>

That's it! If you have other form accessibility tips let me know!

A quick overview of ES2019

Bryce — Mon, 09 Mar 2020 15:47:43 +0000

ES2019 gives us several new features. Here I’ll provide an overview of the major ones -- along with any gotchas to be aware of -- and provide links to the additional minor updates.

Each of these features are available to use in v8 v7.3 & Chrome 73. Be sure to check for the support of these features when using them elsewhere.

Array.prototype.flat()

By default it will flatten one level

[1, 2, [3, 4]].flat(); 
// [1, 2, 3, 4]

[1, 2, [3, [4, 5]]].flat();
//  [1, 2, 3, [4, 5]]

You can adjust the number of levels to flatten

[1, 2, [3, [4, 5]]].flat(2);
// [1, 2, 3, 4, 5]

Gotchas

A missing item will result in undefined, if it is nested

[1, 2, [3, [4,[, 6]]]].flat(2);
// [1, 2, 3, 4, [undefined, 6]]

A missing item will be removed, if it is not nested

[1, 2, [3, [4,[, 6]]]].flat(3);
// [1, 2, 3, 4, 6]

Array.prototype.flatMap()

The value returned by the callback will be flattened one level, if it's an array

[1, 2, 3, 4].flatMap((n) => [n]);
// [1, 2, 3, 4]

[1, 2, 3, 4, 5].flatMap((n) => [[n]]);
// [[1], [2], [3], [4], [5]]

Otherwise it returns the value as is

[1, 2, 3, 4].flatMap((n) => n);
// [1, 2, 3, 4]

[[1], 2, [3], 4].flatMap((n) => n);
// [1, 2, 3, 4]

It is extremely useful if you need to filter and map values

[1, 2, 3, 4, 5].flatMap(
  (a) => a % 2 ? a + " is odd" : []
);
// ["1 is odd", "3 is odd", "5 is odd”]

Gotchas

If the a second argument is provided it becomes this

var stuff = 'stuff';

[1, 2, 3, 4, 5].flatMap(
  function(n) { 
    return `${this.stuff} ${n}`;
  },
  { stuff: 'thing' }
);
// ["thing 1", "thing 2", "thing 3", "thing 4", "thing 5"]

Object.fromEntries()

Creates an object from any iterable containing [key, value] tuples (Map, Array or custom iterable)

Object.fromEntries([['one', 1], ['two', 2], ['three', 3]]);
// { one: 1, three: 3, two: 2 }

Object.fromEntries(new Map([['one', 1]]));
// { one: 1 }

Object.fromEntries(Object.entries({ one: 1 }));
// { one: 1 }

Gotchas

Will throw an error if used with a Set

Object.fromEntries(new Set(["1"]));
// TypeError: Iterator value one is not an entry object

String.prototype.{trimStart, trimEnd}

'  hello world  '.trimStart();
// “hello world  “

'  hello world  '.trimEnd();
// “  hello world”

'  hello world  '.trimStart().trimEnd();
// “hello world”

Gotchas

trimLeft & trimRight are now aliases to trimStart & trimEnd, respectively

Optional catch binding

Catch no longer requires an error parameter, i.e. catch(error) {...}

let catchResult = 'uncaught';
try {
  throw new Error();
} catch {
  catchResult = 'caught';
}
console.log(catchResult); 
// “caught”

Gotchas

catch() is still not allowed; if () is present it must have a parameter

try {
  throw new Error();
} catch() {
  catchResult = 'caught';
} 
// SyntaxError: Unexpected token !

Other ES2019 changes

The remaining changes are either internal or don't have many use cases, but are still useful to know about...

Symbol.prototype.description
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/description

Stable Array.prototype.sort()
https://mathiasbynens.be/demo/sort-stability

Well-formed JSON.stringify()
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify#Well-formed_JSON.stringify()

JSON superset
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON#JavaScript_and_JSON_differences (see "Any JSON text is a valid JavaScript expression”)

Revised/standardized Function.prototype.toString()
https://tc39.es/Function-prototype-toString-revision/#sec-introduction

Refactoring: My 6 favorite patterns

Bryce — Wed, 04 Mar 2020 15:52:44 +0000

Refactoring code has become one of my favorite things to do as a developer. It can have a major impact on code cleanliness, readability, and maintainability.

In this post I’ll outline 6 refactoring patterns that I've found to be very useful and provide examples of each. Many are inspired by Martin Fowler's “Refactoring” book, which I highly recommend if you're looking to better understand common refactoring patterns.

(Side note: having good test coverage is also a CRUCIAL part of refactoring, but is outside the scope of this post.)

While the examples are in JavaScript, each pattern should be applicable to any programming language.

6. Introduce Object Parameter

When functions have multiple parameters, you start running into a few issues:

For the function to work correctly, the order of parameters needs to be maintained.
The names of the arguments (the actual values) passed to a function might not necessarily be the same as the parameter names, which makes searching for certain types of data/logic hard to do.
Adding/removing parameters is a chore; each use of the function needs to be examined.

To make function parameters more manageable, this pattern involves converting a list of parameters into a single object. This forces consistent parameter naming across all functions, and makes the parameter order insignificant.

// Before

function sayHello(toName, punctuation, fromName) {
  return `Hello, ${toName}${punctuation} From, ${fromName}.`
} 

sayHello(customerName, end, myName);

// After

function sayHello({ toName, punctuation, fromName }) {
  return `Hello, ${toName}${punctuation} From, ${fromName}.`
} 

sayHello({ toName, punctuation, fromName });

5. Replace Anonymous Function with Expression

In JavaScript it’s a common practice to pass an anonymous function into an array method, such as .map, .reduce, or .filter. One issue I frequently see with these anonymous functions is they become complicated and difficult to parse; and since there is no name for the function it can be difficult to quickly understand the intent of the code.

Instead, I’ve found it helpful to extract these anonymous functions into a function expression, which makes it much easier to understand the intent (this also resembles "point-free style" a.k.a. "tacit programming".).

// Before

const activeUsers = users.filter((user) => {
  if(user.lastPayment >= moment().startOf('week').toDate()) {
    return true;
  }

  return false;
});

// After

const activeUsers = users.filter(hasUserPaidThisWeek);

function hasUserPaidThisWeek(user) {
  if(user.lastPayment > moment().startOf('week').toDate() ) {
    return true;
  }

  return false;
}

4. Replace Primitive with Object

Using a primitive value such as a string, number, or boolean is a common practice in many programming languages. But problems can arise when requirements and/or rules around these primitive values become more complex.

Instead of using an uncontrolled primitive value, a helpful practice is to wrap these primitives in an object, which will give you more control over how the value is consumed and modified.

// Before

let isLoading = true;
// some code...
loading = false;

const phone = '1 617 484-4049';

const price = 11;

// After

class LoadingStatus {
  constructor(initialStatus) {
    if(!this.statusSet.has(initialStatus)) {
      throw new Error('Invalid status');
    } 

    this._status = initialStatus;
  }

  statusSet = new Set(['loading', 'success', 'error', 'idle'])

  get status() {
    return this._status;
  }

  set status(status) {
    if(!this.statusSet.has(status)) {
      throw new Error('Invalid status');
    } 

    this._status = status;
  }
}

class Phone {
  constructor(phone) {
    this._phone = this.parsePhone(phone);
  }

  parsePhone(phone) {
    const trimmedPhone = phone.trim();

    if(phone.length !== 10) {
      throw new Error('Invalid phone format');
    }

    const areaCode = trimmedPhone.slice(0,3);
    const prefix = trimmedPhone.slice(3,7);
    const lineNumber = trimmedPhone.slice(7, 10);

    return { areaCode, prefix, lineNumber };
  }

  get areaCode() {
    return this._phone.areaCode;
  }

  get formatted() {
    const { areaCode, prefix, lineNumber } = this._phone;

    return `${areaCode} ${prefix}-${lineNumber}` 
  }

  ...
}

class Price {
  constructor(price) {
    if(typeof price !== 'string') {
      throw new Error('Invalid price');
    }

    if(!(price).match(/^[0-9]*$/)) {
      throw new Error('Invalid price');
    }

    this._price = price;
  }

  get price() {
    this._price;
  }
}

3. Decompose Conditional

if/else statements can be a powerful tool when adding logic to your program. But they can also become unwieldy and confusing very quickly. One way to counteract this is by making the conditional logic easier to understand by extracting it into expressions that describe your intent.

// Before

if(user.hasEmail() && user.subscriptions.includes('email')) {
  sendEmail(user);
}

// After

const isSubscribed = user.hasEmail() && user.subscriptions.includes('email');

if(isSubscribed) {
  sendEmail(user);
}

2. Encapsulate Record (Bridge Pattern)

Most of the time building software involves consuming an existing API and/or providing your own. If your component is coupled with another API and that API changes, you may need to change your component as well; and this can sometimes be very time consuming.

Instead of coupling various APIs, I find it helpful to give each component an API that makes the most sense given its functionality, and adding a layer in between your component and any other API it is interacting with.

The Encapsulate Record refactoring pattern provides a great way to do this. This idea is also aligned with the Bridge pattern, which you can learn more about in "Design Patterns: Elements of Reusable Object-Oriented Software”.

// Before

const user = {
  name: 'A Name', 
  favorites: { 
    color: 'blue',
    food: 'pizza'
  }
}

const UserComponent = (user) => (
  <div>Name: {user.name} - Food: {user.favorites.food}</div>
);

UserComponent(user);

// After

const user = {
  name: 'A Name', 
  favorites: { 
    color: 'blue',
    food: 'pizza'
  }
}

class User {
  constructor(user) {
    this._user = user;
  }

  get name() {
    return this._user.name;
  }

  get food() {
    return this._user.favorites.food;
  }
}

const UserComponent = ({ name, food }) => (
  <div>Name: {name} - Food: {food}</div>
);

UserComponent(new User(user));

1. Replace Conditional with Polymorphism

This is probably my favorite refactoring pattern. Several times it has helped me make confusing conditional logic much more readable and maintainable. And once logic is encapsulated in an object, you then have the flexibility to utilize other OOP design patterns to help achieve your goals.

The idea here is that instead of using a bunch of nested if statements in your code, you create objects that represent different "types", and give each type method(s) that are in charge of performing certain actions. Then, the application can simply call the same method on each type, and it’s up to the type to perform the action in the correct way.

// Before

if(user.favorites.food === 'pizza') {
  sendPizzaEmail(user);
}

if(user.favorites.food === 'ice cream') {
  sendIceCreamEmail(user);
}

// After

class PizzaUser {
  constructor(user) {
    this._user = user;
  }

  sendEmail() {
    sendPizzaEmail(this._user);
  }
}

class IceCreamUser {
  constructor(user) {
    this._user = user;
  }

  sendEmail() {
    sendIceCreamEmail(this._user);
  }
}

// this would create the appropriate user using the above classes
const user = getUser(userData); 

user.sendEmail()

That's it! Happy refactoring!

How to debug unnecessary rerenders in React

Bryce — Sun, 09 Feb 2020 22:20:44 +0000

When developing in React, you will likely run into scenarios where components are rerendering more than you would expect; which can have a direct impact on an application's perceived performance.

And with the introduction of React Hooks, developers now have even more ways to inadvertently trigger rerenders (looking at you useEffect!).

Thankfully React gives developers several tools to help them find the source of unnecessary rerenders. In this post I'll discuss three of them: DevTools Profiler, React.memo, and React.Profiler.

DevTools Profiler

DevTools Profiler is a fantastic browser plugin that is currently available in Chrome & Firefox (there is also a Node version). Check out the docs to learn more about specific features.

Version 4 of React DevTools -- released August 15, 2019 -- came with a great new feature called "Why did this render?".

To use this tool, simply install Profiler and turn on the "Record why each component rendered while profiling." option. You can then run Profiler while interacting with your app, focusing on whichever components may be rendering unnecessarily.

After you end the Profiler session, you'll be able to drill down into individual components to see their render metrics. Under the "Why did this render?" heading you'll see a list of reasons the component rendered/rerendered.

Common reasons for rerendering:

Hooks changing (ie useState's setState methode being called)
props changing (it will list the exact props!)
a component's parent rerendering

Of all the debugging tools, I'd say this is the easiest and fastest to set up and use. But there is one shortcoming: there is no way to inspect the value of the props that changed; and it's often helpful to be able to inspect prop values to get a better understanding of what is changing, and why.

To get this data you can use another tool: React.memo.

React.memo

React v16.6.0 gave us a new React.memo method that can be used with both functional and class-based components to give us more control over rerenders, similar to the shouldComponentUpdate class component method. Not only is it a good tool for controlling rerenders, it can also be a helpful tool when trying to find the cause of rerenders.

The key to debugging rerenders is to use the second optional argument of React.memo which is an "isEqual" function that takes two arguments, prevProps and nextProps, and gives you control over whether a component should change. See the React docs for memo for more details.

Now with access to prevProps and nextProps, you can easily view what is changing and determine the root cause of rerenders:

const memoizedComponent = React.memo(MyComponent, 
  (prevProps, nextProps) => {

    console.log(prevProps.thing === nextProps.thing);

    /*
      When using this function you always need to return
      a Boolean. For now we'll say the props are NOT equal 
      which means the component should rerender.
    */
    return false;
  }
)

Side note: while you can use React.memo to manually prevent rerenders once you find the issue, I highly recommend dealing with the root cause -- which is more often than not a prop that is being unnecessarily recreated on every render. Otherwise you'll end up band-aiding every component with React.memo which will result in lots equality checks, plus data being stored in memory.

React.Profiler

Finally, let's take a look at the React.Profiler API, which gives developers additional data points that can be used to debug performance issues.

With React.Profiler, developers can wrap their JSX elements with a <Profiler> component, which takes two props:

id - a unique identifies for the section being profiled.
onRender - a callback function to be called on every render. Check out the docs for a full list of the callback parameters.

return (
  <Profiler 
    id="test1" 
    onRender={(...args) => {
      { [1]: phase, [2]: actualDuraction } = args;

      console.log({ phase, actualDuration })
    }}
  >
    <App />
  </Profiler>
);

Here a few things you can check when debugging rerenders using React.Profiler:

Ensure a component never reverts to the mount phase after the initial render; it should always be updated.
The actualDuraction should go down after the initial render. If it stays the same or goes up, you are likely not rendering children efficiently.
To better understand which action is triggering a rerender, you can track timestamps of multiple actions and see which correlate with the startTime.
baseDuration will tell you the worst case scenario when a component rerenders. Components with the highest baseDuration are the ones you want to pay extra attention to when optimizing rerenders.

That's it! Happy debugging!

Productivity habits for software developers

Bryce — Sat, 08 Feb 2020 21:27:38 +0000

Writing code is fast. And a few lines of code is capable of doing incredible things. Then why can building software take so long?

While I can't give a concrete answer to that question, over the years I have found several areas where employing certain habits can significantly boost developers' productivity.

In this post I'll outline some of these habits, and provide a few resources for stepping up your productivity game.

Understanding Requirements

When we are writing software we are usually trying to meet a set of requirements, often provided by another person. In order to be productive, we need to "produce" working code that meets those requirements.

Generally understanding the requirements is not the time consuming part, the producing part is. And if you produce a solution that does not meet the requirements, you will have to go back and produce more code. Nothing will waste your time more than working on the wrong thing.

Alternatively, if you take extra time to review and understand the requirements it can significantly lessen the amount of rework on a given task.

Good habits to follow:

If requirements are written down, read them 2-3 times. If they are not, write them down so at the very least you are clear on what you're delivering.
Always spend time brainstorming any assumptions you can think of and write those down as well. Get clarification on these assumptions before writing any code.
If requirements change, be sure to update the written requirements so everyone is clear (including you) on what to expect from your work.

Designing Before You Code

Once you have your set of requirements, it can be tempting to jump straight into coding. Don't do it! Code needs to not only be written, but designed. Whether you are adding code to an existing codebase or starting on a brand new project, it should be done according to a design.

Understanding and following a design from the get-go can have a significant impact on your productivity, and will often prevent you from painting ourself into a corner. Without planning and designing your approach you'll need to rely on trial and error to get something to work which is incredibly inefficient, can result in both rework and excess troubleshooting, and may go against previously established designs and patterns.

Once you've developed your initial plan, your planning is still not done. Things will change, realizations will be had, and you'll probably need to modify your plan; and that's OK! As long as you are following and iterating on your plan you'll be much more productive than the alternative.

Good habits to follow:

Write down your plan in the form of comments in your code. Every function, file, or variable that you think you'll touch should have some sort of comment around what you plan to do.
Draw pictures of the existing design and/or the design you plan to implement.
Review your plan with a colleague.
Do a proof of concept if you're not 100% sure how something will work.

Breaking Down Work

Another aspect of planning is understanding what you'll be doing and when. To do this you should break your work into chunks -- each equating to one small/medium sized pull request -- and decide the sequence which you'll work on them.

When starting on a particular "chunk" it can also be helpful to break it down further into subtasks. Having a small manageable task can reduce the barrier to entry when starting work, and makes it easy to jump back in when you've lost context for a while.

You will be much more productive once you've removed the mental overhead of deciding what your next immediate task is, which is a very common distraction.

Good habits to follow:

Keep your chunks of work visible so people know what you're working on and can hold you accountable.
Reduce the burden of context switching by breaking your work into small tasks, or at the very least writing yourself a note when you are about to switch contexts.

Over-communicating

Communicating early and often about your work can not only boost productivity, but is also essential for career growth; strong communication is an invaluable skill for developers. It is one of the best ways to prevent rework, and can save you from many hours of troubleshooting.

Often colleagues will have amazing insights into not only how to solve a problem, but what the right problem is to be solving. Communicating about what you're working on opens up the door for lots of helpful feedback and help.

Good habits to follow:

Track your work in a place that is visible to everyone, and keep it up to date.
Review work with other project stakeholders frequently so you can incorporate their feedback early.
Be proactive about asking questions around your approach as well as your code.
Communicate potential trade-offs (something businesses rely heavily on developers for) and loop in stakeholders so they can help decide the best solution.

Hibernating

Once you have your design, established a plan, written down your tasks, and collected feedback...hibernate! You will be most productive when you have a distraction free environment, and this should be a top priority if you want to be productive on a daily basis.

Do what you need to do -- block off your calendar, put on headphones, go to a coffee shop -- to get a few hours to focus and into a "flow" state. This is when your work actually gets done and is probably the most important aspect of being productive as a developer.

Good habits to follow:

Know your best working hours and develop a schedule where you are able to work during that time.
Let teammates know when you'll be unavailable and why, so you don't feel guilty ignoring emails or messages.

Testing & Refactoring

Writing tests as you code probably won't save you multiple hours of coding, it will save you multiple WEEKS! It can be hard to see the benefit in writing tests when you are initially building something since it increases the time required to complete a feature. But it does help in two specific ways: 1) framing the problem you are trying to solve, and 2) making refactoring less error-prone.

When you've properly framed your problem it becomes much harder to end up working on irrelevant tasks, which is probably one of the most common distractions and productivity killer for developers.

Refactoring code is a crucial tool for staying productive; it's one of the best ways to quickly understand how things are working both now and in the future (and your colleagues will thank you). Being able refactor without the risk of breaking things is a great way to boost productivity.

Good habits to follow:

If possible try to use test driven development when writing code.
Keep track of test coverage; high coverage increases the ease of refactoring.
Separate your chunks of work into refactoring OR feature/bug development work, not both at once.
Focus on functionality and tests first, then refactor for cleanliness and readability.

Knowing Your Tools

Whatever tools you use, make sure you have a deep understanding of how they work. If you don't, set time aside to learn them. Examples of things you should know are: keyboard shortcuts, automation tools, framework APIs, programming language quirks, and the list goes on.

Using your tools in a streamlined way will likely only save you a few minutes per day, but this time really adds up over multiple months. Taking a few hours away from work to understand your tools will pay major dividends after using those tools over long periods of time.

Good habits to follow:

Automate as much as possible. Terminal aliases are a fast and easy way to automate parts of your workflow.
Invest serious time into learning, and staying up to date, on any programming language(s) you use frequently.
Before you use a library/framework, read the docs! Even if you won't be using all of the features, it's extremely helpful to understand the surface area; you never know what features will come in handy and save you time.

Managing Time Efficiently

This seems like an obvious way to boost productivity, but it's easier said than done. As a developer you'll likely only have 2-5 hours a day to "produce", so you need to make those hours count.

Be conscious of how you are spending your time. One hour of extremely focused time can be much more valuable than multiple hours of unfocused time. If there are particular things you find yourself wasting time on repeatedly, write them down and figure out ways to reduce that time.

Good habits to follow:

Don't pre-optimize or write super generalized/flexible code, until it's absolutely needed.
DO optimize for simplicity. Make code easy to read with minimal complexity.
Take breaks. Sometimes the best solutions to problems come to us during breaks, not while writing code.
Commit often so you're not keeping track of large sets of changes.
Don't be afraid to wipe out changes if you get stuck or aren't sure you're building the right thing.
Capture additional work in your notes, but put it aside to work on later.
Use a system like GTD (Getting Things Done) to help manage a variety of tasks, both development and non-development related.

Conclusion

While these habits are relatively simple, making them part of your daily routine can be quite a challenge. Try to pay extra attention to how you are spending your time each day. When you are doing something that you shouldn't, take note and be sure to work on it again the following day.

While I personally have benefited from many of these habits, I find myself falling back to bad habits all of the time. Writing down your habits and/or discussing them with colleagues is a great way to keep them top of mind.

Additional Resources

Here are a few resources that I've found very helpful when trying to optimize productivity.

Books

The War of Art by Steven Pressfield
Getting Things Done by Davis Allen
Atomic Habits by James Clear

Software

Trello (trello.com) - for task management (although Jira is a more popular tools for development teams).
Evernote (evernote.com) - for storing notes, documentation, cheat sheets, etc.

Techniques

Pomodoro - break work into 25 min increments with 5 min breaks.
GTD - learn more in David Allen's Getting Things Done book.
"Eat the frog" - a phrase derived from a quote by Mark Twain encouraging you to start the day by working on the most important/difficult task. There is also a book (which I haven't read) called Eat That Frog! by Brian Tracy.