One simple, cost-effective way is with Belkin WeMo insight switches ($59 from Amazon). Each switch exposes a series of UPnP services via WiFi that can turn the switch on and off, measure power usage, and query usage history. This means that with our simple wrapper library you can do things like simulate a power failure during a sensitive operation, examine the impact of periodic failures on a workload and measure power draw during demanding workloads.

First you need to configure the switches. Unfortunately, this part can be frustrating and time consuming. The step-by-step instructions Belkin’s iPhone app provides are accurate but they fail to mention that the WiFi network broadcast by the switch is extremely weak and difficult to connect to. Expect to need multiple attempts to configure each switch. Once you succeed in configuring the switch however, no more fiddling or resets will be needed. Also, definitely be aware of the security impact. The access control features of Belkin’s WeMo switches are minimal at best. Disable all remote access and configure your firewall to prevent the Belkin switches from sending or receiving traffic outside your network.

Before hopping into code you’ll want to give your switches useful names using the iPhone or Android app. For example, you might have “Test Server 1″ and “Test Server 2″. This will make code that uses the switches easier to understand.

Now things get easier. Add the wrapper library to your maven pom.xml:

<repository>
  <id>maven-snapshots<id>
  <name>Maven Snapshots<name>
  <url>https://oss.sonatype.org/content/repositories/snapshots/</url>
  <snapshots><enabled>true</enabled></snapshots>
</repository>
...
<dependency>
  <groupId>com.palominolabs.wemo</groupId>
  <artifactId>wemo</artifactId>
  <version>1.0-SNAPSHOT</version>
</dependency>

From there you can search for switches and give them commands. For example, if you had a switch named “Floodlight” this code would start a disco rave:

        String switchFriendlyName = "Floodlight";
        try (InsightSwitchFinder insightSwitchFinder = new InsightSwitchFinder(switchFriendlyName)) {
            if (!insightSwitchFinder.findSwitches()) {
                throw new IllegalStateException("Unable to find switches");
            }

            InsightSwitch insightSwitch = insightSwitchFinder.getSwitch(switchFriendlyName);

            while (true) {
                insightSwitch.switchOn();
                Thread.sleep(100);
                insightSwitch.switchOff();
                Thread.sleep(100);
            }
        }

Once you’ve got Java controlling your switches you can do a number of interesting things beyond simulating hard power failures. You could implement Netflix-style chaos monkey behavior for your lab. Or you could measure power usage during benchmarks to calculate metrics like performance-per-watt.

The post Controlling Belkin WeMo Switches from Java appeared first on Palomino Labs Blog.



Palomino Labs unlocks the potential of software to change people and industries. Our team of experienced software developers, designers, and product strategists can help turn any idea into reality. Check out our website for more information, or send us an email and let's start talking about how we can work together.

Introduction

Using power effeciently is essential to making a successful app. Not only is it rude to drain your users’ batteries but if their phones run out of battery quickly they physically can’t use your app. Sadly, the built-in Instruments energy diagnostics are fairly limited. You can see which major power draws (GPS, screen, cell radio, etc) are currently on but there’s no way to see how much current the device is currently drawing. This is the crucial piece of information because ultimately you want to be able to answer two basic questions:

1. How long will the battery last when running my app?
2. How much is the battery life extended when I perform a particular optimization?

Powergremlin leverages private APIs to measure the battery’s current capacity over time and determine current draw. Using this information you can easily answer these questions.

Tutorial

First you’ll need to clone the repo from Github. The README has instructions for building; essentially open in XCode and run.

Now, let’s imagine you’re working on off-brand Foursquare. Your users complain that even an hour of use decimates their batteries. Intuitively you know that doing things like reducing CPU usage, turning off location services as much as possible, minimizing network traffic and so on should help but it’s risky to start making optimizations without profiling. So let’s profile! Here’s what you do:

1. Make sure that location services aren’t active. If you have a solid arrow in the status bar then something is using location services and you should turn it off so that it won’t skew results. A hollow arrow indicates geofencing. Remove any reminders that depend on a location to make it go away.
2. Now restart your phone to minimize the number of background processes. Background processes can cause CPU activity and network activity that would skew your results.
3. Start Powergremlin and tap “Reset”.
4. Use your app for at least 15mins, preferably more like 30mins.
5. Go back to Powergremlin. The cruical figure in this case is “Current Draw (mA)”. It indicates the average current draw since you tapped “Reset”. You divide the battery capacity in milliamp-hours by the average draw in milliamps to get a rough sense of how long your battery will last while running your app.

Now that you have a baseline you can try implementing different optimizations and check their improvements. For example, if your baseline is a draw of 300 mA and after switching to a less chatty API the draw goes down to 270 mA then you just bought an iPhone4 user an extra 30 minutes.

As you embark on your power profiling adventures there are several things to keep in mind:

1. Never test while on external power. Powergremlin doesn’t take into account the current supplied by the charger so the numbers are incorrect. Also, even if Powergremlin handled this case gracefully you’d never want to do this because the phone uses much more power when charging.
2. Batteries degrade over time. A brand new iPhone 4 has a capacity 1420 mAh. My year old iPhone, however, has a capacity of 1350 mAh. In practice most of your users’ phones will have batteries with less capacity than what the specs claim.
3. Power usage is extremely variable. Always make several measurements of at least 15 minutes each.
4. Test usage in the real world as much as possible. The power characteristics of an iPhone on WiFi in an area with good cell coverage are radically different from those of a phone in an an area with only spotty EDGE.

The post Introducing Powergremlin appeared first on Palomino Labs Blog.



Palomino Labs unlocks the potential of software to change people and industries. Our team of experienced software developers, designers, and product strategists can help turn any idea into reality. Check out our website for more information, or send us an email and let's start talking about how we can work together.

The only annoyance is that it’s not immediately clear from the documentation how to enable the WebKit Inspector. Fortunately, this is relatively straightforward.

1. Start by creating a new HTML5 Application in Qt Creator.
   

2. Give it a cool name.
   

3. Tell Qt Creator to generate an index.html to be displayed by the app.
   
4. Default build options are fine.
   
5. Click “Done” to make it happen
   
6. Run the app. After a few seconds you’ll see an app appear containing the ugliest of websites. But hey, it’s running HTML+JS so that’s pretty cool.
   
7. Let’s introduce a JS error. Open up Other files/html/index.html and break the JS, perhaps by removing a precious curly brace. If you run the app again you’ll see that the beautiful animation is gone. At this point you have a couple options like resorting to alert() debugging, trying the app in a desktop browser, selectively rolling back changes, etc but they all have shortcomings, especially when you have complex changes that rely on native code exposed by the Qt wrapper. The correct choice is to enable the Web Inspector, so let’s do that.
8. To display the web inspector change main.cpp to look like this:

#include <QtGui/QApplication>
#include <QtWebKit/QWebInspector>
#include <QtWebKit/QGraphicsWebView>

#include "html5applicationviewer.h"

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);

    Html5ApplicationViewer viewer;
    viewer.setOrientation(Html5ApplicationViewer::ScreenOrientationAuto);
    viewer.showExpanded();

    viewer.webView()->page()->settings()->setAttribute(QWebSettings::DeveloperExtrasEnabled, true);

    QWebInspector inspector;
    inspector.setPage(viewer.webView()->page());
    inspector.setVisible(true);

    viewer.loadFile(QLatin1String("html/index.html"));


    return app.exec();
}

If you run the app again you’ll be greeted with a friendly web inspector displaying the error you created earlier. Now, console.logs will appear in the console and be pretty-printed, you’ll be able to inspect cookies and local storage, place breakpoints, observe network requests and do everything else you can do with the developer tools in Chrome or Safari.

The post Enabling Web Inspector in QtWebKit appeared first on Palomino Labs Blog.



Palomino Labs unlocks the potential of software to change people and industries. Our team of experienced software developers, designers, and product strategists can help turn any idea into reality. Check out our website for more information, or send us an email and let's start talking about how we can work together.

When you download an application on OS X, the browser sets an extended attribute on the bundle that marks it as being quarantined. Starting in Mountain Lion, non-sandboxed apps with the quarantine flag set must be signed with a Developer ID. In practice, this means that if a user downloads an unsigned application from the internet and runs it, they’ll get an error message much like this one:

Developers who can’t sandbox their app because it needs extensive access to the system, or don’t want to for other reasons, can avoid this problem by getting a Developer ID certificate and signing their app before releasing it.

Signing an app

The first step is to get access to a machine running Mountain Lion. If you don’t have a physical machine with Mountain Lion, you can use VMWare Fusion and run Mountain Lion in a VM. This works quite well and it’s what we use here at Palomino Labs for making sure our apps work on non-developer machines.

Next you’ll need to get a Mac Developer account and generate a Developer ID in the web-based Developer Certificate Utility. Note that if you have a company ADC account, only the team agent can request Developer ID certificates.

Once you’ve downloaded the Developer ID certificate and installed it into the keychain you’re ready to sign and test it. To sign application bundle from the command line, do something like this:

codesign -s "Developer ID" YourAppBundle.app

The -s switch tells the codesign tool to use the signing identity whose name begins with “Developer ID”. If you have multiple Developer ID certificates installed on your machine the tool will complain that “Developer ID” is ambiguous and display a list of choices. You can solve this by providing the full name of the identity you want to use.

To test that the signing worked you’ll need to download the app bundle onto the Mountain Lion machine. Because the Developer ID restrictions are only applied to bundles with the quarantine attribute set, to properly test this the app bundle needs to be downloaded from the internet using a browser. You can verify that the app is quarantined by running

xattr -p com.apple.quarantine YourAppBundle.app

If that command prints something like

xattr: YourAppBundle.app: No such xattr: com.apple.quarantine

then the quarantine flag is not set and the Developer ID restrictions won’t be applied regardless of whether the app is signed correctly.

If you verify that the quarantine flag has been set and you don’t see the error when you open your application on a Mountain Lion machine then your app is correctly signed and your users will be able to download and run it without issue.

The post Getting Started With Developer ID for Mountain Lion appeared first on Palomino Labs Blog.



Palomino Labs unlocks the potential of software to change people and industries. Our team of experienced software developers, designers, and product strategists can help turn any idea into reality. Check out our website for more information, or send us an email and let's start talking about how we can work together.

• Provide better error messages: instead of saying “File (x) is in use” you can say “File (x) is in use by (some program)”.
• Infer things about what a program is doing: if Textedit has somedocument.rtf open then you know the user is probably
  editing somedocument.rtf without having to resort to using the accessibility API.
• Detect suspicious behavior: If a process has a bunch of system files open or a bunch of sockets open that might indicate
  it’s up to no good.

This post will walk you through writing get_process_handles which implements a small subset of the functionality in lsof. You can fork/clone the code at https://github.com/palominolabs/get_process_handles and follow along.

The first step is to make the skeleton app. It does nothing but display the PID requested by the user on the command line and print an error message if the user didn’t supply a valid PID.

Once that’s working we come to the tasty meat of the problem. The key method we’ll use is proc_pidinfo. Its prototype is

int proc_pidinfo(int pid, int flavor, uint64_t arg, void *buffer, int buffersize)

To use it we need to call it twice. The first time we pass NULL for buffer and buffersize and it will return the size of the buffer needed to hold all the information records about the given PID. We use that information to allocate a buffer of the appropriate size. Buffer in hand we can call proc_pidinfo again this time providing our buffer. It will populate the buffer with a series of proc_fdinfo instances. The code looks something like this:

int bufferSize = proc_pidinfo(pid, PROC_PIDLISTFDS, 0, 0, 0);
struct proc_fdinfo *procFDInfo = (struct proc_fdinfo *)malloc(bufferSize);

Then, since we know the size of the buffer and the size of each entry we can iterate over each entry in the buffer:

int numberOfProcFDs = bufferSize / PROC_PIDLISTFD_SIZE;

int i;
for(i = 0; i < numberOfProcFDs; i++) {
    // Do stuff with procFDInfo[i]
}

This is oodles of fun already, but we really want to display some useful information about each handle. Each proc_fdinfo has a field indicating the type of FD (socket, file, etc.) and the actual file handle. If we pass the type and the handle to the proc_pidfdinfo function it can give use details about the FD such as the socket or file path. Here’s how to get the path for a file handle:

if(procFDInfo[i].proc_fdtype == PROX_FDTYPE_VNODE) {
    struct vnode_fdinfowithpath vnodeInfo;
    proc_pidfdinfo(pid, procFDInfo[i].proc_fd, PROC_PIDFDVNODEPATHINFO, &vnodeInfo, PROC_PIDFDVNODEPATHINFO_SIZE);
    // File path is in vnodeInfo.pvip.vip_path
}

The code can be easily extended to display the open TCP sockets, too. It goes like so:

if(procFDInfo[i].proc_fdtype == PROX_FDTYPE_SOCKET) {
    proc_pidfdinfo(pid, procFDInfo[i].proc_fd, PROC_PIDFDSOCKETINFO, &socketInfo, PROC_PIDFDSOCKETINFO_SIZE);
    if(socketInfo.psi.soi_family == AF_INET && socketInfo.psi.soi_kind == SOCKINFO_TCP) {
        int localPort = (int)ntohs(socketInfo.psi.soi_proto.pri_tcp.tcpsi_ini.insi_lport);
        int remotePort = (int)ntohs(socketInfo.psi.soi_proto.pri_tcp.tcpsi_ini.insi_fport);
        if (remotePort == 0) {
            // Listening on localPort
        } else {
            // Communicating on localPort and remotePort
        }
    }
}

At this point our little utility can display open files and TCP sockets. You can clone/fork to your heart’s content at https://github.com/palominolabs/get_process_handles/. As a fun exercise you can extend it to support UDP sockets, open Appletalk ports, or installed FS event listeners by handling different values of proc_fdtype.

The post Getting the Files Being Used by a Process on Mac OS X appeared first on Palomino Labs Blog.



Palomino Labs unlocks the potential of software to change people and industries. Our team of experienced software developers, designers, and product strategists can help turn any idea into reality. Check out our website for more information, or send us an email and let's start talking about how we can work together.