One of the big overriding factors is how much external influences impact people. The location and cultural context in which someone is born, the year in which they were born, and even the birth month has a huge impact. Before reading the book I would have had no idea, after I can agree with him, but don’t worry, I’m not about to become an astrologer, and I don’t think it is directly related to the Chinese birth years (although there might be some links). Of additional interest is the idea of 10000 hours of practice being required to become an expert.

The quick list of impacts of particular interest for me were:

1. 10,000 hours of practice is required before becoming an expert
2. the birth month can have a huge impact (6-9 months of age difference can make a huge difference in early childhood – so early streaming favours the older children, with cascading effects)
3. the birth year can have a huge impact (careers available, and many hugely successful people are early adopters, so there is only a small window of age/experience that makes it available)
4. our cultural heritage makes a huge difference (what path and options make sense is often dependant on how we are guided by our parents, which cascades backwards)

The lessons are taught well through the book, and it is a compelling read. You may not agree with all the findings, but I’m sure you will get a good read, learn the stories of some successful people, and be challenged in some of your thinking about success.

If you are interested in having a look at the site he put together, or if you are interested in buying a house in the coastal suburb of Wynnum, in Brisbane, Australia, take a look at Bayside House For Sale.

I always find the latest incarnations of phishing spam entertaining.  I almost clicked on one of the fake facebook links a while ago, but really wasn't at all tempted to click on the links in the one that came in today..

Yes, I am looking at that message in Mail.app, and viewing the source did show that the link didn't go to where it said it would go.

1. open the eclipse preferences pane
2. general->keys
3. in the filter type line start and note that there will be existing bindings when editing text.
4. select line start type home, and ensure that the "when" field stays with Editing Text
5. apply
6. follow this process for select line start, line end, and select line end.

After doing this, expect your anger at eclipse on Mac to decrease to much more manageable levels.

Robert presents the findings of his research, and what he has discovered about persuasion, distilled into the form of six principles . What makes this particularly interesting is the active way he did the research.  He studied the results of experiments, performed his own studies, and worked hard to understand the results (which he presented well).  Also Robert tells of his excitement in trying to analyse situations in which someone persuaded him to do something, and his adventures in trying to understand some of the persuasive people out there.  The wide range of examples in the book includes:

• Boy scouts selling chocolates
• How the Krishna work
• Used car salespeople
• Celebrity endorsements
• Limited time specials
• Some very interesting scientific studies

If nothing else reading through each of the examples of the persuasion and the discussion of what happened was brilliant.  My perspective of free gifts has completely changed. I'd argue that there is much more value in the book.  Getting an idea of why people say yes, and some of the principles behind this is very valuable. The principles are:

• Reciprocation
• Commitment and Consistency
• Social Proof
• Liking
• Authority
• Scarcity

The following provide a very brief note of each area. They are not complete, instead opening up some of the things that most impressed me, and that are worth noting.  Read the book if you want to get the real sense of what's being talked about.  (Failing reading the book you can visit the website).

Reciprocation

After someone does something nice we are likely to reciprocate and do something nice for them. What we do in return may be much greater in value.  Also if we say no to what feels like a big request, we are likely to reciprocate by saying yes to a smaller request.

In sales. Try and start big. Then be nice and sell smaller.

Commitment and Consistency

Once we have made a commitment to something we are likely to act in a way that is consistent with that action.

If we say that we start doing something small we are likely to continue.  This provides an interesting trade-off between this principle and reciprocation.  The way I would reconcile things is the start with a big request, then graciously let someone turn it down and go with a small request in the initial meeting.  The later use the principle of consistency to continue with additional requests.

Social proof

We will often look to others when deciding how to act in a situation. This mostly works well, but can be the cause of problems in situations like if someone has had an accident in a crowd.  People in the crowd will look to how others respond, which can lead to inactivity.

Liking

We will often behave differently if we like someone, or if they like us.  The best example of using this principle comes from Tupperware.  Women will often buy Tupperware when at a party to help their friends, even when they only went to the party because of the friendship.  Blokes aren't immune to this either.

Authority

We treat authority figures differently.  Even young college students (who we expect to have a healthy disrespect for authority) treat authority figures differently.  What is particulary interesting is that experimental results show that we have a poor self perception of how much we do value authority.

Scarcity

A cookie tastes better if there aren't many, and even better again if the limited supply is caused by lots of other people wanting it.  Tech manufactures use this principles.  There is an art form to ensuring that you run out of stock on release day.

Being aware of these principles is a valuable skill to have. We all are in situations where we need to communicate important information.  Being able to persuade people is important. We are all in situations where others are trying to persuade us.  Robert does a good job in helping us think through strategies of how to avoid being manipulated. 

Go Read the book and learn about persuasion, and use your powers for good.

Subtitle: 

Avoid Remembering that VMWare Server Listens on Port 8333 

Alternate subtitle:

Make Tomcat Listen on Port 80

It's increasingly common for applications to have web front ends.  These all tend to run on their own port, which is nice in that it stops services from running into each other (and means that they can run as non-root), but is somewhat painful in that there are always a whole heap of different ports to remember.  Exposing a service over port 80 makes it much easier to use (especially on ie which is dumb, and doesn't know to make requests to non standard ports default to port 80, generating much rsi, and many hours logged into the IE Waste Recorder).  Making services listen on port 80 on Debian is pretty straight forward.  Follow the process below (which I pinched from someone somewhere in the blogosphere a while ago, put on a server as a part of some work with SSH Tunnelling, and only remembered recently when we were getting some VMWare servers setup). So here is the script. In your /etc/network/if-up.d add a script with the following:

#!/bin/sh

PATH=/sbin:/bin:/usr/sbin:/usr/bin

# Flush any existing firewall rules we might have
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X

# Perform the rewriting magic.
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to 8222
iptables -t nat -A OUTPUT -o lo -p tcp --dport 80 -j REDIRECT --to-port 8222

This forwards requests from port 80 to port 8222, and will work for local and remote requests.  I keep this in a script called /etc/network/if-up.d/firewall, because iptables is firewallish, and I believe this is the standard place for this to live.  Remember to chmod +x the script. 8222 is the http port for vmware, and will redirect to 8333 using https. By putting the script in the /etc/network/if-up.d it will automatically be run when the networking layer of your debian installation is brought up.

As per the NewInstance post, this will work for Tomcat as well (Luigi put the iptables rules in a different spot, but that was in 2005, and /etc/network/if-up.d is the right place for this).

So with the above iptables rules, it will be easy to make any service available on port 80.

gem update –system

I only found this when looking through google, and I got a series of pages warning to be careful when using gem update –system as it can kill existing gems (http://puctuatedproductivity.com/2007/11/01/unistalling-ruby-installed-by-source-on-os-x, http://thenoobonrails.blogspot.com/2008/06/doing-gem-update-system-might-lose-all.html) so I was a bit nervous.  Since I have a periodic use of ruby and I'm lazy enough to make Larry Wall proud, I figured I'd take a punt on just using gem update –system.  Turns out it just works, and I've kept all my old gems.  Hooray.  Given that the posts talking about issues are old, I'm either assuming that they've done things differently to me, or things have been fixed since then… so… if you need to update gems due to a message:

ERROR: Error installing sinatra:
fastthread requires RubyGems version >= 1.2

or similar, just use gem update –system

json.org lists 18 different Java libraries for working with JSON (Flexjson gets a double mention). These provide varying levels of functionality, from the simplest (the default org.json packages), to more comprehensive solutions like XStream and Jackson. Join me on a quick review of some of these, focusing on those which have friendly licenses, and meet my requirements.  If you are lazy, you can fast forward to my summary

My Requirements

1. Serialises and Deserialises JSON
2. Lightweight and Simple
3. runs on Java 1.4
4. Friendly license

The contendors

1. org.json
2. Jackson
3. XStream
4. JsonMarshaller
5. JSON.simple

Serialises and Deserialises JSON

This might sound like an obvious requirement, but I’ve seen at least one library which was completely focused on spitting out JSON, without any support for reading JSON. I’m actually using this as a pre-requisite for inclusion in my comparison. If a library can’t read AND write JSON, I’m not going to consider it.

Lightweight

I’ll begin by stating that my actual usecase is to operate within a plugin for EditLive!. I don’t need a all singing all dancing JSON serialisation/deserialisation library. There are some very cool libraries out there that do awesome stuff, but all I need to do is read and write JSON data.

Coupled with this is that I’ll want to be able to keep the memory footprint pretty low, so want to work with Java Streams without needing to necessarily pull in the whole serialised object if I don’t need it.

Runs on Java 1.4

Yep it’s still out there. Thankfully Java 1.4.2 has reached it’s EOL, but businesses can still request patches, and there are most definitely still Ephox clients running on this JRE, even though more recent JRE’s work so much better. (side note: If you have the option of upgrading your JRE to Java 6, please do it, the children in Africa will be much happier. Everytime someone runs up a 1.4 JRE a puppy dies). 1.4 is in it’s final death throws, but it is still kicking.

Friendly License

For Ephox to make money from the product/component that uses JSON (gotta think about the $$$ at the end of the day), I’ll need to make sure that the license is non-viral and Enterprise friendly. Apache license good. GPL bad. (sorry FSF)

Assessment 

So having run through the requirements, we can now consider the options. For each library, I’ll provide a simple table.

The metrics I’m using to judge the libraries are included in the table. The most crude metric that I’ve got is the number of classes. I’m more than happy to admit that this is a very crude way to measure how lightweight the library is, but it does provide an ok rough heuristic, particularly given that there are order of magnitude differences.

org.json

The granddady of them all. This comes pretty close to being a reference implementation. It provides a nice simple API (7 classes), doesn’t try and do any magic, and just makes sense. I’ve used it before when working with small amounts of data. Unfortunately it doesn’t provide any streaming goodness.

Jackson

Jackson advertises itself as a fast powerful conformant JSON processor. It provides heaps of features, and looks to be a good tool for reading and writing JSON in a variety of ways (see the Jackson tutorial for more). The drawback of Jackson for my purposes is that it isn’t exactly svette at 250 classes.

XStream

XStream gets a mention because it’s cool :). I haven’t really considered it because it provides more of a direct object serialisation format, which wasn't quite what I'm looking for. Also, it’s heritage as an xml serialisation format shows, and it likes Java 5 much better. The ability to directly go between Javabeans and JSON java classes is cool, but I don't need this magic or the 200+ classes that come with it.

Json Marshaller

Json Marshaller sells itself (it almost sounds like a bolierplate project description by now) as “Fast, Lightweight, Easy to Use and Type Safe JSON marshalling library for Java”. It’s been under consistent active development for a number of years, and looks to be headed in the right direction. Unfortunately the current version has 3 deal stopping flaws for my environment at the moment.

1. It requires Java 5
2. It has a dependancy on ASM (the developers are looking to remove his dependancy)
3. While it hasn’t quite piled on the bulk of XStream or Jackson, it still has a couple to many classes for me to consider

These constraints make it not quite fit for my purposes, but like all decisions, it depends on your own situation.

JSON.simple

JSON.simple advertises itself as “a simple Java toolkit for JSON”. It provides reading and writing to JSON streams. It’s lightweight and focused on generating JSON from Java code. The critical feature it provides is support for Java IO readers and writers.

Summary 

For the interested, here’s a table that summarises my findings.

Conclusion

If you are looking for a simple lightweight Java library that reads and writes JSON, and supports Streams, JSON.simple is probably a good match. It does what it says on the box in 12 classes, and works on legacy (1.4) JREs.

1. Native Object Serialisation
2. Custom format
3. XML – Extensible Markup Language
4. YAML – YAML Ain’t a Markup Language (obviously created by geeks with the recursive name)
5. JSON – JavaScript Object Notation

Join me in having a look at these formats, and I’ll let you know some of the issues to consider. The main problem I’m solving is for data that belongs to your own application. I’m not considering databases or interoperability.

Native Object Serialisation

Consider this briefly before running away. I’m particularly familiar with the idea of Java Object serialisation. I’ve used Prevayler in the past storing java objects, and xml (So while I’m having a dig at Java Object serialisation in general, I’m not specifically having a go at prevayler).

While the use of native object serialisation is often easy, it has costs, making the content unreadable by humans, coupling the data storage to your implementation language, and can create object migration issues. These costs will typically outweigh the benefits. Having human readable data to aid debugging would provide reason for not using native object serialisation if there was nothing else.

Custom Format

The use of a custom simple text format should not be discarded out of hand. The lack of any third party dependancies is a useful feature, and should be considered. That said, if you have a library that does the parsing for you, that should not be sneezed at.

XML

As wikipedia says, “XML is a general-purpose specification for creating custom mark-up languages” (Wikipedia on XML). Parsers and tools exist for many platforms and environments, which makes it a useful tool when you want to share information between different environments. While a good tool, the syntax is verbose, and can be hard for humans to read.

XML has influenced the birth of two of two more recent notations which are useful for data storage: YAML, and JSON

YAML

YAML purports to be “a human friendly data serialization standard for all programming languages” (Yaml.org). It has a well defined specification (YAML Spec), and makes for an easy to understand data storage format. Implementations of YAML exist for a wide range of languages, including Java, C++, Ruby and Javascript. It’s been around for a while, and has a decent amount of uptake. If it wasn’t for JSON, it would probably be a good default choice.

JSON

At first glance JSON seems much less suitable than YAML for languages other than JavaScript. The kicker against it is that it has “JavaScript” in the name, which has always made people feel icky. That said, it does make for a good cross platform format, it is human readable, and is implemented on a wide range of platforms (Json.org).

JSON has also has the advantages of having mindshare, and is slightly more familiar to developers than YAML. Every developer who has had anything to do with the web has done stuff with JavaScript, so the basic format will be familiar to them. Also in JSON’s favour is the fact that JSON and YAML are syntactically very close (see Redhanded). JSON appears to be very close to a subset of YAML(Ajaxian). In addition, the general applicability of JSON is higher, particularly for people who are going to be doing Javascript development. Also, if you have any possibility of playing with JavaScript, JSON is a very good option because of the native support in JavaScript.

These factors combine to make JSON an excellent choice.

Summary

Tim Bray makes a good case for this being an automatic choice based on your circumstances(http://www.tbray.org/ongoing/When/200x/2006/12/21/JSON ). You’ll still need to think about the pros and cons of the different technologies for your situation (see http://webignition.net/articles/xml-vs-yaml-vs-json-a-study-to-find-answers/), but you’ll often find that JSON is a good format to use for data storage.