clojure

Early/mid 2014 update – we’re hiring

Alex, , , , , Leave a comment

Whoa, a few months have gone by really fast here. Hi world. Guess I should post an update.

Been hard at work as usual at Front Row, it’s been very interesting to watch our numbers go up at a staggering pace while the # of people supporting the project stays the same. Really makes you appreciate the people making it happen, the tools you’re using and the best practices that keep the whole system from falling apart.

In any case, a few folks and we decided that it was time to give Front Row a bit of a budget to start scaling things out. We’re now looking for a couple of engineers to join us and work closely with yours truly. We’re seeking  web generalists with strong interest in functional programming: we’re a very small team and being able to pick any part of the stack up in a few days is very important. Here’s more info.

Whatever you like, we got it:

  • Want to build super-interactive SPAs and get good at data-visualization? Check.
  • Want to get your hands dirty with ops, configuration management, build automation and continuous delivery? Love Ansible? Check.
  • Want to crunch a ton of data and serve it to the outside world with Clojure and Haskell? Check.
  • Want to build tools and pipelines that enable Front Row content creators to publish their work to hundreds of thousands of students? Check again.
  • Love DBs? We do too! Ours is growing exponentially 😦 If you’d like to contain the beast, we can keep you busy.

That’s it for now!

Early/mid 2014 update – we’re hiring

Clojure’s instaparse TI-style math interpreter

Alex, , , , Leave a comment

There aren’t too many examples of Clojure’s instaparse use out there, so if you’re working on parsing a little language of your own, I hope this might come in handy.

I’ve been working on a little interpreter for some internal stuff part of the Front Row stack, mainly for validating student answers in the more complex middle school math domains. The interpreting the answer becomes pretty much mandatory for validating things like equivalence of two polynomials. This is what came out from the early efforts.

The EBNF grammar itself can be found here, the implementation of the parser is here (still blows my mind it’s under 50 lines), and the tests are all here. Wouldn’t have touched this with a ten foot pole without testing every single incremental addition.

A couple of resources I found useful, in addition to instaparse’s official docs:

The author of instaparse himself was also generous with a few tips on the library’s Google Groups.

Clojure’s instaparse TI-style math interpreter

Link

Correct Content-Type of static assets in Ring apps

Alex, , Leave a comment

If you’re thinking of serving assets from a Clojure Ring app, then you should be aware of an interesting quirk of one of the core pieces of Ring middleware: wrap-file-info. This middleware is used to automatically detect the file type based on extension and inject the corresponding Content-Type header into the HTTP response.

Now, when developing with it enabled, you might run into an interesting and somewhat hard situation to debug. In development mode the files will be served with the correct MIME type. In production, when the app is packaged together into a single uberjar, IF your resources were being served from within the resources/ folder, then wrap-file-info will fail to correctly identify the file type. 

Why? In development ring will be working with real files on disk, in a .jar situation you simply don’t get file extensions. See the following thread where Weavejester clarifies the situation.

Solution? Use wrap-content-type middleware instead. It only cares about the extension specified in the URL and should work correctly in most of the basic cases. I imagine you could have Ring fetch resources outside of the .jar itself, in which case the problem above would not reproduce. I believe you could get the best of both worlds by moving your assets outside of the uberjar and by using wrap-content-type regardless.

As a sidenote, cURL seems to infer MIME type based off of the URL, a behavior that’s inconsistent with the current versions of Firefox and Chrome. If you try to debug the issue above with cURL, you will be deeply puzzled. cURL will consistently correctly guess the MIME type, while the browser pointing at the file will print out a console message saying it’s getting a resource with text/plain, instead a different Content-Type value. The browser still correctly tries to use the resource, as they’re wrapped in a <script> or <link> tag with a specified content type. What makes this a tad extra frustrating is that Firefox allows you to generate cURL requests from the debug panel, and the requests are actually inconsistent with the browser that output that command.

If someone knows how to turn off Content-Type inference in cURL, do let me know 🙂

Correct Content-Type of static assets in Ring apps