#ifdef

Here’s my current theory developed after talking with a bunch of folks at the Ruby Hoedown.

The Ruby community is obviously very entrepreneur and freelance friendly. Though there are lots of Linux savvy users, you just can’t deny that there is a large faction of Rubyists that are Mac enthusiasts. That means that when Ruby developers think “mobile app” they are primarily thinking about iOS in its various flavors.

Programmers that make their way to Ruby and fall in love with the language tend to take a vow of Java chastity. They devour books like Beyond Java. The very premise of Rails is that you should have fun when programming and your framework should provide that. Developing with Android must seem like a giant step backwards; an unresolved cognitive dissonance. Who wants to be first in the pack to admit they’re hacking in Java again.

On the other hand, Android java doesn’t look any crazier than Objective-C. Maybe iOS developers have given Cocoa Touch a pass because it is an Apple product, I don’t know, but in the big picture compared to Ruby and compared to Rails, I don’t think either language is significantly more lovable than the other.

Of course, I am completely ignoring developers who have made platform decisions based on Apple vs Google store.

My working theory is that most of the people who find Android development emotionally and technically acceptable are probably the least likely to embrace freelance work in general.

For Android NDK development, it was getting a little irritating bouncing back and forth from Eclipse to Textmate then to a terminal to build an NDK shared library.

There are probably other alternatives, but I was wishing there was something like autotest available for Ruby and Rails projects. Even though it isn’t really enforcing TDD by running any tests, it saves tons of keystrokes while you’re tweaking your NDK project.

I call this little ruby script robomake. It should be run from the ndk directory. It watches the source files and when a change is detected, it runs the make which will build and install the given NDK project.

If you ‘chmod +x’, remove the .rb extension and place it in your executable path, it can run like this.

robomake hello-jni

where hello-jni is the name of an NDK project under the apps folder. The script will run ‘make APP=hello-jni’ each time a dependent file is changed. Run it from the root NDK folder where you would normally do your make.

#! /usr/bin/ruby
# A script to watch files and build Android NDK projects

interrupted = false
trap("INT") { interrupted = true }

def print_separator
  puts "============================================="
end

extensions = ["mk", "cpp", "h"]

if ARGV.size < 1
  puts "Usage: robomake.rb <app>"
  exit 1
end

app = ARGV.shift
app_folder = "apps/#{app}"
application_mk = "#{app_folder}/Application.mk"
command = "make APP=#{app}"

unless File.exists?(application_mk) 
  puts "#{application_mk} does not exist"
  exit 1
end

jni_path = ""
File.open(application_mk) do |file|
  while (line = file.gets)
    split = line.split(':=')
    if "#{split[0].rstrip}" == "APP_PROJECT_PATH"
      jni_path = split[1].strip << "/jni/**"
      break
    end
  end
  file.close
end

files = {}
extensions.each { |ext|
  Dir[jni_path + "/*.#{ext}"].each { |file|
    files[file] = File.mtime(file)
  }
}

system(command)
print_separator
loop do
  sleep 1
  if interrupted
       exit
  end

  changed_file, last_changed = files.find { |file, last_changed|
    File.mtime(file) > last_changed
  }

  if changed_file
    files[changed_file] = File.mtime(changed_file)
    puts "=> #{changed_file} changed, running #{command}"
    system(command)
    print_separator
  end
end

This is a trick worth sharing.

Apple doesn’t supporting exporting the list of devices you use in your adhoc provisioning profiles. But, you might want to export them to share with another developer or import into another team account.

When you look at the devices on the iphone portal, the device IDs are truncated. That prevents you from doing a multiline copy/paste of the data from your browser.

However, if you view the page source, you’ll notice that the entire device ID is actually present in each table row. So, just whack the style and css info. The remaining html table can be imported into a spreadsheet or pasted into a file and converted to a .csv.

Thanks, Josh!

This was really helpful. I was trying to simulate connection failures locally and by applying these Apache config changes and issuing ‘touch tmp/stop.txt’, the app throws returns a 503.

Ah, but you will need to restart Apache, ‘sudo apachectl graceful’.

… it’s possible to use mod_rewrite to prevent users from accessing your site during the deployment. Try this in your Apache virtual host configuration file:

[From Nodeta » Blog Archive » Stopping your Rails application with Phusion Passenger]

I’ve been seriously drinking from the firehose for the past few months, but I’m up to take a few breaths and commit to posting more about what I’m up to.

I’ve been fortunate enough to work with some really talented guys and clients doing iPhone and Rails app development. Objective-C was pretty easy to pickup. I call it a mashup of C and Smalltalk. Combine that with Cocoa Touch and you have a really nice development environment for the iPhone. The abstractions are high level enough that you don’t really have to be a mobile or embedded developer to get into it. Just take care to manage memory allocations and you’ll be fine.

Ryan, Josh and James over at YFactorial have done an awesome job with ObjectiveResource. It really makes it easy to quickly bring up applications with iPhone clients and Rails backends. Core Data is probably a fine library, but if you’re communicating with a Rails app, ObjectiveResource is a great way to serialize data without impacting the server development much.

The Ruby and Rails communities are just chock full of brilliant folks and the quality of teaching and training materials is awesome. It makes it a really exciting place to be working right now. I’m having about as much fun with the productivity hacks as I am with the platform itself. That’s been a really nice refresh.

There are a few product releases in the queue for 2009, so I’ll be busy. I hope you’re having as much fun as I am. I really mean that!

A client’s project requires a Java solution to fit their deployment strategy. One specific component of the implementation is an XML-RPC server. Using Groovy would be useful because there is a lot of XML being slung around as parameters. I could go with the Groovy XMLRPCServer, but it does not support SSL.

No problem, I’ll find a Java solution and Groovify it. How about the Apache XML-RPC implementation?. Excellent. However, I need to know that it works in its most basic, i.e. Java form. I’d rather not sandbox up an entire XML-RPC solution just to see how this thing works. Though small, there ought to be a better way than throwaway, experimental code. A nice way to deal with this is to use the published Calculator example with easyb.

The calculator class was unchanged. Here’s the easyb story that combines the xmlrpc server and client sides.

import org.apache.xmlrpc.client.*;
import org.apache.xmlrpc.webserver.*;
import javax.servlet.http.*;

scenario "apache xmlrpc server should work", {

        given "an xmlrpc servlet",{
          def sum = 0
          servlet = new XmlRpcServlet()
        }

        and "a servlet webserver", {
          webServer = new ServletWebServer(servlet, 4000)
          webServer.start()
        }

        when "the calculator.add method is invoked by an xmlrpc client", {
          config = new XmlRpcClientConfigImpl()
          config.setServerURL(new URL("127.0.0.1:4000/"))

          client = new XmlRpcClient()
          client.setConfig(config)

          sum = client.execute("Calculator.add", [33, 9])
        }

        then "the sum should be correct", {
          sum.shouldEqual 42
        }

        and "stop the webServer", {
          webServer.shutdown()
        }
}

Also, very nice how easyb allows some relaxation of the strict Java syntax in the xmlrpc client section. That starts to suggest what a Groovy subclass might look like. Next, a git commit to capture this working example in a readable form for the lifetime of the project.

There’s been a long running conversation about the relationship between static typing and unit testing. As early as 2003, Bob Martin found that unit tests reduce dependence on type safety. Around the same time Bruce Eckel argued that compilation is simply one test for correctness; and that code needs to pass all the tests that define correctness of your program. More recently, Stuart Halloway claims ‘In 5 years, we’ll view compilation as the weakest form of unit testing‘. Are you spotting a trend here?

This all bubbled up again for me recently on an embedded project I’m working on to optimize security policy lookups on a multicore security platform. The task was to optimize performance of the vendor’s C reference implementation. Policy insertion used a simple, but unscalable single linked list having O(n) performance. Of course, the code comes without tests of any kind, so how does one know that the optimization changes don’t break basic functionality?

Obviously, the best thing to do in this situation is to write tests for existing behavior so that as the API is refactored and reimplemented, the tests find any new logic errors. I got payback even before the optimization work got started. The linked list insert (implemented thousands of times by thousands of developers) had a bug in it. Policies that were supposed to be stored in priority order after insert were off by one.

Definition: Reference System n. A software implementation provided by hardware vendors to demonstrate programming of a target device; not intended for deployment in end user products. (2) A software implementation provided by hardware vendors that is for the most part, directly inserted into the systems of end users.

This really isn’t a rant about reference code, it’s about defensive testing and the fact that writing tests are not just for dynamic languages. The Java community is mostly on board with this, but it seems to have gotten slower adoption by the C variant world. So c’mon embedded developers. Let’s stop pretending that the type safety testing by our compilers is good enough.

Here’s one option. I really like check as a unit test tool for C. It has a niced xUnit flavor and ought to be in everyone’s toolbox.

START_TEST(it_should_insert_in priority_order)
{
    Policy* policy5 = alloc_policy_with_priority(5);
    Policy* policy6 = alloc_policy_with_priority(6);
    insert_policy(policy5);
    insert_policy(policy6);
    fail_if(policy_find(policy5) == NULL);
    fail_if(policy_find(policy6) == NULL);
    fail_unless(policy_first() == policy5);
}
END_TEST

And if you happen to be implementing reference code, a set of tests for your API would be a welcome addition to your product; not a program to exercise the hardware, but tests that verify and document the behavior of your APIs. It will reduce the bulk of documentation that needs to be provided to end users and may allow you to remove those weasel words, “not intended for deployment”.

Exactly who hired the B players then?

“A players hire A players,” he said. “B players hire C players. Do you get it?”

[From Folklore.org: Macintosh Stories: How to Hire Insanely Great Employees]

It turns out that some changes to the Linux kernel — Ubuntu 8.04 uses Linux 2.6.24 — have introduced some issues that make running Ubuntu in a VMWare virtual machine difficult. Ubuntu will install just fine, but you won’t have access to VMWare Tools, which provides some nice features like shared folders and clipboard syncing.

[From Ubuntu 8.04 Causes Problems With VMWare Tools, Open Source to the Rescue | Compiler from Wired.com]

It isn’t just VMWare. Mac Parallels has likewise bitten me and many others judging by the considerable forum angst. My peeps have been telling me to cutover to Fusion. I’d say if VMWare fixes their tools issues before Parallels, I’ll consider it.