Alan and Steve were working on some tweaks for ecommerce. They have some new code that helps generate tiered pricing code and they were debugging some of the pieces. Around 10 am, Wayne popped in and was giving us some information and an update about the servers and what things he was looking at as far as thresholds and matrix. He is really helping things out and is able to watch things and really get things more and more standardized and monitored. That will be a huge help. I'm really excited about that.

Eric joined and had a number of questions. For example: How do we flag the transactions to know what type they are? (manual, double tuesday, normal, auto, redeem, etc.) What about tracking rules and history changes for the rules? What about changing things (rules) right in the middle of the day and/or middle of the transaction? Eric is thinking we may need a way to change things and then publish and/or commit changes in bulk. That would allow small tweaks to happen and then fully wait for all other changes before really committing things (stages). We talked about a few of these things and decided that we will use 3rd party error logs to track rules and changes. We also decided that we would not do the publish and/or commit changes in bulk. For now, all changes will be live as they happen, one by one.

Alan and I were on the meeting and went over a number of projects that are currently in the works. We went over some needs on the sales tax project. We decided to do one more major push on that project and then push up the code and get things going. We have been close on this one for awhile, but it keeps getting hung up with the moving black box (custom code) target.

Alan reported on his permission and user project. This is a project that breaks users and permissions into a more object oriented model with services, logic, and database access objects (DAO's). Basically, our existing code base checks a three-way connection of user to permission to corporation on every page in the entire system. A lot of that data doesn't change very often. So, in the background, we are spending time and resources checking relationships that are fairly stable. Some pages have between 10 and 20 permission checks. That is 10-20 trips to the database for data that doesn't change that often. So, we are starting to cache (temporarily store) the data in the session scope. If nothing changes, we'll start using session or memory checks vs full database checks. If anything does change, we reflush the session cache and then go from there. This reduces the number of database trips by tons, if you take each page, used by x number of users per day, all with active database checks and queries. Great savings on time, resources, and processing.

We also went over a couple of other projects such as a round 4 for sub inventory and ways we could speed up some of the manual processes for reoccurring invoices, reoccurring merchant processing payments (credit card stuff), and tying things together in a better flow environment. Good meeting and lots of good progress on multiple fronts.