Develop Reference

Which language to use for writing an admin console à la webmin?

We have an in house developed web-based admin console that uses a combination of C CGI and Perl scripts to administer our mail server stack. Of late we have been thinking of cleaning up the code (well, replacing most of it), making the implementation more secure, and improving the overall behavior.
I don't have much programming knowledge, but I use Ruby on and off (mainly for writing erb templates), and hence was thinking of using ruby/rails for developing such an app (off-duty for now, I also need to learn stuff !).
Before blindly picking up a language though, what would you folks suggest ? Please let me know if this is too vague a question, I'll try to supply more information, if needed.

Have you considered writing your applications as Webmin modules?
You get a lot of stuff for free when you do so (users and groups, tons of security features, a pretty big variety of helper functions related to config files, and tons of existing code for most aspects of a UNIX/Linux system). You also get a lot of stuff for nearly free, like action logging, packages and updates via wbm or apt or yum, an online help system, etc.
There are some cons, as well. It's an old codebase, so it has some clunky bits in the API among other places. A lot of the old modules can be a bit hard to grok if you're not an old-school Perl programmer. But, it's a well-maintained codebase, and it's been banged on by millions of users for over a dozen years. It's pretty robust. The UI isn't beautiful, but it is relatively theme-able, and if you're distributing a minimized version it becomes easier to customize the UI.
I suspect you can be up and running a lot faster than starting from scratch or using most existing frameworks that aren't targeted specifically to building systems management interfaces the way Webmin is.
Also, it's BSD licensed, so you can do whatever you want with it, including building a custom commercial app with it (hundreds of companies have done so over the years).

If you already know a bit of ruby, then there's no reason not to use that.
If you're interested specifically in learning another language, then what you're trying to do could be done in pretty much any language/framework, it's just a matter of which one you want to learn.

Without knowing much about your existing application I'd say that this effectively boils down to "which language do you like to work with?".
Python and Ruby are both mature languages with ample library infrastructure. They also boast popular, similar web application frameworks namely Django and Ruby-on-Rails respectively.
Since you are porting an existing Perl app(lets) it may be worthwhile to note that Ruby is relatively more similar to Perl. Not surprising given that Ruby was influenced "primarily by Perl, Smalltalk, Eiffel and Lisp".

django has a nice admin interface

A business Case for Enterprise Python [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
This will not be a "programming" question but more technology / platform related question. I'm trying to figure out whether Python can be a suitable Java alternative for enterprise / web applications.
Which are the ideal cases where you would prefer to use Python instead of Java? How would a typical Python web application (databases/sessions/concurrency) perform as compared to a typical Java application? How do specific Python frameworks square up against Java based frameworks (Spring, SEAM, Grails etc.)?
For businesses, switching from the Java infrastructure to a Python infrastructure .. is it too hard/expensive/resource intensive/not viable? Also shed some light on the business case for providing a Python + Google AppEngine based solution to the end customer. Will it be cost effective in an typical scenario?
Sorry if I am asking too wide a question, I would have liked to keep it specific, but I need your help to evaluate Python as a whole from the perspectives of the programmers, service providing company and end business customer.
For an SME, a Python/GoogleAppEngine based technology stack is a clear scalable and affordable platform. But what about a large MNC that already has a lot invested in Java.
Thank you so much. I am researching this myself and will gladly share my conclusions here!
Thank you,
Srirangan

An enterprise that already has a terabucks of Java investments should add jython to their mix of technologies -- it can be adopted gradually and progressively, at first for ancillary functions such as testing, "one-off" data migrations &c, prototyping of new functionality, cases in which using some existing open source Python library is obviously very handy, and so on, and so forth -- then, as the many Java developers in the company learn to use Jython, some of the prototypes will just be put in production as Jython code because there would be no advantage recoding them, some old subsystem needing recoding will be recoded in Jython, and so forth.
It's never really a wise decision to throw away a huge existing and working codebase and the ginormous investment it represents -- Python's strengths include its wealth of strong, production-level implementations, how well they "play with others", and how well Python can gradually and incrementally infiltrate most any development shop.

The larger your investment in an existing technology is, the more expensive it is to move away from it. COBOL is perhaps the best example here.
That investment isn't just in porting existing solutions, but also in retraining or hiring new staff so that you have the skill sets to build and support the new technologies even while still maintaining your legacy solutions.
Add to that the fact that for most large Multinational Corporations, software isn't their core business. As long as it functions effectively and fulfills the business need, they don't tend to care so much about the 'details'.
You need to be able to offer some pretty compelling benefits to overcome this kind of inertia.
Sad but true.

If you need to do the sort of things you can do with Django, then Django and Python is totally what you want. Google App Engine runs Django as well. So, you can do a Django app and host it on Google App Engine, and later change your mind and switch to conventional server hosting, or self-hosting if you have your own server.
I haven't tried Google App Engine but my understanding is that the price is quite reasonable for what you get. Google's IT department does a great job of keeping their data centers going; if you outsource the hosting to Google App Engine you know your data is backed up, you know the servers won't go down, and even if a backhoe takes a whole Google data center off the Internet, some other Google data center will keep serving up your application to your customers. You also know that if your application suddenly becomes hugely popular, Google App Engine wil l scale up automatically to handle the load. (I think you set a cap for the maximum you are willing to pay, and it scales until it hits the cap. But as I said I haven't used it and I'm not certain.)
I haven't used Java yet, but from what I have seen of it, Python is a much more expressive language and skilled Python coders can get more work done in a day just because the language is that much better. However, if you already have invested in Java and have in-house expertise in Java, you would be crazy to walk away from that overnight. The correct thing is to pick one new project to just try out that crazy Python thing.
And I really do recommend Django. You can get the Django book and try out the tutorial. If your first pilot project in Python is a Django project, you should have an easy time of things.

The answer to your question is yes. Python can be well suited for Enterprise because python is a language which has raw power, flexible and can be glued with other programming languages. What enterprise really requires is a language which does everything and i feel python is already enterprise ready. If you want examples then i believe there can be no bigger example than google. Google is running python internally and externally for its business critical applications. The only problem with python is that it is not very well recognized by top MNC company and we as a python programmer find hard time convincing the management team. I guess you will face the same issue. But i guarantee you once you get your feet wet in python, you will understand its true power

There is -- almost -- no usable "Business Case" for any technology choice.
"what about a large MNC that already has a lot invested in Java" Ask around. See if there's a business case for Java.
I doubt you'll find anything. Most companies drift into technology choices slowly.
There was no business case for COBOL -- it was the only game in town in the olden days.
There is rarely a business case for Java. What usually happens is that some visionary individual started building the first web site (probably in Perl). The "web thing" gained traction, and some vision individual started building web sites in Java. Eventually, the success of those small teams indicated to others that Java had advantages over COBOL.
Managers say the words "make a business case", but watch what they actually do. They listen to (1) their peers, (2) successful people.
To make the "business case" for Python, you have to be that visionary individual.
1) Use Python.
2) Be successful.
3) Share your successes.
4) Be prepared to explain that your success is due to your tools, not your personal level of genius and charisma.

How do you make a case for Django [or Ruby on Rails] to non-technical clients [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
Businessmen typically want a web application developed. They are aware of .net or J2EE by names, without much knowledge about either.
Altho' Rails and Django offer for a much better and faster development stack, it is a big task to convince businessmen to use these platforms.
The task begins with introducing Django (or Rails), quoting some blog/research. Then making a case for the use of the framework for the specific project.
Lot of the task is repetitive. What are the sources/blogs/whitepapers and other materials you use to make a case for django (or Rails)
Don't you think there should be a common brochure developed that many development agencies could use to make the same case, over and again. Are there any such ones, now?
There seems to be enough discussion on Django vs Rails. Whereas the need is (Django and Rails) vs (.net and J2EE), at least so, while making a business case. Both represent a faster pragmatic web development in a dynamic language.

It's easier to ask forgiveness than permission.
First, build the initial release in Django. Quickly. Build the model well (really well!). But use as much default admin functionality as you can.
Spend time only only reporting and display pages where the HTML might actually matter to the presentation.
Show this and they'll only want more. Once they've gotten addicted to fast turnaround and correct out-of-the box operation, you can discuss technology with them. By then it won't matter any more.

You need to speak the language of business: money.
"If we do it Rails, it will cost you 50% less than the same functionality in Java."
Your percentage may vary, and you might need to also include hosting and upkeep costs, to show how it balances out.
When you're convincing other programmers, sure, talk about development speed and automation of repetitive tasks. But talk bottom-line cost to a business person.

Before you begin making the case for Django or Rails, you have to be convinced it's the right stack first in the context of the business person's needs. If the business person is an entrepreneur, he may have other factors that go beyond how quickly can the solution be developed. For example:
If its an enterprise play that's being developed (something like SalesForce.com, SugarCRM, etc.) it may make sense to have it written in Java because this makes acquisitions and mergers easier with potential Java-based suitors.
If its an internal IT play for a custom solution in a large company, they may already have a significant amount MS infrastructure in place. It may not make sense to have your client install SQLServer or complicate their stack further with a Rails/Django friendly stack.
If you've cross this chasm and are convinced you have the client's best interest in mind, then I would look for examples on the Internet where the same application has been authored in both Java and Rails/Django. Here's an example of the Pet Store implemented in Rails.
http://www.anassina.com/projects/railspetstore/
You can download the source code and demonstrate to your client how much less code is needed to achieve the same result.
Explain to the client why less code is valuable: the less code you write, the fewer bugs you will have.

The first 2 arguments from the top of my mind:
Easier and faster development = cheaper product, less time to market.
SO optimization out of the box.

While many of you made some good suggestions, WRT the talks/resources for using these frameworks, you may also note to have a look at talk on redesigning yellow pages in ROR:
Summary from the site:
This talk explains how
YELLOWPAGES.COM, one of the
highest-traffic websites in the U.S.,
was written using Ruby on Rails, how
it was scaled to handle the traffic
and how the software architecture
evolved. Also: the reasons for
choosing Ruby on Rails.

The best case to be made for either of these frameworks is their ability to automate repetitive and time-consuming tasks. This allows developers to be faster and more productive which in turn means projects are delivered faster.

The problem with a "brochure" approach is that it doesn't address the clients needs. Putting the language/platform of choice into a presentation that addresses the clients goals is much more likely to sell them - both on the tools you want to use, as well as you as a provider. As long as you can show that your approach will solve the problem (preferably with the least amount of expense), you'll have fewer objections and less of the "but I've heard that xxx is the best".

Dilemma: Should I learn Seaside or a Python framework?

I know it's kinda subjective but, if you were to put yourself in my shoes which would you invest the time in learning?
I want to write a web app which deals securely with relatively modest amounts of peoples private data, a few thousand records of a few Kb each but stuff that needs to be kept safe, addresses, phone numbers etc. I've done several web projects in PHP/MYSQL and have decided, handy though it is I really don't like PHP and don't want to do another large project in it...
As such I figure I'd best learn something new and so I am considering 2 options (although I'll happily entertain others if you have suggestions). I'm having terrible trouble deciding though. They both look quite involved so rather than just jump in and potentially waste days getting up to speed enough on both of them to make an informed choice I thought I'd come here and canvas some opinion.
So the two options I'm considering are...
One of the PYTHON Web frameworks - TurboGears seems well regarded?
Advantage: Of all the languages I ever tried Python is by far and away my favorite. There's loads of frameworks to choose from and I have done quite a lot of non web python coding over the last few years.
Disadvantage: There's loads to choose from so it's hard to pick! Need to run single server process? or mod_python? which I don't like the sound of. What I do like is the notion of process separation and compartmentalization, i.e. if one users account is compromised it gives an attacker no leverage against the rest of the system. I'm not clear to what extent a python solution would handle that.
Writing it as a SEASIDE app Which I guess runs on a squeak app server?
Adv: From what I've heard it would permit good compartmentalization of users as each would have their own little private VM independent of all the systems other users which sounds wonderful from a security, scaling and redundancy standpoint.
Dis: I've not done any Smalltalk since Uni 15 years back and I never dug too deep into it then. I don't see much entry level help for seaside or that many projects using it. I suspect setting a server up to run it is hard for the same reason i.e. not because it's inherently hard but just cause there will be less help online and a presumption you are already rather au fait with Sqeak/Smalltalk.
So, what do people think? Would I be able to efficiently get the kind of strong separation and compartmentalization I'm after with a Python framework? Is Seaside as good as I think in terms of insulating users from each other? Might I be better off, security wise, sticking to the languages I'm most familiar with so I don't make any n00b mistakes or will Seaside be worth worth scaling the learning curve and prove more secure, comprehensible and maintainable in the long run? At the end of the day it's not a life or death decision and I can always bail if I start with one and then hate it so pls nobody get all holy language war and start flaming anyone! ;-)
Cheers for any replies this gets,
Roger :)

Disclaimer: I really don't like PHP, Python is nice, but doesn't come close to Smalltalk in my book. But I am a biased Smalltalker. Some answers about Seaside/Squeak:
Q: Which I guess runs on a squeak app server?
Seaside runs in several different Smalltalks (VW, Gemstone, Squeak etc). The term "app server" is not really used in Smalltalk country. :)
Q: From what I've heard it would permit good compartmentalization of users as each would have their own little private VM independent of all the systems other users which sounds wonderful from a security, scaling and redundancy standpoint.
Yes, each user has its own WASession and all UI components the user sees are instances living on the server side in that session. So sharing of state between sessions is something you must do explicitly, typically through a db.
Q: I've not done any Smalltalk since Uni 15 years back and I never dug too deep into it then. I don't see much entry level help for seaside or that many projects using it.
Smalltalk is easy to get going with and there is a whole free online book on Seaside.
Q: I suspect setting a server up to run it is hard for the same reason i.e. not because it's inherently hard but just cause there will be less help online and a presumption you are already rather au fait with Sqeak/Smalltalk.
No, not hard. :) In fact, quite trivial. Tons of help - Seaside ml, IRC on freenode, etc.
Q: Is Seaside as good as I think in terms of insulating users from each other?
I would say so.
Q: Might I be better off, security wise, sticking to the languages I'm most familiar with so I don't make any n00b mistakes or will Seaside be worth worth scaling the learning curve and prove more secure, comprehensible and maintainable in the long run?
The killer argument in favor of Seaside IMHO is the true component model. It really, really makes it wonderful for complex UIs and maintenance. If you are afraid of learning "something different" (but then you wouldn't even consider it in the first place I guess) then I would warn you. But if you are not afraid then you will probably love it.
Also - Squeak (or VW) is a truly awesome development environment - debugging live Seaside sessions, changing code in the debugger and resuming etc etc. It rocks.

Forget about mod_python, there is WSGI.
I'd recommend Django. It runs on any WSGI server, there are a lot to choose from. There is mod_wsgi for Apache, wsgiref - reference implementation included in Python and many more. Also Google App Engine is WSGI, and includes Django.
Django is very popular and it's community is rapidly growing.

I'd say take a look at Django. It's a Python framework with a ready-made authentication system that's independent of the hosting OS, which means that compromises are limited to the app that was compromised (barring some exploit against the web server hosting the Python process).

I've been getting into seaside myself but in many ways it is very hard to get started, which has nothing to do with the smalltalk which can be picked up extremely quickly. The challenge is that you are really protected from writing html directly.
I find in most frameworks when you get stuck on how to do something there is always a work around of solving it by using the template. You may later discover that this solution causes problems with clarity down the road and there is in fact a better solutions built into the framework but you were able to move on from that problem until you learned the right way to do it.
Seaside doesn't have templates so you don't get that crutch. No problems have permanently stumped me but some have taken me longer to solve than I would have liked. The flip side of this is you end up learning the seaside methodology much quicker because you can't cheat.
If you decide to go the seaside route don't be afraid to post to the seaside mailing list at squeakfoundation.org. I found it intimidating at first because you don't see a lot of beginner questions there due to the low traffic but people are willing to help beginners there.
Also there are a handful of seaside developers who monitor stackoverflow regularly. Good luck.

Have you taken a look at www.nagare.org ?
A framework particularly for web apps rather than web sites.
It is based around the Seaside concepts but you program in Python (nagare deploys a distribution of python called Stackless Python to get the continuations working).
Like Seaside it will auto generate HTML, but additionally can use templates as required.
It has been recently open sourced by http://www.net-ng.com/ who themselves have many years experience in delivering web apps/sites in quality web frameworks like zope and plone.
I am researching it myself at the moment to see if it fits my needs, so can't tell you what I think of it in the wild. If you take a look, please give your feedback.

While considering a Smalltalk web framework, look at Aida/Web as well. Aida has built-in security with user/group/role management and strong access control, which can help you a lot in your case. That way you can achieve safe enough separation of users at the user level in one image. But if you really want, you can separate them with running many images as well. But this brings increased maintenance and I'd think twice if it is worth.

I'm toying with Seaside myself and found this tutorial to be invaluable in gaining insight into the capabilities of the framework.

I think you've pretty much summed up the pros and cons. Seaside isn't that hard to set up (I've installed it twice for various projects) but using it will definitely affect how you work--in addition to re-learning the language you'll probably have to adjust lots of assumptions about your work flow.
It also depends on two other factors
If other people will eventually be maintaining it, you'll have better luck finding python programmers
If you are doing a highly stateful site, Seaside is going to beat the pants off any other framework I've seen.

There is now an online book on Seaside to complete the tutorial pointed out earlier.

If it is decided that our system needs an overhaul, what is the best way to go about it?

We are mainting a web application that is built on Classic ASP using VBScript as the primary language. We are in agreement that our backend (framework if you will) is out dated and doesn't provide us with the proper tools to move forward in a quick manner. We have pretty much embraced the current webMVC pattern that is all over the place, and cannot do it, in a reasonable manner, with the current technology. The big missing features are proper dispatching and templating with inheritance, amongst others.
Currently there are two paths being discussed:
Port the existing application to Classic ASP using JScript, which will allow us to hopefully go from there to .NET MSJscript without too much trouble, and eventually end up on the .NET platform (preferably the MVC stuff will be done by then, ASP.NET isn't much better than were we are on now, in our opinions). This has been argued as the safer path with less risk than the next option, albeit it might take slightly longer.
Completely rewrite the application using some other technology, right now the leader of the pack is Python WSGI with a custom framework, ORM, and a good templating solution. There is wiggle room here for even django and other pre-built solutions. This method would hopefully be the quickest solution, as we would probably run a beta beside the actual product, but it does have the potential for a big waste of time if we can't/don't get it right.
This does not mean that our logic is gone, as what we have built over the years is fairly stable, as noted just difficult to deal with. It is built on SQL Server 2005 with heavy use of stored procedures and published on IIS 6, just for a little more background.
Now, the question. Has anyone taken either of the two paths above? If so, was it successful, how could it have been better, etc. We aren't looking to deviate much from doing one of those two things, but some suggestions or other solutions would potentially be helpful.

Don't throw away your code!
It's the single worst mistake you can make (on a large codebase). See Things You Should Never Do, Part 1.
You've invested a lot of effort into that old code and worked out many bugs. Throwing it away is a classic developer mistake (and one I've done many times). It makes you feel "better", like a spring cleaning. But you don't need to buy a new apartment and all new furniture to outfit your house. You can work on one room at a time... and maybe some things just need a new paintjob. Hence, this is where refactoring comes in.
For new functionality in your app, write it in C# and call it from your classic ASP. You'll be forced to be modular when you rewrite this new code. When you have time, refactor parts of your old code into C# as well, and work out the bugs as you go. Eventually, you'll have replaced your app with all new code.
You could also write your own compiler. We wrote one for our classic ASP app a long time ago to allow us to output PHP. It's called Wasabi and I think it's the reason Jeff Atwood thought Joel Spolsky went off his rocker. Actually, maybe we should just ship it, and then you could use that.
It allowed us to switch our entire codebase to .NET for the next release while only rewriting a very small portion of our source. It also caused a bunch of people to call us crazy, but writing a compiler is not that complicated, and it gave us a lot of flexibility.
Also, if this is an internal only app, just leave it. Don't rewrite it - you are the only customer and if the requirement is you need to run it as classic asp, you can meet that requirement.

Use this as an opportunity to remove unused features! Definitely go with the new language. Call it 2.0. It will be a lot less work to rebuild the 80% of it that you really need.
Start by wiping your brain clean of the whole application. Sit down with a list of its overall goals, then decide which features are needed based on which ones are used. Then redesign it with those features in mind, and build.
(I love to delete code.)

It works out better than you'd believe.
Recently I did a large reverse-engineering job on a hideous old collection of C code. Function by function I reallocated the features that were still relevant into classes, wrote unit tests for the classes, and built up what looked like a replacement application. It had some of the original "logic flow" through the classes, and some classes were poorly designed [Mostly this was because of a subset of the global variables that was too hard to tease apart.]
It passed unit tests at the class level and at the overall application level. The legacy source was mostly used as a kind of "specification in C" to ferret out the really obscure business rules.
Last year, I wrote a project plan for replacing 30-year old COBOL. The customer was leaning toward Java. I prototyped the revised data model in Python using Django as part of the planning effort. I could demo the core transactions before I was done planning.
Note: It was quicker to build a the model and admin interface in Django than to plan the project as a whole.
Because of the "we need to use Java" mentality, the resulting project will be larger and more expensive than finishing the Django demo. With no real value to balance that cost.
Also, I did the same basic "prototype in Django" for a VB desktop application that needed to become a web application. I built the model in Django, loaded legacy data, and was up and running in a few weeks. I used that working prototype to specify the rest of the conversion effort.
Note: I had a working Django implementation (model and admin pages only) that I used to plan the rest of the effort.
The best part about doing this kind of prototyping in Django is that you can mess around with the model, unit tests and admin pages until you get it right. Once the model's right, you can spend the rest of your time fiddling around with the user interface until everyone's happy.

Whatever you do, see if you can manage to follow a plan where you do not have to port the application all in one big bang. It is tempting to throw it all away and start from scratch, but if you can manage to do it gradually the mistakes you do will not cost so much and cause so much panic.

Half a year ago I took over a large web application (fortunately already in Python) which had some major architectural deficiencies (templates and code mixed, code duplication, you name it...).
My plan is to eventually have the system respond to WSGI, but I am not there yet. I found the best way to do it, is in small steps. Over the last 6 month, code reuse has gone up and progress has accelerated.
General principles which have worked for me:
Throw away code which is not used or commented out
Throw away all comments which are not useful
Define a layer hierarchy (models, business logic, view/controller logic, display logic, etc.) of your application. This has not to be very clear cut architecture but rather should help you think about the various parts of your application and help you better categorize your code.
If something grossly violates this hierarchy, change the offending code. Move the code around, recode it at another place, etc. At the same time adjust the rest of your application to use this code instead of the old one. Throw the old one away if not used anymore.
Keep you APIs simple!
Progress can be painstakingly slow, but should be worth it.

I would not recommend JScript as that is definitely the road less traveled.
ASP.NET MVC is rapidly maturing, and I think that you could begin a migration to it, simultaneously ramping up on the ASP.NET MVC framework as its finalization comes through.
Another option would be to use something like ASP.NET w/Subsonic or NHibernate.

Don't try and go 2.0 ( more features then currently exists or scheduled) instead build your new platform with the intent of resolving the current issues with the code base (maintainability/speed/wtf) and go from there.

A good place to begin if you're considering the move to Python is to rewrite your administrator interface in Django. This will help you get some of the kinks worked out in terms of getting Python up and running with IIS (or to migrate it to Apache). Speaking of which, I recommend isapi-wsgi. It's by far the easiest way to get up and running with IIS.

I agree with Michael Pryor and Joel that it's almost always a better idea to continue evolving your existing code base rather than re-writing from scratch. There are typically opportunities to just re-write or re-factor certain components for performance or flexibility.