[GLLUG] Best Web/Desktop Programming solution (...)

[Asenchi]

Hello,

Ruby and Ruby on Rails

www.ruby-lang.org
www.rubyonrails.com

You can't go wrong with these.  You'll be surprised how fast things
come together under these two.

Some examples of Rails in action:
www.basecamphq.com
www.43things.com
www.tadalist.com

Rails is ridiculous in how easy it is to work with, and Ruby is just
super sexy and nice like chocolate.  Plus Ruby works with lots of gui
languages (including GTK as recommended earlier).

My $0.02.

PS: I guess I am the one that is going to start a flame war. :)

On 4/19/05, Scott Henry Harrison <harris41 at msu.edu> wrote:
> Dear Jason:
> 
> I edited the content of your request, and subsequently
> chip in my two cents.
> 
> > The IT Department (all 3 of us) slowly migrate
> > away from our Access 2000 platform to web-based and preferably
> > F/OSS.
> >  All of our applications will be centered around databases.
> 
> have legacy front-end apps to access ... have existing structured
> database...
> 
> > a few caveats [aka necessary features and capabilities]
> 
> desktop runtime, web-based platform, nice pretty GUI for designing
> forms, making minor changes to add fields, federate programming
> from web page design (since only 1 person in 3 person team can program),
> connect to various databases (MySQL, MSSQL) and interfaces (ODBC),
> LDAP/SSL, be fast
> 
> > Once we choose a solution, we'll be slowly migrating each of our
> > applications from Access to the new system, which means a lot of code
> > rewriting.   Rapid Application Deployment (regardless of it's buzzword
> > status) is somewhat required, hence the GUI IDE requirement.  Some of our
> > current forms are quite complex with multiple tabs, linked child forms,
> > and a lot of Event-driven code.  I realize that we'll have to start coding
> > very differently when going web-based, because a large chunk of the code
> > should run at the server level. That's a big change for us, since all of
> > our code currently runs at the application (Access) level.  Any resources
> > or ideas to ease the migration pain are welcome.
> 
> You may need (for the general enterprise-level criteria of
>              a reasonably lean, flexibile, and adaptative deployment):
> 
> 1) a content management system to
>   separate the programming from the web page design
> 
> 2) middleware to connect to a wide range of system architecture
>   issues
> 
> I recommend three things: #1, Plone (content management system) and
> #2 Python (good middleware language).
> 
> Plone works on top of zope which are both driven by python.
> 
> Plone, to me, is like this big robot that you can command.
> The "command interface" (web) is not as quick as emacs and
> the terminal, but it is reasonably efficient.  Configuration
> can take a while, more so ratio-wise than if you built custom components
> from the scratch.  The advantage there is that it
> focuses the effort on configuring pre-existing parts and
> capabilities to realize actual user goals, and bypassing
> some of the short-term and long-term costs to a custom-OOP
> architecture.  Plus, I think you have a huge upside to
> future "rapid application deployments" with a plone-type solution.
> 
> Recommended reading:
> 
> http://www.tundraware.com/Technology/Python-Is-Middleware/Python-Is-Middlewa
> re.html
> http://diveintopython.org/
> http://docs.neuroinf.de/PloneBook
> 
> That said, for both quality and speed of deployment,
> #3 would be another programmer
> (pair programming)
> http://www.extremeprogramming.org/rules/pair.html
> or maybe
> look for some of the dynamo plone consultants out there...once you
> are further along assessing strategy, you may find
> a way to pay less and get more done quickly... unless
> it is somehow profitable to be slow.
> 
> My overall general thinking to your self-described vague request:
> 
> The situation you describe sounds like a real
> gamble...considered separately from the actual platform and
> applications you commit to (like plone and python,
> or any of the other 80+ webplatform/CMS/middleware
> solutions out there).  With just 1 programmer with
> some level of inexperience for this particular mission-critical
> task, I think your organization is putting all its eggs in
> a very slow basket on a potentially rough road.  While
> going slow can alleviate some of the tumbles, I would think
> it's disappointing to wake up and look at, however slowly developed,
> a big steaming mass of perl code... did I say that?
> I mean, any situation where a lot of architectural value may have been
> lost.
> 
> Admitting some of my own inexperience, if there is a more turn-key
> (.NET/JavaUltraMegaBeanVersion8.2/AdobeDoIt...or something)
> proprietary solution out there, or php, or other approaches,
> others may know better than I (and I'd be darn interested to
> hear about those solutions).
> 
> Regards,
> Scott
> 
> 
> _______________________________________________
> linux-user mailing list
> linux-user at egr.msu.edu
> http://www.egr.msu.edu/mailman/listinfo/linux-user
> 


-- 
<<< Asenchi the White >>>