1. profile跟property的mapping 启动Spring时，通过-Dspring.profiles.active指定有效的profile，然后spring就会找到相应的property。application.yml，这个是默认加载的文件。如果参数传递进来的profile是develop，那么spring会按照application.yml→application-develop.yml的顺序去下载配置文件。如果两个文件中有重复的key，后面的develop.yml的优先等级更高。 2. module间的包含关系 通过在配置文件中定义spring.profiles.include可以实现包含关系。一般这种应用场景如下：假设我们有如下几个module– web– batch– infraweb跟batch都调用了infra，那么如果我们在infra里面定义了property的话，同样也需要在web跟batch里面重复定义。为了避免这种情况，就可以通过include去包含其他module里面的property文件。 # web/batch # infra
Category: 编程
多对一的时候，@OneToMany要写明关联entity侧的变量名 像这个例子里写的一样，@OneToMany(mappedBy = “user”) 要协商mappedBy = “user”，这个user对应的是UserApp的@ManyToOne的变量名称，如果不一致启动spring的时候会出错。 @OneToMany的变量要赋初始值 val userApps: List<UserApp>? = null如果没有初始值，启动spring的时候也会报错 相关联的Entity的JpaRepositroy的方法命名 像例子中的findByUserAppId，这个UserAppId，关联的是userApps的单数形式userApp，然后Id代表的是UserApp的Entity的主键。然后，还有一个重要的点，table里面的column，也必须命名为user_app_id，不然虽然能启动Spring，但是执行sql的时候会出错。
最近突然发现，一个测试居然要30分钟才能跑完。记得最早的时候也就十几分钟。随着test case越来越多，时间就越来越长了。要是按照这个增长幅度下去，明年估计跑完全部测试就要奔着1个小时去了。网上查了一些资料，然后尝试了很多，最后总结出来这么几个有效的方案： 尽量不要在不同class里面定义MockBean 测试时最花费时间的，其实是启动DI环境，尤其是使用了spring的web模块，启动一次基本要一分半左右。如果像下面这样，在不同的class里定义MockBean的话，执行一个测试class，Spring就会认为context发生了变化，会去重启DI环境。 像上面这种case，如果把MockBean定义到BaseTest里面，执行不同的TestClass，Spring也不会认为context发生了变化，只是会把数据rollback，而不会去重启DI环境。这样就能节省40%左右的时间。 减少@SpringTest的使用 @SpringTest很方便，启动DI环境时会加载所有的Bean，但是同样也十分浪费时间，如果你只想测试Controller，Repository的话，可以使用@WebMvcTest或者@DataJpaTest等，这样可以减少加载的Bean的数目，提高DI环境的启动速度。 明确每一层的作用，写代码时注意不要跃层 Controller：仅作validation和转发Repository：近作数据查询和更新操作Service：业务逻辑像这样把每层的责任范围都明确并严格执行。这样Controller的话基本就只写少量测试。然后Repository如果使用JPARepository的话，基本上只定义接口就可以，那么测试也比较少。重点基本都放到Service层了。如果严格按照上面的功能划分，那么Service就可以独立出来一个模块。然后有使用Repository的case，@DataJpaTest基本上就可以cover大部分测试了。 尽量减少DI的使用 DI固然有很多好处，很方便。但是最好不要滥用。同样的实装，如果不用DI，测试时就不用启动环境。速度就十分快了。其实极端一点，放弃JPARepository，使用jooq，所有的数据访问都通过DSLContext去实现，那么就完全可以做过不启动DI环境进行绝大部分Service层的测试。当然，是否采用这个策略要根据项目规模跟特点去判断。毕竟全都拿jooq写会增大代码量。对于小型web项目其实是不太适合的。 最后，记录下改善后的测试用时。隔个一年之后再回来看看，看那时测试用时会变成多久。 参考：https://spring.pleiades.io/spring-boot/docs/2.1.11.RELEASE/reference/html/boot-features-testing.html#boot-features-testing-spring-boot-applications-testing-autoconfigured-mvc-tests
前面有一篇文章提到硬盘使用率达到100%导致服务无法启动的问题。最后查出来是数据库的问题。但是当时没有做详细调查。这里简单写一下后续是如何解决这个问题的。 首先通过phpmyadmin打开数据库。具体如何访问phpmyadmin这篇文章有写。然后看了下bitnami_wordpress数据库，发现唯有wp_options这个表如此之巨大。有66G之多。 wp_options这个表，只有option_value是longtext，查看了下容量最大的前10条，并没有发现什么异样。 这就有点不知所措了。所以去网上搜了以下，确实也发现有碰到同样问题的。网上的处理一般有两个步骤：1. 安装 WP-Optimize 进行优化2. 删除 option_name like ‘%_transient_%’ 行 两个方法都尝试了以下。都没有成效。尤其是删除_transient_行，删除以后5分钟就又自动生成了(貌似类似于cache的东西)。最后没有办法，把wp_options表进行手动备份，发现只有1M多。mysql的具体存储机制尚不太清楚，估计是wp_options已经申请了太多的tablespace。所以干脆就drop掉table，然后把刚才手动备份的wp_options重新导入。这样wp_options的表空间就恢复到2M多了。
第一步找到以下文件 第二步修改文件，加入本地机器的global ip address到白名单中 第三部确认phpmyadmin的登陆密码 第四步通过 http://[パブリックIP]/phpmyadmin 地址登陆 参考：https://note.com/ryutakimuravc/n/nf41e6932ad8f
拿lightsail搭建的wordpress最近十分的不稳定。动不动就503错误。开始以为是某些plugin作妖。就尝试了一下隔断时间重启instance。通过lambda脚本跟定义cloudwatch上的rule可以简单的实现。lambda脚本如下： 刚开始的两天这个还算好用，可是又没过几天，连重启instance都不管用了。一直503状况不断。登陆进去查看了一下。打算重启下service来着。 但是重启不成功。disk usage 100% error。硬盘容量不够了。df -h 查看了一下，确实 / 路径下可用已经为0了。 然后，又打算sort head查下使用最多的路径。无奈du也不能用了。 这可怎么办才好。要不要尝试着增加个disk吧。但是查了几篇文章。发现新增disk必须新建目录。单是问题是我现在 / 目录下的东西还是100%。所以这个方案就放弃了。 剩下就是看删点什么东西了吧。尝试了数次，最后找到了apche存放log的地方。sudo rm -rf *.gz 删除了所有log的备份。这下解放了1个多G的空间。 然后重启service，一切就回复正常了。service重启完以后，又重新看了下最费硬盘容量的几个路径。发现这个mysql/data/bitnami_wordpress 自己就占据了67G。这应该就是罪魁祸首了。但是具体为什么占了这么多容量还不太清楚，下次有时间再继续分析。 参考：https://dev.classmethod.jp/articles/add-storage-to-lightsail/
常见的数据访问的写法大概有以下几种： Native SQL JPQL Criteria API Spring Data JPA 其他框架(jooq、MyBatis等) Native SQL Native SQL 算是最简单，也最直观的使用方法了。EntityManger是JSR标准里面提供的，所以不需要依托任何框架就可以使用。 JPQL JPQL跟Native SQL相比，其实也是大同小异。只是把select部分省略了。 Criteria API Criteria API 其实功能很强大，但是就是写起来太复杂。理解起来也比较费劲。在项目中实际使用的其实很少。 Spring Data
前两天面试一个remote职位，一个技术型的面试官，问的特别细致。还记得其中一个是关于Github action的安全措施的。这个考官也十分新奇，问的都很抽象。他就问我在Github action中，都采用了什么样的安全措施。我当时也是有点蒙，细节部分当时确实不是很清楚，直接说了句把重要信息都存在了Parameter Store来敷衍了过去。所以也是为了给自己补补课，打算重新再认真总结下WEB系统常见的安全措施。 WEB安全，主要分为两个大块。一个是Application层面，一个是Network层面。Network的话，我自己也还不是特别熟悉，这次先主要总结下Application层面常见的应对措施。 账号安全 CORS Cross Site Scripting SQL Injection ClickJacking POST、GET等Request Method的正确使用 系统信息的加密，hash化 账号安全 主要包含账号注册，login，logout相关部分的处理。账号注册方面：・要注意不能使用太简单的密码，密码要经过加密处理・为了避免恶意注册，要添加2段认证，比如通过email注册login：・页面里的auto complete最好关闭・如果使用java的session管理功能的话，login前后的JSESSIONID务必要刷新・为了防止暴力破解，要加入login尝试次数限制的机制logout：・logout不只是页面的迁移，之前的认证key也需要进行invalidate处理 CORS 使用API时有时会需要跨域，最好通过ALB的设置解决，商业环境ajax的跨域设置最好要关闭。Spring的话可以设置某些指定环境才打开CORS。 Cross Site Scripting 通过往数据库里写入script，然后在画面显示的时候去执行这些script。以用来窃取用户本地的信息。
Github action：主要用来做CI/CD整体的控制，包括何时build、何时test、何时deploy到相对应环境中去 ECS：用来用来管理docker image 的repository，以及自动发布 解读下上面这段代码。1. 开头的 on 部分这里是指定GitHub action的trigger，可以是push，可以是merge，也可以是publish。 2. Maven Build在GitHub的虚拟环境中执行build的相关指令。 3. Configure AWS Credentials设置AWS的访问密钥。因为yml文件是需要进行版本控制的，为了更加安全起，就将密钥信息写在了GitHub的Secrets里面，这样就避免了在代码里的明文。 4. Deploy docker image这步是将build完了jar文件上传到ECR中，发布在ECS上面的，其实就是一个个的image。 5. Render Amazon ECS
Design（システムにとって適切な設計か？） Functionality（作者が意図したとおりに振る舞うか？） Complexity（できるだけシンプルになっているか？） Tests（適切な自動テストが備わっているか？） Naming（変数やクラス、メソッドに明確な名前が付けられているか？） Comments（コメントは明確で分かりやすいか？） Style（コードはスタイルガイドに従っているか？） Documentation（関連するドキュメントは更新されているか？） https://google.github.io/eng-practices/review/reviewer/
