<#navmenu-bottom>
* Intro
* Videos
* Design
* Agile
* Refactoring
* FAQ
*
About Me
*
All Sections <#bottom-navmenu>
*
ThoughtWorks
*
*
* home
* topics
o agile
o refactoring
o design
o noSQL
o DSL
o continuous delivery
o microservices
* media
o books
o video
* site
o site introduction
o about me
o FAQ
o content index
o photos
* catalogs
o refactoring
o P of EAA
o EAA dev
o DSL
* feeds
o twitter
o rss
o facebook
* popular
o microservices
o dependency injection
* ThoughtWorks
o blogs
o careers
o products
Contents
Characteristics of a Microservice Architecture
<#CharacteristicsOfAMicroserviceArchitecture>
* Componentization via Services <#ComponentizationViaServices>
* Organized around Business Capabilities
<#OrganizedAroundBusinessCapabilities>
* Products not Projects <#ProductsNotProjects>
* Smart endpoints and dumb pipes <#SmartEndpointsAndDumbPipes>
* Decentralized Governance <#DecentralizedGovernance>
* Decentralized Data Management <#DecentralizedDataManagement>
* Infrastructure Automation <#InfrastructureAutomation>
* Design for failure <#DesignForFailure>
* Evolutionary Design <#EvolutionaryDesign>
Are Microservices the Future? <#AreMicroservicesTheFuture>
Sidebars
* How big is a microservice? <#HowBigIsAMicroservice>
* Microservices and SOA <#MicroservicesAndSoa>
* Many languages, many options <#ManyLanguagesManyOptions>
* Battle-tested standards and enforced standards
<#Battle-testedStandardsAndEnforcedStandards>
* Make it easy to do the right thing <#MakeItEasyToDoTheRightThing>
* The circuit breaker and production ready code
<#TheCircuitBreakerAndProductionReadyCode>
* Synchronous calls considered harmful
<#SynchronousCallsConsideredHarmful>
Microservices
a definition of this new architectural term
/The term "Microservice Architecture" has sprung up over the last few
years to describe a particular way of designing software applications as
suites of independently deployable services. While there is no precise
definition of this architectural style, there are certain common
characteristics around organization around business capability,
automated deployment, intelligence in the endpoints, and decentralized
control of languages and data. /
25 March 2014
Photo of James Lewis
James Lewis
James Lewis is a Principal Consultant at ThoughtWorks and member of the
Technology Advisory Board. James' interest in building applications out
of small collaborating services stems from a background in integrating
enterprise systems at scale. He's built a number of systems using
microservices and has been an active participant in the growing
community for a couple of years.
Photo of Martin Fowler
Martin Fowler
Martin Fowler is an author, speaker, and general loud-mouth on software
development. He's long been puzzled by the problem of how to
componentize software systems, having heard more vague claims than he's
happy with. He hopes that microservices will live up to the early
promise its advocates have found.
*Translations: *Japanese
· Russian
· Korean
·
Portuguese ·
Simplified Chinese
·
Simplfied Chinese
· Persian
Find *similar articles* to this by looking at these tags: popular
· application architecture
· web
services ·
microservices
Contents
* Characteristics of a Microservice Architecture
<#CharacteristicsOfAMicroserviceArchitecture>
o Componentization via Services <#ComponentizationViaServices>
o Organized around Business Capabilities
<#OrganizedAroundBusinessCapabilities>
o Products not Projects <#ProductsNotProjects>
o Smart endpoints and dumb pipes <#SmartEndpointsAndDumbPipes>
o Decentralized Governance <#DecentralizedGovernance>
o Decentralized Data Management <#DecentralizedDataManagement>
o Infrastructure Automation <#InfrastructureAutomation>
o Design for failure <#DesignForFailure>
o Evolutionary Design <#EvolutionaryDesign>
* Are Microservices the Future? <#AreMicroservicesTheFuture>
Sidebars
* How big is a microservice? <#HowBigIsAMicroservice>
* Microservices and SOA <#MicroservicesAndSoa>
* Many languages, many options <#ManyLanguagesManyOptions>
* Battle-tested standards and enforced standards
<#Battle-testedStandardsAndEnforcedStandards>
* Make it easy to do the right thing <#MakeItEasyToDoTheRightThing>
* The circuit breaker and production ready code
<#TheCircuitBreakerAndProductionReadyCode>
* Synchronous calls considered harmful
<#SynchronousCallsConsideredHarmful>
"Microservices" - yet another new term on the crowded streets of
software architecture. Although our natural inclination is to pass such
things by with a contemptuous glance, this bit of terminology describes
a style of software systems that we are finding more and more appealing.
We've seen many projects use this style in the last few years, and
results so far have been positive, so much so that for many of our
colleagues this is becoming the default style for building enterprise
applications. Sadly, however, there's not much information that outlines
what the microservice style is and how to do it.
In short, the microservice architectural style [1] <#footnote-etymology>
is an approach to developing a single application as a suite of small
services, each running in its own process and communicating with
lightweight mechanisms, often an HTTP resource API. These services are
built around business capabilities and independently deployable by fully
automated deployment machinery. There is a bare minimum of centralized
management of these services, which may be written in different
programming languages and use different data storage technologies.
My Microservices Resource Guide
provides links to the best articles, videos, books, and podcasts about
microservices.
To start explaining the microservice style it's useful to compare it to
the monolithic style: a monolithic application built as a single unit.
Enterprise Applications are often built in three main parts: a
client-side user interface (consisting of HTML pages and javascript
running in a browser on the user's machine) a database (consisting of
many tables inserted into a common, and usually relational, database
management system), and a server-side application. The server-side
application will handle HTTP requests, execute domain logic, retrieve
and update data from the database, and select and populate HTML views to
be sent to the browser. This server-side application is a /monolith/ - a
single logical executable[2] <#footnote-monolith>. Any changes to the
system involve building and deploying a new version of the server-side
application.
Such a monolithic server is a natural way to approach building such a
system. All your logic for handling a request runs in a single process,
allowing you to use the basic features of your language to divide up the
application into classes, functions, and namespaces. With some care, you
can run and test the application on a developer's laptop, and use a
deployment pipeline to ensure that changes are properly tested and
deployed into production. You can horizontally scale the monolith by
running many instances behind a load-balancer.
Monolithic applications can be successful, but increasingly people are
feeling frustrations with them - especially as more applications are
being deployed to the cloud . Change cycles are tied together - a change
made to a small part of the application, requires the entire monolith to
be rebuilt and deployed. Over time it's often hard to keep a good
modular structure, making it harder to keep changes that ought to only
affect one module within that module. Scaling requires scaling of the
entire application rather than parts of it that require greater resource.
Figure 1: Monoliths and Microservices
These frustrations have led to the microservice architectural style:
building applications as suites of services. As well as the fact that
services are independently deployable and scalable, each service also
provides a firm module boundary, even allowing for different services to
be written in different programming languages. They can also be managed
by different teams .
We do not claim that the microservice style is novel or innovative, its
roots go back at least to the design principles of Unix. But we do think
that not enough people consider a microservice architecture and that
many software developments would be better off if they used it.
------------------------------------------------------------------------
Characteristics of a Microservice Architecture
We cannot say there is a formal definition of the microservices
architectural style, but we can attempt to describe what we see as
common characteristics for architectures that fit the label. As with any
definition that outlines common characteristics, not all microservice
architectures have all the characteristics, but we do expect that most
microservice architectures exhibit most characteristics. While we
authors have been active members of this rather loose community, our
intention is to attempt a description of what we see in our own work and
in similar efforts by teams we know of. In particular we are not laying
down some definition to conform to.
Componentization via Services
For as long as we've been involved in the software industry, there's
been a desire to build systems by plugging together components, much in
the way we see things are made in the physical world. During the last
couple of decades we've seen considerable progress with large
compendiums of common libraries that are part of most language platforms.
When talking about components we run into the difficult definition of
what makes a component. Our definition is that a *component* is a unit
of software that is independently replaceable and upgradeable.
Microservice architectures will use libraries, but their primary way of
componentizing their own software is by breaking down into services. We
define *libraries* as components that are linked into a program and
called using in-memory function calls, while *services* are
out-of-process components who communicate with a mechanism such as a web
service request, or remote procedure call. (This is a different concept
to that of a service object in many OO programs [3]
<#footnote-service-object>.)
One main reason for using services as components (rather than libraries)
is that services are independently deployable. If you have an
application [4] <#footnote-application> that consists of a multiple
libraries in a single process, a change to any single component results
in having to redeploy the entire application. But if that application is
decomposed into multiple services, you can expect many single service
changes to only require that service to be redeployed. That's not an
absolute, some changes will change service interfaces resulting in some
coordination, but the aim of a good microservice architecture is to
minimize these through cohesive service boundaries and evolution
mechanisms in the service contracts.
Another consequence of using services as components is a more explicit
component interface. Most languages do not have a good mechanism for
defining an explicit Published Interface
. Often it's
only documentation and discipline that prevents clients breaking a
component's encapsulation, leading to overly-tight coupling between
components. Services make it easier to avoid this by using explicit
remote call mechanisms.
Using services like this does have downsides. Remote calls are more
expensive than in-process calls, and thus remote APIs need to be
coarser-grained, which is often more awkward to use. If you need to
change the allocation of responsibilities between components, such
movements of behavior are harder to do when you're crossing process
boundaries.
At a first approximation, we can observe that services map to runtime
processes, but that is only a first approximation. A service may consist
of multiple processes that will always be developed and deployed
together, such as an application process and a database that's only used
by that service.
Organized around Business Capabilities
When looking to split a large application into parts, often management
focuses on the technology layer, leading to UI teams, server-side logic
teams, and database teams. When teams are separated along these lines,
even simple changes can lead to a cross-team project taking time and
budgetary approval. A smart team will optimise around this and plump for
the lesser of two evils - just force the logic into whichever
application they have access to. Logic everywhere in other words. This
is an example of Conway's Law[5] <#footnote-conwayslaw> in action.
Any organization that designs a system (defined broadly) will
produce a design whose structure is a copy of the organization's
communication structure.
-- Melvyn Conway, 1967
Figure 2: Conway's Law in action
The microservice approach to division is different, splitting up into
services organized around *business capability*. Such services take a
broad-stack implementation of software for that business area, including
user-interface, persistant storage, and any external collaborations.
Consequently the teams are cross-functional, including the full range of
skills required for the development: user-experience, database, and
project management.
Figure 3: Service boundaries reinforced by team boundaries
How big is a microservice?
Although “microservice” has become a popular name for this architectural
style, its name does lead to an unfortunate focus on the size of
service, and arguments about what constitutes “micro”. In our
conversations with microservice practitioners, we see a range of sizes
of services. The largest sizes reported follow Amazon's notion of the
Two Pizza Team (i.e. the whole team can be fed by two pizzas), meaning
no more than a dozen people. On the smaller size scale we've seen setups
where a team of half-a-dozen would support half-a-dozen services.
This leads to the question of whether there are sufficiently large
differences within this size range that the service-per-dozen-people and
service-per-person sizes shouldn't be lumped under one microservices
label. At the moment we think it's better to group them together, but
it's certainly possible that we'll change our mind as we explore this
style further.
One company organised in this way is www.comparethemarket.com
. Cross functional teams are
responsible for building and operating each product and each product is
split out into a number of individual services communicating via a
message bus.
Large monolithic applications can always be modularized around business
capabilities too, although that's not the common case. Certainly we
would urge a large team building a monolithic application to divide
itself along business lines. The main issue we have seen here, is that
they tend to be organised around /too many/ contexts. If the monolith
spans many of these modular boundaries it can be difficult for
individual members of a team to fit them into their short-term memory.
Additionally we see that the modular lines require a great deal of
discipline to enforce. The necessarily more explicit separation required
by service components makes it easier to keep the team boundaries clear.
Products not Projects
Most application development efforts that we see use a project model:
where the aim is to deliver some piece of software which is then
considered to be completed. On completion the software is handed over to
a maintenance organization and the project team that built it is disbanded.
Microservice proponents tend to avoid this model, preferring instead the
notion that a team should own a product over its full lifetime. A common
inspiration for this is Amazon's notion of "you build, you run it"
where a development team
takes full responsibility for the software in production. This brings
developers into day-to-day contact with how their software behaves in
production and increases contact with their users, as they have to take
on at least some of the support burden.
The product mentality, ties in with the linkage to business
capabilities. Rather than looking at the software as a set of
functionality to be completed, there is an on-going relationship where
the question is how can software assist its users to enhance the
business capability.
There's no reason why this same approach can't be taken with monolithic
applications, but the smaller granularity of services can make it easier
to create the personal relationships between service developers and
their users.
Smart endpoints and dumb pipes
When building communication structures between different processes,
we've seen many products and approaches that stress putting significant
smarts into the communication mechanism itself. A good example of this
is the Enterprise Service Bus (ESB), where ESB products often include
sophisticated facilities for message routing, choreography,
transformation, and applying business rules.
Microservices and SOA
When we've talked about microservices a common question is whether this
is just Service Oriented Architecture (SOA) that we saw a decade ago.
There is merit to this point, because the microservice style is very
similar to what some advocates of SOA have been in favor of. The
problem, however, is that SOA means too many different things
, and that
most of the time that we come across something called "SOA" it's
significantly different to the style we're describing here, usually due
to a focus on ESBs used to integrate monolithic applications.
In particular we have seen so many botched implementations of service
orientation - from the tendency to hide complexity away in ESB's [6]
<#footnote-esb>, to failed multi-year initiatives that cost millions and
deliver no value, to centralised governance models that actively inhibit
change, that it is sometimes difficult to see past these problems.
Certainly, many of the techniques in use in the microservice community
have grown from the experiences of developers integrating services in
large organisations. The Tolerant Reader
pattern is an
example of this. Efforts to use the web have contributed, using simple
protocols is another approach derived from these experiences - a
reaction away from central standards that have reached a complexity that
is, frankly, breathtaking
. (Any time you need
an ontology to manage your ontologies you know you are in deep trouble.)
This common manifestation of SOA has led some microservice advocates to
reject the SOA label entirely, although others consider microservices to
be one form of SOA [7] <#footnote-fine-grained>, perhaps /service
orientation done right/. Either way, the fact that SOA means such
different things means it's valuable to have a term that more crisply
defines this architectural style.
The microservice community favours an alternative approach: /smart
endpoints and dumb pipes/. Applications built from microservices aim to
be as decoupled and as cohesive as possible - they own their own domain
logic and act more as filters in the classical Unix sense - receiving a
request, applying logic as appropriate and producing a response. These
are choreographed using simple RESTish protocols rather than complex
protocols such as WS-Choreography or BPEL or orchestration by a central
tool.
The two protocols used most commonly are HTTP request-response with
resource API's and lightweight messaging[8] <#footnote-protobufs>. The
best expression of the first is
Be of the web, not behind the web
-- Ian Robinson
Microservice teams use the principles and protocols that the world wide
web (and to a large extent, Unix) is built on. Often used resources can
be cached with very little effort on the part of developers or
operations folk.
The second approach in common use is messaging over a lightweight
message bus. The infrastructure chosen is typically dumb (dumb as in
acts as a message router only) - simple implementations such as RabbitMQ
or ZeroMQ don't do much more than provide a reliable asynchronous fabric
- the smarts still live in the end points that are producing and
consuming messages; in the services.
In a monolith, the components are executing in-process and communication
between them is via either method invocation or function call. The
biggest issue in changing a monolith into microservices lies in changing
the communication pattern. A naive conversion from in-memory method
calls to RPC leads to chatty communications which don't perform well.
Instead you need to replace the fine-grained communication with a
coarser -grained approach.
Decentralized Governance
One of the consequences of centralised governance is the tendency to
standardise on single technology platforms. Experience shows that this
approach is constricting - not every problem is a nail and not every
solution a hammer. We prefer using the right tool for the job and while
monolithic applications can take advantage of different languages to a
certain extent, it isn't that common.
Splitting the monolith's components out into services we have a choice
when building each of them. You want to use Node.js to standup a simple
reports page? Go for it. C++ for a particularly gnarly near-real-time
component? Fine. You want to swap in a different flavour of database
that better suits the read behaviour of one component? We have the
technology to rebuild him.
Of course, just because you /can/ do something, doesn't mean you
/should/ - but partitioning your system in this way means you have the
option.
Teams building microservices prefer a different approach to standards
too. Rather than use a set of defined standards written down somewhere
on paper they prefer the idea of producing useful tools that other
developers can use to solve similar problems to the ones they are
facing. These tools are usually harvested from implementations and
shared with a wider group, sometimes, but not exclusively using an
internal open source model. Now that git and github have become the de
facto version control system of choice, open source practices are
becoming more and more common in-house .
Netflix is a good example of an organisation that follows this
philosophy. Sharing useful and, above all, battle-tested code as
libraries encourages other developers to solve similar problems in
similar ways yet leaves the door open to picking a different approach if
required. Shared libraries tend to be focused on common problems of data
storage, inter-process communication and as we discuss further below,
infrastructure automation.
For the microservice community, overheads are particularly unattractive.
That isn't to say that the community doesn't value service contracts.
Quite the opposite, since there tend to be many more of them. It's just
that they are looking at different ways of managing those contracts.
Patterns like Tolerant Reader
and Consumer-Driven
Contracts
are
often applied to microservices. These aid service contracts in evolving
independently. Executing consumer driven contracts as part of your build
increases confidence and provides fast feedback on whether your services
are functioning. Indeed we know of a team in Australia who drive the
build of new services with consumer driven contracts. They use simple
tools that allow them to define the contract for a service. This becomes
part of the automated build before code for the new service is even
written. The service is then built out only to the point where it
satisfies the contract - an elegant approach to avoid the 'YAGNI'[9]
<#footnote-YAGNI> dilemma when building new software. These techniques
and the tooling growing up around them, limit the need for central
contract management by decreasing the temporal coupling between services.
Many languages, many options
The growth of JVM as a platform is just the latest example of mixing
languages within a common platform. It's been common practice to
shell-out to a higher level language to take advantage of higher level
abstractions for decades. As is dropping down to the metal and writing
performance sensitive code in a lower level one. However, many monoliths
don't need this level of performance optimisation nor are DSL's and
higher level abstractions that common (to our dismay). Instead monoliths
are usually single language and the tendency is to limit the number of
technologies in use [10] <#footnote-many-languages>.
Perhaps the apogee of decentralised governance is the build it / run it
ethos popularised by Amazon. Teams are responsible for all aspects of
the software they build including operating the software 24/7.
Devolution of this level of responsibility is definitely not the norm
but we do see more and more companies pushing responsibility to the
development teams. Netflix is another organisation that has adopted this
ethos[11] <#footnote-netflix-flowcon>. Being woken up at 3am every night
by your pager is certainly a powerful incentive to focus on quality when
writing your code. These ideas are about as far away from the
traditional centralized governance model as it is possible to be.
Decentralized Data Management
Decentralization of data management presents in a number of different
ways. At the most abstract level, it means that the conceptual model of
the world will differ between systems. This is a common issue when
integrating across a large enterprise, the sales view of a customer will
differ from the support view. Some things that are called customers in
the sales view may not appear at all in the support view. Those that do
may have different attributes and (worse) common attributes with subtly
different semantics.
Battle-tested standards and enforced standards
It's a bit of a dichotomy that microservice teams tend to eschew the
kind of rigid enforced standards laid down by enterprise architecture
groups but will happily use and even evangelise the use of open
standards such as HTTP, ATOM and other microformats.
The key difference is how the standards are developed and how they are
enforced. Standards managed by groups such as the IETF only /become/
standards when there are several live implementations of them in the
wider world and which often grow from successful open-source projects.
These standards are a world apart from many in a corporate world, which
are often developed by groups that have little recent programming
experience or overly influenced by vendors.
This issue is common between applications, but can also occur /within/
applications, particular when that application is divided into separate
components. A useful way of thinking about this is the Domain-Driven
Design notion of Bounded Context
. DDD divides a
complex domain up into multiple bounded contexts and maps out the
relationships between them. This process is useful for both monolithic
and microservice architectures, but there is a natural correlation
between service and context boundaries that helps clarify, and as we
describe in the section on business capabilities, reinforce the separations.
As well as decentralizing decisions about conceptual models,
microservices also decentralize data storage decisions. While monolithic
applications prefer a single logical database for persistant data,
enterprises often prefer a single database across a range of
applications - many of these decisions driven through vendor's
commercial models around licensing. Microservices prefer letting each
service manage its own database, either different instances of the same
database technology, or entirely different database systems - an
approach called Polyglot Persistence
. You can use
polyglot persistence in a monolith, but it appears more frequently with
microservices.
Decentralizing responsibility for data across microservices has
implications for managing updates. The common approach to dealing with
updates has been to use transactions to guarantee consistency when
updating multiple resources. This approach is often used within monoliths.
Using transactions like this helps with consistency, but imposes
significant temporal coupling, which is problematic across multiple
services. Distributed transactions are notoriously difficult to
implement and as a consequence microservice architectures emphasize
transactionless coordination between services
, with explicit
recognition that consistency may only be eventual consistency and
problems are dealt with by compensating operations.
Choosing to manage inconsistencies in this way is a new challenge for
many development teams, but it is one that often matches business
practice. Often businesses handle a degree of inconsistency in order to
respond quickly to demand, while having some kind of reversal process to
deal with mistakes. The trade-off is worth it as long as the cost of
fixing mistakes is less than the cost of lost business under greater
consistency.
Infrastructure Automation
Infrastructure automation techniques have evolved enormously over the
last few years - the evolution of the cloud and AWS in particular has
reduced the operational complexity of building, deploying and operating
microservices.
Many of the products or systems being build with microservices are being
built by teams with extensive experience of Continuous Delivery
and it's
precursor, Continuous Integration
. Teams
building software this way make extensive use of infrastructure
automation techniques. This is illustrated in the build pipeline shown
below.
Figure 5: basic build pipeline
Since this isn't an article on Continuous Delivery we will call
attention to just a couple of key features here. We want as much
confidence as possible that our software is working, so we run lots of
*automated tests*. Promotion of working software 'up' the pipeline means
we *automate deployment* to each new environment.
Make it easy to do the right thing
One side effect we have found of increased automation as a consequence
of continuous delivery and deployment is the creation of useful tools to
help developers and operations folk. Tooling for creating artefacts,
managing codebases, standing up simple services or for adding standard
monitoring and logging are pretty common now. The best example on the
web is probably Netflix's set of open source tools
, but there are others including Dropwizard
which we have used extensively.
A monolithic application will be built, tested and pushed through these
environments quite happlily. It turns out that once you have invested in
automating the path to production for a monolith, then deploying /more/
applications doesn't seem so scary any more. Remember, one of the aims
of CD is to make deployment boring, so whether its one or three
applications, as long as its still boring it doesn't matter[12]
<#footnote-trickycd>.
Another area where we see teams using extensive infrastructure
automation is when managing microservices in production. In contrast to
our assertion above that as long as deployment is boring there isn't
that much difference between monoliths and microservices, the
operational landscape for each can be strikingly different.
Figure 6: Module deployment often differs
Design for failure
A consequence of using services as components, is that applications need
to be designed so that they can tolerate the failure of services. Any
service call could fail due to unavailability of the supplier, the
client has to respond to this as gracefully as possible. This is a
disadvantage compared to a monolithic design as it introduces additional
complexity to handle it. The consequence is that microservice teams
constantly reflect on how service failures affect the user experience.
Netflix's Simian Army induces
failures of services and even datacenters during the working day to test
both the application's resilience and monitoring.
The circuit breaker and production ready code
Circuit Breaker
appears in Release It!
alongside other patterns such as Bulkhead and Timeout. Implemented
together, these patterns are crucially important when building
communicating applications. This Netflix blog entry
does
a great job of explaining their application of them.
This kind of automated testing in production would be enough to give
most operation groups the kind of shivers usually preceding a week off
work. This isn't to say that monolithic architectural styles aren't
capable of sophisticated monitoring setups - it's just less common in
our experience.
Since services can fail at any time, it's important to be able to detect
the failures quickly and, if possible, automatically restore service.
Microservice applications put a lot of emphasis on real-time monitoring
of the application, checking both architectural elements (how many
requests per second is the database getting) and business relevant
metrics (such as how many orders per minute are received). Semantic
monitoring can provide an early warning system of something going wrong
that triggers development teams to follow up and investigate.
This is particularly important to a microservices architecture because
the microservice preference towards choreography and event collaboration
leads to
emergent behavior. While many pundits praise the value of serendipitous
emergence, the truth is that emergent behavior can sometimes be a bad
thing. Monitoring is vital to spot bad emergent behavior quickly so it
can be fixed.
Synchronous calls considered harmful
Any time you have a number of synchronous calls between services you
will encounter the multiplicative effect of downtime. Simply, this is
when the downtime of your system becomes the product of the downtimes of
the individual components.  At www.guardian.co.uk they have
implemented a simple rule on the new platform - one synchronous call per
user request while at Netflix, their platform API redesign has built
asynchronicity into the API fabric.
Monoliths can be built to be as transparent as a microservice - in fact,
they should be. The difference is that you absolutely need to know when
services running in different processes are disconnected. With libraries
within the same process this kind of transparency is less likely to be
useful.
Microservice teams would expect to see sophisticated monitoring and
logging setups for each individual service such as dashboards showing
up/down status and a variety of operational and business relevant
metrics. Details on circuit breaker status, current throughput and
latency are other examples we often encounter in the wild.
Evolutionary Design
Microservice practitioners, usually have come from an evolutionary
design background and see service decomposition as a further tool to
enable application developers to control changes in their application
without slowing down change. Change control doesn't necessarily mean
change reduction - with the right attitudes and tools you can make
frequent, fast, and well-controlled changes to software.
Whenever you try to break a software system into components, you're
faced with the decision of how to divide up the pieces - what are the
principles on which we decide to slice up our application? The key
property of a component is the notion of independent replacement and
upgradeability[13] <#footnote-RCA> - which implies we look for points
where we can imagine rewriting a component without affecting its
collaborators. Indeed many microservice groups take this further by
explicitly expecting many services to be scrapped rather than evolved in
the longer term.
The Guardian website is a good example of an application that was
designed and built as a monolith, but has been evolving in a
microservice direction. The monolith still is the core of the website,
but they prefer to add new features by building microservices that use
the monolith's API. This approach is particularly handy for features
that are inherently temporary, such as specialized pages to handle a
sporting event. Such a part of the website can quickly be put together
using rapid development languages, and removed once the event is over.
We've seen similar approaches at a financial institution where new
services are added for a market opportunity and discarded after a few
months or even weeks.
This emphasis on replaceability is a special case of a more general
principle of modular design, which is to drive modularity through the
pattern of change [14] <#footnote-beck-rate-of-change>. You want to keep
things that change at the same time in the same module. Parts of a
system that change rarely should be in different services to those that
are currently undergoing lots of churn. If you find yourself repeatedly
changing two services together, that's a sign that they should be merged.
Putting components into services adds an opportunity for more granular
release planning. With a monolith any changes require a full build and
deployment of the entire application. With microservices, however, you
only need to redeploy the service(s) you modified. This can simplify and
speed up the release process. The downside is that you have to worry
about changes to one service breaking its consumers. The traditional
integration approach is to try to deal with this problem using
versioning, but the preference in the microservice world is to only use
versioning as a last resort
. We
can avoid a lot of versioning by designing services to be as tolerant as
possible to changes in their suppliers.
------------------------------------------------------------------------
Are Microservices the Future?
Our main aim in writing this article is to explain the major ideas and
principles of microservices. By taking the time to do this we clearly
think that the microservices architectural style is an important idea -
one worth serious consideration for enterprise applications. We have
recently built several systems using the style and know of others who
have used and favor this approach.
Those we know about who are in some way pioneering the architectural
style include Amazon, Netflix, The Guardian
, the UK Government Digital Service
, realestate.com.au
, Forward and
comparethemarket.com . The conference
circuit in 2013 was full of examples of companies that are moving to
something that would class as microservices - including Travis CI. In
addition there are plenty of organizations that have long been doing
what we would class as microservices, but without ever using the name.
(Often this is labelled as SOA - although, as we've said, SOA comes in
many contradictory forms. [15] <#footnote-already>)
Despite these positive experiences, however, we aren't arguing that we
are certain that microservices are the future direction for software
architectures. While our experiences so far are positive compared to
monolithic applications, we're conscious of the fact that not enough
time has passed for us to make a full judgement.
Our colleague Sam Newman spent most of 2014 working on a book that
captures our experiences with building microservices
.
This should be your next step if you want a deeper dive into the topic.
Often the true consequences of your architectural decisions are only
evident several years after you made them. We have seen projects where a
good team, with a strong desire for modularity, has built a monolithic
architecture that has decayed over the years. Many people believe that
such decay is less likely with microservices, since the service
boundaries are explicit and hard to patch around. Yet until we see
enough systems with enough age, we can't truly assess how microservice
architectures mature.
There are certainly reasons why one might expect microservices to mature
poorly. In any effort at componentization, success depends on how well
the software fits into components. It's hard to figure out exactly where
the component boundaries should lie. Evolutionary design recognizes the
difficulties of getting boundaries right and thus the importance of it
being easy to refactor them. But when your components are services with
remote communications, then refactoring is much harder than with
in-process libraries. Moving code is difficult across service
boundaries, any interface changes need to be coordinated between
participants, layers of backwards compatibility need to be added, and
testing is made more complicated.
Another issue is If the components do not compose cleanly, then all you
are doing is shifting complexity from inside a component to the
connections between components. Not just does this just move complexity
around, it moves it to a place that's less explicit and harder to
control. It's easy to think things are better when you are looking at
the inside of a small, simple component, while missing messy connections
between services.
Finally, there is the factor of team skill. New techniques tend to be
adopted by more skillful teams. But a technique that is more effective
for a more skillful team isn't necessarily going to work for less
skillful teams. We've seen plenty of cases of less skillful teams
building messy monolithic architectures, but it takes time to see what
happens when this kind of mess occurs with microservices. A poor team
will always create a poor system - it's very hard to tell if
microservices reduce the mess in this case or make it worse.
One reasonable argument we've heard is that you shouldn't start with a
microservices architecture. Instead begin with a monolith
, keep it modular,
and split it into microservices once the monolith becomes a problem.
(Although this advice isn't ideal
, since a
good in-process interface is usually not a good service interface.)
So we write this with cautious optimism. So far, we've seen enough about
the microservice style to feel that it can be a worthwhile road to tread
. We can't say for sure where
we'll end up, but one of the challenges of software development is that
you can only make decisions based on the imperfect information that you
currently have to hand.
------------------------------------------------------------------------
Share:
if you found this article useful, please share it. I appreciate the
feedback and encouragement
For articles on similar topics…
…take a look at the following tags:
popular application
architecture
web
services
microservices
Footnotes
1: The term "microservice" was discussed at a workshop of software
architects near Venice in May, 2011 to describe what the participants
saw as a common architectural style that many of them had been recently
exploring. In May 2012, the same group decided on "microservices" as the
most appropriate name. James presented some of these ideas as a case
study in March 2012 at 33rd Degree in Krakow in Microservices - Java,
the Unix Way as did Fred George
about the same time
. Adrian
Cockcroft at Netflix, describing this approach as "fine grained SOA" was
pioneering the style at web scale as were many of the others mentioned
in this article - Joe Walnes, Dan North, Evan Botcher and Graham Tackley.
2: The term monolith has been in use by the Unix community for some
time. It appears in The Art of Unix Programming
to describe systems that get too big.
3: Many object-oriented designers, including ourselves, use the term
service object in the Domain-Driven Design
sense for an object that carries out a significant process that isn't
tied to an entity. This is a different concept to how we're using
"service" in this article. Sadly the term service has both meanings and
we have to live with the polyseme.
4: We consider an application to be a social construction
that binds
together a code base, group of functionality, and body of funding.
5: The original paper can be found on Melvyn Conway's website here
6: We can't resist mentioning Jim Webber's statement that ESB stands for
"Egregious Spaghetti Box"
.
7: Netflix makes the link explicit - until recently referring to their
architectural style as fine-grained SOA.
8: At extremes of scale, organisations often move to binary protocols -
protobufs for example.  Most web properties and
certainly the vast majority of enterprises don't need to make this
tradeoff - transparency can be a big win.
9: "YAGNI" or "You Aren't Going To Need It" is an XP principle
and exhortation to not add
features until you know you need them.
10: It's a little disengenuous of us to claim that monoliths are single
language - in order to build systems on todays web, you probably need to
know JavaScript and XHTML, CSS, your server side language of choice, SQL
and an ORM dialect. Hardly single language, but you know what we mean.
11: Adrian Cockcroft specifically mentions "developer self-service" and
"Developers run what they wrote"(sic) in this excellent presentation
delivered at Flowcon in November, 2013.
12: We are being a little disengenuous here. Obviously deploying more
services, in more complex topologies is more difficult than deploying a
single monolith. Fortunately, patterns reduce this complexity -
investment in tooling is still a must though.
13: In fact, Dan North refers to this style as /Replaceable Component
Architecture/ rather than microservices. Since this seems to talk to a
subset of the characteristics we prefer the latter.
14: Kent Beck highlights this as one his design principles in
Implementation Patterns
.
15: And SOA is hardly the root of this history. I remember people saying
"we've been doing this for years" when the SOA term appeared at the
beginning of the century. One argument was that this style sees its
roots as the way COBOL programs communicated via data files in the
earliest days of enterprise computing. In another direction, one could
argue that microservices are the same thing as the Erlang programming
model, but applied to an enterprise application context.
------------------------------------------------------------------------
References
While this is not an exhaustive list, there are a number of sources that
practitioners have drawn inspiration from or which espouse a similar
philosophy to that described in this article.
Blogs and online articles
* Clemens Vasters’ blog on cloud at microsoft
* David Morgantini’s introduction to the topic on his blog
* 12 factor apps from Heroku
* UK Government Digital Service design principles
* Jimmy Nilsson’s blog and article on
infoq about Cloud Chunk Computing
* Alistair Cockburn on Hexagonal architectures
Books
* Release it
* Rest in practice
* Web API Design (free ebook)
. Brian Mulloy,
Apigee.
* Enterprise Integration Patterns
* Art of unix programming
* Growing Object Oriented Software, Guided by Tests
* The Modern Firm: Organizational Design for Performance and Growth
* Continuous Delivery: Reliable Software Releases through Build, Test,
and Deployment Automation
* Domain-Driven Design: Tackling Complexity in the Heart of Software
Presentations
* Architecture without Architects
. Erik Doernenburg.
* Does my bus look big in this?
. Jim Webber and
Martin Fowler, QCon 2008
* Guerilla SOA
. Jim
Webber, 2006
* Patterns of Effective Delivery . Dan
North, 2011.
* Adrian Cockcroft's slideshare channel
.
* Hydras and Hypermedia . Ian Robinson,
JavaZone 2010
* Justice will take a million intricate moves. Leonard Richardson,
Qcon 2008.
* Java, the UNIX way . James Lewis,
JavaZone 2012
* Micro services architecture
.
Fred George, YOW! 2012
* Democratising attention data at guardian.co.uk
. Graham Tackley, GOTO Aarhus 2013
* Functional Reactive Programming with RxJava
. Ben Christensen, GOTO Aarhus 2013
(registration required).
* Breaking the Monolith
. Stefan
Tilkov, May 2012.
Papers
* L. Lamport, "The Implementation of Reliable Distributed Multiprocess
Systems", 1978 http://
research.microsoft.com/en-us/um/people/lamport/pubs/implementation.pdf
* L. Lamport, R. Shostak, M. Pease, "The Byzantine Generals Problem",
1982 (available at) http://
www.cs.cornell.edu/courses/cs614/2004sp/papers/lsp82.pdf
* R.T. Fielding, "Architectural Styles and the Design of Network-based
Software Architectures", 2000
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
* E. A. Brewer, "Towards Robust Distributed Systems", 2000
http://www.cs.berkeley.edu/ ~brewer/cs262b-2004/PODC-keynote.pdf
* E. Brewer, "CAP Twelve Years Later: How the 'Rules' Have Changed",
2012, http://
www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed
------------------------------------------------------------------------
Further Reading
The above list captures the
references we used when we originally wrote this article in early 2014.
For an up to date list of sources for more information, take a look at
the Microservice Resource Guide .
Significant Revisions
/25 March 2014: /last installment on are microservices the future?
/24 March 2014: /added section on evolutionary design
/19 March 2014: /added sections on infrastructure automation and design
for failure
/18 March 2014: /added section on decentralized data
/17 March 2014: /added section on decentralized governance
/14 March 2014: /added section on smart endpoint and dumb pipes
/13 March 2014: /added section on products not projects
/12 March 2014: /added section on organizing around business capabilities
/10 March 2014: /published first installment
* home
* topics
o agile
o refactoring
o design
o noSQL
o DSL
o continuous delivery
o microservices
* media
o books
o video
* site
o site introduction
o about me
o FAQ
o content index
o photos
* catalogs
o refactoring
o P of EAA
o EAA dev
o DSL
* feeds
o twitter
o rss
o facebook
* popular
o microservices
o dependency injection
* ThoughtWorks
o blogs
o careers
o products
© Martin Fowler | Privacy Policy
| Disclosures


Optical Fitting - AGN from SDSS |
Radio Fitting - NH3 example |
Radio Fitting - H2CO RADEX example |
Doublet Fitting - SII |
Simple Radio Fitting: HCO+ example
import pyspeckit
# load a FITS-compliant spectrum
spec = pyspeckit.Spectrum('10074-190_HCOp.fits')
# The units are originally frequency (check this by printing spec.xarr.units).
# I want to know the velocity. Convert!
# Note that this only works because the reference frequency is set in the header
spec.xarr.frequency_to_velocity()
# Default conversion is to m/s, but we traditionally work in km/s
spec.xarr.convert_to_unit('km/s')
# plot it up!
spec.plotter()
# Subtract a baseline (the data is only 'mostly' reduced)
spec.baseline()
# Fit a gaussian. We know it will be an emission line, so we force a positive guess
spec.specfit(negamp=False)
# Note that the errors on the fits are larger than the fitted parameters.
# That's because this spectrum did not have an error assigned to it.
# Let's use the residuals:
spec.specfit.plotresiduals()
# Now, refit with error determined from the residuals:
# (we pass in guesses to save time / make sure nothing changes)
spec.specfit(guesses=spec.specfit.modelpars)
# Save the figures to put on the web....
spec.plotter.figure.savefig("simple_fit_example_HCOp.png")
spec.specfit.residualaxis.figure.savefig("simple_fit_example_HCOp_residuals.png")
# Also, let's crop out stuff we don't want...
spec.crop(-100,100)
# replot after cropping (crop doesn't auto-refresh)
spec.plotter()
# replot the fit without re-fitting
spec.specfit.plot_fit()
# show the annotations again
spec.specfit.annotate()
spec.plotter.figure.savefig("simple_fit_example_HCOp_cropped.png")
|


{% extends PATH+"/inc/layout_citizen.html" %} {% block staff_content %} {# this is a macro: pass the id of the selected iteam. Code in inc/layout.html #} {{ horizontal_nav('none') }} {% include PATH + "/inc/app_top.html" %}
Evidence collected so far:


{% extends "rest_framework/base.html" %} {% comment 'LICENSE' %} Copyright (C) 2023 by eHealth Africa : http://www.eHealthAfrica.org See the NOTICE file distributed with this work for additional information regarding copyright ownership. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. {% endcomment %} {% load i18n %} {% load static %} {% block title %}{{ app_name }}{% endblock title %} {% block meta %} {% include 'eha/meta.html' %} {% include 'eha/favicon.html' %} {% endblock meta %} {% block style %} {% include 'eha/styles.html' %} {% endblock style %} {% block body %}
{% if form.errors.items|length == 1 %} {% trans 'Please correct the error below.' %} {% else %} {% trans 'Please correct the errors below.' %} {% endif %}
{% endif %} {% if user.is_authenticated %}{% blocktrans trimmed %} You are authenticated as {{ username }}, but are not authorized to access this page. Would you like to login to a different account? {% endblocktrans %}
{% endif %}


SharedExpressionsProcessor
Swifternalization contains some built-in country-related shared expressions. Developer can create its own expressions in expressions.json file for base and preferred languages.
The class is responsible for proper loading the built-in shared ones and those loaded from project’s files. It handles overriding of built-in and loads those from Base and preferred language version.
It always load base expressions, then looking for language specific. If in Base are some expressions that overrides built-ins, that’s fine. The class adds developer’s custom expressions and adds only those of built-in that are not contained in the Base.
The same is for preferred languages but also here what is important is that at first preferred language file expressions are loaded, then if something different is defined in Base it will be also loaded and then the built-in expression that differs.
-
Method takes expression for both Base and preferred language localizations and also internally loads built-in expressions, combine them and returns expressions for Base and prefered language.
Declaration
Swift
class func processSharedExpression(preferedLanguage: CountryCode, preferedLanguageExpressions: [SharedExpression], baseLanguageExpressions: [SharedExpression]) -> [SharedExpression]
Parameters
preferedLanguage
A user device’s language.
preferedLanguageExpressions
Expressions from expressions.json
baseLanguageExpressions
Expressions from base section of expression.json.
Return Value
array of shared expressions for Base and preferred language.
-
Method loads built-in framework’s built-in expressions for specific language.
Declaration
Swift
private class func loadBuiltInExpressions(language: CountryCode) -> [SharedExpression]
Parameters
language
A preferred user’s language.
Return Value
Shared expressions for specific language. If there is no


About
This sample uses a deep neural network to predict the action you will perform based on the history of previous actions you've performed. It records every page you visit and uses that information to continue learning and improve its predictions. Learning is performed asynchronously while the browser is idle so performance is not affected. The entire neural network is constructed on the browser and is WebGL accelerated for fast performance. No backend server is needed.
Usage
Choose a few patterns and click around the site. Your actions will be recorded to local storage. Once you have about 100 clicks, hit the "Learn" button. This will create and train the initial model. After that, when you click around, a graph of predicted next actions will be shown, and "Quick Actions" will be displayed in the lower right corner.
Predictions
Training
Once the model is initially trained, it will automatically update itself as your history is updated.
To train the model from scratch, press the button below. Results are recorded in the console. In general, you should have at least 100 interactions before the model will be very accurate.


After limited rainfall during the first half of the summer of 2014, river levels are running low. Click the points on the map to have a look at the current water levels of various rivers in the south east.


Elder Casian:
What's this? Ah, you must be the agent of Shadow Fox...
I see you found the prophecy...
A female preacher of the Revolutionaries of Dusk heard the angel pleading for help, but we were unable to determine the angel's location.
We have healing medicine ready...
"Tobias told me that you could locate the angel if I gave you this prophecy."


1 reference to ResolveAlias
System.Management.Automation (1)
engine\runtime\Binding\Binders.cs (1)
5692
memberInfo =
ResolveAlias
(alias, target, aliases, aliasRestrictions);


| ?help |
Displays all the commands of the server |
| ?mute <@user> <@user> |
Mutes a user in the server |
| ?unmute <@user> |
unmutes a user in the server |
| ?afk <@user> |
sets an AFK message for a user |
| ?warn <@user> |
Warns a user |
| ?warnings <@user> |
Displays all the past warnings of a user |
| ?clearwarnings <@user> |
Clears the warning of a user |
| ?status |
Changes the status of the bot |
| ?suggest |
Logs a suggestion to the server |
| ?report <@user> |
Reports a user |
| ?Invite |
Generates the invite link from the server |
| ?kick <@user> |
Kicks a user from the server |
| ?say |
Broadcasts a message in the channel as the bot |
| ?addrole <@user> (role) |
adds a role to a user |
| ?softban <@user> |
Soft bans a user from the server |
| ?removerole <@user> (role) |
Removes a role from a user |
| ?purge <# of messages> |
Deletes a number of messages in a channel |
| ?ping |
Gets the ping of the server and bot |


At time of writing, Krishnan Guru-Murthy has nudged ahead of Yoko Ono in our poll to decide on the luminary most deserving of a complimentary Hooting Yard lapel accoutrement. Could it be, I wonder, that the email I fired off to him at Channel 4 News the other day bore fruit?
Dear Mr Guru-Murthy
You are currently in second place (behind Yoko Ono) in a readers' poll at Hooting Yard to choose the luminary most deserving of a complimentary Hooting Yard lapel accoutrement. Might I suggest you vote for yourself and encourage others in the Channel 4 newsroom to cast their votes in your favour?

Yours sincerely
Frank Key
Some readers may be appalled by what they see as a morally reprehensible attempt to influence the outcome of the poll. Let me assure these virtuous souls that I fully intend to fire off similar letters to De Botton, Huffington, Tempah, and Ono. But not Balls, for Christ's sake, not Balls!


I wake up in the morning
the alarm gets pressed snooze
asleep I go again
One thing that I am really interested in is skiing. I only started to ski a year ago. I now have two years under my belt. I usually just get a season pass to Sundance because it is close and cheaper than most resorts. I have started to do 360's off of jumps but my goal for next year will be to do a backflip.
Another thing that I really enjoy doing is resaling golf clubs. This is a hobby that a picked up last year also. I usually just look on the KSL classifieds page to try and find good deals on golf clubs. I then clean the clubs up and post them on different websites to try and sale them. It has been a good side business for me while I try and make it though college while being recently married.
Watching movies is also a fun way to pass time. Currently, my wife and I are watching all of the Marvel movies in chronological order. There are over 20 movies to watch but we are down to the last 4. Some of my favorite movies include: The Italian Job, UHF, Napolean Dynamite, and World War Z.
| Monday | Tuesday | Wednesday | Thursday | Friday | |
|---|---|---|---|---|---|
| 8:00 | Work | Work | Work | ||
| 8:30 | CS 2450 | CS 2450 | |||
| 9:00 | |||||
| 9:30 | |||||
| 10:00 | CS 2550 | CS 2550 | |||
| 10:30 | |||||
| 11:00 | |||||
| 11:30 | CS 3240 | CS 3240 | |||
| 12:00 | |||||
| 12:30 | Golf | ||||
| 1:00 | |||||
| 1:30 | |||||
| 2:00 | |||||
| 2:30 | CS 2600 | CS 2600 | |||
| 3:00 | |||||
| 3:30 | |||||
| 4:00 | |||||
| 4:30 | |||||
| 5:00 | |||||
| 5:30 | |||||
| 6:00 | Dinner | Dinner | Dinner | Dinner | Dinner |


Self-confidence
What is the relationship between mindfulness and self awareness?
Self awareness is the same as mindfulness in the sense that both allow us to reflect on or take note off our emotions, mental and/or physical state in the present moment. Both are done in a non-judgemental/neutral way and both are learnable and definitely get easier the more we practice.
I did the Journaling for Self-Assement with the prompts suggested in the book. This was a fairly easy task although I surprised myself with some of the things I came up with especially when there was still time left and I started to reflect a lot deeper.
What did I take away from the "My Emotions are Not Me" section?
That emotion are what I feel not who I am. I imagine that saying 'I feel stressed' instead of saying 'I am stressed' could also in the long run have positive effects on how my body copes with stress.
Home


X
en
History
Translate
Etimology
>
<
Auto detect language:
Simply right-click on selected text and choose "Search etymology".


New Arrivals
PACK OF 6 PEPSI LITER
Rs: 420
Add to Cart
PACK OF 6 PEPSI 2.25
Rs: 640
Add to Cart
PACK OF 12 STING HALF LITER
Rs: 450
Add to Cart
PACK OF 12 PEACH/LEMON MALT TIN PACK
Rs: 699
Add to Cart
PACK OF 12 PEPSI TIN
Rs: 600
Add to Cart
PACK OF 6 COKE 1 LITER
Rs: 350
Add to Cart
PACK OF 6 COKE 1.5 LITER
Rs: 550
Add to Cart
PACK OF 6 COKE 2.25
Rs: 670
Add to Cart
PACK OF 12 COKE TIN
Rs: 600
Add to Cart
PACK OF 12 VIVO 500 ML JUICE
Rs: 600
Add to Cart
VIVO 1 LITER BOTTLE
Rs: 120
Add to Cart
PACK OF 12 TOPS JUICE
Rs: 350
Add to Cart
PACK OF 12 DASI MINERAL WATER
Rs: 250
Add to Cart
PACK OF 12 AQUAFINA 500ML
Rs: 200
Add to Cart
PACK OF 6 GOURNMET MINERAL WATER
Rs: 250
Add to Cart
PACK OF 6 GOURNMET 1.5 LITER BOTTLE
Rs: 350
Add to Cart


In this post, we are going to analyze electricity consumption data from a house. We have a time-series dataset which contains the power(kWh), Cost of electricity and Voltage at a particular time stamp. We are further provided with the temperature records during the same day for each hour. You can download the compressed dataset from here. I’d further recommend you to have a look at the corresponding ipython notebook.
First part is the Data Analysis Part where we will be doing the basic data cleaning and analysis regarding the power demand and cost incurred. The second part employs a KMeans clustering approach to identify which appliance might be the major cause for the power demand in a particular hour of the day.
So let’s start with basic imports and reading of data from the given dataset.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
# Read the sensor dataset into pandas dataframe
sensor_data = pd.read_csv('merged-sensor-files.csv',
names=["MTU", "Time", "Power",
"Cost", "Voltage"], header = False)
# Read the weather data in pandas series object
weather_data = pd.read_json('weather.json', typ ='series')
# A quick look at the datasets
sensor_data.head(5)
| MTU | Time | Power | Cost | Voltage | |
|---|---|---|---|---|---|
| 0 | MTU1 | 05/11/2015 19:59:06 | 4.102 | 0.62 | 122.4 |
| 1 | MTU1 | 05/11/2015 19:59:05 | 4.089 | 0.62 | 122.3 |
| 2 | MTU1 | 05/11/2015 19:59:04 | 4.089 | 0.62 | 122.3 |
| 3 | MTU1 | 05/11/2015 19:59:06 | 4.089 | 0.62 | 122.3 |
| 4 | MTU1 | 05/11/2015 19:59:04 | 4.097 | 0.62 | 122.4 |
Let’s have a quick look at the weather dataset as well:
weather_data
2015-05-12 00:00:00 75.4 2015-05-12 01:00:00 73.2 2015-05-12 02:00:00 72.1 2015-05-12 03:00:00 71.0 2015-05-12 04:00:00 70.7 . . dtype: float64
TASK 1: Data Analysis
Data Cleaning/Munging:
After having a look at the merged-sensor-files.csv I found out there are some inconsistent rows where header names are repeated and as a result ‘pandas’ is converting all these columns to ‘object’ type. This is quite a common problem, which arises while merging multiple csv files into a single file.
sensor_data.dtypes
MTU object Time object Power object Cost object Voltage object dtype: object
Let’s find out and remove these inconsistent rows so that all the columns can be converted to appropriate data types.
The code below finds all the rows where “Power” column has a string value - “Power” and get the index of these rows.
1
2
3
# Get the inconsistent rows indexes
faulty_row_idx = sensor_data[sensor_data["Power"] == " Power"].index.tolist()
faulty_row_idx
[3784, 7582, 11385, . . 81617, 85327]
and now we can drop these rows from the dataframe
1
2
3
4
5
# Drop these rows from sensor_data dataframe
sensor_data.drop(faulty_row_idx, inplace=True)
# This should return an empty list now
sensor_data[sensor_data["Power"] == " Power"].index.tolist()
[]
We have cleaned up the sensor_data and now all the columns can be converted to more appropriate data types.
1
2
3
4
5
6
7
8
9
10
# Type Conversion
sensor_data[["Power", "Cost", "Voltage"]] = sensor_data[["Power",
"Cost", "Voltage"]].astype(float)
sensor_data[["Time"]] = pd.to_datetime(sensor_data["Time"])
# Also add an 'Hour' column in sensor_data
sensor_data['Hour'] = pd.DatetimeIndex(sensor_data["Time"]).hour
sensor_data.dtypes
MTU object Time datetime64[ns] Power float64 Cost float64 Voltage float64 Hour int32 dtype: object
This is better now. We have got clearly defined datatypes of different columns now. Next step is to convert the weather_data Series to a dataframe so that we can work with it with more ease.
1
2
3
4
5
6
7
8
9
10
11
12
# Create a dataframe out of weather dataset as well
temperature_data = weather_data.to_frame()
# Reindex it so as to create a two column dataframe
temperature_data.reset_index(level=0, inplace=True)
temperature_data.columns = ["Time", "Temperature"]
# Add the "Hour" column in temperature_data
temperature_data["Hour"] = pd.DatetimeIndex(
temperature_data["Time"]).hour
temperature_data.dtypes
Time datetime64[ns] Temperature float64 Hour int32 dtype: object
Since now we have both of our dataframes in place, it'd be a good point to have a look at sum of the basic statistics of both of these data frames.
1
sensor_data.describe()
| Power | Cost | Voltage | Hour | |
|---|---|---|---|---|
| count | 88891.000000 | 88891.000000 | 88891.000000 | 88891.000000 |
| mean | 1.315980 | 0.202427 | 123.127744 | 11.531865 |
| std | 1.682181 | 0.252357 | 0.838768 | 6.921671 |
| min | 0.113000 | 0.020000 | 121.000000 | 0.000000 |
| 25% | 0.255000 | 0.040000 | 122.600000 | 6.000000 |
| 50% | 0.367000 | 0.060000 | 123.100000 | 12.000000 |
| 75% | 1.765000 | 0.270000 | 123.700000 | 18.000000 |
| max | 6.547000 | 0.990000 | 125.600000 | 23.000000 |
1
temperature_data.describe()
| Temperature | Hour | |
|---|---|---|
| count | 25.000000 | 25.00000 |
| mean | 76.272000 | 11.04000 |
| std | 6.635355 | 7.29429 |
| min | 67.900000 | 0.00000 |
| 25% | 69.600000 | 5.00000 |
| 50% | 75.400000 | 11.00000 |
| 75% | 83.000000 | 17.00000 |
| max | 87.000000 | 23.00000 |
As apparent from above statistics there is a good amount of variation in Power and corresponding Cost values in sensor_data dataframe, where average power is 1.315980kW and minimum and maximum power used throughout the day is 0.11kW and 6.54kW respectively. Similarily there is an apparent variation in temperature in temperature_data dataset, most probably it attributes to day and night time.
To get a better understanding of these variations we’ll be plotting power and temperatures with the timestamps, so as to find out the peak times for both.
But before moving to visualizations we’ll have to create respective grouped datasets from sensor_data and temperature_data, grouping by the “Hour” column. This way we can work on hourly basis.
1
2
3
4
# Group sensor_data by 'Hour' Column
grouped_sensor_data = sensor_data.groupby(
["Hour"], as_index = False).mean()
grouped_sensor_data
| Hour | Power | Cost | Voltage | |
|---|---|---|---|---|
| 0 | 0 | 0.173790 | 0.029468 | 124.723879 |
| 1 | 1 | 0.179594 | 0.033805 | 124.522469 |
| 2 | 2 | 0.185763 | 0.037013 | 123.929979 |
| . | . | . | . | . |
| 22 | 22 | 2.542672 | 0.387109 | 123.542620 |
| 23 | 23 | 2.269941 | 0.346457 | 123.415791 |
1
2
3
4
# Group temperature_data by "Hour"
grouped_temperature_data = temperature_data.groupby(
["Hour"], as_index = False).mean()
grouped_temperature_data
| Hour | Temperature | |
|---|---|---|
| 0 | 0 | 78.25 |
| 1 | 1 | 73.20 |
| . | . | . |
| 22 | 22 | 84.40 |
| 23 | 23 | 83.00 |
Basic Visualizations:
1
2
3
4
5
6
7
8
9
# Generates all the visualizations right inside the ipython notebook
%pylab inline
plt.style.use('ggplot')
fig = plt.figure(figsize=(13,7))
plt.hist(sensor_data.Power, bins=50)
fig.suptitle('Power Histogram', fontsize = 20)
plt.xlabel('Power', fontsize = 16)
plt.ylabel('Count', fontsize = 16)
Looks like most of the time this house is consuming a limited amount of power. Although there is also a good amount of distribution in the range of 3.5kW - 5kW, indicating a higher demand.
Let’s now plot the Power Distribution with the day hours.
1
2
3
4
5
6
7
fig = plt.figure(figsize=(13,7))
plt.bar(grouped_sensor_data.Hour, grouped_sensor_data.Power)
fig.suptitle('Power Distribution with Hours', fontsize = 20)
plt.xlabel('Hour', fontsize = 16)
plt.ylabel('Power', fontsize = 16)
plt.xticks(range(0, 24))
plt.show()
Some of the inferences we can get from this bar chart are:
- Highest Demand is noticed during the evening hours. This is quite expected since most of the equipments would be in ‘on’ state during this time like AC(during summers), room heaters(during winters), TV, Oven, Washing Machine, Lights, etc.
- Night hours(0000 - 0500) and office hours(0900 - 1600) have very low demand, since most of the appliances will be in ‘off’ state during this period.
- There is a slight increase in Power during morning hours from 0600 - 0900, which should account for the power used by the appliances during morning activities, lights, geysers, etc.
Steady States:
- In the time period 0000 - 0500, demand is noticeably less and ranges between 0.17kW - 0.18kW
- Another steady period is from 1000 - 1500, demand is pretty much steady between 0.373kW - 0.376kW
- Steady state with highest demand is from 1600 - 1900 having a range between 4.36kW - 4.25kW
Some sudden changes in Demand during 0700 and 1800 can be attributed because of random events or the usage of certain appliances and may be counted as noise in the dataset.
Similarily there is a slight oscillation in demand during 0900 which suddenly falls down from 0.38kW to 0.16kW and rises up again to about 0.37kW. Similar change in demand is seen at 2100.
Let’s further plot temperature with the Power to see if there is any correlation among these.
1
2
3
4
5
6
7
fig = plt.figure(figsize=(13,7))
plt.bar(grouped_temperature_data.Temperature,
grouped_sensor_data.Power)
fig.suptitle('Power Distribution with Temperature', fontsize = 20)
plt.xlabel('Temperature in Fahrenheit', fontsize = 16)
plt.ylabel('Power', fontsize = 16)
plt.show()
There seems to be a direct correlation between temperature and the demand of power. This makes sense, since with our current dataset which is from May, this shows that cooling appliances like AC, refrigerator, etc. are consuming a lot of power during the peak hours(evening).
Task 2: Machine Learning
We’ll start with merging the grouped_sensor_data and grouped_temperature_data so that we can work on the complete dataset from a single dataframe.
1
2
3
# Merge grouped_sensor_data and grouped_temperature_data
# using "Hour" as the key
merged_data = grouped_sensor_data.merge(grouped_temperature_data)
In previous visualization we saw that when temperature is low generally there is less demand of power. But that mainly relates to the cooling appliances in the home. We’ll consider the following appliances:
- Cooling Systems
- TV
- Geyser
- Lights
- Oven
- Home Security Systems
and would try to identify there presence or on/off state using the merged dataset.
AC, Refrigerator and Other Coooling Systems:
As apparent from “Power Distribution with Temperature” figure, there is a sudden increase in power demand with the rise in temperature. This clearly indicates the ON state of one or more cooling systems in the home. Since these appliances takes a considerable amount of power, this sudden upsurge in the power is quite justified. Clearly Power and Temperature are the two features that indicates the ‘ON’ state of these appliances. Although ‘Cost’ feature is also correlated with ‘Power’ we’d leave it out, since it is more of a causation of Power demand, then a completely independent feature.
TV:
During the evening hours(1600 - 2300), an ‘ON’ television set is probably another factor for increased power demand. It is quite apparent from the Power feature.
Geyser, Oven:
Slight increase in power demand during morning hours can be related to the presence of these appliances and is justified again by the Power feature.
Lights:
It’s quite obvious there is a small contribution(considering house owner was smart and installed LED bulbs ;) ) of lights in the house in the ‘Power’ demand. And of course it only makes sense to switch ‘ON’ the lights during darker times :D of the day, Hour and Low Power are the indicators of lights.
Home Security Systems:
During the office hours there’s a very little increase in the Power demand, this can be attributed to home security systems or other automated devices.
Now, we’ll be using simple K-Means clustering using scikit-learn. We are going to consider Hour, Power and Temperature feature from the original dataset. For that first of all we’ll have to merge the sensor_data dataframe with grouped_temperature_data dataframe.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# Complete merged dataset
data =sensor_data.merge(grouped_temperature_data)
# Lets drop Time, MTU, Cost and Voltage features
data.drop(["Time", "MTU", "Cost", "Voltage"], axis = 1,
inplace = True)
# Import required modules from scikit-learn
from sklearn.cluster import KMeans
from sklearn.cross_validation import train_test_split
# Set a random seed, so we can reproduce the results
np.random.seed(1234)
# Divide the merged dataset into train and test datasets
train_data, test_data = train_test_split(data, test_size = 0.25,
random_state = 42)
# Perform K-Means clustering over the train dataset
kmeans = KMeans(n_clusters = 4, n_jobs = 4)
kmeans_fit = kmeans.fit(train_data)
predict = kmeans_fit.predict(test_data)
test_data["Cluster"] = predict
| Power | Hour | Temperature | Cluster | |
|---|---|---|---|---|
| 52595 | 0.114 | 8 | 69.2 | 1 |
| . | . | . | . | . |
| 7834 | 1.094 | 21 | 84.2 | 0 |
| 25231 | 0.125 | 1 | 73.2 | 2 |
This looks like a pretty reasonable clustering. We can further assign the labels to these clusters, as an appliance detection model. As apparent from the predicted result, We can set the labels for clusters as:
- 0 - Cooling Systems
- 1 - Oven, Geyser
- 2 - Night Lights
- 3 - Home Security Systems
We’ll create a data frame with these labels and merge it with predicted results.
1
2
3
4
5
6
7
8
9
10
11
# Create a dataframe with appliance labels
label_df = pd.DataFrame({"Cluster": [0, 1, 2, 3],
"Appliances": ["Cooling System",
"Oven, Geyser",
"Night Lights",
"Home Security Systems"]})
# Merge predicted cluster values for test data set
# with our label dataframe
result = test_data.merge(label_df)
result.head(1)
| Power | Hour | Temperature | Cluster | Appliances | |
|---|---|---|---|---|---|
| 0 | 0.114 | 8 | 69.2 | 1 | Oven, Geyser |
1
result.tail(1)
| Power | Hour | Temperature | Cluster | Appliances | |
|---|---|---|---|---|---|
| 22218 | 0.306 | 15 | 80.7 | 3 | Home Security Systems |
I think this makes sense. As apparent from result dataframe, in hours like 8, 9, 10 there is a high possibility that a Oven or Geyser is being used. On the other hand during office hours(1000 - 1600), most probably Home Security Appliances are taking the power.
Starting from the very beginning, i.e. the Data Analysis process, I think with more data we could group it according to the days(for a week’s or month’s data), or by months(for a year’s data). That could’ve significantly changed the predicted Power values, since the average values over these larger intervals would be smoother.
We’d also have to take care of the seasons and temperature, since different appliances would be taking power in different seasons, so clustering would turn into a bit complicated task compared to what we did with data of just one day.
The most important data that could help in a more accurate analysis would be the power consumption amount of all the appliances in the house. That way it’d be much easier to understand what appliance is taking more power in a certain period of time.
Furthermore, this would also help during the classification task, since we would already know that certain appliances requires much power, hence we could more accurately classify a sample.
One limitation is the number of features we have in this dataset, to learn new features a simple neural net could also be employed to get some hidden patterns here.
You can further look at the Github repo with the above code at: rishy/electricity-demand-analysis. Your feedbacks and comments are always welcomed.
Related Papers:


Creating Windows Installers With the WiX Toolset Part 6
Part 2 – An Overview Of Windows Installer and its Features
Part 3 – Tooling Options for Building Installers
Part 4 – The Windows Installer Runtime Sequence
Part 5 – The Contents of an MSI
Part 6 – The Structure of a WiX File
Part 7 – Generating an MSI Package From Your WiX
Part 8 – Troubleshooting Installer Runtime Problems
Part 9 - Summary
Summary
This post is a companion to the previous post in Part 5 - it shows and explains the structure of the WiX file that was used to generate the MSI.
Tooling and References For Editing WiX Files
Since the name of the toolkit is “Windows Installer in XML”, you probably won’t be terribly surprised to find out that the source files you edit are…wait for it…XML. This means you can author and edit in your favorite XML editor of choice, whether that’s Notepad++, some incredibly expensive specialty tool like Altova XML Spy, or Visual Studio. If you use Visual Studio and you’ve installed WiX on your local machine, you can leverage the included Votive project types to get Intellisense in Visual Studio.
[caption id=”attachment_6409” align=”alignnone” width=”582”] Visual Studio Intellisense with Votive[/caption]
There’s reference documentation for the schema at SourceForge. The first link is for the WiX schema itself, and there are other schema references for the various extensions that are available.
The Complete Hello World
Dissecting the Elements
Line 3 is pretty straightforward: declare our root Wix element and specify the namespace. No that isn’t a typo at the end; the namespace really doesn’t have an x at the end of it. I have no idea why.
Line 5 declares our Product for the installer (recall Product has a cardinality of 1). Some of the supporting attributes like Manufacturer, Name, and Version will show up in the Add Program and Features list for Windows.
Line 12 defines the Package (also cardinality of 1), which is the installer itself. Attributes here will show up in the properties of the MSI file.
Line 19 introduces the concept of Media, which wasn’t discussed in the MSI examination. Windows Installer has a profuse amount of options for the physical layout of the files to be deployed, including things like spanning multiple DVDs (or floppies - remember those? The need for this has fallen by the wayside as most software is downloaded from the internet or an internal network these days. In this example, we only have one physical media target, and the EmbedCab attribute will package all the deployables into the MSI directly since we don’t need disc spanning.
Line 21 defines our target directory structure. Note it’s nested. I’m not going to discuss it exhaustively, but will point out a few interesting things. Line 22 specifies we’re installing into this machine’s Program Files directory, and line 23 is the INSTALLDIR, which is our root target directory. More sophisticated installers will allow the user to specify their own directory and replace the value of INSTALLDIR.
Line 24 defines our one and only component. Recall from the previous post its possible for a component to have more than one deployable in it, but there are advantages to having a component for every file. Components have a unique ID to identify them.
In this example we’ve associated our component with a target directory by simply nesting it under the desired directory. This works for simple scenarios, but if you have more than one target directory for your product or if your code generating your component definitions, it might be easier to declare the directory structure and components separately and use the DirectoryRef attribute on the component to make the association.
Line 25 contains a file that is part of this component. The name attribute is what the file will be called when it is placed on the target file system, and the source attribute specifies where to get the file when compiling the MSI package.
Line 26 does what you hopefully would guess; it removes the installation folder from the machine when the component ‘MainExecutable’ gets uninstalled.
Line 32 finishes things out by declaring our single feature (although you’ll recall there could be multiple Features in a Product), and associating our component with it.
Tying It All Together
So we have:
- File HelloWorld.exe containing our executable
- Component MainExecutable containing the HelloWorld.exe File
- Directory INSTALLDIR (which itself is a subdirectory) associated with the MainExecutable Component
- Feature called Complete containing the MainExecutable Component
- Product that contains the Complete Feature (this is implied and doesn’t have to be explicitly defined)
All of this maps neatly to the MSI we took apart in the last post. In the next installment, we’ll look at the process for actually turning WiX into an MSI.


Installing Windows Adk For Windows 10 Version 1903 Windows Pe Add On Lab Demo
Windows 10 Deployment Scenarios And Tools Windows Deployment Microsoft Docs
Windows Assessment And Deployment Kit Adk Installation Lab Demo
Download Windows Adk The Numerous Versions Of Microsoft Windows Adk Assessment And Planning Toolkit And Where To Find Them Renshollanders Nl
Windows Installation Ciscoucs Github Io
Windows 10 Adk Versions And Downloads Prajwal Desai
ブート キット作成ユーティリティの起動
What Version Of The Windows Adk Is Supported With System Center Configuration Manager Current Branch Version 1902 Just Another Windows Noob
Inside Windows Adk 10 V1607 Deployment Research
Download Windows Assessment And Deployment Kit Windows Adk With Bits Cmdlets
Install Windows Configuration Designer Windows 10 Configure Windows Microsoft Docs
Step By Step Guide To Update Windows Adk On Sccm Server Prajwal Desai
How To Download And Install Adk 8 1 For Use Within A Disconnected Environment Enhansoft
7 1 Windowsサーバ Enterprise Cloud Knowledge Centersolution Guide 2 11 0 ドキュメント
Step By Step Guide To Update Windows Adk And Winpe Addon On Sccm Server
Install The App V Sequencer Windows 10 Windows Application Management Microsoft Docs
1 6 復旧メディア作成編 Enterprise Cloud Knowledge Centersolution Guide 2 11 0 ドキュメント
Windows Adk For Win10 V1809 Without Windows Pe Born S Tech And Windows World
Easy Guide To Install Windows Adk Offline Prajwal Desai
Tools Harjit Dhaliwal
How To Prepare Mdt For In Place Upgrade To Windows 10 2004 Askme4tech
Installing Windows Sdk How To Sign Windows Drivers Executables Adafruit Learning System
Installing And Configuring Mdt With Windows 10 Adk
Mdt Installation And Configuration Microsoft Deployment Toolkit Page 2 Of 9 Rdr It
Windows Adkをインストールする手順 無停電電源装置 Ups イートン
Downloads Harjit Dhaliwal
Installing Windows Adk Formerly The Aik For An Offline Installation
4 How To Download And Install The Windows 10 Adk Offline Youtube


| /Library/Python/2.7/site-packages/_pytest/_argcomplete.py |
35 |
34 |
0 |
3% |
| /Library/Python/2.7/site-packages/_pytest/_code/code.py |
581 |
558 |
0 |
4% |
| /Library/Python/2.7/site-packages/_pytest/_code/source.py |
282 |
258 |
0 |
9% |
| /Library/Python/2.7/site-packages/_pytest/assertion/__init__.py |
66 |
59 |
0 |
11% |
| /Library/Python/2.7/site-packages/_pytest/assertion/rewrite.py |
566 |
494 |
0 |
13% |
| /Library/Python/2.7/site-packages/_pytest/cacheprovider.py |
150 |
116 |
0 |
23% |
| /Library/Python/2.7/site-packages/_pytest/capture.py |
359 |
293 |
0 |
18% |
| /Library/Python/2.7/site-packages/_pytest/compat.py |
164 |
138 |
2 |
16% |
| /Library/Python/2.7/site-packages/_pytest/config.py |
873 |
735 |
0 |
16% |
| /Library/Python/2.7/site-packages/_pytest/debugging.py |
85 |
75 |
0 |
12% |
| /Library/Python/2.7/site-packages/_pytest/doctest.py |
189 |
180 |
11 |
5% |
| /Library/Python/2.7/site-packages/_pytest/fixtures.py |
660 |
536 |
0 |
19% |
| /Library/Python/2.7/site-packages/_pytest/helpconfig.py |
107 |
98 |
0 |
8% |
| /Library/Python/2.7/site-packages/_pytest/junitxml.py |
250 |
248 |
0 |
1% |
| /Library/Python/2.7/site-packages/_pytest/main.py |
532 |
326 |
0 |
39% |
| /Library/Python/2.7/site-packages/_pytest/mark.py |
229 |
214 |
0 |
7% |
| /Library/Python/2.7/site-packages/_pytest/monkeypatch.py |
127 |
115 |
0 |
9% |
| /Library/Python/2.7/site-packages/_pytest/nose.py |
43 |
39 |
0 |
9% |
| /Library/Python/2.7/site-packages/_pytest/pastebin.py |
62 |
60 |
0 |
3% |
| /Library/Python/2.7/site-packages/_pytest/python.py |
736 |
608 |
0 |
17% |
| /Library/Python/2.7/site-packages/_pytest/resultlog.py |
87 |
85 |
0 |
2% |
| /Library/Python/2.7/site-packages/_pytest/runner.py |
320 |
193 |
0 |
40% |
| /Library/Python/2.7/site-packages/_pytest/setuponly.py |
47 |
46 |
0 |
2% |
| /Library/Python/2.7/site-packages/_pytest/setupplan.py |
13 |
12 |
0 |
8% |
| /Library/Python/2.7/site-packages/_pytest/skipping.py |
246 |
214 |
0 |
13% |
| /Library/Python/2.7/site-packages/_pytest/terminal.py |
474 |
337 |
0 |
29% |
| /Library/Python/2.7/site-packages/_pytest/tmpdir.py |
63 |
56 |
0 |
11% |
| /Library/Python/2.7/site-packages/_pytest/unittest.py |
169 |
119 |
0 |
30% |
| /Library/Python/2.7/site-packages/_pytest/vendored_packages/pluggy.py |
429 |
302 |
0 |
30% |
| /Library/Python/2.7/site-packages/_pytest/warnings.py |
54 |
43 |
0 |
20% |
| /Library/Python/2.7/site-packages/apipkg.py |
148 |
141 |
0 |
5% |
| /Library/Python/2.7/site-packages/colored/__init__.py |
8 |
0 |
0 |
100% |
| /Library/Python/2.7/site-packages/colored/back.py |
9 |
0 |
0 |
100% |
| /Library/Python/2.7/site-packages/colored/colored.py |
50 |
20 |
0 |
60% |
| /Library/Python/2.7/site-packages/colored/colors.py |
2 |
0 |
0 |
100% |
| /Library/Python/2.7/site-packages/colored/fore.py |
9 |
0 |
0 |
100% |
| /Library/Python/2.7/site-packages/colored/hex.py |
5 |
3 |
0 |
40% |
| /Library/Python/2.7/site-packages/colored/style.py |
7 |
0 |
0 |
100% |
| /Library/Python/2.7/site-packages/py/_apipkg.py |
138 |
119 |
0 |
14% |
| /Library/Python/2.7/site-packages/py/_builtin.py |
188 |
182 |
0 |
3% |
| /Library/Python/2.7/site-packages/py/_code/code.py |
523 |
521 |
0 |
1% |
| /Library/Python/2.7/site-packages/py/_error.py |
50 |
47 |
0 |
6% |
| /Library/Python/2.7/site-packages/py/_io/terminalwriter.py |
239 |
152 |
0 |
36% |
| /Library/Python/2.7/site-packages/py/_path/common.py |
269 |
173 |
0 |
36% |
| /Library/Python/2.7/site-packages/py/_path/local.py |
638 |
488 |
0 |
24% |
| /Library/Python/2.7/site-packages/py/_std.py |
11 |
5 |
0 |
55% |
| /Library/Python/2.7/site-packages/py/_xmlgen.py |
170 |
168 |
0 |
1% |
| /Library/Python/2.7/site-packages/pytest_cov/compat.py |
19 |
15 |
0 |
21% |
| /Library/Python/2.7/site-packages/pytest_cov/engine.py |
166 |
153 |
0 |
8% |
| /Library/Python/2.7/site-packages/pytest_cov/plugin.py |
157 |
131 |
0 |
17% |
| /Library/Python/2.7/site-packages/pytest_forked/__init__.py |
54 |
53 |
0 |
2% |
| /Library/Python/2.7/site-packages/xdist/looponfail.py |
197 |
196 |
0 |
1% |
| /Library/Python/2.7/site-packages/xdist/plugin.py |
59 |
51 |
0 |
14% |
| /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources/__init__.py |
1605 |
1603 |
0 |
1% |
| __init__.py |
1 |
0 |
0 |
100% |
| colored-1.3.5/tests/test_1.py |
10 |
5 |
0 |
50% |
| colored-1.3.5/tests/test_2.py |
11 |
6 |
0 |
45% |
| colored-1.3.5/tests/test_3.py |
11 |
6 |
0 |
45% |
| colored-1.3.5/tests/test_4.py |
517 |
513 |
0 |
1% |
| colored-1.3.5/tests/test_5.py |
11 |
6 |
0 |
45% |
| rpn.py |
34 |
6 |
0 |
82% |
| test_rpn.py |
15 |
0 |
0 |
100% |


[gecode-users] Gecode/J New users
Malcolm Ryan
malcolmr at cse.unsw.edu.au
Fri Nov 2 09:36:07 CET 2007
Thanks Guido for you prompt reply. I'm starting to find my way
around. I've been reading through the Gecode class, you have by far
the most complete set of constraints that I've seen in any of the
libraries I've looked at!
Am I right in thinking that if I want to say: x in s for intvar x and
setvar s, I do:
Gecode.rel(list, x, SetRelType.SRT_SUB, s);
and if x is a constant int, I do:
Gecode.dom(this, s, SetRelType.SRT_SUP, x);
Is that right?
More below....
>> 3) Do you have any means to label constraints with meaningful tags
>> for debugging?
>
> No, that's currently not possible. What kind of information would
> you like to attach to a constraint? We are currently integrating
> reflection capabilities into the C++ base library, which might
> eventually also become available in Java.
I just want to attach strings that are names decribing the semantic
intent of the constraint, for debugging. What kind of debugging
support do you have? Can I trace the constraints as they propagate?
Ultimately, it would be nice to be able to attach a Java StackTrace
to each constraint, recording the context in which it was posted. If
these could be examined as the constraints propagated, it would be
possible to build a tracing tool which showed _in_the_code_ which
constraints are executing. That would enable you to build an
interactive debugging tool much like a traditional execution tracer.
>> 5) Is this project actively used and supported?
>
> Yes, it is. It hasn't seen an update in quite a while because we
> are busy preparing the next major version (2.0.0), which should be
> available within the next month. We are actively using it mainly
> for teaching CP courses, here at Saarland University and at KTH,
> and some other universities.
Excellent news.
Malcolm
--
"An inconvenience is only an adventure wrongly considered;
an adventure is an inconvenience rightly considered."
- G.K.Chesterton, On Running After Ones Hat
More information about the gecode-users
mailing list


Birth Day Calculator
Find out info about your birth day.
1) Enter in your date of birth
Example:
1 Jan 2000
2) Information about your Birth Day


Teen2Teen
Home
Sleep
Stress
Strict Parrents
Self-Esteem
Button Styles
Underage Sex
Sleep
Stress
Depression
Body Image
LGBTQ
Bullying
Cyber Addiction
Teen Pregnancy
Strict Parents
Child Abuse
Self-Esteem
Drinking & Smoking
Peer-Pressure
Eating Disorders


🐦 @{{ .Page.Params.speaker_twitter }}
{{ end }}
{{ if .Page.Params.workshop }}Workshop/break-out session:
{{ end }}
{{ if .Page.Params.keynote }}Keynote:
{{ end }}
{{ .Title }}
With thanks to {{ .Page.Params.employer_attribution }}
{{ end }}{{ .Page.Params.timeslot }} UTC+2 in {{ .Page.Params.room }}
{{ if not .Page.Params.workshop }}
Will be streamed 📺
{{ end }}
Break-out sessions are expected to last around 60 minutes. They will have limited seats and will have a sign-up option provided on the ticketholder website, once the schedule is known.
{{ end }}


Arc @ UNSW Clubs Membership Audit 2015
{% for club in clubs %}
Society: {{ club }}
Passed Members:
{% for executive in passed[club] %} {{ passed[club][executive] }}, {{ executive }}
{% endfor %}
Failed Members:
{% for executive in failed[club] %} {{ failed[club][executive] }}, {{ executive }}
{% endfor %}
{% endfor %}


Framework Overview
Our framework generates the parametrized strokes step by step in a recurrent manner.
It uses a dynamic window (dashed red boxes) around a virtual pen to draw the strokes,
and can both move and change the size of the window.
(a) Four main modules at each time step: aligned cropping, stroke generation, differentiable rendering and differentiable pasting.
(b) Architecture of the stroke generation module.
(c) Structural strokes predicted at each step;
movement only is illustrated by blue arrows during which no stroke is drawn on the canvas.
Overall Introduction
Vectorization
Rough sketch simplification
Photograph to line drawing
More Results
@article{mo2021virtualsketching, title = {General Virtual Sketching Framework for Vector Line Art}, author = {Mo, Haoran and Simo-Serra, Edgar and Gao, Chengying and Zou, Changqing and Wang, Ruomei}, journal = {ACM Transactions on Graphics (Proceedings of ACM SIGGRAPH 2021)}, year = {2021}, volume = {40}, number = {4}, pages = {51:1--51:14} }


Help children, give them a better life.
Join as a VolunteerMake a donation for the betterment of poor, special and orphan children.
Meet us directly or through our facebook page.
Contact UsAHF is an idea from a bunch of youngsters from India for a great cause. They formed as a group and voluntarily started serving the poor and needy homeless people around their city.
They raised donations for the treatment of specially abled children and children who needs medical attention.
Ocassionaly they visit ophonages to spend some time with them.


Lewis Capaldi's new song is about his aunt's death by suicide
Lewis Capaldi’s new song was written about his aunt taking her own life.
The Scottish star is following up the mammoth success of Someone You Loved and Hold Me While You Wait with Before You Go, which Lewis has called ‘one of the most personal songs I’ve ever written’.
And the 23-year-old has shared the tragic inspiration behind the ballad – the aftermath of suicide for the victim’s loved ones.
Speaking to Zane Lowe on Apple Music’s Beats 1 Radio, Lewis explained: ‘The song’s kind of, it comes from a place of … it’s about suicide and it’s about not necessarily the act of it itself obviously, but people after it happens, the aftermath of it and people blaming themselves or starting to think, what could I have done to help that person? Or whatever.’
Capaldi went on to explain that his mother’s sister had taken her own life when he was younger.
Advertisement Advertisement
He said: ‘When I was about five or six I think, my aunt committed suicide and just remember recently speaking to my mum about their feelings, her feelings about going through that sort of rigmarole in your head of, “What could I have done here? Could I have done anything?” Sort of thing.
‘But she said it was the thing of, at first you’re angry. You’re obviously upset and then you kind of get angry at them, and then you get angry at yourself. She said it was this whole kind of … it’s very, very strange.’

On Instagram, the singer said: ‘Seriously one of the most personal songs I’ve ever written. This song means a lot to me, but it will mean even more if it becomes successful.’
Lewis is currently riding high after spending three weeks atop the Billboard Hot 100 in the US with Someone You Loved.
The star’s debut album Divinely Uninspired To A Hellish Extent is the best-selling album by a British artist in over eight years, and reached number one on the UK, Scottish and Irish charts.
Need support? Contact the Samaritans
For emotional support you can call the Samaritans 24-hour helpline on 116 123, email<EMAIL_ADDRESS>visit a Samaritans branch in person or go to the Samaritans website.