veyepar: Space, time and state

Author(s):	Amy Palamountain
Location	Main Stage
Date	apr Mon 13	Days Raw Files
Start	10:00	First Raw Start	09:48
Duration	00:30:00	Offset	0:11:40
End	10:30	Last Raw End	10:33
Chapters	00:00 0:25:58 0:28:26
Total cuts_time	28 min.

http://lanyrd.com/2015/dotnetfringe/sdktqz/
raw-playlist raw-mp4-playlist encoded-files-playlist host mp4 svg png

assets release.pdf Space_time_and_state.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:
Locked:	clear this to unlock
Locked by:	user/process that locked.
Start:	initially scheduled time from master, adjusted to match reality
Duration:	length in hh:mm:ss
Name:	Video Title (shows in video search results)
Emails:	email(s) of the presenter(s)
Released:	has someone authorised pubication
Normalise:
Channelcopy:	m=mono, 01=copy left to right, 10=right to left, 00=ignore.
Thumbnail:	filename.png
Description:	Reactive this, reactive that. Building responsive and predictable GUI applications is what we strive for, and reactive programming is the new trendy way to achieve that. But, if you think about it, almost everything we program today can be given the description of reactive programming. We react to user input by changing our application state. The presence of state, and state that changes over time has important implications for our application architecture. It complicates things enormously. Writing reactive applications which are easy to reason about, is no simple task. This talk will reveal how reactive programming is only half the story of building responsive, testable and predictable applications. We will discover how applying a functional style to our code can allow us to clearly reason about, and react to user input over time. Using Reactive Extensions, we will explore what it means to mix traditionally imperative design patterns with functional reactive programming. We will discover that while the two ideas complement each other, managing state can prove to be an annoying wrinkle in your beautifully reactive code. Then we will take a look at some tricks you can use to remove the need for state without sacrificing clarity in your architecture. markdown
Comment:	production notes