A One page Reference to Standard Shortcut keys for Windows. You've gotta know these. You've just gotta!

Windows Operating System Shortcut Keys

Windows Applications Shortcut Keys

In this article I will focus on how you can use XML to package up the details of mentally defective and physically handcapped people who possess small fortunes and seamlessly deliver their data to a syndicated crime consortium.

If you are ethically opposed to fleecing the less abled of their savings, then you can take heart that you can make a tidy profit without getting your hands dirty.

The benefits of an XML approach to this kind of problem are endless. With faster development turnaround, a wide choice of tools on any platform and a self-describing format, these helpless victims can be stripped of the wealth they barely knew they had in half the time it takes traditional fraudsters.

The data itself can be acrued using legacy techniques, such as hanging around differently-abled sporting teams, or posing as the family member of a mentally defective person in order to gain the trust of their community.

But once you've compiled the necessary information on their bank accounts, credit cards, home addresses and level of disability, that data can be sent straight into the modern age.

There is currently a lack of XML schemas available for describing potential fraud victims. You may find the need to compose your own XSD, though of course reusing schemas from the insurance industry should be a suitable starting point. You will find a number of these available through OASIS and Microsoft's BizTalk.

In this information age, such data is at a premium. With gross profits of up to one hundred thousand dollars per end-victim, you can charge huge sums for the data you supply.

By providing your data through a subscriber-based web service, you can make it available to numerous faceless crime syndicates, criminal cartels, banks and insurance companies all over the world.

Scalability is what makes this form of racketeering so lucrative and interesting. Once you've enabled the fleecing of a number of these underpriveleged persons, you will find them to be in a state where, for a minimum of money, they are willing to provide you with fresh and valuable data about their ill-brained friends. Once a certain critical mass of victim/informers has been achieved, the business will practically run itself, giving you a veritable licence to print money.

I may not be able to write a new column for a few weeks, as I have just purchased a large brick of cocaine that I intend to mix with egg white and paint all over my body. But sooner or later I will return.

In the meantime, try to keep thinking of new and interesting ways to use XML.

Breast of luck

Danford.

Danford C Meridius is a guest columnist. His opinions are not those of the Secret Geek website. His advice is provided for satirical purposes and should not be followed.

Coining a new term: Encrapulation.

OO design without the design? Beware of Encrapulation

Encrapulation is what occurs when all the useful chunks of code become trapped so far inside obscure and fidgety modules buried deep inside your components within components that they are no longer usable.

Wrappers within wrappers, the hall of wrappers, obfuscated object heirarchies, over use of duplicitous global objects...

Any encrapulated OO project needs to be urgently refactored.

Notes on how to revise a very bad manuscript. Largely gleaned from the book 'How to Write a Damn good novel' by James Frey.

• Analysis. For the entire book compose:
  • step sheet
    • logical flow
    • emotional flow
    • PREMISE
    • Choice of viewpoint
  • character profiles
    • physical
      • gender/age/height/weight/hair/face/features
      • deformities/health/strength/dexterity
    • social
      • names/nicknames
      • upbringing/childhood/family/friends
      • education/career/hobbies
    • mental
      • reactions/attitude/ego/outlook/temper
      • fears, neuroses, anxieties
    • RULING PASSION
• Action. For each chapter/scene, consider:
  • cut irrelevant scenes (irrelevant to the premise)
  • fix logical errors
  • start as far into the action as possible
  • emotions/drama/style
    • empathetic:
    • reader's emotions in check with empathetic characters
    • consistent and effective:
      • characterisation
      • viewpoint
      • tense
    • conflict
      • not sudden or jerky
      • not stagnant
      • intensifying
      • start: hook
      • end: tag
    • dialogue parsing:
      • triteness/cliches
      • characterisation
      • 'indirect'
      • clever
    • prose parsing:
      • not vague
      • specific, detailed
      • tasty, fragrant, tactile, colourful, harmonious, melodious; (stimulating)
      • rhythm (suitable when aloud)
      • consistent tense
      • consistent viewpoint
  • mechanics
    • spelling
    • grammar
    • your checklist:
      • eg: 'ly' words, common typos, character names, cultural specifics

Output

• the Novel itself
• Stepsheet
• Character profiles
• Executive summary
• personal checklist
• premise (1 line summary)
• blurbs/taglines/teasers
• scrap heap of rejected ideas/fragments
• notes (from working through problems, research etc.)
• Archive of old copies, backups (softcopies and hardcopies)

For a list of bad practices you can follow, see the ever-popular How to write a novel

How many job applications ask for experience with 'the complete software lifecycle?' Do you have experience with 'the complete software lifecycle?'.

Just as different species of fish have different lifecycles, so different species of software have different lifecycles. I've produced a chart to show a quite common example of the complete software lifecycle, as I've seen it happen.

If my resume says i have experience with the complete software lifecycle, then this is what i'm talking about.

• Turn off animations
• Make strings stand out
• Turn on Word Wrap
• Adjust your Tab Sizes
• Set Tab Order for multiple controls
• Set code to editable while debugging
• Make breakpoint warnings stand out

No truly sane developer enjoys writing user documentation. This is a short note about fulfilling your obligation to write technical support documentation. Originally it was a comment on Roy Oshergrove's 'Iserializable' blog. Roy seemed to like it, so I've republished it here.

Writing, whether technical or creative, always has defects. It never has the elegance of code, it can never be evaluated completely. There are always more ways you can look at it.

So accept that it's going to be bland and imperfect and boring. Accept that very few people are going to read it or refer to it. All you have to know is that when people do, they'll be able to get nice simple instructions that will lead them to the answer they are looking for.

Use lots of sub headings. Sub headings are easy to write. (if you can't even write the subheadings then you're really in trouble) write enough sub headings the thing is practically done. That's your first draft. Print it out. Give yourself a pat on the back.

Write very quick notes under each sub heading. print it out and re-read it, judging it only for its truthfulness and its completeness. Do not parse it for grammar, style, sophistication, sexiness or anything else. Where it isn't complete, add more notes. Where it isn't truthful, make it truthful. Ugly is fine. Stupid is okay. Boring is expected. Just make it truthful and complete. Now print that out. that's your second draft. You've earned another pat on the back.

Now track down your sub-editor. This is probably your wife/secretary/mother - someone who is not your boss, who loves you unconditionally, who is not as technical as you (they're NOT concerned with the facts or the completeness of what you've written.) Plead with them until they agree to read through it with you. They love you unconditionally, so they will agree. They won't hate what you've written, but they'll know which problems of style are the important ones. And once you've read it through with them, you will too. The third draft's the charm. Once that's done, send it out into the world. You've wasted enough time already.

cheers
Leon bambrick

I've improved smartjelly's commenting engine, so people can write comments more reliably (and more safely). There were flaws in there previously that would have allowed an XSS attack to succeed, and some formatting ugliness that had to go. It's incredible how much effort is required to get the little things right. Next step is to allow comments to be posted at the end of an article (rather than in a separate page) as this makes the commenting more interactive.

a very simple change, but one I like is that now there's a message telling you that html isn't allowed. I hate when feedback forms give no indication of whether HTML is or is not allowed.

So what happens now when you leave a comment is I html encode your comment(so all tags are turned into 'literal' tags), and i append a <br/> tag to any carriage-returns.

Also, comments now give you the exact time (rather than just the date) when the comment was made (in GMT).

There are about a dozen other 'behind-the-scenes' improvements to commenting, and still literally hundreds of other improvements I'd like to make to SmartJelly. But it's hard to work on it, when it's written in 'traditional' ASP (a doomed technology). If I had a viable server, I'd rewrite the thing in ASP.net tomorrow. ASP.net, unlike ASP, is a thing of true beauty.

On the topic of blog comments, I've given some thought and will write something constructive about this after I've had a long nap