No Relation To Blog
Subscribe to the personal musing of Emmanuel Bernard
Autocompletion is crap
I can't believe autocompletion is still so stupid in 2013. Alright, I said it, I feel better. It's actually not quite true and a lot of smart things are going on in Eclipse or IntelliJ IDEA but completion remains incredibly stupid when it comes to discovering an API and offering the most appropriate choice.
It is very important for fluent APIs tailored to offer only the APIs that make
sense in a particular context. So when the autocompletion offers you the full
monty of useless methods of Object, it kills the hours of work an API designer
put into his fluent API and its discoverability. Seriously notify(),
notifyAll() and wait() x 3!
I developed, help develop or gave advice on a number of fluent APIs in Java including:
- Hibernate Search and Hibernate Validator programmatic mapping API,
- an upcoming Hibernate OGM programmatic configuration API
- ShrinkWrap API
- Hibernate Search Query DSL API
So I feel very personally offended when something gets between my work and the end user.
Eclipse
I use Eclipse these days and the sort by relevance works only in so far as relevance is synonymous to alphabetical. In other words it sucks... but in a predictably alphabetical way.
IntelliJ IDEA
IntelliJ IDEA is smarter as it puts in bold the methods hosted on the type and leave supertype methods in regular.
If you dig enough though, you can find a setting
Sort lookup items lexicographically
by opening up preferences and search of autocompletion. Weirdly enough, if you uncheck this box, IntelliJ IDEA does the better thing and put the elements in bold next to each others.
And that concludes this half rant, half tip, half call to action to IDE developers. Yes I know but it takes at least 3 halfs for a good cocktail :)
Une tasse de thé podcast
Eric Lefevre-Ardand vient de lancer un nouveau podcast sur la programmation et en Français: Une tasse de thé Podcast.
Comme son nom l'indique, le podcast est une interview sur un sujet précis autour d'une tasse de thé. J'aime bien ce format qui limite les interview à 15 minutes et donc garde la discussion centrée.
Au lieu de prendre votre thé ou café et de parler de The Voice ou de la 87ème rediffusion de Top Gun avec vos collègues, prenez votre balladeur et écoutez un épisode. Pour l'instant il fait ses épisodes tous les 15 jours.
Bonne chance à Eric. Garde le rythme :)
Making the best of Google Authenticator for One Time Passwords
You can't reorder tokens on Google Authenticator nor edit the associated description? Read on.
I use one time passwords everywhere I can. It's a little hassle but increases security by a whole lot. And the good thing is that more and more providers offer this:
- GMail
- Google Apps
- Dropbox
- Amazon Web Services
- Your company if they are not too dinosaur-y
Go use one time passwords aka two factor authentication, you will thank me later.
I looked around on iOS and the most well known soft token application that supports both time based and event based tokens is Google Authenticator. Except that Google Authenticator's UI is really crap and buggy.
The edit button does not seem to function properly and nothing happens most of the time. The trick is to go to Legal information then back. You can now press the edit button and voilà! Things work. You can now:
- reorder the list properly
- edit the name under each token
That made my life much easier.
Multiple email aliases in iOS
I have tons of email identities. Depending on which hat I am wearing, I use one alias or another. Most are behind my GMail address. It is easy enough to create and use multiple aliases in the GMail web client or even in Mac OS X's Mail app. But until recently I thought it was impossible with iOS Mail app.
It turns out it is possible but requires a bit of cheating. First off, instead of setting up your GMail account as GMail, set it up as IMAP. I already do that as I never give my GMail address (in case I change provider). Once setup, go in Note or any other editor and type the list of comma separated email aliases (including your primary address) and copy this line. For example:
scooby@doo.fr, scooby.doo@worldwildlife.org, scooby.doo@gmail.com
Then go to Setting -> Mail, Contacts, Calendars and select the email account you are interested in. In the Email field, remove the address and paste the list of comma separated email addresses. This whole gymnastic is necessary because iOS does not let you add commas in an email field.
Now you are good to go, when you create an email, you can change the email address with any of the aliases. Note that the last email in the list will be the default email (experienced on iOS 6.1.3).
I found the tip on iMore, they describe a more step-by-step explanation with some screen shot if you get lost.
Google Drive - the good and the ugly
Google Drive is a bit confusing at first but the Dropbox like feature works reasonably well. They have a desktop client that works pretty much like the Dropbox client and syncs your local directory with the cloud.
This is quite handy when your friends have maxed out their Dropbox quota: Google Drive gives you 5 GB free. Images you store on Google Plus and files you store on Google Drive count against your quota. The Google Drive documents do not though.
Not everything is rosy in the Google Drive land though.
Trash or no trash
Data in your trash is counted as used space. It took me a while to figure that out and I could not get why my free space was lower that it should have. I don't think other services do that.
Bugs
When you delete a non empty directory and then try to remove it from the trash, well nothing happens. Someone has forgotten to write the recursive part of the algorithm :) You have to go in each subdirectory and remove files and empty directories.
Simplistic client and speed
It seems to me that Dropbox syncs faster than Google Drive but I have not properly benched them so that might be subjective.
What is for sure is that the sync up cues on Google Drive are too simplistic. It tells you synchronization happens and that's it. Dropbox tells you how many files are uploaded and downloaded, what is the speed rate for each as well as the estimated time it will take. It's not gimmicky, it shows progress to the user.
Overall, I tend to stick with Dropbox despite the fact that it is twice as expensive per GB.
Thou shalt be binary compatible
I learned some new tricks today thanks to Gunnar around backward compatibilities in Java.
There is compatibility and compatibility
In Bean Validation, we need to fix a mistake I made. One easy solution is to create a sub-interface and return that sub-interface.
//API
public interface Contract {
public Result testMe();
public Result testMeMore();
public static interface Result {
void doIt();
}
}
//client code
Contract contract = new ContractImpl();
contract.testMeMore().doIt();
In our example, I need to add a new method to results coming from testMeMore().
I thought of this approach:
//API
public interface Contract {
public Result testMe();
public ResultMore testMeMore();
public static interface Result {
void doIt();
}
public static interface ResultMore extends Result {
void doItAgain();
}
}
//client code
Contract contract = new ContractImpl();
contract.testMeMore().doIt();
This approach is source compatible: if I recompile the client code, things will work perfectly. But it's not backward compatible at the binary level.
If you don't recompile the client code and simply update the API jar, you will get a nasty exception
Exception in thread "main" java.lang.NoSuchMethodError: com.jboss.test.Contract.testMeMore()Lcom/jboss/test/Contract$Result;
That's because the contract is now com.jboss.test.Contract.testMeMore()Lcom/jboss/test/Contract$ResultMore
and even if Result is a super interface, Java does not let go with it.
And since application deployed in Java EE 6 are supposed to work out of the box for Java EE 7, we can't do that. Note that testing binary compatibilities is not trivial.
Use the erasure hack, Luke
The what? It turns out the Java designers already had this problem when they introduced the generics type system. You can solve the problem by using intersection types.
//API
public interface Contract {
public Result testMe();
public <T extends Result & ResultMore> T testMeMore();
public static interface Result {
void doIt();
}
public static interface ResultMore extends Result {
void doItAgain();
}
}
//client code
Contract contract = new ContractImpl();
contract.testMeMore().doIt();
Because generic types are erased by their most left upper bounds which is
Result in our case, things work out smoothly.
By the way, you can reproduce this ad nauseam.
//API
public interface Contract {
public Result testMe();
public <T extends Result & ResultMore & ResultUltimate> T testMeMore();
public static interface Result {
void doIt();
}
public static interface ResultMore extends Result {
void doItAgain();
}
public static interface ResultUltimate extends Result {
void doItForEver();
}
}
//client code
Contract contract = new ContractImpl();
contract.testMeMore().doItAgain();
Conclusion
Now the big question is, should we use this trick in Bean Validation to solve this problem. What's your take on it?
No more Java Preferences for you!
Java on Max OS X is a moving target to say the least since stewardship has moved from Apple to Oracle. I had a lot of trouble to make Eclipse run on my machine making me feel like a customer of The Soup Nazi in Seinfeld.
Let me explain some changes.
The failure
I tried to run Eclipse Juno on my machine and got the following encouraging error
The JVM shared library /Library/Java/JavaVirtualMachines/openjdk-1.7-x86_64 does not contain the JNI_CreateJavaVM symbol
Eclipse always uses the system default JVM on Mac OS X and as far as I know you can't change that. In theory that's not a big deal, you just have to change the default JVM to use via the Java Preferences application.
No more Java Preferences application
Apple recently removed the Java Preferences application from Mac OS X as they deemed it to be useless. In a sort of twisted way - aka we don't care about developers - they were right.
It has been replaced in the Java Oracle distribution by a panel in System Preferences under the Other category. Well except that this panel only deals with Oracle JVMs. So if you happen to have OpenJDK or any other JVM installed, you can not choose (or "unchoose") them.
The side effect for me was that OpenJDK was selected as the default JVM and this created this user friendly error when starting Eclipse.
Hats off to Henri Gomez for helping me find a
way out. You basically need to
go to /Library/Java/JavaVirtualMachines and remove OpenJDK
sudo rm -fR openjdk-1.7-x86_64
In my case I actually moved it somewhere else. What if I want to use OpenJDK too? F**k you! told me Orapple.
The combination of:
- Apple stopping bundling the JVM
- Oracle coming up with an Oracle only replacement
- Apple removing a useful tool
makes the open JDK community at large feel quite unwelcome. So much for an open source project and community where both Apple and Oracle are major stakeholders.
By the way that's not the only glitch I've experienced when moving from the
Apple VM to Oracle VM. JAVA_HOME now points to the JDK instead of the JRE.
Anyways, moving along.
Installing po2xml and xml2pot on Mac OS X
Hibernate documentation system uses po2xml and xml2pot to build translations. Unfortunately, Homebrew does not have a formula for it and I don't think I have the knowledge to work on such thing.
The solution is to install Macport. There is a nice UI installer. Make sure to chose the one specific to your Max OS X version.
MacPort does change your .bash_profile. Because I want to give
Homebrew's executable priority, I make sure to put Macport
changes after homebrew in the PATH variables.
Update Macport
sudo port -v selfupdate
Then install po2xml. Unfortunately, po2xml does not come as standalone package, you have to install all of KDE
sudo port install kdesdk4
Then wait for freaking ever for everything to compile. By the way, source packaging is not eco-friendly. Think about the amount of CPU needed every time you update some package...
Once that is done, add po2xml and xml2pot to your path
PATH=$PATH:/Applications/MacPorts/KDE4/po2xml.app/Contents/MacOS
PATH=$PATH:/Applications/MacPorts/KDE4/xml2pot.app/Contents/MacOS
And you are good to go!
Unable to update git from homebrew
I have had problems on one machine to upgrade Git from Homebrew. Let me first tell you how to fix the problem and then what homebrew is about.
The problem
The problem appeared when I tried to upgrade git
brew upgrade git
It turned out to be much more complicated than I anticipated to find the problem. The exact error message was:
Error: Failed executing: make prefix=/usr/local/Cellar/git/1.7.11.3 CC=/usr/bin/clang CFLAGS=-Os\ -w\ -pipe\ -march=native\ -Qunused-arguments\ -mmacosx-version-min=10.7 LDFLAGS=-L/usr/local/lib install (git.rb:49)
These existing issues may help you:
https://github.com/mxcl/homebrew/issues/8643
https://github.com/mxcl/homebrew/issues/10544
https://github.com/mxcl/homebrew/issues/11481
https://github.com/mxcl/homebrew/issues/12344
https://github.com/mxcl/homebrew/issues/12814
https://github.com/mxcl/homebrew/issues/13850
Otherwise, this may help you fix or report the issue:
https://github.com/mxcl/homebrew/wiki/bug-fixing-checklist
My environment was listed as:
==> Build Environment
HOMEBREW_VERSION: 0.9.2
HEAD: 53d5bfb44e8644eff1693b2a734f079d10b53043
CPU: dual-core 64-bit penryn
OS X: 10.7.4-x86_64
Xcode: 4.3.3
CLT: 4.3.0.0.1.1249367152
X11: 2.6.4 @ /usr/X11
CC: /usr/bin/clang
CXX: /usr/bin/clang++ => /usr/bin/clang
LD: /usr/bin/clang
CFLAGS: -Os -w -pipe -march=native -Qunused-arguments -mmacosx-version-min=10.7
CXXFLAGS: -Os -w -pipe -march=native -Qunused-arguments -mmacosx-version-min=10.7
CPPFLAGS: -isystem /usr/local/include
LDFLAGS: -L/usr/local/lib
MACOSX_DEPLOYMENT_TARGET: 10.7
MAKEFLAGS: -j2
And the last line before the error outputs were
/usr/bin/clang -isystem /usr/local/include -Os -w -pipe -march=native -Qunused-arguments -mmacosx-version-min=10.7 -I. -DUSE_ST_TIMESPEC -DNO_GETTEXT -DHAVE_DEV_TTY -DXDL_FAST_HASH -DSHA1_HEADER='<openssl/sha.h>' -DNO_MEMMEM -DSHELL_PATH='"/bin/sh"' -o git-daemon -L/usr/local/lib daemon.o libgit.a xdiff/lib.a -lz -liconv -lcrypto -lssl
Undefined symbols for architecture x86_64:
"_iconv_open", referenced from:
Undefined symbols for architecture x86_64:
"_iconv_open", referenced from:
_reencode_string in libgit.a(utf8.o)
_reencode_string in libgit.a(utf8.o)
"_iconv", referenced from:
"_iconv", referenced from:
_reencode_string in libgit.a(utf8.o)
_reencode_string in libgit.a(utf8.o)
"_iconv_close", referenced from:
"_iconv_close", referenced from:
_reencode_string in libgit.a(utf8.o)
_reencode_string in libgit.a(utf8.o)
ld: symbol(s) not found for architecture x86_64
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [git-daemon] Error 1
make: *** Waiting for unfinished jobs....
make: *** [git-credential-store] Error 1
It turned out that libiconv was the culprit. Simply uninstall it:
brew remove libiconv
brew prune
brew cleanup
Then run brew upgrade git again and things should work now.
I found the inspiration here.
What is homebrew anyways
Homebrew is a very easy to use and maintain package manager for Mac OS X environments. Anytime you want to install one of those unix-y tools, Homebrew is your friend.
Passed the initial installation, Homebrew is as simple to use as
brew install *something*
and you are good to go. Keeping versions up-to-date are very easy too
# update brew itself
brew update
# update tools installed with brew
brew upgrade
For example here are a few things I have installed and maintain with Homebrew (aka brew for the friends).
- git
- keychain
- mvim
- mongodb
- postgresql
- rsync
- unison
- wget
That also includes some Java tools:
- gradle
- maven
- jboss-as
- ceylon
Homebrew does not install as a privileged user - it is actually discouraged. That makes it a bit picky when permissions are not right.
I have been using this trick quite regularly with success.
ruby -e "$(curl -fsSL https://gist.github.com/raw/768518/fix_homebrew.rb)"
Enjoy
I succumbed to the Cult of vi
I think I am seriously regressing as I grow older.
I mentioned in the past moving from the popular, dynamic and UI based blog system Wordpress to the Ruby based static generator Awestruct. I also mentioned moving to Git and enjoying my command line more and more. On a tangential note, I do enjoy writing my verb in a pure textual form thanks to Markdown and use Git as my backup and memory system if you will.
I think the natural evolution for me was to move to one of those archaic editors like vi or emacs... And I tried vi... and I can't say I liked it at first.
Why oh why move to vi?
Emacs never attracted me, I have only ten fingers after all and
there is only so much flexibility in my hands.
vi has the immense benefit of literally be available everywhere
you ssh in. I have always been acquainted with vi: use i to type
and ESC :q! if things go crazy.
Long time vimers keep claiming that once you get it, it's awesome. Since I have been proved wrong on Git - I thought Mercurial was better at that Git UX was an abomination for bearded people - I was rather curious.
A recent discussion with my friends of Les Cast Codeurs fame convinced me to try once again to jump on the bandwagon.
So far not so bad
In the beginning I felt that I was slow and that every line of text was draining a third of my energy for the day. And that was more than a feeling.
But it's really growing on me and this blog post is an attempt to understand why really. Yes reader, you're my private therapist.
I love good UIs but to be honest, for text documents, you don't really need it. I use MacVim with a decent set of coloring and syntax highlighting and I am happy with it. The key is that vi is extremely powerful to fine-edit text and that even if hard to learn, you feel that there is something you can gain.
What's bad about vi
For beginners or casual users, vi the most horrible piece of user experience ever built. There is no visual or otherwise cue in case you don't know how to do something, no way to navigate menus to figure what can be done. You even need to be an accomplished vi user and sort of already know what you do to begin to make sense of the help system.
But let's pretend you used Google and know enough to play around. Let's face it auto completion is very important in Java. Most of the time Java developers don't need doc, the API and auto completion are here to guide them. I often resort to Google for an API in Ruby or JavaScript, never in Java.
Now what's interesting is that IntelliJ IDEA (my Java editor) has a vi plugin, so does Eclipse. So you can use your vi way of editing but still benefit from auto completion and code navigation.
The vi plugin for IntelliJ is not perfect. It sometimes stops working and you need to close and reopen your file, and it has the tendency to override some common shortcuts (Command click for code navigation for example). But for the most part it works. I think in 2 weeks of use, I gave up the vi mode twice. Not bad!
The other thing that's bad with vi is that there is no native project
view to navigate from one file to another in a project. I'm used to
Command-N in IntelliJ IDEA to open a Java class with a few camel case
friendly keystrokes.
Vi has plugins to mimic that - vi has plugins for everything by the way including ASCII diagram drawing tools. I have installed NERDTree and Command-T so far but I don't feel it's sufficient. The visual reminder of the file hierarchy is quite useful in an IDE.
Likewise, copy / pasting especially between non vi apps is not entirely fluid to me but I suspect it's a matter of training.
What made me click
There is no magic trick, you need to train your brain and your fingers to vi. But there are two things that were key to make me understand how to use vi:
- stay in insert mode (sort of the normal mode of any other editor) for the shortest period of time. Text manipulation is mostly done in command mode. So always come back to command mode.
- vi is very regular, operations are made of an action and a move. The action describes what you want to do, and the move is about what the action will influence. On top of that, you can add a multiplier to repeat the operation several times.
So when you learn a new move or a new action, you can compound them to the ones you know already and create new operations for free.
After a while you like the game. Plus it's very easy to Google a given action and find how to do it efficiently.
The arrow vs hjkl for navigation was essentially a non problem. I use what
I am comfortable with: I started with arrows but I use almost exclusively
hjkl to move now as it makes my hand move less on the keyboard.
Likewise, I use the mouse when I feel like moving around a lot. That might
change down the road.
It has been roughly two weeks of coding and writing in vi mode and I am now feeling that when I move back to a classic editor, I don't feel as efficient as I thought I was. I'm even tempted to say that I feel a bit more efficient now in vi.
A lot of the efficiency comes from the powerful search tools. It turns out to be very efficient to navigate around text or code using small searches.
Resources and conclusion
- a stackoverflow question on the philosophy of vi commands
- the thought process of someone moving back to vi
- everything you need to know on tabulation and indenting in vi
- graphical cheat sheet
If you want to make the jump, I recommend you:
- print the cheat sheets and keep them in front of you
- read a few blogs on the philosophy of vi
- take the time to configure your (graphical) vi(m) environment
- jump and stick to it for most of your work
- use a vi plugin for your IDE: it is good to force you to use vi without losing auto completion and co you need
That's all I have, it's not a tutorial on vi, more my thoughts on the process. I'll keep you posted if I have more interesting things to say on the subject. Oh and of course this blog entry has been written in vi :)
