stk.molecular.energy module¶
Defines energy calculations via Energy
.
Extending stk: Adding more energy functions.¶
It may well be the case that more ways to calculate the energy of molcules will need to be added. For example, if support for using some external software to perform the calculations needs to be added.
In order to add a new function which calculates the energy, just add it
as a method to Energy
. There really aren’t any requirements
beyond this, just make sure the energy value is what the method
returns.
If the energy method does not fit neatly into a single method, feel free to split it up. Make sure that any helper methods are private, i.e. that their names start with a leading underscore. Only the main method which the user will use should be public.
To calculate the energy of some Molecule
object the only
thing that is needed is calling one of the Energy
methods:
>>> molecule.energy.rdkit('uff')
OUT: 16.501
Here, Energy.rdkit()
was used as an example and molecule
is just some Molecule
instance. Each Molecule
object has an Energy
instance in its energy
attribute.
Each Energy
instance also has a values
attribute, which stores the result of previous calculations. Using the
molecule from the previous example:
>>> molecule.energy.values
OUT: {FunctionData('rdkit', forcefield='uff'): 16.501}
I.E. this indicates that Energy.rdkit()
was called with the
forcefield argument set to 'uff'
and the result was 16.501
.
Calling any method of Energy
updates the dictionary
automatically. When adding a new method to the class, no mechanism for
updating the dictionary needs to be provided. Writing the method within
the class is enough for it to update the values
dictionary when called.
Sometimes a function will require a parameter which does not affect the
outcome of the energy calculation. For example, to calculate the energy
using the MacroModel program, Energy.macromodel()
can be used:
molecule.energy.macromodel(forcefield=16,
macromodel_path='path/to/macromodel/dir')
This function requires the number of a forcefield (16
) and the
directory where MacroModel is installed on the users computer
('path/to/macromodel/dir'
). However, the directory does not affect
the value of the calculated energy. When running:
>>> molecule.energy.values
We want the output to be:
OUT: {FunctionData('rdkit', forcefield=uff): 16.501,
FunctionData('macromodel', forcefield=16): 200}
(Assuming we are still dealing with the same molecule
instance from
the rdkit()
example, both calculated energies will be
kept in the dictionary.)
However, if we just define Energy.macromodel()
within
Energy
, and then run it:
molecule.energy.macromodel(forcefield=16,
macromodel_path='path/to/macromodel/dir')
The output of
>>> molecule.energy.values
will be
OUT: {FunctionData('rdkit', forcefield=uff) : 16.501,
FunctionData('macromolecule',
forcefield=16,
macromodel_path='path/to/macromodel/dir'): 200}
In order to make sure that the macromodel_path is excluded from the
key, decorate Energy.macromodel()
with the exclude()
decorator. For example:
@exclude('macromodel_path')
def macromodel(self, forcefield, macromodel_path):
...
Now the parameter macromodel_path will not form part of the key in
the values
dictionary. If there were 2 parameters you
wanted to exlude:
@exclude('exclude1', 'exclude2')
def energy_func(include1, include2, exclude1, exclude2):
...
and so on.
Sometimes even this isn’t enough to get the key to look exactly the way we want. For exmple:
@exclude('force_e_calc')
def formation(self,
func,
products,
building_blocks=None,
force_e_calc=False):
...
The func parameter of this function is a FunctionData
instance, which holds the data of one of the other Energy
methods. This includes all data the method requires to run, even
software directories if needed. As a result, the key when running this
function may look like this:
FunctionData('pseudoformation',
building_blocks=None,
func=FunctionData('macromodel',
forcefield=16,
macromodel_path='/opt/schrodinger2017-2'))
Notice that the path of the MacroModel installation was kept nested in
the key of Energy.formation()
. This is undesirable. To make this
work properly, a completely custom mechanism for making the
key of the Energy.formation()
is necessary. To do this, define a
function in this module. For example:
def formation_key(fargs, fkwargs):
...
And set the key
attribute of the energy method to the newly
defined function:
Energy.formation.key = formation_key
The fargs and fkwargs arguments are the arguments and keyword
arguments with which Energy.formation()
was called, including
self. The formation_key()
function should return a
FunctionData
instance which will act as the key. In our case
the function was defined so that the key is:
FunctionData('formation',
products=[],
building_blocks=None,
func=FunctionData('macromodel', forcefield=16))
Notes.¶
- Make sure to use the values dictionary instead of running the same calculation repeatedly.
- The automatic updating of the dictionary is achieved by the
EMeta
metaclass,EMethod()
descriptor ande_logger()
decorator. You do not need to worry about these, but information about how they work is provided in the docstring ofEMeta
.
-
class
stk.molecular.energy.
EMeta
¶ Bases:
type
A metaclass for
Energy
.In conjuction with the
EMethod
descriptor and thee_logger()
decorator this class allows methods to automatically updateEnergy.values
without explicitly being told to do so.Basically, this metaclass turns all methods of
Energy
into descriptors of theEMethod
class. These descriptors return a decorated version of the original method defined inEnergy
. The method is decorated withe_logger()
decorator. Calling this decorated method makes it automatically updateEnergy.values
.
-
class
stk.molecular.energy.
EMethod
(func)¶ Bases:
object
A descriptor for methods of
Energy
.-
func
¶ The method which the descriptor acts as a getter for.
Type: function
-
-
class
stk.molecular.energy.
Energy
(molecule)¶ Bases:
object
Handles all things related to a molecule’s energy.
An instance of this class will be placed in
Molecule.energy
of eachMolecule
instance.-
values
¶ A
dict
of the formvalues = {FunctionData('method1', param='a'): 34}
Where the
FunctionData
instance identifies anEnergy
method which was run and the parameters which were used, while the key holds the result of the calculation.Type: dict
-
formation
(func, products, building_blocks=None, force_e_calc=False, conformer=-1)¶ Calculates the formation energy.
The formation energy is calculated under the assumption that the molecule in
molecule
is composed of the molecules in building_blocks and that during formation molecules in products are formed in addition tomolecule
.Parameters: - func (
FunctionData
) –A
FunctionData
object which describes the method used to calculate the energies. For example:func = FunctionData('rdkit', forcefield='uff')
- products (
list
) –A
list
of the formproducts = [(4, mol1), (2, mol2)]
Where
mol1
andmol2
areMolecule
objects of molecules produced in addition tomolecule
during its formation reaction. The numbers represent the number of each molecule made permolecule
. - building_blocks (
list
, optional) –A
list
of the formbuilding_blocks = [(2, mol1), (3, mol2)]
Where
mol1
andmol2
areMolecule
objects which react to formolecule
. The numbers represetnt the amount of each building block required to form 1molecule
.This argument can be omitted when the formation energy of a
MacroMolecule
instance is being found, as they keep this data stored elsewhere already. - force_e_calc (
bool
, optional) – If this isTrue
then all molecules in building_blocks, products andmolecule
will have their energies recalculated. Even if the energy values have already been found with the chosen forcefield and method. IfFalse
the energy is only calculated if the value has not already been found. - conformer (
int
, optional) – The conformer to use.
Returns: The formation energy.
Return type: float
- func (
-
macromodel
(forcefield, macromodel_path, conformer=-1)¶ Calculates the energy using macromodel.
Note that this requires macromodel to be installed and have a valid license.
Parameters: - forcefield (
int
) – The id number of the forcefield to be used by macromodel. - macromodel_path (
str
) – The full path to the Schrodinger suite within the user’s machine. For example, in a default Linux installation the folder will probably be something like'/opt/schrodinger2017-2'
. - conformer (
int
, optional) – The conformer to use.
Returns: The calculated energy.
Return type: float
Raises: EnergyError
– This exception is raised if no energy value is found in the MacroModel calculation’s.log
file. Likely due to a forcefield error.- forcefield (
-
mopac
(mopac_path, settings=None)¶ Calculates the energy using MOPAC.
Note that this requires MOPAC to be installed and have a valid license.
Parameters: - settings (
dict
, optional) –A dictionary which maps the names of the optimization parameters to their values. Valid values are:
- ’hamiltonian’ :
str
(default ='PM7'
- A series of different methods can be selected:
PM7, PM6, AM1, CIS (CISD, CISDT), MNDO, RM1, etc..
PM7 is the latest version of the reparametrization of NDDO theory, where all the atomic and diatomic parameters were re-optimized / updated from PM6 [1].
- ’eps’ :
float
(default =80.1
) - Sets the dielectric constant for the solvent.
Presence of this keyword will cause the COSMO
(Conductor-like Screening Model) method to be used
to approximate the effect of a solvent model
surrounding the molecule. Solvents with a low
dielectric constant are not likely to work well
with this model.
0
means that the dielectric constant is not included in the calculation.80.1
can be used to model a water environment at room temperature. - ’charge’ :
float
(default =0
) - The charge of the system.
- ’timeout’ :
float
(default =172800
) - The amount in seconds the calculation is allowed to
run before being terminated. The default value is
2
days or172,800
seconds.
- ’hamiltonian’ :
- mopac_path (
str
) – The full path to the MOPAC installation.
Returns: The calculated energy.
Return type: float
References
[1] http://openmopac.net/PM7_accuracy/PM7_accuracy.html - settings (
-
mopac_dipole
(mopac_path, settings=None)¶ Calculates the dipole moment using MOPAC.
Note that this requires MOPAC to be installed and have a valid license.
Parameters: - settings (
dict
, optional) –A dictionary which maps the names of the optimization parameters to their values. Valid values are:
- ’hamiltonian’ :
str
(default ='PM7'
- A series of different methods can be selected:
PM7, PM6, AM1, CIS (CISD, CISDT), MNDO, RM1, etc..
PM7 is the latest version of the reparametrization of NDDO theory, where all the atomic and diatomic parameters were re-optimized / updated from PM6 [2].
- ’eps’ :
float
(default =80.1
) - Sets the dielectric constant for the solvent.
Presence of this keyword will cause the COSMO
(Conductor-like Screening Model) method to be used
to approximate the effect of a solvent model
surrounding the molecule. Solvents with a low
dielectric constant are not likely to work well
with this model.
0
means that the dielectric constant is not included in the calculation.80.1
can be used to model a water environment at room temperature. - ’charge’ :
float
(default =0
) - The charge of the system.
- ’timeout’ :
float
(default =172800
) - The amount in seconds the calculation is allowed to
run before being terminated. The default value is
2
days or172,800
seconds.
- ’hamiltonian’ :
- mopac_path (
str
) – The full path to the MOPAC installation.
Returns: The calculated dipole.
Return type: float
References
[2] http://openmopac.net/PM7_accuracy/PM7_accuracy.html - settings (
-
mopac_ea
(mopac_path, settings=None)¶ Calculates the electron affinity using MOPAC.
Note that this requires MOPAC to be installed and have a valid license.
Parameters: - settings (
dict
, optional) –A dictionary which maps the names of the optimization parameters to their values. Valid values are:
- ’hamiltonian’ :
str
(default ='PM7'
- A series of different methods can be selected:
PM7, PM6, AM1, CIS (CISD, CISDT), MNDO, RM1, etc..
PM7 is the latest version of the reparametrization of NDDO theory, where all the atomic and diatomic parameters were re-optimized / updated from PM6 [3].
- ’eps’ :
float
(default =80.1
) - Sets the dielectric constant for the solvent.
Presence of this keyword will cause the COSMO
(Conductor-like Screening Model) method to be used
to approximate the effect of a solvent model
surrounding the molecule. Solvents with a low
dielectric constant are not likely to work well
with this model.
0
means that the dielectric constant is not included in the calculation.80.1
can be used to model a water environment at room temperature. - ’charge’ :
float
(default =0
) - The charge of the system.
- ’timeout’ :
float
(default =172800
) - The amount in seconds the calculation is allowed to
run before being terminated. The default value is
2
days or172,800
seconds.
- ’hamiltonian’ :
- mopac_path (
str
) – The full path to the MOPAC installation.
Returns: The calculated energy.
Return type: float
References
[3] http://openmopac.net/PM7_accuracy/PM7_accuracy.html - settings (
-
mopac_ip
(mopac_path, settings=None)¶ Calculates the ionization potential using MOPAC.
Note that this requires MOPAC to be installed and have a valid license.
Parameters: - settings (
dict
, optional) –A dictionary which maps the names of the optimization parameters to their values. Valid values are:
- ’hamiltonian’ :
str
(default ='PM7'
- A series of different methods can be selected:
PM7, PM6, AM1, CIS (CISD, CISDT), MNDO, RM1, etc..
PM7 is the latest version of the reparametrization of NDDO theory, where all the atomic and diatomic parameters were re-optimized / updated from PM6 [4].
- ’eps’ :
float
(default =80.1
) - Sets the dielectric constant for the solvent.
Presence of this keyword will cause the COSMO
(Conductor-like Screening Model) method to be used
to approximate the effect of a solvent model
surrounding the molecule. Solvents with a low
dielectric constant are not likely to work well
with this model.
0
means that the dielectric constant is not included in the calculation.80.1
can be used to model a water environment at room temperature. - ’charge’ :
float
(default =0
) - The charge of the system.
- ’timeout’ :
float
(default =172800
) - The amount in seconds the calculation is allowed to
run before being terminated. The default value is
2
days or172,800
seconds.
- ’hamiltonian’ :
- mopac_path (
str
) – The full path to the MOPAC installation.
Returns: The calculated energy.
Return type: float
References
[4] http://openmopac.net/PM7_accuracy/PM7_accuracy.html - settings (
-
pseudoformation
(func, building_blocks=None, force_e_calc=False, conformer=-1)¶ Calculates the formation energy, sans other products.
This is the formation energy if the energy of the other products of the reaction is not taken into account.
Parameters: - func (
FunctionData
) –A
FunctionData
object which describes the method used to calculate the energies. For example:func = FunctionData('rdkit', forcefield='uff')
- building_blocks (
list
, optional) –A
list
of the formbuilding_blocks = [(2, mol1), (3, mol2)]
Where
mol1
andmol2
areMolecule
objects which react to formolecule
. The numbers represetnt the amount of each building block required to form 1molecule
.This argument can be omitted when the formation energy of a
MacroMolecule
instance is being found, as they keep this data stored elsewhere already. - force_e_calc (
bool
, optional) – If this isTrue
then all molecules in building_blocks, products andmolecule
will have their energies recalculated. Even if the energy values have already been found with the chosen forcefield and method. IfFalse
the energy is only calculated if the value has not already been found. - conformer (
int
, optional) – The conformer to use.
Returns: float – The pseudoformation energy.
Return type: float
- func (
-
rdkit
(forcefield, conformer=-1)¶ Uses
rdkit
to calculate the energy.Parameters: - forcefield (
str
) – The name of the forcefield to be used. - conformer (
int
, optional) – The conformer to use.
Returns: The calculated energy.
Return type: float
- forcefield (
-
-
stk.molecular.energy.
_create_mop
(file_root, molecule, settings)¶ Creates the
.mop
file holding the molecule to be optimized.Parameters: - mol (
Molecule
) – The molecule which is to be optimized. Its molecular structure file is converted to a.mop
file. The original file is also kept. - settings (
dict
) – Dictionary defined by the MOPAC methods, where all the run details are defined.
Returns: The full path of the newly created
.mop
file.Return type: str
- mol (
-
stk.molecular.energy.
_extract_MOPAC_dipole
(file_root)¶
-
stk.molecular.energy.
_extract_MOPAC_en
(file_root)¶
-
stk.molecular.energy.
_kill_mopac
(file_root)¶ Stops an in-progress MOPAC run.
To kill a MOPAC run, a file with the molecule’s name and a
.end
extension is written.Parameters: file_root ( str
) – The molecule’s name.Returns: None Return type: NoneType
-
stk.molecular.energy.
_mop_line
(settings)¶ Formats settings into a MOPAC input string.
Parameters: settings ( dict
) – Dictionary defined inmopac_opt()
, where all the run details are defined.Returns: String containing all the MOPAC keywords correctly formatted for the input file. Return type: str
-
stk.molecular.energy.
_run_mopac
(file_root, mopac_path, timeout=3600)¶
-
stk.molecular.energy.
e_logger
(func, obj)¶ Turns func into a version which updates :attr`Energy.values`.
Parameters: Returns: The function func bound to obj and modified so that when called the results update
Energy.values
.Return type: types.MethodType
-
stk.molecular.energy.
exclude
(*args)¶ A decorator to add the :attr`exclude` attribute to methods.
Parameters: args ( tuple
ofstr
) – Holds the names parameters which are not to be used as part of the key for theEnergy
method.Returns: The function which has had the exclude
attribute added. This is alist
holding the names of parameters, which are not part of the key.Return type: function
-
stk.molecular.energy.
formation_key
(fargs, fkwargs)¶ Generates the key of
Energy.formation()
.Parameters: - fargs (
tuple
) – The arguments with whichEnergy.formation()
was called. - fkwargs (
dict
) – The keyword arguments with whichEnergy.formation()
was called.
Returns: The
FunctionData
object representing the key ofEnergy.formation()
, when called with the arguments fargs and keyword arguments fkwargs.Return type: - fargs (
-
stk.molecular.energy.
func_key
(func, fargs=None, fkwargs=None)¶ Returns the key used in
Energy.values
for func.Parameters: - func (
function
) – The function whose results are to be stored inEnergy.values
. - fargs (
tuple
, optional) – The arguments passed to func. - fkwargs (
dict
, optional) – The keyword arguments passed to func.
Returns: The
FunctionData
object representing the key when func is called with the arguments fargs and keyword arguments fkwargs.Return type: - func (
-
stk.molecular.energy.
pseudoformation_key
(fargs, fkwargs)¶ Generates key of the
Energy.pseudoformation()
.Parameters: - fargs (
tuple
) – The arguments with whichEnergy.pseudoformation()
was called. - fkwargs (
dict
) – The keyword arguments with whichEnergy.pseudoformation()
was called.
Returns: The
FunctionData
object representing the key whenEnergy.pseudoformation()
is called with the arguments fargs and keyword arguments fkwargs.Return type: - fargs (


Welcome to the Angular Store.
Please select the products you want and add them to your shopping cart.
When you are done, click the shopping cart icon to review your order and check out.
Search:
| {{cart.getTotalCount()}} items, {{cart.getTotalPrice() | currency}} | |||
|
{{product.name}} {{product.description}} |
{{product.price | currency}} | add to cart | |
| {{cart.getTotalCount()}} items, {{cart.getTotalPrice() | currency}} |


|
Name
|
Type
|
Description
|
| ipAddress | xsd:string[] |
IP address for the destination of encapsulated remote mirror source session,
IPv4 address is specified using dotted decimal notation.
For example, "<IP_ADDRESS>".
IPv6 addresses are 128-bit addresses represented as eight fields
of up to four hexadecimal digits.
A colon separates each field (:). For example,
2001:DB8:101::230:6eff:fe04:d9ff.
Since vSphere API 5.1
|
| portKey | xsd:string[] |
Individual ports to participate in the Distributed Port Mirroring session.
|
| uplinkPortName | xsd:string[] |
Uplink ports used as destination ports to participate in the Distributed Port Mirroring session.
A fault will be raised if uplinkPortName is used as source ports
in any Distributed Port Mirroring session.
|
| vlans | xsd:int[] |
Vlan Ids for ingress source of Remote Mirror destination
session.
Since vSphere API 5.1
|
| wildcardPortConnecteeType | xsd:string[] |
Wild card specification for source ports participating in the Distributed Port Mirroring session.
See DistributedVirtualSwitchPortConnecteeConnecteeType for valid values.
Any port that has a connectee of the specified type has its receive traffic
mirrored. A fault will be raised if wildcards are specified as destination
ports or source ports mirroring traffic on the transmit side.
It is to be not used.
|
|
Properties inherited from DynamicData |
| None |


Death of popular west Mayo personality
THE death of Grainne Collins (née O'Malley), Cornanool, Castlebar, and late of The Pub, Dooagh, Achill, is widely mourned.
A member of a popular and respected family, she was held in very high regard in the community at large.
Predeceased by her parents Sonny and Josie, sister Lourdie and brother Anthony, she is deeply regretted by her husband John, daughter Sandra (Courell), sons Tony, Johan and Ronan, son-in-law Rory, daughters-in-law Sharon, Sharon and Gillian, brothers-in-law John (Cafferkey), Peter (Collins), Billy (Collins) and Michael (Collins), sisters-in-law Nodie (McCarthy) and Anne (Farrell), grandchildren Zara, Zac, Sean, Sarah, Lauren, Josh, Adam, Jack and Tom, nephews, nieces, relatives, neighbours and friends.
Deepest sympathy is tendered to the bereaved family on their loss.
Requiem Mass takes place in St. Patrick's Church, Islandeady, tomorrow (Monday) at 12 noon with burial afterwards in the New Cemetery, Castlebar.
May her gentle soul rest in peace.


Class Spyc
The Simple PHP YAML Class.
This class can be used to read a YAML file and convert its contents into a
PHP array. It currently supports a very limited subsection of the YAML spec.
Usage:
$Spyc = new Spyc;
$array = $Spyc->load($file);
or:
$array = Spyc::YAMLLoad($file);
or:
$array = spyc_load_file($file);
Methods summary
public
array
|
#
load( string $input )
Load a valid YAML string to Spyc.
Load a valid YAML string to Spyc.
Parameters
Returns
array
Var
mixed
mixed
|
public
array
|
#
loadFile( string $file )
Load a valid YAML file to Spyc.
Load a valid YAML file to Spyc.
Parameters
Returns
array
Var
mixed
mixed
|
public static
array
|
#
YAMLLoad( string $input )
Load YAML into a PHP array statically
Load YAML into a PHP array statically
The load method, when supplied with a YAML stream (string or file), will do
its best to convert YAML in a file into a PHP array. Pretty simple. Usage:
$array = Spyc::YAMLLoad('lucky.yaml');
print_r($array);
Parameters
- $input
string $input Path of YAML file or string containing YAML
Returns
array
Var
mixed
mixed
|
public static
array
|
#
YAMLLoadString( string $input )
Load a string of YAML into a PHP array statically
Load a string of YAML into a PHP array statically
The load method, when supplied with a YAML string, will do its best to
convert YAML in a string into a PHP array. Pretty simple.
Note: use this function if you don't want files from the file system loaded
and processed as YAML. This is of interest to people concerned about security
whose input is from a string.
Usage:
$array = Spyc::YAMLLoadString("---\n0: hello world\n");
print_r($array);
Parameters
- $input
string $input String containing YAML
Returns
array
Var
mixed
mixed
|
public static
string
|
#
YAMLDump( array $array, integer $indent = false, integer $wordwrap = false )
Dump YAML from PHP array statically
Dump YAML from PHP array statically
The dump method, when supplied with an array, will do its best to convert the
array into friendly YAML. Pretty simple. Feel free to save the returned string
as nothing.yaml and pass it around.
Oh, and you can decide how big the indent is and what the wordwrap for
folding is. Pretty cool -- just pass in 'false' for either if you want to use
the default.
Indent's default is 2 spaces, wordwrap's default is 40 characters. And you
can turn off wordwrap by passing in 0.
Parameters
- $array
array $array PHP array
- $indent
integer $indent Pass in false to use the default, which is 2
- $wordwrap
integer $wordwrap Pass in 0 for no wordwrap, false for default (40)
Returns
string
Var
mixed
mixed
|
public
string
|
#
dump( array $array, integer $indent = false, integer $wordwrap = false )
Dump PHP array to YAML
The dump method, when supplied with an array, will do its best to convert the
array into friendly YAML. Pretty simple. Feel free to save the returned string
as tasteful.yaml and pass it around.
Oh, and you can decide how big the indent is and what the wordwrap for
folding is. Pretty cool -- just pass in 'false' for either if you want to use
the default.
Indent's default is 2 spaces, wordwrap's default is 40 characters. And you
can turn off wordwrap by passing in 0.
Parameters
- $array
array $array PHP array
- $indent
integer $indent Pass in false to use the default, which is 2
- $wordwrap
integer $wordwrap Pass in 0 for no wordwrap, false for default (40)
Returns
string
Var
mixed
mixed
|
public
|
|
Magic methods summary
Constants summary
Properties summary
public
boolean
|
$setting_dump_force_quotes
|
#
Setting this to true will force YAMLDump to enclose any string value in
quotes. False by default.
Setting this to true will force YAMLDump to enclose any string value in
quotes. False by default.
|
public
boolean
|
$setting_use_syck_is_possible
|
#
Setting this to true will forse YAMLLoad to use syck_load function when
possible. False by default.
Setting this to true will forse YAMLLoad to use syck_load function when
possible. False by default.
|
public
mixed
|
$_nodeId
|
|


Audio output
dac = T("dac", ...); // ... Input objects which will be processed dac = T("pandac", pan=0.5, ...); // pan [Object] // ... Input objects which will be processed
dac.pan [Object]
synth = T("saw", 880, 0.25); dac = T("dac", synth); dac.pan = T("+sin", 0.5); dac.play();
synth = T("sin", 880).play(); // In fact, the above code is the shortcut, it's the same as below. synth = T("sin", 880); dac = T("dac", synth); dac.play(); synth.dac === dac; // true // A play() method creates a T("dac") object if it is not exists, // and appends self to it, and T("dac").play().


Mohamed Ali Essid
Cooking is my passion😋
Today's menu:
Mille Feuilles de Legumes
https://github.com/udacity/Appetizer
Tagliatelles au chèvre
https://github.com/udacity/Entrée
Macarons
https://github.com/udacity/Dessert


Photo booth fam kinfolk cold-pressed sriracha leggings jianbing microdosing tousled waistcoat.
Alper KamuPhoto booth fam kinfolk cold-pressed sriracha leggings jianbing microdosing tousled waistcoat.
Holden CaulfieldPhoto booth fam kinfolk cold-pressed sriracha leggings jianbing microdosing tousled waistcoat.
Henry Letham


Available in iOS, Android and Amazon store
DOWNLOAD THE APPWe are passionate about growing plants and food, living sustainably, and preserving our environment. If we all do this together, as communities, we can create a better world.
This is why we are transforming gardening into a fun and social activity.


name: inverse layout: true class: center, middle, inverse --- # Placeholder page 1 of 2 .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- layout: false .left-column[ ## Testing ] .right-column[ # Placeholder page 2 of 2 - Presentation is running - This panel is for testing projectors ] .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- template: inverse # Some
Typescript
stuff [ OneLogin Tech Talk: Feb 22 2019 ] .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ---
Henlo, Frens
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ??? Henlo, Frens ---
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ??? I'm Dot Warner ---
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ??? As you know, I'm an economist --- template: inverse # This typescript talk
is about economics
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ??? And that's probably good, because this talk is about economics --- # What is Typescript .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ??? Oh, stop it. We all know what Typescript is by now. --- # What is Typescript It's
type annotations
. ``` const someNum = 5, theBool = false, aString = 'Bob Dobbs', myArray = [ 1, 'two', 3 ], myIntAr = [ 1, 2, 3 ], myObj = { one: 1, two: 2 }, myFun = num => num * 2; ``` becomes ``` const someNum : number = 5, theBool : boolean = false, aString : string = 'Bob Dobbs', myArray : array = [ 1, 'two', 3 ], myIntAr : array
= [ 1, 2, 3 ], myObj : object = { one: 1, two: 2 }, myFun = num => num * 2; ``` .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ??? The basic case is adding type annotations to stuff --- # The Why of Typescript .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # The Why of Typescript
TypeScript forces you to consider
corner cases you hadn't been thinking about
. .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # The Why of Typescript
Let's do a quick debugging session. ```javascript function NoLeapYear_DayCount(WhichMonth) { switch (WhichMonth) { case 'January' : return 31; case 'February' : return 28; case 'March' : return 31; case 'April' : return 30; case 'May' : return 31; case 'June' : return 30; /* case 'July' : return 30; */ case 'August' : return 31; case 'September' : return 30; case 'October' : return 31; case 'November' : return 30; case 'December' : return 31; } } ``` .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # The Why of Typescript
Consider support libraries. .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ??? Consider when the shared component repo changes out from under you. --- # Let's talk about mistakes Everybody makes them. .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ??? Let's talk about mistakes. Everybody makes them. --- # Let's talk about mistakes Everybody makes them.
Even Topher
.
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ??? Even Topher. --- template: inverse # We spend
half of our time
debugging .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # No really, it's half
Let's look at some data .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # No really, it's half
Let's look at some data 1. [Rogue Wave Software](https://l.facebook.com/l.php?u=https%3A%2F%2Fweb.archive.org%2Fweb%2F20140725200714%2Fhttps%3A%2F%2Fwww.roguewave.com%2FDesktopModules%2FBring2mind%2FDMX%2FDownload.aspx%3Fentryid%3D1606%26command%3Dcore_download%26PortalId%3D0%26TabId%3D607&h=AT03sAi2worRSTNkrV1rZIMl3aho4ko91YTANaittcL3vB1Sl4Uuv5qS2OlNYVrbUZMK-JNBO3RVPDSbywaD6CKpjkYIRJ9zHkHHXk5UZCPb8b-XNNc3r0Edcg4gMNhawFbDsBrJ) is in
about 10% of IDEs worldwide
(mostly MSVS and Eclipse) .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # No really, it's half
Let's look at some data 1. Rogue Wave Software is in about 10% of IDEs 1. They say we spend about
49% of our time developing
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # No really, it's half
Let's look at some data 1. Rogue Wave Software is in about 10% of IDEs 1. They say we spend about 49% of our time developing 1. Of that,
about 52% debugging
(a quarter of our total time) .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # No really, it's half
Let's look at some data 1. Rogue Wave Software is in about 10% of IDEs 1. They say we spend about 49% of our time developing 1. Of that, about 52% debugging 1. ClusterHQ [did a survey of 400 people](https://web.archive.org/web/20170613051156/https://clusterhq.com/2016/11/03/devops-testing-survey/) .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # No really, it's half
Let's look at some data 1. Rogue Wave Software is in about 10% of IDEs 1. They say we spend about 49% of our time developing 1. Of that, about 52% debugging 1. ClusterHQ did a survey of 400 people 1. 43% of them said they
debug production issues 10-25% of the time
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # No really, it's half
Let's look at some data 1. Rogue Wave Software is in about 10% of IDEs 1. They say we spend about 49% of our time developing 1. Of that, about 52% debugging 1. ClusterHQ did a survey of 400 people 1. 43% of them said they debug production issues 10-25% of the time 1. 11% of them said
25-50%
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # No really, it's half
Let's look at some data 1. Rogue Wave Software is in about 10% of IDEs 1. They say we spend about 49% of our time developing 1. Of that, about 52% debugging 1. ClusterHQ did a survey of 400 people 1. 43% of them said they debug production issues 10-25% of the time 1. 11% of them said 25-50% 1. Microsoft Research studied production code .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # No really, it's half
Let's look at some data 1. Rogue Wave Software is in about 10% of IDEs 1. They say we spend about 49% of our time developing 1. Of that, about 52% debugging 1. ClusterHQ did a survey of 400 people 1. 43% of them said they debug production issues 10-25% of the time 1. 11% of them said 25-50% 1. Microsoft Research studied production code 1. MSR says prod has
16-51 defects per 1000 lines
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # No really, it's half
Let's look at some data 1. Rogue Wave Software is in about 10% of IDEs 1. They say we spend about 49% of our time developing 1. Of that, about 52% debugging 1. ClusterHQ did a survey of 400 people 1. 43% of them said they debug production issues 10-25% of the time 1. 11% of them said 25-50% 1. Microsoft Research studied production code 1. MSR says prod has 16-51 defects per KLOC 1. MSR says programmers write
around 70 bugs per KLOC
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # No really, it's half
Let's look at some data 1. Rogue Wave Software is in about 10% of IDEs 1. They say we spend about 49% of our time developing 1. Of that, about 52% debugging 1. ClusterHQ did a survey of 400 people 1. 43% of them said they debug production issues 10-25% of the time 1. 11% of them said 25-50% 1. Microsoft Research studied production code 1. MSR says prod has 16-51 defects per 1000 lines 1. MSR says programmers write around 70 bugs per KLOC 1. MSR says
mostly bugs are prevented or caught, not discovered
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # No really, it's half
Let's look at some data 1. Rogue Wave Software is in about 10% of IDEs 1. They say we spend about 49% of our time developing 1. Of that, about 52% debugging 1. ClusterHQ did a survey of 400 people 1. 43% of them said they debug production issues 10-25% of the time 1. 11% of them said 25-50% 1. Microsoft Research studied production code 1. MSR says prod has 16-51 defects per 1000 lines 1. MSR says programmers write around 70 bugs per KLOC 1. MSR says mostly bugs are prevented or caught, not discovered 1. MSR says
the main variance is language
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # This isn't going to change .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # This isn't going to change
1. This has been true
forever
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # This isn't going to change
1. This has been true forever 1. Boehm
measured 40-50% in 1986
for IEEE *
Boehm, Barry W. 1987. "Improving Software Productivity." IEEE Computer, September: 43-57.; Jones, Capers, ed. 1986.
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # This isn't going to change
1. This has been true forever 1. Boehm measured 40-50% in 1986 for IEEE 1. Kernighan says that Bell Labs expected for
debugging to be twice as hard as writing
when planning work *
Kernighan, Plaugher 1989. "The Elements of Programming Style" McGraw Hill .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # This isn't going to change
1. This has been true forever 1. Boehm measured 40-50% in 1986 for IEEE 1. Kernighan says Bell Labs expected debugging to be 2x writing 1. This
is going to be true forever
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # This isn't going to change
1. This has been true forever 1. Boehm measured 40-50% in 1986 for IEEE 1. This is going to be true forever 1. Modern university research supported it [just last year](https://azaidman.github.io/publications/bellerICSE2018.pdf?fbclid=IwAR2b4ccEnPPzTXuKivDIKLfWaVD5hrOx__lNApMJZwlgGQiuANIj1UU55vI) *
Beller et al, 2018. "On the Dichotomy of Debugging Behavior Among Programmers" Delft TU Netherlands
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # This isn't going to change
1. This has been true forever 1. Boehm measured 40-50% in 1986 for IEEE 1. This is going to be true forever 1. Modern university research supported it just last year 1. Zeller found across 200 companies a spearman correlation of 0.81 suggesting
5x work drop
between weeks invested in testing and weeks invested in development *
A. Zeller, 2009. "Why Programs Fail, Second Edition: A Guide to Systematic Debugging 2nd ed." Morgan Kaufmann
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # This isn't going to change
1. This has been true forever 1. Boehm measured 40-50% in 1986 for IEEE 1. This is going to be true forever 1. Modern university research supported it just last year 1. Zeller found 5x work drop for testing vs development time 1. Zeller also found
18x work drop with type systems
*
A. Zeller, 2009. "Why Programs Fail, Second Edition: A Guide to Systematic Debugging 2nd ed." Morgan Kaufmann
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # This isn't going to change
1. This has been true forever 1. Boehm measured 40-50% in 1986 for IEEE 1. This is going to be true forever 1. Modern university research supported it just last year 1. Zeller found 5x work drop for testing vs development time 1. Zeller also found 18x work drop with type systems 1. There are durable results
from the 1970s until today
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # What do we know? .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # What do we know?
1. This is
mostly about language
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # What do we know?
1. This is mostly about language 1. U. Waterloo did a [large scale code study](https://cs.uwaterloo.ca/~m2nagapp/courses/CS846/1171/papers/ray_fse14.pdf) .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ---
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ??? Here's one of the study tables, to let you know what their dataset was like. 729 projects. 29,000 programmers. 80 million lines of code. 1.6 million commits. --- # What do we know?
1. This is mostly about language 1. U. Waterloo did a [large scale code study](https://cs.uwaterloo.ca/~m2nagapp/courses/CS846/1171/papers/ray_fse14.pdf) 1. It contains: * 729 projects. * 28,948 programmers. * 80 million lines of code. * 1.6 million commits. .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ??? This is the largest public formal study of code ever done. --- # What do we know?
1. This is mostly about language 1. U. Waterloo did a large scale code study 1. 729 projects. 29k devs. 80 MLOC. 1.6m commits. 1.
1996 to 2014.
19 years of code. .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ??? This isn't about development methodology, tool use, or whatever. This study traverses 19 years of code and sees similar numbers in every year. ---
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ??? This *does* seem to be about language class and paradigm. --- # What do we know?
1. This is mostly about language 1. U. Waterloo did a large scale code study 1. 729 projects. 28,948 programmers. 1.6 million commits. 1. 1996 to 2014. 1.
17 languages
were checked. .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ??? Statistically significant differences were found between language class and paradigm. Statically typed languages resulted in an 8% reduction in defects vs dynamic. Languages used functionally resulted in a 19% reduction in defects vs procedural imperative. These benefits rapidly get stronger as the team size grows. --- # What about large industry? .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # What about large industry?
1. It's useful to look at big companies .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ??? Large companies sometimes use similar tools, and can offer a more focused perspective on results. --- # What about large industry?
1. It's useful to look at big companies 1. Let's pretend that
AirBNB is like us
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ??? AirBNB offers a very similar stack to ours, running with a much larger count of developers --- # What about large industry?
1. It's useful to look at big companies 1. AirBNB is like us 1. AirBNB extensively uses
testing and linting
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ??? AirBNB maintains the most popular lint config, and tons of code quality tools. They do a whole lot of code auditing over about 250 programmers. ---
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ??? AirBNB found in post-mortem that TypeScript could have prevented 38% of the bugs they sent to production. This is across ***all languages***. --- # What about large industry?
1. It's useful to look at big companies 1. AirBNB is like us 1. TypeScript could have prevented 38% of production bugs 1. That's
more than a third of your debugging time back
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # Do the math .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # Do the math
1. Assume you work 40 hours a week. Ha. .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # Do the math
1. Assume you work 40 hours a week. Ha. 1. 49% programming of 40 hours is
19.6 hours
. 1. 52% debugging of 19.6 hours is
10.1 hours
. 1. 38% saved of 10.1 hours is
3.87 hours
a week. .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # Do the math
1. Assume you work 40 hours a week. Ha. 1. 49% programming of 40 hours is 19.6 hours. 1. 52% debugging of 19.6 hours is 10.1 hours. 1. 38% saved of 10.1 hours is 3.87 hours a week.
That's 2.14 workdays a month
. .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # Do the math
1. Assume you work 40 hours a week. Ha. 1. 49% programming of 40 hours is 19.6 hours. 1. 52% debugging of 19.6 hours is 10.1 hours. 1. 38% saved of 10.1 hours is 3.87 hours a week. That's 2.14 workdays a month.
That's 9.6% of your time
. .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ---
That's 25 days a year
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ??? That's 25 days a year. That's five work weeks. ---
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] ??? Would you like five free work weeks a year? --- # In summation .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # In summation
1.

The company wants 10% more work from you
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- # In summation
1.  The company wants 10% more work from you 1.
Y'all should have listened to Matej
.footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)] --- template: inverse # Thank you for
your time
[ OneLogin Tech Talk: Feb 22 2019 ] .footnote[[Propaganda site](https://stonecypher.github.io/typescript_talk_feb2019/#3)]