Technology Speeds the Pistachio Harvest

"From mid-August to mid-October every year, Paramount Farms of California's San Joaquin Valley processes roughly 11,000 loads of the year's pistachio harvest. For optimum quality, the nuts have to get from the tree to the huller as quickly as possible, without ever touching the ground. Since 2002, Paramount has been removing bottlenecks from the harvest process using a variety of computer technologies—RFID tags, bar code readers, Pocket PCs, networking, Web services, databases, and programmable logic controllers (PLCs)—tied together with software written using the Microsoft.NET Framework. Paramount has not only improved the speed of the harvest, it has also improved its accuracy at every step, reduced unnecessary data entry, and provided better visibility to management and growers alike."

Technology Speeds the Pistachio Harvest

Adopting a new Framework

When I was younger, like in my teens, I would freely spend time trying out different programming languages, frameworks, libraries, etc with much ease. I loved dabbling with different solutions to problems. Some choices would stay with me, like Object Pascal, others would not, Borland Graphics Interface. At any rate I basically had a lot of freedom to move between choices.

I carried that habit into my career as a software developer. After some time I finally realized that I can't freely work with choices when I'm part of a team. Some developers are open to new things others would rather use what they know. I can understand it either way.

Recently I needed to prototype a web interface that did basic CRUD to a set of tables. In mind to use C# for delivery I choose to prototype with Ruby on Rails. In one afternoon I was able to build the prototype (which involved 6 tables and a couple of relationships) including picking up some basic Ruby. I felt the most productive than any other language or framework! And the end result code was highly readable and maintainable.

But my team works with ASP.NET not Rails and I don't feel secure enough to push Rails. I will probably end up falling back on ASP.NET after the prototype is selected but it sure means extra work.

So lately I've been thinking about when should you push a new environment. I don't have a formula for the answer but I do have a list of things to think about:

• What will your current or future team think about it? Are they open to new environments? What about management?
• Does the new environment mesh well with any existing technology? Are you pushing a linux server in an active directory shop?
• What kind of support does the new environment have when you get stuck? Newsgroups, books, articles, blogs all help when you're learning or when you get stuck.
• Will the new environment be around long enough for your applications? Check out the community, see if there's strong push behind it.
  
• Will the new environment have pro's that out weigh the con's of your current environment? Classic ASP to Ruby on Rails does but would Classic ASP to PHP have the same leap?
• Does the new environment cover your project's needs? Does the environment support the database server natively? Do you need to render PDFs? Do you really want to generate reports by hand using HTML and script or would a report package make more sense?
• Is the technology solid? Check out the dependencies? Does it carry over a lot of legacy components?
• What is the risk factor? What would happen if your team gets 1/2 way through and decides that the new environment is not suitable?
  

In a current venture to upgrade an Access project to a multitier platform I selected MySql as the database server of choice because I was able to answer a plus for each of those questions. I felt really secure in pushing that choice. So far the team is really happy and we all seem to be on the same page.

I'll see where my Rails prototypes goes in the mean time =)

SQL On Steroids

At our plant we have machines that are controlled by Programmable Logic Controllers (PLC's). They are basically computers that can be programmed to control switches and pumps and can also read sensors such as thermalcouplers.

The PLCs are capable of generating LOTS of data and quite frequently we need to capture that data. To do that we're using a product from Wonderware called InSql. The product is capable of recording several thousand values per millisecond and give the programmer the ability to view a snapshot through MS SQL Server.

I've been spending the last few days studying the internals of the product. It's actually built along side of MSSQL Server. It stores it's configuration in a SQL database and exposes its data using OLEDB. InSql uses its own data format outside of SQL Server to achieve its high performance.

InSql also has the unique ability to interpolate values which is really nice when building portals for operations. InSql can be setup to poll on a certain interval yet be queried on a different interval.

I actually think out of all of Microsoft's products SQL server in my opinion is the best built. It's just rock solid and it was a good call from Wonderware to build along side it with InSql.