Perception, Planning, and Control
© Russ Tedrake, 2020-2021
Last modified .
How to cite these notes, use annotations, and give feedback.
Note: These are working notes used for a course being taught at MIT. They will be updated throughout the Fall 2021 semester.
| Previous Chapter | Table of contents | Next Chapter |
In this chapter we're going to outfit your mech. I want to make sure you understand the robot hardware that we've selected for these notes, and how it compares to the other hardware available today. You should also come away with an understanding of how we simulate the robot and what commands you can send to the robot interface.
Although we are going to focus on one particular set of hardware for these notes, one of the great things about modern robotics is that many of the tools we will develop over the course of these notes are quite general, and can be transferred from one robot to another easily. I could imagine a future version of these notes where you really do get to build out your robot in this chapter, and use your customized robot for the remaining chapters!
There appear to be a lot of robotics arms available on the market. So how does one choose? Cost, reliability, usability, payload, range of motion, ...; there are many important considerations. And the choices we might make for a research lab might be very different than the choices we might make as a startup.
I've put together a simple example to let you explore some of the various robot arms that are popular today.
This is made possible by the proliferation of some common file formats for describing our robots. Unfortunately, the field has not converged on a single preferred format (yet), and each of them have their quirks. Drake currently loads Universal Robot Description Format (URDF) and Simulation Description Format (SDF); the Drake developers have been trying to upstream improvements to SDF rather than start yet another format.
Let me know if your favorite arm isn't on the list yet!
There is one particular requirement which, if we want our robot to meet, quickly winnows the field to only a few viable platforms: that requirement is joint-torque sensing and control. It's not absolutely clear that this feature is required, even for very advanced applications, but as a researcher who cares a great deal about the contact interactions between my robots and the world, I prefer to have the capability and explore whether I need it rather than wonder what life might have been like.
Out of the torque-controlled robots on the market, I've chosen to use the Kuka LBR iiwa robot to use throughout these notes (I will try to use the lower case "iiwa" to be consistent with the manufacturer, but it looks wrong to me every time!). To better understand why, let us start by understanding the difference between most robots, which are position-controlled, and the handful of robots that have accepted the additional cost and complexity to provide torque sensing and control.
Most robot arms today are "position controlled" -- given a desired joint position (or joint trajectory), the robot executes it with relatively high precision. Basically all arms can be position controlled -- if the robot offers a torque control interface (with sufficiently high bandwidth) then we can certainly regulate positions, too. In practice, calling a robot "position controlled" is a polite way of saying that it does not offer torque control. Do you know why position control and not torque control is the norm?
Lightweight arms like the examples above are actuated with electric motors. For a reasonably high-quality electric motor (with windings designed to minimize torque ripple, etc), we expect the torque that the motor outputs to be directly proportional to the current that we apply: $$\tau_{motor} = k_t i,$$ where $\tau_{motor}$ is the motor torque, $i$ is the applied current, and $k_t$ is the "motor torque constant". (Similarly, applied voltage has a simple (affine) relationship with the motor's steady-state velocity). If we can control the current, then why can we not control the torque?
The short answer is that to achieve reasonable cost and weight, we typically choose small electric motors with large gear reductions, and gear reductions come with a number of dynamic effects that are very difficult to model -- including backlash, vibration, and friction. So the simple relationship between current and torque breaks down. Conventional wisdom is that for large gear ratios (say $\gg 10$), the unmodeled terms are significant enough that they cannot be ignored, and torque is no longer simply related to current.
How can we overcome this challenge of not having a good model of the transmission dynamics? Regulating the current or speed of the motor only requires sensors on the motor side of the transmission; if we add more sensors on the output side of the transmission, then we can use high-gain feedback to try to directly regulate the joint, instead of the motor. Importantly, although the torques due to the transmission are not known precisely, they are also not arbitrary -- for instance they will never add energy into the system. Most importantly, we can be confident that there is a monotonically increasing relationship between the current that we put into the motor and the torque at the joint, and ultimately the acceleration of the joint. Note that I chose the term monotonic carefully, meaning "non-decreasing" but not implying "strictly increasing", because, for instance, when a joint is starting from rest, static friction will resist small torques without having any acceleration at the output.
The most common sensor to add to the joint is a position sensor -- typically an encoder or potentiometer -- these are inexpensive, accurate, and robust. In practice, we think of these as providing (after some signal filtering/conditioning) accurate measurements of the joint position and joint velocity via differentiation -- joint accelerations can also be obtained via differentiating twice but are generally considered more noisy and less suitable for use in tight feedback loops. This is sufficient for accurately tracking desired position trajectories of the arm. For each joint, if we are given a desired trajectory $q^d(t)$, then I can track this using proportional-integral-derivative (PID) control: $$\tau = k_p (q^d - q) + k_d (\dot{q}^d - \dot{q}) + k_i \int (q^d - q) dt,$$ with $k_p$, $k_d$, and $k_i$ being the position, velocity, and integral gains. PID control has a rich theory, and a trove of knowledge about how to choose the gains, which I will not reproduce here. I will note, however, that when we simulate position-controlled robots we use the equation above, commanding a torque directly, but on hardware our PID controller typically outputs voltage commands (via pulse-width modulation). Closing this modeling gap has traditionally not been a priority for robot simulation, but does mean that we often have one list of gains for the physical robot and a separate list for the simulation.
One thing that might be surprising is that, despite the fact that the joint dynamics of a manipulator are highly coupled and state dependent, the PID gains for each joint are often chosen independently for each joint, and are constant (not gain-scheduled ). Wouldn't you expect for the motor commands required for e.g. a robot arm at full extension holding a milk jug might be very different than the motor commands required when it is unloaded in a vertical hanging position? Surprisingly, the required gains/commands might not be as different as one would think.
Electric motors are most efficient at high speeds (often > 100 or 1,000 rotations per minute). We probably don't actually want our robots to move that fast even if they could! So nearly all electric robots have fairly substantial gear reductions, often on the order of 100:1; the transmission output turns one revolution for every 100 rotations of the motor, and the output torque is 100 times greater than the motor torque. For a gear ratio, $n$, actuating a joint $q$, we have $$q_{motor} = n q,\quad \dot{q}_{motor} = n \dot{q}, \quad \ddot{q}_{motor} = n \ddot{q}, \qquad \tau_{motor} = \frac{1}{n} \tau.$$ Interestingly, this has a fairly profound impact on the resulting dynamics (given by $f = ma$), even for a single joint. Writing the relationship between joint torque and joint acceleration (no motors yet), we can write $ma = \sum f$ in the rotational coordinates as $$I_{arm} \ddot{q} = \tau_{gravity} + \tau,$$ where $I_{arm}$ is the moment of inertia. For example, for a simple pendulum, we might have $$ml^2 \ddot{q} = - mgl\sin{q} + \tau.$$ But the applied joint torque $\tau$ actually comes from the motor -- if we write this equation in terms of motor coordinates we get: $$\frac{I_{arm}}{n} \ddot{q}_{motor} = \tau_{gravity} + n\tau_{motor}.$$ If we divide through by $n$, and take into account the fact that the motor itself has inertia (e.g. from the large spinning magnets) that is not affected by the gear ratio, then we obtain: $$\left(I_{motor} + \frac{I_{arm}}{n^2}\right) \ddot{q}_{motor} = \frac{\tau_{gravity}}{n} + \tau_{motor}.$$
It's interesting to note that, even though the mass of the motors might make up only a small fraction of the total mass of the robot, for highly geared robots they can play a significant role in the dynamics of the joints. We use the term reflected inertia to denote the inertial load that is felt on the opposite side of a transmission, due to the scaling effect of the transmission. The "reflected inertia" of the arm at the motor is cut by the square of the gear ratio; or the "reflected inertia" of the motor at the arm is multiplied by the square of the gear ratio. This has interesting consequences -- as we move to the multi-link case, we will see that the inertia of the arm is a state-dependent function that captures the inertial coupling of the other joints in the manipulator. The motor inertia, on the other hand, is constant. For large gear ratios, this means the dynamics of the joint are less dependent on the nonlinear effects of joint position and velocity, making it relatively easy to tune constant feedback gains that perform well in all configurations.
Although not as common, there are a number of robots that do support direct control of the joint torques. There are a handful of ways that this capability can be realized.
It is possible to actuate a robot using electric motors that
require only a small gear reduction (e.g. $\le$ 10:1) where the frictional
forces are negligible. In the past, these "direct-drive
robots"
Hydraulic actuators provide another solution for generating large torques without large transmissions. Sarcos had a series of torque-controlled arms (and humanoids), and many of the most famous robots from Boston Dynamics are based on hydraulics (though there is an increasing trend towards electric motors). These robots typically have a single central pump and each actuator has a (lightweight) valve that can shunt fluid through the actuator or through a bypass; the differential pressure across the actuator is at least approximately related to the resulting force/torque.
Another approach to torque control is to keep the large gear-ratio
motors, but add sensors to directly measure the torque at the joint side
of the actuator. This is the approach used by the Kuka iiwa robot that we
use in the example throughout this text; the iiwa actuators have strain gauges
integrated into the transmission. However there is a trade-off between
the stiffness of the transmission and the accuracy of the force/torque
measurement
The low-cost torque-controlled arms that I mentioned above are just the beginnings in what promises to be a massive proliferation of robotic arms. As demand increases, costs will continue to come down.
Let me just say that, compared to working on legged robots, where for decades we did our research on laboratory prototypes built by graduate students (and occasionally professors!) in the machine shop down the hall, the availability of professionally engineered, high-quality, high-uptime hardware is an absolute treat. This also means that we can test algorithms in one lab and have another lab perhaps at another univeristy testing algorithms on almost identical hardware; this facilitates levels of repeatability and sharing that were impossible before. The fact that the prices are coming down, which will mean many more similar robots in many more labs/environments, is one of the big reasons why I am so optimistic about the next few years in the field.
It's a good time to be working on manipulation!
It's time to simulate our chosen robotic arm. The first step is to obtain a robot description file (URDF or SDF). For convenience, we ship the models for a few robots, including iiwa, with Drake. If you're interested in simulating a different robot, you can find either a URDF or SDF describing most commercial robots somewhere online. But a word of warning: the quality of these models can vary wildly. We've seen surprising errors in even the kinematics (link lengths, geometries, etc), but the dynamics properties (inertia, friction, etc) in particular are often not accurate at all. Sometimes they are not even mathematically consistent (e.g. it is possible to specify an inertial matrix which is not physically realizable by any rigid body). Drake will complain if you ask it to load a file with this sort of violation; we would rather alert you early than start generating bogus simulations. There is also increasingly good support for exporting to a robot format directly from CAD software like Solidworks.
Now we have to import this robot description file into our physics
engine. In Drake, the physics engine is called
MultibodyPlant
. The term "plant" may seem odd -- it is the
word used in the controls literature to represent the physical system,
with origins in the control of chemical plants -- but it is pervasive.
This connection is also important to me; not many physics engines in the
world go to the lengths that Drake does to make the physics engine
compatible with system-theoretic design and analysis. You can access the
methods of MultibodyPlant
through its class methods, e.g. for
use in designing a model-based controller. But in order to work with our
model-based design philosophy, MultibodyPlant
also provides
an interface as a System
, with input and output ports.
As you might expect for something as complex and general as a physics engine, it has many input and output ports; most of them are optional. I'll illustrate the mechanics of using these in the following example.
It's worth spending a few minutes with this example, which should help you understand not only the physics engine, but some of the basic mechanics of working with simulations in Drake.
The best way to visualize the results of a physics engine is with a 2D
or 3D visualizer. For that, we need to add the system which curates the
geometry of a scene; in Drake we call it the SceneGraph
.
Once we have a SceneGraph
, then there are a number of
different visualizers and sensors that we can add to the system to
actually render the scene.
This example is far more interesting to watch. Now we have the 3D visualization!
You might wonder why MultibodyPlant
doesn't handle the
geometry of the scene as well. Well, there are many application where
we'd like to render complex scenes, and use complex sensors, but supply
custom dynamics instead of the default physics engine. Autonomous driving
is a great example; in that case we want to populate a
SceneGraph
with all of the geometry of the vehicles and
environment, but we often want to simulate the vehicles with very simple
vehicle models that stop well short of adding tire mechanics into our
physics engine.
We now have a basic simulation of the iiwa, but already some subtleties emerge. The physics engine needs to be told what torques to apply at the joints. In our example, we apply zero torque, and the robot falls down. In reality, that never happens; in fact there is essentially never a situation where the physical iiwa robot experiences zero torque at the joints, even when the controller is turned off. Like many mature industrial robot arms, iiwa has mechanical brakes at each joint that are engaged whenever the controller is turned off. To simulate the robot with the controller turned off, we would need to tell our physics engine about the torques produced by these brakes.
In fact, even when the controller is turned on, and despite the fact that it is a torque-controlled robot, we can never actually send zero torques to the motors. The iiwa software interface accepts "feed-forward torque" commands, but it will always add these as additional torques to its low-level controller which is compensating for gravity and the motor/transmission mechanics. This often feels frustrating, but probably we don't actually want to get into the details of simulating the drive mechanics.
As a result, the simplest reasonable simulation we can provide of the iiwa must include a simulation of their low-level controller. We will use the iiwa's "joint impedance control" mode, and will describe the details of that once they become important for getting the robot to perform better. For now, we can treat it as given, and produce our simplest reasonable iiwa simulation.
This example adds the iiwa controller and sets the desired positions (no longer the desired torques) to be the current state of the robot. It's a more faithful simulation of the real robot. I'm sorry that it is boring once again!
As a final note, you might think that simulating the dynamics of
the robot is overkill, if our only goal is to simulate manipulation tasks
where the robot is moving only relatively slowly, and effects of mass,
inertia and forces might be less important than just the positions that
the robot (and the objects) occupy in space. I would actually agree with
you. But it's surprisingly tricky to get a kinematic simulation to
respect the basic rules of interaction; e.g. to know when the object gets
picked up or when it does not (see, for instance
You might have noticed that the iiwa model does not actually have a hand attached; the robot ships with a mounting plate so that you can attach the "end-effector" of your choice (and some options on access ports so you can connect your end-effector to the computer without wires running down the outside of the robot). So now we have another decision to make: what hand should we use?
We can explore different hand models in Drake using the same sort of interface we used for the arms, though I don't have as many hand models here yet. Let me know if your favorite hand isn't on the list!
It is interesting that, when it comes to robot end effectors, researchers in manipulation tend to partition themselves into a few distinct camps.
Of course, our fascination with the human hand is well placed, and we
dream of building robotic hands that are as dexterous and sensor-rich.
But the reality is that we aren't there yet. Some people choose to pursue
this dream and work with the best dexterous hands on the market, and
struggle with the complexity and lack of robustness that ensues. The famous "learning dexterity" project from OpenAI used the Shadow hand for playing with a Rubik's cube, and the work that had to go into the hand in order to support the endurance learning experiments was definitely a part of the story. There is a chance that new manufacturing techniques could really disrupt this space -- videos like this one of FLLEX v2 look amazing
Another camp points out that dexterous hands are not necessary -- I can give you a simple gripper from the toy store and you can still accomplish amazingly useful tasks around the home. The PR1 videos above are a great demonstration of this.
Another important argument in favor of simple hands is the elegance and clarity that comes from reducing the complexity. If thinking clearly about simple grippers helps us understand more deeply why we need more dexterous hands (I think it will), then great. For most of these notes, a simple two-fingered gripper will serve our pedagogical goals the best. In particular, I've selected the Schunk WSG 050, which we have used extensively in our research over the last few years. We'll also explore a few different end-effectors in later chapters, when they help to explain the concepts.
To be clear: just because a hand is simple (few degrees of freedom) does not mean that it is low quality. On the contrary, the Schunk WSG is a very high-quality gripper with force control and force measurement at its single degree of freedom that surpasses the fidelity of the Kuka. It would be hard to achieve the same in a dexterous hand with many joints.
Finally, the third and newest camp is promoting clever mechanical designs for hands, which we'll call "underactuated hands", that can achieve some of the advantages of a human hand based on mechanics alone. But often these hands are amazingly good at some range of tasks (most often "enveloping grasps"), but not as general purpose. It would be very hard to use one of these to, for instance, button my shirt.
TODO: finish this section.
Suction, jamming grippers, tool-changers...`
TODO: finish this section.
I particularly liked the response that Matt Mason, one of the main advocates for simple grippers throughout the years, gave to a question at the end of one of our robotics seminars: he argued that useful robots in e.g. the kitchen will probably have special purpose tools that can be changed quickly.
One time I was attending an event where the registration form asked us "what is your favorite robot of all time, real or fictional". That is a tough question for someone who loves robots! But the answer I gave was a super cool "high-speed multifingered hand" by the Ishikawa group; a project that started turning out amazing results back in 2004! They "overclocked" the hand -- sending more current for short durations than would be reasonable for any longer applications -- and also used high-speed cameras to achieve these results. And they had a Rubik's cube demo, too, in 2017.
So good!
I haven't said much yet about sensors. In fact, sensors are going to be a major topic for us when we get to perception with (depth) cameras, and when we think about tactile sensing. But I will defer those topics until we need them.
For now, let us focus on the joint sensors on the robot. Both the iiwa and the Schunk WSG provide joint feedback -- the iiwa driver gives "measured position", "estimated velocity", and "measured torque" at each of its seven joints; remember that joint accelerations are typically considered too noisy to rely on. Similarly the Schunk WSG outputs "measured state" (position + velocity) and "measured force". We can make all of these available as ports in a block diagram.
If you've worked through the examples, you've seen that a proper simulation of our robot is more than just a physics engine -- it requires assembling physics, actuator and sensor models, and low-level robot controllers into a common framework. In practice, in Drake, that means that we are assembling increasingly sophisticated block diagrams.
One of the best things about the block-diagram modeling paradigm is the
power of abstraction and encapsulation. We can assemble a
Diagram
that contains all of the components necessary to
simulate our hardware platform and its environment, which we will refer to
affectionately as the "Manipulation Station". This diagram itself can then
be used as a System
in additional diagrams, which can include
our perception, planning, and, higher-level control systems. All together,
the ManipulationStation
system looks like this:
This model also defines the abstraction between the simulation and the
real hardware. We offer an almost identical system, the
ManipulationStationHardwareInterface
. If you replace this
directly in place of the ManipulationStation
, then the same
code you've developed in simulation can be run directly on the real robot.
The ports that are available only in simulation, but not in reality, are
colored orange on the
ManipulationStation
system.
 If you dig under
the covers, you will see that we use LCM for this instead of ROS messages,
precisely because LCM is a lighter-weight dependency for our public
repository. But many Drake developers/users use Drake in a ROS ecosystem; we
have examples/coverage ensuring that our build systems remain compatible here,
and are working on curating well-maintained tutorials for users who want that
workflow.
If you do have your own similar robot hardware available, and want to run the hardware interface on your machines, I've started putting together a list of drivers and bill of materials in the appendix.
For this exercise you will investigate the effect of reflected inertia on the joint-space dynamics of the robot, and how it affects simple position control laws. You will work exclusively in this notebook. You will be asked to complete the following steps:
For this exercise you will investigate how a manipulation station is abstracted in Drake's system-level framework. You will work exclusively in this notebook. You will be asked to complete the following steps:
| Previous Chapter | Table of contents | Next Chapter |


Fly with Taylor Today! Anywhere within the Tri State Area for an affordable price
Your Flight is booked, Louis Pasteur
Digital Booking Reference If you have a Digital Credential Wallet, you can save time and money by checking in with a Digital Booking Reference from Taylor Chartered Flight.
Click Here to collect your Digital Booking Reference.


Currently the model sits at approximately 52% accuracy. This shows that it is not very likely to be able to fully predict on lyric data alone. This can be due to a few different impacts. For instance, further subgenres (Metal or rock, Rap and hip hop separated, classic country versus modern) could show deeper trends that can make the model more accurate. The genre categorization could also be heavily disputed, as it was based on categories provided from the lyric source.
The genre-based lyrics were web scraped from www.songlyrics.com. From there, the lyrics based on each individual song was tokenized to individual words utilizing python repository nltk (Natural Language ToolKit). nltk also allowed for removal of "stop" words, such as "and", "of", "in", etc to allow for the identification of more unique word use. Both counts of words with stop words and without stop words were calculated. finally, a count of words considered negative, positive, and neutral was made utilizing nltk and a lexicon of positive and negative words identified in a cambridge university study.
Based on the provided data, lyrics alone show a huge cluster of similar points. The more common spread out category is Hip Hop/Rap, hence why the most common return is that category. Other useful data that could be considered to increase the accuracy of the model is beats per minutes, types of instruments, and possibly the gender of the singer.


It looks there was an internal server error, which is fancy scientist talk for something bad happened.
To the homepage! *vrooom*


Our Website
Home Page
New Arrivals
Men's Apparel
Men's Suits
Men's Blazers/Jackets
Men's Pants
Men's Shoes
Men's Outerwear
Men's Casualwear
Women's Apparel
Women's Blouses/Tops
Women's Blazers/Jackets
Women's Dresses
Women's Skirts/Leggings
Women's Outerwear
Women's Casualwear
Accessories
Ties
Socks
Jewellery
Wallets
Hats/Headwear
Gloves
Sales and Promotions
About Northern Threads
Our Story
Our Guarantee
Career Opportunities
My Orders
Track My Order
Shipping Policy
Return Policy
Our Site
Languages
Terms and Conditions
Privacy Policy
Accessibility
Help
FAQ
Sizing Charts
Site map
Contact Us
Store Locator
Customer Service
Northern Threads © 2017


Accenture LOGO
About Us
Locations
Contact us
Submit
Forgot Password?
×
Forgot password?
Send
Password sent successfully


The regression discontinuity (RD) design is a popular quasi-experimental design for causal inference and policy evaluation. Under the local randomization approach, RD designs can be interpreted as randomized experiments inside a window around the cutoff. This package provides tools to perform randomization inference for RD designs under local randomization: rdrandinf() to perform hypothesis testing using randomization inference, rdwinselect() to select a window around the cutoff in which randomization is likely to hold, rdsensitivity() to assess the sensitivity of the results to different window lengths and null hypotheses and rdrbounds() to construct Rosenbaum bounds for sensitivity to unobserved confounders.
| Version: | 0.3 |
| Depends: | R (≥ 3.1) |
| Imports: | AER, sandwich |
| Published: | 2018-03-15 |
| Author: | Matias D. Cattaneo, Rocio Titiunik, Gonzalo Vazquez-Bare |
| Maintainer: | Gonzalo Vazquez-Bare <gvazquez at umich.edu> |
| License: | GPL-2 |
| NeedsCompilation: | no |
| In views: | Econometrics |
| CRAN checks: | rdlocrand results |
| Reference manual: | rdlocrand.pdf |
| Package source: | rdlocrand_0.3.tar.gz |
| Windows binaries: | r-devel: rdlocrand_0.3.zip, r-release: rdlocrand_0.3.zip, r-oldrel: rdlocrand_0.3.zip |
| OS X binaries: | r-release: rdlocrand_0.3.tgz, r-oldrel: rdlocrand_0.3.tgz |
| Old sources: | rdlocrand archive |
Please use the canonical form https://CRAN.R-project.org/package=rdlocrand to link to this page.


How would rate your experience with Polymer?
Novice
Intermediate
Advanced
How will you use use this tutorial?
I won't
Complete it


The Main form
This is the base form. It allows the user to hang around the interest tree. For each selected interest, the list of advisors and the list of articles appear immediately. A double click on a certain article lets the user read the article itself.
The menu bar on the top of the form contains three items: View, Options, Help. The "Options" item holds 4 basic functions: it allows the user sort advisors and messages. Options->favorites allows to change settings in the User Profile (favorite interests and favorite advisors). Options->filter lets set additional limitations to the advisor set and message set.
The tool bar has been set for the user's convenience. Here are some functions it holds:
By default, all the messages responding to the chosen interests and advisors will be reported to the user. If the user wishes to set additional conditions for the message set, he/she has to choose "Filter" item in the Menu to enter advanced preferences.


Label: {{ this.name }}
{{this.description}}
Posts
{% if this.children %}
{{ render_post_list(this.children, this.name) }}
{%else%}
No posts in label {{this.name}} yet. May be there is a draft in the works.
{% endif %}


What is the output in the console?
What is the output in the console?
What is the output in the console?
What is the output in the console?
What is the output in the console?
What is the output in the console?
What is the output in the console?
What is the output in the console?
What is the output in the console?
What is the output in the console?
What is the output in the console?
What is the output in the console?
For more Javascript Date details see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date
What is the output in the console?
For more Javascript Date details see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp
JSON = Javascript Object Notation
- Every JavaScript Object has a "prototype" property.
- The prototype property is simply an object.
The Object.defineProperty() method defines a new property directly on an object, or modifies an existing property on an object, and returns the object.


--- layout: post title: Pattern Specification author: rpierlot date: '2016-09-16 11:24:46 +0200' date_gmt: '2016-09-16 09:24:46 +0200' categories: - Non classé tags: [] --- {% raw %}
Through my different professional experiences, I had to set a lot of business rules in rich web apps. One day, I stumbled upon a different way to deal with those: using the specification pattern. This method has proven to be structuring and deserves some attention if you do not know what it is.
Imagine a simple banking application for instance. This app only has clients and bank accounts. A client can have one or multiple accounts, and your job is to create a very simple system of wire transfer between accounts of a same client with this business rule:
You can clearly see the condition which would prevent a transfer from happening.
In a simple implementation, you would write it this way:
<?php namespace ElevenLabs\Application; use ElevenLabs\Domain\Payment\Entity\Account; class TransferMoneyCommand { /** * @param Amount $accountToDebit * @param Amount $accountToCredit * @param float $amount */ public function execute(Account $accountToDebit, Account $accountToCredit, $amount) { if ($accountToDebit->getBalance() - $amount > 0 && $accountToDebit->getOwner()->isActive()) { //transfer authorized //... } } }
This business rule, although trivial, needs to be implemented every time we want to do a wire transfer.
Many constraints arise from such implementation.
First off, if our business rule evolves, we have to change the (or all) class that uses it. Then, this implementation in a if statement is really not explicit at all.
This is where the specification pattern comes into play. The main idea is to isolate the business rule, separating it from its use. It's used for validation, selection and building of business logic.
Mainly three types of specification exist:
A specification is driven by the following interface:
<?php namespace ElevenLabs\Domain; interface Specification { /** * @param $candidate * * @return bool */ public function isSatisfiedBy($candidate); }
This type of specification enables us to hard code the business knowledge without having the possibility to modify the business rule from the outside.
A business rule can then be translated this way:
<?php namespace ElevenLabs\Domain\Payment; use ElevenLabs\Domain\Specification; class AccountCanTransferMoney implements Specification { /** * @param \ElevenLabs\Domain\Payment\Entity\Account $account * * @return boolean */ public function isSatisfiedBy($account) { return $account->getBalance() > 0 && $account->getOwner()->isActive(); } }
Having created a separated class in order to apply our business rule, we gain clarity and decoupling. Although, it appears obvious that we are condemned to only using our object $account, and that no additional info can be brought from the outside. We still can't use this type of specification in our TransferMoneyCommand because it does not comply totally to our business rule (only the balance is compared).
Parameterized specifications are identical to what we've been talking about, but they resolve the issue we've just mentioned, allowing us to get outside parameters to our candidate.
<?php namespace ElevenLabs\Domain\Payment; use ElevenLabs\Domain\Specification; class AccountCanTransferMoney implements Specification { /** @var float */ private $amount; /** * @param float $amount */ public function __construct($amount) { $this->amount = $amount; } /** * @param \ElevenLabs\Domain\Payment\Entity\Account $account * * @return boolean */ public function isSatisfiedBy($account) { return $account->getBalance() - $this->amount > 0 && $account->getOwner()->isActive(); } }
With this type of specifications, we keep the same pros as before, and we gain flexibility.
This is how our command would look like using our parameterized specification:
<?php namespace ElevenLabs\Application; use ElevenLabs\Domain\Payment\Entity\Account; use ElevenLabs\Domain\Payment\Specification\AccountCanTransferMoney; class TransferMoneyCommand { /** * @param Account $accountToDebit * @param Account $accountToCredit * @param float $amount */ public function execute(Account $accountToDebit, Account $accountToCredit, $amount) { $accountCanTransferMoney = new AccountCanTransferMoney($amount); if (true === $accountCanTransferMoney->isSatisfiedBy($accountToDebit)) { //transfer authorized //... } } }
To simplify my explanation on parameterized specifications, I've hard coded the instantiation of the class AccountCanTransferMoney. A noticeable improvement of this use would be to inject the specification directly into the command, in order to better unit test our command.
The last type of specification I'd like to take a look into is composite specifications. Such specification bases itself on what we've seen. Indeed, it uses composition to exist. Logical operations between two (or more) specifications are part of composite specifications.
The following example explains the implementation of the AND logical operator:
<?php namespace ElevenLabs\Domain; abstract class Composite implements Specification { /** * {@inheritdoc} */ abstract public function isSatisfiedBy($candidate); /** * @param Specification $spec * * @return AndSpecification */ public function andIsSatisfiedBy(Specification $spec) { return new AndSpecification($this, $spec); } //... } class AndSpecification extends Composite { /** @var Specification */ private $a; /** @var Specification */ private $b; /** * @param Specification $a * @param Specification $b */ public function __construct(Specification $a, Specification $b) { $this->a = $a; $this->b = $b; } /** * {@inheritdoc} */ public function isSatisfiedBy($candidate) { return $this->a->isSatisfiedBy($candidate) && $this->b->isSatisfiedBy($candidate); } }
Then, if we instantiate a composite spec, we can chain it to other specifications (see below), by modifying our previous AccountCanTransferMoney specification:
<?php namespace ElevenLabs\Domain\Payment; use ElevenLabs\Domain\Composite; class AccountCanTransferMoney extends Composite { /** @var float */ private $amount; /** * @param float $amount */ public function __construct($amount = 0) { $this->amount = $amount; } /** * @param \ElevenLabs\Domain\Payment\Entity\Account $account * * @return boolean */ public function isSatisfiedBy($account) { return $account->getBalance() - $this->amount > 0; } }
<?php namespace ElevenLabs\Domain\Payment\Specification; use ElevenLabs\Domain\Specification; class AccountOwnerIsActive implements Specification { /** * @param \ElevenLabs\Domain\Payment\Entity\Account $account * * @return boolean */ public function isSatisfiedBy($account); { return $account->getOwner()->isActive(); } }
Finally, here is how we use our composition:
<?php namespace ElevenLabs\Application; use ElevenLabs\Domain\Payment\Entity\Account; use ElevenLabs\Domain\Payment\Specification\AccountCanTransferMoney; class TransferMoneyCommand { /** * @param Account $accountToDebit * @param Account $accountToCredit * @param float $amount */ public function execute(Account $accountToDebit, Account $accountToCredit, $amount) { $accountCanTransferMoney = new AccountCanTransferMoney($amount); $accountOwnerIsActive = new AccountOwnerIsActive(); $compositeSpecification = $accountCanTransferMoney->andIsSatisfiedBy($accountOwnerIsActive); if (true === $compositeSpecification->isSatisfiedBy($accountToDebit)) { //transfer authorized //... } } }
The advantages of this type of specifications are obviously the support of logical operator, and therefore the creation of even more complex business rules. It's now possible to combine specifications. Flexibility is improved, but beware of additional complexity!
Advantages of the specification pattern are as follow:


Woman screams for help in possible L.A. kidnapping
by CNN NewsourceA Los Angeles doorbell camera captured the gut-wrenching screams of a woman police say they believe may have been kidnapped, but it did not capture images of what caused her calls for help.
Witnesses in the Leimert Park neighborhood called Los Angeles police Tuesday to report hearing a woman screaming, according to an LAPD news release.
"Help me," a woman's voice can be heard screaming in the footage, which shows only a dark street from a porch. "Somebody help me, please."
A car then races into and out of the frame.
Witnesses saw what police say may be a four-door, white Toyota Prius with plastic wrap over the front passenger side window speed off with two people inside.
The driver, described as male, was pulling the hair back of a woman with dark braided hair in the passenger seat as she screamed, a witness reported to LAPD.
The driver was heard shouting, "I'm sorry, I'm sorry," police said.
"If you have seen or have any information regarding the identity of the female or male in the video, please contact Southwest Area Detectives at<PHONE_NUMBER>," police said.


The Groups module works together with the User Manager and the Permissions module to give PyroCMS access control.
Give your group a name (usually lowercase) and a short description. Now use the Permissions module to control what this group's users can access.


This sample the usage of Citrus test behaviors when sending and receiving messages to the todo sample application. Read about test behaviors in reference guide
Objectives
The todo-list sample application provides a REST API for managing todo entries. We call this API and receive Json message structures for validation in our test cases.
This time we want to reuse specific message exchange logic by using test behaviors in our tests. The test behavior is a class that provides a set of test actions for reuse in other test cases. A typical test behavior looks like this:
public class HelloBehavior extends AbstractTestBehavior {
private final String name;
public HelloBehavior(String name) {
this.name = name;
}
@Override
public void apply() {
echo("Hello " + name);
}
}
The behavior extends AbstractTestBehavior
and defines its logic in the apply method where you can use all Citrus Java fluent API methods as you would do in a normal test.
The behavior is then applied in your test as follows:
@Test
@CitrusTest
public void testHelloBehavior() {
applyBehavior(new HelloBehavior("Howard"));
applyBehavior(new HelloBehavior("Leonard"));
applyBehavior(new HelloBehavior("Penny"));
}
The sample above applies the behavior in the test multiple times with different names. The result will be multiple echo test actions that print out the messages to the console logging. Now we can use behaviors in order to add new todo entries via Http POST request.
public class AddTodoBehavior extends AbstractTestBehavior {
private String payloadData;
private Resource resource;
@Override
public void apply() {
HttpClientRequestActionBuilder request = http()
.client(todoClient)
.send()
.post("/api/todolist")
.messageType(MessageType.JSON)
.contentType(ContentType.APPLICATION_JSON.getMimeType());
if (StringUtils.hasText(payloadData)) {
request.payload(payloadData);
} else if (resource != null) {
request.payload(resource);
}
http()
.client(todoClient)
.receive()
.response(HttpStatus.OK)
.messageType(MessageType.PLAINTEXT)
.payload("${todoId}");
}
AddTodoBehavior withPayloadData(String payload) {
this.payloadData = payload;
return this;
}
AddTodoBehavior withResource(Resource resource) {
this.resource = resource;
return this;
}
}
As you can see the behavior provides support for Json payload inline data as well as file resource payloads. You can use the behavior in test then as follows:
@Test
@CitrusTest
public void testJsonPayloadValidation() {
variable("todoId", "citrus:randomUUID()");
variable("todoName", "citrus:concat('todo_', citrus:randomNumber(4))");
variable("todoDescription", "Description: ${todoName}");
variable("done", "false");
applyBehavior(new AddTodoBehavior()
.withPayloadData("{ \"id\": \"${todoId}\", \"title\": \"${todoName}\", \"description\": \"${todoDescription}\", \"done\": ${done}}"));
applyBehavior(new AddTodoBehavior()
.withResource(new ClassPathResource("templates/todo.json")));
}
The behavior is reused multiple times with different payload input. Now we can add more behaviors for getting todo entries via Http GET requests.
public class GetTodoBehavior extends AbstractTestBehavior {
private String payloadData;
private Resource resource;
private Map<String, Object> validateExpressions = new LinkedHashMap<>();
@Override
public void apply() {
http()
.client(todoClient)
.send()
.get("/api/todo/${todoId}")
.accept(ContentType.APPLICATION_JSON.getMimeType());
HttpClientResponseActionBuilder response = http()
.client(todoClient)
.receive()
.response(HttpStatus.OK)
.messageType(MessageType.JSON);
if (StringUtils.hasText(payloadData)) {
response.payload(payloadData);
} else if (resource != null) {
response.payload(resource);
}
validateExpressions.forEach(response::validate);
}
GetTodoBehavior validate(String payload) {
this.payloadData = payload;
return this;
}
GetTodoBehavior validate(Resource resource) {
this.resource = resource;
return this;
}
GetTodoBehavior validate(String expression, Object expected) {
validateExpressions.put(expression, expected);
return this;
}
}
This time the behavior provides different approaches how to validate the todo entry that was sent as a Json response payload. We can use payload inline data, file resource and JsonPath expressions:
applyBehavior(new GetTodoBehavior()
.validate("$.id", "${todoId}")
.validate("$.title", "${todoName}")
.validate("$.description", "${todoDescription}")
.validate("$.done", false));
This completes the usage of test behaviors in Citrus. This is a great way to centralize common tasks in your project to reusable pieces of Citrus Java DSL code.
Run
You can execute some sample Citrus test cases in this sample in order to write the reports. Open a separate command line terminal and navigate to the sample folder.
Execute all Citrus tests by calling
mvn integration-test
You should see Citrus performing several tests with lots of debugging output.
And of course green tests at the very end of the build and some new reporting files in target/citrus-reports
folder.
Of course you can also start the Citrus tests from your favorite IDE. Just start the Citrus test using the TestNG IDE integration in IntelliJ, Eclipse or Netbeans.


The Android-x86 4.4-r5 is a bugfix of the 4.4-r4 release. It addresses more hazi fonts issue of Mesa 10.5.9 found on Intel Gen5 GPUs. You are encouraged to upgrade to this release if you still encountered the hazi fonts issue.
This release contains one file. The file is bootable in devices with legacy BIOS as well as UEFI firmware.
sha1sum: 4c0edceef12bf4b8afb1b8390d94a9af29bbbca8
The file can be dumped into a usb drive to get a bootable usb stick, like
dd if=android-x86-4.4-r5.iso of=/dev/sdX
where /dev/sdX is the device name of your usb drive.
repo sync
Read this page for how to compile source code.


Predict Fruit Using AI
{% if prediction_text == 1%}
Fruit name should be Apple
{% elif prediction_text == 2%}
Fruit name should be Mandarin
{% elif prediction_text == 3%}
Fruit name should be Orange
{% elif prediction_text == 4%}
Fruit name should be Lemon
{% endif %}


Alloy - Drawing Demo
Linear
Ease In
Ease Out
Ease In and Out
Bounce
Elastic
Back In
Back Out
Linear
Ease In
Ease Out
Ease In and Out
Bounce
Elastic
Back In
Back Out
Run


Gerald Kaufman's panel show appearances
Gerald Kaufman (born 1930-06-21[ref]) has appeared in 27 episodes between 1980-2003. Gerald Kaufman on IMDB. Gerald Kaufman on Wikipedia.
- 2003-10-30 / Question Time
- 2002-10-25 / Have I Got News For You
- 2001-10-11 / Question Time
- 2000-02-24 / Question Time
- 1999-06-17 / Question Time
- 1998-04-23 / Question Time
- 1995-07-06 / Out Of Order
- 1995-06-08 / Out Of Order
- 1994-05-19 / Question Time
- 1993-11-12 / Have I Got News For You
- 1993-06-03 / Question Time
- 1992-02-13 / Question Time
- 1991-01-17 / Question Time
- 1991-01-10 / Question Time
- 1990-12-06 / Question Time
- 1990-09-27 / Question Time
- 1989-10-12 / Question Time
- 1988-11-10 / Question Time
- 1987-12-10 / Question Time
- 1986-09-25 / Question Time
- 1986-01-23 / Question Time
- 1985-05-23 / Question Time
- 1984-05-03 / Question Time
- 1983-03-17 / Question Time
- 1982-01-28 / Question Time
- 1981-03-26 / Question Time
- 1980-02-28 / Question Time


http://orwelldevcpp.blogspot.com
Tools -> Compiler Options
F11
.File -> New -> Source File
(or Ctrl+N
)
|
|
File -> Save As...
(or Ctrl+Alt+S
).cpp
extension, such as example.cpp
.F11
should compile and run the program.x
, the compiler does not understand the new meaning given to auto
since C++11. Please, make sure you downloaded the latest version as linked above, and that you enabled the compiler options to compile C++11 as described above.


DfE enquiries
Central newsdesk 020 7783 8300
General enquiries 0370 000 2288
Press release
New figures show what young people went on to do after leaving school or college.
Parents and students can now see for themselves how successful their schools and colleges are at ensuring young people fulfil their potential, including how many progress on to top universities, thanks to new government data published today.
The destinations data is published so parents and students can make informed judgements about the performance of schools and colleges in their areas.
Today’s figures reveal what young people went on to do after leaving school or college in 2011. The data captures how many go on to attend university, begin apprenticeships or training, or embark on a career.
Schools Minister David Laws said:
We are publishing this data so people can see for themselves how different schools, colleges and local authorities perform. It is right that parents have as much information as possible on which to base decisions for their children’s education.
Some students will be aiming to get a job after college, others will be hoping to win a place at a great university. But all schools and colleges must ensure they deliver for all their students - whatever that student’s target.
Many schools are excelling at this, including Mossbourne Community Academy in Hackney - one of the most deprived parts of the country. Today’s figures show Mossbourne sent 7% of its pupils to Oxbridge in 2011 to 2012, making it one of the top state performers.
And Birkenhead High School Academy, an all-girls school in the Wirral, Merseyside, sent 38% of its students to Russell Group universities - way above the national average of 11% for state schools.
The government has a package of measures to help young people get the best possible start in life. This includes:
Alongside the destinations of those leaving mainstream state education, today’s figures are the first to measure the destinations of students from independent schools, special schools and pupil referral units or other alternative provision. This reinforces the importance of ensuring all providers are held to account for helping their pupils fulfil their potential.
Central newsdesk 020 7783 8300
General enquiries 0370 000 2288
Published: 26 June 2014


{% extends "layout.html" %} {% block title %}Zero-OS Hub{% endblock %} {% block content %}
Do you want to publish your Zero-OS flist to our hub? It's easy.
All you need is a .tar.gz
archive of your files and upload it here. Simple.
| Repository |
|---|
| Loading repositories... |
| Username |
|---|
| Loading users... |


Under Armour faces federal probe over accounting practices: WSJ
REUTERS: Under Armour is being probed by U.S. federal law enforcement officials, examining whether the sportswear maker shifted sales from quarter to quarter to appear healthier, the Wall Street Journal reported on Sunday.
A criminal Inquiry is being conducted by U.S. Justice Department prosecutors, who are also coordinating with civil investigators at the U.S. Securities and Exchange Commission, the report added, citing a source.
Under Armour did not immediately respond to a request seeking comment outside regular business hours.
Last month, Under Armour said longtime Chief Executive Officer Kevin Plank was stepping down from the role next year, handing the reins of the sportswear maker to operations head Patrik Frisk, in an attempt to help battle brutal competition from Nike Inc and Adidas AG in the United States.


An artist since childhood, Dawn Walker has made her life a quest for
beauty - in people, in her community, in the larger world and earth
around us. Her pastel paintings glow with color while providing tranquility
and peace of mind. "We're so busy in the world," she
explains. "No one has time to stop and really look at God’s
creations. I paint what God put here."
When she discovered the lavender fields of France, Dawn knew she had
come to her spiritual home.
ORIGINALS
TITLE: BOAT
Oil on Canvas
10"x15"
$150.00
TITLE: EARLYBIRDS
Oil on Canvas
10"x15"
$150.00
TITLE: LAVENDERFIELD
Oil on Canvas
10"x25"
$150.00
TITLE: LILY BRIDGE
Oil on Canvas
10"x15"
$150.00
TITLE: ROBIN
Oil on Canvas
10"x15"
$150.00
TITLE: SUNLIGHT PATH
Oil on Canvas
10"x15"
$150.00
TITLE: TRELLIS
Oil on Canvas
10"x15"
$150.00
TITLE: URN
Oil on Canvas
10"x15"
$150.00
TITLE: VINES
Oil on Canvas
10"x15"
$150.00


Measure calculation script which takes a list of data item as input and return a measure result.
Variables:


We will begin by defining a simple service that performs a very basic
task: translate a string of DNA into the corresponding protein characters.
We assume here that you have either constructed a development container and have sourced its user-env file, or you are operating using a pre-built KBase deployment and have sourced its user-env file.
To begin we need to define the interface to the service. It will ingest a string of DNA characters and emit a string of protein characters. We use the string type in the type language:
module MyFirstService {
typedef string DNAString;
typedef string ProteinString;
funcdef translate_dna(DNAString dna) returns (ProteinString prot);
};
Create a file my_service.spec that contains the text above, and run the type compiler to generate output:
$ compile_typespec --psgi service.psgi my_service.spec my_service my_service.spec: module MyFirstService service MyFirstService
This will generate the service code in the directory specified as the last argument:
$ ls my_service MyFirstServiceClient.js MyFirstServiceClient.py MyFirstServiceImpl.py MyFirstServiceServer.py MyFirstServiceClient.pm MyFirstServiceImpl.pm MyFirstServiceServer.pm service.psgi
Note that the files created are named using the module name defined in
the interface document.
The files created include client libraries in Perl, Python, and Javascript (MyFirstServiceClient), server interface libraries in Perl and Python (MyFirstServiceServer), implementation files for Perl and Python (MyFirstServiceImpl), and a service startup program (service.psgi).
At this stage we have a complete service, although it does not do
anything useful. We can still start a server to host the service, however.
For this we will use the plackup
command that is part of the
installed Perl runtime code in the KBase environment:
$ plackup --listen :9999 service.psgi
HTTP::Server::PSGI: Accepting connections at http://0:9999/
The --listen
parameter defines the TCP port that the
service will listen on. Don't forget to include the colon before the port
number.
A python development server can be started by executing the MyFirstServiceServer.py file, with the --port parameter to specify a port.
$ python MyFirstServiceServer --port 9999
Listening on port 9999
Now we need to invoke the service. The type compiler is able to generate
command-line programs that invoke service routines that have scalar
arguments. You can generate these by adding the --scripts
flag
to the compiler:
compile_typespec --scripts my_service --psgi service.psgi my_service.spec my_service
$ ls my_service MyFirstServiceClient.js MyFirstServiceClient.py MyFirstServiceImpl.py MyFirstServiceServer.py simple_translate_dna.pl MyFirstServiceClient.pm MyFirstServiceImpl.pm MyFirstServiceServer.pm service.psgi translate_dna.pl
Note we have two new files, translate_dna.pl and simple_translate_dna.pl. Disregard translate_dna.pl for the moment - it is a skeleton for a CDM-style command line script that we won't further investigate. If you look at simple_translate_dna.pl you will find a script that expects to get a single parameter, a DNA string, and prints the JSON form of the output (this is currently quite crude but not in its final form):
$ cd my_service
$ perl simple_translate_dna.pl
Usage: translate_dna [--port port] [--url url] dna
It also expects to receive an option that defines the location of the service it should use. This can take the form of either a full service URL or a port number. If you use a port number it expects to find the service on the local machine. We can try this now. Start the service using plackup as described above (it is useful to do this in a separate window), and then run the translation script:
$ perl simple_translate_dna.pl --port 9999 ccctag
[null]
Note that we don't receive a valid return. This makes sense, as we have not yet implemented the service.
In your window where plackup is running you will see a log of this request:
<IP_ADDRESS> - - [12/Dec/2012:07:35:29 -0800] "POST / HTTP/1.1" 200 33 "-" "JSON::RPC::Client/0.93 beta libwww-perl/6.04"
We may now implement the service itself. Open MyFirstServiceImpl.pm (MyFirstServiceImpl.py for Python) in an editor. This module is invoked by the service handling code when a request for a service method is received. Each service method is represented by a function in the implementation file. You will find the translation routine to look something like this:
sub translate_dna { my $self = shift; my($dna) = @_; my @_bad_arguments; (!ref($dna)) or push(@_bad_arguments, "Invalid type for argument \"dna\" (value was \"$dna\")"); if (@_bad_arguments) { my $msg = "Invalid arguments passed to translate_dna:\n" . join("", map { "\t$_\n" } @_bad_arguments); Bio::KBase::Exceptions::ArgumentValidationError->throw(error => $msg, method_name => 'translate_dna'); } my $ctx = $MyFirstServiceServer::CallContext; my($prot); #BEGIN translate_dna #END translate_dna my @_bad_returns; (!ref($prot)) or push(@_bad_returns, "Invalid type for return variable \"prot\" (value was \"$prot\")"); if (@_bad_returns) { my $msg = "Invalid returns passed to translate_dna:\n" . join("", map { "\t$_\n" } @_bad_returns); Bio::KBase::Exceptions::ArgumentValidationError->throw(error => $msg, method_name => 'translate_dna'); } return($prot); }
def translate_dna(self, dna): # self.ctx should be set by the wsgi application class # return variables are: prot #BEGIN translate_dna #END translate_dna if not isinstance(prot, basestring): raise ValueError('Method translate_dna return value prot is not type basestring as required.') # return the results return [ prot ]
There is a lot of boilerplate in there that you need not understand (it is type checking code). The key part is this pair of comments:
#BEGIN translate_dna #END translate_dna
Your code will go in between the comments. Leave the comments in place -
they are used by the type compiler to retain your code in the file when
the compiler is rerun. The DNA option appears as the variable $dna
.
The return value will be placed into the variable $prot.
These names are taken directly from the funcdef statement in your service
specification file.
We will use a simple translation module; the Perl and Python code for this is in the Appendix. Copy and paste the code from the appendix into a file called trans.pm (trans.py) and place that file in the my_service directory next to the other compiler-generated files.
Our implementation of the translation code itself is trivial:
#BEGIN translate_dna $prot = translate($dna); #END translate_dna
#BEGIN translate_dna prot = translate(dna) #END translate_dna
However, we do need to include the translation module. Near the top of the implementation file you will find a pair of comments:
#BEGIN_HEADER #END_HEADER
Code placed between these comments will be retained across compiles.
Place a use statement for our translation utility module there:
#BEGIN_HEADER use trans; #END_HEADER
#BEGIN_HEADER from trans import translate #END_HEADER
Kill (^C) and restart your plackup session so that it picks up the new implementation code. We may now test the service:
$ perl simple_translate_dna.pl --port 9999 ATGACAGCGCAAGAAAAACTCTACCAACTAATTCAAACTCTGCCAGAGA ["MTAQEKLYQLIQTLPE"]
We see that we have received a single item from the call, and it is a reasonable protein translation of that DNA string.
SERVICE_NAME = MyFirstService
compile_typespec
-impl Bio::KBase::$(SERVICE_NAME)::Impl \
-service Bio::KBase::$(SERVICE_NAME)::Service \ -client Bio::KBase::$(SERVICE_NAME)::Client \ -js $(SERVICE_NAME) \
-py $(SERVICE_NAME) \
my_service.spec lib
funcdef translate_dna_strings(list<DNAString> dna_list)
returns (list<ProteinString> prot_list)
sub translate { my($dna) = @_; my($i, $j, $ln); my($x, $y); my($prot); my $code = &standard_genetic_code(); $ln = length($dna); $prot = "X" x ($ln/3); $dna =~ tr/a-z/A-Z/; for ($i=0,$j=0; ($i < ($ln-2)); $i += 3,$j++) { $x = substr($dna,$i,3); if ($y = $code->{$x}) { substr($prot,$j,1) = $y; } } if (($start) && ($ln >= 3) && (substr($dna,0,3) =~ /^[GT]TG$/)) { substr($prot,0,1) = 'M'; } return $prot; } sub standard_genetic_code { my $code = {}; $code->{"AAA"} = "K"; $code->{"AAC"} = "N"; $code->{"AAG"} = "K"; $code->{"AAT"} = "N"; $code->{"ACA"} = "T"; $code->{"ACC"} = "T"; $code->{"ACG"} = "T"; $code->{"ACT"} = "T"; $code->{"AGA"} = "R"; $code->{"AGC"} = "S"; $code->{"AGG"} = "R"; $code->{"AGT"} = "S"; $code->{"ATA"} = "I"; $code->{"ATC"} = "I"; $code->{"ATG"} = "M"; $code->{"ATT"} = "I"; $code->{"CAA"} = "Q"; $code->{"CAC"} = "H"; $code->{"CAG"} = "Q"; $code->{"CAT"} = "H"; $code->{"CCA"} = "P"; $code->{"CCC"} = "P"; $code->{"CCG"} = "P"; $code->{"CCT"} = "P"; $code->{"CGA"} = "R"; $code->{"CGC"} = "R"; $code->{"CGG"} = "R"; $code->{"CGT"} = "R"; $code->{"CTA"} = "L"; $code->{"CTC"} = "L"; $code->{"CTG"} = "L"; $code->{"CTT"} = "L"; $code->{"GAA"} = "E"; $code->{"GAC"} = "D"; $code->{"GAG"} = "E"; $code->{"GAT"} = "D"; $code->{"GCA"} = "A"; $code->{"GCC"} = "A"; $code->{"GCG"} = "A"; $code->{"GCT"} = "A"; $code->{"GGA"} = "G"; $code->{"GGC"} = "G"; $code->{"GGG"} = "G"; $code->{"GGT"} = "G"; $code->{"GTA"} = "V"; $code->{"GTC"} = "V"; $code->{"GTG"} = "V"; $code->{"GTT"} = "V"; $code->{"TAA"} = "*"; $code->{"TAC"} = "Y"; $code->{"TAG"} = "*"; $code->{"TAT"} = "Y"; $code->{"TCA"} = "S"; $code->{"TCC"} = "S"; $code->{"TCG"} = "S"; $code->{"TCT"} = "S"; $code->{"TGA"} = "*"; $code->{"TGC"} = "C"; $code->{"TGG"} = "W"; $code->{"TGT"} = "C"; $code->{"TTA"} = "L"; $code->{"TTC"} = "F"; $code->{"TTG"} = "L"; $code->{"TTT"} = "F"; return $code; } 1;
""" Python version of the KBase DNA translation example code """ code = { "AAA" : "K", "AAC" : "N", "AAG" : "K", "AAT" : "N", "ACA" : "T", "ACC" : "T", "ACG" : "T", "ACT" : "T", "AGA" : "R", "AGC" : "S", "AGG" : "R", "AGT" : "S", "ATA" : "I", "ATC" : "I", "ATG" : "M", "ATT" : "I", "CAA" : "Q", "CAC" : "H", "CAG" : "Q", "CAT" : "H", "CCA" : "P", "CCC" : "P", "CCG" : "P", "CCT" : "P", "CGA" : "R", "CGC" : "R", "CGG" : "R", "CGT" : "R", "CTA" : "L", "CTC" : "L", "CTG" : "L", "CTT" : "L", "GAA" : "E", "GAC" : "D", "GAG" : "E", "GAT" : "D", "GCA" : "A", "GCC" : "A", "GCG" : "A", "GCT" : "A", "GGA" : "G", "GGC" : "G", "GGG" : "G", "GGT" : "G", "GTA" : "V", "GTC" : "V", "GTG" : "V", "GTT" : "V", "TAA" : "*", "TAC" : "Y", "TAG" : "*", "TAT" : "Y", "TCA" : "S", "TCC" : "S", "TCG" : "S", "TCT" : "S", "TGA" : "*", "TGC" : "C", "TGG" : "W", "TGT" : "C", "TTA" : "L", "TTC" : "F", "TTG" : "L", "TTT" : "F" } def translate( dna ): dna = dna.upper() prot = "" for i in range( len(dna)/3 ): x=dna[ (i * 3):(i * 3) + 3 ] prot += code.get(x,"X") return prot


Kasey Le is a CS co-term completing a dual-depth in Information Management and Analytics and HCI. She took Bootcamp at the d.school last quarter and absolutely loved it and wanted to learn more about HCI and human-centered design.


|
App Engine Python SDK
v1.6.9 rev.445
The Python runtime is available as an experimental Preview feature.
|
Public Member Functions | |
| def | __init__ |
| def | get_job_by_id |
| def | get_status |
| def | abort |
| def | get_counters |
| def | get_counter |
| def | get_outputs |
| def | submit |
Public Attributes | |
| job_config | |
The job submitter's view of the job. The class allows user to submit a job, control a submitted job, query its state and result.
| def google.appengine.ext.mapreduce.api.map_job.map_job_control.Job.__init__ | ( | self, | |
state = None |
|||
| ) |
Init the job instance representing the job with id job_id. Do not directly call this method. Use class methods to construct new instances. Args: state: model.MapreduceState.
| def google.appengine.ext.mapreduce.api.map_job.map_job_control.Job.abort | ( | self | ) |
Aborts the job.
| def google.appengine.ext.mapreduce.api.map_job.map_job_control.Job.get_counter | ( | self, | |
| counter_name, | |||
default = 0 |
|||
| ) |
Get the value of the named counter from this job. When a job is running, counter values won't be very accurate. Args: counter_name: name of the counter in string. default: default value if the counter doesn't exist. Returns: Value in int of the named counter.
| def google.appengine.ext.mapreduce.api.map_job.map_job_control.Job.get_counters | ( | self | ) |
Get counters from this job. When a job is running, counter values won't be very accurate. Returns: An iterator that returns (counter_name, value) pairs of type (basestring, int)
| def google.appengine.ext.mapreduce.api.map_job.map_job_control.Job.get_job_by_id | ( | cls, | |
job_id = None |
|||
| ) |
Gets the job instance representing the job with id job_id. Args: job_id: a job id, job_config.job_id, of a submitted job. Returns: A Job instance for job_id.
| def google.appengine.ext.mapreduce.api.map_job.map_job_control.Job.get_outputs | ( | self | ) |
Get outputs of this job. Should only call if status is SUCCESS. Yields: Iterators, one for each shard. Each iterator is from the argument of map_job.output_writer.commit_output.
| def google.appengine.ext.mapreduce.api.map_job.map_job_control.Job.get_status | ( | self | ) |
Get status enum. Returns: One of the status enum.
| def google.appengine.ext.mapreduce.api.map_job.map_job_control.Job.submit | ( | cls, | |
| job_config, | |||
in_xg_transaction = False |
|||
| ) |
Submit the job to run. Args: job_config: an instance of map_job.MapJobConfig. in_xg_transaction: controls what transaction scope to use to start this MR job. If True, there has to be an already opened cross-group transaction scope. MR will use one entity group from it. If False, MR will create an independent transaction to start the job regardless of any existing transaction scopes. Returns: a Job instance representing the submitted job.


Hush has been building the first ever open source private messenger service based on Zcash technology. Hush & Komodo not only share core developers, but coinciding views on the importance of independent right to privacy.
100 messages
Before 05-Dec-19 12:00 AM
GatewayBOT21-Aug-19 01:35 PM
[dscrd-hush] <TonyL> I dont have a time for tournament organization atm but have time to play
[dscrd-hush] <dukeleto> maybe it will happen, we have a lot of people in this Discord
[dscrd-hush] <dukeleto> they don't call them "cyber coins" for nuthin'
[dscrd-hush] <TonyL> I want to add to CS:GO tournament prize pool 27.777 KMD for the 1st place, 17.777 KMD for second and 7.777 KMD for the third CC [ @Berg @denio
#8067 ]
GatewayBOT21-Aug-19 01:54 PM
[dscrd-hush] <denio> That is rly amazing @TonyL i will edit our Pricepool
[dscrd-hush] <denio> and you also want to play i hope
[dscrd-hush] <TonyL> I'm noobie in CSGO but maybe will join
[dscrd-hush] <denio> we are all noobies, you must join!
GatewayBOT21-Aug-19 03:49 PM
[dscrd-hush] <dukeleto> Can somebody add us to this Discord server directory? https://disboard.org/
DISBOARD is the public Discord server listing community. You can search Discord servers by your interest like Gaming, Anime, Music, etc. Find and join some awesome servers listed here!
GatewayBOT21-Aug-19 04:00 PM
[dscrd-hush] <dukeleto> @Berg looks like a discord admin can add to their site
HUSH is an Equihash privacy cryptocurrency and messenger on zero knowledge proof encryption. Being the world's first pure-Sapling chain, and utilizing KMD dPoW to secure our chain from 51% attacks, H…
GatewayBOT21-Aug-19 08:37 PM
[dscrd-hush] <Berg> We're the 5th largest cryptocurrency Discord on Disboard
GatewayBOT21-Aug-19 08:50 PM
[dscrd-hush] <xanax> good job
GatewayBOT21-Aug-19 09:08 PM
[dscrd-hush] <gigamesh> !d page
[dscrd-hush] <gigamesh> !dice 2x 5 Hush
GatewayBOT21-Aug-19 09:26 PM
[dscrd-hush] <heguli97> I wonder what it would take to get the dice game on Hush?
GatewayBOT21-Aug-19 09:58 PM
[dscrd-hush] <Privatoshi> Silence
[dscrd-hush] <Privatoshi> lol
GatewayBOT21-Aug-19 10:30 PM
[dscrd-hush] <dukeleto> not sure if we didn't pay for it, or it doesn't support Hush for a different reason
[dscrd-hush] <dukeleto> Dice might have additional integration costs, can't remember
GatewayBOT21-Aug-19 11:56 PM
[dscrd-hush] <heguli97> i asked on their discord, would be cool to get it on Hush
GatewayBOT22-Aug-19 12:27 AM
[dscrd-hush] <Privatoshi> It would be cool to have No-KYC DICE, OVER/UNDER, 0 to 100(edited)
[dscrd-hush] <franciscana23> good evening
GatewayBOT22-Aug-19 02:05 AM
[dscrd-hush] <dukeleto> howdy
[dscrd-hush] <iceyballz> You want a hush dice game bot?
GatewayBOT22-Aug-19 02:25 AM
[dscrd-hush] <dukeleto> Our discord tip bot has one built in, but it's not enable/compatible with Hush for some reason
RubyGems staff have removed 18 malicious Ruby library versions that have been downloaded 3,584 times since July 8.
[dscrd-hush] <dukeleto> @jl777c most of those backdoored libs are related to cryptocoin stuff, we are not done seeing malicious dependencies to steal funds, it's just beginning
[dscrd-hush] <Kumkani> Looks like cryptopia will eventually pay back my Hush according to their recent announcement
[dscrd-hush] <Kumkani> The liquidator of hacked cryptocurrency exchange Cryptopia claims to have made significant progress in securing and preserving funds
https://ct.com/7rdw
The liquidator of hacked cryptocurrency exchange Cryptopia claims to have made progress toward securing and preserving funds.
GatewayBOT22-Aug-19 11:31 AM
[dscrd-hush] <dukeleto> @Kumkani no, you are confused
[dscrd-hush] <dukeleto> the investors of cryptopia might one day get paid back, not the users
[dscrd-hush] <dukeleto> Note that the article never says "we will give these users their funds back". They don't even know how much was stolen, or owed, to the people who invested in the Cryptopia business
[dscrd-hush] <Mixic> We're officially listed on Disboard, a directory of Discord channels! We would appreciate if community members write a short review about our channel to help boost our visibility.
https://disboard.org/server/407861562108542986#reviews
HUSH is an Equihash privacy cryptocurrency and messenger on zero knowledge proof encryption. Being the world's first pure-Sapling chain, and utilizing KMD dPoW to secure our chain from 51% attacks, H…
GatewayBOT22-Aug-19 12:26 PM
[dscrd-hush] <dukeleto> @Mixic nice to see!
[dscrd-hush] <dukeleto> I pushed a ton of code to Github today
WIP, but getting close to mergability.
This attempts to add both transaction stats and payment stats, where one transaction can have many payments.
TODO:
Define zindex CLI param, default to off
...
[dscrd-hush] <dukeleto> and currently testing the latest V3 protocol improvements for Superlite/nSPV wallets
[dscrd-hush] <dukeleto> now I hope to bubble up to hacking on SilentDragon stuff, getting our new release out with all the features we want
[dscrd-hush] <dukeleto> and also an android mobile version of SD, which pairs to your SD on your desktop
[dscrd-hush] <dukeleto> that will allow you to send/receive shielded transactions and memos, from your phone! It must be paired to a full wallet, tho, so it's not for everybody. But it's a huge step forward
GatewayBOT22-Aug-19 01:06 PM
[dscrd-hush] <Mixic> Thanks @dukeleto :hush_dark:
GatewayBOT22-Aug-19 06:02 PM
[dscrd-hush] <CryptoJesus> Confirmations are being slow atm why is that
[dscrd-hush] <denio> higher hashrate (more Miners) ->diff go up ->miner leave->slow blocks for short time
[dscrd-hush] <denio> hope i tell you no nonsense...
GatewayBOT22-Aug-19 07:02 PM
[dscrd-hush] <ITM> its good and bad, but more good.
GatewayBOT22-Aug-19 08:22 PM
[dscrd-hush] <AkiraX> !mining
[dscrd-hush] <AkiraX> Doesn't look higher to me
GatewayBOT22-Aug-19 10:21 PM
[dscrd-hush] <dukeleto> miners gonna mine
[dscrd-hush] <Privatoshi> That's the name of the game
GatewayBOT23-Aug-19 12:33 AM
[dscrd-hush] <heguli97> Petition to have a "Music" channel where we could share our favourite/listening right now music and music videos (from youtube etc.)? Would be kinda cool imo. (edited)
[dscrd-hush] <heguli97> What do you guys think?
GatewayBOT23-Aug-19 01:35 AM
[dscrd-hush] <AkiraX> Pomplamoose
[dscrd-hush] <AkiraX> !mining
GatewayBOT23-Aug-19 02:45 AM
[dscrd-hush] <AkiraX> Can we change the ticker for Bitcoin hush is shhh?
This patch is motivated by the desire to make the output of getchaintxstats more useful and optimized for applications to consume and render the data.
Firstly, this data is already available to the...
[dscrd-hush] <dukeleto> I accidentally sent a PR to Bitcoin, my first one. We already have that improvement in Hush, but I want to see if BTC core wants it
The incipient $HUSH SilentDragon full node features a ROCKPro64 4GB ARMv8 machine with RK3399 Hexa-Core 64bit CPU, capable of running full nodes for multiple coins at the same time!
https://t.co/QVOCOTeG33
All needed software pre-installed, first startup creates a wallet.d...
In porting getchaintxstats RPC to various other coins + extending it to study shielded transactions+payments, I saw a chance to push a tiny improvement back to $BTC upstream.
There are many like it, but this one is mine: My first Bitcoin Pull Request
https://t.co/v7Q8Y9C...
oops, I found the wrong link, it's actually the QuadCore 4GB Pine64: https://t.co/TnXNFETlYj , which helps keep the cost down and also reduces the risk of overheating
[dscrd-hush] <dukeleto> somebody was wrong on the internet .... and it was me!!!
[dscrd-hush] <CryptoCloaks>
GatewayBOT23-Aug-19 11:15 PM
[dscrd-hush] <JiveBuddha> If we promise to yell less, can we convince radix to work on Hush?
GatewayBOT23-Aug-19 11:27 PM
[dscrd-hush] <dukeleto> radix42 is exactly where she needs to be, and they are already helping: We will be using their binaries to run on the ARM SilentDragon sexy machine
[dscrd-hush] <dukeleto> Not sure what exactly to call it
GatewayBOT23-Aug-19 11:43 PM
[dscrd-hush] <iceyballz> SilentNode
[dscrd-hush] <iceyballz> @dukeleto ^
GatewayBOT24-Aug-19 12:53 AM
[dscrd-hush] <AkiraX> Welcome jivebuddha
[dscrd-hush] <AkiraX> @JiveBuddha is that 3 million investment still o. The table?
[dscrd-hush] <heguli97> fun to see some of long time community members popping in here to talk :hush_puppy:


Retiring Domains
Dave Winer posted an interesting idea regarding retiring websites. In sports, teams and leagues can retire numbers, making them unusable by other players. The player and player's number always being remembered together.
Dave, suggests that the internet should have a way to retire domains. He equates it to retiring numbers of great players in sports.
When a great baseball or basketball player leaves the game they retire his or her number. That means the jersey hangs from the ceiling, or there's a plaque at the stadium, and no player on the team ever wears that number again.
His thought arose from the suicide of Aaron Swartz, a wunderkind (I don't use this word lightly) who brought us some amazing things on the internet, such as creative commons, Reddit, and was highly involved in SOPA.
Retiring a domain is an interesting idea and a challenging technical problem.
Mathematically, retiring players numbers is much more problematic than retiring domain names. In sports, players only have 100 numbers (0 - 99) per team. So, in theory, you could run out of numbers as more become retired. Domains have a 67 character domain name limit, so, it would take longer to run out of domain names than jersey numbers.
A problem with retiring domains is we need to do it immediately on the society contributor's death. A lot of time had passed when Major League Baseball decided to retire Jackie Robinson's number. Jackie Robinson's number wasn't retired in 1956, when he stopped playing baseball. Mr. Robinson's number wasn't retried when he died in 1972. Major League Baseball retired the number 42 in 1997.
This late postmortem retiring doesn't work well on the Internet. The person's work needs to be immediately worthy of retirement when they die.
Continuing the baseball analogy, what would happen if another respected player -- the first woman baseball player -- used the number 42 before it's retiring?
We could only preserve the domain on the society contributor's death and before the domain expires. If a corporation or person purchases the domain after the society contributor's death, could the internet force them to give it up?
Forcing someone to give up a domain seems against what the internet stands for. The Internet is about complete freedom. Aaron fought for these rights. When his domain expires, and someone buys it, would Aaron support the forceful removal of the domain from the owner?
But, who qualifies to be the decision maker? How far does there power extend?
We have ways of preserving the content without retiring the domain. The Internet Archive seems to be a perfect place for Aaron's contributions. The Internet Archive's purpose is:
[to] offer permanent access for researchers, historians, scholars, people with disabilities, and the general public to historical collections that exist in digital format.
We could fork the content. If Aaron's essays were in a repository we could create our own copies and distribute them that way. Sharing Aaron's essays would be like distributing large files over a BitTorrent network. This is a reason everyone's content should be on Github. On my death, github will still be around, which means my content will still be there, even when this domain expires.
drivingmenuts has an interesting thought on the Hacker News Thread discussing the idea of retiring domains:
Will the internet become littered with millions of permanent monuments to misguided souls, like the little crosses on side of our highways?
Note: I usually call people by their first names after mentioning thier full name in an article. In Jackie Robinson's case, I couldn't bring myself to calling him anything other than Mr. Robinson.


We're sorry but saasforcovid.com doesn't work properly without JavaScript enabled. Please enable it to continue.


Fresh tone starts with fresh strings.
All of our strings are crafted from high grade U.S. Steel in our factory right here in California. Our craftsmanship comes from 75 years of string making experience.
Modify, update, or cancel any time. We make it easy to quickly change your subscription. No strings attached.
Old strings sound dull, feel gross and are prone to failure. We keep your tone fresh with premium strings delivered to your door at a ridiculously good price. The rest is in your hands.


As absolute is by amounted repeated entirely ye returned. These ready timed enjoy might sir yet one since. Years drift never if could forty being no. On estimable dependent as suffering on my. Rank it long have sure in room what as he. Possession travelling sufficient yet our. Talked vanity looked in to. Gay perceive led believed endeavor. Rapturous no of estimable oh therefore direction up. Sons the ever not fine like eyes all sure.
As absolute is by amounted repeated entirely ye returned. These ready timed enjoy might sir yet one since. Years drift never if could forty being no. On estimable dependent as suffering on my. Rank it long have sure in room what as he. Possession travelling sufficient yet our. Talked vanity looked in to. Gay perceive led believed endeavor. Rapturous no of estimable oh therefore direction up. Sons the ever not fine like eyes all sure.
Commmmmmmmmmmmmmmmmmmmmmment
Commmmmmmmmmmmmmmmmmmmmmment


Retail Major Walmart To Help MSMEs In India In Enhancing Capacity, Supply Chain; Launches Support Initiative
by IANSRetail major Walmart on Monday (9 December) launched "Walmart Vriddhi Supplier Development Program", an initiative to help MSMEs in India to enhance their capability and supply chain.
Speaking at the launch event here Judith McKenna, president and CEO, Walmart International Under the initiative, the company which owns the e-commerce major Flipkart, aims to train around 50,000 micro, small and medium enterprises (MSME) in the next five years, across 25 institutes.
"The Vriddhi programme will encourage Indian suppliers to make for online and offline customers around the world, including -- but not limited to -- the supply chains of Flipkart and Walmart. Whether a supplier has ambitions domestically or around the globe, Walmart Vriddhi will give them the tools they need to succeed," she said.
The first hub would be set up by March 2020, she said, adding that the programme will connect the community of entrepreneurs.
McKenna further said that the initiative is part of the Walmart's "long-term commitment" in India.
She added that the company will have a unique network as part of the initiative to provide inputs and technical support among other support to the MSMEs.
Further, training would cover all aspects of business management, promoting customer-centric strategies and best practices in workforce management and environmental sustainability.
(This story has been published from a wire agency feed without modifications to the text. Only the headline has been changed.)


|
Shopify SDK for Unity
|
Base class for all GraphQL query generator input objects. More...
Public Member Functions | |
| override string | ToString () |
| Returns a string representing a GraphQL input object. More... | |
Protected Member Functions | |
| void | Set (string key, object value) |
| object | Get (string key) |
Base class for all GraphQL query generator input objects.
|
inline |
Returns a string representing a GraphQL input object.


Hangfire is a compherensive background job manager. You can integrate ASP.NET Boilerplate with Hangfire to use it instead of default background job manager. You can use the same background job API for Hangfire. Thus, your code will be independent of Hangfire. But, if you like, you can directly use Hangfire's API also.
First, install Abp.HangFire nuget package to your project. Then you can install any storage for Hangfire. Most common one is SQL Server storage (see Hangfire.SqlServer nuget package). After you installed these nuget packages, you can configure ASP.NET Boilerplate to use Hangfire as shown below:
[DependsOn(typeof (AbpHangfireModule))]
public class MyProjectWebModule : AbpModule
{
public override void PreInitialize()
{
Configuration.BackgroundJobs.UseHangfire(configuration =>
{
configuration.GlobalConfiguration.UseSqlServerStorage("Default");
});
}
//...
}
We added AbpHangfireModule as a dependency and used Configuration.BackgroundJobs.UseHangfire method to enable and configure Hangfire ("Default" is the connection string in web.config).
See Hangfire documentation for more information.


At least 106 protesters killed in Iran during unrest: Amnesty
by ReutersGENEVA / LONDON: At least 106 protesters have been killed in 21 cities in Iran during unrest that broke out over fuel price hike last week, Amnesty International said on Tuesday.
“The organisation believes that the real death toll may be much higher, with some reports suggesting as many as 200 have been killed,” Amnesty said in a statement.
The rights watchdog said the security forces had received a “green light to crush” the protests which broke out on Friday and had spread to more than 100 cities across Iran.
“Authorities must end this brutal and deadly crackdown immediately,” said Amnesty’s Philip Luther, whose organisation based its report on “verified video footage, eyewitness testimony from people on the ground and information” from rights activists outside Iran.
Amnesty also urged Iranian authorities to “lift the near-total block on internet access designed to restrict the flow of information about the crackdown to the outside world”.
It said video footage showed that “snipers have also shot into crowds of people from rooftops and, in one case, a helicopter”.
While most demonstrations appeared to have been peaceful, it said, “a small number of protesters turned to stone-throwing and acts of arson and damage to banks and seminaries”.
Security forces had been seen taking away dead bodies and injured people from roads and hospitals, according to witnesses, and refused to hand over bodies of victims to their families, Amnesty said.
A hike in petrol price sparked the protests in which Iran has officially confirmed at least five dead, including three security personnel allegedly stabbed to death by “rioters”.


Date: Thu, 18 Dec 1997 18:27:52 GMT Server: Stronghold/1.3.4 Ben-SSL/1.3 Apache/1.1.3 Content-type: text/html Content-length: 7924 Last-modified: Tue, 09 Dec 1997 00:18:03 GMT
|
The Advance Paradigm National Outpatient Drug Formulary is an information resource which can be a useful tool in the management of the quality and cost of drug therapy. It should be used as a guide by providers in the selection of drug therapies. The formulary was developed by a Pharmacy and Therapeutics Committee comprised of pharmacists and consulting physicians. The formulary development process involved evaluation of drug use throughout the Plan with selection of drug entities which reflected the prescribing patterns of Advance Paradigm providers. The formulary is continually changing to reflect new advances in drug treatment therapies and the current practices of Advance Paradigm providers. Therefore, input from Plan providers is encouraged. The value and effectiveness of the formulary depends upon the support and compliance of providers. The cooperation of all providers with the purpose of this formulary is appreciated. The Pharmacy and Therapeutics Committee was established to develop and maintain a rational drug formulary and control pharmacy costs. It is comprised of consulting physicians, Plan physicians and pharmacists who meet quarterly to review drug use and establish guidelines for change. The Pharmacy and Therapeutics Committee utilizes the most authoritative sources of information, i.e. Food and Drug Administration (FDA), National Institutes of Health (NIH), National Center for Disease Control (CDC), and others, to select medications based on comparative efficacy, adverse effect profile and cost. Drugs are listed generically by therapeutic classification and alphabetically. Common brand names for generic entities appear in parentheses for informational purposes only. Providers are encouraged to prescribe generically whenever possible and to use first line lower cost options when appropriate. The formulary index lists drugs by both generic and brand names with references to specific formulary sections where the drug may be found. It also indicates over-the-counter (OTC) medications, non-formulary drugs, maintenance medications, schedule II narcotics, drugs which may be dispensed with the generic equivalent, dual source medications which will be dispensed with the formulary brand only, and drugs with recommended prescribing guidelines. All dosage forms and strengths of each drug listed are considered formulary products unless otherwise noted. Over-the-counter (OTC) products are listed for informational purposes only; they are not a covered benefit of Advance Paradigm unless exceptions are made by a Plan. Cost Index $ One to six dollar signs precede all drugs listed in the formulary. The number of dollar signs reflects the weighted daily or unit cost of the pharmaceutical product, based upon average wholesale price less any contractual allowance. The use of these symbols cannot be translated directly into a dollar amount, instead they are intended to illustrate relative costs within a drug category. $ product A least expensive
[MAINT] Maintenance drugs may be dispensed to the Plan member in quantities up to a 34 day supply or 100 units, depending on plan parameters. Asterisk * An asterisk indicates drugs which have an FDA approved generic equivalent available. Pound Sign # A pound sign indicates dual source branded medications which will be dispensed with the formulary brand indicated. NON-FORM Non-formulary drugs CII
(OTC)
The Advance Paradigm prescription benefit is a generic benefit. Specified drugs having FDA approved generic equivalents available will be dispensed generically, and are depicted throughout the formulary with the asterisk symbol. Members requesting a brand name product when a generic product is available must pay the difference between the brand and generic in addition to their standard copayment, unless the physician designates "Do Not Substitute (DNS)" on the prescription. Exclusions may vary for certain groups. Providers are encouraged to comply with the drug formulary when prescribing medications for Advance Paradigm members. The Advance Paradigm national formulary is an open formulary that is designed to be comprehensive but not all inclusive1. Providers occasionally may find it necessary to prescribe drugs which are not listed on the formulary because these drugs are infrequently used or have very limited use. The Pharmacy and Therapeutics Committee will contact providers whose prescribing habits consistently vary from the formulary. 1 Some individual Plans may choose to have a closed or partially closed formulary. |
|||
|
|
|||


Epicodus currently offers five different tracks of study for students to choose from. Each track focuses on different languages, and each language occupies a particular place in the tech development world. The language each student should pursue depends on that student's goals for their future employment.
Note: Disabled questions are irrelevent to your suggested track at Epicodus.
Ruby is a favorite language of developers building interactive web applications. If an app involves users creating accounts, entering information, and interacting with dynamic content, there's a good chance it is built with Ruby. Ruby became popular because the Rails framework, which is written with Ruby, simplified many of the common tasks associated with building web applications. It's most popular with startups and smaller companies who are looking to build their product quickly.
PHP is most used in content-heavy websites with relatively little user interaction. The most popular content management systems - Wordpress, Drupal, and Joomla - are all written in PHP, and everything from local restaurants' websites up through large complex government deployments are built with these tools. If you're keen to work for an agency that builds websites for clients, or if you like the idea of building out sites for brands, businesses, and organizations, PHP is a great direction to go.
Java is also a favorite of enterprise companies, but its appeal is broader as well: it's one of the most popular of all programming languages, and it's used in everything from for high-performance processing to building Android user interfaces. Because Java has been very popular for a very long time and is used in so many applications, it is also a very high-demand language. If you're interested in working for an enterprise-level company, as an Android developer, or in high-performance applications, Java could be a good language to learn.
The CSS/Design track focuses on how to make beautiful, usable interfaces and websites. The classes maintain a strong balance between theory and practice to give students a solid foundation of design principles as well as experience working with modern, industry-standard design tools. Whether you’re an aspiring freelancer, a design-savvy front-end developer, or a budding UI/UX designer, this course is a launching point for anyone interested in designing beautiful, memorable web experiences.
C# and .NET are typically used by larger enterprises, government agencies, and companies serving enterprise and government clients. C# is most popular among bigger established businesses, often for building internal software. Because it's been around for a long time and has the backing of Microsoft, it is one of the most in-demand languages in the job market. C# has also been going through a bit of a rebirth lately, with Microsoft open sourcing the language and surrounding platform, porting it to run on Mac and Linux, and incorporating many of the best features of other languages. If you like the idea of working for a larger company on business software, C# is a great choice.
Please choose an answer for each enabled question.


Evernest
One Last Step
You're almost done! Select at least 3 topics so we can show you stories you'll like.
General
Business
Entertainment
Sport
Technology
Done


Edit Alert Button
Your Personal Information
Male
Female
Asinan
Banicain
Baretto
East Bajac-Bajac
East Tapinac
Gordon Heights
Kalaklan
Mabayuan
New Cabalan
New Ilalim
New Kababae
New Kalalake
Old Cabalan
Pag-Asa
Sta.Rita
West Bajac-Bajac
West Tapinac
Your Full Address
Emergency Contact
I accept
MERSY
Terms & Condition
Save


Server {{ServerName}} with PID {{ServerPID}} is {{ServerStatus}}
{{ServerName}}
{{FName}}
Flag is true
Flagd is false
This is a paragraph that I am supposed to do something with.


Test checkbox 1 Test checkbox 2 Test checkbox 3
Test radio 1 Test radio 2 Test radio 3
Select drop-down Some text goes here Another choice could be here Yet another item to be chosen Some text goes here Another choice could be here Yet another item to be chosen Some text goes here Another choice could be here Yet another item to be chosen
Select multiple Some text goes here Another choice could be here Yet another item to be chosen Some text goes here Another choice could be here Yet another item to be chosen Some text goes here Another choice could be here Yet another item to be chosen
Textarea
Button tag