Technology solutions for Ruby?

  • Thread starter Bruno Desthuilliers
  • Start date
B

Bruno Desthuilliers

vasudevram a écrit :
(snip)
can tell me of a way to meet the above requirements in either Python
or
Perl, I'm all ears (I just prefer Ruby).
mature enough for production use. (snip)
wxPython has this (Native Look and Feel), I think

It does - just like wxRuby, since both are language-specific bindings to
the C++ wxWidgets toolkit.

And FWIW, wxPython has been used on production for many years, so I
think it qualifies as "production ready" !-)

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

In Python, you may want to have a look at SQLAlchemy, which offers lots
of things from the "db abstraction layer" to the full-blown (and
possibily somewhat ActiveRecord-like, cf the Elixir project) ORM.

(snip)
executable? The issue is twofold, speed, and not handing the
customer
the source :)

<OP>
IIRC, Ruby is actually still an interpreted language. Python is much
like Java wrt/ this issue : it's byte-compiled (the difference being
that this step is automagically managed by the VM).

IOW, you won't gain any speed from the existing packaging systems(but
then, if your project is mostly a GUI/DB tunnel, the two most critical
parts are already somewhat optimized). And the level of protection
gained from these packaging systems is very debatable at best (which,
FWIW, is also the case with Java).
</OP>

(snip)
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.
Yes.

(snip)
For more advanced language features related to object-orientation,
metaclasses / metaprogramming, both have some support,

s/some/great/g

Both Ruby and Python are known for this.
but you might
or might not be able to do in one, what you can do in the other.

I'd say that - wrt/ "advanced" programming tricks - *most* of what you
can do with one can be done with the other - but usually in a *very*
different way. While Ruby and Python have similar features and may look
very similar at first sight, their respective object models are totally
different.

<OP>
Basically, it's a matter of
- which language *you* prefer
- which one has the best libs for your app

It seems that, in your case, you prefer Ruby but Python may *or not*
have the best/more mature toolkit. So the best thing to do would be to
first try to write a quick 'proof of concept' program in the language
you prefer. Then, if you're still in doubt, write the same program in
Python.

My 2 cents (and friendly salutations to the Ruby community).
 
M

Michael Reiland

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

snacktime

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
 
T

Travis D Warlick Jr

Michael said:
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 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."
 
M

M. Edward (Ed) Borasky

Michael said:
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 :)
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.
 
J

John Joyce

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.

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


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

SonOfLilit

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
 
M

Michael Reiland

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

Michael Reiland

SonOfLilit said:
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.
 
M

M. Edward (Ed) Borasky

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


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.


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

SonOfLilit

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

Trans

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

SonOfLilit

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
 
R

richard.j.dale

Michael Reiland wrote:

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

Trans

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

SonOfLilit

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
 
J

James Edward Gray II

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
 
J

John Joyce

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

khaines

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
My point is that there are plenty of other choices: Nitro, Camping,
Webrick.

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 Haines
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,905
Latest member
Kristy_Poole

Latest Threads

Top