My recommendations: make sure that the syllabus and course work are comparable to the traditional institutions, and make sure that you have a solid resume (experiences and clear demonstrations of skill). Make sure you are working on real projects in relevant technologies (even part time) so that you can put the magic "5/7 years experience in x" on your resume.
Unfortunate realities: The degree matters. The school matters. The subject matters. The technology platform matters.
I've had the opportunity to do quite a bit of hiring and interviewing over the last few years. My team keeps earning money, and we grow. Other managers tend to invite me to interviews with technical candidates, because I can sort the chaff from the wheat.
I tend towards flexibility in looking at candidates. If I don't know the school, I look at the syllabus. Hint: A master's from City U (I'm talkning about the for-profit degree factory, not CUNY) is approximately equivalent to the first two years of CS in most real universities. I look at the candidate's projects and work. In interviews, I take as much time as I can to ask hard technical questions to verify that they know the subject matter and can think on their feet.
Unfortunately, I'm the exception that proves the rule. Your degree and where you got it are critical to getting into interviews. Most HR departments have a list of 10 criteria and 1000 resumes to screen. Degree + experience are cheap to evaluate. I've pulled resumes out of my HR's wastebin that HR scored low because the candidate was a year or a degree short, but a quick dig into the resume and work showed that they knew their stuff. I've also wasted a lot of time in interviews with people who didn't have a clue, but scored well.
Basically, a degree and work experience will get into interviews. Even if you don't know anything, you can always get contract work through [insert contract-o-matic agency here] if you have a degree. There's always someone who needs a programmer ASAP, and a recruiting agency willing to provide them one without much screening.
Finally, if your skills are there but your resume is imperfect, don't underestimate what recruiting agencies can do for you. Most are really lousy (Volt, etc.) -- I've had agencies offer me contract jobs 1000 miles away when my resume has "will not relocate" and "permenant work only" in bold. A few rare companies take the time to understand a persons skills, and communicate them to employers. Find those companies and work with them.
I wonder if I could supplement a summer solar system, with a winter rain powered mini-hydroelectric system. Any nerds care to calculate how much wattage could be generated by Seattles rainfall on a 1000 sq ft area, assuming I can drop it 20' from roof to sewer? Could I run my coffee pot (assume 1-2 amps at 120v for 5 minutes) once a day?
My apologies, it looks like I didn't read far enough up the thread to understand the context properly.
I very much agree that shunting off user requirements can be costly. It might make initial project development cheaper, but it makes the product worth less. One of the things I like about iterative development, is that it provides a clear approach to handling late breaking user requirements. One of the things that I like about good old waterfall, is that you invest enough time in planning to be able to create a design that is robust enough to flex to meet new requirements.
My major software project management problem is getting developers to read and respect specs. While the classic pieces of the puzzle (management, process, docs) are in place, I've couple bright, creative developers, who tend to code to their own drummer. This works fine on small projects with just one dev, but on the larger projects, we end up rewriting a lot of great code that doesn't follow the design and spec. Agile, lean, waterfall and all other methodologies all start with the flimsy assumption that devs will want to read the documents produced and generally follow direction. Do you know any methods for herding cats?
The arguments that you make against agile software development are actually dealt with in a quick "myths about agile software development" in the start of this book. This argument, and many other made against agile, are classic straw men -- you are attacking a weaker argument, never made by proponents of lean or agile software development.
The example you give is a POORLY managed project, and would have failed no matter what methodology was used. Someone might have been using "agile" or "lean" as an excuse to be lazy.
The key points made by the Poppendiks' include:
Eliminate waste: This does not mean don't document. This means make sure you damn well need the document. Sometimes, I'll line up the headlines for a document, or titles for a few docs, and ask the audience (Devs, users, whoever) what, if anything, they think needs filling in. Sometimes I find stuff that needs the whole kit-and-kaboodle with all manner of UML, functional specs, analysis and so on. Sometimes we find that it's damn obvious, or the an existing doc already covers it, and I can just link. Summary: Eliminating waste means taking the time on the stuff that produces value, eases maintenance, and not the stuff that covers your personal ass or is just there cause some acronym says it should be.
Principles translate well between projects and industries, not practices: I don't remember if they have a heading for it, but the point of many sections of their book is that copying practices from industry (or even project) to another do not work well. Many of the principles may. The appropriate level and style of documentation for my in-house automation systems managed by technical folks is very different from what a project of equal complexity that distribute company wide and turn over to a different department to maintain. The principles around identifying needed documentation and processes are the same, but the practices certainly are not.
Note I'm working my way through several software development methodology books at the moment, Poppendicks' book is one of them., The other books are more traditional (I really wanted a few books with templates of use cases, etc, to copy for the team). I shutter at the overhead of classic waterfall development, but I took the time to learn about it because there are interesting lessons to be learned. I'd recommend that everyone do the same with agile. Applying the principles of both, you'll have some success.
RFID has interesting consequences for checkout, if as a subsequent post suggested, you have RFID on the customers (or at least their credit cards).
One sci-fi book (The Neanderthal Parallax, or something), had this scenario in an alternate universe:
Customer selects the product they want. Customer leaves store (without going through a checkout). Store reads RFID on product. Store reads credit information from customers RFID. Store debits customers account.
It sort of makes the check-out counter job obsolete, except to verify that customers have a readable credit card. We are probably going this way, whether we like it or not.
I'm at least as good at finding CIA secrets as this guy. Look what I just found on the web -
the CIA's super secret fact book!
. It most be secret, since the graphics and style look so hokey.
waiting for 56K dial up
I remember how I'd explain the internet to peers and co-workers in the 1990's. Along with the technical instruction, I'd advise them to bring a magazine to read while waiting for pages to load.
A lot of replies to this post deal with the qualities of Firefox that most users won't use (too technical) or don't care about (application platform? I can see my Granny dancing a gigue!)
There are in fact many scenarios in which IE is better than Firefox. Granted, Firefox remains my default browser. It suits my my nerdy needs excellently. However, there are a number of sites that I need every day, that Firefox doesn't render properly , or doesn't work with at all. Note that Slashdot isn't in the "need" category. I have to keep IE around for those situations.
You can blame this on non-standard HTML. You can blame it on ActiveX. You can blame it on NTLM and a slightly non-standard usage of kereberos on NT domains. Most people don't care if it ain't fair. What people see is that there are almost no sites that Firefox can do, but IE can, while there are many that IE can load, that Firefox can not.
Thus, IE appears to work, and probably does work better, for most users.
I agree, but come to a different conclusion. Poor content is probably why I didn't replace my TV when I dropped it (literally, oops) a year ago. After a few weeks without it, I realized that despite having watched hours of TV each week, there wasn't a single program that I missed.
I'm a (wanna-be) intellectual, not a rutting teenage boy, not a bored housewife. TV, in trying for "broad appeal" in all its programs, simply doesn't produce any content that interests me.
It's much more likely that a cheaper content distribution system, with a lower cost of entry, might actually produce programs niche markets.
Yeah, you can talk about cable reducing cost of entry and providing niche programing -- but the business model is wrong for me. I'm not willing to spend $50 bucks a month to get 100 channels, when I only find 1 or 2 programs per month that interest me. I might pay some internet distributer a buck or two to watch a good (in content) documentary -- just like I'd pay a few bucks to rent the DVD's of series that I do enjoy.
That said, people with my tastes probably represent a tiny fraction of the market. We'll be happy if this kind of thing comes to fruition. Overall, most folks will probably be happier with glossy shiny mass market TV.
The idea that every publication needs to attempt to be fair and unbiased only leads to chick-shit journalism and hidden biases. Frankly, I enjoy having a copy of the Economist and Sciam on my coffee table. I'd like to have the National Review and the Nation there as well, but I'm not big enough to stomach their stuff (it takes too much energy too filter water from the hogwash, and they leave me thirsty for wisdom). Magazines like Sciam and the Economist are not ashamed to have a specific world-view. There biases aren't hidden, and the facts or assumptions behind their statements are generally clear (at least in longer articles).
Contrast this to your average newspaper or weekly, which reduces every debate into he-said she said terms, without ever examining to the facts, assumptions and reasoning behind statements. A typical "unbiased" newspaper article might be summarized as "Mr Hozum states that the there is strong evidence that humans affect climate change. Mr Funkerdunk responded that there are many unknowns, and reducing greenhouse gases would be to expensive." Because the "journalist" should not editorialize, they leave misleading or downright deceptive statements unchallenged. Authors that pursue the holy grail of unbiased journalism usually fail to weed total bunk from valid arguments, and do no service to their readership. They also fail to achieve unbiased journalism, as there will always be assumptions and biases. I'd rather not work so hard to discover the biases and assumptions.
For those who wish to skip this long and tedious post, here is the moral: Use wireless to small outbuildings such as garages.
A few of the responses to the parent post were a bit confused about ground loops. A few other posts have suggested running cat 5 to the outbuilding. Having done some time working with non-profits in Africa, I have some experience with a networks involving cat 5 running between buildings, and can personally attest that this is not a good idea. Ground loops were one of many entertaining problems.
I won't repeat wikipedia's very short explanation of ground loops http://en.wikipedia.org/wiki/Ground_loop_%28electr icity%29
A facility that ran cat 5 between buildings lost up to 10% of the network cards and 25% of their hubs and routers each year to obvious surge damage. By obvious surge damage I'm refering to the melting plastic that amateurs can easily identify as electrical damage. In defense of those responsible for this installation, there was only one electrician in the province, and there were many confounding factors which could explain the high rate of electrical damage -- cheap second hand equipment, regular brown-outs, wasps nesting in PCs, wildlife eating cable sheathing, and so forth.
It is possible to ground these cables between builds, but I'd suggest careful consultation with a reasonably smart electrician. I'm not a smart electrician, so I won't mislead you with the details of how I've approached this problem. That said, you basically have to ground every conductor going from one building to another with nearly the same enthusiasm that you ground the power from building to building. That said, we greatly reduced surge damage in this scenario with lots of long metal rods, shoveling, and wishful thinking. Neither fiber nor wireless were options at the time - cost factors and the era (this was mid 1990's). I think we also replaced the CAT5 with coax, as it was easier to figure out how to ground. For good measure, you really should armor cable or use conduits when running cable outside, as rodents like to chew on it. This adds even more work to the project.
I think the moral of the story is: get a wireless router for internet in outbuildings, unless you involve a competent and professional electrician in the project. With wireless, you are not only protected from ground loops, but also protected from rodents sharpening their teeth on your cables. Fiber is still expensive, and doesn't solve the rodent problem.
I have a rotten suspision all these "I am your father" jokes have something to do with a dramatic ending, that is now totally spoiled for me.
When are you slashdot guys gonna realize that not everyone sees movies in the opening night / decade? I was waiting for the DVD of this Star Wars stuff.
Re:Running out of IPv6
on
IPv6 is Here
·
· Score: 1
I decided to speculate on wasteful uses of IPv6 addresses, and run some calculations on how long it would take to expend them.
Method #126: Mote technology matures.
Intel is working on them.
Berkely is working on them.
Each mote gets an IPV6 address. Maybe you drop a few hundred into each automobile to test everything from tire pressure to CO2 content in exhaust. I don't think this comes close to exhausting the IPv6 addresses.
Method #127: RFID tags for consumer goods. Give each and every consumer product an IPV6 address to track it from manufacturing to purchase.
Reasonable uses of IP addresses? Maybe not. But with 2^128 addresses, it would still take a very long time to use all of the address even with blatent misuse of them.
2^128 is 10^14 moles. A chemist could give you precise estimates, but a 300 milliter can of distilled water contains about 15 mole molecules of water. So, lets say that you could put an RFID tag on every water molecule in every can of pop sold. Maybe water rationing is getting very serious. You'd still have to drink 10^13 cans of pop. Coca cola sells about 4.3 * 10^9 bottles of pop a year. We could go about 23,000 years without needing to recycle IPv6 address on the water molecules. On the one hand, if we can figure out how to attach wireless TCPIP enabled RFID tags to water molecules, we can probably upgrade our IP protocols. On the other hand, who wants to update the hardware attached to 10^14 moles of water?
The link is a very interesting article - more interesting than the initial story.
To me, it looks like the largest drawback to UPnP is that it defines too much and becomes inflexible. While the current implementation of Rendezvous is directed at home networks and networks without much infrastructure, I can't see why it couldn't scale out. If / when it scales out, it will intrude on more than just UPnP. It could also kick butt all over MS's UDDI for web services. Here's a scenario for which I could profitably use a more scalable Rendezvous type functionality, where neither UPnP or UDDI would work well:
A service gets a name, independent of the machine. Clients of all types find and connect to the service. For example, we've got a critical Job Status service, that collects information about myriad automated jobs so that the staff responsible for a set of jobs can quickly check if any of their jobs are misbehaving.
Say the computer running the Job Status service blows up and rolls over to a different device (or we painfully restore it on another device). Certain fancy expensive data base servers handle this rollover smoothly - but not my home grown application. I get it almost for free with Rendezvous (expect moving the service). Because the client connects to a service name, it finds the new service seamlessly. No configuration file push, no changing C-Names in the active directory (which requires arguing with about 4 departments in my company) . Just bring up the same service name on a new device.
Rendezvous could apply to any service - not just web services as with UDDI. Also unlike UDDI, there is no need for a single point of failure (the server with the UDDI directory). Unlike UPNP, I don't have to jump through hoops to describe my service, or attempt to conform it to an existing specification - and the current ones are really focussed on devices. I don't really care about describing my service in grand detail. I can assume an application designed to work with knows how it works.
The main thing missing from Rendezvous for this scenario is scalability. Rendezvous could solve this easily by stealing the controller model for UPnP. Put up 5 or 10 controllers on our 10,000 device network. Each client knows about a few of them. You can handle the load and don't have a single point of failure.
Pascal's entire line of argument fails to explain why I should care. I RTFA'd. I even read some of the links. This is a topic near and dear to me, as I fight for better design, better technologies at work against various technology and platform zealots.
I'd argue that if you have a thesis or hypothesis, you need to make a testable predication and test it against the real world. That's the gist of science. Pascal tests XML and SQL against the Gospel of Formal Data Model's according to Codd. Pascal's arguments are theological, not practical, not scientific.
I want to know how XQuery will or will not make my job of designing and implementing solutions that save my company money. How will the problems of XQuery, or the blasphemous SQL implementations cause me problems that cost time? How do these deviations for orthodoxy really make code harder to write, harder to maintain, more prone to error? These are the relevant questions. These are issues that can also be tested against production scenarios.
I don't give a hoot about how well XML falls into Codd's formal model. I care whether or not it saves me time. I'll happily accept that normalization, taken not too literally, does saves me time. XML also saves me lots of time: makes a great prototype to store data in (gasp!) before I implement the database layer. Even for a somewhat complex schema, I can blast out a small XML document in a few minutes in my text editor of choice, and test out how the components use the data that they store. Sometimes, for small data sets such as configuration information, I even leave it in XML for years before finding a compelling reason to deal with an RDBMS. Web services (the horror!) have made the middle tier much more accessible - I can drive access to a service based on policy now, rather than to whom I can distribute the damn DLL and it's dependencies. None of this is perfect, but XML works where it makes a difference to me.
In short, regardless of how well or poorly Pascal addresses his questions, they are the wrong questions addressed in the wrong way. He should go into theology or critique Chinese literature and leave us working folks alone.
Note that they aren't selling the anti-virus as part of the OS. In fact, the article states that they won't even bundle it with the OS.
At any rate, besides the technical considerations of where anti-virus should lie, there are business considerations. Hopefully the AV folks will sit in the building next to the OS folks, so that they can walk across the street and complain about the vulnerabilities.
On the other hand, maybe they'll start creating new OS vulnerabilities, that only MS AV will protect against...
I can't agree more. The physicial world analogues for organize files are cumbersome - which is which we use computers. My file cabinet is effectively limited to 3 levels: Drawer, hanging folder, and a few manila folders in each.
Finding any item that I don't use on a daily basis in my filing cabinet takes 10 minutes. I spend 1-2 hours a month filing new items into it. Twice a year, I have to engage in several hours of cleaning. I still find expired warranties for love toys^HHHHHHHH watches I bought in the 90's hiding in crevices - and still have a hard time finding last year's car warranty.
I don't want my computer to work like my filing cabinet!
There's a need for easy to read educational materials to hand out to people. One resource is Dan Applebaum's book on security, Always use Protection. It is targeted towards teens, but is probably also applicable to the lay user as well.
All the serious worm infections (just 2) my company has had originated from home use: 1) remote access (from a network admin!) and 2) laptops (used mostly by managers).
I haven't read this book myself, but most of the but everything else I've gotten from Desaware and Dan AppleBaum has been quite good - and the table of contents looks good. Someone less lazy then myself out to do a review on this.
I might ramble a bit in making this point - so here's where I'm trying to go: I don't see how the government, or anyone else, knowing more about me and my life affects my freedom. I'd like to see much more emphasis on rights to fair trial, rights to do what I want when it doesn't hurt anyone else, rights to unionize, rights to know what my government is doing, and so forth and a lot less worrying about my privacy.
I've decided to launch a tirade on this subject, because they eventually dropped this because of "privacy" concerns. I frankly don't care at all how much or how little the government knows about me. I care how they use it.
For example: I attended an extremely liberal college in a foreign country. I've attended numerous protests. Out of curiosity I've visited a few countries not on the US's list of nice guys. I don't care if the US government knows this. I do care about how they act on it. I want to be able to act peaceable on my politics and pursue my business interests without arbitrary interference. The no-fly lists were abhorrent not because the government had lists of people that deserved watching, but because the effectively enforced punishment in the form of limiting travel without good cause.
So, I'm happy if they keep these matrix generate lists and such provided: 1) I can easily access and correct my own status in these lists. For example I should be able to walk into my local police precinct, have them establish my identity and provide my file in a few minutes. At the same time, I can petition for corrections. 2) They do not use weak evidence to restrict my rights to travel (such as the no-fly lists). If they want to hang out outside my condo and watch me - what do I care? As soon as they start inconveniencing me, they are abusing this information. But this is not about privacy, this is about other rights.
What is worrying, is at the same time the government is collecting more information about its citizens, it is providing less information about itself. This administration has classified documents at a much greater rate than previous administrations. (E.G. Why were human rights abuse reports classified?). This creates a discrepancy in the information that the government has about me, and the information that I have about the government.
So: Let the government collect all the info it wants, but make it very difficult for the government to classify and conceal information, and put in place much stronger safe-guards to ensure fair treatment and due process.
Everyone who works in IT knows this story: You or your boss make a promise for a deliverable two months out. Turns out, 5 unexpected complications come in, and 1 and a 1/2 months in, you find yourself pulling 80 hour weeks to meet deadline. Point is that it feels bad to work long weeks, only to miss a deadline anyway. My whole posting here goes at the idea that the more you feel in control, the less you feel stressed. Two problems in getting IT estimates under control: 1) It is infamously difficult to make good cost and time estimates in IT. 2) IT jobs typically are salaried, not hourly. There hasn't been a huge cost pressure on management to avoid overtime.
Well, I can't fix problem 2 - but problem 1 can be addressed. Attack the problem by developing a better and more realistic approach to deadlines. If I talk to a house contractor, he'll tell me with good accuracy that I can expect x dollars per square foot, x dollars per electrical fixture. You can even find standard estimating tables. I've never seen such handy rules of thumb for the IT business. In fields like web design - which use known design patterns and tools, it's probably achievable - except that they tools keep changing. Some of my friends who do contracts make and meet bids, but just as frequently over or under bid. Many work day jobs at big companies to hedge against these mis-calculations in their contracting.
Here are some handy suggestions to start relieving deadline pressure:
- Even if you aren't a manager, read about software management. If you don't like to spend money, go to your favorite big bookstore on a Saturday morning once a month, get a cup of coffee, and skim the various books to get a idea of the approaches.
- Keep a very open dialog with your boss and/or direct reports about process. Talk about what's good and bad. Keep looking for creative solutions.
- You need to gather empirical data on how long it took to finish various projects. Empirical data on past projects, rather than guesses, should form the basis of future estimates. Do you have some project tracking tool? Sometimes, I imagine that I finished my last project in 40 hours of work. If I actually look at the time in our project management tool , is usually 2-3 times what I thought. Time flies when you're having fun!
- Deliver something every week. In my team, we insist that something tangible is turned over to someone every week. Sometimes, a project gets behind schedule, and the embarrased programmer tries to hide it, rather than deal with it. Forcing something visible to show every week makes hiding problems very difficult, and allows us to redistribute team resources to deal with the problem. If something is going behind schedule - you know well in advance, and can communicate with the customer well in advance rather than working 80 hours weeks as the deadline approaches.
- Insist that a project has a solid requirements document, and a solid analysis of how to solve the problem, before promises are made. I had a string of plumbers in to give estimates. All of them spent an hour looking at our plumbing, went home, thought about it, and sent an estimate a week later.
- Don't code extra stuff. I'm way too creative, and like to write really fun programs and neat features. Creativity is good, but at work this can be a liability. Noone wants to pay for something that they didn't ask for - and I get behind schedule writing features noone really wants. Thus - I've started personal projects to release my creative energies - like building an enterprise scale security system from scratch for my personal home page to keep the wrong people from looking at family baby pictures.
That said, after 5 years in the business, and a few more years in related industries, I just barely have enough experience to avoid getting myself into trouble with sloppy project management and optimistic estimates. At 24, I probably should have leveraged my experienced col
Not to mention that they don't support the Pentium line of processors. From FAQ - MINIMUM requirements: 1x Intel Xeon, Intel Itanium, AMD Opteron, Sun SPARC, IBM PowerPC I guess they think you won't bother clustering on anything less than a hefty server. I won't be testing this at home.
Slashdot Mirror
I'll sadly agree that the degree is essential.
My recommendations: make sure that the syllabus and course work are comparable to the traditional institutions, and make sure that you have a solid resume (experiences and clear demonstrations of skill). Make sure you are working on real projects in relevant technologies (even part time) so that you can put the magic "5/7 years experience in x" on your resume.
Unfortunate realities:
The degree matters. The school matters. The subject matters. The technology platform matters.
I've had the opportunity to do quite a bit of hiring and interviewing over the last few years. My team keeps earning money, and we grow. Other managers tend to invite me to interviews with technical candidates, because I can sort the chaff from the wheat.
I tend towards flexibility in looking at candidates. If I don't know the school, I look at the syllabus. Hint: A master's from City U (I'm talkning about the for-profit degree factory, not CUNY) is approximately equivalent to the first two years of CS in most real universities. I look at the candidate's projects and work. In interviews, I take as much time as I can to ask hard technical questions to verify that they know the subject matter and can think on their feet.
Unfortunately, I'm the exception that proves the rule. Your degree and where you got it are critical to getting into interviews. Most HR departments have a list of 10 criteria and 1000 resumes to screen. Degree + experience are cheap to evaluate. I've pulled resumes out of my HR's wastebin that HR scored low because the candidate was a year or a degree short, but a quick dig into the resume and work showed that they knew their stuff. I've also wasted a lot of time in interviews with people who didn't have a clue, but scored well.
Basically, a degree and work experience will get into interviews. Even if you don't know anything, you can always get contract work through [insert contract-o-matic agency here] if you have a degree. There's always someone who needs a programmer ASAP, and a recruiting agency willing to provide them one without much screening.
Finally, if your skills are there but your resume is imperfect, don't underestimate what recruiting agencies can do for you. Most are really lousy (Volt, etc.) -- I've had agencies offer me contract jobs 1000 miles away when my resume has "will not relocate" and "permenant work only" in bold. A few rare companies take the time to understand a persons skills, and communicate them to employers. Find those companies and work with them.
Are you new here? Slashdot has nothing to do with getting stuff done. It's something to do in between, or instead of, getting stuff done.
I live in Seattle, you insenstive clod!
I wonder if I could supplement a summer solar system, with a winter rain powered mini-hydroelectric system. Any nerds care to calculate how much wattage could be generated by Seattles rainfall on a 1000 sq ft area, assuming I can drop it 20' from roof to sewer? Could I run my coffee pot (assume 1-2 amps at 120v for 5 minutes) once a day?
My apologies, it looks like I didn't read far enough up the thread to understand the context properly.
I very much agree that shunting off user requirements can be costly. It might make initial project development cheaper, but it makes the product worth less. One of the things I like about iterative development, is that it provides a clear approach to handling late breaking user requirements. One of the things that I like about good old waterfall, is that you invest enough time in planning to be able to create a design that is robust enough to flex to meet new requirements.
My major software project management problem is getting developers to read and respect specs. While the classic pieces of the puzzle (management, process, docs) are in place, I've couple bright, creative developers, who tend to code to their own drummer. This works fine on small projects with just one dev, but on the larger projects, we end up rewriting a lot of great code that doesn't follow the design and spec. Agile, lean, waterfall and all other methodologies all start with the flimsy assumption that devs will want to read the documents produced and generally follow direction. Do you know any methods for herding cats?
The arguments that you make against agile software development are actually dealt with in a quick "myths about agile software development" in the start of this book. This argument, and many other made against agile, are classic straw men -- you are attacking a weaker argument, never made by proponents of lean or agile software development.
The example you give is a POORLY managed project, and would have failed no matter what methodology was used. Someone might have been using "agile" or "lean" as an excuse to be lazy.
The key points made by the Poppendiks' include:
Eliminate waste:
This does not mean don't document. This means make sure you damn well need the document. Sometimes, I'll line up the headlines for a document, or titles for a few docs, and ask the audience (Devs, users, whoever) what, if anything, they think needs filling in. Sometimes I find stuff that needs the whole kit-and-kaboodle with all manner of UML, functional specs, analysis and so on. Sometimes we find that it's damn obvious, or the an existing doc already covers it, and I can just link. Summary: Eliminating waste means taking the time on the stuff that produces value, eases maintenance, and not the stuff that covers your personal ass or is just there cause some acronym says it should be.
Principles translate well between projects and industries, not practices:
I don't remember if they have a heading for it, but the point of many sections of their book is that copying practices from industry (or even project) to another do not work well. Many of the principles may. The appropriate level and style of documentation for my in-house automation systems managed by technical folks is very different from what a project of equal complexity that distribute company wide and turn over to a different department to maintain. The principles around identifying needed documentation and processes are the same, but the practices certainly are not.
Note I'm working my way through several software development methodology books at the moment, Poppendicks' book is one of them., The other books are more traditional (I really wanted a few books with templates of use cases, etc, to copy for the team). I shutter at the overhead of classic waterfall development, but I took the time to learn about it because there are interesting lessons to be learned. I'd recommend that everyone do the same with agile. Applying the principles of both, you'll have some success.
RFID has interesting consequences for checkout, if as a subsequent post suggested, you have RFID on the customers (or at least their credit cards).
One sci-fi book (The Neanderthal Parallax, or something), had this scenario in an alternate universe:
Customer selects the product they want.
Customer leaves store (without going through a checkout).
Store reads RFID on product.
Store reads credit information from customers RFID.
Store debits customers account.
It sort of makes the check-out counter job obsolete, except to verify that customers have a readable credit card. We are probably going this way, whether we like it or not.
I'm at least as good at finding CIA secrets as this guy. Look what I just found on the web - the CIA's super secret fact book! . It most be secret, since the graphics and style look so hokey.
waiting for 56K dial up
I remember how I'd explain the internet to peers and co-workers in the 1990's. Along with the technical instruction, I'd advise them to bring a magazine to read while waiting for pages to load.
A lot of replies to this post deal with the qualities of Firefox that most users won't use (too technical) or don't care about (application platform? I can see my Granny dancing a gigue!)
There are in fact many scenarios in which IE is better than Firefox. Granted, Firefox remains my default browser. It suits my my nerdy needs excellently. However, there are a number of sites that I need every day, that Firefox doesn't render properly , or doesn't work with at all. Note that Slashdot isn't in the "need" category. I have to keep IE around for those situations.
You can blame this on non-standard HTML. You can blame it on ActiveX. You can blame it on NTLM and a slightly non-standard usage of kereberos on NT domains. Most people don't care if it ain't fair. What people see is that there are almost no sites that Firefox can do, but IE can, while there are many that IE can load, that Firefox can not.
Thus, IE appears to work, and probably does work better, for most users.
Content is King:
I agree, but come to a different conclusion. Poor content is probably why I didn't replace my TV when I dropped it (literally, oops) a year ago. After a few weeks without it, I realized that despite having watched hours of TV each week, there wasn't a single program that I missed.
I'm a (wanna-be) intellectual, not a rutting teenage boy, not a bored housewife. TV, in trying for "broad appeal" in all its programs, simply doesn't produce any content that interests me.
It's much more likely that a cheaper content distribution system, with a lower cost of entry, might actually produce programs niche markets.
Yeah, you can talk about cable reducing cost of entry and providing niche programing -- but the business model is wrong for me. I'm not willing to spend $50 bucks a month to get 100 channels, when I only find 1 or 2 programs per month that interest me. I might pay some internet distributer a buck or two to watch a good (in content) documentary -- just like I'd pay a few bucks to rent the DVD's of series that I do enjoy.
That said, people with my tastes probably represent a tiny fraction of the market. We'll be happy if this kind of thing comes to fruition. Overall, most folks will probably be happier with glossy shiny mass market TV.
The idea that every publication needs to attempt to be fair and unbiased only leads to chick-shit journalism and hidden biases. Frankly, I enjoy having a copy of the Economist and Sciam on my coffee table. I'd like to have the National Review and the Nation there as well, but I'm not big enough to stomach their stuff (it takes too much energy too filter water from the hogwash, and they leave me thirsty for wisdom). Magazines like Sciam and the Economist are not ashamed to have a specific world-view. There biases aren't hidden, and the facts or assumptions behind their statements are generally clear (at least in longer articles).
Contrast this to your average newspaper or weekly, which reduces every debate into he-said she said terms, without ever examining to the facts, assumptions and reasoning behind statements. A typical "unbiased" newspaper article might be summarized as "Mr Hozum states that the there is strong evidence that humans affect climate change. Mr Funkerdunk responded that there are many unknowns, and reducing greenhouse gases would be to expensive." Because the "journalist" should not editorialize, they leave misleading or downright deceptive statements unchallenged. Authors that pursue the holy grail of unbiased journalism usually fail to weed total bunk from valid arguments, and do no service to their readership. They also fail to achieve unbiased journalism, as there will always be assumptions and biases. I'd rather not work so hard to discover the biases and assumptions.
For those who wish to skip this long and tedious post, here is the moral: Use wireless to small outbuildings such as garages.
r icity%29
A few of the responses to the parent post were a bit confused about ground loops. A few other posts have suggested running cat 5 to the outbuilding. Having done some time working with non-profits in Africa, I have some experience with a networks involving cat 5 running between buildings, and can personally attest that this is not a good idea. Ground loops were one of many entertaining problems.
I won't repeat wikipedia's very short explanation of ground loops http://en.wikipedia.org/wiki/Ground_loop_%28elect
A facility that ran cat 5 between buildings lost up to 10% of the network cards and 25% of their hubs and routers each year to obvious surge damage. By obvious surge damage I'm refering to the melting plastic that amateurs can easily identify as electrical damage. In defense of those responsible for this installation, there was only one electrician in the province, and there were many confounding factors which could explain the high rate of electrical damage -- cheap second hand equipment, regular brown-outs, wasps nesting in PCs, wildlife eating cable sheathing, and so forth.
It is possible to ground these cables between builds, but I'd suggest careful consultation with a reasonably smart electrician. I'm not a smart electrician, so I won't mislead you with the details of how I've approached this problem. That said, you basically have to ground every conductor going from one building to another with nearly the same enthusiasm that you ground the power from building to building. That said, we greatly reduced surge damage in this scenario with lots of long metal rods, shoveling, and wishful thinking. Neither fiber nor wireless were options at the time - cost factors and the era (this was mid 1990's). I think we also replaced the CAT5 with coax, as it was easier to figure out how to ground. For good measure, you really should armor cable or use conduits when running cable outside, as rodents like to chew on it. This adds even more work to the project.
I think the moral of the story is: get a wireless router for internet in outbuildings, unless you involve a competent and professional electrician in the project. With wireless, you are not only protected from ground loops, but also protected from rodents sharpening their teeth on your cables. Fiber is still expensive, and doesn't solve the rodent problem.
I have a rotten suspision all these "I am your father" jokes have something to do with a dramatic ending, that is now totally spoiled for me.
When are you slashdot guys gonna realize that not everyone sees movies in the opening night / decade? I was waiting for the DVD of this Star Wars stuff.
I decided to speculate on wasteful uses of IPv6 addresses, and run some calculations on how long it would take to expend them.
Method #126: Mote technology matures. Intel is working on them. Berkely is working on them.
Each mote gets an IPV6 address. Maybe you drop a few hundred into each automobile to test everything from tire pressure to CO2 content in exhaust. I don't think this comes close to exhausting the IPv6 addresses.
Method #127: RFID tags for consumer goods. Give each and every consumer product an IPV6 address to track it from manufacturing to purchase.
Reasonable uses of IP addresses? Maybe not. But with 2^128 addresses, it would still take a very long time to use all of the address even with blatent misuse of them.
2^128 is 10^14 moles. A chemist could give you precise estimates, but a 300 milliter can of distilled water contains about 15 mole molecules of water. So, lets say that you could put an RFID tag on every water molecule in every can of pop sold. Maybe water rationing is getting very serious. You'd still have to drink 10^13 cans of pop. Coca cola sells about 4.3 * 10^9 bottles of pop a year. We could go about 23,000 years without needing to recycle IPv6 address on the water molecules. On the one hand, if we can figure out how to attach wireless TCPIP enabled RFID tags to water molecules, we can probably upgrade our IP protocols. On the other hand, who wants to update the hardware attached to 10^14 moles of water?
The link is a very interesting article - more interesting than the initial story.
To me, it looks like the largest drawback to UPnP is that it defines too much and becomes inflexible. While the current implementation of Rendezvous is directed at home networks and networks without much infrastructure, I can't see why it couldn't scale out. If / when it scales out, it will intrude on more than just UPnP. It could also kick butt all over MS's UDDI for web services. Here's a scenario for which I could profitably use a more scalable Rendezvous type functionality, where neither UPnP or UDDI would work well:
A service gets a name, independent of the machine. Clients of all types find and connect to the service. For example, we've got a critical Job Status service, that collects information about myriad automated jobs so that the staff responsible for a set of jobs can quickly check if any of their jobs are misbehaving.
Say the computer running the Job Status service blows up and rolls over to a different device (or we painfully restore it on another device). Certain fancy expensive data base servers handle this rollover smoothly - but not my home grown application. I get it almost for free with Rendezvous (expect moving the service). Because the client connects to a service name, it finds the new service seamlessly. No configuration file push, no changing C-Names in the active directory (which requires arguing with about 4 departments in my company) . Just bring up the same service name on a new device.
Rendezvous could apply to any service - not just web services as with UDDI. Also unlike UDDI, there is no need for a single point of failure (the server with the UDDI directory). Unlike UPNP, I don't have to jump through hoops to describe my service, or attempt to conform it to an existing specification - and the current ones are really focussed on devices. I don't really care about describing my service in grand detail. I can assume an application designed to work with knows how it works.
The main thing missing from Rendezvous for this scenario is scalability. Rendezvous could solve this easily by stealing the controller model for UPnP. Put up 5 or 10 controllers on our 10,000 device network. Each client knows about a few of them. You can handle the load and don't have a single point of failure.
Pascal's entire line of argument fails to explain why I should care. I RTFA'd. I even read some of the links. This is a topic near and dear to me, as I fight for better design, better technologies at work against various technology and platform zealots.
I'd argue that if you have a thesis or hypothesis, you need to make a testable predication and test it against the real world. That's the gist of science. Pascal tests XML and SQL against the Gospel of Formal Data Model's according to Codd. Pascal's arguments are theological, not practical, not scientific.
I want to know how XQuery will or will not make my job of designing and implementing solutions that save my company money. How will the problems of XQuery, or the blasphemous SQL implementations cause me problems that cost time? How do these deviations for orthodoxy really make code harder to write, harder to maintain, more prone to error? These are the relevant questions. These are issues that can also be tested against production scenarios.
I don't give a hoot about how well XML falls into Codd's formal model. I care whether or not it saves me time. I'll happily accept that normalization, taken not too literally, does saves me time. XML also saves me lots of time: makes a great prototype to store data in (gasp!) before I implement the database layer. Even for a somewhat complex schema, I can blast out a small XML document in a few minutes in my text editor of choice, and test out how the components use the data that they store. Sometimes, for small data sets such as configuration information, I even leave it in XML for years before finding a compelling reason to deal with an RDBMS. Web services (the horror!) have made the middle tier much more accessible - I can drive access to a service based on policy now, rather than to whom I can distribute the damn DLL and it's dependencies. None of this is perfect, but XML works where it makes a difference to me.
In short, regardless of how well or poorly Pascal addresses his questions, they are the wrong questions addressed in the wrong way. He should go into theology or critique Chinese literature and leave us working folks alone.
Note that they aren't selling the anti-virus as part of the OS. In fact, the article states that they won't even bundle it with the OS.
...
At any rate, besides the technical considerations of where anti-virus should lie, there are business considerations. Hopefully the AV folks will sit in the building next to the OS folks, so that they can walk across the street and complain about the vulnerabilities.
On the other hand, maybe they'll start creating new OS vulnerabilities, that only MS AV will protect against
I can't agree more. The physicial world analogues for organize files are cumbersome - which is which we use computers. My file cabinet is effectively limited to 3 levels: Drawer, hanging folder, and a few manila folders in each.
Finding any item that I don't use on a daily basis in my filing cabinet takes 10 minutes. I spend 1-2 hours a month filing new items into it. Twice a year, I have to engage in several hours of cleaning. I still find expired warranties for love toys^HHHHHHHH watches I bought in the 90's hiding in crevices - and still have a hard time finding last year's car warranty.
I don't want my computer to work like my filing cabinet!
There's a need for easy to read educational materials to hand out to people. One resource is Dan Applebaum's book on security, Always use Protection. It is targeted towards teens, but is probably also applicable to the lay user as well.
All the serious worm infections (just 2) my company has had originated from home use: 1) remote access (from a network admin!) and 2) laptops (used mostly by managers).
I haven't read this book myself, but most of the but everything else I've gotten from Desaware and Dan AppleBaum has been quite good - and the table of contents looks good. Someone less lazy then myself out to do a review on this.
Put up AND shut up?
Put up OR shut up?
I'd suggest that the situation is most accurated describe by "Put up" implies "shut up", or (Put Up NAND Shut Up) NAND Put Up.
This gives two cases returing true:
1) Neither put up nor shut up: SCO keeps making noise, without producing evidence.
2) Both put up and shut up.
SCO produces all extant evidence, and they are consequently forced to shut up.
I might ramble a bit in making this point - so here's where I'm trying to go: I don't see how the government, or anyone else, knowing more about me and my life affects my freedom. I'd like to see much more emphasis on rights to fair trial, rights to do what I want when it doesn't hurt anyone else, rights to unionize, rights to know what my government is doing, and so forth and a lot less worrying about my privacy.
I've decided to launch a tirade on this subject, because they eventually dropped this because of "privacy" concerns. I frankly don't care at all how much or how little the government knows about me. I care how they use it.
For example: I attended an extremely liberal college in a foreign country. I've attended numerous protests. Out of curiosity I've visited a few countries not on the US's list of nice guys. I don't care if the US government knows this. I do care about how they act on it. I want to be able to act peaceable on my politics and pursue my business interests without arbitrary interference. The no-fly lists were abhorrent not because the government had lists of people that deserved watching, but because the effectively enforced punishment in the form of limiting travel without good cause.
So, I'm happy if they keep these matrix generate lists and such provided:
1) I can easily access and correct my own status in these lists. For example I should be able to walk into my local police precinct, have them establish my identity and provide my file in a few minutes. At the same time, I can petition for corrections.
2) They do not use weak evidence to restrict my rights to travel (such as the no-fly lists). If they want to hang out outside my condo and watch me - what do I care? As soon as they start inconveniencing me, they are abusing this information. But this is not about privacy, this is about other rights.
What is worrying, is at the same time the government is collecting more information about its citizens, it is providing less information about itself. This administration has classified documents at a much greater rate than previous administrations. (E.G. Why were human rights abuse reports classified?). This creates a discrepancy in the information that the government has about me, and the information that I have about the government.
So:
Let the government collect all the info it wants, but make it very difficult for the government to classify and conceal information, and put in place much stronger safe-guards to ensure fair treatment and due process.
You'd probably learn more, writing this program, then you would writing the essay. You'd probably also spend much more time. A well deserved A!
Everyone who works in IT knows this story: You or your boss make a promise for a deliverable two months out. Turns out, 5 unexpected complications come in, and 1 and a 1/2 months in, you find yourself pulling 80 hour weeks to meet deadline. Point is that it feels bad to work long weeks, only to miss a deadline anyway. My whole posting here goes at the idea that the more you feel in control, the less you feel stressed. Two problems in getting IT estimates under control:
1) It is infamously difficult to make good cost and time estimates in IT.
2) IT jobs typically are salaried, not hourly. There hasn't been a huge cost pressure on management to avoid overtime.
Well, I can't fix problem 2 - but problem 1 can be addressed. Attack the problem by developing a better and more realistic approach to deadlines. If I talk to a house contractor, he'll tell me with good accuracy that I can expect x dollars per square foot, x dollars per electrical fixture. You can even find standard estimating tables. I've never seen such handy rules of thumb for the IT business. In fields like web design - which use known design patterns and tools, it's probably achievable - except that they tools keep changing. Some of my friends who do contracts make and meet bids, but just as frequently over or under bid. Many work day jobs at big companies to hedge against these mis-calculations in their contracting.
Here are some handy suggestions to start relieving deadline pressure:
- Even if you aren't a manager, read about software management. If you don't like to spend money, go to your favorite big bookstore on a Saturday morning once a month, get a cup of coffee, and skim the various books to get a idea of the approaches.
- Keep a very open dialog with your boss and/or direct reports about process. Talk about what's good and bad. Keep looking for creative solutions.
- You need to gather empirical data on how long it took to finish various projects. Empirical data on past projects, rather than guesses, should form the basis of future estimates. Do you have some project tracking tool? Sometimes, I imagine that I finished my last project in 40 hours of work. If I actually look at the time in our project management tool , is usually 2-3 times what I thought. Time flies when you're having fun!
- Deliver something every week. In my team, we insist that something tangible is turned over to someone every week. Sometimes, a project gets behind schedule, and the embarrased programmer tries to hide it, rather than deal with it. Forcing something visible to show every week makes hiding problems very difficult, and allows us to redistribute team resources to deal with the problem. If something is going behind schedule - you know well in advance, and can communicate with the customer well in advance rather than working 80 hours weeks as the deadline approaches.
- Insist that a project has a solid requirements document, and a solid analysis of how to solve the problem, before promises are made. I had a string of plumbers in to give estimates. All of them spent an hour looking at our plumbing, went home, thought about it, and sent an estimate a week later.
- Don't code extra stuff. I'm way too creative, and like to write really fun programs and neat features. Creativity is good, but at work this can be a liability. Noone wants to pay for something that they didn't ask for - and I get behind schedule writing features noone really wants. Thus - I've started personal projects to release my creative energies - like building an enterprise scale security system from scratch for my personal home page to keep the wrong people from looking at family baby pictures.
That said, after 5 years in the business, and a few more years in related industries, I just barely have enough experience to avoid getting myself into trouble with sloppy project management and optimistic estimates. At 24, I probably should have leveraged my experienced col
Not to mention that they don't support the Pentium line of processors. From FAQ - MINIMUM requirements:
1x Intel Xeon, Intel Itanium, AMD Opteron, Sun SPARC, IBM PowerPC
I guess they think you won't bother clustering on anything less than a hefty server. I won't be testing this at home.
LILO uses LAME? Wow, I can encode MP3s, without even booting the OS!