Besides, if a hop is aroung 100m, a packet travelling 100km would be a 1000 hops away!
This is assuming a Gnutella-like set-up. Most likely, the "stems of the lilly pads" would be connected by fibre optic to a common routing station with a big fat pipe to a service provider. A packet travelling 100km would be a half dozen hops away or less like it is now. You don't go hopping from Wi-Fi lillypad to lillypad to your destination.
I'm an Emergency Medical Technician on a US Public Health Service Disaster Medical Assistance Team (DMAT). I am required to be accessable by pager or cell phone 24/7/365... Are you suggesting that... I resign myself to never seeing another movie or play for the duration of my service?
Yes. Too bad, so sad. You love your job, but it comes with negatives. You probably have to make special arrangements when you go out of town as well, correct? Think of going to the theatre as a two hour road trip very far away from work. If you are really on call at every hour of every day I feel sorry for you. You'd have to vacation at home! Boring! ZZzzzzzz.....
Yeah, good idea, punish everybody, including those that didn't commit any crimes.
If the crime is being a social moron, some people have to be protected from themselves. People will take advantage of a situation if they can, no matter how rude the behaviour - they are either ignorant or plead ignorance. Completely blocking cell phones gives them no excuse.
If you have a job that requires you to be on call, you probably also can't travel more than an hour or so away from where you work. If you don't like the side effects of having a job like this, maybe you should choose a different job.
Instead of allowing cell phones, why not just effectively jam cell phone signals from coming in our out of the theatre? I live in a basement apartment in a crappy building and I have terrible cell phone reception. Surely the theatres can set up some sort of blackout zone (ie. using E-M interference).
And for those that argue that some people might need their cell phones for emergencies, I say this: what the eff did these people do 10 years ago when people didn't have cell phones? Surely they can last 2 hours without cell phone service. For most people, cell phones are a luxury and not a necessity. Then if you want cell phone service during a movie, go to a crappy theatre. I'll be going to the ones that jam cell service so I can get some peace and quiet.
I'm surprised no one has mentioned this yet, but if you are working with a group of people and you don't know their abilities, divide the project up. If they don't deliver properly by their deadline, cut their original task in half and assign the other half to someone else (probably yourself), leaving them with less to concentrate on. Then rinse and repeat as necessary.
Don't accept poorly written code just because "it works". If you do, you endanger the project and don't help the poor coders become better. The best way to become a better coder (IMO) is to bang away at one single problem and not worrying about doing "your share" and ending up spreading your effort too thin. When your teammates prove they can handle more coding, give it to them.
If you do it this way, you'll inspire confidence that your co-developer can do the job right. This confidence will, in the long term, be more benificial to the project and to the company you work for.
The thing is, though, that women tend to take nice guys who treat them with respect for granted.
I think we're clouding the issue. Women like nice guys. They also like guys who think for themselves, do what they want to and defend themselves. In the common lexicon, this is called "having balls". The difference is that the former are like little brothers and the latter are the (so-called-by-nice-guys) "assholes" they date.
The correlation between niceness and lack of balls has been well documented. It's very difficult to be nice and defend yourself and be confident, as one deviation from nice behaviour will exclude you from the "nice guy" collective.
Some people also confuse this with "playing the game". The game is bullshit. If you're being yourself and you're confident, you preclude yourself from having to play the complicated mind game that nice guys have to play. It's that easy.
You just have to throw that bologna out the window and do what you want. Be your own person. Don't be a pushover. Save nice for nuns, priests and girl guides. Women are smart social animals and can see right through the BS. They respect that more than a nice pushover guy. Which is why they acutally DATE the assholes - the assholes are just being themselves!
Yes. I asked this question about six months ago, and a clever person pointed out that this would allow ZDNET to use a cookie with the com.com domain across its whole family of sites. Then they could track a person uniquely, customizing advertising, preferences or anything else. I don't know if they actually do this, but it would be a good way to do it.
Allow me to answer my own question about UML and XP:
That, coupled with the fact that there is typically one lead on a project that needs to know what's going on from a Software Engineering perspective. If he has 6 programmers going nuts on his code, he'd like to know where they are making bad turns today instead of in 2 months during a code review.
In the article linked above, Martin Fowler says:
At a conference dinner, Dave and I talked with a vocal opponent of XP. As we discussed what we did, the similarities in our approach were quite marked. We all liked adaptive, iterative development. Testing was important. So we were puzzled at the vehemence of his opposition. Then came his statement, along the lines of "the last thing I want is my programmers refactoring and monkeying around with the design". Now all was clear. The conceptual gulf was further explicated by Dave saying to me afterwards "if he doesn't trust his programmers why does he hire them?". In XP the most important thing the experienced developer can do is pass on as many skills as he can to the more junior developers. Instead of an architect who makes all the important decisions, you have a coach that teaches developers to make important decisions. As Ward Cunningham pointed out, by that he amplifies his skills, and adds more to a project than any lone hero can."
Clearly the emphasis is on training your programmers and then trusting them, instead of "police-ing" them by always looking at an up-to-date UML diagram. This I completely agree with. Not only are you encouraging consistency thoughout the team (also enabled by pair programming) but you are increasing the team's worth as well, reducing the all-the-eggs-in-one-basket effect.
I still think that having the large architecture view could help you educate your programmers and spot bad designs. Pairing them with more experienced developers could remedy this a bit, but it may not always be possible. Your junior programmers aren't going to start out knowing all of your wisdom. You have to be able to spot their poor design decisions early and tell them before they propogate more poor design thoughout the codebase, right?
We're kidding ourselves if we think that UML is automatically more intuitive for everyone. Or even for most people.
Like everything, reading UML takes practise. UML diagrams can sometimes be very dense, and it takes experience to extract all of the information and process it. It isn't "automatically intuitive", but at least you get a very large chunk of architecture on one page where you can see it all at once.
Compare this job to scanning a few thousand lines of code and it will probably change the minds of people that don't think diagrams are helpful. Maybe their jobs don't require a big-picture view and they can live in their unit or subunit and not care - the architecture diagrams are mainly for the architect or project lead, to keep the project on track.
Also, the project leads need to sell the idea of seeing the forest through the trees to their developers. If the developers have an idea of the big picture, they can make more educated choices for the project without much intervention from the lead. If the lead is constantly jumping in and telling the developer he's going in the wrong direction, you can just imagine how the developer feels. On the other hand, if the lead explains his decisions and gives answers to "why" questions, the developer will stay on track (and the lead will spend less time correcting the developer). The lead having a firm grip on the architecture at any given time is important for this reason.
As for Martin Fowler's comments; for normal projects, I don't buy it and it's a moot point anyway. If someone wants to shun UML and spend time shifting through code to see the design, let them. They are just shooting themselves in the foot, time-wise. If the reason they are not using the UML is because it is outdated (which is likely) then that's a totally different reason - I don't like using outdated information either. If the code and the UML are sync'd, there's no difference except the amount of time it *might* take someone to find the design and digest it (not knowing it previously). UML was made to speed up this process. If there are two reliable sources of information, the person is free to make their own choice.
Fowler is also advocating not using UML for the sake of XP, which is valid. XP is a developer-centric methodology. A developer sees a bad part of code and goes in and corrects it. Unfortunately, the "design" changes so much it's hard to get a snapshot. That, coupled with the fact that there is typically one lead on a project that needs to know what's going on from a Software Engineering perspective. If he has 6 programmers going nuts on his code, he'd like to know where they are making bad turns today instead of in 2 months during a code review. I can buy not using UML during XP development, but that's only because (as I see it) refactoring focuses on such a small, managable area of the code that you don't need to look at a diagram to figure it out. However, even in XP an architecture view would be handy, if only for the lead.
Whew, a little off topic there. Thanks for bearing with me. Just wanted to start up more discussion, if you are game.:)
What is necessary is a method for changing design gracefully. "Refactoring" is the best source I've seen that addresses this. Basically, you change methodically, and you test.
I was talking about this with a friend the other day. Wouldn't it be nice if a senior software 'architect' could maintain a unit-level view AND current code at the same time? That way his busy programmers could refactor all they wanted, as long as they didn't overstep their unit bounds but at the same time improve the product. The architect could look at the project at different levels of abstraction (units, subunits) to make sure the programmers aren't getting off track.
Probably the hardest thing about using the iterative or refactoring methodology is knowing what your architecture looks like at any given time. You design a great, flexible architecture for the first iteration, but after several rewrites you may not know where you are in terms of the big picture. Surely a tool that spits out UML-like diagrams of the current code would be very useful to spot architecture flaws introduced during the refactoring process. Effective use of design patterns may also help. Is it impossible?
I've seen some work done by Rational in terms of code generation with.NET, but wouldn't it be nice if you could get up-to-date architecture diagram syncronization with code directly from a source versioning tool (ie. cvs, SourceSafe)?
Everything MS says about Unix is at least 95% true. Just because its MS saying it doesn't make it untrue.
Fair enough, but since when did advertising turn into this? It used to be "Buy our project, it's great!" or "Buy our product X, it's better than Y!". Now it's "Product Y sucks and here is why. The logical conclusion is to buy our product X".
This kind of advertising leaves a bad taste in my mouth. The criticisms that MS makes may be valid, but their biased presentation of fact still doesn't tell me why I should buy product X. In fact, I question why I'd want to buy from a company that advertises this way. Probably because I have no other choice....
Maybe it's tired of Canada's 4 seasons: Almost Winter, Winter, Still Winter, and Highway Construction
Ahhh city folk. We call Highway Construction (summer) Mosquito Season in the bush. After going through that, you can't wait for Almost Winter to start up again!;)
also, you can make a compass [thinkquest.org] using a bowl of still water, a blade of grass, and a small sliver of ferrous metal. (like the hand of a watch)
What attribute of code makes it "refactorable", other than the things that make it good? To me, these are exactly the same thing,...
Heh... my explaination was pretty poor in that last one.
Ultimately, the properties of your code aren't really that important outside of readability and understandability. They are important characteristics, but are often overlooked when you know you are just going to go back later and replace that chunk of code you just wrote. Maybe you'll write a small note to explain how to extend it later.... not 'good practise', but it's good for quick development of a usable product (ie. fulfilling test cases), which is an important aspect of XP.
So really you just need to be able to see the big picture clearly by looking at the code. If you can do this, you can determine whether or not it is suitable to accept the new feature you are going to add or if the design needs to be rethinked (refactored) a bit. If you can spot the design from the code quickly, you can refactor efficiently. So all of the aspects that make code readable and understandable also make it easier to refactor or redesign.
The way I see XP is, you start out with a small managable design that you can get a basic product with. When you want to add features, you determine whether or not the part of the code you're working on can handle the feature and redesign it if it doesn't. To me, refactoring more applies to the design than to the code itself (ie. the forest and not the trees). It may seem weird to code this way, but the result is that you ALWAYS have a functional version of the product ready to test and use - albeit in the early stages a very limited piece of software.
But everyone probably has their own opinion of XP and refactoring. To explain refactoring outside of XP would probably take a lot more effort and experience than I have.:)
I'd even question its usefulness outside of XP for large projects - programs designed the old way tend to be a nice enough design for version 1.0, with feature after feature after bugfix slapped on top of each other. It would be a lot less efficient to refactor in this environment, you can imagine - a lot of hands have touched this code and made it a hard to understand mess. You don't want to break this fragile beast. But it still might be worth your while...
I'm not quite sure what "refactorable" means, but I want my code to be like this: * Good Cohesion * Low Coupling * No Duplication
Refactorable really means keeping your code in a state that allows it to be cheaply and quickly refactored. If you have to spend hours and hours to refactor you code, it's not worth it - it might be cheaper to rewrite it. If you consciously write your code so that it can be played with (ie. it's readable, consistent), you will have better luck.
Sounds like he could save quite a bit of time and maintanence nightmare if he just invested the effort to write it well the first time.
This is counter to the XP get-it-out-the-door-with-the-minimum-amount-of-wor k thinking. If you only need your function to do one thing right now, only implement the one thing right now. No use making the function more complicated - you'll only 1) take more time to implement it and 2) make it more complex which adds opportunity for bugs and increased testing cases to handle.
Having minimally implemented functions also lets you have an almost-always exectuable codebase, which is important to XP.
When you see that the functionality NEEDS to be extended, you extend it. Not before. You can still make the design before you write in that code for the other 4 features, but holding off from coding and then refactoring them in later incrementally will make your testing and maintaining life a lot easier. Just keep in mind you are going to refactor if you want to make it easier to incorporate them in.
No one uses the out-of-the-box version of Win95 anymore, do they?
Two things about Win95: 1. Microsoft no longer supports Windows 95. 2. USB is not natively supported in the early versions of Win95 (and later versions are spotty, they get it right by Win98).
So on that level, Joel's arguments are flawed. Less and less people will be testing on Win95 because MS doesn't support it any more. The WIN baseline now starts at Win98.
Another thing: if you DO use Win95, do you test the off-the-CD version or the highly patched (practically Windows 98) version? Grey grey grey area, Joel.
Having apparently never worked on a team in the Real World and had a piece of code delivered that was so hideous that the only thing you could really do with it is have it taken out and shot. XP Practices can help you avoid having such a hideous piece of code delivered in the first place, but you'll have a had time convincing small shops to do pair programming.
I agree that what he suggests is XP-like, but it doesn't require pair programming. You can't make a 3 story house of cards into a full-sized brick house, no matter how hard you try - design is paramount to refactoring.
I think people get confused when they read about XP and think design is ignored and everything is done "as you go". It's definitely not! You still have to keep in mind where you are going, even though you are only implementing for the present. Not only does that enable you to refactor, but also cuts down the refactoring time itself.
Joel's code is inherently refactorable because he's used to writing like that - and used to refactoring. What Joel hasn't said is that you have to purposely make your code easily refactorable from the outset, otherwise you'll spend your whole life refactoring from one feature to another.
So take your hideous house of cards into the middle of the street and shoot it if you have to. Refactoring may just be a waste of your time if the design is not easily refactorable.
Seriously, though, next time, take another route home. Zeppelin or something.
All kidding aside, Newfoundland is an ISLAND. There aren't too many ways off of it - and taking a ferry with your car takes a good chunk of time. That is, if the professor can even drive.
Driving from Newfoundland to Toronto would probably take 2 or 3 days, for someone that doesn't travel by car a lot. Heartier drivers might be able to do the whole thing in 24 hours.
Another unverified, just my personal experience, YMMV tip is only keeping static installs of programs on your C drive (partition) including the icons on your desktop.
I change the MyDocuments, Internet browser cache and downloading directories (ie. for stuff like Kazaa) folders to another partition (I call mine SCRATCH) and keep all temporary stuff there. After I know I want to keep the data, I move it to yet another partition that stores 'permanent' data.
This technique minimizes fragmentation on your C drive (and on the 'data partition' to a lesser extent). Fragmentation slows loading times of software, because the OS can't load the program in large contiguous chunks if it is fragmented all over the place.
Short of reinstalling Windows every 12 months, this is what I do to keep my programs loading quickly in Windows. It would be nice if this was done automatically though.:)
Microsoft is not about to shoot itself in the foot so massively. Whatever this ends up being it's a good bet it will be fully backwards compatible.
Out of all of the discussions here, this is what I don't understand the most. Why offer backwards compatibility over say, a conversion utility?
You have your old data on partition A with the NTFS, fine - keep it. Your new operating system runs on partition B with the new MSOFS (MS Object File System) and whatever data it produces it saves to the OFS partition.
Why can't these two file systems exist together? The only disadvantage is that the NTFS partitions will not support the OFS features. Big whup, you can still use those files... you can have a general file converter execute when a user opens an NTFS file in an OFS application.
Maybe they'll even have a seperate file converter app so you can migrate files from your NT partitions to your OFS partitions and label them with metadata as you go, if that is what you need.
Considering built-in backwards compatibility for MSOFS just clouds the issue, it's not necessary for the success of MSOFS - they just need good conversion utilities so that people can reuse that legacy data.
Also, if they leave WIN32 and NTFS behind for one superior (though not in performance) FS, they are probably better off. They just need a way to get there.
... but that's just my opinion, I'm probably wrong.:)
It isn't possible to make a secure form of media distribution unless you control the playback devices as well.
You have a good point. And we all know how well 'secured' playback devices that offer a pay-per-play model - DIVX - work: they don't. Techies blow the whistle on them, and they should.
Go back to a tip-based society, make money on live performances and tangible goods, or something.
I can't agree more. Tip-based solutions will allow people with a conscience to contribute. Radio stations will still make money from advertising even though they are playing 'free music'. The hard part will be financing videos and promos, but all of that crap is well, marketing crappola.
Letting musicians survive off of plain old word of mouth (which incidentally travels much faster these days) instead of mass marketing is very doable. Musicians could even market themselves - they don't need some monolithic middleman to tell them how to take care of their own business. Right now they are being forced into a system, and it's the system that's bitching and whining, not the musicians.... well, except for those Metallica bitches.
And perhaps only people who care about music will become musicians!
And the music community will be all the better for it, IMO. Music celebrity won't be an excuse to get rich quick on a hot tune - a la Milli Vanilli. You'll actually have to have a large fan base if you want to get the larger t-shirt and concert revenues - and to get a large fan base you need to make GOOD MUSIC! What a novel idea.;)
Imagine a proposed law that said, since shoplifting is common and unstoppable, all customers at every store will be stopped, background-checked, and strip-searched.
Ah, but it is common for stores to have to raise prices for everyone to compensate for shoplifting losses, which IIRC are in the $billions per year.
The difference is that most things you can shoplift are tangible goods. Digital media can be made tangible, but the "manufacturer" cost of making a copy pales in comparison to the actual value of the "content". "Stealing" digital media is not the same - and shouldn't be legislated under the same rules.
Regular CDs and DVDs have content that costs money to make, I realise that. But assuming that purchasers of CD-Rs are using them to pirate is dangerous, and pretty much tells us citizens that our government doesn't trust us. Furthermore, instead of using this money themselves, the government gives this money back to the companies. Why not start a government program to reduce piracy? Or fund an open research group to create a secure digital format? There are many other solutions other than automatically blaming the consumer.
Putting a tariff on media only legitimizes the claim that current media distribution methods are ineffective. It's a band-aid solution. It's a band-aid solution they'll have to own up to the next time a new format is released. It doesn't solve the problem at all.
You can blame the folks who pirate all you want, but people should remember that it was the RIAA and MPAA that make digital media available in this insecure form in the first place. I think it's ludicrous for them to think that governments will protect their interests in this way, and in that respect I'm ashamed that my Canadian government allowed it and that hardly anyone around Ottawa is making a stink about it.
Until the RIAA and MPAA makes a decent format, I don't see them "winning the battle against piracy". Any other band-aid solution is just more fodder for the masses to hate them with.
Slashdot Mirror
Besides, if a hop is aroung 100m, a packet travelling 100km would be a 1000 hops away!
This is assuming a Gnutella-like set-up. Most likely, the "stems of the lilly pads" would be connected by fibre optic to a common routing station with a big fat pipe to a service provider. A packet travelling 100km would be a half dozen hops away or less like it is now. You don't go hopping from Wi-Fi lillypad to lillypad to your destination.
Ryan
I'm an Emergency Medical Technician on a US Public Health Service Disaster Medical Assistance Team (DMAT). I am required to be accessable by pager or cell phone 24/7/365 ... Are you suggesting that ... I resign myself to never seeing another movie or play for the duration of my service?
Yes. Too bad, so sad. You love your job, but it comes with negatives. You probably have to make special arrangements when you go out of town as well, correct? Think of going to the theatre as a two hour road trip very far away from work. If you are really on call at every hour of every day I feel sorry for you. You'd have to vacation at home! Boring! ZZzzzzzz.....
Yeah, good idea, punish everybody, including those that didn't commit any crimes.
If the crime is being a social moron, some people have to be protected from themselves. People will take advantage of a situation if they can, no matter how rude the behaviour - they are either ignorant or plead ignorance. Completely blocking cell phones gives them no excuse.
If you have a job that requires you to be on call, you probably also can't travel more than an hour or so away from where you work. If you don't like the side effects of having a job like this, maybe you should choose a different job.
Instead of allowing cell phones, why not just effectively jam cell phone signals from coming in our out of the theatre? I live in a basement apartment in a crappy building and I have terrible cell phone reception. Surely the theatres can set up some sort of blackout zone (ie. using E-M interference).
And for those that argue that some people might need their cell phones for emergencies, I say this: what the eff did these people do 10 years ago when people didn't have cell phones? Surely they can last 2 hours without cell phone service. For most people, cell phones are a luxury and not a necessity. Then if you want cell phone service during a movie, go to a crappy theatre. I'll be going to the ones that jam cell service so I can get some peace and quiet.
NOOOOOOOoooooooo...
I'm Canadian!
Welcome to the fold, eh! Want some poutine, ya hoser?
I'm surprised no one has mentioned this yet, but if you are working with a group of people and you don't know their abilities, divide the project up. If they don't deliver properly by their deadline, cut their original task in half and assign the other half to someone else (probably yourself), leaving them with less to concentrate on. Then rinse and repeat as necessary.
Don't accept poorly written code just because "it works". If you do, you endanger the project and don't help the poor coders become better. The best way to become a better coder (IMO) is to bang away at one single problem and not worrying about doing "your share" and ending up spreading your effort too thin. When your teammates prove they can handle more coding, give it to them.
If you do it this way, you'll inspire confidence that your co-developer can do the job right. This confidence will, in the long term, be more benificial to the project and to the company you work for.
The thing is, though, that women tend to take nice guys who treat them with respect for granted.
I think we're clouding the issue. Women like nice guys. They also like guys who think for themselves, do what they want to and defend themselves. In the common lexicon, this is called "having balls". The difference is that the former are like little brothers and the latter are the (so-called-by-nice-guys) "assholes" they date.
The correlation between niceness and lack of balls has been well documented. It's very difficult to be nice and defend yourself and be confident, as one deviation from nice behaviour will exclude you from the "nice guy" collective.
Some people also confuse this with "playing the game". The game is bullshit. If you're being yourself and you're confident, you preclude yourself from having to play the complicated mind game that nice guys have to play. It's that easy.
You just have to throw that bologna out the window and do what you want. Be your own person. Don't be a pushover. Save nice for nuns, priests and girl guides. Women are smart social animals and can see right through the BS. They respect that more than a nice pushover guy. Which is why they acutally DATE the assholes - the assholes are just being themselves!
</tired-jumbled-rant>
Or does zdnet own the com.com domain?
Yes. I asked this question about six months ago, and a clever person pointed out that this would allow ZDNET to use a cookie with the com.com domain across its whole family of sites. Then they could track a person uniquely, customizing advertising, preferences or anything else. I don't know if they actually do this, but it would be a good way to do it.
rL
That, coupled with the fact that there is typically one lead on a project that needs to know what's going on from a Software Engineering perspective. If he has 6 programmers going nuts on his code, he'd like to know where they are making bad turns today instead of in 2 months during a code review.
In the article linked above, Martin Fowler says:
Clearly the emphasis is on training your programmers and then trusting them, instead of "police-ing" them by always looking at an up-to-date UML diagram. This I completely agree with. Not only are you encouraging consistency thoughout the team (also enabled by pair programming) but you are increasing the team's worth as well, reducing the all-the-eggs-in-one-basket effect.
I still think that having the large architecture view could help you educate your programmers and spot bad designs. Pairing them with more experienced developers could remedy this a bit, but it may not always be possible. Your junior programmers aren't going to start out knowing all of your wisdom. You have to be able to spot their poor design decisions early and tell them before they propogate more poor design thoughout the codebase, right?
We're kidding ourselves if we think that UML is automatically more intuitive for everyone. Or even for most people.
:)
Like everything, reading UML takes practise. UML diagrams can sometimes be very dense, and it takes experience to extract all of the information and process it. It isn't "automatically intuitive", but at least you get a very large chunk of architecture on one page where you can see it all at once.
Compare this job to scanning a few thousand lines of code and it will probably change the minds of people that don't think diagrams are helpful. Maybe their jobs don't require a big-picture view and they can live in their unit or subunit and not care - the architecture diagrams are mainly for the architect or project lead, to keep the project on track.
Also, the project leads need to sell the idea of seeing the forest through the trees to their developers. If the developers have an idea of the big picture, they can make more educated choices for the project without much intervention from the lead. If the lead is constantly jumping in and telling the developer he's going in the wrong direction, you can just imagine how the developer feels. On the other hand, if the lead explains his decisions and gives answers to "why" questions, the developer will stay on track (and the lead will spend less time correcting the developer). The lead having a firm grip on the architecture at any given time is important for this reason.
As for Martin Fowler's comments; for normal projects, I don't buy it and it's a moot point anyway. If someone wants to shun UML and spend time shifting through code to see the design, let them. They are just shooting themselves in the foot, time-wise. If the reason they are not using the UML is because it is outdated (which is likely) then that's a totally different reason - I don't like using outdated information either. If the code and the UML are sync'd, there's no difference except the amount of time it *might* take someone to find the design and digest it (not knowing it previously). UML was made to speed up this process. If there are two reliable sources of information, the person is free to make their own choice.
Fowler is also advocating not using UML for the sake of XP, which is valid. XP is a developer-centric methodology. A developer sees a bad part of code and goes in and corrects it. Unfortunately, the "design" changes so much it's hard to get a snapshot. That, coupled with the fact that there is typically one lead on a project that needs to know what's going on from a Software Engineering perspective. If he has 6 programmers going nuts on his code, he'd like to know where they are making bad turns today instead of in 2 months during a code review. I can buy not using UML during XP development, but that's only because (as I see it) refactoring focuses on such a small, managable area of the code that you don't need to look at a diagram to figure it out. However, even in XP an architecture view would be handy, if only for the lead.
Whew, a little off topic there. Thanks for bearing with me. Just wanted to start up more discussion, if you are game.
What is necessary is a method for changing design gracefully. "Refactoring" is the best source I've seen that addresses this. Basically, you change methodically, and you test.
.NET, but wouldn't it be nice if you could get up-to-date architecture diagram syncronization with code directly from a source versioning tool (ie. cvs, SourceSafe)?
I was talking about this with a friend the other day. Wouldn't it be nice if a senior software 'architect' could maintain a unit-level view AND current code at the same time? That way his busy programmers could refactor all they wanted, as long as they didn't overstep their unit bounds but at the same time improve the product. The architect could look at the project at different levels of abstraction (units, subunits) to make sure the programmers aren't getting off track.
Probably the hardest thing about using the iterative or refactoring methodology is knowing what your architecture looks like at any given time. You design a great, flexible architecture for the first iteration, but after several rewrites you may not know where you are in terms of the big picture. Surely a tool that spits out UML-like diagrams of the current code would be very useful to spot architecture flaws introduced during the refactoring process. Effective use of design patterns may also help. Is it impossible?
I've seen some work done by Rational in terms of code generation with
Everything MS says about Unix is at least 95% true. Just because its MS saying it doesn't make it untrue.
....
Fair enough, but since when did advertising turn into this? It used to be "Buy our project, it's great!" or "Buy our product X, it's better than Y!". Now it's "Product Y sucks and here is why. The logical conclusion is to buy our product X".
This kind of advertising leaves a bad taste in my mouth. The criticisms that MS makes may be valid, but their biased presentation of fact still doesn't tell me why I should buy product X. In fact, I question why I'd want to buy from a company that advertises this way. Probably because I have no other choice
Can I build it into a pringles can?
...
Which then naturally leads to
Imagine a wireless Beowulf cluster of pringles cans!!
Now where did I put my hot grits??
Maybe it's tired of Canada's 4 seasons: Almost Winter, Winter, Still Winter, and Highway Construction
;)
Ahhh city folk. We call Highway Construction (summer) Mosquito Season in the bush. After going through that, you can't wait for Almost Winter to start up again!
also, you can make a compass [thinkquest.org] using a bowl of still water, a blade of grass, and a small sliver of ferrous metal. (like the hand of a watch)
;)
Yes, but then it's decidedly less portable.
What attribute of code makes it "refactorable", other than the things that make it good? To me, these are exactly the same thing,...
... my explaination was pretty poor in that last one.
.... not 'good practise', but it's good for quick development of a usable product (ie. fulfilling test cases), which is an important aspect of XP.
:)
...
Heh
Ultimately, the properties of your code aren't really that important outside of readability and understandability. They are important characteristics, but are often overlooked when you know you are just going to go back later and replace that chunk of code you just wrote. Maybe you'll write a small note to explain how to extend it later
So really you just need to be able to see the big picture clearly by looking at the code. If you can do this, you can determine whether or not it is suitable to accept the new feature you are going to add or if the design needs to be rethinked (refactored) a bit. If you can spot the design from the code quickly, you can refactor efficiently. So all of the aspects that make code readable and understandable also make it easier to refactor or redesign.
The way I see XP is, you start out with a small managable design that you can get a basic product with. When you want to add features, you determine whether or not the part of the code you're working on can handle the feature and redesign it if it doesn't. To me, refactoring more applies to the design than to the code itself (ie. the forest and not the trees). It may seem weird to code this way, but the result is that you ALWAYS have a functional version of the product ready to test and use - albeit in the early stages a very limited piece of software.
But everyone probably has their own opinion of XP and refactoring. To explain refactoring outside of XP would probably take a lot more effort and experience than I have.
I'd even question its usefulness outside of XP for large projects - programs designed the old way tend to be a nice enough design for version 1.0, with feature after feature after bugfix slapped on top of each other. It would be a lot less efficient to refactor in this environment, you can imagine - a lot of hands have touched this code and made it a hard to understand mess. You don't want to break this fragile beast. But it still might be worth your while
I'm not quite sure what "refactorable" means, but I want my code to be like this:
* Good Cohesion
* Low Coupling
* No Duplication
Refactorable really means keeping your code in a state that allows it to be cheaply and quickly refactored. If you have to spend hours and hours to refactor you code, it's not worth it - it might be cheaper to rewrite it. If you consciously write your code so that it can be played with (ie. it's readable, consistent), you will have better luck.
Sounds like he could save quite a bit of time and maintanence nightmare if he just invested the effort to write it well the first time.
r k thinking. If you only need your function to do one thing right now, only implement the one thing right now. No use making the function more complicated - you'll only 1) take more time to implement it and 2) make it more complex which adds opportunity for bugs and increased testing cases to handle.
This is counter to the XP get-it-out-the-door-with-the-minimum-amount-of-wo
Having minimally implemented functions also lets you have an almost-always exectuable codebase, which is important to XP.
When you see that the functionality NEEDS to be extended, you extend it. Not before. You can still make the design before you write in that code for the other 4 features, but holding off from coding and then refactoring them in later incrementally will make your testing and maintaining life a lot easier. Just keep in mind you are going to refactor if you want to make it easier to incorporate them in.
No one uses the out-of-the-box version of Win95 anymore, do they?
Two things about Win95:
1. Microsoft no longer supports Windows 95.
2. USB is not natively supported in the early versions of Win95 (and later versions are spotty, they get it right by Win98).
So on that level, Joel's arguments are flawed. Less and less people will be testing on Win95 because MS doesn't support it any more. The WIN baseline now starts at Win98.
Another thing: if you DO use Win95, do you test the off-the-CD version or the highly patched (practically Windows 98) version? Grey grey grey area, Joel.
Having apparently never worked on a team in the Real World and had a piece of code delivered that was so hideous that the only thing you could really do with it is have it taken out and shot. XP Practices can help you avoid having such a hideous piece of code delivered in the first place, but you'll have a had time convincing small shops to do pair programming.
I agree that what he suggests is XP-like, but it doesn't require pair programming. You can't make a 3 story house of cards into a full-sized brick house, no matter how hard you try - design is paramount to refactoring.
I think people get confused when they read about XP and think design is ignored and everything is done "as you go". It's definitely not! You still have to keep in mind where you are going, even though you are only implementing for the present. Not only does that enable you to refactor, but also cuts down the refactoring time itself.
Joel's code is inherently refactorable because he's used to writing like that - and used to refactoring. What Joel hasn't said is that you have to purposely make your code easily refactorable from the outset, otherwise you'll spend your whole life refactoring from one feature to another.
So take your hideous house of cards into the middle of the street and shoot it if you have to. Refactoring may just be a waste of your time if the design is not easily refactorable.
Seriously, though, next time, take another route home. Zeppelin or something.
All kidding aside, Newfoundland is an ISLAND. There aren't too many ways off of it - and taking a ferry with your car takes a good chunk of time. That is, if the professor can even drive.
Driving from Newfoundland to Toronto would probably take 2 or 3 days, for someone that doesn't travel by car a lot. Heartier drivers might be able to do the whole thing in 24 hours.
Another unverified, just my personal experience, YMMV tip is only keeping static installs of programs on your C drive (partition) including the icons on your desktop.
:)
I change the MyDocuments, Internet browser cache and downloading directories (ie. for stuff like Kazaa) folders to another partition (I call mine SCRATCH) and keep all temporary stuff there. After I know I want to keep the data, I move it to yet another partition that stores 'permanent' data.
This technique minimizes fragmentation on your C drive (and on the 'data partition' to a lesser extent). Fragmentation slows loading times of software, because the OS can't load the program in large contiguous chunks if it is fragmented all over the place.
Short of reinstalling Windows every 12 months, this is what I do to keep my programs loading quickly in Windows. It would be nice if this was done automatically though.
Microsoft is not about to shoot itself in the foot so massively. Whatever this ends up being it's a good bet it will be fully backwards compatible.
... you can have a general file converter execute when a user opens an NTFS file in an OFS application.
:)
Out of all of the discussions here, this is what I don't understand the most. Why offer backwards compatibility over say, a conversion utility?
You have your old data on partition A with the NTFS, fine - keep it. Your new operating system runs on partition B with the new MSOFS (MS Object File System) and whatever data it produces it saves to the OFS partition.
Why can't these two file systems exist together? The only disadvantage is that the NTFS partitions will not support the OFS features. Big whup, you can still use those files
Maybe they'll even have a seperate file converter app so you can migrate files from your NT partitions to your OFS partitions and label them with metadata as you go, if that is what you need.
Considering built-in backwards compatibility for MSOFS just clouds the issue, it's not necessary for the success of MSOFS - they just need good conversion utilities so that people can reuse that legacy data.
Also, if they leave WIN32 and NTFS behind for one superior (though not in performance) FS, they are probably better off. They just need a way to get there.
... but that's just my opinion, I'm probably wrong.
It isn't possible to make a secure form of media distribution unless you control the playback devices as well.
.... well, except for those Metallica bitches.
;)
You have a good point. And we all know how well 'secured' playback devices that offer a pay-per-play model - DIVX - work: they don't. Techies blow the whistle on them, and they should.
Go back to a tip-based society, make money on live performances and tangible goods, or something.
I can't agree more. Tip-based solutions will allow people with a conscience to contribute. Radio stations will still make money from advertising even though they are playing 'free music'. The hard part will be financing videos and promos, but all of that crap is well, marketing crappola.
Letting musicians survive off of plain old word of mouth (which incidentally travels much faster these days) instead of mass marketing is very doable. Musicians could even market themselves - they don't need some monolithic middleman to tell them how to take care of their own business. Right now they are being forced into a system, and it's the system that's bitching and whining, not the musicians
And perhaps only people who care about music will become musicians!
And the music community will be all the better for it, IMO. Music celebrity won't be an excuse to get rich quick on a hot tune - a la Milli Vanilli. You'll actually have to have a large fan base if you want to get the larger t-shirt and concert revenues - and to get a large fan base you need to make GOOD MUSIC! What a novel idea.
Imagine a proposed law that said, since shoplifting is common and unstoppable, all customers at every store will be stopped, background-checked, and strip-searched.
Ah, but it is common for stores to have to raise prices for everyone to compensate for shoplifting losses, which IIRC are in the $billions per year.
The difference is that most things you can shoplift are tangible goods. Digital media can be made tangible, but the "manufacturer" cost of making a copy pales in comparison to the actual value of the "content". "Stealing" digital media is not the same - and shouldn't be legislated under the same rules.
Regular CDs and DVDs have content that costs money to make, I realise that. But assuming that purchasers of CD-Rs are using them to pirate is dangerous, and pretty much tells us citizens that our government doesn't trust us. Furthermore, instead of using this money themselves, the government gives this money back to the companies. Why not start a government program to reduce piracy? Or fund an open research group to create a secure digital format? There are many other solutions other than automatically blaming the consumer.
Putting a tariff on media only legitimizes the claim that current media distribution methods are ineffective. It's a band-aid solution. It's a band-aid solution they'll have to own up to the next time a new format is released. It doesn't solve the problem at all.
You can blame the folks who pirate all you want, but people should remember that it was the RIAA and MPAA that make digital media available in this insecure form in the first place. I think it's ludicrous for them to think that governments will protect their interests in this way, and in that respect I'm ashamed that my Canadian government allowed it and that hardly anyone around Ottawa is making a stink about it.
Until the RIAA and MPAA makes a decent format, I don't see them "winning the battle against piracy". Any other band-aid solution is just more fodder for the masses to hate them with.