StyleCopAid

June 11th, 2015

StyleCopAid is a Visual Studio extension that helps to automatically fix code formatting warnings identified by the StyleCop tool.

Benefits

  • - Automatically fix over 40 different StyleCop violations, including some the most labor-intensive ordering and documentation ones
  • - Automatically suppress rules that otherwise require code refactoring
  • - As a safety feature, undo the last change when making fixes


Donate to support tool development

While free for general use, donations of any size are welcomed and greatly appreciated.



Installation

The tool is hosted by the Microsoft Visual Studio Gallery. Use Visual Studio Extension Manager’s search to locate and install the StyleCopAid.

Usage Guide

Analyze your code using the StyleCop tool. Select a rule violation that you want to fix or suppress and use the right-click contextual menu to pick appropriate action. Verify that the change is acceptable. Use the Undo feature as needed.

Fixing/suppressing of multiple warnings is supported but we recommend you do them in smaller chunks before you familiarize yourself with the tool.

Supported Visual Studio versions

The tool supports Visual Studio 2010, 2012, and 2013 versions.

Supported Rules

Fix automatically

Spacing Rules

SA1001: CommasMustBeSpacedCorrectly
SA1003: SymbolsMustBeSpacedCorrectly
SA1005: SingleLineCommentsMustBeginWithSingeSpace
SA1012: OpeningCurlyBracketsMustBeSpacedCorrectly
SA1013: ClosingCurlyBracketsMustBeSpacedCorrectly
SA1014: OpeningGenericBracketsMustBeSpacedCorrectly
SA1025: CodeMustNotContainMultipleWhitespaceInARow
SA1027: TabsMustNotBeUsed

Readability Rules

SA1101: PrefixLocalCallsWithThis
SA1102: QueryClauseMustFollowPreviousClause
SA1111: ClosingParenthesisMustBeOnLineOfOpeningParenthesis
SA1115: ParameterMustFollowComma
SA1116: SplitParametersMustStartOnLineAfterDeclaration
SA1118: ParameterMustNotSpanMultipleLines
SA1120: CommentsMustContainText
SA1122: UseStringEmptyForEmptyStrings

Ordering Rules

SA1200: UsingDirectivesMustBePlacedWithinNamespace
SA1201: ElementsMustAppearInTheCorrectOrder
SA1202: ElementsMustBeOrderedByAccess
SA1204: StaticElementsMustAppearBeforeInstanceElements
SA1206: ElementsMustBeOrderedByAccess
SA1208: SystemUsingDirectivesMustBePlacedBeforeOtherUsingDirectives
SA1210: UsingDirectivesMustBeOrderedAlphabeticallyByNamespace
SA1215: InstanceReadonlyElementsMustAppearBeforeInstanceNonReadonlyElements

Maintainability Rules

SA1407: ArithmeticExpressionsMustDeclarePrecedence

Layout Rules

SA1500: CurlyBracketsForMultiLineStatementsMustNotShareLine
SA1501: StatementMustNotBeOnSingleLine
SA1502: ElementMustNotBeOnSingleLine
SA1503: CurlyBracketsMustNotBeOmitted
SA1505: OpeningCurlyBracketsMustNotBeFollowedByBlankLine
SA1507: CodeMustNotContainMultipleBlankLinesInARow
SA1508: ClosingCurlyBracketsMustNotBePrecededByBlankLine
SA1512: SingleLineCommentsMustNotBeFollowedByBlankLine
SA1513: ClosingCurlyBracketMustBeFollowedByBlankLine
SA1514: ElementDocumentationHeaderMustBePrecededByBlankLine
SA1515: SingleLineCommentMustBePrecededByBlankLine
SA1516: ElementsMustBeSeparatedByBlankLine
SA1517: CodeMustNotContainBlankLinesAtStartOfFile
SA1518: CodeMustNotContainBlankLinesAtEndOfFile

Documentation Rules

SA1600: ElementsMustBeDocumented
SA1615: ElementReturnValueMustBeDocumented
SA1622: GenericTypeParameterDocumentationMustHaveText
SA1626: SingleLineCommentsMustNotUseDocumentationStyleSlashes
SA1627: DocumentationTextMustNotBeEmpty
SA1633: FileMustHaveHeader

Suppress automatically

Naming Rules

SA1300: ElementMustBeginWithUpperCaseLetter
SA1304: NonPrivateReadonlyFieldsMustBeginWithUpperCaseLetter
SA1306: FieldNamesMustBeginWithLowerCaseLetter
SA1307: AccessibleFieldsMustBeginWithUpperCaseLetter
SA1309: FieldNamesMustNotBeginWithUnderscore
SA1310: FieldNamesMustNotContainUnderscore
SA1311: StaticReadonlyFieldsMustBeginWithUpperCaseLetter

Maintainability Rules

SA1400: AccessModifierMustBeDeclared
SA1401: FieldsMustBePrivate
SA1407: ArithmeticExpressionsMustDeclarePrecedence
SA1409: RemoveUnnecessaryCode

Layout Rules

SA1500: CurlyBracketsForMultiLineStatementsMustNotShareLine

Documentation Rules

SA1644: DocumentationHeadersMustNotContainBlankLines
SA1650: ElementDocumentationMustBeSpelledCorrectly

Contact Us

Please direct all you questions and comments to support@mroodles.com

Version History

v2.11.12: releasing the app for free
v2.11.11: implemented SA1407: ArithmeticExpressionsMustDeclarePrecedence
v2.10.11: suppression for SA1407: ArithmeticExpressionsMustDeclarePrecedence
v2.9.11: implemented: SA1615: ElementReturnValueMustBeDocumented, suppressions: SA1400, SA1650
v2.8.11: implemented – SA1600: ElementsMustBeDocumented
v2.7.11: implemented SA1206: ElementsMustBeOrderedByAccess
v2.6.11: fix for SA1115
v2.6.10: implemented SA1120: CommentsMustContainText
v2.5.10: implemented SA1025: CodeMustNotContainMultipleWhitespaceInARow
v2.4.10: fix for closed document changes; fix for SA1101
v2.4.9: implemented SA1101: PrefixLocalCallsWithThis
v2.3.9: implemented SA1633: FileMustHaveHeader; added templates
v2.2.9: rules SA1517: CodeMustNotContainBlankLinesAtStartOfFile, SA1518: CodeMustNotContainBlankLinesAtEndOfFile implemented
v2.1.9: only one ordering rule can be executed; execution ceases when one such rule is executed
v2.1.8: delete Undo temp folder on initialization
v2.1.7: rule SA1122: UseStringEmptyForEmptyStrings implementation
v2.1.6: fix for the 1027 rule (no tabs)
v2.1.5: rules SA1501 and SA1502 implemented
v2.1.4: fix for Undo with read-only files
v2.1.3: RELEASED (June 11, 2015)

Robocall filtering application demo

March 15th, 2014

Over a year ago I prepared a robocall filtering application to participate in one of online competitions. Requirements were: filter out illegal robocalls (e.g., unsolicited advertisement), allow legal ones (e.g., prescription notifications, reverse 9-1-1 calls), and allow real person calls,- here is a demo of the final prototype.

To watch 2014 Olympics online without cable subscription in USA

February 11th, 2014

If you don’t have cable but still want to stream Olympics – you can use VPN Gate (free public peer-to-peer VPN service):

1. Homepage: http://www.vpngate.net/

2. Download and install SoftEther VPN client by following instructions here: http://www.vpngate.net/en/howto_softether.aspx

3. Start the client, pick a Relay service.

Here you have some options: Canada for CBC or UK for BBC webcasts. I like CBC: http://olympics.cbc.ca/ as they offer on-demand replay for events of a day.

D-License soccer coaching license grade

April 26th, 2013

D-License grade and materials: soccer-coaching-d-license.pdf

MSMQ intermittent remote computer is not available exception

March 31st, 2011

Did some poking around MSMQ – and ran into various intermittent exceptions when writing/reading from private remote queues (“remote computer is not available”, “queue cannot be found/accessed”, etc.)

At the root there happened to be the fact that MessageQueue object is disposable/closable. So – add queue.Close() (or queue.Dispose(), or do “using” on your queue) code, restart MSMQ services, and there is a chance that your problem will go away.

Also, follow recomendations you’ll find from all the other searches (e.g., try non-cached queue handles, verify read/write permissions of your queues, etc.)

Django, Apache, and 500 Server Error

November 27th, 2010

Started experiments with Django framework – mostly straightforward.

To troubleshoot when deploying in Apache (I have Ubuntu – beware of specifics) – tailing error.log file for 500 server errors is useful. Logs are located in /var/logs/apache2

One last challenge that I recall was serving of static files (CSS stylesheets in my case – the ones that come by default with admin interface). To achieve – add the following line to your VirtualHost entry in apache config above WSGIScriptAlias line (adjust path for your location)


Alias /media/ /home/www-data/bin/django/django/contrib/admin/media/

Enjoy :-D

I will survive

October 9th, 2010

Great Mistakes in Technical Leadership – reprint

May 30th, 2010

Great Mistakes in Technical
Leadership
11 Jun 2006

Originally:
Hacknot – Great Mistakes in Technical Leadership

http://www.hacknot.info/hacknot/action/showEntry?eid=87

but that site is now gone. I found this text in Google cache and took liberty of posting it here.

“ If you are a good leader who talks little, they will
say when your work is done and your aim fulfilled,
“We did it ourselves.””
Lao-Tse, cited in 1

Perhaps the most difficult job to do on any software
development project is that of Technical Lead. The
Technical Lead has overall responsibility for all technical
aspects of the project – design, code, technology
selection, work assignment, scheduling and architecture
are all within his purview. Positioned right at the border
of the technical and managerial, they are the proverbial
“meat in the sandwich.” This means that they have to be
able to speak two languages – the high-level language of
the project manager to whom they report, and the
low-level technical language of their team. In effect,
they’re the translator between the two dialects.
Observation suggests that there are not that many senior
techies who have the skills and personal characteristics
necessary to perform the Technical Lead role well. Of
those I have seen attempt it, perhaps ten percent did a
good job of it, twenty percent just got by, and the
remaining seventy percent screwed it up. Therefore most
of what I have learnt about being a good Technical Lead
has been learnt by counter-example. Each time I see a
Technical Lead doing something stupid, I make a mental
note to avoid that same behavior or action when I am
next in the Technical Lead role.
What follows is the abridged version of the list of
mistakes I have assembled in this manner over the last
thirteen years of watching Technical Leads get it wrong.

It is my contention that if you can just avoid making
these mistakes, you are well on your way to doing a good
job as a Technical Lead. You might consider it a
long-form equivalent of the Hippocratic Oath “First do
no harm,” although given the self-evident nature of
many of these exhortations, it is more like “First do
nothing stupid.”

Mistake #0: Assuming the team serves you
Perhaps the most damaging mistake a Technical Lead
can make is to assume that their seniority somehow
gives them an elevated status in their organization. Once
their ego gets involved, the door is open to a host of
concomitant miseries such as emotional decision
making, defensiveness and intra-team conflict.
I can’t emphasize enough how important it is to realize
that although the Technical Lead role brings with it
many additional responsibilities, it does not put you
“above” the other team members in any meaningful
sense. Rather, you are on an exactly equal footing with
them. It’s just that your duties are slightly different from
theirs.
If anything, it is you that is in service of them, given that
it is part of your role to facilitate their work. To put it
another way, you are there to make them look good, not
the other way around.

Mistake #1: Isolating yourself from the team
In some organizations, having the title of Technical Lead
gives you entitlements that the rank and file of your team
do not enjoy. Sometimes, the title is considered
sufficiently senior to entitle you to an office of your own,
or at least a larger workspace if you must still dwell in
cubicle land.
It is a mistake to take or accept such perquisites, as they
serve to distance you (both physically and
organizationally) from the people that you work most
closely with. As military leaders know, it creates an
artificial and ultimately unhealthy class distinction
between soldiers and officers if the latter are afforded
special privileges. To truly understand your team’s
problems and be considered just “one of the guys”
(which you are), you need to be in the same
circumstances as they are.

Mistake #2: Employing hokey motivation
techniques

Different sorts of people are motivated by different sorts
of rewards. Programmers and managers certainly have
very different natures, yet it is surprising the number of
managers and aspiring managers who ignore those
differences and try to reward technical staff in the same
way they would like to be rewarded themselves.
For example, managers value perception and status, so
being presented with an award in front of everyone, or
receiving a plaque to display on their wall where
everyone can see it, may well be motivating to them.
However programmers tend to be focused on the
practical and functional, and value things that they can
use to some advantage. Programmers regard the sorts of
rewards that managers typically receive as superficial
and trite. They have a similar view of “team building”
activities, motivational speeches and posters and the
like.
So if you want to motivate a developer, don’t start
cheering “Yay team” or force him to wear the team t-shirt
you just had printed. Instead, give him something of use.
A second monitor for his computer will be well received,
as will some extra RAM, a faster CPU, cooler peripherals,
or a more comfortable office chair. It’s also hard to go
wrong with cash or time off.
Developers are also constantly mindful of keeping their
skill sets up to date, and so will value any contribution
you can make to their technical education. Give them
some time during work hours to pursue their own
projects or explore new technologies, a substantial
voucher from your local technical book store, or leave to
attend a training course that interests them – it doesn’t
have to be something that bears direct relationship to
company work, just as long as it has career value to
them.
Mistake #3: Not providing technical
direction and context

A common mode of failure amongst Technical Leads is
to focus on their love of the “technical” and forget about
their obligation to “lead.” Leading means thinking ahead
enough that you can make informed and well-considered
decisions before the need for that decision becomes an

impediment to team progress.
The most obvious form of such leadership is the
specification of the software’s overall architecture.
Before implementation begins, you should have already
considered the architectural alternatives available, and
have chosen one of them for objective and rationally
defensible reasons. You should also have communicated
this architecture to the team, so that they can always
place the units of work they do in a broader architectural
context. This gives their work a direction and promotes
confidence that the teams collective efforts will bind
together into a successful whole.
A Technical Lead lacking in self-confidence can be a
major frustration to their team. They may find
themselves waiting on the Lead to make decisions that
significantly effect their work, but find that there is some
reticence or unwillingness to make a firm decision.
Particularly when new in the role, some Technical Leads
find it difficult to make decisions in a timely manner, for
they are paralyzed by the fear of making that decision
incorrectly. Troubled that a bad decision will make them
look foolish, they vacillate endlessly between the
alternatives, while their team mates are standing by
wondering when they are going to be able to move
forward. In such cases, one does well to remember that a
good enough decision now is often better than a perfect
decision later. Sometimes there is no choice amongst
technical alternatives that jumps out at you as being
clearly better than any other – there are merely different
possibilities, each with pros and cons. Don’t belabor such
decisions indefinitely. In particular, don’t hand over such
decisions to the team and hope to arrive at some
consensus. Such consensus is often impossible to obtain.
What is most important is that you make a timely
decision that you feel moderately confident in, and then
commit to it. If all else fails, look to those industry
figures whose opinions you trust, and follow the advice
they have to give.
Finally, always be prepared to admit that a decision
you’ve made was incorrect, if information to that effect
should come to light. Some of the nastiest technical
disasters I’ve witnessed have originated with a senior
techie with an ego investment in a particular decision,
who lacks the integrity necessary to admit error, even
when their mistake is obvious to all.

Mistake #4: Fulfilling your own needs via
the team

You will occasionally hear people opine that one should
not let the personal interfere with the professional. In
other words, difficulties at home should not interfere
with the execution of duties in the workplace. In some
environments, the obvious expression of emotion is
simply taboo. But such ideas don’t mesh with reality too
well. People are holistic creatures and our life experience
is not so conveniently compartmentalized, no matter
how desirable some Taylorist ideal may be.
Just the same, there are practical and social limitations
upon workplace behavior which some may be tempted to
flaunt, to the discomfort and embarrassment of their
colleagues. The broader one’s influence, the greater the
opportunity to co-opt activities that should be focused on
work, and turn them to personal effect.
For example, meetings (complete with buffet) make a
fine social occasion for those not concerned with making
best use of company time. Team-building exercises
provide an easily excused opportunity to get away from
the office and out into the sun, as do off-site training
courses and conferences.
Pair programming seems to be most appealing to those
who like to chat about their work … continually. An
excessive focus on group consensus-based
decision-making for all technical aspects of the project,
even the trivial ones, may be a sign that a Technical Lead
is more concerned with the sociology of the project and
their place amongst it, than with leadership and making
efficient use of people’s time and effort.

Mistake #5: Focusing on your individual
contribution

Changing roles from developer to Technical Lead
requires a certain adjustment in mindset. As a developer
you tend to be focused upon individual achievement.
You spend your time laboring on units of work, mainly
by yourself, and can later point to these discrete pieces of
the application and say, with some satisfaction, “I did
that.”
But as a Technical Lead your focus shifts from individual
achievement to group achievement. Your work is now to

facilitate the work of others. This means that when
others come to you for help, you should be in the habit of
dropping everything and servicing their requests
immediately. A fatal mistake some Technical Leads make
is to try and retain their former role as an individual
contributor, which tends to result in the Technical Lead
duties suffering, as they become engrossed in their own
problems and push the concerns of others aside.
The constant alternation between helping individuals
with low-level technical problems and thinking about
high-level project-wide issues is very cognitively
demanding. I’ve come to call the problem “zoom fatigue”
- the mental fatigue which results from rapidly changing
between the precise and the abstract on a regular basis.
It’s like the physical fatigue that the eye experiences
when constantly switching focus from long distance to
short distance. The muscular effort required within the
eye to change focal length eventually leads to fatigue,
making the eye less responsive to subsequent demands.
Similarly, you get cognitive fatigue when in one moment
you are helping someone with an intricate coding issue,
and in the next you’re examining the interaction between
subsystems at the architectural level. The latter requires
a more abstract mental state than the former, and
alternating between the two is quite taxing.
As a result, people may come to you seeking help with
something that has been the sole focus of their attention
for several hours or days, and you will find it difficult to
“task switch” from what you were just doing into a
mindset where you can discuss the problem with them
on equal terms. I find it helpful to just ask the person to
give me ten minutes to get my head into the problem
space, during which I might retreat to my own machine
and study the problem body of code in detail, before
attempting to help them with it.

Mistake #6: Trying to be technically
omniscient


Just because you have the last word in technical
decisions, don’t think that it is somehow assumed that
you are the programming equivalent of Yoda. With the
variety and complexity of development technologies
always growing, it is increasingly difficult to maintain a
mastery of any given subset of that domain. As in most
growing fields, those who call themselves “expert” will
progressively know more and more about less and less.

It is therefore entirely possible that you will be learning
new technologies at the same time as you are first
applying them. The mistakes you make and the gaps in
your knowledge will be abundantly obvious to your team
members, so it is best to abandon at the outset any
pretext of having it all figured out.
Be open and honest about what you do and don’t know.
Don’t try and overstate or otherwise misrepresent the
extent and nature of your familiarity with a technology,
for once you are found out, the trust lost will be very
difficult to regain.
There is an opportunity here to widen the knowledge and
experience of all team members. You might like to
appoint certain people as specialists in particular
technologies, giving them the time and task assignments
necessary to develop a superior knowledge of their
assigned area. To avoid boredom and unnecessary risk,
be sure to give these resident experts plenty of
opportunity to spread their knowledge around the team,
and to exchange specialties with others.
Adopting this “collection of specialists” approach makes
it clear that you are not presuming to be all things to all
people; and that you have faith in the abilities of your
colleagues. But it will require you to park your ego at the
door and be prepared to say “I don’t know” quite
frequently.
But be careful not to lean on others too heavily. It is still
vitally important for you to have a good overarching
knowledge of the technologies you are employing,
particularly those elements of them that are critical to
their successful interoperation in service of your systems
architecture.

Mistake #7: Failing to delegate effectively
To successfully lead a group, there must be an attitude of
implicit trust and assumed good intent between the
leader and those being lead. Therefore a Technical Lead
must be willing to trust his team to be diligent in the
pursuit of their goals, without feeling the need to watch
over their shoulder and constantly monitor their
progress. This sort of micromanagement is particularly
loathed by programmers, who recognize it as a tacit
questioning of their abilities and commitment.
But ineffective delegation can also arise for selfish

reasons. Several times now I’ve seen Technical Leads
who like to save all the “fun” work for themselves,
leaving others the tedious grunt work. For example, the
Technical Lead will assign themselves the task of
evaluating new technologies, constructing exploratory
and “proof of concept” prototypes, but once play time is
over and the need for disciplined work arrives, hand over
the detailed tasks to others.
Not only is effective delegation desirable with respect to
team morale and project risk, on large projects it is
simply a necessity, as there will be too much information
to be managed and maintained at once for one person to
be able to cope.

Mistake #8: Being ignorant of your own
shortcomings

Some people simply don’t have the natural proclivities
necessary to be good Technical Leads. It’s not enough to
have good technical knowledge. You must be able to
communicate that knowledge to others, as well as
translate it into a simpler form that your management
can understand.
You also need good organizational skills. Coordinating
the efforts of multiple people to produce a functionally
consistent outcome is not easy, and demands a
methodical and detail-oriented approach to planning
and scheduling. If you can’t plan ahead successfully, you
will find yourself constantly in reactive mode, which is
both stressful and inefficient.
If you don’t have these qualities naturally, you may be
able to develop them to some extent, through training
and deliberate effort. But it may ultimately be necessary
for you to lean on others in your team to support you,
should they have strengths in areas in which you have
weaknesses.

Mistake #9: Failing to represent the best
interests of your team

Perhaps the most nauseating mistake a Technical Lead
can make is to become a puppet of the management
above them. As the interface between management and
technicians, it is the Technical Lead’s role to go into bat
with their management to represent the best interests of
their team. This means standing up to the imposition of
unreasonable deadlines, fighting for decent tools and

resources, and preventing the prevarications of
management from disturbing the rhythm of the project.
A weak-willed or easily manipulated Technical Lead will
incur the disrespect of his team.
Unfortunately, such spineless behavior is quite common
amongst the ranks of the ambitious, and you don’t have
to look far to find obsequious Technical Leads who will
gladly promise the impossible and impose hardship on
their team, in the interests of creating a “can do” image
for themselves.
Mistake #10: Failing to anticipate


An essential part of the Technical Lead’s role is keeping
an eye on the “big picture” – the system-wide concerns
that are easily forgotten by programmers whose
attention is consumed by the coding problem they
currently face.
These “big picture” issues include those non-functional
requirements sometimes called “-ilities” -
maintainability, reliability, usability, testability and so
on. If you don’t make a conscious effort to track your
progress against these requirements, there is a high
probability of them slipping through the cracks and
being forgotten about until they later emerge as crises.
If you don’t have a dedicated project manager, it may
also fall to you to handle the scheduling, tracking and
assignment of tasks. It isn’t uncommon for Technical
Leads to find themselves playing dual roles in this
manner. You may not be very fond of such
“administrative” duties, but their efficient performance
is critical to the smooth running of the project, and for
the developers to know where they are and where they’re
going. Don’t make the mistake of ignoring or devaluing
these tasks simply because they are non-technical in
nature.
Mistake #11: Repeat mistakes others have
already made

It is common for developers to dismiss the experience
reports of others as having no relevance to their own
situation. Indeed, it is wise to approach all anecdotal
evidence with skepticism. But it is unwise to completely
disregard the advice of others, particularly when it is
accompanied by sound reasoning, or can be
independently verified. Ignoring good advice can be very

expensive; it is said that “Experience keeps a dear school
but fools will learn in no other.”
The unwillingness of developers to learn from the
mistakes of others, and the ease with which you can
encounter software project horror stories in the
literature and recognize your own projects in them, is
evidence suggesting that the software industry as a
whole is not getting any wiser.2 You need not contribute
to that collective stupidity.

Mistake #12: Using the project to pursue
your own technical interests

Remarkably, developers can reach quite senior levels in
their organization without having learnt to appreciate
the difference between work and play. Many are
attracted to programming to begin with because, as
hobbyists, they enjoyed fooling around with the latest
and greatest technologies. Somehow they carry this
tendency to “play” with technologies into their working
lives, and it becomes the aspect of their jobs that they
value most. From their perspective, the purpose of a
development effort is not to create something of value to
the business, but to create an opportunity to experiment
with new technologies and pad their CV with some new
acronyms.
Their technology selection is based upon whatever looks
“cool”. But a rational approach to technology selection
may yield quite a different result to one guided by
technical enthusiasm or a fascination with novelty. New
technologies are often riskier choices, as the
development community has not had much time to apply
the technology in varying circumstances and thereby
discover its weaknesses and shortcomings. Putting an
immature technology on a project’s critical path is
especially risky. So an older, tried and true technology
may be a more rational choice than a new, unproven one.

Mistake #13: Not maintaining technical
involvement

In order to fully appreciate the current status of the
project as well as the difficulties your team is facing, it is
vital that you maintain a coding-level involvement in the
project. If you’re not cutting code, it is too easy to
become divorced from the effects of your own decision
making, and to be seen by other developers as being out
of touch with the technical realities of the project.

Mistake #14: Playing the game rather than
focusing on the target


In some organizations, being a Technical Lead is a
politically sensitive position. Technology choices, work
assignments and project outcomes are all just tools to be
used in the pursuit of personal agendas. To some, this
“game” of political influence is both fascinating and
addictive. They play it in the hope of gaining some
advantage for themselves, and do so to the detriment of
the project and the individuals upon it. When they don’t
have their eye on the ball like this, devoting more energy
to Machiavellian maneuverings than to the technical
difficulties of the project, then the project inevitably
suffers.

Mistake #15: Avoiding conflict

Many people find interpersonal conflict distasteful.
Some dislike it so much that they will do practically
anything to avoid it, including giving up in technical
disputes. Such people are prone to being walked over by
those more aggressive and forthright.
This is bad enough for the individual, but worse if that
person is meant to be representing the best interests of a
team. A meek Technical Lead can be a real liability to a
development team, who will find themselves buffeted
about by external forces that they should have been
shielded from, and burdened by demands and goals that
are not informed by the project’s reality.
With such a disposition, a Technical Lead may be unable
to even deal effectively with unruly behavior or
inadequate performance from members of their own
team.

Mistake #16: Putting the project before the
people

It’s one thing to be focused on the project’s goals, but
quite another to adopt a “succeed at all costs” attitude.
Ambitious Technical Leads, concerned with the image
they project to their management, sometimes accept
impossible goals or unreasonable demands, because they
lack the courage or integrity to say “no.” These goals then
become the development team’s burden to shoulder,
leading to increased stress, higher defect injection rates,
longer working hours and lower morale. There is a
tendency to be so focused on the end goal that the effects

of the project on the developers gets overlooked. It is not
uncommon for successful delivery on a high pressure
project to be followed by the resignations of several
disgruntled team members, making the project’s
triumph a pyrrhic victory indeed.
Given the costs of hiring and training staff, treating
developers as expendable resources makes no financial
sense, quite aside from the ethical implications of such
treatment. A wise Technical Lead will know that putting
the well-being of the developers first also produces the
best results for the project and the business. Project
success should leave the participants satisfied with their
achievement, not burnt out and demoralized.
Mistake #17: Expecting everyone to think
and act like you

Being a Technical Lead may be the first time you are
exposed so frequently and directly to the problem
solving styles and low-level work habits of others.
Programming is traditionally an individual activity.
Programmers are often able to face the technical
difficulties of their work in isolation, emerging sometime
later with the completed solution. But as a Technical
Lead you will frequently be called on to help those who
are stuck part way through the problem-solving process,
unable to proceed. Seeing a solution that is “under
construction” might be a bit of a shock to you at first, as
you may find your colleagues approach to problem
solving dramatically different to your own. Some people
work “outside in”, others “inside out”, others jump all
over the place, some work quickly with lots of trial and
error, others slowly and methodically. It is tempting to
stand in judgment of approaches and methods that don’t
gel for you, pronouncing them somehow inferior. Avoid
the temptation. Learn to accept the varieties of cognitive
styles on your team, and recognize that this cognitive
diversity may actually be an asset, for the variety of
perspective it brings.
Mistake #18: Failing to demonstrate
compassion

Although I’ve put this last, it is in some ways the most
important of all the mistakes listed here. Always
remember that your team members are people first and
programmers second. You can expect them to be
temperamental, inconsistent, proud, undisciplined and

cynical – perhaps all in the same day. Which is to say
they are flawed and imperfect, just like you and everyone
else. So cut them some slack. Everyone has good and bad
days, strengths and weaknesses; so tolerance is the order
of the day.
If someone breaks the build, it’s no big deal. If a
regression is introduced, learn something by finding out
how it got there, but don’t get upset over it or attempt to
assign blame. If a deadline is missed, stand back from
the immediate situation and appreciate that in the grand
scheme of things, it really doesn’t matter. Mistakes
happen and you should expect your colleagues to make
many, as you will surely make many yourself.

References
1. Becoming A Technical Leader – G. M. Weinberg,
Dorset House, 1986
2. Facts And Fallacies of Software Engineering -
Robert L. Glass, Addison-Wesley, 2003

Soccer coaching philosophy and practice organization

May 12th, 2010

Hi Everybody,

After talking with one of our player’s parents tonight it seems that a brief message on our practice organization and coaching philosophy would be helpful.

This message is not going to be brief – it’s going to be very long, so if you do not have time or do not care – please feel free to stop reading right now :-)

—–

Some background. I came from Ukraine: we moved with my family to the United States in 1996. As far as I can remember (and that means about three years old), I played soccer. it’s fact of life in those countries: you go on a street – you play. That’s one of the reasons why the “street soccer” coaching model works for me.

This model was first formalized and applied in Netherlands in 1970s and is the single biggest reason why this country with population less than the state of New York consistently performs exceptionally well in international competitions. Since then, this system became recognized and widely adopted throughout the world and is currently officially recommended by the United States Soccer Federation and United States Youth Soccer Association for utilization at all levels.

My coaching resume includes E-level coaching license (total of 28 hours of courses) and over ten seasons of coaching in youth soccer (including seasons when I had two teams at once that’s over 150 kids). For my E-license, I had luck and privilege to have former training director of the national US Youth Soccer Association as an instructor.

Throughout all the classes, “street soccer” approach is emphasized for its simplicity and efficiency. The main idea is that soccer is a self-learning game: if you put kids into situation when they have to play soccer they will have no choice but learn key principles even without realizing that they are learning. Soccer presents concrete problems – infinite set of concrete problems – and players need to solve them all the time. They need to learn to recognize established patterns (e.g., two attackers running against a single defender) as well as adjust and improvise in surprising situations (e.g., being a single defender against five attackers).

Key principles of the game are: technique, decision making, communication, and endurance. In conventional approach – when you predominantly do drills in a practice, – you can only target and improve one of these areas at a time, sometimes two. With only two 90-minute practices per week improvement rate for all four areas is fairly low. With the “street soccer” approach – when you do specialized scrimmages – players simultaneously exercise all four principles at the same time, which usually means that improvement rate is approximately three-four times higher when compared to conventional methodology.

“To play soccer” means to have all main characteristics of the game: have competition between two teams governed by basic soccer rules, have one ball, have boundaries, have defined directions and rules for scoring. By using such activities you can build a practice.

At the basis of each practice is a single purpose – or a subject. This makes each practice effective through targeted specialization. Subject examples are: first defender (“pressure”), first attacker, second defender (“cover”), second attacker (“support”), third defender, third attacker (that’s it: there are just three of each :-) ), short passing, long passing, shooting, basic team shape, two players combining, handling crosses, role of wing midfielders, just to name a few.

Starting with U10 level, usual practice consists of a dynamic warm-up and four activities. Warm-up is something to get players going. Activities are built by the principle “from simple to difficult” as follows: 1st activity (~10-20 mins): no-pressure exercise; 2 (~20 mins): limited pressure small-sided game, 3 (~20-30 mins): full pressure small-sided game, 4 (~30 minutes): single scrimmage with highest numbers of players per team possible (e.g., 6v6 for a team of 12, or 8v8 if we can scrimmage with another team).

All activities including warm-up are targeting the practice’s subject. Such, if the subject is “second attacker” (or “attacking in twos”, or “short passing”) then I usually start with “free-for-all in twos” on a single goal (players are paired together, each team of two is playing against everybody else. everybody is scoring on the same goal). The first “official” activity is “no pressure”. As an example – for passing practice – I like to make boys run around the field aimlessly in pairs and pass on a whistle to each other. “Limited pressure” during the second activity is achieved by creating lopsided numbers: for example a team of five playing against a team of two; the “five” can score by completing seven passes in a row without turning the ball over, the “two” can score in cone goals. Or – you can add “neutral players” such that they are always on offense; this way for example you always have four attackers going against two defenders in a game with six players, etc. The third activity is a scrimmage of equally numbered teams with small number of players on each team (four vs. four is ideal), with or without modified rules (e.g., instead of a single goal each team may have to defend two goals, etc.).

This is practice organization. Now – a little on how coaching happens in this approach.

First – instructional session, or “improvised lecture”. Happens between warm-up and the first activity, and for this age group it should last (ideally – I can never make it happen :-) ) under five minutes. This is when you discuss with players subject of the practice and demonstrate any techniques or situations if necessary. This is however information only, main body of coaching happens during second and third activities, and it happens through means of providing feedback.

During each practice, feedback should be provided strictly on the subject: there should be no points on defending given when practice’s subject is passing, etc. Feedback is classified by its degree of intrusion into the activity: from least intrusive to the most intrusive. Such, you can just talk to a player one on one and ask him why he performed one or another action, or – you can talk to him one on one and tell him why one action could be better than another, or – you can yell some feedback without stopping the game flow, or – you can stop the play and make players freeze and discuss concrete game situation, what happened, and what could have happened.

While observing game play, you need to concentrate on a single team: it’s easier to watch four players instead of eight. As result, you will be providing feedback to one team with the hope that the other one picks up your points.

Feedback should not interrupt game flow too much: during the second activity (“limited pressure”), you should wait about five-seven minutes into the game to let players get the feeling for the rules and objectives. During the third activity (“small-sided game with full pressure”), there should be no more than two-three “stop-freeze” interruptions during entire game.

There is no coaching during the final scrimmage, just observations (and having warm feeling from noticing players executing the points that they learned in previous activities :-) ).

Couple more words on practice specialization and having just a single subject. I know it may be frustrating to see players not being able to pass properly and shoot and defend and spread out and execute all the points at once – but unfortunately that’s reality :-) Another reality is that you cannot fix everything at once: you need to be patient with kids and address one problem at a time. Some times you can go through all the basics in a season, and other times – you have just three practices halfway through the season because of rain outs and try outs, but that’s something you can’t control. The main premise of going through a single subject at a time still holds :-)

Those of you who made it this far – thank you very much for your patience :-)

Vyach.

На дальней станции сойду…

April 4th, 2010

Автор: муз. В. Шаинский, сл. М. Танич

Hа дальней станции сойду -
Тpава — по пояс,
И хоpошо с былым наедине
Бpодить в полях, ничем, ничем не беспокоясь,
По васильковой cиней тишине.
Бpодить в полях, ничем, ничем не беспокоясь,
По васильковой cиней тишине.

Hа дальней станции сойду -
Запахнет медом,
Живой воды попью у жуpавля!
Тут все мое, и мы, и мы отсюда pодом:
И васильки, и я, и тополя.

Hа дальней станции сойду,
Hеобходимо
С высокой ветки в детство заглянуть…
Ты мне опять позволь, позволь, мой кpай родимый,
Быть посвященным в эту тишину!

Hа дальней станции сойду,
Тpава — по пояс,
Зайду в тpаву, как в моpе босиком!
И без меня обpатный cкоpый-скоpый поезд
Растает где-то в шуме гоpодском.

Post-game thoughts after playing Brasilians in O30 league

March 26th, 2010

Gentlemen,

I’d like to elaborate a little on what I attempted to say during the game. (I had tried to keep my mouth shut – but am too excited right now :-) Please feel free to ignore this post as things may seem totally different in the morning. Besides, I do tend to loose track of word count so messages sometimes come out long and boring).

With that said – here’s some theory.

There are only two distinct styles of play: “playmaking” (AKA “total football” – made famous by Ajax in the seventies), and “counterattacking”:

<quote (last paragraph on the page): http://www.bettersoccermorefun.com/dwtext/coachmen.htm>

The most basic tactical decision is what style the team will adopt, the playmaking or counter attacking style. These styles incorporate different mentalities, they approach the game differently.

<end of quote>

and here are outlines for both styles:

http://www.bettersoccermorefun.com/dwtext/totalsoc.htm
http://www.bettersoccermorefun.com/dwtext/countera.htm

After learning about these styles, the key point to realize is that a team must choose one or the other: nobody is fit enough to apply pressure consistently throughout entire field – you have to pick either opponent’s half (playmaking style) or your half (counterattacking one).

Playmaking style is more intuitive (“you hold the ball – you control the game”) and therefore usually most teams try to execute it – either intentionally or without realization. The thing however is that you need to be technically and physically superior compared to your opponent to play this way in a game, otherwise mistakes are punished severely.

To play counterattacking style you need to make conscious decision to do so because it’s counter intuitive: you are seemingly giving up control of the game to the other team. As benefit of this approach however, a team can play fairly efficiently against more technical and physical opponent. You do need to be disciplined to pick your moments to cross to the other half and be mentally tough because constant defending can be mentally draining. Also, the key phrase becomes “relief of pressure” (kick the ball out of your zone if you don’t see a safe pass quickly) vs. “control the ball”.

Another key point with counterattacking style is that you try to have higher number of defenders than opponent’s attackers. This way you have more redundancy built into the system. Also, because the area in front of the goal becomes crowded, it’s harder for attackers to have easy short distance shots. Giving up the middle of the field in this case is justified: you defend less space and therefore spend less effort to do so.

To apply this to our current situation, we could do something like this: three defenders, one midfield, one forward. The defenders hold the fort and do not cross the half line unless absolutely necessary/safe. Defenders actively engage only on own half. Midfielder is defense oriented as well and engages close to the half line on either side (imagine a diamond of the four: midfielder at the top in the center circle, two defenders at the sides, and one deep near own goal). Also, when midfielder is not involved into our attack (see below), he rotates with the defender who is.

For own attack – our forward has to stay fairly deep and be wandering constantly to create some space between him and other team’s defender (usually teams leave one v one in these situations – and it becomes four v four on our half in this case). When one of our players wins the ball and has an option to target the forward in one or two passes (through a connecting player) – he does so. Another player, the one who’s at the top of our defense, has to make a run opposite to the forward to create two v one (attacking teams are usually slow to return). If this player is our midfielder – all is good, everybody is in position. If it’s one of the defenders – midfielder has to take his place on defense. Two v one is plenty enough to create a scoring chance. In the worst case – it’s four v three the other way, which is not that bad (much better for defenders than two v one).

I hope it all makes sense – I can draw this before the next game if anybody cares. And another thing – if you pay attention to how our games go – we already play this way occasionally :-)

And again – this holds true only against superior teams.

Hope I didn’t offend anybody :-) It was a beautiful game – we truly can keep up with these Brazilians, final score doesn’t matter.

Cheers,
Vyach.
http://www.mroodles.com/soccer_junkie/

Заметки об Америке, часть 3

March 6th, 2010

> кстати, если проблемы с мочью, есть специальные средства;)) мочегонные называются

пробовал – не помогают :-(

> так что изредка бери себя в руки и ….

у меня после работы – как в том анекдоте: “- вот Вы, девушка, кем работаете? – официанткой в кафе – ну вот представьте, приходите домой, а там кругом чашки с кофе, и все нужно разнести…” :-)

Футбол – наш (украинский в смысле :-) ). Здесь он развит очень сильно – слухам не верь :-) Не на профессиональном, но на любительском уровне, особенно для детей. Так, в нашем городке из 30 тыс. жителей, в местной футбольной детской организации регистрируется более двух тыс. игроков ежегодно. Организация добровольная: все тренера – из родителей тех же детей. Другое дело, что “местные” виды спорта (амер. футбол, бейсбол, баскетбол и хоккей) здесь развиты еще интенсивнее. Вообще, ребенком здесь быть просто потрясающе: развитие получается очень разностороннее. Когда подрастал Вадька (старший), мы этого есще не обнаружили, и он массу вещей пропустил (сейчас нагоняет). Павлу повезло больше: и пианино, и футбол, и баскетбол, и роботы, и тромбон, и наверняка что-то забыл… У Вади сейчас кроме амер. футбола и бейсбола (это он сам захотел – настырный :-) ) – пение, актерское мастерство, пианино… Уму непостижимо. Часть этих предметов дается в школе, остальное – во внеурочное время. Смотрю на них – завидки берут иногда.

[to be continued below...]

mod_rewrite: Displaying original URL request

March 6th, 2010

There are many comprehensive examples for mod_rewrite usage – you’ll google virtually any topic.

Here’s one that I couldn’t find easily: answer to the query “how to display original url mod_rewrite”. I wanted to have client browser display original address string, not the one of a redirected page.

The answer is rather simple: don’t use [R] flag in your RewriteRule. In other words, instead of

RewriteRule ^hacking/$ wordpress/category/hacking/ [R,L]

use

RewriteRule ^hacking/$ wordpress/category/hacking/ [L]

in your .htaccess.

Infragistics version mismatch and Visual Studio designer screen of death

February 24th, 2010

Work email on VS designer screen of death…
———–

Gentlemen,

I wanted to share this find with you.

I was experiencing multiple designer exceptions when trying to bring various designer views – I think some of you encountered the same at different times. As result of investigation, it happened to be discrepancy of Infragistics versions on my machine: the version I had installed was 9.1.20091.1000 and the version we have in ClearCase is 9.1.20091.2050. I didn’t know how to upgrade properly so I just dragged and dropped the xxx.2050 files from our 3rdparty folder into GAC (c:\WINDOWS\assembly). After cleaning and rebuilding solution I was able to bring all designer views I tried so far – even those, which I thought were long lost.

Hope this helps – I know it bugged me for quite some time :-)

Also, we have discrepancies in various places in our projects – here’s UIP proj example. Please note 9.1.20091.1000 and 8.2.20082.2022 descriptors for the DLLs, which are actually 9.1.20091.2050. It does not seem that this affects the designer view though – but definitely something to keep an eye on.

 

<Reference Include=Infragistics2.Win.UltraWinDataSource.v9.1,
Version=9.1.20091.1000, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb,
processorArchitecture=MSIL
>

<SpecificVersion>False</SpecificVersion>

<HintPath>..\..\..\..\3rdparty\infragistics\WindowsForms\bin\Infragistics2.Win.UltraWinDataSource.v9.1.dll</HintPath>

<Private>False</Private>

</Reference>

<Reference Include=Infragistics2.Win.UltraWinEditors.v9.1,
Version=8.2.20082.2022, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb,
processorArchitecture=MSIL
>

<SpecificVersion>False</SpecificVersion>

<HintPath>..\..\..\..\3rdparty\infragistics\WindowsForms\bin\Infragistics2.Win.UltraWinEditors.v9.1.dll</HintPath>

<Private>False</Private>

</Reference>

Заметки об Америке, часть 2

February 17th, 2010

у нас все потихоньку; сейчас уже жизнь устоялась (в хорошем смысле): дом, работа, детвора, программирование на себя, всевозможные периодические проэкты на интернете; футбол когда только возможно (в сезон доходит до семи дней в неделю: четыре дня – взрослые игры, три дня – тренировки и игры малышни; в межсезонье – до четырех взрослых игр в неделю). Так и живем :-) Как только сюда приехали была напряженка: сначала – официально я был студентом, и изза этого работать было нельзя; подрабатывали и я, и Юля неофициально – это на психику хоть и немного, но давило. Через год устроился официально программистом, но учебу бросить не мог: нужна была для поддержания статуса. Отрабатывал полный рабочий день, а потом – полный учебный день, благо расписание здесь для таких случаев предусмотрено: вечерние классы начинаются с пяти-шести и идут до десяти. Плохо было, что приходилось мотаться из дома на работу, с работы – в университет, из универа – домой. Наезжал до ста миль в день – изза трафика тратилось три-четыре часа только на дорогу. В конце концов, заснул за рулем – въехал с разгону во впереди ползущую фуру :-) Но ничего, обошлось без телесных повреждений, даже машину отремонтировали. Позже стало полегче: работа оформила рабочую визу, и учебу я уже заканчивал part-time (не четыре класса в день минимум, а как получится: один-три). В это же время переехали из самого Бостона в Челмсфорд, поближе к работе. С тех пор ничего особо и не менялось. Как-то так :-)

Заметки об Америке, часть 1

February 14th, 2010

Из ответа Мишке
===========

Занятно :-)

По стране был в Сент-Луисе, Оклахоме (был летом – жара изза высокой влажности непередаваемая: на улицах – никого, как корова языком слизала: все сидят в зданиях с кондиционерами), Сан Хосе, Чикаго. Это все по работе. Сами по себе ездили в тур по Калифорнии (Сан Франциско, Лос Анжелес), Аризоне (Гранд Каньон), и Неваде (Лас Вегас) – забавно получилось, но это было так давно, что уже ничего и не помню. Были в Нью-Йорке пару раз – без ночевок (рано утром выезжали, вечером возвращались: дорога – четыре с половиной часа в одну сторону). Были много раз на Кейп Коде (мыс Трески) – это летом, как в Крым съездить, только ближе: чуть больше двух часов в одну сторону. Там хорошо: Гольфстрим, тепло :-) Еще здесь недалеко Белые Горы (примерно как Карпаты) (штаты Нью-Хемпшир, Мэйн) – туда ездим на вылазки иногда. Вот и все пожалуй. (Раньше не задумывался, казалось, что никуда никогда не езжу, а сейчас пересчитал – был в десяти штатах из пятидесяти; не так уж и плохо :-) )

За пределы штатов не выезжаю: раньше не мог изза отсутствия украинского паспорта (старый истек почти сразу, как сюда приехали, а на новый не подавали: слишком большая заморочка), сейчас – с американским – может, пошлют в Индию как-нибудь. На Украину в этом году поедут Юля с детворой, я останусь здесь. Моя семья почти вся здесь: папа с мамой, две младшие младшие сестры. Старшая младшая сестра (в смысле, младше меня, но старше всех остальных сестер :-) ) осталась в Харькове: когда папа выиграл грин-карту, она уже не проходила по возрасту. Юлины родители сюда приезжали несколько раз.

Если интересно – вот по этому адресу гуглмапс показывает наш дом: 44 parker rd, chelmsford, ma 01824

Вот как-то так :-)

Пару слов вдогонку об упомянутом паспорте, если интересно… Одна из положительных сторон проживания в этой стране – отсутствие какой бы то ни было с нашей точки зрения бюрократии. Паспорт нужен лишь для выезда за границу. Прописки нет – живи, где хочешь. Если где-то нужно указать место жительства – обычно верят на слово. Самой серьезной проверкой считается проверка водительских прав, которые на самом деле являются пластиковой карточкой размером с кредитку.

Права есть практически у всех, начиная с 15-16-летнего возраста, и являются жизненной необходимостью: общественный транспорт есть только в больших городах. В захолустьях, которым является и наш городок (а таких примерно две трети от всех населенных пунктов), передвигаются исключительно на машинах.

Еще – регистрация бизнеса исключительно легкая. Как пример – чтобы легализовать AquariumGarden, я зашел в местный town center (помещение с местными административными структурами), взял заявление на лицензию на открытие бизнеса, заполнил ее, сходил заверил в банк у нотариуса, отнес обратно в town center, заплатил взнос ($25 за пять лет), и все :-) За обеденный перерыв управился.

К такому положению вещей после Украины привыкаешь медленно (“как это – ничего не нужно показывать??”), но потом это уже укореняется прочно: тот факт, что приходится звонить в украинское посольство в течение месяца лишь затем, чтобы узнать, почему до сих пор не пришел паспорт – а мы подавали кучу бумажек на ускоренное продление и его должны были сделать за 2-3 дня – а в конце концов получать ответ, что наш статус не соответствует их записям, и поэтому нужно все переоформлять, – сей факт кажется дикостью. Изза этого, кстати, не поехал в Индию – но как следствие оформили Американское гражданство, так что все к лучшему в итоге :-)

The Secret Life of an American Granola Bar

February 11th, 2010

The Secret Life of an American Granola Bar

By Paul Harmak Vyacheslav Mayorskiy

In the factory, I was born

With a taste, I was given caramel

And small nuts to eat

As I get into a wrapper I feel excited to travel

But wait, I’m being opened

Aaahhh!!! I’m being eaten! What a cruel life,

Eaten where I was born

The factory! Ahh! Goodbye, wor…

Terrified Fish in a Shark’s World

February 11th, 2010

By Paul Mayorskiy

The fish is terrified of its new home so he made a wish
He can’t find any friends or races
A shark swims past, wanting to taste the delicacy of the fish
And the fish frantically searches for a hiding places

He can’t find any friends or races
The fish starts to see another shark
And the fish frantically searches for a hiding places
Luckily he finds a sunken ship for which he can park in the dark

The fish starts to see another shark
He stays parked in the ship
Luckily he finds a sunken ship for which he can park in the dark
But somehow, he was eaten

The fish is terrified of his new home
He stays parked in the ship
A shark swims past, wanting to taste the delicacy of the fish
But somehow, he was eaten

02/10/10 Running a U8 soccer season – general guidelines and advices.

February 10th, 2010

Notes for a co-worker who was volunteered to run a U8 team.

1. Practices one time a week, duration of 60 minutes, 5-6 activities total.

1a. Encourage players to come early by playing games of their choice or letting them do what they want prior to official start of the practice.

2. Activities should progress from simple (no pressure on players: they need to try things without interference first), to limited pressure, to full pressure in a small-sided game (2v2, 3v3), to full scrimmage with the highest number of players per side possible (6v6 for a team of 12)

3. If you want to make a point – form a question. I.e., instead of “dribble fast” say “do you think you should dribble fast or slow?”. This will force your players to think and come up with the (hopefully – obvious) answer. If you say it – they’ll forget, if they say it – there is a good chance they’ll remember.

4. Limit your talk to absolute minimum. At this age – just put a ball at their feet and create conditions for them so that one or another aspect of the game is accentuated. No matter what you say – they will learn faster through trial and error. That’s the beauty of the game, it teaches you without words :-)

5. Limit your talk to absolute minimum. Even when you know what you are talking about (which is fairly rare for parents, who were not exposed to the game before) – keep it to yourself. As an example – “spread out” is a nice tactical concept, but kids at this age have no mental capacity or attention span to grasp it. In fact, the basics of it are usually taught in advanced U12 – normal U14 age group teams: the concept is based on roles and responsibilities of the third attacker. If you don’t know what a third attacker is, or even – who is the second or the first attackers are and what their roles and responsibilities are – don’t say “spread out” to the kids. You can teach them do it without understanding – but doing so bears very little value in a long run: the “bunch ball” style is more productive at this age from development standpoint (lots of resources online, check if you want). As a general rule – no tactical concepts at this age at all: technical concepts (dribbling, short and long passing, and shooting) will fill your season quite nicely and prepare solid basis for their future development as soccer players. Without technics there are no tactics.

6. Limit your talk to absolute minimum. Instead of telling them why they should do one or another thing – modify game conditions to force them do it: make a field smaller for dribbling practice games – and they will be forced to keep the ball close to keep it inbounds, make a goal wider for shooting practices – and they will be more tempted to shoot from longer distances, etc. Don’t be afraid to experiment.

7. When you do talk to the kids – make sure they all stand in front of you: that way, you can see all of them and see if they are paying attention. Couple things to keep in mind: on a sunny day, face the sun yourself, that way if kids are facing you they don’t have to fight sun. If you want to assert authority – stand tall when talking to them. For one to one pep talks, consolations, etc. – kneel down: you’ll be perceived as a peer because of the shorter height and will get to them on a more personal and friendly level.

8. Coach is not a physical ed teacher: there are no tests or homeworks, there should be no lines, laps, or lectures. At this age, coach is an activity leader: all he/she needs to do is prepare games and explain the rules as quickly as possible. Trust your players – they are smarter and much more intuitive than we are anyway when it comes to games :-)

9. To keep the games flowing – make sure you plan game restarts: keep lots of balls ready at your feet and feed them in into the field of play.

————–

U8 practice season organization (8 weeks – 8 practices)

1. dribbling

2. dribbling

3. short passing

4. long passing/shooting

5. dribbling

6. short passing

7. long passing/shooting

8. final practice – scrimmage: kids vs. adults

Usually, after fourth practice, you can adjust to what your players want: they should have their favorite games by then and will ask you to play them over and over – let them.

Final note:

Dribbling is THE thing to learn/play at this age. Do not get discouraged when your passing practices “deteriorate” into dribbling battles – it’s supposed to happen. And in general – do not be afraid of things going out of order – with kids it just looks that way :-) If they constantly have a ball at their feet and look happy and enthusiastic, and are tired at the end of the practice – you did your job :-)

02/10/10 Practice plan. Dribbling and ball control. U8, 60 minutes.

February 10th, 2010

1. Warm-up (~10 mins)

“Green light” dribbling game. Setup: 10×10 square (yards) (dimensions depend on number of players). Players inside the box, everyone has a ball. Coach issues commands: “green light” – players can dribble, “red light” – players have to stop and put a foot on a ball. Do couple times. Add more lights one by one: “yellow light” – dribble slow, other lights (use your imagination for colors) – dribble make a 180 degree turn, dribble with right/left foot only, inside/outside of a foot only, etc. Also – after red light, call out a body part: when you name a body part – players have to put it on a ball, for example: “left elbow”, “right knee”, “forehead”, “stomach”, “back”, etc. Can combine two or three: “left elbow and right knee”, etc. (this is dynamic stretching exercise). At the end – combine four or five parts at a time or ask for something impossible, kids will have a laugh by trying to do it.

How to run the activity:

At first – just explain “green light – red light” rules and start them running. Usually, kids get into it semi-heartedly, some will even walk with the ball. Stop the game and ask them if they are supposed to walk or run when dribbling – make sure they say “run”. Re-affirm that, restart the game, watch the difference. If they only jog – let them dribble for a couple of minutes, stop again, and ask if they need to run slow or fast – they will answer “fast”, re-start. Other things to watch/questions to ask: “do you keep your ball close or kick it away?” (close – so that in a game other team does not steal it), “do you stay inbounds or let it go out of bounds?”, “do you bump into other players or keep your head high and watch out?”, etc. After you make sure that they get two-three out of these points (don’t go for all of them in one practice) and you see that they dribble with higher intensity – add other lights, add body parts.

As a general rule, keep your talk to two-three sentences at most, no longer than thirty seconds at a time. Keep it to absolute minimum: they will learn faster by playing with a ball.

Water break. For water breaks, make them do something funny to get from the point of activity to their parents with bottles: make them jump like kangaroos, or frogs, or crawl like crabs, or hop like bunnies, etc. Make them race. Tell them ahead of time how much time they have: “thirty seconds for water break”, “one minute”, etc. As a rule: you want short breaks (30sec-1min) in the beginning, longer ones (~2 mins) later.

2. “Sharks and minnows” (3-4 cycles, will usually take 10-15 mins)

Setup: rectangular field 15×30 (can use large goalie box).

Rules: all players (“minnows”) line up at the narrow end of the field, everyone has a ball. Their goal is to dribble through the field to the other end. One or two coaches (sharks) start in the field; sharks’ goal is to kick players’ balls out of bounds. If a player looses a ball then she becomes a shark too. The last minnow with a ball wins (end of cycle).

To start, go easy on them, let everybody through at least once until they get into the game. Then – kick balls out of one or two players and make them sharks (normally – target your best players: it’s the other ones who need more practice).

By the end, when only two or three “minnows” left standing, make sharks hop like bunnies or crawl like crabs – otherwise, it’s too easy for them.

Water break.

3. “Line soccer” (~10-15 mins) 2v2

Setup: 20×30 field, large goals at each end, 2v2 game.

Rules: to score, a player needs to dribble through the goal and stop the ball beyond the goal line. Depending on players’ abilities, you can allow certain distance where it still counts as a goal (e.g., have to stop the ball within 3 feet behind the goal line).

Have two games at a time (have assistant coach supervise the second game), rotate teams in and out after ~2-3 minutes (this is very intense – they get tired easily; as soon as they start walking instead of running – substitte). This way, you will have 4 players playing and 2 players resting for each game – works out perfect for a team of 12. Adjust for your numbers accordingly.

Water break.

4. “Line soccer” (~10 mins), two games at the same time.

Same rules as before – only make sure that all players are on the field (still two games at the same time. Adjust field sizes accordingly). Such, for a team of 12, you would have 2 games of 3v3.

Water break.

5. Scrimmage (through the end of the practice – try to make it at least 10 mins)

Divide your team in two groups and make them play each other in a scrimmage. Play with the “line soccer” rules for the first 3-5 minutes, no restrictions after that.

The end :-)

on Lisp

February 5th, 2010

Kent Pitman: “…Please don’t assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list.”

Breadcrumbs:

http://www.gigamonkeys.com/book/lather-rinse-repeat-a-tour-of-the-repl.html
http://www.osix.net/modules/article/?id=912
http://common-lisp.net/project/slime/doc/html/Running.html#Running

http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2007-06/msg01185.html

To fix indentation: C-c M-q

Памяти хомячка Йоши. Январь 31, 2010

January 31st, 2010

В день смерти хомячка Йоши, Jan 31, 2010

На смерть собаки. Вадим Егоров

Как же мы с тобой
Жили хорошо,
Как же сладко,
Солнышко моё,
Горюшко моё,
Шоколадка,

Наледь на душе,
На сердце ожог,
Шаг бесцельный.
Что ж ты натворил,
Нежный мой дружок,
Друг бесценный.

Жалящий огнём,
Лечащий мечом,
Умный самый,
Упокой, Иисус,
В садике своём
Нашу Сану.

Ибо в снег и дождь,
Ибо в день и ночь,
В зиму, в лето,
Уж прости Господь,
Нам была, как дочь,
Псина эта.

На моём окне
Дождь чечётку бьёт,
Отбивает,
А соседский пёс
Воет, как поёт,
Отпевает.

Непогодь и пёс
Воют в унисон,
Будто плачут,
Завтра поутру
Мне ворвётся в сон
Визг собачий:

Это в небесах,
В горней из высот
Там, над нами,
Девочка моя
Палочку несёт
Мне и маме.

Ошибка Apple – by Paul Graham

January 29th, 2010

Первоисточник:
http://www.paulgraham.com/apple.html
Translated on Jan 29, 2010 by Vyacheslav Mayorskiy.



Ноябрь 2009

Мне кажется, что Apple не осознает, насколько ужасно сломан процесс одобрения программ для App Store. Либо же они не понимают, насколько это плохо, то, что этот процесс сломан.

То, как Apple организовала App Store, вредит ее репутации среди программистов более чем что-либо еще, что она когда-либо делала. Репутация компании среди программистов имела обыкновение быть благоприятной. Обычным делом были жалобы на то, что фаны Apple восхищались компанией без должного критисизма. App Store изменил такое положение вещей. Теперь многие программисты начинают воспринимать Apple как зло.

Какую долю программистов, первоначально настроенных доброжелательно, Apple уже потеряла из-за App Store? Треть? Половину? И все еще продолжает терять. App Store – это непрекращающаяся утечка кармы.

* * *

Как же Apple оказалась в таком беспорядке? Ее фундаментальная проблема заключается в непонимании процесса программирования.

Apple рассматривает iPhone приложения так же, как и музыку, продающуюся через iTunes. Apple – это канал; пользователь ему принадлежит; если вы хотите связаться с пользователями, вы делаете это на условиях, контролируемых компанией. Рекорд-лейблы на такое сотрудничество согласились, хотя и с неохотой. Но эта модель не работает для программного обеспечения. Посредник не может контролировать пользователя. Бизнес программного обеспечения узнал это в начале 1980-ых на примере таких компаний как VisiCorp: хотя слова “программное обеспечение” и “издатель” и сочетаются лингвистически, но суть от этого не меняется. Программное обеспечение не походит на музыку или книги. Действовать как посредник между разработчиком и пользователем для третьего лица слишком сложно. И все же это то, чем Apple пробует быть с App Store: издателем программного обеспечения. Издателем со специфическим вкусом и строгим упорядоченным стилем.

Если публикация программного обеспечения не работала в 1980, то сейчас она работает еще меньше: теперь, когда разработка программного обеспечения перешла от редкого количества крупных релизов к постоянному потоку малых. Но Apple этого тоже не понимает. Ее модель разработки берет начало из аппаратных средств. Она работает над продуктом до тех пор, пока он, по ее мнению, не готов к выпуску, и только после этого следует релиз. Такой подход необходим с аппаратными средствами, но неприемлем для программного обеспечения. Стандартный современный способ программирования состоит в том, чтобы начать быстро и выпускаться часто. Это означает, что длинные, случайные задержки между версиями, это – катастрофа.

Очевидно, позиция Apple состоит в том, что разработчики должны быть более осторожными, когда они представляют новую версию в App Store. Но насколько бы мощной компания ни была, она не достаточно мощна, чтобы повернуть вспять развитие технологий. Программисты не используют “начни быстро, выпускайся часто” из-за лени. Они используют этот подход, потому что он приводит к лучшим результатам. Затрудняя этот процесс, Apple побуждает их выпускать брак, и это программистам неприятно так же, как и Apple.

Как бы понравилось Apple, если бы когда она обнаружила серьезную ошибку в OS X, вместо того, чтобы выпустить исправленную версию немедленно, она должна была бы предоставить свой код посреднику, который бы продержал его в течение месяца и затем отклонил, потому что тот содержал иконку, которая ему не подошла?

Нарушая процесс разработки программного обеспечения, Apple получает противоположность того, к чему она стремится: версия приложения, в настоящее время доступного в App Store, имеет тенденцию быть старой и с большим количеством ошибок. Один разработчик мне сказал:

   В результате их процесса, App Store полон полусырых приложений. Почти каждый день я делаю новую версию, которую  выпускаю своим бета – пользователям. Версия на App Store чувствуется старой и дрянной. Я уверен, что большое количество разработчиков чувствуют то же самое: “Я не особенно горжусь тем, что поместил в App Store” в совокупности с “Правду говоря, это вина Apple”.

Другой написал:

   Я полагаю, что они думают, что их процесс одобрения помогает пользователям, гарантируя качество. В действительности, такие ошибки, как наши, попадаются все время, а разрешение исправленной версии может занять 4-8 недель, оставляя пользователей с мнением, что iPhone приложения просто иногда не работают. Что еще хуже для Apple, так это то, что эти же программы работают прекрасно на других платформах со скорым процессом одобрения версий.

В действительности, я полагаю, что Apple имеет третье неправильное представление: что все жалобы о процессе одобрения App Store – это несерьезная проблема. Разработчики, партнеры, и поставщики жалуются всегда. Это был бы плохой признак, если бы жалоб не было; отсутствие жалоб означало бы, что что-то не в порядке. В то же время продажи iPhone идут лучше, чем когда-либо. Так зачем же им что-то менять?

Apple удается избегать последствий плохого обращения с разработчиками, потому что она выпускает замечательное “железо”. Я приобрел новый 27″ iMac пару дней назад. Он великолепен. Экран слишком ярок, и диск неожиданно громок, но он настолько красиво, что на такие мелочи не обращаешь внимания.

Итак, я его приобрел, но приобрел со смешанными чувствами. Мне казалось, будто я покупаю нечто, сделанное в стране, где нарушаются права человека. Это было ново. В прошлом, когда я покупал продукты Apple, покупка была чистым удовольствием. Это восхитительно! Они выпускают такие замечательные вещи! В этот же раз я чувствовал себя Фаустом. Они выпускают такие замечательные вещи, но они – такие идиоты. Хочу ли я в самом деле поддерживать эту компанию?

* * *

Стоит ли Apple беспокоиться о том, что думают, такие как я? Какая разница, если незначительное меньшенство их пользователей будет относиться к ним отчужденно?

Есть пара причин, по которым им следует беспокоиться. Когда вашу компанию воспринимают как зло, то лучшие программисты работать к вам не пойдут. Это повредило Microsoft в значительной степени в 90-х. Программисты начинали чувствовать себя овцами. Им казалось, что они продаются. Когда сотрудники Microsoft в общении упоминали свое место работы, им приходилось выслушивать множество уничижительных шуток о переходе на сторону тьмы. Но действительная проблема Microsoft заключалась не в унижении нанятых работников. Она заключалась в программистах, которых они никогда не получили. И знаете куда те подались? В Google и Apple. Если Microsoft – Империя, то они были Союз Повстанцев. И по большому счету именно потому, что они сумели приобрести большее количество лучших сотрудников, Google и Apple чувствуют себя лучше, чем Microsoft.

Почему же программисты настолько разборчивы в морали своего работодателя? Отчасти потому, что они могут себе это позволить. Лучшие программисты могут работать там, где захотят. Им необязательно работать на компанию, которая вызывает чувство тошноты.

Другая причина, почему программисты разборчивы, как мне кажется, заключается в том, что зло порождает глупость. Организация, побеждающая за счет силы, теряет способность побеждать за счет лучших разработок. И для способного человека удовольствия не приносит работать там, где лучшие идеи не преобладают. Я думаю, что Google принял “Не будь злом” с таким энтузиазмом не для того, чтобы произвести впечатление, а как напоминание самим себе о том, к чему может привести высокомерие.[1]

Такой подход до сих пор работал для Google. Они превратились в более бюрократическую структуру, но, похоже, остались верными своим изначальным принципам. С Apple такого не произошло. Оглядываясь на известный рекламный ролик 1984-го, Apple теперь легче представить в качестве диктатора на экране чем в качестве спортсменки с молотом [2]. Если перечитать речь диктатора, она звучит как предсказание App Store:

   Мы одержали победу над беспринципным распространением фактов.

   Мы создали, впервые во всей истории, сад чистой идеологии, где каждый рабочий может цвести в безопасности от вредительства противоречащих и запутывающих истин.

Еще одна причина, по которой Apple следует заботиться о том, что думают программисты, это то, что если вы продаете платформу, то программисты – это та сила, которая ведет либо к успеху, либо к провалу. Если кто и должен это знать, так это Apple. VisiCalc послужила залогом успеха Apple II.

Программисты создают программы для платформ, которые они используют. Большинство программ – большинство начинающих компаний, по всей видимости, – происходят из персональных проэктов. Apple не исключение. Apple делала микрокомпьютеры, потому что их хотел для себя Стив Возняк. Он не мог себе позволить приобрести микрокомпьютер [3]  Точно так же и  Microsoft началась с разработки интерпретаторов для микрокомпьютеров, потому что Бил Гейтс и Пол Аллен были заинтересованы в их использовании. Редко когда начинающая компания создает нечто, не использующееся собственными основателями.

Основная причина того, что существует такое множество iPhone программ в том, что множество программистов имеют iPhone. Они могут знать, ибо прочитали, что Blackberry занимает такой-то процент на рынке. Но в действительности, RIM как будто не существует. Когда программисты хотят что-то создать, они хотят создать это для себя, и это означает iPhone приложение.

Итак, программисты продолжают писать программы для iPhone, хотя Apple продолжает ставить им препоны. Они похожи на того, кто завяз в отношениях с избивающим партнером. iPhone настолько притягателен, что они не могут его покинуть. Но они поглядывают на сторону. Вот что написал один программист:

   Хотя мне и нравилось писать для iPhone, но контроль, налагаемый на App Store не дает мне возможности создавать приложения, как мне бы того хотелось. Теперь у меня уже нет намерений писать для iPhone за исключением абсолютной необходимости. [4]

Может ли что либо разорвать этот круг? Ничто, что я видел до сих пор. На Palm и RIM надежды никакой. Единственный вероятный соперник это Android. Но Android – сирота; Google относится к нему с безразличием, в отличии от того, как Apple относится к iPhone. Apple относится к iPhone, как Google относится к поиску.

* * *

Застолбила ли Apple за собой будущее карманных устройств? Перспектива мрачной моно-культуры, какую мы имели в 1990-х, неутешительна. В 1995-м написание программ для пользователей означало написание  Windows программ. Наш ужас от такой перспективы был единственным наизначительнейшим фактором, побудившим создание программ для интернета.

По крайней мере теперь мы осознаем, что может привести к поражению Apple. Нужно отобрать iPhone у программистов. Если бы программисты использовали какое-то другое мобильное устройство для онлайн-доступа, то они бы начали разработки для него.

Как же можно сделать такое устройство, которое бы больше понравилось программистам, чем iPhone? Маловероятно, что удалось бы создать что-то с лучшим дизайном. Apple не оставляет никаких шансов. Следовательно, такое устройство по всей вероятности уступало бы с точки зрения общей привлекательности. Чтобы выиграть, ему бы пришлось предложить что-то привлекательное специально для программистов.

Один способ привлечь программистов – это при помощи программного обеспечения. Если вы можете придумать нечто, что программисты бы нашли необходимым заполучить, но что было бы невозможно в ограниченном мире iPhone, то предположительно они бы переключились.

Это неизменно бы случилось, если бы программисты начали использовать карманные устройства для написания программ: если бы карманные устройства заменили ноутбуки так же, как ноутбуки заменили десктопы. Свобода с машиной для разработки нужна бОльшая, нежели Apple позволит с iPhone.

Сможет ли кто-нибудь сделать устройство, которое помещалось бы в кармане, как телефон, и в то же время подходило для программирования? Сложно представить, как бы такое устройство выглядело. Но я уже научился никогда не говорить никогда в отношении технологий. Устройство для программирования размером с телефон не более поразительно по современным стандартам нежели iPhone мог бы показаться по стандартам 1995-го.

Моя теперишняя машина для программирования – это MacBook Air, которую я использую с внешними монитором и клавиатурой в моем оффисе, а так же саму по себе в дороге. Если бы была версия вполовину меньше то я бы предпочел ее. Она бы не была размером с телефон, но примерно в четыре раза больше. Несомненно, эта разница преодолима. Давайте сделаем это RFS-ом. Требуется: женщина с молотом.

Заметки.

[1] Когда Google приняли “Не будь злом”, они все еще были настолько малы что зла от них никто и не ожидал. Пока.

[2] Интересно, что диктатор на экране в ролике 1984-го не Microsoft; это IBM. IBM казалась намного более устрашающей в те дни, но она была более дружественной для разработчиков нежели Apple в наши дни.

[3] Он даже не мог себе позволить монитор. Вот почему Apple I использовала телевизор в качестве монитора.

[4] Несколько человек, с которыми я разговаривал, отметили, что им нравится iPhone SDK. Проблема не в продуктах Apple а в ее порядках. К счастью, порядки – это программы; Apple может их изменить мгновенно если захочет. Удобно, не правда ли?

Благодарности: Сэму Альтману, Тревору Блэквелу, Россу Баучеру, Джэймсу Брэйси, Габору Целле, Патрику Коллисону, Джэймсу Фреедману, Джону Груберум Джо Хьюитту, Джессике Ливингстон, Роберту Моррису, Тенг Сионг Онгу, Нихиль Пандит, Саврай Сингх, и Джэреду Тэйм за прочтение черновиков этого текста.

Psychology of Debugging

January 27th, 2010

One day I came to work after semi-sleepless night just to find out that some of my colleagues thought they were incapable of performing simple troubleshooting tasks and waited for me to resolve fairly trivial issues. Naturally, frustration spilled into a long letter on the subject – with some mroodling on psychology and phylosophy of debugging. Here are some extras…



The main philosophical thing in troubleshooting is to remember that with these stupid metal things we call computers there are no mysteries: everything can be explained (eventually :-) ), it’s just matter of time. Under the hood, these things are pretty stupid: on a given conductor fragment it’s either one (there is electric current) or zero (there is no current), that’s all there is to it. If there are differences in behavior then it means that there are differences in the binaries and therefore differences in the code. You just need to ask yourself what could be wrong and confirm or eliminate that possibility with whatever means you can think of (i.e., if you can’t use debugger – use printout statements, etc. Long time ago, I once had to make lights blink in different ways in different scenarios in order to identify which path the code took. Another time – had to make machine reboot on one path and had it stay online on another. These are just examples on to what extent you can take available equipment. After a while, after all false possibilities are eliminated, you will inevitably find the source of the problem :-) (“Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth.” -Arthur Conan Doyle).

Applying all this to the current situation – if the issue is reproducible on the test bed only then that’s where you troubleshoot it. And make sure that you always can revert to “well-known” state: change things one at a time between tests; if new issues arise and you cannot explain them – remove your changes and test again to make sure that behavior reverts to previous controlled flow. Main thing is not to rush: take little steps but make sure that at any time you can both explain what’s happening and revert to previously established flow. If the code is throwing exception in specific place – make sure it’s always throwing it right there and nowhere else; don’t troubleshoot multiple issues – take them one at a time.

And you can add some spirituality to your approach too: those machines are actually alive and they have their own characters. They sense confidence and fear – don’t show them your doubts; instead, make them afraid of you – and they will give up sooner :-)

This is not a job – this is mysterious adventure :-)

HTTPS, SNI, and gnutls breadcrumbs

January 20th, 2010

I am not going to get into details on the subject, just will mention some keywords (“breadcrumbs”) – and you should be able to google the rest.

The issue at hand: I needed to host two websites on the same server and both sites needed to be secured with SSL. When you try this for the first time you will quickly run into unpleasant discovery of the fact that you can only have one certificate active per IP address, which means that when you have virtual hosts then only one of them can be secured out of the box so to speak.

Simplest solution around this limitation would probably be to use unified communication certificate but it was impractical for my purposes: I already bought two separate certificates and did not want to do another investment (it’s not too much though: you can get a certificate for five sites at around $75 per year or so at GoDaddy for example).

Next possible solution was to run https on different ports for different sites: even though you’ll find claims that a cert is limited to an IP address – it’s actually to IP address plus port number therefore you can run https on port 1443 for one domain name and on 2443 for another for example. I did go this route at first. For seamless user experience I opened ports 1443 and 2443 in my router (443 was open already) and then set up redirection with mod_rewrite (LAMP, free as in beer, remember?) for each site. Things worked this way successfully – but I ran into issues with my shopping cart software package and did not feel like troubleshooting those (apparently, they have some validation checks, which hardcodedly expect port 443).

So – a little more searching the net – and here come gnutls and SNI

http://en.wikipedia.org/wiki/GnuTLS
http://en.wikipedia.org/wiki/Server_Name_Indication

gnutls is not packaged into Ubuntu 8.04 (the LTS version I set my server with) therefore to avoid hassles of compilation I ended up upgrading to 9.10 (karmic). After that,

apt-get libapache2-mod-gnutls

with appropriate apache configuration did the trick.

Nota Bene: make sure to learn limitations of SNI. Such, quite ironically in my opinion, Konqueror is one of the browsers, which does not process such responses correctly.

Another thing: I suspect that fairly soon (within a year from the date of posting this message) SNI support will be built into ssl mode directly so there will be no need for all this trickery.

Mroodles on Errands

November 22nd, 2009

Among other things, Paul Graham’s essays are great by the fact that they contain first-hand tips about practical pitfalls of applied hacking. These pitfalls may seem secondary to uninitiated but they serve as foundation to everyday coding. And Paul shows extensively throughout his texts how to deal with these pitfalls, you just need to pay attention and not miss these hints when they jump into your face.

Take errands for example. Errands are killers of inspiration: when you have outstanding errands to run you cannot concentrate on a problem at hand. Everyday chores hang over your head with Damocles sword’s inevitability and trash your mind with wasteful worries. It can be any little stupidest thing that breaks your work mood, anything at all: necessity to pay bills, or cut your lawn, or change water in aquarium, or load a dishwasher, or feed a cat.

Thought process is very finicky: you need to get in the flow, you need to approach a problem from considerable distance starting with things that at first may not even seem related to the task at hand. Step by step, pass by pass you iterate towards your ultimate goal with back and forth swings, sometimes intentionally getting distracted by some tiny detail of some secondary feature, sometimes taking a step back and overlooking entire domain as a whole. These gradual methodical mind advances cannot be rushed and crude interruptions from “real life” at any stage of this catching the wind dance may be deadly to the entire problem solving process. It’s even beyond the point that you will need to waste considerable time just to return to the virtual neighborhood of thoughts where you were interrupted; this time may be in the magnitude of hours but that’s not the worst. The most horrible part is that the next time at some obscure intersection your mind will take left turn instead of right and you will never catch the same flow. It may look similar and may contain most the same primary attributes but there is high likelihood that some original thoughts are missing. It’s like re-writing a piece of code the second time around on the same feature: you will never be able to get it the same and will be left with unsettling feeling of mistaken identity.

Errands are probably the worst enemy of creativity (outside of having to work for the corporate world that is). Foreign thought intrusion of having to pay a bill during working on real stuff is this kind of crude mood killer that has to be avoided at all cost. One of the ways to fight back is quiet contention: you can train yourself to work out the “so what” attitude towards chores even when it pushes boundaries of social acceptability. So what that neighbors point to your overgrown grass where turkeys can hide with ease. So what that you incur an overdraft fee because you forgot to check your account balance prior to the automated payment kicking in. So what that stupid aquarium fish did not get their food in three days. By successfully ignoring these chores you are able to dedicate your undivided attention to worthwhile substance and – most likely – create more wealth than you loose in late fees.

Of course, as with anything, you have to walk the fine line of not taking this concept to the extreme. At some point stupid fish will indeed die if you do not attend to it. That kind of point of no return is usually good indicator for you to stop coding and sacrifice your time to errands: “I cannot postpone it any longer or stupid fish will die.” Until then – enjoy your freedom of social emancipation.

Kicking and Screaming

November 13th, 2009

Here’s how you tell if a coach has any kind of experience or not: watch him on the sidelines during a game. An experienced coach will observe his team quietly for the most time, giving brief pointers or encouragements from time to time, but mostly – just watch, silently analyze, and enjoy the game.

On the other side of the spectrum, however, there is a coach, who does not trust his players yet, and as a result – jumps up and down with every kick of a ball, and screams and yells instructions for every play – every single little play that is.

I recently watched a game between two boys’ U12 teams – one of those we’ already played, the other one – are about to play later in the season, so I wanted to scout it (by some lucky incident, their originally scheduled game rained out and now they had to play it during a week, which gave me this opportunity).

So – the game starts. Coaches on both benches are quiet, boys are playing, the game is exciting and full of legitimately thoughtful action by both sides. The first half ends in a 0-0 tie. Halftime break. Another coach arrives for one of the teams. As soon as the second half starts – the coach brings painful dissonance into the harmony of the moment: he starts yelling directions to his players every roll of the ball: “go to the left!”, “pressure him!”, “spread out!” (my all time favorite :-) ), “pass!”, “shoot!”, “run!”. He just never shuts up. And unless you are unfamiliar with the situation – you won’t believe it: his players start playing worse and worse, and you can tell – the only reason is that the boys are loosing their confidence… Five minutes into the half, the other team scores. Five minutes of kicking and screaming on the sidelines by an adult, who seemed nauseatingly out of place – all it took to break the team. That’s how the game ends – 1:0. A loss for a team that most of the time controlled the flow and borderline dominated the field.

It’s difficult for us as parents and adults to let go and accept the fact that frankly – after a game starts – there is not that much we can do to control a horde of excited kids, chasing a piece of leather filled with air. That’s why all this desperate instructional flood of words: it’s coping mechanism by a coach to disillusion oneself into belief that he can still direct where the game goes, that he is still in control.

From personal observations, we all go through this phase of kicking and screaming – vast majority of coaches (I am talking here about at least 6v6 or higher numbers games on official fields with official referees). It is not until you’ve been in a hand full of games when you realize that all you need to do is trust your players to make right decisions – or make wrong ones and learn from them. It’s not until later – that is of course if you decide to stay in this racket – when you learn to step back and let players play.

Another thing is – as shown on the example of the above game – children do sense when you do or do not trust them. If you are relaxed, or at least if you are putting up the face of a coach who relies and trusts his players to do their job – your confidence will rub off them and they will not look over their shoulder checking whether they are doing the right thing or not every instant of a game.

Sure, you will still need to correct your team periodically in a game and you will still get emotional on the side lines from time to time (I am often accused of showing lack of any emotion – even though I have tsunamis overflowing erupting volcanoes inside of my soul every second of a game) – but at least you won’t be filling air with non-stop vibrations of useless dissonance in helpless attempt to justify your own existence as a coach :-)

Letter to Parents

November 13th, 2009

This was a letter to parents of one of my boys’ U10 travel team. Fall 2008 season (?). Feel free to re-use it :-)

——————-

Hi Everybody,

With our first game just another day away, I would like to make some comments on practices and games (yes, another veeerrry loooong message).

Practices:

Please arrive five-ten minutes prior to the designated start time to allow for proper warm-up.

We will go through some basics this season, mostly offense-oriented: mostly dribbling and passing with some shooting. After that, we’ll do whatever seems to be of the most need. We will not care much about positions at this age at practices.

Games:

Please arrive thirty minutes prior to all games.

Let me repeat :-)

Please arrive thirty minutes prior to all games. Once again, this is needed for proper warm ups. Also, under other equal circumstances (i.e., practice attendance) those, who arrive to the game first, will start the game.

During the games – please respect all participants: both the opposition and the referees. Especially referees: approximately 50% of the first year referees stop helping with the games due to verbal abuse from parents. Please remember that these are the same kids as your boys and deserve the same type of respect. They will make mistakes – it’s really not a big deal :-)

Also, unfortunately for you (or fortunately – depending on your perception of youth soccer :-) ) – I don’t care about wins or losses that much. The priority will be given to having all boys play equal amount of time during the games at all positions.

Please don’t give advices from the sidelines during the games: usually, they do not achieve much and only distract boys from the action. Also, they may and will contradict with what we are doing in practices and that will really confuse the players. Such, we are doing some dribbling exercises in practices right now – and that’s what I am going to look for in the first couple of games – just plain one on one encounters (or one on two, or one on five – whatever the case may be :-) ). Also, games are for players: they need to go through practical trial and error experience in competitive setting. Last reason is that even though our intentions are good – we don’t always give the right advices: cliche`s like “spread out”, “mark somebody”, “boot it”, etc. are generally counterproductive for several reason. First – they need to be taught in a practice first through targeted exercises and repetitions in order to mean anything in a game. Second – they usually do not provide specific directions and most often do not apply to the whole team but to individual players only. Also, point of view from the sidelines is different from the point of view from the middle of the pile: kids may not see what you see.

All this does not mean that you cannot cheer – by all means, parental support is vital to the team spirit :-) Just please try to restrict yourself to general encouragement phrases only, a la “great shot!”, “nice pass!”, “it’s ok, you’ll get him the next time!”, etc.

I hope I did not come off too negative :-)

Please let me know if you have questions, I’ll be happy to help. And remember: our main objectives are having some fun and continuing skill development, the rest is distant second.

Just a reminder: our first game is this Saturday at our home field at 1 PM. And yes – this means that you need to bring the boys no later than 12:30. Some of the kids did not have enough water at our last couple practices – please make sure that they have enough for the game. Also, please don’t forget the uniforms :-)

See you at the game :-)

——————–

Ты меня не любишь, не жалеешь…

November 13th, 2009
Сергей Есенин - "Ты меня не ..."

Ты меня не любишь, не жалеешь,
Разве я немного не красив?
Не смотря в лицо, от страсти млеешь,
Мне на плечи руки опустив.

Молодая, с чувственным оскалом,
Я с тобой не нежен и не груб.
Расскажи мне, скольких ты ласкала?
Сколько рук ты помнишь? Сколько губ?

Знаю я — они прошли, как тени,
Не коснувшись твоего огня,
Многим ты садилась на колени,
А теперь сидишь вот у меня.

Пусть твои полузакрыты очи
И ты думаешь о ком-нибудь другом,
Я ведь сам люблю тебя не очень,
Утопая в дальнем дорогом.

Этот пыл не называй судьбою,
Легкодумна вспыльчивая связь,—
Как случайно встретился с тобою,
Улыбнусь, спокойно разойдясь.

Да и ты пойдешь своей дорогой
Распылять безрадостные дни,
Только нецелованных не трогай,
Только негоревших не мани.

И когда с другим по переулку
Ты пойдешь, болтая про любовь,
Может быть, я выйду на прогулку,
И с тобою встретимся мы вновь.

Отвернув к другому ближе плечи
И немного наклонившись вниз,
Ты мне скажешь тихо: «Добрый вечер...»
Я отвечу: «Добрый вечер, miss».

И ничто души не потревожит,
И ничто ее не бросит в дрожь,—
Кто любил, уж тот любить не может,
Кто сгорел, того не подожжешь.

4 декабря 1925

Невеста льва

November 13th, 2009
Жрец решил. Народ, согласный
С ним, зарезал мать мою:
Лев пустынный, бог прекрасный,
Ждёт меня в степном раю.

Мне не страшно, я ли скроюсь
От грозящего врага?
Я надела алый пояс,
Янтари и жемчуга.

Вот в пустыне я и кличу:
«Солнце-зверь, я заждалась,
Приходи терзать добычу
Человеческую, князь!

Дай мне вздрогнуть в тяжких лапах,
Пасть и не подняться вновь,
Дай услышать страшный запах,
Тёмный, пьяный, как любовь».

Как куренья, пахнут травы,
Как невеста, я тиха,
Надо мною взор кровавый
Золотого жениха.

-Николай Гумилев, сентябрь 1907

Отказ

November 13th, 2009
Царица иль, может быть, только печальный ребенок,
Она наклонялась над сонно вздыхающим морем,
И стан ее, стройный и гибкий, казался так тонок,
Он тайно стремился навстречу серебряным зорям.

Сбегающий сумрак. Какая-то крикнула птица,
И вот перед ней замелькали на влаге дельфины.
Чтоб плыть к бирюзовым владеньям влюбленного принца,
Они предлагали свои глянцевитые спины.

Но голос хрустальный казался особенно звонок,
Когда он упрямо сказал роковое: "Не надо"...
Царица иль, может быть, только капризный ребенок,
Усталый ребенок с бессильною мукою взгляда.

-Николай Гумилев

Epiphany: High Memory Usage in Linux

November 11th, 2009

This is a good one – and it caused me approximately three-four days worth of worrying. Both in CentOS and in Ubuntu virtual memory kept growing and growing, slowly while system was relatively idle and lightning fast and almost up to the total limit when performing heavy IO operations. For the life of me I could not figure out what was going on – until finally instead of searching for “memory leak in linux” I did “high memory usage in linux”. Results were quite surprising:

http://www.webmasterworld.com/forum40/242.htm

Summary of the thread in a short quote:

<quote>

On a healthy and active system, there’s no “unused” RAM.

linux (and probably any *nix system) will give each application the memory it requests, and then use the rest for disk caching. Depending on the reporting mechanism, you may indeed see a constant memory useage somewhere between 90 and 100%. If your web server gets more load and requests additional memory later, then the system will sync out some of the cached disk data and reallocate the gained space to the httpd.

<end of quote>

Very unorthodox for someone with Windows background – but very reasonable and logical if you think about it for longer than three seconds. Quite a epiphany :-)

Самоубийца

November 11th, 2009
Улыбнулась и вздохнула,
Догадавшись о покое,
И последний раз взглянула
На ковры и на обои.

Красный шарик уронила
На вино в узорный кубок
И капризно помочила
В нём кораллы нежных губок

И живая тень румянца
Заменилась тенью белой,
И, как в странной позе танца,
Искривясь, поникло тело.

И чужие миру звуки
Издалёка набегают,
И незримый бисер руки,
Задрожав, перебирают.

На ковре она трепещет,
Словно белая голубка,
А отравленная блещет
Золотая влага кубка.

-Николай Гумилев, сентябрь 1907

Планер: Универсальная Эмблема Хакеров – by Eric S. Raymond

November 10th, 2009

Первоисточник: http://www.catb.org/~esr/hacker-emblem/ Translated on Nov 8, 2009 by Vyacheslav Mayorskiy. Last updated: March 6, 2010.


Glider pattern from the Game of Life

 

У Линуксовского сообщества есть пингвин, у FreeBSD – чертенок, а PERL представлен верблюдом. У фанов Фонда свободного программного обеспечения есть антилопа гну, и даже у Организации Открытого Программного Обеспечения есть своя картинка. Чего у нас исторически не сложилось, так это символа, который объединяет сообщество хакеров, включающее в себя и вышеназванные группы. Я предлагаю принять в качестве такого символа модель планера из Игры “Жизнь”.

БОльшая часть хакеров, которым я высказывал эту идею в качестве альфа-тестирования, соглашались мгновенно и в дополнительных объяснениях не нуждались. Если вы не знаете, что такое этот планер, или почему он подходит в качестве символа, или если вы сомневаетесь в необходимости эмблемы как таковой, то прочитайте страницу
ЧАСТО ЗАДАВАЕМЫХ ВОПРОСОВ
. (Либо – вот это – Прим. Сл.)

Впервые я предложил эту эмблему в октябре 2003. С тех пор она приобрела довольно широкое распространение, в чем вы можете лично убедиться по количеству переводов слева (См. первоисточник – Прим. Сл.). Эмблема не универсальна, ибо многие хакеры возражают против идеи наличия эмблемы в принципе, но, по крайней мере, она является наиболее подходящим мемом (Ссылка моя – Сл.)

Что этот символ собой выражает?

 
Когда вы помещаете эмблему планера на вашу веб-страничку, или носите на одежде, или показываете каким-либо другим способом, вы связываете себя с культурой хакеров. Это – не совсем то же самое, что и быть хакером самому: чести удостоиться этого звания можно лишь от других; самому хакером прозваться не выйдет. И все же,используя этот символ, вы выражаете свою симпатию целям, мировоззрению, и этому удивительному образу жизни. См. страницу ЧАСТО ЗАДАВАЕМЫХ ВОПРОСОВ для дальнейших разъяснений.

К слову сказать, лишь четыре дня после того, как было высказано это предложение, в продаже уже появились чашки и футболки. Пожалуйста заметьте, что я к ним не имел никакого отношения, и отчислений от продаж не получаю. Фактически, доходы идут в Фонд Электронных Рубежей

Кто не должен использовать эту эмблему?

 
Если ты думаешь, что хакерство – это взламывание компьютеров, то эта эмблема не для тебя: не для того мы ее изобретали. Иди изобрети свою собственную эмблему, крекер. Мы найдем способ унизить и опозорить тебя публично, если ты замешаешься с нашими идеалами.

Первоначально, у меня здесь еще был текст о запрещении против коммерческого использования этого символа, однако достаточно большое количество собеседников весьма убедительно аргументировало, что запрещать непрактично и, возможно, несправедливо, поэтому если вы хотите его использовать, то используйте, но делайте это со вкусом, иначе будут последствия.

Какое использование этого символа разрешается?

 
На планер не существует авторского права и он не зарегистрирован как торговая марка. Рекомендованный способ использования – поместить его на веб-странице, с изображением и ссылкой либо на эту страницу либо непосредственно
на Как Стать Хакером. Вот отрывок XHTML, который Вы можете использовать:

<a href='http://www.catb.org/hacker-emblem/'>
<img src='http://www.catb.org/hacker-emblem/glider.png' alt='hacker emblem' /></a>

будет выглядеть примерно вот так:

hacker emblem

 
Не стесняйтесь увеличивать или сокращать изображение. Этот PNG файл был создан из исходника PIC source и затем уменьшен вдвое. Вы можете также загрузить версию SVG, encapsulated PostScript version, или даже TEX.

Варианты:

 
Перед тем, как создавать ваш собственный вариант, пожалуйста прочитайте страницу ЧАСТО ЗАДАВАЕМЫХ ВОПРОСОВ.

Вот – некоторые из тех, которые мне присылали:


hacker emblem
hacker emblem

.O.
..O
OOO


|_|0|_|
|_|_|0|
|0|0|0|

  .
 ..:

Вот – тема karamba с планером для десктопа KDE.

Вот – ico иконка, а вот – еще одна. Если Вы переименуете один из этих файлов в favicon.ico и поместите его в корневую директорию вашего вебсайта, то планер станет иконкой вашего сайта.

Эти изображения татуировок (1) и (2) внушительны, но, пожалуй, немного чрезмерны.

Прототипы:

 
Идея использовать модели из Жизни в качестве эмблем обыгрывалась некоторыми хакерами в Аргентине.

Linux distro install exercises: part 2

November 6th, 2009

Well, I installed CentOS 5.4 just to try it – with XWindows, etc. – and liked it. Installation was quick and painless, my very own RAID array was automatically recognized and partitioning was intuitive and easy.

Then I re-installed CentOS with minimal configuration (no XWindows – just very basic install).

Then – for the sake of science and curiosity satisfaction – installed Debian 5.0.3 to try. Partitioning process was quite a nightmare among other things, even though RAID was successfully recognized as well: I could not figure out how to specify partition sizes or how to let the installer use existing partitions, etc. And on top of that – as soon as you click “Back” button the installer crashes so you have to re-start the whole process. Another thing I do not like after going through CentOS setup for a couple of times is that the installer is too intrusive and babysitting: it has too many steps instead of combining some stuff into a single screen. As an example, for network configuration you have to go through three or four screens: there is dedicated view for hostname, IP address, network mask, and alike.

Gnome desktop was quite cute though – I forgot how cute it is :-)

Then – once again for the sake of science and curiosity satisfaction – I tried to install Windows 2003 Enterprise Server and it did not recognize redundancy disk array. I poked around but got bored quite quickly: don’t care about Windows on this machine (Dell PowerEdge T100).

I also tried to install Windows XP Pro and Ubuntu Server 8.04 but those did not work at all: I got completely black screen immediately after boot.

So – for the last time I installed CentOS in minimal configuration and started configuring for production. It all went well for a while: no problem with Apache, MySql, or PHP setup, but then I needed to install Gallery2 picture hosting package and – surprise! – it was not found in CentOS repository. This incident made me re-think that whole “six thousand packages for sure include all I want”: out of five packages that I wanted 20% were not found. Of course one can always search and prepare things manually but if that were the case we could have successfully stayed with Windows. You don’t realize how spoiled you become after a month of working with yum…

As a result – here’s new plan: I am going to put Debian on this server :-) So what that setup is raw and crashes during partitioning? its expert mode must include all that one can need, right?

We’ll see how it goes :-)

[Postnote: Debian install kept crashing and crashing so I gave up and installed Ubuntu server edition. In the first couple days I was really missing 'service' and 'chkconfig' commands but on the positive side - had to learn direct access to /etc/init.d area daemons. Here are server specs by the way (it's a x64 system):

PowerEdge T100
Dual Core Intel® Xeon® E3110, 3.0 GHz, 6MB Cache, 1333MHz FSB, No Operating System





PowerEdge T100 Dual Core Intel® Xeon® E3110, 3.0 GHz, 6MB Cache, 1333MHz FSB

[224-1527]
Memory 4GB, DDR2, 800MHz, 2×2GB,Dual Ranked DIMMs


[311-7744]

Primary Hard Drive

160GB 7.2K RPM SATA 3Gbps 3.5-in Cabled Hard Drive

[341-5815]

Floppy Drive No Floppy Drive


[341-5437]

Operating System

No Operating System

[420-6320]

Network Adapter

On-Board Single Gigabit Network Adapter


[430-0488]

CD/DVD Drive 16x DVD Drive, Internal


[313-6943]

System Documentation Electronic System Documentation, OpenManage DVD Kit with DMC


[330-1666]

[330-5280]

2nd Hard Drive

160GB 7.2K RPM SATA 3Gbps 3.5-in Cabled Hard Drive


[341-5824]

Hard Drive Controllers Add-in SAS6iR (SATA/SAS Controller) supports 2 Hard Drives – RAID 1


[341-7775]

Hardware Support Services

1Yr Basic Hardware Warranty Repair: 5×10 HW-Only, 5×10 NBD Onsite

[988-7347]

[989-3500]


[991-2219]


[991-2267]

Installation Services No Installation


[900-9997]

Notes from watching Reading – Billerica BU12 game

October 30th, 2009

(scouting Reading for the upcoming game)

Observations:

1. Formation: mostly 3-2-2. Played 2-3-2 couple times when had two tall
defenders on the field, when 3 defenders – playing sweeper back. Style
of play: play-making.

2. Have two strong wingers: #29 on the left and #45 on the right. They
however did not connect: either played on different shifts or played
opposite to each other in the bad sense of word: both made crosses to
the center where there was no help. Otherwise can be real trouble: both
boys are good technically.

3. No spectacular skills on the team: normal boys. Three or four tall boys – same as ours.

4. Weak spots: on several shifts, right defense + mid area was weak.
Both flanks were susceptible to attacks because of the sweeper’s
V-shape formation but the right one was falling quite badly. Also,
defense did loose concentration: after a Billerica’s winger was coming
down the flank they tended to shift in that direction leaving a couple
of attackers right in the center of the penalty box (that’s how
Billerica scored the only goal by the way: came down left flank and
crossed to the middle – 2 Billerica players were left all alone).

Plan for the game:

Formation: 3-2-2 with center defender on top and side defenders back – this should cover flanks from R wingers.
Style: counter-attack

Area of attack: left flank offense. Left wingers: Paul, Tod, Brendan. Center attack: John, Brady, Justin, Tod.
Defense: left (someone to stay with #45): Justin, Paul, Brendan (?). right: Alvaro, Derek, Greg. Center: Johnatan, Donovan.
Keeper: Ryan.

Last Practice

October 29th, 2009

Tonight was our last practice of the season.

Last practice… As usual, we had coaches vs. kids scrimmage. We did have some modification to this routine: these are hard running 12 year old players, at our age with all our wounds and injuries it’s tough to keep up with youth so we had three of the boys play for us; in total it was 5 v 8 and the game was somewhat even.

Last practice… We still have three more games to play, which is fairly uncommon: these are the make ups due to rain outs. This fact controverses my feelings quite a bit: I am still going to see them three more times, just not at practices.

Last practice… In years of coaching you learn to accept this unfortunate fact: the toughest part of this racket is to let go and realize that you may never see some of these kids again. Sure, it’s a small town, sure, many adults will cross a street to approach and check how you’re doing while you are unlikely to recognize them and just pretend to remember in order not to offend anybody, and of course you will coach some of these boys in the future seasons and bump into others here and there. As for the rest – you are very unlikely to see them.

Last practice and letting go… Every beginning of the season – every first meeting – you watch new boys to come to the field, some confident, some shy and unsure, some eager to play, some indifferent, and you keep thinking: “I don’t know their names just yet but soon – very soon – will know who they are, will know their personalities and their characters”, and you do find out all those things, but then – before you have time to blink – and definitely much sooner than you want, much much sooner, it’s time to let them go.

And all you have to look forward in front of you now is the last game. Because in this season you already had your last practice.

Mroodling while picking linux flavor for my new server

October 29th, 2009

The time has come – I am replacing my server with all its websites with a bigger better meaner machine. This time around I decided to make it Linux: original machine runs Windows 2003 Server OS and I do not like how two-three simultaneous PHP sessions effortlessly max out CPU.

Also, I am making conscious decision to migrate into the open source world. It started maybe three or four months ago: I got excited with Python and as result converted my laptop to Fedora as experiment. Reality exceeded my expectations: for programmer, linux is heaven.

But we digress…

Here is brief overview of what I learned about different Linux flavors.

There are two major families: Red Hat based and Debian based. After that, there are Mandriva, PCLinuxOS, SUSE, and some other popular stand alone distributions. I am going to summarize “family” distributions only.

Red Hat family includes Red Hat Enterprise Linux, or RHEL (you have to pay for it – out of questions for a freelancer), Fedora (desktop oriented community developed), and CentOS (server optimized installation; in reality – recompilation of RHEL source code without Red Hat branding).

Debian family includes Debian itself (commonly picked for server installs) and Ubuntu (to maintain the parallel with RH we will call it predominantly desktop OS even though both Fedora and Ubuntu can be successfully deployed as server installations and Ubuntu even releases separate server edition iso download).

Here are two major differences between families.

First difference: package management: yum vs apt-get. While both managers have similar functionality their repositories differ significantly: as of this writing (10/29/09), “yum list | grep wc -l” for default repository on Fedora 11 returned 15,000+ matches while Debian/Ubuntu repositories presumably know the number of packages in the range of 22,000-25,000. CentOS looses to its peer Debian quite dramatically: it seems to have just 6,000+ packages. Also, apt-get seems to be significantly faster – but I did not have a chance to experience it first hand just yet.

Second difference – for desktop distros: Ubuntu seems to cater towards regular user. As result, it provides more convenience in the form of UI tools (so I’ve heard). As a flipside, for heavy developers it sometimes can be a hassle to get to the actual work domain and perform no-nonsense coding (once again – so I’ve heard). Fedora on the other hand is more raw and actually more unstable due to the fact that it employs cutting edge barely tested packages: I had it crash on me four or five times between reinstalls until I learned not to “yum” every piece of junk that came to mind :-) but it does let me get right to the piece of code I want: with Red Hat heavily relying on python I feel reasonably confident that all modules that I may ever need are already in repository.

Both these differences are quite minor in my opinion: I find it hard to believe that anybody would notice difference between 15,000 amd 25,000 packages unless they are really into some specific stuff. Also, I cannot imagine being unable to apt-get eclipse with python plugin or find some exotic module if push comes to shove, therefore I believe we should agree with common consensus: pick a distro that you know and most comfortable with for your purposes – it’s all linux after all.

Historically, I come from Red Hat background: had to deal with this OS at work when inherited a machine about eight or so years ago. This was the original reason why I put Fedora on my laptop. As such, here is the plan: I’ll keep Fedora for my laptop, will put CentOS on my server (6,000 packages is hardly a limitation: I just need LAMP (Linux + Apache + MySql + PHP)). I also am going to put Ubuntu on my son’s desktop: for him to get the idea that there is world beyond Windows and for me to play around with what seems to be the most popular distro of Linux.

Random thoughts while watching Patriots blowing out Titans 38-0 in the first blizzard of the season by the end of the first half (oh, wait – they scored again, it’s 45-0 already and the half is still not over)

October 18th, 2009

The New England NFL franchise is not the same as during their peak glory days of 2001-2004: two thirds of the team are gone, first generation and then second generation of assistant coaches are gone, and on top of that – Tom Brady is still trying to find the former self after missing a year due to injury.

Anyway, in those glory days, when Patriots were blowing teams out left and right, discussion boards were filled with hating whiners: “they have no class! they have no sense of sportsmanship! they should stop scoring after they are up by one/two/three touchdowns and just run the ball and punt when they don’t get the first down! this is no fair! whaaa!”

The whole premise of not playing your very best in professional sports for any reason is ridiculous at the very least and in my opinion is not worth discussing – and so we won’t :-) On the other side of the spectrum, my assistant coach and I were on the brink of suspension after our second game this season just because our boys U12 team shellacked the opposition 16-0 (that’s the official score, I actually think it was even more than that…)

Usually, what you are supposed to do in such situations when your team significantly outskills its opponent is to put some kind of restrictions on the players: request them to make certain number of passes before they can score, or restrict number of touches they can have with the ball prior to giving it up (e.g., two-touch soccer only), or prohibit scoring all together. Our boys were passing incredibly well – making them do certain number of passes deemed to be sensless so we went to the opposite extreme and told them that they can only dribble in the opposition’s half. Strangely enough (being sarcastic here), that presented no problem to them either: the goals kept accumulating. Later, they imposed another restriction on themselves – without any encouragement from coaches: only those who did not score could shoot on the net… As you may guess, by the end of the game all but one of the boys did not have at least one goal under their belt.

(Bill Bellichick must really hate Jeff Fisher (coach of the Titans): Tom Brady is still in the game, and less than two minutes into the second half he just threw another touchdown to Randy Moss. But we digress…)

One last thing we could do was to prohibit boys from scoring all together but this kind of measure – punishing kids for job well done – is something that goes against my fundamental beliefs and I hope never to resort to such unfairness.

After the game the scores were submitted to the automated system. Later, I was contacted by our division coordinator asking if 16-0 was a typo. After my response that it was not, he must have notified higher league authorities, higher league authorities contacted our town higher authorities, and our higher authorities notified my assistant and I that we’ve been very very bad and naughty and that we have to sit down and explain ourselves and how we reached this lowest of all the lowest levels of indignity, greed, and obsessiveness with results. Sit down we did, explain ourselves we had (basically, that we tried to contain our little monsters but failed), apologize we did, and more severe punishment is left to hang over our heads for the rest of the foreseeable future.

[second part - continuing after a couple of days]

I suppose the thinking behind prohibiting blowouts is to spare childrens’ fragile psychic from the stress of the one-sided losses… I was once told by a league official that “believe me, I saw children quit soccer after blowouts”. I was also told by another official that “nobody wants to be embarrassed like this”. Seemingly, all well and good: big smart adults having kids’ interests at heart, protecting them from unfairness of the cruel world… The downfall of this approach however is very damaging in my opinion: throughout seasons, I observe that some kids give up too easily in the face of adversity. Just tonight at a practice we had a round-robin one-v-one competition and one of the boys went into it complaining that he is the worst and is going to loose. After his opponent scored two goals on him the boy became so discouraged that he almost refused to play. We had some words with him during the break and in the next game he almost beat our best player but that’s not the point. The point is that adults emposing rules on how childrens play leads to loss of interest and excitement by these same children from one side and also promotes culture of not having to try your hardest and giving up too easily on the other.

I see no logic whatsoever in the “kids quit because of blowouts” and “kids are embarrased by blowouts” statements: blowouts are result of one team dominating another; quitting and embarrassment – if any – happens due to domination, not because of its byproducts. Also – just another thought – if a child has any resemblence of character and is excited by soccer then she or he will not quit just because of a 10-0 loss: most fun happens at practices anyway. Those who quit most likely are not too interested in the game to begin with, and here’s a novel idea: why don’t we include children into decision making process in what activities for them to participate.

I also want to share another epizode from one of my former lives. I witnessed a game between two clubs – twelve or thirteen year old boys – and one team was dominating. You know what the winning team members were telling each other after every scored goal? “Zero-zero, stay focused”. After the first, second, third, fourth, fifth, sixth, seventh, eighth, ninth, and tenth: “Zero-zero, stay focused”. That’s how they’d been taught. This is the other spectrum of domination: it’s easy to relax and become susceptible to great comeback by the other team. Needless to say, this game happened in another country.

Soccer is not just a game, it’s life in itself. Lowest lows and highest highs are all part of life and youth sports is excellent way to prepare children to adversities and fluctuations they are going to encounter in real world. Crippling these experiences however cripples and distorts kids’ expectations of the real world and in my opinion does more harm than good. Children are resilient, they recover quite effortlessly. Give them more leeway, they will be fine.

Boys U12 Fall Rodrigo’s last reply in this exchange

October 10th, 2009

This was the last Rodrigo’s reply – we did not exchange any more messages after that, just talked during practices and games.

======================

Good for the game this Saturday. I was told it was good. As I have said so many times you are doing a good job. But I think I can also contribute and I would like that you let me.

Well, if the goal is to create information, here I go.

First. After your first reply, I was quite pissed (I am being honest ). I was expecting a reply saying that you will/may consider my comments and you will/may try to implement something in that regard. And receiving an email saying that what I was thinking was plain wrong and your thinking is the best way was not expected, to say the less. I know you are stubborn, and if you know that too,  then it will be good to do something about it. Your second email is better, I am being ask what I think. Then I feel I can have other contribution to the team other than just play when you need an extra player.

Second, my comments to the rest of the message are below.

> O boy that was a long response to two short comments.

Sorry to subject you to this – the lenght and expanded explanations are mostly for the site (and this includes this response as well :-) Content is the most valuable commodity of the internet, I am just using this opportunity to accumulate some). I think I am going to register a site for all this pretty soon, want to be in on this? We can brainwash and conquer the world :-) You will write articles and I will count the money… Seems fair :-)

R> Getting rich?!, I like that. I’ll  then keep writing. <R

> I consider myself a teacher.

Here’s an article, which defines two main styles of coaching, you may want to check it out:

http://www.bettersoccermorefun.com/dwtext/firstsea.htm

R> So which one you consider yourself, Street soccer model or PE teacher? Do you agree with the article? I think this is biased toward the Street soccer model. I think a combination of both will be a better approach. Some discipline form time to time is not bad, and the freedom of experimenting should always be there. <R

> We can let them play and play and yes anybody may eventually get it. It took me about 25+ years to understand some basic techniques in soccer and many I still do not get.

This is excellent point: check out the first sentence and bold highlights from here:

http://www.bettersoccermorefun.com/dwtext/thecoach.htm

R> Agreed, we are just facilitators. <R

> Now about the talk to the kids, you really underestimate them.

Maybe :-) I think it’s mostly about degree of efficiency: in my opinion, it’s more efficient to do the “kite” exercise (http://www.mayouthsoccer.org/download/722_u12_attacking_shape_individual_small_groups_units_.pdf) for ten minutes than have a talk on team shape for roughly the same amount of time, and if that’s the case – then playing should be favored.

R> Absolutely, Nobody should give a ten minutes lecture of anything. I read somewhere that  the average span of attention was 5 minutes. In kids wanting to play soccer maybe a fraction of a minute. May be I did not express myself correctly. I like short bits of  information. For example, the three P’s: power, pressure and passing. That is not that long.  Is it? Do the kids get the meaning of all that? I am sure  they won’t  the first time the hear it. But if we keep repeating it and giving examples of when that happens they will not only get the meaning we are trying to convey but will put their own interpretation. <R

Also, I don’t believe that kids learn much during the games, majority of learning comes from practices… Ok, that first portion of the previous sentence did not come out right :-) More precisely: opportunities for coaching during the games are very limited – mostly, because of that same reason: we can only tell kids what to do

R> Here, I strongly disagree. The game is the best learning opportunity anybody has. And the game has tons and tons of coaching opportunities. One thing that Jim Jordan does that I think is great is that he is commenting about what is happening  on the field to the kids on the bench or asking to them what they think about something that just happened. That will lead to guided discovery, I think that is what some educators call it . Another way is by highlighting some of the things they just did that gave results. Most times the kids did not realize they did such thing and highlighting show it to the player the contest of what the coach is trying to transmit. <R

but they have no opportunity to go through the actual process of the learning sequence: trying it without pressure – trying it with limited pressure – and only then trying it in game conditions.

R> Who said that is the only way we learn? How many times have you learned under pressure? I think most of the time. In soccer is the same. You go on the field try something and if works, you will try to do it again.  <R

We can only coach efficiently during practices.

R> Not necessary, as I mentioned before <R

I like to have no more than two very specific stress points for a game: one per each subject for each of the practices during previous week.

R>Agreed<R

I believe in the pre-game speeches we only stressed team shape and maybe counterattack; for the second defender I believe boys are actually doing good job already so there was no need to overwhelm them.

R> And sometimes coaches do not need to mention even that. Just tell them the line up and cheer them up. <R

> clear, specific and short bits of information are perfect

This is their we disagree: definition of “short” :-) (or maybe I just misunderstand your definition). In my opinion, for this age group (U12) – short means no longer than 90-120 seconds, and that should include pre-game speeches. Anything beyond that – for kids who’d rather play than listen – will go over their heads.

R> Agreed , as I said above about short bits of information<R

> I still stand that the two things we should be focusing is position and passing. [snip] Some time ago you mentioned that you have set goals for the season. Could you share those with me?

Positions are good – and we are going to get there. The problem is that I think we need to build up basis for positions: I don’t want to put boys in a formation and tell them: “this is your spot”. On that http://www.bettersoccermorefun.com site there is a quote somewhere: “Americans play fast but think slow”, I think this is precisely why: from the very beginning kids are taught to do different jobs on the field, e.g., “play your position”, they learn to do it and they do it well – it’s easy to do the same thing over and over even if you don’t understand why you are doing it. Later, however, when put in different situation (let’s say, formation changes from 3-3-1 to 2-3-2) they get lost: they need to be taught again what to do.

R>Agreed too, I am agreeing to too much. I should make up some disagreement to keep building up that web page or yours ;-) . Nobody should be in one spot all the time. This kids are too young to be assigned a spot, including goalies. But keep the same formation may not be bad idea as long as all the players play all the positions of that formation. That way they do not have to absorb all that information at each game and they still get the flexibility of playing different spots, switching and moving around<R

The way to avoid it I believe is to build up tactical mentality from ground up (not just for this group – for the complete development progression of a youth player): a soccer player needs to gradually learn what to do alone with the ball (first attacker), how to play in twos (second attacker), how to play in threes (third attacker), and the diamond shape (1-2-1 formation in a 4 v 4 small sided game). If they can master that – in my opinion they will be able to move from formation to formation effortlessly, and that’s what I am aiming for in general.

For this specific season, I want the boys learn how to be comfortable playing in twos (first attacker – second attacker), that’s all. If they can do that by the end of the last game – from tactical standpoint I will consider this season success. We actually did not address this in targeted fashion yet – mostly we spent time on defense so far. As you wish (and actually – according to the grand plan :-) ) – we will be doing first a – second a predominantly through the remainder of the season, and this will inolve plenty of passing.

Same for the defense: I want them to play first defender – second defender comforably by the end of the season.

R> I agree, it is a good goal for the season:  Lear to play in two either as defenders or attackers. But as you pointed out, it will require to know their passing and they position. <R

From the team play perspective, I want to do one or two more practices on the diamond shape – same as we did already – and also want the boys to start learning how to play counter attacking style (if you did not see it yet – now is the time: http://www.bettersoccermorefun.com/dwtext/countera.htm). If you read carefully – and compare to the other – playmayking – style of play – you’ll notice that “kicking aimlessly” has technical term: “relief of pressure” and is acceptable in counterattacking style. It’s the distinguishment of

R> Relief of pressure is good but only when necessary and not 90% of the time. The parents already encourage the kids too much to kick that ball as hard as they can. Our job is now to put more meaning to those kicks. I would like them to try to control that ball instead of just trying to get it as far as possible from them. Sometimes it looks like the kid is not really trying to prevent the ball from getting to the goal but the ball from getting to close to them.  <R

moments when to relief pressure and when to switch to the counter what the boys need eventually to figure out but I do not plan on having lots of talks on this with them, for now it’s good enough that they experience this method of play. Also, I like the counter attacking style because it teaches discipline and mental toughness: it’s tough to be on defense most of the time, you need to develop mindset, coolness, and steady heart for that

Final note :-)

After this last game and seeing how boys shifted to the positions they played earlier in the game I now tend to think that it would be good for them to stay in one area for the entire game and only switch their place from game to game. What do you think? Also, on formations – I don’t want to pick one over another: these things are situational and same as playing all positions boys need to be comfortable in any formation.

R> The kids could change positions if they know what each position has to do. If you keep one formation they will soon enough recognize each function and play accordingly. You do not have to pick one formation for all the season but do not change that from game to game or during the game. Otherwise they will not find the meaning of formation. This is what happened during our Reading game..

Let us be clear how the formation will change and how they will need to adjust.  Let’s have two formations and no more. It is the same with the goals you set for the season. You set only a couple and I do agree with that. <R

If you remember – so far we tried four formations total: 3-2-2 with flat mid – flat forwards, 3-2-2 with tandem of forwards, 3-3-1 with a sweeper and dropped center mid and free forward, and 3-3-1 with dropped side backs, advanced center d, and advanced center mid + free forward. The more defensive 3-3-1 ones we played against Lowell – probably the best team in our division, – and Reading – good team with us having just one sub so our boys needed extra insurance back. Most likely, we are going to play more offensively against Melrose – just because they are not a good team according to the standings. And yet another reason for the changes is that I want to experiment a little :-) So – as you hopefully see – we really cannot select one formation for the season and stick to it :-)

R> Read the first three lines of the paragraph. That is just too much variation to understand: Flat mid, flat forwards, tandem, sweeper, dropped center mid, etc. That is just too much.  Soccer after all is quite simple, why do we need to make it complicated? <R

I hope I don’t bore you to death with all this…

R> I hope I don’t do the same. Take care and see you next week.

Rodrigo

Boys U12 Fall season goals, or second response to Rodrigo :-)

October 10th, 2009

> O boy that was a long response to two short comments. [full message]

Sorry
to subject you to this – the lenght and expanded explanations are
mostly for the site (and this includes this response as well :-)
Content is the most valuable commodity of the internet, I am just using
this opportunity to accumulate some). I think I am going to register a
site for all this pretty soon, want to be in on this? We can brainwash
and conquer the world :-) You will write articles and I will count the
money… Seems fair :-)

> I consider myself a teacher.

Here’s an article, which defines two main styles of coaching, you may want to check it out:

http://www.bettersoccermorefun.com/dwtext/firstsea.htm

>
So if I see something that I can help improve, I’ll try to address it

We agree on this :-)

>
We can
let them play and play and yes anybody may eventually get it. It took me about
25+ years to understand some basic techniques in soccer and many I still do not
get.

This is excellent point: check out the first sentence and bold highlights from here:

http://www.bettersoccermorefun.com/dwtext/thecoach.htm

> Now about the talk to the kids, you really underestimate them.

Maybe :-) I think it’s mostly about degree of efficiency: in my opinion, it’s more efficient to do the “kite” exercise (http://www.mayouthsoccer.org/download/722_u12_attacking_shape_individual_small_groups_units_.pdf)
for ten minutes than have a talk on team shape for roughly the same
amount of time, and if that’s the case – then playing should be favored.

Also,
I don’t believe that kids learn much during the games, majority of
learning comes from practices… Ok, that first portion of the previous
sentence did not come out right :-) More precisely: opportunities for
coaching during the games are very limited – mostly, because of that
same reason: we can only tell kids what to do but they have no
opportunity to go through the actual process of the learning sequence:
trying it without pressure – trying it with limited pressure – and only
then trying it in game conditions. We can only coach efficiently during
practices; games are for showing off the skills that boys learned
during the week. That’s actually why I like to have no more than two
very specific stress points for a game: one per each subject for each
of the practices during previous week. We somewhat got screwed by this
make up game this week – it’s been three practices without a game, but
if you noticed – here were the subjects: second defender, team shape,
counterattack. Those were the points to watch in the last game – but we
did not even mention all of them to the boys: I believe in the pre-game
speeches we only stressed team shape and maybe counterattack; for the
second defender I believe boys are actually doing good job already so
there was no need to overwhelm them.

> clear, specific and short bits of
information are perfect

This is their we disagree: definition of “short” :-) (or maybe I just misunderstand your definition). In
my opinion, for this age group (U12) – short means no longer than
90-120 seconds, and that should include pre-game speeches. Anything
beyond that – for kids who’d rather play than listen – will go over
their heads.

> I still stand that the two things we should be focusing is
position and passing. [snip]
Some time ago you mentioned that you have set goals for the
season. Could you share those with me?

Positions
are good – and we are going to get there. The problem is that I think
we need to build up basis for positions: I don’t want to put boys in a
formation and tell them: “this is your spot”. On that http://www.bettersoccermorefun.com

site there is a quote somewhere: “Americans play fast but think slow”,
I think this is precisely why: from the very beginning kids are taught
to do different jobs on the field, e.g., “play your position”, they
learn to do it and they do it well – it’s easy to do the same thing
over and over even if you don’t understand why you are doing it. Later,
however, when put in different situation (let’s say, formation changes
from 3-3-1 to 2-3-2) they get lost: they need to be taught again what
to do.

The way to avoid it I believe is to build up tactical
mentality from ground up (not just for this group – for the complete
development progression of a youth player): a soccer player needs to
gradually learn what to do alone with the ball (first attacker), how to
play in twos (second attacker), how to play in threes (third attacker),
and the diamond shape (1-2-1 formation in a 4 v 4 small sided game). If
they can master that – in my opinion they will be able to move from
formation to formation effortlessly, and that’s what I am aiming for in
general.

For this specific season, I want the boys learn how to
be comfortable playing in twos (first attacker – second attacker),
that’s all. If they can do that by the end of the last game – from
tactical standpoint I will consider this season success. We actually
did not address this in targeted fashion yet – mostly we spent time on
defense so far. As you wish (and actually – according to the grand plan
:-) ) – we will be doing first a – second a predominantly through the
remainder of the season, and this will inolve plenty of passing.

Same for the defense: I want them to play first defender – second defender comforably by the end of the season.

From
the team play perspective, I want to do one or two more practices on
the diamond shape – same as we did already – and also want the boys to
start learning how to play counter attacking style (if you did not see
it yet – now is the time: http://www.bettersoccermorefun.com/dwtext/countera.htm).
If you read carefully – and compare to the other – playmayking – style
of play – you’ll notice that “kicking aimlessly” has technical term:
“relief of pressure” and is acceptable in counterattacking style. It’s
the distinguishment of moments when to relief pressure and when to
switch to the counter what the boys need eventually to figure out but I
do not plan on having lots of talks on this with them, for now it’s
good enough that they experience this method of play. Also, I like the
counter attacking style because it teaches discipline and mental
toughness: it’s tough to be on defense most of the time, you need to
develop mindset, coolness, and steady heart for that.

Final note :-)

After
this last game and seeing how boys shifted to the positions they played
earlier in the game I now tend to think that it would be good for them
to stay in one area for the entire game and only switch their place
from game to game. What do you think? Also, on formations – I don’t
want to pick one over another: these things are situational and same as
playing all positions boys need to be comfortable in any formation. If
you remember – so far we tried four formations total: 3-2-2 with flat
mid – flat forwards, 3-2-2 with tandem of forwards, 3-3-1 with a
sweeper and dropped center mid and free forward, and 3-3-1 with dropped
side backs, advanced center d, and advanced center mid + free forward.
The more defensive 3-3-1 ones we played against Lowell – probably the
best team in our division, – and Reading – good team with us having
just one sub so our boys needed extra insurance back. Most likely, we
are going to play more offensively against Melrose – just because they
are not a good team according to the standings. And yet another reason
for the changes is that I want to experiment a little :-) So – as you
hopefully see – we really cannot select one formation for the season
and stick to it :-)

I hope I don’t bore you to death with all this…

—– Original Message —–
From: Rodrigo
Sent: Saturday, October 10, 2009 12:00:04 AM GMT -05:00 US/Canada Eastern

Subject: RE: Boys U12 soccer game this Saturday

O boy that was a long response to two short comments. 

Well here goes my not that long response ;-) . I do agree on most
things you said. Specially with the game is the best teacher. But I also
believe that we should learn from what we do, whatever that is, soccer or
anything. And teachers are there to help us learn. I consider myself a teacher.
So if I see something that I can help improve, I’ll try to address it. We can
let them play and play and yes anybody may eventually get it. It took me about
25+ years to understand some basic techniques in soccer and many I still do not
get. But if we can show and make the kids learn more and as consequence have
more fun, why not do it. And of course, when we play stronger teams we will see
our weakness and that is when we really get to learn. And then, we need to adjust
our plan. Are we going to change our plan every week after each game? Of course
not, but we should be flexible enough to allow some change. 

Now about the talk to the kids, you really underestimate them. I
think most kids will listen and they will try to improve accordingly, specially
at this age. When they get to U14 and up, most kids think they know better. We
should not get them hour long lectures, but clear, specific and short bits of
information are perfect. Repeat those often and they will sure try, learn and
remember. 

Patience, patience, I consider myself a patience person. But I also
feel emotions and I think that as long as I express them within a healthy level,
they are good for the team. Most kids are trying to please some grown up,
parent and coach. And seeing their coach sharing the emotion with the team is
very good. 

Enough of coaching philosophy. 

I still stand that the two thinks we should be focusing is
position and passing. And that includes teaching the kids who take the position
to heart (i.e. Brendan) that is not only ok but he is encourage to move to and
cover other areas but show them when or how. Will they get it at the first
practice and scrimmage? Most likely not. But three or more practices, many will
sure get the concept and then it is just practice.

Some time ago you mentioned that you have set goals for the
season. Could you share those with me?

Take care you too,
Rodrigo

 

Patience coaching, or response to Rodrigo :-)

October 9th, 2009

Hi Rodrigo :-)

> I also wanted to mention two things I did not like yesterday about the way we played… [full message]

Oh, boy, this is gonna be long (on a bright side, I can post it to my
private vault :-) ) Just don’t take it the wrong way, ok? I do realize
that I am quite stubborn. Also, I am going to inflate this piece
somewhat intentionally – with the web site in mind: I expect it to be a
big hit with millions of people visiting every day, making me one of
the fortunes :-D So with all that in mind – here it goes.

I
firmly believe that at this age (and for quite some time, until they
really become more mature) any amount of talk will have very limited
effect. You need to remember that these are not adults, these are kids,
and normal kids at that: their interests, dedication, and ability
levels vary, and there is nothing wrong with that. At this age, proper
soccer learning can only be achieved through repetitions and
scrimmaging during practices, there is simply no way around it: that’s
what “game is the best teacher” means.

In this specific case of
breaking formations – there is really no surprise: all in all, we only
had one (that’s _one_) practice so far, dedicated to team shape. We
will likely have another one but this is way too little to expect
results of any significance during this season.

Also, let’s take a closer look at who stuck to their places and who ran wild :-)

John:
played center mid first half – stayed in position with emphasis on
defense (what we asked), second half – when we tried to move him to
forward – he ran wild as if still playing center mid. Strangely enough
- that’s what he was in the first half :-) Also – see comment below for
Donovan, it applies to John as well.

Donovan – well, he always
runs around :-) On the other hand, at my E license course, when playing
a game for the team shape subject, the coach caught me in the position
of deep left defender while I was supposed to play right forward – I
couldn’t be farther on the field from where I was supposed to be if I
tried :-) The point is: even for adults, it’s quite common for stronger
players, who assume and accept responsibility for the entire team, to
run all around the place, and Donovan is a prime example of this rule.

Todd
- was right mid in the first half – stuck to his place (and he is a
lefty mind you – that was double tough for him). In the second half we
put him into left defense – he shifted to the right side immediately.
Once again – that’s where he was in the first half :-)

Derek – mostly, stuck to his place all the time (left mid, left d, center mid, right d)

Brendan – he is overcommited to the “position” concept; with him – I would be happy if he ran wild once in a while.

Alvaro – stuck to his place all the time (center d, left d, right mid)

Paul – stuck to his place (right d, left mid, center mid).

Jonathan – mostly, stayed in his place, but he is a special case.

Ryan – strangely enough, being a keeper – stayed in his place :-)

So
if you take a look at the overall picture, it was just two or three
guys who were running wild at any given time, and when they did – it
was usually because they tended to shift to places, where they played
for full thirty minutes just a few brief moments earlier. I think that
overall the boys held their shape in the first half extremely well. The
only goal that we conceded in the first half was defensive breakdown in
very tight space against very good forward: our first defender (I can’t
remember who it was – I was watching where this play was about to go)
applied perfect pressure in the corner but got beaten, and Paul was at
the proper distance in position of the second defender and was almost
in the proper place – but he was about two-three yards too high from
where he was supposed to be. After their #45 (their best player,
remember?) beat our first defender in the corner – he accelerated past
Paul and then – shifted to center to open himself for a shot. From
beginning to the end, that was very insightful play by the boy, who has
abilities to execute. We really had no chance after our first defender
got beaten – and that happened good ten-fifteen seconds prior to the
striker finishing the play. Two yards – that’s all that made the
difference in that situation, because otherwise Paul would be in
position to delay for help to arrive.

In the second half – you
are right, they did break down more often than one would desire but
that’s what fatigue does to you: thought processes slow down and you
need to spend extra effort to stay focused, and ability to control your
mind when fatigued is one of the most difficult things to master; at
amateur level – few adults can do that successfully, we can’t be too
hard on the kids in this case.

With your second point – you need
to remember that the first two games were against weaker opponents.
With the last two – the opposing teams were stronger and that resulted
with our boys having less time at any given moment to make soccer
decisions: when to pass, when to dribble, how strongly to kick the ball
for passes, how far to dribble, how closely to approach defenders, what
distances to keep when receiving passes, etc. We as adult players take
all these things for granted – but you need to remember that all these
things are obtained through practical playing only, no amount of talk
can teach you to approach a defender at the perfect distance such that
he is already engaged but still does not present immediate threat, and
then to make a pass to a supporting teammate with the proper pace.
Player’s mind needs time to examine, process, and calculate
possibilities for every little situation in order to make good
decisions; when versing better opponents, whose speed of play is faster
- which means that they apply pressure faster than boys are accustomed
to, – this time to make decisions is significantly shortened, which
amounts to lesser quality of play. Again, all this is expected :-) We
had just two practices on short passing – plus the team shape practice,
which can count as another one – but still that’s not enough.

So
let’s just try to relax and be patient: these kids have their entire
lives in front of them to learn all this – that is, if they choose to
continue playing soccer :-) (this age is approximately when most kids
decide whether to drop out or not). Also, as a side note – patience is
one of the most difficult things about coaching therefore one really
needs to make conscious effort to contain himself: above all, kids need
playing experience, you cannot teach that. Sometimes, this may give us
helpless feeling of not being able to control situation, but this kind
of feeling is usually false: we provide plenty of playing
possibilities, and sometimes – however rarely, discretely, and
selectively, – boys even remember some of the things that we say. This
is really all that there is to coaching in my opinion :-)

—– Original Message —–
Sent: Friday, October 9, 2009 2:41:16 PM GMT -05:00 US/Canada Eastern
Subject: Re: Boys U12 soccer game this Saturday

Hi Vyach,

I may not be there but Alvaro will. We also are going to the Revs game. Are you coming?

I also wanted to mention two things I did not like yesterday about the way we played.
1)
Poor formation: You give them clear directions of what they should be
doing and very few players kept to their positions with several just
running wild. I appreciate the effort but we have to move to the next
technical level. So I’ll suggest to pick a formation: 3-2-2, 2-3-2 or
anyone you like and from now on stick to that one. Every kid will play
all positions but every position will be well defined. From there we
can learn to switch and cover and all that.

2) Too many kicks to
nowhere or holding the ball too long. In the first two games, we saw
lots of great passes and it seems that we are starting to loose that.
Let’s talk to them about the importance of kicking the ball to some one
before the game and then run a couple of practices to address it.

Take care,
Rodrigo

3rd attacker practice plan (pdf)

September 18th, 2009

This was what I came up with for home assignment for my E-license course: 3rd attacker practice plan (pdf)

You can see nice summary of 3rd attacker principles here: http://www.thesoccerhelper.com/pages/coaching/principles-of-play.php