Getting Started with Oracle Data Provider for .NET (C# Version)

was looking for Oracle C# tutorial and found the official one: 

Time to Complete

Approximately 30 minutes

Overview

In addition to basic Oracle client connectivity software, .NET applications require the use of what is known as a managed data provider (where "managed" refers to code managed by the .NET framework). The data provider is the layer between the .NET application code and the Oracle client connectivity software.

The Oracle Data Provider for .NET (ODP.NET) is Oracle's high performance ADO.NET 2.0 compliant data provider that exposes a complete set of Oracle specific features and tuning options including support for Real Application Clusters, XML DB, and advanced security. It is available for free download from the Oracle Technology Network website.

When ODP.NET and any required Oracle client connectivity software is installed, application development using Visual Studio can begin. It is a good idea to confirm client connectivity before starting development. If you can connect to Oracle using SQL*Plus on the same machine as Visual Studio, then you know that your Oracle client-side software is properly installed and configured.

complet article continues here

Why Waterfall Gurantees Wrong Solution: Project Management

I think this applies for IT jobs where the customers really don't have a good idea of what they want, it doesn't apply to things like compilers or cell phones where the functionality is usually based 95% of what the last version or competitor was. 

It is still good to have a waterfall to have some sort of plan in place that puts some bounds of what is to be done and how it is going to be done. I have seen too many projects use Agile as an excuse to not have a waterfall process or plan at all. 

A Better Project Model than the "Waterfall"

by Jeff Gothelf  |   8:22 AM July 6, 2012

• Comments (302)
•        

This happens every day: A "solution" is handed to a team to build. The team determines the scope of the work, develops a project plan and promises a set of features by a specific date. It is assumed that these features will solve some business problem or meet an executive directive because someone with a paygrade higher than the execution team has blessed the work. And with this set of features and project plan the waterfall cycle begins again.

The team begins to define the work in painstaking detail, outlining every possible scenario, use case, back-end integration point, and business rule. The design team takes it from there, visually articulating the placement of every pixel and the logic behind every input field, check box, and submit button. Soon the software engineers will get their turn at bat followed closely by their compatriots in quality assurance and then, finally, after the t-shirts have been printed and the launch parties have died down, the company's customers will get their first chance to use the new product.

Despite the confidence inspired by all of this upfront planning and design, the only guaranteed thing to come out at the end of this waterfall process is the wrong solution. It's not that the project sponsor chose an inadequate feature set or that the system's user experience was poor. The team delivered the wrong solution because the project was based on unvalidated assumptions. These assumptions were presented as requirements and as such were not positioned as something that could be disproved or even questioned.

article continues here