Inaugural Meeting of the Greater Philadelphia AWS User Group

We are pleased to announce the formation of the Greater Philadelphia Amazon Web Services User Group (GPAWSUG).    This user group is intended to be a collaborative community of AWS end-users sharing knowledge and real-world experience.  All are welcome, including, but not limited to devOps professionals, developers, DBA’s, big data wranglers, and IT executives.   The organizers will schedule bi-monthly presentations of interest to both AWS novices, and experts. Presentations both critical of, and favorable to, AWS products are welcome.

The group’s online home is found on Meetup.com.  Members will be given early access to event seating for future events, and can participate in the group’s online discussion forums and (at their option) mailing lists.  The group’s charter explains the grass-roots philosophy that guides the selection of presentation topics and the rules of engagement.  To summarize:  this is a private members-only group, the membership list is not to be used for marketing, and no product vendor presentations are allowed (excepting, on a limited basis, Amazon itself, as with the inaugural meeting).

Join the Group

Inaugural Meeting

The inaugural meeting of the group will be held on Thursday, September 19, 2013 from 5:45 PM to around 7:30 PM (EST) at Villanova University.  Sanjay Kotechas from Amazon Web Services will discuss how to integrate AWS’ data warehousing product, Redshift, into your solutions.

Light dinner fare (a sandwich bar) will be served.

You need not join the Meetup.com group to attend the meeting, but you must RSVP using EventBrite.

Register via EventBrite

Abstract

Amazon Redshift is a fast and powerful, fully managed, petabyte-scale data warehouse service in the cloud. With a few clicks in the AWS Management Console, customers can launch a Redshift cluster, starting with a few hundred gigabytes and scaling to a petabyte or more, for under $1,000 per terabyte per year. Continue Reading…

Clojure Closures In Java

As part of a team conversation this morning, I worked up a quick Java translation of some more-interesting-than-it-looks Clojure code. It’s a good example of how lexical closures map to objects.

The code we started out with was this:

(defn make-adder [x]
  (let [y x]
    (fn [z] (+ y z))))

(def add2 (make-adder 2))

(add2 4)

What this code does is define and return a new type of function that adds values to the constant x. In Java, it looks like this: Continue Reading…

Nicely Formatted Tabular Output in Java

Occasionally, it’s useful to be able to print nicely formatted tables of data to a textual output stream. This is particularly the case when writing command line tools. To make the output of these tools more readable, any tables they write should have columns that line-up from row to row. The Unix tool ‘ls’ does this when it prints out long form directory listings. In this example, notice how the dates line up, even though the file size column varies in width.

drwxr-xr-x+ 1 mschaef Domain Users        0 Oct  3 09:20 docs
-rwxr-xr-x  1 mschaef Domain Users 29109013 Oct 10 13:38 file.zip
-rwxr-xr-x  1 mschaef Domain Users    77500 Oct 10 13:17 file2.zip

Continue Reading…

Announcing the Open Source Ernie Report Generator

ernie-small

KSM Technology Partners is pleased to announce the alpha release of Ernie, an open source asynchronous report generator based on the Eclipse BIRT framework.  You can find it on GitHub at https://github.com/ksmpartners/ernie.  There is also an Ernie support forum on Google Groups for the community to ask questions and offer feedback.

For developers, Ernie provides both Scala and Java APIs for:

  • building and maintaining a catalog of reusable BIRT report definitions;
  • running parameterized reports asynchronously to create jobs;
  • interrogating the status of enqueued jobs; and
  • accessing report results in PDF, CSV, or HTML format.

For integrators, Ernie provides a JEE .war implementation that can be deployed standalone, and controlled via a RESTful API. Continue Reading…

Why is Traditional Java I/O Uninterruptable?

One of the best things about writing code in the Java ecosystem is that so much of the underlying platform is open source. This makes it easy to get good answers to questions about how the platform actually works. To illustrate, I’ll walk through the JVM code to show why Java I/O isn’t interruptable. This will explain why threads performing Java I/O can’t be interrupted.

The core issue with interrupting a Java thread performing I/O is that the underlying system call is uninterruptable. Let’s see why that is, for a FileInputStream. Continue Reading…

Custom EHCache Sizing Engines

One of the ways that EHCache can be configured is to put a bound on the maximum amount of memory a cache can consume. To do this, EHCache needs to be able to compute the size of the cache, which implies that it can compute the size of object graphs contained within the cache. The usual way it does this is to traverse the object graph of each key/value pair in the cache, estimate the size of each component object within the graph, and then add them all up to get a total for the key/value pair.  By doing this for each cached key/value pair, EHCache can estimate the overall memory footprint of a cache and enforce a memory bound by evicting objects, if necessary. Continue Reading…

SQLDeveloper Canned Queries and Templates

Recently, I’ve been trying to give my best effort at using SQL Developer as an Oracle IDE. I really have. And, for the most part, I’ve been somewhat successful. But, as a lifelong (since 2001) TOAD user, there are a few things that I can’t live without. This article is about one of them: canned queries. And, as a bonus, the solution I’m going to outline provides something TOAD never did well: canned templates with variables.

Continue Reading…

Thread Local State and its Interaction with Thread Pools

I recently blogged about solving problems with thread local storage. In that instance, thread local storage was a way to add a form of ‘after the fact’ synchronization to an interface that was initially designed to be called from a single thread.  Thread local storage is useful for this purpose, because it allows each thread to easily isolate the data it manipulates from other threads. Unfortunately, while this is the strength of Thread Local storage, it is also the weakness. In modern multi-threaded designs, threading issues are often abstracted behind thread pools and work queues. With these abstractions at work, the threads themselves become an implementation detail, and thread local variables are too low level to serve some useful scenarios.

One way to address this issue is to use some of the techniques from an earlier post on dynamic extent. The general gist of the idea is to provide Runnable‘s with way of reconstructing relevant thread local state at they time they are invoked on a pool thread. This maps well to the idea of ‘dynamic extent’, as presented in the earlier post. ‘Establishing the precondition’ is initializing the thread locals for the run, and ‘Establishing the post condition’ is restoring their original values. Here’s how it might look in code: Continue Reading…

Dynamic Extent in Java

In my work, I tend to borrow heavily from the Lisp tradition, even when writing in Java. One of my go to techniques from the ‘Lisp world’ is using Runnable‘s in API’s to explicitly enforce dynamic extent. Without getting too heavily into the Lisp-specific terminology, dynamic extent is what you need to write code for the following kinds of scenarios:

  • ‘Ensure that an opened file is closed, after it’s been used’
  • ‘Ensure that this lock is released at the end of this critical section’.

These scenarios are common enough that Java provides explicit support for dynamic extent with the try...finally and synchronized(...) { ...} statements. However, both of these have to be explicitly written by the caller of an API, at each call site. There’s no way for a file API to use these constructs to automatically enforce that all opened files are eventually closed. The API is limited to providing open and closed and trusting that the caller will use try...finally. The technique I’m about to describe makes it possible to write an an API that removes that burden from the caller.

Continue Reading…

Threads, Line-Synchronization, and OutputStream: ThreadLocals and Java I/O

The other day, our team ran across an interesting design problem related to Java synchronization. Without getting into the details of why this problem came up, the gist of it was that we had to somehow to write a synchronization wrapper around OutputStream. (Well, technically, it was a BufferedWriter…but the issue is the same.) This wrapper needed to correctly allows multiple unsynchronized writer threads to write to an underlying writer, each thread atomically writing lines of text. We wound up managing to avoid having to do this by changing our interface, but the solution to the OutputStream problem still provides an interesting look at a lesser-known aspect of the Java Runtime: ThreadLocal variables.

Continue Reading…

Page 4 of 5«12345»