This year at OSCON I will be leading a hands-on lab and presenting about Reactive, Play Framework, and Scala. Here are two sessions:

• Reactive All The Way Down (lab) - 9:00am Monday, July 21

  In this tutorial you will build a Reactive application with Play Framework, Scala, WebSockets, and AngularJS. We will get started with a template app in Typesafe Activator. Then we will add a Reactive RESTful JSON service and a WebSocket in Scala. We will then build the UI with AngularJS.

Bruce Eckel will be hosting the Scala Summit in Crested Butte again this summer. The Open Spaces conference will be September 15 - 19 which is a perfect time of year up in the Colorado Rockies. The theme of the Scala Summit this year is Scala vs. The New Features in Java 8. So there will definitely be some fascinating discussions. I’m also looking forward to working on some IoT projects during the hackathons. Bruce and I have a few pcDuino devices that will be fun to get Scala working on. Hope to see you there!

As part of the Salesforce Wear Developer Pack for Android Wear I created a Gradle plugin that fetches and deploys Salesforce code (Apex). Gradle is the default build tool for Android but it can also be used with many other languages. For instance, here is an example build.gradle file for a project that fetches all of the Apex classes and Visualforce pages:

buildscript {
    repositories {
        mavenLocal()
        mavenCentral()
    }
    dependencies {
        classpath 'com.jamesward:force-gradle-plugin:0.1'
    }
}

apply plugin: 'force'

repositories {
    mavenLocal()
    mavenCentral()
}

force {
    username = forceUsername
    password = forcePassword
    unpackagedComponents = ["ApexPage": "*", "ApexClass": "*"]
}

The unpackagedComponents definition uses the Salesforce Metadata Types and pulls everything specified down into the src/main/salesforce/unpackaged directory when you run the forceMetadataFetch Gradle task. The forceMetadataDeploy Gradle task deploys everything in the src/main/salesforce/unpackaged directory to Salesforce.

Webhooks are the modern, web-oriented way for servers to receive notifications from other servers. For instance, when an event happens on a server, like Salesforce.com, your own custom application can receive the event via a web request.

Salesforce already has a built-in way to handle events called Triggers which run on Salesforce via Apex code. However, you may want to receive these events in your own custom application. In Salesforce it is pretty easy to write the Apex to do this but why not automate that process? I built the Salesforce Webhook Creator to do just that. Here is a short demo:

By default browsers limit access to cross-origin resources. For instance, if a JavaScript app is loaded from foo.com then it isn’t allowed to access content from bar.com because this would be a significant security hole. Cross-Origin Resource Sharing (CORS) is the way to workaround this limitation in modern browsers.

Salesforce.com has a great REST api but unfortunately it doesn’t yet have native CORS support (but you can vote for this feature). Having CORS support comes in handy with JavaScript UIs on top of the Salesforce REST APIs. Luckily you can easily workaround this by proxying the API requests through the server that is serving the JavaScript UI so that the REST requests are not cross-origin. But it is tedious to set this up for every app, so I created a generic Salesforce CORS proxy.

Right out of the gate in my new job at Salesforce.com and I have been working on a pretty exciting new project to integrate clouds and humans using Salesforce.com and Android Wear. This week Salesforce launched six new open source developers packs for wearables. I created the Salesforce Wear Pack for Android Wear to help developers start building cloud-driven wearable apps for emerging devices like smart watches. Check out a short demo of the sample app I built:

Popularized by GitHub, Webhooks are the modern way for apps to receive notifications / events from other servers. But testing Webhooks has always been pretty painful, especially if you want to automate those tests. So I created a little app to make it easier. Before we get into that lets cover the basics…

A Webhook is a way for you to define a URL that is called by another service when a particular event occurs. For example, you can configure your repo on GitHub to have a Webhook that calls http://foo.com/pr when a new Pull Request is created. The old alternative to this is polling (bad).

Yesterday I started playing around with gulp which is a build tool for JavaScript applications. My goal was to have a build for a fully client-side application built with AngularJS and Bootstrap. In modern JavaScript apps we now need a build tool to compile various pieces, manage libraries, do production transformations (like minification), and to provide a nice development cycle when working on a project. I created a Gulp Starter project that has the following:

Next week I will be presenting Going Reactive with Java 8 at the Boulder and Denver Java User Groups. Here is the session description:

Java 8’s lambdas make building Reactive applications a whole lot easier and cleaner. Through copious code examples this session will show you how to build event-driven, scalable, resilient, and responsive applications with Java 8, Play Framework and Akka. On the web side you will learn about using lambdas for async & non-blocking requests & WebSockets. You will also learn how the actor model in Akka pairs well with lambdas to create an event-driven foundation that provides concurrency, clustering and fault-tolerance.

Modern web applications are a mix of a back-end services, dynamic web pages, custom static assets, and library-based static assets. To maintain a productive development process it is easiest to have all this stuff in one project. But in production there are a number of optimizations that can dramatically speed up the loading of the application.

HTTP 304, Not Modified, responses enable the browser to not re-download an entire static asset a second time. Far-future expires enable the browser to cache static assets for a very long time so that they never request them a second time. The challenge with far-future expires is that you need to have a way to invalidate that cache. Asset fingerprinting allows you to do that invalidation. GZip encoding compresses the static assets. Putting static assets on a CDN caches the static assets near the consumer of the content.