It was the 10th anniversary, and since it’s ending this year, I participated in my first and last “YAPC::Asia Tokyo”.
The flow of each talk session is summarized on Togetter, so it’s good to search from here.
Below are the talks I attended and my personal notes & impressions.
世界展開する大規模ウェブサービスのデプロイを支える技術
With many servers across AWS US/JP/EU 3 regions, git pull becomes heavy.
- Synchronization to Git Slave
- Load issues when pulling from Git Slave
Apparently they use Mackerel: New Generation Server Management & Monitoring Tool.
Synchronizing GHE and Git Slave repository is difficult, so they created a new repository sync system.
Impression
I’d like to consider Consul + stretcher deployment when the scale gets large. It doesn’t seem like I need to worry about that for a while though.
Also, recently there’s AWS CodeDeploy (Automated Code Deployment to Amazon EC2 Instances), but I wonder how that is?
今フロントエンドで何が起こっているのか
- Slides: What's happening in frontend now? // Speaker Deck
- YAPC::Asia Tokyo 2015で「今フロントエンドで何が起こっているのか」という話をしました - blog.koba04.com
Impression
I hadn’t properly grasped recent frontend developments, so it was good to understand the general flow.
Conway's Law of Distributed Work
The presentation covered tools and mindset to use for effective work in distributed teams.
In Distributed Work, you can save time with effective communication.
When doing remote work, it’s important to make people feel included in communication as if they were physically present.
Commit Messages
Have conversations through commit messages. As an archaeologist, wouldn’t you want some clues when digging up code later?
The information about “what you were thinking and why it turned out this way” is sometimes lost. This needs to be preserved.
CODE REVIEW
There’s analysis showing code review can reduce bugs by 60% (apparently).
Suitable for asynchronous communication. Don’t expect immediate responses.
Everyone should experience remote work. First, it’s important to understand the challenges, empathize, and improve.
Have on-site meetups Create opportunities to gather regularly.
Over communicate. This doesn’t mean “constantly talking”. It means being conscious of “constantly writing”.
Share your personality Try to share your individuality and personality. Share through daily text chats. Prepare an Off Topic Slack channel.
Exhibit a “visible pulse.” When working remotely, you must appeal what you’re doing.
Pick a timezone. Standard Operating Time (SOT)
CAP THEOREM (SOME LIMITATIONS)
The CAP theorem also applies to remote work.
Q&A
Q) Remote work can sometimes lead to overwork, how do you handle this? A) Yes, it happens. But then family gets lonely. Discipline yourself. Manage your own schedule. Timing to leave the office, rest when tired.
Make it a team habit to say “you’re working too much, you should go home.” Approach your work with some leeway.
Q) Isn’t remote work difficult when timezones are different? For example, Japan and America. A) You should place teams of several people in Japan and America respectively. My opinion) I’ve practiced this before, and there were overlapping hours, so it wasn’t particularly a problem.
Q) How often do you meet face to face? A) Once per quarter is minimum At those times, don’t get buried in code. Make it a place for medium to long-term discussions.
Q) Mobile is an important tool for remote work, do you use it? A) It’s convenient. It becomes frustrating for friends and family. Sometimes you should put your smartphone aside.
Impression
I had experience with remote work, so I could do good reflection by comparing it with my own case.
The example of “archaeologists wanting hints when excavating” was easy to understand when talking about how important commit messages are. I’ll use this example next time I explain the importance of commit messages.
※ An archaeologist’s job is “searching for traces left by humanity such as ruins and archaeological sites, excavating them, and studying past human activities and changes”
Electron: Building desktop apps with web technologies
Impression
It was a demo-centered session.
I don’t have plans to develop desktop apps in the near future, but if I do, I’ll probably use Electron first.
esa.io - 趣味から育てたWebサービスで生きていく
“Want to develop enjoyably!”
I haven’t been able to do this much lately, so I want to follow their example.
Don’t set development schedules
- Develop when motivation rises.
- User feedback leads to motivation.
That’s ideal. I’m curious about what they do when motivation for development itself doesn’t rise.
Lightning Talks Day 1
I listened to all the LTs too.
懇親会
I forgot to apply for the networking party, but someone transferred their ticket to me so I could enter. Thank you!
That’s all from participating in YAPC::Asia Tokyo. That’s all from the Gemba.