web notes - a blog

grep -rl MultiViews *  | sed  "s/\(.*\)/chown user:group \1/" > chown_multi
grep -rl bacjdzzazbzceh * | sed  "s/\(.*\)/chown user:group \1/" > chown_bacj
grep -rl MultiViews *  | sed  "s/\(.*\)/rm -f \1/" > rm_multi
grep -rl bacjdzzazbzceh * | sed  "s/\(.*\)/rm -f \1/" > rm_bacj

If you don't have root privileges on a server and need to clean up after a hack, your hosting company may be willing to change the ownership of the files so you can delete them.

You can also try to use

<?php system('./rm_multi'); ?>.

• Do what you’re told. If you disagree, voice your concerns, and then, do what you’re told, even if you still disagree.
• Let people know what you’re doing, so they have an opportunity to correct you if you are going astray.
• Ask for permission if you are doing something unusual, or something that requires a significant amount of resources - including time.
• Be honest. If you make a mistake, admit it. Then, fix it.
• Don’t assign blame. No one wants it publicized that they made a mistake. They probably don’t illuminate your errors, either.
• Work within the code you’re given. Adhere to the architecture and practices, even if you don’t like them. If you radically change the way a system runs, it will likely be expensive to maintain, and difficult to understand.
• If you don’t understand what you are supposed to do, ask. ‘I didn’t know’ and ‘I thought’ are not valid excuses.
• Know who you work for. That person is the boss. They make the decisions with respect to what you must do. Clients, both internal and external must understand that your boss is in charge, not you. Don’t try to do more work than you are supposed to. It will cost someone something.
• Meet the specification fully. If you can’t, identify alternate solutions and get approval before deviating.
• Know how much time you have for a task, and finish in that time, or explain why you can’t and how you will handle it.
• Published material, of any form, is not a place for humor. Don’t put humor in your code, don’t use silly sample data, no matter how hilarious you think it is, don’t post funny images. If you send an email, it should be clear and concise. Posts in the defect/bug reporting, and in version control, should be strictly professional. Never forget that what you think is funny may not be funny to your coworkers, or your successors.

In virtually every web application - performance should take precedence over everything.

PHP (and many other languages) are interpretive. The code is read over and over.

• Organize the files such that the most commonly used code is first.
• Keep files small.
• Use a good architecture.
• Don’t read data or access information that won’t be used. If it won’t go to the client, on every request, don’t read it.
• Validate on the client side first, and don’t send the data to the server if it isn’t valid.
• Perform quick validation and escaping to protect the server on the server side.
• Cache files on the client whenever possible.
• Cache information on the server, use session variables for anything that will be used on every request. Consider storing ACL data in a session variable, but be aware of security risks.
• Be aware of PHP best practices, and the impacts of double-quoted strings.

robots.design was used to convert a complex AJAX application from one color scheme to another.

Since the objective was a neutral color scheme, I put greyscale color codes into the image/new color area. I ran the third script on the CSS files, and on the HTML (some inline styles were there). Took all those colors and pasted them into the existing CSS color block, and ran the tool.

Applied the second set of sed commands, and it looked pretty good.

I did change some of the colors manually to make it look better, but in 2 hours, I had a completely recolored application. The last time, it took me 2 days.

:)

Later note: I ran robots.design on a different application, with a much more sophisticated design, including dojo’s tundra theme, and it performed extremely well. I copied the dojo .css files into the application’s css directory, then ran robots.design. I didn’t copy the dojo .css files back into the dojo tree, because once they have been modified, they aren’t truly ‘tundra’.

• Start with a skin, purchasing skins is almost always worth the investment. The layout of the skin is more important than the colors. If a skin isn’t available, have the design team build one that is flexible enough for most clients.
• Develop a starting point and process to reskin it, even if it is just a list of manual operations. It may be more cost-effective to have an engineer do this than a designer.
• Try to use supporting graphics with neutral colors, to reduce the number of images that have to be recolored.
• Distribute the tasks to the lowest level possible. For example, recoloring images with image software can be performed by someone with limited technical experience.
• Don’t expect to be able to fully automate the process.
• Identify areas that are likely to be overlooked and ensure quality assurance is aware of them.
• Check the log files to find any missing image calls.
• Explain the cost savings and benefits to the client. Be sure they understand the limitations.