Typical development mistakes and problems

In process of developing server side of the interactive internet TV for one of the major Russian TV channels (REN TV) developers (and author of this keynote) have build a complex system, which interacts with a TV software, CDN & videos converting and streaming system, Erlang-deamons for monitoring the state of the air and the Rails app.

A lot of problems in the process (management and development) were met. In this keynote author will share an experience he got while working on this project.

2011, RUBYC, Kiev

Transcript

1. Typical development problems and mistakes Online TV for REN TV http://ren-tv.com Timothy N. Tsvetkov 2011, rubyc, Kiev
2. Evil Martians
3. Air and live
4. Genres
5. Personal playlists
6. REN TV is The best Online TV in Russia
9. Architecture
10. Planning • We have planned API to develop • CDN Video have planned API to develop
11. Real life • CDN Video API changed
12. DDs • BDD • TDD • CI • ADD • DDD • ASP .NET MVC 1.0
13. Truth • BDD — Body Dysmorphic Disorder • TDD — Test Driven Development • CI — Convergence insufficiency • ADD — Attention Deficit Disorder • DDD — DDD
14. Testing limitations • We can’t test everything • You can’t develop an algorithm to proof that your program is correct • Testing is hard • Tests have errors • Not that effective at finding bugs
15. Race conditions • Most developers don’t think about race conditions • Validates uniqueness is not race conditions safe • Some gems are not race conditions safe and it is your business to check them
16. Optimistic locking • Each update to the record increments the lock_version column and the locking facilities ensure that the records instantiated twice will let the last one saved raise a StaleObjectError if the first was also updated • Doesn’t work between actions like edit/ update
17. Pessimistic locking • SELECT FOR UPDATE • FOR UPDATE causes the rows retrieved for by the SELECT statement to be locked as thought for update. This prevents them from being modified or deleted by other transactions until the current transaction ends
18. Advisory lock • Locks that have application defined meanings
19. Advisory locks. Usage
20. Test on race conditions • It is hard to find them and there is no tool for that • You can use test hooks in your production code for testing them in your rspec
21. Deamons • Erlang is great • Node.js sucks
22. Deamons v. 1 • Rebar to install debs, compile and start • Classical OTP: Supervisor + fetchers, monitors
23. Deamons v. 2 • Supervisors spawns workers • Workers spawn fetchers and monitors them • Worker never die
24. Deamons v. 3 • v. 1 without Rebar but with Runit
25. Investigate a problem • Log everything you can • strace, tcp dump, netcat, gdb • etc
26. Special thanks toYaroslav Markin
27. Dumb questions