1915 became the year in which he became recognized as America’s quintessential poet; in August, the Atlantic Monthly published what is perhaps Frost’s most well-known work, “The Road Not Taken.”
Over the past thirty-five years alone, language from Frost’s poem has appeared in nearly two thousand news stories worldwide, which yields a rate of more than once a week. In addition, “The Road Not Taken” appears as a title, subtitle, or chapter heading in more than four hundred books by authors other than Robert Frost, on subjects ranging from political theory to the impending zombie apocalypse.
My poems—I should suppose everybody’s poems—are all set to trip the reader head foremost into the boundless. Ever since infancy I have had the habit of leaving my blocks carts chairs and such like ordinaries where people would be pretty sure to fall forward over them in the dark. Forward, you understand, and in the dark.
The premise for this project stems from the popularity of Robert Frost's poetry, as well the recurring topic that the popular poem, "The Road Not Taken", is frequently misread or misunderstood by the general public. Seeing that little to no work has been done on Robert Frost's poetry from a Digital Humanities approach, it would be interesting to examine Frost's poetry through the lens of digital textual analysis approaches.
The collections that are used for this project include:
This project begins with the hypothesis that there is something that stands out about Frost's "The Road Not Taken" from others which may correlate with its popularity. We will be examining the poem at both the structural level, assisted by textual analysis tools, and statistical analysis from tone scores retrieved from Natural Language Processing performed by IBM Watson.
While this project may have a focus on "The Road Not Taken", we will be looking at all of Frost's work (that was retrieved for this study) in the hopes that there will be interesting patterns across the different poems which can reveal new insight into Frost's poetry.
To begin the study, I had to first retrieve and build the corpus. There's an online source for a complete collection of Robert Frost's poetry in entirety. However, it wasn't properly OCR'd, and I had to look for a way to extract data in a way that can be used separately rather than in one contiguous text form.
I used Bartleby's database of poetry items, and thankfully due to the way the site has been organized, it was easy to pull out poems from individual publications with a simple script.
For the next part, I used a series of NodeJS scripts to prepare my documents for generating a corpus.
I scrubbed out the poems' whitespaces so as to extract the stanzas in their pre-existing formatted form (something I was unable to do with the PDF's OCR text corpus).
The poems are titled according to the format "Year - Title"
so as to prepare the data should there arise a need for a timeline to be drawn.
The reason I wanted to build the poem samples separately was due to the intentions of using Voyant Tools to run a corpus analysis on the text. By having the poems in separate documents, it was clearer to view the document differences in Voyant.
You may refer to the scripts used to generate the corpus and for data preparation here.
Download: Corpus
As one of the most extensive textual analysis tools built for the purposes in Digital Humanities, I felt that it was most appropriate to begin inspecting the poetry works using Voyant Tools as a first cut at the data set that I've retrieved. It is in the hopes of using Voyant that either interpretation or word count analysis will reveal more about the corpus that we are investigating.
Should Voyant reveal any shortcomings in the process, I will take the steps necessary to evaluate what other parameters should be supplemented for more extensive approaches at examining the corpus.
To add on to another dimension of the text analysis, I was inspired to use the IBM Watson's Natural Language Understanding API to process the poems at scale.
The IBM Watson's API is useful because it provides a comprehensive psycholinguistic model to analyse the text we are supplying the model. In doing so, I am able to retrieve scores on the tone of the document, which is backed by some very heavy research in language tones. The tones are evaluated in three aspects, Emotional, Social, and Language tones, which are described in detail on Understanding your tone score.
To make use of this service, I made use of the pre-existing poem files and fed them to the IBM Bluemix Watson Services, which can be found in this script.
With Watson, I scoped the level of analysis to be at document level rather than at sentence level. This is so that we can focus more on the individual poems as a whole rather than go deep into the granular sentence level to detect variances in tone. Of course, doing so at the sentence level is also possible, but will require a careful setup for it to yield meaningful, useful results to analyse at a high level.
The API also offered to extract keywords from each poem. I limited the response to return 10 top keywords according to their sentiment scores, hoping that it may be used at some point.
The most immediate thing was to see if there were any trends between the words used across the different collections. In the following Cirrus visualisations of the words used per document/corpus, a term scale of 85 was used to see if there are any repetitive words used. This set of words are also retrieved after applying a filter from the stop words list provided by Voyant Tools.
Arguably, much can be done from these word clouds. For instance, the top/most frequently used words can be used in forming n-grams to perform an n-grams analysis through Google Books' N-gram viewer to see if any of these terms yield an increase in popularity over certain time periods, so as to investigate if a correlation exists between the words used in "The Road Not Taken" and in popular culture (in books).
At a glance, we can only tell that The Road Not Taken has a set of very unique vocabulary when looked at singularly. It is hard to tell if there is any real impact in those words used in The Road Not Taken compared across the entire collection of poems retrieved. We can tell based on the frequency of words used in the respective collections and the entire corpus that the words frequently used are simple monosyllablic words. Beyond that, there is not much else we can gather from the word clouds.
Voyant has a Document summary feature that returns a statistics on each poem. However, the approach of counting words and sentences may not be useful when looking at a poem's structure. As such, I had to write my own word count evaluation of the poetry from the perspective of the stanzas, lines, and words instead of sentences (which is also taken into consideration).
I went ahead to extend on the textual statistics on each poem stored it back into JSON format.
With the additional parsing and data manipulation, we get the following new attributes for each poem:
From these additional parameters, we're able to get even more interesting ratios to work with, such as:
All of which are definitely more relevant and consumable with regards to textual analysis on poetry.
With the data table now generated on this page, we are able to quickly learn a few things about the poetry. Displaying only 10 results, sorting the order ascendingly or descendingly will give you a perspective of the top or bottom 10 poems according to the metric we want to find out by.
For instance, If we want to know which poem has the greatest number of words per stanza, we're able to sort by that column and we find out a few interesting details about those with a higher word density. There are other things we can do rather quickly with this table that reveal some preliminary insight into the statistics across the entire collection.
With the data now at hand, let's investigate through visualising this set of data to see if any patterns emerge.
The form below controls the visualisation to its right. Tweak the values below to visualize a new graph. Slice and dice the parameters to see how each discrete property relates to the other poems by Frost.
The following graph below is generated through Watson's Natural Language Understanding API, and yields the overall sentiment scores for the corpus.
The sentiment scores range from -1 to 1, where a positive value indicate a better sentiment, and a negative value indicating a poorer sentiment in terms of the tone of the document. Each document was sent to be scored by the machine, which is then analyzed based on the textual contents of the document as a whole instead of using targeted phrases.
When ordered by year_published
, the poems spanning from 1909 to 1922 generally show a trend
of negative sentiment. The sentiment score was returned on the overall document that was passed over to the
Watson API for analysis. Frost's "The Road Not Taken" is not spared from the general sentiment of negativity
(according to Watson) as well, with a sentiment score of -0.685
.
With the whisker plot shown on the left, we can see that Frost's "The Road Not Taken" lies beyond the lower bound of the overall negative sentiments of all his poetry written in this corpus (and is also in fact the most negative in sentiment scores).
This makes "The Road Not Taken" an outlier in terms of its negative sentiment, as it is the only outlier in the set of
negative sentiments. This makes "The Road Not Taken" more negative in its sentiment score than the others with a score of
-0.68531
.
It thus seems that "The Road Not Taken" is an unusually bitter piece written, albeit scored by a machine in terms of detecting negativity in tone.
"The Road Not Taken" is preset as the default poem to display for its tone analysis scores. In each of the panels, it reveals some information
about what the Watson Tone Analyzer service has found on the contents of the poem. Scores greater than 0.5
indicate a greater likelihood
of the tone property, and vice versa.
In this section, I have also provided a switch for readers to switch between all poetry that can be obtained from this corpus, beginning from 1909 to 1922. Select another poem to observe the changes in the tone scores. Results from these three panels can be compared to the boxplots generated below to compare the tone scores against the collection of poems at large. For more information on what the scores mean: Understand your tone score.
Looking at the boxplots for each of the emotional tone vectors retrieved from the data, we can see that there is very little variance between the Anger and Disgust emotions, as well as the fact that the range of scores also indicate that Frost's poetry is also not reflective of those tones in his expression.
On the other hand, there is greatest variance in Fear and Joy across his poems. "The Road Not Taken" has been deemed unlikely to be conveying any of these emotions according to the legend (scores of less than 0.5 indicates that it is unlikely) as seen from above in the Emotional Tone panel.
It was interesting to observe that none of the poems were scored for Confidence in terms of the language tone, which implies that there is no evidence of confidence in the tone of the poems.
On the other hand, tentativeness has the largest variance, which reveals a varying degree of inhibition that Frost has in his language expressed in the poems. As the bulk of the scores appear to be a low value score (less than 0.5), implying that there is little evidence of these tones in the poetry, Nothing conclusive can be said about these language tone scores.
Lastly, the social tones in his poems are analysed according to the Big Five personality model.
While it may seem like a long shot, we can infer the characteristics of Frost's personality through his text based on the spread of these results. We see that there is some likely evidence of Openneess and Agreeableness in Frost's poetry, which stand out more than the other personality traits.
Structurally, it does not seem like anything much stands out from the poem compared to the others. As it stands, it seems that I am unable to conclude on this point, which may be because I may not be looking at the right parameters.
It would be presumptuous to make sweeping statements about "The Road Not Taken" based on the findings that this study has provided and shown. While the poem may have stood out in terms of its negative sentiment score, each and every poem written by Frost should not be trivialised to a score. It was also interesting to note the differences that "The Road Not Taken" has with the rest of the poems as a whole, perhaps more can be done by segmenting according to their collections, or perhaps across time periods (maybe according to the year of publishing) to gain a more granular understanding of the differences in the poems.
As Digital Humanities is like an 'open sandbox' field of study, there seems to be a lack of best practices and documentation going around for how to approach the analysis of literary text (in this case). Most tools that are provided by scientists and DH scholars mostly tell you what they are for, but not quite thoroughly on how to use them effectively. For instance, with Voyant Tools, unless I have had the literary training to approach the subject, the visualisations and content distilled from the corpus meant very little to me, and it was also hard to spot any patterns unless further manipulation is performed (as evidenced in the course of this project).
Visualisations work much better on quantitative sets of data, and it was also hard to visualize some sets of the data in terms of multiple parameters (for example, comparing words per line to, perhaps the year of publishing to observe any trends in verbosity) because the published year of the book is not distinctively discrete (many published in the same year). It was also hard to discern what would be a good approach to choose parameters for analysis because properties like word count seem so arbitrary and lack meaning unless applied to an appropriate context.
It would perhaps been better should I have been more rigorously grounded in any of the relevant areas in this DH study. These areas include the domains of statistical analysis, and literary training. My main concern was that I was trying hard not to force the data in any way to fit the hypothesis I was testing for. There would undoubtedly be more that I could have looked into, perhaps with fairer comparison methods to gain a more objective point of view on the corpus. That said, I am also sure that there may be biases that will be implicated.
I tried adopting a storytelling approach to this project. I assumed some basic premises before setting off on this journey of discovery based on the text corpus and statistic analysis on the Watson data. Then I went on to bring the reader (you!) through my thought processes and the methods I've used to visualise and investigate the corpus. I found this to be an interesting manner of representing my stream of consciousness when looking at the results of the textual analysis tools, but it was also risky should there be inconclusive results from the findings.
Choosing a topic to look into has probably been the hardest part for this project since the DH methods are so broadly applied, and it seemed as though I had to be careful not to treat the digital methods as a hammer to every nail.There is definitely more that one can do with the data, even from such a small scope of 90 poems. With more poems (and text) to be put through such methods, I am sure there can be more insights to be derived from such works.
From the structural analysis point of view, I could have done more in terms of looking at poetry forms in a stricter manner. The groups of form, primarily, the Lyric, Narrative, and Dramatic forms were not explored widely enough in this DH project, and I could have gone deeper to look into the stanzaic, fixed, and continuous forms of the poetry. Unfortunately, it was difficult or impossible to find a database out there which has already performed such analysis on the poetry for me to perform other visualisations for comparison purposes. This may perhaps be a suitable extension in this study.
| Lyric | My November Guest | Mowing | A Late Walk |
| Narrative | Out, Out | Love and a Question | Brown's Descent |
| Dramatic | Death of the Hired Man | Home Burial | The Witch of Coos |
|
|
|||
| Couplet | The Secret Sits | The Tuft of Flowers | A Minor Bird |
| Tercet (Triplets) | Acquainted with the Night | A Star in a Stoneboat | Provide, Provide |
| Quatrain | Devotion | Stopping by Woods | Good Hours |
| Quintet | My November Guest | The Road Not Taken | Bond and Free |
| Sestet | Spring Pools | The Freedom of the Moon | Closed for Good |
| Octave | Nothing Gold Can Stay | Two Tramps in Mud Time | Love and a Question |
|
|
|||
| Sonnet | Design | Mowing | The Silken Tent |
| Blank Verse | Mending Wall | Birches | Out, Out |
|
|
Storm Fear | After Apple-Picking | Mending Wall |
The Watson API also provided some interesting results in terms of its keyword analysis as shown in the table above.
Keywords are not retrieved the way it was done on Voyant Tools, whereby words are looked at singularly. Rather, it seems to have generated n-grams (up to 2) of the keywords found in each poem (according to the relevance to the overall body of the poem). The relevance scores for each term are ranked for each of the 10 terms (I specified a return of the top 10 most relevant terms, but the API service is able to accommodate more), and a sentiment value, amongst others like the emotion tone scores for the keywords are also provided in the table above, much like what we have gathered in the Tone Analysis section.
By exploring this set of keywords further, we may be able to find more useful and interesting relationships with the overall corpus as compared to plainly using Voyant Tools. For the scope of this project, efforts to pursue this aspect of the analysis is too ambitious and excessive to undertake. The keyword analysis offered some sentiment analysis on the words used and their tones, which could also have been useful to analyse broadly to investigate if there exists other patterns which may reveal more insight.


What? Why? When?
locache.js is a simple framework to help you cache objects on the client-side. It's not a replacement for HTTP caching, and often that is a better idea. Rather it allows you to cache JavaScript objects ( anything that is JSON serialisable) for re-use or offline usage. You can optionally provide an expiration time for cached objects.
Changes at version 0.4.3
At the version 0.4.3 we changed our async method to use the new javascript Promise. Any questions, go ahead and look at MDN.
Download
Download locache either with annotated source (~20 kb) or production ready and minified (~5 kb)


Lazy Loading
Note: Spartacus 3.x is no longer maintained. Please upgrade to the latest version.
Note: Spartacus 3.x was tested with SAP Commerce Cloud versions 1905 to 2105. Spartacus 3.x has not been verified to work with (and is not guaranteed to work with) SAP Commerce Cloud 2211 or later releases.
Lazy loading, also known as code splitting, lets you divide your JavaScript code into multiple chunks. The result is that you do not have to load all the JavaScript of the full application when a user accesses the first page. Instead, only the chunks that are required for the given page are loaded. While navigating the storefront, additional chunks are loaded when needed.
Such an approach can substantially improve “Time To Interactive”, especially in the case of complex web applications being accessed by low-end mobile devices.
Table of Contents
- Spartacus Approach to Lazy Loading
- General Concepts
- Lazy Loading of CMS Components
- Lazy Loading of Modules
- Preparing Libraries to Work with Lazy Loading
Spartacus Approach to Lazy Loading
Code splitting is a technique that has to be done at application build time. Code splitting provided by Angular is typically route-based, which means there is a chunk for the landing page, another chunk for the product page, and so on. Since Spartacus is mostly CMS driven, the actual application logic for each route cannot be decided at build time. Business users will eventually alter the page structure by introducing or removing components. This is why an alternative approach to lazy loading is required, which Spartacus provides in the following ways:
- Lazy loading of CMS components
- CMS-driven lazy loading of feature modules
General Concepts
The following sections offer some important information about how lazy loading works in Spartacus.
Defining Dynamic Imports Only in the Main Application
Dynamic imports, a technique that is used to facilitate lazy loading and that also allows code splitting, can only be used in the main application. It is not possible to define dynamic imports in the prebuilt libraries.
This is an unfortunate limitation, which results in some application code that must be added by customers. Although the amount of custom code is limited to the bare minimum, we’ll add a feature in a future version of the schematics library to automatically add lazy-loaded modules.
Avoiding Static Imports for Lazy-Loaded Code
To make code spitting possible, your static JavaScript code (the main app bundle) should not have any static imports to code that you want to lazy load. The builder will notice that the code is already included, and as a result, will not generate a separate chunk for it. This is especially important in the case of importing symbols from libraries.
At the time of writing (Angular 9 and Angular 10), mixing static imports with dynamic imports for the same library entry point, even for distinct symbols, will break lazy loading and tree shaking for this library entry point. If you were to do this, it would statically include the entire entry point in the build. For this reason, it is highly recommended that you create specific entry point for the code that has to be loaded statically, and separate entry points for the code that can be loaded lazily.
Configuration in Lazy-Loaded Modules
Note: This functionality is introduced with version 3.0 of the Spartacus libraries.
If additional configuration is provided inside the lazy-loaded module, Spartacus merges it into the global application configuration to support lazy loading scenarios for existing components and services. In most cases, especially when lazy-loaded modules provide mostly default configurations, this works reliably. However, it can cause problems if it is overused, especially when two modules provide different configurations for the same part of the config. Scenarios such as these can be fixed by providing the necessary overrides in the main app.
This merging functionality is made possible by a compatibility mechanism that is enabled by default, but you can disable it with the disableConfigUpdates
feature flag. If you are developing new modules that have to hook into configurations from lazy-loaded modules, you should use the ConfigurationService.unifiedConfig$
instead. This functionality is described in the following section.
Unified Configuration
Unified configuration provides a way to get a global configuration that includes both the root configuration and the configuration from already-loaded lazy-loaded modules.
The ConfigurationService.unifiedConfig$
exposes the unified configuration as an observable that emits the new configuration each time it changes. This happens, for example, every time a lazy-loaded module with a provided configuration is loaded and instantiated.
All configuration parts are merged in a strict order, where the actual configuration always overrides the default one, and the configuration defined in the root module (that is, the app shell) has precedence.
The following is an example that shows the order in which different configurations provided in the root app and in two lazy-loaded modules are merged, where each subsequent item in the list can override the previous one:
- default root configuration
- default configuration from lazy-loaded module 1
- default configuration from lazy-loaded module 2
- configuration from lazy-loaded module 1
- configuration from lazy-loaded module 2
- root configuration (always takes precedence)
Providers in Lazy-Loaded Modules
Injection tokens provided in lazy-loaded modules are not visible to services provided in the root application. This applies especially to multi-provided tokens, such as HttpInterceptors
, various handlers, and so on.
To mitigate this drawback, some Spartacus features, such as the PageMetaService
(which consumes PageMetaResolver
tokens), or the ConverterService
(which mostly consumes adapter serializers and normalizers), use the unified injector under the hood. In doing so, they have access to lazy-loaded tokens and can leverage them for global features.
For mechanisms that do not rely on the unified injector (for example, functionality from most non-Spartacus libraries, such as the core Angular libraries), it is recommended that you always eager load modules with these kinds of tokens.
For more information about eager loading, see the Angular documentation glossary.
Unified Injector
The unified injector provides a way to inject a token, or multi-provided tokens, while taking into account the root injector and the injectors from lazy-loaded features. The injector exposes an observable that emits a new set of injectables for a specified token each time the status of the unified injector changes.
Avoiding Importing the HttpClientModule in Your Lazy-Loaded Modules
In general, the HttpClientModule
should be imported in the root application, not in the library. For example, if you import it inside a lazy-loaded library, all injectors from the root library will be invisible to HTTP calls originating from the lazy-loaded module.
Although technically it is possible to import the HttpClientModule
in the library, in most cases it is not something that is expected, and it might cause errors that are difficult to explain, so please keep this in mind.
Lazy Loading of CMS Components
Note: This feature is introduced with version 2.0 of the Spartacus libraries.
Configuration of Lazy Loading CMS Components
Lazy loading of CMS code is achieved by specifying a dynamic import in place of a statically-referenced components class in the CMS Mapping configuration. The following is an example:
{
cmsComponents: {
SimpleResponsiveBannerComponent: {
component: () => import('./lazy/lazy.component').then(m => m.LazyComponent)
}
}
}
For more information on CMS mapping, see Customizing CMS Components.
Technical Details
Support for dynamic imports in CMS component mapping is implemented using customizable component handlers (specifically, the LazyComponentHandler
).
It is possible to extend this handler to customize its behavior, to add special hooks, or different triggers, or to implement a completely new handler that can optionally reuse existing ones.
Lazy Loading of Modules
Note: This feature is introduced with version 2.1 of the Spartacus libraries.
CMS-driven lazy loading of feature modules allows the following:
- Lazy loading not only component code, but also the core part (including NgRx state)
- Loading a feature only once, when first needed
- Providing shared, lazy-loaded dependency modules
Lazy loading of the feature module is triggered by the CMS requesting a component when the implementation is covered by the relevant feature configuration.
Configuration of Lazy-Loaded Modules
Configuration of the feature involves the following aspects:
- The dynamic import of the feature module (which has to be defined in main application)
-
The information about what CMS components are covered by a specific feature (which can become part of the library and imported statically). This information is provided as an array of strings under the
cmsComponents
key. The following is an example:{ featureModules: { organization: { module: () => import('@spartacus/my-account/organization').then( (m) => m.OrganizationModule ), cmsComponents: [ 'OrderApprovalListComponent', 'ManageBudgetsListComponent', 'ManageCostCentersListComponent', 'ManagePermissionsListComponent', 'ManageUnitsListComponent', 'ManageUserGroupsListComponent', 'ManageUsersListComponent', ], }, }, }
Component Mapping Configuration in Lazy-Loaded Modules
Default CMS mapping configuration in lazy-loaded modules should be defined in exactly the same fashion as in statically-imported ones.
Spartacus is able to extract a CMS component mapping configuration from a lazy-loaded feature and use it to resolve component classes and factories covered by the feature. That is why it is possible and recommended to use the standard way of providing the default CMS mapping configuration inside a lazy-loaded module. As a result, the exact same module and library entry point can be imported dynamically or statically, depending on the needs, and it is still possible to overwrite a lazy-loaded CMS configuration from the application level by providing configuration overrides in the application.
Defining Shared-Dependency Modules
It is possible to extract some logic to a shared, lazy-loaded module that can be defined as a lazy-loaded dependency for a feature module by providing an array of dynamic imports in the dependencies
property of the feature configuration. The following is an example:
{
featureModules: {
organization: {
module: () =>
import('@spartacus/my-account/organization').then(
(m) => m.OrganizationModule
),
dependencies: [
() =>
import('@spartacus/storefinder/core').then(
(m) => m.OrganizationModule
),
// ,,
],
},
},
}
Such unnamed dependency modules are instantiated only once, when lazy loading the first feature that depends on it. Its providers contribute to the combined injector that is passed to the feature module, and as a result, all feature services and components have access to the services provided by the dependency modules.
Combined Injector
Any lazy-loaded module can inject (that is, have access to) services and tokens from the root application injector and the dependency modules injectors. This is possible because of the CombinedInjector
that is created each time the feature module with dependencies is instantiated.
When a CMS component that is covered by a lazy-loaded module is instantiated, it can inject (that is, have access to) services from the following:
- The
ModuleInjector
hierarchy, starting from the feature module injector, and including dependency modules and the root injector - The
ElementInjector
hierarchy, which is created implicitly at each DOM element
Initializing Lazy Loaded Modules
Note: This functionality is introduced with version 3.2 of the Spartacus libraries.
Spartacus provides a MODULE_INITIALIZER
that should be used instead of the Angular APP_INITIALIZER
for initializing lazy-loaded modules. The APP_INITIALIZER
mechanism finishes initializing the application before any lazy loading occurs, so lazy-loaded features that may need to run initialization logic when they are loaded are unable to do so.
The MODULE_INITIALIZER
injection token can be used to provide initialization functions in modules that are intended to be lazy loaded.
You configure a MODULE_INITIALIZER
in the same way that you would configure an APP_INITIALIZER
. The following is an example:
...
import { MODULE_INITIALIZER } from '@spartacus/core';
...
export function myFactoryFunction(
dependencyOne: DependencyOne
) {
const result = () => {
// add initialization logic here
};
return result;
}
@NgModule({
providers: [
{
provide: MODULE_INITIALIZER,
useFactory: myFactoryFunction,
deps: [DependencyOne],
multi: true,
},
],
})
export class MyLazyLoadedModule {}
Although the primary use case for the MODULE_INITIALIZER
is to run when a module is lazy loaded, the MODULE_INITIALIZER
function still runs if the module it is defined in is configured to be loaded eagerly (that is, loaded when the app starts, which is the default method for importing modules). If an eager-loading configuration is applied on a module that is designed for lazy loading, the MODULE_INITIALIZER
functions are run during the Angular app bootstrap sequence.
An initialization function that is provided by the MODULE_INITIALIZER
only runs when the module is loaded. This means that if a module is lazy loaded, the initialization function will run before the module is loaded, but it will not run when the app is initialized. If a module is configured for eager loading, the initialization function will only run when the app is initialized.
If any of the initialization functions returns a promise, app initialization or module loading does not complete until the promise is resolved. If one promise is rejected, the app initialization or the module loading is interrupted. If an initialization function throws an error, the app initialization or module loading is also interrupted.
If a feature needs to apply initialization logic at the moment the app is loaded, feature libraries can still use the regular APP_INITIALIZER
in their @spartacus/{featurename}/root
entry point, which by convention is an entry point that is always eager loaded.

Preparing Libraries to Work with Lazy Loading
Providing Fine-Grained Entry Points in Your Library
Mixing static and dynamic imports from the same entry points breaks lazy loading and affects tree shaking, so any library that will be used directly in dynamic imports should expose fine-grained secondary entry points to optimize code splitting.
As a convention, Spartacus exposes root entry points for features, such as @spartacus/orgainzation/administration/root
. This type of entry point contains all of the code that should not or cannot be lazy loaded. Modules from the root entry point should be imported statically in the root application, which means they will be eager loaded and will be available in the main application chunk.
For more information about support for secondary entry points in the Angular libraries, see Secondary Entry Points in the ng-packagr documentation on GitHub.
Separating Static Code from Lazy-Loaded Code
When you work with Angular Dependency Injection, the list of providers in the injector should not change after the injector is initialized. This paradigm specifically applies to any multi-provided tokens, to handlers, and especially to any Angular-native multi-provided tokens, such as HTTP_INTERCEPTOR
, APP_INITIALIZER
, and so on.
The result is that any multi-provided token in a lazy-loaded module will not be visible to modules and services that are provided in the root, or in other lazy-loaded chunks, with the exception of multi-provided tokens that are injected using the unified injector.
Some Spartacus features, such as PageMetaService
or ConverterService
, use the UnifiedInjector
to be aware of tokens that can be lazy loaded, so that the global logic (such as SEO features) can work reliably even if the logic is lazy loaded with the feature. For example, the store locator page meta resolver can be lazy loaded with the store locator feature.
The Spartacus configuration, which is also defined by providing configuration chunks, is treated a bit differently because of a compatibility mechanism that contributes configurations from lazy loading features to the global configuration. This mechanism can be disabled by a feature flag, and will be turned off by default in the future, in favor of the unified configuration feature.
If there are issues with lazy-loaded providers not being visible by the root services, it is always possible to include this kind of code in a statically-linked module that is available upfront. It is recommended to create a separate entry point in your library (by convention, named root
, such as my-library/root
) that contains minimal code, that will be included in the main bundle, and that will be available from the beginning.
Wrapping Library Code in a Lazy-Loaded Module
To address some specific customizations on top of a lazy-loaded library, it is possible to wrap static imports from one or more libraries into a single module that will be imported dynamically instead. This technique can also be an effective optimization strategy, because the builder will be able to use tree shaking for all of the static imports inside the module.


station module¶
Model for a monitoring station and tools for manipulating station data.
-
class
station.
MonitoringStation
(station_id, measure_id, label, coord, typical_range, river, town)¶ Bases:
object
Class representing a river level monitoring station.
-
static
get_relative_water_level
(station)¶ Return the relative water level of a given station.
Useful to pass directly to sorted() as a key
- Parameters
station (MonitoringStation) –
- Returns
the relative water level of the station.
- Return type
float
-
static
inconsistent_typical_range_stations
(stations)¶ Return the stations with inconsistent typical ranges.
- Parameters
stations (list[MonitoringStation]) –
- Returns
output – the monitoring stations with inconsistent typical ranges.
- Return type
list[MonituringStation]
-
relative_water_level
()¶ Return the water level as a proportion of the typical range.
This is 0.0 when the water level is equal to the lower typical range and 1.0 when the water level is equal to the upper typical range
- Returns
the relative water level compared to the typical range. If the typical range is not consistent, None is returned.
- Return type
float
-
typical_range_consistent
()¶ Return true if the typical range is inconsistent.
Range is inconsistent if lowest value is greater than largest value.
- Returns
if typical range is consistent.
- Return type
bool
-
static


Maruti Suzuki S-Presso vs Renault Kwid comparison
by Nikhil BhatiaThe S-Presso ‘mini-SUV’ is Maruti’s long overdue answer to the ‘SUV-inspired’ Renault Kwid. We cut through the marketing speak to find out which is the better‘car’.
You have the Renault Kwid to thank for the genesis of the Maruti Suzuki S-Presso because while Maruti might have reigned supreme in the budget segment for decades, the refreshingly different Kwid, launched in 2015, sure rocked the boat. With the Kwid, Renault successfully established that a budget hatchback need not be a basic hatchback. The car came loaded with class-first features, like a touchscreen and digital speedometer and, of course, there was the Kwid’s biggest draw – the way it looked. Styled to look like a mini-Duster, the Kwid cashed in on Indian buyers’ infatuation with SUVs.
Maruti made clear its intention of coming up with a Kwid fighter with the Concept Future S at Auto Expo 2018, and what we have today is the final product along with the car it’s here to beat. In case you are wondering why the Kwid pictured here looks different, it’s because this is the facelifted version that made its debut just a day after the S-Presso’s launch! Renault clearly is in no mood to cede ground.
What makes the contest all the more interesting is that there’s little between the comparable engine and gearbox versions in terms of price, power and economy. Question is, which one is more worthy of your money?
On the face of it
The S-Presso and Kwid flaunt their SUV-ness to varying degrees. With its upright pillars, flat bonnet and relatively high roof, the S-Presso has the more SUV-like shape. Does that make it the more attractive car? No. Thing is, the Maruti is too narrow for its height and simply doesn’t look substantial enough for anything that wants to be thought of as an SUV. The styling is also a miss to my eyes. The toothy front grille and the cladding lower down work but the sides and tail are far too plain. And while the squared-out wheel arches add some volume to the body, they also make the 14-inch wheels look smaller than they are. You can embellish the S-Presso with side cladding, alloy wheels, LED DRLs and more but the add-ons can only do so much for the look.
The Kwid, on the other hand, is a more traditionally handsome car. It’s got classic hatchback proportions but its significantly longer and wider body means it has the larger footprint. Helping the updated Kwid’s stance are its upsized 14-inch rims, and as an added plus, ground clearance is up 4mm to 184mm, versus the S-Presso’s 180mm. The Kwid’s SUV link? It comes from the wheel cladding and chunky runners at the sides. The roof rails on the top-spec Climber versions also help deepen the connect.
I don’t think I’m alone to think Renault’s designers have hit it out of the park with the facelift. The restyled front end features a new-age split headlamp setup, with standard-fit LED DRLs on top and the main headlights lower down, and the result is really eye-catching. The chunky surrounds for the large headlights are also nicely done, while the orange accents on the bumper add flair to the Climber versions’ appearance. The smoked-grey wheel covers on the Climbers also look far more imaginative than the S-Presso’s basic units. The new LED light guides on the tail-lamps also do their bit to update the Kwid’s appearance.
Space cadets
These cars carry their exterior personalities on the inside as well. Once again, the S-Presso comes across as a car that's trying hard to be different with its centrally stacked instruments, an arrangement not everyone will take readily to. That said, the Mini-like look for the centre console is nice, and the coloured surround for the side air-con vents helps brighten things up. But if there's something drivers will particularly like, it's the view out. The high seating and upright pillars are a boon and make the S-Presso an easy car to get comfy in.
You sit much lower in a Kwid, and the initial impression is also of sitting in a smaller car. Drivers will find themselves sat closer to their co-passenger, there's less headroom and, in general, the Kwid cabin doesn't feel as airy as the S-Presso's. However, you will like what you see inside the Kwid's updated cabin. The dashboard has been revised (the top glovebox area now houses the optional passenger airbag), the touchscreen is now a size larger and the new part-digital dials include a tachometer too. The bright seat upholstery looks snazzy while the new steering with leather inserts enhances the look of things. Unfortunately, overall cabin quality hasn't taken the same jump up. The Kwid's plastics are scratchy and don't feel as nice as the textured surfaces you'd find in the S-Presso.
But if there's one area where the Kwid is completely outdone, it's in rear-seat space. Where there's just about enough room for average-sized adults in the back of a Kwid, the S-Presso's rear seat can host two six-footers in good comfort. Vertical space has been used to the fullest to maximise useable room. There's ample headroom, a surprising amount of knee room and good shoulder room too. What's more, rear-seat occupants also sit more comfortably in the S-Presso. The slight knees-up seating position in the Kwid gets tiring on long journeys, but the Climbers do get a class-first rear centre armrest and that does up comfort to an extent. What's a pity is that both cars come with minuscule rear headrests that will offer limited whiplash support.
Both cars offer a fair amount of storage space with bottle holders at the front doors and smaller recesses on the dashboard. The Kwid's cavernous glovebox is larger though, while the S-Presso is the only one to offer a bottleholder for rear seat passengers. On airport runs, you'll find the S-Presso's better-shaped 270-litre boot slightly more accommodating than the Kwid's 279-litre boot. Do note, the updated Kwid's boot size is down from the original's 300-litre figure owing to the incorporation of larger wheel wells.
| Dimensions | ||
| Maruti Suzuki S-Presso VXi+ | Renault Kwid Climber (O) | |
| Length | 3565mm | 3731mm |
| Width | 1520mm | 1579mm |
| Height | 1564mm | 1490mm |
| Wheelbase | 2380mm | 2422mm |
| Ground clearance | 180mm | 184mm |
| Kerb Weight | 763kg | 755kg |
| Tyres | 165/70 R14 | 165/70 R14 |
Features and options
Both cars come with their fair share of creature comforts. Power steering, remote locking and front power windows are standard on the top-spec versions of both cars, but only the Kwid offers rear power windows as a Rs 8,000 option. Again, while digital speedometers are among the things you'd find common on both models, a tachometer is exclusive to the Renault. The Kwid is also the only one with a reverse camera. The Maruti, on the other hand, goes one-up with steering-mounted audio controls and internally adjustable mirrors. As for infotainment systems, the Kwid's new 8.0-inch touchscreen is a size larger than the S-Presso's 7.0-inch unit, though both screens are equally slick and come bundled with Android Auto and Apple CarPlay.
Switching focus to the all-important matter of safety, it's reassuring to know is that both cars comply with India's latest crash protection norms. Top-spec S-Presso's do get dual airbags as standard. A passenger airbag is a Rs 8,000 option on the Kwid.
| Equipment | ||
| Maruti Suzuki S-Presso VXi+ | Renault Kwid Climber (O) | |
| Airbags | 2 | 2 |
| LED DRLs | Option (Rs 9990) | Yes |
| Power steering | Yes | Yes |
| Power windows | Front | Front and rear |
| Central locking | Yes | Yes |
| Remote locking | Yes | Yes |
| Rear centre armrest | No | Yes |
| Rear parking sensors | Yes | Yes |
| Parking camera | No | Yes |
| Touchscreen | 7.0-inch | 8.0-inch |
| Android Auto/Apple CarPlay | Yes/Yes | Yes/Yes |
| Steering-mounted audio controls | Yes | No |
| Digital speedometer | Yes | Yes |
| Tachometer | No | Yes |
Power to the people
As before, the Kwid is on offer with 0.8-litre and 1.0-litre petrol engines. For this comparison, we've considered the larger-hearted of the Kwids – one that's a direct match for the S-Presso and its sole 1.0-litre unit. Suzuki and Renault’s three-cylinder, naturally aspirated engines produce the exact same 68hp of power, are near identical in max torque too (90Nm on the S-Presso vs 91Nm on the Kwid) and have to propel similar mass (763kg vs 755kg) as well. Unsurprisingly, our preliminary performance tests revealed little difference in acceleration and roll-on timings, with the S-Presso being quicker to the ton and from 40-100kph in fourth gear, and the Kwid being faster from 20-80kph in third. What the numbers fail to convey is how different the two cars feel to drive.
The S-Presso's BS6-compliant K10 engine is surprisingly tractable and delivers its power in a smooth manner. What makes the engine all the more likeable is its refinement. It is free from undue vibes, runs quiet and only gets vocal when you rev it hard. A light clutch and smooth-shifting gearbox only enhance the experience.
After a go in the S-Presso, you'll find that the Kwid's powertrain isn't as sorted. The engine is noticeably noisier to begin with, and low-speed power delivery isn't quite as crisp. Resultantly, you'll have to work the Kwid's gearbox more in town. Build the revs, though, and you'll appreciate the Renault engine's responsiveness and zesty nature. The trade-off is that you have to contend with a lot more noise from the Kwid's engine bay. Perhaps the inevitable upgrade to BS6-spec will make the engine a smoother and quieter unit.
We are yet to do a full fuel economy run but both models do boast an identical ARAI-rated economy of 21.7kpl. Interestingly, the updated Kwid 1.0's official fuel economy figure is down on the earlier car's 23.01kpl. The switch to chunkier tyres and the 35kg increase in weight (a result of added structural reinforcements) are responsible for the drop in economy.
| Engine and Performance | ||
| Maruti Suzuki S-Presso VXi+ | Renault Kwid Climber (O) | |
| Engine | 3-cyl, 998cc, petrol | 3-cyl, 999cc, petrol |
| Power | 68hp at 5500rpm | 68hp at 5500rpm |
| Torque | 90Nm at 3500rpm | 91Nm at 4250rpm |
| Gearbox | 5-speed manual | 5-speed manual |
| Performance* | ||
| 0-60kph | 5.40 sec | 5.64 sec |
| 0-100kph | 13.49 sec | 13.84 sec |
| 20-80 in 3rd | 13.13 sec | 12.34 sec |
| 40-100 in 4th | 21.40 sec | 19.22 sec |
* S-Presso performance not to Autocar test standards
Easy does it
The compact dimensions and easy-to-twirl steerings make the S-Presso and Kwid really friendly to punt around town. The Maruti does have the tighter turning radius, and is also the one with the more absorbent ride at low speeds, while the switch to larger wheels has cost the Kwid some of its pliancy over bumps. You also hear more of the suspension in the Kwid.
The lower-slung Kwid does feel more sure-footed at highway speeds. There's less vertical movement and you get a greater feeling of confidence in the corners, even if the steering is devoid of any feel. The S-Presso moves around that little bit more at high speeds but straight-line stability is actually better than what you'd expect from a tall car. There is reasonable weight at the steering too but quick changes in direction catch the S-Presso out.
Buy call
The Kwid has long been our favourite budget hatchback and the updated model only builds on the original's strengths. Were this a contest on looks alone, the striking 2019 Kwid would have walked away with it. However, if you see the two cars in their entirety, it's the S-Presso that comes across as the more rounded product. It is far more spacious, is better finished on the inside, has the quieter engine and is generally a nicer car to drive. It lacks some of the frills that you get on the Kwid but, given a choice, the S-Presso would be the car we'd go for. If only it wasn't such an odd looker.
| Price | ||
| Maruti Suzuki S-Presso VXi+ | Renault Kwid Climber (O) | |
| Price (ex-showroom, Delhi) | Rs 4.48 lakh | Rs 4.62 lakh |
Renault Kwid
Rs 3.18 lakh * on road price (New Delhi)


"I enjoy working from home with kids very much and I can balance very well between my work, life, and especially kids" - somebody
Tip #1
Block calendar for yourself
Tip #2
Being comfortable saying no
Tip #3
Look for ways to be collaborative
Tip #8
Backup work to cloud regularly


{% load staticfiles %}
Stylesheet switching is done via JavaScript and can cause a blink while page loads. This will not happen in your production code.


Going under the handle of @marcomorettim
Personal Page of Marco Moretti
"Nothing appearing here is necessarily meant to be the most accurate reppresentation of reality"
Bio
In a nutshell
I am someone who can be described as working in Business
I am currently based in Paris, France
I am maintaining this page as a hobby, yes, that's why it doesn't look pro
Soon going to create a
publication
And keeping on learning how to be a better coder at
Tweets by marcomorettim
Subtext
Notes:
This website was created by @marcomorettim hosted on


The ecosystem of this project use the boid technique. A boid is an autonomous agent who is aware of its environment and move considering the steering force applied to it. Here is an example of boids which are moving as a group.
Simple boid system. This simulation is computed live on your browser.
To improve the behavior of the boids, we used an automaton which indicate the transitions between the different states of the boid. We also used some state variables which indicate if a boid is hungry, thirsty or tired. The following automaton represent a simplified version of the automaton used in this project.
Boid state automaton
In order to populate the world, two type of boids were used
Wolf mesh
Rabbit mesh
Tree mesh
Carrot mesh
Trees and carrots were considered here as boid to handle the relations between them and the others moving boids. We could therefore for example use a delimitation zone to avoid the collision between the boids and the environmental elements. It is the same rule which indicate why two animals do not intersect and why a living boid do not touch an environmental element.
Here is non exhaustive list of the behavior implemented in this project :
The pack of wolfs follows the leader
The pack of wolf do not collide with the trees and keep following the leader
Two rabbits are eating a carrot
The rabbits see the wolf and flee from it
The wolf is hungry and chase some rabbits
The wolfs are thirsty and drink at the lake
One concern of this project was to make it run in real time. Here are some optimisations we made to improve the speed of the program.
In the end, it was possible to run the program with around 1000 boids on a standard machine at 60 fps.
The boids also interact with the environment. For example :


Hello human!
I am OSModal. A javascript modal plugin written in plain javascript. That means, no dependecies required.
You can resize me, drag me and even snap me just like you would a explorer/finder window in your favourite OS
I am quite customizable via plugin options or css.


Home
Categories
About
Contact
Search
Search Companies
Search Ads
Search Jobs
Info
How it Works
Pricing
FAQ
Sign Up
Log in
Profile
Your Profile
Logout
All Categories
Arts & Entertainment
Business and Consumer Servicese
Computer Electronics & Technology
E-Commerce & Shopping
Finance
Food & Drink
Health
Heavy industry & Engineering
Home & Garden
Pets & Animals
Real Estate
Scince & Education
Sports
Travel & Tourism
Vehicles
100km
25km
50km
Search
Arts & Entertainment
0 Companies
Business and Consumer...
0 Companies
Computer Electronics &...
0 Companies
E-Commerce & Shopping
0 Companies
Finance
0 Companies
Food & Drink
0 Companies
Health
0 Companies
Heavy industry &...
0 Companies
Home & Garden
0 Companies
Pets & Animals
0 Companies
See all categories
Top Rated Companies on CLA
Automobile Category
Ford LTD
Minesota, Address Some 19DK, United States
Microsoft
Address of the company or smth else
Google Inc
Address of the company or smth else
Uber San Francisco
Address of the company or smth else
Microsoft
Address of the company or smth else
Show All
Buy & Sell online locally or internationally
For all interested to list classified ad, please register
here.
Top Rated
Latest
Random
Placing ads has never been easier!
Placing ads has never been easier!
Learn how CLA works
Register your company
FREE
List your company
Create beautiful company profile and list it on our directory for free forever.
FREE
List your company
Create beautiful company profile and list it on our directory for free forever.
FREE
List your company
Create beautiful company profile and list it on our directory for free forever.
FREE
Always FREE ad posting
Post as many ads as you like for 30 days without limitations and 100% FREE.
FREE
Always FREE ad posting
Post as many ads as you like for 30 days without limitations and 100% FREE.
FREE
Always FREE ad posting
Post as many ads as you like for 30 days without limitations and 100% FREE.
FREE
Premium Exposure
It’s very simple to choose pricing & level of exposure on our
pricing page.
FREE
Premium Exposure
It’s very simple to choose pricing & level of exposure on our
pricing page.
FREE
Premium Exposure
It’s very simple to choose pricing & level of exposure on our
pricing page.
Trusted by


Game Over
Your Score:
Enter initials to save your score:
Save
Cancel and Return Home
View Highscores


Objective of Lazarillo Project
The aim is building, annotating and create a dataset, the “ImageNet” for the blind, i.e., a dataset of images taken from a wearable camera (or phone if preferred) by visually impaired people, that can later facilitate image captioning and question answering to help them be more independent in their daily lives. The aim of project Lazarillo is developing this mobile application that has as end-user the visually impaired.
Once enough data has been collected, the application will help describe, with text or speech, the surroundings to the blind person, in the most needed times, or in most beautiful moments. We think people who can benefit the most from AI are people with special needs, and that is the motivation to build datasets and models that can make cities more visible simply by touching a button of a wearable camera or phone. Its activation will translate the scene into a vocal description, helping to give the blind person context about the environment around him, or even answer questions posed by the user.
Lazarillo Application Use Cases
1. The blind user may choose to send for processing only the textual description of the situation that the image its wearable camera takes, or also the visual description, depending on the degree of complexity of help he wants to obtain from the application, or the degree of privacy or speed he requires for the answer.
2. Only elements relevant to the situation in which the user specifically requires help will be processed. In such situations, the user will share the image of his environment through the wearable camera and then will receive, through an audio, the caption (a legend or subtitle) that would accompany the image of the real situation where he is located; that is, a description of e.g., objects, people and the general context that surrounds him in his current enviroment. The application can also provide answers to questions about a given image.
We seek:
AI Researchers and engineers: to collect, annotate, document and publish datasets, and develop models for image captioning and visual question answering (VQA) from the collected dataset. The dataset should be similar to MS-COCO (at least with captions per image and possibly answers to questions -posed or not by the blind person). If you are willing to contribute, join ContinualAI.org Slack and ask Natalia Diaz to add you to the channel.
Visually impaired/ blind volunteers. Do you know visually impaired people that would be happy to wear the Google Clips camera and save images every time he would find useful getting a description of the environment? We would provide them the camera if they are comfortable wearing it (otherwise, a mobile phone will suffice). Volunteers should be happy to share pictures of their lives in the situations they feel they would need most help with. In order to assist even more, they could as well ask a question about the picture that could potentially be answered by an AI model (i.e., as if we would provide Siri with images). The data will be made public for research purposes and so that the scientific community can build and improve upon such models.
More concretely, we would train a model to transform images to the relevant information that the blind person would need from the images surrounding him. Therefore, at the time of saving, it would be great to annotate if possible some context for the blind person (what would he like to be told about the image? e.g. if he is in a supermarket, in what food section I am? or in a new hotel, In what direction should I walk to find the reception? The blind user may provide context for each situation when he takes a picture where he thinks he would benefit from a textual description of the environment. The idea is that this contextual information will help a question answering application improve responding questions about his surroundings in the future. This information should be answerable by just looking at the images of the wearable (or phone) camera.


nui-repeat
is responsible for repeating the items provided in itemSource
.
NuiRepeatModule
This example demonstrates how easy it is to create a simple list by repeating the items of provided datasource.
Simply pass an array of items to itemsSource
, and also don't forget to set the
repeatItemTemplateRef
with a template to render for each item.
To enable the dragging of items in the nui-repeat
list, just set the draggable
input property to true
.
To allow list items to be reordered, set the reorderable
input property to
true
. Bind to the itemsReordered
output to receive sorting data
when an item is dragged to a new spot in the list. The payload for the event is an
IItemsReorderedEvent
object.
draggable
input to true with the reorderable
input set to false
will disable reordering and only allow dragging items to other containers.
In order to customize the handle by which an element can be dragged, you can specify the dragHandleTemplateRef
.
dragHandleTemplateRef
template makes declaring the draggable
input property optional
as it will automatically be set to true
.
Once the user starts dragging an item, the preview DOM element is created as the last child of the body.
To have a custom CSS class for that element, you can specify the dragPreviewClass
input
property. The default value for this input is "nui-dnd-preview"
.
In order to customize the drag preview template, you can specify the
dragPreviewTemplateRef
input.
dragPreviewTemplateRef
template makes declaring the draggable
input property optional
as it will automatically be set to true
.
In order to customize the drag and drop behavior of any item in the repeat component you can provide
a configuration object containing callbacks for the provided functionality via the itemConfig
input.
IRepeatItemConfig
:
{{getItemConfigKey("isDraggable")}}
- Provide a callback to decide if the item should be draggable
{{getItemConfigKey("isDisabled")}}
- Provide a callback to decide if the item should be disabled
{{getItemConfigKey("trackBy")}}
- Provide a function that defines how to track changes for items in the iterable.
draggable
input must be true.
The selectionMode
: multi
repeats the items with a checkbox component, and allows the user to select
multiple items by clicking the provided checkboxes or by clicking on the row itself.
You can easily set the items being repeated to a disabled state. Make sure the itemsSource
you provide contains property
disabled
: true
for each disabled item.
If you need to highlight clicked item without checkboxes and radio-button, you can just use
selectionMode
: single
Use the selectionMode
: radio
mode to add radio buttons for each item and allow to select one of them.
This example shows how to make a list with radio buttons that can be either checked on or checked off.
This example shows the single selection mode list where at least one item is always selected.
nui-repeat
component but the List Schematic documentation provides examples on how to use them.


WITNESS LIST
Veteran Affairs & Military Installations
March 20, 2013 1:30 PM - or upon adjournment
FOR:
Staffel, David Small Business Owner (Self), Round Rock, TX
ON:
Duncan, David Deputy General Counsel (Texas Council on Purchasing from People with
Disabilities), Austin, TX
Jackson, Kevin Disabled/Blinded Veteran (Texas Council on Purchasing from People with
Disabilities), Austin, TX
Moran, Daniel Commissioner (Texas Veterans Commission), Austin, TX
Registering, but not testifying:
FOR:
Bratton, Pamela VP Meador Staffing & Co. Director of Government Affairs for SHRM
TSC (Society for Human Resource Management Texas State Council (SHRM TSC)),
Austin, TX
Cartwright, Bob President/CEO Intelligent Compensation, LLC (Society for Human
Resource Management - Texas State Council), Pflugerville, TX
Cunningham, James R. Major (Texas Coalition of Veteran Organizations - Military
Officers Association of America), San Antonio, TX
ON:
Burris, Edward Lieutenant Texas DPS, Lt Col USMC (Texas Department of Public Safety),
Austin, TX
Cutrone, Susanna Director of Human Resources Management (Texas Workforce
Commission), Austin, TX
Montemayor, Cruz Chief Administrative Officer (Texas Veterans Commission), Austin,
TX
FOR:
Nicola, James (Self), Houston, TX
Nicola, Mark (Self), Austin, TX
Toreson, Anthony (also providing written testimony) (Self/Thirty/Three Solutions, LLC),
Conroe, TX
Waybourn, Bill Chief (City of Dalworthington Gardens), Dalworthington Gardens, TX
ON:
Borland, Cindy Manager, Professional Licensing and Certification Unit (Department of
State Health Services), Austin, TX
Bowie, RenEarl Assistant Director - Regulatory Services (Texas DPS), Austin, TX
Kuntz, Jr., William Executive Director, Texas Department of Licensing and Regulation
(Texas Department of Licensing and Regulation), Austin, TX
Robinson, Mari Executive Director (Texas Medical Board), Austin, TX
Van de Hey, Dale M. DoD State Liaison, South Central States (DoD - State Liaison
Office), San Antonio, TX
Walker, Jaime (Texas Department of Insurance), Austin, TX
WITNESS LIST
Veteran Affairs & Military Installations
March 20, 2013 1:30 PM - or upon adjournment
Registering, but not testifying:
FOR:
Bond, Mark Chief (Soc) (Naval Special Warfare), Richmond, TX
Bratton, Pamela VP Meador Staffing (Meador and Texas Association of Staffing), Austin,
TX
Brauer, Scott (Self), Dripping Springs, TX
Burgess, Clint Constable Tarrant County Pct. 7 (Police in general), Mansfield, TX
Cartwright, Bob President/CEO Intelligent Compensation, LLC (SHRM - Texas State
Council (18,000 + Members)), Pflugerville, TX
Chatelle, Melody Legislative Consultant (United Ways of Texas), Austin, TX
Clark, Mark Executive Director (Houston Police Officers' Union), Houston, TX
Connett, Brent (Texas Conservative Coalition), Austin, TX
Copeland, Dathan Vice President (Shooter Performance Institute), Austin, TX
Crow, David President (Arlington Professional Firefighters Association), Arlington, TX
Cunningham, James R. Major (Texas Coalition of Veteran Organizations - Military
Officers Association of America), San Antonio, TX
Grahaeis, Ferdinand LT. Airforce of Germany (Military), Mansfield, TX
Kappas, David (Self), Sugar Land, TX
Lara, Rene Legislative Director (Texas AFL-CIO), Austin, TX
Matthews, Matt (Texas Association of Staffing), Austin, TX
Meadows, Randle President (Arlington Police Association), Arlington, TX
Rodriguez, Jennifer Attorney (Plumbing Heating Cooling Contractors Association
(PHCC)), Austin, TX
Providing written testimony:
FOR:
Shields, Chris (Toyota Motor Manufacturing Texas, Inc.), San Antonio, TX
ON:
Coleman, Ron Commercial Drivers License Coordinator (Texas Department of Public
Safety), Austin, TX
Registering, but not testifying:
FOR:
Cartwright, Bob President/CEO Intelligent Compensation, LLC (SHRM - Texas State
Council), Pflugerville, TX
Findeisen, Les Director of Policy (Texas Motor Transportation Association), Austin, TX
Matthews, Matt (Texas Association of Staffing), Austin, TX
FOR:
Toreson, Anthony (also providing written testimony) (Self/Thirty/Three Solutions, LLC),
Conroe, TX
ON:
Kuntz, Jr., William Executive Director, Texas Department of Licensing and Regulation
(Texas Department of Licensing and Regulation), Austin, TX
WITNESS LIST
Veteran Affairs & Military Installations
March 20, 2013 1:30 PM - or upon adjournment
Van de Hey, Dale M. DoD State Liaison, South Central States (DoD - State Liaison
Office), San Antonio, TX
Walker, Jaime (Texas Department of Insurance), Austin, TX
Registering, but not testifying:
FOR:
Cartwright, Bob President/CEO Intelligent Compensation, LLC (SHRM - Texas State
Council), Pflugerville, TX
Chatelle, Melody Legislative Consultant (United Ways of Texas), Austin, TX
Cunningham, James R. Major (Texas Coalition of Veteran Organizations - Military
Officers Association of America), San Antonio, TX
Lara, Rene Legislative Director (Texas AFL-CIO), Austin, TX
Matthews, Matt (Texas Association of Staffing), Austin, TX
Rodriguez, Jennifer Attorney (Plumbing Heating Cooling Contractors Association
(PHCC)), Austin, TX
ON:
Hamilton, Patrick Colonel (Adjutant General's Department), Austin, TX
Palladino, Thomas Executive Director (Texas Veterans Commission), Austin, TX
Registering, but not testifying:
FOR:
Bratton, Pamela VP Meador Staffing (Meador and Texas Association of Staffing), Austin,
TX
Cunningham, James R. Major (Texas Coalition of Veteran Organizations - Military
Officers Association of America), San Antonio, TX
ON:
Burris, Edward Lieutenant Texas DPS, Lt Col USMC (Texas DPS), Austin, TX
Jefferies, Perry Tex Vet Organization Manager (Texas A&M Health Science Center),
Round Rock, TX
Osborne, Chip Director of Finance (Texas Veterans Commission), Austin, TX
Williford, Jeff Legislative Liaison (Texas Veterans Commission), Austin, TX
FOR:
Sellers, Charmane President and CEO (ALEON Properties, Inc. (API)), Austin, TX
ON:
McGhee, Duncan Program Manager Veteran Entrepreneur Program (Texas Veterans
Commission), Austin, TX
Moran, Daniel Commissioner (Texas Veterans Commission), Austin, TX
Registering, but not testifying:
FOR:
Cartwright, Bob President/CEO (SHRM - Texas State Council), Pflugerville, TX
Cunningham, James R. Major (Texas Council of Chapters - Military Officers Association
of America), San Antonio, TX
WITNESS LIST
Veteran Affairs & Military Installations
March 20, 2013 1:30 PM - or upon adjournment
Providing written testimony:
FOR:
Romiti, Heather (Self), Austin, TX
FOR:
Floyd, Robert Chairman (Texas Capitol Vietnam Veterans Monument Committee), Austin,
TX
Registering, but not testifying:
FOR:
Cunningham, James R. Major (Texas Coalition of Veteran Organizations - Military
Officers Association of America), San Antonio, TX


0x01 – Preamble
Today, we will analyze the impact associated to the assignment of the “Load and unload device drivers” policy, which specifies the users who are allowed to dynamically load device drivers. The activation of this policy in the context of non-privileged users implies a significant risk due to the possibility of executing code in kernel space.
Although this is a well known technique, it can not be found in post-exploitation and privilege escalation tools, and there are no tools which carry out automatic exploitation neither.
WARNING
As of Windows 10 Version 1803, NTLoadDriver seems to forbid references to registry keys under HKEY_CURRENT_USER.


Questions
- Has Paul competed in over 5 different sports?
- Is Paul a "Certified Ethical Hacker" (CEH)?
- Are pineapples Paul's favorite pizza topping?
- Did Paul's father serve in the U.S. Navy?
- Is Paul's birthstone: emerald?
- Guess what number Paul's thinking of, from 1 to 10 inclusive.
- Name a state that Paul would like to move to at some point?
Answers
- Yes
- Yes
- No
- No
- Yes
- Random
- Correct States:
Additional Info About Paul
Education History
- Code Fellows
- Certificate *in progress
- Advanced Software Development in Full-Stack JavaScript
- Arizona State University
- Bachelor of Science *in progress
- Edmonds Community College
- Associate of Technical Arts
- Information Security and Digital Forensics
- Certificate
- Digital Forenics
- Cyber Security Specialist
Top Ten Favorite Movies
- Harry Potter and the Half-Blood Prince
- Jurassic Park
- Harry Potter and the Sorcerer's Stone
- Dracula Untold
- The Mummy
- Jumper
- The Matrix
- Van Helsing
- I, Robot
- Monty Python and the Holy Grail


Gets a list of roles available on a specified site.
Returns a list of site role objects, with the below fields:
id
- the role id in the database (integer)name
- the user friendly name, to be used as label (string)Accepts and returns JSON as Content-Type.
Request:
GET /api/v2/admin/sites/current/roles HTTPS/1.1
Connection: keep-alive
Content-Type: application/json
Authorization: 14f87f21c5ea4830a06a6314a8aad82b45bc61dc08f24a0fb55599cea83ca811
Response:
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: length
{
"links": [{
"rel": "self",
"uri": "https://api-ava.worldsecuresystems.com/api/v2/admin/sites/%7BsiteId%7D/roles"
}, {
"rel": "previous",
"uri": null
}, {
"rel": "next",
"uri": null
}],
"items": [{
"id": 10000,
"name": "Administrators"
}, {
"id": 10013,
"name": "Users"
}],
"totalItemsCount": 2,
"itemsPerPageCount": 1000,
"currentPage": 1
}
var request = $.ajax({
url: "/api/v2/admin/sites/current/roles",
type: "GET",
contentType: "application/json",
headers: {
"Authorization": $.cookie('access_token')
}
});
request.done(function (msg) {
console.log(msg);
})
request.fail(function (jqXHR) {
console.log("Request failed.");
console.log("Error code: " + jqXHR.status);
console.log("Error text: " + jqXHR.statusText);
console.log("Response text: " + jqXHR.responseText);
})
This method will return the following error codes:
200
- success401
- when authentication token is incorrect403
- when the user attempting the call does not have the proper permissions


*** User 2017-05-05 20:11:58.376 ***
20:11:58.376 [info] Disabling blocking sync...
*** User 2017-05-05 20:11:58.383 ***
20:11:58.383 [info] Configured peer_service_manager partisan_default_peer_service_manager on node 'node-1@MacBook-Pro-de-Anne-France'
*** User 2017-05-05 20:12:00.028 ***
20:12:00.028 [info] Enabling membership...
*** User 2017-05-05 20:12:00.030 ***
20:12:00.029 [info] Disabling blocking sync...
*** User 2017-05-05 20:12:00.035 ***
20:12:00.034 [info] Configured peer_service_manager partisan_default_peer_service_manager on node 'node-2@MacBook-Pro-de-Anne-France'
*** User 2017-05-05 20:12:01.542 ***
20:12:01.542 [info] Enabling membership...
*** User 2017-05-05 20:12:01.544 ***
20:12:01.544 [info] Disabling blocking sync...
*** User 2017-05-05 20:12:01.549 ***
20:12:01.549 [info] Configured peer_service_manager partisan_default_peer_service_manager on node 'node-3@MacBook-Pro-de-Anne-France'
*** User 2017-05-05 20:12:01.823 ***
Joining node: 'node-3@MacBook-Pro-de-Anne-France' to 'runner@MacBook-Pro-de-Anne-France' at port 58269
*** User 2017-05-05 20:12:01.823 ***
Joining issued: 'node-3@MacBook-Pro-de-Anne-France' to 'runner@MacBook-Pro-de-Anne-France' at port 58269
*** User 2017-05-05 20:12:01.824 ***
Joining node: 'node-2@MacBook-Pro-de-Anne-France' to 'runner@MacBook-Pro-de-Anne-France' at port 58253
*** User 2017-05-05 20:12:01.824 ***
Joining issued: 'node-2@MacBook-Pro-de-Anne-France' to 'runner@MacBook-Pro-de-Anne-France' at port 58253
*** User 2017-05-05 20:12:01.825 ***
Joining node: 'node-1@MacBook-Pro-de-Anne-France' to 'runner@MacBook-Pro-de-Anne-France' at port 58239
*** User 2017-05-05 20:12:01.825 ***
Joining issued: 'node-1@MacBook-Pro-de-Anne-France' to 'runner@MacBook-Pro-de-Anne-France' at port 58239
*** User 2017-05-05 20:12:01.886 ***
Waiting for join to complete with manager: partisan_default_peer_service_manager
*** User 2017-05-05 20:12:01.887 ***
Finished.
*** CT 2017-05-05 20:12:01.887 *** COVER INFO
Adding nodes to cover test: ['runner@MacBook-Pro-de-Anne-France']
*** CT 2017-05-05 20:12:01.896 *** COVER INFO
Successfully added nodes to cover test: []
*** User 2017-05-05 20:12:02.315 ***
Case finished: product_test
*** User 2017-05-05 20:12:09.358 ***
20:12:09.357 [info] Application lasp exited with reason: stopped
*** User 2017-05-05 20:12:09.358 ***
20:12:09.358 [info] Application partisan exited with reason: stopped
=== Ended at 2017-05-05 20:12:09
=== successfully completed test case
=== Returned value: ok
Test run history
| Top level test index


|
OR-Tools
7.1
Google Optimization software suite
|
#include <permutation.h>
Public Member Functions | |
| Permutation () | |
| Permutation (IndexType size) | |
| IndexType | size () const |
| bool | empty () const |
| void | clear () |
| void | resize (IndexType size, IndexType value) |
| void | assign (IndexType size, IndexType value) |
| IndexType & | operator[] (IndexType i) |
| const IndexType | operator[] (IndexType i) const |
| void | PopulateFromInverse (const Permutation &inverse) |
| void | PopulateFromIdentity () |
| void | PopulateRandomly () |
| bool | Check () const |
| int | ComputeSignature () const |
Definition at line 43 of file permutation.h.
|
inline |
Definition at line 45 of file permutation.h.
|
inlineexplicit |
Definition at line 47 of file permutation.h.
|
inline |
Definition at line 49 of file permutation.h.
|
inline |
Definition at line 50 of file permutation.h.
|
inline |
Definition at line 52 of file permutation.h.
|
inline |
Definition at line 54 of file permutation.h.
|
inline |
Definition at line 58 of file permutation.h.
|
inline |
Definition at line 62 of file permutation.h.
|
inline |
Definition at line 64 of file permutation.h.
| void operations_research::glop::Permutation< IndexType >::PopulateFromInverse | ( | const Permutation< IndexType > & | inverse | ) |
Definition at line 126 of file permutation.h.
| void operations_research::glop::Permutation< IndexType >::PopulateFromIdentity | ( | ) |
Definition at line 135 of file permutation.h.
| void operations_research::glop::Permutation< IndexType >::PopulateRandomly | ( | ) |
Definition at line 144 of file permutation.h.
| bool operations_research::glop::Permutation< IndexType >::Check | ( | ) | const |
Definition at line 150 of file permutation.h.
| int operations_research::glop::Permutation< IndexType >::ComputeSignature | ( | ) | const |
Definition at line 168 of file permutation.h.


WeBot
Home
Try
About
WeBot
A chat bot of Wechat.
Record all messages and reply them due to different conditions.
Try Now


You can pass this API an URL and it will respond with a shortened link to access that URL.
Note: the URL you provide must start with ftp://, http:// or https://
To shorten an URL:
https://atomk-fcc-urlshort.glitch.me/new/https://www.example.com
Sample output:
{ "url-original": "https://www.example.com", "url-short": "https://atomk-fcc-urlshort.glitch.me/xmpl" }
To access the shortened URL:
https://atomk-fcc-urlshort.glitch.me/xmpl
Sample error output:
{"error":"This route requires a parameter. Use /new/:url instead."}


PGD hPGDS cells allergic inflammation cell Immunol. human activation prostaglandin production Prostaglandin receptor Allergy patients levels mast macrophages Clin. DP/CRTH asthma mice protein role synthase disease express {border-style expression inflammatory inhibitor lung px;} #ffffff;} atopic increased respiratory ./j.jaci... function study Urade eosinophils food IL- Med. acute dendritic dermatitis however, including release Aritake Hematopoietic associated basophils effects nasal potential skin Cells airway allergy cells, development inflammation, inhibition inhibitors knock-out reduced reported therapeutic tissue Nakamura Pharmacol. Sci. beneficial blood bronchial eosinophilic epithelial hematopoietic immune receptors various Allergic Exp. IL-, LPGDS PGE Prostaglandins clinical inflammation. mRNA muscle phase response studies Asthma CRTH Cell Human PGDS anaphylactic bone effect endothelial eosinophil mRNA, marrow-derived murine pro-inflammatory pulmonary showed shown specific treatment type- types viral Biol. Figure Further, TAS- antigen asthmatic cytokine innate lipid lymphoid mediators monocytes mouse peripheral px; reactions rhinitis roles smooth stimulation urinary {font-family Am. DCs M.L. Murata Nat. barrier disorders early effector experimental font-size intestinal involved metabolite ng/ numbers patients, primarily target type vascular Dendritic Heinemann ILC Int. J.W. LPS Macrophages Mol. OVA-induced Respir. Zhao able airways antagonists asthma, basophil bronchoconstriction central contribute double; downstream evidence expressed functional gastrointestinal glutathione group guinea higher i.e., infection late models monocyte-derived neutrophils novel pg/ pg/mL play potentially progression prostanoid rat reduce revealed signalling systemic ./jimmunol... Duchenne’s E.M. Endothelial Eur. Food HQL- Hirai However, Inhibition Interestingly, Konya Lee Lipid Mast Mediat. Narumiya PGH Role Sturm TSLP Tanaka Zhang allergen allergens arachidonic autocrine blocking border-color border-width changes chemoattractant chronic collab: combination considered contrast, diseases enzyme eosinophils, function. functions healthy highly histamine important induce induced induction influx keratinocytes macrophage mediator model mucosa neutrophil pathway pigs potent presentation produce promotes seen signaling solid; source suggested thromboxane {font-style {font-weight ./j.prostaglandins... ./s--- Activation Chem. Christman Eosinophils Expression G.J. Hori ILCs IgE IgE-mediated Inflammation Inhibitors LPGDS-derived Maeda NADPH New Recently, Rep. Satoh T-cells Table Ther. Therapeutic Wang Xiao Yokozeki accumulation activated activity acts antagonist anti-IgE anti-inflammatory article biosynthesis blockage bold causing cells. cellular characterized concentrations contributing courier; crucial dermatitis, differentiation drug efficacy efficient elevated em; emerged essential factor fluid high importance increase infiltration initiation level like linked lipocalin-type mg/kg mice, migration muscular ng/mL nuclear number observed pathogenic pathway. population positive prostaglandins pt;} receptors, responses resulted rhinitis, severe severity sources study, survival symptoms targets tuft upregulation van