Introducing the Team and Its Work

Our team is the Woven Payment Solution Development Group.
However, before I tell you about our team, I need you to know a bit about Woven City. Woven City is both a test course for mobility and a city for conducting demonstration experiments, where Toyota Motor Corporation is developing technologies with the aim of “mass-producing happiness.” The development of Woven City is led by Woven Planet Holdings, a member of the Toyota Group.
Our team is working with members of Woven Planet’s Payment Solution team and other teams to develop payment services to be used in Woven City. KINTO Technologies and Woven Planet are separate companies, but when it comes to the development work, we are working as one team without particularly being conscious of that.
Woven City is a mobility test course for inventing the commonplace things of the future, and we are also required to develop features that will contribute to that. In Woven City, all the residents and other people involved are either inventors who create new value in some form or other, or people who create inventions together with them. That means those inventors must be provided with the features and data that they need to create better products, services, and the like. This is a big difference between general payment services and the ones we make.
For example, for how a given service accepts payments from users, we are thinking about UX aspects such as making it easier to consider things like whether the best option is prepaid, postpaid, recurring payment, or some other method. We are also looking at the data provision aspects, and thinking about providing not just the payment information but that combined with other Woven City data, in a form that will enable things to be considered from multiple angles. Of course, these kinds of data are not only provided to inventors, but also used to kaizen the system that is Woven City itself. (Of course, we never obtain people’s personal information without their consent.)

How We Work

The Payment Solution team, including the members from Woven Planet, is doing the development work remotely from home. However, we come to the office once a week on Wednesday, giving us an opportunity to communicate directly with each other. We use Google Meet and Slack for our communication tools. In Woven Planet, the basic premise is that communication is in English, so we converse in that, especially if there are non-Japanese speakers present. Also, on Slack and in documents, communication is done in English even when it is between Japanese people. We also use English for postings that are like talking to ourselves, so if we write about something we are concerned about, it sometimes leads to getting advice from other teams or sparks a discussion. Besides that, other teams also sometimes consult us, and sometimes, that can lead straight into starting up an oral chat via Huddle, for example. So, there is lively communication even though we are working remotely.
When we come to the office, we enjoy the stimulation you can get from actually meeting people in person, such as discussing things face-to-face and eating the company food together if our lunchtimes coincide. Our development work also gives us opportunities to visit the planned site for building Woven City. Woven City itself is currently under construction, so it looks different depending on when we visit, and although there are still many vacant areas, it is a useful experience for expanding our mental image of it actually being used.

Technologies We Are Using

Programming language

Kotlin

Our team’s scope is server-side applications, and we use Kotlin to develop them. A major reason why we chose Kotlin is its high interoperability with Java. There are already a great many Java engineers in KINTO Technologies and the group, and we are hoping this will induce them to join our team quickly. I myself have experience of using Java in the past, and had a go at building simple web applications with Kotlin several times as part of introducing it. Through this, I became able to code in it about as smoothly as in Java and with no real problems just by referring to the official documentation a bit.
Some of the members have experience of server-side development in other languages like Go, C#, and Ruby but none in terms of Java itself, but they can all use Kotlin with no real problems now, too.
Initially, we used Kotlin as a better version of Java, but now, we are starting to forget about Java and consciously use Kotlin for its own merits.
Additionally, we use Gradle for project management and write the configuration files in Kotlin Script.

The main libraries we are using

Ktor, Koin, Exposed, Kotest, MockK, etc.

Our services consist of several application services, many of which are web services with a REST API. You can use Spring MVC and Spring Boot with Kotlin as well, but we chose Ktor instead. We chose not to use Spring because we wanted to avoid code that is heavily annotated and feels like magic. However, we still wanted to use a dependency injection mechanism for testing and dependency management, so we adopted Koin as our DI library. Koin also has an annotation-based configuration method like Spring, but it has a DSL-based configuration method as well, and we are using that one. Although it requires knowledge of Koin and of DSL itself, DSL can be incorporated into normal Kotlin code more naturally than annotations, so I feel you can express your intentions clearly in it.
In addition, we use various FOSS libraries, such as Exposed for ORM and Kotest and MockK for testing.

Ktor official website
Koin official website
Exposed GitHub repository
Kotest official website
MockK official website

This is more of a personal interest than a team one, but since Ktor also works in GraalVM, I would like to try doing a native build with GraalVM if I get the chance.

Reference: https://ktor.io/docs/graalvm.html#prepare-for-graalvm

Application Infrastructure

Kubernetes

The applications we are developing are deployed on Kubernetes, and for the services we are developing ourselves, we write the configuration files ourselves in YAML. Another team is in charge of the development and operation of the Kubernetes environment as a whole, but this team has also prepared a CD mechanism. Basically, if we turn the new configuration data into PRs then review and merge them on GitHub, everything right up to deploying the apps gets done automatically. The team also responds to requests from us about configuration, architecture, and so on, so they are always a tremendous help.

How We Do Development

Because of the project’s unprecedented nature of creating a city that functions as a test course, there are many unknowns not just in the parts that our team is working on but in the whole thing, too. So, using as a foothold the features that will be required as a matter of course, we are coming up with rough hypotheses and development plans, and are learning about our own services ourselves as we create them, and about Woven City, too. Specifically, the process we are following is to set a big theme for each quarter, add or update features as needed for that, then check them by running small demos in the office. For this reason, we adopt an agile development method, we do the development iteratively with two weeks as the timeboxes, while managing the backlog with Jira. We are not following strict Scrum practices, but are seeking to adapt to the facts that come to light and changes in requirements that arise along the way as we develop things.

Conclusion

What is difficult about this project is that, at this point in time, the real test course that is Woven City still does not exist, and of course, the users are only potential ones, too. This goes for all teams and not just ours. It often happens that another team wants to use a feature that is still in development, but it is still unstable. On the other hand, you could also say that since there are no general users, it does not matter (at least now) if things are unstable to a certain extent. While being in this unstable state can be taken as grounds for not using each other’s creations, it can also be relished as an opportunity to improve them by respectfully but frankly pointing out their defects, all in the spirit of forging and honing them together through use. We definitely want people who think in the latter way to take part in our project.