the big board the big board
play

The Big Board. The Big Board. Jeff Heard Jeff Heard The - PowerPoint PPT Presentation

The Big Board. The Big Board. Jeff Heard Jeff Heard The Renaissance Computing Institute The Renaissance Computing Institute jeff@renci.org jeff@renci.org http://vis.renci.org/jeff http://vis.renci.org/jeff The problem. Disasters don't


  1. The Big Board. The Big Board. Jeff Heard Jeff Heard The Renaissance Computing Institute The Renaissance Computing Institute jeff@renci.org jeff@renci.org http://vis.renci.org/jeff http://vis.renci.org/jeff

  2. The problem. ● Disasters don't obey state or county lines nor resource constraints. ● Thus resources for one disaster need to be coordinated effectively across boundaries. ● EMs need a geographically coordinated shared workspace. ● Most natural shared workspace is a map.

  3. Existing Solutions. ● Google Maps / Earth – Content is static ● ArcInfo – Solutions are difficult to integrate ● WebEOC – Non georeferenced ● Pen and Paper – Need I really say more?

  4. The Big Board. ● T eleconferencing over maps ● Realtime content creation and generation ● Orthophotography or vector layers ● 100% Haskell with Python server-side. ● Directly uses Hieroglyph, buster, haxr (xml-rpc), mtl (applicative), gtk2hs, parsec, HTTP 4000.x, bytestring.

  5. Why Haskell? ● Memory and speed efficient executables. ● Excellent graphics libraries. ● Reliability through type-safety. ● Rapid development. ● High level of code reuse.

  6. FP vs. T raditional vis. ● Visual Semantics – Visual meaning vs. data and purpose of application. ● Abstracts away from process of drawing. ● Ties visual representation to data closely.

  7. Interactivity via FRP . ● Functional Reactive Programming models interactivity via behaviours and events. ● Behaviours react to events. ● Buster, TBB's FRP system is a broadcast FRP as opposed to an arrow- based FRP .

  8. Postmortem. ● The Big Board: – Less than 1000 lines of app-specific code. ● T wo libraries, plus the beginnings of a third. – Hieroglyph for pure-functional vis graphics. – Buster for “app-orchestration” – Beginnings of GIS library for parsing WKT, WKB, PROJ, and interfacing with libproj2

  9. Advantages of FP . ● Rapid development. ● Encouragement of reuse and small understandable codebase. ● High performance compared to other high-level languages. ● Active and responsive dev community on #haskell and [Haskell-cafe].

  10. Disadvantages of FP . ● Relatively small dev community, ● Dev community overlap with the graphics community is not yet all that large. ● Much of FP is still theory-focused. ● Few colleagues at my office understand FP or think they have time to learn.

  11. Lessons Learned. ● Shortcuts are generally the long way around. ● The type system should be used to concentrate on semantics rather than modularization. ● “pure” functions preferable to IO functions, because it encourages deeper thought about the problem. More reuse, clearer code.

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend