Just install XP without any patches on them and hook them up to the internet without a firewall. I can assure you they will be fully utilized in short order.
Actually rather than waiting to decide whether I need to configure the database layer, or whether I need to use Rails' full support for transactions, or when to use finder_sql or find_by_sql, I prefer to go directly to http://www2.sqlonrails.org/ and just DO IT!
When I do my off the clock surfing, I see all sorts of women participating in the internet economy. In fact they tend to be the real stars of the sites I visit.
If a small tweak to the startup fee structure were made this could be quite lucrative for all us.
Right now there is a 25 euro signup fee that goes straight into the company coffers. That just doesn't make me feel motivated enough to go out and get the amount of new people to join the venture in order to make it succeed. Now with the following small tweak, we could reward people for signing up coworkers. We will start with a list of 7 unique people.
nightowl03d
nightowl
niteowl
notnightowl03d
not really nightowl03d
really not nightowl03d
nice nite owl who is not that mean old nightowl03d
Now suppose Dave Rhodes wishes to join our open source company. All he does is crosses off nightowl03d adds his name to the bottom, and sends in the 25 euros to the company.
nightowl, would be next in line. Nightowl03d gets 20 euros, and the company gets a 5 euro management fee, At the end of this iteration we would have the following list.
nightowl
niteowl
notnightowl03d
not really nightowl03d
really not nightowl03d
nice nite owl who is not that mean old nightowl03d
Dave Rhodes
So Dave would sign as many people up as he could, (possibly through bulletin boards), every person he signs up, gets to bump off nightowl, move dave up, and add their name to the bottom as follows...
niteowl
notnightowl03d
not really nightowl03d
really not nightowl03d
nice nite owl who is not nightowl03d
Dave Rhodes
Mark Garner
In no time at all Dave will be at the top of the list and making a good income. Hmm, this open source company thing could just work, just so long as people are honest and give proper credit to the people at the top of the list.
I have been working in the BPM field for about 10 years, and I think ProjectLink is very nice.
The workflow engine in particular really rocks. Full Petri Net expression capabilities, robots, inline Java code to fine tune activities and provides automatic rollup of dependant activities. Workflows can even be created from an MS project file, or their native UI.
In my experience, people don't know what they want until they see that you have isn't it.
You don't say what your target market is, so what I am going to reply here has a relatively small probability of applying to your situation. But this is slashdot so I don't have to worry about a silly think like relevance, so here we go....
If you had this experience, chances are the person who fell down on the job is not the user, the PM, or the developers, but the software architect for not identifying a fluxional feature. In fact the sole justification for the Agile methodologies is these fluxional features. Many, (but not all), "Agile" projects I have been called in to clean up have made this mistake. In most of these cases, the principal performing the architect role was a true technology wizard, but who would filter everything the business people said to conform to the principal's pre-conceived notions or more subtly falling into the "one true answer" trap.
When a contentious topic comes up in analysis meeting, a technology focused architect often seeks to resolve it and record the resolution, and hard-wire that behavior into the requirements. This is death. As this type of error multiplies, the seeds have been sown for disaster. What should have happened, was a contentious point should be used as an indicator of a volatile feature that should be designed with ease of customization in mind.
Volatile requirements are the norm and the identification of fluxional features is the key to knowing when to address them.
In my market these areas often require extreme flexibility.
1. Screen details, and screen workflow on the UI side. Keep the UI shell stupid using an MVC/MVP paradigm. (.Net 2.0 does a fairly good job with this if you use their binding framework judiciously,.Net 3.0 does a better job, JSP sucked donkey balls in this area, JFC and JSF are better, ROR is pretty good for simpler web sites). Oddly enough navigation is usually pretty stable once the stakeholder meetings have been conducted. Be ready for this.
2. New commands will be added. (Commands in this sense are persistence operations or new features). Work out early how all of those contentious points that came up in your continuous interviews with your stakeholders can be resolved with an appropriate plug in approach. What meta data will be needed for future commands? Be ready for this.
3. Your input formats and medium will change. Be ready for this.
4. Business rules will always change, never allow anything structural in your system be governed by any business rule stated in a stakeholder meeting. Keep them behavioral. Construct/purchase an appropriate rules engine who only knows about business rules. Be ready for this.
5. New persistence mechanisms will be desired. Be ready for this.
Sounds a lot like Agile doesn't it? The only difference is that be ready for this changes to react to this. Putting the effort in it to think about these and other volatile issues up front finds the trolls sooner, which enables refactoring efforts to be more local than they would have been otherwise. This list isn't comprehensive, so remember that outside of mathematics, and mathematical physics, there is almost never a one "One True Answer". My personal rule of thumb if that an issue can't be resolved via a thought experiment it should be made a fluxional point.
Very few people have the intelligence and foresight to extrapolate what a screenshot will mean to them, in the real world.
If you are using screen shots to walk through your scenarios, it is no surprise to me that you have gotten bad results. Paper prototypes will let the stakeholder see the consequences of their actions much easier. But that isn't enough either. You should also make efforts to communicate the state of the system and processes at each point in the screen shot. Designing a good walk through is more of an exercise in psychology than a technical exercise . Wal
If you are early in your career, (less than 5 years out of your last degree), now is the perfect time to find out if you chose your spouse wisely.
Take the job, and do the commute. If your wife can't handle it, this is the time to find out while the alimony payments are still relatively low. Once you get 6+ years of experience, on the road consulting is where the money is, so you don't want a spouse who would be a detriment to that life style.
If she can handle a year or two of that schedule, you got yourself a keeper. THEN consider moving closer to the primary site if that is what you want to do.
Yes, the grandparent has committed the cardinal sin of posting to Slashdot WITHOUT reading all the potentially related Slashdot articles for the previous 6 weeks. I would think they would have fixed slash code to prevent that by now.
It is pricks like these that caused me to switch from Linux to BSD years ago, and to use libraries with the MIT/BSD/Boost style licenses instead of anything under GPL/LGPL.
Please mod parent up!
Slashdot Mirror
Just install XP without any patches on them and hook them up to the internet without a firewall. I can assure you they will be fully utilized in short order.
Just keep in mind the following rule of the corporate world... Credit goes up, blame goes down
Actually rather than waiting to decide whether I need to configure the database layer, or whether I need to use Rails' full support for transactions, or when to use finder_sql or find_by_sql, I prefer to go directly to http://www2.sqlonrails.org/ and just DO IT!
Actually Gimp wouldn't be so bad if they would drop the GTK and use a better UI framework such as Qt.
1. Fragmentation 2. Fragmentation 3. Fragmentation 4. Fragmentation 5. Fragmentation 6. Fragmentation 7. Fragmentation
Some things I learned include...
1. The only job a real programmer will take must involve Ruby on Rails
2. Never buy a MS product
3. Filesharing music is "fair use"
4. Programmers should not create closed source programs EVER.
5. Linux sucks, BSD sucks, MacOS sucks, and Windows sucks. (I am posting from an IBM/360)
6. The only safe browser is Lynx
When I do my off the clock surfing, I see all sorts of women participating in the internet economy. In fact they tend to be the real stars of the sites I visit.
I am surprised no one has pointed you to this site for some good examples of how to use your information.
If a small tweak to the startup fee structure were made this could be quite lucrative for all us.
Right now there is a 25 euro signup fee that goes straight into the company coffers. That just doesn't make me feel motivated enough to go out and get the amount of new people to join the venture in order to make it succeed. Now with the following small tweak, we could reward people for signing up coworkers. We will start with a list of 7 unique people.
nightowl03d
nightowl
niteowl
notnightowl03d
not really nightowl03d
really not nightowl03d
nice nite owl who is not that mean old nightowl03d
Now suppose Dave Rhodes wishes to join our open source company. All he does is crosses off nightowl03d adds his name to the bottom, and sends in the 25 euros to the company.
nightowl, would be next in line. Nightowl03d gets 20 euros, and the company gets a 5 euro management fee, At the end of this iteration we would have the following list.
nightowl
niteowl
notnightowl03d
not really nightowl03d
really not nightowl03d
nice nite owl who is not that mean old nightowl03d
Dave Rhodes
So Dave would sign as many people up as he could, (possibly through bulletin boards), every person he signs up, gets to bump off nightowl, move dave up, and add their name to the bottom as follows...
niteowl
notnightowl03d
not really nightowl03d
really not nightowl03d
nice nite owl who is not nightowl03d
Dave Rhodes
Mark Garner
In no time at all Dave will be at the top of the list and making a good income. Hmm, this open source company thing could just work, just so long as people are honest and give proper credit to the people at the top of the list.
I have been working in the BPM field for about 10 years, and I think ProjectLink is very nice.
The workflow engine in particular really rocks. Full Petri Net expression capabilities, robots, inline Java code to fine tune activities and provides automatic rollup of dependant activities. Workflows can even be created from an MS project file, or their native UI.
ProjectLink is NOT freeware.
In my experience, people don't know what they want until they see that you have isn't it.
You don't say what your target market is, so what I am going to reply here has a relatively small probability of applying to your situation. But this is slashdot so I don't have to worry about a silly think like relevance, so here we go....
If you had this experience, chances are the person who fell down on the job is not the user, the PM, or the developers, but the software architect for not identifying a fluxional feature. In fact the sole justification for the Agile methodologies is these fluxional features. Many, (but not all), "Agile" projects I have been called in to clean up have made this mistake. In most of these cases, the principal performing the architect role was a true technology wizard, but who would filter everything the business people said to conform to the principal's pre-conceived notions or more subtly falling into the "one true answer" trap.
When a contentious topic comes up in analysis meeting, a technology focused architect often seeks to resolve it and record the resolution, and hard-wire that behavior into the requirements. This is death. As this type of error multiplies, the seeds have been sown for disaster. What should have happened, was a contentious point should be used as an indicator of a volatile feature that should be designed with ease of customization in mind.
Volatile requirements are the norm and the identification of fluxional features is the key to knowing when to address them.
In my market these areas often require extreme flexibility.
1. Screen details, and screen workflow on the UI side. Keep the UI shell stupid using an MVC/MVP paradigm. (.Net 2.0 does a fairly good job with this if you use their binding framework judiciously, .Net 3.0 does a better job, JSP sucked donkey balls in this area, JFC and JSF are better, ROR is pretty good for simpler web sites). Oddly enough navigation is usually pretty stable once the stakeholder meetings have been conducted. Be ready for this.
2. New commands will be added. (Commands in this sense are persistence operations or new features). Work out early how all of those contentious points that came up in your continuous interviews with your stakeholders can be resolved with an appropriate plug in approach. What meta data will be needed for future commands? Be ready for this.
3. Your input formats and medium will change. Be ready for this.
4. Business rules will always change, never allow anything structural in your system be governed by any business rule stated in a stakeholder meeting. Keep them behavioral. Construct/purchase an appropriate rules engine who only knows about business rules. Be ready for this.
5. New persistence mechanisms will be desired. Be ready for this.
Sounds a lot like Agile doesn't it? The only difference is that be ready for this changes to react to this. Putting the effort in it to think about these and other volatile issues up front finds the trolls sooner, which enables refactoring efforts to be more local than they would have been otherwise. This list isn't comprehensive, so remember that outside of mathematics, and mathematical physics, there is almost never a one "One True Answer". My personal rule of thumb if that an issue can't be resolved via a thought experiment it should be made a fluxional point.
Very few people have the intelligence and foresight to extrapolate what a screenshot will mean to them, in the real world.
If you are using screen shots to walk through your scenarios, it is no surprise to me that you have gotten bad results. Paper prototypes will let the stakeholder see the consequences of their actions much easier. But that isn't enough either. You should also make efforts to communicate the state of the system and processes at each point in the screen shot. Designing a good walk through is more of an exercise in psychology than a technical exercise . Wal
If you are early in your career, (less than 5 years out of your last degree), now is the perfect time to find out if you chose your spouse wisely. Take the job, and do the commute. If your wife can't handle it, this is the time to find out while the alimony payments are still relatively low. Once you get 6+ years of experience, on the road consulting is where the money is, so you don't want a spouse who would be a detriment to that life style. If she can handle a year or two of that schedule, you got yourself a keeper. THEN consider moving closer to the primary site if that is what you want to do.
Volumes 1-3 of The Art of Computer Programming by Knuth. Be sure to do all the problems .
Yes, the grandparent has committed the cardinal sin of posting to Slashdot WITHOUT reading all the potentially related Slashdot articles for the previous 6 weeks. I would think they would have fixed slash code to prevent that by now.
It is pricks like these that caused me to switch from Linux to BSD years ago, and to use libraries with the MIT/BSD/Boost style licenses instead of anything under GPL/LGPL. Please mod parent up!