В вас чувствуется очень прошареный маркетолог, во как вы все завернули, запутали и оказались в профите)
>> Думаю техническая поддержка сможет создать тот или иной код, но уже за отдельную плату, в общем как и все
В целом это я и хотел услышать. Логично, что для разработчика CMS проще будет что-то допилить, чем для стороннего разработчика, поэтому это, возможно, и выйдет дешевле. Однако это уже не совсем тоже самое, как купить CMS засовсемалоденег и быть счастливым :)
>Всё даже очень логично, мы обсуждаем лендинг-каталог
С чего вы взяли то? :) Я написал про CMS, т.е. в целом про CMS а не про такую, которая лендинги только умеет делать :)
Вот, все-таки программирование тут необходимо и не важно будет ли этим заниматься сам покупатель.
А значит ваши слова «Тем более сейчас кризис, и не каждый может позволить себе услуги программиста. » вводят в заблуждение.
Ну типа примерно так: вы пришли к изготовителю специальных ручной работы красовок и начали советовать купить другие стандартные кросовки и использовать их.
В целом формально вы вправе — т.к. ваш блог и все такое, но многие на это внимания не обращают.
>>К платной лицензии прилагается и тех поддержка и удобство
>>во многих аспектах, человеку не имеющего богатого опыта проще добавлять контент, оптимизировать его, составлять карту сайта
Вот это то меня и удивило, неужели в бесплатных до сих пор все плохо.
>>Мы платим в автосервисе за замен резины почему?
>>Потому, что нам не хочется пачкать руки, тратить время и надрываться над сменой резины,
Что-то вы начали юлить и привели очень странный пример.
Создание сайта:
-желающий сделать сайт.
-поставщик CMS комьюнити(если бесплатная), продавец CMS (если платная)
-программист
-дизайнер, верстальщик. (один человек может сделать все, но суть не меняется, более менее сложный сайт = задача по программированию)
Вы пишите про тех поддержку, вы имеете ввиду программирование?
Или получается, что при любой CMS программист таки нужен отдельно?
Ну так вроде, по логике вещей, бесплатные CMS могли бы уже вырасти до уровня платных? Я об этом.
Или вы имеете ввиду, что в целом уровень такой же, но к платной просто прилагается поддержка (ну т.е. небольшие услуги программиста)?
>Ну я хотя бы множественное лицо второго рода
>настоящего времени глаголов отличаю от повелительного наклонения.
>Писать — глагол первого спряжения, в окончаниях настоящего времени пишется «е».
Чтож, подловили :) Хотя мы тут про Rest вроде?
>Если у вас организована передача данных в виде, например, сериализованных
>PHP-объектов, то клиенту приходится знать, что на сервере работает PHP.
Какие-то вы бредовые примеры приводите, я писал про сравнение Restfull и обычный просто http, но впрочем даже в таком бредовом примере, нет клиенту не надо знать что там PHP, надо только знать формат сериализации, а он строгий.
>REST-методология требует представлять операции в виде собственно
> HTTP-запросов так, чтобы семантика операции была понятна из самого запроса.
Каша какая-то. Как связана семантика операции и формат получаемых данных?
>> Ну так в по идеалогии Restful нельзя сохранять состояние.
>Я именно это и написал
Тогда причем тут куки вообще?
>Интересное «без разницы».
>GET /user/{userid} клиент может кэшировать по отдельность для каждого userid, и
> инвалидировать кэш также по отдельности (используя If-Modified-Since, например).
>GET /user кэшировать вообще нельзя.
В вашем первом странном примере без разницы.
>Нет, не очень.
>Если у вас есть операция
>GET /?method=шарах
>И сервер проксирует её до другого гейтвея,
>она вполне может оказаться где-то по пути закэшированной
>и в реальности не выполниться.
Ну и? Есть метод и он что-то получает, раз GET, вы позволили ему где-то закешироваться.
>Эта схема может работать если и только если все промежуточные
>узлы понимают и правильно интерпретируют семантику HTTP.
Так Rest то тут вообще причем?
>>Достаточно заметить, что автор попросту не знает, что такое REST.
Простите, но вы тоже фигню всякую пишите :)
>>— клиент-серверная архитектура (в частности, клиента не заботит, на каких технологиях >>реализован сервер за счет унифицированного протокола)
Если взять тупо чистый http запрос, клиенту не пофигу что на сервре?
>>— отсутствие состояний: все детали операции содержатся в самой операции; т.е. в парадигме
>>REST нельзя сделать вот так:
>>DELETE /user/data
>>со взятием id юзера из куки. REST-клиент обязан отправить запрос вида
>>DELETE /user/{userid}/data
А кука у вас в чем так в этом случае принципиально от урла отличается? Так же на сервер уйдет в общем случае в заголовке.
>>А куку использовать строго для проверки, имеет ли право этот юзер удалять данные {userid}
Так вы перепутали куки с серверной сессией? Ну так в по идеалогии Restful нельзя сохранять состояние.
>>— управление кэшированием — методы, статусы и заголовки позволяют гибко кэшировать >>максимальный объём данных; в частности
>>GET /user/data — невозможно закэшировать, потому что id юзера знает только сервер
>>GET /user/{userid}/data — кэшировать уже можно
И только сервер знает, когда протухнет кеш, вообщем со стороны управлением кеша без разницы.
>>— многослойная архитектура — сервер может, не уведомляя клиет, проксировать по HTTP >>запрос дальше (что достижимо как раз за счет унифицированной работы с протоколом).
Очень много чего можно так проксировать, не уведомляя клиент, странный довод.
Браузеры то да, а вот серверное нестандартное не факт.
Если смотреть стандартный случай, клиент + api, то обычно все ок, но на практике часто бывают взаимные взаимодействия с различными сервисами, а везде реализовывать RESTful задолбаешься.
Проблема RESTful в том что мало кто делает именно точно RESTful, почти у всех какие-то особенности и оговорки.
Да и он далеко не все проблемы решает связанные с взаимодествие с API.
А еще вот есть Apache Thrift кстати, который решает больше проблем, немного в другой плоскости, но тоже по теме.
Окей, вот и я высказываю свое мнение — статья не очень, вам стоит реабилитироваться и написать еще, к тому же вы обещали «Мы собираемся в ближайшем будущем опубликовать несколько материалов пусть не о минусах со своей стороны, но о проблемах, которые мы решаем.» :)
Окей. Идея самописного биллинга вещь спорная, соглашусь. Но ведь она имеет право на жизнь, хотя бы потому что кто-то так делает и доволен, верно? Идея коробочной версии имеет свои проблемы, верно? Так почему вы в статье, в которой рекламируете свой продукт не проводите честное сравнение обоих подходов, а пишите только про плюсы своего и минусы другого?
Вы случайно не такой, как те менеджеры, которые вместо того чтобы понять, принять и решить проблему, выдумывают какие-то тренинги, тестирования, внешние показатели эффективности и веруют во влияния фаз Луны на качество кода?
Создатель софта, критичного для фирмы, пишущий его с самого начала как бы делает для бизнеса очень многое. И оставлять его просто безправным сотрудником так, что ему приходится «держать контору за яйца» это не очень умное решение. Если некий менеджер думает, что он пуп земли, а все остальные гавно, ему даже «носят как правило деловой характер (репутация и прочее)» не поможет.
Если же там на самом деле «сумрачный гений», возникает вопрос, а зачем изначально работали с «сумрачными гениями»? Почему не нашли нормальных адекватных людей, сэкономить хотели? Ну так сами себе буратины.
>Надеюсь проблемы с русским языком не мешают вам писать хороший самописный софт.
Многие программисты в работе даже устным русским почти не пользуются, не говоря уж про письменный, непонятно зачем вы так неумно наехали на человека.
>> Думаю техническая поддержка сможет создать тот или иной код, но уже за отдельную плату, в общем как и все
В целом это я и хотел услышать. Логично, что для разработчика CMS проще будет что-то допилить, чем для стороннего разработчика, поэтому это, возможно, и выйдет дешевле. Однако это уже не совсем тоже самое, как купить CMS засовсемалоденег и быть счастливым :)
С чего вы взяли то? :) Я написал про CMS, т.е. в целом про CMS а не про такую, которая лендинги только умеет делать :)
А значит ваши слова «Тем более сейчас кризис, и не каждый может позволить себе услуги программиста. » вводят в заблуждение.
В целом формально вы вправе — т.к. ваш блог и все такое, но многие на это внимания не обращают.
>>во многих аспектах, человеку не имеющего богатого опыта проще добавлять контент, оптимизировать его, составлять карту сайта
Вот это то меня и удивило, неужели в бесплатных до сих пор все плохо.
>>Мы платим в автосервисе за замен резины почему?
>>Потому, что нам не хочется пачкать руки, тратить время и надрываться над сменой резины,
Что-то вы начали юлить и привели очень странный пример.
Замена колес:
-желающий заменить колеса
-автомеханник.
Создание сайта:
-желающий сделать сайт.
-поставщик CMS комьюнити(если бесплатная), продавец CMS (если платная)
-программист
-дизайнер, верстальщик. (один человек может сделать все, но суть не меняется, более менее сложный сайт = задача по программированию)
Вы пишите про тех поддержку, вы имеете ввиду программирование?
Или получается, что при любой CMS программист таки нужен отдельно?
и статьи в целом норм, в чем проблема то?
Или вы имеете ввиду, что в целом уровень такой же, но к платной просто прилагается поддержка (ну т.е. небольшие услуги программиста)?
>настоящего времени глаголов отличаю от повелительного наклонения.
>Писать — глагол первого спряжения, в окончаниях настоящего времени пишется «е».
Чтож, подловили :) Хотя мы тут про Rest вроде?
>Если у вас организована передача данных в виде, например, сериализованных
>PHP-объектов, то клиенту приходится знать, что на сервере работает PHP.
Какие-то вы бредовые примеры приводите, я писал про сравнение Restfull и обычный просто http, но впрочем даже в таком бредовом примере, нет клиенту не надо знать что там PHP, надо только знать формат сериализации, а он строгий.
>REST-методология требует представлять операции в виде собственно
> HTTP-запросов так, чтобы семантика операции была понятна из самого запроса.
Каша какая-то. Как связана семантика операции и формат получаемых данных?
>> Ну так в по идеалогии Restful нельзя сохранять состояние.
>Я именно это и написал
Тогда причем тут куки вообще?
>Интересное «без разницы».
>GET /user/{userid} клиент может кэшировать по отдельность для каждого userid, и
> инвалидировать кэш также по отдельности (используя If-Modified-Since, например).
>GET /user кэшировать вообще нельзя.
В вашем первом странном примере без разницы.
>Нет, не очень.
>Если у вас есть операция
>GET /?method=шарах
>И сервер проксирует её до другого гейтвея,
>она вполне может оказаться где-то по пути закэшированной
>и в реальности не выполниться.
Ну и? Есть метод и он что-то получает, раз GET, вы позволили ему где-то закешироваться.
>Эта схема может работать если и только если все промежуточные
>узлы понимают и правильно интерпретируют семантику HTTP.
Так Rest то тут вообще причем?
Простите, но вы тоже фигню всякую пишите :)
>>— клиент-серверная архитектура (в частности, клиента не заботит, на каких технологиях >>реализован сервер за счет унифицированного протокола)
Если взять тупо чистый http запрос, клиенту не пофигу что на сервре?
>>— отсутствие состояний: все детали операции содержатся в самой операции; т.е. в парадигме
>>REST нельзя сделать вот так:
>>DELETE /user/data
>>со взятием id юзера из куки. REST-клиент обязан отправить запрос вида
>>DELETE /user/{userid}/data
А кука у вас в чем так в этом случае принципиально от урла отличается? Так же на сервер уйдет в общем случае в заголовке.
>>А куку использовать строго для проверки, имеет ли право этот юзер удалять данные {userid}
Так вы перепутали куки с серверной сессией? Ну так в по идеалогии Restful нельзя сохранять состояние.
>>— управление кэшированием — методы, статусы и заголовки позволяют гибко кэшировать >>максимальный объём данных; в частности
>>GET /user/data — невозможно закэшировать, потому что id юзера знает только сервер
>>GET /user/{userid}/data — кэшировать уже можно
И только сервер знает, когда протухнет кеш, вообщем со стороны управлением кеша без разницы.
>>— многослойная архитектура — сервер может, не уведомляя клиет, проксировать по HTTP >>запрос дальше (что достижимо как раз за счет унифицированной работы с протоколом).
Очень много чего можно так проксировать, не уведомляя клиент, странный довод.
Если смотреть стандартный случай, клиент + api, то обычно все ок, но на практике часто бывают взаимные взаимодействия с различными сервисами, а везде реализовывать RESTful задолбаешься.
Да и он далеко не все проблемы решает связанные с взаимодествие с API.
А еще вот есть Apache Thrift кстати, который решает больше проблем, немного в другой плоскости, но тоже по теме.
Если же там на самом деле «сумрачный гений», возникает вопрос, а зачем изначально работали с «сумрачными гениями»? Почему не нашли нормальных адекватных людей, сэкономить хотели? Ну так сами себе буратины.
Многие программисты в работе даже устным русским почти не пользуются, не говоря уж про письменный, непонятно зачем вы так неумно наехали на человека.