It sounds pretty cool but I would like to see a tool that deals with email, documents, and other stuff as well as web pages. Perhaps something along the lines of Omea
You assume that scoring a game state is easy in go. It isn't and it remains the reason why go playing computer programmes still cannot defeat even relatively weak amateurs (at least not the last time I checked, which was a few years ago). Try learning the rules and reading a few books on "life and death" problems and you'll see what I mean.
I have a fair degree of familiarity with this issue and have some comments on the blog entry.
Limit access to customer records.
There's almost zero chance the phishers knew the author had an account at his bank. They use spamming techniques and count on getting lucky.
Financial Institutions could automate the process of identifying where their logos and site images are used as a standard practice of trademark enforcement.
Some financial institutions already do this but it is very expensive. Despite the dire headlines, current levels of fraud are not high enough to justify the cost in many (or most) cases. This is also why financial institutions in North America do not use two-factor authentication such as token cards. I've seen some clever ideas for cheap two-factor auth. that might work out.
FIs, and other organizations, should pressure ISPs (AOL and Comcast especially) that deliver email on their networks to mark these emails as fraudulent.
I think it would be more effective if consumers put pressure on browser and email client software suppliers to fix the security holes in their applications.
highly sophisticated phishing sites would require that the phisher have a banking account
I find it very doubtful that phishers would ever have an account at the instituion whose clients they are attempting to defraud. First, there is no need to get access to authenticated pages to create a "highly sophisticated phishing site". Second, the act of opening an account requires providing proof of identity and would create evidence that could lead to finding the real identity of the phisher.
Banks should actually follow-up on reported phishing attacks.
This is bang on. Not following up on the author's email is a pretty big mistake.
If I wanted to hack around, I might use Lisp, Ruby or Prolog(!) but if I want to develop a complex application with a large team, I think Java strikes a nice balance between expressiveness and "safety".
Canadian and US banks are far behind Europe in terms of online banking security. However, that is not necessarily a mistake. When you look at these news items, you think it's terrible but the amount of fraud that has been perpretated up to this point has been way less than the amount it would cost to introduce one-time passwords or other "two factor" schemes. Also, even if someone steals your account id and password, they may not be able to do anything except transfer money between your accounts or pay your bills. If you're banking at a credit union, it will be hard for the fraudster to get the money out of the cash box under the general manager's desk.;-)
Indeed. We develop server-side code on Windows (2k and XP), and deploy on Linux, Windows, and Solaris. With three major products representing millions of lines of code developed over a period of approximately 6 years, we have never had a single instance of platform incompatibility.
Writing a rebuttal is nice, but like retractions in newspapers, they are not all that effective in undoing the impression created by the original report. Aren't there any studies out there showing Linux is cheaper? Relying on "Linux is free" is no longer sufficient.
IBM's 1.3.1 JDK for Linux had noticably better performance than the Sun JDK in certain areas. There is an extensive performance report posted on www.javalobby.org. I think you have to register (free) to access the report.
The browser is excellent. At work, I use both IE and Mozilla (mainly because Windows launches IE when I click on a URL link in Outlook and I haven't been able to find out how to change that). Mozilla does a better job rendering complex pages. Take a page with a big table that uses CSS to control the layout. Mozilla is able to display the table progressively (i.e. display the rows as the data arrives at the browser) while IE seems to need to wait for the entire table to arrive. IE also crashes trying to print out that page if the table is big enough to take more than 2 or 3 paper pages.
Mozilla also has tabbed browsing, a popup blocker, etc. etc. The only area I have noticed where Mozilla still lags is in some DHTML (JavaScript/DOM) stuff. For example, pages that implement animation using DHTML can be much slower than IE.
The Mozilla Mail/News client, on the other hand, has not been so successful, in my opinion. For example, the last time I tried to use it, it would do strange things when I tried to insert blank lines between quoted lines in a reply.
Which earliest version of IE? IE on Win 95, Win 98, Win Me, Win NT, Win 2000, Win XP or IE on the Mac? All of these platforms represent significant portions of my company's client base.
But a competent web developer can create a site with pretty graphics and groovie flash movies that is still accessible to people with disabilities (who have to use alternate browsers). They may not get the full benefits of your site, but they won't feel completely shut out.
Clearly SOAP itself does not provide application level security, but I personally do not see that as a "SOAP security problem".
Why is the lack of security in SOAP not a SOAP security problem? Are you saying that security is outside SOAP's scope? That doesn't sound right to me. Surely security should be one of the prime concerns of any protocol.
That would be a very badly run department indeed. However, I am almost inclined to agree that 4 to 6 "super coders" can *outcode* a sloppy 400 person programming department filled with IT college rejects. The problem is that for an application as complex as an office suite, you need a whole bunch of people to do things like documentation, QA, build management, project management, etc.
Studying management techniques will not make you a good manager. At the same time, it is not necessary to have a formal education in management to be a good manager. In fact, I think reading a book like "Management for Dummies" is about all you need as far as "management theory" goes.
Managing is about people skills first. It is also critical to have a good understanding of the nature of the work that the people you are managing do. Throw in a dash of intelligence and some organizational skills and you have a great manager.
Outperforming apache isn't much of a feat. If your JVM segfaults, your whole webserver is dead. If an apache process segfaults, only one connection is affected.
I don't think your point is entirely valid. You can easily set up a load balancing system with multiple JVMs on one or more CPUs, and I think such a system would still be faster than Apache 1.3 (but maybe not 2.0). However, the Java server would undoubtedly require a lot more RAM to handle the same load.
The comment from Eve about Buck failing to motivate the team to work more than 40 hours a week hits a sore spot.
At my company, we take pride in something called "work/life balance". This means that people have a life outside the job. We don't want people spending their lives in front of a cathode ray tube or sleeping under their desks. A company that expects overtime is a company that will destroy its employees.
This rant, though I'm sure it's full of truth, does manage to excuse the founders of responsibility.
Go back and read what he wrote. The entire post is about how the founders screwed up by trying to "make a substantial impact on the world" without adequate preparation. Scalability has a meaning outside the techno-nerd realm. ArsDigita was not scalable.
* being forced to use lesser software products and tools due to cost or partnership arrangements;
If it's really bad and not just a matter of taste, you should be able to make a convincing business case against using the inferior product. If it turns out that the cost of using the "superior product" exceeds the cost of working within the limitations of the "inferior product", you don't really have a leg to stand on.
* having time-to-market be a larger issue than software reuse
A good architect will inevitably deliver re-usable components (which may require some refactoring if rushed). An inexperienced one will have a hard time no matter what.
* attempting design and development when the skill set is diverse
You just need a few people with the knowledge/experience and a smart crew who can learn.
Methodology is good but is not a panacea for the basic scheduling problem. In essence, a development team cannot accurately predict the amount of time to design and implement something unless they have experience designing and implementing something quite similar.
It sounds pretty cool but I would like to see a tool that deals with email, documents, and other stuff as well as web pages. Perhaps something along the lines of Omea
You assume that scoring a game state is easy in go. It isn't and it remains the reason why go playing computer programmes still cannot defeat even relatively weak amateurs (at least not the last time I checked, which was a few years ago). Try learning the rules and reading a few books on "life and death" problems and you'll see what I mean.
There's almost zero chance the phishers knew the author had an account at his bank. They use spamming techniques and count on getting lucky.
Some financial institutions already do this but it is very expensive. Despite the dire headlines, current levels of fraud are not high enough to justify the cost in many (or most) cases. This is also why financial institutions in North America do not use two-factor authentication such as token cards. I've seen some clever ideas for cheap two-factor auth. that might work out.
I think it would be more effective if consumers put pressure on browser and email client software suppliers to fix the security holes in their applications.
I find it very doubtful that phishers would ever have an account at the instituion whose clients they are attempting to defraud. First, there is no need to get access to authenticated pages to create a "highly sophisticated phishing site". Second, the act of opening an account requires providing proof of identity and would create evidence that could lead to finding the real identity of the phisher.
This is bang on. Not following up on the author's email is a pretty big mistake.
Remember the "Paul is dead" rumour back when the Beatles released Abbey Road?
I predict the nonsense about Java being dead will have about the same ending.
Since the Beatles outclass the Beach Boys, my prediction wins.
If I wanted to hack around, I might use Lisp, Ruby or Prolog(!) but if I want to develop a complex application with a large team, I think Java strikes a nice balance between expressiveness and "safety".
Canadian and US banks are far behind Europe in terms of online banking security. However, that is not necessarily a mistake. When you look at these news items, you think it's terrible but the amount of fraud that has been perpretated up to this point has been way less than the amount it would cost to introduce one-time passwords or other "two factor" schemes. Also, even if someone steals your account id and password, they may not be able to do anything except transfer money between your accounts or pay your bills. If you're banking at a credit union, it will be hard for the fraudster to get the money out of the cash box under the general manager's desk. ;-)
Indeed. We develop server-side code on Windows (2k and XP), and deploy on Linux, Windows, and Solaris. With three major products representing millions of lines of code developed over a period of approximately 6 years, we have never had a single instance of platform incompatibility.
Writing a rebuttal is nice, but like retractions in newspapers, they are not all that effective in undoing the impression created by the original report. Aren't there any studies out there showing Linux is cheaper? Relying on "Linux is free" is no longer sufficient.
IBM's 1.3.1 JDK for Linux had noticably better performance than the Sun JDK in certain areas. There is an extensive performance report posted on www.javalobby.org. I think you have to register (free) to access the report.
The browser is excellent. At work, I use both IE and Mozilla (mainly because Windows launches IE when I click on a URL link in Outlook and I haven't been able to find out how to change that). Mozilla does a better job rendering complex pages. Take a page with a big table that uses CSS to control the layout. Mozilla is able to display the table progressively (i.e. display the rows as the data arrives at the browser) while IE seems to need to wait for the entire table to arrive. IE also crashes trying to print out that page if the table is big enough to take more than 2 or 3 paper pages.
Mozilla also has tabbed browsing, a popup blocker, etc. etc. The only area I have noticed where Mozilla still lags is in some DHTML (JavaScript/DOM) stuff. For example, pages that implement animation using DHTML can be much slower than IE.
The Mozilla Mail/News client, on the other hand, has not been so successful, in my opinion. For example, the last time I tried to use it, it would do strange things when I tried to insert blank lines between quoted lines in a reply.
I just checked our site stats for 2003 and "Mozilla 5" has rocketed up to 5.7%! ;-)
Which earliest version of IE? IE on Win 95, Win 98, Win Me, Win NT, Win 2000, Win XP or IE on the Mac? All of these platforms represent significant portions of my company's client base.
But a competent web developer can create a site with pretty graphics and groovie flash movies that is still accessible to people with disabilities (who have to use alternate browsers). They may not get the full benefits of your site, but they won't feel completely shut out.
Clearly SOAP itself does not provide application
level security, but I personally do not see that
as a "SOAP security problem".
Why is the lack of security in SOAP not a SOAP security problem? Are you saying that security is outside SOAP's scope? That doesn't sound right to me. Surely security should be one of the prime concerns of any protocol.
That would be a very badly run department indeed. However, I am almost inclined to agree that 4 to 6 "super coders" can *outcode* a sloppy 400 person programming department filled with IT college rejects. The problem is that for an application as complex as an office suite, you need a whole bunch of people to do things like documentation, QA, build management, project management, etc.
Studying management techniques will not make you a good manager. At the same time, it is not necessary to have a formal education in management to be a good manager. In fact, I think reading a book like "Management for Dummies" is about all you need as far as "management theory" goes.
Managing is about people skills first. It is also critical to have a good understanding of the nature of the work that the people you are managing do. Throw in a dash of intelligence and some organizational skills and you have a great manager.
Outperforming apache isn't much of a feat. If your JVM segfaults, your whole webserver is dead. If an apache process segfaults, only one connection is affected.
I don't think your point is entirely valid. You can easily set up a load balancing system with multiple JVMs on one or more CPUs, and I think such a system would still be faster than Apache 1.3 (but maybe not 2.0). However, the Java server would undoubtedly require a lot more RAM to handle the same load.
The comment from Eve about Buck failing to motivate the team to work more than 40 hours a week hits a sore spot.
At my company, we take pride in something called "work/life balance". This means that people have a life outside the job. We don't want people spending their lives in front of a cathode ray tube or sleeping under their desks. A company that expects overtime is a company that will destroy its employees.
This rant, though I'm sure it's full of truth, does manage to excuse the founders of responsibility.
Go back and read what he wrote. The entire post is about how the founders screwed up by trying to "make a substantial impact on the world" without adequate preparation. Scalability has a meaning outside the techno-nerd realm. ArsDigita was not scalable.
If it's really bad and not just a matter of taste, you should be able to make a convincing business case against using the inferior product. If it turns out that the cost of using the "superior product" exceeds the cost of working within the limitations of the "inferior product", you don't really have a leg to stand on.
* having time-to-market be a larger issue than software reuse
A good architect will inevitably deliver re-usable components (which may require some refactoring if rushed). An inexperienced one will have a hard time no matter what.
* attempting design and development when the skill set is diverse
You just need a few people with the knowledge/experience and a smart crew who can learn.
Does your CGI nest work? If so, maybe you should leave it alone.
Hmm, sounds like COBOL.
I'm still waiting to see enterprise scalable software written in Java.
I think Bin Laden said the same thing.
Methodology is good but is not a panacea for the basic scheduling problem. In essence, a development team cannot accurately predict the amount of time to design and implement something unless they have experience designing and implementing something quite similar.