Weblog

Boomerang Plugin

Created by Gustaf Neumann, last modified by Gustaf Neumann 11 Jan 2018, at 01:41 PM

Package Specification Summary for Package: boomerang

Summary:	Boomerang is a JavaScript library to measure the performance of your website from your end user’s point of view. It has the ability to send performance data measured at the client back to the server via a beacon URL further analysis. The boomerang library implements Real User Measurement (RUM) to measure the performance experience of real users by collecting quality indicators from the clients. The boomerang library is released under the BSD license. Details: https://soasta.github.io/boomerang/doc/ This package integrates boomerang with OpenACS, in particular with OpenACS subsites.
Description:
Maturity:	Immature
This package depends on:	acs-templating acs-tcl
Packages that depend on boomerang:	None
Package parameters:	Version Version of the boomerang library (default 1.737.0, type string, scope instance)

Bug Tracker Summary for Package: boomerang

There is no package with the name "boomerang" known to bug-tracker.

Code Metrics Summary for Package: boomerang

# Tcl Procs	6
# Tcl Lines	647
# Tcl Blank Lines	74
# Tcl Comment Lines	172
# Automated Tests	0
# Stored Procedures	PG: 0 ORA: 0
# SQL Lines	PG: 0 (blank 1 comments 0) ORA: 0 (blank 1 comments 0)
# ADP pages	1
# ADP lines	41
# Include pages (boomerang/lib/)	0
# Documentation pages	0
# Documentation lines	0
Browse Source	API-browser
Github Repository:	https://github.com/openacs/boomerang/tree/oacs-5-10

Integration of the Boomerang library as an OpenACS Plugin

Boomerang is a JavaScript library to measure the performance of your website from your end user’s point of view. It has the ability to send performance data measured at the client back to the server via a beacon URL further analysis.  The boomerang library implements Real User Measurement (RUM) to measure the performance experience of real users by collecting quality indicators from the clients.

The boomerang library is released under the BSD license.

Details:
    https://soasta.github.io/boomerang/doc/

This package integrates boomerang with OpenACS, in particular with OpenACS subsites.

Features

• Obtain client site timings to measures the performance of your  website from your end user's point of view.
• Support sampling (e.g. just obtain metrics from every nth request)
• Output performance data in a format suitable for feeding into  Elasticsearch/Logstash (see below for example config files)
• Configure the appearance of the boomerang per subsite with  the following parameters:
   

  BoomerangEnabled	0|1
  BoomerangSample	1
  BoomerangBeaconUrl	/boomerang_handler

   
  The parameter BoomerangSample can be used for busy sites to sample not every request (when the value is 1), but e.g. every 5th request (setting BoomerangSample to 5).
• Support for host-node-mapped subsites
• Site-wide admin support for compressing .js file
• Performance: include boomerang in the template costs about 0.3ms, processing of the beacon call takes about 1ms (filter times).

Installation

1. Install this package via the OpenACS Package Manager
    
2.  Add this package to the templating system
    
   • OpenACS 5.10.0d2 or newer:
     The boomerang plugin uses the "subsite::page_plugin" callback, so no changes on templates are necessary. Make sure to update as well the acs-bootstrap-installer to 5.10.0d2 or newer to obtain the updated blank-master.
      
   • OpenACS 5.9.1:
     Add to the top of your blank-master.tcl the following snippet:

           if {[info commands ::boomerang::initialize_widget] ne ""} {
               ::boomerang::initialize_widget
           }

3.  Configure in the parameters of the subsite (e.g. the main subsite) the section "Boomerang Plugin"

 

Usage

For the explanation of the parameters, see:
     https://soasta.github.io/boomerang/doc/howtos/howto-0.html
     https://soasta.github.io/boomerang/doc/api/RT.html
     https://soasta.github.io/boomerang/doc/api/navtiming.html    
 

Prerequirements

The implementation uses nx from the next-scripting framework.

    https://next-scripting.org/xowiki/

which is automatically installed for XOTcl2 via naviserver-openacs. It works best with OpenACS 5.10.0d2 or newer, but works as well with 5.9.1 (see INSTALLATION section above) or earlier versions with little adaptions

 

OPTIONAL: Define a custom Boomerang Plugin

1. Clone boomerang repository
2. Install npm, grunt if necessary
3. Follow step 2 in https://github.com/SOASTA/boomerang     which means
         ... configure plugins
         ... grunt clean build
4. The result is in the build directory. The generated files have the a build-time stamp in seconds included. You might which to rename these with a custom name.
5. Copy the the *.min.js and *.min.js.gz files to the boomerang/www/resouces directory, which might be

   cp  build/boomerang-1.0.*.min.js build/boomerang-1.0.*.min.js.gz ..

   and adapt the version number in the boomerang parameters (on /acs-subsite)
    

    

OPTIONAL: Feed Boomerang Data into an elasticsearch cluster

When boomerang is enabled, the results of the beacon are placed into
the OpenACS log directory with a name boomerang-*.log (containing the date).

Below are sample-snippets from OpenACS.org the log-files into elasticsearch,
such that it can be analyzed later with kibana or grafana.

Example filebeat entry for the data feed:

      paths:
        - /var/www/openacs.org/log/boomerang-*.log
      input_type: log
      fields:
          log_type: boomerang-log

Example logststash entry (input filter for transforming the data from filebeat and to feed it into easticsearch)

  if [fields][log_type] == "boomerang-log" {
    json {
       source => "message"
       remove_field => [ "restiming" ]
    }
    grok {
       match => [ "source", "/var/www/%{GREEDYDATA:server}/log/boomerang-" ]
    }    
    geoip { source => "clientip" }
  }

 

Example Analysis Screenshots from OpenACS

The following chart shows performance indicators of OpenACS.org over the last two days. The topmost chart is produced with grafana and shows elapsed time (left axis) and number of requests (right axis). "Average runtime" is the time measured on the server (how long does it take the server to fulfill the requests), whereas "Average t_done" is the time it took the browser to render the page (stating at the click). "t_done" is a default measurement provided by boomerang. Note, that the values from boomerang require that JavaScript is active at the client side (i.e. there are typically no spiders included in this value, as well only views).

We can see from these values that the average runtime is 36ms, while the full render time is on average 2.2s (about 60x larger). One reason is that static content is served quite fast.  The second chart is as well produced with grafana and analyses the phases of requests based on W3C Navigation Timing. The nt_response_time shows the client point of view how long it took the server to provide an response to the request.

We can see that nt_response_time is about 100ms (it takes longer to server the dynamic html files). Also from this point of view the response time of the server for the main request only contributed a fraction of the total time. The longest time is the processing time in the client, which depends on the content, CSS, JavaScript, etc. Note that these are overall values, averaging over all requests. One can certainly drill down on certain pages for more details.

Another interesting aspect is the geographic location: has the client a good internet connection in respect to the server? The first map was produced with kibana and shows from which geographic locations pages of OpenACS.org were requested over the last week. Locations with more requests are shown emphasized.

We see that the highest number of requests are coming from the US (Seattle and Washington areas), and in Europe is Austria (Vienna) and France (Paris) issued many requests. If we analyze for boomerang requests with high values of "t_done", we see that these requests are coming from regions far away from Vienna, where the server is located (e.g. from Asia, South America, Australia)

 

 

OpenACS Reference Platform

Created by OpenACS community, last modified by Robert Taylor 29 Dec 2017, at 03:23 PM

These are the defaults we create and use during the standard installation process, in helper scripts and other places. None of these locations are set in stone - they're simply the values that we've chosen.

Default directories for a standard install

Fully qualified domain name of your server	yourserver.test
name of administrative access account	remadmin
OpenACS service	service0
OpenACS service account	service0
OpenACS database name	service0
SERVERROOT - base of the OpenACS service file tree	/var/lib/aolserver/service0
Location of source code tarballs for new software	/var/tmp
The OpenACS tarball contains some files which are useful while setting up other software. Those files are located at:	/var/lib/aolserver/service0/packages/acs-core-docs/www/files
Database backup directory	/var/lib/aolserver/service0/database-backup
Service config files	/var/lib/aolserver/service0/etc
Service log files	/var/lib/aolserver/service0/log
Base compile directory	/usr/local/src
PostgreSQL directory	/usr/local/pgsql
AOLserver directory	/usr/local/aolserver

Some instructions provide cut and paste conveniences

In order for some copy and paste instructions to work in your bash shell, you must set the environment variable $OPENACS_SERVICE_NAME. Add this line to your .bashrc or .profile_bash file to set the environment variable for a specific user:

export OPENACS_SERVICE_NAME=service0

To set it globally so that it works for any new users or special service users you may create, add the above line to the file /etc/profile

$OPENACS_SERVICE_NAME is set to the value of service0 on a default install. Change service0 to a word that better represents your project. The other values we recommend you leave unchanged unless you have a reason to change them.

A service name ($OPENACS_SERVICE_NAME) should be a single word, letters and numbers only. If the name of your site is one word, that would be a good choice. For example "$OPENACS_SERVICE_NAME" might be the service name for the OPENACS_SERVICE_NAME.net website.

Some discussion that lead to these default values: https://openacs.org/forums/message-view?message_id=82934

Commit Messages

Created by Gustaf Neumann, last modified by Gustaf Neumann 29 Dec 2017, at 10:11 AM

• Write your commit message in the imperative present tense: Use "Fix bug" and not "Fixed bug" or "Fixes bug." This convention matches up with commit messages generated by commands like git merge and git revert. It should start with a verb like "Fix", "Add" or "Change".
• Commit message should contain a title and an optional body.
• The title of the commit message should be a capitalized, short (50 chars or less) summary, not ending with a period.
• The title can be followed by the body, an explanatory text, if necessary. Title and body are separated by an empty line. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together.
• The body should be wrapped to 72 characters.  The body can contain multiple paragraphs, containing plain text or bullet points. The bullet points should be typed as a hyphen or asterisk with blank lines in between. Use a hanging indent for longer bullet points
• Make white-space changes separately

See also:

• http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
• https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message
• https://github.com/torvalds/linux/pull/17#issuecomment-5659933

Cookie Consent Widget

Created by Gustaf Neumann, last modified by Gustaf Neumann 22 Dec 2017, at 06:55 PM

Package Specification Summary for Package: cookie-consent

Summary:	Cookie Consent Widget based on the free Cookie Consent Library
Description:
Maturity:	Immature
This package depends on:	acs-templating acs-tcl
Packages that depend on cookie-consent:	None
Package parameters:	None

Bug Tracker Summary for Package: cookie-consent

There is no package with the name "cookie-consent" known to bug-tracker.

Code Metrics Summary for Package: cookie-consent

# Tcl Procs	9
# Tcl Lines	517
# Tcl Blank Lines	64
# Tcl Comment Lines	93
# Automated Tests	1
# Stored Procedures	PG: 0 ORA: 0
# SQL Lines	PG: 0 (blank 1 comments 0) ORA: 0 (blank 1 comments 0)
# ADP pages	1
# ADP lines	7
# Include pages (cookie-consent/lib/)	0
# Documentation pages	0
# Documentation lines	0
Browse Source	API-browser
Github Repository:	https://github.com/openacs/cookie-consent/tree/oacs-5-10

Integration of the Cookie Consent Library into OpenACS

The Cookie Consent Library is and Cookie Consent to be free and open sourced library for for alerting users about the use of cookies on a website.  It is designed to help you comply with the hideous EU Cookie Law and not make you want to kill yourself in the process. So we made it fast, free, and relatively painless.

Details:
    https://cookieconsent.insites.com/
    https://github.com/insites/cookieconsent/

This package integrates the Consent Plugin with OpenACS, in particular with OpenACS subsites.

So far, this package supports on the "inform" type of cookie consent policies. When the "opt-out" or "opt-in" variants of the policies should really include all types of cookies (even session-cookies) the user would not be able to login to the site. However, most countries stick for now to the "inform" policy, and the detailed regulation are still in flux.

Features:

•  Configure the appearance of the cookie consent widget via the following parameter (on acs-subsite):
   

  CookieConsentEnabled	0|1
  CookieConsentPosition	bottom|top|pushdown|left|right
  CookieConsentLayout	block|classic|edgeless|wire
  CookieConsentPalette	oacs|honeybee|mono|neon|corporate
  CookieConsentLearnMoreLink	https://cookiesandyou.com/
  CookieConsentDefaultPalette

   

• Usage from CDN (out-of-the box) or from a local copy (download your local copy via   "Site-Wide Admin" link in /acs-admin/)
• Support for host-node-mapped subsites
• Internationalized with OpenACS message keys

Installation

1.  Install this package via the OpenACS Package Manager
2.  Add this package to the templating system
    
   •  OpenACS 5.10.0d2 or newer:
      The cookie consent widgets uses the "subsite::page_plugin" callback, so no changes on templates are necessary. Make sure, you update also acs-bootstrap-installer to 5.10.0d2 or newer to obtain the updated blank-master
      
   • OpenACS 5.9.1:
     Add to the top of your blank-master.tcl the following snippet:
      ================================================================
     if {[info commands ::cookieconsent::initialize_widget] ne ""} {
           ::cookieconsent::initialize_widget
     }
     ================================================================
3. Configure the CookieConsent* parameters of the subsite (e.g. of the main subsite) in the section "Cookie Consent"

Prerequirements:

The implementation uses nx from the next-scripting framework.

    https://next-scripting.org/xowiki/

which is automatically installed for XOTcl2 via naviserver-openacs

It works best with OpenACS 5.10.0d2 or newer, but works as well with 5.9.1 (see INSTALLATION section above) or earlier versions supporting Content Security Policy (CSP), and probably with  earlier versions as well, when CSP code is commented out.

 

 

 

Richtext CKEditor 5

Created by Gustaf Neumann, last modified by Gustaf Neumann 21 Dec 2017, at 09:28 AM

Package Specification Summary for Package: richtext-ckeditor5

Summary:	Richtext editor plugin for integrating CKeditor 5 with the acs-templating richtext widget
Description:
Maturity:	New Submission or Maturity Unknown
This package depends on:	acs-templating acs-tcl xotcl-core attachments
Packages that depend on richtext-ckeditor5:	None
Package parameters:	SCAYT Fully featured "Spell Check As You Type" based on WebSpellChecker.net. Please note that the spellchecked words are transferred to that site, so you might be cautious to activate this feature for confidential content. (default false, type string, scope instance)

Bug Tracker Summary for Package: richtext-ckeditor5

There is no package with the name "richtext-ckeditor5" known to bug-tracker.

Code Metrics Summary for Package: richtext-ckeditor5

# Tcl Procs	10
# Tcl Lines	622
# Tcl Blank Lines	84
# Tcl Comment Lines	131
# Automated Tests	0
# Stored Procedures	PG: 0 ORA: 0
# SQL Lines	PG: 0 (blank 1 comments 0) ORA: 0 (blank 1 comments 0)
# ADP pages	1
# ADP lines	20
# Include pages (richtext-ckeditor5/lib/)	1
# Documentation pages	0
# Documentation lines	0
Browse Source	API-browser
Github Repository:	https://github.com/openacs/richtext-ckeditor5/tree/oacs-5-10

In general, the CKEditor 5 can be used via CDN (zero configuration, default) or via local files. One can use /acs-admin/ (section Site-wide Service Administration to download a version to your local site to reduce latency or to use local modifications.

So far, CKeditor 5 is not released yet, this integration is just minimal, no xowiki formfield support is included yet.

.LRN Accessibility

Created by Olga C. Santos, last modified by Gustaf Neumann 25 Oct 2017, at 08:34 AM

From quite a long time .LRN community has been moving towards producing both accessible interfaces and services for all. Accessibility analysis on previous releases have been done such as Tristan Kalnins-Cole's under Dorian Peter's (dotLRN Director of Visual Design) supervision. This lead to the unofficial conclusion that version 2.1.3 was level A compliant.

Selva theme was designed to make easier the customization of the look and feel of .LRN, improving navigation and usability. Moreover, unlike other .LRN templates, it is strongly based on CSS. Therefore, it can be easily seen that Selva theme was a step forward in considering accessibility issues.

During the development of version 2.2.0 we have been working to assure that .LRN 2.2.0 with Selva theme is compliant at least with W3C WAI WCAG 1.0 level A. In this sense, three new categories of bugs have been created in the Bug Tracker and are being used to report problems regarding accessibility. So far, within the framework of several R&D projects in which aDeNu Research Group at UNED is involved, we have compiled several accessibility analysis performed by some of our partners (Soluziona) and research groups within UNED to translate the problems found at different development stages to .LRN/OpenACS bugs and discuss them in the .LRN IRC Tuesday meetings. "This work has led to the release of .LRN 2.2.0 as W3C WAI WCAG 1.0 level A compliant, except for LORS package (there is a strong incompatibility between the SCORM RTE and WCAG 1.0, which is to be solved with WCAG 2.0). Moreover, there may be some minor level A bugs reported found here, which are to be solved."

The planning for next version is to achieve WC3 WAI WCAG level AA and take into account, when available, specific guidelines from national regulations such as the American Section 508, UK SENDA, Australian DDA, German BITV or Italian Stanca. Our plans are to consider WCAG 2.0 as soon as they are officially released as well as other WAI documents (e.g. ATAG and UAAG).

In order to improve the accessibility quality of dotLRN, we ask you to use W3C Web Content Accessibility bug types to report any problems encountered so they are taking into account when developing.

Update for dotLRN 2.3

See Zen project and external evaluations on Educational packages [1], [2].

Information on the progress is also done in periodic dotLRN/OpenACS conferences:

• Fall 2006
  • Session Towards full Accessibility in LMS
• Spring 2007
  • Improving Accessibility, Usability, and Code Quality of .LRN and OpenACS: The .LRN Zen Project [3]
  • Workshop on Experiences on Accessible eLearning Platforms

 

Last modified: 2017-10-25 08:34:57.234495+02

Ajax Helper

Created by Hamilton Chua, last modified by Gustaf Neumann 25 Oct 2017, at 08:32 AM

Package Specification Summary for Package: ajaxhelper

Summary:	Ajax Helper for various javascript libraries.
Description:	Provides helper procs to generate javascript used for Ajax and generating cinematic effects. Includes Scriptaculous 1.7.1 beta3 with Prototype 1.5.1, ExtJS 1.1.1 and the Yahoo UI Libraries (2.3.0). As of 0.87d, there is now an option to load YUI js source files direct from yahoo (http://developer.yahoo.com/yui/articles/hosting/). Lee Denison's template::head is now used to load javascript sources and css. The YUI loader is used to intelligently load YUI sources and css. As of 0.7d, all javascript libraries have been moved to ajaxhelper/www/resources to take advantage of caching. As of 0.8d, the wrappers will now be able to check a global variable to see if the required sources are loaded, this allows helper procs to automatically load the javascript sources you need.
Documentation:	Package Documentation
Maturity:	Immature
This package depends on:	acs-kernel acs-tcl
Packages that depend on ajaxhelper:	ajax-filestorage-ui ajax-photoalbum-ui connections contacts eduwiki learning-content messages planner scorm-player
Package parameters:	LoadJsfromYahoo Set this parameter to 1 if you wish to load YUI javascript sources from yahoo's servers. (default 0, type number, scope instance) UseMinifiedJs Set this parameter to 1 if you want ajaxhelper to load minified versions of the javascript sources whenever possible. (default 0, type number, scope instance)

Bug Tracker Summary for Package: ajaxhelper

There is no package with the name "ajaxhelper" known to bug-tracker.

Code Metrics Summary for Package: ajaxhelper

# Tcl Procs	67
# Tcl Lines	2784
# Tcl Blank Lines	514
# Tcl Comment Lines	67
# Automated Tests	0
# Stored Procedures	PG: 0 ORA: 0
# SQL Lines	PG: 0 (blank 1 comments 0) ORA: 0 (blank 1 comments 0)
# ADP pages	15
# ADP lines	147
# Include pages (ajaxhelper/lib/)	1
# Documentation pages	9 (Package Documentation)
# Documentation lines	1400
Browse Source	Not installed
Github Repository:	https://github.com/openacs/ajaxhelper/tree/oacs-5-10

 

Ajax Helper is a package created to assist OpenACS developers incorporate Ajax into their web applications. It is composed of helper procs that wrap javascript functions that perform DHTML effects and Ajax. 

Ajax Helper incorporates javascript from Thomas Fuch's Scriptaculous Javascript Library (http://script.aculo.us) and Yahoo's User Interface Library or YUI ( http://developer.yahoo.com/yui/ ).

Tutorials on how to use Ajax Helper :

Introduction to Ajax Helper with Simple Effects
http://web.archive.org/web/20111221205659/http://www.solutiongrove.com/blogger//one-entry?entry%5fid=266153

Using Ajax
http://web.archive.org/web/20060715115103/http://www.solutiongrove.com:80/blogger/one-entry?entry%5fid=268010

Simple Drag and Drop
http://web.archive.org/web/20060715115051/http://www.solutiongrove.com:80/blogger/one-entry?entry%5fid=266155

Current Release on CVS HEAD : AjaxHelper 0.87d
includes Scriptaculous v.1.7.3 Beta, YUI v. 2.3.0 and ExtJs 1.1.1
 

 

Assessment Admin UI

Created by Caroline Meeks, last modified by Gustaf Neumann 20 Oct 2017, at 05:25 AM

TODO LIST

• Update this page with the latest work
• Carl will fill in here... 

 The current UI is very confusing and cluttered.

Our vision of a final UI is that a assessment creator would pick a type of assessment he wants and the site will set all defaults appropriately for it. However, the first attempt to do this was a failure so we are working on an incremental approach that we think will provide value with minimal effort. Our intent is that later we move to an even friendlier UI.

 Incremental Improvement Vision:  The current user experience is: every time you create anything you are confronted by many many choices, most of which you can ignore. Similarly all the admin pages have many repeated buttons and its not clear when you want to do what.  Thus our goal is:

• Creation pages are very very simple and useful defaults are set for everything.
• Objects then have one button to an Edit page that has all the complex things you can do with the object.

Related Pages:

• Assessment Admin Index
• One Assessment Admin Assessment one-a 

Screenshots

These are screenshots of the work in progress.

 

Simplified quick assessment creation form. 

 

One Assessment Admin Page 

 

One Section Admin Page

 

 

 Add a question page.

First the original question form:

Now the new form. The question creation process used to require filling out 3 forms. We compressed it to one form by removing unused settings, and making intelligent default decisions. Some more work needs to be done. Assessment has a huge amount of complex features and it is not clear how they are used together to create a certain type of assessment. It is clear that all of the settings rarely need to be used together.

 

Official Test Servers

Created by Gustaf Neumann, last modified by Gustaf Neumann 19 Oct 2017, at 11:53 AM

Currently none

{done} OpenACS 5.3.x releases

Created by Rocael Hernández Rizzardini, last modified by Gustaf Neumann 19 Oct 2017, at 11:53 AM

OpenACS 5.3.x Releases

---

Update: OpenACS 5.3.0a1 is available for download https://openacs.org/projects/openacs/download/one-revision?revision_id=494139 or by checking out openacs-5-3-0a1 tag from CVS. Work continues on the oacs-5-3 branch in CVS
 

The main goal is to have acs-core to pass all the automated tests (PG 8.1.x & Oracle 9i).

We plan to branch for oacs-5-3 in September 2006. 

Many bug stomp where we actually create, fix, update tests for acs-core has been done. 

Bug-stomp: 21-22 sept. 06. Focus on have all the actual test pass for acs-core (no more new test), plus start classifying the bugs in the bug-tracker. Based on the results of this bug-stomp we'll decide when to branch and what should be included (bug-fixes) in next release.

 

Check the Official Test Servers