About CSC

Process for CSC hosting
School Models
Role of Local Organisers
Other Roles

Past Schools

2004 2005 2006 2007 2008 2009 2010 2011

Diploma at CSC
Sport at CSC
Inverted CSCs

iCSC05 iCSC06 iCSC08 iCSC10 iCSC11

Special schools


Inverted School 2005

CSC 2005

CSC2005 Overview

Practical Information






Examination results
Grants from EU -FP6

Eligibility Conditions

Level of grant support

How to apply
New  Lecture videos
New  Photo-Contest
New  Updated news
New  Social activities



inverted CERN School of Computing 2005 23-25 February 2005, CERN

Programme Overview

Data Management and Data Bases

Advanced Software Development Engineering

Web Services
in Distributed Computing



Lecturer Bios

Printable Version

iCSC2005 Advanced Software Theme

Details of all lectures

An introduction to Entreprise Computing


Thursday 24 February

09:00 - 09:55 Design Block Lecture 1 An introduction to Entreprise Computing Giovanni Chierico

The objective of this lecture is to introduce the principles of Enterprise Computing and o describe the major challenges


  • Definition of EC

  • Common multitiered architecture

  • Parallels with MVC

Common EC Problems & Solutions

  • Naming Services / Directories

    • Deployment schemas

  • Caching

  • Pooling

  • Messaging

    • Asynchronous

    • Synchronous

  • Transaction Management

    • Optimistic

    • Distributed

Design Patterns


Thursday 24 February

10:05 - 11:00 Design Block

Lecture 2

Design Patterns

Ruben Leivas  Ledo

Brice Copy

Using design patterns is a widely accepted method to improve software development. There are many benefits of the application of patterns claimed in the literature. The most cited claim is that design patterns can provide a common design vocabulary and therefore improve greatly communication between software designers. Most of the claims are supported by experiences reports of practitioners, but there is a lack of quantitative research concerning the actual application of design patterns and about the realization of the claimed benefits. We will explore this information to gain an insight into the differences of software development with and without design patters.

Part 1 by  Ruben Leivas  Ledo

1. Why patterns?
2. Group of Four Taxonomy of Design Patterns

  • Creational Patterns

  • Structural Pattern

  • Behavioral Patterns

3. Classification of Design Patterns

  • What a pattern does (its purpose)

  • What a pattern applies to (its scope)

4. Elements of Design Patters

  • Name

  • Problem

  • Solution

  • Consequences

5. Some interesting examples applied to the real life of programmers

6.- Implementing Design Patterns as Declarative Code Generators

7.- Patterns for Java and Distributed Computing

Part 2: Important Enterprise Patterns by Brice Copy

8.- MVC in Web applications (Struts, Spring MVC)

9.- Inversion of Control, Dependency Injection (Spring)

Security in Computer Applications


Thursday 24 February

11:30 - 12:25 Theory Block

Lecture 3

Security in Computer Applications

Sebastian Lopienski

The lecture will address the following issues:

  • how to think of about security, how to design a secure computer system, and how to implement it

  • what are the common errors, pitfalls, bugs and traps while implementing, what are common ways for attackers to exploit some code,

  • how to make a good use of cryptography (which algorithms to use, length of keys, validity of certificates etc.),

  • threats appearing on the human-machine (or human-application) interface, and threats coming from dishonest users

  • many real-life examples of good security, poor security, misunderstood security and security which in fact makes things less secure

1. Introduction:
• What is security in computer world
• Dangerous times
• Types of dangers
• Is it an issue for average software developer (at CERN)?
2. Getting secure
• Prevention, detection and counteraction
• Why security is difficult to achieve
• General rules: simplicity, modularity etc.
• What about security by obscurity?
• Bugs, flaws, vulnerabilities
3. Architecture and design
• Advantages of modularity
• Security of the whole system is only as strong as its weakest element
• Least privilege principle
• Other design principles
4. Coding (introduction)
• Readable and understandable code
5. Enemy number one: input data
• Strings and buffer overflow issue
• Canonical representation problems
• Command-line arguments
• Data
• External code
6. Common problems, pitfalls, traps while implementing
• Using temporary files
• Working on files
• Environment variables and settings
• Parallel or non-atomic execution
• Hardcoding passwords
• SUID/SGID programs
7. Coding - advices
• Deal with error / Catch exceptions
• Assertions
• Logging
• Dumping core/leaving debug information
• Optimizing code
• Network programs
8. After implementation
• Reviewing, testing
• Open source vs. proprietary solutions
• Tools
9. Identification, authentication, authorization
• Authentication with something you know, something you have, something you are (or a combination)
• Passwords
• ACLs
10. Cryptography - practical review
• Encryption (symmetric and asymmetric algorithms)
• Hash functions and MAC
• Cryptography in network protocols (ex.: SSL)
11. How cryptography can help
• A lock in a door
• keys: confidential, algorithm: public
• Don’t implement cryptographic algorithms
• Encrypted = secure ?
• Key lengths
12. Other interesting techniques
• Steganography
• Port knocking
• etc.
13. Social engineering risks
• Phishing, hoaxes etc.
• How can we help users (education, restrictive software, clear design)
• Password policy
14. Summary
• What is the main message?
• Future readings (at the lecture's web page)
• Questions?

Change Control: Iterative Development /  Advanced CVS


Thursday 24 February

14:00 - 14:55 Integration Block

Lecture 4




Change Control: Iterative Development /  Advanced CVS

Brice Copy

Sebastian Lopienski

This lecture is formed of two parts. In the first one, Brice Copy presents the principles of  Iterative Development, why it was introduced, where it is used and what the various components are. In the second part, Sebastian Lopienski, after a setting the scene, presents the latest development of CVS, advices about common problems and pitfalls, suggest ways to use it and compare it to other similar tools.

Part 1 by Brice Copy

What Is Iterative Development ?
— As opposed to monolithic approaches (cascade model)
— Perform full, fast and complete development cycles (spec, code, build, integrate, test and back again)
— In line with modern risk management techniques
— Enables you to cope with changing requirements
Why Iterative Development Was Introduced
— Cascade development too cumbersome
— Full development cycles lets your team members (Dev, QA, System) work in parallel
Where Is It Used
— Microsoft
— Oracle
Ingredients List
— Source control management (SCM) system
— Somebody to write requirement and design specifications
— An eager team of developers ready to work in parallel
— Quality Assurance people
— An integrated build tool (your Swiss army knife)
Integrated Build Tool
— Code generation
— Metadata attributes
— Remote invocations stubs (Web services, RMI etc...)
— ORM mapping files
— SCM integration (CVS, Perforce, SourceSafe? etc...)
— Code compilation (from various sources to various targets)
— Functional and regression testing
— Packaging
— JAR/WAR/EAR files
Integrated Build Tool (2)
— Deployment as a named deliverable
— Web Application Server
— Middle tier server
— Shared library repository
— Integration testing
— In Container testing
— ?
— Documentation generation
— Javadoc
— Cross Referenced Code
— UML Documentations
— Specification in various formats (XDoc, PDF etc...)
— Reporting
— SCM activity
— Coding standards
— Testing coverage
— Dependency convergence
Apache Ant
— All of the above plus more
— Not Java specific, but well err..
— Easy to extend through Ant Tasks
— Somewhat low level
Apache Maven
— A layer wrapping Ant
— Your project is seen as a high level object
— Properties
— Named dependencies
— Deliverable
— Deployment locations
— Sub projects
— Your project must follow a certain structure
— Really aimed at Java projects
Automated Build Tools
— Cruise Control
— Damage Control

Part 2 by Sebastian Lopienski

Objectives of the presentation
• Basic and not so basic but still useful functionality of CVS (including branching, merging, tagging, watching etc.)
• Demystify the vocabulary (repository, revision, tag, attic, karma etc.)
• Present available clients (command line clients, GUIs and IDE integrated clients) for both Unix-like and Windows platforms
• Present others tool for CVS (Web interfaces etc.)
• Show some good (and also bad) CVS users' habits
• warn about some common problems and pitfalls
• Discuss access control in CVS and security issues
• Suggest ways to use CVS in build process
• Mention other revision control systems like SourceSafe, Subversion etc.
• Collect and present links to books, tutorials etc.
• Prepare some exercises to be downloaded and run for further studies.

Debugging Techniques



Friday 25 February

15:05 - 16:20 Maintenance Block

Lecture 5

Debugging Techniques

Paolo Adragna
The lecture addresses the problem of eliminate bugs from software. It is targeted on programmers who develop software on Unix-like platform using C/C++ language, but a large part of the content is general purpose and can be exploited also in a different context (platform or language).
Introduction and general comments about debugging
In the introduction the general background required by debugging is reviewed
1) Noting and localizing a bug
2) Classifying a bug
3) Understanding a bug
4) Repairing a bug

Part one - General debugging
The first part of the lecture presents advices for general purpose debugging
1) Exploiting compiler feature: static analysis, warning option, optimization flag
2) Reading the right documentation
3) The abused cout debugging technique: general description, disadvantages.
4) Defensive programming and the assert macro (as a solution of cout technique)
5) The debugger. The example of gdb/ddd.
6) ANWB debugging technique: not really a technique actually, rather a method to flush out bugs
7) Code walkthrough: really an advice (possibly a citation of Gerhard's lecture)

Part two - C/C++-generated problems and tools to solve them
The second part addresses problems usually generated by C/C++ programming
1) Preprocessor: problems with versions, headers
2) System dependency
3) System call examination and interaction with the system: the example of strace
5) Dynamic storage allocation: general description of the problem.


Exploitable tools: libraries (to be linked) or external programs


Libraries: MEMWATCH, Electric Fence (with examples)


Executables: YAMD, Valgrind (with examples)


6) Incremental building: description of the problem and citation of make

Code Reviews: Best Practices



Friday 25 February

15:20 - 16:00 Maintenance Block

Lecture 6

Code Reviews: Best Practices

Gerhard Brandt
This lecture addresses the following questions
— How to write code that's readable and understandable ?
— Which tools can you use to make this easier ?
— How to understand already existing code ?
Starting points for this lecture:
Other people have engineered code for you.
— It's your honor to adjust this code where it shows
suboptimal behaviour ( = fix bugs )
— You learn from their ingeniosity and apply your experience
as you and others contribute new code
1 Reading existing code
2 Adding new code

Part 1: Reading Code
Approaching a foreign body of code top-down:
Read it in increasing level of detail
— Read File/Directory Structure
— Recognize Structures
(like Design Patterns, Interfaces, Libraries, makefiles)
— Details
stay on top - dive only as required!
( = don't try to read 100k lines of code from the beginning to the end )
* High-level Orientation in an unknown body of code
— Command line tools
— Code Browsing
— Documentation and its Generation
* Use the command line, like: Simple heuristics
* cvs: Watch what happens during checkout
* ls: directory structure
* wc: size

* Code Signatures
— Condense code to structural elements: {} , ;
— ref: Cunningham W., OOPSLA 2001 Software Archeology Workshop
* Code Browsing:
* ViewCVS
— Real-time access to CVS
— View Changes, Diffs, Tags, ... immediately
* LXR - Linux Cross Reference
— Perl script that generates xref'ed source code in HTML from C++
— Not real-time on CVS - rerun by webserver about once a day
* IDEs
* Generating documentation from code
— javadoc type tools
— javadoc:
— by Sun for Java
— enriched comments
— many different tools - incompatible formats
* ROOT Thtml
— Used with ROOT based applications (eg. H1OO?)
— Classes to be documented must be included in ROOT
(ClassDef?, ClassImp? Macros)
— Need code that sees ALL classes to generate complete documentation
(eg. executable that links everything)
— Non C++ Files not documented
— Bugs (eg. inline functions don't work correctly)
— Unofficial outlook: THtml2
— ROOT team choice: rewrite doc tool from scratch, incl. C++ parser etc.
— more features: more output formats, code browsing from CINT cmdline, ...
* Doxygen
— popular
— good results for un-enriched code
— too many bells and whistles?
* dot
— Graph generation tool from BellLabs?
– graphical representation of code structure
— simple syntax
— used by Doxygen for its graphs
* Noticing Structures:
* What to notice
* Used Coding Standard
— Notation for type and scope?
— Layout?
— (Rich) comments?
* Design Patterns
— example: Singleton
* Framework Facilities
— example: messages/error logging
— often old/suboptimal solution
* What to skip
* Headers, Initialization
* find point of entry
* How to navigate
* searching
* regexps to reckognize
* grep
* ctags
Part 2: Writing new code
— Checking Contributions by others
— Writing it yourself
* Checking Contributions
* cvs diff
* Program Syntax Checker
* compile it
* lint
* test suite
* junit, cppunit
— junit Covered in CSC
— Available in other languages: C++ cppunit
— Assert Macros
— normally used for test driven development
-> not identical to correctness checking
* Handwritten test suite
— Example H1OO? - H1 Fast Validation
— Check code based on changes in physics variables
— Compare set of observables from identical data
but reconstructed from two different releases
— Differences must make sense from physics POV
-> if not, infer indirectly to problems in the code
— Very simple implementation, great success for our purposes
* Layout
— Coding Standards
* Enforcing Coding standards: Code Beautifiers
* indent
* Jalopy (a java code beautifier)
* More
* Code analyzers PMD (Java)
Testing coverage reports (Clover, JBlanket)
* Summary
* Outlook
— Graphical Programming
— code browsers
— Spinellis D., Code Reading, Addison Wesley 2003
— McConnell? s., Code Complete, Microsoft Press, 2nd Ed 2004
— ... Test Driven Development



All on iCSCs



Data Theme






All lectures

Soft Theme







All lectures

WS Theme




All lectures

Exercises New
Social Events


Feedback: Computing (dot) School (at) cern (dot) ch
Last update: Thursday, 14. November 2013 11:48

Copyright CERN