I've been working for four years as a software developer. I started reading all these books when I got out of school, not while I was in school, when I was still busy reading text books.
In my opinion, you get more out of these programming books when you are working as a programmer, so you can allow your experience and reading to feed back on each other and achieve a synthesis of theory and practice.
I have this book. I haven't read it cover to cover (yet), but have absorbed sections as appropriate.
I like it. It seems down to earth. I agree that occasionally, the examples seem a wee bit forced, but I'm not bothered by the C++ focus as that is my preferred language.
I'd agree that the book is a good read if you are into patterns. If you aren't, you should check out the patterns web site, and the original Design Patterns book.
Also, I went nuts and bought the original Christopher Alexander architectural patterns books. They look fantastic!
Note: I am a programmer with a CS degree, who isn't afraid of software engineering.
I think there is a difference between the three. The programmer writes code. Anyone can do that. The CS grad knows the fundamentals and theory of algorithms, data structures, information science, etc. The software engineer applies sound engineering practices to software design and implementation.
They aren't the same. A PhD in computer science may not know anything about software engineering: construction of real systems. A software engineer may not know the little details of languages, automata, etc. And a programming wizard may not know either, but dwarf them in his C expertise and knowledge of an OS.
They can all work together. Each contributes something to the team.
One thing I've noticed, though, from where I used to work, with "computing" engineers and CS grads. The engineers cut more corners, are far more cowboy. Perhaps it is a rebellion against their training, a chance to cut loose in the abstract world of software. At any rate, I found their lack of rigour disturbing, and invariably it bit us in the end.
The fatal flaw with the Darwin Awards is obvious to anyone who has read The Selfish Gene (or is otherwise familiar with genetics).
They don't remove themselves from the gene pool, if they have already reproduced. Hell, if they orphan their children, then someone else has to take care of their offspring. They're ahead.
First, I don't see that FreeMWare is coming along that great. I'll believe that they are making progress, but I don't see any screenshots.
Second, VMware is great. It does what it claims. It isn't that expensive. It's a nice piece of software. I have it at work. I don't use it much, but when I do, I'm impressed.
I've preordered my copy and am awaiting its arrival. I'm happy to support Linux, id, and Loki.
I hardly play games these days (too much else to do), only AoE 1&2, Starcraft, Quake 2&3, and Civ3.
It's nice that for the latter two, I don't have to reboot. Quake isn't quite as playable as on Windows, but it *is* playable. Hopefully the coming RIVA TNT2 drivers, and XFree86 4.0, will bring things more in line.
The coding style is discussed in the preface, which is available online here. I think it is reasonable to expect readers to read the preface. In part it reads:
"The programs use a terse coding style: short variable names, few blank lines, and little or no error checking. This is inappropriate in large software projects, but it is useful to convey the key ideas of algorithms."
Much of the "code" is in fact pseudocode. One thing it does include which is a good habit, is scaffolding for testing, debugging, and timing the functions. That's something you don't see everyday.
To his credit, Bentley explains his coding style in the book (and probably on the web site). It's not meant to be robust in IO or error checking, but to convey the ideas.
I figured out how to run it. The "couldn't get visual" problem is because there is only 4MB of memory. You have to remove the large virtual desktops from your XF86Config file, so that the desktop (note, not display) resolution is smaller. Then it can get a visual.
However, I find that I still only get about 20fps in corners and 2fps otherwise. Clearly it isn't hardware accelerated, as it is with the same drivers and RIVA TNT2. I can't figure out why. I'm fairly sure I'm doing everything correct (16bit etc.).
It works great with my RIVA TNT2 at work. However, at home (with the test and this demo test) I haven't had luck with my RIVA 128. I am using the same driver (X server and libGL.so) but I get this error:
I also started a new job this year, and had the pleasure of sitting down to write proper requirements documents for new software systems. This was something I did not have the opportunity to learn or practice at my previous job.
We too found ourselves running out to our neighbourhood book store, to find good books on requirements documents. We ended up with info from McConnell books, and a requirements lexicon by Michael Jackson.
Really, we knew the theory, but just hadn't had the practice. Now, after going through a round of requirements, revisions, etc., the process is a lot clearer. I'm a lot more comfortable with it.
Another thing we found helpful, is to try to write testing documents based on the requirements documents, before writing the design documents.
If you think requirements are academic, then you haven't been in industry.
I've worked at corporations that neglected requirements documents, and those that required them. The difference is night and day.
How do you know your software is correct without documented requirements you can check against? Perhaps that's not so important with OSS, where almost anyone will find a use for the software even if it isn't what was originally intended. But when your customer, and your future paychecks, are depending on meeting a market need, better than your competitors, you can't afford to play fast and loose.
Perhaps previous OSS projects were mostly little ones. They're not so bad to maintain without proper documentation, due to their simplicity. But many industry software systems are huge, with many features, legacy code, backwards compatibility, etc. You cannot just wade into the code and start hacking. It doesn't work like that.
As OSS projects mature and get larger and more complex (XFree86, GNOME, etc.), they also require a more academic/industry approach. And if you check out their web sites, you'll find that they do. You'll also find that those that don't, quietly disappear without a ripple.
Slashdot Mirror
I've been working for four years as a software developer. I started reading all these books when I got out of school, not while I was in school, when I was still busy reading text books.
In my opinion, you get more out of these programming books when you are working as a programmer, so you can allow your experience and reading to feed back on each other and achieve a synthesis of theory and practice.
--
Hey, that's me!
Thanks, I read a lot of these books (like Justin) and like to share what I've learned. I'm always glad to hear it is helping others.
--
I have this book. I haven't read it cover to cover (yet), but have absorbed sections as appropriate.
I like it. It seems down to earth. I agree that occasionally, the examples seem a wee bit forced, but I'm not bothered by the C++ focus as that is my preferred language.
I'd agree that the book is a good read if you are into patterns. If you aren't, you should check out the patterns web site, and the original Design Patterns book.
Also, I went nuts and bought the original Christopher Alexander architectural patterns books. They look fantastic!
--
I always knew it.
The solution, of course, is simple. Hire more immigrants as INS staff.
--
That's what I'm working on.
Click the URL above.
--
Please explain what "tweaking" is required, don't just tease me!
--
I know it's a little old now, but it's still playable and very well balanced (regarding gameplay).
Age of Empires II is another I'd like on Linux.
Pretty much those two games are the only reason I ever reboot my machine. I'd pay $100 Canadian for each.
--
Note: I am a programmer with a CS degree, who isn't afraid of software engineering.
I think there is a difference between the three. The programmer writes code. Anyone can do that. The CS grad knows the fundamentals and theory of algorithms, data structures, information science, etc. The software engineer applies sound engineering practices to software design and implementation.
They aren't the same. A PhD in computer science may not know anything about software engineering: construction of real systems. A software engineer may not know the little details of languages, automata, etc. And a programming wizard may not know either, but dwarf them in his C expertise and knowledge of an OS.
They can all work together. Each contributes something to the team.
One thing I've noticed, though, from where I used to work, with "computing" engineers and CS grads. The engineers cut more corners, are far more cowboy. Perhaps it is a rebellion against their training, a chance to cut loose in the abstract world of software. At any rate, I found their lack of rigour disturbing, and invariably it bit us in the end.
--
Heh, I just discovered a week ago that Corel pays its developers less than Hummingbird. Pathetic.
--
The fatal flaw with the Darwin Awards is obvious to anyone who has read The Selfish Gene (or is otherwise familiar with genetics).
They don't remove themselves from the gene pool, if they have already reproduced. Hell, if they orphan their children, then someone else has to take care of their offspring. They're ahead.
--
Hey, I go to check out www.linuxninja.com, and discover that I know the owner!!
--
What's the story here?
--
First, I don't see that FreeMWare is coming along that great. I'll believe that they are making progress, but I don't see any screenshots.
Second, VMware is great. It does what it claims. It isn't that expensive. It's a nice piece of software. I have it at work. I don't use it much, but when I do, I'm impressed.
--
I've preordered my copy and am awaiting its arrival. I'm happy to support Linux, id, and Loki.
I hardly play games these days (too much else to do), only AoE 1&2, Starcraft, Quake 2&3, and Civ3.
It's nice that for the latter two, I don't have to reboot. Quake isn't quite as playable as on Windows, but it *is* playable. Hopefully the coming RIVA TNT2 drivers, and XFree86 4.0, will bring things more in line.
--
The coding style is discussed in the preface, which is available online here. I think it is reasonable to expect readers to read the preface. In part it reads:
"The programs use a terse coding style: short variable names, few blank lines, and little or no error checking. This is inappropriate in large software projects, but it is useful to convey the key ideas of algorithms."
Much of the "code" is in fact pseudocode. One thing it does include which is a good habit, is scaffolding for testing, debugging, and timing the functions. That's something you don't see everyday.
--
Of course it's written for Alice Pleasance Liddell. Look carefully at the first letters of each line in the final poem of Through the Looking Glass...
--
To his credit, Bentley explains his coding style in the book (and probably on the web site). It's not meant to be robust in IO or error checking, but to convey the ideas.
--
Good movie. Recommended.
--
Recall that part of the problem was not to identify the *exact* answers, but to get 90% ranges for them.
--
I figured out how to run it. The "couldn't get visual" problem is because there is only 4MB of memory. You have to remove the large virtual desktops from your XF86Config file, so that the desktop (note, not display) resolution is smaller. Then it can get a visual.
However, I find that I still only get about 20fps in corners and 2fps otherwise. Clearly it isn't hardware accelerated, as it is with the same drivers and RIVA TNT2. I can't figure out why. I'm fairly sure I'm doing everything correct (16bit etc.).
--
It works great with my RIVA TNT2 at work. However, at home (with the test and this demo test) I haven't had luck with my RIVA 128. I am using the same driver (X server and libGL.so) but I get this error:
Couldn't get a visual
How can I fix this to work at home? Please email.
--
Has it occurred to you that the reason I don't contribute directly to Debian is because I am an upstream provider?
That is, I write original software. It doesn't exist before I create it.
I use Debian. I would like to have an up to date version upon which to write my original, GPL software.
--
This is ridiculous. Literally. People are ridiculing Debian for this.
I use Debian at home and at work. I already de-stabilized my home machine with potato, and slink is really old at work.
Potato is now scheduled for release a year after slink. That's an eternity.
No wonder we are being ridiculed. Debian can't get it up.
apt-get install viagra
--
Thanks Jason, for the informative review.
I also started a new job this year, and had the pleasure of sitting down to write proper requirements documents for new software systems. This was something I did not have the opportunity to learn or practice at my previous job.
We too found ourselves running out to our neighbourhood book store, to find good books on requirements documents. We ended up with info from McConnell books, and a requirements lexicon by Michael Jackson.
Really, we knew the theory, but just hadn't had the practice. Now, after going through a round of requirements, revisions, etc., the process is a lot clearer. I'm a lot more comfortable with it.
Another thing we found helpful, is to try to write testing documents based on the requirements documents, before writing the design documents.
--
If you think requirements are academic, then you haven't been in industry.
I've worked at corporations that neglected requirements documents, and those that required them. The difference is night and day.
How do you know your software is correct without documented requirements you can check against? Perhaps that's not so important with OSS, where almost anyone will find a use for the software even if it isn't what was originally intended. But when your customer, and your future paychecks, are depending on meeting a market need, better than your competitors, you can't afford to play fast and loose.
Perhaps previous OSS projects were mostly little ones. They're not so bad to maintain without proper documentation, due to their simplicity. But many industry software systems are huge, with many features, legacy code, backwards compatibility, etc. You cannot just wade into the code and start hacking. It doesn't work like that.
As OSS projects mature and get larger and more complex (XFree86, GNOME, etc.), they also require a more academic/industry approach. And if you check out their web sites, you'll find that they do. You'll also find that those that don't, quietly disappear without a ripple.
--