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."
You are formally a TV guy.... "Real men don't preview their edits."
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?
Just check for
1 = Good to go.
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).
"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.
"Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience."
WTF? What if I *need* that data in order to determine how to complete the rest of the page?
Render a skeleton of the page the main page load, and populate the full contents asynchronously. Surely that's the whole reason you wanted to use AJAX in the first place, so it is the best practice.
Once that's done, nearly everything else can happen asynchronously.
Admittedly, however, I am a n00b to writing web applications this way, and as soon as it's implemented past the point of no return I'll figure out a better way to do it.
of data structures. This determines how the remainder of the page gets
It's either that, or do more of that first, skeletal rendering server side, the old-fashioned way.
What I ended up doing is running the initial JS piece on page load and then having that function's OnComplete (or whatever it's called) call a function that loads all the other pieces that depend on it. I suppose that's "how it's supposed to be done" but it still seems a bit obtuse to me.
Yeah, that's how the cool kids do web development these days, daddy-o.
*snap* *snap* Fresh.
I have written a fairly significant amount of Rails code lately.
I thought we should embrace it, as the rest of the company uses it for their efforts, so we could potentially pull from a larger pool of people in the future if we ever needed to do so.
Although I'd never used this before, I find this environment impressive.
Although, getting something up in production seemed to involve installing the world.
I might have an illness.
I've been spending my free time writing a C++ header library to act as an HTTP 1.1 client.
Handling chunked transfer encoding or regular 'identity' transfer encoding, getting headers, able to write the body either to memory or file, etc.
I never found a truly C++ library that quite did all of this the way I want, so I figured I should write my own. There's this one guy, named Falco, working on something that looks nice, but it requires C++11 or better, and I don't want to be limited to newer compilers for this.
I think after I get the client side working, I want to see how much of this I can reuse/rework for server side. I'll never replace apache, but if someone needed an embedded http 1.1 server, maybe I can make this interesting.