fetch(url, {
method: "PUT",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
PUT api/v1/point-settings/{point_setting}
PATCH api/v1/point-settings/{point_setting}
api/v1/point-settings/{point_setting}
Example request:
curl -X DELETE \
"http://localhost/api/v1/point-settings/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/point-settings/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "DELETE",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
DELETE api/v1/point-settings/{point_setting}
api/v1/point-conditions
Example request:
curl -X GET \
-G "http://localhost/api/v1/point-conditions" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/point-conditions"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/point-conditions
api/v1/point-conditions
Example request:
curl -X POST \
"http://localhost/api/v1/point-conditions" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/point-conditions"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "POST",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
POST api/v1/point-conditions
api/v1/point-conditions/{point_condition}
Example request:
curl -X GET \
-G "http://localhost/api/v1/point-conditions/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/point-conditions/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/point-conditions/{point_condition}
api/v1/point-conditions/{point_condition}
Example request:
curl -X PUT \
"http://localhost/api/v1/point-conditions/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/point-conditions/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "PUT",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
PUT api/v1/point-conditions/{point_condition}
PATCH api/v1/point-conditions/{point_condition}
api/v1/point-conditions/{point_condition}
Example request:
curl -X DELETE \
"http://localhost/api/v1/point-conditions/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/point-conditions/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "DELETE",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
DELETE api/v1/point-conditions/{point_condition}
api/v1/voucher-wallets
Example request:
curl -X GET \
-G "http://localhost/api/v1/voucher-wallets" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/voucher-wallets"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/voucher-wallets
api/v1/voucher-wallets
Example request:
curl -X POST \
"http://localhost/api/v1/voucher-wallets" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/voucher-wallets"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "POST",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
POST api/v1/voucher-wallets
api/v1/voucher-wallets/{voucher_wallet}
Example request:
curl -X GET \
-G "http://localhost/api/v1/voucher-wallets/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/voucher-wallets/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/voucher-wallets/{voucher_wallet}
api/v1/voucher-wallets/{voucher_wallet}
Example request:
curl -X PUT \
"http://localhost/api/v1/voucher-wallets/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/voucher-wallets/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "PUT",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
PUT api/v1/voucher-wallets/{voucher_wallet}
PATCH api/v1/voucher-wallets/{voucher_wallet}
api/v1/voucher-wallets/{voucher_wallet}
Example request:
curl -X DELETE \
"http://localhost/api/v1/voucher-wallets/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/voucher-wallets/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "DELETE",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
DELETE api/v1/voucher-wallets/{voucher_wallet}
api/v1/reward-lists
Example request:
curl -X GET \
-G "http://localhost/api/v1/reward-lists" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/reward-lists"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/reward-lists
api/v1/reward-lists
Example request:
curl -X POST \
"http://localhost/api/v1/reward-lists" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/reward-lists"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "POST",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
POST api/v1/reward-lists
api/v1/reward-lists/{reward_list}
Example request:
curl -X GET \
-G "http://localhost/api/v1/reward-lists/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/reward-lists/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/reward-lists/{reward_list}
api/v1/reward-lists/{reward_list}
Example request:
curl -X PUT \
"http://localhost/api/v1/reward-lists/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/reward-lists/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "PUT",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
PUT api/v1/reward-lists/{reward_list}
PATCH api/v1/reward-lists/{reward_list}
api/v1/reward-lists/{reward_list}
Example request:
curl -X DELETE \
"http://localhost/api/v1/reward-lists/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/reward-lists/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "DELETE",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
DELETE api/v1/reward-lists/{reward_list}
api/v1/point-logs
Example request:
curl -X GET \
-G "http://localhost/api/v1/point-logs" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/point-logs"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/point-logs
api/v1/point-logs
Example request:
curl -X POST \
"http://localhost/api/v1/point-logs" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/point-logs"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "POST",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
POST api/v1/point-logs
api/v1/point-logs/{point_log}
Example request:
curl -X GET \
-G "http://localhost/api/v1/point-logs/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/point-logs/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/point-logs/{point_log}
api/v1/point-logs/{point_log}
Example request:
curl -X PUT \
"http://localhost/api/v1/point-logs/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/point-logs/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "PUT",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
PUT api/v1/point-logs/{point_log}
PATCH api/v1/point-logs/{point_log}
api/v1/point-logs/{point_log}
Example request:
curl -X DELETE \
"http://localhost/api/v1/point-logs/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/point-logs/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "DELETE",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
DELETE api/v1/point-logs/{point_log}
api/v1/vehicle-brands
Example request:
curl -X GET \
-G "http://localhost/api/v1/vehicle-brands" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/vehicle-brands"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/vehicle-brands
api/v1/vehicle-brands
Example request:
curl -X POST \
"http://localhost/api/v1/vehicle-brands" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/vehicle-brands"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "POST",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
POST api/v1/vehicle-brands
api/v1/vehicle-brands/{vehicle_brand}
Example request:
curl -X GET \
-G "http://localhost/api/v1/vehicle-brands/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/vehicle-brands/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/vehicle-brands/{vehicle_brand}
api/v1/vehicle-brands/{vehicle_brand}
Example request:
curl -X PUT \
"http://localhost/api/v1/vehicle-brands/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/vehicle-brands/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "PUT",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
PUT api/v1/vehicle-brands/{vehicle_brand}
PATCH api/v1/vehicle-brands/{vehicle_brand}
api/v1/vehicle-brands/{vehicle_brand}
Example request:
curl -X DELETE \
"http://localhost/api/v1/vehicle-brands/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/vehicle-brands/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "DELETE",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
DELETE api/v1/vehicle-brands/{vehicle_brand}
api/v1/vehicle-mangements
Example request:
curl -X GET \
-G "http://localhost/api/v1/vehicle-mangements" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/vehicle-mangements"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/vehicle-mangements
api/v1/vehicle-mangements
Example request:
curl -X POST \
"http://localhost/api/v1/vehicle-mangements" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/vehicle-mangements"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "POST",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
POST api/v1/vehicle-mangements
api/v1/vehicle-mangements/{vehicle_mangement}
Example request:
curl -X GET \
-G "http://localhost/api/v1/vehicle-mangements/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/vehicle-mangements/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/vehicle-mangements/{vehicle_mangement}
api/v1/vehicle-mangements/{vehicle_mangement}
Example request:
curl -X PUT \
"http://localhost/api/v1/vehicle-mangements/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/vehicle-mangements/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "PUT",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
PUT api/v1/vehicle-mangements/{vehicle_mangement}
PATCH api/v1/vehicle-mangements/{vehicle_mangement}
api/v1/vehicle-mangements/{vehicle_mangement}
Example request:
curl -X DELETE \
"http://localhost/api/v1/vehicle-mangements/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/vehicle-mangements/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "DELETE",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
DELETE api/v1/vehicle-mangements/{vehicle_mangement}
api/v1/vehicle-models
Example request:
curl -X GET \
-G "http://localhost/api/v1/vehicle-models" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/vehicle-models"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/vehicle-models
api/v1/vehicle-models
Example request:
curl -X POST \
"http://localhost/api/v1/vehicle-models" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/vehicle-models"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "POST",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
POST api/v1/vehicle-models
api/v1/vehicle-models/{vehicle_model}
Example request:
curl -X GET \
-G "http://localhost/api/v1/vehicle-models/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/vehicle-models/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/vehicle-models/{vehicle_model}
api/v1/vehicle-models/{vehicle_model}
Example request:
curl -X PUT \
"http://localhost/api/v1/vehicle-models/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/vehicle-models/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "PUT",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
PUT api/v1/vehicle-models/{vehicle_model}
PATCH api/v1/vehicle-models/{vehicle_model}
api/v1/vehicle-models/{vehicle_model}
Example request:
curl -X DELETE \
"http://localhost/api/v1/vehicle-models/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/vehicle-models/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "DELETE",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
DELETE api/v1/vehicle-models/{vehicle_model}
api/v1/car-park-locations
Example request:
curl -X GET \
-G "http://localhost/api/v1/car-park-locations" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/car-park-locations"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/car-park-locations
api/v1/car-park-locations
Example request:
curl -X POST \
"http://localhost/api/v1/car-park-locations" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/car-park-locations"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "POST",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
POST api/v1/car-park-locations
api/v1/car-park-locations/{car_park_location}
Example request:
curl -X GET \
-G "http://localhost/api/v1/car-park-locations/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/car-park-locations/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/car-park-locations/{car_park_location}
api/v1/car-park-locations/{car_park_location}
Example request:
curl -X PUT \
"http://localhost/api/v1/car-park-locations/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/car-park-locations/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "PUT",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
PUT api/v1/car-park-locations/{car_park_location}
PATCH api/v1/car-park-locations/{car_park_location}
api/v1/car-park-locations/{car_park_location}
Example request:
curl -X DELETE \
"http://localhost/api/v1/car-park-locations/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/car-park-locations/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "DELETE",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
DELETE api/v1/car-park-locations/{car_park_location}
api/v1/carpark-logs
Example request:
curl -X GET \
-G "http://localhost/api/v1/carpark-logs" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/carpark-logs"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/carpark-logs
api/v1/carpark-logs
Example request:
curl -X POST \
"http://localhost/api/v1/carpark-logs" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/carpark-logs"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "POST",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
POST api/v1/carpark-logs
api/v1/carpark-logs/{carpark_log}
Example request:
curl -X GET \
-G "http://localhost/api/v1/carpark-logs/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/carpark-logs/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/carpark-logs/{carpark_log}
api/v1/carpark-logs/{carpark_log}
Example request:
curl -X PUT \
"http://localhost/api/v1/carpark-logs/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/carpark-logs/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "PUT",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
PUT api/v1/carpark-logs/{carpark_log}
PATCH api/v1/carpark-logs/{carpark_log}
api/v1/carpark-logs/{carpark_log}
Example request:
curl -X DELETE \
"http://localhost/api/v1/carpark-logs/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/carpark-logs/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "DELETE",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
DELETE api/v1/carpark-logs/{carpark_log}
api/v1/event-payments
Example request:
curl -X GET \
-G "http://localhost/api/v1/event-payments" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/event-payments"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/event-payments
api/v1/event-payments
Example request:
curl -X POST \
"http://localhost/api/v1/event-payments" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/event-payments"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "POST",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
POST api/v1/event-payments
api/v1/event-payments/{event_payment}
Example request:
curl -X GET \
-G "http://localhost/api/v1/event-payments/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/event-payments/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/event-payments/{event_payment}
api/v1/event-payments/{event_payment}
Example request:
curl -X PUT \
"http://localhost/api/v1/event-payments/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/event-payments/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "PUT",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
PUT api/v1/event-payments/{event_payment}
PATCH api/v1/event-payments/{event_payment}
api/v1/event-payments/{event_payment}
Example request:
curl -X DELETE \
"http://localhost/api/v1/event-payments/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/event-payments/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "DELETE",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
DELETE api/v1/event-payments/{event_payment}
api/v1/carpark-payments
Example request:
curl -X GET \
-G "http://localhost/api/v1/carpark-payments" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/carpark-payments"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/carpark-payments
api/v1/carpark-payments
Example request:
curl -X POST \
"http://localhost/api/v1/carpark-payments" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/carpark-payments"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "POST",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
POST api/v1/carpark-payments
api/v1/carpark-payments/{carpark_payment}
Example request:
curl -X GET \
-G "http://localhost/api/v1/carpark-payments/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/carpark-payments/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/carpark-payments/{carpark_payment}
api/v1/carpark-payments/{carpark_payment}
Example request:
curl -X PUT \
"http://localhost/api/v1/carpark-payments/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/carpark-payments/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "PUT",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
PUT api/v1/carpark-payments/{carpark_payment}
PATCH api/v1/carpark-payments/{carpark_payment}
api/v1/carpark-payments/{carpark_payment}
Example request:
curl -X DELETE \
"http://localhost/api/v1/carpark-payments/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/carpark-payments/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "DELETE",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
DELETE api/v1/carpark-payments/{carpark_payment}
api/v1/shop-rentals
Example request:
curl -X GET \
-G "http://localhost/api/v1/shop-rentals" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/shop-rentals"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/shop-rentals
api/v1/shop-rentals
Example request:
curl -X POST \
"http://localhost/api/v1/shop-rentals" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/shop-rentals"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "POST",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
POST api/v1/shop-rentals
api/v1/shop-rentals/{shop_rental}
Example request:
curl -X GET \
-G "http://localhost/api/v1/shop-rentals/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/shop-rentals/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/shop-rentals/{shop_rental}
api/v1/shop-rentals/{shop_rental}
Example request:
curl -X PUT \
"http://localhost/api/v1/shop-rentals/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/shop-rentals/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "PUT",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
PUT api/v1/shop-rentals/{shop_rental}
PATCH api/v1/shop-rentals/{shop_rental}
api/v1/shop-rentals/{shop_rental}
Example request:
curl -X DELETE \
"http://localhost/api/v1/shop-rentals/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/shop-rentals/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "DELETE",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
DELETE api/v1/shop-rentals/{shop_rental}
api/v1/mall-units
Example request:
curl -X GET \
-G "http://localhost/api/v1/mall-units" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/mall-units"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/mall-units
api/v1/mall-units
Example request:
curl -X POST \
"http://localhost/api/v1/mall-units" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/mall-units"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "POST",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
POST api/v1/mall-units
api/v1/mall-units/{mall_unit}
Example request:
curl -X GET \
-G "http://localhost/api/v1/mall-units/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/mall-units/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/mall-units/{mall_unit}
api/v1/mall-units/{mall_unit}
Example request:
curl -X PUT \
"http://localhost/api/v1/mall-units/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/mall-units/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "PUT",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
PUT api/v1/mall-units/{mall_unit}
PATCH api/v1/mall-units/{mall_unit}
api/v1/mall-units/{mall_unit}
Example request:
curl -X DELETE \
"http://localhost/api/v1/mall-units/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/mall-units/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "DELETE",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
DELETE api/v1/mall-units/{mall_unit}
api/v1/voucher-redeems
Example request:
curl -X GET \
-G "http://localhost/api/v1/voucher-redeems" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/voucher-redeems"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/voucher-redeems
api/v1/voucher-redeems
Example request:
curl -X POST \
"http://localhost/api/v1/voucher-redeems" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/voucher-redeems"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "POST",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
POST api/v1/voucher-redeems
api/v1/voucher-redeems/{voucher_redeem}
Example request:
curl -X GET \
-G "http://localhost/api/v1/voucher-redeems/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/voucher-redeems/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "GET",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
Example response (500):
{
"message": "Server Error"
}
HTTP Request
GET api/v1/voucher-redeems/{voucher_redeem}
api/v1/voucher-redeems/{voucher_redeem}
Example request:
curl -X PUT \
"http://localhost/api/v1/voucher-redeems/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/voucher-redeems/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "PUT",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
PUT api/v1/voucher-redeems/{voucher_redeem}
PATCH api/v1/voucher-redeems/{voucher_redeem}
api/v1/voucher-redeems/{voucher_redeem}
Example request:
curl -X DELETE \
"http://localhost/api/v1/voucher-redeems/1" \
-H "Content-Type: application/json" \
-H "Accept: application/json"
const url = new URL(
"http://localhost/api/v1/voucher-redeems/1"
);
let headers = {
"Content-Type": "application/json",
"Accept": "application/json",
};
fetch(url, {
method: "DELETE",
headers: headers,
})
.then(response => response.json())
.then(json => console.log(json));
HTTP Request
DELETE api/v1/voucher-redeems/{voucher_redeem}


Nokor Reach
"National Anthem" of Cambodia.
Verse I
Heavens protect the King. Send him happiness and glory. Us, your servants want you to reign O heir of the Sovereign Builders and rule the Khmer Land and make it high and filled with honor.
Greetings in Cambodia are more than just a way of saying "Hi". Known as " Sompeah", it involves holding your hands together as if praying and slightly bowing the head at the same time.
The
"Sompeah" is appropriate for both sexes. The height at which the hands are held depends on the social status
of the person being greeted. With equal social standing, the hands are held near the mouth.
When greeting someone of
higher social status or a monk, for instance, the hands are held higher, signifying greater respect, and
can be at the level of the nose or even the brow. The bow will also be correspondingly lower.
When greeting someone younger or of inferior social status, the hands are held at the level of the chin.
It is not necessary to "
Sompeah" taxi drivers or waiters in a restaurant or other workers in shops, etc.
After the initial introduction when you "
Sompeah", it is not necessary to repeat it each time you meet afterwards, especially with friends or colleagues
at work.
However you greet, you should not forget to smile -:)).
To the uninitiated, communicating verbally in Cambodia can be confusing and sometimes even frustrating. This is due
to the typical
non-confrontational and indirect approach that distinguishes the Cambodian communications style.
They will tell you what they think you want to hear rather than telling you the
"truth". This often results in getting contradictory information to the same question from different sources.
As always,
stay calm in such situations and do not aggravate them by pointing out the obvious.
Their motivation is not malicious and they do not intend to cause you harm; rather, they aim to be polite and do
not wish to bother you with their problems. The easiest way to ask questions then is to ask those that have a simple
yes/no answer and to try and piece together the information thus gleaned into a bigger picture.
Avoid the how/why questions that can cause discomfort and even irritability.
In the event of a conflict, do not try to resolve the situation directly with the other party concerned. Rather,
use a third party, an intermediary trusted by both sides, to resolve the conflict. The conflict itself may
never get mentioned. The aim is to re-establish congenial relations and once this has been achieved, it is better
not to bring up the contentious issue again.
The world is not as black or white for Cambodians as it is for many Westerners and therefore "yes" may not
always mean "yes" and "no" can also have different meanings, even "yes". Therefore, a clue to the correct interpretation
is often found when observing the body language rather than the actual words. While Cambodians always smile, their
smile can mean either pleasure or embarrassment, so other non-verbal communications, such as giggling nervously,
especially when bringing negative news, will assist in understanding the real message that is being communicated.
Unlike in the West, Cambodians tend to make indirect eye contact only in most social situations. When talking to a superior, like a manager for instance, direct eye contact is usually avoided. The same applies when speaking to an older person. However, you can follow their lead and if they look directly at you, it is fine to reciprocate but not to initiate. Conversely, when you are talking to a younger person or one of equal social standing, they will follow your lead as far as eye contact is concerned. It is common that when a man is talking to a woman, especially a much younger woman than the man, that the woman will tend to look at the ground and not at the person speaking.
Touch and Personal Space in Cambodia
It is recommended in a formal or business setting to always keep at arm's length from the next person, whether
male or female.
Physical contact between men and women should be avoided.
In a social setting, follow what the others do but keeping an arm's length distance is always safe. If you are meeting
with close friends of the same sex, physical contact, including hugging and holding hands, is acceptable and there
are no sexual connotations associated with such behaviour.
However, when meeting with people of the opposite sex, one should always be careful and remain at a safe distance.
physical contact, especially in public places, is deemed to be inappropriate and any displays of affection in public
should be avoided.


Search:
Welcome
00 : 00
|
00 : 00
No songs here yet
Add New Playlist
List Name:
Name must be less then 20 characters
List Image:
Image has to be a valid URL address
List Songs
Name:
URL:
Update Playlist
List Name:
Name must be less then 20 characters
List Image:
Image has to be a valid URL address
List Songs


This document is meant to capture the state of the discussion about modernising the tooling that supports the making of W3C standards.
Discussion is open to all. Pull requests are welcome, and the discussion takes place in the issues.
This is just informal work by an informal task force.
W3C is a heavily tooled organisation. We did Web tools long before they became ubiquitous and our tooling has earned us two decades of praise — which is probably more than can be said for any other part of the organisation.
But the Web has changed quite a fair bit since then. Today, tools abound. The Web is an application platform. Our users are happy using many third-party tools, and it is only natural that they will compare what they can find elsewhere to our offering, sometimes preferring other options.
This causes problems:
We need an energetic rethink of the W3C’s tooling in order to stay relevant to our users. That is what this document endeavours to provide.
I expect to proceed as follows:
This section is a categorised but unprioritised list of tools and services that W3C should deploy, as well as ideas on how to manage integration with third-party systems.
The heart of what we produce is specifications, as a manifestation of consensus. These already have some tooling support but it can be both further and better integrated or documented.
Great progress has already been made thanks to the Echidna system that can publish Working Drafts in an automated manner, as often as needed. This can effectively make TR documents and Editor’s Drafts indistinguishable.
There are, however, still a number of exceptions to the documents that Echidna can publish, and a number of rough edges to the system itself and its documentation. It needs iterative improvements.
It will also need to expose a stream of notifications (as described further below) for the documents it publishes.
While the door needs to remain open for alternatives that our users may wish to avail themselves of, the expected default location for specifications (and any other W3C-related repository) should be GitHub, preferably under the w3c organisation. This has several implications.
We need to document the proper usage of GitHub for such work. Some of our users who are not from the Web development community can at times struggle with the site or with common conventions. Team resources need to be dedicated to supporting users of GitHub. A specific collaboration with GitHub may be considered if needed.
Better even than documentation, which is often ignored, a tool that enables the Team to set up new repositories correctly, within conventions, and given a few specific options would be most useful.
Groups regularly need to add new contributors to their repositories (or, on occasion, to remove them); which requires administrative powers. Sadly, the granularity of the ACL system there does not allow us to grant that power to non-Team participants, which in turn means that the Team needs to be called upon for everyday business. An interface to grant our users the ability to maintain a repository’s collaborators without involving the Team would be a time-saver. The ability to activate Travis without admin powers would also come in handy and save the Team some time.
 In such an event, we must have all the useful data at hand and, if possible, be able to exploit it elsewhere. Git certainly makes it easy to keep repository data — it only needs be cloned.
But GitHub also has a lot of useful information that isn’t in git: issues, discussions, etc. We also need to keep that around. For that, we need a GitHub backup tool. This would use git’s naturally distributed nature in conjunction with the ability to receive organisation-wide hooks (and use the API to grab everything) in order to store all the useful information. Ideally all work would happen under the w3c organisation but the tool ought to be flexible enough to account for there being work elsewhere.
The hook system should also be used so as to produce a stream of notifications that can later be integrated into the dashboard.
This also entail that both dev.w3
and dvcs.w3
should be phased
out. No new repository should be created there and no new user granted access. Projects
that are still active there should be moved (and redirected). Obviously the content
already published that no one is touching will likely need to stay there, but it should
essentially be a static, frozen archive of old work.
We regularly hear complaints about the usability of our specification styles. Several projects were started to radically improve them, but petered out.
At the same time, they cannot be changed radically overnight. Older specifications cannot be broken through style changes and we shouldn’t throw away the brand recognition that comes with the current style.
The solution is to open up the management of these styles and drive the project through largely small, incremental updates to the stylesheets. A repository for the styles should be created and we should start accepting pull requests. At first a clean-up of the current code ought to be carried out. Then, regular releases ought to be made based on contributions.
The Web is no longer a static medium that is essentially fluid print brought to the screen. Documents today can work with the user interactively. So far we have only very sporadically made use of these capabilities, when in fact they could greatly enhance the usage of our primary products.
A common library should be developed to provide basic functionality across all specifications. This would include:
Like the styling project, this can easily start small and humble, and progressively grow into a highly useful system thanks to contributions.
The new PubRules system (Specberus) is a welcome improvement in the toolbox. It still needs some UI fixes and should be moved to a location not intended to make it impossible to find but overall it should soon be able to replace the previous instantiation.
We should, however, think beyond specification validation. As things stand today, it is extremely hard to get information out of our documents. Even when they are correct, they are all different. The RDF export is a very partial view and borderline unusable. The data that is extracted into W3C’s systems cannot be obtained, and is partial as well. Yet so much can be done with this information.
We need to progressively refine the components that make up a specification and to rethink them using modern HTML constructs for document semantics and metadata. Step by step we need to start unifying these constructs across the board (having tools produce them and enforcing them through PubRules). Document structure and metadata needs to become eventually regular enough that TR can be used as an API.
We have quality specification production tools and most specifications today make use of them. It is worth thinking about how, as a common ecosystem, they can be improved.
One aspect in which they can be improved is to bring their source formats in line wherever it makes sense (and isn’t disruptive). The end goal here is that contributors to specifications who move between groups should as much as possible find themselves able to switch between tools as easily as possible.
This, naturally, should not be done at the cost of innovation in those tools, but it surely can be done for some of the common, well-understood aspects.
The Web platform is increasingly described by a large mesh of specifications that reference one another. Currently, this is done relatively poorly overall. There are several methods in use:
Ideally, all definitions from all specifications should be globally available. This would make it possible to simply reference them in a specification tool source format and get the correct link and reference handled. It would enable the generation of glossaries (we urgently need to phase out the current one). We could expose a searchable interface that would make it possible for people to find which specification defines what, and which make use of what concept or construct (something that would prove invaluable in coordination).
It is extremely common today to replace examples in documentation with live ones that can be edited and rendered using one of the many services that provide such functionality.
While it is probably not acceptable to inject code from a third-party service into our specifications, there exist reusable components that would enable use to make the examples in our specifications hackable. This would have tremendous value for developers trying to learn and understand the technology.
Specref is the database of bibliographical references that specifications rely upon. It has been through several iterations and is generally considered good, but it can be improved.
It is currently managed by Tobie, it could be brought under W3C management.
It could use a front-end for adding resources and a few other niceties to integrate it better with the W3C tool suite.
Some specification issues (that are not about the actual prose content) can sometimes exist for embarrassingly long periods of time before anyone notices. Sometimes they are noticed after a document is finalised. Or they are raised at the worst moment, all at once when the editor is busy doing something else.
Developers use continuous integration to make sure that there is a constant pressure towards quality rather than a last-minute rush — so should editors. There have been experiments around this (using Travis’ integration with GitHub), they should be expanded and systematised.
Ideally, an editor should be able to, at the click of a button, have the proper Travis integration (and dependencies) installed into the specification’s repository and deployed for immediate usage. This could even be made the default at repository creation if it is know that it will contain a specification.
Several different tools can be called up on for quality checking; since they can be used on their own they are listed separately below and in the «Developer Tools» section.
We have an existing WebIDL Checker. It needs to be integrated into the quality workflow (arguably into Specberus as well as into the linting options of specification tools), exist with guarantees of maintenance, documentation, and made easy to find.
We have existing tools (that almost no one knows about) that can read a specification and validate that its references (at least to W3C or IETF documents) are up to date with the latest versions of those documents: the references checker and the IETF references checker.
While specification production tools, by building atop SpecRef, have largely removed the need for these, some specifications are produced by hand and some have local bibliographies. They should be part of automated checking.
W3C actually exposes a Spell checker tool (that can work with HTML). It is unclear that this could be integrated into automated checking (given the number of justifiable exceptions) but it could perhaps be made more prominent (or, if found not to be useful, retired).
W3C currently offers an HTML Diff service which is sometimes used to see changes to documents.
It is a common request to find out what has changed between two versions of a specification, in fact producing a diff seems slated to be part of the new errata management approach that the AB is investigating.
This should be made automatic, and possibly specialised. Right now the HTML diff tool will produce as output a complete document, which can make the differences hard to find (e.g. a paragraph change in the whole HTML specification). It can also include a lot of spurious differences (for instance if a section was added at the beginning, all the section numbers come out as changes).
This tool could be specialised for specifications in such a way that ignorable differences would be ignored. Also, an affordance could be exposed in specifications offering to see a diff between the version being looked at and any other version of this document.
Supporting WYSIWYG editing for specifications could help improve collaboration and contributions from people who might know HTML but are not necessarily versed in the specific formalism of a given specification tool.
While such a tool would be interesting and valuable, it is a long and complex project to put together, and likely not a priority.
Perhaps the most common complaint about the W3C’s tooling setup, which is only made worse by spreading work across a broad set of external services, is that there are too many places at which to track things, often in very different ways.
In addition to tracking information, taking action within the system also involves remembering where different parts are. There are several pages listing services (e.g. the Member page, the AC page, the Editors’ page) but they can prove overwhelming, especially since they often have content that is out of date. They are also very generic: most users don’t need to know everything that they contain.
This leads to three high-level requirements for a modern system, from its users’s point of view:
This translates to a specific design for the various moving parts of the system.
There are many sources of data that can become involved in the dashboard. In order to keep them manageable, we need a specialised component that can provide a consistent interface to them.
This service is a relatively simple shell around various data streams. It can be
configured to poll a resource at regular intervals (e.g. retrieve and process an RSS
feed), or on the contrary to expose a hook for pushed information (e.g. we can set up
a GitHub hook calling it for all events in the w3c
organisation there).
Ideally we could also collect data from mailing lists, for instance to produce a feed of
browser vendors’ intents to implement/deprecate.
Each of its plugins knows how to obtain data and store it in a unified manner. They can easily be configured (e.g. to add RSS feeds, to receive GitHub notifications from other repositories).
This mass of data can then be returned to queries that essentially involve two filters: which feeds the user is interested in, and a date-time cut-off so that one can ask only for what has happened since one last visited.
Additionally, a WebSockets interface can be made available so that dashboard users can get notifications in real time in the UI.
The dashboard itself is nothing but a container of smaller widgets which can be configured, added, or removed by each user. In order to be fully generic, we need to ensure that it remains extremely simple both in its own functionality and in the interface it exposes to widgets.
Widgets can be used as part of an overview grid, or can take over the whole screen when they need more real estate.
It is very important that it be possible for independent contributors to develop widgets
separately, that can then become available through the dashboard (after W3C approval, we
can’t automatically deploy third-part code). Widgets can expect to run in insulated
iframe
s and to communicate with the dashboard to access whatever
information they need through messaging.
W3C’s own applications are expected to transition to being exposed as widgets. The general principle at work is that services should be made available as APIs, and exposed to users through widgets. With this in mind widgets can use a common stylesheet and common scripting libraries to help support greater coherence and fluidity in interaction.
Another tool that can plug into the unified feed is a notifier. Users can opt into being notified of various events by email (though, you guessed it, a dashboard widget).
The notifier simply receives the unified data feed, and for each event finds if there are people who want to be notified of it. If so, they get an email.
This section covers tools that are in common use for coordination and communication inside groups and the broader community.
IRC is relatively operational and it is highly programmable. Because of this, it would be hard to replace with other more modern solutions such as Slack or gitter. It is, however, often unknown to the younger generation or in fact more generally to people not strongly steeped in the open source culture of the past twenty years. As such, an improved Web interface would be desirable (the current one is serviceable, but could do with some freshening). One potential option here would be Shout. It is a client-server combo with a rich interface, and is entirely implemented in JS. Amongst its advantages are that it can remain connected to IRC even when you close your browser, it supports connecting as the same user through multiple channels at once, and has a responsive layout that is well-suited to usage on a smartphone.
IRC logging could, however, be improved. RRSAgent
has its value for the
specific case of capturing minutes in a manner that is easily reused by other tools, but
as a general-purpose logger we can do better. Too many channels are simply not logged at
all — even though much work takes places over IRC — and when they are
RRSAgent
logs are then extremely hard to find, lost in dated-space never to
be retrieved again.
A general-purpose channel logger bot need not be complicated. In my experience, people are satisfied with Krijn Hoetmer’s setup. Its limitations are largely that it requires getting agreement from Krijn in order to get something logged, and it wouldn’t scale to the many channels we would want to log.
A single service at which all chat logs can be located would therefore be needed. It does not require bells and whistles, but it needs to support continuous logging, finding channels, and search.
While the mailing list service itself is largely beyond reproach, the interface to our archives is now one of the more decried parts of our offering. While a number of the complaints may be exaggerated, it is certainly true that it could do with improvements in both style and usability.
A project that is commonly cited as a huge improvement over what existed previously is https://esdiscuss.org/. It is not perfect, and the source can probably not be reused as is. Its fundamental architecture is sound however: convert email to JSON and expose those for other services to build upon. Given the size of the W3C archive and its daily volume, this would not be a minor undertaking — it is likely better to test-drive the idea on a small set of lists.
People have also complained about the user experience of signing up to our lists. A user interface allowing people who have an account (either with us, or with a third-party service that we can authenticate against) to use that to subscribe directly (without the email ping-pong) and to immediately accept archival would help our community as well.
Forums have overtaken mailing lists in terms of popularity for online discussion. Groups would certainly benefit from being able to rely on those for at least some of their work.
This aspect is already covered by our Discourse installation, which is being moved to WebPlatform.
Etherpads are commonly used to take shared notes, which could be useful for minutes in some groups, but is also particularly useful during brainstorming sessions when a group of people wishes to collectively.
Because W3C does not provide its own pads, people routinely use those available from Mozilla or the MIT. This results in information being scattered far and wide.
There are numerous pad implementations, deploying this is largely a case of picking one that we like. A good pad should support:
Bonus points if there is a way for the pad to tie into our user system such that people who join a pad to edit automatically have their names set up.
This section is more of an open question than anything else. Some teams use systems like Trello to organise their work, basically through collaborative todo lists. I am not aware of groups doing the same, but I would be interested in hearing about usage or interest.
Three major bug trackers are in use in W3C groups: Bugzilla, Tracker, and GitHub Issues.
Bugzilla is the most powerful and flexible of the three, but it is extremely slow, its interface is clunky, and automating it through external tools generally requires scraping its HTML output. (There does exist a way of enable XML-RPC into it, but, well, it’s XML-RPC.) It also likes to send email; a lot.
Tracker is the only option with IRC integration (through trackbot
) and it
also supports action items in addition to issues. It knows about our users, IRC nicks,
and working groups, which can prove useful. However its interface is also clunky and
setting up a new instance for a given project requires intervention.
GitHub issues are by far the easiest to use. They have nice conversational capabilities. However they’re external to W3C and they don’t know about groups and the such.
I am making the following perhaps radical recommendations:
If we cannot unify our issues handling, then at the very least the various services will need to be plugged into the Unified Feeds system so as to be visible in the dashboard.
Wikis are annoying. Idiosyncratic syntax, little to no notification, practically nothing in the way of actual collaboration (people might work on the same document but don’t really talk, certainly not in practice). W3C makes the problem worse by having uncountable different wikis spread out all over the place. It is already hard to find information in one wiki; when one has to remember which wiki it was in things go awry.
That said, wikis do have their die-hard lovers and they will likely remain in use. I recommend:
Even with a freshened up and more organised setup, making use of all our tools and the external tools they rely on can be challenging.
It is absolutely necessary that there exist clear and well-identified guidelines for operating with these tools. Ideally, short enough that people actually read and memorise them.
Where possible, we should provide template configurations (e.g. the typical GitHub repository for a specification) that can easily be reused.
Developers use W3C technology a lot, and some of our services. Yet we make little use of this interaction in order to build a relationship that we badly need. There is currently a lost opportunity to turn these useful (and, in some cases, used) tools into goodwill and good feedback. We are probably not getting as many donations as we could from these.
We don’t offer an integrated view on the tools that we make available to developers. There is ongoing work in exposing this through a simple landing page. The W3C developer tools page aims to provide developers with a summary of all our open source tools and links to helpful resources. It is currently in development, you can contribute to it in its Github repository.
The Link Checker is one of the more useful resources that W3C exposes, but it is woefully antiquated.
While not a top priority, it would be useful to rebuild it with modern technology and a modern interface. It should be relatively straightforward to make it a fair bit faster, if only by adding some caching.
These are solid tools and do not need much work. We should stop calling the new HTML validator «experimental» and we should retire anything to do with the old one. We can sprinkle a little bit of nice design on the output, and we could document some of the APIs better, but nothing radical beyond some cleanup. It would be nice to ensure that the validators are available as libraries (outside Java), for instance as Gulp/Grunt packages that can easily integrate with common build systems for Web applications.
It has been suggested that it would be valuable to rewrite these two validators in a language more likely to be reusable by Web developers, namely JavaScript. While this may be true, it can only be a long-term, low-priority objective.
As in the previous section, this is good and operational. It could use being promoted more.
We currently do not provide A11Y checking as a service, and arguments have been made that this would be a bad idea as there are aspects that cannot be tested. However, there are projects appearing that are beginning to offer this service (e.g. Tenon). We should take the time to think about our strategy here.
The MobileOK checker is a potentially valuable tool, but it needs an update. Validating XHTML Basic 1.1 or ensuring that a page is under 20K might not work that well with many modern uses of mobile. (Testing a site that I know works well on today’s devices scored it 29%.)
W3C is currently working on a new, open source version of the Mobile Checker. It is expected to be released soon.
While not strictly a tool in itself, the core w3c.org
site is a big part of
what our users interact with, and improving it would help with many aspects of their work,
notably not driving them to third parties when there is no need to.
CVS makes using the core site inordinately painful. I for one avoid publishing anything
there unless I really have to; in several cases I have set up an .htaccess
proxy from a subdirectory just so I would never need to touch it again. I know others
have similar experiences.
The massive size of the site also causes issues of its own. For instance, the recent discussion on upgrading to HTTPS across the board revealed just how hard it is to evolve it.
The site cannot be moved to a more modern system wholesale, but likely it does not need to.
W3C invented conventions before conventions existed. In some cases, those became conventions only within W3C.
Overview.html
is one of those. The norm is index.html
. It
should become the norm on all new Web setups at W3C, and where possible
Overview.html
ought to be retired. It may seem like a small thing but it is
a regular annoyance.
Dated space, of course, needs to die. There are exact seven people in the world who find it usable, six of which are on the Team (the other one being DanC). It is maddening, distracting, confusing, and in violation of every single URL design best practice in use anywhere outside the Consortium’s walls.
Again, dormant content in dated space can stay there. But content that is in any way, manner, or form still in active use should never be in dated space. A non-exhaustive list of content that should never be allowed to reside in dated space includes:
Our testing infrastructure has become increasingly important. In general it is much more recent that the rest of our tools and so less in need of modernising. But the setup can nevertheless be improved.
The Web Platform Tests (WPT) system relies on a code-review engine known as Critic. It ties into GitHub pull requests and is much more powerful than GitHub’s built-in code review.
Most groups likely do not need Critic, but for more complex code such as that which is found in tests it is a very welcome improvement.
The current Critic instance is run by James Graham on his personal server, and without HTTPS. While that is not the end of the world, given how central Critic is to the testing work it would be much better to host it on W3C.
We have an existing system that allows people to run the (automated parts of the) test suite continuously, without human intervention. Right now it has only been adopted by a couple of browser vendors.
We should take this to the next level. We can integrate with SauceLabs (with whom we have a free account) and systematically run the entire test suite against the full set of browsers that they expose. This should allow us to gather very detailed statistics about which parts of the platform work where. It has the added advantage that it can help detect some broken tests.
Finding out how much of a given specification is covered by the test suite is a hard, manual, and error-prone process. It cannot be perfectly automated, but it can be improved.
This also involves figuring out how to identify that a given test is related to part of a specification.
These tasks are not trivial and highly heuristic, but there has been previous work. It needs to be assessed and integrated.
Once we have testing results for many implementations, we should publish them in a manner that is useful to developers. Such information is invaluable. The interface does not require much in terms of complexity.
The testing project involves close collaborations between parties that are not all on the Team, yet develop the major parts of the system. While the service should be run on W3C resources, it would not be efficient to gate deployment to Team members only.
It would therefore be very valuable to enable SSH access to a select group of contributors so that they could help curate the testing services.
All new tools must be developed in a such a manner that they are automatically deployed to production whenever a change is merged to master. It is the only sane way to maintain a product.
These are services that can be reused by other parts of the ecosystem.
Many tools and services will expose features that are user-dependent. It is not appropriate for those to implement their own user database duplicating W3C’s. It would also be a shame if they had to make use of third-party sign-on infrastructure (which was the case with Discourse).
Which exact solution is selected here is of relatively little importance, but it does need to support typical modern Web application authentication workflows. GitHub’s OAuth implementation may provide a good example.
It should also be possible to retrieve useful information about a user, such as their GitHub ID.
The various tools to be developed may commonly require search functionality. Given the spread of W3C’s content, this can quickly become required. For instance, an Etherpad service might request indexing for its pads (using its own ACL knowledge), a chat logging service might index the logs, etc.
One potential candidate, that can double as a JSON document store and therefore be usable for application data storage, is Elastic Search.
XXX
XXX
XXX
The following people have provided useful input into this document.


Module: Sidekiq::Worker::ClassMethods
- Defined in:
- lib/sidekiq_unique_jobs/testing.rb
Overview
Adds class methods to Sidekiq::Worker
Instance Method Summary collapse
-
#clear ⇒ Object
Clears the jobs for this worker and removes all locks.
-
#use_options(tmp_config = {}) ⇒ Object
Temporarily turn a workers sidekiq_options into something different.
Instance Method Details
#clear ⇒ Object
Clears the jobs for this worker and removes all locks
64 65 66 67 68 69 70 71 |
# File 'lib/sidekiq_unique_jobs/testing.rb', line 64 def clear jobs.each do |job| SidekiqUniqueJobs::Unlockable.unlock(job) end Sidekiq::Queues[queue].clear jobs.clear end |
#use_options(tmp_config = {}) ⇒ Object
Note:
this method will restore the original configuration after yielding
Temporarily turn a workers sidekiq_options into something different
51 52 53 54 55 56 57 58 59 |
# File 'lib/sidekiq_unique_jobs/testing.rb', line 51 def (tmp_config = {}) = .dup (.merge(tmp_config)) yield ensure self. = Sidekiq::DEFAULT_WORKER_OPTIONS () end |


Namespace UnityExt.Core.IO
Classes
Base64Serializer
Class that extends the base serializer to handle base64 read/write
BitStream
Class that abstract bitwise manipulation and storage.
JSONSerializer
Class that extends the base serializer to handle json read/write
ObjectParser
Class that implements C# object's internal structure navigation.
ObjectParserTokenLog
Auxiliary class that outputs human readable information about an object being parsed.
ObjectReader
Class that implements the read/write of C# objects into streams.
ObjectSerializer
Class that extends the base serializer to handle objects read/write
ObjectWriter
Class that implements the read/write of C# objects into streams.
Parse
Class that wraps numerical parsing from and to the general C# types, aiming for less to no GC and speed.
ParseSettings
Parsing settings to guide the object parser.
SerializableField
Attribute to tag a field/property as serializable
Serializer
Base Class for all serialization operations using UnityEx features. Serializers use the 'Activity' system to either run sync or async (using threads).
Structs
Parse.UIntToFloat
Parse.ULongToDouble
Interfaces
IObjectParserTokenHandler
Interface that describes an object to handle each node visit during an object graph traversal.
Enums
SerializerAttrib
Class that wraps attribute bits for serialization.
SerializerMode
Operation Mode


[gecode-users] Expr() in GECODE
Christian Schulte
cschulte at kth.se
Tue Sep 3 09:46:03 CEST 2013
Hi Zichen,
Yes, you are right the minimodeling layer (that is expr()) should do a
better job at avoiding posting reified constraints if it is not necessary
(as you did in your own improved variants).
I'll write that down for a future release.
Let me try to explain what happens: with your first expression you create
three Boolean variables b1, b2, b3 and then three reified propagators:
!_A[i] <=> b1
(x[index] != val) <=> b2
b1 || b2 = b3
and expr() returns b3. Unfortunately the constraints might stay on even
though the disjunction is already satisified (which it is in you example).
Embarrasingly enough, I am the co-author of a paper (done using Gecode) that
explains the problem and shows how to eliminate these constraints but it has
not yet made it into Gecode:
http://web.it.kth.se/~cschulte/paper.php?id=SchulteStuckey:PPDP:2008
I hope that helps.
Best
Christian
--
Christian Schulte, Professor of Computer Science, KTH,
www.ict.kth.se/~cschulte/
From: users-bounces at gecode.org [mailto:users-bounces at gecode.org] On Behalf
Of Zhu Zichen's cse
Sent: Tuesday, September 03, 2013 4:38 AM
To: users at gecode.org
Subject: [gecode-users] Expr() in GECODE
Hi,
I have a question.
For GECODE,
When I use expressions:
BoolVar sofar = expr( home,( !_A[i] || x[index] != val ));// where
_A[i] is a BoolVar, and x is IntVarArray, index and val are integer.
If I rewrite it as:
if(_A[i].one())
sofar = expr( home, x[index] != val);
else
sofar = expr( home,( !_A[i] || x[index] != val));
There will be a great improvement on runtime, say 40%.
If I rewrite it as:
if(_A[i].one())
x[index].nq(val);
else
sofar = expr( home,( !_A[i] || x[index] != val));
There will be another improvement on the latest one for runtime, say 30%.
For ILOG,
IlcConstraint sofar = (! _A[i]) || x[index] != val ) ;
Rewrite as:
if(_A[i].isTrue()==IlcTrue)
sofar = x[index] != val;
else
sofar = (! _A[i]) || x[index] != val ) ;
Running times of the above two methods are the same.
Is this because the "inefficient" of expr() to handle Boolean expressions
and relations in GECODE?
Thanks!
Zichen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gecode.org/pipermail/users/attachments/20130903/bb5606dc/attachment.html>
More information about the users
mailing list


Digging Simulator 1989 is a basic recreation/prequel of my classic, boring and practical joke game Digging Simulator 2015 for the original Nintendo GameBoy using the GBDK library and written in C.
Digging Sim is an actual GameBoy game, meaning it can run on a real system using either an Everdrive or other similar cartridge solutions, as well as other third-party systems and emulators.
A dream of mine since becoming a programmer has been to create my own GameBoy game, and in January 2022, that dream became a reality with the creation of Digging Simulator 1989.
The development of Digging Sim started with the discovery of GBDK and an introduction from a Modern Vintage Gamer YouTube video (More on that in my blog). He showed me how much easier the development process for GameBoy can be using the GBDK framework, so I decided what better "Hello World" learning project than a remake of my classic boring and practical joke game Digging Simulator 2015!
There were several goals for Digging Sim, starting with the desire to expand my programming knowledge and develop something outside the scope of Unity once again. A bonus to changing the programming scope was the opportunity to use the C language, something I hadn't found a reason to develop in yet. So a good time as ever to try something I always wanted to experience, especially the discovery of differences between C and more modern languages like C++ and C#. But the main goal of this project was, of course, creating my first GameBoy title, though the problem with this being the desire was I had no actual idea or direction for what kind of game I wanted to develop. So that brings me to goal 4, the recreation of Digging Simulator 2015.
The reason I chose to recreate Digging Sim for my introduction into GameBoy development and GBDK was that the idea of this game was relatively straightforward, pixel graphics and very simple logic. It was the perfect "Hello World" experience, allowing me to learn the framework and limitations of the GameBoy hardware with the added bonus of something more to show off on this website than just a small blog post!
Over the years, there have been several moments I have looked into the possibility of creating my own game for the GameBoy, sadly my lack of confidence always scared me away. But projects like An Infestation have been great for my confidence in my programming skills and especially good at teaching me to go with my gut and create what I want! So that would be one of my first lessons learnt, and an addition to the main lesson of An Infestation's development.
Another obvious lesson, based on my personal accomplishments above, was learning about the limitation of a system or hardware. Most of my game development experience up until this point has been in Unity, and like most modern techniques, the sky is the limit! You feel like you can create anything your heart desires, but that is not the case for older systems or hardware and something I have always wanted to experience for myself. I think this kind of experience will be incredibly valuable in the future, especially with the release of the highly anticipated PlayDate, which I plan to play around within development when mine arrives!
The final lesson (and goal for this year (2022)) is to get my hands dirty in development more often. The creation of this game has been inspirational, and I want that feeling more much often!
Digging Simulator 1989 is a basic recreation/prequel of my classic, boring and practical joke game Digging Simulator 2015 for the original Nintendo GameBoy using the GBDK library and written in C.
Digging Sim is an actual GameBoy game, meaning it can run on a real system using either an Everdrive or other similar cartridge solutions, as well as other third-party systems and emulators.


We are pleased to announce #Utrum web portal will be launched on 22 August 2019, 3 PM EST. Utrum is a one stop center for your crypto research based on unique community consensus. @KomodoPlatform @Chainzillaio @PirateChain $OOT $KMD #CryptoNews #Crypto #cryptocurrency


Overview
A simple React.js application that explored the use of react hooks, effects, and props while replicating the rock paper scissors game. The use of css animations were involved all the while learning SCSS. The background is blurred and dynamic.
Tools
HTML/CSS, Javascript, React.js, Affinity Designer, Webstorm


The margin
theme variation can be applied to both horizontal and vertical layout.
When applying, the CSS margin
property is set on host element.
The property value is specified by the Lumo theme.
Note: The same behavior can achieved by setting corresponding property in CSS.
The padding
theme variation can be applied to both horizontal and vertical layout.
When applying, the CSS padding
property is set on host element.
The property value is specified by the Lumo theme.
Note: The same behavior can achieved by setting corresponding property in CSS.
The spacing
theme variation can be applied to both horizontal and vertical layout.
When applying, the CSS margin
property is set on child elements.
The property value is specified by the Lumo theme.
Note: The same behavior can achieved by setting corresponding property in CSS,
but this theme also attaches ::before
pseudo element to compensate the first item margin.
So please keep in mind that justify-content
CSS property is not supposed to work with
spacing
theme, and if you want to handle alignment yourself, you should remove the theme and use CSS.
The spacing
theme comes with small and large variations:
spacing-xs
for an extra small space between items;spacing-s
for a small space between items;spacing-l
for a large small space between items;spacing-xl
for an extra large space between items.


After I finished my project. My CSS file became a huge, ungainly mess. One front-end methodology would have saved me a lot of pain and cleaned up my code: BEM (Block Element Modifier), a highly useful, powerful, and simple naming convention that makes your front-end code easier to read and understand, easier to work with, easier to scale, more robust and explicit, and a lot more strict. But, in a professional setting, BEM (or the alternative methodology of your choice) becomes indispensable for efficiency and clarity of code — especially when paired with SASS. BEM isn’t the only naming methodology out there, but it’s the one we use here at Tajawal. So, what do we like about it?
- BEM makes collaboration easy : Diving into another developer’s project or developing a project with a team has its challenges. People get comfortable in their own naming conventions for CSS selectors, which may be quite different than your own. Using BEM removes this issue. It provides a clear architecture and recognizable terminology for use across projects and among developers.
- It’s modular : Block styles are never dependent on other elements on a page, so you will never experience problems from cascading. You also get the ability to transfer blocks from your finished projects to new ones.
- Reusability : Composing independent blocks in different ways, and reusing them intelligently, reduces the amount of CSS code that you will have to maintain. With a set of style guidelines in place, you can build a library of blocks, making your CSS super effective.
- Structure: BEM methodology gives your CSS code a solid structure that remains simple and easy to understand.
Basics
BEM describes relationships between the items in our HTML markup.
-
Blocks: Blocks describe a standalone, high-level object on the page — in other words — a page component. While blocks can be nested and interact with each other, semantically they remain equal; there is no precedence or hierarchy. Holistic entities without DOM representation (such as controllers or models) can be blocks as well.
-
Elements: Parts of a block and have no standalone meaning. Any element is semantically tied to its block. They depend on their parent block for meaning, and can’t be moved around the page arbitrarily.
-
Modifiers: Flags on blocks or elements. Use them to change appearance, behavior or state. Let’s say we want the block__elem to be styled differently to highlight it. We could add a class like .block__elem--highlight to make those style changes.
Gnereral Rules
Here are some general principles that help guide BEM methodology
-
Stay flat: Just because your BEM naming describes blocks’ and elements’ relationships to each other doesn’t mean it’s a literal description of the DOM tree. You should never have a class name describing a grandchild element like this: .block__element__element
-
Avoid high specificity: One of the values of BEM is that it (mostly) keeps everything at the same level of specificity (no IDs, no use of HTML elements in CSS selectors like .class > ul). Ask yourself, how can I target an element without increasing specificity?
-
Maintain modularity: Always question whether nested blocks are independent of their parent containers. If they are, they can also be named independently of the parent containers.


PART II. PLANNING COORDINATION AND IMPLEMENTATION
Note
Part heading reenacted. L 1991, c 76, part of §1.
§226-51 Purpose. The purpose of this part is to establish a statewide planning system to coordinate and guide all major state and county activities and to implement the overall theme, goals, objectives, policies, and priority guidelines. [L 1978, c 100, pt of §2; am L 1984, c 236, §3; ree L 1991, c 76, pt of §1]


§461-17 Penalties. Any person violating this chapter or the rules duly prescribed by the board of pharmacy shall be fined not more than $500, or imprisoned not more than six months, or both. [L 1949, c 175, pt of §1; RL 1955, §71-17; HRS §461-17; am L 1983, c 23, §6]
Cross References
Classification of offense and authorized punishment, see §§701-107, 706-640, and 706-663.


Note: This example shows an outcome implementation procedure that describes how a large organization with significant web resources and more complicated web development processes could meaningfully implement the COGA Usable guidance. Time investment, define roles, and evaluation requirements are higher in this example, but are meant to be achievable for organizations of the target size.
Note: All content here is provide for example purposes only. Only the overall structure is meant for review.
| Name | Provide help and support for users with cognitive or learning disabilities. |
|---|---|
| Author | Example org |
| Review record | {information about the development and review process of the procedure} |
| Approval record | {information about formal approvals of this procedure} |
| Context | Organizations with more than 25 Full Time Equivalent (FTE) of total web development resources. |
| Scope | This applies to help and support related to Company X's Flagship Product. |
| Supports outcome(s) | Users can obtain help and support |
| Validity assertion | This procedure describes responsibilities for several roles in the organization, with the intention to build the guidance meaningfully into the organization’s work process. |
Developers in all roles use cognitive accessibility guidance to Provide Help and Support published as a supplement to WCAG 2.
Note: The definition of "use" could change based on the conformance level. For lower levels of conformance, we're primary looking at the proedures an organization has put in place to measure a protocol. These controls help assure users that guidance is being followed, though outputs are not normally measured at this level. At higher conformance levels the output of the procedure implementation will be measured with varying degrees of rigour depending on the level of conformance claimed. All protocols will have evaluation measures. All results of evaluations must be publicy documented at higher conformance levels. At lower conformance levels, documentation of procedures is sufficent.
Note: For a large organization, the procedures would be more specific and comprehensive about steps needed. This is just a starter example to differentiate from the small org example.
All roles read the accessibility guidance.
Management oversees organizational commitment to implementing this outcome implementation procedure. Initially this is expected to take .4 FTE until all requirements for initial implementation have been met. .025 FTE is expected for ongoing supervision and support.
Web department managers develop requirements and strategies for implementation, determining what additions and changes are needed on the site, and setting requirements for design and placement of solutions. Initially this is expected to take .4 FTE for each manager until all requirements for initial implementation have been met. .1 FTE is expected for ongoing supervision and support.
@@ Initially this is expected to take .8 FTE for each designer until all requirements for initial implementation have been met. .05 FTE is expected for ongoing support.
@@ .05 FTE for each coder
The accessibility department coordinates with management in the strategy for following these procedures, evaluates progress and barriers, and provides relevant information on the company’s accessibility statement. .1 FTE during coordination points.
The risk management department monitors overall progress and effectiveness reports in order to be able to respond to complaints quickly and effectively. .05 FTE during coordination points.
The report describing attention points serves as a milestone that the procedure has been implemented.
Frequency and duration of meetings related to the task are tracked for a given annual period. Frequency should be 12 / year, duration should be 1 hour / meeting. The score is the actual vs benchmark ratio.
We use the following evaluation procedures in the newly-released Help and Support Evaluation Procedure published as a companion to the Making Contnet Usable Protocol:
When implementation is demonstrated with the initial report, the relevant outcomes score at the lowest level of conformance.
Note: higher conformance levels would require additional evaluation of the implementation procedures, beyond the baseline.


food
Places (
38
)
Cost
$5 - $50
Distance
1 miles - 10 miles
Type
All (Takeout & Restaurant)
Takeout
Restaurant
Mood
All
Sandwiches
Burgers
Seafood
Mexican
Chicken
Asian
Sushi
Noodles
Pizza
BBQ
Italian
Mediterranean
Cajun
Steak
Indian


⌛
Starting app initialization.
Loading data.
Validating data.
✔
Initialization complete.
⌛
Waiting for rooms to load.
Loading rooms.
✔
Rooms completed.
⌛
Waiting for models to load.
Loading models.
✔
Models completed.
⌛
Waiting for provisionable systems to load.
Loading provisionable systems.
✔
Provisionable systems completed.
⌛
Waiting for racks to load.
Loading racks.
✔
Racks completed.
⌛
Waiting for enclosures to load.
Loading enclosures.
✔
Enclosures completed.
⌛
Waiting for {{rackMountable}} assets to load.
Loading {{rackMountable}}
assets..
✔
{{rackMountable}} assets completed.
⌛
Waiting for {{enclosureMountable}}s to load.
Loading {{enclosureMountable}}
assets.
✔
{{enclosureMountable}} assets completed.


| spark.svmLinear {SparkR} | R Documentation |
Fits a linear SVM model against a SparkDataFrame, similar to svm in e1071 package. Currently only supports binary classification model with linear kernel. Users can print, make predictions on the produced model and save the model to the input path.
spark.svmLinear(data, formula, ...) ## S4 method for signature 'SparkDataFrame,formula' spark.svmLinear( data, formula, regParam = 0, maxIter = 100, tol = 1e-06, standardization = TRUE, threshold = 0, weightCol = NULL, aggregationDepth = 2, handleInvalid = c("error", "keep", "skip") ) ## S4 method for signature 'LinearSVCModel' predict(object, newData) ## S4 method for signature 'LinearSVCModel' summary(object) ## S4 method for signature 'LinearSVCModel,character' write.ml(object, path, overwrite = FALSE)
data |
SparkDataFrame for training. |
formula |
A symbolic description of the model to be fitted. Currently only a few formula operators are supported, including '~', '.', ':', '+', and '-'. |
... |
additional arguments passed to the method. |
regParam |
The regularization parameter. Only supports L2 regularization currently. |
maxIter |
Maximum iteration number. |
tol |
Convergence tolerance of iterations. |
standardization |
Whether to standardize the training features before fitting the model. The coefficients of models will be always returned on the original scale, so it will be transparent for users. Note that with/without standardization, the models should be always converged to the same solution when no regularization is applied. |
threshold |
The threshold in binary classification applied to the linear model prediction. This threshold can be any real number, where Inf will make all predictions 0.0 and -Inf will make all predictions 1.0. |
weightCol |
The weight column name. |
aggregationDepth |
The depth for treeAggregate (greater than or equal to 2). If the dimensions of features or the number of partitions are large, this param could be adjusted to a larger size. This is an expert parameter. Default value should be good for most cases. |
handleInvalid |
How to handle invalid data (unseen labels or NULL values) in features and label column of string type. Supported options: "skip" (filter out rows with invalid data), "error" (throw an error), "keep" (put invalid data in a special additional bucket, at index numLabels). Default is "error". |
object |
a LinearSVCModel fitted by |
newData |
a SparkDataFrame for testing. |
path |
The directory where the model is saved. |
overwrite |
Overwrites or not if the output path already exists. Default is FALSE which means throw exception if the output path exists. |
spark.svmLinear
returns a fitted linear SVM model.
predict
returns the predicted values based on a LinearSVCModel.
summary
returns summary information of the fitted model, which is a list.
The list includes coefficients
(coefficients of the fitted model),
numClasses
(number of classes), numFeatures
(number of features).
spark.svmLinear since 2.2.0
predict(LinearSVCModel) since 2.2.0
summary(LinearSVCModel) since 2.2.0
write.ml(LogisticRegression, character) since 2.2.0
## Not run:
##D sparkR.session()
##D t <- as.data.frame(Titanic)
##D training <- createDataFrame(t)
##D model <- spark.svmLinear(training, Survived ~ ., regParam = 0.5)
##D summary <- summary(model)
##D
##D # fitted values on training data
##D fitted <- predict(model, training)
##D
##D # save fitted model to input path
##D path <- "path/to/model"
##D write.ml(model, path)
##D
##D # can also read back the saved model and predict
##D # Note that summary deos not work on loaded model
##D savedModel <- read.ml(path)
##D summary(savedModel)
## End(Not run)


Apache HTTP Server 版本2.2
| 说明 | 使用DBM数据库为认证提供支持 |
|---|---|
| 状态 | 扩展(E) |
| 模块名 | authn_dbm_module |
| 源文件 | mod_authn_dbm.c |
| 兼容性 | 仅在 Apache 2.1 及以后的版本中可用 |
This module provides authentication front-ends such as
mod_auth_digest
和mod_auth_basic
to authenticate users by looking up users in dbm password
files. Similar functionality is provided by
mod_authn_file
.
When using mod_auth_basic
或mod_auth_digest
, this module is invoked via the
AuthBasicProvider
或AuthDigestProvider
with the dbm
value.
| 说明 | Sets the type of database file that is used to store passwords |
|---|---|
| 语法 | AuthDBMType default|SDBM|GDBM|NDBM|DB |
| 默认值 | AuthDBMType default |
| 作用域 | directory, .htaccess |
| 覆盖项 | AuthConfig |
| 状态 | 扩展(E) |
| 模块 | mod_authn_dbm |
Sets the type of database file that is used to store the passwords. The default database type is determined at compile time. The availability of other types of database files also depends on compile-time settings.
It is crucial that whatever program you use to create your password files is configured to use the same type of database.
| 说明 | Sets the name of a database file containing the list of users and passwords for authentication |
|---|---|
| 语法 | AuthDBMUserFile file-path |
| 作用域 | directory, .htaccess |
| 覆盖项 | AuthConfig |
| 状态 | 扩展(E) |
| 模块 | mod_authn_dbm |
AuthDBMUserFile
directive sets the
name of a DBM file containing the list of users and passwords for
user authentication. File-path is the absolute path to
the user file.
The user file is keyed on the username. The value for a user is the encrypted password, optionally followed by a colon and arbitrary data. The colon and the data following it will be ignored by the server.
Make sure that the AuthDBMUserFile
is stored
outside the document tree of the web-server; do not put it in
the directory that it protects. Otherwise, clients will be able to
download the AuthDBMUserFile
.
Important compatibility note: The implementation of
dbmopen
in the apache modules reads the string length of
the hashed values from the DBM data structures, rather than relying
upon the string being NULL-appended. Some applications, such as
the Netscape web server, rely upon the string being
NULL-appended, so if you are having trouble using DBM files
interchangeably between applications this may be a part of the
problem.
A perl script called
dbmmanage
is included with
Apache. This program can be used to create and update DBM
format password files for use with this module.


The open source e-mail platform
To add someone to your organization enter their e-mail address below. If they don't already have a Postal account, they'll need to create one before you can add them to your account.
Users who have admin access will be permitted to manage the organization as if they had the same access as the organization owner. This includes managing users, creating & deleting mail servers, and even removing the account. This level of access should granted carefully. Regardless of which level you select, this user will have access to all servers within the organization.