I can understand why you would think that, my explanation doesn't really do it justice. I it really does do quite a lot more and provides a much richer domain specific language to do this. Since I failed to communicate it last time I'll not try again, but again I can see why you might think that. Maven attempts to do something similar to Capistrano except that I haven't found a JMX-oriented Maven plugin, which is key for J[2]EE apps.
OK, Java, Ruby,.NET, Linux, BSD, Solaris, Mac and Windows fans - chill!
I love you all, but you do bicker too much.
I cannot comment much on.NET, but three top notch Windows/MS developers I have known for years have said this about.NET: many of the standard widgets produce non-standard, non-validating (X)HTML and CSS. This is a fairly big deal, which hopefully future versions of.NET will rectify eventually. Other than this major point that they keep drilling down on, they are happy from a productivity perspective of developing on the.NET platform.
As a huge Ruby and Rails fan, I still think Java should remain in the enterprise as opposed to Ruby/Rails. The reason is simple: going enterprise killed Java's productivity gains. I mean this in the nicest way, because until 3 years ago I thought Java was the dog's tuxedo. Couldn't imagine using another language for any type of development.
Ruby isn't perfect, neither is Rails. I make no such assertion. There are areas where using Java as an example might benefit the future development and progress of Ruby and/or Rails. However, I suggest the reverse is also true.
I have two examples: (a) automatic server application deployment; (b) dependency management of external libraries (like RPMs).
(a) In the Ruby/Rails world we have Capistrano, which provides a very nice *start* towards a comprehensive tool to help automate the deployment process (in various environments if necessary) for server application environments. In Java/J[2]EE world there is the JMX API, but you must write your own Java/Beanshell/Groovy, etc deployer based on a fine grained API. Capistrano provides a more intuitive way, easier (less fuss) way to create deployment "recipes" to save time. Again Capistrano is not perfect, but a great start considering Rails has only been around for 2 years and J[2]EE has been around for 6+ years. I continually search sourceforge, java.net, codehaus and similar OSS project websites seeking such a tool that is in active development and has a remotely similar feature set to Capistrano for the Java world utilizing JMX, but it does not seem to exist or has a user base of perhaps 10 maximum. Over the last 10 years of my Java career I have implemented 3 custom/in-house tools to do this, but our focus should have been on solving business problems in our applications NOT writing new deployment tools. There is a big difference between writing a deployment recipe for each environment and writing a reliable deployment tool that does all the things we need it to do AND the configuration files for each environment.
(b) In Ruby (not specific to Rails, but the Ruby language environment) there is a concept of Ruby Gems. Gems are basically JARs on steroids, that can define dependencies and requirements for the gem installer to install prior to that Gem. For example, in Java we have the Xerces and Spring libraries. So if we translated the notion of Gems to the Java world Spring library would have a manifest/descriptor that defines what external libraries that are pre-requisites to installing Spring. We would probably specify Xerces and provide the version number(s). Some versions of Spring may also specify requirements like you must be using JDK 1.4+ or even 1.5+. The Ruby Gem mechanism is extremely similar to the YUM and APT package managers on Linux. This sounds like a stupid thing to worry about, but having worked on large scale enterprise deployments throughout my software consulting practice I have encountered production environments that are unmanageable from a JAR and deployment perspective. Recently I finished a JEE project that had 3 different versions of Xerces in the classpath and the wrong Xerces JAR was first! This took a very long time to determine the cause of the issue because there is no concept similar to a Gem in Java. Having a Java equivalent to a Gem would improve productivity for application deployment without a
Role I work 60-70% of my time as a member of the core consulting team here and the rest of the time on "IT" administration and management around the local office. I should note though that I am a software engineer first and fore most, but it so happens that in small businesses one must wear many hats. Last year I was also heavily involved in accounting activities and managed a marketing program.
Scale I only have 30 workstations and 27 servers (only 2 are publicly accessible and 8 are in a RCF) to worry about presently:
Culture It should be noted that my users are technically very competent, which is a totally different can of worms to you (I assume from your comments), but there are plenty of issues to guard against with too competent a user as well!:) The issues are just different.
Environment Server OS: RHEL 3 Workstation OS: Fedora Core 4 and 2 MacOS X (those damn graphic designers/marketing folk!:) VPN Server OS: NetBSD 3 (runs on an Alpha box)
Software Tools SCM: Subversion http://subversion.tigris.org/ Issue Tracking: Trac, which integrates nicely with Subversion http://edgewall.com/trac/ Internal Documentation (for future growth): Trac's built-in wiki http://edgewall.com/trac/ Web Server: Apache, mod_python, mod_ssl, mod_dav, and all that good stuff http://apache.org/ Knowledge Base: OpenCyc (but looking for something better that is still open source) Intranet Framework: Python 2.4/TurboGears/Apache/mod_python http://python.org/ and http://turbogears.org/ Authentication: Fedora Directory Server (LDAP) Updates: Yum, up2date Server Monitoring: Nagios http://www.nagios.org/ [Internal] Remote Access: ssh and Gnome/VNC for the rare visual task [External] Remote Access (i.e. VPN): OpenVPN
Internal Tools Fixed Asset Management: Rolled my own TurboGears Web/AJAX application that hooks into our accounting system (it took 3 days part-time). Backups: Rolled own Python backup mechanisms including scripts Deployment Tools: Using Python's autoinst http://autoinst.tigris.org/ Continous Integration: I have started using Bitten instead of using cron and shell scripts to launch Python distribution builds and tests on a nightly and "continuous" basis for immediate feedback - something I find invaluable.
Office Software As mentioned in a previous posting using a good calendaring tool is a very good idea. My recommendation is the Calendar extension for the Mozilla suite of tools.
Slashdot Mirror
I can understand why you would think that, my explanation doesn't really do it justice. I it really does do quite a lot more and provides a much richer domain specific language to do this. Since I failed to communicate it last time I'll not try again, but again I can see why you might think that. Maven attempts to do something similar to Capistrano except that I haven't found a JMX-oriented Maven plugin, which is key for J[2]EE apps.
OK, Java, Ruby, .NET, Linux, BSD, Solaris, Mac and Windows fans - chill!
.NET, but three top notch Windows/MS developers I have known for years have said this about .NET: many of the standard widgets produce non-standard, non-validating (X)HTML and CSS. This is a fairly big deal, which hopefully future versions of .NET will rectify eventually. Other than this major point that they keep drilling down on, they are happy from a productivity perspective of developing on the .NET platform.
I love you all, but you do bicker too much.
I cannot comment much on
As a huge Ruby and Rails fan, I still think Java should remain in the enterprise as opposed to Ruby/Rails. The reason is simple: going enterprise killed Java's productivity gains. I mean this in the nicest way, because until 3 years ago I thought Java was the dog's tuxedo. Couldn't imagine using another language for any type of development.
Ruby isn't perfect, neither is Rails. I make no such assertion. There are areas where using Java as an example might benefit the future development and progress of Ruby and/or Rails. However, I suggest the reverse is also true.
I have two examples: (a) automatic server application deployment; (b) dependency management of external libraries (like RPMs).
(a) In the Ruby/Rails world we have Capistrano, which provides a very nice *start* towards a comprehensive tool to help automate the deployment process (in various environments if necessary) for server application environments. In Java/J[2]EE world there is the JMX API, but you must write your own Java/Beanshell/Groovy, etc deployer based on a fine grained API. Capistrano provides a more intuitive way, easier (less fuss) way to create deployment "recipes" to save time. Again Capistrano is not perfect, but a great start considering Rails has only been around for 2 years and J[2]EE has been around for 6+ years. I continually search sourceforge, java.net, codehaus and similar OSS project websites seeking such a tool that is in active development and has a remotely similar feature set to Capistrano for the Java world utilizing JMX, but it does not seem to exist or has a user base of perhaps 10 maximum. Over the last 10 years of my Java career I have implemented 3 custom/in-house tools to do this, but our focus should have been on solving business problems in our applications NOT writing new deployment tools. There is a big difference between writing a deployment recipe for each environment and writing a reliable deployment tool that does all the things we need it to do AND the configuration files for each environment.
(b) In Ruby (not specific to Rails, but the Ruby language environment) there is a concept of Ruby Gems. Gems are basically JARs on steroids, that can define dependencies and requirements for the gem installer to install prior to that Gem. For example, in Java we have the Xerces and Spring libraries. So if we translated the notion of Gems to the Java world Spring library would have a manifest/descriptor that defines what external libraries that are pre-requisites to installing Spring. We would probably specify Xerces and provide the version number(s). Some versions of Spring may also specify requirements like you must be using JDK 1.4+ or even 1.5+. The Ruby Gem mechanism is extremely similar to the YUM and APT package managers on Linux. This sounds like a stupid thing to worry about, but having worked on large scale enterprise deployments throughout my software consulting practice I have encountered production environments that are unmanageable from a JAR and deployment perspective. Recently I finished a JEE project that had 3 different versions of Xerces in the classpath and the wrong Xerces JAR was first! This took a very long time to determine the cause of the issue because there is no concept similar to a Gem in Java. Having a Java equivalent to a Gem would improve productivity for application deployment without a
Role
I work 60-70% of my time as a member of the core consulting team here and the rest of the time on "IT" administration and management around the local office. I should note though that I am a software engineer first and fore most, but it so happens that in small businesses one must wear many hats. Last year I was also heavily involved in accounting activities and managed a marketing program.
Scale
I only have 30 workstations and 27 servers (only 2 are publicly accessible and 8 are in a RCF) to worry about presently:
Culture
It should be noted that my users are technically very competent, which is a totally different can of worms to you (I assume from your comments), but there are plenty of issues to guard against with too competent a user as well!:) The issues are just different.
Environment
Server OS: RHEL 3
Workstation OS: Fedora Core 4 and 2 MacOS X (those damn graphic designers/marketing folk!:)
VPN Server OS: NetBSD 3 (runs on an Alpha box)
Software Tools
SCM: Subversion http://subversion.tigris.org/
Issue Tracking: Trac, which integrates nicely with Subversion http://edgewall.com/trac/
Internal Documentation (for future growth): Trac's built-in wiki http://edgewall.com/trac/
Web Server: Apache, mod_python, mod_ssl, mod_dav, and all that good stuff http://apache.org/
Knowledge Base: OpenCyc (but looking for something better that is still open source)
Intranet Framework: Python 2.4/TurboGears/Apache/mod_python http://python.org/ and http://turbogears.org/
Authentication: Fedora Directory Server (LDAP)
Updates: Yum, up2date
Server Monitoring: Nagios http://www.nagios.org/
[Internal] Remote Access: ssh and Gnome/VNC for the rare visual task
[External] Remote Access (i.e. VPN): OpenVPN
Internal Tools
Fixed Asset Management: Rolled my own TurboGears Web/AJAX application that hooks into our accounting system (it took 3 days part-time).
Backups: Rolled own Python backup mechanisms including scripts
Deployment Tools: Using Python's autoinst http://autoinst.tigris.org/
Continous Integration: I have started using Bitten instead of using cron and shell scripts to launch Python distribution builds and tests on a nightly and "continuous" basis for immediate feedback - something I find invaluable.
Office Software
As mentioned in a previous posting using a good calendaring tool is a very good idea. My recommendation is the Calendar extension for the Mozilla suite of tools.