Home > macOS > Using Ruby on Rails for Web Development on Mac OS X

Using Ruby on Rails for Web Development on Mac OS X

  Submitted by Hakime macOS 19 Comments

“It should come as no surprise that Mac OS X is a favored platform for Rails development. Rails and its supporting cast of web servers and databases thrive on the rich Mac OS X environment. The premier text editor favored by legions of Rails programmers everywhere is TextMate, a Cocoa application. And all members of the Rails core development team work with Macs. This article introduces you to Ruby on Rails by building a trivial web application step by step.”

About The Author

Thom Holwerda

Follow me on Mastodon @[email protected]

19 Comments

  1. 2006-02-28 12:11 pm
    negativity

    If web if not everything to you, maybe some low level view on Ruby would be interesting:

    http://www.squidoo.com/ruby_is_the_best/

    • 2006-02-28 2:33 pm
      Ronald Vos

      If web if not everything to you, maybe some low level view on Ruby would be interesting:

  • 2006-02-28 2:58 pm
    negativity

    Here is a Hello World with a Ruby C extension:

    1. create a file extconf.rb in a new directory and put this in it:

    require ‘mkmf’

    create_makefile ‘hello_world’

    2. create a second file hello_world.c and put this in it:

    #include “ruby.h”

    void

    Init_hello_world()

    {

    printf(“Hello World!
    “);

    }

    3. Compile and execute it with this line:

    ruby extconf.rb && make && ruby -e “require ‘hello_world'”

    How do you make the same in your preferred high level language?

    • 2006-02-28 7:18 pm
      Get a Life

      Shouldn’t you at least bother to export something instead of just using the initialization process to output some text?

      Other than the distutils script used to build the extension being more verbose than extconf.rb, the C extension isn’t really more complicated with the Python C API.

      PyMODINIT_FUNC inithello_world()

      {

      Py_InitModule(“hello_world”, NULL);

      printf(“Hello World!
      “);

      }

      Tiny little examples like this that don’t do anything aren’t much of a metric for comparison. They’ll favor languages with real FFIs. In Bigloo importing a simple C function is trivial.

      • 2006-02-28 7:58 pm
        negativity

        Even though it’s a short example, it’s short enough that I didn’t mind posting its whole here, unlike you who didn’t bother to post the whole Python version.

        Anyway, you are right that it’s a meaningless piece of code, but that’s what “Hello World”s are for.

        If you bother to check out the C Ruby extensions you will see that they all enjoy a lot of what Ruby offers, and like the author of the following article said, Ruby is top-notch in its support for C:

        http://www.onlamp.com/pub/a/onlamp/2004/11/18/extending_ruby.html

      • 2006-02-28 8:37 pm
        Get a Life

        I didn’t include the distutils script because I didn’t feel like typing it out. If you want to know what a distutils script looks like, you can Google it. It’s unnecessarily verbose, since I can build the entire “module” with one call to GCC. I wouldn’t have even provided the C code for the Python extension except to show that it differs trivially.

        People don’t write extensions that just do something in the initialization function and then exit. At the very least they provide functions or methods, but more often they provide types. My objection to your example is that you don’t bother to do that. I object entirely to comparing simple bindings that don’t do anything, because they aren’t representative of the work involved in writing an actual extension. In Python extension for example, you’ll do a lot of extraneous reference counting that isn’t necessary in Ruby. In Bigloo importing a function that returns nothing and accepts no arguments is all of one line. The function doesn’t need to even know it’s being used by Bigloo. It doesn’t require a wrapper. Not much of a comparison, is it?

      • 2006-02-28 8:46 pm
        negativity

        It’s piece of cake to create Ruby modules and classes with Ruby C Extensions. To create a module is one short line, etc.

        You are right that the comparison was not good, but that was not its purpose. If anyone starts with the example that I provided he can grow it to a more useful extension.

        If you want to dive into Ruby C Extensions, the reference is one file.

        Anyways, I’m done with this subject. 🙂

  • 2006-02-28 1:02 pm
    ValiSystem

    Eclipse with Radails ( http://www.radrails.org/ ) is a quite good combination. I prefer to use the update site instead of the binaries packages provided.

    • 2006-02-28 1:25 pm
      miketech

      I totally agree with you! I really like radrails and I will do my next online project with Ruby On Rails.

      The alternative was Java (J2EE). But the problem is, that Java is too complex for me ;) RoR is easier to handle and I don’t have to look at so many books about Java.

      The Java world is really huge. I can do my project with JSF, Tapestry, Struts, JSP only and so on. It is not easy to decide with the result that I have choosen another framework.

      And I also have a problem with the performance of Java. I only have a small server and ruby works good. Java with Tomcat seems to be heavy and slower. But maybe I only don’t know how to speed it up.

      Maybe I will try a project in Java too, because I have a J2EE book here and it is really fascinating, but too much for my low level stuff ;)

      Greetings

      Mike

  • 2006-02-28 2:05 pm
    modmans2ndcoming

    You should look at Turbogears as well. TG is a python based Mega framework like RoR, only better 😀

  • 2006-02-28 3:19 pm
    santagada

    Python has the same kind of functionality in the weave module. Here’s the documentation http://www.scipy.org/doc/api_docs/scipy.weave.inline_tools.html

    and this should work:

    from scipy import weave

    weave.inline(‘pintf(“hello world!”);’)

    in perl they have a inline package that should do the same

    • 2006-02-28 3:23 pm
      negativity

      Ruby has inline too. But the functionality that powers almost all the C libraries is not with inline. So it matters when it’s as easy as possible. Swig is good, but hand crafted libraries are better for maintenance when possible.

      • 2006-02-28 7:22 pm
        Get a Life

        Manually-written bindings are more of a negative in terms of maintenance than a positive. That’s why a lot of large binding projects create their own autogeneration tools, so they can avoid writing them by hand, while not having to deal with some of the sewage SWIG can output.

        • 2006-02-28 8:02 pm
          negativity

          If SWIG is up to the job, yes, it might be a time saver. But there are times that a Pythonic library is better than a general library, and the same thing happens with Ruby. Ruby-GTK2 in Ruby is hand crafted, as an example, and it’s very good:

          http://ruby-gnome2.sourceforge.jp/

          Please consider that Ruby has its own characteristics that differ from other languages, hence SWIG could be more optimized for Python than for Ruby…

          • 2006-02-28 8:47 pm
            Get a Life

            This really has nothing to do with Python vs. Ruby. It’s simply a matter of maintaining an interface to a library with a continually changing interface. Writing it by hand is easy if it’s small and doesn’t vary in its interface between versions. Writing it by hand when the interface is extended or the API changes between major versions is a pain in the ass. It is a maintenance negative, because you have to spend time doing the busy work of writing trivial glue code to a library for N different interfaces with M types and K functions and methods. All of the time spent writing that glue code is wasted time. It’s also time that often bitrots when the person doing it moves on.

          • 2006-02-28 8:51 pm
            negativity

            The SWIG interfaces need to be updated as well. My experience with SWIG dependent projects is that they aren’t as good as the non-SWIG dependent ones. YMMV.

          • 2006-03-01 12:04 am
            Get a Life

            I specifically referred to non-SWIG generators, which are typically tailored for the task at hand. Not that regenerating interfaces with SWIG is anything like supporting several different versions of a library by hand. I’ve never been fond of SWIG or SWIG-generated interfaces. I’ve written my share of interfaces for libraries for a number of languages by hand. I’m quite familiar with the tedium. I’m also quite familiar with the disappointment of finding the hand-crafted interface for a library hasn’t been updated in several versions. And then there are some that require versions of a library you can’t use by fiat. It creates lots of annoying busy-work that isn’t anything like actual productivity. That’s why people got all sorts of hard-ons over .NET and Parrot, among other things.

  • 2006-02-28 4:55 pm
    Jack_Green

    How does Ruby run on the new Intel Macs? What about the various service you usually need with Ruby on Rails such as MySQL?