Ну ваша категоричность у меня вызывает только усмешку. Продолжайте так думать.
Basecamp я пользую для собственного планирования, а в чужих Jira, YouTrack, RedMine, Trello… учавствую, когда работаю над проектом компании, которая использует один из этих сервисов.
Кроме управления проектами есть еще куча большая разных статей расхода: хостинг, таймтрэкинг, облачное хранилище, репозиторий…
И у меня лично затраты в месяц на разные полезные и нужные сервисы давно ушла за $1к в месяц. И это мои личные деньги, которые я бы мог потратить на что угодно. Поэтому я думаю что действительно нужно и полезно, а что дань моде. Например я не использую GitHub для своих проектов, так как социальные фишки мне не нужны и хватает с головой RepositoryHosting, экономия 93 бакса в месяц. Ну и так далее.
Сравнивать с монитором и креслом совсем не уместно, абсолютно разные вещи: сервис и материальная ценность.
Популярность джиры связанна именно с тем, что она хорош продумана и проработана. Знаю историю нескольких компаний, в которых только с помощью джиры получилось наладить хороший рабочий процесс (сложное взаимодействие большого количества отделов и людей) и размер одной из них был меньше 100 человек. А если у вас не получилось или вы не поняли или не разобрались — это не значит, что продукт плохой. Он работает и помогает людям и это хорошо.
Я точно убежден, что каждому свое.
Мне лично вообще хватает с головой Basecamp и я обожаю его за то, что он экономит мне кучу времени. Но для сложного процесса и взаимодействия его использовать невозможно.
Если вам Jira не понравилась, это не значит, что она хуже.
Jira очень мощный, удобный и популярный инструмент.
А по поводу денег, то это просто потому-что вы не свои тратите, поэтому такое отношение типа: пару сотен туда, пару сотен обратно — значения не имеет.
И там и там цены указаны за месяц, вот сравнительная таблица:
Количество людей, цена YouTrack, цена GreenHoper
10 0 (открытые) 10
15 20 25
25 75 50
50 150 100
100 300 150
YouTrack выгоднее только на 15 человеках, пользоваться бесплатным тарифом нереально, так как только публичные проекты. При увеличении количества людей разница становится ощутимо больше.
Продукт отличный, но ваш самый главный австралийский конкурент предлагает более вкусные цены.
Ребят, сделайте хотя-бы такие-же цены, у австралийцев они терпимые.
я не знаю как у вас, но у меня Bitcasa работает намного медленнее (раз в 5-10) чем Dropbox и YD. Причем сервис от Яндекса естественно самый быстрый.
Ну и плюс у Bitcasa нет многих плюшек.
Чего все скептики такие, 180 дней — это пол года. За это время при желании можно и С/С++ изучить. А на изучение JS в свое время у меня ушло около 4-х дней. Правда я его учил, чтоб написать интерпретатор, а не писать на нем, но в последствии и с десяток тестовых сайтов написал для проверки работоспособности.
При наличии хорошей документации (а тут не сказано, пользовалась ли она ей или нет), можно все изучить и понять.
А когда-то очень давно, когда я учился в школе, у меня не было интернета (да вообще в городе его ни у кого не было) и не было книг, да и денег на них не было. Вот я изучал assembler, дизасемблируя другие приложения. Так что главное — это желание.
Если вы 60% времени боритесь с ошибками в зависимостях — значит что-то с процессом выбора библиотек не так.
Вы опять переиначиваете. Я не 60 процентов времени борюсь с ошибками в зависимостях, а 60 процентов времени оптимизации провожу оптимизацию чужого кода а не собственного.
Ну пока идеального ничего не встречал, те-же MagicalRecord и mogenerator входили в число этого кода.
А по поводу переноса шаблонов из других языков — нельзя их бездумно переносить, если они лишают Вас каких-то возможностей динамичного рантайма ObjC.
Ну возможностей динамического рантайма ни один шаблон избавить не может, так как приложение работает в этом рантайме.
Что Вы теряете в описанных в статье случаях? Вместо @«someProperty» будет @keypath(object.someProperty)? Серьезно? Да в этом любой джуниор за полчаса разберется.
Я не говорю о сложностях, я говорю о чюжеродности. Хранить указатели на Objective-C функции тоже можно, и разобраться в этом может любой джуниор, как вы выразились. Вопрос просто зачем, если есть блоки. А даже когда их небыло, то колл-бэки лучше было бы делать родными механизмами (центр уведомлений или шаблон делегирования например). Понятно что указатели бы работали быстрее и понятнее для любого С/С++ разработчика, но вопрос, зачем это делать, ради чего?
Вот так и в вашем случае, я лично не вижу вообще никаких оснований и доказательств того, что эта статическая проверка экономит время.
естественно, что нужно использовать и фреймворки и инструменты для облегчения труда.
Но я лишь говорил, что те проблемы, о которых вы писали в статье — надуманные. Естественно и ваше и мое мнения — субьективны и каждый для себя сам выбирает путь. Для того комментарии и нужны, чтоб высказать альтернативную точку зрения, что я и сделал. И привел собственно аргументы.
Вы работаете с CoreData, но будете продолжать писать FetchRequest-ы оперируя строковыми константами, вместо того, чтобы использовать библиотеки, которые на порядки уменьшат количество кода (и соответственно ошибок), таких как ActiveRecord for Core Data
Библиотеки как правило увеличивают количество кода (я понимаю что вы имели ввиду, но просто озвучил другую сторону медали), и еще могут снизить производительность и увеличить количество ошибок. Любую библиотеку перед использованием нужно хорошо изучить, а не полагаться на чужую внимательность и компетентность.
Как правило в 60 процентах я борюсь в ошибках и тормозах чужого кода, а не собственного, именно поэтому так и говорю.
Рефакторинг в XCode работает не очень хорошо, но в AppCode все намного лучше.
Я лишь пытаюсь сказать, что во всем должна быть мера и переносить шаблоны и подходы с других языков нужно осторожно и вдумчиво.
Рефакторинг делаю крайне редко при крайней необходимости. Если честно, в масштабах iOS приложений рефакторинг провожу только в чужом коде, в своем ни разу не было такого.
Вы плотно работаете с CoreData?
Плотнее некуда.
Именно поэтому я буду использовать инструменты, позволяющие выявлять ошибки на стадии компиляции.
Ваш выбор, но я еще думаю о тех людях, которые вероятно могут поддерживать мой код.
Я ценю свое время.
А нужно еще думать о времени других разработчиков, в том числе тех, которые потом будут разбираться в ваших «нестандартных» подходах.
Вы часто изменяете reuseIdentifiers / storyboardID? Вы переименовуете имена пропертей? Вы плотно работаете с CoreData?
Это надуманные проблемы, ошибки в этих примерах приводят к падению приложения при первом же обращения к «неизмененным» данным. Плюс инструменты рефакторинга переименовывают и iVar'ы (если их еще кто-то использует) и названия свойств и все места где они используются (так для примера о надуманности приведенных аргументов).
Basecamp я пользую для собственного планирования, а в чужих Jira, YouTrack, RedMine, Trello… учавствую, когда работаю над проектом компании, которая использует один из этих сервисов.
И у меня лично затраты в месяц на разные полезные и нужные сервисы давно ушла за $1к в месяц. И это мои личные деньги, которые я бы мог потратить на что угодно. Поэтому я думаю что действительно нужно и полезно, а что дань моде. Например я не использую GitHub для своих проектов, так как социальные фишки мне не нужны и хватает с головой RepositoryHosting, экономия 93 бакса в месяц. Ну и так далее.
Сравнивать с монитором и креслом совсем не уместно, абсолютно разные вещи: сервис и материальная ценность.
Популярность джиры связанна именно с тем, что она хорош продумана и проработана. Знаю историю нескольких компаний, в которых только с помощью джиры получилось наладить хороший рабочий процесс (сложное взаимодействие большого количества отделов и людей) и размер одной из них был меньше 100 человек. А если у вас не получилось или вы не поняли или не разобрались — это не значит, что продукт плохой. Он работает и помогает людям и это хорошо.
Я точно убежден, что каждому свое.
Мне лично вообще хватает с головой Basecamp и я обожаю его за то, что он экономит мне кучу времени. Но для сложного процесса и взаимодействия его использовать невозможно.
Jira очень мощный, удобный и популярный инструмент.
А по поводу денег, то это просто потому-что вы не свои тратите, поэтому такое отношение типа: пару сотен туда, пару сотен обратно — значения не имеет.
Количество людей, цена YouTrack, цена GreenHoper
10 0 (открытые) 10
15 20 25
25 75 50
50 150 100
100 300 150
YouTrack выгоднее только на 15 человеках, пользоваться бесплатным тарифом нереально, так как только публичные проекты. При увеличении количества людей разница становится ощутимо больше.
Ребят, сделайте хотя-бы такие-же цены, у австралийцев они терпимые.
Ну и плюс у Bitcasa нет многих плюшек.
При наличии хорошей документации (а тут не сказано, пользовалась ли она ей или нет), можно все изучить и понять.
А когда-то очень давно, когда я учился в школе, у меня не было интернета (да вообще в городе его ни у кого не было) и не было книг, да и денег на них не было. Вот я изучал assembler, дизасемблируя другие приложения. Так что главное — это желание.
Вы опять переиначиваете. Я не 60 процентов времени борюсь с ошибками в зависимостях, а 60 процентов времени оптимизации провожу оптимизацию чужого кода а не собственного.
Ну пока идеального ничего не встречал, те-же MagicalRecord и mogenerator входили в число этого кода.
Ну возможностей динамического рантайма ни один шаблон избавить не может, так как приложение работает в этом рантайме.
Я не говорю о сложностях, я говорю о чюжеродности. Хранить указатели на Objective-C функции тоже можно, и разобраться в этом может любой джуниор, как вы выразились. Вопрос просто зачем, если есть блоки. А даже когда их небыло, то колл-бэки лучше было бы делать родными механизмами (центр уведомлений или шаблон делегирования например). Понятно что указатели бы работали быстрее и понятнее для любого С/С++ разработчика, но вопрос, зачем это делать, ради чего?
Вот так и в вашем случае, я лично не вижу вообще никаких оснований и доказательств того, что эта статическая проверка экономит время.
Но я лишь говорил, что те проблемы, о которых вы писали в статье — надуманные. Естественно и ваше и мое мнения — субьективны и каждый для себя сам выбирает путь. Для того комментарии и нужны, чтоб высказать альтернативную точку зрения, что я и сделал. И привел собственно аргументы.
Библиотеки как правило увеличивают количество кода (я понимаю что вы имели ввиду, но просто озвучил другую сторону медали), и еще могут снизить производительность и увеличить количество ошибок. Любую библиотеку перед использованием нужно хорошо изучить, а не полагаться на чужую внимательность и компетентность.
Как правило в 60 процентах я борюсь в ошибках и тормозах чужого кода, а не собственного, именно поэтому так и говорю.
Рефакторинг в XCode работает не очень хорошо, но в AppCode все намного лучше.
Я лишь пытаюсь сказать, что во всем должна быть мера и переносить шаблоны и подходы с других языков нужно осторожно и вдумчиво.
Плотнее некуда.
Ваш выбор, но я еще думаю о тех людях, которые вероятно могут поддерживать мой код.
А нужно еще думать о времени других разработчиков, в том числе тех, которые потом будут разбираться в ваших «нестандартных» подходах.
Это надуманные проблемы, ошибки в этих примерах приводят к падению приложения при первом же обращения к «неизмененным» данным. Плюс инструменты рефакторинга переименовывают и iVar'ы (если их еще кто-то использует) и названия свойств и все места где они используются (так для примера о надуманности приведенных аргументов).