Goodbye 2024
Overview
Month | Project |
---|---|
01 | Assistant System for Government Cloud Management |
02-12 | WebRTC PaaS |
- entered new company and joined new project
- webrtc paas
- about 30 members
- kind, skilled, talented and passionate
- learned a lot of new things
- webrtc
- service maintenance
- typescript
WebRTC
- webrtc is a protocol stack to achieve real-time communication, mainly using media such as audio and video via p2p
- tutorial is easy
- browsers provide simple apis for webrtc so app developers can easily use them in javascript and implement real-time communication apps if they are simple just like sample apps
- the protocol stack is very complex
- webrtc is not a just single protocol, but a protocol stack; consisting of many existing protocols like srtp, sctp, ice, udp, etc.
- these protocols were not tailored only for webrtc, and webrtc just uses part of them
- but to master webrtc, understanding those specification and actual working in detail can't be avoided
- i know that making my hands dirty and implementing something by my self is an important step to understand and satisfy my curious
- actually i started to write stun/turn server in ts
- it was for the first time to me to implement something following a specification like RFC
- and was good for study about networking
- but at the same time i feel that implementing webrtc from the bottom of the protocol stack could be kinda waste of time because webrtc is not using those protocol fully
- it would be good to touch only the part of those protocols on which webrtc depends if can...
- at least i wanna understand how rtp works for real-time media connection
- also knowledge about audio/video encoding is necessary
- just trying webrtc is easy, but controlling, optimizing and maintaining the service using webrtc is super hard
- webrtc itself is complex
- characteristics like real-time, asynchronous and of networking make the service more complicated
- tutorial is easy
- i often watch game streams on youtube or twitch so am interested in vod or real-time content delivery
- there are other protocols such as hls, rtmp, moqt, etc.
- i wanna get closer to it
- also i have a lot of benefit from remote working
- glad to enter such a field which is challenging but interesting
twada-juku
- entered to a study course mainly for tdd by t-wada
- i was already familiar with tdd but i got more confidence and structured knowledge thought the course
- developed a simple crud web app
- deployed it onto cloud run
- test size
- problem is that words like unit, integration, e2e have ambiguity
- define test size and name them like small, middle and large; the number of tests should shape pyramid
TypeScript
- improved developer experience of dev team
- update obsoleted packages
- fixed type errors and reduced suppressed type errors like using
@ts-ignore
,any
or so on- defined correct and flexible types
- replaced eslint with biome
- eslint v9 introduced new config format called flat config
- migration from >= v8 seemed not easy
- biome is much faster than eslint
- enabled to run app without source code build leveraging type inference and conditional exports
- introduced pnpm
- better performance than npm
- secure node_modules structure
- one of biggest motivation is that pnpm has features for mono repo such as workspace, recursive command run, prune other app code, etc.
- introduced zod
- modern and ts-community standard schema validation library
- there were many complex type guards written manually in our codebase
- writing complicated type guards manually is error-prone
- introduced changesets
- publish js-sdk packages on ci/cd; reduce the operation time to a half of it
WASM
- learned what wasm is
- wasm seems to be thought like the next tech of container?
- developed a ts library that loads wasm
- used vite
Scrum
- struggled team management
- our team has responsibility for develop and operation (not only deployment and server operation but also user's dev support)
- unexpected incidents and tech supports had made our planning difficult and taken away the time for development
- => calculated velocity and introduced buffer to time we can use for the sprint based on it
- utilized my knowledge and experience on scrum
- make scrum events smooth
- they had surly applied scrum framework but the development was not agile at all
- they've taken so much time for daily scrum, retrospective, and planning
- 2 hours daily scrum, 2 days retrospective and planning, or so...
- => set time box and shortened the time taken for events
- had them focus on the topic of discussion
- if discussion prolong and it's not about team management, schedule an isolated meeting about it
- had them focus on the sprint goal
- i think it's important for team to work together to achieve one important thing
- velocity had been low
- => set sprint goal like "make A enable to B" (define who is A and what is B explicitly)
- led team to more like "we're creating/committing to good product!"
- encouraged mob working e.g. mob-programming
- => the number of in-progress tasks decreased and the number of done tasks increased (burn-down chart became to decrease constantly)
- make scrum events smooth
Books
- High Performance Browser Networking
- Creative-Projects-for-Rust-Programmers
- Essentials of Programming Languages
- Computer Systems: A Programmer's Perspective
- read again and again to delve into actual implementations
- The Professional Product Owner
- Efficient Linux at the Command Line: Boost Your Command-Line Skills
- Systems Performance: Enterprise and the Cloud, 2nd Edition