Disk I/O error when I try to sign in to Skype?

Sometimes you may see a "Disk I/O error" when attempting to sign in to Skype.

To resolve this problem, please make sure that you are using the latest version of Skype.

However, if the same error happens again, follow these steps:

1. Quit Skype. If you can see the Skype icon in the taskbar (at the bottom right of your screen), right-click it and select Quit. If you cannot see the Skype icon, use Task Manager to close Skype: press Ctrl+Alt+Delete and click Start Task Manager. In the Applications tab, select Skype and click End Task.

2. Make sure that you can see hidden files.

   On Windows XP:

   1. In Windows Explorer, go to Tools > Folder Options.
   2. Click the View tab.
   3. Under Hidden files and folders, tick Show hidden files and folders, and then click OK.

   On Windows Vista / Windows 7/ Windows Server versions:

   1. Click Start > Control Panel > Appearance and Personalization > Folder Options.
   2. Click the View tab.
   3. Under Advanced settings, tick Show hidden files and folders, and then click OK.

3. In Windows Explorer, navigate to the following folder:

   On Windows XP:

   • C:\Documents and Settings\\ApplicationData\Skype

   WindowsVista / Windows 7/ Windows Server versions::

   • C:\Users\\AppData\Roaming\Skype

   Where is your Windows user name.

4. Locate the folder with the same name as your Skype Name and delete it.

   This will delete your chat history. To save your chat history, copy the file main.db and the “chatsync” folder to another location. You will be able to transfer them back (described in step 6, below). Please note that we cannot guarantee your entire chat history will be restored.

5. Restart Skype and sign in with your Skype Name and password. If you forget your password,these instructions tell you what to do.
6. The folder you have deleted will be recreated. If you saved your chat history files (described in step 4, above) transfer them back into the folder with the same name as your Skype name.

How to Connect Two Computers Without a Router?

Usage?

You can easily share an internet connection between the two machines or transfer photos, music and other files from one computer to another.

Things you need:

1. Inexpensive Ethernet crossover cable

2. Network cards (Also known as LAN or Ethernet cards) - should be installed on each of your computers.

How do you do this?

Step 1: Connect Computers with an Ethernet Crossover Cable.

Note: Before connecting the two computers with a physical cable, make sure that both machine are using the same work-group. Here is step-by-step guide that explains how you can change the workgroup of your computers.

Step 2: Changing workgroup

Open the Control Panel, type “Workgroup” in the search box, and select the entry that says “Change Workgroup Name.” Click the “Change…” button, enter a Work-group name and restart the computer.

Windows 7 users can skip one step; simply type “Workgroup” in the search box in the start menu, and select the first entry, then proceed as above.

Now that the workgroups are same for both computers, connect the two computers together using the Ethernet crossover cable. Simply plug-in one end of the crossover cable into the network adapter of Computer A and connect the other end of the cable to the network adapter of Computer B.

Windows will automatically recognize the new network, and you can now easily view files and folder that the other computer has shared. Simply open Networks from the Start Menu (or the Control Panel), and you should see the other computer by its name. You can then browse any shared files on the other computer, and can even utilize shared printers.

Step 3: Share an Internet Connection Between Two Computers

Open Control Panel, enter “network connections” in the search box on the top right and select “View Network Connections.”

Right-click on the network connection you wish to share (this must be the one connected to the internet) and select Properties. Select the "Sharing" tab and then check the option that says “Allow other network users to connect through this computer’s Internet connection.” Click OK, and the other computer you have connected to this Windows 7 or Vista computer should have internet access now.

How Web applications differ's from Websites?

For example, with a web application;

■ You can create an MVC application.

■ Visual Studio stores the list of files in a project file (.csproj or .vbproj), rather than

relying on the folder structure.

■ You cannot mix Visual Basic and C#.

■ You cannot edit code without stopping a debugging session.

■ You can establish dependencies between multiple web projects.

■ You must compile the application before deployment, which prevents you from testing

a page if another page will not compile.

■ You do not have to store the source code on the server.

■ You can control the assembly name and version.

■ You cannot edit individual files after deployment without recompiling.

Note:

Typically, website projects are the right choice when one developer will be creating and

managing a website.

Web application projects are better for enterprise environments with multiple developers and formal processes for testing, deployment, and administration.

Three-Tier Architecture Vs MVC

Three-Tier Architecture

Three-tier architecture is perfectly good for describing the overall design of a software product, but it doesn’t address what happens inside the UI layer. That’s not very helpful when, as in many projects, the UI component tends to balloon to a vast size, amassing logic like a great rolling snowball.

It shouldn’t happen, but it does, because it’s quicker and easier to attach behaviors directly to an event handler (a la Smart UI) than it is to refactor the domain model. When the UI layer is directly coupled to your GUI platform (Windows Forms, Web Forms), it’s almost impossible to set up any automated tests on it, so all that sneaky new code escapes any kind of rigor. Three-tier’s failure to enforce discipline in the UI layer means, in the worst case, that you can end up with a Smart UI application with a feeble parody of a domain model stuck on its side.

MVC Architecture

In this architecture, requests are routed to a controller class, which processes user input and works with the domain model to handle the request. While the domain model holds domain logic (i.e., business objects and rules), controllers hold application logic, such as navigation through a multistep process or technical details like authentication.

When it’s time to produce a visible UI for the user, the controller prepares the data to be displayed (the presentation model, or ViewData in ASP.NET MVC, which for example might be a list of Product objects matching the requested category), selects a view, and leaves it to complete the job. Since controller classes aren’t coupled to the UI technology (HTML), they are just pure application logic. You can write unit tests for them if you want to. Views are simple templates for converting the view model into a finished piece of HTML. They are allowed to contain basic, presentation-only logic, such as the ability to iterate over a list of objects to produce an HTML table row for each object, or the ability to hide or show a section of the page according to a flag on some object in the view model, but nothing more complicated than that. By keeping them simple, you’ll truly have the benefit of separating application logic concerns from presentation logic concerns.

Separating Out the Domain Model

Given the limitations of Smart UI architecture, there’s a widely accepted improvement that yields huge benefits for an application’s stability and maintainability.

By identifying the real-world entities, operations, and rules that exist in the industry or subject matter you’re targeting (the domain), and by creating a representation of that domain in software (usually an object-oriented representation backed by some kind of persistent storage system, such as a relational database or a document database), you’re creating a domain model.

What are the benefits of doing this?

• (Easy To Maintain) First, it’s a natural place to put business rules and other domain logic, so that no matter what particular UI code performs an operation on the domain (e.g., “open

a new bank account”), the same business processes occur.

• (No Source Code Duplications) Second, it gives you an obvious way to store and retrieve the state of your application’s universe at the current point in time, without duplicating that

persistence code everywhere.

• Third, you can design and structure the domain model’s classes and

inheritance graph according to the same terminology and language used by

experts in your domain, permitting a ubiquitous language shared by your programmers and business experts, improving communication and increasing the chance that you deliver what the customer actually wants (e.g., programmers working on an accounting package may never actually understand what an accrual is unless their code uses the same terminology).

In a .NET application, it makes sense to keep a domain model in a separate assembly (i.e., a C# class library project—or several of them) so that you’re constantly reminded of the distinction between domain model and application UI. You would have a reference from the UI project to the domain model project, but no reference in the opposite direction, because the domain model shouldn’t know or care about the implementation of any UI that relies on it.

For example, if you send a badly formed record to the domain model, it should return a data structure of validation errors, but would not attempt to display those errors on the screen in any way (that’s the UI’s job).