Make 'Bootstrap 4' dashboards. Use the full power of 'AdminLTE3', a dashboard template built on top of 'Bootstrap 4' <https://github.com/almasaeed2010/AdminLTE/tree/v3-dev>.
| Version: | 0.2.0 |
| Imports: | shiny, htmltools |
| Suggests: | plotly, shinyWidgets, knitr, rmarkdown |
| Published: | 2018-09-20 |
| Author: | David Granjon [aut, cre], Almasaeed Studio [ctb, cph] (AdminLTE3 theme for Bootstrap 4), Winston Chang [ctb, cph] (Utils functions from shinydashboard), Thomas Park [ctb, cph] (Bootswatch Sketchy theme CSS) |
| Maintainer: | David Granjon <dgranjon at ymail.com> |
| BugReports: | https://github.com/DivadNojnarg/bs4Dash/issues |
| License: | GPL-2 |
| URL: | https://divadnojnarg.github.io/bs4Dash/index.html, https://github.com/DivadNojnarg/bs4Dash |
| NeedsCompilation: | no |
| Materials: | README NEWS |
| CRAN checks: | bs4Dash results |
| Reference manual: | bs4Dash.pdf |
| Vignettes: |
How to start? bs4Dash Showcase Themes |
| Package source: | bs4Dash_0.2.0.tar.gz |
| Windows binaries: | r-devel: bs4Dash_0.2.0.zip, r-release: bs4Dash_0.2.0.zip, r-oldrel: bs4Dash_0.2.0.zip |
| OS X binaries: | r-release: bs4Dash_0.2.0.tgz, r-oldrel: bs4Dash_0.2.0.tgz |
| Old sources: | bs4Dash archive |
| Reverse suggests: | shinyEffects |
Please use the canonical form https://CRAN.R-project.org/package=bs4Dash to link to this page.


| 1 |
Blood Systems Research Institute |
Modeling viral entry and its inhibition using SARS-CoV |
406,843 |
2,034,215 |
15 December 2007 |
30 November 2012 |
US |
| 2 |
Harvard University |
Structure and mechanism of programmed ribosomal frameshifting in SARS coronavirus |
375,687 |
1,127,061 |
7 February 2013 |
31 January 2016 |
US |
| 3 |
Katholieke Universiteit Leuven |
Virus discovery and epidemic tracing from high throughput metagenomic sequencing |
1,168,428 |
3,505,285 |
1 June 2015 |
31 May 2018 |
EU |
| 4 |
Osaka University |
Elucidation of the establishment and the virulence factors of reverse genetic manipulation system of MERS coronavirus |
48,100 |
144,300 |
1 April 2016 |
31 March 2019 |
JP |
| 5 |
Yamaguchi University |
Analysis of coronavirus evolution mechanism for appearance prediction emerging coronavirus |
21,700 |
43,400 |
24 April 2015 |
31 March 2017 |
JP |


Cate's EDA Journey
Reflection
Time and Habits
Technical Blog 1
Technical Blog 2
Emotional Intelligence
Design to Web
Meditation Process
JavaScript Basics
Daily Mindfulness
Self-Confidence
Problem-Solving
JavaScript Language
Control
Motivation


Russia says 2,000 relatives of Middle East militants pose security threat: RIA
MOSCOW (Reuters) - Russia’s FSB security service has identified 2,000 Russian nationals who are relatives of militants in the Middle East and could try to return to Russia, posing a terrorist threat, the FSB’s head said on Thursday, RIA news agency reported.
FSB director Alexander Bortnikov said such people try to reach Russia after leaving conflict areas in the Middle East via humanitarian corridors.


Debezium Connector for Db2
|
This connector is currently in incubating state, i.e. exact semantics, configuration options etc. may change in future revisions, based on the feedback we receive. Please let us know if you encounter any problems. |
Debezium’s Db2 Connector can monitor and record the row-level changes in the tables of a Db2 database. This connector is strongly inspired by the Debezium implementation of SQL Server, using a SQL based polling model of tables put into "capture mode". This uses the ASN libraries that come as a standard part of Db2 LUW and can be added to Db2 zOS.
In order to use ASN and hence this connector, you need to have a license for the IBM InfoSphere Data Replication (IIDR) product. It is not required that IIDR itself is installed.
The first time it connects to a Db2 database, it reads a consistent snapshot of all of the tables that are whitelisted (or not blacklisted depending on the mode of operation). Note that by default all tables in the database are snapshoted, NOT just those that are in capture mode.
When that snapshot is complete, the connector continuously streams the changes that were committed to the Db2 database for all whitelisted tables in capture mode. This generates corresponding insert, update and delete events. All of the events for each table are recorded in a separate Kafka topic, where they can be easily consumed by applications and services.
Overview
The functionality of the connector is based upon the ASN Capture/Apply agents that enable SQL Replication within DB2.
The capture agent generates ASN tables for all tables in CDC mode, these ASN tables can be queried via a SQL interface in order to read change events. Using this mechanism a Db2 ASN capture agent monitors all databases and tables that the user is interested in and stores the changes into specifically created ASN tables. The connector has been tested with Db2/Linux <IP_ADDRESS>, but our expectation is that the model would work for Windows, AIX and zOS as well.
The database administrator must put the tables to be monitored into capture mode.
For convenience and for automating testing we have written a User Defined Function (UDF) in C that can be compiled and then used to control the ASN agent, create the ASN schemas/tables and add/remove tables to capture.
These utilities are described in debezium-connector-db2/src/test/docker/db2-cdc-docker/
but these are only for convenience and manually performing the same commands using
db2 control commands would have the same effect.
The connector then produces a change event for every row-level insert, update, and delete operation that was published via the ASN SQL Tables, recording all the change events for each table in a separate Kafka topic. The client applications read the Kafka topics that correspond to the database tables they’re interested in following, and react to every row-level event it sees in those topics.
The database administrator normally enables CDC in the middle of the life of a table. This means that the connector does not have the complete history of all changes that have been made to the table. Therefore, when the Db2 connector first connects to a particular Db2 database, it starts by performing a consistent snapshot of each of the whitelisted tables. After the connector completes the snapshot, it continues streaming changes from the exact point at which the snapshot was made for tables in capture mode. This way, we start with a consistent view of all of the data, yet continue reading without having lost any of the changes made while the snapshot was taking place.
The connector is also tolerant of failures. As the connector reads changes and produces events, it records the position in the database log (LSN / Log Sequence Number) of the CDC record for each event. If the connector stops for any reason (including communication failures, network problems, or crashes), upon restart it simply continues reading the CDC tables where it last left off. This includes snapshots: if the snapshot was not completed when the connector is stopped, upon restart it will begin a new snapshot. Care needs to be taken with mixing multiple snapshot in the same topic as delete operations may be missed.
Setting up Db2
Before using the Db2 connector to monitor the changes committed on the Db2 database, first enable CDC on a monitored database.
We recommend using the UDF functions that we provide. However these are only for convenience and manually performing the same commands using db2 control commands would have the same effect.
We assume here that the contents of debezium-connector-db2/src/test/docker/db2-cdc-docker are available on the machine on which Db2 is running in $HOME/asncdctools/src and that the user has logged-in as the db2inst1 user.
First compile this function on the Db2 server, using the bldrtn C-compiler
$ cd $HOME/asncdctools/src
$ ./bldrtn asncdc
Start the database if not already running:
$ db2 start db <DB NAME>
We need to make sure that the metadata catalog can be read via JDBC
$ cd $HOME/sqllib/bnd
$ db2 bind db2schema.bnd blocking all grant public sqlerror continue
The database needs to have been recently backed-up, such that the ASN agents have a recent starting point to read from. Do the following if this is not the case. Note This will prune the data such that only the most recent version is available:
$ db2 backup db <DB NAME> to <BACK UP LOCATION>
/dev/null can be used for the location if the older versions of the data do not need to be retained.
$ db2 restart db <DB NAME>
Install the UDF:
$ db2 connect to <DB NAME>
We assume that the db2 tool is installed on the db2inst1 user
$ cp $HOME/asncdctools/src/asncdc $HOME/sqllib/function
$ chmod 777 $HOME/sqllib/function
Enable the UDF that allows the ASN capture agent to be started/stopped
$ db2 -tvmf $HOME/asncdctools/src/asncdc_UDF.sql
Create the ASN Control tables
$ db2 -tvmf $HOME/asncdctools/src/asncdctables.sql
Enable the UDF that allows us to add/remove tables to be captured
$ db2 -tvmf $HOME/asncdctools/src/asncdcaddremove.sql
Having done the above, we can use the UDFs to control ASN via SQL commands. Some of the UDFs expect a return value in which case we use the SQL VALUE statement to invoke them, while others are fire-and-forget in which case we use the SQL CALL statement.
First the ASN agent needs to be started:
VALUES ASNCDC.ASNCDCSERVICES('start','asncdc');
If the agent every needs to be stopped:
VALUES ASNCDC.ASNCDCSERVICES('stop','asncdc');
The status if the agent can be checked at any moment:
VALUES ASNCDC.ASNCDCSERVICES('status','asncdc');
A table MYTABLE in MYSCHEMA can be put into capture mode by doing:
CALL ASNCDC.ADDTABLE('MYSCHEMA', 'MYTABLE');
At table MYTABLE in MYSCHEMA can be removed from capture mode by doing:
CALL ASNCDC.REMOVETABLE('MYSCHEMA', 'MYTABLE');
After a table is added or removed, the user MUST reinitialize the ASN service:
VALUES ASNCDC.ASNCDCSERVICES('reinit','asncdc');
How the Db2 connector works
Snapshots
Db2 ASN is not designed to store the complete history of database changes. It is thus necessary that Debezium establishes the baseline of current table content and streams it to Kafka. This is achieved via a process called snapshotting.
By default (snapshotting mode initial) the connector will upon the first startup perform an initial consistent snapshot of the table.
Each snapshot consists of the following steps:
-
Determine the tables to be snapshoted from whitelist/blacklist
-
Obtain a lock on each of the monitored tables to ensure that no structural changes can occur to any of the tables. The level of the lock is determined by
snapshot.isolation.mode
configuration option. -
Read the maximum LSN ("log sequence number") position in the server’s transaction log.
-
Capture the structure of all relevant tables.
-
Optionally release the locks obtained in step 2, i.e. the locks are held usually only for a short period of time.
-
Scan all of the relevant database tables and schemas as valid at the LSN position read in step 3, and generate a
READ
event for each row. Then write that event to the appropriate table-specific Kafka topic with the maxiumun LSN, i.e. all snapshot insert operations (i.e those with opcode='r') have the same LSN. -
Record the successful completion of the snapshot in the connector offsets.
Reading the change data tables
Upon first start-up, the connector takes a structural snapshot of the structure of the requested tables and persists this information in its internal database history topic. Then the connector identifies a change table for each of the source tables and executes the main loop
-
For each change table read all changes that were created between last stored maximum LSN and current maximum LSN
-
Order the read changes incrementally according to commit LSN and change LSN. This assures that the changes are replayed by Debezium in the same order as were made to the database.
-
Pass commit and change LSNs as offsets to Kafka Connect.
-
Store the maximum LSN and repeat the loop.
After a restart, the connector will resume from the offset (commit and change LSNs) where it left off before.
The connector is able to detect whether the CDC is enabled or disabled for whitelisted source table during the runtime and modify its behavior.
Topic names
The Db2 connector writes events for all insert, update, and delete operations on a single table to a single Kafka topic. The name of the Kafka topics always takes the form databaseName.schemaName.tableName, where databaseName is the logical name of the connector as specified with the database.server.name
configuration property, schemaName is the name of the schema where the operation occurred, and tableName is the name of the database table on which the operation occurred.
Unlike for SQL Server, it is only possible for a connector to streams changes from one Db2 database.
For example, consider a Db2 installation with an mydatabase
database that contains four tables: PRODUCTS
, PRODUCTS_ON_HAND
, CUSTOMERS
, and ORDERS
in schema MYSCHEMA
then the connector would produce events on these four Kafka topics:
-
mydatabase.MYSCHEMA.PRODUCTS
-
mydatabase.MYSCHEMA.PRODUCTS_ON_HAND
-
mydatabase.MYSCHEMA.CUSTOMERS
-
mydatabase.MYSCHEMA.ORDERS
Events
All data change events produced by the Db2 connector have a key and a value, although the structure of the key and value depend on the table from which the change events originated (see Topic names).
|
The Debezium Db2 connector ensures that all Kafka Connect schema names are valid Avro schema names. This means that the logical server name must start with Latin letters or an underscore (e.g., [a-z,A-Z,_]), and the remaining characters in the logical server name and all characters in the schema and table names must be Latin letters, digits, or an underscore (e.g., [a-z,A-Z,0-9,\_]). If not, then all invalid characters will automatically be replaced with an underscore character. This can lead to unexpected conflicts when the database name, schema names, and table names contain other characters, and the only distinguishing characters between table full names are invalid and thus replaced with underscores. In addition, note that databases, schemas and tables can be case sensitive in Db2 meaning that different tables maybe mapped to the same Kafka topic. |
Debezium and Kafka Connect are designed around continuous streams of event messages, and the structure of these events may change over time. This could be difficult for consumers to deal with, so to make it easy Kafka Connect makes each event self-contained. Every message key and value has two parts: a schema and payload. The schema describes the structure of the payload, while the payload contains the actual data.
Change Event Keys
For a given table, the change event’s key will have a structure that contains a field for each column in the primary key (or unique key constraint) of the table at the time the event was created.
Consider a customers
table defined in the mydatabase
database’s schema MYSCHEMA
:
CREATE TABLE customers (
ID INTEGER IDENTITY(1001,1) NOT NULL PRIMARY KEY,
FIRST_NAME VARCHAR(255) NOT NULL,
LAST_NAME VARCHAR(255) NOT NULL,
EMAIL VARCHAR(255) NOT NULL UNIQUE
);
The database.server.name
configuration property is then mydatabase
.
Every change event for the customers
table while it has this definition will feature the same key structure, which in JSON looks like this:
{
"schema": {
"type": "struct",
"fields": [
{
"type": "int32",
"optional": false,
"field": "ID"
}
],
"optional": false,
"name": "mydatabase.MYSCHEMA.CUSTOMERS.Key"
},
"payload": {
"ID": 1004
}
}
The schema
portion of the key contains a Kafka Connect schema describing what is in the key portion. In this case, it means that the payload
value is not optional, is a structure defined by a schema named mydatabase.MYSCHEMA.CUSTOMERS.Key
, and has one required field named id
of type int32
.
If you look at the value of the key’s payload
field, you can see that it is indeed a structure (which in JSON is just an object) with a single id
field, whose value is 1004
.
Therefore, you can interpret this key as describing the row in the MYSCHEMA.CUSTOMERS
table (output from the connector reading from database mydatabase
) whose id
primary key column had a value of 1004
.
Change Event Values
Like the message key, the value of a change event message has a schema section and payload section. The payload section of every change event value produced by the Db2 connector has an envelope structure with the following fields:
-
op
is a mandatory field that contains a string value describing the type of operation. Values for the Db2 connector arec
for create (or insert),u
for update,d
for delete, andr
for read (in the case of a snapshot). -
before
is an optional field that if present contains the state of the row before the event occurred. The structure will be described by themydatabase.MYSCHEMA.CUSTOMERS.Value
Kafka Connect schema, which the connector reading frommydatabase
uses for all rows in theMYSCHEMA.CUSTOMERS
table. -
after
is an optional field that if present contains the state of the row after the event occurred. The structure is described by the samemydatabase.MYSCHEMA.CUSTOMERS.Value
Kafka Connect schema used inbefore
. -
source
is a mandatory field that contains a structure describing the source metadata for the event, which in the case of Db2 contains these fields: the Debezium version, the connector name, whether the event is part of an ongoing snapshot or not, the commit LSN (not while snapshotting), the LSN of the change, database, schema and table where the change happened, and a timestamp representing the point in time when the record was read from the the source database by the connector. -
ts_ms
is optional and if present contains the time (using the system clock in the JVM running the Kafka Connect task) at which the connector processed the event.
And of course, the schema portion of the event message’s value contains a schema that describes this envelope structure and the nested fields within it.
Create events
Let’s look at what a create event value might look like for our customers
table:
{
"schema": {
"type": "struct",
"fields": [
{
"type": "struct",
"fields": [
{
"type": "int32",
"optional": false,
"field": "ID"
},
{
"type": "string",
"optional": false,
"field": "FIRST_NAME"
},
{
"type": "string",
"optional": false,
"field": "LAST_NAME"
},
{
"type": "string",
"optional": false,
"field": "EMAIL"
}
],
"optional": true,
"name": "mydatabase.MYSCHEMA.CUSTOMERS.Value",
"field": "before"
},
{
"type": "struct",
"fields": [
{
"type": "int32",
"optional": false,
"field": "ID"
},
{
"type": "string",
"optional": false,
"field": "FIRST_NAME"
},
{
"type": "string",
"optional": false,
"field": "LAST_NAME"
},
{
"type": "string",
"optional": false,
"field": "EMAIL"
}
],
"optional": true,
"name": "mydatabase.MYSCHEMA.CUSTOMERS.Value",
"field": "after"
},
{
"type": "struct",
"fields": [
{
"type": "string",
"optional": false,
"field": "version"
},
{
"type": "string",
"optional": false,
"field": "connector"
},
{
"type": "string",
"optional": false,
"field": "name"
},
{
"type": "int64",
"optional": false,
"field": "ts_ms"
},
{
"type": "boolean",
"optional": true,
"default": false,
"field": "snapshot"
},
{
"type": "string",
"optional": false,
"field": "db"
},
{
"type": "string",
"optional": false,
"field": "schema"
},
{
"type": "string",
"optional": false,
"field": "table"
},
{
"type": "string",
"optional": true,
"field": "change_lsn"
},
{
"type": "string",
"optional": true,
"field": "commit_lsn"
},
],
"optional": false,
"name": "io.debezium.connector.db2.Source",
"field": "source"
},
{
"type": "string",
"optional": false,
"field": "op"
},
{
"type": "int64",
"optional": true,
"field": "ts_ms"
}
],
"optional": false,
"name": "mydatabase.MYSCHEMA.CUSTOMERS.Envelope"
},
"payload": {
"before": null,
"after": {
"ID": 1005,
"FIRST_NAME": "john",
"LAST_NAME": "doe",
"EMAIL"<EMAIL_ADDRESS>},
"source": {
"version": "1.1.2.Final",
"connector": "db2",
"name": "myconnector",
"ts_ms":<PHONE_NUMBER>470,
"snapshot": false,
"db": "mydatabase",
"schema": "MYSCHEMA",
"table": "CUSTOMERS",
"change_lsn": "00000027:00000758:0003",
"commit_lsn": "00000027:00000758:0005",
},
"op": "c",
"ts_ms":<PHONE_NUMBER>739
}
}
If we look at the schema
portion of this event’s value, we can see the schema for the envelope, the schema for the source
structure (which is specific to the Db2 connector and reused across all events), and the table-specific schemas for the before
and after
fields.
|
The names of the schemas for the |
If we look at the payload
portion of this event’s value, we can see the information in the event, namely that it is describing that the row was created (since op=c
), and that the after
field value contains the values of the new inserted row’s' ID
, FIRST_NAME
, LAST_NAME
, and EMAIL
columns.
|
It may appear that the JSON representations of the events are much larger than the rows they describe. This is true, because the JSON representation must include the schema and the payload portions of the message. It is possible and even recommended to use the Avro Converter to dramatically decrease the size of the actual messages written to the Kafka topics. |
Update events
The value of an update change event on this table will actually have the exact same schema, and its payload will be structured the same but will hold different values. Here’s an example:
{
"schema": { ... },
"payload": {
"before": {
"ID": 1005,
"FIRST_NAME": "john",
"LAST_NAME": "doe",
"EMAIL"<EMAIL_ADDRESS>},
"after": {
"ID": 1005,
"FIRST_NAME": "john",
"LAST_NAME": "doe",
"EMAIL"<EMAIL_ADDRESS>},
"source": {
"version": "1.1.2.Final",
"connector": "db2",
"name": "myconnector",
"ts_ms":<PHONE_NUMBER>937,
"snapshot": false,
"db": "mydatabase",
"schema": "MYSCHEMA",
"table": "CUSTOMERS",
"change_lsn": "00000027:00000ac0:0002",
"commit_lsn": "00000027:00000ac0:0007",
},
"op": "u",
"ts_ms":<PHONE_NUMBER>706
}
}
When we compare this to the value in the insert event, we see a couple of differences in the payload
section:
-
The
op
field value is nowu
, signifying that this row changed because of an update -
The
before
field now has the state of the row with the values before the database commit -
The
after
field now has the updated state of the row, and here was can see that theemail
value is<EMAIL_ADDRESS>. -
The
source
field structure has the same fields as before, but the values are different since this event is from a different position in the transaction log. -
The
ts_ms
shows the timestamp that Debezium processed this event.
There are several things we can learn by just looking at this payload
section. We can compare the before
and after
structures to determine what actually changed in this row because of the commit.
The source
structure tells us information about Db2’s record of this change (providing traceability), but more importantly this has information we can compare to other events in this and other topics to know whether this event occurred before, after, or as part of the same Db2 commit as other events.
|
When the columns for a row’s primary/unique key are updated, the value of the row’s key has changed so Debezium will output three events: a |
Delete events
So far we’ve seen samples of create and update events.
Now, let’s look at the value of a delete event for the same table. Once again, the schema
portion of the value will be exactly the same as with the create and update events:
{
"schema": { ... },
},
"payload": {
"before": {
"ID": 1005,
"FIRST_NAME": "john",
"LAST_NAME": "doe",
"EMAIL"<EMAIL_ADDRESS>},
"after": null,
"source": {
"version": "1.1.2.Final",
"connector": "db2",
"name": "myconnector",
"ts_ms":<PHONE_NUMBER>243,
"snapshot": false,
"db": "mydatabase",
"schema": "MYSCHEMA",
"table": "CUSTOMERS",
"change_lsn": "00000027:00000db0:0005",
"commit_lsn": "00000027:00000db0:0007"
},
"op": "d",
"ts_ms":<PHONE_NUMBER>205
}
}
If we look at the payload
portion, we see a number of differences compared with the create or update event payloads:
-
The
op
field value is nowd
, signifying that this row was deleted -
The
before
field now has the state of the row that was deleted with the database commit. -
The
after
field is null, signifying that the row no longer exists -
The
source
field structure has many of the same values as before, except thets_ms
,commit_lsn
andchange_lsn
fields have changed -
The
ts_ms
shows the timestamp that Debezium processed this event.
This event gives a consumer all kinds of information that it can use to process the removal of this row.
The Db2 connector’s events are designed to work with Kafka log compaction, which allows for the removal of some older messages as long as at least the most recent message for every key is kept. This allows Kafka to reclaim storage space while ensuring the topic contains a complete dataset and can be used for reloading key-based state.
When a row is deleted, the delete event value listed above still works with log compaction, since Kafka can still remove all earlier messages with that same key.
But only if the message value is null
will Kafka know that it can remove all messages with that same key.
To make this possible, Debezium’s Db2 connector always follows the delete event with a special tombstone event that has the same key but null
value.
Transaction Metadata
Debezium can generate events that represents tranaction metadata boundaries and enrich data messages.
Transaction boundaries
Debezium generates events for every transaction BEGIN
and END
.
Every event contains
-
status
-BEGIN
orEND
-
id
- string representation of unique transaction identifier -
event_count
(forEND
events) - total number of events emmitted by the transaction -
data_collections
(forEND
events) - an array of pairs ofdata_collection
andevent_count
that provides number of events emitted by changes originating from given data collection
Following is an example of what a message looks like:
{
"status": "BEGIN",
"id": "00000025:00000d08:0025",
"event_count": null,
"data_collections": null
}
{
"status": "END",
"id": "00000025:00000d08:0025",
"event_count": 2,
"data_collections": [
{
"data_collection": "testDB.dbo.tablea",
"event_count": 1
},
{
"data_collection": "testDB.dbo.tableb",
"event_count": 1
}
]
}
The transaction events are written to the topic named <database.server.name>.transaction
.
Data events enrichment
When transaction metadata is enabled the data message Envelope
is enriched with a new transaction
field.
This field provides information about every event in the form of a composite of fields:
-
id
- string representation of unique transaction identifier -
total_order
- the absolute position of the event among all events generated by the transaction -
data_collection_order
- the per-data collection position of the event among all events that were emitted by the transaction
Following is an example of what a message looks like:
{
"before": null,
"after": {
"pk": "2",
"aa": "1"
},
"source": {
...
},
"op": "c",
"ts_ms": "1580390884335",
"transaction": {
"id": "00000025:00000d08:0025",
"total_order": "1",
"data_collection_order": "1"
}
}
Database schema evolution
Debezium is able to capture schema changes over time. Due to the way CDC is implemented in Db2, it is necessary to work in co-operation with a database administrator in order to ensure the Debezium connector continues to produce data change events when the schema is updated.
As was already mentioned before, Debezium uses Db2’s change data capture functionality. This means that Db2 creates a capture table that contains all changes executed on the source table. Unfortunately, the capture table is static and needs to be updated when the source table structure changes. This update is not done by the Debezium connector itself but must be executed by an administrator with elevated privileges.
There are generally two procedures how to execute the schema change:
-
cold - this is executed when Debezium is stopped
-
hot - executed while Debezium is running
Both approaches have their own advantages and disadvantages.
|
In both cases, it is critically important to execute the procedure completely before a new schema update on the same source table is made. It is thus recommended to execute all DDLs in a single batch so the procedure is done only once. |
|
Not all schema changes are supported when CDC is enabled for a source table. We note here some of the likely effects:
It is recommend that if the structure of a source change is changed, that we: - that we mark the tables as inactive on the ASN register table - reinit the ASN capture service (see the UDFs) - update the ASN representation of the table (manual task) - mark the table as active - reinit the ASN capture service again (see the UDFs) |
Cold schema update
This is the safest procedure but might not be feasible for applications with high-availability requirements. The administrator should follow this sequence of steps:
-
Suspend the application that generates the database records
-
Wait for Debezium to stream all unstreamed changes
-
Stop Debezium connector
-
Apply all changes to the source table schema
-
Mark the tables as INACTIVE on the ASN register table and reinit the ASN capture service (see the UDFs)
-
Remove the old structure table from ASN
-
Add the new structure table to ASN
-
Mark the tables as ACTIVE on the ASN register table and reinit the ASN capture service (see the UDFs)
-
Resume the application
-
Start Debezium connector
Hot schema update
The hot schema update does not require any downtime in application and data processing. The procedure itself is also much simpler than in case of cold schema update. First we consider an incremental change to the source, e.g. adding a new column to the end:
-
lock the source table to change
-
Mark the tables as INACTIVE on the ASN register table and reinit the ASN capture service (see the UDFs)34. Apply all changes to the source table schema
-
Apply all changes to the ASN table schema
-
Mark the tables as ACTIVE on the ASN register table and reinit the ASN capture service (see the UDFs)
Now we consider an non-incremental change to the source, e.g. adding a new column in the middle:
-
lock the source table to change
-
Mark the tables as INACTIVE on the ASN register table and reinit the ASN capture service (see the UDFs)
-
export the data of the source table to change
-
truncate the source table
-
alter the source table
-
LOAD the exported data into the altered source table
-
export the data of the ASN table to change
-
truncate the ASN table
-
alter the ASN table
-
LOAD the exported data into the altered ASN table
-
Mark the tables as INACTIVE on the ASN register table and reinit the ASN capture service (see the UDFs)
Data types
A summary of Db2’s data types are described in Data Types.
As described above, the Db2 connector represents the changes to rows with events that are structured like the table in which the row exist. The event contains a field for each column value, and how that value is represented in the event depends on the SQL data type of the column. This section describes this mapping.
The following table describes how the connector maps each of the Db2 data types to a literal type and semantic type within the events' fields.
Here, the literal type describes how the value is literally represented using Kafka Connect schema types, namely INT8
, INT16
, INT32
, INT64
, FLOAT32
, FLOAT64
, BOOLEAN
, STRING
, BYTES
, ARRAY
, MAP
, and STRUCT
.
The semantic type describes how the Kafka Connect schema captures the meaning of the field using the name of the Kafka Connect schema for the field.
| Db2 Data Type | Literal type (schema type) | Semantic type (schema name) | Notes |
|---|---|---|---|
|
|
n/a |
|
|
|
n/a |
|
|
|
n/a |
|
|
|
n/a |
|
|
|
n/a |
|
|
|
n/a |
|
|
|
|
A string representation of a timestamp without timezone information |
|
|
|
|
|
|
|
|
|
|
n/a |
|
|
|
n/a |
|
|
|
n/a |
|
|
|
n/a |
|
|
|
n/a |
|
|
|
|
A string representation of a times without timezone information |
|
|
|
A string representation of a timestamp without timezone information |
|
|
n/a |
|
|
|
n/a |
|
|
|
n/a |
|
|
|
|
Contains the string representation of a XML document |
Other data type mappings are described in the following sections.
If present, a column’s default value will be propagated to the corresponding field’s Kafka Connect schema. Change messages will contain the field’s default value (unless an explicit column value had been given), so there should rarely be the need to obtain the default value from the schema. Passing the default value helps though with satisfying the compatibility rules when using Avro as serialization format together with the Confluent schema registry.
Temporal values
Other than Db2’s DATETIMEOFFSET
data type (which contain time zone information), the other temporal types depend on the value of the time.precision.mode
configuration property. When the time.precision.mode
configuration property is set to adaptive
(the default), then the connector will determine the literal type and semantic type for the temporal types based on the column’s data type definition so that events exactly represent the values in the database:
| Db2 Data Type | Literal type (schema type) | Semantic type (schema name) | Notes |
|---|---|---|---|
|
|
|
Represents the number of days since epoch. |
|
|
|
Represents the number of milliseconds past midnight, and does not include timezone information. |
|
|
|
Represents the number of microseconds past midnight, and does not include timezone information. |
|
|
|
Represents the number of nanoseconds past midnight, and does not include timezone information. |
|
|
|
Represents the number of milliseconds past epoch, and does not include timezone information. |
|
|
|
Represents the number of milliseconds past epoch, and does not include timezone information. |
|
|
|
Represents the number of milliseconds past epoch, and does not include timezone information. |
|
|
|
Represents the number of microseconds past epoch, and does not include timezone information. |
|
|
|
Represents the number of nanoseconds past epoch, and does not include timezone information. |
When the time.precision.mode
configuration property is set to connect
, then the connector will use the predefined Kafka Connect logical types. This may be useful when consumers only know about the built-in Kafka Connect logical types and are unable to handle variable-precision time values. On the other hand, since Db2 supports tenth of microsecond precision, the events generated by a connector with the connect
time precision mode will result in a loss of precision when the database column has a fractional second precision value greater than 3:
| Db2 Data Type | Literal type (schema type) | Semantic type (schema name) | Notes |
|---|---|---|---|
|
|
|
Represents the number of days since epoch. |
|
|
|
Represents the number of milliseconds since midnight, and does not include timezone information. Db2 allows |
|
|
|
Represents the number of milliseconds since epoch, and does not include timezone information. |
|
|
|
Represents the number of milliseconds past epoch, and does not include timezone information. |
|
|
|
Represents the number of milliseconds since epoch, and does not include timezone information. Db2 allows |
Timestamp values
The DATETIME
, SMALLDATETIME
and DATETIME2
types represent a timestamp without time zone information.
Such columns are converted into an equivalent Kafka Connect value based on UTC.
So for instance the DATETIME2
value "2018-06-20 15:13:16.945104" will be represented by a io.debezium.time.MicroTimestamp
with the value "1529507596945104".
Note that the timezone of the JVM running Kafka Connect and Debezium does not affect this conversion.
Decimal values
| Db2 Data Type | Literal type (schema type) | Semantic type (schema name) | Notes |
|---|---|---|---|
|
|
|
The |
|
|
|
The |
|
|
|
The |
|
|
|
The |
Deploying a connector
If you’ve already installed Zookeeper, Kafka, and Kafka Connect, then using Debezium’s Db2` connector is easy.
First download the connector’s plug-in archive,
extract it, and add the contained directory to Kafka Connect’s plugin.path
by using the plugin.path
configuration property.
In addition, due to licensing reasons you need to separately obtain the JDBC driver for Db2. Add the JDBC driver JAR to the directory with the Debezium Db2 connector JARs. Restart your Kafka Connect process to pick up the new connector.
If immutable containers are your thing, then check out Debezium’s Container images for Zookeeper, Kafka and Kafka Connect with the Db2 connector already pre-installed and ready to go. You can even run Debezium on OpenShift.
To use the connector to produce change events for a particular Db2 database or cluster:
-
enable the CDC on Db2 to publish the CDC events in the database
-
create a configuration file for the Db2 Connector and use the Kafka Connect REST API to add that connector to your Kafka Connect cluster.
When the connector starts, it will grab a consistent snapshot of the schemas in your Db2 database and start streaming changes, producing events for every inserted, updated, and deleted row. You can also choose to produce events for a subset of the schemas and tables. Optionally ignore, mask, or truncate columns that are sensitive, too large, or not needed.
Example configuration
Using the Db2 connector is straightforward. Here is an example of the configuration for a connector instance that monitors a Db2 server at port 50000 on <IP_ADDRESS>, which we logically name fullfillment
:
{
"name": "db2-connector", (1)
"config": {
"connector.class": "io.debezium.connector.db2.Db2Connector", (2)
"database.hostname": "<IP_ADDRESS>", (3)
"database.port": "50000", (4)
"database.user": "db2inst1", (5)
"database.password": "Password!", (6)
"database.dbname": "mydatabase", (7)
"database.server.name": "fullfillment", (8)
"table.whitelist": "MYSCHEMA.CUSTOMERS", (9)
"database.history.kafka.bootstrap.servers": "kafka:9092", (10)
"database.history.kafka.topic": "dbhistory.fullfillment" (11)
}
}
| 1 | The name of our connector when we register it with a Kafka Connect service. |
| 2 | The name of this Db2 connector class. |
| 3 | The address of the Db2 instance. |
| 4 | The port number of the Db2 instance. |
| 5 | The name of the Db2 user |
| 6 | The password for the Db2 user |
| 7 | The name of the database to capture changes from |
| 8 | The logical name of the Db2 instance/cluster, which forms a namespace and is used in all the names of the Kafka topics to which the connector writes, the Kafka Connect schema names, and the namespaces of the corresponding Avro schema when the Avro Connector is used. |
| 9 | A list of all tables whose changes Debezium should capture |
| 10 | The list of Kafka brokers that this connector will use to write and recover DDL statements to the database history topic. |
| 11 | The name of the database history topic where the connector will write and recover DDL statements. This topic is for internal use only and should not be used by consumers. |
See the complete list of connector properties that can be specified in these configurations.
This configuration can be sent via POST to a running Kafka Connect service, which will then record the configuration and start up the one connector task that will connect to the Db2 database, read the transaction log, and record events to Kafka topics.
Monitoring
The Debezium Db2 connector has three metric types in addition to the built-in support for JMX metrics that Zookeeper, Kafka, and Kafka Connect have.
-
snapshot metrics; for monitoring the connector when performing snapshots
-
streaming metrics; for monitoring the connector when reading CDC table data
-
schema history metrics; for monitoring the status of the connector’s schema history
Please refer to the monitoring documentation for details of how to expose these metrics via JMX.
Snapshot Metrics
The MBean is debezium.db2:type=connector-metrics,context=snapshot,server=<database.server.name>
.
| Attribute Name | Type | Description |
|---|---|---|
|
|
The last snapshot event that the connector has read. |
|
|
The number of milliseconds since the connector has read and processed the most recent event. |
|
|
The total number of events that this connector has seen since last started or reset. |
|
|
The number of events that have been filtered by whitelist or blacklist filtering rules configured on the connector. |
|
|
The list of tables that are monitored by the connector. |
|
|
The length of the queue used to pass events between the snapshotter and the main Kafka Connect loop. |
|
|
The free capacity of the queue used to pass events between the snapshotter and the main Kafka Connect loop. |
|
|
The total number of tables that are being included in the snapshot. |
|
|
The number of tables that the snapshot has yet to copy. |
|
|
Whether the snapshot was started. |
|
|
Whether the snapshot was aborted. |
|
|
Whether the snapshot completed. |
|
|
The total number of seconds that the snapshot has taken so far, even if not complete. |
|
|
Map containing the number of rows scanned for each table in the snapshot. Tables are incrementally added to the Map during processing. Updates every 10,000 rows scanned and upon completing a table. |
Streaming Metrics
The MBean is debezium.db2:type=connector-metrics,context=streaming,server=<database.server.name>
.
| Attribute Name | Type | Description |
|---|---|---|
|
|
The last streaming event that the connector has read. |
|
|
The number of milliseconds since the connector has read and processed the most recent event. |
|
|
The total number of events that this connector has seen since last started or reset. |
|
|
The number of events that have been filtered by whitelist or blacklist filtering rules configured on the connector. |
|
|
The list of tables that are monitored by the connector. |
|
|
The length of the queue used to pass events between the streamer and the main Kafka Connect loop. |
|
|
The free capacity of the queue used to pass events between the streamer and the main Kafka Connect loop. |
|
|
Flag that denotes whether the connector is currently connected to the database server. |
|
|
The number of milliseconds between the last change event’s timestamp and the connector processing it. The values will incorporate any differences between the clocks on the machines where the database server and the Debezium connector are running. |
|
|
The number of processed transactions that were committed. |
|
|
The coordinates of the last received event. |
|
|
Transaction identifier of the last processed transaction. |
Schema History Metrics
The MBean is debezium.db2:type=connector-metrics,context=schema-history,server=<database.server.name>
.
| Attribute Name | Type | Description |
|---|---|---|
|
|
One of |
|
|
The time in epoch seconds at what recovery has started. |
|
|
The number of changes that were read during recovery phase. |
|
|
The total number of schema changes applie during recovery and runtime. |
|
|
The number of milliseconds that elapsed since the last change was recovered from the history store. |
|
|
The number of milliseconds that elapsed since the last change was applied. |
|
|
The string representation of the last change recovered from the history store. |
|
|
The string representation of the last applied change. |
Connector properties
The following configuration properties are required unless a default value is available.
| Property | Default | Description |
|---|---|---|
Unique name for the connector. Attempting to register again with the same name will fail. (This property is required by all Kafka Connect connectors.) |
||
The name of the Java class for the connector. Always use a value of |
||
|
The maximum number of tasks that should be created for this connector. The Db2 connector always uses a single task and therefore does not use this value, so the default is always acceptable. |
|
IP address or hostname of the Db2 database server. |
||
|
Integer port number of the Db2 database server. |
|
Username to use when connecting to the Db2 database server. |
||
Password to use when connecting to the Db2 database server. |
||
The name of the Db2 database from which to stream the changes |
||
Logical name that identifies and provides a namespace for the particular Db2 database server being monitored. The logical name should be unique across all other connectors, since it is used as a prefix for all Kafka topic names emanating from this connector. Only alphanumeric characters and underscores should be used. |
||
The full name of the Kafka topic where the connector will store the database schema history. |
||
A list of host/port pairs that the connector will use for establishing an initial connection to the Kafka cluster. This connection will be used for retrieving database schema history previously stored by the connector, and for writing each DDL statement read from the source database. This should point to the same Kafka cluster used by the Kafka Connect process. |
||
An optional comma-separated list of regular expressions that match fully-qualified table identifiers for tables to be monitored; any table not included in the whitelist will be excluded from monitoring. Each identifier is of the form schemaName.tableName. By default the connector will monitor every non-system table in each monitored schema. May not be used with |
||
An optional comma-separated list of regular expressions that match fully-qualified table identifiers for tables to be excluded from monitoring; any table not included in the blacklist will be monitored. Each identifier is of the form schemaName.tableName. May not be used with |
||
empty string |
An optional comma-separated list of regular expressions that match the fully-qualified names of columns that should be excluded from change event message values. Fully-qualified names for columns are of the form schemaName.tableName.columnName. Note that primary key columns are always included in the event’s key, also if blacklisted from the value. |
|
|
Time, date, and timestamps can be represented with different kinds of precision, including: |
|
|
Controls whether a tombstone event should be generated after a delete event. |
|
n/a |
An optional comma-separated list of regular expressions that match the fully-qualified names of character-based columns whose values should be truncated in the change event message values if the field values are longer than the specified number of characters. Multiple properties with different lengths can be used in a single configuration, although in each the length must be a positive integer. Fully-qualified names for columns are of the form schemaName.tableName.columnName. |
|
n/a |
An optional comma-separated list of regular expressions that match the fully-qualified names of character-based columns whose values should be replaced in the change event message values with a field value consisting of the specified number of asterisk ( |
|
n/a |
An optional comma-separated list of regular expressions that match the fully-qualified names of columns whose original type and length should be added as a parameter to the corresponding field schemas in the emitted change messages.
The schema parameters |
|
n/a |
An optional comma-separated list of regular expressions that match the database-specific data type name of columns whose original type and length should be added as a parameter to the corresponding field schemas in the emitted change messages.
The schema parameters |
|
empty string |
A semi-colon list of regular expressions that match fully-qualified tables and columns to map a primary key. |
The following advanced configuration properties have good defaults that will work in most situations and therefore rarely need to be specified in the connector’s configuration.
| Property | Default | Description |
|---|---|---|
initial |
A mode for taking an initial snapshot of the structure and optionally data of captured tables. Supported values are initial (will take a snapshot of structure and data of captured tables; useful if topics should be populated with a complete representation of the data from the captured tables) and schema_only (will take a snapshot of the structure of captured tables only; useful if only changes happening from now onwards should be propagated to topics). Once the snapshot is complete, the connector will continue reading change events from the database’s redo logs. |
|
repeatable_read |
Mode to control which transaction isolation level is used and how long the connector locks the monitored tables.
There are four possible values: It is worth documenting that Another aspect is data consistency. Only the |
|
|
Specifies how the connector should react to exceptions during processing of events.
|
|
|
Positive integer value that specifies the number of milliseconds the connector should wait during each iteration for new change events to appear. Defaults to 1000 milliseconds, or 1 second. |
|
|
Positive integer value that specifies the maximum size of the blocking queue into which change events read from the database log are placed before they are written to Kafka. This queue can provide backpressure to the CDC table reader when, for example, writes to Kafka are slower or if Kafka is not available. Events that appear in the queue are not included in the offsets periodically recorded by this connector. Defaults to 8192, and should always be larger than the maximum batch size specified in the |
|
|
Positive integer value that specifies the maximum size of each batch of events that should be processed during each iteration of this connector. Defaults to 2048. |
|
|
Controls how frequently heartbeat messages are sent. |
|
|
Controls the naming of the topic to which heartbeat messages are sent. |
|
An interval in milli-seconds that the connector should wait before taking a snapshot after starting up; |
||
|
Specifies the maximum number of rows that should be read in one go from each table while taking a snapshot. The connector will read the table contents in multiple batches of this size. Defaults to 2000. |
|
|
An integer value that specifies the maximum amount of time (in milliseconds) to wait to obtain table locks when performing a snapshot. If table locks cannot be acquired in this time interval, the snapshot will fail (also see snapshots). |
|
Controls which rows from tables will be included in snapshot. |
||
|
Whether field names will be sanitized to adhere to Avro naming requirements. See Avro naming for more details. |
|
|
When set to See Transaction Metadata for additional details. |
The connector also supports pass-through configuration properties that are used when creating the Kafka producer and consumer. Specifically, all connector configuration properties that begin with the database.history.producer.
prefix are used (without the prefix) when creating the Kafka producer that writes to the database history, and all those that begin with the prefix database.history.consumer.
are used (without the prefix) when creating the Kafka consumer that reads the database history upon connector startup.
For example, the following connector configuration properties can be used to secure connections to the Kafka broker:
In addition to the pass-through to the Kafka producer and consumer, the properties starting with database.
, e.g. database.applicationName=debezium
are passed to the JDBC URL.
database.history.producer.security.protocol=SSL
database.history.producer.ssl.keystore.location=/var/private/ssl/kafka.server.keystore.jks
database.history.producer.ssl.keystore.password=test1234
database.history.producer.ssl.truststore.location=/var/private/ssl/kafka.server.truststore.jks
database.history.producer.ssl.truststore.password=test1234
database.history.producer.ssl.key.password=test1234
database.history.consumer.security.protocol=SSL
database.history.consumer.ssl.keystore.location=/var/private/ssl/kafka.server.keystore.jks
database.history.consumer.ssl.keystore.password=test1234
database.history.consumer.ssl.truststore.location=/var/private/ssl/kafka.server.truststore.jks
database.history.consumer.ssl.truststore.password=test1234
database.history.consumer.ssl.key.password=test1234
Be sure to consult the Kafka documentation for all of the configuration properties for Kafka producers and consumers. (The Db2 connector does use the new consumer.)


{% extends "ems/base.html" %} {% block sidebar_content %}
Event Home
Event Setup
Manage Participants
Judge Event
The following particpants are currently in {{ level.name }} level of {{ event.name }}


Hello
FIND CARD
Search By Type...
Artifact
Autobot
Card
Character
Creature
Dragon
Elemental
Enchantment
Goblin
Hero
Instant
Jaguar
Knights
Land
Phenomenon
Planeswalker
Scheme
Sorcery
Specter
Summon
Tribal
Vanguard
Wolf
You’ll
Search By Color...
Blue
Red
White
Black
Green


Installing Contiv Network with Cisco ACI
This page gives brief instructions for installing Contiv Network with Cisco's Application Centric Infrastructure (ACI).
For more information about ACI, contact Cisco Systems.
Prerequisites
Configure your APIC Fabric and Access Policies as follows:
Create a VLAN Pool under Fabric -> Access Policies -> Pools -> VLAN. Set allocation mode to Static Allocation.
Create a physical domain under Fabric -> Access Policies -> Physical and External Domains -> Physical Domains.
Create an attachable access entity profile (AAEP) and associate it with the physical domain created in Step 2.
Create a Policy Group (under Interface Policies) and specify the AAEP created in Step 3.
Create an Interface Profile and specify the physical interfaces connected from your ToRs to the bare metal servers. You can create separate Interface Profiles for individual ToRs if you like.
Create a Switch Profile (Switch Policies/Profiles) and specify the appropriate interface profile created in Step 5.
Make a note of the full node names of the ToRs you have connected to your servers.
Configure the ACI Gateway Container
To enable the ACI-GW to access and configure ACI to match the Contiv configuration, set these environment variables (see configuring aci under Installation):
APIC_URL
- The URL of the APIC.
APIC_USERNAME
- The login username for the APIC.
APIC_LEAF_NODE
- The full URI path of the ACI leaf nodes where the cluster servers are connected,
for example, topology/pod-1/node-101
. If there are multiple nodes, you can use comma separation,
for example, topology/pod-1/node-101,topology/pod-1/node-102
.
APIC_PHYS_DOMAIN
- The name of the physical domain used for the Contiv cluster (Step 2 above).
Set Up Authentication
Both key-based authentication and password authentication are supported. Key-based authentication is the recommended method.
Password-Based Authentication
For password-based authentication, pass the password to the ACI-GW using the APIC_PASSWORD
environment variable.
Key-Based Authentication
To enable key-based authentication, follow these steps:
Create a Key Create a key and certicate. Add the certificate to APIC using the procedure described here.
Set the APIC_CERT_DN Environment Variable in aci config Find the distinguished name (DN) of the key that was added to APIC and pass it to the ACI-GW via the
APIC_CERT_DN
environment variable. This DN is of the form uni/userext/user-admin/usercert-admin The exact DN can be found from the APIC visore, for example,APIC_CERT_DN=uni/userext/user-admin/usercert-admin
.Create a Key Directory Create a directory on the server that hosts ACI-GW and copy the key created in the previous step to this directory.
Share the key and restart aci_gw container TBD: this step is potentially different in k8s vs swarm environment. Share this directory with the ACI-GW using the bind mounting option of Docker. For example, if the keys are copied to the
/shared/keys
directory on the host, use the-v /shared/keys:/aciconfig
option while starting the ACI-GW container.


{% extends 'profile_base.html' %} {% load static %} {% load commonmark %}$ {% load token_tags %} {% block title %} Your Secret Tokens | {{ block.super }} {% endblock %} {% block profile_content %}
The Secret Token game lasts the whole event and is about finding little text strings matching the regular expression:
[0-9a-zA-Z\.@]{12,32}
Tokens are hidden or in plain sight physically or virtually on the BornHack venue, online and offline.
If you think you found a secret token you can register it by visiting https://bornhack.dk/token/TOKEN/
where TOKEN
is replaced by the token you found.
This page shows an overview of the tokens in this years game, a hint for each token, and how many of them you have found. Here is your first token to start the hunt: "ThankYouForParticipaing"
{{ token.camp.title }} |
|||||||
| Category | Time Limits | Token | Description | Found | |||
|---|---|---|---|---|---|---|---|
| {{ token.category }} |
{% if token.valid_now %}
{% else %}
{% endif %}
{% if token.valid_when.lower %}
Not valid before {{ token.valid_when.lower }} {% endif %} {% if token.valid_when.upper %} Not valid after {{ token.valid_when.upper }} {% endif %} {% if not token.valid_when %} No time limit {% endif %} |
{% with token|found_by_user:user as user_has_found_token %}
{% if user_has_found_token %}
{{ token.token }} | {{ token.description }} | {{ user_has_found_token }} | {% else %}- | - | - | {% endif %} {% endwith %}


Hey I am usama fassy, my interest is to develop application using MEAN stack
Here are about some technologies i'am interseted in
The easiest way to contact me is via twitter: @usama


Khong Jia Wei
Home
Notable Projects
Technical Skills
Hobbies
Technical Skills
Programming Languages
Java
Swift
Python
Mobile App Development
Android (Android Studio & Java)
iOS (XCode & Swift)
Prototyping (Adobe XD)
Web Development
HTML, CSS, Javascript


I am a web and graphic designer from Belfast. I am currently studying Interactive Media at Ulster University
In my spare time, I like to listen to music, play music, anything music. My favourite genre of music would definately be anything in the realms of Progressive Rock/Metal. In 2017, I got the chance to meet the guys from Dream Theater in Cardiff during their Images & Words 25th Anniversary tour. My other favourite artists would include Rush, Animals as Leaders, Steven Wilson, Opeth, Devin Townsend Project, Haken etc. the list goes on. I primarily play the drums and have achieved Grade 6, but I since have moved on to play Guitar and I currently play a Jackson 7 String Guitar. I enjoy writing and recording music in my spare time. I currently use Reaper as my main DAW, I use BIAS AMP and FX for simulating amplifiers and pedals, and a skew of Kontact libaries like GetGood Drums and Native Instruments' Symphony Essentials.


BREAKING: Four houses and two cars damaged in Ratoath fire suspected as deliberate
by John DonohoeRTE is reporting that four houses have been damaged and two vehicles burned out following a fire at Meadowbank Hill in Ratoath.
"Gardaí have said the fire, which started at around 3am this morning, may have been started deliberately," it is reported.
The four houses in the Fairyhouse Road estate were evacuated, with no injuries reported.
At least one of the houses has been extensively damaged and a car and van parked outside were completely destroyed by the blaze.
Several units of the Fire Brigade are still at the scene.


The goal of dfoliatR
is to provide dendrochronologists with tools for identifying and analyzing the signatures of insect defoliators preserved in tree rings. The methods it employs closely follow (or in some cases exactly replicate) OUTBREAK, a FORTRAN program available from the Dendrochronological Program Library.
You can install the released version of dfoliatR from CRAN with:
And the development version from GitHub with:
The package requires users to input two sets of tree-ring data: standardized ring widths of individual host trees and a standardized tree-ring chronology from a local non-host tree species or climate series. dfoliatR
combines these to remove the climate signal represented by the non-host chronology from the host tree series. What’s left should represent a disturbance signal. Then dfoliatR
identifies defoliation events in the host tree series.
We recommend that the input tree-ring data be standardized in either ARSTAN or the dplR
R package. If there is more than one ring-width series from the same tree, these should be standardized and averaged to the tree level. In ARSTAN, make sure to output ‘.TRE’ files and read them into R with the read.compact()
function in dplR
. If you choose to standardize raw ring widths in dplR
with detrend()
, then use the treeMean()
function to generate tree-level series. All data input to dfoliatR
needs to be an rwl
object as defined in dplR
.
Here we briefly explore defoliation and outbreaks patterns for a Douglas-fir site in New Mexico. These data re includedin the package
To start out, we identify defoliation events on individual trees,
## Identify defoliation signals
dmj_defol <- defoliate_trees(host_tree = dmj_h, nonhost_chron = dmj_nh)
## Plot the results
plot_defol(dmj_defol)
And then scale up to outbreaks by compositing across the site via
Analyses of the tree series (termed defol
objects) can be done via:
To identify ecologically-significant outbreak events, use the outbreak()
function. Various filters are available to aid users in defining outbreak thresholds. Analyses of outbreak series (termed obr
objects) can be done via:
For the full range of usage in dfoliatR
, please visit the introduction vignette.


--- layout: post title: 'It''s not about early adopters any more...' date: 2004-12-23 00:00:00 category: mobile ---
MDA Touts GPRS/MMS Figures: "From a total active customer base of over 53 million*, GPRS active devices topped 26 million as of 30th September 2004, an increase of 10% on the previous quarter and double that of last quarter 2003 . This figure represents a 50% penetration rate for GPRS devices for the total UK market. This trend is expected to continue with the MDA predicting by the end of 2005 that 75% of all UK handsets in use will be able to access the internet."
It's not about early adopters any more... oh and it's women who are the big gamers...


You'll find the Column "Modify" in the IP addresses list.
In this colum, on each line, a checkbox is present.
Select records to modify by selecting thoses checkboxes.
On the column header there is a All link which invert the selection you made.
Click afterwards on which complete the Add/Modify section.
See help on adding an IP address for explanations on that section.


--- layout: page title: "About" description: "This is what we do." header-img: "img/team.jpg" ---
We make the world a better place.


Login
Logout
Spitale
(current)
Sectii
Doctori
Contact
RoSpitals © 2018. Toate drepturile rezervate.
Terms and conditions


The 4D Nucleome Data Portal hosts data generated by the 4DN Network and other reference nucleomics data sets. The Portal is currently in pre-release as more data is being curated, and data processing and visualization tools are being incorporated. Click Browse to see currently available data.
The 4DN program aims to understand the principles underlying nuclear organization in space and time, the role nuclear organization plays in gene expression and cellular function, and how changes in nuclear organization affect normal development as well as various diseases. The program is developing novel tools to explore the dynamic nuclear architecture and its role in gene expression programs, models to examine the relationship between nuclear organization and function, and reference maps of nuclear architecture in a variety of cells and tissues as a community resource.


Overrides or extends the standard labels or symbols for a subject.
The subject metadata can assign new labels or symbols to a subject within the scheme. A property within the scheme overrides any equivalent property in the definition of the subject.
author, category, copyright, critdates, othermeta, permissions, publisher, resourceid, shortdesc, source, subjAltLabel, subjAltSymbol, subjHiddenLabel, subjPrefLabel, subjPrefSymbol
( (shortdesc) (optional) then (author) (any number) then (source) (optional) then (publisher) (optional) then (copyright) (any number) then (critdates) (optional) then (permissions) (optional) then (category) (any number) then (subjPrefLabel) (optional) then (subjAltLabel) (any number) then (subjHiddenLabel) (any number) then (subjPrefSymbol) (optional) then (subjAltSymbol) (any number) then (othermeta) (any number) then (resourceid) (any number))


{{ notification.message }}
Where and how to get and use WIC
Who Accepts WIC?
Do I Qualify?
What Is WIC?
Which Foods Qualify?


Be a Smart Consumer
How to become a smart consumer
Buying and consuming high quality products but spending less money is the objective of a smart consumer. As a smart consumer, you buy things you really need and avoid unnecessary items so that you don't waste the resources from earth. Also you Avoid buying souvenirs because these souvenirs came from the animals that harmed the habitat of biodiversity.
What to buy and what not to buy
Buy things that will help biodiversity such as:
- Local foods. Buy local foods since it gives good benefits to us and the environment.
- Organic foods. Foods that are 100% pesticides free.
- Recycled products. This products used unprocessed materials provide environmental benefits that protect our environment
- Long lifetime products. Products that you can use for a long period of time.
- Essential products. Products that you need for your everyday life such as toothbrush, clothes, foods, water and more daily products.
Do not buy these things that threatened biodiversity:
- Wildlife products. These products was came from different species that affects biodiversity
- Animal Souvenirs. Don't buy souvenirs unless it's not made from ivory skin, fur, bone, shell, beak or hooves of an endangered species.
- Pesticides. Pesticides caused the population decline which threatens species. Don't buy it unless you have severe plant damage caused by pests.


Awesome Tour
Home
About
Start Tour
Card with image
Large
Action 1
Action 2
Card with image
Small
Action 1
Action 2


Television shows or better known as TV shows are a series of related productions that are broadcasted over-the-air to serve as attraction for viewership. They have multiple episodes in a single season and the popular TV shows can have multiple seasons. TV shows can vary in the audience that they intend to attract. There are dramas, comedies, thrillers, and reality shows that all serve a purpose in entertaining the World. My favorite TV shows are "It's Always Sunny in Philadelphia," "Friends," and "The Office".
"It's Always Sunny in Philadelphia" is a comedy show about five friends who own a bar and consistently come up with dumb ideas to get themselves into trouble. I have listed my five favorite characters in the show as well as incorporated a video of some of my favorite scenes.
Friends is a comedy sit-com and is consistently known as one of the best comedy shows of all time. This late 90's and early 2000's TV show is relateable and funny as a group of friends living in New York get themeselves in hilarious situations. I can watch any episode of this show and laugh every time. Here is a list of my top 3 favorite Friends' episodes. I also included a video of some of my favorite scenes.
The Office was originally created in England, but America put its own spin on it as main character Michael Scott, played by Steve Carell, manages a paper company named "The Dunder Mifflin Paper Company." This show has over 100 episodes and is considered one of the best comedy shows of all time. Here is a link to some of my favorite scenes. Click here to watch!


Your family tree can take you back generations. It can be difficult deciding where to start. We help by providing you with the tools to access government and private databases. You'll be surprised what you may find.
Preserve and hand down your legacy on a family tree. We’ll help you as you go along.
No need to start from scratch. Upload your tree from elsewhere and receive new discoveries.
Our vital records cover 90% of North America with birth, marriage, and death records.
Build your family tree for free and watch your story emerge. Discover your loved ones and how your family's story was shaped over time. When you've made progress, share your genealogy story with your family.
No credit card needed to get started. Create your profile for free and start searching for relatives.
When you find your family, you discover yourself. Learn where you came from and enrich your life.
Click on a family member's name and see what you can discover about them. You might be surprised.
Gain unlimited access to the world's largest genealogy databases for free. No other service gives you this amazing access to help you complete your family tree in just a few steps.


For most, social media is usually the highlights of our lives. When people go to the beach or go on vacation. Additionally, users post the best pictures of themselves and I've witnessed my friends take over a hundred pictures just to get one to post.
I, personally, have a Snapchat, Instagram, Facebook, and maybe more. I don't really spend too much time going through what others post but when I do I can see that people are making their lives to be like a fairytale. This is bad because other young teens will see it and think negatively upon their life. Social media usage often leads to depression in young teens.
About 70% of people (in the US) use or have social media! Moreover, 97% of people aged 13-18 use social media. These numbers are crazy high and we need to take a step back, unplug, and think about what we are absorbing from social media.


{% extends "bootstrap3/base.html" %} {% block title %}{{_('Page not found')}}{% endblock %} {% block content %}
{{_("The requested page could not be found.")}}


WITNESS LIST Judicial Affairs Committee March 1, 1999-3:00P HB 57 For: Igo, Shanna (Texas Municipal League) Registering, but not testifying: HB 510 For: Guillot, Patrick (Self and Texas Commission on Uniform Laws) Tindall, Harry (Self) HB 524 For: Mitchell, Charles (Self and District Attorney, First Judicial District) On: Krampitz, Tom (Texas District & County Attorneys Association) Registering, but not testifying: HB 1136 For: Streater, Joy (County & District Clerks Association) For: Herman, Judge Guy (Statutory Probate Judges of Texas) Registering, but not testifying: HB 1142 For: Streater, Joy (County & District Clerks Association) HB 1142 Committee Substitute (CSHB 1142) For: Herman, Judge Guy (Statutory Probate Judges of Texas) Registering, but not testifying: HB 1274 For: O'Neal, Michael (Texas Municipal Courts Association) HB 1350 For: Robles, Judge Daniel (Self) HCR 63 For: Whiteaker, Bruce (Self and Texas Association of Broadcasters & KXAN-TV) HJR 28 Against: Specia, Jr., John J. (Self and 225th District Court) Registering, but not testifying:


This is a short helpful error message that should be approximately 66 characters per line.
This is being formatted somewhere inside the component in terms of input field width


For a threephase system, 8 space vectors are available according to the following switching patterns:
Vector 1..6 form a hexagon, vector 0 and 7 are of length 0.
First, the space vector is limited, and the sector of the hexagon is determined where the input space vector u is located; then the angle of the space vector within this sector 0≤φ<60° is calculated.
The input space vector is averaged by u = ta*ua + tb*ub + t0*0, where ua is the space vector at the left border of the sector and ub is the space vector at the right border of the sector. If necessary, a zero length vector is applied additionally.
The relative time spans for averaging over one switching period are determined by the following equations:
To obtain the positive fire signal, the switching time spans are distributed symmetrically: t0/4 + ta/2 + tb/2 +t0/2 + tb/2 + ta/2 + t0/4
The switching pattern of the negative fire signal is just the inverse of the positive fire signal.


species climate distribution change range future RCP {border-style projected (.) data px;} #ffffff;} area models Primula Table alpine warming current habitats plant projections shifts specimens study Cyananthus changes elevation response suitable change. expand expansion upward used high variables China HHM MaxEnt conservation distributional endemic local model northward px; ranges scenario shift species, studies time {font-family Ecol. Himalaya-Hengduan distributions font-size herbarium latitude mean shown (RCP (range: Biol. Chinese Glob. Institute Mountains century double; habitat macrocalyx modeling mountain period scenario, size species. study, value ./j.-...x Current Divers. Evol. Fig. Plant Species Wang areas associated border-color border-width climatic downloaded effects elevation, genus however, increase inflatus limited lobatus niche occupied pessimistic potential provide sikkimensis solid; tangutica {font-style {font-weight Academy Biogeogr. Chang. Distrib. Environmental Fois Global Liang Multimedia Nat. Pearson Phillips Range Sci. Zhang Zhou arc-seconds) average bio, biotic bold component considered courier; distributed diversity dynamics elevations em; example, expected extinction global highest layer mainly optimistic predict previous projection pt;} records region regions relatively rimula scenarios scenarios. secundifolia sizes spatial specimen tree using values westward wild


Everybody Loves Pizza!
Pizza is a delicious food, is easy to make, and wonderful to eat. Although it make not be the most nutritious meal, it is great for any occasion.
Pizza is great for a number of occasions:
- Birtdays
- Parties
- Watching the game with your best buds
- When you're too lazy to go out
- On a study night
- And many more!
Situations will arise when you are not sure which type of pizza to order. Here's a key to help you out!
| Type of Pizza | Situation |
|---|---|
| Cheese | Default / When you don't know what others want |
| Veggy | When you know there's a vegetarian |
| Meat Lovers | When you know there isn't a vegetarian |
| Combo | When everyone is arguing about toppings |
Click here if you love pizza too!


Collaborate. Track. Sell. Manage with ease.
We will CoCreate a website to your specific industry and needs.
Sign Up NowWe will walk you through the process, improve the image of your business. A professional look can bring organic traffic
See more featuresDomain represent your brand. Our sole purpose is to improve your domains visibility on search engines and get visitors.
See more featuresIncludes ivr menu so you can route your customers and provide some marketing of your services.
See more featuresProvide a personal touch to your website. Everything is 100% customizable. We already provided SEO friendly content as inspiration. Search engine's love fresh and unique content. Adding your own personal touch will achieve that goal.
See more featuresWe will guide you through :
We add new milestones so you can continue to improve and grow. Business is a long game and requires patience. You need to nurture it to maturity. It can take months to start receiving organic traffic. But it will feel great when you recieving traffic, Similaly when people walking in to your shop and requesting your service or product.
See more features


[gecode-users] LinExp issue with MSVC 9
Filip Konvička
filip.konvicka at logis.cz
Thu Mar 20 00:09:19 CET 2008
Hi,
when porting my code from Gecode 1.3.1 to 2.1.1 (MSVC 2008 Express
Edition), the following code
GECODE_ES_CHECK((GqBin<int, IntView, MinusView>::post(home, start[i],
iv, d)));
("home" is my Space*, "start[i]" is an IntView, "iv" is a MinusView, and
"d" is an int) worked well with Gecode 1.3.1, but with 2.1.1 I'm getting
C:\lib\gecode-2-vc90\gecode/int/linear.hh(82) : error C4263:
'Gecode::Reflection::ActorSpec
Gecode::Int::Linear::LinBin<Val,A,B,pc>::spec(const Gecode::Space
*,Gecode::Reflection::VarMap &,const Gecode::Support::Symbol &) const' :
member function does not override any base class virtual member function
with
[
Val=int,
A=Gecode::Int::IntView,
B=Gecode::Int::MinusView,
pc=1
]
C:\lib\gecode-2-vc90\gecode/int/linear.hh(307) : see reference
to class template instantiation
'Gecode::Int::Linear::LinBin<Val,A,B,pc>' being compiled
with
[
Val=int,
A=Gecode::Int::IntView,
B=Gecode::Int::MinusView,
pc=1
]
It seems that spec() has more arguments in LinBin than in Actor, so the
compiler chokes. (Note that the function is not explicitly "virtual" in
LinBin.) This is a "Level 4" warning 4263, which I used to have turned
into error using, so I wonder whether this should be fixed in Gecode or
not. The warning says that LinBin::spec() effectively hides
Actor::spec() in LinBin (which might be intentional, of course, but the
compiler probably doubts that).
Thanks,
Filip
More information about the gecode-users
mailing list


There are 11 themes of bricks available:
red green amber orange blue cobalt
cyan purple teal dark yellow
<Brick theme={theme} />
// red, green, amber, orange, blue, cobalt,
// cyan, purple, teal, dark, yellow
<Brick theme='cyan' />
There are 4 sizes of bricks available:
small medium wide large
<Brick size={size} />
// small, medium, wide, large
<Brick size='wide' />
An icon is displayed at the center of the brick.
<Brick icon={icon} />
// specify a string as image source
<Brick icon='your/icon/path.png' />
// use JSX as icon
<Brick icon={} />
Name and Badge are located at the bottom of the brick.
<Brick name={name} badge={badge} />
// badge could be number or string
<Brick name='My App Name' badge={123} />
// or make a JSX badge
<Brick name='My App Name'
badge={} />
Instead of setting a Theme, you can provide an image as background.
Unless it's a small brick, the icon will be placed in the Badge position.
<Brick bkg={bkg} />
<Brick bkg='your/background/path.png' />
You can display custom message and display duration in the brick.
This will not work for small brick.
<Brick msg={msg[]} msgDelay={msgDelay} />
// message accepts:
// 'title', 'body', 'delay', 'theme', 'bkg'
// where 'theme' and 'bkg' can be inherited
<Brick msg={[{
title: 'Title',
body: 'Message Body',
delay: 6000
}, {
title: 'Title 2',
body: 'Message Body 2'
}]} msgDelay={7000} />
Use BrickContainer to arrange bricks easily
// either specify JSON config of array of Bricks
<BrickContainer bricks={bricks} name={name} />
// or directly place Bricks as children
<BrickContainer bricks={bricks} name={name}>
<Brick />
<Brick />
<Brick />
</BrickContainer>
Set custom columns in each row
<BrickContainer size={size} columns={columns} />
// size: small - 4 cols, medium - 6 cols,
// wide - 8 cols, large - 12 cols
<BrickContainer size='medium' />
// or you can set other number
<BrickContainer columns={6} />
Bricks always try to find a gap to fill. Thus, Bricks may position in different order
Use empty brick to fill the gap instead
// create empty bricks mannually
// can alter 'divProps' and apply custom CSS
<BrickContainer bricks={[
{ fill: true },
{ fill: true },
{}
]} />
// or you can use Brick tag directly
<BrickContainer>
<Brick fill />
<Brick fill />
<Brick />
</BrickContainer>
// use 'prepend'/'append' to fill in bulkly
// accepts 'count', 'size'
// 'prepend' - fill before that brick
// 'append' - fill after that brick
// 'prepend'/'append' don't work when using Brick tag directly
<BrickContainer bricks={[
{ prepend: { count: 2 } },
]} />


|
||||||||
| PREV NEXT | FRAMES NO FRAMES |
AdRequest
object contains information about the ad to fetch.AdSize
.
View
that displays the ads.AdView
.
AdView
from an XML layout.
AdView
from an XML layout.
AdView
.
AdSize
.
AdRequest
.
AdSize
.
true
if the ad is successfully loaded and is ready to be
shown.
Ad.isReady()
.
Ad.isReady()
.
true
if the ad is currently automatically refreshing.
true
if this device will have test ads returned or
false
if real ads are returned.
AdRequest
.
Ad.loadAd(AdRequest)
.
AdRequest
.
Activity
that will leave the application (e.g.
Activity
is created in front of the
app (e.g.
AdListener
for this Ad
.
Ad.setAdListener(AdListener)
.
AdListener
for this InterstitialAd
.
Ad.stopLoading()
.
Object.toString()
.
Object.toString()
.
AdSize
as a String
.
|
||||||||
| PREV NEXT | FRAMES NO FRAMES |


redraw graph
highlight line
unhighlight
hide
unhide
delete plane
redraw graph
highlight line
unhighlight
hide
unhide
delete plane


Q. 43. With whom did God the Father make the covenant of grace?
A. With Christ, his eternal Son.
Q. 44. Whom did Christ represent in the covenant of grace?
A. His elect people.
Q. 45. What did Christ undertake in the covenant of grace?
A. To keep the whole law for his people, and to suffer the punishment due to their sins.


Pizza that will please
One of Kenya’s most celebrated pizzerias, PIZZA PLEASE combines the elegance of a Bolognese enoteca with the fun bustle of an Italian train station. Open daily from 10AM to midnight, PIZZA PLEASE is perfect for a quick snack, a lingering meal, a family night out, or a large social gathering.


SILVER
DURATION : 3 MONTHS
CONTACT : 30 PROFILES
PRICE : RS 1499
Client Should Be Contact Directly
GOLD
DURATION : 4 MONTHS
CONTACT : 50 PROFILES
PRICE : RS 2499
Client Should Be Contact Directly
PLATINUM
DURATION : 5 MONTHS
CONTACT : 70 PROFILES
PRICE : RS 3499
Client Should Be Contact Directly
DIAMOND
DURATION : 6 MONTHS
CONTACT : 90 PROFILES
PRICE : RS 4999
Service Will be Provided Our Executive
Feedback will be updated for every 10 days
PREMIUM SERVICE
DURATION : 12 MONTHS
CONTACT : 120 PROFILES
PRICE : RS 9999
Our Management Will Take Responsibility in Dealing With Both Sides
Feedback will be updated weekly once
VIP & FAST TRACK
DURATION : 12 MONTHS
CONTACT : 120 PROFILES
PRICE : RS 19999
Our Management Will Take Responsibility
Feedback will be updated weekly twice
Family and property information will be monitered throughly
PROFILE HIGHLIGHTER
DURATION : 1 MONTH
PRICE : RS 500
Highlighting profile in search Results for one month..Get More visibility at your profile
GROOM OF THE DAY / BRIDE OF THE DAY
DURATION : 1 DAY
PRICE : RS 100
Highlighting profile for one day..Get More visibility at your profile
STARTER
DURATION : 45 DAYS
CONTACT : 15 PROFILES
PRICE : RS 799
Client Should Be Contact Directly


Web Designer
Engineer
Volunteer
Web Designer
Engineer
Volunteer
My Projects
Work Experience
Volunteer Experience


{% extends 'base.html' %} {% block title %}
Note : to upload data to Course and Lesson models use $ python manage.py loaddata fixtures/learning.json --app learning


--- layout: help title: Meld - Help ---
When comparing several files, you may have sections of text where differences aren't really important. For example, you may want to focus on changed sections of code, and ignore any changes in comment lines. With text filters you can tell Meld to ignore text that matches a pattern (i.e., a regular expression) when showing differences between files.
Text filters don't just affect file comparisons, but also folder comparisons. Check the file filtering notes for more details.
You can turn text filters on or off from the the Text Filters tab in Preferences dialog. Meld comes with a few simple filters that you might find useful, but you can add your own as well.
In Meld, text filters are regular expressions that are matched against the text of files you're comparing. Any text that is matched is ignored during the comparison; you'll still see this text in the comparison view, but it won't be taken into account when finding differences. Text filters are applied in order, so it's possible for the first filter to remove text that now makes the second filter match, and so on.
If you're not familiar with regular expressions, you might want to check out the Python Regular Expression HOWTO.
It's easy to get text filtering wrong, and Meld's support for filtering isn't complete. In particular, a text filter can't change the number of lines in a file. For example, if we had the built-in Script comment filter enabled, and compared the following files:
|
comment1.txt
a b#comment c d |
comment2.txt
a b c #comment |
then the lines starting with b would be shown as identical (the comment is stripped out) but the d line would be shown as different to the comment line on the right. This happens because the #comment is removed from the right-hand side, but the line itself can not be removed; Meld will show the d line as being different to what it sees as a blank line on the other side.
The Ignore changes which insert or delete blank lines preference in the Text Filters tab requires special explanation. If this special filter is enabled, then any change consisting only of blank lines is completely ignored. This may occur because there was an actual whitespace change in the text, but it may also arise if your active text filters have removed all of the other content from a change, leaving only blank lines.
You can use this option to get around some of the problems and limitations resulting from filters not being able to remove whole lines, but it can also be useful in and of itself.


Olin College of Engineering & Citizens of the World believe we need to radically transform the culture of STEM to welcome folks of all backgrounds. We're starting in Cambridge, MA. There's no city better positioned to prototype a new, mission-drvien public institution.


Sync your database with multiple remote hosts.
Synchronizing {{ remoteSyncService.getLastHostSynchronizing() }} ...
Abort
When syncing, a list of changes will be listed below.


Teretana Pobednik
Home
Services
Appointments
My Account
About us
Yoga
Learn more
Cardio
Learn more
Pilates
Learn more
Core
Learn more
Gym
Learn more
Previous
Next


sealed class Deposit : GrapheneObject
Echo sidechain base deposit model
Author
Dmitriy Bushuev
BtcDeposit |
Describes single btc deposit model class BtcDeposit : Deposit |
EthDeposit |
Describes single ethereum deposit model class EthDeposit : Deposit |
TransactionInfo |
Describes transaction info in btc deposit class TransactionInfo |
TransactionOut |
Describes transaction out in btc deposit class TransactionOut |
Undefined |
Currently undefined deposit type class Undefined : Deposit |
account |
val account: String |
approves |
val approves: List<String> |
isApproved |
val isApproved: Boolean |


I'm an occasional user of various opiates: codeine, morphine, darvocet, fentanyl, buprenorphine, poppies etc. I try my best not to take them too often, but it is difficult to do if they're available. My prefered route of administration is oral, but I will give IM injections if the product is pharmaceutically pure.
The basic reasons I use opiates recreationally are:
1. The warm, happy feelings they produce -- like an internal hug.
2. The little problems & worries that cause anxiety tend to go
away (albeit for a short while).
3.
Back when I was in medical school, circa 1995, I was doing my family practice rotation and noticed boxes of this 'new' medicine that we were told to give to patients who complained of aches & pains. It was Ultram, and the free samples came in little blister packs of two, tiny 50mg, capsule-shaped tablets. In the back room of the clinic there were drawers & bins filled with these free samples. At first I assumed it was a new type of NSAID, or ibuprofen-like drug. The first time I took some Ultram for a headache, I noticed something odd, this drug was tickling my opiate receptors. The euphoria wasn't nearly as strong as that caused by codeine, but closer to darvocet.
Regardless, it was a positive experience and I had access to literally thousands of the blister packets--for free! I would never deprive a patient of pain meds, that would be horribly unethical. But there was enough Ultram to go around.  Whatever samples I did not handout, came home with me.
The nice thing about Ultram (tramadol) is that I never needed to increase the dosage, tolerance did not seem to develop. Two, 50mg caplets in the morning carried me through (floated me through) the day, well into the evening. It did not make me drowsy either. I agree with others that it does lighten one's mood, and probably has value as an anti-depressant. As I mentioned earlier, not feeling the little aches & pains of middle age helps me to feel younger and more energetic.
I am a recreational user of opiates. I know what an opiate feels like when its binding and activating my mu-opiate receptors. There is NO DOUBT in my mind that Ultram (tramadol) is an opiate. I am glad that after thirteen years on the market it still is not scheduled, BUT, by all rights, it should be CIII.
I enjoy Ultram. I do take advantage of its availability. Becoming addicted to it happens fairly often enough, and the withdrawals from Ultram have been reported to be worse than coming off of heroin. I rarely take more than 150mg (3 pills) every 6-8 hours. I tell my patients that its okay to enjoy this medication, but I do set limits that I myself follow.
Perhaps in 100 years, people will look back on the folly of the 'non-opiate' (wink-wink) Ultram, much the same as we look back on heroin's introduction & use as a 'non-addictive, morphine substitute'.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


{% extends "layouts/public.html" %} {% block content %}
Weatherglass is an open-source Google Analytics alternative that is easy to self-host.