For the project we're working on, we are combining several bits of XML data and using an XSL template to display the HTML. This helps seperate the data from the markup. That way, your PHP or Perl would be responsible for getting the data (in our case, XML from web service calls and XML config files), handling user input, and running the XML/XSL transform. This solution works for us because we can dynamically call different XSL templates depending on the skin we want to display to the user, but the data always coming from the config files and web service calls always stays the same and doesn't care about the markup. The downside here is that this method requires that any database calls or business logic is returning XML. It works great for us, since we're moving all of our logic into a web service layer, and the services always return XML. This might require more architectural work than is necessary in your case, but if the web app is big enough or complicated enough, this method provides some great decoupling.
1) Do you have any rapid development tools at your disposal? Depending on the technology involved, you could leverage certain tools like Visio or any of Rational Rose's products in order to quickly generate the database scripts and/or skeleton code; however, for this to actually be useful, you have to already be familiar with these tools in the first place (and thus not spend half your time looking for the right menu options or diagram shapes).
2) Could you perhaps break up the functionality into phases? Sometimes the best way to do it is to give them some initial functionality sooner, then deliver the rest as a "phase 2". This will give you the chance to deliver a more solid "phase 1" that both you and the client will be satisfied with.
3) If the client is not willing to work with you on the timeframe (or they are not willing to negociate a solution in the above idea), then definitely state to them that you cannot accept the project, and that furthermore you want to give them a little advice that whomever does accept the project will probably deliver a shoddy solution, given their rigid timeframe.
I deal with this quite a lot at my company; however, I've found that our business people and our outside clients are actually rather receptive to a phased release schedule, especially if you can deliver their important features earlier and then leave the less important features to a "phase 2."
I agree. If you take a look at other areas in computer security (for example, Windows 2000 servers and insecure IIS setups), the actual breakins/worms/etc. have (albeit slowly) caused more admins to lock down their Win2K servers. It has also caused a change for the better with the vendor (Microsoft) in that the next version of their server software (.Net Server 2003) will initially be relatively locked down, and the admin who is configuring the server will have to specifically turn services on. Thus, abusers and intruders have a necessary place by providing the motivation for improving security.
However, with so many consumer-based 802.11 access points out there, I doubt that Joe Homeoffice will even realize how to lock down their networks. In this case, the vendors should start by having as much default security as possible, as well as some helpful reading in the instruction manuals for how to secure your wireless setup.
When you first see a decision like this, it's easy to say "hey, why didn't those fat cats in the court just fix the broken law." The problem is that the law isn't SO bad that it needs the judiciary to strike it down.
The court did the right thing given it's constitutional authority. The responsibility to fix the current set of patent regulations lies with Congress, not the courts; especially when the underlying concept of patent law is inherently good. Only when a law is so completely bad (for example, slavery) should the judiciary make an end run around the Congress.
Slashdot Mirror
For the project we're working on, we are combining several bits of XML data and using an XSL template to display the HTML. This helps seperate the data from the markup. That way, your PHP or Perl would be responsible for getting the data (in our case, XML from web service calls and XML config files), handling user input, and running the XML/XSL transform. This solution works for us because we can dynamically call different XSL templates depending on the skin we want to display to the user, but the data always coming from the config files and web service calls always stays the same and doesn't care about the markup. The downside here is that this method requires that any database calls or business logic is returning XML. It works great for us, since we're moving all of our logic into a web service layer, and the services always return XML. This might require more architectural work than is necessary in your case, but if the web app is big enough or complicated enough, this method provides some great decoupling.
...why aren't these optimizations contributed back to the Mozilla source? I'm assuming there's a good reason... just curious.
1) Do you have any rapid development tools at your disposal? Depending on the technology involved, you could leverage certain tools like Visio or any of Rational Rose's products in order to quickly generate the database scripts and/or skeleton code; however, for this to actually be useful, you have to already be familiar with these tools in the first place (and thus not spend half your time looking for the right menu options or diagram shapes).
2) Could you perhaps break up the functionality into phases? Sometimes the best way to do it is to give them some initial functionality sooner, then deliver the rest as a "phase 2". This will give you the chance to deliver a more solid "phase 1" that both you and the client will be satisfied with.
3) If the client is not willing to work with you on the timeframe (or they are not willing to negociate a solution in the above idea), then definitely state to them that you cannot accept the project, and that furthermore you want to give them a little advice that whomever does accept the project will probably deliver a shoddy solution, given their rigid timeframe.
I deal with this quite a lot at my company; however, I've found that our business people and our outside clients are actually rather receptive to a phased release schedule, especially if you can deliver their important features earlier and then leave the less important features to a "phase 2."
I agree. If you take a look at other areas in computer security (for example, Windows 2000 servers and insecure IIS setups), the actual breakins/worms/etc. have (albeit slowly) caused more admins to lock down their Win2K servers. It has also caused a change for the better with the vendor (Microsoft) in that the next version of their server software (.Net Server 2003) will initially be relatively locked down, and the admin who is configuring the server will have to specifically turn services on. Thus, abusers and intruders have a necessary place by providing the motivation for improving security.
However, with so many consumer-based 802.11 access points out there, I doubt that Joe Homeoffice will even realize how to lock down their networks. In this case, the vendors should start by having as much default security as possible, as well as some helpful reading in the instruction manuals for how to secure your wireless setup.
When you first see a decision like this, it's easy to say "hey, why didn't those fat cats in the court just fix the broken law." The problem is that the law isn't SO bad that it needs the judiciary to strike it down.
The court did the right thing given it's constitutional authority. The responsibility to fix the current set of patent regulations lies with Congress, not the courts; especially when the underlying concept of patent law is inherently good. Only when a law is so completely bad (for example, slavery) should the judiciary make an end run around the Congress.
BOFH!!!
If ever a circumstance called for some BOFH TLC, it would be this...
"Hi... my KaZaA isn't working."
"Well, let me take care of that... what's your password?"
Just in time for your favorite spring installfests!
*** it's thinking ***
Dear God, someone save us...
First the DVD chips/Windows Media tie-in, and now a whole OS... and you thought the IE market share/desktop OS monopoly was bad...
did i get an fp after all these years?