itech9

From http://justaddwater.dk/2008/04/29/how-to-make-a-dry-run-with-svn-update/

svn merge –dry-run -r BASE:HEAD .

Also:

svn status -u

This command will not show conflicts .

From http://techinterviewcoach.com/blog/?p=30#more-30

• Hash tables are backed by arrays.
• A hash function is used to map the keys to an index within the backing array.
• Put, Get, Delete operations all run in constant ( O(1) ) time.
• Hash function determines performance.
• Even with the best hash function, collisions can occur.
• Main advantage of HTs over other data structures is speed.
• Growing HTs need to be rehashed but the cost is amortized by constant cost of ‘put’.
• Should not use HTs for small data sets, but everybody does.
• Rehashing should occur when the load factor (occupied array slots / array size) reaches over .75.

• – SOA - Service Oriented Architecture
  – 3 major roles: Provider, Registry (Broker) and Requester.
  – SOA is based on web services.
• – SOAP - Simple Object Access Protocol
  – 2 major methods: Message-based Document Exchange AND RPC
  (Remote Procedure Calls).
  – All structures based on XML.
  – A SOAP message contains an Envelope and a Header.
  – A SOAP message may contain (MIME) attachments.
  – Main transport protocol is HTTP(S).
  – Providers (Receivers) are usually based on Servlets.
• – SOAP-RPC
  – Method signatures contain a single SOAP structure.
  – SOAP service methods must match info in deployment descriptor.
  – Errors and Faults: VersionMismatch, MustUnderstand, DTDNotSupported, etc..
• – WSDL - Web Services Description Language
  – WSDL is an XML grammar for describing a web service
  as a collection of access end-points capable of exchanging
  messages in a procedure- or document-oriented fashion (p. 72)
  – The reasonable flow is to create service methods and
  than generate WSDL from code using tools.
  – Best practices: web service is (functionally) coarse-grained
  and messages are more business-oriented than programmatic.
• – UDDI - Universal Description, Discovery and Integration
  – Similar to an Internet search engine for businesses.
  – UBR - UDDI Business Registry (the Public Cloud).
  – Designed for B2B mostly.
  – 2 APIs: inquiry and publishing API.
  – JAXR = Java API for XML Registries.
  – Some details: Categorization (NAICS, ISO, etc..),
  Identifier (DUNS, Thomas Reg, etc),
  tModel (web service metadata)
• – JAX-RPC and JAXM
  – JAXM = Java API for XML Messaging.
  – JAX-RPC = Java API for XML-based RPC.
  – JAXM may be used as a frontend to SOAP-based messaging
  frameworks through the use of “profiles”.
  – JAX-RPC covers code generation for client and server parts,
  dynamic SOAP, creating services within J2EE and J2SE environments,
  bindings, serialization, mapping of datatypes between WSDL and Java,
  etc..
• – The Java Web Service (JWS) Standard
  – Proposed by BEA, using templates to create simple web services.
  – Example (HelloWorld.jws <- note the .jws extension)
  Note the annotations @operation, @conversation ..

  import com.bea.jws.*
  
  public class HelloWorld extends Service {
    /**
    * @operation
    * @conversation stateless
    */
    public String getHelloWorld() {
      return "Hello, World!";
    }
  }
  

  Other values for @conversation are ’start’, ‘continue’ or
  ‘finish’. The ’start’ directive, for example, starts a session.

• – Security notes
  – Use of SSL (HTTPS), encryption, signing and secure hashing.
  – Security Assertion Markup Language (SAML) - used with Single Sign-On (SSO).
• – Resources
  http://aws.amazon.com/
  http://seekda.com/
  http://www.programmableweb.com/
  http://www.webservices.org/
  http://xmethods.com/

Colophon - European (Alpine) Ibex - a wild goat.

Great introductory article on Eclipse UML Tools

http://www.vogella.de/articles/UML/article.html#uml

Table of Contents

1. UML

    1.1. Overview
    1.2. Definition
    1.3. UML Profiles

2. Installation of Eclipse UML2 Tools
3. Eclipse UML2 Tools

    3.1. Creating UML Diagrams
    3.2. Multiplicity
    3.3. Interfaces
    3.4. Viewing the .uml file

4. Thank you
5. Questions and Discussion
6. Appendix: Class diagrams

    6.1. Overview
    6.2. Classes
    6.3. Attributes
    6.4. Interfaces
    6.5. Relationships

7. Appendix: Model-Driven Architecture (MDA)

    7.1. Overview
    7.2. Platform Independent Model (PIM)
    7.3. Platform Specific Model (PSM)
    7.4. Code Mode

8. Links and Literature

For reverse engineering, see “MoDisco” (Model Discovery)

http://www.eclipse.org/gmt/modisco/

For building UML models from legacy packages, here are some
tips:

http://dev.eclipse.org/newslists/news.eclipse.modeling.gmt.modisco/msg00055.html

...
- the first one builds a Java Abstract Syntax model (based on the JDT Java API) from a Java
compilation unit, this Java model may be then transformed into a UML2 model using an ATL
model-to-model transformation (http://www.eclipse.org/m2m/atl/);
- the second one builds a UML2 model from a Jar file.

To check for cvs with pserver configuration:

• - Check that xinetd is installed
• - Check file /etc/xinetd.d/cvspserver
  It should look like this:

  service cvspserver
  {
  port = 2401
  socket_type = stream
  protocol = tcp
  wait = no
  user = root
  passenv = PATH
  server = /usr/local/bin/cvs
  server_args = -f –allow-root=/opt/cvs pserver
  }

• - Check that cvsnt is where the xinetd file (above) says it is
  (/usr/local/bin/cvs in this example)
• - Check the cvs path (/opt/cvs in this example)
• $ telnet cvsserver 2401 (or whatever port is specified in /etc/xinet.d/cvspserver file)
• - Check the cvs passwd file in /opt/cvs/cvsroot folder.
  It should have an entry for the user.
• - If the user is not in the cvs passwd file (in example: /opt/cvs/cvsroot/passwd)
  add the user with:

  $ cvs passwd -a user (it will ask for a password)

See http://devguy.com/fp/cfgmgmt/cvs/cvs_admin_nt.htm#pserver for more info.

Finally! A methodology that makes sense to me!

http://www.extremeprogramming.org/

Basic rules:

* Make frequent small releases.

* The project is divided into iterations.

* Move people around.

* No functionality is added early.

* Refactor whenever and wherever possible.

* The customer is always available.

* Write/Code the unit test first (with stubs).

* Integrate often.

* Leave optimization till last.

* All code must have and must pass unit tests.

* When a bug is found, unit tests are created.

* No overtime.

* Code must be written to agreed standards.

• – Inheritance from anything (including abstract)
  should be a function of the business model.
• – If a class does not _really_ inherit from
  an abstract, one should not use it.
• – Use interface to avoid the problem of multiple
  inheritance.
• – Use interface to improve modularity.. if one
  uses an abstract class and the class changes,
  it may break subclasses.
  (not method signatures but logic/code.. changing
  method signatures is a problem for both abstract
  and interface)
• – Use interfaces when some part of the design
  will change frequently.
• – Interface for plug-in architectures - like
  the strategy pattern.
• – Use abstract class to provide basic services
  for derived classes (event, message handling)
• – In favor of abstract class:
  • – interfaces may be more difficult to read in
    code logic.
  • – interfaces are somewhat slower due to
    indirections.