Eclipse Auto Activation

Auto Activation triggers for Java to be more like Xcode Auto-completion:

Go To Window > Preferences > Java > Editor > Content Assist


Auto Activation Delay (ms): 1000

Auto activation triggers for Java: .(abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ

Auto activation triggers for Javadoc: @#


I like a slower delay because sometimes Eclipse will autocomplete when you don’t want it to. For instance, try to type String str = with a fast delay (50) and it will autocomplete to String string =.



Making Eclipse’s autocomplete behave more like Xcode

SO A: Type ahead autocompletion Eclipse


What are anti-patterns?


An anti-pattern is a recurring software design that is counterproductive to general software development goals and best-practices.

Or a more literal definition:

A software design pattern is a general reusable solution for a particular context.  So anti (opposite or against) that would be a pattern that creates a non-general non-reusable solution.

Other Definitions:

Alphabetical Anti-pattern list:  (See Anti-Pattern Examples for a categorized list)

  • Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
  • Accidental complexity: Introducing unnecessary complexity into a solution
  • Action at a distance: Unexpected interaction between widely separated parts of a system
  • Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
  • Analysis paralysis: Devoting disproportionate high effort to the analysis phase of a project
  • Avalanche: An inappropriate mashup of the Waterfall model and Agile Development techniques
  • BaseBean: Inheriting functionality from a utility class rather than delegating to it
  • Big ball of mud: A system with no recognizable structure
  • Blind faith: Lack of checking of (a) the correctness of a bug fix or (b) the result of a subroutine
  • Boat anchor: Retaining a part of a system that no longer has any use
  • Busy waiting: Consuming CPU while waiting for something to happen, usually by repeated checking instead of messaging
  • Bystander apathy: When a requirement or design decision is wrong, but the people who notice this do nothing because it affects a different group of people
  • Call super: Requiring subclasses to call a superclass’s overridden method
  • Caching failure: Forgetting to reset an error flag when an error has been corrected
  • Cargo cult programming: Using patterns and methods without understanding why
  • Cash cow: A profitable legacy product that often leads to complacency about new products
  • Circle-ellipse problemSubtyping variable-types on the basis of value-subtypes
  • Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
  • Coding by exception: Adding new code to handle each special case as it is recognized
  • Constant interface: Using interfaces to define constants
  • Copy and paste programming: Copying (and modifying) existing code rather than creating generic solutions
  • Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
  • Death march: Everyone knows that the project is going to be a disaster – except the CEO – so the truth is hidden to prevent immediate cancellation of the project – (although the CEO often knows and does it anyway to maximize profit). However, the truth remains hidden and the project is artificially kept alive until the Day Zero finally comes (“Big Bang”). Alternative definition: Employees are pressured to work late nights and weekends on a project with an unreasonable deadline.
  • Dependency hell: Problems with versions of required products
  • Design by committee: The result of having many contributors to a design, but no unifying vision
  • DLL hell: Inadequate management of dynamic-link libraries (DLLs), specifically on Microsoft Windows
  • Error hiding: Catching an error message before it can be shown to the user and either showing nothing or showing a meaningless message. Also can refer to erasing the Stack trace during exception handling, which can hamper debugging.
  • Escalation of commitment: Failing to revoke a decision when it proves wrong
  • Extension conflict: Problems with different extensions to pre-Mac OS X versions of the Mac OS attempting to patch the same parts of the operating system
  • Golden hammer: Assuming that a favorite solution is universally applicable (See: Silver Bullet)
  • Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
  • God object: Concentrating too many functions in a single part of the design (class)
  • Groupthink: During groupthink, members of the group avoid promoting viewpoints outside the comfort zone of consensus thinking
  • Hard code: Embedding assumptions about the environment of a system in its implementation
  • Improbability factor: Assuming that it is improbable that a known error will occur
  • Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
  • Input kludge: Failing to specify and implement the handling of possibly invalid input
  • Interface bloat: Making an interface so powerful that it is extremely difficult to implement
  • Invented Here: The tendency towards dismissing any innovation or less than trivial solution originating from inside the organization, usually because of lack of confidence in the staff
  • JAR hell: Overutilization of the multiple JAR files, usually causing versioning and location problems because of misunderstanding of the Java class loading model
  • Lasagna code: Programs whose structure consists of too many layers
  • Lava flow: Retaining undesirable (redundant or low-quality) code because removing it is too expensive or has unpredictable consequences[5][6]
  • Loop-switch sequence: Encoding a set of sequential steps using a switch within a loop statement
  • Magic numbers: Including unexplained numbers in algorithms
  • Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction
  • Magic strings: Including literal strings in code, for comparisons, as event types etc.
  • Management by perkele: Authoritarian style of management with no tolerance of dissent
  • Management by objectives: Management by numbers, focus exclusively on quantitative management criteria, when these are non-essential or cost too much to acquire
  • Moral hazard: Insulating a decision-maker from the consequences of his or her decision
  • Mushroom management: Keeping employees uninformed and misinformed; employees are described as being kept in the dark and fed manure, left to stew, and finally canned
  • Not Invented Here (NIH) syndrome: The tendency towards reinventing the wheel (Failing to adopt an existing, adequate solution)
  • Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
  • Object *: Failing to properly encapsulate objects permitting unrestricted access to their internals
  • Overengineering: Spending resources making a project more robust and complex than is needed
  • Poltergeists: Objects whose sole purpose is to pass information to another object
  • Premature optimization: Coding early-on for perceived efficiency, sacrificing good design, maintainability, and sometimes even real-world efficiency
  • Programming by permutation (or “programming by accident”, or “programming by coincidence”): Trying to approach a solution by successively modifying the code to see if it works
  • Race hazard: Failing to see the consequence of different orders of events
  • Reinventing the square wheel: Failing to adopt an existing solution and instead adopting a custom solution which performs much worse than the existing one
  • Repeating yourself: Writing code which contains repetitive patterns and substrings over again; avoid with once and only once (abstraction principle)
  • Stovepipe or Silos: A structure that supports mostly up-down flow of data but inhibits cross organizational communication
  • Vendor lock-in: Making a system excessively dependent on an externally supplied component[4]
  • Scope Creep: Uncontrolled changes or continuous growth in a project’s scope, or adding new features to the project after the original requirements have been drafted and accepted. (Also known as requirement creep and feature creep.)
  • Sequential coupling: A class that requires its methods to be called in a particular order
  • Shotgun surgery: Developer adds features to an application codebase which span a multiplicity of implementors or implementations in a single change.
  • Silver bullet: Assuming that a favorite technical solution can solve a larger process or problem
  • Smoke and mirrors: Demonstrating unimplemented functions as if they were already implemented
  • Soft code: Storing business logic in configuration files rather than source code[7]
  • Software bloat: Allowing successive versions of a system to demand ever more resources
  • Spaghetti code: Programs whose structure is barely comprehensible, especially because of misuse of code structures
  • Stovepipe system: A barely maintainable assemblage of ill-related components
  • Tester Driven Development: Software projects in which new requirements are specified in bug reports
  • Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation



I created a Chrome Extension that can be downloaded here.

Unzip it, go to Chrome >  Click Tool icon > Tools > Extensions. Check Developer Mode. Select “Load Unpacked Extension” and browse to the extracted folder.

Omnibox Usage:

mailto user@email.com this is the message

Then gmail will open with the composer with autofilled email and message, all that’s left is to press send.

mailto on GitHub



Strategy Pattern

Head First Design Patterns

Interestingly enough the Head First Design Patterns book teaches the strategy pattern using the Duck example yet the example itself ends up being more than strategy pattern as it uses context inheritance as well which is not part of strategy pattern. Subclassing Duck is subclassing the context which is not part of strategy pattern. See my question on Programmers Stack Exchange: Is context inheritance, as shown by Head First Design Patterns’ Duck example, irrelevant to strategy pattern? for more info.

Here are some simpler examples you can fall back. These stick strictly to strategy pattern.


Hunter.java [GitHub src]:

public class Hunter
    Hunt huntStrategy;

    Hunter(Hunt huntStrategy) {
	this.huntStrategy = huntStrategy;

    public void hunt() {

    public void setHuntStrategy(Hunt huntStrategy) {
	this.huntStrategy = huntStrategy;

    public static void main(String[] args) {
	Hunt hunt = new SpearHunt();
	Hunter hunter = new Hunter(hunt);

	hunt = new RifleHunt();

	hunt = new KnifeHunt();

interface Hunt
    public void hunt();

class SpearHunt implements Hunt
    public void hunt() {
	System.out.println("Hunting with Spear");

class RifleHunt implements Hunt
    public void hunt() {
	System.out.println("Hunting with Rifle");

class KnifeHunt implements Hunt
    public void hunt() {
	System.out.println("Hunting with Knife");


solver.py [StackOverflow src]

def strategy_add(a, b):
    return a + b

def strategy_minus(a, b):
    return a - b

solver = strategy_add
print solver(1, 2)
solver = strategy_minus
print solver(2, 1)