8817bb68f3e21f6f0d0ea6b08004335bc68eeaf4
wiki/info/general/inventar-liste.md
| ... | ... | @@ -1,11 +0,0 @@ |
| 1 | -# Inventory Management |
|
| 2 | - |
|
| 3 | -We manage our inventory for events by little paper placeholder cards. When taking a piece of equipment our of of the cupboards or from a pelicase, note your name, the date and a purpose on the placeholder card for that piece of equipment. If you can't find a card for the piece you're taking, create one, noting the type and ID of the item in the card's header. Should the item not have a label with an ID on it, create one using our label printer, then write it on the card. |
|
| 4 | - |
|
| 5 | -Once you took the item, leave the card where the item was. We'll get you in case you should forget to return the item. |
|
| 6 | - |
|
| 7 | -If you plan to hand the item to someone else, perform the above process recursively and leave the card where the item was after you took it, e.g., in the pelicase. This may help you once we go after you to return the item so you know whom to go after in order to get the item back. |
|
| 8 | - |
|
| 9 | -Please note that particularly the smaller-sized items such as chargers and HDMI adapters fall under this policy because they tend to get lost even more often. |
|
| 10 | - |
|
| 11 | -Thanks for your support and co-operation :-) |
|
| ... | ... | \ No newline at end of file |
wiki/info/general/project-history.md
| ... | ... | @@ -0,0 +1,14 @@ |
| 1 | +# Project History |
|
| 2 | + |
|
| 3 | +The Sailing Analytics are a technology show-case originally used for demonstrating SAP technologies, concepts, skills and values applied to the domain of regatta sailing. They started as a small tool primarily intended to support a commentator in his job by displaying a live leaderboard for a sailing regatta with data interesting for the commentary. GPS and wind data travel from sensors to the server where the application keeps it in memory. When a request for a leaderboard is received, the data is aggregated on the fly, performing geometric computations including wind projections and involving a virtual "advantage line" orthogonal to the wind direction. |
|
| 4 | + |
|
| 5 | +The live leaderboard started as a web application with a Java back-end responsible for the connectivity with the sensors and providing the geometry engine, and a Python process rendering the Web UI for the client's browser. The Python process issued REST requests to the Java back-end which responded with JSON documents. |
|
| 6 | + |
|
| 7 | +The solution was first shown at Kieler Woche 2011. At the time, it was capable of displaying a single leaderboard that showed a number of tracked races in numerical form, offering columns for overall rank, race rank, rank at a mark, and values for average speed, distance traveled, gap to leader in seconds, velocity made good (VMG), estimated time of arrival at the next mark and current speed over ground. It was prototypical in many regards but regardless was considered an improvement for the commentary. The sailors liked it too because for the first time they could see numerical evidence of their choices of speed over distance. |
|
| 8 | + |
|
| 9 | +After Kieler Woche 2011, the architecture changed. We removed the Python engine and used the Google Web Toolkit instead to render the Web UI directly in the Java process. A first new live leaderboard with this approach was shown at the IDM Travemünde 2011 and later at the MdM Hamburg 2011 events. Over time, the solution learned to manage multiple leaderboards, combining historic race analysis with live tracking. Particularly the accumulation of historic race data will require changes in the architecture in the near future to support this use case better. |
|
| 10 | +A Google Map visualization, originally intended primarily for debugging purposes, matured to a useful tool used by commentators and spectators alike, combined with charts showing wind and competitor data, and of course the traditional live leaderboard. The leaderboard itself received various enhancements over time, including data about maneuvers such as tacks, jibes and penalty circles, and additional figures such as the average cross-track error which under shifty wind conditions in some boat classes may be an indicator for the risk taken by a competitor. Some of these figures turned out to be quite expensive to compute. Therefore, in a few cases we deviated from the original approach where everything was computed on the fly upon receiving a request. Instead, the more expensive calculations in live mode now happen asynchronously in the background, and client requests are fulfilled with whatever the most current result for these figures is. |
|
| 11 | + |
|
| 12 | +The REST/JSON APIs offered by the Java back-end have been exploited by at least two additional show-case scenarios. Already in 2011, Business Objects Dashboards displayed data extracted through these interfaces in various analytical views. In 2012, the interfaces started to be used for repeated extraction of data into a HANA database on top of which Experience UI technology is now used for visualization with sophisticated analyses. |
|
| 13 | + |
|
| 14 | +In 2012, a mobile application to support the race committees in their functions has been developed using largely the same architecture. Although the server for this app currently runs in a separate process, it uses largely the same code base, versioning repository and build process. We plan to integrate it with the SAP Sailing Analytics soon. A first loose coupling will allow users of the mobile app to send wind data entered on a mobile device into the SAP Sailing Analytics back-end where it augments the wind-based calculations. Later, we plan to integrate the mobile app even closer so that it supports race officials in laying and moving marks, changing the course layout as well as detecting and announcing disqualifications. |
|
| ... | ... | \ No newline at end of file |
wiki/info/general/workspace-bundles-projects-structure.md
| ... | ... | @@ -0,0 +1,3 @@ |
| 1 | +# Workspace, Bundles, Projects |
|
| 2 | + |
|
| 3 | +After completing the [[onboarding|wiki/howto/onboarding]], your workspace will contain dozens of projects. |
|
| ... | ... | \ No newline at end of file |
wiki/info/landscape/architecture-and-infrastructure.md
| ... | ... | @@ -1,29 +0,0 @@ |
| 1 | -# Architecture and Infrastructure |
|
| 2 | - |
|
| 3 | -### Table of Contents |
|
| 4 | - |
|
| 5 | -* [[Runtime Environment|wiki/info/landscape/runtime-environment.md]] |
|
| 6 | -* [[Basic Architectural Principles|wiki/info/landscape/basic-architectural-principles]] |
|
| 7 | -* [[User Management|wiki/info/landscape/usermanagement]] |
|
| 8 | -* [[Development Environment|wiki/info/landscape/development-environment]] |
|
| 9 | -* [[Production Environment|wiki/info/landscape/production-environment]] |
|
| 10 | -* [[Typical Development Scenarios|wiki/info/landscape/typical-development-scenarios]] |
|
| 11 | - |
|
| 12 | -## Introduction, Project Background and History |
|
| 13 | - |
|
| 14 | -The SAP Sailing Analytics are a technology show-case demonstrating SAP technologies, concepts, skills and values applied to the domain of regatta sailing. They started as a small tool primarily intended to support a commentator in his job by displaying a live leaderboard for a sailing regatta with data interesting for the commentary. GPS and wind data travel from sensors to the server where the application keeps it in memory. When a request for a leaderboard is received, the data is aggregated on the fly, performing geometric computations including wind projections and involving a virtual "advantage line" orthogonal to the wind direction. |
|
| 15 | - |
|
| 16 | -The live leaderboard started as a web application with a Java back-end responsible for the connectivity with the sensors and providing the geometry engine, and a Python process rendering the Web UI for the client's browser. The Python process issued REST requests to the Java back-end which responded with JSON documents. |
|
| 17 | - |
|
| 18 | -The solution was first shown at Kieler Woche 2011. At the time, it was capable of displaying a single leaderboard that showed a number of tracked races in numerical form, offering columns for overall rank, race rank, rank at a mark, and values for average speed, distance traveled, gap to leader in seconds, velocity made good (VMG), estimated time of arrival at the next mark and current speed over ground. It was prototypical in many regards but regardless was considered an improvement for the commentary. The sailors liked it too because for the first time they could see numerical evidence of their choices of speed over distance. |
|
| 19 | - |
|
| 20 | -After Kieler Woche 2011, the architecture changed. We removed the Python engine and used the Google Web Toolkit instead to render the Web UI directly in the Java process. A first new live leaderboard with this approach was shown at the IDM Travemünde 2011 and later at the MdM Hamburg 2011 events. Over time, the solution learned to manage multiple leaderboards, combining historic race analysis with live tracking. Particularly the accumulation of historic race data will require changes in the architecture in the near future to support this use case better. |
|
| 21 | -A Google Map visualization, originally intended primarily for debugging purposes, matured to a useful tool used by commentators and spectators alike, combined with charts showing wind and competitor data, and of course the traditional live leaderboard. The leaderboard itself received various enhancements over time, including data about maneuvers such as tacks, jibes and penalty circles, and additional figures such as the average cross-track error which under shifty wind conditions in some boat classes may be an indicator for the risk taken by a competitor. Some of these figures turned out to be quite expensive to compute. Therefore, in a few cases we deviated from the original approach where everything was computed on the fly upon receiving a request. Instead, the more expensive calculations in live mode now happen asynchronously in the background, and client requests are fulfilled with whatever the most current result for these figures is. |
|
| 22 | - |
|
| 23 | -The REST/JSON APIs offered by the Java back-end have been exploited by at least two additional show-case scenarios. Already in 2011, Business Objects Dashboards displayed data extracted through these interfaces in various analytical views. In 2012, the interfaces started to be used for repeated extraction of data into a HANA database on top of which Experience UI technology is now used for visualization with sophisticated analyses. |
|
| 24 | - |
|
| 25 | -In 2012, a mobile application to support the race committees in their functions has been developed using largely the same architecture. Although the server for this app currently runs in a separate process, it uses largely the same code base, versioning repository and build process. We plan to integrate it with the SAP Sailing Analytics soon. A first loose coupling will allow users of the mobile app to send wind data entered on a mobile device into the SAP Sailing Analytics back-end where it augments the wind-based calculations. Later, we plan to integrate the mobile app even closer so that it supports race officials in laying and moving marks, changing the course layout as well as detecting and announcing disqualifications. |
|
| 26 | - |
|
| 27 | -The remainder of this document explains the key architectural principles on which the SAP Sailing Analytics have been developed. It is to be considered a snapshot of the status quo, as documented by the time stamp in the document's header. |
|
| 28 | - |
|
| 29 | -See also this [[presentation|https://git.wdf.sap.corp/gitweb?p=SAPSail/sapsailingcapture.git;a=blob;f=doc/SAPSailingAnalyticsArchitecture.pptx;h=26e0746e2d6a660cc2885fc47c0e817ab2dc8709;hb=refs/heads/master]] that provides an overview of the project's architecture and history. |
|
| ... | ... | \ No newline at end of file |
wiki/info/landscape/runtime-environment.md
| ... | ... | @@ -3,7 +3,11 @@ |
| 3 | 3 | [[_TOC_]] |
| 4 | 4 | |
| 5 | 5 | ## Linux, Java, OSGi/Equinox |
| 6 | -By and large, the SAP Sailing Analytics are a web application implemented using Java technology. The application's components are OSGi bundles running in an Equinox OSGi container. Some bundles offer static web content or dynamic content in the form of servlets. Those bundles are implemented as OSGi Web Bundles which we consider a simple and elegant way to meet web standards using an OSGi-based implementation. A Web Bundle's main extension compared to a regular OSGi bundle is the presence of a web.xml descriptor in the WEB-INF top-level folder where servlets and static content can be declared and mapped to URLs. |
|
| 6 | +By and large, the Sailing Analytics are a web application implemented using Java technology. The application's components are OSGi bundles running in an Equinox OSGi container. Some bundles offer static web content or dynamic content in the form of servlets. Those bundles are implemented as OSGi Web Bundles which we consider a simple and elegant way to meet web standards using an OSGi-based implementation. A Web Bundle's main extension compared to a regular OSGi bundle is the presence of a web.xml descriptor in the WEB-INF top-level folder where servlets and static content can be declared and mapped to URLs. |
|
| 7 | + |
|
| 8 | +Yet other bundles are GWT projects that also may have a backend part, making them an OSGi bundle from the backend's perspective, yet a GWT project for the GWT compiler and runtime. |
|
| 9 | + |
|
| 10 | +The application exposes a web UI, implemented using GWT (see below), a REST API implemented largely using JAX-RS/Jersey-based OSGi web bundles, an OSGi console accessible through the telnet protocol, and one or more connectivity components, such as a socket server backend for Igtimi wind sensors or a UDP connector for the "Expedition" on-board navigation tool. |
|
| 7 | 11 | |
| 8 | 12 | ## Database |
| 9 | 13 | By and large, we use a database to recover from a server restart. Once started, most data managed by the application is kept in main memory. We currently use MongoDB as our database. Different DB instances belong to different server instances. This allows us to cleanly separate development and test data from production data. |
wiki/info/landscape/ui-clickable-prototypes.md
| ... | ... | @@ -1,6 +0,0 @@ |
| 1 | -# Clickable UI prototypes with Axure |
|
| 2 | - |
|
| 3 | -In the process of designing new user interfaces we can use the 'Axure' software to create clickable prototypes for our ideas. These ideas are often represented through so called 'wireframes' described e.g. with tools like Adobe Illustrator. |
|
| 4 | - |
|
| 5 | -## First steps |
|
| 6 | -- Download and install the software 'Axure' from http://www.axure.com |
|
| ... | ... | \ No newline at end of file |