Slashdot Mirror

You might find Pair Programming, 40-hour week and continuous integration a little more exciting. I'm not saying that it works or even that you should have heard of it, but a "quick look" is definitely not a good reason for rejecting it.

Personally I find that some of its suggested methods are right on the spot while others a bit on the idealistic side. Still, I would like to try it and see first-hand how it works in a proper business environment.

You might find Pair Programming, 40-hour week and continuous integration a little more exciting. I'm not saying that it works or even that you should have heard of it, but a "quick look" is definitely not a good reason for rejecting it.

Personally I find that some of its suggested methods are right on the spot while others a bit on the idealistic side. Still, I would like to try it and see first-hand how it works in a proper business environment.

The simplest thing that could possibly work (don't design more than you already need, and be ready to evolve it) is a tenet of XP. AbstractFactoryContainerXYZYourMom instead of a getter sounds like architecture astronaut-grade overgeneralized design in advance (or slavishly following design patterns instead of adapting them to your needs). Pair programming doesn't guarantee that what you were doing was XP.

http://c2.com/cgi/wiki?EmbraceChange

That is something that should be read by all "Waterfall" developers like you. It is very useful, even if you don't change your opinion.

Damn. IHBT. :)

All of you who have seen "a written and documented plan" (aka the waterfall method) succeed without coming in late or overbudget raise your hands...I thought so.
The waterfall method rarely if ever works.
For more waterfall info
Those who are interested in software development should read:
The Steve McConnell Books
The Tom DeMarco Books
The Brooks classic: The Mythical Man-Month: Essays on Software Engineering
Death March by Yourdon
The Pragmatic Programmer: From Journeyman to Master
by Andrew Hunt and David Thomas
Design Patterns
Fowler's excellent Refactoring: Improving the Design of Existing Code
AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis

More information about XP can be found here or here.

Kent was not alone, but yes he was one of the earliest advocates of patterns -- He is also a good friend of Eric's (its not that big of a community).

As I mentioned here A good place to learn more about these topics (including Extreme Programming) is to go to the Portland Pattern Repository Which is also, incidently the first Wiki.

Tell that to Kent Beck

An alternative to designing software using patterns is to refactor code toward patterns.

This is considered one of the best ways to use patterns by many in the patterns community -- especially to avoid the "little boy with a pattern" syndrome described by many here.

For more on this idea, and on patterns in general check out the Portland Patterns Repository. There is also a conference every year about patterns called PLOP

Finally, the software patterns community owes its origins to the Architectural (think buildings not code) Patterns world. Christopher Alexander is considered the father of patterns. His books A Timeless Way of Building, and A Pattern Language are technical, dry and expensive, but considered fundamental to truly grokking patterns.

It's good but there are lots of places on the web that provide similar information.

I'd recommend reading it more than buying it; if your experience is similar to mine then you will probably end up going through it once or twice, thinking "ah, I used that in such and such a design", use it as a reference once or twice and then leave the book sitting on a shelf gathering dust. It has changed the way I design systems (for the better) but I also found that it was quicker to build up an overall understanding of unknown code written using patterns, simply by spotting where they're used.

There's a lot of information in the wiki at www.c2.com; it's probably useful to read:

http://www.c2.com/cgi/wiki?PatternsForBeginners provides a reasonable introduction.
http://www.c2.com/cgi/wiki?DesignPatternsConsidere dHarmful

The patterns themselves can be dangerous, as I've found myself on some occasions, as they foster a detachment from the implementation details. There is a tendency to knock out code quickly because you know the design well, but the resulting code contains subtle flaws that aren't considered in the GOF book.

Alexandrescu's book, Modern C++ Design, discusses the implementation of factory patterns, visitor and singleton, which is regarded as being one of the simplest patterns to understand but hard to implement well. Apparently one of the authors of the GOF book once stated that he wished singleton had not been included in the book.

For interest, perhaps look at
http://c2.com/cgi/wiki?SingletonsAreEvil

It's worth buying if you can't find a copy to read and you have the spare cash at some point, simply because it can be hard to find information on some of the less used patterns in the book on the internet.

Hope this rambling is useful.

It's good but there are lots of places on the web that provide similar information.

I'd recommend reading it more than buying it; if your experience is similar to mine then you will probably end up going through it once or twice, thinking "ah, I used that in such and such a design", use it as a reference once or twice and then leave the book sitting on a shelf gathering dust. It has changed the way I design systems (for the better) but I also found that it was quicker to build up an overall understanding of unknown code written using patterns, simply by spotting where they're used.

There's a lot of information in the wiki at www.c2.com; it's probably useful to read:

http://www.c2.com/cgi/wiki?PatternsForBeginners provides a reasonable introduction.
http://www.c2.com/cgi/wiki?DesignPatternsConsidere dHarmful

The patterns themselves can be dangerous, as I've found myself on some occasions, as they foster a detachment from the implementation details. There is a tendency to knock out code quickly because you know the design well, but the resulting code contains subtle flaws that aren't considered in the GOF book.

Alexandrescu's book, Modern C++ Design, discusses the implementation of factory patterns, visitor and singleton, which is regarded as being one of the simplest patterns to understand but hard to implement well. Apparently one of the authors of the GOF book once stated that he wished singleton had not been included in the book.

For interest, perhaps look at
http://c2.com/cgi/wiki?SingletonsAreEvil

It's worth buying if you can't find a copy to read and you have the spare cash at some point, simply because it can be hard to find information on some of the less used patterns in the book on the internet.

Hope this rambling is useful.

It's good but there are lots of places on the web that provide similar information.

I'd recommend reading it more than buying it; if your experience is similar to mine then you will probably end up going through it once or twice, thinking "ah, I used that in such and such a design", use it as a reference once or twice and then leave the book sitting on a shelf gathering dust. It has changed the way I design systems (for the better) but I also found that it was quicker to build up an overall understanding of unknown code written using patterns, simply by spotting where they're used.

There's a lot of information in the wiki at www.c2.com; it's probably useful to read:

http://www.c2.com/cgi/wiki?PatternsForBeginners provides a reasonable introduction.
http://www.c2.com/cgi/wiki?DesignPatternsConsidere dHarmful

The patterns themselves can be dangerous, as I've found myself on some occasions, as they foster a detachment from the implementation details. There is a tendency to knock out code quickly because you know the design well, but the resulting code contains subtle flaws that aren't considered in the GOF book.

Alexandrescu's book, Modern C++ Design, discusses the implementation of factory patterns, visitor and singleton, which is regarded as being one of the simplest patterns to understand but hard to implement well. Apparently one of the authors of the GOF book once stated that he wished singleton had not been included in the book.

For interest, perhaps look at
http://c2.com/cgi/wiki?SingletonsAreEvil

It's worth buying if you can't find a copy to read and you have the spare cash at some point, simply because it can be hard to find information on some of the less used patterns in the book on the internet.

Hope this rambling is useful.

Maybe if you are a 20 year old with no life outside work you could do that. However, I've built similar system working 40/50 hour weeks. Some of these have been running in production for over 15 years.

Read about Heroic Programming. I feel sorry for the guys who had to maintain your code...

Also, wikis in general are group authorship, although most don't aim to produce books. See the Portland Pattern Repository's WikiWikiWeb for an example.

Check out Martin Fowler's Enterprise Architecture Patterns, some of them can apply to any type of GUI. The MVC pattern does not just have to apply to single components of a window. But there is a difference between creating the GUI architecture for a CAD type program as opposed to a Business type program. For example: CAD programs can have thousands (or more) of objects on the screen at the same time; so modelling each as an object will bring your program to it's knees (using the Prototype pattern can help here).

You might try searching google for 'CAD GUI' or something similar; I've seen articles / web pages that discuss GUI's that are not database backed / business related, but I don't know the addresses off-hand.

Then this guy who says he communicated with the publisher and they indicated that it would be coming out in three parts starting next July, must be telling a story:

Usemod is another popular wiki, and there are dozens more WikiEngines, many of them licensed open/free.

There's also the book, The Wiki Way.

You could probably build something on top of Zope (which comes with a ZWiki component), and might find a href="http://www.gzigzag.org/

Usemod is another popular wiki, and there are dozens more WikiEngines, many of them licensed open/free.

There's also the book, The Wiki Way.

You could probably build something on top of Zope (which comes with a ZWiki component), and might find a href="http://www.gzigzag.org/

I am guessing that someone could write a plugin for any wiki system todo the pointless little map of information with little lines on it

I am guessing that someone could write a plugin for any wiki system todo the pointless little map of information with little lines on it

Look at SeattleWireless' HowDoesThisWikiLookLike there are few pages with a lot of references to or from other pages, and many pages with few references. It seems to follow a 'power law' too(~ 'scale free').

So, the 'inside' of the web seems to follow the same rules. It is particulary interresting with wikis because of the unplanned, distributed growth (like the Internet).

As the belgian provider, where the pictures are, seems to be down. You can also see the pictures in ReseauCitoyen.be's TopologieDuWiki

I thing it would be a good idea to have a discussion on /. on the Wiki phenomenon (sites everybody can contribute to, like WikiPedia.com ( more than 95,000 pages!).

I know of only one book on the subject : "The Wiki Way: Collaboration and Sharing on the Internet" by Bo Leuf, Ward Cunningham (of c2.com, creator of the Wiki concept).

If you search Google for 'RecentChanges' (a good marker for wikis (?)), you get a lot of them, more and more (A survey by country domain sept->oct 2002)

There are some scientific papers at GaTech.edu

It will save you time and money because you won't end up buying/writing something you don't need. And you might be surprised how useful index cards can be...

Sure, because it's much easier to say what you mean in one flawless take than to type it up, edit and then send. Of course, video's also a lot easier to edit than plain text, if you do make a mistake. Also, it'll be nice to know that your clients can see exactly what you look like at 8.30am on a Monday.

For fuck's sake. Let's not even go into the surround sound. How are these people still in business?

All the fancy screens and video technology won't disguise the fact that Microsoft Office is a bad way to work productively with computers. The document-oriented model (based around preparing documents for print) is outdated - try collaborating through a wiki for a week and you'll see what I mean.

I can only imagine that this is some sort of disinformation campaign to fool the competition.

Worst thing that can happen is some subscribers start bouncing mail, and you drop them (and tell them why). Not your problem anymore.

I'm suddenly reminded of DoNotWantItGoodWantItTuesday. I'm sure the WikiWeb will love me for sending the hordes over there. 8-)

The next step will be HashCash viruses, which use up CPU time on the owned machine making tokens and sending them somewhere.

My back-of-envelope calculations say that each spammer with the T1 line will need to r00t a thousand boxes to put postage on all his spam. Then those boxes need to be left on 24/7. Most random victims switch their machines off after two hours.

Sometimes, the accounting overhead costs more than the thing is worth.

We need a solution to spam, but this isn't it. There really aren't that many spammers; put fifty people in jail and it will stop.

Putting spammers in jail won't stop the otherwise-reputable companies joining in the spam game, it will simply set up a framework in which they can get state approval for spamming.

You can't put Chinese or Korean spammers in US or British jails. Not unless you romp over there with a load of tanks and kidnap them. It's not really polite to blacklist the whole of China, is it?

Also, putting spammers in jail will make it more attractive to forge spam to appear to come from someone else. Like we have now.

virt just relased his chip tune disk fx 2.0 on monotonik. the professional game musician, who made the soundtracks of several games on the nintendo platform, re-scored 15-year-old nintendo titles from konami, as if he were actually soundtracking them at the time. you can download them there for beer -- and have a look at that great cover!

Here's a good reference: Forty Hour Week on c2.com, which seems to be the best web authority for Extreme Programming discussions and patterns.

Give it a gander.

Here is the original WikiWikiWeb: http://c2.com/cgi/wiki?WelcomeVisitors
Here is a Wiki you can easily install on your own machine: http://minnow.cc.gatech.edu/swiki/15
Here is a free Wiki farm that let's you start your own on a shared server: http://www.seedwiki.com

Blockquoth bons:

When programming in a literate system do you describe the objects and methods from a programming viewpoint, a business viewpoint, or from a metaphor viewpoint?

At its heart, literate programming creates multiple documents from a single master document. The common case is creating two documents - a document that is a paper on a program, and a document that compiles to the program - from the master document; but it's entirely possible to create more than just the two documents with a tool like noweb.

As an example, you could produce API documentation, algorithm descriptions, a description of the interaction of the whole schebang, and the program source itself from a single set of master documents.

And, again, the gain of literate programming is that you can keep all these forms of documentation close to each other and close to the code, which is a win.

Now, noweb isn't perfect: it's optimized for creating just one set of documentation, so the other documentation would have to be treated as code. It would be a lot better if you could name documentation blocks just like code blocks, but oh well...

When we build systems, we work directly with the client and we are able to describe the system in three equal, but very different ways. Depending on the documentation required and the target audience, we can describe the system in a way that allows everyone involved to communicate effectively. This is an advantage I don't want to lose.

From what I've read, literate programming seems to be a discipline that works best when the programmers are isolated from the client. How it works when the programmers and the client closely interact is something I simply don't understand.

We've all heard rumblings about age bias in programming--they'd often rather underpay an desperate, overcaffeinated twenty-year-old than have to listen to that old cuss who can explain why the project is doomed. As a colleague (hi Dan!) put it, the two career paths for a programmer are

1. graybeard
2. management

You can stay focused on coding if you're the local guru who knows the systems inside and out (in fact they might be afraid to try to go on without you), but there's always the risk your expertise will suddenly be obsolete, and many companies don't even realize how much they needed one until they get rid of them.

At 31, I'm slowly picking up project management (mostly by choosing jobs likely to let me do some, and reading), because it's easier to sell (nobody sane thinks they don't need it) and age mostly improves credibility. And somebody's got to oppose the industry's gratuitous complexity (or "cover fire", as Joel Spolsky puts it) in favor of the simplest thing that works.

A long time ago I worked at a small software company that sold eductional software to schools, for the Apple ][ and similar computers. Schools classified computers as A/V, which meant they went in the library, which meant the librarian cataloged software, which meant that we got back a lot of 5" floppies with library cards stapled to them.

You might want to give pair-programming a try. Although it certainly doesn't feel natural at first, with a little practice, it's possible to use this to spread knowledge and maximize code efficiency across the code base.

If you are the most experienced developer, it gives the other developers a chance to see how you begin solving problems, and a chance to see your code as it emerges. It's important however, that you don't do 100% of the coding in your pair. Spend approximately half the time letting your partner code. This provides an opportunity for them to generate code, and gain some confidence in their abilities.

After a period of time, you should mix up the pairs, so everyone has a chance to work with everyone else.

As I said, this method of working feels extremely counter-intuitive at first, but with a bit of practice can really make a difference (especially on teams with widely disparate skill levels.)

As an added bonus, developers are less inclined to slack when they've got someone working with them, meaning you'll tend to get more productive hours out of each developer/day.

Check out this link for more descriptive info, and some discussion.

Writing software is not difficult. Writing high-quality software _is_ difficult and requires experienced craftsmen (infer journalistic gender-neutrality, please).

So how then, can you get high-quality software quickly? Two ways:

1. Hire experienced experts. Experienced experts produce high-quality work quickly. They write code generators to do tedious work for them. They classify problems and hunt down and implement reusable solutions. Keep giving them raises and interesting problems. Granted, defects in the software will be of the extremely intractable variety (very subtle design flaws or bad/wrong requirements)
2. Reuse experienced expert knowledge and technique in the form of pattern-driven code generating tools. Hire journeyman developers to adapt the code the tool burps out and get on with life. Keep an expert or two around to extend or correct the patterns the tool uses for generation. You'll get applications that are far less pretty than the hand-crafted variety. On the other hand, the defects are known and predicatable. Tools (apologies for the shameles plug) for this sort of development are just now becoming available and practical. Granted, when handed a powerful implement fools often find a way to hurt themselves (thus instantiating the 8th corollary to Murphy's Law).

Either method has drawbacks. #1 produces the best software, #2 produces the cheapest software. #1 makes the "Agile" crowd happy while #2 is the sermon of "Software Engineers."

Why single-out developers for defective code? Because developers write defective code. No, all developers aren't clods with text editors. Developers who do write buggy code may even care about their craft (Pragmatic Programmer tip #1). But developers themselves are to blame for the defects in their work, even though outside factors contribute to problems. We must take responsibilty for our bugs, move on and fix them. Then find new ways of working that make it more difficult for software defects to make it into production evironments.

We cannot fix imperfect programmers. We can only mitigate the effects of their imperfection through mentoring, certification, education, and proper management. In other words, treat software development as a craft, a talent to be polished and perfected.

Writing software well means communicating well with a computer. Artful written communication is very difficult to reduce to an engineering discipline, yet the skill can be taught and practiced.

I'd actually consider these separate types of bugs. They're both design problems. The first is of the type that can often be remedied by either a) forming your requirements better or b) performing peer design reviews.

The second is what the XP-people would call a "code smell". I've found Fowler's Refactoring book to be quite useful in figuring out ways to fix the design such that the "I made a change in these six places but forgot that one" (and other) bugs go away.

If your api says 'you can't pass a null here', or 'must be between 1 and 7', put an assertion inside that invocation, let the computer test it for you at runtime.

See Offensive Programming for a discussion of this kind of thing.

Put the pertinent information in a WikiWikiWeb, then any of your admins can access or add info from any web browser that can see the Wiki server. Plus the whole idea of Wiki is so neat that they'll want to use it and watch it grow.

We have just started to use a wiki for this purpose, and it looks good. We use MoinMoin, a wiki written in python which does versioning, and can send email notifications when a page is updated. People are documeting much more than before.

On the contrary, in my opinion, AudioGalaxy was the absolute best such service for the mac because AG didn't support it. AG was shit for windows becuase of the cruddy client, but for the mac it was great because you just used one of the non-supported third-party clients, all of which were excellent.

This brings up my question, though: third party clients. Is there any reason the extant 3rdparty clients out there could not just be set to, instead of talking to the now-crippled audiogalaxy server, talk to some independent audiogalaxy workalike? How difficult would it be to create an open-source implementation of an AudioGalaxy server, given we already have many open-source third-party implementations of clients? OpenNAP meets OpenAG? Cut loose, the way GiFT has cut loose from kazaa.

I am just curious.

In the meantime, may i assume it would maybe be possible to take the idea behind audiogalaxy (everyone publicly queues stuff they'd like to download someday, and transactions are negotiated automatically as bandwidth becomes available on all sides) and someday recreate it as a wholly-decentralized gnutella-style network? Or do you need that central authority doing the negotiations for you to keep everything from falling apart? I would have to think about the idea some more. You could maybe do it. If you tried, how would the web page frontend thing be handled? Would we just have to throw that idea out?

I always thought that was the most disappointing thing about AG-- their "featured artists" were pretty good compared to (say) napster's, but i always thought it would be really neat if AG fufilled its potential as a site with a message board for every song in existence. This would be a godsend for those of us who like to collect really obscure music, especially bootlegs and such-- it would be convenient if, upon running across a track labelled (say) "Nine Inch Nails - eraser (Utter Desolation Remix -- Unreleased)" i could type that into a website, and even if i couldn't download the mp3 from there i could see some discussion and find out "this is fake" or "this is from X bootlegs & rarities compilation" or "this is a b-side from the japanese single of Y, only they renamed it". Allmusic.com meets everything2.com, or something :) Could a community-run version of such a website somehow tie into a decentralized community-run version of the AudioGalaxy idea? How would the client and the website communicate? A browser plugin, maybe? It would have to be something sufficiently disconnected to stave off the Out of Court Settlement Smackdown.. perhaps each webpage on the website could have an ID number / checksum, and you'd just cut&paste that ID number into your OpenGalaxy Client? Perhaps the "download this song" thingy could be inserted via some kind of variation on thirdvoice, and the people who run the website could just insist, honestly officer, we can't help it if the mp3 pirate people choose to use our database as a base for checksumming and such. We just run a message board. We aren't connected to those people. These aren't the bots you're looking for.

Ah well, idle wondering. In the meanwhile, i guess now i gotta go hit AudioGalaxy's site to find out how to inform them i give them permission to redistribute the music i own the rights to.. (Not that anyone *wants* to listen to my music.. just that it's the principle of the thing :) )

• The Rules
• The Wiki Roadmap

Though this isn't directly Apache related, one more aspect of scalability is code flexibility and ease of change.

Don't be short-termist just because the person generating the business requirements thinks like that. After you're up and running, things may still change. By using good design patterns you'll find it easier to add new functionality or change the system behaviour.

I think any wiki clone will be more appropriate. Try
phpwiki
(in perl) usemod wiki.
There are dozens more clones.

I think any wiki clone will be more appropriate. Try
phpwiki
(in perl) usemod wiki.
There are dozens more clones.

perl only really starts to fail when you consider it a panacea. it will not do everything for you, and there's some things that it just plain sucks at.

What are you talking about? There is nothing Perl cannot do!

I did not read all the comments yet, but I did not found the word wiki in them... This is a powerful technology for building something together. It is sometimes difficult to keep the structure sound but some are used with success in wireless community networks seattlewireless is one, wireless-fr is another one (in french). General info about wikis can be found on Google directory/Wiki A lot of implementations now exist (I prefer phpwiki), the original one is on c2.com Some of them, like TuxScreen allow you to protect modifs with a login.

I find that a lot of useful discussion on this fairly new and therefore not down to a textbook analysis process can be found at Wiki. Wiki is a bit confusing but whats there is evolving as quickly as the field.

Now excuse me as I go rig my code so my boss will sign off on it before the deadline...

There is an entire movement that advocates Test Driven Programming. It's not such a bad idea, you just need enough tests.

You can get one from here as well as other places.

Put it online, do various things to encourage each department to use it, put some of your own content on it, make sure students know about it and so on. One of the first things to use it for is to start a discussion for feedback about how the campus can be improved.

For more on what a wiki is, try The Portland Repository. I would explain in detail, but after you go through the introductory pages there, anything that I could say would be redundant.

There's a difference between two. Open-source means anyone can take your source code (in LaTeX or something like that), make some changes and produce his own version of the book. I have some doubts about this model, though. Most ot the free books I've seen are just free. Anyone can use them but not contribute.

If you really want to produce a "collaborative" book, take a look at the Wiki model.

Don't know about Slash.

Stephan