Learn Every HTML Tag and Every CSS Property

It is worth knowing every HTML tag and CSS property. It will help you build pages more efficiently. The quiz in the link above, and in the big green box on the left, is a great way to test your memory.

Learn all the CSS properties as well. http://www.oneplusyou.com/bb/css_quiz

Check the answers you missed to find out what they are. Be careful, some have been deprecated for XHTML.

It’s also Fun!

Super HTML Lists

Using ul and ol for lists with XHTML is nice, but for lists that include a short title, dl is a great option.

The code below produces a nice list, where Term and Word are bolded, and Definition and Value follow on the same line.

<style type="text/css">
dt{clear:left;float:left;width:50px;font-weight:bolder;}
</style>
<dl>
<dt>Term</dt>
<dd>Definition</dd>
<dt>Word</dt>
<dd>Value</dd>
</dl>

Customizing dijit tundra

dijit’s (dojo - http://dojotoolkit.org) tundra theme is excellent.

Notes on customizing it:

  • Copy dojo.css, dijit.css, tundra.css, and the supporting images out of the dojo tree and into the application’s CSS directory. Place the images in a directory under CSS, that way, the paths don’t have to be updated in the CSS files for those images. This risks later version conflicts with dojo, but also prevents inadvertant destruction of customization on upgrades. This also ensures you don’t affect other applications as you modify the files.
  • Update paths in the files (tundra.css imports dijit.css). Renaming tundra.css is a good idea, since it won’t be tundra after you change it.
  • Use icons from the Crystal Project (see link above). Be creative, the icons are beautiful and can be used in many ways to enhance the dijit theme.
  • Strive to avoid creating new images, unless you can create them quickly. Tiny images can take a surprising amount of time. Since the majority of tundra is grey, with blue highlights, simply removing the blue images and adjusting the remainder can provide a neutral color scheme.
  • Augment the tundra colors with those from you application. If you use the same hue, you can adjust the brightness and saturation to add variety to the color scheme.
  • Change as little as possible, because tundra already looks great. Try to preserve the dojo CSS file structures, so that if you need to merge in changes after an upgrade, it is not too difficult.
  • Use at least four other CSS files, base.css which contains application common basic layout, color.css, which contains application common color settings, ie.css for IE, and ff.css for FF specific settings. Additional page-specific CSS files, as well as some embedded style tags may be helpful as well. Configure caching to reduce the impact of these files, consider compression or bundling them together if necessary. Keep CSS as lean as possible, place design images in HTML, where they don’t incur overhead unless they are used.
  • Spend time looking at the Crystal icons. Even if the icon is named ‘urgent_mailmessage.png’, if it looks good where you want to use it - use it there.
  • Install the Crystal icons in DocumentRoot, then link to them with a symlink from the images directory, which should be at the same level as the CSS directory. That way, the icons can be shared by all applications and sites on the server.

Top 25 Most Dangerous Programming Errors

Anyone writing web-based applications should refer to the above link and audit their code.

This is one of the best ways to improve the security of the application, and to learn how to write more secure applications in the future.

Never assume that your application can’t be attacked or compromised.

Although existing open source software on publicly accessible servers is easier for malicious users to attack and defeat, custom applications are not immune.

Reasons you should always strive to build secure applications:

  • Improved security protects the data, the code, the server, the network the server is on, and your job. It limits the time wasted cleaning up after compromises.
  • Quality. Security, done well, usually improves quality. It requires greater care to write the code.
  • Future use of the code. Many applications start with a particular goal and grow. Soon they are distributed, and a wide audience can look at the code, either with an eye to collaborate - or attack.

Another excellent resource is http://phpsec.org, they have an audit you can run.

Don’t discount vulnerabilities with ‘that threat would not apply.’ Assume all threats will apply, because, in all likelihood, if they don’t at launch time, they will in the future.

Invest in SSL/HTTPS at the beginning and learn about Web Application Firewalls like mod_security (http://mod_security.org). It is okay to use a self-signed certificate, instruct affected users to trust it, with instructions on how to verify it (a screenshot is good).

Most importantly, take the time to read and learn. Even if you can’t address every issue as well as you would like, strive to address as many as possible. Loop back to improve the code if you have time.

Success in Teamwork and Process

Together Everyone Achieves More”

  • It is very difficult to test a complex RIA thoroughly. It is even more difficult if it is yours. Sending the system to the users, and asking them to focus on specific areas is an excellent way to find problems you missed. Remaining focused on delivering quality software and doing a good job makes it easier to acknowledge oversights, errors, bugs, and mistakes - and fix them.
  • Don’t send harsh comments or accusations. If something is wrong, check very carefully to see what is happening. Report only the facts, for example: ‘this is in the log’, ‘this sequence of steps causes an error’. Read carefully. Take your time.
  • Don’t underestimate the value of the data in the system. Take great care to protect it at all times from corruption. Test the system on a different server or using a different database prior to launch.
  • Respect the value of other people’s time. Don’t ask them to test anything that you aren’t very confident in. Request their help with several, specific issues, to reduce communication overhead. Offer to meet them in person if it is difficult to resolve through email.
  • Use version control. Be sure that if you changed the file last, you didn’t overwrite anyone else’s changes.
  • Thank those that test the code and take the time to respond, even if they find problems.
  • Even if there isn’t a problem, or it is a simple piece of code, it is good to allow others to review it and suggest changes. Whenever possible, make the changes.
  • Avoid scope creep by adhering to written and recorded content. email and verbal changes that have been agreed upon should be entered into a defect management system. This ensures the details aren’t forgotten and also serves to limit the scope of changes when the work is done. Use the ids from the defect system to be sure everyone knows which issue is being addressed.
  • Use neutral colors and be courteous in email replies. Many people perceive red text and UPPERCASE as harsh, even if the content isn’t. Blue, green, purple are better choices.
  • Remember that it isn’t ‘your’ code, it belongs the the company or the client, whoever is paying your salary. The objective of the project isn’t to produce software, it is to provide a solution to a need or requirement. Strive to find the best solution.
  • Give credit for good ideas from others.
  • Test plans are excellent resources. They don’t need a specific template. Any way that you can comfortably explain what to do, and what should happen is find.