Posts

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 communic…

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 tha…

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 …

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.

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.

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…

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 chanc…