首页   注册   登录
 Philippa 最近的时间轴更新

Philippa

  •   V2EX 第 277176 号会员,加入于 2017-12-27 02:44:05 +08:00
    Philippa 最近回复了
    9 天前
    回复了 Philippa 创建的主题 设计 学习设计的几点疑问和路线图咨询
    @shimomiaizo 我今晚看设计时
    时看到
    。Flutter,我不知道对于设计来说难不难,但我用了不到 1 个小时就写完了整个 demo 并运行在自己的 Android 手机上(我从未写过移动 app,毫无概念可言,只有后端基础) : https://flutter.io/get-started/codelab/,移动端实际上体积更少,设计更多的 UX 设计,并且 Flutter 直接运行在 web/ios/android,我觉得你会感兴趣。相比于 swift/java 这些开发适合于个人项目(但这个很新,而且普遍做空这个框架,假如你要往前端发展还是学 Vue/React/Ng 之类吧,但单纯说个人项目,我觉得很好很好,相对于混乱的前端生态圈和学习成本)。
    @n3hatv2 #9 我觉得你现在的方法很好了,那样做就完全不用考虑原先的问题了,walk round 同时也是一种风格更好的 design。Queue 模块放在 multiprocessing 虽然没问题但共享 Queue 比较麻烦,所以 Redis 更方便,就是多了个 Redis 依赖。

    1.不会
    2.是的,假如 session 是同一个,就会覆盖掉了。因为 Model.attr = 'xxx'时相当于塞进了预备被提交的 box 里面,commit 就全部提交了。假如相同 id,应该是原有 box 已有内容被覆盖了一遍(我猜,源码我就不看了= =)。
    性能还好,我对比过 peewee 和 sqlalchemy 的性能都差不多。如果不存在锁或其他等待,速度一般卡在大批量数据插入时比较慢,sqlalchemy 有个 bulk_insert 的方法,不过大量时间会花在构建对象或 append 插入数据里面。但具体执行插入到插入完成这个阶段,到底是数据库是瓶颈,还是网络,还是对象的构建销毁比较耗资源,就没测过了。
    @n3hatv2 pool 子进程没用过耶,pool 线程池就用过,还是 subprocessing ? executor ?所以我猜你有两个担心的地方,一是 multiprocessing 这块可能共享,二是 threading 这边可能会共享。前者我一般用一个 docker 一个 process 所以不熟悉,不过据搜索结果看 multiproccessing.array 专门用于共享内存的,并用 actor 模型处理消息,所以我理解是不会共享的,所以这里我们是一样的,不用管。至于 threading 嘛,是会的,我也很常用 threading_pool.map 然后通道来传消息,还能共享变量。假如你的 Model 绑定了 session,在使用 Model 时,session 在 commit 的时候会把所有都包含进来……所以每个线程应该单独使用 session 来完成。比如这样:

    ```
    # 用调用函数的方式加括号(),一种明确的信号来建立连接
    with session_scope() as session:
    do_something()
    ```
    不过我觉得更好的方法是用 Queue (线程安全的),集中处理所有的存储步骤。pool.map(worker_lambda, args)来执行任务,在 def worker_lambda 里面处理好后结果 push 到 Queue 里面:queue.push(result),然后做一个 while True 的消费者,从 queue 取出结果,然后 session.add(result)来保存结果,result 包含多个结果,单独塞 X, Y, Z 变量也可以,但是多线程下顺序有可能会乱,所以有多个结果就一起塞。设置 timeout/retry/queue.empty 作为超时 /重试 /中止信号。这样就不用担心这种问题了,虽然每个自己处理也可以,但是我觉得那样会增加许多脑资源消耗,而且更容易出错和更难维护,其他人接手修改也容易出现 bug。不然你可以用协程,最后看看数据库的锁默认设置。最后最好避免全局变量这种东西,以后会搞坏自己。

    flask-sqlalchemy 那个我不大记得,我记得是最后 db.session.commit()就提交了,或者有的人直接 auto_commit。这在多线程里面的确会有问题。如有错,请指出。
    @n3hatv2 #2 Yeah~我还没遇到过进程不安全的问题!那我想请教一下大概原理,或有链接分享一下吗?是多进程,多线程还是协程下不安全,竞态?还是别的原因?我现在有很多和别人一起写的用到 flask-sqlalchemy 项目是在 docker 集群上跑的,web 服务层有的也用到,新的才是纯 sqlalchemy,想了解一下。
    这里没有写清楚是 flask-sqlalchemy 还是 sqlalchemy。flask-sqlalchemy 的文档写的是 Model.query,它会返回一个 BaseQuery 的类,继承 sqlalchemy 的 Query 类,实现了一些额外的东西,比如 paginate 的方法。但看看上面方法 2 就知道,Model 和 session 一点关系都没有,这是因为在 app 里面封装了,不然 session.commit()怎么会知道上面那个 Model 做了什么。这也造成,当你只想使用 sqlalchemy 而不是 flask app 时,你会发现用不了,因为没有共享上下文,因此在调试和写测试时耦合度会比较高,那些喜欢自己写代码而不是学习一整套方案的人就不喜欢 flask-sqlalchemy 的,比如我。同时从代码看,sqlalchemy 的方案更加直接,session 可以简单理解成用于建立连接,session 传参去 query 模型,最后还要 add 一下加入事务,commit 提交,虽然代码多一点,但逻辑很清洗。而 class 只是映射 sql 逻辑成一个面向对象的 object,通过操作 object 来操作 sql。

    session 是抽象出来的概念,实质关键是用来处理链接问题。建议用 sqlalcehmy 而不是 flask-sqlalchemy,因为解耦方便,组件化复用也可行,而不是跟 flask 耦合在一起。sqlalchemy 可以用 session_scope,create_engine 自己写个连接方法来处理,虽然入手肯定是没 flask-sqlalchemy 那么方便,但也是一次编写多几行代码,终身使用了。另外 peewee 是没有处理这个问题的,看起来更简单但不懂用埋了坑。peewee 和 flask-sqlalchemy 一样,也是 Model.select 这种形式的,但没有自动关闭连接。因此,对于长期运行的任务,队列等,某些数据库由于太长时间接受到请求就会直接中断,因此 peewee 在这种情况会出现 client 报错的原因,因为 timeout 了。peewee 的 issues 的官方给出解决方案竟然是 conn.close()这种东西,这在涉及 import/复杂业务容易出现单个 instance 里过早关闭的问题,感觉就像一不小心就变野指针,是个 bad design。
    11 天前
    回复了 Philippa 创建的主题 设计 学习设计的几点疑问和路线图咨询
    @shimomiaizo #25 原来如此,的确想想我们的整体设计水平是在人家之下。定居那个不重要,其实我怕定居这种玩意,我只想出去找一下工作机会,如果有的话,我是单纯喜欢到处跑接触不同东西的。虽说我现在做后端这一块,现在已经是我第二个领域了。不过哪怕还年轻,不过去念书拿学位代价的确太高了,考虑到放弃目前工作腾空几年,将丧失目前职位这几年可能是最快的发展阶段,可能念完了设计从 0 开始,而在现在的领域也归 0 了。

    我所在公司里面的设计屈指可数。不过我一般是把大部分产品当傻子看,哈哈……那些名牌大学硕士毕业出来做产品,画个流程图都乱七八糟,组织能力也不行,逻辑也不慎密,尤其在 IT 公司,在尝试结合科技和产品两个方面时,听那些负责产品的说话会感到非常尴尬,因为他们并不懂得技术,设计上缺乏实际得表达能力(出稿原型图,交互方面得组织),只有一张嘴,所以实际一个项目流程十分颠簸。而项目经理则通常是一个经验丰富,技术和管理都出色的人担任,所以通常出篓子都是设计,产品那边上游出问题。具体设计给我的印象是,非常忙,感觉就是很惨,通常做技术的 6 点多的就下班走人了,而设计还在不停地做。不过设计往前端发展其实也是条路,前端 + 设计 + 产品其实是一条路。而后端这边一般所谓全栈则是后端 + 前端,不过经验上觉得,设计 + 产品 配 前端 + 后端是最节省沟通成本的。
    snapshot 技术不会耗费很多硬盘,第一次完整备份之后它只会保存增量部分。但秒级备份用的不是 snapshot,它用的是日志,通过还原点 + 日志方式恢复。参考数据库。这种技术存在很久了。如有错请指出。
    14 天前
    回复了 Philippa 创建的主题 设计 学习设计的几点疑问和路线图咨询
    @parkcg 学 AI 是个人兴趣还是工作?工作尽快找家第一梯队公司进入,现在已经开始落地了。设计嘛,你也看到,虽然看起来一片惨淡,但 AI 算法和工程两个层面裂缝很大,现在行业还没到弥补这个裂缝的时候,目前几乎每个客户都需要大量人力物力支撑才可以发挥出 AI 的威力。相比之下设计所见即所得。
    14 天前
    回复了 Philippa 创建的主题 设计 学习设计的几点疑问和路线图咨询
    @IvanID 谢谢分享,这够详细的。我身边也见过一些前端 X 设计的,也经常和产品打交道。我在想设计师往产品和前端扩展应该是很不错的方向,每次看到产品、设计和前端在各自指点江山经常搞得一团糟。产品不懂设计,拿 axure 画个丑陋的设计稿出来,然后告诉设计,你把它转换成设计吧。设计画好稿后,经常不是完整的图,而是不同组件都画一个,然后前端做出来后,产品说不是这种感觉,或者说还要让后端写个程序跑起来先看看。而且交互方案一般由产品出,然而实际上很多产品缺乏文档能力,也缺乏设计能力,结果出来效果很笨拙。那些懂设计能用工具快速表达自己观念,并且画出交互设计图的产品根本不会存在这种问题。哪怕那个产品沟通能力比较好,也常常会如此。
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   鸣谢   ·   1481 人在线   最高记录 3541   ·  
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.1 · 15ms · UTC 00:17 · PVG 08:17 · LAX 17:17 · JFK 20:17
    ♥ Do have faith in what you're doing.
    沪ICP备16043287号-1