expatpp is a free wrapper to the also free expat C XML Parser library. Unfortunately, it doesn’t exist… or so I thought.
The sourceforge site doesn’t have any files to download, but after some fishing, I found a download which includes expatpp and a compatible version of expat here.
After removing the txt from the Makefile in expatpp/expat and running “make all” from terminal, I had a static version of expatpp, ready to go! Sort of. The makefile builds expat, the underlying library. So far, I’m simply including the single source file in my projects.
You just have to move the expat lib to the directory of your choice (there is no install target in the Makefile) and also expatpp.h & xmlparse.h (so far) where your projects will be able to find them.
God bless free software providers. But, oh how painful the installation!! After slogging through outdated documentation, this is how to download HTML Tidy through cvs on the mac.
Fire up Terminal and enter the following commands:
- cvs -d:pserver:email@example.com:/cvsroot/tidy login
- [Press Enter when asked for a password]
- cvs -z3 -d:pserver:firstname.lastname@example.org:/cvsroot/tidy export -f -Dnow tidy
Yay! Now that you have the source…
- cd path/of/installed/source
- cd build/gmake
- make all
- sudo make install (I changed the include dir in the makefile first)
This is a fascinating book with this claim: world-class performance seems to have little connection to innate talent (which may not even exist), general ability (like IQ), or years of experience. The only factor supported by the evidence is the number of hours of “deliberate practice,” which must be designed for improvement, repeatable, usually includes a teacher, and is often not fun. I’m still taking it all in after several days.
I’m so clear on the “how” of BDD. What I haven’t been connected to is the underlying motivation, the first principles from which all the techniques flow. So I decided to start collecting them in one place (here, lol)…
- Driving is the key word. Emergent Design is the result Testing is a bonus. The real juice is that the specifications actually drive the code to achieve its objective as simply as possible
It’s amazing. I read about the poor maintenance programmers who will spend way more time working with my code than I will writing it. About how important it is to keep the code clear so that they can recreate what I was thinking. It makes total sense. What freaks me out is how often I benefit from readable code. I just got back from a four-day weekend in LA and I’ve settled back into my test driven code like a favorite comfy chair.
Me: “What the heck does this class do?!”
- BOOST_AUTO_TEST_CASE( shouldThrowOnInvalidDBInfoPassedToConstructor )
- BOOST_AUTO_TEST_CASE( shouldConnectToDBViaConstructor )
- BOOST_FIXTURE_TEST_CASE( shouldConnectToDBViaConnectFunction, NotConnected )
- BOOST_FIXTURE_TEST_CASE( shouldThrowIfPassedBogusServerCredentials, NotConnected )
- BOOST_FIXTURE_TEST_CASE( shouldThrowOnSelecting, NotConnected )
- BOOST_FIXTURE_TEST_CASE( shouldSelectDB, Connected )
- BOOST_FIXTURE_TEST_CASE( shouldThrowIfInvalidDBSelected, Connected )
- BOOST_FIXTURE_TEST_CASE( shouldThrowIfSelectingInvalidDB, Connected )
Me: “Ok, right. Now I can get back to work.”
I wrote a CGI app in C++ which compiled and linked with no problem. When I ran it, thud:
error while loading shared libraries… can not open shared object file… no such file or directory
The problem is that programs don’t hard-code paths to shared libs. This works great most of the time because the app simply searches the standard lib paths and find it. However, if the shared lib is elsewhere, game over – runtime link error.
Since it was only this program that needed to link to the library, I used a linker option that adds a directory to the runtime library search path: the -rpath flag. Since I was using g++ through a makefile, I passed the flag to the linker via -Wl, which – you guessed it – passed flags to the linker! The full LDFLAGS were: -L/path/to/shared/lib -l[libname] -Wl,-rpath,/path/to/shared/lib. The commas are a little weird and through me off at first, but they are correct. You can read about the syntax here (for -Wl) and here (for -rpath) and here (for the combination).
Exactly what I wanted: the program can find the library at runtime in its non-standard location!
Love Boost, hate Boost. You can’t imagine how much time I spent on this.
Ok, much better. If you install the Boost libraries to an alternate directory (other than usr/local/lib), you will have to jump through hoops to link to the shared versions.
Option #1: Keep Boost in /usr/local/libs. To link to shared libs, drag them into Xcode. Done. (Tip: put a symlink in a visible directory if you can’t see /usr/local/libs)
Option #2: Keep Boost wherever you want and copy the dynamic libs you use into the executable’s directory before linking. This approach is not recommended. Your program will only work when the current directory is the directory of the executable.
Typical install… like there is such a thing! I sat down eager to take MySQL++ for a test-drive, so I opened up a few Safari tabs, shuttling between the MySQL and MySQL++ sites (the library has been taken over by a caring individual), and sipped my large glass of water. Everything went along smashingly until configure complained that it couldn’t find the MySQL library and include files. Oh yeah, I’m using MAMP, so I don’t have any! This was the solution:
- Download MySQL++ from here.
- Unarchive MySQL++.
- Download closest compatible MySQL version (5.0.77 at time of writing) here.
- Unarchive MySQL
- Open a terminal window
- cd /path/to/MySQL++
- ./configure ./configure –with-mysql-lib=/path-to-wherever-you-unarchived-mysql/lib –with-mysql-include=/path-to-wherever-you-unarchived-mysql/include –prefix=/path/where/you/want/mysql++/installed
- sudo make install
- Revel in installation success
Update: when I tried to build and run one of the sample programs in xcode, I got a “Signal 10″ bus error – but only in debug builds (release were fine)! After an hour lost in the www woods, I started manually flipping all the target settings that were different and found that the preprocessor macro “-D_GLIBCXX_DEBUG=1″ was the problem. Of course, once I knew what I was looking for, I found it in two seconds on the web. You can read a more detailed description of the problem here. Once I removed the macro, all was well.
Update #2: the library tries to find the mySQL server in the default location, not wherever MAMP’s mySQL server is. One solution, which I found here, is to put a symbolic link in the place where the library looks, which points to the real file in MAMP.
Although not officially tested for the Mac, I got version 3.2.7 to compile (3.2.8 had compiler errors). Here’s what I did:
- Remove “#pragma interface” and “#pramga implementation” from all source files
- In Terminal, change to the cgicc directory
- ./configure –prefix=/Path/where/you/want/to/install
- sudo make install
I was attracted to Dave’s work after seeing him in some Google videos. You can tell right away that he has TDD in his bones. And, even better, he seems to be very practical and light on the dogma. Here are some of the points that I found illuminating:
- Programmer tests – define what it means for the code to work, different from unit tests (test that the code you’ve written works)
- Comments – if they are required, consider that the code is not clear enough. Valid reasons are todo placeholders, use of unusual algorithms (cite reference if published), performance tuning (so maintainers don’t undo), and class descriptions
- TestCase (unit test framework classes) – for sharing fixtures, not for conceptual grouping. This is great, so many basic tutorials make it seem like you should have one TestClass per ClassToBeTested, which creates duplication for member tests with partially overlapping setups. Dave says: split them up into separate TestCases – so obvious, so perfect!
- Keep test methods small, ultimately one-assert-per-test – so much clearer. Instead of writing 4 asserts on 3 different objects, refactor into 3 test methods with a common fixture
- Test boundary conditions early – easy way to get started (e.g. null and INT_MAX)
- External resources (e.g. databases) – don’t test against, use mocks
- Add a main to test cases so you can run them individually from a tool
- Mocks – many benefits and uses. Two I always like are to test unusual/exception events and as a placeholder until classes are actually implemented
Holy crap! I just got to the example project. This is the book I’ve been wanting to read since I started programming. The example is an end-to-end TDD project. He goes from project vision on through as if you’re coding together. Most other books use toy implementations that leave out all the thorny parts – the GUI, the flexion of the model as requirements change. I’m still reading, and I can’t wait to get through this project!!!