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



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

По-моему, эта статья — самое важное, что я в жизни сделал. Не самое сложное, объёмное или интересное, а важное.

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

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

Я работаю в области, которую headhunter относит одновременно и к строительству, и к производству. Речь идет об инженерных изысканиях, будь то геология, геодезия, экология. Наша глобальная задача – изучение территории для создания проекта. Работая в этой отрасли, мы сталкиваемся со словом «секретно» через шаг. Координаты – секретно, приемник – секретно, через забор перелезть – секретно, фотографировать в торговом центре – тоже секретно…

Недавно я получил от своего знакомого вопрос примерно следующего содержания:

Добрый день Михаил! Сейчас занимаюсь одной исследовательской работой. Учитывая ваш профессиональный опыт, хотел бы вас попросить ответить на вопрос:

Вы выпустили продукт, который делали целый год, потратив на разработку все инвестиции. Из 1 000 первых пользователей 995 удалили его или перестали им пользоваться на следующий же день. Опишите ваши действия.
Заранее благодарю!!!

Я начал отвечать прямо в окне Facebook, но понял, что ответ получается очень объёмный и совершенно не того формата. Кроме того, я решил поделиться этой информацией со всеми желающими. Надеюсь, кому-то она окажется полезной.

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

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

Также рискну обрисовать пути решения проблем, состоящие в том, чтобы поменять то, что можно поменять (в основном — себя), а не то, чего изменить нельзя (скажем, рынок труда).

Ошибка №1

Соискатель получает столько приглашений на собеседование, что не в состоянии их обработать.
Логичный вывод соискателя: «на рынке острый дефицит кадров, так что могу отсеивать компании как хочу, отфутболив тех, кто заикнется о коде на бумажке, сортировках или гномиках». Возможна и менее скромная вариация того же вывода: «раз меня все хотят, значит, я классный профессионал, могу всем диктовать свои условия». Звучит, вроде, логично, но абсолютно бесполезно.

Я предлагаю взглянуть на корень ошибки (да-да, это ошибка). Если соискатель получает слишком много приглашений — значит, он неправильно составил резюме. Ведь именно резюме послужило причиной лавинообразного интереса.

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

Итак, вы устали работать на дядю и решили замутить свой IT бизнес. У вас уже есть какие-то наработки или прорывные идеи. Вы уже вечерами написали все что задумывали, у вас уже есть пара заинтересованных клиентов. И вот вы гордо вышли из кабинета директора с подписанным заявлением в новую жизнь.

Вы работаете по 12 часов, вас прет, уже пошли первые доходы и уже можно сравнить их с зарплатой. И уже кажется, что жизнь налаживается. Жизнь просто изменилась. И теперь у вас будут другие проблемы. И они очень скоро дадут о себе знать.

Что же это за проблемы?

Оглавление

1. Введение
2. Инициализация приложений Prism
3. Управление зависимостями между компонентами
4. Разработка модульных приложений
5. Реализация паттерна MVVM
6. Продвинутые сценарии MVVM
7. Создание пользовательского интерфейса
   
   1. Рекомендации по разработке пользовательского интерфейса
8. Навигация
   1. Навигация на основе представлений (View-Based Navigation)
9. Взаимодействие между слабо связанными компонентами

Навигация на основе представлений (View-Based Navigation)

Несмотря на то, что навигация на основе состояний может быть полезна в сценариях, описанных ранее, тем не менее, навигация в приложении часто требует замены одного представления на другое. В Prism, такой вид навигации называется «навигация на основе представлений (view-based navigation)».

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

• Цель навигации — контейнер для добавляемых, или удаляемых представлений — может обрабатывать навигацию разными способами при добавлении и удалении представлений, или может визуализировать процесс навигации по-разному. Во многих случаях, целью навигации является обычный Frame, или ContentControl, и представления просто отображаются внутри этих элементов управления. Однако существует множество сценариев, когда целью навигации является другой вид элементов управления, таких как TabControl, или ListBox. В таких случаях, навигация может потребовать активации или выделения уже существующего представления, или добавление нового представления.
• Приложению часто будет требоваться, каким-либо образом идентифицировать представление, к которому должна быть выполнена навигация. Для примера, в web-приложениях, страница, к которой выполняется навигация, напрямую идентифицируется по URI. В клиентских приложениях, представление может быть идентифицировано по имени его типа, по расположению файла ресурсов, или множеством других способов. В составных приложениях, состоящих из слабо связанных модулей, представления зачастую определены в раздельных модулях. Отдельные представления, в таких случаях, должны иметь возможность быть идентифицированы без создания дополнительных зависимостей между модулями.
• После идентификации представления, процесс его создания и инициализации должен быть тщательно скоординирован. Это особенно важно при использовании паттерна MVVM. В таком случае, представления и соответствующая модель представления должны быть созданы и ассоциированы друг с другом во время совершения навигации. В случае использования контейнера внедрения зависимостей, такого как Unity, или MEF, при создании модели представления и/или представления может потребоваться использование особого механизма конструирования.
• MVVM паттерн позволяет отделить UI приложения от его логики взаимодействия с пользователем и бизнес-логики. Однако процесс навигации может охватывать как UI, так и логику приложения. Пользователь может начать навигацию внутри представления, в результате чего представление будет обновлено. Но часто будет требоваться возможность инициировать и скоординировать навигацию из модели представления. Важным аспектом для рассмотрения, является способность чётко разделить навигационное поведение между представлением и моделью представления.
• Приложению часто может потребоваться передавать параметры, или контекст, представлению для его корректной инициализации. Для примера, если пользователь производит навигацию к представлению для редактирования информации о выбранном клиенте, ID этого клиента, или его данные, должны быть переданы в представление, для отображения в нем корректной информации.
• Многим приложениям необходимо тщательно координировать навигацию для уверенности, что будут выполнены определённые бизнес-требования. К примеру, пользователю может быть показано всплывающее сообщение о некорректности введённых им данных, во время попытки навигации к другому представлению. Этот процесс требует координации между предыдущим и новым представлениями.
• Наконец, большинство современных приложений позволяют пользователю производить навигацию к предыдущему, или к следующему представлению. Аналогично, некоторые приложения реализуют свой рабочий процесс, используя последовательность представлений, или форм и позволяют пользователю производить по ним навигацию вперёд или назад, добавляя или редактируя данные, перед тем, как завершить задачу и отправить все сделанные изменения одним пакетом. Такие сценарии требуют некоторого механизма журналирования, для того, чтобы последовательность навигации могла быть сохранена, повторена, или предопределена.

Prism предоставляет руководство по решению этих проблем, расширяя механизм регионов для поддержки навигации. Следующие разделы содержат краткую сводку о регионах Prism и рассказывают о том, как они были расширены для поддержки навигации на основе представлений.

В этой статье я попытаюсь поделиться своим опытом в проектировании пользовательской бизнес-логики. Это явно не претендует на полноценный ликбез, т.к. я всего лишь вспоминаю то, через что прошёл лично я, какие ошибки я допустил, и как мне их удалось (или не удалось) исправить в будущем. Наверняка, опытные системные архитекторы уже все проходили и знают, однако надеюсь, что некоторые советы таки будут полезны.
Мы использовали (и используем) клиентскую часть на WPF/Silverlight, WCF сервисы и СУБД Oracle, Postrges, MsSQL. Код написан по MVVM, использована Prism для модульности и навигации. Не могу точно сказать, какие из тезисов подойдут для других платформ и языков.

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

Итак, поехали.

Spintires: The ultimate off-road challenge! — (ссылка на KickStarter)
Демо-верия предлагаемая на KickStarter линк на страничку с демо
Более ранняя демо-версия 2009 года прямой линк
Исходный код демо-версии 2009 года прямой линк

Oovee Game Studios, одна из восходящих звезд Объединенного Королевства вышла на Кикстартер с дебютным проектом «Spintiers». Событие хоть и отмеченное на известном британском новостном ресурсе Rock Paper Shotgun (что уже само по себе говорит за игру), но, к сожалению, не вызвавшее достаточного резонанса среди игроков. Причины могут быть разными и не последняя из них – жанр. Это не гоночный симулятор, не полноценный симулятор дальнобойщика, а симулятор «месителя грязи». По крайней мере, из демо-версии складывается именно такое впечатление. Однако, даже демо-версия намного глубже чем кажется, даже если не проваливаться в колею. Если присмотреться – это отличнейшая база под будущую игру, необычный сеттинг не без изюминок.

А ведь в демо, между прочим, представлен шикарный парк отечественного автомобилестроения. При должном исполнении это может сделать ее своеобразным Сталкером от мира колес. Из чрева железных монстров при переключении коробки передач доносится забористая русская речь, вокруг расстилается живописная тайга, прорезанная линиями разбитых троп и дорог, и ведь елки-палки… все действительно родное, от и до. Как так? В Британии появились поклонники колесного русского духа? Вопрос на миллион долларов.



Что еще можно сказать об этой игре? Перво-наперво то, что Spin Tires не игра, а демонстрация физического движка Havok. Техническая демо-версия, созданная специально для конкурса Havok Physics Innovation Contest.
Особенностями этой демо-версии стало наличие «физичных» покрытий (вода, грязь) и взаимодействие с ними объектов (грузовых и не очень автомобилей), деформация грязевых и водных участков ландшафта в реальном времени, очень красивое и эффектное освещение. Как это часто бывает в случае удачных решений – демо постепенно начало превращаться в игру. Именно с этим демо Oovee Game Studios и обратилась к игрокам, чтобы собрать средства на полноценную игру.

Все выше сказанное — легкий набросок собственных эмоций на базе доступной и типовой информации, которую легко можно почерпнуть в сети. А что произойдет, если копнуть глубже?

Всё нижеизложенное вымысел, основанный на реальных событиях.

Не являясь мастером писать заметки, пытался «с пылу с жару» изложить это вчера. Но просто и доступно выстроить мысли в стройном порядке «по горячим следам» не вышло.

Кроме того на личном опыте выяснилось, что описываемый подход, хоть он, на первый взгляд и кажется мне очень простым, статистически таким не является. Известное высказывание о том, что «простые вещи, они самые сложные» оказывается в данном случае верным.

«Практическое» применение данного подхода требует усилий и кропотливой работы над собой, до тех пор, пока он не станет безусловным рефлексом, пока допускаемая «неточность» не будет заметна ещё до её совершения.

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

В связи с чем, публикуя эту заметку здесь, ожидаю, что вторым «застреленным зайцем» может стать помощь кому-нибудь ещё в избавлении от подобных ситуаций.

UPD3 спасибо dimka_ben: под «однопоточностью» подразумевается особенность мышления конкретного индивидуума, когда в один момент времени он может думать только о чем-нибудь одном.

Всем привет! Сегодня я бы хотел рассказать про свой проект HackStore — альтернативный магазин приложений для Mac OSX.

Предыстория

В январе 2011 года Apple запустила Mac App Store, по аналогии с подобным магазином приложений для iOS.
Оставаясь верной своим традициям, Apple установила жесткие проприетарные условия для разработчиков. И если iOS с самого рождения была закрытой системой, то Mac OS напротив, всегда являлась открытой платформой по отношению к сторонним разработчикам. С момента появления первой OS X разработчики успели создать огромное количество как платных, так и бесплатных утилит, игр и приложений.
В момент открытия Mac App Store многие разработчики оказались перед сложным выбором. Чтобы попасть в App Store, им необходимо было изменять приложение, урезать часть функционала, менять лицензию, покупать Mac Developer Program. В противном случае им оставалось продолжать распространять свое приложение как раньше, при этом рискуя потерять пользователей.
При этом, из-за жестких требований AppStore, многие популярные и известные приложения вообще не имеют шанса туда попасть. Так, к примеру, App Store закрыт для приложений, которые распространяются с лицензиями Open Source, MIT или CCL, а также тем, которые даже незначительно меняют системные функции или оформление. Доступ к магазину приложений также закрыт для множества популярных утилит и твиков, таких как CleanMyMac, MacHider, Magician, Adium, Skype и для многих других не менее удобных и полезных приложений.

Вы наконец-то можете сделать кое-что со своим старым LCD монитором, который завалялся у Вас в гараже. Превратите его в шпионский монитор! Для всех вокруг он будет выглядеть просто белым экраном, но не для Вас, потому что у Вас будут специальные «волшебные» очки.

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

Вот несколько необычных фактов о языке C#, о которых знают лишь немногие разработчики.

1. Индексаторы могут использовать params параметры

Мы все знаем, как обычно выглядят индексаторы x = something["a"], а так же код необходимый для его реализации:

public string this[string key]
 {
   get { return internalDictionary[key]; }
 }

Но знали ли вы, что для доступа к элементам вы можете использовать params параметры x = something["a", "b", "c", "d"]?
Просто напишите ваш индексатор следующим образом:

Разработчик и дизайнер Питер Ноэджл опубликовал «Шпаргалку по графическому дизайну для Android». В ней практически все, что вам необходимо знать для создания графических элементов приложений и оформления страниц в Google Play.

Тут описаны размеры, DPI, цвета, соглашения по именам и много другой важной информации.

Кроме того даются ссылки на все важные ресурсы, такие как стандартные гайдлайны и инструменты, шаблоны и заготовки для Photoshop.

Вступление

Моя прошлая статья была посвящена особенностям строкового типа данных String в .NET. Эта статья продолжает традицию, однако на этот раз мы рассмотрим класс StringBuilder.

Как известно, строки в .NET являются неизменяемыми (не используя unsafe), а поэтому проводить с ними операцию конкатенации в больших количествах не самая лучшая идея. Это значит, что следующий код имеет весьма серьезные проблемы с нагрузкой на память:

string s = string.Empty;
for (int i = 0; i < 100; i++)
 {
    s += "T";
 }

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

Во второй части мы увидели, сколько статистики собирают на нас даже без использования сторонних (third-party) «куки»-файлов и рассказали о пользе и настройке VPN простым языком.

Сегодня поговорим о приватности в социальных сетях, благо даже в комментариях были прецеденты. Однако пока небольшое отступление.

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

I bought a return flights to the Philippines a few days ago, just checked it with incognito mode….180$ cheaper!
…
I F… KNEW IT! I kept refreshing when I was buying airplane tickets and that f…er kept going up when I hit the refresh button. It eventually went up by $100 extra dollars!
…
I had been searching for a specific itinerary for a few weeks, just checking on prices. I saw this on the front page and decided to try it out. $400 DIFFERENCE!!!!

Если вы не знаете язык, можете почитать выдержку на русском здесь. Если даже после этого вам все равно, то человечество, все-таки, вымрет. Ну да вернемся к социальным сетям.

Строковый тип данных является одним из самых важных в любом языке программировании. Вряд ли можно написать полезную программу не задействовав этот тип данных. При этом многие разработчики не знают некоторых нюансов связанных с этим типом. Поэтому давайте рассмотрим кое-какие особенности этого типа в .NET.

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

В.NET строки располагаются согласно правилу BSTR (Basic string or binary string). Данный способ представления строковых данных используется в COM (слово basic от языка программирования VisualBasic, в котором он первоначально использовался). Как известно в C/C++ для представления строк используется PWSZ, что расшифровывается как Pointer to Wide-character String, Zero-terminated. При таком расположении в памяти в конце строки находится null-терминированный символ, по которому мы можем определить конец строки. Длина строки в PWSZ ограничена лишь объемом свободной памяти.

Рассказ пойдет о 2D играх от третьего лица (вид сверху). В основном это шутеры, но и стратегия будет тоже затронута. Для простоты сравнения и понимания мы возьмем наших любимых «котяток». Да, да, именно коты нам хорошо в этом помогут.

Название оригинала: Dependency Injection in .NET
Автор: Марк Симан
Дата выхода: август 2013г.

В конце лета у нас выходит новая переводная книга «Dependency Injection in .NET» издательства Manning Publications. Хотим вашему внимаю представить перевод небольшого анонса.

Dependency Injection in .NET — это великолепное описание технологии внедрения зависимостей (DI), связанных с ней паттернов и нескольких важнейших фреймворков для такого внедрения. Симан проработал множество ресурсов (книг, журнальных статей, записей в блогах) и создал свой всеобъемлющий труд. Несомненно, автор опирается на массу самостоятельно проведенных исследований и собственный практический опыт в работе с внедрением зависимостей.

Доброго времени суток!
В этой статье я расскажу, как повысить производительность многопоточного (и не только) C#-приложения, в котором часто создаются объекты для «одноразовой» работы.
Немного про многопоточность, неблокирующую синхронизацию, использование встроенного в VS2012 профилировщика и небольшой бенчмарк.

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

Когда я пишу что-нибудь под андроид — я часто правлю XML (разметку, стили, строки, ...). Так вот в текстовом редакторе это делать не очень удобно. И я решил потратить пару часов и написать генератор XML на основе упрощенного языка разметки (типа lesscss или stylus для CSS). Все-таки NIH — очень уж соблазнительный стимул.