Enterprise Systems Integration Project Launched This Week, Mission: Possible!

We can’t screenshot it, and due to the business-process nature of the project for our client, we can’t really give many technical details, but we want you to know about our latest project.

The project isn’t a website launch or a custom web application, it’s a systems integration that helps a national manufacturing company leverage their existing internal sales and logistics systems in a whole new way.

If you are reading this and don’t know what “systems integration” actually might mean, here’s the short version. Most (all?) mid-to-large manufacturers use an ERP (enterprise resource planning) system to manage the logistics of their sales, manufacturing, and distribution. Most (all?) also use a CRM (customer relationship management) system to manage sales leads, customer accounts, and quotes.  This company uses Microsoft Dynamics AX as their ERP, and Saleforce.com as their CRM. They hired us to make those two systems talk to each other, in real-time, in order to build themselves a more customized system and improve efficiency company-wide.

And, stepping into that place where traditional IT analysts and web developers both usually fear to tread, we did it.

We’re pretty proud of it. The client’s sales team can now use Salesforce to access real-time product information and build accurate and meaningful quotes. Once the quotes are sold, the workflow moves seamlessly over into AX  and the order begins to be filled. Now, if your company sells, makes, and then ships products, can you think about how useful something like this could be? An ERP system can be a poor match for the needs of sales…  side note: one of our team experienced using SAP as a sales rep once, and it was scary … and a CRM usually has nothing to do with the real logistics of manufacturing and delivery. But, different systems tooled to different needs, talking to each other in a harmony – that’s business magic.

On another note, the Reno team enjoyed having Patrick here in the office this past week. We think he appreciated an escape from the snow in Anchorage. We took the opportunity to do a little planning, a mission refresh, some navigation as we round the first turn of 2012. Here’s our shiny new mission statement –  nothing considerable has changed, core values still stand and always will, except we think we know ourselves a bit better than we did back in 2007:

Trinity Applied Internet provides businesses with expert client-centered design, development, systems integration, content management and online business intelligence, exceeding the wildest goals and contributing to the outstanding success of clients and team members alike, with respect and integrity.

Server Technology’s Custom Ruby CMS Gets A Makeover

TAI Launches Another Custom Ruby CMS Website for Server Technology

Time to toot our own horn, again! We are excited to announce we’ve finished another version of Server Technology’s custom-built Ruby on Rails content management system, complete with a sharp and professional front-end redesign. The new website features a Product Selector application designed for sales, a simple but powerful back-end admin area designed for marketing, and a comprehensive products database that stores everything from datasheets to engineering schematics, designed for a global manufacturer on the forefront of their industry. Trinity Applied Internet has been Server Technology’s applications solutions provider going on five years now, and we are proud to say their website’s next generation is built to last for many more.

In other news, we have moved into our new space and have some other interesting changes on the horizon, so stay tuned in the next week or two for more on that!

Investing Time and Experience Before We’ve Even Started

Working with Trinity Applied Internet Part B: Investing Time and Experience Before We’ve Even Started

You know the staff. Now, what is the process? How do we approach your project?

The term “applied” in the name of the company is no accident. A cumulative thirty years experience in software and web development speaks volumes on behalf of the partners, and is directly applied to every project we produce, problem we approach, and product we deliver. The process behind your website or web application development is not piecemeal or made up as we go along.

Consult, research, facilitate, plan (and plan and plan some more), design, develop, test, adjust. Rinse and repeat. Every time, for every project. It doesn’t matter the size or the complexity of the project at hand, we spend the time at the beginning on analysis of your company, research, and planning. In fact, if you have already been through an estimating and proposal process with us, you know we spend a considerable amount of time getting to know you before we’ve ever even won you as a client.

Think every shop that advertises their easy and cheap WordPress package, or their hosted solution you dial right into, does that on your behalf? They don’t. Believe us, because we hear time and again from clients who tried out the competition first because of a really attractive price point, and since have realized they didn’t need a cookie-cutter approach. Or they went with a big media and advertising agency and were shoehorned into marketing decisions based on what the agency was “really good at,” and how it wanted to promote themselves as a full interactive shop.

Well, that strayed from the topic a bit, but the point is, at Trinity Applied Internet you get specialized, considerate, and tailored service that addresses your needs specifically. If you are a marketing department working with some IT constraints, we plan for that. If you are a small organization with one paid staff member and no time for teaching yourself website administration, we plan for that when we design your project, rather than discovering it at the end (or not at all.)

The adage about “prior planning prevents…” at best catastrophe and at worse any number of irritating little hassles. We take it to heart, to the extent that we are researching, discussing, and planning your project before you have even officially engaged us.

Trinity Applied Internet Voted Best Social Application at Hack4Reno

Hack4Reno was a fantastic experience, and we really enjoyed working with several local teams!

Keith Anderson of Trinity Applied Internet Working at the Hackathon

First, a giant thank you to Reno Collective and The City of Reno for putting on this incredible event – we look forward to participating again next year. And, we were blown away by the talent of all the teams, but want to give a special congratulations to our friend Dawson Loudon of Sapphire, who took Best in Show for GoOutsi.de.

We created EventSmash: a mobile-friendly, area-wide events calendar website. Anyone can post an event, but only registered users can vote on these events. Users can sort events by category, including: art, training, music, nightlife, and more. All posted events are geo-located, so users will only see events that are relevant to their location. Fields to be published for each event include event title, description, date, category and place.  Also, the map icons change based on the type of event. Users can sign in through Facebook, Twitter and Google.

Some of the technology behind the app:

• consumes and publishes events via RSS and iCal
• allows developers to integrate EventSmash with their own website or application using a publishing API
• built on Ruby on Rails and hosted on Heroku

Keith and Patrick Anderson at Reno Collective for a Hackathon Mixer

We are honored to have won Best Social Application, and will be fine tuning and updating the app for full use very soon. Check back or keep in touch through our Facebook and  Twitter updates!

Hack4Reno Is Coming!

Calling all developers and designers! We are super excited to be a part of the fun happening in 5 short days.

If you haven’t heard yet, The City of Reno and Reno Collective are organizing the first ever Hack4Reno – a 24-hour ‘hackathon‘ which is a team competition where apps are to be built to benefit the community. Apps can be anything from serious and potentially life changing to something fun and light hearted.

Why are we participating?

We want to help get the community involved in giving back with their mad designer and developer skills to the city (and region) and to promote the openness of platforms and data.

We are not only forming a team (Go Trinity!) but we are also sponsoring the kick off luncheon for participating teams on Saturday at noon, and coffee for participants later in the evening.

Perhaps it is not for the faint of heart: let’s remember that this is October in Reno and the competition is being held outside (out in the open – like the open public data), but it will be 24 hours of having a great time with fellow developers and giving back to the community.

Come root on the Hack4Reno teams this Saturday, October 15th at noon at the Pioneer Center for the kick off and if you are really excited you can join us and stay all night! Or come back on Sunday, October 16th at 2:30pm for the announcement of the winning team!

Engineering Socially: Traffic Spikes and the old new Old Spice Guy

A while back, we did a little promotional project to tie into Old Spice’s online marketing campaign running on YouTube.  It was very spur of the moment, since we launched the project after the Old Spice campaign had already started.  Because of how fast we needed to get something working, and the size of the potential exposure, some of the engineering issues were more prominent for us than they have been in the past.

Engineering Challenges

We knew right away that if we got any pick up at all, we’d be looking at a significant traffic spike.  While we were hoping for the best in regards to traffic, that also meant preparing for the worst – a huge traffic spike.  The big engineering challenges were:

1. The promotional page must not impact regular operation of the other websites we manage for our clients
2. It must not negatively impact bandwidth allocation from our hosting partner Slicehost.  And by negatively impact, I mean cost us money.
3. The hosting must be able to scale easily, so we weren’t looking at a lot of server errors, or being offline completely.
4. Ideally, the hosting for this should cost as little as possible, since it was pretty much a one shot deal.
5. We knew the campaign was already going on, so we needed to get it up and running fast.
6. The application had to handle several large data sets, namely: Twitter feeds and Facebook, Digg, YouTube and Reddit comments.

Clearly, we weren’t going to be hosting it on our own servers.  Too much risk of a slowdown causing denial of service for our customers.  The sites we host generally don’t get the level of traffic that warrants the engineering investment in load balancers, content delivery networks, redundant servers, etc.  And setting all that up for a spur of the moment deal like this just wasn’t worth the investment of time.  We also didn’t want to afford the cost of setting up at least one, but possibly several, new virtual servers, since we would be paying the full monthly cost.

While there are many virtual application platforms out there, such as PHP Fog, Heroku, and Google App Engine just to name a few, the short timeline and my previous experience with Heroku made it an obvious choice. Since we had no idea when Old Spice would declare a winner and end the campaign, we set ourselves the goal of having something up and running the same night.

Because of its close integration with rake and git, Heroku seemed like the best choice to host the application.  Heroku makes it easy to create, deploy and scale rails apps, and has lots of seamless automation to make maintaining them easy.  A bonus for us is that they only charge you for the time you actually use.  So we could scale up our processes (to serve the app) during the initial rush, and then scale down again when it was over.

Also, Heroku is a Rails 3 hosting service and Ruby made the app a breeze to build (satisfying the time constraint).  I went from idea to working site in an evening. I built the app as a single page, which updates the data on a fixed interval.  While I could have used Heroku worker processes to remove  the refresh process from the page display code path entirely, that would have added to the final bill, so I stuck with refreshing the data during page load and causing an occasional slow request.

Implementation Challenges

While it would be nice to say everything went smoothly, despite all this planning, there were occasionally problems, but surprisingly all of them were from our outside data sources.  We used Google Fusion Tables as mass storage for the collected tweets, comments and feedback that we were mining for “votes.”  I discovered the hard way that very occasionally the comma separated values (CSV) formatted output from the Google Tables API was not quite as CSV standard as Ruby would have liked it to be.  Comments from Twitter with newlines in them were occasionally showing up without being enclosed in double quotes.  In fairness, this might have been a garbage-in-garbage-out issue from the software that was scanning Twitter, but the time we had the problem, it was much too late to fix the Twitter side of things, as the data was already somewhere amongst the tens of thousands of records in the raw Twitter feed table.

Fortunately, we could exclude records from our API calls to Google, but we needed a unique record id to do it.  Unfortunately, Ruby’s CSV parser was somewhat unhelpful about exactly which record was causing the problem.  And the web front end to Google Fusion tables doesn’t have a way to jump to a specific record easily in any case.  Paging through a table with tens of thousands of records a hundred at a time is no way to do things.  And of course, rather than returning nothing, or the data up until that point, or trying to recover, the Ruby CSV parser just throws up its metaphorical hands and raises an exception when the CSV data isn’t up to its standards.  So it was a perfect storm of mediocrity.  While the argument can be made that that’s exactly what the Ruby CSV parser should have done, having it return nothing meant that suddenly our numbers were all over the place.  I did eventually track down the offending data and hide it from the Ruby CSV parser, but it would have been much more helpful to have a parser that could at least try to continue in the face of corrupt data.  I think the robustness principle applies here.

Lessons Learned

We learned several lessons from this exercise:

1. Plan to be inundated with traffic.  We got more than 25 thousand unique requests the first day.
2. Make sure you have a backup plan when relying on remote data.  You never know when or why problems might crop up.
3. Secure a domain name or other stable URL sooner rather than later.  After all that work, we almost blew it by announcing too soon, before we could be sure our domain name was working.
4. If you think you might need to scale, plan ahead.  It’s much easier to take advantage of someone else’s infrastructure which was designed for scalability than to roll your own or try to shoehorn it in after the fact.

But all in all, we learned a lot from this about how to handle high profile events.  We also had a lot of fun doing it.  And hey, a shout out from the Old Spice Guy is pretty cool too.