Live data from Hacker News

One in Three Farms Is Using FarmLogs

techcrunch.com

21–30 of 67 posts

Re: One in Three Farms Is Using FarmLogs

#21
post #8
post #5

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?

Farming is often in the raster world as opposed to the line/row/text/vector world. Some of things in Postgres might be huge. Farm data sets could easily be only adding a few thousand rows a day, but the objects associated with each row could be several gigabytes. Meaning that the size of the data is bigger than so-called "big data" but the row analysis tool set looks more like your "regular data." However, there's a lot that goes into the raster analysis that's a whole different beast.

Re: One in Three Farms Is Using FarmLogs

#22
post #18
post #17

Earlier 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?

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 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

#23
post #19
post #18

Earlier 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 :)

> ...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.

[1] https://www.youtube.com/watch?v=ByNs9TG30E8

Re: One in Three Farms Is Using FarmLogs

#24
post #5

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.)

They did a StackShare blog post [0] and podcast in February talking about their stack, and it makes for a pretty good read. About Hadoop specifically, it doesn't show up on their StackShare page [1] anywhere.

[0] http://stackshare.io/posts/how-farmlogs-is-building-software...

[1] http://stackshare.io/farmlogs

Re: One in Three Farms Is Using FarmLogs

#25
post #18

Earlier 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…

It seems pretty obvious: You're giving up using one (great) language, which you already know, end-to-end. I can't think of a good reason to do this, especially when an entire UI revolution is being led, right now, in ClojureScript.

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

#26
post #5

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.)

They're big fans of Clojure (and are sponsoring clojure/conj).

Many of us will be there this year and will probably be in our borderline-offensive green shirts so please do say hello!

Re: One in Three Farms Is Using FarmLogs

#27
post #8
post #5

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?

You'd be surprised at what you can do with PostgreSQL. Also, there are also some really exciting new ways to handle data pipelines using Docker and tiny applications (see Pachyderm) as opposed to classic approaches like HDFS and Hadoop.

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

#28
post #23
post #19

Earlier 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…

Personally, I'm not a big fan of CoffeeScript and it's something I brought up when I started, but at the end of the day you can write good and bad code in any language. I've watched that talk and found it really compelling, but I'd sooner get rid of Backbone than change languages. I've been following Dan Abramov's stuff pretty closely, the refinements in Redux seem to take the best parts of Om and Flux.
Post reply on HN