wishselfly个人技术博客，分享技术干货，了解技术第一线资讯
最近跟朋友在讨论数据库优化的时候，说到了稳定排序和不稳定排序的问题，所以就把聊天记录的一部分记下来。 说一下稳定排序算法。和不稳定排序算法
所谓稳定排序算法就是排序后，子序列不变
例如有序列
A = [[3, 1], [2, 4], [2, 3]]如果按A[0]降序排列，如果是稳定排序，结果肯定是
A = [[2, 4], [2, 3], [3, 1]] [2,4]永远在[2,3]前面
如果是不稳定排序
A = [[2, 4], [2, 3], [3, 1]] A = [[2, 3], [2, 4], [3, 1]] 这两种可能都有。看具体算法
例如选择排序、冒泡排序就是不稳定排序。
你可以试试用来排[3,1] [2,4] [2,3]这个序列。用冒泡的话。从尾部冒泡到头部，从小到大，结果肯定就是
[[2, 3], [2, 4], [3, 1]] 破坏了[2,4] [2,3]数组中第二个数的子序列
最近在帮外包公司的开发App的时候，遇到一些奇葩的BUG问题，因为是跟硬件交互的App，可能硬件返回了一些异常的数据，导致了App的崩溃，毕竟客户跟我不在同一个城市，而且对方公司没有用Mac系统的，所以在iOS出现崩溃BUG的时候，想要获取到对应的崩溃日志我可是绞尽脑汁。因为这个App是用Swift开发的，其实这次开发以后我觉得我可能短时间内，接到别的项目的时候，除非真的足够的小，不然我不会用Swift开发，我认为当前的Swift还处于上升期，还没到达能够用它开发比较大型项目的程度。而且相对于objective-c，有个令我蛋痛的问题，在objc中，我只要使用freopen之后，我就能把所有使用NSLog打印出来的LOG导出到文件。但让我头痛的时候，Swift使用了这句以后没有任何作用，我也没有去深究里面的问题。
另一方面，虽然Swift真的相对objc安全太多，特别Optional还有一些强大的语法支持，确实能够避免很多诸如空指针之类的异常。但写程序的总是人，总是会犯一些低级错误，导致App崩溃，在这种情况下。因为Swift太安全了，反而导致这个崩溃的BUG真的想都想不到在哪里，只能靠直觉去看那些可能有问题的地方进行加固。
所以我们最需要的是崩溃日志！崩溃日志真的太TM重要了，但是问题是，无论我使用NSSetUncaughtExceptionHandler设置，在Swift里面还是在objc里面，最后都发现无功而返。最终都没有办法取出崩溃的信息。哪怕把所有的signal都设上handler，还是没有办法捕获程序的崩溃。
所以最后的最后，还是无办法生成我所需要的崩溃日志，就算用XCode能够直接拷贝处iOS设备中的Log，但是客户不在同一个城市，总不可能我往那边频繁的跑把，这也非常不现实，我尝试教对方各种导出方法，可惜Mac盲+iOS盲，教起来有点费力，所以经过各种尝试，最后提倡客户去使用itunes connect里的TestFlight进行测试。
简单来说，就是生成一个构建版本之后上存到App store，然后在TestFlight里面邀请内部iTunes connet里面的成员进行内测，然后教对方在iOS设备上安装TestFlight，然后输入邀请码一系列操作。终于成功用TestFlight装上App了，那么希望崩溃问题能够捕捉到吧，问题是上面说信息会有72小时的误差?我只能祈祷生效
最近在忙公司的项目，公司现在重新做自己产品，所以我现在前端后台各种换着做，所以产品也奔着小程序走了。
但是坑爹的是，我在做上存文件时候发现，我填OSS的域名的时候，小程序竟然警告我这是非法的域名，然后想想暗战中那两家，就明白把阿里的域名填进去是不可能的，不过我还是庆幸没有把阿里的IP网段全封了，毕竟我们公司服务器主要用的都是阿里的?。
好了，那么问题来了，这个问题要怎么解决，试了很多种方案，麻烦的是小程序的那些域名白名单第一需要ICP备案，第二需要https证书，我又不想又去申请一张证书，那实在太麻烦了。所以最后发现比较折衷的方法，那就是用nginx做反向代理，连接到到阿里的OSS，下面附上配置
server {
server_name aaa.com;
listen 443 ssl;
ssl_certificate 证书书地址;
ssl_certificate_key 秘钥地址;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_session_cache shared:SSL:10m;
ssl_prefer_server_ciphers on;
ssl_session_timeout 10m;
location /oss {
rewrite ^/oss(/.+)?$ /$1 break;
proxy_http_version 1.1;
proxy_pass http://bucket-name.oss-cn-shenzhen-internal.aliyuncs.com;
#这两句是为了替换调用阿里云返回的错误数据的时候，把域名替换成自己的，纯粹强迫症
sub_filter_types application/xml;
sub_filter_once off;
sub_filter 'bucket-name.oss-cn-shenzhen-internal.aliyuncs.com' 'aaa.com/oss';
}
location / {
#其它的反向代理
}
}如上，大家可以把bucket-name.oss-cn-shenzhen-internal和aaa.com换成自己的阿里云OSS的endpoint和域名
另外，如果绑定了域名到OSS的话，因为小程序必须使用https访问，但是如果我们把OSS绑定的域名换成https访问的话，阿里的服务器会返回他们自己的https证书，然后小程序会直接校验TLS失败而直接拒绝了请求，因此只能通过自己的服务器做反向代理，毕竟这样能够返回我们自己域名的https证书，这样又没有必要特地给oss再指定一个二级域名，还省掉了麻烦的申请https证书的过程。而且可以看到用的是OSS的内部域名访问的，这样用自己服务器的流量来替换了OSS直接的外网流量，说不定是牺牲了服务器一些性能，而减少了OSS的外网流入流量，省钱啊。毕竟OSS不算内网流量。
还有就是我发现小程序内部使用到图片的时候，那个image标签和css的background-image的时候，地址是http和直接用OSS的那个三级域名也是没有问题的，那样就可以避免这些静态数据走逻辑服务器，还是直接走OSS吧，只是上存的时候比较绕，要到自己的服务器后台一圈再去OSS罢了。
其实最近心情很复杂，感觉到迷惘，也感觉到一些不甘。不甘的是现在项目的走向，虽然缓慢，但感觉还有一步一步脚踏实地的前进着，基本上都没有遇到一些比较大的技术难题。可能因为长时间的加班，导致已经开始如咱老大说得，做项目做疲了那样的感觉。有时候觉得很累，但又很多东西要做。现在才慢慢有一些踩着开发节奏的感觉，现在来说目标只有快点开发完，快点上线。 那么那些让我迷惘的东西，就是之前老大突然问我们产品设计的一个问题，你感觉市面上那么多跟我们同类的产品，而且功能大且全，你觉得我们比他们有什么区别？有什么优势？
虽然这些话并不是对我说，我只是听到那么一说，也让我自己陷入了沉思。你说我们跟别人已经发展了几年甚至上线不知道经过多少次迭代的产品比较，我们的产品确实如一个初生婴儿一样，要啥啥不成熟，如果真有去挑毛病挑刺，我感觉好想能挑出不少，而且我自己本身也挺害怕这个对比。就感觉像被人问，你觉得你自己离BAT的工程师差距有多大的感觉。那么我就去挑我们产品比别人好的地方，虽然好像能够说出那么几个，但是总感觉认真一想，难道别人会没有注意到这个问题吗？我觉得我自己对于自己现在做的产品的理解不够深入，只是远远停在了知道需求，知道怎样开发上。我的直觉很想知道，如果真的要比起来，到底比别人的产品好在哪。其实如果真要照刚开始做产品的时候我们的目标来说，我认真比对了下，总感觉不到什么发光点，我感觉连离我们最初定的目标也有一段距离。
另一方面，总感觉自己技术上已经在某个位置停滞了有几个月的时间，有时候想往一些新方面发展看看，能不能给现有的瓶颈来一个意想不到的反转？
我个人是挺喜欢往架构方面深入的，而且我觉得心在算比较擅长的java和iOS也想进一步深入了解底层，也稍微了解一下golang和kotlin之类的。
这里我会以上一篇文所的的预定义的表，请对照着阅读:一些Hibernate的用法笔记（1）
在一些实际的开发环境中，我们查询一张表，可能需要关联到另外一张表的信息，不是那种已经存在于数据库表的字段中的数据，可能是需要统计的一些数据，例如我需要知道这个用户在系统下面到底有多少中角色，写成SQL可能是
select {ac.*},
(select count(*) from account_role_rel where account_role_rel.account_id=ac.id) role_count
from account ac
where
ac.id=?对于像上述查询语句中，这种查出来为纯数字的变量，而且不存在于实体当中的变量，我们可以通过addScalar的方式捕获出来
那么我们在DAO中转换当前SQL语句查询结果的代码如下：
SQLQuery q = session.createSQLQuery(
"select {ac.*}," +
"(select count(*) from account_role_rel where account_role_rel.account_id=ac.id) role_count " +
"from account ac " +
"where" +
"ac.id=1"
);
q.addEntity("ac", AccountModel.class);
//可以通过StandardBasicTypes设置额外捕获的参数的类型
q.addScalar("role_count", StandardBasicTypes.INTEGER);
//获取到的内容为Object[]{AccountModel, role_count}
return q.uniqueResult();StandardBasicTypes里面有很多基本类型:
还记得我们之前声明的用户和角色的关联表：
| account_role_rel | ||
| 列名 | 类型 | 注释 |
| id | INT(11) NOT NULL PRIMARY KEY AUTO_INCREMENT | 递增标识 |
| account_id | INT(11) NOT NULL | 用户ID |
| role_id | INT(11) NOT NULL | 角色ID |
现在我们需要声明AccountRoleRelModel.java，我需要在里面Join上RoleModel和AccountModel的实体：
/**
* 用户与角色的关联表的实体
*/
@Entity
@Table(name = "account_role_rel")
public class AccountRoleRelModel {
private Integer id;
private AccountModel account;
private RoleModel role;
@Id
@Column(name = "id")
@GeneratedValue(strategy = GenerationType.IDENTITY)
public Integer getId() {
returnn this.id;
}
@OneToOne //这里可以改成ManyToOne，相对，下面的JoinColumn需要加上insertable=false, updatable=false
@JoinColumn(name = "account_id", referencedColumnName = "id")
public AccountModel getAccount() {
return this.account;
}
@OneToOne
@JoinColumn(name = "account_id", referencedColumnName = "id")
public RoleModel getRole() {
return this.role;
}
//setter省略
}这种时候，我们在编写DAO的时候，我们可以通过addJoin加入对应实体的映射：
@Repository()
public class AccountRoleRelDAO {
@PersistenceContext
public EntityManager em;
@Transactional(readOnly = true)
public List<Object[]> getCashAccount(int accountId) {
Session session = em.unwrap(Session.class);
SQLQuery q = session.createSQLQuery(
"select {account_role_rel.*}," +
"{account.*}," +
"{role.*} " +
"from account_role_rel " +
"inner join role on " +
"role.id=account_role_rel.role_id " +
"inner join account on " +
"account.id=account_role_rel.account_id " +
"where account_role_rel.account_id=:accountId"
);
q.setParameter("accountId", accountId);
q.addEntity("account_role_rel", AccountRoleRelModel.class);
/* public abstract SQLQuery addJoin(String tableAlias, String path)
* Declare a join fetch result.
* Parameters:
* tableAlias - The SQL table alias for the data to be mapped to this fetch
* path - The association path ([owner-alias].[property-name]).
*/
//根据上述定义，addJoin的第一个参数，应该是需要join的表在SQL语句中的名字，如果我们给对应表声明了别名的话，这里填的应该是别名
//后面应该是主表在SQL中的名字，有别名用别名，然后.后面接实体中，Join的模型的变量的名字
//例如AccountRelModel中我们声明AccountModel Join的变量名为account
//因此这里填的是account_role_rel.account
q.addJoin("account", "account_role_rel.account");
//同上
q.addJoin("role", "account_role_rel.role");
//返回的内容List<Object[AccountRelModel, AccountModel, RoleModel]>，顺序根据上面addEntity、addJoin的顺序产生对应的Object[]内用的顺序
return (List<Object[]>) q.list();
}
}我的公司的老板对新的项目的后台的架构下了非常重的力度，所以很多东西希望能够抽取出来重用，特别是对于一些很多项目都会重用到的模块进行抽出。开发中，一些封装的功能甚至关联的表都是未知的，因此对Hibernate用法进行了一次比较深入的研究。我们希望针对自己的业务，形成一套系统，让以后的开发效率更高。并且能够能增强封装出来的东西的重用性。有时候非常庆幸有一个搞技术的老板，真的能够学到很多好东西。
这里总结一下，做下记录。虽然hibernate的ORM的注解很强大，包括和spring jpa一起使用的时候真的非常爽。但是这些功能，虽然用着爽，却容易对业务造成很大的耦合度。
好了，转入正题。
例如我们有一个用户表：
| account | ||
| 列名 | 类型 | 注释 |
| id | INT(11) NOT NULL PRIMARY KEY AUTO_INCREMENT | 递增标识 |
| account | VARCHAR(25) NOT NULL | 用户名 |
| password | VARCHAR(64) NOT NULL | 密码 |
角色表:
| role | ||
| 列名 | 类型 | 注释 |
| id | INT(11) NOT NULL PRIMARY KEY AUTO_INCREMENT | 递增标识 |
| role_name | VARCHAR(25) NOT NULL | 角色名 |
用户角色关联表:
| account_role_rel | ||
| 列名 | 类型 | 注释 |
| id | INT(11) NOT NULL PRIMARY KEY AUTO_INCREMENT | 递增标识 |
| account_id | INT(11) NOT NULL | 用户ID |
| role_id | INT(11) NOT NULL | 角色ID |
因此我们可能需要生成两个实体
AccountModel、RoleModel
至于中间那个account_role_rel的表，因为开发中要用hibernate转换出它的实体，实在多此一举，因此就直接省略掉对应的实体了。
/**
* 用户实体
*/
@Entity
@Table(name = "account")
public class AccountModel {
private Integer id;
private String account;
private String password;
@Id
@Column(name = "id", nullable = false)
public Integer getId() {
return this.id;
}
@Basic
@Column(name = "account", nullable = false)
public String getAccount() {
return this.account;
}
@Basic
@Column(name = "password", nullable = false)
public String getPassword() {
return this.password;
}
//Setter省略
}/**
* 角色实体
*/
@Entity
@Table(name = "role")
public class RoleModel {
private Integer id;
private String roleName;
@Id
@Column(name = "id", nullable = false)
public Integer getId() {
return this.id;
}
@Basic
@Column(name = "role_name", nullable = false)
public String getRoleName() {
return this.roleName;
}
//Setter省略
}现在假设我们建了Account和Role这两张表的实体，而且没有使用@JoinColumn一类的注解，但是我们需要动态的把两张表关联在一起 我们需要DAO
/**
* 获取账号和角色集合的DAO
*/
@Repository
public class AccountRolesDAO {
@PersistenceContext
public EntityManager em;
public Map<AccountModel, List<RoleModel> findAccountRoles(int accountId) {
Session session = em.unwrap(Session.class);
SQLQuery q = session.createSQLQuery("SELECT {ac.*},{ro.*} from " +
"account ac" +
" left join " +
"account_role_rel rorel " +
"on rorel.account_id=ac.id " +
"left join " +
"role ro " +
"on ro.id=rorel.role_id");
q.addEntity("ac", AccountModel.class);
q.addEntity("ro", RoleModel.class);
//返回的东西是{[AccountModel,RoleModel],[AccounrModel,RoleModel]}
List<Object[]> result = q.list();
Map<AccountModel, List<RoleModel>> map = new HashMap<AccountModel, List<RoleModel>>();
for (Object[] entities : result) {
List<RoleModel> list = map.get(entities[0]);
if (list == null) {
list = new ArrayList<RoleModel>();
map.put(entities[0], list);
}
list.add(entities[1]);
}
return map;
}
}上面的东西，如果我们关联表是未知的，我可以很方便的通过上面代码的变形，传入对应实体类型和参数，就能够实现自动关联，不像Hibernate注解声明的实体，实体之间的关系必须在实体内声明。即使在不清楚另一个实体是什么的情况下进行关联，能够很好的把一些业务重复的逻辑抽取出来，再跟项目或者功能特定业务的表关联，这样就不用每次开发都特地的写一遍这些功能。