Кто то будет миллионером ? PHP в EXE

[-Tom-]

Люди такой вопрос, почему не сделают такую возможность для языков типа PHP собирать их в один файл что то похожее на EXE.
А то полно файлов, а так хочется клиенту скинуть один файл самого движка который бы запускался на сервере и все.

Это не возможно сделать ? не надо ? или просто не кто не думал об этом и всем все удобно...
Как мне кажется, кто такое сделает тот заработает хорошую кучку денег :)

[AlexZ75]

-Tom-,
Гы... А зачем?

[Private person]

...клиенту скинуть один файл самого движка который бы запускался на сервере и все.

я недопонял что имеется ввиду

[observer]

...клиенту скинуть один файл самого движка который бы запускался на сервере и все.

я недопонял что имеется ввиду

Видимо аналог *.jar для PHP.

[Юрий]

Существует вот такая фича
http://www.bambalam.se/bamcompile/

[-Tom-]

Конкретнее я имел в виду вот что.
Сейчас у меня в софте 35 классов.
Это "мозги" системы, которые хорошо бы упаковать в один файл.
Все равно их клиент не трогает, если кто то и пытается что то дописать, то ему разрешено по лицензии это делать только через API, он не имеет право трогать основные файлы.

То есть вот такие основные классы системы собрать в один файл, наверное это как сказал observer "аналог *.jar для PHP" и чтобы, при этом все работало на любом сервере как и раньше.
Очень удобно и компактно.

А для многих клиентов вообще очень удобно упаковать все php файлы в один файл, например который бы назывался index.php и все, в нем уже и папки с другими php файлами и так далее, весь основной програмный код все в одном файле который уходит к клиенту а бинарном формате.

Надо бы Зенду написать, такая фишка была бы удобна весьма, не только лично мне, а всем кто продает софт без открытого кода написанный на php.

[Юрий]

А почему в таком случае не подходит Zend Safeguard?

[-Tom-]

Юрий Он у меня есть этот Zend Safeguard, хоть я и не доволен этим софтом, если честно, но так как альтернативы хорошей нет, то вот на днях продлил лицензию еще на год.

Просто как мне видется, если вместо кучи php файлов, к которым и так нет доступа по лицензии, в итоге будет только 1 файл, это будет очень удобно, как и для обновлений, так и для других важных вещей :)

Имхо, можно и стар-тап открыть под такую идею :))

[Private person]

Конкретнее я имел в виду вот что.
Сейчас у меня в софте 35 классов.
Это "мозги" системы, которые хорошо бы упаковать в один файл.
Все равно их клиент не трогает, ...

под "клиентом" я понял клиентскую часть какого-то приложения, потому и странно это "звучало".

[AlexZ75]

-Tom-,
Это бред, просто надо сделать нормальные скрипты для установки.
Возможный сценарий - клиент получает один файл со скриптом, который самораспаковыватся во временную директорию и запускает установку.

[-Tom-]

AlexZ75 Да наверное ты прав, бред я написал полный, а ты предложил хороший сценарий, главное оригинальный что я даже не подумал о таком уникальном варианте обновлений.
А ведь для него надо просто правильно писать скрипты для установки/обновлений, и потом у меня будет полный доступ и настоящим папкам и файлам менять CHMOD и файлы переписывать даже если нет прав, и так далее, всего делов то, действовать надо под рутом, и можно делать все обновления спокойно :)

З.Ы
А если серьезно, то автоматом обновлять скрипты сейчас можно, более менее нормально только через FTP сервер. Но многие не могут дать туда временый доступ скрипту обновлений.

[Tezaurus]

Люди такой вопрос, почему не сделают такую возможность для языков типа PHP собирать их в один файл что то похожее на EXE.
А то полно файлов, а так хочется клиенту скинуть один файл самого движка который бы запускался на сервере и все.

Это не возможно сделать ? не надо ? или просто не кто не думал об этом и всем все удобно...
Как мне кажется, кто такое сделает тот заработает хорошую кучку денег

На .NET ето легко. На PHP пока вроде не придумали.

[AlexZ75]

-Tom-,
О! Я мыслей читать не научился, но насколько я понимаю, ты теперь поднял три разные темы:
1. Установка скриптов (ты хотел бы все-в-одном).
2. Шифрование скриптов, чтобы делать не open-source
3. Обновление скриптов
Все ети вещи могут и, ИМХО, должны, делаться независимо.
Если вы делаете пакаджинг, вы должны предусмотреть его нормально установку и работу под любым юзером.

Я думаю, что решения для энкодинга можно найти немало, например:
http://www.sourceguardian.com/

На счет обновлений... да все зависит от клиента.


Если ты дорос до серьезного деплоймента, заведи себе скриптописца, который тебе решит эти проблемы.

[-Tom-]

AlexZ75

О! Я мыслей читать не научился, но насколько я понимаю, ты теперь поднял три разные темы:
1. Установка скриптов (ты хотел бы все-в-одном).
2. Шифрование скриптов, чтобы делать не open-source
3. Обновление скриптов

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

Если вы делаете пакаджинг, вы должны предусмотреть его нормально установку и работу под любым юзером.

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

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

Я думаю, что решения для энкодинга можно найти немало, например:
http://www.sourceguardian.com/

sourceguardian вскрывается как баночка и его вскрывалки валяются по всему инету уже второй год, в отличие от зенда который вкрывают по заказу, и то легко только до версии 3 и ниже.

Если ты дорос до серьезного деплоймента, заведи себе скриптописца, который тебе решит эти проблемы.

Странно, а что значит дорос до серьезного деплоймента ?
Наш софт работает во многих странах, и в компаниях где работают по 3000 программистов, и в компаниях где не работает не один программист а сидит только один дизайнер.
И такие компании как Wall Street Journal и другие не меньше их в разных направлениях, пользуются нашими решениями и довольны....
Или серьезный деплоймент в твоем понимании, это когда сидит куча программистов, половину из которых можно уволить, и не кто не заметит, и пишет custom софт для местных крупных компаний ?

А по поводу проблемы, ее решение на скриптах, просто это совсем не то что я хотел бы иметь, а делать полу-решения, это временый выход, который врядли оправдает затраты на него в этом случае.

Поэтому хотелось бы готовое решение, и не на скриптах, как например Zend Studio для программироваия, все в одном, купил и все можно занялся своими делами.

[DK]

По мне любые скриптовые языки годятся только для демо. Серьёзные решения, когда производитель несет ответственность за продукт, невозможны, если кто-либо другой может свободно менять сорсы. Единственным решением может быть только компиляция в машинный либо бинарный промежуточный код. Т.е. подальше от скриптов, поближе к компилируемым языкам. На ЮНИКСе это Jаva или С/С++. Там, правда, есть свои недостатки: удлиняется время разработки, сложнее дебаггить на машине юзера, етц. Зато есть компайлер, который помогает ловить ошибки.

ПС. Компиляция не спасает от хакеров, но спасает от "случайных" хакеров.

[AlexZ75]

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

Я говорю, что программер, который берется за эту задачу может разделить ее. Я не думаю, что шифровка файлов и пакаджинг может хоть как то повлиять на перформанс, это можно включить как пункт №4, и решать таки отдельно.

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

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

Опять оптимизация.... Ваш сложный производственный процесс, не являет собой ничего нового, вы просто пытаетесь выдать желаемое за действительное.

sourceguardian вскрывается как баночка и его вскрывалки валяются по всему инету уже второй год, в отличие от зенда который вкрывают по заказу, и то легко только до версии 3 и ниже.

Дык пользуйте тогда зенд!

Странно, а что значит дорос до серьезного деплоймента ?
Наш софт работает во многих странах, и в компаниях где работают по 3000 программистов, и в компаниях где не работает не один программист а сидит только один дизайнер.
И такие компании как Wall Street Journal и другие не меньше их в разных направлениях, пользуются нашими решениями и довольны....
Или серьезный деплоймент в твоем понимании, это когда сидит куча программистов, половину из которых можно уволить, и не кто не заметит, и пишет custom софт для местных крупных компаний ?

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

А по поводу проблемы, ее решение на скриптах, просто это совсем не то что я хотел бы иметь, а делать полу-решения, это временый выход, который врядли оправдает затраты на него в этом случае.

Поэтому хотелось бы готовое решение, и не на скриптах, как например Zend Studio для программироваия, все в одном, купил и все можно занялся своими делами.

Дык купите, в чем проблема?! Видимо продукт 4 в одном еще не просто не придумали, я подозреваю что он нужен столь узкому количеству людей, и такова цена разработки, что его еще не начали планировать. В конце-концов переходите на Java, там все это есть, но опять таки программеру надо не слабо платить.

[-Tom-]

AlexZ75

Я говорю, что программер, который берется за эту задачу может разделить ее. Я не думаю, что шифровка файлов и пакаджинг может хоть как то повлиять на перформанс, это можно включить как пункт №4, и решать таки отдельно.

Опять оптимизация.... Ваш сложный производственный процесс, не являет собой ничего нового, вы просто пытаетесь выдать желаемое за действительное.

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

О! Тогда у вас есть ресурсы чтобы разработать соответсвующий продукт, отвечающий вашим высоким требованиям, хотя при таких клиентах непонятно, зачем нужен энкодинг, они не опустятся до воровства.

Странно а кто говорит что крупные или средние или мелкие компании воруют ?
Или в зависимости от веса компании обязательно надо отдавать ей сорсы своего продукта

А разрабатывать продукт который не входит в мою компетенцию, это я оставлю тем кто думает что знает все, и все надо разрабатывать и писать самим.

В моем пониманий серьезный деплоймент - это когда к нему серьезно относятся, когда этим занимаются профессионалы интеграции.

Хорошее замечание, полностью согласен.
Проблема только в том что профессионалов в любых направлениях очень мало, много есть тех кто думает что он профи.
Профи в моем понимании, это тот кто может видеть задачу в 4D, а к сожалению большинство видят ее как 2D.

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

[uccaxap]

ну дa пoстaвит xoстер екзешник неизвестнoгo сoдержaния