I hate to rake this over the coals, but are you referring to the old ASP, with VBScript and so forth? If so, I absolutely and completely agree that it is awful and not to be touched.
Yeah, I should have clarified - I haven't worked with.Net at all, so can't speak to it. I don't suppose there's a lot of old-style VBScript being done anymore, but that was what I was referring to.
I don't really have a great desire to work with.Net...we're a Linux shop (as far as server stuff goes), so until mono becomes commonly offered by hosting providers, there's not much point for us. The next thing I'll probably pick up is J2EE. I have some small exposure to it, and I like the model. I find that I'm mostly doing PHP these days. Not because I'm crazy about the language (I'm not), but it gets things done, it's everywhere, and I've got a ton of code for doing common things with it.
I'm not a language zealot, but there are certain tools that I like working with more than others, and I have the luxury of being able to choose projects for which those tools are best suited.
Regarding print design, I feel your pain. We did a small project in a similar way once (design was done when we came in, and obviously not by a web designer). The complete lack of consideration for very basic things like variable browser window sizes, accounting for browser chrome, (yes, it was fixed-width, and couldn't be changed), etc. made it take at least twice as long as it should have. Fortunately, we only decided to do this because it was a small project at a slow time. Never again. Ever.
I'm lucky in that our designer is very good. A good designer is a joy to work with.
Can anyone tell me why tables are so bad for layout?
Table layouts are a bitch to maintain. It's much easier to work with good CSS and proper semantic markup. CSS layouts are lighter. Search engines don't like table based layouts as much (all that extra markup pushes your content further down in the actual file). If you want to move page elements around (say putting the menu on the right instead of left), it's much easier to change a couple lines of CSS than sorting out a bunch of nested tables, counting columns, etc. One of the happiest moments of my career was when we decided we could start moving away from table layouts.
...the potential to make asshorrible ANYTHING is there if you aren't very skilled with what you're trying to do. It all comes down to the skill of the designer.
Generally, I agree. Especially on the table layout bit. There's no reason to be doing that in this day and age, unless you've got some seriously ancient browser requirements. Yes, budget is going to be a major factor in how the site turns out - underfunded web projects fail the same way any underfunded software development project will fail. And I definitely agree that you should let the dev company worry about the things that you're hiring them for. Micromanagement is going to result in a crap project that misses deadlines and is over budget.
I'm not quite sure where you were going with "XHTML1.0 strict is an XML document", though. Of course it is, but that's likely tangential. It's just a fact of life that IE6 screws certain things up, and to get around them, there's a good chance you'll have to bend a corner here or there. Do I like it? No, it pisses me off because it makes my life harder. But as arkanes says above, IE6 is going to be with us for at least the next three years, and we have to deal with it.
Note that I didn't say strict was useless, or that it was never appropriate. Part of good web development is pragmatism. Chose your tools and standards wisely. Don't overburden a project with unnecessary strictures. If you only advocate strict to be strict, then it's the wrong reason. If it's because there's a good business case for it, then by all means, use it.
And of course anyone that builds solely for IE should be shot. Vigilante justice has it's place.
Context: I've been doing web development professionaly for seven years, the last four with my own small web development company. We've worked with other firms, and been called in to clean up other people's work (the latter more often than I'd care for - that kind of work is zero fun).
As many other have pointed out, language doesn't matter a whole lot. We do recommend open source platforms, for the reasons familiar to anyone that reads this site often, but the most important question about this is whether the tool will fit the job. I've told clients before that what they really want is a Microsoft solution (because it fits the requirements) and that they should really find another firm to do it (because I'd rather put a hot poker in my eye than work with ASP).
Portfolio is important, but there are a million ways of fluffing it. Maybe it was subcontracted work, maybe they happened to have a really good person working for them for a few months, and they left because the company sucked. Maybe they're a large company, and their portfolio is all A team work, but you'll be getting the B team. On the other side, we've done work that would never make our portfolio because the client insisted on a nuclear orange and blue color scheme, or 500 links on the main page.
Picking a good web development company is difficult, largely because a) most of them are truly horrible and inexperienced, and b) the important things are difficult to quantify. There's a few things that are immediate warning signs, though. These should be rampantly obvious, but this is Ask Slashdot, and I've encountered each of these from companies that a client thought looked good on paper:
where does the design phase come in? If it's early in the process, run away. You don't know what the design requirements are until you've worked out the site architecture, at the very least. Design usually shouldn't happen until somewhere around halfway through the project. (We don't touch design until the information architecture is done, we've seen any print materials you have, and layout grids are produced)
they tell you that as long as it works in IE, browser requirements don't really matter
can you talk to the project lead? Many companies will have a suprememly non-technical person doing the client liason. While I think this is generally a bad idea, it's the way a lot of companies work. But if you can't talk to the person that's going to be making technical decisions, run away.
print is not the web. There's still this strange idea floating out there that print designers are interchangable with, or even superior to, web designers. The web is a whole different medium, and requires different skill sets. If they try to sell you on their print designers, it's a bad sign. Similarly, they shouldn't be selling their web designers as print designers.
they make any kind of guarantess about search engine optimization. SEO is this week's snake oil. There are common sense things you can do to improve your ranking, but if they're promising top ten rankings, they're blowing smoke.
Some of the things that you should look for (this list keeps growing, I had to stop early):
do they make recommendations? There's usually some aspect of a site that can be improved by a slightly different approach than what's outlined in the RFP
do they provide source files for creatives? You don't want to be asking them to hunt down some graphic two years from now.
ask about process. There isn't necessarily a "right" answer to this, but they should have a design process in place, and be able to explain to you why they do things this way. They should be able to explain this in a way that's understandable to a non-technical user.
ask about usability. Budget is going to be a factor here. It's not necessarily cost-effective to run the site through multiple usability labs, but at the very least they should know about general usability guidelines (keeping content above the fo
I would agree that the pages should validate cleanly, but I wouldn't go so far as to say against strict mode. To get things to work properly cross platform, you may very well need to work with "transitional." This is largely because of problems with IE. This depends a lot on requirements - strict might be appropriate in a given situation. For a general usage, publicly accessible site, I wouldn't shoot higher than transitional. You'll be giving yourself more hurt than it's worth.
Definitely some murky waters here, and I'm glad that Moglen et al are thinking about this kind of thing.
I'm currently working on some PHP libraries that I'm considering LGPLing, but if I develop anything using these, I'd like to distribute the application specific parts under the GPL. Problem is, those would be web services. The whole point of them is to provide services without requiring distribution of the code. I'm not to crazy about the idea of someone being able to build off of it and offer a modified pay service without releasing changes. If someone wanted to hack around with it, or use it internally in an organization, I have no problem with it. But if it would be offered to the world at large, I definitely want the users (and myself) granted the same rights as they would have if it was installed on the desktop. Just because it's running off someone's server shouldn't mean that they could avoid this little issue, but it currently does.
Fortunately, I'm not in that league yet, although I've noted a dramatic increase in the last few months. I'm more in the 300 a week category, but at the rate things are going...Thunderbird is doing a pretty good job nailing spam for me. It's catching around 80% currently, and I haven't had a false positive yet.
One thing you might want to consider for posting email addresses on your site is to encode it with javascript. It's not guaranteed (if a browser can decode it, a harvester can), but it significantly raises the bar. The one downside is that anyone with javascript disabled won't be able to get your address. That's getting more rare.
Here's a link to a handy encoder - just cut and paste the resulting javascript into your web page.
Have you ever registered a domain? Nearly all the spam I get is to an address I only use for registering domains. I'm careful with my primary addresses, and receive nearly nothing on them.
A lot of spam that hits the system you'll never see as well. A big chunk of spam lists have bad or nonexistent addresses in them. There's usually some poor schmuck (here, that's me) that has to check and see if an Important Business Contact just can't type, or if all those emails to betty1@example.com, betty2@example.com, etc. are aimed at insecure men.
Other popular targets for spam are sales@, info@, support@....etc. so unless you're responsible for one of those, that's more spam you won't see.
- Lacked the geek talent and dedication required to pull it off.
Except that he didn't lack it - go read his web page. It explains how he pulled it off, generating the faked images on the fly from a few pre-shot photos and perl.
Personally, I think it's a cool hack. Glad someone out there is still doing this stuff...
I agree that this kind of thing - charging for bug fix releases - is sleazy. But it's not an easy problem (*Disclaimer: I don't think this excuses MS, whom I think are incredibly slimy, or anyone else).
There are two options:
charge a stupid amount of money for a product that's behind the feature curve
charge a (mostly) reasonable amount of money for a rushed product, with all the flaws that implies
The problems with 1) are obvious, from a company-health standpoint. The problem with 2) is that all those bug fixes cost money. Otherwise 1) would be cheap. You have to pay for that quality somehow.
MS have themselves in a bind - they've made their money on getting "good enough" products out, and having shiny features to sell. They've been really pushing the "reasonable price" envelope for a while, but they're still way lower than what a bug free product would cost. Now people are realizing that "good enough", wasn't. Frankly, I think they've been cutting too many corners for too long, and I hope they choke on this.
But for Joe Schmoe software developer, this is much more difficult to balance. How do you pay for bug-fixing while still remaining competitive? Bug fixing is expensive.
Eventually, hopefully, the software market will settle enough that quality and security become major selling points. The market has to reach the point where it's willing to accept fewer shiny things, and where it's open enough to welcome a product that comes out six months later. Until then, we're going to be getting shafted on this.
If anything, they're too good. One of my favorite things about BattleZone was the monochrome vector graphics. Damn, I miss that game.
I love shiny graphics as much as the next guy (UT2004 is a current favorite), but give me a good game over whizzy graphics any day. Hell, I just whacked Morgoth again a couple of weeks ago. Not using any of those silly tiled graphics, either. I look like a '@', as god intended.
Indeed...I've been hearing a lot about how the rest of the world doesn't want another Bush presidency because we want the US to be weak. This couldn't be further from the truth.
I live just north of them, and I can tell you unequivocally that I want a good, stable and healthy America. I do a large part of my business with Americans and it is manifestly in my best interest that they have a strong economy and laws that make them an attractive trading partner. The Patriot Act, the US copyright and patent system (and their insistence that we support it), the current administration's ruinous economic policies all make me very concerned about economic health of the United States. If they continue down their current path, I have no doubt their economy will continue it's downward spiral, and Canada will be swimming right next to that big, sucking whirlpool
It also amazes me how few US citizens seem to understand that the rush to a police state will make this situation worse. Never mind that I hate to see friends of mine living in a country where the people don't seem to see that secret searches, perpetual monitoring of the citizenry and widespread government propaganda are bad things. How can people not realize that just as much as the economic policies of the current administration are weakening the country, their social, trade and law enforcement policies are destroying them?
To my American friends, don't let fear and promises of global dominance take you back to isolationism and unilateral foreign policies. The rest of the world does want to work with you. It's just been getting very hard to do that lately.
I agree it's not a major drawback, but it can be annoying if you have different programmers with different preferences. If one is naming things "getfoo()" and another is "getFoo()", they lack visual similarity, which is important if you're scanning large blocks of code. Also, if you're looking for the occurence of a particular function, you have to remember to do a case-insensitive search which may not be the editor's default. Even if you've got some kind of sane capitalization system that everyone follows, it's easy to accidently type "getfoo()". If capitalization matters, you'll catch these things and keep your code just a little bit cleaner.
More annoying, I find, are inconsistencies in the way built in functions are named, eg "file_get_contents()" versus "readfile()". It's a small thing, but remembering if they decided to break this function with an underscore on words or not is an irritant. It's one of those little things that makes the language feel sort of thrown together, as opposed to perl or python that have a nice, consistent feel.
That said, I use PHP almost exclusively these days, so this isn't a flame against the language. Just something I wish was different.
I'm glad there are still teachers with this attitude out there. Cries of "what practical use is that?" are disheartening. I don't know if it's just that I'm getting older and more cynical, but it seems to be more common. If there isn't an application for a discovery in the next quarter, no one's interested in it.
It's not just the things we may discover that we can't predict that are important, the process of discovery and learning is important. Without the process, we wouldn't have science as we know it. Just a bunch of people running around with alchemy sets and healing crystals.
We need to preserve and pass on the sense of awe and wonder that comes from pursuing knowledge for it's own sake. It teaches us to think, gives us perspective, and allows us to see humanity in a broader context than profits and dominance.
So, from someone who had too many teachers that answered that question with "It will be on the test", thank you.
Ah, that explains the rabid "this is crazy serious" comments. I RTFA, just not TFC. I thought this was just doing the obvious thing, and using javascript to manipulate a browser window that had been opened by the parent. Thanks for the clarification.
Yeah, I'd hardly call this a vulnerability. Maybe a "feature that can be used to trick users." Of course a parent window can modify content in it's child windows. This isn't exactly news. News would be "a child window can modify content in it's parent window", something that's supposed to require a signed script.
You could do something similar without even bothering with frames, by, say, registering 'microssoft.com' and then linking to "http://msdn.microssoft.com/library/default.asp." How many peole will notice the extra 's' in their addressbar? Is that a "vulnerability"?
Sounds like someone wanted to publish a "six year old vulnerability" to hawk their product.
Sounds obvious, but I just wanna point it out before it gets lost in the/. responses... Work *hard* on finding yourself customers, harder than you want to, even...
Funny how often that does get lost in these discussions, even though it seems obvious. Finding customers is now your number one priority. In the beginning, especially, all that time you're saving by not having a day job anymore will go to getting clients (and a bit of other business minutae). Coding the project will still be something you do in your spare time, although you have a bit more control over when that spare time is.
Have an advertising plan, and a budget for same. Word of mouth will almost certainly not bring in business rapidly enough, or in large enough numbers. Don't rely on it.
Also, for consulting gigs, the right kind of clients are important. Learn how to say No. This is really hard at the beginning, but it's maybe most critical then. The wrong client will suck the lifeblood out of you if you let them. (Hell, the right ones can too;) ). Do not overcommit, and if they're asking for too much, tell them. They'll appreciate your honesty. If they don't, their the kind that will be a continual burden on your company,and you can't afford them.
I'd ammend that to most changes have been for good reasons. In my post above, I was thinking specifically of the $HTTP_VARS_ change. Granted, typing $_POST is a heckuva lot nicer, but I really wish more thought had been put into how to handle that. There have also been a number of changes in how individual functions behave between point releases where the only rationale seemed to be that they thought it looked nicer the new way. (It usually did, but don't go doing things like that unless you give people an escape route, at least temporarily).
Perl is an excellent example of how to handle backwards compatibility the right way. 6 is almost a complete language rewrite, but it's still going to be able to run perl 5 scripts without change, unless you're doing something really funky. And I never had a perl 5 script break because of an upgrade during the entire 5.x series.
If something breaks in your code 99% of the time it is your fault.
I'd argue that lacking a formal specification, the language is the final arbiter of what's correct. If it compiles and runs, it's correct. It might be shite code, but if it breaks afterwards because of a change in the language, it's hardly the fault of the coder.
(Web developer for nearly twice as long, and extreme style nazi).
...and as far as I know it's completely back-compatible(except from some new reserved keywords, but that's easy to fix)
If this is true, it takes away one of my major fears about PHP5. They haven't exactly been careful about this in the past, and there's been more than one occasion where I was franticaly updating mounds of code because they decided something should be spelled different.
I've been keeping half an eye on the changes, and the only thing that had twigged as a possible issue so far was in classes, especially changing the default contstructor. Changing the name of a constructor isn't a big deal in itself, but I'd be doing it in a lot of code, distributed across many, many sites. I'd be very happy to put this particular fear to rest.
That aside, I am looking forward to the new OOP features. 95% of what I write is OOP, and there are some things in there I've been wanting for a long time.
That's an interesting approach. I'm in the big, white, cold country north of you, so the sales tax thing doesn't apply, but code ownership could be a selling point. I have considered putting our library code under GPL/BSD/etc.for karma and ease-of-licensing issues. The main reason we haven't is because half of our clients go glassy eyed when you start talking about IP, and the other half require big lawyer contracts that deal with IP anyway.
However, your approach might be the ticket to putting the idea across in an accessible way. Food for thought - thanks...
Well, I mentioned this above -- I have a contract which says "you own everything, but I still own and will be maintaining my code library" -- probably not 100% legally airtight, but the intent is clear.
Ah, sorry, I missed that part. This is basically what we do in the cases where it comes up. To your second point, if it is an issue in the contract/SOW, then we do present them with the above option. They're nearly always ok with this - and if not, it'll cost 'em to re-implement.
It depends a lot on the client...we've done work for the dot-com types (amazing how many people still think the web is a get-rich-quick scheme). Those involve big nasty lawyer contracts, and there's always clauses about IP in them. These projects always fall into the "less-fun" category.
We also do work for individuals, small businesses, NPOs. People whose eyes glaze over when you start using phrases like "code library." None of these have yet fallen into the development-for-resale category, and if they did, that would require a different approach. Basically, if there's nothing contradictory in any agreements with them, we're still covered and it's one less thing to haggle about.
OK, so do you go through the business of having them sign a license agreement for your code library? Do they have to go to you for maintenance, or can they do it themselves? How do you handle this legally?
Depends on the situation...I've rarely been an employee, so I'll answer for clients.
First, I don't usually bring it up. The chances of my/our code finding it's way into the wild this way aren't that great. We're not doing anything cutting edge, just your standard business logic kind of stuff. Bringing up IP during contract negotiations is a great way to lose contracts. Some might consider it kind of sneaky, but unfortunately, it's the world we live in. It's not like we're looking for reasons to sue people, the important thing is that we keep the right to use it.
Me -- I usually just give 'em the code from my library.
You have to be careful with that - if you explicitly sign over the rights to the code, they can come after you if you ever re-use it. They probably won't, but I have seen situations where I was glad that it wasn't a risk I had to think about. On the other hand, if you mean you just use your code and never discuss IP with them, it's still yours.
When it has come up, in almost every situation they were fine with a license that said (roughly) that they can use it or modify it themselves as they see fit and sell it providing no copies are retained and that this same license transfers with the sale. We've occasionally broached various open source licenses as a good way around this, and it's almost universally not understood. So we stopped doing that - don't scare your clients.
Slashdot Mirror
Yeah, I should have clarified - I haven't worked with .Net at all, so can't speak to it. I don't suppose there's a lot of old-style VBScript being done anymore, but that was what I was referring to.
I don't really have a great desire to work with .Net...we're a Linux shop (as far as server stuff goes), so until mono becomes commonly offered by hosting providers, there's not much point for us. The next thing I'll probably pick up is J2EE. I have some small exposure to it, and I like the model. I find that I'm mostly doing PHP these days. Not because I'm crazy about the language (I'm not), but it gets things done, it's everywhere, and I've got a ton of code for doing common things with it.
I'm not a language zealot, but there are certain tools that I like working with more than others, and I have the luxury of being able to choose projects for which those tools are best suited.
Regarding print design, I feel your pain. We did a small project in a similar way once (design was done when we came in, and obviously not by a web designer). The complete lack of consideration for very basic things like variable browser window sizes, accounting for browser chrome, (yes, it was fixed-width, and couldn't be changed), etc. made it take at least twice as long as it should have. Fortunately, we only decided to do this because it was a small project at a slow time. Never again. Ever.
I'm lucky in that our designer is very good. A good designer is a joy to work with.
Table layouts are a bitch to maintain. It's much easier to work with good CSS and proper semantic markup. CSS layouts are lighter. Search engines don't like table based layouts as much (all that extra markup pushes your content further down in the actual file). If you want to move page elements around (say putting the menu on the right instead of left), it's much easier to change a couple lines of CSS than sorting out a bunch of nested tables, counting columns, etc. One of the happiest moments of my career was when we decided we could start moving away from table layouts.
Yep ;)
Generally, I agree. Especially on the table layout bit. There's no reason to be doing that in this day and age, unless you've got some seriously ancient browser requirements. Yes, budget is going to be a major factor in how the site turns out - underfunded web projects fail the same way any underfunded software development project will fail. And I definitely agree that you should let the dev company worry about the things that you're hiring them for. Micromanagement is going to result in a crap project that misses deadlines and is over budget.
I'm not quite sure where you were going with "XHTML1.0 strict is an XML document", though. Of course it is, but that's likely tangential. It's just a fact of life that IE6 screws certain things up, and to get around them, there's a good chance you'll have to bend a corner here or there. Do I like it? No, it pisses me off because it makes my life harder. But as arkanes says above, IE6 is going to be with us for at least the next three years, and we have to deal with it.
Note that I didn't say strict was useless, or that it was never appropriate. Part of good web development is pragmatism. Chose your tools and standards wisely. Don't overburden a project with unnecessary strictures. If you only advocate strict to be strict, then it's the wrong reason. If it's because there's a good business case for it, then by all means, use it.
And of course anyone that builds solely for IE should be shot. Vigilante justice has it's place.
And I'm sorry about your buttocks.
Context: I've been doing web development professionaly for seven years, the last four with my own small web development company. We've worked with other firms, and been called in to clean up other people's work (the latter more often than I'd care for - that kind of work is zero fun).
As many other have pointed out, language doesn't matter a whole lot. We do recommend open source platforms, for the reasons familiar to anyone that reads this site often, but the most important question about this is whether the tool will fit the job. I've told clients before that what they really want is a Microsoft solution (because it fits the requirements) and that they should really find another firm to do it (because I'd rather put a hot poker in my eye than work with ASP).
Portfolio is important, but there are a million ways of fluffing it. Maybe it was subcontracted work, maybe they happened to have a really good person working for them for a few months, and they left because the company sucked. Maybe they're a large company, and their portfolio is all A team work, but you'll be getting the B team. On the other side, we've done work that would never make our portfolio because the client insisted on a nuclear orange and blue color scheme, or 500 links on the main page.
Picking a good web development company is difficult, largely because a) most of them are truly horrible and inexperienced, and b) the important things are difficult to quantify. There's a few things that are immediate warning signs, though. These should be rampantly obvious, but this is Ask Slashdot, and I've encountered each of these from companies that a client thought looked good on paper:
Some of the things that you should look for (this list keeps growing, I had to stop early):
I would agree that the pages should validate cleanly, but I wouldn't go so far as to say against strict mode. To get things to work properly cross platform, you may very well need to work with "transitional." This is largely because of problems with IE. This depends a lot on requirements - strict might be appropriate in a given situation. For a general usage, publicly accessible site, I wouldn't shoot higher than transitional. You'll be giving yourself more hurt than it's worth.
Definitely some murky waters here, and I'm glad that Moglen et al are thinking about this kind of thing.
I'm currently working on some PHP libraries that I'm considering LGPLing, but if I develop anything using these, I'd like to distribute the application specific parts under the GPL. Problem is, those would be web services. The whole point of them is to provide services without requiring distribution of the code. I'm not to crazy about the idea of someone being able to build off of it and offer a modified pay service without releasing changes. If someone wanted to hack around with it, or use it internally in an organization, I have no problem with it. But if it would be offered to the world at large, I definitely want the users (and myself) granted the same rights as they would have if it was installed on the desktop. Just because it's running off someone's server shouldn't mean that they could avoid this little issue, but it currently does.
Fortunately, I'm not in that league yet, although I've noted a dramatic increase in the last few months. I'm more in the 300 a week category, but at the rate things are going...Thunderbird is doing a pretty good job nailing spam for me. It's catching around 80% currently, and I haven't had a false positive yet.
One thing you might want to consider for posting email addresses on your site is to encode it with javascript. It's not guaranteed (if a browser can decode it, a harvester can), but it significantly raises the bar. The one downside is that anyone with javascript disabled won't be able to get your address. That's getting more rare.
Here's a link to a handy encoder - just cut and paste the resulting javascript into your web page.
More information on the technique via this handy Google link.
Have you ever registered a domain? Nearly all the spam I get is to an address I only use for registering domains. I'm careful with my primary addresses, and receive nearly nothing on them.
A lot of spam that hits the system you'll never see as well. A big chunk of spam lists have bad or nonexistent addresses in them. There's usually some poor schmuck (here, that's me) that has to check and see if an Important Business Contact just can't type, or if all those emails to betty1@example.com, betty2@example.com, etc. are aimed at insecure men.
Other popular targets for spam are sales@, info@, support@....etc. so unless you're responsible for one of those, that's more spam you won't see.
Lucky bastard.
Except that he didn't lack it - go read his web page. It explains how he pulled it off, generating the faked images on the fly from a few pre-shot photos and perl.
Personally, I think it's a cool hack. Glad someone out there is still doing this stuff...
I think you've been hanging out at the command line too long..
Nope
I agree that this kind of thing - charging for bug fix releases - is sleazy. But it's not an easy problem (*Disclaimer: I don't think this excuses MS, whom I think are incredibly slimy, or anyone else).
There are two options:
- charge a stupid amount of money for a product that's behind the feature curve
- charge a (mostly) reasonable amount of money for a rushed product, with all the flaws that implies
The problems with 1) are obvious, from a company-health standpoint. The problem with 2) is that all those bug fixes cost money. Otherwise 1) would be cheap. You have to pay for that quality somehow.MS have themselves in a bind - they've made their money on getting "good enough" products out, and having shiny features to sell. They've been really pushing the "reasonable price" envelope for a while, but they're still way lower than what a bug free product would cost. Now people are realizing that "good enough", wasn't. Frankly, I think they've been cutting too many corners for too long, and I hope they choke on this.
But for Joe Schmoe software developer, this is much more difficult to balance. How do you pay for bug-fixing while still remaining competitive? Bug fixing is expensive.
Eventually, hopefully, the software market will settle enough that quality and security become major selling points. The market has to reach the point where it's willing to accept fewer shiny things, and where it's open enough to welcome a product that comes out six months later. Until then, we're going to be getting shafted on this.
If anything, they're too good. One of my favorite things about BattleZone was the monochrome vector graphics. Damn, I miss that game.
I love shiny graphics as much as the next guy (UT2004 is a current favorite), but give me a good game over whizzy graphics any day. Hell, I just whacked Morgoth again a couple of weeks ago. Not using any of those silly tiled graphics, either. I look like a '@', as god intended.
Indeed...I've been hearing a lot about how the rest of the world doesn't want another Bush presidency because we want the US to be weak. This couldn't be further from the truth.
I live just north of them, and I can tell you unequivocally that I want a good, stable and healthy America. I do a large part of my business with Americans and it is manifestly in my best interest that they have a strong economy and laws that make them an attractive trading partner. The Patriot Act, the US copyright and patent system (and their insistence that we support it), the current administration's ruinous economic policies all make me very concerned about economic health of the United States. If they continue down their current path, I have no doubt their economy will continue it's downward spiral, and Canada will be swimming right next to that big, sucking whirlpool
It also amazes me how few US citizens seem to understand that the rush to a police state will make this situation worse. Never mind that I hate to see friends of mine living in a country where the people don't seem to see that secret searches, perpetual monitoring of the citizenry and widespread government propaganda are bad things. How can people not realize that just as much as the economic policies of the current administration are weakening the country, their social, trade and law enforcement policies are destroying them?
To my American friends, don't let fear and promises of global dominance take you back to isolationism and unilateral foreign policies. The rest of the world does want to work with you. It's just been getting very hard to do that lately.
I agree it's not a major drawback, but it can be annoying if you have different programmers with different preferences. If one is naming things "getfoo()" and another is "getFoo()", they lack visual similarity, which is important if you're scanning large blocks of code. Also, if you're looking for the occurence of a particular function, you have to remember to do a case-insensitive search which may not be the editor's default. Even if you've got some kind of sane capitalization system that everyone follows, it's easy to accidently type "getfoo()". If capitalization matters, you'll catch these things and keep your code just a little bit cleaner.
More annoying, I find, are inconsistencies in the way built in functions are named, eg "file_get_contents()" versus "readfile()". It's a small thing, but remembering if they decided to break this function with an underscore on words or not is an irritant. It's one of those little things that makes the language feel sort of thrown together, as opposed to perl or python that have a nice, consistent feel.
That said, I use PHP almost exclusively these days, so this isn't a flame against the language. Just something I wish was different.
I'm glad there are still teachers with this attitude out there. Cries of "what practical use is that?" are disheartening. I don't know if it's just that I'm getting older and more cynical, but it seems to be more common. If there isn't an application for a discovery in the next quarter, no one's interested in it.
It's not just the things we may discover that we can't predict that are important, the process of discovery and learning is important. Without the process, we wouldn't have science as we know it. Just a bunch of people running around with alchemy sets and healing crystals.
We need to preserve and pass on the sense of awe and wonder that comes from pursuing knowledge for it's own sake. It teaches us to think, gives us perspective, and allows us to see humanity in a broader context than profits and dominance.
So, from someone who had too many teachers that answered that question with "It will be on the test", thank you.
Ah, that explains the rabid "this is crazy serious" comments. I RTFA, just not TFC. I thought this was just doing the obvious thing, and using javascript to manipulate a browser window that had been opened by the parent. Thanks for the clarification.
(Canada Day involves heat and beer. Mea culpa).
Yeah, I'd hardly call this a vulnerability. Maybe a "feature that can be used to trick users." Of course a parent window can modify content in it's child windows. This isn't exactly news. News would be "a child window can modify content in it's parent window", something that's supposed to require a signed script.
You could do something similar without even bothering with frames, by, say, registering 'microssoft.com' and then linking to "http://msdn.microssoft.com/library/default.asp." How many peole will notice the extra 's' in their addressbar? Is that a "vulnerability"?
Sounds like someone wanted to publish a "six year old vulnerability" to hawk their product.
Have an advertising plan, and a budget for same. Word of mouth will almost certainly not bring in business rapidly enough, or in large enough numbers. Don't rely on it.
Also, for consulting gigs, the right kind of clients are important. Learn how to say No. This is really hard at the beginning, but it's maybe most critical then. The wrong client will suck the lifeblood out of you if you let them. (Hell, the right ones can too ;) ). Do not overcommit, and if they're asking for too much, tell them. They'll appreciate your honesty. If they don't, their the kind that will be a continual burden on your company,and you can't afford them.
Well, we tried, but we left the job half done when we couldn't find any good beer.
Kidding! We love our big lug of a brother to the south. ;)
I'd ammend that to most changes have been for good reasons. In my post above, I was thinking specifically of the $HTTP_VARS_ change. Granted, typing $_POST is a heckuva lot nicer, but I really wish more thought had been put into how to handle that. There have also been a number of changes in how individual functions behave between point releases where the only rationale seemed to be that they thought it looked nicer the new way. (It usually did, but don't go doing things like that unless you give people an escape route, at least temporarily).
Perl is an excellent example of how to handle backwards compatibility the right way. 6 is almost a complete language rewrite, but it's still going to be able to run perl 5 scripts without change, unless you're doing something really funky. And I never had a perl 5 script break because of an upgrade during the entire 5.x series.
I'd argue that lacking a formal specification, the language is the final arbiter of what's correct. If it compiles and runs, it's correct. It might be shite code, but if it breaks afterwards because of a change in the language, it's hardly the fault of the coder.(Web developer for nearly twice as long, and extreme style nazi).
If this is true, it takes away one of my major fears about PHP5. They haven't exactly been careful about this in the past, and there's been more than one occasion where I was franticaly updating mounds of code because they decided something should be spelled different.
I've been keeping half an eye on the changes, and the only thing that had twigged as a possible issue so far was in classes, especially changing the default contstructor. Changing the name of a constructor isn't a big deal in itself, but I'd be doing it in a lot of code, distributed across many, many sites. I'd be very happy to put this particular fear to rest.
That aside, I am looking forward to the new OOP features. 95% of what I write is OOP, and there are some things in there I've been wanting for a long time.
That's an interesting approach. I'm in the big, white, cold country north of you, so the sales tax thing doesn't apply, but code ownership could be a selling point. I have considered putting our library code under GPL/BSD/etc.for karma and ease-of-licensing issues. The main reason we haven't is because half of our clients go glassy eyed when you start talking about IP, and the other half require big lawyer contracts that deal with IP anyway.
However, your approach might be the ticket to putting the idea across in an accessible way. Food for thought - thanks...
It depends a lot on the client...we've done work for the dot-com types (amazing how many people still think the web is a get-rich-quick scheme). Those involve big nasty lawyer contracts, and there's always clauses about IP in them. These projects always fall into the "less-fun" category.
We also do work for individuals, small businesses, NPOs. People whose eyes glaze over when you start using phrases like "code library." None of these have yet fallen into the development-for-resale category, and if they did, that would require a different approach. Basically, if there's nothing contradictory in any agreements with them, we're still covered and it's one less thing to haggle about.
Depends on the situation...I've rarely been an employee, so I'll answer for clients.
First, I don't usually bring it up. The chances of my/our code finding it's way into the wild this way aren't that great. We're not doing anything cutting edge, just your standard business logic kind of stuff. Bringing up IP during contract negotiations is a great way to lose contracts. Some might consider it kind of sneaky, but unfortunately, it's the world we live in. It's not like we're looking for reasons to sue people, the important thing is that we keep the right to use it.
You have to be careful with that - if you explicitly sign over the rights to the code, they can come after you if you ever re-use it. They probably won't, but I have seen situations where I was glad that it wasn't a risk I had to think about. On the other hand, if you mean you just use your code and never discuss IP with them, it's still yours.
When it has come up, in almost every situation they were fine with a license that said (roughly) that they can use it or modify it themselves as they see fit and sell it providing no copies are retained and that this same license transfers with the sale. We've occasionally broached various open source licenses as a good way around this, and it's almost universally not understood. So we stopped doing that - don't scare your clients.