FA+
Shop
The big update...
14 years ago
Some journals are personal, and some journals are business related for Kinzart. For everything else, I don't care.
As many of you already know, the vendor system of Kinzart is well over two years old. She's been kicking orders left and right and has yet to show any signs of slowing down. However, like all good things, there eventually has to be a sequel.
From the customer's standpoint, there is little to understand why we need this update. From the standpoint of someone using the system, the reason for the update is very apparent. To help explain this, let me tell you a story.
Upon transfer to the main grid, I had not a lot of funding to work with. Sylver has yet to transfer (yes, I am older than Syl) and as a scripter, I wasn't sure where to go. I eventually landed a job at ITFE (In the Fur Enterprise) in developing their new vendor system. I thought it through carefully and made a rather effective system that could dynamically expand itself and update as well. For what I made more than 2 years ago, it was very impressive.
Skip up a few months and Sylver finally transfers. She requested I make a newer vendor system for her to use that would allow her to keep track of all purchases, at the same time, Ayeaka asked for a similar system, but instead only had to worry about deliveries. On top of those two requests, Psistorm became interested in a system that would be much like Sylver's but could also update and insert older customers not in the current system. This was quite a situation.
After reviewing my notes, I came to realize the way I made the vendor system for ITFE was near flawless, but had much room for improvement. After messing a bit with the internal protocols, I soon had a system that was completely modular and could be modified to act differently by adjusting what plugins were in the system in the first place!Thanks to this design, I was able to make all 3 vendor systems, even though they had the same internal core.
The system's popularity began to spread and soon many other companies adopted the system, being able to take advantage of how it could be modified to do more than originally designed! Bugs showed up and were quickly resolved, and all was good.
Now the system made over two years ago is only now showing its age. From my eyes, I can see so many wrongs I had done in it that I only now know how to properly do. I've taken my studies very seriously and because of that, it became time to give dawn to an upgraded system of the original designed to keep the business going.
This, ladies and gentlemen and hermaphrodites, is Naverous v2.
Unlike the sorry folks who upgraded from Windows 98 to ME, the upgrade to v2 retains many of its original features of v1 and adds to it. The first is a nifty feature on the web paneling system that enables users to see the newer system in the same layout as version 1. This means that should a user be unsure on where a certain item is, they can make use of the classic layout mode to help get the job done. This means that a customer does not need to be delayed on any request that requires customer support due to a UI Layout change.
Another feature is the major revisions done to pre-existing web controls. Finding a customer in version 1 meant sorting through all purchases done by customers with similar names, which can sometimes mean sorting through 50, sometimes 100 results. Version 2 only searches for the customer him/her/hirself, meaning that purchases can only be viewed upon entering the customer's profile page, a new additional to version 2 that allows support to see more helpful information about a customer and actions to assist in a number of problems.
A major feature is a new database layout. Before in version 1, all purchases and customer names were a single table. This means that the only way to address a customer is if they are in this table. If a customer was 'deleted' out of this table, the customer is also removed from the database completely! In version 2, all data is separated and now relates to each-other. This not only is more effective in preventing confusion, it also speeds the system up greatly. This is ultimately the key in how version 2 and version one are different.
The last feature I'll mention for now, but is not limited to this last one and the ones already listed, is better resending. Since the customer table is separate from the purchases table, the system can better pull up what items that customer as an individual has purchased, meaning the customer can now cycle through their purchases and choose which one to resend. If a customer is unsure and would like to simply resend all purchases, this option is still available.
From a customer's standpoint, the systems will operate nearly the same. From the aspect of what support we can provide, there will be a greater difference in how fast we can operate at and accurately as well, two pieces of criteria I do not take lightly and hope to improve only more as development continues.
-Flame
EDIT: Helpful Picture: http://www.furaffinity.net/view/6281369/
From the customer's standpoint, there is little to understand why we need this update. From the standpoint of someone using the system, the reason for the update is very apparent. To help explain this, let me tell you a story.
Upon transfer to the main grid, I had not a lot of funding to work with. Sylver has yet to transfer (yes, I am older than Syl) and as a scripter, I wasn't sure where to go. I eventually landed a job at ITFE (In the Fur Enterprise) in developing their new vendor system. I thought it through carefully and made a rather effective system that could dynamically expand itself and update as well. For what I made more than 2 years ago, it was very impressive.
Skip up a few months and Sylver finally transfers. She requested I make a newer vendor system for her to use that would allow her to keep track of all purchases, at the same time, Ayeaka asked for a similar system, but instead only had to worry about deliveries. On top of those two requests, Psistorm became interested in a system that would be much like Sylver's but could also update and insert older customers not in the current system. This was quite a situation.
After reviewing my notes, I came to realize the way I made the vendor system for ITFE was near flawless, but had much room for improvement. After messing a bit with the internal protocols, I soon had a system that was completely modular and could be modified to act differently by adjusting what plugins were in the system in the first place!Thanks to this design, I was able to make all 3 vendor systems, even though they had the same internal core.
The system's popularity began to spread and soon many other companies adopted the system, being able to take advantage of how it could be modified to do more than originally designed! Bugs showed up and were quickly resolved, and all was good.
Now the system made over two years ago is only now showing its age. From my eyes, I can see so many wrongs I had done in it that I only now know how to properly do. I've taken my studies very seriously and because of that, it became time to give dawn to an upgraded system of the original designed to keep the business going.
This, ladies and gentlemen and hermaphrodites, is Naverous v2.
Unlike the sorry folks who upgraded from Windows 98 to ME, the upgrade to v2 retains many of its original features of v1 and adds to it. The first is a nifty feature on the web paneling system that enables users to see the newer system in the same layout as version 1. This means that should a user be unsure on where a certain item is, they can make use of the classic layout mode to help get the job done. This means that a customer does not need to be delayed on any request that requires customer support due to a UI Layout change.
Another feature is the major revisions done to pre-existing web controls. Finding a customer in version 1 meant sorting through all purchases done by customers with similar names, which can sometimes mean sorting through 50, sometimes 100 results. Version 2 only searches for the customer him/her/hirself, meaning that purchases can only be viewed upon entering the customer's profile page, a new additional to version 2 that allows support to see more helpful information about a customer and actions to assist in a number of problems.
A major feature is a new database layout. Before in version 1, all purchases and customer names were a single table. This means that the only way to address a customer is if they are in this table. If a customer was 'deleted' out of this table, the customer is also removed from the database completely! In version 2, all data is separated and now relates to each-other. This not only is more effective in preventing confusion, it also speeds the system up greatly. This is ultimately the key in how version 2 and version one are different.
The last feature I'll mention for now, but is not limited to this last one and the ones already listed, is better resending. Since the customer table is separate from the purchases table, the system can better pull up what items that customer as an individual has purchased, meaning the customer can now cycle through their purchases and choose which one to resend. If a customer is unsure and would like to simply resend all purchases, this option is still available.
From a customer's standpoint, the systems will operate nearly the same. From the aspect of what support we can provide, there will be a greater difference in how fast we can operate at and accurately as well, two pieces of criteria I do not take lightly and hope to improve only more as development continues.
-Flame
EDIT: Helpful Picture: http://www.furaffinity.net/view/6281369/
sounds quiet a lot like the administration interface I wrote up for myself in ruby on rials.
But I admit I don't have nice vendors ^^' they are not modular, nor do they use a central delivery system .. quiet hard to maintain them if products change or update ... then on the other hand my web based interface is way better.
Similar to your system I use separated tables for products, customers, locations and sales. Allowing for some nice statistics and balancing features, as well as a name based search for customers. Just collecting current data is a bit of a hassle. I implemented a mail parser which parses my Marketplace mails and adds these sales also to my database. Even if the parsing fails, the partial results are stored for a manual review. It works quiet well currently but I fear it won't scale up ^^
Also I am kind of sick of LSL after I finished my recent HUD >_> ... so I don't have much motivation to review or redo my vendor code....the language is just an ugly child compared to real languages like Java, JavaScript, ruby .. or PHP well ANY other language
I do have to admit that LSL is slowly showing its age. It's mostly in relation to older functions that are only just getting a face lift, but still holding the same problems as before. Introducing a modular vendor system into Second Life is pretty annoying, but is pretty fun at the same time.
I've heard a bit about ruby... I'll have to look into it. I coded mine in PHP only because it was what I was requested to make it in. Several years later, still using it.
-Flame