• Интернет по всему миру: Япония и Сингапур
    +1
    Живу в Сингапуре, домашний интернет (Singtel) говно и дорого (около 60S$ в месяц, честно забыл цену ибо первые пол года бесплатно)
  • Программисты не могут написать алгоритмы без помощи: ещё раз про интервью
    +8
    Умею писать алгоритмы на листе так как учился в такие времена и таких местах что даже олимпиада по программированию проходила на листочках с карандашем )) Первые свои программы на С++ писал в тетрадке
  • Иммиграция вместе с Крымом в Россию
    –1
    <sarcasm_mode_on>
    Ну как где, забрал наверное у репрессированных татар или украинцев или тп. )))
    <sarcasm_mode_off>
  • Эффективный JSON с функциональными концепциями и generics в Swift
    0
    Самые лучшие технические статьи набирают так мало плюсиков ((
  • Особенности создания NSString
    0
    Вы правы, затупил.
  • Особенности создания NSString
    0
    Аналогичную оптимизацию строковых констант выполняет и gcc при компиляции кода на Си. Например,
    #include <stdio.h>
    void main(){
    char *a = «123456789»;
    char *b = «123456789»;
    printf("%p %p\n", a, b);
    }

    Здесь к char * надо добавить const что бы дальнейшие рассуждения были верными
  • Простой JSON Schema валидатор для Objective-C
    0
    давно себе сделал подобный велосипед ) потому как нужен был мне
  • Continuous Integration для мобильных и веб-проектов
    0
    >>> Чтобы iPhone перейдя по ссылке начал устанавливать приложение, эта ссылка должна быть вида itms-services://?action=download-manifest&url=http://server/projectname.plist

    У них там свой testflight — with blackjack and hookers. Чтобы враги не украли( дизассемблировали ) драгоценные приложения. git, небось, тоже сами хостят.
    Корпорасты иногда выдвигают подобные требования…
  • Continuous Integration для мобильных и веб-проектов
    0
    >>> А как с номерами версий у вас устроено дело?
    xCode plug-in умеет сам версию в нужный Info.plist «вшивать».

    >>> Допустим, есть текущая версия 7.0, над которой все работают, а надо выпустить срочно 6.4 SR, которая решает какие-то проблемы.
    То есть, вопрос «как вы пользуетесь git tag/branch»?
    Каждый выбирает для себя. А иногда за вас выбирает начальство и заставляет сидеть на уродливом SVN…
  • Continuous Integration для мобильных и веб-проектов
    0
    >>> Там все только начинается, еще даже не сделан окончательный выбор инструментов.

    Итого, я пришел к следующему набору job-ов и инструментов.
    Надеюсь, будет вам полезно.

    1. OTA (Over the Air) distribution
    Jenklins xCode plug-in + script для заливки в testflight. «Родной» testflight pug-in пока нормально настроить не получилось
    Иногда собираю под симулятор когда QA «дрались» за device-ы (один смотрит на device, а другой — увы через iphonesim).

    2. Static analyzer.
    Clang «scan-build» с принудительным выставлением компилятора в тот, что поставляется с xCode

    3. Unit test (Sen testing kit)
    Обычный xcodebuild (не привязывая к application/library в качестве dependence).
    Для них можно считать coverage с помощью gcovr + cobertura plug-in

    4. gh-unit тесты
    Гоняются через «iphonesim» и скриптовую магию (см. презентации по ссылкам выше). Coverage для них пока считать не умею

    5. UI тесты
    calabash + Jenkins TAP plug-in

    6. Документация
    Пока только appledoc. Latex еще не осилил (да и вряд ли понадобится).

    Небольшой бонус для любителей framework-ов.

    P.S. CocoaPods я не забыл, а намеренно не упомянул.
  • Continuous Integration для мобильных и веб-проектов
    +1
    >>> Я так понимаю Hudson у вас установлен на Mac OS?
    Для запуска xcodebuild и пр. обязательно нужен slave на Mac OS.
    При этом если собираетесь запускать симулятор, то Hudson нужно ставить не демоном (читай «из *.dmg»), а в userspace (читай «из *.war плюс скриптовая магия»).
    В моём случае (не путать с автором статьи) это один mac mini, поскольку ведроидом пока не занимаюсь.

    >>> Мне бы было очень интересно прочитать статью о том
    А я-то думал, здесь все ну оооочень умные — вот и не пишу. Надо будет подумать над этим…

    А пока вот вам немного устаревший материал.
    Раз, Два

    Обновлять пока смысла не вижу. И не я один такой

    Для тестов использую calabash
    Почитать про Build&Analyze можно в документации clang
  • Дайджест предстоящих IT-событий на апрель 2013 года
    +1
    Я что-то пропустил или Россия отобрала Крым обратно?
    ** поправьте, пожалуйста, флаг напротив iOSonRailsConf **
  • RAII + С++ variadic templates = win
    0
    Как-то очень уж вычурно.
    Почему бы не засунуть освобождение ресурсов в лямбду или любую другую сущность с operator() без параметров? Или иначе статьи для хабра состряпать не получилась бы?

    Вот вариант для Objective-C.
    Header
    Implementation

    Где-то в закромах валялся такой же, но на шаблонах и для любого объекта-функции. Работал задолго до появления C++11. Если будет интерес — откопаю да выложу «на посмотреть».
  • Использование Berkeley DB в Android приложении
    0
    А под iOS кто-то осилил собрать?
    Что-то у меня не получилось с первого раза…

    P.S. RTFM не помог
  • Кроссплатформенная разработка для мобильных с Xamarin
    +1
    А с Obj-C блоками эта штука умеет работать?
    То есть, создать блок в Native code и вызвать из C#.

    P.S. В примерах из документации monotouch описан обратный процесс.
  • Objective C. Практика. События и «мертвые» объекты
    0
    Или же тихо отписать observer, аналогичное решение в: iAsync
  • Разработка iOS приложений на Ruby
    0
    >>> Плюс, всегда можно написать свой класс WeakRef, благо Objective-C в данный момент позволяет.
    Вариант «в лоб» не проканал — тест «Returns nil if not stored otherwise» валится.
    github.com/dodikk/MotionBlocks/blob/master/MotionBlocksTests-Ruby/spec/WeakRef_spec.rb

    Следовательно, ObjC не совсем позволяет. Очень надеюсь что где-то ошибся…
    * Может, вместо строк лучше использовать более честный объект? С литеральными массиами поведение такое же.
    * Шаманство с garbage collector тоже не помогло

    >>> Я помню пару лет назад ее мусолили в MacRuby, и тогда Лаурент писал что-то вроде того, что «или GC сам все сделает как надо, или это архитектурная проблема вашего приложения».
    Про RubyMotion он примерно то же самое говорит. Но полноценной замены делегатам пока не предлагает.
  • Разработка iOS приложений на Ruby
    0
    >>> Использую RubyMotion + RubyMine уже полтора месяца. Балдею от легкости разработки.
    И как, не «течет»/не тормозит?
  • Разработка iOS приложений на Ruby
    0
    >>> Насколько я помню, указатели в RM как раз таки со слабой связанностью, и если закинуть ссылку на объект в указатель – то это будет некий «unsafe_unretained».
    Proof никакой не подкинешь? У самого нагуглить не особо получается.

    >>> «или GC сам все сделает как надо, или это архитектурная проблема вашего приложения»
    И на что мне переползать с уютных делегатов? Делать все через NSNotificationCenter?

    >>> и если закинуть ссылку на объект в указатель – то это будет некий «unsafe_unretained». Плюс, всегда можно написать свой класс WeakRef, благо Objective-C в данный момент позволяет.

    Ну, это понятно
    Тесты пока не успел на сие написать. О результатах отпишусь, если интересно. Ну, и ты тоже держи в курсе, ежели желание «покопать» перерастет в действие ))
  • Разработка iOS приложений на Ruby
    0
    Не понял, что есть «FFI». Молви человеческим языком, будь добр.

    >>> Есть приватный метод -invoke
    Насколько я понял, это на стороне ObjC, что, по сути, эквивалентно моему костылю.

    Так как же правильно готовить memory management на стороне RubyMotion? Особенно без поддержки __weak?
    Методом «don't worry — пусть себе течет»?
  • Разработка iOS приложений на Ruby
    0
    Про блоки — уже пробовал . Пока глухо.
    Про weak — нагуглился WeakRef, но завести с пол-оборота не вышло.
  • Разработка iOS приложений на Ruby
    0
    6. Есть ли в Ruby аналог ключевого слова "__weak". Если нет, то как избегать циклических ссылок при работе с делегатами?
  • Разработка iOS приложений на Ruby
    0
    5. Можно ли вызывать ObjectiveC блоки из Ruby кода?

    В сети решений не нашел и придумал свой уродливый костыль:
    github.com/dodikk/RubyMotionTestApp/blob/master/vendor/BlockBuilder/BlockBuilder/NSObject%2BBlockForRuby.m

    Нормального решения не подскажете, часом?
  • Анализ Code Coverage для iOS и OS X проектов (xCode 4.4)
    0
    С твоего позволения, farcaller/ios-tdd

    P.S.
    С бинарником из твоего репозитория перестало работать когда обновился до Xcode 4.4. Если не дожидаться Xcode 4.5 release, то как лечить? Тащить исходники в проект?

    xcodebuild -version
    Xcode 4.4
    Build version 4F250
  • Анализ Code Coverage для iOS и OS X проектов (xCode 4.4)
    0
    image
  • Анализ Code Coverage для iOS и OS X проектов (xCode 4.4)
    0
    >>> Советуют добавлять build step и там запускать скрипт с lcov
    Это как раз понятно.

    >>> Судя по всему, плагина нет
    То есть, после этого полученную пачку html заархивировать в виде artefact, качать и смотреть глазами.

    Просто при использовании gcovr мне jenkins может нарисовать вот такие веселые картинки.
    К тому же, это чудо пытается обсчитывать coverage по классам и conditionals (комбинаторный перебор всех возможных веток if/case путей выполнения). Правда, я пока не совсем понимаю как этим пользоваться, поскольку не видно информации, какие из вариантов остались за бортом.

    lcov и coverstory предоставляют лишь покрытие по строкам кода, что также весьма неплохо.
  • Анализ Code Coverage для iOS и OS X проектов (xCode 4.4)
    0
    А еще можно собирать статистику с помощью gcovr
    И просматривать через Jenkins Cobertura plug-in

    Раз уж зашла речь об автоматизации — осмелюсь поинтересоваться: «А для lcov есть какой-либо plug-in для jenkins?»
  • Автоматизируем работу с проектами Xcode средствами Ruby
    +2
    >>> Что касается программной работы со структурой проекта — это прикольно и интересно, я только сходу не могу придумать задач, зачем бы это могло быть нужно.

    Например, Cocoa Pods.
    Вы все правильно сказали.
  • CocоaPods — мощное средство в руках Objective-C разработчика
    –1
    >>> Make, если что, зависимостями не управляет.
    да что вы говорите?

    Он как раз зависимостями и управляет. Только не проека, а команд ( компиляции\линковки\установки итд. ). Да, низкоуровнево и не вполне удобно, но управляет ведь!
  • CocоaPods — мощное средство в руках Objective-C разработчика
    0
    >>> а Вы потом все ваши «драг-н-дропнутые» фреймворки храните в дереве исходных кодов вашего проекта? Кладете в vcs?
    в принципе, да. Я их обновляю нечасто. И да, я делаю это руками.
    Пока ни с чем сравнимым по размерам с boost под iOS не пользовался ==> vcs не рвался под их тяжестью.
    Для особо тяжелых зависимостей, подобных boost или three20 можно написать script, дергающий за xcodebuild в нужных местах.

    >>> Простите, но у Вас все куда более костыльно, а Вы подаете это под соусом «более правильного» подхода.
    Чую запах holy war
  • CocоaPods — мощное средство в руках Objective-C разработчика
    0
    Костыли не нужны. Нужен набор script-ов.

    Есть прекрасный target template ( хотя его можно было бы слегка упростить )
    github.com/kstenerud/iOS-Universal-Framework

  • CocоaPods — мощное средство в руках Objective-C разработчика
    0
    >>> Даже под Windows/Unix можно все статически влинковать со всеми зависимостями, и и пользователю глубого фиолетово.

    Но вы почему-то так не делаете?
    В своих java проектах вы ведь используете *.jar, а не перетаскиваете *.java файлы в каждый новый проект? Вот и для ObjectiveC должен работать тот же принцип. К сожалению, не тут-то было.
  • CocоaPods — мощное средство в руках Objective-C разработчика
    0
    >>> Я только что понял, что бы абсолютно не в курсе как работают bundler, npm и иже с ним.
    Вы правы. Мне должно быть стыдно?

    >>> Зависимости приходится находить (в простейшем случае они будут в доке/ридми упомянуты) и добавлять по-отдельности.
    Нормальный maintainer должен бы выложить у себя framework своей библиотеки + набор framework для ее зависимостей. В случае коллизий выбирать или собирать нужный вариант прийдется вручную, но и CocoaPods, вроде как не особо спасает в таких случаях.

    Пока таких maintainer не встречал. Обычно код зависимостей также тупо скопирован в репозиторий библиотеки. В лучшем случае автор осилил git submodule.

    >>> Да, фреймворк, для подключения в проект лучше, чем копирование исходников.
    >>> Не убедили
    1. То есть, вы считаете копирование исходников нормальной практикой в случае ObjectiveC?
    2. Перечитайте еще раз мою аналогию с Java/.NET package.
    ну, не убедил, так не убедил. что поделаешь…

    >>> Вы упорно отказываетесь понимать, что я говорю в первую очередь про dependency-management. А с инструментами подобными cocoapods это делать удобнее.
    Вы упорно отказываетесь понимать, что я не против dependency management. Я категорически против copy-paste исходников. Для меня это критичней, чем удобство CocoaPods.

    Скорее всего, у меня и не получится убедить вас. Вы сделали выбор осознано.
    А многие тупо копируют исходники в проект потому что так было написано в tutorial, по которым они осваивали язык. И как раз эта особенность iOS community меня удручает.
  • CocоaPods — мощное средство в руках Objective-C разработчика
    0
    Framewok == библиотека + headers + resources.
    Отличие — интеграция с xCode. Имея framework не нужно ничего прописывать в header search path и linker flags. Нужную зависимость будет добавить так же легко как Foundation или UIKit, предоставляемые Apple.

    >> И в том и в другом случае необходимо самостоятельно эти зависимосты трэкать, выкачивать и добавлять в проект.
    Не совсем так. Скачать, собрать из них framework и его добавить. Согласитесь, обновление third party библиотек — не столь частая штука, чтобы пересобирать их каждый раз на основе nightly builds.

    >> К аналогичный подходу к dependency management'у рано или поздно приходят многие платформы
    Ага. Особенно те, у которых source code == executable. То есть, интерпретируемые языки (в основном, они и попали в ваш список).

    Ну неправильно это — использовать copy-paste для повторного использования кода в компилируемых языках, таких как C++ и ObjectiveC. В своем любимом .NET или Java вы ведь исходники библиотек не включаете в основной проект? Конечно, нет, ведь вы создаете package (*.dll или *.jar соответственно). Аналогичный подход стоит применять к ObjectiveC, взяв framework в качестве подобного package.

    >> Инструменты подобные cocoapods как раз и существуют, чтобы этот процесс упростить и автоматизировать.
    Вот если бы CocoaPods собирал мне нужные frameworks, а не тупо вставлял исходники в мой проект (хорошо, в отдельный static library project) — цены бы ему не было. А так это большой и удобный костыль, поощряющий неряшливый стиль работы с зависимостями и построения собственных библиотек.

    >> с некоторой натяжкой сюда же можно добавить и maven для java
    А если еще больше натянуть, то можно добавить и make для ObjectiveC чего угодно
  • CocоaPods — мощное средство в руках Objective-C разработчика
    0
    Вот только «либу с зависимостями» и framework (хорошо, несколько framework, ежели у нужного вам есть зависимости) путать не стоит.

    С библиотеками — да. Возня есть. Но если уж из нее добрые люди скрутили framework, то подключение сводится к «скачал->drag&drop->можно пользоваться».

    P.S. Товарищ дело говорит.
    >> На вид все довольно просто, но мне кажется для управления зависимостями в проекте предоставляется слишком большая абстракция, делегирование управления и возможность загнать себя в рамки инструмента
  • CocоaPods — мощное средство в руках Objective-C разработчика
    0
    >>> А за пивом ваш утюг умеет бегать?
    Зря вы так…
    .NET вполне отлично дружит с native code ( interop, DllImport и прочие радости ). Вот я и поинтересовался, насколько могуч предложенный вами инструмент. Вдруг ваш утюг и вправду можно было за пивком отправить. Эх, мечты-мечты…
    No offence, так сказать.

    Кроме того, у вас проблема зависимостей неплохо решена с помощью GAC. А NuGet, как я понял, качает, собирает и правильно все в этом GAC размещает.
    И это круто.

    Хотя во «вселенском бардаке» есть некое свое очарование и романтика.
  • CocоaPods — мощное средство в руках Objective-C разработчика
    0
    Видать, все дело в том что я пришел в iOS development из сурового бородатого C++
    И уже привычен к ручным ( ну, или с помощью CMake ) сборкам зависимостей.

    >>> Зачем мне все это если я хочу сэкономить время?
    1. Framework way идеологически более верен для данной платформы. Framework programming guide
    2. Для следующих проектов framework добавляется очень быстро и безболезненно. Так же как для Mac OS X, поскольку используется единый xCode.
    3. Помочь сообществу, правильно оформив хорошие библиотеки. Чтобы даже команду в терминале запускать не нужно было. Скачал собранный framework, перетащил — и пользуйся на здоровье.
    В качестве примера — тот же gh-unit

    И да. В случае Ruby обычно executable == source code. В случае C++/Objective-C сей подход не вполне оправдан.
  • CocоaPods — мощное средство в руках Objective-C разработчика
    0
    >>> этот инструмент нужно внедрять в массы.
    Только не забывайте предупреждать массы о том что это по своей сути костыль copypaste вселенских масштабов.

    А на мой взгляд, внедрять в массы нужно умение правильно писать свои библиотеки и frameworks. А то iOS developers отстают от своих коллег в этом плане лет эдак на 50.
  • CocоaPods — мощное средство в руках Objective-C разработчика
    0
    >>> так или иначе бывает нужно посмотреть как оно работает, или посмотреть бэктрэйс, а вот собранная либа мне этого не позволит

    Ну так собирайте на здоровье! Или вы target dependencies не смогли осилить?
    image

    Если кто заинтересовался, то код тут

    >>> мне не нужно прописывать для каждой либы Other Linker Flags, добавлять Frameworks
    да. Добавить собранный framework с помощью «drag and drop» особенно тяжко…
    Вам не послышалось: свой framework нужно тащить к Foundation и прочим ( см. картинку выше ).

    >>> Да и главный плюс CP на мой взгляд, это то что мне не нужно прописывать для каждой либы Other Linker Flags.
    Если есть исходники — делаем dependence ( см. картинку ).
    Иначе — у вас есть universal binary + набор headers. Делаем руками из этого всего framework. Дальше — ваш излюбленный drag and drop.

    В общем, если это правильно приготовить, то можно обойтись и без hard core типа Linker Flags, и без костылей подобных CocoaPods.

    P.S. а немало времени порой занимает наведение порядка в сторонней библиотеке, заточенной под copy paste. А раздражает то, что многие, называющие себя «iOS developer», так и используют copypaste, считая это прекрасным способом повторного использования кода.

    Может, для ruby подобный подход и оправдан. Но Objective C++ ведь не интерпретируемый (и слава богу).

    P.S. Если у вас еще остались аргументы в пользу CocoaPods — готов выслушать.
  • CocоaPods — мощное средство в руках Objective-C разработчика
    –1
    >> Некоторые еще и хардкодят при этом.
    Вот им и трудно хардкодить. Потому и изобрели CocoaPods.
    С моей точки зрения данный инструмент — большой автоматизированный серебряный костыль. Хотя кому-то, возможно, так удобней.

    >> как описываете Вы, делают далеко не все
    Я не один такой. автор ghUnit тоже так делает. Может, прочитав это обсуждение кто-либо еще пополнит ряды таких людей.

    P.S. Не вполне понял вашу орфографию. Уж не взыщите