Думаю можно, но нужно пробовать. Сейчас использую это решение в одном из проектов, заодно правлю баги и улучшаю существующий функционал, делая его удобнее для использования.
Опять таки, я открыт для предложений, и готов вносить новый фичи по требованию.
Индексы будут =)
Переименование и удаление не реализовано в самой sqlite, а делать миграции через создание временной таблицы может быть очень затратно, если таблица большая.
Если сразу пытаться создать продукт с поддержкой всего на свете, всех ньюансов и требований, то в итоге может выйти какой-то монстр. Все что сейчас реализовано было нужно мне в тот или иной момент, постепенно функционал расширяется, что-то добавляется, что-то улучшается. Всему свое время :)
И главное что я хотел видеть в своей поделке — это простота. Мне надоело делать массу телодвижений с CoreData'ой для создания простой сущности =)
Ну к примеру я создал две сущности, одна из них невалидна, и я не смогу сохранить другую, т.к. получу ошибку о невалидности какой-то сущности в данном контексте. Прийдется одну удалять, а затем создавать снова. Столкнулся с такой проблемой в одном из проектов, где было несколько связанных сущностей, и все это лихо валилось, при чем с exception'ом и совершенно непонятной ошибкой из серии Error -912.
Создание объектов там не прозрачное, при создании нужно обязательно запихивать в контекст, как-то это неудобно, на мой взгляд.
Но скорее дело в том что я плохо знаю CD.
И как бы то ни было, я получил новые знания во время разработки, так что для меня польза как минимум в этом :)
Да, объект нужно освобождать, просто не привел этого в примере.
Я не утверждаю что мой велосипед лучше чем CoreData, или, не дай бог, он идеален =)
Просто от скуки написал такую вещь, судя по отзывам с гитхаба кому-то это пригодилось, у кого-то была задача использовать существующую БД на sqlite, и CoreData'у туда было тяжело прикрутить.
Настраиваю, иначе просто не могу. На работе если ОСь переставляю, то могу и целый убить чисто на настройку всяких «мелочей»: от установки всяких необходимых пакетов, вплоть до установки цветовой схемы в Vim'e или IDE.
Спасибо за статью, очень понравилась идея вводить команды с новой строки, нужно попробовать, а то у самого на 13" мониторе половина экрана занята инфой об окружении (тоже что и у вас, только вместо python'а ruby).
Для вывода текущей версии ruby и текущего gemset'а написал такую функцию.
rvm_gemset(){
ruby_version=$(ruby -v | awk ' { print $2 } ')
ree=$(ruby -v | grep -q Enterprise && echo "ree")
if [ $ree ]
then
ruby_version="ree"
fi
gemset=$(rvm current | awk -F@ ' { print $2 } ')
if [ $gemset ]
then
echo "$ruby_version@$gemset "
else
echo "$ruby_version "
fi
}
Я не пробовал SenTestingKit, но я попробовал использовать Cedar и мне это понравилось. Проблема с CoreData очень сильно оттолкнула от использования стандартных тестов. А писать UI-тесты на Javascript как-то не хочется.
Когда я пишу тесты для iOS на Cucumber, то я не учу инструмент_только_для_iOS, а я изучаю универсальный инструмент, он позволяет мне писать теже тесты и для Rails приложений, и если я вдруг буду писать под Android, то мне не придется изучать какой-нибудь специфичный для этой ОС фрэймворк.
Говорю ж, все это субъективно, я описал то чем я тестирую, и я ни в окем случае не настаиваю на том чтобы все начали использовать только эти средства :)
UIAutomation — когда-то «пробовал».
Что не понравилось:
Нужно писать тесты на Javascript.
Для запуска тестов нужно открывть какое-то «левое» приложение, что очень неудобно если использовать CI (continuous integration), прийдется писать хитрый скрипт на AppleScript, и я не до конца уверен что это возможно.
И самый главный, который даже не позволил написать простейший тест: приложение должно быть подписано. Подписать приложение не проблема, но зачем я должен делать это для простого обучения?..
Ну а плюсов я не нашел.
Стандартный фрэймворк для unit-тестов — пробовал Kiwi на его основе.
Минусы:
Точки останова в тест-кейсах не работают.
Для тестирования CoreData пришлось писать массу лишнего кода обернутого в #ifdef (хотя может я что-то не так сделал) для того чтобы создать PersistentStorage, часа 4 убил на все это дело.
Наверое впервые меня не радует распространение проприетарного софта на linux-системах =\
Надеюсь никогда не приведется иметь делом с таким сервисом.
Опять таки, я открыт для предложений, и готов вносить новый фичи по требованию.
Переименование и удаление не реализовано в самой sqlite, а делать миграции через создание временной таблицы может быть очень затратно, если таблица большая.
Если сразу пытаться создать продукт с поддержкой всего на свете, всех ньюансов и требований, то в итоге может выйти какой-то монстр. Все что сейчас реализовано было нужно мне в тот или иной момент, постепенно функционал расширяется, что-то добавляется, что-то улучшается. Всему свое время :)
И главное что я хотел видеть в своей поделке — это простота. Мне надоело делать массу телодвижений с CoreData'ой для создания простой сущности =)
Создание объектов там не прозрачное, при создании нужно обязательно запихивать в контекст, как-то это неудобно, на мой взгляд.
Но скорее дело в том что я плохо знаю CD.
И как бы то ни было, я получил новые знания во время разработки, так что для меня польза как минимум в этом :)
Я не утверждаю что мой велосипед лучше чем CoreData, или, не дай бог, он идеален =)
Просто от скуки написал такую вещь, судя по отзывам с гитхаба кому-то это пригодилось, у кого-то была задача использовать существующую БД на sqlite, и CoreData'у туда было тяжело прикрутить.
Для вывода текущей версии ruby и текущего gemset'а написал такую функцию.
Frank
KIF
Когда я пишу тесты для iOS на Cucumber, то я не учу инструмент_только_для_iOS, а я изучаю универсальный инструмент, он позволяет мне писать теже тесты и для Rails приложений, и если я вдруг буду писать под Android, то мне не придется изучать какой-нибудь специфичный для этой ОС фрэймворк.
Говорю ж, все это субъективно, я описал то чем я тестирую, и я ни в окем случае не настаиваю на том чтобы все начали использовать только эти средства :)
Но это все субъективно, кому что нравится.
Что не понравилось:
Ну а плюсов я не нашел.
Стандартный фрэймворк для unit-тестов — пробовал Kiwi на его основе.
Минусы:
Плюсы: работает почти «из коробки»