E:dpkg was interrupted, you must manually run'dpkg配置'to correct the problem.

执行sudo apt-get install安装对应的软件出现如下错误

详细错误信息:

1
2
E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?

错误原因:是因为引用错误的链接导致的。

解决办法(删除这些引用即可):

1
2
cd /var/lib/dpkg/updates
rm -r ./*

删除完后,执行sudo apt-get update即可,这时就可以正常安装软件了。

参考解决办法链接:
14.04消息’E:dpkg was interrupted, you must manually run’dpkg配置’to correct the problem.’

nginx上配置phpmyadmin

Nginx配置phpmyadmin流程如下:

一、准备软件和环境(这里我以ubuntu16.04为例)

1.安装php7.1

1
2
3
4
5
sudo LC_ALL=C.UTF-8 add-apt-repository ppa:ondrej/php
sudo apt-get update
sudo apt-get install php-pear php7.1-cli php7.1-common php7.1-curl \
php7.1-dev php7.1-fpm php7.1-json php7.1-mbstring php7.1-mcrypt \
php7.1-mysql php7.1-opcache php7.1-zip php7.1-intl php7.1-gd php7.1-xml

(1)修改 PHP-FPM 监听方式为127.0.0.1:9000

1
sudo sed -i 's/listen = .*/listen = 127.0.0.1:9000/g' /etc/php/7.1/fpm/pool.d/www.conf

(2)重启 PHP-FPM 服务进程

1
sudo service php7.1-fpm restart

SpringBoot打包成war

关于SpringBoot打成jar包以及jar包如何在Linux持久运行,我在前面已经说过了,所以本次不再赘述。

关于SpringBoot打包成war,其实步骤特别简单,如下图所示(如果是jar,通常是没有图中红色标记处,因为默认就是jar):

大型网站架构模式

关于什么是模式,这个来自建筑师的词汇是这样定义的:”每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样,你就能一次又一次地使用该方案而不必做重复的工作”。

模式的关键在于模式的可重复性,问题与场景的可重复性带来的解决方案的可重复使用。

联系实际开发:
每个做前后台开发的小伙伴们都会发现一点,一个正儿八经的后台系统,80%是重复的,20%是特别的(可以称作个性化定制)。

举个例子:
人人开源的后台系统:

Jeesite4的后台系统:

从这两者进行比对就可以明显的发现公共的部分非常相似(只不过展现的形式不一样,renren-security中的角色管理是直接在菜单中显示,而jeesite4则放在权限管理中,只需点击即可看到对应的角色管理)

Caused by: java.sql.SQLException: Value '0000-00-00 00:00:00' can not be represented as java.sql.Timestamp

错误信息如下:

1
Caused by: java.sql.SQLException: Value '0000-00-00 00:00:00' can not be represented as java.sql.Timestamp

原因如下:
是因为数据表中字段类型与对象中的属性类型不一致。比如在我的数据表中是datetime类型,正常来说,对象中应该是Date类型,但是本次在对象中却是String类型。

解决办法:
(1)将datetime类型修改为varchar类型,即可解决问题;
(2)将Java对象属性类型(对应的那个)改为Date类型(java.util而非java.sql),即可解决问题;

git分支开发的好处

有不少开发者们不习惯使用Git分支开发。原因有如下几个方面?
(1)不熟悉不习惯;
(2)觉得太麻烦;
今天我想说的是使用git分支开发绝对是一个高效版本控制的做法。

当你遇到测试人员给你提的bug,你只需将其pull下来,并执行git checkout -b bug-solution01该命令即可,这条命令是切换并创建分支,当你切换到创建的分支时,便可以着手解决对应的bug,解决这个bug后,然后执行git checkout master后,再执行git merge bug-solution01该命令合并分支即可。
不过在一些中大公司里面,它们并不会通过主分支来合并侧分支,而是有一个开发分支,通过开发分支合并开发者分支,最后通过持续集成使master分支和开发分支合并集成测试部署(其实也是可以手动切换到master分支合并开发分支)等。假设有A、B、C等三个开发者,通常分支的形式是这样:

  • 主分支(master)
  • 开发分支(project-dev)
  • 开发者分支(A开发者分支、B开发者分支、C开发者分支等)

假设我是开发者A,测试给我提了一个bug,我在A分支的基础上创建一个解决bug分支(暂且命名为a-bug-solution),当我在a-bug-sllution分支上解决了这个bug并git commit提交到本地仓库后,然后通过git log查看对应的日志(防止提交失败或者其它意外),查看有对应的提交记录后,然后我切换到a-project-dev分支上执行git merge a-bug-solution,合并该分支,合并该分支成功后,然后我再次切换到project-dev分支上,执行git merge a-project-dev进行合并,合并成功后,我就可以不管了,因为剩下的可以交给持续集成工具(jenkins等)。

上述说起了,大家可能觉得很麻烦或者是没必要这样做,原因可能觉得太耽误时间了,我的回答是非也,一开始可能有点麻烦,越到后面你会越发现它的好处,让你情不自禁地爱上它。

分支开发的好处,是真正的确保每个人有自己的独立分支而不是全部在master分支上开发,全部在master分支上开发,弊端太多,比如隔离性太差了,而且全部在一个分支上开发的话,经常面临的就是解决冲突(在自己的分支上开发进行合并与全部在一个主分支上开发进行对比,如果代码提交相对频繁,你将会发现你永远都在解决冲突,如果提交缓慢的话,你还是发现在解决冲突,实际上你并不需要解决太多冲突,很多冲突是没有必要的)。

最后归纳总结一下,分支开发的好处:

  • 版本迭代更加清晰
  • 开发效率提升
  • 利于代码review的实现,从而使整个团队开发更加规范,减少bug率