MS SQL starts on wrong port

Over the past few days we’ve been working with one of our clients to develop an enterprise search solution for one of their databases. Due to various historical reasons, the database is on MS SQL and has to stay that way. No worries right? Fail.

I decided to move forward with Solr because of its DataImportHandler feature and its ability to easily expose search results in various formats (JSON, XML, PHP serialized objects, etc).

For some reason I can’t seem to get MS SQL server to open on the port it is configured to. This proved particularly hairy to debug because I couldn’t tell if my JDBC DSN binding was failing, the JDBC driver was failing, or if the DB server was actually mucking it up.

The JDBC URL I’m using is:

url=“jdbc:sqlserver://localhost:1170;databaseName=dbName;User=test;Password=*****”

To try and narrow things down, I used the Eclipse Data Tools package to let me use a JDBC driver from within Eclipse to connect to the server. Using this, I could clearly see that the exception being thrown was that the MS SQL server was not accepting connections on port 1433. As far as I can tell MS SQL is set up correctly.

sql-server-1 sql-server-2

I checked the MS SQL start up log and it was showing this:

Server is listening on [‘any’ <ipv4> 1170]
</ipv4>

I tried using 1170 in Eclipse and Solr and bang everything fell into place.

What is weird is that the configuration is showing that the server should be running on 1433. If anyone has any idea why this is happening I’d love to know for future reference.

I replicated this behavior on a production machine. In both instances I was using MS SQL Server 2008 Express. On the dev box I was running Windows XP SP2+ and the production box was running Windows Server 2003.

sfWidgetjQueryTimepickr - Symfony timepickr widget

A couple of months ago John Resig posted on his blog about a “new” way for users to pick time.

The component is a jQuery plugin called timepickr and I thought it was particularly neat. Anyway, I finally needed to write a form which had a time component so I figured I’d drop in the timepickr jQuery plugin.

It didn’t look like there was a Symfony Forms widget for it so I whipped one up. You can grab it here

.

The only issue with timepickr is that it introduces a ton of dependencies. It requires jQuery, jQuery-ui, jQuery.utils, jQuery.string, and ui.dropslide. Additionally, it needs the dropslide css as well as the timepickr css.

The form widget assumes that you will include jquery-ui by yourself since everyone usually has different naming conventions. It will include the other JS files and CSS files for you.

You can download a package with all of the JS and CSS you need here

. Again this DOES NOT include the jQuery-ui stuff. YOU have to include that yourself in your Symfony project as well as on the page that you deploy this widget.

To use it, just drop it in your Symfony project somewhere where classes get autoloaded (projectdir/lib works) and then instantiate a widget with new sfWidgetjQueryTimepickr() . It currently will support all of the timepickr options passed in as widget options (on the constructor). Full documentation for timepickr is here.

Have fun picking time.

Gmail fail

Looks like someone at gmail forgot to make sure the system won’t display negative time for future timestamped emails. I’m not sure where/how this email got a bad timestamp but gmail is displaying it as being sent in the future! See it!

Client side RSS aggregator

One of our clients came to us a few days ago asking us if we could build something to aggregate several RSS feeds and then display it on their site.

Easy enough. Except the caveats were 1) This had to be done on a shoe string budget and 2) We had no permission to script on the server side (only client side scripting allowed kids).

We put our heads together and realized that Yahoo Pipes would provide the functionality to easily combine several RSS feeds, sort them, filter them, ect. And best part? It’s all built and all free. Pipes also provides the functionality to export a pipe as a JSON feed (as opposed to RSS).

So that takes care of problem 1 and almost fixes problem 2. Of course the remaining problem is getting around the cross domain XHR restrictions on the JSON. I did some poking around the Yahoo Pipes documentation and it turns out you can add a _callback parameter to the URL and bang it wraps the JSON in a JS callback!

Issues solved. The final part was to mix in a little jQuery to load the JSON+callback feed into a <script> tag and then display it.

Total lines of code: 27 lines of javascript.

EDIT. Now with code!

$(document).ready(function(){ $("body"). append('<div id="rss-script"><script src="
  http://pipes.yahoo.com/pipes/pipe.run?_id=CuFeIogD3hG4ERynPxJ3AQ&_render=json&_callback=renderRSS" type="text/javascript"></script></div>'); });

function renderRSS(obj){ var stories = obj.value.items; var desc;

  $("#rss-loading").html("<span id='powered-setfive'>Powered by <a href='http://www.setfive.com'>Setfive Consulting</a></span>");

  for(var i=0; i < stories.length; i++){

    $("#temp").html(stories[i].description);

    desc = ( $(".rteleft:first").html() != null )? $(".rteleft:first").html() : stories[i].description;

    $("#feed").append("<div class='story'>" + "<h2><a href='" + stories[i].link + "' target='_blank'>" + stories[i].title + "</a></h2>" + "<p>" + desc +
			"</p>" + "</div>"); } }

function viewFeed(){ window.open("http://pipes.yahoo.com/pipes/pipe.run?_id=CuFeIogD3hG4ERynPxJ3AQ&_render=rss", "GAP RSS"); }

Hello Android!

In the last few weeks the battle and buzz over the smart phone market seems to have seriously intensified.

First there was the usual iPhone buzz, news about the Android powered HTC Magic, the Windows Mobile marketplace, and of course the obligatory ridiculousness at Microsoft.

I’d been considering experimenting with a mobile platform for sometime and finally decided to take the plunge. I decided to give Android a whirl primarily because I don’t have easy access to OSX or Visual Studio and my Java is less rusty than my .NET.

Anyway, getting going with Android was deliciously simple - download the SDK+Emulator and Eclipse plugin and you’re off.

After the necessary “Hello World” application I tried to write something a bit more substantive. Personally, one of the coolest facets of mobile development is the ability for applications to be location aware (GPS). Mix this together with some openly available geo tagged data and the result is probably going to be interesting.

With this in mind, the plan became to mash together Android’s GPS coordinates with flickr’s geotagged photos.

Getting access to Android’s location service is fairly straightforward. You basically register to receive updates either when the device moves a certain distance or on some time interval:

LocationManager locationManager = (LocationManager)getSystemService(Context.LOCATION_SERVICE);        
flickrLocationReciever flReciever = new flickrLocationReciever();
locationManager.requestLocationUpdates( locationManager.getProviders(true).get(0),  5, 10, flReciever);

public class flickrLocationReciever implements LocationListener {
  @Override
   public void onLocationChanged(final Location arg0) {
    // do things
   }
}

The biggest “gotcha” with this is that you NEED to remember to modify the default Application security settings to allow you to access the device’s location. In Eclipse, edit AndroidManifest.xml and add “UsesPermission” for the following: android.permission.ACCESS_MOCK_LOCATION, android.permission.ACCESS_COARSE_LOCATION, android.permission.ACCESS_FINE_LOCATION

So on to part II - using the device’s location to pull down Flickr photos. I’d used the Flickr API before so I knew how to do it but I’d never used it from Java. I tried loading the JAR for the flickrj client library but the Android JVM was having some strange issues with it. I was under the impression you can link to external JARs from Eclipse but I may be wrong (anyone?).

Anyway, the Flickr requests were un-authenticated and pretty straightforward so I decided to use Java’s URL class. Accessing sockets was another “gotcha” - Android requires your application to have the “UsesPermission” android.permission.INTERNET to use sockets. The exception when the permission isn’t set is notably cryptic - “unknown error”.

I decided to download all the Flickr photos to the device so that the UX would be generally smoother. This introduced threading to the project so that the UI wouldn’t freeze up while the photos were downloading. Android threads work just like traditional Java threads and the process was generally painless:

private Handler handler = new Handler()
  {
   public void handleMessage(Message msg) {
   // handle the end of the thread
  }
}

Thread t = new Thread()
   {
     public void run(){
     // do stuff
     // let the handler know we are done
     handler.sendEmptyMessage(1);
     }
}
T.start();

With the photos pulled down the final task was displaying them. After poking around the Android documentation I discovered the Gallery widget. It basically allows you to display a set of items in a list and specify a “renderer” for the gallery. I’m not sure if there is a default way to make it “fisheye” (like on an iPhone) but I rolled a quick n dirty solution for that. I also couldn’t get it to look really sexy but that’s also probably possible.

So that’s about it. Here are some screen shots of the application running in the emulator:

screen1 screen2 screen3

And without further a due here is the code as an Eclipse project. geoflickr

Anyway, before the bashing starts - I know I’m a terrible Java programmer and that this project isn’t really engineered beautifully. It was just supposed to be a way to get my (and anyone else’s) feet wet with Android. Any comments/thoughts/improvements are of course welcome!