Access Modifiers in C# Are Easy To Understand with the Right Examples

private, protected and public are access modifiers. They indicate which other code can see the code they affect:

public class Foo
{
    private int _myOwn = 1;
    protected int _mineAndChildren = 2;
    public int _everyOnes = 3;
}

public class Bar : Foo
{
    public void Method()
    {
        _myOwn = 2; // Illegal - can't access private member
        _mineAndChildren = 3; // Works
        _everyOnes = 4; // Works
    }
}

public class Unrelated
{
    public void Method()
    {
        Foo instance = new Foo();
        instance._myOwn = 2; // Illegal - can't access private member
        instance._mineAndChildren = 3; // Illegal
        instance._everyOnes = 4; // Works
    }
}

An abstract class is one that may contain abstract members. An abstract member has no implementation, so all derived classes must implement the abstract members.

A sealed class cannot be inherited. A static class is sealed, but also can only contain staticmembers.

Handling Conflicts while Merging in Subversion

Conflicts occur when Subversion is unable to merge two files together automatically. Generally, this happens when two users have independently made a change to the same area of a file. Because Subversion doesn’t actually understand the files that it merges, it has no way of figuring out which of the two versions to use. Its only recourse, in this case, is to let the user solve the conflict.

Before you can resolve a conflict, you have to have a conflict. So, let’s create a conflict. To start, check out a new working copy, which will represent the work of a second developer.

$ svn checkout file:///home/bill/my_repository/trunk/ /home/bill/ ¬
other_dev_trunk
A other_dev_trunk/hello.c
A other_dev_trunk/Makefile
Checked out revision 7.


Then, edit the file hello.c in your new working copy, and change the line

printf{"Subversion Rocks!!\n");


so that it reads

printf("Subversion is Great!!\n");


After the change has been made, commit it to the repository

$ svn commit --message "Changed to a more conservative phrase" /home/ ¬
bill/other_dev_trunk/hello.c
Sending hello.c
Transmitting file data .
Committed revision 8.


With your changes from the new working copy committed, it’s time to go back to your original working copy. Once there, edit the copy of the file hello.c that is stored there, without updating the file from the repository first. This time, change the line

printf("Subversion Rocks!!\n");


to the third, yet equally complimentary line,

printf("Subversion is Awesome!!\n");


Now, try to commit this change to hello.c.

$ svn commit --message "Decided on a more hip phrase" /home/bill/ ¬
my_repos_trunk/hello.c
Sending my_repos/trunk/hello.c
svn: Commit failed (details follow):
svn: Out of date: '/my_repos_trunk/hello.c' in transaction '9'

Per View Caching in Django

A more granular way to use the caching framework is by caching the output of individual views. This has the same effects as the per-site cache (including the omission of caching on requests with GET and POST parameters). It applies to whichever views you specify, rather than the whole site.

Do this by using a decorator, which is a wrapper around your view function that alters its behavior to use caching. The per-view cache decorator is called cache_page and is located in the django.views.decorators.cache module, for example:

from django.views.decorators.cache import cache_page

def my_view(request, param):
    # ...
my_view = cache_page(my_view, 60 * 15)

Alternatively, you can use decorator syntax. This example is equivalent to the preceding one:

from django.views.decorators.cache import cache_page

@cache_page(60 * 15)
def my_view(request, param):
    # ...

cache_page takes a single argument: the cache timeout, in seconds. In the preceding example, the result of the my_view() view will be cached for 15 minutes. (Note that we’ve written it as 60 * 15 for the purpose of readability. 60 * 15 will be evaluated to 900—that is, 15 minutes multiplied by 60 seconds per minute.)
The per-view cache, like the per-site cache, is keyed off of the URL. If multiple URLs point at the same view, each URL will be cached separately. Continuing the my_view example, if your URLconf looks like this:

urlpatterns = ('',
    (r'^foo/(\d{1,2})/$', my_view),
)

then requests to /foo/1/ and /foo/23/ will be cached separately, as you may expect. But once a particular URL (e.g., /foo/23/) has been requested, subsequent requests to that URL will use the cache.
Read more here http://djangobook.com/en/1.0/chapter13/