We interviewed the hot startup company listed recently this September, Pixta Inc., owner of the largest stock photo website "PIXTA"
PIXTA is a stock photo website where you can purchase more than 15 million high quality, low priced, royalty free stock images from as low as 100 yen. I visited the site just now, and I found out for the first time that even illustrations, stock videos, and seasonal materials (such as new year's greeting card materials) are on sale there. Study sessions and Communities of Ruby in the Shibuya neighborhood are often held at Pixta, so Ruby programmers living in Tokyo may already be very familiar.
I am informed that Pixta do their development in Japan and Vietnam, two offices, 4 teams total. This time, we interviewed three members of the generic technology team.
Mr.Sato: First of all, development is done at PIXTA's development team with roughly 4 kinds of teams. At PIXTA, we sell materials contributed by creators to buyers as a online marketplace.
Mr.Sato: So, the development team is divided into 4 teams according to that business flow; 2 teams "for creators" and "for buyers", "Vietnam team" located at Vietnam, and us, "generic technology team". Our role in the development team is something like a jack-of-all-trades, but we are responsible for the so-called DevOps parts.
Mr.Goto: It is expected that the independence of each of these teams will increase in the future. Our job is to support the teams and to commonalize and standardize as the development department, so that the teams can be maintained and scaled-out.
generic technology team Mr.Sato
Mr.Sato: To be honest, first was out of curiosity. I happened to try SideCI out shortly after it was released. At that time, it was not well refined yet, like the timing and amount of comments SideCI made on GitHub not being appropriate. I have talked about issues like this with Mr.Sumi of SIdeCI. Then, it was improved gradually, and we started using SideCI full-scale from this year.
Mr.Sato: At the start of this year, we discussed and set coding rules in our company. We had experimentally introduced several tools to check coding rules other than SideCI, like "HoundCI", but we chose to unify the functions and use only one tool.
Mr.Sato: Personally, among the tools SideCI supported, the one that I was most grateful for was brakeman. Considering security issues is a must. We used to run penetration tests, but products that scan forsecurity holes compatible with Rails are not seen much, even commercial ones. With SideCI, you can use that brakeman, has Rubocop, Reek, and rails_best_practices. There are all the functions you need. So, we decided on the sole use of SIdeCI, having the most compatible tools and being easy to use. SideCI is good, since you can easily use many tools, and the settings are easy too.
## Really convenient when the places and languages of work are different
- How was it?
Mr.Saeki: I really appreciated SideCI when we started up the Vietnam Team around summer. Being right after the startup, the engineers there don't know Pixta's coding rules. If you only give them a document about it, someone will need to check if the rules are followed properly when reviewing codes. This is definitely not a fun task, and inefficient to start with. Communication with the Vietnam team is obviously remote, and our languages are different. In this kind of situation, requiring humans to check each time if the coding rules are followed takes much effort. By introducing SideCI, checks and indications became automated, so those laborious tasks were taken off humans.
Mr.Saeki: If we wanted to apply the same coding rules to another team, we could just give them Rubocop's config files, and they're good to go. I was really happy about this.
Mr.Saeki: I think SideCI is a necessary tool when setting up environments at the start of a project, or creating teams.
generic development team Mr.Saeki
## The pros of "bot indication"
Mr.Goto: When reviewing codes, we want to review the essential parts, like design, but when the coder is new to the company, there are times that the code does not follow the coding style set in-house. Whensomeone starts reviewing that, both the reviewer and reviewee get tired, and find it annoying, so being able to indicate these with a non-human account, and having the reviewee request a code review after fixing those is very useful.
generic technology team Mr.Goto
## Future work
- Are there any future works?
Mr.Goto: In Pixta, we have the statement: "the phase of 1→10 is done. Next is 10→100" set company-wide. To accomplish 10→100 faster, we aim to create a structure for scaling.
Mr.Saeki: We hold up "PixtaWay" for Pixta's code of behavior, and what we talked about now is included there.
Mr.Saeki: Incorporating SideCI is part of "Standardization for Scaling". Detailed checks in code reviews could be managed by humans in the 1→10 phase. However, when it comes to the 10→100 phase, it becomes a different story.
Mr.Saeki: Not only SideCI, we will keep on standardizing and automating for scaling in other parts as well.
Members of Pixta. From the left, Mr.Saeki, Mr.Goto, and Mr.Sato