At some point in your career you will approach a plateau. How you deal with it and get past it is a real challenge and something that many programmers will reach in their careers.The problem that Rubbing Elbows presents is “Your productivity has reached a plateau, your learning is stagnating, and you have the feeling… Continue Reading →
From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.
This past sprint was not quite as productive as we would have liked, although we did manage to start making great progress towards the end. In the beginning we ran into a tremendous amount of roadblocks. Between angular versioning, formatting errors, and more, we were really struggling to get off the ground in terms of productivity. It seemed as though, once one person had the local environment running on their machine, it broke for someone else. It wasn’t just a couple of us having issues, either. Each person in the group seemed to encounter some error at some point in time.
First, one of our members was struggling to build the angular environment at all. A fresh install of angular was required, which seemed to have fixed the issue. After that, I was facing some issues with something called polyfill.js, which was interfering with my ability to get my angular server running at all. Stack overflow wasn’t of much help because most of the issues I found posted were suggesting that I alter package-lock.json files, etc. These were all things that my teammates didn’t have to do in order to get the server running, so I figured that the solution was simpler than that. I was correct in my assumption once I remembered that AMPATH recommends that we run ng serve with the –prod tag as well. Upon doing this, the issue with pollyfill.js resolved and I could run the server perfectly fine.
Not only this, but we seemed to have many issues with git branching for whatever reason. We had previously played around with another group’s branch in order to confirm that we could get styling running at all on our local machines (which is how we realized we needed to ng serve in order to see styling). This ended up being a bit of an issue for a few of our team members, because they were seemingly unable to git checkout back into our branch — git was declaring that they didn’t have permission to join the branch again. In order to fix this, those members decided it was easiest if they just deleted the repository locally and recloned the project. Upon all of these changes, we were finally all caught up and able to ng serve nice and cleanly, without any big red errors.
Once we had fixed angular environment issues, we moved on to development and actually got some design happening. A big issue we were trying to conquer was that our angular form component using the material design “mat-form-field” module wasn’t displaying correctly. It was a standard HTML text field as opposed to the correct Angular Material styled one. Last sprint we discovered that we were being a bit silly with this and that we needed the angular server running for the text boxes to display correctly, but even still, our field component wasn’t functioning how we had anticipated. After playing with some other components (material design checkboxes, etc.) I realized that we foolishly hadn’t important the library for the material input field, which was nested within the form field. Due to this, it was completely un-styling our entire form field. After importing this correctly, it was (and has been) development game time.
From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.
The apprenticeship pattern framed the problem is that if you do not have room to make mistakes in your day to day programming, you will not have room to grow. The next line hit close to home, “It’s as if you’re always on stage.”
I learn quite a bit from my school assignments, but I don’t always think I have mastered each area before moving on to the next topic. The problem arises when I know my code could be improved upon, but it’s currently working. I don’t want to restructure my code too much, because I’m afraid of making it worse.
The term comes to mind, “If it ain’t broke don’t fix it.” I have problems with this way of thinking, but when you’re pressed to make something work before the impending deadline, “good enough” is sometimes feels like the only option I have left.
This pattern champions a different approach to this kind of mentality. I like the idealized version that they have laid out based on the research of K. Anders Ericsson. This describes where a mentor would assign you a task based on your strengths and weaknesses. Once you have finished your mentor will review it and point out areas for potential growth the next time.
A important distinction the pattern makes is that we cannot use our profession to practice because when you practice, you make mistakes. You need to find time outside of your work session and make those mistakes when you practice.
I realize having a mentor may not always be realistic for everyone. However, I think I have a way to practice this over the summer. I have been talking to one of my classmates who has started a small consulting company. He offered me a position if I was interested, which I am.
They are currently is contracted by my alma mater, Quinsigamond Community College, to keep track of the information that is collected by their greenhouses. He has hinted that he might look to expand it if he is successful.
I feel this closely fits to what the pattern suggests. I will have a mentor. I will be practicing my skills and having close feedback. I will have room to make mistakes as my status as their employee does not solely rely on my performance. Don’t get me wrong, I still want to do a good job, but it is not extremely high stakes. There is also the freedom to work when I choose, so I won’t be constrained by time, especially when I am going to be lifeguarding and taking a summer course. I am excited to begin this new chapter in my life — a new step on the journey towards mastery.
From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.
The apprenticeship pattern I’m addressing this week is Confront Your Ignorance from Chapter 2: Emptying the Cup. This pattern follows the previous pattern in the same chapter, Expose Your Ignorance, which I’ve previously written about here. The idea is that, once you’ve identified where your weaknesses are in your area of work, you must confront those weaknesses in order to grow. It’s hard to know where to start. Sometimes you’ve pinpointed weaknesses in areas where it is expected for you to have expertise, and it seems like you’re the only one who actually has those weaknesses. It’s hard to know where to begin. Confront Your Ignorance suggests that you choose one area and start filling in the gaps. Do so in whatever way is most helpful for you — whether it be through introductory guides or through diving right in.
This pattern is actually very helpful for me in this very moment. Over the past few days, I’ve been dwelling extensively on what I do and don’t know. What is expected of me as a software engineer, and what I expect of myself in this discipline. I’ve come to recognize that I have many weaknesses that I’d like to eliminate — things like algorithms, many topics in systems engineering, and so much more. There’s a lot of things I would like to experiment with, and there are also a lot of things I need to understand before I can do that. Frankly, it has been pretty overwhelming to constantly think of all of these things at once, and it’s been fairly discouraging as well.
I’ve exposed my ignorances (or rather, they’ve been exposed for me through the interview process), and now it’s time to work on them. It’s not going to change over night, and it isn’t going to change all at once. However, it will improve through consistent, deliberate work. That involves choosing one topic and chipping away at it over time. The difficult thing for me is likely going to be choosing which topic to work on, because I have so many things I’d like to learn. I suppose I can’t go wrong though, so long as I commit to learning and keep checking new topics off my list.
From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.
This week I decided to learn about how to “Find Mentors” by reading the pattern. This pattern gives advice about why and how apprentices should seek out to find mentors to continue down the path to becoming a journeyman. They give tips about attending conferences, joining online forums, and taking your potential mentors out to lunch if you have the opportunity.
I do agree that finding mentors is greatly important in the development process to become a successful software developer, but I think this pattern idolizes a certain type of developer and therefore limits the opportunities for mentorship for those who try to strictly follow what the pattern is advising. This pattern seems to focus on those who are directly working on the development of a particular language, framework, tool, or some variant of open-source software. They even pretty much open with the idea that it is very likely that your mentors are not local and that you will likely never meet them. I think that this is where the pattern is failing.
From my experience, there is almost always someone, or a group of people within a company that those with technical positions turn to for mentorship and advice. At my most recent internship, it was a man named Kurt who has worked on the proprietary software (Oracle) before signing onto the company that we both worked for over the summer (TJX). He initially was a contractor from Oracle, but TJX found that his expertise regarding the frameworks that made up our software made him too valuable to let go of and they hired him full time. He immediately became the go-to guy whenever anyone had a question about our software. He had been working on it for over 15 years and had gone through over 10 iterations of the software. A key thing to note is that while everyone asked him for help, they weren’t asking for mentorship. This is something that came with my internship as he was selected to be my “buddy”, which was just a fancy word for mentor. We spoke several times throughout the summer about both career goals, and different ways to solve problems. We spoke about how to solve certain problems that were specific, yet more general than our specific code base. To get this kind of mentorship, I didn’t need to lurk on an internet forum, and the same went for everyone I worked with that wanted to learn from him. All I had to do was ask. There will likely be a Curt everywhere, any of us end up working, and I plan on utilizing their mentorships.
From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.
For this week’s sprint, I’ve spent most of the time looking into a way to automatically increment the version number (based on semantic versioning) every time we make changes. Currently there is a reference to the version number in 4 different places: The Procfile used by Heroku, the build.gradle file, the Java configuration file for Swagger, and the README Markdown file. To do this, I’ve been looking at different Gradle plugins that could do this automatically. There seem to be many different options available, but there doesn’t seem to be one that completely fits what I’m trying to do. I think that the fact that some of these files simply have the version number hard coded in is causing this issue. It would be simpler if the version number was located in one place (maybe a version.properties file) where all of the other files simply reference that file to do what they need to do with the version number.
While it’s not exactly an high priority task, given that there doesn’t seem to be many more changes needed to be made to the project at the time, it’s important to automate the version incrementation now in case the project needs to be updated in the future. It’s definitely not a good idea to keep it the way it is, as having the change the version number in multiple locations could potentially break something if one of them is forgotten. For example, we already ran into an issue where Heroku couldn’t find the jar file created because the version number hadn’t been updated in the gradle.build file but it had been in the Procfile. This caused the jar file that was created to have the wrong name, so Heroku couldn’t find it.
Also, another thing that I want to start looking into is to add unit tests using JUnit, as it’s something that I’ve neglected to do but definitely want to get done before the semester ends. That would include some basic unit tests for each class to make sure their methods are working properly but also some Spring Boot specific tests. For example, I should be able to create tests for each endpoint to confirm that they’re working properly, perhaps using some of the techniques learned from previous coursework such as mocks. Spring Boot appears to have a wide variety of auto-configured annotations that could potentially be useful for creating these tests. For example, the annotation “@RestClientTest” disables full automatic configuration and instead only applies the configuration that is relevant to REST client tests. This ensures that Jackson and GSON support is auto-configured.
In conclusion, I’m hoping to finish up with the automatic versioning as well as added necessary tests to the project by the end of the last sprint and before the presentation. I definitely don’t want to leave the project without adding any tests as that’s bad practice. In any future projects I’ll need to make sure not to neglect creating useful tests but I also want to avoid creating useless tests that were made just to have tests in the project.
Sources:
https://www.baeldung.com/spring-boot-testing
https://www.baeldung.com/restclienttest-in-spring-boot
https://github.com/davideas/GrabVer
From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.
For this week’s installment of individual apprenticeship patterns I have decided to write about the chapter of our textbook called dig deeper. The reason I did this chapter is because it initially caught my attention with its relatability. The catch with this article was that you have a superficial understanding of different software tools. I find this to be extremely relatable because we see a lot of different tools in our classes and at the same time we don’t have much time to cover the tools and master them. I think in my testing class we were using a new tool every few weeks, which really hurt us in the end because I did not have a chance to fully grasp or understand how the tools(s) worked so I have a very superficial and not very deep understanding of these tools. I could probably use them if I tried hard enough and used google to assist me in my journey. I wish that one of two things happened. I wish we had more time to understand these tools or I wish that we did not cover so many tools, however I do understand that we need to cover many tools because there are many tools out there that are constantly changing and they are always making new tools too. The solution to the problem of not understanding the tools or having just a superficial knowledge of the tools is simple. You have to study and learn the new tools. It kind of sounds intuitive that you would have to spend time to learn the tools, but you really have to spend time to learn the tools. This means doing homework outside of work and being able to understand your learning in these tools. By this I mean not just simply taking an online tutorial on a software tool that you well and fully know will cut corners in attempt to try to make the tutorial more understandable and faster. This may seem good in concept but they are leaving out pertinent information that you need to know to master the tools.
From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.
This week wraps up sprint number five. This was our second to last sprint which is kind of crazy to think about. It feels like we just started! Unfortunately we also believe this means we are not going to be able to finish all of the product that we had hoped to. We were not necessarily expecting to finish an entire project form scratch at the begining but we had been making some extraordinary progress over the past two or three sprints. As it stands now we have a (mostly) complete intake form for the food pantry owners to use. It is missing a few fields that they would like to see, however the base version of the sheet is complete. The base version is the current intake form that they gave to us to translate from paper to application. What we are working on now (and calling “incomplete”) is the extra features or new fields that the food pantry owners wanted added to their base version of their current existing intake sheet. For this sprint we got our repository fixed. It had some underlying issues with the way that it was set up that prevented us form achieving progress to the fullest extent (see sprint 4 blog for more information on our wacky repository). Once we got into our new and restructured repository we started back up on work. For this sprint I took out the task of implementing a zip code feature to add to the intake form. To do this, I created a new branch separate from master on our repository and called it zipCodeFeature (git checkout -b zipCodeFeature). The next thing I had to do before working on this feature was to create an empty pull request on our parent repository in order to track my progress and commit history. In github I went to our parent repository and created a pull request from my new branch. Once I have finished my work and am ready for it to go onto the permanent repository I can ping a member of that repository with write access to review my pull request and implement my feature. What I did from there was begin working. Creating the zip code field on the form was rather easy. Since we have a bunch of other similar fields on the intake form I was able to reuse the HTML for it, leaving me to only have to change the ng.model and variable names. For this one I used the “studentID” field and changed all the studentID references to the new zipCode references. Next I had to go into our customer.ts file and add zipCode to the list of instance variables for our Customer object. After this I had to go to the customer-form-spec.ts file (this is where the customer object is constructed and there also is another customer object that we are using as a test subject in that file) and add the zipCode fields to both of those constructors. Going back to the main HTML page for the form I had to add a method at the bottom which relates to the second page of the intake form and saves the information. Again, I was able to reuse some methods that were already existing in the file. I then proceeded to test the zipCode feature and it worked! There was a catch though. The pantry owners wanted a feature within zipCode where if the student chose resident as their housing then the zip code would default to the campus zip code. I spent a good week or two trying to figure this out with *ngif() and other angular statements. Since the sprint ended and it is getting very close to our final class I decided to scrap that task and push my commit with a working base version of the zip code feature. All it is missing now is the auto-fill functionality. My plan is to take out a pull request within our repository to merge my branch to the master branch and hope that someone else may have a solution for me as to why this auto-fill feature is not working while they are reviewing my pull request.
From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.
From the blog mrogers4836 by mrogers4836 and used with permission of the author. All other rights reserved by the author.
Hello my readers. So as I mentioned in the very first blog for this semester, all the blog posts will be related to that class. This is a Capstone class and we are working in groups in a project that I am really looking forward to give my contribution.
But what is AMPATH? AMPATH stands for Academic Model Providing Access to Healthcare and is a healthcare partnership based in Kenya and created from different organizations. As far as I understood from my professor, there are multiple universities working on the AMPATH project. What we will be doing this semester is to help developers in Kenya as they are rebuilding the system. Excitingggg!!
Before the second sprint kicks in, here I am thinking about how did this last sprint go. Overall good I would say! My biggest disadvantage was that I had to be away for a week from the country and I kinda missed a few meetings but was able to recover in time without missing much information.
Starting working with AMPATH felt to me just like starting a new job. During sprint one we mostly got familiar with tools, the program we were going to use, our teammates, the systems we were going to use. We were assigned to different teams based on our availability. Fortunately I knew half of my team as I had worked with them in the past in other projects and was looking forward to work with the other developers as well.
In all this new process, I would like to point out one of the systems that i really liked and had not used before: Trello. It was very convenient to have all the stages of the First Sprint lined up in front of you (Product Backlog, Sprint Backlog, In Progress an Done). We started to organize our work and what needed to be done to increase our productivity.
Another step we took was pulling, cloning and getting familiar with the code of the project we were going to use. As a new MAC users (pointing this as I don’t know Mac too much) I had a few issues with running the code in my computer. Kristi though, was able to help me figure out the issue and solve it. .
Unfortunately our semester is a bit short for us to have big development getting done. However I am very excited for the new learning that I am and will be getting out of this project. I choose this project because I thought this way I could assist in an application that was real and had a good purpose.
I would consider this sprint as a research sprint where we researched and tried to learn ans study a lot about Karma ( a test runner for JavaScript), and JavaScript itself. Personally I hadn’t worked with it a lot and needed a few more blogs/chapters to read about it. I am really looking forward to the next sprints and to see what we will be achieving. I didn’t lie when I said it felt like starting a new job :).
From the blog CS@Worcester – Danja's Blog by danja9 and used with permission of the author. All other rights reserved by the author.