For the past few months, I have been running the iPhone OS 3.0 betas on my iPhone without too many issues. Thus I assumed that when the final version of OS 3 was released, it would be easy to upgrade to it. This has not been the case. The current beta on my iPhone was beta 5, and then yesterday when the final version was announced, I assumed after a simple plug in to iTunes, I would be upgraded to the released version. Nope, iTunes kept telling me that I have the latest version of iPhone OS 3. It seems as though it is not checking the build number, only the OS level. The next thing I tried was doing a restore, this didn’t work either because it gave me an error saying it could not connect to the site to download the file.

Finally, after some Googling around, I found that others with the same problem circumvented it by putting their iPhone in recovery mode and then upgrading from there.

If you are currently running beta 5, you were supposed to upgrade to the GM version posted last week. I skipped it thinking their would be another release in the next few days with the final version. I have now learned that the GM version is the same as the final version. Unfortunately, now it is too late to download the GM from the developer website, as Apple has taken it down, and according to their documentation, you should obtain the final version through iTunes. Thus if you are in the same boat as me, on beta 5, you will have to install the latest version via recovery mode.

Who doesn’t like easy upgrades? Easy upgrades are great when implemented correctly. There are two speciifiic easy upgrades I have been (enjoying) using recently, namely, Wordpress and Ubuntu Server.

Wordpress

This blog has been powered by Wordpress for a long time, and has been upgraded many times along the way. Download the latest tgz file, unzip it, save your wp-content directory, upgrade your database, and then you are good to go. Keep in mind this was a very simple procedure, as they call it their “famous 5-minute installation”, which it typically was.

Once upgrading to 1.7, the procedure became as easy as clicking a link on the admin page, and stepping through a wizzard This blog is now running 1.8, so it has been through several automatic upgrades already, and each one of them has been completely boring, which when talking about upgrading an environment, is a very good thing. This magic does not only apply to upgrading the entire platform, as you can automatically upgrade your plugins as well.

Ubuntu

Many years ago I set up several Ubuntu Gutsy Gibbon (7.10) Servers in my basement to serve different purposes on my internal network. These servers have been running without issue for the past 2 years. They would probably run seamlessly for another 2 years, but unfortunately, I needed to install a new package that didn’t have a deb available for the current version of Ubuntu. At first I was trying to find ways around this, installing the sources instead, but that didn’t work well for me, as it needed a newer version of a dependent library. Even considered trying a different software package, but it seemed like all of the software packages I was trying to install, required a newer version of Ubuntu.

What was I left to do? Either upgrade or rebuild from scratch. Based on past experiences with other distros, upgrades have been nothing but headaches for me. Since, I really didn’t want to invest the time to rebuild the server from scratch, decided to try my first Ubuntu upgrade. Again, based on my past experiences, I assumed I needed to download the media, and then hook up a monitor to the server, and finally go through a set of upgrade screens.

To my delight, after a little bit of research I found that you can do the entire upgrade from the command line), no user interface required, no media download required, no monitor required! This was too good to be true right? Well, no. I ran the do-release-upgradecommand, and now my server is running Hardy Heron (8.04). Couldn’t be any easier. Ubuntu’s upgrade infrastructure is very impressive.

What is the moral of the story? If you want to build a loyal user community, treat the members of the community well by providing them with an easy upgrade path.

It has been a while since a single program changed my workflow as much as Quicksilver has.

Over the years, it has been covered a lot on the Mac sites, but it never really seemed like something that would help me. Guess it was the stubborn side of me refusing to try something new. So the question is what changed my mind now? Two things:

• The Productive Programer: In his book Neil Ford describes several work flows involving Quicksilver that actually made sense to me, especially the Subversion plugin.
• Pragmatic Thinking And Learning: Again, the virtues of Quicksilver described in such a way, that made a lot of sense to me.

After reading these two excellent books, it was time for me to give it a try, and see what it has to offer. It has been about a week now, and it is hard to imagine using my Mac without it. It has increased the efficiency of my workflow tremendously. The mouse has become optional for most tasks. It has sped up common tasks for me such as checking in/out files from Subversion, opening documents to edit, quickly composing emails and attaching files, and my favorite time saver is this neat trick that allows you to lock your computer with a simple keystroke. Previously, it required clicking on the “lock screen” option in keychain.

If you are a Mac developer like me, and you are in to efficiency, you need to at least give Quicksilver a try. You won’t be disappointed.

Lately it seems like functional programming has been the talk of the town, the new (old) paradigm that is making a comeback in a major way. For a while, I resisted the urge to follow the paradigm de jour, being the hard core OO guy that I am, but now it is clear to me that it is more than just hype. There are many reasons functional programming makes sense as a paradigm for developing software today, but the one that I am most interested in is the fact that it handles concurrency so well, thus providing us the building blocks to develop extremely scalable applications.

FP(Functional Programming) has been on my mind for a while. The seed was placed there in late 2007 by the Java Posse listening to their interview with Martin Odersky. They were not talking about FP per se, but more about a specific JVM language called Scala (pronounced skah-lah not scale-la). Scala is not a pure functional language, it is actually a fusion between functional and object oriented programming. It brings together the best of both worlds. My exposure to Scala did not end there, as I got another huge dose at Java One 2008. Two of my favorite sessions there were either on Scala, or Scala was a major discussion point.

The first session was the Script Bowl. This session was not specifically about Scala, it was more of a JVM scripting language battle, and in the end JRuby was crowned king by the audience. In my mind, Scala was the clear winner, because of the simple, yet elegant and powerfull concurrency demonstrated. The presenter wrote what looked like a relatively simple program, and it was capable of indexing tons of RSS feed dumps in real time on a typical multi-core laptop computer. I remember thinking to my self, wow, it would take me a lot more time and effort to write a similar program in Java, and it probably wouldn’t have the same level of scalability as the one demonstrated. The Scala code was able to fully utilize the multi-core processors it was running on.

The second session was on Scala presented by the father of Scala him self Martin Odersky. During that session I was wowed again with some of Scala’s features like it:

• is scalable because it works for very small and very large systems.
• “is the Java programming language of the future.”
• is object oriented, functional, and a scripting language.
• leverages Actor’s as the primary concurrency construct.
• fits seamlessly in to a Java environment.
• is a composition language, as it adds the notion of Traits.
• has an updated type system supporting type inference.

After those two sessions, I headed over to the Java One bookstore to check out the Beta version of Programming in Scala. I was impressed, but couldn’t help thinking, is Scala for me? Can I use it at work? Is it viable in the enterprise?

Fast forward 7 months to today, and let me answer my own questions with one word: yes!

• Is it for me? Yes, because Scala is not only something new, it is something advanced, because it was written in a no compromise academic environment. If nothing else it is a great way to broaden my horizons as a programmer.
• Can I use this at work? Yes, Scala code compiles down to Java byte code, so theoretically, if I was very evil, I could write all my code at work in Scala, run Scalac on it, and add the class files to the application, and no one would be any the wiser. Will I do that? No way, I am simply trying to illustrate a point that Scala is totally compatible with any existing Java environment.
• Is it viable in the enterprise? Yes, with its advanced concurrency model, I can only imagine the type of throughput you can achieve. (Looking forward to finding out)

Now you know where my interest in Scala comes from. Hopefully after reading this post, you will be a bit curious about it as well.

Just noticed a new and important feature released with the latest nighty build of Webkit, namely, an option to check for updates automatically. Mozilla has had this feature in their browsers for a long time, and it was hard not having it available in Webkit. Just got used to downloading a new version every so often.

The days of remembering to update Webkit are now over, the latest nightly knows how to keep it self in sync with the current nightly build.

Here is the option you are presented with the first time you open the latest Webkit.

If you choose to say no to the above dialog, or if you are like me and you leave your browser open all the time, and you want to check for updates manually there is that option too.

Once the process is complete, you will see the following dialog letting you know you are up to date.

It is great to see this much needed feature has finally arrived in Webkit. Hopefully this will entice more people to jump on the Webkit nightly bandwagon.

Do you want to learn all of the keyboard shortcuts to your favorite Java IDE, but just don’t have time to study a cheat sheet? Are you envious of your team lead because when you peer program with them, they are able to get things done without using the mouse?

You ask your self how did they do it? Do they memorize a cheat sheet while on the Subway? Do they go home and practice coding every night? Are they gifted with great memories? Well, they may be all of these things, but you don’t have to be!

All you need to do is install a plugin called Key Promoter that is available for both Intellij and Eclipse. The way it works is every time you use your mouse to accomplish a task that can be accomplished via a keyboard shortcut, it pops up a window and lets you know. In the Intellij version, it actually keeps track of how many times you used your mouse for each action. It becomes insulting after a while if you see you used your mouse 20 times for the same action, knowing it has shown you the corresponding keyboard shortcut each time.

For more details you can find the Intellij plugin here, and the Eclipse plugin here.

In part one of this series, we examined one potential solution that turned out to be not so good. In this post lets try to find a solution using the same design, but a better implementation.

To recap, we decided to use the simplest solution which is to add a security hash to each service call. The first approach we tried was adding the security hash to the XML payload of each service call. The conclusion was that approach was not very elegant, and actually quite ugly.

Let us now discuss a more elegant solution. Keeping the same parameters in place, namely, we want to pass the hash along with each service request, where can we place it where it will not cause the implementation to be ugly? Why don’t we try by add the Hash as a field in the Http header?

The request would look like:

1
2
3
4
5
6
7
8
9
10
11

PUT http://blah.com/services/someEntity/226 HTTP/1.1
Accept: text/xml
Content-Type: text/xml
User-Agent: Jakarta Commons-HttpClient/3.1
Host: somehost:port
Hash: 53b383c67a03d23a38b6f52f4a732553
Content-Length: 380
<someEntity>
    <fieldOne> fieldOne </fieldOne>
    <fieldTwo> fieldTwo </fieldTwo>
</someEntity>

As you can see, the hash has been added to the Http header (line 6). To verify the hash, we need to do create a Servlet Filter that verifies the Hash.

A very simple filter would look like:

1
2
3
4
5
6
7
8
9
10

public class VerifyHashFilter implements Filter {
   public void doFilter(ServletRequest request,
            ServletResponse response,FilterChain chain)
            throws IOException, ServletException {
     if(((HttpServletRequest)request).getHeader("HASH").equals("12345"))
        chain.doFilter(request,response)
     else
        ((HttpServletResponse)response).setStatus(401);
   }
}

Then our service code implementation would change to:

1
2
3
4
5
6
7
8
9
10
11

@Path("/services")
public class SomeEntityServiceImpl {

    @PUT
    @Path("/someEntity/{id}")
    @Consumes("text/xml")
    public void updateSomeEntity(SomeEntity entity,
                @PathParam("id") int id) {
    dao.saveOrupdate(entity)
    }
}

To test our service, we can use curl:

1
2
3
4
5
6
7
8
9
10
11

$ curl -i  -H 'HASH:12345' http://localhost:9095/rest-test
HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: 71
Server: Jetty(6.1.14)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<someEntity>
    <fieldOne>fieldOne</fieldOne>
    <fieldTwo>fieldTwo</fieldTwo>
</someEntity>

And the negative test:

1
2
3
4

$ curl -i  -H 'HASH:54321' http://localhost:9095/rest-test
HTTP/1.1 401 Unauthorized
Content-Length: 0
Server: Jetty(6.1.14)

As you can see, the implementation code is much cleaner and reusable now. The service code can be called from anywhere within the application without having to worry about a security hash. It is safe to assume that if the code makes it as far as the service, it passed through the security filter thus making the request authorized. Having that assumption as part of the design allows you to write much more generic and reusable code.

Please keep in mind this concept is nothing new, as this solution is an over simplification of how the Spring Security module works. The value in this solution is it doesn’t have dependencies on any external frameworks. When designing this solution, that was one of the determining factors.

Next time you need to implement a quick authorization mechanism for your REST service, make sure you keep the Http header along with a Servlet filter in mind.

This is going to be the first in a series of posts discussing potential ways of securing bi-directional RESTful based HTTP services. For this series we are going to make the requirements quite simple, namely, “secure” simply means the caller of the service is authorized to invoke it. Lets assume that this solution is being deployed along with a simple IP addresses restriction mechanism. Since IP address’s can easily be spoofed, this solution is the next level of defense to ensure the identity of the caller.

There are many different potential solutions to this problem, but for this series, we are going to focus on the simplest solution which is to add a security hash to each service call. This post assumes you understand how to secure B2B communications with the use of a security hash. If you need a refresher, please refer to this post on the subject.

Since we know the design for securing our communications, we need to decide on an implementation. The first potential implementation we are going to examine is adding a “security hash” to the XML payload for each service call.

The embellished XML payload would look like:

1
2
3
4
5

<someEntity>
    <hash>4723af11bef05fc6207bd22cd163d9db</hash>
    <fieldOne> ... </fieldOne>
    <fieldTwo> ... </fieldTwo>
</someEntity>

with the “hash” field (line 2) representing the security hash.

The interface of the SomeEntity service, would look like:

1
2
3

public interface SomeEntityService {
    public void updateSomeEntity(SomeEntity entity, int id) throws SecurityException;
}

with an implementation that looks like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

@Path("/services")
public class SomeEntityServiceImpl {

    @PUT
    @Path("/someEntity/{id}")
    @Consumes("text/xml")
    public void updateSomeEntity(SomeEntity entity,
                    @PathParam("id") int id)
                        throws SecurityException {
        if (validateHash(entity))
            dao.saveOrupdate(entity)
        else
            throw new SecurityException("Not Authorized");
    }
}

With the actual HTTP Client call looking like:

1
2
3
4
5
6
7
8
9
10
11

PUT http://blah.com/services/someEntity/226 HTTP/1.1
Accept: text/xml
Content-Type: text/xml
User-Agent: Jakarta Commons-HttpClient/3.1
Host: somehost:port
Content-Length: 380
<someEntity>
    <hash>4723af11bef05fc6207bd22cd163d9db</hash>
    <fieldOne> fieldOne </fieldOne>
    <fieldTwo> fieldTwo </fieldTwo>
</someEntity>

There you have it, our first potential solution to the problem. We now need to examine if this solution is correct, and if it is, is it elegant?

First things first, is it correct? If you trace through the code, you can see that before the service makes a call to the DAO, it checks to verify the validity of the hash field (line 10). If the hash it is not valid, it will throw an Exception, which in turn would return a 401 to the user. It would not be possible for a client to access the DAO without having the proper hash as part of the XML Payload.

Even though this approach would perform as expected, it has two main issues, the first being it mixes concerns. What we mean by mixes concerns is it mixes business logic with security logic. This is a standard problem that applies to layered architectures. The main side effect of this problem is it makes the code very difficult to reuse. Lets me demonstrate this with a simple code fragment:

1
2
3
4
5
6

// Code in a Web Controller class somewhere
try {
    someEntitySvc.updateSomeEntity(entity);
} catch (SecurityException e) {
    // Nothing we can do... We don't have the hash???
}

As you can see from this simple example the implementation of the service is not generic enough to be usable by a Controller in the Web Tier. Firstly, even if the Web Tier knew about he hash, the code becomes polluted with Exception handling for an Exception that is not applicable to this client. Secondly, the Web Tier simply doesn’t have any knowledge of the hash, and putting logic here to generate the hash just to use the service would not make any sense from a design perspective.

The second issue with this approach is the fact that you can only apply it to Http methods that accept a payload. What about methods that do not accept a Payload, I.e., GET? To make this work for the GET method, we would have to pollute our GET method implementation with a @Consumes(“text/xml”) tag, which functionally would work, but from a API design perspective, it is quite ugly. As a consumer of a GET method, all you need to know is the id of the entity you wish to “get”. Adding an XML payload for “security” purposes is a bad and cumbersome design.

With all that being said, it looks like this is not the best solution to the problem. Stay tuned for part two of this series where we will discuss a more elegant approach to solving this problem.

Was just presented with a unique (to me) requirement which is to implement a single sign on across multiple domains within the same page via a cookie. Huh? Let me elaborate, in simple terms it means that there is a base site, lets call it foo.com, and then there is a partner site, lets call it bar.com. On foo.com’s main page we want to be able to iFrame in bar.com with the credentials of the current user logged in to foo.com transparently sent over and in turn logged in to bar.com as well.

In order to achieve this, the first thing that needs to happen is the two sites need to have a sub domain in common. The easiest way to accomplish this is to set up an alias on the parent site (foo.com) to bar.com. The alias would be something like bar.foo.com which points to bar.com. This is required because if they do not have a domain in common there is no way for them to share cookies.

The next thing that needs to happen is both sites have to agree on a way of authenticating a user. In our case we used a cookie that consisted of the user id followed by a hash of the user id which looked something like 12345,jfk83jf835jfiie43.

Your probably wondering how this simple cookie can facility a single sign on across two different sites? Let me explain, first lets talk about the how the values of the cookie are generated. The first value, namely, the user id, is self explanatory. The second part of the cookie, the hash, has a little bit more to it. In order to effectively use the hash, the two sites need to have a “shared secret” aka “The Salt” that only they know.

In order to generate the hash, you append the salt to the user id, and then run it through a one way hashing function. The result is a unique key that can only be generated by the two parties who know the salt (or generated by anyone who knows the salt, so make sure the salt stays very secure). Since it is a one way function, it would be very difficult for someone to reverse engineer it.

Now that we have the id and the hash explained, lets talk about how bar.com can use this to authenticate the user. When a user on Foo.com first logs in, the shared cookie is created by foo.com, and when they hit a page in the iFrame which is pointing to bar.com, bar.com checks the cookie. If it is there, it has the user id and hash of the remote user.

Step one for bar.com is to take the user id, hash it (based on the agreed upon salt), and first verify that it matches the hash that is supplied as the second part of the cookie. If it matches, it is safe for bar.com to assume the user id in the cookie is the user id of the remote user, thus bar.com can log the user in.

This method is not the most secure method of doing a single sign on as a hacker can easily do a man in the middle attack and thus obtain the cookie, and hash, and then with the user id and hash in hand, can easily log in to bar.com as the remote user.

There are a few precautions you can take if you choose to use this method like adding values to the salt like, date, time, request id, that would make the request unique not only to a user, but to a specific time of day or a specific request. Another approach you can take to make this more secure is to simply use SSL across the wire.

Keep in mind we used this method as a simple way of verifying user identity, we were not concerned with either site getting hacked as we had other security mechanisms in place.

So, please take this approach with a grain of salt.

The recent release of Google Chrome Beta for Windows has re-stirred the good old browser wars. Chrome is based on WebKit, but uses the V8 Javascript Engine Currently Chrome is a Windows only browser, so it is not possible for me to benchmark the browser first hand, but the claims have been that it is faster than both Firefox and WebKit on Windows.

Those are pretty bold claims, especially since the folks over at WebKit just released the SquirrelFish Extreme Javascript engine. Based on my initial personal non-scientific benchmarks, it looks fast! Almost 2x’s as fast as the previous SquirrelFish implementation. See the results below.

After using WebKit for the past two months it is clear to me, WebKit is the best browser for me on Mac. There is one small issue with using WebKit, namely, since you are running a nightly build, you need download and update the binary quite often, and some of the time, the daily build is not the stablest. Again, this is just a minor price to pay in order to take advantage of the latest and greatest build. It is nothing specific to WebKit, it applies to any beta software.

Latest Results

• WebKit (SquirrelFish Extreme) Results URL
• WebKit (SquirrelFish) Results URL

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

TEST                   COMPARISON         FROM                 TO
                                         (SquirrelFish)    (SquirrelFish Extreme)
=============================================================================

** TOTAL **:           1.86x as fast     1918.6ms +/- 0.9%   1032.6ms +/- 1.4%    

=============================================================================

  3d:                  1.59x as fast      260.6ms +/- 2.9%    164.2ms +/- 4.6%
    cube:              1.53x as fast       84.2ms +/- 5.9%     55.2ms +/- 4.3%
    morph:             1.36x as fast       82.8ms +/- 2.0%     61.0ms +/- 4.8%
    raytrace:          1.95x as fast       93.6ms +/- 4.3%     48.0ms +/- 11.1%    

  access:              2.49x as fast      280.2ms +/- 4.1%    112.4ms +/- 6.0%
    binary-trees:      1.64x as fast       36.0ms +/- 15.1%     22.0ms +/- 22.2%
    fannkuch:          4.76x as fast       88.6ms +/- 3.8%     18.6ms +/- 9.0%
    nbody:             2.03x as fast      124.8ms +/- 7.3%     61.6ms +/- 2.3%    

  bitops:              2.31x as fast      188.8ms +/- 4.5%     81.8ms +/- 9.9%
    3bit-bits-in-byte: 1.96x as fast       26.6ms +/- 13.5%     13.6ms +/- 24.7%
    bits-in-byte:      1.96x as fast       32.6ms +/- 8.8%     16.6ms +/- 22.2%
    bitwise-and:       1.77x as fast       54.8ms +/- 4.4%     31.0ms +/- 15.5%
    nsieve-bits:       3.63x as fast       74.8ms +/- 14.5%     20.6ms +/- 15.7%    

  controlflow:         1.35x as fast       27.0ms +/- 22.6%     20.0ms +/- 19.2%
    recursive:         1.35x as fast       27.0ms +/- 22.6%     20.0ms +/- 19.2%    

  crypto:              1.98x as fast      129.6ms +/- 7.7%     65.4ms +/- 6.7%
    aes:               2.51x as fast       45.6ms +/- 14.8%     18.2ms +/- 24.3%
    md5:               1.74x as fast       39.6ms +/- 14.8%     22.8ms +/- 6.0%
    sha1:              1.82x as fast       44.4ms +/- 27.6%     24.4ms +/- 6.8%    

  date:                1.78x as fast      172.6ms +/- 2.6%     96.8ms +/- 2.9%
    format-tofte:      2.42x as fast      105.2ms +/- 3.5%     43.4ms +/- 3.3%
    format-xparb:      1.26x as fast       67.4ms +/- 5.6%     53.4ms +/- 5.8%    

  math:                1.50x as fast      206.6ms +/- 4.1%    138.0ms +/- 1.7%
    cordic:            1.59x as fast       67.6ms +/- 5.9%     42.4ms +/- 4.4%
    partial-sums:      1.45x as fast       97.8ms +/- 3.7%     67.6ms +/- 3.6%
    spectral-norm:     1.47x as fast       41.2ms +/- 8.6%     28.0ms +/- 6.3%    

  regexp:              4.27x as fast      198.8ms +/- 1.6%     46.6ms +/- 6.4%
    dna:               4.27x as fast      198.8ms +/- 1.6%     46.6ms +/- 6.4%    

  string:              1.48x as fast      454.4ms +/- 1.6%    307.4ms +/- 2.4%
    base64:            2.56x as fast       64.6ms +/- 4.0%     25.2ms +/- 10.7%
    fasta:             1.43x as fast       85.4ms +/- 3.4%     59.6ms +/- 5.6%
    tagcloud:          1.14x as fast      112.0ms +/- 7.2%     98.2ms +/- 2.7%
    unpack-code:       1.75x as fast      118.6ms +/- 3.4%     67.8ms +/- 3.0%
    validate-input:    1.30x as fast       73.8ms +/- 4.0%     56.6ms +/- 9.5%