Думаю, стоит подписаться на RSS всех python-проектов, которые сможете найти. Я бы не отказался наблюдать новости проекта Eve, например.
И, конечно, стоит следить за твиттером.
«Энциклопедия» вышла в свет годом позже, так что это она расширенная, а не «город» урезанный. Я на неё в библиотеке наткнулся спустя пару лет после знакомства с «компьютерным городом» — хороша, конечно, только ностальгии уже не вызывает.
Когда мне было четыре года, отец продемонстрировал простенький исходник на бейсике, который потом запустил. Я копипастнул этот код в тетрадочку и с тетрадочки обратно. Заработало: программа рисовала на чёрном экране белые кружочки внахлёст. Формально, мой опыт программирования приближается к 20 годам :)
Чуть позже он научил меня азам пайки. Всё детство я хотел стать схемотехником, но к 15 годам окончательно перешел на тёмную сторону.
Сейчас компьютеры повсюду, и сами по себе интерес у ребёнка вряд ли вызовут — нужно показывать что-то редкое. Не обязательно хайтек (хотя Augmented Reality, думаю, хорошо подходит), просто что-то, чего он прежде не видел вблизи.
И больше качественной научной фантастики. «Приключения Алисы» Кира Булычёва — когда появятся дети, обязательно соберу всю коллекцию, первыми книгами которой зачитывался сам. Хотя, по слухам, за 40 лет работы над серией, автор планку приспустил.
Потом как-нибудь ненавязчиво подсуну ребёнку что-нибудь из Стругацких. Совсем ненавязчиво. Если бы отец так активно мне не впаривал «Трудно быть богом» — я бы гораздо раньше приобщился к их творчеству.
Статистика подсчитывается и хранится в отдельных таблицах, из которых удобно потом делать выборки.
Интересно, какие данные хранятся в этих сводных таблицах, какую аналитическую ценность они представляют и каким образом обновляются (на лету или периодически).
Я читал где то, что если Вы делаете POST и передаете
параметр action это почти всегда плохо.
Речь о параметре в URI, или вообще в запросе?
И в целом
уже несколько лет такое правило мне здорово помогает.
Помогает чем?
Лучше делать POST /api.cfm/archive и в теле запроса message=8
В случае с добавлением в архив это может быть уместно, но что делать если нужно просто произвести манипуляцию над документом? Например, конвертировать все изображения документа в формат png, указав при этом необходимые характеристики конечного изображения.
В ответ сервер возвращает ID транзакции по которому можно
опрашивать состояние операции.
Такой подход актуален для операций, которые могут затянуться по времени. Для быстрых операций, на мой взгляд, это избыточное решение.
Не уверен, что совсем понял вопрос, но:
есть python-фреймворки flask и bottle — каждый из них позволяет повесить на один маршрут обработчики для разных http-методов: bottle с помощью декораторов, flask — c помощью декораторов, либо с помощью отдельных методов объекта, представляющего ресурс.
Ну а работа с http-заголовками и аргументами запроса не представляет труда во многих популярных фреймворках.
Я погорячился, сказав слово «подразумевает» — как справедливо заметил marapper: REST — это принцип построения архитектуры, строгой спецификации не существует. Зато существует куча руководств в стиле best practices — сегодня только ленивый (вроде меня) не написал собственный гайд по «правильному» REST.
Наверное, у меня не совсем верное представление о понятии «RESTful» — я думаю, что это просто набор лучших практик реализации REST-архитектуры, и в первую очередь — использование по полной возможностей протокола HTTP.
На самом деле, я считаю, что указывать действие стоит вообще в http-заголовках, а не параметрах URI — но уж лучше в параметрах, чем в пути.
Но, если над сущностью можно сделать больше операций, чем обычно, то куда логичнее это сделать отдельным ресурсом, т.к. смешение в POST редактирования и, например, привязки другой сущности — странно.
Вы не хотите смешивать в одном методе привязку сущности и редактирование, а я не хочу смешивать в ресурсе сущность и действия. Метод POST просто подразумевает отправку данных, ничего более, на то он и метод. Кто-то вообще отождествляет метод POST с созданием сущности — не думаю, что это правильно. А для привязки сущности есть http-метод LINK :)
И, конечно, стоит следить за твиттером.
Чуть позже он научил меня азам пайки. Всё детство я хотел стать схемотехником, но к 15 годам окончательно перешел на тёмную сторону.
Сейчас компьютеры повсюду, и сами по себе интерес у ребёнка вряд ли вызовут — нужно показывать что-то редкое. Не обязательно хайтек (хотя Augmented Reality, думаю, хорошо подходит), просто что-то, чего он прежде не видел вблизи.
И больше качественной научной фантастики. «Приключения Алисы» Кира Булычёва — когда появятся дети, обязательно соберу всю коллекцию, первыми книгами которой зачитывался сам. Хотя, по слухам, за 40 лет работы над серией, автор планку приспустил.
Потом как-нибудь ненавязчиво подсуну ребёнку что-нибудь из Стругацких. Совсем ненавязчиво. Если бы отец так активно мне не впаривал «Трудно быть богом» — я бы гораздо раньше приобщился к их творчеству.
И подавать пример до конца собственных дней.
Кстати, было бы неплохо добавить в статью ссылки на страницу проекта, api и примеры.
Было бы славно услышать историю разработки, которая подводит к озвученным в статье выводам, с некоторыми из которых я пока не могу согласиться.
В любом случае, если дело дошло до выполнения php-кода злоумышленником, эффективность запрета отдельных функций вызывает у меня сомнения.
eval— конструкция языка, а не функция, заблокировать её с помощьюdisable_functionsне получится, нужно использовать suhosin.Спасибо за информацию для размышления.
Помогает чем?
В случае с добавлением в архив это может быть уместно, но что делать если нужно просто произвести манипуляцию над документом? Например, конвертировать все изображения документа в формат png, указав при этом необходимые характеристики конечного изображения.
Такой подход актуален для операций, которые могут затянуться по времени. Для быстрых операций, на мой взгляд, это избыточное решение.
есть python-фреймворки flask и bottle — каждый из них позволяет повесить на один маршрут обработчики для разных http-методов: bottle с помощью декораторов, flask — c помощью декораторов, либо с помощью отдельных методов объекта, представляющего ресурс.
Ну а работа с http-заголовками и аргументами запроса не представляет труда во многих популярных фреймворках.
Мне по душе пришлись ресурсы restapitutorial.com (и их RESTful Best Practices), и Thoughts on RESTful API Design.
Как указывать действие в запросе — руководства оставляют решение этого вопроса на плечах разработчика.
На самом деле, я считаю, что указывать действие стоит вообще в http-заголовках, а не параметрах URI — но уж лучше в параметрах, чем в пути.
Вы не хотите смешивать в одном методе привязку сущности и редактирование, а я не хочу смешивать в ресурсе сущность и действия. Метод POST просто подразумевает отправку данных, ничего более, на то он и метод. Кто-то вообще отождествляет метод POST с созданием сущности — не думаю, что это правильно. А для привязки сущности есть http-метод LINK :)