To set up debugging on the slapd, in slapd.conf:
Continue readingAuthor Archives: Adam Young
16 Random Things About Me
1. The mechanism in the brain is that is supposed to disengage the mouth doesn’t always work with me. When I remember an embarrassing episode from earlier in my life, I often yell at my self about it, out loud, usually something like “Stop think so much!” or “Quit it.” I have Programming induced Turrette’s Syndrome.
2. I read incredibly fast. I started reading in kindergarten and have always devoured books. I was reading the full length Alexandre Dumas books in third grade.
3. I wore braces while wrestling in high school. My lips were routinely turned into chopped liver by them.
4. Music has been an incredibly strong force in my life. I was singing before I spoke. I started piano lessons in first grade (Thanks Mrs. Stephanski!). My great Uncle Ben started teaching me Saxophone in second grade. I sing out loud whenever I am in the car alone. I contemplated going to Berklee school of music. As a Junior and Senior at West Point I conducted the Jewish Chapel Choir.
5. I read Zen and the Art of Motorcycle Maintenance while in High School. No other book I’ve read has had more of an effect of how I interpret the world.
6. As a Plebe at West Point, I got into big trouble twice. The first time was because I had a sword for the medieval studies club in my locker in the trunk room. The second time was for drinking. My roommate had snuck a bottle of Jack Daniels into the Barracks. I had to shots, and threw them up.
7. When I was a three years old I made up a Superhero named “Strong Running Man”
8. I was really into Archery when I was in boy scouts. I had a recurve bow. My cousin and I were shooting arrows up into the air in New Hampshire. One got stuck in the trees, and fell to earth right in front of my father, missing him by a few feet. He broke the bow over his knees.
9. My first crush was when I was in nursery school. Her name was Elizabeth Lubin. I still don’t know how to spell her last name.
10. I compose music. I’ve written a few jazz and folk songs. I have written about 70% of the book for “The Princes Bride, the Musical.” It is an Operatta.
11. I spent my first two and a half years as a professional programmer doing Microsoft programming. My focus on Linux and Open Source programming comes from having been burnt by MS too many times.
12. When I was Lieutenant in the Army, I lived in a beach house on the North Shore of Hawaii. On certain days, when I was allowed to do the morning exercises (PT) on my own, I would often go snorkeling right behind my own house.
13. My favorite hobby is Rock Climbing. I have done more damage to my body by climbing with out doing injury prevention exercises than any other way. My favorite type of climbing is climbing cracks by jamming my hands and feet into the wall and camming them.
14. I was incredibly nearsighted as a kid. It killed my depth perception. It is one reason I never liked sports like Baseball or Basketball. I had LASIK about ten years ago, and my eyes have continued to get worse to the point that I need glasses full time again.
15. I have a ridiculous memory for quotes. I can watch a movie or TV show once and pick up a quote that I remember for years.
16. I grew up wandering in the woods. The thing I love most about being back on the East Coast (aside from being near to family) is the woods here. There is something about the deciduous forests and terrain gentle enough to let you walk just about anywhere while out in the woods that I find really recharging. I’ve recently taken up snowshoeing because I love being able to wander through the snow covered woods and walk anywhere.
Cool it with the Ayn Rand comparisons
No, we are not entering the time of Atlas Shrugged. No, Obama’s plan to deal with the economic melt down is not the same thing as the various acts passed during Atlas Shrugged. No, we are no about to enter a world dominated by socialism.
If you feel the need to drop out of society and move to a valley in Colorado, please feel free to do so. I will be understandably jealous.
Who touched a file in perforce
p4 filelog $FILENAME | grep @ | awk ‘{print $9}’ | sed ‘s!@.*!!’ | sort -u
This little ditty pulls all of the the user names out of the filelog and creates a sorted list. At my company, the portion after the @ is the machine that was used for check in, so I don’t want it showing.
contracting
After the dot com bubble burst, I worked as an independent contractor in software for a few years. This is extremely common in the field. Some companies will hire independents outright, where as many others make you go through contracting firms to mitigate risk. (There was a lawsuit regarding compensation and stock options at Microsoft that caused this, worth googling and reading about). I set up an LLC that I used for a couple of the projects. I want to record a few of the lessons that I learned.
I leanred that when figuring negotiating price, I needed to remember to factor in Health Insurance, which is much higher for a single payer than for a member of a large organization. I had to pay both sides of payroll tax (roughly 15%) but you then could deduct half of that as a business expense. The math gets a little tricky, but I would say that I was paying about 5% more in taxes than I would have as a salaried employee. There are tax benefits: you can expense much more than you can as a full time employee. Many of these additional costs to me would have been norne by the comapny that issued me a W2 if I had been a Full Time Employee.
Regardless of the setup between me and the company, I treated it just like I was a company, and separated out the money I earned as an LLC from the money I paid to myself as an employee. Except for the times I had to work through a body shop that issued a W2, I had to deal with paying both state and federal taxes. I didn’t pay income tax directly out of your monthly pay, so I held on to the tax money for an average of 1 month an a half longer, which I could invest. There is a final accounting done at the end of the year. There are books on this. I had a good accountant.
One thing I learned to watch is the length of the contracts. Once a contract ends, if I didn’t have another lined up, I went without work, but was still paying the mortgage. It was up to me to fill in my own schedule. I spent a good deal of the time working on my own software, and a lot of time cleaning the apartment.
Entangled Dependencies
Our LDAP Client has a wrapper for creating a persistent search. In order to execute a persistent search, a polling mechanism has to call the client code with notifications of changes from the LDAP server. This means a threading library. The call looks something like this:
LDAPCLient->GetApp()->GetThreadPool()->ScheduleTimer(MakeFunctor(callback))
Here the call to GetApp is completely superfluos to the logic: we should not care where the ThreadPool comes from. Instead, LDAP client should either take a thread pool pointer in its constructor, or a thread pool should be passed as a parameter to CreatePersistentSearch. I prefer to resolve all dependencies like this at object construction time.
GetApp throws an exception if it is called prior to a call to AppImpl::Init. Init reads an XML based config file. So our dependencies now include both the config file and the xml parser on top of the App object. The LogObject and LogName are also initialized in the App.
What we are seeing here is how dependencies get entangled implicitly. In order to reuse the LDAP client, or to create a Unit Test for it, I have to initialize an App object, which is far beyond the scope of LDAP.
Continuing on looking at the ThreadPool, I see that the AppImpl actually creates the ThreadPoolWin32 object by passing the config file view to it, and the config file view is used to fetch values for the state of the thread pool value by value. Example:
_config->Get(“TaskMax”, &_maxWorkerThreads);
_minIOThreads = 1;
_config->Get(“IoMin”, &_minIOThreads);
_maxIOThreads = 2 * _maxWorkerThreads + 1;
_config->Get(“IoMax”, &_maxIOThreads);
The binding of the values to the object should be external of the constructor, as it is just one Initialization scheme. What if we want to reuse this object and read the values in from a database, or from a different config file format?
The LDAP Client should have a field that is the ThreadPool base class. For the Unit test, we could mock this out. Of course, maybe the persistent search itself should be its own class.
Hometown
One facet of returning to Boston after half my life away is dealing with the demons of High School. Not just my demons but those of my friends from my home town. Things we didn’t talk about then are now part of the conversations. The emotional irritants from 1986 have been encapsulated in enough mother of pearl to be taken out and admired in the light. As technology increases the frequency of re-acquaintance, old names and faces trip old traps. The strong and confident find themselves in tears over a snub two decades passed. Anger long since packed away in the attic is extracted, unfolded, and ignites upon exposure to fresh air.
When we were expecting our son, my wife and I read many books. One phrase that stood out is ontology recapitulates phylogeny. In simpler language, an embryo passes through all the stages of evolution before it becomes a baby. All those previous steps are incorporated into the nascent human. But evolution didn’t stop with human infancy. Dr Karp suggests we should think of toddlers as cavemen not yet ready to comprehend full language. Is the teenager then still carrying around the same set of energy and impulses as we needed when we were in the trees? As adults, we have built on what we were as children and teens. We’ve incorporated it into our adult selves. Have we grown from our pains or just grown around them? Nietzsche promised us to grow stronger from a non fatal encounters, but was that may have just been the optimistic aspiration of a man in extreme pain.
Like Robert Frosts swinger of birches, I have gone away and come back. My arc described not just a removal from earth, although I have spent a good deal of time looking down at earth from high up on a cliff side, but also a removal from the society in which I first developed. I can’t claim to any great insights to any development but, maybe, my own. It is not that I have grown beyond who I was in 1989, but that I’ve gotten a sense of how that boy fits inside the man I am now.
Stoughton. Mention of the name of my home town now evokes a common response: Ikea. Yes, the great blue behemoth sits in the center of the woods that we dubbed Sasquatch Territory many years ago. The name came from the trees bent, like Frost’s Birches, from an ice storm, that an older brother in the neighborhood would rather have ascribe to the attentions of a descendant of some sibling branch of our phylogeny. The naming was inspired, no doubt, by the most popular of episode from the Six Million Dollar man. Those woods were our playground, our battle grounds, where we built dams and dug for old railroad spikes. The benefit of living with such great woods behind our houses came at the cost of being removed from the center of action, around the North Elementary School, where the tighter knit subdivisions lead to the forming of alliances that would play out on the school grounds and classrooms. Four of us from the edge of Stoughton had the combination of nurture and nature to succeed in Stoughton’s Academic environment. A Catholic, a Korean Buddhist, and a Unitarian, and me, the Jew, somehow survived and succeeded, at least academically.
Stoughton is proud of its blue-collar roots. Drinking and smoking were normal part of teen culture, as was a moderate degree of drug use. We lost a few kids to driving accidents, most notably for me one of my older sisters boyfriends. There was social ostracism, taunting, bullying, and fights. The latter were often started with our version of a thrown gauntlet, the phrase “meet you at the tracks”. We even have our own minstral, singing in much more evocative terms than I ever could. My sister’s friend Lori Gerow grew up and married into the name Lori McKenna. How a girl from a school that prized speed metal above all grew up to be a country/folk star is just the sort of irony that you might expect from a town that is caught on the edge of the Boston Metrosprawl: not quite farm country anymore, but not quite the city.
There are many stories triggered by this reminiscence, but they don’t really address the matter at hand. My demons from this part of my life are domesticated beasts who now rarely ruin the carpet or chew my slippers. I faced them later in life, when they were the members of a larger pack that briefly overwhelmed me. That time brought deep introspection and a truce that has held. Nec Stoughtonia Terrent. High School Ended for me in 1989. Between there and here is a long journey. But my connection with these friends, the commonality of experience ended then, too. After that, Stoughton was a place visited for a Week during Christmas or Summer in between Training and Education. After my folks sold their place on Larson Road, I didn’t have any excuse to go back, and lots of other demands on my vacation time. So to connect with people I knew back then, I refer to events of two decades hence. But what to do when the responses bring forth such vehemence? Stoughton wasn’t nearly the worst thing I’ve faced in my life. I can’t claim I would have chosen that as my upbringing, or that there are not major steps there I would have changed, but I don’t hate the place, not by any stretch.
One common theme though is a sense that we really didn’t know each other back then. Certainly the divide along gender lines was quite strict amongst us, the geeks. There might a be a strong friendships that crossed lines, but they were ones and twos. My friends were mostly guys. Girls in class were fearsome things, more likely to laugh at you then to respond kindly to an approach. My early relationships happened during transitions: summers, trips. Even crushes were reserved for girls outside my classes, girls who wouldn’t have seen the ass I made of myself by talking too much during a class I had prepared for too little. I don’t know if a 13 year old boy and girl can be just friends. Certainly it is a chemically unstable situation, too prone to slip on one side or the other into obsession or rejection. Some of the girls in the classes were caustic . Some unconscious action of mine would bring derision, a sneer of contempt and add another layer of shellac to my shell of isolation. It didn’t keep me from speaking up to the teacher, to challenging the pedagogy, but is kept my attention focused on the front of the classroom. Another girl from these days remain fixed in my mind with a perpetually startled expression, mortified of the least attention. An essay read aloud in English class would periodically cast a brief spotlight into the mind of one of these foreign entities.
There are a few things I got from Stoughton that I might not have if I had grown up elsewhere. It was far enough from the city that there were still large tracts of woods. Both houses I lived in backed up to stretches of woods large enough that I never fully explored them. I loved the freedom and relative safety I had of wandering free in the woods, a freedom that my Brookline raised son will not be ableto enjoy without travel. Stoughton was a small enough town that we knew, if not everyone, than the majority. Rare is the member of my graduatin class whose name does not evoke some small memory. I remember my teachers, knew the principals. My folks and my friends parents were involved in town meeting and in social issues that affected our town. If I was left behind by the organized sports collectives so popular amongst my peers in elementary school (Soccer, Baseball) the music department and High School Wrestling team made up for it. The honors program challenged me enough to get me engavged, but was not so competative that it stifled anything other than the superstars.
Today Stoughton is more memory to me than reality. I cheered to hear that we won the football game on Thaksgiving against tradition rival of Canton, but didn’t go to watch the game. Few of the teachers that taught me are still employed in the system, far more have retired. My friends no longer live there: those that stayed in the area have migrated to surrounding towns, or, like me, have been drawn in to the city. Periodic epsidoes involving Ikea aside, the greatest draw of Stoughton remains the staple of our diet from adolescence: Town Spa Pizza.
Coding at Walker Interactive Systems
My time at Walker Interactive Systems, a now defunct Mainframe financials company, served both as my transition out of the Army and into the civilian world, and as my introduction to life as a professional programmer. It marked a rapid change in many of my attitudes about life, software, and business.
When I started at Walker, the company had recently gone through a round of layoffs, and was just recovering enough to start hiring again. Many of the people on staff around me were veterans of the company, somewhat jaded, and ready to move on. When I started in January of 1997, there were two other developers on my Group: Laura and Tony. By the time August rolled around, they were both gone.
I worked in a group developing internal software. The end users were primarily the consultants of the company who customized the software for the end users. Overall, the company sold a suite of financial software: General Ledger, Accounts Receivable, and the like. The software ran on IBM System 390 mainframes. Customers were behemoths like AAFES, and one of the Airlines (I think United). The primary software was designed to run on a 3270 terminal: a fixed size, fixed font terminal run on a screen by screen basis. It was an old technology. Keystrokes were scanned and processed by the terminal software and stayed on the local system until an explicit “Enter” command would send the whole buffer back to the mainframe.
My team was responsible for turning these screens into an API that Visual Basic programmers could use, a process known as screen scraping. An off line process would read the database of screens, including position and length information, and store it in a database on client side. Code inside the applications would act like a terminal, buffer up the changed information, and send it back and forth to the mainframe. The code to execute this was split into two pieces, one for the UI and one for direct communication to the mainframe. When Laura left, I inherited the front end. When Tony left, I got the rest.
Microsoft technology was then at the DCOM stage. What had started as Object Linking and Embedding had evolved into a development philosophy that pervaded the various flavors of the Operating systems at that time: Windows 95, NT4. I became a student of the component object model, learned about monikers and marshalling, reflective cross language interfaces, and remote procedure calls. Wrox Press provided most of the information I needed, and Stacey’s bookstore graciously provided me access to spend a portion of my salary to purchase the books I needed.
The first thing I did was a rewrite of the UI code. This was less a matter of Hubris and more a matter of it being easier to learn by writing than understanding the existing code base. The existing code was in C, and I was immersed in C++. The existing code was a series of dynamic link libraries for the non-preemptive-multitasking version of windows that had been forward ported to Win32, but that had much of the vestiges of the older systems. The old code was more error handling than anything else. My version had the benefit of focusing on a single platform. Since I had the freedom to develop the code from scratch without worrying about backwards compatibility, it made it much easier to make the new code re-entrant, something that the old code had to work to prevent.
One big lesson learned from this effort was to respect the amount of embedded knowledge that there is in a pre-existing code base. After the first release of my code, I spent a lot of time fielding bug reports from the UI developers about features I had missed. I learned the value of having a quick-to-run debugging code driver that allowed me to easily reproduce their problems. The integrated debugger was invaluable in stepping through, viewing what was actually happening, and allowing me to quickly make and distribute fixes. I got the notion of step through your code drilled into my bones.
When adapting the Gateway code, I had to deal once again with the rapidly changing API from Microsoft. The older method of remote procedure call was deprecated. DCOM was the new hotness.  After much trial and error with their Interface Defintion Language (IDL) and SAFEARRAYS I finally got a simple network service to run. Since my version was expected to be remote, we had reduced licensing from each client machine to a single NT server as well…or at least the potential to do that. Not sure if the company ever followed up on it.
Of course, all of this distracted me from what I was “supposed” to be working on: the replacement for the screen scraping which was an asynchronous messaging layer. This was my first exposure to the recurring theme that I will state here as a rule: Never name a software project Phoenix. Really, do you want to imply that your project will go down in flames, dying time and time again? This project phoenix was no different. The concept was good: pull out a section of the cobol code that could be executed as a standalone transaction. Turn this into an asynchronos message and let the developers send the message to the mainframe. The reality was that so much of Walkers code would needed to be restructures that even after we got the messaging layer working, the concept was unusable.
One of the end goals of the messaging layer was to work with Data Bound Controls. There are things like spread sheeets and fields that can be bound to a column from a database query. Since that meant playing nicely with the Microsfot database technoligies, I dove in and made the messaging layer an OLEDB Provider. If this doesn’t scare, just be glad and move on with you life. If this does scare you, then you know way too much about microsoft technologies and I feel somewhat sorry for you. Basically, I had to learn about the technology that microsoft was then pimping as a replacement for ODBC, a tehcnology which never really should have caught on, and a technology that should be quietly taken out to the back 40 and shot.
One bug while developing the OLEDB provider took me two weeks to track down and fix. THe mistake was mina and mine alone. I was apassing in a NULL to a field that required an allocated structure. THe problem was that, while I owned the calling and implementing code, in the middle it had to go through a microsoft technology called Active DAta Objects (ADO). This particular API was closed source. I could see only the disaassembly of the executing code, which didn’t provide the context I needed to deduce my mistake. This adventure really sold me on the concept of Free (as in Speech) Software and Open Source coding. I had just started experimenting with Linux, and this really drove home why the development model was so successful.
The very tail end of my time at Walker was spent learning about Java. IBM was pushing Visual Age, and the company was planning a bitg transition. Walker really suffered from the .com boom: people fled to cooler, more interesting jobs throughout 1998 and 99. I left in the summer of 99 to go to Fort Point Partners, a botique services company that was pretty focused on ATG/Dynamo and eCommerce. Soon after I left, I happened across a group of former co-workers there. We chatted and they let me know that the company was then very Java and Websphere focused. Not long after that, Walker was acquired and then passed on to the corporate afterlife.
What’s wrong with me
(Lyrics Composed while jogging some years back and dedicated to my wife)
When I was a little boy
I had a schoolyard crush
There was a little dark haired girl
I wanted very much
Instead I go rejection,
delivered brutally
Hey, what’s wrong with me?
Starting out, a first career
my enthusiasm burst
When the time came to evaluate
my performance was the worst
I worked so long, I tried so hard,
oh no, this cannot be
Hey’ what’s wrong with me?
Looking back at all my life,
have I done the whole thing wrong?
When will I find happiness,
and where will I belong
We shared a dance we shared a kiss
The kiss was very nice
you called me back to break our date
but then you called me twice.
A brand new occupation
that fits me perfectly
there’s nothing wrong with me
nothing, major, wrong with me.
(Inspired by the standard “Everything happens to me”)
Parsing and Inversion of Control
Parsers are essential to the interface layers of an application. A message based system requires a socket listener that will convert the contents of the stream from the network into usable collection of objects. In an inversion of control container, these request scoped objects should be registered instances in the container in order to build/fetch more complex objects, potentially of longer lived scope. Parsed request scope objects should be of classes that enforce invariants, but often will be simple strings in language specific form; char * or std::string being the most common for C++.
Take the example of a userid passed in as part of the request. There really is no format that this string conforms to other than, perhaps, some constraints of the system. To create an immutable UserID class may really just force casts to char * or std::string when the UserID is to be used.
There are many objects, specifically request scoped objects, that need to be created based on the runtime values provided by the system. In a pure Inversion of COntrol (IofC) environment, the parser would create each, and then add them to the container. This may require a large amount of coding in a manner specific to the IofC container. One goal of IofC is to minimize the amount of work that is specific to the container.
Many API’s handle this by creating a map. In the Java HTTP Servlet API, the request object has two string to string maps, one for parameters and one for cookies. This may be a good middle ground between two APIs. A better approach is what Struts does using the Apache Jakarta PropertyUtils API. The Action field of a form specifies an URL that in turn starts with a java object of type Action. THe action is configured in an XML file (Ugh!) that specifies the subclass of ActionForm. The request parameters are bound to the properties of ActionForm using the Java Bean coding convention. Thus a parameter user.homePhone.areaCode =415 would force the reflection equivalent of:
action.getForm().getUser().getHome().setArea(“415”);
One problem with this implementation is that any exception thrown at any point of this binding would force halt to the entire setting of parameters. The net effect is lots of Struts specific coding. Personally, I am not a big fan of getter/setter dependency injection, as it tends to violate the precept that classes enforce invariants. It doesn’t have to, just that code written that way tends to be of the nature where an object can have an invalid state until the setter is called. However, the setter approach does work well with builders, if the set method can be called multiple times in the role of “BuildPart.”
When discussing the marshaling layer we can often think in terms of combing interpreters with builders. The interpreter is responsible from converting from the marshaled format to object format for simple data objects. Each of these objects is added to a larger complex object. In terms of the Builder pattern, the interpreter plays the role of the Director. Only once the entirety of the message is parsed will the director call GetResult. Exceptions thrown during the parsing of the message are collected up so that they can be reported in bulk.
One common objection to this style of programming is the cost of multiple exceptions thrown during the parsing stage. Reducing the number of exceptions thrown should be a performance tune performed after the system is operational. The general structure is to split the parse of a data object into a three stage process. First create builder that takes the object in string form. Second, ask the builder if the marshaled form is valid. Third, fetch the object from the builder. If stage two returns false, add an error to the collection of errors and short circuit the building process. Note the higher degree of complexity over performing the parsing in the constructor. The constructor has to validate the format it is given from the builder, or has to know about the builder object, creating a bidirectional dependency. The logic in calling the builder and the return code has to be coded by hand or has to fit into some larger framework.
The degenerate case also seems to be the most prevalent: confirm the format of the data objects, but then transfer them around as strings. The problem with this approach is that each layer of the application will be written not trusting the other layers, and the objects will be re-parsed, potentially following different rules. From the increase in code size, complexity, and potential for error, we can infer that we should avoid this approach.
Since the builder can be created with minimal dependencies, and most of these can be defined statically, it should be a request scoped component defined in the IofC container. We have to decide at what point in the parsing process do we switch from a general purpose parser to a specific class dedicated to the data coming off the socket. Ideally, the message format provides a way to specify the message type and version early in the stream. This can be the key used to fetch the specific parser. The stream coming off the socket should conform to one of the standard types of the language. In C++ this means something out of std::. The parser can depend on the builder. After the parsing process, one last call into the IofC container kicks off the business processing, that which takes the parsed message and does something with it. At this point we can use something as simple as a functor: Everything is in the IofC layer.
There is a lot here subject to interpretation. The stream may or may not be encoded according to a public protocol, a language specific feature, XML, UUEncoded, encrypted, compressed, and so on. A pipeline can handle the transformation. Converting from stream to objects may use this pipeline, or be a portion of the pipeline, converting from a character or binary based stream to a stream of objects. The issue here is always how to get the objects available to the container without too much container specific logic. If the value comes in key value pairs, the key needs to provide enough information to determine which instance of which class to create.
Since your inversion of control layer should be minimally invasive, you don’t want to have each call in the building of the input validation require knowledge of this layer. Something about the network protocol is going to be unique enough to pull in the processor for your code. This is going to be the URL, the message type, or something unique to your protocol. The should be enough to select the interpreter and the builder objects, connect them, and let the parser become the pump from there on out. The builder should registered in the Inversion of COntrol container. When something needs the end product of the build process, it should get this from the container, which will delegate to the builder. This should strike the right balance between type safety and flexibility.