Technology solutions for Ruby?

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 :slight_smile:

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

···

--
Posted via http://www.ruby-forum.com/.

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

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

···

On 7/15/07, Michael Reiland <mreiland1978@yahoo.com> wrote:

Michael Reiland 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 :slight_smile:

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 Warlick

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

Michael Reiland 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

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 :slight_smile:

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. :slight_smile: I won't stand in
your way if you want to do this in Ruby.

···

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 :slight_smile:

Maybe try, Ruby2exe.

T.

···

On Jul 16, 12:53 am, Michael Reiland <mreiland1...@yahoo.com> wrote:

Mr Eiland 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.

1. GUI
2. Databases
3. Binary

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

For what it's worth to you, I've been using the following components for
production Windows desktop apps for the past year and a half:

GUI = wxRuby (0.60)
Database = Sqlite3 (with the sqlite3 ruby bindings)
Binary = RubyScript2exe
Installer = Inno Setup

I (and my users) have been pleased with the results, but your needs may
differ.

You'll find comments about all or most of these components in this
thread.

Some further details can be found here:

David

···

--
Posted via http://www.ruby-forum.com/\.

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.

···

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

Michael Reiland 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

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 :slight_smile:

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. :slight_smile: I won't stand in
your way if you want to do this in Ruby.

snacktime wrote:

···

On 7/15/07, Michael Reiland <mreiland1978@yahoo.com> 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

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

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.

Michael Reiland 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 :slight_smile:

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

···

On Jul 16, 6:43 am, "M. Edward (Ed) Borasky" <zn...@cesmail.net> wrote:

YES!!!!!!!!! THERE IS rubyscript2exe!

Awesome tool, never used it, but I'm hoping it's awesome.

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

G'luck, mate! (in inspiration of today's featured wikipedia article)

HTH,
-------------------------------------------------------|
~ Ari
crap my sig won't fit

···

On Jul 16, 2007, at 1:25 AM, snacktime wrote:

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

No.

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

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

···

--
Posted via http://www.ruby-forum.com/.

M. Edward (Ed) Borasky wrote:

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.

Generally the default Java L&F tries to match the host platform as well as possible, and in Java 6 it's pretty damn close. Of course, you can plug in any L&F you want without changing the code.

- Charlie

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.

···

--
Posted via http://www.ruby-forum.com/\.

That's a ridiculous statement.

T.

···

On Jul 16, 2:51 am, SonOfLilit <sonofli...@gmail.com> wrote:

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

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.

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

···

On 7/16/07, Trans <transfire@gmail.com> wrote:

On Jul 16, 2:51 am, SonOfLilit <sonofli...@gmail.com> 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.

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 Gray II

···

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

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.

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

Ruby != Rails.

T.

···

On Jul 16, 5:33 am, SonOfLilit <sonofli...@gmail.com> wrote:

On 7/16/07, Trans <transf...@gmail.com> wrote:

> On Jul 16, 2:51 am, SonOfLilit <sonofli...@gmail.com> 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).

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.

···

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

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

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.

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 Gray II