Showing posts with label resources. Show all posts
Showing posts with label resources. Show all posts

Friday, November 11, 2011

MJSON 1.1 Released

NOTE: The Library described here has grown and moved to Github with official website http://bolerio.github.io/mjson/It still remains faithful to the original goal, it's still a single Java source file, but the API has been polished and support for JSON Schema validation was included. And documentation is much more extensive.

I few months, we made an official release of a compact, minimal, concise JSON library that we called MJSON. See the JSON Library blog post for an introduction to this library. After some experience with it, some bug reports on that blog post, we have released an improved, fully backward compatible version 1.1. The original download & documentation links now point to the new version.
Pointers

Documentation: http://www.sharegov.org/mjson/doc
Download: http://www.sharegov.org/mjson/mjson.jar
Source code: http://www.sharegov.org/mjson/Json.java
Maven
The latest 1.1 release is available on Maven central:
<dependency>
    <groupId>org.sharegov</groupId>
    <artifactId>mjson</artifactId>
    <version>1.1</version>
</dependency>
Also, both 1.0 and 1.1 versions are available from our Maven repository at http://repo.sharegov.org/mvn. This is depracated and henforth we'll be publishing only on Maven central. Incude that repository in your POM or in a settings.xml profile like so:
<repositories>
  <repository>
  <releases>
  <enabled>true</enabled>
  </releases>
  <snapshots>
  <enabled>true</enabled>
  </snapshots>
  <id>sharegov</id>
  <url>http://repo.sharegov.org/mvn</url>
  </repository>
  </repositories>
Then include a dependency like so:
<dependency>
  <groupId>mjson</groupId>
  <artifactId>mjson</artifactId>
  <version>1.1</version>
  <scope>compile</scope>
</dependency>
List of Improvements

The following bugs were fixed in this new release:
  • The example from the Javadocs was missing a final 'up()' call.
  • The NumberJson implementation appropriately return true in its isNumber method now.
  • A parsing bug.
  • Some warnings were removed and explicitly disabled.
The following additional features were implemented:
  • Addition of  top-level methods: is(String, Object) for objects and is(int, Object) for arrays. Those methods return true if the given named property (or indexed element) is equal to the passed in Object as the second parameter. They return false if an object doesn't have the specified property or an index array is out of bounds. For example is(name, value) is equivalent to 'has(name) && at(name).equals(make(value))'.
  • Addition of a dup() method that will clone a given Json entity. This method will create a new object even for the immutable primitive Json types. Objects and arrays are cloned (i.e. duplicated) recursively.
  • Addition of a Factory interface that allows plugging of your own implementation of Json entities (both primitives and aggregates) as well as customized mapping of Java objects to Json. More on this below.
The Factory Interface - Customizing MJSON

The Factory interface, declared as an inner interface, within the scope of the Json class, looks like this:
public static interface Factory
{
Json nil();
Json bool(boolean value);
Json string(String value);
Json number(Number value);
Json object();
Json array();
Json make(Object anything);
}

You can implement this interface if you need to customize how the Json types are actually represented. For instance, objects are represented using standard Java HashMap. But you may want to has a different representation, say a LinkedHashMap or a more efficient variant, optimizing for strings (say, a Trie based map of some sorts). Or you may want strings to be case-insensitive in which case you'd have a Json derived class representing strings, but whose equals method will actually do equalsIgnoreCase etc. 

The make allows you to customize how arbitrary Java objects are translated into Json. It should be easy for example to implement a make method that handles Java beans with introspection, which is something that we don't want by default as part of the API.

The methods in that interface are used internally every time a new Json instance has to be constructed, either from a known type, as a default empty structure or from an arbitrary Java type. Thus you can pretty much customize the representation any way you like while relying on the same simple API.

The default implementation of this factory is public: Json.DefaultFactory. Therefore you can extend that default implementation and only customize certain aspects of the Json representation. 

That's it for this release. Enjoy!

Cheers,
Boris

Thursday, January 20, 2011

A no-risk proposition

Open source used to evoke the scrunching of executive eyebrows and a patronizing -"it's still young and risky" comment. Things have surely changed, and the open source "movement" has proven its maturity and is fulfilling its potential.

So why are gov't executives still rolling their eyes and tensing up at the mere mention of "open source." Government is in so many cases the proverbial "late adopter". Well, better late than never. The government development and open source fit is a natural one. The transparency promise (a promise of virtually every government administration) presupposes that software developed in government IT shops is a community resource ... like any other government asset - it is public property.

This is the bottom line of what we are trying to achieve here, with our Sharegov initiative - to align the themes firmly embedded in the philosophy of public service (openness, low cost to the public, objectivity, public participation), with our software development practice. Much overdue. And substantially less risky than permanently committing to some expensive software product only because a charming sales engineer from a big company swept us off our feet during a powerpoint presentation.

We dare to suggest a little formula that will help government developers start sharing more and form a dynamic, energetic community: a little bit of extra, focused effort a couple of times a week! Just like exercise - start with regularity, and maintain discipline - working out will pay off in overall health, stamina, nimbleness... in our case, for our government organizations, for our e-government applications and projects We realize no one will give us the extra time and money to dedicate to kick-off a gov't app development "co-op", so we will give our own time and effort to get things going. We encourage you to do so too - by commenting on our blogs, taking a look at the applications we're making available, by sharing your issues, projects and your own applications. Please don't let inertia and organizational fatigue take over. We're fighting it every day ourselves.

Thursday, September 2, 2010

Gov Developers v. Industry Developers



What do our private counterparts in the commercial world have as an advantage that we in government agencies don't? Flexibility, brains, money?

One of the reasons why open source development is so successful, is that self-employed developers or those that work for private, for-profit, organizations, tend to be more prone to sharing, especially if that minimizes the amount of work or maintenance they must perform. Having to deal with steep deadlines, market pressures and competition, perhaps, makes freelance and industry developers more resourceful in adopting and co-opting solutions.


On the other "side" - government is notorious for being slow, and immune to competitive forces, so a common reflex is to be distrusting of community-driven development... our knee-jerk reflex is either to build from scratch ourselves, or to buy something big, ready-made and expensive. What does this result in, in the end - the relative professional isolation of the government software developer.


Gov developers tend to mix less with their peers, their employing organization typically does not force them regularly to refresh their skills. On the contrary, most of the time the government worker needs to beg for training and participation and professional forums, and justify the expense, due to the lack of training and travel budgets. Or, training and learning is usually "silo-"ed -- provided by the companies that the government purchases software from - big names, we all know, that dominate the market, and that naturally favor their own solutions and their methods of development/integration/implementation.

Everyone knows, exposure to diversity contributes greatly to learning and boosts one’s skills. Are open-source technology communities the cure to the gov developer blues, sentenced to isolation and inertia by the bureaucratic environment in which she works?