Грамотно и любовно настроенный XCode проигрывает AppCode в очень небольшом спектре задач. И примерно в столь же небольшом — выигрывает.
Могли бы вы описать, что делается по вашему мнению в AppCode существенно комфортнее? Интересуюсь для себя — для того, чтобы как-нибудь самому попробовать Апкод, а не только с коллегами обсуждать
И для этого есть прекрасный пример :-) Reactive Cocoa, которые пользуясь новыми фичами языка были вынуждены поднять минимальную версию iOS, причем значительно.
Или если ваша IDE в один прекрасный момент откажется собирать для старой версии.
Или компилятор C++, который после обновления откажется компилировать старый код и не предложит инструментарий для миграции.
Вообще — в этом плане очень хорошо поступили разработчики XCode — делая какое-то существенное и значимое изменение — они вместе с тем предлагают и инструментарий по адаптации вашего кода к этому.
И это хорошая практика.
В остальных случаях — можно понять разработчиков, но это их решение приносит иногда весьма существенные затраты на адаптацию. И черт его знает, насколько это хорошо в общем смысле.
А вообще — это программирование ради программирования. По-моему не стоит забывать, что программисты работают, чтобы решать задачи пользователей, а не для того, чтобы красиво и удобно разрабатывать.
Фраза «пользователи — мертвый груз» — это вообще, на самом деле, за гранью.
Можешь обосновать выгодность новых технологий для бизнеса (например, стратегической выгодой, что переход на новый инструментарий значительно увеличит ретеншн засчет повышения стабильности и быстродействия сервиса — и желательно в цифрах и на основе какого-то опыта) — вперед, делай. Не можешь — плачь, колись, продолжай жрать кактус.
Эти пользователи — мертвый груз, они должны быть уничтожены вне зависимости от того сколько денег они вам приносят. Дайте им возможность перехода и двигайтесь дальше, если они способны, то догонят вас. Если же нет, то они того не стоят.
Просто пример из жизни:
В рабочем проекте мы привязаны не столько к версиям SDK и прочих third-party (которые мы поддерживаем в максимально актуальном состоянии), сколько к версии операционной системы, которую мы поддерживаем (что закрывает для нас возможность использовать САМУЮ актуальную версию некоторых third-party и, в результате мы иногда сами повторяем функциональность более новых версий). И, с одной стороны, это наша боль и наше страдание.
А с другой стороны, инком, который генерят пользователи, сидящие на «неактуальной» версии операционной системы — достаточен чтобы оплатить большой отдел разработчиков, которые и поддерживают эту старую систему. И еще останется. В частности на людей, занимающихся глубинным рефакторингом и пишущий код с большим количеством #ifdef для улучшения производительности на разных версиях. И вот смогли бы вы ДОКАЗАТЬ, что внедрение новых и хипстоватых инструментов даст вам такой бонус в новых пользователях, способный покрыть (и перекрыть) уже существующий доход?
Вообще, смысл внешних конфигов начинается в тот момент, когда у них появляется хорошая и качественная сегментация, то есть, когда по каким-то данным можно сделать так, чтобы у одних пользователей была одна конфигурация, а у других — другая. Как у вас с этим?
Я мог бы вам порекомендовать еще вот такой вот сервис на посмотреть — www.leanplum.com/ — они помимо конфига предлагают еще и мобильные SDK, для легкого пользования оными, дефолтные настройки в случае отсутствия интернета и многое другое.
Кстати, я бы не исключал того, что char name[10] представляет собой только первую часть структуры, реализующей собой селектор. В таком случае, приводя селектор к char* — мы и будем видеть только лишь первую часть структуры.
svn.gna.org/svn/gnustep/libs/libobjc2/trunk/selector.h — вот тут например приводится альтернативный вариант, при котором над char * (которому, к слову не всегда соответствует первая часть структуры, экономии чего-то ради, будучи замененная на некоторый индекс) существует и еще одно поле types, которое хранит в себе, судя по всему, сигнатуру вызова.
Ну с этой точки зрения реализация сущности сообщений, а, главное, их смысл — это действительно жемчужина objective-C, которая позволяет реализовать много действительно красивых и изящных вещей.
Программист на фортране — на любом языке может писать на фортране?
Я ни в коем случае не хочу обидеть язык Си, однако в данном случае я не вижу смысла в происходящем.
Селектор является «строкой» лишь постольку поскольку. Селектор является абстракцией, указателем в памяти, для удобства, помимо прочего, указывающую на некую описывающую его структуру (в данном случае С-стринг). С большего, этого знания достаточно для работы с этой частью языка.
Поэтому не дай вам бог использовать это знание в своих проектах.
P.S. К слову, могу порекомендовать закопаться на какое-то время в этот репозиторий Там все есть. Кроме определения SEL — потому что это определение кодогенерируемое :-)
objc_selector:
typedef struct objc_selector *SEL;
Эта штука имеет обратное значение. objc_selector — является алиасом на *SEL, а не наоборот
Ответ хороший, но есть нюанс — если ты не TDD раньше — то ты не напишешь сразу код так, что он будет тестируемый.
Ну и 100 процентное покрытие — это избыточная (иногда значительно) сложность — особенное если имеешь дело не со stateless приложениями. Да и просто возникают тысячи вопросов на тему «о, это так здорово — но как протестировать, когда у нас вон тот объект дергает вон этот синглтон, в котором изменяется состояния вон тем классом и вообще?» На которые «просто писать код иначе» — не самый подходящий ответ))
Если честно, я просто в экстатическом восторге от того, что по мере развития технологий — инструментарий дорастает до того уровня, когда генератор идеи, после не слишком утомительного обучения, путем компоновки кубиков Лего способен САМ донести свою идею до заинтересованной аудитории, не опасаясь потерь на этапе объяснения этой самой идеи еще кому-то.
Культура программирования и алгоритмика возникала не как самоцель, а как инструмент по контролю сложности и ограниченных ресурсов на сложных задачах. Не совсем понятно, почему она должна выходить из этой сферы.
Если идея оправдывается, то в проекте со временем появится сильный программист, который сделает все по науке и сможет поддерживать все в актуальном состоянии и помогать в развитии. И по моему мнению это значительно лучше кейса, когда идея не была реализована вообще по той причине, что простого инструментария не было, а позволить себе квалифицированного разработчика генератор идеи не смог.
Все ж таки задача программирования заключается в облегчении чьей-либо жизни)
Так что да — это, конечно забавный факт, что появилось много людей, создающих продукты, не обладая базовыми знаниями в computer science — но все-таки положительный.
не могу не вспомнить старую шутку — программист на Фортране на любом языке может писать на Фортране. Хаскель, хоть и усложняет это дело — но не меняет в корне.
Из личного опыта — от момента, когда я проникся и восхитился элегантностью TDD, в частности BDD, до момента, когда я смог его эффективно использовать на реальных задачах, сложнее «протестируйте калькулятор» — прошло около полутора лет — и то, потому, что я искренне верил в то, что это нужно и важно.
Я могу поверить в студентов MIT или заведений сходного уровня подготовки и отбора — но тем не менее — чистый функциональный подход — достаточно тяжелая для головы концепция и даже состоявшиеся и опытные программисты от «пишу код на хаскеле» до «понимаю функциональный подход, его плюсы/минусы/ограничения» тратят не один год. Императивное объектно-ориентированное программирование дальше от математической чистоты, но ближе к «осязаемому» миру — поэтому для восприятия проще. Современные языки позволяют «эмулировать» функциональные подходы в разработке — и как мне кажется — проще на них выйти уже убедившись, что студент смог понять и принять более простые подходы.
С какого-то момента считаю, что приложение, которое позиционирует себя как ежедневное, должно быть в первую очередь крайне лаконичным в выполнении основных действий. Потому что все красивости перестаешь замечать ко второй неделе использования. Жест с отрезанием ножницами показался крайне излишним. А вот идея с размерами шрифтов по-своему прекрасна.
Но все-таки интересно — почему считается, что реализация скачанная из интернета, не проверенная на соответствие алгоритму (и при этом не проверен лично на корректность, собственно, сам алгоритм) заслуживает большего доверия, чем просмотренный в интернете же результат его работы?)
А где гарантии того, что во время вычисления числа Пи своим способом (прогона теста) не произойдет сбоя в процессоре/оперативной памяти/вашей версии компилятора/…? Чем эти риски менее вероятны, чем риск наткнуться на неверное значение в соответствующих источниках?
ну и вызывает некоторое удивление понимание словосочетания проще всего :-)
Почти согласен с вами) Требуется немало времени, чтобы убедить близких людей, что когда вы работаете — вас нет дома. Нет и точка.
С противоположной стороны, для улучшения обстановки в семье, когда вы не работаете (вне определенного вами самостоятельно и заранее времени) — вы не работаете, не думаете сверх необходимого о работе и вообще всячески радуете вниманием близких и котов.
Очень частая ошибка фрилансера в том, что «работать когда хочешЬ» быстро превращается в «полуработать вообще всегда».
Для любых сторонних инициатив есть внутренний голос «но мне же нужно сделать это», а для «мне нужно сделать этО» не хватает мотивации.
Могли бы вы описать, что делается по вашему мнению в AppCode существенно комфортнее? Интересуюсь для себя — для того, чтобы как-нибудь самому попробовать Апкод, а не только с коллегами обсуждать
Очень рекомендую проглядеть эту статью) Тут много «эффективности» уже на уровень повыше. Парочка — стала ценными откровениями)
Или если ваша IDE в один прекрасный момент откажется собирать для старой версии.
Или компилятор C++, который после обновления откажется компилировать старый код и не предложит инструментарий для миграции.
Вообще — в этом плане очень хорошо поступили разработчики XCode — делая какое-то существенное и значимое изменение — они вместе с тем предлагают и инструментарий по адаптации вашего кода к этому.
И это хорошая практика.
В остальных случаях — можно понять разработчиков, но это их решение приносит иногда весьма существенные затраты на адаптацию. И черт его знает, насколько это хорошо в общем смысле.
Фраза «пользователи — мертвый груз» — это вообще, на самом деле, за гранью.
Можешь обосновать выгодность новых технологий для бизнеса (например, стратегической выгодой, что переход на новый инструментарий значительно увеличит ретеншн засчет повышения стабильности и быстродействия сервиса — и желательно в цифрах и на основе какого-то опыта) — вперед, делай. Не можешь — плачь, колись, продолжай жрать кактус.
Просто пример из жизни:
В рабочем проекте мы привязаны не столько к версиям SDK и прочих third-party (которые мы поддерживаем в максимально актуальном состоянии), сколько к версии операционной системы, которую мы поддерживаем (что закрывает для нас возможность использовать САМУЮ актуальную версию некоторых third-party и, в результате мы иногда сами повторяем функциональность более новых версий). И, с одной стороны, это наша боль и наше страдание.
А с другой стороны, инком, который генерят пользователи, сидящие на «неактуальной» версии операционной системы — достаточен чтобы оплатить большой отдел разработчиков, которые и поддерживают эту старую систему. И еще останется. В частности на людей, занимающихся глубинным рефакторингом и пишущий код с большим количеством #ifdef для улучшения производительности на разных версиях. И вот смогли бы вы ДОКАЗАТЬ, что внедрение новых и хипстоватых инструментов даст вам такой бонус в новых пользователях, способный покрыть (и перекрыть) уже существующий доход?
Я мог бы вам порекомендовать еще вот такой вот сервис на посмотреть — www.leanplum.com/ — они помимо конфига предлагают еще и мобильные SDK, для легкого пользования оными, дефолтные настройки в случае отсутствия интернета и многое другое.
svn.gna.org/svn/gnustep/libs/libobjc2/trunk/selector.h — вот тут например приводится альтернативный вариант, при котором над char * (которому, к слову не всегда соответствует первая часть структуры, экономии чего-то ради, будучи замененная на некоторый индекс) существует и еще одно поле types, которое хранит в себе, судя по всему, сигнатуру вызова.
Я ни в коем случае не хочу обидеть язык Си, однако в данном случае я не вижу смысла в происходящем.
Селектор является «строкой» лишь постольку поскольку. Селектор является абстракцией, указателем в памяти, для удобства, помимо прочего, указывающую на некую описывающую его структуру (в данном случае С-стринг). С большего, этого знания достаточно для работы с этой частью языка.
Поэтому не дай вам бог использовать это знание в своих проектах.
P.S. К слову, могу порекомендовать закопаться на какое-то время в этот репозиторий Там все есть. Кроме определения SEL — потому что это определение кодогенерируемое :-)
Эта штука имеет обратное значение. objc_selector — является алиасом на *SEL, а не наоборот
Ну и 100 процентное покрытие — это избыточная (иногда значительно) сложность — особенное если имеешь дело не со stateless приложениями. Да и просто возникают тысячи вопросов на тему «о, это так здорово — но как протестировать, когда у нас вон тот объект дергает вон этот синглтон, в котором изменяется состояния вон тем классом и вообще?» На которые «просто писать код иначе» — не самый подходящий ответ))
Культура программирования и алгоритмика возникала не как самоцель, а как инструмент по контролю сложности и ограниченных ресурсов на сложных задачах. Не совсем понятно, почему она должна выходить из этой сферы.
Если идея оправдывается, то в проекте со временем появится сильный программист, который сделает все по науке и сможет поддерживать все в актуальном состоянии и помогать в развитии. И по моему мнению это значительно лучше кейса, когда идея не была реализована вообще по той причине, что простого инструментария не было, а позволить себе квалифицированного разработчика генератор идеи не смог.
Все ж таки задача программирования заключается в облегчении чьей-либо жизни)
Так что да — это, конечно забавный факт, что появилось много людей, создающих продукты, не обладая базовыми знаниями в computer science — но все-таки положительный.
Из личного опыта — от момента, когда я проникся и восхитился элегантностью TDD, в частности BDD, до момента, когда я смог его эффективно использовать на реальных задачах, сложнее «протестируйте калькулятор» — прошло около полутора лет — и то, потому, что я искренне верил в то, что это нужно и важно.
С какого-то момента считаю, что приложение, которое позиционирует себя как ежедневное, должно быть в первую очередь крайне лаконичным в выполнении основных действий. Потому что все красивости перестаешь замечать ко второй неделе использования. Жест с отрезанием ножницами показался крайне излишним. А вот идея с размерами шрифтов по-своему прекрасна.
ну и вызывает некоторое удивление понимание словосочетания проще всего :-)
Большинство задач, которые выглядят простыми уже кем-то решены в удобной для меня форме
И давать животноподобные имена грядущим подверсиям.
С противоположной стороны, для улучшения обстановки в семье, когда вы не работаете (вне определенного вами самостоятельно и заранее времени) — вы не работаете, не думаете сверх необходимого о работе и вообще всячески радуете вниманием близких и котов.
Очень частая ошибка фрилансера в том, что «работать когда хочешЬ» быстро превращается в «полуработать вообще всегда».
Для любых сторонних инициатив есть внутренний голос «но мне же нужно сделать это», а для «мне нужно сделать этО» не хватает мотивации.