Author Archives: cradkowski

Finishing Initial Comparisons and LibreFoodPantry Retreat

Last Wednesday night I finished my comparisons between GitLab Gold and GitHub Free. I’m happy that I managed to get through all of the features before the LibreFoodPantry retreat the following day. I found that most of the features left for GitLab Gold did not have comparable versions in GitHub. This is more of what I was originally expecting and so the remainder of the table has a lot of features marked GitLab Gold exclusives. There was also a trend with the GitLab features that most of them would relate to one overall feature such as having Epics so since GitHub doesn’t have a native Epics feature it wouldn’t have any advanced features related to managing and tracking Epics like GitLab does. I also found that some of these features were harder to compare between platforms since most of them were more advanced, enterprise grade features than the earlier ones. This is again also due to how well the documentation for both platforms explains the features and how to use them.

Thursday was the beginning of the LibreFoodPantry Retreat. We started off by going to lunch and having casual conversations before the meetings began. I enjoyed this as I got to know everyone a little bit before getting down to business. Once we got back from lunch, all of the members who taught a course last semester developing software for LibreFoodPantry had a retrospective detailing the good and the bad and developing ideas and solutions to the issues. I found this process interesting to observe, especially after learning about software management processes this spring and now I got to see it in action with a real project. My advisor and I briefly described our summer research project and how it relates to what was currently happening with LibreFoodPantry. Through the first day I began to learn about issues that the group was encountering and areas where I can focus my research. Some items I will need to look for is assigning issues to multiple people or groups.

Friday continued with the second day of the LibreFoodPantry Retreat. I came in after lunch and immediately saw a whole whiteboard along one wall covered in sticky notes with labels. I soon found out that this was all of the user story mapping that was worked on while I wasn’t there. Dr. Jackson went through the whole story mapping briefly with me, explaining the user groups and the features and how they all fit together. It was eventually decided that this story map should be stored in the LibreFoodPantry organization/group on whichever platform we end up using and I should try to create a small version of this board on each platform. We then moved on to discussing infrastructure and workflow. Additional things I will be looking at now will be setting up continuous integration in GitLab and see how this works. I will also be fixing my platform features table so that features have consistent naming with their respective platform and that they are directly comparable across rows. Overall, I really enjoyed going to the LibreFoodPantry Retreat and seeing the processes and discussions involved in creating an open source software project.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Continuing Platform Comparisons

Last week I continued researching the features of the GitLab Gold and GitHub Free platforms. I continued going down the list of the features listed for GitLab Gold on its feature comparison page and then seeing if GitHub Free had similar implementations of these features. I originally thought that most of the GitLab Gold features would be exclusive to this platform, but to my surprise GitHub Free supports quite a few of GitLab Gold’s advanced features. I found that GitLab Gold does have some features that GitHub Free doesn’t though, some of these are either advanced features geared more towards enterprise environments, others seem to fall under more advanced user permissions such as selecting which users can approve merge requests. I found that GitLab Gold’s issue board system is much better than GitHub’s project boards with the ability to create more advanced boards than GitHub, such as a board with user assignee lists or a milestone list. I am again finding that certain features between the GitHub and GitLab platforms are easily comparable and have a direct counterpart such as requiring commits to be signed and other features are a bit more ambiguous such as supporting what GitLab calls “backlog management”. I am finding this is largely due to how clearly GitHub’s and GitLab’s websites document and explain the features the platforms offer. Another thing that I am finding that makes this comparison process harder is that the description for the feature on GitLab Gold’s product comparison page doesn’t always match exactly with the features described in the documentation it links to, or sometimes the links provided from the feature comparison page don’t go to a specific section of the online document. I have also begun to use the test groups to see for myself what features are available in these platforms. I have been mainly using the GitHub organization to compare its project board features to GitLab Gold’s issue board features as I find it is easier to actually see what’s available in GitHub than to use its website guides. I have also started to take note of what I think should be tested in the workflows between GitHub and GitLab, this includes the project/issue boards and some of the more advanced options GitLab Gold offers, along with other user permission settings GitLab has such as push rules.  I am hoping that at the meeting later this week we will refine the workflow so I can begin testing these features. I plan to finish the comparisons between GitHub Free and GitLab Gold before the meeting at the end of this week so that I have a good idea of all the advertised features of all of the platforms.

In addition to continuing research on the platforms, I also began to learn more about the LibreFoodPantry project. I did this by going through all of the past meeting minutes that were sent to me. I wanted to get a better idea and background on the project to see what decisions have been made so far and how my research into version control software fits in to this. I also wanted to this before the meeting later this week, so I could get a better idea of my purpose in these meetings.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Beginning My Summer Research Project

This summer I will be conducting research under the Aisiku Undergraduate Research Fellowship which is awarded to STEM projects for students at Worcester State University. The goal of this project is to research and select the best version control software to use for the LibreFoodPantry projects which fall under the category of Humanitarian Free and Open Source Software. I will be looking at the GitHub Free, GitLab Free, and GitLab Gold packages and selecting which one out of these three is the most suitable for contributing to and maintaining the LibreFoodPantry projects. I will be writing weekly blog posts to keep track of what I learned and did during the week while working on this project throughout the summer.

 

This week I began the project by looking at the features of GitHub Free, GitLab Free, and GitLab Gold. I created a table in a document with a column for each one of these and started listing out the features that are provided in the product comparisons page for GitHub and GitLab. Once I listed out all the provided features for all three of these I started to do a comparison between the features listed for the GitHub and GitLab plans. The comparison for GitLab Free and GitLab Gold is easier since GitLab Gold has the same base options as GitLab Free in addition to other advanced features which are listed in the plan comparison page. I then started going through all the features listed in GitHub Free’s plan page and seeing if the GitLab versions had them and if they were similar features. I kept track of differences by highlighting the text of the features in the table with different colors. I ended up finding that most of the GitHub features were comparable to GitLab such as having code owners or project boards. I found out that GitHub has a couple of features that both versions of GitLab we are looking at doesn’t such as an apps marketplace. GitHub also has a couple of features it does better than GitLab such as offering repository insights. There were also a couple of features that GitLab does do better such as having built-in continuous integration and continuous delivery. Overall I found that I started to prefer the GitLab platform by the end of the first week and their website offers better and more thorough documentation for its features than GitHub’s does. At the end of the week I had a meeting with my faculty advisor for the project to go over my progress and findings so far. In the beginning of the meeting we both came to the conclusion that the research being done for this project is applicable outside of the scope of just the LibreFoodPantry projects and can be used for other open source projects. We decided that I would continue looking at the features between the platforms during the second week. My advisor also created testing groups on each of the platforms and added me as an administrator so that we can start testing workflows after I finish comparing features. We also discussed the details about an upcoming meeting for LibreFoodPantry (which should help refine the workflows we will be examining in this project) and my involvement in this.

 

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

The JPA Architecture

Today, in this final post of the semester for CS-343 I will be examining the JPA architecture. This is something I have been curious about after browsing articles on DZone for the past couple of weeks and seeing this topic pop up a lot, luckily they made a good introduction post this week. From the article: “The Java Persistence API is the Java standard for mapping Java objects to a relational database”, this is something that I have been wondering how to do since we started working with the REST APIs and our projects that have been using Java HashMaps for makeshift databases instead of something more permanent like SQL. This article briefly introduces and explains the functionality of the six key parts of the architecture for JPA. The article gives a diagram for these six units and the multiplicity of their relationships. The article then gives a simple example of mapping a simple Java POJO Student class into data for a database, using the student ID as the primary key. I was surprised at how easy this translation was, all it includes is a couple of tags for columns above the instance variables that designate the database column, and which one is the primary key to generate in the database. The article then creates an application class that uses the various entity classes to store a newly created student into a database. I liked the simplicity of the article as most introductory articles are on this website for what are advanced programming topics, but my biggest criticism is that this article has brief definitions for many of the elements of JPA and then links to an external site that further elaborates on them. I wished that the author put a bit more time and consolidated all of this information into one article for this site, instead of having a bunch of separate webpages on his own website. I also wish he showed in this post getting data from the database and translating it back into Java and performing manipulations on this data with methods. Overall it was a good introduction to a very useful topic and one that I would like to further look at. Going forward, I am much in favor of using this way of storing data as opposed to simple Java in-memory databases for entire applications like we did in our projects.

Source: https://dzone.com/articles/introduction-to-jpa-architecture

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

The Command Design Pattern

Today I am looking at another design pattern. This one is the command design pattern, which is yet another Gang of Four design. They classify it as a behavioral pattern with object as the scope (GoF 223). I wanted to explore this one as reading through the different pattern descriptions in the Gang of Four book, this peaked my interested by its ability to separate requests from objects. The article gives a good summary of the idea of the pattern with a real-life example of a restaurant with a server taking an order from a customer and handing it off to a chef. It then further breaks down the pattern with the usual UML diagram and a helpful sequence diagram that shows the order in which the classes perform the pattern. I found this sequence diagram, along with the comments in the example program with code that show which class matches with which part of the diagrams really useful in this example, as the pattern goes through a couple of classes just to call a basic function on a simple object. Although this pattern does seem complex at first, it has a nice simplicity once you understand what all the classes are doing, and once you get the base created adding more functions is as simple as adding more command classes. The article then creates a simple example with Java of the command pattern using the various classes to switch a light bulb object on and off. I do like the idea of the pattern and its particular implementation in this example. It nicely breaks down requests into their own separate command objects that gives much greater control over requests across a program. I agree that the ability this pattern gives to create a log of function calls and add an ability to undo all functions called on an object is very helpful. I also agree with the author that it can get messy if you have a lot of functions that need to be implemented. As this pattern calls for a separate command class to be made for each function or method performed on an object, this can quickly add up depending on how many methods you need in your program. In the future, I will definitely remember this pattern and its useful ability to separate commands from the objects it performs them on.

Source: https://dzone.com/articles/design-patterns-command

 

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

REST APIs – A Few Good Guidelines

Today I will be looking at an article that examines five basic guidelines when creating a REST API program. I thought that after spending over a month on our final project creating a REST API backend it would be good to review some good practices for creating these REST APIs. The article gives five basic guidelines to follow and a brief background on each of the guidelines. The five guidelines are: name and case conventions for URIs, the different HTTP methods, HTTP headers, query parameters, and status codes. Some of these topics were a refresher from what we’ve already been taught, such as some of the HTTP status codes, and others were new such as the query parameters or case conventions. I especially thought the name and case conventions for the URIs was interesting. I don’t think I have reviewed naming conventions in coding in a couple of years, I usually use camel case for everything since I mostly write in Java. But I have been wondering what was the best practice for endpoints since I remembered code with HTML being more case sensitive. Also, with using different naming schemes instead of just using verbs that describe the method as in Java. I will keep in mind going forward to use the spinal-case method when creating endpoints. The HTTP methods section was fairly straightforward with what I already know, and the use cases for most of them are the same, but it does have a couple of additional methods I haven’t seen before such as HEAD or OPTIONS. The HTTP headers section was interesting, giving definitions and names for the different types of headers you use for different requests. The query parameters section was the most interesting and something that I haven’t come across yet working with REST. The status codes were familiar too, I have mostly used OK, CREATED, and NOT FOUND in my endpoints. Although I will start using NO CONTENT when performing a deletion endpoint instead of just 200-OK, as this seems to be the more proper response code. The same with using a 400 error of BAD REQUEST instead of just giving everything a 404-NOT FOUND error when an invalid request is made or an item is not available. In the future when working with REST I will keep in mind these simple guidelines from this article, especially in regards to case conventions for endpoints and with using appropriate status messages.

Source: https://dzone.com/articles/5-basic-rest-api-design-guidelines

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

The Iterator Design Pattern

Today I learned more about the Iterator Design Pattern and how it specifically applies to Java. The reason for choosing this topic is that during my project and talking with others the Iterator has come up a number of times throughout this semester. Now, I already knew about the Iterator in Java from taking Data Structures, but I never realized it was a design pattern before this course. The Iterator is actually a Gang of Four design pattern and it is classified as a behavioral pattern with object as the scope (GoF 257). The article gives a short summary of the iterator pattern and the reason it is used in Java. It is basically a way of accessing elements in a collection in order without having to know about the internal representation of the structure, a nice way of using abstraction. The author then gives a nice simple example in Java of how to use the Iterator pattern to access a collection of elements. He does this by creating a basic shape POJO with an id int and String name and stores them in another class that is an array of shapes. He then creates an Iterator class that defines the next element and if there is another element after the current one. This may be my favorite design pattern I’ve seen yet. It is simple to implement, but yet effective at its purpose, especially the way this article showed its implementation. I really like that once you’ve created an iterator for a type, all you need to do is pass in a collection of elements to it in order to process it. When I was working on the backend for my project I realized the need for something like an Iterator, especially with all the endpoints that were looping through the whole database. I wish I had implemented this so that I did not have to keep rewriting conditions to check that the data wasn’t out of bounds. In the future when I create my own programs with collections of elements I will make sure to implement an Iterator so that I can easily cycle through the data without having to worry about how to do it or constantly bounds checking the collection.

Source: https://www.javacodegeeks.com/2015/09/iterator-design-pattern.html

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Using Swagger for API Documentation

As we are nearing the end of the semester and about to finish our projects, I’ve been thinking more about the documentation process for the different parts including the frontend and backend. With this in mind, today I found a great topic about documentation generation for REST APIs with a tool called Swagger. I’ve never heard of Swagger before today, but it is a useful framework that allows for testing, documentation, and other useful features for building APIs. This post shows a quick little tutorial of how to implement Swagger for documentation generation with a Spring Boot project that is very similar to my project and the example REST API order system we have been using. It is a relatively simple process that includes adding the necessary dependencies for Swagger and adding a controller class for it, then all you have to do is just add the necessary documentation statements for each controller and requests within the controllers. The end result is a very nice-looking HTML page that displays a well formatted layout which includes the documentation for your API backend with a graphical display for each request and all the information associated with the request such as body and return information. Now as I was reading this article and this new way of creating documentation, I was comparing it to the way we’ve been doing it so far with a simple table written in Markdown for all of our API endpoints. The output of doing it in Markdown was nice but writing it was a tedious task with the formatting of the table. I much prefer the simplicity that Swagger allows you when adding a new endpoint. I also like the final product that Swagger produces a lot more than the simple Markdown document. In the future if I am creating another Spring Boot project, I am going to try to use Swagger from the start for documentation instead of using a Markdown document with a table for a basic readme as it appears that using Swagger makes adding new endpoints much less tedious with formatting. I would also like to try to add this to my current project if there is enough time, and also see if it is possible to use it with Angular too.

Source: https://dzone.com/articles/swagger-generation-with-spring-boot

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Processing JSON Data with Jackson

The article that I read this week is about processing JSON data with Jackson. I thought this would be a good article to read after using JSON data a lot this week for processing input and output in our final projects, and since Spring Boot uses Jackson as the way for processing JSON. I wanted to learn more about how this works, especially after getting some errors when trying to pass in certain data types this week (particularly Calendar objects). This post goes over how to read and write JSON data to and from Java objects using Jackson for data binding. It does this by creating an example POJO to use for input and output. It creates a basic employee with the fields of name, ID number, address and other typical fields, it also has an object within an object by using an address within Employee that contains a street, city, and zip code. The article creates an example of this in a JSON input file and creates the necessary Java classes and then implements the Jackson methods (such as ObjectMapper) for databinding and outputting Java input as a JSON file.

I think that it was interesting to see how to do this with the Jackson implementation as a seemingly more proper method of converting JSON to Java objects and the other way around. Especially after spending the past week creating and getting our project to pass similar data back and forth between JSON and Java. It does seem out of the ordinary to me that both of the example classes don’t use constructors, instead using just set methods to create the object, but that’s how this implementation is supposed to work with Jackson. I particularly liked the Tree Model implementation in the article and was not aware that this was a way of processing JSON data. This article has definitely made me think more about the different ways of processing JSON data with web applications and REST APIs and the best practices to use when doing this, especially with larger, serious implementations for applications. If time permits for our final project, I would like to try and do a similar implementation in this article for our JSON processing. By doing this, it would make adding new objects to the database a lot cleaner (especially without needing a constructor) in the implementation than it currently is.

Source: https://dzone.com/articles/processing-json-with-jackson

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

The Abstract Factory Design Pattern

This post on DZone talks about the abstract factory design pattern and gives an example implementation in Java using geometric shapes. This pattern is similar to the simple factory with the idea of constructing objects in factories instead of just doing so in a client class. It differs in that this abstract version allows you to have an abstract factory base that allows multiple implementations for more specific versions of the same original type of object. It also differs in that you actually create an instance of a factory object instead of just creating different objects within the factory class as in the simple factory.

I like the concept of this pattern more than just having a simple class that creates multiple instances of different objects such as the simple factory. I also like how the design allows you to have multiple types of objects that can split off into different more specific types, such as how the example Java implementation has 2D shapes and 3D shape types and factories for each kind. The design appears to be efficient, especially in the implementation example, only creating a factory for a type of object when it matches a specific type in the client call. Like the other factory pattern, you can also easily implement other design patterns for the object itself such as a strategy or singleton, which further would improve the final outcome. Another aspect of this pattern that I like is that the client itself is not creating the objects, it just calls the factory get method from a provider class that sits between the factory and the client.

I definitely like this pattern and will certainly consider using it the next time I have to create a program with many different variations of the same objects such as shapes or ducks as seen in previous programming examples. It will be especially useful to use this design if I am trying to type check the objects from user input to make sure they are trying to create a valid type of object with the factory. Overall, I am finding that as I read more articles about design patterns, especially for many objects of the same base, I am gaining a better understanding of how to maximize the program efficiency with one or multiple design patterns.

Source: https://dzone.com/articles/abstract-factory-design-pattern

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.