Alexis Mas

Mastering your IDE

Sun, 11 Jun 2017 00:00:00 +0000

Most of us, as developers we spend plenty of time improving our programming skills: design patterns, meta-programming, good practices, new languages or frameworks, you name it. Furthermore, even deployment and infrastructure can be managed through code. Hence, we could say that most part of our days revolves around code, as a matter of fact when we aren’t writing code we are reading it.

Why not put the same effort to master our editor of choice? In the end is the most used tool in software development. Let’s take a look at the different areas we should cover to know our IDE as the palm of our hand. On each section, you will find a short description and a small list of what features of your IDE you should rely on.

DISCLAIMER: I’ll use IDE and editor interchangeably, deal with it! ;)

There’s nothing more irritating than not knowing how to navigate through your code efficiently. Ok, I might be overreacting but it’s annoying to go char by char when you want to go from point A to B.

Move between words
Go to method
Go to definition
Tagging

The last one is especially useful when working on large file that constantly requires you to jump up and down.

Writing

When it comes to coding, I start with an initial draft of what the solution could look like, from there I start iterating over the code looking for a better approach. This usually implies duplicating, deleting and rearranging lines. Knowing how to do it without copy-pasting will make writing code a little bit smoother.

Code auto-formatting
Delete current line
Duplicate line
Move line up/down

Refactoring

Refactoring a complex piece of code without relying on the IDE features could end up being a frustrating experience. Why do the hard work by hand instead of delegating the effort to our editor?

Extract variable
Extract method
Rename variable
Rename class
Find usages of variable/method/class

Layout

When working on a big screen (I currently using a 27-inch monitor) I tend to split my editor in two, three or even four sections. That allows me to work with several files at the same time so I can glimpse over their content with ease.

Split view vertically
Split view horizontally

Path to Mastery

via GIPHY

Find your own way to learn your IDE features, and above all their shortcuts. Since knowing how to trigger all of those actions with a keystroke will make you spend less time figuring out how to do things instead actually doing them. Furthermore, don’t try to memorize all of them at once, it can be overwhelming go for a baby steps approach instead. Printing a cheatsheet and hang it next to your screen or writing down the shortcuts you want to learn on a post-it might come in handy.

Happy coding!

Unit Testing with RxJava

Wed, 20 May 2015 00:00:00 +0000

When we are testing our RxJava code we can distinguish three main subjects to be tested:

Observables
Subscribers
Notifications

Observables

Testing an Observable is pretty simple: create the observable, subscribe and assert! In order to execute all operations on the test thread we have to define subscriber’s and observable’s scheduler as Schedulers.immediate(). If we use other scheduler we’ll end up with flaky tests.

Subscribers

When it comes to Subscribers we can differentiate two scenarios:

Named subscriber
Anonymous subscriber

Despite both implementations carry out the same function, the way of testing each one is totally different. A named subscriber can be constructed directly on our test by doing new MySubscriber(). As that subscriber extends Subscriber<T> we can access its public methods: onCompleted, onError and onNext; because of that just instantiate a new subscriber, call each method and do the assertion/verification for each case.

In contrast to named subscribers we’re unable to create the same anonymous subscriber on our test case. Therefore to test it properly we have to go through the full chain of notifications, this will require working with different threads. We will go into further details on the next section.

Notifications

This is the most complex part about testing with RxJava, as usually this could involve three threads:

observer: where the observable is running
subscriber: where observable results are pushed
current: where the test is running

Synchronizing all those threads solely for unit testing could be painful. We can override default schedulers instead handling thread’s synchronization. To accomplish this we have to implement RxJavaSchedulersHook then tell RxJavaPlugins to use that hook for schedulers.

The first step is to override RxJavaSchedulersHook, overriding schedulers hooks allow us to return a custom scheduler for io, computation and new thread requests. To execute both observer and subscriber on the current thread we need to return Schedulers.immediate() for all Schdulers request.

    private class SchedulerHook extends RxJavaSchedulersHook{
        @Override
        public Scheduler getIOScheduler() {
            return Schedulers.immediate();
        }

        @Override
        public Scheduler getNewThreadScheduler() {
            return Schedulers.immediate();
        }

        @Override
        public Scheduler getComputationScheduler() {
            return Schedulers.immediate();
        }
    }

Besides scheduler hook we can also use RxJavaObservableExecutionHook, this hook can be really helpful to obtain information about the execution order in our test. In my cases I implemented to know the actual order of execution and the execution thread. This is the log from one of my tests:

[main] DEBUG RxJavaResetRule - onCreate
[main] DEBUG RxJavaResetRule - onCreate
[main] DEBUG RxJavaResetRule - onSubscribeStart
[main] DEBUG RxJavaResetRule - onSubscribeStart
[main] DEBUG RxJavaResetRule - onSubscribeReturn
[main] DEBUG RxJavaResetRule - onSubscribeReturn

Are we ready to start testing? Uh… NO

The first problem comes when we have more than one test method on out test case, setup and teardown will be executed several times (one for each test) hence setting schedulers hook on each execution. The error we will get is an IllegalStateException saying “Another strategy was already registered”. So let’s take a look at RxJavaPlugins until we find registerSchedulersHook method.

public void registerSchedulersHook(RxJavaSchedulersHook impl) {
    if (!schedulersHook.compareAndSet(null, impl)) {
        throw new IllegalStateException("Another strategy was already registered: " + schedulersHook.get());
    }
}

That’s the origin of the error we’re seeing but if we keep looking we will find a package protected reset method that reset the current implementations of available hooks.

/* package accessible for unit tests */
void reset() {
    INSTANCE.errorHandler.set(null);
    INSTANCE.observableExecutionHook.set(null);
    INSTANCE.schedulersHook.set(null);
}

In order to access reset method we have to define a class under the same package as RxJavaPlugins. For reusability sake I ended up using a JUnit rule to reset the plugins and define the hooks.

package rx.plugins;

public class RxJavaResetRule implements TestRule {

    private static final Logger LOG = LoggerFactory.getLogger(RxJavaResetRule.class);

    @Override
    public Statement apply(Statement base, Description description) {
        return new Statement() {
            @Override
            public void evaluate() throws Throwable {
                //before: plugins reset, execution and schedulers hook defined
                RxJavaPlugins.getInstance().reset();
                RxJavaPlugins.getInstance().registerSchedulersHook(new SchedulerHook());
                RxJavaPlugins.getInstance().registerObservableExecutionHook(new ExecutionHook());

                base.evaluate();

                //after: clean up
                RxJavaPlugins.getInstance().reset();
            }
        };
    }

	//Hooks implementations

And we’re finally there, we just have to add the rule to ALL our test that implies RxJava because onces the schedulers factory is initilized we cannot change its schedulers instances despite how many times we change the hook.

There is an issue on GitHub about making reset method public.

Deploying an Android project to Sonatype Nexus

Fri, 17 Oct 2014 23:20:00 +0000

When we try to deploy an Android to Sonatype Nexus using Gradle Sonatype Nexus plugin, we will encounter (at least in my case) two errors.

The first one is because nexus plugin can’t find install task on the project.

A problem occurred configuring project ':app'.
> Failed to notify project evaluation listener.
   > Task with name 'install' not found in project ':app'.
   > Could not find property 'poms' on project ':app'.

And the second one seems to be that plugin can’t find where source are located.

A problem occurred configuring project ':library'.
> Failed to notify project evaluation listener.
    > Could not find property 'main' on SourceSet container.
    > Task with name 'install' not found in project ':library'.
    > Could not find property 'poms' on project ':library'.

The easiest solution I have found by now, is using Sonatype Nexus plugin in combination with Gradle Android Maven plugin.

First we need to add both plugins to the buildscript closure

buildscript {
    repositories {
        mavenCentral()
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:0.13.2'
        classpath 'org.gradle.api.plugins:gradle-nexus-plugin:0.7.1'
        classpath 'com.github.dcendents:android-maven-plugin:1.1'
    }
}

Now we’re ready to go, just apply both plugins and define sources location.

    apply plugin: 'android-maven'
    apply plugin: 'nexus'

    sourceSets {
        main {
            java.srcDirs = ['src/main/java']
        }
    }

Finally pom’s data needs to be defined, you can find a sample on Gradle Sonatype Nexus page. For more details on how to configure each plugin, please go the their respective pages.

Contact form backed by Parse

Sat, 30 Nov 2013 00:00:00 +0000

This is the first post of my brand new blog!

What a better opportunity to write about something related to the setup of this site. On the contact page there is a contact form, as you should know when a form is submitted its send to a server where its data is processed. But lets be honest, I’m lazy, the DRY-KISS type (it could be worse). So I didn’t want to setup a server, hire a hosting only to handle a stupid contact form then Parse came to the rescue.

For those who doesn’t know it, Parse is BaaS platform who was recently acquired by Facebook; it offer a cloud backend for our software and I say software because it doesn’t care if it’s Android, iOS, JavaScript whatever. I have been testing it in a personal Android project and its really easy to use, leaving database/server administration to Parse itself.

That enough, lets go to the point.

The form

The form has nothing special, for completion sake, here is it:

	<form id="contactForm" role="form">
		<label for="name">Name</label>
		<input type="text" class="form-control" id="name">

		<label for="email">Email</label>
		<input type="email" class="form-control" id="email">

		<label for="website">Website</label>
		<input type="url" class="form-control" id="website">

		<label for="message">Message</label>
		<textarea rows="3" class="form-control" id="message"></textarea>

		<input type="hidden" name="save" value="contact">
			<button type="submit">
				Send Message
			</button>
	</form>

The backend

First of all you will need to signup in Parse and create an application. Once the app is created copy the APP ID and CLIENT KEY you will need it later.

The backend have two main functionalities: first save the message received from client then send an email with that message. For saving the message nothing needs to be done on the server, mailing will be done by Mailgun. If you don’t have an account go to Mailgun and create one.

	var Mailgun = require('mailgun');
	Mailgun.initialize('myDomainName', 'myAPIKey');

	Parse.Cloud.beforeSave("Message", function(request, response){
		var msg = request.object;

		var body =
		"Name: " + msg.get("name") + "\n" +
		"Website: " + msg.get("website")+ "\n --- \n" +
		msg.get("message");

		Mailgun.sendEmail({
		  to: "hello@alexismas.com",
		  from: msg.get("email"),
		  subject: "Message from alexismas.com",
		  text: body
		}, {
		  success: function(httpResponse) {
			console.log(httpResponse);
			response.success();
		  },
		  error: function(httpResponse) {
			console.error(httpResponse);
			response.error("Uh oh, something went wrong");
		  }
		});
	});

The glue

The form needs to communicate somehow with the backend, nothing that a small script couldn’t solve.

As I said before Parse is quite simple, in this case we need to create a Parse Object called Message. First we define the class name so we instantiate it. Once the object is created, we can fill it up with the data obtained from the form, and finally save it.

	var Message = Parse.Object.extend("Message");

	function saveMessage(){
		var msg = new Message();

		msg.set("name", $("#name").val());
		msg.set("email", $("#email").val());
		msg.set("website", $("#website").val());
		msg.set("message", $("#message").val());

		var callback = {
			success: function(){
				alert("Thanks!");
			},
			error: function(){
				alert(":S");
			}
		};

		msg.save(null, callback);
	}

The only missing part is how to execute this function when the form is submitted, that can be done in four lines.

	$("#contactForm").on("submit", function(e) {
		e.preventDefault();
		saveMessage();
	});

That’s it.