обезпечить безопасность софт апдейтов намного легче – просто надо использовать цифровую подпись. и не хранитъ сертификат подписи на сайте.
большенство 'нормальных' прог так и делают. так что сломав сайт невозможно запустить в оборот 'левую' версию.
> В результате на сервере хранится только анонимный «мусор», ломать ради него сервер бессмысленно.
Очень даже имеет смысл. меняем JS и перехватываем все мастер пароли у всех кто заходит. онлайн менеджер для паролей – ОЧЕНЬ плохая идея.
Рилэкс, пипл :)
Он совсем не имел в виду что ваша инфа должна быть доступна всем.
Как раз наоборот. И Гугл охраняет её очень не плохо.
Но.
Есть законы. И естъ судебные повестки. И в **некоторых** случаях Гуглу просто придётся поделиться инфой с органами.
А что он имел в виду это: «Если вы занимаетесь чем то таким что вы **очень** боитесь что кто нибудь узнает (даже если для етого надо идти в суд) то, возможно вам действительно не стоит делать этого в онлайне (или даже вообще не стоит :).
Например собираясь прибитъ тёщу не стоит гуглить „куда спрятать труп“ :)
* «git branch -D» исползуется толко в исключительных случаях т.к. он позволяет потерять данные. в 99% случаев лучше использовать «git branch -d» — ета команда вернёт ошибкы при попытке удаления бранча который не «замерджен» в текущий.
* также из моего опыта если в команде работают толковые люди то настолько тотальный контроль не обязателен. у нас любой может «мерджить» в master
* под gitosis обычно используют юзер git а не gituser :)
* также предложенный порядок ведения бранчей отличается от «канонического» с точностью до наоборот :)
по идее «master» (или trunk) это место куда сливают всё самое последнее (и куда все могут мерджить),
а как раз для стабилизации используют staging и production бранчи.
мне по роду работы прихотидся время от времени интегрировать разные API.
SOAP он очень хорош для сферического проекта в вакууме :)
В реальной работе я предпочитаю REST.
Несколько причин:
* если SOAP работает то всё хорошо. А если нет – лучше застрелиться.
* REST достаточно прост концептуально что бы его можно было понять и собрать «на коленке».
* SOAP — приходится пользоваться код–генераторами. Что при изменении версии протокола визывает реальный гемор т.к. оригиналный сгенеренный код уже давно «причесали» и т.д.
* к REST API можно очень легко «достучаться» из javascript-а.
* Мне страшно даже подуматъ как дебаггить javascript SOAP через firebug :)
* Каждый производитель мыльной либы делает чтото слегка по своему, плюс разница версий так что часто получается несовместимость между генераторами с обоих сторон, приходится в ручную с напильником…
это толко то что сразу пришло мне в голову. причинам мылной мозговой болезни нет конца.
GET, HEAD, PUT, DELETE — Идемпотентныe методы. т.е. повторное их выполнение не должно визывать изменений состояния ресурса. Сколко ресурсу не говори «PUT тебя зовут вася» – один, два или десять раз – резултат один :)
POST — повторный вызов может привести к нежелательным резултатам (например создать несколко новых ресурсов).
большенство 'нормальных' прог так и делают. так что сломав сайт невозможно запустить в оборот 'левую' версию.
Очень даже имеет смысл. меняем JS и перехватываем все мастер пароли у всех кто заходит. онлайн менеджер для паролей – ОЧЕНЬ плохая идея.
Он совсем не имел в виду что ваша инфа должна быть доступна всем.
Как раз наоборот. И Гугл охраняет её очень не плохо.
Но.
Есть законы. И естъ судебные повестки. И в **некоторых** случаях Гуглу просто придётся поделиться инфой с органами.
А что он имел в виду это: «Если вы занимаетесь чем то таким что вы **очень** боитесь что кто нибудь узнает (даже если для етого надо идти в суд) то, возможно вам действительно не стоит делать этого в онлайне (или даже вообще не стоит :).
Например собираясь прибитъ тёщу не стоит гуглить „куда спрятать труп“ :)
* «git branch -D» исползуется толко в исключительных случаях т.к. он позволяет потерять данные. в 99% случаев лучше использовать «git branch -d» — ета команда вернёт ошибкы при попытке удаления бранча который не «замерджен» в текущий.
* также из моего опыта если в команде работают толковые люди то настолько тотальный контроль не обязателен. у нас любой может «мерджить» в master
* под gitosis обычно используют юзер git а не gituser :)
* также предложенный порядок ведения бранчей отличается от «канонического» с точностью до наоборот :)
по идее «master» (или trunk) это место куда сливают всё самое последнее (и куда все могут мерджить),
а как раз для стабилизации используют staging и production бранчи.
SOAP он очень хорош для сферического проекта в вакууме :)
В реальной работе я предпочитаю REST.
Несколько причин:
* если SOAP работает то всё хорошо. А если нет – лучше застрелиться.
* REST достаточно прост концептуально что бы его можно было понять и собрать «на коленке».
* SOAP — приходится пользоваться код–генераторами. Что при изменении версии протокола визывает реальный гемор т.к. оригиналный сгенеренный код уже давно «причесали» и т.д.
* к REST API можно очень легко «достучаться» из javascript-а.
* Мне страшно даже подуматъ как дебаггить javascript SOAP через firebug :)
* Каждый производитель мыльной либы делает чтото слегка по своему, плюс разница версий так что часто получается несовместимость между генераторами с обоих сторон, приходится в ручную с напильником…
это толко то что сразу пришло мне в голову. причинам мылной мозговой болезни нет конца.
По определению HTTP (пример смотреть на www.w3.org/Protocols/rfc2616/rfc2616-sec9.html):
GET, HEAD, PUT, DELETE — Идемпотентныe методы. т.е. повторное их выполнение не должно визывать изменений состояния ресурса. Сколко ресурсу не говори «PUT тебя зовут вася» – один, два или десять раз – резултат один :)
POST — повторный вызов может привести к нежелательным резултатам (например создать несколко новых ресурсов).