Author Archives:

Sprint 1 Retrospective

At the middle of last week, our team finally concluded our first sprint, working on user approving system for the LibreFoodPantry. Overall, I think our team did pretty good on doing a lot of initial setups and communicating with other teams to make sure we can have a consistency on data across databases. For me personally, I did quite a lot of work on setting up repositories, researching on making the back-end database, and helping my teammate, as well as people from other teams on the problems that they have that are related to our module.

List of what I accomplished during the last sprint:

– Setting up repositories, including ApproveGuestWebUIApproveGuestService, and isApprovedWebUI, which regarding to tasks like forking from templates, enforcing rules for making changes to the source code, and informing the team about that policy.

– Researching about how mySQL database can be initialized on Docker containers, import – export existing mySQL container for future usage, and communicating to it from outside of the container (wiki page is available at link)

– As I am more interested in getting the back-end to finish in the early stage of development, I helped one of my teammate, Tyler, to make documentation about REST API endpoints and further getting feedback and making suggestion with other teams on those endpoints (wiki page is available at link).

– With all that endpoints in place, I setup the schema to potentially be what the mock and the actual database looks like and getting appropriate changes to it to match with the Register Guest module (wiki page is available at link).

– Finally, I had a lot more time towards the end of the sprint than I expected, so I dug deeper in setting up Spring Boot for the REST API and making a few objects within the program to lighten the amount of work for the next sprint.

With a lot of work that is put into initializing the project, I also learned a lot. While I did have a chance to experience SCRUM on my last internship, this time we use Gitlab as a tool to log all of our work, which I really the simplicity but professional and effective, rather than Jira and Confluence, which are more corporate driven software. I also learn to operate Docker, which I delay on getting to know it for a while as I though to myself that virtualization is a most optimal way to go, and after the last sprint, both are now under my consideration for future projects. And lastly, I learn that communication is really important, especially in the early stage of development, as a lot of data structures have to be defined and unified among the teams.

There is also the excitement, and at the same time,  frustration, of planning what to do to optimize the time and the work needed to get the job done as we had a list of questions without a clear answer on where we should head to. Although on Gitlab, we got really few comments put up, the teams had a lot of face to face conversations to make decisions on problems, and that I think is a problem that we need to record more of our conversation during the next sprint. At the end of the sprint, we are able to finish every issue tickets that we put up initially and we got quite some spare time afterward so I think we did a really great job on what we set out to do and I think the more sprint that goes on, we would be able to take a much heavier workload.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Pratice makes permanent

Apprenticeship Patterns is a really interesting book to read and I actually learned a lot from it. For this week, I read about the pattern “Practice, Practice, Practice” and there are a few interesting things I found about it. The pattern starts with a quote by George Leonard saying that masters they don’t just get better by devoting in a particular skill, but they practice getting better and the it gets more enjoyable to perform basic moves over again once they are better. I can definitely agree on this as I think we all have been through a rough beginning of doing something, but when we are better, we would think back how easy it is to do those basic task and we would do those rather than more complex problems that we have to face later on during the process of mastering a skill.
Then the author went on to talk about practice is a long process and it has to be done without interruption, and in a comfortable environment of making mistake. At this part, it is interesting to learn that practice in software development can be in a stress-free and playful environment. For me, I always think that the best way to practice is to join a group project, and there would be one or another thing that would stress me out so easily like if I work in a small group or alone even on a small size project, at some point we would be overwhelm with the amount of work that we have to deal with, or too much concern about security, features, accessibility, etc. and after reading this chapter, it makes me question about my priority on different aspect of the program and maybe I should change in order to get better.
The author also brings up another interesting point is to try to do a bit different for each time we practice and choosing the right thing to practice is very important. In my opinion, I think that should be the most optimize way to discover new things and not to miss out any important things while we are still on the basic level.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Thoughts on Apprenticeship Patterns at first glance

Apprenticeship Patterns: Guidance for Aspiring Software Craftsman by Adewale Oshineye and Dave Hoover is a really fascinating book that I’ve read throughout the weekend for my software development capstone class. At first, the book seems to be a lot more intimidating as I did not know what to expect from it, but while reading the first chapter and the introduction of five other chapters, there are some interesting contents that I found.
For the first chapter, or the introduction for the entire book, it starts off with the author of the book trying to tell how he started with BASIC and Java afterward and failed to find any interests in them due to the fact that they are not really beginners friendly and I think this applies to a lot of new developers that are constantly trying to get into the field but unable to do it by themselves. He then proceeds to move on to tell about how he found his success years later in Perl and use that leverage to dive deeper into software development such as Extreme Programming and Agile, which I think would encourage new developers to be patient on learning the basic and reading through this book may put them in the right path. I really like this story as it holds true for myself and it reminds me when I failed to learn Pascal, which in that time was described to be one of the easiest languages to start, when I was younger, and it really made me question myself to fit in this field. The author goes on to explain what apprenticeship and craftsmanship as known by everyone and how it is applied to software development. I honestly like how he ties this concept into software development to describe it to be a really long-term process, as we have to learn from other people through being an apprentice and a journeyman to be able to “masterwork” their ability, not just putting together codes and it is certainly not common to think software development in this way.
When I read the second chapter introduction, I think that it has a really great story in the introduction to make help us put aside everything that we know, or empty our mind and be exposed to the material of this book because we might be able to learn something new, whether we are new to software development or not. It is a good transition into the main content of the books that can either help beginners to understand further about concepts of software development, or veteran to solidify these concepts.
With chapter three, the message from the author is pretty clear that it can be really scary to not know a lot at first and we can also find it intimidated to know that there are a lot of people that know much better about what we are doing and it is important to be able to learn from them.
For chapter four and five, I think the authors are trying to say that there will always be more to learn and improve even when we excelled in a lot of fields. I think these chapters should be the most relevant one for graduating student like us as we might know a lot already and even be very good at it, but there will also be a lot more to learn when it comes to work in a real project for a real company.
And finally, with chapter six, the authors suggest that all developers should have their own curriculum to always expand our knowledge in the field. It is important to be able to find resources to read and learn on our own time and it is up to us to catch up with never ending developing technology. It is certainly an interesting chapter to read about to be more efficient on improving ourselves.
Overall, I think it should be a really useful book to read and it certainly be useful with a lot of aspects that it covers for each chapter. I am pretty excited to read more about it.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Familiarize myself with LibreFoodPantry

For the project LibreFoodPantry, although it is pretty new, its main page already includes a lot of useful information about the project as well as related topic such as licensing, code of conduct, and the change log, which I think is really important for users, and developers, establishing professionalism.

What I found the most useful item in the website is the Principle behind the Agile Manifesto. This item provides a really brief, but essential core principles for developers to correctly used Agile. As Agile documentation can be a lot and frustrated to go through, I think that this would be an better way for the team to understand them and to make good decisions on the project. These principles pretty much emphasize the value of customer satisfaction, encourage the team to work together as much as the project requires, improving the work environment for developer and operation team, and at the same time cut major costs for the project.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Software Development Capstone

CS-448, or Software Development Capstone, is one of the last classes that I have to take before graduating this Spring 2020. I am really excited to be able to work in this community project LibreFoodPantry as it can be a great experience to be exposed to skills that are needed to get the job done in the Computer Science field like leadership, teamwork and Agile. I hope that I, as well as everyone that are taking this class can make a huge contribution in this project so that it can be in used soon.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Static testing and Dynamic testing

Static testing and Dynamic testing is two different approaches to testing available for developers and testers in the software development process. In order to get the most out of these tests, this has to be chosen carefully and it is important to understand the benefits and the limitations of each one.

Static testing is a test method where code are not being executed and it can be done manually or using a set of tools. This type of testing would check the syntax, required documentation and design of the code. Static testing also includes security testing to analyze the software for potential errors, code flaws, or vulnerabilities. This method can be start in the early development stage of the program, and it can be done on work documents like specification documents, design documents, web page contents, etc. Static testing techniques include:
–  Inspection: The main purpose of this is to find defections. This task can be reviewing the check lists, work documents, or code walkthroughs and it is conducted by moderators.
– Walkthroughs: This technique would require the author to conduct a meeting to explain the product. Participant can ask questions and a scribe is assign to make notes.
– Technical review: This technique is to check if the written code is matched with technical specifications and standards. Test plans and strategy is reviewed here.
– Informal review: Documents in this technique should be reviewed informally and comments should be added.

Dynamic testing is done when code is in execution in a runtime environment. When code is running, the predefined input should get the expected result for the test to return positive. With this, developers can observe features of the program and monitoring the effect of this program on the running hardware. There are two types of Dynamic testing: functional and non-functional testing. Dynamic testing techniques include:
– Unit testing: testing individual modules by developers.
– Integration testing: testing the performance when different modules run with each other.
– System testing: testing the system as a whole.
– Acceptance testing: testing from user’s perspective end.

Article can be found here.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Black Box, White Box and Grey Box testing

Black Box, White Box and Grey Box are there most common terms in testing as it is really important. These terms are selections of tests that developers have that is based on their purpose of testing, what is being tested, and they determine which what tools or technologies to be used in order to tackle to problem efficiently.

Firstly, let’s talk about Black box testing. This type of test is really common on testing user interface. It treats the program as if it is a “black box”, or refer to testing without knowing or be able to change the internal implementation. It is also known among developers as closed or opaque box. The advantage of this type of testing is pretty huge, as developers can focus more on how to test the feature, rather than having to get to know the internal code. It also needs low time to prepare, and designed to simulate the perspective of users. With those potential advantages, the trade off of Black Box testing is also huge, as it might have a chance to have redundancy in tests, and QA engineer has to blindly explore the system without knowing the source of error, if the program has some.

White Box testing is basically opposite to Black Box testing, which allows the QA engineer to fully access to internal data structures and implementation. They are not only able to view the source code, they can also manipulate the code as part of the testing process. This is also known as clear box or open box testing. The advantages could bring a lot of benefits to developers as codes can be tested during the development process of a feature, which allows them to spot out bugs almost immediately. With the ability to access to the internal, QA engineer can use test in order to test for performance and optimization, and also it is a good practice to have code reviewed by multiple developers. The disadvantages can also be huge in contrast to what are mentioned before. White Box testing would require very in depth knowledge about the system and the duration of these test should correspond to the length of the source code, which is a lot. This type of test can also have a big influence from tools from development process that can affects the test cases and it is not scalable in anyway.

And finally, Grey Box testing, which is a combination of Black Box testing, and White Box testing. It allows the QA engineer to see the internal implementation, but cannot modify them directly. The advantages and disadvantages from this, is pretty much also combine between the two previous type of test. Grey Box testing can have the program to be seen as the level of user, while also can use the internal implementation to optimize the test cases. The downside of this is that QA engineer will not be able to change the source code, and have to play around with it multiple times to find a correct way to tackle the problem.

Article can be found here.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Path testing

Path testing is widely used to design test cases. Path testing process has 4 steps, which is to draw control flow graph, calculate Cyclomatic Complexity, make set of paths, and then create test cases for the those paths, which would use this formula: E – N + 2P (where E is number of edges, N is number of vertices and P is program factor). Path testing usually use control flow graph, which would help developers find sets of linearly dependent paths of execution. Path testing also use Cyclomatic Complexity to determine the number of linearly independent paths and each path should be a separate test case.

Besides control flow graph, path testing can also use different techniques like decision to decision path, where control flow path can be broken into various decision to decision paths and collapse into individual nodes, and Independent paths. There are various advantages of path testing like making sure that tests are isolated and not redundant to each other, it helps developers focus more on the logic of the programs, and finally, it helps developers to design test cases in a much easier and simpler way.

Article can be found here.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Code coverage

Code coverage is a subject that has recently come up in my Testing class and it did catch my attention for its useful functionality. So what’s code coverage? Code coverage is how much of the code that has been executed during the testing process. This process is not only check for every line of code, it also checks if all the branch of conditional and loops is covered. With this process in place, it would surely decrease the number of bugs.

With that being said, how would developers be able to apply this into their code? There are a lot of system and plugins out there that would help doing this job correctly, I will take JaCoCo plugins for Gradle as an example in this post, since I think it is a really good system that gives excellent reports. To enable JaCoCo, add this line to build.gradle:
 apply plugin: ‘jacoco’ 
What is greater about JaCoCo is that it let user define thresholds or conditions that the code coverage has to pass in order for the build system to return pass. For example, consider this configuration below:
jacocoTestCoverageVerification {
    violationRules {
        rule {
            limit {
                minimum = 0.8
check.dependsOn jacocoTestCoverageVerification
When this task runs, build system will ensure that the build only pass only if the code coverage metric reaches 80%. As simple as it looks like, I think it is an essential quality of life plugin to have for the build system.
Article can be found here.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Mock testing

Mocking, or mock testing, is a really well known method in writing unit tests. With “mock” in English is to imitate or replica something, a mock object in programming can be seen as a place holder for another object that has the exact same behavior. With that being said, mocking would enable developers to use the mock object to simulate the real behavior of the real object in order to perform without having to worry about dependencies of the real object.

With a little help from mock frameworks that available for the majority of the languages, mock testings has become easier and more efficient to use. The first type of mock framework is Proxy based frameworks, and it would usually creates a mock object to be called by the test, and it can handle that call by delegate it to the original object, or do operations by itself. This type of frameworks is commonly used as because of its simplicity but still does have its own drawback. For instance, proxy based frameworks can neither be able to intercept static method calls, private method calls, final method call nor build a proxy for a final class. The second type of mock frameworks is classloader mapping as the program would tell the class loader to remap the reference to the class file it loads, so essentially it would load the mock class instead of the actual class.

Article reference can be found here.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.