Forum: Ruby Technology solutions for Ruby?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Mr E. (Guest)
on 2007-07-16 08:53
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.
snacktime (Guest)
on 2007-07-16 09:25
(Received via mailing list)
On 7/15/07, Michael R. <removed_email_address@domain.invalid> 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
Travis D Warlick Jr (Guest)
on 2007-07-16 09:35
(Received via mailing list)
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."
M. Edward (Ed) Borasky (Guest)
on 2007-07-16 09:45
(Received via mailing list)
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.
John J. (Guest)
on 2007-07-16 10:40
(Received via mailing list)
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.
SonOfLilit (Guest)
on 2007-07-16 11:04
(Received via mailing list)
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
Mr E. (Guest)
on 2007-07-16 11:16
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).
Mr E. (Guest)
on 2007-07-16 11:21
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.
M. Edward (Ed) Borasky (Guest)
on 2007-07-16 11:51
(Received via mailing list)
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.
SonOfLilit (Guest)
on 2007-07-16 12:05
(Received via mailing list)
> 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.
Trans (Guest)
on 2007-07-16 13:10
(Received via mailing list)
On Jul 16, 2:51 am, SonOfLilit <removed_email_address@domain.invalid> 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.
Trans (Guest)
on 2007-07-16 13:20
(Received via mailing list)
On Jul 16, 12:53 am, Michael R. <removed_email_address@domain.invalid> 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.
SonOfLilit (Guest)
on 2007-07-16 13:34
(Received via mailing list)
On 7/16/07, Trans <removed_email_address@domain.invalid> wrote:
> On Jul 16, 2:51 am, SonOfLilit <removed_email_address@domain.invalid> 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
(Guest)
on 2007-07-16 13:57
(Received via mailing list)
On Jul 16, 6:43 am, "M. Edward (Ed) Borasky" 
<removed_email_address@domain.invalid>
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
Trans (Guest)
on 2007-07-16 14:50
(Received via mailing list)
On Jul 16, 5:33 am, SonOfLilit <removed_email_address@domain.invalid> 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.
SonOfLilit (Guest)
on 2007-07-16 15:33
(Received via mailing list)
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
James G. (Guest)
on 2007-07-16 17:37
(Received via mailing list)
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
John J. (Guest)
on 2007-07-16 19:57
(Received via mailing list)
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.
unknown (Guest)
on 2007-07-16 20:13
(Received via mailing list)
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.
vasudevram (Guest)
on 2007-07-16 21:30
(Received via mailing list)
[ 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 R. 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
vasudevram (Guest)
on 2007-07-16 22:52
(Received via mailing list)
On Jul 16, 10:25 pm, vasudevram <removed_email_address@domain.invalid> 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
>
> "
> http://www.packtpub.com/article/Using_xtopdf
> 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):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
Ari B. (Guest)
on 2007-07-16 22:52
(Received via mailing list)
On Jul 16, 2007, at 1:25 AM, snacktime wrote:
>> 3. Binary - Are there any utilities for compiling Ruby into a binary
>> executable?
>
> No.

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
unknown (Guest)
on 2007-07-16 22:55
(Received via mailing list)
On Jul 16, 1:46 pm, vasudevram <removed_email_address@domain.invalid> wrote:
>
> > or
> > technologies to use, you'll have to evaluate the suggested options to
> > mature enough for production use.  Does anyone have any experience
> > "wxPython is a cross-platform toolkit. This means that the same
> > (e.g. a few widgets / controls and a file dialog or two). I was able
>
> > 'win32all' to get it. Its also available as a link from the Python for
> > its trivial to correct if you know Python indenting rules). Also read
> > building EXEs for a simple Python hello-world program, and for a
> > Note: py2exe only creates an EXE and DLLs needed, from your source and
> > rather thoroughly in the last few weeks (and trying out and modifying
>
> P.S.: Some more thoughts:
>    - sockets (lowest level, more coding needed, need to create your
> (E.g. I could generate a PDF file on the server in response to a
> that delegates to other classes to do the needed work.
> for a commercial license.
> 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.

Mike
unknown (Guest)
on 2007-07-17 00:12
(Received via mailing list)
In article <removed_email_address@domain.invalid>,
 <removed_email_address@domain.invalid> wrote:
      .
      .
      .
>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.
>
>Mike
>

Now you have me curious--when you write of "the best user's group
...", do you mean <URL: http://www.python-forum.de/forum-19.html >?
David M. (Guest)
on 2007-07-17 01:09
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:

http://rubyonwindows.blogspot.com/2007/03/developi...

David

http://rubyonwindows.blogspot.com
Bruno Desthuilliers (Guest)
on 2007-07-17 01:27
(Received via mailing list)
vasudevram a écrit :
(snip)
>>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).

>>1. GUI - Native Look and Feel.  According to wxRuby the bindings aren't
> 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)
>>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).

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

<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. Edward (Ed) Borasky (Guest)
on 2007-07-17 05:26
(Received via mailing list)
removed_email_address@domain.invalid wrote:
> 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.

I'll have to admit that as much as I like the Qt look and feel, wxGTK on
Linux and whatever flavor of wxWidgets runs on Windows does an excellent
job on a tool that I use regularly -- PgAdmin3. It's a bitch to build
from source, though -- get the RPMs (or .debs or ebuilds).
Charles Oliver N. (Guest)
on 2007-07-17 10:02
(Received via mailing list)
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
Kashia B. (Guest)
on 2007-07-21 22:00
(Received via mailing list)
Hi,

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

why do you recommend things you aren't totally 'in sync' with.  :)
Things having glitter... this is blinding people, user base, Java has
a huge userbase, I still would only recommend it on special occasions.
What I do recommend though is 'check things out' and 'dont't take
stuff for granted'.  Try out several frameworks, not everything that
glitters smells good, and good smell is the base of all good feelings.
And if 'feeling good' isn't the only thing worth living for, what else
is it....

Kash
Robert D. (Guest)
on 2007-07-21 22:29
(Received via mailing list)
On 7/16/07, SonOfLilit <removed_email_address@domain.invalid> wrote:
> 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
Aur if you think that Camping is better why do you go mainstream and
recommend Rails ????
Difficult to understand.

Cheers
Robert
SonOfLilit (Guest)
on 2007-07-22 20:56
(Received via mailing list)
On 7/21/07, Robert D. <removed_email_address@domain.invalid> wrote:
> Difficult to understand.
More mature, more documentation, more community, more tools - Rails is
easier to cope with.

It's also better, based on my limited impression, for big projects,
whilst Camping shines in small projects - which is why I prefer it for
my own work.


Aur
vasudevram (Guest)
on 2007-07-24 22:31
(Received via mailing list)
Bruno Desthuilliers wrote:

>s/some/great/g

>Both Ruby and Python are known for this.

Thanks for the info. (I don't know much about metaprogramming etc. in
either languages - just started exploring those topics recently.)


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

Can you briefly explain what you mean by "their respective object
models are totally different"? Do you refer to how the object-
orientation (classes, objects, etc.) is implemented in the two
languages?

Thanks
Vasudev
This topic is locked and can not be replied to.