陌桑 - 一个人的力量在于他的思想

AJAX跨域与URI大小写问题

By heiry on 2019-03-27 in 技术

以前解决过很多异步请求跨域的问题，自认为不会有什么难点，可今天调试一个项目API的时候遇到了之前没遇到的问题，弄了好久才解决，记录如下：

项目中涉及一个主域（以www.abc.com表示），子域（以s.abc.com表示），子域控制器s.abc.com/Action向主域www.abc.com/Reply发异步POST请求，www.abc.com/Reply发出Header参数“Access-Control-Allow-Origin:http://s.abc.com““Access-Control-Allow-Methods:POST”,按理说这应该没什么问题了，但问题来了：
1. 直接访问通过URL：www.abc.com/Reply访问，可以看到添加的“Access-Control-Allow-Origin“等响应头，也能正常传递JSON，如下：

Access-Control-Allow-Methods: POST
Access-Control-Allow-Origin: http://s.abc.com
Access-Control-Expose-Headers: Authorization
Content-Encoding: gzip
Content-Length: 138
Content-Type: text/json; charset=utf-8
Date: Wed, 27 Mar 2019 07:03:09 GMT
Server: Tengine
Vary: Accept-Encoding

2. 但通过子域的AJAX请求，死活就得不到添加的Headers参数，FF及Chrome均提示提示同源错误“原因：头缺少 ‘Access-Control-Allow-Origin’”，明明已经设置，就是没有传递，而之前做的一个接口几乎代码一样，但却能正常返回值，确实让人百思不得其解。
无奈之下，只能检查服务器设置，发现URLrewrite有如下规则：

<rule name="LowerCaseRule1" stopProcessing="true">
                    <match url="[A-Z]" ignoreCase="false" />
                    <action type="Redirect" url="{ToLower:{URL}}" />
</rule>

恍然大悟！

这个是SEO常设规则，用来规避因为URL大小写而带来搜索引擎识别为不同站点的问题，而项目很多CLASS命名都根据大小驼峰规则，Controls也是大小混写，这条重写规则强制将文件名小写返回，而AJAX请求则认为是两个不同请求，导致Headers参数无法正常接收。

取消此规则，问题解决。

jquery $().val的bug

By heiry on 2019-01-31 in 技术

近来研究一些开源的前端框架，重拾js，发现一个奇怪问题：
input如果设置为display：none，那么通过$(“#id”).val(“value”);方式赋值，无论是chrome、firefox还是IE都是传值方式失效。
改用$(“#id”).attr(“value”,”value”);却又可以
但是如果设置type=”hidden”，同样使用$(“#id”).val(“value”);方式赋值却又可以。

table doesn’t exist,mysql文件备份导入的问题

By heiry on 2017-11-21 in 技术

今天在兆维工业园IDC帮一位朋友迁移web服务器，他将之前拷贝的mysql数据库文件还原到新服务器中，结果有部分表在PHPmyadmin中没显示，而用Navicat 连接，能看到表，却打不开，提示”table doesn’t exist”。web应用显然不能正常运行。为何会这样，明明有表，却不能显示或是doesn’t exist？

我们知道，MySQL备份可直接拷贝datadir下的数据库文件，还原时将拷贝文件放到mysql下的data目录下就可以。但是今天却出现这种情况，是什么原因？

MySQL存储引擎分MyISAM与InnoDB，两种类型最主要的差别就是Innodb 支持事务处理与外键和行级锁，而MyISAM不支持。MyISAM类型的表强调的是性能，其执行速度比InnoDB类型快，但是不提供事务支持。

MyISAM类型的表，都对应data下的一个文件夹，文件夹名字就是表名，数据存储在该文件夹下三个”Table.frm”,”Table.MYD”,”Table.MYI”中;InnoDB的表，数据和结构是分别存储的，数据存储在ibdata1文件中（默认），而结构存储于.frm文件中。

我们常用的直接拷贝”Table.frm”,”Table.MYD”,”Table.MYI”方式来备份数据库，对MyISAM类型是有效的。但是对于InnoDB的表，还必须拷贝ibdata1文件。

之所以出现上面提到的问题，原因就是在于有部分是InnoDB表，却没有拷贝ibdata1文件。

出现错误后，直接拷贝ibdata1文件覆盖，还是问题依旧，这时只要删除log文件（ib_logfile*）就可以了。

这其实也是我多年前遇到的问题，当时备份数据库没注意，没有拷贝ibdata1，导致很多数据丢失，是得了教训的。

数据库备份一定要十分小心，不仅要测试，还要多种方式备份，最为稳妥的是导出sql文件，或用专业备份工具，多种形式备份。

Google Material Design的设计思路

By heiry on 2017-10-21 in 设计

产品图标网格已经形成了一致的标准，且建立了一套明确的图形元素定位规则。这种标准化带来了灵活，而连贯的系统。

以上已经是全尺寸比例高宽网格图可以右击另存作为参考图使用

网格

关键线的形状

关键线的形状是网格的基础。利用这些核心形状做为向导，即可使整个相关产品的图标保持一致的视觉比例。

方形

高&宽: 152

圆形

直径: 176

竖直矩形

高:176 宽:128

水平矩形

高:128 宽:176

DP 单位网格

设备上的启动器以 48dp 的尺寸显示产品图标 (边缘 1dp)，所以当你创建图标时，请使用 48dp 的尺寸，必要时可将其放大 400% 到 192 x 192 dp (边缘变位 4dp)。

保持这样的放缩比即可在尺寸在缩小时保持边缘的锋利和对齐的正确性。

1:1 单元网格

4:1 单元网格

几何

我们为这几种特定的关键线制定了预设规则：圆形线、方形线、矩形线、正交线和对角线。这个通用且简洁的元素调板形成的目的是统一产品图标和规范它们在网格上的布置。

为什么要这样设计？以上右图著名的视觉错觉案例可以例证：

一样长的线段不同的视觉表现产生不一样的视觉感知，矩形的视觉感知面积相对大，所以相对网格线居中定格最小部分来设计来达到各种其他形状样式的图标统一感。

内容区域

内容应该保持在活动区域以内，如有必要，内容可以延展至修饰区域之中，但不能超出。

活动区域

修饰区域

关键线形状

关键线形状是网格的基础，通过关键线，即可保持系统图标的一致性。

方形

宽&高：18px

圆形

直径：20px

竖直矩形

高：20px, 宽：16px

竖直矩形

高：20px, 宽：16px

几何

我们为这几种特定的关键线制定了预设规则：圆形线、方形线、矩形线、正交线和对角线。这个通用且简洁的元素调板形成的目的是统一 Google 系统图标和规范它们在网格上的布置。

构建

组成

系统图标剖析

笔划末端
角
留白
笔触
内部角
边界区域

角

一致的圆角半径（2px）是统一全系列系统图标的关键，不要修改它。

图标内部的角应为直角，也不要修改它。

外部角

內部角

笔触

一致的画笔宽度（2px）也是统一全系列系统图标的关键，请在内外部的边角上保持使用2px的宽度。

一致

折线和角

笔划末端

内部角

视觉校正

极端情况下必要的校正能够增加图标的清晰度。如有必要，需与其他图标保持一致的几何形状，不要加以扭曲。

复杂

缩小

清空

为了可读性和触摸操作的需要，图标周围可以留有一定的空白区域。

清空区域

放置

———————————————————————————————-

最佳范例

一致的图标可以有利于用户理解，在不同应用中也尽量使用已有的系统图标。

(上图)可取

使用相同的画笔宽度以及方形的笔划末端。

(上图)不可取

不要使用不相同的画笔宽度以及非方形的笔划末端。

(上图)可取

让图标显得正面且坚定。

(上图)不可取

不要倾斜、旋转图标，或是让图标显得立体。

(上图)可取

简化图标使其更具清晰度和可读性。

(上图)不可取

不要过度拟物化使得图标复杂。

(上图)可取

让图标更加几何化而变得更加显眼。

(上图)不可取

不要过度精细，使用过细画笔宽度。

(上图)可取

使用一致的几何形状。

(上图)不可取

不要使用过于松散的形状。

(上图)可取

让图标在像素点上（X、Y 坐标值不包含小数）。

图标应有相等的宽高(e.g. 24×24)，避免扭曲。

(上图)不可取

图标不在像素点上。

宽高不等。

相近性在设计中的应用

By heiry on 2017-10-21 in 设计

格式塔理论的相近性原则告诉我们，我们的大脑会将距离相近的各部分元素组成一个整体。

相近性原则：

当分离的各个元素接近的时候，他们便呈现一个整体的形象，就算这些元素看起来不一样。

相近掩盖差别：

利用相近性我们将不同的字母、形状及颜色元素组成一个标志。

尽管上述各个字母的形态并不一样，但是由于各个元素距离相近，我们在识别时仍会将其看作一个完整的词组。

尽管上述右边的标志是由不同形状及颜色的元素结合，但相近性原则使我们能够清晰识别出一个房子的轮廓。

组合相关元素：

将元素相合，能够创造出更有条理的展示，不但更具美感，也使读者在观看时更加轻松。

改造前的名片

缺乏联系的设计：

上面的这个设计仅仅是考虑如何填满版面，而联系信息却被分割成三块元素，这使到观看的人会花额外的精力将这些信息元素组合在一起。

改造后的名片

产生联系的设计：

将相关的文字元素且合起来，立即就产生了一种清晰的阅读效果，现在名片上的联系信息能够轻松地让人从上到下观看。上面竖版的排列中，标志形成了一个视觉焦点，所以我们的眼睛首先会移到上面观看，然后很自然地由上到下地阅读下面的联系信息。

白色背景的重要性：

相近性原则也取决于元素在背景上不同位置的放置，从而使人们获得各种不同的信息组合，而最清晰的效果就是利用白色背景来区分这些组合。

在上面这个关于学习提升的宣传单张中，我们通过元素的属性来将上方的文字区域A作为一个相近性的组合，也将其视作一个单独的组合，尽管B也是一堆文字，甚至两者的文字意思也接近，但我们并不会将A与B看作一个整体。

文章来源: http://www.sj33.cn/article/sjll/201707/47665.html

“触动人心的设计”的方法

By heiry on 2017-10-17 in 设计

原文作者：阿里 B2B_UED团队
原文标题：《“触动人心的设计”方法初步探究》

用户体验设计的精髓，在于恰到好处的设计出最合适的用户场景体验，而这种体验是不知不觉给予用户同时能让用户在触点的那个瞬间怦然心动，那如何让用户心动呢？

古人云：“动人心者，莫先乎情。”，同样的我们从约翰.奈斯比特的语言中窥见：”无论何处都需要高补偿的情感，社会中高技术的越多，我们就越渴望高情感的环境，用设计软性的一面来平衡技术硬的一面。设计作为人的创造性活动，不是摒除激情或者情感，而是要创造一种中性的、能容纳和激起使用者情感的东西，这种东西是一种境界。”

因此，我们1688UED在2014年组建了人文情怀课题研究小组专门来探讨如何进行“触动人心的设计”,课题研究的范围从马斯诺需求到各种效应理论以及设计心理学,大家在浩瀚的知识学说中徜徉，并不断碰撞产生了各种的灵感火花，最后得到了一个关于“DesignO2O”的设计思路以及“CORE”的方法模型，同时找到了如何验证我们“触动人心的设计”是否有效方法。

DesignO2O这个思路是由课题小组不离同学提出的也是我们整个设计方法的理论基石。(见下图)

人的大脑是个超级存储器，总是通过五感接受信息，被大脑识记，并且保存在记忆当中，五感由于我们是从事互联网设计行业，都是偏电脑页面的一些设计，所以主要能发挥的是视觉和听觉，线下某些实物的工业设计还会有嗅觉，味觉，触觉等等。图中的“识记-保存-重现”是人类记忆的主要过程，重现包括回忆和再认两个环节，我们这里提到的主要是指回忆，是在一定诱因的作用下，过去经历的事物在头脑中的再现过程。拥有记忆的人通过看见了一些事物或者听见了某些信息，和大脑保存的过去进行了重合配对，唤醒了记忆，那些画面会被重现，在这个过程中你的大脑已经不知不觉中招了、被刺激了，重现的画面在你的脑海里久久不能离去，以至于让你做出一些意想不到的事，就是我们说的情绪行为，以我们自身为例，影响的就是购买决策，在我们的平台上就有一群这样的用户，人称“月光族，剁手党”…所以我们发现对于一个完全没有记忆的人来说，其实是很难触动情感的。通过大量的案例收集和讨论给这样的方式在设计中的运用总结为“DESIGNO2O”，offline2online，就是刚才所说的过程，这个过程转化为设计就是把线下的场景或者人物或者事件等等还原到我们的设计中，公式就是要简单好记，才能被广泛引用，这也是O2O业务模式的设计延伸，也同样印证了一句哲学思想：everything is connected。万事万物都是互相联系的。

超大流量网站PHP到Node 的迁移

By heiry on 2017-10-15 in 技术

转自：http://taobaofed.org/blog/2016/06/02/thing-about-taobao-homepage/

作者：淘宝前端团队阎王原题《聊一聊淘宝首页和它背后的一套》

一、相关背景介绍

淘宝首页是淘宝的门面，承载着几乎淘系所有业务的入口，流量很大，量级单位为亿。近几年无线端崛起，业务重点开始向无线终端偏移（目前不能叫偏移，基本以无线为主了），所以淘宝 PC 端首页的流量也有削减，不过即便如此，它的日均 PV 依然相当高。

淘宝首页一向是内部平台和技术的试验田，它一直在变化着。最新的框架和系统都会找淘宝首页试点，可以试想下，如果某一项需要推动的升级或者优化措施在淘宝首页已经上线，并且拿到了良好的数据和稳定性，其他业务还有什么理由不去尝试和更迭呢？同时，去年一年身在淘宝前端的技术架构组，自然而然也会主动去 push 一些实验性的内容到业务上。

淘系的站点页面包括首页、其他频道页和活动页等，这些页面并不都由淘宝前端一行一行的代码码出来，业务如此之多，这种玩法即便人数 double 也忙不过来。事实上，大多数页面都是依托内部的搭建平台——运营或者前端通过模块搭建的方式——构建的，而前端 focus 的重点在于搭建平台的建设自身以及模块的通用性和复用率的保障，当然，还有一些工程化的东西。

使用搭建平台搭建的页面，前端只需要考虑组成页面的原子模块的开发，整体的渲染由搭建平台提供的统一脚本全权负责。而在淘宝首页上，考虑到页面模块数量巨多，加上还有少量跨部门、跨团队的沟通，渲染模型略微不同。

二、淘宝首页的整体变迁

背景中提到，淘宝首页依托于内部搭建平台，它的变迁自然也是跟着搭建系统的变化而变化的。

1. PHP 下的淘宝首页

接手淘宝首页不久，便遇到了一年一度的改版，那时它还运行在 PHP 环境中。这里需要说明的是，淘宝首页的所有代码完全由前端掌控，前端不会直接跟数据库打交道，其数据来源分为两部分。

数据来源

一是 运营填写的数据。 采用前端挖坑的形式，预留坑位让运营获取填写数据，如（伪代码）：

  
<?php $info = Person('name:String:姓名,age:Number:年龄', '个人信息坑位填写');?>

<div>
<?php $info.forEach(index) { ?>
  Name: <?= info[index].name ?>, Age: <?= info[index].age ?>
<?php } ?>
</div>

  
<?php $info = Person('name:String:姓名,age:Number:年龄', '个人信息坑位填写');?>

<div>
<?php $info.forEach(index) { ?>
  Name: <?= info[index].name ?>, Age: <?= info[index].age ?>
<?php } ?>
</div>