Image Scaling¶
Image scaling now is A LOT EASIER with eemont! Let’s see how!
Before anything, let’s import our modules and authenticate in Google Earth Engine:
import ee, eemont
ee.Authenticate()
ee.Initialize()
Now, we are ready to go!
Overview¶
The eemont package extends the ee.Image and ee.ImageCollection classes with the following methods:
ee.Image¶
|
Gets the offset parameters for each band of the image. |
|
Gets the scale parameters for each band of the image. |
|
Pre-processes the image: masks clouds and shadows, and scales and offsets the image. |
|
Scales bands on an image according to their scale and offset parameters. |
ee.ImageCollection¶
|
Gets the offset parameters for each band of the image collection. |
|
Gets the scale parameters for each band of the image collection. |
|
Pre-processes the image collection: masks clouds and shadows, and scales and offsets the image collection. |
|
Scales bands on an image collection according to their scale and offset parameters. |
Supported Platforms¶
This method automatically scales ALL images from the Google Earth Engine STAC Catalog by using the List of Scale and Offset Paramaters from the GEE STAC Catalog Repository.
Usage¶
The scaleAndOffset()
method scales each image according to the Scale and Offset parameters for each band of the image.
Let’s take the Sentinel-2 SR image collection as example:
S2 = ee.ImageCollection('COPERNICUS/S2_SR')
The spectral bands from Sentinel-2 have values close to the (0, 10000) range, but they’re unscaled. In order to get the real values, each spectral band must be multiplied by 0.0001, while AOT and WVP bands must be multiplied by 0.001. This scaling is automatically done by the scaleAndOffset()
method, without any additional parameters:
S2.scaleAndOffset()
The Scale and Offset parameters vary according to the satellite platform and the scaleAndOffset()
method detects the platform and do the scaling according to its parameters.
Let’s take now the MOD11A2 product from MODIS. The LST_Day_1km and LST_Night_1km bands must be multiplied by 0.02, the Day_view_time and Night_view_time bands must be multiplied by 0.1,
the Emis_31 and Emis_32 bands must be multiplied by 0.002 and added by 0.49, while the Day_view_angl and Night_view_angl bands must be added by -65. All of this scaling
is simply done by the scaleAndOffset()
method:
MOD11A2scaled = ee.ImageCollection('MODIS/006/MOD11A2').scaleAndOffset()
The scale()
method can be applied to single images as well:
MOD11A2scaled = ee.ImageCollection('MODIS/006/MOD11A2').first().scaleAndOffset()
Preprocessing¶
Additionally, if required, the preprocess()
method can be used to scale and mask images and image collections:
S2 = ee.ImageCollection('COPERNICUS/S2_SR').preprocess()


TensorFlow.js example: Trains LSTM model to perform the following sequence task:
Given a sequence of 0s and 1s of fixed length (10), output a single binary number (0 or 1).
The training data has the following pattern:
The output (i.e., label) is 1 if there are four or more consecutive and identical items (either 0s or 1s) in the input sequence. Otherwise, the output is 0. For example:
| Train Examples: |
| Epoch: | |
| Training loss: | |
| Training accuracy: | |
| Validation loss: | |
| Validation accuracy: |
| Input: | |
| Results: |


You agree that by accessing the Application, you have permitted the use of
Kandy CPaaS JavaScript SDK
and bound by their
License
agreement.
×
Audio & Video Chat App
Authenticate using your account information
Server URL:
Password Grant
Client Credentials
Client ID:
User Email:
Password:
Login
Private project key:
Private project secret:
Login
Subscribe To Call Service Websocket Channel
Subscribe
Make a Call
Make Call
to
with video
Respond to a Call
Answer Call
with video
Reject Call
End a Call
End Call
Remote video:
Local video:
Terminal


Version 1.2
Freezed at March 6, 2002
| AUTHOR | : | Hans-Gert Graebe |
| ADDRESS | : | Univ. Leipzig, Institut f. Informatik, D - 04109 Leipzig, Germany |
| URL | : | http://www.informatik.uni-leipzig.de/~graebe |
| : |<EMAIL_ADDRESS>|
The GeoProver (formerly GEOMETRY) is a small package for mechanized (plane) geometry manipulations with non degeneracy tracing, available for different CAS platforms (Maple, MuPAD, Mathematica, and Reduce).
It provides the casual user with a couple of procedures that allow him/her to mechanize his/her own geometry proofs. Version 1.1 grew out from a course of lectures for students of computer science on this topic held by the author at the Univ. of Leipzig in fall 1996 and was updated after a similar lecture in spring 1998.
The (completely revised) version 1.2, finished in March 2002, was set up as a generic software project to manage the code for different platforms in a unified way. Even most of the function names changed due to more concise naming conventions. There is a close relationship to the SymbolicData project (see http://www.symbolicdata.org/).
For examples we refer to the SymbolicData GEO table that contains many proof schemes of geometry theorems, mainly from Chou's book, and an interface from SymbolicData to the GeoProver.
Comments, bug reports, hints, wishes, criticisms etc. are welcome. Please send them to the author.
If you have used the GeoProver in the preparation of a publication, please cite it in the following format (in particular, refer explicitely to the used version):
\bibitem{GeoProver} H.-G. Gr\"abe. \newblock {\sc GeoProver} 1.2 -- {A Small Package for Mechanized Plane Geometry Theorem Proving}, 2002. \newblock {With versions for Reduce, Maple, MuPAD and Mathematica.}\\ See \url{http://www.informatik.uni-leipzig.de/~compalg/software}.
If you are using BibTeX, you can use the following BibTeX entry
@Misc{GeoProver, author = {Gr\"abe, H.-G.}, title = {{\sc GeoProver} 1.2 -- {A Small Package for Mechanized Plane Geometry Theorem Proving}}, year = {2002}, note = {{With versions for Reduce, Maple, MuPAD and Mathematica.}\\ See \url{http://www.informatik.uni-leipzig.de/~compalg/software} }, }
Malte Witte translated the code of version 1.1 from Reduce to Maple, MuPAD, and Mathematica and filled the SymbolicData GEO table with many examples from mechanized geometry theorem proving, mainly from Chou's book.
Benjamin Friedrich collected examples and solutions with geometric background from IMO contests.


WITNESS LIST Business & Commerce Committee March 1, 2001 -12:00P SB 11 FOR: Bowers, Dee (Self), Katy, TX Braun, Catherine (Self), Houston, TX Goertz, MD, Roland (Texas Medical Association), Waco, TX Halligan, Mike (Texas Mental Health Consumers), Austin, TX Hayes, Aaryce (Advocacy, Inc.), Austin, TX Levinson, Cynthia (Patients' Assistance League/Breast Cancer Resource Center), Austin, TX Marshall, Susan (The Arc of Texas), Austin, TX McAnally, Bruce (Independent Pharmacy), McKinney, TX McGiffert, Lisa (Consumers Union), Austin, TX AGAINST: Cobb, Ronald H. (American Insurance Association), Austin, TX Gonzales, David A. (Texas Pharmacy Association), Austin, TX Guilbert, Terry V. (Texas Society of Health Systems Pharmacists) Hammond, Bill (Texas Association of Business and Chambers of Commerce), Austin, TX Heasley, John (Texas Bankers Association), Austin, TX Jones, William (Materials Transportation and TABCC), Temple, TX Kautz, Margaret (Employers), Houston, TX Kowalski, Robert (Parkland Community Health Plan/Texas Association of Health Plans), Dallas, TX Nance, Millard (H.E.Butt Grocery and Texas Federation of Drug Stores), San Antonio, TX Neeley, Karen (Independent Bankers Association of Texas), Austin, TX Thompson, Jay (Texas Association Life Health Insurers; AFACT; Prudential; Farm Bureau Ins. Cos.), Austin, TX ON: Beckett, Sheila (ERS), Austin, TX Chernov, MD, Allan (AETNA), Dallas, TX Davis, Will (Texas Association of Life and Health Insurers), Austin, TX Donoho, Patrick (Pharmaceutical Care Management Assciation), Arlington, TX Easterly, Mark (Christus Health and Texas Hospital Association), Houston, TX Gates, Carole (Cigna/HIAA), Kansas City, KS Guckian, Dr. Jim Vice Chancellor for Health Affairs (The University of Texas System), Austin, TX Hahn, Chrisopher H. (Texas Employment Law Council), Austin, TX Jenkins, Kristin (JPS Health Network), Forth Worth, TX Jewell, Cindy (Baylor College of Medicine), Houston, TX Lindloff, Keith (Texas Children's Hospital), Houston, TX Porto, MD, Maurine D. (Community First Health Plans/TAHP), San Antonio, TX Registering, but not testifying: For: Banning, Tom (Texas Academy of Family Physicians), Austin, TX Borel, Dennis (Coalition of Texans with Disablilties), Austin, TX Bush, John R. (Texas Society of Psychiatric Physicians), Austin, TX Fisher, Christine (Texas Mental Health Consumers), Austin, TX Gant, Melanie (Mental Health Association in Texas), Austin, TX Mizcles, Amy (National Alliance for the Mentally Ill of Texas), Austin, TX Parker, Carl (Legend/TRU Care Pharmacy Association), Austin, TX Against: Guinn, Joe (Pacificare of Texas), San Antonio, TX Herman, B. Michael (Health Insurance Association of America), Washington, DC Ireland, Jill (TAHP), San Antonio, TX Pinkus, David R. (Small Business United of Texas), Austin, TX Rummel, Leah (Texas Association of Health Plans), Austin, TX Sandberg, Eric (Texas Savings and Community Bankers Association), Austin, TX Yatsu, MD, Dr. John (Texas Association Business and Chambers of Commerce), Austin, TX On: Durden, David (Texas Department of Insurance), Austin, TX Furgiuele, Tracy C. (Merck Medco), Dublin, OH Rushing, Linda (Texas Conference of Catholic Health Facilities), Austin, TX Samuels, Marc (Disease Management Association of America), Austin, TX Wall, Matthew T. (Texas Hospital Association), Austin, TX Weigman, Linda S. (Texas Department of Health), Austin, TX Wong, Bala (Self), Austin, TX


Rom Patcher JS
Creator mode
ROM file:
CRC32:
MD5:
SHA-1:
Remove header before patching
Add temporary header
(
)
Patch file:
Apply patch
Original ROM:
Modified ROM:
Patch type:
IPS
BPS
PPF
UPS
APS
RUP
Create patch


Texas Court Halts Execution of Convicted Murderer on Death Row for 23 Years - Legal Group
WASHINGTON (Sputnik) - The Texas Court of Criminal Appeals has stopped the scheduled execution next week of convicted murderer Rodney Reed, who has been in jail awaiting execution for more than 20 years, the Innocence Project announced.
“The Texas Court of Appeals has granted Rodney Reed an indefinite stay of execution, which means he no longer has an execution date”, the Innocence Project said in a news report on Friday.
A spokeswoman for the Court of Criminal Appeals said the new ruling to put a hold on the execution would soon be posted on its official website, the Innocence Project said.
Earlier on Friday, the Texas Board of Pardons and Paroles voted unanimously to recommend that state Governor Greg Abbott delay the execution by 120 days. Reed had been due to be executed by lethal injection this coming Wednesday.
Rodney Reed was convicted for the 1996 murder of Stacey Stites, a 19-year-old grocery store worker in central Texas. New witnesses, however, have come forward and forensic evidence has been re-evaluated leading to growing calls for a new trial, the Innocence Project said.


Allow our talents to shine through
Balance spirit and matter
Thrive in our relationships
Have a more positive impact
M Men
A Association
N Networking
T Teamwork
R Responsibility
A Action
Men ages 18 and up
Virtual Zoom
Nov 20-Nov 22, 2020
Start: Friday Nov 20, Evening Eastern Time
Finish: Sunday Nov 22, Evening Eastern Time
Kirtan, sanga, connecting, contributing, philosophy, comedy, drama, group projects, designing strategies for success, and other cool stuff!
We're excited to bring you the first virtual MAN-tra retreat and share with you insights from a variety of men from all across the world. Before completing your registration we are asking every man to offer a donation according to his means. Registration for MAN-tra enables you to attend all of the sessions, or any mix of sessions of your choice.
Please note your PayPal Transaction ID/Confirmation Number. This will be required for you to complete your registration.
NOTE: A donation of any size is sufficient to complete the registration form. If you are unable to contribute, please contact us via email<EMAIL_ADDRESS>and we will complete the registration on your behalf. These funds will be used to cover the cost of this year's event and be seed money for future MAN-tra retreats.
Step 1: Select Donation Amount
Step 2: After noting down your PayPal Confirmation number, click below to complete registration.
Register+1<PHONE_NUMBER> (WhatsApp Call only)


Just how rainy was that wet weekend on Vancouver Island?
But don't fret, there's plenty of sun in the forecast for Victoria this week
Heavy rain pounded parts of Vancouver Island on the weekend as an “atmospheric river” hammered the B.C. Coast, said Environment Canada.
Ucluelet was the hardest hit with 210 millimetres of rain.
Here’s a summary of rainfall totals in millimetres collected by Environment Canada for Saturday and Sunday until 4 p.m:
- Malahat: 33
- Victoria University: 27
- Esquimalt Harbour: 35
- Bowser: 53
- Tofino: 167
- Ucluelet: 210
- North Courtenay: 42
- Campbell RIver: 23
- Zeballos: 106
By comparison, the Lower Mainland was not as wet as Vancouver Island’s West Coast:
- Vancouver Harbour: 66
- Vancouver International Airport: 34
- Pitt Meadows: 49
- White Rock: 30
- Lynn Valley: 99
- West Vancouver: 69
- Abbotsford Airport: 42
- Eagle Ridge: 61
- Agassiz: 45
- Cultus Lake: 37
- Squamish: 70
- Port Mellon: 102
- Brandywine: 64
- Pender Harbour: 40
- Westwood Plateau: 117
In addition to rain, the atmospheric river also brought warm temperatures to B.C., and new records were set in several communities.
On the Island, temperatures reached 15.9 C at Victoria International Airport, edging out the 15.6 C mark set in 1932. Records have been kept at the airport since 1932. Campbell River reached 12.0 C, breaking a record of 11.7 C from 1976. Records have been kept in that area since 1958.
Things are looking up in Greater Victoria this week with sunshine in the forecast for Tuesday, Wednesday, Thursday and Friday, with highs between 8 C and 11 C. More details here.


| Class | Description |
|---|---|
| AutonomousBlueBotmk2 |
runs
AutonomousLinearBotmk2 set up for blue |
| AutonomousLinearBotmk2 |
contains all the code to run Autonomous, it has no inherent side
|
| AutonomousRedBotmk2 |
runs
AutonomousLinearBotmk2 set up for red |
| ColorTest |
prints the values of a color sensor
|
| FtcOpModeRegister |
determines which OpModes show uop on the control phone screen
|
| sensorTest |
prints all sensor values
|
| TeleOpBlue |
runs
TeleOpOctopus set up for blue |
| TeleOpOctopus |
contains all the code to run TeleOp, it has no inherent side
|
| TeleOpRed |
runs
TeleOpOctopus set up for red |


Natasha Rooney - @thisNatasha
HTTP, TCP, HTTPS, TLS, XHR Reqests, HTTP2, UDP...
(old APIs, new APIs, super cool ultra new APIs)
3G |
4G |
|
|---|---|---|
| Data Throughput | Up to 3.1Mbps with an average speed range between 0.5 to 1.5 Mbps | Practically speaking, 2 to 12 Mbps (Telstra in Australia claims up to 40 Mbps) but potential estimated at a range of 100 to 300 Mbps. |
| Peak Upload Rate | 5 Mbps | 500 Mbps |
| Peak Download Rate | 100 Mbps | 1 Gbps |
| Switching Technique | packet switching | packet switching, message switching |
| Network Architecture | Wide Area Cell Based | Integration of wireless LAN and Wide area. |
| Services And Applications | CDMA 2000, UMTS, EDGE etc | Wimax2 and LTE-Advance |
| Forward error correction (FEC) | 3G uses Turbo codes for error correction. | Concatenated codes are used for error corrections in 4G. |
| Frequency Band | 1.8 – 2.5 GHz | 2 – 8 GHz |
source: GSMA Intelligence
3G, LTE, 2G, Pigeon (maybe not pigeon)...
var x = "Is the browser online? " + navigator.onLine;
document.getElementById("demo").innerHTML = x;
Originally: "Exposes the current connection type. The value returned is one of the following strings, case-sensitively: unknown, ethernet, wifi, 2g, 3g, 4g, none.""
(comparable to some WiFi networks)
//onchange event
navigator.connection.addEventListener('change', show, false);
//get bandwidth
if (navigator.connection.bandwidth > 2) {
i.src = "http://example.com/pony_hd.png";
} else {
i.src = "http://example.com/pony_ld.png";
}
But I can't use push...
// Connect to server, listen for messages, manage data:
var source = new EventSource('/stats');
source.onopen = function () {
connectionOpen(true);
};
source.onerror = function () {
connectionOpen(false);
};
source.addEventListener('connections', updateConnections,false);
source.addEventListener('requests', updateRequests, false);
source.addEventListener('uptime', updateUptime, false);
source.onmessage = function (event) {
// a message without a type was fired
};
(W3C Working Draft)
//register
function registerPush() {
navigator.push.register().then(
function(value) {
pushRegistrations.push(value);
registerWithAppServer(value);
},
function(reason) {alert("error: "+ reason);}
);
}
//handler
navigator.setMessageHandler("push", gotPush);
//manage the message
function gotPush(message) {
//do stuff
}
source: http://www.w3.org/TR/push-api/
Native App Win?
//register
CACHE MANIFEST
# 2013-10-22:v1
# Explicitly cached
CACHE:
/offlineanime/anime.json
/offlineanime/app/css/app.css
/offlineanime/app/img/404.png
/offlineanime/app/lib/angular/angular.js
/offlineanime/app/lib/angular/angular-route.js
/offlineanime/app/js/controllers.js
/offlineanime/app/js/app.js
/offlineanime/app/partials/anime-list.html
/offlineanime/app/partials/anime-detail.html
# Resources that require the user to be online.
NETWORK:
# Don't actually need other URLs because * covers them
# Needed * for ajax requests
*
FALLBACK:
http://static.hummingbird.me /offlineanime/app/img/404.png #doesn't work!
(What is cached? How hold are they? Is an update available?)
(Based on Promises)
this.addEventListener("install", function(e) {
//Create a cache of resources. Begins the process of fetching them.
var shellResources = new Cache(
"/app.html",
"/assets/v1/base.css",
"/assets/v1/app.js",
"/assets/v1/logo.png",
"/assets/v1/intro_video.webm",
);
//Add Cache to the global so it can be used later during onfetch
caches.set("shell-v1", shellResources);
//The coast is only clear when all the resources are ready.
e.waitUntil(shellResources.ready());
});
this.addEventListener("fetch", function(e) {
//No "onfetch" events are dispatched to the ServiceWorker
//until it successfully installs.
//All operations on caches are async, including matching URLs, so we use
//Promises heavily. e.respondWith() even takes Promises to enable this:
e.respondWith(caches.match(e.request.url, "shell-v1"));
});
source: https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md
this.addEventListener("fetch", function(e) {
var url = e.request.url;
if (url == inventory) {
e.respondWith(
fetch(url).then(
null,
function() { return caches.match(fallbackInventory); }
)
);
}
});
source: https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md
(just a few)
Especially:
Ilya Grigorik (@igrigorik), Jake Archibald (@jaffathecake), Alex Russell (@slightlylate),
GSMA Intelligence, W3C WebApps, SysApps, DeviceApps WGs, W3C Webmob IG
Read Ilya's Book! "High Performance Browser Networking"


Unhappy people
Amount of coffee
Lightbulbs in use
Bugs killed
Baseball players
Babies born today
Amount of fish in the see
Golf balls lost today


§27C-1 Purpose. The purpose of this chapter is to provide a centralized, statewide information service, through which the public's information needs can be most effectively served and by which agencies can coordinate and maintain communication with the community. [L 1971, c 106, §1; am L 1976, c 187, pt of §1]


{{ book.title }}
Book metadata
ISBN:
{{ book.isbn }}
Book description
{{ book.description }}
Also was read by:
{% for reader in book.readers %}
{{ reader.username }}
{% endfor %}


The following displays the entropy (random numbers) used to generate the seed phrase above.
The entropy below was generated using a random number generator, but you can edit the
fields below to use your own randomness to generate the seed phrase (you can't go wrong
with a set of dice). You can also enter
your own seed phrase directly if you prefer.
Because there is a standard for generating seed phrases for Bitcoin (called
BIP39),
and because we use this same standard to generate BitClout seed phrases,
BitClout seed phrases can also be used with any Bitcoin wallet that implements
this standard under the m/44'/0'/0'/0/0 derivation path (e.g.
Mycelium,
Electrum).
Similarly, any standard
Bitcoin seed phrase you have can also be used as an BitClout seed phrase. Of course, all
of this can be verified using a tool like the
Ian Coleman mnemonic generator
(must click "show entropy details") so you know this generator is doing what it says it is.


Vaadin Themes
Vaadin Themes
Install
To start using a theme, you need to install at least one Vaadin Core Element (such as vaadin-text-field ) and the vaadin-themes package.
If you install the vaadin-core-elements bundle you get all the necessary dependencies.
Install individual elements…
bower install --save vaadin-text-field
bower install --save vaadin-themes
…or install the bundle
bower install --save vaadin-core-elements#master
Until there’s a stable release for vaadin-themes, you need to install the master
branch of vaadin-core-elements.
Import a theme
After installing, import any element specific theme files you need. Here, we are importing the Valo theme for vaadin-text-field.
You need to import the theme for an element before the actual element itself.
Next steps
Next, you can start customizing the theme to your needs.
Built-in theme customization
Check the individual theme documentations to see what features they offer and which customizations are easy to do out of the box:
If there’s something you can’t accomplish with the built-in customization options, read the advanced styling and theming instructions.
If you want to create a completely new theme from scratch, read the instructions how to build and distribute your own theme .
If you need to support Internet Explorer 11 or Edge 14, read the browser compatibility instructions to avoid situations where your application doesn’t look the same in all browsers.


@(user: models.User)
The Simpsons Quiz was developed as part of the students lab
Question Answering Technologies Behind
IBM Watson
offered by the
Language Technology Group at Technische Universität Darmstadt and uses IBM Watson technology.
It was created in 2015 by Stefan Bauregger, Timo Gerecht, Daniel Theiß and Ute Winchenbach.
The Simpsons® is a registered trademark of 20th Century Fox.
Images from Wikisimpsons.


fprime.common.models.serialize.type_base
¶
Created on Dec 18, 2014
@author: reder Replaced type base class with decorators
Module Contents¶
Classes¶
|
An abstract base defining the methods supported by all base classes. |
|
An abstract base type used to represent a single value. This defines the value property, allowing for setting and |
Functions¶
|
Routine to show bytes in buffer for testing. |
-
class
fprime.common.models.serialize.type_base.
BaseType
[source]¶ Bases:
abc.ABC
An abstract base defining the methods supported by all base classes.
-
class
fprime.common.models.serialize.type_base.
ValueType
(val=None)[source]¶ Bases:
fprime.common.models.serialize.type_base.BaseType
,abc.ABC
An abstract base type used to represent a single value. This defines the value property, allowing for setting and reading from the .val member.
-
abstract
validate
(self, val)[source]¶ Checks the val for validity with respect to the current type. This will raise TypeMissmatchException when the validation fails of the val’s type fails. It will raise TypeRangeException when val is out of range.
- Parameters
val – value to validate
- Raises
TypeMismatchException – value has incorrect type, TypeRangeException: val is out of range
-
abstract
-
fprime.common.models.serialize.type_base.
showBytes
(byteBuffer)[source]¶ Routine to show bytes in buffer for testing.
Build: 1.4.1


I had the dubious pleasure of trying to figure out how to get some Web Parts that I developed deployed to a SharePoint site in order to demo for a client. I had the Web Parts working in a test host outside of SharePoint so I figured it wouldn’t be a big deal to get them pushed to a real SharePoint installation. Well, you might guess it took me a little longer to work this situation out, since I’m taking the time to write about it here.
First attempt – manual deployment
The first shot I took was to drop the binaries out to the SharePoint server as outlined here. It should be possible to drop the assemblies under the bin/ folder of the SharePoint site, allow the assembly as safe code in web.config, and pull it into the Web Part catalog using the following admin page:
1
|
|
Individual SharePoint sites are set up under the IIS Inetpub/ folder structure by default, so this is roughly the path we are looking at:
1
|
|
Needless to say I couldn’t get this to work. The problem was that nothing showed up in the admin page. The assembly was being loaded since I was getting errors if I messed up the web.config file, but alas, no luck getting the parts to display.
Second attempt – using WSPBuilder
Having failed at a quick and dirty approach, I moved my Web Parts to proper WSPBuilder Web Part projects. This is what you get if you create a new Visual Web Part project in Visual Studio. I also tried to create a WSPBuilder deployment project, but this didn’t do what I wanted. There seemed to be a place where you could put your Web Part code, but it didn’t look like what I wanted. Someone feel free to correct me on this.
One small note when creating a WSPBuilder project is that we want to give it the specific SharePoint site we want to work with, as this is the worker process that Visual Studio will attach to. So if the site is on a different port, you’ll want to specify the full URL like this assuming that the site is on port 5559:
1
|
|
After un-mangling the default names and namespaces and moving my existing code into the new project layout, I hit F5 and crossed my fingers. The Web Parts get installed under a catalog section called “Custom”. I was almost there at this point, but for some reason WSPBuilder was not adding the correct namespaces to the trusted assemblies list in web.config. I figured this out by having the site open in Windows Explorer and noticing that WSPBuilder was making backup copies of web.config every time I deployed. When you stop debugging it restores the previous web.config, removing any changes to the trusted assemblies configuration.
I manually added the assembly to web.confg like this:
1
|
|
So now that I had my code running I poked around to figure out where things were ending up. SharePoint puts things generally in one of three places:
1) The GAC 2) IIS root (inetpub) 3) SharePoint “hive” C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES\
By default, WSPBuilder seems to install the assemblies in the GAC. There is a configuration option clearly visible on the project for this setting. The .webpart xml configuration goes into the hive, and changes to web.config happen under the IIS root.
Hopefully this helps you to figure out where the heck all of this stuff ends up when deploying Web Parts to SharePoint. It takes a while to get used to.


A dependency tracking library for Silverlight 5 in the spirit of KnockoutJS. Based on Update Controls.
Other .NET client libraries coming soon. If yours isn't supported yet, please consider using Update Controls.
Create a POCO model.
public class Model { public virtual string FirstName { get; set; } public virtual string LastName { get; set; } }
Add computed fields.
private void MainPage_Loaded(object sender, RoutedEventArgs e) { Model model = KO.NewObservable<Model>(); DataContext = KO.ApplyBindings(model, new { FullName = KO.Computed(() => model.FirstName + " " + model.LastName) }); }
Bind.
<TextBox Text="{Binding FirstName, Mode=TwoWay}"/> <TextBox Text="{Binding LastName, Mode=TwoWay}"/> <TextBlock Text="{Binding FullName}"/>
To install KnockoutCS from NuGet, run the following command in the Package Manager Console
PM> Install-Package KnockoutCS
Source code is available on GitHub. Please fork the code and contribute.


Mary Reilly
Mary Reilly is a movie starring Julia Roberts, John Malkovich, and George Cole. A housemaid falls in love with Dr. Henry Jekyll (John Malkovich) and his darkly mysterious counterpart, Mr. Edward Hyde.


Panel Show Db
People
Data
Kelvin MacKenzie's panel show appearances
Kelvin MacKenzie has appeared in
0
episodes between 10000-0.
Kelvin MacKenzie on Wikipedia
.


1) There are 4 sections: Order Components, Omelets, Weekly Specials, and Extras.
Examples of
what goes into each are given. Please add each type to the specified section.
2) Note that this is the way the orders will appear on the client's side.
| Index | Details | |
|---|---|---|
| {{orderComponent.componentIndex}} |
{{orderComponent.name}}
|
|
| Index | Details | |
|---|---|---|
| {{omelet.componentIndex}} |
{{omelet.name}}
|
|
| Index | Details | |
|---|---|---|
| {{weeklySpecial.componentIndex}} |
{{weeklySpecial.name}}
|
|
| Index | Details | |
|---|---|---|
| {{extra.componentIndex}} |
{{extra.name}}
|
|


Use the Show Pop-up and Hide Pop-up animations to show and hide custom pop-up UI.
Show pop-up
This is a pop-up.


Enumeration members
AvailableContacts
AvailableContacts: = "contacts.available"
Defined in node_modules/vsls/vscode.ts:541
BadFeedback
BadFeedback: = "help.badFeedback"
Defined in node_modules/vsls/vscode.ts:560
Contact
Contact: = "contacts.contact"
Defined in node_modules/vsls/vscode.ts:544
ContactOffline
ContactOffline: = "contacts.contact.offline"
Defined in node_modules/vsls/vscode.ts:545
ContactsProvider
ContactsProvider: = "contacts.provider"
Defined in node_modules/vsls/vscode.ts:542
CurrentUser
CurrentUser: = "participants.currentuser"
Defined in node_modules/vsls/vscode.ts:518
DontAskAgain
DontAskAgain: = "help.dontAskAgain"
Defined in node_modules/vsls/vscode.ts:561
FollowedGuest
FollowedGuest: = "participants.guest.followed"
Defined in node_modules/vsls/vscode.ts:520
FollowedGuestAnonymous
FollowedGuestAnonymous: = "participants.guest.followed.anonymous"
Defined in node_modules/vsls/vscode.ts:525
FollowedGuestElevated
FollowedGuestElevated: = "participants.guest.followed.elevated"
Defined in node_modules/vsls/vscode.ts:528
FollowedParticipant
FollowedParticipant: = "participants.participant.followed"
Defined in node_modules/vsls/vscode.ts:522
GoodFeedback
GoodFeedback: = "help.goodFeedback"
Defined in node_modules/vsls/vscode.ts:559
Guest
Guest: = "participants.guest"
Defined in node_modules/vsls/vscode.ts:519
GuestAnonymous
GuestAnonymous: = "participants.guest.anonymous"
Defined in node_modules/vsls/vscode.ts:524
GuestElevated
GuestElevated: = "participants.guest.elevated"
Defined in node_modules/vsls/vscode.ts:527
InvitedContact
InvitedContact: = "contacts.invited"
Defined in node_modules/vsls/vscode.ts:552
Loading
Loading: = "loading"
Defined in node_modules/vsls/vscode.ts:566
LocalServer
LocalServer: = "servers.local"
Defined in node_modules/vsls/vscode.ts:531
LocalTerminalReadOnly
LocalTerminalReadOnly: = "terminals.local.readonly"
Defined in node_modules/vsls/vscode.ts:535
LocalTerminalReadWrite
LocalTerminalReadWrite: = "terminals.local.readwrite"
Defined in node_modules/vsls/vscode.ts:536
MoreInfo
MoreInfo: = "help.moreinfo"
Defined in node_modules/vsls/vscode.ts:563
NoContact
NoContact: = "contacts.noContact"
Defined in node_modules/vsls/vscode.ts:548
NoRecentContacts
NoRecentContacts: = "contacts.NoRecentContacts"
Defined in node_modules/vsls/vscode.ts:551
NoSuggestedContacts
NoSuggestedContacts: = "contacts.NoSuggestedUsers"
Defined in node_modules/vsls/vscode.ts:550
Other
Other: = "other"
Defined in node_modules/vsls/vscode.ts:569
Participant
Participant: = "participants.participant"
Defined in node_modules/vsls/vscode.ts:521
Participants
Participants: = "participants"
Defined in node_modules/vsls/vscode.ts:513
RecentContact
RecentContact: = "contacts.recentContact"
Defined in node_modules/vsls/vscode.ts:546
RecentContactOffline
RecentContactOffline: = "contacts.recentContact.offline"
Defined in node_modules/vsls/vscode.ts:547
RecentContacts
RecentContacts: = "contacts.RecentContacts"
Defined in node_modules/vsls/vscode.ts:549
RemoteServer
RemoteServer: = "servers.remote"
Defined in node_modules/vsls/vscode.ts:532
RemoteTerminal
RemoteTerminal: = "terminals.remote"
Defined in node_modules/vsls/vscode.ts:537
ReportAProblem
ReportAProblem: = "help.reportAProblem"
Defined in node_modules/vsls/vscode.ts:556
SelfContact
SelfContact: = "contacts.selfContact"
Defined in node_modules/vsls/vscode.ts:543
Servers
Servers: = "servers"
Defined in node_modules/vsls/vscode.ts:514
SessionFeedbackQuestion
SessionFeedbackQuestion: = "help.sessionFeedback"
Defined in node_modules/vsls/vscode.ts:555
SuggestedContacts
SuggestedContacts: = "contacts.suggested"
Defined in node_modules/vsls/vscode.ts:540
Survey
Survey: = "help.survey"
Defined in node_modules/vsls/vscode.ts:558
Terminals
Terminals: = "terminals"
Defined in node_modules/vsls/vscode.ts:515
Thankyou
Thankyou: = "help.thankyou"
Defined in node_modules/vsls/vscode.ts:562
TweetUsYourFeedback
TweetUsYourFeedback: = "help.tweetUsYourFeedback"
Defined in node_modules/vsls/vscode.ts:557
Identifiers for Live Share tree view items. These identifiers may be used by other extensions to extend Live Share tree items with additional commands using conditional expressions in the
view/item/context
section of their own package.json.


Hi.
We've been trying to use the feed API and we're having issues.
Apparently, the documentation is not complete, and we didn't know, when creating a feed, how to pass the parameters (engine, datatype, etc.), so we've been proceeding by trial/error.
Is there any other source of documentation regarding this?
We've been looking in the code as well.
We first tried to pass strings such as "PHPFIWA" but it seems parameters should be passed as integers and we found a file in the code where the corresponding enums are declared.
While playing with the feed create function, we must have introduced broken data that the code should have refused, because now we can't even list the feeds.
Here's a few of the URL we used along with the answers:
http://emoncms.org/feed/create.json?name=test7&tag=1&datatype=2&engine=1 Notice: Undefined offset: 1 in /var/www/emoncms/Modules/feed/feed_model.php on line 113 Fatal error: Call to a member function create() on a non-object in /var/www/emoncms/Modules/feed/feed_model.php on line 113 http://emoncms.org/feed/list.json Notice: Undefined index: 1 in /var/www/emoncms/Modules/feed/feed_model.php on line 297 Fatal error: Call to a member function lastvalue() on a non-object in /var/www/emoncms/Modules/feed/feed_model.php on line 297 http://emoncms.org/feed/delete.json?id=91352 Notice: Undefined index: 1 in /var/www/emoncms/Modules/feed/feed_model.php on line 465 Fatal error: Call to a member function delete() on a non-object in /var/www/emoncms/Modules/feed/feed_model.php on line 465
I think both feeds 91352 and 91353 are concerned.
It looks like we managed to create a feed with an invalid field and when EmonCMS tries to get to the last value to display on the listing page, it calls lastvalue() on an object which is not an engine as expected. More or less the same with the delete() function.
I guess at least wrong entries should be detected and creation process exited with an explicit error.
If this is a bug, and you want to investigate, you may look in the database, as this is on the emoncms.org instance. You may also find all error messages in your webserver logs.
The instance advertise itself as 8.3.5 but surprisingly, the error messages point to lines in the code of that version that don't seem to be related to the message. Any reason for this? For instance, there is no lastvalue() call on line 297.
Should I open an issue on GitHub about this?
Is the feed API used and supported or is this a corner case (most people use input API) that may have other issues?
Is it supposed to cover all functionalities accessible through the GUI? Or is it WIP?
We want to display values about a building (temperatures, power consumption, etc.) that we get through csv files. We generate requests from the csv files. We will process all old csv files then catch up with the building and feed csv files as they come. Since there is no need for processing, it seems logical to use the feed API rather than using inputs and "log to feed". And since there may be a lot of feeds, using the API to create the fields would be a life-saver.
I've been away from OpenEnergyMonitor for a while, so please excuse me if I'm missing the obvious. I'd be happy if we could use EmonCMS in our project. And even more if it was improved in the process.
Edit - wrapped long lines - BT
Re: EmonCMS feed API?
Hello Jerome, thanks for finding and investigating this.
The feed creation method really needs improving as its currently allowing the registering of a feed for an engine that is not actually installed anymore on emoncms.org (engine 1 = timestore) That is then creating the other error's down the line.
The quick fix which I have now added to stop this from happening on emoncms.org is:
but it really needs a better long term solution. The emoncms.org code base is now quite a bit behind version 9.0 which Id recommend looking at if your installing your own server, see Chaveiro's great work here http://openenergymonitor.org/emon/node/11009.
Yes the line numbers on the errors on emoncms.org may not match the github code as I removed all the checks to provide a non redis mysql fall back mode on emoncms.org, the code has become a bit of a mix between the low-write branch of emoncms and v8.5, I need to review it again and work out to what degree it can be moved to the new v9 release too.
Re: EmonCMS feed API?
Hi Trystan.
Thank your for your answer.
We might install EmonCMS on our server. In this case, I suppose we'll go for a recent code version so that we can benefit from all latest features and perhaps contribute if possible.
My colleague started with the emoncms.org instance as a test to check EmonCMS was a correct fit for the project's needs. He is currently stuck because the feed list does not load due to feeds 91352 and 91353 being broken. I'm afraid there's nothing we can't do about it without DB access. Would it be possible for your to delete them manually from the DB? Or should he create a new account?
Is the feed API any safer in v9.0? Would you recommend its use (I mean the use of the API, not of v9.0)? Maybe if we validate the use of EmonCMS for the project we can justify spending a bit of time securing and documenting the feed API.
I guess the doc should include a comprehensive list of parameters (tag, engine, datatype, etc.) and the possible values or enum description for each of them. Or better, the API could accept strings instead of integers (like 'PHPFIWA' instead of whatever the number is).


Press k, or the button below to toggle the console.
In the console, write help for a list of commands...


In linear regression our main interest was centered on learning the coefficients of a functional fit (say a polynomial) in order to be able to predict the response of a continuous variable on some unseen data. The fit to the continuous variable \( y^{(i)} \) is based on some independent variables \( \boldsymbol{x}^{(i)} \). Linear regression resulted in analytical expressions for standard ordinary Least Squares or Ridge regression (in terms of matrices to invert) for several quantities, ranging from the variance and thereby the confidence intervals of the parameters \( \boldsymbol{w} \) to the mean squared error. If we can invert the product of the design matrices, linear regression gives then a simple recipe for fitting our data.
Classification problems, however, are concerned with outcomes taking the form of discrete variables (i.e. categories). We may for example, on the basis of DNA sequencing for a number of patients, like to find out which mutations are important for a certain disease; or based on scans of various patients' brains, figure out if there is a tumor or not; or given a specific physical system, we'd like to identify its state, say whether it is an ordered or disordered system (typical situation in solid state physics); or classify the status of a patient, whether she/he has a stroke or not and many other similar situations.
The most common situation we encounter when we apply logistic regression is that of two possible outcomes, normally denoted as a binary outcome, true or false, positive or negative, success or failure etc.
Logistic regression will also serve as our stepping stone towards neural network algorithms and supervised deep learning. For logistic learning, the minimization of the cost function leads to a non-linear equation in the parameters \( \boldsymbol{w} \). The optimization of the problem calls therefore for minimization algorithms. This forms the bottle neck of all machine learning algorithms, namely how to find reliable minima of a multi-variable function. This leads us to the family of gradient descent methods. The latter are the working horses of basically all modern machine learning algorithms.
We note also that many of the topics discussed here on logistic regression are also commonly used in modern supervised Deep Learning models, as we will see later.
We consider the case where the dependent variables (also called the responses, targets, or outcomes) are discrete and only take values from \( k=0,\dots,K-1 \) (i.e. \( K \) classes).
The goal is to predict the output classes from the design matrix \( \boldsymbol{X}\in\mathbb{R}^{n\times p} \) made of \( n \) samples, each of which carries \( p \) features or predictors. The primary goal is to identify the classes to which new unseen samples belong.
We will use the following notation:
Let us specialize to the case of two classes only, with outputs \( t^{(i)} \in \{0,1\} \). That is $$ t^{(i)} = \begin{bmatrix} 0 \\ 1 \end{bmatrix} = \begin{bmatrix} \mathrm{no}\\ \mathrm{yes} \end{bmatrix}. $$
Before moving to the logistic model, let us try to use our linear regression model to classify these two outcomes. We could for example fit a linear model to the default case if \( y^{(i)} > 0.5 \) and the no default case \( y^{(i)} \leq 0.5 \).
We would then have our weighted linear combination, namely $$ \begin{equation} \boldsymbol{\tilde{y}} = \boldsymbol{X}^T\boldsymbol{w} + \boldsymbol{\epsilon}, \label{_auto1} \end{equation} $$ where \( \boldsymbol{y} \) is a vector representing the possible outcomes, \( \boldsymbol{X} \) is our \( n\times p \) design matrix and \( \boldsymbol{w} \) represents our estimators/predictors.
The main problem with our function is that it takes values on the entire real axis. In the case of logistic regression, however, the labels \( t^{(i)} \) are discrete variables.
One simple way to get a discrete output is to have sign functions that map the output of a linear regressor to values \( y^{(i)} \in \{ 0, 1 \} \), \( y^{(i)} = f(\tilde{y}^{(i)})=\frac{\mathrm{sign}(\tilde{y}^{(i)})+1}{2} \), which will map to one if \( \tilde{y}^{(i)}\ge 0 \) and zero otherwise. We will encounter this model in our first demonstration of neural networks. Historically it is called the perceptron model in the machine learning literature. This model is extremely simple. However, in many cases it is more favorable to use a soft classifier that outputs the probability of a given category. This leads us to the logistic function.
The perceptron is an example of a "hard classification" model. We will encounter this model when we discuss neural networks as well. Each datapoint is deterministically assigned to a category (i.e \( y^{(i)}=0 \) or \( y^{(i)}=1 \)). In many cases, it is favorable to have a "soft" classifier that outputs the probability of a given category rather than a single value. For example, given \( \boldsymbol{x}^{(i)} \), the classifier outputs the probability of being in a category \( k \). Logistic regression is the most common example of such a soft classifier. In logistic regression, the probability that a data point \( \boldsymbol{x}^{(i)} \) belongs to a category \( t^{(i)} \in \{0,1\} \) is given by the so-called logit function (an example of a S-shape or Sigmoid function) which is meant to represent the likelihood for a given event, $$ y(\boldsymbol{x}; \boldsymbol{w}) = y(a) = \frac{1}{1+e^{-a}} = \frac{e^a}{1+e^a}, $$ where the so called activation \( a = a(\boldsymbol{x}; \boldsymbol{w}) \).
We assume now that we have two classes with \( t^{(i)} \) being either \( 0 \) or \( 1 \). Furthermore we assume also that we have only two parameters \( w_0, w_1 \) and the predictors \( \boldsymbol{x}^{(i)} = \{ 1, x^{(i)} \} \) defining the Sigmoid function. I.e., there is a single independent (input) variable \( x \). We can produce probabilities from the classifier output \( y^{(i)} \) $$ \begin{align*} p(t^{(i)}=1|x^{(i)},\boldsymbol{w}) &= y(a^{(i)})= \frac{\exp{(w_0+w_1x^{(i)})}}{1+\exp{(w_0+w_1x^{(i)})}},\\ p(t^{(i)}=0|x^{(i)},\boldsymbol{w}) &= 1 - p(t^{(i)}=1|x^{(i)},\boldsymbol{w}) = \frac{1}{1+\exp{(w_0+w_1x^{(i)})}}, \end{align*} $$ where \( \boldsymbol{w} = ( w_0, w_1) \) are the weights we wish to extract from training data.
Note that \( [p(t^{(i)}=0), p(t^{(i)}=1)] \) is a discrete set of probabilities that we will still refer to as a probability distribution.
In this course we will obviously also advocate (or at least make aware of) the more probabilistic approach to learning about these parameters.
In order to define the total likelihood for all possible outcomes from a dataset \( \mathcal{D}=\{(x^{(i)}, t^{(i)},)\} \), with the binary labels \( t^{(i)}\in\{0,1\} \) and where the data points are drawn independently, we use the binary version of the Maximum Likelihood Estimation (MLE) principle. We express the likelihood in terms of the product of the individual probabilities of a specific outcome \( t^{(i)} \), that is $$ \begin{align*} \mathcal{L} = P(\mathcal{D}|\boldsymbol{w})& = \prod_{i=1}^n \left[p(t^{(i)}=1|x^{(i)},\boldsymbol{w})\right]^{t^{(i)}}\left[1-p(t^{(i)}=1|x^{(i)},\boldsymbol{w}))\right]^{1-t^{(i)}}\nonumber \\ \end{align*} $$ from which we obtain the log-likelihood $$ L \equiv \log(\mathcal{L}) = \sum_{i=1}^n \left( t^{(i)}\log{p(t^{(i)}=1|x^{(i)},\boldsymbol{w})} + (1-t^{(i)})\log\left[1-p(t^{(i)}=1|x^{(i)},\boldsymbol{w}))\right]\right). $$
The cost/loss function is then defined as the negative log-likelihood $$ \mathcal{C}(\boldsymbol{w}) \equiv -L = -\sum_{i=1}^n \left( t^{(i)}\log{p(t^{(i)}=1|x^{(i)},\boldsymbol{w})} + (1-t^{(i)})\log\left[1-p(t^{(i)}=1|x^{(i)},\boldsymbol{w}))\right]\right). $$
Using the definitions of the probabilities we can rewrite the cost/loss function as $$ \mathcal{C}(\boldsymbol{w}) = -\sum_{i=1}^n \left( t^{(i)}\log{ y(x^{(i)},\boldsymbol{w})} + (1-t^{(i)})\log\left[ 1-y( x^{(i)},\boldsymbol{w}) \right] \right), $$ which can be recognised as the relative entropy between the empirical probability distribution \( (t^{(i)}, 1-t^{(i)}) \) and the probability distribution predicted by the classifier \( (y^{(i)}, 1-y^{(i)}) \). Therefore, this cost function is known in statistics as the cross entropy.
Using specifically the logistic sigmoid activation function with two weights, and reordering the logarithms, we can rewrite the log-likelihood as $$ L(\boldsymbol{w}) = \sum_{i=1}^n \left[ t^{(i)}(w_0+w_1 x^{(i)}) -\log{(1+\exp{(w_0+w_1x^{(i)})})} \right]. $$
The maximum likelihood estimator is defined as the set of parameters (weights) that maximizes the log-likelihood (where we maximize with respect to \( w \)).
Since the cost (error) function is here defined as the negative log-likelihood, for logistic regression, we have that $$ \mathcal{C}(\boldsymbol{w})=-\sum_{i=1}^n \left[ t^{(i)} (w_0+w_1x^{(i)}) -\log{ \left( 1+\exp{(w_0+w_1x^{(i)})} \right) } \right]. $$
In particular, Lasso regularization is obtained by defining another cost function $$ \mathcal{C}_W (\boldsymbol{w}) \equiv \mathcal{C} (\boldsymbol{w}) + \alpha E_W (\boldsymbol{w}) $$ where \( E_W (\boldsymbol{w}) = \frac{1}{2} \sum_j w_j^2 \) and \( \alpha \) is known as the weight decay.
Can you motivate why \( \alpha \) is known as the weight decay? Hint: Recall the origin of this regularizer from a Bayesian perspective.
The cross entropy is a convex function of the weights \( \boldsymbol{w} \) and, therefore, any local minimizer is a global minimizer.
Minimizing this cost function (here without regularization term) with respect to the two parameters \( w_0 \) and \( w_1 \) we obtain $$ \begin{align*} \frac{\partial \mathcal{C}(\boldsymbol{w})}{\partial w_0} &= -\sum_{i=1}^n \left(t^{(i)} -\frac{\exp{(w_0+w_1x^{(i)})}}{1+\exp{(w_0+w_1x^{(i)})}}\right) &= -\sum_{i=1}^n \left(t^{(i)} - y^{(i)} \right), \\ \frac{\partial \mathcal{C}(\boldsymbol{w})}{\partial w_1} &= -\sum_{i=1}^n \left(t^{(i)} x^{(i)} -x^{(i)}\frac{\exp{(w_0+w_1x^{(i)})}}{1+\exp{(w_0+w_1x^{(i)})}}\right) &= -\sum_{i=1}^n x^{(i)} \left(t^{(i)} - y^{(i)} \right). \end{align*} $$
Let us now define a vector \( \boldsymbol{t} \) with \( n \) elements \( t^{(i)} \), an \( n\times 2 \) matrix \( \boldsymbol{X} \) which contains the \( (1, x^{(i)}) \) predictor variables, and a vector \( \boldsymbol{y} \) of the outputs \( y^{(i)} = y(x^{(i)},\boldsymbol{w}) \). We can then express the first derivative of the cost function in matrix form $$ \frac{\partial \mathcal{C}(\boldsymbol{w})}{\partial \boldsymbol{w}} = -\boldsymbol{X}^T\left( \boldsymbol{t}-\boldsymbol{y} \right). $$
Having access to the first derivative we can define an on-line learning rule as follows:
Alternatively, one can perform batch learning for which multiple instances are combined into a batch, and the weights are adjusted following the matrix expression stated above. One can then repeat the training multiple times where each iteration consists of a forward pass (computing the outputs \( \boldsymbol{y} \) given a set of weights \( \boldsymbol{w} \)) and back-propagation in which the gradient is computed and the weights are adjusted. At the end, one hopes to have reached an optimal set of weights.
Within a binary classification problem, we can easily expand our model to include multiple predictors. Our activation function is then (with \( p \) predictors) $$ a( \boldsymbol{x}^{(i)}, \boldsymbol{w} ) = w_0 + w_1 x_1^{(i)} + w_2 x_2^{(i)} + \dots + w_p x_p^{(i)}. $$ Defining \( \boldsymbol{x}^{(i)} \equiv [1,x_1^{(i)}, x_2^{(i)}, \dots, x_p^{(i)}] \) and \( \boldsymbol{w}=[w_0, w_1, \dots, w_p] \) we get $$ p(t^{(i)}=1 | \boldsymbol{w}, \boldsymbol{x}^{(i)}) = \frac{ \exp{ \left( \boldsymbol{w} \cdot \boldsymbol{x}^{(i)} \right) }}{ 1 + \exp{ \left( \boldsymbol{w} \cdot \boldsymbol{x}^{(i)} \right) } }. $$
Until now we have mainly focused on two classes, the so-called binary system. Suppose we wish to extend to \( K \) classes. We will then need to have \( K-1 \) outputs \( \boldsymbol{y}^{(i)} = \{ y_1^{(i)}, y_2^{(i)}, \ldots, y_{K-1}^{(i)} \} \).
Why do we need only \( K-1 \) outputs if there are \( K \) classes?
Let us for the sake of simplicity assume we have only one independent (inout) variable. The activation functions for the outputs are (suppressing the index \( i \)) $$ a_1 = w_{1,0}+w_{1,1}x_1, $$ $$ a_2 = w_{2,0}+w_{2,1}x_1, $$
and so on until the class \( C=K-1 \) class $$ a_{K-1} = w_{(K-1),0}+w_{(K-1),1}x_1, $$
and the model is specified in term of \( K-1 \) so-called log-odds or logit transformations \( y_j^{(i)} = y(a_j^{(i)}) \).
The transformation of the multiple outputs, as described above, to probabilities for belonging to any of \( K \) different classes can be achieved via the so-called Softmax function.
The Softmax function is used in various multiclass classification methods, such as multinomial logistic regression (also known as softmax regression), multiclass linear discriminant analysis, naive Bayes classifiers, and artificial neural networks. Specifically, the predicted probability for the \( k \)-th class given a sample vector \( \boldsymbol{x}^{(i)} \) and a weighting vector \( \boldsymbol{w} \) is (with one independent variable): $$ p(t^{(i)}=k\vert \boldsymbol{x}^{(i)}, \boldsymbol{w} ) = \frac{\exp{(w_{k,0}+w_{k,1}x_1^{(i)})}} {1+\sum_{l=1}^{K-1}\exp{(w_{l,0}+w_{l,1}x_1^{(i)})}}. $$ It is easy to extend to more predictors. The probability for the final class is $$ p(t^{(i)}=K\vert \boldsymbol{x}^{(i)}, \boldsymbol{w} ) = \frac{1} {1+\sum_{l=1}^{K-1}\exp{(w_{l,0}+w_{l,1}x_1^{(i)})}}, $$ which means that the discrete set of probabilities is properly normalized.
Our earlier discussions were all specialized to the case with two classes only. It is easy to see from the above that what we derived earlier is compatible with these equations.


Business
Veterans
American Flag. Credit: Larry Spencer Veteran's Day 2019
Resources
-
Resources for Business Owners with Disabilities
Bybusiness.com editorial staff,business.com writer | Feb 06, 2019
-
Self-Employment & Entrepreneurship
Self-Employment & Entrepreneurship from the Department | Labor's Office of Disability Employment Policy


"If we fail to understand that we are more alike from birth than we are different and treat our children accordingly, our world will continue to be gendered. Undoing these assumptions is not easy, but perhaps we can all think twice before we tell a little boy how brave he is and a little girl how kind or perfect she is."
The gender biases that shape our brains
Melissa Hogenboom is the editor of BBC Reel.


In the previous chapters, we created the telemetry necessary to see and solve problems in production and at all stages of our deployment pipeline, and created fast feedback loops from customers to help enhance organizational learning—learning that encourages ownership and responsibility for customer satisfaction and feature performance, which helps us succeed.
Our goal in this chapter is to enable Development and Operations to reduce the risk of production changes before they are made. Traditionally, when we review changes for deployment, we tend to rely heavily on reviews, inspections, and approvals just prior to deployment. Frequently those approvals are given by external teams who are often too far removed from the work to make informed decisions on whether a change is risky or not, and the time required to get all the necessary approvals also lengthens our change lead times.
The peer review process at GitHub is a striking example of how inspection can increase quality, make deployments safe, and be integrated into the flow of everyone’s daily work. They pioneered the process called pull request, one of the most popular forms of peer review that span Dev and Ops.
Scott Chacon, CIO and co-founder of GitHub, wrote on his website that pull requests are the mechanism that lets engineers tell others about changes they have pushed to a repository on GitHub. Once a pull request is sent, interested parties can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary. Engineers submitting a pull request will often request a “+1,” “+2,” or so forth, depending on how many reviews they need, or “@mention” engineers that they’d like to get reviews from.
At GitHub, pull requests are also the mechanism used to deploy code into production through a collective set of practices they call “GitHub Flow”—it’s how engineers request code reviews, gather and integrate feedback, and announce that code will be deployed to production (i.e., “master” branch).
GitHub Flow is composed of five steps:
These practices, which integrate review and coordination into daliy work, have allowed GitHub to quickly and reliably deliver features to market with high quality and security. For example, in 2012 they performed an amazing 12,602 deployments. In particular, on August 23rd, after a company-wide summit where many exciting ideas were brainstormed and discussed, the company had their busiest deployment day of the year, with 563 builds and 175 successful deployments into production, all made possible through the pull request process.
Throughout this chapter we will integrate practices, such as those used at GitHub, to shift our reliance away from periodic inspections and approvals, and moving to integrated peer review performed continually as a part of our daily work. Our goal is to ensure that Development, Operations, and Infosec are continuously collaborating so that changes we make to our systems will operate reliably, securely, safely, and as designed.
The Knight Capital failure is one of the most prominent software deployment errors in recent memory. A fifteen minute deployment error resulted in a $440 million trading loss, during which the engineering teams were unable to disable the production services. The financial losses jeopardized the firm’s operations and forced the company to be sold over the weekend so they could continue operating without jeopardizing the entire financial system.
John Allspaw observed that when high-profile incidents occur, such as the Knight Capital deployment accident, there are typically two counterfactual narratives for why the accident occurred.†
The first narrative is that the accident was due to a change control failure, which seems valid because we can imagine a situation where better change control practices could have detected the risk earlier and prevented the change from going into production. And if we couldn’t prevent it, we might have taken steps to enable faster detection and recovery.
The second narrative is that the accident was due to a testing failure. This also seems valid, with better testing practices we could have identified the risk earlier and canceled the risky deployment, or we could have at least taken steps to enable faster detection and recovery.
The surprising reality is that in environments with low-trust, command-and-control cultures, the outcomes of these types of change control and testing countermeasures often result in an increased likelihood that problems will occur again, potentially with even worse outcomes.
Gene Kim (co-author of this book) describes his realization that change and testing controls can potentially have the opposite effect than intended as “one of the most important moments of my professional career. This ‘aha’ moment was the result of a conversation in 2013 with John Allspaw and Jez Humble about the Knight Capital accident, making me question some of my core beliefs that I’ve formed over the last ten years, especially having been trained as an auditor.”
He continues, “However upsetting it was, it was also a very formative moment for me. Not only did they convince me that they were correct, we tested these beliefs in the 2014 State of DevOps Report, which led to some astonishing findings that reinforce that building high-trust cultures is likely the largest management challenge of this decade.”
Traditional change controls can lead to unintended outcomes, such as contributing to long lead times, and reducing the strength and immediacy of feedback from the deployment process. In order to understand how this happens, let us examine the controls we often put in place when change control failures occur:
These controls often add more friction to the deployment process by multiplying the number of steps and approvals, and increasing batch sizes and deployment lead times, which we know reduces the likelihood of successful production outcomes for both Dev and Ops. These controls also reduce how quickly we get feedback from our work.
One of the core beliefs in the Toyota Production System is that “people closest to a problem typically know the most about it.” This becomes more pronounced as the work being performed and the system the work occurs in become more complex and dynamic, as is typical in DevOps value streams. In these cases, creating approval steps from people who are located further and further away from the work may actually reduce the likelihood of success. As has been proven time and again, the further the distance between the person doing the work (i.e., the change implementer) and the person deciding to do the work (i.e., the change authorizer), the worse the outcome.
In Puppet Labs’ 2014 State of DevOps Report, one of the key findings was that high-performing organizations relied more on peer review and less on external approval of changes. Figure 41 shows that the more organizations rely on change approvals, the worse their IT performance in terms of both stability (mean time to restore service and change fail rate) and throughput (deployment lead times, deployment frequency).
In many organizations, change advisory boards serve an important role in coordinating and governing the delivery process, but their job should not be to manually evaluate every change, nor does ITIL mandate such a practice.
To understand why this is the case, consider the predicament of being on a change advisory board, reviewing a complex change composed of hundreds of thousands of lines of code changes, and created by hundreds of engineers.
At one extreme, we cannot reliably predict whether a change will be successful either by reading a hundred-word description of the change or by merely validating that a checklist has been completed. At the other extreme, painfully scrutinizing thousands of lines of code changes is unlikely to reveal any new insights. Part of this is the nature of making changes inside of a complex system. Even the engineers who work inside the codebase as part of their daily work are often surprised by the side effects of what should be low-risk changes.
For all these reasons, we need to create effective control practices that more closely resemble peer review, reducing our reliance on external bodies to authorize our changes. We also need to coordinate and schedule changes effectively. We explore both of these in the next two sections.
Whenever we have multiple groups working on systems that share dependencies, our changes will likely need to be coordinated to ensure that they don’t interfere with each other (e.g., marshaling, batching, and sequencing the changes). In general, the more loosely-coupled our architecture, the less we need to communicate and coordinate with other component teams—when the architecture is truly service-oriented, teams can make changes with a high degree of autonomy, where local changes are unlikely to create global disruptions.
However, even in a loosely-coupled architecture, when many teams are doing hundreds of independent deployments per day, there may be a risk of changes interfering with each other (e.g., simultaneous A/B tests). To mitigate these risks, we may use chat rooms to announce changes and proactively find collisions that may exist.
For more complex organizations and organizations with more tightly-coupled architectures, we may need to deliberately schedule our changes, where representatives from the teams get together, not to authorize changes, but to schedule and sequence their changes in order to minimize accidents.
However, certain areas, such as global infrastructure changes (e.g., core network switch changes) will always have a higher risk associated with them. These changes will always require technical countermeasures, such as redundancy, failover, comprehensive testing, and (ideally) simulation.
Instead of requiring approval from an external body prior to deployment, we may require engineers to get peer reviews of their changes. In Development, this practice has been called code review, but it is equally applicable to any change we make to our applications or environments, including servers, networking, and databases.‡ The goal is to find errors by having fellow engineers close to the work scrutinize our changes. This review improves the quality of our changes, which also creates the benefits of cross-training, peer learning, and skill improvement.
A logical place to require reviews is prior to committing code to trunk in source control, where changes could potentially have a team-wide or global impact. At a minimum, fellow engineers should review our change, but for higher risk areas, such as database changes or business-critical components with poor automated test coverage, we may require further review from a subject matter expert (e.g., information security engineer, database engineer) or multiple reviews (e.g., “+2” instead of merely “+1”).
The principle of small batch sizes also applies to code reviews. The larger the size of the change that needs to be reviewed, the longer it takes to understand and the larger the burden on the reviewing engineer. As Randy Shoup observed, “There is a non-linear relationship between the size of the change and the potential risk of integrating that change—when you go from a ten line code change to a one hundred line code, the risk of something going wrong is more than ten times higher, and so forth.” This is why it’s so essential for developers to work in small, incremental steps rather than on long-lived feature branches.
Furthermore, our ability to meaningfully critique code changes goes down as the change size goes up. As Giray Özil tweeted, “Ask a programmer to review ten lines of code, he’ll find ten issues. Ask him to do five hundred lines, and he’ll say it looks good.”
Guidelines for code reviews include:
To ensure that we are not merely rubber stamping reviews, we may also want to inspect the code review statistics to determine the number of proposed changes approved versus not approved, and perhaps sample and inspect specific code reviews.
Code reviews come in various forms:
Close scrutiny of changes in many forms is effective in locating errors previously overlooked. Code reviews can facilitate increased code commits and production deployments, and support trunk-based deployment and continuous delivery at scale, as we will see in the following case study.
Case Study
Code Reviews at Google (2010)
Google is an excellent example of a company that employees trunk-based development and continuous delivery at scale. As noted earlier in this book, Eran Messeri described that in 2013 the processes at Google enabled over thirteen thousand developers to work off of trunk on a single source code tree, performing over 5,500 code commits per week, resulting in hundreds of production deployments per week. In 2010, there were 20+ changes being checked in to trunk every minute, resulting in 50% of the codebase being changed every month.
This requires considerable discipline from Google team members and mandatory code reviews, which cover the following areas:
Figure 42 shows how code review lead times are affected by the change size. On the x-axis is the size of the change, and on the y-axis is the lead time required for code review process. In general, the larger the change submitted for code reviews, the longer the lead time required to get the necessary sign offs. And the data points in the upper-left corner represent the more complex and potentially risky changes that required more deliberation and discussion.
While he was working as a Google engineering director, Randy Shoup started a personal project to solve a technical problem that the organization was facing. He said, “I worked on that project for weeks and finally got around to asking a subject matter expert to review my code. It was nearly three thousand lines of code, which took the reviewer days of work to go through. He told me, ‘Please don’t do that to me again.’ I was grateful that this engineer took the time to do that. That was also when I learned how to make code reviews a part of my daily work.”
Now that we have created peer reviews that reduce our risk, shorten lead times associated with change approval processes, and enable continuous delivery at scale, such as we saw in the Google case study, let us examine the effects of how testing countermeasure can sometimes backfire. When testing failures occur, our typical reaction is to do more testing. However, if we are merely performing more testing at the end of the project, we may worsen our outcomes.
This is especially true if we are doing manual testing, because manual testing is naturally slower and more tedious than automated testing and performing “additional testing” often has the consequence of taking significantly longer to test, which means we are deploying less frequently, thus increasing our deployment batch size. And we know from both theory and practice that when we increase our deployment batch size, our change success rates go down and our incident counts and MTTR go up—the opposite of the outcome we want.
Instead of performing testing on large batches of changes that are scheduled around change freeze periods, we want to fully integrate testing our daily work as part of the smooth and continual flow into production, and increase our deployment frequency. By doing this, we build in quality, which allows us to test, deploy, and release in ever smaller batch sizes.
Pair programming is when two engineers work together at the same workstation, a method popularized by Extreme Programming and Agile in the early 2000s. As with code reviews, this practice started in Development but is equally applicable to the work that any engineer does in our value stream. In this book, we will use the term pairing and pair programming interchangeably, to indicate that the practice is not just for developers.
In one common pattern of pairing, one engineer fills the role of the driver, the person who actually writes the code, while the other engineer acts as the navigator, observer, or pointer, the person who reviews the work as it is being performed. While reviewing, the observer may also consider the strategic direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of his or her attention on the tactical aspects of completing the task, using the observer as a safety net and guide. When the two have differing specialties, skills are transferred as an automatic side effect, whether it’s through ad-hoc training or by sharing techniques and workarounds.
Another pair programming pattern reinforces test-driven development (TDD) by having one engineer write the automated test and the other engineer implement the code. Jeff Atwood, one of the founders of Stack Exchange, wrote, “I can’t help wondering if pair programming is nothing more than code review on steroids….The advantage of pair programming is its gripping immediacy: it is impossible to ignore the reviewer when he or she is sitting right next to you.”
He continued, “Most people will passively opt out [of reviewing code] if given the choice. With pair programming, that’s not possible. Each half of the pair has to understand the code, right then and there, as it’s being written. Pairing may be invasive, but it can also force a level of communication that you’d otherwise never achieve.”
Dr. Laurie Williams performed a study in 2001 that showed “paired programmers are 15% slower than two independent individual programmers, while ‘error-free’ code increased from 70% to 85%. Since testing and debugging are often many times more costly than initial programming, this is an impressive result. Pairs typically consider more design alternatives than programmers working alone and arrive at simpler, more maintainable designs; they also catch design defects early.” Dr. Williams also reported that 96% of her respondents stated that they enjoyed their work more when they programmed in pairs than when they programmed alone.¶
Pair programming has the additional benefit of spreading knowledge throughout the organization and increasing information flow within the team. Having more experienced engineers review while the less experienced engineer codes is also an effective way to teach and be taught.
Case Study
Pair Programming Replacing Broken Code Review Processes at Pivotal Labs (2011)
Elisabeth Hendrickson, VP of Engineering at Pivotal Software, Inc. and author of Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing, has spoken extensively about making every team responsible for their own quality, as opposed to making separate departments responsible. She argues that doing so not only increase quality, but significantly increases the flow of work into production.
In her 2015 DevOps Enterprise Summit presentation, she described how in 2011, there were two accepted methods of code review at Pivotal: pair programming (which ensured that every line of code was inspected by two people) or a code review process that was managed by Gerrit (which ensured that every code commit had two designated people “+1” the change before it was allowed into trunk).
The problem Hendrickson observed with the Gerrit code review process was that it would often take an entire week for developers to receive their required reviews. Worse, skilled developers were experiencing the “frustrating and soul crushing experience of not being able to get simple changes into the codebase, because we had inadvertently created intolerable bottlenecks.”
Hendrickson lamented that “the only people who had the ability to ‘+1’ the changes were senior engineers, who had many other responsibilities and often didn’t care as much about the fixes the more junior developers were working on or their productivity. It created a terrible situation—while you were waiting for your changes to get reviewed, other developers were checking in their changes. So for a week, you would have to merge all their code changes onto your laptop, re-run all the tests to ensure that everything still worked, and (sometimes) you’d have to resubmit your changes for review again!”
To fix the problem and eliminate all of these delays, they ended up dismantling the entire Gerrit code review process, instead requiring pair programming to implement code changes into the system. By doing this, they reduced the amount of time required to get code reviewed from weeks to hours.
Hendrickson is quick to note that code reviews work fine in many organizations, but it requires a culture that values reviewing code as highly as it values writing the code in the first place. When that culture is not yet in place, pair programming can serve as a valuable interim practice.
Because the peer review process is an important part of our control environment, we need to be able to determine whether it is working effectively or not. One method is to look at production outages and examine the peer review process for any relevant changes.
Another method comes from Ryan Tomayko, CIO and co-founder of GitHub and one of the inventors of the pull request process. When asked to describe the difference between a bad pull request and a good pull request, he said it has little to do with the production outcome. Instead, a bad pull request is one that doesn’t have enough context for the reader, having little or no documentation of what the change is intended to do. For example, a pull request that merely has the following text: “Fixing issue #3616 and #3841.”**
That was an actual internal GitHub pull request, which Tomayko critiqued, “This was probably written by a new engineer here. First off, no specific engineers were specifically @mentioned—at a minimum, the engineer should have mentioned their mentor or a subject matter expert in the area that they’re modifying to ensure that someone appropriate reviews their change. Worse, there isn’t any explanation of what the changes actually are, why it’s important, or exposing any of the implementer’s thinking.”
On the other hand, when asked to describe a great pull request that indicates an effective review process, Tomayko quickly listed off the essential elements: there must be sufficient detail on why the change is being made, how the change was made, as well as any identified risks and resulting countermeasures.
Tomayko also looks for good discussion of the change, enabled by all the context that the pull request provided—often, there will be additional risks pointed out, ideas on better ways to implement the desired change, ideas on how to better mitigate the risk, and so forth. And if something bad or unexpected happens upon deployment, it is added to the pull request, with a link to the corresponding issue. All discussion happens without placing blame; instead, there is a candid conversation on how to prevent the problem from recurring in the future.
As an example, Tomayko produced another internal GitHub pull request for a database migration. It was many pages long, with lengthy discussions about the potential risks, leading up to the following statement by the pull request author: “I am pushing this now. Builds are now failing for the branch, because of a missing column in the CI servers. (Link to Post-Mortem: MySQL outage)”
The change submitter then apologized for the outage, describing what conditions and mistaken assumptions led to the accident, as well as a list of proposed countermeasures to prevent it from happening again. This was followed by pages and pages of discussion. Reading through the pull request, Tomayko smiled, “Now that is a great pull request.”
As described above, we can evaluate the effectiveness of our peer review process by sampling and examining pull requests, either from the entire population of pull requests or those that are relevant to production incidents.
So far, we have discussed peer review and pair programming processes that enable us to increase the quality of our work without relying on external approvals for changes. However, many companies still have long-standing processes for approval that require months to navigate. These approval processes can significantly increase lead times, not only preventing us from delivering value quickly to customers, but potentially increasing the risk to our organizational objectives. When this happens, we must re-engineer our processes so that we can achieve our goals more quickly and safely.
As Adrian Cockcroft observed, “A great metric to publish widely is how many meetings and work tickets are mandatory to perform a release—the goal is to relentlessly reduce the effort required for engineers to perform work and deliver it to the customer.”
Similarly, Dr. Tapabrata Pal, technical fellow at Capital One, described a program at Capital One called Got Goo?, which involves a dedicated team removing obstacles—including tools, processes, and approvals—that impede work completion. Jason Cox, Senior Director of Systems Engineering at Disney, described in his presentation at the DevOps Enterprise Summit in 2015 a program called Join The Rebellion that aimed to remove toil and obstacles from daily work.
At Target in 2012, a combination of the Technology Enterprise Adoption Process and Lead Architecture Review Board (TEAP-LARB process) resulted in complicated, long approval times for anyone attempting to bring in new technology. The TEAP form needed to be filled out by anyone wanting to propose new technologies to be adopted, such as a new database or monitoring technologies. These proposals were evaluated, and those deemed appropriate were put onto the monthly LARB meeting agenda.
Heather Mickman and Ross Clanton, Director of Development and Director of Operations at Target, Inc., respectively, were helping to lead the DevOps movement at Target. During their DevOps initiative, Mickman had identified a technology needed to enable an initiative from the lines of business (in this case, Tomcat and Cassandra). The decision from the LARB was that Operations could not support it at the time. However, because Mickman was so convinced that this technology was essential, she proposed that her Development team be responsible for service support as well as integration, availability, and security, instead of relying on the Operations team.
“As we went through the process, I wanted to better understand why the TEAP-LARB process took so long to get through, and I used the technique of ‘the five why’s’....Which eventually led to the question of why TEAP-LARB existed in the first place. The surprising thing was that no one knew, outside of a vague notion that we needed some sort of governance process. Many knew that there had been some sort of disaster that could never happen again years ago, but no one could remember exactly what that disaster was, either,” Mickman observed.
Mickman concluded that this process was not necessary for her group if they were responsible for the operational responsibilities of the technology she was introducing. She added, “I let everyone know that any future technologies that we would support wouldn’t have to go through the TEAP-LARB process, either.”
The outcome was that Cassandra was successfully introduced inside Target and eventually widely adopted. Furthermore, the TEAP-LARB process was eventually dismantled. Out of appreciation, her team awarded Mickman the Lifetime Achievement Award for removing barriers to get technology work done within Target.
In this chapter, we discussed how to integrate practices into our daily work that increase the quality of our changes and reduce the risk of poor deployment outcomes, reducing our reliance on approval processes. Case studies from GitHub and Target show that these practices not only improve our outcomes, but also significantly reduce lead times and increase developer productivity. To do this kind of work requires a high-trust culture.
Consider a story that John Allspaw told about a newly hired junior engineer: The engineer asked if it was okay to deploy a small HTML change, and Allspaw responded, “I don’t know, is it?” He then asked “Did you have someone review your change? Do you know who the best person to ask is for changes of this type? Did you do everything you absolutely could to assure yourself that this change operates in production as designed? If you did, then don’t ask me—just make the change!”
By responding this way, Allspaw reminded the engineer that she was solely responsibility for the quality of her change—if she did everything she felt she could to give herself confidence that the change would work, then she didn’t need to ask anyone for approval, she should make the change.
Creating the conditions that enable change implementers to fully own the quality of their changes is an essential part of the high-trust, generative culture we are striving to build. Furthermore, these conditions enable us to create an ever-safer system of work, where we are all helping each other achieve our goals, spanning whatever boundaries necessary to get there.
Part IV has shown us that by implementing feedback loops we can enable everyone to work together toward shared goals, see problems as they occur, and, with quick detection and recovery, ensure that features not only operate as designed in production, but also achieve organizational goals and organizational learning. We have also examined how to enable shared goals spanning Dev and Ops so that they can improve the health of the entire value stream.
We are now ready to enter Part V: The Third Way, The Technical Practices of Learning, so we can create opportunities for learning that happen earlier and ever more quickly and cheaply, and so that we can unleash a culture of innovation and experimentation that enables everyone to do meaningful work that helps our organization succeed.


In collaboration with Jenna Loyd, Kelly Lytle Hernandez, and Transforming Justice, this year's Design Challenge will explore everyday experiences of policing in Milwaukee. Drawing on video documentaries and workshop transcripts, we will explore how these experiences build on histories of segregation and how they continue to shape divisions in the city, access to shared spaces, and well-being.
Friday, February 1 | 12–1pm | UW Cartography Lab
Please join us to learn more about the project and related Design Challenge activities. We will be there to answer your questions!
Saturday, February 9 | 9am–5pm | More information soon.
Friday, February 22 | 3:30–4:30pm | Science Hall, Room 108
The Million Dollar Hoods (MDH) research team maps and monitors how much local authorities spend on locking up residents in L.A.’s Million Dollar Hoods. Led by Black and Brown women and driven by formerly-incarcerated persons as well as residents of Million Dollar Hoods, the MDH team also provides the only full and public account of the leading causes of arrest in Los Angeles, revealing that drug possession and DUIs are the top booking charges in L.A.’s Million Dollar Hoods. Collectively, this data counters the popular misunderstanding that incarceration advances public safety by removing violent and serious offenders from the streets. In fact, local authorities are investing millions in locking up the County’s most economically vulnerable, geographically isolated, and racially marginalized populations for drug and alcohol-related crimes. This talk provides an introduction to the Million Dollar Hoods project, method, and impact.
Saturday, March 2 | 9am–8pm | UW Cartography Lab
The Design Challenge is a one-day mapping workshop that challenges students (cartographers and geographers, alike) to create a map or a series of maps during an eight-hour stretch. Teams of students work with community partners, topic experts, and data experts on real-world issues. In the past, our students have mapped the hazardous waste trade in North America, fossil data to better understand climate research, and community resources for two ongoing projects.
Afro-American Studies, Center for Humanities, Chican@ and Latin@ Studies, Department of History, Geography Department, Havens Center, Holtz Center, LACIS, Morgridge Center, and UW–Cartography Lab.


Welcome to Our Website!
stylized is a free template designed by NodeThirtyThree for cssMoban.com released under a Creative Commons Attribution 2.5 License. You"re free to use it for both commercial or personal use. I only ask that you link back to my site in some way. Enjoy :)


We don't have any upcoming speaking engagements at the moment.
Until something comes up, make sure you check our YouTube channel and follow us on social media.
If you want us to be part of your event reach out on<EMAIL_ADDRESS>| Event | Start date |
|---|---|
| {{ event.name }} {{ event.name }} | {{ event.date.start }} |


RDF Schema: review.rdfs
1. Introduction
2. Namespaces
3. RDF Classes
5. Examples
C Changes
This document provides a vocabulary specification for the purpose of creating sharable reviews and ratings of blogs, CDs, books, software, anything identifiable.
The vocabulary is suitable for inclusion in any RDF-compatible language : FOAF, RSS etc. This specification only defines the minimum terms needed to provide the review/rating capability, leaving the rest of the resource description to existing, more domain-appropriate vocabularies.
The XML namespace for this vocabulary is
http://www.purl.org/stuff/rev#
and the
recommended prefix is review. i.e. in RDF/XML documents the
following attribute should be included in the rdf:RDF
element :
xmlns:review="http://www.purl.org/stuff/rev#"
Note: Reviews written using the RDF Review Vocabulary are also likely to use terms from the Dublin Core and FOAF namespaces :
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
Refers to the review itself.
Used to describe the reviewer.
Used to say that a work (or other resource) has the review identified.
The media type (Book, Film, Music etc) will be given in a
<review:type>
element.
The suggested value of the rating of the work will be an integer value 1 -
10, in a <review:rating>
element scaled with 1 for
Truly, Madly, Deeply and 10 for Terminator.
The application developer may choose a different scale, or whether to datatype this value (using RDF Datatypes).
The relationship between the work and the creator of the work (author, director...) will usually be expressed using the Dublin Core vocabulary's <dc:creator> element.
mm
is the MusicBrainz namespace
(http://musicbrainz.org/mm/mm-2.1#
),
rdf:nodeID="A0"
points to a foaf:Person
elsewhere
in the file)
<mm:Album rdf:about="http://mm.musicbrainz.org/album/37b9a29b-2d39-441b-9ac6-81770916e5b5">
<dc:title>Aftermath</dc:title>
<review:hasReview>
<review:Review>
<review:rating>8</review:rating>
<review:reviewer rdf:nodeID="A0"/>
<dc:description>Classic.</dc:description>
</review:Review>
</review:hasReview>
<dc:creator>
<mm:Artist rdf:about="http://mm.musicbrainz.org/artist/b071f9fa-14b0-4217-8e97-eb41da73f598"/>
</dc:creator>
</mm:Album>
<mm:Artist rdf:about="http://mm.musicbrainz.org/artist/b071f9fa-14b0-4217-8e97-eb41da73f598">
<dc:title>The Rolling Stones</dc:title>
</mm:Artist>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns="http://www.purl.org/stuff/rev#"
xmlns="http://purl.org/rss/1.0/">
<item rdf:about="http://mm.musicbrainz.org/album/bb4d834e-c21a-4288-bbee-d9b86c6c3f8b">
<dc:title>Every Day</dc:title>
<description></description>
<dc:creator>
<mm:Artist rdf:about="http://mm.musicbrainz.org/artist/7c158ea8-c0aa-410e-bdc1-20bba9759577">
<dc:title>The Cinematic Orchestra</dc:title>
</mm:Artist>
</dc:creator>
<review:hasReview>
<review:Review>
<review:rating>9</review:rating>
<dc:description>Blinding</dc:description>
<review:reviewer>
<foaf:Person>
<foaf:name>Leigh Dodds</foaf:name>
</foaf:Person>
</review:Review>
</review:hasReview>
</item>
</rdf:RDF>
Leigh, Victor, Alf & Me
Review (RVW) Module for RSS 2.0 (Alf Eaton)
SSR-Enabling an RSS 2.0 Module (uses this vocabulary)
Leigh stuff?
FOAF
As a separate document : review.rdfs
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns="http://www.purl.org/stuff/rev#"
xml:base="http://www.purl.org/stuff/rev#">
<rdfs:Class rdf:ID="Review">
<rdfs:comment>A review of an artistic
work</rdfs:comment>
</rdfs:Class>
<rdf:Property rdf:ID="type">
<rdfs:comment>The type of media of a work under
review</rdfs:comment>
</rdf:Property>
<rdf:Property rdf:ID="rating">
<rdfs:comment>A mark out of 10</rdfs:comment>
</rdf:Property>
<rdf:Property rdf:ID="text">
<rdfs:comment>The text of the review</rdfs:comment>
</rdf:Property>
<rdf:Property rdf:ID="hasReview">
<rdfs:comment>Used to associate a work of art with a a
review</rdfs:comment>
<rdfs:domain
rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource"/>
<rdfs:range rdf:resource="#Review"/>
</rdf:Property>
<rdf:Property rdf:ID="reviewer">
<rdfs:comment>The person that has written the
review</rdfs:comment>
<rdfs:domain rdf:resource="#Review"/>
<rdfs:range rdf:resource="http://xmlns.com/foaf/0.1/Person"/>
</rdf:Property>
</rdf:RDF>
Use as you please, attribution/link to this document appreciated
2005-05-10 :
shifted to different server, dud dns (report - Morten)
changed ns/base in RDFS (linked & in text) & RSS example to http://www.purl.org/stuff/rev#
changed examples to use dc:description rather than review:text
various minor editorial changes
(report - Benjamin Nowack)
$Id$
First Draft 26th September 2003
---------------------------------------------------------------------------------
[@@TODO add a bit of OWL and vocabulary status markers]
[@@TODO update XSLT in SSR example to use this and RVW]
[@@TODO put review:type values in]
[@@TODO make dc:description in RSS feed describe the media - e.g. 'CD single'?]
Danny Ayers 2005


{% extends "base.html" %} {% block title %}
Medieval catalogues > NEW FRIARS > Cambridge-Austin > Leland, c. 1536-1440
{% endif %}7 identified entries found.
All data was derived from the List of Identifications by Professor Richard Sharpe.
{% if not printing %}
A key to codes used in the List is available (opens in new tab).{% endif %}


| Datum | Artikel | Rating |
|---|---|---|
| 12.12.2015 |
*HELP* unconfirmed/double spend transaction: how to solve it?
|
15 |
| 11.12.2015 |
Eugene Kaspersky: Cryptocurrencies Will Be Banned
|
218 |
| 11.12.2015 |
Should You Invest In Bitcoin?
|
240 |
| 12.11.2015 |
Bitcoin Breaks Out Higher
|
93 |


and the with were for cells was SARSâ€�CoVâ€� cholesterol etÂ al, pseudovirus Caluâ€� entry membrane that infection viral (FigÂ plasma from SARSâ€�CoV- fusion The virus Î¼M accessible lung {background treated CHH are using â€" SARSâ€�CoV cell cells. human infected not activity ACAT margin medium EtOH For spike treatment {border-style Â±Â ALOD inhibits MERSâ€�CoV data epithelial protein px;} #ffffff;} VSV fluorescence prior this HCâ€�treated luciferase meanÂ performed represents through tâ€�test. washed Scale TMPRSS Vero analyzed bar, expression patients results Bar coronavirus quantified which COVIDâ€�â€�infected Cells entry. incubated mechanism organoids type Î¼m. EGFP antiviral assay depletion further induced into lipid pretreated Then, USAâ€�WA/ has measured postâ€�infection. postâ€�transfection, (FigsÂ ACE Cell RNA These analysis cells, could encoding fresh infection. COVIDâ€� Figure HC. MOIÂ Source Western but ethanol inhibition supernatant then used (Liu A). After Cacoâ€� Data PBS SZâ€� Student's blocked challenged containing examined host our pseudovirus. px; studies viruses without {font-family & (HC) ****PÂ California DMSO HC, San additional binding captured concentrations confirmed control coronaviruses effect file. font-size formation found healthy immune including incubation indicate interferon membrane. min. nuclei other pseudovirus, rescue Â°C Î¼M) *PÂ B). COVIDâ€�-infected COVIDâ€�. Click FigÂ LINK Luciferase Nat Since Statistical also antibody arrows available bound camostat double; enzyme expressing function fusion. have here indicated inhibit isolate lysed microscope obtained pLVX postâ€�infection, respiratory restricts role severe showed significantly stained syncytia three two under Â°C. (Hoffmann ***PÂ **PÂ Altogether, D). DiegoLa Next, RNAâ€�seq SARSâ€�CoVâ€�, This according affect after against amount associated based been blotting. border-color border-width both broad bronchoalveolar calculated cellular cellâ€"cell compared depletes depleting does donors doseâ€�dependent during entry, esterification figure. gene inhibited inhibitors its mediated min online presence pseudoviruses receptor rescues shRNA show signals solid; their these transduced transfected twice virusâ€"cell visualized whether {font-style {font-weight â€� â€�well (B) (Blancoâ€�Melo (Forward: (G, (addgene C). Cholesterol E). EGFPâ€�expressing Human III JollaCAUSA[], LipidSpot Mol Our Reverse: SARSâ€�CoV, SARSâ€�CoVâ€�. Sandoz Sci White absence activating acyltransferase acylâ€�CoA:cholesterol analyses any bold broadly can caused cleavage conducted courier; culture data, determine disease each effective em; essential evidence experimental extracted first four fusion, inhibitor inhibitory innate intracellular inÂ lavage line lysed, mechanisms membrane, microscopy. mouse new nonâ€�targeting one overnight plasmids postâ€�infection postâ€�inoculation, previously primers product provide pt;} quantify relative removed scRNAâ€�seq shown spikeâ€�mediated statin subjected subsequently subunit syncytia. syndrome system targeting therapeutic thereby titer upon upâ€�regulated upâ€�regulation use vehicle work â€".e â€�Hydrocholesterol