Warning: preg_match(): Allocation of JIT memory failed, PCRE JIT will be disabled. This is likely caused by security restrictions. Either grant PHP permission to allocate executable memory, or set pcre.jit=0 in /home/vfehring/codemonkeyssoftware.com/wp-includes/wp-db.php on line 1763

Warning: Cannot modify header information - headers already sent by (output started at /home/vfehring/codemonkeyssoftware.com/wp-includes/wp-db.php:1763) in /home/vfehring/codemonkeyssoftware.com/wp-includes/feed-rss2.php on line 8
Code Monkeys Software http://codemonkeyssoftware.com Just another WordPress site Sat, 24 Oct 2020 03:43:40 +0000 en-US hourly 1 https://wordpress.org/?v=5.5.3 Converting Code v0.0.2 http://codemonkeyssoftware.com/index.php/2020/10/24/converting-code-v0-0-2/ http://codemonkeyssoftware.com/index.php/2020/10/24/converting-code-v0-0-2/#respond Sat, 24 Oct 2020 03:43:39 +0000 http://codemonkeyssoftware.com/?p=22 After slimming down our codebase for our project, we started to realize, that functionality still was not working in some areas. We were able to do a diff on the different versions of files that were the same, and discovered that some had additional functions, that were removed when a newer version was put in place, but these functions were not removed from the core application. This caused the necessity to create additional files, and include lines in the application.

We would see include lines such as:

<!--#include virtual="/v3/functions.asp"-->
<!--#include virtual="/v2/functions.asp"-->
<!--#include virtual="functions.asp"-->

All within the same exact file, but being called for the necessity of various functions. It started to make our heads hurt.

The solution to this conundrum was to create a centrally located functions file in a location like includes/functions.asp where we could then include one file, and as errors were thrown, we could pull the functions from the original 3 functions files, and fill in our new global file.

This allowed us to see what functionality was still being used, and trim off the fat, so to speak about what was not. After roughly 2 days of messing with the functions.asp file, we have a single global include that now has all the required functionality needed to operate the software. This means that we were able to remove the other files, saving a few MB of disk space. And if you are familiar with AWS, Azure, Google Cloud Platform, you know that these MB of disk space mean money.

Another git commit and a few messages related to what we did later, and we have a more streamlined application, that we can continue to add global functionality to in a single location.

http://codemonkeyssoftware.com/index.php/2020/10/24/converting-code-v0-0-2/feed/ 0
Vend-Trak VMS v0.0.1 http://codemonkeyssoftware.com/index.php/2020/10/23/vend-trak-vms-v0-0-1/ http://codemonkeyssoftware.com/index.php/2020/10/23/vend-trak-vms-v0-0-1/#respond Fri, 23 Oct 2020 18:37:35 +0000 http://codemonkeyssoftware.com/?p=20 Below is the complete change log related to the Vend-Trak VMS project.

== v0.0.1 ==
* Initial commit of original project source to repository.

http://codemonkeyssoftware.com/index.php/2020/10/23/vend-trak-vms-v0-0-1/feed/ 0
Converting Code v0.0.1 http://codemonkeyssoftware.com/index.php/2020/10/23/converting-code-v0-0-1/ http://codemonkeyssoftware.com/index.php/2020/10/23/converting-code-v0-0-1/#respond Fri, 23 Oct 2020 18:34:50 +0000 http://codemonkeyssoftware.com/?p=18 When taking on a project, we have to be prepared for the unthinkable. Sometimes, this comes as unrealistic expectations, and other times, it comes as unexpected spaghetti westerns (code bases). They truly are like the wild west, as anything can be happening, and people are just trying to live their best life.

This is what we experienced when we took over the Vend-Trak VMS project. Not only is it written in a language that has minimal support now, but the hosting associated with it is still relatively specialized.

The project codebase is written in ASP Classic, and the source was never kept under version control. This makes for an interesting challenge to maintain. The previous developer wasn’t really a developer at all. Which is surprising, due to the fact that much of the code is well written. The issue is that there are 6 versions of the same exact file in 6 different folders, due to the lack of knowledge in maintaining a codebase.

When we received the .zip file that contained the project source, we just sat and reviewed it for days. This allowed us to become familiar with the how the layout affected the operation of the project. After taking a few days to review and become familiar with the code, we did what we felt was the absolute most important thing to do. We ran a shell command in the folder. One simple command, git init. It wasn’t enough for us to have the .zip file that we could always refer back to. What happens if the computer crashed, or we accidentally deleted the .zip file. This was unacceptable in our shop.

After committing the source to a git repository, we started to make changes. Slowly, committing every change we made, so we had a rollback point. This allowed us to prune the codebase down, and produce a maintainable setup.

We started with the default.asp file, which is the launching point of our application, and slowly changed paths, again, committing after every small change, due to the fragility of the application. Pushing these changes to the server after testing, allowed us to know that we were slowly bringing the code to a smaller footprint, allowing for optimizations at a later date.

That’s where we are right now, maintaining a smaller version. It is just that though, maintenance, we have not really made any structural changes to the code as of yet.

http://codemonkeyssoftware.com/index.php/2020/10/23/converting-code-v0-0-1/feed/ 0