text:
Javier Mascherano has announced the 2018 World Cup in Russia will be his final tournament with Argentina, while he has also said this could be his last season with Barcelona.
The 33-year-old started in Argentina's final World Cup qualifier, a 3-1 win at Ecuador on Tuesday, a result that clinched third place in the CONMEBOL standings and earned the Albiceleste a direct ticket to next year's event in Russia.
"My cycle with the national team ends in Russia," Mascherano told TyC Sports. "It's very clear to me that that will be it. There's nothing after that.
"I will try in the next six to seven months to prepare myself to be there although the decision is taken by the coach and it will be him [Jorge Sampaoli] to decide whether I go Russia or not."
Argentina struggled in qualifying and went into Tuesday's encounter in Quito to guarantee their place for the World Cup.
They fell behind immediately but three goals from Lionel Messi handed the two-time World champions a crucial win.
Mascherano, who has made 139 appearances for Argentina since his debut in 2003, would like to finish his international career with a title.
The veteran has endured heartache with the national team, losing to Germany in extra-time in the World Cup final in Brazil three years ago and also falling in the Copa America finals in 2015 and 2016.
"I don't have that many things in my life I still want to do," he said. "Playing in a World Cup and trying to get back to the final is one of them."
With Barcelona, Mascherano has started just four of the last nine games since the Spanish Super Cup and has seen his place taken alongside Gerard Pique in the big games by Samuel Umtiti, who joined the club from Lyon last year.
"There will be time for me to think [about my future]," Mascherano said. "I'm playing less for my club right now because there are two better centre-backs. I will try to fight for my place and to be ready when I'm called upon.
"When you have someone better ahead of you, you accept it and try to turn the situation around. I'm not a player that gets angry, especially not with coaches. I still have a contract with the club and they have shown they are happy with me, but I haven't spoken with anyone yet. Perhaps at the end of this season, I'll analyse what to do."
Mascherano joined Barcelona from Liverpool in 2011, initially as a midfielder, but went on to become the long-term replacement for Carles Puyol in the middle of the back four. He has started at least 20 La Liga games in each of the last six seasons, is well-liked among the squad and has a contract with the club until 2019.
If Mascherano does leave Barcelona, he told ESPN FC in an exclusive interview in the summer that he would explore a number of options, including Major League Soccer, before eventually moving into coaching, something he has already started working towards.
Meanwhile, another player who is hoping to make next year's World Cup with Argentina is Fernando Gago, who underwent successful reconstructive ACL surgery on his left knee on Thursday and will have to fight against the clock to make it back in time.
The Boca Juniors captain was making his first international appearance since 2015 and had only been on the pitch six minutes when he got injured in last week's goalless draw with Peru.
"Fernando Gago's surgery was complicated because there were two ligaments that were affected," Doctor Jorge Batista, who performed the two-hour surgery on the 31-year-old midfielder, told Radio Red.
"Fernando wants to be in the Copa Libertadores and wants to have a chance to play at the World Cup."


text:
First home buyer guide
Please fill out the form to instantly download your FREE step-by-step guide
Want to get straight to the point? Click here to talk to a Coronis Mortgage Broker today. It will cost you nothing, and they will be able to steer you in the right path.
Your full financial situation would need to be reviewed prior to acceptance of any offer or product. Always review your personal position with a finance specialist prior to application. Coronis Mortgage and Finance Pty Ltd ABN 11 169 710 669 | Credit Representative 461844 is authorised under Australian Credit Licence 389328.
A Coronis Group company | Interested in buying, renting, selling, property management, conveyancing, building and pest services or join the Coronis family?
532 Lutwyche Road
Lutwyche, Queensland, Australia 4030
(07) 3828 2060

subset: commoncrawl


text:
The summary below describes major new features, items of note and breaking changes. The full list of issues for 2.1.1 and full list of issues for 2.1.2 are available for those with access to the Encodo issue tracker.
GetList(IEnumerable<IMetaRelation>) method to help products avoid lazy-loading (QNO-5113)
EventLogger and
MailLogger (QNO-5080)
ConfigureDataProviderActionBase has been replaced with
IFeedback and
IStatusFeedback as well as the other special-purpose feedbacks (e.g.
ISchemaMigratorFeedback) have all been updated to require an
IFeedbackLogger or
IStatusLogger in the constructors. This was done to ensure that messages sent to feedbacks are logged, as noted in the highlights above. If you've implemented your own feedbacks, you'll have to accommodate the new constructors.
In part I of this series, we discussed some core concepts of profiling. In that article, we not only discussed the problem at hand, but also how to think about not only fixing performance problems, but reducing the likelihood that they get out of hand in the first place.
In this second part, we'll go into detail and try to fix the problem.
Since we have new requirements for an existing component, it's time to reconsider the requirements for all stakeholders. In terms of requirements, the
IScope can be described as follows:
There is more detail, but that should give you enough information to understand the code examples that follow.
There are many ways of implementing the functional requirements listed above. While you can implement the feature with only requirements, it's very helpful to know usage patterns when trying to optimize code.
Therefore, we'd like to know exactly what kind of contract our code has to implement -- and to not implement any more than was promised.
Sometimes a hopeless optimization task gets a lot easier when you realize that you only have to optimize for a very specific situation. In that case, you can leave the majority of the code alone and optimize a single path through the code to speed up 95% of the calls. All other calls, while perhaps a bit slow, will at least still be yield the correct results.
And "optimized" doesn't necessarily mean that you have to throw all of your language's higher-level constructs out the window. Once your profiling tool tells you that a particular bit of code has introduced a bottleneck, it often suffices to just examine that particular bit of code more closely. Just picking the low-hanging fruit will usually be more than enough to fix the bottleneck.1
I saw in the profiler that creating the
ExpressionContext had gotten considerably slower. Here's the code in the constructor.
foreach (var value in values.Where(v => v != null))
I saw a few potential problems immediately.
Add() had gotten more expensive in order to return the most appropriate object from the
GetInstances() method
The faster version is below:
var scope = CurrentScope;
for (var i = 0; i < values.Length; i++)
var value = values[i];
if (value != null)
Why is this version faster? The code now uses the fact that we know we're dealing with an indexable list to avoid allocating an enumerator and to use non-allocating means of checking null. While the Linq code is highly optimized, a
for loop is always going to be faster because it's guaranteed not to allocate anything. Furthermore, we now call
AddUnnamed() to use the faster registration method because the more involved method is never needed for these objects.
The optimized version is less elegant and harder to read, but it's not terrible. Still, you should use these techniques only if you can prove that they're worth it.
Another minor improvement is that the call to retrieve the scope is made only once regardless of how many objects are added. On the one hand, we might expect only a minor improvement since we noted above that most use cases only ever add one object anyway. On the other, however, we know that we call the constructor 20 million times in at least one test, so it's worth examining.
The call to
CurrentScope gets the last element of the list of scopes. Even something as innocuous as calling the Linq extension method
Last() can get more costly than it needs to be when your application calls it millions of times. Of course, Microsoft has decorated its Linq calls with all sorts of compiler hints for inlining and, of course, if you decompile, you can see that the method itself is implemented to check whether the target of the call is a list and use indexing, but it's still slower. There is still an extra stack frame (unless inlined) and there is still a type-check with
Replacing a call to
Last() with getting the item at the index of the last position in the list is not recommended in the general case. However, making that change in a provably performance-critical area shaved a percent or two off a test run that takes about 45 minutes. That's not nothing.
protected IScope CurrentScope
get { return _scopes.Last(); }
protected IScope CurrentScope
get { return _scopes[_scopes.Count - 1]; }
That takes care of the creation & registration side, where I noticed a slowdown when creating the millions of
ExpressionContext objects needed by the data driver in our product's test suite.
Let's now look at the evaluation side, where objects are requested from the context.
The offending, slow code is below:
public IEnumerable<TService> GetInstances<TService>()
var serviceType = typeof(TService);
var rawNameMatch = this[serviceType.FullName];
var memberMatches = All.OfType<TService>();
var namedMemberMatches = NamedMembers.Select(
item => item.Value
if (rawNameMatch != null)
var nameMatch = (TService)rawNameMatch;
return namedMemberMatches.Union(memberMatches);
As you can readily see, this code isn't particularly concerned about performance. It is, however, relatively easy to read and to figure out the logic behind returning objects, though. As long as no-one really needs this code to be fast -- if it's not used that often and not used in tight loops -- it doesn't matter. What matters more is legibility and maintainability.
But we now know that we need to make it faster, so let's focus on the most-likely use cases. I know the following things:
Scope instances are created with a single object in them and no other objects are ever added.
FirstOrDefault() object.
These extra bits of information will allow me to optimize the already-correct implementation to be much, much faster for the calls that we're likely to make.
The optimized version is below:
public IEnumerable<TService> GetInstances<TService>()
var members = _members;
if (members == null)
yield break;
if (members.Count == 1)
if (members[0] is TService)
yield return (TService)members[0];
yield break;
object exactTypeMatch;
if (TypedMembers.TryGetValue(typeof(TService), out exactTypeMatch))
yield return (TService)exactTypeMatch;
foreach (var member in members.OfType<TService>())
if (!ReferenceEquals(member, exactTypeMatch))
yield return member;
Given the requirements, the handful of use cases and decent naming, you should be able to follow what's going on above. The code contains many more escape clauses for common and easily handled conditions, handling them in an allocation-free manner wherever possible.
You'll notice that returning a value added by-name is not a requirement and has been dropped. Improving performance by removing code for unneeded requirements is a perfectly legitimate solution.
And, finally, how did we do? I created tests for the following use cases:
Here are the numbers from the automated tests.
This looks amazing but remember: while the optimized solution may be faster than the original, all we really know is that we've just managed to claw our way back from the atrocious performance characteristics introduced by a recent change. We expect to see vast improvements versus a really slow version.
Since I know that these calls showed up as hotspots and were made millions of times in the test, the performance improvement shown by these tests is enough for me to deploy a pre-release of Quino via TeamCity, upgrade my product to that version and run the tests again. Wish me luck4
The best approach at this point is to create issues for the other performance investigations you could make. For example, I opened an issue called Optimize allocations in the data handlers (start with IExpressionContexts), documented everything I had analyzed and quickly got back to the issue on which I'd started.↩
For those with access to the Quino Git repository, the diffs shown below come from commit a825d5030ce6f65a452e1db85a308e1351288b96.↩
If you're following along very, very carefully, you'll recall at this point that the requirement stated above is that objects are returned in LIFO order. The faster version of the code returns objects in FIFO order. You can't tell that the original, slow version did guarantee LIFO ordering, but only because the call to get
All members contained a hidden call to the Linq call
Reverse(), which slowed things down even more! I removed the call to reverse all elements because (A) I don't actually have any tests for the LIFO requirement nor (B) do I have any other code that expects it to happen. I wasn't about to make the code even more complicated and possibly slower just to satisfy a purely theoretical requirement. That's the kind of behavior that got me into this predicament in the first place.↩
Spoiler alert: it worked. ;-) The fixes cut the testing time from about 01:30 to about 01:10 for all tests on the build server, so we won back the lost 25%.↩
An oft-quoted bit of software-development sagacity is
Premature optimization is the root of all evil.
As is so often the case with quotes -- especially those on the Internet1 -- this one has a slightly different meaning in context. The snippet above invites developers to overlook the word "premature" and interpret the received wisdom as "you don't ever need to optimize."
Instead, Knuth's full quote actually tells you how much of your code is likely to be affected by performance issues that matter (highlighted below).
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
In other articles, I'd mentioned that we'd upgraded several solutions to Quino 2 in order to test that the API was solid enough for a more general release. One of these products is both quite large and has a test suite of almost 1500 tests. The product involves a lot of data-import and manipulation and the tests include several scenarios where Quino is used very intensively to load, process and save data.
These tests used to run in a certain amount of time, but started taking about 25% longer after the upgrade to Quino 2.
Before doing anything else -- making educated guesses as to what the problem could be, for example -- we measure. At Encodo, we use JetBrains DotTrace to collect performance profiles.
There is no hidden secret: the standard procedure is to take a measurement before and after the change and to compare them. However, so much had changed from Quino 1.13 to Quino 2 -- e.g. namespaces and type names had changed -- that while DotTrace was able to show some matches, the comparisons were not as useful as usual.
A comparison between codebases that hadn't changed so much is much easier, but I didn't have that luxury.
Even excluding the less-than-optimal comparison, it was an odd profile. Ordinarily, one or two issues stick out right away, but the slowness seemed to suffuse the entire test run. Since the direct profiling comparison was difficult, I downloaded test-speed measurements as CSV from TeamCity for the product where we noticed the issue.
How much slower, you might ask? The test that I looked at most closely took almost 4 minutes (236,187ms) in the stable version, but took 5:41 in the latest build.
This test was definitely one of the largest and longest tests, so it was particularly impacted. Most other tests that imported and manipulated data ranged anywhere from 10% to 30% slower.
When I looked for hot-spots, the profile unsurprisingly showed me that database access took up the most time. The issue was more subtle: while database-access still used the most time, it was using a smaller percentage of the total time. Hot-spot analysis wasn't going to help this time. Sorting by absolute times and using call counts in the tracing profiles yielded better clues.
The tests were slower when saving and also when loading data. But I knew that the ORM code itself had barely changed at all. And, since the product was using Quino so heavily, the stack traces ran quite deep. After a lot of digging, I noticed that creating the
ExpressionContext to hold an object while evaluating expressions locally seemed to be taking longer than before. This was my first, real clue.
Once I was on the trail, I found that when evaluating calls (getting objects) that used local evaluation, it was also always slower.
Once you start looking for places where performance is not optimal, you're likely to start seeing them everywhere. However, as noted above, 97% of them are harmless.
To be clear, we're not optimizing because we feel that the framework is too slow but because we've determined that the framework is now slower than it used to be and we don't know why.
Even after we've finished restoring the previous performance (or maybe even making it a little better), we might still be able to easily optimize further, based on other information that we gleaned during our investigation.
But we want to make sure that we don't get distracted and start trying to FIX ALL THE THINGS instead of just focusing on one task at a time. While it's somewhat disturbing that we seem to be created 20 million
ExpressionContext objects in a 4-minute test, that is also how we've always done it, and no-one has complained about the speed up until now.
Sure, if we could reduce that number to only 2 million, we might be even faster3, but the point is that that we used to be faster on the exact same number of calls -- so fix that first.
I found a likely candidate in the
Scope class, which implements the
IScope interface. This type is used throughout Quino, but the two use-cases that affect performance are:
ExpressionContext, which holds the named values and objects to be used when evaluating the value of an
IExpression. These expressions are used everywhere in the data driver.
The former usage has existed unchanged for years; its implementation is unlikely to be the cause of the slowdown. The latter usage is new and I recall having made a change to the semantics of which objects are returned by the
Scope in order to make it work there as well.
You may already be thinking: smooth move, moron. You changed the behavior of a class that is used everywhere for a tacked-on use case. That's definitely a valid accusation to make.
In my defense, my instinct is to reuse code wherever possible. If I already have a class that holds a list of objects and gives me back the object that matches a requested type, then I will use that. If I discover that the object that I get back isn't as predictable as I'd like, then I improve the predictability of the API until I've got what I want. If the improvement comes at no extra cost, then it's a win-win situation. However, this time I paid for the extra functionality with degraded performance.
Where I really went wrong was that I'd made two assumptions:
Avoid changing a type shared by different systems without considering all stakeholder requirements.
I think a few words on process here are important. Can we improve the development process so that this doesn't happen again? One obvious answer would be to avoid changing a type shared by different systems without considering all stakeholder requirements. That's a pretty tall order, though. Including this in the process will most likely lead to less refactoring and improvement out of fear of breaking something.
We discussed above how completely reasonable assumptions and design decisions led to the performance degradation. So we can't be sure it won't happen again. What we would like, though, is to be notified quickly when there is performance degradation, so that it appears as a test failure.
Notify quickly when there is performance degradation
Our requirements are captured by tests. If all of the tests pass, then the requirements are satisfied. Performance is a non-functional requirement. Where we could improve Quino is to include high-level performance tests that would sound the alarm the next time something like this happens.[^5]
Enough theory: in part II, we'll describe the problem in detail and take a crack at improving the speed. See you there.
In fairness, the quote is at least properly attributed. It really was Donald Knuth who wrote it.↩
By "opportunity", of course, I mean that I messed something up that made Quino slower in the new version.↩
See the article Quino 2: Starting up an application, in detail for more information on this usage.↩
I'm working on this right now, in issue Add standard performance tests for release 2.1.↩
The summary below describes major new features, items of note and breaking changes. The full list of issues is also available for those with access to the Encodo issue tracker.
Quino 2 is finally ready and will go out the door with a 2.1 rather than a 2.0 version number. The reason being that we released 2.0 internally and tested the hell out of it. 2.1 is the result of that testing. It includes a lot of bug fixes as well as API tweaks to make things easier for developers.
On top of that, I've gone through the backlog and found many issues that had either been fixed already, were obsolete or had been inadequately specified. The Quino backlog dropped from 682 to 542 issues.
Quino.Web.Glimpse package to use the support we do have (QNO-4560)
HtmlHelpers and other client-side rendering (QNO-3921, QNO-3995, QNO-3804, QNO-3797, QNO-3974, QNO-4001, QNO-3992, QNO-3991, QNO-3973, QNO-3970, QNO-3969, QNO-3918, QNO-3866, QNO-3865, QNO-3857, QNO-3849, QNO-3848, QNO-3842, QNO-3839, QNO-3837, QNO-3836, QNO-3834, QNO-3833, QNO-3831, QNO-3824 w/sub-tasks, QNO-3806, QNO-3805, QNO-3802, QNO-2288)
12 issues marked as incomplete (not sufficiently specified)
The following changes are marked with
Obsolete attributes, so you'll get a hint as to how to fix the problem. Since these are changes from an unreleased version of Quino, they cause a compile error.
UseMetaSchemaWinformDxFeedback() has been renamed to
UseSchemaMigrationSupport() has been renamed to
MetaHttpApplicationBase.MetaApplication has been renamed to
IServer.Run() extension method is no longer supported.
GetStandardFiltersForFormsAuthentication() and
GetStandardFiltersForUnrestrictedAuthentication are no longer supported. Instead, you should register filters in the IOC and use the
IWebFilterAttributeFactory.CreateFilters() to get the list of supported filters
ToolRequirementAttribute is no longer supported or used.
AssemblyExtensions.GetLoadableTypesWithInterface() is no longer supported
AssemblyTools.GetValidAssembly() has been replaced with
GetExecutableName() and
GetExecutablePath() have removed.
MetaBuilderBase (e.g.
EndOfTimeExpression) are obsolete. Instead, use
MetaBuilderBase.ExpressionFactory.Constants.EndOfTime instead.
MetaObjectDescriptionExtensions are obsolete; instead, use the
IMetaObjectFormatterSettings from the IOC to change settings on startup.
GetShortDescription() has been moved to the
IMetaObjectFormatter. Obtain an instance from the IOC, as usual.
The summary below describes major new features, items of note and breaking changes. The full list of issues is also available for those with access to the Encodo issue tracker.
In the beta1 and beta2 release notes, we read about changes to configuration, dependency reduction, the data driver architecture, DDL commands, security and access control in web applications and a new code-generation format.
In 2.0 final -- which was actually released internally on November 13th, 2015 (a Friday) -- we made the following additional improvements:
These notes are being published for completeness and documentation. The first publicly available release of Quino 2.x will be 2.1 or higher (release notes coming soon).
As we've mentioned before, this release is absolutely merciless in regard to backwards compatibility. Old code is not retained as
Obsolete. Instead, a project upgrading to 2.0 will encounter compile errors.
The following notes serve as an incomplete guide that will help you upgrade a Quino-based product.
As I wrote in the release notes for beta1 and beta2, if you arm yourself with a bit of time, ReSharper and the release notes (and possibly keep an Encodo employee on speed-dial), the upgrade is not difficult. It consists mainly of letting ReSharper update namespace references for you.
Instead of going through the errors (example shown to the right) one by one, you can take care of a lot of errors with the following search/replace pairs.
Encodo.Quino.Data.Persistence =>
IMetaApplication =>
ICoreApplication =>
GetServiceLocator() =>
MetaMethodTools.GetInstance =>
application.ServiceLocator.GetInstance =>
Application.ServiceLocator.GetInstance =>
application.ServiceLocator =>
Application.ServiceLocator =>
application.Recorder =>
Application.Recorder =>
session.GetRecorder() =>
Session.GetRecorder() =>
Session.Application.Recorder =>
FileTools.Canonicalize() =>
application.Messages =>
Application.Messages =>
ServiceLocator.GetInstance =>
MetaLayoutTools =>
GlobalContext.Instance.Application.Configuration.Model =>
IMessageRecorder =>
GetUseReleaseSettings() =>
ReportToolsDX =>
Although you can't just search/replace everything, it gets you a long way.
These replacement pairs, while not recommended for global search/replace, are a handy guide for how the API has generally changed.
*Generator => *
SetUpForModule =>
Builder.SetElementVisibility(prop, true) =>
Builder.SetElementVisibility(prop, false) =>
Builder.SetElementControlIdentifier(prop, ControlIdentifiers =>
Builder.SetPropertyHeightInPixels(prop, 200); =>
Constructing a module has also changed. Instead of using the following syntax,
var module = Builder.SetUpForModule<AuditModule>(Name, "ApexClearing.Alps.Core", Name, true);
Replace it with the following direct replacement,
var module = Builder.CreateModule(Name, "ApexClearing.Alps.Core", Name);
Or use this replacement, with the recommended style for the v2 format (no more class prefix for generated classes and a standard namespace):
var module = Builder.CreateModule(Name, typeof(AuditModuleBuilder).GetParentNamespace());
Because of how the module class-names have changed, the standard module ORM classes all have different names. The formula is that the ORM class-name is no longer prepended its module name.
ReportsReportDefinition =>
SecurityUser =>
Furthermore, all modules have been converted to use the v2 code-generation format, which has the metadata separate from the ORM object. Therefore, instead of referencing metadata using the ORM class-name as the base, you use the module name as the base.
ReportReportDefinition.Fields.Name =>
ReportReportDefinition.MetaProperties.Name =>
ReportReportDefinition.Metadata =>
There's an upcoming article that will show more examples of the improved flexibility and capabilities that come with the v2-metadata.
The standard action names have moved as well.
Any other, more rarely used action names have been moved back to the actions themselves, so for example
If you created any actions of your own, then the API there has changed as well. As previously documented in API Design: To Generic or not Generic? (Part II), instead of overriding the following method,
protected override int DoExecute(IApplication application, ConfigurationOptions options, int currentResult)
base.DoExecute(application, options, currentResult);
you instead override in the following way,
public override void Execute()
If you're already using Visual Studio 2015, then the NuGet UI is a good choice for managing packages. If you're still on Visual Studio 2013, then the UI there is pretty flaky and we recommend using the console.
The examples below assume that you have configured a source called "Local Quino" (e.g. a local folder that holds the
nupkg files for Quino).
install-package Quino.Data.PostgreSql.Testing -ProjectName Punchclock.Core.Tests -Source "Local Quino"
install-package Quino.Server -ProjectName Punchclock.Server -Source "Local Quino"
install-package Quino.Console -ProjectName Punchclock.Server -Source "Local Quino"
install-package Quino.Web -ProjectName Punchclock.Web.API -Source "Local Quino"
We recommend using Visual Studio 2015 if at all possible. Visual Studio 2013 is also supported, but we have all migrated to 2015 and our knowhow about 2013 and its debugging idiosyncrasies will deteriorate with time.
These are just brief points of interest to get you set up. As with the NuGet support, these instructions are subject to change as we gain more experience with debugging with packages as well.
Quino.zip as part of the package release)
Quino packages are no different than any other NuGet packages. We provide both standard packages as well as packages with symbols and sources. Any complications you encounter with them are due to the whole NuGet experience still being a bit in-flux in the .NET world.
An upcoming post will provide more detail and examples.
We generally use our continuous integration server to create packages, but you can also create packages locally (it's up to you to make sure the version number makes sense, so be careful). These instructions are approximate and are subject to change. I provide them here to give you an idea of how packages are created. If they don't work, please contact Encodo for help.
%QUINO_ROOT%\src directory
nant build pack to build Quino and packages
%QUINO_ROOT%\nuget (one-time only)
nant nuget from your project directory to get the latest Quino build from your local folder
If you're like us at Encodo, you moved to SSDs years ago...and never looked back. However, SSDs are generally smaller because the price (still) ramps up quickly as you increase size. We've almost standardized on 512GB, but some of us still have 256GB drives.
Unfortunately, knowing that we all have giant hard drives started a trend among manufacturers to just install everything, just in case you might need it. This practice didn't really cause problems when we were still using by-then terabyte-sized HDs. But now, we are, once again, more sensitive to unnecessary installations.
If you're a Windows .NET developer, you'll feel the pinch more quickly as you've got a relatively heavyweight Visual Studio installation (or three...) as well as Windows 8.1 itself, which weighs in at about 60GB after all service packs have been installed.
Once you throw some customer data and projects and test databases on your drive, you might find that you need, once again, to free up some space on your drive.
I wrote a similar post last year and those tips & tricks still apply as well.
One additional tip I have is to use Win + S to search for "Free up disk space by deleting unnecessary files"1 and run that application in "clean up system files" mode: the latest version will throw out as much Windows Update detritus as it can, which can clean up gigabytes of space.
The other measure you can take is to remove programs that you don't use anymore: for .NET developers that means you should finally toss out Visual Studio 2010 -- and possibly even 2013, if you've made the move to the new and improved 2015 already.2 Removing these versions also has the added benefit that extensions and add-ons will no longer try to install themselves into these older Visual Studios anymore.
However, even if you do remove VS2010, for example, you might find that it just magically reappears again. Now, I'm not surprised when I see older runtimes and redistributables in my list of installed programs -- it makes sense to keep these for applications that rely on them -- but when I see the entire VS2010 SP1 has magically reappeared, I'm confused.
Imagine my surprise when I installed SQL Server Management Studio 2016 -- the November 2015 Preview -- and saw the following installation item:
However, if you do remove this item again, then SQL Server Management Studio will no longer run (no surprise there, now that we know that it installed it). However, if you're just doing cleanup and don't know about this dependency3, you might accidentally break tools. So be careful; if you're too aggressive, you'll end up having to re-install some stuff.4
The reason I write that "it's back" is that for a couple of versions of Windows, Microsoft made it an optional download/feature instead of installing it by default.↩
Be careful about removing Visual Studio 2013 if you have web projects that still rely on targets installed with VS2013 but not included in VS2015. I uninstalled 2013 on my laptop and noticed a warning about an MS target that the compiler could no longer find.↩
The fact that Windows still can't tell you about dependencies is a story for another day. We should have had a package manager on Windows years ago. And, no, while Choco is a lovely addition, it's not quite the full-fledged package manager that aptitude is on Ubuntu.↩
Speaking from experience. Could you tell?↩
As part of the final release process for Quino 2, we've upgraded 5 solutions1 from Quino 1.13 to the latest API in order to shake out any remaining API inconsistencies or even just inelegant or clumsy calls or constructs. A lot of questions came up during these conversions, so I wrote the following blog to provide detail on the exact workings and execution order of a Quino application.
I've discussed the design of Quino's configuration before, most recently in API Design: Running an Application (Part I) and API Design: To Generic or not Generic? (Part II) as well as the three-part series that starts with Encodos configuration library for Quino: part I.
The life-cycle of a Quino 2.0 application breaks down into roughly the following stages:
ServicesConfigured action
The first stage is all about putting the application together with calls to
Use various services and features. This stage is covered in detail in three parts, starting with Encodos configuration library for Quino: part I.
Let's tackle this one last because it requires a bit more explanation.
Technically, an application can add code to this stage by adding an
IApplicationAction before the
ServicesConfigured action. Use the
Configure<TService>() extension method in stage 1 to configure individual services, as shown below.
s => s.Behavior = FileLogBehavior.MultipleFiles
The execution stage is application-specific. This stage can be short or long, depending on what your application does.
For desktop applications or single-user utilities, stage 4 is executed in application code, as shown below, in the
Run method, which called by the
ApplicationManager after the application has started.
var transcript = new ApplicationManager().Run(CreateApplication, Run);
IApplication CreateApplication() { ... }
void Run(IApplication application) { ... }
If your application is a service, like a daemon or a web server or whatever, then you'll want to execute stages 1--3 and then let the framework send requests to your application's running services. When the framework sends the termination signal, execute stage 5 by disposing of the application. Instead of calling
Run, you'll call
var application = new ApplicationManager().CreateAndStartUp(CreateApplication);
IApplication CreateApplication() { ... }
Every application has certain tasks to execute during shutdown. For example, an application will want to close down any open connections to external resources, close file (especially log files) and perhaps inform the user of shutdown.
Instead of exposing a specific "shutdown" method, a Quino 2.0 application can simply be disposed to shut it down.
If you use
ApplicationManager.Run() as shown above, then you're already sorted -- the application will be disposed and the user will be informed in case of catastrophic failure; otherwise, you can shut down and get the final application transcript from the disposed object.
var transcript = application.GetTranscript();
// Do something with the transcript...
We're finally ready to discuss stage 2 in detail.
An IOC has two phases: in the first phase, the application registers services with the IOC; in the second phase, the application uses services from the IOC.
An application should use the IOC as much as possible, so Quino keeps stage 2 as short as possible. Because it can't use the IOC during the registration phase, code that runs in this stage shares objects via a poor-man's IOC built into the
IApplication that allows modification and only supports singletons. Luckily, very little end-developer application code will ever need to run in this stage. It's nevertheless interesting to know how it works.
Obviously, any code in this stage that uses the IOC will cause it to switch from phase one to phase two and subsequent attempts to register services will fail. Therefore, while application code in stage 2 has to be careful, you don't have to worry about not knowing you've screwed up.
Why would we have this stage? Some advocates of using an IOC claim that everything should be configured in code. However, it's not uncommon for applications to want to run very differently based on command-line or other configuration parameters. The Quino startup handles this by placing the following actions in stage 2:
An application is free to insert more actions before the
ServicesInitialized action, but they have to play by the rules outlined above.
Code in stage 2 shares objects by calling
SetSingle() and
GetSingle(). There are only a few objects that fall into this category.
The calls
UseCore() and
UseApplication() register most of the standard objects used in stage 2. Actually, while they're mostly used during stage 2, some of them are also added to the poor man's IOC in case of catastrophic failure, in which case the IOC cannot be assumed to be available. A good example is the
Before listing all of the objects, let's take a rough look at how a standard application is started. The following steps outline what we consider to be a good minimum level of support for any application. Of course, the Quino configuration is modular, so you can take as much or as little as you like, but while you can use a naked
Application -- which has absolutely nothing registered -- and you can call
UseCore() to have a bit more -- it registers a handful of low-level services but no actions -- we recommend calling at least
UseApplication() to adds most of the functionality outlined below.
RunMode from the
IRunSettings to determine if the application should catch all exceptions or let them go to the debugger. This involves getting the
IRunSettings from the application and getting the final value using the
IApplicationManagerPreRunFinalizer. This is commonly an implementation that can allows setting the value of
RunMode from the command-line in debug builds. This further depends on the
ICommandSetManager (which depends on the
IValueTools) and possibly the
ICommandLineSettings (to set the
CommandLineConfigurationFilename if it was set by the user).
ICommandProcessingResult, possibly setting other values and adding other configuration steps to the list of startup actions (e.g. many command-line options are switches that are handled by calling
Configure<TSettings>() where
TSettings is the configuration object in the IOC to modify).
IConfigurationDataSettings, involving the
ILocationManager to find configuration files and the
ITextValueNodeReader to read them.
ILogger is used throughout by various actions to log application behavior
IApplicationCrashReporter uses the
IFeedback or the
ILogger to notify the user and log the error
IInMemoryLogger is used to include all in-memory messages in the
The next section provides detail to each of the individual objects referenced in the workflow above.
You can get any one of these objects from the
IApplication in at least two ways, either by using
GetSingle<TService>() (safe in all situations) or
GetInstance<TService>() (safe only in stage 3 or later) or there's almost always a method which starts with "Use" and ends in the service name.
The example below shows how to get the
ICommandSetManager2 if you need it.
application.GetSingle<ICommandSetManager>(); // Prefer the one above
All three calls return the exact same object, though. The first two from the poor-man's IOC; the last from the real IOC.
Only applications that need access to low-level objects or need to mess around in stage 2 need to know which objects are available where and when. Most applications don't care and will just always use
The objects in the poor-man's IOC are listed below.
IValueTools: converts values; used by the command-line parser, mostly to translate enumerate values and flags
ILocationManager: an object that manages aliases for file-system locations, like "Configuration", from which configuration files should be loaded or "UserConfiguration" where user-specific overlay configuration files are stored; used by the configuration loader
ILogger: a reference to the main logger for the application
IInMemoryLogger: a reference to an in-memory message store for the logger (used by the
ApplicationManager to retrieve the message log from a crashed application)
IMessageFormatter: a reference to the object that formats messages for the logger
ICommandSetManager: sets the schema for a command line; used by the command-line parser
ICommandProcessingResult: contains the result of having processed the command line
ICommandLineSettings: defines the properties needed to process the command line (e.g. the
Arguments and
CommandLineConfigurationFilename, which indicates the optional filename to use for configuration in addition to the standard ones)
IConfigurationDataSettings: defines the
ConfigurationData which is the hierarchical representation of all configuration data for the application as well as the
MainConfigurationFilename from which this data is read; used by the configuration-loader
ITextValueNodeReader: the object that knows how to read
ConfigurationData from the file formats supported by the application3; used by the configuration-loader
IRunSettings: an object that manages the
RunMode ("release" or "debug"), which can be set from the command line and is used by the
ApplicationManager to determine whether to use global exception-handling
IApplicationManagerPreRunFinalizer: a reference to an object that applies any options from the command line before the decision of whether to execute in release or debug mode is taken.
IApplicationCrashReporter: used by the
ApplicationManager in the code surrounding the entire application execution and therefore not guaranteed to have a usable IOC available
IApplicationDescription: used together with the
ILocationManager to set application-specific aliases to user-configuration folders (e.g.
IApplicationTranscript: an object that records the last result of having run the application; returned by the
ApplicationManager after
Run() has completed, but also available through the application object returned by
CreateAndStartUp() to indicate the state of the application after startup.
Each of these objects has a very compact interface and has a single responsibility. An application can easily replace any of these objects by calling
UseSingle() during stage 1 or 2. This call sets the object in both the poor-man's IOC as well as the real one. For those rare cases where a non-IOC singleton needs to be set after the IOC has been finalized, the application can call
SetSingle(), which does not touch the IOC. This feature is currently used only to set the
IApplicationTranscript, which needs to happen even after the IOC registration is complete.
application.GetConfigurationDataReader(); // Recommended
Two large customer solutions, two medium-sized internal solutions (Punchclock and JobVortex) as well as the Demo/Sandbox solution. These solutions include the gamut of application types:
* 3 ASP.NET MVC applications
* 2 ASP.NET WebAPI applications
* 2 Windows services
* 3 Winform/DevExpress applications
* 2 Winform/DevExpress utilities
* 4 Console applications and utilities
I originally used
ITextValueNodeReader as an example, but that's one case where the recommended call doesn't match 1-to-1 with the interface name.↩
Currently only XML, but JSON is on the way when someone gets a free afternoon.↩
Quino has long included support for connecting to an application server instead of connecting directly to databases or other sources. The application server uses the same model as the client and provides modeled services (application-specific) as well as CRUD for non-modeled data interactions.
We wrote the first version of the server in 2008. Since then, it's acquired better authentication and authorization capabilities as well as routing and state-handling. We've always based it on the .NET
As late as Quino 2.0-beta2 (which we had deployed in production environments already), the server hierarchy looked like screenshot below, pulled from issue QNO-4927:
This screenshot was captured after a few unneeded interfaces had already been removed. As you can see by the class names, we'd struggled heroically to deal with the complexity that arises when you use inheritance rather than composition.
The state-handling was welded onto an authentication-enabled server, and the base machinery for supporting authentication was spread across three hierarchy layers. The hierarchy only hints at composition in its naming: the "Stateful" part of the class name
CoreStatefulHttpServerBase<TState> had already been moved to a state provider and a state creator in previous versions. That support is unchanged in the 2.0 version.
We mentioned above that implementation was "spread across three hierarchy layers". There's nothing wrong with that, in principle. In fact, it's a good idea to encapsulate higher-level patterns in a layer that doesn't introduce too many dependencies and to introduce dependencies in other layers. This allows applications not only to be able to use a common implementation without pulling in unwanted dependencies, but also to profit from the common tests that ensure the components works as advertised.
In Quino, the following three layers are present in many components:
Encodo.Connections and so on)
Quino.Application and so on).
The diagram below shows the new hotness in Quino 2.2
The hierarchy is now extremely flat. There is an
IServer interface and a
Server implementation, both generic in
TListener, of type
IServerListener. The server manages a single instance of an
The listener, in turn, has an
IHttpServerRequestHandler, the main implementation of which uses an
As mentioned above, the
IServerStateProvider is included in this diagram, but is unchanged from Quino 2.0-beta3, except that it is now used by the request handler rather than directly by the server.
You can see how the abstract layer is enhanced by an HTTP-specific layer (the
Encodo.Server.Http namespace) and the metadata-specific layer is nice encapsulated in three classes in the
Quino.Server assembly.
This type hierarchy has decoupled the main elements of the workflow of handling requests for a server:
It is important to note that this behavior is unchanged from the previous version -- it's just that now each step is encapsulated in its own component. The components are small and easily replaced, with clear and concise interfaces.
Note also that the current implementation of the request handler is for HTTP servers only. Should the need arise, however, it would be relatively easy to abstract away the
HttpListener dependency and generalize most of the logic in the request handler for any kind of server, regardless of protocol and networking implementation. Only the request handler is affected by the HTTP dependency, though: authentication, state-provision and listener-management can all be re-used as-is.
Also of note is that the only full-fledged implementation is for metadata-based applications. At the bottom of the diagram, you can see the metadata-specific implementations for the route registry, state provider and authenticator. This is reflected in the standard registration in the IOC.
These are the service registrations from
return handler
.RegisterSingle<IServerSettings, ServerSettings>()
.RegisterSingle<IServerListenerFactory<HttpServerListener>, HttpServerListenerFactory>()
.Register<IServer, Server<HttpServerListener>>();
And these are the service registrations from
.RegisterSingle<IServerRouteRegistry<IMetaServerState>, StandardMetaServerRouteRegistry>()
.RegisterSingle<IServerStateProvider<IMetaServerState>, MetaPersistentServerStateProvider>()
.RegisterSingle<IServerStateCreator<IMetaServerState>, MetaServerStateCreator>()
.RegisterSingle<IHttpServerAuthenticator<IMetaServerState>, MetaHttpServerAuthenticator>()
.RegisterSingle<IHttpServerRequestHandler, HttpServerRequestHandler<IMetaServerState>>()
As you can see, the registration is extremely fine-grained and allows very precise customization as well as easy mocking and testing.
Any Men in Black fans out there? Tommy Lee Jones was "old and busted" while Will Smith was "the new hotness"? No? Just me? All righty then...↩
This diagram brought to you by the diagramming and architecture tools in ReSharper 9.2. Just select the files or assemblies you want to diagram in the Solution Explorer and choose the option to show them in a diagram. You can right-click any type or assembly to show dependent or referenced modules or types. For type diagrams , you can easily control which relationships are to be shown (e.g. I hide aggregations to avoid clutter) and how the elements are to be grouped (e.g. I grouped by namespace to include the boxes in my diagram).↩
In the previous article, we discussed the task of Splitting up assemblies in Quino using NDepend. In this article, I'll discuss both the high-level and low-level workflows I used with NDepend to efficiently clear up these cycles.
Please note that what follows is a description of how I have used the tool -- so far -- to get my very specific tasks accomplished. If you're looking to solve other problems or want to solve the same problems more efficiently, you should take a look at the official NDepend documentation.
To recap briefly: we are reducing dependencies among top-level namespaces in two large assemblies, in order to be able to split them up into multiple assemblies. The resulting assemblies will have dependencies on each other, but the idea is to make at least some parts of the Encodo/Quino libraries opt-in.
On a high-level, I tackled the task in the following loosely defined phases.
Remove direct, root-level dependencies
This is the big first step -- to get rid of the little black boxes. I made NDepend show only direct dependencies at first, to reduce clutter. More on specific techniques below.
Remove indirect dependencies
Crank up the magnification to show indirect dependencies as well. This will will help you root out the remaining cycles, which can be trickier if you're not showing enough detail. On the contrary, if you turn on indirect dependencies too soon, you'll be overwhelmed by darkness (see the depressing initial state of the Encodo assembly to the right).
Examine dependencies between root-level namespaces
Even once you've gotten rid of all cycles, you may still have unwanted dependencies that hinder splitting namespaces into the desired constellation of assemblies.
For example, the plan is to split all logging and message-recording into an assembly called
Encodo.Logging. However, the
IRecorder interface (with a single method,
Log()) is used practically everywhere. It quickly becomes necessary to split interfaces and implementation -- with many more potential dependencies -- into two assemblies for some very central interfaces and support classes. In this specific case, I moved
IRecorder to
Even after you've conquered the black hole, you might still have quite a bit of work to do. Never fear, though: NDepend is there to help root out those dependencies as well.
Examine cycles in non-root namespaces
Because we can split off smaller assemblies regardless, these dependencies are less important to clean up for our current purposes. However, once this code is packed into its own assembly, its namespaces become root namespaces of their own and -- voila! you have more potentially nasty dependencies to deal with. Granted, the problem is less severe because you're dealing with a logically smaller component.
In Quino, use non-root namespaces more for organization and less for defining components. Still, cycles are cycles and they're worth examining and at least plucking the low-hanging fruit.
With the high-level plan described above in hand, I repeated the following steps for the many dependencies I had to untangle. Don't despair if it looks like your library has a ton of unwanted dependencies. If you're smart about the ones you untangle first, you can make excellent -- and, most importantly, rewarding -- progress relatively quickly.1
The high-level plan of attack sounded interesting, but might have left you cold with its abstraction. Then there was the promise of detail with a focus on root-level namespaces, but alas, you might still be left wondering just how exactly do you reduce these much-hated cycles?
I took some screenshots as I worked on Quino, to document my process and point out parts of NDepend I thought were eminently helpful.
I mentioned above that you should "[k]eep zooming in", but how do you do that? A good first step is to zoom all the way out and show only direct namespace dependencies. This focuses only on
using references instead of the much-more frequent member accesses. In addition, I changed the default setting to show dependencies in only one direction -- when a column references a row (blue), but not vice versa (green).
As you can see, the diagrams are considerably less busy than the one shown above. Here, we can see a few black spots that indicate cycles, but it's not so many as to be overwhelming.2 You can hover over the offending squares to show more detail in a popup.
If you don't see any more cycles between namespaces, switch the detail level to "Members". Another very useful feature is to "Bind Matrix", which forces the columns and rows to be shown in the same order and concentrates the cycles in a smaller area of the matrix.
As you can see in the diagram, NDepend then highlights the offending area and you can even click the upper-left corner to focus the matrix only on that particular cycle.
Once you're looking at members, it isn't enough to know just the namespaces involved -- you need to know which types are referencing which types. The powerful matrix view lets you drill down through namespaces to show classes as well.
If your classes are large -- another no-no, but one thing at a time -- then you can drill down to show which method is calling which method to create the cycle. In the screenshot to the right, you can see where I had to do just that in order to finally figure out what was going on.
In that screenshot, you can also see something that I only discovered after using the tool for a while: the direction of usage is indicated with an arrow. You can turn off the tooltips -- which are informative, but can be distracting for this task -- and you don't have to remember which color (blue or green) corresponds to which direction of usage.
Once you've drilled your way down from namespaces-only to showing member dependencies, to focusing on classes, and even members, your diagram should be shaping up quite well.
On the right, you'll see a diagram of all direct dependencies for the remaining area with a problem. You don't see any black boxes, which means that all direct dependencies are gone. So we have to turn up the power of our microscope further to show indirect dependencies.
On the left, you can see that the scary, scary black hole from the start of our journey has been whittled down to a small, black spot. And that's with all direct and indirect dependencies as well as both directions of usage turned on (i.e. the green boxes are back). This picture is much more pleasing, no?
For the last cluster of indirect dependencies shown above, I had to unpack another feature: NDepend queries: you can select any element and run a query to show using/used by assemblies/namespaces.3 The results are shown in a panel, where you can edit the query see live updates immediately.
Even with a highly zoomed-in view on the cycle, I still couldn't see the problem, so I took NDepend's suggestion and generated a graph of the final indirect dependency between
Culture and
Enums (through
Expression). At this zoom level, the graph becomes more useful (for me) and illuminates problems that remain muddy in the matrix (see right).
In order to finish the job efficiently, here are a handful of miscellaneous tips that are useful, but didn't fit into the guide above.
And BOOM! just like that4, phase 1 (root namespaces) for Encodo was complete! Now, on to Quino.dll...
Depending on what shape your library is in, do not underestimate the work involved. Even with NDepend riding shotgun and barking out the course like a rally navigator, you still have to actually make the changes. That means lots of refactoring, lots of building, lots of analysis, lots of running tests and lots of reviews of at-times quite-sweeping changes to your code base. The destination is worth the journey, but do not embark on it lightly -- and don't forget to bring the right tools.5
This can be a bit distracting: you might get struck trying to figure out which of all these offenders to fix first.↩
I'm also happy to report that my initial forays into maintaining a relatively clean library -- as opposed to cleaning it -- with NDepend have been quite efficient.↩
And much more: I don't think I've even scratched the surface of the analysis and reporting capabilities offered by this ability to directly query the dependency data.↩
I'm just kidding. It was a lot of time-consuming work.↩
In this case, in case it's not clear: NDepend for analysis and good ol' ReSharper for refactoring. And ReSharper's new(ish) architecture view is also quite good, though not even close to detailed enough to replace NDepend: it shows assembly-level dependencies only.↩
A lot of work has been put into Quino 2.01, with almost no stone left unturned. Almost every subsystem has been refactored and simplified, including but not limited to the data driver, the schema migration, generated code and metadata, model-building, security and authentication, service-application support and, of course, configuration and execution.
Two of the finishing touches before releasing 2.0 are to reorganize all of the code into a more coherent namespace structure and to reduce the size of the two monolithic assemblies: Encodo and Quino.
The first thing to establish is: why are we doing this? Why do we want to reduce dependencies and reduce the size of our assemblies? There are several reasons, but a major reason is to improve the discoverability of patterns and types in Quino. Two giant assemblies are not inviting -- they are, in fact, daunting. Replace these assemblies with dozens of smaller ones and users of your framework will be more likely to (A) find what they're looking for on their own and (B) build their own extensions with the correct dependencies and patterns. Neither of these is guaranteed, but smaller modules are a great start.
Another big reason is portability. The .NET Core was released as open-source software some time ago and more and more .NET source code is added to it each day. There are portable targets, non-Windows targets, Universal-build targets and much more. It makes sense to split code up into highly portable units with as few dependencies as possible. That is, the dependencies should be explicit and intended.
Not only that, but NuGet packaging has come to the fore more than ever. Quino was originally designed to keep third-party boundaries clear, but we wanted to make it as easy as possible to use Quino. Just include Encodo and Quino and off you went. However, with NuGet, you can now say you want to use Quino.Standard and you'll get Quino.Core, Encodo.Core, Encodo.Services.SimpleInjector, Quino.Services.SimpleInjector and other packages.
With so much interesting code in the Quino framework, we want to make it available as much as possible not only for our internal projects but also for customer projects where appropriate and, also, possibly for open-source distribution.
I've used NDepend before2 to clean up dependencies. However, the last analysis I did about a year ago showed quite deep problems3 that needed to be addressed before any further dependency analysis could bear fruit at all. With that work finally out of the way, I'm ready to re-engage with NDepend and see where we stand with Quino.
As luck would have it, NDepend is in version 6, released at the start of summer 2015. As was the case last year, NDepend has generously provided me with an upgrade license to allow me to test and evaluate the new version with a sizable and real-world project.
Here is some of the feedback I sent to NDepend:
I really, really like the depth of insight NDepend gives me into my code. I find myself thinking "SOLID" much more often when I have NDepend shaking its head sadly at me, tsk-tsking at all of the dependency snarls I've managed to build.
Before I get more in-depth with NDepend, please note that there at least two main use cases for this tool4:
These two use cases are vastly different. The first is like cleaning a gas-station bathroom for the first time in years; the second is more like the weekly once-over you give your bathroom at home. The tools you'll need for the two jobs are similar, but quite different in scope and power. The same goes for NDepend: how you'll use it to claw your way back to architectural purity is different than how you'll use it to occasionally clean up an already mostly-clean project.
Quino is much better than it was the last time we peeked under the covers with NDepend, but we're still going to need a bucket of industrial cleaner before we're done.5
The first step is to make sure that you're analyzing the correct assemblies. Show the project properties to see which assemblies are included. You should remove all assemblies from consideration that don't currently interest you (especially if your library is not quite up to snuff, dependency-wise; afterwards, you can leave as many clean assemblies in the list as you like).6
Running an analysis with NDepend 6 generates a nice report, which includes the following initial dependency graph for the assemblies.
As you can see, Encodo and Quino depend only on system assemblies, but there are components that pull in other references where they might not be needed. The initial dependency matrices for Encodo and Quino both look much better than they did when I last generated one. The images below show what we have to work with in the Encodo and Quino assemblies.
It's not as terrible as I've made out, right? There is far less namespace-nesting, so it's much easier to see where the bidirectional dependencies are. There are only a handful of cyclic dependencies in each library, with Encodo edging out Quino because of (A) the nature of the code and (B) I'd put more effort into Encodo so far.
I'm not particularly surprised to see that this is relatively clean because we've put effort into keeping the external dependencies low. It's the internal dependencies in Encodo and Quino that we want to reduce.
The goal, as stated in the title of this article, is to split Encodo and Quino into separate assemblies. While removing cyclic dependencies is required for such an operation, it's not sufficient. Even without cycles, it's still possible that a given assembly is still too dependent on other assemblies.
Before going any farther, I'm going to list the assemblies we'd like to have. By "like to have", I mean the list that we'd originally planned plus a few more that we added while doing the actual splitting.7 The images on the right show the assemblies in Encodo, Quino and a partial overview of the dependency graph (calculated with the ReSharper Architecture overview rather than with NDepend, just for variety).
Of these, the following assemblies and their dependencies are of particular interest[^8]:
Encodo.Core and
Encodo.Application and
Quino.Application and some Encodo.* assemblies
This seems like a good spot to stop, before getting into the nitty-gritty detail of how we used NDepend in practice. In the next article, I'll discuss both the high-level and low-level workflows I used with NDepend to efficiently clear up these cycles. Stay tuned!
Articles about design:
* [Encodos configuration library for Quino: part I](/blogs/developer-blogs/encodos-configuration-library-for-quino-part-i/)
* [Encodos configuration library for Quino: part II](/blogs/developer-blogs/encodos-configuration-library-for-quino-part-ii/)
* [Encodos configuration library for Quino: part III](/blogs/developer-blogs/encodos-configuration-library-for-quino-part-iii/)
* [API Design: Running an Application (Part I)](/blogs/developer-blogs/api-design-running-an-application-part-i/)
* [API Design: To Generic or not Generic? (Part II)](/blogs/developer-blogs/api-design-to-generic-or-not-generic-part-ii/)
Several valid .NET assemblies with the name have been found. They all have the same version. the one with the biggest file has been chosen.
If NDepend has accidentally found an older copy of your assembly, you must delete that assembly. Even if you add an assembly directly, NDepend will not honor the path from which you added it. This isn't as bad as it sounds, since it's a very strange constellation of circumstances that led to this assembly hanging around anyway:
* The project is no longer included in the latest Quino but lingers in my workspace
* The version number is unfortunately the same, even though the assembly is wildly out of date
I only noticed because I knew I didn't have that many dependency cycles left in the Encodo assembly.
Release notes for 2.0 betas:
* [v2.0-beta1: Configuration, services and web](/blogs/developer-blogs/v20-beta1-configuration-services-and-web/)
* [v2.0-beta2: Code generation, IOC and configuration](/blogs/developer-blogs/v20-beta2-code-generation-ioc-and-configuration/)
I published a two-parter in August and November of 2014.
* [The Road to Quino 2.0: Maintaining architecture with NDepend (part I)](/blogs/developer-blogs/the-road-to-quino-20-maintaining-architecture-with-ndepend-part-i/)
* [The Road to Quino 2.0: Maintaining architecture with NDepend (part II)](/blogs/developer-blogs/the-road-to-quino-20-maintaining-architecture-with-ndepend-part-ii/)
You can see a lot of the issues associated with these changes in the release notes for Quino 2.0-beta1 (mostly the first point in the "Highlights" section) and Quino 2.0-beta2 (pretty much all of the points in the "Highlights" section).↩
I'm sure there are more, but those are the ones I can think of that would apply to my project (for now).↩
...to stretch the gas-station metaphor even further.↩
Here I'm going to give you a tip that confused me for a while, but that I think was due to particularly bad luck and is actually quite a rare occurrence.↩
Especially for larger libraries like Quino, you'll find that your expectations about dependencies between modules will be largely correct, but will still have gossamer filaments connecting them that prevent a clean split. In those cases, we just created new assemblies to hold these common dependencies. Once an initial split is complete, we'll iterate and refactor to reduce some of these ad-hoc assemblies.[^8]: Screenshots, names and dependencies are based on a pre-release version of Quino, so while the likelihood is small, everything is subject to change.↩
Stay tuned for an upcoming post on the details of starting up an application, which is the support provided in


text:
John Rabbit BundricK
Birth name John Douglas Bundrick
Born November 21, 1948 (age 69)
Houston, Texas, United States
Genres Blues-rock, hard rock, blues
Occupation(s) Musician, Songwriter, Producer
Instruments Keyboards, piano, vocals
Years active 1971–present
Associated acts Free
the Who
Johnny Nash
Bob Marley
Website rabbitwho.com
John Douglas ""Rabbit"" Bundrick (born November 21, 1948 in Houston, Texas) is an American rock keyboardist, pianist and organist. He is best known for his work with the Who and associations with others including Eric Burdon, Bob Marley and the Wailers, Roger Waters, Free and Crawler. Bundrick is noted as the principal musician for the cult film The Rocky Horror Picture Show. In the mid-1970s, he was a member of the short-lived group Mallard, formed by ex-members of Captain Beefheart's Magic Band. He is also known as a composer and has recorded solo albums. He was also a member of the Texas group, Blackwell, who had a hit single in 1969, I believe, entitled "Wonderful". [1][2] [3]
1 Biography
1.1 Kossoff, Kirke, Tetsu and Rabbit
1.2 Johnny Nash and Bob Marley
1.3 Free
1.4 Pete Townshend and The Who
1.5 2008–present
2 Selected discography
3 References
4 External links
Kossoff, Kirke, Tetsu and Rabbit[edit]
In 1971, Bundrick recorded and wrote five tracks for the album Kossoff Kirke Tetsu Rabbit with guitarist Paul Kossoff, drummer Simon Kirke and bassist Tetsu Yamauchi.[4]
Johnny Nash and Bob Marley[edit]
Bundrick toured and recorded with Texan vocalist Johnny Nash. Bundrick played on Nash's hit single and album ""I Can See Clearly Now"" (1972). He met Bob Marley while in Sweden, while working on the soundtrack to the Swedish film Vill så gärna tro. Marley, Bundrick, and Johnny Nash became roommates there during the stay. Sometime after their return to London, Bundrick was brought in to collaborate on arrangements for Marley's Catch a Fire album, adding keyboards to the original Jamaican recordings to make the record more accessible to listeners.[5] Around this time, Bundrick also worked with Chris Blackwell of Island Records, appearing on recordings by the company.
In 1972 the members of Free reformed joined by Bundrick on keyboards. They recorded Free's final album Heartbreaker, which included ""Muddy Water"" and ""Common Mortal Man"" by Bundrick, who was also credited for collaborations on two other tracks. After a brief tour period of touring Free broke up.[6]
Pete Townshend and The Who[edit]
The Who in 2007; L to R – drummer Zak Starkey, Roger Daltrey, Pete Townshend and John ""Rabbit"" Bundrick
Bundrick first worked with Pete Townshend in 1977 when he performed on Rough Mix, Townshend's solo collaboration with Ronnie Lane, former bass player for Small Faces and Faces. He was invited to play on the Who's album Who Are You (1978), but broke his arm falling out of a taxi at the studio door and was unable to participate in recording sessions. Bundrick toured with The Who from 1979 to 1981 along with drummer Kenney Jones and played on their album Face Dances (1981), then briefly parted with the band during the recording of It's Hard (1982) and the subsequent tour. Bundrick later rejoined the band performing with them at Live Aid in 1985 and played live with them until 2012.
Bundrick played on the Who's single ""Real Good Looking Boy"" and ""Old Red Wine"" in 2004, and on their album Endless Wire (2006) and joined the band for The Who Tour 2006-2007, appearing in the summer and fall concerts. He missed the start of the second leg of the North American tour due to the illness of his wife Sue; keyboard technician Brian Kehew took keyboard duties. Townshend said at the time that Sue was ""very close to the end, and [Rabbit] will be back with us when she's gone"".[citation needed]
In the spring of 2008, Bundrick married Canadian Jody Ahern. On July 12, 2008, he performed at the recording of VH1 Honors The Who in Los Angeles. He then worked with English alternative folk band Small Engine Repair and has recently played on their track ""This Whole Setup Is A Lie"". In December 2009, it was announced he was working with the band Night Parade on their new album.
Bundrick performed with the Who for their Super Bowl XLIV halftime show in 2010. He played with the group in 2011 at a charity show[7] but was replaced in the subsequent tours. Pete Townshend has commented that there "".. was an issue between Roger [Daltrey] and Rabbit.""[8]
Selected discography[edit]
1971 Kossoff Kirke Tetsu Rabbit
1972 Johnny Nash – I Can See Clearly Now
1972 Sandy Denny – Sandy
1973 Free – Heartbreaker
1973 Paul Kossoff – Back Street Crawler
1973 John Martyn – Solid Air
1973 Bundrick – Broken Arrows
1973 Donovan – Cosmic Wheels
1974 Bundrick – Dark Saloon
1974 Kevin Ayers, John Cale, Nico, Eno – June 1, 1974
1974 Bryn Haworth – Let the Days Go By
1975 The Rocky Horror Picture Show
1975 Jim Capaldi – Short Cut Draw Blood
1975 Andy Fairweather Low – La Booga Rooga
1977 Joan Armatrading – Show Some Emotion
1977 Eric Burdon – Survivor
1977 Townshend & Lane – Rough Mix
1979 The Only Ones – Special View
1980 Pete Townshend – Empty Glass
1981 The Who – Face Dances
1985 Deep End – Deep End Live!
1988 Bundrick – Dream Jungle
1992 Roger Waters – Amused to Death
1998 Fairport Convention – Cropredy 98
2006 The Who – Endless Wire
2007 Mick Jagger – The Very Best of Mick Jagger (Deluxe Edition)
2015 208 Talks of Angels – Made in Hell
2017 The Puss Puss Band - Echoes Across the Cruel Sea
Rough as a Diamond
a nice little reggae tune that me and greg wrote together. mixed by DJ
Trouble in Mind
a song from my album Tour Guide
Licensed Cover
A song taken from my album Tour Guide
Yellow House....sung by Tommy Taylor
a lovely little ballad of mine, covered by Johnny Nash, and Kossoff, Kirke Tetsu & Rabbit album...Island Records 1971
A song I wrote when I was 13 years old.....
Licensed Cover
funky jazzy thang
Outlandish man stuck out in Space without his girl
grooving guitar instrumental
rab jazz african idea1
African drums to dance to...
©2015-2016 Indie Music People All Rights Reserved
Last pageview at: 8/4/2020 7:30:25 AMPageviews: 2048


text:
If a cutesy action figure like Figma Kurisu Makise is the perfect follow-up to the very hot-blooded Mechanic Collection Mazinger Z with God Scrander, who would be the next suitable candidate for her to pass the baton to in this never-ending review relay?
Oh I know, how about an ugly Samurai-Skeletor Transformers hybrid? XD Sounds perfect, and I have just the right item in my collection to fill in that role. XD
Transformers: Revenge of the Fallen RD-20 N.E.S.T. Decepticon Bludgeon
Production company: Takara Tomy
Release date: Late January 2010
Price: 3,800 Yen (exclusive of tax)
Merchandise link
This is actually the second Samurai themed Transformers figure, a Decepticon no less, to be featured on my blog in this year alone. ^^ The first one was Transformers Alternity Megatron Blade Silver reviewed in May. ^^
With Bludgeon, it's a visit to the Transformers toy archive no doubt. ^^ While everyone is having fun with the latest releases from the fourth movie, "Age of Extinction", I'm going to do a review on a figure from the second movie instead. ^^ As part of N.E.S.T. line, Bludgeon is a character who never appeared on screen in "Revenge of the Fallen", so my purchase decision for the figure is solely based on its transformation design and gimmicks. For that matter, Bludgeon is amazingly well designed, despite being a toy-only character. ^^
Released in late January 2010, this is the Takara Tomy version based off the original Hasbro release which came out about a year earlier. Bludgeon is a Voyager Class figure, even though this Takara Tomy version didn't place any emphasis on that classification in its product name. Also, as with many other Transformers figures, Bludgeon's mold was later reused to release a couple of variants, with the first one being Banzaitron. As basically a metallic gray on mecha gray Bludgeon with green and copper deco, Banzaitron's recolor is actually quite good in my opinion. If you like Bludgeon's designs but don't fancy its secondary color being orange, Banzaitron is a fine substitute I reckon. ^^
Interestingly, out of Bludgeon's mold also came Megatron, not one but two: ^^ the initial purple on bright green Generations GDO (Global Development Organization) G2 version, and the more recent Transformers Cloud version, which is just the former but in G1 gray and silver color scheme. Both of them are limited releases in Asia by the way. I suppose Bludgeon's alternate mode as a tank does suit Megatron's image, as the Decepticons boss does transform into a tank at one point in history, but the claw feet, skeletal frame inside the limbs, and most importantly, using katanas and a short knife as its main weapon instead of a cannon is a bit stretching to convincingly show off a retooled Bludgeon as Megatron. ^^;
Then again, there are many other retooled Transformers figures that share the same unexplainable, sometimes bizarre choice of design, so just for their alternate mode, the connection between Bludgeon and Megatron is alright I suppose. XD
Front view of the box.
Credits to whoever designed Bludgeon's packaging. ^^ The placement of the tank gives it a more dynamic look inside the box, and more of its details get to be revealed as well.
Closeup on Bludgeon's face design on the bottom right corner of the box.
(Left) Logo of the second movie.
(Right) Level 3 (of 4), "Advanced" in terms of transformation technicality.
The Japanese logo of the movie, and the N.E.S.T. emblem can be seen on the top right corner of the box.
Takara Tomy version only extra materials I believe: a N.E.S.T. sticker, and a small promo booklet entitled "Perfect Guide".
Having no loose option part or accessory, almost all of the tank's top and side views can be seen clearly through the front window. ^^
Closeups on the content.
Left, right, top, and bottom sides of the box.
Bludgeon's arch-rival, Recon Ironhide, or RA-26 in this Takara Tomy line is somewhat previewed on the bottom side of the box. ^^;
Introduction of the character on the back of the box.
Size comparison between Bludgeon's box and that of "Transformers: Prime" Voyager Class "First Edition" Optimus Prime.
Just for the fun of it, size comparison with Figma Drossel (Charming). ^^
Box open.
Package content.
Box content. The excessive space around the tank to accommodate it in such a misaligned position can be observed. The box size can definitely be reduced if such an arrangement for display is omitted.
Closeups on the details.
Rear view of the paper box.
Two rather thick strings bind the tank to the plastic tray.
The tray itself has such tight grip on Bludgeon that the tank doesn't fall out even when it's being held in an upside down position. ^^
A specially designed plastic "dock" helps to support the machine gun on top the turret, while the right smoke grenade launcher is covered by a small clear cap.
The folded instruction sheet, promo booklet, and N.E.S.T. sticker are enclosed in a plastic bag.
Plenty of Japanese text on the instruction sheet to confuse those who can't read the language during transformation. XD
Character rivalries in this toy-only storyline, and more importantly, a preview of all related figures can be seen in "N.E.S.T. Perfect Guide".
The special sticker.
The tank mode of Bludgeon can be displayed straight out of box without any additional adjustment. ^^
A look at the tank mode of Bludgeon in the next posting. ^^


text:
Resident re-specialist John Norris takes a look at war films…continue reading >
The New Forest in Hampshire covers an area of some 150 square miles proper and is visited by over 14 million tourists each year. But how...continue reading >
The invasion may have knocked Italy out of the war but Germans troops fought until the...continue reading >
Despite sounding like the title of a war novel, this film is far from being a...continue reading >
Despite sounding like the title of a war novel, this film is far from being a work of fiction.continue reading >
The Bookshelf & DVDscontinue reading >
The North Atlantic was the main battlefield of the German submarines.continue reading >
Original German film footage - The top fighter planes.continue reading >
Original archive footage crafted into a new documentary.continue reading >
Germany flirted briefly with the idea of building an aircraft carrier, the Graf Zeppelin, and although the idea was eventually dropped the Luftwaffe deployed a number...continue reading >
Buy & Sell Online. Advertise your guns and accessories and be seen by 1000's of buyers..... Buying a Gun or Accessory, Choose from 1000's of items for sale....


text:
A judge based in Wyoming who was censured for publicly stating her opposition to same-sex marriage has appealed her case to the U.S. Supreme Court on Friday.
Judge Ruth Neely, who served as a municipal judge for 22 years and as a part-time circuit court magistrate for about 15 years, was censured by the Wyoming Supreme Court in March 2017 for her comments to a reporter in 2014 saying that she believes marriage "is the union of a man and a woman," according to a press release by her attorneys at Alliance Defending Freedom (ADF).
In March of 2015, the Wyoming Commission on Judicial Conducts and Ethics filed a complaint against Neely regarding her comments, and the commission recommended in February 2016 that Neely be removed from both her roles as a municipal judge and circuit court magistrate. Neely then appealed to the state Supreme Court, which ruled against her in March 2017 with a 3 to 2 vote.
Neely was then required to solemnize all marriages or none, which led to her losing her magistrate position.
"The Wyoming Supreme Court said that it had to punish Judge Neely to uphold 'judicial integrity' even though it recognized that there was 'no evidence' that Judge Neely's comments harmed 'respect for the judiciary' or 'any person,'" said the ADF.
However, Neely's attorneys argue that the state of Wyoming "allows magistrates to decline wedding requests for countless secular reasons — because they refuse to perform weddings for strangers, they simply don't feel like marrying the couple, or they prefer to watch a football game."
"But the state punished Judge Neely for saying that she would need to refer some wedding requests for a religious reason," the ADF stated.
The ADF also noted that Neely was never asked to solemnize any same-sex marriages, and that if she was asked, she would have referred the couple to another magistrate.
Unless an extension is requested, the state of Wyoming will file a response within 30 days, according to the ADF.


text:
Air Asia has upgraded their Windows Phone app to a Universal Windows App for phones and PCs.
The AirAsia Mobile App makes it easier for you to book flights and check-in while on-the-go. It offers their lowest fares, lets you manage your booking and pre-book meals, seats, baggage and travel insurance.
The app also lets you check in by using a barcode in the app. Just scan the barcode at the airport kiosk to print your boarding pass. You can also opt to get an e-boarding pass which allows you to go straight to the gate if you have no bags to check-in.
It features:
- Flight Booking
- Flight Check-In
- eBoarding Pass & QR Code
- AirAsiaBIG Membership Login (SSO)
- Flight Search
- Optimised for Desktop
- Cortana Integrated
See screen shots of the app below:
Gallery : Air Asia app screen shots
Find the app in the Windows Store here.
Developer: AirAsia Bhd
Price: Code needed


text:
- Products & Services
- Solutions
- Knowledge Base
- Company
Our goal at BMW Discount Parts is to provide genuine OEM parts and accessories at excellent prices to BMW and MINI enthusiasts.
SAN DIEGO, CA, June 13, 2018 /24-7PressRelease/ -- BMW Discount Parts is a family owned company located in Escondido, CA. a subsidiary of a local BMW and MINI dealership. The website sells factory direct BMW parts and accessories . All products in their catalog are genuine OEM with a manufacturer's warranty. The site is designed to provide an intuitive user-friendly experience.
"To some, BMW is more than a brand; it's a lifestyle," states Robert Scott, a spokesperson for BMW Discount Parts. "A common theme among BMW owners is a dedication that is unique and not found in the majority of automobile brands. Our goal at BMW Discount Parts is to provide genuine OEM parts and accessories at excellent prices to BMW and MINI enthusiasts. We pride ourselves on outstanding customer service. Our dedicated team is here to help you find the correct parts for your vehicle. If you are looking for a simple-to- use online catalog of genuine OEM BMW and MINI parts and accessories, BMW Discount Parts is an excellent choice."
The online parts catalog intuitively guides customers browsing for BMW and MINI parts and accessories. The catalog also contains a complete selection of Dinan performance parts. The website allows users to easily create an order and conveniently checkout via PayPal. As with any other retailer, it is recommended users review the various BMW Discount Parts disclosures; These include, terms and conditions, privacy, shipping and return policies. Dedicated parts specialists will expeditiously fulfill each order. Users can simply track their order through a designated online interface. The store is open Monday through Friday from 8am to 6pm and Saturday 9am to 3pm Pacific Standard time.
For further information regarding current or classic BMW or MINI products or accessories contact BMW Discount Parts using the information below.
BMW Discount Parts is located at 330 S. Hale Ave in Escondido, CA (92029). The company can be contacted toll-free via telephone at (800) 544-4269 or through their website at https://bmwdiscountparts.com.
# # #


text:
Questions About Her Future Follow Danica To Japan
By Jonathan Ingram | Senior Writer
Motegi, Japan – Danica Patrick took the racing world by storm on a rainy spring weekend at the Twin Ring Motegi circuit last year when she became the first woman to win an IndyCar race. In this year's return of the series to the Japanese track on a balmy September weekend, there's doubt about Patrick's return next year – or her chances of winning this year.
The favorites on intermediate speedways are the same two teams wrestling over the championship – Penske Racing and Target Chip Ganassi Racing. The performance of the Andretti Green Racing team where Patrick is one of three drivers, has been lacking enough that team owner Michael Andretti has re-organized as part of his effort to sign Patrick to a new contract, a deal that is still not confirmed.
"We haven't won a race this year and that's very different for us," said Patrick, whose fifth place in the points is the best among teammates Tony Kanaan and Marco Andretti. "We've struggled over all. But I don't think there's any reason why we can't come here and win this weekend."
In the midst of negotiations which could include both a deal with AGR and selected races in the Nationwide Series of NASCAR in 2010, Patrick declined to confirm whether she'd be back in an IndyCar in Japan next year. That leaves open the possibility she will run NASCAR full time. "You'll know when I tell you," she said tersely when asked during a media conference packed with Japanese and American reporters.
Andretti said recently he expected to sign Patrick to his team for next year. But NASCAR team owner Tony Stewart has said subsequently that he expects Patrick to compete in the Nationwide Series next season after a second meeting with the driver at Stewart-Haas Racing.
The loss of Patrick and her extraordinary name recognition to NASCAR would be a major blow to the IndyCar series.
As for this year's Motegi round, the teams and cars will get on the track for the first time for the 200-lap, 300-mile race on Friday morning. "I hope the cars will come off the truck fast (Friday) and we'll just maintain that," said Patrick.
She won last year by saving fuel while maintaining a sufficient pace to beat the rapidly closing Helio Castroneves of Penkse Racing. That victory plus this year's consistent points season have gained Patrick a lot of respect within the Indy Racing League.
Beyond her performance and long recognized media drawing power, Patrick is now regarded in the paddock as more focused and less likely to blame other drivers for problems. Patrick is not considered one of the top five drivers whose talent enables her to win in the IRL on any race weekend, but she's seen as a driver who's tough to beat on days when she's running well.
There's no doubt Patrick runs well on the egg-shaped 1.5-mile oval located on a mountain top north of Tokyo. She started on the front row her rookie season in April of 2005, led twice for 32 laps and finished fourth. She's finished no worse than 11th in four races.
"I must just know what I want out of the car to be able to do well here," she said. "It's not just simple, straight forward and easy. I think that shows in other places that I do well like short ovals and Indy and places like that. It's important in these places to be in a car that you're comfortable in."
The trip through turns 3 and 4 is faster due to a longer radius than the tighter Turns 1 and 2. "Around a place like this 3 and 4 is the only spot that matters here," she said. "One and two are the easy ones. You pace yourself in 3 and 4 to get up to flat out."
Though short-winded on the subject of next season, Patrick politely repeats her answer to the eternal question about winning on fuel mileage rather than flat-out pace last year.
"Any race you go to you have to be running well to win the race," she said. "There's been a lot of people who've won a race on strategy," she continued. "I've put myself in position in a lot of places to win on strategy and I've lost it. Everybody wants their win to be dramatic, you know a pass for the lead or lapping second place."
– Jonathan Ingram can be reached at firstname.lastname@example.com Comments


text:
When getting your fitness on, the last thing you want is a boring routine. Spice up your workout with these beautiful ballet fitness exercises that anyone can do! You don't need a ballet barre or mirrors for this workout, just put on your favorite athletic wear and start toning. These exercises are fun, quick, and don't take up much space. Incorporate all 15 into your daily routine and you will have a gorgeous ballerina figure in no time. Long legs and fit booty… here you come!
Pretty pliés
Plié is a French word, literally meaning 'to bend'. Start with your feet together and open your toes so that only your heels are touching. If you are a beginning or have never engaged your 'turn out' muscles before, stick to a smaller V with the feet. Make sure your body is upright and your knees are squeezed together. Bend your knees slowly, counting to two, then straighten. Repeat this exercise eight times, then rest.


text:
If you're seeking advice on treating insomnia, know that there are millions of men and women who share your concerns. Countless folks are currently combating insomnia, and many have come across useful tips. This article has advice from those in the know which can help you sleep again.
Staying up late is enjoyable for some. Anyone who has insomnia just can't do this. Get an alarm that wakes you up the same time every day. After a few weeks, this should become a habit, and you will be able to form a sleep routine.
Sleep long enough to get your rest. Do not try to catch up on lost sleep by sleeping longer as it does not work this way. Sleep until you feel rested every night. It is not useful to save up sleep hours or take them away from other days.
If you have already done all you know how to do to fight insomnia and it's not working, then you might want to consider getting your doctor to prescribe something. Talk to your physician to get some advice on which product may be right for you.
Avoid eating or drinking before going to bed. Liquids can wake you so you have to go to the bathroom, and eating stimulates your digestive system and keeps you up. Be sure to have your bedtime snack at least a couple of hours before bedtime. If you have a lot of nightmares, make it three hours, instead.
If you have had insomnia for many nights, think about heading to the doctor. Insomnia can be temporary, but at times there is another health issue involved. See your doctor and alert him to what has been happening so he can rule out a serious issue.
Be sure the bedroom is noise-free and dark. Ambient artificial light may prevent you from getting proper sleep. Control whatever noise in the area that you can. For the things you can't change, try using a white noise machine.
Many people that try to sleep have racing thoughts. This can prevent them from getting restful sleep. A distracted mind will keep you up at night. Ambient noises such as waves and rain help many people relax and fall asleep.
If your mattress is too soft, buy a new one. A firm mattress supports the body and allow it to relax. In addition, your whole body will feel better when it wakes up after sleeping on a supportive surface. Mattresses are expensive, but it is a good investment.
Don't let worrisome thoughts steal your sleep. A fine idea to handle insomnia is setting a time to worry earlier on in the day. Many people get restless with a mindful of thoughts of the day and are unable to fall asleep. Allocate a portion of your day to going over anything that is on your mind. Then, you won't feel tempted to solve problems during time you should be devoting to sleep.
Looking for tricks and tips from people who have had insomnia is a great way to get some help. Hopefully, you can use this article to get the rest you need. Make the changes necessary so that you can sleep well tonight and every night thereafter.