Poignant Talks

An alpha is like a skeleton, its brittle and easy to break, frames the core of an object without looking pretty, and it needs support to stand on its own. That being said, everything is built on top of an alpha version. Each new feature, bug fix, or style/UX changes are meaningless without applying them to a working project. Now, going back ~10 months to when I began coding AgBiz Logic’s website with a team, we were obviously handed a working site to base our changes on. However, now that we have created an alpha version of our own changes I can see the difference between referencing an existing codebase and working off of a functional version of your own code.

I am happy that we have gotten to this point. Over the course of the term our team has shared our changes and worked together to review each others code. However, I wish we could have gotten to the alpha stage even sooner, as communication about the code, bug fixes, and aspects which need additional testing are so much clearer and direct when the basic components are laid out everyone to see.

That being said, I think team communication and our familiarity with the codebase/languages has gotten better over the course of the last two terms. In the future, I would focus on building up my team with smaller exercises than putting all our code together as an “early alpha” version. For instance, a few weeks ago we held a code review where I flipped through each of our changes and inquired about how they work, what changes where made recently, and restated the reasons we decided to make those changes. It may seem like a small step forward, but it opened up communication and allowed each team member to come forward with their own ideas.

Creating a positive environment for ideas prevents people from getting bogged down thinking about the same issue over and over. Outside input, or simply hearing the problem out loud, can have an amazing effect on motivation. By recontextualizing the issue people are able to find additional reasons to work on the problem, sometimes this will even inspire novel solutions for the problem.

Post alpha development may demand a different mindset, but I am excited to work with my team going into testing and finalization. We have been making good progress and I like what AgBiz Logic does. Adding mapping and geospatial data to the site has been rewording. In this way I am happy to start testing as I want to make the site, or the section which we are working on, the best that it can be.

Working on an Angularjs project is new to me. My project uses Django, a Python web framework and Angularjs, which if you hadn’t guessed it is a Javascript framework. For my part in the project I rarely work with Django, but I’ve definitely been working with Angular.

For the most part Angular allows anything you want to be coded into Javascript and appear in HTML. The project that I am working on already has Angular fully setup for multiple pages and different controllers which govern the Javascript for those pages. The state of the controller is supposed to take precedence from the any other state, for instance other controllers. I have to create and implement a modal (popup page on top of the current page) and since modals have their own controllers I cannot use any of the variables from the previous controller (the controller for the page) directly, I have to send them to the modal’s controller first. However, there are differences with using state variables from a modal verses from a normal page. The HTML document is only loosely associated with the modal even though it should be completely controlled by the controller.

Angular is great, but for bugs like this I had to use a workaround. Since some angular directives (HTML attributes which access Javascript) didn’t work with the modal I decided to use one that did. The only downside–which could be beneficial in the long run–is that the directive injects an entire block of HTML into the document instead of changing a simple src attribute. This does allow for any and all attributes of the HTML block to be controlled by Javascript. However, I still consider it a workaround as this method will almost surely slow down the rendering speed.

Currently I am focusing on the practical elements of the code, leaving the aesthetic and edge-case problems for the next sprint. So far, I have enjoyed working with Angular and the small amount of Django which I’ve coded. It is fun working on an establish project. I hope you will understand that some of my descriptions are very indirect, and the reason there are no images is because I am under an NDA. This is still an honest description of my work, but until everything is set in stone I would rather not leak anything on accident.

This week marked the beginning of implementing real code for our project. Each of my teammates created an early version of their functional area. We all created slides for the v0.0.2 presentation where our scrub master would show off all the developments. Turns out I was the scrub master.

I enjoy organizing projects, and was ready to tackle this, our second presentation. The scrub master has more work than the other team members, they have to actually put the presentation together and record and submit a video of their presentation. I was our team’s second scrum master, and I am a little glad I wasn’t the first. All and all it ended well, but I did run into some issues.

Development on an existing code base is a great and exciting opportunity. However, problems may arise. I found out that even though I could run the code locally I wasn’t able to access all of the features/pages of the AgBiz Logic website. This was quite problematic as one such page is where our whole project takes place. I have not quite fixed the error and so cannot load half the pages on the site locally. I decided to develop my functional area externally then port it over later as we are still early in development.

I included my problems loading pages locally in the presentation. After creating my external implementation all that was left was the slides/recording. Editing the slides took awhile but I am happy with the result. Recording was a different story.

I was running out of time to record the video, however I had an issue which was impairing my speech. I had a canker sore which was lasting over a week. For whatever reason I get canker sores more than the average person, and they can get pretty painful if they last a long time. I was not looking forward to recording the presentation.

I still wanted to go through with the recording even though it was painful at times. I was appointed by the team to handle the presentation and I didn’t want to offload that on to someone else last minute. It wasn’t as bad as I thought it would be. The video is definitely longer and it took more takes to record than it normally would, but I came out the other end completely fine. I guess it goes to show that growing pains are there to be “grown past.”

Hello all, it has been a little while. My time has been taken up by communicating with my team. This term we have a team member that is not from the Ecampus, and so I’ve been trying to communicate as much as possible. That continued as I hit road blocks.

When we started meeting with our project partner the main focus was on setting up our environments because we were accessing an existing code base. We’ve all signed NDAs so I can’t go into details, but suffice it to say I did not think it would be a 4 week project simply to get the code working…

We started by trying to setup the initial requirements and setup using Window[probably all 10]. However, the first member to get a “working directory” used a fedora linux VM(virtual machine). I wanted to continue using Windows as I could help other team members if I figured out my own setup. This started me down a long and narrow path, one full of past setup mistakes/strange bugs.

Python has different versions it turns out. Yeah, the first problem I ran into was that I was using the wrong version. What version was that? Well, I had 2 versions installed, and I used to have 3. Then I decided that I might as well just install the one our project partner was using…So I ended up having 3 again. All of them were python 3+. For those who don’t know, you can switch between python 2 and python 3 pretty easily. But switching between different versions of python 3+ is a different story. I ended up uninstalling every version, then installing one that our project partner said should work. However, a ghost of python 3.11 still haunted me.

I setup dummy code which worked the same as the initial setup bash file I was given. This told me that I had no modules installed even though I just ran pip. Nothing installed, and yet commands showed that they existed. What is more, I could run the same code inside command line and it worked, I just couldn’t get it working from a bash file. What was going on? Turns out, python 3.11 was still installed on Ubuntu; my VM that I use for WSL(windows VM for Linux). After uninstalling it from Ubuntu I could no longer run any python code through bash files. I ended up with a very simple fix that took far to long to figure out. I started using git bash instead of the basic command line that windows comes with. I know I should always use something like powershell, the Ubuntu VM would’ve probably worked better too.

That was the main problem, the haunting! But I still had a few hurdles before the code was up and running. I needed headers, and from libraries. I had tried to install them through command line, and the setup requirements includes these required libraries. Although, I don’t think they include the headers, and those are necessary. I might’ve been the first team member to figure out how to install the headers. I installed source files. But one of them ended up being too new for the code to run. The other was unable to add to the Path environment variable because it was “too long” already. So, to fix the first problem I tracked down the archived versions and snagged one. To fix the next, I had to add the bin folder manually to the Path. To fix both–and yes they both had an additional problem–I added a environment variable which was named [Name of library]_Dir, this solution was spit out in the terminal when I ran the setup bash.

That was it, a GitHub pull to a working setup environment. I now see why people use VMs for projects; the software versions, not to mention the dependencies are isolated. I hope you all have good luck on your next pull request, perhaps you’ll run into one of these issues and think, “well, it had to happen as least once,” that’s how I thought of it. After all, a learning experience is always welcome.