Добрый день.

Как многие наверное знают, Павел Дуров разрабатывает новый клон What's App и прочих популярных мессенджеров на базе своего собственного протокола MTProto.

Недавно американская компашка выпустила iOS клиент под этот протокол под названием Telegram. Параллельно с этим проводится — конкурс на разработку Android клиента.
Недавно завершился второй этап, народ отправил свои поделки и я в том числе. Скажу сразу, второй этап я не прошел.

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

Разработка

Я расскажу о цикле разработки через Github, который я использую. Он был проверен в течении года на командах разного размера: 3 — 14 человек.

Существует 2 основных ветки: master и dev.

master — стабильная ветка, готовая к выкатыванию на production сервер в любой момент.

dev — ветка, над которой в данный момент работает команда.

Итак, в начале разработки master и dev ветки идентичны.

Многие знакомы с выступлением Алекса Мартелли (Alex Martelli) на Google Tech Talk под названием Python for Programmers (слайды) — в нём он чётко и лаконично рассказывает основы Питона для тех, кто уже умеет программировать, например на C, С++ или Java. По его презентации я сам учил Питон четыре года назад, перед тем как начать использовать его в преподавании программирования на матмехе СПбГУ.

Сегодня хочу представить вам интерактивный вариант этой презентации — онлайн мини-курс Python for Programmers, созданный и опубликованный под лицензией Creative Commons с разрешения Алекса. Мы добавили к его презентации интерактивных упражнений, обновили материал с Python 2.5 до Python 3.3, добавили информацию по актуальным библиотекам и разнице между 2 и 3 версиями Питона.

Предлагаю перейти на сторону зла, на темную сторону программирования. Ситхи сильнее джедаев. И печенек хватит на всех. Предупреждаю, прежде чем начнете читать далее. Характер при переходе на темную сторону портится.
Прошу под кат

Списки книг

• 25 бесплатных книг по информатике
• Шпаргалки
• CodePlex: Список бесплатных книг
• Бесплатные технические книги
• Galileo Computing (Немецкий)
• How to Design Programs: An Introduction to Computing and Programming
• Microsoft Press: Бесплатные книги
• MindView Inc
• Проект O'Reilly's Open Books
• TechBooksForFree.com
• Theassayer.org
• Wikibooks: Программирование
• Неплохая подборка, редактируемая сообществом (JIghtuse)
• Книги на Русском (telteron)

Программирование графики

Задача сортировки — это классическая задача, которую должен знать любой программист. Именно поэтому эта статья посвящена данной теме — реализации сортировки на платформе .NET. Я хочу рассказать о том, как устроена сортировка массивов в .NET, поговорить о ее особенностях, реализации, а также провести небольшое сравнение с Java.

Итак, начнем с того, что первые версии .NET используют алгоритм быстрой сортировки по умолчанию. Поэтому небольшой экскурс в быструю сортировку:

Перевод оригинальной статьи за авторством Des Traynor

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



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

Ранним утром программист спросил великого мастера:
— Я готов писать модульные тесты. К какому покрытию кода я должен стремиться?
Великий мастер ответил:
— Не переживай о покрытии, просто пиши хорошие тесты.
Программист улыбнулся, поклонился и ушел.

Немного времени спустя другой программист задала этот же вопрос. Великий мастер указал на котел с кипящей водой и сказал:
— Сколько зерен риса я должен положить в этот котел?
Программист с озадаченным видом ответила:
— Как я могу ответить наверняка? Все зависит от того, сколько людей вам надо накормить, насколько они голодны, какие еще блюда вы подаете, сколько риса у вас есть и от многого другого.
— Совершенно верно. — сказал великий мастер.
Второй программист улыбнулась, поклонилась и ушла.

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

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

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

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

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

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

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

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

К сожалению, топиков-ссылок на Хабре давно нет, так что придётся что-то написать о замечательной библиотеке PushSharp.

От переводчика:
Немало копий сломано в спорах о том, когда уместнее KISS, а когда DRY, когда лучше как можно быстрее и проще решить задачу любыми средствами, а когда стоит создавать красивые и универсальные абстракции. Натан Марц, автор популярного фреймворка Storm, используемого в Твиттере, предлагает свой вариант. Чтобы не создавать тонны бесполезного кода ради абстрактной универсальности и в то же время не позволять системе превращаться в кашу из костылей, он использует «разработку через страдание» (suffering oriented programming).

---

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

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

Я придумал такую мантру разработки: «Сначала сделай, чтобы было. Затем — чтобы было красиво. Затем — чтобы было быстро».

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

Итак, начнем с главного! Прежде, чем приступить к разработке, необходимо подробно выяснить все требования заказчика.
Для того чтобы разработать успешное приложение, нужно все делать правильно с самого начала. Основное количество конфликтов между заказчиком и разработчиком связано с отсутствием документов, определяющих детали того, что именно нужно проработать. Не всем вопросы являются обязательными для заполнения, но очень важно сразу донести до клиента значимость проработки задания с первых шагов.

Первая часть брифа: вопросы, которые помогут определить, какое именно приложение необходимо вашему клиенту

Понадобилось мне недавно сделать статичным IP на своем Windows Phone.
Пошел я искать решение в гугл. Все, что я там нашел, было связано непосредственно с настройкой роутера или полностью рутованными телефонами (мой рут накрылся после обновления до Tango), поэтому данное решение мне также не подошло. И вот, в голову пришла гениальная идея — а что если ребята из Samsung уже потрудились, однако сообщить об этом забыли? Так неоднократно было с меню Diagnosis. Напомню, через дыру в него создавали полноценный рут, запускали exe файлы без подписей и многое-многое другое. В прошлом. Снова гуглим, но это ничего не дает — никто толком не знает рабочих кодов диагностики. Хорошо. Ищем xap меню диагностики. На удивление, нашел, т.к. обычно они внедрены глубоко в ядро. Ядро было написано на нативном коде, однако интерфейс — на C#. То, что нужно! Нашел, правда, в кэше китайского ресурса на последней странице, но не суть.
Что же, в путь! Открываем любимый dotPeek от JetBrains и видим следующую картину:

Бен Кэменс обнаружил, что в выпадающем списке Shop by Department на сайте «Амазон» ховер-эффект происходит очень быстро, абсолютно без какой-либо задержки. Тем самым происходит нарушение старого, выработанного ещё в 90-х годах прошлого века правила: перед отображением пункта подменю необходим так называемый гистерезис, запаздывание.



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

С выходом .NET Framework 4.0 в состав BCL была добавлена библиотека Task Parallel Library (TPL), реализующая параллелизм на основе задач. В основе библиотеки лежат типы Task и унаследованный от него тип Task. Эти типы являются обёртками для асинхронных операций; они позволяют абстрагироваться от таких технических деталей, как, например, потоки и синхронизировать асинхронные операции друг с другом.

В этой же версии .NET Framework появился мини-framework для кооперативной отмены асинхронных операций. Состоит он из всего трёх типов:

• CancellationTokenSource — создаёт маркёры отмены (свойство Token) и обрабатывает запросы на отмену операции (перегруженные методы Cancel/CancelAfter).
• CancellationToken — маркёр отмены; позволяет несколькими способами отслеживать запросы на отмену операции: опросом свойства IsCancellationRequested, регистрацией callback-функции (через перегруженный метод Register), ожиданием на объекте синхронизации (свойство WaitHandle).
• OperationCanceledException — исключение, выброс которого по соглашению означает, что запрос на отмену операции был обработан и операция должна считаться отменённой. Предпочтительный способ генерации исключения — вызов метода CancellationToken. ThrowIfCancellationRequested.

Механизм отмены через CancellationToken является стандартным для TPL — есть перегрузки методов, принимающих CancellationToken, исключения OperationCanceledException специальным образом обрабатываются и т.д. Однако, как и в любом другом API, есть свои тонкости, хитрости, best practices.

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

Как избавиться наконец от насилия над собой в виде этих бесконечных техник? Делать то, что хочешь!
Если более развернуто, то обычно советуют работать на пересечении нескольких областей — делать:

1. то, что хочешь,
2. на что располагаешь талантом,
3. то, что служит на благо людей,
4. то, что приносит деньги.

Это просто идеальная самореализация!

Но как это сделать? Об этом обычно не говорят или неуверенно дают какие-то общие советы. Я долго копал и кое-какую методику все же нашел.

Задача: в массиве длиной N найти элемент, который повторяется больше N/2 раз.

Казалось бы, чего тут думать? Возьмём Dictionary<значение элемента, число появлений>, за один проход по массиву сосчитаем появления каждого элемента, потом выберем из словаря искомый элемент. Решение за O(N), куда может быть ещё быстрее?

Есть один нюанс: для словаря нам потребуется O(N) дополнительной памяти — в несколько раз больше размера исходного массива, и это при реализации словаря хоть хэш-таблицей, хоть деревом. Что будем делать, если наша цель — обработка сигнала неким устройством с маленькой памятью? Массив — замеры уровня сигнала, из которых один — «настоящий» передаваемый уровень, а остальные — шум и помехи. Неужели придётся для определения «настоящего» уровня возиться с хэш-таблицами и деревьями?

К счастью, нет: достаточно O(1) дополнительной памяти, и по-прежнему одного прохода по массиву.