Please wait...
I just figured something out, while sitting in my car hacking on Citadel code (waiting for my daughter's dance class to finish ... 2 hours at the computer is more productive than wasting :50 driving home and back).
My skills in managed hosting are hurting my skills in software development.
Today I finally started ripping apart a couple of small, outdated subsystems that need to be modernized. I've been skirting around them for months because I couldn't figure out a clean way to start working on them. I didn't really want to badly break the build, even on my own development machine.
Eventuallly I remembered the old adage "If you want to make an omelette, you've got to break some eggs."
And I realized that it has a lot to do with my career in managed hosting.
We run large scale data centers, and uptime is *everything*. Even a minute or two of downtime causes people to get hostile. So everything we do is carefully planned. Maintenance is like replacing the engine of an airplane while it's in flight.
I've got to get myself out of the habit of thinking of uptime when I'm working on a development system. It's ok to break the build on my own machine. It's ok if the code stops working for a few days. Nobody is running it in production.
I have a lot of brain damage. And this particular bit I probably can't blame on my parents.
I hear you IG. I work at a small hosting company and have the luxury of thinking out the "chess moves" of what I plan to do. I also have the luxury of performing some of the acrobatics involved overnight. The thing is, eventually, the businesses grows to a point where you are to a point where you are still in a hole in the ground and trying to pile up dirt to stay alive.
Hm.
Some of my co-workers have a fear of 'breaking the build'. Understandable, but anything involving fixing setup involves breaking the build, since you have no other way to get the setup built.
Of course, there's also the whole 'branch, break the world in the branch, once you have it all working, merge again' sort of method.
maybe you should use the time of habit changing to start writing some tests? maybe using ctdlsh to test if its the same again after you modified everything? ;-)
I whish I have had this while debugging the eventloop stuff in citadel:
it records a session of a program with all io it does, and lets you replay it again and again in gdb.
No need for feeding in the external data again. Its storing and replaying all i/o state for you.
Man, that's what I need to get the guys to do... fix the damn testing harnesses so they're actually testing code in the builds.
Interesting. Can you run the same binary with recompiled code later, for test cases.
That could help unit testing, but would of course be brittle. You need the ability to edit the I/O data to suit changes in the code. Tricky. ;-)
If it's not clear over my pithy phrasing, I think this is problematic. A compiled binary is a whole program, and therefore (in any non-academic, reasonably large, industrial system) too large for unit testing tricks. Kernel-level I/O capture solutions will be too broad to be of use, if they are from production. Even in an encapsulated test environment, this can be too high-level to be of use.
"I don't always test my code ... but when I do, I test it in production."Back in the day ... only weenies did assembly and insert editing. Real men spliced videotape!
So, how about those fun useful macros, __FILE__ and __LINE__ ?
Are they still only available in GCC? Or does the rest of the civilized world have them now?
That's good to know ... although at the time I was posting that I was trying to figure out a way to generate a variable name inside a macro that would be unique each time the macro is called, so using #ifdef to provide optional functionality isn't an option. I ended up compromising, though, and writing a function instead of a macro.
My current attitude, though, is to leave behind anyone who isn't reasonably modern. At the moment I'm working in an autoconf-free environment and finding the air is fresh, the sky is sunny, and the birds are chirping merrily. I no longer have any interest in supporting HP/UX from 1994, and I am losing interest in the idea of trying to keep the build going with reduced functionality if optional dependencies are not found. In short, using autoconf makes the build ridiculously complicated, hard to maintain, and bloats the code with #ifdef's that don't really benefit a lot of people.
I want to spend time writing code, not build systems :)
I hear ya. Onward and upward. Only entangle and make automated that which becomes mind numbing drudgery if not automated. Better to write a README I say. The packagers can figure out a way to make it "user friendly".
One of the things you can do is spoof messages from another user in the chat.
So my 5yo son spoofed a message from "God" telling my older boy to build a giant wooden boat. I just happened to have remoted into the server console from work when this happened, and I saw the message come across the line. I immediately typed a message from the server: "A boat would be a really good idea." And then I changed the weather to rain and thunder.
My wife reported (via chat) that the kids were having a really amazing reaction to the server suddenly talking back to them and interacting. They didn't know it could do that.
Nice Sig. My son has a Pi and when I showed him the cool stuff you could do with Mincraft on it and some simple Python, he said - 'meh'.
If I had that back in the day, I would have had quite the kick butt 3d graphing calculator (at a minimum).
I'm pretty sure Visual C++ has the __FILE__ and __LINE__ macros, although I haven't tried them.
But then, if the resumes we are getting in response to the vacant position we've had for months now is any indication, nobody actually programs in C/C++ anymore, and everything only happens in the web anymore.
(Which, if anyone is interested in working remotely, maybe send a resume... intermediate to senior systems engineer on old-to-modern flavors of linux to help create software for an automated classroom).
*sigh*
"Don't use the 'auto' keyword," I said.
"We have to support compilers that were written 10 years ago, and that keyword is c++11."
So my co-worker used it.
And it broke the build today, now that we're having to support a machine that used gcc 4.3.
Worse yet, the person who did this had absolutely no reason to do so short of being fucking lazy.