Heartbreaker

My wife and I have decided to sell off one of our small side businesses. The effort is too great with our full time careers. This site would make a nice part time job for somebody. The potential is far greater for the right person.

Candles and Accessories Web Site for Sale

http://www.sitepoint.com/marketplace/auction/642

Good Article

I am literally weeks behind on my Blog. I have nearly one dozen items I am working on that I have not posted yet. But today I ran across an article I had tagged and almost neglected to read.

I was impressed with this article. Not only because it bestows the values I believe an organization should genuinely hold and suport, but because it comes from one with a very impressive track record. A man, who for all practical purpose, had no reason to doubt his ways.

http://www.fastcompany.com/magazine/02/meyerson.html

AD World - Day 2

Update on Unified Process
"Idea that each team should follow the same process is a great theory, but is impossible in practice. Goal should be to have all teams using similar processes." – presenter’s opinion
"Firehose" Presentation – lots of data fast
Speaker has done the gambit on project management – strict to Agile. Has drafted industry standards.
First public release of RUP was June 1998. Slow activity through late 90s. Much work on application of Agile w/in RUP over past six months.
http://www.enterpriseunifiedprocess.com/essays/history.html
UP is a framework from which system processes are instantiated

Spirit of the UP
· Attack risks early (or they will attack you)
· Deliver value to the customer
· Focus on executable software
· Accommodate change early in the project
· Baseline an executable architecture early on
· Build with components
· Work together as one team
· Communicate early and often
· Make quality a way of life
There will be a new version of RUP released later this year

RUP Universal Principles
· Adapt the process
· Balance stakeholder priorities
· Collaborate across teams
· Demonstrate value interactively
· Elevate the level of abstraction
· Focus continuously on Quality

LOOK AT AGILE 2.0
Working with Legacy Code – book on evolving legacy systems over time
Refactoring Databases – book on improving legacy database schemas
RUP original six best practices are now encompassed w/in the Universal Principles
http://www-128.ibm.com/developerworks/rational/library/5823.html - Extending the RUP
Eclipse Process Framework – www.eclipse.org/epf
OpenUP
open source version of UP. Modification of RUP material. Brief description of RUP (overview). Easy to use and available for free. Anybody can use it. Currently in BETA. "looks like crap – user interface challenges"
A Method Framework is a framework based on a common set of principles.
RUP – gives you everything and you choose what you need
OpenUP – gives you the base and you can add on what you need

Agile UP (AUP) – worth looking at
"The only true measure of progress in a software development project is working software"

Essential UP (Ess UP) – worth looking at
www.ivarjacobson.com
Lightweight
Agile
Freely available
Easy to use
Open source process
Only the "essential" practices
Agile 2.0 process

Enterprise Unified Process – wraps UP into a wider scope process that includes support and enterprise concerns. Change management, project management, operations, support, Portfolio Management, Strategic reuse, People Management, Enterprise Admin, Software Process Improvement, etc.
"Architect also codes" – speaker is a firm believer in this pattern – you need to be involved with the team.
Developers will not read white papers and look at models. Developers will download code. Model your designs in code for developers to use. Make sure examples are high quality. Developers do not respect architects who do not write code.
Speaker believes the industry suffers from too much theory and not enough reality. Discuss how it "should" be done, but do not observe how it is actually done. Example – how many books are there on how to model on paper and white boards? The books are on how to model using tools.

Strategic Reuse – almost always fails. You need to have a reuse plan and encourage it. Charge-back plans for reuse will kill the effort (if one department/team uses components/service from other teams, the developer team charges the consumer internal funny money). Monitor what your teams are doing and when something looks like it could be made reusable, do so. Do not design with the intent of reuse in mind; distracts from the project needs.

Agile UP is the lightest of the options
EAP is the heaviest

AUP and Open UP are emerging – gaining acceptance and support

Suggests we take Open UP seriously – main editing tool is eclipse, but it is NOT eclipse specific

US Department of Defense has belief that all processes can be broken down into granular repeatable steps. US Department of Defense is statistically one of the least successful software development team anywhere.

Scott W. Ambler
www.ambysoft.com/scottAmbler.html
www.agiledata.org/feedback.html
www.agilemodeling.com/feedback.html

---

Architect Soup - EA, SOA, EDA, SCA, MDA
Mike Rosen – architect for ~15 years
EA – enterprise architecture
SOA – service oriented
EDA – Enterprise Driven
SCA – Service Component
MDA – Model Driven

Enterprise Architecture
About enabling and managing change
Goal is to align IT systems with business goals and strategy

Secondary goals

• Reduce IT expenditures
• Run IT as a business
• Support portfolio management
• Support outsourcing
• Provide governance framework
• Enable SOA

Zachman
Usually implemented with a framework – Zachman is most commonly implemented.
"Technology is not the solution to IT problems, Architecture is." - Zachman
States Zachman is a great way to start, but it is not a THE solution

Federal Enterprise Architecture Framework
Implemented by US Federal Government

Service Oriented Architecture
Most SOA definitions are technology focused, but only address a small part of SOA
Web Services are a good technology for implementing SOA, but not the only. Can use CORBA, Java, .NET
NOT new – CORBA and Tuxedo have been successfully used tools. Many other attempts failed.
Web Services are not SOA
Architecture commonly fails at the delivery of standards and architecture to the developers. Drafting a white paper and other documentation is not as affective as delivering samples and templates.

Event-Driven Architecture
Any app that reacts intelligently to changes in the environmental conditions – failure on a hard drive, sudden change in sales demand
Publish/Subscribe services (Event Management)
Event/Sponsor/Response systems
Applications constructed entirely from "state machine" modules
One where we think about communication between different parts of a business in terms of the occurrence of an event
Workflow needs to be addressed as part of the architecture.

Service Component Architecture
Doesn’t see this getting much traction

Model Based Development
Major initiative from Microsoft and IBM

A side effect of UML Standardization

Create models at business, application, and implementation levels. Write code to support all views of the model.

Model - is a representation of the system
Formal model - is a model that applies to stringent rules.
Model Compiler – can take a formal model and produce transformational output

MDA tools/compilers can generate code for us

Challenge with test generation tools for MDA is they generate TOO Many tests – not all are necessary, but tools can’t discern value of the tests.

Theoretically, models allows you to not be concerned with technology changes. For example, move from .NET 1.1 to 2.0 would be "easy" – build new code base from models for the new platform and you are done.

---

Introduction to UML

Ok. You might ask why I took this class. First of all, it is immediately after lunch and I am tired; not sure I could take on another heady subject. Secondarily, although I use UML fairly regularly, I’ve never taken a course or read a book on it. I thought maybe I should.

UML is the standard language for visualizing, specifying, construction and documenting the artifacts of a system

http://www.omg.org/ – can download UML from site

The importance of modeling

• Smaller projects may not require modeling
• easy to build a dog house
• Larger projects require modeling
• Difficult to build a two-story, five bedroom colonial
• Very difficult to build an office complex

Why we model

• Communication
• Manage complexity
• Makes people think
• To help understand requirements
• To drive implementation
• To understand the impact of change
• To ensure resources are deployed efficiently

Activity Diagrams

• Is a flow chart
• Used to show flow of control
• Usually used early on in the process
• Good for business rules
• Flow within a use case
• UML 2.0 allows for the interruption of an activity

Use Case Diagrams

• Visualization between use cases and actors
• Start with Actors
• Someone or some thing that must interact with the system under development
• Rendered as a stick person (usually)
• Use Cases
• Why the actor wants to use the system
• A pattern of behavior the system exhibits
• “A sequence of functions where the outcome makes the actor happy”
• Interaction with an ATM is likely one use case
• Deposit, withdrawal, transfer, balance inquiry all one use case
• Use case diagrams can have includes and extends
• Includes – one use case or piece of a use case includes another
• Make reservation includes search for flight
• Extends – one use case or piece can be extended by another
• Select seating location extends Make reservation
• Do not overuse these
• Can lead to functional decomposition
• If not sure, create separate use cases
• Nothing new in UML 2.0

Interaction Diagrams

Show dynamics of the system

Show communication between things

Includes Sequence Diagrams

Sequence Diagrams

• Should show distribution of behavior between objects
• Should not have a lot of sequences pointing to one object
• Can get large very fast
• Does not represent conditionals very well (if, then, else)
• Addition of frames allows me to make composite diagrams – one sequence diagram can include another by reference
• Looping and Breaking are now represented well (better)
• Negatives, assertions, and critical regions are available

Communication Diagrams – changed in 2.0 – was called something else

Timing Diagrams – added in 2.0

Interaction overview diagram – flow between interactions. Could be represented by activity and sequence diagrams. Not sure they are needed….

Class diagrams – show static structure

• Collection of objects
• Want to have standards for naming of classes
• Classes should have all operations
• Look at sequence diagrams to determine required operations
• Known operations not in a sequence diagram = missing sequence diagram
• Classes have attributes
• Classes have relationships
• Not required, but a system with classes and no relationships is not possible
• Association, aggregation, composition, dependency
• Model all as association first
• Relationships are discovered by examining interaction diagrams
• Multiplicity
• How many objects participate in a relationship
• One to one
• One to many
• One to zero or more
• Etc.
• Navigation
• Indicates directionality of communication
• Arrow states uni-directional
• Want to have as many as you can uni-directional
• Inheritance
• Relationship between class and subclass
• Realization
• No change in UML 2.0

Composite Structure Diagrams – new in 2.0

State Diagrams

• Shows life history of a given class
• For objects with significant dynamic behavior

Component Diagrams

• Components can be logical or physical
• UML 2.0 – components can have ports and notation has changed

Artifacts are new to UML 2.0 – represents a physical entity

UML Extension

• You can extend the UML for things like Databases, business processes, web pages, etc.
• Stereotype

Martin Fowlers UML books are good

Scott Amblers process books are good

Has heard UML 2.0 in a nutshell is good – not fond of UML 2.0 for dummies

AD World - Day 1

Registration
Ok, registration actually took place yesterday. We arrived early and decided to go ahead and pre-register to make things easier on ourselves.

Talk about easy... they did not ask for any form of ID. We walked up to the counter, looked down at the name tags all layed out and easy to read, said a name, and were handed a lanyard, badge, bag, shirt, and CDs. No questions asked. Nothing to sign.

Not a great first impression.

Designing Service Oriented Applications
Service Oriented Architecture

SOA History
CORBA, Tuxedo – prior platforms/tools that SOA has been implemented in. Many other attempts with other tools (and these) failed.

Case Study (loose)
Created a group called the Business Objects Service Group and they were assigned the task of creating reusable services. Service talented developers were put into BOSG. Other (front-end) developers placed in business units to create apps that consume services.

Separation of Function from Interface put the company at a competitive advantage – able to react to change in the market place much faster (took time to build library of services) Doesn’t happen overnight.

System developed in CORBA – now in EJB. Handles 2 Billion transactions/month


Proper architecture requires more than one architectural view
Make it easy to enable the developers to build applications that follow the architectural standards

SOA is concerned with the independent construction of services that can be combined together

Service – encapsulates a unit of work, made available through a service contract
Dynamic Binding, Loose Coupling, Modular and self contained, composable

BPEL – Business Process Execution Language – used inside a business service; usually provided by the technology platform

Business Process Level (BPM) – manage process; checkpoint, auditing, security, etc. also determine sequence/series of services changed together to achieve a need

Salesforce.com, eBay, Amazon, WebSuite – provide third party Web services

Majority of corporate expenditure for application development is on Maintenance. Next highest number is on Integration. Last is on New development.

Coupling
Loose Coupling – Want to make it possible for the creator of the service to make adjustments without requiring the consumer to alter their use of the service. Decouple the life cycle of the consumer from the life cycle of the provider.

Synchronous vs. Asynchronous – not really significant in SOA. These terms are more specific to the requirements of the system, but not specific to SOA and decoupling. Most SOA implementations will use both.

Interface and Implementation – allows a service to change without requiring changes of the service consumers. Important in an SOA architecture. SOA ensures the interface contract is the ONLY means of interaction.

Publication, Discovery and Binding
Registry exists as a broker
Service is published as a service definition to the Registry
Service Provider registers as a provider of an implementation
Consumer requests a service from the registry
Registry makes a decision and provides “handle” to the service.
Consumer then connects to service

SOA integration
Integrate Once, use many, consistent access, lower total cost
Adaptable to change
Incremental approach – start small, add new integration services over time as part of specific projects
Flexibility increases with each new service

SOA and Web Services by Eric Newcommer – “Not a bad book” – decent book RE: Web services, but weak regarding SOA overall.

Best Practices in SOA Development

MDA Overview

Model Driven Architecture

Business Model -> Application Model -> Implementation Model -> Code

Model – a representation of the system. A model describes part of the function, structure and/or behavior of a system.

Formal Model – a representation of the system conforming to rigorous rules All Model Based Development models are formal

Model should be platform independent – independent of the language/technology used to build it. Also independent of any hardware.

PSM – platform specific

PIM – Platform independent

Tools exist that can generate code based on well defined models. Use of these tools is convenient and saves cost, but regardless, the process of building models accurately (theoretically) makes app dev/maintenance easier and more flexible.

Applying MDA to SOA
More SOA app initiatives are bottom up rather than top down. Top Down is based on a Business Process Model. Bottom Up is trying to leverage an existing service or service enable legacy systems. Best approach is “middle out”

Process Overview
· Understand Use Cases – not too detailed
· Specify Scenarios – show flow of use cases with actors
· Design/Align Information Model
· Understand Overall Context
· Look for appropriate patterns
· Identify Service and Interface Style
· Define Documents
· Define Service Implementation
· Look for appropriate patterns
· Information Transformation follows data flow

SOA should implement the most important things first; shared information and shared functions.




Threat Modeling: Creating Secure Applications
Agenda is based on two books:
Writing Secure Code and Threat Modeling

Threat Modeling (book) – good place to start, but getting long in the tooth. Great if you are just getting started.

void main() {
char buf[512];
gets(buf);
}

The above is vulnerable to a buffer overflow.

Java Principle – As you work on an application, it gets better and better.
This is a fallacy. The likelihood of bugs is no more or less with each release.

“Security is all about data. Attacks are via data. What they are looking for is data.” therefore
“The ultimate safe program is one that takes in no data and produces no results.”

What are threat personas?
A systems’ anti-users
- based on real-world data. There are five behaviors and eight actual personas

“One person’s feature is another person’s exploit”

Author
Vandal – Curiosity; usually script kiddie
Trespasser – after personal fame – want to make a mark and get credit for it - usually hobbyist/hacker
Personal Gain – Thief – actually after the data to take advantage of it – usually hobbyist, but many expert
National Interest – spy – experts and specialists

Some Important Definitions
Threat Agents – someone who could do harm to a system (adversary)
Threat – An adversary’s goal
Threat Tree – A graphical representation of security-relevant pre-conditions in a system
Vulnerability – a flaw in the system that could be exploited
Asset – Something of value to the valid users and adversaries alike
Attack – When a motivated and sufficiently skilled threat agent takes advantage of a vulnerability

Threat Model – describes a system’s threat profile

Classic Threat Modeling
Collect Background Information -> Model the System -> Determine Threats

Collect Background Information
Identify Scenarios
how the system is intended to be used (or not intended) in deployment
Help us understand what was considered in security model in the first place
Identify External Dependencies
Dependencies / requirements outside of our system/model
Implementation Assumptions
Assumptions should be validated on completion of implementation
Identify external security notes
Counterpart to external dependencies
Identify internal security notes
Makes model more clear
Explain tradeoff made in design or implementation of the system that affect security

Model the System
Modeling is critical to determining threats; helps us understand adversary’s view of the system; helps team understand internal workings
Identify Entry Points
Define the boundaries of the system being modeled
List all places where the system consumes or provides data including actions on behalf of third parties
Often obvious, but may not be. Reading files from the system is an entry point.
Identify Assets
Those things (concrete and abstract) that could be targets of an attack by an adversary
Assets should be nouns
Assets can be widely varies; data in a database, network coherency on a peer to peer application
Identify Trust Levels
Have preconditions (authentication)
Trust levels characterize either entry points or assets
Trust level specific to the entry point of asset
Create flow diagrams / process models
Describe processing on the threat path
Threat Path is the processing that occurs based on the input to the enumerated entry points
Follow the processing from entry point – determine what it does (or can do to data)
Create Data Flow Diagrams
Context Diagram
Keep modeling until there are no more multi-processes
Building a DFD
Identify the actors and where data moves in and out
Break-down HOW data moves in and out
Keep these at the high level

Determine Threats
Enumerate threats – creates a threat profile
Threats with valid attack paths are vulnerabilities
Threats are verbs

STRIDE – types of threats to a system (all known threats to date fall into these types)
Spoofing – pose as another user
Tampering – modification of data
Repudiation – deniability of malicious acts
Information (disclosure)
Denial of Service
Elevation of Privilege



DREAD – means of characterizing the risk associated with a vulnerability
Damage Potential – extent of possible damage
Reproducibility – how easy is it repeat the attack with success
Exploitability – Effort required to execute the attack in the first place
Affected Users –ratio of installed instances affected is exploit is widely available
Discoverability – how likely the unpatched exploit is to be found by others

CIA – Confidentiality / Integrity / Availability

Threat models should include review from outside parties.

Conclusion

So far, so good. The SOA class was too slow to start and too quick at the end. Bored me and then lost me. Security course was very good. Lots of useful tools and examples. Nice exercise. I'm definitely growing more and more interested in this aspect of our field....

Writing Secure Code - Authentication

There are numerous authentication mechanisms to choose from. If not correctly selected and implemented, the authentication mechanism can expose vulnerabilities that attackers can use to gain access to your system.

Vulnerabilities
Network Eavesdropping
If authentication credentials are passed in plaintext, an attacker armed with basic network monitoring software on a host on the same network can capture traffic and obtain user names and passwords.
Note: This type of attack implies the network has already been compromised.

Brute Force Attacks
Brute force attacks rely on computational power to crack hashed passwords or other secrets secured with hashing and encryption. Brute force attacks typically involve trying to work through all possible key combinations to decrypt a string and are, therefore, difficult to accomplish.

Dictionary Attacks
This attack is used to obtain passwords held as hashes. On such systems, users are authenticated by re-computing the hash based on the user-supplied password value and comparing it against the system-stored hash value. If an attacker manages to obtain the list of hashed passwords, a brute force attack can be used to crack the password hashes.
With the dictionary attack, an attacker uses a program to iterate through all of the words in a dictionary and computes the hash for each word. The resultant hash is compared with values in the data store. Weak passwords such as “Yankees” or “Mustang” will be cracked quickly. Stronger passwords such as “RuN4PhuN”, are less likely to be cracked.

Cookie Replay Attacks
With this type of attack, the attacker captures the user’s authentication cookie using monitoring software and replays it to the application to gain access under a false identity. See Session Hijacking and Replay and Man in the Middle Attacks for more information.

Credential Theft
If your application implements its own user store containing user account names and passwords, compare its security to the credential stores provided by the platform, for example, a Microsoft Active Directory® service user store. Current implementation uses Active Directory® as the user store, but Gemstone should not rely solely on the fortitude of the chosen user store.
Browser history and cache also store user login information for future use. If the terminal is accessed by someone other than the user who logged on, and the same page is hit, the saved login will be available.

Recommendations
· Secure the channel
· Encrypt it
· Strong authentication requirements
· Avoid holding long sessions
· Re-Authenticate

Writing Secure Code - Input Validation

There are a number of attacks an intruder can use that take advantage of the common assumption that data supplied by users while filling out a Web form is safe. Improper checks against data supplied by users can make the site vulnerable to a number of different attacks.


Vulnerabilities


Buffer Overflows


Buffer overflow attacks have been around for decades. A buffer overflow attack can either result in a denial of service or it can cause code injected by the attacker to be run on the server. .NET code is not as susceptible to buffer overflows because the code base is better managed and array bounds are checked before arrays are accessed. Even .NET sites can be susceptible where unmanaged APIs or COM objects are involved.


Cross Site Scripting


In Cross Site Scripting (XSS), an attacker takes advantage of poor handling of data either at entry or display. This technique can be used to gather confidential user information or to impersonate users and achieve access to the Web application with the same rights as the impersonated user. Cross Site Scripting is a technique commonly associated with phishing.


SQL Injection


In SQL Injection, and attacker takes advantage of poorly handled data and weakly constructed queries to a SQL Database. Most commonly, this is on screens where developers are relying on input from the end user to filter or sort data and then the data provided by the end users is not properly validated.


Recommendations


Validate all input all the time


Assume all input is malicious, regardless of source and handle it as such. You can’t be certain that a service, file share, or database you work with has not been compromised. You absolutely can’t be certain that a user is who they claim they are or has good intentions.
Do not assume that data validation only need to take place at a single layer of the application. Verify data at all levels of the application. If any one layer is circumvented or compromised, the remaining layers must perform their due diligence to assure the integrity of the system.


Use common validation routines

Make input validation a core element of your application development strategy. Create shared validation routines for all common routines such as email, zip code, phone numbers, etc. This ensures validation is consistent and makes maintenance much easier.
Be careful about page or module specific validation. Make sure this approach is truly necessary and then attempt to leverage as much of the common routines as possible.


Constrain and sanitize


Constrain
To constrain data is to allow only expected characters or patterns to be submitted. This is commonly accomplished through the application or regular expressions. However it is applied, the idea is to check the data for type, length, format, and range, considering all data that fails to meet the criteria as bad. We would check string patterns and reject any that did not match our specific rules. This not only eliminates errant characters, but further assures the accuracy of the data stored.
In the case of an age field, for example, the length would be at least one and no more than three and only digits would be acceptable. Any string not matching this pattern would be rejected.

/^[0-9]{1,3}$/

An email address would be more complicated. The following pattern is good for most email addresses. It must start with a character, followed by any number of word characters, dots, or hyphens, followed by either a character or digit, followed by “@”, followed by either an IP Address or a character, followed by any series of word characters, dots, or hyphens, followed by either a character or a digit, followed by a dot, and two to four characters.

^[a-zA-Z][\w\.-]*[a-zA-Z0-9]@([0-9]{2,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})([a-zA-Z][\w\.-]*[a-zA-Z0-9]\.[a-zA-Z]{2,4})$

Sanitize
To sanitize data is to transform the data into a safe format. This is different than constraint. In constraint, we do not allow data that does not match our patterns. In sanitization, we alter the data to ensure it is not harmful. This may include stripping nulls or other extended characters from strings or escaping out values so they are treated as literals.
In the simple example shown below, we remove the characters, whereas in actual code, we may choose to replace the characters with displayable representations, such as replacing “<” with “<”.

function RemoveBad(InStr){
InStr = InStr.replace(/\/g,"");
InStr = InStr.replace(/\"/g,"");
InStr = InStr.replace(/\'/g,"");
InStr = InStr.replace(/\%/g,"");
InStr = InStr.replace(/\;/g,"");
InStr = InStr.replace(/\(/g,"");
InStr = InStr.replace(/\)/g,"");
InStr = InStr.replace(/\&/g,"");
InStr = InStr.replace(/\+/g,"");

return InStr;
}

The HTMLEncode method will escape out HTML Characters and the URLEncode method will ensure a URL is a valid URI request. These should be a required part of your standard input/output data handling.


Set the Character Set


If the character set of a page is not explicitly defined, the server is unable to determine which characters are special. This ambiguity can be exploited by hackers because filters for special characters are that much more difficult to create.
Character coding for HTML and HTTP was intended to default to ISO-8859-1, but many browsers did not support this encoding by default. Version 4 of the HTML standard now allows for any character encoding to be used, unless explicitly indicated in the page header.
Recommendation is to set all pages to the same character set, consistent with the server. The following shows a simple example of how to set the character set to ISO-8859-1 in an HTML page. This can be done through a more universal means such as a standard include file for all page headers or use of page templates.

<html>
<head>
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>HTML SAMPLE</title>
</head>
<body>
<p>This is a sample HTML page</p>
</body>
</html>

Wine and Friends

For those of you who know me, you know I am not much of a sophisticate. In fact, I am to sophisticate as Keanu Reeves is to extraordinary thespian. If you don't know any better, you might mistake either of us as our respective pairing.

This past weekend was a wonderful experience for my wife and me. Some friends invited us out to dinner and a wine tasting. Now, as fairly recent graduates from the school of "White Zinfandel is the only wine I know", we were in over our heads. And I was intimidated. We were to meet a third couple for the dinner. Both of the other couples are quite well versed in wines.

We explained very early in the evening that we knew little, if anything, about wine. Once confessed, I felt better. At least I didn't have to pretend. But much to our delight, they were more than happy to help us learn. Through the entire five course meal, they explained the origins of the various wines, the flavors, and the proper pairings with particular foods. They showed us how to take in the boquet, swirl, sample the boquet again, and finally taste.

Of course one evening does not make us experts. This is certainly an area of knowledge where the more you know, the more you realize how little you know. It takes years to develop a proper pallet and decades to become an expert.

But it took only one evening to make good friends.

Zoho Writer

Most of you have heard of Google Spreadsheets. If you haven't, you should certainly check them out. For the Excel officianado (Mr. oz108us, you know who you are), the Google sheets will be nothing but an exercise in frustration and limited functionality. But for us commoners who don't do much beyond keep lists and 0ccassionally SUM() or AVG() a column, they rock! And they are far more affordable than Excel.

Now I've found Zoho Writer. Currently a free service, Zoho Writer allows you to draft documents on-line with nothing but a browser. I took a document I had written in Word, copied and pasted it into Zoho and the content transferred perfectly, formatting, style definitions, and ALL. Very nice.