CSP: Huh? And Components

203
-1

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
203
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Hello World
  • CSP: Huh? And Components

    1. 1. CSP: Huh? And Components @TheHydroImpulse hydrocodedesign.com github.com/TheHydroImpulse
    2. 2. Communicating Sequential Processes
    3. 3. • I won’t be getting into the complex theory. • I’ll be going into the practical examples of CSP.
    4. 4. Concurrency What is it exactly?
    5. 5. Concurrency != Parallelism • • • Concurrency is a model for concurrent execution. Parallelism is the literal act of being concurrent. With concurrency, tasks are able to run at the same time, but they don’t have to — that’s parallelism.
    6. 6. CSP: Huh? • A formal language for describing patterns of interaction in concurrent systems. • based on message passing via channels.
    7. 7. Channels • A powerful primitive for communication • Channels are exactly what you think it is; they let you pass stuff through it. • Two basic actions: Put & Take Input Channel Output
    8. 8. Kinds of Channels Buffered Unbuffered (Can be dangerous)
    9. 9. Basic Actions • Put: Send a new value onto the channel • Take: Receive on existing value from the channel.
    10. 10. Channel Semantics • Semantics vary on the language/implementation. • The basic semantics are: • on share-ability of concrete channels. (i.e., across tasks/threads?) • when channels block
    11. 11. Blocking • Can block when trying to put a value onto the channel when it’s full. • Can block when trying to take a value from an empty channel.
    12. 12. What Blocks? • Very much dependent on the implementation/language. • Golang blocks on goroutines (a.k.a green threads) • Rust blocks on tasks (a.k.a green threads or native threads) • Clojure (core.async): both actions have the potential to block the underlying thread.
    13. 13. Clojure: core.async • A library not a language feature. • Goes to show how powerful a consistent language form (Lisp) can be, thanks to macros. • Supports unbounded buffered and bounded buffered channels. The former is discouraged. • Two implementations of the underlying “threads”. • Supports timeouts (super powerful) • All operations are expressions not statements. • Priority selects with alts!
    14. 14. Clojure: core.async • Supports two kinds of thread of control: • • • IoC (inversion of control) Normal Threads IoC threads are created with go blocks • go is a macro that examines it’s body for any channel operations and turns them into a state machine. • C#’s async does the same thing.
    15. 15. Clojure: Example!
    16. 16. JavaScript Example! • Uses ES6 Generators • Similar to ClojureScript/Clojure’s go blocks.
    17. 17. Callbacks (Direct Data-Flow) • Worst style of concurrency • You have no control over the data flow. • You’re (the callback) at the mercy of the caller.
    18. 18. Direct vs Indirect Direc t In Callback/Logic Out Indirec t In Channel Logic Channel Out
    19. 19. Indirect = Channels • Channels offer a better alternative at managing data-flow. • They are indirect. This means the logic is in control of the data-flow. • The logic can decide when it’s had too much data coming through. It’s the best decider at judging how much it can handle.
    20. 20. Examples! • Return the 5 fastest search queries. • Return the x number of queries that finish within 3 seconds (timeouts) • Channels act like queues. They’re a buffer for your data.
    21. 21. Components Building modular applications.
    22. 22. Components • Not an abstract component. • https://github.com/component/component • A client-side package manager and build tool. • CommonJS style code. • Ability to share client and server code super easily.
    23. 23. Unix Style • Build small, concentrated applications that do one thing, and does that thing extremely well. • Modular • Modular • Modular
    24. 24. Globals..grrr • Globals are horrible. Never use them. • Globals are horrible. Never use them. • Globals are horrible. Never use them. • jQuery, Angular, Ember, etc… ALL use them.
    25. 25. /** * Module Dependencies */ var dom = require('dom'); var model = require('tower-model'); var migration = require('tower-migration'); /** * User Model */ model('user') .attr('email') .validate('presence') .validate('isEmail') .attr('firstname') .attr('lastname') .attr('country') .attr('city'); /** * Migration */ migration.up('create_user_table') .model('user');
    26. 26. Creating a Component App
    27. 27. Modular Apps • It’s the future • Building monolithic apps suck • Tooling is only going to get better. • It’s much easier to wrap your head around a single module that has no side-effects (i.e., no external state & globals).
    28. 28. Server & Client-side • Node.js offers the ability to share code with the client-side (components). • Both have the same module pattern (CommonJS • Module can now be designed for both platforms.
    29. 29. No Globals? • We can take advantage of the module caching. • A version of inversion-of-control • Decentralized.
    30. 30. Module Caching • If each module is concentrated, you can store data (instances, values, etc…) in the module exports or module itself. • Example!
    31. 31. Wrapping Up • CSP is awesome. • Clojure is awesome. • Message passing & channels are awesome. • Modular apps are awesome. • Globals are horrible. • Callbacks are horrible.
    32. 32. Resources
    33. 33. Components & ES6 • Module system in ES6 replaces the build system in component. • Components might just become a package manager.
    34. 34. Thanks! @TheHydroImpuls e github.com/TheHydroImpulse hydrocodedesign.co m
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×