Technology solutions for Ruby?

[mreiland]

I’m contemplating writing an application in Ruby but in order to do so I
have some requirements that I hope everyone can help me out with.

This is for a primarily windows application, however I’d like to keep
the door open for Mac/Linux.

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

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).

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

I have no experience with developing/deploying Ruby in a
“shrinkwrapped-esque” environment and would appreciate input from those
with more experience.

[mreiland]

On 7/15/07, Michael R. [email protected] wrote:

feel (I

wxruby is the best that I’m aware of, and I wouldn’t even think of
creating a production windows gui with it.

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).

Not sure what you mean by uniform. Activerecord is pretty uniform
from the perspective of how you use it regardless of the database.
There is also ruby-dbi, similar to the perl dbi.

3. Binary - Are there any utilities for compiling Ruby into a binary
   executable?

No.

You might take a look at Jruby.

Chris

[mreiland]

Michael R. wrote:

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

GUI isn’t my thing, sorry.

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).

ActiveRecord does pretty well at supporting multiple types of DBs
Some currently supported adapters currently included with ActiveRecord:
DB2, Firebird, FrontBase, Mysql, OpenBase, Oracle, SQlite, MS SQL Server
(Windows only), and Sybase. However, you can always create your own by
inheriting ActiveRecord::ConnectionAdapters::AbstractAdapter

I’ve never seen it used, but OpenLink has an ODBC Adapter:
http://odbc-rails.rubyforge.org

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

I believe there is one for .NET, and I know of a couple in design or
proof-of-concept stages, but that’s it. (Google: ruby compiler)

–
Travis W.

“Programming in Java is like dealing with your mom –
it’s kind, forgiving, and gently chastising.
Programming in C++ is like dealing with a disgruntled
girlfriend – it’s cold, unforgiving, and doesn’t tell
you what you’ve done wrong.”

[mreiland]

Michael R. wrote:

feel (I
Forget native look and feel – go for quality look and feel. I’d
recommend Qt4-qtruby for that. It just looks better than any other
toolkit, and it’s extraordinarily well documented.

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).
   unixODBC is a pain in the ass to work with … there are very few
   free-as-in-freedom drivers. I’d go with ActiveRecord, since it binds to
   Oracle, MS SQL, MySQL, PostgreSQL and SQLite. It’s probably not all that
   difficult to extend it to other databases.

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
   The closest thing is the Zen Obfuscator, I think.

I have no experience with developing/deploying Ruby in a
“shrinkwrapped-esque” environment and would appreciate input from those
with more experience.

Do you have experience developing anything in a shrinkwrapped-esque
environment? Especially Perl, because I think you’ll find the
ActiveState Perl tools are quite good for this, and Perl will do
everything Ruby can do – except be Ruby, of course. I won’t stand in
your way if you want to do this in Ruby.

[mreiland]

The ruby way is to consider building any app with the requirements you
listed as a Rails app. Is there a reason for you not to?

Aur

[mreiland]

On Jul 16, 2007, at 12:43 AM, M. Edward (Ed) Borasky wrote:

aren’t
2. Databases - contemplating using ActiveRecord, but I would like

those

why go to all the trouble of trying to obfuscate anything?
Just sign a licensing agreement.
If your customer violates it, your customer is in deep doodoo in court.
Lawyers will scare almost anybody out of doing stuff.

If you’re worried about it too much, you could always be annoying and
put a very obfuscated phone home function in buried as an extension
of one of the higher classes. And give them a version that is
stripped of documentation.

In the end though, if you’re using a scripting language, it is utter
foolishness to try to hide the code. Even compiled languages can be
decompiled well enough and often enough.

[mreiland]

SonOfLilit wrote:

The ruby way is to consider building any app with the requirements you
listed as a Rails app. Is there a reason for you not to?

Aur

The project is to replace an existing desktop software solution targeted
towards small to midsized companies. I don’t see any advantages to
moving it onto the web.

[mreiland]

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).

[mreiland]

snacktime wrote:

this and/or can you offer alternatives that provide a native look and
from the perspective of how you use it regardless of the database.

Chris

Yeah … jRuby has a cross-platform GUI and all the database stuff. I
don’t particularly like the typical Java GUI look and feel, but that’s
just my personal taste.

[mreiland]

The project is to replace an existing desktop software solution targeted
towards small to midsized companies. I don’t see any advantages to
moving it onto the web.

The advantage is that Rails gives a better API for GUI database
programming than any GUI library I know.

It also gives you absolute hiding of the source code.

You could also, BTW, implement the backend in Rails with a REST API
and the frontend with some GUI library.

[mreiland]

On Jul 16, 2:51 am, SonOfLilit [email protected] wrote:

The ruby way is to consider building any app with the requirements you
listed as a Rails app.

That’s a ridiculous statement.

T.

[mreiland]

On Jul 16, 12:53 am, Michael R. [email protected] wrote:

I’m contemplating writing an application in Ruby but in order to do so I
have some requirements that I hope everyone can help me out with.

This is for a primarily windows application, however I’d like to keep
the door open for Mac/Linux.

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

The best way to handle this is to use SOC (Separation of Concerns)
keeping all you logic together separate from your interface code, then
add a dedicated GUI for each OS you want to support. You’ll find that
some of the same concepts will apply to each, so once you finish one
front-end it won’t be as hard to do another. Yes, this means
mantinaing more code, but you get native look and feel, and can take
advantage of any special features of each GUI.

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).

How is ActiveRecord not uniform? ActiveRecord is a good choice. But if
you’d rather just work in SQL there is also DBI.

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

Maybe try, Ruby2exe.

T.

[mreiland]

On 7/16/07, Trans [email protected] wrote:

On Jul 16, 2:51 am, SonOfLilit [email protected] wrote:

The ruby way is to consider building any app with the requirements you
listed as a Rails app.

That’s a ridiculous statement.

T.

It’s based on the fact that in any such thread, the idea comes up and
many have supported it from their experience. Notice I said to
“consider”. What I mean is:

In Ruby, when you need a database GUI app, there’s another option
besides GUI toolkits and that is Rails.

BTW, using Rails does not mean having it online, you can even
distribute it as a Rails server to be run on the client’s computer
(but then you don’t get the advantage of absolutely hidden code).

Aur

[mreiland]

On Jul 16, 5:33 am, SonOfLilit [email protected] wrote:

It’s based on the fact that in any such thread, the idea comes up and
many have supported it from their experience. Notice I said to
“consider”. What I mean is:

In Ruby, when you need a database GUI app, there’s another option
besides GUI toolkits and that is Rails.

BTW, using Rails does not mean having it online, you can even
distribute it as a Rails server to be run on the client’s computer
(but then you don’t get the advantage of absolutely hidden code).

My point is that there are plenty of other choices: Nitro, Camping,
Webrick.

Ruby != Rails.

T.

[mreiland]

On Jul 16, 6:43 am, “M. Edward (Ed) Borasky” [email protected]
wrote:

Michael R. wrote:

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).

unixODBC is a pain in the ass to work with … there are very few
free-as-in-freedom drivers. I’d go with ActiveRecord, since it binds to
Oracle, MS SQL, MySQL, PostgreSQL and SQLite. It’s probably not all that
difficult to extend it to other databases.
QtRuby works well with ActiveRecord. I’ve included a couple of classes
in the latest 1.4.9 release under qtruby/rails_support that provide
subclasses Qt::AbstractTableModel and Qt::AbstractItemModel that are
generic, and will work with any ActiveRecord (or ActiveResource)
instance. You can also write you’re own custom versions of these
classes and the other Qt model classes to work with ActiveRecord.

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

The closest thing is the Zen Obfuscator, I think.
Note that Qt4 QtRuby is GPL only at present, and if you wish to
distribute closed source binaries (not that I’m convinced that is
possible with C Ruby), you would need to make an arrangement with
myself (and I would have to discuss with the other copyright holders).
That may well be a show stopper, but in order to justify a commercial
version of QtRuby I would need to believe there was a critical mass of
paying customers, and I don’t see that at present.

You can use WxRuby for commercial development, but I haven’t heard of
anyone doing it which would also suggest there isn’t sufficient demand
for commercially licensed Ruby GUI bindings.

– Richard

[mreiland]

Of course - actually, personally I prefer Camping over Rails.

But Rails has all the features, all the glitter and all the userbase.

That’s why I recommended it.

Aur

[mreiland]

On Jul 16, 2007, at 2:21 AM, Michael R. wrote:

targeted
towards small to midsized companies. I don’t see any advantages to
moving it onto the web.

Well, without knowing thing one about the problem domain, a midsized
company I often work with is hard at work moving one of their
applications to the Web for several reasons that may or may not apply
to you:

• Centralized database. Having to constantly sync up the data on
  various employee boxes has caused them a lot of grief.
• Easier software updates. Their current desktop solution requires
  them to upgrade all boxes involved at the same time. Their employees
  are spread all over the country, so that’s quite a challenge.
• Simplified training for new employees. They’ve found that it takes
  less time to train employees to use a company Web site than it does a
  custom desktop application.

I’m not trying to tell you how to do your job. Many applications
aren’t viable for a move to the Web, in my opinion. If yours is
though, I think there are quite a few advantages to doing it.

James Edward G. II

[mreiland]

On Jul 16, 2007, at 8:30 AM, James Edward G. II wrote:

• Centralized database. Having to constantly sync up the data on
  aren’t viable for a move to the Web, in my opinion. If yours is
  though, I think there are quite a few advantages to doing it.

James Edward G. II

A web-based interface can be clumsy and ugly compared to native GUI
interfaces, but you could also look into Flex or Flash as viable
alternatives that make interfaces pretty easy and are definitely
cross platform, still leaving web connectivity open as an option.
There’s always Ncurses if you want to go with butt ugly in the eyes
of users!
One other option I just thought of is RealBasic. If you have VB
skills around, RealBasic would be pretty easy to start using. You’d
need to buy a license, but you can compile to native UI apps for
various platforms including Windows and OS X.

[mreiland]

On Mon, 16 Jul 2007, Trans wrote:

To address the original poster’s question first, I agree with Ed that QT
is probably the best choice for a GUI toolkit right now.

For DB Access, Once can look at an ORM like AotiveRecord, Og, or Kansas,
or a db abstraction layer like DBI, or something that’s kind of in
between
them, like Sequel. There are many choices, depending on what the needs
actually are.

For obfusication, the prevailing advice is; “Don’t bother.” However,
there is Zen Obfusicator if you really want to obfusicate and are
willing
to pay the licensing fee.

You can also turn any of your classes into binary extensions using

http://ruby2cext.rubyforge.org/

And you can turn a Ruby app a .exe using

http://www.erikveen.dds.nl/rubyscript2exe/index.html

Ruby != Rails.
Exactly. The frameworks other than Rails that have some production
userbase, and that each have some differences and advantages over Rails,
include:

IOWA, Nitro, Ramaze, Merb, and Camping. Rack should also be mentioned
because while it is not a framework like those other, it is a
meta-framework, providing much of the low level of functionality that
all
frameworks share. Rack makes it pretty easy to develop custom apps that
are not built on top of any particular framework.

So, when using Ruby, when you need a database GUI app, there’s another
option besides GUI toolkits and Rails, and that includes any of the
above
items. The “Ruby way” isn’t just Rails.

Kirk H.

[mreiland]

On Jul 16, 10:25 pm, vasudevram [email protected] wrote:

project, I prefer not to use .Net because of the portability issues,
the growth of the language if wxRuby was more mature as a GUI toolkit.
many, though not all, language features and libraries of both

"
Search | Packt Subscription
of

recently.
two EXEs described above. Worked ok.
O, classes, objects, modules/libraries, etc. - they work roughly in

HTH
Vasudev Ram
Site:http://www.dancingbison.com
PDF toolkit (in Python):Conversion of other file formats to PDF download | SourceForge.net
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

dancingbison.com