Class: Sprockets::CachedEnvironment
| Relationships & Source Files | |
| Super Chains via Extension / Inclusion / Inheritance | |
|
Class Chain:
self,
Base
|
|
|
Instance Chain:
|
|
| Inherits: |
Sprockets::Base
|
| Defined in: | lib/sprockets/cached_environment.rb |
Overview
CachedEnvironment
is a special cached version of Environment
.
The exception is that all of its file system methods are cached for the instances lifetime. This makes CachedEnvironment
much faster. This behavior is ideal in production environments where the file system is immutable.
CachedEnvironment
should not be initialized directly. Instead use Environment#cached.
Constant Summary
SourceMapUtils
- Included
BASE64_DIGITS, BASE64_VALUES, VLQ_BASE, VLQ_BASE_MASK, VLQ_BASE_SHIFT, VLQ_CONTINUATION_BIT
DigestUtils
- Included
ADD_VALUE_TO_DIGEST, DIGEST_SIZES, HASH_ALGORITHMS
PathUtils
- Included
Utils
- Included
MODULE_INCLUDE_MUTEX, WHITESPACE_ORDINALS
ProcessorUtils
- Included
VALID_METADATA_COMPOUND_TYPES, VALID_METADATA_COMPOUND_TYPES_HASH, VALID_METADATA_TYPES, VALID_METADATA_VALUE_TYPES, VALID_METADATA_VALUE_TYPES_HASH
Server
- Included
Bower
- Included
Class Method Summary
- .new(environment) ⇒ CachedEnvironment constructor
Instance Attribute Summary
-
#config=(config)
writeonly
private
Cache
is immutable, any methods that try to change the runtime config should bomb.
Base
- Inherited
Configuration
- Included
| #config, #config=, | |
| #context_class | This class maybe mutated and mixed in with custom helpers. |
| #digest_class | Public: Returns a |
| #digest_class= | Deprecated: Assign a |
| #logger | Get and set |
| #version | The |
| #version= | Assign an environment version. |
Paths
- Included
| #root | Returns |
| #root= | Internal: Change Environment root. |
Exporting
- Included
| #export_concurrent | Public: Checks if concurrent exporting is allowed. |
| #export_concurrent= | Public: Enable or disable the concurrently exporting files. |
Compressing
- Included
| #css_compressor | Return CSS compressor or nil if none is set. |
| #css_compressor= | Assign a compressor to run on |
| #gzip= | Public: Enable or disable the creation of Gzip files. |
| #gzip? | Public: Checks if Gzip is enabled. |
| #js_compressor | Return JS compressor or nil if none is set. |
| #js_compressor= | Assign a compressor to run on |
| #skip_gzip? | Public: Checks if Gzip is disabled. |
Instance Method Summary
-
#cached
(also: #index)
No-op return self as cached environment.
-
#entries(path)
Internal:
Cache
Environment#entries
-
#index
Alias for #cached.
-
#load(uri)
Internal:
Cache
Environment#load -
#processor_cache_key(str)
Internal:
Cache
Environment#processor_cache_key
-
#resolve_dependency(str)
Internal:
Cache
Environment#resolve_dependency
-
#stat(path)
Internal:
Cache
Environment#stat
Base
- Inherited
| #[] | Preferred |
| #cached | Return an |
| #compress_from_root, #expand_from_root, | |
| #file_digest | Internal: Compute digest for path. |
| #find_all_linked_assets, | |
| #find_asset | Find asset by logical path or expanded path. |
| #find_asset! | Find asset by logical path or expanded path. |
| #index | Alias for Base#cached. |
| #inspect | Pretty inspect. |
Npm
- Included
| #read_package_directives | Internal: Read package.json’s main and style directives. |
| #resolve_alternates | Internal: Override resolve_alternates to install package.json behavior. |
Bower
- Included
| #read_bower_main | Internal: Read bower.json’s main directive. |
| #resolve_alternates | Internal: Override resolve_alternates to install bower.json behavior. |
Loader
- Included
| #load | Public: Load Asset by |
| #asset_from_cache | Internal: Load asset hash from cache. |
| #compress_key_from_hash, #expand_key_from_hash, | |
| #fetch_asset_from_dependency_cache | Internal: Retrieves an asset based on its digest. |
| #load_from_unloaded | Internal: Loads an asset and saves it to cache. |
| #resolve_dependencies | Internal: |
| #store_asset | Internal: Save a given asset to the cache. |
Resolve
- Included
| #resolve | Public: Find Asset URI for given a logical path by searching the environment’s load paths. |
| #resolve! | Public: Same as resolve() but raises a |
Server
- Included
| #call |
|
| #bad_request_response | Returns a 400 Forbidden response tuple. |
| #cache_headers, | |
| #css_exception_response | Returns a CSS response that hides all elements on the page and displays the exception. |
| #escape_css_content | Escape special characters for use inside a CSS content(“…”) string. |
| #forbidden_request?, | |
| #forbidden_response | Returns a 403 Forbidden response tuple. |
| #head_request?, #headers, | |
| #javascript_exception_response | Returns a JavaScript response that re-throws a Ruby exception in the browser. |
| #method_not_allowed_response, | |
| #not_found_response | Returns a 404 Not Found response tuple. |
| #not_modified_response | Returns a 304 Not Modified response tuple. |
| #ok_response | Returns a 200 OK response tuple. |
| #path_fingerprint | Gets ETag fingerprint. |
| #precondition_failed_response |
Configuration
- Included
Paths
- Included
| #append_path | Append a |
| #clear_paths | Clear all paths and start fresh. |
| #each_file | Public: Iterate over every file under all load paths. |
| #paths | Returns an |
| #prepend_path | Prepend a |
Mime
- Included
| #mime_exts | Internal: Mapping of MIME extension Strings to MIME type Strings. |
| #mime_type_charset_detecter | Internal: Get detecter function for MIME type. |
| #mime_types | Public: Mapping of MIME type Strings to properties Hash. |
| #read_file | Public: Read file on disk with MIME type specific encoding. |
| #register_mime_type | Public: Register a new mime type. |
Transformers
- Included
| #compose_transformers | Internal: Compose multiple transformer steps into a single processor function. |
| #expand_transform_accepts | Internal: Expand accept type list to include possible transformed types. |
| #register_transformer | Public: Register a transformer from and to a mime type. |
| #register_transformer_suffix | Internal: Register transformer for existing type adding a suffix. |
| #resolve_transform_type | Internal: |
| #transformers | Public: Two level mapping of a source mime type to a target mime type. |
| #compose_transformer_list, #compute_transformers! |
HTTPUtils
- Included
| #find_best_mime_type_match | Internal: Find the best qvalue match from an Array of available mime type options. |
| #find_best_q_match | Internal: Find the best qvalue match from an Array of available options. |
| #find_mime_type_matches | Internal: Find the all qvalue match from an Array of available mime type options. |
| #find_q_matches | Internal: Find all qvalue matches from an Array of available options. |
| #match_mime_type? | Public: Test mime type against mime range. |
| #match_mime_type_keys | Public: Return values from Hash where the key matches the mime type. |
| #parse_q_values | Internal: Parse Accept header quality values. |
Processing
- Included
| #bundle_processors |
|
| #pipelines, | |
| #postprocessors | Postprocessors are ran after |
| #preprocessors |
|
| #processors | Alias for Processing#preprocessors. |
| #register_bundle_metadata_reducer | Public: Register bundle metadata reducer function. |
| #register_bundle_processor | Registers a new |
| #register_pipeline | Registers a pipeline that will be called by |
| #register_postprocessor | Registers a new Postprocessor |
| #register_preprocessor | Registers a new Preprocessor |
| #register_processor | Alias for Processing#register_preprocessor. |
| #unregister_bundle_processor | Remove Bundle Processor |
| #unregister_postprocessor | Remove Postprocessor |
| #unregister_preprocessor | Remove Preprocessor |
| #unregister_processor | Alias for Processing#unregister_preprocessor. |
| #register_config_processor, #unregister_config_processor |
ProcessorUtils
- Included
| #call_processor | Public: Invoke processor. |
| #call_processors | Public: Invoke list of processors in right to left order. |
| #compose_processors | Public: Compose processors in right to left order. |
| #processor_cache_key | Internal: Get processor defined cached key. |
| #processors_cache_keys | Internal: Get combined cache keys for set of processors. |
| #validate_processor_result! | Internal: Validate returned result of calling a processor pipeline and raise a friendly user error message. |
Exporting
- Included
| #exporters |
|
| #register_exporter | Public: Registers a new Exporter |
| #unregister_exporter | Public: Remove Exporting processor |
Compressing
- Included
| #compressors, | |
| #register_compressor | Public: Register a new compressor |
Dependencies
- Included
| #add_dependency | Public: Add environmental dependency inherited by all assets. |
| #depend_on | Alias for Dependencies#add_dependency. |
| #dependencies | Public: Default set of dependency URIs for assets. |
| #dependency_resolvers | Public: Mapping dependency schemes to resolver functions. |
| #register_dependency_resolver | Public: Register new dependency URI resolver. |
| #resolve_dependency | Internal: |
Utils
- Included
| #concat_javascript_sources | Internal: Accumulate asset source to buffer and append a trailing semicolon if necessary. |
| #dfs | Internal: Post-order Depth-First search algorithm. |
| #dfs_paths | Internal: Post-order Depth-First search algorithm that gathers all paths along the way. |
| #duplicable? | Internal: Check if object can safely be .dup’d. |
| #hash_reassoc | Internal: Duplicate and store key/value on new frozen hash. |
| #hash_reassoc1 | Internal: Duplicate and store key/value on new frozen hash. |
| #module_include | Internal: Inject into target module for the duration of the block. |
| #string_end_with_semicolon? | Internal: Check if string has a trailing semicolon. |
PathDependencyUtils
- Included
| #entries_with_dependencies | Internal: List directory entries and return a set of dependencies that would invalid the cached return result. |
| #stat_directory_with_dependencies | Internal: List directory filenames and associated Stats under a directory. |
| #stat_sorted_tree_with_dependencies | Internal: List directory filenames and associated Stats under an entire directory tree. |
URIUtils
- Included
| #build_asset_uri | Internal: Build Asset URI. |
| #build_file_digest_uri | Internal: Build file-digest dependency URI. |
| #encode_uri_query_params | Internal: Serialize hash of params into query string. |
| #join_file_uri | Internal: Join file: URI component parts into String. |
| #join_uri | Internal: Join URI component parts into String. |
| #parse_asset_uri | Internal: Parse Asset URI. |
| #parse_file_digest_uri | Internal: Parse file-digest dependency URI. |
| #parse_uri_query_params | Internal: Parse query string into hash of params. |
| #split_file_uri | Internal: Parse file: URI into component parts. |
| #split_uri | Internal: Parse URI into component parts. |
| #valid_asset_uri? | Internal: Check if String is a valid |
PathDigestUtils
- Included
| #file_digest | Internal: Compute digest for path. |
| #files_digest | Internal: Compute digest for a set of paths. |
| #stat_digest | Internal: Compute digest for file stat. |
PathUtils
- Included
| #absolute_path? | On Windows, ALT_SEPARATOR is \ Delegate to Pathname since the logic gets complex. |
| #atomic_write | Public: Write to a file atomically. |
| #directory? | Public: Like |
| #entries | Public: A version of |
| #file? | Public: Like |
| #find_matching_path_for_extensions | Internal: Match paths in a directory against available extensions. |
| #find_upwards | Internal: Find target basename checking upwards from path. |
| #join | Public: Joins path to base path. |
| #match_path_extname | Internal: Match path extnames against available extensions. |
| #path_extnames | Internal: Get path’s extensions. |
| #path_parents | Internal: Returns all parents for path. |
| #paths_split | Internal: Detect root path and base for file in a set of paths. |
| #relative_path? | Public: Check if path is explicitly relative. |
| #relative_path_from | Public: Get relative path from |
| #set_pipeline | Public: Sets pipeline for path. |
| #split_subpath | Internal: Get relative path for root path and subpath. |
| #stat | Public: Like |
| #stat_directory | Public: Stat all the files under a directory. |
| #stat_sorted_tree | Public: Recursive stat all the files under a directory in alphabetical order. |
| #stat_tree | Public: Recursive stat all the files under a directory. |
DigestUtils
- Included
| #already_digested? | Internal: Checks an asset name for a valid digest. |
| #detect_digest_class | Internal: Detect digest class hash algorithm for digest bytes. |
| #digest | Internal: Generate a hexdigest for a nested JSON serializable object. |
| #digest_class | Internal: Default digest class. |
| #hexdigest | Internal: Generate a hexdigest for a nested JSON serializable object. |
| #hexdigest_integrity_uri | Public: Generate hash for use in the |
| #integrity_uri | Public: Generate hash for use in the |
| #pack_base64digest | Internal: Pack a binary digest to a base64 encoded string. |
| #pack_hexdigest | Internal: Pack a binary digest to a hex encoded string. |
| #pack_urlsafe_base64digest | Internal: Pack a binary digest to a urlsafe base64 encoded string. |
| #unpack_hexdigest | Internal: Unpack a hex encoded digest string into binary bytes. |
| #build_digest |
SourceMapUtils
- Included
| #bsearch_mappings | Public: Search Array of mappings for closest offset. |
| #combine_source_maps | Public: Combine two separate source map transformations into a single mapping. |
| #compare_source_offsets | Public: Compare two source map offsets. |
| #concat_source_maps | Public: Concatenate two source maps. |
| #decode_source_map | Public: Decompress source map. |
| #decode_vlq_mappings | Public: Decode VLQ mappings and match up sources and symbol names. |
| #encode_source_map | Public: Compress source map. |
| #encode_vlq_mappings | Public: Encode mappings Hash into a VLQ encoded String. |
| #format_source_map | Public: Transpose source maps into a standard format. |
| #make_index_map | Public: Converts source map to index map. |
| #vlq_decode | Public: Decode a VLQ string. |
| #vlq_decode_mappings | Public: Decode a VLQ string into mapping numbers. |
| #vlq_encode | Public: Encode a list of numbers into a compact VLQ string. |
| #vlq_encode_mappings | Public: Encode a mapping array into a compact VLQ string. |
Constructor Details
.new(environment) ⇒ CachedEnvironment
# File 'lib/sprockets/cached_environment.rb', line 15
def initialize(environment) initialize_configuration(environment) @cache = environment.cache @stats = Concurrent::Map.new @entries = Concurrent::Map.new @uris = Concurrent::Map.new @processor_cache_keys = Concurrent::Map.new @resolved_dependencies = Concurrent::Map.new end
Instance Attribute Details
#config=(config) (writeonly, private)
Cache
is immutable, any methods that try to change the runtime config should bomb.
# File 'lib/sprockets/cached_environment.rb', line 60
def config=(config) raise RuntimeError, "can't modify immutable cached environment" end
Instance Method Details
#cached Also known as: #index
No-op return self as cached environment.
# File 'lib/sprockets/cached_environment.rb', line 27
def cached self end
#entries(path)
Internal: Cache
Environment#entries
# File 'lib/sprockets/cached_environment.rb', line 33
def entries(path) @entries.fetch_or_store(path) { super(path) } end
#index
Alias for #cached.
# File 'lib/sprockets/cached_environment.rb', line 30
alias_method :index, :cached
#load(uri)
Internal: Cache
Environment#load
# File 'lib/sprockets/cached_environment.rb', line 43
def load(uri) @uris.fetch_or_store(uri) { super(uri) } end
#processor_cache_key(str)
Internal: Cache
Environment#processor_cache_key
# File 'lib/sprockets/cached_environment.rb', line 48
def processor_cache_key(str) @processor_cache_keys.fetch_or_store(str) { super(str) } end
#resolve_dependency(str)
Internal: Cache
Environment#resolve_dependency
# File 'lib/sprockets/cached_environment.rb', line 53
def resolve_dependency(str) @resolved_dependencies.fetch_or_store(str) { super(str) } end
#stat(path)
Internal: Cache
Environment#stat
# File 'lib/sprockets/cached_environment.rb', line 38
def stat(path) @stats.fetch_or_store(path) { super(path) } end


Assembly Configuration¶
The assembly config file required to initialize the assembly class and perform model training and deployment
- param assembly_system[‘data_type’]
The incoming data type from the assembly/VRM system, currently defaults to 3D point cloud data
- type assembly_system[‘data_type’]
str (required)
- param assembly_system[‘application’]
The application for which the library is being used, currently defaults to In line Root Cause Analysis
- type assembly_system[‘application’]
str (required)
- param assembly_system[‘part_type’]
The type of the part within the assembly, used to create the file structure within trained_models and active_learning
- type assembly_system[‘part_type’]
str (required)
- param assembly_system[‘part_name’]
Name of the part, to be extended to a list when used for multi-stage systems
- type assembly_system[‘part_name’]
str (required)
- param assembly_system[‘data_format’]
The data format currently defaults to complete, to be extended to partial data input refer: https://github.com/manojkumrb/spaceTimeV2 for more details
- type assembly_system[‘data_format’]
str (required)
- param assembly_system[‘assembly_type’]
Type of assembly system, single stage vs multiple stages
- type assembly_system[‘assembly_type’]
str (required)
- param assembly_system[‘assembly_kccs’]
The number of kccs in the assembly system used to determine the number of output neurons for the system
- type assembly_system[‘assembly_kccs’]
int (required)
- param assembly_system[‘assembly_kpis’]
the number of assembly KPIs in the system (the first KPI is convergence flag to indicate if the VRM simulation has converged), minimum value should be 1
- type assembly_system[‘assembly_kpis’]
int (required)
- param assembly_system[‘voxel_dim’]
The dimension/resolution of the voxel required to initialize the input to the model currently defaults to 64
- type assembly_system[‘voxel_dim’]
int (required)
- param assembly_system[‘point_dim’]
The number of nodes in the input mesh of the assembly
- type assembly_system[‘point_dim’]
int (required)
- param assembly_system[‘system_noise’]
Noise parameter for the system, used to make model training more robust to actual system noise
- type assembly_system[‘system_noise’]
int (required)
- param assembly_system[‘aritifical_noise’]
Noise parameter for the model, used to make model training more robust to actual system noise (usually same as system noise)
- type assembly_system[‘aritifical_noise’]
int (required)
- param assembly_system[‘noise_type’]
The distribution of the noise , defaults to uniform random value between +- system noise, in case of Gaussian it corresponds to the standard deviation (mean is zero)
- type assembly_system[‘noise_type’]
float (required)
- param assembly_system[‘mapping_index’]
File name of the mapping index, after download is complete the file is saved with this name
- type assembly_system[‘mapping_index’]
str (required)
- param assembly_system[‘nominal_cop_filename’]
File name of the nominal cop, after download is complete the file is saved with this name
- type assembly_system[‘nominal_cop_filename’]
str (required)
- param assembly_system[‘data_folder’]
Path to input data location
- type assembly_system[‘data_folder’]
str (required)
- param assembly_system[‘kcc_folder’]
Path to Output data/KCC location
- type assembly_system[‘kcc_folder’]
str (required)
- param assembly_system[‘kcc_files’]
List of kcc files, after download is complete the file is saved with this name
- type assembly_system[‘kcc_files’]
str (required)
- param assembly_system[‘test_kcc_files’]
List of test kcc files, after download is complete the file is saved with this name
- type assembly_system[‘test_kcc_files’]
str (required)
- param assembly_system[‘data_files_x’]
List of x deviation input files, after download is complete the file is saved with this name
- type assembly_system[‘data_files_x’]
str (required)
- param assembly_system[‘data_files_y’]
List of y deviation input files, after download is complete the file is saved with this name
- type assembly_system[‘data_files_y’]
str (required)
- param assembly_system[‘data_files_z’]
List of z deviation input files, after download is complete the file is saved with this name
- type assembly_system[‘data_files_z’]
str (required)
- param assembly_system[‘test_data_files_x’]
List of x deviation test input files, after download is complete the file is saved with this name
- type assembly_system[‘test_data_files_x’]
str (required)
- param assembly_system[‘test_data_files_y’]
List of y deviation test input files, after download is complete the file is saved with this name
- type assembly_system[‘test_data_files_y’]
str (required)
- param assembly_system[‘test_data_files_z’]
List of z deviation test input files, after download is complete the file is saved with this name
- type assembly_system[‘test_data_files_z’]
str (required)


Purchase Information:
Chuck Norris insurance a.d.o. Novi Sad
{{vm.amount.amount}} RSD
{{vm.paymentId}}
Card Information:
Required field
Min characters is 10
Max characters is 16
Min characters is 3
Max characters is 4


If several languages coalesce the grammar
3 min ago
It will seem like simplified English.
1 hours ago
As a skeptical Cambridge friend of mine occidental.
Description: CONSULTANCY SERVICES TO UNDERTAKE BOARD EVALUATION FOR THE PUBLIC SERVICE COMMISSION.


{% extends "base/page_centered.html" %} {% block page_title %}Contact Us{% endblock %} {% block extra_styles %} {{ block.super }} .icon { vertical-align: bottom; } {% endblock %} {% block main_content %}
We are always interested in new ideas for Local Ground, and for new ways to
collaborate with teachers, students, non-profit organizations and other
mappers everywhere!
Please send us email at<EMAIL_ADDRESS>or call us at +1-510-859-3003.


From the Death Certificate
for Joseph Schell
State of Ohio #26472
Place of Death: Miltonsburg, Malaga Township, Monroe County,
Ohio
PERSONAL AND STATISTICAL
PARTICULARS
male, white, single, never
married
birth: Nov. 7, 1855, Miltonsburg, O.
age at death: 83 years 5 months
occupation: farmer
father: George Schell, born (don't know)
mother: (don't know)
informant: Mrs. Marl or Merl* Burkhart, Miltonsburg,
Ohio
burial: Schell Cemetery, Miltonsburg O; April 10th,
1939
buried by: Bauer and Turner, Woodsfield, O.
MEDICAL CERTIFICATE OF DEATH
date of death: [nothing is filled in on this line]**
physician's statement: I hereby certify, that I attended deceased
from Nov. 28, 1938, to
April 7, 1939; I last saw him alive on Nov. 28, 1938, death is said to have occurred on the date stated
above at 8:00 p.m.
cause: general arteriosclerosis & chronic
myocarditis
signature: O.C. Jackson, M.D., Apr 8, 1939, Woodsfield,
Ohio
Submitter's Notes:
* Writing was
difficult to read. Perhaps MARL or MERL
is an error.
** Other sources indicate the date of death was April 7, 1939.
Provided by Betty Latta Kitchen
Click here for the Short-Cut Table of Contents


--- layout: post title: "How wonderful things become guilty pleasures" external-url: http://thisisindexed.com/wp-content/uploads/2010/02/card2376-380x229.jpg ---
Jessica Hag blows me away with beautiful insight like this every day.


|
S1 Fig
|
Geographic patterns of model uncertainty. Uncertainty propor ... |
|
S1 Table
|
Summary of data and model performance statistics. Nrec: numb ... |
|
S2 Table
|
Protected areas. Conservation Units (CU) and Indigenous Land ... |
|
S3 Table
|
Area change. Projected species occurrence area and differenc ... |
|
S4 Table
|
Biodiversity change dynamics in protected areas. Projected s ... |
|
S1 File
|
The R code. occurrence records acquisition, modeling procedu ... |


--- layout: post esbma_id: 1165 title: Product Pricing Primer date: 2004-08-18 19:26:20 keywords: bos ignoretoc teaser: Product pricing is hard. There is no magic formula that will determine the best price for your product. I can't provide any easy answers, but I can give you some things to think about as you make your pricing decisions. In the end, you will just have to make a decision using your own judgment. There will be times you will wonder if you made the right decision. You may never know for sure. ---
Summary: Eric provides a collection of issues to consider when making decisions about the price of software products.
Every small ISV wrestles with the question of how to set pricing for its software products. I've been asked many times to write an article on this topic, and I have finally decided to do so. Before we begin, I would like to offer a disclaimer:
Product pricing is hard. There is no magic formula that will determine the best price for your product. I can't provide any easy answers, but I can give you some things to think about as you make your pricing decisions. In the end, you will just have to make a decision using your own judgment. There will be times you will wonder if you made the right decision. You may never know for sure.
Let us first say that our goal is to find the price at which profit is maximized. If we say that a price is "too high" or "too low," we are saying that our profit could have been greater if we had set the price either lower or higher.
Obviously, revenue is the simple multiplication of quantity by price:
Revenue = Quantity * Price
Where "Quantity" is the total number of units we sell, and "Price" is the amount we charged for each unit. The only variable we can control is the price. But the price we choose will influence the quantity sold.
In a simplified view of the world, we would draw a graph with price on the x axis and revenue on the y axis. The curve would look like a parabola.
The price we want is the value of x at the point at which the curve peaks. However, in real life, pricing is far more complicated than this.
Pricing and positioning are inseparable. Don't bother trying to figure out your price point until you first figure out what position your product will have in the market.
Ask yourself these four questions:
Keeping all these things in mind, you should be able to figure out an approximate price range to use as a starting point. In rough terms, what price range is consistent with the perception you want people to have of your product?
As a hypothetical example, let us suppose that you want to develop a new database development tool based on the Firebird open source database. Responding to the four questions above:
So what is the right price range?
This question is the point where most small ISVs will wimp out. "We don't have the Microsoft name." "Our product is less mature." "We feel inferior, so obviously our price has to be lower than theirs."
Bzzzt! Wrong answer. The right answer is: "A lot more than $229."
Your differentiation is clear. Your strategy is to convince the world that in one specific way, your product is better than Access. Your price has to be consistent with that message. Nobody will believe you if you set your price at $199. By doing so, you are sending a mixed message.
Send the world the clear message that you believe your product is around four times better than Access. Set your price at $899. Find creative ways to say, "You get what you pay for."
 Trust me, I know. I'm simply trying to use this example to illustrate the point that pricing and positioning are inseparable. Don't miss that point by focusing on all the obvious holes in this very hypothetical example.
In more traditional industries, a classic approach to the pricing problem is called "cost plus." Basically, "cost plus" means that you determine your product price by taking all your costs and adding the amount of profit you want.
We don't really want to price things this way. The software industry is maturing, but our markets are a long way from the day when they behave like actual commodities. Our pricing should not be primarily based on our expenses. We want to charge the maximum amount that our customers are willing to pay.
However, that doesn't mean we should completely ignore our expenses when we make our pricing decisions. Whatever price we choose, we do have to convince ourselves that we can in fact make a profit. We need to identify all our costs, being careful not to overlook any of them that might be hiding. The total of all of those expenses will help us define the floor--the minimum price we can consider.
There are several different kinds of costs that we need to remember:
Compare your small ISV to a traditional business like a bicycle shop. Most of the bike shop's expenses are monthly items that are quite predictable. The guy who owns the bike shop isn't actually designing and manufacturing the bikes. He buys the bikes, marks up the prices, and sells them.
Your life is different. In your small ISV, you are not merely the retailer, but also the designer and manufacturer. You have to invest a whole bunch of time and money in development before you can get your first dollar of revenue. Regardless of how you paid for that development effort, it must be considered and somehow included in the price of your product.
The bike is no different, actually. Be it a bicycle or a blogging tool, the price of every product must reflect the cost of its design and development. The bike shop guy knows exactly what this price is—it is the amount he paid for the bike. In your case, you might want to keep track of your developers' time so you can get a rough idea of the value of the effort you have expended.
The price paid for the bike is called "cost of goods." The difference between cost of goods and the product price is usually called "markup." In traditional businesses, the amount of markup varies widely. Clothing at the mall may be sold at 100% markup. A clothing business may buy a shirt for $15 and sell it for $30. The markup on a gallon of milk--or a small sedan--is much lower.
In a small ISV, the concept of markup is essentially irrelevant. The actual "cost of goods" on each sale is very low, perhaps even zero if customers are merely downloading your product. Nonetheless, if you do have physical materials like a printed manual or a CD-ROM, be sure to keep those costs in mind when you determine your pricing.
This cost is sometimes difficult to quantify. Customers need help. They get themselves into strange messes and expect you to get them out. You have to be ready to provide assistance to your customers. There are two common ways of dealing with this:
There are costs associated with each of these two approaches. Here at SourceGear we use a combination of both.
How are you going to sell your product?
Regardless of how you do it, the act of selling costs money. You have to include these costs somewhere in the price of your product.
All of the costs in your business have to get paid somehow, including rent, utilities, insurance, taxes and your T-1 line. When you calculate your costs, don't overlook anything. Make sure your understanding of your company's expenses is complete.
One of the most important issues in your pricing decision is the matter of how much value your product generates for your customer. This value is the justification for the price of your product. As much as possible, it is important to understand your customer's perspective on this.
Some products generate value that is much easier to quantify than others. Let us suppose for a moment that you invented a molecular transporter that can instantly "beam" an individual to any place in the world. How much value would this generate for the business traveler?
Although this example is obviously rooted in fantasy, it is quite simple to quantify. I really need to visit the Microsoft campus tomorrow. It's not hard to figure out approximately how much I would pay to be instantly transported to Redmond.
Bottom line, my break-even point is around $3,300. Let us now suppose that your transporter only costs $100 per jump, including depreciation on the machine. You could charge me $300 roundtrip and still make money.
However, I am happy to pay you ten times that amount and I am still saving money over my other option. You should charge me as much as I will pay, even if the profit is obscene. Eventually, market forces will erode your profit margin. Enjoy it while it lasts.
Put yourself in the shoes of your customer. Understand his world in as much detail as you can. Figure out how much your product is worth to them.
With apologies for grossly oversimplifying, I assert that you are facing an important strategic decision that offers you two alternatives:
This matter is highly tied to the questions about your positioning. It is important to realize that you have these two alternatives. In fact, there are probably a number of other opportunities available between these two extremes.
Conventional wisdom says that if all else is equal, if you can get the same revenue with fewer customers, you should do so. There is a certain cost associated with having every customer. Having fewer customers reduces those costs and simplifies things.
However, I have to confess that I'm not fond of this bit of conventional wisdom. I simply don't like the implication that customers are something to be avoided. We sell SourceGear Vault for $199. We could have priced it ten times higher and focused our marketing message only at those customers who really needed Vault's specific set of features and benefits. I honestly don't know if our revenues would be higher or lower than they are now.
However, I personally prefer the high-volume-low-price approach. In high school I played Harold Hill in The Music Man. I've been a bit of ham ever since. I like a big room.
Having a large customer base has some advantages that offset those per-customer costs. A larger customer base will generate more buzz and more word-of-mouth marketing. A larger customer base has more gravity.
The high-volume-low-price approach fits very well with the "Responsive Sales" approach I presented in Closing the Gap. Part 2. In contrast, if you choose a high-price-low-volume approach, you are far more likely to need a sales guy.
Low prices can cause all kinds of problems. Most people are naturally afraid of setting a high price point, worrying that the customer simply won't buy the product if it is too expensive. To balance that fear, here are two reasons you might want to be afraid of setting a price point that is too low.
Referring back to the issue of positioning, it is hard to overstate the importance of being different. Your product doesn't need to be better in every way--it needs to be better in just one way.
But as I mention above, you don't want lower price to be your primary differentiator. It's okay to be competitive on price, but you need something else to say as well. If your only message is about price, a certain portion of your market will perceive your product to be "cheap" or "low quality." If you want to be aggressive on price, fine, but focus your message on something else.
Even worse, if price is your only message, what happens if your competitors lower their price to match? Now you have nothing at all to say.
This is a risky business. The industry-wide pace of change is insane.  The competitors are big and smart.
Running a small ISV requires you to take risks, and it is inevitable that you will get burned at least once in a while. One of the reasons that gross margins in software are so high is to offset all these unpleasant surprises. When you get too aggressive on price, you are cutting into those margins, and you may be reducing your ability to cope with the next unpleasant surprise. The customer might pay more.
In the macro view, a product will always sell fewer units at a higher price than it would at a lower price. However, in the micro view, there are exceptions.
Over the last seven years, SourceGear has sold approximately 60,000 licenses of SourceOffSite. Our current price is $239. What if our price had been 1 cent higher? Would any of those buyers have made a different decision over a mere penny per license? I rather doubt it. We have almost certainly given up $600 in revenue by setting our price too low.
Obviously I don't lose too much sleep over this glaring mistake in our pricing. And yet, I can't help but wonder: Isn't it intriguing that I could increase the price even a little without affecting demand? How far does this horizontal segment of the curve extend? Exactly how high could I raise the price without affecting quantity? What if the price of SourceOffSite had been just $5 higher? That's only a two percent increase, but it would have made a difference of $300,000 in revenue.
I'm asking questions that cannot be answered. I nonetheless recommend you ask yourself the same questions about your own product pricing. It can't hurt you to at least think it over. If customers will pay n, why won't they pay n+1?
Depending on your situation, there may be certain numbers to which your price will be compared. Think of these numbers like lines painted on the floor. If you cross the lines, there are consequences you must accept.
If your product is an add-on for another product, the price of the base product will be a barrier for your own price. The market will usually expect your product to be significantly less expensive than the base product.
For example, suppose you are selling plug-ins for Adobe Photoshop. It is only natural that customers will raise an eyebrow if your plug-in costs more than Photoshop itself. That doesn't mean you absolutely cannot cross this line, but you're going to need a darn good reason.
In corporate environments, your customer has spending limits. At each rung of the corporate ladder, the organization has policies that specify how much that person is allowed to spend without getting higher approval. It's worth trying to make sure that your price point is within the amount that your customer is allowed to spend.
Exactly who is making the purchasing decision for your product? Find out how much she is allowed to spend, and price your product slightly less.
Up to this point, we have been assuming that price is simply one constant number. It doesn't have to be.
In an ideal world, the price would be different for every customer. The "perfect" pricing scheme would charge every customer a different amount, extracting from each one the maximum amount they are willing to pay.
Your pricing is more than just a number. A complete pricing policy contains lots of details that you have to consider.
You can never make your pricing "perfect," but you can do much better than simply setting one constant price for all situations. By carefully tuning all these details, you can find ways to charge more money from the people who are willing to pay more.
The most common way to approach perfect pricing is to have a product with multiple tiers. Each tier has a feature set and price point that is carefully chosen. For example:
Examples of this strategy are obvious, but Microsoft Visual Studio is the first one that comes to my mind.
Three tiers is a good number to have:
The wise use of multiple tiers can offer a very rough way of approximating "perfect pricing."
Your desire to approximate perfect pricing should be held in the proper tension with a value for simplicity.
The ultimate example of the quest for perfect pricing is the system of fares in commercial air travel. The airlines are willing to sacrifice simplicity in a never-ending quest to ensure that each passenger pays the maximum amount they are willing to pay. For example, last-minute travelers pay more, on the assumption that they are business travelers and are therefore willing to be gouged.
The airlines have built enormous computer systems that are constantly running simulations and models to determine the ideal prices for every flight. Based on the result of all these computer simulations, the airline industry makes thousands of fare changes each and every day.
The result is a system that no consumer can possibly understand. All this complexity has opened the door for a number of small airlines to carve out a nice market niche by presenting a pricing system that isn't so scary.
After seven years of running a small ISV, I have come to the following conclusion: No matter how low we set the price, someone will complain.
That's life. Most of SourceGear's customers are really nice people, but it is inevitable that someone will have the perspective that your price is too high.
In fact, if nobody is complaining about your price, then it is probably too low. The trick is to tune your pricing until the volume of the whining is just right.
When we first introduced SourceOffSite, the price was $119. At that level, a number of enterprise customers told us they couldn't believe we were charging such a low price. Virtually nobody was complaining that it was too high. So we raised the price until the level of complaining seemed about right.
The basic idea of a "loss leader" is to price a product very low in an effort to gain the attention of a large number of people to whom you plan to sell something else. Many traditional businesses do this all the time. Your grocery store sells milk at a loss, placing it in the very back of the store so you have to walk by a bunch of higher-profit items in order to buy it.
The loss leader concept is very tempting for software because we don't have any cost of goods. Unlike milk, we can take our price all the way to zero if we want.
Some ISVs use no-cost products or open source strategies quite effectively. For example, SleepyCat is a very successful small ISV that developed its own software. At SleepyCat, they use an open source strategy. Their product is wildly popular.
However, it's easy to forget just how expensive it is to build software. The ideal loss leader is something that is quite cheap. Although the cost of goods on software can be zero, software development is really expensive. If you are building a piece of software for the specific purpose of giving it away, you are accumulating a lot of costs that need to be repaid in some other way.
What I'm saying here is that SleepyCat is unusual. Most open source companies are companies that did not have to pay the cost of development. Red Hat did not write Linux. Covalent did not write Apache.
Even worse, loss leaders in software don't capture users as effectively as you might think. If you actually want to give away milk at no charge, you can probably capture most of the market. Software isn't like that. OpenOffice.org and Linux involve no license fees, but lots of people still use Microsoft Office and Windows.
Giving away software is not as straightforward as it looks. Tread carefully.
Resist the temptation to run short-term special sales.
Here again, we see this tactic frequently in traditional retail. The grocery store is selling milk for $1.79 a gallon, but only through Sunday. The car dealer promises us a bigger rebate if we buy before the end of the month. The furniture store is running a different sale every week of the year.
In the short term, temporary pricing usually works. It will temporarily increase your sales. This can be handy for situations where you need a relatively quick inflow of cash.
However, these special sales often have a negative effect in the long term. People who miss the sale may wait for the next one. Customers gradually become trained never to buy at regular prices.
Here in the United States (and probably elsewhere as well) the law has a few things to say about pricing. If you are Microsoft or Wal-Mart, these laws affect every decision you make and every conversation you have. Small ISVs are a lot less likely to be affected by these laws, but it can't hurt you to know something about them.
Once again, all I can do on this topic is mention it and suggest that you consult other sources. I am not an attorney, so I am not allowed to say anything that could be construed as legal advice. Google on the words price fixing. Ask your attorney for more information.
Well, here we are at the end of the column. You've read the whole thing, and just like I threatened at the beginning, you don't have any simple answers.
I've given you a whole bunch of guidelines and issues to consider as you face your pricing decision. I've said some things here which conflict with other things I've said here. Which issues are you supposed to consider?
You should consider all of these issues, and probably a few more that are specific to your situation. Look at the decision from every possible angle. Anything you read on the subject of pricing is merely an aid to your own judgment, not a substitute for it.
Eric Sink is the non-legendary founder of SourceGear, a developer tools ISV located in Illinois. Eric recently visited a 12-Step program for people who can't stop using alliteration in the title of their columns. They kicked him out for refusing to admit that he has a problem. Eric's weblog is at https://ericsink.com/.
This article originally appeared on the MSDN website.


Reports
First you need to create a report template according to your report structure.
You can use a report template designer(e.g iReport) to generate this templates.
Using your own report design - Custom Template
- Add your Custom report template.
- In the navigation under Tools click Reports -> Add -> Custom Report
- Add Report Template page appears.
Figure 1. Add Report Template page
- Click on Reports -> List , after you will see the available reports list
- Reports list page appears.
Figure 2. Reports List
- If you want to update the template ,click on the Edit icon.
- Report Editor page appears.
Figure 3. Report Editor
- Click on the report name , then you will see the report generation page.
- Select Datasource and report Type. (If you haven't configured a datasource please follow the the guide to create a
new Datasource )
- Generate Report page appears.
Figure 4. Generate Report
- Click on the Generate Report button to generate the report.
Using Default Report Templates
You can also use the report templates which are inbuilt with WSO2 server,
and follow the instructions provided in the UI. Follow instruction given Reports using report templates
to add reports using templates.


Toggle navigation
Cypher Marketing (MVC)
Messages
View Messages
Tasks
Create Task
View Tasks
Create a New Task
These are issues your team members should take care of - ASAP!
Title
Description
Category
Business Enquiry
Payment
UI Issue
Question
Due Date
Assigned To
Associated Message
Notes
Is Complete


DAZE is a simple list of daily activities to help focus on a grounded, self-aware and positive lifestyle.


Preparation time
less than 30 mins
Cooking time
10 to 30 mins
Serves
Serves 4
The humble cabbage is transformed into an unusual pesto here to go with simply steamed turbot and decadent cheesy potatoes.
Preheat the oven to 180C/350F/Gas 4. Separate the cabbage heart by removing the looser leaves from the outer layers but leaving the tighter centre leaves attached to the stem. Bring a large pan of water to the boil, add the outer cabbage leaves and cook until tender. Remove with a slotted spoon into a bowl of iced water to refresh. Return the water to the boil and cook the centre leaves until tender then drain and refresh in iced water.
Line a baking tray with a large piece of buttered greaseproof paper, season the turbot and place on the paper. Fold the paper over like a parcel and carefully turn it over so the join is at the bottom. Place in the oven and cook for 7-8 minutes until the fish is just cooked through.
Put the large blanched cabbage leaves, pine nuts, parmesan and oil in a blender, pulse until smooth then season with sea salt and freshly ground black pepper and lemon juice.
Meanwhile, cook the potatoes in a pan of boiling water then drain well and peel. In a small pan, melt the Poacher cheese with the crème frâiche. Coat the potatoes in the melted cheese and check the seasoning. Cut the blanched cabbage centre into quarters. Melt a little butter in a pan and fry the cabbage until it starts to colour.
To serve, place the cabbage on a plate and top with a portion of turbot. Arrange the potatoes around the fish, spoon over the cabbage pesto and garnish with the chickweed.


On Beginnings
begin a life
beginning was the Word
lines
the lines of a poem
semicolons
trial and error
disappointment
origins have consequences
where quotations begin is in a cloud
an act of mind
fulfilled
The End


Prophet Of Visitor Traffic & Visiting Time Recommandation
What time is your visiting?
Want to get heatmap or time recommandations?
Heatmap
Best Visiting Time (hover your mouse on the green area to get the result)
Which floor?
B1F
1F
5F


Improve This Doc
Popups are a great way to require the user to take a specific action. They can provide the user with important information, and require them to make a decision. Ionic provides three types of popups — **alert**, **confirm**, and **prompt**. Each popup is meant to be used in a different scenario.
The **alert** popup simply displays a message to the user, and provides a button to close the popup. This popup is useful for displaying important messages (eg: *"Your battery is low!"*).
The **confirm** popup displays a message, and gives the user the option to either cancel or confirm their action. This popup is useful when the user wants to perform an uncommon, but important action (eg: *"Are you sure you'd like to delete your account?"*).
The **prompt** popup displays a message, and requires to user to input some data. This popup is useful when you need important information from the user in order to continue (eg: *"Please re-enter your password to continue."*).
Popups are quite flexible, and can easily be customized. Check out the [API docs](../api/components/popup/Popup) for more information.


Argyle Admin App
Home
(current)
Settings
GitHub
×
Owners
Last Activity
Send Message To Owners
Subject
Message
Load Team Info
Welcome to the Argyle Admin App.
Loading...


A few days ago, it was the 10th birthday to the king of cryptocurrency and people took its birthday referring to the day Mr Satoshi published the Bitcoin Whitepaper to the Cryptography Mailing List, which was on 31 Oct 2008
.
Here is the brief introduction to the Bitcoin e-cash project by Satoshi himself.
A Peer-to-Peer Electronic Cash System, sounds very much old-fashioned and not attractive at all if I were to read this letter back in the day. Most of the readers of this letter would never be expected this “lame” project could impact and change the world at such a degree. And the ripple effect of Bitcoin success was just started followed by the recent market booming, although the crypto market is at a relatively bear market, it really depends on what stage of Bitcoin we are comparing to. Anyhow, a pile of random hash would worth a few thousand dollars per piece, I wonder if Mr Satoshi was expecting this coming or not.
Back in the day when this “e-cash” paper was announced, I was just graduated from high school and looking hard for the path to the university. A computer was nothing but a gaming station for me. Never knew I was going to end up with Computer Science in the U and never expected I could go this deep with cryptocurrency which is having a big deal with computational technologies.
Anyway, any project that could last for 10 years is celebratable， not to mention there is a huge potential for it to last for another 100 years. Happy belated birthday, Bitcoin!
Posted from my blog with SteemPress : https://fr3eze.vornix.blog/happy-10th-birthday-to-bitcoin/
This page is synchronized from the post: ‘Happy 10th birthday to Bitcoin’


Get personalized artwork “hints” for your home from Roomhints designers
Get Started NowUpload photo of your room and detail what you are looking for?
Your professional will send you ideas “hints” to solve your design problem. View the ideas 'hints' directly on your mobile phone and talk directly to your designer
Choose the 'hints' you love the most and purchase directly from your phone!
It's that easy to love your home with the help of Roomhints!
Get Started NowSign up for Roomhints Magazine. Every Friday we profile a designer and share their secrets.


|
| Local Properties | Local Methods | |
| Managed Object Types | Data Object Types | All Properties | All Methods |
The content of the returned results depends on the server environment:
Properties
| Name | Type | Description |
|---|---|---|
| domainList* P | xsd:string[] |
List of Windows domains available for user searches, if the underlying
system supports windows domain membership.
|
Methods
| Methods defined in this Managed Object |
|---|
| RetrieveUserGroups |
You must hold the Authorization.ModifyPermissions privilege to invoke this method. If you hold the privilege on any ManagedEntity, you will have access to user and group information for the server.
Parameters
| Name | Type | Description |
|---|---|---|
| _this | ManagedObjectReference | A reference to the UserDirectory used to make the method call. |
| domain* | xsd:string |
Domain to be searched. If not set, then the method searches
the local machine.
|
| searchStr | xsd:string |
Case insensitive substring used to filter results;
the search string is compared to the login and full name for users,
and the name and description for groups. Leave
this blank to match all users.
|
| belongsToGroup* | xsd:string |
If present, the returned list contains only users or groups
that directly belong to the specified group. Users or groups that
have indirect membership will not be included in the list.
|
| belongsToUser* | xsd:string |
If present, the returned list contains only groups that directly
contain the specified user. Groups that indirectly contain
the user will not be included in the list.
|
| exactMatch | xsd:boolean |
Indicates the searchStr passed should match a user or
group name exactly.
|
| findUsers | xsd:boolean |
True, if users should be included in the result.
|
| findGroups | xsd:boolean |
True, if groups should be included in the result.
|
Return Value
| Type | Description |
|---|---|
| UserSearchResult[] |
Faults
| Type | Description |
|---|---|
| NotFound | Thrown if any of the domain, belongsToGroup, or belongsToUser arguments refer to entities that do not exist. |
| NotSupported | Thrown if you specify a domain for systems that do not support domains, such as an ESX Server. The method also throws NotSupported if you specify membership (belongsToGroup or belongsToUser) and the server does not support by-membership queries. |
| RuntimeFault | Thrown if any type of runtime fault is thrown that is not covered by the other faults; for example, a communication error. |
Events
| Type | |
|---|---|
| None |
| Top of page | Local Properties | Local Methods | |
| Managed Object Types | Data Object Types | All Properties | All Methods |


You can review the list of Mup features, or a somewhat more detailed overview.
We currently provide Mup in ready-to-run form for Windows, Mac OS X, and Linux systems.
If you use a different operating system, Mup source code is also available, so if you have a C compiler, you can probably compile and run Mup. It has been run using several versions of UNIX on x86, Sun, Digital, and Silicon Graphics, as well as on OS/2, Atari, etc. Mup requires no special libraries. The Windows version will run under ReactOS. An ANSI-C compiler is recommended, but not required. If you try to compile Mup and have problems, please let us know at
<EMAIL_ADDRESS>We'd like to make it portable to as many computer system types as possible. The companion Mupmate program requires a C++ compiler and the FLTK toolkit.This will vary from person to person. A person who has experience with computer languages will probably pick up Mup more quickly, but such knowledge is not necessary. Mup has a broad array of features, so if you want to learn how to use every feature that Mup has to offer, this may take several days. (The Mup User's Guide, which explains all the features, and includes many examples, is about 200 pages long.) However, once you get Mup installed, you can start experimenting with Mup after reading the first few pages of the User's Guide, and it should take no more than a few hours to feel comfortable with the basics, enough to enter simple songs and get professional-looking output. Users have reported that the language is intuitive enough that even if they haven't used Mup for quite a while, it quickly comes back to them. The User's Guide includes many examples, and is provided both as a PostScript file that you can view or print out on paper, and as HTML files with hundreds of hypertext links, that you can view with your Web browser. The Mup installation package contains several sample files and a template file to help you get started. You can also download sample songs from http://www.arkkra.com/doc/music.html
This will vary greatly, depending on a number of factors, such as how complicated the music is, how much experience you have had with using Mup, how fast you type, etc. An experienced Mup user can typically enter simple music in less than 15 minutes per page, but very complex music can often take over an hour, especially if you like to make a lot of adjustments to make things look just exactly the way you want.
We are musicians and computer programmers who wanted a music publication program that would produce very high-quality output with a minimum amount of fuss. We wrote the Mup program for our own use, and continue to use it for all our own compositions. When other people expressed an interest in getting a copy of Mup, we formed Arkkra Enterprises to set up a website in 1995 to make Mup available as shareware to anyone who wanted it. After 17 years of adding features, we decided to just make it available for free, so that it could be included unencumbered in Linux distributions and such, and to encourage more people to use it.
Yes. There is a "majordomo" mailing list available exclusively to Mup users who have asked to join it. It provides a forum where you can ask or answer questions, get tips on how other people are using Mup, etc.
There is a tool that comes with Ghostscript, called "ps2epsi" that converts a PostScript file to an Encapsulated PostScript file, which can then be imported into other documents.
Not directly, but since Mup produces PostScript output, you can easily convert the output to PDF format using the ps2pdf utility that comes with Ghostscript.
The first score of a piece of music is traditionally indented somewhat
more than subsequent scores, so that's what Mup does by default.
It does that by setting the default
label parameter to a few spaces,
whereas it sets the default for the
label2 parameter to an empty string.
If you don't want the indentation, you can set
label=""
Yes. You use "space" on all voices. For example,
1: 2.s; 4e;
2: 2.s; 4c;
will produce a pickup measure with just a quarter note in it.
Yes. Try something like
rom above all: 1 "( \(sm4n) = 120 )";
No. However, it is possible to write a program that reads a MIDI file and outputs a file that can be input to Mup. Two programs that do this, called "mtm" and "midi2mup," have been donated by Mup users. They are limited, and not supported by Arkkra Enterprises, but may be useful for some people. Check out the programs donated by Mup users.
There are thousands of MIDI tutorials on the web; just search for "MIDI tutorial." One place you might start is http://www.midi.org.
There are many shorthands available. Some of the most useful are:
There is a Mup Quick Reference
You may need to edit the mupprnt file to make sure the variables and paths are set to match where things are installed on your system. In particular,
Check your config.sys file. You need to have a line like
files=10
where the number after the equals sign is greater than or equal to 9.
Also, make sure gs386.exe exists and is in your PATH. If you are running Mup from MS-DOS directly or from a DOS prompt under Windows, make sure you installed the DOS version of Ghostscript, not the Windows version. If you are using Mupmate, or Winmup, make sure you installed the Windows version of Ghostscript, not the MS-DOS version.
Mup handles all the symbols in the standard PostScript fonts, which covers most Western languages. Only Latin-1 characters are handled directly from Mup input, but others can be entered via names like \(Euro) or \(lambda). The User's Guide section on text strings gives a complete list of supported non-ASCII characters. You can also define keymaps to easily input in another alphabet, like Cyrillic.
The svga library used by Mupdisp in non-X-windows mode requires write permission to the console. To allow this:
Send us email at
<EMAIL_ADDRESS>We welcome any comments and questions about Mup. Normally, you should have no problem contacting us this way. In the event you get a "rejected" reply when sending email, this is because excessive "spam" (junk mail) has been received from your domain at some time in the past, and our Internet service provider has installed a "spam blocker." In this case, you will have to send email from another address.


You know, you could get the Perl Weekly right in your mailbox. Every Week.
Free of charge!
|
Issue #142 - 2014-04-14 - Heartbleed and Perl sites latest | archive | by Gabor Szabo
Don't miss the next issue!
Tweet | ||
| ||
|
Sponsors
| ||
| ||
|
Articles
| ||
| ||
| ||
| ||
| ||
|
Discussion
| ||
|
| ||
|
Testing
| ||
|
| ||
|
| ||
|
Code
| ||
| ||
| ||
|
CPAN
| ||
| ||
|
Heartbleed
I guess you've already heard about the serius security bug found in OpenSSL. This is just a reminder and a few articles related to Perl sites | ||
| ||
| ||
|
| ||
| ||
|
Fun
| ||
|
| ||
|
Grants
| ||
| ||
|
Tutorials
| ||
| ||
|
Videos
| ||
| ||
|
Perl 6
| ||
| ||
| ||
|
Weekly collections
| ||
|
| ||
|
| ||
|
Perl Maven Tutorials
| ||
| ||
| ||
|
| ||
|
| ||
|
Events
| ||
| ||
|
You know, you could get the Perl Weekly right in your mailbox. Every Week.
Just ONE e-mail each Monday. Easy to unsubscribe. No spam. Your e-mail address is safe.
|


Labs
Select lab to view details.
Filter by:
Futurewei
HQ
Others
All
Create New Lab
Lab Name
Company
Leader
Description
{{ lab.name }}
{{ lab.company }}
{{ lab.leader }}
{{ lab.description }}


{include file="common/header"} {block name="style"}{/block}
{include file="common/header_nav"} {block name="banner"}{/block}
{block name="main"}{/block} {block name="right_bar"}{/block}
{include file="common/footer"} {block name="footer_js"}{/block}


--- layout: page permalink: /writing sitemap: priority: 0.9 tags: - name: pudhina fresh theme - name: jekyll theme - name: jekyll ---
peer-reviewed journal article
public writing
2020. "White Environmentalism and the Corporate University." The Trouble.
2020. With M. Sehrsweeney. "GEO members: 'We are striking as an act of community care.'"Strikewave.


Enviar
Button with link
Go to google.com
Button icon
Button round with icon
Button round, outline with icon
Button without background
Button with progress
Download File
Button icon with progress


An overview of Boost participation in Google Summer of Code™ 2006
For the second consecutive year, Google has conducted its Summer of Code™ initiative, a program by which student developers are sponsored for their contributions within open source organizations willing to mentor the participants. The 2006 campaign has run between April and September, with active development work taking place between May 23 and August 21.
Around mid April, when the program had just started, some Boost members began considering the possibility to enter Summer of Code as a mentoring organization. Despite the lack of time and the fact that most of us were completely new to this initiative, Boost managed to successfully apply for the program. As a result ten projects were selected and mentored, most of which are expected to become full contributions to Boost shortly.
We give here a summary report of this experience, along with a short analysis of the main problems we found, so that we can work at solving them and do better next year.
Contents
- How the program works
- Boost participation
- Analysis
- Suggestions for improvement
- Conclusions
- Acknowledgements
How the program works
There are three types of participants in Google Summer of Code:
- Google itself acts as the funding partner and conducts the overall program.
- The open-source organizations accepted into the program must designate people inside the organization who will act as project mentors.
- Students submit their project ideas and, if selected, work in collaboration with one of the mentoring organizations; upon successful completion of the project, students receive the full stipend for the program.
The program goes through the following stages:
- Organization selection: those open source organizations willing to enter Summer of Code submit an expression of interest to Google, along with information Google uses for qualifying purposes. Selected organizations are publicly announced and each organization is expected to provide a pool of project ideas.
- Student selection: students willing to participate submit one or more project proposals, typically expanding on some of the ideas previously provided by the mentoring organizations. A student can apply several times and for different organizations, but ultimately can only be chosen for just one project. These proposals are routed by Google to the appropriate organizations, which must analyze them, rank them, and assign mentors to the most promising applications. Based on the information provided by mentoring organizations, Google issues the final list of accepted projects.
- Development: Students, guided by their assigned mentors, are expected to complete the projects during a period of three months. Google asks mentors for a mid-program review upon which continuation of the project depends.
- Final review: Once the development period is over, mentors are requested to inform Google of the results of the project, and determine whether students qualify to receive the full stipend.
2006 figures
The 2006 campaign of Google Summer of Code took place between April 14 and September 25. A total of 102 mentoring organizations participated. Of the 6,338 applications submitted by 3,044 students around the globe, 630 were finally selected and funded. Google has spent more than US$3 million in student stipends and compensations to the mentoring organizations.
Boost participation
Application and process selection
On April 14, the same day Google Summer of Code started, Julio M. Merino Vidal (later to become one of the selected students) sent a message encouraging Boost members to participate in this program as a mentoring organization. This call sparked the interest of the community; although time was already short for doing all the preparation labors, Boost moderators put rapidly themselves to work and conducted the preliminary registration steps. In the meantime, a Wiki page was grown with project ideas provided by Boost members, totaling more than twenty proposals.
By the beginning of May Boost was officially accepted into the program and Boost moderators set out to form a group of mentors, selected on an invitation basis. As student selection is a delicate process, involving the assessment of individuals on their technical skills, all subsequent discussions were conducted by the selected mentors on a private mail list established for their collaboration.
We were not prepared for the avalanche of student applications that followed. On day two after the application period was open, we had received three proposals; the next day it was 14, and within a week the count exceeded 50. By the end of the application period the total number of proposals received was 174, which forced us to go through a very intensive ranking process and recruit additional mentors. Two rules were followed so as rationalize the process of selection among dozens of different proposals:
- Where there were competing applications for the same project idea, only one were to be ultimately selected; so, no two projects with the same or very similar goals were accepted.
- Some of the applications built on a given Boost library (for instance, the Boost Graph Library is a frequent target for the addition of algorithms.) We limited the applications to a maximum of two per Boost library.
These rules have the combined effect of greatly reducing the number of eligible applications while at the same time distributing the accepted projects evenly across the space of ideas. Moreover, students with unique proposals, i.e. project ideas not coming from the pool originally presented by Boost, are at a competitive advantage.
The different proposals were classified according to their related technological area so that each cluster could be handled by an appointed mentor with the required expertise on the subject. Mentors submitted then "focus reports" summarizing the applications under their responsibility; these reports served as a first filter to help reduce the number of final applications to be evaluated jointly. Along the process, students with the most promising proposals were asked to refine their ideas and provide further information.
Although not enforced by the official rules, we agreed upon a one-to-one ratio of mentors to students, which ultimately marked a hard limit on the maximum number of eligible projects.
Accepted projects
Google accepted and funded the ten top-ranked projects endorsed by Boost. Of these, eight projects are libraries or library components targeted for future inclusion into Boost, while the remaining two consist of utility programs heavily relying on Boost.
C++ Coroutine Library
Giovanni Piero Deretta, mentored by Eric Niebler.
Library for the management through a modern C++ interface of OS-provided coroutine facilities.
Concurrency Library
Matthew Calabrese, mentored by David Abrahams.
STL-inspired generic framework for high-level specification and execution of parallelizable algorithms.
TR1 Math Special Functions
Xiaogang Zhang, mentored by John Maddock.
Implementation of the 23 special mathematical functions specified in C++ standard library extension proposal TR1.
The Boost.Process library
Julio M. Merino Vidal, mentored by Jeff Garland.
Portable library for process launching and basic management.
Out-of-Core Graphs and Graph Algorithms
Stéphane Zampelli, mentored by Jeremy Siek.
Extension of the Boost Graph Library to deal with out-of-core structures, i.e. data sets too large to be kept in main memory at once.
MISC (M)ulti (I)ndex (S)pecialized (C)ontainers
Matías Capeletto, mentored by Joaquín M López Muñoz.
Families of specialized containers internally based on Boost.MultiIndex.
Generic Tree Container
Bernhard Reiter, mentored by René Rivera.
Design and implementation of a family of STL-compatible tree containers.
Viewer utility for FSMs
Ioana Tibuleac, mentored by Andreas Huber Dönni.
Utility program for the visualization of finite state machines (FSMs) specified with Boost.Statechart.
Modular C++ preprocessor, using Boost.Spirit
Hermanpreet 'Lally' Singh, mentored by Joel de Guzman.
Implementation with Boost.Spirit and Boost.Wave of a front-end translator from Modular C++ (as specified in a proposal to add modules to C++ by Daveed Vandevoorde) to standard C++.
Implementing a state of the art Mincut/Maxflow algorithm.
Stephan Diederich, mentored by Douglas Gregor.
Implementation of a fast mincut/maxflow routine for the Boost Graph Library based on a new algorithm devised by Vladimir Kolmogorov.
Development
Two main facilities were set up to assist students and mentors during the development phase: a mailing list and a Trac/SVN project management system with separate directories for each project. One of the students, Matí as Capeletto, out of personal initiative registered a Google Group aimed at giving students with Boost a place for informal interaction and discussion of common problems.
After the initial warm-up period, each student-mentor pair performed development work mostly privately. The usage of the Boost mailing lists was scarce, and only by the end of the program did some students publicly announced their results.
Results
By the date the development period was officially closed, the status of the different projects was as follows:
- Seven projects were completed or nearly completed and the students are expected to ask for a formal review within 2006 or early 2007. Four of these projects necessitated a goal reorientation during development, basically because the original plan was too ambitious for three months. Most of the projects are still in active development during the months following the Summer of Code program.
- Two projects did not reach the planned goals, but nevertheless produced useful material that could be expanded outside of the Summer of Code program.
- One project was abandoned shortly after the midterm review. The reasons for the abandonment are unknown.
The results of all the projects can be consulted online at the dedicated Trac site.
Analysis
We examine the various stages of Boost participation in Summer of Code, with an emphasis on discovering opportunities for improvement.
Boost appeal
In a mid project presentation at OSCON 2006, Chris DiBona from Google provided some data about the organizations which received the most applications:
| Organization | No of applications |
|---|---|
| KDE | 244 |
| Ubuntu & Bazaar | 236 |
| Python Software Foundation | 212 |
| GNOME | 199 |
| Apache Software Foundation | 190 |
| Boost | 174 |
| Gaim | 152 |
| The GNU Project | 148 |
| Drupal | 146 |
The numbers shown here have been estimated from a chart included in the presentation slides. This chart contains an additional column labeled "Google" which actually accounts for the applications dismissed because of their low quality.
The fact that Boost is ranked the sixth most attractive organization out of a total of 102 was entirely unexpected, especially considering the wide popularity of the rest of top-rated organizations. There is a more or less implicit consensus among Boost members that ours is a relatively niche project, known for its quality standards by seasoned C++ practitioners, but with a limited penetration among entry level programmers: maybe the figures above should make us reconsider this assumption. A cursory examination of the applications submitted to Boost reveals that most applicants were regular users of Boost: many cite the Boost status among the C++ community as an appealing factor to apply.
Opportunities lost?
If we look at the number of funded projects concerning the applications received, figures are not so favorable to Boost.
| Organization | No of projects | Project/app ratio |
|---|---|---|
| KDE | 24 | 9.8 % |
| Ubuntu & Bazaar | 22 | 9.3 % |
| Python Software Foundation | 23 | 10.8 % |
| GNOME | 19 | 9.5 % |
| Apache Software Foundation | 27 | 14.2 % |
| Boost | 10 | 5.7 % |
| Gaim | 8 | 5.3 % |
| The GNU Project | 10 | 6.8 % |
| Drupal | 14 | 9.6 % |
It turns out that the project/application ratio for almost any other organization among the top nine is considerably higher than that of Boost. As it happens, Google initially requested that organizations submitted the maximum number of projects they felt they could cope with, and we got funding for exactly what we aimed for, so the limiting factor lies entirely on Boost's side.
Projects startup
Contributing to Boost relies on a fair number of guidelines and protocols for coding, documentation, testing and maintenance. Many of the required tools are exclusively used within Boost, and some of them are not trivial, like for instance Boost.Build. Although the Boost web site contains information about all these tools and procedures, this intelligence is scattered through unrelated pages and sometimes is very hard to come by.
So, there is a good deal of expertise required to begin
working at Boost. Some students have reported on startup
difficulties getting to know these details and familiarizing
themselves with the tools, most notably bjam
and
Quickbook. Each student overcome the startup difficulties on
their own or resorting to their mentors (see the section on
public communication
issues).
Ongoing development
Once students got past the startup stage, most projects advanced without serious complications. In the majority of cases, it was realized at some point during the development that there was no time to complete it. Some participants had to redefine the goals to keep the project within schedule, while others simply decided that they would continue working after the official deadline of Summer of Code.
The information flow between each student and their mentor was usually reported by both parties to be satisfactory. The projects suffering from lack of communication have been precisely those yielding the poorest results. In general, mentors have not felt overwhelmed by requests from their students, and even in a couple of cases, the projects were run practically unattended. This fact is witness to the high competence of the students recruited into the program.
The degree of usage of the Trac/SVN system has varied. Some students did frequent updates, while others have just used the repository to dump the final results for the official submission to Google.
Public communication issues
Students and mentors had at their disposal three different forums for the public interchange of information and support:
- Boost public lists, especially the developers and users lists.
- A dedicated mailing list reaching all students and mentors working at Summer of Code in Boost.
- A more casual Google Group, set up by one of the students, aimed at providing the participants with a place for socializing and resolution of common problems.
Despite this abundance of resources, there was an almost complete lack of group communication among all the parties involved and between these and the larger Boost community. Seemingly, students were satisfied to pursue their activities by relying on support from their mentors alone. This circumstance has prevented Boost members from enriching the initiative by offering their experience and insight, and has possibly led students to the false impression that contributing to Boost proceeds in a predictable linear path from requisites to completion of the work. When asked about their not engaging in public communication, the students gave vague justifications that can be classified into the following:
- Doubts were deemed too technical or specific to be worth raising in public.
- A craving for perfectionism detracted students from asking or submitting work in progress until they felt their material looked good enough.
- Shyness: some students probably lacked previous experience communicating in public, and most are not English native speakers, which could also be a limiting factor.
Although students did not identify the following as a reason not to go public, likely, many of them did not feel the need given the ready access to their mentors they enjoyed. It is easy to grow used to such a dedicated source of support and neglect to resort to other resources. Mentors should have encouraged their students to pursue the public discussion of projects, which constitutes one of the pillars of Boost renowned quality.
Scope of projects
In hindsight, it has become apparent that most projects were too ambitious to be completed within the three months of duration of the program, and even those that were considered a success will need weeks or months of polishing up before the material is ready for a formal review. In contrast with other organizations participating in the Summer of Code program, Boost has as of this writing included no results into its codebase. No formal review for any project has been requested yet, either.
These scope issues are very dependent on the particular type of project. We can classify the Boost projects for Summer of Code as follows:
- Full-fledged libraries,
- additions to existing Boost libraries,
- utilities and tool projects using Boost.
Of these, additions (like for instance the max-flow min-cut algorithm for BGL by Stephan Diederich) are the most suitable for completion in a short period of time: most of the preparation work is already done, and the student has clear guides as to what coding and documentation standards to follow. Also, these projects need not undergo a formal review, since it is the responsibility of the hosting library author to review the code and include it within her discretion. Utility projects seem also suitable for small timeframes, though most project proposals and requests are naturally oriented to contributions of actual code to the Boost project.
As for those projects involving the design and realization of full-fledged libraries, there is little hope that the goals and scope can be kept modest enough for a three-month schedule. Boost candidate libraries developed by professional authors usually take much longer than three months to be accepted; some libraries have been evolving through several years before being included in Boost. So, the best we can hope for if we are to support the realization of library projects for Boost inside Summer of Code is that the results by the end of the program can be evaluated to constitute a viable potential contribution to Boost. When this is the case, it is crucial that the student commits to further working on the project up to completion and formal review. Perhaps more important than getting libraries coded is to engage new authors in a long-term relationship with the Boost project.
Suggestions for improvement
The following proposals aim to alleviate some of the problems we have identified during the development of Summer of Code within Boost. These action points are related only to the issues found in connection with Boost: we are not addressing other areas of improvement associated with the Summer of Code program itself.
Preparation
Much work can be done before the actual program begins. The following preparation activities can already be launched:
Create a pool of ideas for projects. This action will provide valuable extra time for evaluation and refining of ideas before the Summer of Code begins. The experience has shown that those projects with more preparation work, especially in the area of design, were ultimately more successful. The pool can also be used to retain interesting ideas that arise on the mailing lists and very often are not given proper attention and become abandoned.
Create a student pool. Prior involvement with Boost is an advantage both in the selection phase and later during project development. Those students with a serious interest in participating in Summer of Code with Boost can enter the pool and begin exploring ideas and interacting with the community well in advance of the summer, to put themselves in a favorable position for the selection. Advertisement for the student pool can be initiated in the beginning of 2007 through the usual channels (web site and mailing lists): additionally, Boost members involved with the University can spread this information locally and help raise the interest of students in their environment.
Create a mentor pool. Given the rush with which Boost entered the 2006 Summer of Code campaign, the invitation of mentors has to be done on an on-demand basis as it became all too evident that the task was growing bigger and bigger. The organization must be better prepared next year so that several people with the ability and will to participate as Boost mentors are identified in advance.
Prepare a startup package. In order to facilitate the initial period of getting familiarized with the various Boost guidelines, protocols and tools, it would be extremely useful to prepare a compilation of startup material for students. This package can consist of a single document gathering the currently dispersed information, or go beyond this and provide some bundle of documentation and pre-built tools, an approach that one of the students is currently working on.
Public communication
students must get involved with the community as soon as possible and grow to appreciate the advantages of public development concerning solitary coding.
Mandate (bi)weekly reports. These reports should be directed to the public mailing lists to allow all Boost members to follow the work in progress and contribute. Reporting has the extra benefit for students of forcing them to reflect on their work periodically and struggle with the often difficult task of presenting their ideas to others.
Conduct student-mentor exclusively through public channels. This might be too drastic a policy, as some matters need privacy and depending on the amount of information exchanged flooding problems may arise. Less severe variations involve allowing for some private interchange at the mentors' discretion and moving this kind of communication to a dedicated public mailing list different from the general ones.
Project management
The two most important issues to improve upon with respect to the management are:
- Project scope must be kept under control,
- The progress has to be publicly visible, so that problems of scope, design and/or schedule can be more easily detected.
Some of the proposals in this section are not to be regarded as strict rules, but rather as general guidelines to be kept in mind by students and encouraged by mentors.
Create a best practices document. This document can serve as a guideline for project management, an area in which Boost traditionally imposes no requirements. Students might lack the expertise in this area that is usually taken for granted in the traditional model where contributions to Boost are made by professional programmers.
Mandate a design phase. Having a concrete design set up and clearly described early in the project will help estimate the necessary effort for completion of the work. This is also an opportunity for public discussion.
Maintain code, docs and tests in parallel. All too often, novice programmers do the coding in one fell swoop and only then move to testing and documenting their work. This is unacceptable by all current methodology standards, and can result in serious underestimations of the time to completion.
Encourage the KISS principle. It is much better to finish a simpler library and then iteratively evolve it, once it has been exposed to public scrutiny and usage.
More Trac updates. The repository should be viewed as an everyday work tool, not only as of the place into which to dump the final results. Updating often leads to more visibility of the work by the mentor and the public in general.
Informal reviews. The typical Summer of Code Boost project will not be completed by the official deadline, as have been discussed earlier. To somehow officialize the work done within the Summer of Code proper, and also to allow the students to reach some sort of psychological milestone, informal reviews can be instituted where Boost members evaluate the work done at the end of Summer of Code.
Engage students. This experience has shown that it is possible to guide willing and bright students to the competence levels required for contributing to Boost. The best possible outcome of Summer of Code campaigns are the incorporation of new people into the circle of Boost active contributors. Strive to make the students commit to Boost.
Conclusions
Despite the lack of previous experience in Boost, our participation in Google Summer of Code has been extremely fruitful: much useful material has been produced, and, perhaps more importantly, some of the students are likely to commit on a long-term basis and grow to be regular Boost contributors. Traditionally, becoming a productive Boost author has a very high entry barrier due to the extreme quality standards, lack of public support and the very specific culture of the project. The appeal of Summer of Code itself and the possibility of being gently mentored into the world of Boost has most likely been key factors in lowering this entry barrier.
The process has not been without some difficulties, either, as it was expected of a newcomer organization as Boost. We have tried to identify in this paper the areas of improvement and suggest specific actions so that the upcoming Google Summer of Code 2007 can be an even more rewarding experience.
Acknowledgements
This paper couldn't have been written without the numerous reports and contributions kindly provided by Boost students and mentors: Many thanks to all the participants for sharing their experiences with me. Thank you also to the people at Google who have promoted and conducted the Summer of Code initiative.


Preface
0.1 What is the IM Data Hub?
The Impact Maria (IM) Data Hub is a project monitoring system in DHIS2 used to collect, analyze, monitor and report Impact Malaria indicator data. It’s built on DHIS2 core software, and it supports HNQIS (1.4.X) compatibility.
0.2 Who should read this guide?
This guide is aimed at two main audiences:
- System Administrators who are involved in the configuration, maintenance and troubleshooting the IM Data Hub,
- IM Project teams and M&E staff involved in supporting M&E activities like data entry, reporting, data analysis and visualizations and project monitoring.
The audiences will find this guide helpful in understanding the overall system set up and how different components work together in the system.
0.3 What is covered in this guide.
The guide is divided into seven chapters:
- Introduction - offers some background information, primary setup, and how to get started on the IM Data Hub quickly.
- IM Data Hub Components - explores the basic set up to provide an understanding of the different components and how they function.
- Data Specification - builds on the IM Data Hub components and talks about the IM indicators and data reporting.
- Metadata Specifications - Explores the data specification and IM Data Hub components to talks about what lies at the bottom, the metadata.
- Security and Access Model - Explains the security mechanisms and access model implemented in the IM Data Hub.
- Health Network Quality Improvement System (HNQIS) - A brief overview of the HNQIS and how to get started.
- Getting help - Some guidance on how to get help in the IM Data Hub.
- References
0.4 What is not covered in this guide.
The focus of this guide is to walk you through the technical specification of the IM Data Hub. We attempt to showcase some best practices in configuring, testing, troubleshooting, reporting, monitoring, or use of data in the IM Data Hub. However, this is not a training on DHIS2 Foundamentals and you need other references to master these essential skill sets.
0.5 Conventions
This guide follows the following abbrevations.
| Abbreviation | In Full |
|---|---|
| CR | Case Reporting |
| CS | Country Specific |
| DX | Diagnosis |
| IM | Impact Malaria |
| MIP | Malaria In Pregnancy |
| PMP | Performance Management Plan |
| RE | Reporting |
| SMC | Seasonal Malaria Chemoprophylaxis |
| SS | Supportive Supervision |
| TL | Technical Leadership |
| TR | Training |
| TX | Treatment |
0.5.1 Data Sets
Data set: [country ISO code
] [Data entry form name
]:
Examples:
- GH Supportive Supervision
- CD Case Reporting
0.5.2 Data Elements
DEs: [country ISO code
] [Data entry form name abbreviation
] - [Section abbreviation
] [DE Form name
]:
Examples:
- GH CR - DX Cases confirmed
- CD TL - DX Does this province have national malaria diagnostic supervision tools that adhere to global standards?
0.5.3 Indicators
Indicators: [country ISO code
] [PMP
] [number
] - [Section abbreviation
] [Indicator name
]:
Example:
GH PMP 01 - DX Percentage of confirmed malaria cases


What will happen if your product’s design doesn’t appeal to your audience??
You’ll be forgotten in few seconds and won’t capture your their attention
Most websites now uses template which make them look the similar, they are lazy to design for their audience that will resonate, why become like them and instead standouts by designing a product that is appropriate for your audience?
You’ll be forgotten in few seconds and won’t capture your their attention
Most websites now uses template which make them look the similar, they are lazy to design for their audience that will resonate, why become like them and instead standouts by designing a product that is appropriate for your audience?
You’ll be forgotten in few seconds and won’t capture your their attention
Most websites now uses template which make them look the similar, they are lazy to design for their audience that will resonate, why become like them and instead standouts by designing a product that is appropriate for your audience?


Please identify yourself with name and organisation.
Your details have been copied from the previous certificate.
Given name(s)
Surname
Full name
Email address
Organisation
(advanced)
Comments
Crypto:
size
2048 (normal)
4096 (strong)
hash
SHA-1
SHA-256
SHA-512
Please enter the password of your current certificate key.
Password
You need to choose a password for your new key.
Your personal key is generated together with the request, and needs to remain private to you only.
Please choose your password carefully; it must not be easy to guess, but you need to remember it.
Password
I agree to the
privacy policy
of the DutchGrid CA


close
Close the connection to the database.
connect
Connect to the database server.
driver
Return database driver name.
execute(sql_query)
Perform a database query that expects no results.
Returns the number of rows affected.
option(key)
Retrieve an option value for the connection.
optionClear(key)
Clear a specific option associated with the connection.
optionPut(key,value)
Add an option key, value pair to the connection.
options
Retrieve an option list of the connection.
optionsClear
Clear all options associated with the connection
ping
Ping the database to see if it's alive.
Will return true if it is, otherwise false.
query(sql_query)
Perform a database query returning a DBIResult object.
queryOne([object], sql)
Perform a query and return the first
result.
If [object] is supplied, the object is populated with the contents of the
result, the result is marked done and the object is returned.
quote(value)
Quote a string value according to the database server's specifications.
sequenceLast([name])
Return the last inserted sequence value.
sequenceNext([name])
Return the next sequence that will be used during an INSERT query.
|


Herlings visited last night. Good times. Now that they're off, it's time to get down to yard work.
6/21/2008, 11:42:17 AM
Favs: 0
Retweets: 0
link--- layout: tweet ---
Herlings visited last night. Good times. Now that they're off, it's time to get down to yard work.
6/21/2008, 11:42:17 AM
Favs: 0
Retweets: 0
link


Important Notice
Membership is required to attend
HackSoc Events.
If you aren't already a member, you can join for free at
https://hacksoc.net/join


Aviation experts explain why plane window blinds have to be up during landing
Passengers are often asked to raise their plane window blinds by flight attendants just before landing takes place and it's actually to do with their safety
by Julie Delahaye, https://www.facebook.com/juliedjournoWhen you're on a flight, there are plenty of rules to follow such as no smoking, staying seated when the seatbelt signs are on etc.
But one rule that often puzzles passengers comes during take-off and landing, when flight attendants ensure that all plane window blinds are raised.
In fact, they will walk along the cabin and ask passengers to open any closed blinds - even if that means waking up a sleeping passenger.
However, they're not doing it just so that passengers can take in pretty views.
In fact, aviation experts have revealed on Quora that this plays a key role in passenger safety.
Overall, it seems to come down to two key reasons.
The first is to adjust passengers' eyes to the light outside, according to pilot Amitesh as well as some aviation enthusiasts.
For example, if you're starting with a day flight that lands at night, or vice versa, it gives you time to acclimatise to the light and also ensures you have good vision should there be an emergency.
Airlines tend to aim to complete evacuations in 90 seconds, so having passengers who can easily see where they are going can be a major help - it's also why the cabin lights are dimmed before plane landings at night time.
The second reason?
Former pilot John Keese explains on the thread that it's useful in an emergency for people - whether that be cabin crew or passengers - to see what is going on outside the cabin.
With all of the window blinds up, in the event of an emergency it means that cabin crew can have a clearer picture of what is going on and assess the situation.
For example, in the rare case of an evacuation, they can check that the surroundings are safe before people disembark from the plane.
The extra benefit is that, with the plane windows raised, passengers can see out of the windows easily and can spot any potential issues.
With pilots in the cockpit and the flight attendants often sat on either end of the plane during landing, the passengers become invaluable pairs of eyes and can flag any problems they can see from their seat.
In extreme situations, it also allows emergency services to be able to see inside the plane.


Home
(current)
About
History
Testimonies
Crossroad School of Discipleship
Contact
"Here am I. Send me!"
Isaiah 6:8
OUTREACH
IGNITE
LECTURES
CULTURAL NIGHT
DINE 2021
---------------
Dates: Jul - Aug (Dates to be announced soon)
Venue: Divine Retreat Center, UK
Cost: 250 £ (Full Board)


Back To Top
| Home
Marvel | DC
Star Wars
City
Marvel/DC
Clash of Universes
Track and Field
Fruit Ninja
Typical Saturday
Teen Titan
Social Activist
The Mask-Ed Man


Add a polygon to a map using a GeoJSON source
This sample loads Mapbox styles of a GeoJSON polygon into Azure Maps. This sample is based on this
Mapbox example
.