前端

让我们一起拆解VUE

本文章仅仅写给后端或者准备学习vue的前端同学,大牛就忽略本文吧,因为本文只想无经验的同学快速入门vue。 什么是vue? vue就是一个js库,并且无依赖别的js库,直接引入一个js文件就可以使用,你就当它跟jquery差不多就好。 版本选择? 现在vue分为vue1和vue2这两个大版本,然而现在有一些基于vue的框架还不兼容vue2,不过自己折腾可以随意选择一个的,反正文档还算挺详细。 为什么我们要使用vue? 其实跟jquery差不多,都是简化我们的开发。例如我们可以用vue实现像后端模板渲染的功能,可以更加便捷的绑定dom事件,可以把一些页面的组件打包重复使用。下面我们看看如何简单粗暴的使用vue。 看我们如何优雅的使用vue当成模板引擎 后端的同学想必挺清楚模板引擎是什么玩意了,而对于刚入门前端的同学来说,往往渲染页面会使用字符串拼接(非常不推荐)或者dom的clone来动态生成html,但是这两种方法写法都很麻烦,而vue却能十分优雅的实现模板渲染这种功能。 我们拿官方的例子来看看,如下图: 我们可以看到,el里面跟jquery的元素选择标识符是一样的,这个就是选择要渲染的区域。

要拿到研发offer,你需要多强悍的技术?

注:该文章仅仅面对于大多数小型及创业公司而言,请勿跟中大型企业挂钩。 公司与个人的关系 为什么要拿offer,当前是为了拿钱生活了。公司为什么招人,就是为了实现某种功能。总的来说就是用最少的钱找一个能实现功能的人。而我们选择offer必然是选择对我们最有利的。 招聘启事的要求大部分达不到咋办? 我们先随便看几个公司的招聘启事,然后发现要求如下: xx年xx开发经验,精通xx技术,熟悉xx技术优先,具备xx能力。 然而经验告诉我们,进去以后这些要求基本上用不到。但是为什么他们要这样子写呢?一种可能性,不懂技术的人写的,既然他们不懂技术,那么之后照搬网上的东西咯。另一种可能性,想以提高门槛来找到技术水平更高的人。(一般来说前者的可能性要比后者大,我怎么可能告诉你当年我也写过这种招聘要求,当然目的是后者) 这个时候明白了吧,我们不管他上面写着多么高大上的技术,我们只需要事前粗略了解一下即可,反正用上机率不高,

故事

一个程序猴子在创业的公司的一年,是如何从0到1

传说中有一只程序猴子,我们暂且叫他小C,小C在经历了一次创业失败之后,毕竟临近毕业,所以就需要寻找一份工作,作为一个实际项目经历丰富却不背理论的人,所以决定选择一家普通的小公司来工作。 原来只有小C一个后台研发,并且代码为0 入职前几天,小C还在想着,又回归平常的生活了。由于带团队久了,虽然独立解决问题的能力凶残了很多,但是毕竟没有人带,没法吸取前人的经验,并且正所谓当局者迷旁观者清,自己的不足也很难以发现。 但是入职之后,小C蒙了。后台就小C一个人,那就是说没人带小C啦。并且是没有代码的,然后API文档却已经写好的,然后APP端界面是已经完成的,并且他们是2个人。 更可怕的是,他们要出第二版新功能。那么意味着小C是要从版本0写到版本2,而APP是版本1写到版本2,加班加点无可避免了。 技术选型 既然小C接手的时候是0行代码,

看完就会用的GIT操作图解分析

无论你是前端还是后台,无论是运维还是移动端研发,GIT是逃避不了的东西,当然你说你要用SVN,那不在这次的讨论范围之内。不多说,请看下文GIT图解分析,10分钟学会git操作,当然下面的教程是为实战为主,会跟你在别的网站看到的不一样。 1.GIT是啥玩意呀? 首先每一个项目,我们都把他变成一个git仓库。 一个git仓库包含无数分支,默认分支为master 每个分支都包含无数个版本库 每个版本库都包含无数个文件 注:具体包含关系看上图哈,看这图仅仅让你知道git的样子 我们为什么要用GIT呢? 我们可以每次修改一些文件之后,冻结住当前所有文件,然后定义成一个版本,让自己有一颗后悔药吃,可以随时拿到某个版本的文件内容。 记录下每个人修改了什么,可以秋后算账(后半句开玩笑啦) 2.创建一个git项目 寻找一家第三方git托管平台商(

运维

我的运维之路

下面写的是本人三年以来的部署经验,仅仅是个人经验之谈,如有不足欢迎指出。 直接把修改的文件覆盖线上文件 想想一开始的时候,刚学会独立开发一个网站,然后服务器跑一个tomcat,然后每次修改后都是打包成一个war,然后传上服务器覆盖,重启tomcat。 使用git来更新文件 因为后来使用php来开发,然后每次修改都会涉及一堆文件,然后那个时候由于上传的图片跟代码都在同一个目录,所以不能发布新版直接替换整个目录,但是一个一个文件的手工替换又很容易出现遗漏,而导致系统无法正常使用。 刚好这个时候学会使用git来管理代码,所以每次发布版本都是在服务器pull最新的代码,然后手动重启服务,这样子就避免了覆盖文件遗漏的问题。 进阶级使用git自动部署 上面两种阶段只能说是手工部署,完全还算不上运维。进阶版是如何出现的呢?某一段时间,由于涉及微信公众号开发,代码需要提交到服务器来测试。那么在调一个功能的时候,需要频繁更信服务器代码,及重启服务来测试,那么就浪费大量的时间来手动部署了。然后这个时候了解到我们使用的第三方git托管平台提供钩子功能,

高并发

我是如何开发公司年会抽奖系统的?

需求出现 年会将近,而年会抽奖环节必不可少,但是抽奖系统却还没有。所以某一天,PM走过来说:小伙,手头的需求修完成了吧!在年会开始之前必须做出一个抽奖系统。这个系统很简单,后台可以设置总金额,然后每个用户可以获得的金额范围,金额派完则显示很遗憾没有中奖,还要设置抽奖活动时间。 需求分析 一看这东西,就觉得非常简单。最简单的一个方案,活动时间放在一个数据表,总金额和已经使用金额存放在一个表,已经派送的日志一个表。后台提供一个接口,客户端手动点击按钮,则发送一个请求。账号体系直接使用微信的oauth,接口首先判断活动有没有开始,如果开始则随机一个金额,然后判断如果派送该金额会不会超预算,如果不超预算,则调用微信的现金接口发放零钱。 并发问题 这个简单方案存在一个致命的问题,就是并发下,

redis

你真的懂redis吗?

缓存 我相信大部分互联网应用都是用redis作为缓存的,因为相对于memcached来说,redis的kv结构效率区别不大,并且还有hash这种方便的结构,并且redis还有持久化的能力,可以防止重启机器导致的数据丢失而造成数据击穿问题。 计数器 例如记录文章的点击数,用户每次访问文章就自增一。然后还可以利用自减操作来判断库存问题。由于是原子性操作,可以避免并发问题,而且性能很好。 队列 用做消息队列,在要求不高的情况下可以替代rabbitmq等消息中间件 由于redis把数据添加到队列是返回添加元素在队列的第几位,所以可以做判断用户是第几个访问这种业务 队列不仅可以把并发请求变成串行,并且还可以做队列或者栈使用 集合 可以保存一堆预生成的随机数 可以避免一些操作重复调用,因为加入集合的操作是返回true或者false 发布和订阅 这种特性类似于广播,对于一些不用查看历史记录的业务,可以利用这个特性实现类似于聊天室或者系统消息等业务。 字符串操作 这个数据结构,对于普通应用,使用不高,

前端

前后端分离的必要性

前后端分离之前 在前后端分离观点出现之前,我们往往都是后端直接使用后端模板引擎渲染出html页面,当然这个时候对于前端来说是异常痛苦的,他们不仅需要学习后端模板引擎的语法还得配置后端的开发环境。 前后端分离的萌芽 为了让前端无需配置后端开发环境和学习后端的模板引擎,一个简单的前后端分离方案出现了,它就是前端编写静态页面,然后通过ajax从后端拉取数据,然后渲染页面即可,而渲染方法往往就是拼接字符串或者使用js的dom操作。 前端模板渲染的进化 拼接字符串的方法对于后期维护来说是灾难性的,根本没有可读性。而js操作dom需要大量的代码量,对于开发效率来说是低效的。所以前端模板引擎应运而生,使用模板引擎往往只需要引入一个js即可,学习门槛也非常低,渲染出html之后,只需要替换特定的dom元素即可。 前端工程化 在前端进入ajax拉取数据,通过模板引擎渲染页面的时期之后。前端还存在一个亟需要解决的问题,就是多个页面之间往往存在重叠的部分,一开始前端是copy重叠部分代码到每一个页面,弊端也显而易见,就是这重叠部分一旦需要需改的话,每个页面都会被牵连到,这工作量是巨大的,这个时候前端打包技术出现了,

python

python web 框架分析

主流的python web框架 django: 一个大而全的框架 flask: 一个轻量级框架,挺多人使用的 bottle: 一个更加轻量级的框架 tornado: 一个高性能异步框架 web.py: 一个简单易懂的框架 我该选择哪一个web框架 如果是刚入门python的同学,我的建议是使用flask,因为使用这个框架的学习成本是最低的,并且该框架提供了大量的第三方插件,出现问题可以查找的资料也是非常多的。 如果网站是属于高并发,并且是IO密集型的话,我的建议是使用tornado,因为tornado的性能比较强悍,异步特性特别适合IO密集型的情况,当然异步的写法会比同步的纠结一些。 如果是想快速的搭建起一个网站,建议使用django,因为django自带一个非常强悍的admin管理后台,定义好模型和配置好模型之后,就自动完成了管理后台。 flask能否用于商业系统 这个绝对是可行的,

rabbitmq

消息中间件的一点点小看法

消息中间件出现之前 其实消息中间件简单来说就是临时保存一些信息,然后让程序去读取。在还没有接触消息中间件之前,就简单的使用数据库或者redis来实现消息中间件所提供的功能。 rabbitmq的认识 想起第一次接触rabbitmq,就是在2016年工作的时候,后台的哥们介绍的。我对rabbitmq的理解就是一条信息进入rabbitmq需要设置使用哪个交换器,路由件是什么。然后程序读取信息需要指定队列。 一点需要注意的地方 修改了主机名之后,rabbitmq会无法启动。 引入消息中间件的优势 一些可延迟的操作可以通过消息中间件异步处理,例如记录日志,例如用户完成任务赠送优惠券等业务操作,这样子可以大大提高并发能力。 引入消息中间件的缺点 异步错误处理使代码变得更加复杂。 要考虑消息持久化和效率的问题。 提高了入门门槛。 是否需要使用消息中间件 一般来说我们的业务都会涉及消息推送,日志记录,或者一些可以延迟执行的延时操作,那么消息队列还是很有存在的必要的。但是我们可以从业务量来分析,往往业务量不大的情况下,使用redis即可。当然大数量或者对消息完整性有很高要求的时候还是使用消息中间件比较合适。

python

异步的使用分析

什么是异步 同步很好理解,我们每一个操作都是等待上一个操作完成之后,才继续执行。但是有些操作没有必要等待完成之后才进行下一步操作。举个例子,你在12306买票,当你提交订单并且支付完成之后,是会有短信通知和邮件通知的,但是这两个通知并不是完成之后你才看到支付成功,而是有时候很慢才收到信息。这就是异步处理,把非强依赖的操作独立队列慢慢处理。 异步使用场景 当业务要求短时间响应的时候就需要异步,就像今年初和野熊一起创业那会,遇上一个需求,就是点击然后生成一张海报,但是生成海报是一个耗时数秒的任务,但是由于业务关系,不能让用户等待这么久,所以弄了一个中间页面,然后后台异步生成海报,这样子也避免了并发导致系统崩溃。 异步的实现 异步一般来说就是有独立的进程来处理一些操作,那么这些进程怎么去拿任务呢? web服务把任务信息放入redis的队列,然后独立进程往redis里面拿任务,这种做法优点是门槛比较低,不需要额外学习成本,但是redis毕竟不是专门的做任务队列的,所以在海量数据下表现可能比不上专业的软件。

php

一次apache迁移到nginx的历险记

起因 话说在2016年的某一天,老大在阿里云购买服务器需要重启,但是这一次的重启涉及到IP变换。总的来看是一件简简单单的事情,但就由于太久没接触服务器配置,结果引出了一点点小风波。 域名解析 这一步处理起来很简单,只需要在域名服务商的管理面板,修改域名指向的IP地址即可。但是域名解析是有缓存时间的,这个时候,修改后只能默默等待域名解析更新。 启动服务 首先在最前面的服务器软件是nginx和apache,之所以有两个是因为历史遗留问题,这个会在开机自动启动。然后老大的应用主要是php和python,并且由于写好了启动应用的shell脚本,所以执行shell脚本即可。 RDS添加白名单 为什么用RDS呢?其实出于性能和可靠性的考虑。用了RDS就省去自己去搞异地灾备和定时备份。然后数据库主要IO操作比较频繁,并且数据量或者访问量比较大的时候还是需要独立的数据库服务器,然后RDS是优化过数据库的,所以选择RDS可以节省很大部分运维成本,并且性能更佳。但是RDS需要设置IP才可以访问,所以IP变了就需要加入白名单。 apache与nginx在服务器的出生