Company profile - Canadian Company Capabilities
Third-Party Information Liability Disclaimer
Some of the information on this Web page has been provided by external sources. The Government of Canada is not responsible for the accuracy, reliability or currency of the information supplied by external sources. Users wishing to rely upon this information should consult directly with the source of the information. Content provided by external sources is not subject to official languages, privacy and accessibility requirements.
Hanover Door Systems (1996) Inc.
Legal/Operating Name:
Hanover Door Systems (1996) Inc.
Mailing Address:
105 Commerce Dr.STEINBACH, Manitoba
R5G 1W6
Location Address:
105 Commerce Dr.STEINBACH, Manitoba
R5G 1W6
Tel.:<PHONE_NUMBER>
Tel.:<PHONE_NUMBER>
Fax:<PHONE_NUMBER>
Logo
Company Profile
We manufacture and install patented weight counterbalanced overhead door Lift
System using a system of chain linked weights connected to the door
panels through a unique pulley system. The Lift System itself requires
very little expertise to install and is nearly service free,
making it very popular in rural, remote, or high usage
applications. The Lift system is supplied with or without the door panels. The cost of the product is very competitive in price with quality torsion spring overhead door systems with
only a fraction of the maintenance required. These systems are
especially well suited to very high openings (where torsion
spring mechanisms are ineffective and multi leaf doors may be
cost prohibitive), as well this lift system is very effective
where the openings are extremely wide (up to and more than 40') when using
slide away mullions. The greatest benefit is the nearly
unlimited number of cycles that lift system is capable of with a
minimal amount of service required during the life of the
building. Systems are also available with aluminum panels, or polycarbonate panels making
it ideal for car washes, potatoe sheds and other high humidity
applications. Remote and rural commercial, city commercial, and
industrial are primary sales regions. These panels are supplied and or installed (or installation supervised ) all over North America. Many Door Companies across North America assist buisinesses and industry in their trading areas with the sale and installation of these systems.
We also process from bulk Richards Wilcox panel stock, metal
insulated overhead commercial and industrial doors. These doors
use either our weight counterbalanced Lift System or Richards-
Wilcox torsion spring hardware.
We also carry a complete line of Richards-Wilcox finger protect residential products.
Our company has developed a unique method of manufacturing small buildings of polyurethane insulated panels. These utility sheds require very few tools to set up. They can be shipped knocked down as 6 (standard) pieces, (more pces for larger buildings) doors
and windows pre-installed. They feature prefinished metal 2 sides, open ceiling, rodent proof and much more. Can be used as a shed or a cabin or a variety of enclosures around existing equipment or machinery. Largest size is 14x28 with optional overhead door. Standard wall heights are 6'8" and 7'. Other heights available.
Hanover also supplies and installs numerous lines of Steel Roll-up doors, Dock Levelers, loading dock seals, dock bumpers, commercial man doors, high speed fabric doors, polycarbonate doors, and most door related products.
Service to overhead doors, ours or any other manufacturer is
another main aspect of our buisiness. We carry a large supply of
parts, panels, motors, etc. to look after almost any overhead
door service or repair. We do a lot service, sales and installations for local buisiness, local gov't.,provincial gov't, federal gov't across the far north, coast to coast.
Full profile
Full profile
Contact information
Company description
Product / Service / Licensing
Door weight system/hardware and Richards-Wilcox track.
2.Torsion spring operated sectional overhead doors using
Richards-Wilcox and Amarr sections and hardware.
3. Service and parts for all and other makes. Territory includes
Manitoba, Sk., NWT, N.W. Ont.
4. Sales to almost anywhere.
overhead door panels. Include standard overhead door sizes,
doors up to 40' wide. Can be wider with sliding mullions. For very high doors, doors higher than 24' where springs are ineffective and for high cycle doors where frequent service is unacceptable.
(recycled new door panels) Available in 6 piece knock down
packages.(more pieces for larger sizes) Sizes from 6'x6' up to
15'x28' or longer. Included as standard are double swinging doors opening up to 4'.
Options include windows, overhead doors, 5' wide double swinging
doors, floors built on site and building set-up. (depending on
location) Knocked down shipping available. See under Buildings
at www.hanoverdoors.com
5680-Miscellaneous Construction Materials
Technology profile
overhead door panels. We manufacture and install weight
counterbalanced overhead door system using a system of chain
linked weights connected to door panels through a unique pulley
system. The system itself requires very little expertise to
install and is nearly service free, making it very popular in
rural, remote, or high usage applications.
We have developed insulated wall and roof panels that can be
used as utilty, security, or tool sheds or almost anything that
requires a small enclosure up to 16' x28', in size. Are already
being shipped to remote areas to enclose generators. Brochures
available. Very economical.
Market profile
Industry sector market interests:
- Construction
- Consumer Products
Geographic markets:
Actively pursuing:
- United States
Sector information
Unique applications:
1.grain elevator overhead doors - very high doorswhere springs are ineffective - especially
economical when compared to leaf style doors.
2.very wide doors using sliding mullions - any
width of clear openening possible in "as
required" width increments - i.e. - side by side
door widths could include many doors up to 26'
wide or as little as 6' or 8' wide. Doors can be
raised to full open position and all the track
mullions moved to the sides. The width of the
opening is dependant only on the clear span
engineered into the building.
3.unlimited number of cycles of use. There are no
weak links built into the entire lift system
including track and face hardware. This is
especially useful for remote locations where
service may be difficult to find on short notice.
It is also cost effective where a door may have
to open up to a 1000 times per day such as a
public garage. The startup cost is only slightly
higher than standard torsion spring doors but the
payback in service free reliability over the life
of the building is enormous.
Key / Major clients:
Gardwine Transport, Dept of Highways, Envirnment Canada. Quick-Zip Steel Buildings Ltd., Hutterite Colonies of Manitoba, Hutterite Colonies of Sasketchewan, Potatoe Growers of Manitoba, Trans X, Steve's Livestock Truck Wash, Penner International Trucking, Trappers Trucking, Vitera, Zipperlock, Monarch Industries, Manitoba Car Dealers, Northern Dock, Granny's Poultry, Big Freight, Gardwine North, Various School Divisions, EMS in Manitoba, Manitoba Hydro, Dryden Health Authority, Kindersly, Kleyson's, Norway House, RCMP City of Thompson, C.P. Rail, Progress Rail, Air Canada, Drydon Airport, Loewen Windows, Jeld-Wen Windows & Doors, Manitoba Dept. of Natural Resources, various Manitoba Municipal Fire Deptments.Success stories:
Many builders, contracters and management companies use our services for supply and installation.Testimonial:
February 8, 2000From Steve Smith, Environment Canada, Facilities
and Projects, Atmospheric Monitoring Division,
Prairie and Northern Region. (Winnipeg, Manitoba)
I am writing to express to you my complete
satisfaction with your product and with your
installation of two large overhead doors at the
Churchill Weather Station.
Many of the weather stations for which I am
responsible are located in the most remote
locations in the country. The arctic environment
in which these sites are located is the harshast
in North America. The cost of shipping new
overhead doors and the cost of travel for service
technicians often exceedsthe cost of the doors
themselves. For my application, reliability and
low maintenance are of paramount consideration.
Your product is the best that I have used. I
particularily like the simplicity of the opening
system and the rugged construction of the
hardware. I am favourably impressed with the
competance of your installation technicians.
My experiance in dealing with your firm
continues to be positive.
March 22, 2001
From Sophie Turko, Edgewood Estates, Property
Manager, (Winnipeg, Manitoba)
To Whom It May Concern:
Please be advised that Edgewood Estates have had
one garage door installed 3 years ago and one
installed 2 years ago. We experience a high usage
rate with 500 units in our apartment complex. We
have had no problems with the doors what so ever
and the service that Hanover Doors provides is of
the utmost quality.
If you should require any more information please
feel free to contact the writer at # 339-9286.
Third-Party Information Liability Disclaimer
Some of the information on this Web page has been provided by external sources. The Government of Canada is not responsible for the accuracy, reliability or currency of the information supplied by external sources. Users wishing to rely upon this information should consult directly with the source of the information. Content provided by external sources is not subject to official languages, privacy and accessibility requirements.
Contacts
Contact information
Description
Company description
Products, services and licensing
Product / Service / Licensing
Door weight system/hardware and Richards-Wilcox track.
2.Torsion spring operated sectional overhead doors using
Richards-Wilcox and Amarr sections and hardware.
3. Service and parts for all and other makes. Territory includes
Manitoba, Sk., NWT, N.W. Ont.
4. Sales to almost anywhere.
overhead door panels. Include standard overhead door sizes,
doors up to 40' wide. Can be wider with sliding mullions. For very high doors, doors higher than 24' where springs are ineffective and for high cycle doors where frequent service is unacceptable.
(recycled new door panels) Available in 6 piece knock down
packages.(more pieces for larger sizes) Sizes from 6'x6' up to
15'x28' or longer. Included as standard are double swinging doors opening up to 4'.
Options include windows, overhead doors, 5' wide double swinging
doors, floors built on site and building set-up. (depending on
location) Knocked down shipping available. See under Buildings
at www.hanoverdoors.com
5680-Miscellaneous Construction Materials
Technology
Technology profile
overhead door panels. We manufacture and install weight
counterbalanced overhead door system using a system of chain
linked weights connected to door panels through a unique pulley
system. The system itself requires very little expertise to
install and is nearly service free, making it very popular in
rural, remote, or high usage applications.
We have developed insulated wall and roof panels that can be
used as utilty, security, or tool sheds or almost anything that
requires a small enclosure up to 16' x28', in size. Are already
being shipped to remote areas to enclose generators. Brochures
available. Very economical.
Market
Market profile
Industry sector market interests:
- Construction
- Consumer Products
Geographic markets:
Actively pursuing:
- United States
Sector
Sector information
Unique applications:
1.grain elevator overhead doors - very high doorswhere springs are ineffective - especially
economical when compared to leaf style doors.
2.very wide doors using sliding mullions - any
width of clear openening possible in "as
required" width increments - i.e. - side by side
door widths could include many doors up to 26'
wide or as little as 6' or 8' wide. Doors can be
raised to full open position and all the track
mullions moved to the sides. The width of the
opening is dependant only on the clear span
engineered into the building.
3.unlimited number of cycles of use. There are no
weak links built into the entire lift system
including track and face hardware. This is
especially useful for remote locations where
service may be difficult to find on short notice.
It is also cost effective where a door may have
to open up to a 1000 times per day such as a
public garage. The startup cost is only slightly
higher than standard torsion spring doors but the
payback in service free reliability over the life
of the building is enormous.
Key / Major clients:
Gardwine Transport, Dept of Highways, Envirnment Canada. Quick-Zip Steel Buildings Ltd., Hutterite Colonies of Manitoba, Hutterite Colonies of Sasketchewan, Potatoe Growers of Manitoba, Trans X, Steve's Livestock Truck Wash, Penner International Trucking, Trappers Trucking, Vitera, Zipperlock, Monarch Industries, Manitoba Car Dealers, Northern Dock, Granny's Poultry, Big Freight, Gardwine North, Various School Divisions, EMS in Manitoba, Manitoba Hydro, Dryden Health Authority, Kindersly, Kleyson's, Norway House, RCMP City of Thompson, C.P. Rail, Progress Rail, Air Canada, Drydon Airport, Loewen Windows, Jeld-Wen Windows & Doors, Manitoba Dept. of Natural Resources, various Manitoba Municipal Fire Deptments.Success stories:
Many builders, contracters and management companies use our services for supply and installation.Testimonial:
February 8, 2000From Steve Smith, Environment Canada, Facilities
and Projects, Atmospheric Monitoring Division,
Prairie and Northern Region. (Winnipeg, Manitoba)
I am writing to express to you my complete
satisfaction with your product and with your
installation of two large overhead doors at the
Churchill Weather Station.
Many of the weather stations for which I am
responsible are located in the most remote
locations in the country. The arctic environment
in which these sites are located is the harshast
in North America. The cost of shipping new
overhead doors and the cost of travel for service
technicians often exceedsthe cost of the doors
themselves. For my application, reliability and
low maintenance are of paramount consideration.
Your product is the best that I have used. I
particularily like the simplicity of the opening
system and the rugged construction of the
hardware. I am favourably impressed with the
competance of your installation technicians.
My experiance in dealing with your firm
continues to be positive.
March 22, 2001
From Sophie Turko, Edgewood Estates, Property
Manager, (Winnipeg, Manitoba)
To Whom It May Concern:
Please be advised that Edgewood Estates have had
one garage door installed 3 years ago and one
installed 2 years ago. We experience a high usage
rate with 500 units in our apartment complex. We
have had no problems with the doors what so ever
and the service that Hanover Doors provides is of
the utmost quality.
If you should require any more information please
feel free to contact the writer at # 339-9286.


The following tutorials are aimed at students/enthusiasts who have an introductory background in finite-volume methods and CFD. The aim of theses tutorials is to help those individuals bridge the gap to developing more sophisticated CFD codes for research. The topics covered will include finite-volume methods on unstructured meshes, object-oriented CFD code design, higher-order methods, multiphase flows and compressible flows.
Before beginning these tutorials, it is recommended that the reader have taken a basic introductory CFD course or equivalent and have a working knowledge of C++ (familiarity with classes will be assumed).


An Apple ][ Emulator in JavaScript
Disk 1
Disk 2
0 kHz
Loading...
Options
Save Disk
Save to Browser
Save Name:
Save
Download to Local Disk
Manage Local Saves
Load URL
Load Disk
$
Printer
Alert


The Modelica.Electrical.QuasiStationary library addresses the analysis of electrical circuits with purely sinusoidal voltages and currents. The main characteristics of the library are:
omega
of the voltages and
currents of a circuit are determined from a reference angle
gamma
by means of omega =
der(gamma)
.gamma
is not a global quantity
since it propagated through the connector. Therefore, independent
circuits of different frequencies can be modeled in one model.The main intention of this library is the modeling of quasi stationary behavior of single and multi phase AC circuits with fixed and variable frequency. Quasi stationary theory and applications can be found in [Dorf1993], [Burton1994], [Landolt1936], [Philippow1967], [Weyh1967], [Vaske1973].
A general electrical circuit can be a DC circuit, an AC circuit with periodic sinusoidal or non-sinusoidal voltages and currents or a transient circuit without particular waveform of voltages and currents. Therefore a coupling model between a quasi stationary circuit and a general (transient) electrical circuit has to be designed carefully taking the specific application into account. As an example, you may look at the ideal AC DC converter, which is used in the rectifier example.
| Name | Description |
|---|---|
| Introduction | Introduction to phasors |
| ACCircuit | AC circuit |
| Power | Real and reactive power |
| ReferenceSystem | Reference system |


-
Testing a way for you to make purchases on Twitter | Twitter Blogs
blog.twitter.com
A new way to discover and buy products on Twitter.
-
On Death and iPods: A Requiem | WIRED
www.wired.com
The single-use device is gone---and with it, the very notion of cool that it once carried.
-
I have 46 Thanksgiving dinners left with my family. After that, I’ll be ...
medium.com
Time is the most valuable resource I have. Yet, I don’t manage it like one. So how can I change my actions?
-
Product Hunt
www.producthunt.com
Product Hunt is a curation of the best new products, every day. Discover the latest mobile apps, websites, and technology products that everyone's ...
-
iPhone camera evolution: How does the iPhone 6 camera compare to previous ...
snapsnapsnap.photos
How does the iPhone 6 camera stack up against previous hardware? In her ongoing series, professional iPhone photographer Lisa Bettany takes a hard ...
-
Robinhood Raises $13M To Democratize Stock Market With Zero-Commission ...
techcrunch.com
Half a million people have already signed up for Robinhood's unlaunched zero-fee stock trading service. Now the startup has raised $13 million to ...
-
Derek Jeter Opens the Door.
nymag.com
The retiring legend offers a photographer access to his private world—the first project in a new career that is all about control.
-
Talko | Talko is the best way to use your voice to get things done.
www.talko.com
TALK. SHARE. DO. Amazing things can happen when we talk with each other. Thoughts are shared, ideas formed and problems solved. Talko is the best way ...
-
Stripe Lands Apple in Quest for $720 Billion in Payments - Bloomberg
www.bloomberg.com
Stripe Lands Apple in Quest for $720 Billion in Payments
-
Zenefits’ Leader Is Rattling an Industry, So Why Is He Stressed Out? - ...
www.nytimes.com
Parker Conrad’s start-up, Zenefits, is thought to be one of the fastest-growing companies in recent Silicon Valley history, and his investors and ...
 Google Ventures' Daniel Burka dives into the data.
-
How to Start a Startup
startupclass.samaltman.com
CS183B is a class we’re teaching at Stanford. It’s designed to be a sort of one-class business course for people who want to start startups.
-
Venture Capitalist Sounds Alarm on Startup Investing
online.wsj.com
Silicon Valley may have taken on more risk than it can handle, according to prominent venture capitalist Bill Gurley, who cited potential cracks in ...
-
There’s a Dragon at the Door – Redpoint Ventures
www.redpoint.com
All eyes are focused this week on Alibaba. The Chinese-based ecommerce powerhouse will make its debut as the largest technology initial public ...
-
Stripe: Apple Pay
stripe.com
Stripe is a suite of APIs that powers commerce for businesses of all sizes.
-
Breaking News, World News & Multimedia
www.nytimes.com
The New York Times: Find breaking news, multimedia, reviews & opinion on Washington, business, sports, movies, travel, books, jobs, education, real ...
-
@Shopify is growing! Work on challenging problems with some of the ...
www.shopify.com
Careers and jobs at Shopify
-
Thom Yorke - Tomorrow's Modern Boxes
bundles.bittorrent.com
Tomorrow's Modern Boxes is a new record from Thom Yorke.. the BitTorrent Bundle features 8 tracks and a music video. Download the Bundle for $6, or ...
-
5 Lessons From a 70 Year-Old Company That Got Its Start With Dropshipping ...
www.shopify.com
A blog about ecommerce marketing, running an online business and updates to Shopify's ecommerce community.
-
3Fish Studios
ecommerce.shopify.com
3Fish Studios was founded in San Francisco when husband-and-wife team Annie Galvin and Eric Rewitzer turned their passion into their business.
-
50 Best Websites for Entrepreneurs
www.inc.com
For entrepreneurs, time is especially precious. Every wasted minute is a lost opportunity for networking, growing the business, and of course making ...
-
9 Resources Online Store Owners Can Use to Create Beautiful Marketing ...
www.shopify.com
A blog about ecommerce marketing, running an online business and updates to Shopify's ecommerce community.
-
How to Come up with Your First Product Idea – Part 1 [Video] – Shopify
www.shopify.com
A blog about ecommerce marketing, running an online business and updates to Shopify's ecommerce community.


This is an ongoing project! I'm working really hard to update the contents on this page, and I'll keep posting my progress here once they are ready. Meanwhile, please checkout my other projects!


{% extends 'messages/email/base_to_user.html' %} {% block content %}
Welcome to {{ config.SITE_NAME }}! You know have access to the {{ config.SITE_NAME }} site and can start setting up reminders right away. All you need to do is log in, add your Breeze® Card and add a few reminders. We'll handle the rest!
But before you get started, we need you to verify your email address. Simply click here or visit https://{{ config.DOMAIN }}{{ url_for('auth.verify', pk_hash=current_user.pk_hash) }} in your browser.
{% endblock %}


jliefeld @ ucsd.edu
Edit Dataset (based on the GParc module removeSamples by Barbara Weir) is a GenePattern module that removes user-defined samples from a dataset. The user inputs their dataset as a GCT file, along with a text file containing the list of samples to be removed. The module outputs a GCT file containing the dataset with the user-defined samples removed.
GenePattern 3.9.11 or later that uses dockerized modules.
| Name | Description |
|---|---|
| gct file* | Data file containing samples to be removed in a GCT file format. |
| removelist* | Text file containing the list of samples to remove. Each sample should be on a separate line and must match a sample name in the file exactly. |
| extension* | User defined prefix for the output file. |
* - required


Hacklab Cosenza / Centro di Ricerca su Tecnologia e Innovazione
OSPF has three main data structures in its internals:
OSPF uses several types of packets to convey different messages: Hello packets, database description packets, link-state request, update and acknowledgment packets.
OSPF uses Djkstra SPF’s algorithm with a metric based on cumulative bandwidth.
OSPF operates as a typical link-state protocol, but also has a few peculiarities and implementation details.
OSPF achieves better scalability than other protocols by supporting the split of all the AS’ routers into multiple areas, although it can also run in single-area mode (called backbone area or area 0).
An "area" is a subset of the OSPF routers that share the same LSDB, because LSAs reach only inside an area.
What we generally called LSAs (link-state advertisements) when overviewing a link-state protocol operations, are split into several stages and packets in OSPF.
On a multi-access and broadcast-capable medium like Ethernet, this topology would generate n(n-1)/2 = 10 adjancencies. It would exponentially grow if we add more routers.
In this situation flooding to every adjacency like OSPF does would become excessive.
The OSPF solution to this problem is to elect a Designated Router (DR) that will have the task to collect and distribute all the LSAs.
A Backup designated Router (BDR) is also elected to provide redundancy.
All the other adjacent routers become DROTHERS.
If the medium in use is not broadcast-based, like Frame Relay, DR and BDR are not necessary even in similar topologies.
To enable OSPFv2 on a router, use:
router(config)#: router ospf [process_id]
Where process_id is in the range 1-65535. It doesn't have to be the same value as other OSPF routers.
We are now in OSPF router configuration mode, which has the following commands available:
R2(config-router)# ?
Router configuration commands:
address-family Enter Address Family command mode
area OSPF area parameters
auto-cost Calculate OSPF interface cost according to bandwidth
bfd BFD configuration commands
capability Enable specific OSPF feature
compatible OSPF compatibility list
default Set a command to its defaults
default-information Control distribution of default information
default-metric Set metric of redistributed routes
discard-route Enable or disable discard-route installation
distance Define an administrative distance
distribute-list Filter networks in routing updates
domain-id OSPF domain-id
domain-tag OSPF domain-tag
event-log OSPF Event Logging
exit Exit from routing protocol configuration mode
help Description of the interactive help system
ignore Do not complain about specific event
interface-id Source of the interface ID
ispf Enable incremental SPF computation
limit Limit a specific OSPF feature
local-rib-criteria Enable or disable usage of local RIB as route criteria
log-adjacency-changes Log changes in adjacency state
max-lsa maximum number of LSAs OSPF process will receive
max-metric Set maximum metric
maximum-paths Forward packets over multiple paths
neighbor Specify a neighbor router
network Enable routing on an IP network
no Negate a command or set its defaults
nsf Non-stop forwarding
passive-interface Suppress routing updates on an interface
prefix-suppression OSPF prefix suppression
priority OSPF topology priority
queue-depth OSPF Hello/Router process queue depth
redistribute Redistribute information from another routing protocol
router-id router-id for this OSPF process
shutdown Shutdown the OSPF protocol under the current instance
snmp Modify snmp parameters
summary-address Configure IP address summaries
timers Adjust routing timers
traffic-share How to compute traffic share over alternate paths
ttl-security TTL security check
R2(config-router)#
OSPF needs every router to have its own router ID, for:
Router ID can be explicitely (manually) configured with:
Router(config-router)# router-id [a.b.c.d]
Router# show ip protocols
Routing Protocol is "ospf 10"
[...]
Router ID [a.b.c.d]
Even if it has the appearances of an IPv4 address, the Router ID is not an actual assigned and routable address.
Even non-OSPF interfaces participate in determining the Router ID!
Given that a router is listed as neighbor in other router's databases through its Router ID, changing it requires to renegotiate all the adjancencies.
After changing the Router ID, you must enter the command
Router# clear ip ospf process
Reset ALL OSPF processes? [no]: y
*Mar 25 19:46:22.423: %OSPF-5-ADJCHG: Process 10, Nbr <IP_ADDRESS>
on Serial0/0/1 from FULL to DOWN, Neighbor Down: Interface
down or detached
*Mar 25 19:46:22.423: %OSPF-5-ADJCHG: Process 10, Nbr <IP_ADDRESS>
on Serial0/0/0 from FULL to DOWN, Neighbor Down: Interface
down or detached
*Mar 25 19:46:22.475: %OSPF-5-ADJCHG: Process 10, Nbr <IP_ADDRESS>
on Serial0/0/1 from LOADING to FULL, Loading Done
*Mar 25 19:46:22.475: %OSPF-5-ADJCHG: Process 10, Nbr <IP_ADDRESS>
on Serial0/0/0 from LOADING to FULL, Loading Done
forcing a restart from the Down and Init states.
Just as in RIP, we use the network
command to enable OSPF on a specific interface, but with different parameters:
network [network_address] [wildcard_mask] area [area_id]
The Area ID must be the same for all routers belonging to the Single-Area. It is advisable to use the value of 0.
The Wildcard mask is a 32 bits "address" that is exactly the reverse of the subnet mask: 1s becomes 0s and viceversa.
IP Address <IP_ADDRESS> Subnet Mask <IP_ADDRESS> Wildcard Mask <IP_ADDRESS>
The fastest way to calculate the wildcard mask is to subtract the subnet mask from <IP_ADDRESS>.
Cisco's implementation of OSPF uses bandwidth (translated into a cost), as the metric. A link with a higher bandwidth will result in a lower cost, and therefore a better metric.
The cost of a route will be the accumulated cost of all the links in the path.
The equation used to calculate the cost of an OSPF link is:
The default reference bandwidth is 100 Mbps.
Links with bandwidth equal or higher to the reference will result in the same OSPF cost. To achieve better accuracy on faster interfaces, we can adjust the reference bandwidth:
R1(config-router)# auto-cost reference-bandwidth [value_in_mbps]
This new reference has to be equal on all routers, otherwise we would have inconsistent cumulative costs for routes.
We can also adjust the interface bandwidth (only the nominal value, not the actual throughput!) or just set a manual cost for it:
R1(config-ig)# bandwidth [new_value_in_kbps]
R1(config-ig)# no bandwidth [new_value_in_kbps]
R1(config-ig)# ip ospf cost [new_cost]
Router# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
<IP_ADDRESS> 0 FULL/ - 00:00:32 <IP_ADDRESS> Serial0/0/1
<IP_ADDRESS> 0 FULL/ - 00:00:38 <IP_ADDRESS> Serial0/0/0
The dash ("-") on the State column indicates that there was no need to elect a DR/BDR on this link.
If a neighbor isn't shown, it could be that the adjacency could not be formed because of:
network
command).Router# show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "ospf 10"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID <IP_ADDRESS>
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
<IP_ADDRESS> <IP_ADDRESS> area 0
<IP_ADDRESS> <IP_ADDRESS> area 0
<IP_ADDRESS> <IP_ADDRESS> area 0
Routing Information Sources:
Gateway Distance Last Update
<IP_ADDRESS> 110 00:14:58
<IP_ADDRESS> 110 00:16:59
Distance: (default is 110)
R2# show ip ospf
Routing Process "ospf 10" with ID <IP_ADDRESS>
Start time: 01:37:24.332, Time elapsed: 01:32:17.412
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
Supports NSSA (compatible with RFC 3101)
Event-log enabled, Maximum number of events: 1000, Mode: cyclic
Router is not originating router-LSAs with maximum metric
Initial SPF schedule delay 5000 msecs
Minimum hold time between two consecutive SPFs 10000 msecs
Maximum wait time between two consecutive SPFs 10000 msecs
Incremental-SPF disabled
Minimum LSA interval 5 secs
Minimum LSA arrival 1000 msecs
LSA group pacing timer 240 secs
Interface flood pacing timer 33 msecs
Retransmission pacing timer 66 msecs
Number of external LSA 0. Checksum Sum 0x000000
Number of opaque AS LSA 0. Checksum Sum 0x000000
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Number of areas transit capable is 0
External flood list length 0
IETF NSF helper support enabled
Cisco NSF helper support enabled
Reference bandwidth unit is 1000 mbps
Area BACKBONE(0)
Number of interfaces in this area is 3
Area has no authentication
SPF algorithm last executed 01:30:07.268 ago
SPF algorithm executed 3 times
Area ranges are
Number of LSA 3. Checksum Sum 0x02033A
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
This command's output display the last time the topology was recomputed with the SPF algorithm, and the OSPF area informations.
Router# show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Se0/0/1 10 0 <IP_ADDRESS>/30 976 P2P 1/1
Se0/0/0 10 0 <IP_ADDRESS>/30 647 P2P 1/1
Gi0/0 10 0 <IP_ADDRESS>/24 1 DR 0/0
Router# show ip ospf interface serial 0/0/1
Serial0/0/1 is up, line protocol is up
Internet Address <IP_ADDRESS>/30, Area 0, Attached via Network Statement
Process ID 10, Router ID <IP_ADDRESS>, Network Type POINT_TO_POINT, Cost: 976
Topology-MTID Cost Disabled Shutdown Topology Name
0 976 no no Base
Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:03
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 3/3, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor <IP_ADDRESS>
Suppress hello for 0 neighbor(s)
They operate on top of a different IP version. In dual-stack networks, their processes run completely independently, each with its own data strucures, settings and algorithms.
Route(config-if)# ipv6 ospf [process_id] area [area_id]


| Style | American Option: the holder of an option has the right to exercise his option at any time before the expiration date European Option: an option which can only be exercised on its expiration date |
| Type | Call option, Put option |
| Underlying Asset | The security on which the option is bound. The underlying could be stocks(stock option), stock indices(index option), exchange rate(Foreign exchange option) or even futures(Futures Options). Note: The options in the tutorial refer to the stock options. |
| Premium | The price of the option. (Premiums are quoted on a per share basis). The option premium depends on the strike price, volatility of the underlying, as well as the time remaining to expiration. |
| Strike Price | The specified price at which the stock can be bought or sold when the option is exercised. |
| Expiration Date | The last day that an options contract is valid. All options expire after a certain period of time. The right to exercise the option will no longer exist once the stock option expires. |
| Participants | Holder: People who buy the options(have long positions) Writer: People who sell the options(have short positions) |
| At the Money(ATM) | The strike price is the same as the current price of the underlying asset |
| In the Money(ITM) | Call Option: the strike price is below the current trading price of the underlying Put option: the strike price is above the spot price of the underlying |
| Out of the Money(OTM) | Call Option: the strike price is above the current trading price of the underlying Put Option: the strike price is below the current trading price of the underlying |
For example, if the price of Apple stock is at $140, then all calls with a strike price below $140 are in the money calls, all puts with a strike price above $140 are in the money puts. All calls with a strike price above $140 are out of the money calls, all puts with a strike price below $140 are out of the money puts.
But why are they in the money or out of the money? For a call option as an example, it is ITM because it already has an intrinsic value. If you buy the call option and own the right to buy AAPL at strike price $143 and the current market price is $150, then this call option is in the money 150-143=$7. If you need to exercise it, you can buy shares of AAPL at $143 and sell them immediately for $150 and secure $7 profit.
Likewise, for a call option, it is OTM because it doesn't have any intrinsic value. If you buy the call option and own the right to buy AAPL at strike price $143 and the current market price is $130, then this call option is out of the money 130-143=$13. If you need to exercise it, you can buy shares of AAPL at $143 and sell them immediately for $130 and then you will lose $13. In this case, you would not do that. But why this kind of OTM options still traded in the market and you need to pay for them? That because they still have time values and have time to expiration. There is probability or there is expectation from the OTM option holders that the apple price will go up and above the strike price before the expiration.An option is a standardized contract between two parties to buy or sell an asset for a certain price. Options are pretty different from equity trading. Here we concerned primarily with the stock options.  In addition, we explain how options markets are organized, how the contracts are traded. Next chapter we will take a close look at how to use QuantConnect API to start your options trading algorithm.


Home
About Kobedi
Data Science Topics
Here is a list topics to checkout:
The Art of Technical Decisions
Data Exploration Analysis
Data Science Driven Solution Architecture
Available African Data Sets


Layout Grid
experimental Evo does not require usage of any particular grid system. Evo offers this experimental grid for solving basic needs for page layout and positioning inside of a container. Very basic, almost rudimentary.
If you need a more powerful grid with well defined mobile responsive states, consider a third-party solution such as Bootstrap's grid, Foundation's grid, or Flexbox grid.
Note that Evo was originally was intended to augment and layer upon a framework such as Bootstrap, so reliance on a more familiar third party grid is intentional and advantageous. If you really must be original, try pushing the Evo grid into new and adventerous territory, or even make your own. :-)
12 Column Grid
Evolution features a basic 12 column responsive grid. Create an HTML tag using

or

, and apply an grid-[number]
class. To fix any layout issues try using the clearfix
class on the very last element.

12 Column Grid
Evolution features a basic 12 column responsive grid. Create an HTML tag using

or

, and apply an grid-[number]
class. To fix any layout issues try using the clearfix
class on the very last element.

1-up-grid
More grid variations can be found here.

1-up-grid
2-up-grid
3-up-grid
4-up-grid
6-up-grid
More grid variations can be found here.

More grid variations can be found here.

More grid variations can be found here.

1-up-grid
2-up-grid
3-up-grid
4-up-grid
6-up-grid
12-up-grid
More grid variations can be found here.

7-up-grid
More grid variations can be found here.


relevel
: Added S3 method support for DataFrame
and GRanges
objects containing factor columns.Improved S4 method support for dplyr verbs working on DataFrame
class.
inner_join
, left_join
(already defined), right_join
, full_join
, semi_join
, and anti_join
. These methods use merge
internally but ensure that rows are not unexpectedly reordered.mutate
and select
: mutate_all
, mutate_at
, mutate_if
, transmute_at
, transmute_if
; select_all
, select_at
, select_if
. These variants keep track of row names. Internally, these functions coerce to tbl_df
and then call the dplyr function. Return is coerced back to DataFrame
, with row names preserved.relevel:
Made S3 methods for relevel
defunct of favor of recommend S4 method usage of droplevels
instead. S4 method support for droplevels
is already provided in S4Vectors (i.e. List
, DataFrame)
. Here we are improving droplevels
functionality by adding additional method support for Ranges
(to support IRanges
, GRanges
) as well as SummarizedExperiment
, which enables automatic leveling of factors in colData
or rowData
.innerJoin
, leftJoin
, rightJoin
, fullJoin
, semiJoin
, antiJoin
; mutateAll
, mutateAt
, mutateIf
; selectIf
.mutate*
and select*
verbs to use simple base R code internally, and now methods are only defined for DataFrame
class. This way we don’t run into any masking issues with dplyr, and we don’t need to list it as a suggested package.


|
IOH
<IP_ADDRESS>
Experimentation procedure for Iterative Optimization Heuristics
|
CRTP class for BBOB problems. More...
#include <ioh/problem/bbob/bbob_problem.hpp>
Public Member Functions | |
| BBOProblem (const int problem_id, const int instance, const int n_variables, const std::string &name, const double condition=sqrt(10.0)) | |
| Construct a new BBOProblem object. More... | |
| void | update_log_info () override |
| Update the log info. | |
| Solution< double > | calculate_objective () const |
| Calculate the solution to the problem. | |
| virtual void | reset () |
| Reset method, resets problem state and logger if attached. | |
| logger::Info & | log_info () |
| Accessor for current log info. | |
| void | attach_logger (Logger &logger) |
| Attach a logger. | |
| void | detach_logger () |
| Dettach a logger. | |
| double | operator() (const std::vector< T > &x) |
| Main call interface. | |
| MetaData | meta_data () const |
Accessor for meta_data_ | |
| Solution< T > | objective () const |
Accessor for objective_ | |
| State< T > | state () const |
Accessor for state_ | |
| Constraint< T > | constraint () const |
Accessor for constraint_ | |
Protected Member Functions | |
| double | transform_objectives (const double y) override |
| Default objective transform for BBOB. | |
| bool | check_input_dimensions (const std::vector< T > &x) |
| Method for checking the input given to the problem has the correct dimension. More... | |
| template<typename Integer = T> | |
| std::enable_if< std::is_integral< Integer >::value, bool >::type | check_input (const std::vector< T > &x) |
| Check input given to problem for Integer types. More... | |
| template<typename Floating = T> | |
| std::enable_if< std::is_floating_point< Floating >::value, bool >::type | check_input (const std::vector< T > &x) |
| Check input given to problem for Floating point types. More... | |
| virtual double | evaluate (const std::vector< T > &x)=0 |
| Evaluation function. | |
| virtual std::vector< T > | transform_variables (std::vector< T > x) |
| TODO: check why this is not const Variables transformation function. | |
Protected Attributes | |
| struct ioh::problem::BBOB::TransformationState | transformation_state_ |
| The current transformation state. | |
| MetaData | meta_data_ |
| Problem meta data. | |
| Constraint< T > | constraint_ |
| The Constraint. | |
| State< T > | state_ |
| The Problem state. | |
| Solution< T > | objective_ |
| The solution to the problem. | |
| Logger * | logger_ {} |
| A pointer to the attached logger. | |
| logger::Info | log_info_ |
| The current log info. | |
Private Attributes | |
| InvokeApplyOnConstruction< Type, Factory > & | invoker = RegistrationInvoker<Type, Factory>::registration_invoker |
Forces creation of invoker | |
Static Private Attributes | |
| static InvokeApplyOnConstruction< Type, Factory > | registration_invoker |
Forces creation of registration_invoker More... | |
CRTP class for BBOB problems.
Inherit from this class when defining new BBOB problems
| ProblemType | The New BBOB problem class |
|
inline |
Construct a new BBOProblem object.
| problem_id | The id of the problem |
| instance | The instance of the problem |
| n_variables | the dimension of the problem |
| name | the name of the problem |
| condition | the conditioning of the problem |
|
inlineprotectedinherited |
Check input given to problem for Integer types.
| Integer | integer type |
| x | the input |
|
inlineprotectedinherited |
Check input given to problem for Floating point types.
| Floating | floating type |
| x | the input |
|
inlineprotectedinherited |
Method for checking the input given to the problem has the correct dimension.
| x | the input vector |


Futuristic technologies For You
A paragraph is a series of sentences that
are organized and coherent, and are all
related to a single topic. Almost every piece
of writing you do that is longer than a few
sentences should be organized into paragraphs.
Learn More


Full-Stack Engineering Comes Back to Gilt This Tuesday!
After enjoying a relaxing (?) three-day weekend, get back into the heavy-duty tech-talk swing of things by coming to 2 Park on May 27 for the Full-Stack Engineering meetup! Even compared to past FSE speaker lineups this Tuesday’s is especially strong, with presenters representing three of NYC’s top tech companies:
- Mike Brittain, Director of Engineering at Etsy, will discuss “Advanced Topics in Continuous Delivery”
- Wes Chow, CTO at Chartbeat, will present on “Pseudorandomness in JavaScript”
- and last–but definitely not least–Will Chiong, Lead Software Engineer at Gilt, on “Data-driven Personalization”
We’ll have food, drink, and–with +200 RSVPs and a waitlist–lots of company! Hope to see you here.


www.woodenartwork.com.au
www.suherman-ng.com
Please copy and paste the link above, as github does not allow hotlinking outside its domain.


--- layout: page title: "Scala in Depth" prev: kindle_split_011.html next: kindle_split_013.html book_path: books/scala-in-depth-joshua-d-suereth--_oeb/ --- {% include JB/setup %} {% raw %}
Scala is a rich object-oriented language. In Scala, every value is an object. Even operators are method calls against the class of an object. Scala offers mixin inheritance through the use of traits. Objects are core to everything in Scala, and understanding the details of how they work is important for using Scala.
Object, class, and traits are used to define public APIs for libraries. The initialization, comparison, and composition of objects are the bread and butter of Scala development. Initialization is important because of mixin inheritance and the way objects get instantiated in various locations. Comparing two objects for equality is critical and can be made trickier when inheritance gets in the mix. Finally, composition of functionality is how code reuse is accomplished, and Scala provides a few new ways to compose objects.
In Scala, the code inside an object, trait or class’s body is the constructor.
A common starting point for most developers learning Scala is the standard “Hello, World” program. You’ll see many examples on the internet with the following code:
object Test extends Application { println("Hello, World!") }
Although elegant, this code sample is misleading in its simplicity. The Application trait uses a nifty trick to simplify creating a new application but comes with a price. Let’s look at a simplified version of the Application trait in the following listing.
trait Application { def main(args: Array[String]): Unit = {} }
That’s it. That one empty method is all that’s needed for the Application trait. Why does this work? Let’s dig into the bytecode.
When compiling traits, Scala creates an interface/implementation pair of classes. The interface is for JVM interoperability and the implementation is a set of static methods that can be used by classes implementing the trait. When compiling the Test object, a main method is created that forwards to the Application implementation class. Although this method is empty, the logic inside the Test object is placed in the Test object’s constructor. Next, Scala creates “static forwarders” for the object. One of these static forwarder methods will be the main method, in the signature the JVM expects. The static forwarder will call the method on the singleton instance of the Test object. This instance is constructed in a static initialization block. And finally, we get to the issue. Code inside a static initialization block isn’t eligible for HotSpot optimization. In fact, in older versions of the JVM, methods called from a static initialization block wouldn’t be optimized either. In the most recent benchmarks, this has been corrected, such that only the static block itself isn’t optimized.
Scala 2.9 provides a better solution: the DelayedInit trait.
Scala 2.9 provides a new mechanism for dealing with constructors. DelayedInit is a marker trait for the compiler. When implementing a class that extends DelayedInit, the entire constructor is wrapped into a function and passed to the delayedInit method. Let’s a look at the DelayedInit trait.
trait DelayedInit { def delayedInit(x: => Unit): Unit }
The trait has one method, delayedInit. As stated before, this method has a function object passed to it. This function contains all the regular constructor logic, which provides a clean solution to the Application trait. Let’s implement your own to demonstrate the DelayedInit behavior.
trait App extends DelayedInit { var x: Option[Function0[Unit]] = None override def delayedInit(cons: => Unit) { x = Some(() => cons) } def main(args: Array[String]): Unit = x.foreach(_()) }
The new App trait extends DelayedInit. It defines an Option x containing the constructor behavior. The delayedInit method is overridden to store the constructor logic in the x variable. The main method is defined so that it will execute the constructor logic stored in the x variable. Now that the trait is created, let’s try it in the REPL.
scala> val x = new App { println("Now I'm initialized") } x: java.lang.Object with App = $anon$1@2013b9fb scala> x.main(Array()) Now I'm initialized
The first line creates a new anonymous subclass of the App trait. This subclass prints the string "Now I'm initialized" in its constructor. The string isn’t printed to the console during construction. The next line calls the main method on the App trait. This calls the delayed constructor, and the string "Now I'm initialized" is printed.
The DelayedInit trait can be dangerous because it delays the construction of the object until a later time; methods that expect a fully initialized object may fail subtly at runtime. The DelayedInit trait is ideal for situations where object construction and initialization are delayed. For example, in the Spring bean container, objects are constructed and then properties are injected before the object is considered complete. The DelayedInit trait could be used to delay the full construction of an object until after all properties have been injected. A similar mechanism could be used for objects created in Android.
The DelayedInit trait solves the problem where construction and initialization of objects are required, due to external constraints, to happen at different times. This separation isn’t recommended in practice but sometimes is necessary. Another initialization problem exists in Scala, and this occurs with multiple inheritance.
Scala traits provide the means to declare abstract values and define concrete values that rely on the abstract. For example, let’s create a trait that stores property values from a config file.
trait Property { val name: String override val toString = "Property(" + name + ")" }
The Property trait defines an abstract member name which stores the current name of the Property. The toString method is overridden to create a string using the name member. Let’s instantiate an instance of this trait.
scala> val x = new Property { override val name = "HI" } x: java.lang.Object with Property = Property(null)
Using abstract values in traits requires special care with object initialization. While early initializer blocks can solve this, lazy val can be a simpler solution. Even better is to avoid these dependencies by using constructor parameters and abstract classes.
The val x is defined as an anonymous subclass of the Property trait. The name is overridden to be the string "HI". But when the REPL prints the value of toString, it shows the value null for name. This is due to order of initialization. The base trait, Property, is initialized first during construction. When the toString method looks for the value of name, it hasn’t been initialized yet, so it finds the value null. After this, the anonymous subclass is constructed and the name property is initialized.
Two ways to solve the problem exist. The first is to define the toString method as lazy. Although this delays when the toString method will look for the value of the name property, it doesn’t guarantee that the initialization order is correct. The better solution is to use early member definitions.
Scala 2.8.0 reworked the initialization order of traits. Part of this was the creation of early member definitions. This is done by creating what looks like an anonymous class definition before mixing in a trait. Here’s an example:
scala> class X extends { val name = "HI" } with Property defined class X scala> new X res2: X = Property(HI)
The class X is defined such that it extends the Property trait. But before the Property trait is an anonymous block containing the early member definition. This is a block containing a definition of the val name. When constructing the class X, the toString method correctly displays the name HI. A second way to declare early initializers exists.
scala> new { val name = "HI2" } with Property res3: java.lang.Object with Property{ val name: java.lang.String("HI2")} = Property(HI2)
The next line constructs a new anonymous Property. The anonymous block after the new keyword is the early member definition. This defines the members that should be initialized before the Property trait’s constructor is initialized. The REPL prints the correct toString from the Property value.
Early member definitions solve issues that occur when a trait defines an abstract value and relies on it in other concrete values. We usually avoid this situation due to issues from previous versions of Scala. For any complicated trait hierarchies, early member initializations provide a more elegant solution to the problem. Because the members that need early initialization can be buried behind several layers of inheritance, it’s important to document these throughout a type hierarchy.
Scala makes multiple inheritance simpler and provides mechanisms for dealing with the complicated situation. Early member definitions are one such way. Some things can be done to help prevent issues in the future such as providing empty implementations for abstract methods.
One of the first things I tried to do when first toying with the Scala language was use traits for a kind of “mixin inheritance.” The problem I was trying to solve involved modeling a real-world situation. I needed to be able to create managed objects, including physical servers, network switches, and so on. The system needed to emulate the real world and create realistic-looking data that would be fed through our application’s processing stream. We used this simulation shown in the following figure 4.1 to test “maximum throughput” of the software.
We want this system to model real-world entities as best as possible. We also want the ability to mix in different behaviors to our entities, where certain base traits could provide default behavior. Starting out, we want to model network switches and network servers, including Windows and Linux servers, along with some form of agent that runs on these services and provides additional functionality. Let’s create a simple base class for a SimulationEntity.
trait SimulationEntity { def handleMessage(msg: SimulationMessage, ctx: SimulationContext): Unit }
This is a simple trait that contains a handleMessage method. This method takes in a message and a context and performs some behavior. The design of the simulation is such that each entity will communicate through a simulation context via messages. When an entity receives a message, it updates its current state and sends messages appropriate to that state. The context can also be used to schedule behavior for later in the simulation. We’re off to a great start. Let’s define a simple NetworkEntity trait with simple NetworkEntity behavior. Remember that in a chain-of-command pattern, we want to define a base set of functionality and defer the rest to a parent class.
Scala traits have a handy property of not defining their super class until after they have been mixed in and initialized. This means that an implementer of a trait doesn’t necessarily know which type super will be until a process called linearization occurs.
Linearization is the process of specifying a linear ordering to the superclasses of a given class. In Scala, this ordering changes for each subclass and is reconstructed for classes in the hierarchy. This means that two subclasses of some common parent could have different linearizations and therefore different behaviors.
Because of linearization, the NetworkEntity trait could be using super correctly, or it might not, as the compilation output implies:
simulation.scala:21: error: method handleMessage in trait SimulationEntity is accessed from super. It may not be abstract unless it's overridden by a member declared `abstract' and `override' case _ => super.handleMessage(msg, ctx) ^ one error found
To make this work properly, the Scala compiler must know that no matter what, we can safely call super.handleMessage. This means we have to do one of two things: define a self-type or make the abstract method have a default “do nothing” implementation that would get called. The self-type approach could work, but it limits how your trait could be mixed in. We would be defining an alternative “base” that the trait had to be mixed into. This base would then need to have some kind of implementation for handleMessage. This provides too much restriction for the aims of the application.
The right way to approach this is to implement the method in the Simulation-Entity trait. This gives all our mixed-in traits the ability to delegate to super, which is a common theme when using traits as mixins. You must select some point in an object hierarchy where traits may start being mixed in. In our simulation, we desire to start directly at the top with SimulationEntity. But if you’re attempting to use traits with a Java hierarchy, this might not be the case. You may desire to start mixing into some lower-level abstraction. In the case of Java Swing, you could start your trait mixin classes with a javax.swing.JComponent rather than something lower, like a java.awt.Component. The point is that you need to select the right location to ensure that your mixin-delegate behavior will work correctly.
Sometimes with real-life libraries you can’t find default behaviors to delegate into. In this case, you might think that you could provide your own “empty implementation” trait. Let’s see if we can do that on your network simulation example. Let’s define your classes like so:
This code looks like a perfectly reasonable class hierarchy and compiles correctly, but it doesn’t work in practice. The reason is that the linearization of a concrete entity (Router in this case) doesn’t work with the MixableParent trait; things aren’t ordered as we’d like. The issue arises when we try to create a Router with NetworkEntity class. This class compiles fine but fails to handle the Test message at runtime, because this is how the linearization works. The following figure 4.2 shows the class hierarchy for a Router with NetworkEntity class and numbering classes/traits in their linearization order. This order determines what super means for each trait in the hierarchy.
As you can see, the MixableParent class is being called directly after NetworkEntity but before Router. This means that the behavior in NetworkEntity is never called because the MixableParent doesn’t call its super! Therefore, we have to find a way of getting MixableParent earlier in the linearization. Because things linearize right to left in Scala, we want to try creating a MixableParent with Router with NetworkEntity. That first requires turning the Router class into a trait. This might not be feasible in real life, but let’s continue the exercise. We’ll see what this looks like in a Scala REPL session:
In Scala, trait linearization means that super calls within a trait may be different depending on how an object is linearized. To provide full flexibility, each composable trait should be able to call a super method, even in that super method doesn’t do anything.
As you can see, the behavior is now correct, but it isn’t quite intuitive that you have to use the MixableParent first in every entity creation. Also, the Router trait suffers from the same issues as MixableParent. It doesn’t delegate to its parent class! This is okay because Router is an entity that other behavior is mixed into, but in some cases this would be unacceptable. Also, there are cases where you can’t convert your classes into traits.
When creating a hierarchy of mixable behaviors via trait, you need to ensure the following:
An aphorism among the Java community is “favor composition over inheritance.” This simple advice means that it’s usually best in object-oriented Java to create new classes that “contain” other classes, rather than inherit from them. This allows the new class to use features/functionality of several other classes, whereas inheritance is limited to one class. This advice also has other benefits, including creating more self-contained “do one thing well” classes. Interestingly, Scala blurs this aphorism with its addition of traits.
Scala traits are composable in flexible ways. You can decide the ordering of polymorphic behavior by adjusting the order trait inheritance is declared. Multiple traits can also be inherited. These features combine to make traits a viable mechanism of composing functionality. Trait composability isn’t all roses; there are still some issues that aren’t addressed. Let’s look at the issues associated with composing behavior via inheritance in Java in table 4.1. Let’s look at the complaints associated with composing behavior via inheritance in Java and see how they stack up against Scala. I refer to composing behavior via inheritance as “inheritance-composition” and classes/traits that can do this as “inheritance-composable.” Composition that’s done via members of an object I’ll refer to as “member-composition” and classes/traits that can do this as “member-composable.”
|
Issue |
Java interfaces |
Java abstract classes |
Scala traits |
|---|---|---|---|
| Reimplement behavior in subclasses | X | ||
| Can only compose with parent behavior | X | ||
| Breaks encapsulation | X | X | X |
| Need to call a constructor to compose | X | X | X |
Scala traits immediately solve the problem of having to reimplement behavior in subclasses. They also use a clever trick to support multiple-inheritance on the JVM, making them “inheritance-composable” with more than one parent’s behavior. Scala traits still suffer from two major issues, breaking encapsulation and needing access to a constructor. Let’s look at how critical breaking encapsulation is.
Scala traits break encapsulation when used for composable behaviors. Let’s see what the impact of this would be. Suppose we have a class that represents a data access service in the system. This class has a set of query-like methods that look for data and return it. Suppose also that we want to provide a logging ability so we can do postmortem analysis on a system if it runs into an issue. Let’s see how this would look with classic composition techniques:
Notice how the DataAccess class uses the Logger class. The current method of composition means that the DataAccess class must be able to instantiate the Logger class. An alternative would be to pass a logger into the constructor of the DataAccess class. In either case, the DataAccess trait contains all logging behavior. One point about the preceding implementation is that the logging behavior is nested in your DataAccess class. If we instead wanted to also have the ability to use DataAccess with no Logger, then we need to create a third entity that composes behavior from the first two. It would look something like this:
trait Logger { def log(category: String, msg: String) : Unit = { println(msg) } } trait DataAccess { def query[A](in: String) : A = { ... } } trait LoggedDataAccess { val logger = new Logger val dao = new DataAccess def query[A](in: String) : A = { logger.log("QUERY", in) dao.query(in) } }
Now we have standalone classes Logger and DataAccess that are minimal in implementation. We’ve composed their behavior into the third LoggedDataAccess class. This implementation has all the benefits of DataAccess and Logger being encapsulated and doing only one thing. The LoggedDataAccess class aggregates the two, providing mixed behavior. The issue here is that LoggedDataAccess doesn’t implement the DataAccess interface. These two types can’t be used interchangeably in client code via polymorphism. Let’s see what this would look like with pure inheritance:
trait Logger { def log(category: String, msg: String) : Unit = { println(msg) } } trait DataAccess { def query[A](in: String): A = { ... } } trait LoggedDataAccess extends DataAccess with Logger { def query[A](in: String): A = { log("QUERY", in) super.query(in) } }
Notice how the LoggedDataAccess class is now polymorphic on DataAccess and Logger. This means you could use the new class where you would expect to find a DataAccess or Logger class, so this class is better for later composition. Something is still strange here: LoggedDataAccess is also a Logger. This seems an odd dichotomy to have for a DataAccess class. In this simple example, it seems Logger would be an ideal candidate for member-composition into the LoggedDataAccess class.
Another way to design these two classes (outlined in “Scalable Component Abstractions” by Oderksy and colleagues) involves inheritance-composition and member-composition. To start, let’s create a Logger trait hierarchy. The hierarchy will have three logger types, one for local logging, one for remote logging, and one that performs no logging.
trait Logger { def log(category: String, msg: String): Unit = { println(msg) } } trait RemoteLogger extends Logger { val socket = ... def log(category: String, msg: String): Unit = { //Send over socket } } trait NullLogger extends Logger { def log(category: String, msg: String): Unit = {} }
The next thing we do is create what I’ll call an abstract member-composition class. This abstract class defines an overridable member. We can then create subclasses matching all the existing Logger subclasses.
trait HasLogger { val logger: Logger = new Logger } trait HasRemoteLogger extends HasLogger { override val logger: Logger = new RemoteLogger {} } trait HasNullLogger extends HasLogger { override val logger: Logger = new NullLogger {} }
The HasLogger trait does one thing: contains a logger member. This class can be subclassed by other classes who want to use a Logger. It gives a real “is-a” relationship to make inheritance worthwhile to Logger users. “Why the indirection?” you may be asking yourself. The answer comes with the ability to override members as you would methods in Scala. This allows you to create classes that extend HasLogger and then mixin the other HasLogger traits later for different behavior. In the following listing, let’s look at using the HasLogger trait to implement our DataAccess class.
trait DataAccess extends HasLogger { def query[A](in: String) : A = { logger.log("QUERY", in) ... } }
Now for the real fun. Let’s write a unit test for the DataAccess class. In the unit test, we don’t want to be logging output; we want to test the behavior of the function. To do so, we want to use the NullLogger implementation. Let’s look at a specification test for DataAccess:
We now have the ability to change the composition of the DataAccess class when we instantiate it. As you can see, we gain the benefits of member-composition and inheritance composition at the cost of more legwork. Let’s see if Scala has something that could reduce this legwork.
A trait containing multiple abstract members is sometimes called an environment. This is because the trait contains the environment needed for another class to function.
In the case of classic Java-like inheritance, we can try to compose using constructor arguments. This reduces the number of parent classes to one, as only abstract/concrete classes can have arguments, and they can only be singly inherited. But Scala has two features that will help you out:
In the following listing, let’s recreate the DataAccess class, but this time as a full up class where the logger is a constructor argument. Let’s also define a default argument for logger. We’ll promote this argument to be an immutable member on the Data-Access class.
class DataAccess(val logger: Logger = new Logger {}) { def query[A](in: String) : A = { logger.log("QUERY", in) ... } }
This class is simple. It defaults to a particular logger at instantiation time and lets you supply your own (via constructor) if desired. The real fun comes when we want to extend this class, provide users with a mechanism to supply a logger to the subclass and use the same default as the DataAccess class. To do so, we’ll have to understand how the compiler collects default arguments.
When a method has default arguments, the compiler generates a static method for obtaining the default. Then when user code calls a method, if it doesn’t supply an argument, the compiler calls the static method for the default and supplies the argument. In the case of a constructor, these arguments get placed on the companion object for the class. If there’s no companion object, one will be generated. The companion object will have methods for generating each argument. These argument-generating methods use a form of name mangling so the compiler can deterministically call the correct one. The mangling format is method name followed by argument number, all separated with $. Let’s look at what a subclass of DataAccess would have to look like for our requirements:
class DoubleDataAccess( logger: Logger = DataAccess.`init$default$1` ) extends DataAccess(logger) { ... }
You’ll notice two things in this code. First, the constructor is pickled with a method name of init. This is because in the JVM bytecode, constructors are called <init>. The second is the use of the backtick (`) operator. In Scala, this method is used to denote “I’m going to use an identifier here with potentially nonstandard characters that could cause parsing issues.” This is handy when calling methods defined in other languages that have different reserved words and identifiers.
We’ve finally created a method of simplifying composition using constructor arguments. The method certainly suffers from ugliness when trying to also include inheritance in your classes. Let’s look at the pros and cons of each compositional method in the following table:
|
Method |
Pros |
Cons |
|---|---|---|
| Member composition |
|
|
|
||
| Inheritance composition |
|
|
| Abstract member composition |
|
|
| Composition using constructor with default arguments |
|
|
Many “new” methods of doing object composition are possible within Scala. I recommend picking something you’re comfortable with. When it comes to inheritance, I prefer “is-a” or “acts-as-a” relationships for parents. If there’s no “is-a” or “acts-as-a” relationship and you still need to use inheritance-composition, use the abstract member composition pattern. If you have single-class hierarchies and no “is-a” relationships, your best option is composition using constructors with default arguments. Scala provides the tools you need to solve the problem you have at hand. Make sure you understand it fully before deciding on an object-composition strategy.
In section 11.3.2, we show an alternative means of composing objects using a functional approach. Although the concepts behind this approach are advanced, the approach offers a good middle ground between using constructors with default arguments and abstract member composition.
It’s possible to mix implementation and interface with traits, but it is still a good idea to provide a pure abstract interface. This can be used by either Scala or Java libraries. It can then be extended by a trait which fills in the implementation details.
Modern object-oriented design promotes the use of abstract types to declare interfaces. In Java, these use the interface keywords and can’t include implementation. In C++ the same could be accomplished by using all pure virtual functions. A common pitfall among new Scala developers was also an issue with C++: With the new power of traits, it can be tempting to put method implementations into traits. Be careful when doing so! Scala’s traits do the most to impact binary compatibility of libraries. In the following listing, let’s look at a simple Scala trait and a class that uses this trait to see how it compiles:
trait Foo { def someMethod(): Int = 5 } class Main() extends Foo{ }
The following listing shows the javap output for the Main class:
As you can see, with some adjustment to reading JVM bytecode, the Main class is given a delegate class from the compiler. One obvious issue with binary compatibility is that if the Foo trait is given another method, the Main class won’t be given a delegate method without recompiling it. The JVM does something funny, though. It will allow you to link (think binary compatibility) even if a class doesn’t fully implement an interface. It errors out only when someone tries to use a method on the interface that’s unimplemented. Let’s take it for a test toast in the following listing. We’ll change the Foo trait without modifying the Main class.
trait Foo { def someMethod(): Int = 5 def newMethod() = "HAI" }
As you can see, we’ve added the newMethod method. We should still be able to use the compiled Main to instantiate a Foo at runtime. Here’s what it looks like:
object ScalaMain { def main(args : Array[String]) { val foo: Foo = new Main(); println(foo.someMethod()); println(foo.newMethod()); } }
You’ll notice we’re making a new Main object and coercing its type to be a Foo. The most interesting piece of this class is that it compiles and runs. Let’s look at its output.
java -cp /usr/share/java/scala-library.jar:. ScalaMain 5 Exception in thread "main" java.lang.AbstractMethodError: Main.newMethod()Ljava/lang/String; at ScalaMain$.main(ScalaMain.scala:7) at ScalaMain.main(ScalaMain.scala)
Notice that the classes link fine; it even runs the first method call! The issue comes when calling the new method from the Foo trait. This finally causes an Abstract-MethodError to be thrown, the closest we get to a linking error. The confusing part to a Scala newcomer is that the trait provides a default implementation! Well, if we want to call the default implementation, we can do so at runtime. Let’s look at the modified ScalaMain in the following listing:
object ScalaMain { def main(args: Array[String]) { val foo: Foo = new Main() println(foo.someMethod()) val clazz = java.lang.Class.forName("Foo$class") val method = clazz.getMethod("newMethod", Array(classOf[Foo]): _*) println(method.invoke(null, foo)); } }
You’ll see we’re looking up and using the new method via reflection. Here’s the runtime output:
java -cp /usr/share/java/scala-library.jar:. ScalaMain 5 HAI
This points out an interesting side of the JVM/Scala’s design; methods added to traits can cause unexpected runtime behavior. Therefore it’s usually safe to recompile all downstream users, to be on the safe side. The implementation details of traits can throw off new users, who expect new methods with implementations to automatically link with precompiled classes. Not only that, but adding new methods to traits will also not break binary compatibility unless someone calls the new method!
When creating two different “parts” of a software program, it’s helpful to create a completely abstract interface between them that they can use to talk to each other. See figure 4.3. This middle piece should be relatively stable, compared to the others, and have as few dependencies as possible. One thing you may have noticed from earlier is that Scala’s traits compile with a dependency on the ScalaObject trait. It’s possible to remove this dependency, something that’s handy if the two pieces of your software wanted to use differing Scala-library versions.
The key to this interaction is that each module depends on the common interface code and no artifacts from each other. This strategy is most effective when there are different developers on module A and module B, such that they evolve at different rates. Preventing any kind of dependencies between the modules allows the new module systems, such as OSGi, to dynamically reload module B without reloading module A so long as the appropriate framework hooks are in place and all communications between the modules A and B happen via the core-api module.
To create a trait that compiles to a pure abstract interface, similar to a Java interface don’t define any methods. Look at the PureAbstract trait in the following listing:
trait PureAbstract { def myAbstractMethod(): Unit }
Now let’s look at the javap disassembled code:
javap -c PureAbstract Compiled from "PureAbstract.scala" public interface PureAbstract{ public abstract void myAbstractMethod(); }
You’ll notice the PureAbstract trait doesn’t have a dependency on ScalaObject. This is a handy method of creating abstract interfaces when needed; it becomes important when used with module systems like OSGi. In fact, this situation is similar to the one faced when interfacing two C++ libraries using C interfaces.
Although this rule may seem contradictory to the “Provide empty implementations for abstract methods,” the two are used to solve differing problems. Use this rule when trying to create separation between modules, and provide implementations for abstract methods when creating a library of traits you intend users to extend via mixins. Pure abstract traits also help explicitly identify a minimum interface. A dichotomy of thought exists here. Some designers prefer “rich” APIs, and others prefer “thin,” where a thin API would be the minimum necessary to implement a piece of functionality, and a rich API would contain a lot of extra helper methods to ease usage.
Scala traits bring the power to add lots of helper methods, something lacking in Java’s interfaces. This kind of power was common in C++, which also suffered many more issues with binary compatibility. In C++, binary compatibility issues forced the creation of a pure “C” integration layer for libraries. This layer wrapped a rich C++ hierarchy inside the library. Clients of the library would then implement wrappers around the C layer, converting back from classless world to OO and providing the “rich” API. In my experience, these classes usually were thin wrappers around the C layer and mostly lived in header files, such that users of the library could gain binary compatibility without having to write their own wrapper.
In Scala, we can provide our rich interface via a simple delegate trait and some mixins. The “thin” interface should be something that we can reasonably expect someone to implement completely. This way the users of the “abstract interface” can grow their rich interface as needed for their project, assuming the “thin” interface is complete.
When you have two pieces of software that will be interacting but were developed by diverse or disparate teams, you should promote abstract interfaces into their own traits and lock those traits down as best as possible for the life of that project. When the abstract interface needs to be modified, all dependent modules should be upgraded against the changed traits to ensure proper runtime linkage.
Scala can infer return types to methods. However, for a human reading a nontrivial method implementation, infering the return type can be troubling. In addition, letting Scala infer the return type can allow implementation details to slip past an interface. It’s best to explicitly document and enforce return types in public APIs.
Imagine you’re developing a messaging library. This library contains a Message-Dispatcher interface that users of your library can use to send messages. A Factory method also takes various configuration parameters and returns a MessageDispatcher. As a library designer, we decide that we want to rework existing implementation to create different MessageDispatcher implementations based on the parameters to the Factory method. Let’s start with a MessageDispatcher trait in the following listing:
trait MessageDispatcher[-T] { def sendMessage(msg: T) : Unit }
The trait is rather simple; it provides a mechanism to send messages. Now let’s create the factory and an implementation class:
class ActorDispatcher[-T, U <: OutputChannel[T]](receiver: U) extends MessageDispatcher[T] { override def sendMessage(msg: T) { receiver ! msg } } object MyFactory { def createDispatcher(a: OutputChannel[Any]) = new ActorDispatcher(actor) }
The code is pretty standard. The actor dispatcher will transmit messages to an actor in the Scala actors library. We’ll discuss that library in depth later. For now, we’ll focus on the createDispatcher factory method. This method looks standard but has one issue: The return type isn’t a MessageDispatcher but an ActorDispatcher. This means we’ve leaked our abstraction. See the javap output for proof:
public final class MyFactory$ extends java.lang.Object implements scala.ScalaObject{ public static final MyFactory$ MODULE$; public static {}; public ActorDispatcher createDispatcher(java.lang.Object); }
We’ve leaked the ActorDispatcher class in the public API. This may be okay in a small project, but it lends itself to issues if others rely on receiving ActorDispatcher instances from this method instead of a MessageDispatcher. We can easily change this by refactoring your API slightly to return more than one type. Let’s create a Null-Dispatcher that doesn’t send messages. We also change the createDispatcher method to take in any type of object and return appropriate dispatchers for each. If we don’t have a useful dispatcher, we’ll use the NullDispatcher.
object NullDispatcher extends MessageDispatcher[Any] { override def sendMessage(msg: Any) : Unit = {} } object MyFactory { def createDispatcher(a: Any) = { a match { case actor: OutputChannel[Any] => new ActorDispatcher(actor) case _ => NullDispatcher } } }
This slight change has made the compiler reinfer a different return type. We can see proof of this in the new javap output:
public final class MyFactory$ extends java.lang.Object implements scala.ScalaObject{ public static final MyFactory$ MODULE$; public static {}; public MessageDispatcher createDispatcher(java.lang.Object); }
The resulting API has inferred MessageDispatcher as the return type. This could silently break code that was relying on receiving an ActorDispatcher. It’s easy enough to annotate the return type for a public API. Modify the createDispatcher method as follows:
object MyFactory { def createDispatcher(a: Any): MessageDispatcher[Any] = { a match { case actor: OutputChannel[Any] => new ActorDispatcher(actor) case _ => NullDispatcher } } }
Now the return type is locked to MessageDispatcher[Any] and anything that violates this will cause a compiler warning, rather than breaking client code.
To help avoid confusion or leaking implementation details, it’s best to provide explicit return types on public methods in your API. This can also help speed compilation slightly, as the type inferences don’t need to figure out a return type, and it gives a chance for your implicit conversions to kick in, coercing things to the desired type. The only time it would be okay to not specify return types is in the case of sealed single-class hierarchy, a private method, or when overriding a method in a parent that explicitly declares a return type. Ironically, when coding in a functional style, you find that you tend not to use inheritance as much as you would think. I find this rule generally applies to my domain model and perhaps my UI library, but not the more functional aspects of my code.
Scala’s object system is powerful and elegant. The body of code in a class definition defines the constructor of a class. For top-level objects, this means that code in the body should avoid expensive operations and other non-construction behavior. Scala also allows mixin inheritance. But when defining methods, only methods marked with override can override an existing implementation in the hierarchy. Adding override can help ease mixin inheritance and avoid method typos. Mixin inheritance also provides a new way to compose software. Mixins can mark objects as having a value and allow new values to be mixed in via inheritance. This technique provides the most flexibility when pure abstract interfaces are used for the API systems. Finally, type inference can change an API as the object model expands. For public methods, it’s best to explicitly annotate return types on critical interfaces. This leads to the best use of objects in Scala.


Hello runner! It is our pleasure to have you here with us at the Ridge Runners 5th Anniversary Run! Press 'START' whenever you are ready to run. We will be tracking...


Poachers kill 2 southern white rhinos
by PAULINE KAIRUIn Summary
- The attack at the Lewa Wildlife Conservancy in Meru County is believed to have taken place at around 11pm on Friday, as it rained heavily.
- Dr Tuqa Jirmo, Lewa’s Chief Operations Officer, termed the loss devastating, "after six years of successfully keeping all rhinos in the conservancy safe and recording high birth rates'.
- According to the World Wide Fund for Nature, Kenya is home to around 1,000 rhinos, two-thirds of which are critically endangered black rhinos.
Police and the Kenya Wildlife Service are pursuing suspects involved in a poaching incident that left two male southern white rhinos dead and their horns clipped.
The attack at the Lewa Wildlife Conservancy in Meru County is believed to have taken place at around 11pm on Friday, as it rained heavily.
“Our rangers heard gun shots but it was raining heavily ... the terrain are impossible to patrol during such times," said Joseph Kabiru, an employee at the conservancy.
"The poachers had already disappeared by the time our rangers got to the scene. Usually, poachers take advantage of the heavy rains which make most of the conservancy difficult to access. Police and KWS officers have taken the lead on the matter.”
"SCOURGE"
Dr Tuqa Jirmo, Lewa’s Chief Operations Officer, termed the loss devastating, "after six years of successfully keeping all rhinos in the conservancy safe and recording high birth rates'.
"Since the incident, we have been working tirelessly with the Kenya Police and the [KWS] to apprehend the criminals."
Dr Jirmo noted that the incident served as a reminder that the threat from poaching is ever-present so animal sanctuaries cannot be complacent.
"The poaching scourge and illegal rhino horn trade continue to put the survival of rhinos at risk across the continent.”
Tourism CS Najib Balala said in an event yesterday, “The numbers of rhinos killed by poachers had dropped to single digits while those of elephants had dropped to just 38 last year from the hundreds killed years back.”
ENDANGERED
According to the World Wide Fund for Nature, Kenya is home to around 1,000 rhinos, two-thirds of which are critically endangered black rhinos – the rarer of Africa’s two rhino species, with just 5,000 left in the wild globally.
This is in comparison to around 20,000 white rhinos.
It was reported in the 80s that Kenya’s rhino population had dropped to less than 400.
In 2017, however, the KWS reported that the rhino populations were rising, with a reported number of 1,258 at the time, including 745 black rhinos.
Lewa, which was founded in 1995, spans 61,000 acres and holds 13 per cent of Kenya’s black rhino population and 12 per cent of the world’s Grevy’s zebras.

This is mainly driven by a huge surge in the demand for rhino horn in Asia – especially Vietnam - where it's seen as a status symbol.
Kenya’s worst poaching year was in 2013, when 59 animals or at least five per cent of the national population were killed.
The rhino poaching crisis began in 2008, with increasing numbers of the animals killed for their horn throughout Africa until 2015.
However, there has been a decrease in the number of rhinos poached across the continent since the peak of 1,349 in 2015.


IntroductionFrequently asked questionsSyntax, keywords and built-in functionsStandard distributionimport implementationBrowser interface
Introduction - DOM API
Creating a document Accessing elements Attributes and methods Events Mouse events Keyboard events Focus events Drag events Query string Using Javascript objects and libraries Brython-specific built-in modules
browser
browser.ajax browser.html browser.local_storage browser.markdown browser.object_storage browser.session_storage browser.svg browser.timer browser.websocket javascript Working with Brython
Options of function
brython()
Installing the development environment Testing and debugging Deploying an application Brython for Firefox OSCookbook |
Options of function
To run the Python scripts in the page, you must call the function |


Type in 'DELETE' without ' ' to confirm you wish to delete your account


All Blockchain events and industry conferences on BlockEvent.co is available in iCalendar (.ics) format. You can subscribe the calendar in any compatible web calendar or apps and it keeps your calendar in sync.
Copy the url above and go to your calendar:
Google Calendar: Find "Add calendar" on the left sidebar and click on the "dots", click "From URL". Then paste the URL into input box and click "Add calendar".
Apple Calendar (macOS App): Click "New Calendar Subscription" under "File" menu. Then paste the URL into input box and click "Subscribe".
Outlook.com Calendar: Click "Discover calendars" on the left sidebar and find "Import calendar", click "From Web". Then paste the URL into input box, type the name "Blockchain Conferences & Events" and click "Import".
It is free to have your Blockchain event listed on BlockEvent.co. Please fill in this form to submit your event.


| 232 | (A) | and al to-thruschede als the clothe thorowe the kirke passede |
| (C) | ---- no text ---- | |
| 231 | (D) | And al to-clatrid as þe clothe to þe kyng ȝede |
| 231 | (E) | And al to-clateryd as þe clooth . to þe kyng ȝede . |
| (Ex) | ---- no text ---- | |
| 236 | (L) | & al to-crased as þe cloþ þroȝ þe kirke passed |
| 229 | (P) | And ałł to-crached als þe cloth thurgh þe kyrke ȝode |
| 229 | (U) | And al to crased os the clothe / to the chirche yede |
| (V) | ---- no text ---- |


Interesting week for stablecoins.
Recently BitShares bitUSD went into "global settlement," meaning that users can no longer borrow bitUSD from the chain, but they can convert it into collateral (BTS) at the global settlement price, currently about $0.70.


About Me:
I am Shaunak Guchhait, a student keen to know everything about technology. In this modern world people are advacing with technology at a very high rate and creating wonderful and useful things with their
creative mind. Being a enthusiastic coder and tech geek, I also intend to contribute not great but small creations of my own.
Languages Learned:
↪ Java
↪ HTML5
↪ CSS3
↪ JavaScript


A Flavours registry for automatically resolving Java Artefacts. No datastorage is used in this project and all requests are handled stateless.
git clone git@github.com:flavours/registry-java.git
cd registry-java
docker-compose build
The project includes a web
service, running the Java code. See the docker-compose.yml
file for details.
docker-compose up
Containers for the registry will be launched. The project can be reached at http://localhost:8000.
Hot-reloading is enabled (i.e. changes to the Java code in the project will cause the application to restart so that they can be used.)
You can run these quick tests to make sure the service works fine.
curl -XPOST http://localhost:8000/addonversions/resolve/ -d 'query=java/com.amazon/aws-s3:1.2.3'
curl http://localhost:8000/addonversions/amF2YS9jb20uYW1hem9uL2F3cy1zMzoxLjIuMw/
curl http://localhost:8000/addons/amF2YS9jb20uYW1hem9uL2F3cy1zMzoxLjIuMw/
curl http://localhost:8000/stacks/77bde934-5d73-4d25-9222-e74adb48ef3e/
curl http://localhost:8000/namespaces/380ca58e-32dc-4a90-831d-b63a57a8f621/
Of use the flavour CLI:
flavour check --verbose java/com.amazon/aws-s3:1.2.3 --registry=http://localhost:8000/
The app uses the environment variables SCHEME
, DOMAIN
and PORT
to create URLs in responses. For local development the values specified in .env_local are used.
The container runs a Tomcat server listening on port 8080. The docker-compose.yml
file is set up to expose this port to the Docker host at port 8000, but you are free to change it as you wish - edit the ports
directive:
services:
web:
[...]
ports:
- 8000:8080
See the contribution guide.
To create a new release of this project, you have to updated the default welcome screen with the latest version.
docker run --rm --volume "`pwd`:/data" --user `id -u`:`id -g` pandoc/core:2.9.2 -s --css https://utils.flavours.dev/baseproject/1.0/style.css -o /data/src/main/resources/templates/index.html /data/README.md
Please also update the changelog accordingly and tag a new release in github.


@* * Copyright 2023 HM Revenue & Customs * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. *@ @import sdil.models.Address @import sdil.models.retrieved.RetrievedSubscription @import views.html.softdrinksindustrylevy.helpers._ @import helper.{inputRadioGroup => _, _} @this() @(key: String, subscription: RetrievedSubscription, address: Address)(implicit request: Request[_], messages: Messages) @helper.form(action = play.api.mvc.Call("post", key)) { @CSRF.formField


---
layout: page
title: "League Rules"
description: "Follow these rules!"
header-img: "/img/bg-shoes-with-ball.jpg"
---
- Home
- About
- League Rules
- Each team has a goalkeeper and 4 players on the field (5 total)- minimum 3
- The Carmichael Futsal League will be played on a basketball court
- The penalty box is a semi circle with a ~4m radius
- No off-sides
- When the entire ball goes out of bounds over the sideline, play is restarted with a kick-in
- The kick-in cannot go directly into the goal, except corner kicks
- When the ball goes out over the end line, it is put back into play either by the goalie throwing the ball back into the playing area, or awarding a Corner Kick
- Goal keeper cannot punt or drop kick the ball
- Goal keeper throw may not go over the half court line in the air
- After a goal has been scored, it is put back into play by a kick-off
- Home team opens with kickoff, away team opens 2nd half with kickoff
- Players can score from anywhere on the field
- Scoring- when the entire ball passes over the goal line, between the goal posts and under the crossbar (except by illegal means)
- All fouls result in direct kicks
- If, while the ball is still in play, the referees are required to stop play temporarily for any reason not mentioned elsewhere in these rules, the match is restarted with a kickin by the team that posessed the ball or a drop ball if posession was not established
- Each game is 34 minutes in duration (2x 17 minute halves, running clock only stops for 5 minutes at halftime or for prolonged injuries)
- Equipment: shorts, socks, shin-guards and footwear with flat, rubber soles
- Ball sizes:
- U12 and under - size 3 or a Select "Jinga"
- U14 and older – size 4 FUTSAL ball
Referee
Referees manage the game to ensure a safe environment and that players put the ball back into play properly. Referees dress distinctly from players.
Timekeeper
Start game clock after kick-off, indicate end of first half and match with some sort of sound; record scorers, and players cautioned and sent off, and other information relevant to the game.
Kick-in
- To be taken in place of the throw-in, placed on touchline before kicking.
- The kick-in must be taken within 5 seconds; if it is not, the kick-in is given to the opposing team.
- The kicker cannot play the ball a second time until it has been played by another player.
- Players on opposing team must be at least 3 m away from point of kick-in.
- Cannot score directly from a kick-in.
Goal Clearance
- To be taken in place of goal kick.
- From inside the penalty area, the goalkeeper throws the ball into play.
- The ball is not in play until it has passed outside of the penalty area. If the goal clearance is received inside of the penalty area, the goal clearance shall be taken over.
Corner Kick
- Ball placed on the corner (no corner-kick arc). If ball is misplaced, the corner kick is re-taken.
- Must be taken within 5 seconds or turned over to other team
- The kicker cannot play the ball a second time until it has been played by another player.
- Opposing players must be at least 3m away from point of the corner kick.
- Can score goal directly from a corner kick.
Fouls and Misconduct
All fouls are penalized with a direct free kick for the following offences: handball (except goalkeeper within penalty area), kick, trip, charge, push, hold, slide tackle, spit or attempt to do so. A direct free kick is taken from the place where the offence occurred unless the foul is committed by a player inside his own penalty area, in which case a ‘penalty kick’ is awarded- from the penalty spot.
- Opposing players must be at least 3 meters away until the ball is in play
- Ball is in play after it has rolled at least once
- Kick must be taken within 5 seconds
- Kicker cannot touch the ball again until it has been touched by another player
Penalty Kick
A penalty kick is awarded against a team that commits a foul inside its own penalty area.
- To be taken from the penalty mark on the midpoint of the 6-m-line.
- All players must be out of the penalty area, opposing team must be at least 3 m away.
- The kicker shall not play the ball a second time until it has been touched by another player.
- The goalkeeper shall remain in his penalty area starting within 1 m of goal line.
Yellow Card Offenses:
Can be given for any of the fouls above- if committed to a greater/reckless degree or if the foul is intentional. Two yellow cards in the same match will result in a red card.
Red Card Offenses:
Carmichael Futsal has a strict policy for red card violations. Any player issued a red card will become ineligible from finishing the current match and is suspended from the next scheduled match. The player, parent, and coach will be required to meet with the league manager prior to their next eligible game. Red Card violations include: malicious intent or unsportsmanlike conduct. The player sent off (shown a red card) is out for the rest of the game and cannot sit on the bench.