Comments 14
Ну, там есть и обратная проблема. Что может быть проще, чем XML RPC over HTTP?… и это вместо plaintext pipe'а. Когда есть готовые библиотеки очень легко можно застрять в мире высоких абстракций, не замечая того оверхеда, что внизу. (не замечая до определённого момента).
В целом — да. С другой стороны, железо стоит дешево, а люди — дорого. Лучше, когда система требует не два сервера, а пять, чем когда она быстрая и производительная, но ни один программист не может быстро ответить, можно ли в принципе реализовать какое-либо изменение, не говоря уже о том, сколько на это уйдет времени по его оценке.
Железо стоит дёшево в количестве 1шт. Когда речь идёт о том, будет внутри железки 1ГГц процессор или 300МГц (и это всё от одной батарейки), то нет, железо стоит очень дорого.
я сервера имел ввиду, конечно. Если программно-аппаратное решение разрабатывается, там подход, конечно, должен учитывать требования к производительности, энергопотреблению, теплоотдаче и многому другому… Там тонкостей вообще до фига. А для сайтов-сервисов лучше добавить еще один (два, пять) сервера, зато иметь красивую и прозрачную архитектуру, чем оптимизировать донельзя, чтобы потом любое изменение было целым проектом… Я тут недавно с одними людьми общался, руководителями интернет-магазина, так у них он развернут, по его словам, на сорока серверах. Мне вообще очень сложно представить, что же там такое должно быть, чтобы не хватило 2-4 серверов. Но для 2-4 серверов написать софт, способный перерабатывать несколько миллионов хитов очень непросто. Поэтому обычно такие магазины ставят на 5-8 серверов и их достаточно по уши (у нас осенью так будет). Так вот, если есть выбор — оптимизировать ПО в ущерб архитектурной целостности и supportability, в ущерб стоимости поддержки и развития, или добавить пару серверов и ничего не трогать, то лучше выбрать второе. А трогать уже без спешки — проводить рефакторинг, взвешивая каждое изменение.
Вообще в универсальности интерфейса есть и недостаток: он может быть недостаточно гибок
Возможно, но тогда это повод пересмотреть архитектуру и сделать усложнение правильно. Без этого подхода решение простое — например, одна система просто напрямую обращается через SQL-запросы к другой. Выходит гибко-гибко. Но любое изменение структуры БД выходит очень трудоемким процессом. Если же делать через веб-интерфейсы, в какой-то момент понимаешь, что сервиса не хватает и пересматриваешь архитектуру. Это может повлечь больших затрат на проект, зато меньших — на поддержку.
>Создание программы, оперирующей своими форматами и не умеющей общаться с себе подобными — прошлый век.
Сейчас, по-моему, уже мало кто без необходимости (жёсткие требования к размерам и/или скорости обработки, например СУБД) пользуется своими форматами (как правило бинарными с неизвестной структурой), да ещё и не предоставляя экспорта хотя бы в одном «приличном» формате. По крайней мере в большинстве приложений, с которыми я сталкивался в последнее время (десктопные, серверные и веб-приложения), данные хотя бы экспортируются/импортируются в/из CSV, XML, YAML, JSON и т. п. Неужели ещё кто-то не понимает, что возможность интеграции с другими продуктами — это плюс для своего продукта, а не продуктов конкурентов?
Сейчас, по-моему, уже мало кто без необходимости (жёсткие требования к размерам и/или скорости обработки, например СУБД) пользуется своими форматами (как правило бинарными с неизвестной структурой), да ещё и не предоставляя экспорта хотя бы в одном «приличном» формате. По крайней мере в большинстве приложений, с которыми я сталкивался в последнее время (десктопные, серверные и веб-приложения), данные хотя бы экспортируются/импортируются в/из CSV, XML, YAML, JSON и т. п. Неужели ещё кто-то не понимает, что возможность интеграции с другими продуктами — это плюс для своего продукта, а не продуктов конкурентов?
Ну вот опять.
Не скажу за CORBA, но есть ли у Вас конкретные претензии к COM?
«Узкое применение»? Да он в Windows ВЕЗДЕ. То есть вообще везде. Что же до «универсальности» — прошу пояснить свою мысль. Это Вы о кроссплатформенности? Или о том, что какие то интерфейсы невыразимы на MIDL?
Вот как раз это следовало приводить в качестве отрицательного примера ВООБЩЕ не проработанной технологии для связывания разнородных систем. Ну то есть ее могло хватать для задач тридцатилетней давности, но сейчас — однозначно нет.
Что значит «потенциально»? Вообще то, если взять пример из Вашей первой статьи, то на PS все будет именно так, как я описал:
ps | where {$_.Name -match «powershel+»} | kill
Естественно есть сокращения для часто используемых вещей типа «kill -n powershe*», но это уже абстракция более высокого уровня, созданная исключительно для удобства (программист может и сам вводить эти абстракции, если они ему нужны)
Что Вы хотите сказать? Даже если брать только Windows 7, в которой он по дефолту, то установлено уже почти 200 миллионов копий — в несколько раз больше, чем всех установок Linux, MacOSX, SUA/Windows и всяких древних коммерческих юниксов.
В качестве отрицательных примеров можно вспомнить омгэшную CORBA и майкрософтовский COM — довольно плохо проработанные технологии для связывания разнородных систем.
Не скажу за CORBA, но есть ли у Вас конкретные претензии к COM?
А COM имеет довольно узкое применение для связи программ в среде MS Windows, хотя никто не мешал его с самого начала разработать более универсальным.
«Узкое применение»? Да он в Windows ВЕЗДЕ. То есть вообще везде. Что же до «универсальности» — прошу пояснить свою мысль. Это Вы о кроссплатформенности? Или о том, что какие то интерфейсы невыразимы на MIDL?
В мире Unix, для взаимодействия консольных программ есть технология каналов (pipe), о которой я уже писал раньше.
Вот как раз это следовало приводить в качестве отрицательного примера ВООБЩЕ не проработанной технологии для связывания разнородных систем. Ну то есть ее могло хватать для задач тридцатилетней давности, но сейчас — однозначно нет.
Майкрософт, например, в своей реализации пайпов в powershell добавила объектность, что потенциально должно было сделать их супергибкими. Но простые решения, как говорится, «рулят».
Что значит «потенциально»? Вообще то, если взять пример из Вашей первой статьи, то на PS все будет именно так, как я описал:
ps | where {$_.Name -match «powershel+»} | kill
Естественно есть сокращения для часто используемых вещей типа «kill -n powershe*», но это уже абстракция более высокого уровня, созданная исключительно для удобства (программист может и сам вводить эти абстракции, если они ему нужны)
И где сейчас этот powershell…
Что Вы хотите сказать? Даже если брать только Windows 7, в которой он по дефолту, то установлено уже почти 200 миллионов копий — в несколько раз больше, чем всех установок Linux, MacOSX, SUA/Windows и всяких древних коммерческих юниксов.
1. К COM претензии только в одном — за рамки мира windows он не выходит. Внутри windows вполне себе технология. Я cobra ругаю, а не com.
2. Про узкое применение — я имел ввиду для межпрограммного взаимодействия в однородной майкрософтовской среде. Например, свою почтовую службу, работающую на юниксе, я по COM Ник чему не подключу. А по SOAP, например, вполне. Хотя, конечно, это не совсем сравниваемые вещи.
3. Юниксовое связывание используется на несколько порядков активнее, чем виндовое COM. Потому что его используют не только 'родные' компонеты ОС, но и 90% программ на sourceforge. Поэтому с windows powershell сравнивать плохо.
У нас тут был великолепный опыт разработки на windows script engine. я сейчас с айпада пишу — неудобно, если Макс вылезет, буду ему признателен за примеры. Это вообще чудо какое-то, а не инструмент. Хотя не совсем в тему.
2. Про узкое применение — я имел ввиду для межпрограммного взаимодействия в однородной майкрософтовской среде. Например, свою почтовую службу, работающую на юниксе, я по COM Ник чему не подключу. А по SOAP, например, вполне. Хотя, конечно, это не совсем сравниваемые вещи.
3. Юниксовое связывание используется на несколько порядков активнее, чем виндовое COM. Потому что его используют не только 'родные' компонеты ОС, но и 90% программ на sourceforge. Поэтому с windows powershell сравнивать плохо.
У нас тут был великолепный опыт разработки на windows script engine. я сейчас с айпада пишу — неудобно, если Макс вылезет, буду ему признателен за примеры. Это вообще чудо какое-то, а не инструмент. Хотя не совсем в тему.
Блин, он corba на cobra переправил
1. Не могу вспомнить ни одной Windows-specific части в COM. Более того, есть успешные реализации типа COMsource или даже так. Если смотреть на неполные реализации COM, то все становится еще интереснее. Под прицелом оказываются не только carbon/cocoa, но и I/O Kit (да, у некоторых даже драйверы ядра частично на COM).
2. Дык COM как таковой здесь ни при чем. Более того, «довольно плохо проработанные технологии для связывания разнородных систем» к этой претензии не относится ну совсем. То есть вообще. Более того, тот же XPCOM довольно точно повторяет собственно дизайн COM, но ABM требует, чтоб IUnknown был переименован в nsISupports. Ну а w3c «на полных парах» разрабатывает WebIDL. Глядишь лет через 10-15 (когда у всех уже будут собственные «нестандартные» реализации) и примут.
3. Вообще то, виндовое компонентное связывание используется на несколько порядков шире, чем plain-text пайпы. Хотя бы потому, что оно проникло далеко за пределы винды.
Windows script Host, Вы имели в виду? Отличная штука, да. До сих пор частенько пользуюсь — чисто по привычке.
2. Дык COM как таковой здесь ни при чем. Более того, «довольно плохо проработанные технологии для связывания разнородных систем» к этой претензии не относится ну совсем. То есть вообще. Более того, тот же XPCOM довольно точно повторяет собственно дизайн COM, но ABM требует, чтоб IUnknown был переименован в nsISupports. Ну а w3c «на полных парах» разрабатывает WebIDL. Глядишь лет через 10-15 (когда у всех уже будут собственные «нестандартные» реализации) и примут.
3. Вообще то, виндовое компонентное связывание используется на несколько порядков шире, чем plain-text пайпы. Хотя бы потому, что оно проникло далеко за пределы винды.
Windows script Host, Вы имели в виду? Отличная штука, да. До сих пор частенько пользуюсь — чисто по привычке.
Ага. Уникальный опыт с Windows script Host у нас имеется.
По просбе Рауфа распишу поподробнее.
Писали мы инсталятор для XP.
Инсталятор этот должен был снести MySQL, Adobe Air и nCron из состава старой софтины, затем установить наш новый софт состоящий из Apache,PHP,nCron,Chromium-portable, fonts, images и собственно PHP-приложения.
Стандартные install-генераторы нам не подходили, ибо установка должна была проходить в один клик и были специфические вещи, с которыми стандартный генератор не справится.
Итак задача полностью:
Запуск из-под админа.
Снести службу MySql
Снести службу nCron
Установить консольный zip.exe
Распаковать части нового ПО и раскидать по своим местам
Дать права на часть новых файлов в системе непривелегированному пользователю some_user
Зарегистрировать службу Apache и прописать ей авто-старт
Зарегистрировать службу Cron и прописать ей авто-старт
Прописать в PATH пути до hg.exe и php.exe, чтоб потом не мучаться
Пользователю some_user в автостарт прописать вместо explorer.exe (ну там уже не explorer, а Air приложение) Chromium в полноэкранном режиме.
Забрать с сервера данные
Сменить разрешение экрана
Перезагрузиться, чтобы приложение стартовало при загрузке.
Мне как, пользователю Linux на своей системе нацарапать такой инсталятор на Bash — полчаса.
Когда-то давно я помню игрался с Windows script Host, потому решил, что за полдня я этот инсталятор напишу.
В итоге вышло ДВЕ НЕДЕЛИ на разработку инсталятора. И это при всем том, что мне постоянно помогал очень грамотный в WSH Windows-админ. (Спасибо, Дима!)
Мы встретили много нелогичностей
1. Где-то надо использовать двойные кавычки, а где-то одинарные.
2. Чтобы запустить системную команду иногда нужно писать cmd /c command
3. Как поменять права на папку рекурсивно скриптом, не проходя вручную по дереву не нашли, пришлось после создания пустой папки присваивать ей права и устанавливать атрибут наследования прав подкаталогами.
4. Шрифты простым копирование в каталог Windows/fonts не устанавливаются. Нужно после этого открыть explorer.exe на этом каталоге, чтоб винда автоматом установила эти шрифты, ну или писать каждый фонт вручную в реестр.
5. Ветки реестра пользователей назваются не по имени а по какому-то SID, чтобы его найти нужно сделать запрос (нечто типа SQL) к WMI (Windows Management Interface) и забрать этот SID по имени пользователя.
6. Записать в чужую ветку даже из-под админа просто так не получится. Ветка не подгружена — надо залогинить пользователя в систему. Но как сделать это в скрипте??? Лучшего способа мы не нашли: стартанули службу планировщика задач, установили задание на calc.exe через полчаса, принудительно стартанули задание — Ура!!! Пользователь залогинен.
7. Реестр вроде удобная вещь и все настройи системы должны храниться там, но вот беда — с разрешением экрана какая-то Ж… Там столько всего нужно поменять… Пришлось взять какую-то консольную программку — qres.exe.
8. В дополнение ко всему такие вещи как запись пользователю в реестр, исполнение qres.exe работают нестабильно, потому приходится проверять результат и повторять операцию.
9. ага, вот еще вспомнил — в параметрах комманды sc (Service Control) есть параметр старт… Так вот мы долго ржали, когда поняли, что start=auto не работает, но работает start= auto (с пробелом — это должны быть разные argv[ ] ) :) ( чтобы выключить компьютер нажмите кнопку «пуск» — Где логика???)
Вкусный опыт правда? После этого я уже не говорю, что Windows простая или плохая система. Для меня не подходит — да! Но теперь я знаю, что она гораздо сложнее *nix в тех местах, где эта сложность не нужна. Я уверен, что Windows нужно просто знать, и еще больше уверен, что людей, действительно знающих Windows очень не много! На моем пути был только один (все тот же Дима).
Мои выводы: под Windows писать софт я постараюсь не браться. Если нужно просто, быстро, стабильно и предсказуемо — Выбирайте *nix. Unix way is my way.
По просбе Рауфа распишу поподробнее.
Писали мы инсталятор для XP.
Инсталятор этот должен был снести MySQL, Adobe Air и nCron из состава старой софтины, затем установить наш новый софт состоящий из Apache,PHP,nCron,Chromium-portable, fonts, images и собственно PHP-приложения.
Стандартные install-генераторы нам не подходили, ибо установка должна была проходить в один клик и были специфические вещи, с которыми стандартный генератор не справится.
Итак задача полностью:
Запуск из-под админа.
Снести службу MySql
Снести службу nCron
Установить консольный zip.exe
Распаковать части нового ПО и раскидать по своим местам
Дать права на часть новых файлов в системе непривелегированному пользователю some_user
Зарегистрировать службу Apache и прописать ей авто-старт
Зарегистрировать службу Cron и прописать ей авто-старт
Прописать в PATH пути до hg.exe и php.exe, чтоб потом не мучаться
Пользователю some_user в автостарт прописать вместо explorer.exe (ну там уже не explorer, а Air приложение) Chromium в полноэкранном режиме.
Забрать с сервера данные
Сменить разрешение экрана
Перезагрузиться, чтобы приложение стартовало при загрузке.
Мне как, пользователю Linux на своей системе нацарапать такой инсталятор на Bash — полчаса.
Когда-то давно я помню игрался с Windows script Host, потому решил, что за полдня я этот инсталятор напишу.
В итоге вышло ДВЕ НЕДЕЛИ на разработку инсталятора. И это при всем том, что мне постоянно помогал очень грамотный в WSH Windows-админ. (Спасибо, Дима!)
Мы встретили много нелогичностей
1. Где-то надо использовать двойные кавычки, а где-то одинарные.
2. Чтобы запустить системную команду иногда нужно писать cmd /c command
3. Как поменять права на папку рекурсивно скриптом, не проходя вручную по дереву не нашли, пришлось после создания пустой папки присваивать ей права и устанавливать атрибут наследования прав подкаталогами.
4. Шрифты простым копирование в каталог Windows/fonts не устанавливаются. Нужно после этого открыть explorer.exe на этом каталоге, чтоб винда автоматом установила эти шрифты, ну или писать каждый фонт вручную в реестр.
5. Ветки реестра пользователей назваются не по имени а по какому-то SID, чтобы его найти нужно сделать запрос (нечто типа SQL) к WMI (Windows Management Interface) и забрать этот SID по имени пользователя.
6. Записать в чужую ветку даже из-под админа просто так не получится. Ветка не подгружена — надо залогинить пользователя в систему. Но как сделать это в скрипте??? Лучшего способа мы не нашли: стартанули службу планировщика задач, установили задание на calc.exe через полчаса, принудительно стартанули задание — Ура!!! Пользователь залогинен.
7. Реестр вроде удобная вещь и все настройи системы должны храниться там, но вот беда — с разрешением экрана какая-то Ж… Там столько всего нужно поменять… Пришлось взять какую-то консольную программку — qres.exe.
8. В дополнение ко всему такие вещи как запись пользователю в реестр, исполнение qres.exe работают нестабильно, потому приходится проверять результат и повторять операцию.
9. ага, вот еще вспомнил — в параметрах комманды sc (Service Control) есть параметр старт… Так вот мы долго ржали, когда поняли, что start=auto не работает, но работает start= auto (с пробелом — это должны быть разные argv[ ] ) :) ( чтобы выключить компьютер нажмите кнопку «пуск» — Где логика???)
Вкусный опыт правда? После этого я уже не говорю, что Windows простая или плохая система. Для меня не подходит — да! Но теперь я знаю, что она гораздо сложнее *nix в тех местах, где эта сложность не нужна. Я уверен, что Windows нужно просто знать, и еще больше уверен, что людей, действительно знающих Windows очень не много! На моем пути был только один (все тот же Дима).
Мои выводы: под Windows писать софт я постараюсь не браться. Если нужно просто, быстро, стабильно и предсказуемо — Выбирайте *nix. Unix way is my way.
CORBA вроде как ооочень в яндексе любят кстати.
Sign up to leave a comment.
Искусство программирования под Unix (и не только). Часть третья, «правило композиции»