Site Sponsors:
HTTP Forma As-a Service Transfer (F.A.S.T) 
When creating a new web presence, as a set of architectural guidelines using JSON and REST is a good way to go.

However, sometimes we need to manage data on the Internet in such a way as to automate existing HTTP Forms.

Historical


Such was the case when I created "The Wiki Recipe Club." Like you, I am often working as "an army of one." When time and costs are so limited, we need to transfer data as quickly & efficiently as possible. -In my case, I simply wanted to pump 180,000+ recipes into an Open Source WIKI using HTTP Forms.



Because classic web forms only need a GET or a POST, I created EasyHTTP.

Followers of this blog might recall that EasyHTTP is the reference implementation of our "Business / Enterprise State Transfer" (B.E.S.T) architectural guideline. Curiously however, a few years back that framework - along with over 13 of my other projects - mysteriously disappeared from Sourceforge.

New Moniker for Old Services


While restoring the content of EasyHTTP to Sourceforge today, I realized - in today's Web 2+ world - that the classic HTTP way of creating, reading, updating, or deleting data from our web sites should have it's own "service oriented" moniker.

Indeed, in as much as forms-encoded data smells allot like JSON, that Web 1.0 way of moving data back-and-forth between those classic, HTTP-centric, web-based set of maintenance operations could also be referred to as "Forms As-a Service Transfer," or F.A.S.T.

Enjoy the journey!


-Rn

[ add comment ] ( 3 views )   |  permalink  |  related link
Pay-As-You-Go -v- Global Initialization 
While easy to understand in Java, the opportunity to initialize data & classes prior to their use is a well known technique.

Here is a Java:


static ColorPair[] colors = null;

static {
List<ColorPair> array = new ArrayList<ColorPair>();
Color[] ccc = {
Color.BLACK,
Color.BLUE,
Color.CYAN,
Color.DARK_GRAY,
Color.GRAY,
Color.GREEN,
Color.LIGHT_GRAY,
Color.MAGENTA,
Color.ORANGE,
Color.PINK,
Color.RED,
Color.WHITE,
Color.YELLOW
};
for (Color a : ccc) {
for (Color b : ccc) {
if (a == b) {
continue;
}
array.add(new ColorPair(a, b));
}
}
colors = new ColorPair[array.size()];
array.toArray(colors);
}


Indeed, when we are guaranteed to use static content, then taking the time to pre-initialize objects is a common practice. Why would anyone want to do anything else?

Yet when calculating the total latency in pre-execution load times, on more than one occasion I have been found re-factoring static initializers so as to allow programs to be more responsive.

Pay As-You Go


Given that the above example has been defined as package-protected, surely it can be declared private.


private static ColorPair[] colors = null;


After so hiding the data structure, the very next thing to do might be to expose the structure with a more visible member function.


public static ColorPair[] GetDefaultColors() {
return colors;
}


Once so exposed, a far less costly initialization strategy can be created. -Specifically, rather than requiring colors to be pre-initialized, we can now pay-as-we-go by only allowing the initialization loop to run when the data are needed:


private static void init() {
List<ColorPair> array = new ArrayList<ColorPair>();
Color[] ccc = {
Color.BLACK,
Color.BLUE,
Color.CYAN,
Color.DARK_GRAY,
Color.GRAY,
Color.GREEN,
Color.LIGHT_GRAY,
Color.MAGENTA,
Color.ORANGE,
Color.PINK,
Color.RED,
Color.WHITE,
Color.YELLOW
};
for (Color a : ccc) {
for (Color b : ccc) {
if (a == b) {
continue;
}
array.add(new ColorPair(a, b));
}
}
colors = new ColorPair[array.size()];
array.toArray(colors);
}


Note in the above that the initialization still takes place as before, but not every time our program is loaded. Rather, we can "pay as we go" by allowing the structure to be initialized only if, as well as when, the data are required:


public static ColorPair[] GetDefaultColors() {
if(colors == null)
init();
return colors;
}


Conclusion


Whenever I find myself migrating a bit of code from a project into a support library the first thing I look for is an opportunity to convert any global / static initializers into a pay-as-you-go strategy. Of course, given that one of the first principles of good Object Oriented Design is Encapsulation, from a puritanical point of view many often find very little justification for doing anything else.

Enjoy the Journey!

-- Rn

[ add comment ] ( 15 views )   |  permalink

| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | Next> Last>>