Technology solutions for Ruby?

[vasudevram]

On Jul 16, 10:25 pm, vasudevram <vasudev... at gmail.com> 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:/www.wxpython.org
>  - 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):
>
> http://www.packtpub.com/article/Using_xtopdf
>
> - 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:http://www.wxpython.org/quotes.php
>
> >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 python.org.
> I've used Python ODBC some, it works and is easy to use.
> See this for a simple example:
>
> http://jugad.livejournal.com/2006/07/07/
>
> (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:http://www.dancingbison.com
> PDF toolkit (in Python):http://sourceforge.net/projects/xtopdf
> Blog:http://jugad.livejournal.com

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 - www.zeroc.com . 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 command-line or GUI client; and, though you're using HTTP,
you need not use HTML, and in particular, you need not render HTML in
your client; you can, for instance, use XML and generate/parse it at
either end.)

HTH
Vasudev
www.dancingbison.com