Jamie's Space

JP

TechEd 08 - Day 2

ARC202: I am not an Architect, I am an architect - Dr. Neil Roodyn

  • Why do most projects fail?

    • There are risks in developing software - laws, quality, misunderstood business needs, etc.

    • Unhappy customers.

  • History

    • Pioneering era - early computing. Software Development Process: Chaotic.

    • Stabilizing era - First demand for programmers,structure comes to development. SDP: Predictability. Based on engineering discipline.

    • Micro era - Drop in price of computing, more customer expectations.

    • Internet era - mid 90’s till present. Interconnectivity, change in pace of development. Customer expectations have outpaced developer abilities. SDP: Adaptive.

  • Predictability might be impossible in a creative field.

  • Requirements change in every project. “Change is Inevitable”.

  • Software needs to move away from the separation of architect and developer.

  • The majority of the cost of a system is usually the software development, and the major component of that is personal costs.

  • Craftsmanship is a different approach to software development.

    • Needs dedication - constant learning.

    • Duplication of software is low cost - this makes it more difficult to get revenue from your work.

    • Mentoring - Share experiences and knowledge.

    • Taking time out to think about things in the background - some of the best ideas are discovered while not actively thinking about the problem.

    • Accomplishment.

    • Need to set up processes so that developers can learn from their own and others mistakes.

  • Why promote the best coders into positions where they don’t write code?

  • Customers have a lot of choices - need to educate them on the tradeoff between cost and quality.

  • Happy developers create better quality code.

  • High quality software is possible - needs good supporting tools.

  • People over process.

SEC314: Secure Development Patterns - How not to screw yourself during development - Corneliu L. Tusnea

  • Distributed authentication systems work by verifying security tokens are valid, rather than verifying usernames and passwords on each service. The more times the password verification code has to be repeated the more chances there are for data leakage or failure.

  • Security should not be part of the code, it should be part of some external configuration - what user can use what services.

    • You still need to set attributes in code to determine what services to manage with security. This provides a better security model as there is only one place for look for specific security policy, and the code only needs to be referred to determine if it can be configured with security policy.
  • XSS protection is difficult to do yourself - the Microsoft security guys have written a library called AntiXSS, use that. HtmlEncode does not protect against XSS attacks. You should create a basic replacement for Label and Literal that AntiXSS encodes the text it displays and set up a TagMap to these new tags.

  • Validators are a source of duplication in a system.

  • Exceptions can leak information if used naively. A better method is to attach an enum to your exceptions, and to show a message based off of that. This gives you an easy way of internationalising error messages too.

WEB305: Pumping Iron: Dynamic Languages on .Net - Harry Pierson

  • Tradeoff between Type Safety and Flexibility

    • Rails ActiveRecord example - AR adds the column names of a table as properties on the model class at run time.
  • Real products are being shipped on IronPython - ResolverOne

  • Dynamic languages are very productive - good for initial work on greenfield projects.

  • Dynamic languages are not as fast as Static languages, so optimise by replacing slow parts of Iron(Ruby/Python) with C#. This is easy in the Iron* languages.

  • Dynamic Languages are easy to teach and learn.

    • Short on Ceremony - You don’t have to add extra stuff like package management or class creation to python if you don’t want to.
  • Formatting and whitespace matters. All Python code looks the same, so it is easy to start working with someone else’s code.

  • Dynamic languages are powerful.

    • AOP is easy in Python - it is possible to pass functions around as they are first level citizens, or you can use decorators to wrap functions.

    • You can create new types at runtime - example given was an XML to Python loader, which created Python objects from any given XML document.

  • Iron* languages are first class .Net citizens.

    • Interop with other .Net code. Easy to use C# or VB.Net code from Iron languages, but it is harder to go the other way. Standard .Net assemblies just work in Iron.
  • Iron* languages are embeddable by using the DLR.

  • Microsoft are working on integration with Visual Studio currently, due in 2009.

  • IronRuby and IronPython are both true Open Source.