Search This Blog

12 November 2015

Tag Heuer - Day 1

Ordering the watch was a little tricky. Every time I went to checkout, it would remove the watch from my cart. It was just minutes after the release, so I assumed the website was having a hard time. Since there were no local shops that were going to carry it, I decided to try one more thing. I created an account first and voila the order went through with no problems. That was Monday.
Tuesday, they inform me it will be delivered by the following morning. It arrived before 10am Wednesday morning.

The packaging was really well done. Not only secure, but even the packing slip was inside a thank you note. There was no instruction manual or anything - but I mean, really, those get out of date as fast as you OTA... And I had two of those right away.

The magnetic charging base is nice, though it is awkward to use since it can't sit flat while charging.

I've had the email address for years so I rather quickly disabled wear notifications from gmail. 

The first time my phone rang, I found myself glance at my watch first. That actually surprised me. I tried answering a call with the watch, but that was pretty pointless since it was still using the speaker and microphone from the phone a few feet away.

It's rather comfortable. I like that Google Fit can be more accurate than before ( didn't always carry my phone while waking around the house, using elliptical, etc ). 

After charging through the night, today was the real test. After about 15 hours it is reporting 8% battery left. That's a far cry from 25 hours. It's a good thing I didn't leave gmail notifications enabled or I might have had to charge it after 5.  I'd say the battery is the only downside so far.

08 November 2015

LG v10 Day 1

I've been using the LG v10 for about a day so far, an upgrade from my HTC One m7 GPe.

Overall, it's a nice device. A bit big, but I should be able to get used to that since I used to have the first gen Galaxy Note.

The UI is a little different... In the app drawer, there is a Google subfolder. You can add additional apps to it, but can't sort them. Actually doesn't look like you can remove them either. Haven't found any way to add additional folders yet.  I was able to hide all the AT&T bloatware, so that's something.

Second screen? Eh still haven't decided if it is gimmick or useful. I didn't buy it for that feature anyway.

I was going to replace the launcher with the Google Now launcher, but I like that it is a doubly linked list so I'll keep it for now.

I do like that there it's a dedicated button for screenshots - the HTC was notorious for making me try try again. I also like that I can change the soft buttons ( order and content ).

I do not like the buttons on the back. I'm sure I'll get used to them, but whoever thought it was a good idea to encourage people to accidentally put their finger on the camera lens repeatedly was obviously not a photo buff.

I haven't run any cpu or ui benchmarks yet, but it seems rather quick. Speedtest wasn't looking great. Time will tell.

And in case you are wondering why I went with this phone, it was mostly because I wanted to try out the manual camera mode. I don't expect it to beat out my Canon, but it seemed i interesting. Also, removable battery and sd are hard to come by these days.

28 October 2015

USB3 hub disconnecting - dropping adb connection


I'm probably jumping the gun, but I am hopeful.

I was having a problem where my new OctoFire hub was disconnecting quite often -- especially if using something like Android ScreenMonitor.

I think it is fixed.  I found the suggestion to disable the autosuspend here.

Edit the /etc/default/grub file and append to the GRUB_CMDLINE_LINUX_DEFAULT line:
usbcore.autosuspend=-1
Then run:
sudo update-grub
sudo reboot

16 September 2014

Threading

I was just thinking today....

  • synchronized: The single line open at the DMV
  • thread pool: Cashiers at the grocery store
  • reentrant read/write locks: The tiny booths at Saturday Market
  • volatile: The "in-use" sign on airplane restrooms
  • concurrent collections: Open-air Farmers Market
  • FIFO: freeway on-ramp
  • LIFO: UHaul Boxes


anyone else want to contribute some?

20 August 2014

nVidia + video tearing in my IDE

I have been having some problems for the last few months where the menu items in my IDEs (plural) were tearing.  Sometimes they wouldn't popup, sometimes more than one would be highlighted, etc.

I found this article from 2 years ago which I couldn't really follow to the letter.  My nv only had one of the specified settings. I don't have ccsm installed, etc.

The ONLY change I made was:

  1. sudo su - root
  2. echo CLUTTER_PAINT=disable-clipped-redraws:disable-culling >> /etc/environment
  3. reboot

So far it seems to be working fine.

16 August 2014

Writing a custom Gradle plugin: Java + buildSrc/

I spent some time looking around at various suggestions (including on the Gradle documentation page) about how to write a custom plugin.  For my specific purpose, it was not intended to be a shared plugin - but rather one to abstract out some of the logic we are doing in our build.  I did another post on writing a Groovy plugin, here's the Java one.

To show that we are really doing a minimalist design here, let's start with a completely empty directory.

~> mkdir mytest
~> cd mytest

1. Gradle Wrapper


I personally use the Gradle Wrapper. Since the last post, I upgraded to Gradle 2.0, but the Gradle Wrapper it installs by default is not currently compatible with the Android plugin.  As such, we'll still manually define one.

Create a build.gradle file:

task wrapper(type: Wrapper) {
    gradleVersion = '1.12'
}

Run it.

~/mytest> gradle wrapper

Now that we have the wrapper installed in a fresh directory, let's look to that plugin. We'll be adding 3 Java classes and 1 properties file.

Here's what we are aiming for:

.
├── build.gradle
├── buildSrc
│   └── src
│       └── main
│           ├── java
│           │   └── org
│           │       └── eoti
│           │           └── gradle
│           │               ├── BrewinPluginExtension.java
│           │               ├── BrewinPlugin.java
│           │               └── BrewTask.java
│           └── resources
│               └── META-INF
│                   └── gradle-plugins
│                       └── brewin.properties
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradlew
└── gradlew.bat


2. POJO Extension


Let's start this time by defining our POJO.  We'll create buildSrc/src/main/java/org/eoti/gradle/BrewinPluginExtension.java.

We'll add our package:

package org.eoti.gradle;

And import the Gradle API:

import org.gradle.api.*;

And create our POJO with getters/setters. 

Our complete POJO:

package org.eoti.gradle;

import org.gradle.api.*;

public class BrewinPluginExtension
{
    private String message = "Wake up!";
   
    public String getMessage(){return message;}
    public void setMessage(String message){this.message = message;}
}

3. Task


Next, we'll define our task.  Create buildSrc/src/main/java/org/eoti/gradle/BrewTask.java.

We'll add our package and imports:

package org.eoti.gradle;

import org.gradle.api.*;
import org.gradle.api.tasks.*;


Our class will extend DefaultTask.

public class BrewTask extends DefaultTask{...}

Next we'll define our task and annotate it:

@TaskAction
public void brew() {...}

In the implementation, we want to find our configuration.  If there isn't one, we'll create a default one.  Then, we'll output our message.  The complete code:

package org.eoti.gradle;

import org.gradle.api.*;
import org.gradle.api.tasks.*;

public class BrewTask extends DefaultTask
{
    @TaskAction
    public void brew() {
        BrewinPluginExtension extension = getProject().getExtensions().findByType(BrewinPluginExtension.class);
        if(extension == null)
            extension = new BrewinPluginExtension();
       
        System.out.format("%s\n", extension.getMessage());
    }
}

Note the getMessage() that we defined in our POJO.

4. Plugin


Next, we'll define our plugin.  Create buildSrc/src/main/java/org/eoti/gradle/BrewinPlugin.java.

Add your package and the Gradle import.  In my case, that is:

package org.eoti.gradle;

import org.gradle.api.*;

Our class implements Plugin<Project> which means we have:

@Override
public void apply(Project project){ ... }

We will specify two things in this function.

First, an extension to allow parameters to be passed in:

project.getExtensions().create("brewin", BrewinPluginExtension.class);

The name "brewin" is the name of the configuration block.

Second, a task to be added once this plugin is applied:

project.getTasks().create("brew", BrewTask.class);

That 'brew' is the @TaskAction name from above.

The complete plugin:

package org.eoti.gradle;

import org.gradle.api.*;

public class BrewinPlugin implements Plugin
{
    @Override
    public void apply(Project project)
    {
        project.getExtensions().create("brewin", BrewinPluginExtension.class);
        project.getTasks().create("brew", BrewTask.class);
    }
}


5. Properties


Now, we need to add the properties file using the same configuration name we chose above.  In this case, buildSrc/src/main/resources/META-INF/gradle-plugins/brewin.properties.

It contains one line that points to our plugin implementation:

implementation-class=org.eoti.gradle.BrewinPlugin

Ok, we're almost done.

6. Apply it


In your top-level build.gradle, specify that we want to apply our new plugin by adding this to the top:

apply plugin: org.eoti.gradle.BrewinPlugin

And then from the command line, call the task we defined earlier:

~/mytest> ./gradlew brew


That's great!  But, why did we create a configuration parameter if we aren't going to use it?

Add this to your top-level build.gradle:

brewin{
    message = "Make another pot!"
}

And then re-run it:

~/mytest> ./gradlew brew

There you go.  You can add additional parameters, additional Java logic, etc.

Writing a custom Gradle plugin: Groovy + buildSrc/

I spent some time looking around at various suggestions (including on the Gradle documentation page) about how to write a custom plugin.  For my specific purpose, it was not intended to be a shared plugin - but rather one to abstract out some of the logic we are doing in our build.  I'll probably actually do another post on writing a Java plugin, but for now let's try the Groovy one.

To show that we are really doing a minimalist design here, let's start with a completely empty directory.

~> mkdir mytest
~> cd mytest

I personally use the Gradle Wrapper. Gradle 1.6 is installed on the system, but once the Gradle Wrapper takes over it's ignored.

Create a build.gradle file:

task wrapper(type: Wrapper) {
    gradleVersion = '1.12'
}

Run it.

~/mytest> gradle wrapper

Now that we have the wrapper installed in a fresh directory, let's look to that plugin.  We'll be adding 1 groovy file and 1 properties file.

Here's what we are aiming for:

.
├── build.gradle
├── buildSrc
│   └── src
│       └── main
│           ├── groovy
│           │   └── GroovinPlugin.groovy
│           └── resources
│               └── META-INF
│                   └── gradle-plugins
│                       └── groovin.properties
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradlew
└── gradlew.bat

In buildSrc/src/main/groovy/ create your new plugin file. In my case, it was called GroovinPlugin.groovy.

We'll still put a Java-style package at the top, even though the source file was not contained in a Java-style package directory. IE: I used package org.eoti.gradle even though the directory was not org/eoti/gradle.

We need to import the Gradle API.

import org.gradle.api.*
import org.gradle.api.plugins.*

Our class (same name as the file) implements Plugin<Project> which means we have:

void apply(Project project) { ... }

In my case I specified two things in this function.

First, an extension to allow parameters to be passed in:

project.extensions.create("groovin", GroovinPluginExtension)

We'll discuss that GroovinPluginExtension in a moment.  The name "groovin" is the name of the configuration block.

Secondly, I specified a task to be added once this plugin is applied:

project.task('groove') << {
    println project.groovin.message
}

That 'groovin' is the configuration name from above. 'message' is the parameter name defined inside GroovinPluginExtension.  The GroovinPluginExtension is just another class defined in the same file (not an inner class though) providing a POGO. A POGO is basically a POJO that automatically creates the getters and setters for you.

In this case, we define a String called 'message', as such:

class GroovinPluginExtension {
    def String message = 'We be groovin\''
}

Put all together, the GroovinPlugin.groovy looks like:

package org.eoti.gradle;

import org.gradle.api.*
import org.gradle.api.plugins.*

class GroovinPlugin implements Plugin<Project> {
    void apply(Project project) {
        project.extensions.create("groovin", GroovinPluginExtension)
        project.task('groove') << {
            println project.groovin.message
        }
    }
}

class GroovinPluginExtension {
    def String message = 'We be groovin\''
}

Pretty small, right?

Now, we need to add the properties file using the same configuration name we chose above.  In this case, buildSrc/src/main/resources/META-INF/gradle-plugins/groovin.properties.

It contains one line that points to our plugin implementation:

implementation-class=org.eoti.gradle.GroovinPlugin

Ok, we're almost done.

In your top-level build.gradle, specify that we want to apply our new plugin by adding this to the top:

apply plugin: org.eoti.gradle.GroovinPlugin

And then from the command line, call the task we defined earlier:

~/mytest> ./gradlew groove

That's great!  But, why did we create a configuration parameter if we aren't going to use it?

Add this to your top-level build.gradle:

groovin{
    message = "We be jammin'"
}

And then re-run it:

~/mytest> ./gradlew groove

There you go.  You can add additional parameters, additional Groovy logic, etc.