后端技术

什么是技术视野 网上看到不少关于如何提升技术视野的讨论，但却没有人给出定义，到底什么是技术视野？ 所谓技术视野，就是看问题时所能切换的不同角（维）度。 下面就以API管理工具（以下简称“管理工具”）为例，来探讨背后隐藏的技术视野。 API管理工具 零视角 曾经在一个小型创业公司用到过最简单的管理工具，就是一个开源的文档管理工具，界面功能类似wiki（维基百科）。 这样的工具确实能满足核心需求——API在线文档化，并支持用户管理。 可是深想一层，对于管理工具的使用者——工程师，操作足够友好，功能足够完善吗？ 使用这类管理工具很多时候都会出现文档与代码不一致的情况，也就是说工程师都不愿意去维护这个文档。 因为编写修改文档是个耗费时间的事情，短期来看， 维护了既无利益，不维护也无危害~ 所以有时候接口的变更通过口头协商而非文档协商。 小结：零视角其实谈不上视野，是大多数工程师的最容易形成的思维方式，特点就是只关注功能/问题本身。 单一视角 当时为了解决上面的问题，同时为了练手所学的Node.js，我写了第一版的管理工具，并参加了线下沙龙分享。 现在看来其实当初的写的项目还是比较粗糙的，除了展示界面相较于wiki更加美观之外，主要加入了 Mock 功能。 更好的开源项目也有不少，比如阿里的 RAP 和国外的 APIDOC 。 之所以把它们归为一类讨论，那是因为它们都体现了开发者的单一视角。

choices参数 用于存： 用户性别 用户学历 工作状态 客户来源 是否结婚 ...... 1.怎么使用 2.如何取 from app01 import models user_obj = models.User.objects.filter(pk=7).first() # print(user_obj.gender) print(user_obj.get_gender_display()) 1.取choices里面罗列的数字与中文对应关系时： 　　取到对应的中文 2.取choices里面没有罗列的数字与中文对应关系时： 　　不会报错，还是展示数字 只要是choices字段，在获取数字对应的注释固定语法： 　　get_choices的字段名_display() MTV与MVC模型 django框架，自称为是MTV框架： 　　M：models 　　T：templates 　　V：views MVC框架： 　　M：models 　　V：views 　　C：controller 控制器(urls) 本质:MTV其实也是MVC Ajax 特点：异步提交，局部刷新 请求方式：GET、POST 　　a标签href属性 　　　　　　GET请求 　　浏览器窗口输入url 　 GET请求 　　form表单 　　　　　　　　 GET/POST 　　ajax 　　　　　　　　　　 GET/POST

MTV与MVC模型 django框架 自称为是MTV框架 M:models T:templates V:views MVC M:models V:views C:controller 控制器(urls) 本质:MTV其实也是MVC Ajax 异步提交，局部刷新 请求方式 　　　　　　　　GET POST a标签href属性 GET请求 浏览器窗口输入url GET请求 form表单 GET/POST ajax 　 GET/POST 首先ajax这门技术 是js中的，但是原生的js操作ajax比较繁琐,我们这里为了提高效率，直接使用jQuery封装版本的ajax AJAX 最大的优点是在不重新加载整个页面的情况下，可以与服务器交换数据并更新部分网页内容。 index.py文件 <input type="text" id="i1">+<input type="text" id="i2">=<input type="text" id="i3"><button id="b1">求和</button> $('#b1').on('click',function () { // 点击按钮 朝后端发送post请求 $.ajax({ url:'', // 控制发送给谁 不写就是朝当前地址提交 type:'post', // 发送方式是post请求 data:{'i1':$('#i1').val(),

最近我的朋友王小闰进入一家新的公司，正好公司项目采用的是前后端分离架构，技术栈是王小闰非常熟悉的vue全家桶，后端用的是Java语言。 在前后端开发人员碰面之后，协商确定好了前端需要的数据接口（扯那么多，其实也就是关于json数据的字段的定义），然后前后端程序猿就嗨皮地并线开发去了。 前后端联调前夕 我的朋友王小闰他们这家公司做本地旅游项目的，安排到他手上的活儿是该旅游项目的webapp工程。 项目动工伊始，一切都得从头来做。在公司没日没夜的开发了一天之后，王小闰在没有借助vue-cli官方提供的脚手架工具下，徒手从零开始，搭建了一套基于公司特定要求的vue项目的工程架构目录。（关于如何从零开始搭建vue项目的脚手架工程，后面我会单独写一个系列）。 前端项目环境搭建好之后，就正式进入了项目首页的业务编码工作。王小闰又没日没夜的敲了一天代码之后，首页header区域、轮播图以及导航图标的页面布局和逻辑开发都实现了，此时他想调用后端数据测试下流程，但是后端程序猿还没有将该数据的接口开发出来，没办法，我的朋友王小闰此时只能在本地模拟点假数据，逼格高点的说法叫mock数据。 捣鼓半天，首页的mock数据终于弄好了，如下图所示： 但是现在有一个问题让王小闰很困惑，他的axios写的url路径是与后端程序猿商量好的绝对路径（域名 请求路径 请求参数），因为这是以后真正的请求路径

文章原创于公众号：程序猿周先森。本平台不定时更新，喜欢我的文章，欢迎关注我的微信公众号。 最近一直在更新关于Nginx的系列文章，终于将Nginx的几个关键知识点讲的差不多了。本篇作为Nginx系列的结尾篇幅，主要是列举一些面试时经常问到的Nginx知识点。其实Nginx适合提问的面试点并不多，问来问去基本都是类似的问题。接下来我们一起来看看Nginx基本的面试题。 Nginx的作用 这个问题是入门级知识点，讨论Nginx的用处。我觉得只要几个重要的点都回答到位就可以了，可以考虑这样的一个回答：Nginx是一个高性能web服务器和反向代理服务器，也是一个IMAP/POP3/SMTP服务器。不仅可以实现负载均衡，还可以做接口限流，缓存等功能。 使用Nginx的优势点 Nginx由于使用了epoll和kqueue网路I/O模型，在实际生产环境能够支撑3万左右并发连接。 Nginx内存消耗低。 Nginx跨平台，而且配置相对来说难度较低。 Nginx内置健康检查功能，如果负载均衡其中一个服务器宕机了，则接受到的请求会发送给其他服务器去处理。 支持Gzip压缩，可以添加浏览器本地缓存的Header头。 Nginx支持热部署，可以在不间断服务的情况下平滑进行配置的更改。 Nginx异步接收用户请求，减轻了Web服务器的压力。 Nginx如何实现高并发

文章原创于公众号：程序猿周先森。本平台不定时更新，喜欢我的文章，欢迎关注我的微信公众号。 最近一直在更新关于Nginx的系列文章，终于将Nginx的几个关键知识点讲的差不多了。本篇作为Nginx系列的结尾篇幅，主要是列举一些面试时经常问到的Nginx知识点。其实Nginx适合提问的面试点并不多，问来问去基本都是类似的问题。接下来我们一起来看看Nginx基本的面试题。 Nginx的作用 这个问题是入门级知识点，讨论Nginx的用处。我觉得只要几个重要的点都回答到位就可以了，可以考虑这样的一个回答：Nginx是一个高性能web服务器和反向代理服务器，也是一个IMAP/POP3/SMTP服务器。不仅可以实现负载均衡，还可以做接口限流，缓存等功能。 使用Nginx的优势点 Nginx由于使用了epoll和kqueue网路I/O模型，在实际生产环境能够支撑3万左右并发连接。 Nginx内存消耗低。 Nginx跨平台，而且配置相对来说难度较低。 Nginx内置健康检查功能，如果负载均衡其中一个服务器宕机了，则接受到的请求会发送给其他服务器去处理。 支持Gzip压缩，可以添加浏览器本地缓存的Header头。 Nginx支持热部署，可以在不间断服务的情况下平滑进行配置的更改。 Nginx异步接收用户请求，减轻了Web服务器的压力。 Nginx如何实现高并发

问题 “一云多端”成为趋势，终端类型越来越多。比如，现在PC Web网站的产品已经有了，现在想扩展APP，小 程序... ...怎么办？一个直接能想到的方法就是在原来的基础上，为APP等增加API接口，如下图所示： image.png image.png 这样做是可以的，然而一旦遇到修改，那么要同时修改几个端的代码，很麻烦，不是很完美。 “前后端分离”成为趋势。一开始的PC Web网站，大多是采用服务端渲染的前后端一体化的模式。随着技术的发展，前后端分离，前端渲染逐渐成为趋势。相应地，前端开发人员也从后端团队中独立出来。 最近兴起的APP，小程序等，天生就是前后端分离的。 前端，APP，小程序等各自独立成专门的团队，当然可以满足这种趋势。 相应地服务端需要为每一个前端部门提供服务，在实践中常常发现，重复的内容很多，有没有办法增加复用？或者说后端能否只对接一个“大前端”部门，剩下的“大前端”部门内部自己解决？ image.png 服务端设计的API接口，面向通用服务，还是面向UI？各个端对数据的显示要求不同，给一个公共的API还是分别给不同的API？ 比如，时间显示，PC端可能要求“2018-6-11”的格式，而APP端可能要求“2018/6/11”的格式，接口怎么给？ 再比如，相同功能的一个接口，PC Web端需要20个字段，已经做好了。现在APP端因为屏幕小，只要10个字段就够了

HI大家好 今天给大家带来一个分享 工程师怎样转算法 这里的工程师指的是什么？ 包括我们的前端开发 后端开发 Java开发 业务开发 大数据分析 甚至一些非计算机出身的 比如说学医的学商的等等 这种问题 经常会在知乎或者是微信群看到 大家都有这个疑问 就是自己不是算法 怎样转成一个算法 对于这个问题我有发言权 因为我自己转了两次 我自己最开始 是一个业务系统的Java的开发 做的就是一些增删改查的一些事情 后来我发现大数据这个领域有意思 于是自己学了Hive/Spark转了大数据的开发 再后来我又发现 大家都在搞人工智能搞算法 于是我不断学习和努力 现在也转成了一个推荐系统的算法的开发 接下来我就给大家分享三条我的经验和感受 第一条要想转算法 最佳的方法就是内部转 大家想一下 如果你跳槽转算法的话 它至少有两个要求 第一要求你之前有丰富的算法的实战经验 这个我们肯定没有 因为我们现在就要转算法 怎么可能有实战经验！ 第二个如果你实战经验不足的话 他就会要求你学校非常好 或者说要求你精深的算法发过论文 能够把一个复杂算法通过手推来实现 这个要求对于我们工程出身的人来说 更是不可能的事情 也就是说如果你想实现跳槽转算法的话 真的是太难了 但是内部转的话可能性非常的大 我可以说任何业务 包含一些非互联网的业务它都需要算法 很多情况下 往往是你用了算法 跟不用算法有很大的区别

　　中秋过的真快，还没体会到就到最后一天了。今天在图书馆，突然想写篇与技术无关的，但是我们工作中经常发生的事情。本来不想写这种类型的文章，怕这种文章降低自己形象显得太low。但是一来想锻炼下自己的文笔叙事能力，越怕这怕那越不敢动笔，越不动笔越没长进，总要开个头来个正向刺激循环；二来相比技术类型的文章，故事类型的文章应该更受大家待见观看；三来这种工作中常见的“甩锅”事件值得大家探讨评论一下，碰撞的火花下交换解决思路，或许以后再碰到类似的事情，能够更迅速完美的解决。 　　故事是这样的，昨天周六，突然有客户反馈了一个问题过来，说公司产品有个业务操作展示错乱了，下一步操作无法执行。问题很快反馈到我们研发大群来了，由于前一天刚好产品迭代了一个版本，负责人是后端的一位小Leader，于是这个问题先由后端的这个同事接了。这个同事看了下接口返回数据，没看出什么问题，马上判定说是前端这边的问题，怀疑是前端这边进行了逻辑修改，要前端去定位原因。 　　由于前端部门老大回老家了，这个任务就落到我头上了。客户发现的问题，还是这么明显的操作，我们竟然没有自查出来，测试也没测出来，那问题就严重了。我也不敢怠慢，顾不得去玩了，赶紧回家连上公司电脑查原因。先查这块逻辑最近git记录，没有发现明显的更改逻辑；然后又切换了四个月前的一个代码分支看效果，发现效果和如今一样。因此我判断，应该不是前端这边的问题

这次作业是对自我想学习技术的学习规划，即软件开发的技术。软件开发，分有诸多个方向，包括但不限于： 1、PC桌面程序， 2、网站服务器端开发， 3、手机APP， 4、脚本开发， 5、数据库开发， 6、人工智能， 7、游戏开发等等。 我想要学习的是Web后端开发的技术。其实之前我自己是很茫然的，没有什么确定要学的东西，这个学一些，那个学一些，也导致没什么动力，。后面看到WEB开发，感觉很有意思，就想要进行学习。百度后，才发现要学的东西很多，把我吓了一吓。不过仔细看了看，感觉很多点或多或少学过一些，而且学完后可以进行开发和设计，还有点小激动。这个路线图就是大致学习的方向，有点小多，只能慢慢的学习，一步一步的前行。 老师给了五个月的学习期限，感觉不太够用啊/(ㄒoㄒ)/~~。感觉学个基础部分时间就用的很多了，进阶部分学不了多少啊。。。不过，五个月后，谁又说得准呢，努力学习吧。 还有点想说的，我比较想学的是后端的开发，因为前端涉及到设计类的，感觉没有艺术细胞，这样的话，有做全栈的可能性吗。。。 来源： https://www.cnblogs.com/gs-23/p/11517353.html