Friday, December 08, 2006

Rolling a long

Well it's been a long time since I've posted anything. Lately there has just been soo many projects, work and pet.

I've spent time playing with Portlets, using the Spring 2.0 MVC and Hibernate. I've also been hacking at an interesting application called 'Democracy Player'. The software has versions for Windows, Mac OS X and Linux. Each one uses different means of GUI rendering. On Mac Cocoa is used and on Linux Gtk. It is mostly written in Python, with some C/C++/ObjC used for the native GUI. I'm liking Python, much like I have enjoyed the little work I have got to do with Ruby.

At work it's been lots of integration work. I've been tasked with reimplementing some old integration processes with our new ERP solution. One big integration point in our legacy system is Amazon. I've just finished integrating my companies warehouse fulfillment data with Amazon. Next thing is to integrate our returns/cancellation/refund data with Amazon. I've been doing a bit of tweaking here and there for the order entryways. I created a simple rest like web service to take orders, returning an immediate sales order. This was needed for a couple of satallite sites that we deal with. They need to know right away if a sales order was successfully created. The other entry point which we will soon use for all web order entry is the messaging system. The messaging system makes submitting orders from just about any app, written in any language trivial. It also allows our companies order data to flow smoothly through from web to ERP.

Not a lot new here.... Hopefully I will have something more interesting to post here soon!

Wednesday, October 25, 2006

Integration across the board

So I've come to a point where I have Windows services reading from ActiveMQ = AMQ (it's MOM software) and feeding a system via a COM connector. The COM connector seems to be holding up really well. Last night I was tossing messages at AMQ at a rate of 10 per second. These messages are about 150-200 characters in size. I tested 360010 message going through. The messages finally ended up in a database. This morning I checked and 360010 messages where in the table! Also the software I use to track the status of the AMQ showed that 360010 messages had been put on a queue, and the same amount read off. So things are looking up.

I used Ruby to send the messages onto AMQ. I think I have mentioned before that there is a simple messaging protocol called STOMP, which I used to connect to AMQ from Ruby. AMQ has a snappy transport connector which allows you to do this. AMQ also allows you to write your own transport connector, so if you don't like a protocol write your own :)

I'm testing changes I made to the STOMP Ruby client. I made it much easier to use the client to send messages that get marshalled in the AMQ STOMP transport connector. The client as it came did not make it possible to send what would be a JMS TextMessage in AMQ. Messages that came from the basic client came into AMQ and got marshalled into the JMS BinaryMessage type. The AMQ transport allows for marshalling to BinaryMessage or TextMessage, depending on STOMP header settings. With some simple Ruby coding I have a modified client that now has an extra method 'sendTextMessage'. When using this method the message in AMQ will be marshalled as a TextMessage! TextMessage fits our current purposes better than BinaryMessage.

So back to the testing. I have 4 producers spitting 20 messages a second onto a queue, and one consumer reading messages off of the queue as fast as it can. I'm up near 200k messages sent/received and counting. I'll see if things can break at some point :) I also have the Windows service coming on and off to take messages from this queue. This tests how well things are handled with consumers going down and coming online on the fly.

So the big picture is to be able to easily integrate a M$ product into a ESB using the AMQ messaging system. Rather than have to handle the problem of the M$ product dying and data being dropped we will have a scenario where messages are kept and fed over when the product comes back online. We should also have an easy time reusing bizz logic components in the ESB.

Saturday, October 21, 2006

More messaging fun!

In my last post I talked about using a STOMP client for Ruby. STOMP is a very light weight protocol for doing messaging. I have implemented an ESB (Servicemix) and messaging system (ActiveMQ) for my company. Our business depends on many programming languages, databases, software and such to keep things running. STOMP as I explained before allows the web guys at my work to message our system using Perl, Ruby, Python, C# and more :). This will allow for easy routing of web data through our ESB.

The goal for now is to set up orders to flow through the ESB for our web department. We are using this new piece of software to do all our CRM, product maintenance and other business functions. I have refered to this software as 'Magic' and will continue to here. Orders will need to flow into Magic somehow. Magic is M$ built, and I figured why not put the ActiveMQ NMS implementation to use. NMS is like a .Net version of JMS. The guys over on the ActiveMQ project created an implementation of NMS for ActiveMQ. This is very nice of them. I can now use either a STOMP client or NMS client to message with ActiveMQ from my C# code!

So at first I tried to create .dll libraries of the AMQ NMS implementation, then load those into Magic. Magic has CLR functionality in it's newest release. This means that the language you code with inside Magic can use objects written in C#, VB.net, Java, and on... The problem is the CLR implementation in Magic is lame! It does not support language features like events, delegates, virtual functions etc. So I cannot use the NMS code inside of Magic. Bummer. I mulled for a day about this one while working on other stuff. Then I found an idea.

Magic has a COM connector, which allows you to call pretty much any code written in Magic. This is nice for executing remote procedure calls to Magic. So my new solution is to write Windows services which do the messaging, then pass/pull data from Magic using the COM connector! I have already written my first service. It writes a simple XML doc to a queue on a separate machine every 30 seconds or so.

Now that I have this written I will be focusing on writing the COM connector code to push and pull messages from Magic. Pushing is the easy part as Asynchronous communication is easy to keep. As a message comes in, the service will grab it and push it over to Magic. Pulling data out may be harder. Right now I use a timer object in my service, to execute some functions every 30 seconds. I figure I may have to do this polling type thing to pull data. It sucks, but it is better than the alternative. In the long run it allows finer tuning of how the data will flow across our system.

Right now we are getting data out of Magic using web services. I'm not impressed with web services. The only time people ask me to write them is for improper purposes. When we need to get data out of Magic, we run batch processes which send the data to an external web service. Magic spams out large chunks of data to the web service, causing it to stress badly. But for the most part the web service sits there doing nutin :) It's not a very pretty picture. With messaging we can take the flow and streamline it. Messages flow out as they are created, not at batch time. The message consumer can pull the messages as it likes, rather than having to deal with a large volume being spamed to it. This relieves stress accross the system. very nice. I think my boss is convinced that this is the way we should go. I just need to get the many pieces of this together, so that we can do some testing.

Monday, October 16, 2006

STOMP

I started something in motion today at work. A thing that may revolutionize inter-departmental communciation. I am urging the Perl/Ruby hackers at my work to get involved with my Smix/Amq habit. They will be doing so using the Perl or Ruby client for STOMP. STOMP is a very simple protocol for doing messaging. When I say simple I mean it. Look at the code for the Ruby client. AMQ, my favorite implementation of the Java Messaging Service (JMS), offers an adapter so that you may handle STOMP messaging clients. SWEET!!!

So what does that mean for me? Well those web guys are Perl/Ruby/PHP masters but don't like the idea of getting their feet wet with Java. I wrote up some super simple Ruby scripts for doing STOMP messaging with AMQ. One pair of scripts reads and writes messages from/to a topic respectively. The other pair of scripts reads and writes message from/to a queue respectively. Publishing and consuming of messages happened very quickly. I'm hoping we can get some measurements soon.

I showcased this stuff to one of the top web programmer guys. I don't know if he was wow'ed but he seems excited to start playing with it. I also got him to install the Java 1.5 SDK on his windows machine. He needs it so that he can use jconsole to monitor messaging in AMQ. Jconsole is bundled with the SDK, and is used to access JMX enabled apps. JMX stands for Java Management Extensions. It's pretty nice to see exactly whats going on with your messaging service.

I'm pretty excited. This should make working with the web team much easier. In the past my department has used flat files and web services to communicate. This will add an extra way for our processes to communicate.

Sunday, October 08, 2006

And the award goes to!

WARNING: extreme rant dead ahead!

I'm about to be totally slammed. By slammed I mean that I will have no social life and spend all my time working on a huge project. My predicament stems from poor planning from the top down. My company has decided to build a brand new warehouse, running it on completely new software, for our purposes we will call if 'LowSquat'. Oh yeah and they also have brought in a completely new piece of software to run all the business functions such as: customer support, order entry, and product data management. Let's call this software 'Magic'!

Magic is not written yet. It's a piece of software which you build 'vertically' to suit your company. Magic's manufacturer licenses business partners to build these 'vertical solutions' (tailored software for client companies). Magic has some great features. It allows us developers to make changes, or create whole new applications that run in it's environment. Thats great and all, but Magic's out of the box the software doesn't do what we need it to do. It comes with a bunch of basic, 'vanilla' applications (like customer service, order entry, and financials). It will be our developers jobs to extend these apps so that they meet our business needs. Fun... So we need to work with this partner to develop Magic's apps/functions, then integrate with the warehouse software (LowSquat), inventory planning software etc. We do this and make sure that this happens right on time (a date that exists only based on construction of the warehouse!).

I wouldn't be so bent out of shape if I trusted the management at my work. Unfortunately they have shown that they do not want to extend themselves. So far I have seen a lot of half measures. Small changes in the way we do things that make little benefit, or that are all talk. One huge obstacle in the project moving forward is that they expect us to already know how the vanilla apps work. Our management's expectations (which do not exist on paper) are going to kill this project. No one knows exactly how all the vanilla apps work. We also do not have the test data set up to properly to 'play' with Magic's vanilla apps. So how do we find out how the unmodified Magic software works? It would be obvious to any project manager that to gather requirements for modifying Magic, you would first need to be very comfortable (dare I say an expert) with Magic.

The software also will be different when we go live. We are using Magic 2.5, but when we go live we will be using a whole new version 3.1!!! 3.1 is completely different in some respects. So why is that a problem? We won't have 3.1 until a month before the projects due for completion. Yikes.

A little background on the project so far. We first worked on a small 'sample' phase of the project. It was one piece of many, and it took damn near 5 months (for me) to complete. The planning for that phase did nothing but cause problems. The milestones/deliverables had dates set that did not rely on any useful information. No one in management bothered to write a full project plan that detailed each feature, how it should work, how all features integrate, how to test each and know it works etcettera. The project was actually just set up by someone with *some* technical experience, so that with dates combined we would hit a certain launch date. This launch date came from above I think. It was bad...one day during a meeting I was given the timetable to complete tasks assigned to me. Laughably, we spent hours going over this completely groundless plan. I could have used that time to do some real work. I don't know how the management felt about the meetings, but they left me frustrated, and I wonder what they got from them.

Another big miss on the 'sample' phase was not communicating across departments. People in departments which should have been involved never knew about our project. We where unaware of how our our project would affect other people's jobs. What happened was I was knee deep in development and finally the word got out what was going to happen. People were unhappy. Last minute, when the project should have been sailing to completion, a bunch of new 'critical' requirements came up. Since time was so short we had to hack together whatever we could. There was no way that we where going to postpone the project launch.

Another real problem I have is that no contact list has been provided. We should have a list of all 'power users' or 'insanely knowledgeable' contacts on each facet of our business. That way I don't have to chase around to find the expert. This allows me to quickly contact a person and get the info I need. We should also have proper training, and facilities to get the training we need. I should not have to wait for 1/2 a day or more to get the email describing what I need.

I guess the above comes to this point: if you don't bother to do a good job, don't expect me to do it for you! By good job I don't mean that you work real hard. I mean you work smart. You know what it is you are doing, and why you are doing it, and why it is a benefit. You communicate those things to other people (on paper!). You look for solutions to problems, problems that you confidently define (on paper!). You face those problems one by one, but all the while keep the big picture in view. Dates that are not created from thoughtful, thorough planning, but from need to hit a date are just a waste of everyones time.

I wish that the management had brought in more experienced people to manage the project. I seriously question the fact that we have total 'greenies' running the show. A project of this caliber requires massive planning. Even I know that and I'm just a low peon of IT. The planning has been lax. They basically drummed up a bunch of 'gaps' and said to me and mine "here you guys figure these out and implement the solution". Great f#*king project management! Now that they have gone through all that hard work to find what the gaps are, I can:

  • Become an expert on the current business functions (much of which I don't know)
  • Become an expert on Magic's business functions, look for gaps :(
  • Compare the 2.5 Magic app to the 3.1 Magic app, find gaps
  • In one month implement all the fixes to the vanilla 3.1 Magic release so that it can run our companies business functions
  • find out if proper functions exist in the new software
  • write business requirements
  • write design requirements
  • Create milestone/deliverables (running tested features?)
  • implement solutions (git' codin)
  • make contact with the users/customers
  • test the solutions
  • write test plans (maybe in my head only)
  • document proper processes
  • document my time and progress
  • Create and set my own goals, milestones and deliverables
  • Manage people on my team
  • More to come


Compound all this work with the following:

  • Create plans to train employees on new software
  • Train the employees on new software
  • Test the fully integrated solution
  • Test the warehouse on the new softwares
  • Collect info on the terrible bugs (don't sweat the small ones ;)
  • Fix the terrible bugs (probably goes in my list above)


There has got to be many things I'm missing here. When I look at all the things we have to do, and how much talent we have to do it, I just can't fathom things going well. At least I know I will do the absolute best I can :)

Tuesday, October 03, 2006

Maven 2 + Hibernate + HSQLDB

Maven make projects very portable. Hibernate makes working with persistent objects simple. HSQLDB is a Java database that you can run embeded in other programs.

A problem with using Hibernate is it can take away some of the portability of your project. This is because you will need to provide a database for making your objects persistent. In doing so your test config files will be spec'd to a single database. What happens when someone runs the project's tests and does not have access to the test database? The tests will fail :( We want to have unit tests be used for all our hibernate objects. It is especially important to thouroughly test them, as they will be a central part of your projects functioning properly (especially web projects!).

Luckily Maven makes it easy to use one database for testing, and another for production. This is where HSQLDB can come in handy. You can create a hibernate config just for testing which connects to an in memory HSQL database. You will need the proper files in src/test/resources folder of your Maven 2 project. The files include the test version of your hibernate config file, and also the test hibernate mapping files that accompany your code. I put the hibernate mapping files into folders that mirror the packaging of the POJO object classes. When you run 'mvn package' the .hbm files will be placed in the same folder as the POJO class they belong to. Here is an example of my Maven 2 project's structure:

/project
pom.xml
...other files
/src
/main
/java
/some
/package
Foo.java
/resources
hibernate.cfg.xml
/some
/package
Foo.hbm.xml
/test
/java
/some
/testpackage
TestFoo.java
/resources
hibernate.cfg.xml
/some
/package
Foo.hbm.xml


So you can see that there are a set of hibernate files for the build and the test phase. Now in the test hibernate.cfg.xml file you will need to have the following properties set:


<!-- Database connection settings -->
<!-- HSQL DB -->
<property name="connection.driver_class">org.hsqldb.jdbcDriver</property>
<property name="connection.url">jdbc:hsqldb:mem:aname</property>
<property name="connection.username">sa</property>
<property name="connection.password"></property>

and...

<property name="dialect">org.hibernate.dialect.HSQLDialect</property>
<mapping resource="some/package/Foo.hbm.xml" />


These entries should have you now set up to use a in memory database for all your testing with hibernate. But before this will work you need to do one more thing.

Set up you Maven 2 project so that HSQLDB is a dependency. Added this dependency section to your project:

<dependency>
<groupId>hsqldb</groupId>
<artifactId>hsqldb</artifactId>
<version>1.8.0.1</version>
</dependency>


Note that you will not need to make any specific JDBC driver available. The HSQLDB dependency contains the proper driver!

Using this pattern you will be able to make very portable Maven/Hibernate projects. Users any place in the world will be able to check out your project and test it immediately. If they would like to test using their own database it is not hard for them to overwrite what is in the src/test/hibernate.cfg.xml file.

Friday, September 29, 2006

Open source commercialism or: how I learned to stress test and prove the app

For any perspective software you may use to run a company, you will need a guaruntee that it will be able to handle what you throw at it. In the case of a bleeding edge, open source project that shows much potential you really want to make that software work. Besides the benefits of open source, such as the code being downloadable/editable/compilable, the software is free!!! Pair that with the fact that if it is a hot project then many eyes have glanced the codebase, and many users have filed many bug reports and feature requests on issues they have. Open source projects can be very commercialy viable: just look at Tomcat.

I am working with a ambitious piece of software called Servicemix (Smix). If things go well it could really help me and my company out. While we have been using it in our production system for over 3 months I have not had time to really stretch it out. What I mean is test more of the 'out of the box' functionality in stressed ways. Smix is an ESB which implements the Java Business Integration (JBI) specification. This specification is much like the Sun servlet spec, JDBC spec etc. Those Sun guys love their specs!

To really test out this software I have created some basic service assemblies (SA). A service assembly allows you to package together functionality that comprises any number of processes. It is also part of the JBI spec. An example of a SA would be a consumer for a JMS topic queue, which passes all messages to an XSLT transformer, which in turn passes the message to an app that processes the messsage and inserts the data into a database. This would all be packaged into one file for deployment. Those familiar with J2EE would think of it as a .ear file. If an SA is analogous to a .ear, then a service unit (SU) would be to .war. In the previous example the SU's would be the JMS routing, the XSLT services, and the database service. Each would be packaged as it's own service unit in Smix.

Now I also created a configurable JMS provider, which can be tasked with many different things. I created a configurable JMS consumer, which can read from a queue. Last night I sent 75,000 small messages through an SA I created which does two separate XSLT transforms. The transfromed results go onto two separate queues. The contents of those queues are consumed by two of the consumers I created. Everything went off hitch free! Very nice for my first real foray into stress testing Smix. Here are some approx. results:

Started message providing: ~9:40 pm

Message provider rate: ~6-7 message per second
Message consumer rate: 7.8125 messages per second

Message consumer 1 finished: 2006.09.28 AD at 22:38:17:108 PDT
Message consumer 2 finished: 2006.09.28 AD at 22:38:17:108 PDT

The message payload:

<message>
<count>(message #)</count>
<datetime>(date-time inserted)</datetime>
</message>

An example of a transformed message:
<ecometry>2 ::: 2006.09.29 AD at 07:47:41:996 PDT</ecometry>

Wednesday, September 27, 2006

Working

Lot's of work with Servicemix... I have checked out the newest SNAPSHOT release and built it, deploying all the project artifacts into my companies Maven snapshot repository. I'm trying now to get all the conifguration I had for Smix before into tidy little service assemblies (SA's). These are kinda like .ear files, in that they contain service units (SU's) which are sorta like a .war. The whole service assembly idea is from the JBI specification, which Smix implements.

I'm working mostly now on learning to develop for JBI and Servicemix. The newest snapshot release has reworked examples which show how to use the maven-jbi-plugin to easily create and deploy JBI components (shared libs/binding components/service engines/service assemblies). I am posting a little Smix developer roadmap over on the Smix site; follow this link.

...also on the board is getting CVS managed projects into Subversion. Our SVN repository is now up and ready to go. We got the cvs2svn tool installed, which will allow for migrating one project at a time from CVS to SVN. The benefit in doing this is all historical information for the CVS managed project will be translated into SVN. Very nice!

With Subversion up and running I hope to soon get Continuum installed on our development server. It is a continuos integration server which works very well with Maven 2. It also works with plain old Ant, or Maven 1. Another thing on the board is getting a nice front end to our Subversion repository. I looked at fisheye, it is pretty nice but costs a bit of dough to use. I passed it up to my boss. If he is impressed then maybe we will end up writing the check

Friday, September 22, 2006

Servicemix, Spring 2.0 Maven poms in central

My work with portals has been stopped as of late. I talked to someone at the Spring project, offereing my services to get some poms together for the Spring dependencies. I found out that Ben Hale, a member of that project is going to be doing this. Can't wait for those to be up. Then I can Maven-ize the petportal app and offer it up.

I have been hacking away at Servicemix, trying to get some things done. First is using a component that comes with Smix for reading from a JMS channel (queue/topic) using JCA to handle all the resources. This component has not worked for me yet. It causes some very wierd behavior when using a durable topic subscriber. The subscriber will not get some of the messages it misses when down. This means that it is not functioning like a durable subscriber. So I gotta fix that issue.... meanwhile I am also working on learning how to create service assemblies for Smix. This allows creating SOAP services in the container, which is what I would like to do eventually. We are running our XFire SOAP services in Tomcat.

Tuesday, September 12, 2006

petportal Spring 2.0 Portal MVC application

This is how to get the petportal application that was supposed to be released with Spring 2.0.

First check this page:
http://sourceforge.net/cvs/?group_id=73357

That is the sourceforge site for Springframework. You can view the CVS sources that are checked in. There should be a little ditty about anonymous CVS access. I used this from my MacBook terminal to get the petportal application:

cvs -z3 -d:pserver:anonymous@springframework.cvs.sourceforge.net:/cvsroot/springframework co -P spring/samples/petportal

happy coding!

Back again....

I haven't been posting much lately (obviously). My fiance has moved up here to good old Medford, Oregon, and I have been pretty busy between helping her get settled and working. I have been playing around with a bunch of new stuff since my last post.

Ruby: I have been able to get my hands on 'Ruby Cookbook' from O'Reilly. My boss at work bought a copy for our department, bless his heart. If you plan on quickly jumping into some useful Ruby I highly recommend this book. I have already used it for developing a SOAP service client to test a Java XFire service I wrote. With this books aid I wrote the whole thing in five minutes. The benefit is in being able to test my web service with another language, and to verify the correct responses. I feel the 'cookbook' series is one of the best for becoming useful in a new language. They match a seasoned coders ability to look past the basics of a language's grammar and begin actually getting into the api's and such of a language (the nitty gritty ;).

XFire: this is a nifty Java tool for doing webservices, which get war'd up and deployed into a J2EE web container. I am using it to create web services at work now, deploying to a 5.x version of Apache Tomcat. XFire is very quick and easy to work with. I started out using MyEclipse's new built in XFire web project. Of course I wanted to use XFire in a Maven2 type project (for the enormous benefits that Maven2 provides). This is easy!!! The best part about using XFire was that the services I created worked with M$ Dynamix Ax out of the box, which is a huge deal to my bosses. I was using Axis before, but I had to customize WSDL files for each of my services. Ax's SOAP object did not like the WSDL files automatically created by Axis (thus the customizing). Creating and maintaining WSDL files was time consuming and complicated the whole web service creation process for me. XFire will also auto generate WSDL files, which then work with M$ Dynamix Ax. Hurrah!!!

Servicemix (Smix) and ActiveMQ (AMQ): these amazing open source projects have become a major deal at my work. We are currently using both to implement our cockeyed attempt at SOA. We are luckily starting out easy, but I get the feeling I will soon be going full bore into setting up our company with an Enterprise Service Architecture (ESA). My awsome boss bought more books. I don't have all of them here, but I will tell you that "Enterprise Integration Patterns" is the book to read to get your feet wet. It is a theoretical type textbook which ellicits heartwarming memories of college reading. In it you will not find long code samples. You will find in depth explanations of how and why things work in the enterprise integration world.

Portlets: I have once again taken up the burden of Java's Portlet api. It is pretty rad. I am using Liferay which is actually better for portlet development (in my opinion of course) than Pluto. Pluto is supposed to be a container used for portlet development. I think it's got a ways to go, considering the ease of deploying/redeploying portlet .war's in Liferay. Oh and not to mention how nice Liferay looks! I am hoping to write a nifty portlet which will interface with a tool we use for storing information on projects and requests for things. This tool is called QuickBase, and is an online app from Intuit. We have used it to develop a bunch of stuff for tracking projects. It was my dept's first crack at doing anything of the sort and falls a bit short (especially in the ease of use aspects). If I can get it up it will be a very nice proof of concept. Fingers crossed.

Portlet-MVC: Who wants to do plain old portlet development? Not me! I first messed around with the Struts portlet bridge framework, but quickly became bored of it. Struts may be the big kid, but the kid is obviously a beer short. I have been searching around for a better MVC for portlet development. I have found Spring 2.0's Portlet MVC. I am happy, especially since I'm a fan of Spring to begin with. The Spring portlet framework allows you to easily leverage Springs niceties. You can also work in Struts, WebWork, etc. if you really want to....

So thats it. I am trying to check out a portlet app from Spring's site. It is supposed to be packaged with the 2.0 releases of Spring, but I downloaded many different versions and none included the sample app. I'll post later on how I get it (if I can). C'ya.

Tuesday, August 15, 2006

Ruby/Rails update

I've been playing around with Ruby, and the web framework for Ruby called Rails. I'm finding that Rails has some nice benefits. Using rails I've set up a couple database backed web apps from tutorials found online. I also quickly created an AJAX web app which uses Flickr's API to download thumbnails and display them. I've done this and more in two days....and I didn't have more than a couple hours previous experience with Ruby or Rails.

If you are a Perl/PHP/Python programmer and haven't tried Ruby on Rails check it out.

If you are a C/C++/Java/.NET/etc. programmer and haven't tried Ruby on Rails check it out.

Go to the Rails site and get Rails.

You will find directions on getting Ruby, and Rails up and running on your machine. I am working on a MacBook, but I've also installed Ruby and Rails on a Windows machine. It works great on both.

Once you have Ruby & Rails I recommend downloading Mongrel. Find it here.

Mongrel is a lightweight server that will make developing your initial Rails apps easy. I have not had time to investigate but it seems Mongrel is also being used for hosting on the net. Why? I think it has something to do with it being fast, and working well with other technologies. I'll post back with more information when I get it.

Once you get Ruby, Rails, and Mongrel here are some links to tutorials that you should definitely work through:

Do these 'screencasts', they are very informative: link

From the same Rails site check out the 'Rolling with Ruby on Rails' series: link

Find some very interesting articles on using FLEX and Rails: link

And another FLEX/Rails tut: link

There are a lot of good articles out there so if you get hooked on Rails it should not be hard to find more information.

Oh and here is a pretty good online book I found on Ruby itself: link

Saturday, August 12, 2006

Ruby and Rails

I'm installing the Ruby platform for doing web work, called "Rails". I've already done this on an old CentOS box at home, but I never spent much time working with it... Now that I have Ruby installing on my MacBook (which I spend all my time on) I will soon be playing with it. Ruby sure has garnered a lot of praise from people. It seems to have really developed a cult following. I don't think 'cult' is proper, as it's more like a group who is busily evangelizing their love of Ruby.

The group seems to be a more arty type. By this I mean not so black and white joe programmer. They appear to have lotsa time to be teaching Ruby, which is a good thing. It definitely helps out the language that people are excited about it. There are some real good tutorials too. One in particular is totally original:

Why's (Poignant) guide to ruby

Check this out, believe me it is interesting. I'll post soon on how the Ruby is going.

Friday, August 11, 2006

Stuck on Java?

So I am knee deep in Java. That is the Java programming language. Mostly this would be due to my work with Java dating back to highschool. It was reinforced when in college Java was used in my introductory courses. I ended up being familiar with Java, and therefore using it more and more.

It helps that when I entered college IDE's for languages such as C/C++ cost money while a half-decent Java IDE would be free. This just added to the ease of use, making Java my pick to write most course related code.

(Sidenote: had I been properly trained in Make I probably would have been a C programmer)

Now I feel pressure as I become more involved in the various Java technologies...

Can any one language do everything? Maybe. But do it well? I would say no. I could be wrong, please prove me so :)

So this pressure I feel is probably due to the fact that there may be a better solution to some of my problems. I don't know if Perl, Ruby, Haskell, C/C++, Basic etc. etc. could provide a cleaner, faster and/or more optimized product.

I guess I should start looking into other languages. Being bilingual in the programming sense could likely bring great benefits. Especially in this age of interoperability between languages.

This seems to strikingly resonate through the current world, where globalization, offshoring etc. are crippeling the dominance of any one force.

Friday, July 21, 2006

This is the first post....

I'll cut this short. Maybe this will become a place to post IT/Software engineering information. Maybe not.