Technology solutions for Ruby?

kyosohma at kyosohma at
Mon Jul 16 20:51:16 CEST 2007

On Jul 16, 1:46 pm, vasudevram <vasudev... at> wrote:
> On Jul 16, 10:25 pm, vasudevram <vasudev... at> wrote:
> > [ Though the OP posted his message to comp.lang.ruby, I'm cross-
> > posting it to comp.lang.python, since he mentions Python as a possible
> > alternative he's looking at, and also because I've recommended Python
> > for his stated needs. Also, interested to see what other Pythonistas
> > have to say in response to my reply.
> >  - Vasudev]
> > > On Jul 16, 2007, at 2:21 AM, Michael Reiland wrote:
> > > At the heart of the issue is the fact that I refuse to use Java for this
> > project, I prefer not to use .Net because of the portability issues,
> > and
> > I'd like to get away from C++ for obvious reasons.
> > > To me this means Ruby, Python, or, as mentioned above, Perl.  If anyone
> > can tell me of a way to meet the above requirements in either Python
> > or
> > Perl, I'm all ears (I just prefer Ruby).
> > Yes, I think it would be really great for the Ruby community and for
> > the growth of the language if wxRuby was more mature as a GUI toolkit.
> > (Not knocking the wxRuby developers at all, its great that they've
> > even done what they have - I know that creating other language (like
> > Ruby) bindings to a C++ lib is a non-trivial task).
> > My suggestion: Python + wxPython + Python DBI + (Py2Exe + InnoSetup)
> > *might* meet all your needs. (As with any decision about what software
> > technologies to use, you'll have to evaluate the suggested options to
> > see if they fit your needs.)
> > Note: I've used and like both Ruby and Python (saying this after using
> > many, though not all, language features and libraries of both
> > languages), and am not trying to discourage you from using Ruby for
> > your needs; its just that, based on your needs as described, it looks
> > to me as if Python meets them better than Ruby at present:
> > > 1. GUI - Native Look and Feel.  According to wxRuby the bindings aren't
> > mature enough for production use.  Does anyone have any experience
> > with
> > this and/or can you offer alternatives that provide a native look and
> > feel (I
> > I don't know enough about wxRuby to comment.
> > wxPython has this (Native Look and Feel), I think (used it some, a
> > while ago), not 100% sure, you can check on the site  - http:/
> >  - to make sure. The site does say that it is cross-platform:
> > "wxPython is a cross-platform toolkit. This means that the same
> > program will run on multiple platforms without modification. Currently
> > supported platforms are 32-bit Microsoft Windows, most Unix or unix-
> > like systems, and Macintosh OS X.
> > "
> > but that doesn't necessarily mean that it will have native look and
> > feel on all supported platforms. (The two are not the same thing.)
> > That's why you will need to check.
> > wxPython pros: Its fairly easy to learn, at least for simple GUI apps
> > (e.g. a few widgets / controls and a file dialog or two). I was able
> > to build these simple ones - see the code, article and screenshots
> > available here (or from links from here):
> >
> > - in quite a short time, starting from zero knowledge of wxPython (I
> > did know some Python from before), just by looking at the sample apps,
> > and some reading of the docs.
> > See the quotes about wxPython:
> > >2. Databases - contemplating using ActiveRecord, but I would like to use
> > ODBC to support multiple types of DB's in a uniform way (if you know
> > of
> > alternatives to ODBC or ActiveRecord, please let me know).
> > I think, but again, not sure, that Python DBI + appropriate database
> > drivers, may meet this need. Basically Python DBI is similar to ODBC
> > (roughly), and to Perl DBI + DBD, as I understand. There's also ODBC
> > support in the Win32 extensions package for Python - IIRC, Google for
> > 'win32all' to get it. Its also available as a link from the Python for
> > Win32 MSI installer on
> > I've used Python ODBC some, it works and is easy to use.
> > See this for a simple example:
> >
> > (See the second post at that page, titled "Publishing ODBC database
> > content as PDF
> > ". The code shown in the post is not indented as per proper the Python
> > syntax (LiveJournal messed up the indentation), sorry about that, but
> > its trivial to correct if you know Python indenting rules). Also read
> > the Python ODBC docs and examples, of course.
> > >3. Binary - Are there any utilities for compiling Ruby into a binary
> > executable?  The issue is twofold, speed, and not handing the
> > customer
> > the source :)
> > For Python, there is py2exe (for Windows only). I used py2exe recently
> > and it works well enough for the simple cases that I tried. (I tried
> > building EXEs for a simple Python hello-world program, and for a
> > simple wxPython GUI app based on my xtopdf toolkit. Both worked ok.)
> > For cross-platform (Windows and Linux, IIRC), there is PyInstaller
> > (Google for it), haven't tried it out yet, just downloaded it
> > recently.
> > I don't think you'll gain much speed by this compiling step, though
> > (over and above what Python gives you itself, when it compiles
> > your .py files to .pyc files). The purpose of py2exe is more to hide
> > the source code than to speed it up, as I understand (could be wrong).
> > Note: py2exe only creates an EXE and DLLs needed, from your source and
> > its required Python modules. To create an installer, try InnoSetup
> > (for Windows only). I recently tried it out, version 5, again, it
> > worked well. Could create Windows SETUP.EXE-type installers for the
> > two EXEs described above. Worked ok.
> > I first learned Python, have been using it for some time for various
> > projects, and then learned Ruby, and have done some projects with Ruby
> > too.
> > I've been reading both the Ruby Cookbook and the Python Cookbook
> > rather thoroughly in the last few weeks (and trying out and modifying
> > many of the recipes), and what I've observed is that the two languages
> > are roughly similar in features. For basic features common to most
> > languages (constants, variables, arrays, hashes/dictionaries, file I/
> > O, classes, objects, modules/libraries, etc. - they work roughly in
> > the same fashion - though syntax obviously differs, you can mostly do
> > what you can in one of them, in the other as well. (Note that I'm not
> > talking about libraries here - this will obviously differ as each
> > language will have its own set of libraries for doing various tasks,
> > like networking and other areas - though even here there is a good
> > amount of overlap/similarity.)
> > For more advanced language features related to object-orientation,
> > metaclasses / metaprogramming, both have some support, but you might
> > or might not be able to do in one, what you can do in the other.
> > HTH
> > Vasudev Ram
> > Site:
> > PDF toolkit (in Python):
> > Blog:
> P.S.: Some more thoughts:
> If you'd really prefer to work in Ruby, but find after investigation,
> that the wxPython recommendation I've made is worth pursuing, you
> could check out this other approach:
> - Write the GUI in Python + wxPython
> - Write the rest of the app - the back end - in Ruby.
> - Connect the two via any one of the following distributed computing
> technology options:
>    - sockets (lowest level, more coding needed, need to create your
> own proprietary, application-specific (though not necessarily very
> difficult) "protocol" on top of the sockets layer
>    - XML-RPC (less coding than sockets, fairly easy to code with,
> supports most/all basic scalar data types (string, int) of Python/
> Ruby, also supports 'structs' and arrays. XML-RPC structs are not
> really structs in the C sense, they more or less map to hashes/
> dictionaries of Ruby/Python respectively. A Binary XML-RPC data type
> is also available, it works by Base-64 encoding your binary data. Have
> tried out this type as well as the simple scalar types, they work.
> (E.g. I could generate a PDF file on the server in response to a
> client method call, and send the PDF back to the client as the method
> response, using the Binary data type.) In XML-RPC you can either use
> the register_instance or register_function functions to register your
> class's callable methods or your standalone callable functions so the
> client can call them.
> Each of these approaches (register_function vs. register_instance) has
> its pros and cons - e.g. IIRC, you can register any number of
> functions, but you can only register one instance of an object - so if
> using this approach, you'd need to either a) have all your callable
> code in one class, or make that one class a manager/controler class
> that delegates to other classes to do the needed work.
>    -  SOAP. Ruby's stdlib has SOAP support. Python has SOAPpy and a
> few others, not sure whether those projects are active and supported
> currently. You will need to check this out. Comments similar to those
> for XML-RPC above.
>    - ICE from ZeroC This is like a lighter CORBA.
> Some of the key developers are prior CORBA experts, like Michi Henning
> who wrote a well-known C++/CORBA book. But check out the licenses for
> ICE; IIRC, the open source version is under the GPL. You have to pay
> for a commercial license.
>    ICE supports Python for both client and server, has Ruby support
> (need to check if both client and server, or client only).
>    - HTTP calls. Use Webrick or Mongrel HTTP server libraries - you
> can "mount" instances of classes into the HTTP servers that these
> libraries allow you to create and run. (This is similar to Java
> servlets running inside a Java servlet container.) "Call" the methods
> of these instances from the Python + wxPython GUI front end via the
> appropriate HTTP client library (urllib or urllib2 or httplib2) for
> Python, open-uri for Ruby. I've checked this out (briefly), it works,
> and is a neat and somewhat powerful technique, IMO. (What this implies
> is that the client for your HTTP server, need not be a browser - it
> can be a...
> read more »

wxPython uses the native widgets of the platform it is running on in
most (if not all) cases, so if you want the "native look & feel", than
that is the way I would go. They have the best user's group I've seen
so far as well.


More information about the Python-list mailing list