社区功能

今天我有一个idea,我想记录下来,以免忘记了 一个博客平台,一开始注册的时候,每个用户都获得一颗种子, 随着发表的文章多起来,这个种族发芽,生长, 成为大树 成为大树后,可以获得更多的种子, 直到用户拥有一片森林 每一课大树,都对应现实中的一棵树,这棵树的所有权是用户,将来这树上结的果子,可以邮寄给用户,用户体会到自己的收获和喜悦 该博客平台,需要兼顾全部优点: 用户主题自定义, 开发者提供主题,可以出售, 优秀强大的编辑功能 没有广告 博客发布需要审核, 审核可以交给社区的义工来完成,类似于b站的纪律检查员,有奖励 为了要把这个博客平台发展成为一个社区, 拥抱社区,崇尚开源, 一定阶段,甚至不应该限制在一种领域博客, 甚至可以发布连载小说 社区化平台化是一种趋势, 来源： CSDN 作者： 佐月儿 链接： https://blog.csdn.net/CSDN_zuoyueer/article/details/103569516

以下文章来源于：阿翘AKIU ，作者：阿翘在这里。 最近在给一些应届生讲产品经理基础课，不少人都问我，为什么从来不给他们讲 产品经理工具 怎么用。这些难道不是产品经理的基本功吗？ 突然意识到很多同学陷入一个误区，就是把产品经理当成传统行业的岗位一样，把工具学会了就能上岗工作了。实际上工具只是表达思维的方式，比起产品技能更重要的是产品能力。 我始终认为，产品经理最基本的能力只有两个，一个是解决问题的能力，另一个是感知用户的能力。解决问题的能力很好理解，但什么是感知用户的能力呢？ 01 01.“感知用户”与“我是用户”的区别 先聊一件很有趣的事情。最近看到有很多人在做校园类产品。他们做校园产品的思路很简单，因为以前大家都在校园里待过，都知道学生时代的那些痛点，找几个场景把产品做出来，再找一些学生来内测一番就准没有问题。 同样的情况还有做各种兴趣社区以及同类人群社区的，几个养狗的互联网人突然做了一个宠物社区，几个喜欢医美的同事找到一个切入点就辞职创业做了个医美社区，他们的逻辑大多都是：因为我就是这样的人，所以我知道这群人有什么痛点。 并非在批判这种做产品的方式不好，只是这种方式很容易做出一款“想当然”的产品。 产品经理与创业者在想问题的时候经常犯的一个错误就是把自己当用户，用自己特定的情感或经历代替了大部分的用户。 某高校欲开发一款与校园图书馆互联的app，方便学生使用图书馆

我们为Tungsten Fabric将在中国安“新家”——Tungsten Fabric中文社区，欢迎对Tungsten Fabric社区、多云互联、SDN、SD－WAN有兴趣的伙伴关注社区，与我们共同建设社区，解决云网络建设过程中遇到的技术问题。 或许你第一次接触Tungsten Fabric，或许你对中文社区还心存疑虑，希望下面的问答能够帮到你。 1，Tungsten Fabric是什么？ Tungsten Fabric曾用名OpenContrail，最初是由Juniper开源的一个可扩展的多云网络平台，拥有一个充满活力的开发者和最终用户社区。2018年3月完成向Linux基金会的迁移，并且正式更名为Tungsten Fabric。 2，为什么我们需要Tungsten Fabric？ SDN是动态和智能网络路线图中的关键技术，无论是数据中心内部，还是数据中心之间，包括延伸到多个云环境以及跨广域（SD-WAN）的分支机构都会需要。SDN和NFV技术的出现，为建立一个对最终用户具有预期需求的网络，以及对服务提供商或企业的动态和集中控制奠定了基础。Tungsten Fabric为不同类型的数据中心或多云环境的部署，提供网络和安全性的单点控制、可见性和管理，可以将SDN技术提升到新的水平，其中包括 为使用不同编排器（OpenStack、Kubernetes、VMware等

本文转自： https://mp.weixin.qq.com/s/OloZhn2pwfIrOQit_8jefA 一、前言 2014年可以认为是微服务1.0的元年，当年有几个标志性事件，一是Martin Fowler在其博客上发表了“Microservices”一文，正式提出微服务架构风格；二是Netflix微服务架构经过多年大规模生产验证，最终抽象落地形成一整套开源的微服务基础组件，统称NetflixOSS，Netflix的成功经验开始被业界认可并推崇；三是Pivotal将NetflixOSS开源微服务组件集成到其Spring体系，推出Spring Cloud微服务开发技术栈。 一晃三年过去，微服务技术生态又发生了巨大变化，容器，PaaS，Cloud Native，gRPC，ServiceMesh，Serverless等新技术新理念你方唱罢我登场，不知不觉我们又来到了微服务2.0时代。基于近年在微服务基础架构方面的实战经验和平时的学习积累，我想总结并提出一些构建微服务2.0技术栈的选型思路，供各位在一线实战的架构师、工程师参考借鉴。对于一些暂时还没有成熟开源产品的微服务支撑模块，我也会给出一些定制自研的设计思路。 二、选型准侧 对于技术选型，我个人有很多标准，其中下面三项是最重要的: 1. 生产级 我们选择的技术栈是要解决实际业务问题和上生产抗流量的（选择不慎可能造成生产级事故）

一、项目概述 1.1 项目背景 音乐是一门艺术，是由有组织的乐音来表达人们情感、反映人类现实生活情感的艺术。现代科技的发展使得人们可以利用网络随时随地的享受音乐，然而在当今互联网却很少有一个以音乐为媒介的社交平台。本开发团队想以“音乐+社交”的形式，开发一款集听歌、交友和讨论为一体的网上社区——“Violet”音乐社区。Violet多指紫罗兰，也可形容羞怯的人，本团队旨在通过此平台增强人们对音乐的交流，同时拉近人与人之间的距离。 1.2 技术路线 项目整体采用了B/S架构，并采用前后端分离技术。 前端使用 Vue.js + ElementUI + axios 后端使用 Flask+MySQL 1.3 实现情况 用户、歌曲歌单、圈子帖子、点赞、评论等模块都基本实现了，有小部分功能存在冗余，重复工作量，因为时间受限，没用将我们的设计全部实现。但总体设计中的绝大部分功能都 进行了实现，核心功能、主要业务可以运行。达到了我们立项的基本目标。 1.4 项目文档 Violet音乐社区需求分析说明书： https://www.cnblogs.com/Keadin/p/11791088.html Violet音乐社区设计文档： http://www.cnblogs.com/Keadin/p/11885656.html Violet音乐社区API接口文档： https://www.showdoc

前言 我已经学习 Rust 有挺长的一段时间了，一直想用 Rust 来写点东西，但是缺乏好的想法； 有些想法自我感觉良好，但是又没有能力实现 (比如，写一个操作系统？), 所以最后我决 定还是拿我的博客来做实验品吧。我原来的博客 是 基于 Github Page 和 Org mode 实现的静态博客，略显简单。所以我就觉得用 Rust 来写 个新的博客。 我眼中的 Rust 前后花了一个月的空余时间来写这个博客，写完这个博客之后，我觉得我应该算是有点 Rust 的编程经验了 ;-). 在学习 Rust 和使用 Rust 的时候，我总是将 Rust 和我平时使 用的语言进行对比。一段时间下来，我对使用 Rust 的感悟越来越多，所以我谈谈我眼中的 Rust 优点 内存安全 谈及 Rust, 首先想到的一定是内存安全，正如官网对 Rust 的定义： Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety. 这个也是 Rust 对比其他的语言最大的亮点之一. 众所周知，在 Rust 之前的其他编程语言 管理内存的方式无非是以使用垃圾回收算法管理内存(代表就是 Java 和 Python), 或者是 C/C++

Violet音乐社区-个人总结 目录 项目相关链接 参与工作 权限模块 用户模块 关注用户操作 项目总结 课程建议 一、项目相关链接 Violet音乐社区需求分析说明书 Violet音乐社区设计文档 Violet音乐社区API接口文档 Violet音乐社区界面原型手册 Violet音乐社区前端源码 Violet音乐社区后端源码 Violet音乐社区 二、参与工作 后端我们小组使用了flask框架进行开发，我在权限操作中主要是用到了flask-login插件，这款插件主要解决了登录登出后在访问一些API接口之前自动检测是否登录（检验是否拥有权限），在一些登录注册等接收较多参数的API中，使用wtforms进行了参数的一些必要校验 2.1 权限模块 注册功能 注册我主要是以邮箱为标准进行注册，我们要求的是邮箱不可以重复，而用户名这些则无所谓，而对于用户的密码加密，我使用了werkzeug.security中的generate_password_hash方法对密码进行加盐哈希加密，这样密码在数据库中能保证安全。 登录功能 用户输入邮箱和密码进行登录，我们先通过用户传入邮箱取出加密的密码，然后使用werkzeug.security中的check_password_hash方法进行判断，判断明文和加密之后的密码是否相同，注意这里是不能通过generate_password

目录 一、项目概述 1.1 项目背景 1.2 编写目的 1.3 项目文档 1.4 项目源码 1.5 项目成果 二、个人工作总结 1.1 工作概览 1.1.1 作为项目组组长 1.1.2 作为项目组成员 1.2 工作详述 1.2.1 选择前端技术路线 1.2.2 确立前端界面风格 1.2.3 绘制界面原型 1.2.4 编写前端框架代码 1.2.5 实现播放器功能 1.2.6 履行组长职责 三、项目总结 3.1 项目立意 3.2 技术路线 3.2.1 整体技术路线 3.2.2 前端技术路线 3.2.3 后端技术路线 3.3 实现情况 3.4 项目收获 四、课程建议 一、项目概述 1.1 项目背景 音乐是一门艺术，是由有组织的乐音来表达人们情感、反映人类现实生活情感的艺术。现代科技的发展使得人们可以利用网络随时随地的享受音乐，然而在当今互联网却很少有一个以音乐为媒介的社交平台。本开发团队想以“音乐+社交”的形式，开发一款集听歌、交友和讨论为一体的网上社区——“Violet”音乐社区。Violet多指紫罗兰，也可形容羞怯的人，本团队旨在通过此平台增强人们对音乐的交流，同时拉近人与人之间的距离。 1.2 编写目的 此文档为本人作为该项目成员的个人工作总结，用于记录在开发过程中的经验、感悟以及对该课程的意见和建议，望今后的其他项目能以此为鉴。 1.3 项目文档

OPC测试常用的OPCClient和OPCServer软件推荐 董维康_MES专家 发布于：2013-04-30 各位在进行OPC通讯时，常会遇到两种情况： 1）使用一个OPCClient在同一台计算机上连接远程计算机上的多个OPCServer时，发现某个OPCServer是通畅的，但其他的OPCServer却无论如何都不通。不知该如何定位问题了？ 2）多个厂家的OPCClient连接同一计算机上的OPCServer，发现有的OPCClient通了，有的不通，有的能获取数据，有的不能获取数据。 ff6ff【中国自动化网社区】4982c2【http://sns.ca800.com】cd82c 基于以上情况，将一直以来常用的OPCClient和OPCServer推荐几款，以备大家不时之需。 不是最好，但可能是恰好！ c9a377【中国自动化网社区】d37b43【http://sns.ca800.com】489b644 1. OPC DA Client推荐： 推荐的理由（此标准仅仅代表个人意见）： 1） 单文件；携带方便，无需安装，绿色环保。 2） 遵循OPC标准，稳定。 3） 功能无需多，但适用功能有一个或多个。 c9a377【中国自动化网社区】d37b43【http://sns.ca800.com】489b644 推荐的第一位：OPCClient.exe 把它放在第一位并不是有多好

目录 项目相关链接 参与工作 数据流图绘制 类图绘制 顺序图绘制 后端开发 1. 点赞模块 2. 评论模块 3. 动态模块 4. 根据用户喜好推荐具有相似兴趣的用户 项目总结 项目概念产生 同类产品比较 团队协作 知识获取 意见和建议 课堂讲授 进度安排 项目相关链接 Violet项目源代码 - GitHub Violet音乐社区需求分析说明书 Violet音乐社区设计文档 Violet音乐社区API接口文档 Violet音乐社区 参与工作 数据流图绘制 类图绘制 顺序图绘制 后端开发 1. 点赞模块 点赞模块中包含三个功能，分别是 判断用户是否对某个内容点赞 、 点赞该内容 、 取消点赞该内容 功能模块 query_like(user_id, item_type, item_id) 判断用户是否对某个内容点赞 :param user_id: 用户id :param item_type: 内容种类 :param item_id: 内容对象id :return: 返回值为True表示存在点赞记录 返回值为False表示不存在点赞记录 like(user_id, item_type, item_id) 点赞 :param user_id: 点赞的用户id :param item_type: 点赞的内容种类（歌曲等） :param item_id: 点赞的对象id :return: