--- layout: post title: "Flattening arrow code using a stack of monads" description: "Flatten arrow code with a stack of monads. A horrible example in C#." date: 2018-07-30 6:05 UTC tags: [Software Design, Functional Programming, F#] --- {% include JB/setup %}
{{ page.description }}
In the previous article, you saw how to refactor an injected dependency to a Visitor that implements a free monad. One remaining problem is that some of the code tends towards the Arrow anti-pattern. In this article, you'll see how elegantly you can deal with this in Haskell, how it translates to slightly more verbose F# code, but how, even though it does translate all the way to C#, it stops being nice along the way.
All code for this article is available on GitHub.
This is the problematic code:
public IReservationsProgram<int?> TryAccept(Reservation reservation) { return ReservationsProgram .IsReservationInFuture(reservation) .SelectMany(isInFuture => { if (!isInFuture) return new Pure<int?>(null); return ReservationsProgram .ReadReservations(reservation.Date) .SelectMany(reservations => { var reservedSeats = reservations.Sum(r => r.Quantity); if (Capacity < reservedSeats + reservation.Quantity) return new Pure<int?>(null); reservation.IsAccepted = true; return ReservationsProgram .Create(reservation) .Select(x => new int?(x)); }); }); }
Perhaps it doesn't look that bad, but I think that that's mostly a result of the original example being as simple as it is. After all, the original example code started out like this:
public int? TryAccept(Reservation reservation) { if (!ReservationsRepository.IsReservationInFuture(reservation)) return null; var reservedSeats = ReservationsRepository .ReadReservations(reservation.Date) .Sum(r => r.Quantity); if (Capacity < reservedSeats + reservation.Quantity) return null; reservation.IsAccepted = true; return ReservationsRepository.Create(reservation); }
The cyclomatic complexity of this method could be as low as 3, so if this was real production code, there'd be no reason to refactor it. As with most of my articles, however, you have to think of this example problem as a stand-in for something more complicated.
If you take a second look at the top version (which is actually the later version), I hope you'll agree that the change has harmed the code. In general, it's more noisy, and it shows a clear tendency towards the dreaded Arrow anti-pattern. Again, it may not look that bad here, but if you imagine that we're looking at a stand-in for a much worse problem, I hope you can see how this could quickly become unsustainable.
Part of the problem is that while C# has some syntactic sugar for monads, you can't branch inside a query expression, so instead it seems as though you're stuck with such nested closures.
F#, on the other hand, doesn't have that limitation. In F#, you can branch inside of computation expressions, so would that address the problem? Unfortunately, that's not the whole story. Here's an attempt at writing equivalent code in F#, using a custom reservations
computation expression:
// int -> Reservation -> ReservationsProgram<int option> let tryAccept capacity reservation = reservations { let! isInFuture = isReservationInFuture reservation if not isInFuture then return None else let! reservations = readReservations reservation.Date let reservedSeats = List.sumBy (fun r -> r.Quantity) reservations if (capacity < reservedSeats + reservation.Quantity) then return None else let! reservationId = create { reservation with IsAccepted = true } return Some reservationId }
While this is, in my opinion, more readable than the C# code, it doesn't successfully address the Arrow anti-pattern. While it's perfectly possible to branch (that is: use if
, then
, and else
) inside a computation expression, we run into another problem. In statement-based languages like C# and Java, you can use Guard Clauses to return early, as the original, pretty C# example demonstrates. In expression-based languages like F# and Haskell, on the other hand, any if
branch must have a corresponding else
branch, and both branches must return a value of the same type. This restriction forces the above F# code into the same Arrow shape as the problematic C# code.
Languages like F# and Haskell would be poor languages, though, if they didn't have ways to address problems like this one.
While it already feels unpleasant to write F# code like the above, writing similar code in Haskell would be figuratively painful. In Haskell, however, you essentially just change the return type of your function, pull in some standard library functions, and before you know it, you have nice flat code, with nary an Arrow in sight:
tryAccept :: Int -> Reservation -> MaybeT ReservationsProgram Int tryAccept capacity reservation = do guard =<< isReservationInFuture reservation reservations <- readReservations $ reservationDate reservation let reservedSeats = sum $ reservationQuantity <$> reservations guard $ reservedSeats + reservationQuantity reservation <= capacity create $ reservation { reservationIsAccepted = True }
One of the notable traits of Haskell is that, because of its high-level abstractions, changing the type of an expression can change its behaviour. In this case, I decided to add a MaybeT
to the ReservationsProgram Int
return type. This means that not only does the following code take place inside the ReservationsProgram
free monad, it takes place inside a stack of monads. In this case, the stack consists of Maybe
and ReservationsProgram
.
What this means is that you can use the built-in guard
function to short-circuit the program if the guards fail. Yes, these are literally guard clauses!
Not only does this address the Arrow anti-pattern, it completely flattens the code so that the happy path is emphasised.
While Haskell comes with built-in monad transformers that enable you to declaratively stack monads, you'll have to do it manually in F#. It's still possible, though. All it takes to stack ReservationsProgram
and option
is something like this:
// ('a -> ReservationsProgram<'b option>) -> ReservationsProgram<'a option> -> // ReservationsProgram<'b option> let bind f x = reservations { let! x' = x match x' with | Some x'' -> return! f x'' | None -> return None } type ReservationsOptionBuilder () = member this.Bind (x, f) = bind f x member this.Return x = Pure (Some x) member this.ReturnFrom x = x member this.Zero () = Pure (Some ()) let reservationsOption = ReservationsOptionBuilder ()
This stack of monads specifically handles the combination where a ReservationsProgram
contains an option
value. It considers the continuation value x'
produced by the previous step in a ReservationsProgram
, and only continues with f
if the value is a Some
value. Just like option
normally works, it short-circuits further processing if the value is a None
value.
While F# doesn't have a general-purpose guard
function, you can easily write one for this particular stack of monads:
// bool -> ReservationsProgram<unit option> let guard = function | true -> Pure (Some ()) | false -> Pure None
This function takes a Boolean value as input, and returns Pure (Some ())
when the value is true
, and Pure None
otherwise. While this seems weird at first glance, this is essentially what Haskell's guard
does in the above code listing. The point is that Pure None
short-circuits further processing, while Pure (Some ())
allows the program to continue, as per the above bind
function.
You can now write a flattened version of tryAccept
// int -> Reservation -> ReservationsProgram<int option> let tryAccept capacity reservation = reservationsOption { do! ReservationsOption.bind guard <| isReservationInFuture reservation let! reservations = readReservations reservation.Date let reservedSeats = List.sumBy (fun r -> r.Quantity) reservations do! guard (reservedSeats + reservation.Quantity <= capacity) return! create { reservation with IsAccepted = true } }
Notice that the type of the function doesn't change. It still returns a ReservationsProgram<int option>
, but the implementation is different. Instead of explicitly dealing with branching in a reservations
computation expression, it implicitly deals with it in the composed reservationsOption
computation expression.
Using the specialised guard
function doesn't look as pretty as in Haskell, but it gets the job done.
Can you do the same in C#? Yes, sort of, but it'll be ugly.
As a first step, you'll need a Maybe monad, as this isn't a built-in type in C#. While I'd typically prefer a simpler implementation, since we're already looking at Church-encoded sum types, let's take the Church-encoded Maybe implementation, and refactor it to a Visitor. The IMaybe<T>
interface is simply this:
public interface IMaybe<T> { TResult Accept<TResult>(IMaybeVisitor<T, TResult> visitor); }
The Visitor is defined like this:
public interface IMaybeVisitor<T, TResult> { TResult VisitNothing { get; } TResult VisitJust(T just); }
This is, hopefully, not terribly surprising. There's two cases: just and nothing, and only the just case has a value associated. While I'm not going to walk you through all the details, this version of IMaybe<T>
is still a monad:
public static IMaybe<TResult> SelectMany<T, TResult>( this IMaybe<T> source, Func<T, IMaybe<TResult>> selector) { return source.Accept(new SelectManyMaybeVisitor<T, TResult>(selector)); }
If you want to see how SelectManyMaybeVisitor<T, TResult>
is implemented, you can see it in the code repository, but otherwise, it's also a good exercise to see if you can puzzle it out yourself.
You already have the IReservationsProgram<T>
and IMaybe<T>
monads. Now you just need to stack them, just like the above F# code:
public static IReservationsProgram<IMaybe<TResult>> SelectMany<T, TResult>( this IReservationsProgram<IMaybe<T>> source, Func<T, IReservationsProgram<IMaybe<TResult>>> selector) { return source.SelectMany(x => x.Accept(new SelectManyMaybeVisitor<T, TResult>(selector))); } private class SelectManyMaybeVisitor<T, TResult> : IMaybeVisitor<T, IReservationsProgram<IMaybe<TResult>>> { private readonly Func<T, IReservationsProgram<IMaybe<TResult>>> selector; public SelectManyMaybeVisitor(Func<T, IReservationsProgram<IMaybe<TResult>>> selector) { this.selector = selector; } public IReservationsProgram<IMaybe<TResult>> VisitNothing { get { return new Pure<IMaybe<TResult>>(new Nothing<TResult>()); } } public IReservationsProgram<IMaybe<TResult>> VisitJust(T just) { return this.selector(just); } }
Just like in the F# code, you can write the code inside of the IReservationsProgram<T>
monad. To do that, you call SelectMany
on source
. The x
in that lambda expression is a IMaybe<T>
value, so in order to be able to proceed, you'll have to call its Accept
method and pass it a Visitor.
The overall signature of the outer SelectMany
method is fixed. This is, after all, the monadic bind function, so you know that the return type must be IReservationsProgram<IMaybe<TResult>>
. Therefore, this must be the second type argument of the Visitor that you pass to Accept
, so the Visitor must have the type IMaybeVisitor<T, IReservationsProgram<IMaybe<TResult>>>
. From there, it's 'just' a matter of figuring out how to implement VisitNothing
and VisitJust
.
In the VisitNothing
case, you simply return a new Nothing<TResult>()
, but wrapped in a Pure
value, so that it becomes an IReservationsProgram<IMaybe<TResult>>
, rather than just an IMaybe<TResult>
.
In the VisitJust
case, you'll need the injected selector
, which you can simply call with the input argument and return the result.
In order to support query expressions, you'll also need this special SelectMany
overload:
public static IReservationsProgram<IMaybe<TResult>> SelectMany<T, U, TResult>( this IReservationsProgram<IMaybe<T>> source, Func<T, IReservationsProgram<IMaybe<U>>> k, Func<T, U, TResult> s) { return source .SelectMany(x => k(x) .SelectMany(y => new Pure<IMaybe<TResult>>(new Just<TResult>(s(x, y))))); }
This is merely a weird C# technical detail, so I'm not going to tire you with this. It's not interesting.
Like the above F# code, you can define a specialised Guard
method:
public static IReservationsProgram<IMaybe<Unit>> Guard(bool b) { if (b) return new Pure<IMaybe<Unit>>(new Just<Unit>(Unit.Instance)); else return new Pure<IMaybe<Unit>>(new Nothing<Unit>()); }
It does the same as its F# counterpart, only is it more verbose, and it required me to define a unit type, because C# doesn't have one:
public class Unit { public readonly static Unit Instance = new Unit(); private Unit() { } }
This is simply a Singleton that carries no data. It's like void
, but can act as a generic return type, which is what we need here.
Finally, in order to be able to set IsAccepted
to true
and make it look like a function, you can add a Do
method:
public static IReservationsProgram<IMaybe<Unit>> Do(Action action) { action(); return new Pure<IMaybe<Unit>>(new Just<Unit>(Unit.Instance)); }
This is a nasty piece of impure code, but it'll get the job done. It'd also be possible to refactor to a make the Reservation
class immutable, but for this proof of concept code, that's not necessary.
The point of the method is to enable method chaining in the Fluent style, even while you're mutating state. In general, I'd like to warn against doing something like this, because the entire point of functional programming is to avoid mutating state. It does allow us, however, to reproduce the original behaviour in the top of the article, which also mutates the reservation
argument.
You can now write TryAccept
as an IReservationsProgram<IMaybe<int>>
method, instead of IReservationsProgram<int?>
. In other words, you replace the int?
(Nullable<int>
) with IMaybe<int>
. This enables you write the entire program as a 'flat' composition, by chaining calls to SelectMany
and Select
:
public IReservationsProgram<IMaybe<int>> TryAccept(Reservation reservation) { return ReservationsProgram.IsReservationInFuture(reservation) .SelectMany(isInFuture => ReservationsProgram.Guard(isInFuture)) .SelectMany((Unit _) => ReservationsProgram.ReadReservations(reservation.Date)) .Select(reservations => reservations.Sum(r => r.Quantity)) .SelectMany(reservedSeats => ReservationsProgram.Guard(reservedSeats + reservation.Quantity <= Capacity)) .SelectMany((Unit _) => ReservationsProgram.Do(() => { reservation.IsAccepted = true; })) .SelectMany((Unit _) => ReservationsProgram.Create(reservation)); }
You start with ReservationsProgram.IsReservationInFuture
and continue with SelectMany
off of its return value. Inside SelectMany
, you then call ReservationsProgram.Guard
in order to short-circuit if isInFuture
is false
. In fact, that step can be reduced to SelectMany(ReservationsProgram.Guard)
, using method group syntax.
While Guard
returns a program containing Unit
, you can still continue with SelectMany
to call ReservationsProgram.ReadReservations
.
I'm not going to walk you through the rest of this code, but it works.
If you can write an entire program by chaining SelectMany
and Select
, chances are you can write it using C# query syntax as well. This turns out to be the case:
public IReservationsProgram<IMaybe<int>> TryAccept(Reservation reservation) { return from isInFuture in ReservationsProgram.IsReservationInFuture(reservation) from _ in ReservationsProgram.Guard(isInFuture) from reservations in ReservationsProgram.ReadReservations(reservation.Date) let reservedSeats = reservations.Sum(r => r.Quantity) from __ in ReservationsProgram.Guard(reservedSeats + reservation.Quantity <= Capacity) from ___ in ReservationsProgram.Do(() => { reservation.IsAccepted = true; }) from id in ReservationsProgram.Create(reservation) select id; }
This is simply the 'sugared' version of the previous code. It's a little more succinct, but whether it's better is subjective at best. I think you'd be challenged to find anyone who'd consider this idiomatic C# code.
It gets the job done, though. It actually works!
To be clear, I'm not particularly impressed with the readability of this. I love the Haskell version, but the C# translation isn't my cup of tea.
When I go to meetups and conferences, I often get the chance to talk to people who have read my articles or seen my talks on functional programming. I often get the question whether it's possible to use some of the wonderful F# and Haskell concepts in C#. This article answers such questions. Yes, it's possible, but what's the point?
Such code is brittle, because you're dancing on the edge of what C# can do. I had to accept some compromises just to get this proof-of-concept code to work. To add spite to injury, the code is not as readable as idiomatic C#, and it taps into concepts that most C# developers wouldn't be familiar with.
I'd expect most C# programmers to consider a code base like this unreadable. In the amount of time it takes to understand and learn the underlying concepts of monads and their syntactic sugar, one can learn a proper functional programming language like F#. Don't try to make C# do something it wasn't designed to do; just use a functional programming language; you can learn that sooner than you'll be able to make sense of this Frankenstein's monster shown here.


xf-material-input
In general all HTML types will be supported. However some of these types will still need some
extra consideration.
a bound value
[
{
"bind": {
"id": "b-value",
"value": "a bound value"
}
}
]
Material input
a simple material input
date type
color type
datetime-local type
email type
month type
number type
password type
range type
search type
time type
week type


Student Details
Parent/Guardian Details
Emergency Contact & Siblings Details
School Details
Other Details
Uploads & Declaration
4. School Details
4.1 Current School Attended
Current School Attended(If Any)
Yes
No
4.2 Other School Attended
International School
Yes
No
Does your child has any discontinuation in his/her studies?
Yes
No
Does your child has any learning disabilities?
Yes
No
Does your child needs any special educational help?
Yes
No
Has your child met with any discipline issues?
Yes
No
Does your child have any special concerns(Eg:Speech,Language,health,other?
Yes
No
4.3 School Preferences
Please list below all your prefered schools in priority order.
Preference
Preferred School
Siblings already attending the school
Reason
1st
2nd
3rd
4th
--Next--


result of addition : {{ msg }}
Data on page: {{ data }}
Site on page: {{ Site }}
Go back to home page
Add/Remove another entry or file


Find documents
Case documents
Find a case using a case reference number. For Access UK cases, use the Unique Application Number (UAN).
How to find the Unique Application Number (UAN)
The Unique Application Number is automatically assigned to a case when an applicant applies through GOV.UK. The Unique Application Number is shown when you view the case in the Casework Information Database (CID).


DIRTY DANCING A film review by Ken Perlow Copyright 1987 Ken Perlow
Based on the previews, you probably wouldn't go see DIRTY DANCING unless you're either bored out of your skull or under 16. And you'd miss a real gem. I was curious because the screenplay was written by a woman, and this is pretty rare for the usual LA-LA fare. (I had visions of my delight at ROMANCING THE STONE--for once a heroine not made of perfumed cardboard.)
I was expecting SATURDAY NIGHT FEVER. But what I saw was a tight, emotional, well-told story of a fall from innocence. With real people. It's the summer of '63, the the twilight of the Camelot days. If this is a movie for kiddies, they'll never understand that special time. With Kennedy's death and then into Vietnam, we all grew up in a hurry.
Interestingly, as with ROMANCING THE STONE, it's the male characters who are a bit stereotypical. The male lead (one of these days I'll remember names of actors, directors, et al. and write *real* reviews) is a classic "noble savage" right out of Rousseau, but you want to believe it anyway. There's also a slimy, effete twit who justifies his arrogance in a marvelous scene where he pulls a copy of THE FOUNTAINHEAD out of his pocket and tells the female lead, "It's all in here. I've made notes in the margins."
Ah, Jennifer Grey. She did a first-class, remarkably subtle job on a part that begs to be overacted. And can she dance or what?
 I'd give it a solid 2 stars on the Leeper Scale. The Ayn Rand-trashing scene alone is worth the price of evening admission.
ken perlow<PHONE_NUMBER> ihnp4!ihlpa!gadfly
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


Relink
Login
Invalid username and password
Account successfully created!
Sign in to Relink
Username
Password
Sign In
Create an Account
or
Sign In With Github
Sign In With Google


|
|
To access Support Online, you need to be connected to the Internet. Windows 98 has detected that you currently do not have an Internet connection set up.
Connect me to the Internet.
If you have never connected to the Internet before, the Internet Connection wizard will help you sign up for Internet access. After you are connected to the Internet, your Internet browser will bring up the Support Online site. If you believe that you have already established an Internet connection, click this link to retry to connect to Support Online.
I will connect to Support Online later.
If you do not want to connect to Support Online at this time, click this link to close the browser window. When you are ready to return to Support Online, you can choose to create a new connection to the Internet at any time by doing the following:
- Click Start.
- Point to Programs, point to Internet Explorer, and then click on Connection Wizard.
- The Internet Connection wizard will help you select an Internet Service Provider (ISP) or connect you to your Local Area Network (LAN).
|
|


OutputDevice
public class CommandLineOutput extends java.lang.Object implements OutputDevice
| Constructor | Description |
|---|---|
CommandLineOutput() |
| Modifier and Type | Method | Description |
|---|---|---|
void |
displayHand(java.lang.String name,
java.util.Collection<java.lang.Integer> hand) |
Prints the name and hand.
|
void |
displayHandSize(java.lang.String name,
int handSize) |
Prints the name of the player and their hand size
|
void |
displayIntro(Player p1,
Player p2) |
Prints the names of Player 1 and Player 2 in the format:
|
void |
displayResults(java.lang.String p1,
java.lang.String p2,
GameResult result) |
Displays the game result.
|
void |
displayStats(int p1WinHigherSum,
int p1WinOppBust,
int p2WinHigherSum,
int p2WinOppBust,
int tieGameEqualSum,
int tieBothBust) |
Prints the game statistics.
|
void |
endOfGame() |
Prints a line of dashes.
|
void |
promptForAction() |
Prompts the player to input 'h' or 's' to hit or stand (respectively).
|
void |
promptForName() |
Prompts for a name to be entered.
|
void |
promptForPlayerType() |
Prompts an input of 'hp' for humand player type and 'spb' for SafePlayBot.
|
void |
promptNumGames() |
Prompts for the number of games.
|
void |
splitTurn() |
Prints a blank line (used to separate chunks of printing, such as between the
turns of the players)
|
public void displayIntro(Player p1, Player p2)
displayIntro
in interface OutputDevice
p1
- Player 1p2
- Player 2public void promptForAction()
promptForAction
in interface OutputDevice
public void displayResults(java.lang.String p1, java.lang.String p2, GameResult result)
displayResults
in interface OutputDevice
p1
- the name of Player 1p2
- the name of Player 2result
- the result of the gamepublic void displayHand(java.lang.String name, java.util.Collection<java.lang.Integer> hand)
displayHand
in interface OutputDevice
name
- the name of the player who has the handhand
- the hand of cards to printpublic void displayHandSize(java.lang.String name, int handSize)
displayHandSize
in interface OutputDevice
name
- the name of the playerhandSize
- the number of cards the player has in their handpublic void splitTurn()
splitTurn
in interface OutputDevice
public void endOfGame()
endOfGame
in interface OutputDevice
public void promptForPlayerType()
promptForPlayerType
in interface OutputDevice
public void promptForName()
promptForName
in interface OutputDevice
public void promptNumGames()
promptNumGames
in interface OutputDevice
public void displayStats(int p1WinHigherSum, int p1WinOppBust, int p2WinHigherSum, int p2WinOppBust, int tieGameEqualSum, int tieBothBust)
displayStats
in interface OutputDevice
p1WinHigherSum
- the number of times Player 1 won due to a higher sump1WinOppBust
- the number of times Player 1 won due to opponent
bustingp2WinHigherSum
- the number of times Player 2 won due to a higher sump2WinOppBust
- the number of times Player 2 won due to opponent
bustingtieGameEqualSum
- the number of times the game was tied by both players
having equal scores and not bustingtieBothBust
- the number of times the game was tied by both players
busting


As an agile coach for many years and the founder of TeamMood, I have been wondering and inquiring about different types of organizations over the years. Indeed, over the years, agile has become a dogma in many organizations, blindly following the principles of methodologies like Scrum, SAFe or XP, thus distorting the very principles of the Agile Manifesto. Following my last article on Radical agility, I wanted to go a step further and share some thoughts on “Teal organizations”, a concept explained by Frederic Laloux in his book Reinventing Organizations. Could this concept help companies realign with the Agile Manifesto?
This article doesn’t claim to summarize nor detail the niceties of such organizations. It is merely an introduction to the book based on my understanding, aiming at convincing its readers to peruse Frederic Laloux’s full manuscript (or its illustrated version , much more digestible, if you ask me).
***
If I imagine a dream company, I picture an organization in which employees are aligned with their firm’s purpose, are given the freedom and responsibility to manage the topics they feel called for and are encouraged to be their true selves at work. How would such a company work? And would it work?
Companies have long been considered as machines, in which people are defined by their role like a piece in the mechanism, and actions follow processes as machinery of a purring engine. In such companies, people are resources, pushed and monitored to reach goals and to continuously self-improve, with no consideration whatsoever for their psychological state.
The problem is: people are not robots that can blindly and coldly play a part that was written for them, leaving all feelings and personal matters aside. And considering them as such is the best way to a minor (or rather major) glitch in the organization: interpersonal issues, depressions, burnouts, … are flooding in organizations of all kinds.
I believe that companies should be considered as living beings, the place of individual and collective deployment in which we are “called to discover and rejoin our true nature, to deploy our unique potential, to unleash our innate talents” as Laloux says. Of course, such organizations require us to subdue our egos and to no longer allow ourselves to be governed by our fears, ambitions, and desires – but instead, to welcome them. They demand to follow our inner righteousness as a compass – our values and causes. They ask for a new level of consciousness, called “Teal” by American writer Ken Wilber – pioneer of the integral theory –, or “evolutive” by Frederic Laloux. And in return, they offer the end of cognitive dissonance and a path to fullness.
In Reinventing Organizations, Laloux shares the three pillars of “teal” organizations: self-management, wholeness, and evolutionary purpose. I did the exercise of imagining how an agile team applying these pillars would work. The following thoughts are mine only.
The power of self-management
Laloux describes self-management as a system based on peer relationships, with no need for a fixed and statutory hierarchy, consensus, nor central command and control. Without falling in the trap of horizontal organizations in which everyone has a voice on every topic, self-management offers a fluid and efficient system of distributed authority and collective intelligence.
This pillar makes total sense in agile teams. It even is one of the Agile manifesto principles: “Individuals and interactions over processes and tools”. Indeed, an agile team is a complex organization. Who better than the team members can choose how best to accomplish their work? In such a self-organized agile team, external considerations are taken into account of course. But the team members hold the power to make their own decisions and bear the responsibility to deliver their promise at the same time.
Don’t fall into the trap of flat organizations! Self-management doesn’t mean that everyone in the team has the influence on decisions, nor that the team needs a consensus to make a decision. An expert may have more leadership on certain topics than a newcomer. But the youngster may also be more comfortable than his elders on adopting new tools, and take the lead on a project according to his drive and skills.
Fostering wholeness
The idea of separating private and professional lives is based on the idea that we can (and should) act as two separate personas, a work persona who is efficient and focused, and a private persona who only expresses itself behind-the-scenes. It promotes the belief that one should leave personal matters at home. Emotions, feelings and aspirations are masked by the pressure of corporate or even societal cultures: a man doesn’t cry, a woman is less profitable because she gets pregnant, …
In reality, we are complex human beings and our personality includes all our different aspects: I am at the same time a father, a husband, a son, a friend, I care deeply about sustainability AND I am the founder of Teammood, an agile coach, a coworker, a volunteer in charities. Separating these worlds can only create a sense of misalignment. Rather than a truncated professional “I”, evolutive companies have developed processes that invite us to drop the masks, claim our integrity and come to work the way we are.
This pillar is particularly relevant in this period of confinement and massive working-from-home. Attending Zoom meetings in our living room, possibly with our kids playing nearby, can’t help but highlight personal environments and circumstances that used to be hidden or at least ignored.
Once again, this pillar completely applies to agile teams, in which team members are asked to be themselves to facilitate communication in the group. And to help you safely reach this level of authenticity, TeamMood allows you to share your current state of mind with your team.
Embrace an evolutionary purpose
Budgets, multi-year plans, and projections are common practice in most companies. But instead of taking it as it is, merely dreams and intentions for the future, companies hold to them and strive to make them happen. Let’s be honest, how can we predict anything in our complex and ever-evolving world? 2020 is a perfect example, and I believe radical changes are yet to come.
In teal organizations, instead of trying to predict and control the future, employees are encouraged to listen and understand what they are called upon to become and where they are naturally heading. The organization’s purpose is the result of the personal purposes, causes and values of the people who comprise it. Therefore, it evolves over time as the organization grows and people join or leave it.
Adopting an evolutionary purpose makes organizations more resilient, like a living system, which has a natural aptitude for change. Agile teams that embrace this state of mind will therefore be in a position to “adapt to change more than following the plan” (agile manifesto’s fourth principle) while listening to weak signals and making sensible choices according to the context around us.
I truly believe that if considered as a whole, given the freedom to self-organize and questioned about their purpose, values, and cases, agile (or not) team members will work towards the “desired change”, one that is concerned with social value and the impact on living beings – to borrow the words of Jean-Pascal Boignard, Claude Aubry, and Anthony Cassaigne.
Does that sound crazy to you? Utopian? Unrealistic? Yet dozens of companies around the world are successfully applying some of these principles: The Morning Star Company 🇺🇸, Patagonia 🇺🇸, AES (international), Buurtzorg 🇳🇱, ESBZ 🇩🇪, FAVI 🇫🇷, Varkey 🇬🇧, and many more.
***
Thanks to Adrien Tardif for his comments 🙏.
Header picture by Karim MANJRA on Unsplash


A B C D E F G H I L M N O P R S T U V W X
All Classes All Packages
All Classes All Packages
All Classes All Packages
N
- NameFilter - Class in com.ensoftcorp.open.commons.filters
-
Filters nodes and edges based on their name attributes
- NameFilter() - Constructor for class com.ensoftcorp.open.commons.filters.NameFilter
- next() - Method in class com.ensoftcorp.open.commons.algorithms.dominance.DepthFirstPreorderIterator
- node(Node) - Method in class com.ensoftcorp.open.commons.sandbox.Sandbox
-
Returns a node from the sandbox corresponding to the Atlas node, if it already exists in the sandbox.
- NodeFilter - Class in com.ensoftcorp.open.commons.filters
- NodeFilter() - Constructor for class com.ensoftcorp.open.commons.filters.NodeFilter
- nodes() - Method in class com.ensoftcorp.open.commons.algorithms.UniqueEntryExitControlFlowGraph
- nodes() - Method in class com.ensoftcorp.open.commons.algorithms.UniqueEntryExitCustomGraph
- nodes() - Method in interface com.ensoftcorp.open.commons.algorithms.UniqueEntryExitGraph
-
The set of nodes in the graph
- nodes() - Method in class com.ensoftcorp.open.commons.algorithms.UniqueEntryExitInterproceduralControlFlowGraph
- nodes() - Method in class com.ensoftcorp.open.commons.sandbox.SandboxGraph
-
Returns the nodes of this graph
- nodes(AtlasSet<Node>) - Method in class com.ensoftcorp.open.commons.sandbox.Sandbox
-
Returns a set of sandbox nodes contained in the sandbox universe corresponding to the given set Atlas graph nodes.
- nodes(String...) - Method in class com.ensoftcorp.open.commons.sandbox.SandboxGraph
-
A convenience method for nodes(String...
- nodesAttributeValuesContaining(Q, String, String) - Static method in class com.ensoftcorp.open.commons.analysis.CommonQueries
-
Returns the nodes whose attribute values contain the given string within the given context.
- nodesAttributeValuesContaining(String, String) - Static method in class com.ensoftcorp.open.commons.analysis.CommonQueries
-
Returns the nodes whose attribute values contain the given string.
- nodesAttributeValuesEndingWith(Q, String, String) - Static method in class com.ensoftcorp.open.commons.analysis.CommonQueries
-
Returns the nodes whose attribute values end with the given string within the given context.
- nodesAttributeValuesEndingWith(String, String) - Static method in class com.ensoftcorp.open.commons.analysis.CommonQueries
-
Returns the nodes whose attribute values end with the given string.
- nodesAttributeValuesMatchingRegex(Q, String, String) - Static method in class com.ensoftcorp.open.commons.analysis.CommonQueries
-
Returns the nodes whose attribute values match the given regular expression within the given context.
- nodesAttributeValuesMatchingRegex(String, String) - Static method in class com.ensoftcorp.open.commons.analysis.CommonQueries
-
Returns the nodes whose attribute values match the given regular expression.
- nodesAttributeValuesStartingWith(Q, String, String) - Static method in class com.ensoftcorp.open.commons.analysis.CommonQueries
-
Returns the nodes whose attribute values start with the given string within the given context.
- nodesAttributeValuesStartingWith(String, String) - Static method in class com.ensoftcorp.open.commons.analysis.CommonQueries
-
Returns the nodes whose attribute values start with the given string.
- nodesContaining(Q, String) - Static method in class com.ensoftcorp.open.commons.analysis.CommonQueries
-
Returns the nodes whose names contain the given string within the given context.
- nodesContaining(String) - Static method in class com.ensoftcorp.open.commons.analysis.CommonQueries
-
Returns the nodes whose names contain the given string.
- nodesEndingWith(Q, String) - Static method in class com.ensoftcorp.open.commons.analysis.CommonQueries
-
Returns the nodes whose names end with the given string within the given context.
- nodesEndingWith(String) - Static method in class com.ensoftcorp.open.commons.analysis.CommonQueries
-
Returns the nodes whose names end with the given string.
- nodeSize(Q) - Static method in class com.ensoftcorp.open.commons.analysis.CommonQueries
-
Returns the number of nodes contained.
- nodesMatchingRegex(Q, String) - Static method in class com.ensoftcorp.open.commons.analysis.CommonQueries
-
Returns the nodes whose names match the given regular expression within the given context.
- nodesMatchingRegex(String) - Static method in class com.ensoftcorp.open.commons.analysis.CommonQueries
-
Returns the nodes whose names match the given regular expression.
- NodeSourceCorrespondenceSorter - Class in com.ensoftcorp.open.commons.utilities
- NodeSourceCorrespondenceSorter() - Constructor for class com.ensoftcorp.open.commons.utilities.NodeSourceCorrespondenceSorter
- nodesStartingWith(Q, String) - Static method in class com.ensoftcorp.open.commons.analysis.CommonQueries
-
Returns the nodes whose names start with the given string within the given context.
- nodesStartingWith(String) - Static method in class com.ensoftcorp.open.commons.analysis.CommonQueries
-
Returns the nodes whose names start with the given string.
- nodesTaggedWithAll(String...) - Method in class com.ensoftcorp.open.commons.sandbox.SandboxGraph
-
Returns the set of nodes from this graph that are tagged with any of the given tags
- nodesTaggedWithAny(String...) - Method in class com.ensoftcorp.open.commons.sandbox.SandboxGraph
-
Returns the set of nodes from this graph that are tagged with all of the given tags
- nodesWithSelfEdges(Q) - Static method in class com.ensoftcorp.open.commons.analysis.CommonQueries
-
Returns those nodes in the context which have self edges.
- NORMALIZE_GRAPH_ELEMENT_ADDRESSES - Static variable in class com.ensoftcorp.open.commons.preferences.CommonsPreferences
-
Enable/disable node address normalization
- NORMALIZE_GRAPH_ELEMENT_ADDRESSES_DEFAULT - Static variable in class com.ensoftcorp.open.commons.preferences.CommonsPreferences
- NORMALIZED_ADDRESS_ATTRIBUTE - Static variable in class com.ensoftcorp.open.commons.utilities.address.NormalizedAddress
- NormalizedAddress - Class in com.ensoftcorp.open.commons.utilities.address
- NormalizedAddress() - Constructor for class com.ensoftcorp.open.commons.utilities.address.NormalizedAddress
- normalizeIntensity(long, long, long) - Static method in class com.ensoftcorp.open.commons.highlighter.HeatMap
-
Given the lower bound, upper bound, and actual value, normalize the actual value to a value between 0.0 and 1.0
- normalizeLogarithmicIntensity(Long, long, long) - Static method in class com.ensoftcorp.open.commons.highlighter.HeatMap
-
Given the lower bound, upper bound, and actual value, normalize the actual value to a log base 10 value between 0.0 and 1.0
All Classes All Packages


Model
public enum Model : UInt8
Atem model number
-
Television studio
Declaration
Swift
case tvStudio = 1
-
Undocumented
Declaration
Swift
case oneME
-
Undocumented
Declaration
Swift
case twoME
-
Undocumented
Declaration
Swift
case productionStudio4K
-
Undocumented
Declaration
Swift
case oneME4K
-
Undocumented
Declaration
Swift
case twoME4K
-
Undocumented
Declaration
Swift
case twoMEBroadcastStudio4K
-
Undocumented
Declaration
Swift
case tvStudioHD
-
Undocumented
Declaration
Swift
case tvStudioProHD
-
Undocumented
Declaration
Swift
case tvStudioPro4K
-
Undocumented
Declaration
Swift
case constellation
-
Undocumented
Declaration
Swift
case constallation8K
-
Undocumented
Declaration
Swift
case mini


{% extends 'structure.html' %} {% block title %} Privacy {% endblock title %} {% block main %}
Our terms of privacy are outlined here.


By transferring in 3 old account(s)¹ with an
average
balance of $8,100², participants can gain $8,748 from consolidation over 10 years³.
Total account balance after consolidation ⤵
$8,100Lower Fees Easier to ManageLower Cash out Risks$33,048
Unconsolidated Accounts
Consolidated Accounts
Inactive Participants
For every 1 inactive account
transferred
out, a plan can gain $540 in cost over 5 years⁵.
Total Cost Reduction from Transferring ⤵
$540
=
$360(72 x 5yrs)
Employer Cost⁶+
$180(36 x 5yrs)
Participant Cost⁷
Active Accounts
1The average American has 2.8 old accounts
(2,500 Participant Survey)
2$8,100 is the average retirement balance
in 2018
3Data assumes a 6% market return with a
long-term investment horizon
4Consolidation can increase an account by
36% over 10 years because the consolidated account is generally better managed, has lower cash out risks
and lower fees (Washington University)
Inactive Accounts
5The average inactive account stays in a
plan for 5 years or longer (Vanguard DC Survey 2018)
6Employers pay providers about $36/yr in
administrative fees and bear a cost of $36/yr for required regulatory communication and fiduciary risk
7Providers charge inactive participants
about $36 per year


GREY
(dom)
PURPLE
(dom)
ORANGE
(domclone)
WHITE
(loader)
GREEN
(builder)
TRANSPARENT
(void)
BROWN
(dom, block)
-
clear
PINK
(dom, block)
-
clear
ALERT
(function, command)
TRIGGER
(function, command)
DATE
(date, command)


DESCRIPTION The default signal for kill is TERM. Use -l or -L to list available sig‐ nals. Particularly useful signals include HUP, INT, KILL, STOP, CONT, and 0. Alternate signals may be specified in three ways: -9, -SIGKILL or -KILL. Negative PID values may be used to choose whole process groups; see the PGID column in ps command output. A PID of -1 is special; it indicates all processes except the kill process itself and init. OPTIONS <pid> [...] Send signal to every <pid> listed. -<signal> -s <signal> --signal <signal> Specify the signal to be sent. The signal can be specified by using name or number. The behavior of signals is explained in signal(7) manual page. -l, --list [signal] List signal names. This option has optional argument, which will convert signal number to signal name, or other way round. -L, --table List signal names in a nice table.  You may need to run the command described here as /bin/kill to solve the conflict.  SEE ALSO kill(2), killall(1), nice(1), pkill(1), renice(1), signal(7), skill(1) STANDARDS This command meets appropriate standards. The -L flag is Linux-specific. AUTHOR Albert Cahalan<EMAIL_ADDRESS>wrote kill in 1999 to replace a bsdutils one that was not standards compliant. The util-linux one might also work correctly. REPORTING BUGS Please send bug reports to<EMAIL_ADDRESS>procps-ng October 2011 KILL(1)


Use this rule to force the type of new line characters.
Be aware that, for simplicity reasons, only the first line of the YAML file is checked and therefore issues will be reported only on this first line. It is assumed that the whole document has the same new line characters as the first line, and if your document has different new line sequences this inconsistency will not be reported.
unix
to use UNIX-typed new line characters \n
), or dos
to use
DOS-typed new line characters (\r\n
).


Released in 2002, Software for Force was released until 2011. Any “Force” machine will only take “Force” software.
[Read More]Released in 2002, Software for Force was released until 2011. Any “Force” machine will only take “Force” software.
[Read More]


Nonprofits around San Francisco can apply and join GiveHub to access more donations, employ new skills, and make importan connections.
You can give what you can to your favorite organizations; You will get feedback about how great your donations are put to work by our trusted partner organizations.
Nonprofits have the resource they need to help communities all over San Francisco and become more awesome!


Africa
Second-largest continent (after Asia), straddling the equator and lying largely within the tropics. Africa's first great civilization emerged in ancient Egypt in c.3400 BC. Carthage was founded by Phoenicians in the 9th century BC.
Antarctica
The history of Antarctica emerges from early Western theories of a vast continent, known as Terra Australis, believed to exist in the far south of the globe. The term Antarctic, referring to the opposite of the Arctic Circle, was coined by Marinus of Tyre in the 2nd century AD.
Asia
The complex natural and geographical environment and diverse cultures and customs of Asia have given birth to a variety of distinctive regional civilizations over its thousands-year-long history.
Australia
The complex natural and geographical environment and diverse cultures and customs of Asia have given birth to a variety of distinctive regional civilizations over its thousands-year-long history.
Europe
The complex natural and geographical environment and diverse cultures and customs of Asia have given birth to a variety of distinctive regional civilizations over its thousands-year-long history.
They mainly include the Mesopotamian civilization in Western Asia, the Indian civilization in South Asia, the Umran civilization in Central Asia, and the Chinese civilization in East Asia.
North America
The complex natural and geographical environment and diverse cultures and customs of Asia have given birth to a variety of distinctive regional civilizations over its thousands-year-long history.
South America
The complex natural and geographical environment and diverse cultures and customs of Asia have given birth to a variety of distinctive regional civilizations over its thousands-year-long history.


Non-GLSL types that are used to define precision-based types. More...
Typedefs | |
| typedef highp_float_t | highp_float |
| typedef detail::highp_int_t | highp_int |
| typedef detail::tvec2< highp_int > | highp_ivec2 |
| typedef detail::tvec3< highp_int > | highp_ivec3 |
| typedef detail::tvec4< highp_int > | highp_ivec4 |
| typedef detail::tmat2x2 < highp_float > | highp_mat2 |
| typedef detail::tmat2x2 < highp_float > | highp_mat2x2 |
| typedef detail::tmat2x3 < highp_float > | highp_mat2x3 |
| typedef detail::tmat3x3 < highp_float > | highp_mat3 |
| typedef detail::tmat3x3 < highp_float > | highp_mat3x3 |
| typedef detail::tmat4x4 < highp_float > | highp_mat4 |
| typedef detail::tmat4x2 < highp_float > | highp_mat4x2 |
| typedef detail::tmat4x3 < highp_float > | highp_mat4x3 |
| typedef detail::tmat4x4 < highp_float > | highp_mat4x4 |
| typedef detail::highp_uint_t | highp_uint |
| typedef detail::tvec2< highp_uint > | highp_uvec2 |
| typedef detail::tvec3< highp_uint > | highp_uvec3 |
| typedef detail::tvec4< highp_uint > | highp_uvec4 |
| typedef detail::tvec2 < highp_float > | highp_vec2 |
| typedef detail::tvec3 < highp_float > | highp_vec3 |
| typedef detail::tvec4 < highp_float > | highp_vec4 |
| typedef lowp_float_t | lowp_float |
| typedef detail::lowp_int_t | lowp_int |
| typedef detail::tvec2< lowp_int > | lowp_ivec2 |
| typedef detail::tvec3< lowp_int > | lowp_ivec3 |
| typedef detail::tvec4< lowp_int > | lowp_ivec4 |
| typedef detail::tmat2x2 < lowp_float > | lowp_mat2 |
| typedef detail::tmat2x2 < lowp_float > | lowp_mat2x2 |
| typedef detail::tmat2x3 < lowp_float > | lowp_mat2x3 |
| typedef detail::tmat3x3 < lowp_float > | lowp_mat3 |
| typedef detail::tmat3x3 < lowp_float > | lowp_mat3x3 |
| typedef detail::tmat4x4 < lowp_float > | lowp_mat4 |
| typedef detail::tmat4x2 < lowp_float > | lowp_mat4x2 |
| typedef detail::tmat4x3 < lowp_float > | lowp_mat4x3 |
| typedef detail::tmat4x4 < lowp_float > | lowp_mat4x4 |
| typedef detail::lowp_uint_t | lowp_uint |
| typedef detail::tvec2< lowp_uint > | lowp_uvec2 |
| typedef detail::tvec3< lowp_uint > | lowp_uvec3 |
| typedef detail::tvec4< lowp_uint > | lowp_uvec4 |
| typedef detail::tvec2< lowp_float > | lowp_vec2 |
| typedef detail::tvec3< lowp_float > | lowp_vec3 |
| typedef detail::tvec4< lowp_float > | lowp_vec4 |
| typedef mediump_float_t | mediump_float |
| typedef detail::mediump_int_t | mediump_int |
| typedef detail::tvec2 < mediump_int > | mediump_ivec2 |
| typedef detail::tvec3 < mediump_int > | mediump_ivec3 |
| typedef detail::tvec4 < mediump_int > | mediump_ivec4 |
| typedef detail::tmat2x2 < mediump_float > | mediump_mat2 |
| typedef detail::tmat2x2 < mediump_float > | mediump_mat2x2 |
| typedef detail::tmat2x3 < mediump_float > | mediump_mat2x3 |
| typedef detail::tmat3x3 < mediump_float > | mediump_mat3 |
| typedef detail::tmat3x3 < mediump_float > | mediump_mat3x3 |
| typedef detail::tmat4x4 < mediump_float > | mediump_mat4 |
| typedef detail::tmat4x2 < mediump_float > | mediump_mat4x2 |
| typedef detail::tmat4x3 < mediump_float > | mediump_mat4x3 |
| typedef detail::tmat4x4 < mediump_float > | mediump_mat4x4 |
| typedef detail::mediump_uint_t | mediump_uint |
| typedef detail::tvec2 < mediump_uint > | mediump_uvec2 |
| typedef detail::tvec3 < mediump_uint > | mediump_uvec3 |
| typedef detail::tvec4 < mediump_uint > | mediump_uvec4 |
| typedef detail::tvec2 < mediump_float > | mediump_vec2 |
| typedef detail::tvec3 < mediump_float > | mediump_vec3 |
| typedef detail::tvec4 < mediump_float > | mediump_vec4 |
Non-GLSL types that are used to define precision-based types.
The GLSL language allows the user to define the precision of a particular variable. In OpenGL's GLSL, these precision qualifiers have no effect; they are there for compatibility with OpenGL ES's precision qualifiers, where they do have an effect.
C++ has no language equivalent to precision qualifiers. So GLM provides the next-best thing: a number of typedefs of the Template types that use a particular precision.
None of these types make any guarantees about the actual precision used.
| typedef highp_float_t highp_float |
High precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification
Definition at line 70 of file type_float.hpp.
| typedef detail::highp_int_t highp_int |
High precision signed integer.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification.
Definition at line 75 of file type_int.hpp.
| typedef detail::tvec2<highp_int> highp_ivec2 |
2 components vector of high precision signed integer numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.5 Precision Qualifiers.
Definition at line 237 of file type_vec2.hpp.
| typedef detail::tvec3<highp_int> highp_ivec3 |
3 components vector of high precision signed integer numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.5 Precision Qualifiers.
Definition at line 243 of file type_vec3.hpp.
| typedef detail::tvec4<highp_int> highp_ivec4 |
4 components vector of high precision signed integer numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.5 Precision Qualifiers.
Definition at line 256 of file type_vec4.hpp.
| typedef detail::tmat2x2<highp_float> highp_mat2 |
2 columns of 2 components matrix of high precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers
Definition at line 268 of file type_mat2x2.hpp.
| typedef detail::tmat2x2<highp_float> highp_mat2x2 |
2 columns of 2 components matrix of high precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers
Definition at line 286 of file type_mat2x2.hpp.
| typedef detail::tmat2x3<highp_float> highp_mat2x3 |
2 columns of 3 components matrix of high precision floating-point numbers.
There is no guarantee on the actual precision. (From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers)
Definition at line 234 of file type_mat2x3.hpp.
| typedef detail::tmat3x3<highp_float> highp_mat3 |
3 columns of 3 components matrix of high precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers
Definition at line 270 of file type_mat3x3.hpp.
| typedef detail::tmat3x3<highp_float> highp_mat3x3 |
3 columns of 3 components matrix of high precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers
Definition at line 288 of file type_mat3x3.hpp.
| typedef detail::tmat4x4<highp_float> highp_mat4 |
4 columns of 4 components matrix of high precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers
Definition at line 273 of file type_mat4x4.hpp.
| typedef detail::tmat4x2<highp_float> highp_mat4x2 |
4 columns of 2 components matrix of high precision floating-point numbers.
There is no guarantee on the actual precision. (From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers)
Definition at line 247 of file type_mat4x2.hpp.
| typedef detail::tmat4x3<highp_float> highp_mat4x3 |
4 columns of 3 components matrix of high precision floating-point numbers.
There is no guarantee on the actual precision. (From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers)
Definition at line 245 of file type_mat4x3.hpp.
| typedef detail::tmat4x4<highp_float> highp_mat4x4 |
4 columns of 4 components matrix of high precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers
Definition at line 291 of file type_mat4x4.hpp.
| typedef detail::highp_uint_t highp_uint |
High precision unsigned integer.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification.
Definition at line 93 of file type_int.hpp.
| typedef detail::tvec2<highp_uint> highp_uvec2 |
2 components vector of high precision unsigned integer numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.5 Precision Qualifiers.
Definition at line 255 of file type_vec2.hpp.
| typedef detail::tvec3<highp_uint> highp_uvec3 |
3 components vector of high precision unsigned integer numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.5 Precision Qualifiers.
Definition at line 261 of file type_vec3.hpp.
| typedef detail::tvec4<highp_uint> highp_uvec4 |
4 components vector of high precision unsigned integer numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.5 Precision Qualifiers.
Definition at line 274 of file type_vec4.hpp.
| typedef detail::tvec2<highp_float> highp_vec2 |
2 components vector of high precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.5.2 Precision Qualifiers.
Definition at line 219 of file type_vec2.hpp.
| typedef detail::tvec3<highp_float> highp_vec3 |
3 components vector of high precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.5.2 Precision Qualifiers.
Definition at line 225 of file type_vec3.hpp.
| typedef detail::tvec4<highp_float> highp_vec4 |
4 components vector of high precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.5.2 Precision Qualifiers.
Definition at line 238 of file type_vec4.hpp.
| typedef lowp_float_t lowp_float |
Low precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification
Definition at line 58 of file type_float.hpp.
| typedef detail::lowp_int_t lowp_int |
Low precision signed integer.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification.
Definition at line 63 of file type_int.hpp.
| typedef detail::tvec2<lowp_int> lowp_ivec2 |
2 components vector of low precision signed integer numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.5 Precision Qualifiers.
Definition at line 249 of file type_vec2.hpp.
| typedef detail::tvec3<lowp_int> lowp_ivec3 |
3 components vector of low precision signed integer numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.5 Precision Qualifiers.
Definition at line 255 of file type_vec3.hpp.
| typedef detail::tvec4<lowp_int> lowp_ivec4 |
4 components vector of low precision signed integer numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.5 Precision Qualifiers.
Definition at line 268 of file type_vec4.hpp.
| typedef detail::tmat2x2<lowp_float> lowp_mat2 |
2 columns of 2 components matrix of low precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers
Definition at line 256 of file type_mat2x2.hpp.
| typedef detail::tmat2x2<lowp_float> lowp_mat2x2 |
2 columns of 2 components matrix of low precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers
Definition at line 274 of file type_mat2x2.hpp.
| typedef detail::tmat2x3<lowp_float> lowp_mat2x3 |
2 columns of 3 components matrix of low precision floating-point numbers.
There is no guarantee on the actual precision. (From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers)
Definition at line 222 of file type_mat2x3.hpp.
| typedef detail::tmat3x3<lowp_float> lowp_mat3 |
3 columns of 3 components matrix of low precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers
Definition at line 260 of file type_mat3x3.hpp.
| typedef detail::tmat3x3<lowp_float> lowp_mat3x3 |
3 columns of 3 components matrix of low precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers
Definition at line 276 of file type_mat3x3.hpp.
| typedef detail::tmat4x4<lowp_float> lowp_mat4 |
4 columns of 4 components matrix of low precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers
Definition at line 261 of file type_mat4x4.hpp.
| typedef detail::tmat4x2<lowp_float> lowp_mat4x2 |
4 columns of 2 components matrix of low precision floating-point numbers.
There is no guarantee on the actual precision. (From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers)
Definition at line 235 of file type_mat4x2.hpp.
| typedef detail::tmat4x3<lowp_float> lowp_mat4x3 |
4 columns of 3 components matrix of low precision floating-point numbers.
There is no guarantee on the actual precision. (From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers)
Definition at line 233 of file type_mat4x3.hpp.
| typedef detail::tmat4x4<lowp_float> lowp_mat4x4 |
4 columns of 4 components matrix of low precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers
Definition at line 279 of file type_mat4x4.hpp.
| typedef detail::lowp_uint_t lowp_uint |
Low precision unsigned integer.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification.
Definition at line 81 of file type_int.hpp.
| typedef detail::tvec2<lowp_uint> lowp_uvec2 |
2 components vector of low precision unsigned integer numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.5 Precision Qualifiers.
Definition at line 267 of file type_vec2.hpp.
| typedef detail::tvec3<lowp_uint> lowp_uvec3 |
3 components vector of low precision unsigned integer numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.5 Precision Qualifiers.
Definition at line 273 of file type_vec3.hpp.
| typedef detail::tvec4<lowp_uint> lowp_uvec4 |
4 components vector of low precision unsigned integer numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.5 Precision Qualifiers.
Definition at line 286 of file type_vec4.hpp.
| typedef detail::tvec2<lowp_float> lowp_vec2 |
2 components vector of low precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.5.2 Precision Qualifiers.
Definition at line 231 of file type_vec2.hpp.
| typedef detail::tvec3<lowp_float> lowp_vec3 |
3 components vector of low precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.5.2 Precision Qualifiers.
Definition at line 237 of file type_vec3.hpp.
| typedef detail::tvec4<lowp_float> lowp_vec4 |
4 components vector of low precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.5.2 Precision Qualifiers.
Definition at line 250 of file type_vec4.hpp.
| typedef mediump_float_t mediump_float |
Medium precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification
Definition at line 64 of file type_float.hpp.
| typedef detail::mediump_int_t mediump_int |
Medium precision signed integer.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification.
Definition at line 69 of file type_int.hpp.
| typedef detail::tvec2<mediump_int> mediump_ivec2 |
2 components vector of medium precision signed integer numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.5 Precision Qualifiers.
Definition at line 243 of file type_vec2.hpp.
| typedef detail::tvec3<mediump_int> mediump_ivec3 |
3 components vector of medium precision signed integer numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.5 Precision Qualifiers.
Definition at line 249 of file type_vec3.hpp.
| typedef detail::tvec4<mediump_int> mediump_ivec4 |
4 components vector of medium precision signed integer numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.5 Precision Qualifiers.
Definition at line 262 of file type_vec4.hpp.
| typedef detail::tmat2x2<mediump_float> mediump_mat2 |
2 columns of 2 components matrix of medium precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers
Definition at line 262 of file type_mat2x2.hpp.
| typedef detail::tmat2x2<mediump_float> mediump_mat2x2 |
2 columns of 2 components matrix of medium precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers
Definition at line 280 of file type_mat2x2.hpp.
| typedef detail::tmat2x3<mediump_float> mediump_mat2x3 |
2 columns of 3 components matrix of medium precision floating-point numbers.
There is no guarantee on the actual precision. (From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers)
Definition at line 228 of file type_mat2x3.hpp.
| typedef detail::tmat3x3<mediump_float> mediump_mat3 |
3 columns of 3 components matrix of medium precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers
Definition at line 265 of file type_mat3x3.hpp.
| typedef detail::tmat3x3<mediump_float> mediump_mat3x3 |
3 columns of 3 components matrix of medium precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers
Definition at line 282 of file type_mat3x3.hpp.
| typedef detail::tmat4x4<mediump_float> mediump_mat4 |
4 columns of 4 components matrix of medium precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers
Definition at line 267 of file type_mat4x4.hpp.
| typedef detail::tmat4x2<mediump_float> mediump_mat4x2 |
4 columns of 2 components matrix of medium precision floating-point numbers.
There is no guarantee on the actual precision. (From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers)
Definition at line 241 of file type_mat4x2.hpp.
| typedef detail::tmat4x3<mediump_float> mediump_mat4x3 |
4 columns of 3 components matrix of medium precision floating-point numbers.
There is no guarantee on the actual precision. (From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers)
Definition at line 239 of file type_mat4x3.hpp.
| typedef detail::tmat4x4<mediump_float> mediump_mat4x4 |
4 columns of 4 components matrix of medium precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.6 Matrices and section 4.5 Precision and Precision Qualifiers
Definition at line 285 of file type_mat4x4.hpp.
| typedef detail::mediump_uint_t mediump_uint |
Medium precision unsigned integer.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification.
Definition at line 87 of file type_int.hpp.
| typedef detail::tvec2<mediump_uint> mediump_uvec2 |
2 components vector of medium precision unsigned integer numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.5 Precision Qualifiers.
Definition at line 261 of file type_vec2.hpp.
| typedef detail::tvec3<mediump_uint> mediump_uvec3 |
3 components vector of medium precision unsigned integer numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.5 Precision Qualifiers.
Definition at line 267 of file type_vec3.hpp.
| typedef detail::tvec4<mediump_uint> mediump_uvec4 |
4 components vector of medium precision unsigned integer numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.1.5 Precision Qualifiers.
Definition at line 280 of file type_vec4.hpp.
| typedef detail::tvec2<mediump_float> mediump_vec2 |
2 components vector of medium precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.5.2 Precision Qualifiers.
Definition at line 225 of file type_vec2.hpp.
| typedef detail::tvec3<mediump_float> mediump_vec3 |
3 components vector of medium precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.5.2 Precision Qualifiers.
Definition at line 231 of file type_vec3.hpp.
| typedef detail::tvec4<mediump_float> mediump_vec4 |
4 components vector of medium precision floating-point numbers.
There is no guarantee on the actual precision. From GLSL 1.30.8 specification, section 4.5.2 Precision Qualifiers.
Definition at line 244 of file type_vec4.hpp.


Beardy
Brews
Beer For Your Beard
Our Story
Beers
Contact
Our Beers
Let our Brown Ale traverse your tastes buds
Our IPA has enough hops to take you into Orbit
Look slick with our Lager in your hand
Our Pilsner is in a whole other class
The Ruby Red Ale is a colorful display
The Stout will take you to new heights


PSPE Laboratory Safety Manual
Emergency Contact Information
TTU Police (UPD)
| Emergency |
9-911 |
| Non-Emergency |
742-3931 |
TTU Environmental Health and Safety (EH&S)
| Daytime Emergencies (M-F, 8:00 AM – 5:00 PM) |
742-2876 |
| Non-Daytime Emergencies (24 hrs/day, 7 days/week) |
742-3328 |
After Emergency Is Reported, Contact:
| Responsible Principle Investigator |
Richard Gale |
| Office Number: |
ECE 236 |
| Primary: |
(806) 535-9576 |
| Office Phone: |
(806) 834-0007 |
| Email: |
<EMAIL_ADDRESS>|
| Department Safety Officer |
Richard Woodcock |
| Office Number: |
ECE 02 |
| Primary: |
(806) 834-3095 |
| Office Phone: |
(806) 470-9290 |
| Email: |
<EMAIL_ADDRESS>|
| Lab Manager |
Kenyan Burnham |
| Primary: |
(806) 319-2773 |
| Email: |
<EMAIL_ADDRESS>|
Emergency Response Equipment Location
PSPE Lab 252
- If there is an emergency or threat, leave the laboratory immediately and call 911.
- Each Department has a DOSMA (Designated Outside Safe Meeting Area). This area is designed to remove individuals from any present danger from any emergency.
For the Department of Electrical and Computer Engineering the DOSMA's are:
- East of the building on the Engineering Key.
- The far West end of the parking lot located near the Linda and Terry Fuller Track and Field Complex.
- And South of the building on the open arcade.
General Emergency Guidance
- If there is an emergency or threat, leave the laboratory immediately and call 911.
- Each Department has a DOSMA (Designated Outside Safe Meeting Area). This area is designed to remove individuals from any present danger from any emergency.
Medical Emergency Guidance
First aid treatment for the potential hazards of equipment in lab 252 that may cause bodily injury or chemical exposure should be known and employed in any medical emergency.
Always call 911 when a medical emergency occurs.
| Situation |
Response |
| Minor Injury |
- Seek to contain and seal the wound using wraps and bandages located in the medical kit.
|
| Vapor Exposure |
- Leave area and go outside for fresh air.
- Symptoms of any degree warrant calling 911.
- If unsure of a suitable response to a specific agent call EH&S.
|
| Exposure to Liquid Chemical Agent |
- Follow instructions laid out in MSDS (if available).
- Any present symptoms warrant calling 911.
- If unsure of a suitable response to a specific agent call EH&S.
|
| Machine Injury |
- TURN OFF THE MACHINE in every instance.
- Reduce blood loss by immediately beginning to wrapping area in absorbent and containing material that may be found in the medical kit.
- If a member is separated do not try and reattach the severed member.
- Immediately seek medical emergency assistance.
|
Fire Emergency Guidance
Even if one strongly suspects the alarm may be false, Texas Tech and the Fire Department of Lubbock assume every event is in fact real.
If the building fire alarm sounds:
- Follow all emergency shut down procedures for your experiment.
- Exit the building through the nearest exit.
In the event that a fire is detected or suspected:
- All occupants of the building should evacuate immediately.
- If the alarm has not been sounded, the nearest fire alarm pull station should be activated.
In all cases immediately proceed to the Designated Outside Meeting Area (DOSMA).
- The DOSMA for lab 252 and the 253 workspace is to the West adjacent to the Linda and Terry Fuller Track and Field Complex located behind the Electrical and Computer Engineering building.
Situational Fire Responses:
| Situation |
Response |
| Caught in smoke |
- Drop to hands and knees and crawl towards nearest exit.
- Hold breath as much as possible; breathe through your nose and use shirt or cloth as a filter.
|
| Trapped in a room. |
- Close as many doors as possible in between you and the fire.
- Wet and place cloth material around or under the door to help prevent smoke from entering the room.
|
| Clothing on fire. |
- Direct or assist a person to roll around on the floor to smother the flames.
- Only drench with water if safety shower is nearby.
|
Electrocution Emergency Guidance
The following steps are to be followed in the event of an electrocution emergency:
| Step |
Response |
| Approach |
- Call emergency responders as soon as possible.
- If a coworker trained in electrical emergency protocols is nearby, marshal their assistance immediately.
- The approach to where a coworker has succumbed to electrical shock should be made cautiously to help ensure the current that incapacitated the victim does not harm you.
|
| Examine |
- A quick look at the scene will reveal whether the victim remains in contact with the object inducing the electrical shock.
- Avoid nearby conductors and do not touch the victim until the electrical circuit that powers the area is de-energized.
|
| De-Energize |
- If the only source of power to the victim's locale is a power cord to portable equipment, simply disconnect it at the power source.
- However, using an emergency stop button is also recommended.
- For information regarding the safety switched located in 252/253 see the Emergency Response Equipment Location procedure
|
| Insulate |
- In the event that de-energization is impossible, the victim will need to be removed from the electrical source using an insulated material to move the victim without endangering the emergency respondent.
- DO NOT USE WOOD BROOM HANDLES to remove victims. They have a conductive finish and will only endanger emergency respondents.
|
| Rescue |
- Do not touch electrocuted victims unless actively standing on an insulated material with the power source disconnected.
- If there is a risk of neck injury or contingency do not remove the victim at all. Ensure the victim's airway is unobstructed, check pulse, and perform CPR if necessary.
- Use of an Automated Emergency Defibrillator (AED) is preferred. You should not hesitate to use the AED even if you believe doing so might make the neck injury worse.
|
Active Shooter Emergency Guidance
If you witness an armed individual on campus at any time or if an individual is acting in a hostile or belligerent manner, immediately contact the Texas Tech Police at 9-911 on a university phone or 911 on mobile devices.
The following are guidelines for situations involving an active shooter:
| Situation |
Response |
| Armed subject outside building. |
- Turn off the lights. Close and lock all doors and windows.
- If you can do so safely, move out of the line of fire.
- Move to a core area of the building if it is safe to do so and remain there until the "all clear" instruction is given by the Texas Tech Police Department or a university authority.
- If you doubt the authenticity or identity of the authority that is giving you instruction do not change your status.
|
| Armed subject inside building. |
- If at all possible to flee the area safely and avoid danger, do so.
- Contact the TTU Police Department immediately at 743-2000 or 9-911 with you location, if possible.
- If flight is impossible, lock all doors and secure yourself in your space.
- Get down on the floor or under a desk and remain silent.
- Get out of the line of fire.
- Wait for the "all clear" signal from the TTU Police Department.
|
| Armed subject in workspace. |
- There is no procedure authorities can recommend in this situation. Do anything necessary to protect yourself.
- Attempt to get the word out to others if possible, and call 743-2000 or 9-911 if practical and possible.
- Use common sense. If hiding or fleeing is impossible, attempt to negotiate with the individual.
- Attempting to overcome and armed subject with force is a last resort and should only be initiated in the most extreme of circumstances.
|
Tornado Emergency Guidance
If a tornado warning is officially issued in Lubbock County the Backup Emergency Manager, Richard Woodcock, will immediately advise building occupants to take shelter.
The preferred location for shelter is in the Electrical and Computer Engineering basement rooms 02 and 06.
The need to shelter in the event of a tornadic storm threatening TTU may be received from one or more of the following sources.
- The TTU Alert Emergency Notification System
- NOAA Weather Station(The Specific Area Message Encoder, "SAME")
Guidance Statement
This laboratory safety manual supplements the University Chemical Hygiene Plan. It is designed to emphasize key elements of the University Chemical Hygiene Plan that are important to this laboratory and workspace, and to detail specific and additional safety requirements unique to the activities of this space.
- This document was prepared by and is curated by the current Lab Safety Captain.
- It is the ultimate responsibility of the Principle Investigator to ensure the availability of the manual to all laboratory personnel and regulatory bodies.
- All laboratory and workplace personnel are responsible for following the regulations and recommendations of the University Chemical Hygiene Plan and Laboratory Safety Manual.
In addition, the Laboratory Safety Manual will be a living document that all workplace and laboratory personnel are encouraged to update and modify in order to create a safe and productive workplace.
Minimum Training Required
As stated by EH&S and the TTU Chemical Hygiene Plan all students, faculty, and staff are REQUIRED to complete the online training on the EH&S website:
EH&S Website.
Locations Covered by This Manual
- ECE Room 253
- ECE Laboratory 252
Required training:
- Laboratory Safety Training
- Hazard Communication Training
- Safety Awareness Training
- Electrical Safety Work Practices and Standards Training
Completed certificates must be received and curated by the Laboratory Safety Captain in digital form.
Completed course certificates may be sent to<EMAIL_ADDRESS>Not completing the training necessary will lead to immediate removal from the facility.
Identification of Potential Hazards
The following are potential hazards with specific examples, locations of the possible hazard, resources for response and mitigation, and source references.
| Hazard |
Example |
Location |
Mitigation |
References |
| High Voltage |
Greater than 50 Volts |
Throughout laboratory 252 |
Procedures |
|
| Burns |
Greater than 600 degrees Fahrenheit |
Throughout laboratory 252 |
Procedures and PPE |
|
| Physical |
Hand Drills |
Throughout laboratory 252 |
Procedures and PPE |
|
Location of Laboratory/Workspace Documents
The following are all documents required by the Texas Tech University Chemical Hygiene Plan and where they may be found in Laboratory 252.
| Document |
Location |
| MSDS |
N/A No chemicals are used in this lab. |
| Chemical Inventory |
N/A No chemicals are used in this lab. |
| University Chemical Hygiene Plan |
Located in Safety Equipment cabinet |
| Laboratory Safety Manual |
Located in Safety Equipment cabinet |
| Training Records |
Digital copies stored on PSPE file server. Individual records given upon request. |
Minimum PPE required
The following is a list of minimum personal protective equipment requirements for lab personnel:
- Long pants.
- Closed-toed shoes.
- Safety glasses while operating soldering stations.
Responsible Personnel
Current Responsible Parties are identified in Emergency Contact Info.
| Role |
Responsible Party |
Responsibilities |
| User |
All Laboratory Personnel |
- Are responsible for ensuring their own personal safety.
- The safety of others around them.
- And for reading and understanding the Chemical Hygiene Plan and this Laboratory Safety Manual.
|
| Principle Investigator or Workplace Supervisor |
Richard Gale |
- Ultimately responsible for all activities in the workspace and laboratory.
|
| Laboratory Safety Captain |
Kenyan Burnham |
- Acts as a liaison between the Department Safety Officer and the Principle Investigator or Workplace Supervisor.
- Is responsible for the ongoing improving of safety measures and enforcing of safety culture.
- Implements and updates laboratory safety policies and documentation.
|
| Department Safety Officer |
Richard Woodcock |
- Is the liaison between the Laboratory Safety Captains and EH&S.
- Provides guidance on safety-related issues and ensures compliance with the Chemical Hygiene Plan.
|
In addition, Section 5 of University Chemical Hygiene Plan Responsibilities and Roles of Individuals details the expectations and responsibilities of all parties.
General Safety Requirements
The following are general guidelines and expectations of laboratory and workplace personnel.
All Personnel
- Must have completed the proper training before they are permitted into the lab space.
- Will not allow access to non-permitted personnel.
- Will adhere to the guidelines specified or they will be subject to immediate removal from the space.
- Will wear appropriate personal protective equipment when any hazard is present.
- Safety glasses are required when using any soldering station or portable and stationary power tool.
- Will not bring consumables such as food, beverage, cosmetics, tobacco, or gum. Unless otherwise permitted by the Principal Investigator for research purposes only.
- Will keep the door to the laboratory shut at all times.
- Will not wear headphones when working with tools or equipment in the lab.
- When performing research or work in the lab after normal day-time operating hours will ensure a second individual is present or near in case of an emergency.
- Working individually is considered dangerous during night-time hours and it is the safety culture of the PSPE program to always have someone accountable for you in case of an emergency.
- Will ensure their behavior does not lead to the destruction or defacement of Texas Tech University property. Individuals suspected or apprehended will immediately be removed from the area.
- Will ensure no property of Texas tech University is removed from the laboratory without the written permission of the Laboratory Safety Captain or Principal Investigator.
- Will not bring foreign chemicals or flammables into the lab without the express permission of the Principal Investigator or Laboratory Safety captain.
- Will be responsible for maintaining the culture of good laboratory housekeeping on an ongoing basis.
The Laboratory Safety captain, Principal Investigator, and Department Chemical Hygiene Officer
- Have explicit right to remove any individual.
- Can take photographic evidence of any action not in compliance to the safety guidelines.
Facility Safety Requirements
The following are the general guidelines any Texas Tech facility must follow:
- Housekeeping will be maintained on an ongoing basis.
- Solvents or other chemicals that volatize must be worked with under a fume hood.
- All storage containers should be labeled with required information, segregating by their hazard class, stored in the appropriate manner, and removed by Waste Management
- Large or heavy items are to be stored as close to the ground level as possible to make them easier to move and prevent them from falling.
- Exits, Emergency eyewash and safety showers, aisles, and walkways must be completely unobstructed.
- Trip hazards must be removed or mitigated.
- Sharps in the laboratory need to be secured when not in use.
- Overhead storage must be at least 18" lower than the fire sprinkler head.
- When working with energetic or potentially energetic materials, a blast shield must be in place.
- The laboratory shall be designed so that it can be easily cleaned.
- Carpets and rugs shall not be placed in the laboratory.
- Laboratory furniture will be routinely cleaned.
- Bench tops will be impervious to water and resistant to heat, organic solvents, acids, alkalis, soldering equipment, and other chemicals.
- Chairs in the laboratory should be covered in non-porous material.
- Doors shall have a locking mechanism so that it can be secured when there are no laboratory personnel present.
- Physical and electrical hazard signs must be clearly posted on all the doors entering the laboratory so that any individual can see the sign prior to entering the laboratory space.
- The Texas Tech Chemical Hygiene plan dictates that laboratories must be furnished and or be located near sinks or portable sinks for hand washing.
- Signs should be posted for all safety concerns throughout the workspace, laboratory, and entrances.
Incident Reporting Procedure
The following are the guidelines for individuals when a Near Miss or Accident occurs.
When a Near Miss or Accident Occurs
- An Incident Report Form found in the Texas Tech University Chemical Hygiene Plan must be filled out and submitted to the Principal Investigator.
- The Principal Investigator must turn in the Incident Report Form to the Department Chemical Hygiene Officer.
The following are the generalized standard operating procedures for working with the equipment in the laboratory.
General Equipment Requirements
The following safety practices are required in addition to the general lab safety requirements.
- Power sources that are improvised or not factory standard should not be used.
- When working with voltages over 40V and current over 10A another person must be present.
- One should always know the ratings of the device under test and should make adjustments before applying voltage to a device.
- Exploding components (especially electrolytic capacitors) and arcing circuits can cause blindness and severe burns.
- Components that arc can cause fires and should be avoided.
- A emergency stop switch should be included in any power supplied circuit so that when opened, the switch will de-energize the entire setup. Place these switches so that you can reach them quickly in case of emergency, and without reaching across hot or high voltage components.
- Always turn off equipment when you exit the laboratory.
- Never leave any device unattended running.
Function Generator
This equipment has the following hazards:
The following safety practices are required in addition to the general lab safety requirements.
- Do not operate this instrument in the presence of flammable gases or fumes. Operation of an electrical instrument in such an environment constitutes a definite safety risk.
- Disconnect the power cord before removing the instrument covers when replacing components. Under certain conditions, even when if the power cable is removed, dangerous voltages may exist. To avoid injuries, always disconnect the power and discharge circuits before handling or adjusting.
- Wear safety glasses when working with a circuit at high power or high voltage.
- Use rubber floor mats (if available) to insulate yourself from ground, when working in the lab.
- Make sure connections to terminals are secured properly.
Oscilloscope
This equipment has the following hazards:
The following safety practices are required in addition to the general lab safety requirements.
- Use only isolated power sources (either isolated power supplies or AC power through isolated power transformers). This reduces possible risk by grounding the oscilloscope to a factory tested and approved source.
- Wear safety glasses when working with a circuit at high power or high voltage.
- Use rubber floor mats (if available) to insulate yourself from ground, when working in the lab.
Power Supply
This equipment has the following hazards:
The following safety practices are required in addition to the general lab safety requirements.
- Do not operate this instrument in the presence of flammable gases or fumes. Operation of an electrical instrument in such an environment constitutes a definite safety risk.
- Disconnect the power cord before removing the instrument covers when replacing components. Under certain conditions, even when if the power cable is removed, dangerous voltages may exist. To avoid injuries, always disconnect the power and discharge circuits before handling or adjusting.
- Wear safety glasses when working with a circuit at high power or high voltage.
- Use rubber floor mats (if available) to insulate yourself from ground, when working in the lab.
- Do not exceed the limits of the device you are testing.
- Make sure connections to terminals are secured properly.
- Make sure the voltage adjustment knob is zeroed before operating.
- Never modify a connection when the power supply is operating.
Soldering Station
This equipment has the following hazards:
- Burn Hazard
- Potential Lead Poisoning (PPE NEEDED: Safety Glasses)
The following safety practices are required in addition to the general lab safety requirements.
- Do not operate this instrument in the presence of flammable gases or fumes. Operation of an electrical instrument in such an environment constitutes a definite safety risk.
- Turn the soldering iron off when not in use. Leaving a hot iron can prevent a risk to peers and can damage the tip if it has not been correctly tinned.
- Always solder in a ventilated area and avoid inhaling.
- Lead-based solder can pose a lead poisoning risk. Always remember to wash hands thoroughly when finished.
- Eye protection should always be worn when working with soldering stations.
- Always place iron or pencil in holder when not in use. Do not place a hot or cold pencil on any surface.
- Solder over the bench top to prevent hot solder from dropping on to the operator's legs.
Hand Drill
This equipment has the following hazards:
- High Speed Rotating Equipment (PPE Needed: Safety Glasses or Side Shields)
The following safety practices are required in addition to the general lab safety requirements.
- Always know the properties of the material to be drilled. The density, thickness of sheet, and porousness of the material can effect the performance of the drill and the bit needed for the job.
- All work should be secured to the table when drilling. In general, if the drill is capable of spinning the material towards the operator it should be secured.
- When drilling on a bench be sure the drill bit will not drill into the table surface. This can be avoided by securing a scrap piece of material underneath the material to be drilled or by ensuring the drilled hole will be off the table.
- Make adjustments and change the drill bits only when the drill safety is on, or if it is a corded drill, with the cord unplugged.
- Battery powered drills have limited current, and limited torque. Corded drills have an almost unlimited current, and thus have more torque.
- When drilling with a corded drill; use caution and accelerate the drill slowly. It has the ability to injury your wrist if the flute of the drill becomes stuck.
- If a drill begins to twist your hand release the trigger and remove your hand to avoid injury.
- When drilling with a cordless drill be careful not to overheat the drill and be sure to place the battery on it's charger when finished.
- The proper way to hold and drill is with the trigger hand connected to the trigger and your other hand on the back base of the drill to guide and provide steady pressure to the surface of the material being drilled.
- Do not attempt to make a smaller hole larger by wallowing it out, this damages the flute of the bit and will likely cause wrist and hand injury when the material catches the flute and twists the drill from the operator's hands.
- When drilling deep holes withdraw the bit several times to clear the drilled area of debris inside the hole.
- When using any rotating apparatus; hair, loose-clothing, and jewelry should be removed before operating.
- As with any machine if you are unsure how to use it in a safe way ask for help.
Source Meter
This equipment has the following hazards:
The following safety practices are required in addition to the general lab safety requirements.
- Do not operate this instrument in the presence of flammable gases or fumes. Operation of an electrical instrument in such an environment constitutes a definite safety risk.
- Disconnect the power cord before removing the instrument covers when replacing components. Under certain conditions, even when if the power cable is removed, dangerous voltages may exist. To avoid injuries, always disconnect the power and discharge circuits before handling or adjusting.
- Wear safety glasses when working with a circuit at high power or high voltage.
- Use rubber floor mats (if available) to insulate yourself from ground, when working in the lab.
- Do not exceed the limits of the device you are testing.
- Make sure connections to terminals are secured properly.
- Make sure the voltage adjustment knob is zeroed before operating.
- Never modify a connection when the device is operating.
DC Electronic Load
This equipment has the following hazards:
The following safety practices are required in addition to the general lab safety requirements.
- Do not operate this instrument in the presence of flammable gases or fumes. Operation of an electrical instrument in such an environment constitutes a definite safety risk.
- Disconnect the power cord before removing the instrument covers when replacing components. Under certain conditions, even when if the power cable is removed, dangerous voltages may exist. To avoid injuries, always disconnect the power and discharge circuits before handling or adjusting.
- Wear safety glasses when working with a circuit at high power or high voltage.
- Use rubber floor mats (if available) to insulate yourself from ground, when working in the lab.
- Do not exceed the limits of the device you are testing.
- Make sure connections to terminals are secured properly.
- Make sure the voltage adjustment knob is zeroed before operating.
- Never modify a connection when the device is operating.
NI Virtual Bench
This equipment has the following hazards:
The following safety practices are required in addition to the general lab safety requirements.
- Know the operational procedures and guidelines from the documentation of the device.
- Do not operate this instrument in the presence of flammable gases or fumes. Operation of an electrical instrument in such an environment constitutes a definite safety risk.
- Wear safety glasses when working with a circuit at high power or high voltage.
- Use rubber floor mats (if available) to insulate yourself from ground, when working in the lab.
- Do not exceed the limits of the device you are testing.
- Make sure connections to terminals are secured properly.
- Make sure the voltage adjustment knob is zeroed before operating.
- Never modify a connection when the device is operating.
ETS
This equipment has the following hazards:
The following safety practices are required in addition to the general lab safety requirements.
- Know the operational procedures and guidelines from the documentation of the device.
- Wear safety glasses when working with a circuit at high power or high voltage.
- Use rubber floor mats (if available) to insulate yourself from ground, when working in the lab.
- Do not exceed the limits of the device you are testing.
- Make sure connections to terminals are secured properly.
- Make sure the voltage adjustment knob is zeroed before operating.
- Never modify a connection when the device is operating.
STS
This equipment has the following hazards:
The following safety practices are required in addition to the general lab safety requirements.
- Know the operational procedures and guidelines from the documentation of the device.
- Wear safety glasses when working with a circuit at high power or high voltage.
- Use rubber floor mats (if available) to insulate yourself from ground, when working in the lab.
- Do not exceed the limits of the device you are testing.
- Make sure connections to terminals are secured properly.
- Make sure the voltage adjustment knob is zeroed before operating.
- Never modify a connection when the device is operating.


Assignment 1: tags, lists, tables, images, links
Lists
My Favorite Chinese Foods:
- Newdoughs
- Fried Rice
- Chicken Fried Rice
- Yang Zhou Fried Rice, never heard of this mang..
- Cha Siu BAOSSSSSS
Tables
| James | Dastin DaOnion | Miipis | |
|---|---|---|---|
| Birthday | 2/4 | 6/29 | 12/15 |
| Gender | M | M | F |
Images
This image is 400 pixels wide and scaled proportionally to a bananar
KEKDOG


univariate
| Title: | Univariate Linear Regression. |
@author: Bhishan Poudel
@date: Sep 22, 2017
@email<EMAIL_ADDRESS>The cost function is given by
Minimizing the cost function w.r.t. w gives two system of liner equations:
We solve these normal equations and find the values w0 and w1.
-
univariate.
compute_cost
(X, t, w)[source]
Compute objective function on dataset (X, t).
-
univariate.
compute_rmse
(X, t, w)[source]
Compute RMSE on dataset (X, t).
Note: cost function J is 1/2 of mean squared error.
RMSE is square root of mean squared error.
-
univariate.
main
()[source]
Run main function.
-
univariate.
myplot
(fh_train, fh_test, w)[source]
-
univariate.
read_data
(infile)[source]
Read the datafile and return arrays
-
univariate.
train
(X, t)[source]
Implement univariate linear regression to compute w = [w0, w1].
I solve system of linear equations from lecture 01
w0 N + w1 sum_x = sum_t
w0 sum_x + w1 sum_xx = sum_tx
-
univariate.
univariate_reg
(fh_train, fh_test)[source]


My Training Log
Sessions
Log
Progression
Target
Notifications
Logout
Settings
Default View
Units
Week Structure
Welcome to Your Home Page
Here you can see your plan and milestones.
Enjoy!
Switch View
Day View
Week View
Month View
Edit Plan
ID
Full Name
Email
Done
{{member.id}}
{{member.firstName}} {{member.surname}}
{{member.email}}
Add Member
Add Member
First Name
Surname
Username
Email
Password


{% extends "item-base.html" %} {% block description %} I told you, it's name is {{ name }}. It also has the description: {{ desc }}. {% endblock %}