ctodx

In this episode of the video series on the various chart types available in XtraCharts, DevExpress' charts product for WinForms and ASP.NET, we look at the stock chart, that most basic of financial charts.

The stock chart is fascinating in that it embodies four values per argument point instead of the usual one. The argument axis is the trading date and the value axis the price of the stock being plotted. The four values are open, close, high, low and the point is represented as a vertical line with tick marks rather than a single dot.

For this demo I copied a month's worth of stock prices for MSFT from Yahoo Finance and inserted them into a new Access database.

[Sidebar note: This video almost didn't get made. I had a plane to catch, Jeff was ready with the camera, we started shooting. I was recording with Camtasia on my little Dell notebook. Half way through, it overheated and ground to a stop. I had to put it in the freezer compartment of the office fridge to cool it off. Minutes ticked by. Finally it was cold enough to do the recording and this is the video that came out of it. One take, no messing. I then popped the notebook back in the freezer so that the rendering would complete without overheating. Needless to say I caught the flight, and I now have a new notebook, one with a better cooling system.]

It's certainly turning into a charting marathon in my blog recently, and why not? XtraCharts is just so cool.

Anyway, Jeff has completed the editing of the next video in my series on the various chart types in XtraCharts, and so I present it without further ado: the Gantt chart.

[To make customers in Europe happy, I'm using D/M/Y formatted dates. Well, OK, that's just how I have it set up on my machine, but it does show you that our controls work perfectly well with a non-US date format!]

A request came in just recently, prompted by my video introducing the three major new features in XtraCharts v2008 vol 2: how do you set up a couple of series and display them in separate panes. "Programmatically" came the kicker before I could quip with "watch the video properly."

So our Charts team quickly whipped up a couple of examples and have uploaded them to CodeCentral.

The first shows the steps needed for the example I showed at design-time in the video. Here we bind to the gsp.mdb database and display the chart using the automatic SeriesTemplate property. We show each of the 5 series in the data in a separate pane.

The second shows the same data, but this time the series are explicitly set up. (For brevity we only show two of the possible 5 series in the data. It left as an exercise for the reader to display the other 3 series .)

A quick video this one, part of a series on the different chart types available in XtraCharts. Here I discuss the three radar charts provided in our charting product: radar points, lines, and area.

[For some reason, it looks as if some demented two-year-old got hold of my mouse during this one; since it was me, I'm going to say my coffee must have been a tad strong that morning. Just a tad.]

Today Embarcadero announced Delphi 2009 and C++Builder 2009, previously codenamed Tiburón.

Consequently, we have been getting some questions on what our policy is about supporting these new compilers with our VCL products. To which, I can only say, duh, support them, of course.

However, there is more to this support than meets the eye, so let me expound a little on the subject.

The biggest change, at least as far as we're concerned, is the new support for Unicode in Delphi 2009. I really don't want to go into the issues too deeply here, but will instead state that the Unicode support is pervasive. The default string type is now Unicode and not Ansi as before. Although CodeGear have done a remarkable job in making the porting of normal application code to Delphi 2009 as seamless as possible, it is not the same with some of the code we have in our codebase. As a quick example, in order to gain the best performance for our VCL UI Ocontrols, we make extensive use of direct Win32 API calls. Of course, in doing so we've been making use of the Ansi versions of the interfaces. All of these need to be changed, thoroughly checked and tested after conversion. And that's just the tip of the iceberg: we can't just make wholesale changes to our codebase, since we need to have it support all Delphi versions from Delphi 6 to Delphi 2009 (and, no, just $IFDEFing whole blocks of code doesn't count).

The next biggest change is the interface between C++Builder 2009 and Delphi 2009. Again, there are a great many changes in this area. Huge. Although the vast majority of our VCL customers use Delphi, we have to make sure our C++Builder customers are well served by our port. I'd have to say I wish Borland of old had spent as much quality time in this area as Tiburón R&D have: our C++Builder support would have been much easier.

The current goal for Tiburón support is to convert all current versions of our active VCL products. Let me parse that more carefully.

• By "active VCL products" I mean all of the VCL suites and libraries that form part of our VCL subscription and that are mentioned here. The retired products that you may also download as part of your VCL subscription (such as CodeRush for Delphi, say) are not included and will not be ported. Other products that form part of the unified installer, but that were not supported in Delphi 2007, are not included either.
• By "current versions" I mean only the latest version of a particular suite will be ported. So, for example, only ExpressQuantumGrid Suite v6 will be converted, only ExpressPivotGrid Suite v2 will be ported, and so on.

The next big change is the new generics support in Delphi 2009. We are not planning on supporting generics with the current conversion project.

Although Embarcadero announced Delphi 2009 and C++Builder 2009 today, they explicitly refrained from saying anything about when they would be shipped. Considering the vast number of changes and their architectural breadth embodied in these new compilers, there is absolutely no possible way for us to be ready with our support on the day that Delphi 2009 and C++Builder 2009 are released. None whatsoever. We shall require a good deal of time to test our code with the final RTM of the compilers, once we get it.

Given the fundamental changes that are needed in our code to support Tiburón, we are considering having a beta program so that customers can get the code early and do their own testing. It's likely that this will be offered to our VCL subscription customers initially.

Oh, and if you own one of the products being updated, the support for Tiburón will be provided for free. Obviously it will be part of the normal VCL subscription update cycle as well. It goes without saying that if you are planning to move to Delphi 2009 or C++Builder 2009, I would urge you to make sure that you have the latest versions of the products you own and that you've fully integrated them into your applications. Moving existing projects to Tiburón is going to be enough work without having to worry about the fact that you're upgrading your controls as well.

Last week, Jeff and I recorded a "basics" video about XtraCharts.

In looking at this video, I see I should do further explanatory posts explaining the glossary or nomenclature that XtraCharts uses. At least I touched on things like arguments and values, but skirted over series. There will be more!

I'd have to say that Jeff's skill at editing out the "erm"s and so on makes me look better than I really am (in other words, be thankful you're not actually there during the recording ).

Here's a video that describes three of the important new features in XtraCharts for v2008 vol 2.

The three features I talk about are:

• Intelligent label layouts: making sure that your series labels don't overlap. Since this can be a very processing intensive operation when there are many labels, this is enabled as an option.
• Trend lines in financial charts: the first in a series of new indicators for financial charts (others will be added in future major versions of the product).
• Multiple panes in the chart diagram. This feature is helpful if you don't want to overlay one chart on top of another.

(Looking at the image above, it seems as if I've totally embraced extreme shoulder pads in some show of solidarity with a bad TV science fiction series. I can assure you that you're seeing the chair I'm sitting on )

Recently an issue came up with regard to the export to PDF functionality in our printing and reporting suites, XtraPrinting and XtraReports. The issue was in regard to the use of characters that weren't the normal 7-bit ASCII characters and whether the fonts should be embedded or not in that case.

I decided to take a peek at how we've implemented the export to PDF functionality in order that you can gain a better understanding of the issues. Since the whole subject is pretty complicated, I took the hit so that you didn't have to .

With PDF, there is a fundamental distinction between the notion of a character and a glyph. A character is a symbol, like "A" or "4", whereas a glyph is an image or rendering of that character. A collection of glyphs is known as a font.

Easy enough, except that a character has to be encoded in some way into a binary number. We're used to thinking of the character "A", for example, as being encoded as 0x41. This particular encoding started life in ASCII and has now propagated into Unicode.

That's all very well, but in the days when a character was encoded in a byte value, there weren't enough bit values available to encode all possible characters. So the notion of codepages evolved to encode different characters in the range 128 to 255. In the Latin codepage or character set (sometimes known as Latin-1 or Windows 1252), for example, the character à is encoded as 0xE0 (and, again, that propagated to Unicode). However, on the Mac the character à is encoded as 0x88.

Back to PDF. PDF is a file format that is essentially text and not binary. (Yes, I'm oversimplifying since text blocks can be compressed using the Deflate algorithm and will appear as binary blobs, but bear with me.) The text is obviously represented using some encoding. There are a set of standard encodings for text in PDFs: one for Macs called MacRomanEncoding, one for "Windows ANSI" (which is essentially codepage 1252) called WinAnsiEncoding, and one for a more general PDF codepage called PDFDocEncoding. All of these encodings are single byte encodings: each byte value represents a different character.

Back to fonts in PDFs (as you can see, there are lots of strands to pull together here to get the full tapestry). There are two different ways to define the fonts in a PDF. The first, and very lightweight way, is to describe the font as a set of metrics (name, width of glyphs, slope of italics, and so on). The reader of the PDF (say, Acrobat Reader) is then responsible for locating the font on the user's machine and using it. If the actual font is not available on the user's machine, the reader then has to locate the nearest font that matches the font metrics embedded in the PDF.

If the PDF uses fonts in this way, the text in the PDF is encoded as one of the standard encodings. As you can imagine, you are relying on the user machine being pretty similar to the machine that generates the PDF, otherwise the user is possibly going to get some weird effects (wrong or missing glyphs, a different look to the page, and so on).

In XtraPrinting and XtraReports, we used to use PDFDocEncoding in this situation. However, the majority of our customers use the Latin-1 codepage, and so there was a possibility that reports could have some missing or invalid glyphs when exported as a PDF for these customers. For the next minor version (2008.2.3), we've switched to WinAnsiEncoding and this change should help more people.

Of course, you may be thinking that it's nice to generate very small PDFs in this way, but it's all a little bit too hit and miss on the reader side. That's why there is a second way of defining fonts in PDFs: to embed them.

Here the onus is on the writer of the PDF. It has to analyze the text in the PDF, work out which glyphs of the font are being used and then embed those glyphs directly in the PDF. If fonts are embedded in the PDF in this way, the text is actually encoded in a two-byte manner and a map is generated that maps the character encoding to the index of the glyph in the embedded font.

Using fonts in this way, you get absolute precision control. What You See (as the writer) Is What You Get (as the reader). There is no wishy-washy, crossed-fingers, hope-for-the-best aspect to reading the PDF: the end-user will see exactly what you wanted them to see, no dropped or swapped glyphs. The downside to this is, obviously, the PDF is "heavier" or larger since it has to have all those glyphs embedded.

(Note to those who are really clued up on PDFs and character encodings and font support. There is yet another method: the writer can define a ToUnicode character map, or CMap, that is a single-byte encoding that uses a special map to work out which glyph to use with a font that's not embedded. We don't support this variant yet.)

Having said all that, you can mix and match. You can have some text in your PDF where you assume that the reader will have the required fonts available to display it, and you can have some text where you embed the fonts. In our printing suites, you can manage this scenario by using the NeverEmbeddedFonts property. If you name a font in the NeverEmbeddedFonts property (it's a semicolon-separated list of font names) it will be defined in the PDF in the first, lightweight, way. If a font is used in the PDF that is not in this list, then it will be embedded in the PDF in the second, heavier, way.

And that's pretty much it. I hope that this exposition has made the whole issue of fonts in PDFs clearer and that it helps you make the best decisions in your particular scenario when you need to export your report to PDF for your users.

Sounds like a conspiracy theory, so maybe I should put it all in caps, with spelling mistakes: INSTALING VISHUL STUDIO SP1 NUKKED MY DX NEW ITEMS IKONS. KTHXBYE.

A customer phoned me up this afternoon saying that he'd just installed DXperience Enterprise but couldn't find any XtraReports items in his toolbox. He was worried in case the install had failed in some way. Ha, I thought, I'll just walk him through creating a new application that has a report, and show that the XtraReports controls only show up in the toolbox if the designer is showing a report form. You know, that friendly CTO helping the customer thing.

So we started off together. Create a new solution, I said, and we did. OK, to add a report to this project, I said, we right-click and select New Item, and select XtraReports... WHERE THE HECK HAVE ALL MY ITEMS GONE?

For some unfathomable reason, installing SP1 had wiped all third-party item templates from this list. It was bare. No XAF, no XPO, no XtraReports, nothing. A tiny little tab still promised some DXCore items, but otherwise zip, nada, zilch. I shivered.

Meanwhile, I'm sure my customer was slowly backing away from the phone: the CTO of DevExpress doesn't know how to create a simple XtraReports app? What the... I made some reassuring noises -- OK, maybe they were just noises -- and we finished the call with my abject apologies.

I had a look at my other machine which I use for travel. There I'd installed SP1 and DXperience 2008.2.2 (I was late in updating it on that machine) in that order, and, lo, the new items page was full.

So there was nothing for it but to uninstall XAF and DXperience and then reinstall them (hmm, now I write this perhaps Repair might have done the job in a shorter time) and full functionality was restored. So, if you run into this, you'll know what to do.

Meanwhile, if you did call me this afternoon about XtraReports, I can lead you though the basics over the phone now. Honest .

Microsoft Senior VPs Steve Sinofsky and Jon DeVaan (the former in charge of Windows and Windows Live and the latter in charge of Windows Core Operating Systems) have started a new joint blog called Engineering Windows 7 to talk about, well, Windows 7, the next version of Windows beyond Vista. So that would be Lost Horizon then (bada boom bada bing ).

They're going to be regularly blogging about the new things in Windows 7 all the way up to PDC (Professional Developers Conference)in October -- where already there's a large number of sessions booked to talk about Windows 7 -- and WinHEC (Windows Hardware Engineering Conference) the week after. It seems that, after a virtual desert from the past couple of years, we're going to be deluged with information until we're drowning in the stuff.

The blog is bound to be interesting. My recommendation then is to subscribe to the RSS feed so you're kept up to date with what they say. (Well, as soon as it's ready; must be a Windows Live thing.)

(Er, Ray? I know that we're a Platinum Sponsor of PDC this year and that we have a large booth 'n' all and it's likely to be a madhouse in the Exhibitor's Hall, but could I have lots of time off to go to these sessions? Ray? Don't walk away laughing hysterically, I'm asking a serious question. No, don't switch the light off...)

A couple of days ago the Silverlight Control Builder Contest '08 that Page Brooks organized came to an end. He'd managed to convince a whole bunch of vendors like ourselves to pony up prizes (ours was a subscription to DXperience Universal and a $500 gift certificate to NewEgg) and had managed to amass something like $17,000 worth.

So how did it go? Well, unfortunately that was a problem. Only one person entered, Faisal Waris, and of course he won. Despite this, he didn't win with a piddly progressbar control or something, but instead created a stunning FishEyeGrid control for Silverlight -- you should certainly go and check it out. (Note, for some reason it wasn't working for me in Firefox 3, so use IE7.) Certainly a worthy winner.

Many congratulations to Faisal. The part of your prize from DevExpress is on its way.

But my post is not about Faisal's winning entry, it's about what went awry. Why only one entrant? That's a real shame. I came up with some thoughts:

1. The competition was for US developers only. As it happens, I can understand this: in the past we've looked at whether we could organize a competition in the same vein as this and the legalities can be overwhelming. Just in the US there are rules and laws about giving away prizes (for instance, the rule that everyone has heard of: "No purchase necessary"). I can't imagine what it's like in other countries; it could be there's tax liabilities or to give away a prize you have to have a legal office/address in that country, for example. Anyway, in this international, interconnected day and age it's all a bit of a mess.

2. It's hard creating controls for Silverlight. OK, I'm being more jokey than serious.

3. Silverlight is still too new for many people to have gained expertise in writing controls. Applications, maybe; controls, not so much. This is perhaps a better reason than 2. Although there is a lot of buzz about Silverlight 2, it is still in beta and not many workplaces will be using it yet, or even experimenting with it. So without work-related experience, you're left to play around with it at home in your spare time. And of course, there's a lot from Microsoft in the same space jockeying for your attention and learning abilities (WPF, ASP.NET MVC, etc). And, to be honest, not many people write controls (and most of them would be working for companies like Developer Express .

4. There wasn't enough time. A difficult one this: you want to give the potential contestants well enough time to experiment and design and write something, but you don't want to make it so long that the buzz dissipates and people say "uh, what contest?"

5. It takes a lot of time to create a compelling control that would win a competition. And as we all know, time equals money. Perhaps the $17,000 of prizes didn't have enough in gift cards/money/cheques to make it worthwhile. Sure it's nice to have the top of the range products from us and our fellow prize-giving vendors, but in the end a lot of the contestant's spare time goes into this. I calculate $1000 in certificates that can be used to buy "stuff" to repay your efforts for the first prize, $475 for second place, $200 for third place. Maybe that's not compelling enough to sink many tens of hours into the contest.

6. There was no registration. Without that Page had no real idea about how many people were considering entering the contest nor who they were, so he couldn't email all the registrants a week from the end to say, how are you doing?, are you going to finish? Without that knowledge, it becomes hard to make a decision to, say, extend the contest another week. With registration, more people might have persevered -- it's like signing up for a beta, you tend to feel compelled to try it out.

Nevertheless, it was a good contest and, as I say, well organized by Page and we all got a great control from Faisal that everyone can use.

When you install the .NET Framework 3.5 SP1 that was released today, and you're running Firefox 3 as your browser du choix, the next time you run Firefox you'll get the Add-Ons dialog showing you that a new add-on has been installed.

Funny that, I don't remember okaying that particular choice, but anyway. I'm about to install SP1 on another machine, so I'll look out for it.

This add-on provides click-once support for Firefox and also will report back to whatever web server is asking the latest version of .NET that you're using. Back in May, Scott Guthrie reported that this would be part of the SP1 beta, although it's fun to try and find it:

ClickOnce Client Application Deployment Improvements

• ...blah blah...
• FireFox browser extension to support Clickonce installations using FireFox browsers

Just a friendly heads-up from your homies at DevExpress...

Over the past few months I've been reading of rumblings in the .NET blogosphere about the directions Microsoft is taking with .NET.

The poster child for these rumblings is the dichotomy between LINQ to SQL and the ADO Entity Framework (EF). Both in essence are used to get data from your database engine into your .NET application, both implement an ORM (object-relational mapping), but it's not really clear which one to use. So there's a whole cottage industry that's grown up around this, with many august commentators opining for their readers which they'd go for (just google for "LINQ to SQL" "Entity Framework").

It turns out the reason there are two frameworks that have such wide overlap is that, ta-da!, they were written by two different teams at Microsoft. LINQ to SQL was written by the C# team, whereas EF came about through some long-winded gestation (I'm visualizing that scene from one of the Lord of the Rings movies where you see the orcs been "born") from something called Object Spaces and is owned by the ADO.NET team. LINQ to SQL was recently given over to the ADO.NET team.

Roger Jennings, in a post from May this year, wonders whether the ADO.NET team are just going to abandon LINQ to SQL. It's crippled in the sense that it only works with SQL Server and, as I said, there's a great deal of overlap between it, and EF. Why have 2 official ORMs when just having one will do?

And another example: the Patterns and Practices (P&P) group at Microsoft have been producing "best practices" type libraries, such as CAB, for a long time. Last year, just before TechEd, there was a flurry of information about a new product codenamed Acropolis that seemed to replicate a lot of what the P&P group were doing, but in a shiny new framework with designer support in Visual Studio. By October it had gone, its ideas to be subsumed in P&P and eventually the .NET framework itself. P&P has expanded its repertoire of libraries since.

And of course we have WPF, WCF and WF, all frameworks that expand on the basic .NET Framework. Ditto ASP.NET MVC. Poor old Visual Studio just can't keep up, which is unfortunate since they all really need VS's discoverability and designers to make them easier to use. So there's more blogging advice from august commentators...

The .NET Framework no longer seems to be single and indivisible. Instead it's turning into this multiheaded hydra, a victim of its own ease-of-use and productivity enhancers. Different teams at Microsoft seem to be producing libraries and frameworks as quickly as possible without anyone having much of any control over the process to try and unify them. David Worthington of SD Times seems to have a key to someone's filing cabinet at Microsoft, since he's quoting from yet another internal memo about exactly this issue in his latest article.

I don't know quite honestly what the answer to this might be. In one sense, it's great to get all this functionality flowing out of Microsoft. On the other, it just makes the whole process of developing with the .NET Framework that much more complex. Also, looking at it from our viewpoint, should we try and support everything that it makes sense for us to do? Wouldn't that spread us too thin, meaning our existing products and customers getting reduced love, but getting more marketing hits for new anemic products that support the latest framework/library? Or should we be more cautious, and test the waters a little with some experimental products before jumping in or retiring?

This is all a shame since the .NET universe was so much simpler than the previous COM and ActiveX universe. Are we getting to the point when another super abstraction is needed to make .NET simpler. together with full support in Visual Studio?

Alongside the new version of our VCL pivot table control, ExpressPivotGrid 2, that Ray introduced here, we are debuting our new spell checking component, ExpressSpellChecker, in the same release.

This component provides you with an uncomplicated way in which you can add Microsoft® Office® style spell checking capabilities into your next Windows® application. Features include:

• Built-in support for Ispell and OpenOffice dictionaries.
• The ability to check text in standard text editors as well as in DevExpress text input controls.
• If you do use text input controls from Developer Express, words that aren't in the dictionary can be underlined.
• The ExpressSpellChecker automatically checks spelling as you type, word by word. This is done in a separate thread without affecting the responsiveness of your UI.
• Custom dictionary support is provided and uses a plain text format.
• Dictionary dialogs allow end-users to add unrecognized words to a dictionary, so that they can build a custom word list as they work.
• There is a choice of two error indication dialogs, the dialogs that allow users to correct spelling mistakes. Both replicate dialogs found in Microsoft Office:
  
  
• Pre-built Options editor. Options include the ability to ignore emails, URLs, mixed case/upper-case words, repeated words and words with numbers within them:
  
  
• You can force the spell checker to start scanning the text from the current cursor position or to check the current selection first.
• Error correction can be done using a customizable built-in context menu:
  
  
• The ExpressSpellChecker's API includes methods to spell check an arbitrary string, the content of a text editor, or the content of all text editor controls within a specified container.
• The spell checker provides a complete set of events to allow you to manage the spell checking process - including the suppression of built-in forms, modifications to suggestion lists, skipped words, manual error processing, etc.

The Developer Express VCL spell-checking component will be available with the VCL Subscription.

[Supported compilers: Delphi 7, Delphi 2005, Delphi 2006, Delphi 2007, C++Builder 2007]

And before you think I'm slamming those damn lusers, think again. I'm including you and me in this.

A couple of weeks ago, I took my wife's car in for a recall. Since I work at home and she works downtown and the dealer is the other side of downtown, I said I'd drop her off at work, drop the car off for its service, and drive home in the loaner car. No problem, everything went as planned until I got home...

...When I realized that I didn't have a front door key, and I didn't have the garage door remote. It was pointless going back to the dealer since my wife's garage door opener is built into her car (it's a feature of some Acuras - a programmable remote). I was stuck outside my own house.

Needless to say, I managed to get in. No, I'm not telling you how, but it scared me that I was able to do it without any expensive damage, and that no one saw me do it either and I consider our neighborhood to be safe and crime-free. The whole episode made me think about security and how we take it for granted and how easily it can be subverted.

Another story. At the end of June, we were visiting my parents-in-law, when my father-in-law asked me some questions about viruses; the computer kind, not the biological kind. This led me to a demonstration of why Vista's UAC (User Account Control) was such a good idea. It heartened me that he had hardly ever come across the "dreaded" UAC dialog, meaning that for many people it's pretty invisible. I showed him how the UAC dialog will come up whenever the system detects that something is about to alter the system itself, such as installing a program. I drilled it into him that he should always click Cancel if it ever came up in his normal interactions with his computer, but that if he initiated the event that caused the UAC dialog then he was free to click Allow, although he should think about it first.

But there's a big problem with UAC and any other method of asking the end-user permission to do something when the end-user doesn't have the expertise needed to properly assess the risks: social engineering. Social engineering is the technique of fooling people into revealing secret information or of making them do something they shouldn't do. There are many examples of this:

• Phishing emails. You get an email from your bank, you click on the link, you go to a site which looks exactly like your bank's website and you enter your userid and password. You get a page saying, due to high workload the site is temporarily down, please try again later, but of course the baddies are already making off with your savings.
• CNN Top Ten lists. (Man, I'm getting sick of these.) The latest scam email purports to come from CNN.com, lists some kind of Top Ten set of videos. Each item is a link. Click on the link and you go to a page with a video, but, alas, it seems your video player is out-of-date, so could you install this latest version? Ta. Oops, the install seems to have failed, but we did mange to install a bot without you knowing. Welcome to the Storm botnet.
• You get a phone call, an automated recording, saying that your car's warranty is about to expire and you only have a very short amount of time to buy an extended warranty. Press 1 to talk to an operator. You break out in a sweat, press 1, talk to someone, pass over your credit card details, etc, put the phone down before you realize that they didn't know what car you had, how old it was, whether it had a warranty or not.
• You can't afford some software, so you go looking for cracked versions on warez sites. You find a zip of the application you want and download and install it. Well, we know what happens next. Pwned!

The common theme to these examples is that the point of failure is the human being. We are conditioned to be trustful. In general the people we meet and talk to are not trying to fleece us, so when someone who acts trustful towards us, we can easily be duped by them. It also seems that we are also unable to evaluate risks properly: if something has low friction (clicking on a link) we'll ignore the risks, when we know we should go the long, but less risky, way round (type the URL into the address bar).

Security is hard to get right. Not only that, it's downright difficult to patch on afterwards. If we write a program we should think about the security issues right up front. We should build in security so that the end-user doesn't have to think or worry about it. For example, are you going to have an auto-update option in your software? How can the user be sure that the update is coming from you? Perhaps a digital signature might be the answer, maybe something else entirely, but you should think about this first and not tack it on when the software is complete. Consider doing a threat analysis.

Security is also about education and risk-assessment. Educate your users on what to expect with your software and with your company, and train them to contact you if something else happens. Keep it simple. If you trade using the foobar.com domain, don't suddenly send your users emails from foobar-thatsus.ru (and if you do, and some users respond, then someone wasn't listening). Learn how to assess risks as well. This is a much harder lesson to learn, and, to be honest, just taking airport security as an example, you shouldn't feel bad that you may get it wrong some of the time.

And make sure you carry your front door key with you at all times.