Youth Justice Milwaukee Hosts
Milwaukee, WI – Today, Youth Justice Milwaukee (YJM) held a roundtable meeting with Milwaukee County
representatives, local aldermen, state officials and other elected officials, to discuss next steps after the
closure of Lincoln Hills and Copper Lake youth prisons.


{{ categoryName}}
Bailiff
Enforcement agent, Enforcement officer, High Court enforcement officer
Bailiffs visit properties to collect debts, serve a court document or give a notice or summons.
Forensic scientist
Forensic scientists prepare traces of physical evidence for use in courts of law.
Paralegal
Legal assistant, Property assistant, Contracts assistant
Paralegals carry out research, prepare legal documents and give legal advice to clients.
Probation officer
Probation officers supervise people serving community and prison sentences, and help them to stay away from crime.


Welcome to our experiment
<Here goes the overall description of the experiment, how long does it take, what does it require etc.>


Sensex ends 76 points lower; Nifty below 12K
NSE Nifty closed 30.70 points down.
by PTIMarket benchmark Sensex settled 76 points lower on Thursday, tracking weak cues from global equities as US-China impasse continued to weigh on investor sentiment.
After trading on a choppy note through the day, the 30-share index ended 76.47 points, or 0.19%, lower at 40,575.17. It hit an intra-day low of 40,534.12 and a high of 40,744.85.
Similarly, the broader NSE Nifty closed 30.70 points, or 0.26%, down at 11,968.40.
Tata Steel was the top loser in the Sensex pack, dropping 3.35%, followed by Bharti Airtel down 2.52%, Yes Bank 2.43%, ONGC 1.98% and ITC 1.96%.
On the other hand, HUL gained 1.15%, L&T 0.89%, Bajaj Auto 0.82% and SBI 0.81%.
Elsewhere in Asia, bourses in Shanghai, Hong Kong, Tokyo and Seoul settled in the red amid reports that the US-China trade deal was unlikely to be signed this year.
Further, the US Senate passed legislation supporting Hong Kong protestors, potentially complicating the trade negotiations with China, experts said.
European equities were also trading on a negative note in their respective early deals.
Meanwhile, the Indian rupee appreciated marginally to 71.78 against the US dollar in intra-day trade.
Brent crude futures, the global oil benchmark, fell 0.51% to USD 62.08 per barrel.


{% extends './layouts/default.html' %} {% block title %}{{title}}{% endblock %} {% block content %}
Downloadify plugin
Filename
File Contents Whatever you put in this text box will be downloaded and saved in the file. If you leave it blank, no file will be downloaded
You must have Flash 10 installed to download this file.
FileSaver


An Internal Style Sheet may be used if one single page has a unique style. Internal style are defined within the style element, inside the head section of an HTML page:


Overview
Firebug Lite is not a substitute for Firebug, or Chrome Developer Tools. It is a tool to be used in conjunction with these tools. Firebug Lite provides the rich visual representation we are used to see in Firebug when it comes to HTML elements, DOM elements, and Box Model shading. It provides also some cool features like inspecting HTML elemements with your mouse, and live editing CSS properties.
To get more information about what's new in Firebug Lite 1.3 beta (which is compatible with all major browsers) please visit the beta release page.
Benefits over Firebug Lite bookmarlet
Firebug Lite 1.3.0 beta for Google Chrome is basically the same you'll see when using the bookmarlet. There are, though, some benefits by using the extension for Google Chrome, including:
- Browser toolbar integration, providing an easy way to start debugging your page
- It is possible to activate the Firebug Lite for a particular domain, so next time you visit a page in that domain, it will be automatically active.
- Firebug Lite will be loaded before all other scripts, allowing it to capture all console calls, and all XHR requests for that page
- It is faster to load, because all code and images will be store in the extension's directory in your machine
- Will allow to read external resources
Limitations
The main limitations of the Firebug Lite version are:
- Cannot read external resources
- Won't work well on pages with frames
- JavaScript debugger isn't available
- Net Panel isn't available
Known Issues
The known issues of the Firebug Lite for Google Chrome extension are:
- Fore security reasons, Google Chrome does not execute "content scripts" for some URLs like the Chrome Extentions Gallery. On those pages, Firebug will try to load the bookmarlet version.
- Google Chrome does not execute "content scripts" of popup windows, so when you open Firebug Lite in a new window (popup), the Firebug icon will become gray. This is a bug in Google Chrome, and should be fixed soon by the Chrome dev team.


NUS Money
Good Afternoon User!
Nett Expense
$0.00
Income
+$0.00
Expense
-$0.00
Details
Metamask
Your Public Address:
Connect to Metamask
COT token contract address:
0xcad680287ee517cfae13c6956f035f07294d975d
Your Balance:
COT
Show Token Balance
Add Transaction
Shop Name
Date
Amount
Type of Transaction
Income
Expense
Please fill in all fields!
Submit
Login
User Name
Password
Login
Logout


A user in the server.
More...
Inherited by Nakama.Console.ApiUser.
|
| string | AvatarUrl [get] |
| | A URL for an avatar image.
|
| |
| string | CreateTime [get] |
| | The UNIX time when the user was created.
|
| |
| string | DisplayName [get] |
| | The display name of the user.
|
| |
| int | EdgeCount [get] |
| | Number of related edges to this user.
|
| |
| string | FacebookId [get] |
| | The Facebook id in the user's account.
|
| |
| string | FacebookInstantGameId [get] |
| | The Facebook Instant Game id in the user's account.
|
| |
| string | GamecenterId [get] |
| | The Apple Game Center in of the user's account.
|
| |
| string | GoogleId [get] |
| | The Google id in the user's account.
|
| |
| string | Id [get] |
| | The id of the user's account.
|
| |
| string | LangTag [get] |
| | The language expected to be a tag which follows the BCP-47 spec.
|
| |
| string | Location [get] |
| | The location set by the user.
|
| |
| string | Metadata [get] |
| | Additional information stored as a JSON object.
|
| |
| bool | Online [get] |
| | Indicates whether the user is currently online.
|
| |
| string | SteamId [get] |
| | The Steam id in the user's account.
|
| |
| string | Timezone [get] |
| | The timezone set by the user.
|
| |
| string | UpdateTime [get] |
| | The UNIX time when the user was last updated.
|
| |
| string | Username [get] |
| | The username of the user's account.
|
| |
◆ AvatarUrl
| string Nakama.Console.IApiUser.AvatarUrl |
|
get |
A URL for an avatar image.
◆ CreateTime
| string Nakama.Console.IApiUser.CreateTime |
|
get |
The UNIX time when the user was created.
◆ DisplayName
| string Nakama.Console.IApiUser.DisplayName |
|
get |
The display name of the user.
◆ EdgeCount
| int Nakama.Console.IApiUser.EdgeCount |
|
get |
Number of related edges to this user.
◆ FacebookId
| string Nakama.Console.IApiUser.FacebookId |
|
get |
The Facebook id in the user's account.
◆ FacebookInstantGameId
| string Nakama.Console.IApiUser.FacebookInstantGameId |
|
get |
The Facebook Instant Game id in the user's account.
◆ GamecenterId
| string Nakama.Console.IApiUser.GamecenterId |
|
get |
The Apple Game Center in of the user's account.
◆ GoogleId
| string Nakama.Console.IApiUser.GoogleId |
|
get |
The Google id in the user's account.
◆ Id
| string Nakama.Console.IApiUser.Id |
|
get |
The id of the user's account.
◆ LangTag
| string Nakama.Console.IApiUser.LangTag |
|
get |
The language expected to be a tag which follows the BCP-47 spec.
◆ Location
| string Nakama.Console.IApiUser.Location |
|
get |
The location set by the user.
◆ Metadata
| string Nakama.Console.IApiUser.Metadata |
|
get |
Additional information stored as a JSON object.
◆ Online
| bool Nakama.Console.IApiUser.Online |
|
get |
Indicates whether the user is currently online.
◆ SteamId
| string Nakama.Console.IApiUser.SteamId |
|
get |
The Steam id in the user's account.
◆ Timezone
| string Nakama.Console.IApiUser.Timezone |
|
get |
The timezone set by the user.
◆ UpdateTime
| string Nakama.Console.IApiUser.UpdateTime |
|
get |
The UNIX time when the user was last updated.
◆ Username
| string Nakama.Console.IApiUser.Username |
|
get |
The username of the user's account.
The documentation for this interface was generated from the following file:


Welcome back to CensusMapper!
Please enter the following information to make a new CensusMapper account.All fields are required.
Enter a name for your map.
You must be logged in to save a map.
Export your map.


Pokemon Video Reveals Ash Ketchum's Teams Across the Various Anime
by Math EraoAn impressive video runs down every one of Ash Ketchum's Pokémon partners from the past two decades of the popular anime.
YouTube account よろず屋 has put together an exhaustive video breaking down all of Ash's teams, from the first animated series to the Alolan adventures of Sun & Moon. Check out how the trainer's roster has changed since his adventure began in 1997:
As the video is from May of last year, it lacks the latest updates to Ash's Sun & Moon team, but it's nevertheless an impressive feat of fandom to see every roster laid out. With the new game Sword & Shield now out, fans can also expect Ash to gain a new Galar-based group soon. In fact, we've already caught a glimpse of the new Pokémon anime that will arrive later this year.
The new series will be something of a reboot, taking the simple title of Pokémon: The Series. It will follow Ash after finally winning the Pokémon League, teasing that the static nature of the series may be getting more updates.
Pokémon: The Series will premiere on Nov. 17 in Japan. Pokémon Sword & Shield is out now on Nintendo Switch.
https://schema.orgBreadcrumbListListItem1Homehttps://www.cbr.com/ListItem2TVhttps://www.cbr.com/category/tv/ListItem3TV Newshttps://www.cbr.com/category/tv/news-tv/ListItem4Pokemon Video Reveals Ash Ketchum's Teams Across the Various Animehttps://www.cbr.com/pokemon-video-every-ash-ketchum-team-anime/


https://developer.mozilla.org/en-US/docs/MDN/Contribute/Guidelines/Code_guidelines/JavaScript
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions
https://www.smashingmagazine.com/2016/07/how-to-use-arguments-and-parameters-in-ecmascript-6/
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures
https://medium.com/javascript-scene/master-the-javascript-interview-what-is-a-closure-b2f0d2152b36
https://medium.com/backticks-tildes/understanding-hoisting-and-scoping-in-javascript-39ea7b41e31
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/typeof
http://www.c-point.com/javascript_tutorial/jsgrpComparison.htm
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/undefined
https://levelup.gitconnected.com/sneak-peak-of-map-filter-and-reduce-in-javascript-79d38181a48
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes
https://medium.com/karuna-sehgal/a-simplified-explanation-of-the-big-o-notation-82523585e835
https://medium.com/javascript-scene/master-the-javascript-interview-what-is-a-promise-27fc71e77261
https://medium.com/ltunes/what-is-clean-code-naming-conventions-part-1-426d383eb85d
The purpose of these standards is to promote maintainable, readable and scalable JavaScript code.
Whilst these standards will adhere to the behaviours, limitations and conventions of JavaScript, some of the core principles mentioned are proven software design principles, which may be applied across the board, such as the SOLID, YAGNI, KISS and DRY principles.
In order to understand the reasoning for some of these standards, it is important to first understand the dynamic nature of JavaScript and some key characteristics, along with the available tools that are native to the language. With this in mind, this document will attempt to offer clear explanations to justify suggestions.
This document will also include examples using the latest ES6 JavaScript standards. Apply these with caution. Ensure browser compatibility and use a transpiler such as Babel if you wish to use ES6 syntax.
There is a repository of all examples used in this document: NEED TO ADD REPO LINK
All JavaScript should be written in strict mode. This will highlight possible issues with the script either during compilation, with a tool such a Babel, or in the developer console in the browser.
name = "Adam"; console.log(`Hello ${name}`);
This will not error, but there is a problem with this code. The name variable is global and it has no protection. Declarations such as this should not happen for a number of reasons, mainly around scoping and shadowing, explained later in more detail.
"use strict"; name = "Adam"; console.log(`Hello ${name}`);
Now in strict mode, this will error and so it should! Strict mode has highlighted for us that this is bad code and we should correct it. We should see strict mode as a useful tool when writing quality JavaScript and we should always use it.
Naming can be split into the following categories:
General naming conventions
Variable names
Constant names
Function names
Function and variable naming should be in camelCase.
Class and constructor functions should be in PascalCase.
Constants should be identified by using CAPITAL_CASE.
Variable names should be meaningful, searchable and pronounceable. Variable names should reveal intention of use and avoid disinformation.
Think about why the variable name exists, we should be able to tell what the variable holds in memory just by reading it.
Comments should not be required in order to explain a variable name. The name itself should be meaningful and sufficient that comments are not required.
We should not use mental mapping of variable names with the use of abbreviations such as “i”, or “a” or “dd” or “crn” etc:
var i = 0;
What is “i” in this context ? This is disinformation. In this case a more meaningful variable name would be preferred: “index”, “counter” or “position”.
Depending on the scope, Variable names should also not be unnecessarily too descriptive, such as: indexOfTheItemIamIteratingThroughInMyCollection - In a local scope this can also be seen as disinformation by being overly descriptive. We are aware of the context in a local scope, so a shorter variable name would be preferred.
var index = 0;
The problem of abbreviation becomes more relevant in the case of nested for loops when working with multidimensional arrays:
var categories = [[0,1],[2,3]]; for(var i = 0; i < categories.length; i++) { for(var j = 0; j < categories[i].length; j++) { console.log(categories[i][j]); } }
When there are nested for loops, there will be multiple index variables. Abbreviating them could cause ambiguity around what “i” or “j” are, you also cannot use “i” twice in the same block scope, as it already exists.
var categories = [[0,1],[2,3]]; for(let category = 0; category < categories.length; category++) { for(let item = 0; item < categories[category].length; item++) { console.log(categories[category][item]); } }
Here using, short but descriptive variable names allows us to clearly read what we are iterating over.
However, using “i” for the index variable in the context of a single level for loop is a common approach and is acceptable :
const items = [0, 1, 2, 3]; for(let i = 0; i < items.length; i++) { console.log(items[i]); }
Variable names can however be longer, but their length should be relative to the scope they are in.
A variable name in the outer scope (not necessarily global), might require some additional context or even a namespace for it to be meaningful enough, making it longer in length. This is the preferred approach, instead of the need to add comments in order to explain what a variable is doing, the name itself should be enough.
//Outer scope let entry = "index.js"; let root = "http://www.application.co.uk/"; let getEntryUrl = function() { //Inner scope return `${root}${entry}` } console.log(getEntryUrl())
The problem with these variable names is that they do not reflect the scope they are in, they have no context. Both entry or root are being declared in a much wider scope than where they are being used. They are being used at the block level, so for us to know where they have come from and what they are being used for, we should consider a more descriptive naming convention for them.
//Outer scope let globalApplicationConfigurationSettings = { entry: "index.js", root: "http://www.application.co.uk/" } let getEntryUrl = function() { //Inner scope return `${globalApplicationConfigurationSettings.root}${globalApplicationConfigurationSettings.entry}` } console.log(getEntryUrl())
Now our intention is clear with a much more descriptive naming convention. We are still declaring in the outer scope, but they are being encapsulated by an object literal, which means in order to access these properties we need to go via the objects namespace. This now gives root and entry a clear context and we know exactly where they are coming from and what they are going to be used for.
We should be writing boolean variables as predicates, such as “is” or “has”. This would help denote state. For example, either something “is” or something “is not”.
let empty = true; if(empty) { console.log("It is empty"); }
We do not know initially from looking at this variable that it returns a boolean, we can only assume it is. For all we know, empty could contain an empty string, not a state. This variable also has no context, what is empty ? It is ambiguous.
let input = { isEmpty: true } if(input.isEmpty) { console.log("It is empty"); }
This variable now refers to something that “is” empty. We have also used an object literal to contain all of the properties sharing the same context. This also allows for a nice and clear if statement.
We should avoid Magic Numbers where possible. We should always declare arbitrary numbers as variables with a clear, meaningful name as per our naming conventions.
var password = "Password1"; if (password.length > 8 && password.length < 31) { console.log("Password is valid"); }
Initially from the above code we do not know the meaning of 8 or 31 without reading through the code first. We should know what they are being used for without need to read through the code.
var password = "Password1"; const MIN_PASSWORD_LENGTH = 8; const MAX_PASSWORD_LENGTH = 31; if (password.length > MIN_PASSWORD_LENGTH && password.length < MAX_PASSWORD_LENGTH) { console.log("Password is valid"); }
Now we have assigned these values as constants with meaningful names. We now know exactly what they are being used for. We can also change them without needing to amend the existing logic directly.
Constants should be identified as being “constant”, something that cannot be changed. We can visually do this with the use of CAPITAL_CASE. In JavaScript if you see a declaration using CAPITAL_CASE, it means the value should not be changed.
var thresholdOfUsers = 10; var thresholdOfUsers = 30; thresholdOfUsers = 50;
Visually there is nothing denoting the above variable should be treated as a constant. This is a problem when trying to ensure your code is to be used as intended by other developers.
var THRESHOLD_OF_USERS = 10; // or, even better: const THRESHOLD_OF_USERS = 10;
By using CAPITAL_CASE it helps identify the difference between a constant, which should not be changed and a variable declared using camelCase which may be changed. We can offer additional protection by using the const keyword. This is covered in section 5. Declarations in more detail.
With the same approach, function names should also be meaningful, searchable and pronounceable. Make them a verb, what is the function actually doing ? what is it returning ? is it an integer, a boolean, a string ?
JavaScript by nature is a dynamic language, it is not strongly typed, which means it is very easy to return an unexpected data type, either intentionally or unintentionally. Making variable and function names descriptive is very important when making code readable and understandable, as this cannot always be denoted from a methods signature in JavaScript, unlike some statically types languages such as C#, Java etc.
function error(input) { return input === 0; };
The problem here is the method name does not suggest it is doing anything, or that it is returning anything, when it is in fact evaluating an input and returning true or false.
function validateInput(input) { return input === 0; };
Breaking this method name into parts. The “validate” is a verb and implies what this method is doing - validating. The “Input” is describing what we are actually acting on, or evaluating.
Functions or members that exist inside a specific scope or class should not add unnecessary context to their names:
var user = function() { this.getUser = function() { }; this.deleteUser = function() { }; }
The additional context of “user” is not needed here:
var user = function () { this.get = function () { }; this.delete = function () { }; }
We should be using either Constructor functions, object literals or the class construct where possible for declaring patterns of variables that could be identified as objects. This is typically good in the sense of a more traditional object oriented approach to programming. This can really help with code reuse, reducing repetition and also improve reliability and readability.
let name = "James" let age = 23; console.log(`${name} ${age}`) name = "Anna" age = 30; console.log(`${name} ${age}`) name = "Tim" age = 18; console.log(`${name} ${age}`)
With the example above the same two variables are being declared and reassigned with every instance before being used, in this case to simply log out to the console, but this could well be call updating a database, for example. There is a clear repetition of code here and a clear pattern. We should avoid such repetition as this. If we see this occurring in our code, we should refactor our code.
let persons = []; persons.push({ name: "James", age: 23 }); persons.push({ name: "Anna", age: 30 }); persons.push({ name: "Tim", age: 18 }); persons.forEach((person) => console.log(`${person.name} ${person.age}`));
We could instead declare each instance of the repetition as an object literal representing each person and push them into a collection. Each person is now encapsulated by an object. We could have also declared each object literal directly into the array, either way would have helped create a more definitive pattern.
We could also refactor this further to alternatively use either a constructor function or a class.
let persons = []; let Person = function(name, age) { this.name = name; this.age = age; } persons.push(new Person("James", 23)); persons.push(new Person("Anna", 30)); persons.push(new Person("Tim", 18)); persons.forEach((person) => console.log(`${person.name} ${person.age}`));
Now we have even more reduced code repetition and we do not need to manually type the object literal every time, but this solution would be more performance intensive on a larger scale because we are creating an object by calling a function for every instance.
let persons = []; class Person { constructor(name, age) { this.name = name; this.age = age; } } persons.push(new Person("James", 23)); persons.push(new Person("Anna", 30)); persons.push(new Person("Tim", 18)); persons.forEach((person) => console.log(`${person.name} ${person.age}`));
Now using a class this reads more like a traditional object oriented approach, but is effectively the same as the constructor function example.
Constructor functions, object literals and classes help save space, eliminate variable repetition and also have great benefits when it comes to inheritance and The SOLID Principles, covered later in this document.
The preferred pattern in JavaScript is to have the opening brace inline with the declaration, preceded with a space and the closing brace on the following line, unlike some languages such as C#.
function myFunction() { } function myFunction() { }
function myFunction() { }
This applies to all usages of braces, whether that be JSON, object literals, if statements, function declarations, etc.
All control structures should use braces even though they are not necessary. This makes the intended execution clear:
if (valid === true) doThis();
An indentation is all that stands between semantic code and non-semantic code, which would not run as intended and also cause an error if the indentation was incorrect.
if (valid === true) { doSomething(); }
This is considered safer and clearer to read. Not only do we have the indentation identifying the code to be executed, we also have the braces offering safety and encapsulation.
Variable declarations in JavaScript as of this writing can be made using three different keywords, var, let and const.
Each have different behaviours and we should use them as required. It is not a case of simply using let instead of var. There is good reason to use let instead of var as long as the scoping behaviour meets your needs.
let and const protect against re-declaration, with let allowing re-assignment and const not allowing re-assignment. This makes using let and const safer than always using var, which can be re-declared and re-assigned.
*Please note, currently let and const require transpilation to work in older browsers such as IE11. This process will also catch any attempts to try and re-declare with let and const and re-assignment of const.
var thresholdOfUsers = 10; var thresholdOfUsers = 30;
Drawing on a previous example. Here var is allowing us to re-declare a variable, there is nothing stopping this from happening, meaning context and value could be changed at any point during a program. Imagine a scenario where two developers are working on the same application, in the same scope but in separate scripts and they both declare variables with identical names in the global scope. This is a problem.
const THRESHOLD_OF_USERS = 10;
The keyword const protects against re-declaration and re-assignment.
If the intention is to not re-declare, but to re-assign, we can use let. This means we cannot re-declare the same exact variable, but we can change its value.
var THRESHOLD_OF_USERS = 10; var numberOfUsers = 11; var isThresholdMet = false; var THRESHOLD_OF_USERS = 11; // Within the same global scope, there is nothing stopping this from happening. if (numberOfUsers > THRESHOLD_OF_USERS) { isThresholdMet = true; numberOfUsers--; }
Here the re-declaration of THRESHOLD_OF_USERS
means that our if statement will fail to
catch the scenario.
const THRESHOLD_OF_USERS = 10; let numberOfUsers = 11; let isThresholdMet = false; if (numberOfUsers > THRESHOLD_OF_USERS) { isThresholdMet = true; numberOfUsers--; }
Here we make use of const for a value that will not change, and we can re-assign values where we have used let. The above code will not exceed the threshold and demonstrates a scenario where you may want to intentionally re-assign.
We should not be delimiting variable declarations with a comma. This can make code tricky to read and hard to debug.
let make = "Ford", color = "Blue", isHybrid = false;
We now cannot debug these declarations per line, it is also easy to miss read these declarations as global declarations without the use of var, let or const, when they are in fact, block level declarations in a local scope. This also makes it hard to make use of the various different keywords var, let and const as necessary, they do not all behave in the same way.
let make = "Ford"; let color = "Blue"; let isHybrid = false;
We could now debug each of these declarations per line if needed, also it is very clear each line is being declared with the keyword - let.
When declaring a complex string, we should be using template literals instead of using the + operator to concatenate multiple strings together. This will make for much clearer string declarations and are easier to read and code.
let name = "Anna"; let age = 40; let description = name + " is " + age + " years old."; console.log(description);
We have to open and close each string and concatenate them together using the + operator. This is a very manual way to code, especially at length, when considering full sentences for feedback in a UI, for example.
let name = "Anna"; let age = 40; let description = `${name} is ${age} years old.`; console.log(description);
This now reads much clearer and is easier to code. We do not need to open and close each string, we use a single template literal and populate it with the declared variables above. We should use template literals where possible.
Understanding scoping in JavaScript is incredibly important. There are two main scopes to consider:
The Global Scope
The Local Scope (Block level scope)
In the instance of the web the Global Scope is the Window object. So if you are to declare a variable at Global Scope it will belong to the Window object. We should avoid setting Global variables at all costs. The reason for this is because in JavaScript it is very easy to re-declare a variable of the same name in the Global Scope, changing the context of the variable entirely. You may also alter a global declaration from any Local Scope. This is known as variable shadowing, we must protect our code against this scenario and we can do this by avoiding global declarations.
The Local Scope is a more manageable scope and gives us protection against variable shadowing. Declarations within a Local Scope cannot be altered from outside of that scope, in effect they become “private”.
This is similar to Access Modifiers in C#, but we achieve it in a different way with JavaScript:
function myFunction() { console.log("myFunction in Global Scope 1"); } myFunction(); function myFunction() { console.log("myFunction in Global Scope 2"); } myFunction();
The above code will output “myFunction in Global Scope 2
” twice, because the method is declared
twice within the same Global Scope. This results in “shadowing”. Imagine if these declarations
existed in separate scripts, but are loaded onto the same Global Scope. They would clash, and
the last declaration of the method would override the first.
(function() { function myFunction() { console.log("Local Scope"); } myFunction(); })(); function myFunction() { console.log("Global Scope"); } myFunction();
This would ensure we have two separate declarations of the method myFunction, resulting in both methods being run
individually. The output in this case is “Local Scope
” “Global Scope
”.
A Closure is the encasing of a function together with references to its outer state, created at the point of definition. A closure gives you access to an outer functions scope and state (the Lexical environment) from the inner function.
“A closure is the combination of a function and the lexical environment within which that function was declared. This environment consists of any local variables that were in-scope at the time the closure was created” https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures
You should use Closures to emulate private variables where necessary. In a scenario where you want to protect a state a function will run against, we should use Closures.
Closures are also key for managing the global namespace, and again we should consider them where possible.
var increment = function(prop) { return !isNaN(prop) ? prop + 1 : 0; } var increment = function(prop) { return !isNaN(prop) ? prop + 2 : 0; } // Imagine the above methods are declared in seperate scripts, but in the same global scope. // The context of the add method has changed. We may not be aware of the new definition. // Now when we use the method, we are using the latter definition. // Not our intention. increment(0); // This will return 2
This will return 2, as we have been able to change the definition of the method. This highlights the need for Closures and why they are necessary to help us manage the global namespace.
const methodFactory = function() { return function(prop) { return !isNaN(prop) ? prop + 1 : 0; } } let increment = methodFactory(); increment(0); // This will return 1
This will return 1 as intended. We cannot, in anyway change the definition of the nested “private” method. We also use the const keyword to protect our namespace definition.
A common type of closure is the Module Pattern. This offers encapsulation, a closed scope, cohesion and the ability to expose only the methods we wish to via an interface, we do this in the form of an object literal. Methods which are not exposed remain private.
var module = { privateMethod: function() { }, publicMethod: function() { } };
The above would offer a namespace, but expose all methods. We also could not capture state, as it is not a closure.
const module = (function() { const privateMethod = function() { } const publicMethod = function() { } return { publicMethod: publicMethod } })();
The same code written using the Module Pattern. The anonymous function encapsulates the scope of the module and returns an object literal, exposing only the methods we would like to expose.
An AMD module extends the standard Module Pattern, and is wrapped using the define() function in conjunction with a loader such as Require.js, Browserify or Webpack, among others, in order to load the module and any dependencies. https://requirejs.org/docs/whyamd.html
//Calling define with a dependency array and a factory function define(['dep1', 'dep2'], function (dep1, dep2) { const base = 0; const myMethod = function(prop) { return base + prop; } return { myMethod: myMethod }; });
We can now load this module via a module loader, meaning we can utilise dependency injection, allowing us to manage our dependencies more economically, instead of loading them all at once.
In JavaScript when we need to refer to the current context we will use the this keyword. It is common in a number of programming languages to use this for when you would like to refer to a property or method within the current context. Not so straightforward in JavaScript however, because the context is always changing depending on where and how the code has been executed.
The key thing to remember with this and JavaScript is that it is relative to the current scope, whether that be Local Scope or Global Scope. Because there are multiple scopes in JavaScript, it is important we understand which this we are referring to.
For example in terms of the web browser environment, using this in the Global Scope will refer to the Window object. But if we are to use this from within an event callback method, this will refer to the context of the event and not beyond.
Arrow functions, Introduced with ES6, allow us to write shorter and cleaner code. But beyond their abbreviated syntax, the real power of arrow functions lies in their handling of this.
“Before arrow functions, every new function defined its own this
value based on how the function was
called” https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions
It is possible to have access to the defining context from within a Local Scope, the defining context being that which defined the method and not the context of the method itself. This is known as Lexical this, and can be achieved with the use of arrow functions.
Arrow functions allow access to the defining context, because there is no binding of this in arrow functions, unlike regular functions, which bind this to the context that called the function, whether that be Window, Document, Event etc.
See the below example taken from the Mozilla JavaScript reference:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions
function Person() { var that = this; that.age = 0; setInterval(function growUp() { // The callback refers to the `that` variable of which // the value is the expected object. that.age++; }, 1000); } var person = new Person();
In order to get hold of this in the defining scope from the calling scope, we need to first declare this as a local variable within the defining scope. We can later then refer to this as that and be confident we know which this we are referring to. But this means mapping this to a new variable before the context changes. Imagine if you had many nested scopes, each with their own this.
function Person() { this.age = 0; setInterval(() => { this.age++; // |this| properly refers to the Person object }, 1000); } var person = new Person();
Now that we are using an arrow function we are able to use plain old this in order to refer to the defining scope. This is because the arrow function has no this bound to it.
It is very important to only use arrow functions if you intend the use of this to be handled in this way. Using arrow functions may not always result in the intended outcome, it might be that the handling of this in a more traditional method is better for your needs. Use arrow functions with caution, they are great but they have their purpose and are not always necessary, despite their nice syntax. We should use arrow methods when we require access to the defining scope.
Equality is very important due to the dynamic nature of JavaScript. We need to be confident when making comparisons that a value is what we expect it to be.
When comparing a value against another using only a Reference Equality Operator (==/!=), JavaScript will attempt to match the types of two values. But in doing this the value itself can change, meaning you are no longer comparing the original values. The values are coerced into something they are not.
In other words, 0 is equal to ““ in JavaScript when comparing an integer to a string and only using a Reference Equality Operator (==/!=) because the empty string gets converted into a number, that number being a 0 by best match according to JavaScript. But a zero is not equal to an empty string!
For this reason, we should always be using the Identity Equality Operator (===/!==) when comparing values in JavaScript. When using the Identity Equality Operator there is no type conversion and both values must be of the same type in order to be considered “equal”, so we can be confident they are indeed the same.
"" == 0; // this equals true.
This returns true, which is a real problem when trying to compare types. Imagine if we were to now perform a sum on a variable that is in fact equal to “” because we assume it to be a number after the above equation returns true ? We would get a NaN error!
"" === 0; // this equals false, and so it should!
Now using the Identity Equality Operator we are able to not only be confident that these values do not match, but also their types are not the same either, so this will now return false. An equation such as 0 === 0 would return true, this is what we are checking for.
"" != 0; // this would return false, meaning these are equal when they are not.
We can clearly see these values are not equal but the Reference Equality Operator is distorting our perception of what is true or false.
"" !== 0; // this would return true, as it should because they are not equal.
We can now be confident that these values do not match by using the Identity Equality Operator.
JavaScript has a great tool for checking if a value is a number - isNaN(). We should always use isNaN() where possible before attempting number equations. This will prevent us from getting NaN errors when dealing with numbers.
This is useful for when we are not checking for a particular numerical value but specifically the type and do not want to perform a typeof check, which we could do in order to check a value is a “number” but we would need to check this specifically ( === “number”), isNaN(); handles the type checking for us in an easy to use function.
let valueA = "abc"; let valueB = 1; let result = 0; // First problem result = valueA + valueB; console.log(result); // Second problem result = valueA * valueB; console.log(result);
There are a couple of things you will notice here. The first problem being that instead of attempting a sum of two values, which was our intention, we have performed a string concatenation instead. JavaScript has coerced valueB into being a string. The second problem is when we attempt to perform a more advanced equation, in this case with multiplication. This causes a NaN error. This is because the types do not match and, we could have prevented this from occurring:
let valueA = "abc"; let valueB = 1; let result = 0; if(!isNaN(valueA) && !isNaN(valueB)) { result = valueA * valueB; } console.log(result); valueA = 2; valueB = 2; if(!isNaN(valueA) && !isNaN(valueB)) { result = valueA * valueB; } console.log(result);
Notice how result is still just 0 for the first output. This is because we will only attempt to multiply these two values if they are both numbers.
With our second pass, we have re-assigned valueA and valueB to indeed be numbers. Now running the same code, result returns 4 because isNaN(); returned false.
There is one important thing to always remember with isNaN(); It is checking if a NaN error is returned from type checking a value. So in the above snippet we are checking that a NaN error has NOT occurred by using the ! operator (exclamation mark) to check the result is false. Keep this in mind when using isNaN();
Another very important tool when it comes to checking for types is the typeof keyword. JavaScript is not strongly typed, we need to manually check for types if we want to be sure.
We should be using typeof even if we are sure of a type, incase the context has been altered for example, or a value is undefined. This way our code will only run if the value is of the correct type. This offers protection against incorrect use.
typeof is best used in conjunction with an if statement and an Identity Equality Operator.
typeof will return a string representation of the type, so when testing for a type, it is important to know the string definition for each type:
“undefined”
“object”
“boolean”
“bigint”
“string”
“symbol”
“function”
let callback = true; let get = (callback) => { if (callback) { callback(); } } get(callback);
This will give an error “callback is not a function”. This is because we loosely checked the callback parameter and assumed that whatever is being passed in is always going to be a function and something that we can run. But in this case, it is not a function, so we have a problem. What we need to do, is check specifically if the parameter is a function before attempting to handle it as a function.
let callback = true; let get = (callback) => { if (typeof callback === "function") { callback(); } } get(callback);
This will now not error, as we are checking what type the callback parameter is first. If we were to pass in a callback function, then the function would run. This is also known as a higher order function or delegate function.
let callback = () => console.log("This is our callback"); let get = (callback) => { if (typeof callback === "function") { callback(); } } get(callback);
This will now run and we will also see an output in our developer console “This is our callback”.
Undefined is a primitive type in JavaScript, along with Boolean, Number, String, Symbol, Null etc.
We can think of undefined as the default return type in JavaScript for an object or variable that has not yet been initialised. If something is not defined, it is therefore undefined.
It is common, when viewing an undefined JavaScript error in the console to see one of the following:
TypeError: 'undefined' is not a function TypeError: Cannot read property '<prop-name>' of undefined
Whilst it is best practice to always initialise a variable or object first with a default value of the correct type, sometimes this is out of our control. This is when we need to defend against undefined.
We can reliably test for undefined by using typeof.
let myVariable; console.log(myVariable);
This variable is not initialised with any value. So when we try and use it, we see that it is undefined.
let myVariable; if (typeof myVariable !== "undefined") { console.log(myVariable); }
By using typeof we can check to see if a variable returns the string representation of the primitive type -undefined. By doing this check, the code will not run if the variable is undefined. If our variable is initialised however, then the above code would run without error.
let myVariable = 0; if (typeof myVariable !== "undefined") { console.log(myVariable); }
In this example we see how initialising with a default value allows the above check to pass and the code to run.
It is important to always protect against the occurrence of undefined in our code, such an error can cause the entire script to freeze. We can do this by making sure we always initialise our definitions before using them.
This can be done both in a method signature and within our closures/methods at the point of definition.
let price; price.toFixed(2);
You will notice when running this code we get an error: TypeError: Cannot read property 'toFixed' of undefined. This is because, although we have defined our variable, we have not initialised it with any value.
let price = 0; price.toFixed(2);
By assigning the variable with an initial value it is no longer undefined and when we want to act on it, we can, without getting an error.
This can be more common in a method signature, with the assumption that something being passed in is safe to use straight away, when it is not:
let myMethod = (price) => { return price.toFixed(2); } myMethod();
This will also error with the same response as the first problem TypeError: Cannot read property 'toFixed' of undefined.
let myMethod = (price = 0) => { return price.toFixed(2); } myMethod();
Now with a default value assigned in the method signature, the above method will not error.
It is however safer to combine both a default value with an undefined typeof check in the same method. This will give maximum protection against an undefined value.
let myMethod = (price = 0) => { if (typeof price !== "undefined") { price = price.toFixed(2); } return price; } myMethod();
Accessing the DOM is something very common in JavaScript, due to the position it tends to sit within the stack. For the most part, accessing the DOM for a single element is no big deal. But if working on a large application, with the DOM populated with many HTML elements, it is very important to understand what is happening every time you get or update an element.
document.querySelector("#elementId").innerText = "Some text"; document.getElementById("elementId").setAttribute("class", "someClass");
The above will perform a search of the whole DOM as the HTML is parsed in order to find the elements that are being requested. For a single use, it can be argued storing the element before using it is of little benefit, but for multiple updates it is important to store the element first.
We would not want to be calling any of the above methods thousands of times during an iteration for example. We would want to be using caching in order to store and access elements in memory, instead of physically accessing the DOM every time.
To give this some context, such frameworks as React and Vue.js build up a “virtual DOM” cached in memory, which is always kept in sync with the physical DOM on screen by a process called “Reconciliation”, this helps a great deal to improve performance and is good evidence that caching DOM access is good practice and good for performance. See the React documentation for more detail on the “Virtual DOM” - https://reactjs.org/docs/faq-internals.html
let element = document.getElementById("elementId"); element.innerText = "Some text"; element.setAttribute("class", "someClass");
Now we only access the physical element once, store it and then update it. Notice updating the stored element will also update the physical DOM due to the stored element being of reference type. This is because JavaScript, like other programming languages, also has reference types and value types.
There are various ways we can loop in JavaScript, depending on what it is you want to do. Some methods are quicker than others and much more performant, again depending on the size of the iteration.
Big O is a great way to assess how expensive your program is. This may help decide which iteration method might fit best to maximise on performance. A great explanation of Big O in relation to JavaScript can be found here - https://medium.com/karuna-sehgal/a-simplified-explanation-of-the-big-o-notation-82523585e835
These looping method are all on the Array prototype, which means we can only use them directly on an array. They all require a higher order function, as they all take a single method as a parameter.
The method passed is performed on every iteration, so be aware of this when using such array methods. Such methods are slow to run when considering a large number of iterations and are not particularly performant. They are good to use on small arrays and can really help reduce code, but we should not be using them for all scenarios, especially not because they read nicely.
These are the more traditional looping methods, and most common in programming languages. They are far more adaptive than the “ready made” Array looping methods in JavaScript and can be far more performant with a large number of iterations.
for looping is great for when you know your limit and while looping is best used when we want a loop to run until a given condition.
We should be using the correct looping techniques for each given scenario.
The code below demonstrates how certain looping techniques are not as good as others when it comes to performance:
// Lets setup an example to loop against let array = []; let i = 0; while(i < 2000000){ array.push(Math.random(5)); i++; } let calc = (a) => a * 1000; let getTime = () => new Date().getTime(); let timeDifference = (start, end) => end - start; // Now lets run the below looping methods to see which is more performant. let mapExample = () => { let start = getTime(); array.map((item) => item = calc(item)); let end = getTime(); console.log(`Map example took: ${timeDifference(start,end)}`); } let forEachExample = () => { let start = getTime(); array.forEach((item) => item = calc(item)); let end = getTime(); console.log(`ForEach example took: ${timeDifference(start,end)}`); } let forwardsForExample = () => { let start = getTime(); for(let i = 0; i < array.length; i++){ array[i] = calc(array[i]); } let end = getTime(); console.log(`Forward for loop example took: ${timeDifference(start,end)}`); } let forwardsForCachingExample = () => { let start = getTime(); let length = array.length; let i; for(i = 0; i < length; i++){ array[i] = calc(array[i]); } let end = getTime(); console.log(`Forward for loop, w/ cached length example took: ${timeDifference(start,end)}`); } let backwardsForExample = () => { let start = getTime(); for(let i = array.length; i--;){ array[i] = calc(array[i]); } let end = getTime(); console.log(`Backward for loop example took: ${timeDifference(start,end)}`); } let backwardsForCachingExample = () => { let start = getTime(); let length = array.length; let i = length; for(i; i--;){ array[i] = calc(array[i]); } let end = getTime(); console.log(`Backward for loop example took: ${timeDifference(start,end)}`); } let whileExample = () => { let start = getTime(); let i = 0; let length = array.length; while(i < length) { array[i] = calc(array[i]); i++; } let end = getTime(); console.log(`While loop example took: ${timeDifference(start,end)}`); } mapExample(); forEachExample(); forwardsForExample(); forwardsForCachingExample(); backwardsForExample(); backwardsForCachingExample(); whileExample();
We can clearly see from the resulting outputs after running this code which looping methods are more performant and which are better at handling a larger number of iterations.
You will see something like:
Map example took: 507 ForEach example took: 137 Forward for loop example took: 5 Forward for loop, w/ cached length example took: 5 Backward for loop example took: 7 Backward for loop example took: 5 While loop example took: 4
With the Array methods Array.map() and Array.forEach() being the slowest, especially Array.map(). Array.reduce() and Array.filter() have different uses to what we are doing here, but both are equally as slow as Array.map() depending on the method being passed and what it is doing of course.
The various iterations of for looping are much alike, but there are small performance gains to be made with these techniques. Notice we store both the index variable and the length of the array before iteration. We should be storing both in memory and not declaring them for every iteration.
Both for and while come out on top when compared to other looping techniques.
The S.O.L.I.D Principles are a set of principles that traditionally apply to classic object oriented programming languages. Whilst JavaScript is not solely an object oriented language and is very dynamic in nature, consisting of multiple paradigms, we can apply the SOLID principles for the most part.
Arguably there are a number of ways the SOLID principles can be interpreted in JavaScript, especially when it comes to inheritance, but we will focus on solutions already looked at in this document. We have already been following the SOLID principles to some degree.
The Single Responsibility Principle aims to have a single concern for any given piece of code. We should not couple logic and responsibilities together, we should separate out the logic and responsibilities. Smaller, manageable methods will allow for single responsibility, which in turn will allow for effective unit testing.
const doMath = (firstNumber = 0, secondNumber = 0, operator = "+") => { let result = 0; if(operator === "+") { result = firstNumber + secondNumber; } else if (operator === "-") { result = firstNumber - secondNumber; } else if (operator === "x") { result = firstNumber * secondNumber; } return result; } let result = doMath(1, 2, "+"); console.log(result); result = doMath(2, 1, "-"); console.log(result); result = doMath(1, 2, "x"); console.log(result);
This example breaks a number of the SOLID principles. It is not following single responsibility because a single method is being used for many concerns. This method would only grow and become unmanageable with the more logic we give it.
We can address this by having a dedicated method for each task:
const add = (firstNumber = 0, secondNumber = 0) => firstNumber + secondNumber; const subtract = (firstNumber = 0, secondNumber = 0) => firstNumber - secondNumber; const multiply = (firstNumber = 0, secondNumber = 0) => firstNumber * secondNumber; let result = add(1, 2); console.log(result); result = subtract(2, 1); console.log(result); result = multiply(1, 2); console.log(result);
Instead of having a single method that has many responsibilities we can have individual methods, each with a single responsibility. There is no logic involved to decide which method to use and we can be clear which method we would like to use in each case. Now we could unit test each method individually, for example, making this much more manageable.
The Open Closed Principle - Open for extension, closed for modification. We need to write our code in such a way that we can extend it, without needing to change existing code.
We will go back to the bad example used for The Single Responsibility Principle.
const doMath = (firstNumber = 0, secondNumber = 0, operator = "+") => { let result = 0; if(operator === "+") { result = firstNumber + secondNumber; } else if (operator === "-") { result = firstNumber - secondNumber; } else if (operator === "x") { result = firstNumber * secondNumber; } else if (operator === "/") { result = firstNumber / secondNumber; } return result; } let result = doMath(1, 2, "+"); console.log(result); result = doMath(2, 1, "-"); console.log(result); result = doMath(1, 2, "x"); console.log(result); result = doMath(6, 2, "/"); console.log(result);
As it stands, we could not extend the functionality of our method without changing the existing code. This would mean all logic surrounding this method would need to be retested, even if we only changed a single character or line or added a new if clause. We can improve our refactor for the Single Responsibility Principle even further to now cater for The Open Closed Principle.
let math = (function() { const add = (firstNumber = 0, secondNumber = 0) => firstNumber + secondNumber; const subtract = (firstNumber = 0, secondNumber = 0) => firstNumber - secondNumber; const multiply = (firstNumber = 0, secondNumber = 0) => firstNumber * secondNumber; return { add: add, subtract: subtract, multiply: multiply } })(); math.divide = (firstNumber = 0, secondNumber = 0) => firstNumber / secondNumber; let result = math.add(1, 2); console.log(result); result = math.subtract(2, 1); console.log(result); result = math.multiply(1, 2); console.log(result); result = math.divide(6, 2); console.log(result);
It is now possible to extend this solution. Using the module pattern, we can now add additional methods at will, without changing any original code in the module. But we should keep in mind that adding methods this way will always expose them via the modules interface.
We can achieve similar with prototypal inheritance, but with the added benefit of being able to pass the same behaviour to any derived object:
const MathFactory = function() { this.add = (firstNumber = 0, secondNumber = 0) => firstNumber + secondNumber; this.subtract = (firstNumber = 0, secondNumber = 0) => firstNumber - secondNumber; this.multiply = (firstNumber = 0, secondNumber = 0) => firstNumber * secondNumber; } let mathUtil = new MathFactory(); MathFactory.prototype.divide = (firstNumber = 0, secondNumber = 0) => firstNumber / secondNumber; let result = mathUtil.add(1, 2); console.log(result); result = mathUtil.subtract(2, 1); console.log(result); result = mathUtil.multiply(1, 2); console.log(result); result = mathUtil.divide(6, 2); console.log(result);
Notice that we have instantiated the MathFactory and then modified the base, which has used prototypal inheritance to modify all derived instances. This would not break the The Open Closed Principle and also not break the Liskov Substitution Principle, if there were multiple instances of the MathFactory, they would all still be interchangeable.
A solution now using ES6 Classes:
class MathFactory { add = (firstNumber = 0, secondNumber = 0) => firstNumber + secondNumber; subtract = (firstNumber = 0, secondNumber = 0) => firstNumber - secondNumber; multiply = (firstNumber = 0, secondNumber = 0) => firstNumber * secondNumber; } let mathUtil = new MathFactory(); MathFactory.prototype.divide = (firstNumber = 0, secondNumber = 0) => firstNumber / secondNumber; let result = mathUtil.add(1, 2); console.log(result); result = mathUtil.subtract(2, 1); console.log(result); result = mathUtil.multiply(1, 2); console.log(result); result = mathUtil.divide(6, 2); console.log(result);
The Liskov Substitution Principle states that any derived object should be substitutable for the base it was derived from without breaking the application.
Whilst this may not seem very relevant to a simple JavaScript application, not requiring instances and inheritance, we should still understand it.
We could apply this way of thinking to any object composition, to allow for swappable implementation, even with the module pattern and its object literal interface.
As an example of this in JavaScript we can look to the previous. We could have added a new method without using prototypal inheritance by adding it directly to the instance. The problem with this is that the instances would now differ from the base, and therefore would not be interchangeable. This would break the Liskov Substitution Principle.
Let's try and use another example to demonstrate the problem further.
class Dog { walk() { console.log("The Dog is walking."); } sleep() { console.log("The Dog is sleeping."); } bark() { console.log("The Dog is barking."); } } class Cat extends Dog { walk() { console.log("The Cat is walking."); } sleep() { console.log("The Cat is sleeping."); } bark() { throw new Error("Cats do not bark"); } meow(){ console.log("The Cat is meowing."); } } let dog = new Dog(); let cat = new Cat(); let animals = [dog, cat]; animals.forEach((animal) => { animal.bark(); });
This will cause an error: Error: Cats do not bark
This has happened because, while both Dog and Cat
have a lot in common (eat, sleep, walk, etc), they do not make the same noises. So in an attempt to make the Dog
“fit” into the Cat type, we have amended Cat, we have been lazy and tried to extend Dog. But in doing this it
means the subclass cannot be substituted for the superclass (base) in the existing application. It is also
confusing to read, as Cats do not bark, neither do all animals walk.
class Animal { move() { console.log("The Animal is moving."); } sleep() { console.log("The Animal is sleeping."); } communicate() { console.log("The Animal is communicating."); } } class Dog extends Animal { move() { console.log("The Dog is walking."); } sleep() { console.log("The Dog is sleeping."); } communicate() { console.log("The Dog is barking.") } } class Cat extends Animal { move() { console.log("The Cat is walking."); } sleep() { console.log("The Cat is sleeping."); } communicate() { console.log("The Cat is meowing.") } } let dog = new Dog(); let cat = new Cat(); let animals = [dog, cat]; animals.forEach((animal) => { animal.communicate(); });
Now we have a higher class to inherit from - Animal, which is more generic and has attributes in common with both Cat and Dog. We could swap either of the Dog or Cat for the base of Animal and our code would still execute without error. It is important to think ahead like this when designing any object oriented application, creating the correct hierarchy early on will ensure there is room for extension, not only ensuring we abide by the Liskov Substitution Principle, but also the Open Closed Principle and the Single Responsibility Principle too.
The Interface Segregation Principle aims to separate methods into cohesive groups of methods, with each method being related to a specific task. We should not be grouping methods together that have very little relevance to each other. For example, if there is a generic, large module or class, with many unrelated methods, that is being injected all over our application, we should not keep adding to that same module for the sake of convenience. We should instead create a new module or class, who’s only concern is of a specific task or related tasks.
let mathFactory = (function() { const add = (firstNumber = 0, secondNumber = 0) => firstNumber + secondNumber; const subtract = (firstNumber = 0, secondNumber = 0) => firstNumber - secondNumber; const multiply = (firstNumber = 0, secondNumber = 0) => firstNumber * secondNumber; // lets add a new method because an existing method does not already do what we want const greetingMessage = (name) => console.log(`Hello ${name}`); return { add: add, subtract: subtract, multiply: multiply, greetingMessage: greetingMessage } })(); mathFactory.greetingMessage("James");
Here we would have broken a number of the SOLID principles, one of which is the Interface Segregation Principle. We have appended a method, who’s concern has no relation to the other methods in the module. This module’s concern is to work with numbers, not print greeting messages. If this module is already being consumed by our calling code, it might be quicker and easier to just add a method to the existing module, but this would be breaking the Interface Segregation Principle.
let mathFactory = (function() { const add = (firstNumber = 0, secondNumber = 0) => firstNumber + secondNumber; const subtract = (firstNumber = 0, secondNumber = 0) => firstNumber - secondNumber; const multiply = (firstNumber = 0, secondNumber = 0) => firstNumber * secondNumber; return { add: add, subtract: subtract, multiply: multiply, } })(); // Make a new module let greetingFactory = (function() { const greet = (name) => console.log(`Hello ${name}`); return { greet: greet } })(); greetingFactory.greet("James");
Now we have a dedicated module that will only include methods that relate to greeting messages. This provides good cohesion and divides concerns. This will help keep modules small and manageable. We could then inject this new module into the application only where it is needed.
We can also express the same issue as a class:
class MathFactory { add = (firstNumber = 0, secondNumber = 0) => firstNumber + secondNumber; subtract = (firstNumber = 0, secondNumber = 0) => firstNumber - secondNumber; multiply = (firstNumber = 0, secondNumber = 0) => firstNumber * secondNumber; greetingMessage = (name) => console.log(`Hello ${name}`); } let mathUtil = new MathFactory(); mathUtil.greetingMessage("James");
class MathFactory { add = (firstNumber = 0, secondNumber = 0) => firstNumber + secondNumber; subtract = (firstNumber = 0, secondNumber = 0) => firstNumber - secondNumber; multiply = (firstNumber = 0, secondNumber = 0) => firstNumber * secondNumber; } class GreetingFactory { greet = (name) => console.log(`Hello ${name}`); } let greetingUtil = new GreetingFactory(); greetingUtil.greet("James");
The Dependency Inversion Principle aims to move dependency up the chain of command. The idea is to loosely couple our methods, modules and classes with their dependencies.
An obvious example of this is with server requests and nested callbacks, common in an AJAX request.
One way of achieving dependency inversion in JavaScript is by thinking of our functions as higher order functions and lower order functions. We can invert dependency by replacing lower order functions with higher order functions.
Another way of inverting dependency is to program more sequentially, instead of nesting code. Nested code can lead to dependencies being buried, this is what we need to look out for when identifying lower order functions. If we use promises, for example, we can “wait” for a task to complete before moving on, or while performing some other task, removing the need to nest code. Making asynchronous code appear synchronous. It is important to understand JavaScript can handle multiple threads, we should take advantage of this.
“A promise is an object that may produce a single value some time in the future” - See here for a great read on promises in JavaScript - https://medium.com/javascript-scene/master-the-javascript-interview-what-is-a-promise-27fc71e77261
let userDataFactory = (function() { const get = () => { // this object would typically come from an API call let data = { name: "Anna", colour: "Blue" } printFavouriteColour(data); } const printFavouriteColour = (data) => console.log(`Hello ${data.name}, your favourite colour is ${data.colour}`); return { get: get } })(); userDataFactory.get();
With this example we are breaking the Dependency Inversion Principle. We have dedicated methods to both get and printFavouriteColour, but the get method is always dependent on the printFavouriteColour method, this is essentially the callback method. We would need an entirely new get method, duplicating code, in order to do some other task once we have the data.
Instead we could move the depending code up the chain and pass it down as a higher order function. We could then always call the get method just to get the data and not assume we always want to print out the favourite colour of the user.
Because JavaScript is asynchronous by nature, it may be common to see nested callbacks. Similar to the above, in order to try and handle timing issues, we could even nest a couple of callbacks. This can get very unmanageable, very quickly and is referred to as “Callback hell” and “dependency hell”.
For example, if we needed to make another call to the server to get more data, but we needed to first wait for our user data to arrive before making the second call. How could we handle that without nesting methods ?
A possible solution is using async await (a promise) as a means of allowing our code to get the data first before doing anything with it. We can then program sequentially, instead of nesting callbacks or dependencies.
let userDataFactory = (function() { const get = async () => { // this object would typically come from an API call let data = { name: "Anna", colour: "Blue" } return data; } const printFavouriteColour = (data) => console.log(`Hello ${data.name}, your favourite colour is ${data.colour}`); const printName = (data) => console.log(`Hello ${data.name}`); return { get: get, printFavouriteColour: printFavouriteColour, printName: printName } })(); (async() => { let user = await userDataFactory.get(); userDataFactory.printName(user); userDataFactory.printFavouriteColour(user); })();
Now the same get method can be used again and again. There is no tightly coupled dependency in our code, we can determine what we would like to do once we have the data, we could even make another call to a different service and wait for both calls to complete, while doing some other task asynchronously. This now makes the get method very flexible and reusable. It has a single responsibility and is not tightly coupled to a behaviour or dependency.
A word on async await and promises - please consider browser compatibility before using this syntax and promises in general.
Now another solution using higher order functions to pass down the logic to use once we have the data:
let userDataFactory = (function() { const get = (callback) => { // this object would typically come from an API call let data = { name: "Anna", colour: "Blue" } if(typeof callback === "function") { callback(data); } } const printFavouriteColour = (data) => console.log(`Hello ${data.name}, your favourite colour is ${data.colour}`); const printName = (data) => console.log(`Hello ${data.name}`); return { get: get, printFavouriteColour: printFavouriteColour, printName: printName } })(); userDataFactory.get(userDataFactory.printFavouriteColour); userDataFactory.get(userDataFactory.printName);
With this example we are now passing down the chain a method that has come from a higher order. Think of this as being similar to a delegate method. The method we are passing down will determine what we do once we have the data. There is no assumption being made other than we want to do something once we have the data. Both solutions given are interpretations of dependency inversion, they move the control up the chain to a higher level.
The DRY Principle stands for “Don't' Repeat Yourself” and refers to code reuse and code repetition. Where we see patterns of code forming, we should either be refactoring the code to remove the repetition or design the code to maximise on code reuse from the beginning.
let make = "Audi"; let colour = "Red"; let isHybrid = false; let isHybridText = isHybrid ? "is a hybrid" : "is not a hybrid"; let description = `This car is an ${make} and it is ${colour}. This car ${isHybridText}`; console.log(description); make = "Ford"; colour = "Blue"; isHybrid = true; isHybridText = isHybrid ? "is a hybrid" : "is not a hybrid"; description = `This car is an ${make} and it is ${colour}. This car ${isHybridText}`; console.log(description); make = "Honda"; colour = "Black"; isHybrid = true; isHybridText = isHybrid ? "is a hybrid" : "is not a hybrid"; description = `This car is an ${make} and it is ${colour}. This car ${isHybridText}`; console.log(description); make = "Lamborghini"; colour = "Black"; isHybrid = false; isHybridText = isHybrid ? "is a hybrid" : "is not a hybrid"; description = `This car is an ${make} and it is ${colour}. This car ${isHybridText}`; console.log(description); make = "Porsche"; colour = "Yellow"; isHybrid = false; isHybridText = isHybrid ? "is a hybrid" : "is not a hybrid"; description = `This car is an ${make} and it is ${colour}. This car ${isHybridText}`; console.log(description); make = "Dodge"; colour = "Green"; isHybrid = true; isHybridText = isHybrid ? "is a hybrid" : "is not a hybrid"; description = `This car is an ${make} and it is ${colour}. This car ${isHybridText}`; console.log(description);
Here we clearly have a repetition of code. Each block of code is doing exactly the same thing. The only difference with each block are the properties. The logic is identical and the result of each block is of the same type - a string. The code would grow 6 lines with every car we add. This is not DRY!
class Car { constructor(make, colour, isHybrid) { this.make = make; this.colour = colour; this.isHybrid = isHybrid; this.isHybridText = isHybrid ? "is a hybrid" : "is not a hybrid"; } describe = () => `This car is an ${this.make} and it is ${this.colour}. This car ${this.isHybridText}`; } let describeCars = (cars = []) => { cars.forEach((car) => { console.log(car.describe()); }); } let cars = [ new Car("Audi", "Red", false), new Car("Ford", "Blue", true), new Car("Honda", "Black", true), new Car("Lamborghini", "Black", false), new Car("Porsche", "Yellow", false), new Car("Dodge", "Green", true), ]; describeCars(cars);
Now using a reusable class and a some iteration, we are able to reuse the same code again and again. Our code will now only grow with a single line for every car we add. This is now DRY, we should always be thinking of DRY.
The KISS Principle stands for “Keep it simple, stupid” and relates to overly complex code. The smaller and simpler our methods are, the more manageable our code will be. Complex code is prone to bugs, so by keeping it simple we remove the likelihood of bugs and we make our code much more friendly to work with and read.
let convertIntToDay = (dayNumber = 0) => { let result = ""; if(dayNumber === 0) { result = "Monday"; } else if(dayNumber === 1) { result = "Tuesday"; } else if(dayNumber === 2) { result = "Wednesday"; } else if(dayNumber === 3) { result = "Thursday"; } else if(dayNumber === 4) { result = "Friday"; } else if(dayNumber === 5) { result = "Saturday"; } else if(dayNumber === 6) { result = "Sunday"; } return result; } let day = convertIntToDay(2); console.log(day);
This example uses multiple if statements to handle what is essentially just an index lookup. There is far more logic here than there needs to be. This is the kind of code that is in breach of the KISS principle.
We could use a switch to make this read a bit easier, but simpler still, we could use the index directly to find the matched day. Arrays in JavaScript are zero indexed, so if our case begins with a zero we could get the same result by using the passed in number as an index position for the array.
let convertIntToDay = (dayNumber = 0) => { let days = [ "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday" ] if(days.length < dayNumber) { throw new Error("Must be in range of days"); } return days[dayNumber]; } let day = convertIntToDay(2); console.log(day);
Removing all the unnecessary logic reveals a much cleaner solution, easier to understand and read. We are relying instead on the index of the array in order to find the matched day. This is a clear example of the KISS principle and what to look out for when considering existing code or designing new code.
The YAGNI principle stands for “You ain’t gonna need it” and aims to remove unnecessary code and features. We should not be adding complexity just because it might come in handy in the future. Yes we should always consider future proofing our code, but be careful, we should not add extra weight where it is not needed. For example, adding additional properties that are not being used - “you ain’t gonna need it”.
class Person { constructor(name) { this.name = name; } name = ""; age = 0; sex = ""; occupation = ""; } let person = new Person("James"); console.log(person.name);
In this example we see there are more properties than we need, they are not being used in the constructor and they are not being accessed elsewhere. They appear to be there “just in case”. We do not need them.
class Person { constructor(name) { this.name = name; } } let person = new Person("James"); console.log(person.name);
Now having removed the unnecessary properties we have a much cleaner solution, comprising only of the properties we need. This is following the YAGNI principle and we should be using this principle where possible.
Only implement what we need for the immediate requirement and not what we think we might need in the future. This allows for faster development and simpler, lighter code.


Hello, I'm Nick!
About me 🤓
Hello 👋 I’m Nick,
I currently live in the US - Milwaukee, WI 🇺🇸
Customer Service Professional by day ☀, and a Sim Racer by night 🌙. I am passionate about all things technology and enjoy finding innovative solutions to complex challenges.
Before diving into the tech industry, I worked in physically demanding Warehouse jobs, but it was not fulfilling. I decided to switch careers to IT, which I have been thriving in ever since. In my free time, I enjoy exploring the world of Real Estate investing and the thrill of Sim Racing. I am also keenly interested in staying up-to-date on security-related topics in the technology industry. I prefer to consume media through podcasts (~20%) and YouTube (~80%) to avoid pesky TV commercials.
A few fun facts about me:
- I am an only child, which has taught me how to be independent. 👶
- I am terrified of centipedes, which always gives my friends a good laugh. 🐛
- My dream job is to become a successful entrepreneur, working remotely to provide for my family and myself. 🧑💼
- I have a guilty pleasure - deep-fried cheese curds! 🧀
I'm proud of my experiences and accomplishments, which have helped me to develop a unique set of skills and expertise. If you're interested in collaborating with me on an exciting Real Estate venture or sim racing challenge, I'd love to hear from you. (Reach out here )
Thanks for stopping by, and I look forward to connecting with you soon!


top
|
up
|
prev
|
next
GenObject Abstract Class
Definition at line
47
of
GenObject.hpp
Constructors
GenObject
()
Member Functions
void
*
GetType
()
void
Load
(
Emitter
& emitter,
OperationFlags
flags)
pure virtual
void
SetType
(
void
* type_)
void
Store
(
Emitter
& emitter,
OperationFlags
flags)
pure virtual
Member Variables
void
*
type
Constructor Details
GenObject Constructor
cmajor::ir::GenObject::GenObject()
Definition at line
11
of
GenObject.cpp
:
11
:
type
(
nullptr
)
12
{
13
}
Declaration at line
50
of
GenObject.hpp
Member Function Details
GetType Member Function
void
* cmajor::ir::GenObject::GetType()
Definition at line
55
of
GenObject.hpp
:
55
{
return
type
;
}
Load Member Function
void
cmajor::ir::GenObject::Load(
Emitter
& emitter,
OperationFlags
flags)
pure virtual
Definition at line
52
of
GenObject.hpp
Derived class overrides:
cmajor::ir::NativeValue::Load
SetType Member Function
void
cmajor::ir::GenObject::SetType(
void
* type_)
Definition at line
54
of
GenObject.hpp
:
54
{
type
=
type_
;
}
Store Member Function
void
cmajor::ir::GenObject::Store(
Emitter
& emitter,
OperationFlags
flags)
pure virtual
Definition at line
53
of
GenObject.hpp
Derived class overrides:
cmajor::ir::NativeValue::Store
top
|
up
|
prev
|
next


| software_version_and_target_device | |||
| beta | FALSE | build_version | 2258646 |
| date_generated | Tue Nov 13 22:09:33 2018 | os_platform | WIN64 |
| product_version | XSIM v2018.2 (64-bit) | project_id | ff3eb27d74514c27a4d7e091e02111b8 |
| project_iteration | 77 | random_id | a116c827-e290-47be-b9a1-d6946223b46d |
| registration_id | a116c827-e290-47be-b9a1-d6946223b46d | route_design | FALSE |
| target_device | not_applicable | target_family | not_applicable |
| target_package | not_applicable | target_speed | not_applicable |
| tool_flow | xsim_vivado |
| user_environment | |||
| cpu_name | Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz | cpu_speed | 2400 MHz |
| os_name | Microsoft Windows 8 or later , 64-bit | os_release | major release (build 9200) |
| system_ram | 8.000 GB | total_processors | 1 |
| vivado_usage |
| xsim | |||||||||
| |||||||||
|


General
Translation
Set what language pair will be used for word translation.
Subtitles languages
Mark what languages will be used for subtitles search.
Set what language pair will be used for word translation.
Mark what languages will be used for subtitles search.
Flowplayer fork based on Flowplayer


(G)I-DLE look stunning for their new 'LION' Music Video
by Kang_Hujin(G)I-DLE released a MV for Lion.
Neverlands are truly happy to watch another masterpiece made by (G)I-DLE.
(G)I-DLE released a MV for Lion.
Neverlands are truly happy to watch another masterpiece made by (G)I-DLE.


By clicking this button user will be provided with a list of available spots.
By clicking this button user will be provided with directions from his current place to the current parking spot.
By clicking this button the user will no longer stay on the current spot.
The user will be provided with a list of available spots and their locations with the possibility to exchange his current spot for the new one.
Successfully logged out!


Before Change
net.eval()
params_queues = [mp.Queue(maxsize=1) for _ in range(PROCESSES_COUNT)]
rewards_queues = [mp.Queue(maxsize=ITERS_PER_UPDATE) for _ in range(PROCESSES_COUNT)]
workers = []
for idx, (params_queue, rewards_queue) in enumerate(zip(params_queues, rewards_queues)):
proc = mp.Process(target=worker_func, args=(idx, params_queue, rewards_queue, args.cuda))
proc.start()
workers.append(proc)
print("All started!")
for step_idx in range(100000):
// broadcasting network params
params = net.state_dict()
for q in params_queues:
q.put(params)
// waiting for results
t_start = time.time()
batch_noise = []
batch_reward = []
results = 0
batch_steps = 0
batch_steps_data = []
while True:
for idx, q in enumerate(rewards_queues):
if not q.empty():
reward = q.get_nowait()
np.random.seed(reward.seed)
noise, neg_noise = sample_noise(net)
batch_noise.append(noise)
batch_reward.append(reward.pos_reward)
batch_noise.append(neg_noise)
batch_reward.append(reward.neg_reward)
results += 1
batch_steps += reward.steps
batch_steps_data.append(reward.steps)
// print("Result from %d: %s, noise: %s" % (
// idx, reward, noise[0][0, 0, 0:1]))
if results == PROCESSES_COUNT * ITERS_PER_UPDATE:
break
time.sleep(0.1)
After Change
net.eval()
params_queues = [mp.Queue(maxsize=1) for _ in range(PROCESSES_COUNT)]
rewards_queue = mp.Queue(maxsize=ITERS_PER_UPDATE)
workers = []
for idx, params_queue in enumerate(params_queues):
proc = mp.Process(target=worker_func, args=(idx, params_queue, rewards_queue, args.cuda))


Measure single-storage water supply system performance using resilience, reliability, and vulnerability metrics; assess storage-yield-reliability relationships; determine no-fail storage with sequent peak analysis; optimize release decisions for water supply, hydropower, and multi-objective reservoirs using deterministic and stochastic dynamic programming; generate inflow replicates using parametric and non-parametric models; evaluate inflow persistence using the Hurst coefficient.
| Version: | 1.1.5 |
| Imports: | gtools, stats, graphics |
| Published: | 2016-04-14 |
| Author: | Sean Turner [aut, cre], Jia Yi Ng [aut], Stefano Galelli [aut] |
| Maintainer: | Sean Turner <swd.turner at gmail.com> |
| License: | GPL-2 | GPL-3 [expanded from: GPL (≥ 2)] |
| URL: | https://cran.r-project.org/package=reservoir |
| NeedsCompilation: | no |
| Citation: | reservoir citation info |
| CRAN checks: | reservoir results |
| Reference manual: | reservoir.pdf |
| Package source: | reservoir_1.1.5.tar.gz |
| Windows binaries: | r-devel: reservoir_1.1.5.zip, r-release: reservoir_1.1.5.zip, r-oldrel: reservoir_1.1.5.zip |
| OS X binaries: | r-release: reservoir_1.1.5.tgz, r-oldrel: reservoir_1.1.5.tgz |
| Old sources: | reservoir archive |
Please use the canonical form https://CRAN.R-project.org/package=reservoir to link to this page.


- IMPORTANT NOTE
- The interfaces defined in this package are bound to change. Kindly treat the interfaces as work in progress. Release notes/user guide list the additional limitation/restriction of this module/interfaces. See also TI Disclaimer.
Chip Support Library(CSL) provides a no-OS platform support for multi-core SoCs. CSL provides CSL Functional Layer (CSL-FL) libraries and CSL Register Layer (CSL-R) along with peripheral/board level sample/demo examples that demonstrate the capabilities of the peripherals.
Also refer to top level user guide for detailed features, limitations and usage description.
The below listed is a superset of all the CSL-FL modules, for certain SDK release, it may include only a subset of these modules.
The CSL-FL includes the following modules/drivers
- HW Type Defines (See HW Type Defines)
In-line functions required to read/write values from/to the hardware registers
- IP's
- Video Module
- System Module
- Safety/Security Module
- Serial Module
- Memory Controller
- Memory/Storage
- SOC Module
This Module contain the SOC level configuration API's such as cross bar configuration, cross bar defines, SOC defines
- Device Common API's (See Device Common API)
- TDA2EX (See SOC_TDA2EX)
- TDA2PX (See SOC_TDA2PX)
- TDA2XX (See SOC_TDA2XX)
- TDA3XX (See SOC_TDA3XX)
- ARCH Module
This Module contain the core specific configuration API's such as Interrupt, Cache, ECC


Birmingham gang bosses jailed for smuggling drugs in frozen chicken
by LBCTwo members of a Birmingham organised crime group who used frozen chickens to smuggle drugs into the UK have been jailed.
Wasim Hussain and Nazrat Hussain set up a series of front companies involved in the importing of chicken to the UK from the Netherlands.
However, the real purpose of the companies was to import millions of pounds worth of class A drugs to the UK.
On several occasions, heroin and cocaine worth around £5 million was seized hidden in chicken shipments.
The National Crime Agency identified 16 chicken shipments containing class A drugs between 2016 and 2017.
Following each seizure, the men set up a new company with a new name to try and cover their tracks.
The men would use genuine shipping companies to move frozen chicken loads from Rotterdam to distribution hubs when the chicken would be collected by gang members.
Following the police interception of first two chicken shipments and the arrest of two gang members, the gang switched tactics.
They employed the services of two corrupt baggage handlers to collect three kilos of cocaine off a flight from Brazil to Heathrow, all while continuing to smuggle drugs in their chicken shipments.
They also recruited Mohammed Shabir, a Birmingham-based meat supplier, to help.In June 2017 another shipment was dispatched from the Netherlands, but when it arrived in Birmingham minus the drugs the group knew they had been caught.
Wasim Hussain rang his main Dutch criminal contact in panic, telling him “throw your phone, throw everything, throw the SIM away.”
The two men were arrested shortly after.
Nazrat Hussain pled guilty to three counts of conspiring to import class A drugs.
Brothers Manjinder Singh Thakhar and Davinder Singh Thakhar, along with Mohammed Shabir also all pleaded guilty to participating in the activities of an organised crime group.
Following a five week trial at Birmingham Crown Court Wasim Hussain was found guilty of conspiring to import a class A drug.
On Friday Nazrat Hussain was sentenced at the same court to 29-and-a-half years in prison, while Wasim Hussain was jailed for 14 years and four months.
Mohammed Shabir, Manjinder Singh Thakhar and Davinder Singh Thakhar will also be sentenced on 23 January 2020.
Colin Williams, the NCA Branch Operations Manager, said: “Throughout the course of this investigation, which has gone on for more than three years, we have systematically dismantled an organised crime group that was involved in the importation and distribution of class A drugs across the West Midlands.
“As well as drugs, the gang also attempted to source firearms, presumably to be used to threaten others in support of their criminality.
“The investigation has uncovered links to criminal networks in London and the Netherlands, and our partnership with the Dutch police was crucial.
He continued: “We worked our way through the group until we managed to reach the two men at the very top, Wasim Hussain and Nazrat Hussain.
“As we have shown in this case, the NCA will use the full range of its capabilities to comprehensively target and disrupt those involved in organised criminal activity.
“In total more than 98 years of jail sentences have been handed out, and with these men behind bars communities in the West Midlands and beyond are safer.”


/**
* ActionFieldLayouts are used with OO.ui.FieldsetLayout. The layout consists of a field-widget, a button,
* and an optional label and/or help text. The field-widget (e.g., a {@link OO.ui.TextInputWidget TextInputWidget}),
* is required and is specified before any optional configuration settings.
*
* Labels can be aligned in one of four ways:
*
* - **left**: The label is placed before the field-widget and aligned with the left margin.
* A left-alignment is used for forms with many fields.
* - **right**: The label is placed before the field-widget and aligned to the right margin.
* A right-alignment is used for long but familiar forms which users tab through,
* verifying the current field with a quick glance at the label.
* - **top**: The label is placed above the field-widget. A top-alignment is used for brief forms
* that users fill out from top to bottom.
* - **inline**: The label is placed after the field-widget and aligned to the left.
* An inline-alignment is best used with checkboxes or radio buttons.
*
* Help text is accessed via a help icon that appears in the upper right corner of the rendered field layout when help
* text is specified.
*
* @example
* // Example of an ActionFieldLayout
* var actionFieldLayout = new OO.ui.ActionFieldLayout(
* new OO.ui.TextInputWidget( {
* placeholder: 'Field widget'
* } ),
* new OO.ui.ButtonWidget( {
* label: 'Button'
* } ),
* {
* label: 'An ActionFieldLayout. This label is aligned top',
* align: 'top',
* help: 'This is help text'
* }
* );
*
* $( 'body' ).append( actionFieldLayout.$element );
*
* @class
* @extends OO.ui.FieldLayout
*
* @constructor
* @param {OO.ui.Widget} fieldWidget Field widget
* @param {OO.ui.ButtonWidget} buttonWidget Button widget
* @param {Object} config
*/
OO.ui.ActionFieldLayout = function OoUiActionFieldLayout( fieldWidget, buttonWidget, config ) {
// Allow passing positional parameters inside the config object
Eif ( OO.isPlainObject( fieldWidget ) && config === undefined ) {
config = fieldWidget;
fieldWidget = config.fieldWidget;
buttonWidget = config.buttonWidget;
}
// Parent constructor
OO.ui.ActionFieldLayout.parent.call( this, fieldWidget, config );
// Properties
this.buttonWidget = buttonWidget;
this.$button = $( '<span>' );
this.$input = this.isFieldInline() ? $( '<span>' ) : $( '<div>' );
// Initialization
this.$element
.addClass( 'oo-ui-actionFieldLayout' );
this.$button
.addClass( 'oo-ui-actionFieldLayout-button' )
.append( this.buttonWidget.$element );
this.$input
.addClass( 'oo-ui-actionFieldLayout-input' )
.append( this.fieldWidget.$element );
this.$field
.append( this.$input, this.$button );
};
/* Setup */
OO.inheritClass( OO.ui.ActionFieldLayout, OO.ui.FieldLayout );
|


|
Syntax for a variable declaration: name DB value name DW value DB - stays for Define Byte. DW - stays for Define Word. name - can be any letter or digit combination, though it should start with a letter. It's possible to declare unnamed variables by not specifying the name (this variable will have an address but no name). value - can be any numeric value in any supported numbering system (hexadecimal, binary, or decimal), or "?" symbol for variables that are not initialized. |
ORG 100h MOV AL, var1 MOV BX, var2 RET ; stops the program. VAR1 DB 7 var2 DW 1234h |
ORG 100h DB 0A0h DB 08h DB 01h DB 8Bh DB 1Eh DB 09h DB 01h DB 0C3h DB 7 DB 34h DB 12h |
BYTE PTR [BX] ; byte access. or WORD PTR [BX] ; word access.assembler supports shorter prefixes as well:
ORG 100h MOV AL, VAR1 ; check value of VAR1 by moving it to AL. LEA BX, VAR1 ; get address of VAR1 in BX. MOV BYTE PTR [BX], 44h ; modify the contents of VAR1. MOV AL, VAR1 ; check value of VAR1 by moving it to AL. RET VAR1 DB 22h END |
ORG 100h MOV AL, VAR1 ; check value of VAR1 by moving it to AL. MOV BX, OFFSET VAR1 ; get address of VAR1 in BX. MOV BYTE PTR [BX], 44h ; modify the contents of VAR1. MOV AL, VAR1 ; check value of VAR1 by moving it to AL. RET VAR1 DB 22h END |
name EQU < any expression >
|
k EQU 5 MOV AX, k |
| MOV AX, 5 |


You need to enable JavaScript to run this app.
About
Current Config
collections
Current collection:
Current Route Variant:
Set collection base
Set collection user2
Routes
Alerts


Hey! Welcome to Ghost, it's great to have you :)
We know that first impressions are important, so we've populated your new site with some initial Getting Started posts that will help you get familiar with everything in no time. This is the first one!
There are a few things that you should know up-front:
-
Ghost is designed for ambitious, professional publishers who want to actively build a business around their content. That's who it works best for. If you're using Ghost for some other purpose, that's fine too - but it might not be the best choice for you.
-
The entire platform can be modified and customized to suit your needs, which is very powerful, but doing so does require some knowledge of code. Ghost is not necessarily a good platform for beginners or people who just want a simple personal blog.
-
For the best experience we recommend downloading the Ghost Desktop App for your computer, which is the best way to access your Ghost site on a desktop device.
Ghost is made by an independent non-profit organisation called the Ghost Foundation. We are 100% self funded by revenue from our Ghost(Pro) service, and every penny we make is re-invested into funding further development of free, open source technology for modern journalism.
The main thing you'll want to read about next is probably: the Ghost editor.
Once you're done reading, you can simply delete the default Ghost user from your team to remove all of these introductory posts!


Reverse String
IS Palindrome
Change Bg
Check out some Algorithms
Reverse A String
Check If A String Is Palindrone
Click
test


{{HospitalProfileCtrl.hospital.name}}
{{HospitalProfileCtrl.hospital.email}}
{{HospitalProfileCtrl.hospital.address}}
{{HospitalProfileCtrl.hospital.hospitalurl}}
{{HospitalProfileCtrl.hospital.phonenum}}
Edit Information:
Hospital name
Hospital email
Location
Phone Number
Website
Hospital Hours
{{schedule.name}} :
You are hosting an event on {{event.time | date}}, at {{event.time | date: 'shortTime'}}.
{{event.donors.length === 1 ? '1 donor is' : event.donors.length +' donors are'}} currently confirmed to attend.
{{review.content}}


This year's competitive stapling event features athletes from 13 countries and split between two categories.
Athletes will be timed in stapling two reams worth of paper in groups of 14 sheets of paper using a standard-issued stapler. The paper must be hand-counted and stapled using a non-automated stapler by individual. This is not a team-event. There will be age classes in this event, and medals will be awarded by age class:
In this event, athletes will compete to see how can staple the thickest packet of paper using a standard-issued stapler. Should the staple not protrude through the back of the last sheet of paper, the athlete will be disqualified. This is certainly a risky event, as there are no second chances. One staple--that's all each athlete gets. For this event, there are weight brackets by gender:


Example using jQuery RPiJS plugin
Cpu
Usage:
%
Uptime:
Temperature:
°C
Memory
Total:
Used:
Swap:
Swap used:
Network
Storage
Device
Mount
Filesystem
Size
Use
Total throughput


About me.
Thank’s for checking out my website! My name is Andrew Bretnall and I am a Product Designer from New Jersey. I graduated from the Savannah College of Art and Design and am currently taking a coding bootcamp with The University of Pennsylvania. I’ve had the pleasure of designing for Fiserv as a UX Design Intern and now am looking to become a UX Engineer.


11
The LORD's Love for Israel
1 When Israel was a child, I loved him,
and out of Egypt I called my son.
2 The more they were called,
the more they went away;
they kept sacrificing to the Baals
and burning offerings to idols.
3 Yet it was I who taught Ephraim to walk;
I took them up by their arms,
but they did not know that I healed them.
4 I led them with cords of kindness,
with the bands of love,
and I became to them as one who eases the yoke on their jaws,
and I bent down to them and fed them.
5 They shall not return to the land of Egypt,
but Assyria shall be their king,
because they have refused to return to me.
6 The sword shall rage against their cities,
consume the bars of their gates,
and devour them because of their own counsels.
7 My people are bent on turning away from me,
and though they call out to the Most High,
he shall not raise them up at all.
8 How can I give you up, O Ephraim?
How can I hand you over, O Israel?
How can I make you like Admah?
How can I treat you like Zeboiim?


It is great being the funny dad. The punch lines are perfect to get my little ones giggling and the older “cooler” kids grinning and rolling their eyes. Dad Jokes has helped me improve the calibre of my jokes and I am now a lot more popular with not just my own kids but their friends as well.


The wizarding world is filled with memorable characters.
Houses. Hogwarts is divided into four houses, each bearing the last name of its founder: Godric Gryffindor, Salazar Slytherin, Rowena Ravenclaw and Helga Hufflepuff.
From the original book series to the movie franchise and the spin-off video games, the world of Harry Potter has captured the minds of millions of fans across the globe. Indeed, Harry Potter has been imprinted into our modern-day culture, with many of the magical spells and charms used in the book now known around the world.
Harry Potter is a series of novels by J.K. Rowling. It is about a young boy named Harry Potter and his adventures as he attends Hogwarts School of Witchcraft and Wizardry, learns how to perform magic and comes face to face with his archenemy, Lord Voldemort.


Go to index page.
gifcolor
A program to generate color test patterns. Feed it a color map file (as
generated, say, by the -s otion of GifClrMp) and it will generate a GIF
containing lines of the form
Color %-3d: [%-3d, %-3d, %-3d]:
where the first number is the zero-based color index, and the triple is the
index's [Red, Green, Blue] value. There will be one such line for each color.
Each line will be set in a simple 8x8 font in the color it describes; thus,
any lines corresponding to the GIF's background color will be blank.
Usage:
gifcolor [-q] [-b Background] [-h] <ColorMapFile
As gifcolor can generate huge amounts of data, ^C will kill it, but 'q' will
stop only the printing (of one of -e, -z, -p), while file integrity will still
be checked.
Memory required:
Line.
Options:
- [-q]
- Quiet mode. Defaults off on MSDOS, on under UNIX. Controls printout
of running scan lines. Use -q- to invert.
- [-b]
- Set the image's backround color to a given numeric index.
- [-h]
- Print one line of command line help, similar to Usage above.
Author:
Gershon Elber
Eric S. Raymond <esr@snark.thyrsus.com>