首页 文章 精选 留言 我的

精选列表

搜索[share]，共2823篇文章
优秀的个人博客,低调大师

十日谈 (share)

@拔赤 一直想写这篇“十日谈”，聊聊我对Web前端开发的体会，顺便解答下周围不少人的困惑和迷惘。我不打算聊太多技术，我想，通过技术的历练，得到的反思应当更重要。 我一直认为自己是“初级”前端开发工程师，一方面我入道尚浅，只有短短几年，另一方面我自知对技术的钻研并不深入，可能是由于环境的原因，当然最重要的是，我幸运的参与到互联网崛起的浪潮之巅。时势造就了一批技能薄弱但备受追捧的“弄潮者”，这在很大程度上影响我们对“技术本质”的洞察力，多年来也一直未有成体系的“前端技术”布道佳作，以至于当下多数人对前端技术的了解，盖始于表述并不严谨的岗位招聘描述，而这正恰恰反映了Web前端开发对自身的模糊定位。对于很多Web前端工程师来说，初尝禁果的快感无法持续很久，就陷入一轮又一轮的迷惘，思索自己的职业规划，试图寻找到适合自己的成长道路、看清自身技能的瓶颈，寻找突破。但遗憾的是，Web前端技术被广泛接纳时日尚短，没有多少励志的成功样板可供遵循。然而情况不总是这么糟，毕竟Web前端技术是一门“技术”，和计算机科学系出同门，只是因为互联网的高速崛起而被蒙上了迷雾，遮住了双眼，让我们傻傻看不清时局。 那么，如何定义Web前端技术岗位边界？Web前端技术的价值体现在何处？前端工程师的价值仅仅体现在物以稀为贵吗？前端工程师的初级、中级、高级和专家之间到底如何界定？当前“我”处在什么位置？接下来的路子应当怎样走？何谓前端技术之“道”？我想多数人都思考过这些问题，本篇“十日谈”里的观点可能有些偏激，但抛砖引玉，读者权且把这些言论当作一个引子吧。第一日：初尝禁果 【上帝说：“要有光！”便有了光】 万物生灵、阳光雨露盖源于造物之初的天工开物，我们无法想象上帝创造光明之前的世界模样。但幸运的是，前端开发没有神祗般的诡魅。这个技术工种的孕育、定型、发展自有轨迹，也颇有渊源，当然，这非常容易理解。不严格的讲，在杨致远和费罗在斯坦福大学的机房里撺掇出Yahoo!时，Web前端技术就已经开始进入公众视野，只不过当时没有一个响亮的名字。从那时起，“基于浏览器端的开发”就成了软件开发的新的分支，这也是Web前端技术的核心，即不论何时何地何种系统以及怎样的设备，但凡基于浏览器，都是Web前端开发的范畴（当然，这个定义很狭隘，下文会提到）。 在2000年之后浏览器技术渐渐成熟，Web产品也越来越丰富，中国有大批年轻人开始接触互联网，有一点需要注意，大部分人接触互联网不是始于对浏览器功能的好奇，而是被浏览器窗口内的丰富内容所吸引，我们的思维模式从一开始就被限制在一个小窗口之内，以至于很长时间内我们将“视觉”认为是一种“功能”，Web产品无非是用来展现信息之用。起初的入行者无一例外对“视觉”的关注超过了对“内容”的重视，先让页面看起来漂亮，去关注html/css，沿着“视觉呈现”的思路，继续深入下去。因此，这类人是被“视觉”所吸引，从切页面入行，着迷于结构化的html和书写工整的css，喜欢简洁优雅的UI和工整的页面设计，之后开始接触视觉特效，并使用jQuery来实现视觉特效，以此为线索，开始深入研究Dom、Bom和浏览器的渲染机制等，html/css在这些人手中就像进攻兵器，而JavaScript则更如防守的盾牌。 还有另外一群人从另一条道路接触Web前端，即工程师转行做前端，他们有较多的后台语言开发背景，从读写数据开始，渐渐触及浏览器端，接触JavaScript库，起初是在html代码上加js逻辑，后来开始涉及html和css，他们喜欢OO、逻辑清晰、结构悦目的代码，更关注界面背后的“程序语言”和数据逻辑。html/css在这些人手中则更像盾牌，而JavaScript更如进攻的兵器。 应当说这两类人是互补的，他们各自了解浏览器本质的一部分，一拨人对渲染引擎了如指掌，另一拨人则将JS引擎奉为至宝，其实任何一部分的优势发挥出来都能做出精品。大部分前端工程师都能从这两条渊源中找到自己的影子。但，这两类人的思维模式和观点是如此不同，以至于形成了一些不必要的对抗，比如在某些公司，干脆将Web前端技术一分为二，“切页面的”和“写js的”。这样做看上去明确了分工提高了效率，但他对员工的职业发展带来巨大伤害。在第二日“科班秀才”中会有进一步讨论。 我应该属于第二类，即在学校正儿八经的学习C/Java和C#之类，以为大学毕业后能去做ERP软件、桌面软件或者进某些通信公司写TCP/IP相关的程序。校园招聘时选择了中国雅虎，因为当年（08年）雅虎还是有一点儿名气，而且我听说雅虎比较算技术流的公司……自此就上了贼船，一发不可收拾。 在雅虎的这段时间，我有幸接触到一股正气凛然的技术流派，也形成了我对前端技术的一些基本看法，这些基本观点一直影响我至今。 【优雅的学院派】 当年雅虎的技术流派正如日中天，拥有众多“之父”级的高人，所营造出的Hack氛围实在让人陶醉的无法自拔，那段时间我甚至宁愿加班到深夜阅读海量的文档和源代码，感觉真的很舒服，我深深的被雅虎工程师这种低调务实、精工细琢的“服务精神”所打动，而这种不起眼的优秀品质很大程度的影响雅虎产品的用户体验和高质量的技术输出。那么，何谓“服务精神”？即你所做的东西是服务于人的，要么是产品客户、要么是接手你项目的人、要么是使用你开发的功能的人，所以技术文档成为伴随代码的标配。因此，工程师之间通过代码就能做到心有灵犀的沟通。这是工程师的一项基本素质，即，思路清晰的完成项目，且配备了有价值的技术文档，如果你的程序是给其他程序员用的，则更要如此，就好比你制造一款家电都要配备说明书一样。因此，YDN成了当时最受全球程序员最喜爱的技术文档库，这种优雅务实的“学院气息”让人感觉独具魅力。 让人感觉奇怪的是，在中文社区始终未见这种学院派。甚至在具有先天开源优势的Web前端技术社区里也是波澜不惊，可见写一篇好的技术文案真的比登天还难。我所见到的大部分所谓文档索性把代码里输出数据的语句块拷贝粘贴出来，至于为什么数据格式要设计成这样、如果字段有修改怎么做、编码解码要求如何等等关键信息只字不提，或者开发者也没想过这些问题呢。因此，我们一直在强调代码的质量和可维护性，但一直以来都未见效，盖源于缺少这种“服务”意识的灌输。这种意识在下文中还会多次提到，因为它能影响你做事的每个细节，是最应当首先突破的思想纠结。 除了意识问题，另一方面是技术问题，即文笔。这也是工程师最瞧不上眼的问题，难以置信这竟然是阻碍工程师突破瓶颈的关键所在。我已看到过数不清的人在晋升这道关卡吃了大亏，很多工程师技术实力很强，但就是表达不出来，要么罗列一大堆信息毫无重点、要么毫无趣味的讲代码细节，不知云云。除非你走狗屎运碰到一个懂技术的老板，否则真的没办法逃脱码农的宿命。但大部分人还振振有词不以为然。而在Web前端开发领域情况更甚。前端工程师是最喜欢搞重构的，但在快节奏的需求面前，你很难用“提高了可维护性”、“提升了性能”这类虚无缥缈的词藻为自己争取到时间来搞重构，说的露骨一点，可能你真的对某次重构带来的实际价值无法量化，只是“感觉代码更整洁了”而已。我会在下文的“伪架构”中会展开分析前端工程师的这种浮躁献媚的技术情结。而这正是前端工程师最欠缺的素质之一：用数据说话，用严谨科学的论据来支撑你的观点，老板不傻，有价值的东西当然会让你去做。 当然，情况不总是这么糟糕，我们看到中文社区中已经锻炼出了很多写手，他们在用高质量的文字推销自己的技术理念，这是一个好兆头，好的文笔是可以锻炼出来的。而在职场，特别是对前端工程师这个特殊职位来讲，这种基本技能可以帮你反思梳理需求的轻重缓急，从凌乱的需求中把握七寸所在。因为当你开始认真写一封邮件的时候，这种思考已经包含其中了。 所以，雅虎技术的推销是相对成功和远播的。关键在于两方面，扎实的技术功底和高超的写手。而真正的技术大牛一定是集两者与一身，不仅钻研剑道，还能产出秘籍。这也是Yahoo!优雅的学院派气息的动力源泉。国内很多技术团体想在这方面有所建树，应当首先想清楚这一点。 【规范的破与立1】 雅虎的技术运作非常规范，刚才已经提到，包括技术、组织、文化，一切看起来有模有样，也堪称标杆，自然成了国内很多技术团队和社区的效仿对象。一时间各种“规范“成风、各色“标准“大行其道，结果是质量参差不齐。 我们到底需要什么样的规范？雅虎的技术规范到底有何种魔力？以何种思路构建的规范才是货真价实的？规范有着怎样的生命周期？想清楚这些问题，能很大程度减轻很多Web前端工程师的思想负担，看清一部分技术本质，避免盲目跟风。 我们的确需要规范，但好的规范一定是务实的，一定是“解决问题“的。比如针对项目构建的DPL可以收纳公用的视觉元件以减少重复开发、规定某OPOA项目的事件分发原则以确立增量开发的代码惯性。反之，糟糕的规范却显得过于“抽象“，比如页面性能指标、响应式设计原则。另外，尽管他山之石可以攻玉，但拿来主义有一个大前提，就是你了解你的项目的关键问题，你要优先解决的是些关键问题，而外来规范正好能解决你的问题。因此规范是一本案头手册，是一揽子问题的解决方案，应当是“字典”，而不是“教程“。可见规范的源头是“问题”。所以，当你想用CoffeeScript重构你的项目时、当你想引入CommonJS规范时、当你想在页面中揉进Bootstrap时、当你打算重复造轮子搞一套JS库时、当你想重写一套assets打包工具时，想想这些东东解决了你的什么问题？会不会带来新的问题、把事情搞复杂了？还是为了尝鲜？或者为了在简历中堂而皇之的写上使用并精通各种新技术？ 规范之立应当有动因，动因来源于项目需求，项目需求则来自对产品的理解和把握，这是Web前端初级工程师走向中级甚至高级的一次重要蜕变，软件工程领域早就有“架构师”角色，而架构师往往存在于项目需求分析和概设、详设阶段。我看到的情况是，Web前端工程师的思维过多的限制在“界面”之内，向前和产品需求离的太远（认为这是视觉设计师的事）、向后和数据逻辑又隔离开来（认为这是后台工程师该干的事），因此前端规范也大都泛泛，无关项目痛痒，成了玩具。 雅虎技术规范的优秀之初在于它们解决问题。所以，学习使用规范应当多问一句，“他们为什么这样做？”其实，想清楚这些问题时，脑海中自然形成了一种“遇山开山”的创造性思维。 【规范的破与立2】 如果说新技术的尝鲜缺少针对性，但至少满足程序员的某种洁癖和快感，那么“负担”从何而来呢？对于初学者来说，有价值学习资料可能只有这些规范，如果说规范价值不大，那又当从何入手呢？ 刚才我说的不是依赖于规范，而是对规范的反思，摆脱规范灌输给我们所思维定势。新人们大概是看了Wiki中的很多指标、结论、实践，在做项目之初就附加了不少“八股式”的负担，甚至影响我们对项目关键需求和关键问题的洞察力和判断力，负担过重就无法轻装上阵，Wiki中提到的这些指标和规范是结论性的，是大量的实践之后得出的，也只有经历过大量实践才会真正理解这些结论，比如DomReady时间和http请求数是否有因果关系，http请求数增加是否真的会导致页面性能下降，什么条件下会导致性能下降？我们从那些条文和结论中无法找到答案。 举个具体的例子，Kissy刚刚出了DPL，也是一大堆结论，比如他的布局就采用了经典的双飞翼，使用容器浮动来实现，那么，这种做法就是不可撼动的“标准”吗？看看淘宝车险首页，布局容器齐刷刷的inline-block，只要顶层容器去掉宽度，布局容器自身就能根据浏览器宽度调整自然水平/垂直排列，轻易的适应终端宽度了。 再比如，淘宝旅行计划项目中的部署方式，也没有完全使用Loader管理依赖，而是将依赖层级做的很少，业务逻辑使用脚本来合并，这样就可以更容易在build环节加入语法检查和代码风格检查。 类似这种摆脱原有编程思维，有针对性的用新思路新方法解决问题的做法显然让人感觉更加清爽，编程的乐趣也正体现在打破常规的快感之中，小马曾经说过：“制造规范是为了打破规范”，万不要因为这些规范标准加重负担，导致开始作一个简单页面时也显得缩手缩脚，无法放开身手。大胆的动手实践，才能真正得出属于自己的“结论“和“标准“，才会真正深刻理解那些“结论”的意义所在。代码写的多了，自然熟能生巧，也容易形成成熟的技术观点。 在这个过程中，我们唯一的对手是懒惰，惰于思考，就无法真正发现问题，自然形不成自己的观点。还是那句话，任何规范、方法、结论、实践都是为了解决项目中的问题的，所以，我们所接触到那些看似“八股文”式的规范标准也是为了解决某些问题而提出的，想清楚这些问题，理解方法论背后的“因“，内心自然有“果”。 因此，“着眼当下、对症下药”的品质就显得弥足珍贵了，比如，双飞翼布局方法是为了解决一套（html）代码适应多种布局设计，这里的布局相对于固定的产品来说也是固定的，而无针对终端的自适应（适用于移动端的榻榻米布局似乎还没有最佳实践）。这是双飞翼产生的背景，如今终端环境较之5年前已经翻天覆地，问题早已不在“多种布局”上，而在“终端适应“上，这才是我们面临的问题，需要我们给出新的技术方案。 所以，勤于思考，轻装上阵，大胆实践，勇于创新，发掘问题所在，实打实的解决（潜在）问题，这才是我们真正需要的能力。放下思维定势枷锁，也会有一种豁然开朗的感觉。第二日：科班秀才 【秀才仕途】 Web前端工程师是一个特别的岗位，只存在于互联网领域。最近几年随着互联网产业的火爆，对前端工程师的需求量暴增，兵源几近枯竭。各大公司技术掌门一定都有过类似的苦恼：“招一个靠谱的前端工程师、难于上青天”。 我想，一部分原因是，当前不少入道的前端工程师大都是转行而来，毕竟，正儿八经的学校里也不会教这玩意，觉得“切页面”有啥好教的，甚至不觉得html/css是一门语言。转行这事自不必详说，大家也各自瞄准当前市场需求，造成的现象是，初级前端工程师堆成山，中高级人才却一将难求，计算机系的科班出身就更加凤毛麟角了。一方面反映了教育部门的后知后觉，另一方面也体现了大部分人急功近利的跟风。当然最重要的原因是，所谓中国“第一代前端工程师”并未做好布道的工作。导致大家对于基础和潜力的态度从之前的忽视演变为如今的蔑视。所谓基础，就是在大学上的那些计算机基础课。所谓潜力，就是戒骄戒躁的务实作风。这些会在后文中多次提到。 对于科班出身的莘莘学苗来说，根正苗红本身就是一种优势，事实证明，这些人在前端技术上的成长轨迹有一定的套路，而且大都能如期的突破技能瓶颈。从一个人大学毕业到他最满意的工作状态，中间会经过几个阶段。 前2年是学习技能的阶段，这个阶段主要精力放在专业技能的提升上，2年内起码要赶上平均水平，即所谓“中级“，在这个阶段的人通常对软技能不怎么关注，沟通能力达不到平均水平，基本上是来啥活干啥活，干不完就加班的这种，对需求的合理性不甚理解，对项目也没什么把控，尽管在技能上有提高的空间，也不是公司最需要的人，但有不少成长空间。 工作2-3年的人在前端技能上趋于稳定，也就是技能上的第一次瓶颈，这种人干活熟练，切页面可能也很快，代码看上去也比较规范，属于熟练工，开始注重沟通技巧和一些职业技能的积累，比如带人带项目，至少有这方面的意识，并有过推动项目、和业务方pk需求的经历，这就达到了中级应当具备的职业技能，但应当注意的是，这时最容易出现偏科的情况，特别是对于那些“专门切页面的“和“专门写脚本的“人，毕竟html/css/js三者不分彼此，三者是一个合格前端工程师都必须要掌握的。如果你觉察到自身有偏废的嫌疑，则要小心了，要清楚的了解自身的差距，并意识到瓶颈的存在，为过渡到“中级“的打下基础。 过了这道坎之后，工作3年以上的人大部分技能也趋稳，有些人对前端新技术有钻研，能够熟练应对日常工作，软技能也ok，具备有针对性的“拿来主义“，代码也具有一定的架构性，开始突破“代码民工”的这一层瓶颈，对团队气氛、培训、工作环境有个性化的要求，一般来讲，这种人是典型的具有潜力的“中级”工程师，但很快会遇到职业发展中的第二个技术瓶颈。 有少数工作3年或4年以上，在不断寻求新的技能上的突破，最明显的一点体现是，开始关注“底层协议”，即HTTP、第三方应用、系统对接、制造工具、工作流程等，这时思考的重点已经脱离了“切页面”，变为“出方案“，比如要架设一个站点，能够搭建站点框架，预见站点后续（前端）开发中的所有风险，并一一给出解决方案。项目后续开发遇到问题只要翻阅你提供的“手册”即能找到答案。这种人是标准的“高级”Web前端工程师。 出方案是一件挺难的事情，它要求一个工程师同时具备经验、技术、气场等诸多硬技能。尤其是对技术底子的要求非常高。 【半路出家】 那么，转行作前端的人又当如何呢？其实发展轨迹和科班秀才们非常类似，只是时间跨度可能会长一些，你要花更多的精力、作更多的项目、更多的反思和总结才能理解某个知识点的本质（比如HTTP协议）。当然这只是一般情况。 此外，这些人还需要摆脱很多思维定势的禁锢。这里我推荐大家阅读阿当的《Web前端开发修炼之道》。当然，如果你有一个靠谱的师兄带你入道，自然幸运万倍。 但不管怎样，我始终认为应当秉承兴趣第一的原则，不管你是误打误撞、还是意欲为之，不管你是科班秀才、还是半路出家，兴趣始终应当是第一原则，然后才是你“想做好“。我对自己的要求无法强加于人，所以很多业界大牛在回顾自己成功之路时，提到最多的是：“热爱你的工作、拥抱它给你带来的挑战”。N.C.Zakas曾经这样勉励大家： “我对Web开发人员最大的建议就是：热爱你的工作。热爱跨浏览器开发带来的挑战、热爱互联网技术的种种异端，热爱业内的同行，热爱你的工具。互联网发展太快了，如果你不热爱它的话，不可能跟上它的步伐。这意味着你必须多阅读，多动手，保证自己的才能与日俱增。下了班也不能闲着，要做一些对自己有用的事儿。可以参与一些开源软件的开发，读读好书，看看牛人的博客。经常参加一些会议，看看别人都在干什么。要想让自己快速成长，有很多事儿可以去做，而且付出一定会有回报。“第三日，幸福感 【先精通十行？！】 兴趣第一，听上去很美，但现实却不总是这么酷。练就了一身本领，那也要找到对口的怪物来打一打才过瘾。 自然，每个人都想做出好东西，每个工程师也都渴求这样的机遇，用层次分明的设计、漂亮优雅的代码、精妙的细节雕琢，做出美观、安全、实用耐用的产品，不过现实是如此残酷，以至于工程师们一直都缺乏对产品的归属感。作为前端工程师，如何才能在江湖中把握住前进方向、步步走高？毕竟，在职位繁杂的大公司，缺乏人性化的工作流程影响着工程师的工作幸福感。产品从设计之初、到技术方案评审、再到实现，处处充满了妥协，大部分产品都是杂交的产物，人与人相互掣肘，每个人都对产品不满意……，大跃进式的敏捷开发早就被证明百害无一利。但，或许这就是成长的代价。年轻的工程师需要更多的了解需求和设计、产品经理更要懂得软件迭代规律。对于前端工程师来讲更是如此，多学习交互设计和UI，多了解网络协议和软件迭代模型，更能帮助前端工程师和需求方沟通、和后台的衔接、以及控制版本的迭代。 说来奇怪，前端工程师不是写html/css/js的吗，搞懂那些边缘知识有什么用？《Web前端开发修炼之道》中也提到，精通一行需要先精通十行。这里我来解释一下原因。 作为交互设计师的下游，前端工程师学需要习设计知识是很容易理解的，因为它能帮助你更准确的理解设计师的意图，在原型不完整的时候也能正确的反馈设计缺陷，将问题阻挡在设计的环节，会大大减少UIbug数量，比如说，设计师会给出理想状态下的容器样式，却往往忽略了文字溢出折行、长连续字符、容器宽高是否适应内容尺寸变化而变化，溢出部分是作截字还是隐藏等诸多细节，因为设计师不懂“边界值测试”的道理，而这些问题往往在测试阶段才被发现，所以，如果能在拿到UI设计稿时就提醒设计师补充完整这些场景，自然减少测试回归次数。 另外，前端工程师必须要了解网络协议，原因很简单，我们作的产品运行在Web上。很多依赖域Ajax的实现，只有前端工程师才会提出实现方案，产品经理不了解技术瓶颈，后台工程师更不会在意客户端的用户体验，举个简单的例子：通过JS实现一个Ajax，如果Ajax抓取的数据源是一个302跳转，则需要在JS程序中多做一些事情，这就需要前端工程师了解一些HTTP协议。应当说，这是很常见的一个场景。 那么，为什么说前端工程师也要关注代码版本控制呢？因为web开发和软件开发本质无异，同样具有迭代周期，需求不是一揽子提完、一口气开发完的，是有步骤的开发，因此，每次上线开发哪些功能、为后续扩展功能留足哪些接口、代码在可扩展和可维护性上应当作哪些考虑……，这些应当是每个工程师关注的事情，所谓迭代就是指这种需求的叠加，这是软件开发的常态，也是web开发的常态，刚开始，前端工程师总会不断抱怨没完没了的需求，代码起初还算干净，但很快就越来越乱，代码的版本管理对于Web前端工程师来说有些困难，这也使得大部分前端工程师很难上档次，从这个角度讲，前端工程师是需要向后台工程师学习的，他们的开发量不比前端少，维护代码的能力要超过前端工程师。另外，对于刚入行的前端工程师，心态要放对，提需求是产品经理的职责所在，整理出有价值的需求是交互设计师的职责所在，将需求作版本控制分步实现是前端工程师的职责所在，前端工程师没必要去抱怨产品经理提一大堆没规律的需求，而更应当去理解需求缘由，将需求提炼成UC（用例），让需求在自己手中可控制。只是多数前端工程师缺乏提炼、整理需求的能力，一味的在接需求，才会搞的手忙脚乱，带着情绪堆代码。 所以，只有练就了一身本领，才会更有目标的去寻找对产品的责任感和对团队的归属感，不要误以为能切出漂亮的页面就是能力的提高，纯粹的写代码每个人都差不多的，要成为合格的工程师，眼界要进一步放开，前端工程师能做的，不仅仅是切页面而已，作一个精品项目，一定不乏专业的过程把控，这也是大多数人最易忽略的地方。 【励志之本】 其实，除了个人需要明确努力的方向，每个人都更渴望身处一个好团队，谁都不希望有猪一样的队友。我们都很羡慕处身这样的团队，可以放心的将精力放在纯粹的技术上，身边每个人都自觉的补充文档注释，代码也层次清晰解偶充分重用率高，精妙的设计实现可以更快的传播，bug得到的改进建议也是务实专业的，技术在这种良性互动中价值倍增。我想这也算是好团队的一种境界了，这有赖于团队成员水平水涨船高。不过，反观Yahoo的成长之路，他们的技术积淀也是靠点滴的积累，其实他们当初的状况不比现在的我们好哪去，10年的进化，才造就了Yahoo技术团队的专业性和Hack精神，我们每个人才刚刚起步而已。为了积攒工作中的幸福感，多付出一些是值得的。 但我猜，你现在的处境一定不会太过乐观，产品乱提需求、一句话的PRD、不被重视，被生硬的当作“资源“……反正，情况就是这么个情况，要么你选择抱怨下去，要么想办法去改变。“积极主动“是源自内心的一种坚韧品质，也是励志之本，有些人在现实中被磨平了理想，有些人却在黑暗森林中找到了方向，这就是犬儒主义和英雄气概之间的差别。这自不必详说，因为这让我想起了“大长今”，这简直就是前端工程师的励志典范：“这是一个可怕的环境,足以消磨任何人的斗志和信念，所有来这里的人都变得麻木和无所作为，‘多栽轩‘恶劣的环境没有改变长今，但长今却改变了‘多栽轩‘所有的人“。 如果你想做到“资深”，就一定要想清楚这一点，因为你是团队的顶梁柱（业务），也是幸福感的源头（士气）。第四日，架构和伪架构 【代码设计的本质】 读到这里，你不禁会问，前端领域存在“架构师”吗？这个问题会在后面的“码农的宿命”中展开解释。这里先说下代码架构的一些琐事吧。 什么是架构？架构是由“架”和“构”组成，架，即元件，构，即连接件。因此，架构即是将总体分解为单元，然后定义单元之间的连接方式。架构的含义源自禅宗，而禅宗的基本信条则之一就是真理是无法用语言来描述的。这个基本信条有其背景，即语言具有某种抽象性。而人们对这种抽象性的悟道则直接影响对事物的看法，进而决定了对客观世界的分解方法。 而在编程语言中，同样存在这种禅宗所隐喻的悖论。在面向对象的教科书中，通常举一些显而易见的例子，比如“水果”是一个类，包含有苹果、桔子、香蕉等实例，“蔬菜”也是一个类，包含白菜、冬瓜、茄子等实例。这两个类之间并无交集，因此很容易理解。但实际项目中情况要复杂的多，比如两个图书类目“文学”和“历史”，那么“明朝那些事”应当是“文学”类的实例还是“历史”类的实例呢？即一旦用语言说出了某一事物，即人为的割裂了世界，于是就会陷入迷途。这在程序设计领域情况更甚，也是造成混乱的主要根源，也就是说，如果你的程序可扩展性不好，一定是程序作者对“单元”的定义不够准确，即单元的概念之间不够“正交”。而这种架构终是徒有其形，根基不稳。 因此，变量和类的命名才是真正考验架构功力的关键（命名是否准确清晰、单元之间是否有概念重叠或盲区），而和所谓“组合”、“继承”、“桥接”等模式化的“外表”无本质联系。 【伪架构】 实际情况是，程序员早早的就想让自己和“架构”扯上关系，并自封xx架构师。在项目中应用各种模式分层、解耦方法，每个项目都可以产出一套看上去很复杂的“架构图”，感觉很牛逼的样子，没错，实践这些方法论总不是坏事，但世界观才是方法论的基础，只有在概念上对产品模块有科学的定义，方法论便自然形成了，《编程珠玑》中一再提及数据结构就是静态的算法，在Web前端领域亦是如此，在页面的建模过程中，定义分解维度要比分解方法更加基础和重要。我想阿当可以在《Web前端开发修炼之道》的第二版里加上这部分内容。 真正的高手用记事本就能写出高质量的代码、用cvs就能做到完美的版本控制、用字典式的分解就能做好系统架构，我想，这正是剑宗一派的最高境界吧。第五日：寻找突破 【动心忍性】 技术流派看上去是如此吸引人，高手就像侠客一般，来去如风潇洒自如。但反观自己怎么看怎么没有侠客那股范儿。尽管上文提到了一些道理，了解这些尽管不是坏事，但缺少实践总感觉是纸上谈兵。更何况，日常的工作又是枯燥无味、繁杂单调。每个人都盼望更高的目标、接触新鲜技术、将新技术运用到日常，在探索尝试之中寻找成就感。这种感觉可以理解，但却缺少更深层次的思考。因为越到最后越会发现一线的工作才是最有挑战的。当然，我说这话的前提是，你能如前文所说具备合格的软技能，需要一些技巧让工作变得工整有序、节奏健康，这样你才能将注意力放在纯粹的代码中，摆脱了外界的烦扰，方能从技术的角度思考突破。这也是从初级到高级的进化过程需要大量的历练的原因。正如玉伯所说，“枯燥是创新的源泉。如果你发现自己没什么新想法，做事缺少激情，很可能是因为你还未曾体验过真正的枯燥的工作”。 关于如何寻找突破，我的建议是马上动手做、不要等，相信自己的直觉（这里和上文提到的先思后行是两码事）。比如，Slide幻灯控件理应支持触屏事件以更好的适应移动终端，或许你在用的Slide幻灯版本很旧、或者时间不允许、再或者你害怕对Slide改造而引入bug，不要担心，大不了多花业余时间，只要想，只要感觉合理和必要，就去做。因为这个过程带来的编程体验才是工程师们独有的美妙体味。我现在还时常深夜写代码，没有打扰、思如泉涌、代码也更加工整严谨，不失为一种享受。因此，用眼睛去观察，用心去感触，“所以动心忍性，才会增益其所不能”啊。 【得与失】 互联网的发展的确太快，Web前端技术也在花样翻新，有人经不起诱惑，开始做新的尝试。前端技术虽然范围广，但各个分支都还比较容易入门，比如服务器端脚本编程、再比如纯粹的WebApp，我认为这两者都是前端技术的范畴，毕竟他们都没有脱离“浏览器”，或者说类似浏览器的环境。NodeJS依赖于V8，WebApp更是软件化的WebPage。只要打好基础，这些方向都是值得深入钻研的，因为，互联网的形态越发多元，新的技术总能找到用武之地，这就要凭借自己的技术嗅觉和产品直觉，寻找技术和业务的契合点。 这看上去是一种放弃，放弃了自己赖以生存的铁饭碗（熟练的切页面至少不会失业），实则不然。这种想法是一种误区，新的选择并不会让你放弃什么，就像学会了开车，并不意味着就不会骑车了。其实改变的是思维方式而已，是一种进步，如果你能想通这一点，你也能跟得上互联网发展的脚步了，打开你的思维，让技术变成你的金刚钻，而不是包袱。 所以，所谓得失之间的权衡，其实就是“解放思想”。做到了这一点，那么你已经在做“技术驱动”了。 【误区】 但是，不要高兴的太早，“技术驱动”是需要大量的积累和经验的。在入行初期，很多人过于着迷与此，从而陷入了迷途。比如有人纠结于是否将dt、dd的样式清除从reset.css中拿掉，原因是觉得这两个标签的清除样式会耗费一些渲染性能；或者是否需要将for循环改为while循环以提高js执行速度。尽管这些考虑看上去是合理的，但并不是性能的瓶颈所在，也就是说，你花了很大力气重构的代码带来的页面性能提升，往往还不如将两个css文件合成一个带来的提升明显。就好比用一把米尺量东西，没必要精确到小数点后10位，因为精确到小数点后2位就已经是不准确的了。这种技术误区常常让人捡了芝麻丢了西瓜。 话说回来，这里提到的怀疑权威的精神是绝对应当鼓励的，但不应当止于表象，如果怀疑dt的清除样式会对性能带来影响，就应当想办法拿到数据，用事实来证明自己的猜测。数据是不会骗人的。而求证过程本身就是一种能力的锻炼。 【技术驱动】 说到这里，你大概对“技术驱动”有那么一点点感觉了。身边太多人在抱怨“公司不重视前端”、公司不是技术驱动的、技术没机会推动产品业绩、我的价值得不到体现？ 什么是技术驱动？简单讲，就是技术对业务有积极推动作用。更多的是工程师发起、工程师影响、工程师负责。刚才提到的用数据说话只是一种“驱动”技巧，那么我需要何种数据，数据从哪里来？我来分享一个实际的场景吧。 工程师A被委派一个重要的频道首页，因为是新年版，所以要赶在年前上线。A学了一点点响应式设计，想在这次重构中加上，但谁也没做过响应式设计，需求方根本不懂，设计师也懵懵懂懂，交互设计师太忙，做完交互搞就忙别的去了。A纠结了，按部就班的把项目做完上线发布，尽管不会出什么问题，但总觉少点什么。这时A做了两个决定，1，我要按时完成项目，2，趁机实践我在响应式设计中的想法和思考，若成功，作为附加值赠送给需求方，若失败，权当技术玩具耍一耍罢了。所以A熟练的提前完成了项目，剩下的时间开始考虑如何将首页适应到各个平台中，视觉设计是一大难题，他用吃饭的时间找了设计师收集建议，对窄屏中的内容模块做了看似合理的编排，代码上hack一下，能够正确适配，就发布上线了。这件事情需求方不知道，视觉设计师也不了解，交互设计师更没工夫操心。A感觉挺爽，开始给工程师弟兄们到处炫耀这个好玩的功能，B看了问，手机端访问量如何，A觉得这个问题有道理，就去部署埋点，一周后拿到数据出奇的意外，首先，移动段的访问量稳步增加，趋势健康，再者，移动端首屏焦点广告位的点击率较PC端高了近一倍，这个数据让A喜出望外，兴奋的拿着报表找到交互设计师C和市场研究的同事D，D看了报表之后立即启动一个项目，专门调研公司全站响应式设计页面在PC端和移动端的点击率、PV、UV趋势方面的影响……后来发生的事情就都水到渠成了，设计师C开始注意设计页面交互时（至少是有条件的考虑）对移动端的适配，D的调研报告也放到了UED老大的案头……接下来的事情，你懂得。A被指派要出一套响应式最佳实践和规范，最终，A走在了技术的前沿，也因此拿到了好绩效。 这件事情就是一个典型的技术驱动的例子。谁不让你玩技术了，谁不重视你了，谁把你当工具了，谁觉得你的代码没价值？这世界只有自己把自己看扁，谁想跟你这个蝇头小卒过不去？用实力说话，用数据说话，用独到的见解说话，想不做技术驱动都难。第六日：码农的宿命 【青春饭】 “码农”是IT从业者一个自嘲的称号，也有从事没有发展前景的软件开发职位，靠写代码为生的意思。但我认为码农是一个爱称，编码的农民，和农民一样有着执着纯真朴实豪爽的共性，仅仅分工不同而已。就好比农业社会对粮食的依赖，工业化进程对计算机应用也有着很强的依赖，大量的需求催生出这样一群人。他们有智慧的大脑，对于编程，设计，开发都有着熟练的技巧，但多数人看来，码农的特点是： 1，收入低 2，工作单调 3，工作时间长 实际上这个描述非常片面，或者说是外行看热闹。第一，全行业比较来看，软件开发领域收入为中等偏上，第二，程序员一般都是有癖好的，沉浸在自己的癖好中是不会感觉单调的，第三，程序员有一定的时间自由度（如果你是一名合格的程序员的话），至少不会像流水生产线工人一样。其实，通过几十年的发展，我们对程序员的定义更加科学，比如很多IT企业都开始建立详细的JM（JobModule），即职级模型，程序员沿着专业方向可以走到很高，甚至可以说，程序员是可以被当成一生的事业的。 然而，有一个非常普遍的观点是，程序员和做模特一样是吃青春饭的，到了三十岁就要考虑转行或者转管理。尽管这种观点颇具欺骗性，但至少它对一种人是适用的，即入错了行的人。如果你骨子里不想写程序，就算年纪轻轻为了生计写几年代码，之后肯定会另有他途。心非所属则不必勉强，但问题是，即便如此，你知道你的心之所属吗？ 我们知道，一个成熟的产业一定需要各色岗位来支撑，若要成熟，则需要时间的沉淀，比如实体经济制造业，创意、生产线、高级技工、技术管理四个方面都产出大量的高级人才。因为历史悠久，我们能看得到。而软件产业则不然，九成以上是刚出道的新手，并没有太多“高级”和“资深”的具体样板可供参照，在前端开发领域中情况更甚，绝大部分人根本搞不清楚什么样才是“资深”前端工程师，相比传统软件行业近四十年的进化，我不相信仅有几年光景的前端技术岗位能产出多少货真价实的“资深”。但互联网崛起速度太快，还没有等技术基础打牢，互联网形态就又花样翻新了，这种变化是一种常态，而岗位的设定也在这种变化之中自然的优胜劣汰，比如两年前可能还难以想象数据部门会需要前端工程师，他们甚至不直接和浏览器打交道。前端工程师需要适应这种变化带来的观念冲击，不要以为自己只能做切页面、或者只会给页面搞重构、只会搞兼容性，要把自己放在整个软件行业来看。 所以，由于历史“不悠久”导致的岗位模糊本身不是什么大问题，岗位的演化本身就包含在互联网的发展轨迹之中。所以，当今的互联网IT状况，就好比移动终端的大哥大时代、云计算的肉鸡时代、或者桌面操作系统的DOS时代。因此，前端工程师当前要务是要想清楚看清楚，在互联网中我能做什么，而不是作为前端工程师我能做什么，所以，从这个角度讲，技术是一个工具，放大来看，技术也只是你职业生涯中很小的组成部分，而你的从业积累、和知识面的广度深度才是你随着时间的推移慢慢步入“资深”的原因所在，而不是写了个什么框架就变“资深”了。如果有一天互联网形态固定了，它的岗位可能真正就定型了，才会有真正清晰的职能边界，就像蓝色巨人IBM中的各色岗位一样，边界清晰，权责分明，普通程序员只能实现接口而无机会设计接口、低层级的工程师也无机会跃进式的接触项目架构、技术经理人也不能轻易对产品有决策性影响，到这时，人的能力才真正的被限制在方圆之内，容不得越界，这种环境下人的成长非常缓慢。根本不会有像今天互联网乱局之中所提倡的创新、革命、成长和思想解放。简单讲，一旦产业定型，就不太需要很多“创造”了，更多的是“维护”。所以，我个人宁愿互联网IT“黑暗”的中世纪越久越好，至少对于年轻气盛程序员来说，黑暗的丛林环境才是真正的自然进化最理想的土壤，这时我想起了狄更斯在“双城记”中的开篇。 “这是最好的时代，这是最坏的时代；这是智慧的时代，这是愚蠢的时代；这是信仰的时期，这是怀疑的时期；这是光明的季节，这是黑暗的季节；这是希望之春，这是失望之冬；人们面前有着各样事物，人们面前一无所有；人们正在直登天堂，人们正在直下地狱”。 【半路出家的危与机】 然而，不管怎样，信心的树立不是一蹴而就的，对于转行做前端的人来说更是如此。俗话说，隔行入隔山。每个行业自有其道，自然不是想做就做。前端技术领域半路出家者非常多，我们来分析一下转行的心理。第一，看到前端技术入门简单、互联网对前端技术的需求缺口巨大；第二，前端技术所见即所得、感觉学习起来很快；第三，我身边的某某转行作前端看上去不错、我似乎也可以；第四，我不喜欢我现在做的工作、想换行业、正好前端技术上手较快，就选他吧；第五，我真的喜欢作Web前端，为它付出再多都是值得的。 转行者的心态比较容易走两个极端，一是只看到新行业的好，二是只觉得原工作很糟糕。但不管是什么行业的转行，对自己的职业规划的思考都应当先行一步。即务必首先清晰的回答这些问题： 1，我能做什么？ 2，我不能做什么？ 3，我的优势是什么？ 4，我的劣势是什么？ 5，做新行业对我有何好处？ 6，换行会让我付出何种代价？ 7，如何定义转行成功？ 因为面试的时候一定会被这些问题所挑战。如果支支吾吾说不清楚，要么是对自己未来不负责任，要么骨子里就是草根一族，习惯做什么都蜻蜓点水浅尝辄止，也难让人信服你的转行是一个权衡再三看起来合理的选择。我无法帮每个人回答这些问题，但至少有两点是确定的，第一，Web前端技术是一个朝阳行业，绝对值得义无反顾的坚持下去，第二，你将经历从未有过的枯燥、苛刻的历练，所谓痛苦的“行弗乱其所为“阶段。不过话说回来，经历过高考的人，还怕个屁啊。 有心之人自有城府、懂得放弃，看得清大势中的危机、识得懂繁华里的机遇。尤其当立足于Web前端技术时，这种感觉就愈发强烈。因为国内外前端技术领域从2000年至今一直非常活跃，前端技术前进的步伐也很快，对于一些人来说，不管你是在大公司供职还是创业，不管你是在接外包项目还是自己写开源项目，从转行到跟得上新技术的脚步是有一些方法和“捷径”的。 第一，梳理知识架构 我们知道知识积累有两种思路，第一种是先构建知识面、建立技术体系的大局观，即构建树干，然后分别深入每一个知识点，即构建枝叶，最终形成大树。第二种是先收集知识点，越多越好，最后用一根线索将这些知识点串接起来，同样形成大树。第一种方法比较适合科班秀才，第二种方法则更适合转行作前端的人，即实践先行，理论升华在后。比如对“IE6怪异模式“这条线索来说，要首先将遇到的IE6下的样式bug收集起来，每个bug都力争写一个简单的demo复现之，等到你收集到第100个bug的时候，再笨的人都能看出一些规律，这时就会自然的理解IE的hasLayout、BFC和各种bug的原因、你就成为了IE6的hack专家了，当你成为100个知识线索的专家的时候，你已经可以称得上“资深”的水平了。我们知道，10个人中有9个是坚持不下来的，他们会以项目忙等各种理由万般推托，将自己硬生生的限制在草根一族，坐等被淘汰。所以，对于立志作前端的人来说，这种点滴积累和梳理知识非常重要。 第二，分解目标 将手头的工作分解为几部分来看待，1，基本技能，2，项目经验，3，沟通能力，4，主动性和影响力。想清楚做一件事情你想在哪方面得到历练，比如，我之前在作第一次淘宝彩票常规性重构的时候（正好是一次视觉和交互上的全新设计），我清楚的明白这次重构的目的是锻炼自己在架构准富应用时的模块解偶能力，寻找在其他项目中架构的共通之处，所以我宁愿加班或花更多精力做这个事情，当然更没打算向业务方多解释什么，这件事情对我来说纯粹是技能的锻炼。而经过这一次重构之后，我意外的发现对业务的理解更透彻深入、更清晰的把握用户体验上的瓶颈所在。如果一开始就把这次常规改版当成一个普通的项目按部就班的做，我只能说，你也能按时完成项目，按时发布，但真真浪费了一次宝贵的锻炼机会，项目总结时也难有“动心忍性”的体会。 所以，每个项目的每个事情都应当认真对待，甚至要超出认真的对待，想清楚做好每件事对于自己哪方面有所提升？哪怕是一个bug的解决，即便不是自己的问题也不要草草踢出去了事，而是分析出问题原因，给出方案，有目的involve各方知晓……，正规的对待每个不起眼的小事，时间久了历练了心智，这时如果突然遇到一个p0级的严重线上bug（比如淘宝首页白屏，够严重的了吧）也不会立即乱了方寸，这也是我上文提到的心有城府自然淡定万倍，而这种淡定的气场对身边浮躁的人来说也是一种震慑和疗伤，影响力自然而然就形成了。 第三，作分享 做分享这事儿真的是一本万利。有心的人一定要逼着自己做分享，而且要做好。首先，自己了解的知识不叫掌握，只有理解并表达出来能让别人理解才叫掌握，比如如果你解释不清楚hasLayout，多半说明自己没理解，如果你搞不懂双飞翼的使用场景，可能真的不知道布局的核心要素。再者，作分享绝对锻炼知识点的提炼能力和表达能力，我们作为工程师不知道多少次和强硬的需求方pk，被击败的一塌糊涂。也反映出工程师很难提炼出通俗易懂的语言将技术要点表述清楚。而做ppt和分享正是锻炼这种能力，将自己的观点提炼出要点和线索，分享次数多了，自然熟能生巧。档次也再慢慢提高。另一方面，逼迫自己站在公众场合里大声讲话，本来就是提高自信的一种锻炼。 这时，你或许会问，我讲的东西大家都明白，我讲是不是多余，我第一次讲讲不好怎么办，大家会不会像看玩猴似的看我“这SB，讲这么烂还上来讲”？要是讲不好我以后再讲没人听怎么办，我今后怎么做人啊？ 老实说，这是一道坎，任何人都要跨过去的，谁都一样，你敢鼓起勇气在大庭广众之下向爱人表白，就没勇气对自己的职业宿命说不？其实勇敢的跨越这一步，你会意外的收获他人的掌声和赞许，这些掌声和赞许不是送给你所分享的内容，而是送给你的认真和勇气。这个心结过不去，那就老老实实呆在自己的象牙塔里遗老终生，当一辈子工程师里的钻石王老五吧。 【匠人多福】 如果你能耐心读到这里，心里一定有一个疑问，上面说的都是技术上能力上怎样怎样，那我所做项目不给力又当如何？如果项目不挣钱、黄了、裁了，我的努力不就白费了吗？我又有什么绩效和价值呢？ 没错，有这种想法的人不在少数。特别是刚出道的校招同学往往更加心高气傲，以为自己有改变世界的本事，一定要参与一个牛逼的团队做一款光鲜靓丽受人追捧能给自己脸上贴金的项目。如果你有这种想法，趁早打消掉这个念头，当然，我们这里先不讨论创业的情形。 第一，如果你刚毕业就加入一个牛逼团队，说难听点，你就是团队中其他人眼中的“猪一样的队友”，不创造价值且拖项目后腿（显然大家都要照顾你的成长啊），按照271理论，你没有理由不是这个1。至少相当长一段时间内是这样。 第二，你在所谓牛逼团队中的创造性受限，因为创新多来自于团队中的“资深“和大牛们，你参与讨论但观点通常不会被采纳，他们只会给你这个菜鸟分活干，想想看，你如何能花两到三年就超越身边的大牛们？甚至连拉近与他们的距离都难。 第三，如果身在牛逼团队，自然心理对周围的牛人们有所期待，希望他们能灌输给你一些牛逼的知识和牛逼的理念。这种思想上的惰性在职场生涯之初是非常危险的。要知道技术和知识本身是很简单和淳朴的，只不过披上了一个光鲜项目的外衣而让人感觉与众不同。 第四，由简入奢易，由奢入简难，做过一个看似光彩的项目，心理再难放平稳，去踏实的做一个看上去不那么酷的产品。这种浮躁心态会严重影响今后的职业发展和成长。 第五，光鲜靓丽的项目被各种老大关注，是难容忍犯错误的，傻瓜都知道犯错误在成长之初的重要性。 就我所看到的情形看，一开始加入看似很牛的项目组，三年后得到的成长，比那些开始加入一个不被重视的项目的同学要小很多，而后者在能力上的弹性却更大。所以，道理很简单，你是要把一个很酷的项目作的和之前差不多酷，还是把一个不酷的项目做的很酷？项目是不是因为你的加入而变得与众不同了？ 从这个角度讲，不管是转行的新人还是刚出道的秀才，最好将自己当作“匠人”来对待，你的工作是“打磨”你的项目，并在这个过程中收获经验和成长。付出的是勤奋，锻炼的是手艺，磨练的是心智。因此，你的价值来自于你“活儿“的质量，“活儿”的质量来自于你接手的项目之前和之后的差别。做好活儿是匠人应有的职业心态。想通这一点，内心自然少一些纠结，才会对自己对项目的贡献度有客观的认识，不会感觉被项目所绑架。 做一名多福的匠人，拥有了金刚钻、就不怕拦不到瓷器活儿。但对于人的成长来说，如果说“项目”重要但不关键，那么什么才是关键呢？这个话题还会在接下来的“伯乐与千里马”这篇中给出答案。 【若干年后】 现在，让我们回过头回答一下“青春饭”的问题。在“青春饭”小节中提到，“程序员到三十岁之后需要转行或者转管理吗？” 上文提到，工业化生产的四个领域，1，创意，2，生产线，3，高级技工，4，技术管理。Web前端技术也是如此，可以在这四个领域找到各自的归宿。 第一，“创意“ 即和产品需求越走越近，拥有良好的产品感，对产品需求、设计交互把握准确，能够用适当的技术方案推动产品用户体验，属于“架构师”的范畴，因为职能更加靠前，偏“出主意”型的。这种人更贴近用户，需要活跃的思维、广阔眼界、厚实的项目经验。更多的影响产品体验方面的决策。 第二，“生产线“ 即前端基础设施建设，优化前端开发流程，开发工具，包括开发环境、打包上线自动化、和各种监控平台和数据收集等，属于“技术支持”的范畴，相比于很多企业粗犷难用的平台工具，前端技术方面的基础设施建设基础还需更加夯实，因为这是高效生产的基本保证。 第三，“高级技工“ 即高级前端开发工程师，专职做项目，将产品做精做透，用代码将产品用户体验推向极致，偏“实战”型的，是项目的中坚力量，直接产出成果，影响产品效益。属于项目里的“资深”。 第四，“技术管理“ 即做技术经理，这才是多数人所理解的“管理”，其实就是带团队、靠团队拿成果。这类人具有敏感的技术情结，在技术风潮中把握方向，能够指导培训新人，为各个业务输出前端人才，偏“教练”型的，促进新技术对业务的影响。并有意识的开辟新的技术领域。 可见，转管理可不是想当然，也不是所谓做项目变资深了就能转管理，转了也不一定能做好。根据“彼得原理”，即人总是倾向于晋升到他所不能胜任的岗位，这时就又陷入“帕金森”定律所隐喻的恶性循环之中，直到你带的团队整个垮掉。 所以，转管理应当是一件非常慎重的事情，不是所谓程序员混不下去就转管理这么简单。但不管怎样，有一件事情是需要尤其要想清楚，即，转了管理，技术就丢了吗？我们在第七日“伯乐与千里马”中再深入聊聊这个事儿。 第七日，伯乐与千里马 【师兄们的抉择1】 千里马常有，而伯乐不常有。——韩愈，“马说”。 一个人这辈子能遇到一个好师兄是一种缘分，可遇不可求。很多人工作中的幸福感似乎也源自这种被认同，被师兄的了解和认同，有人能直言不讳的指出你的不足，帮你发现机会，并将最适合你做的事情分配给你，这是莫大的幸运，但如此幸运的人十之一二，大多数人因为缺少伯乐的提点，渐渐辱于“奴隶人之手“，潜力渐失，毁于中庸。 在前端技术领域，这种情况很普遍也很特殊，当然有很多客观原因。即前端技术进入公众视野时间不长，有实力的伯乐更加是凤毛麟角。更何况，Web前端技术还有着一些江湖气，知识点过于琐碎，技术价值观的博弈也难分伯仲，即全局的系统的知识结构并未成体系，这些因素也客观上影响了“正统“前端技术的沉淀，奇技淫巧被滥用，前端技术知识的传承也过于泛泛，新人难看清时局把握主次，加之业务上的压力，未免过早导致技术动作变形。而这些问题也无法全赖自己全盘消化，若有人指点迷津，情况要好上万倍。因此，前端技术领域，为自己觅得一个靠谱的师兄，重要性要盖过项目、团队、公司、甚至薪水。 这也是上文所说的“项目不重要，师兄才重要“的原因。说到这里就有一个问题，每个人都问下自己，你是想当师弟呢还是想当师兄呢？当师兄有什么好处呢？ 没错，很多师兄都是被师兄，甚至没有做好当师兄的准备，更进一步说，不少经理人也都是“被经理人“，没有做好准备就被推到了管理岗位。带人是耗精力的，师兄要做很多思想斗争才舍得把这些宝贵的精力放在那些菜鸟身上，这不是一个技术问题，而是一个道德问题。要记住，没有谁应该无缘无故把自己所掌握技能给你倾囊相授，如此皆命也。读到这里，作为菜鸟，作为学徒，作为新人，作为师弟，你做到对这份命运的足够尊重了吗？ 尊师重教的传统美德并没有在技术领域得以很好的延续。也正因为此，人才梯队难建立起来，但对于师兄来说，却是有更多机遇的。 【师兄们的抉择2】 作为师兄，不管是主动还是被动，肯定会想当师兄对我有什么提升？对于初次做师兄的人来说，最大的提升在于两方面，1，任务分解，2，问题分析。 第一，任务分解，作为师兄要给师弟派分任务，就涉及到任务分解，分解这事儿往低了说，就是派活，往高了说，其实就是做“架构”，比如一个页面，按照什么思路进行模块划分，模块划分是否适合单人开发，如何控制共用样式和共用脚本，我需要为他提供什么接口，如何控制他的代码并入整个页面时不会影响整体页面代码的熵值，这些都是实打实的“架构“应该包含的问题，而从小页面开始就做这种锻炼，做的多了，“架构感”自然就形成了。 第二，问题分析，在之前自己写代码都是单打独斗，什么都是用代码解决问题，但一旦涉及协作，就要强迫自己分析问题，或者说给徒弟分析问题，告诉他应当用什么方法来解决问题，当说到“方法”时，脑子里定形成了一个方案，按照这个方案路子走一定能解决问题。分析问题比写代码要更抽象、更高效，因为在脑子里构建方案要比写代码要快，思考也会更加缜密，当锻炼的多了，思考越来越快，代码的草稿也很快就在脑海中形成了，这也是我们说为什么很多人不写代码但编码思路和水平都很高的原因。 这些工作方法对了，积累多了，就是提高。对于技术经理人来说，也是同样的道理。所以，就像在第五日的“得与失”部分提到的那样，转身师兄、变身管理并不意味着“失“掉技术饭碗，而是一种进步。 【做自己的伯乐】 那么，在前端技术领域里什么样的人才算千里马，其实人人都是千里马，人人都可以发掘自己的潜力，如果上面的文字你能读懂，能认可，这种自我发掘已经开始了，没有一个好伯乐又何妨呢？做一个勤快的小码农，少一些势利的纷争，很快会发现，自己才是最好的伯乐。 但这并不是说，他人对自己的观点不重要，有时甚至要综合各种声音，所以，多找身边的大牛们聊聊天，多找你的师兄和主管，不管他们给你的建议是多么形而上，总有一些声音对你是有益的，多收集，有好处。 第八日，做地球上最牛的UED 【谁推动了历史前进，英雄？还是人民？】 “做地球上最牛的UED！”，这是淘宝UED创立之初的口号，现在被渐渐淡忘了，因为微博上的一些讨论，又想起了这份曾经美好的初衷。玉伯也感叹道：“这愿景曾吸引了多少好汉前往投奔呀。只可惜短短几年间，这愿景好像越来越远了”。问题是，要做好一个团队，靠的是个人、还是整体？愿景是越来越远了吗？ 是谁推动了历史的前进，是英雄？还是人民？微观来看，是英雄，宏观来看，是人民。再放大了看，是互联网大潮之崛起推动了前端技术的进步，时势需要UED、需要用户体验。 所以，UED团队的创立发展受这些积极的外因影响，赶上了好时候，成员也跟着沾光。然而，我并不关心这个口号，我只关心体制内的关键人物，那些带动整个团队水涨船高的人们。往往我们发现，某些人的高度代表了整个团队的高度，个体的影响力代表了整个团队的影响力，某个人的水平代表了整个团队的水平。支付宝、淘宝、腾讯、百度、盛大，都是如此。而我们作为普通的个体，正是要励志成为这种人，成为真真用技术推动用户体验前进的尖刀人物。 这时我想起了很多人在知乎上的问题，关于跳槽、关于转行、关于创业、关于各种UED团队。我想，读得懂我上面的文字，你心理也许会有自己的答案。 【归宿】 最后，还有一个不得不说的问题，即归属问题，前端开发应当归属于UED还是技术部门？应当说，当前Web前端技术的价值体现在“用户体验“上。是用户体验这块阵地最后一道坎。也就是说，前端工程师应当重点考虑我所作的页面的感官体验。这是需要一些灵感和感性的，应当看到帅气优雅的界面会心有所动、或者实现一款精巧的小组件时萌生一阵快意。这种所见即所得的美妙编程体验正是其他后端工程师无法体验到的。因此，这种精确到像素级的精工雕琢虽然不直接决定产品生死，但却是提升产品品味和时尚感的要素。物质越来越丰富的今天，大众的更高诉求不就是品味和时尚吗？ 如果将前端归到技术部门，一方面和“设计“离的更远，代码写的规规矩矩但渐缺少了灵性，另一方面作为工程师又缺少计算机专业课的功底，才真正丧失了优势所在，如果有一天，前端工程师的平均水平足够高，清一色的计算机科班出身，似乎更合适归入到技术部门。所以，Web前端工程师是“工程师“，需要科学严谨的编程能力，但身处UED所应当具备的美感和灵性是万不可被剥夺去的。 还有一点，Web前端工程师作为UED之中最具实践精神和逻辑思维的工种，是能够将技术对设计的影响发挥到最大，可以催生出大量的创造和革新的，这一点也是传统后端工程师所不具备的。 第九日，前端技术体系 现在越来越感觉到前端技术需要成体系的积累，一方面可以规范我们的前端技术培训，另一方面，作为知识线索为新人做指引，省的走弯路，避免陷入奇技淫巧的深坑之中不能自拔。 之前我整理了一下“前端技术知识结构”，罗列的比较散，但也基本表述清楚了我的观点。今年上半年也在整个研发中心组织了一次前端技术培训，对于前端技术的演化规律也有过整理，都放在了这个ppt中，希望对大家有所帮助。 概观国内前端技术界，其实我不认为和国外顶尖的前端技术有多少年差别，甚至很多方面都走在了他们前面，比如对IE6暴力式的兼容，以及各种外壳浏览器的风靡（呵呵，开玩笑哈）。唯一的美中不足是国外顶尖的前端技术难第一时间就在国内普及，可能是两方面原因，一是多数人英文底子很差，这可是个大问题啊。二是国内前端技术方面高质量的译文图书实在是少的可怜。那么…… 接下来的最后一日，想了想还是留给答疑吧，一方面很多人读到这里肯定满肚子问题，我收集下，争取及时回复大家。另一方面，万一上面的话的有得罪人的地方，还好留有余地来补救，哈哈。 ps：一直很喜欢“神曲”的插图，从“天堂篇”里摘出一张作为封面吧，呵呵。第十日：QA 本文转自挨踢前端博客园博客，原文链接http://www.cnblogs.com/duanhuajian/p/3142634.html如需转载请自行联系原作者 @挨踢前端
2017-11-28
优秀的个人博客,低调大师

web app开发技巧总结 （share）

转自http://hi.baidu.com/kuntakinte/item/ca92d6e5edae9fc0bbf37d08） 自Iphone和Android这两个牛逼的手机操作系统发布以来，在互联网界从此就多了一个新的名词-WebApp(意为基于WEB形式的应用程序，运行在高端的移动终端设备)。 开发者们都知道在高端智能手机系统中有两种应用程序：一种是基于本地（操作系统）运行的APP；一种是基于高端机的浏览器运行的WebApp，本文将主要讲解后者。 WebApp与NativeApp有何区别呢？ NativeApp： 1、开发成本非常大。 一般使用的开发语言为JAVA、C++、Objective-C。 2、更新体验较差、同时也比较麻烦 每一次发布新的版本，都需要做版本打包，且需要用户手动更新（有些应用程序即使不需要用户手动更新，但是也需要有一个恶心的提示）。 3、非常酷 因为nativeapp可以调用IOS中的UI控件以UI方法，它可以实现WebApp无法实现的一些非常酷的交互效果 4、Nativeapp是被Apple认可的 Nativeapp可以被Apple认可为一款可信任的独立软件，可以放在AppleStroe出售，但是Webapp却不行。 WebApp： 1、开发成本较低 使用web开发技术就可以轻松的完成webapp的开发 2、升级较简单 升级不需要通知用户，在服务端更新文件即可，用户完全没有感觉 3、维护比较轻松 和一般的web一样，维护比较简单，它其实就是一个站点 Webapp说白了就是一个针对Iphone、Android优化后的web站点，它使用的技术无非就是HTML或HTML5、CSS3、JavaScript，服务端技术JAVA、PHP、ASP。 当然，因为这些高端智能手机（Iphone、Android）的内置浏览器都是基于webkit内核的，所以在开发WEBAPP时，多数都是使用HTML5和CSS3技术做UI布局。当使用HTML5和CSS3l做UI时，若还是遵循着一般web开发中使用HTML4和CSS2那样的开发方式的话，这也就失去了WEBAPP的本质意义了，且有些效果也无法实现的，所以在此又回到了我们的主题–webapp的布局方式和技术。 在此所说的移动平台前端开发是指针对高端智能手机（如Iphone、Android）做站点适配也就是WebApp，并非是针对普通手机开发Wap2.0，所以在阅读本篇文章以前，你需要对webkit内核的浏览器有一定的了解，你需要对HTML5和CSS3有一定的了解。如果你已经对此有所了解，那现在就开始往下阅读吧…… 1、首先我们来看看webkit内核中的一些私有的meta标签，这些meta标签在开发webapp时起到非常重要的作用 1<metacontent=”width=device-width,initial-scale=1.0,maximum-scale=1.0,user-scalable=0;”name=”viewport”/> 2<metacontent=”yes”name=”apple-mobile-web-app-capable”/> 3<metacontent=”black”name=”apple-mobile-web-app-status-bar-style”/> 4<metacontent=”telephone=no”name=”format-detection”/> 第一个meta标签表示：强制让文档的宽度与设备的宽度保持1:1，并且文档最大的宽度比例是1.0，且不允许用户点击屏幕放大浏览； 第二个meta标签是iphone设备中的safari私有meta标签，它表示：允许全屏模式浏览； 第三个meta标签也是iphone的私有标签，它指定的iphone中safari顶端的状态条的样式； 第四个meta标签表示：告诉设备忽略将页面中的数字识别为电话号码 2、HTML5标签的使用 在开始编写webapp时，哥建议前端工程师使用HTML5，而放弃HTML4，因为HTML5可以实现一些HTML4中无法实现的丰富的WEB应用程序的体验，可以减少开发者很多的工作量，当然了你决定使用HTML5前，一定要对此非常熟悉，要知道HTML5的新标签的作用。比如定义一块内容或文章区域可使用section标签，定义导航条或选项卡可以直接使用nav标签等等。 3、放弃CSSfloat属性 在项目开发过程中可以会遇到内容排列排列显示的布局(见下图)，假如你遇见这样的视觉稿，哥建议你放弃float，可以直接使用display:block; 4、利用CSS3边框背景属性 这个按钮有圆角效果，有内发光效果还有高光效果，这样的按钮使用CSS3写是无法写出来的，当然圆角可以使用CSS3来写，但高光和内发光却无法使用CSS3编写，这个时候你不妨使用-webkit-border-image来定义这个按钮的样式。-webkit-border-image就个很复杂的样式属性。 5、块级化a标签 请保证将每条数据都放在一个a标签中，为何这样做？因为在触控手机上，为提升用户体验，尽可能的保证用户的可点击区域较大。 6、自适应布局模式 在编写CSS时，我不建议前端工程师把容器（不管是外层容器还是内层）的宽度定死。为达到适配各种手持设备，我建议前端工程师使用自适应布局模式（支付宝采用了自适应布局模式），因为这样做可以让你的页面在ipad、itouch、ipod、iphone、android、websafarik、chrome都能够正常的显示，你无需再次考虑设备的分辨率。 7、学会使用webkit-box 上一节，我们说过自适应布局模式，有些同学可能会问：如何在移动设备上做到完全自适应呢？很感谢webkit为display属性提供了一个webkit-box的值，它可以帮助前端工程师做到盒子模型灵活控制。 8、如何去除Android平台中对邮箱地址的识别 看过iOSwebappAPI的同学都知道iOS提供了一个meta标签:用于禁用iOS对页面中电话号码的自动识别。在iOS中是不自动识别邮件地址的，但在Android平台，它会自动检测邮件地址，当用户touch到这个邮件地址时，Android会弹出一个框提示用户发送邮件，如果你不想Android自动识别页面中的邮件地址，你不妨加上这样一句meta标签在head中1<metacontent=”email=no”name=”format-detection”/> 9、如何去除iOS和Android中的输入URL的控件条 你的老板或者PD或者交互设计师可能会要求你：能否让我们的webapp更加像nativeapp，我不想让用户看见那个输入url的控件条？ 答案是可以做到的。我们可以利用一句简单的javascript代码来实现这个效果 1setTimeout(scrollTo,0,0,0); 请注意，这句代码必须放在window.onload里才能够正常的工作，而且你的当前文档的内容高度必须是高于窗口的高度时，这句代码才能有效的执行。 10、如何禁止用户旋转设备 我曾经也想禁止用户旋转设备，也想实现像某些客户端那样：只能在肖像模式或景观模式下才能正常运行。但现在我可以很负责任的告诉你：别想了!在移动版的webkit中做不到！ 至少ApplewebappAPI已经说到了：我们为了让用户在safari中正常的浏览网页，我们必须保证用户的设备处于任何一个方位时，safari都能够正常的显示网页内容（也就是自适应），所以我们禁止开发者阻止浏览器的orientationchange事件，看来苹果公司的出发点是正确的，苹果确实不是一般的苹果。 iOS已经禁止开发者阻止orientationchange事件，那Android呢？对不起，我没有找到任何资料说Android禁止开发者阻止浏览器orientationchange事件，但是在Android平台，确实也是阻止不了的。 11、如何检测用户是通过主屏启动你的webapp 看过ApplewebappAPI的同学都知道iOS为safari提供了一个将当前页面添加主屏的功能，按下iphoneipodipodtouch底部工具中的小加号，或者ipad顶部左侧的小加号，就可以将当前的页面添加到设备的主屏，在设备的主屏会自动增加一个当前页面的启动图标，点击该启动图标就可以快速、便捷的启动你的webapp。从主屏启动的webapp和浏览器访问你的webapp最大的区别是它清除了浏览器上方和下方的工具条，这样你的webapp就更加像是nativeapp了，还有一个区别是window对像中的navigator子对象的一个standalone属性。iOS中浏览器直接访问站点时，navigator.standalone为false,从主屏启动webapp时，navigator.standalone为true，我们可以通过navigator.standalone这个属性获知用户当前是否是从主屏访问我们的webapp的。在Android中从来没有添加到主屏这回事！ 12、如何关闭iOS中键盘自动大写 我们知道在iOS中，当虚拟键盘弹出时，默认情况下键盘是开启首字母大写的功能的，根据某些业务场景，可能我们需要关闭这个功能，移动版本webkit为input元素提供了autocapitalize属性，通过指定autocapitalize=”off”来关闭键盘默认首字母大写。 13、iOS中如何彻底禁止用户在新窗口打开页面 有时我们可能需要禁止用户在新窗口打开页面，我们可以使用a标签的target=”_self“来指定用户在新窗口打开，或者target属性保持空，但是你会发现iOS的用户在这个链接的上方长按3秒钟后，iOS会弹出一个列表按钮，用户通过这些按钮仍然可以在新窗口打开页面，这样的话，开发者指定的target属性就失效了，但是可以通过指定当前元素的-webkit-touch-callout样式属性为none来禁止iOS弹出这些按钮。这个技巧仅适用iOS对于Android平台则无效。 14、iOS中如何禁止用户保存图片＼复制图片 我们在第13条技巧中提到元素的-webkit-touch-callout属性，同样为一个img标签指定-webkit-touch-callout为none也会禁止设备弹出列表按钮，这样用户就无法保存＼复制你的图片了。 15、iOS中如何禁止用户选中文字 我们通过指定文字标签的-webkit-user-select属性为none便可以禁止iOS用户选中文字。 16、iOS中如何获取滚动条的值 桌面浏览器中想要获取滚动条的值是通过document.scrollTop和document.scrollLeft得到的，但在iOS中你会发现这两个属性是未定义的，为什么呢？因为在iOS中没有滚动条的概念，在Android中通过这两个属性可以正常获取到滚动条的值，那么在iOS中我们该如何获取滚动条的值呢？ 通过window.scrollY和window.scrollX我们可以得到当前窗口的y轴和x轴滚动条的值。 17、如何解决盒子边框溢出 当你指定了一个块级元素时，并且为其定义了边框，设置了其宽度为100％。在移动设备开发过程中我们通常会对文本框定义为宽度100％，将其定义为块级元素以实现全屏自适应的样式，但此时你会发现，该元素的边框(左右)各1个像素会溢了文档，导致出现横向滚动条，为解决这一问题，我们可以为其添加一个特殊的样式-webkit-box-sizing:border-box;用来指定该盒子的大小包括边框的宽度。 18、如何解决Android2.0以下平台中圆角的问题 如果大家够细心的话，在做wap站点开发时，大家应该会发现android2.0以下的平台中问题特别的多，比如说边框圆角这个问题吧。 在对一个元素定义圆角时，为完全兼容android2.0以下的平台，我们必须要按照以下技巧来定义边框圆角： 1＼-webkit这个前缀必须要加上（在iOS中，你可以不加，但android中一定要加）； 2＼如果对针对边框做样式定义，比如border:1pxsolid#000;那么-webkit-border-radius这属性必须要出现在border属性后。 3＼假如我们有这样的视觉元素，左上角和右上角是圆角时，我们必须要先定义全局的(4个角的圆角值)-webkit-border-radius:5px;然后再依次的覆盖左下角和右下角，-webkit-border-bottom-left-radius:0;-webkit-border-bottom-right-border:0;否则在android2.0以下的平台中将全部显示直角，还有记住！-webkit这个前缀一定要加上！ 19、如何解决android平台中页面无法自适应 虽然你的html和css都是完全自适应的，但有一天如果你发现你的页面在android中显示的并不是自适应的时候，首先请你确认你的head标签中是否包含以下meta标签： 1<metaname=”viewport”content=”width=device-width,initial-scale=1.0,maximum-scale=1.0,user-scalable=0;”/> 如果有的话，那请你再仔细的看清楚有没有这个属性的值width=device-width，如果没有请立即加上吧！ 20、如何解决iOS4.3版本中safari对页面中5位数字的自动识别和自动添加样式 新的iOS系统也就是4.3版本，升级后对safari造成了一个bug：即使你添加了如下的meta标签，safari仍然会对页面中的5位连续的数字进行自动识别，并且将其重新渲染样式，也就是说你的css对该标签是无效的。 1<metaname=”format-detection”content=”telphone=no”/> 我们可以用一个比较龌龊的办法来解决。比如说支付宝wap站点中显示金额的标签，我们都做了如下改写： 1<buttonclass=”t-balance”style=”background:none;padding:0;border:0;”>95009.00</button>元 本文转自挨踢前端博客园博客，原文链接http://www.cnblogs.com/duanhuajian/archive/2012/11/09/2763171.html如需转载请自行联系原作者 @挨踢前端
2017-11-15
优秀的个人博客,低调大师

Authing Share｜理解 SAML2 协议

SAML2 综述 安全断言标记语言（英语：Security Assertion Markup Language，简称SAML，发音 sam-el）是一个基于 XML 的开源标准数据格式，它在当事方之间交换身份验证和授权数据，尤其是在身份提供者和服务提供者之间交换。SAML2.0 可以实现基于网络跨域的单点登录（SSO）， 以便于减少向一个用户分发多个身份验证令牌的管理开销。 SAML 主体 在 SAML 协议中，涉及两个主体： Service Provider 服务提供方，简称 SP。什么是服务提供方？例如：阿里云控制台、腾讯云控制台、AWS 控制台这些都是服务提供方。 Identity Provider 身份提供方，简称 IdP。什么是身份提供方？Authing 可以作为身份提供方，身份提供方能够向 SP 发送身份断言，所谓身份断言就是由 Authing 签发的，可以标识某个人身份的 Token，只不过，在 SAML 协议中，这个 Token 的格式是 XML 形式的。还有一些其他的身份提供方，例如 Okta、SSOCircle、Auth0，他们都可以向 SP 返回身份断言。 两个主体通过用户的浏览器进行信息交换。方式上，SP 可以返回带参数的重定向 HTTP 响应，让用户立刻通过参数将信息发给 IdP。而 IdP 会返回一个表单，同时还有一段立即提交表单的 JS 代码，从而让用户立刻将信息发给 SP。 总结一下，SP 提供服务，需要知道用户的身份，就需要向 IdP 询问。IdP 知道用户的身份，当用户在 IdP 登录成功，IdP 就将用户的身份以 SAML 断言的形式发给 SP。SP 信任 IdP 发来的身份断言，从而赋予该用户在 SP 的相关权限。 SAML Request 当用户的身份无法鉴定时，SP 会向 IdP 发送 SAML Request 信息（通过浏览器发送），请求 IdP 来鉴定用户身份。 由阿里云控制台发起一次 SAML Request 的形式是这样的： GEThttps://core.authing.cn/v2/api/saml-idp/5e10927e4ecfd464fb4edaf6?SAMLRequest=fZJLT%2BMwFIX3%2FIrI%2B7yct9Wk6kyFQGJERQKL2RnnJnWV2Blfp2L%2BPaGlDLOApaV7vnN0jlfrl3FwjmBQalWS0AuIA0roVqq%2BJI%2FNtZuTdXW1Qj4OdGKb2e7VA%2FyZAa2zQQRjF91PrXAewdRgjlLA48NdSfbWTsh8H2WvpPL4IP%2FOyhN69N9Qfl3fE2e7UKTi9mR9EQhtwOOLz5LAE8o%2FUp9P8qRyZTv5CYRBQTOIQXRtnMbdcwwt71LiXGsj4JSwJB0fEIhzuy0Jp9AXgvaHgwzzPA%2FjfXagbRYlebeP%2BmI5wh1HlEf4J0Oc4Vah5cqWhAY0cIPCpXkTRiwoWJJ5eZH%2BJs7OaKuFHn5IdS5sNoppjhKZ4iMgs4LVm193jHoBez4fIbtpmp27u68b4jxdiqdvxS9TKGTnqr9nTe%2FGpDovw06JzWfC9wB%2B2Y5UXy8VRlmcpkWUpUlGY5p8TLfyP7tW78%2F%2Fv0f1Cg%3D%3D (提示：代码可向右滑动) SAMLRequest 参数通过query在 URL 中发送给 IdP，SAMLRequest 的内容如下： fZJLT+MwFIX3/IrI+7yct9Wk6kyFQGJERQKL2RnnJnWV2Blfp2L+PaGlDLOApaV7vnN0jlfrl3FwjmBQalWS0AuIA0roVqq+JI/NtZuTdXW1Qj4OdGKb2e7VA/yZAa2zQQRjF91PrXAewdRgjlLA48NdSfbWTsh8H2WvpPL4IP/OyhN69N9Qfl3fE2e7UKTi9mR9EQhtwOOLz5LAE8o/Up9P8qRyZTv5CYRBQTOIQXRtnMbdcwwt71LiXGsj4JSwJB0fEIhzuy0Jp9AXgvaHgwzzPA/jfXagbRYlebeP+mI5wh1HlEf4J0Oc4Vah5cqWhAY0cIPCpXkTRiwoWJJ5eZH+Js7OaKuFHn5IdS5sNoppjhKZ4iMgs4LVm193jHoBez4fIbtpmp27u68b4jxdiqdvxS9TKGTnqr9nTe/GpDovw06JzWfC9wB+2Y5UXy8VRlmcpkWUpUlGY5p8TLfyP7tW78//v0f1Cg== (提示：代码可向右滑动) base64 decode + inflate 解码后 （https://www.samltool.com/decode.php） <?xmlversion="1.0"encoding="UTF-8"?> <saml2p:AuthnRequestAssertionConsumerServiceURL="https://signin.aliyun.com/saml/SSO"Destination="https://core.authing.cn/v2/api/saml-idp/5e10927e4ecfd464fb4edaf6"ForceAuthn="false"ID="a2eg9c2gjji188814h7j2d7358fh3g9"IsPassive="false"IssueInstant="2020-09-28T13:09:57.896Z"ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"Version="2.0"xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"><saml2:Issuerxmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://signin.aliyun.com/1374669376572425/saml/SSO (提示：代码可向右滑动) SAML Response IdP 收到 SAML Request 后，会弹出登录框对用户身份进行认证： 当用户在 IdP 完成登录后，SAML IdP 将用户身份断言发送给 SP（放在表单中，通过浏览器 POST 请求发送）。SAML IdP 的响应内容如下： <formid="saml-form"method="post"action="https://signin.aliyun.com/saml/SSO"autocomplete="off"><inputtype="hidden"name="SAMLResponse"id="saml-response"value="PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iIElEPSJfNjJiMTc3YzEtYTkxOS00MmY2LTk1ODYtNDdmMTNiNzEwODFmIiBWZXJzaW9uPSIyLjAiIElzc3VlSW5zdGFudD0iMjAyMC0wOS0yOFQxMzozMDozMS43ODhaIiBEZXN0aW5hdGlvbj0iaHR0cHM6Ly9zaWduaW4uYWxpeXVuLmNvbS9zYW1sL1NTTyIgSW5SZXNwb25zZVRvPSJhNDlmOGVkaTMxY2owYTJhNDU5ZzAzMzFjM2Q5YzEwIj4KICA8c2FtbDpJc3N1ZXI+aHR0cHM6Ly8yMG5xdWx2b3FwYnAuYXV0aGluZy5jbjwvc2FtbDpJc3N1ZXI+CiAgPHNhbWxwOlN0YXR1cz4KICAgIDxzYW1scDpTdGF0dXNDb2RlIFZhbHVlPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6c3RhdHVzOlN1Y2Nlc3MiLz4KICA8L3NhbWxwOlN0YXR1cz4KICA8c2FtbDpBc3NlcnRpb24geG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSIgeG1sbnM6eHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIiB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIiBJRD0iX2ZhZTk1YjQ3LWNiZjMtNGEyMC1hZGQwLTk5ZDg1NmI0MTI0ZSIgVmVyc2lvbj0iMi4wIiBJc3N1ZUluc3RhbnQ9IjIwMjAtMDktMjhUMTM6MzA6MzEuNzg4WiI+CiAgICA8c2FtbDpJc3N1ZXI+aHR0cHM6Ly8yMG5xdWx2b3FwYnAuYXV0aGluZy5jbjwvc2FtbDpJc3N1ZXI+PGRzOlNpZ25hdHVyZSB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+PGRzOlNpZ25lZEluZm8+PGRzOkNhbm9uaWNhbGl6YXRpb25NZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzEwL3htbC1leGMtYzE0biMiLz48ZHM6U2lnbmF0dXJlTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI3JzYS1zaGExIi8+PGRzOlJlZmVyZW5jZSBVUkk9IiNfZmFlOTViNDctY2JmMy00YTIwLWFkZDAtOTlkODU2YjQxMjRlIj48ZHM6VHJhbnNmb3Jtcz48ZHM6VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3BlZC1zaWduYXR1cmUiLz48ZHM6VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+PC9kczpUcmFuc2Zvcm1zPjxkczpEaWdlc3RNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjc2hhMSIvPjxkczpEaWdlc3RWYWx1ZT4vb2w2bEMxaitzbWRvbmw0OCtsSlR6VWVxbnc9PC9kczpEaWdlc3RWYWx1ZT48L2RzOlJlZmVyZW5jZT48L2RzOlNpZ25lZEluZm8+PGRzOlNpZ25hdHVyZVZhbHVlPmF3emNFMGRwOEJ6VFc0YjRQRmFSWDdOS09DOTViTHFPblBlQUtJL0NzRGZHYUpkbXpDSzBmVmxpeitlNlh6Qmx1S2ZCcFF0clFvbktsN2sydlZOYVBGeDlQcFNWendLOTFITEd2WVEwcUIzNnVBNEhGdm0vM00zMURMM1pSRlBScTY4WmFWQUc2bE1WZDBZYmlJblZ2OUZXd3NpKzZqRXBGK1BSbG1rb3FBST08L2RzOlNpZ25hdHVyZVZhbHVlPjxkczpLZXlJbmZvPjxkczpYNTA5RGF0YT48ZHM6WDUwOUNlcnRpZmljYXRlPk1JSUNRakNDQWF1Z0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRMEZBREErTVFzd0NRWURWUVFHRXdKMWN6RVNNQkFHQTFVRUNBd0o1THFMNWE2ZTVMaUtNUXd3Q2dZRFZRUUtEQU56YzNNeERUQUxCZ05WQkFNTUJITnpjM013SGhjTk1qQXdNVEF6TVRNeE9ERTBXaGNOTWpFd01UQXlNVE14T0RFMFdqQStNUXN3Q1FZRFZRUUdFd0oxY3pFU01CQUdBMVVFQ0F3SjVMcUw1YTZlNUxpS01Rd3dDZ1lEVlFRS0RBTnpjM014RFRBTEJnTlZCQU1NQkhOemMzTXdnWjh3RFFZSktvWklodmNOQVFFQkJRQURnWTBBTUlHSkFvR0JBTU5XbE1rNEwrVGNXd3lkOXBsVFBMaEhML1VNQ1BHSmd2NVZwOHZhQXA0V01zR3R3T0xJMVVOV2NjSXFNZVUwS2FzSnFyS3hIWXZxOUp6Wmg0ZmZ0Rm1vd0J6MzZ2ejBlSVVzUDVQS3ZGVUxrQzF2anJkbitRSlhiSjUxYWxaWktmUGdsMUhJOHc2bGgxMmFXVGphS1ErS2VtSXR0cUxxSmdMV09ZQVhQSXN6QWdNQkFBR2pVREJPTUIwR0ExVWREZ1FXQkJUVDEwNGhWWVZuUHBnN2FGckRpWFBTaGJ0eFVUQWZCZ05WSFNNRUdEQVdnQlRUMTA0aFZZVm5QcGc3YUZyRGlYUFNoYnR4VVRBTUJnTlZIUk1FQlRBREFRSC9NQTBHQ1NxR1NJYjNEUUVCRFFVQUE0R0JBQjYrMXhLN0dNSmE1TTZVamcvd2Q0RXR3eThOZFRGNnlwU3FOMzZCZDVPZFBtd1U5SHpEdUdqS2kzWndvb1BJR1JCOHBpTHNLazExTTRJaEFGNEMyUi9Kc3ZWWXdXT1lnb2pXNEgxaFI1d2syam43cGx0V3FSUGRmWkJsMFlmc0R5c1VQN2s4L01jaE9XWDdXaWZOeHBlM0dkU0tOMTdDa2RSakw5MjRiVjBsPC9kczpYNTA5Q2VydGlmaWNhdGU+PC9kczpYNTA5RGF0YT48L2RzOktleUluZm8+PC9kczpTaWduYXR1cmU+CiAgICA8c2FtbDpTdWJqZWN0PgogICAgICA8c2FtbDpOYW1lSUQgRm9ybWF0PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoxLjE6bmFtZWlkLWZvcm1hdDp1bnNwZWNpZmllZCI+eWV6dXdlaUBhdXRoaW5nLm9uYWxpeXVuLmNvbTwvc2FtbDpOYW1lSUQ+CiAgICAgIDxzYW1sOlN1YmplY3RDb25maXJtYXRpb24gTWV0aG9kPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6Y206YmVhcmVyIj4KICAgICAgICA8c2FtbDpTdWJqZWN0Q29uZmlybWF0aW9uRGF0YSBOb3RPbk9yQWZ0ZXI9IjIwMjAtMDktMjhUMTQ6MzA6MzEuNzg4WiIgUmVjaXBpZW50PSJodHRwczovL3NpZ25pbi5hbGl5dW4uY29tL3NhbWwvU1NPIiBJblJlc3BvbnNlVG89ImE0OWY4ZWRpMzFjajBhMmE0NTlnMDMzMWMzZDljMTAiLz4KICAgICAgPC9zYW1sOlN1YmplY3RDb25maXJtYXRpb24+CiAgICA8L3NhbWw6U3ViamVjdD4KICAgIDxzYW1sOkNvbmRpdGlvbnMgTm90QmVmb3JlPSIyMDIwLTA5LTI4VDEzOjMwOjMxLjc4OFoiIE5vdE9uT3JBZnRlcj0iMjAyMC0wOS0yOFQxNDozMDozMS43ODhaIj4KICAgICAgPHNhbWw6QXVkaWVuY2VSZXN0cmljdGlvbj4KICAgICAgICA8c2FtbDpBdWRpZW5jZT5odHRwczovL3NpZ25pbi5hbGl5dW4uY29tLzEzNzQ2NjkzNzY1NzI0MjUvc2FtbC9TU088L3NhbWw6QXVkaWVuY2U+CiAgICAgIDwvc2FtbDpBdWRpZW5jZVJlc3RyaWN0aW9uPgogICAgPC9zYW1sOkNvbmRpdGlvbnM+PHNhbWw6QXV0aG5TdGF0ZW1lbnQgQXV0aG5JbnN0YW50PSIyMDIwLTA5LTI4VDEzOjMwOjMxLjg4OFoiIFNlc3Npb25JbmRleD0ib29ldW1jcTZlSGpkZHIxSDNGeXpvdTdDcy1PR1RzTmwiPjxzYW1sOkF1dGhuQ29udGV4dD48c2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZj51cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3Nlczp1bnNwZWNpZmllZDwvc2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZj48L3NhbWw6QXV0aG5Db250ZXh0Pjwvc2FtbDpBdXRoblN0YXRlbWVudD48c2FtbDpBdHRyaWJ1dGVTdGF0ZW1lbnQ+PHNhbWw6QXR0cmlidXRlIE5hbWU9ImVtYWlsIiBOYW1lRm9ybWF0PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXR0cm5hbWUtZm9ybWF0OmJhc2ljIj48c2FtbDpBdHRyaWJ1dGVWYWx1ZSB4bWxuczp4cz0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhzaTp0eXBlPSJ4czpzdHJpbmciPnllenV3ZWlAYXV0aGluZy5jbjwvc2FtbDpBdHRyaWJ1dGVWYWx1ZT48L3NhbWw6QXR0cmlidXRlPjxzYW1sOkF0dHJpYnV0ZSBOYW1lPSJuYW1lIiBOYW1lRm9ybWF0PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXR0cm5hbWUtZm9ybWF0OmJhc2ljIj48c2FtbDpBdHRyaWJ1dGVWYWx1ZSB4bWxuczp4cz0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhzaTp0eXBlPSJ4czpzdHJpbmciLz48L3NhbWw6QXR0cmlidXRlPjxzYW1sOkF0dHJpYnV0ZSBOYW1lPSJ1c2VybmFtZSIgTmFtZUZvcm1hdD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmF0dHJuYW1lLWZvcm1hdDpiYXNpYyI+PHNhbWw6QXR0cmlidXRlVmFsdWUgeG1sbnM6eHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4c2k6dHlwZT0ieHM6c3RyaW5nIj55ZXp1d2VpQGF1dGhpbmcuY248L3NhbWw6QXR0cmlidXRlVmFsdWU+PC9zYW1sOkF0dHJpYnV0ZT48c2FtbDpBdHRyaWJ1dGUgTmFtZT0icGhvbmUiIE5hbWVGb3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphdHRybmFtZS1mb3JtYXQ6YmFzaWMiPjxzYW1sOkF0dHJpYnV0ZVZhbHVlIHhtbG5zOnhzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSIgeHNpOnR5cGU9InhzOnN0cmluZyI+bnVsbDwvc2FtbDpBdHRyaWJ1dGVWYWx1ZT48L3NhbWw6QXR0cmlidXRlPjwvc2FtbDpBdHRyaWJ1dGVTdGF0ZW1lbnQ+PC9zYW1sOkFzc2VydGlvbj4KPC9zYW1scDpSZXNwb25zZT4="/><inputtype="hidden"name="RelayState"id="relay-state"value=""/><scripttype="text/javascript">(function(){document.forms[0].submit();})(); (提示：代码可向右滑动) 没有什么神秘的，就是一个 HTML form 表单和一段立即提交该表单的 JS 代码。其中的 SAML Response 信息如下： base64 decode + inflate 解码后 (https://www.samltool.com/decode.php) <samlp:Responsexmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"ID="_62b177c1-a919-42f6-9586-47f13b71081f"Version="2.0"IssueInstant="2020-09-28T13:30:31.788Z"Destination="https://signin.aliyun.com/saml/SSO"InResponseTo="a49f8edi31cj0a2a459g0331c3d9c10"><saml:Assertionxmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:xs="http://www.w3.org/2001/XMLSchema"xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"ID="_fae95b47-cbf3-4a20-add0-99d856b4124e"Version="2.0"IssueInstant="2020-09-28T13:30:31.788Z"><ds:Signaturexmlns:ds="http://www.w3.org/2000/09/xmldsig#"><saml:ConditionsNotBefore="2020-09-28T13:30:31.788Z"NotOnOrAfter="2020-09-28T14:30:31.788Z"><saml:AuthnStatementAuthnInstant="2020-09-28T13:30:31.888Z"SessionIndex="ooeumcq6eHjddr1H3Fyzou7Cs-OGTsNl"> (提示：代码可向右滑动) 这段内容就是用户的身份断言，也就是用户的 Token，只不过这个 Token 通过 XML 格式传递。 读到这里，你可能会对 SP、IdP 如何处理这些冗长的 XML 信息感到困惑。Authing 会解决这些繁琐的处理，而你只需关注如何正确地配置 Authing IdP，与 SAML SP 进行通信。 SAML2 流程 本文为读者讲述 SAML 中，SP、IdP、浏览器三个实体之间数据交互的流程。 SAML 协议中涉及到的主体 使用 SAML 协议进行身份认证时，涉及到以下三个主体 浏览器：SP 和 IdP 借助浏览器互相通信 SP：资源提供方 IdP：身份认证提供方 发起 SAML 登录到登录成功的整个过程 用户试图登录 SP 提供的应用。 SP 生成 SAML Request，通过浏览器重定向，向 IdP 发送 SAML Request。 IdP 解析 SAML Request 并将用户重定向到认证页面。 用户在认证页面完成登录。 IdP 生成 SAML Response，通过对浏览器重定向，向 SP 的 ACS 地址返回 SAML Response，其中包含 SAML Assertion 用于确定用户身份。 SP 对 SAML Response 的内容进行检验。 用户成功登录到 SP 提供的应用。 SP 与 IdP 之间通信方式 SP 与 IdP 之间的通信方式分为 HTTP Redirect Binding、HTTP POST Binding、HTTP Artifact Binding。每种方式在不同的阶段会用不同类型的 HTTP 与对方通信。 HTTP Redirect Binding SP 通过重定向 GET 请求把 SAML Request 发送到 IdP，IdP 通过立即提交的 Form 表单以 POST 请求的方式将 SAML Response 发到 SP。 HTTP POST Binding IdP 通过立即提交的 Form 表单以 POST 请求的方式将 SAML Request 发到 SP。IdP 通过立即提交的 Form 表单以 POST 请求的方式将 SAML Response 发到 SP。 HTTP Artifact Binding SP、IdP 双方只通过浏览器交换 SAML Request、SAML Response 的索引编号，收到编号后，在后端请求对方的 Artifact Resolution Service 接口来获取真正的请求实体内容。从而避免 SAML Request、SAML Response 暴露在前端。 如果你喜欢我们的内容，欢迎关注公众号「Authing 身份云」和访问我们的博客Authing 博客，更多有趣的内容等你来看～
2021-05-18
优秀的个人博客,低调大师

新浪微博AppKey大集合(share)

本文转自：http://blog.sina.com.cn/s/blog_9e1ea13a01017y3n.html ---------------------------------------------------------------------------------------- 新浪微博AppKey大集合：IPhone,IPAD,Android,Google,Baidu应有尽有： 如果有一天，你和新浪微博扯上关系，或者想玩转新浪微博的“来自”尾巴，那就到这来找吧： 小米手机 App Key：xiaomi App Secret：3MqAdNoRLHomm4AECoURl7gds1sUIjun Panda.memo App Key：31641035 App Secret：6a7c98c1eef2109622d0a08199a35bef 周博通微博管家 App Key：202088835 App Secret：9567e3782151dcfd1a9bd2dd099d957f Android平板客户端 App Key：2540340328 App Secret：886cfb4e61fad4e4e9ba9dee625284dd Google.Nexus App Key：1206405345 App Secret：fa6095e113cd28fde6e14c7b7145c5c5 Spring微博.Android App Key：1905839263 App Secret：36b51c6ebf2dd3e5361f80f6c4506267 Acer平板电脑 App Key：783190658 App Secret：7f63ae9eb3c1438e9f8932748ca8a341 iphone客户端 App Key：5786724301 App Secret：5Jao51NF1i5PDC91hhI3ID86ucoDtn4C app梦工厂微博 App Key：569452181 App Secret：bbd573c3052999adcd026cbf88ffbf8e FIT随享.iPhone版 App Key：31024382 App Secret：25c3e6b5763653d1e5b280884b45c51f iPad客户端 App Key：2849184197 App Secret：7338acf99a00412983f255767c7643d0 iPhone微博助手 App Key：2702428363 App Secret：82d9b7c386000b0de0711a20f146fa44 Weico.Android版 App Key：211160679 App Secret：63b64d531b98c2dbff2443816f274dd3 weico.iphone版 App Key：82966982 App Secret：72d4545a28a46a6f329c4f2b1e949e6a 联想乐Pad客户端 App Key：2440435914 App Secret：70dc2ae26780817793c9c533092171dd 摩托罗拉XOOM App Key：2190063733 App Secret：9222f119671ebf566b74220768014afd 三星GalaxyS App Key：3442868347 App Secret：07b27d2c098eda5eec681abdde832a51 android手机 App Key：android App Secret：5l0WXnhiY4pJ794KIJ7Rw5F45VXg9sjo 黑莓客户端 App Key：blackberry App Secret：ivij24vyWpP0zE0M03r56RL2u8nu0L66 三星GalaxyTab App Key：sxtab App Secret：6b2BhcdpiCdyZaIh4O3S1zHAUoC6Zpql 三星Android智能手机客户端 App Key：sxandroid App Secret：tYQO8S1RndCGgI3qNbiCEjG3cVaeOvq7 htc App Key：htc App Secret：ybQv5D6BC2bIOqYV2wCsIs0dX9vV0xIG SonyXpera App Key：x10 App Secret：rPVsSGvnz8erJ7w8sIICKEE70wQMRswU Moto App Key：me511 App Secret：5AgbUpV7fL2APXOkI04QnRhlGUdUlwy0 乐phone App Key：lp App Secret：5EmMeHqPOYsLSQ2zjrdXHoUhqtD4QYGx 魅族M9 App Key：meizu_m9 App Secret：WQnVIAWDBmR9XV86YNAO97P3Xgk21az9 S60手机 App Key：s60 App Secret：AbLmkn77N8j72iyE2Aup5RoRN8C0M3E5 天翼3G互联网手机 App Key：tianyi App Secret：DX2eXTXpGhnTeSoMcJs2BCpXQQKyzehf TCL互联网手机 App Key：tcl App Secret：gPvIKBER6kF2wAe6POQF9mTL1W9I9Y8C 中兴手机 App Key：zhongxing App Secret：sc2GRZT16abrHaUps2cydiQKvWizy8IE 华为手机 App Key：huawei App Secret：QUoQoFbH7LVmuCBhEwMKzC65R1JZDX0t 我的天语手机K-Touch App Key：k_touch App Secret：7d125GronKUP1rcgkOb8rqVjh2Q44fdx 我的K-Touch天语W700 App Key：tyw700 App Secret：nj3PK1AvukNAwXihZZg9PN6H文明用语b5QQb 我的酷派大观9930 App Key：yulong App Secret：9qCZ3L9riYQRz4FznnwUGrv2uPjqBGEm 我的coolpad酷派终端 App Key：coolpad App Secret：SuQmVobcpJxaNZRThXR4xsytbHUMOdFB ========================================= android 5l0WXnhiY4pJ794KIJ7Rw5F45VXg9sjo ========================================= hong_android d6YLHfS5dfdB2YcNDOpt97Zvqav20orv ========================================= iphone 5Jao51NF1i5PDC91hhI3ID86ucoDtn4C ========================================= galaxy_s RXZstlbVx7384oNWkeMWamsSEwfeEgii ========================================= htc ybQv5D6BC2bIOqYV2wCsIs0dX9vV0xIG ========================================= x10 rPVsSGvnz8erJ7w8sIICKEE70wQMRswU ========================================= me511 5AgbUpV7fL2APXOkI04QnRhlGUdUlwy0 ========================================= meizu_m9 WQnVIAWDBmR9XV86YNAO97P3Xgk21az9 ========================================= xiaomi 3MqAdNoRLHomm4AECoURl7gds1sUIjun ========================================= dellpad z9UbGHARtNkPZbZvLIw8UvVZlTOtVfHs ========================================= lp 5EmMeHqPOYsLSQ2zjrdXHoUhqtD4QYGx ========================================= sxtab 6b2BhcdpiCdyZaIh4O3S1zHAUoC6Zpql ========================================= sxandroid tYQO8S1RndCGgI3qNbiCEjG3cVaeOvq7 ========================================= s60 AbLmkn77N8j72iyE2Aup5RoRN8C0M3E5 ========================================= blackberry ivij24vyWpP0zE0M03r56RL2u8nu0L66 ========================================= tianyi DX2eXTXpGhnTeSoMcJs2BCpXQQKyzehf ========================================= tcl gPvIKBER6kF2wAe6POQF9mTL1W9I9Y8C ========================================= huawei QUoQoFbH7LVmuCBhEwMKzC65R1JZDX0t ========================================= coolpad SuQmVobcpJxaNZRThXR4xsytbHUMOdFB ========================================= tyw700 nj3PK1AvukNAwXihZZg9PN6Hcaob5QQb ========================================= yulong 9qCZ3L9riYQRz4FznnwUGrv2uPjqBGEm ========================================= k_touch 7d125GronKUP1rcgkOb8rqVjh2Q44fdx ========================================= zhongxing sc2GRZT16abrHaUps2cydiQKvWizy8IE ========================================= 1.以下App Key和App Secret适合修改于第三方客户端(例如Yibo,Weico) ========================================= yibo 3105114937 985e8f106a5db148d1a96abfabcd9043 ========================================= 联想乐pad 2440435914 70dc2ae26780817793c9c533092171dd ========================================= Spring微博.Android 1905839263 36b51c6ebf2dd3e5361f80f6c4506267 ========================================= 摩托罗拉xoom 2190063733 9222f119671ebf566b74220768014afd ========================================= weico.android 211160679 63b64d531b98c2dbff2443816f274dd3 ========================================= app梦工厂微博 569452181 bbd573c3052999adcd026cbf88ffbf8e ========================================= 微博助手 2702428363 82d9b7c386000b0de0711a20f146fa44 ========================================= FIT随享微博 31024382 25c3e6b5763653d1e5b280884b45c51f ========================================= 宏基acer 783190658 7f63ae9eb3c1438e9f8932748ca8a341 ========================================= Android平板 2540340328 886cfb4e61fad4e4e9ba9dee625284dd ========================================= weico.iphone 82966982 72d4545a28a46a6f329c4f2b1e949e6a ========================================= ipad客户端 2849184197 7338acf99a00412983f255767c7643d0 ========================================= 微博物语iphone 2735371158 fa2318d3281101f0c9b1be38f499dda4 ========================================= PushBox_iPad 1965726745 55377ca138fa49b63b7767778ca1fb5a ========================================= 微格iPhone客户端 2027761570 5042214816d14b2d9e8ae8255f96180d ========================================= weicoPro 2323547071 16ed80cc77fea11f7f7e96eca178ada3 ========================================= PoMe微博杂志 2135576995 37b190bebb816c11c0bd1f996a7ca49f ========================================= ArmingWeibo 2612767607 4f988ffd2fba40eaab89dc4aa4c5389d ========================================= GIF快手 915345515 88b51e31ddbe926089706e4500c55d2d ========================================= 美图秀秀 4229079448 bc58f8c7179369d4bfa914656c161b15 ========================================= 三星GalaxyTab 3510766076 f97dfdd530d85eaaee45e63ee47445a3 ========================================= WeicoGIF 1078446352 c698c95df62b060734d3d0a9e8787a9a ========================================= 围脖Call 1008696810 bd464ae2cee0e5d7234a12d06c9476ff ========================================= webOS 1262673699 6185cf040b403dfa35de9678b5e35baf 本文转自挨踢前端博客园博客，原文链接 http://www.cnblogs.com/duanhuajian/p/3834044.html如需转载请自行联系原作者 @挨踢前端
2017-11-21
优秀的个人博客,低调大师

Android SDK 安装中组件的离线安装方法 （share）

这次安装在Android开发环境搭建及配置phoneGap中，搜到了一下资料，留个备份。 源地址：http://anlab-qiao.blog.sohu.com/190769011.html 一、迅雷下载地址 资源 https://dl-ssl.google.com/android/repository/xxx.zip , xxx用以下包替换。 API 3 android-1.5_r04-windows.zip android-1.5_r04-macosx.zip android-1.5_r04-linux.zipAPI 4 android-1.6_r03-windows.zip android-1.6_r03-linux.zip android-1.6_r03-macosx.zip API 5 android-2.0_r01-linux.zip android-2.0_r01-macosx.zip android-2.0_r01-windows.zip API 6 android-2.0.1_r01-linux.zip android-2.0.1_r01-macosx.zip android-2.0.1_r01-windows.zip API 7 android-2.1_r03-linux.zip（三种平台共用） API 8 android-2.2_r03-linux.zip（三种平台共用） API 9 android-2.3.1_r02-linux.zip（三种平台共用）API 10android-2.3.3_r02-linux.zip（三种平台共用） API 11 android-3.0_r02-linux.zip（三种平台共用）API 12 android-3.1_r03-linux.zip（三种平台共用） API 13 android-3.2_r01-linux.zip（三种平台共用） API 14 android-14_r01.zip（三种平台共用） sysimg_armv7a-14_r01.zip 2.2 Android SDK Platform-tools revision 7platform-tools_r07-windows.zip platform-tools_r07-linux.zip platform-tools_r07-macosx.ziprevision 8platform-tools_r08-windows.zip platform-tools_r08-linux.zip platform-tools_r08-macosx.zip 2.3 Android SDK Tools revision 12tools_r12-windows.zip tools_r12-linux.zip tools_r12-macosx.ziprevision 13tools_r13-windows.zip tools_r13-linux.zip tools_r13-macosx.ziprevision 14tools_r14-windows.zip tools_r14-linux.zip tools_r14-macosx.zip 2.4 Android SDK Docs for Android API X, revision Y docs-3.2_r01-linux.zip docs-14_r01.zip Android SDK Samples for Android API X, revision Ysamples-2.1_r01-linux.zip samples-2.2_r01-linux.zip samples-2.3_r01-linux.zip samples-2.3.3_r01-linux.zip samples-3.0_r01-linux.zip samples-3.1_r01-linux.zip samples-3.2_r01-linux.zip samples-14_r01.zip 二、将下载的压缩包放入temp文件夹下 例如：D:\ProgramFiles\android-sdk-windows\temp 三、点击SDK Manaer.exe，让其自动解压缩。 四、配置环境变量 PATH =D:\ProgramFiles\android-sdk-windows\tools SDK安装完成 本文转自挨踢前端博客园博客，原文链接http://www.cnblogs.com/duanhuajian/archive/2012/10/21/2732883.html如需转载请自行联系原作者 @挨踢前端
2017-11-27
优秀的个人博客,低调大师

ASP.NET Jumpstart：构建 Media Share Library Starter Kit 的数据层

摘要：描述如何建立新的 ASP.NET 成员关系、角色管理和个性化服务，从而使用常规的 SQL Server 代替 Microsoft SQL Server Express。 注本文最初发表于 Scott 的网络日记。请在此处加入讨论。 本页内容 快速回顾：新的 ASP.NET 2.0 应用程序服务是什么？ 默认的 SQL Express 提供程序 小结 快速回顾：新的 ASP.NET 2.0 应用程序服务是什么？ Microsoft ASP.NET 2.0 包含许多内置的“构造块”应用程序服务。我们称其为“构造块”的原因是，它们是有用的核心框架，从而能够在超常情况下用于当前的 Web 应用程序 — 因此，它们可以大大提高生产效率并节约开发人员的时间。 这些构造块包括： • 成员关系 API（用于管理用户名/密码和安全凭据）以及角色 API（支持将用户映射到逻辑组）。 • 配置文件 API，用于存储访问 Web 站点的已验证用户和匿名用户的任意属性（例如，邮编、性别、主题首选项等）。 • 个性化 API，用于存储控件自定义首选项（通常与 ASP.NET 2.0 中的 WebPart 功能一起使用）。 • 状态监视 API，用于跟踪和收集有关运行状态的信息和 Web 应用程序内部发生的任何错误。 • 站点导航 API，用于定义应用程序内部的层次结构，以及根据当前传入用户在站点内的位置来构建特定于上下文的导航 UI（菜单、树视图、详细路径跟踪）。 ASP.NET 应用程序服务 API 可插接且实现过程不可知，这意味着，API 不对数据存储位置的详细信息进行硬编码。相反，API 调入“提供程序”，而“提供程序”是实现特定“提供程序约定”（定义为一个抽象类，具有 API 期望实现的一组定义好的方法/属性）的类。 ASP.NET 2.0 随附有许多内置提供程序，包括： • 针对本地 SQL Express 数据库的 Microsoft SQL Server Express 提供程序。 • 针对成熟的 SQL Server 的 Microsoft SQL Server 2000/2005 提供程序。 • 针对 AD 或 ADAM 实现的活动目录提供程序。 • 绑定文件系统上 XML 文件的 XML 提供程序（用于站点导航）。 该模型的优势在于，如果您不喜欢随附的现有提供程序，或者希望针对已经使用的现有数据存储集成这些 API，那么只需实现一个提供程序并将其插入模型即可。例如：您或许已经有一个存储用户名/密码的现有数据库，或者一个需要集成的现有 LDAP 系统。只需将成员关系提供程序约定实现为一个类，并在应用程序的 web.config 文件中注册（后文将详细说明），然后对 ASP.NET 中成员关系 API 的所有调用将委托给代码。 返回页首 默认的 SQL Express 提供程序 坦白说，大多数 ASP.NET 2.0 应用程序服务均配置为使用内置的 SQL Express 提供程序。在第一次使用一个应用程序服务时，该提供程序将自动创建和提供一个新的数据库，并提供一种非常简单的入门方法，而无需过多的安装步骤（只要有 SQL Express 就可以进行）。请注意，SQL Express 数据库也可以升级为在成熟的 SQL Server 实例上下文中运行。因此，使用 SQL Express 进行开发的应用程序可轻松升级为高容量、集群的故障转移安全 8P SQL 盒，与此同时所开发的应用程序将迈向更大的成功。 如何将提供程序从使用SQL Express更改为使用SQL Server？ 如果要使用成熟的 SQL Server 2000 或 SQL Server 2005 数据库实例（而不是 SQL Express），可按照以下步骤执行： 步骤1：创建或获取一个空白的SQL数据库实例 步骤将创建或获取一个连接字符串，该字符串指向一个空的标准 SQL 数据库实例。 步骤2：提供您的SQL数据库和ASP.NET架构 在系统中打开一个命令行窗口，并运行与 ASP.NET 2.0 一起安装的 aspnet_regsql.exe 实用工具，该实用工具位于 C:\WINDOWS\Microsoft.NET\Framework\v2.0.xyz 目录。 请注意，该实用工具可以在基于 GUI 的模式下运行，也可以与命令行开关一起运行（添加一个“-?”标记即可查看所有开关选项）。 通过这个向导，您能够演练如何为 ASP.NET 2.0 随附的内置 SQL 提供程序创建架构、表格和存储过程。图 1 至图 5 展示循序渐进的演练过程。 图1. SQL Server安装向导，欢迎屏幕 图2. SQL Server安装向导，配置应用程序服务 图3. SQL Server安装向导，选择服务器和数据库 图4. SQL Server安装向导，确认设置 图5. SQL Server安装向导完成 演练向导完成后，将安装和配置所有支持应用程序服务的数据库架构和存储过程。（注：我们还提供了上述框架目录下的原始 .sql 文件，如果 DBA 想要确切知道内部发生的事情，可以手动演练和/或运行这些文件来安装 DB。） 步骤3：使Web.config文件指向新的SQL数据库 现在，ASP.NET 2.0 支持 web.config 文件中一个名为 的新区段，它（显然）用于存储连接字符串。从管理角度看，好处之一是现在新的 ASP.NET MMC 管理单元可提供一种基于 GUI 的方式来配置和管理这些连接字符串（如图 6 所示）。 图6. ASP.NET管理页面中的连接字符串 ASP.NET 2.0 现在还支持加密任何存储在 web.config 文件中的区段，因此您可以安全地存储私人数据（例如，连接字符串），而不必编写任何加密代码。 ASP.NET 2.0 随附有一个名为 LocalSqlServer 的内置连接字符串，默认情况下，它配置为使用 SQL Express 数据库，以及成员关系、角色、个性化、配置文件和状态监视等服务。 让应用程序自动利用新创建的 SQL 数据库的最简单的方法是，在应用程序的本地 web.config 中，替换该 LocalSqlServer 设置的连接字符串值。 例如，如果我在本地计算机的 appservicesdb 数据库实例中创建了数据库，并使用 Windows 集成安全进行连接，那么我将更改本地的 web.config 文件来指定这项操作。 <configuration> <connectionStrings> <remove name="LocalSqlServer"/> <add name="LocalSqlServer" connectionString="Data Source=localhost; Initial Catalog=appservicesdb; Integrated Security=True" providerName="System.Data.SqlClient"/> </connectionStrings> </configuration> 单击“保存”，现在所有的内置应用程序服务都会使用新创建和新定义的 SQL Server 数据库。 注这种方法的一个缺点是，重用了 LocalSqlServer 连接字符串名 — 如果我在另一台机器上部署数据库，将感觉很别扭。如果想将它命名为自己的连接字符串名，只需添加一个全新的连接字符串，然后指定现有提供程序使用新的连接字符串名来代替默认的 LocalSqlServer 连接字符串。 返回页首 小结 虽然 ASP.NET 2.0 提供的应用程序服务默认使用 SQL Server 2005 Express，但是将其更改为使用 SQL Server 2000 或 2005 是一件相当简单的事情。一旦进行更改，您就能够享受这些数据库引擎的功能所带来的优点了。 本文转自高海东博客园博客，原文链接：http://www.cnblogs.com/ghd258/archive/2005/12/10/294619.html，如需转载请自行联系原作者
2017-11-25

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2026-04-11 大小: 211.28KB 下载: 56次
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2026-09-24 大小: 189MB 下载: 9次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2026-08-21 大小: 5MB 下载: 2次
WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册