add final slides before presentation

diff --git a/js/slides.js b/js/slides.js
index 078d1949544b558c54bf8044fc0990c5eca54956..1c14dd2f4dcfcb8a767e027e51a2f94a2afca90e 100644 (file)
--- a/js/slides.js
+++ b/js/slides.js
@@ -1 +1,2 @@
 createHotkey(1, 'graph-eventloop');
+createHotkey(2, 'graph-reactor');

diff --git a/notes.txt b/notes.txt
index 3aca42177364452f7878280255459afb5ee118cc..7af3f6e27fce1d08ff7cdf8a72493063b0cb1266 100644 (file)
--- a/notes.txt
+++ b/notes.txt
@@ -1,8 +1,8 @@
 
 TODO:
-- Get more knowledge about the Reactor front ends.
-- Throw up some examples in some slides (#5).
-- Add a section at the end to get out of the weeds and put a bit ol' bow on it.
+X Get more knowledge about the Reactor front ends.
+X Throw up some examples in some slides (#5).
+X Add a section at the end to get out of the weeds and put a bit ol' bow on it.
 
 Topics:
 

diff --git a/slides.html b/slides.html
index 4da6ba0c16f4afec585ea38ac1102fa99c2b8b80..745bf127db87dedbe3ae370155dfe02d9c935c1b 100644 (file)
--- a/slides.html
+++ b/slides.html
@@ -444,6 +444,12 @@ while (1) {
 }
 ```
 
+???
+Of course, you don't actually need to know anything about which syscalls are used and how a reactor actually works to do
+event-driven programming. (and if any of this is going over your head, that's fine.)
+
+But I'm covering it because I think it's good for you.
+
 ---
 class: ex-basicreactor2
 
@@ -1203,13 +1209,60 @@ my $eventual_future = repeat {
 ```
 
 ---
-## Events in the world
+class: center, middle
+
+## Final thoughts
+
+---
+class: center, middle
+
+### Proactor pattern
+
+???
+We've gone over the Reactor pattern quite a bit, and for good reason.
+
+It's the predominant implementation of event-driven code in userspace apps.
+
+But you should also know about the Proactor pattern.
+
+It's basically the same as the reactor pattern except the event handlers perform asynchronous operations.
+- Can be done using special kernel facilities
+- or by keeping a thread pool.
+
+One thing to keep in mind about the reactor pattern is that any sort of blocking that occurs by any event handlers will
+slow everything down quite a bit. The proactor pattern can help avoid problems.
+
+---
+class: center, middle
 
-- Interconnected devices
+### Event-driven <strike>programming</strike> architecture
 
 ???
-- Events are everywhere in the world, and our devices can tell other devices about them.
-  - Interconnected devices (IoT)
+Making your apps reactive and able to generate and respond to events is the tip of a very large iceburg.
+
+- Pubsub systems can be used to distribute events at a massive scale.
+- Message queues are components that can be plugged in to provide guaranteed delivery of events.
+
+Once your programs are event-driven, they're ready to be plugged into a whole world of other services.
+
+---
+class: center, middle
+
+### Lots of interconnected devices
+
+???
+This concept has a trendy name, but I can't say it because I've swarn off buzzwords.
+
+Event-driven programming and architecture is used as a foundation for building APIs and applications that scale, if
+that's important to you.
+
+You can avoid coupling: When one of your devices has an event, it just needs to notify your world of devices and let the
+devices decide what to do.
+
+For example, if your car has connected sensors, it can notify your devices when you leave the car. Then your phone can
+receive that event and notify you that you left your kid in the car.
+
+So there are a lot of cool applications for this stuff.
 
 ---
 class: center, middle