Zopfli

Despite previous advice - do not use zopfli for alternative compression

Images

If the images were manually optimized - turn off the cruncher. You can do zopli compression on the images unlike on the apps Use WebP (but support is only available since Android 4.0)

// Gradle Plugin 2.0+
android{
    defaultconfig {
        vectorDrawables.useSupportLibrary = true
    }
}

Use Proguard

Use proguard. It is tough and things break but it is worth it.

This configuration though will not use full blown ProGuard but use a built in simplified shrinker.

minifyEnabled true
useProguard false   

use @Keep annotation in code to generate ProGuard rules automatically during the build process

Open sourced tool ClassyShark

If you have not run a gc yet and it has been less than 2 weeks (default gc setting) since the commits you lost were created you are in luck.

STEP 1 - fsck

run git fsck --lost-found to identify the dangling commits

You will get something like this:

Checking objects: 100% (7151/7151), done.
dangling commit fa8249bd69c8cdf796e84a35dbb41d7d0c8e8930
dangling commit ce46084419bb1dfdb150c3af289efc1aafc5c066
dangling commit 934bf7ca1a24cea55cbef66d330b522ea023733
dangling commit 9e0e15c2842838f1e0ad408ddc3ebe106454f962
dangling commit 36d1659104054279036e25c2d18406bddfdb848e
dangling commit dfe36b11aeb25b1164167563f9d81211914df4f1
dangling commit 1665174227ec2bda0a1edb5353427a4fdee239ba

Great! You have the commits but which one is which? git show to the rescue

STEP 2 - show

find the commit you need with git show COMMIT_HASH e.g. git show fa8249bd

Once you find the commit you would like to get back to - last step is to merge it to your current branch

STEP 3 - merge

merge, e.g. git merge fa8249bd

Any system with enough moving parts
and no entity to coordinate
is doomed to be in a state of chaos

–– Inteist

List the running VMs
vboxmanage list runningvms

Power Off specific VM with the name VM_NAME (the name can be obtained via the list command)
vboxmanage controlvm VM_NAME poweroff

Any good idea is only as good as its implementation

–– Inteist

I have stumbled across Tarantool database which seems to be a very fast storage for hot data. If you are looking for a very fast and efficient tool, check it out.

Tarantool is claiming to be about 30% faster than Redis.

Tarantool allows to write server side stored procedures with Lua, allowing to create in DB rest APIs.

Tarantool is not good for big (static/cold) data.

Since it is not always easy to separte cold data from hot data. They are working on an smart automatic solution that will analyze the patterns of data access and decide automatically which parts of data are cold and should be phased out to disk and which parts are hot and should be treated as such.

In April I have wrote how to solve a problem of poor highlighting for the search results for the Atom editor. Since then in the ever evolving editor after one of the updates something broke and the highlight feature became broken. Took me a while to get to it but I have finally had some time to take a look at it and I came up with the following replacement:

//
//  Search highlight
//
atom-text-editor::shadow .highlight.find-result .region {
  background: rgba(255,255,255,.2);
  border-color: rgba(250, 248, 51, .6);
}

//
// the active search highlight - to distinguish from the other results
//
atom-text-editor::shadow .highlight.current-result .region,
atom-text-editor::shadow .highlight.current-result ~ .highlight.selection .region {
  background: rgba(255,255,255,.05);
  outline: dashed;

}

A neat method to test for a set containment in another set both of which are Collections

private boolean isSubsetOf(Collection<String> subset, Collection<String> superset) {
    for (String string : subset) {
        if (!superset.contains(string)) {
            return false;
        }
    }
    return true;
}

The problem

The history list in Safari is not timestamped. Yes, it is chronologically ordered but for some misterious reason is not timestamped. That sucks but fortunately there is a simple solution for that.

The history is actually saved as files on your machine.

So ….

Solution

is pretty simple:

cd ~/Library/Caches/Metadata/Safari/History && ls -lt | perl -MURI::Escape -lne 'print uri_unescape($_)' | less

or you can define a nice csh alias using function

function safari-history() {
    cd ~/Library/Caches/Metadata/Safari/History
    ls -lt | perl -MURI::Escape -lne 'print uri_unescape($_)' | less
}

The problem

If you have recently upgraded to El Capitan and now your fonts in Android Studio are non anti aliased (they look thin and broken) you’ve come to the right place for a solution.

The source of the problem is in the different font rendering used in different SDK versions. The Java 6 (JDK 1.6) which is used by Android Studio by default has the subpixel antialiasing rendetin while the JDK 1.7 and JDK 1.8 do not.

I have upgraded from Mavericks to El Capitan and suddenly my JDK 1.6 was gone and not surprisingly Android Studio’s font rendering was horrible.

To confirm you don’t have JAVA 6, go to /Library/Java/JavaVirtualMachines and run ls

cd /Library/Java/JavaVirtualMachines && ls -l

you will most likely see jdk1.7.0_60.jdk jdk1.8.0_31.jdk as an output. (that’s what I saw)

The fix

You should download JAVA 6 from this Apple’s support article. It’s about 70Mb install file. Make sure to close any Java apps and run the installer. You should have the 1.6.0.jdk folder inside your JavaVirtualMachines folder I was talking about above.

Once this is set, you can launch Android Studio and enjoy the anti aliased fonts again.

Good luck!

Useful links:

• Configurion Android Studio
• Mac OS X JDK Selection for Android Studio