Chapter 9 details the transition from a new FOSS project to a mature FOSS project. The hand off step is the first part of this transition in which a new professional developer takes over the project moving forward. Other aspects of moving forward and the maturing of a FOSS project include opening a forum for consumer feedback, and identifying new markets to try to branch out to for a larger consumer base. Creating a community forum is an excellent way to open discussion for bug reports, and new feature requests/ discussions. While identifying new markets to branch out too is a solid way to increase your consumer base which in turn will also increase your customer feedback, however this new consumer base could have different values than your original base. With maturity comes the importance of concrete roles within the project as well. Task specific roles such as data analysis, and bug fixes/ testing are very important for the longevity of the project’s life.

 Due to the pandemic going on currently I was not able to meet with any groups in the Charleston area. However, two weeks ago I competed in the national cyber league hosted by cyber skyline.

The National Cyber League is a biannual cybersecurity competition that consists of challenges designed to demonstrate participants ability to identify hackers from forensic data, break into vulnerable websites, recover from ransomware attacks, and employing other security methodologies and practices.

First of all, I will say that my experience of this competition was mostly enjoyable! First, we practiced the preseason game which was about 98 questions and tasks related to cyber security that we needed to attempt to complete. This preseason lasted a week and was initially quite easy until I got further into the challenges where the difficulty ramped up significantly. The main thing I learned from this first encounter of the NCL was that of the art of steganography or the art of hiding images, text, and files in different nonsuspicious type files. For example, the fact that one of our challenges were given an image and told that a flag was hidden somewhere in it. Steganography was new to me and finding these flags proved to be a great and fun way to learn something new.

Now, after the preseason concluded my score was tallied and I ended up being placed in the silver bracket for the individual ranked games.  (the middle bracket). I was excitedly surprised with as this was the first time I had gotten to utilize my cyber security knowledge outside of a school setting, and it turns out I wasn’t nearly as bad as I though about it.  The individual game was intense to say the least. While we had a whole week to dedicate work to the preseason we now had only 72 hours to answer about 150 questions and tasks. This had to be the most intense coding weekend of my life. I easily dedicated almost any waking hour that wasn’t spent eating to the NCL. All in all, the challenges for the individual game were mostly in the same topic however, their difficulty had been drastically increased. I notice under the wireless access section that one of the tasks labeled hard in the preseason was now drastically similar to a task labeled easy in the individual game. Once the competition was over I had achieved 65.8% completion status of all possible tasks in the competition. Something that I was originally upset with, but now looking back I am proud of since our Professor Dr. X who also competed in the competition was stumped on some of the same hard labeled problems as I was.

As a closing note I would highly recommend participating in the NCL as it was a fun and rewarding way to learn new topics and test my knowledge and command over what I already knew.

Chapter 6 generalizes the concept of solid database structures and how to implement them. Normalization is the first key topic that stands out to me here. Any developer working on a project should have a clear scope of how to handle each task at hand. Normalization is the key to this. Developers tasked with planning out what is necessary to make a project work must then normalize the tasks at hand to remove redundancy from the project.

Other points this chapter focus on include security and integrity, The former focuses on safe keeping databases from malicious actors through blocking unauthorized access of user accounts or data stored in the database. Users should only have access to the data pertinent to their account and the intended function of the app being used. The concept of integrity then goes on to focus on the fact that data in a database should be stored as it was intended to be. There should be checks put in place so that data does not become miss managed or corrupted from wrongful access. For example, gracefully handing two users editing the same page twice. Google docs is excellent at this and will show each user what is currently being edited to all other connected users. While GitHub for example can only allow one user to edit a given page at a time to prevent any previously written data being lost.

In summation, to ensure responsible database handling programmers should employ solid database security and integrity methods to produce a quality product.

Chapter 5 of our book mostly revolves around how implementing proper testing practices can greatly benefit developers. Testing is crucial to any type of development to ensure that the finished product will work as expected/ intended. This chapter goes very in depth over unit testing and the use of properly designed test case template as well as a framework for the whole testing process. Employing a proper framework will alleviate workload as all the tests in the suite can be ran together instead of the need for them to be run individually.

Another point this chapter raises is the proper implementation of a domain class to tie all good testing habits too. The domain class at it’s core is the heart of the any CO-FOSS project. The chapter emphasizes the need to use legacy with minor tweaks in how it functions for to help ease testing strain, and the help build higher cohesion with moving forward with the project. Debugging and Refactoring code that has been a around for a while is a good method to adopt as well. As given enough time there can always be things that break or can be implemented more efficiently to smooth continued production. All in all these are all things to keep in mind as I move forward into the computer science world. Coupled with S.O.L.I.D. coding practices this is all some very solid advice to bare in mind.

This concept is one that we covered last semester in 362. It is important to employ this concept when you know you will be adding too and modifying an existing project. Releasing early and often also allows clients outside of the development environment to stay up to date on the happenings surrounding the project. Which in turn, also allows users to give constructive feedback more frequently and often.

The article I picked to read was from the CoACM magazine titled “Cyber Security, Nuclear Security, Alan Turing, and Illogical Logic” The article was written by Martin Hellman one of the creators along with Diffie and Merkle of public key cryptography. The first half of the article discusses Hellman and Diffie’s troubles “battling” the National Bureau of Standards (NBS – now called the NIST) and the NSA over the fact that their proprosed Data Encryption Standard’s (DES) key size of 56 bits was not secure enough. Hellman begins by initially believe that the 56-bit key size was a mistake on that would be corrected once addressed, however the NSA states that a larger key size would mean foreign governments, criminals, and terrorists would have an easier time hiding their communications from the NSA while the 56-bit key size would not. The NSA would not concede the 56-bit key size until much later when both sides of the battle learned an important lesson that Hellman would go on to emphasize as “get curious, not furious.” The NSA in 1978 contacted Hellman to review the key size when design proportions for the F-35 fighter jet where stolen and decrypted.

It was very interested to see Hellman’s reflections of his time working in encryption during his 30’s as he is now in his 70’s.

The idea of this reading was to convey “SOLID” coding practices that all developers should strive to employ. The “STUPID” part of the article refers to: Singletons, Tight Coupling, Untestability, Premature Optimization, In-descriptive naming, and Duplication. All of these are concepts I have absolutely used many times in my career as a computer science student. I still find my self using terrible variable names such as “x” all time. The basic over view of “STUPID” is that it is a novice way to code, and pretty much how everyone starts out.

Next the article moves on to “SOLID” which consists of: Single Responsibility, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. The aim of the “SOLID” ideology is to produce code with high cohesion. In short going through the list one should strive for:

• keeping classes to a single responsibility, instead of having a class control multiple jobs. This is to keep coupling low.
• projects and classes should be open for extension and closed for modification.
• The liskov principle states that sub-classes should be replaceable by their parent class.
• Interfaces should be as direct as possible. Just like the single responsibility principle for classes, interfaces share the same idea. That is, one should not implement an interface that contains methods that are not needed.
• Finally, use the same level of abstraction at any given level, and interfaces should depend on other interfaces.

Employing these concepts will lead to a highly testable, and cohesive project.

6.4 Find the oldest bug that’s still open in your chosen project. Write a blog entry describing the problem, with a theory about why the bug hasn’t been resolved yet. (Bonus points if you can actually resolve the bug.)

• The oldest open issue for OpenPetra is “Print Posting Register after posting a batch only works with FastReports.” This issue was posted December 4th, 2014 and has been marked as a low priority. This is more of a feature request than a bug as there is already a way to print the statement under fast reports.

6.5 Figure out how to create a new account on the bug tracker of your chosen project. You’ll need that account very soon.

• OpenPetra utilizes GitHub’s issues tracker, and I have already forked the project to my repository so there is no need to set-up an issue tracker account.

6.6 Go through your project’s bug tracker and find a bug that you think you might be able to reproduce — and then try to reproduce it in the latest build. Take careful notes. Report your experiences as a comment to the bug. If you can reproduce the bug, great! Give as much information as you can. If you can’t reproduce the bug, great! Give as much information as you can, and ask the original reporter if there are other steps you might be able to take to reproduce the bug.

• The first bug we chose to tackle as a team was the easiest to reproduce. We have actually fixed this bug and submitted a pull request from our repo. Now the bug in question is “Fix missing translation in LedgerSetup.entry_first_current_period.” This bug is caused due to there being a missnamed dictionary term in the project which causes the variable name to show up instead of the desired result. Recreating the bug is as simple as opening a demo of OpenPetra and navigating to the correct tab to view where the variable name is being presented.

6.7 Find five bug reports in the new state, and attempt to triage them according to the rules above. Your goal is to do as much as you possibly can, in a short period of time, to make those bug reports as useful as possible to the developer to whom they are assigned. (Note: be sure to follow any triage rules that your project may have defined. If there are no set triage rules, be sure to announce your intentions on the project’s mailing list, so that developers can provide you some guidelines if they choose.)

• The creator of OpenPetra submits all issues himself into the issue tracker, and keeps it organized the way he sees fit.

My name is Wright Ledbetter, and I am a senior at college of Charleston. My major is computer science. I am an introvert, but still consider myself to be fun loving and out-going at times. My biggiest hobbies include reading, playing video games, amatuerly playing the guitar, and occasionally playing dungeons and dragons. I’m looking forward to expanding my knowledge in software engineering during this semester.

25.10. Describe five factors that engineers should take into account during the process of building a release of a large software system.

1. Marketing – teams will need to have the experience and know how to meet the costumers expectations.
2. Instructions – the users will need a well documented list of instructions for how to use the system.
3. Past versions – The users will not want a completely revamped system or system UI. Engineers will want to do their best to keep their new system visually similar to the past version.
4. Platform – The platform that the system will be running on is important as well. One would want to ensure that their product will reliably run on the widest possible ranges so that more user coverage can be achieved.
5. Time management – You will need to ensure that the project planning is properly prepared as working on a large system cannot be rushed.