Up here just south of Portland, OR, there's a church placed high up on a hillside along Interstate 5. When you drive up close to it, you can see that the very large cross on the front lawn actually is a tower with cell antennae on the upper part of the verticle. It really is a nice commanding view of a long stretch of heavily-travelled highway, and I'm sure the church makes out well for the placement.
So I can be sure to never apply for a job at a place that doesn't even believe in employing fundamental pragmatic programming tools like a source browser. I suppose all the printouts are on green-bar from the chainprinter?
The computer can understand and run any obscure syntactically and logicall correct gook you throw at it, but we invented high level languages to allow humans to express concepts at a higher level than 1s and 0s. Mandating that all code be understandable without tools designed to manipulate and understand it smacks of voodoo coding.
Oh No! Another anti-OO "relational alegebra is all we ever need" rant by Tabilizer. Remember the term from back in the vinyl LP days, "broken record"? Now we say a CD is skipping.
Yes, 1990. I was quoting from amazon.com since my copy was at home (sitting in a place where I do a lot of reading, hehe). I have it in front of me now: Copyright 1990, Prentice-Hall 2nd printing paperback. Even more classic. It should be required reading.
WHY are requirements changing? Because they do, and they always will. No matter how hard you try to hold back the waterfall, it will drown you. Deal with the fact that you are lucky to get 80% of the most important requirements up front. Deal with the fact that some of those will change anyway, as the users get more comfortable with the solutions. You must be flexible and able to handle change or you'll bust a blood vessel in frustration at "wishy-washy" users.
if you are constantly changing critical code, you need to worry more about your development practices and not your testing.
Not true in many developement shops. With short iterations, refactoring, rigorous unit testing, collective code ownership, and continuous integration, code can be constantly changing but stable. Take for example the Mozilla Tinderbox. Development proceeds on many components and the builds and tests are run continuously. There are daily build smoketests (download a daily build and you'll see the smoketest menuitem), and sometimes things are broken for an hour or a day, but overall things just get better.
On a serious note, consider the locations of all the hot network jacks at your employer. Are any of them in public locations that are empty at times, say conference rooms in common areas? How easy would it be for someone to go in, plug in a lap top, and start up a packet sniffer? There are aspects of your network that need physical consideration other than the server room.
Other old hands will tell you war stories, I'm sure, but a developer being able to build and run the latest code is not the same as continuous integration on a designated integration station with an automated build and smoketest.
With a developer base in the hundreds of active people, there is little need for automated builds.
That's about as scary an assertion as I've ever heard from a developer on a large software project. Quite the opposite, the bigger your team, the more you need that automated build and smoketest. But I thinkJoel can say it better than I.
KDE and Gnome releases are fine, but compared to the Mozilla build/release process, managed by the enigmatic Leaf, they are 2nd class. Mozilla developers created their own tools to do it, too. Mozilla is cross platform, continuous builds, bug tracking integrated with version control, and they released regularly on a five week cycle (now quarterly), and daily build and smoketests. And once again, Mozilla is cross-platform -- Linux, Windows, and Mac OS 9/X.
Sorry to crash the party, but I have yet to see KDE or Gnome approach the bar that Leaf and Brendan Eich set high.
A couple of search terms that you'd never come up with if you weren't already steep in the the arcane x.500 world: ISODE and quipu.
Most of this stuff comes out of and is maintained in Europe. As the RFC 1330 says,
"The ISODE is not proprietary, but it is not in the public
domain. This was necessary to include a "hold harmless"
clause in the release. The upshot of all this is that anyone
can get a copy of the release and do anything they want with
it, but no one takes any responsibility whatsoever for any
(mis)use."
You can still find the latest downloads via FUNET.
Be aware, this stuff is a major effort to compile and get working. It's big and complex, but well documented. Have fun, and let me know when you get dish -user "@c=$(COUNTRY)@o=ORG@cn=Manager" to give you a prompt.
It is my sincere hope that everyone here on/. realizes that the USA Patriot act (horrible name if there ever was one) already mandates that certain businesses create and maintain a database of people that they FBI thinks might commit a crime. As discouraging as this one small case in Wilmington is, it's peanuts compared to what the feds are requiring. For example, a story on Yahoo News discusses the detailed data that colleges are required to collect and frequently transmit to the INS. Simliarly, business like bookstore and banks, libraries, and the phone company are now required to keep information on their customer "just in case" they commit a crime or are suspected of committing one.
Not only that, but in the US at least you can be taken to court for libel if you write that someone is a criminal before they are convicted. As long as you drop in "alleged", though, you can pretty much lay out all the facts. For example: WorldCom execs defrauded customers and stockholders and bilked their employees out of insanely huge wads of cash to line their own pockets, allegedly.
Fantastic Voyage Incredible Shrinking Man Attack of the 50 Foot Woman Them! Giant The Iron Giant My Dinner with Andre the Giant anything with Ray Harryhausen animation The Unshrinkable Jerry Mouse
In my defense, I only said Mozilla is pretty well factored code. There are around 4000.cpp files in the 1.0 source, though, and nsDocSHell isn't even in the top 10 in size! Take a look at nsCSSFrameConstructor.cpp, for example -- definitely a candidate for serious reorganization.
You refactor when you find you have bad coupling. This is the same criteria that has been used since back in the dark ages of structured, procedural programming.
It's always good to see the grey-hairs confirming that what seems new and different and untested is in fact obvious and essential for junior programmers to know. Repackaging it a Refactoring may not add anything new, but it does place it in a context that's more accessible to those not raised on FORTRAN and COBOL. Plus, when the old classics are out of print and hard to find, it's good that the new refactorings of the information are still on the shelves at Amazon.
Having a thousand 10 line files does nothing to improve maintainability.
My obligatory plug for The Mozilla Project. Not quite one function per source file, but definitely lots of very small source files, each implementing a very narrow slice of functionality. Mozilla is pretty well factored code, and maintainability is enhanced by the separation of responsibilities. It makes it possible to enhance or fix problems in one area, say the in nsFTPChannel, and know that all the thousands of other lines in the program will be largely insulated from those changes.
Yes, it does take a while to get familiar with the entire Mozilla codebase. The flip side is that you only have to look at and understand a small fraction of it to start becoming productive.
If you are using C++, Large Scale C++ Software Design is definitely a recommendation I can second.
There good news is that there are great tools for automating refactorings for some languages (Java and Smalltalk come to mind immediately). The bad news is that C/C++ is not one of the languages, but C# is.
That said, some of what refactoring browsers do can be done with search and replace. Be careful though, you don't want to change all occurences of "i" to "index" and end up with code that won't compile because there's no type "indexnt".
The ability to rollback refactorings is essential, too. Industrial-strength source control tools are pretty much a necessity, allowing you to re-get your CVS tree if a refactoring attempt gets out of hand.
Since I bought Martin Fowler's book and started studying refactorings, my code has gotten much easier to live with. I no longer fear making a significant change to add functionality or fix bugs because I know I can refactor and still have code that continues to work as before. The addition of unit tests has helped to ensure that it not only keeps working, but it keeps behaving as expected.
Maybe it's a spoiler, but maybe for people who haven't read the book, they'll think of it like Obi-Wan coming back whispering in the first Star Wars movie. Or maybe they'll think it's a dream sequence, or a flashback, (like showing Isildur on Mount Doom in FOTR) or any of another million possibilities that don't require Gandalf to actually return from the dead. You and I know what comes next, but just showing Gandalf in the trailer for TTT isn't an automatic spoiler.
I don't work for them, but I find the Construx Software Reading List to be an excellent guide. It has preferred and alternates for various topics. Here's a sampling:
Introduction to Algorithms, Thomas H. Cormen, et al Code Complete, Steve McConnell 201 Principles of Software Development, Alan M. Davis The Design of Everyday Things, Donald A. Norman Fundamentals of Database Systems, Ramez Elmasri and Shamkant B. Navathe Design Patterns, Erich Gamma, et al. Software Runaways, Robert L. Glass Wicked Problems, Righteous Solutions, Peter DeGrace and Leslie Hulet Stahl
The reading list also includes classic articles and recommended periodicals.
"I can't imagine this mattering much". How hypocritical to be so in favor of open source but irredeemably dissing Mozilla. Oh wait, compare the kind of work that went into slashcode and the quality of the resulting codebase to the Mozilla project. Maybe Taco's definition of open source doesn't include quality code developed by a professional team using good software engineering practices.
Slashdot Mirror
Up here just south of Portland, OR, there's a church placed high up on a hillside along Interstate 5. When you drive up close to it, you can see that the very large cross on the front lawn actually is a tower with cell antennae on the upper part of the verticle. It really is a nice commanding view of a long stretch of heavily-travelled highway, and I'm sure the church makes out well for the placement.
Please tell me where you work....
So I can be sure to never apply for a job at a place that doesn't even believe in employing fundamental pragmatic programming tools like a source browser. I suppose all the printouts are on green-bar from the chainprinter?
The computer can understand and run any obscure syntactically and logicall correct gook you throw at it, but we invented high level languages to allow humans to express concepts at a higher level than 1s and 0s. Mandating that all code be understandable without tools designed to manipulate and understand it smacks of voodoo coding.
Oh No! Another anti-OO "relational alegebra is all we ever need" rant by Tabilizer. Remember the term from back in the vinyl LP days, "broken record"? Now we say a CD is skipping.
How is this different from a story posted two days ago?
Yes, 1990. I was quoting from amazon.com since my copy was at home (sitting in a place where I do a lot of reading, hehe). I have it in front of me now: Copyright 1990, Prentice-Hall 2nd printing paperback. Even more classic. It should be required reading.
WHY are requirements changing? Because they do, and they always will. No matter how hard you try to hold back the waterfall, it will drown you. Deal with the fact that you are lucky to get 80% of the most important requirements up front. Deal with the fact that some of those will change anyway, as the users get more comfortable with the solutions. You must be flexible and able to handle change or you'll bust a blood vessel in frustration at "wishy-washy" users.
Read, for example, Wicked Problems, Righteous Solutions , written in 1998. Not exactly radical bleeding edge stuff.
if you are constantly changing critical code, you need to worry more about your development practices and not your testing.
Not true in many developement shops. With short iterations, refactoring, rigorous unit testing, collective code ownership, and continuous integration, code can be constantly changing but stable. Take for example the Mozilla Tinderbox. Development proceeds on many components and the builds and tests are run continuously. There are daily build smoketests (download a daily build and you'll see the smoketest menuitem), and sometimes things are broken for an hour or a day, but overall things just get better.
Embrace Change.
On a serious note, consider the locations of all the hot network jacks at your employer. Are any of them in public locations that are empty at times, say conference rooms in common areas? How easy would it be for someone to go in, plug in a lap top, and start up a packet sniffer? There are aspects of your network that need physical consideration other than the server room.
That's about as scary an assertion as I've ever heard from a developer on a large software project. Quite the opposite, the bigger your team, the more you need that automated build and smoketest. But I thinkJoel can say it better than I.
KDE and Gnome releases are fine, but compared to the Mozilla build/release process, managed by the enigmatic Leaf, they are 2nd class. Mozilla developers created their own tools to do it, too. Mozilla is cross platform, continuous builds, bug tracking integrated with version control, and they released regularly on a five week cycle (now quarterly), and daily build and smoketests. And once again, Mozilla is cross-platform -- Linux, Windows, and Mac OS 9/X.
Sorry to crash the party, but I have yet to see KDE or Gnome approach the bar that Leaf and Brendan Eich set high.
A couple of search terms that you'd never come up with if you weren't already steep in the the arcane x.500 world: ISODE and quipu.
Most of this stuff comes out of and is maintained in Europe. As the RFC 1330 says,
"The ISODE is not proprietary, but it is not in the public
domain. This was necessary to include a "hold harmless"
clause in the release. The upshot of all this is that anyone
can get a copy of the release and do anything they want with
it, but no one takes any responsibility whatsoever for any
(mis)use."
You can still find the latest downloads via FUNET.
Be aware, this stuff is a major effort to compile and get working. It's big and complex, but well documented. Have fun, and let me know when you get dish -user "@c=$(COUNTRY)@o=ORG@cn=Manager" to give you a prompt.
It is my sincere hope that everyone here on /. realizes that the USA Patriot act (horrible name if there ever was one) already mandates that certain businesses create and maintain a database of people that they FBI thinks might commit a crime. As discouraging as this one small case in Wilmington is, it's peanuts compared to what the feds are requiring. For example, a story on Yahoo News discusses the detailed data that colleges are required to collect and frequently transmit to the INS. Simliarly, business like bookstore and banks, libraries, and the phone company are now required to keep information on their customer "just in case" they commit a crime or are suspected of committing one.
If AP wasn't writing for the masses, they might have said, "the co-inventor of object-oriented programming".
I'll let the late genius speak for himself, though: Kristen Nygaard's home page.
Not only that, but in the US at least you can be taken to court for libel if you write that someone is a criminal before they are convicted. As long as you drop in "alleged", though, you can pretty much lay out all the facts. For example: WorldCom execs defrauded customers and stockholders and bilked their employees out of insanely huge wads of cash to line their own pockets, allegedly.
And the winner will come out stronger and with no serious rivals. Prepare to be crushed.
Fantastic Voyage
Incredible Shrinking Man
Attack of the 50 Foot Woman
Them!
Giant
The Iron Giant
My Dinner with Andre the Giant
anything with Ray Harryhausen animation
The Unshrinkable Jerry Mouse
In my defense, I only said Mozilla is pretty well factored code. There are around 4000 .cpp files in the 1.0 source, though, and nsDocSHell isn't even in the top 10 in size! Take a look at nsCSSFrameConstructor.cpp, for example -- definitely a candidate for serious reorganization.
You refactor when you find you have bad coupling. This is the same criteria that has been used since back in the dark ages of structured, procedural programming.
It's always good to see the grey-hairs confirming that what seems new and different and untested is in fact obvious and essential for junior programmers to know. Repackaging it a Refactoring may not add anything new, but it does place it in a context that's more accessible to those not raised on FORTRAN and COBOL. Plus, when the old classics are out of print and hard to find, it's good that the new refactorings of the information are still on the shelves at Amazon.
Having a thousand 10 line files does nothing to improve maintainability.
My obligatory plug for The Mozilla Project. Not quite one function per source file, but definitely lots of very small source files, each implementing a very narrow slice of functionality. Mozilla is pretty well factored code, and maintainability is enhanced by the separation of responsibilities. It makes it possible to enhance or fix problems in one area, say the in nsFTPChannel, and know that all the thousands of other lines in the program will be largely insulated from those changes.
Yes, it does take a while to get familiar with the entire Mozilla codebase. The flip side is that you only have to look at and understand a small fraction of it to start becoming productive.
If you are using C++, Large Scale C++ Software Design is definitely a recommendation I can second.
There good news is that there are great tools for automating refactorings for some languages (Java and Smalltalk come to mind immediately). The bad news is that C/C++ is not one of the languages, but C# is.
That said, some of what refactoring browsers do can be done with search and replace. Be careful though, you don't want to change all occurences of "i" to "index" and end up with code that won't compile because there's no type "indexnt".
The ability to rollback refactorings is essential, too. Industrial-strength source control tools are pretty much a necessity, allowing you to re-get your CVS tree if a refactoring attempt gets out of hand.
Since I bought Martin Fowler's book and started studying refactorings, my code has gotten much easier to live with. I no longer fear making a significant change to add functionality or fix bugs because I know I can refactor and still have code that continues to work as before. The addition of unit tests has helped to ensure that it not only keeps working, but it keeps behaving as expected.
Maybe it's a spoiler, but maybe for people who haven't read the book, they'll think of it like Obi-Wan coming back whispering in the first Star Wars movie. Or maybe they'll think it's a dream sequence, or a flashback, (like showing Isildur on Mount Doom in FOTR) or any of another million possibilities that don't require Gandalf to actually return from the dead. You and I know what comes next, but just showing Gandalf in the trailer for TTT isn't an automatic spoiler.
Just a confirmation that sourceforge.net is blocked by SmartFilter. I'm seeing the rejection message sitting here at work. How silly of them.
I don't work for them, but I find the Construx Software Reading List to be an excellent guide. It has preferred and alternates for various topics. Here's a sampling:
Introduction to Algorithms, Thomas H. Cormen, et al
Code Complete, Steve McConnell
201 Principles of Software Development, Alan M. Davis
The Design of Everyday Things, Donald A. Norman
Fundamentals of Database Systems, Ramez Elmasri and Shamkant B. Navathe
Design Patterns, Erich Gamma, et al.
Software Runaways, Robert L. Glass
Wicked Problems, Righteous Solutions, Peter DeGrace and Leslie Hulet Stahl
The reading list also includes classic articles and recommended periodicals.
It has to be said -- maybe if you did do XP-style unit testing you'd get better results?
"I can't imagine this mattering much".
How hypocritical to be so in favor of open source but irredeemably dissing Mozilla. Oh wait, compare the kind of work that went into slashcode and the quality of the resulting codebase to the Mozilla project. Maybe Taco's definition of open source doesn't include quality code developed by a professional team using good software engineering practices.