jamon51

This made me happy. I also (obviously) have a soft place in my heart for pushing the boundaries of old / limited tech.

I updated the README with instructions on how to download the file, review it, and alias it locally. :-)

I made around 200 QBasic games when I was a teenager with no internet to help me, and it gave me so many amazing skills that I still use today!

Hey, fun to see my fun little project showing up on HN!

Yes, aliasing the CLI command to a remote script is not exactly best practice. My casual question to myself when I made it was … what’s the literal easiest way I could get this to work on someone’s computer with as few dependencies as possible? This was the solution I came up with. (And in my defense, it is similar to how you install homebrew … `/bin/bash -c "$(curl -fsSL https://xn--rvg)`, but I get that most wouldn’t trust a somewhat random GitHub account like this.)

If you have any questions about this, let me know! My website (https://jamon.dev) runs on it (in a DigitalOcean droplet) and I’ve enjoyed the experience.

Don't tempt me.

I love this so much. I got my start on QBasic and made hundreds of games between 12 and 19 years old. I eventually left it behind, but always had a fond spot in my heart for it.

Last year, when I was going to rebuild my personal website, someone on Twitter challenged me: “Build it in QBasic, you coward”. I was like “haha…wait, can I?”

And I did! It runs on QB64 on a DigitalOcean droplet.

Here’s the source:

https://github.com/jamonholmgren/jamon.dev

Check app.bas for the QBasic code.

I may eventually release a CLI and library that lets people spin up a QB64 website in little time.

I had the same experience as a kid. Probably built over a hundred QBasic-powered games with no internet to help me.

I missed it, so last year when I rebuilt my website I built it in QBasic:

jamon.dev

This is one of the big problems App.net always had, in that it wasn't at all intended to be a "Twitter alternative". Alpha was supposed to be an example of what could be built on the platform, not the entire product itself.

It's relatively large for a Phoenix web app, given that there aren't that many out there yet.

At Infinite Red we chose React.js over our previous choice of Ember not because it was objectively better at web, but because it lowered the context switching when our devs would switch between mobile and web projects. We have many devs who only handle web or only handle mobile, but for the ones who can do both, it's well worth it.

React.js being superior/inferior to Vue.js or others isn't very relevant unless the gap is huge, which it's not.

Portland is amazing in the summer, so if you get a chance to come visit us and attend this conference, please do!

Sorry to hear that, but thank you for being forthcoming.

I should also mention that we've found React Native to be far more productive to use than Appcelerator or Xamarin. Not sure what the author used to determine those charts near the bottom.

Complaining about longevity of React Native and then recommending two proprietary, non-open-source competitors is, frankly, absurd. If Facebook ever abandons React Native we have all of the code and can continue to support it ourselves. If Microsoft or Appcelerator ever shut down their platforms for any reason, we're SOL.

While there are some valid concerns with using React Native, the productivity gain and community make it a more than worthwhile trade off.

One of the slides shows "Rails is still the best choice for entire classes of apps."

"Best" is of course usually subjective, and this could spawn huge internet arguments back and forth about the relative merits of various solutions. But I think there's perhaps an objective argument to be made that this isn't true now, and won't be true with Rails 5 and beyond.

I own a web + mobile app dev shop (Infinite Red). Our background is Rails, and some on our team have been using Rails since pre-1.0 (Steve Kellock, for example wrote the first Rails guides, and his name still appears on the website). We have loved Rails (and Ruby) for a long time.

But the concurrency and scalability difficulty of Rails isn't just an opinion. As we've built larger and larger applications on Rails, the amount of effort put into making Rails scale gets disproportionately high. Not to mention server costs.

Yes, it's totally possible to scale Rails. No, not every Rails app needs to scale to Twitter-level. We get that; we've been doing both for years.

When we discovered Elixir/Phoenix [cue the groans, sorry] it felt like we kept the magic of Ruby on Rails while (in a single stroke) we also made a giant leap forward in concurrency, scale, and reliability. In my opinion, this is the direction the Rails community would be better off going. We felt so strongly about this that my partner Ken Miller wrote a piece titled "Phoenix is Rails 5". https://shift.infinite.red/phoenix-is-rails-5-f6d28e57395#.1...

We don't need Ruby on Rails to be great again. It's done its job and we're all better for it and grateful for it. We don't have to become Node.js developers and abandon all the things we love about Ruby and Rails. We have a better alternative: Elixir/Phoenix.

I would start with LearnElixir.tv (disclaimer: Daniel Berkompas works for Infinite Red, which i own). It's very good though!

> Does anyone know if there is any support for isomorphic Javascript on either platform? Or is that strictly a Node thing?

That's more of a Node thing, although React.js has very clever server-rendered JavaScript tooling that you can implement alongside your Phoenix apps.

Rarely are we in a position to "accept" or "deny" changes in language. They just happen, with or without our consent. All we can do is try to keep up and make some sense of the current state.

Will there be RubyMotion iOS & Android CI support?

Makes sense. For the record, I don't know much about the issue at hand, was specifically talking about one-word contributions (which I encourage on my project).

@buckbova, what's wrong with one-word changes? I run a semi-popular OS project and accept them all the time. It makes the newbs feel good and encourages them to explore further into the source code.

I wouldn't do a project rate as a freelancer.

I own a design/development studio and encourage my employees to do side work if they want to, in order to get some experience in areas they don't normally dabble in. Examples are estimating, invoicing, figuring out tough problems all on their own (and being on the hook for the solutions), etc. I think it's awesome.

But I always tell them to bill hourly. I do NOT want them to make the same mistakes that I did when I got started. Working late into the night for free is never a fun feeling.

It's too bad that keyword arguments are semantically opposite between CRuby and RubyMotion in Ruby 2.0+. It'll cause a divergence and makes it a little more difficult for Rails+RubyMotion engineers like me to switch.

I understand the reasoning behind both decisions (RubyMotion is following Objective-C's semantics, CRuby is following Python et al).

For those who aren't familiar with RubyMotion's syntax:

    def my_method(arg1, keyword: arg2)
      puts arg1
      puts arg2
    end

    my_method("test", keyword: "test2")
    # output
    test
    test2

How do I know this statement is reliable?

It's worse than that, though. They're selling the game for half price which can harm in a couple ways. It takes away a potential sale and it also sets the market expectation that the game is only worth $15.

Actually, the license is good forever. The $100 is for updates and support.

I can attest, as a RubyMotion early adopter, the product and especially the customer service make the $200 entry point and $100 service renewal well worth it.

If excellent customer reviews and a real money-back guarantee don't convince you, then I'm not sure a free trial will either.