I'm sorry, but if you think this is a straightforward task, you are making the same mistake Diebold did. Programming is just one minor part of the whole system they need to implement.
Calculating this with any accuracy would require knowledge of both the width of a Stegasaur (which can be approximated from their fossils), but also how fast they ran. Given other arguments about the unknowns of dinosaurs, the figures we can guesstimate for their speed are just to varied to calculate this capacity to any meaningful value.
I'm sure this will be said to death by the time this post closes for comments, and while this analysis might have merit when done from the viewpoint of someone 'valuing their own labor', the same way donations to charity dry up during hard economic times, that analysis does not apply for several reasons:
1) Something that has been open sourced is perpetually in the open source marketplace. Often called the 'viral nature of the GPL', an economic downturn cannot take away, say, MySQL or JBoss. Both are here, and are here to stay. His argument could be taken to mean innovation may stop temporarily, and I'd entertain that notion.
2) Companies seeking ways to control their costs will EMBRACE open source, so its use will INCREASE. If a CEO is facing a choice between his cushy salary or a license for WebLogic or Oracle, He will choose his salary and tell his IT department to find alternatives. they will, n JBoss and MySql.
3) Training budgets will shrink. So if you can learn everything you need to know to write Rails apps from sources like http://www.railscasts.com/ you are going to build your next app in Rails, as opposed to ColdFusion (and if you have never heard of Cold Fusion, that proves my point - PHP and Java pretty much killed it during the dot-bomb ays).
4) Tech jobs will dry up - and the cream of the crop will need to distinguish themselves. I have heard Dave Thomas (PragDave) say on several occasions that our industry would be better off if we fired the bottom half of developers. This economic downturn may see that happen, and the top half will need to distinguish themselves. the currency of this kingdom is knowledge, and the way we demonstrate this knowledge is by sharing it with others... So I expect to see an INCREASE in blogs, contributions to open source as resume building, etc.
I could go on and on - for instance, people seeking free training will go to more user group meetings... people seeking to network for job opportunities will go to more user group meetings - people seeking to distinguish themselves will want to PRESENT at said user group meetings.
As I said in a post a few months ago, I am seeing an INCREASE in the aount of work I'm doing... why? I develop and I train on open source technologies and agile development methodologies... it is all about doing more with less.
Don't just survive - THRIVE during this downturn. I'll see the best of you on the other side of this downturn, still here reading slashdot, still climbing the skills mountain.
Yes, my company has done this for a client and we are about to do it for one more. We have 3 servers hosted at 'traditional' hosing providers (one at Rimu Hosting, the other at ServerBeach), and during peak load, we fire up Amazon EC2 instances and throw traffic towards them. The 'real hardware' servers can handle normal traffic and redundancy (any one can fail), we just use the cloud for handling peak traffic. We also use the cloud for creating a multiple machine staging environment for testing. We can fire that up, deploy to test, and have the client check out all the new features, and it only costs us a dollar or two.
As cost effective as short bursts are, if they stay up for any amount of time, they cease to be cost effective. I never understand why people think EC2 is so cost effective when, at 10 cents an hour, you will pay $72/month... When you can get a virtual machine that is as performant from a company like Rimu for ~$30-40, or a dedicated resource for something like $90.
Just once, I'd like to see a report on the LHC that didn't call the Higgs Boson the "God Particle", and didn't talk about crackpot fears of mini black holes. I mean, we don't follow every report from the Mars polar lander or rovers about the "Canals of Mars were once thought to carry water", do we?
First, a disclaimer - My consulting company specializes in consulting on this topic, so you might consider me biased. On the other hand, I started this company because I had the experience, and saw the need.
Second, so this won't seem like a commercial, let me say I'm not answering this for any consulting opportunity... I answer slashdot questions all the time without looking for monetary gain; I'm just speaking from experience here.
There are a ton of great references for working together as a team - Any or the books from the Extreme Programming Explained series, a book on Scrum, Bob Martin's book on Agile Project Management, a dramatic reading of 'The Pragmatic Programmer', the book 'Practices of an Agile Developer' (in which several of my stories are published), or the book 'The Productive Programmer', recently published by OReilly (for which I wrote the forward), etc. But reading a book and putting it into practice are very different things. I strongly believe that teams should have mentors. (Thus the name of my company, CodeSherpas - as in we are guides to the terrain, but again, not a plug, just a reference for the kind of thing you need).
You have a fantastic opportunity here - to create a team culture where there are values like continual education, the team not afraid to learn from mistakes, peer reviews and retrospectives, iterative development, proper estimation techniques, and so on. Don't squander it. Find a good book that talks about the 'way things should be' - there are probably a zillion references here on slashdot already, but once you have that, make sure you get someone who has done it before... Even if it is just for a week of consulting/training, and then an occasional 'tune up'. And don't get a talking head... you want "visiting professor", not "ivory tower". A little bit of experience brought into your team now will mean that by this time next year, a group of ~3 awesome people who really know how to work as a team could be out-performing a team of ~7 people who just 'get it' enough to 'get by'.
There is no 'one size fits all'. It depends on the language, the corporate culture, and even the kind of app you might be writing.
A coding standard is necessary for teams of any reasonable size - even though people will complain about them, chances are if the team is that large, the code will be maintained for 'generations' of developers. You need to optimize for the poor sod a year from now who has to understand what this code is doing, not optimize for the guy today who wants to be clever.
The coding standard should not be externally imposed by an organization that doesn't have to live with the decisions.
The coding standard should evolve over time. Languages change - for example most coding standards I've seen for Java don't say 'boo' about the syntax changes introduced with generics or annotations.
Here's how you achieve that:
1) Start with a blank whiteboard 2) get the team that will be writing the code together 3) list everything you agree upon, get that out of the way 4) list stuff you *mostly* agree on, and get dissenters on board, even if only for a 'trial' period. 5) Every few weeks (perhaps corresponding with your retrospective at the end of an iteration), review what is working, what isn't and make changes.
This way, the standards will evolve with the needs of the team, and people who dissent only have a few weeks before they get to try to sway people again, and learn to give up if the idea doesn't take hold.
Respect people's pain when making these decisions. You might have strong opinions that conflict with someone else on your team - in the long run, it doesn't matter who is 'right', but the poor guy who is constantly trying to pull fixes up into a release branch might really be pissed off when the 'brace placement churn' causes him issues. He might not care *where* they are, just that they don't change every week.
Issues that there are no good answers to: 1) When you change your coding conventions, what heppens to all the code that follows the older conventions?
2) If you are doing a lot with branching and merging in a version control tool, churning of the coding standard can create 'false diffs'. You'll want to minimize these while evolving the standard.
So, don't try to come up with the perfect coding convention document, try to come up with the perfect mechanism by which your team can develop and evolve the conventions they need.
I had a uch longer post but I wasn't logged in - when I logged in, slashdot ate my homework. so, shorter and more to the point this time:
1) the most important feature set a language can offer, and the most important thing that separates intermediate from awesome programmers is proper packaging of concepts in code. I don't mean packaging for the language, or for the IDE... I mean for the human to solve a problem at one level of abstrction, maintain it at that level, and use it at another level of abstraction without thinking about it too much. Java got this mostly right with packages (and the little used package-level access modifier), and is one of the reasons I still like Java so much. This is also one of the reasons Ruby is such a nice language - I can bundle abstractions up in declarative statements that start to look like keywords in the language - think of the way Rails does things like "belongs_to" and "validates_presence_of". I was on the JSR for the upcoming Java Module System, so this is something I have thought about.
2) regardless of the process methodology, configuration management is something that has to be disciplined for real software development. I don't just mean version control - I mean requirements management (work backlog), version control, branching, merging, repeatable builds, continuous integration, defect tracking, deploys, backup and restore, reconstitution plan, and a bunch of other things that about to project-wide afety nets and 'undo' operations. Rather than try to build the perfect softare, we (very zen-like) embrace the fact that we can't write perfect software and plan accordingly. This makes the software better.
If you want to get some real thought provoking converation about this, I would suggest that you find the nearest NFJS conference to you (www.nofluffjuststuff.com), and hang out with the speakers some saturday night as we drink scotch in a hotel bar and discuss this kind of stuff until we annoy everyone else out of the area.
Agreed. My first ideal solution (for bookmarks, anyway) would be a plugin that let me use my browser's bookmark manus, shortcuts, etc. but just stored them at del.icio.us.
My second ideal solution would be something like google browser sync that let me provide the path and credentials for something like an svn repository, and stored and synced from there. That way, I wouldn't be relying on some unknown server to keep things like passwords and cookies secure.
Employee: "You know boss, we really should devote some time to updating the Browser Sync tool to work with Firefox 3..."
Manager: "I have been meaning to talk to you about that... You see, we have been thinking about it, and there really isn't a way to make ad revenue from that tool. While it is cool and useful and all, I don't think people would be happy with ad links showing up randomly in their bookmark menus."
Employee: "Um, yeah... I agree with that. I didn't reslize..."
Manager: "The ad revenue thing? Yeah... well something has to pay for that 20% self-directed time since ad revenues are down. The good news is we think that the Google Toolbar can replace it, and we have a plan for monetizing that."
Employee: "Well, can I work on the FF3 upgrade in my 20% self-directed time and open source the tool?"
Manager: "We thought about that too - first, the Google Toolbar doesn't need the competition. Second, we can't release the code in the shape its in... people would throw our 'do no evil' slogan back at us and slashdot would be all a-titter. It would take as much to clean it up as it would just to get it to work with FF3, so we think it is at its end-of-life."
Yes, static analysis, especially with some of the open source tools available in the Java space, can be awesome. Check out PMD and FindBugs for two awesome examples of this. Both are free, and do everything you could ever want. If you are willing to pay money for a tool like this though, you are focusing on the wrong things.
No, these tools won't catch entire categories of bugs that can only crop up while your application is running. For those, use unit tests, profilers, etc. For an explanation beyond code for this, check out the book "Godel Escher Bach, an Eternal Golden Braid", specifically the discussion about recording records that when played, destroy the record player playing them. No, its not real, its a thought experiment.
It might be 'your database', but it sounds like it the 'their data'. Give it to them. Whats wrong with read-only access? My guess is it boils down to fear of:
a) working yourself out of a job. Why would they need you as the bitkeeper if they can write their own queries.
or
b) someone who knows better might tell you why your schema sucks.
In either csse, sharing the data might be a hard thing to do, but is in your long-term best interests... do you want to be maintaining reports forever? If you are designing a lousy database, wouldn't you want the education to do it right?
Chances are most of those buttons are there because some Marketing/Sales wonk decided it had to be there, not some engineer. Chances are, the engineers had some other way to do it, but everyone thought it was too "complicated for normal people... give them a button to do it instead".
I'm quite certain that is how "email" and "web" buttons appeared on keyboards... some marketer said "I want the box to say this is an INTERNET keyboard!"
I just downloaded the fonts, and installed them on my mac, where I am now using consolas to write a rails application that will be bundled as a WAR file and deployed in a Java application server.
That isn't against any terms of service for a font from Microsoft, is it?
The metric should be 'number of times the sysadmin has to be consulted', and it should be driven as close to zero as possible.
I might get moded 'funny', or 'flamebait', but I'm serious.
Think about it. When is a sysadmin needed? When there is some kind of crisis. "I can't get to the internet", "I can't check m email", "My computer thinks I might have won a million dollars", "I lost that important project file". A good sysadmin will prevent these things from ever happening, and when they do happen will have them resolved quickly, without a lot of technobabble or attitude (like the SNL skit guy), and will fade into the woodwork. Ironically, the middle-of-the-road IT guys are often thought of as heroes by the staff they support. They might be thought of as the firefighters, but unfortunately, they are also often the pyromaniacs.
Other useful metrics:
If you don't already have a ticket support system, get one. It will generate useful metrics for you. Some useful things out of it would be:
- The AGE of the OLDEST OPEN SUPPORT TICKET. Proves you aren't dilly-dallying
- Number of Priority 1 Tickets opened per quarter (see above - should be as low as possible)
- Everything you do, you should open a ticket for. Upgrading that linux box? Ticket it. Updating anti-virus definitions? ticket it. From this you will get:
- Nunber of tickets open per day
- Nunber of proactive vs. reactive tickets (tickets you opened vs. someone else opened. You should get credit for fixing things before they become an issue someone notices.
And if the bean counter needs some big numbers to justify things, just count up stuff that the logs on public boxes find. Seriously - have you ever looked at the stuff from logwatch? Just yesterday I had 2163 unique failed attempts to log in as root, not to mention all of the other assorted hackery it catches. "Number of successfully defended intrusion attempts" is a metric that will scare a bean counter enough that he won't take the liability of getting rid of you.
In the U.S., the new Dr. Who is on both SciFi and BBC America.
In America, what the british call a 'series' we call a 'season'. So, to our ears, this is an announcement that yes, there will be a 4th season.
The first season is curently being played on BBC America (last time I checked). The second season, with Tennant, is airing on the Sci Fi Channel. The third season should be airing in England - almost immediately, if it isn't already.
I think the poster's original point is that it is not enough that there is prior art - these things shouldn't get to the point where prior art defense is necessary. We know the system is broken because a patent like this should never have been granted, while someone who is part of the system could say, "you see? the system worked! People Identified prior art and shot down the patent".
Prior art is a defense if they try to enforce the patent on you. They never should have been given the ability to enforce the patent in the first place.
Just to be clear, for people who might read this and have no idea what all this linked-list business is about, this ia a data structure that is taught in every 200-level com sci "algorithms and data structures" class, and is so ubituitous that it would certainly be on any exam based on that material. Put in terms in another domain, this would be like patenting "the use of horse hair for the application of water, oil, or acrylic-based substances in an effort to produce a visually aesthetic experience" - that is, a paint brush. Linked lists are in the basic toolset that software engineers use every day. If you are reading this post electronically, then there are probably hundreds of them swirling around inside your computers memory at this very second.
Slashdot polls are normally pretty useless, especially given the bias of the community - but this is one place it could work on our favor! How about doing the following poll:
I would consider buying a Dell PC if it came installed with: [ ] Red Hat Enterprise Linux [ ] Latest Fedora Core [ ] Ubuntu [ ] (2-3 other popular choices) [ ] I don't care, as long as it runs on a stock 2.6.x kernel and comes with
a disk of all the hardware drivers [ ] I wouldn't buy a Dell PC if it came free in a box of fruit loops.
I don't know if Dell would listen, but this would probably be worth as much as any information they get from market-droids.
Slashdot Mirror
Georgetown University Hospital in Washington DC has had several models of these going back years. They do radio ads for using it for prostate cancer.
http://www.georgetownuniversityhospital.org/body.cfm?id=451
I'm sorry, but if you think this is a straightforward task, you are making the same mistake Diebold did. Programming is just one minor part of the whole system they need to implement.
right here
http://www.youtube.com/watch?v=t-L-0s-7-Z0&NR=1
Amazon S3. dirt cheap, there forever.
When you find yourself in a ditch, the first thing you should do is stop digging.
Last night we did. It will take some time to fill in the ditch.
Calculating this with any accuracy would require knowledge of both the width of a Stegasaur (which can be approximated from their fossils), but also how fast they ran. Given other arguments about the unknowns of dinosaurs, the figures we can guesstimate for their speed are just to varied to calculate this capacity to any meaningful value.
I'm sure this will be said to death by the time this post closes for comments, and while this analysis might have merit when done from the viewpoint of someone 'valuing their own labor', the same way donations to charity dry up during hard economic times, that analysis does not apply for several reasons:
1) Something that has been open sourced is perpetually in the open source marketplace. Often called the 'viral nature of the GPL', an economic downturn cannot take away, say, MySQL or JBoss. Both are here, and are here to stay. His argument could be taken to mean innovation may stop temporarily, and I'd entertain that notion.
2) Companies seeking ways to control their costs will EMBRACE open source, so its use will INCREASE. If a CEO is facing a choice between his cushy salary or a license for WebLogic or Oracle, He will choose his salary and tell his IT department to find alternatives. they will, n JBoss and MySql.
3) Training budgets will shrink. So if you can learn everything you need to know to write Rails apps from sources like http://www.railscasts.com/ you are going to build your next app in Rails, as opposed to ColdFusion (and if you have never heard of Cold Fusion, that proves my point - PHP and Java pretty much killed it during the dot-bomb ays).
4) Tech jobs will dry up - and the cream of the crop will need to distinguish themselves. I have heard Dave Thomas (PragDave) say on several occasions that our industry would be better off if we fired the bottom half of developers. This economic downturn may see that happen, and the top half will need to distinguish themselves. the currency of this kingdom is knowledge, and the way we demonstrate this knowledge is by sharing it with others... So I expect to see an INCREASE in blogs, contributions to open source as resume building, etc.
I could go on and on - for instance, people seeking free training will go to more user group meetings... people seeking to network for job opportunities will go to more user group meetings - people seeking to distinguish themselves will want to PRESENT at said user group meetings.
As I said in a post a few months ago, I am seeing an INCREASE in the aount of work I'm doing... why? I develop and I train on open source technologies and agile development methodologies... it is all about doing more with less.
Don't just survive - THRIVE during this downturn. I'll see the best of you on the other side of this downturn, still here reading slashdot, still climbing the skills mountain.
Yes, my company has done this for a client and we are about to do it for one more. We have 3 servers hosted at 'traditional' hosing providers (one at Rimu Hosting, the other at ServerBeach), and during peak load, we fire up Amazon EC2 instances and throw traffic towards them. The 'real hardware' servers can handle normal traffic and redundancy (any one can fail), we just use the cloud for handling peak traffic. We also use the cloud for creating a multiple machine staging environment for testing. We can fire that up, deploy to test, and have the client check out all the new features, and it only costs us a dollar or two.
As cost effective as short bursts are, if they stay up for any amount of time, they cease to be cost effective. I never understand why people think EC2 is so cost effective when, at 10 cents an hour, you will pay $72/month... When you can get a virtual machine that is as performant from a company like Rimu for ~$30-40, or a dedicated resource for something like $90.
-db
Just once, I'd like to see a report on the LHC that didn't call the Higgs Boson the "God Particle", and didn't talk about crackpot fears of mini black holes. I mean, we don't follow every report from the Mars polar lander or rovers about the "Canals of Mars were once thought to carry water", do we?
First, a disclaimer - My consulting company specializes in consulting on this topic, so you might consider me biased. On the other hand, I started this company because I had the experience, and saw the need.
Second, so this won't seem like a commercial, let me say I'm not answering this for any consulting opportunity... I answer slashdot questions all the time without looking for monetary gain; I'm just speaking from experience here.
There are a ton of great references for working together as a team - Any or the books from the Extreme Programming Explained series, a book on Scrum, Bob Martin's book on Agile Project Management, a dramatic reading of 'The Pragmatic Programmer', the book 'Practices of an Agile Developer' (in which several of my stories are published), or the book 'The Productive Programmer', recently published by OReilly (for which I wrote the forward), etc. But reading a book and putting it into practice are very different things. I strongly believe that teams should have mentors. (Thus the name of my company, CodeSherpas - as in we are guides to the terrain, but again, not a plug, just a reference for the kind of thing you need).
You have a fantastic opportunity here - to create a team culture where there are values like continual education, the team not afraid to learn from mistakes, peer reviews and retrospectives, iterative development, proper estimation techniques, and so on. Don't squander it. Find a good book that talks about the 'way things should be' - there are probably a zillion references here on slashdot already, but once you have that, make sure you get someone who has done it before... Even if it is just for a week of consulting/training, and then an occasional 'tune up'. And don't get a talking head... you want "visiting professor", not "ivory tower". A little bit of experience brought into your team now will mean that by this time next year, a group of ~3 awesome people who really know how to work as a team could be out-performing a team of ~7 people who just 'get it' enough to 'get by'.
-db
Key points:
There is no 'one size fits all'. It depends on the language, the corporate culture, and even the kind of app you might be writing.
A coding standard is necessary for teams of any reasonable size - even though people will complain about them, chances are if the team is that large, the code will be maintained for 'generations' of developers. You need to optimize for the poor sod a year from now who has to understand what this code is doing, not optimize for the guy today who wants to be clever.
The coding standard should not be externally imposed by an organization that doesn't have to live with the decisions.
The coding standard should evolve over time. Languages change - for example most coding standards I've seen for Java don't say 'boo' about the syntax changes introduced with generics or annotations.
Here's how you achieve that:
1) Start with a blank whiteboard
2) get the team that will be writing the code together
3) list everything you agree upon, get that out of the way
4) list stuff you *mostly* agree on, and get dissenters on board, even if only for a 'trial' period.
5) Every few weeks (perhaps corresponding with your retrospective at the end of an iteration), review what is working, what isn't and make changes.
This way, the standards will evolve with the needs of the team, and people who dissent only have a few weeks before they get to try to sway people again, and learn to give up if the idea doesn't take hold.
Respect people's pain when making these decisions. You might have strong opinions that conflict with someone else on your team - in the long run, it doesn't matter who is 'right', but the poor guy who is constantly trying to pull fixes up into a release branch might really be pissed off when the 'brace placement churn' causes him issues. He might not care *where* they are, just that they don't change every week.
Issues that there are no good answers to:
1) When you change your coding conventions, what heppens to all the code that follows the older conventions?
2) If you are doing a lot with branching and merging in a version control tool, churning of the coding standard can create 'false diffs'. You'll want to minimize these while evolving the standard.
So, don't try to come up with the perfect coding convention document, try to come up with the perfect mechanism by which your team can develop and evolve the conventions they need.
I had a uch longer post but I wasn't logged in - when I logged in, slashdot ate my homework. so, shorter and more to the point this time:
1) the most important feature set a language can offer, and the most important thing that separates intermediate from awesome programmers is proper packaging of concepts in code. I don't mean packaging for the language, or for the IDE... I mean for the human to solve a problem at one level of abstrction, maintain it at that level, and use it at another level of abstraction without thinking about it too much. Java got this mostly right with packages (and the little used package-level access modifier), and is one of the reasons I still like Java so much. This is also one of the reasons Ruby is such a nice language - I can bundle abstractions up in declarative statements that start to look like keywords in the language - think of the way Rails does things like "belongs_to" and "validates_presence_of". I was on the JSR for the upcoming Java Module System, so this is something I have thought about.
2) regardless of the process methodology, configuration management is something that has to be disciplined for real software development. I don't just mean version control - I mean requirements management (work backlog), version control, branching, merging, repeatable builds, continuous integration, defect tracking, deploys, backup and restore, reconstitution plan, and a bunch of other things that about to project-wide afety nets and 'undo' operations. Rather than try to build the perfect softare, we (very zen-like) embrace the fact that we can't write perfect software and plan accordingly. This makes the software better.
If you want to get some real thought provoking converation about this, I would suggest that you find the nearest NFJS conference to you (www.nofluffjuststuff.com), and hang out with the speakers some saturday night as we drink scotch in a hotel bar and discuss this kind of stuff until we annoy everyone else out of the area.
-db
Agreed. My first ideal solution (for bookmarks, anyway) would be a plugin that let me use my browser's bookmark manus, shortcuts, etc. but just stored them at del.icio.us.
My second ideal solution would be something like google browser sync that let me provide the path and credentials for something like an svn repository, and stored and synced from there. That way, I wouldn't be relying on some unknown server to keep things like passwords and cookies secure.
In a manager's office at Google -
Employee: "You know boss, we really should devote some time to updating the Browser Sync tool to work with Firefox 3..."
Manager: "I have been meaning to talk to you about that... You see, we have been thinking about it, and there really isn't a way to make ad revenue from that tool. While it is cool and useful and all, I don't think people would be happy with ad links showing up randomly in their bookmark menus."
Employee: "Um, yeah... I agree with that. I didn't reslize..."
Manager: "The ad revenue thing? Yeah... well something has to pay for that 20% self-directed time since ad revenues are down. The good news is we think that the Google Toolbar can replace it, and we have a plan for monetizing that."
Employee: "Well, can I work on the FF3 upgrade in my 20% self-directed time and open source the tool?"
Manager: "We thought about that too - first, the Google Toolbar doesn't need the competition. Second, we can't release the code in the shape its in... people would throw our 'do no evil' slogan back at us and slashdot would be all a-titter. It would take as much to clean it up as it would just to get it to work with FF3, so we think it is at its end-of-life."
Employee: "um... o..k... thanks."
Yes, static analysis, especially with some of the open source tools available in the Java space, can be awesome. Check out PMD and FindBugs for two awesome examples of this. Both are free, and do everything you could ever want. If you are willing to pay money for a tool like this though, you are focusing on the wrong things.
No, these tools won't catch entire categories of bugs that can only crop up while your application is running. For those, use unit tests, profilers, etc. For an explanation beyond code for this, check out the book "Godel Escher Bach, an Eternal Golden Braid", specifically the discussion about recording records that when played, destroy the record player playing them. No, its not real, its a thought experiment.
It might be 'your database', but it sounds like it the 'their data'. Give it to them. Whats wrong with read-only access? My guess is it boils down to fear of:
a) working yourself out of a job. Why would they need you as the bitkeeper if they can write their own queries.
or
b) someone who knows better might tell you why your schema sucks.
In either csse, sharing the data might be a hard thing to do, but is in your long-term best interests... do you want to be maintaining reports forever? If you are designing a lousy database, wouldn't you want the education to do it right?
Skeptical? Sure... they should be. But shouldn't they be able to answer a question like this definitively one way or the other?
Elections need to be auditable.
Chances are most of those buttons are there because some Marketing/Sales wonk decided it had to be there, not some engineer. Chances are, the engineers had some other way to do it, but everyone thought it was too "complicated for normal people... give them a button to do it instead".
I'm quite certain that is how "email" and "web" buttons appeared on keyboards... some marketer said "I want the box to say this is an INTERNET keyboard!"
I mean, have you ever really looked at the mechanics of a vintage MG?
I just downloaded the fonts, and installed them on my mac, where I am now using consolas to write a rails application that will be bundled as a WAR file and deployed in a Java application server.
That isn't against any terms of service for a font from Microsoft, is it?
The metric should be 'number of times the sysadmin has to be consulted', and it should be driven as close to zero as possible.
I might get moded 'funny', or 'flamebait', but I'm serious.
Think about it. When is a sysadmin needed? When there is some kind of crisis. "I can't get to the internet", "I can't check m email", "My computer thinks I might have won a million dollars", "I lost that important project file". A good sysadmin will prevent these things from ever happening, and when they do happen will have them resolved quickly, without a lot of technobabble or attitude (like the SNL skit guy), and will fade into the woodwork. Ironically, the middle-of-the-road IT guys are often thought of as heroes by the staff they support. They might be thought of as the firefighters, but unfortunately, they are also often the pyromaniacs.
Other useful metrics:
If you don't already have a ticket support system, get one. It will generate useful metrics for you. Some useful things out of it would be:
- The AGE of the OLDEST OPEN SUPPORT TICKET. Proves you aren't dilly-dallying
- Number of Priority 1 Tickets opened per quarter (see above - should be as low as possible)
- Everything you do, you should open a ticket for. Upgrading that linux box? Ticket it. Updating anti-virus definitions? ticket it. From this you will get:
- Nunber of tickets open per day
- Nunber of proactive vs. reactive tickets (tickets you opened vs. someone else opened. You should get credit for fixing things before they become an issue someone notices.
And if the bean counter needs some big numbers to justify things, just count up stuff that the logs on public boxes find. Seriously - have you ever looked at the stuff from logwatch? Just yesterday I had 2163 unique failed attempts to log in as root, not to mention all of the other assorted hackery it catches. "Number of successfully defended intrusion attempts" is a metric that will scare a bean counter enough that he won't take the liability of getting rid of you.
In the U.S., the new Dr. Who is on both SciFi and BBC America.
In America, what the british call a 'series' we call a 'season'. So, to our ears, this is an announcement that yes, there will be a 4th season.
The first season is curently being played on BBC America (last time I checked).
The second season, with Tennant, is airing on the Sci Fi Channel.
The third season should be airing in England - almost immediately, if it isn't already.
I think the poster's original point is that it is not enough that there is prior art - these things shouldn't get to the point where prior art defense is necessary. We know the system is broken because a patent like this should never have been granted, while someone who is part of the system could say, "you see? the system worked! People Identified prior art and shot down the patent".
Prior art is a defense if they try to enforce the patent on you. They never should have been given the ability to enforce the patent in the first place.
Just to be clear, for people who might read this and have no idea what all this linked-list business is about, this ia a data structure that is taught in every 200-level com sci "algorithms and data structures" class, and is so ubituitous that it would certainly be on any exam based on that material. Put in terms in another domain, this would be like patenting "the use of horse hair for the application of water, oil, or acrylic-based substances in an effort to produce a visually aesthetic experience" - that is, a paint brush. Linked lists are in the basic toolset that software engineers use every day. If you are reading this post electronically, then there are probably hundreds of them swirling around inside your computers memory at this very second.
Child mummy had an egyptian mom? That's news?
Slashdot polls are normally pretty useless, especially given the bias of the community - but this is one place it could work on our favor! How about doing the following poll:
I would consider buying a Dell PC if it came installed with:
[ ] Red Hat Enterprise Linux
[ ] Latest Fedora Core
[ ] Ubuntu
[ ] (2-3 other popular choices)
[ ] I don't care, as long as it runs on a stock 2.6.x kernel and comes with
a disk of all the hardware drivers
[ ] I wouldn't buy a Dell PC if it came free in a box of fruit loops.
I don't know if Dell would listen, but this would probably be worth as much as any information they get from market-droids.