flask, AJAX, jQuery

http://flask.pocoo.org/docs/0.10/patterns/jquery/
http://runnable.com/UiPhLHanceFYAAAP/how-to-perform-ajax-in-flask-for-python

Работаем с REST

Например, пишем своё апи и нужен некий стандарт, по которому будет взаимодействовать мир и наш апи. Раньше для этого использовали чистый XML и SOAP, сейчас всё более популярным становится rest-подход.
REST=REpresentational State Transfer
http://en.wikipedia.org/wiki/Representational_state_transfer

Много вопросов может вызывать, что передавать в заголовках, что в теле запроса.

Также нет чёткого разделения между PUT и POST, оба метода могут как добавлять записи, так и менять их. Тут совет такой: POST всегда добавляет запись, PUT добавляет если такой не было и меняет, если была. Это позволяет заново послать запрос, если нет уверенности в первом получении сервером, и это не должно вызывать дублей и ошибок.

http://stackoverflow.com/questions/630453/put-vs-post-in-rest

http://restcookbook.com/HTTP%20Methods/put-vs-post/

Есть неплохое введение у Рея
Designing a RESTful API with Python and Flask
Writing a Javascript REST client
Designing a RESTful API using Flask-RESTful
Implementing a RESTful Web API with Python & Flask

Архитектура REST

Тут много интересного, в том числе замена POST-ом операций PUT и DELETE

Передавать данные имеет смысл в JSON
https://ru.wikipedia.org/wiki/JSON

Для работы rest_flask может быть еще полезно
библиотека flask-restful
http://www.slideshare.net/nicolaiarocci/developing-restful-web-apis-with-python-flask-and-mongodb
http://blog.luisrei.com/articles/flaskrest.html

Линки
http://www.infoq.com/articles/webber-rest-workflow
http://anton.shevchuk.name/php/create-restful-api/
QIWI и новый протокол REST в примерах

http://www.predic8.com/rest-webservices.htm

http://www.restapitutorial.com/lessons/whatisrest.html

http://www.restapitutorial.com/lessons/restfulresourcenaming.html

Разбираемся с OAuth2

http://tools.ietf.org/html/draft-ietf-oauth-v2
https://ru.wikipedia.org/wiki/OAuth

OAuth 2.0 — протокол авторизации, позволяющий выдать одному сервису (приложению) права на доступ к ресурсам пользователя на другом сервисе. Протокол избавляет от необходимости доверять приложению логин и пароль, а также позволяет выдавать ограниченный набор прав, а не все сразу.
OAuth 2.0 простым и понятным языком

OAuth: описание протокола простым и понятным языком

О недостатках
http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/


И еще линки
http://api.yandex.ru/oauth/doc/dg/reference/web-client.xml
http://api.yandex.ru/oauth/doc/dg/reference/obtain-access-token.xml#POST

webpy: ещё один лёгкий веб-фреймворк

Хотя flask оказался удобнее, он и webpy очень похожи, может кому-то понравится больше.

Начинать отсюда:
http://webpy.org/tutorial3
и далее по сайту, например
http://webpy.org/docs/0.3/templetor

делаем restful
http://johnpaulett.com/2008/09/20/getting-restful-with-webpy/

формы
http://runnable.com/Uple-VHLs9IKAACS/working-with-forms-in-web-py-for-python-and-webpy

python for windows

Если вдруг возникла нужда разрабатывать под windows, есть очень хорошая IDE PyCharm

Из вкусностей: нормальная подсветка, автодополнение, справка по параметрам с описаниями итд. Штатный IDLE и рядом не валялся.

Плюс уже встроенная поддержка virtualenv, в scripts лежит pip.exe.

Питон ставится отдельно, например отсюда

Линки

http://www.tylerbutler.com/2012/05/how-to-install-python-pip-and-virtualenv-on-windows-with-powershell/

http://www.jetbrains.com/pycharm/webhelp/creating-virtual-environment.html

python: работаем с Couchbase

Неплохая дока на сайте

http://docs.couchbase.com/couchbase-sdk-python-1.2/#hello-couchbase

И чуть ниже есть примеры работы с базой через flask, попутно объясняя как с ним работать. Впрочем, для начала лучше изучить серию документов на хабре + на офсайте:

http://dragonflybsd-scripts.blogspot.ru/2014/08/flask.html

знакомство с flask

Flask это микрофреймворк, и в отличии от того же django, не навязывает структуру. Фактически, представляет небольшую обёртку к:

• Шаблонизатор Jinja2
• Маршрутизатор Werkzeug
• itsdangerous - Various helpers to pass trusted data to untrusted environments and back
• markupsafe - Implements a XML/HTML/XHTML Markup safe string for Python

Обычно используется в связке с SQLAlchemy+WTForms. Для запуска в бой - часто используется с nginx+Gunicorn

Часть 1: Привет, Мир!
Часть 2: Шаблоны
Часть 3: Формы
Часть 4: База данных
Часть 5: Вход пользователей
Часть 6: Страница профиля и аватары
Часть 7: Unit-тестирование
Часть 8: Подписчики, контакты и друзья
Часть 9: Пагинация

Вообще частей 18, но переводится очень медленно (год уже).

Собственно, оригинал, полный:

• Part I: Hello, World!
• Part II: Templates
• Part III: Web Forms
• Part IV: Database
• Part V: User Logins
• Part VI: Profile Page And Avatars
• Part VII: Unit Testing
• Part VIII: Followers, Contacts And Friends
• Part IX: Pagination
• Part X: Full Text Search
• Part XI: Email Support
• Part XII: Facelift
• Part XIII: Dates and Times
• Part XIV: I18n, L10n
• Part XV: Ajax
• Part XVI: Debugging, Testing and Profiling
• Part XVII: Deployment on Linux (even on the Raspberry Pi!)
• Part XVIII: Deployment on the Heroku Cloud

Про структуру каталогов например тут:
Flask для больших проектов
или готовая основа
https://github.com/sean-/flask-skeleton

Большие проекты можно разбивать на блоки, для этого есть
http://flask.pocoo.org/docs/blueprints/ (на русском: http://vladimir-stupin.blogspot.ru/2013/05/flask-blueprint.html), пример https://github.com/xmm/flask-restful-example
http://pythonhosted.org/Flask-Classy/ 

ещё примерчик
https://www.digitalocean.com/community/tutorials/how-to-structure-large-flask-applications

Ещё очень полезные модули
flask-login

flask-wtf

python logging

import logging
logging.info('text')

Logging — библиотека для удобного ведения логов в Python
https://docs.python.org/2/howto/logging.html
https://docs.python.org/2/howto/logging-cookbook.html
http://plumberjack.blogspot.ru/2010/09/python-logging-functionality-facts-vs.html

python: json to xml

http://stackoverflow.com/questions/1019895/serialize-python-dictionary-to-xml
https://www.npmjs.org/package/json2xml

http://code.activestate.com/recipes/415983/
http://sourceforge.net/projects/pyxser/
http://soapy.sourceforge.net/
http://www.ibm.com/developerworks/webservices/library/ws-pyth5/
http://gnosis.cx/publish/programming/xml_matters_1.txt
 

dict2xml

 

 

переписывать ли приложения с нуля

http://habrahabr.ru/post/219651/
Действительно, переписывать с нуля зачастую неоправдано вообще никак, и в большинстве случаев нужен просто рефакторинг, иногда очень глубокий и сложный, а иногда действительно лучше переписать. Но надо понимать, что было в старом коде. Да, неизбежно появляются костыли, в том числе для совместимости, и чем дальше, тем будет больше кода "для совместимости", но удачные участки можно и из старого кода взять.
А чтобы не терять позиции, придётся тянуть 2 ветки -- старую и новую, то есть расходы сразу удваиваются. И быть готовым к тому, чтобы новую версию просто выкинуть, если вдруг стало понятно что "не взлетит". Просто забросить старую версию, пока пишется и отлаживается новая версия -- обычно значит, что компания(продукт) умрёт.

http://bash.im/quote/420672

khim,4 июня 2014 в 09:49#

↵

↑

Вы забыли один важный момент, а он, в общем-то критичен: да, вы бы получили что-то, что было бы, скорее всего, ничуть не лучше, чем Windows Phone 7, но при этом вы бы сохранили лояльных пользователей, нормальные отношения с OEM'ами и операторами.

Если бы для победы в войне операционок было бы достаточно технического совершенства, то всякие BB10 и webOS'ы были бы ещё с нами и были бы претендентами на победу. Про «битву эко-систем» в 2010м вопил не кто-нибудь, а бывший Microsoft'овец Элоп — а Microsoft как раз перед этим эту самую свою экосистему своими же руками задушил.

Не нравится Джоэл — посмотрите в другую сторону. «Великий и Ужасный» Стив Джобс в своё время славно потоптался по этим граблям при создании Apple III, Apple Lisa и Apple Macintosh. До такой степени, что в тот раз это чуть не привело к гибели Apple и его пришлось выпереть, чтобы хоть что-нибудь сохранить. В своё «второе пришествие» имея за плечами полный коммерческий провал технически очень качественной NeXTSTEP он уже этой ошибки не совершил: переход от MacOS Classic к MacOS X занял несколько лет, был придуман способ поставить на один раздел и MacOS 8/9 и MacOS X (причём в первый год MacOS 8/9 грузилась по умолчанию!), были разработаны способы запускать старый софт и в MacOS X — в общем было сделано всё, чтобы сохранить экосистему. И в это же время Microsoft, совершивший очень похожий переход на ядро Windows NT (разве что «две OS по цене одной» он не предлагал) решил не использовать свой собственный опыт, а вместо этого повторить ранние ошибки Джобса и выпустить себе в ноги два рожка из автомата. Ну как так можно-то?

http://habrahabr.ru/post/225061/

AllexIn,17 апреля 2014 в 20:54#

Переписывание «с нуля» — важная часть развития проекта.
Проект в процессе эволюции обрастает огромным количеством кода, который не лечит баги, а тупо обеспечивает обратную совместимость.
Код проектов поддерживающих обратную совместимость становятся очень страшным.
Я сам писал редактор 3Д сцен, который поддерживал 60 версий форматов файлов вплоть до самой первой. И это было оправданно. И мало поддерживать загрузку 60 версий. Еще надо поддерживать работу разных алгоритмов. Если первые сцены делали с учетом хабагованного алгоритма, то значит при работе с первыми версиями нужно чтобы алгоритм работал с теми же багами! Ведь нужно воспроизвести сцену так как ее создавали. А новые версии файлов нужно воспроизводить уже корректно.
И таким образом код превращается в страшную ересь.
И можно только переписать все заново, потому что корректно убрать все костыли практически невозможно.
И ладно просто страшный код. Его практически невозможно расширять так, чтобы ничего не сломать.
Поэтому редактор переписывается с нуля. Хотя это и не ноль. Ведь многие куски кода не содержат костылей и вполне могут корректно использоваться в новой версии. Загрузка текстур, например. Работа со звуком и т.п.
Плюс пишется отдельный конвертер, который 60 версий файлов конвертирует в новый формат с учетом всех нюансов.
Конвертер пишется один раз и поддержка его не нужна в будущем. Поэтому какие в нем костыли и код — совершенно не важно.
А новый редактор чистый и красивый. Да, через 5 лет он тоже превратится в монстра. Но эти 5 лет он будет развиваться, потому что ему больше не мешают костыли.
А через 5 лет — новая итерация. Еще один конвертер старых файлов…
Конечно, надо останавливаться себя от переписывания, когда это не актуально. Но часто это более чем актуально.

Alik_Kirillovich,17 апреля 2014 в 23:40#

Считаю нужным добавить, что два года спустя Джоэл все-же признал, что переписывание кода с нуля в некоторых случаях бывает оправдано:

… Наконец, с .NET поставляются замечательные библиотеки классов. Было переработано все — от доступа к данным и веб-разработки до GUI, поэтому создалось редкостное единообразие, сверху до низу. <...> Да, я согласен: .NET нарушает закон «никогда не переписывай с чистого листа». Microsoft это сошло с рук по двум причинам. Во-первых, у них был лучший в мире конструктор языков, человек, которому имы обязаны 90% прироста эффективности разработки программ за последние 20 лет, Андерс Гейльзберг, давший нам Turbo Pascal (спасибо!), Delphi (спасибо!), WFC (отлично!) и теперь .NET (сногсшибательно). ВО-вторых, они посадили за эту работу тьму инженеров на целых три года, в какой-то мере ослабив на это время свое участие в конкурентной борьбе. Запомните: если Microsoft может что-то себе позволить, это не значит, что то же самое можете вы.

Джоэл Спольски. Джоэл о программировании, 2006. Глава 44. Наша стратегия .NET. Стр. 321-322.

Оригинал: Joel Spolsky. Our .NET Strategy, 11 April 2002.

Вы мне Javascript сломали 
О стартапе-ловушке