Author Archives: Kat Law

Software Development Capstone – Sprint 6 Retrospective

For this last sprint, our team made several steps to continue tackling additional features for our left navigation bar. As I described in the previous sprint retrospective, we had made a list of other tasks that would make sense to be added to this minimum viable product. Last sprint, I focused primarily on the CSS styling of the navigation bar. This sprint, I spent more time refactoring our code so that it would be more easily modifiable and versatile for upcoming semesters. We also looked at integration of other components into the main app.

Towards the beginning and throughout the sprint, our team had been starting to discuss how our code would work with other components that other teams were making. Instead of putting all of our navigation bar code into the app.component.html file of the Angular project (the main app’s HTML), we were directed to make a new component, called “left-nav-bar,” which would store all of the code that we had already written. The file structure of this component is the same as the “app” component, so that our code was easily transferrable, moving the contents of the app.component.html file to the left-nav-bar.component.html file, as well as updating the left-nav-bar’s CSS file in a similar manner. To generate this new component through the terminal, I used the command, “ng generate component left-nav-bar” (reference found here). Then, once all of the files of the left-nav-bar component had been updated, the app.component.html file was modified such that it referenced left-nav-bar. This utilized the left-nav-bar selector tag, found in the left-nav-bar.component.ts file. The following line is the only one in the app.component.html file: <app-left-nav-bar></app-left-nav-bar>. With this left-nav-bar component, rather than having all of the code in the app component, any other component could utilize the left-nav-bar code. It becomes easier for the left-nav-bar to be used elsewhere through referencing it, whether in the main app or within another component.

Another significant addition to the navigation bar was a home button, so that the user could navigate to a primary home page at any time. This home page would also be the default page when initially launching the main application. In order to go about this task, I once again used the above mentioned command to generate a new component: “ng generate component home-page”. This created the home-page component in the “app” folder. Fortunately, I did not have to change anything that was created from this command. However, my component was missing a routing module, which implements the Router service provided by Angular to display certain components or component views, based on the definition of a given URL (reference found here). In order to successfully create this module file, I created a file with a name (home-page-routing.module.ts) that matched other components’ router module names (patient-search-routing.module.ts, for example). Then, I copied the code from the latter file into the former, and changed the names presented in the home-page-routing file accordingly such that they reflected that component and not the patient-search component. For example, I changed the name of the router module class name from PatientSearchRoutingModule to HomePageRoutingModule. The following line was also added to the home-page-module.ts file such that the importing of this routing module into the application was recognized: import { HomePageRoutingModule } from ‘./home-page-routing.module’;. I also updated the app-routing.module.ts file (more specifically, its list of possible Routes) to add a new path to this home page component, as such: path:’home-page’,. Finally, I added the following code to the end of this list so that upon starting the app, the home page component view would be immediately shown – path: ”, redirectTo: ‘/home-page’, pathMatch: ‘full’. The redirectTo section allowed me to specify that component.

After these were added to the app, we set to start merging our app with other teams’ components. However, this encountered further issues, as these other components were overlaying our navigation bar while the application was running and caused them to not work properly at the same time. While we did not have much time to fix this issue, we discussed that continuous integration with other teams should have been a top priority from earlier sprints, and unfortunately this was not considered until the last minute. Hopefully during future semesters, other classes can ensure that this process is started earlier so that we could end up with a working app with multiple components.

Thanks for reading! It’s been a productive semester, and I hope to have more posts soon about my experience as a new software engineer.

From the blog CS@Worcester – Hi, I&#039;m Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Reflecting on “Apprenticeship Patterns” – Confront Your Ignorance

Here we are – the last Apprenticeship Pattern of the semester! I’ve learned so much about how to successfully transition from a budding computer science undergraduate to a new software development professional. Now that the semester is just about over, I am going to be spending most of my time between now and the start of my new job learning about their tech stack. As I’ve discovered while getting to know the engineering team, I don’t have any experience with the technologies that they use. This brings me to the apprenticeship pattern for this week, “Confront Your Ignorance.”

Confront Your Ignorance pretty accurately describes the position that I am in right now. In this situation, the apprentice has identified several areas or skills that they don’t know much about, and they are interested in learning more. Sometimes, those around the apprentice may already feel comfortable with these skills. The simple solution for the apprentice is to begin “filling in the gaps” in what they know about any skill(s). This could be in the form of articles, tutorials, or Breakable Toys (personal, private projects that allow the apprentice to safely learn about different tools without consequence of failure), among other methods. This pattern is closely related to Expose Your Ignorance, another pattern that I wrote about in the past (found here). While it is possible to keep these patterns mutually exclusive, a balance should be made between the two so that the apprentice feels comfortable enough to share what they don’t know about different subjects with other teammates, as well as puts in the effort to work on it and learn more.

I have been able to relate to each of my discussed apprenticeship patterns in some way, and this pattern is no different. While I am aware that I have a lot of ground to cover in order to understand as much as I can about my company’s tech stack before the start date, it will be great to combat this by confronting this ignorance head-on with multiple learning strategies, mostly by reading more books and completing online coursework.

Thanks for reading! I hope to keep up with this blog as I continue self-learning throughout my professional career.

From the blog CS@Worcester – Hi, I&#039;m Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Reflecting on “Apprenticeship Patterns” – Kindred Spirits

One of the most important lessons that I have learned from being in a computer science program is to surround myself with people who value computing as much as I do and push me to challenge myself and learn more about the field. When I first started working on my computer science degree, I tended to isolate myself from other people in the major and work on projects or assignments alone. However, over time, I did eventually start to find “my people,” or the people who were also pushing themselves through the program, focusing on improving their skills as well. This week’s apprenticeship pattern, “Kindred Spirits,” emphasizes how essential it really is to have people who not only support your growth in computer science, but also understand what it’s like to go through what you’re going through.

The problem that Kindred Spirits seeks to address is the situation where the apprentice feels like they are “stranded” without help or guidance from mentors or other supporters in the community of computing. They may feel like they are walking the CS path alone, which, in such a huge, rapidly-changing field, can be detrimental towards the apprentice’s success.

The solution is, in short, to get in contact with people who are involved in the same road of knowledge, as well as joining communities that encourage that growth. For some, this form of reaching out may be easy, but for others, it may take more effort to put themselves out there. For me, I tend to have difficulties with joining new groups, especially if I don’t know anyone from the group. But, as I’ve been progressing through the computer science major, I have acquired some great friends along the way who know how difficult this journey can be. For example, one of my pals, James (here’s his blog), and I have consistently collaborated on assignments and projects for a lot of our classes, and getting through those courses definitely would have been more difficult without the support from someone who is also working hard to learn more about CS. I’m also looking forward to meeting and working with my new co-workers, who I’m certain also possess that passion and determination to learn more about computing and want to share that passion with others.

Thanks for reading!

From the blog CS@Worcester – Hi, I&#039;m Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Software Development Capstone – Sprint 5 Retrospective

Once again, this week marks the end of another sprint, with even more progress taking place for our team’s component of the AMPATH mobile app, the left navigation bar. As I described during the previous sprint retrospective, our team was able to complete a minimum viable product (MVP), meaning that any consumers utilizing this app would have a minimally functioning navigation bar! This sprint was focused mostly on adding and polishing new features that could make this navigation bar better.

During our preparation for the upcoming sprint, we came up with a list of additions that would benefit our navigation bar component, not only in terms of aesthetic but also in terms of functionality. For styling changes, we decided that we wanted to make edits which promoted easier readability. Other changes that we wanted to make included adding a home button on the navigation bar so that users could redirect back to the main home page, creating a dropdown menu for some of our buttons in case a sub-menu was required, and fixing the navigation bar such that once a button was clicked, the menu would collapse, rather than staying open when switching to a new page.

My overarching task for this sprint was to focus on the styling changes that we wished to make to the navigation bar. This included making the text size for the navigation buttons larger, increasing the spacing between each button to make navigation between each tab easier, center-aligning the button text (rather than left-justified text) because our whole team preferred the center alignment, and changing the color of the whole app to a darker mode so that it makes it even easier for users to look at the app. Adjusting the font size of the button text required a quick edit in the CSS file, app.component.css, where the font-size attribute related to the container with our navigation bar buttons was increased. I used the following site to make this change. Likewise, switching the alignment of the button text was specified in this CSS file, in the same section which described the formatting of the same aforementioned container. I used the following site to verify which attribute to change and how to modify it properly.

In order to increase the spacing between the buttons, I simply added 2 line breaks between each button, modified in the HTML code for the app (saved in the app.component.html file provided by the Angular framework). Finally, to change the color scheme of the app, I used the following site in the Angular Material documentation to learn more about the different themes that are pre-built into Angular Material, as well as how to go about creating my own custom theme. I initially considered creating a custom theme, but I wanted to check out each of the pre-built themes beforehand in case I liked any of those instead. As part of the Angular Material Themes, each theme has a primary palette (which are colors most often used on the app), an accent palette (for interactive elements on the app or any floating screens or dialogs), and a warning palette (for any error messages or notifications). I did a trial and error of each of these 3 palettes, for each pre-built theme provided by Angular Material, listed on the Angular Material site, and I found that I, and the rest of the team, preferred the accent palette of the pink-bluegrey.css theme, which resulted in a “dark mode” of the app. In order to incorporate this theme into our app, I navigated to our global stylesheet, styles.css in the top level of our src folder, and added the following line: “@import ‘@angular/material/prebuilt-themes/pink-bluegrey.css’;” Then, in our HTML code, whenever a color attribute in our button tag came up, I specified that the accent palette would be used, which looked like: “color = accent”.

This was a very productive sprint, and I’m very glad that our team has the flexibility to add more features without having to be concerned about the basic functionality of the navigation bar being affected. For our final sprint, we are going to be focused on finishing most, if not all, of the rest of our additional features. We will also be wrapping everything up for the semester (holy moly it’s the end of the semester already?). Stay tuned for my last sprint retrospective, and thanks for reading!

From the blog CS@Worcester – Hi, I&#039;m Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Reflecting on “Apprenticeship Patterns” – Unleash Your Enthusiasm

As I’ve been progressing throughout my computer science education, I’ve realized that I’m pretty psyched about coding and computing in general. Just thinking about how much that can be done with computer science is enough to get me excited about the kind of work I’m doing. I’m sure that at some point in my career, it may become harder to maintain this excitement for what I’m doing. Even though it’s incredibly cool, it’ll inevitably be my daily routine. This week’s pattern has to do with the continued passion and excitement that I should maintain about computing, even if others around me might not reflect it as much.

Unleash Your Enthusiasm presents the hypothetical situation where an apprentice, with a lack of experience in the field, brings enthusiasm for the subject as part of their skillset to a team. However, the team may be more established and therefore could be less outward about their enthusiasm towards their work. They may be focused more on completing their projects without taking the time to be excited about it. As a result, the apprentice may feel more obligated to keep their enthusiasm more inward and conform to what they think is the norm for the rest of the team. It is imperative that the apprentice keeps this level of excitement and isn’t afraid to let it out, even if others don’t necessarily share it or express it.

I honestly feel very fortunate to have surrounded myself with people who not only support my passion for computing, but also take part in that same enthusiasm. However, I completely agree that even if I were to end up in a situation where I may feel more pressured to subdue this flame of excitement for computer science, I should still not let this affect how much I love what I do. I’ve worked in some teams in my classes where my groupmates were determined to get work done, but they weren’t really excited about it. This has, at times, negatively influenced me so that I spent more time keeping my head down and refraining from showing how I really felt about our progress. But, as I finish up my undergraduate classwork and start my professional career, I am confident that I will have that supportive environment to fully express my passion for computing.

Thanks for reading!

From the blog CS@Worcester – Hi, I&#039;m Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Reflecting on “Apprenticeship Patterns” – Expand Your Bandwidth

I have some very exciting news to share: I have recently accepted a software engineer position to start after graduation! I can’t wait to get started with this company, and I’m counting down the days until my first day there! My final interview involved talking with different members of the engineering team, and there was time allotted throughout the discussions for me to ask my own questions. There was one question that I asked everyone: “What is some advice that you would give a new graduate from a computer science program who is just getting started in the field?” There was one answer that came up the most, which was to not stop being eager to learn new things. This brings me to the apprenticeship pattern for this week, “Expand Your Bandwidth.”

This pattern exactly reflects the advice that I was given during my interview. Expand Your Bandwidth provides context with a possible problem of software developers’ knowledge potentially being focused to the type of work that they take part in on a daily basis. The solution is to simply begin absorbing more new knowledge at a faster, deeper rate. While the developer may find this process to be overwhelming, it is crucial that they can improve their ability to increase the level of learning new concepts and applying them to their own work. This process of expanding bandwidth includes actively seeking out knowledge, possibly through blogs, podcasts, courses, and contact with others who are as passionate about the topic as the apprentice is.

I couldn’t agree more with the suggestions and solutions that this pattern provides. I already have a list of several projects and practice exercises that I hope to complete throughout my career. I am so fortunate that the company that I will be working for seems to be ever-changing with the type of engineering work that is being done. I am confident that I will not run into the problem of work becoming stale or too routine. Nonetheless, I will be sure to continue to keep on taking in new information and building my field knowledge.

Thanks for reading!

From the blog CS@Worcester – Hi, I&#039;m Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Software Development Capstone – Sprint 4 Retrospective

Over the course of this past sprint, our team has continued to make more progress in providing a functional side navigation bar for the AMPATH mobile application. In fact, at the very end of this sprint, we found that we now have a minimum viable product for this component! Every member of the team had a part to play in this development.

For this sprint, we divided each section of the side navigation bar component into parts, such that each of us would have a smaller contribution to complete. Each of the roles were as follows: creating skeleton code for the side navigation bar so that it could provide a template for adding styling and further functionality, fixing the toggle button for opening and closing the navigation bar, adding styling and design based on the uniform style for the rest of the app, determining the type of content that will be displayed and navigated to with this bar, and adjusting the scaling of the navigation bar depending on the type of device used to access the application.

Most of these tasks were able to be completed by the end of the sprint! One of the team members created a blank Angular project on GitLab and provided code for a functioning dropdown navigation menu, which was a great template for our next step to creating the navigation bar.

The next step was figuring out the styling and design for the application overall (which would reflect in the navigation bar). This ended up being Angular Material (powered by Google), which is an implementation of Google Material Design that is compatible with Angular applications. Because the wireframes that were provided from the AMPATH team utilized Google Material Design, it made sense to work with this sort of design. So, using the Angular Material Getting Started guide (found here), I followed the 5 steps to change the skeleton Angular project into an Angular Material project. This first involved using the following command to install required packages: npm install –save @angular/material @angular/cdk @angular/animations. Next, the BrowserAnimationsModule was imported into the Angular project such that animations that come with Angular Material would be supported. Then, the NgModules for each of the desired components of the project were also imported. A prebuilt theme was also added, so that all core and theme styles could be incorporated into the application. This required the following statement in the styling sheet: @import ~@angular/material/prebuilt-themes/indigo-pink.css;. Finally, in order to allow for gesture support in the application, the HammerJS library was installed using the following command: npm install –save hammerjs. With all of these steps in place, we had a project with Angular Material! One of my teammates found a useful video tutorial about Angular Material (found here), and this resulted in even further developments on our navigation bar, in terms of better aesthetic, as well as functional pages to navigate to, and a working toggle button!

This upcoming sprint will be devoted more towards adding more features to this working navigation bar, and these will all be discussed in more detail in the next sprint retrospective.

Thanks for reading!

From the blog CS@Worcester – Hi, I&#039;m Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Reflecting on “Apprenticeship Patterns” – Expose Your Ignorance

If my previous blog posts haven’t reflected it enough, I am definitely nervous to step into the professional software development field. This is likely mostly due to my case of imposter syndrome, where I think of myself as less capable or knowledgeable than I actually am. On another hand, though, I have also been overwhelmed by the thought of being behind other team members or colleagues in terms of knowledge and experience, even though everyone will, and should, be aware of this gap.

This week’s apprenticeship pattern, Expose Your Ignorance, further reassured me that learning new things and not necessarily knowing everything right away on the job is a normal occurrence. Everyone on the team is under pressure to submit work by a certain time, and when there is a “weaker link” who may not be on the same page as other team members, it can certainly cause some tension and perhaps anxiety for this team member. However, in order to best confront this issue, the team member should break down their walls hiding their ignorance toward the subject of the project, as well as let everyone else know about of how much they know and how much they still need to learn. It is suggested that one of the best ways to show this ignorance of any topic is to ask questions, as well as remain transparent when working with others so that the team member’s level of expertise is not misinterpreted. The apprentice should not only disclose this information, but also emphasize their willingness to learn and catch up with the rest of the team.

I already had a feeling that upon entering the workforce, senior developers and other colleagues would have some sort of understanding that I will not have as much experience as them, and that I will need to spend time catching up to what they know. This pattern was great to allow me to realize that I shouldn’t be afraid to let everyone know where my knowledge of our work stands, even if it requires further progress to strive towards everyone else’s level of understanding.

Thanks for reading!

From the blog CS@Worcester – Hi, I&#039;m Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Software Development Capstone – Sprint 3 Retrospective

As I mentioned in my Sprint 2 Retrospective, this sprint was going to be significantly more exciting than the last sprint. This absolutely proved to be correct, because our team now has a project and a component of the project to work on! This is a very exciting development, because now we can finally start coding! We have been in touch with a representative from the AMPATH team, who has been giving us further information and wireframes/designs. Our final project will eventually start to reproduce these designs, and the remaining sprints will document the progress on that code.

But before that, we have been receiving lots of information about the type of work that we will be doing for the rest of the semester. Our project is the completion of a mobile app that simplifies the AMPATH point-of-care system, which is currently only present in a desktop interface. This app ideally will contain various components, which include: a search bar to find patients with an accompanying results page, a form that would appear when retrieving specific patient information, multiple lists of patients which can be toggled with a side navigation bar, a selection of different form types when choosing a patient to learn more about, a form with multiple tabs that contain different but related information, and a bottom navigation bar for further options. All of these parts of the mobile app were designed by the AMPATH team, and we were able to observe the wireframes of each component on Zeplin, a website which joins the roles of designers and developers. We are also not going to be provided a server, so we also have a team composed of members from different groups starting to work on mocking a back-end server (releasing pre-defined data rather than live data) so that the app can mimic retrieval of real-time information. In order to do this, the team is determining which of the front-end components will require some sort of back-end communication, so that the server can be mocked properly and fully.

Over the course of this sprint, we have mainly been setting up our coding environment with the new knowledge of what our project is going to be, as well as the part of the project that each team will be working on. Every team from Worcester State who is working on the AMPATH project has been connecting to a GitHub repository which only has a blank Angular project and a README/License. From this point, progress on each component of the app will be part of a separate branch in the GitHub project. We have been deciding how to go about diverging so that each part of the work is separate from every other component. Some ideas included individual or team forking, as well as team branches. However, due to possible changes in teams, as well as members of different teams working together, the decision is to work on component or feature branches.

I am very excited to see what kind of development process we will make over the course of the next sprint! Thanks for reading!

From the blog CS@Worcester – Hi, I&#039;m Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Reflecting on “Apprenticeship Patterns” – Practice, Practice, Practice

The time has come where I need to start looking for jobs in the field of software development. These jobs require rigorous interview processes, which generally include some sort of coding assessment; in fact, I just took such a test only a couple days ago. I want to ensure that I will do the best that I can do during each assessment, while also continuously improving so that my performance will get better with each interview. This growth requires practice, practice, practice, which, conveniently, is the pattern that I will be discussing this week.

Practice, Practice, Practice, as the name of the pattern suggests, describes the ever-present need to keep up with skills and striving to improve upon current level of skill. One of the common challenges, though, is that an apprentice may only have the opportunity to practice in the workplace, so that there is a risk to make mistakes with potentially harmful effects. Apprentices should have the opportunity to practice techniques outside of this environment so that there is room to make mistakes. When there is the looming pressure of causing lasting damage should the on-the-job practice go wrong, it can definitely be stressful for the apprentice. This could result in a lack of learning from any mistakes made from the process. The whole point of practicing is to ultimately learn from it, and so it is imperative to separate practice from job training.

I completely agree with the points discussed from this week’s apprenticeship pattern. It’s so important that I have the chance to make mistakes and learn from them, without having to worry about messing something up in my job’s overall system. It’s also important that I keep working on my skills in general. As I keep applying to development positions, I need to (and will) make sure that I maintain a level of consistency with my practice exercises. Using online tools such as code katas, as described in the apprenticeship pattern, as well as other resources, I have plenty of ways to implement high-quality patterns of practicing.

Thanks for reading!

From the blog CS@Worcester – Hi, I&#039;m Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.