Hacker Newsnew | comments | show | ask | jobs | submit | login

I'm curious what network activity would come out of the VM if the author turned on the network interface.

-----


Exactly. I was disappointed that there was absolutely no attempt to look under the hood of this thing. That would actually be an interesting blog post to read: like a look at the system, pre-installed programs, the difference between it and PearOS, whether you can install whatever software you want on it, whether there is a package manager and, and then of course some wireshark captures.

-----


Docker was written off with the caveat of, "but I still use it for my local development environment". I feel like that's a huge advantage for Docker. Maybe I missed it, but all the other mentioned technologies didn't try to solve the problem of providing a consistent development to production environment. That said, Docker still has a lot of problems around making the dev-to-production experience smooth, especially for teams that use OS X for development and run Linux in production.

-----


That's always been the least interesting thing about Docker for me, since Vagrant solves that particular problem much more completely, and has been around a lot longer than Docker has.

Using Docker for this forces you to do things the Docker way, whereas Vagrant is much more OS and CM agnostic. (CM is configuration manager: you can use puppet, chef, ansible, shell, salt or even Docker: whatever you're already using in production).

-----


My current web app is composed of 10 database hosts and 11 REST APIs. 21 VMs would blow my laptop's resources away while 21 containers run just fine. For me, that makes Docker a lot more attractive for local development. Also, Docker removes the need for a CM if you are into stateless deployments.

-----


If you're running a large number of VM's, vagrant-lxc is awesome, so are offsite targets. (digital ocean, AWS, et cetera)

Vagrant also has more options for stateless deployments than Docker: docker, packer, nixos, et cetera.

-----


That's probably the most important thing to me. Also, docker will probably succeed in the enterprise world you, being a Linux based solution.

-----


You don't get it.

-----


I hope somebody forks this and creates a version that automatically corrects the method for you at runtime. Why even show an error or throw an exception?

Bonus if the corrections are cached for performance.

-----


What a horrible idea - what if the suggested method wasn't the intended one?

-----


This has already been done before:

http://decomplecting.org/blog/2013/03/01/code-typos-got-you-...

-----


Hopefully you're joking.

As if it wasn't already hard enough to figure out the code path in a ruby application, now we can make it largely indeterminate and dependent on an ever-changing fuzzy algorithm!

-----


Haha this is maybe the worst idea ever.

-----


We've had a lot of vendors, like Firebase, approach us at Poll Everywhere over the years. Despite how awesome they are as people, a company, and the huge problems they solve, I've always avoided it getting in bed with any vendor for something that I think is fundamental to a realtime web application. As a result, we developed our own realtime web framework at http://firehose.io, open sourced it under the MIT license, and made ourselves immune to these circumstances.

-----


In .xlsx format.

-----


https://github.com/DataGarage/node-xlsx-json

Node module to convert xlsx to JSON.

-----


You could get away with a voluntary Wufoo survey limited to 5- 10 questions. Our company would have time for that (2-3 minutes?)

-----


That really puts into perspective how huge Yo app is a threat to national security. It's only a matter of time until the NSA is intercepting Yos, or at least capturing Yo metadata.

-----


I bet a Yo takeover is coming within few months. Buying the company may cost less than hacking it...

-----


already got a insider - http://www.theguardian.com/technology/2014/jun/23/yo-founder...

-----


We use hamlc and Backbone.js in our stack. This lib looks like it will simplify a lot of that.

I have a few questions:

1. Its interesting to see JS events specified in the template (e.g. `%a(onclick=@doSomething)`). Is there a way to specify that in the JS/model?

2. Does "Observable" mean that the value is updated when the model changes, when the DOM changes, or both? Could all of the attributes of the object passed into the template be observable by default or would that incur a significant performance penalty?

-----


For point one, it is specified in the model. @doSomething would invoke the model's doSomething function. The template just names it.

As to point two, observable provides a bi-directional binding so that changes to the value are reflected in the DOM and changes in the DOM are reflected in the model.

The observable interface is essentially a jQuery style getter/setter method that allows for observers to be notified of changes.

-----


When is the DOM updated? Are the changes performed as soon as they are observed or are they queued? Does Hamlet implement some kind of "virtual DOM" for diffing or does it sync DOM and model directly?

Looks very nice, just this weekend I looked at some frontend frameworks, including Vue, Mithrill, Ractive and React and found some issues with them all. Hamlet would fit my use case very well, I think. One thing I'd like is more technical details on the main page - not how it "looks like" compared to other frameworks, but how it does its thing (compared to other frameworks).

-----


Thanks for trying Ractive (I'm on the core team). If you don't mind, I'd be interested in knowing what issues you came up against with those frameworks that you listed?

-----


The current implementation performs changes immediately. There is no virtual DOM, as soon as a change occurs the model is update and vice versa.

The Observable component invokes the callback to all listeners immediately when its value is changed. I find this makes testing and debugging somewhat easier than async callbacks or nextTick.

-----


How does observable wrap values? I see a few things:

  list = Observable []
  list.push 'blah'
and

  isOrange = Observable false
  isOrange = true // This obviously doesn't work this way...
Do you poll the value? Or do you check the type of the value and wrap/proxy methods that would normally change the value?

-----


When Observable is declared with a type (especially an array) it sets up some wrapped methods to simplify working with it.

The wrappers also set up automatic dependency resolution so you can do cool things like:

    list = Observable []

    reversed = Observable ->
      list.map reverse

    list.push 'blah'

    reversed() # => ['halb']
There's no polling, the observable notifies all observers immediately when the value changes.

-----


What about simple types, like the `false` value example above? Is there a `set` and `get` method?

-----


You'd use a jQuery style setter.

  isOrange(false)

-----


What issues did you find with React?

-----


I see you can also use `%button(click=@hello) Hello!` in the example page: http://hamlet.coffee/garden/

-----


That's correct. Both styles of event names are supported!

-----


We use hamlc and knockout: this seems like a wonderful improvement. If only we weren't 80% of the way to cljs+om.

-----


If you haven't already, check out http://fontcustom.com/. Its like Font Awesome, except you drop a directory of SVGs at it and it generates a ton of fonts. The project could use help in a few areas including:

- Sprockets asset pipeline integration https://github.com/glaszig/compass-fontcustom

- A PNG sprite compiler for compatibility with IE8, Win7/8 phones, and older versions of Android.

I can't say enough good things about these projects.

-----

More

Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: