青青子衿,悠悠我心
但为君故,沉吟至今

在不考虑SSR的情况下如何优化SEO

Yakima Teng阅读(217)

Meta标签

description和keywords两个类型的meta标签对SEO影响很大,直接输出给客户端的页面通常有三种:

一种是类似联系地址、公司介绍之类页面标题固定的页面,可以在前端层面直接写好描述和关键词两类meta标签。

还有一种是类似产品详情页这类页面,如果支持SSR的话一般会在标题里显示出产品具体名称之类的信息,在不支持SSR的情况下,可以填写一些比较范范、通用的介绍和关键词,比空着不写要好一些。

第三类是类似具体业务流程的页面,比如下单、支付过程的界面,这些界面可以不做SEO,或者像第一种那样处理。

H1、H2标签权重较高

尤其是h1标签,其内的文本内容权重较高,不要乱用,要放关键内容。

Sitemap

通过尽可能的完善sitemap(网站地图)来诱导搜索引擎爬虫来爬取页面。可定期完善后主动提交给百度等搜索引擎。

本地预渲染

phantomjs/Puppeteer是无界面浏览器,可用于编程实现在本地打包时通过无界面浏览器来访问尽可能多的页面url来得到渲染好的html结构,如果产品数量和详情在一定时间段内变化不大的话效果还是比较可观的。注意这种本地渲染出的页面只是供蜘蛛爬取所用的,并不供用户访问使用,服务端需要根据UA是蜘蛛还是用户浏览器来返回不同的内容。

这里有个问题就是,渲染的页面的url需要与spa单页应用的页面url相一致,而且不应使用hash方式的url路由(例如:index.html#hello),所以需要服务端配置一下以支持history模式(例如:index/hello)。对于不支持Html5 history API的浏览器(IE从10开始才支持),可以降级用户体验,使用跳转页面的方式取代无刷新跳转路由。

另外一个问题是,如果搜索引擎蜘蛛发现预渲染的页面与用户实际浏览到的页面差异较大,可能会被认为是在欺骗搜索引擎从而导致网站被降级,因此需要考虑以一个较小的周期(比如每天一次)去执行这个预渲染页的生成工作,并且在有内容更新的时候再执行一次。

目前发现prerender-spa-plugin有现成可用的与webpack集成的方案,也支持不使用这些构建工具的原生js项目。核心问题是需要制定待渲染的路由列表,碰到路由上需要带入参数的情况,需要看看是否可以获取到所有路由(及对应的路由上的参数):

  • 我们可以写爬虫(如果方便爬到所有数据的话,另外如果页面html结构重构了的话需要修改爬取逻辑);
  • 或者如果可以获取到数据库的只读权限(不需要写的权限),或者让数据库管理员导出数据来分析,来。

服务端预渲染

原理与本地预渲染一致,就是提前把静态页面渲染出来。但是服务端渲染与SSR(服务端渲染)是不一样的,不需要由服务端去获取各个原先由客户端ajax请求获取到的数据来拼接页面内容。

java服务在判断访问者为搜索引擎蜘蛛时,即时地去使用phontomjs等无界面浏览器来下载页面渲染页面内容然后将生成的内容返回给蜘蛛。

优点是给蜘蛛的内容与给用户的内容更一致。

有一个缺点是因为要等无界面浏览器下载完页面执行完ajax请求获取完数据才能得到渲染好的页面,过程会比较费时,所以可以考虑设定一个文件过期时间,首次预渲染后将对应的html文件保存到服务器上,下一次访问到该文件时使用该文件而非重新去预渲染,当检测到文件已到过期时间就重新预渲染页面然后保存,以此类推,这样平均访问速度不会很慢,而且对服务器端增加的压力并不大。

另外一个缺点是,根据以前写phantomjs批量爬取网页截图的经验,无界面浏览器并不是很稳定,就跟我们用浏览器打开很多页面一样,容易卡死啥的,如果页面数量很多的话,碰到新发布后一次性遇到蜘蛛大量访问新页面的话,服务器吃不吃得消需要再考虑下,服务器端预渲染也可以结合本地预渲染一起来。

参考资料

一个专业的『前端工程化体系』是如何建立的?

Yakima Teng阅读(36)

原问题:一个专业的『前端工程化体系』是如何建立的?

原问题描述:从技术选型到研发到优化、监控、运维等等一系列体系是如何建立起来的?

在知乎上看到了这个问题,我试着按自己的经验去回答了一下,下面是回答内容:

没在大公司工作过,按题目里的几个名词逐个说点自己的看法。

写在前面:工程化以工程化(易维护、易拓展)为核心,不以性能为核心目的(冒泡排序改成快速排序这种不是工程化的事情)。

一、选型

一般的公司用主流技术栈就行了,别搞太小众的,也别自己搞一套太特异性的,不然一来是给新人熟悉项目结构增加了麻烦,二来也给招人带来了难度,换做是我去应聘一家公司,在待遇等方面都大同小异的情况下,我是不会去到这样的公司做这种项目的,君不见那么多公司都要求面试者要熟悉某某框架某某UI库?如果公司项目不用这些,为了自身发展,员工等于需要变相地花其他时间去熟悉那些东西了,研究那些小众技术基本没有研究主流技术带来的进步大。现在主流的技术选型大致是四种吧,vue, react, angular和传统jquery式开发。说个真实的事,有一次我面试过一个人,他的项目经历里有用vue开发过一个企业官网性质的项目,不是SSR服务端渲染的,是常规客户端渲染的,这种技术选型就太离谱了。需要考虑搜索效果的网站,主要渲染工作应该放在服务端,像后台管理系统这样需要避免被搜索的,或者微信公众号项目这样不care搜索效果的,则只要你的技术选型能带来比较好的模块化开发体验问题一般都不大。如果是要避免被搜索的,一定记得写robo.txt,很多人好像都不写的?
选型需要考虑团队的平均水平,既要避免无法提供团队成长的机会劣币驱逐良币,也要避免选型难度过大到时候有问题没人能解决(所以啊,别弄太小众的技术选型)。

技术选型还要考虑开发效率问题,如果现在这个年头了,选型选的大家还需要写以前那种html, css文件,那简直是在谋财害命。html可以用pug来写,css可以用scss这种来写,这两种按缩进来书写的我感觉基本上是对手写代码量要求最少的了。构建工具(gulp、webpack)肯定要用起来。

二、研发

需要团队统一编码规范,尤其是JavaScript的代码规范,用各种lint来约束即可,配以文档加以简要说明,我觉得这种规范重要的是统一,直接定就可以,不太需要团队讨论,因为这东西基本众口难调,而且像末尾加不加分号根本无伤大雅,要的只是统一,有不合理之处的话另当别论。如果是旧项目,可能不方便一次性调整完所有文件的代码风格,除了直接eslint fix(不确定风险大不大,不建议)外,可以尝试在git的commit钩子上配一下代码风格检测——我的意思是说只对当前要commit的内容进行代码风格检测,这样不会影响到旧有代码,随着业务的更新,慢慢地就会把项目大部分代码的风格都统一起来的。

如果团队成员不太排斥的话,最好上typescript或者flow便于类型检查。

代码要配有适度的注释。

另外个人比较建议上一份大体的业务流程文档方便新人熟悉项目,找代码三小时编码三分钟简直mmp。

代码需要注意抽象拆分,这样方便后续代码的维护和重构,当然也方便测试。如果抽象做得好,会有很多东西最后可以拿出来开源的,如果一个团队的开源做得好,他们的业务项目也不会差,这是一个良性循环。

如果团队有一定规模,并且有人力能抽出来,尽可能要做代码审核。要创建一个和谐的研发氛围,定期的代码审核和技术分享都是要的,要鼓励新人老人们分享技术和经验,不然光写业务代码实在太无聊了,人会跑光的。

三、优化

只要页面加载时间和其他请求的等待时间不至于太长的话,一般不需要考虑优化,不要犯一些诸如遍历ul > li操作dom(应该把ul里的html片段字符串对应改动写好后直接替换,这样只操作一次dom)的问题就可以了。基本的优化点想到的有这些:
静态资源压缩(js、css、图片等)+CDN(浏览器对单个域名的静态资源有并行下载个数限制,把静态资源挂在多个二级目录上,就可以增加并行的静态资源下载数了);

减少直接的DOM操作(DOM操作开销非常大);

dom操作语句尽量写到一起,不要分开,据说这样可以利用浏览器自身的优化功能;

可并行的http请求不要顺序发送;

一些请求可以考虑静默发送;

频繁触发的事件(比如滑动事件)对应的handler如果随着事件发生而高频率执行,也是非常不可取的,可以考虑函数节流,让handler不要执行得这么勤快;

减少明显不需要的冗余代码(除了自己写的代码外,常见的比如同时使用jquery和axios。。。);

四、监控

监控的话看过几篇文章,大体思路是ajax错误处理里对发生的错误按一定比例取样上报(发请求到服务端),要发送的信息包括请求的地址、请求参数和请求头、响应参数和响应头、当前页面地址、用户设备信息(UserAgent、屏幕尺寸等)、当前时间、用户id等你觉得需要的信息。这块我尚无实践经验,就此打住。

五、运维

运维运维,运行和维护。

编译本地项目、发布到服务器、在服务器上启动服务,这些操作一定要通过命令/脚本执行,并且还需要写一份check list,不能靠记忆和人力手工执行,因为人为操作,总有疏忽的时候,比如【忘了编译直接就发布了】。

如果是纯前端范围的话,由于都是静态文件,发布后的运维还是比较简单的。发布方面,npm里有个叫gulp-scp2的包,可以在有ssh账号的情况下很方便的将本地文件发布到服务器上(特意去开个发文件用的SFTP工具就显得有点麻烦了)。npm上还有个npm-run-all的包,可以很方便的将package.json的scripts中的多个命令进行串并联组合,在本地弄一些命令的时间比较好用。
如果涉及到node服务的话,可以用pm2进行发布。pm2有对应的错误日志的,如果服务挂了,看错误日志一般能找到问题所在的。pm2 status 这样一个简单的命令,就可以让你看到一些诸如重启次数、CPU占用、服务当前状态等有用的信息。

当然你还应该在服务出故障后往一些人的邮箱里发提示邮件,发邮件我还没尝试过 。

桌面端浏览器兼容性问题总结

Yakima Teng阅读(15)

这里有一份IE8份额统计数据,数据来源为百度统计所覆盖的超过150万的站点,样本为2017年6月1日-2017年6月30日这一个月的数据:https://baijiahao.baidu.com/s?id=1571935494090406&wfr=spider&for=pc。根据文中数据,可以看到那个时间段里IE8的份额已经降至9.83%,并且由于微软不再对IE8提供支持等原因,IE8份额在过去的一年里一直处于一个下降的趋势中。但是9.83%的份额还没有小到让所有企业都愿意忽略的地步。

首先,IE8以下的浏览器已经退出历史舞台了,IE8的份额虽然越来越低了,但还没有低到可以忽略的程度,另外,为低端浏览器的使用者提供一个基本的可用性的保障应当是我们开发人员的一个责任所在。所以,现在浏览器兼容最低做到IE8就可以了,公司内容的工具类网站做到IE9便已足够。

如果你的网站只需要兼容到IE9,那基本上可以说你是不需要考虑什么兼容性的问题了。IE9+(含IE9)、chrome、firefox等浏览器在前端领域统称为现代浏览器,它们对html5、ES5、CSS3的大部分特性都有较好的支持。

需要说明一点,本文所指的兼容性处理方案,有一类是为了保持相类似的效果,有一类是做优雅降级/渐进增强处理,如果为了保持相类似的效果而为低版本浏览器做一些很吃性能的处理是不如直接做优雅降级的,因为对用户来说,“卡得要死”是最糟糕的。当然,还有一种方案是直接提示用户使用现代浏览器。

处理兼容性问题的终极大招——项目写好后:

  • 在其他浏览器里也打开看看界面效果是否有问题,如果有问题的话审查下元素看下是样式没生效,还是样式有问题;
  • 再点点按钮,看看控制台是否有报错,如果有报错,排除掉逻辑性问题后基本就是JS的兼容性问题了,而很多兼容性问题就是缺少polyfill,去MDN网站上搜一下相关的polyfill代码复制粘贴一下就好了。

大致例举下常见的兼容性问题:

Vue、Angular不支持IE8

请在项目开发之前先确定浏览器要兼容到的程序,不需要兼容到IE8的项目要及时劝阻,需要兼容到IE8的项目别上Vue、Angular这些,喜欢MVWhateveryoulike框架的话可以考虑上avalon,如果还要同时考虑SEO,那直接上jquery 1+版本其实也挺好。

部分JS API不支持

使用polyfill,这个可以去MDN这类网站上找相关实现。或者使用做了相关兼容性处理的js库文件。

IE6、7、8怪异模式(quirk)下的盒模型

IE6、7、8怪异模式下的盒模型相当于元素应用了CSS3的box-sizing: border-box;后的结果——width/height的计算是包括border、padding在内的。这个只要你在文档头部进行<!DOCTYPE html>这样的声明就可以避免了。所以如果你碰到一个人不知道IE6、7、8怪异模式下的盒模型问题的话,其实没什么,说明他一直有写这些头部文档类型声明。

CSS兼容性

由于各个浏览器对各种html元素的默认样式是不一致的,所以需要一套CSS Reset来进行统一,可以视统一后的样式为浏览器的“默认样式”,然后在这个基础上进行界面开发。

当初学初学前端的时候,我们还会手写一堆css厂商前缀来尽可能保障各个浏览器都能对这些css属性有个较好的识别。现在借助autoprefixer这类node工具,我们可以把这个工作交给工具去处理。

这里有个非常好用的网站:http://caniuse.com,在这上面可以查各种CSS属性的兼容性,比如可以查到微软对border-radius属性的支持是从IE11开始的,这个地方如果考虑为优雅降级处理的话,就是IE11开始的现代浏览器里显示圆角,IE10及以下的浏览器里显示矩形;这个地方如果想都显示圆角的话,可以不使用border-radius属性,改为使用background-image背景图片,然后将圆角图片作为背景使用。

IE8不支持Html5新标签

IE8出现的比Html5还早,不支持header、footer、article、nav这些新标签是能理解的。在IE8中,可以通过 document.createElement('article'); 这样的方式来让IE8能对其进行识别,另外还需要在CSS里对这些元素进行display属性的声明,因为IE8并不知道他们是块级元素还是行内元素。这种重复性的工作早有现成的解决方案——可以直接使用一个叫html5shiv的js库(这种对页面样式潜在影响比较大的库,应当在head头部中就进行引入,而不是至于body结束标签处)。

结语

其实PC端现存的兼容性问题就那么多,你按标准来写代码即可,你能碰到的问题基本上搜一下都有现成的处理方案的。

 

前端面试FAQ

Yakima Teng阅读(16)

8月末,我学前端快两个月的时候,虽然我还有很多知识漏洞,但我感觉应该可以去应聘个实习生的岗位了。于是我就做了份简历投给了几家杭州的IT公司,应聘的是前端实习生的岗位,期望薪资写的是2000元。后来接到了两个面试,一个是电话面试,一个是去杭州参加的现场面试。这两个面试下来,我觉得如果你的专业不是计算机、数学、物理、自动化等对一元思维要求较强的专业,你的学习能力会比较受怀疑,因为Coding基本上就是不断的判断true or false、1 or 0。我承认自己还有许多技术负债,但我应聘的是实习生,期望薪资是2000元人民币月薪,我觉得我的能力用来求职这样一份工作是没有问题的,我并不是要应聘三四千的熟练工。不过怀疑也是有道理的,毕竟我是新人。

下面是针对这两次面试被问到的一些非技术问题所写的回答,另外我自己也加了几个话题。

问题1:你有github、知乎、技术博客吗?你用google、gmail吗?

我知道github但没有github,知乎还没开放注册的时候我就有知乎账号了但一直只是看客,有博客但没有技术博客,因为我的博客以前写的废话实在太多了,而且以后也还会写很多个人日志,所以技术文章的比例很难达到两位数——博客主体还是个人日志,so未来可预见的时间内我也不会有技术博客的。

我当然用google,而且用得非常频繁,google的东西不是IT人士的专属产品!gmail不怎么用。

问题2:你之前的工作是什么?主要做什么事情?

我刚毕业的时候在一家药厂做了3个月的QA(Quality Assurance,质量保证);然后到另外一家药企做了近2年的国外药品注册工作,主要是做原料药的注册。我不夸张的话,做这两份工作的时候我的工作效率还是比较可以的。我所从事的国外药品注册的工作内容可以归纳为:3个工作流:

  • 工作流1:向公司相关部门索要技术资料→整理撰写注册文档→提交注册资料给国外药政机构(类似中国的药监局)→收到这些官方机构的补件函→反映给公司相关部门进而索要补充资料→将补充资料提交给国外的药政官方机构→反复直至注册成功或注册失败(有时候我们和这些药政机构中间会隔着代理,相当于有个中间的传话人)
  • 工作流2:公司销售人员将客户问卷资料等转发给我们→我们填写问卷中的问题→将填写好后的问卷转发给公司销售人员
  • 工作流3:有时候会需要翻译一些资料给别人看,有中译英的,也有英译中的,频率不是很高。印象中翻译任务比较重的时候是FDA(美国食品药品监督管理局)来公司检查的时候。

问题3:你为什么要转前端?

对前端感兴趣。谈不上“热爱前端”。并不是不热爱就要去深恶痛绝的,我自己有比较强的求知欲,自律方面也还好,就算不热爱,想做到中等水平偏上我觉得不会有什么问题的。另外,我觉得前端本身也不是什么“痛苦的事情”,并不难坚持,甚至于说,由于前端的效果反馈速度非常快(刷新一下浏览器就能看到效果),对学习者的驱动是非常明显的,以至于我觉得学前端技术本身对学习者自律方面的要求是不高的。作为药学人,我有经常去看一下我们这个行业的一些网站——从用户的角度,我目前为止还从来没有见过同学或同事跟我吐槽说丁香园、小木虫、蒲公英这些网站难看的——当然也没人跟我说这些网站好看。怎么说呢,我觉得大部分网络上的站点,最重要的是它们的内容,而不是他们的外观——当然外观上不能糟糕到前景色和背景色一致,前端技术是为内容服务的。我想学前端,是为了业余时间里可以将我自己的内容按我自己的想法表现出来。我比较喜欢写“文章”,虽然都比较水,但是我喜欢写,听着按键的声音我都觉得心里很充实。我高中毕业开始在QQ空间里写东西,然后新浪博客、网易博客都写过,大三的时候(2011年)自己用WordPress搭建了一个博客站点开始写博客,到现在(2015年)我用WordPress已近4年了,以前我只会写一点简单的HTML标签和CSS规则来对我的博客进行小型手术,一直不能做些比较大型的手术,对WordPress的结构我一直比较好奇。但是因为恰逢要做毕业专题、找工作,一直没有空去解开了解它,现在我转前端,有一定原因是想了解我所用的程序。我对前端,现在是感兴趣的同时外加有好奇心的驱动(但是你不用怀疑我做不久,我所说的“感兴趣”跟很多人说的“热爱”的程度没啥区别,只是我觉得大部分人所说的“热爱”有些用词不当,就跟我见过许多说自己喜欢看书的人,但我问他一年看几本书的时候,他马上跟我说书的数量没有意义,那我觉得他所说的“喜欢”也是用词不当——是的,书的数量没有意义,但是你看书花的时间是很有参考意义的,你不愿意往一件事情上花时间,你就不应该说自己“喜欢”做这件事——如果你认为“叶公好龙”是“好龙”,那我收回我的这些话,然后我再告诉你:那么,我也热爱前端)。凡是都有个过程,不热爱就不能去喜欢了吗?不喜欢就不能去接触吗?不接触怎么知道喜欢不喜欢,不喜欢一下怎么知道是不是真的喜欢,算不算热爱?

感兴趣为什么刚毕业的时候不搞的原因。因为我感兴趣的东西多得是。我念了4年的大学,才有机会去从事药学相关的工作,我为什么要放弃这个给人生增加阅历的机会?而且我很早就知道,如果我一毕业就去搞IT,我几乎不太可能有机会去从事药学相关的工作的;但是如果我先去做药学方面的工作,我随时有机会去搞IT。所以。。。而且我去药厂后先后从事了QA和国外药品注册的工作,刚开始的时候我觉得需要学习的东西是很多的,所以开始的一两年内我并没有多余的精力可以专心学其他的东西(当然有部分原因是自身自律方面做得不够),这两年下来,在前辈们的教导下,我觉得自己算是对药厂里的药学相关链有了个基本的认识,算是入了门。师傅领进门,修行看个人,我觉得我后面已经可以自己修行,不一定必须呆在药厂里面了。所以我觉得我可以开始考虑转前端了。

关于智商能不能满足前端工作需求的说明。因为面试的时候有被要求证明自己的学习能力强。很多药厂的地理位置都比较偏僻,整体环境的竞争意识比较弱,人才少,虽然我不算个人才,但不知道为什么我也会有一种孤独感,这种孤独感迫使我想让融入一个稍微有竞争力一点的氛围。像我现在呆的地方,可以说是当地我这个行业里最好的公司了,可我才二十几岁啊,二十几岁就在当地最好的公司里了,这是什么概念?努力的盼头都没有了。一辈子呆里面了吗?为什么感觉像是在坐牢。而且偏点的地方,年轻人流动率相对于在当地安家落户的年长一点的人来说要高得多,所以各个部门都比较缺核心副手,由于年轻人都比较新,对工作的熟悉程度自然有所欠缺,沟通成本大并且风险高,所以有点什么工作上的事情都是直接和各个部门的领导沟通的,这让我比较缺少和公司同龄人沟通的机会,缺少了解他们工作能力的机会,自然也就没法找到从心底上认可的“大神”,这样的环境对提高个人能力的驱动力是很有限的。我并没有觉得IT行业相比制药行业来说更加得人才济济,只是IT行业主要就集中在那个几个核心城市,而且位置大都没有药厂的那么偏僻,楼上、隔壁就是同行公司,而且IT发展很快,因为它很“轻”,不像制药公司那么“重”,诸如此类的原因导致整个IT生态环境的竞争意识相比制药要强多了,另外,IT公司非领导职位存在许多比制药公司非领导职位工资高的情况,这也给人一种IT公司到处是人才的情况,但这基本上只是一个市场供需比造就的经济现象外加大环境对内部人员的驱动造成的,真不是说学IT的更聪明。大家智商都差不多,你能做的事,我也没啥问题。不过如果你们现在做的工作已经难道需要考验你们的智商了的话,那请不要给我面试机会,我怕浪费你们时间。大部分的工作并不是搞创新,是在重复做某些事情(你为几十个网站写了后台的登陆注册逻辑之后,你就不觉得是在重复写一些东西?),还没到需要拼智商的地步,我可能只能做这样的工作。我转前端,更多得是奔着这个生态环境去的,不是奔着找更多牛人的心态去的,在这样的环境里,我会比现在进步得快一些。回到本段开头说的话,学习能力这个事情,我觉得主要是智商+花的时间决定的,智商我没得救了,就这么大众的水平(我跳级到初中,保送到高中,高考不是清华北大但也是个一本,所以我觉得我真的能达到大众的智商水平),但是我比较愿意花时间在学习这件事上(豆瓣已读100+),这个就是我对我的学习能力的答复。

转行的理由?其实我心里并没觉得IT是一个行业。IT,information technology,信息技术,我觉得这个名词本身就已经解释了为什么我会有这样的看法。我目前留意的编程语言只是JavaScript和PHP这样的高级语言,所谓“高级”,就是说它们比较接近人类语言,所以如果正如你某天看到你的同事在学英语的时候你不会觉得他要转行了一样,我学前端或者后端的一些东西的时候,从来没有觉得自己是在转行,我是要去一个可以实际应用所学知识的环境里进一步地学习一些技能。这些技术get过来,是要为了以后能将这些技术用到其他具体的行业里面的。我觉得前端技能就像英语技能一样,但是它在国内相对于英语来说是个比较“年轻”的技能,它现在就像以前的英语一样是少数人会的东西,但是它以后很可能是像现在的英语一样,是很多人都会的东西——虽然正如大部分人的英语不能达到做同声传译的要求一样那时候大部分人的前端技能也不能达到一个非常高的程度,但是也正如很多人的英语水平完全能够满足工作需要一样那时候的大多数具体行业的人的前端技能也完全能够满足他们的工作所需要的前端技能。等我前端技能比较熟络之后,让我选一个行业,我当然希望是制药行业,但是具体做什么,先不想那么多,机会自己会出现的。

最后,用我提出辞职意愿的时候我们经理跟我说的一句话结束这个话题吧:

有千万个理由喜欢,也就有千万个理由不喜欢。能经常自省,梳理,自然是一种积极的态度。祝,转角遇见自己的真正的喜欢。

问题4:说说你对我们公司的了解?

。。。

问题5:你有什么想问我们的问题吗?

  • 需要兼容IE8以下的IE浏览器吗?是渐进增强还是需要实现完全相同的效果?

问题6:你的期望薪资是多少?

期望实习薪资为当地法定最低工资。

另外说明一下,我不要求占用贵公司的转正名额,不要求贵公司帮我交五险一金之类的东西,不要求有师傅带我,不要求公司配电脑(我自己带手提就可以了)、不要求公司提供餐补房补。如果贵公司愿意提供单人间,我可以不要薪水。如果上述由法律上的问题,贵公司可以不跟我签劳务合同,我的身份就不是贵公司的员工了,应该可以规避一些问题。

问题7:你看过那些前端的书籍?

  • Learning PHP, MySQL, JavaScript&CSS
  • JavaScript Visual QuickStart Guide
  • Learning jQuery
  • 《HTML5与CSS3基础教程》
  • 《CSS设计指南》
  • 《疯狂HTML5/CSS3/JavaScript讲义》(暂未看完)
  • 《编写高质量代码:Web前端开发修炼之道》(暂未看完)

另,非前端类的书籍看过《程序员的职业素养》(作者的经验之谈)、《疯狂的程序员》(小说)。

问题8:你有什么项目经验和作品吗?

无正式的项目经验和作品。

我自己写的作品有:第三个作品、第二个作品、第一个作品。

问题9:你近期的职业发展规划?

请注意,职业规划并不是定死的。

开始的两三年时间用来基本掌握HTML、CSS、JavaScript、PHP、MySQL,达到可以搞个博客程序并按自己的需求进行功能改进的程度,然后继续从事前端工作,业务时间维护一个药学APP,一开始的时候自己提供内容,后面尽量形成一个社区氛围。

再次,请注意,职业规划并不是定死的。另,不要期望应聘者的职业规划是和贵司共存亡。。。

问题10:你的英语水平如何?

上一份近2年的工作中,敲的英文比中文多。平常工作不用口头说英语。大概每半年会拿本单词书过一下。

2015年公司付费在当地学校请了一个英国籍的老师来教英语口语,上课成员名额有限,我主动争取了这个名额。每周同时上课的加我一起一共8个同事,一开始大家英语口语水平差不多,或者说我还略差一点,因为我们几位同事平常工作也是不用说英语的,而我本身连中文也都很少说——不管是工作中还是下班后。不过我的进步同比别人要明显得多,后来【老师有比较难的问题都让我来回答】(这句是别人说的)。我觉得我的缺点是发音不那么好,优点是我说话更注重表达内容,我不是以学习英语这个工具为目的,而是以表达观点为目的,另外就是我虽然不太喜欢平常聊天的那种说话,但是我对站在讲台前给一堆人讲某个我准备好了的内容有着较强的渴望。我的英语口语能力可以总结为:能和老外(不包括一些方言音比较特别的)非正式地沟通。

其他地方 也 能 看到我

Github豆瓣读书