The cat is out of the bag: yesterday, during Google I/O‘s keynote, we announced our new IntelliJ IDEA-based Android IDE, Android Studio. This is what my team has been working on for the past months.

From what I read on the web, Android Studio has been pretty well received. I personally heard nice comments about it, from “awesome!” to “fantastic!” and “really cool.”

Here are some highlights about Android Studio. I’ll be writing more detailed blogs about our IDE soon. Before I continue, let me make this clear:

This is a personal blog. The opinions expressed here represent my own and not those of my employer, Google.

With that out of the way, here we go:

Our goal is to be Gradle-centric

We are working closely with the Gradleware folks on a new Gradle-based build system. Right now, with Android Studio, you can create new Gradle-based Android projects or import existing ones. When you build your project in Android Studio, we disable the default IDEA Java builders and delegate the build to Gradle. You get the same output from building within Android Studio or from the command line. Our goal is to have Gradle build files as the only source of truth.

This is an early access preview

Even though it is possible to create applications with Android Studio, there are still rough corners, bugs and features that we have not implemented yet. It would be great to get as many bug reports and feature requests from early adopters. Here is the list of known issues.

We still support Eclipse

We will be supporting Eclipse ADT as well. In fact, we plan to add similar Gradle support to ADT. The catch here is that given limitations in Eclipse, especially JDT, we cannot guarantee a development experience as smooth as Android Studio. You can, however, export your Eclipse-based Android project as a Gradle project, and then import it into Android Studio.

This is not a fork of IntelliJ IDEA

We have been working, and continue to work, really close with JetBrains, the folks behind the best Java IDE, IDEA. They implemented the changes we needed in their platform in order to develop Android Studio. Eventually, you will be able drop Android Studio as a plug-in into your copy of IDEA.

That’s it for now. Stay tuned for more Android Studio posts :)

Update: Xav‘s and Tor‘s Google I/O talk “What’s New in Android Developer Tools” is on YouTube!

I’m most excited to announce my new adventure! Today is my first day as part of the Android project at Google. In particular, I’ll be working on tooling for Android.

For the past 2 years I worked in the Eclipse tooling team (also at Google.) I had the privilege to work with an amazing group of people. Thank you, guys, for the best years of my career!

In response to my post, “My team at Google is hiring,” I got a lot more résumés than I expected. This is absolutely great! Many thanks to all the folks interested in working in my team!

While chatting with a few of the potential candidates, I offered some advice on interviewing with Google. This is advice that was passed to me when I interviewed a couple of years ago. Even though these tips are nothing out of ordinary, they are, however, practical and useful. Since I found myself repeating them over an over, I thought it may be a good idea to write them down.

Here we go.

1. Listen to your best friend: the (Google) recruiter

Is the recruiter’s job to get you an offer from Google. He or she will do everything in their control to help you. As part of their job, they will tell you what you need to study for the interview. It is a lot of material, but it is absolutely worth the effort. Needless to say, Google is awesome.

2. You decide when to interview

It is your decision when to interview. Take all the time you need to prepare and don’t let anybody push you. Knowing when you are ready is difficult though. Studying all the material is pretty much impossible. Instead, you need to set a realistic goal. In my case, since I was terrified by the interview process, my goal was to cover the basic algorithms and data structures, and study until I feel calm and confident.

3. Practice, practice, practice…and get a whiteboard

It does not matter if your solution is wonderful, you are in trouble if the interviewer cannot understand it. While preparing for the interview, solve problems on a whiteboard. Learn how to express your ideas and write code (yes, write code on a whiteboard) in a clear, neat and organized way. You want interviewers to understand your solutions.

4. Let all your friends at Google know that you are interviewing

The more Googlers that can say something good about you, the better. You may be able to skip the phone interview (it is not a promise though.) I personally hate technical phone interviews.

5. $hit can happen

Preparing for the interview does not guarantee you will pass it. There are many factors that can work either in your favor or against you. Plus, there is no such a thing as a perfect interview process. $hit out of your control can happen. Don’t feel too bad if, for whatever reason, you fail the interview. It happens more often than you think. Seriously. Just learn from the experience and apply again in six months. Like I mentioned earlier, working for Google is worth the effort.

That’s pretty much it. Good luck! :)

A couple of weeks ago, one of our users reported that Eclipse consistently froze when executing some action. I was hoping that Eclipse would have an editor where I can open the thread dump I got and navigate, through hyperlinks, from stack traces to source code. The closest thing I found was the “Java Stack Trace Console,” which provides hyperlinking to source code. It would have been nice if there is a specialized editor that provides the following features, besides code navigation:

• an Outline View that shows the threads by name (with icons representing their state) and any deadlocks found
• some basic syntax highlighting to make reading easier
• ability to collapse blocks (e.g. a thread or stack trace) to minimize noise
• navigation to thread definitions from references (e.g. a deadlock)

BTW, IntelliJ IDEA provides something somehow close to what I’m asking for since 2008! 2008!

In addition, I didn’t want a tool that analises a thread dump for me (e.g. TDA or the IBM one.) So far, I haven’t seen a thread dump that is that hard to read.

Of course I had to scratch my own itch! This past weekend I finally had time to write my own “Thread Dump Viewer.” It is an editor that provides everything I described. I was able to write a working editor in a matter of hours, using Xtext. The key was getting the grammar right. I spent an additional couple of hours making it “prettier.”

Here is a screenshot of the editor (click to enlarge.)

Here is a demo showing off the features of the “Thread Dump Viewer.”

I created this tool for my own use. I haven’t open-sourced the code or made the plug-in publicly available simply because I don’t know if anybody else would find this tool useful. If you do, please leave a comment.

(10/07/12) Update: I’m in the process of open sourcing this plug-in. I need to do some cleanup (code formatting, add copyright headers, etc.) first. I expect the first version of the plug-in to be what I have now. Right after that, I’ll be implementing the features mentioned in the comments:

• detection of multiple threads locking on the same object
• compare multiple thread dumps with each other

Many thanks to everyone that left a comment! :)

One of the goals of FEST-Assert 2.0 is to learn from the mistakes we made in the 1.x releases, even if that means not being backwards-compatible.

Not fully understanding the semantics of the API we were building, is, IMHO, one of the biggest mistakes we made in FEST 1.x. We were not able to see that each assertion in the method chain should be an independent unit.

To better explain my point of view, consider this snippet using FEST-Reflect‘s API:

Person person = constructor().withParameterTypes(String.class)
                             .in(Person.class)
                             .newInstance("Yoda");

In this example, each chained method in the fluent interface serve a common purpose: instantiate a new Person (similar to the builder pattern.)

On the other hand, in FEST-Assert, each method in the fluent interface has its own, individual purpose. For example:

assertThat(yoda).isInstanceOf(Jedi.class)
                .isEqualTo(foundJedi)
                .isNotEqualTo(foundSith);

The purpose of isInstanceOf is different than the one from isNotEqualTo. We can even call them individually:

assertThat(yoda).isInstanceOf(Jedi.class);
assertThat(yoda).isEqualTo(foundJedi);
assertThat(yoda).isNotEqualTo(foundSith);

In FEST 1.x I broke this assumption by introducing overridingErrorMessage as a way to override FEST’s default error message in case an assertion fails. Let’s take a look at this example:

assertThat(yoda).overridingErrorMessage("Yoda is a Jedi, dammit!")
                .isInstanceOf(Jedi.class)
                .isEqualTo(foundJedi)
                .isNotEqualTo(foundSith);

This is when it gets confusing. Now a method in the chain affects the behavior of the next one. It is hard to tell if overridingErrorMessage only applies to isInstanceOf, or to all the methods in the chain. It is so confusing that I cannot remember what were the semantics of overridingErrorMessage!

This is a potential fix:

assertThat(yoda).isInstanceOf(Jedi.class, overridingErrorMessage("Yoda is a Jedi, dammit!"))
                .isEqualTo(foundJedi)
                .isNotEqualTo(foundSith);

Now it is easier to understand that overridingErrorMessage only affects isInstanceOf.

Looking back, I can see that I introduced overridingErrorMessage the way I did because I naively thought that method chaining makes it easier to write and read code. It surely makes it easier to write code (just press “.” and your IDE’s content assist will show you all the available methods) but I showed you that chaining methods does not always produce a readable API.

In short: I abused method chaining.

Conclusion

When creating a fluent interface using method chaining, step back and think what are you trying to achieve. Do the methods in the chain share a common purpose? Are you chaining a bunch or independent methods? Regardless of the style you choose, be consistent and try not to mix them. That will make the code written with your API readable.

Oh BTW, we made the same mistake (again) in FEST-Assert 2.x. Luckily, there is still time to fix it :)

This is a follow up for a tweet I sent this morning. I’m sharing some more details to save everybody’s time.

In short: my team at Google is hiring. If you enjoy writing Eclipse plug-ins, send me your résumé at: alruiz at google.com.

Important details:

• No prior experience with Eclipse is needed. We are looking for strong Java developers that have passion for building tools.
• This job is in Mountain View, at Google’s headquarters. No telecommuting. Candidates should be willing to relocate if necessary.
• You need to go through the regular Google interview process.

Take a look at this post if you’d like to know a little bit more about what we do and our culture.

I’m pretty happy to announce that FEST has been named a finalist in the 4th Annual ATI Automation Honors.

The winner will be announced at the TestKIT 2012 Conference.

If you are happy FEST user, please vote for us! :)

Update: FEST’s home page was down, most likely due to the recent problems GoDaddy is going through. If you have problems accessing it, you can visit our Google Code page :)

This is a short rant. Please do not use Iterable as a return type. Its Javadoc states that

Implementing this interface allows an object to be the target of the “foreach” statement.

That’s the only purpose of this interface.

Other than that, this interface is almost useless, or at least a PITA to consume. For example, to obtain the size of an Iterable you’d need to do this:

Iterable<String> names = getRecentUsers();
int size = 0;
for (String name : names) {
  size++;
}

Or, just to check that an Iterable is not empty:

Iterable<String> names = getRecentUsers();
boolean empty = !names.iterator().hasNext();

Horrible, isn’t it?

Return a Collection instead. If your users may need to access to the elements by index, return a List.

(I actually think that Iterable should not even used for parameters, but I’m not 100% sure yet.)

Update: After reading the comments in this post, I realized I didn’t cover one use case: collections that contain a big number of elements and are lazily loaded. I also did not specify the context I was talking about: domain-specific APIs that you are in control of.

I still think that Iterable is a poor choice. Since we are in control of the API we can provide something more useful (or potentially more useful) to the consumers of such API. In the case of lazily-loaded collections, provide something like a Page object. It may or may not implement Iterable. A Page class may contain other useful information besides simple iteration of elements (e.g. the page number.)

Changing the subject a little bit, this is something that I’ve seen quite frequently, all in the name of “flexibility”:

Iterable<String> getRecentUsers() {
  List<String> users = fetchFromDb();
  return Collections.unmodifiableList(users);
}

Since we are already dealing with List, why not just return the same type?

Update 2: If you are thinking about Guava‘s usage of Iterable. please read the comments, which includes one from the man himself, Kevin Bourrillion.

Update 3: This is my position about general-purpose libraries like Guava:

Guava’s goal is to make Java easier to use. It provides a lot of useful functionality that IMHO should be in the JDK itself. As such, it needs to deal with very general classes such as Iterable. Plus, it provides utilities to overcome some of Iterable‘s deficiencies (like lack of a isEmpty method.)

My post is about domain-specific APIs that you provide to your users, not something like Guava. ]]> http://alexruiz.developerblogs.com/?feed=rss2&p=2519 26 http://alexruiz.developerblogs.com/?p=2468 http://alexruiz.developerblogs.com/?p=2468#comments Wed, 22 Aug 2012 22:57:21 +0000 Alex Ruiz http://alexruiz.developerblogs.com/?p=2468

Today, IBM developerWorks published the article I recently wrote, “Integrate an external code checker into Eclipse CDT.”

When writing for developerWorks, we have the option to write in three formats: Word, Write or XML. Since I find it pretty painful to use Word or Write, I usually choose the XML format. developerWorks provides a pretty detailed tutorial on how to write an article in XML. In addition, developerWorks provides an “author package” that includes a little command-line program to convert the article in XML format to an HTML page, something handy when you want to see how your article will look like when published.

While writing my last article, I noticed that I was wasting too much time switching between my XML editor (Eclipse), the conversion tool and the browser (I like to review the article as I write it, and the HTML format is a lot easier to read than XML.)

I wanted to write and preview everything using a single tool. Unfortunately, there is no WYSIWYG editor for developerWorks’ XML format. The best I could do is to have everything, the editor, the command-line tool and browser in one place: Eclipse.

Eclipse already comes with a built-in browser. Luckily for me, I released a terminal plug-in for Eclipse last month!

Here is a screenshot of my setup (click to enlarge.)

On the left side I have the XML editor. Once I’m done writing, I switch to the terminal and run the conversion tool (after the first time I just press “UP” and “ENTER.”) Once conversion is done, I just refresh the browser (on the top-right) to preview the article.

This simple setup saved me a lot of time (I’m using a 30-inch monitor, BTW.) If you write or plan to write articles for developerWorks you may want to give it a try :)

You can find more information about the terminal plug-in at the project’s home page.

Update: Alexander Pupeikis made a good point on my G+ post: why bother with all this for writing text?

What I forgot to mention is that being in an IDE is pretty handy if you include code snippets or a code attachment in your article. In my case, for code snippets, I write code in a Java editor to ensure I’m not writing stuff that doesn’t work. Then I copy/paste code between editors.

I’m pretty happy to announce the first release of our terminal plug-in for Eclipse!

This plug-in provides a fully-working, command-line terminal to Eclipse 3.7 or later (yes, even 4.2!) It works on Linux and MacOS only.

Why a terminal?

At Google we have several interactive command-line tools that we need to invoke from Eclipse. It resulted in poor user experience. The terminal opened in its own window. After issuing several commands, managing all those windows was messy. This terminal also does not allow us to copy/paste URLs.

This first release is mostly for users to give the terminal a try. For our next release, we expect to fix all major bugs and have the ability to issue commands from Eclipse.

Standing on the shoulder of giants

The terminal plug-in is based on two great Eclipse projects: Eclipse CDT and Eclipse Target Management. We forked the minimum necessary pieces to make the plug-in work. From Target Management we got the terminal emulator, and from CDT we got the pseudo-terminal (PTY) support.

Improvements

Once we had a minimal terminal working, we added some features to improve the user experience.

1. Quickly open a terminal from almost anywhere in Eclipse

A new terminal view can be opened in three different ways:

1. Right-click any file or folder, and select the “Open Terminal Here” context menu (idea borrowed from the Windows XP Power Toy “Command Prompt Here”)
2. On a terminal view, click the “New Terminal” button in the toolbar
3. If there are no terminal views open, go to the menu “Window” > “Show View” > “Other” and find “Terminal” under the “General” category

2. Colors and font configuration

You can change the terminal’s background and foreground colors as well as the font. Go to the menu “Window” menu (or “Eclipse” menu in Mac OS) and navigate to the “Terminal” > “Colors and Font” preference page.

3. Hyperlinking

The terminal plug-in recognizes and provides hyperlinks for URLs using the HTTP(S) protocol. We’ll provide an extension point for custom hyperlink detectors.

4. Keyboard shortcuts

Shortcuts for copy/pasting text was one of the most requested features. On Linux you can use Ctrl+Shift+C and Ctrl+Shift+V while on MacOS you can use Command+C and Command+V, respectively.

5. Change terminal’s title

By default, the title of a terminal view is the last segment of the path of its working directory. You can change the title by pressing a button in the toolbar.

Project location

The terminal plug-in is hosted at Google Code, under the name ELT (Eclipse Local Terminal.)

Feedback is always welcome :)