Game Theme Generator

My first npm module. Nothing too fancy, but a small utility that I use to spark my game maker creativity. Does that even exist?

Did you ever want to make a small game and you had no clue where to start? No? Well, I did.
But now you can just write gametheme in your terminal and get thinking. It will put your brain within the restrictions of a game theme chosen specially for you!

OK … It is randomly chosen … but only for you! ūüėČ

If the fancy badge above is not enough, you can go directly to the NPM page.

Contributions are more than welcome! Checkout the Github repository.

Thank you to the¬†Ludum Dare¬†community, which is always bringing up some cool themes. Don’t wonder if the themes chosen for you are very familiar ūüėČ

Posted in JavaScript, NodeJS, Technology | Tagged , , , | Leave a comment

2014 in review

A small thank you to WordPress.com for hosting this blog and everyone that viewed it through the last years. You are awesome!

The WordPress.com stats helper monkeys prepared a 2014 annual report for this blog.

Here’s an excerpt:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 9,100 times in 2014. If it were a concert at Sydney Opera House, it would take about 3 sold-out performances for that many people to see it.

Click here to see the complete report.

Posted in Technology | Leave a comment

AngularJS + KineticJS = Stage Directive

In the last days I came across an interesting canvas library called Kinetic.js, which called my attention by its easy API. Even though the library provides some complex functionality, like drag and drop, it still feels a pleasure to work with it.
Let me show you how to integrate that with angularjs!
What we need to create is a simple directive called Stage that will
setup a new Kinetic.Stage for us.

Continue reading

Posted in AngularJS, Directives, JavaScript, Technologien, Technology, Web, Web development | Tagged , , , , , , , , , , , , , | Leave a comment

Refactoring vs Performance

Refactoring is for readability, not for performance.

Performance can and should be measured.
Performance optimization has to come from a data based approach.

Readability cannot be measured. It is therefore even more important to keep improving it, because you can’t prove when it is already good enough.

Refactoring should be part of every software development time plan. From the start.

Posted in Technologien, Web development | Tagged , , , , , , | Leave a comment

Using LiveReload with Chrome and Sublime Text 2

How to use LiveReload with Chrome and Sublime Text 2?

Assuming that you already know how to use Sublime Text 2 with its Package Control plugin.

Then … Continue reading

Posted in JavaScript, Productivity, Technology, Web development | Tagged , , , , , , , , , , | 4 Comments

Starting to move the web forward

Last week, I took some time to watch a very nice video from Paul Irish in youtube about javascript development workflow. I recommend it, even if you think your workflow is already great, maybe you learn one new cool thing.

There are plenty of things to learn from the video. I specially liked the website that helps you to get involved in the Web. I mean there are plenty of information about how to help to shape the future of the internet and give back to the amazing community that has been built around this platform. Move the Web Forward with concrete steps and measures. It only goes forward and in a good direction, if we all make part of it together. I think that is the idea behind the website.

I’m on it. Maybe it increases the frequency of posts in this blog. ūüôā

Posted in JavaScript, Technologien, Web | Tagged , , , , , | Leave a comment

Webcam directive for AngularJS apps

Imagine being able to show the data of the webcam of an user by using this simple HTML tag:

<webcam></webcam>

Well, now you can!
Take a look at some demos and download it and see for yourself.

Continue reading

Posted in AngularJS, Directives, JavaScript, Technologien | Tagged , , , , , , , , | 10 Comments

Java EE 6 – CDI: Using InjectionPoint to resolve ambiguous dependencies at run-time

This is an advanced usage of the CDI specification of Java EE 6 that assumes the reader is already familiar with the Dependency Injection patterns provided by it.

The problem:

We have a service which is dependent of certain type of object to perform its actions. If we only have one implementation of the dependency, then we can use the regular injection methods to get a reference of it.

In our case, we need to find out which of the implementations the client of our service wants to be used. We would like this configuration to be made as easy as possible for the client, so we need to assure our dependency can be easily changed with minor modifications to the code.

  • First, we need to create an annotation to be able to allow the client to specify the type of the dependency that he would like to use. The following snippet of code shows an example of it:
    @Retention(RUNTIME)
    @Target({ TYPE, METHOD, FIELD, PARAMETER })
    public @interface DependentAnnotation {
        public Class<? extends DependencyType> type();
    }
  • Our dependency is specified by an interface which the implementations should extend:
    public interface DependencyType{
        public void performSomeAction(Object arg);
    }
  • These are sample implementations of our dependency interface:
    1. public class DependencyTypeImplOne implements DependencyType{
      
          @Inject
          public DependencyType() {
              // Constructs the object
              ...
          }
      
          public void performSomeAction(Object arg) {
              // Perform some action with arg
              ...
              System.out.println("One received argument: " + arg.toString());
          }
      }
    2. public class DependencyTypeImplTwo implements DependencyType{
      
          @Inject
          public DependencyType() {
              // Constructs the object
              ...
          }
      
          public void performSomeAction(Object arg) {
              // Perform some action with arg
              ...
              System.out.println("Two received argument: " + arg.toString());
          }
      }
  • And the following code shows how an implementation of the service would find out which of the implementations to use.
    public class Dependent {
    
        private DependencyType dependency;    
    
        @Inject
        public Dependent(@Any Instance‚ÄĻDependencyType‚Äļ depInstance,
                        InjectionPoint ip) {
            // Get the class passed in at injection point
            Annotated annotated = ip.getAnnotated();
            DependentAnnotation annotation = 
                 annotated.getAnnotation(DependentAnnotation.class);
            if (annotation == null) {
                 throw new RuntimeException("Needs to be annotated");
            }
            Class<? extends DependencyType> dependencyClass = 
                     annotation.type();
            /* 
            * Find the actual implementation at run-time
            * using the class passed in at injection point
            */
            dependency = depInstance.select(dependencyClass).get();
        }    
    
        public void someAction() {
            dependency.performSomeAction("pass some argument to it");
        }
     }
  • The next three options show how the service could be injected, so that it would be able to find the correct implementation of its dependency. That’s also how the client indicates which implementation he expects to be used as dependency for the service.
    1. Using field injection:
      @Inject 
      @DependentAnnotation(type = DependencyTypeImplOne.class)
      private Dependent dependentService;
    2. Using constructor injection:
      @Inject 
      public SomeClass(
         @DependentAnnotation(type = DependencyTypeImplOne.class)
         DependentService dependentService) {
          ...
      }
    3. Using setter injection:
      @Inject 
      public setDependentService(
          @DependentAnnotation(type = DependencyTypeImplOne.class) 
          DependentService dependentService) {
          ...
      }

    We can see from above that the only thing the client needs to do now to change the implementation used, would be to change the type given to the annotation. To use the second implementation he could for example write this:

    @DependentAnnotation(type = DependencyTypeImplTwo.class)
  • After obtaining a reference to it through injection, the only thing left for the client is to use it somewhere:
    public void someMethod() { 
        dependentService.someAction(); 
    }

The code snippets above were not tested and thus probably contain errors, but I hope they serve their purpose of illuminating the intended solution.

If you have any suggestions on how to solve the same problem in a better way, feel free to express yourself.

Find me on Google+

Posted in CDI, Java, Java EE 6, Technologien | Tagged , , , , , , , , | 2 Comments