text:
React has been around for a few years now and there are quite a few tutorials available. Unfortunately, many are outdated, overly complex, or gloss over configuration for getting started. Tutorials which side-step configuration by using jsfiddle or code generator options are great when you're wanting to just focus on the framework features itself, but many tutorials leave beginners struggling to piece things together when you're ready to create a simple react application from scratch. This tutorial is intended to help beginners get up and going with React by manually walking through a minimal setup process.
A Simple Tutorial
This tutorial is merely intended to help walk you through the steps to getting a simple React example up and running. When you're ready to dive into actually learning the React framework, a great list of tutorials can be found here.
There are a several build, transpiler, or bundling tools from which to select when working with React. For this tutorial, we'll be using be using Node, NPM, Webpack, and Babel.
Step 1: Install Node
Download and install Node for your target platform. Node distributions can be obtained here.
Step 2: Create a Project Folder
From a command line prompt, create a folder where you plan to develop your example.
$> mkdir hello-react
Step 3: Initialize Project
Change directory into the example folder and use the Node Package Manager (npm) to initialize the project:
$> cd hello-react $> npm init --yes
This results in the creation of a package.json file. While not technically necessary for this example, creating this file will allow us to persist our packaging and runtime dependencies.
Step 4: Install React
React is broken up into a core framework package and a package related to rendering to the Document Object Model (DOM).
From the hello-react folder, run the following command to install these packages and add them to your package.json file:
$> npm install --save-dev react react-dom
Step 5: Install Babel
Babel is a transpiler, which is to say it's a tool from converting one language or language version to another. In our case, we'll be converting EcmaScript 2015 to EcmaScript 5.
From the hello-react folder, run the following command to install babel:
$> npm install --save-dev babel-core
Step 6: Install Webpack
Webpack is a module bundler. We'll be using it to package all of our scripts into a single script we'll include in our example Web page.
From the hello-react folder, run the following command to install webpack globally:
$> npm install webpack --global
Step 7: Install Babel Loader
Babel loader is a Webpack plugin for using Babel to transpile scripts during the bundling process.
From the hello-react folder, run the following command to install babel loader:
$> npm install --save-dev babel-loader
Step 8: Install Babel Presets
Babel presets are collections of plugins needed to support a given feature. For example, the latest version of babel-preset-es2015 at the time this writing will install 24 plugins which enables Babel to transpile ECMAScript 2015 to ECMAScript 5. We'll be using presets for ES2015 as well as presets for React. The React presets are primarily needed for processing of JSX.
From the hello-react folder, run the following command to install the babel presets for both ES2015 and React:
$> npm install --save-dev babel-preset-es2015 babel-preset-react
Step 9: Configure Babel
In order to tell Babel which presets we want to use when transpiling our scripts, we need to provide a babel config file.
Within the hello-react folder, create a file named .babelrc with the following contents:
{ "presets" : ["es2015", "react"] }
Step 10: Configure Webpack
In order to tell Webpack we want to use Babel, where our entry point module is, and where we want the output bundle to be created, we need to create a Webpack config file.
Within the hello-react folder, create a file named webpack.config.js with the following contents:
const path = require('path'); module.exports = { entry: './app/index.js', output: { path: path.resolve('dist'), filename: 'index_bundle.js' }, module: { rules: [ { test: /\.js$/, loader: 'babel-loader', exclude: /node_modules/ } ] } }
Step 11: Create a React Component
For our example, we'll just be creating a simple component which renders the text "Hello, React!".
First, create an app sub-folder:
$> mkdir app
Next, create a file named app/index.js with the following content:
import React from 'react'; import ReactDOM from 'react-dom'; class HelloWorld extends React.Component { render() { return (
 Hello, React!
 ) } }; ReactDOM.render(<HelloWorld />, document.getElementById('root'));
Briefly, this code includes the react and react-dom modules, defines a HelloWorld class which returns an element containing the text "Hello, React!" expressed using JSX syntax, and finally renders an instance of the HelloWorld element (also using JSX syntax) to the DOM.
If you're completely new to React, don't worry too much about trying to fully understand the code. Once you've completed this tutorial and have an example up and running, you can move on to one of the aforementioned tutorials, or work through React's Hello World example to learn more about the syntax used in this example.
Note: In many examples, you will see the following syntax:
var HelloWorld = React.createClass( { render() { return (
 Hello, React!
 ) } });
This syntax is how classes were defined in older versions of React and will therefore be what you see in older tutorials. As of React version 15.5.0 use of this syntax will produce the following warning:
Warning: HelloWorld: React.createClass is deprecated and will be removed in version 16. Use plain JavaScript classes instead. If you're not yet ready to migrate, create-react-class is available on npm as a drop-in replacement.
Step 12: Create a Webpage
Next, we'll create a simple html file which includes the bundled output defined in step 10 and declare a
 element with the id "root" which is used by our react source in step 11 to render our HelloWorld component.
Within the hello-react folder, create a file named index.html with the following contents:

Step 13: Bundle the Application
To convert our app/index.js source to ECMAScript 5 and bundle it with the react and react-dom modules we've included, we simply need to execute webpack.
Within the hello-react folder, run the following command to create the dist/index_bundle.js file reference by our index.html file:
$> webpack
Step 14: Run the Example
Using a browser, open up the index.html file. If you've followed all the steps correctly, you should see the following text displayed:
Hello, React!
Congratulations! After completing this tutorial, you should have a pretty good idea about the steps involved in getting a basic React app up and going. Hopefully this will save some absolute beginners from spending too much time trying to piece these steps together.
A proposal to use TypeScript was recently made within my development team, so I've taken a bit of time to investigate the platform. This article reflects my thoughts and conclusions on where the platform is at this point.
TypeScript: What is It?
TypeScript is a scripting language created by Microsoft which provides static typing and a class-based object-oriented programming paradigm for transpiling to JavaScript. In contrast to other compile-to-javascript languages such as CoffeeScript and Dart, TypeScript is a superset of JavaScript which means that TypeScript introduces syntax enhancements to the JavaScript language.
Recent Rise In Popularity
TypeScript made it's debut in late 2012 and was first released in April 2014. Community interest has been fairly marginal since it's debut, but has shown an increase since an announcement that the next version of Google's popular Angular framework would be written in TypeScript.
The following Google Trends chart shows the interest parallel between Angular 2 and TypeScript from 2014 to present:
The Good
Type System
TypeScript provides an optional type system which can aid in catching certain types of programing errors at compile time. The information derived from the type system also serves as the foundation for most of the tooling surrounding TypeScript.
The following is a simple example showing a basic usage of the type system:
interface Person { firstName: string; lastName: string; } class Greeter { greeting: string; constructor(message: string) { this.greeting = message; } greet(person: Person) { return this.greeting + " " + person.firstName + " " + person.lastName; } } let greeter = new Greeter("Hello,"); let person = { firstName: "John", lastName: "Doe" }; document.body.innerHTML = greeter.greet(person);
In this example, a Person interface is declared with two string properties: firstName and lastName. Next, a Greeter class is created with a greet() function which is declared to take a parameter of type Person. Next, instances of Greeter and Person are instantiated and the Greeter instance's greet() function is invoked passing in the Person instance. At compile time, TypeScript is able to detect whether the object passed to the greet() function conforms to the Person interface and whether the values assigned to the expected properties are of the expected type.
While the type system and programming paradigm introduced by TypeScript are its key features, it's really the tooling facilitated by the type system that makes the platform shine. Being notified of syntax errors at compile time is helpful, but it's really the productivity that stems from features such as design-time type checking, intellisense/code-completion, and refactoring that make TypeScript compelling.
TypeScript is currently supported by many popular IDEs including Visual Studio, WebStorm, Sublime Text, Brackets, and Eclipse.
EcmaScript Foundation
One of the differentiators of TypeScript from other languages which transpile to JavaScript (CoffeeScript, Dart, etc.) is that TypeScript builds upon the JavaScript language. This means that all valid JavaScript code is valid TypeScript code.
Idiomatic JavaScript Generation
One of the goals of the TypeScript team was to ensure the TypeScript compiler emitted idiomatic JavaScript. This means the code produced by the TypeScript compiler is readable and generally follows normal JavaScript conventions.
The Not So Good
Type Definitions and 3rd-Party Libraries
Moreover, interfaces maintained by 3rd-party sources are somewhat antithetical to their primary purpose. Interfaces should serve as contracts for the behavior of a library. If the interfaces are maintained by a 3rd-party, however, they can't be accurately described as "contracts" since no implicit promise is being made by the library author that the interface being provided accurately matches the library's behavior. It's probably the case that this doesn't prove to be much of an issue in practice, but at minimum I would think relying upon type definitions created by 3rd parties would eventually lead to the available type definitions lagging behind new releases of the libraries being used.
Type System Overhead
Introducing a typesystem is a bit of a double-edged sword. While a type system can provide a lot of benefits, it also adds syntactical overhead to a codebase. In some cases this can result in the code you maintain actually being harder to read and understand than the code being generated. This can be illustrated using Anders Hejlsberg's example presented at Build 2014.
The TypeScript source in the first listing shows a generic sortBy method which takes a callback for retrieving the value by which to sort while the second listing shows the generated JavaScript source:
interface Entity { name: string; } function sortBy(a: T[], keyOf: (item: T) => any): T[] { var result = a.slice(0); result.sort(function(x, y) { var kx = keyOf(x); var ky = keyOf(y); return kx > ky ? 1: kx < ky ? -1 : 0; }); return result; } var products = [ { name: "Lawnmower", price: 395.00, id: 345801 }, { name: "Hammer", price: 5.75, id: 266701 }, { name: "Toaster", price: 19.95, id: 400670 }, { name: "Padlock", price: 4.50, id: 560004 } ]; var sorted = sortBy(products, x => x.price); document.body.innerText = JSON.stringify(sorted, null, 4);
function sortBy(a, keyOf) { var result = a.slice(0); result.sort(function (x, y) { var kx = keyOf(x); var ky = keyOf(y); return kx > ky ? 1 : kx < ky ? -1 : 0; }); return result; } var products = [ { name: "Lawnmower", price: 395.00, id: 345801 }, { name: "Hammer", price: 5.75, id: 266701 }, { name: "Toaster", price: 19.95, id: 400670 }, { name: "Padlock", price: 4.50, id: 560004 } ]; var sorted = sortBy(products, function (x) { return x.price; }); document.body.innerText = JSON.stringify(sorted, null, 4);
Comparing the two signatures, which is easier to understand?
function sortBy<T>(a: T[], keyOf: (item: T) => any): T[]
function sortBy(a, keyOf)
It might be reasoned that the TypeScript version should be easier to understand given that it provides more information, but many would disagree that this is in fact the case. The reason for this is that the TypeScript version adds quite a bit of syntax to explicitly describe information that can otherwise be deduced fairly easily. In many ways this is similar to how we process natural language. When we communicate, we don't encode each word with its grammatical function (e.g. "I [subject] bought [past tense verb] you [indirect object] a [indefinite article] gift [direct object].") Rather, we rapidly and subconsciously make guesses based on familiarity with the vocabulary, context, convention and other such signals.
In the case of the sortBy example, we can guess at the parameters and return type for the function faster than we can parse the type syntax. This becomes even easier if descriptive names are used (e.g. sortByKey(array, keySelector)). Sometimes implicit expression is simply easier to understand.
Now to be fair, there are cases where TypeScript is arguably going to be more clear than the generated JavaScript (and for similar reasons). Consider the following listing:
class Auto{ constructor(public wheels = 4, public doors?){ } } var car = new Auto(); car.doors = 2;
var Auto = (function () { function Auto(wheels, doors) { if (wheels === void 0) { wheels = 4; } this.wheels = wheels; this.doors = doors; } return Auto; }()); var car = new Auto(); car.doors = 2;
In this example, the TypeScript version results in less syntax noise than the generated JavaScript version. Of course, this is a comparison between TypeScript and it's generated syntax rather than the following syntax many may have used:
wheels = wheels || 4;
Community Alignment
While TypeScript is a superset of JavaScript, this deserves some qualification. Unlike languages such as CoffeeScript and Dart which also compile to JavaScript, TypeScript starts with the EcmaScript specification as the base of it's language. Nevertheless, TypeScript is still a separate language.
A team's choice to maintain an application in TypeScript over JavaScript isn't quite the same thing as choosing to implement an application in C# version 6 instead of C# version 5. TypeScript isn't the promise: "Programming with the ECMAScript of tomorrow … today!". Rather, it's a language that layers a different programming paradigm on top of JavaScript. While you can choose how much of the feature superset and programming paradigm you wish to use, the more features and approaches peculiar to TypeScript that are adopted the further the codebase will diverge from standard JavaScript syntax and conventions.
A codebase that fully leverages TypeScript can tend to look far more like C# than standard JavaScript. In many ways, TypeScript is the perfect front-end development environment for C# developers as it provides a familiar syntax and programming paradigm to which they are already accustomed. Unfortunately, developers who spend most of their time in C# often struggle with JavaScript syntax, conventions, and patterns. The same might be expected to be true for TypeScript developers who utilize the language to emulate object-oriented development in C#.
Ultimately, the real negative I see with this is that (at least right now) TypeScript doesn't represent how the majority of Web development is being done in the community. This has implications on the availability of documentation, availability of online help, candidate pool size, marketability, and skill portability.
Consider the following chart which compares the current job openings available for JavaScript and TypeScript:
Source: simplyhired.com – August 2016
Now, the fact that there may be far less TypeScript jobs out there than JavaScript jobs doesn't mean that TypeScript isn't going to be the next big thing. What it does mean, however, is that you are going to experience less friction in the aforementioned areas if you stick with standard EcmaScript.
For those considering TypeScript, the following are a couple of options you might consider before converting just yet.
ECMAScript 2015
If you're interested in TypeScript and currently still writing ES5 code, one step you might consider is to begin using ES2015. In John Papa's article: "Understanding ES5, ES2015 and TypeScript", he writes:
Why Not Just use ES2015? That's a great option! Learning ES2015 is a huge leap from ES5. Once you master ES2015, I argue that going from there to TypeScript is a very small step.
In many ways, taking the time to learn ECMAScript 2015 is the best option even if you think you're ready to start using TypeScript. Making the journey from ES5 to ES2015 and then later on to TypeScript will help you to clearly understand which new features are standard ECMAScript and which are TypeScript … knowledge you're likely to be fuzzy on if you move straight from ES5 to TypeScript.
If you've already become convinced that you need a type system for JavaScript development or you're just looking to test the waters, you might consider a lighter-weight alternative to the TypeScript platform: Facebook's Flow project. Flow is a static type checker for JavaScript designed to gain static type checking benefits without losing the "feel" of coding in JavaScript and in some cases it does a better job at catching type-related errors than TypeScript.
For the most part, Flow's type system is identical to that of TypeScript, so it shouldn't be too hard to convert to TypeScript down the road if desired. Several IDEs have Flow support including Web Storm, Sublime Text, Atom, and of course Facebook's own Nuclide.
As of August 2016, Flow also supports Windows. Unfortunately this support has only recently become available, so Flow doesn't yet enjoy the same IDE support on Windows as it does on OSX and Linux platforms. IDE support can likely be expected to improve going forward.
Test-Driven Development
If you've found the primary appeal of TypeScript to be the immediate feedback you receive from the tooling, another methodology for achieving this (which has far greater benefits) is the practice of Test-Driven Development (TDD). The TDD methodology not only provides a rapid feedback cycle, but (if done properly) results in duplication-free code that is more maintainable by constraining the team to only developing the behavior needed by the application, and results in a regression-test suite which provides a safety net for future modifications as well as documentation for how the system is intended to be used. Of course, these same benefits can be realized with TypeScript development as well, but teams practicing TDD may find less need for TypeScript's compiler-generated error checking.
After taking some time to explore TypeScript, I've found that aspects of its ecosystem are very compelling, particularly the tooling that's available for the platform. Nevertheless, it still seems a bit early to know what role the platform will play in the future of Web development.
Personally, I like the JavaScript language and, while I see some advantages of introducing type checking, I think a wiser course for now would be to invest in learning EcmaScript 2015 and keep a watchful eye on TypeScript adoption going forward.
I recently went through the process of setting up a new development environment on Windows which included installing Git for Windows. At one point in the course of tweaking my environment, I found myself trying to determine which config file a particular setting originated. The command 'git config –list' showed the setting, but 'git config –list –system', 'git config –list –global', and 'git config –list –local' all failed to reflect the setting. Looking at the options for config, I discovered you can add a '–show-origin' which led to a discovery: Git for Windows has an additional location from which it derives your configuration.
It turns out, since the last time I installed git on Windows, a change was made for the purposes of sharing git configuration across different git projects (namely, libgit2 and Git for Windows) where a Windows-specific location is now used as the lowest setting precedence (i.e. the default settings). This is the file: C:\ProgramData\Git\config. It doesn't appear git added a way to list or edit this file as a well-known location (e.g. 'git config –list windows'), so it's not particularly discoverable aside from knowing about the '–show-origin' switch.
So the order in which Git for Windows sources configuration information is as follows:
- C:\ProgramData\Git\config
- system config (e.g. C:\Program Files\Git\mingw64\etc\gitconfig)
- global config (%HOMEPATH%\.gitconfig
- local config (repository-specific .git/config)
Perhaps this article might help the next soul who finds themselves trying to figure out from where some seemingly magical git setting is originating.
I've always had an interest in application build processes. From the start of my career, I've generally been in the position of establishing the solution architecture for the projects I've participated in and this has usually involved establishing a baseline build process.
My career began as a Unix C developer while still in college where much of my responsibilities required writing tools in both C and various Unix shell scripting languages which were deployed to other workstations throughout the country. From there, I moved on to Unix C-CGI Web development and worked a number of years with Make files. With the advent of Java, I begin using tools like Ant and Maven for several more years before switching to the .Net platform where I used open source build tools like NAnt until Microsoft introduced MSBuild with its 2.0 release. Upon moving to the Austin, TX area, I was greatly influenced by what was the early seat of the Alt.Net movement. It was there where I abandoned what in hindsight has always been a ridiculous idea … trying to script a build using XML. For the next 4-5 years, I used Rake to define all of my builds. Starting last year, I began using Gulp and associated tooling on the Node platform for authoring .Net builds.
Throughout this journey of working with various build technologies, I've formed a few opinions along the way. One of these opinions is that the Build process shouldn't be coupled to the Continuous Integration process.
A project should have a build process which exists and can be executed independent of the particular continuous integration tool one chooses. This allows builds to be created and maintained on the developer's local machine. The particular build steps involved in building a given application are inherently part of its ontology. What compilers and preprocessors need to be used, how dependencies are obtained and published, when and how configuration values are supplied for different environments, how and where automated test suites are run, how the application distribution is created … all of these are concerns whose definition and orchestration are particular to a given project. Such concerns should be encapsulated in a build script which lives with the rest of the application source, not as discrete build steps defined within your CI tool.
Ideally, builds should never break, but when they do it's important to resolve the issue as quickly as possible. Not being able to run a build locally means potentially having to repeatedly introduce changes until the build is fixed. This tends to pollute the source code commit history with comments like: "Fixing the build", "Fixing the build for realz this time", and "Please let this be it … I'm ready to go home". Of course, there are times when a build can break because of environmental issues that may not be mirrored locally (e.g. lack of disk space, network related issues, 3rd-party software dependencies, etc.), but encapsulating as much of your build as possible goes a long way to keeping builds running along smoothly. Anyone on your team should be able to clone/check-out the project, issue a single command from the command line (e.g. gulp, rake, psake, etc.) and watch the full build process execute including any pre-processing steps, compilation, distribution packaging and even deployment to a target environment.
Aside from being able to run a build locally, decoupling the build from the CI process allows the technologies used by each to vary independently. Switching from one CI tool to another should ideally just require installing the software, pointing it to your source control, defining the single step to issue the build, and defining the triggers that initiate the process.
The creation of a project distribution and the scheduling mechanism for how often this happens are separate concerns. Just because a CI tool allows you to script out your build steps doesn't mean you should.
Earlier this year I joined a development team which chose Entity Framework for the persistence needs of a new greenfield project. While I've worked on a few projects which used Entity Framework here and there over the years, the bulk of my experience has been with NHibernate and, more recently, Dapper.Net. As a result, there hasn't been all that much occasion for me to explore it in any level of depth until this year.
One area I recently took some time to research is how the Unit of Work pattern is best implemented within the context of using Entity Framework. While the topic is still relatively fresh on my mind, I thought I'd use this as an opportunity to create a catalog of various approaches I've encountered and include some thoughts about each approach.
Unit of Work
To start, it may be helpful to give a basic definition of the Unit of Work pattern. A Unit of Work can be defined as a collection of operations that succeed or fail as a single unit. Given a series of operations which need to be executed in response to some interaction with an application, it's often necessary to ensure that none of the operations cause side-effects if any one of them fails. This is accomplished by having participating operations respond to either a commit or rollback message indicating whether the operation performed should be completed or reverted.
A Unit of Work can consist of different types of operations such as Web Service calls, Database operations, or even in-memory operations, however, the focus of this article will be on approaches to facilitating the Unit of Work pattern with Entity Framework.
With that out of the way, let's take a look at various approaches to facilitating the Unit of Work pattern with Entity Framework.
Implicit Transactions
The first approach to achieving a Unit of Work around a series of Entity Framework operations is to simply create an instance of a DbContext class, make changes to one or more DbSet
Here's an example:
public Customer CreateCustomer(CreateCustomerRequest request) { Customer customer = null; using (var context = new MyStoreContext()) { customer = new Customer { FirstName = request.FirstName, LastName = request.LastName }; context.Customers.Add(customer); context.SaveChanges(); return customer; } }
The benefit of this approach is that a transaction is created only when necessary and is kept alive only for the duration of the SaveChanges() call. Some drawbacks to this approach, however, are that it leads to opaque dependencies and adds a bit of repetitive infrastructure code to each of your applications services.
If you prefer to work directly with Entity Framework then this approach may be fine for simple needs.
Another approach is to use the System.Transactions.TransactionScope class provided by the .Net framework. When any of the Entity Framework operations are used which cause a connection to be opened (e.g. SaveChanges()), the connection will enlist in the ambient transaction defined by the TransactionScope class and close the transaction once the TransactionScope is successfully completed. Here's an example of this approach:
public Customer CreateCustomer(CreateCustomerRequest request) { Customer customer = null; using (var transaction = new TransactionScope()) { using (var context = new MyStoreContext()) { customer = new Customer { FirstName = request.FirstName, LastName = request.LastName }; context.Customers.Add(customer); context.SaveChanges(); transaction.Complete(); } return customer; } }
In general, I find using TransactionScope to be a good general-purpose solution for defining a Unit of Work around Entity Framework operations as it works with ADO.Net, all versions of Entity Framework, and other ORMs which provides the ability to use multiple libraries if needed. Additionally, it provides a foundation for building a more comprehensive Unit of Work pattern which would allow other types of operations to enlist in the Unit of Work.
Caution should be exercised when using TransactionScope, however, as certain operations can implicitly escalate the transaction to a distributed transaction causing undesired overhead. For those choosing solutions involving TransactionScope, I would recommend educating yourself on how and when transactions are escalated.
While I find using the TransactionScope class to be a good general-purpose solution, using it directly does couple your services to a specific strategy and adds a bit of noise to your code. While it's a viable choice, I would recommend inverting the concerns of managing the Unit of Work boundary as shown in approaches we'll look at later.
ADO.Net Transactions
This approach involves creating an instance of DbTransaction and instructing the participating DbContext instance to use the existing transaction:
public Customer CreateCustomer(CreateCustomerRequest request) { Customer customer = null; var connectionString = ConfigurationManager.ConnectionStrings["MyStoreContext"].ConnectionString; using (var connection = new SqlConnection(connectionString)) { connection.Open(); using (var transaction = connection.BeginTransaction()) { using (var context = new MyStoreContext(connection)) { context.Database.UseTransaction(transaction); try { customer = new Customer { FirstName = request.FirstName, LastName = request.LastName }; context.Customers.Add(customer); context.SaveChanges(); } catch (Exception e) { transaction.Rollback(); throw; } } transaction.Commit(); return customer; } }
As can be seen from the example, this approach adds quite a bit of infrastructure noise to your code. While not something I'd recommend standardizing upon, this approach provides another avenue for sharing transactions between Entity Framework and straight ADO.Net code which might prove useful in certain situations. In general, I wouldn't recommend such an approach.
Entity Framework Transactions
The relative new-comer to the mix is the new transaction API introduced with Entity Framework 6. Here's a basic example of it's use:
public Customer CreateCustomer(CreateCustomerRequest request) { Customer customer = null; using (var context = new MyStoreContext()) { using (var transaction = context.Database.BeginTransaction()) { try { customer = new Customer { FirstName = request.FirstName, LastName = request.LastName }; context.Customers.Add(customer); context.SaveChanges(); transaction.Commit(); } catch (Exception e) { transaction.Rollback(); throw; } } } return customer; }
This is the approach recommended by Microsoft for achieving transactions with Entity Framework going forward. If you're deploying applications with Entity Framework 6 and beyond, this will be your safest choice for Unit of Work implementations which only require database operation participation. Similar to a couple of the previous approaches we've already considered, the drawbacks of using this directly are that it creates opaque dependencies and adds repetitive infrastructure code to all of your application services. This is also a viable option, but I would recommend coupling this with other approaches we'll look at later to improve the readability and maintainability of your application services.
Unit of Work Repository Manager
The first approach I encountered when researching how others were facilitating the Unit of Work pattern with Entity Framework was a strategy set forth by Microsoft's guidance on the topic here. This strategy involves creating a UnitOfWork class which encapsulates an instance of the DbContext and exposes each repository as a property. Clients of repositories take a dependency upon an instance of UnitOfWork and access each repository as needed through properties on the UnitOfWork instance. The UnitOfWork type exposes a SaveChanges() method to be used when all the changes made through the repositories are to be persisted to the database. Here is an example of this approach:
public interface IUnitOfWork { ICustomerRepository CustomerRepository { get; } IOrderRepository OrderRepository { get; } void Save(); } public class UnitOfWork : IDisposable, IUnitOfWork { readonly MyContext _context = new MyContext(); ICustomerRepository _customerRepository; IOrderRepository _orderRepository; public ICustomerRepository CustomerRepository { get { return _customerRepository ?? (_customerRepository = new CustomerRepository(_context)); } } public IOrderRepository OrderRepository { get { return _orderRepository ?? (_orderRepository = new OrderRepository(_context)); } } public void Dispose() { if (_context != null) { _context.Dispose(); } } public void Save() { _context.SaveChanges(); } } public class CustomerService : ICustomerService { readonly IUnitOfWork _unitOfWork; public CustomerService(IUnitOfWork unitOfWork) { _unitOfWork = unitOfWork; } public void CreateCustomer(CreateCustomerRequest request) { customer = new Customer { FirstName = request.FirstName, LastName = request.LastName }; _unitOfWork.CustomerRepository.Add(customer); _unitOfWork.Save(); } }
It isn't hard to imagine how this approach was conceived given it closely mirrors the typical implementation of the DbContext instance you find in Entity Framework guidance where public instances of DbSet
First, this approach leads to opaque dependencies. Due to the fact that classes interact with repositories through the UnitOfWork instance, the client interface doesn't clearly express the inherent business-level collaborators it depends upon (i.e. any aggregate root collections).
Second, this violates the Open/Closed Principle. To add new aggregate roots to the system requires modifying the UnitOfWork each time.
Third, this violates the Single Responsibility Principle. The single responsibility of a Unit of Work implementation should be to encapsulate the behavior necessary to commit or rollback an set of operations atomically. The instantiation and management of repositories or any other component which may wish to enlist in a unit of work is a separate concern.
Lastly, this results in a nominal abstraction which is semantically coupled with Entity Framework. The example code for this approach sets forth an interface to the UnitOfWork implementation which isn't the approach used in the aforementioned Microsoft article. Whether you take a dependency upon the interface or the implementation directly, however, the presumption of such an abstraction is to decouple the application from using Entity Framework directly. While such an abstraction might provide some benefits, it reflects Entity Framework usage semantics and as such doesn't really decouple you from the particular persistence technology you're using. While you could use this approach with another ORM (e.g. NHibernate), this approach is more of a reflection of Entity Framework operations (e.g. it's flushing model) and usage patterns. As such, you probably wouldn't arrive at this same abstraction were you to have started by defining the abstraction in terms of the behavior required by your application prior to choosing a specific ORM (i.e. following The Dependency Inversion Principle). You might even find yourself violating the Liskof Substitution Principle if you actually attempted to provide an alternate ORM implementation. Given these issues, I would advise people to avoid this approach.
Injected Unit of Work and Repositories
For those inclined to make all dependencies transparent while maintaining an abstraction from Entity Framework, the next strategy may seem the natural next step. This strategy involves creating an abstraction around the call to DbContext.SaveChanges() and requires sharing a single instance of DbContext among all the components whose operations need to participate within the underlying SaveChanges() call as a single transaction.
Here is an example:
public class CustomerService : ICustomerService { readonly IUnitOfWork _unitOfWork; readonly ICustomerRepository _customerRepository; public CustomerService(IUnitOfWork unitOfWork, ICustomerRepository customerRepository) { _unitOfWork = unitOfWork; _customerRepository = customerRepository; } public void CreateCustomer(CreateCustomerRequest request) { customer = new Customer { FirstName = request.FirstName, LastName = request.LastName }; _customerRepository.Add(customer); _unitOfWork.Save(); } }
While this approach improves upon the opaque design of the Repository Manager, there are several issues I find with this approach as well.
Similar to the first example, this UnitOfWork implementation is still semantically coupled to how Entity Framework is urging you to think about things. Entity Framework wants you to call SaveChanges() whenever you're ready to flush any INSERT, UPDATE, or DELETE operations you've issued against the database and this abstraction basically surfaces this behavior. If you were to use an alternate framework that supported a different flushing model (e.g. NHibernate), you likely wouldn't end up with the same abstraction.
Moreover, this approach has no definitive Unit of Work boundary. With this approach, you aren't defining a logical Unit of Work, but are merely injecting a UnitOfWork you can participate within. When you invoke the underlying DBContext.SaveChanges() method, it isn't explicit what work will be committed.
While this approach corrects a few design issues I find with the Repository Manager, overall I like this approach even less. At least with the Repository Manager approach you have a defined Unit of Work boundary which is kind of the whole point. My recommendation would be to avoid this approach as well.
Repository SaveChanges Method
The next strategy is basically a variation on the previous one. Rather than injecting a separate type whose sole purpose is to provide an indirect way to call the SaveChanges() method, some merely expose this through the Repository:
public class CustomerService : ICustomerService { readonly ICustomerRepository _customerRepository; public CustomerService(ICustomerRepository customerRepository) { _customerRepository = customerRepository; } public void CreateCustomer(CreateCustomerRequest request) { customer = new Customer { FirstName = request.FirstName, LastName = request.LastName }; _customerRepository.Add(customer); _customerRepository.SaveChanges(); } }
This approach shares many of the same issues with the previous one. While it reduces a bit of infrastructure noise, it's still semantically coupled to Entity Framework's approach and still lacks a defined Unit of Work boundary. Additionally, it lacks clarity as to what happens when you call the SaveChanges() method. Given the Repository pattern is intended to be a virtual collection of all the entities within your system of a given type, one might suppose a method named "SaveChanges" means that you are somehow persisting any changes made to the particular entities represented by the repository (setting aside the fact that doing so is really a subversion of the pattern's purpose). On the contrary, it really means "save all the changes made to any entities tracked by the underlying DbContext". I would also recommend avoiding this approach.
Unit of Work Per Request
A pattern I'm a bit embarrassed to admit has been characteristic of many projects I've worked on in the past (though not with EF) is to create a Unit of Work implementation which is scoped to a Web Application's Request lifetime. Using this approach, whatever method is used to facilitate a Unit of Work is configured with a DI container using a Per-HttpRequest lifetime scope and the Unit of Work boundary is opened by the first component being injected by the UnitOfWork and committed/rolled-back when the HttpRequest is disposed by the container.
There are a few different manifestations of this approach depending upon the particular framework and strategy you're using, but here's a pseudo-code example of how configuring this might look for Entity Framework with the Autofac DI container:
() .As () .InstancePerRequest() .OnActivating(x => { // start a transaction }) .OnRelease(context => { try { // commit or rollback the transaction } catch (Exception e) { // log the exception throw; } }); public class SomeService : ISomeService { public void DoSomething() { // do some work } }
While this approach eliminates the need for your services to be concerned with the Unit of Work infrastructure, the biggest issue with this is when an error happens to occur. When the application can't successfully commit a transaction for whatever reason, the rollback occurs AFTER you've typically relinquished control of the request (e.g. You've already returned results from a controller). When this occurs, you may end up telling your customer that something happened when it actually didn't and your client state may end up out of sync with the actual persisted state of the application.
While I used this strategy without incident for some time with NHibernate, I eventually ran into a problem and concluded that the concern of transaction boundary management inherently belongs to the application-level entry point for a particular interaction with the system. This is another approach I'd recommend avoiding.
Instantiated Unit of Work
The next strategy involves instantiating a UnitOfWork implemented using either the .Net framework TransactionScope class or the transaction API introduced by Entity Framework 6 to define a transaction boundary within the application service. Here's an example:
public class CustomerService : ICustomerService { readonly ICustomerRepository _customerRepository; public CustomerService(ICustomerRepository customerRepository) { _customerRepository = customerRepository; } public void CreateCustomer(CreateCustomerRequest request) { using (var unitOfWork = new UnitOfWork()) { try { customer = new Customer { FirstName = request.FirstName, LastName = request.LastName }; _customerRepository.Add(customer); unitOfWork.Commit(); } catch (Exception ex) { unitOfWork.Rollback(); } } } }
Functionally, this is a viable approach to facilitating a Unit of Work boundary with Entity Framework. A few drawbacks, however, are that the dependency upon the Unit Of Work implementation is opaque and that it's coupled to a specific implementation. While this isn't a terrible approach, I would recommend other approaches discussed here which either surface any dependencies being taken on the Unit of Work infrastructure or invert the concerns of transaction management completely.
Injected Unit of Work Factory
This strategy is similar to the one presented in the Instantiated Unit of Work example, but makes its dependence upon the Unit of Work infrastructure transparent and provides a point of abstraction which allows for an alternate implementation to be provided by the factory:
public class CustomerService : ICustomerService { readonly ICustomerRepository _customerRepository; readonly IUnitOfWorkFactory _unitOfWorkFactory; public CustomerService(IUnitOfWorkFactory unitOfWorkFactory, ICustomerRepository customerRepository) { _customerRepository = customerRepository; _unitOfWorkFactory = unitOfWorkFactory; } public void CreateCustomer(CreateCustomerRequest request) { using (var unitOfWork = _unitOfWorkFactory.Create()) { try { customer = new Customer { FirstName = request.FirstName, LastName = request.LastName }; _customerRepository.Add(customer); unitOfWork.Commit(); } catch (Exception ex) { unitOfWork.Rollback(); } } } }
While I personally prefer to invert such concerns, I consider this to be a sound approach.
As a side note, if you decide to use this approach, you might also consider utilizing your DI Container to just inject a Func
Unit of Work ActionFilterAttribute
For those who prefer to invert the Unit of Work concerns as I do, the following approach provides an easy to implement solution for those using ASP.Net MVC and/or Web API. This technique involves creating a custom Action filter which can be used to control the boundary of a Unit of Work at the Controller action level. The particular implementation may vary, but here's a general template:
public class UnitOfWorkFilter : ActionFilterAttribute { public override void OnActionExecuting(ActionExecutingContext filterContext) { // begin transaction } public override void OnActionExecuted(ActionExecutedContext filterContext) { // commit/rollback transaction } }
The benefits of this approach are that it's easy to implement and that it eliminates the need for introducing repetitive infrastructure code into your application services. This attribute can be registered with the global action filters, or for the more discriminant, only placed on actions resulting in state changes to the database. Overall, this would be my recommended approach for Web applications. It's easy to implement, simple, and keeps your code clean.
Unit of Work Decorator
A similar approach to the use of a custom ActionFilterAttribute is the creation of a custom decorator. This approach can be accomplished by utilizing a DI container to automatically decorate specific application service interfaces with a class which implements a Unit of Work boundary.
Here is a pseudo-code example of how configuring this might look for Entity Framework with the Autofac DI container which presumes that some form of command/command-handler pattern is being utilized (e.g. frameworks like MediatR , ShortBus, etc.):
// DI Registration builder.RegisterGenericDecorator( typeof(TransactionRequestHandler<,>), // the decorator instance typeof(IRequestHandler<,>), // the types to decorate "requestHandler", // the name of the key to decorate null); // the name of the key to this decorator public class TransactionRequestHandler
: IRequestHandler where TResponse : ApplicationResponse { readonly DbContext _context; readonly IRequestHandler _decorated; public TransactionRequestHandler(IRequestHandler decorated, DbContext context) { _decorated = decorated; _context = context; } public TResponse Handle(TRequest request) { TResponse response; // Open transaction here try { response = _decorated.Handle(request); // commit transaction } catch (Exception e) { //rollback transaction throw; } return response; } } public class SomeRequestHandler : IRequestHandler { public ApplicationResponse Handle() { // do some work return new SuccessResponse(); } }
While this approach requires a bit of setup, it provides an alternate means of facilitating the Unit of Work pattern through a decorator which can be used by other consumers of the application layer aside from just ASP.Net (i.e. Windows services, CLI, etc.) It also provides the ability to move the Unit of Work boundary closer to the point of need for those who would rather provide any error handling prior to returning control to the application service client (e.g. the Controller actions) as well as giving more control over the types of operations decorated (e.g. IQueryHandler vs. ICommandHandler). For Web applications, I'd recommend trying the custom Action Filter approach first, as it's easier to implement and doesn't presume upon the design of your application layer, but this is certainly a good approach if it fits your needs.
Out of the approaches I've evaluated, there are several that I see as sound approaches which maintain some minimum adherence to good design practices. Of course, which approach is best for your application will be dependent upon the context of what you're doing and to some extent the design values of your team.
I recently started working with a new team that uses NUnit as their testing framework. While I think NUnit is a solid framework, I don't think the default API and style lead to effective tests.
As an advocate of Test-Driven Development, I've always appreciated how context/specification-style frameworks such as Machine.Specifications (MSpec) allow for the expression of executable specifications which model how a system is expected to be used rather than the typical unit-test style of testing which tends to obscure the overall purpose of the system.
To facilitate a context/specification-style API, I created a base class which makes use of the hooks provided by the NUnit testing framework to emulate MSpec. I've published this code under the project name NUnit.Specifications.
The following is an example NUnit test written using the ContextSpecification based class from NUnit.Specifications using the Should assertion library:
One nice benefit of building on top of NUnit is the wide-spread tool support available. Here is the test as seen through various test runners:
Resharper Test Runner:
TestDriven.Net: (see notes below)
NUnit Test Runner:
NUnit Test Adaptor for Visual Studio:
One caveat I discovered with the TestDriven.Net runner is it's failure to recognize tests without the specification referencing types from the NUnit.Framework namespace (e.g. TestFixtureAttribute, CategoryAttribute, use of Assert, etc.). That is to say, it didn't seem to be enough that the spec inherited from a base type with NUnit attributes, but something in the derived class had to reference a type from the NUnit.Framework namespace for the test to be recognized. Therefore, the TestDriven.Net results shown above were actually achieved by annotating the class with [Category("component")] explicitly.
Other Stuff
As a convenience, NUnit.Specifications also provides attributes for denoting categories of Unit, Component, Integration, Acceptance, and Subcutaneous as well as a Catch class (as provided by the MSpec library) for working with exceptions.
You can obtain the NUnit.Specifications from NuGet or grab the source from github.
When the term "agile" is used in reference to one's development processes, it more often than not seems to be used in a monolithic way. It isn't that many aren't cognizant of the fact that people tend to use a subset, combination, or modified form of the main agile processes marketed today, but even in this recognition there seems to be a tendency to think about each variation in monolithic terms.
Which Process Do You Use?
If you've ever attended a local agile user group to hear various processes compared, you may have encountered the speaker asking for a show of hands to find out what various processes people are using. If you've been to one of these meetings, it might have gone a little like this:
Let's see a show of hands of those in the room who are using Scrum. That's quite a few of you. How about Scrum-ban? Nice. Now let see a show of hands for people using Extreme Programming or XP. Not as many of you guys here. Who's using the Rational Unified Process or RUP? Anyone? Who isn't currently using an agile process, but came here today to learn more about agile? Glad to have you guys here! I hope this session will be informative. So, is anyone using any other process we haven't mentioned? Yes, you sir. What is your group using?
Um, we'll, we use a process we call 'Scrum-but'. We use Scrum, but we leave out some things. [a chuckle is heard from a few individuals].
While such a meeting generally turns to discussing the various attributes of different processes, usually hitting major highlights of Scrum such as iterations, stand-ups, planning meetings, user stories, retrospectives, etc., it still does so in terms of the attributes of different monolithic processes. The deficiency in this line of thinking is that it trains people to think in terms of what percentage of a name-brand agile process their team is adhering to, or should seek to adopt, rather than thinking about what problems these processes individually have evolved to solve. "Which Process Do You Use" is the wrong question.
Are you Agile?
Many teams like to say "We're an agile development shop". Now to be fair, when we want to convey to someone which common group of practices we follow, it can be useful to use labels such as Scrum, XP, Scrum-ban, etc. That said, there seems to be an awful lot of shops that say they are agile when what they mean is that they do "stand-ups" (i.e. a daily status meetings for keeping their managers informed about what their up to) and "iterate" (i.e. chunky waterfall) their way to a deadline that's been handed down by upper management or a sales department.
What is Agile?
If you ask what agile is in a typical development shop today, you'll more than likely find yourself in a conversation about Scrum or some other process than to talk about the actual meaning of the word. Let's actually go back and look at the definition:
ag·ile - adjective \ˈa-jəl, -ˌjī(-ə)l\
1: marked by ready ability to move with quick easy grace <an agile dancer>
2: having a quick resourceful and adaptable character <an agile mind>
Based on this definition from Merriam-Webster's dictionary, being agile is "an ability to change, or adapt to change, quickly". While communicating that you adhere to a given agile process may have it's usefulness at times, thinking of your process in this monolithic way doesn't promote the kind of thinking that leads to continuous improvement. Rather than thinking in terms of which process we use, we should think in terms of what aspects of change our processes help us adapt to.
Toward An Agile View of Process
It seems that many team's first foray into agile processes is the selection of Scrum by their management. They've heard about this Scrum and how it can save them money, so they've sent the managers and Business Analysts off to Scrum Master training to outfit them with their Scrum-capes and Scrum-tights.
Introducing a process like Scrum (or whatever portions of Scrum a company's existing process will tolerate) will sometimes improve upon matters, but only insofar as one's cargo-cult emulation of the prescribed practices happen to match up with the problems for which they were conceived. Unfortunately this approach to adopting agile processes often seems to lead to a bunch of people going through the motions without really understanding what the purpose is. Worse, when the local Scrum training consultants sell them on the fact that they don't really have to give up things like deadlines, using business analysts to gather all the requirements, or otherwise restructuring their organization, they generally end up with some empty shell of a process which is really nothing more than their old waterfall process with more micro-management.
A better approach is to first learn about the types of issues different agile practices seek to address and then consider how your team's existing process can improve if each practice were applied individually. Rather than thinking of your team as "agile" or "not agile", consider asking the following types of questions:
Is my team agile WITH RESPECT TO …
changes to the product's desired features?
changes to the product's code base?
changes to the team's understanding of the domain?
changes to the team's understanding of the technologies used?
changes to team member's hours of availability?
changes to individuals on the team?
changes to skillsets within the team?
changes to the cost of materials and resources?
changes to the compatibility or availability of 3rd-party software?
Different agile practices address different kinds of problems, but to really become an agile team you need to learn how to identify problems and solutions on an ongoing basis, not just implement processes. Let's stop thinking of ourselves as agile or not agile and start asking the question "What are we agile at?"
ExpectedObjects is a testing library I developed a few years ago to facilitate using the Expected Objects pattern within my specifications to avoid obscure tests. You can find the original introduction to the library here.
As of version 1.1.0, the ExpectedObjects library has been updated to include a feature called Custom Comparisons. The standard behavior of the library is to traverse a strategy chain (which is itself configurable) to determine which comparison strategy is to be used for each type of object encountered within the object graph. The Custom Comparisons feature allows you to override this behavior for specific properties.
For example, let's say we're writing a end-to-end test which validates a Receipt class as follows:
public class Receipt { public string Name { get; set; } public DateTime TransactionDate { get; set; } public string VerificationCode { get; set; } }
Given the following class, the VerificationCode property would probably not be a value you could anticipate. In such a case, while you can't verify that the property has a specific value, you may care that it at least has some value. This is where the Custom Comparisons feature can help. We can verify that the actual Receipt received matches the expected receipt structure using the following expected object configuration:
var expected = new { Name = "John Doe", DateTime = DateTime.Today, VerificationCode = Expect.NotNull() }.ToExpectedObject(); var actual = new Receipt { Name = "John Doe", DateTime = DateTime.Today, VerificationCode = "ABC123" }; expected.ShouldMatch(actual);
In the event that the VerificationCode property is null, the library will raise an exception with the following message:
For Receipt.VerificationCode, expected a non-null value but found [null].
The ExpectedObjects library currently provides a static Expect class which includes convenience methods to check for null, not null, and an Any<T> comparison for checking that an object is of a specific type (e.g. Expect.Any<Receipt>()). To supply your own comparisons, simply implement the IComparsion interface which defines the custom comparison and the text to include within any exception messages raised (e.g. "For SomeType.SomeProperty, expected [text you supply here] but found "42").
This is the first article in a new sporadic series I'll contribute to from time to time wherein I'll discuss some noteworthy issues I've wrestled with. In this installment, I'll be discussing an NHibernate issue which took me some time to work through. So, let's dive into the story …
The Context
In an application I was recently working on, a need arose to modify a section of code involving two entities which should have been modeled using a parent/child relationship but which only had a loose association in the database. The primary table in the database schema for what needed to be the parent object in the domain only contained a unenforced foreign key column which matched up with a candidate key on the table used for what needed to be the child object. In the section of code I needed to modify, a View Model was being created by first retrieving data for the parent object and subsequently for the child object. I'm not exactly sure what lead to this path, but I think it had something to do with the original developer's attempt at using a surrogate key strategy for all the tables and later attempts by others to pull the data into a domain model with NHibernate.
At any rate, while I wasn't in a position to revamp the whole design, I knew there was a way to express many-to-one mappings in NHibernate using non-primary keys, so after a little searching and some trial-and-error I got the parent entity referencing the child entity with a Fluent NHibernate Auto-Mapping configuration similar to the following:
return AutoMap.AssemblyOf
(new AutomappingConfiguration()) .Override (map => map.References(p => p.Child, "ParentColumnChildKeyName").PropertyRef("ChildCandidateKeyColumnName") .Fetch.Join());
Part of the changes required to make this work was some refactoring of an import job used to populate the database which relied upon the domain model and mappings to populate the parent and child data. After changing the parent entity to reference the child entity instead of just a candidate key to the child entity, I needed to modify the import job to persist the relationship between the parent and the child. To do this, I injected a pre-existing ChildRepository to query for existing instances of the child entities (which had its own separate import process) so I could associate it with the parent entity upon saving. All of the changes worked as expected for the client portion of the application, but the changes broke some acceptance tests for the import job. The error I started receiving in the tests was as follows:
null id in "MyEntityType" entry (don't flush the Session after an exception occurs)
In this case the "MyEntityType" was another entity which had a many-to-one mapping with the aforementioned parent entity. After looking over the code and scratching my head for a bit, I decided to do a search on this particular error and read a few articles which at first didn't seem to speak to my particular scenario. The advice I read basically boiled down to "Don't try to do stuff with the session after you receive an error". That certainly made sense, but upon stepping through the code I couldn't see anywhere I was catching an error and proceeding to do something further with the session. I then decided to add a try/catch around the offending code and suddenly I saw the issue: trying to save an entity associated with one open session with an entity from another open session.
The Solution
Ultimately, the reason I couldn't see the error was due to an issue with a manifestation of some common infrastructure code my team uses when working working with NHibernate. We use Autofac for dependency injection, and to facilitate transactions we use Autofac's OnActivating() and OnRelease() methods to begin an NHibernate transaction and to handle the rollback or commit of the transaction when complete. Here was the offending code:
builder.Register(c => c.ResolveNamed
(RegistrationKey).OpenSession()) .As () .OnActivating(x => x.Instance.BeginTransaction()) .OnRelease(session => { try { if (!session.Transaction.WasRolledBack && session.Transaction.IsActive) { session.Transaction.Commit(); } } finally { session.Close(); session.Dispose(); } });
When used within the context of our Web applications, this code would contain a call to register the ISession with an HTTP Request lifetime scope, but this import job didn't require a shared ISession prior to my changes. To fix the problem, I added a call to register the ISession as InstancePerLifetimeScope() which causes the same lifetime scope used to resolve the job to be used for resolving any instances of ISession. Additionally, I added a try/catch/throw around the session to at least provide some logging of similar issues should this ever come up again.


text:
Discussing European-based operations Jean Madar, Chairman & CEO of Inter Parfums noted, "The favorable trends of the first quarter continued into the second quarter with strong performances across our brand portfolio. Compared to the same periods in 2011, Burberry sales rose 34% for the current second quarter and 21% for the first half on strong growth of established fragrances, including Burberry Body, which launched in late 2011. While there were no major launches this year, Lanvin fragrance sales increased 13% for the quarter and year-to-date due to continuing gains by Eclat d'Arpège and the steady performances by Jeanne Lanvin and Marry Me! With Montblanc Legend as the catalyst, Montblanc brand sales rose 72% in the second quarter and 75% through the first half. We are likewise delighted by the momentum of Jimmy Choo fragrances that began in 2011 with the Eau de Parfum, and continued in 2012 with the Eau de Toilette, resulting in a 13% and 42% increase in brand sales for the second quarter and first half, respectively. Some of the smaller brands in our portfolio are also generating significant year-to-date gains, including Boucheron, which had a more than fivefold increase in sales, and S.T. Dupont with a 48% sales increase compared to the first half of 2011."He continued, "Top line growth has been especially strong in North America, the Middle East, Asia, and South America where year-to-date sales rose 56%, 40%, 22%, and 35%, respectively. We have also seen significant sales growth in Eastern Europe with first half gains of 25%. Despite the slowdown in consumer spending in selected countries in Western Europe, first half sales were 10% ahead of the same period last year." On the subject of U.S.-based operations, Mr. Madar went on to say, "As was the case in the first quarter, second quarter sales benefited from the inclusion of Anna Sui fragrance sales and the launch of our first Nine West fragrance, Love Fury. Additionally we brought a number of new products to market during the quarter including: Miss Madison by Brooks Brothers, Wishes & Dreams for bebe, and a new men's scent, Wildbloom Blue for Banana Republic. Finally, international distribution of the U.S. specialty retail brands in our portfolio has been an ongoing success and an important contributor to our top line growth." Raises 2012 Guidance Russell Greenberg, Executive Vice President & Chief Financial Officer stated, "Based upon our performance thus far this year, our expectations for the second half and the strength of the dollar relative to the euro, which was 15% higher on June 30, 2012, as compared to June 30, 2011, we are increasing our 2012 sales guidance to $632 million. We are likewise increasing our guidance for net income attributable to Inter Parfums, Inc. to approximately $35.9 million or $1.17 per diluted share. Our guidance assumes the dollar remains at current levels."
- Log In
- Newsletters
Access insights and guidance from our Wall Street pros. Find the product that's right for you.
- Action Alerts PLUS
- Daily Swing Trade
- Income Seeker
- Quant Ratings
- Real Money
- Real Money Pro
- Stocks Under $10
- Top Stocks
- Trifecta Stocks
- Real Money Pro Portfolio
- Chairman's Club
- Compare All

subset: commoncrawl


text:
Kitten is fascinated by dog's tongue
One Response to Kitten is fascinated by dog's tongue
Sharon April 19, 2012 @ 4:28 am
Very cute and obviously fun cat! She seems to be very full of herself especially love the run an slide across floor in box part. thanks for sharing
RSS feed for comments on this post. TrackBack URL
Leave a comment
Site 'Breadcrumb' Navigation:


text:
BP Comment Quick Links
|Strength of Schedule Report
June 10, 2003
Prospectus Today
M's 2001, v2.0
To my mind, the biggest surprise of the 2003 season is the Seattle Mariners. After their late-season fade in 2002, I believed that their decline from 2001's 116 wins would continue. They did little to address their aging roster this winter, and their best prospects remain a year or two away.
Note to self: stop making predictions about the AL West.
Today, the Mariners are 42-19, eight games ahead of the A's. They haven't been lucky: Their .682 winning percentage is almost exactly what you would expect from a team with 344 runs scored and 232 runs allowed. The Mariners have the second-best offense in baseball (.285 EqA, tied with the Red Sox and just behind the Braves), the fourth-best bullpen and fifth-best rotation. They turn batted balls into outs better that any team in the game other than the A's, sporting a .739 Defensive Efficiency Rating.
If anything, this team is a good comp for the sainted 2001 squad. Through 61 games, that team was 48-13, but with a run differential that paralleled that of the current version:
Year Pct. RS RA Pyth. 2003 .682 344 232 .687 2001 .787 374 248 .695
In between, the Mariners went 93-69, finishing 10 games behind the A's in the West and six games out of the wild-card chase. Through the end of July, however, the M's were pretty much the same dominant baseball club they were in 2001 and have been so far in 2003:
2001: 116-46, .716
A team that has had a remarkably stable roster and won two out of every three games for nearly two-and-a-half seasons had a two-month stretch it which it played .500 ball, a stretch that cost it a playoff spot. How the heck did that happen?
It wasn't the offense. The Mariners scored 538 runs in 108 games through July 31 last year, an average of 4.98 r/g. Afterwards, they scored 276 runs in 54 games for an average of 5.1 r/g. The noted collapse of Ichiro Suzuki was more than balanced by the big second half of Bret Boone, keeping the lineup on an even keel.
The pitching was another story. The Mariners' staff had an ERA of 3.73 on the morning of August 1. That's comparable to their ERA in 2001 (3.54) and their ERA in 2003 (3.60). For the last two months of last season, though, the team had an ERA of 4.75. The starting rotation, especially Freddy Garcia, collapsed. James Baldwin finally lost his rotation job in August; John Halama was brutal, and replacement Ismael Valdes was alternately injured and ineffective through the end of the season. Jamie Moyer scuffled his way through September. While the bullpen was just about as effective as it had been, save a Kazuhiro Sasaki meltdown in September, the team's starting pitching was the key element in the M's falling off the pace in the division.
Well, that may not be entirely fair. Certainly, the ERAs of the Mariners' starters took a beating after August 1, but was it all their fault? We know that run prevention is a combination of pitching and defense; pitchers control walks, strikeouts and home runs, and the defense largely controls everything else. What changed in the dog days of August?
BB/9 K/9 HR/9 BABIP* April-July 2.6 6.5 1.0 .280 August-September 3.0 6.9 1.3 .307 *quick-and-dirty BABIP ((H-HR/AB-HR-SO))The pitching was less effective down the stretch, as you can see, but certainly not a whole run's worth. It was the defense that died. Batting average on balls in play is a serviceable proxy for Defensive Effiiciency, and as you can see, the Mariners' figure shot through the roof. The difference between the two figures is roughly equivalent to going from the top third of the league to the bottom third. The core strength that had enabled the team to muddle through with a non-strikeout rotation fell apart, and it showed up in the ERAs of the starting pitchers.
So what's the point? Well, the first point is that that despite the disapponting finish to last year's season, the 2003 Mariners can be viewed as a continuation of 2001's dominant squad. They share many of the same players and the same basic approach to the game. Moreover, they don't appear to be aging: Edgar Martinez, John Olerud, Boone, Moyer...the best players on the 2001 team were old, they're now two years older, and they're the best players on the 2003 team. If anything, it's the younger players, like Garcia and Carlos Guillen, who have been disappointments.
The team age is what makes me question whether this team can continue to win. The Mariners are heavily reliant on their defense to keep runs off the board, because their starting pitchers put a ton of balls in play. Perhaps the collapse of the defense we saw last summer was age-related. While replacing Mark McLemore and others in left field with Randy Winn should help that somewhat, the Mariners have enough aging legs that they need to be concerned about a repeat of those summertime blues.
Which brings us to the other problem the Mariners face: management. There may not be a more stark contrast come July 31 than that between Pat Gillick and Billy Beane. Gillick is nicknamed "Stand Pat" for his inactivity in the trade market, while year after year, Beane makes a key trade or three to improve his A's for the stretch drive. The A's have a deep pool of prospects from which to deal, which will make them dangerous in the market. The Mariners lack that depth and have a gaping hole at third base that needs repair; there's at least one very good third baseman--Mike Lowell--on the market. The Mariners certainly could use the upgrade on Jeff Cirillo, and Lowell fits the Mariners' scheme: a very good defensive player who brings an above-average bat to the park as well.
Gillick's ability to give his team a boost at the trade deadline--something he's never been able to do--may make the difference between repeating 2001 and repeating 2002.
Joe Sheehan is an author of Baseball Prospectus.
0 comments have been left for this article.
BP Comment Quick Links
Not a subscriber? Sign up today!


text:
GRAND JUNCTION, Colo.- A nonpartisan taxpayer group says their new study brings to light just how many failed oil shale experiments were funded by taxpayer subsidies.
The study by Taxpayers for Common Sense says billions of taxpayer dollars have gone to oil shale experiments that have been unsuccessful.
"We have no problem with oil shale development if it's developed by the oil companies ... we don't want to have to have the taxpayer subsidizing an industry that, so far, has been a failure over the last 100 years," said Jill Lancelot, co-founder of Taxpayers for Common Sense.
The study comes out in light of a new bill proposed by Texas Rep. Ralph Hall, which would require the federal government to spend $10 million a year until 2017 to develop oil shale.
In a statement, Hall said, "In addition to providing hundreds of thousands of much needed jobs, safe and prudent development of these resources would redraw the global energy map, positioning the U.S. as a world leader in energy production for decades to come."
Written By: Danielle Kreutter
Original Publication URL: http://www.krextv.com/news/around-the-region/Study-Taxes-Paid-for-Failed-Oil-Shale-Subsidies-181481321.htmlDiscussion


text:
Just to set the record straight -My CFV back uses the Kodak KAF-39000 sensor, which according to the spec sheet has an active image size of 49.0 x 36.8 mm. The pixel size is 6.8 um. It does not have microlenses. Interestingly, there are two grades available - standard, and engineering grade.I think that with the SWC a sensor using microlenses would be very bad news. The rear element of the Biogon is very, very close to the sensor plane - actually, I'm amazed that it works as well as it does. The light rays at the edge of the sensor must be coming in at a very low angle.Another interesting thing which really we only become aware of when we put these old lenses on a digital back, is that just like the Distagons and in fact most of the old Zeiss glass, the Biogon is optimised for the far field. It does close focus (down to 12 inches) but close shots are OK but not stunning. When you get out to 30 feet plus, the lens comes on song and you go "Wow" as the detail snaps in. Which is just what you want for architectural stuff and church interiors, of course. For close work stick to the 120mm S-Planar.John
john,thanks again for your input!so your opinion would be that the swc biogon ought to be basically unusable with sensors with micro lenses?you also mention that the biogon is optimized for the far field. short of me starting to try to get hold of one with a back and testing myself:could you give some indication as to what kind of IQ difference ld have to be expected between i.e. 3-6 and 30 ft?
John, that's also been my experience.
Keith, thanks for that supporting evidence!John
Seen this with the 60mm Distagon but not with the 80mm so I'd look at sensor position/ alignment
Well, sensor position and alignment for me is what I believe the Americans call a "crap shoot". I have three 500 C/M bodies, all getting on for forty years old and in varying states of wear, and now the SWC as well, also nearly forty. None of them have been serviced or collimated or whatever it is you are supposed to do. I am quite sure that when I swap around between these with various equally elderly lenses that the idea of 10 micron tolerances between the sensor plane and the lens or whatever is just laughable. Nonetheless, my shots are mostly in focus and when it does go wrong it always seems to be down to human error. The only thing I have done (and always do with a "new" body) is to very gently adjust the lower magazine "hooks" so that the CFV back is really a very snug fit. No slop.John
Opens entirely fresh Pandora Boxes, copiously stuffed with clouds of misinformation and opinion made fact.Rob C
It's a wonderful thing that these old beauties can keep on doing their thing in this digital age.


text:
I am about a year into my 1st surgery, but had a revision in the middle of January since my right breast was higher/tighter in comparison to my left. My surgeon and I agreed to a revision in which the right crease would be lowered. Currently, I wonder if the crease is two low and will not smooth (maybe bottoming out?). When I go over my right breast with a finger, I can feel a slight dip. Please let me know if this can be fix with time or something non-surgical... or should I expect another revison.
How Long Will It Take for my New Crease to Smooth out with the Old? (photo)
Doctor Answers 8
Breast augmenation and crease
Sorry but the photos are microscopic. They are really small and hard to view in the post. Can't say much.
Crease Issues After Breast Augmentation #breastimplants
Your photos are very tiny. It looks like the folds are more even but you look like you have more droop to the left breast. I can not tell if the right one looks bigger or not. This is one of those cases where only an in-office exam will yield the best opinion. You possibly may need another revision surgery.
How Long Will It Take for my New Crease to Smooth out with the Old?
To me the result is acceptable and any further operative intervention is most likely a error. Best to have realistic expectations.
You might also like...
Revision surgery to correct uneven inframammary creases
Your photographs are really small and are not too helpful. It looks like your inframammary creases were fairly even after the first surgery and now the are uneven. To correct this asymmetry you will need a revision surgery.
Crease Issues
I am terribly sorry to say that it appears like your right implant has gone too far in the other direction. It now appears to be too low. Unfortunately, it will require another surgery to fix this issue.
You are not the first or only person to have this problem. Revision surgery is technically more difficult than primary surgery, even if it seems 'minor', and revision surgery has a higher risk than primary surgery for another revision surgery.
If your doctor is not expert in revision surgery, you may benefit from visiting a few in consultation. Just be sure that he has photos of the same kind of problem you have.
Best of luck, you will eventually get the results that you wanted and deserve!
Learn more: http://www.drminniti.com
Inframammary crease issues
It looks in the tiny photos like the creases were pretty level after the revision but that the one side is bottoming out. If that is the case, no non-surgical solution exists and you will need another revision.
Reviews (1819) Photos (6070) Q&A (4499) Forum (164) Doctors How Long Will It Take for my New Crease to Smooth out with the O
Unfortunately, the photos are too small to be helpful in looking at the problem. As far as I can see the folds looked pretty even after the first surgery, and now look rather uneven. If I am correct, it looks like you may need another revision. Please consider reposting with larger images.
Best wishes.
The infra mammary fold will not migrate after breast augmentation revision.
If the infra mammary crease is not symmetrical with the opposite side is unlikely that anything short of a revision will be necessary to correct the problem.
Learn more: http://www.zubowicz.com/
These answers are for educational purposes and should not be relied upon as a substitute for medical advice you may receive from your physician. If you have a medical emergency, please call 911. These answers do not constitute or initiate a patient/doctor relationship.


text:
Blue Sphere (ブルースフィア Buruusufia?) is an intermediate Water-elemental spell in the Tales series.
Arte Description and History
When activated, the user creates a large water bubble above their enemy, which the user releases a moment later, splashing upon contact with the ground. Through his "Arte Tuning" special ability, Rowen J. Ilbert can increase the size of the bubble before it is released.
Mothership Titles
- Tales of Xillia - Rowen J. Ilbert, Presa, Roparde (Blue Sphere)
- Tales of Xillia 2 - Rowen J. Ilbert, Muzét, Presa, Fortune Stepper (Blue Sphere)
Mobile Titles
- Tales of Link - Rowen J. Ilbert, Muzét (Blue Sphere)


text:
Photo Flash: A Glimpse at Arena Stage's RUINED!
Arena Stage at the Mead Center for American Theater produces the first in-the-round staging of Ruined, the 2009 Pulitzer Prize winner for drama by Arena Stage Project Resident Lynn Nottage and directed by Resident Playwright Charles Randolph-Wright (Director of Arena Stage's Duke Ellington's Sophisticated Ladies).
Ruined is the stirring tale of Mama Nadi, a mother figure loosely based on Bertolt Brecht's Mother Courage and Her Children, who provides refuge for women affected by civil war ravaging the Democratic Republic of Congo. The production features an expanded company with cast members playing live music and additional ensemble roles featuring University of Maryland students. Ruined runs though June 5, 2011 in the Fichandler Stage.
Tickets may be purchased online at www.arenastage.org, by phone at 202-488-3300 or at the Sales Office at 1101 Sixth St., SW, D.C.
Jeremiah W. Birkett and Babs Olusanmokun
Lawrence Redmond, Rachael Holmes, and Clifton Duncan
The Cast
Donnetta Lavinia Grays, Rachael Holmes, and Jamairais Malone
Jamairais Malone
Jenny Jules and Rachael Holmes
Rachael Holmes and Donnetta Lavinia Grays


text:
Cecil Township supervisors
• Date: April 1
• Action: Supervisors set a pair of public hearings starting at 6 p.m. April 22 in the township meeting room, the first of which will deal with a new property maintenance code ordinance. The second, to be held immediately following the first public hearing, will deal with a conditional-use application for In and Out Grocery for installation of a canopy and gasoline dispensing pumps. The grocery is at 3369 Millers Run Road, and the applicant is Sagar Ukani.
Supervisors agreed to submit a grant request through the state Department of Conservation and Natural Resources for additional development in Klinger Park, off Klinger Road near Southpointe. The five-member board also authorized the township engineer to prepare plans and cost estimates for the DCNR grant for an amount not to exceed $3,500, and authorized Don Gennuso, township manager, to hire a cerftified appraiser to provide information for the DCNR grant applications.
Superviors approved a subdivision plan for Quattro Investment Group for the first phase of a three-building office complex in Southpointe II West Plan.
The board accepted a bequeathed amount of $11,851 from the estate of Geraldine Checca, with the money to be spent on recreation.
Supervisors extended the lease of the former municipal building for use by District Judge Valarie Costanzo until December 2013, at the same rate on a month-to-month basis. Gennuso said the township is in need of expanded space for the public works department and is considering using the space now occupied by the magisterial office.
• Next meeting: 7 p.m. May 6 at the municipal building
Burgettstown council
• Date: April 1
• Action: Council members voted to include an additional $25,000 for a construction project associated with repairs on the Shady Avenue Bridge. The roughly $1 million project is a joint effort between the federal government, state and borough. Burgettstown will cover 5 percent of costs, the state 15 percent and the federal government 80 percent. The additional money will be used for unexpected utility relocation costs.
The council also voted to purchase a backhoe for the road crew at a cost of about $17,000.
It was announced that the Washington County Redevelopment Authority approved a construction plan submitted by the borough for a resurfacing project on Lower Center Avenue.
• Next Meeting: 7 p.m. May 6 at the municipal building
Midway council
• Date: April 1
• Action: Council members voted to purchase additional insurance for the gymnasium at the municipal building. The council is looking into opening the gym to pickup basketball on a weekly basis.
• Next Meeting: 6 p.m. May 6 at the municipal building
Join the conversation
To comment and read comments on the article, please log in as a subscriber
Already a print subscriber? Your current O-R print subscription includes digital access. Fill out the "I am a subscriber" registration form to activate your digital access


text:
Girls hockey: Bemidji dominates Crookston 5-0
BEMIDJI — Playing at a quick pace, moving the skates and passing to the open teammate are aspects of the game that the Bemidji girls hockey players work on every day at practice.
Tuesday night at the Bemidji Community Arena those drills paid dividends as the Lumberjacks dominated Crookston 5-0.
"This is the type of performance we hoped to see," said BHS coach Jackie Robertson whose team improved to 3-5-2. "The effort has been there all year but the difference is that we've been playing teams like Warroad and Roseau. I expected the girls to play this way again tonight."
The Lumberjacks were a step ahead of the Pirates all night long. In the opening period they outshot Crookston 13-5 but neither team was able to find the net.
"Every day we work on breakouts and passing," Robertson said. "We repeat those drills all the time and it was nice to see them work in a game situation."
On the few occasions that the Pirates threatened, Bemidji goalie Emily Frazer stood tall. The Jacks offense generated many more scoring opportunities but Crookston netminder Lexie Cormican also was up to the task in the opening 17 minutes.
The tide turned in the middle session, however, and starting the onslaught was Kelsey Isaacson whose shot from the blue line deflected off traffic and past Cormican 1:42 into the period.
Less than four minutes later the Jacks found the net again when Savanna Hanson gained control behind the Pirates net and centered to Madison Schultz who was stationed in the slot. Schultz' shot was stopped by Cormican but Jacie Lalli was camped at the right post and was in the right spot at the right time to stuff home the rebound.
With 10:13 to play in the stanza Bemidji notched the back-breaker when Isaacson kept the zone at the left point and took a low shot. Cormican made the initial save but she couldn't control the carom and Megan Dondelinger zipped it between Cormican's pads.
The Lumberjacks outshot Crookston 18-6 in the period and continued that trend in the final stanza, sending 10 more shots on the Pirates net.
Midway through the session BHS was playing shorthanded when the defense blocked a shot and the rebound deflected to center ice. Dondelinger was the first player to the puck and she beat Cormican on the shorthanded breakaway.
A few minutes later Isaacson capped the scoring with a goal from the slot area.
Cormican finished with 36 saves while Frazer needed 18 stops to record the shutout.
On Saturday Bemidji will head to Warroad for the second game of the home-and-home series. A few weeks ago the teams tied 1-1 in Bemidji.
Bemidji 5, Crookston 0
Crookston 0 0 0 - 0
Bemidji 0 3 2 - 5
First period - No scoring
Second period - 1, Bem, Isaacson (unassisted) 1:42. 2, Bem, Lalli (Hanson, Schultz) 5:36. 3, Bem, Dondelinger (Isaacson) 10:13.
Third period - 4, Bem, Dondelinger (unassisted) 8:01 SH. 5, Bem, Isaacson (Hietala) 8:59
Saves - Cormican (Crookston) 13-15-8-36; Frazer (Bemidji) 5-6-7-18
Penalties/minutes - Crookston1/2; Bemidji 1/2


text:
Auburn Township
Damian M. and Sevin M. Gallo sold a home at 10740 Crackel Road to Delta Trust for $221,000.
Jason and Lindsay Watson sold a home at 157 Chadwick Court to William R. Carpenter and Darlene P. Fleming for $272,000.
Bainbridge Township
Cynthia F. Harris sold a property at Akron Street to Jason Morales for $2,800.
Valley Energy Systems Corp. sold a home at 17975 English Drive to Frank Arsena, Jr., for $144,000.
Federal National Mortgage Association sold a home at 17095 Catsden Road to Martha Boland, LLC for $139,000.
Burton Township
Federal National Mortgage Association sold a home at 15190 Old Rider Road to Arms Trucking Co. for $160,800.
Burton Village
Jeremy and Rebecca Klink sold a home at 14452 Hickox Street to Citimortgage Inc. for $83,400.
Chardon City
Marion Steinbrunner sold a home at 303 South Street to Bank of New York Mellon Trust Company for $93,400.
Chester Township
Fannie Mae a.k.a. Federal National Mortgage Association sold a home at 8060 Oxford Lane to Mark and Anne Vidmar for $177,500.
Claridon Township
Michael and Stacy Hackett sold a home at 13721 Mayfield Road to Citibank N.A., Trustee for $53,400.
Aquilla Village
Kimberly Crowley sold a home at 202 Turner Drive to Fannie Mae a.k.a. Federal National Mortgage Association for $50,000.
Middlefield Township
James A. and Martha G. Miller, Trustees sold a property at chipmunk Lane to James J. and Linda H. Miller, Trustees for $135,000.
Middlefield Village
Joseph A. Jr., and Georgia A. Puzder sold a home at 15099 State Avenue to Fannie Mae a.k.a. Federal National Mortgage Association for $76,700.
Munson Township
David T. Hellard and Sandra Kroll Hellard sold a home at 9710 Wilson Mills Road to Nicholas Keglovic and Michelle Nicastro for $300,000.
Brian R. Dudich sold a home at 10486 Mayfield Road to Federal Home Loan Mortgage Corporation for $100,000.
Fannie Mae a.k.a. Federal National Mortgage Association sold a home at 11903 Bean Road to Caitlyn M. McCaskey for $84,900.
Newbury Township
Amy Munn sold a home at 15406 Munn Road to Angela J. Allen for $140,000.
Russell Township
Denise Musgrave sold a home at 8398 Riverside Drive to Morequity Inc. for $146,700.
Andrew B. Zelenkofske, Trustee sold a home at 117 Partridge Lane to Merrill Lynch Credit Corporation for $500,000.
Robert L. Ragley sold a home at 7460 Hunters Hollow Trail to Thomas J. Rempe for $ 240,000.
South Russell Village
Rosemary B. Moroney, Trustee sold a home at 1412 Bell Road to David Royce and Tara Michele Martin for $185,000.


text:
S/O Satyamurthy Promotional Song HD - Allu Arjun and Devi Sri Prasad - Maa Tv
Thu, Apr 02, 2015, 01:43 AM
S/O Satyamurthy is an upcoming movie Allu Arjun and Trivikram Srinivas. This movie is the second one in the combination of Allu Arjun and Trivikram Srinivas and it is slated for a relese on 7th of April. This movie is being produced by D. V. V. Danayya and S. Radha Krishna on Haarika & Haasine Creations banner. Music of this film is scored by Devi Sri Prasad. Watch tthe video to have a glimpse at the promotional song of this movie . . . .


text:
The structure at 459 I Street NW occupied by BicycleSPACE would be razed under plans by IBG Partners to construct a new apartment building. Business owner Erik Kugler has responded to the plans on the BicycleSPACE blog.
According to the timeline, we will only get one complete season in before construction is started which is far from being enough time to recoup our initial expenses and loans. We are very encouraged that IBG has requested that we be part of the new project, has initiated talks to relocate us to a new space several doors down the street, has discussed their desire for our uninterrupted operation during construction, and has suggested a lease to accommodate our capacity during the transition. This would not only ensure our survival, but would also provide us with a platform to thrive in the long term.
I think we are all very hopeful that our local bike shop is able to continue uninterrupted operation.


text:
Take an Additional $10 Off AC Kits. Use Coupon Code ACKIT10
Saab 9000 Parts
The Saab 9000 is an executive car produced from 1984 to 1998. Established in 1945, Saab was a Swedish car manufacturer whose headquarters were in Trollhattan. Saab became the first company to introduce diagonally split dual brake circuits in their cars in 1963. In 1978, Saab entered an agreement with Fiat, which saw the release of Saab's first luxury car, the Saab 9000. The early 2000s saw the release of the Saab 9-2X and the Saab 9-7X under the direction of General Motors which had fully acquired the company in 2000. Some of the well-known Saab models are the Formula Junior, 9-5 and 9000.
The Saab 9000 was released in three versions: the 9000 CC, CD and CS. It featured a 2.0L/2.3L I4 or 3.0L V6 engine. Saab 9000 cars were available in 4-door sedan and 5-door liftback body styles. The vehicle was built on the Type Four platform. It was equipped with a 4-speed automatic/5-speed manual transmission.
If any of the auto parts in your Saab 9000 are not working properly, you need to replace them as soon as possible. Buy Auto Parts sells a wide range of car parts at unbeatable prices. We stock genuine OEM replacements and premium aftermarket parts. All our car parts are tested thoroughly and come with a warranty. We provide free shipping on all orders above US $99. We stock parts such as AC kits and fuel pumps for your Saab 9000. Take a look at the full list below for all of the Saab 9000 replacement parts we carry. If you do not see the part you need, give us a call and we can find it for you.
To place an order for your car part, you just need to select the right year, make and model of your car on our online catalog. As we have warehouses all across the country, Buy Auto Parts will make sure your orders are delivered on time.
Making sure our customers get the right part at the best price is our top priority. For any assistance, you can call our toll-free support line at 1-888-907-7225 or email us at [email protected]. Our US-based sales and support teams are here to answer all your questions about our car parts.


text:
Have Honda Questions? Ask a Honda Repair Expert.
Disconnect the negative battery cable. If so equipped, disable the Supplemental Restraint System (SRS).
On1990-93 Accords, remove the steering wheel.
Unplug the ignition switch connector.
Insert the key and turn it to the O position.
If present, remove the tape on the switch wires. .
Remove the two screws securing the switch, then remove the switch.
Fig. 1: The switch is secured by two screws
To install:
Make certain the recess of the switch aligns with the tab of the lock housing. Insert the switch and install the retaining screws.
If applicable, install the switch cover and retape the wires.
Remove the key.
Connect the wiring harness to the ignition switch.
Reinstall the steering column covers.
Install the steering wheel or any other applicable trim panels.
If applicable, enable the SRS.
Connect the negative battery cable.
Ignition Key Cylinder:
Remove ignition switch as describedRemove key light case from lock body, if equipped. Place ignition lock in the I position. Insert suitable punch into hole on lock cylinder housing and depress pin, then remove lock cylinder from housing.
Remove the Steering Column Shroud completely:


text:
WBEZ News
Art and Incarnation with Dr. Andrew McKenna
The Loyola University Museum of Art (LUMA) exhibit Back to the Future: Alfred Jensen, Charmion von Wiegand, Simon Gouverneur, and the Cosmic Conversation focuses on three American abstract artists who created works on spiritual themes from the 1940s through the 1980s. Although Jensen, von Wiegand and Gouverneur did not know each other, their works express common yearnings of the post–WWII generation. While the Cold War ushered in a period of cynicism, these artists pursued positive, life-affirming themes of unity and harmony. They delighted in the colorful patterns of sacred geometry and mathematical patterns found in the natural world. Dr. Andrew J. McKenna, Loyola Professor of French Literature, examines how the extent of the spiritual claims of these artists is in inverse proportion to the recognizable figural content of their works.
Dr. Andrew J. McKenna, professor of French language and literature at Loyola University in Chicago, earned a Ph.D. in Romance Languages [French & Spanish] from Johns Hopkins University after receiving his B.A. in French from Holy Cross College. In addition to acting as the host of the French club, he teaches courses in French Literature of 17th, 19th, 20th centuries, Stylistics, French culture and civilization, and Masterpieces of European Literature and Comparative Literature (in translation). For the decade between 1996 and 2006, he was the Editor-in-Chief of Contagion: Journal of Violence, Mimesis, and Culture, 1996-2006. He presently serves on the Board of the Raven Foundation. Back to the Future continues through November 18. The exhibit is generously funded in part by The Judith Rothschild Foundation and the Terra Foundation for American Art.
Recorded Tuesday, October 27, 2009 at Loyola University Museum of Art.


text:
pictured: my new Kromski Minstrel
Hello and welcome! I'm a knitter, photographer, designer and the creative director at Brooklyn Tweed. I use this notebook as a space to record inspiration and write about my creative work both inside and outside of BT. Thanks for reading, and don't be a stranger—I love hearing from you!


text:
This add-in requires one of the following applications:
Need help finding your version?
When this add-in is used, it
This app displays standard SharePoint task lists on your site as a task board with one column for each option in the status column of your task list. This means that the number of columns and their titles are completely customizable. Just like physical task boards common in Scrum or Kanban methodologies, you can change status of your task by simply dragging the "sticky-note" to Another column.


text: We went to Jekyll Island about three weeks ago, I'm just now posting a picture from it due to too many irons flying around. It's one of the closest places I know to Atlanta that has driftwood beaches. My brother had visited a few weeks earlier and showed me what he found. It turned out thte place is commercialized much more than I like, but on the north end of the island you can get access to the driftwood beaches and wander to your hearts content. If you pick your vantage point well you can get shots with unimpeded ocean to the horizon. I found going there on the off season is the best time for much lower rates at the hotel, far fewer people wandering around, and the light is at a lower angle all day and helps bring out detail in the sand better. Only hassle was the wind, it seemed to have a thing going on with my darkcloth and it wanted to run away at every chance.