week of 25 march

25 Mar 2019

25 mar

server/apache log fun

On Friday, Jennifer hooked me up with some info about our apache logs so I can see PHP errors in realtime. Imma drop that info here for future reference:

Haley fixed her code this morning, so the hours API is back up and functioning and I can continue with my angular directives/controllers/testing journey. Yay! :tada:

building a test angular app

I went over the AngularJS fundamentals in 60 minutes video again today, but this time I actually followed along with the coding. Through this process I found out why my previous angular app wasn’t working! There are some difference in the very early version of angular we use… surprise! This time, the app actually runs and has some dynamic behavior.

After that, I decided to dive back into the hours app code. I kept getting my wires crossed, so I ended up taking notes/mind mapping the code. This was insanely helpful, so I’ll need to remember that for the future. I’m hoping all these apps are structured in more-or-less the same method, so maybe after I figure this one out, the rest of them will be “easy.”

I realized today that our apps all use class-based directives. :flushed: After I’ve finished writing tests, one of my first refactors will be changing these class-restricted directives to attribute-restricted directives.

Also came across John Papa’s Angular style guide which will prove to be very helpful in the coming weeks.

26 mar

Read a great article today (via twitter, of course): Innovate this! Bullshit in academic libraries and what we can do about it

Worked on review material via digital measures for quite some time this morning, as well.

I’ve been trying to figure out how exactly the app code ends up in the dev repo. For example, the hours app is its own repo: hours_ui. This app also technically lives in the roots-ualib repo, but it doesn’t end up in the compiled build. So… where is that all happening? And how does it end up live?

I learned pretty early on that all the stuff in the vendor folder (which, coincidentally, is the folder that doesn’t end up in the compiled build) is all compiled into the scripts_bower.js file. As I was messing with the hours app as it exists in roots, I noticed the grunt build isn’t affected by any changes made in that folder. Which led me to believe there must be some kind of connection between the hours_ui repo and the roots repo. The hours_ui repo has its own grunt build and development workflow… is the compile for the hours_ui build somehow connected to the roots repo through a github hook or something? Guess I’m going to have to make a small change and see how grunt live-build in hours_ui changes things or doesn’t. :woman_shrugging:

Hokay, so. hours_ui is listed as a bower dependency, so it ends up getting pulled in/compiled during the grunt build (I tested: it does it for both default and live tasks). Any template/js changes in those apps end up in /assets/js/scripts_bower.js. List of our apps in the bower dependencies list:

Today was an object lesson in the complexity of this codebase. Every time I think I finally have a grasp on it, there’s yet another layer. I hope this is one of the last things that doesn’t make sense, but that’s probably wishful thinking, right?

27 mar

Testing! I’m trying to figure out where to start with writing tests for the hours app. Looking through the angular docs, it looks like they recommend:

I think I’ll start by cloning the angular-seed project and getting it set up to see how all the things run.

Also: since all these apps already use grunt/bower, I need to do some digging on how to add automatic testing to the Gruntfile.

Get ready to break some stuff! :sweat_smile:

Steps I followed to install testing stuff:

karma

jasmine

I think that’s all that I need to do for installing/configuring Jasmine, but I won’t really know until I write a test!

Ran a test, but had some karma settings messed up. I needed to add some angular files to the files list:

testing

Successfully passing hello world sanity test! :raised_hands:

I’m sure as I add more things to test, I’ll need to include most if not all of the bower components.

I also added ngMocks via npm i --save-dev angular-mocks@1.2.18 which is the oldest version that exists in npm. Then added it to the karma conf under files: 'node_modules/angular-mocks/angular-mocks.js'

Started with writing a “simple” test for one directive and immediately ran into errors. After much googling and many trials, it turns out versions of angular and angular-mocks have to match. :roll_eyes: For future reference: our angular version in bower is "angular": ">=1 <1.3.0" which means we have to use version 1.2.32 of angular-mocks. Now you know. For some reason, I’ve been under the assumption that we were on version 1.2.7 of angular, but I just checked the source code (which I should’ve done day one), and we’re on 1.2.32. So that shit adds up. :expressionless:

28 mar

New day, new opportunity for failing tests. :thumbsup:

Early success this morning! Got my grunt watch tasks working so the karma ui doesn’t freak out when I change a test. :tada: Spoke too soon on that one, but I did get it figured out. I didn’t correct it to my exacting standards, but it’s working for now. The problem: I want Karma to run the tests in the chrome browser it opens when I first run grunt and then keep that browser open and refresh when new tests are added. The problem with the continuous version of karma via grunt is it blocks the rest of the watch task, which is not helpful. I think I have it working now, but it still occasionally gives me a weird error about grunt run not working… but then it continues working? It’s still telling me how many tests are failing/passing? Who knows. Maybe I’ll figure it out as I go along. For now, I’m using the configuration as laid out in the grunt-karma docs, so at least it’s working.

Did some more digging (I can’t help myself…) and found I didn’t have karma-cli installed either as dev dependency or globally. I installed globally and no more error. :woman_facepalming: Not sure if it needs to be added to the dev dependency? This is one of those things where I feel like I could mess with it for the next week and it still wouldn’t be set up correctly. There’s too much I don’t know about all of this: I’m new to angular, I’ve never used karma or jasmine, I haven’t used grunt in five years, and there’s a whole codebase/gruntfile here I know nothing about. So. I’m going to stop messing with the config unless I get an error that is causing dev problems.

All that said– I know I just got all of this set up with Jasmine, but I really don’t like the feedback in the console. I really appreciate the straightforward error messaging in mocha/chai… if I can’t figure out how to work with jasmine, I’m going to have to swap it all out for mocha/chai. :grimacing:

testing

I’ve been trying to test a very simple directive. It’s hard to cobble together different tutorials into the correct syntax for a test you’re not even sure works. I’ve been trying to follow Angular’s directive unit testing and a sitepoint tutorial for testing directives but kept getting errors. I realized the two things these have in common with each other but not with my directive, is their templating is inline and doesn’t import it using templateUrl in the directive. So. That explains why all my tests returned “Expected ‘’ to be ‘whatever’”. The blank stands for where my template should be.

I found some tutorials on testing directives that use templateUrl:

Turns out I’m going to need yet another plugin and do more configuring of my karma config file. karma-ng-html2js-preprocessor compiles templates to JS strings and generates angular modules and puts them in $templateCache so angular won’t try to fetch them from the server. This all sounds like a good deal for testing… but this plugin hasn’t been updated in about 3 years. Cool cool cool cool cool cool.

I thought I was picking an easy thing to unit test. There’s only one directive per “app section” in our codebase, so I figured these would be the easiest place to start as sort of standalone units. BUT all the docs are like “testing directives is really tricky because HTML templates, http requests, $compile/$digest, watching, and DOM manipulation” so now I’m wondering if I should just continue on through this mess since I’ve gotten this far, or if I should pivot and focus on testing controllers. I’m just… :bowing_woman::bowing_woman: Time for a walk and some chocolate, I suppose.

I chose to move on to testing the controller. I took about an hour to figure out how all the pieces fit together and what exactly the controller is doing, then wrote some describe and it functions to prepare for testing. The good news is I understand the controller logic. The bad news is the controller brings in data from an outside factory and I’m not sure how to mock that data while still testing the functionality of the data “import.” I’ve been googling, but I’m not sure I even know the right words to explain my dilemma. I’ve watched some youtubes and read through some tutorials, but I feel very lost right now, which appears to be a theme for the week.

I’m most confused about these:

Big question right now: do I need to test the factory in this script or is it good enough to pass it a mock object? My gut is telling me I should really be testing the asynchronous behavior of the returned data via promise and simply passing it a mock object will not be enough. HOWEVER, from what I’ve read, the $httpBackend method could work since it also does asynchronous promises.

29 mar

Last Friday of the month means monthly retrospective time!

March retrospective

Typically, I answer these questions:

  1. On a scale of 1-10, how are you doing on the goals you set for the month?
  2. Highlights
  3. Lowlights
  4. Biggest lessons learned
  5. Set goals for the next month

Quarterly, I go over my top 10 “major job buckets” and assess my 1-10 rankings of those, too. That would typically be today since it’s the end of of a quarter, but I didn’t actually write goals or major job buckets/rankings because I don’t actually have a great grasp on what exactly my job is yet. Lots of my rankings would be 0/10 because I know nothing about major areas of my job (DSpace, ArchivesSpace, iLLiad, student worker management, etc.).

Instead, I’ll review my work logs from the past month and reflect on what I’ve been up to.

All in all, this is my general feeling about March:

The cognitive overload and imposter syndrome feelings have been very, very real. I’m constantly reminding myself that this situation is not my fault, and I will do everything I can to learn and document as I go so this doesn’t happen to others who follow behind me. However, I’m not a wizard, I can’t just know all of this stuff by osmosis, so it’s going to take time to figure it out, and that’s okay. Just keep learning and working, one day at a time. :relieved:

April goals

I would very much like to set goals for April, but I don’t really know what to expect from the next month. Let’s get very general here:

That’s all I can really count on. Other things will pop up and those will be priority, so if I make any kind of significant progress on these three things, I’ll feel pretty good. :thumbsup:

back to work

So much reading today about testing legacy code. I heard someone on a youtube video say that when you don’t have documentation, tests, or a mentor, adding to the codebase or editing an existing piece of code puts you in “archaeology mode”– it’s going to take you 30 times longer to do anything. This is a good reminder since I’ve been feeling like such a failure recently.