Posted on

Getting more productive in the command line

I mentioned previously that I changed my Android Studio terminal to Bash.

Since doing that, I’ve been working on making my console more productive as well.

I’ve done 3 main things:

  • Set up a gem to allow me to create pull requests from my terminal
  • Set up some aliases for Bash
  • Set up a ton of aliases for Git

Create pull requests from the terminal:

We use an Atlassian tool chain and part of our process is that everything gets peer reviewed and merged to our main branches through pull requests.

This meant that I had to leave the terminal to create a PR after I pushed code. This will not do! So it made sense to install a tool to do that from the terminal. Atlassian has a good blog post on doing that here: http://blogs.atlassian.com/2012/11/stash-pull-requests-from-the-command-line/

This was before Atlassian added default reviewers, and having to add my 6 team members every time I had to create a PR was a big part of the reason I went down this rabbit hole. So there was one more thing missing: How do I add the reviewers?

The answer ended up being a function in my Bash config:

This allows me to create a pull request to origin/develop with myself as a reviewer by simply typing: pr develop

Bash setup:

Other than the pr() function in my bash config, I also alias ‘git’ to ‘g’. It might seem a bit silly, but I type git a lot, and I hate typing… It looks like this:

So, the alias bit is obvious. The rest is there so that you can still auto-complete branch names and git commands on ‘tab’.

I keep my config in a gist at: https://gist.github.com/riaancornelius/90cb54157bb4ec8d5b6c18dbe9f418f2

Git aliases:

I keep a copy of my git config here: https://gist.github.com/riaancornelius/fb541aaeef24c851b20682db1b578a3f

This has been built up from contributions by co-workers, podcast hosts and various random things I found on the internet.

Bonus: Install Cmder

When I’m not in the IDE, my terminal of choice is Cmder

Posted on

Android Studio – Don’t clear logs after app crash

In Android Studio, the default setting for the Logcat window seems to be “Show only selected Application” (top right corner of the Logcat window)… which is looking at the log of the selected process (your current launch by default). So when your app crashes during testing, that process is gone, so the filter clears the log.

Instead, select “Edit Filter Configuration…” and set up a filter for your app, eg:

  • FilterName: MyApp
  • PackageName: com.example.myapp (<< replace with your app’s package name)

…and then select that filter for future runs. This should keep the log there for you, even after the app crashes.

Posted on

Android Studio – Set up a custom terminal

In my endless quest to make it unnecessary to leave the IDE, I figured it would make sense to use Git bash as my terminal in Android Studio rather than the default cmd.exe on Windows.

Turns out this is really simple.

1. Open your settings in Android Studio (CTRL-ALT-S) and type ‘terminal’ to find the correct settings.

2. Change the Shell path to Git bash. In my case it was ‘C:\Program Files (x86)\Git\bin\sh.exe –login -i‘. I just  copied this from the start menu shortcut’s properties.

Android Studio Terminal Setup

3. Restart your IDE.

4. Profit. You can bring up the terminal window with ALT-F12, so no need to use the mouse.

Android Studio TerminalOptionally, you can change the console colors in Editor > Colors & Fonts > Console Colors. Just remember to restart your IDE if you change them. If you are on the Darcula theme this is not necessary – everything just works.

 

Posted on

Visualising your code as a city

I was looking at visualising some code recently and came across CodeCity. It’s somewhat useful and quite interesting, but getting it to work is not as simple as it once was…

This is because CodeCity uses the Famix 2.1 model to visualise your code, and very few of the tools referenced on the CodeCity website and most other blog posts are still available.

I did however find this useful blog post that highlights one tool still available: Analyzing a Java Codebase with CodeCity in 2016

Essentially, you need to download CodeCity and iPlasma.

iPlasma ScreenshotThen you use iPlasma’s Swing interface to import your codebase and then generate a Famix model of your code (This takes a while). After all this you end up with a rather strange looking screen from where you can run the “Moose MSE exporter” tool.

This finally gives you a Famix 2.1 model which you can import into CodeCity and (after some more waiting) generate a city visualising your code.

I found that this works fairly well, however some of my classes seems to be missing from the visualisation (Some big god objects), and I haven’t been able to figure out why yet.

Still, it’s an interesting way to look at your code. It also let’s you generate visualisations of multiple versions of your code and show you how the “city” evolved.

Posted on

My style guides

After starting to work on an Android project that has a lot of inconsistent styles all over the codebase, I decided to finally document what I consider to be the right style for Java and Android.

You can see them on my Github repo:

I’ve also exported my Android studio ‘Code styles’ and ‘Inspections’ to this repo. This is an attempt to get Android Studio to format our code according to these style guides.

By using the same ‘Code style’ settings across the team, we can get Android Studio to enforce the consistency for us.

You should be able to just run the Install.sh script to copy them to your user folders (or just copy the contents of the config manually if you prefer that).