I just threw an image with a solid black background at it, so it should have been relatively simple for the program to extract the image.
Terrible result. This site is doing the job all that well.
At the time the bridge was built, I suspect that the factor of safety used in the design was likely 2x (200%), so having a reduction of 20% of load carrying capacity would not have raised any alarm bells as the bridge would not have been anywhere near its design limits.
Obviously either the original factor of safety was calculated incorrectly or the the examination underestimated the weakening of the bridge due to corrosion. The bad weather and lightening strike could have also been a factor in its collapse.
Let's wait until the cause of failure is determined by a thorough failure analysis, rather than making statements that have no technical backup.
First of all, I have an issue in using the concept of "professional programmer". Sorry, there is no such thing. A profession has strict entry and eligibility requirements; usually a university degree in an appropriate subject, certification by an independent licensing body (that usually have a formal written exam process as a condition of getting a licence, a formal period of intership before a a full license is granted, a formal code of conducts that covers legal and ethical concerns) as well as the suspension or loss of designation / license if the person's conduct does not meet the standards set down by the profession. Nowhere do I see programmers go through this type of process that doctors, lawyers, accountants, engineers, architects, etc. do. Perhaps programmers should fall under this type of regime, given how poor code can cause injury, death or financial losses as much as a botched operation or the collapse of a building, but as this is not currently the case, the thought is purely academic..
Having gotten that off my chest, I suspect you are referring more to the is more the demeanor of how the programmers conduct themselves with peers, superiors and clients (i.e. interpersonal skills) as well as how they write, document code, test and migrate the code according to the organization's standards. What you are trying to do is a good start, but part of the reasons that the professions have an internship arrangement is so that the newcomers end up working under experienced working professionals to develop this skill set. This takes a number of years and depending on the profession, this internship usually lasts for at least two years. I sometimes have seen this happen in the programming world, especially in larger organizations, but smaller shops with just a few programmers working there seem to fail miserably here.
Until the programming industry wakes up and starts following the best practices seen in the professions, I think you are not going to see the success you hope to. I've worked with programmers who were very professional, but unfortunately for each one of those, I was subjected to working with "cowboys" who were extremely difficult to manage.
The moment the word "nuclear" is mentioned people go crazy. This is fusion where tritium pellets are bombarded with lasers to fuse into helium. The concept works in the lab, but the the amount of energy generated is pretty low when compared to the energy required to drive the lasers. It is NOT fission, the process used in current nuclear power plants where uranium or plutonium is split into radioactive particles with long half lives.
Chances are pretty good that this patent will expire well before the process becomes viable (if this ever occurs).
Yawn!
I find it amusing that this argument is still continuing (and will likely continue to occur).
I graduated in mechanical engineering almost 35 year ago. On top of the usual heavy engineering workload; requirements to graduate included two full credit (two-semester courses) in the humanities. I also had to have a full credit course in either biology or geology, a one semester course in business, a one credit course in communications (mostly technical writing) as well as some intermediate to advanced (second, third and fourth year) courses in taught by other faculties in the Engineering Department; three one-semester electrical engineering courses, one civil engineering course and one metallurgy / materials science course. This was of course on top of the regular core and elective mechanical engineering courses. After graduation, I had to pass a course in law and one in ethics to get my professional engineering licence, on top of meeting all of the other technical requirements. Frankly, the business and communications courses have been more important in my career than a number of the pure engineering courses.
My daughter graduated with an arts degree last year; she went this route because she was not particularly good at maths and sciences. She needed two science credits to graduate (full year courses). She founds these tough, but admits that she has a much more rounded view of the world because of it. We graduated from two different universities; they are consistently ranked as the top two or three in the country. Perhaps these schools are onto something
I’ve been working as an engineering manager for over 30 years, and have at various times in my career been involved in college recruitment, hiring, training and mentoring of engineering grads. The one predominant trend that I have noticed is that the young engineers that had a broader, more diversified education (i.e. beyond the purely technical courses) tended to be better engineers; they were generally more successful; they were better at solving problems, meeting their deliverables and meeting deadlines. They also tended to have more successful career paths. The people that were more the “pure techies” tended to get stuck on minutia and had trouble seeing how their work fit into the “big picture”. Corporately, we tended to hire what we saw as more well-rounded individuals.
So, stop whining and get a broader education. You may not realize it now, but it will actually work to your advantage over your career.
I'm sorry to disagree with your premise, but having delivered a number of large projects, having a good solid project team increases the likelihood of success, Running something complex on your own is more likely to have the opposite result. That being said, a poor project management team can sink a project quickly to, but if you work for a large technology company, chances are they know how to deliver successful projects.
It seems to me that your real issue is that you are afraid of losing ownership and control of your project, rather than anything else. It sounds like your key skills are technical and not necessarily related to managing a project, so as an outsider looking in, I could see you in a key role on the development team, but it doesn't sound like you necessarily have the skill set to do this on your own. Budgets, schedules, resource management, coding, test plans, user and code documentation, change management, training, standards compliance, etc., etc. all require expertise that you likely don't have. Someone has to lock down the scope and keep the team on track. I personally don't have a problem with the MBA types; like any other group, there are some good ones out there that will add value and others that you likely would not want on the team....
If the project is delivered on time and on budget, everyone wins. If it is not, the company has wasted valuable resources; I would not want to be on a team that did not deliver the project, regardless of who was on the team or running it. Be realistic about your own skills and abilities; are you really the best person to run this project?
Slashdot Mirror
I just threw an image with a solid black background at it, so it should have been relatively simple for the program to extract the image. Terrible result. This site is doing the job all that well.
At the time the bridge was built, I suspect that the factor of safety used in the design was likely 2x (200%), so having a reduction of 20% of load carrying capacity would not have raised any alarm bells as the bridge would not have been anywhere near its design limits. Obviously either the original factor of safety was calculated incorrectly or the the examination underestimated the weakening of the bridge due to corrosion. The bad weather and lightening strike could have also been a factor in its collapse. Let's wait until the cause of failure is determined by a thorough failure analysis, rather than making statements that have no technical backup.
First of all, I have an issue in using the concept of "professional programmer". Sorry, there is no such thing. A profession has strict entry and eligibility requirements; usually a university degree in an appropriate subject, certification by an independent licensing body (that usually have a formal written exam process as a condition of getting a licence, a formal period of intership before a a full license is granted, a formal code of conducts that covers legal and ethical concerns) as well as the suspension or loss of designation / license if the person's conduct does not meet the standards set down by the profession. Nowhere do I see programmers go through this type of process that doctors, lawyers, accountants, engineers, architects, etc. do. Perhaps programmers should fall under this type of regime, given how poor code can cause injury, death or financial losses as much as a botched operation or the collapse of a building, but as this is not currently the case, the thought is purely academic.. Having gotten that off my chest, I suspect you are referring more to the is more the demeanor of how the programmers conduct themselves with peers, superiors and clients (i.e. interpersonal skills) as well as how they write, document code, test and migrate the code according to the organization's standards. What you are trying to do is a good start, but part of the reasons that the professions have an internship arrangement is so that the newcomers end up working under experienced working professionals to develop this skill set. This takes a number of years and depending on the profession, this internship usually lasts for at least two years. I sometimes have seen this happen in the programming world, especially in larger organizations, but smaller shops with just a few programmers working there seem to fail miserably here. Until the programming industry wakes up and starts following the best practices seen in the professions, I think you are not going to see the success you hope to. I've worked with programmers who were very professional, but unfortunately for each one of those, I was subjected to working with "cowboys" who were extremely difficult to manage.
The moment the word "nuclear" is mentioned people go crazy. This is fusion where tritium pellets are bombarded with lasers to fuse into helium. The concept works in the lab, but the the amount of energy generated is pretty low when compared to the energy required to drive the lasers. It is NOT fission, the process used in current nuclear power plants where uranium or plutonium is split into radioactive particles with long half lives. Chances are pretty good that this patent will expire well before the process becomes viable (if this ever occurs). Yawn!
I find it amusing that this argument is still continuing (and will likely continue to occur). I graduated in mechanical engineering almost 35 year ago. On top of the usual heavy engineering workload; requirements to graduate included two full credit (two-semester courses) in the humanities. I also had to have a full credit course in either biology or geology, a one semester course in business, a one credit course in communications (mostly technical writing) as well as some intermediate to advanced (second, third and fourth year) courses in taught by other faculties in the Engineering Department; three one-semester electrical engineering courses, one civil engineering course and one metallurgy / materials science course. This was of course on top of the regular core and elective mechanical engineering courses. After graduation, I had to pass a course in law and one in ethics to get my professional engineering licence, on top of meeting all of the other technical requirements. Frankly, the business and communications courses have been more important in my career than a number of the pure engineering courses. My daughter graduated with an arts degree last year; she went this route because she was not particularly good at maths and sciences. She needed two science credits to graduate (full year courses). She founds these tough, but admits that she has a much more rounded view of the world because of it. We graduated from two different universities; they are consistently ranked as the top two or three in the country. Perhaps these schools are onto something I’ve been working as an engineering manager for over 30 years, and have at various times in my career been involved in college recruitment, hiring, training and mentoring of engineering grads. The one predominant trend that I have noticed is that the young engineers that had a broader, more diversified education (i.e. beyond the purely technical courses) tended to be better engineers; they were generally more successful; they were better at solving problems, meeting their deliverables and meeting deadlines. They also tended to have more successful career paths. The people that were more the “pure techies” tended to get stuck on minutia and had trouble seeing how their work fit into the “big picture”. Corporately, we tended to hire what we saw as more well-rounded individuals. So, stop whining and get a broader education. You may not realize it now, but it will actually work to your advantage over your career.
I'm sorry to disagree with your premise, but having delivered a number of large projects, having a good solid project team increases the likelihood of success, Running something complex on your own is more likely to have the opposite result. That being said, a poor project management team can sink a project quickly to, but if you work for a large technology company, chances are they know how to deliver successful projects. It seems to me that your real issue is that you are afraid of losing ownership and control of your project, rather than anything else. It sounds like your key skills are technical and not necessarily related to managing a project, so as an outsider looking in, I could see you in a key role on the development team, but it doesn't sound like you necessarily have the skill set to do this on your own. Budgets, schedules, resource management, coding, test plans, user and code documentation, change management, training, standards compliance, etc., etc. all require expertise that you likely don't have. Someone has to lock down the scope and keep the team on track. I personally don't have a problem with the MBA types; like any other group, there are some good ones out there that will add value and others that you likely would not want on the team.... If the project is delivered on time and on budget, everyone wins. If it is not, the company has wasted valuable resources; I would not want to be on a team that did not deliver the project, regardless of who was on the team or running it. Be realistic about your own skills and abilities; are you really the best person to run this project?