jzoidberg

You get your original battery back on the way home.

We need one for "got"

San Diego and Sunnyvale CA

Front end positions: html5 and Play Framework

Back end positions: Scala with Hadoop (we don't require Scala experience just enthusiasm)

GridX - we are a well funded startup developing a unique new system to operate the next generation smart electricity grid. Our software wrangle smart grid data at scale to solve real problems that make a difference to everyone's lives.

Join us at the ground floor in this exciting and challenging field.

Please contact johan at gridx dot com

San Diego and Sunnyvale CA

Front end positions: html5 (with Play framework)

Back end positions: Scala with Hadoop (we don't require Scala experience just enthusiasm)

GridX - we are a well funded startup developing a unique new system to operate the next generation smart electricity grid. Our software wrangle smart grid data at scale to solve real problems that make a difference to everyone's lives.

Join us at the ground floor in this exciting and challenging field.

Please contact johan at gridx dot com

It looks like the DB schema is generated from the class definitions by the library. Queries are type safe: http://slick.typesafe.com/doc/0.11.0/gettingstarted.html#sch...

Awesome - thank you. It is great to have so many choices

How does this differ from Spray?

https://github.com/spray/spray

Cassandra stretches across multiple DC's nicely by design.

Scala runs perfectly on Android

Sunnyvale and San Diego CA

Front-end UI Developer

GridX - we are a well funded startup developing a unique new application to operate the next generation smart electricity grid.

Help us solve some of the most complex and rewarding energy and environmental problems of our time using Big Data and Cloud Computing.

We use Scala based web frameworks like Liftweb and Play! - experience with or interest in those would be a plus.

Our UI's use highly interactive HTML5 with WebSockets and Server Side Events. Rendering in SVG and Canvas.

Please contact johan at gridx dot com

This is a very static analysis. It takes the current spread of power generation emissions and applies it to the future electricity load of EV's. This is fundamentally flawed reasoning.

EV's will constitute a significant new load on the grid and we will have to build modern power plants to supply the extra load. New power plants produce significantly fewer emissions.

Sunnyvale and San Diego CA

Front-end UI Developer

GridX - we are a well funded startup developing a unique new application to operate the next generation smart electricity grid. Join and help us solve some of the most complex and rewarding energy and environmental problems of our time using Big Data and Cloud Computing.

We use Scala based web frameworks like Liftweb and Play! - experience with or interest in those would be a plus.

Our UI's use highly interactive HTML5 with WebSockets and Server Side Events. Rendering in SVG and Canvas.

Please contact johan at gridx dot com

Google Docs (and Zoho) does collaboration really well. This is important. MS Office does not even come close.

The article makes a valid point - we do not need bloated desktop software to produce documents. Some of the people already realized this - the question is how long it will take for most of the people to realize this.

As a developer i love Git. I love its speed, its decentralized nature, merging, branching. I even love submodules. We use git to deploy with - github hooks lets us auto pull from all our ec2 servers - changes are globally available in seconds.

As a collaborator i think it has failed us. I simply cant convince non-programmers to learn it. People who only occasionally use versioning systems simply do not need as much control. They need a much simplified layer over Git - that prevents them from screwing up . I have tried SmartGit for this - not simple enough, it still exposes the complexity.

The battery pack and associated circuitry is a array of solid state components.

An internal combustion engine has thousands of different parts - many of them moving, unmonitored and uncontrolled.

The EV is much simpler to manufacture and maintain. The GM EV1 was famously robust and low maintenance. Personally i believe this is one of the reasons the previous generation of EV's were canceled - it radically changes the profit spread on a vehicle. The old school manufacturers make a lot af profit on vehicle maintenance and parts - this is about to change.

The part count on a typical automobile is 30000 according to toyota - I would love to know what the Model S count is - even with the 6000 battery cells.

You are kidding right? - EV drive trains are much simpler and have a order of magnitude fewer parts than ICE vehicles or hybrids.

The JVM is a absolute dream to work with. We run it on a multi node Cassandra EC2 cluster and on tiny embedded devices. And develop for both those platforms on OS X.

Java the language is optional - it is simply the lowest common denominator on the JVM.

Really? We are in a absolute computing revolution. Never before has small teams or individuals had access to so much cheap, available computation. We can spin up vast compute resources in seconds and tackle huge problems. Just a couple of years ago this was only possible as part of a huge corporate team.

The cloud and dirt cheap embedded and mobile systems will make computers truly ubiquitous for the first time. It is interesting that we now run the same platforms and code on tiny embedded devices and the cloud. The web is finally turning into the broad platform we hoped it would. All of this is truly empowering.

On the language front we have wonderful new ways to express ourselves. Functional programming and constructs like Actors, STM and nosql data stores allow us to scale properly for the first time (See Scala and Akka).

The only limit is our imagination.

David carries quite a lot of weight in my book (we use Lift in production). Despite the negative title he makes a very good point and points out that this is entirely solvable. This falls under the "growing pains" category for Scala. I hope we get this right soon.

Excellent response. I never understood the hate towards Dispatch - I had a lot of fun learning it with the help of http://www.flotsam.nl/dispatch-periodic-table.html

If you dont want the fun simply drop down to the Apache HTTP client and use its interfaces. Dispatch is just a thin wrapper around the Apache client anyway.

The article seems very fear driven, many of his arguments simply do not gel with my experience.

We have been using Scala for 4 months now and have the first cut of our product released:

The Scala community have been great - we have had insightful answers on the Lift, Akka, Dispatch and Scala users list and on stack exchange.

We have used parallel collections and Akka actors to get good scalability without the usual pain. We do have some mutable data structures where it makes sense - we appreciate the flexibility to do that. The distinction between mutable and immutable data structures is pretty easy to read in the code.

Our code base is very concise, and i think readable for the breath of functionality we have implemented. We have not used type level programming, simple Scala constructs like pattern matching, collections and closures make a huge difference. You can write obtuse code in Scala - we choose not to.

In short we see Scala as a competitive advantage going forward.

Ward Bell is right and a visionary to boot.

I hope all our competitors read this blog and follow his advice.

I really like this idea: http://www.chrononsystems.com/post-execution-logging/

Akka actors are the accepted production solution in Scala.

I wonder how the author translated actor heavy code to clojure - I guess the closest available concept would be agents.

We have to wait a little bit: http://blogs.oracle.com/henrik/entry/supported_platforms_for...

Awesome IO stuff - finally we have great cross platform file handling.

We have known this was coming for many months now - why is anyone surprised? The support will revert to JVM vendors where it belongs. Personally I think it is a good thing - we will get JVM versions much faster than Apple supplied them.

Great stuff - can we render them one per page? They are a little small to grok.

It looks like someone's private blog. Nowhere does it say anything about MSDN. In the subtitle it says the author works for MS. The article itself does not state the technology limitations at all but does call it "heterogeneous", which is misleading.

Agreed - this is ridiculously vendor specific. The article misrepresents it.