we're working on it :)
1,777 karma · joined April 20, 2009
hipster oracle loves irony
In terms of human-readable code, we reduced the lines of code by ~30%. It's cleaner and more concise. I feel our code is more managable because of CoffeeScript.
In terms of the generated JS, I really appreciate that CoffeeScript creates an abstraction that will implement JS best practices and consistency
At this point, any JS work I do is done with CoffeeScript
The Enterprise Edition of SyncPad allows you to run that same server on your own hardware or managed by SyncPad.
Engineers Sales/Marketing
A few other notable Riak features include a JS or Erlang MapReduce API and full-text search.
The way that SyncPad was prototyped was using PHP/MySQL. I ported that to using Mochiweb. I manage all of the queuing of messages through a relatively straight forward OTP gen_server and Redis.
UPDATE: I should also mention, if you look at the charts, there's a point in time which the CPU hits 99%-100% and it's always reproducible. Once the CPU hits 100% I have just sat back and watched the memory get chewed up.
I'm sure someone w/ more experience than me can probably debug what's going on. The code is there, I really hope someone else can take a look at it. As my friend mentioned, it's reproducible, it can be fixed.
I'll run the test again later tonight and post a follow up.
Basho (Riak)
* Software Developers
* Developer Advocates
We ended up re-writing it all in erlang and it solved our problem much better. Erlang is much better suited for multicore, binary, and seemingly memory handling. Frankly, I really enjoyed writing it in erlang as well, but prototyping in Node.js worked out really well.
Regarding redis, we're actually storing the base64 string (list in erlang) as binary. This sounds crazy since we could just store the binary file, but since we'd have to encode it as base64 for all the connected clients receiving the data. This actually lowers CPU usage in the long-run. The image is only cached in redis for a period of time then flushed (or in the future persisted elsewhere) anyhow.
If you're interested in using our server for your feature, just let me know @roder and I'll contact you. Maybe we can work something out.
The speed and ease at which I can search the erlang docs for specific functions is the best I have found.
I couldn't believe when I read this article that in related content, the top item was "IE9 tops Chrome, Firefox in HTML5 Compatibility"[2]. That's what made me research if there was any connection between Network World and Microsoft.
[1] http://techrights.org/2010/06/11/idc-idg-and-propaganda/
My point was that I totally agree with the notion of a REST-based service, but it's easier from an implementation perspective to have have web-heads for views (static files, session handling, etc) that interact with the application (REST) server.
What I've ended up doing is writing the REST backend and writing the presentation layer in something light, like flask or sinatra, just for session handling.
But they totally missed the mark by putting so much white space and padding around everything.
The minimal size I can shrink the window to is still >=33% of my 20" monitor, even with "Compact Sidebar" and smaller font.
They really should have studied the Mac OS user interface a bit more before releasing this. It seems like they fell into the whole lots of white-space and big font web-design trends...
I recently had lunch with a friend and I asked him about if he was planning new features their key/value store and I loved his answer: (paraphrased)
I'm a unix-guy. I want small bits of software that does one thing and does it really well.
His point was that software these days is rarely "finished". However in Unix so much of the software are small pieces. Each piece does one job and does it well. Then you can fit those pieces together in all sorts of configurations to do new and interesting things.
That's really scary that China's media narrative is pumping fear of the US into the populous.
If this worldview is followed to its logical conclusion, war between the two powers over influence or resources may be inevitable.
_shutters_
1> 0.1 + 0.3.
0.4