Search

Co de Ha rm on ics

mastering the routine play

The iWalk Framework

Overview

In this documentation, we trace the multiple layers of the iWalk code, to demonstrate how data from the Crawl database gets to the iSee and iKnow web applications. The other direction – such as saving data entered by the Crawl user – is not discussed, though it follows the same layered process in reverse.

There are at least seven layers between the data in the Crawl database and the information that appears in iSee and iKnow. Seven is the lucky number, but there are in fact many ways to enumerate the quantity of layers. We can say there are actually ten or fifteen layers because within each layer there are a number of sub-layers of equal importance and significantly different from the others so as to warrant separate distinction. Or we can say there are really only two layers: the Data / Business layer and the Presentation Layer. But all this is too abstract. What follows is a discussion of the seven major interlocking points along the data cascade.

Sometimes the layers build upon the previous layer – combining fields, adding new data, and reformatting information; other times, the layers are redundant, with nothing really changing in the exchange, the only purpose being that of wrapping functionality or decoupling iWalk from the Crawl database. In all cases, however, the layers are set up to be followed in a very precise, linear fashion with the momentous task of getting data from Crawl (Part 1) into the front end (Part 2).

The first five layers – Part 1 – require a good understanding of Crawl’s data and its functional concepts. The final two layers – Part 2 – require a good understanding of iWalk functionality and web development.

Each layer plays a small but significant role in the overall process. Be aware that each layer accomplishes its task using a different way of thinking, a different vocabulary, a different technology, a different set of data, and a different way of representing that data.

This complexity requires patience, concentration, creativity and adaptability, along with an ease in a number of distinct skills – both functional and technical. And time – there is an estimated two-year learning curve. So, be patient with the process. At times, this document might let slip some criticisms of the iWalk Framework, or frustrations with its code. These are personal to the writer and are not intended to be merely critical: they are added constructively to inform the reader that the learning process is difficult for everybody.

Continue reading “The iWalk Framework”

Salesforce Crawl Platform

General Description

The Salesforce Interface (SFA) enables the exchange of Company data between Crawl and Salesforce, ensuring that both systems contain the same data. As of this writing, the systems that use SFA are Crawl, Salesforce, and iSee.

In the most common workflow, Salesforce is the Master of the data. This means that new company data is first entered into Salesforce and sent to Crawl using the automated SFA process. While the company remains a prospect, any changes to that data are done only in Salesforce and sent to Crawl. Crawl is therefore a Passive Receiver of data. Being passive, Crawl’s screens allow only read-only access to company data.

Note that there are other company data not in Salesforce that originate in Crawl and are therefore editable via Crawl.

All this changes when a company signs a contract with Sidewalk. With a signed contract, a prospect becomes a client, and the relationship switches, making Crawl the Master of the data and Salesforce the Passive Receiver. At this point, all changes to company data must be done in Crawl, which are automatically sent to Salesforce via the SFA interface. Additionally, Salesforce becomes read-only.

Continue reading “Salesforce Crawl Platform”

PRC Web Services

General Description

The PRC interface manages the exchange of data between Crawl and PRC. PRC is a third-party software and company used to perform credit checking on a company before contract signing.

The PRC process is a credit review process used by Crawl before contract signing.

The word “PRC” can be used in many different ways: the credit review process, or Crawl’s PRC interface, or the PRC software platform.

The “PRC software platform” stands for Platform Credit Risk, which is an in-house, Sidewalk solution to manage risk prior to contract signing. PRC is used by Sidewalk employees and interfaces, among others, with Nasaw and Crawl.

Continue reading “PRC Web Services”

this is where paris baseball is played

Baseball is played along an impressive line that cuts Paris in two. This line, which starts with a castle in the Bois de Vincennes and ends with another one in Saint Germain-en-Laye, travels along Rivoli and the avenues Sainte-Antoine and Champs Elysées. It is threaded by the Arche de Triomphe and the Grande Arche at La Defense, it cross stitches the palaces and gardens of the Louvre, and is held taught by the jumping boy on the golden pole at Bastille.

If you whip this line across the ocean, you’ll find Yankee stadium or maybe Fenway Park, another set of palaces for a decidedly different set of people. Or perhaps you’ll hit an old abandoned ballpark in another French speaking city, Montreal.

But you don’t have to leave Paris to play baseball. Simply go deeper into the woods of Vincennes and navigate through hundreds of soccer fields where you’ll find two regulation baseball fields and a single softball field. This is where Paris baseball is played.

Continue reading “this is where paris baseball is played”

Amateur Baseball, or The Chaos of Unearned Runs

The general bad level of play in some amateur baseball leagues flattens out individual skills. There is a point at which the number of fielding errors, passed balls, etc., as well as gratuitous walks and all sorts of mis-judgements, become so numerous that everyone – best or worst – contributes equally to wins and losses. Systemic bad play, in other words, makes everyone equally productive and non-productive. Furthermore, individual skills and statistics seem so unreliable to predict future performance that, win or lose, there seems little use of strategy in a game where there are more errors and unworked walks than hits. How does one design a team around that?

This is the dilemma.

Continue reading “Amateur Baseball, or The Chaos of Unearned Runs”

Create a website or blog at WordPress.com

Up ↑