[* Java *] I went to JJUG CCC 2017 Fall
Introduction
We participated in JJUG CCC 2017 Fall.
I was drinking the day before, so I started participating in the afternoon.
It is a memo at that time.
Session list
- CQRS ・ ・ ・ Separate writing model and reading model
- As the system grows, write control becomes more complicated, and multiple tables are referenced for reading.
- Differences in write and read requirements
- When separated, you can write with good processing efficiency and the code is simple.
- ORM ・ ・ ・ Object-centric and SQL-centric
- Object center ・ ・ ・ Hibernate etc.
- SQL-centric: jOOQ, JPQL, etc.
- Hibernate and jOOQ can be used together
- Question "What is the performance?" Answer "This time it was an internal system, so I didn't attach much importance to it."
- The problem that CI time is too long and can only be turned once at midnight
- CI should be fast (10 minutes or less, 20 minutes or less at the latest)
- If the CI becomes long, it is difficult to identify the cause when there is a problem due to a mixture of commits by multiple people.
- Engineers also forget that CI is spinning around with their own commits
- CI is not over and release is delayed
- I used CI for build and unit tests, but unit tests were a problem.
What i did
- In principle, we did not perform tests that cross layers of Controller ⇛ Service ⇛ Repository ⇛ RDB…
- Annotation change:
@SpringBootTest is heavy because all beans are registered and it starts up to the web server, @WebMvcTest is fast because only the necessary beans are registered.
- Since the Service layer does not interact with the outside of the application, do a simple JUnit test and do not use DI
- Bean selection by Filter in Repository (I didn't do it) ... The actual degreasing is scary, and the wheels will be redeveloped even if it operates
- Improving debt-based tests: More tests for development of a certain scale, crushing one by one, reviewing, crushing if late, etc.
- Delete test: The test itself has the advantage of running it many times, and leaving a test that is difficult to maintain is a disadvantage, so decide to delete it.
- CI reconstruction & parallel test environment construction: CI was not so important, so I was doing it on my personal PC ⇛ Moved to AWS, what can be solved with money should be solved with money
- Introducing test size: Introducing test size advocated by Google, test execution timing JUnit
@Category, maven-surefire-plugin groups
- FeedBack of pull request: Feedback to the developer is made faster for each pull request. Various things that can be done on the pull request can be fed back (improvement of CI fulfillment).
It's faster and easier to give feedback!
Question:
I think there is a more complicated system, but this time the layers were properly separated, so it seems that this kind of improvement was possible.
Answer:
It's a recently made product, and it's relatively clean, so it's divided into layers.
If the code itself is messed up, you first need to refactor the code itself.
- It's hard to create an environment for each project on the development PC one by one.
- [Docker demo] It didn't go well
- A mechanism to raise a virtual process by downloading a container image from Docker Hub and instantiating it
- JavaEE environment can be done with only 3 commands
- No Java IDE is Docker friendly
A lot of samples of Eclipse Collections were introduced and I was looking at it
- Operation of an app called Pictolink targeting young women, 13 million members
- DB connection URLs of various projects and tools ⇛ Modify all project files when replacing DB
- The Twelve-Factor App Ⅲ. Setting: Enter the setting value in the environment variable and refer to the application.
Spring Cloud Config: Get configuration from repository and return as JSON- JavaScript dependency resolution: More things I want to do on the front end ⇛ I have dependencies between files ⇛ It's hard to remove features
- I tried to use
Require.js, but dependent JS execution is slow ⇛ Use webpack to make one JS! ⇛ Node.js environment required, transpile required
- Installing Node.js is difficult for non-engineers
- Use Gauge for UI test automation
- You can write test contents in Japanese by using
Gauge
Selenium makes it program-like, but Gauge allows non-engineers to write.- The disadvantage of
Gauge is that it may not work if you upgrade to the current beta version, and the definition of steps tends to be confused when there are many tests.
Gauge project structure (Gauge ⇛ Gauge Java ⇛ DbUnit and Selenide)- It's important to improve!
in conclusion
I can't just introduce something useful, but
I thought it was important to improve it in a positive direction, even little by little.