RE: [boost] Re: Customer Friendlier Boost Installation

From: Brian Braatz (brianb_at_[hidden])
Date: 2005-05-27 08:28:38

> On Behalf Of David Abrahams
> Subject: [boost] Re: Customer Friendlier Boost Installation
> 
> "Brian Braatz" <brianb_at_[hidden]> writes:
> 
> > Wild thought-
> >
> > Is there a rational way to have a "environment" checker. I am NOT a
> > bjam expert- but it would be handy if we had some cmd line program
> > that would follow spit out all the info BJAM looks for and finds.
> >
> > I am slightly half cocked in this idea, but basically it would have
to
> > be enough information that you could get a better sense for what
Bjam
> > was doing
> >
> > Something like
> >
> > C:\boost\> boostenvcheck.exe ** Enviroment Report** Python is not in
> > the path User-config.jam file is setup to use gcc, vc7.1 Etc....
> 

[David Abrahams Writes:] 
> If you're talking about user-config.jam you're talking about BBv2.
> 
> First question: how would this information help people?  They can go
look
> at their user-config.jam themselves, right?

Hmm.. My apologies for not fully explaining myself. I will explain the
concept I am speaking from FROM A GENERAL sense first, and then relate
it to boost.

BACKGROUND: I have had good success with the following paradigm:
GENERALLY, if you have app you are deploying to MANY sites and you need
to support those sites, it is extremely valuable to build a program
which analyzes the environment and spits out a report. This is useful
for both on site techs and trouble shooting over the phone.

How you build such a program is ask yourself the following questions:

1- What are the configuration assumptions my application requires?
2- What concepts does my application *assume*?

Once you have identified these, you then build an application which
allows for introspection of the environment. Generally it is usually
something that spits out a report that checks all the "assumptions" of
the tools and displays the conformance to the assumptions.

Think of this concept as "unit testing" for an environment or product.
You can also think of this as a "blood test" for a patient. :)

PRACTICE:
Generally, over many companies I have worked with, I have had a
*DIFFICULT* time getting developers under my leadership to see the value
of this thinking. The mental shift for folks with this thinking is "well
we should just make sure the systems are configured properly. What you
are saying we need to do isn't necessary. The users (or techs) need to
learn to read the docs.".

In practice I have found applying a tool like this invaluable. Everytime
I have gone through this cycle with folks, they EVENTUALLY SEE that
value. The pain of trying to support something deployed allows for
people to "feel" the value. But it is always hard to get the developers
to "go there". This is something I have yet to understand why people
have an aversion to this thinking. It can save a company's proverbial
butt by significantly reducing the down time and trouble shooting time
of an environment.

Even if you have standards, and train people, and put systems in place
to enforce those standards, chaos always finds a way of creeping in.

BOOST:
To me this is a piece that is missing that stops wider adoption. I have
taken the proposed boost profiler, added A LOT to it, integrated it into
a production application and shared the techniques and concepts with my
developers.

I have purchased the MPL and Modern CPP books for my people and have
been busy helping folks implement some modern techniques into their
designs.

I now have an entire team excited about boost. Extremely excited. Their
excitement and the time I have spent fostering that has SLOWED my
ability to get a "next cut" of the profiler out for review.

REMEMBER: I am not ashamed to recognize myself as the "Village Idiot" on
this list. I DO know more about boost and template programming than
anyone in my company, but I am in NO WAY SHAPE or form as knowledgeable
as the fine people who frequent the list.

What is interesting though as I watch this process, is I am SHOWN
CLEARLY why boost is not adopted by the normal programmer. Many things
the rest of you guys KNOW and take for granted are not easily grasped by
people. I believe this pattern forms as people get smart, the things
they see as obvious grow in complexity as they become smarter.

I noticed the other day a post where someone was NOT getting a concept,
the response to the person was basically "Documentation should not cover
things that are obvious". That struck me and I have discussed that mail
with some of the folks under my leadership, using that as an example to
discuss difficulties in communication.

I understand boost better than anyone in my company, but I have to tell
you it REALLY shows how hard this stuff is to get your head around by
watching CLOSELY someone stepping into it for the first time.

I have written several samples and have spent hours explaining
boost.function for example. This is a lib, most people might see as
"obvious" (me included).

There are obvious limits to what can be documented, and there is always
going to be a barrier to entry. With boost that barrier is huge, I
believe it to be bigger than EVEN I initially thought as I try to bring
my team up to speed on what I know.

HOW THIS THINKING RELATES TO AN ENV CHECKER IN BOOST:
On a windows box, one used to be able to run MSD.exe, which would spit
out a report for your configuration.
XP allows one to still run sysedit.exe. This program is outdated (it is
from Win3.1) but it shows you your configuration. In the old days people
us3ed these tools to better support the system.

I AM NOT a BOOST.BUILD expert. I believe the "how to think about this" I
am presenting is valid (I see it everyday working with people using
boost for the first time). I am unsure if the explicit idea is valid due
to my remaining limited understanding of boost.build.

HAVING said that here is the suggestion, reformed:

Boostenvcheck.exe become s a program which LISTS the dependencies for
your configuration. How to identify WHAT it lists requires someone more
knowledgeable than me about it's dependencies and configuration
assumptions.

Once one has this tool then, just like a general software app, one can
say to a newbie on the list "run boostenvcheck.exe" in your boost dir
and send the report to the list. 

If the report is well formed, the people on this list should be able to
scan the report and QUICKLY help someone out.

Think of this like a "blood test", it measures and reports all the
assumptions and parameters. Overtime, just like a doctor, the folks on
this list will develop an intuition for the values in the report and be
able to quickly help people resolve issues. ( SIDE NOTE: I interviewed a
Dr recently (requirements work) and he was telling me about his
intuitive sense he has gained over reading blood tests and
troubleshooting problems)

EXECUTION: (or "Finishing current tasks") :)
        I am currently working very hard on bringing what I learned
about profiling and introspection to this list. I have to take the code
I integrated with the app (conforming to internal ways of doing things)
and boostify it enough for presentation, it is also gaining scope and
functionality and being redesigned.
        I have been working for the last 6 months on the profiler and
moving that forward (not just technical, we have taken my code through
QA and put it into production). I regret this has kept me largely off
list, but it has been a huge learning experience about "actual"
introspection (not just logging or profiling- there is a deeper concept
here I am not seeing anyone else address on this list or in this
industry)

        My plan is to do this:
                - Get the profiler re-written to work alongside the
other pieces I have learned are needed
                - Get this sent out to the list so people can finally
SEE what I have been working on (there is a connection to the excellent
work John T has been working on with logging- but these two concepts are
not mutually exclusive- logging is just one piece of introspection)

                - Get some of the other pending library submissions I
have not had a chance to finish "out there" for people to see and tear
apart.
                - Get "down and dirty" with boost.build and SPEND the
time to learn that sucker. Once I have done this, I can then formally
propose an actual "working" boostenvchecker program and everyone have an
easier time "seeing" what I am talking about.

In general, I LOVE BOOST, and have devoted as much time as I can suck
out of my production world to finding ways to contribute my perspective.
I have taken to going to bed REALLY early so I can get up early every
morning and work on bringing the profiler \ tracer to boost. I am now
getting in a good 6-8 hour day prior to my work day starting. 

There are so many things I would like to contribute. I believe my
"village idiot" perspective, if executed correctly, can provide
considerable aid to people adopting boost. I just simply have to focus
enough effort to SHOW people what I am talking about. Sample code \
tools communicate better than words sometimes.

If someone "sees" what I am talking about and wants to move if forward
before I get there. ALL THE BETTER. :)

Sorry for the long response. But what I have explained for anyone
reading this is where I am coming from. Anyone who follows this will see
a consistency between this mail, past mails, and future actions.

> 
> First problem:  .jam files are programs, not just configuration, like
> .ini files.  We can't capture everything a user might want to write
> there in English.
> 
> > I have been using boost for (has it been that long) 2 years now.
Bjam
> > still confounds me. ( I appreciate the work effort, it is a cool
tool,
> > I remain struggling with it though)
> 
[David Abrahams Writes:] 
> You never post questions; how can we improve its interface and help
> you understand it otherwise?
> 

Excellent point indeed. I need to do more of this. I tend to take a LONG
TIME to learn something, once I have it, I have it well. But the first
initial barrier is tough, and my initial questions are frequently so
idiotic I don't always get the information by asking the question.

I have read the MPL book now FIVE TIMES cover to cover. On the fith
pass, I "saw it". (the mpl::for_each<> is what kicked it in for me) I
have been now writing programs using the MPL library (kudos to both you
and Aleksey- excellent body of work). Because I know I have to go
through this learning process, I work very hard up front to "see it"
enough so I can answer my own conceptual questions first.

Basically though, your advice is well received by me. I need to ask more
questions, and will do so in the future. I have a personal goal of
learning everything I can about boost as this will help me contribute.

> > (I am also a tad frustrated because I have been trying to make vc7.1
> > build wave for the last 5 hours)
> >
> > Semi-Related:
> >
> > I proposed (a long time ago) building a SIMPLE gui framework- with
> > the core elements, and then making a "boost environment checker" out
> > of that- I.e. imagine a tree control with all the types of settings
> > and what nots, and the ability to navigate this gui to try to
> > determine what is not set correctly.
> 
> Might be a good idea; we can't really know until we see one, though.
[Brian Braatz Writes:] 
YES. THIS IS THE BANE OF MY EXISTANCE. So much to code, so little time.
:) 

I realize I "come from a different place" in my thinking. And I realize
that to truly communicate what I am talking about I have to show it. I
am just frustrated than I require sleep. If I didn't need sleep I could
spend more time learning more about boost. :) 

CONCLUSION:
Dave- 
Thank you very much for your thoughts and advice. 

Everyone-
I see everyday in people I am working with the incredible hair raising
effect and energizing influence bringing boost into my dev team has had.
I am grateful for everyone's dedication to creating some incredible
works. 

THANK YOU ALL,

"The Village Idiot" :)