davidroetzel

This seems to be quite nice. The generated slides look very good.

For everyone looking for a html based alternative: slideshow (or S9) [1] is a ruby tool that also lets you generate slides from markdown. It has output plugins for most of the popular html5/js-based presentation systems.

It is a nice tool but what I like even better is its mailing list [2]. It is a wonderful place to learn about and discuss alternative and/or related projects.

[1] http://slideshow-s9.github.io/ [2] https://groups.google.com/forum/#!forum/webslideshow

Slightly off topic, but I wanted to chime in to say that I enjoy Atomic Brawl very much. I like both the game and the technical execution. If you haven't already, give it a shot!

> This all suggests you're generating some revenue but you don't mention how.

AB is a card/board game hybrid. You can collect cards and experiment with different decks. You get additional cards for regular logins and of course for playing.

AB offers both a subscription and the possibility to buy different amounts of gems. Subscribers get additional cards for every login, win or loss. Gems can be used to buy additional cards.

Ruby 1.9.1, the first "stable" release of the 1.9 series, was released back in January 2009.

So when 1.9.3 is EOLd in 2015, the 1.9 series will have been around for 6 whole years. Seems like quite a lot of time to me.

And of course, as others have pointed out, upgrading to 2.0 is fairly painless. Going from 2.0 to 2.1 should be even smoother.

SEEKING WORK - Remote or onsite (Cologne/Bonn area in Germany)

I have spent the last 7 years building all kinds of applications with ruby on rails.

I love working with ruby, rails, coffeescript, but I am also eager to learn new stuff (currently dabbling with ember.js).

As a former sysadmin, I also do not mind taking care of the operations side of things. I also have limited experience with puppet.

Contact: consulting at roetzel dot de

> Creating proper platform-specific packages is a mad undertaking, requiring huge amounts of manpower to setup and to maintain.

Of course you are right, and I am well aware of this. After all, that is the reason it has not been done before.

Still, a crazy amount of effort went into creating and maintaining rvm, rbenv and the myriad of other tools we now have. I cannot help but wonder where we would stand now had all of this instead been directed towards great packaging.

> You'd end up with at least 100 different packages, and you'll have to test each one of them. That's going to cost much more than a one-off campaign of $50000.

I am not quite so pessimistic. What I am daydreaming about would involve the distributions and their package maintainers. They already ship ruby right now. The packages are just not in optimal shape and oftentimes not up to date.

But one can surely build on the foundation already laid out by the distributions and work with them to hand off some of the work.

Still, I know this would be a herculean task. And not only a technical challenge, but a social one as well.

I would love to hear more about "leverage existing package management systems".

I guess many people use rvm to install ruby and I always recommend newbies to try it out for that purpose.

But recent criticisms of ruby made me wonder if that really is the right approach. Maybe it would be better to put more effort into creating top-notch packages for the major linux distros (and, say, homebrew). And to work with the distributions on the stable packages, while offering official repositories to get the latest versions.

rvm could still play a role in this scenario as a tool to switch between versions, isolate gem installations and so on, offering a unified interface that hides the platform differences of the distros.

I would certainly donate to such a cause.

While I do not disagree with any of the proposed features, I am not sure, what they would accomplish. Could someone point out, what kind of applications would benefit from those changes?

Is this just about making ruby more like node (substituting callbacks for promises)?

Also, do all of these features really need to be implemented on the interpreter level?

I have so many thoughts about this post right now, that I find it hard to put them into a coherent comment. Still, I want them out there:

1) I, too, feel that Ruby is no longer as fashionable as it used to be. I do not think this to be much of a problem and more like the natural way fashions work. But I still think the effect can be observed. It was not long ago that I learned about a cool new project written in Ruby here on HN on a weekly basis. These days, it has become a rare occurence.

2) It is a fact that the "cool kids" have moved on. But there is not the one big new thing. Rather, people who were popular in the Ruby world 5 years ago use Scala, Clojure, Node.js, Go and a few other things these days.

3) Still, Rails seems to be very popular with startups. Maybe not with the ones that are highly technical. But many of those just trying to get a mvp out there seem to default to rails these days.

4) I love Ruby. I used to love learning new programming languages. But ever since writing Ruby code on a daily basis, other languages most often fail to attract me. And I no longer look at technical benefits. Instead I take a look at the syntax and most often I am annoyed. Ruby has this effect on _some_ people, but not on others. For those who do not care about Ruby's aesthetics, there is probably little to keep them from trying out other languages.

5) There is little in the list of features on x.rubini.us that I disagree with. But at the same time, there is nothing I ever missed. Also, I am not convinced that all of those issues can or should be solved on the interpreter level.

6) Instead of a list of features, I would love to see a list of the kinds of applications that would benefit from those. I am not convinced that Node.js-style network services should be the future of Ruby.

> Guess will need to try a second round at some point!

Please do. I loved the idea when I first read about it. And as you said, 5 is a small sample size to draw any conclusions from.

Maybe your experience from the first batch will help you choose better motivated developers to work with next time.

There was a story on HN a few weeks ago by a photographer wanting this kind of service. I found the discussion very interesting.

Is this in any way inspired by that? Or is this a coincidence?

Do you think the Edge's hardware will be a major improvement over the Nexus 4?

I am asking because I wonder why I should wait until next year for the Edge when Ubuntu Touch works just as well on a Nexus 4.

We desperately need something like todomvc for ui kits.

This is of course total off topic, but since a lot of GNOME-bashing is already happening in the comments here, I would just like to state that I am very, very happy with GNOME3.

It perfectly fits my use case (running a few apps fully maximised) and gets out of my way. Also, it is rock solid and has never crashed on me.

The recent NSA scandals seems to have put me in full tin foil hat mode. All I read here is: "We record everything you and/or your child say and send it to our servers."

There have been some heated discussions here following the latest bugs found in cryptocat.

Several people pointed to SILC as an existing option for secure group chat.

But SILC has its own share of problems: https://we.riseup.net/riseup+tech/problems-with-silc

Maybe the people who argued against cryptocat and similar efforts could shed some light on what they think of SILC.

I wonder if SILC's fundamentals are similarly flawed. Or is the recent rise of interest in secure communcations a good opportunity to revisit SILC?

SILC has it own set of problems though: https://we.riseup.net/riseup+tech/problems-with-silc

This is of course well meant and I think it is good to remind people, that there is no need to use Ember Data in Ember, but I have one objection:

The example only fetches records from the API and never creates, updates or deletes any. This is actually something that can easily be achieved with Ember Data today and in fact it is the one thing that is well documented.

It really is not easy. I really want to like Ember, I really do. But I also gave up after being unable to wrap my head around it.

I read the official documentation, which is well written, but does not cover the big picture needed to tie everything together.

I watched the peepcode screencast, which is great, even if for me the pace could have been a bit faster. After that I was convinced I wanted to give Ember a shot.

I failed very early on, wanting to accomplish two things that I guess should be very common. But neither one is documented anywhere. And while I found a few answers on SO, those usually used functions that were either not documented at all or where the documented said they were meant for something else entirely.

The first thing was integration with server side authentication. The foundation was a pretty standard rails app that handled authentication. I wanted access to the current_user from the Ember App.

The second thing was loading a few models together with the initial page in order to save additional calls to the server. I do not even know where to look for documentation on how to accomplish this.

It probably does not help that Ember Data is a seperate project. Ember without Ember Data is no way near as useful as the combination of both.

Again, I really want to like Ember. I love Yehuda's work on other projects and some Ember features like data binding look awesome.

But trying to use Ember to write a new app from scratch that deviates slightly from basic CRUD gives me a headache.

I could not agree more. The defaults are there for a reason. There are brilliant people out there building awesome software with those defaults.

When teaching rails, I always tell people to get familiar with the defaults first then try the alternatives and make an informed decision to switch (if at all necessary).

There is so much valuable information in those log files that I often wonder why there is no tool to analyze them.

With a nice UI this would not only solve this problem here but it could potentially offer a lot more insight than just looking at isolated entries in text form.

Now that it is official that WakeMate is dead, it would be great to see some kind of post mortem.

People keep iterating that hardware is not as easy as software, but WakeMate actually solved some of the biggest problems, including being allowed to sell the devices in the EU (for which you need to meet some requirements many small hardware companies do not want to deal with).

I would love to read about what actually went wrong. I guess there are some great lessons to be learned here.

Are you involved in the open sourcing arun hinted at?

If yes, what will this include and when can we expect to see some code?

> the firmware was hosed in such a way that pretty much all units would fail over the course of a few months

I initially had some good experiences with the android version which then got more and more unreliable until I stopped using it altogether. I was led to believe that this was due to bugs in the android app. Are you now saying that it is actually a firmware bug on the devices?

And if yes, is there any hope to have this fixed once everything is open sourced?

I am surprised that the collective hn memory seems to fail so terribly.

When Meteor was announced, people upvoted and commented like crazy. There was genuine excitement. A lot of people saw the potential for this being the next Ruby on Rails.

The commenters (including me at the time) only found two major flaws with Meteor: a) the license was too restrictive for a framework and b) security/authentication was still missing.

The Meteor team fixed a) right away and now they finally address b).

For me this means I am finally going to spend some time digging deeper into Meteor. And I thought people here would be similarly excited.

Do people here really forget that quickly, or is it just the weekend?

AGPL closes the "loophole" for server-side code.

Meteor pushes a lot of code to the client. This most probably constitutes distribution.

See Sencha's take on this: http://www.sencha.com/legal/open-source-faq/

They make money by dual-licensing JS code.

tl;dr I do not think that the GPL is suitable to build an open source community around a web framework.

With the current licensing it looks a lot like they are pondering a dual-licensing business: Offer a GPLed version for free and charge for commercial licenses.

Since the product seems to be very promising and since the GPL is not suited for many use-cases (web startups, freelance work for clients and even many inhouse developments), this might actually work.

Being a developer myself, I see nothing wrong with a bunch of other developers wanting to be paid for their work. If this is really how they want to play it, I wish them all the best. (If this really is the case, I find the current copy on their website a bit misleading, though).

On the other hand, if their goal is to establish a vibrant open source community around meteor, then I think they are on the wrong track.

To accomplish that you need to have a low barrier of entry for a) users of your product and b) contributors to your project.

The GPL, in the case of a web-framework that blurs the client-server divide, sets the bar quite high for both groups:

a) Other commenters seem to agree with me that every app developed with a GPL'ed meteor has to be put under GPL as well. The implications alone might drive some people away from using meteor, but even having to think about those things upfront can be discouraging. Some people do not like the GPL, some may not be able to work with it and some may simply want to be able to choose the license for their work themselves.

b) If they are offering a commercial license, it will not be easy for them to accept outside code contributions. They need to establish some legal documents (Contributor Agreements, maybe Copyright Assignments) and a process for accepting contributions. This makes it a lot harder to contribute than simply sending a pull request. They cite the MySQL business model as something they closely studied. MySQL has a particulary bad reputation for not accepting outside contributions. And this is mainly due to their dual-licensing model.

I strongly believe that Ruby on Rails became popular so quickly and still has an active community because of its liberal license (MIT).

Personally I am very excited about meteor and I wish that they reconsider using another license. It does not have to be MIT, even though that is what I would choose, but even LGPL would be better IMHO.

IANAL and my understanding of the GPL in a web context is at best fuzzy, but I still believe the following to be true:

The majority of application code is run on a user's browser. This means it is distributed (or conveyed) to the user. Thus, you have to offer every user of the app a possibility to obtain the unobfuscated source code.

But there is more: The GPL requires you to offer not only some JS files, but everything needed to run the application. This would include everything on the server-side as well.

Sencha's take on this might also be interesting in this context: http://www.sencha.com/legal/open-source-faq/

They have been using a GPL dual-licensing model for their products for quite some time now and I suspect they consulted more than one lawyer.

I am also looking for something like this. The best I could come up with so far is fastspring.com. They offer their services to european customers and even handle european VAT.

I have not had a chance to try them out, though. Maybe someone has some experience to share?

Thanks to whoever posted this. Greetings from the FrOSCon office!

Here is the online schedule, so you know when to watch the streams:

http://programm.froscon.de

Note that the time zone is UTC +2