Boolean ObjDoRelocation( /* returns true if error */ ObjRelocationType type, /* type of relocation */ MemHandle block, /* handle of info block */ void * sourceData, /* source of relocation */ void * destData); /* relocated value */
This routine relocates a given word or dword argument and is used for resolving handles and pointers to movable objects. Most often, relocation and unrelocation occur when resources are loaded, swapped, or saved, and this is in most cases taken care of by the kernel.
ObjDoRelocation()
takes four parameters:
type
RelocationType
). This can be one of the three values shown below.
block
sourceData
destData
sourceData
and
type
, above.
The type of relocation to be done affects the type of data passed in
sourceData
and
destData
. The relocation type is passed in the type parameter and must be one of the following enumerations of
RelocationType
:
sourceData
pointer should be cast to type word, and the
destData
pointer should be cast to type Handle.
sourceData
pointer should be cast to type word, and the
destData
pointer should be cast to type Segment.
sourceData
pointer and the
destData
pointer should be cast to type dword.
ObjDoRelocation()
returns an error flag that will be
true
if an error occurs,
false
otherwise.
The relocation done by this routine can be undone with
ObjDoUnRelocation()
.
Include: object.h
Boolean ObjDoUnRelocation( /* returns true if error */ ObjRelocationType type, /* type of relocation */ MemHandle block, /* handle of info block */ void * sourceData, /* source of relocation */ void * destData); /* relocated value */
This routine unrelocates a given word or dword. It translates a handle, a segment address, or an entry point back into a resource ID. The translation done is the exact reverse of that done by
ObjDoRelocation()
. See that routine (above) for more information.
ObjDoUnRelocation()
returns an error flag that will be
true
if an error occurs and
false
if the unrelocation is successful. The unrelocated resource ID will be returned pointed to by the
destData
pointer.
Include: object.h
See Also: ObjDoRelocation()
.
EventHandle ObjDuplicateMessage( EventHandle msg); /* event to duplicate */
This routine duplicates a prerecorded event, returning the event handle of the new event. Pass the handle of the event to be duplicated. You can then change information about the event with
MessageSetDestination()
.
Include: object.h
MemHandle ObjDuplicateResource( MemHandle blockToDup, /* handle of resource; must * not be loaded */
GeodeHandle owner, /* owner of duplicate */ ThreadHandle burdenThread); /* burden thread of duplicate */
This routine duplicates an entire object resource block. The new block will be put on the "saved blocks" list so it gets saved to the geode's state file. Usually this is used by the UI to make editable copies of an application's UI resources to ensure the proper state information gets saved. This routine takes three parameters:
blockToDup
ObjDuplicateResource()
is called. Also, it can only be a "template" resource--a resource that does not get used by the UI or the application directly, but only gets copied via this routine.
owner
owner
of -1, the new block will be owned by the same geode that owns the original.
burdenThread
burdenThread
of -1 makes the new resource have the same burden thread as the original.
ObjDuplicateResource()
returns the handle of the newly created block, which will be unlocked and may or may not be resident in memory.
Include: object.h
See Also: ObjFreeDuplicate()
,
MSG_META_BLOCK_FREE
,
ObjLockObjBlock()
.
void ObjEnableDetach( optr obj); /* object calling this routine */
This routine acts as an object's handler for
MSG_META_ACK
. This handler decrements the acknowledgment count (incremented with
ObjIncDetach()
) and, if the count is zero, enables the detach mechanism so the object can be fully detached. Because the detach mechanism is implemented in
MetaClass
, it is highly unlikely you will ever call this routine.
The lone parameter of this routine is the optr of the calling object (or, in the case of
MSG_META_ACK
, the object sending acknowledgment).
Warnings: This routine may resize and/or move chunks and object blocks, thereby invalidating all pointers and segment addresses.
Include: metaC.goh
See Also: MSG_META_DETACH
,
ObjInitDetach()
,
ObjIncDetach()
,
MSG_META_ACK
.


in court
Man charged with Glasgow ‘rape’ on Halloween after ‘west end sex attacks’
by Paul SmithA MAN has appeared in court after a woman was allegedly raped in the west end of Glasgow on Halloween.
Parvinder Singh, who has also been charged with two alleged sexual assaults, made no plea at the city’s sheriff court yesterday.
It is alleged the 34-year-old raped a woman, 20, in Sutherland Lane, near the University of Glasgow’s library in the early hours of October 31.
He has also been charged with sexually assaulting another woman on October 17, and a third on October 24.
Detective Inspector Suzanne McNulty of the Public Protection Unit in Govan said: “Officers in Glasgow carried out enquiries following a reports three woman had been the victim of sexual assaults
in the West End between 17 and 31 October.

“In every serious crime reported to police, officers carefully consider whether or not it is appropriate to proactively make the circumstances public.
“This is continually assessed throughout the investigation to ensure the safety of the wider public is protected.”
“We will continue to liaise with Glasgow University and the surrounding communities as part of our continued investigations into this.”
The case was committed for further examination and Singh was remanded in custody.
His court appearance comes after Glasgow students were warned to “stay safe” around campus following alleged sexual assaults.
University of Glasgow chiefs issued an "important security message" during the week to reassure students that security procedures were being put in place.
Increased guard patrols have now been brought in around the campus and improved lighting has been installed.
In a social media warning, uni bosses said: "Incidents like this are rare and student and staff safety is of the utmost importance to the University.
"We work extremely closely with Police Scotland and we have increased security patrols and improved lighting on campus.
"If you have any concerns or information to report, please contact our security team on 0141 330 4282 or Police Scotland 101."


Your Shopping List:
S.No.
Image
Product
Timestamp
Cheapest Price
Amazon
Walmart
Details
Addition Type
Sensor
Client


MY FIRST MISTER A film review by Steve Rhodes Copyright 2001 Steve Rhodes RATING (0 TO ****): *** 1/2
Leelee Sobieski delivers the best performance of her career in Christine Lahti's MY FIRST MISTER. Both funny and touching, Sobieski plays Jennifer -- she prefers to be called simply J -- a character who's the complete opposite of the leader of the math nerds she played in NEVER BEEN KISSED. Like the highly acclaimed GHOST WORLD, MY FIRST MISTER concerns the world of rebellious teens. But for my money, MY FIRST MISTER is a much more accessible and successful film.
J is an angry and lost teen without friends of any age. Our first glimpse of Sobieski is a shock, since we think of her as the sweet girl-next-door type. She is dressed from head to toe in black, has most of her body pierced and metalled and is covered in tattoos. With a pair of binoculars, she uses them to spy with one end and to distort and make fun of her world with the other end.
Having long since given up on life, 17-year-old J finds her salvation in a clothing store owner, Randall (Albert Brooks). She calls him "boss man" and "sir" at first but later goes with just R. With great chemistry together, Brooks as the supportive straight man and Sobieski as the needy and sarcastic jokester, they form a relationship that's more than paternal but less than lovers. Certainly everyone, especially those at her favorite coffee place (Bourgeois Pig), figure that, at 49, he must be her father. She has a wacky mother and a taciturn stepfather (Carol Kane and Michael McKean) as well as a freeze-dried hippie, biological father (John Goodman), but she's never been able to communicate with any of them.
When R gives J a job in his store, he forces her to make herself more presentable. After a painful sequence watching her remove her body metal, we witness J's transformation from heavy metal rebel to a bit more sedate teen. Costume designer Kimberly Tillman is careful to give her a black look that shows she has changed but far from completely or necessarily permanently.
Jill Franklyn's script is sharp and dead-on in its humor and its pathos. "I'm old. I'm George Burns," R tells J when he tries to convince her that he's too old for her. "Who's George Burns?" she asks in reply. In truth, J and R are soul mates. Neither has any friends, and both have been miserable until they formed their bond. Other than the age and clothes, the main difference between them is that J contemplates suicide and engages in self-mutilation.
Lahti has a gifted touch with her material. We sympathize with both J and R, but we never feel manipulated by any cheap theatrics. You will laugh, you may cry and you will certainly be touched by this unusual story of these two, new best friends.
MY FIRST MISTER runs 1:49. It is rated R for "language and some sexual material" and would be acceptable for teenagers.
The film opens nationwide in the United States on Friday, October 12, 2001. In the Silicon Valley, it will be showing at the Camera Cinemas.
Web: http://www.InternetReviews.com Email<EMAIL_ADDRESS>Want free reviews and weekly movie and video recommendations via Email? Just send me a letter with the word "subscribe" in the subject line.
========== X-RAMR-ID: 29700 X-Language: en X-RT-ReviewID: 252541 X-RT-TitleID: 10000258 X-RT-SourceID: 703 X-RT-AuthorID: 1271
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


+ Post
Login
re:Invent 2013 Blog Demo
Create a New Article
Title:
Cancel
Publish
Loading articles...


def test_lstm_init():
model = with_padded(LSTM(2, bi=True))
model.initialize()
with pytest.raises(NotImplementedError):
with_padded(LSTM(2, dropout=0.2))
def test_lstm_init():
model = with_padded(LSTM(2, bi=True)).initialize()
model.initialize()
with pytest.raises(NotImplementedError):
with_padded(LSTM(2, dropout=0.2))


by Brad Appleton
<EMAIL_ADDRESS>http://www.bradapp.net
Copyright © 1994-1997 by Bradford D. Appleton
Permission is hereby granted to make and distribute
verbatim copies of this document
provided the copyright notice and this
permission notice are preserved on all copies.
The following is an attempt to put together a complete, yet reasonably flexible template for the specification of software designs. Wherever possible, I have tried to provide guidelines (instead of prescribing requirements) for the contents of various sections and subsections of the document. Some may prefer to require more detailed subsections of a particular section, choosing one or more of the subsection topics from the list of guidelines provided. In this sense, this document is really a template for a template.
In devising this template, I have gleaned information from many sources, including various texts on Software Engineering (Pressman, Sommerville, and Van Vliet), Object-Oriented Development (Booch, Rumbaugh, Berard, and Wirfs-Brock), various SEI reports, DoD-Std and Mil-Std documentation requirements (2167/2167A), and IEEE documentation standards (particularly IEEE-1016 for software designs, and IEEE-830 for software requirements). I have made every effort not to assume or impose a particular software development methodology or paradigm, and to place more emphasis on content than on format.
It is my desire that a completed software design specification meet the following criteria:
Please note that there are no sections in this document for describing administrative or business duties, or for proposing plans or schedules for testing or development. The sections in this document are concerned solely with the design of the software. While there are places in this document where it is appropriate to discuss the effects of such plans on the software design, it is this author's opinion that most of the details concerning such plans belong in one or more separate documents.
Here is the outline of the proposed template for software design specifications. Please note that many parts of the document may be extracted automatically from other sources and/or may be contained in other, smaller documents. What follows is just one suggested outline format to use when attempting to present the architecture and design of the entire system as one single document. This by no means implies that it literally is a single document (that would not be my personal preference):
The above outline is by no means exclusive. A particular numbering scheme is not necessarily required and you are more than welcome to add your own sections or subsections where you feel they are appropriate. In particular you may wish to move the bibliography and glossary to the beginning of the document instead of placing them at the end.
The same template is intended to be used for both high-level design and low-level design. The design document used for high-level design is a "living document" in that it gradually evolves to include low-level design details (although perhaps the "Detailed Design" section may not yet be appropriate at the high-level design phase).
The ordering of the sections in this document attempts to correspond to the order in which issues are addressed and in which decisions are made during the actual design process. Of course it is understood that software designs frequently (and often fortunately) don't always proceed in this order (or in any linear, or even predictable order). However, it is useful for the purpose of comprehending the design of the system to present them as if they did. Frequently, one of the best ways to document a project's design is to keep a detailed project journal, log, or diary of issues as they are mulled over and bandied about and to record the decisions made (and the reasons why) in the journal. Unfortunately, the journal format is not usually organized the way most people would like it for a formal review. In such cases, for the purpose of review, the journal can be condensed and/or portions of it extracted and reorganized according to this outline. However, if this is done then you need to choose whether to update and maintain the design document in the journal format, or the formal review format. It is not advisable to try and maintain the design document in both formats. (If you have an automated method of converting the journal into a formal document, then this problem is solved.)
Here is the description of the contents (by section and subsection) of the proposed template for software design specifications:
Provide an overview of the entire document:
Provide a general description of the software system including its functionality and matters related to the overall system and its design (perhaps including a discussion of the basic design approach or organization). Feel free to split this discussion up into subsections (and subsubsections, etc ...).
This section describes many of the issues which need to be addressed or resolved before attempting to devise a complete design solution.
Describe any assumptions or dependencies regarding the software and its use. These may concern such issues as:
Describe any global limitations or constraints that have a significant impact on the design of the system's software (and describe the associated impact). Such constraints may be imposed by any of the following (the list is not exhaustive):
Describe any goals, guidelines, principles, or priorities which dominate or embody the design of the system's software. Such goals might be:
For each such goal or guideline, unless it is implicitly obvious, describe the reason for its desirability. Feel free to state and describe each goal in its own subsubsection if you wish.
Briefly describe the method or approach used for this software design. If one or more formal/published methods were adopted or adapted, then include a reference to a more detailed description of these methods. If several methods were seriously considered, then each such method should be mentioned, along with a brief explanation of why all or part of it was used or not used.
Describe any design decisions and/or strategies that affect the overall organization of the system and its higher-level structures. These strategies should provide insight into the key abstractions and mechanisms used in the system architecture. Describe the reasoning employed for each decision and/or strategy (possibly referring to previously stated design goals and principles) and how any design goals or priorities were balanced or traded-off. Such decisions might concern (but are not limited to) things like the following:
Each significant strategy employed should probably be discussed in its own subsection, or (if it is complex enough) in a separate design document (with an appropriate reference here of course). Make sure that when describing a design decision that you also discuss any other significant alternatives that were considered, and your reasons for rejecting them (as well as your reasons for accepting the alternative you finally chose). Sometimes it may be most effective to employ the "pattern format" for describing a strategy.
This section should provide a high-level overview of how the functionality and responsibilities of the system were partitioned and then assigned to subsystems or components. Don't go into too much detail about the individual components themselves (there is a subsequent section for detailed component descriptions). The main purpose here is to gain a general understanding of how and why the system was decomposed, and how the individual parts work together to provide the desired functionality.
At the top-most level, describe the major responsibilities that the software must undertake and the various roles that the system (or portions of the system) must play. Describe how the system was broken down into its components/subsystems (identifying each top-level component/subsystem and the roles/responsibilities assigned to it). Describe how the higher-level components collaborate with each other in order to achieve the required results. Don't forget to provide some sort of rationale for choosing this particular decomposition of the system (perhaps discussing other proposed decompositions and why they were rejected). Feel free to make use of design patterns, either in describing parts of the architecture (in pattern format), or for referring to elements of the architecture that employ them.
If there are any diagrams, models, flowcharts, documented scenarios or use-cases of the system behavior and/or structure, they may be included here (unless you feel they are complex enough to merit being placed in the Detailed System Design section). Diagrams that describe a particular component or subsystem should be included within the particular subsection that describes that component or subsystem.
If a particular component is one which merits a more detailed discussion than what was presented in the System Architecture section, provide that more detailed discussion in a subsection of the System Architecture section (or it may even be more appropriate to describe the component in its own design document). If necessary, describe how the component was further divided into subcomponents, and the relationships and interactions between the subcomponents (similar to what was done for top-level components in the System Architecture section).
If any subcomponents are also deemed to merit further discussion, then describe them in a separate subsection of this section (and in a similar fashion). Proceed to go into as many levels/subsections of discussion as needed in order for the reader to gain a high-level understanding of the entire system or subsystem (but remember to leave the gory details for the Detailed System Design section).
If this component is very large and/or complex, you may want to consider documenting its design in a separate document and simply including a reference to it in this section. If this is the option you choose, the design document for this component should have an organizational format that is very similar (if not identical to) this document.
Describe any design policies and/or tactics that do not have sweeping architectural implications (meaning they would not significantly affect the overall organization of the system and its high-level structures), but which nonetheless affect the details of the interface and/or implementation of various aspects of the system. Such decisions might concern (but are not limited to) things like the following:
Each particular policy or set of tactics employed should probably be discussed in its own subsection, or (if it is large or complex enough) in a separate design document (with an appropriate reference here of course). Make sure that when describing a design decision that you also discuss any other significant alternatives that were considered, and your reasons for rejecting them (as well as your reasons for accepting the alternative you finally chose). For this reason, it may frequently be convenient to use one of the more popular "pattern formats" to describe a given tactic.
For this particular section, it may become difficult to decide whether a particular policy or set of tactics should be discussed in this section, or in the System Architecture section, or in the Detailed System Design section for the appropriate component. You will have to use your own "best" judgement to decide this. There will usually be some global policies and tactics that should be discussed here, but decisions about interfaces, algorithms, and/or data structures might be more appropriately discussed in the same (sub)section as its corresponding software component in one of these other sections.
Most components described in the System Architecture section will require a more detailed discussion. Other lower-level components and subcomponents may need to be described as well. Each subsection of this section will refer to or contain a detailed description of a system software component. The discussion provided should cover the following software component attributes:
Much of the information that appears in this section is not necessarily expected to be kept separate from the source code. In fact, much of the information can be gleaned from the source itself (especially if it is adequately commented). This section should not copy or reproduce information that can be easily obtained from reading the source code (this would be an unwanted and unnecessary duplication of effort and would be very difficult to keep up-to-date). It is recommended that most of this information be contained in the source (with appropriate comments for each component, subsystem, module, and subroutine). Hence, it is expected that this section will largely consist of references to or excerpts of annotated diagrams and source code. Any referenced diagrams or source code excerpts should be provided at any design reviews.
Provide a detailed description of this software component (or a reference to such a description). Complex diagrams showing the details of component structure, behavior, or information/control flow may be included in the subsection devoted to that particular component (although, unless they are very large or complex, some of these diagrams might be more appropriately included in the System Architecture section. The description should cover any applicable software component attributes (some of which may be adequately described solely by a source code declaration or excerpt).
An ordered list of defined terms and concepts used throughout the document.
A list of referenced and/or related publications.


Relude_Validation
This module does not have a toplevel documentation block.
type t('a, 'e) = | VOk('a) | VError('e)
Similar to Belt.Result, but has an Applicative instance that collects the errors using a semigroup, rather than fail-fast semantics.
let flatMapV: (t('a, 'e), 'a => t('b, 'e)) => t('b, 'e)
This function performs a flatMap-like operation, but if the f
fails, all previous errors are discarded.
Validation is not a traditional Monad, because the point of it is to preserve the errors via a Semigroup.


{% filter markup %}
Your message has been sent, and I'll look at it and try to get back to you as soon as possible.
In the meantime, you might be interested in reading [some entries from my weblog]({% url 'entries:index' %}).
{% endfilter %}
{% endblock %}


| Technical Review Papers | ||
| trpbillybob.docx | Billy's source file | |
| trpbillybob.pdf | Billy's PDF file | |
| . | ||
| trpgeorgeburdell.docx | George's source file | |
| trpgeorgebrudell.pdf | George's PDF file | |
| . | ||
| trpgeorgiaburdell.docx | Georgia's source file | |
| trpgeorgiaburdell.pdf | Georgia's PDF file | |
| . | ||
| trpjanedoe.docx | Jane's source file | |
| trpjanedoe.pdf | Jane's PDF file | |
| . | ||
| trpthelmalou.docx | Thelma's source file | |
| trpthelmalou.pdf | Thelma's PDF file | |
| Accepted Written Proposal | ||
| acceptedproposal.docx | Proposal source file | |
| acceptedproposal.pdf | Proposal PDF file | |
| Proposal Presentation | ||
| proposalpresentation.pptx | Proposal Presentation source file | |
| proposalpresentation.pdf | Proposal Presentation PDF file | |
| Group Picture | ||
| picturegroup.jpg | A group picture | |
| or Individual Pictures |
or
|
|
| picturebillybob.jpg | Billy's individual picture | |
| picturegeorgeburdell.jpg | George's individual picture | |
| picturegeorgiaburdell.jpg | Georgia's individual picture | |
| picturejanedoe.jpg | Jane's individual picture | |
| picturethelmalou.jpg | Thelma's individual picture | |
| Final Project Summary | ||
| projectsummary.docx | ||
| projectsummary.pdf | ||
| Final Presentation | ||
| finalpresentation.pdf | ||
| finalpresentation.pptx | ||
| Final Written Report | ||
| finalwrittenreport.docx | ||
| finalwrittenreport.pdf |
FAQs
Why do you want the file names to reflect group members' names?
So that the files can be programatically detected.
Only the last name needs to be included if it is unique within your group.
What if our pictures are not JPGs?
Fine, but use standard image file types such as GIF, PNG, TIF, BMP which render
on contemporary browsers.
What if we use other than Microsoft Office products as our presentation or
written documents?
Fine, include in the native source, but also include a PDF.
What if we have multiple presentation documents (e.g. a poster, and a Powerpoint)?
Fine, include them all, but include the one you consider as primary as finalpresentation.pdf.
What about our videos, other pictures, CAD, datasheet, code, and other files?
Fine, include what you need so that another group could reproduce or continue
your project.
But, you need the minimal set of deliverables listed above with a PDF for each.
But we cannot find George's Technical Review Paper source file?
Fine, but include a placeholder document stating George's scenario.


{% load static %}
Report Count Statistics
Refresh the map canvas to view latest all time report count.


Toggle navigation
PICU Map
Past Shifts
Include Options Here
Filter By
Availability
Last Name, First Name
First Name, Last Name
ICU All
Experience ICU
Years
EMCO
CVVH
CVVH4
Transplant
PD
Highlight Rms By
Certain Highlights
Undo Last Assignment
+
-
Nurse One
Nurse Two
Nurse Three
Nurse Four
Nurse Five


From v0.4.0 all the application code has been integrated into a number of packages. Each package uses MVC on the server and client. Below is the overall file structure as well as the package file structure
config --- env # Configuration Files ----- all.js # General configuration for all environments ----- development.js # Development specific ----- production.js # Production specific --- express.js # Express middleware packages # See Below
All of the Server side code resides in the /server directory.
Serverserver --- config # Configuration Files (see below) --- controllers # Server side logic goes here --- models # schema models goes here --- routes # rest api endpoints routing - here --- views # swig based html rendering - here
All of the Client side code resides in the /public directory.
Clientpublic --- config # Configuration Files (see below) --- controllers # Client side logic goes here --- routes # Angular routes defined here --- views # Angular view files found here --- services # Angular service files found here --- directives # Angular directive files found here
All the configuration code resides in the /config directory. Different environment configurations (testing, development, production) can be defined within the env directory.
Serverconfig --- env # Configuration Files ----- all.js # General configuration for all environments ----- development.js # Development specific ----- production.js # Production specific --- express.js # Express middleware
Limit changing code in express.js as it will make upgrading more challenging in the future
All of the Packages code resides in the /packages directory.
The package can be thought of as a mini mean project following the same file structure
See the packages section for more details about the packages file structure


--- layout: post title: "Laniakea up and running" subtitle: "The new ELIXIR Italy (CVMFS) Reference Data Repository is now on-line" date: 2020-09-17 010:00:00 -0400 background: '/img/posts/all_systems_go.jpg' ---
Dear Users,
the new ELIXIR-Italy CVMFS repository for reference data is on-line The service is now up and running. Thanks a lot.
The Laniakea team.


Takes is a true object-oriented and immutable Java web framework. Current version is ${project.version}. Check us out at Github. Here is JavaDoc. See also test coverage.


See: Description
| Interface | Description |
|---|---|
| PwBuildingMapManager.PwMarkersAddedListener |
PwMarkersAddedListener is a listener listening to added markers
|
| PwIndoorFloorChangeLocationListener |
PwIndoorFloorChangeLocationListener is a listener listening to floor changes in the map
|
| PwIndoorLocationStatusListener |
PwIndoorLocationStatusListener is a listener listening to indoor location status changes.
|
| PwOnBuildingDataLoadedCallback |
The
PwOnBuildingDataLoadedCallback interface defines a set of methods used to receive building data-loaded callbacks |
| PwOnBuildingPOIDataLoadedCallback |
The
PwOnBuildingPOIDataLoadedCallback interface defines a set of methods used to receive Points of Interests data-loaded callbacks |
| PwOnCameraChangeListener |
The
PwOnCameraChangeListener interface defines a method used to receive camera-related callbacks |
| PwOnFloorChangedCallback |
The
PwOnFloorChangedCallback interface defines a method used to receive floor-related callback |
| PwOnMapDataLoadedCallback |
The
PwOnMapDataLoadedCallback interface defines a set of methods that you can use to receive map data loaded callbacks. |
| PwOnSnapToRouteCallback |
The PwOnSnapToRouteCallback interface defines a set of methods that you can use to receive "Snap to route" start and stop callbacks.
|
| Class | Description |
|---|---|
| PwBuildingMapManager |
The
PwBuildingMapManager provides a simple interface for fetching building data and resources. |
| PwMapOverlayManagerBuilder |
PwMapOverlayManagerBuilder provides the ability to manage map overlays, and create PwBuildingMapManager objects
|
| PwRouteUtils |
This class provides helper functions for creating routes.
|
| Enum | Description |
|---|---|
| PwRouteSnappingTolerance |
The tolerance factor that is multiplied to the horizontal accuracy is configurable, but restricted to values of Off(0), Normal(1.0), Medium(1.5) and High(2.0).
|


Everyone has a dream. Whether it is to go to the moon, cure cancer, or open a simple bakery, we want to help you bring it into reality. We provide a time and place for anyone, with any background, to create a project and bring their dream to life. So it doesn't matter if you're just getting off the ground or are flying circles in the virtual cloud. HackPrinceton is your time to make something new, to explore that ambitious craving in your head, and to step outside your comfort zone.
Top notch hardware, world records, and food that isn't pizza?!? You won't want to miss it, so fill out the form above to hear when signups begin.
Want to help inspire the next generation of entrepreneurs?
Email us at<EMAIL_ADDRESS>We welcome undergraduate and graduate students from all universities. Unfortunately, you must be over 18 to attend. HS Hackers, we're working hard on getting this changed!
Signups are closed, and lottery results are now available. If you're on the waitlist, keep an eye out; we may be able to open a few more spots! Princeton students are automatically accepted.
We've got you covered! We will make sure to set aside meals that satisfies your allergy or dietary condition. All we ask is that you let us know when you confirm your invitation.
Not at all! We welcome students of all skill levels. We have an incredible staff of mentors here to help out if you're just getting started, or even if you've been coding since you could walk. Because even then, they're Yoda and we're just Luke.
We will be sending out buses out to the schools with the most signups. Destinations will be announced alongside lottery results. If there is not a bus near your school, we will be offering reimbursements of up to $150 per person. You just need to finish your hack!
Laptops, cellphones, and chargers tend to be helpful at events such as HackPrinceton. We recommend non-Princeton students also pack a change of clothes, and toiletries. Just nothing dangerous please. Of course, don't forget to bring your friends and teammates!
Teams are composed of 2-5 people, involving any combination of school, age and gender. Though participants may work alone, we highly encourage you to join a group and make new friends!
Our opening ceremony kicks off early Friday evening, and general fun ensues until Sunday afternoon, when we bid adieu and all get some shuteye. There will be plenty of awesomeness in between.
Ping<EMAIL_ADDRESS>and we'll get back to you as soon as we can! You may be surprised at the odd hours we'll be up.


by Angela Duncan View on Dribbble
by Antonio F. Mondragon View on Dribbble
by Charlie Wagers View on Dribbble


Microtrain 2009
Welcome to class. We are here to develop web and mobile hybrid applications...
Agile Full Stack Web and Hybrid Mobile Application Development
Full stack web and hybrid mobile applications developer specializing in full stack JavaScript application and architectures. Experienced in all stages of the development life cycle, well versed in numerous programming languages.
HTML, CSS, JavaScript
Learn front-end and client-side development starting with HTML, CSS and JavaScript. Work with libraries and frameworks such as jQuery, Bootstrap and Angular. Apply and use web technology to build hybrid mobile applications using Apache’s Cordova.
Learn how to work with third party APIs from vendors such as Google, Nasa, Twilio and LinkedIn. Learn the server side by working with LAMP (Linux, Apache, MySQL, PHP) and MEAN (MongoDB, Express, Angular, Node,js) stacks. Apply newly acquired backend knowledge to build your own cloud-based server in AWS.
- Lecture
- Labs
- Coding Assignments
Summary
Additionally, security best practices and mobile first design concepts as well as extreme programming, agile and scrum methodologies. You will apply these skills throughout the course building an array of applications to add to your project portfolio.


 Tangsuyuk (also spelled tangsooyuk) is another beloved Korean-Chinese dish along with the two noodle dishes – jajangmyeon and jjamppong.
Every time my family goes out to a Korean-Chinese restaurant, we almost always order a large plate of tangsuyuk to share as an appetizer. At home, I often make this dish for special occasions or gatherings, especially when my extended family gets together. Everyone loves it! Tangsuyuk is easy to make, but the process goes very quickly. So, have all your kitchen equipment and ingredients ready before starting to cook. This tangsuyuk recipe was originally posted in September 2011. I’ve updated it here with new photos, more information, and an improved recipe.


Created by Daniel Górny, we just received word from RR, a special take the crossover between the physical patching paradigm and digital synthesis with Prynth. Check out RR on the instrument gallery.
NOTE: Let us know if you’ve developed a new instrument with Prynth!


MyFxHedge - Material Design
Let us Know About Your Activity
{{ profile.name }}
{{ currency.header }}
EUR
USD
JPY
CHF
Your Hedging Strategy
{{ strategy.name }}
Show as List
Show as Grid
The products to buy
The KPI
The KPI
The KPI
The KPI


AI-RFX Procurement Framework v1.0
Online Version for the AI Request for Proposal Template, AI & Machine Learning Solutions.
0 - Introduction
0.1 - Overview
The “AI Request for Proposal v1.0” is part of the AI-RFX Procurement Framework. The objective of this document is to empower industry practitioners looking to procure AI systems. It should serve as a guide and a reference when putting together a tender or when procuring a machine learning solution. This template should also serve as a guide for suppliers that are looking to put together a proposal for a machine learning solution. This way suppliers can ensure they are following best practices in responsible machine learning development.
This AI-RFP template has been built using our “Machine Learning Maturity Model” as its core, which is available for download at our website. The “Machine Learning Maturity Model” goes beyond the machine learning algorithms themselves, and provides an assessment criteria to evaluate the maturity of the infrastructure and processes around the algorithms. The concept of “Maturity” is not just defined as a matter of technical excellence, scientific rigor, and robust products. It also essentially involves responsible innovation and development processes, with sensitivity to the relevant domains of expert knowledge and consideration of all relevant direct and indirect stakeholders.
All the frameworks under the AI-RFX Procurement Framework, including the “AI Request for Proposal”, the “Machine Learning Maturity Model”, and the “AI Tender Competition” templates have been released as fully open source. This allows suppliers and companies to contribute and update these templates, helping raise the bar for AI safety, quality and performance.
0.2 - About Us
The Institute for Ethical AI & Machine Learning is a UK-based research centre that carries out world class research into responsible machine learning systems. We are formed by cross functional teams of applied STEM researchers, philosophers, industry experts, data scientists and software engineers.
Our vision is to mitigate risks of AI and unlock its full potential through frameworks that ensure ethical and conscientious development of intelligent systems across industrial sectors. We are building the Bell Labs of the 21st Century by delivering breakthrough contributions through applied AI research. You can find more information about us at https://ethical.institute.
0.3 - Motivation
There is currently a growing number of companies that are working towards introducing machine learning systems to automate critical processes at scale. This has required the “productisation” of machine learning models, which introduces new complexities. This complexity revolves around a new set of roles that fall under the umbrella of “Machine Learning Engineering”. This new set of roles fall in the intersection between DevOps, data science and software engineering.
To make things harder, the deployment of machine learning solutions in industry introduces an even bigger complexity. This involves the intersection of the new abstract “Machine Learning Engineering” roles, together with the industry domain experts and policy makers.
Because of this, there is a strong need to set the AI & ML standards, so practitioners are empowered to raise the bar for safety, quality and performance around AI solutions. The AI-RFX Procurement Framework aims to achieve the first steps towards this.
0.4 - How to use this document
0.4.1 - Using as reference
Many procurement managers may already own internally-approved RFP templates or RFP portals with standard entries. If that is the case, this document can be treated as a reference to obtain insights from key sections specific to machine learning, such as “Chapter 3: Tender Process” and “Chapter 4: Detailed Scope”. The machine learning specific sections in this document include:
0.4.2 - Structure
The document consists of multiple chapters, each chapter with a set of sections. The text in the sections is meant to be replaced completely, and it consist of:
-
An explanation of what the section should contain
-
An example of what it the section could look like
0.4.3 - Example
Each section has an example. The example is consistent throughout the document, and it is around a fictitious company called “Manufacturing Group Limited”. The objective is to provide a broad and generic example that covers multiple useful areas which companies can relate to. In this specific example, the company is looking for a machine learning system that performs predictive maintenance and data analysis automation on a fictitious end-to-end internal process.
0.4.4 - When to use
This template is relevant primarily for the procurement of machine learning systems, and hence it is only relevant when looking to automate a process that involves data analysis that is too complex to be tackled using simple RPA tools or rule-based systems.
0.5 - Template vs Reality
This document should serve as a guide. Especially for smaller projects, the level of detail required may vary significantly, and some sections can be left out as required. This template attempts to to provide a high level overview on each chapter (and respective sections) so the procurement manager and suppliers can provide as much content as reasonable.
Each company putting together a procurement process will have different set of requirements, and unfortunately this is not a “one-size-fits-all” document. The main purpose of this document is to raise the bar both in industry and technology, and provide key industry stakeholders with a solid basis to start from. Also, it’s free.
0.6 - Open Source License - Free as in freedom
0.6.1 - Open source License
This document is open source, which means that it can be updated by the community. The motivation to release this as open source is so that it is continuously improved by the community. This will ensure that the standards for safety, quality and performance of what is expected in machine learning systems will keep increasing, whilst being kept in check on a realistic level by both suppliers and companies.
0.6.2 - Contributing.md
The Institute for Ethical AI & Machine Learning’s AI-RFX committee is in charge of the contributing community for all of the templates under the AI-RFX Procurement Framework. Anyone who would like to contribute, add suggestions, or provide example and practical uses of this template, please contact us through the website, or send us an email via<EMAIL_ADDRESS>0.6.3 - License
This document is registered under this MIT License (raw file), which means that anyone can re-use, modify or enhance this document as long as credit is given to The Institute for Ethical AI & Machine Learning. It also includes an “as is” disclaimer. Please read the license before using this template.
Request for Proposal Template Begins Here:
Example company name: MANUFACTURING GROUP LIMITED
Example AI-RFP for Machine Learning Automation System
Issued on: 00/00/2019
Issued by: Person’s Name
Reference Number: #REFNUMBER
1 - Our Company
This chapter contains a high level overview about the company that is setting up the tender process.
1.1 - Company Overview
This section should provide a brief overview of the company. It may also be worth adding insights on the company’s commitments and efforts in the field of AI.
|
Example Company Overview for “Manufacturing Group Limited” Manufacturing Group Limited is an OEM manufacturing company that was set up in 1992, we are a large manufacturing group with a large number of suppliers. We operate machinery across over 10 countries across the world. The quality of our machines is the highest amongst our competitors, and the processes we have created around maintenance & operations are the most advanced in the industry. We have a commitment of £100m during the next 5 years to introduce machine learning into our company to improve the quality and efficiency of our processes, and enable our staff to focus on more important higher level tasks. |
1.2 - Key Facts
This section should contain 5-10 key facts about the company. Similar to the brief overview, it may be worth adding some key facts about the current focus as an organisation towards the area of artificial intelligence and machine learning.
|
Example Key Facts for “Manufacturing Group Limited”
|
1.3 - Values
List your company values as relevant to ensure suppliers are aware.
|
Example Values for “Manufacturing Group Limited”
|
1.4 - Responsibility Commitment
This section requests suppliers to ensure they follow the 8 Principles for Responsible Machine Learning development. The 8 commitments are implemented in this framework through the Machine Learning Maturity Model, and they are implicit on each section.
We suggest you use a variation of the default example provided below.
|
Example Responsibility Commitment This request for proposal requires all suppliers to follow the 8 principles for responsible machine learning defined by The Institute for Ethical AI & Machine Learning. The 8 principles state best practices in each area, and as it is stated, they don’t always have to be implemented in every project, but when this is the case it should be an explicit decision not to.
You can find the Machine Learning Principles by The Institute for Ethical AI & Machine Learning at https://ethical.institute/principles.html |
1.5 - External Links
This section should contain links relevant for suppliers and solution providers. Some sample links are provided which reference to some of the points covered in this document, including website address, reference to background knowledge, and links to domain specific requirements.
|
Example Process Overview for “Manufacturing Group Limited”
|
2 - Requirements Overview
The objective of this chapter is not to propose the solution desired, but to provide details on the end-to-end process and/or challenge identified within the company. As mentioned in the introduction, given that this RFP is specific to machine learning solutions, the ideal way to explain the challenge/process is through the flow of data across the entire process, including transformations, stakeholders involved, systems, and data-sources. This is because machine learning solutions are used to automate the analysis of data, and hence this would provide suppliers with a good understanding on all the steps that surround the data itself.
This chapter has been put together using the Machine Learning Maturity Model assessment criteria. Each section takes into consideration each of the criteria implicitly. It is recommended to take into consideration all the 8 assessment criteria when putting together this section.
2.1 - Key objectives & outcomes
This section is one of the most important in this chapter. This section should provide a high level overview of what are the tangible outcomes desired as outputs of a successful tender process. The idea is for this section to provide high level objectives / KPIs. Later on, Section 2.6 - Target improvements and metrics focuses on lower-level quantifiable metrics that relate to each of the high level objectives / KPIs in this section.
Points to include in this section include:
-
High level reason why process/challenge is being tackled
-
Key improvement areas (e.g domain expert time freed, reduction of errors, improvement of inefficient process, etc)
-
Type of high level services or qualities that are sought in suppliers being procured
|
Example Aims & Objectives for “Manufacturing Group Limited”
|
2.2 - Process/challenge overview
This section should contain a concise and high level description of the process / challenge that the organisation has identified which needs to be automated or improved. As mentioned at the beginning of the chapter, the overview should focus on the flow of the data across the steps throughout process. Once again, the reason for this is because machine learning use-cases in industry are for (full or partial) automation of data analysis -- whether for business insights or process automation.
Providing in-depth information on the current flow of data will allow suppliers to use their expertise to how and to what extent their solution will be able to automate the process, whether full or partial automation.
The key questions that should be covered in this section include:
-
What are the data-sets and data-sources involved in the process?
-
Who are the stakeholders involved?
-
What are the approximate/high-level volumes processed?
-
How common are human/system errors?
-
What are the inefficiencies that were identified?
Below is an example of how these questions can be answered in a high level summary.
|
Example Process Overview for “Manufacturing Group Limited”
|
2.3 - Process Detail
This section covers the process into detail. It still focuses mainly on the data-flow, but provides a much more in-depth overview for the following 4 areas:
-
Dataset overview
-
Stakeholder overview
-
Workstreams overview
-
Step by step workstreams breakdown
2.3.1 - Dataset Overview
This subsection should provide information about the datasets involved across the end-to-end process. There should be a brief overview of the systems and/or data-sources where the datasets are stored and/or processed. There should also be a high level overview of what the datasets consist of. “Chapter 4: Detailed Scope” covers the systems and the datasets into much more detail with samples and documentation where relevant.
The table below provides an example of 6 datasets across 3 systems:
|
Example Datasets Overview for “Manufacturing Group Limited” Datasets involved:
|
2.3.2 - Stakeholder Overview
This subsection should provide an overview of the stakeholders that are involved throughout the end-to-end process, including:
-
Name of the type of stakeholder
-
Brief description
-
Whether stakeholder is a domain expert or staff (more on this below)
This subsection should outline which stakeholders are “Domain Experts”. The “Domain Experts” are the stakeholders that use domain-specific or expert knowledge to analyse data. Often the Domain Experts need to be available for suppliers to answer questions, as suppliers may need to obtain insight about how the data is analysed or how the systems are used, so the right machine learning solution can be proposed.
The example below covers 4 stakeholders, three of which are domain experts and perform complex analysis on the datasets.
|
Example Stakeholder Overview for “Manufacturing Group Limited” Stakeholders involved in the process:
|
2.3.3 - Workstreams Overview
The end-to-end process often may consist of multiple different independent or dependent workstreams. This step requires an overview of the workstreams that constitute the process. Each workstream should contain the following information:
-
High-level description of each workstream
-
Order in which workstreams are executed, or alternative whether they are not dependent on each other (i.e. parallel or sequence).
Below is an example with 2 parallel workstreams:
|
Example Workstreams Overview for “Manufacturing Group Limited” In this process there are two workstreams identified, which are independent of each other and are executed in parallel, but at a different frequency.
|
2.3.4 - Step-by-Step Workstreams Breakdown
This subsection should contain every step for each workflow identified across the end-to-end process. Each step provided should contain the following where relevant:
|
# |
Name |
Description |
|
1 |
Stakeholders |
All the stakeholders involved in this step |
|
2 |
Datasets |
All the datasets that are retrieved, transformed or created - ideally one action per step |
|
3 |
Systems |
The systems that are used to retrieve, transform or save data |
|
4 |
Actions |
Actions performed by stakeholders or systems, generally around the data, but also could be different |
(*) Don’t forget
It is important to make sure that there are no steps that are missed -- especially the following points:
-
Detailed steps required to extract the data from the systems
-
The domain expert analysis/transformations that are performed in the data involved
-
New creation of datasets which could be as small as adding results to a system or writing a report
The example below covers an overview of the first workstream outlined in the example above.
|
Example Step-by-Step Workstreams Breakdown for “Manufacturing Group Limited” The granular step-by-step process for the FIRST workflow, machine evaluation is as follows:
|
2.4 - Diagram of workstreams
This section should provide a visual diagram to outline the current process and more specifically the interactions between its constituent workstreams.
Given the complexity of some of the workstreams, especially where there is dependency or conditional branches, there is a lot of clarity that would be gained through a visual diagram. The diagram should add emphasis on the flow of the data, and provide an insight of what actions are carried out on each step.
The example below is a simple overview of both of the workstreams visualised. This is a simplification of the process - in more complex proposals, it may be important to provide more granular detail, and potentially different diagrams.
|
Example Diagram of Workstreams for “Manufacturing Group Limited” The current workflow for domain-specific analysis on the data mentioned is depicted at the end of this section. The diagram below provides a high level overview of the data sources involved, together with all the data formats that are extracted, created and pushed back into systems. The datasets involved as labelled in the image are as follows:
|
2.5 - Key target metrics
This section provides the benchmarks gathered from the process, together with the ideal targets, which should be aligned with the high level objectives provided in Section 2.1 - Key objectives & outcomes.
In practice, it may be hard or near impossible to measure accurate benchmarks, however it is possible to relax constraints to obtain higher level metrics that would still be useful for suppliers. The example in this section provides an overview of some metrics that can be collected. This section is directly addressed in “Assessment Criteria #1 - Practical Benchmarks” of the “Machine Learning Maturity Model”.
2.5.1 - Current benchmarks & metrics
This section should provide benchmark metrics that are gathered from the process. These will allow suppliers to have a base for benchmarking their proposed metrics. Some common metrics for benchmarking are covered below.
|
Name |
Description |
|
Time |
Time taken from start to end of process, broken down by workstream where relevant. |
|
Volumes |
The expected number of instances the process will be executed per day, month or year (as relevant), with the relevant granularity (number of datasets involved in each layer) |
|
Accuracy / Error frequency |
(*) Accuracy will be one of the most important pieces in this template. This is covered in more detail below, and it is directly aligned with metric #6 in the Machine Learning Maturity Model. |
|
Resources |
This should contain information about the resources required to have the process operational, such as stakeholders. |
|
Costs |
Costs can include operation costs, but also the costs of an error in a specific part of the process. |
(*) Accuracy metrics
As it is mentioned in the Machine Learning Maturity Model, it is critical to consider what practical accuracy metrics make sense for each project. Often projects consider only simple accuracy (i.e. number of correct cases / total number of cases). However it is often necessary to take into consideration what types of errors are the most critical in the specific project. Some of these considerations include:
-
A case that should have been correct but was missed (Type I Error / Recall)
-
A case that was incorrectly marked as correct (Type II Error / Precision)
Below is an example that contains high-level metrics for the first workstream. For more detail on this section, please refer to the “Machine Learning Maturity Model”.
|
Example Benchmarking for “Manufacturing Group Limited” The benchmarking results that we have compiled on the workstreams where put together through the following process:
The resulting benchmarks are as follows:
|
2.5.2 - Target improvements & metrics
Each of the targets in this subsection should link to a high level objective provided in Section 2.1 - Key objectives & outcomes, and should reference the metrics in the previous Subsection 2.5.1 - Current benchmarks & metrics. The points to cover in this subsection should include the following:
|
Section referenced |
Description |
|
Requirements |
The requirements can be functional or non-functional requirements that can be directly related to features that require user-friendliness, but also it could be more specific requirements such as integrations with user management systems, or the ability to extend the platform in case there is an in-house team of experts that has the skills. |
|
Process |
The process steps can be referenced to mention what the ideal level of automation would be. This could be full automation or partial automation. It’s also possible to reference some of the workstreams and mention which ones should be automated. |
|
Benchmarking |
Each of the metrics can be referenced with an ideal decrease or increase. |
|
Example Target improvements and metrics for “Manufacturing Group Limited” The ideal solution would have the following:
The ideal solution would show a quantifiable improvement in benchmarks provided as follows:
In order for a solution to be viable, we need to see at least a 70% in overall cost reduction within the first 3 years. |
3 - Tender Process
This chapter introduces suppliers to the end-to-end tender process that they will have to go through during procurement. This chapter has been put together using the Machine Learning Maturity Model assessment criteria. It is recommended to take into consideration all the 8 assessment criteria when putting together this section. Each section in this chapter takes into consideration each of the criteria implicitly, and Section 3.2 - Assessment criteria addresses the Machine Learning Maturity Model explicitly.
3.1 - Key point of contact
This section should have the contact details of the person or people that are in charge of the day to day communications for this project. This ideally will be an individual that is well connected with the relevant stakeholders in the organisation. At the same time, it has to be someone that will have the time to dedicate to perform the delivery, communications and internal championing of the solution.
If the key point of contact is not able to engage internally or externally in an efficient way for any reason (whether not enough time committed, not enough resources or slow response from other departments) the success of the project may be affected. It is critical that the key point of contact and the team are able to work closely together as necessary for the project.
|
Example Key point of contact for “Manufacturing Group Limited”
|
3.2 - Assessment criteria
This section provides an insight on the criteria that can be used to evaluate the proposals. The criteria contains multiple areas, but the core is reflected in the Machine Learning Maturity Model assessment criteria.
The table below contains an overview of common criteria that is used to assess a proposal:
|
Criteria |
Description |
|
Competition results |
This criteria covers the results obtained by the supplier during the optional competition, which is covered in Section 4.1 - Competition. Often there is a minimum bar set, and if a supplier doesn’t pass it is not considered. |
|
Machine Learning Maturity Model |
The Machine Learning Maturity Model is the assessment criteria proposed to evaluate the maturity of a machine learning solution. The maturity model is available for free download at our website, and consists of the following 8 criteria:
|
|
License & service terms |
This criteria covers the terms that revolve around the legal terms around the solution. This includes the terms of the license, including the service-level-agreements, security questionnaires, maintenance terms, etc. |
|
Costs |
This includes the total costs of the technology, together with the proposed improvements in the process itself |
The example below provides a high level overview of assessment metrics that reference the machine learning maturity evaluation.
|
Example Assessment Criteria for “Manufacturing Group Limited” The suppliers will be evaluated using the criteria outlined below. Scores will be weighted and then brought together to form total qualitative rating for your proposal. This will then be reviewed in conjunction with the commercial pricing submission to form an overall view. The scoring metrics that will be used for each criteria are:
The suppliers will be evaluated on the following criteria:
|
3.3 - Evaluation team
This section should have details on the stakeholders that will be involved in the evaluation process, and the way each of the criteria will be evaluated. This will provides suppliers with an understanding of what are the skills and domain specific knowledge in the evaluation board, and will ensure suppliers add extra (or less) background knowledge / explanations as relevant.
Below is an example of what the evaluation team could consist of, and what each of the members will evaluate.
|
Example Evaluation Process for “Manufacturing Group Limited”
|
3.4 - Short-List Negotiations
Once the supplier has been selected, the framework agreement, statement of work and relevant contracts should be drafted, and finalised with the deadline provided. This section should contain information about what is expected from the chosen supplier. Commencement dates, as well as timelines should also be drafted.
|
Example Short-List Negotiations for “Manufacturing Group Limited”
|
3.5 - Project timeline
This section should provide a key breakdown for the milestones expected. Some of the deadlines and timelines would vary depending on the complexity of the project, but some standard dates that should be included are provided below. Besides providing these external deadlines for suppliers, it’s also important to set up internal deadlines and allocate the right responsibilities to be able to meet the necessary requirements when interacting with suppliers at each stage.
Below is a set of the most common points to ensure are covered, and each of them are linked to a sub-section in this section.
|
Activity |
Description |
|
Issue of RFP Documentation |
This date would require all supporting documents relevant to the RFP. If there is a competition being ran, this would also include further instructions required for this, together with the data correctly labelled as relevant. |
|
Suppliers Questions Due |
Suppliers should be able to submit questions about the proposal. This is often done through a portal or sending an excel file. Often the answers of suppliers are made public to all other suppliers so that all suppliers are able to have the same context when proposing the solution. |
|
Supplier Proposals Deadline |
This is the deadline for the proposals. If there is an ongoing competition in place, extra deadlines may apply, such as potential evaluation day, or requirement to provide access to the solution to run an unseen test-case for evaluation. |
|
Short-list announcement |
The selected short-list suppliers are notified and invited to participate in further negotiations which may require changes in the initial proposals. Suppliers that are not selected are also notified. |
|
Preferred supplier notified |
Once the preferred supplier is selected, the offer and contract are sent, which should provide a the framework agreement together with the relevant statements of work required, as well as SLAs, license terms, etc. |
|
Contract drafted & signed |
It’s worth also having a deadline for contract signing to make sure the process doesn’t drag out. |
|
Project kick-off date |
The project kick-off date should be agreed beforehand, and updated depending on changes on scope that may have arisen |
|
Example Project Timeline for “Manufacturing Group Limited”
|
3.6 - Issue of RFP Documentation
This section contains an overview of all the documents that the suppliers will receive with the documentation.
|
Example Issue of RFP Documentation for “Manufacturing Group Limited” Manufacturing Group Limited will be sending all suppliers the following documentations on the issuing date:
|
3.7 - Supplier questions due
This section should cover instructions of how suppliers should submit questions. Some of the points that are advised to have include:
-
Suppliers are able to see each other’s questions and answers
-
Clear deadline that reflects the one provided in the previous section
-
Instructions for suppliers to submit the questions
-
Specific points where answers cannot be provided for any reason
|
Example Suppliers questions due for “Manufacturing Group Limited”
|
3.8 - Supplier proposals deadline
This section provides details on how the suppliers should submit the proposals to the company (portal, email, etc). This should also cover whether extensions can be made for suppliers.
|
Example supplier proposals deadline for “Manufacturing Group Limited”
|
3.9 - Short-list negotiations
This section should contain information for suppliers to understand what they are expected to do during and after the short-list announcement. The three main points are outlined in the table below:
|
Activity |
Description |
|
Feedback |
The level of feedback that will be given to successful and optional unsuccessful suppliers |
|
Negotiations and proposal amendments |
Short-listed suppliers are often expected to receive feedback that will require changes on their initial proposals. This section should cover what the expected next steps will be. |
|
Example short-list negotiations for “Manufacturing Group Limited”
|
3.10 - Preferred supplier contract drafting
This section should contain information for suppliers to understand what the successful supplier and unsuccessful short-listed suppliers are supposed to do. The main points covered are provided in the table below.
|
Activity |
Description |
|
Notification channel |
How suppliers will be notified of the short-list and actions |
|
Feedback |
The level of feedback that will be given to the preferred supplier and unsuccessful short-listed suppliers |
|
Next steps |
High-level instructions of what selected supplier should go forward - this will mainly consist of drafting and finalising all contracts |
|
Short-listed supplier terms |
If there are any terms where it is desired to have other suppliers potentially involved at a later date, or if there is the potential of having short-listed proposals valid for a longer period of time |
|
Example preferred supplier contract drafting for “Manufacturing Group Limited”
|
4 - Detailed Scope
This chapter contain an overview of what requirements supplier proposals are expected to contain. The structure of this chapter was obtained from the most common stages identified in RFPs for machine learning solutions, which are outlined in the table below:
|
Phase |
Description |
|
Proof of concept competition |
In the context of machine learning systems, suppliers are often required to compete against each other by evaluating the performance of their solutions based on the client’s data and feature requirements. For smaller procurement processes, this could be a more informal evaluation such as trying out multiple different systems, but for larger tenders there is a requirement for formal processes. This document provides an example of best practices when running a competition to evaluate machine learning based solutions. |
|
Productisation |
Suppliers should provide detailed insight on the work that still needs to be carried out for the solution to be operated fully in production. This includes further development on the proof of concept, enterprise integration, training and even operational transformation required for the system to be in production. This is often a one-off service, and should include the resources and timelines required to be carried out successfully. |
|
License |
The licensing overview provides an insight of contract length, service-level-agreement, volumes, limits, training included. |
|
Further Services |
This encompasses an overview of the costs and resources required to extend the systems that have been deployed. |
This chapter has been put together using the Machine Learning Maturity Model assessment criteria. Each section takes into consideration each of the criteria implicitly. It is recommended to take into consideration all the 8 assessment criteria when putting together this section.
4.1 - Competition
This section contains the instructions, documentation and datasets required for the suppliers to be able to carry out the competition. It’s important that the competition is representative of the challenge presented, and that it references the right areas in “Chapter 2 - Our Process”, in order for suppliers to get complete context.
The details to put together a strong competition for suppliers are covered in the “AI Competition Tender” template which can be downloaded from the website. However, below there is a high-level process outlined on how competitions can be set up.
In summary, the generic process required to prepare a competition for a machine learning system, it requires the following steps:
-
For the end-to-end process, identify the datasets used (as outlined in chapter 2)
-
For more complex challenges, you will require more examples
-
-
Identify the final insights or decisions that are inferred from these datasets
-
This often requires manual work, as it’s important that the datasets come together with the answers that are expected to be predicted by the ML models
-
-
Split the data into a TEST dataset, and an EVALUATION dataset
-
Each contains the datasets and answers
-
-
Give the TEST dataset to the suppliers so they build a machine learning model
-
Evaluate the suppliers with the evaluation set
There are key points that need to be taken into consideration, including:
-
Evaluation metrics should go beyond accuracy (precision, recall, etc)
-
The expertise required to operate the system
-
The work required to get to that level of accuracy
-
Access to domain experts as relevant for suppliers to obtain understanding on datasets and ways of analysing datasets
|
Example Competition for “Manufacturing Group Limited” Overview
Evaluation Metrics
Evaluation Process
|
4.2 - Locations
This section should contain information about the exact locations where the system will be installed, as well as the locations where the system will be used in order to provide an idea of the support timetable required.
|
Example Locations for “Manufacturing Group Limited” Please find below a table of the locations of the offices requiring these goods and services:
|
4.3 - Implementation
4.3.1 - Data-source information
This section contains an overview of the all the data-sources where the data comes from. The two main approaches for integration of suppliers is push and/or pull systems. This means that either supplier systems can pull from the company’s systems, or alternatively the company can push to the supplier’s APIs. If there is preference, this should be the section where it should be covered. If it is expected for suppliers to integrate with the company’s systems, this section should contain a high level overview of the datasets in the system.
|
Example Data-source information for “Manufacturing Group Limited” The three main data-sources are provided in the table below. We expect suppliers to integrate to all of our systems individually and poll every hour for new content. We expect suppliers to have a way to keep track of the machines that have already been processed. We also expect the system to be able to notify the relevant stakeholder through our MyERP system.
|
4.3.2 - Infrastructure Available
This section should cover the infrastructure that is available for suppliers to perform the deployment of their platforms. Example infrastructure available can be:
-
Physical servers that can be provisioned for the supplier
-
Container infrastructure (Kubernetes / Openshift Cluster)
-
Preferred cloud provider (Google cloud, AWS, Azure, etc)
-
Hadoop-based infrastructure
There should also be information about the known limitations and constraints that suppliers will require, such as maximum RAM or Video memory. Although not always, machine learning computations may be quite heavy, so it’s important that this is made explicit by suppliers.
|
Example infrastructure available for “Manufacturing Group Limited” We have a simple physical server architecture, but we are currently moving towards cloud. Initially suppliers will only have access to one server with 60GB RAM, however we expect to migrate by mid-next year. Suppliers should include in their proposal a migration plan together with complexity and costs. |
4.3.3 - Detailed supplier information
This section should consist of a list of points that suppliers should make sure they include with their proposals. The example provided contains a table with a set of commonly required sections that are expected in supplier proposals.
|
Example detailed supplier evaluation for “Manufacturing Group Limited” We expect suppliers to go into detail on their implementation requirements, and cover at least the points mentioned in the table below.
|
4.4 - IP Ownership
This section should provide an overview of what are the expectations of IP ownership to be in place. This may vary depending on how much custom development is being requested by the suppliers, however a common standard in industry is provided in the example below.
|
Example IP Ownership for “Manufacturing Group Limited” The high level requirements stated by Manufacturing Group Limited in regards to IP ownership are as follows:
|
4.5 - Key Contract terms
This section should provide an overview of key term metrics in the contract/license.
|
Phase |
Description |
|
Length |
Length of the contract |
|
Renewal |
Process for contract to be renewed |
|
Cancellation |
Terms for company or supplier to cancel agreement, together with timelines |
|
Example Contract Terms (High Level) for “Manufacturing Group Limited”
|
4.6 - Required service levels (SLAs)
This section should contain the service level agreements that the suppliers should abide by. This would comprise of:
-
Definition of issue levels (critical, severe, small), together with:
-
Response timeframe
-
Bug fix timeframe
-
Permanent fix timeframe
-
-
Recovery point objective
-
Recovery time objective
-
Support locations and languages
-
Support portal from supplier (Helpdesk, portal, email, etc)
The reason why machine learning accuracy is not added in this list, is because it is often too ambiguous to define an actual number as an umbrella. Often the definition of the types of issue cover in part the point of accuracy indirectly, as the system would become non-functional if the accuracy decreases significantly. If there are constraints in the SLA defined for accuracy, it should be approached with care by both company and suppliers, as if not taken a high-level approach, it may lead to a more brittle agreement that may affect negatively the suppliers or the company (or both).
|
Example Required Service Levels for “Manufacturing Group Limited” We require our suppliers to provide us with a SLA consisting of the following points:
|
4.7 - Financial and company information
This section should outline the company information that suppliers need to provide in their proposals. RFP authors should be aware when setting the minimum financial requirement timelines, as there may be less mature startups that would not be able to take part in the tender process.
|
Example Financial and Company information for “Manufacturing Group Limited”
|
4.8 - Sub-contracting
This section should outline whether subcontracting is expected for suppliers. Depending on requirements,
|
Example Sub-contracting for “Manufacturing Group Limited” The supplier shall not subcontract any aspect of the service without prior written consent from Manufacturing Group Limited, whose consent shall not be responsibility of the supplier to ensure all subcontractors have received the necessary security clearance and training, where appropriate. |
5 - Contractual terms & conditions
5.1 - Legal conditions
This section should contain information about the contract that will be used. It may be best practice to share a link to a contract, or provide a template for suppliers to add comments in the first or second phase of the procurement process.
|
Example legal conditions for “Manufacturing Group Limited”
|
5.2 - Validity
This section should contain information on the validity of the proposals, commercial offers, etc.
|
Example validity for “Manufacturing Group Limited” Suppliers agree that by participating in this process, any proposals or commercial offers shall remain valid for a minimum of 90 days |
5.3 - Limited liability
This section should provide information about the liability for the company and the suppliers.
|
Example limited liability for “Manufacturing Group Limited” Manufacturing Group Limited accepts no liability for any of the costs associated with your response to this invitation to tender. Suppliers are therefore not entitled to compensation from Manufacturing Group Limited for any time, effort or expense incurred in preparing bids. You should only respond to this document in this basis. Manufacturing Group Limited reserves the right to:
|
5.4 - Confidentiality
This section should contain the confidentiality agreement that suppliers must agree in order to work with the company. The example below assumes there is an external NDA that was previously signed by suppliers. This may be required depending the confidential nature of the project.
|
Example Confidentiality for “Manufacturing Group Limited”
|


GOP Rep. Reed: I'm Seeing Democrats 'Coming Out Potentially Against Impeachment' | Breitbart
by Ian HanchettOn Monday’s broadcast of the Fox Business Network’s “Varney & Co.,” Representative Tom Reed (R-NY) stated that he doesn’t see any Republicans in the House moving towards supporting impeachment, but he does “see Democratic members that are coming out potentially against impeachment in the private conversations I’ve been having.”
Reed said, “I don’t see the movement in any way on the Republican side. The movement I am picking up on is I see Democratic members that are coming out potentially against impeachment in the private conversations I’ve been having. So, I would keep an eye out there.”
Follow Ian Hanchett on Twitter @IanHanchett


--- layout: post title: git advanced config and shortcuts / aliases date: '2013-02-21T20:42:00+01:00' tags: [git] category: 'Server' tumblr_url: http://andywenk.tumblr.com/post/43660524895/git-advanced-config-and-shortcuts-aliases ---
Moin Moin,
wow - two git related posts today ;-)
I recently found a very nice page with helpful git settings. They are written by Mislav Marohnic. On the first page he is discussing Git merge vs. rebase:
http://mislav.uniqpath.com/2013/02/merge-vs-rebase/
The second one is offering some nice tips when using git:
http://mislav.uniqpath.com/2010/07/git-tips/
So it should be a good thing to add some aliases to your ~/.gitconfig. Let’s say you wanna set the shortcut ‘pu’ for pull but with an extra option to always use rebase when pulling:
This helps you to avoid flooding your history with unnecessary merge commits.
Here some helpful shortcuts taken from my ~/.gitconfig:
I found an entry on stackoverflow giving some insight on how to use aliases: http://stackoverflow.com/questions/2553786/how-do-i-alias-commands-in-git
Cheers
Andy


Assignment: Add an output device to a microcontroller board you've designed and program it to do something
output_devices/index.htmlOnce again I tried to design a shield that could be useful for my final project.
Table size (LxP): 232.2 x 156.6 mm
Distance from collet tip to table: 232.2 x 156.6 mm
Components:
- 1 Resistors 10K
- 2 Resistors 499
- Yellow Led
- S1 switch 6mm
- 2 Capacitors 0.1 UF
- 1 Capacitors 1 UF
- Header 6 Pin
- Resonator 8MHZ
I have chosen the Servo motor because I would like to apply this output device in my final project. I want to create a mechanical movement based on that. My intention is to move a surface according to inputs such as light, sound and humidity.
Components:
- Micro servo SG90 9G TOWERPRO
- Trimpot 10K with Knob
- Header 4 Pin
SETTING MACHINE:
- Open fabmodules.org
- Click on Input Format;
- Choose Image(.png) and Upload Image;
- Click on Output Format and choose "Roland Mill (.rml)";
- Machine Settings;
- Machine: SRM-20; Speed: 4; Jog: 1; Xmin: 0; Ymin: 0;
- CLick on Process and choose "PCB traces(1/64)" or "PCB outline(1/32)";
- Change offset to 5 (this is a personal setting);
- Hit Calculate;
- Save.
Instructions:
- Turn on the machine for the heating, at least for 20 minutes.
- Open the Fab Modules on a browser (fabmodules.org) and on the new window selected the endmill settings as 1/64".
- Click on the “load" button and selected the file (mine was simply OUTPUT1.png) and then set the machine type as SRM20. Press calculate. Fabmodules generates .rml file.
- When the machine is ready, open Roland Vpanel. Load the .rml file.
- Set the X,Y,Z axes.
- Now you can mill.
- To cut the board a 1/32th n-mill is needed, change the drill tool to the 1/32" on the Fabmodules.org, and repeat the process.
- Open again Roland Vpanel. Load the new .rml file.
- Set only Z origin.
- Repeat the same operation for every file.
I designed the board to place a potentiometer (Trimpot 10K with Knob). After various tests, however, I realized that the potentiometer I had available was defective. So, to save time, I simplified the output, using only the servomotor. In any case, the board is still designed to accept the potentiometer.
Arduino Sketch to program the microcontroller.
The output board worked as expected.