AppleScript - готово для предприятий?

• Является ли это тихим, зависит от приложения и ваших скриптов, многие приложения захотят открывать окно на экране и т. Д., Уровень и тип поддержки приложений, которые могут иметь приложения для AppleScripts, могут сильно различаться.
• Является ли он стабильным и долговечным, вроде бы проблема в том, что AppleScripts не очень быстр, он все делает с AppleEvents, и поэтому вы можете часто сталкиваться с проблемами тайм-аута с AppleEvents или AppleScripts, которые занимают много времени, хотя я должен признать, что в последнее время не очень много использовал AppleScript, но когда я использую современные более быстрые процессоры, это не такая большая проблема, как раньше.
• Является ли он зрелым, он существует дольше, чем Mac OS X, самая большая проблема с AppleScripts, которую я обнаружил, заключается в том, что язык выглядит как естественный язык, что создает впечатление, что вы можете просто написать что-то, что соответствует его шаблону естественного языка, и он будет работать, но это не так, и из-за его естественного языка, такого как синтаксис, требуется время, чтобы узнать, что будет работать, он не похож на другие языки, где вы можете разработать синтаксис, а затем практически любая комбинация, которая подчиняется этому синтаксису, будет работать. Я все еще разочарован операциями, которые работают со списком, язык создает впечатление, что вы можете выполнять некоторые операции фильтрации в любом списке, хотя на самом деле это приложение, которое вы используете AppleScripting, чтобы предоставить вам эту функциональность, например, вы можете попросить Finder чтобы получить каждое работающее приложение, которое имеет какое-либо свойство из каждого активного приложения, но если у вас есть собственный список, вы должны вручную перечислить его и проверить каждый элемент индивидуально.

AppleScript - это язык, с которым вы можете легко экспериментировать, поэтому я бы просто попробовал кое-что, чтобы посмотреть, работает ли он так, как вы хотите, а затем конкретизировать, если он будет успешным. Люди использовали AppleScripts для написания полного приложения Cocoa, но я никогда не думал, что оно подходит для чего-то подобного.

Ответ Натана Дэя правильный. Но это еще не все.

AppleScript можно разделить на два уровня - уровень Open Scripting Architecture и язык AppleScript.

Открытая архитектура сценариев - это то, что облегчает отправку событий Apple и реагирование на них, то есть то, что отправляется между приложениями. В Open Scripting Architecture есть способы использовать те же функции без использования AppleScript.

Например, Apple предоставляет структуру Scripting Bridge., с помощью которого вы можете написать этот код в Objective-C и Какао (и, как следствие, в другом коде, который сам может соединяться с Какао).

Существуют также другие библиотеки для других языков, такие как Ruby rb-appscript и rubyosa и скрипт приложения библиотеки Python.

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

@Jesper: Scripting Bridge проблематичен, а appscript и RubyOSA фактически мертвы, поэтому рекомендовать их не стоит.

...

@boj: Спрашивать, является ли сам язык AppleScript «готовым для предприятий», - неправильный вопрос, потому что это, безусловно, меньшая из ваших проблем. Вы должны спросить:

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

и:

«Является ли Apple правильным выбором для серверной части чего-либо?»

iOS может быть прекрасной ориентированной на потребителя мобильной платформой, а OS X - достойной операционной системой для настольных ПК, но что касается серверной, я бы не стал трогать их баржой, если только они не были абсолютно последним и единственным вариантом (например, вы застряли в использовании одной из проприетарных служб OS X Server, другой альтернативы нет). Виртуализация - не лучшая идея. IME, а такие корпоративные основы, как LOM и стоечные корпуса, не подходят. И не забывайте о тенденции Apple внезапно / радикально пересматривать свои продуктовые линейки, функции и услуги с минимальным предупреждением или без него. Если вам нужна стабильность, предсказуемость и поддержка на уровне предприятия, придерживайтесь Linux и / или Windows boxen.

В вашем случае вы говорите об использовании iMessage, и поскольку это 1. проприетарный протокол и 2. Apple до сих пор не опубликовала базовые API-интерфейсы, это действительно сужает ваши возможности. Первое, что вы, вероятно, должны спросить себя: уверены, что вы не можете найти подходящее решение с помощью SMS, которое одновременно открыто и уже хорошо поддерживается на уровне предприятия? Я думаю, вы могли бы привести веское экономическое обоснование: это может стоить немного дороже, но обратите внимание, что они платят за стабильность и надежность и (как вы надеетесь) профессионально сконструированную систему.

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

• Что может привести к сбою вашей системы (например, диалоговые окна приложений, появляющиеся в окне без заголовка, являются серьезным PITA и не учитывают сбои приложений, проблемы с подключением и другие возможности, вплоть до смерти самого окна)?

• На какие простои вы рассчитываете и каковы финансовые последствия любого сбоя? (То есть, каково ваше ожидаемое соглашение об уровне обслуживания для этой услуги?) Если это что-то критически важное для удаленного бизнеса или корпоративные требования, превышающие, скажем, две девятки времени безотказной работы, то бегите, а не переходите к существующему решению.

• Каковы ваши варианты восстановления / перезапуска системы, когда что-то пойдет не так (например, вы попытаетесь настроить автоматическое переключение при отказе, или попросите кого-то удаленно подключиться к ящику, чтобы попытаться исправить это, или есть ли администратор на месте, который циклически мощность), и есть ли потеря данных или другие проблемы, о которых вам нужно беспокоиться? (например, вы можете сохранить свою бизнес-логику и базу данных в отдельном окне Win / Linux, чтобы система не теряла информацию о том, где оно было, когда поле OS X запускается / перезагружается.)

• Какова сделка с обслуживанием системы: если вы недоступны или больше не находитесь там, сможет ли кто-нибудь еще обработать код и / или развернутые системы без вас?

BTW, WWDC и 10.9 сейчас не так уж и далеко, поэтому я бы порекомендовал подождать, чтобы узнать, будет ли iMessage API общедоступным в 10.9, прежде чем тратить время на AppleScript и Messages.app. Если / когда API обмена сообщениями будет открыт, это позволит вам создать более надежный сервис в ObjC, хотя помните, что вы все равно будете привязаны к OS X, чтобы разрабатывать и запускать его.