1. Dave Lange

Dave Lange har bl a skrivit följande inlägg på jsolutions.se.

  1. Overview of the Google App Engine Persistence framework

    The Google cloud computing environment, Google App Engine, currently provides a low cost (free) highly scalable runtime environment (python) for web applications. Along with App Engine specific APIs and support for their general service APIs, you have access to a distributed, scalable persistence engine, Datastore. A quick review of App Engine Datastore sets firm your impression that Google has again relied on the ”we build it better” framework approach. Not following a relational model or a webservice, Datastore started with goals of high availability, scalablity and performance. Because of quota limits on current free accounts, its hard to validate their success here; however, we can get a better understanding of the architecture of Datastore by checking out their internal ”Bigtable” implementation, which is the basis for Datastore.
    (Läs mer…)

  2. developers roasting on an open fire..

    Over the last few months there have been some interesting blog entries concerning the scalability of a popular social net site (twitter). What was most interesting to me wasn’t the technical issues (yes solving performance problems is always a good read..) but how the issues were expressed
    publically. Twitter, like many 2.0 apps, provides greater insight into their inner-workings through employee blogs. With business models such as software as (Läs mer…)

  3. lost in space

    I was thinking of getting my oldest kid a small telescope- a little father/daughter time wondering about the universe etc etc… but it was easer to download Google Earth 4.2 featuring ”Sky”. yes we lose the fun of strange insects and clouds, but we get quite a view! Sky makes use of the typical Google Earth controls, allowing you to pan and zoom your way through the heavens. Unlike the toy store scope I would have ended up with, Sky arms you with the resolving power of the Hubble telescope, mapping hundreds of millions of objects in space. Like Earth, Sky is user-powered: a community of professional astronomers are adding content for fun, education and real research.
    Check it out now at http://earth.google.com/sky/skyedu.html. There. post complete without any cheezy space humor.

  4. Single out that state

    The Singleton pattern has been around for quite some time, providing an instrument to limit a single instance of a class. This is great use for classes which are designed solely with this in mind. Of course it has also been an anti-pattern for just as long, either as a crutch for global state or relaxed scoping. This can lead to problems with maintainability and testability. Coupling a client class to a singleton concrete instance is a problem with extending or subclassing the singleton; additionally, mock testing of a class using a singleton forces you to also test the singleton’s behaviour. Sometimes a ‘lazy’ design relying on global state can be turned on its head to better facilitate encapsulation / polymorphism.

    So why not call out all those singletons and see if they can stand on their own merit?

    Enter the Google Singleton Detector http://code.google.com/p/google-singleton-detector

    The Google Singleton Detector identifies global state within a java application. Along with the ”classic” singleton, they have coined terms for other forms of state as well:
    The Hingleton (helper singleton) which basically makes a class a singleton by ensuring that there is only one instance of it
    The Mingleton (method singleton) is a class with a static parameter-less method which returns some state (non-primitive object). More informative then useful.
    The Fingleton (field singleton) is a class with one or more public static fields. Again, informative given the dependency graphing provided by the tool

    The GSD examines jar/classes and produces a graphML file showing the above -ingletons and all dependent classes. The tool describes how you can quickly view the graph using the yEd graph viewer (http://www.yworks.com/en/products_yed_about.htm)

    There are some limitations with the current version- singletons created using a static final field and a static initializer are ignored (to avoid false positives with other static usages of final). Inner-class singletons are also missed. A practical limitation is the inability to evaluate either a jar or classes in a directory. Multiple jars must be unpacked in this version.

    I tried it out on the hibernate jar (hibernate3.jar):

    1. download gsd-0.7.3 which basically is the gsd.jar
    2. run using a java5 jvm: java -jar gsd.jar hibernate3.jar hibernate3.graphml
    3. download yEd from www.yworks.com- there are several install options, including just a jar file.
    4. run yEd, open hibernate3.graphml. This default layout was a mess of stacked lines and boxes…
    5. re-size text to nodes (Tools-> Fit Node to Label, use default properties)
    6. choose better layout (Layout -> Organic -> Smart, use default properties)

    Below is a portion of the graph. Quite a lot of yellow and green boxes, which are identified as ‘mingletons’ and ‘fingletons’ respectively. The blue ovals are classes dependent on -ingletons. Such a graph on your codebase is helpful in visualizing the organization and use of Fingletons, at least as a maintenance exercise.
    graph.jpg

     

     

  5. all your base are belong to us

    The spreadsheet has been the tool of choice for my wife’s small business; pretty much wysiwyg with no real hidden data models or business processes or odd UIs. Just type in the data.

    ahh but the problems with these spreadsheets- multiple machines, not backed up, office vs. openoffice… had them all.

    well, since her business already uses some Google services (gmail, calendar), why not Google Docs & Spreadsheets? Yes this solves issues with backups and multiple copies. What about availability? For her, being online is not a problem (and the Google servers have better uptime then her laptop). As for functionality, the simple equations in her worksheets work as expected.
    But this is all pretty boring for me, until you add in the nice set of APIs available to Google Apps (Google Spreadsheets, Calendar, Gmail, etc.). Now look what your code can do with all that manual entering of information:

    Read entries from a spreadsheet as Atom/RSS feeds for product catalog and pricing info. Sure this is easily Spring configured or in a database, but my wife updates this: putty/linux/SQL or typing in a spreadsheet?

    Placing order information into ”template” worksheets for generating packing lists, invoices, late payment reminders.

    Creating calendar events for invoicing, payment and other CRM issues

    Querying on these events to trigger other business (PDF generation and email is easy manually with Docs & Spreadsheets, not sure if API for this is available).

    Most of these APIs utilize the REST influenced GData API to GET / POST / PUT / DELETE information either publicly or securely via the Google Account Authentication.

    There are client libs for java/net/php etc and even JSON for you script kiddies. So try some programmatic access to your blogger data, local maps or youTube videos… but remember, its free and probably beta !

  6. Be True

    You can see it in their dull glaze- developers facing the details of a complicated web interface. Breadcrumbs. Form redirects. Sort columns. Synchronizing back/forward button. Uploads. 10 ways to do ”basically the same thing”. Bookmarks. i18n… and then there is the application to code, they mumble.
    There are many good reasons and rationale one should abide by when deciding on a presentation technology for a web application. Or at least I am sure there are. I just picked Spring MVC for a little e-shop I did for my wife because I wanted to play with it. Fortunately for her it all turned out well, and I can fill in the back-story.

    A rule of thumb I like to follow is to try to stay true to the core business and core technology. Just as a UI designer describes interactions which best fit the type of application being built, a software architect/designer could pick technologies which align well with the application platform. If I am developing an HTTP based web application then I may pick a presentation tier technology that fits well with the HTTP request / response paradigm. I have found that technologies which disguise their core implementation or try to generalize themselves into a broader classification tend to irritate me with limitations down the road.

    Back to Spring MVC.. The name betrays its rather clean implementation of servlet based request dispatch. You can choose from several different types of ”controllers”, from basic Get functionality to one supporting a more complex multi-page form post (wizard). The Model and View aspects of a web MVC pattern are abstracted out a bit more in Spring MVC, with POJIs and technology specific implementations. The Controller is the key here and Spring MVC gives you enough rope..

    Controller: ”We have a special guest, I will show them something fancy.”
    Model: ”You are always trying to get involved in my business. Its me they really want to see.”

    I liked how Spring MVC helps deal with the presentation issues I mentioned at the start- it seems to stay true to the technology, not trying to extend out into new territories (that would be Spring WebFlow).

    Spring MVC is covered nicely on the Springframework site, but there was not much describing it’s integration with Struts Tiles. So a few little details which may help someone. Three steps will get you there:

    1) Include your dependencies
        *     Struts version 1.1 or higher
        *     Commons BeanUtils
        *     Commons Digester
        *     Commons Lang
        *     Commons Logging

    2) Point to your Tiles config files through the Spring configuration of a TilesConfigurer. This includes a property for the factoryClass used (standard Tiles org.apache.struts.tiles.xmlDefinition.I18nFactorySet default).

    3) Select a ViewResolver which can recognize the Tiles configuration. Configure the InternalResourceViewResolver with the supplied Spring view class TilesView. This will resolve the String name from a controller into a matching Tiles definition name found in your Tiles config file.

    If you need your controller to redirect or forward to another controller and not a view, Spring MVC lets you put the keywords ”redirect:” or ”forward:” in front of the view name. If you inject the view names into the controllers, you gain some reuse with your controllers, leaving the flow of the application (either to a tiles view or another controller) specified clearly in the MVC application context configuration file.