Jamie's Space


TechEd 08 - Day 3

DEV375: Reactive Programming - Ivan Towlson

  • History of developing for windows clients

    • Win16/Win32 - Procedural style (message loops)

    • ActiveX/Visual Basic - Limited OO style, events + components

    • Windows Forms - Component oriented style

    • Common themes

      • Write code to copy data from model to control

      • Write code to detect changes in control data

      • Write code to copy data from control to model

      • Detect changes in model data or use gatekeeper

  • What is better about WPF/Silverlight?

    • Enhanced component model encapsulates common plumbing.

    • Designer-developer workflow needs a declarative programming style to work well.

    • Hard to write robust OO/procedural code against a lookless model.

  • Reactive programming is like binding values together. Think like how you can create formula’s in Excel - changing the value of one of the cells in a formula updates the result of the formula, and it keeps doing it.

  • Benefits

    • Remove plumbing code, no need to track changes in model and controls and copy data between

    • View/model relationship expressed in view instead of in controller/presenter code. Express the what, not the how.

    • Works well with the lookless approach - view reacts to model change, rather than the model manipulating the view.

  • .Net works on a notification system (INotifyPropertyChanged) - when something changes, dependent values re-evaluate themselves.

  • Issues

    • We need to react to changes to derived data -> use converters for this.

    • A reactive expression may produce unacceptable values (user input?). Solution is to use validation.

Bindable LINQ

  • How do you query an ObservableCollection? How do you observably query an ObservableCollection?

  • LINQ queries don’t provide change notification!

  • Bindable LINQ is a community project to enable reactive controls to back easily onto LINQ queries

  • Key API : AsBindable() - extension method on IEnumerable

SEC201: Do These Ten Things or Get Own3d - Steve Riley

1. Use precise terminology

  • Vulnerability - The problem

    • Code

    • Configuration

    • Circumvention - Security rules that are so draconian that they encourage people to actively try to get around it.

  • Threat - The person that carries out the attack

    • External

    • Internal

  • Exploit - the code that exploits the vulnerability

  • Exposure - The cost of the attack being carried out.

  • Risk

2. Accept that no one will like you

3. Think like a bad guy

People will not like you for this either.

4. Understand the science

  • Identity is not Authentication.

  • Encryption is not Integrity

  • Inspection is not Intent - Can’t tell intent by looking at someone’s stuff.

  • Secrecy is not Trust - just because you can make something a secret, doesn’t mean you can trust it.

  • People are not Technology - All the technology in the world will not solve your technology problem.

  • “Defence in depth” = “I am a parrot”

  • Stupidity is not Malice

  • Usability and Security are a tradeoff.

5. Protect your gear

  • Patch your stuff.

  • Use the firewall.

  • Don’t run as admin, or reduce number of admins.

  • Install anti-malware, or scan fileshares.

  • Don’t tweak.

  • Rebuild, don’t disinfect.

6. Swallow your pride

7. Reconsidering the laws

  • Law 1: If a bad guy can persuade you to run his program on your computer, it is not yours anymore.

  • Law 2: If a bad guy can alter the operating system on your computer, it’s not yours anymore.

  • Law 3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore.

  • Law 4: If you allow a bad guy to upload programs to your website, it’s not your website anymore.

  • Law 5: Weak passwords trump strong security.

  • Law 6: A computer is only as secure as the administrator is trustworthy.

  • Law 7: Encrypted data is only as secure as the decryption key.

  • Law 8: An out of date is only marginally better worse than no virus scanner at all.

  • Law 9: Absolute anonymity isn’t practical, in real life or on the web.

  • Law 10: Technology is not a panacea.

8. Classify, and classify again.

  • Access

    • Principle of least privilege - others and yourself. If this principle interferes with your business process and is part of the OS, email Steve.
  • Data

    • Confidentiality, retention, recovery.
  • Trust

    • Functions, directions.

9. Don’t let your guard down.

  • People are always trying to sell you silver bullets/snake oil.

  • Trustworthy people will discuss the downsides of their software

10. Protection, not restriction.