Всем привет!
Не секрет, что мы, программисты, минимум половину времени тратим на написание кода. Логично было бы это время как можно лучше сократить.
Однажды, когда я в очередной раз написал конструкцию NSString *, я подумал, что пора что-то менять.
Как же можно упростить себе жизнь, разрабатывая под iOS?
Статья является расширением другой статьи

При использовании UITableView в iOS приложениях достаточно часто возникает необходимость изменить его внешний вид. Как минимум – поменять цвет фона ячеек и цвет разделителей. И в общем это не проблема для UITableView в виде списка, но немного нетривиально для группированного UITableView.

Проблема состоит в том что поменяв backgroundColor ячейки в группированном UITableView результат будет отличаться от ожидаемого. Решение состоит в том чтоб изменить backgroundView ячейки. Довольно часто с этой целью используются заранее отрисованые картинки и соответственно UIImageView. Но этот способ довольно неудобен если нужно всего лишь поменять цвет фона и границ ячейки.

Так что я создал подкласс UIView для повторного использования в качестве фона ячеек. Благодаря использованию UIBezierPath его реализация тривиальна, вот практически весь код:

- (void)drawRect:(CGRect)rect
{
    CGRect bounds = CGRectInset(self.bounds,
                                0.5 / [UIScreen mainScreen].scale,
                                0.5 / [UIScreen mainScreen].scale);
    UIBezierPath *path;
    if (position == CellPositionSingle) {
        path = [UIBezierPath bezierPathWithRoundedRect:bounds cornerRadius:kCornerRadius];
    } else if (position == CellPositionTop) {
        bounds.size.height += 1;
        path = [UIBezierPath bezierPathWithRoundedRect:bounds
                                     byRoundingCorners:UIRectCornerTopLeft | UIRectCornerTopRight
                                           cornerRadii:CGSizeMake(kCornerRadius, kCornerRadius)];
    } else if (position == CellPositionBottom) {
        path = [UIBezierPath bezierPathWithRoundedRect:bounds
                                     byRoundingCorners:UIRectCornerBottomLeft | UIRectCornerBottomRight
                                           cornerRadii:CGSizeMake(kCornerRadius, kCornerRadius)];
    } else {
        bounds.size.height += 1;
        path = [UIBezierPath bezierPathWithRect:bounds];
    }

    [self.fillColor setFill];
    [self.borderColor setStroke];
    [path fill];
    [path stroke];
}

В первый раз я услышал о CQRS, когда устроился на новую работу. В компании, в которой работаю и по сей день, мне сразу сказали что на проекте, над которым я буду работать используется CQRS, Event Sourcing, и MongoDB в качестве базы данных. Из этого всего я слышал только о MongoDB. Попытавшись вникнуть в CQRS, я не сразу понял все тонкости данного подхода, но почему-то мне понравилась идея разделения модели взаимодействия с данными на две — read и write. Возможно потому что она как-то перекликалась с парадигмой программирования “разделение обязанностей”, возможно потому что была очень в духе DDD.

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

Сразу хочу уточнить что я работал только со связкой CQRS + Event Sourcing, и никогда не пробовал просто CQRS, так как мне кажется что без Event Sourcing он теряет очень много бенефитов. В качестве CQRS фреймворка я буду использовать наш корпоративный Paralect.Domain. Он чем-то лучше других, чем то хуже. В любом случае советую вам ознакомиться и с остальными. Я здесь упомяну только несколько фреймворков для .NET. Наиболее популярные это NCQRS, Lokad CQRS, SimpleCQRS. Так же можете посмотреть на Event Store Джонатана Оливера с поддержкой огромного количества различных баз данных.

Начнем с CQRS

Что же такое CQRS?
CQRS расшифровывается как Command Query Responsibility Segregation (разделение ответственности на команды и запросы). Это паттерн проектирования, о котором я впервые услышал от Грега Янга (Greg Young). В его основе лежит простое понятие, что вы можете использовать разные модели для обновления и чтения информации. Однако это простое понятие ведет к серьёзным последствиям в проектировании информационных систем. (с) Мартин Фаулер

В прошедний понедельник мне посчастливилось попасть на собеседование на Senior .Net Developer в одну международную компанию. Во время собеседования мне предложили пройти тест, где ряд вопросов был связан с .Net. В частности в одном из вопросов надо было дать оценку (истина/ложь) ряду утверждений, среди которых было и такое:

В .Net любой массив элементов, например int[], по умолчанию реализует IList, что позволяет использовать его в качестве коллекции в операторе foreach.

Быстро ответив на этот вопрос отрицательно и отдельно дописав на полях. что для foreach необходима реализация не IList, а IEnumerable, я перешел к следующему вопросу. Однако по дороге домой меня мучал вопрос: реализует ли массив все-таки этот интерфейс или нет?

Про IList я смутно помнил, что этот интерфейс дает мне IEnumerable, индексатор и свойство Count, содержащее число элементов коллекции, а также еще пару редко используемых свойств, типа IsFixedCollection(). Массив имеет свойство Length для своего размера, а Count в IEnumerable является методом расширения от LINQ, что было бы невозможно, если бы этот метод был реализован в классе. Таким образом, получалось, что массив не мог реализовывать интерфейс IList, однако какое-то смутное чувство не давало мне покоя. Поэтому вечером после интервью я решил провести небольшое исследование.

Большинство приложений провальны. Эта жестокая реальность приводит многих разочарованных разработчиков к заключению, часто подсознательному, что преуспевание в App Store — всё равно, что разбогатеть на «золотой лихорадке»: нужно быть чертовски удачливым.



Идея «удачи» — опасное успокоительное средство, облегчающее боль неудачи. А боль — это хорошая вещь. Она показывает, что что-то идёт не так. Если моё приложение потерпело крах, я хочу знать почему. Вместо того, чтобы обвинять мироздание, почему бы не посмотреть, что ребята из tap tap tap и Tapbots делают для того, чтобы снова и снова достигать успеха.

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

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

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

Велосипед

Итак, Вася долго трудился рядовым программистом, ведущим программистом и наконец стал Руководителем. У него есть команда отчаянных головорезов разработчиков в количестве двух единиц. Безусловно талантливых и знающих свое дело специалистов.

Вася получает первый заказ — надо сделать … велосипед.

Добрый день, уважаемые хабражители. Совсем недавно я закончил разработку apns-сервиса и хотел бы поделиться некоторыми особенностями работы с ним. Статья не является пошаговой инструкцией, а описывает трудности и подводные камни с которыми может столкнуться разработчик. Примеры кода буду приводить на Ruby, но все написанное актуально и для других платформ, в частности, PHP.

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

Не претендуя на библию или «настольную статью программиста» я хочу поделиться полезными находками в моей любимой IDE, не скатываясь в тупую копипасту мануалов и скучных списков хоткеев, только то, что я сам использую постоянно и над чем удивляются коллеги: «о! а так можно?»

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

То-есть народ особо не понимает сам принцип работы тем и аттрибутов.
Попробуем немного разжевать эту тему.

Для начала: что такое вообще стили? Набор значений для аттрибутов.
А где список этих аттрибутов, как получить их значения?
Styleable-ресурсы.

Давайте пока по старинке: создадим свою вьюху:

Вот признайтесь: читая Android Interface Guidelines, вам не приходила мысль, что это все, конечно, офигенно, но на старые (2.3 <) Андроиды приходиться перелопачивать половину стилей, чтобы смахивало на Holo интерфейс?

Или так: в последнем Андроиде есть ну просто офигенная фича, а вам вот нужно ее использовать?

Самое первое, что приходит на ум: ActionBar и ActionBarSherlock.
ABS — это замечательно, но одним ActionBar не отделаешься. Мы хотим Holo тему, а не только Holo бар, блин.

Эх, такой привлекательный ActionMode на списках чего стоит…

Позвольте представить вам HoloEverywhere — проект, целью которого является портирование Holo стиля, Holo виджетов и других фишек на Android 1.6 и старше.

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

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

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

Тема статьи пришла после ознакомления с отчетом rabota.ua, в котором есть результаты исследования, свидетельствующие о том, что для большинства айтишников главный мотиватор – зарплата. Вроде все ясно и понятно, но давайте посмотрим на проблему глубже.

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

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

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

Привет. Я хочу продолжить тему реализации методов машинного обучения на c#, и в этой статье я расскажу про алгоритм обратного распространения ошибки для обучения нейронной сети прямого распространения, а также приведу его реализацию на языке C#. Особенность данной реализации в том, что реализация алгоритма абстрагирована от реализаций целевой функции (той, которую нейросеть пытается минимизировать) и функции активации нейронов. В итоге получится некий конструктор, с помощью которого можно поиграться с различными параметрами сети и алгоритма обучения, посмотреть и сравнить результат. Предполагается, что вы уже знакомы с тем, что такое искусственная нейросеть (если нет, то настоятельно рекомендую для начала изучить википедию или одну из подобных статей). Интересно? Лезем под кат.

В подборке сервисы, плагины, темы и другие полезности, облегчающие работу с Twitter Bootstrap.

Стилизация

BootSwatchr — быстрая стилизация Twitter Bootstrap.

Вводная часть:

Сам инструментарий называется NDEV. Чтоб получить необходимый код (его мало) и документацию (её много), надо зарегиться на сайте в «программе сотрудничества». Сайт:

dragonmobile.nuancemobiledeveloper.com/public/index.php

Это весь «геморрой», если клиентов вашего приложения менее полумиллиона и они пользуются сервисами менее 20 раз в день. Сразу после регистрации вы получите членство «Silver», которое позволит вам бесплатно пользоваться данными сервисами.
Разработчикам предлагается пошаговая инструкция по внедрению в свое приложение на iOS сервисов распознавания и синтеза речи:

Здравствуй Хабр. Я предлагаю вам перевод статьи, с помощью которой мне стали очевидны основные возможности Core Data.

Примечание:
Член команды обучающей программы iOS Adam Burkepile любезно обновил ряд Core Data в iOS 5. — В этом посту я немного расскажу об этом.



Это руководство было полностью переписано, чтобы показать более изящный способ предварительно загрузить данные, используя только Core Date вашего iPhone.

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

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

Недавно в нашей новостной ленте появились два Героя, программисты-пекари – Борис и Маркус. Борис – хороший человек и перфекционист, а Маркус – очень скромный и серый программист, не желающий выделяться. Оба стремятся к лучшему и хотят быть полезными. Но кажется, что Маркус не очень старался.
Это новая ветка – продолжение. Сегодня сюжетная линия коснется только Маркуса. Он – главный герой.
Итак, история под катом.

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

Прочтение этой статьи: 15 минут
Осмысление методики: 10 минут
Ощутимые результаты: 30 минут