"Programming: Principles and Practice Using C++"

"Programming is learned by writing programs."
-from the Preface page xxv of Stroustrup's new book on programming using C++.

Programming: Principles and Practices Using C++
by Bjarne Strousrup.

So far the first impression of the book, built from browsing and skimming, is that one could learn the essentials of programming and software construction while using the C++ languages. The book is based on a first year course that Stroustrup taught at Texas A&M University. It appears a lot of work and thought has gone into the course and book.

This is not a typical text book as Stroustrup says, "No. This is not a traditional Computer Science 101 course. It is a book about how to construct working software. ...... It is about programming (or more generally about how to develop software), and as such it goes into more detail about fewer topics than many traditional courses."

I look forward to studying several of the book topics that I have never really used or fully looked at while developing software. As a text book about programming then this may be an excellent book about programming and learning C++ at the same time. We will see how it goes as I work through the book.

Python For Scientists and Engineers: Recent Class

Steve and I took a three day class that ended up being a survey of what is available for scientists and engineers using Python. The instructor did point out a good number sites to look at for scientific software bundles in Python.

One the most interesting sites pointed to was Python(x,y) which has bundled a number of tools (mostly python) into one package that was right up our alley on the MCATK project we are working. Python(x,y) is free and all the packages bundled under it are free-ware.

Python(x,y) has downloads for two platforms so far. Windows and Ubuntu. I have downloaded the Windows version (full setup) onto two different machines and it has installed perfectly and easily.

Python(x,y) provides a small window with menus and buttons that serve up the various packages it offers. Some of the packages Eclipse, Qt, MayaVi, SciTE, IDLE, gnuplot, Python, and IPython. There are Python modules for numpy, scipy, numexpr, sympy, matplotlib, pylab, and VTK to name a few. There is easy access to documentation for all of these packages and more.

You can easily launch Eclipse from the Python(x,y) window and turn around and launch the IPython command line window too. Also in the bundle is the Spyder the interactive software development environment.

For us one nice thing is that Eclipse already has plug-ins for CDT(C++), Python, and PyDev (unit tester). This way since we already do development with Eclipse and C++ then we can now easily do any Python work within the same IDE with unit testing. Unfortunately it is only available for Windows and Ubuntu at this time.

Also downloaded is the Photran plugin for Fortran development under Eclipse. Not that we need that.

Another site pointed out to us was EnThought which has some prebundled Python tools. The bundles are not free but all the packages under them are free. So you could download them yourself if you did not want to pay. The site is a great resource for scientific computing.

All in all it seems that Python would be fine choice for many scientific computation needs. Less so for the HPC we are doing at LANL but it certainly come in handy as another tool in our toolbox. One suggested use of Python and all the available tools was as a replacement for MatLab since all the Python tools are free. Definitely a possibility especially for students.

Recently, Neopythonic (Guido van Rossum) has an interesting post about Python in the Scientific World. Check it out.

Python Reference Page

Python Reference Page will be added to as newer, useful reference are discovered.

---

• Dive Into Python
  
• Agile Testing: Python unit testing
• Python (Wikipedia)
• Python (python.org)
• Python (getting started)
• Python (IDEs)
  
• PyDev (plug-in for Eclipse)
• PyUnit (Python xUnit testing framework)
• PyUnit Related Link
• High Performance Development with Python
• Numeric And Scientific Python
• Getting Started With SciPy
• Python(x,y) (Python for Scientists ... nice package)*
• Scientific Python (Looking for scientific packages? Be sure to look here before deciding)
  

Wolfram Demonstrations Project

Mathematica is a very useful and powerful tool for learning, teaching, and doing simulations. Recently, I ran across a Project page which has demonstration topics in almost every field. Very cool stuff. The demos themselves can be used as templates to create your own demonstrations.

Wigner Function of Two-Dimensional Isotropic Harmonic Oscillator




There is some really cool stuff ... check it out.

Wolfram Demonstrations Project

Favorite Scientific Biography: Rabi

Back in around 1988, when I started graduate school, I decided to subscribe to a weekly science news magazine which I have now forgotten its name. Inside each issue was an advertisement to join a science book club that I could not resist. Upon joining this book club you get a complimentary book.

One day in the mail I received a biography about Isidor Rabi called Rabi: Scientist and Citizen by John Rigden as my complimentary book. I had no idea who Rabi was and was not really interested in the book. So it sat on my shelf for several years then one day I decided to read the book.

It has ever since been my favorite biography about a scientist and has not been displaced after all these years.

Some highlights of I.I. Rabi incredible life and influential work:

• One of the first to apply the Schrodinger wave equation to the symmetric top which is a common model for molecular spectroscopy.
• Visited Europe in the last 1920s and learned from Bohr, Sommerfeld, Pauli, Stern, Heisenberg, and more.
  
• Was considered a theorist but lead experimental work for most of his career.
• Did extremely accurate molecular beam experiments.
• Designed and lead the first nuclear magnetic resonance methods.
• Measured accurately the proton and deuteron magnetic moments.
• Discovered that the deuteron has a quadrupole moment which changed the whole picture of the nucleus.
• Worked at the Rad Lab on war time radar
• Was consultant to Los Alamos and Oppenheimer during the WWII.
• Was present at the Trinity test.
  
• Won the Nobel Prize in 1944 "for his resonance method for recording the magnetic properties of atomic nuclei."
• Proposed the atomic clock.
• Contributed to the discovery of the intrinsic moment of the electron.

There was so much more to Rabi than I have listed here. I highly recommend this biography that is hard to put down once you get started.


Rabi, Scientist and Citizen (Google Books)

Simulation Models

In scientific computing, we often are looking to model physical processes through computer simulation. Though generally computational scientists (physical scientists that is) are performing this work, often this simulation and modelling is not done in a very systematic or scientific way. This has been an issue for computational science since the inception of the computer.

This challenge was recognized many decades ago and was the driving force in John Pople's computational quantum chemistry research. Though Pople's chosen field was quantum chemistry, we would do well to learn from his approach to modelling for our chosen fields of research and study.

---

Here in general terms and for an outline of development and use of a model (from Pople.)

A theoretical model for any complex process is an approximate but well-defined mathematical procedure of simulation.

......

Five stages may be distinguished in the development and use of such a model:

1) Target
2) Formulation
3) Implementation
4) Verification
5) Prediction

---

Now an explanations of these stages from Pople's quantum chemical models:

1) Target
A target accuracy must be selected. A model is not likely to be of much value unless it is able to provide clear distinction between possible different modes of molecular behavior. As the model becomes quantitative, the target should be that data is reproduced and predicted within experimental accuracy. For energies, such as heat of formation or ionization potentials, a global accuracy of 1 kcal/mole would be appropriate.

2) Formulation
The approximate mathematical procedure must be precisely formulated. This should be general and continuous as far as possible. Thus, particular procedures for particular molecules or particular symmetries should be avoided. If this can be done, the procedure becomes a full theoretical model chemistry, which can be explored in detail as far a available resources permit.

3) Implementation
The formulated method has to be implemented in a form which permits its application in reasonable times and at reasonable cost. In recent times, this stage involves the development of efficient and easily used computer programs. It is closely comparable to the stage of building equipment in an experimental investigation.

4) Verification
The next step is to test the model against known chemical facts to determine whether the target has been achieved. If quantitative accuracy is being sought, this can be done by various statistical criteria such as the root-mean-square difference between the results of the theoretical model and experimental data. In selecting such a dataset, it is important to make it as broad as possible, while limiting it to experimental facts known to be of high quality. If the results of such a comparison do meet the target requirements, the model may be said to
be validated.

5) Prediction
Finally, if the model has been properly validated according to some such criterion, it may be applied to chemical problems to which the answer is unknown or in dispute. If the experimental dataset is sufficiently broad, there is a reasonable expectation that the results will be accurate to something like the target accuracy. This stage, of course, is the one of
most interest to the larger chemical community.

From - Nobel Lecture: Quantum chemical models by John A. Pople.
Reviews of Modern Physics, Vol. 71, No. 5, October 1999, page 1287.

---

As a computational scientist, all the stages should be of interest. As a scientific software developer then stages 3 and 4 are of the most interest though often all stages cross our path. Particularly stage 3 where often we as scientists are building our experimental apparatus (computer software) for the experiment ( computer simulation.) Interestingly enough as scientists we often do not build our software to the same standards we build our experimental equipment. Why? I am still trying to formulate the reasons we often seem to lose our scientific training when it comes to scientific software and computation.

Pople On Dirac's Famous Remark

The Schrodinger equation is easily solved for the hydrogen atom and found to give results identical to the earlier treatment of Bohr. With inclusion of the relativistic corrections via the Dirac equation, almost perfect agreement was found with experimental spectroscopic data. However, exact solutions for any other system was not found possible, leading to a famous remark by Dirac in 1929:

"The fundamental laws necessary for the mathematical treatment of a large part of physics and the whole of chemistry are thus completely known, and the difficulty lies only in the fact that application of these laws leads to equations that are too complex to be solved."

This was a cry both of triumph and of despair. It marked the end of the process of fundamental discovery in chemistry but left a colossal mathematical task of implementation. In retrospect, the implied finality of the claim seems excessively bold.

In 1929, there had only been one preliminary approximate quantum-mechanical calculation on the hydrogen molecule by Heitler and London, leading to a value of the bond energy of only about 70% of the experimental value. Nevertheless, the physicists were highly confident and most moved on to study the internal structure of the nucleus during the 1930s. In fact, their boldness was apparently justified, for no significant failure of the full Schrodinger-Dirac treatment has ever been demonstrated.


Nobel Lecture: Quantum chemical models
John A. Pople
Reviews of Modern Physics, Vol. 71, No. 5, October 1999, page 1287.

Where Is Software Development Really Learned?

Back in April, Bob Martin of ObjectMentor wrote a blog post, entitled “Master Craftsman Teams,” about software development, team structure, and “maybe this is where Agile got it wrong.” It came out on April First and was a good bit of a departure from Agile and XP which Bob has been a major proponent for as long as anyone. Some would even say the post was anti-Agile.

The controversial post generated a lot of reasoned and well thought out responses. It was described by one commenter as, “a thought experiment.” I would tend to agree. Sort of a “let's shake up the status quo” and see what falls out.

Martin's post was very similar in spirit to an essay written by Peter Gill about density functional theory (DFT) called “Obituary: Density Functional Theory (1927-1993).” Peter’s essay style was like… well an obituary, with a bit of tongue in cheek fun, and was intended to generate discussion about DFT and hopefully provide a jump start to physicists and chemists on atomic and molecular theory. Though in his essay, Peter did not propose a new direction as Bob Martin is doing in his post.

Bob proposes, as his title states, a team of craftsman for software development. This team would have at its center a Chief (Master) Programmer along with several Journeyman programmers and several Apprentice programmers per Journeyman. Bob gives the background for this proposal and describes the basic responsibilities within this hierarchy, the cost benefits, and where to find the apprentices for this craftsmanship. Though I disagree with Bob on several of his points, which I will not address now, he has some very interesting points.

In the article Master Craftsman Teams, I feel the real point that really came out of the post and comments was, “Where is software development really learned?” In school …. On-the-job … self-study, or where?

Unfortunately, in the end I think it is primarily a combination of on-the-job and self-study. As for myself, since I have an applied and computational physics background, then I know it was through on-the-job training and self-study. And, except for a few good exceptions, the work environment was not conducive with learning good software development. Many of the experienced scientific programmers just were not interested in improving their skills for software development. They reached a point and said it was good enough or had other issues to on their mind. Thus often many who are learning under them are content not to grow far beyond their mentor.

Now, I naively thought I was just learning the hard way what C.S. students already knew. But the more I interacted with C.S. students the more I realized that often many of them did not learn it in school either if they learned it at all. My guess is they learning it the same way I am learning it except their surroundings may be a better learning environment.

This leads me to believe the sooner a developer gets real hands-on experience developing software the better. Especially with people who care about software development and continually improving at their craft. This is why I am beginning to think internships and mentoring programs within the software industry and concurrently with formal education is really important.

Here at Los Alamos National Laboratory, there are student mentoring programs for high school through graduate school. There can be perfect opportunities here for those who want to do scientific programming. The real problem is hooking up with folks who do not want to rest on their software development laurels but who really want to be better developers and continually grow.

The sooner you start learning and caring about software development the better. And you do not have to wait for school, internships, or a job. There is a lot of information on the internet to start reading about and learning to prepare you for that first internship or job. Just care enough to do it.

Also see Steve McConnell's blog Chief Programmer Team Update that sheds more light on the IBM development in the 60's.

"For the CPT model to work, the Chief Programmer doesn’t have to be 10x as productive as the worst programmer. He has to do the work of eight or nine people put together, which means he has to be 10x as productive as the average programmer, not 10x as productive as the worst. That’s a very tall order" - Steve McConnell

Beck: Thought on Design Cost

"Design isn't free. ... When you put more design in today, you increase the overhead of the system. There is more to test, more to understand, more to explain. So everyday ... you pay a little design tax."
- Kent Beck's Extreme Programming Explained.

With more experience this is becoming truer and truer. As the design gets more general and seems to be preparing for potential future needs then there is more to test, understand, and explain. And yes it is that simple. That is not even counting the cost of the thought and white board time ( meaning less coding time ) going into the extra design.

Is it often worth the cost?

I am beginning to think not necessarily. Maybe the YAGNI question needs to be applied more thoughtfully to design and design decisions.

Scott Meyers: Good Library Design

Some principles that make for better libraries:

• Make classes and functions easy to use correctly, hard to use incorrectly.
• Obey the principle of least astonishment.
• Avoid gratuitous incompatibilities with the built-in types.
• Use const whenever possible
• Avoid duplicating code.

Scott commented that the first principle listed is a "Hallmark of a professionally designed library."

And the for the third principle listed, "When in doubt, do as the ints do."

This is from material and notes taken at the 2002 C++ Seminar in Boston during the session about Library Design and the C++ Standard Library by Scott Meyers.

These still seem like sensible principles to keep in mind as one develops code.

VAX/VMS

Recently, I found another blast from my past. I used this VAX/VMS book to write many of my DEC Command Language (DCL) scripts back while at Texas Tech in the late 80's and early 90's. I really enjoyed VMS and DCL. Tech, like many universities back then, had DEC systems for mainframes and even the physics department had a MicroVax.




I liked DCL over Unix script languages since DCL used command and keywords that made sense. Unix which uses "grep" for a search command whereas DCL used "search." Tell me which one is intuitive to remember? Of course grep is probably more powerful.




Recently I was lamenting about the VAX/VMS and found out that the cancelled F-22 fighter used the VAX/VMS OS! This was pleasant surprise. Cool.

IBM: Assembly Language Programming

WARNING: If you easily get distracted and go off on tangents then this blog post is not for you. Please browse to another place on the internet and be content.


While visiting my Mom this last week I found one of my Dad's IBM Assembly Language books upon the bookshelf and decided to bring it home for safe keeping and to explore it a bit.

Assembly Language Programming for the IBM Systems 360 and 370 for OS and DOS copyrighted circa 1980 by Michael Kudlick.



An example page of part of a binary search in assembly.











Though exposed to assembler in a C.S. class and in an electronic instrumentation class, I seldom think about it anymore. Seeing this book got me to wondering about GNU Assembler. A slightly different looking assembly than IBM's but still interesting. I wonder where this all will end up ...... hmmm. ;)

You were warned, remember?

Where It All Began

My father was a computer programmer from the early 1960's until the early 1990's when he retired while in his early fifties. His journey began by learning to wire boards for an accountant after he got out of college in 1962. This skill landed him a job teaching high school data processing (or programming.) Then a year later he landed a job with General Telephone (GTE) as a beginning programmer and did that until retirement. His only programming classes were several weeks of training in the Dallas-Fort Worth area then the rest was on the job training.

Interestingly enough the replacement teacher, when Dad left the high school, ended up still being the programming teacher at the high school by the time that my sister and myself got there in the late 1970's and both of us took that class.

Other than what little (punch cards and COBOL) my Dad tried to show me about programming up until high school, this class was the first time I had a programming class. We learned BASIC on a Radio Shack TRS-80 (aka Trash-80), RPG, COBOL, and FORTRAN from a terminal connected to a state computer. I forget whether I was a sophomore or a junior when I started the class (either in 1979 or 1980.) We started off learning BASIC and then moved onto other languages of our choice from the list above. I only tried RPG and COBOL. Luckily I did not have to learn FORTRAN for a few more years and luckily stopped using it in around 1997. Interestingly, COBOL was a much more a Literate-like language which Knuth has promoted.

Our instructor made us use this form (on the left) to write out our algorithm. At the time on the TRS-80 you could type in your code and get it running. Then you either printed it out on a narrow ribbon paper or if you had a cassette tape you could save it to cassette. Then you had to type NEW to delete it from the TRS-80 and you were ready to type in another program. I would print the working code out on the ribbon paper and tape or glue it to the work sheet as seen to the left. This is the first BASIC code I wrote.



Here is a example of the ribbon print out. This was just about the longest program we wrote during the class. Most of the program exercises were simple and small. All very sequential in nature.









Looking through my notebook from this class I found an interesting exercise. It appears that the instructor wanted us to write a program to plot a sine curve and to calculate the area under the curve. What I find so interesting is the fact that at the time I had no idea what a sine function was or even the concept of the area under a curve. A few others in the class may have had a clue but not myself. Somehow I got through this class doing somethings I did not learn for another four or five years while I was in college trying to catch up to start taking some physics classes. I did not take trigonometry or calculus until several years (~1985) into college.


If you look closely enough you can see that I defined Pi as TT instead of PI. That was how naive I was in math....really.


Also note the TRS-80 is an interesting story in itself.

Now nearly thirty years later I am still at it but doing it for physics but this was where it all began.

Buksas' Postulates On Testing

After careful thought (and experience born out of his projects) about software and unit testing, one of my coworkers (Mike Buksas) wrote some "disorganized thoughts" about unit testing. I thought they were worth sharing here:

Postulate One: Tests suffer from the same, or complimentary, defects as the code they test.

Postulate Two: Stubborn determination to do the right thing badly is not a virtue.

Postulate Three: Bad code needs more tests, and needs tests more, to attain the same level of confidence.

Conclusion One: Bad tests impede refactoring, making the code harder to improve.

Conclusion Two: Testing makes bad code more correct, but less maintainable.

Postulate Four: Code must change over time, and bad code is harder to change correctly.

Conclusion Three: Determined testing can make bad code worse over time, or at least, less better than it could be.

from Local Extrema: Disorganized Thoughts On Unit Testing Software

---

I do not know about you but this sorta reflection causes me to think more about how we write unit tests and to strive to do a better job for other's sake.

Another Reason To Like Kent Beck

Kent, regarding your comment that "all methodologies are based on fear". Would I be way off if I were to guess your fear was the Change Cost Curve? -- Ben Aveling

No, my fears are more about not spending enough time with my kids, growing away from my wife, and dying young of heart trouble like my grandfather. The Change Cost Curve I know how to handle.

---

from c2/KentBeck

"I Can Sleep When The Wind Blows"

The following story, from a Kent Beck article, illustrates one reason we have enjoyed learning and doing XP.

---

Once, a farmer interviewed a young man for a job as a farm hand. One thing the young man said particularly puzzled the farmer, “I can sleep when the wind blows.” The farmer didn’t know what this meant, but the young man seemed competent and knowledgeable and so he was hired.

A few months later the farmer was awakened in the middle of the night by a thunderous wind storm. Panicked, he raced to the cot where he found the farm hand fast asleep. Shaking him roughly awake, he demanded, “We have to bring in the animals!”

“They are already in.”

“We need to fasten the windows.”

“They are already fastened.”

“We need to tarp the hay.”

“It’s done.”

After going down his list of worries and being reassured that they were already taken care of, the farmer finally realized the meaning of the young man’s puzzling statement. By taking care to finish every job and leave the farm safe every night, the farm hand could sleep when the wind blew.

The farmer went back to bed and told his wife what he had just learned. She just smiled knowingly and the two of them went back to sleep, lulled by the music of the storm.

---

The rest of the article is here: Accountability In Software Development

Tastes Great, Less Filling: Agile vs. Lean

Over the last year I have been paying more attention to Lean Six Sigma (also see Six Sigma.) Mainly because the lab has decided to move in this direction and has been having orientations and black & green belt training for employees. Recently, we discovered that our sister lab in the UK also is moving to Lean Six Sigma.

This of course always brings up Agile and Lean and are they in line with each other or orthogonal. I had read that Agile and Lean are a lot alike and that Agilist were heavily influenced by Lean.

Recent searches for more on the topic brought me to Martin Fowler's article (short) about Agile vs. Lean that I found interesting and worth sharing here. Here is a quote from it to pique your interest into reading it.

"The Poppendiecks didn't introduce lean as a separate idea, nor did they introduce lean as a published process in the style of Scrum or XP. Rather they introduced lean as a set of thinking tools that could easily blend in with any agile approach. I think of lean as a strand of thinking within the agile community, like a pattern in a rich carpet." - Martin Fowler.


On an aside....the "Tastes Great, Less Filling" was an advertising phrase that was "Made To Stick" because it has been stuck in my head for many years. Too bad I dislike beer so much. ;)

Eye Contact Is Important

An interesting study on eye contact, that was reported by Science Daily in 2002, found that:

"...people in group discussions will speak up more if they receive a greater amount of eye contact from other group members. There was no relationship between the impact of the eye contact and when it occurred."

Often participation is an issue in meetings, retrospectives, and on teams where you need more input from certain team members who are quiet and reserved. Agile has poker planning that naturally encourages everyone to participate in the estimating of stories. But for meetings and retros then it would be good to find other ways to encourage this participation.

So perhaps being purposeful in testing out this observation of eye contact would be worth trying. Maybe in the next meeting, where you want at least one person to contribute a bit more, you try making a bit more direct eye contact throughout the meeting to see if that person speaks up more than normal. I am unsure how to get other group members to contribute to the eye contact without things looking like a conspiracy but perhaps there is a way.

Persuasion: Can We Be Doing The Opposite

One of the reasons to follow TED talks is to gleam presentation ideas. But often the talks themselves are very interesting and relevant to something I am thinking about.

Often it is said that presentations are made for two reasons only. One reason is to inform and the other reason is to persuade. Put the second reason in back of you mind and hold it there for about 20 minutes for now.

The presentation by Dan Ariely called Are We In Control Of Our Decisions is not only humorous but shockingly interesting in the fact that he makes some very good points about how irrational our decision making can be if looked at more closely.



While watching this I started wondering about presentations and the affect of our presentations driving people to buy into our idea or dislike it. Or more concisely ..... persuasion.

Perhaps it is not good enough to ask is our presentation persuasive or unpersuasive but more is it actually persuasive in the in the wrong direction?

I am unclear on examples that apply to my situations at this time but it seems that being persuasive is harder if you have more than two options to explain to someone.

Agile Reference Page

In many ways Dobbing Around is meant to be a replacement for a static web page. In doing so then I will have posts as needed that are meant to be reference pages like on a static web page. Those pages will be updated as needed.

---

Agile Software Development



• Agile Manifesto
  
• Agile Manifesto Principles
  
• What Is Agile?
  
• Why Use Agile?
  
• Agile Software Development (Wikipedia)
  
  

  Agile Methodology

  
  
• The New Methodology - Matrin Fowler (Agile)
  
  
  
  • Agile Methodology: Extreme Programming (XP) (Wikipedia)
    
  • Agile Methodology: Scrum (Wikipedia)
    
  • Agile Methodology: Crystal Clear (Wikipedia)
    
  
  
• Lean Software Development
  
  
• The Criteria For Determining Whether A Team Is Agile
  
• Examing The Agile Manfesto
  
• Steve McConnell: Agile Is Falling Short Of Promise
  
• Steve McConnell: Five Questions on Agile Development
  
• Crystal Methodologies
  
• Extreme Programming (XP) Methodology
  
  

  Agile Books

  
  

  Actively Using

  
  
• Crystal Clear - Alistair Cockburn (Great overview of Agile and how to get started regardless of your methodology)
  
  "Crystal Clear does not aspire to be a best methodology; it aspires to be sufficient, in order that your team will shape it to itself and then actually use it."
  
  
• The Art Of Agile Development - James Shore and Shane Warden (Great guide to what is needed for Extreme Programming)
  
• Scrum and XP from the Trenches - Henrik Kniberg ("How we did it" white paper! A great source for a real start-to-end example.)
  
• Agile Estimating and Planning - Mike Cohen (Great for learning estimating and planning. Examples of tracking and communicating.)
  
• Extreme Programming Explained: Embrace Change - Kent Beck and Cynthia Andres
  
• Agile Project Managment with Scrum - Ken Schwaber (Slow read but some good examples and ideas on planning)
  
• Agile Retrospectives: Making Good Teams Great
  
  

  Looks Interesting and Useful

  
  
• Testing Extreme Programming
  
• Agile and Iterative Development: A Manager's Guide - Craig Larman
  
  
  

  Agile Blog Roll

  
  
• Successful Software: James Shore's Blog
  
• Suceeding With Agile: Mike Cohen's Blog
  
• Three Rivers Institue: Kent Beck Website
  
• Object Mentor Blogs
  
• Martin Fowler's Blog
  
• Agile Otter (Tim Ottinger's) Blog
• Agile: In A Flash (Langr & Ottinger) Blog
  
• Agile Thinkers (Interviews with Agile Leaders)
  
• Implementing Scrum (Great Comic Strip Inside)
  
• Test Obsessed: Elisabeth Hendrickson's Blog
  
• Alistair Cockburn
  
• Scott Ambler's Blog
  
• Agile Advice Blog
  
• Agile Team Games
  
  
  

  ---

  
  

D Programming Language

The D Programming Language developed by Walter Bright may really pick up steam when Andrei Alexandrescu's book The D Programming Language comes out (like I know anything programming languages.) See Safari Rough Cuts for the first few chapters.

So why am I posting about D? Because Andrei's book showed up on Safari Rough Cuts which my coworker/friend Steve Nolen follows. Of course Andrei is one of Steve's heroes and D is very similar to C++. There is no telling where this all might go or end now that it is on Steve's radar. But it is not like I did not tell him about it about a year ago. ;)

Actually D looks really interesting. There are several compilers out there including a GNU D compiler package. It seems there are two Eclipse plug-ins for D ..... Descent and Mmrnmhrm. Also D can interact with C++ through the C API and possibly a more complete C++ API in the near future. There is also a document generator. For more about this see D Programming Language at Wikipedia.

D has unit testing capability built in and also Design by Contract capability. For more on the unit testing then see Unit Testing in D and Agile low level programming in D. It appears at first glance that the unit testing is meant to be part of the source code but it might be used in the way of xUnit and Kent Beck. I hope so.

Note D has been influenced by many successful concepts from other languages like JavaScript, PERL, Ruby, Lisp, Ada, Erlang, and Python.

With Andrei Alexandrescu champing D (The Case for D by Andrei Alexandrescu) then it could have a Bright future. Pun intended. ;)

Also see:
Interview with Walter Bright
Tango: The Developer's Library for D

I wonder if we can get a boost-like MPI interface to D? :)

Unit Test Framework: UnitTest++

There are numerous unit test frameworks for C++ out there. The software effort that I am on uses one called UnitTest++ (aka UT++). It was designed and developed by games developers and it is open source.

The debut release post at Games From Within describes why another unit test framework, the design reasons, and its strengths & uniqueness.

UT++ practices what it preaches by being developed using test driven development (TDD) and comes with a suite of unit tests that runs automatically upon completion of the build. Not only do these tests give you confidence UT++ is installed correctly they also come in handy as developer documentation and even user examples & documentation. They are very nice examples of how one can use the framework.

UT++ is simple, lightweight, and easy to learn. If you have not used a unit test framework before then I can recommend UT++ as a place to start learning.

Boost C++ Libraries: Changing the face of C++

We have been using Boost C++ libraries (Boost Wikipedia) in our Monte Carlo Application ToolKit (MCATK) software effort. Though we had heard of it for awhile, we had not investigated it.

Thanks to a Scott Meyer's talk at SDWest 2008, one of the team decided it was worth investigating and found there were several boost libraries that could be useful and help simplify our design.

Several Boost libraries have been accepted for incorporation into both the Technical Report 1 (TR1) and C++0x. Scott Meyer's list of the five most important C++ software includes Boost and Scott has a training course for TR1 and Boost.

Quotes from the Boost home page:

"...one of the most highly regarded and expertly designed C++ library projects in the world." — Herb Sutter and Andrei Alexandrescu, C++ Coding Standards

"Item 55: Familiarize yourself with Boost." — Scott Meyers, Effective C++, 3rd Ed.

"The obvious solution for most programmers is to use a library that provides an elegant and efficient platform independent to needed services. Examples are BOOST..." — Bjarne Stroustrup, Abstraction, libraries, and efficiency in C++

A few of the boost libraries that MCATK make use of:

boost::function
boost::bind
boost::signal
boost::mpi
boost::serialization
boost::filesystem
boost::shared_pointer
boost::array


It has changed how we think about using C++ and development.