Testing to Pass the Time

What is going my good people of open source dev?

Have you ever dreaded those damn tests in school? Have you always put your heart and soul on the line to get that 'Pass'? Yeah, me neither...

This week's lab in my open source class we were tasked with creating unit tests for.... 
**queue drum-roll**
Our link checker program... Yes that again. Those of you who have no idea what is going on, good... you don't need to know. DeadLinkage (just incase you are interested)

Anyways,
As I mentioned, we had to integrate unit testing in our link checking programs. Let me start off by saying #$%! unit testing on java... OH MY GOD! What a pain in the ass this lab was.
I mean I loved the way java handles everything... But for real though. Unit testing on my code was a nightmare. I spent roughly 3-4 days trying to get JUnit (the testing framework for java) to cooperate with my IDE. 
BIG MISTAKE
It was a mistake primarily because everything had to work on a CLI. 
Anyways, at first I tried to get stuff working with JUnit5 everything was fine and dandy up to a point where I had to mock objects and classes such as the HttpUrlConnection and URL.

This posed a problem because the mocking API that I had settled on using was mockito. There was not a whole lot of documentation and examples of Mockito cooperating with JUnit5 so I decided to backtrack a version of JUnit to 4.12.

A good chunk of my time was spent walking back and forth while reading documentation on my phone about how mockito works. On my off time I would try code only to have it fail miserably.

I decided to take my problems to stack overflow and see if anyone else has run into this issue. I spent about a day reading through stackoverflow pages/questions and came to the conclusion that mockito, while a powerful mocking tool. Could not mock Final classes, the exact classes I was trying to mock (of course...)

While reading similar problems from other people trying to use mockito to mock final classes I came up on a forum that described an API that was used in parallel with mockito, Powermock. Powermock had an API of its own that works with the mockito API and served as sort of an extension to it.

So began my readings of the novel called "The Documentation". The way powermock is used was very similar to the way mockito is used to mock. Actually they were almost identical, slight variations from version to version in syntax, but that didn't pose much of a "threat". 

OK, COOL.

Theoretically, it should work right? WROOONG!
I was so close to making it work until I ran into another problem. Version compatibility.....
AGGGGGGGGGGHHHHH

The first thing I did was ask this cool girl (who unrealistically also likes Java like me)... and a lot of other things but anyways. Nesa had no idea what the issue was and proved to be of no help. She actually said she hadn't started the lab herself so she had no idea what to do. Here is a little proof.

Thanks for the compliments Nesa, but nice habits don't write the unit tests. (or at least not yet)

So, powermock 2.x is not really compatible with most versions of mockito. The same goes for the opposite. A full compatibility list can be found here. (note: I did not find the compatibility list right away) Learn from my mistakes and get the right versions.

Awesome! I found the right versions, downloaded the correct JAR files to stash in my external library list and now it was time to write some tests. 

For my first unit test I picked an area of my program that would be easy to work with and wouldn't be dependent on many mocked objects that needed to be passed in. That area was my function to load an ignore-urls.txt file. The only parameter that this function needs is the filename which is given through the system arguments (which are stored as Strings) when the program is ran. I had to mock the file name being passed in which was as simple as making a string hold a "filename.txt" and running the function with that argument. The function returns an array list of strings which I then had to iterate through a loop and assert that they were returning the correct thing. Easy peazy.

Hazaah! and so I had written my first unit test. I ran the test (remember in my IDE) and everything was working correctly. I decided to try and run the test on the CLI. aaaaand more problems started occurring. I was not able to compile my test java file due to the terminal that I was using not being able to see environment variables. I took my problems to the very helpful and knowledgeable professor HumphD. 

What do you know, the professor was right. Everything compiled fine in command prompt and another version of PowerShell. Thank you for the help! I was pulling my hair out and almost ended up looking like my buddy Chris.

It compiled, sweet! I only hoped that was my biggest issue at the time. I tried to run my compiled Test Runner only to have it crash and burn for missing dependencies. There was way too many for me to add and I did what every sensible person would do. 
PROFESSOR! I NEED HELP... again.
I explained what the problem was and David (yeah first name basis, we are cool like that) told me something I dreaded of hearing ever since I started this damn link checking program at the beginning of the semester. 

"Make a build project!" That is all I was hearing and my ears were ringing like I had been standing next to a speaker at a rave/club (ah what simpler times we lived in before all this pandemic stuff started happening).

Well I guess it was time to do the right thing. It was time to use a build tool like maven to "manage all this crap" as HumphD put it. 

Integration into a maven project really was not that hard. The IDE (IntelliJ) I use actually makes it really easy for you to setup a maven project structure on a Java project. I will link it here, in case others are trying to do the same.

Once maven support was added into my project I began to add the dependencies from the maven general repository, where you can find almost anything and everything. It is extremely easy to add a dependency into a Java project with maven... Literal click of a button.
Anyways once everything was setup, I ran the test I had written from before (The maven way) on cli and everything compiled and ran PERFECT! I was so happy I got over this hurdle and could finally move on after 3 days of pain and torture on my way back from the depths of hell.

Oh man, maven opened my eyes to a whole new world with Java. Maven is now my new best friend. Everything is so easy with this build tool.

Anyways, I moved on and started to write my tests for the core of my program. Testing my CheckLink logic. These functions basically take in a URL (string) to be checked and a HttpUrlConnection to get the status code of said URL. Remember 10 minutes ago when I was explaining about mockito and powermock being used together to mock final classes such as HttpUrlConnection? Well, this is what I needed this mocked connection for. I had to mock the status codes for a specific url, I chose google.ca because why not. I set the status code of the mocked huc to 200 and 404 so that they would pass my goodLink and badLink functions and basically checked the output the function returned against an expected output I had preset. This was not that bad once I already had the knowledge of how to do this. Once I finished writing the tests I ran all tests and to my amazement everything works flawlessly.

I am so glad I spent a couple of hours rebuilding my project as a maven build. PHEW. In the long run it probably saved me so much time.

Next on the task list was to incorporate a code coverage tool. I chose to work with JaCoCo because it was the first one that popped up on google it was in the maven repository and was easy to work with. Guess how long it took me to get it up and running. Roughly 15 seconds!

MAVEN BAYBEEHH! but for real I just copy and pasted the JaCoCo dependency code into my pom file and specified the directory I wanted my new reports to go in and ran my tests. Boom I now had code coverage (although not a lot of code was covered with 3 tests LOL)!

Next up on the task list was to add integration testing via github actions. This was not hard at all. Github actually has already made templates for executing maven tests. I just had to change the platform that the project was being built/ran on from ubuntu to windows although I doubt that makes a difference anymore since I added maven support. 
If you are interested in my workflow file it can be found here.

All I do in this workflow is the following:

• Setup Java
• Cache dependencies
• Compile the project
• Run tests

Running tests is dependent on whether the project compiles or not. If the project does not compile there is no point in running the tests. That is it. Pretty simple. Github documentation on maven CI was probably the clearest documentation I read throughout this whole lab. 

Anyways this is how executing the tests look like on each commit to master.

                              

The next item on the agenda was to write some tests for a fellow class mate. I did not even give it a thought I messaged my bald headed friend Chris right away to ask if he wanted to work together on this lab as well. To my surprise he said sure. I really did think he hated me.

Anyways, as I have expressed my feelings about Python before (utter hatred). I asked Chris to give me a little crash course on using pytest to see how everything works. He did a great job of explaining everything. We then discussed what exactly he wanted me to write tests for. He mentioned that he would like tests for the functions that print out each status code...(like why was this necessary for you to make Chris) uhm yeah sure let me do that.

So I decided to add the following tests to ensure they were returning proper status codes and that nothing was broken. If these functions stopped reporting the correct code the entire program will break. so anyways this is what I came up with.

For:

def test_status_check_unknown(capsys):

• this function is used when a link is unknown
• I had to figure out how to capture stdout and read what was being returned from a test
• I also had to find the ansi codes to verify the texts match from stdout since the text color was white

The next test I just made a mockresponse() class and assigned a status_code of 300 and checked that the object had a status_code member which was set appropriately. I did this because the 'requests' library in python returns an object containing these details so I mocked that. 

The rest of the tests are more or less the same, I just had to ensure the ANSI code was correct. 

I tested this on my end using the Pycharm IDE, I also changed the function I was testing in question and the tests did in fact fail because the underlying functionality of the base function failed. 

This reminds me of the matrix checker for our submissions in IPC/OOP/345.

FINITO!

Overall this entire process was a nightmare, I would never want to repeat it again. 

HOWEVER, with that being said I learned so much about java, build tools, unit testing and integration testing. It was a really big learning curve to say the least but it is now done and I can finally do some Game Dev work for my final project. Thanks for the learning experience David. It really was a lot of involvement and reading on this one cheers.

Working with Chris was always a sad reality that I had to settle to work with this bald little man 😐 LOL I'm joking Chris, it was a pleasure as always.

Till next time, 

XOXO, 

Gossip Plamen

Formatting and Linting my Life

 

Hello my fellow followers (professor).

I hope you are all doing well, despite Toronto being in the red zone. 

So, this week was an interesting one for my open source ventures. Lab 7 was released and we were tasked with implementing a code formatter and linter for our, you guessed it, link checker.

To be honest, I've grown fond of working on this little program because I enjoy building on top of it. It's awesome, it started as a POS horrid bandaged looking program but has since turned into something gorgeous, something like a rose if you will.

Anyways, I will get right into it because I have to finish 2 more blogs for this week and do my Game Dev lab #ThankGeorge. 

The first task was to choose a code formatter that would format code according to some standards. I chose the google-java-format that professor Humphrey suggested.

So this tool was actually pretty easy to use. I read the manual and just ran the jar file with the options on the CLI and it worked like a charm.

Low key,

I kind of don't like the way it formatted some of the files and in some instances it became even harder to read... Google standards are weird.

I actually took the extra challenge and made a git hook that will do this automatically every time on any file you commit. (I had some help from a couple of google searches on how to set this up properly)

So I made a little script that would download the formatter to a temp directory, if you don't already have it. The rest is self explanatory but I will throw the script anyways.

I actually installed this as a plugin for my IDE because... why not.

So the next thing we were tasked with was to pick a linter for our code that would improve our code and spot bugs automatically, professors lectures were actually really neat on this. I won't get into details though.

Once again, I chose to go with the professor's recommendations and chose the SpotBugs linter for java.

This was a big harder to use as the documentation was not that explanatory. As the standalone version I chose to use the GUI to see how it was. It was pretty cool so I recommend using that. It spot a couple of "bugs" in my code but not that many. I would say the major one it found was in my Load Ignore files, java file.

I was not closing the BufferedReader and it told me that (see below)

This is actually the same linter but the plugin version on my IntelliJ IDE. The fix it suggested was to either close the reader manually or encapsulate it in a try and catch block, like so.

You can read the full documentation on the CONTRIBUTING.md on my repo.

The final step was to squash all of my commits and push it to github.

Alright, that is all from me for this week's lab.

Till next time, 

XOXO, 

Gossip Plamen

Through the Looking Glass of Telescope

 

Hello my fellow open source followers.

I have been AFK for quite some time (reading week).

Although I have kept busy with studying for my last two midterms I have been looking into some interesting repos to continue my OS dev adventures.

Just when I thought I was all caught up and have gotten ahead on school work, I got slammed with so much stuff after reading week. Thus, this week was a busy one for me. #ThankGeorge (Game Dev professor)

Nevertheless, I pulled a couple of late nights and got through it...

Anyways, this week's lab was an interesting one. We were tasked with installing telescope, Seneca alumni made website to gather open source blogs together in one place using RSS Feeds, and YOU GUESSED IT, use our never ending link checker tool we had made way back in Release 0.1. 

Man it feels like ages ago

So, I dreaded setting up telescope because when I tried to set it up last time for hacktoberfest, I was left only in disappointment and quickly lost interest in setting it up because who RTFM... 

To my luck, of course our professor wants us to work with telescope for Release 0.3 and lab 6. Meaning I was forced to figure out how to set it up and actually RTFM. To my surprise everything installed properly this time and everything went pretty smooth. I also took my sweet time installing it... 

YEP... 5 HOURS

To be fair it only took that long because I was taking down Halloween decorations before it snowed again. I don't even know why I decorated this year, only two, TWO, kids showed up. 

EH! Whatever, I am not complaining. Now, I have a good reason as to why I am stuffing my face with so much candy. (#SorryNotSorry Dr. Roberts, my dentist)

Anyways, back to the point.

Everything went buttery smooth, so I ran telescope, ran docker, opened up and saw the JSON that the backend was returning for the 10 latest posts and began to think about how I would implement yet another functionality into my DeadLinkage. 

Thank god I had refactored my code from the previous lab, otherwise this would have been a NIGHTMARE.

I made a new file that would be dedicated to handling and parsing the JSON formatted array and pass back links to the actual main driver.
I then simply duplicated my logic for checking through all the links but added an extra loop to switch each link that was passed back from the JSON parser. To my avail it worked perfectly. I had to tweak it a tad to make it look pretty and all but I have spent so much time with this code I know all the ins and outs of it by heart and line (man I have no social life).

The ending result was something like this:

I am actually pretty happy with the results to be honest. This continuous expansion on the link checker tool is turning out to be a neat little app (especially after refactoring). 
OH, here is the diff if you want to check it out.

I will leave that with you and go bang my head on the desk spend hours in front of the screen because of DSA. #ThanksCathy

Till next time,
XOXO,
Gossip Plamen

Season 1 - Hacktoberfest Recap

 

WHAT A RUSH!

A race against time and other open source devs to qualify for open issues on repositories you are interested in.

What a great past time activity that is also accredited for school. 

Hacktoberfest! What a great idea. Especially in these interesting and difficult times.

It has finally ended. The busiest month I have ever lived through. It was not that bad to be honest. I have gotten through a lot worse (I think). 

Welp, this blog will serve as a recap to the most interesting event I have participated in, Hacktoberfest. The point of Release 0.2 was to contribute to at least 3 different repos and make 4 different PRs. 

What a great experience to gain knowledge in different projects and languages... UGH Python. 

Without further adu, Season 1 Recap of my Hacktoberfest journey.

Release 0.2.1 - Entry into Open Source

To get into the swing of Open Source contributions, I wanted to start off with something small. The first repository I chose was of a website that I had used on occasion to keep up with VR news when I first bought my Oculus Quest HMD. Unfortunately, I found a more intriguing website that contained more up-to-date information and game release/news. My first PR was to locate a script that was returning a status code 404. This was not that hard, like at all (thanks chrome dev tools). I made an issue on the repo and created a PR that had simply commented out the script returning a 404, which was doing nothing anyways. I think the maintainer does not check his github often since the issue and PR still remain open, Oh well.

Release 0.2.2 - Entering Another (Virtual) Reality

This was by far the most exciting repo I worked on throughout the whole month. I love virtual reality and I am really glad I got to contribute to this repo because the whole idea behind it is very neat. Oculus Quest is a standalone headset and has no connection to your PC. This owner of the project created a link to your HMD and PC through your LAN so that the Quest can communicate with discord and update your "discord presence", or simply put what game you are playing at the moment. I felt really accomplished with this PR because, I was finally doing something I have a passion for. I made a PR to update his JSON file which contained all sorts of applications and games. I even chatted with "MadMagic" on discord and we are now friends and talk regularly.

Release 0.2.3 - Avoiding Boring People with Chat Automation

My third PR was actually two smaller PRs. Why two? Well, because I didn't think it was enough for the fixes I made on the first one. I found this really neat repository that was basically a chat automation bot for the whatsapp web-based platform. The chatbot did everything you could imagine a chatbot doing. The maintainer was looking for a small refactor on his code by including a different style of CSS selectors from calling his constant selector class file. I replaced the selectors the way he wanted and got acquainted a little more with python, my arch nemesis. For the second PR of my third PR I had to basically copy the basic logic of his whatsapp bot, but make slight modifications so that a facebook session is made (click link above for more details).

Release 0.2.4 - More Pythonic Automation

This was yet another contribution towards automation bots. However this was tailored only to scraping elements from the whatsapp web-based platform. The maintainer (Navpreet) wanted me to write a function to scrape and return a phone number of a specific person that the user has an existing chat with. Really neat and as it turns out not that easy. It was interesting seeing how code varies from machine to machine. A problem I encountered was that the code ran fine on my machine and did the intended task, but once Navpreet ran it on his end it gave him an error (see blog for more details).

That was it for the month. Overall the experience was amazing and I will definately participate in next years Hacktoberfest. I really enjoyed getting involved in various projects and most importantly I made friends and (Hopefully) connections by interacting with the project maintainers. There are a lot of people that are like minded and have the same cores and interests as I do, no matter where in the world they are. a big thank you to my professor for picking something so interesting to get us involved. 

Oh and I made my 4 + 1 Hacktoberfest accepted PRs even though 2 of the PRs I made for Release 0.2 were not in hacktoberfest repos.

Now, all that is left is to wait for the PRs to mature and for me to get a sweet T-shirt. 

That was everything that happened during Season 1, stay tuned for Season 2 of my hacktoberfest journey next year around the same time... obviously for hacktoberfest.

Till next time, 

XOXO, 

Gossip Plamen

Lab 5 - Changing the Course of Time

Oh Boy oh Boy!
I am back with another week's worth of (meaningful) knowledge.

This week we were tasked with refactoring our code for our never ending assignment, link checker (DeadLinkage) for those of you who have not been keeping up with the Kardashians blog. 

I had to pick and choose at least 3 things I wanted to refactor about my code... TBH, I wanted to throw the whole thing away and never look at it again. SERIOUSLY! Although it worked flawlessly the whole thing was held together by a piece of reused duct tape that had fallen on the carpet.

Anyways, I started thinking about how to refactor this whole gigantic mess that looked like my current room state, into something that was modular and easier to look at, as well as easier to work with and maintain.

I came up with something similar to the suggestions put out from our professor.

• I decided to get rid of global variables such as the CLI ANSI colors and store them into a completely separate class.

• Split the main driver of the program into smaller more maintainable components and naturally moved them to other classes/files.

• Refactored how the parsing of the arguments was being handled in the main driver program and split into components based on whether the user provides a URL or a local html file.

Now that the "hard" part of the lab was done, it was time to do some git...git...git outta here...

First thing I had to do once my final commit had been made into my refactoring branch was to rebase and squash the previous commits into one final commit.
This was done by: "git rebase master -i" which opened an interactive rebase editor where I was to pick which commit I wanted to squash the others into.

That went pretty smooth. I was expecting some sort of conflict to occur, but no. 💯

The next step before I merged into master was to make a meaningful commit message because frankly the rebasing commit message was not doing it for me.
This is achieved by: "git commit --amend"

IT IS TIIIIIIIMMEEEE!

Let's merge to master ~sweating profusely~. 

uhhhhmmmm... WHAT?!? No merge conflicts second week in a row?
Am I doing this right? I mean I will take it and go on about working on designing my game for yet another time consuming course GAM537. #ThanksGeorge

I will leave you guys with that for this week.

Expect more of my greatness O.o in the upcoming weeks.

Till next time, 

XOXO, 

Gossip Plamen

Release 0.2.2 - Entering Another (Virtual) Reality

 

Hello my fellow gamers.

Today's blog will be a continuation on the festivities of Hacktoberfest.

As I mentioned on my last hacktoberfest blog, I am a big VR enthusiast. I absolutely love escaping reality and jumping into the virtual world where I can be whoever or... erhm... whatever I want to be without any judgements. 

So as you all know I bought an Oculus Quest roughly a year ago and have been dabbling into VR open source lately. There are a lot of cool apps/games that are made specifically for the Oculus Quest.

Anyways,
for my second PR I wanted to contribute to something I recently found and have been using ever since I found it. The discord rich presence application for the Quest. It is basically an app that runs on your computer and updates your discord status based on the packets sent from the quest to your local network. The Quest sends packets based on event driven tasks, so every time you open an application a packet is sent. The PC application picks it up and updates your discord status to whatever the packet was.

The creator of this application mentioned that he is looking for contributions to their games/apps json list. 
I got into contact with him and chatted for quite a bit. He told me how to properly test the updates and how the application itself works (see above).

My chat with him went something like this.

Extremely cool dude.

Awesome, I got the OK from the owner to go ahead and contribute to his repo.

The first thing I did was open up his json file to find that there were already over 100 games/apps that were being picked up by discord... That did not make my job easier.

I opened up a third party store (SideQuest) tailored for Oculus Quest developers and got to searching for games that were not in his list.

I found content that I can update his json file with and got to work.

I added about 20 games to the list. Might not seem a lot but it definitely is for the amount of time I spent searching.

Everything was working as expected I fed the package name, the state and the description for each app.

I then pushed it to my fork on github and opened an issue on his repo. I made a PR and linked it with the issue.
To my satisfaction he merged my PR. I felt so good about contributing to an actual VR project. It was awesome. 

I will contribute something more in the future to this repo as it is very useful for Quest owners.

Well... that was it from me for this week. Stay tuned for my next contribution in the VR scene.

Till next time, 

XOXO, 

Gossip Plamen

The Merge Conflicts of Life

Hello my fellow strugglers,

This week in Open Source Development we were tasked with making a couple of small features to our ever growing and glorious link checker program.

TBH. 

I feel like there is nothing glorious about this program and the way I did it. I am realizing this the hard way. Even though Selenium gets the job done, but at what cost, something like this would be written better in plain java. Eliminate all these dependencies.

Anyways, before I go off topic too much, we had to implement 2 small features or "upgrades" if you will.

The first feature I chose was to add in exit codes, really simple. Since I had made a separate function to check links all I had to do was put the function call in main in a nice little try and catch. If anything went wrong an exception would be thrown and a boolean variable would be made false and would exit with an exit code of 1. Super simple even my cat could write it.

My second feature however, took a little thought. I implemented a command line argument to check for good, bad, and all links with their respective arguments. Sounds easy, but  I had to refactor a lot of my old code to make it happen.

BUT!

That was not the point of the lab. The point of the lab was to merge the 2 branches together and see if we get any merge conflicts and deal with them.

Alas, my two features were complete and it was time to merge them. Naturally my first merge went without a sweat.

Time for my second merge.

MERGE CONFLICT!!!!!!!!

Of course there was a merge conflict, why wouldn't there be one. Life couldn't have just given me this one favor this week.

Meh, W.E.

I opened up my IDE and checked out what the issue was. To my benefit it was just a couple of lines that were having problems with each other. Easy fix!

Thank goodness that was over because I had just came off a whole nighter for one of my other courses (Game dev....)

I had to fix a merge conflict before and it got real messy because I didn't know what I was doing I never encountered one before and had no experience with them.

TBH.

I would not change anything next time when merging something because working on different branches and having these small merge conflicts are just part of the fun road to success.

I am now going to stare at my screen pretending I know what is happening work on some data structure labs.

Till next time,

XOXO,

Gossip Plamen

New Issue -> PR, New Issue -> PR, New Issue -> PR ... Hold Your Horses

 

OK!... 

Now I know I am no expert or even come close to it, but how do you find issues in my code?
Not to boost my ego or anything but I have been programming in Java pretty much since "Day 1", and consider my knowledge slightly above average than the regular newbie acceptable. 

This week we were tasked with finding a person on slack to work with and I did just that, Chris - Bald (🦲) dude with a bad attitude. We had to fork, analyze and create new issues on their (Chris') repository.

OH BOY!

So I began forking, cloning, analyzing/ reviewing, fixing... the whole nice yards.

Chris did his 0.1 release on python EW. If you guys should know something about me, it is that I absolutely from the bottom of my heart despise python and anything built with python... but Chris looks like a smart dude and I figured looking at his code might not give me a brain aneurysm. P.S. it did not.

Anyways, it was time to begin. upon cloning his repo locally I began to read the README file he had provided with instructions on how to setup the tool and get it running. That is where I ran into the first issue. Since I hate python (as mentioned above) I had no idea which version I needed to install on my machine to get it running. I suggested he add a download link in the readme. The rest of the setup went pretty smooth.

Time to analyze

This was fun! Looking at how someone else handles the same exact problem is fascinating. Chris did a great job on his code, I did notice some exceptions that could be handled a little better but with my knowledge in python (basically none) I could not make a PR for that. Instead, I found something small that was confusing at first glance. His variable naming conventions, although fine for such a small tool, were not to my liking. So... I made what any other sensible person would have done. My first PR BABEEH. He actually merged it. I felt a sense of accomplishment, a sense of contribution. 

Likewise, Chris found several issues on my 0.1 release. They were not anything ground breaking but he did help me clean up my code a bit. He edited my instructional README quite a lot, which was a punch in the gut I thought was clear enough but with the edits it looks and sounds more clear. Thanks bud.

All in all, this experience with communicating, reviewing, and fixing other's "mistakes" was a very insightful experience on how the real world operates. 

Chris was an awesome partner and I agree with his words (some) "We Learned", however I would say...

We didn't grow, We didn't laugh, I definitely hate him.

Till later,

XOXO,
Gossip Plamen

P.S. I don't actually hate you that much Chris

Release 0.1 AKA anxiety attacks every 0.5 second

 

WHAT A WEEK! This week was a rough one for your boy. 

I am the type of person who looks forward to new challenges.

Someone who enjoys spending time and learning about new things.

Someone who gets some sort of euphoria when something is completed.

BUT OMG! This week had me banging my head on my desk my anxiety levels through the roof.

I say this because this week we were tasked with completing our very first OSD600 release.

Release 0.1:

This annoying little program was to be a CLI tool to check for broken links on a specified URL or a local html file.

Naturally, when starting these types of projects I think to myself. What would be the best approach to do this with as little effort and least time consumed.

BUT, since this is Open Source Development, I wanted, NAY!, I had to be unique from all the python and JavaScript plebs coders. So, what did I choose... Java with the Selenium framework.

OK. Perfect I knew what I was going to do.

Time to start.

Starting was the easy step. Reading up on Selenium and how to use the chrome web driver was not so easy.

At this point there was a lot of this...

When I finally had an understanding of what I needed to do and how to implement the code I ran into an issue with the chromedriver.exe which quickly turned from (look above) to...

After talking to my professor (and me having my IDE open for the whole day) about why it was not working he pointed me in the right direction. 

The issue was solved but the terminal on my IDE had to restarted in order for the environment variables to take effect. Easy fix. Restart Intellij. HORRAH! It worked.

Anyways, this is the ending result for my 0.1 release which bares the creative name of "Dead Linkage".

Getting started:

There are a couple requirement in order to get the tool setup and ready to go.

• Download Chrome browser
• Download chromedriver.exe
• Make sure you have Java installed on your machine
• Download "Dead Linkage" jar file
• Make sure you have an up-to-date terminal which supports ANSI escape characters such as "Windows Terminal"

Excellent onto the usages.

First thing you want to do is open the windows terminal and navigate (using cd) to where you saved the jar file.

Once inside the directory you can run the tool using the following commands: