С выходом в свет Silverlight 4 у разработчиков появилась возможность создавать доверяемые приложения, которые могут делать вызовы к COM подсистеме Windows. Это позволяет расширять функциональности Silverlight приложений практически неограниченным образом. Все бы ничего, но примеров такого использования и реализаций немного, да и скорее всего они вызывают самые необходимые вещи в приложениях, в виде библиотек их не выпускают. Поэтому Microsoft выпустил в свет обертки Silverlight над наиболее интересными функциями COM.

У проекта Racios.com появилось свое первое мобильное приложение! Теперь Вы можете в любое время добавить свежую идею в ваш Racios план или просто свериться с ним!

Сегодня мы — команда разработчиков биржи удаленной работы PROhq начинаем публикацию серии постов об исследовании фриланс-рынка, проведённого нашими специалистами. В основу этого исследования был положен наш опыт работы на нескольких фриланс-биржах.
Первый пост будет посвящен описанию русскоязычного рынка фриланс-услуг и его проблем, а также общему знакомству с новыми решениями этих проблем, которые предлагает PROhq.

Возможно, для многих этот топик не окажется откровением, но я лично узнал об этом совсем недавно. Однако, многим начинающим разработчикам он может быть полезным.

Как известно, с самого рождения WPF болел проблемами с отображением текста. Особенно это было заметно на не крупных шрифтах (подписи к кнопкам, Labels, ListBoxes итд.) Однако, с выходом версии 4.0 Microsoft серьезно переработали вывод текста и добавили несколько полезных attached properties.

Я не буду останавливаться подробно на рассмотрении всех свойств, а приведу лишь короткий рецепт, как сделать, чтобы ваши контролы в WPF форме отображались с четким текстом. Подчеркну, что он применим к ситуации, когда вы используете стандартные контролы без особых трансформаций, анимаций и огромного текста.

Итак, достаточно добавить следующее свойства в элемент вашего окна:

<Window TextOptions.TextFormattingMode="Display" ...... />


Результат можно приблизительно увидеть здесь (по клику полное изображение):



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

Для тех, кто хочет подробнее почитать про рендеринг текста в WPF 4.0 есть замечательный блог посвященный исключительно этой теме: WPF Text Blog. Очень советую почитать вот этот пост: blogs.msdn.com/b/text/archive/2009/08/24/wpf-4-0-text-stack-improvements.aspx

UPD: Коллега посоветовал интересный пост тему рендеринга текста: www.codinghorror.com/blog/2007/06/font-rendering-respecting-the-pixel-grid.html

Вы хотите делать неунылые презентации, выигрывать переговоры и так ставить задачу так, чтобы ее с радостью быстро решали? Я тоже хочу. Удается? Иногда – да, иногда нет.

На днях я забрел на замечательную конференцию. Она называлась “Успешный руководитель” и проходила у меня в Самаре. Спешу поделиться своими эмоциями и впечатлениями.

Решил немножко покопаться в Silverlight, да смастерить на нём что-нибудь прикольное. Это прикольное, конечно, должно шевелиться, переливаться и плавно подёргиваться, ибо вебдваноль у нас или где? :). И вот тут мне пришлось столкнуться с неплохой, по сути, системой анимаций в WPF/Silverlight. Покурив MSDN, я бодренько приступил к написанию анимаций в XAML. Одну написал, вторую, третью… А потом мне захотелось сделать так, чтобы они шли в определённой последовательности. И вот тут-то я и понял, что XAML, зараза, очень избыточный. Для описания интерфейсов он подходит идеально: сразу видно, что к чему относится и надобность в визуальном редакторе отпадает чуть менее, чем полностью. Но вот когда пытаешься написать в этом XAMLе какую-то логику, начинает проявляться вся его несуразность. Покурив гугл, я был сильно удивлён тем, что большинство людей упорно пытаются впихнуть в XAML абсолютно всё. Ругаются, путаются в коде, плачут, но продолжают писать. Прямо как те мыши с кактусом, чесслово. И тут мне пришла идея аккуратно описать анимации обычным кодом на C#. Мы, так сказать, олдфаги, рисовали интерфейс прямыми вызовами к WinAPI, неужто нас какие-то анимации испугают? :)

«Если единственный язык, который вы знаете — это Java или C#, я не думаю, что вы профессиональный программист — вы как молодой плотник, который пока работал только с одним видом дерева.»
Дядя Боб

Несколько месяцев назад я начал разрабатывать приложения для iPhone. Переключение с платформы .NET и C# на Cocoa и Objective-C проходило не без приключений, но было достаточно интересным и познавательным. Скоро мне предстоит помогать осваивать новую платформу и другим разработчикам нашей компании. Поэтому решил написать серию вводных заметок, которые, надеюсь, сделают этот переход более плавным.

Здравствуйте! В нашей первой статье мы представили тех. превью проекта и немного рассказали о самом сервисе. Мы обещали предоставить бета ключи через неделю, но, к сожалению, не смогли этого сделать из-за юридических проблем и NDA. Пока наши юристы решали актуальные вопросы, мы не теряя времени, занимались своими: перерисовали интерфейс, завершили переход на Hetzner и Yandex (MDNS). Так что теперь нам действительно необходима Ваша помощь в тестах.

Работая над уменьшением связанности и размышляя о SOA пришел к идее построения типов путем композиции интерфейсов.

В классическом DDD нужно выделить домен – совокупность объектов и их связей. Но когда я применял этот принцип в жизни, встретился с двумя трудностями:

1. Если есть большой домен и кучка сервисов вокруг него, то становится сложным управление доступом к членам класса. Выглядит это так: есть объект User со свойством CreatedAt, которое я хочу разрешить редактировать только сервису MembershipService. Чтож, пишем InternalsVisibleTo с указанием MembershipService. Дальше нам нужно сделать объект, например Car, у которого есть свойство PassedDistance, которое я хочу открыть только для CarService. Опять повторяем манипуляции с InternalsVisibleTo, но тут появляется проблема: теперь Membersip может изменять километраж автомобиля, а CarService – дату регистрации пользователя.
2. DDD всё еще не дает возможности строить приложение «по кирпичикам» – просто подключая нужные модули. Говорят, что в Ruby можно, поэтому хочется такой же легкости в .Net =). А не получается всё по той же причине – домен выделен в отдельную сборку, и, подключая сервис, приходится вручную тянуть из домена все зависимые сущности, перебирая их свойства, т.к. большинство из них в новом проекте не понадобятся. Т.е. проблему связанности сервисов DDD решает, а вот связанность домена всё еще не решена.

Выход один

Итак, джентльмены, прошу минуточку внимания!

В последнее время, обсуждая какие-нибудь технологические или архитектурные штукенции, в спорах приходилось частенько упоминать, что «это же просто opinion», и давать ссылку на статью из Getting Real под названием Make Opinionated Software (по ссылке можно не ходить, ниже перевод той самой статьи).

Это простая и интересная концепция, которую я хотел бы донести до всех, ну а особенно — до руководителей проектов, чьи команды с огнем у рта и с пеной в глазах (или наоборот?) изобретающих собственные велосипеды, фреймворки, платформы, пытаясь сделать все и сразу, на все случаи жизни — все то, что кажется очень нужным, необходимым и «без этого никак».

В свое время тоже (и не раз) пройдя испытания в велосипедостроении, я уже давно придерживаюсь того же мнения, что и «37 сигналов». И они говорят нам:

Приветствую всех!
Продолжаем писать бизнес-план

Статья 1. Начало
Статья 2. Описание бизнеса

Темой этой статьи является то, что вы продаете.

Что мы продаем?

Как вы помните, я часто рекомендую вам задавать себе побольше вопросов. Сегодня не исключение.
Итак, какой вопрос является лучшим на тему вашей продукции? «Каков наш продукт или услуга?» Нет.
Нужно задавать себе следующий вопрос: «Что мы продаем?». Казалось бы, разницы нет. Ан нет, есть.
Присмотримся внимательнее: например, вы думаете, что продаете молотки, гвозди, краску, обои, ламинат. Однако клиенты у вас покупают не это. Клиенты покупают улучшенный интерьер дома, решение мелких проблем по хозяйству, и прочее. Заметили разницу? Думать о своем продукте лучше уровнем вверх, прослеживая его комплексные цели. Так будет легче позиционировать и продавать.
Вышеуказанный подход позволит вам ставить более четкие цели. В примере выше цель — обеспечить возможность ремонта, улучшения жилищных условий клиентам. Ребята из 37Signals продают не программу Basecamp для проджект-менеджеров, а возможность командам совместно управлять проектами и укладываться в сроки.

Почему это будут покупать?

* перевод «Твоя мама это неподходящий рынок для проверки»

Допустим, фирму вы уже создали, отдавать инвесторам 75% долю не хотите, а денег где-то взять надо. Помощь приходит совершенно из неожиданного места – Государства. Речь идет о 350 000 рублей, которые вам (внимание!) подарят! Но заплатить придется некоторой бюрократической возней и потерей времени. Речь будет идти о малых предприятиях, зарегестрированных в городе Москве, так как пишу по собственному опыту.



По программе содействия развитию малого бизнеса г.Москвы (в других регионах есть аналоги) любой субъект малого предпринимательства имеет возможность получить до 350 000 рублей на следующих условиях:

• Необходимо вложить не менее 50% собственных средств;
• Нужно иметь помещение и договор аренды;
• Необходимо потратить более 50% предоставляемой субсидии на покупку основных средств;
• Возмещение арендной платы из бюджета — не более 3 600 руб. за кв.м. в год;
• На расходные материалы можно потратить не более 20% субсидии.

Условия устраивают? Тогда действуем! 

Итак, этот пост будет немного «поспешным», что неудивительно для субботнего утра (оригинальная статья была опубликована 18-ого августа 2007-ого года. прим.пер.), но я хочу сослаться на этот топик в одной работе, которой собираюсь заняться этой осенью. Я планирую плодотворно поработать: создать несколько ресурсов со ссылками в интернете, которые помогут детям в создании своих первых проектов, а также в обучении таким предметам как физика, физика космоса и робототехника/электроника. Если вы знаете меня, то вы знаете, что я довольно долго изучал эти вещи. Проблема в процессе обучения этим предметам в наше время в том, что они чересчур абстрактны и часто ограничиваются теорией «на бумаге». Чтобы изучить эти предметы на уровне более высоком, чем просто знание тривиальных вещей и фактов, вы должны по-настоящему «заниматься» наукой, а не просто «читать» о них.

Существует несколько статей и моделей, которые серьезно повлияли на мое отношение к некоторым вещам, перевернули мой взгляд на подход к изучению этих вещей. Я коснусь каждой из них по-отдельности, а затем соберу вместе накопленные знания и опишу подход, который я собираюсь опробовать. Ни одна из этих статей или идей не станет ни для кого откровением, однако они производят впечатление, когда вы их читаете. Авторы проделали огромную работу и описали предмет так глубоко и детально, как я никогда не смогу.

Вторую часть, пожалуй, начну с ответов на некоторые вопросы по прошлой части. Некоторые читатели обвинили меня в бессистемности, сказав, что вот, мол, непонятно чем тут занимается, какой-то НДС в бланках смотрит. Нет, чтобы думать о более высоких материях. Понимаете, мне эти высокие теории и материи… Я внедрением уже 10 лет как занимаюсь и хочу, чтобы рано или поздно любое внедрение стало простым и формализованным процессом. Ни у кого не возникает вопрос, когда нужно взять и настроить сеть, потому что ее просто берут и настраивают, и всем понятно, как именно это нужно делать. Вот и при внедрении ERP нужно стремиться к тому же.

У нас ежемесячно выходит новая версия. Она проходит жесткий тестинг перед тем, как ее поставят клиентам. Это такая инструкция на 6 листах. И версия не выходит пока все не будет тип-топ. Тестер почти не думает, просто тестирует по инструкции и все. Проколы, конечно, случаются, но не часто, да и то мелкие. После каждого прокола карта тестирования дорабатывается. Вот и то тестирование, о котором я тут толкую, тоже должно проходить по аналогичному принципу. Есть ряд простых, мелких, но жизненноважных тестов. Просто делаешь их и смотришь на результат. Прошло тестирование успешно, значит можно продолжать разговор о внедрении, разработке ТЗ и о более высоких материях. Не прошло тестирование – до свидания. Все!

Когда книгу о бизнесе пишет очередной гуру, консультант или тренер с сомнительным опытом и достижениями, трудно решить как к ней относится. Другое дело прочесть мысли человека за одно поколение ставшего миллиардером, основавшего компанию Virgin в 18 лет (сейчас в нее входит более 200 компаний в 30 странах мира).

Это вторая книга Ричарда Брэнсона, попавшая мне в руки. Первая была «К черту все, берись и делай», она оставила неизгладимый след. Так что сомнений в том, чтобы прочесть и вторую — не было.

Книга «Обнаженный бизнес» раз в 5 толще, содержит много специфических подробностей и читалась сложнее. Но, при этом, написана в том же духе оптимизма, веры в силы каждого. Она заряжает энергией, уверенностью и содержит множество ценных мыслей, опыта и рекомендаций человека, который похоже знает, о чем говорит.

В последнее время читаю с маркером, выделяя для себя основные, наиболее интересные мысли. Их и предлагаю Вашему вниманию в качестве цитат автора:

• Суть бизнеса заключается не в соблюдении формальностей, поиске выгоды, практическом результате, получении прибыли, стремлении продать, коммерческой игре или чем-то еще. Бизнес — это прежде всего то, что вам не безразлично.
  

Топик навеян впечатлениями от докладов на swpiter и постом о том, как не продать машину :)

Как работать над стартапом и всегда оставаться в выигрыше?

Суть в чём, есть некая порция работы, которую нужно сделать перед тем, как начинать тратить свои деньги. Я попытался описать последовательность этих действий.

Картинка слева кликабельна, а ниже — текстовое описание в 12 шагах как инициировать стартап и при этом всегда оставаться в выигрыше.

1. Идея!

И так, всё начинается с идеи, которая каким-то образом пришла к вам в голову. Идея выглядит интересной и соблазнительной. Она мотивирует вас.

Самое важное в идее — это не терять мотивацию вплоть до 10 шага и тогда вы в любом случае получите для себя выгоду.

2. Детализация идеи

Необходимо хотя бы примерно ответить на эти вопросы:

• область применения
• какие задачи поможет решить
• какие инструменты применяются для решения задач
• что вы хотите получить в процессе и в результате реализации
• какие-то существенные моменты, которые вам просто необходимо изложить, чтобы не потерять в будущем

На этом этапе ещё рано отвечать на вопросы:

• сколько времени вы можете уделить (если идея вас реально интересует, вы перейдёте к следующим этапам)
• сколько на это нужно денег
• кто вам ещё нужен для реализации идеи

Это вторая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Возможно, вы захотите прочитать и первую часть «Переобучение для пользователей Subversion».

Даже если вы работаете в одиночку, то вам стоит использовать Mercurial. Так вы сможете получить все прелести контроля версий. Эта часть покажет насколько просто добавить каталог в Mercurial, чтобы с легкостью отслеживать предыдущие версии.

Часть 2. Основы Mercurial

Mercurial — это система контроля версий. Разработчики используют ее для администрирования исходного кода. У нее два основных назначения:

1. Она хранит все предыдущие версии каждого файла
2. Она может объединить разные версии вашего кода, то есть сотрудники могут независимо работать над кодом и затем объединять свои изменения

Как и обещал, выкладываю вторую часть цитат, выделенных маркером во время прочтения одной из лучших (с моей точки зрения) книг о бизнесе — книги Джима Коллинза «От хорошего к великому».

См. также (первая часть).

***

Собрание руководителей Pitney в начале года — это обычно 15-минутное обсуждение результатов прошлого года, почти всегда превосходных, и два часа обсуждения «неприятных вещей», которые могут помешать росту компании в будущем.

***


В тот момент, когда лидер позволяет себе стать главным объектом забот своих сотрудников, в ущерб действительно реальным проблемам, он встает на путь, ведущий к прозябанию, а может, и куда хуже.

Уважаемые Хабровчане, решил поделиться одним не очевидным моментом использования LinqToSql, с которым столкнулся некоторое время назад. А именно, про особенности использования каскадных Linq запросов:

Работая над очередным ASP.NET MVC проектом, и проектируя уровень доступа к БД мне потребовалось проверить качество скриптов, генерируемых Framework-ом L2C.

Что имеем (упрощенный вариант модели):

class User {
  public long Id { get; set; }
  public string Name { get; set; }
  public IEnumerable<Parameter> Parameters { get; set; }
}

class Parameter {
  public long UserId { get; set; }
  public string Name { get; set; }
  public string Value { get; set; }
}

Для получения данных написан класс UserRepository:

class UserRepository: MyProjectDataContext {
  public IEnumerable GetUsers() {
    return this.Users.ToModelUsers();
  }
}

static class RepositoryHelper {
  public static IEnumerable<Model.User> ToModelUsers(this IEnumerable<DataAccess.User> users) {
    return users.Select(u => new Model.User { Id = u.Id, Name = u.Name, Parameters = u.Parameters.ToModelParameters() });
  }

  public static IEnumerable<Model.Parameter> ToModelParameters(this IEnumerable<DataAccess.Parameter> parameters) {
    return parameters.Select(u => new Model.Parameter {… });
  }
}

пишем
var users = userRepository.GetUsers().ToList();

смотрим профайлер, и с удивлением обнаруживаем что для загрузки 10 пользователей и их параметров было выполнено целых 11 запросов.

Hg Init: Учебное пособие по Mercurial.

Mercurial — это современная распределенная система контроля версий с открытым кодом. Эта система — заманчивая замена для более ранних систем вроде Subversion. В этом простом учебном пособии в шести частях Джоэль Спольски (Joel Spolsky) рассказывает о ключевых принципах Mercurial.

Если вы использовали Subversion, то Mercurial будет непонятным. Эта часть рассказывает о главных отличиях при работе с Mercurial. Если вы никогда не использовали Subversion, то можете просто пропустить эту часть.

Часть 1. Переобучение для пользователей Subversion

В каком же я был смятении, когда программисты в моей компании решили сменить Subversion на Mercurial!

Для начала, я начал приводить всевозможные тупые причины, по которым нам не надо ничего менять. «Мы должны хранить репозиторий на центральном сервере, так безопаснее», — сказал я. Знаете что? Я был неправ. При работе с Mercurial у каждого разработчика на жестком диске хранится полная копия репозитория. Это, на самом деле, безопаснее. В любом случае, почти в каждой команде, использующей Mercurial, центральный репозиторий тоже существует. И вы можете делать резервное копирование этого репозитория со всей необходимой одержимостью. А еще можете устроить трехступенчатую защиту с Сайлонами, Штурмовиками и прелестными лабрадудлами или что там требует ваш IT-отдел.