I wonder what their stack is. I can't readily determine that, which might just be a function of working too hard today. I don't have time to search for the info. (I was specifically wondering if they use Hadoop.)
I can't remember seeing them looking for anything other than Postgres, which seems less like "big data" than... regular data. Maybe they don't put their heavy duty stuff in job listings?
One in Three Farms Is Using FarmLogs
21–30 of 67 posts
Re: One in Three Farms Is Using FarmLogs
#22Earlier quoted context omitted.
Frontend is currently Backbone + React, moving towards more React, written in CoffeeScript.
A bit of a shame it's not ClojureScript, to be honest. What's the rationale CoffeeScript?
We handle iOS push notifications with Ruby, a lot of data and image processing with Python, and even run .NET/Mono in a few areas. Our stack is very diverse and we do a really great job considering what the best technology for a particular problem might be.
Clojurescript is certainly interesting, but I wouldn't consider it a shame that our front-end isn't built with it. I love programming but at the end of the day you gotta remember that code is really just a means to an end.
Re: One in Three Farms Is Using FarmLogs
#23Earlier quoted context omitted.
A bit of a shame it's not ClojureScript, to be honest. What's the rationale CoffeeScript?
I'm relatively new so I can't speak to the original rationale, but right now it fits our needs. I'd love to do some ClojureScript (or just ES2015 through Babel), but right now we're focusing on building stuff instead of playing with languages :)
Which is exactly what's so compelling with regard to ClojureScript and say Om or any one of the React wrappers out there: you guys already use Clojure and ClojureScript and its libraries are incredibly pragmatic and designed for "real work". CoffeeScript would seem more like language play than ClojureScript, but of course I'm speaking as an outsider. :)
Also if you haven't already, take a look at David Nolen's recent talk on Om Next[1]. Personally if I were using Clojure on the backend, I'd be pushing hard for it on the frontend too.
Re: One in Three Farms Is Using FarmLogs
#24I wonder what their stack is. I can't readily determine that, which might just be a function of working too hard today. I don't have time to search for the info. (I was specifically wondering if they use Hadoop.)
[0] http://stackshare.io/posts/how-farmlogs-is-building-software...
Re: One in Three Farms Is Using FarmLogs
#25Earlier quoted context omitted.
A bit of a shame it's not ClojureScript, to be honest. What's the rationale CoffeeScript?
Can you explain why you feel it's a shame? We write a lot of Clojure at FarmLogs but there is certainly a time and a place for it. We handle iOS push notifications with Ruby, a lot of data and image processing with Python, and even run .NET/Mono in a few areas. Our stack is very diverse and we do a really great job considering what the best technology for a particular problem might be. Clojurescript is certainly inte…
What possible reasons could there be for giving that up?
(See my other comment below as well.)
Re: One in Three Farms Is Using FarmLogs
#26I wonder what their stack is. I can't readily determine that, which might just be a function of working too hard today. I don't have time to search for the info. (I was specifically wondering if they use Hadoop.)
They're big fans of Clojure (and are sponsoring clojure/conj).
Re: One in Three Farms Is Using FarmLogs
#27I wonder what their stack is. I can't readily determine that, which might just be a function of working too hard today. I don't have time to search for the info. (I was specifically wondering if they use Hadoop.)
I can't remember seeing them looking for anything other than Postgres, which seems less like "big data" than... regular data. Maybe they don't put their heavy duty stuff in job listings?
Not everything needs to be in an enterprise grade multi-node C* cluster to be big data!
Re: One in Three Farms Is Using FarmLogs
#28Earlier quoted context omitted.
I'm relatively new so I can't speak to the original rationale, but right now it fits our needs. I'd love to do some ClojureScript (or just ES2015 through Babel), but right now we're focusing on building stuff instead of playing with languages :)
> ...but right now we're focusing on building stuff instead of playing with languages Which is exactly what's so compelling with regard to ClojureScript and say Om or any one of the React wrappers out there: you guys already use Clojure and ClojureScript and its libraries are incredibly pragmatic and designed for "real work". CoffeeScript would seem more like language play than ClojureScript, but of course I'm speaki…