Put a pound or two of Lego shaped candy on each table. They are a good, playful, conversation starter and double as a snack.
At a New Years party, I brought a bowl and they were a hit. The candy stacks like regular Legos, comes in the basic block sizes (2, 4, and 8), and taste like smarties. Sugar...gooood!
Note: If your guests start to get naked, it's not my fault. Blaim the boose.
If any propriatary software company does this, they risk reimportation back into a more 'expensive' country.
I've seen this already in small mom & pop computer stores in the US that sell UK versions of titles in DVD cases for a little less than the US boxed version. No MS titles, though other popular games have shown up.
"The reason we can't resolve 99.992% of help desk calls in 60 min is that we don't have the parts we are supposed to have." or whatever.
I've used the same tactic...it's effective to a point. The worse the manager, the more likely they will foot drag on these types of requests or lead you into 1000 what-if type questions that lead nowhere.
The better the manager the less likely it's necessary to do this because they already know. If they can't do it (budget), they'll say so but only after they have gone on a money hunt.
PS: Feel free to show this to your boss. Make sure he knows my email address is peter at fpcc net;-) I'm available for consulting, or save a bundle and hire me outright!
Same here...Washington DC area (local), national, or international; active.consulting at metamark com .
I think that six sigma is overkill for just about every software project. That said, most managers I've delt with start out to document and codify the current way things are being done and make minor corrections. The idea is that the way things are being done is good, and that it should now be consistant. By introducing consistancy, you can ballence resouces and not rely on any one person since things are now documented and can be repeated.
This usually fails for existing projects since it's difficult to engineer something that has grown up organically.
The sucessful managers don't waste time on these existing, organic, projects. Instead, they start with a new project and allow for change. They drag in the users of the systems first and learn what they do. They document failures of the deployed system. They try and make using it more natural so that the delivered system matches the process and silently enforces consistancy.
Unfortunately, six sigma or CMM are check boxes for many managers since they are told by thier bosses to get it. Real improvements are usualy secondary. I try and drag along useful processes under the guise that if we don't do them, we aren't going to get that check box. To me, that can make quite a bit of difference. Manage your managers.
I've alway been of the opinion project and processes methodologies are the last resort worthless middle management use to justify their existence. Leadership, aptitude and competence being fearsome skills they prefer to outsource.
People before process, yes. It doesn't matter what is in some document if the people aren't any good -- or are flat out dishonest.
That applies to any sized project, and the smaller the project the more people matter and the less process does.
I worked on one project where nobody on the customer's side would talk to me for 2 weeks strictly because of office politics and a manager that felt threatened by the contracting company I worked for. We had a great process...and it was entirely ineffective for months at a time.
That said, programmers and tech-only specialists don't make large projects work. Good managers do. Think about it: ineffective management will kill any work that good programmers could do. Worse yet, bad management tends to bring in bad workers. Good managers will get rid of bad workers and bring in good ones...improving sucess.
For large projects, process methodologies are just as critical as the people since management has to be able to say "we will do this". No specs, no design documents, nobody to check the code,...
Process doesn't gaurantee a thing. Without standards and paper work, how do you know that you've done anything? How do you know the difference between an unreasonable user and one that has a real legitimate gripe?
Document the hell out of everything? YES! Don't allow any flexibility? NO! Just make it obvious what is being done and what is expected. If you deal with reasonable people, it'll work out. Work with bad people (managers or not) and it'll be a struggle. If you don't document anything, you have completed nothing.
Yes, it should be, because QA -- better VV verification, validation and test -- starts before coding.
Test/QA/VV&T starts in the general documents needed during sales -- "this system will do these major tasks" -- and is followed by the initial rough specifications. Specifications -- even poor ones -- do come first, right?
Design (how the specs will be implemented) and coding (the implementation) come after QA/VV&T have been working on the project and have written up initial, if sketchy, test plans.
By the time that coding starts, serious scaling issues should already be addressed. QA/VV&T/Test are there to make sure that things work as specified. If the ability to smootly scale up a project wasn't included in the specs or design documents, it's unlikely to end up in the implementation.
That simply isn't true. Example: if I want to pipe the output of lynx to a file, I need to use -source on the command line. If I want to do the exact same thing in wget, it's -o. In netcat, I can just use the redirection of the shell. Open Source programmers are notorious for doing their own thing (and why shouldn't they, not as if it will hurt their revenue stream). In the commercial world, on NT or Unix, playing well with others is much more important.
Bad habits are management's fault -- even if a project lead on an open source project. Being a Windows or X program matters not one bit, though the libraries in Windows do help. Nothing is preventing these features from being added to any of the libraries under the different flavors of *nix -- except for virus worries, maybe, and general apathy since the shells available work damn well for most tasks.
I've worked on plenty of commercial projects (COTS and custom) where one or two folks in development decided that their way of doing something was better. I'm talking button placement, dialog modality, error boxes, and basic menus not one-use algorithms. None of these changes were impovements over what is normally expected or the project's existing style. Pure lazyness.
The AIX credit card server here probably has boat loads of information. I haven't gotten around to formatting it, though it does boot to a login prompt. It was for Homeruns, a failed grocery delivery service.
WTF indeed. If you read my comment, you'd know why I wouldn't read the article.
I am amused though. Someone rated my original comment as a "Troll". (?!?!?!) Still, one bad rating out of hundreads of other comments on/. is a good record.
Regaurdless of the personal feelings of Mozilla developers, ZD is known for this kind of sensationalistic and emotion-charged reporting.
Ziff Davis wants you to jump on this -- and visit thier site. DON'T DO IT!
That said, Apple and Apple's staff can choose what they wish or what fits the task. If they decide later to use Gecko for something else, ZD will no doubt run a "Apple uses Mozilla -- KDE developers miffed!" or some such garbage.
The important thing is that open source is becoming more and more important on the user end -- not just on the server side.
Under Steve Case, AOL was a company that took advantage of its customer's ignorance. Under Steve Case, pushed its customers in every way possible to get money from them.
AOL, before it supported the Internet, used to bill some of it's customers $1-2,000 a month for accessing it's chat service. You were charged per-hour, not pre month. Most active topic: Sex. (Gee, couldn't guess that one, eh?)
Someone said, "AOL was founded on the idea that users of the Internet need training wheels to get started." Using AOL says, "I don't have any friends who understand computers." As users get smarter, they realize they don't need AOL.
And that someone would be wrong. AOL started out as Quantum -- a small competitor to Compuserve that had a graphical interface as opposed to Compuserve's original text-based one. Over time, they grew, found a pre-Internet nitch, fought migration to the Internet, and finally caved in and joined. That's why AOL isn't like most Internet services -- since it isn't an ISP. AOL is a propriatory service with Internet support.
I half-heartedly recommend AOL for new or computer phobic people for the simple fact that they would have probably chosen AOL anyway -- and I know that AOL has nation wide dialup support. I save my strong recommendations for things that they might actually listen to and that matter more.
AOL is popular, they see it, and automatically suspect that if something is not advertised, it's not worth money. People hate to change, so moving from AOL is not common in my experience.
I very much would like to see AOL support x86 Linux.
PHB: You write, what, 30 maybe 80 "eL Oh Cee" a day? Right?
Jim: Well, the TPS and project plans take --
PHB: Says here, that this 16 year old kid can write 1500 "eL Oh Cee" a day. What do you think about that?
PHB: Don't laugh...this is serious.
Jim: Sorry. I ment --
PHB: Jim, maybe you need to put in more hours. Reconsider your work habbits.
Jim: I work till 10 most nights...
PHB: Jim, it's not the hours it's how efficiently you handle them. I expect todays TPS on my desk by noon, along with a status report on each programming task you've done today.
Jim: It's 11 --
PHB: That's it Jim! Keep up the good work. In the meantime, see if you can increase that "eL Oh Cee" to, say, about a hundread. It's good to make a good impression. Fine. Excellent. I knew I could count on you. I'll see you then!... Brian...did you fill out that TPS report...
What did you really expect from a.0 release? 9.1 probably won't be perfect either. I imagine they'll stop at 9.2 until 10.0. It's the same with Redhat.. 7.0 (buggiest), 7.1(less buggy),7.2 (less buggy then the last),7.3 (not too buggy).. and now 8.0 (back to buggiest). Consider it a stable beta.
While I agree that.0 releases of Red Hat are traditionally unstable, Red Hat 8.0 broke that mold. I've had no problems with it on multiple, different, machines. It feels like a.2 release.
"Foreword by CEO Ken Lay Sections include: Principles of Human Rights; Securities Trades by Company Personnel; Business Ethics; Confidential Information and Trade Secrets; Governmental Affairs and Political Contributions; Consulting Fees, Commissions and Other Payments; Conflicts of Interest, Investments and Outside Business Interests of Officers and Employees, Responsibility for Reporting, Compliance; Administration"
People and management matter well beyond a code of ethics.
As any experienced contractor knows, the contract is important but means nothing if there aren't good and properly motivated people -- contractor and client -- on both sides willing to fight to live up to the spirit of the thing.
That said, the code of ethics you are being asked to sign is a CYA for upper management. They want to point a finger at someone if something goes wrong.
If you do sign it, keep a paper trail of your activities. These kind of things also can be used in office politics by those who will blissfully ignore the whole concept of ethics.
I'd avoid signing anything unless the alternative is job loss.
I read through their strategy and I couldn't find any hint of why people should actually use OS/2 over any other solutions. Java, XML and the internet protocols are very well supported in Linux and *BSD, so why would anyone switch to OS/2 rather than one of those systems, if they decide to switch to something, or why would they choose OS/2 rather than something else if they're starting a new project?
This announcement isn't for future OS/2 customers -- it's for current OS/2 customers. The idea is that this group should use generic interfaces so that they can transition off of OS/2 when IBM finally cuts the cord.
It also shows that IBM as a company is trustworty in the most normal of senses -- even if you never liked or even knew about OS/2.
Maintenance mode on most projects is usually 80-95% of the project's lifetime, and IBM will cover everything if you want them too from start to finish.
This is one thing about IBM that I love -- they don't stop support after a couple years. The fees they charge pay for this kind of long-range planning so they are worth it if you need this kind of stability and assurance.
To bring this back to an Unix/Linux focus...If anyone doubts Linux's future or top-notch support -- say, they have been in a cave for the last 10 years -- point to this type of dedication from IBM and that IBM not only supports Linux but has invested heavily in it.
The case I'm using is unbranded with USB 1, 2, and 1394/firewire support. I've tested it under Linux (firewire & USB 1) and Windows (USB 1). Testing under Linux shows that the firewire connection allows for speeds similar to internal IDE drives. USB 1 support is as expected -- slow for both Linux and Windows. USB 2 support was not tested (no USB 2 host).
So far, my biggest complaint is that the 25mm fan (20mm blade) -- ARX CeraDyna FD0525 - A 1042A (DC 5v, 0.19A) -- is noisy and rattles. If anyone knows of a replacement or how to quiet it, let me know.
Stress testing for about a day shows that the drive remains cool, so the fan does it's job -- if not quietly.
My domain has recieved fresh spam from them on a regular basis. Givning Staples the benifit of the doubt -- the accounts spammed are test accounts -- I've contacted them a couple different ways telling them to stop. Unfortunately, I've contacted them about once a month for the last 6 months, each time they apoligize and each time they say that my domain won't recieve any more solicitiations...only that it may take 4-6 weeks for the request to process.
No more. If I recieve a single spam from them in 2003, they will be reported to all the anti-spam services I already use. F-em!
Slashdot Mirror
Pah! Everything effects Windows .
Candy Blox multi-pack box
Same, different store
Concord also makes Bubble Blox, though I don't know if these are Lego shaped or not.
Trivia: Concord also makes Doubble Bubble.
At a New Years party, I brought a bowl and they were a hit. The candy stacks like regular Legos, comes in the basic block sizes (2, 4, and 8), and taste like smarties. Sugar...gooood!
Note: If your guests start to get naked, it's not my fault. Blaim the boose.
I've seen this already in small mom & pop computer stores in the US that sell UK versions of titles in DVD cases for a little less than the US boxed version. No MS titles, though other popular games have shown up.
I'd like to see it. There are few effective lawsuits against these scumbags.
I've used the same tactic...it's effective to a point. The worse the manager, the more likely they will foot drag on these types of requests or lead you into 1000 what-if type questions that lead nowhere.
The better the manager the less likely it's necessary to do this because they already know. If they can't do it (budget), they'll say so but only after they have gone on a money hunt.
PS: Feel free to show this to your boss. Make sure he knows my email address is peter at fpcc net ;-) I'm available for consulting, or save a bundle and hire me outright!
Same here...Washington DC area (local), national, or international; active.consulting at metamark com .
This usually fails for existing projects since it's difficult to engineer something that has grown up organically.
The sucessful managers don't waste time on these existing, organic, projects. Instead, they start with a new project and allow for change. They drag in the users of the systems first and learn what they do. They document failures of the deployed system. They try and make using it more natural so that the delivered system matches the process and silently enforces consistancy.
Unfortunately, six sigma or CMM are check boxes for many managers since they are told by thier bosses to get it. Real improvements are usualy secondary. I try and drag along useful processes under the guise that if we don't do them, we aren't going to get that check box. To me, that can make quite a bit of difference. Manage your managers.
People before process, yes. It doesn't matter what is in some document if the people aren't any good -- or are flat out dishonest.
That applies to any sized project, and the smaller the project the more people matter and the less process does.
I worked on one project where nobody on the customer's side would talk to me for 2 weeks strictly because of office politics and a manager that felt threatened by the contracting company I worked for. We had a great process...and it was entirely ineffective for months at a time.
That said, programmers and tech-only specialists don't make large projects work. Good managers do. Think about it: ineffective management will kill any work that good programmers could do. Worse yet, bad management tends to bring in bad workers. Good managers will get rid of bad workers and bring in good ones...improving sucess.
For large projects, process methodologies are just as critical as the people since management has to be able to say "we will do this". No specs, no design documents, nobody to check the code, ...
Process doesn't gaurantee a thing. Without standards and paper work, how do you know that you've done anything? How do you know the difference between an unreasonable user and one that has a real legitimate gripe?
Document the hell out of everything? YES! Don't allow any flexibility? NO! Just make it obvious what is being done and what is expected. If you deal with reasonable people, it'll work out. Work with bad people (managers or not) and it'll be a struggle. If you don't document anything, you have completed nothing.
...slash took out my first ampersand and T! Should have previewed...
Test/QA/VV&T starts in the general documents needed during sales -- "this system will do these major tasks" -- and is followed by the initial rough specifications. Specifications -- even poor ones -- do come first, right?
Design (how the specs will be implemented) and coding (the implementation) come after QA/VV&T have been working on the project and have written up initial, if sketchy, test plans.
By the time that coding starts, serious scaling issues should already be addressed. QA/VV&T/Test are there to make sure that things work as specified. If the ability to smootly scale up a project wasn't included in the specs or design documents, it's unlikely to end up in the implementation.
It's a good thing that spammers are ethical!
Bad habits are management's fault -- even if a project lead on an open source project. Being a Windows or X program matters not one bit, though the libraries in Windows do help. Nothing is preventing these features from being added to any of the libraries under the different flavors of *nix -- except for virus worries, maybe, and general apathy since the shells available work damn well for most tasks.
I've worked on plenty of commercial projects (COTS and custom) where one or two folks in development decided that their way of doing something was better. I'm talking button placement, dialog modality, error boxes, and basic menus not one-use algorithms. None of these changes were impovements over what is normally expected or the project's existing style. Pure lazyness.
Read the site. Movix is cool, though I don't know if it's a complete answer to the original question.
The AIX credit card server here probably has boat loads of information. I haven't gotten around to formatting it, though it does boot to a login prompt. It was for Homeruns, a failed grocery delivery service.
I am amused though. Someone rated my original comment as a "Troll". (?!?!?!) Still, one bad rating out of hundreads of other comments on /. is a good record.
Ziff Davis wants you to jump on this -- and visit thier site. DON'T DO IT!
That said, Apple and Apple's staff can choose what they wish or what fits the task. If they decide later to use Gecko for something else, ZD will no doubt run a "Apple uses Mozilla -- KDE developers miffed!" or some such garbage.
The important thing is that open source is becoming more and more important on the user end -- not just on the server side.
Someone gets it...posts as an AC...and they get modded -1!
AOL, before it supported the Internet, used to bill some of it's customers $1-2,000 a month for accessing it's chat service. You were charged per-hour, not pre month. Most active topic: Sex. (Gee, couldn't guess that one, eh?)
Someone said, "AOL was founded on the idea that users of the Internet need training wheels to get started." Using AOL says, "I don't have any friends who understand computers." As users get smarter, they realize they don't need AOL.
And that someone would be wrong. AOL started out as Quantum -- a small competitor to Compuserve that had a graphical interface as opposed to Compuserve's original text-based one. Over time, they grew, found a pre-Internet nitch, fought migration to the Internet, and finally caved in and joined. That's why AOL isn't like most Internet services -- since it isn't an ISP. AOL is a propriatory service with Internet support.
I half-heartedly recommend AOL for new or computer phobic people for the simple fact that they would have probably chosen AOL anyway -- and I know that AOL has nation wide dialup support. I save my strong recommendations for things that they might actually listen to and that matter more.
AOL is popular, they see it, and automatically suspect that if something is not advertised, it's not worth money. People hate to change, so moving from AOL is not common in my experience.
I very much would like to see AOL support x86 Linux.
Jim: Yes, I --
PHB: Jim...I'm concerned about your performance.
Jim: Er, wha--
PHB: You write, what, 30 maybe 80 "eL Oh Cee" a day? Right?
Jim: Well, the TPS and project plans take --
PHB: Says here, that this 16 year old kid can write 1500 "eL Oh Cee" a day. What do you think about that?
PHB: Don't laugh...this is serious.
Jim: Sorry. I ment --
PHB: Jim, maybe you need to put in more hours. Reconsider your work habbits.
Jim: I work till 10 most nights...
PHB: Jim, it's not the hours it's how efficiently you handle them. I expect todays TPS on my desk by noon, along with a status report on each programming task you've done today.
Jim: It's 11 --
PHB: That's it Jim! Keep up the good work. In the meantime, see if you can increase that "eL Oh Cee" to, say, about a hundread. It's good to make a good impression. Fine. Excellent. I knew I could count on you. I'll see you then! ... Brian...did you fill out that TPS report...
While I agree that .0 releases of Red Hat are traditionally unstable, Red Hat 8.0 broke that mold. I've had no problems with it on multiple, different, machines. It feels like a .2 release.
People and management matter well beyond a code of ethics.
As any experienced contractor knows, the contract is important but means nothing if there aren't good and properly motivated people -- contractor and client -- on both sides willing to fight to live up to the spirit of the thing.
That said, the code of ethics you are being asked to sign is a CYA for upper management. They want to point a finger at someone if something goes wrong.
If you do sign it, keep a paper trail of your activities. These kind of things also can be used in office politics by those who will blissfully ignore the whole concept of ethics.
I'd avoid signing anything unless the alternative is job loss.
This announcement isn't for future OS/2 customers -- it's for current OS/2 customers. The idea is that this group should use generic interfaces so that they can transition off of OS/2 when IBM finally cuts the cord.
It also shows that IBM as a company is trustworty in the most normal of senses -- even if you never liked or even knew about OS/2.
Maintenance mode on most projects is usually 80-95% of the project's lifetime, and IBM will cover everything if you want them too from start to finish.
This is one thing about IBM that I love -- they don't stop support after a couple years. The fees they charge pay for this kind of long-range planning so they are worth it if you need this kind of stability and assurance.
To bring this back to an Unix/Linux focus...If anyone doubts Linux's future or top-notch support -- say, they have been in a cave for the last 10 years -- point to this type of dedication from IBM and that IBM not only supports Linux but has invested heavily in it.
Afterall, were talking about Network Ass...nevermind.
So far, my biggest complaint is that the 25mm fan (20mm blade) -- ARX CeraDyna FD0525 - A 1042A (DC 5v, 0.19A) -- is noisy and rattles. If anyone knows of a replacement or how to quiet it, let me know.
Stress testing for about a day shows that the drive remains cool, so the fan does it's job -- if not quietly.
Drive: Maxtor 120GB, 7200 RPM
Enclosure: no shock mounts for the drive
Connectors: 1 USB square B, 2 Firewire.
Two main chips with these markings;
ALI
M5621 A1
0210 TH05
XHC79900000D
(crab logo)
22017S1
212J TAIWAN
No more. If I recieve a single spam from them in 2003, they will be reported to all the anti-spam services I already use. F-em!