• Tanmai Gopal
    Tanmai Gopal
    schedule 1 year ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

    From the perspective of one of the few companies in the country using Haskell in production (hasura.io), we will talk about the journey of using Haskell as a programming language to build and maintain real world software.
    From the burden of choosing a language that probably has a single digit number of active developers in the country, to
    the joys of a small team churning out code that just keeps on working.

    We'll go over how we created a team, organized work ("software development practices"), architecting code, tooling up, testing, performance tweaking and finally deploying a Haskell codebase. We hope that Haskell developers with some prior experience will be able to take away
    something new about the Haskell ecosystem, and those interested in just functional programming will see tangible value in how certain features unique to Haskell have an impact.

    Expect a case study, a review of some cutting-edge tools and how to use them, and some Haskell code samples that will make you grunt in geeky approval.

  • Liked Naresha K
    keyboard_arrow_down

    Rethinking HTTP Apps on JVM with Ratpack

    Naresha K
    Naresha K
    schedule 1 year ago
    Sold Out!
    45 mins
    Demonstration
    Intermediate

    HTTP application programming model on JVM traditionally has been based on the thread per request model. However increasing scale and complexity of applications are forcing the developers to think in new directions. Ratpack is one of such efforts. Ratpack is a collection of libraries glued with Java 8 and makes use of Netty, Guava and Reactive Streams. Ratpack also provides a Groovy DSL, helping developers to use declarative style.

    In this demo, I will explore the asynchronous programming model leveraged by Ratpack. Composition, immutability, laziness are the core techniques used in building an application, which in fact are the ideas from functional programming. Though Ratpack has a variety of features, my focus for this presentation is asynchronous, reactive and functional aspects of Ratpack.

  • Liked Bernard Duggan
    keyboard_arrow_down

    Achieving High Uptime with Erlang's OTP

    Bernard Duggan
    Bernard Duggan
    schedule 1 year ago
    Sold Out!
    90 mins
    Tutorial
    Intermediate

    Few technical metrics are more closely watched in the world of online service delivery than a system's “uptime”. Response speed, number of concurrent users and data throughput are all forgotten about very quickly when users can't even get onto your system.

    The Erlang language was designed with fault tolerance as a core principle. Fault tolerance describes the ability of a system to keep running in the event of some kind of unexpected problem, without external assistance (in other words, without waking up your sysadmins) and with minimal impact to users. Consider a single monolithic C++ program, handling 10,000 concurrent users all with persistent TCP connections. If one user does something unusual and hits a poorly tested code path, causing a segfault, then 10,000 people see their connection drop. That's (obviously) not fault tolerant. If just that one user's connection dies and everyone else's carries on, that's fault tolerance (and also far preferable!).

    While Erlang's basic features give a degree of fault tolerance, they're not a silver bullet. The share-nothing memory model and ability to separate your system into thousands of isolated threads are extremely useful when building robust systems, but they're a foundation rather than the whole solution.

    The other killer for uptime is rolling out upgrades and fixes. Without some clever infrastructure, sooner or later your customers will see “We're down for scheduled maintenance – come back in 30 minutes”. One solution to this is “hot upgrades” whereby code can be upgraded on the fly with literally no downtime or interruption to ongoing services.

    This tutorial covers Erlang's Open Telephony Platform (which has almost nothing to do with telephony per se) and how it delivers on Erlang's promise of robust, fault tolerant, hot-upgradable software.

  • Mayank Jain
    Mayank Jain
    schedule 1 year ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

    Testing business logic quickly becomes tricky, as applications grow and scale. Example based unit and integration tests, and exploratory tests become poor choices to check and verify a large state space. Also such methods are not  well-suited to clearly describe the state space / transitions we want to test. 

    Since we use Clojure to write test suites and tools at Helpshift, we tried experimenting with DSLs to express some of our testing problems. We've found that mini DSLs can indeed become useful to describe and test fairly complicated business logic.

    In this talk I will cover some of the mini-DSL approaches we've tried, demonstrate one of them by example, and discuss the benefits and drawbacks based on current experience.

  • Liked Akshay Gupta
    keyboard_arrow_down

    Modeling a game with melody recognition and machine training using ClojureScript and real instruments

    Akshay Gupta
    Akshay Gupta
    schedule 1 year ago
    Sold Out!
    45 mins
    Demonstration
    Beginner

    Being great at a first-person shooter game requires a lot of hand-eye coordination and skill with the mouse. Being great at an MMORPG requires a working knowledge of a vast variety of keyboard shortcuts. Being great at a fighting game requires speed and skill with the gamepad.

    The underlying philosophy behind this experiment is to showcase that you can potentially take the input to any stringed instrument (with a pickup) lying around in your house, to use to design a game that requires as much skill (if not more) as playing any other game with any other kind of input device. By treating the instrument as a game controller, and moving the onus of deriving quality from the playing into the system, we can harness some of the basic qualities – speed and melody – of the instrument to make our game more interesting and a lot more unique and fun.

    The idea is to go as far away from being a Guitar Hero derivative as possible, and closer to a system that treats it as just another input device. The game should not be about playing guitars or any kind of music, but should be about playing any other regular game. Unlike other Musical Instrument Games™, we want ours to work for anyone, anywhere. So we're going to use a simple semi-electric guitar plugged into the microphone line-in and demonstrate this on the browser using the Web Audio Interface.

    We'll go through a few papers and look at implementing some of the algorithms to pitch / note detect in near real-time, process the input to make sense of it, run it through a few simple constraints and algorithms to recognise what a melody might be like and eventually explore how we can make the system intelligent enough to train itself based on the player and the styles so that we can generate smarter and harder levels for our game.

Sorry, no proposals found under this section.