Как ни странно, но конструкция вида:

var string = "find this and find that".replace("find", "found");

получит на выходе «found this and find that». Но не надо никаких циклов, что бы сделать правильно, достаточно простого регекспа (точнее модификатора ‘g’):

var string = "find this and find that".replace(/find/g, "found");

и в итоге – все нашли – «found this and found that».

Так получилось, что хоть я и сторонник технологий Microsoft, последние два-три года я являюсь Mac-пользователем, а последний год – Mac является моим основным рабочим ноутбуком. Для .Net я разрабатываю в виртуальной машине, а Python, Mono, впрочем как и много чего другого – нативно.
Но заинтересовался я и Objective-C, надо же заниматься саморазвитием +) Итак начну по порядку, первым делом я пошел на официальный сайт и вошел в Developer’s Zone, где нашел статью какраз для меня – Introduction to Cocoa, пролистал и, откровенно говоря, объема статьи для понимания мне абсолютно не хватило. В итоге открыл Google, Xcode и начал писать…
Objective-C – объектно-ориентированный язык, похож на Smalltalk, и в корне отличается от всего с чем я имел дело раньше. Главное отличие – сообщения. В Objective-C мы не вызываем метод, а шлем объекту сообщение. Как же это выглядит? Примерно так:

[ialubimii learnNewProgrammingLang:@"Objective-C" toLevel:5];

Здесь ialubimii – объект, то есть я, и мне отправляется сообщение учить Objective-C до уровня 5. Но изучить язык я пока не могу, а что бы я мог обработать такое сообщение, я должен иметь для него селектор, который сможет получить и обработать это сообщение. Но для начала нам надо создать меня, экземпляр класса CProgrammer – наследника CHuman.
Классы в Objective-C определяются в двух файлах – .h и .m, первый – заголовок в котором прописывается @interface, второй – имплементация.

CHuman.h

// Импортируем главный заголовочный файл Cocoa:
#import <Cocoa/Cocoa.h>

// Объявляем класс и наследуем его от NSObject, базового объекта Cocoa:
@interface CHuman : NSObject {
    // Объявляем защищенные переменные:
    //   1. Ссылка на экземпляр строки NSString;
    NSString *name;
    //   2. Переменная NSInteger.
    NSInteger age;
}
// Объявляем публичные свойства нашего класса:
//   1. readwrite определяет тип доступ;
//   2. retain говорит о том, что тип ссылочный и нам
//       нужно удалять ссылки при удалении самого
//       объекта.
@property (readwrite, retain) NSString *name;
@property (readwrite) NSInteger age;

@end

CHuman.m

// Импортируем наш заголовок:
#import "CHuman.h"

// Объявляем имплементацию класса:
@implementation CHuman
// Говорим компилятору, что хотим синтезировать
// код для свойств name и age:
@synthesize name, age;
@end

Теперь определим класс-наследник CHuman – CProgrammer , который будет определять программиста, именно класс CProgrammer будет уметь принимать сообщения learnNewProgrammingLang:toLevel, а заодно иметь словарь своих знаний:

CProgrammer.h

#import <Cocoa/Cocoa.h>
// Импортируем заголовок класса CHuman для наследования:
#import <CHuman.h>

@interface CMan : CProgrammer {
    // Определяем словарь знаний нашего программиста:
    NSMutableDictionary *programmingSkills;
    // NSMutableDictionary является динамическим аналогом
    // NSDictionary.
}
@property (readwrite, retain) NSMutableDictionary *programmingSkills;

// Определяем заголовок селектора для сообщения:
-(void)learnNewProgrammingLang:(NSString*)name toLevel:(NSInteger)level;

@end

CProgrammer.m

#import "CProgrammer.h"

@implementation CProgrammer
@synthesize programmingSkills;
// Реализуем конструктор и деструктор, это необходимо
// для инициализации и уничтожения нашего словаря.
-(id)init {
    // Вызываем супер-конструктор.
    self = [super init];
    // Выделяем память и создаем словарь на 20 записей:
    programmingSkills = [[NSMutableDictionary alloc] initWithCapacity:20];
    // Здесь используется вложенное сообщение, то есть
    // сначала мы выделяем память под NSMutableDictionary
    // с помощью сообщения alloc, а затем инициализируем
    // экземпляр с помощью конструктора init.
    return self;
}
-(void)dealloc {
    // Удаляем наш словарь:
    // Вызываем супер-деструктор:
    [super dealloc];
}

// Реализуем объявленный в заголовке селектор:
-(void)learnNewProgrammingLang:(NSString*)name toLevel:(NSInteger)level {
    // Сохраняем сообщение в словарь знаний,
    // таким образом наш программист теперь
    // сможет запоминать то что он учит:
    [programmingSkills setValue:level forKey:name];
}
@end

Теперь необходимые классы готовы и мы можем использовать их в нашем приложении:

// Создаем экземпляр программиста-меня:
CProgrammer *ialubimii = [[CProgrammer alloc] init];
// А теперь мы можем послать сообщение, которое
// я смогу получить и обработать, выучив Objective-C.
[ialubimii learnNewProgrammingLang:@"Objective-C" toLevel:5];

А скоро я расскажу о своем небольшом проекте, разрабатываемом на Objective-C, а так же об XCode, Interface Builder… Вообщем о том, как создаются приложения под Mac на Cocoa.

Сейчас в Visual C# Highlights последним постом висит «Introducing the Expando Object». Это, наверное, третий или четвертый пост про DLR (Dynamic Language Runtime), но лично для меня самый пугающий.
Посмотрим на пример (кстати, не так давно я описывал «Enumerator в Python»):

dynamic contact = new ExpandoObject();
contact.Name = "Alexander Shvetsov";
contact.Location = "Moscow, Russian Federation";

Выглядит вполне невинно. Тем более что по сути своей это не многим больше чем оболочка для:

Dictionary<string, object> contact = new Dictionary<string, object>();
contact.Add("Name", "Alexander Shvetsov");
contact.Add("Location", "Moscow, Russian Federation");

Но к чему это может привести? По мнению MS:

• Более тесной интеграции с динамически типизированными языками;
• Простоте использования.

Трудно с чем-либо поспорить, но вот от себя очень хотелось бы добавить:

• Снижению и без того низкой планки вхождения до уровня Python’а;
• Значительному уменьшению стабильности кода;
• Появлению противников со стороны сообщества.

Кстати один противник в лице меня уже появился. Но ведь можно его (DLR) просто не использовать +)

Иногда случается что большие транзакции могут зависнуть (эксепшны, аварийный выход), в таком случае Transaction Log может вырастать до неимоверных размеров – иногда соизмеримыми с объемом данных. Если лог все же не нужен, уменьшить его объем можно простой командой SHRINKFILE:

USE [MyDatabase];
BACKUP LOG [MyDatabase] WITH TRUNCATE_ONLY;
DBCC SHRINKFILE(MyDatabase_Log, 10)
GO

В гугле почему-то очень трудно найти внятный пример использования.

Если задача об идентификаторах была скорее на логику, то вот небольшая задача на внимательность.

Как будет работать такая конструкция в C#?

while (value --> 0)
{
    ...
}

Одним словом, что делает такая стрелочка?

Отнють нетривиальным можно назвать возможность выставлять различные модификаторы доступа для get и set в свойствах. Все очень просто, а между тем и очень полезно.

public string Name
{
    get { return this.name; }
    internal set { this.name = value; }
}

Update: Жаль, нельзя так же определять свойства в интерфейсах.

Сейчас достаточно популярен фреймворк ASP.NET MVC. Сам по себе «паттерн» MVC достаточно интересен, но не всегда применим. Конечно же он накладывает множество ограничений и на разработчика, и на приложение. Но ведь иногда можно почерпнуть отдельную часть, без ущерба для кого-либо, в данном случае это механизм URL роутинга, который всемте с .Net 3.5 SP1 вошел во фрэймворк в виде неймспейса System.Web.Routing.
Итак по порядку, для начала проставим все необходимые референсы и параметры в web.config:

<?xml version="1.0"?>
<configuration>
    ...
    <system.web>
        <compilation debug="true">
            <assemblies>
                ...
                <add assembly="System.Web.Routing, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
                <add assembly="System.Web.Abstractions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
            </assemblies>
        </compilation>
        ...
        <httpModules>
            <add name="UrlRoutingModule" type="System.Web.Routing.UrlRoutingModule, System.Web.Routing, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
            ...
        </httpModules>
    </system.web>
    ...
    <system.webServer>
        <modules runAllManagedModulesForAllRequests="true">
            <add name="UrlRoutingModule" type="System.Web.Routing.UrlRoutingModule, System.Web.Routing, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
        </modules>
        ...
    </system.webServer>
</configuration>

Здесь мы сделали следующее:

1. Добавили референс на System.Web.Routing в compilation/assemblies;
2. Добавили модуль UrlRoutingModule в system.web/httpModules (для поддержки ASP.NET Development Server) и в system.webServer/modules (для корректной работы IIS7);
3. Проставили значение аргумента runAllManagedModulesForAllRequests который так же необходим для корректной работы IIS7, без него мы бы получали 404 на все запросы к неизвестным типам файлов, то есть мы бы смогли роутить только запросы оканчивающиеся на *.aspx, которые IIS направляет приложению.

К сожалению, установка runAllManagedModulesForAllRequests может сказаться на скорости выдачи IIS статического контента. Это вызвано тем, что IIS будет загружать все управляемые модули для всех запросов, то есть при каждом обращении к файлу изображения, будет инициализироваться ScriptModule. Поэтому на высоконагруженных системах лучше выделять отдельную сущность сайта в IIS для обработки запросов к статическому содержимому приложения.
Далее нам нужен класс RouteHandler, который будет обрабатывать наши роутинги, для этого он должен реализовывать интерфейст IRouteHandler, то есть метод GetHttpHandler(), возвращающий IHttpHandler, обработающий запрос:

using System;
using System.Web;
using System.Web.Compilation;
using System.Web.Routing;
using System.Web.UI;

/// <summary>
/// Represents common route handler.
/// </summary>
public class RouteHandler : IRouteHandler
{
    private string path = "";

    /// <summary>
    /// Creates and instance of route handler by
    /// virtual path.
    /// </summary>
    /// <param name="VirtualPath">Handler virtual path.</param>
    public RouteHandler(string virtualPath)
    {
        this.path = virtualPath;
    }

    public IHttpHandler GetHttpHandler(RequestContext requestContext)
    {
        // Copying route data to context.
        foreach (var value in requestContext.RouteData.Values)
        {
            requestContext.HttpContext.Items[value.Key] = value.Value;
        }

        return BuildManager.CreateInstanceFromVirtualPath(this.path, typeof(Page)) as Page;
    }
}

Здесь так же присутствует узкое место, а именно вызов CreateInstanceFromVirtualPath. Впрочем, оценить производительность BuildManager мне не удалось, и данное утверждение по сути является лишь предположением.
Последний шаг настройки – добавление роутинга в RouteTable, для этого легче всего использовать Global.asax:

protected void Application_Start(object sender, EventArgs e)
{
    System.Web.Routing.RouteTable.Routes.Add(
        new System.Web.Routing.Route("Users/{UserName}", new RouteHandler("~/Users.aspx")));
}

Вот и все, сама же Users.aspx может выглядеть примерно так (допустим наш запрос содержив себе так же и GET параметр «/Users/ashvetsov/?Action=Test»):

using ...;

public partial class _Users : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        if (Context.Items["UserName"] != null) // "ashvetsov"
        { }

        if (Request["Action"] != null) // "Test"
        { }
    }
}

Просматривая нэймспейс System.Diagnostics, обнаружил много интересного, но самым интересным показался аттрибут DebuggerStepThroughAttribute. Сегодня же, нашел интересный пост посвященный тому, как применять этот аттрибут к свойствам (очень неочевидно, но логично):

public object MyProperty {
    [DebuggerStepThrough]
    get { return this.myobject; }
}

В результате же на таком вызове мы не будем проваливаться в геттер:

object one = two.MyProperty;

Самое производительное и ничем не ограниченное решение задачи об идентификаторах:

def Increment( string ):
    for i in range( len( string ) - 1, 0 ):
        if string[i].isdigit():
            val = int( string[i] ) + 1
            if val == 10:
                string[i] = '0'
            else:
                string[i] = str( val )
                break
        else:
            break
    return string

Суть его в том, что пробегая строку от последнего символа к первому, мы проверяем цифра ли это (на C# для этого можно проверять код символа, на питоне же я использовал метод string.isdigit()) и прибавляем 1 к ней, если результат меньше 10, мы можем на этом остановиться, если же равен 10 – перейти к следующему символу. В случае же если мы достигнем префикса – мы получаем либо обнуленный идентификатор, либо можем выкинуть исключение о переполнении.

Преимущества этого решения в следующем:

1. не нужно знать превикс;
2. длина строки может быть любой и не ограниченной типом используемой переменной;
3. скорость работы значительно выше чем разбор строки регулярным выражением.

Даже после многочисленных подсказок, далеко не все собеседуемые смогли решить задачу.

Проводя собеседования я всегда давал одну из самых моих любимых задачек на логику и внимание в программировании. Задача простая:

Имеется идентификатор платежа, например INV03329993892129, нужно придумать как этот идентификатор инкрементировать и описать метод, позволяющий это сделать. Префикс постоянный. Длина идентификатора должна быть неизменна.

Жаль, что первым делом я видел лишь демонстрацию знания регулярных выражений.

Правильный ответ: http://ashvetsov.wordpress.com/2009/08/06/ответ-на-задачу-об-идентификаторах/