者 | 六小登登
责编 | 屠敏
从 2013 年专科毕业开始,一路跌跌撞撞走了很多弯路,做过餐厅服务员,进过工厂干过流水线,做过客服,干过电话销售可以说经历相当的“丰富”。
最后的机缘巧合下,走上了前端开发之路,作为一个非计算机专业且低学历的人来说,自学编程其实不是件容易的事情,不过庆幸的是自己坚持下来了。
目前工作还算不错,收入在目前所在的城市不算高,不算低,生活也还过得去,继续加油努力,也希望自己在今后更上一层。
从 2016 年下半年开始,我真正接触前端,到现在 2 年多的时间。开始之初,我没有任何的语言基础,完全从零的小白开始,就连「对象」我都弄不明白,更别说那些高深莫测的什么封装、继承、多态等。
当时自己也不知从何入手,怎么办呢?于是每当自己遇到困难时,就厚着脸皮去请教前辈大牛,然后就是去查阅资料,很多时候自己也很觉得不好意思,现在才发现人很多时候都耻于相别人请教,怕自己丢面子。
但作为一个过来人,我要告诉你请教前辈大牛真的很重要,可以让你少走很多的弯路,不要怕丢人,没面子,面子值几个钱?学到真本事才最重要。没有技能才叫真的没有面子。当然了我们在请教别人时,一定要掌握「度」,不要打扰到了别人的工作。
我现在非常感谢前辈们的赐教,也感谢那些在网上写博客、文章分享的大牛们,给了我们这些自学的小白很多的资料,经验,心得。从中受益很多。
向优秀的前辈们学习,我开始写博客,希望也能帮到和我一样,学渣、从零开始、喜欢技术的一群志同道合的人。
我深知自己的技术并不高,还处在继续学习的路上,离大牛还差的很远,我本身也非常敬畏技术,也知道自己的渺小,只希望这篇文章的「学习之路」对于那些「从零开始」学习前端的同学有一些指引作用,不像自己一开始那样的那么盲目,哪怕对你有一点点的帮助,就足够了。
说了这么多,下面我们直接进入正题,都是我平时学习和收集的一些资料希望能够帮到你。
前言
工具篇
工欲善其事,必先利其器,所以在开始之前选择一个合适好用的编辑器是很重要的,工具不再多,在于好用就行,除了编辑器,我们也要掌握其他的一些工具,才能够让我们在学习的道路上更加的顺畅。
1. WebStorm
不必多说,前端最强大的编辑器,特别是那无敌的智能提示,但是它的缺点在于如果项目多于大时,出现的卡顿让很多人苦恼。
2. Visual Studio Code
微软开源免费产品,受到非常多技术人员的喜爱,基本上成为前端开发者的必备编辑器,强大的插件扩展,可以灵活的打造自己喜欢的风格。给你们送上常用插件列表拿走不谢。
3. atom
也是一款免费开源的编辑器,受到很多人的喜爱,但是我本人用的较少,所以插件方面就不推荐了,大家可以按照自己的爱好去寻找。
4. 科学上网
每个程序员都应该具备的工具和能力,否则很多事情都无法办到,至于怎么做,你可以自己查阅资料,这里不就不在多说了。而且下面推荐的很多资源都是需要科学上网之后才能访问,所以一定要学会。
5. Google
在使用「Google」之前必须学会科学上网,不然无法访问,学会使用搜索可以帮助我们解决很多问题,一个人的知识是有限的,掌握了搜索的技巧才能以不变应万变,很多时候百度出来的东西重复性很大,最重要的是垃圾信息很多,在百度找不到的答案,在这里很容易找到,Google 是我的必备搜索。
6. Github
全球最大的「同性」开源交流社区,没有账号的赶紧注册,在这有很多优秀的资源项目,各种大神。观摩优秀代码是我们学习的很好路径。另外在开发过程中,很多时候任务重、时间紧,应该避免重复造轮子,这里能够找到你需要的工具或代码。
7. Stack Overflow
国外著名的技术问答交流社区,开发时碰到的很多问题在这里都能找到答案。
8. SegmentFault
对应的国内版的技术问答交流社区,如果你英文不好,也可以在这里找找答案。
9. Markdown
Markdown 轻量级标记语言,简洁的语法,让作者专注内容而非复杂的格式要求,我认为人人都应该掌握,特别是经常写博客的人。想想你在用 world 时的场景,每次写完文章之后,不得不话费很多时间进行格式的排版,使用它你就可以避免这些烦恼。
HTML 篇
一些准备就绪之后,开始我们的学习之旅,首先我们先从 HTML 开始。
HTML名为「超文本标记语言」,是整个页面的结构基础,它承载了我们的页面内容。
1. 基础
2. 进阶
CSS 篇
HTML 承载了页面的内容,但是有时候会略显单调与「丑陋」,CSS 的作用就是为这些内容加上样式,就像一个美女也要有漂亮的外衣去修饰才会更加漂亮,「人靠衣装马靠鞍」,网页的内容也是需要穿上一件漂亮的外衣去吸引用户。而 CSS 则完成了这个装饰。
1. 基础
2. 进阶
书籍:
《CSS揭秘》(https://book.douban.com/subject/26745943/):非常推荐的一本 CSS 书籍,可以学到很多鲜为人知的技巧。
在线系列:
知识点:
JavaScript 篇
有了 HTML 与 CSS,网页也就有了内容和样式,但是会缺少与用户的互动,所有的内容都静静的躺在那里死气沉沉。就好比一个美女穿着漂亮的衣服在你面前一动不动好像也没有什么吸引力,但如果又唱歌,又跳舞,还向你抛媚眼,那可真就把持不住了。JavaScript 就是给网页添加这样的「行为」。
Javascript 简史(https://blog.csdn.net/qq_32135281/article/details/81667714):可以简单了解下,JavaScript 发展由来。
1. 基础
书籍
在线系列
除了书籍之外,也有很多优秀的在线教程,可以帮助我们更好的学习。
2. 进阶
TypeScript篇
ES6 的超集扩展,严格的数据类型,带来更好的维护,适合大型项目的开发工作,有人说它是未来的发展趋势,你说要不要了解?
Jquery篇
虽说现在已经是单页面应用时代,有React,Vue 这种强大的框架可以使用,但也不缺乏一些老的项目需要维护,而且在学习之初,可以用它做两个简单的应用还是不错的,可以相对了解下基本用法,它可以让你更好,更方便的操作DOM。但不建议再深度学习。
Ajax篇
掌握了的HTML、CSS、JavaScript时,这时候可以尝试自己做一些项目了,而项目中肯定会有数据的交互,这时候就是 Ajax 的用武之地了。
NodeJS与模块化
NodeJs 的出现让前端发展进入了一个新的领域,并且滋生出专业的 Node 工程师,不仅如此 Node 在前端模块化,工程化起到很重要的作用,所以了解是必须的,如果感兴趣的可以深入学习,可以向全栈工程师发展。
框架篇
随着日益复杂的用户需求,与系统的复杂度上升,传统的开发模式日渐的很难满足,此时的三大框架孕育而生,让开发者更加高效,可复用,把关注点都放在数据层的操作,免去那些繁琐而又重复的视图操作。
现在框架的能力已经是前端开发人员必备的技能之一也是趋势,三大框架的「最终目的」都是一致的,我认为开发者不必纠结于到底应该选择哪一个学习,可以选择其中的两个是最好的。对于刚入门的人来说,建议选择 Vue 入手,比较简单,灵活。
1. Angular
2. Vue
3. React
React我了解不多,所以就没什么好推荐的了,大家可自行学习。
图形可视化
随着日益增长的数据,如何利用高效的利用数据,是每个企业都考虑的问题,而人的眼睛看到的东西要胜过阅读的问题,俗话说「一图胜千言」就是这个道理,所以数据的可视化就会格外的重要,以下都是我常看的一些技术,书籍,和关注的可视化开源库。
工程化与版本控制篇
1. Git
版本控制工具,很多新手往往把 git 与 github 傻傻分不清楚,二者是不同的东西,一定要去区分清楚。
2. Gulp
自动化构建工具,项目打包部署前的压缩合并,节省时间,提高开发效率。
3. Webpack
Webpack 是当下最热门的前端资源模块化管理和打包工具。它可以将许多松散的模块按照依赖和规则打包成符合生产环境部署的前端资源。
4. Babel
JavaScript代码编译器,可以让ES6及以上语法转换成浏览器支持的语法,一般会在框架的脚手架中自行配置。
5. 代码质量
浏览器与HTTP
性能优化
SEO
博客系列
1. 个人
现在是一个信息爆炸的时代,网上有很多优秀的博客文章,每个人的精力都是有限的,不可能关注到所有的博客,每个人关注点可能不太一样,所以关注的个人博客也会不同,这些推荐几个我比较常看的几个高质量博客。而且是持续更新的。
2. 团队
项目资源
常用工具
最后
以上是我这两年多一路走来收藏的一些资料,整理这份资料也花了我好几天的时间,希望能够在自学的道路上帮到你。
再次声明,我并不是什么大神,我自认为技术也没有到达这个层级,但是我会一直坚持学下去,另外一定不要误会这里面的知识我全部都会,这些都是我学习的一些资料想整理出来,免去小白的一些不知道如何查阅资料。
这里的资源可能并不适合每一个人,你也不一定全部都需要,只需要挑选自己想要的部分就行,任何事情并不是越多越好。
作者:六小登登,个人公众号:六小登登(ID:liuxiaodengdeng)。目前在某创业公司任职前端开发工作,近 3 年前端开发经验,爱技术、爱写作、爱分享。
声明:本文为作者投稿,版权归其个人所有。
一个非专业人士看3D图纸有多难?比如打开一个30M的3D图纸:
但是如果换做用网页看三维,不管你手机多老旧,不论你电脑配置多平常,也不论你是否专业人员,一个链接或者一个超链接、二维码就能解决这些问题。选择SView 网页端,让3D图纸跃然网上,以一个链接的形式,自由适配你的手机和电脑,会有这几种形式:
链接
https://sview.sv3d.cn/model/preview/0a7e37de-1c33-4b32-aed8-72c36584799b
超链接
点击图片跳转预览
二维码
长按识别二维码
网站嵌入
<script src="https://lf6-cdn-tos.bytescm.com/obj/cdn-static-resource/tt_player/tt.player.js?v=20160723"></script>
为什么3D图纸在SView网站上会这么流畅呢?
因为SView在生成3D图纸的链接之前会先对3D图纸做高性能轻量化转换,让图纸的大小能够适配手机,以H5的形式在网页上浏览。这种形式扩大了图纸的复用性以及应用范围的广度,出现了多样化的应用场景。比如:
在电商平台、产品官网,用产品的3D图纸代替传统的文字、图片、视频、动画介绍讲解。通过网页嵌入或者超链接跳转到产品的三维结构图,让浏览者更清晰更全面了解产品的特质、结构、属性。用科技感十足的宣传手段,提升客户对企业实力的认可。
可以摆脱图文表达在直观性和互动性上的不足,销售人员在拜访客户时直接打开手机或者网页,就能立体生动的向客户进行产品介绍,让销售工作事半功倍;介绍产品只提供二维码、链接就可以让客户全面了解产品。
3D产品手册,操作简单,使用方便,360°全三维展示、不同视图展示、结构爆炸图展示、装配树展示、零部件拖拽和旋转。
把传统机械制图教材中的平面三维教学内容,用SView展示出来。拿起移动设备扫一扫,在移动设备中呈现三维图纸的3D立体化效果。学生可对设备中的3D模型做剖切、放大、缩小、爆炸、装配等等自由操作,全方位立体化识得每一个模型结构和特质。
SView利用HTML5技术及三维大数模的轻量化技术,实现在网页端的三维模型预览,同时适配手机及网页浏览,想了解更多SView三维产品知识或者想应用到更广泛的场景中,请联系我们。
更多SView产品体验下载地址:
https://sview.sv3d.cn/tool
SView产品激活地址:
https://service.sv3d.cn/web/licence/applypage
使用由Angular,React,Vue等应用程序框架构建的客户端应用程序时,您总是会处理HTML5客户端路由,它将完全在浏览器中处理到页面和组件的客户端路由。几乎完全在浏览器中...
HTML5客户端路由在客户端上工作的很好,但是当深入链接到一个站点或在浏览器中按刷新时,客户端路由有一个恶习,变成服务器HTTP请求。请求可能未配置服务器的路由。
在这篇文章中,我将讨论如何使ASP.NET Core(或间接ASP.NET应用程序)通过有效地将客户端应用程序重新连接到其路由来处理这些“假”请求。
Html 5客户端路由?
如果您不知道HTML5客户端路由是什么,请快速回顾一下。
客户端框架实现他们自己的客户端路由机制,以便他们可以 - 就像服务器应用程序 - 在页面或组件之间进行导航。
Angular支持几种路由类型:
哈希路线(http:// localhost:4200 /#!/ albums或http:// localhost:4200 /#/ albums)
HTML 5路线(http:// localhost:4200 / albums)
#!/
哈希邦德路线
前者是一种较早的方法,它直接与HTTP语义一起工作,指定任何具有a的URL #
在客户端被触发并跳转到页面内的“本地”URL。框架可以拦截导航并检查跟随的URL内容#
以确定路线。散列爆炸#!\
用于区分应用程序URL和普通#
锚链接。
散列爆炸路线的好处是,他们只是工作。没有服务器端出血的路线,如果您书签或刷新客户端页面,它只是如预期的那样工作,因为散列逻辑是作为浏览器中本地URL解析的一部分执行的。很简单,对吧?它只是工作。
但缺点是,如果您必须手动输入网址,则这些网址非常难看且不直观。对于散列爆炸路线来说,这并不是一个很好的论据,但是不管它们是否对HTML5路由不利。
哈希在Angular中的Bang路由
Angular使用默认的HTML5客户端路由,但它是一个简单的开关来启用Hashbang路由,而不是HTML5路由::
// in app.module.tsproviders : [ .. // make sure you use this for Hash Urls rather than HTML 5 routing { provide: LocationStrategy, useClass: HashLocationStrategy },]
只要您routerLink
在HTML模板中使用链接网址,并router.navigate()
在代码链接中使用,Angular交换机就会自动在两种模式之间进行切换。
在HTML中使用<a routerLink="/albums" />
链接
在代码中使用: router.navigate(["/album",album.id])
HTML5路由
HTML5路由使用更复杂的方法 - 它使用HTML5的Pushstate API来控制客户端的路由并管理地址栏显示。
这种方法的优点是,使用HTML5 API相对容易操作,并且使用标准的无延伸路由约定,使用Web应用程序和API时,URL更加简洁,易于控制。
但是HTML5路由需要服务器的明确支持来正确理解哪些路由是服务器路由,哪些是客户路由。
没有服务器处理的HTML5路由问题
问题在于HTML5客户端路由与服务器路由无法区分。
http://localhost:4200/albums
可以很容易地将客户端URL作为服务器端URL。在完全在客户端上导航时,HTML5路线工作正常 - 应用程序可以拦截导航并在激活特定路线时路由到相应的客户端页面。
如果您使用深层链接导航到客户端驱动的应用程序,然后您将该页面书签为书签,然后使用该URL导航回到该页面,或者刷新当前活动页面,则会弹出问题。在这两种情况下,当浏览器请求路由时,客户端应用程序不运行,因此浏览器向服务器请求路由URL。但是,默认情况下不设置处理说/albums
路线,所以你会得到一个错误。
如果您在ASP.NET Core应用程序中没有对HTML5路由设置进行任何特殊处理,您将在应用程序中打开错误页面,或者从Kestrel中选择此默认显示:
图1 - 未处理的客户端路由产生服务器错误
修复服务器上的客户端路由
那么你如何解决这个问题呢?
客户端SPA应用程序通常有一个或几个启动应用程序的静态页面。对于一个典型的Angular应用程序,该页面是index.html
启动应用程序并启动客户端路由。大多数框架都足够聪明,可以在启动时检查当前路由,并移至首次访问请求的路由。
如果客户端路由从书签,链接或完全刷新被触发到服务器,则需要提供index.html
并保持原始URL不变。
然后,客户端应用程序将自行引导,并且内部路由启动,以希望将您甩回书签/刷新位置。
从服务器提供Index.html
为了这个工作,你需要确保服务器只提供服务器负责的内容。
有几种方法可以做到这一点:
主机服务器URL重写
处理ASP.NET Core应用程序中的客户端路由
主机Web服务器上的URL重写
如果您在主流Web服务器上运行ASP.NET Core(或ASP.NET)应用程序,最简单且最有效的解决方案是重写客户端URL并为index.html
给定的URL 提供内容。
在IIS上,您可以使用IIS重写模块来执行此操作。我最近在一篇博文中更详细地介绍了这一点:
ASP.NET核心应用程序的IIS重写规则
但是这里是相关的IIS重写规则:
<rewrite> <rules> <!-- Make sure you have a <base href="/" /> tag to fix the root path or all relative links will break on rewrite --> <rule name="AngularJS-Html5-Routes" stopProcessing="true"> <match url=".*" /> <conditions logicalGrouping="MatchAll"> <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" /> <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" /> <add input="{REQUEST_URI}" pattern="api/" negate="true" /> </conditions> <action type="Rewrite" url="wwwroot/index.html" /> </rule> </rules></rewrite>
您可以从以下任何位置安装UrlRewrite模块:
Microsoft下载网站
choco install urlrewrite
Web平台安装程序
如果你在Linux上运行Docker和nginX或者Apache,那么类似的Rewrite选项就可以在那里使用。
让ASP.NET Core处理客户端路由
如前所述,我通常使用像IIS或nginX这样的前端Web服务器来处理重定向,但是通常在测试或内部应用程序时,只需要Kestrel直接为应用程序提供服务即可。如果您直接让Kestrel处理HTTP流量,那么您需要在ASP.NET Core代码中处理客户端路由。
捕获所有app.Run()
处理程序
有很多方法可用,但是我发现了在Startup
类的Configure()
方法中使用一个非常简单的后备处理程序来处理客户端路由的最简单的方法:
// set up whatever routes you use with UseMvc()// you may not need to set up any routes here// if you only use attribute routes!app.UseMvc(routes =>{ routes.MapRoute( name: "default", template: "{controller=Home}/{action=Index}/{id?}");});//handle client side routesapp.Run( async (context) =>{ context.Response.ContentType = "text/html"; await context.Response.SendFileAsync(Path.Combine(env.WebRootPath,"index.html"));});
关键是app.Run()
位于路由后的管道末端的中间件处理程序。如果服务器端路由不能找到匹配的路由,这个通用处理程序就会启动。
上面的代码是你可以做的最简单的事情,只是把内容发送index.html
到客户端。如果您有多个静态页面和SPA筒仓,您可以在其中添加额外的逻辑来尝试确定需要加载哪个页面。
请注意,内容不会重定向到,而是作为内嵌流发送到现有的URL请求,以便用户请求的URL保持不变。这确保了当用户请求http://localhost:4200/albums
你回到那个客户端页面而不是index.html
。
捕获所有路由处理程序
另一种方法是在路由定义中使用最后定义的全部捕获的 MVC路由处理程序。这基本上拿起你的MVC路由配置无法处理的任何URL,然后路由到你指定的路线。
使用catch-all处理程序设置您的MVC路线,将此代码放在您的Startup
类的Configure()
方法中:
app.UseMvc(routes =>{ // default routes plus any other custom routes routes.MapRoute( name: "default", template: "{controller=Home}/{action=Index}/{id?}"); // Catch all Route - catches anything not caught be other routes routes.MapRoute( name: "catch-all", template: "{*url}", defaults: new {controller = "AlbumViewerApi", action = "RedirectIndex"} );});
然后执行完全相同的事情中间件处理程序使用:index.html
使用以下代码将内容流式传输到客户端:
// we need hosting environment for base pathpublic IHostingEnvironment HostingEnv { get; }public AlbumViewerApiController(IHostingEnvironment env){ HostingEnv = env;}[HttpGet]public IActionResult RedirectIndex(){ return new PhysicalFileResult( Path.Combine(HostingEnv.WebRootPath,"index.html"), new MediaTypeHeaderValue("text/html") );}
Catch-All Route不使用属性路由
确保您为回退路线指定的路线不具有分配给它的属性路线。当我昨天检查出来的时候,我无法得到一条全面的路线,直到我
[Route("api/RedirectIndex")]
从控制器的操作中移除 了这个全部工作。
SpaServices
SpaServices提供了另一个选项,routes.MapSpaFallbackRoute()
尽管我自己也没有尝试过,但是如果您已经在ASP.NET Core应用程序中使用了Spa服务,那么这可能是一个简单的方法来实现这个功能,包括潜在的支持服务器预渲染。
概要
HTML5路由为客户端应用程序提供了干净的URL,但它的价格必须有服务器支持才能使其工作。使用主机Web服务器中的重写规则或直接在Kestrel的中间件管道或自定义路由处理程序中进行设置并不困难,但是您必须确保将此功能显式添加到您创建的每个ASP.NET应用程序中。
尽管旧的Hash Bang路线看起来不那么干净,但它们工作正常,不需要任何服务器端支持。对于需要支持古代浏览器的非公众应用程序或应用程序,在没有服务器支持的情况下,散列邦线路仍然是提供路由的可行方式。
最后,如果您正在使用完整的Web服务器,UrlRewriting是处理非ASP.NET内核后端直接处理的非API内容的最干净和最有效的方式。
选择是好的,你有几个选择提供方便,干净的网址或简单的只是把它放在功能。你的选择...
*请认真填写需求信息,我们会在24小时内与您取得联系。