Fake rhino horn invented to ruin poachers' market
by Sean CoughlanScientists have developed a technique for making fake rhino horn, which they hope will undermine the illegal market in the genuine article.
Researchers at the University of Oxford and Fudan University in China have found a way of making fake rhino horn cheaply from horse hair.
Demand for rhino horn has been blamed for driving poaching and threatening the survival of the species.
The Oxford team said the fakes would "confuse the trade".
But there has been some scepticism about whether this will be effective - with Save the Rhino International warning it could inadvertently stimulate the market for rhino horn.
The conservation charity says it is more important to focus on anti-poaching measures and attempts to reduce consumer demand.
Financial attack
Rhino horn has been claimed as an aphrodisiac in traditional Chinese medicine - which has sustained demand despite official attempts to prevent the trade.
This joint UK and Chinese project is the latest attempt to find a way of making artificial horn that is realistic enough to be convincing, with the aim of flooding the market with fakes and undermining the financial incentives for poachers and smugglers.
There have been previous ideas for fake horn, but this project wants a credible version that can be cheaply mass-produced.
The scientists say the "horn" of a rhino is not like the horn of a cow, but is formed from tufts of tightly packed hair that are glued together by secretions from the animal.
And the team of zoologists in Oxford and molecular scientists in Fudan University in Shanghai have developed a way of compressing and moulding horse hair in a way that looks and feels similar even when the "horn" is cut.
If credible fakes could be produced cheaply, the scientists say it would cut prices and reduce the incentive for killing the rhinos.
"It appears from our investigation that it is rather easy as well as cheap to make a bio-inspired horn-like material that mimics the rhino's extravagantly expensive tuft of nose hair," said Prof Fritz Vollrath, from the University of Oxford's Department of Zoology.
He said he hoped the technique could be used to "confuse the trade, depress prices and thus support rhino conservation".
Unintended consequence?
But John Taylor, deputy director of Save the Rhino International, is unconvinced how much fake horn would reduce the threat to rhinos.
He says there is a risk that attempts to "flood the market" would have the unintended consequence of expanding the market and creating even more demand, which could cause even more poaching for real rhino horn.
He also questions how in practice fake horn could be inserted into an illegal black market trade.
Mr Taylor is not certain that artificial horn would really convince two of the main markets - where it is ground up for traditional Chinese medicine and where wild rhino horn is used as a status symbol, particularly in Vietnam.
"There is no substitute for anti-poaching measures at one end and reducing demand at the other," he says.


A two-dimensional Euclidean vector with 16-bit integer precision.
The Vector2int16 type represents a two-dimensional Euclidean vector with 16-bit integer precision.
Returns the zero vector.
The new constructor returns the origin vector, where each coordinate is 0.
Returns a vector composed by each given coordinate.
The new constructor returns a vector composed by each given component.
The X coordinate.
The X field returns the X coordinate of the vector.
The Y coordinate.
The Y field returns the Y coordinate of the vector.
The sum of two vectors.
The add operator returns a vector where each corresponding component of the two operands are summed.
The difference between two vectors.
The sub operator returns a vector where each corresponding component of the two operands are subtracted.
Multiplies each corresponding component.
The mul operator returns a vector where each corresponding component of the two operands are multiplied.
Multiplies each component.
The mul operator returns a vector where each component of the first operand is multiplied by the second operand.
Divides each corresponding component.
The div operator returns a vector where each corresponding component of the two operands are divided.
Divides each component.
The div operator returns a vector where each component of the first operand is divided by the second operand.
Returns whether two Vector2int16 values are equal.
The equal operator returns true if both operands are Vector2int16, and each corresponding component is equal.
The negation of the vector.
The unm operator returns a vector where each component is negated.


Keyword(s) for which to search:
Sort results by title
Keyword Index
Direct Link
Org.CBCrypt Namespace
CBCrypt Class
CBCrypt Members
CBCrypt Methods
GenerateHighCostSecret Method
GenerateKeyPair Method
GenerateKeyPair Method (String, String, String)
GenerateKeyPair Method ()
CBCryptKey Class
CBCryptKey Members
CBCryptKey Constructor
CBCryptKey Constructor (String, String, String)
CBCryptKey Constructor ()
CBCryptKey Constructor (AsymmetricCipherKeyPair)
CBCryptKey Methods
GetPublicKeyDerEncoded Method
GetPublicKeyDerEncoded Method (AsymmetricCipherKeyPair)
GetPublicKeyDerEncoded Method
GetSharedSecret Method
GetSharedSecret Method (AsymmetricCipherKeyPair, )
GetSharedSecret Method ()
CBCryptKey Properties
Key Property
Challenge Class
Challenge Members
Challenge Constructor
Challenge Methods
GenerateChallengeResponseBytes Method
GetServerPublicDer Method
TryValidateChallengeResponse Method
Challenge Properties
CBCryptHostId Property
ChallengeBytes Property
ServerPublicKeyDerEncoded Property
ChallengeResponse Class
ChallengeResponse Members
ChallengeResponse Constructor
ChallengeResponse Methods
ChallengeResponse Properties
ChallengeResponseBytes Property
PublicKeyDerEncoded Property
This page uses an IFRAME but your browser does not support it.


Details for Participants of Civic Switchboard Workshop
NNIP Preconference, May 8, 2018, Atlanta, GA
Time and Place
Tuesday, May 8, from 11:30am to 5:00pm
Atlanta Regional Commission
229 Peachtree ST NE, STE 100
Atlanta, GA 30303
The Atlanta Regional Commission provides directions and travel information here.
Lunch and snacks will be provided. Lunch will include vegetarian and gluten-free options. If you have any other dietary needs, please let us know.
Agenda
11:30am - 12:00pm - Participants arrive, lunch food is served
-
We'll have lunch ready as you arrive and we'll eat together before the workshop program starts at noon
12:00pm - 12:30pm - Welcome, Introductions, Workshop Logistics
-
Including a brief overview of Civic Switchboard project, and brief introductions from workshop participants
12:30pm - 2:05pm - Mapping Ecosystem Activity
-
Why we advocate for ecosystem mapping; hands-on creation of your own ecosystem map; a chance to
look at what other teams have produced. If you have done ecosystem mapping before, great! ...we'll have some prompts that will
make this a fresh experience.
2:05pm – 3:00pm – Building Partnership Activity
-
A brief typology of civic data roles that include libraries; teams consider a project to conduct as a team;
use ecosystem map to situate your work and to identify who should be involved; teams
create a worksheet capturing next steps.
3:00pm – 3:30pm - Social Break / snacks / propose and form Birds of a Feather groups.
-
During break, participants consider: What would you like to dive into with a group? What questions are most
pressing for you? Post ideas on wall; Civic Switchboard team will cluster topics into Birds of a Feather groups
3:30pm – 4:15pm - Birds of a Feather Sessions
-
BoF sessions take place -- OK to split up members of a team for this part! Also OK to move between groups as
your interest directs you.
4:15pm – 5:00pm - Wrap-up
-
All back together -- What are your takeaways? What will you do when you are back home? Also some logistical
wrap-up and workshop evaluation.
Workshop Code of Conduct
All attendees, speakers, sponsors and volunteers at the Civic Switchboard workshop are required to agree with the following code of conduct. Organizers will enforce this code throughout the event. We expect cooperation from all participants to help ensure a safe environment for everybody.
Need Help?
Contact us during the workshop by email at<EMAIL_ADDRESS>(Eleanor),
<EMAIL_ADDRESS>(Bob), or by phone:<PHONE_NUMBER> (Eleanor) or<PHONE_NUMBER> (Bob),
or talk to any Civic Switchboard organizer.
Civic Switchboard is dedicated to providing a harassment-free workshop experience for everyone, regardless of gender, gender identity and expression, age, sexual orientation, disability, physical appearance, body size, race, ethnicity, religion (or lack thereof), or technology choices. We do not tolerate harassment of workshop participants in any form. Sexual language and imagery is not appropriate for any workshop venue, including talks, workshops, parties, Twitter and other online media. Workshop participants violating these rules may be sanctioned or expelled from the conference without a refund at the discretion of the conference organizers.

Participants asked to stop any harassing behavior are expected to comply immediately.
If a participant engages in harassing behavior, the workshop organizers may take any action they deem appropriate, including warning the offender or expulsion from the workshop with no refund.
If you are being harassed, notice that someone else is being harassed, or have any other concerns, please contact a member of the Civic Switchboard organizing team immediately.
Civic Switchboard organizers will be happy to help participants contact hotel/venue security or local law enforcement, provide escorts, or otherwise assist those experiencing harassment to feel safe for the duration of the conference. We value your attendance.
We expect participants to follow these rules at throughout the workshop and workshop-related social events.
In addition to having a code of conduct as an anti-harassment policy, in order to foster a productive and inclusive meeting environment, we ask that all workshop participants adhere to the following guidelines and principles for National Neighborhood Indicators Partnership meetings described here: https://www.neighborhoodindicators.org/library/guides/code-conduct-nnip-partner-meetings
Contact
Team
- Aaron Brenner, The University Library System (ULS) at the University of Pittsburgh
- Bob Gradeck, Western Pennsylvania Regional Data Center (WPRDC)
- Toby Greenwalt, Carnegie Library of Pittsburgh (CLP)
- Nora Mattern, The University Library System (ULS) at the University of Pittsburgh
- Liz Monk, Western Pennsylvania Regional Data Center (WPRDC)
- Kathy Pettit, National Neighborhood Indicators Partnership (NNIP)
- Eleanor Tutt, Carnegie Library of Pittsburgh (CLP)


This project shows how to use the dependency injection mechanism in Play2.5 to communicate with a Couchbase Db.
Once the application has been compiled and the server started, your application can be accessed at: http://localhost:9000.
The inventory of all available routes is available at routes.
The project consist of the following main classes:


Welcome to the Mindfulness Room at CMU This is a place where you... can Meditate Nap Relax Read Refresh can't Do homework Use technology Hold meetings Talk loudly Disrupt others


The main reason why
After all, I am still an Internal Auditor. Therefore I often face one of the typical internal auditors problems: understand links between people and companies, in order to discover the existence of hidden communities that could expose the company to unknown risks.
the solution: linker
In order to address this problem I am developing Linker, a lean shiny app that take 1 to 1 links as an input and gives as output a network map:
[caption id="attachment_324” align="aligncenter” width="300”] click the picture to reach the app[/caption]
**Linker **is packed with a demo network, but you can easily load your dataset following the tutorial below.
how to use linker ( and some code specs)
the one that follow is a tutorial with some focus on code, if you are interested in giving a look to the full reprocudibile Rstudio project, I make it available at the end of the post.
describing data
Linker is only able to read .csv datasets, structured as “hedge-to-hedge” tables.
This mean you will have to create a two-column table, having on each row a link.
For instance, suppose A is linked with B, C is linked with A and B is linked with D; this will be your dataset:
be sure to set “;” as a separator in your .csv file.
loading data
using the ‘load file’ control you can choose the dataset to load.
connecting dots
Linker leverages the great features builted in the **linkComm package **by Alex T. Kalinka and Alain Guenoche .
Therefore, the first step required is to create a linkComm object, containing the network map and informations about founded communities.
This object is obtained through the getLinksCommunities() function. This function takes your dataset as an input and, applying a clustering method, gives as an output the network map aggregated by community.
[code language="r”] links_graph <- getLinkCommunities(links_file(),hcmethod="mcquitty”, use.all.edges = TRUE) [/code]
just note that:
-
Linker use as hierarchical clustering method the mcquitty method. There are other clustering methods available. just type ?getLinkCommunities() in your console to discover them;
-
the parameter use.all.edges is set to TRUE in order to show in the network all member of your networks.
Plotting the map
as soon as Linker creates the getLinkCommunities object, it will return, in the"network map” area, a visual representation of your network.
the default graph is the spencer circle, a graph developed by Rob Spencer starting from a 2010 paper by Yong-Yeol Ahn , James P. Bagrow and Sune Lehmann .
If you prefer, you can change the graphing layout to circle.
I think this second way is a bit more clearer, even if is not as impacting as the Spencer Circle.
Advanced topics
highligthing most relevant subjects
not all the subjects in your network have got the same relevance. If you want to focus just on the most influent subjects, you can use the “number of communities” option.
This option lets you focus on subjects being part of** at least n communities**, starting from one to infinite.
code spec
the option uses the shownodesin argument
[code language="r”] shownodesin = input$"n_input” [/code]
focusing on a single community
If you want to focus on a single community, you can just type the community id into the ‘community to focus on’.
Community's id are printed around the circle in the spencer circle layout.
code spec
these option is builted using the clusterids argumenti within the plot function:
[code language="r”] clusterids = c(as.numeric(input$selected_communities)) [/code]
export your map
this is not actually a feature created within the application, but could be better described as a trick:
if you want to export your map, just right-click on the map and select “save image”.
the Rstudio Project.
to download the full project, just click the button below.
download the Linker R studio project App
If you found Linker useful, you may be interested in other Shiny Apps I developed for analytics and productivity purposes. Find them out at software page
Icons made by Google from www.flaticon.com is licensed under CC BY 3.0


browserify-as-a-service
Places
- fork me on github
- browserify on the web
- browser-module-sandbox - helpful for using multi-bundles
- requirebin.com - powered by wzrd.in
- esnextb.in - also powered by wzrd.in
Quick Start
Try visiting this link:
/standalone/concat-stream@latest
What just happened?
Well, in this case, since someone has visited this link before you, the file was cached with leveldb. But if you were to try and grab a bundle that nobody else has tried to grab before, what would happen is this:
- The module gets pulled down from npm and installed
- The module gets browserified as a standalone bundle
- The module gets sent to you, piping hot
- The module gets cached so that you don't have to wait later on
API
There are a few API endpoints:
GET /bundle/:module
Get the latest version of :module.
GET /bundle/:module@:version
Get a version of :module
which satisfies the given :version
semver range. Defaults to latest.
GET /debug-bundle/:module
GET /debug-bundle/:module@:version
The same as the prior two, except with --debug
passed to browserify.
GET /standalone/:module
GET /standalone/:module@:version
In this case, --standalone
is passed to browserify.
GET /debug-standalone/:module
GET /debug-standalone/:module@:version
Both --debug
and --standalone
are passed to browserify!
POST /multi
POST a body that looks something like this:
{
"options": {
"debug": true
},
"dependencies": {
"concat-stream": "0.1.x",
"hyperstream": "0.2.x"
}
}
"options" is where you get to set "debug", "standalone", and "fullPaths".
Usually, in this case, you'll probably only really care about debug. If you
don't define "options", it will default to
{ "debug": false, "standalone": false, "fullPaths": false }
.
What you get in return looks something like this:
HTTP/1.1 200 OK
X-Powered-By: Express
Location: /multi/48GOmL0XvnRZn32bkpz75A==
content-type: application/json
Date: Sat, 22 Jun 2013 22:36:32 GMT
Connection: keep-alive
Transfer-Encoding: chunked
{
"concat-stream": {
"package": /* the concat-stream package.json */,
"bundle": /* the concat-stream bundle */
},
"hyperstream": {
"package": /* the hyperstream package.json */,
"bundle": /* the hyperstream bundle */
}
}
The bundle gets permanently cached at /multi/48GOmL0XvnRZn32bkpz75A==
for
future GETs.
GET /multi/:existing-bundle
If you saved the Location url from the POST earlier, you can just GET it instead of POSTing again.
 Returns build information for all versions which satisfy the given semver (or latest in the event of a missing semver).
Blobs generally look something like this:
HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Content-Length: 109
ETag: "-9450086"
Date: Sun, 26 Jan 2014 08:05:59 GMT
Connection: keep-alive
{
"module": "concat-stream",
"builds": {
"1.4.1": {
"ok": true
}
}
}
The "module" and "builds" fields should both exist. Keys for "builds" are the versions. Properties:
- "ok": Whether the package has last built or not
- "error": If the package was built insuccessfully ("ok" is false), this property will contain information about the error
Versions which have not been built will not be keyed onto "builds".
Heroku Installation
browserify-cdn is ready to run on Heroku:
heroku create my-browserify-cdn
git push heroku master
heroku ps:scale web=1
Docker Installation
You can build and run an image doing the following:
docker build -t "wzrd.in" /path/to/wzrd.in
docker run -p 8080:8080 wzrd.in
Keep in mind that a new deploy will wipe the cache.
License
MIT


Logo
Home
About
Info
Services
Contact
Like Nature
Be Creative!
This is tutorial how to make beautiful page using html css and JavaScript
More Information


Wishlist.pm
Code Index:
Wishlist.pm - Perl Module to manage Gift Wishlists
This document refers to version 0.80 of Christmas::Wishlist, released Jan
1, 2003.
include Christmas::Wishlist;
$wl = Christmas::Wishlist->new(userid=>$user, create=[0|1], path=<dirpath>);
$wl->suggest_update(by=>, [itemnum=>], description=>, requested=>, expires=>);
$wl->remove(by=>, itemnum=>, description=>, howmany=>);
$wl->purchase(by=>, itemnum=>, description=>, howmany=>);
$wl->item( );
@itemlist = $wl->get_items( );
$wl->userid();
$wl->last_update();
- "error message that may appear"
-
Explanation of error message
Move NEWTRANS into object.
Change to explicit parameters to new in suggest_update
Bad data in the file should be reported, not cause a failure to return. For
instance, bad date fields should be appropriately reported as ``Bad''.
Michael G. Birdsall
Copyright (c) 2002,2003, Michael G. Birdsall. All Rights Reserved. This
module is free software. It may be used, redistributed and/or modified
under the same terms as Perl itself.
#!/usr/local/bin/perl -w
# $Id: Wishlist.pm,v 1.18 2003/01/17 03:58:32 mbirdsal Exp $
# $Name: $
#
# Module to manage user wishlist objects.
# Wishlists are stored in a file in the repository at $defdir
# The filename is wishlist.<owner> where <owner> is the userid
# of the person whose wishlist it is.
#
# The file can have commentary records starting with a #
# or transaction records including:
# |<when> <whom> added <author> <description> <needed> <expires>
# |<when> <whom> bought <author> <description> <num-bought>
# |<when> <whom> delete <author> <description>
#
# where fields are separated by tabs.
#
# Modules:
# new
# suggest_update
# remove
# purchase
# item
# get_items
# last_update
#
package Christmas::Wishlist;
use lib "/users/m/mbirdsal/perllib/";
use Christmas::Wishlist::WishItem;
use Time::Local;
use Data::Dumper;
use Carp;
use strict;
#_____________________________________________________________________________
# Ultimately, a repository will probably need to be an attribute of a wishlist,
# or an object all on its own.
# For now, we use a closure to make it a class attribute.
{
my $defdir;
# Common values on a bert or on mbirdsal are:
# "/users/m/mbirdsal/apache/htdocs/family/data/";
# "/big/dom/xkirkbird/www/mbirdsall/family/data/";
sub set_repository
{
shift;
$defdir = shift;
return $defdir;
}
sub _get_repository
{
return $defdir;
}
}
#_____________________________________________________________________________
# Create a wishlist object
#
# Attributes to add to the object: Last Updated
sub new
{
my $class = shift;
$class = ref($class) || $class;
my $self = bless {}, $class;
return $self->_init(@_);
}
#_____________________________________________________________________________
# Set the initial data
#
# Arguments: a hash contain the following keyed items:
# userid => login id of the user whose wishlist is being initialized (req)
# path => a repository path for the wishlist (optional); defaults to the
# directory set with set_repository
# create => determines special create checks if defined (boolean)
# false -> fail if the wishlist isn't already in existence
# (refuse to create a new wishlist)
# true -> fail if the wishlist is already in existence
# (refuse to use an existing wishlist
# when => records the time the wishlist was last updated
#
sub _init
{
my ( $self, %arg ) = @_;
%$self = (
_userid => $arg{userid} || croak("missing userid"),
_path => $arg{path} || $self->_get_repository,
_item => [],
_last_update => "unknown",
);
# form filename
my $fname = $self->_filename();
# If wishlist already exists
if ( -f $fname && -s _ ) {
return if ( defined $arg{create} and $arg{create} );
# Read the file and initialize the object from the data
$self->_read($fname);
open( NEWTRANS, ">>$fname" );
} else {
return if ( defined $arg{create} and !$arg{create} );
# Create the file
open( NEWTRANS, ">" . $fname );
$self->_write_header();
#If this is a truly new file, this is the time of last update
$self->{_last_update} = localtime;
}
return $self;
}
#_____________________________________________________________________________
#
# _numeric_time
# returns the local (seconds from start of epoch) time for a time string
# formatted like the return from scalar localtime
#
sub _numeric_time
{
my ($time) = @_;
my (%numericmonth) = (
Jan => 0,
Feb => 1,
Mar => 2,
Apr => 3,
May => 4,
Jun => 5,
Jul => 6,
Aug => 7,
Sep => 8,
Oct => 9,
Nov => 10,
Dec => 11
);
my ( $mmm, $dd, $hh, $min, $sec, $yyyy ) =
( $time =~ /\w*\s+(\w{3})\s+(\d*)\s+(\d+):(\d+):(\d+)\s+(\d+)/ );
return timelocal( $sec, $min, $hh, $dd, $numericmonth{$mmm}, $yyyy - 1900 );
}
#
# _date_parts
# Breaks o date of the form:
# Sat Jan 11 17:00:55 2003
# out to get just the date information, e.g. qw(Jan 11 2003)
sub _date_parts
{
my ($dstring) = @_;
return ( $dstring =~ /\w*\s+(\w{3})\s+(\d*)\s+\d+:\d+:\d+\s+(\d+)/ );
}
#_____________________________________________________________________________
#
# _read - reads the wishlist file whose name is passed and update the wishlist
# items based on the log in that file
sub _read
{
my ( $self, $fname ) = @_;
open( NEWTRANS, "$fname" );
while (<NEWTRANS>) {
chomp;
next if /^\s*#/;
next if /^\s*$/;
my ( $time, $author, $transcode, $itemnum, $descrip, $num, $expdate ) =
split (/\t/);
my ($update_time) = _numeric_time($time);
# Handle the proper transactions
SWITCH: {
if ( $transcode =~ /^add/ ) {
unless ( defined $expdate ) {
# Set an expiration date one year after the add
my ( $mmm, $dd, $yyyy ) = _date_parts($time);
$yyyy++;
$expdate = "$mmm $dd $yyyy";
}
$self->_update( $itemnum, $descrip, $num, $author, $update_time,
$expdate );
last SWITCH;
}
if ( $transcode =~ /^del/ ) {
$self->_delete( $itemnum, $update_time );
last SWITCH;
}
if ( $transcode =~ /^bou/ ) {
$self->_bought( $itemnum, $descrip, $num, $author );
last SWITCH;
}
}
}
}
#_____________________________________________________________________________
# Create the filename for a wishlist
# Uses the path and userid to create the full path to the wishlist file
sub _filename
{
my ( $self, %arg ) = @_;
return $self->{_path} . "wishlist." . $self->{_userid};
}
#_____________________________________________________________________________
#
# _write_header
#
# Writes the header lines at the top of a new wishlist file
sub _write_header
{
my ($self) = @_;
my $userid = $self->{_userid};
print NEWTRANS _unindent(<<"ENDHEADER");
#Defining a wishlist for $userid
#Local Day, Time, and Date\twho\top\tident\tdescription\tnum\texpires
ENDHEADER
}
#_____________________________________________________________________________
#
# _update
# changes the object using the information in a logfile add transaction
#
# Part of the 'read" subsystem that deals with an existing wishlist.
sub _update
{
my ( $self, $itemnum, $descrip, $num, $author, $update_time, $expires ) =
@_;
if ( defined $self->item($itemnum) ) {
$self->item($itemnum)->description($descrip);
$self->item($itemnum)->requested($num);
$self->{_last_update} = $update_time;
$self->item($itemnum)->expiration_date($expires);
} else {
$self->{_item}[ $itemnum - 1 ] = Christmas::Wishlist::WishItem->new(
for => $self->{_userid},
by => $author,
requested => $num,
description => $descrip,
ident => $itemnum,
expires => $expires,
);
$self->{_last_update} = $update_time;
}
}
#_____________________________________________________________________________
#
# _tranlog
# Creates a properly formatted transaction line to the log for this transaction
sub _tranlog
{
my (%args) = @_;
$args{expires} ||= " ";
return join (
"\t",
(
scalar localtime, $args{by}, $args{transcode},
$args{itemnum}, $args{description}, $args{how_many},
$args{expires},
)
);
}
#_____________________________________________________________________________
#
# _print_log
#
sub _print_log
{
my (%args) = @_;
my $string = _tranlog(%args);
print NEWTRANS "$string\n";
}
#_____________________________________________________________________________
#
sub remove
{
my ( $self, %args ) = @_;
$self->_delete( $args{itemnum}, time );
$args{transcode} = "delete";
_print_log(
by => $args{by},
transcode => "delete",
itemnum => $args{itemnum},
description => $args{description},
how_many => $args{how_many},
);
}
#_____________________________________________________________________________
# _delete - removes a deleted item from the wishlist object
# Both part of the 'read" subsystem that deals with an existing wishlist, and
# the subsystem that processes new requests.
sub _delete
{
my ( $self, $itemnumber, $update_time ) = @_;
# Note that the item index is 1 less than the item number
return unless ( defined $self->{"_item"}[ $itemnumber - 1 ] );
$self->{"_item"}[ $itemnumber - 1 ]->deleted(1);
$self->{"_last_update"} = $update_time;
return $self;
}
#_____________________________________________________________________________
#
# purchase - updates item and writes transaction log
# need to add record of who purchased
# Args: Hash with element keys:
# itemnum
# description
# by
# how_many
sub purchase
{
my ( $self, %args ) = @_;
return
unless $args{itemnum}
and defined $args{description}
and $args{by}
and $args{how_many};
return
if (
!$self->_bought(
$args{itemnum}, $args{description}, $args{how_many}, $args{by}
)
);
_print_log(
by => $args{by},
transcode => "bought",
itemnum => $args{itemnum},
description => $args{description},
how_many => $args{how_many},
);
return 1;
}
#_____________________________________________________________________________
#
sub _bought
{
my ( $self, $itemnum, $descrip, $num, $by ) = @_;
my $item = $self->item($itemnum);
return $item->buy( $num, $descrip, $by );
}
#_____________________________________________________________________________
#
# suggest_update
# Creates or modifies a suggestion and writes it out to the transaction log
sub suggest_update
{
my ( $self, %args ) = @_;
return unless $args{by} and $args{requested} and $args{description};
if ( $args{itemnum} ) {
$self->_update(
$args{itemnum}, $args{description}, $args{requested},
$args{by}, $args{expires},
);
} else {
delete $args{itemnum}; # In case it exists but is undefined.
# Should probably pass the arguments explicitely, rather than
# pulling things like the previous line.
my $newitemindex = $#{ $self->{_item} } + 1;
# $args{for} = $self->{_userid};
# $args{ident} = $newitemindex + 1;
my $newitem = Christmas::Wishlist::WishItem->new(
%args,
for => $self->{_userid},
ident => $newitemindex + 1
);
$self->{_item}[$newitemindex] = $newitem;
$args{itemnum} = $newitemindex + 1;
}
_print_log(
by => $args{by},
transcode => "added",
itemnum => $args{itemnum},
description => $args{description},
how_many => $args{requested},
expires => $args{expires},
);
return $args{itemnum};
}
#_____________________________________________________________________________
#
sub userid
{
my ($self) = @_;
return $self->{_userid};
}
#_____________________________________________________________________________
#
sub item
{
my ( $self, $num ) = @_;
# The item index is 1 less than the item number
return $self->{_item}[ $num - 1 ];
}
#_____________________________________________________________________________
#
sub last_update
{
my ($self) = @_;
return $self->{_last_update};
}
#_____________________________________________________________________________
#
sub get_items
{
my $self = shift;
return @{ $self->{_item} };
}
#_____________________________________________________________________________
#
sub _unindent
{
my $string = shift;
$string =~ s/^\s+//gm;
return $string;
}
1;
#_____________________________________________________________________________
__END__


Toggle navigation
Home
Services
About
Product
SEALANT
ADHESIVE
SLIM DUCT
Brands
Contact
arrow_back
Slim Duct System
Slim Duct
SLIM DUCT
Product No.
A
B
C
D
E
F
G
PCS/PKG
SD-75-HR
75
60
37.5
78
73
73
2000
5
Relate Product


American artist Alexander Calder changed the course of modern art by developing an innovative method of sculpting, bending, and twisting wire to create three-dimensional “drawings in space.” Resonating with the Futurists and Constructivists, as well as the language of early nonobjective painting, Calder’s mobiles (a term coined by Marcel Duchamp in 1931 to describe his work) consist of abstract shapes made of industrial materials––often poetic and gracefully formed and at times boldly colored––that hang in an uncanny, perfect balance.
Master changes1
=======
American artist Alexander Calder changed the course of modern art by developing an innovative method of sculpting, bending, and twisting wire to create three-dimensional “drawings in space.” Resonating with the Futurists and Constructivists, as well as the language of early nonobjective painting, Calder’s mobiles (a term coined by Marcel Duchamp in 1931 to describe his work) consist of abstract shapes made of industrial materials––often poetic and gracefully formed and at times boldly colored––that hang in an uncanny, perfect balance.
Lorem ipsum dolor sit amet, consectetur adipisicing elit. A aliquid atque commodi dolor est nobis veniam! Eius rerum, unde. Accusamus corporis esse eveniet exercitationem fugiat harum pariatur sequi similique tenetur vitae. Aliquam amet est excepturi, exercitationem facere fugit ipsa laborum molestiae nemo officiis placeat quos repellat saepe temporibus voluptatum.


Taking a look at the user settings¶
The smallest part of PetBlocks are the user settings. Make sure you have understood the introduction to this topic.
These are some of the available user settings in PetBlocks. All user settings are listed up in the Customizing section.
config.yml
pet:
enabled: false
name: "<player>'s Pet"
sound-enabled: true
particle-enabled: true
User settings are just values which are too basic to be ais and should be able to be changed by the user. The enabled: tag for example, states if the pet of a player is enabled or not.
Let’s change the enabled tag in the config.yml. This means if a player joins for the first time, the pet is already enabled and will spawn in front of him.
config.yml
pet:
enabled: true
name: "<player>'s Pet"
sound-enabled: true
particle-enabled: true
Unfortunately, you have already got your pet and it does not get overwritten when the config.yml changes. All of your pet properties are stored in the PetBlocks.db file. This is not a problem at all as we can reset the pet of a player easily.
Reload the config changes into the plugin via /petblockreload
Reset your pet to the default pet via /petblocks reset
Rejoin your server
You can see that your pet instantly spawns instead of having to enable it first after resetting.


Gecode::CommitTraceInfo Class Reference
Commit trace information.
More...
#include <core.hpp>
List of all members.
Public Member Functions |
| unsigned int | id (void) const |
| | Return brancher identifier.
|
| BrancherGroup | group (void) const |
| | Return brancher group.
|
| const Brancher & | brancher (void) const |
| | Return brancher.
|
| const Choice & | choice (void) const |
| | Return choice.
|
| unsigned int | alternative (void) const |
| | Return alternative.
|
Protected Member Functions |
| | CommitTraceInfo (const Brancher &b, const Choice &c, unsigned int a) |
| | Initialize.
|
Protected Attributes |
| const Brancher & | b |
| | Brancher.
|
| const Choice & | c |
| | Choice.
|
| unsigned int | a |
| | Alternative.
|
Related Functions |
(Note that these are not member functions.)
|
| template<class Char , class Traits > |
std::basic_ostream< Char,
Traits > & | operator<< (std::basic_ostream< Char, Traits > &os, const CommitTraceInfo &cti) |
| | Print commit trace information.
|
Detailed Description
Commit trace information.
Definition at line 995 of file core.hpp.
Constructor & Destructor Documentation
| Gecode::CommitTraceInfo::CommitTraceInfo |
( |
const Brancher & |
b, |
|
|
const Choice & |
c, |
|
|
unsigned int |
a | |
|
) |
| | [inline, protected] |
Member Function Documentation
| unsigned int Gecode::CommitTraceInfo::id |
( |
void |
|
) |
const [inline] |
Return brancher identifier.
Definition at line 3348 of file core.hpp.
| BrancherGroup Gecode::CommitTraceInfo::group |
( |
void |
|
) |
const [inline] |
Return brancher group.
Definition at line 3352 of file core.hpp.
| const Brancher & Gecode::CommitTraceInfo::brancher |
( |
void |
|
) |
const [inline] |
| const Choice & Gecode::CommitTraceInfo::choice |
( |
void |
|
) |
const [inline] |
| unsigned int Gecode::CommitTraceInfo::alternative |
( |
void |
|
) |
const [inline] |
Return alternative.
Definition at line 3364 of file core.hpp.
Friends And Related Function Documentation
template<class Char , class Traits >
| std::basic_ostream< Char, Traits > & operator<< |
( |
std::basic_ostream< Char, Traits > & |
os, |
|
|
const CommitTraceInfo & |
cti | |
|
) |
| | [related] |
Print commit trace information.
Definition at line 113 of file print.hpp.
Member Data Documentation
The documentation for this class was generated from the following files:


The randomness comes from atmospheric noise, which for many purposes is better than the pseudo-random number algorithms typically used in computer programs.
Set min, max length of the password [min=8; max=52 characters]
Value min:
Value max:
Fisher–Yates shuffle
Sattolo cycle


Ezekiel 23:21
Thus thou calledst to remembrance the lewdness of thy youth, in bruising thy teats by the Egyptians for the paps of thy youth.


Toggle navigation
IWC SCHAFFMAUSEN
COLLECTION
EXPERIENCES
RETAIL&SERVICE
FORUM
SIGN IN
REGISTER
IWC
INTERNATIONAL WATCH CO.SCHAFFMAUSEN
SWITZERLAND,SINCE 1968
FROM THE COLLECTION
PORTOFINO HAND-WOUND EIGHT DAYS
New for 2011,IWC proudly releases a new line of your Portofino timepieces
INSIDE IWC
NEW IWC-MANUFACTURED 59210 CALIBRE
The new 59210 calibre is large,accurate and features an eight-day power reserve.
EXPERIENCES
LEONARDO-DAYS IN PORTOFINO
Time moves on.Only in Portofino does it stand still.See Leonardo's stunning photos
WHERE HAS YOUR IWC BEEN
+
Submit
+
Register
First Name:
Last Name:
Male
Female
Other
Email:
Password:
Birthday:
jan
feb
1
2
1998
1999
I agree to the terms and conditions:
submit


{{ address.address1 }} {{ address.zip_or_postal_code }}, {{ address.city }}, {{ address.country }}
{{ address.phone_number }} {{ address.email }}


List public organization memberships for the specified user.
This method only lists public memberships, regardless of authentication. If you need to fetch all of the organization memberships (public and private) for the authenticated user, use the List organizations for the authenticated user API instead.
GET /users/:username/orgs
Status: 200 OK
Link: <https://api.github.com/resource?page=2>; rel="next",
<https://api.github.com/resource?page=5>; rel="last"
[
{
"login": "github",
"id": 1,
"node_id": "MDEyOk9yZ2FuaXphdGlvbjE=",
"url": "https://api.github.com/orgs/github",
"repos_url": "https://api.github.com/orgs/github/repos",
"events_url": "https://api.github.com/orgs/github/events",
"hooks_url": "https://api.github.com/orgs/github/hooks",
"issues_url": "https://api.github.com/orgs/github/issues",
"members_url": "https://api.github.com/orgs/github/members{/member}",
"public_members_url": "https://api.github.com/orgs/github/public_members{/member}",
"avatar_url": "https://github.com/images/error/octocat_happy.gif",
"description": "A great organization"
}
]


A.mphibio.us is not adverse to change. In fact, A.mphibio.us thrives on input from developers who put it to use. You’re openly encouraged to build on top of it. If you have input about A.mphibio.us or any of its functionality, feel free to add your changes and comments to our public repository on Github. You’re invited to become part of the active community and add features and improvements as you see fit. Just ask for a pull request.
We’ll give you access to a rapid development kit to get started with your project. The kit contains some basic layout grids, some base typography and styles, and a collection of sample themes that you can play with.
You don’t have to be an absolute genius to start working with the best of CSS practices.


Coursework Assessment
Contents
Coursework Assessment#
In case your work on this course is being assessed, here are the guidelines.
Undergraduates#
Assessment will typically be through team-based learning assignments as well as a computer-based test. You be expected to be able to apply the concepts you have learned to address questions by using appropriate computer code (e.g., R) input and interpreting the output.
Masters students#
Both your practical computing work itself (including any writeups), and whether you are following good programming and workflow practices will be assessed, usually on a weekly basis. Note that practicals in the weeks not included in this book (e.g., GIS and Genomics) will also be included in the assessment (what “assessment” of these weeks’ practicals means is explained below). So keep the workflow in those weeks organized, even if the analyses or pipelines/workflows you were taught we not fully reusable or machine-reproducible.
The basic rules you must follow, irrespective of a Week’s content are:
All code/scripts go to a
Code
(orcode
) directoryAll data go to a
Data
(ordata
) directoryAll results go to a
Results
(orresults
) directory. The results directory should be empty when you submit your week’s work, as it will be populated automatically when the assessment script runs.If you have files that don’t fit in these categories, put them additional, meaningfully named directories. For example, you can create a
writeup
directory to hold your (LaTeX) written work, and include your compiled pdf of the written report there.No single file should be greater than 100 mb, either data or script/code. If a script needs a data file, but the example data file is >100 mb, reduce it to a minimum working dataset and upload that, keeping the main data file(s) under
.gitignore
(see the Git Chapter. Keep all your main data backed up, of course!.Most importantly, all Python, R, bash, and LaTeX scripts should run without errors, taking in data and spitting out the results as necessary.
When necessary, more specific, module-specific details on weekly coursework and assessment will be given when the module starts.
Weekly practicals wrap-up#
Do this as after you finish with an assignment, and at the end of every week:
Review and make sure you can run all the commands, code fragments, and named scripts you have built till then and get the expected outputs.
Review your code files and annotate/comment code lines as much and as often as necessary using
#
.Check that all code, data and results files organized as instructed above in you weekly directory.
git add, commit and push your work after every major change to your weekly work, and make a final push by the given deadline (typically in the following week).
The Weekly Feedback#
A Python script will check whether your weekly (version-controlled) directories
are neat and organized in a logical workflow, and whether all the scripts run
correctly with the expected inputs and outputs, starting with the R
Chapter. For example, the script will check if your coursework
code, data and results outputs in each week are organized in separate
directories named code
, data
, results
(or equivalent) respectively.
The feedback script will then record a log file that summarizes all the issues found in your workflows, which will be pushed to your git repo, typically within 4 days after you submit your weekly practical. This log file will award “points” on a weekly basis to give you and the assessor a quantitative measure of how well you have done in that week. Here is the points scheme for this weekly feedback:
Note
An in-class script is one that is either given to you in class, or which you built from code fragments used in class (typically by re-typing them verbatim) to illustrate one or more programming concepts/tools. An assigned script is one you have written yourself, either from scratch, or by modifying one given to you, to address/answer a problem or task assigned to you (always appearing under a “Practicals” subsection of a chapter).
You would get 100 points if,
All the in-class scripts were in place (in the code directory in the respective week’s directory) and functional when run on the assessor’s (Linux) computer.
All the assigned practicals / problems were complete and functional, and give the right answers.
The scripts are all up to the the mark in terms of internal documentation and commenting.
There is a neat
readme
file for the overall repository and in each of the weekly directories.For every missing script or assigned practical/problem, 10 pts deducted (including groupwork scripts; see below)
For every assigned practical/problem, 5 pts deducted for wrong answer if applicable (that is, script runs without error, but gives wrong numerical/text/graphical output).
For every missing
readme
file, 1 pt deducted.For every extra, non-script file in
Code
directory, 0.5 pt deducted.For every pre-existing file in the
Results
directory, 0.5 pt deducted.For every valid script file in
Code
directory lacking an appropriate extension file (*.sh
,\*.py
, etc), 0.5 pt deducted.For every in-class script that gives a syntax error, 5 pts deducted, and for every script that gives an error because of wrong path (e.g., absolute) assignment, 2 pts deducted.
For every Python script completely lacking a docstring, 2 pts deducted. For every function in a Python script lacking a docstring, 0.5 pt deducted.
For every result of a code/script run not saved to a separate results directory, 1 pt deducted. For example, the separate directory may be
Results
for new results, orData
, if the scripts is for generating a new or modified dataset.
Groupwork#
Execution#
Each student group will assign a “scribe” to the group who will create a new Groupwork repository where all assigned groupwork practicals will be tackled collaboratively.
The group members will collaborate to develop the solution by creating branches of the script.
Every group member MUST create their own branch and work on each of the groupwork practicals.
Once the group has reached a solution, all branches should be merged and the final script transferred to each student’s main coursework repository.
Please read about git branching/merging, including the resources given at the end of the Git Chapter
The groupwork practicals will will only be evaluated in the final assessment (next section). The specific deadline will be given in class.
Assessment#
Every “Groupwork” question/script completed will be assessed using the same criteria as above, but in the final evaluation only.
If there are inconsistencies between a groupwork script of a given group, 5 points will be deducted from each group member’s total.
The final assessment of computing coursework#
A written summary assessment of your overall performance with your marks will be sent after the end of the computing weeks (end of term). For this, all the weeks scripts (including the Groupwork scripts) will be run / re-run.
Using the points obtained by each student in each week based on the criteria goben in the (The Weekly Feedback section), the assessor will exercise her/his judgment to deduct further marks if the weekly directory structure is disorganized, the code inadequately commented or insufficiently documented, the solution is not optimal or correct, or the written components of practicals are not up to the mark.
Please put (judicious) comments in all of your script files. You will be penalized if you don’t properly document and comment code, even if you weren’t explicitly asked to.
The weekly log files are to help you spot general, as well as programming language-specific issues with your computing coursework on a regular basis. You may and should fix bugs and other problems that the feedback logs bring to your attention. The assessor will have a look at how much you addressed the issues in the final assessment (by re-running all the weeks’ scripts). The final assessment will necessarily be more subjective than the weekly assessments, because the goal is to provide an overall, summative picture of how you did and what you can improve on. You will get feedback if these issues needed to be addressed in the final written assessment. The final marks will be based upon the weekly points and a coursework marking criteria. The contribution of each week to the overall marks will be up- or down-weighed based upon the difficulty level.
Plagiarism#
Students are encouraged to collaborate on these courses (e.g., CMEE). You may often exchange code snippets (solutions to sub-problems within the bigger problem, if you like) or blocks of code to test them. Also, two implementations of a coding solution / algorithm might often be very convergent and relatively similar. However, unless it is a groupwork practical (see above), extremely similar or identical scripts / code files will be reviewed carefully by markers. To this end, the assessment script will perform a diff on pairs of (non-groupwork) code files to detect “inordinate” degrees of similarity.
Alright, full steam ahead then!


A smooth, mild blend of coffees from Mexico, Bolivia and Guatemala.
Espresso, steamed milk and chocolate syrup.
A mixture of espresso, steamed milk and milk foam.
A spicy drink made with black tea, spices, milk and honey.