如果是普通的flask页面profile建议使用WSGI Application Profiler
它会自动分析每一个页面，并profile，内部也是cprofile实现。
针对初始化过程只能手动使用cProfile：
python -m cProfile -o profiling run_web.py
等到初始化完毕再进入python ide：
>>> import pstats
>>> stats = pstats.Stats(‘profiling’)
>>> stats.sort_stats(‘time’).print_stats(10)
这个如果是在debug模式下出现一般是跟reloader特性有关系，WERKZEUG提供的这个特性主要是方便实时监测到开发中修改的文件，比重启app要快很多。但是有的时候我们希望app或者部分代码指启动一遍，可以用下面的环境变量来监测是否是第二次reload中的初始化。
if not app.debug or os.environ.get(“WERKZEUG_RUN_MAIN”) == “true”
组件初始化我们也希望初始化一遍，flask对此有一个专门的事件：
@app.before_first_request
def initialize():
print “Called only once, when the first request comes in”
docker-compose的启动会默认创建一个bridge类型的网络，当然它跟默认的bridge是继承关系。最近升级ide和docker后发现服务之间出现了个现象，服务能ping的通但是别名就不可以。而更改的地方就是网络模式network_mode 设置为了bridge。
原来当使用default bridge network的情况下，docker container使用宿主机的resolv.conf，当然不会解析服务名了。从1.10开始docker对自建的网络默认启用embedded dns，这个dns会自动更新新分配的服务。
docker network create mynet //不指定网络模式时默认是bridge
用mynet替换原先的bridge即可。如果在一个网络内可以用服务名来访问比如ping service_name，如果不是可以通过ping service_name.devnet
docker通常修改 -v /etc/localtime：/etc/localtime就可以修改系统时间，但是mysql日志输出时间还是没变，因为它的时间默认是UTC时间，修改需要更改mysql的配置。增加启动参数：–log_timestamps=SYSTEM
完整示例：
docker run -e MYSQL_ROOT_PASSWORD=root -v /etc/localtime:/etc/localtime:ro -d mysql:5.7 –log_timestamps=SYSTEM
wordpress的升级非常方便，就是不适合国情，之前多试几次总会成功的，最近老是失败，删除了几次lock后发飙了。
对了如果没有安装SSH SFTP Updater Support的话，请先装好他，wp原生的太弱，还不加密，咱升级的重要原因不就是因为漏洞太多么，还没侵入性，因为ssh肯定有啊。win OS请走开，xx空间请走开。
然后就是主角WP-CLI了，这个东西太好了，有了它就算上面的升级失败也有终极方法了，命令行终究是万能的，甩UI几条街。安装请移步：WP-CLI
wp plugin install 插件名
wp core update #wordpress升级wp language core update #wordpress语言包升级
奇怪的就是这种升级非常快，如果下载慢重来一次，如果实在下载不了可以拷贝下载链接用迅雷下载后直接安装。wp plugin update --all #wordpress 插件升级wp media regenerate --yes #重新生成wordpress多媒体文件wp theme update --all #更新所有皮肤文件
#带–allow-root
wp core update --allow-root
wp language core update --allow-root
wp language plugin --all update --allow-root
wp language theme update --all --allow-root
wp plugin update --all --allow-root #wordpress 插件升级
wp media regenerate --yes --allow-root #重新生成wordpress多媒体文件
wp theme update --all --allow-root #更新所有皮肤文件 PHP7安装mcrypt失败。
最近更新docker镜像发现这个问题，搜索半天居然没有解决，原来从7.1开始mcrypt就被放弃了。因为它的依赖10年前就停止更新了。好吧放弃需要他的组件即可。
此攻略完全原创，没看过他人的攻略，全凭自己的推测和经验。精力有限玩了大概二十局不到一般都进前十,照着攻略走前十没问题，越靠前的规则越重要。前十的攻略较为重要，前五要养成习惯。十条以后就是经验了。
ffmpeg太出名了，linux上只要跟多媒体有关的多多少少都会有它的身影。最近需要用到它读取多媒体metadata，使用的库说找不到ffmpeg，apt也装不了会报错误。原来debian7开始ffmpeg被libav取代，这个东西也是从ffmpeg fork出来的，到了debian9又回到了ffmpeg，不过奇怪的是我换了stretch还是无法安装ffmpeg。老版本如果要装ffmpeg可以加入backports源，例如jessie源可以加入如下：
deb http://mirrors.163.com/debian/ jessie-backports main non-free contrib deb-src http://mirrors.163.com/debian/ jessie-backports main non-free contrib
在HTTPS站点ajax请求的地址如果不是https那么就有ERR_SSL_PROTOCOL_ERROR错误了。
解决办法：当然是把http改为https即可
阿里云一贯loss文档的尿性，确实找不到相应的说明，甚至找到对应sdk的项目地址都难，这里贴上oss js sdk的地址，看去是淘宝ued出品：https://github.com/aliyun-UED/aliyun-sdk-js
找到后发现有n多可配置项，这里需要加secure:true 到oss对象初始化的options即可，默认是false所以请求的是http。
最后重要的事说三遍：鄙视👎阿里云、鄙视👎阿里云、鄙视👎阿里云
用flask的肯定知道url_for,解放了记住url的繁琐。前阵子因为flask臭名昭著的 servername问题彻底拆分了应用程序，在解决了大部分引用和重用后发现应用间导航也是个问题，写硬url显然不科学。这里祭出几大法宝用来解决这个问题：
贴一下我在用的Dispatcher
class Dispatcher:
"""
Allows one to mount middlewares or applications in a WSGI application.
This is useful if you want to combine multiple WSGI applications::
app = DispatcherMiddleware(app, {
'/app2': app2,
'/app3': app3
})
"""
def __init__(self, app, mounts=None):
self.app = app
self.mounts = mounts or {}
self.url_for_resolver = URLForResolver(
self.mounts
)
self.app.dispatcher = self
def __call__(self, environ, start_response):
script = environ.get('PATH_INFO', '')
path_info = ''
while '/' in script:
if script in self.mounts:
app = self.mounts[script]
break
script, last_item = script.rsplit('/', 1)
path_info = '/%s%s' % (last_item, path_info)
else:
app = self.mounts.get(script, self.app)
original_script_name = environ.get('SCRIPT_NAME', '')
environ['SCRIPT_NAME'] = original_script_name + script
# Convert empty path info values to a forward slash '/'
environ['PATH_INFO'] = path_info or '/'
return app(environ, start_response)
class URLForResolver:
"""
A URL resolver that provides resolution of `url_for` across multiple apps.
"""
def __init__(self, mounts):
self.mounts=mounts
self.apps = list(mounts.values())
self.cache = {}
for app in self.apps:
app.url_build_error_handlers.append(self)
def __call__(self, endpoint, **values):
"""Attempt to resolve a URL any of the registered apps"""
error = Exception('can not find endpoint for %s' % endpoint)
parts=endpoint.split('.')
path=parts.pop()
if len(parts)>1:
path='%s.%s'%(parts[1],path)
app_name=None
if len(parts)>0:
app_name=parts[0]
# Check if we have a cached look up
if endpoint in self.cache:
app = self.cache[endpoint]
if app:
with app.app_context(), app.test_request_context():
ret_path= url_for(path, **values)
if ':5000' in ret_path:
ret_path=ret_path.replace(':5000','')
return ret_path
else:
raise error
if app_name:
app = self.mounts[app_name]
self.cache[endpoint] = app
return self(endpoint, **values)
# Attempt to find an app with the registered endpoint
for app in self.apps:
for rule in app.url_map.iter_rules():
if rule.endpoint == path:
# Found - cache the result and call self to return the URL
self.cache[endpoint] = app
return self(endpoint, **values)
# Not found - cache the result and re-raise the error
self.cache[endpoint] = None
raise error
使用方式：
#初始化
init_apps()
apps = create_apps()
del apps['/passport']
dispatcher = Dispatcher(passport, mounts=apps)
#调用
current_app.dispatcher.url_for_resolver('/appname.blueprint_name.page_name',_external=True))