Review: The Hercules Monitor 5 Entry Level Studio Speakers
The Monitor 5 is one of the better entry level monitors on the market, with a nice balance of lows, mids and highs for music production and even a little DJing.
by David IrelandHercules is mostly known for its DJ controllers, software, and, more recently, their multimedia monitors. The brand offers quality entry-level solutions for those that want to get into DJing but don't have deep pockets or are unsure of how serious they are about it.
The Monitor 5 is the first product targeted at the home studio monitor market, and competes alongside other entry-level monitors like the KRK Rockit RP5 and comes in around the same price ($300 for the pair).
The speakers themselves are identical with the same front panel power switches and volume, along with bass and treble controls on the back to help dial in the room. You get three types of inputs, including RCA, balanced quarter-inch, and XLR inputs. The ability to turn these speakers on and off from the front, along with volume control, is fantastic. It sounds simple, but when you are in a tight space having access to these functions on the front is extremely handy.
The Monitor 5, as you would guess, comes equipped with a 5" woofer, a 1" tweeter and two front-facing ports to pump the air through. One thing we noticed right away was the heft and size of these monitors; they are 15 lbs and stand 12" high, 8.7" wide and 9.2" deep, so they might crowd your desk if you are in a tight configuration. You might want to consider getting some speaker stands with some isolation to help dial in the sweet spot. The speakers come with foot pads to mount on the bottom if you are going to set them on your desk.
Aesthetically the look clean with wood cabinets and plastic fronts with a yellow woofer, very reminiscent of the KRK's offering at this level.
The monitors are powered with an A/B bi-amplified system with the woofer getting 50 watts and the tweeter getting 30 watts. This power is enough to bump a small room and function as either DJ or Studio monitors adequately. You should not expect any heart-stopping bass here; these are for small spaces not powering your backyard rave.
How do they sound?
We tested these with our two-deck turntable set up with Pioneer PLX-1000s and the Omnitronic TRM-202MK3 2-Channel Rotary Mixer, along with running a line in from our AkJr HD Media player.
What you will notice with electronic dance music and hip hop is that the bass is a bit subdued and lacks that fullness we like as DJs. So if you are looking at these as DJ monitors, you might consider something else that gets a bit more bottom heavy.
Where the Monitor 5's shine for this price point is the mids and highs, you get a nice balance in genres like neoclassical, ambient, jazz, and even some more complex house music. So if you are more into production than DJing, these are a great way to start off your studio on a budget.
If you plan on DJing and using them for production, then these are a good bet for that type of versatility.
Should I get these?
If you are starting out and want to get a solid pair of monitors to handle a variety of genres and workloads, the Monitor 5's will suit you well.  If you are doing music production, these are definitely the way to go at this price point and will also suffice for DJing as well. These are kind of like an all-terrain snowboard, competent in the powder, groomers, and ok in the pipe. If you need deep bass, and want to only DJ with them, you won't be super happy with these.
More Here Hercules Monitor 5 MSRP $299
Monitor 5 features
- 5 inch woofers.
- Balanced dual bass ports.
- Speaker enclosures crafted of high-density MDF.
- 80 watts RMS output power per speaker.
- RCA, TRS (6.35 mm) and XLR inputs.
- Compact design, perfect for any space.
- On/Off switch on front of each speaker for easy access.
- Master volume knob on front of each speaker for more precise control.
- Indicator light in ON position.
- High-frequency adjustment: + or – 2 dB.
- Low-frequency adjustment: + or – 2 dB.
- Adjustable low-frequency cutoff: 56 Hz, 80 Hz or 100 Hz.


Introduction
EPICS version 3 and its predecessors have been enormously successful as a
framework for distributed device control, but have not been optimal for all
purposes. Firstly, the underlying network protocol has not been documented and
standardized, and so is not suitable for independent implementation or
extension. Secondly, the network codec and message passing system has not supported
passing semi-structured data, nor arguments, and so has not been suitable for use as
a transport for modern needs of experimental physics detectors or host level
scientific applications.
The EPICS V4 Working Group was chartered last year to define and publish an open
control protocol for control system endpoints, which functionally extended channel
access to suitability for both device control and high level services. It included
data types suitable for high level services, such as tables and complete image data
such as from gated photon detectors.
In the past year, EPICS V4 successfully brought a
communications protocol for controls, "pvAccess", to advanced public review status,
and a software framework suitable for high performance distributed control, message
passing, and high level software services, to beta release status.
Mission
This year the Mission of the EPICS V4 working group is to integrate with the
broader EPICS toolkit. Further, it is to extend EPICS into the application level of
scientific instrument controls and optimization, and into the high performance
computing data pipeline of backend data processing. It is intended that high
performance scientific applications, particualrly those that use or processes
instrument data, should be made easier to develop and to effectively deploy.
Basis for Work
The EPICS V4 working group is supported by Brookhaven Lab (BNL), Paul Scherrer
Institute (PSI) and Diamond Light Source, and collaborating organizations, subject
to their following mission, goals, and expected deliverables, of this Charter, and
following the EPICS V4 Process as the work method. Conformance to this Charter is
required for participation in the working group.
Basic Scope and Goals
Presently, in an EPICS installation it is expected that control and module support
would be done with EPICS V3 IOCs, while middle layer and "Service Oriented
Architecture" based operations would be done with EPICS V4. V4 includes some support
for protocol interoperability with V3. In short, EPICS V4 builds on EPICS V3.
This year the initial goal of the EPICS V4 Working group is expected to bring
fully integrate EPICS V3 and V4 technologies, for seamless interoperation.
Scope for this year's charter is specifically extended to the IOC level, where we
will complete integration with vxWorks and interoperation with the classic EPICS
IOC.
We intend to improve the EPICS IOC's suitability and performance as
a scientific instrument data processing pipeline, specifically for fast detector
image data, and to greatly improve facilities for
clients to deal with these data.
Wheres last year, Java, C or C++, reference bindings must have been supplied for
all implementations of each normative
standard document; this year (only) the reference bindings of the client side of
EPICS V4 tools must be supplied in both C++ and Java. IOC work may be C++ only.
Note that, as last year, our primary focus is on definition of standard behavior
as normative documents of the Working Group, informed by the development of
software which implements the behavior. As last year, we shall supply
reference implementations for these standards. It is to be expected that in some
respects, reference implementations may trail the standard.
Goals
The goals of the Working Group are the following
- Begin development of the EPICS IOC, as a high performance
instrument data processing pipeline suitable for detector data processing and
communications.
- Development of a pvAccess server for the IOC which
enables IOC channel data to be collectively requested and returned as coherent data
package to clients. For instance, so a client can make one request for the
pertinent data of a beam position monitor (BPM), and get all and only the x, y,
current, and status at that BPM.
- Further development of pvAccess, concentrating on high
performance and communication mechanisms other than TCP/IP (multicast
in particular).
- Further development of pvData, concentrating on high
performance, particularly by zero-copy and block data transfer enhancements.
pvData is the open, documented, data type encoder/decoder
capable of exchanging both atomic and semi-structured data,
suitable as the data exchange format for high end diagnostics and services.
- Interoperability with EPICS v3. The pvAccess message protocol
must be interoperable with EPICS IOCs, and add the Channel Access provider to
pvAccess client side. See Interoperability
with EPICS v3 below
- Development of data aggregation services; completion of the
EPICS V4 core services Directory Service and extend the Gather service for connection time domain rebasing (a server side pvManager). These are
to enable scientific application programs to deal simply with many channels and
channels whose update rates are different to their client consumption
rates.
- High Performance. The above protocols and
controller framework must be of high
performance. See Performance goals
below
- Much easier for developers to get started. The above protocols
and framework must be transparent, documented, and delivered so that it is very
easy for a developer to create EPICS V4 IOC applications and services and interop
pretty easily with "V3". Note that we do not yet intend to support easy adoption
by EPICS users such as database writers and screen developers
- Implementability. The above protocols, and the
processing of message I/O, must be documented in such as way that
outside software developers can easily create an interoperable
implementation
- Error handling. All normative software implementations must handle
and log all errors in such a way that distributed users can see both the causes
and outcomes of all system errors (scientific and control issues, as well as
detected program exceptions). In practice, this may mean the creation and
adoption of a single error messaging standard, perhaps an EPICS V4 service whose
job it is to receive and log errors from all other endpoints.
It is anticipated that one further goal, which may be stated as
production of a software framework for scientific services, may be undertaken
either as part of the EPICS V4 working group, or by an associated working group
operating within the same EPICS V4 Process as
the EPICS V4 Working Group.
Interoperability with EPICS V3
EPICS V4 clients must be interoperable with EPICS v3 IOCs. This interoperability
must be both interlayer (IOC ⇔ client) and intralayer (V3 IOC ⇔ "V4
IOC"). PvAccess must run in version 3 IOCs and serve all v3 type structures. dbLinks
will be adapted to interoperate with pvaccess accessible data.
Add ability to get or set V3 channels (pvaSrv) synchronously (so long as
they are all in the same lockset) as a result of 1 V4 channel operation.
This mechanism must satisfy the expected use case of device control including
EPICS V4 in the medium term; in which device control will continue to be through
EPICS v3, with control wire protocols and client sides in EPICS V4. It is expected
that in the longer term, past the duration of this charter, the EPICS V4 IOC will be
properly extended into device control.
Interoperability within EPICS V4
Each normative standard must be demonstrated to be interoperable with adjacent
layers in the EPICS v4 protocol stack by production of, and testing, at least one
implementation, in each of C++ and Java, from device to client (end to end).
Specific requirements for Pipelining
- loss-less, high performance transport of detector and camera images
See others from David
Performance Goals
The following minimum performance goals are unchanged
from last years charter. This year we intend to concentrate on certifying their
achievement particularly for streams over network connections:
- put / get: 100% of Channel Access in equivalent scenario
- monitors: 100% of Channel Access in an equivalent scenario
- multicast: when available, 100% of Channel Access, but more scalable
- streams: 90% of the raw TCP socket throughput, and 80% of the capacity of the media. For
example, over 10GBit Ethernet, then a little less than 8GBits of data transfer on a
dedicated VLAN. This should be optimized for sending images and
multidimensional arrays, and by implication should minimize
copying.
Out of Scope
The following are out of scope for the group specifically:
- The production of the new Input/Output Controller (IOC) framework, suitable
for both controls and services, known as "pvIOC", will not be pursued as a
software deliverable this year. Rather, requirements and design references for
such a new IOC will
be pursued, with a view to development next year
- Both and only Java and C/C++ bindings are required for reference
implementations of the core protocols (pvAccess and pvData). One or the other
language binding is required for service implementations
- The Windows server side is out of scope for now. A Windows client side may be
developed. Windows server side may be added in a charter revision subject to
resources and specifically funded requirement (lookin at you PSI).
- Development of specific production quality services are out of scope. A few
reference services may be produced, but they are only for illustration and offered
as a basis for extensions.
This statement of Out-of-Scope has been changed to last year's to omit the ban on
development of a specific application; this year we will concentrate on the specific
application of high performance image pipelining.
Success Criteria
Derived from the goals above, success criteria are at least:
- Adoption or planned adoption of EPICS V4 in the EPICS
community
- Demonstrated interoperability of EPICS V4 clients and EPICS V4
services
- Demonstrated interoperability with EPICS v3
- Demonstrated high performance
- Demonstrated easy to implement an EPICS V4 service, taking
arguments, and returning semi-structured data
- Demonstrated easy to implement an EPICS V4 client, taking data
from EPICS v3 records, packaged by an EPICS V4 service (pvaSrv)
- Demonstrated easy for an end user to get a list of all PVs and named entities in
an EPICS network, through an EPICS client, given a name pattern
- What else?
Deliverables and Duration
The outputs of the working group will be delivered as a system of
documented standards, plus reference implementation source code where
relevant. These documents and source codes will all be available from
the EPICS V4 web
site, http://epics-pvdata.sourceforge.net/.
Deliverables
The group is expected to produce the following normative deliverables WG to agree:
- Performance measurement and micro-benchmark test framework
for pvAccess, including documentation, made publicly available. This must run on
both host level and embedded computers. This should be used to measure, and
optimize performance per the performance goal
- An image processing pipeline outline design framework,
particularly oriented towards encapsulating the semantics of asynRecord and
asynDriver. At the end of the year this must also be documented as implemented.
- Create proven vxWorks cross-compile ports of pvAccess, pvData
and associated code sets (pvCommon, [where is pvaSrv?]). Track and publish the proven
host compilation, cross-compilation, and runtime experience of at least the most
recent public release tar, and the tips of the source code repos (when those are
thought to be consistent and should work)
- Support for Channel Access client in pvAccessCPP (it already exists
in pvAccessJava), together with a suitable mechanism for dealing with name collision
- Further develop the IOC module that acts as the V3 Ca to
pvAccess clients. This module is now called pvaSrv, to include at least the
following:
- pvAccess client get or put or monitor, a single ca channel
- pvAccess client get or put or monitor, a single pva channel which corresponds to a set of ca channels where the members of the set is defined at runtime prior to the get call
- pvAccess client get or put or monitor, a single pva channel which corresponds
to a set of ca channels where the members of the set has been defined by a prior
configuration
Precise semantics in the case of locksets, status and alarms, particularly in the
case of the I/O operations involving more than on ca channel, must be defined and
clearly started in documentation
- Completion of the easy to use pvAccess API, now called easyPVA, for both Java and C++ bindings. Publish matlab examples
- Completion to at least 2PWD of the normative document of the EPICS V4
interoperable data types. These data types must be universally
understood by every client and service which claims EPICS V4
compatibility. The requirement for this deliverable is distinct from
the pvData document deliverable, since pvData can encode any type,
this deliverable recommends the confined set of data objects that will
be used by EPICS V4 interoperable services. In particular this document must
clarify the definition of types with respect to images and areaDetector - decide
on whether we use a general image metatype, an area detector type, or both
- A directory service accessible through the EPICS V4 API itself,
from which can be found at least both CA and PVA channel and entity names, and associated service names
- Completion of support an use of NTURI
- A report of interoperability of the EPICS V4 IOC with EPICS V3
record processing
- Write and publish to EPICS community, a performance report,
comparing EPICS v3 to EPICS V4 for some common EPICS v3 control and read
tasks. Comparisons to other common high performance data interconnects
should be made, eg ICE, ASN.1, EXI Web Service, though are to specific deliverables
- Extend the "Getting Started" document to how one would
start programming the use of EPICS V4
- synoptic displays:
pvManager. Complete support for all of stably defined normative types in pvManager.
Begin normative type support in caQtDm.
- pvIOCCPP. Develop a discussion document for the requirements and
design of the V4 IOC. Don't attempt an actual non-alpha release! Instead take time
to define requirements for the pv processing,
pvCopy, support, and the local pvAccess server.
Duration
The expiration date of this charter is 1-Oct-2013.
Expected Milestones
To be added.
Coordination with Other Bodies
The Working Group should coordinate and align objectives to satisfy
the requirements of the following bodies:
- BNL NSLS Controls
- [TBD:]
- PSI SwissFEL
- PSI requires EPICS V4 services framework, for online accelerator
modelling in particular, and interoperability of the EPICS V4 based
services with EPICS v3 IOCs and their associated record support.
- SLAC FEL accelerators (LCLS/LCLS-II)
- SLAC requires EPICS V4 services framework
in general, and for online accelerator modelling in
particular.
- Control System Studio (CSS)
- Periodically joint meetings of the EPICS V4 WG and CSS developers.
- "Database" group
- Periodically joint meetings of the EPICS V4 WG and BNL database applications group
[needs work - who are those guys, what are they called?], [need to say why]
- Scientific Applications Working Group, if formed
- It may be that in this year a working group for accelerator physics services
and applications will be formed. If it is, it is expected that the EPICS V4 WG will
work closely with that group.
Group Participation
Effective participation is expected to consume one to two working
days per week for each group participant (see below); two days per week for
editors of a specific normative document. Developers of
implementations of a normative standard (such as pvAccess, pvData,
services) are expected to consume three days per week. The Chair shall
ensure that the criteria for Good Standing are understood and
followed:
- Participant Status
-
Prospective group participants should ask their primary EPICS contact
or manager to send an email to one of the EPICS V4 chairs, showing
that they understand the participant will be involved with EPICS V4
and the commitment level expected
- Observer Status
- Individuals
who are not active at the full participation level, may join meetings
of the group as observers. Email the chairs to get details of how to
join the meetings.
The group is expected to have at least 4 active participants to be successful.
Good Standing
A participant who is absent from more than 3 meetings consecutively,
or in the opinion of the chairs is not acting on Action Items or their
responsibilities for group deliverables,
will be deemed out of good standing, and will no longer
participate.
Chair
The initial chairs of this Group are Greg White (PSI, SLAC) and Bob Dalesio (BNL).
Meetings
The Group will have distributed meetings, one to two hours every
week, and face–to–face meetings, every three or four months.
Communication
The Working Group will utilize the mailing
list<EMAIL_ADDRESS>All
except the most trivial messages should be cc'ed to this mailing
list. The web
archive of it used should be used as backward references in
communications.
Confidentiality
The proceedings of this Working Group are open to all (not just
members of the working group), subject to exceptions made by the
Chairs, after consultation with the Working Group. The group's
communications on
the web
archive will be world readable. Posting
to<EMAIL_ADDRESS>will be unrestricted for members, but moderated for non-members.
Patent Policy
This Working Group operates
under EPICS Open
License.
Glossary
- Host Level
- Host Level describes the category of computer systems including
daemons, services,
user level GUIs and other front-end programs, in the computer archiecture of a large distributed computer
system, such as an accelerator control system. Host level is in distinction to field
level. In the client-server paradigm, host level programs are largely clients of field level systems.
- Field Level
- Field Level describes the category of computer systems including
front-end-controllers and network enabled diagnostic equipement in the computer archiecture of a large distributed computer
system, such as an accelerator control system. In EPICS the field level corresponds to IOCs and instrument
hardware. These systems are "in the field". In the client-server paradigm, field
level systems are largely servers of host level systems.
- V4 IOC
- A "classic" IOC that is connected to pvaccess, such as one that includes
pvaSrv. Note that a V4 IOC in this definition is very different from what may
formerly have been
understood as a V4 IOC, being an instance of an IOC running pvIOC. It is
envisaged that an IOC running pvIOC may be called something else now that V4 is
beign targetted to the classic EPICS IOC runtime.
Greg White, EPICS V4 group co-chair
Bob Dalesio, BNL Controls Group leader, and EPICS V4 co-chair
Last modified $ Date: 2011/09/15 17:21:49 $


Simon Cowell still rocking the open shirt look after 20lb weight loss
Simon Cowell has even more reason to rock the open shirt look these days after his recent weight loss, and he couldn’t look any happier.
The TV mogul was spotted leaving ITV’s studios on Saturday night after the latest X Factor: Celebrity live show, and he seemed to be in good spirits despite losing Glee star Kevin McHale in the sing-off with Vinnie Jones.
As he headed to his waiting car, Simon flashed the widest smile while rocking an even bigger gap in his white shirt, which was unbuttoned halfway down his chest flashing a lot of chest hair.
Still rocking his navy blue suit worn earlier during the show, Simon gave photographers two thumbs up and even blew a kiss to his adoring fans.
Wowza, maybe he should rock an open shirt more often.
Earlier this year, Simon was forced to rubbish claims that his 20lbs weight loss was the result of a gastric bypass.
Advertisement Advertisement
Speaking to Best magazine, Si-Co said: ‘People have said: “Oh, he’s had a gastric band fitted” – but I haven’t. If I had, I would admit to it. This diet is all about what you put into your body.
 I could see the difference. Cutting out sugar made a massive difference. The first few weeks were difficult, but then I actually stopped craving sugar.’
He revealed: ‘I had also found a brilliant gluten-free beer, which helps. The hardest part is when I see Eric eat pizza in front of me. That’s really tough.’
Last night’s X Factor had been a tough one for Simon after Vinnie pleaded with him to save Kevin and send himself home in the sing-off.
‘Simon…I feel that I’ve had a fantastic time, I’ve really enjoyed it – it’s been everything I’ve needed since my wife’s passing. This guy is a real singer, I think he can win it, for his career, I would like to step down and let him go through,’ Vinnie said.
Advertisement Advertisement
But Simon decided: ‘The last person in the world I would like to have a fall out with is Vinnie Jones, which means we’re going to have to fall out because I’m going to insist that you stay in the competition.
‘This is not disrespect to Kevin, I am voting with my heart…I think you have a chance of winning this competition still.’
Got a showbiz story?
If you've got a story, video or pictures get in touch with the Metro.co.uk Entertainment team by emailing us<EMAIL_ADDRESS>calling 020 3615 2145 or by visiting our Submit Stuff page - we'd love to hear from you.


base plugin class
you have to implement the process() method, it will receive the parameters that are in the template code
This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.
Located in /Dwoo/Plugin.php (line 20)
| Class | Description |
|---|---|
| Dwoo_Block_Plugin | base class for block plugins |
| Dwoo_Plugin_counter | Initiates a counter that is incremented every time you call it |
| Dwoo_Plugin_cycle | Cycles between several values and returns one of them on each call |
| Dwoo_Plugin_dump | Dumps values of the given variable, or the entire data if nothing provided |
| Dwoo_Plugin_extends | Extends another template, read more about template inheritance at http://wiki.dwoo.org/index.php/TemplateInheritance |
utility function that converts an array of compiled parameters (or rest array) to a string of xml/html tag attributes
this is to be used in preProcessing or postProcessing functions, example : $p = $compiler->getCompiledParams($params); // get only the rest array as attributes $attributes = Dwoo_Plugin::paramsToAttributes($p['*']); // get all the parameters as attributes (if there is a rest array, it will be included) $attributes = Dwoo_Plugin::paramsToAttributes($p);
Documentation generated on Sun, 07 Feb 2010 17:53:53 +0000 by phpDocumentor 1.4.0


Blockchain's Potential
An informative page for Blockchain Technology.
For this project we were assigned to create a simple About page, about either ourselves, or something we enjoy. I decided to do my
simple webpage on Blockchain Technology. On the page I have various links to articles and papers explaining blockchain Technology, as well
as current cryptocurrency prices, and Blockchain Technology news.
- Date: January 2017
- Category: HTML/ CSS


×
The lecture has been created successfully. It can be watched
here
.
Create new lecture
×
New lecture
Video Link
Title
Slug
Start at (e.g. 2:40)
Stop at (e.g. 4:22)
Description
Lecturer
Select Lecturer
Category
Select Category


class: center, frontpage .frontcontent-outer[ .frontcontent-inner[ # Reusing Web-enabled Actuators from a Semantic Space-based Perspective ##
Aitor Gómez Goiri
, Iñigo Goiri, Diego López-de-Ipiña .date[July 2, 2014] ] ] ??? Hello to everyone. My name is... I come from the univ... to present the paper I made together with Iñigo and Diego entitled... --- # Outline 1 - Introduction 2 - Baseline actuation techniques 3 - Comparison 4 - Hybrid actuation 5 - Conclusions --- class: center, middle # Introduction --- # Background .subtitle[ ## Introduction ]
??? So let's start from the beginning. At the beginning, there were few computers in the Internet. Maybe too beginning. --- # Background .subtitle[ ## Introduction ]
??? Then, the __popularity__ of the Internet increased and connecting computers became __easier and cheaper__. Consequently, __more and more__ computers got connected. --- # Background .subtitle[ ## Introduction ]
??? Thanks to __wireless__ technologies, devices started accessing to the Internet without having to be physically connected to a network. --- # Background .subtitle[ ## Introduction ]
??? So the __mobile computing__ appeared. --- # Background .subtitle[ ## Introduction ]
??? Nowadays, __not only__ a wider range of smartphones, but also everyday objects like cars or washing machines connect to the Internet to exchange information. This is what __is know as__ the Internet of Things (IoT). Both IoT and the mobile computing have contributed to the __Ubicomp__ idea. --- # Heterogeneity challenge .subtitle[ ## Introduction ]
??? So, as we saw in the previous slide, nowadays, we have __heterogeneous__ devices running on top of heterogeneous applications. This means that the __interoperability__ is a key property for these environments. --- # Interoperability .subtitle[ ## Introduction > Heterogeneity ] The [IEEE](http://ieeexplore.ieee.org/servlet/opac?punumber=2238) defines __interoperability__ as > The ability of two or more systems or components to __exchange__ information > and to __use__ the information that has been exchanged. ??? The [AI] triple [I] defines... --- # Interoperability .subtitle[ ## Introduction > Heterogeneity ] The [IEEE](http://ieeexplore.ieee.org/servlet/opac?punumber=2238) defines __interoperability__ as > .weak[The ability of two or more systems or components to _exchange_ information > and to __use__ the information that has been exchanged.] ??? So, let's first talk about the second problem: how to use (or reuse) information. --- # Interoperability: use info .subtitle[ ## Introduction > Heterogeneity ]
??? We can identify two levels to allow this __use__: 1. The __syntactic__ level, which cares about the format of the data (i.e. its syntax and encoding) * For instance, if the robot does not undestand chinese characters, the information the mobile phone provides will be useless. 1. The __semantic__ level gives a precise meaning to the information... * _"understandable by any other application that was not initially developed for this purpose"_ * Following the example, this character may mean different things depending on the context. --- # Interoperability: use info (solution) .subtitle[ ## Introduction > Heterogeneity ]
??? To achieve both levels, we propose to use __Semantic Web__ standards and tools. The vision of the Semantic Web is to __extend__ principles of the __Web from documents to data__. It __relates terms__to one another, so they can be shared and reused across applications. This terms can be __processed automatically__ revealing __new relationships__ among the data. > .weak[The __vision__ of the Semantic Web is to extend principles of the Web from documents to data. > Data should be accessed using the general Web architecture using, e.g., URI-s; > data should be __related to one another__ just as documents (or portions of documents) are already. > This also means creation of a common framework that allows data > to be __shared and reused__ across application, enterprise, and community boundaries, > to be __processed automatically__ by tools as well as manually, > including revealing possible __new relationships__ among pieces of data.] --- # Interoperability: exchange info .subtitle[ ## Introduction > Heterogeneity ] The [IEEE](http://ieeexplore.ieee.org/servlet/opac?punumber=2238) defines _interoperability_ as > .weak[The ability of two or more systems or components to __exchange__ information > and to _use_ the information that has been exchanged.] ??? The other aspect which affects the interoperability is __how to exchange information__. Rather than focusing on __low-level__ communication protocols, this paper analyses __more general__ communication strategies. --- # Exchange info 1: the Web .subtitle[ ## Introduction > Heterogeneity ]
??? The first way is the web. The web is massively accepted * By humans * But also, by machines: a lot of applications expose their capabilities using HTTP APIs __REST__ architectural style comprises the design principles of _the modern web_ --- # Exchange info 1: the Web .subtitle[ ## Introduction > Heterogeneity ]
??? It achieves the following properties (see Fielding's thesis) * Scalability * Simplicity * Portability * etc. Note that most of these properties are particularly useful for limited devices. --- # Exchange info 1: the Web .subtitle[ ## Introduction > Heterogeneity ]
??? As a consequence, the web has been widely applied to IoT, bringing what people has called the __Web of Things__ (WoT). In the WoT, everyday things expose their capabilities through web standards. This way, they are first-class web citizens and can seamlessly work with other web apps. --- # Exchange info 2: Tuple Spaces .subtitle[ ## Introduction > Heterogeneity ]
??? A second way to exchange info is space-based computing (or Tuple Spaces). Tuple Spaces is a paradigm where nodes coordinate with each other by writing and reading structured pieces of information (i.e., tuples) in a shared space. --- # Exchange info 2: Tuple Spaces .subtitle[ ## Introduction > Heterogeneity ]
??? This paradigm can be uncoupled in space and in time. * _Space uncoupling_ is achieved because the nodes __don't need to know each other beforehand to communicate__. * _Time uncoupling_ is achieved because two nodes communicating with each other __do not need to coexist at the same time__. --- class: center, middle # Baseline actuation techniques ## How to make a change in the environment? ### (2/5) --- # Patterns for Tuple Spaces .subtitle[ ## Baseline actuation techniques ]
??? To solve this question I first examined the common Tuple Spaces' usage patterns. For sake of brevity, I will present just two of them. --- # Patterns for Tuple Spaces .subtitle[ ## Baseline actuation techniques ]
??? The first one is the __replicated-worker pattern__. In this pattern, there is a master process and many worker processes able to compute the same task. --- # Patterns for Tuple Spaces .subtitle[ ## Baseline actuation techniques ]
??? First, the master takes a problem, divides it into smaller tasks, and --- # Patterns for Tuple Spaces .subtitle[ ## Baseline actuation techniques ]
??? writes these tasks into the space. --- # Patterns for Tuple Spaces .subtitle[ ## Baseline actuation techniques ]
??? Then, any available worker takes a task, --- # Patterns for Tuple Spaces .subtitle[ ## Baseline actuation techniques ]
??? processes it, --- # Patterns for Tuple Spaces .subtitle[ ## Baseline actuation techniques ]
??? and writes the result back into the space. --- # Patterns for Tuple Spaces .subtitle[ ## Baseline actuation techniques ]
??? As the workers write their results, the master takes these results from the space. --- # Patterns for Tuple Spaces .subtitle[ ## Baseline actuation techniques ]
??? When the master has collected all the results, it combines them into a meaningful merged solution. This pattern is scalable and naturally balances the load on the space. --- # Patterns for Tuple Spaces .subtitle[ ## Baseline actuation techniques ]
??? The second pattern in the __specialist pattern__. It can be seen as a variation of the previous one. The difference is that in this pattern each __worker is specialized__ and knows how to make a particular task. --- # Patterns for Tuple Spaces in UbiComp .subtitle[ ## Baseline actuation techniques ]
??? We can __translate__ the previous patterns to our domain. --- # Patterns for Tuple Spaces in UbiComp .subtitle[ ## Baseline actuation techniques ]
??? For instance, a smartphone may write the "__turn the fan on__" __task__ into the space. --- # Patterns for Tuple Spaces in UbiComp .subtitle[ ## Baseline actuation techniques ]
??? A smart-fan which belongs to the same space, will then take the task, --- # Patterns for Tuple Spaces in UbiComp .subtitle[ ## Baseline actuation techniques ]
??? process it and as a result __activate the blades__. Then, it may __write a result__ in the space that the "activator node" will read. For example, with information about when it was turned on. .weak[This approach has been widely applied in the literature. In the past, this idea evolved into service-oriented engines. The task-types where described through services and task through _service invocations_.] --- # HTTP API .subtitle[ ## Baseline actuation techniques ]
```http POST /blades HTTP/1.1 Host: smartfan.eu true ``` ??? However, the more I read about __WoT__, the more I liked its simplicity. For example, for the fan, we could simply make a HTTP POST request to the smart-fan. Unfortunately, like most of the resource-oriented API, this per-se would __not__ be __REST-compliant__. --- # REST/Hypermedia-driven HTTP API .subtitle[ ## Baseline actuation techniques ]
??? To make the API hypermedia-driven, the application has to describe * the current state and * the transitions to the next ones. This way, the client can __select__ the __next state__ of the application through __hypermedia__. --- # REST/Hypermedia-driven HTTP API .subtitle[ ## Baseline actuation techniques ]
??? When the __client is a human__, it's easy for him to interpret the HTML content and decide __which link__ to follow or which __button__ to press. --- # REST/Hypermedia-driven HTTP API .subtitle[ ## Baseline actuation techniques ]
??? However, doing this automatically (__without human intervention__) is currently a __hot research topic__. Some solutions propose to use the __semantic__ web to __describe__ these __applications and__ state __transitions__. In this paper, we used a solution called __RESTdesc__. --- # RESTdesc .subtitle[ ## Baseline actuation techniques ]
??? RESTdesc describes HTTP methods using __rules expressed in the Notation 3__ language (or N3). In the figure, we can see a description for a HTTP __GET__ method. It explains __how to obtain a light measure__. --- # RESTdesc .subtitle[ ## Baseline actuation techniques ]
??? A rule’s __premise__ expresses the __requirements__ to make an state __transition__. --- # RESTdesc .subtitle[ ## Baseline actuation techniques ]
??? A rule’s __conclusion__ expresses both * the HTTP call that needs to be made and... --- # RESTdesc .subtitle[ ## Baseline actuation techniques ]
??? ...the description of what we can __expect as a result__ of the request. --- # RESTdesc .subtitle[ ## Baseline actuation techniques ] ```http OPTIONS /deustotech/lights HTTP/1.1 Host: deusto.eu ``` ```http HTTP/1.0 200 OK Date: Sat, 14 Jun 2014 21:22:01 GMT Content-type: text/n3; charset=UTF-8 Content-Length: 512 { actuators:light ssn:madeObservation ?light_obs . } => { _:request http:methodName "GET" ; http:requestURI ?light_obs ; http:resp [ http:body ?light_obs ]. ?light_obs a ssn:Observation ; ssn:observedProperty sweet:Light ; ... ``` ??? These descriptions can be obtained through different mechanisms. We will assume that they are provided in the same resources which it describes. To this end, we can use the __HTTP OPTIONS verb__. --- # RESTdesc .subtitle[ ## Baseline actuation techniques ]
??? So, when a client has __crawled an API__ collecting several of these descriptions, __what can we do__ with them? IF we also have... --- # RESTdesc .subtitle[ ## Baseline actuation techniques ]
??? ... background knowledge expressed with semantics, and... --- # RESTdesc .subtitle[ ## Baseline actuation techniques ]
??? __a goal__, which is an __special rule__ which expresses the __ending state__ we want to reach; --- # RESTdesc .subtitle[ ## Baseline actuation techniques ]
??? THEN we can use a reasoner to make an __execution plan__. Personally, I have used the __EYE reasoner__. --- # RESTdesc .subtitle[ ## Baseline actuation techniques ]
??? This plan indicates different paths to __reach the desired goal__ (or final state). Let's assume that there is only one path (or no path). This path will contain different steps composed by the rules which need to be invoked to obtain a plan. And since these rules are composed by the HTTP requests, we just have to check if we can invoke them. --- # Motivation .subtitle[ ## Baseline actuation techniques ]
??? In short, machines can learn __how to use__ an API __autonomously__ using RESTdesc. That is, RESTdesc becomes APIs hypermedia-driven. The main advantage of an hypermedia-driven __API__ is that it __can change its shape over the time__ and the applications automatically consuming it will not need to be reconfigured or redeveloped. Translating it to the WoT field, it will allow to act __using actuators not known__ at the design or implementation phases. --- class: center, middle # Comparison ### (3/5) --- # General properties and requirements .subtitle[ ## Comparison ]
Actuation
Communication style
Benefits
Required features
Space-based
Indirect
Decoupling
Subscriptions
REST-based
Direct
Reuse
Rule-based reasoning
??? The two actuation techniques presented are quite distinct in nature. --- # General properties and requirements .subtitle[ ## Comparison ]
Actuation
Communication style
Benefits
Required features
Space-based
Indirect
Decoupling
Subscriptions
REST-based
Direct
Reuse
Rule-based reasoning
??? One promotes the direct communication style, while the other promotes an indirect uncoupled style. .weak[ * Decoupled communication * Reuse of third-party WoT apps ] --- # General properties and requirements .subtitle[ ## Comparison ]
Actuation
Communication style
Benefits
Required features
Space-based
Indirect
Decoupling
Subscriptions
REST-based
Direct
Reuse
Rule-based reasoning
??? We can also see in the table how each of them require additional features: * A subscription mechanism in the case of space-based computing. This mechanism helps nodes __to be aware__ of what is written into the space without constantly polling it. * A reasoner to create a execution plan, --- # Driving scenario .subtitle[ ## Comparison ]
??? To __deepen__ in the comparison, I planned a baseline scenario and __implemented it using both__ mechanisms. The scenario is the "helloworld" of the scenarios: turning on and off a light. However, it __helps to understand__ both actuation mechanisms and test the interoperation ideas. --- # Networking activity .subtitle[ ## Comparison ]
??? After implementing both scenarios, I calculated how the variation in the number of providers (e.g., actuators) could affect these techniques. First, we can see that as the amount of actuators increases, both techniques generate more requests. The __slope__ will __vary depending on the design__ (and implementation) of each solution. In any case, the figure shows that __none__ of the techniques behave in a __scalable__ manner. In the case of space-based actuation, the variation corresponds to the subscription request of each actuator and two additional writings it does. In the case of REST-based actuation the crawler needs to obtain 5 different rules for each actuator. --- # Experimental environment .subtitle[ ## Comparison ]
Platform
Raspberry Pi (model B)
RAM Memory
512 MB
CPU
700 MHz Low Power ARM1176JZ-F Applications Processor
??? To check how much computing resources each techniques requires, I tested them in a Raspberry Pi. Again, the scenario was tested __with 1 to a thousand actuators__. --- # Computing activity .subtitle[ ## Comparison ]
??? In the chart, we see that the amount of actuators affects more severely to __REST__-based actuation. This is due to the to the __reasoning process__ which takes place in the node which generates the plan. In __space__-based actuation, most of the time is spent __checking subscriptions__ at each write. Note that even if the subscription mechanism was unoptimized due to its __prototyping nature__, it made space-based actuation scale much better. --- # Summary .subtitle[ ## Comparison ]
Actuation
Perspective
Activity
Networking
Computation
Space-based
Provider
Proactive, limited
Limited
Consumer
Proactive, limited
Limited
Space
Reactive, high
Varies
REST-based
Provider
Reactive, limited
Limited
Consumer
Proactive, high
Demanding
??? Considering these results and after analysing the characteristics of both techniques, we came out to the following table. It summarizes the strengths and weaknesses of both techniques. --- # Summary .subtitle[ ## Comparison ]
Actuation
Perspective
Activity
Networking
Computation
Space-based
Provider
Proactive, limited
Limited
Consumer
Proactive,
limited
Limited
Space
Reactive, high
Varies
REST-based
Provider
Reactive,limited
Limited
Consumer
Proactive,
high
Demanding
??? From the consumer point of view, the previous charts have already shown its __higher activity__ compared to space-based actuation. --- # Summary .subtitle[ ## Comparison ]
Actuation
Perspective
Activity
Networking
Computation
Space-based
Provider
Proactive, limited
Limited
Consumer
Proactive, limited
Limited
Space
Reactive, high
Varies
REST
-based
Provider
Reactive,
limited
Limited
Consumer
Proactive, high
Demanding
??? The table shows how the __providers in the second__ actuation mechanism are more __lightweight__. That is, they just attend to the request received using HTTP. Probably as a consequence of these few requirements, exposing the actuation capabilities of the limited devices with HTTP is a __consolidated trend__. .weak[This tendency is backed by the WoT initiative.] REST-desc only requires devices to additionally provide their API's resources' descriptions. This can be done before deploying them and does not affect to their usual operation. --- class: center, middle # Hybrid actuation ## Could we seamlessly reuse web actuators from space-based perspective? ### (4/5) ??? So, seeing_these properties, the question I wanted to explore in this paper was: * could __space-based computing take advantage__ of these existing __REST-based actuators__? Reuse lightweight providers and consumers. Furthermore, could this reuse be made in a __seamless way for nodes already following each of these techniques__? --- # Interoperation .subtitle[ ## Hybrid actuation ]
??? With these considerations in mind, I propose a solution which __completely reuses__ the nodes implemented for the previous actuation techniques. In the left hand side, we see a master node from Space-based actuation which writes the "turn light on" task. --- # Interoperation .subtitle[ ## Hybrid actuation ]
??? In the right hand side, we see a smart-bulb light which exposes their actuation capabilities through an HTTP API. --- # Interoperation .subtitle[ ## Hybrid actuation ]
??? This API is __described__ using RESTdesc. In this paper, I propose __not to alter__ the existing nodes. Therefore, the space needs to be extended to make their interoperability possible. --- # Proposed solution .subtitle[ ## Hybrid actuation ]
??? And... how is it extended? The __space__ will be responsible of: * Translating a _subscription to a task result_ into a reasoning goal. Considering the how I implemented the subscriptions .weak[(based on SPARQL using RDFLib)], this is a straightforward __syntactic translation__ .weak[(from SPARQL to N3QL for EYE)]. --- # Proposed solution .subtitle[ ## Hybrid actuation ]
??? Apart from this, it will be in charge of two tasks performed by the client in REST-based actuation: * __crawl__ APIs to obtain RESTdesc rules and --- # Proposed solution .subtitle[ ## Hybrid actuation ]
??? * __create__ a plan. Note one beneficial aspect: as the process resides in the same machine as the space, it can __locally read__ all the content written into the space. This content is provided as additional knowledge to the reasoning process. This way, we __avoid__ additional costly __networking__ operations (both in bandwidth and in time) to obtain this knowledge. --- # Discussion .subtitle[ ## Hybrid actuation ] 1. Obtaining background knowledge 1. Triggering REST actuation 1. From a _subscription to result_ to goal * More general from task to result. ??? --- class: center, middle # Conclusions --- # Conclusions and Future Work Seamless reuse in simple scenario *
[github.com/gomezgoiri /reusingWebActuatorsFromSemanticSpace](https://github.com/gomezgoiri/reusingWebActuatorsFromSemanticSpace)
Further investigation with more complex scenarios is needed * Is the __translation__ between the subscriptions and the goal always possible? * If the plan has __2 or more paths__ to achieve a goal, which one should we chose? * What if __two different actuators__ from space-based and rest-based actuation can be activated? ??? We presented a solution to... However, the hybrid-actuation technique presented needs further investigation to __ensure its universality__. For example, * Would the translation between the subscriptions and the goal always be possible? .weak[What if the node initiating the change does not subscribe to any result?] * If there are two or more paths to reach a goal, how can we discern which one to follow? .weak[This problem is specific to the REST actuation using REST-desc.] * How does the middleware deal with the coexistence of both mechanisms? When both methods can be applied, which one is triggered? .weak[Which one prevails over the other?] In any case, I analysed actuation in space-based computing from a novel-point of view. From the space-based consumer perspective, I proposed to seamlessly reuse actuators from the WoT. Additionally, what about reusing space-based actuation capabilities from the web? --- class: middle, questionslide # Questions? Aitor Gómez Goiri .breakline[ aitor.gomez (at) [deusto (dot) es](http://www.deusto.es)] ??? With this I conclude my presentation and I am ready to answer the questions and comments you make regarding this dissertation. Thank you very much for listening. --- class: center, middle All rights of images are reserved by the
__original owners__*, the rest of the content is licensed
under a __[Creative Commons by-sa 3.0](http://creativecommons.org/licenses/by-sa/3.0/)__ license.
![Creative commons by-sa 3.0 license logo](img/CC-logo.svg)
\* [leogg](http://openclipart.org/detail/89209/), [rduris](http://openclipart.org/detail/167948/), [williamtheaker](http://openclipart.org/detail/178310/) and [cibo00](http://openclipart.org/detail/14056/). --- class: center, middle # Backup slides --- # Space uncoupling .subtitle[ ## Tuple Spaces ]
??? __Space uncoupling__ is achieved because the nodes don't need to know each other beforehand to communicate. That is, TS' primitives do not care about addresses and references, they just care about the content which is being shared. When the computer writes the circle does not know which one node use this piece of info. --- # Space uncoupling .subtitle[ ## Tuple Spaces ]
??? Similarly, if the umbrella reads a circle, it does not know which one generated this concrete blue circle. --- # Time uncoupling .subtitle[ ## Tuple Spaces ]
??? __Time uncoupling__ is achieved because two nodes communicating with each other do not need to coexist at the same time. For instance, after writing the pentagon... --- # Time uncoupling .subtitle[ ## Tuple Spaces ]
??? ...the laptop might left the space. For instance, because it run out of battery of it phisically left the room. --- # Time uncoupling .subtitle[ ## Tuple Spaces ]
??? Then, an umbrella might join the space. --- # Time uncoupling .subtitle[ ## Tuple Spaces ]
??? If it ask for a pentagon, it will get the one written by the laptop even if it is not present. Thanks to these uncoupling levels, TS faces dynamism successfully both in the short and in the long term. --- # "Short" or "limited" are relative adjectives .subtitle[ ## Motivation ]
??? The player in the center is Nate Robinson who, compared to any of the remaining NBA players will be considered small. However, he is about 4 cm taller than me, so I wouldn't consider him small. The same thing happens when we speak about _limited devices_. In the context of my dissertation, _limited devices_ are mobile or embedded devices able to manage semantic annotations. --- # The Semantic Web and limited devices * semantic reasoners for this type of environments (mencionar al tio que hizo un razonador adaptado) * lightweight semantic formats * lightweight web protocols * mobile and embedded devices' the processing capability * [autonomy of the batteries](http://energi.us/liberacion-patentes-tesla/) or * energy harvesting * large etc. ??? Some of our attempts with several platforms (e.g., Arduino) where unsuccessful. However, with current advances in: [leer] More and more devices will be able to manage semantics.


| crashrpt | |
| A crash reporting system for Windows applications |
These steps should be performed for exactly the same software build that you plan to release. If you rebuild the project after files are copied, you must copy the files again.
When a crash report comes in, you use the release build, source code and symbols you copied, along with the minidump included in the crash report, to debug the crash.
Before release is made, it is recommended that you check if exceptions are properly intercepted (use the crEmulateCrash() function), that error reports are properly received by your support team and that you can properly read received error reports.
The CrashRpt.dll and CrashSender.exe are core CrashRpt modules. dbghelp.dll (Microsoft Debug Help Library) is a dependent module.
Since v.1.1.3 it is also required that you copy a language INI file crashrpt_lang.ini to the folder where CrashSender.exe is located.
You can distribute several INI files with your software. On install, rename an appropriate file to crashrpt_lang.ini and copy it to the folder where your CrashSender.exe is located.
I do not like that I should distribute all these DLLs. Can I compile them all as static libs?
No, this is impossible. You may ignore distribution of dbghelp.dll, but a end user's operating system may not have dbghelp.dll installed. In addition, architecture of CrashRpt requires two modules: CrashRpt.dll and CrashSender.exe. So, you have to distribute all these binaries.
I use a packer for my EXE or DLL (e.g. PECompact, UPX and so on). How does this affect the way I read the generated minidump file?
Feel free to use a compression utility for reducing the size of your executable or DLL, but be careful of the following.
In order to read the minidump, you need to save a local copy of the uncompressed EXE (DLL) file and a PDB file generated for that EXE (DLL). You also need to have the source code that you used when building the EXE (DLL). These should be enough to read the minidump generated by the compressed version of your EXE.
I sign my EXE with a digital certificate (Authenticode). How does this affect the way I read the generated minidump file?
Feel free to use an Authenticode utility for signing your executable, but be careful of the following.
In order to read the minidump, you need to save a local copy of the unsigned EXE file and a PDB file generated for that EXE. You also need to have the source code that you used when building the EXE. These should be enough to read the minidump generated by the signed version of your EXE.
I need to edit a resource embedded into my compiled EXE (DLL) binary (e.g. I need to upgrade its version). How this affects the way I read the generated minidump file?
Feel free to edit resources in your compiled binaries, but be careful of the following.
In order to read the minidump, you need to save a local copy of the original (unmodified) EXE (DLL) file and a PDB file generated for that EXE (DLL). You also need to have the source code that you used when building the EXE (DLL). These should be enough to read the minidump generated by the resource-modified version of your EXE (DLL).
I use IncrediBuild for compiling my project. Does crashrpt work with PDB files generated such way?
Yes, CrashRpt works with PDB files generated with help of IncrediBuild.
IncrediBuild is a platform for accelerating Visual C++ builds through by distributing the build processes over local area network.


Detect-obfuscation
I tried to detect obfuscated powershell scripts with@danielhbohannon's Invoke-Obfuscation tools. I used markov model again. I created this dataset from Powershell corpus.
Please test with obfuscated and normal scripts and comment.
Demo
I used these domains as dataset without tlds in demo. Results may vary according to the table above.
Project repo is here


| Type | View: Single / Double |
SE | LE |
|---|---|---|---|
|
(Other) |
Uploaded 05-26 2008, Size 187.78 MiB, ULed by daradib | 0 | 0 |
|
(Handheld) |
Uploaded 06-06 2008, Size 82.17 MiB, ULed by ozz314 | 0 | 1 |
|
(HD - Movies) |
Uploaded 06-06 2008, Size 451.06 MiB, ULed by saintdev | 0 | 1 |
|
(Other) |
Uploaded 06-08 2008, Size 123.3 MiB, ULed by saintdev | 0 | 1 |
|
(Music) |
Uploaded 07-14 2008, Size 17.65 MiB, ULed by freewareprirate | 0 | 0 |
|
(Movies) |
Uploaded 12-22 2008, Size 149.45 MiB, ULed by circlensess | 0 | 0 |
|
(Movie clips) |
Uploaded 12-29 2008, Size 149.45 MiB, ULed by dkhueyjr | 0 | 0 |
|
(HD - Movies) |
Uploaded 02-04 2009, Size 369.54 MiB, ULed by cgaurav007 | 0 | 1 |
|
(Movie clips) |
Uploaded 01-28 2010, Size 175.06 MiB, ULed by .BONE. | 0 | 1 |
|
(Movie clips) |
Uploaded 01-29 2010, Size 34.67 MiB, ULed by twentyforty | 0 | 0 |
|
(HD - Movies) |
Uploaded 03-09 2010, Size 885.68 MiB, ULed by SeederZ | 0 | 1 |
|
(Movies) |
Uploaded 03-11 2010, Size 7.51 GiB, ULed by Anonymous | 0 | 0 |
|
(Movies DVDR) |
Uploaded 03-11 2010, Size 7.73 GiB, ULed by DcyMatrix | 0 | 0 |
|
(Other) |
Uploaded 03-31 2010, Size 159.1 MiB, ULed by xor666 | 0 | 0 |
|
(Other) |
Uploaded 05-11 2010, Size 885.65 MiB, ULed by Anonymous | 0 | 1 |
|
(HD - Movies) |
Uploaded 05-21 2010, Size 866.82 MiB, ULed by Gallaecio | 0 | 0 |
|
(HD - Movies) |
Uploaded 07-04 2010, Size 888.95 MiB, ULed by asamson23 | 0 | 0 |
|
(Other) |
Uploaded 07-17 2010, Size 541.09 MiB, ULed by Anonymous | 0 | 0 |
|
(HD - Movies) |
Uploaded 10-21 2010, Size 507.41 MiB, ULed by zabuza89 | 0 | 1 |
|
(HD - Movies) |
Uploaded 11-22 2010, Size 209.37 MiB, ULed by Nishant88 | 0 | 1 |
|
(HD - Movies) |
Uploaded 03-07 2011, Size 74.73 MiB, ULed by MitZep | 0 | 1 |
|
(Other) |
Uploaded 09-28 2013, Size 2.06 MiB, ULed by tempacc5 | 0 | 0 |


Documentation / Query / Background / Query Beans
Overview
Ebean provides a mechanism for building type safe queries by generating query beans
.
The design/approach taken for the query beans
and type safe query construction is orientated
for maximum readability and to achieve that with Java (which does not have properties support) has meant
that we need to use AOP to enhance the query beans
. The AOP enhancement can be done via:
IntelliJ IDEA Plugin
- Ideal for use during developmentjavaagent
- 'Ok' during development, Good for production deploymentmaven plugin
- Good for production deployment
Recommendation
The recommendation is that during development the IntelliJ IDEA Plugin
is used as that is
just very easy to use relative to specifying a javaagent
when running tests etc.
For deployment/production you can use the javaagent
or maven plugin
.
Benefits
Model changes
When entity bean model changes the query beans are regenerated. If there are queries that are broken by a model change then this results in a compile error (rather than a runtime error) and so breaking model changes are detected easily and early.
Typed bind values
Using query beans means that the bind values used for any given property must be compatible with the properties type. For example, you can bind a String value for a property that has type Timestamp.
Speed of development
Using query beans means we can use IDE auto completion to help write our queries. There is no need to check the model when we build our queries. This makes development a little bit faster, safer and fun!!
Long term maintenance
When applications get bigger and older using strongly type query beans makes maintenance easier as it helps guide new developers who are less familiar with the model and model changes across large applications are much less risky due to compile type checking relative to string based queries.
Examples
Example
List<Customer> customers =
new QCustomer()
.id.greaterThan(12)
.name.startsWith("Rob")
.findList();
Example: nested or() and and()
The following example contains an or()
containing a nested and()
.
List<Customer> customers
= new QCustomer()
.billingAddress.city.equalTo("Auckland")
.version.between(1,100)
.billingAddress.country.equalTo(nz)
.registered.before(new Date())
.or()
.id.greaterThan(1)
.and()
.name.icontains("Jim")
.inactive.isTrue()
.endAnd()
.endOr()
.orderBy()
.name.asc()
.id.desc()
.findList();
Example: filterMany
filterMany provides the ability to filter the returned objects of an associated OneToMany or ManyToMany relationship.
For example, lets say Customers have a lot of orders and for a specific use case we want to find customers and only want their recent new orders. We want to fetch the orders (a OneToMany) for the customers but want to filter those orders to only contain 'recent new orders'
Date oneWeekAgo = ...
// Use QOrder to create an expression list ...
// .. use this expression list to then filter orders
ExpressionList<Order> recentNewOrders = new QOrder()
.orderDate.after(oneWeekAgo)
.status.eq(Order.Status.NEW)
.getExpressionList();
List<Customer> customers = new QCustomer()
.name.ilike("Rob")
// filter the orders (not customers)
.orders.filterMany(recentNewOrders)
.findList();
Example: select() and fetch()
Use the alias()
method to get a shared instance of the query bean
that can be used to specify properties for select()
and fetch()
.
Note that the 'alias' instance of the query bean returned by the alias()
method
does not have an underlying query associated with it and can only be used to provide properties
to select()
and fetch()
.
// special 'alias' instances of query beans
// used to supply properties to the select() and fetch()
QCustomer cus = QCustomer.alias();
QContact con = QContact.alias();
List<Customer> customers = new QCustomer()
// query tuning
.select(cus.name, cus.inactive)
.contacts.fetch(con.email, con.firstName)
// predicates
.name.ilike("Rob")
.findList();
// special 'alias' instances of query beans
// used to supply properties to the select() and fetch()
QContact con = QContact.alias();
QCustomer cus = QCustomer.alias();
QProduct pro = QProduct.alias();
Customer customer =
Customer.find.where()
// manual query tuning
.select(cus.name, cus.registered)
.orders.fetchAll()
.orders.details.product.fetch(pro.name)
.contacts.fetch(con.firstName)
// predicates
.id.eq(12)
.findOne();
APT / KAPT (generating query beans)
To generate Java
query beans we use the io.ebean:querybean-generator
java annotation processor and to generate Kotlin
query beans we use
io.ebean:kotlin-querybean-generator.
Generating with Maven
Refer to docs / getting-started / maven for details of how to generate query beans using maven.
Generating with Gradle
Refer to docs / getting-started / gradle for details of how to generate query beans using gradle.
Enhancement
Note that prior to version 12.1.8 we need to edit a src/main/resources/ebean.mf
manifest file to specify querybean-packages
for the packages that should
be enhanced for query beans. This is no longer needed from 12.1.8 onwards.
Manual generation
There is a mechanism to generate query beans via running code (not via javac annotation processing). This is manual in the sense that whenever there is a change to the entity beans we then need to re-run this process (where as with the java annotation processor it is automatically updated with each compile).
<dependency>
<groupId>io.ebean.tools</groupId>
<artifactId>finder-generator</artifactId>
<version>12.1.1</version>
</dependency>
To generate the query beans
add code similar to below to your src/test
.
The Generator reads compiled .class
entity beans using the ASM
library.
It then uses this meta data to generate java source for the query beans
.
Using this approach rather than using javac
annotation processing means there is
no requirement for javac - you can use any JVM language to write/compile your
entity beans (so maybe Scala
and SBT.
The requirement of this approach is that entity beans are compiled as .class files and that
GeneratorConfig
is configured to know where the classes are, where the source
code should go and the package containing the entity beans.
package main;
import org.avaje.ebean.typequery.generator.Generator;
import org.avaje.ebean.typequery.generator.GeneratorConfig;
import java.io.IOException;
/**
* Generate type query beans for each entity bean.
*/
public class MainQueryBeanGenerator {
public static void main(String[] args) throws IOException {
GeneratorConfig config = new GeneratorConfig();
//config.setClassesDirectory("./target/classes");
//config.setDestDirectory("./src/main/java");
//config.setDestResourceDirectory("./src/main/resources");
config.setEntityBeanPackage("org.example.domain");
//config.setDestPackage("org.example.domain.query");
//config.setOverwriteExistingFinders(true);
Generator generator = new Generator(config);
generator.generateQueryBeans();
// Additionally generate 'finder's
//generator.generateFinders();
//generator.modifyEntityBeansAddFinderField();
}
}


| File | Statements | Branches | Functions | Lines | |||||
|---|---|---|---|---|---|---|---|---|---|
| AccessToken.js | 100% | 5/5 | 100% | 0/0 | 100% | 1/1 | 100% | 5/5 | |
| Account.js | 98.48% | 65/66 | 72.73% | 16/22 | 93.75% | 15/16 | 98.48% | 65/66 | |
| AccountStoreMapping.js | 90.32% | 28/31 | 75% | 9/12 | 100% | 6/6 | 90.32% | 28/31 | |
| ApiKey.js | 92.68% | 38/41 | 66.67% | 8/12 | 100% | 7/7 | 92.68% | 38/41 | |
| Application.js | 89.06% | 236/265 | 77.54% | 107/138 | 93.62% | 44/47 | 89.06% | 236/265 | |
| ApplicationAccountStoreMapping.js | 100% | 12/12 | 100% | 0/0 | 100% | 3/3 | 100% | 12/12 | |
| AuthenticationResult.js | 80.77% | 21/26 | 37.5% | 3/8 | 80% | 4/5 | 80.77% | 21/26 | |
| Challenge.js | 100% | 16/16 | 100% | 0/0 | 100% | 4/4 | 100% | 16/16 | |
| CollectionResource.js | 96.84% | 184/190 | 86.36% | 57/66 | 95.08% | 58/61 | 96.81% | 182/188 | |
| CustomData.js | 96.3% | 52/54 | 83.33% | 10/12 | 100% | 14/14 | 96.3% | 52/54 | |
| Directory.js | 92% | 46/50 | 50% | 2/4 | 92.86% | 13/14 | 92% | 46/50 | |
| DirectoryChildResource.js | 100% | 19/19 | 100% | 0/0 | 100% | 5/5 | 100% | 19/19 | |
| Factor.js | 100% | 17/17 | 100% | 4/4 | 100% | 4/4 | 100% | 17/17 | |
| FactorInstantiator.js | 100% | 21/21 | 100% | 7/7 | 100% | 2/2 | 100% | 21/21 | |
| Field.js | 100% | 8/8 | 100% | 0/0 | 100% | 2/2 | 100% | 8/8 | |
| GoogleAuthenticatorFactor.js | 100% | 9/9 | 100% | 0/0 | 100% | 2/2 | 100% | 9/9 | |
| Group.js | 100% | 17/17 | 100% | 2/2 | 100% | 4/4 | 100% | 17/17 | |
| GroupMembership.js | 100% | 12/12 | 100% | 0/0 | 100% | 3/3 | 100% | 12/12 | |
| IdSiteModel.js | 83.33% | 5/6 | 100% | 0/0 | 0% | 0/1 | 83.33% | 5/6 | |
| InstanceResource.js | 98.51% | 66/67 | 92.86% | 26/28 | 100% | 11/11 | 98.51% | 66/67 | |
| OAuthPolicy.js | 100% | 6/6 | 100% | 0/0 | 100% | 1/1 | 100% | 6/6 | |
| Organization.js | 64.22% | 70/109 | 37.5% | 12/32 | 53.33% | 16/30 | 64.22% | 70/109 | |
| OrganizationAccountStoreMapping.js | 100% | 12/12 | 100% | 0/0 | 100% | 3/3 | 100% | 12/12 | |
| PasswordPolicy.js | 100% | 9/9 | 100% | 0/0 | 100% | 2/2 | 100% | 9/9 | |
| PasswordResetToken.js | 83.33% | 5/6 | 100% | 0/0 | 0% | 0/1 | 83.33% | 5/6 | |
| Phone.js | 100% | 9/9 | 100% | 0/0 | 100% | 2/2 | 100% | 9/9 | |
| Provider.js | 100% | 6/6 | 100% | 0/0 | 100% | 1/1 | 100% | 6/6 | |
| ProviderData.js | 100% | 6/6 | 100% | 0/0 | 100% | 1/1 | 100% | 6/6 | |
| RefreshToken.js | 100% | 5/5 | 100% | 0/0 | 100% | 1/1 | 100% | 5/5 | |
| Resource.js | 100% | 18/18 | 100% | 10/10 | 100% | 3/3 | 100% | 18/18 | |
| ResourceFactory.js | 97.37% | 37/38 | 95% | 19/20 | 100% | 5/5 | 97.37% | 37/38 | |
| SamlPolicy.js | 100% | 9/9 | 100% | 0/0 | 100% | 2/2 | 100% | 9/9 | |
| SamlServiceProvider.js | 100% | 6/6 | 100% | 0/0 | 100% | 1/1 | 100% | 6/6 | |
| Schema.js | 100% | 9/9 | 100% | 0/0 | 100% | 2/2 | 100% | 9/9 | |
| SmsFactor.js | 100% | 12/12 | 100% | 0/0 | 100% | 3/3 | 100% | 12/12 | |
| SmtpServer.js | 83.33% | 5/6 | 100% | 0/0 | 0% | 0/1 | 83.33% | 5/6 | |
| Strength.js | 100% | 6/6 | 100% | 0/0 | 100% | 1/1 | 100% | 6/6 | |
| Tenant.js | 98.18% | 54/55 | 87.5% | 7/8 | 100% | 16/16 | 98.18% | 54/55 |


Cake\Utility\
Text
¶The Text class includes convenience methods for creating and manipulating
strings and is normally accessed statically. Example:
Text::uuid()
.
If you need Cake\View\Helper\TextHelper
functionalities outside
of a View
, use the Text
class:
namespace App\Controller;
use Cake\Utility\Text;
class UsersController extends AppController
{
public function initialize()
{
parent::initialize();
$this->loadComponent('Auth')
};
public function afterLogin()
{
$message = $this->Users->find('new_message');
if (!empty($message)) {
// Notify user of new message
$this->Flash->success(__(
'You have a new message: {0}',
Text::truncate($message['Message']['body'], 255, ['html' => true])
));
}
}
}
Cake\Utility\Text::
transliterate
($string, $transliteratorId = null)¶Transliterate by default converts all characters in provided string into
equivalent ASCII characters. The method expects UTF-8 encoding. The character
conversion can be controlled using transliteration identifiers which you can
pass using the $transliteratorId
argument or change the default identifier
string using Text::setTransliteratorId()
. ICU transliteration identifiers
are basically of form <source script>:<target script>
and you can specify
multiple conversion pairs separated by ;
. You can find more info about
transliterator identifiers
here:
// apple puree
Text::transliterate('apple purée');
// Ubermensch (only latin characters are transliterated)
Text::transliterate('Übérmensch', 'Latin-ASCII;');
Cake\Utility\Text::
slug
($string, $options = [])¶Slug transliterates all characters into ASCII versions and converting unmatched characters and spaces to dashes. The slug method expects UTF-8 encoding.
You can provide an array of options that controls slug. $options
can also be
a string in which case it will be used as replacement string. The supported
options are:
replacement
Replacement string, defaults to ‘-‘.
transliteratorId
A valid tranliterator id string. If default null
Text::$_defaultTransliteratorId
to be used.
If false
no transliteration will be done, only non words will be removed.
preserve
Specific non-word character to preserve. Defaults to null
.
For e.g. this option can be set to ‘.’ to generate clean file names:
// apple-puree
Text::slug('apple purée');
// apple_puree
Text::slug('apple purée', '_');
// foo-bar.tar.gz
Text::slug('foo bar.tar.gz', ['preserve' => '.']);
Cake\Utility\Text::
uuid
¶The UUID method is used to generate unique identifiers as per RFC 4122. The
UUID is a 128-bit string in the format of
485fc381-e790-47a3-9794-1337c0a8fe68
.
Text::uuid(); // 485fc381-e790-47a3-9794-1337c0a8fe68
Cake\Utility\Text::
tokenize
($data, $separator = ', ', $leftBound = '(', $rightBound = ')')¶Tokenizes a string using $separator
, ignoring any instance of $separator
that appears between $leftBound
and $rightBound
.
This method can be useful when splitting up data that has regular formatting such as tag lists:
$data = "cakephp 'great framework' php";
$result = Text::tokenize($data, ' ', "'", "'");
// Result contains
['cakephp', "'great framework'", 'php'];
Cake\Utility\Text::
parseFileSize
(string $size, $default)¶This method unformats a number from a human-readable byte size to an integer number of bytes:
$int = Text::parseFileSize('2GB');
Cake\Utility\Text::
insert
($string, $data, $options = [])¶The insert method is used to create string templates and to allow for key/value replacements:
Text::insert(
'My name is :name and I am :age years old.',
['name' => 'Bob', 'age' => '65']
);
// Returns: "My name is Bob and I am 65 years old."
Cake\Utility\Text::
cleanInsert
($string, $options = [])¶Cleans up a Text::insert
formatted string with given $options
depending
on the ‘clean’ key in $options
. The default method used is text but html is
also available. The goal of this function is to replace all whitespace and
unneeded markup around placeholders that did not get replaced by
Text::insert
.
You can use the following options in the options array:
$options = [
'clean' => [
'method' => 'text', // or html
],
'before' => '',
'after' => ''
];
Cake\Utility\Text::
wrap
($text, $options = [])¶Wraps a block of text to a set width and indents blocks as well. Can intelligently wrap text so words are not sliced across lines:
$text = 'This is the song that never ends.';
$result = Text::wrap($text, 22);
// Returns
This is the song that
never ends.
You can provide an array of options that control how wrapping is done. The supported options are:
width
The width to wrap to. Defaults to 72.wordWrap
Whether or not to wrap whole words. Defaults to true
.indent
The character to indent lines with. Defaults to ‘’.indentAt
The line number to start indenting text. Defaults to 0.Cake\Utility\Text::
wrapBlock
($text, $options = [])¶If you need to ensure that the total width of the generated block won’t
exceed a certain length even with internal identation, you need to use
wrapBlock()
instead of wrap()
. This is particulary useful to generate
text for the console for example. It accepts the same options as wrap()
:
$text = 'This is the song that never ends. This is the song that never ends.';
$result = Text::wrapBlock($text, [
'width' => 22,
'indent' => ' → ',
'indentAt' => 1
]);
// Returns
This is the song that
→ never ends. This
→ is the song that
→ never ends.
Cake\Utility\Text::
highlight
(string $haystack, string $needle, array $options = [])¶Highlights $needle
in $haystack
using the $options['format']
string
specified or a default string.
Options:
format
string - The piece of HTML with the phrase that will be
highlightedhtml
bool - If true
, will ignore any HTML tags, ensuring that only
the correct text is highlightedExample:
// Called as TextHelper
echo $this->Text->highlight(
$lastSentence,
'using',
['format' => '\1']
);
// Called as Text
use Cake\Utility\Text;
echo Text::highlight(
$lastSentence,
'using',
['format' => '\1']
);
Output:
Highlights $needle in $haystack using the
$options['format'] string specified or a default string.
Cake\Utility\Text::
truncate
(string $text, int $length = 100, array $options)¶If $text
is longer than $length
, this method truncates it at $length
and adds a suffix consisting of 'ellipsis'
, if defined. If 'exact'
is
passed as false
, the truncation will occur at the first whitespace after the
point at which $length
is exceeded. If 'html'
is passed as true
,
HTML tags will be respected and will not be cut off.
$options
is used to pass all extra parameters, and has the following
possible keys by default, all of which are optional:
[
'ellipsis' => '...',
'exact' => true,
'html' => false
]
Example:
// Called as TextHelper
echo $this->Text->truncate(
'The killer crept forward and tripped on the rug.',
22,
[
'ellipsis' => '...',
'exact' => false
]
);
// Called as Text
use Cake\Utility\Text;
echo Text::truncate(
'The killer crept forward and tripped on the rug.',
22,
[
'ellipsis' => '...',
'exact' => false
]
);
Output:
The killer crept...
Cake\Utility\Text::
tail
(string $text, int $length = 100, array $options)¶If $text
is longer than $length
, this method removes an initial
substring with length consisting of the difference and prepends a prefix
consisting of 'ellipsis'
, if defined. If 'exact'
is passed as false
,
the truncation will occur at the first whitespace prior to the point at which
truncation would otherwise take place.
$options
is used to pass all extra parameters, and has the following
possible keys by default, all of which are optional:
[
'ellipsis' => '...',
'exact' => true
]
Example:
$sampleText = 'I packed my bag and in it I put a PSP, a PS3, a TV, ' .
'a C# program that can divide by zero, death metal t-shirts'
// Called as TextHelper
echo $this->Text->tail(
$sampleText,
70,
[
'ellipsis' => '...',
'exact' => false
]
);
// Called as Text
use Cake\Utility\Text;
echo Text::tail(
$sampleText,
70,
[
'ellipsis' => '...',
'exact' => false
]
);
Output:
...a TV, a C# program that can divide by zero, death metal t-shirts
Cake\Utility\Text::
excerpt
(string $haystack, string $needle, integer $radius=100, string $ellipsis="...")¶Extracts an excerpt from $haystack
surrounding the $needle
with a number
of characters on each side determined by $radius
, and prefix/suffix with
$ellipsis
. This method is especially handy for search results. The query
string or keywords can be shown within the resulting document.
// Called as TextHelper
echo $this->Text->excerpt($lastParagraph, 'method', 50, '...');
// Called as Text
use Cake\Utility\Text;
echo Text::excerpt($lastParagraph, 'method', 50, '...');
Output:
... by $radius, and prefix/suffix with $ellipsis. This method is especially
handy for search results. The query...
Cake\Utility\Text::
toList
(array $list, $and='and', $separator=', ')¶Creates a comma-separated list where the last two items are joined with ‘and’:
$colors = ['red', 'orange', 'yellow', 'green', 'blue', 'indigo', 'violet'];
// Called as TextHelper
echo $this->Text->toList($colors);
// Called as Text
use Cake\Utility\Text;
echo Text::toList($colors);
Output:
red, orange, yellow, green, blue, indigo and violet


Data provided for free by IEX. View IEX's Terms of Use. All price quotes leverage IEX's Real-Time Price


 I know everything that goes on in the town of Floran! Now confess! Who sent you here?
Tell him about the Mark of the Challenger and Martien


Toggle navigation
GoHost
Login
×
Login
Email
Password
Username/password do not match.
Welcome to GoHost
Name
Email
Password
Confirm Password
Error in creating account
This user name has already been taken.
Find nearby activities.
Meet new friends.
Go host your own events.


This is me from about three years ago
This is Mateo and Ariel. They were the children of some close friends at church. We are like family.
My dad is named Enin. He is in the middle and those are his friends from church.
That's my youngest sister Yajaira. She loves to smile!
This is my mom, Maritza, and her dad from Guatemala.
This is Me and my sister Hellen while carpooling to church.
This is a family photo that includes (from left to right) my mom, her mom, Hellen, Yajaira and me. I miss that beard.
This picture is from our first time in Universal studio. My oldest sister is Hellen, on the right. And My youngest sister on the left.


Eclipse SDK
Version: 3.7.2
Build id: M20120208-0800
(c) Copyright
Eclipse contributors and others 2000, 2012.
All rights reserved.
Visit http://www.eclipse.org/platform
This product includes software
developed by the
Apache Software Foundation http://www.apache.org/


UIInterface
component for testing purposes.Accordion
objectDate
to match
that in the format string.Filter
s in the filter chain stack by chaining calls
to Filter.applyFilter(ArrayList)
, beginning with the list of
Task
objects in the root Filter
.Task
objects.


@composi/core:
Render
Defining Markup
By default Composi uses JSX for defining the markup that it renders. This is declarative and makes it easy to reason about what the rendered markup will be.
Importing h and render
Before we can do anything, we need to import two essential functions from @composi/core: h
and render
:
import { h, render } from '@composi/core'
h
gets used by Babel to transform the JSX tags into function calls to be create virtual nodes. These will be converted into real DOM nodes during render.
JSX
You can use JSX to define the markup that a functional component creates. Unlike React, you do not have to use special attributes or camel case with attributes. You use the normal HTML attributes: onclick=''
, class=''
, for=''
, etc. Because this is JSX, which is a variety of XML, you do need to terminate self-closing tags with a forward slash:

, <input type='text'/>
,
, etc.
Functional Components
To create a component that you can render, you need to start with a function. The name needs to be capitalized. Here is a simple Hello World function.
import { h, render } from '@composi/core'
function HelloWorld() {
return (

Hello, World!

)
}
Notice that this function does one thing, it returns some JSX markup.
Rendering
We can now pass this function to the render
function as a tag. The render
function takes two arguments: the tag to render, and the container to render into. The tag should be a function written as a JSX tag. The container can be a DOM node reference, or a selector.
import { h, render } from '@composi/core'
function HelloWorld() {
return (

Hello, World!

)
}
// Render the component to the DOM:
render(<HelloWorld />, document.body)
To udate a component, just pass it to render along with new values for its props. Let's update the above example:
See the Pen @composi/core - Hello World by Robert Biggs (@rbiggs) on CodePen.
Selector vs DOM Reference
In the above example we're using a string "header"
as the container for the component. This is fine for occasional renders. However, if the component might be rendered many times in rapid succession, such as when animating a component, it would be better to use a DOM reference to that container. That's because when you provide a string selector for the container, each time the component is rendered, Composi has to query the DOM for that selector. Getting a reference to the container first and using that in the render function means that render can immediate start diffing and patching the DOM.
Passing Children to a Component
Sometimes you may want to be able to pass children to a component. You can enable any fuctional component to accept arbitrary children by passing it a second parameter after the props one. Then you can output whatever the children are by processing the children
value inside of curly braces. Notice how we do that in this example. We have a FancyBorder
that accepts any child component. This means we can pass anything we need to as a child. In this case, we pass in another component, DialogMessage
, but it could be anything. This makes the FancyBorder component much more reusable.
See the Pen @composi/core - Passing Children to Component by Robert Biggs (@rbiggs) on CodePen.
Props
To make a component dynamic, we need to be able to pass some data into it. We do that through props
. This is the main argument that any JSX tag receives. Whatever properties you give the tag will be available from this object. Let's redo our previous example to use props. Notice how we access the greeting
value from props
:
See the Pen @composi/core - Hello World-2 by Robert Biggs (@rbiggs) on CodePen.
Since we are now using props
in our component, we can update the component at any time by re-rendering it with a new prop
value. Let's say we want to update the value of our Hello World example after five seconds. To update a component, we just need to change the value of the prop when we re-render it:
See the Pen @composi/core - Hello World-3 by Robert Biggs (@rbiggs) on CodePen.
For more details about using props
consult the documentation.
Conditional Rendering
Sometimes you need to render a component based on a certain criterion. There are two ways to handle conditional rendering: directly in the return statement, or before the return statement.
Return Statement Logic
The most common way to control is or how a component renders is to do so directly inside the return statement. To do this you use boolean checks with JavaScript logical operators (&&, ||, and !) or with a ternary operator. In fact, you can use these to return different markup based on your conditional checks. Because you are inside a return statement, you cannot use any conditional statements (if, if else, else).
Logical Operators
You can use logical operators to determine what to return in your statement. Notice how we use the AND operator (&&) and then the OR operator (||) to switch to the other option. However, when you want an if/else
you need to use the OR operator for the else
. The problem is that it is easy to forget to put the OR operator, in which case the second condition will never happen. This results in hard to debug situations.
// Two components to render:
function UserGreeting(props) {
return
Welcome back!

}
function GuestGreeting(props) {
return
Please sign in.

}
function Greeting(props) {
const isLoggedIn = props.isLoggedIn
// With logical operators:
return (
isLoggedIn && <UserGreeting /> ||
!isLoggedIn && <GuestGreeting />
)
}
Using the AND operator is great when you just want to output based on one condition, basically the same as if
. Notice how in this version, it is very clear what the intent is. However it is not branching logic.
// Only render greeting if the user is logged in.
// There is no alternative rendering here.
function Greeting(props) {
const isLoggedIn = props.isLoggedIn
// With logical operators:
return (
isLoggedIn && <UserGreeting />
)
}
Here's an example that shows how using logical operators can result in hard to read logic when the components are complex:
See the Pen @composi/core - Conditional-1 by Robert Biggs (@rbiggs) on CodePen.
Ternary Operator
The ternary operator is more clear about what is going on, and more compact. This is a great choice for simple tags. However, if your tags have a lot of properties, then a ternary expression can be hard to read.
function Greeting(props) {
const isLoggedIn = props.isLoggedIn
// With a tertiary conditional:
return isLoggedIn ? <UserGreeting /> : <GuestGreeting />
}
Here's an example of using a ternary operator with complex components. Notice that its got the same basic structure as the previous live example using logical operators:
See the Pen @composi/core - Conditional-2 by Robert Biggs (@rbiggs) on CodePen.
Logic Before Return
If you need conditional rendering without the drawbacks of logical and ternary operators, you can use standard conditional statements to determin what to return. Many developers prefer the more compact syntax of logical and ternary operators. However, with conditional statements there is no ambiguity about what is happening.
function Greeting(props) {
const isLoggedIn = props.isLoggedIn
// With conditional statements:
if (isLoggedIn) {
return <UserGreeting />
} else {
return <GuestGreeting />
}
}
Some people and linters don't like return statements in conditional statements because there is no explicit return. We can change that to fix the issue:
function Greeting(props) {
const isLoggedIn = props.isLoggedIn
// With conditional statements:
if (isLoggedIn) {
return <UserGreeting />
}
// If the above logic failse,
// return the guest greeting:
return <GuestGreeting />
}
And here is this as a live example. This does result in more readable logic:
See the Pen @composi/core - Conditional-3 by Robert Biggs (@rbiggs) on CodePen.
In the end, pick the approach that works best for you.
Not Rendering a Component
Sometimes you want to not render a component when a condition occurs. Using the above conditional state format we can solve this. Here's an example:
See the Pen @composi/core - Conditional-4 by Robert Biggs (@rbiggs) on CodePen.
Notice how when showWarning
is true, we return the component, otherwise we return null. We could also leave off the else
statement for brevity. We could also use a simple logical operator for this:
function WarningBanner() {
return (
showWarning && (

Warning!

)
)
}
In this case, the use of the logical operator is clear and concise. We could also use a ternary operator for this:
function WarningBanner() {
return (
showWarning ? (

Warning!

) : null
)
}
In this case, the ternary operator is not as concise as the logical operator. The ternary operator requires if/else
logic, whereas the logical operator lets us handle an if
condition.
Limits of Container
When @composi/core renders a component into a container, it caches the component's virtual node on the container. The next time you render that component, Composi grabs the cached virtual node from the container and uses that to diff and patch the DOM. This means that a container can have only one component. When you render a component into a container, if said container has static content, the component will be appended after the content.
If you need to output more than one component into the same container, wrap them in a parent component and render it in the component. You cannot use the Fragment
tag for this, as it must be consumed by a tag that returns a singular element.
Debouncing Renders
It's possible that you may be using some type of event, such as cursor position, to trigger an update. This is very common for animation. In that case you would want to wrap the render function in requestAnimationFrame
. This will result in skipping unnecessary attempts to render faster than the browser can handle. The format is like this:
requestAnimationFrame(() => {
render(, 'body')
})
Check out the documentation about how to do this with @composi/datastore


{% extends "newwebpage/base.html" %} {% load crispy_forms_tags %} {% load static %} {% block content %}
-No. Even though you can identify the most closely related proteins, you can only acquire an official name by use of this site. Self-naming of proteins will inevitably lead to different users adopting the same protein name, confusing the literature. Only the nomenclature committee can issue new protein names.
-No. Xpp is a holding group containing members of several disparate protein families. As a result, Xpp-like would not actually indicate any significant homology. You could however, refer to your protein in relation to a specific Xpp protein (as Xpp37-like for example). The numeric value will be retained when the protein is re-categorized to a specific protein family in the future.
-Probably not. This site only aims to deal with proteins of bacterial origin. However, if your protein of non-bacterial origin has a high degree of identity with a protein that is already in the database, you may make a case for its inclusion. The committee will consider these requests on a case-by-case basis.


RTTraceroute
This was a little project I did for a networks class. It finds the RTT (Round-Trip delay Time), hop count, and geographical distance between your computer and other hosts on the internet. The sites are hardcoded to comply with the assignment.


Data Source V2 API in Spark 3.0 - Part 2 : Anatomy of V2 Read API
Spark 3.0 is a major release of Apache Spark framework. It’s been in preview from last December and going to have a stable release very soon. As part of major release, Spark has a habit of shaking up API’s to bring it to latest standards. There will be breaking changes also in these API’s. One of such API is Data source V2 API.
Data Source V2 API, a new data source API for spark, was introduced in spark 2.3. Then it’s been updated in spark 2.4. I have written detailed posts on same here.
This API is going to be completely changed in Spark 3.0. Spark rarely change an API this frequently in between releases. But as data source are heart of the framework, they are improved constantly. Also in spark 2.4, these API’s were marked evolving. This means they are meant to be changed in future.
The usage of the data sources have not changed in 3.0. So if you are a user of the third party data sources you don’t need to worry. These changes are geared mainly towards the developer of these sources. Also all the sources written V1 API going to work even in 3.0. So if your source is not updated, no need to panic. It’s going to work without latest optimisations.
These new changes in V2 API brings more control to data source developer and better integration with spark optimiser. Moving to this API makes third party sources more performant. So in these series of posts I will be discussing the new Data source V2 API in 3.0.
This is the second post in the series where we discuss about different interfaces to read data in V2 API.You can read all the posts in the series here.
Java Interfaces
One of the characteristics of V2 API’s is it’s exposed in terms of Java interfaces rather than scala traits. The primary reason for this is better interop with Java.
The below are the basic interfaces to read the data in V2 API.
TableProvider
TableProvider trait signifies it’s a source which can read or write a table. Here table is a structured dataset. The below are the methods
def inferSchema(caseInsensitiveStringMap: CaseInsensitiveStringMap): StructType
def getTable(structType: StructType, transforms: Array[Transform], map: util.Map[String, String])
The methods are
-
inferSchema - The method takes parameter from user and tries to infer the schema
-
getTable - This is used for loading table with user specified schema and other transformations.
Table
Table is an interface representing a logical structured data set of a data source. It exposes below three methods
def name:String
def schema:StructType
def capabilities: TableCapability
The different methods are
-
name : A name to identify the table.
-
schema : Table Schema. An empty schema can be returned if schema inference needed.
-
capabilities : Capabilities exposed by the table. This is one of the unique feature added in spark 3.0. This allows to specifying what kind of operation table supports. Some capabilities like BATCH_READ, BATCH_WRITE. This helps spark to verify these before attempting to run the operations.
SupportsRead
This interface indicates that source supports read. This has one abstract method that needs to be overridden.
def newScanBuilder(options: CaseInsensitiveStringMap): ScanBuilder
ScanBuilder
An interface for building Scan. This interface can mix with filter push down to keep the needed information to push the filters to readers. The exposed abstract methods are
def build(): Scan
Scan
Logical representation of a data source scan. This interface is used to provide logical information, like what the actual read schema is. This is a common scan for all different scanning like batch, micro batch etc. The needed methods to be overridden are
def readSchema(): StructType
def toBatch: Batch
The methods are
-
readSchema - The actual schema of the source. This may look like repetitive from Table interface. The reason it is repeated because, after column pruning or other optimisation the schema may change or we may need inference of schema. This method returns actual schema of the data where as the Table one returns the initial schema.
-
toBatch - This method needs to be overridden to indicate that this scan configuration should be used for batch reading.
Batch
A physical representation of a data source scan for batch queries. This interface is used to provide physical information, like how many partitions the scanned data has, and how to read records from the partitions.
The methods that need to be overridden are
def planInputPartitions(): Array[InputPartition]
def createReaderFactory(): PartitionReaderFactory
The methods are
-
planInputPartitions : List of partitions for the table. This number decides number of partitions in Dataset.
-
createReaderFactory : Factory to create the readers
PartitionReaderFactory
It’s a factory class to create actual data readers. The data reader creation happens on the individual machines. It exposes single method.
def createReader(partition: InputPartition): PartitionReader[InternalRow]
As the name suggest, it creates data reader.
PartitionReader
Finally we have the interface which actually reads the data. The below are methods
def next : Boolean
def get : T
def close() : Unit
As you can see from interface, it looks as simple iterator based reader. Currently T can be only InternalRow.
References
https://github.com/apache/spark/pull/22009
Conclusion
In this post we discussed some of the important interfaces from data source V2 API for reading data. You can see how this API is much different than earlier API.


Apple Bluetooth Keyboard on Linux
The Microsoft Entertainment 7000 we use for MythTV was being flaky - repeated keypresses, ignored keypresses. Kind of strange. So one of the problems with the microsoft keyboard was it was hard to pass around, thus getting dropped and probably creating many problems. Apple's shiny Bluetooth keyboard is small and relatively grippy. But don't buy it at FutureShop, the bastards - the MSRP is cheaper than their price.
A weird thing about the MS Entertainment keyboard is that it 'is' Bluetooth - well the keyboard and mouse are, but not necessarily. You see, the Transceiver can operate in a custom mode where it looks like a USB HID device. Actually, one advantage of this particular embrace-and-extend is that the keyboard is available before the OS is ready (which makes you wonder what the Bluetooth SIG was thinking).
Apparently there is a means (Windows only, of course) to change it to a (limited!) Bluetooth transceiver, which is good enough for me as I need the Bluetooth keyboard to work in MythTV. But I don't have a Windows machine around right now that I can just throw crappy drivers on without consequences. So finally I gave up on it and brought home a Bluetooth adapter I used to detect when I was in the office and toggle my screensaver password on and off.
So, then the trick was getting KnoppMyth to work with it. (I'm still running KnoppMyth R5F1 on this machine - instructions may change for newer versions).
apt-get install bluetooth
I think followed the instructions here except I'm NOT running Gnome on my Knoppmyth box, so I changed /etc/bluetooth/hcid.conf file to look kinda like this:
options {
autoinit yes;
# Security Manager mode
# none - Security manager disabled
# auto - Use local PIN for incoming connections
# user - Always ask user for a PIN
#
security auto;
# Pairing mode
# none - Pairing disabled
# multi - Allow pairing with already paired devices
# once - Pair once and deny successive attempts
pairing multi;
# Default PIN code for incoming connections
# not really - I changed it
passkey "2222";
}
device XX:XX:XX:XX:XX:XX {
name "Apple Wireless Keyboard";
# not sure if class is necessary, interesting, etc.
class 0x002540;
lm master;
# these were specified in the docs I linked but are not acceptable arguments in the version.
# auth enable;
# encrypt enable;
}
I also added the following options to /etc/default/bluetooth:
HIDD_OPTIONS="-t5000 --master --server --connect XX:XX:XX:XX:XX:XX "
The '-t5000″ option is apparently required to allow the keyboard to reconnect after it goes to sleep. Without it the keyboard will not work after a long period of inactivity.
oops - doesn't work yet!!!
And then when initializing the Bluetooth system I had to type in the PIN specified in the file on the keyboard blindly and eventually things worked. Honestly it took more fiddling than that. But it works.
If it comes to it the obvious next option (if necessary) would be a DiNovo Mini, which I forgot about and didn't think was available yet.
About this entry
You"re currently reading "Apple Bluetooth Keyboard on Linux," an entry on a crick in the net
- Published:
- 07.04.08 / 6pm
- Category:
- MythTV