Basanta Thapa's Blog

Here are some tips on how to stay focused as you move through the workday, while still enjoying all the unique benefits of working at home.

---

1. Respect Your Own Time

---

When you work at an office, family and friends seem to naturally respect your schedule. But when you’re working from home, you’ll inevitably get calls at 11:00 a.m. or be expected to handle the daily errands. I’m not saying you shouldn’t wait for the cable appointment or chat on the phone, but be mindful of how easy it is to have time ripped from your workday.

It’s important to set boundaries, if needed. People will respect your schedule, only if you respect it first.

---

2. Impose Time Limits on Specific Tasks

---

It’s easy to become distracted, particularly when dealing with a task that’s challenging or a bit dull. If you find yourself losing focus, tell yourself to dedicate just 15 more minutes to the task on hand. Knowing there’s an end in sight might inject new energy into the project. And if not, move on to something else and return to it when you’re in a better mindset.

---

3. Set Strict Deadlines

---

Ever wonder why you’re ultra productive when facing a tight deadline, while a simple task can take hours to complete? You might chalk this up to working well under pressure, but it could also be Parkinsons Law, which basically states that a task will expand to fill the time you can give it. Combat this phenomenon by imposing your own deadlines for specific tasks. These can be as complicated as finishing a proposal or as simple as responding to a client email.

---

4. Log Off for “Power Productivity” Hours

---

Digital distractions aren’t just limited to Facebook and YouTube. For most, the daily barrage of emails and IMs from friends and colleagues ends up being the day’s biggest time sink. If you’re stuck in your inbox, dedicate chunks of the day when you unplug from your phone and email to get work done. You can log back on afterward and power through the necessary responses.

---

5. Delineate Your Workspace

---

Ideally you can have an area dedicated as your office (and preferably with a door so you can shut out unwanted distractions). Creating boundaries not only helps you be more productive “at work,” but also helps you decompress during your personal time.

---

6. Slowing Down? Change Your Environment

---

If you find yourself stuck (and you’ve already tried the “just 15 more minutes” tactic), change your environment. Go work at the café for an hour, or brainstorm at the park. A change in scenery can spark new ideas and give you newfound focus.

---

7. Conduct a Time Audit

---

Ever finish up the day and wonder where your time went? If you’re self-employed, it’s important to understand exactly how you’re using your time. Every so often, conduct a detailed audit of your day and keep track of what you did and how long it took. These audits can reveal great insights into your daily workflow and can help you make adjustments where needed — whether it’s getting help for your bookkeeping, dropping an overly demanding client, or condensing multiple trips to the grocery store.

---

8. Create Task Lists

---

I tend to have multiple lists running at any given time. One list keeps track of longer term goals (for example, the projects I need to complete by the end of the week or month). Then each morning I also create a focused outline for the day’s tasks. Try to keep your daily list as realistic and uncluttered as possible. Nothing can sap your motivation like staring at an overly ambitious list full of items you can’t possibly complete.

---

9. Make Your Breaks Count

---

Whether you’re working at home or in the office, it’s not possible to stay focused for hours on end. Breaks are an integral part of the workday, but make sure your free time counts. Have you ever denied yourself a trip to the gym or lunch with a friend “because you’re too busy?”

Chances are that on that very same day, you spent well over an hour browsing eBay, watching TV, looking at Facebook, checking your online bank account, or organizing your medicine cabinet. Busy work doesn’t accomplish anything and won’t recharge your batteries. So take your dog for a hike, take an actual lunch, or do whatever you enjoy. You’ll not only end up being happier, but more productive as well.

Source: http://mashable.com/2011/05/26/work-from-home-productivity/

Generics is a Java feature that was introduced with Java SE 5.0 and, few years after its release, I swear that every Java programmer out there not only heard about it, but used it. There are plenty of both free and commercial resources about Java generics and the best sources I used are:

• The Java Tutorial
• Java Generics and Collections, by Maurice Naftalin and Philip Wadler
• Effective Java (second edition), by Joshua Bloch.

Despite the wealth of information out there, sometimes it seems to me that many developers still don’t understand the meaning and the implications of Java generics. That’s why I’m trying to summarize the basic information developers need about generics in the simplest possible way.

The Motivation for Generics

The simplest way to think about Java generics is thinking about a sort of a syntactic sugar that might spare you some casting operation:

List box = ...;
Apple apple = box.get(0);

The previous code is self-speaking: box is a reference to a List of objects of type Apple. The get method returns an Apple instance an no casting is required. Without generics, this code would have been:

List box = ...;
Apple apple = (Apple) box.get(0);

Needless to say, the main advantage of generics is having the compiler keep track of types parameters, perform the type checks and the casting operations: the compiler guarantees that the casts will never fail.

Instead of relying on the programmer to keep track of object types and performing casts, which could lead to failures at runtime difficult to debug and solve, the compiler can now help the programmer enforce a greater number of type checks and detect more failures at compile time.

The Generics Facility

The generics facility introduced the concept of type variable. A type variable, according to the Java Language Specification, is an unqualified identifier introduced by:

• Generic class declarations
• Generic interface declarations
• Generic method declarations
• Generic constructor declarations.

Generic Classes and Interfaces

A class or an interface is generic if it has one or more type variable. Type variable are delimited by angle brackets and follow the class (or the interface) name:

public interface List extends Collection {
...
}

Roughly speaking, type variables act as parameters and provide the information the compiler needs to make its checks.

Many classes in the Java library, such as the entire Collections Framework, were modified to be generic. The List interface we’ve used in the first code snippet, for example, is now a generic class. In that snippet, box was a reference to a List object, an instance of a class implementing the List interface with one type variable: Apple. The type variable is the parameter that the compiler uses when automatically casting the result of the get method to an Apple reference.

In fact, the new generic signature or the get method of the interface List is:

T get(int index);

The method get returns indeed an object of type T, where T is the type variable specified in the List declaration.

Generic Methods and Constructors

Pretty much the same way, methods and constructors can be generic if they declare one or more type variables.

public static  T getFirst(List list)

This method will accept a reference to a List and will return an object of type T.

Examples

You can take advantage of generics in both your own classes or the generic Java library classes.

Type Safety When Writing…

In the following code snippet, for example, we create an instance List of populate it with some data:

List str = new ArrayList();
str.add("Hello ");
str.add("World.");

If we tried to put some other kind of object into the List, the compiler would raise an error:

str.add(1); // won't compile

… and When Reading

If we pass the List reference around, we’re always guaranteed to retrieve a String object from it:

String myString = str.get(0);

Iterating

Many classes in the library, such as Iterator, have been enhanced and made generic. The iterator() method of the interface List now returns an Iterator that can be readily used without casting the objects it returns via its T next() method.

for (Iterator iter = str.iterator(); iter.hasNext();) {
String s = iter.next();
System.out.print(s);
}

Using foreach

The for each syntax takes advantage of generics, too. The previous code snippet could be written as:

for (String s: str) {
System.out.print(s);
}

that is even easier to read and maintain.

Autoboxing and Autounboxing

The autoboxing/autounboxing features of the Java language are automatically used when dealing with generics, as shown in this code snippet:

List ints = new ArrayList();
ints.add(0);
ints.add(1);

int sum = 0;
for (int i : ints) {
sum += i;
}

Be aware, however, that boxing and unboxing come with a performance penalty so the usual caveats and warnings apply.

Subtypes

In Java, as in other object-oriented typed languages, hierarchies of types can be built:

In Java, a subtype of a type T is either a type that extends T or a type that implements T (if T is an interface) directly or indirectly. Since “being subtype of” is a transitive relation, if a type A is a subtype of B and B is a subtype of C, then A will be a subtype of C too. In the figure above:

• FujiApple is a subtype of Apple
• Apple is a subtype of Fruit
• FujiApple is a subtype of Fruit.

Every Java type will also be subtype of Object.

Every subtype A of a type B may be assigned to a reference of type B:

Apple a = ...;
Fruit f = a;

Subtyping of Generic Types

If a reference of an Apple instance can be assigned to a reference of a Fruit, as seen above, then what’s the relation between, let’s say, a List and a List? Which one is a subtype of which? More generally, if a type A is a subtype of a type B, how does C<A> and C relate themselves?

Surprisingly, the answer is: in no way. In more formal words, the subtyping relation between generic types is invariant.

This means that the following code snippet is invalid:

List apples = ...;
List fruits = apples;

and so does the following:

List apples;
List fruits = ...;
apples = fruits;

But why? Is an apple is a fruit, a box of apples (a list) is also a box of fruits.

In some sense, it is, but types (classes) encapsulate state and operations. What would happen if a box of apples was a box of fruits?

List apples = ...;
List fruits = apples;
fruits.add(new Strawberry());

If it was, we could add other different subtypes of Fruit into the list and this must be forbidden.

The other way round is more intuitive: a box of fruits is not a box of apples, since it may be a box (List) of other kinds (subtypes) of fruits (Fruit), such as Strawberry.

Is It Really a Problem?

It should not be. The strongest reason for a Java developer to be surprised is the inconsistency between the behavior of arrays and generic types. While the subtyping relations of the latter is invariant, the subtyping relation of the former is covariant: if a type A is a subtype of type B, then A[] is a subtype of B[]:

Apple[] apples = ...;
Fruit[] fruits = apples;

But wait! If we repeat the argument exposed in the previous section, we might end up adding strawberries to an array of apples:

Apple[] apples = new Apple[1];
Fruit[] fruits = apples;
fruits[0] = new Strawberry();

The code indeed compiles, but the error will be raised at runtime as an ArrayStoreException. Because of this behavior of arrays, during a store operation, the Java runtime needs to check that the types are compatible. The check, obviously, also adds a performance penalty that you should be aware of.

Once more, generics are safer to use and “correct” this type safety weakness of Java arrays.

In the case you’re now wondering why the subtyping relation for arrays is covariant, I’ll give you the answer that Java Generics and Collections give: if it was invariant, there would be no way of passing a reference to an array of objects of an unknown type (without copying every time to an Object[]) to a method such as:

void sort(Object[] o);

With the advent of generics, this characteristics of arrays is no longer necessary (as we’ll see in the next part of this post) and should indeed by avoided.

Wildcards

As we’ve seen in the previous part of this post, the subtyping relation of generic types is invariant. Sometimes, though, we’d like to use generic types in the same way we can use ordinary types:

• Narrowing a reference (covariance)
• Widening a reference (contravariance)

Covariance

Let’s suppose, for example, that we’ve got a set of boxes, each one of a different kind of fruit. We’d like to be able to write methods that could accept a any of them. More formally, given a subtype A of a type B, we’d like to find a way to use a reference (or a method parameter) of type C<B> that could accept instances of C.

To accomplish this task we can use a wildcard with extends, such as in the following example:

List apples = new ArrayList();
List fruits = apples;

? extends reintroduces covariant subtyping for generics types: Apple is a subtype of Fruit and List<Apple> is a subtype of List<? extends Fruit>.

Contravariance

Let’s now introduce another wildcard: ? super. Given a supertype B of a type A, then C<B> is a subtype of C<? super A>:

List fruits = new ArrayList();
List = fruits;

How Can Wildcards Be Used?

Enough theory for now: how can we take advantage of these new constructs?

? extends

Apple[] apples = new Apple[1];
Fruit[] fruits = apples;
fruits[0] = new Strawberry();

As we saw, this code compiles but results in a runtime exception when trying to add a Strawberry to an Apple array through a reference to a Fruit array.

Now we can use wildcards to translate this code to its generic counterpart: since Apple is a subtype of Fruit, we will use the ? extends wildcard to be able to assign a reference of a List<Apple> to a reference of a List<? extends Fruit> :

List apples = new ArrayList();
List fruits = apples;
fruits.add(new Strawberry());

This time, the code won’t compile! The Java compiler now prevents us to add a strawberry to a list of fruits. We will detect the error at compile time and we won’t even need any runtime check (such as in the case of array stores) to ensure that we’re adding to the list a compatible type. The code won’t compile even if we try to add a Fruit instance into the list:

fruits.add(new Fruit());

No way. It comes out that, indeed, you can’t put anything into a structure whose type uses the ? extends wildcard.

The reason is pretty simple, if we think about it: the ? extends T wildcard tells the compiler that we’re dealing with a subtype of the type T, but we cannot know which one. Since there’s no way to tell, and we need to guarantee type safety, you won’t be allowed to put anything inside such a structure. On the other hand, since we know that whichever type it might be, it will be a subtype of T, we can get data out of the structure with the guarantee that it will be a T instance:

Fruit get = fruits.get(0);

? super

What’s the behavior of a type that’s using the ? super wildcard? Let’s start with this:

List fruits = new ArrayList();
List = fruits;

We know that fruits is a reference to a List of something that is a supertype of Apple. Again, we cannot know which supertype it is, but we know that Apple and any of its subtypes will be assignment compatible with it. Indeed, since such an unknown type will be both an Apple and a GreenApple supertype, we can write:

fruits.add(new Apple());
fruits.add(new GreenApple());

If we try to add whichever Apple supertype, the compiler will complain:

fruits.add(new Fruit());
fruits.add(new Object());

Since we cannot know which supertype it is, we aren’t allowed to add instances of any.

What about getting data out of such a type? It turns out that you the only thing you can get out of it will be Object instances: since we cannot know which supertype it is, the compiler can only guarantee that it will be a reference to an Object, since Object is the supertype of any Java type.

The Get and Put Principle or the PECS Rule

Summarizing the behavior of the ? extends and the ? super wildcards, we draw the following conclusion:

• Use the ? extends wildcard if you need to retrieve object from a data structure
• Use the ? super wildcard if you need to put objects in a data structure
• If you need to do both things, don’t use any wildcard.

This is what Maurice Naftalin calls The Get and Put Principle in his Java Generics and Collections and what Joshua Bloch calls The PECS Rule in his Effective Java

Bloch’s mnemonic, PECS, comes from “Producer Extends, Consumer Super” and is probably easier to remember and use.

Source & References: http://www.javacodegeeks.com/2011/04/java-generics-quick-tutorial.html