I’ve been working behind the scenes to prepare for a major update to LambTracker that will introduce many new features.
The biggest changes include full tracking of feeds, ownership and locations.
As a result of these changes the first step has been to add a number of new tables in the database structure. Designing that structure and getting it working has taken far longer than I expected.
Unfortunately, the additions and changes will effectively break all existing LambTracker code.
I am making a new development branch that will use the new database structure. I have started documenting what I need to do and have over 200 individual areas identified that need updates or changes to work with the new structure. To see the new structure in the code you can check out the blank lambtracker db file that is in the assets section. Once code changes are made I can merge things back into the main develop branch.
Of course complicating this all is that we are just weeks away from shearing and vaccinating which will be followed by lambing. I need LambTracker to be working to collect data and document all these procedures but it is unlikely that I can get all the code changes made before we start.
I have updated the blank spreadsheet files that are used to fill the new database structure when you first star using LambTracker and need to add in the historical data. That repository is now up to date.
It’s been a long time since I posted. For the last couple of years we’ve been using LambTracker for all of our sheep tracking and data gathering. Lots of things need improvement and my list of enhancements I want to implement is getting longer every time we use it but overall it works well. Other projects took priority so nothing much was done on LambTracker to change the basic functions. I developed some workflow workarounds to cover the major bugs that impacted us and the enhancements, while nice, were not critical.
Well that has changed now.
First major change is that I’ve moved the development system off of GitHub to GitLab. With Microsoft buying GitHub I could not stay there. So all new work is on my GitLab account.
The latest big feature addition is that we now have a bluetooth scale and can send weight data directly to LambTracker. It’s still in work, today is the first time the new code will encounter the sheep as part of the yearly evaluations but it worked well during routhine sheep management tasks.
Got a few minor bug fixes done. Corrected calculation of the age of the sheep when putting in a carcass weight. The sequence is you must first remove the sheep and then do the evaluation with carcass as the only item being evaluated.
Working to get the test database populated with sheep.
Annual flock inspection went well. Discussed a bunch of potential user interface and use case options with our veterinarian. I still did all the queries to produce the reports by hand but developed some new query code that provides more of the information in a better format. Trying to decide on a system for using GitHub to store/update Query code so haven’t pushed any of the new queries up yet. I don’t want todo all individual files but that is easier to update on GitHub. DEVONThink is easier for me to use while I am developing and testing code but almost impossible to put on GitHub. Scrivener seems like a decent compromise but is more difficult both to use in development and to update GitHub. So still looking for a better option before I spend too much time on implementation.
We used LambTracker during shearing to print labels for both wool samples and fleeces I saved for sale. Found a few bugs and worked on them. Now trying to clean up stuff for the Federal Scrapie Flock Inspection.
All lambing is done now. I’ve got a lot of work to do to finish my Masters Degree so LambTracker is going to take a back seat until early 2016.
We are nearing the end of lambing season, we only have 6 more ewes to lamb, and this year we uncovered a few more lambing bugs. Most have been fairly minor, things like forgetting to update the sheep record for new lambs with some of the new fields for management group and location. Others are on hold until lambing is done since it’s working fairly well as is and I don’t want to break anything until I don’t need it for real data.
I am also entering in historical lambing data and have developed a workflow to get the information in. I am going back to my original paper lambing books and crossreferencing with my calendar and my original spreadsheep records. I have the database up on another computer looking at all the sheep sorted by dam and then by birth date. I have a spreadsheet I created to insert lambing history records and I have a copy of the database that I am working on on a second computer.
The procedure is I look up a lambing record in the paper book, start creating the insert record in the update spreadsheet. Look to find the sheep_id for the dam then use that to look at the other copy of the database to find all her lambs. Verify that the number of lambs in the database matches the paper record. Add the lamb numbers to the lambing_history_table record. Go to my calendar and pull any notes about that lambing and add those. Go into the sheep_table and add the reference to the soon to be adde4d lambing_history record to each lamb’s sheep record. When I have a batch of maybe 10 or so done, I save the update spreadsheet as a .CSV file and then run the CSV to SQL converter to create insert statement. Copy and paste the code into the database and execute it. Then I save a copy of the database as a backup. I continue tis until all lambing records are entered for the year. Then I go to my population history records and figure out all the ewes who failed to lamb in that year and enter in a record with them listed as barren for that year. This step is necessary to allow for more accurate reporting of percentages of lambs born and weaned each year.
My final verification step takes place after I have entered in an entire year from the paper and calendar records. I pull up all my old spreadsheet records on the entire flock and look at the lambing notes for that year and make sure I have the right lambs and the right data in the lambing_history record. I do this final step at least a day after I have finished the original data entry. This is my final chance to catch any data entry errors.
So far I’ve managed to enter in 10 years worth of lambing records and only have 7 more years to go. It’s slow and tedious but necessary.
Making some changes to the database structure based on feedback from other rare breed breeders. I’ve moved the registration info out to a separate set of tables to account for sheep that may be registered with more than 2 registries. I have found some breeds with 3 or more different registrations, example US BWMS, UK BWMS and Natural Colored, so needed to allow for more than 2 different registration numbers per sheep. I’ve also started to add the tables and placeholders necessary to handle semen collections and dealing with lambs sired by rams that have died. Also embryo collection or eggs and handling lambs with a genetic mother who is different from the rearing mother for embryo transfer. That part is still a work in progress but I’m making headway.
Squashed a few more lambing bugs. Just in time. We are within the gestation period now and expect lambs any day now.
After a bit of a hiatus while we did normal things like moving breeding rams in and out of pens, all handled by making any required changes to the database by hand I am back at updating LambTracker.
Current top priority task, integrate the pull requests from other developers and update the demo and blank database structures to be the current design.
As we’ve added new modules I’ve added to the database tables but I haven’t gone back to update the demo and blank versions of the database.
I put the Scrivener novel I am using to document LambTracker up on GitHub as a separate repository. It seems to be working well for tracking changes I make.