Writing an entire engine without having any experience with shaders is really not a good idea, start with basic games before you work on a huge advanced project like an engine.

Direct3D uses a C-like language called HLSL, which is similar to the shading language GLSL used by OpenGL. Since you're talking about shaders in the context of post-processing effects I'll assume you're using fixed function pipeline functionality in D3D9 to do your 'regular' rendering, since D3D10 and beyond require you to write shaders for all your rendering tasks.

A good place to start with HLSL is the DirectX SDK, which contains a good amount of samples and tutorials on how to implement basic functionality with shaders.
I recommend you practice and experiment with shaders a lot, since they can be quite tough to wrap your head around in the beginning.
It might be a good idea to abandon the use of the fixed function pipeline altogether and force yourself to do all your rendering tasks with shaders. This will give you a much better understanding of what shaders are and what they can do.

The ShaderX books are not meant for teaching people shader programming. They contain explanations and implementation of advanced rendering techniques, so they won't be useful to you at this point.

I don't want to turn this into a 'how to build a game engine' thread, but I do hope you realize that an engine is much more than just a few systems slapped together, right?

The DXSDK samples will provide you with the basics of how to write shaders, that's pretty much it. They have advanced samples, but I've never found them to be really useful.

I actually don't have idea about any rendering teckniques. For example how to get better frame rate. Or how to render +8 lights(Maybe I can calc the most valuable lights for one object and enable them before rendering it[/quote]

Worrying about the performance of a system without having even written it is something you really shouldn't do, premature optimization mostly leads to more problems than it solves.

How your rendering system works is completely up to you. There are a lot of ways to set up a renderering system, each of them having a set of advantages and disadvantages, and each implementation of these setups can differ based on what your requirements are.
Since you're writing an engine you'll probably want to provide the option for a user to decide which setup applies to his/her needs, and add the ability for the user to implement a custom setup if required, just like you should with any other system.

The 8 lights maximum (it's actually a guaranteed minimum rather than a maximum) is a limit imposed by the fixed function pipeline, this limit does not exist in a shader-based approach where the lighting calculations are completely up to you. How lights are handled and how many lights you can include in a scene again depend on your rendering setup. There are techniques like deferred rendering and light pre-pass rendering which potentially allow for thousands of active dynamic lights in a scene while sacrificing other qualities like material variation. This is in contrast to forward rendering where you can have a huge range of materials while compromising on the amount of lights you could realistically use.

There are enough tutorials on how to build a basic shader-based rendering setup like proper forward rendering or deferred rendering, but when you get to the much more complex features a proper general purpose rendering engine should have you'll pretty much be on your own.

I don't think an "engine" means what you think it means. An engine is not related to rendering only, but to the framework that is used to create an application as a whole as well as a collection of tools for asset and content creation

He clearly stated in his second post that he has been working on other systems besides rendering too.