Category Archives: cs-wsu

“Concrete Skills” Apprenticeship Pattern

I am writing this blog post about the “Concrete Skills” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of this pattern, it is about dealing with concerns about seeking a role on a team but not having any practical experience. I chose to write about this pattern in particular because I find it relevant to myself at the moment. I am searching through job descriptions and they all seem to prefer certain areas of experience that I do not have. This is also evident in our capstone project. The “solution” section of this chapter in the book says to gain some concrete skills. I do have concrete skills; my aptitude is for mathematics, data structures and algorithms – computer science in general. It refers specifically to “tools” and “technologies”, though, and I know nothing about that. It becomes apparent when I work on the capstone project that my expertise has no application here. This sort of computer programming has nothing to do with computer “science.” There is no logical problem to solve, there are only tools and frameworks to learn how to utilize in order to accomplish some basic tasks. My past experiences have not seemed to have prepared me to be any better than anyone else at approaching these problems. It seems, then, that the “concrete skills” that I need are of a different sort. The chapter recommends looking at the CVs of others and finding a common set of discrete skills that seem important to become familiar with. This seems like a good idea. In order to gain some level of confidence about being able to perform on a team, it would be helpful to become familiar with the skills and common knowledge among the demographic. Rather than continuing to study computer science, there seems to be an additional field of knowledge that I am unaware of a name for, which is comprised of tools and technologies that are required for certain software development tasks. It seems like it will be important for me to gain some “concrete skills” in whatever field it is this might be.

From the blog CS@Worcester – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Craft Over Art

This blog is about another pattern from the Apprenticeship Patterns book. This pattern is about Craft Over Art. Choosing whether to add that extra feature that you think will impress your colleagues rather than focusing on what the customer specifies or want. This problem would occur to you more than you would think. We are not just programmers we are also artists. Creating beautiful, unique and creative applications are all within us, but if you are working for someone else, you might have to forgo of your creativity.

The book suggests focussing on delivering value to the customer rather than advancing your own self-interest. As a craftsman you are primarily building things in terms of the specification, working under someone and not indulging in your creative self. As craftsmen, we work for the customer. You need to do your best work in ways that place the interests of your customers over your desire to display your own skills or pad your resume. The book even says “If your desire to do beautiful work forces you out of professional software development and away from building useful things for real people, then you have left the craft.”  They said that the things we build for customers can be beautiful but it must be useful. That part of the process of maturation is developing the ability to sacrifice beauty in favor of utility when it becomes necessary.

I am split on this pattern. I kind of agree that we should do what the customer has asked us and enhance its quality, making it a software that can do almost everything that they needed. But, I also think that you can still practice art even if you are working for a company. You can inquire on your customer and see if they like what you are trying to do, but then again I see how this can conflict with the other software developers. Since you are not the only person that would be working on a project when you become an apprentice, there are things that others would think is not necessary to the software, so there definitely going to be things that gonna have to be agreed upon.

 

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

Sprint 4 Retrospective

Since the last sprint retrospective blog post, our team has begun to work on some of the components described in the first video. We are referring to the template wire frame layouts from the Zeppelin website, and we are working on form 1d in particular. It is still not very clear how to move forward and what to work on; the only way to make any progress is to keep focusing and thinking about what can be done and what to try looking at. The Angular Materials Design seemed to open the way into making progress. It established a much clearer way to begin the actual programming part of making the components. Everything we have done up to this point seems irrelevant now, but now things seem to be picking up in pace.

I have not begun writing any code myself, so my goal for the next sprint is to start writing code and finish an actual component. With the new angular materials design tool we are using now, this should be doable, since a lot of the code just comes from there, and it’s just a matter of implementing it by changing some small details. Progress has been slow, but progress is being made.

From the blog CS@Worcester – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Why doctors hates their computers?

Imagine you are a pilot, the world’s best pilot, and you are told “we are updating your control panel to make it more universal so that everyone can use it”. You show up to work one day and the entire control panel has now been reversed and is in Chinese. Chinese was never part of … Continue reading Why doctors hates their computers? →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Sprint 4 Retrospective

This blog is about our third Sprint. This sprint is a bit better than the last one. I finally think that we are making some progress towards the Food Pantry project.  During this sprint, we did a lot of organization and more planning. We have decided to put our board into Github.

We created a project board and created issues on github as sprint backlogs or product backlog. This process was not easy since I do not have much experience with creating issues on github. I also find it weird how we create issues and use them as a story, but it is actually pretty efficient when you got a couple groups working on a project. During this sprint, it was a little tough how to separate what is an epic, a story, or a task. We were deciding in the group what is considered a story or a task. Most of the story we made had to be broken into a task so that it is more descriptive.

Another thing that kind of made it hard is that we need to create issues in two github repositories. There is the internal repository for the cs-448 students only which are the two group and there is the LibreFoodPantry which is more for the more serious issues and is available to others. I was not sure what difference is written in the LibreFoodPantry and the cs-448 repository. For now, I think it is mostly tasks that are put on the groups repository and the major stuff like one card scanning are placed into the public repository.

Lastly, we got ourselves a magnetic card reader. We are gonna be using it to get the student or customer’s ID from their OneCard and use it to find their information from the database. It will be stored along with their information. If an ID does not exist in the database, we would prompt them to fill out the intake form. Then we store these attributes into a database. I think we should try to design the database along with the food pantry’s front end. Since it feels like there is not enough task for everybody to do, I would probably try to make a rough draft of database design.

In this sprint, I learned more about agile development. This time we are doing it in github by creating issues. I also learned that I should always try to break down stories that are very vague and making tasks from it. I also learned that the process into creating a project is not as straight forward as it seems, there is a lot of things that have to be considered like which programs to use, what server, and other little things that make up the project. This time, we actually got our hands to a magnetic card reader where we could swipe the OneCard to. We figured out that it takes the ID number that needs to be formatted before it enters the database. Hopefully, we can manage to get it working during the next sprint.

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

“Expose Your Ignorance” Apprenticeship Pattern

I am writing this blog post about the “Expose Your Ignorance” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of this pattern, it is about making known what it is that you do not know in order to learn. People have a tendency of wanting to appear competent and knowledgeable about any job that is expected of them, but faking expertise is counterproductive. It is more helpful to seek knowledge than it is to hide ignorance. I have been looking at job descriptions lately, and many of them are filled with expectations and preferences referring to things I have never worked with before or have minimal experience with. My aptitude is for algorithms and data structures; I have studied and developed and implemented them a lot, for years. When it comes to “technologies”, though, I do not know anything about software development. There are so many languages and frameworks and libraries and acronyms that I am not familiar with because they have never been necessary or relevant before, and now I see that a lot of jobs are expecting proficiency with these tools. I am used to solving problems without extra tools, so in order to work in a new environment where an unfamiliar tool is necessary, it is important to establish that I do not know how to do anything using the tool. Then, I can begin to ask questions and learn how to apply my skills to the new problem. During the CAPSTONE project this semester, for instance, I am required to work with the Angular framework, and a tool for making things with Angular. I have no practical experience with any of these things, so whenever I need to know something in particular, I put out a question, so then I can learn. Rather than going off and trying to learn how to use these utilities, it is much more efficient to begin by seeing whether anybody else around already has an answer. Sharing knowledge and asking questions is a much more practical way to learn about how to work in a new environment.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

“Read Constantly” Apprenticeship Pattern

I am writing this blog post about the “Read Constantly” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of this pattern, it is about spending more time reading about new material and ideas in order to stay in touch and learn about some new things. I think that this pattern is similar in many ways to the “Practice, Practice, Practice” apprenticeship pattern, because it is about taking the time and effort to become more familiar with a new topic. Reading research papers is an example given in the chapter. Any time I read about some unfamiliar topics, I always find that there is a huge depth of information that I have no idea about. Machine learning is one such topic that I spent a while reading about. After I had a good enough grasp of the basics behind the theory of it, I tried practicing implementing a basic multi layer feed forward neural network myself and have it classify some handwritten number symbols. Reading about it and implementing it was an interesting introduction into the field of machine learning, but continuing to read further into deep learning and the theory behind various learning algorithms, it becomes clear that there is still a ton about computer science that I have a ton to learn about. This is the case any time I look more than briefly into any broad topic. I was trying to implement a solution to a variant of the subset sum problem years ago and stumbled into NP-completeness and computational complexity theory. Constantly reading about new things is the only way to learn about different topics. The “problem” section in the book describes that there seems to be an endless amount of fundamental concepts that are unfamiliar despite proficiency in a programming language, and this is inevitable without reading constantly. Continuing to only practice in topics that are familiar makes it nearly impossible to expand into other fields without re-discovering them independently, which is unlikely when the areas are particularly advanced. Reading is like practicing learning. Proficiency in a language can only go so far.

From the blog CS@Worcester – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

The Long Road

This week’s blog is gonna be about “The Long Road” pattern. This pattern is all about traveling the long road. No matter how much you try to master anything, it will always be ahead of you. Mastery is a lifetime journey. You got to love whatever it is you are mastering. That is why they said, “Choose a job that you love and you’ll never work a day in your life.”

The book suggests valuing long term growth opportunities over salary and some sort of leadership or managerial role.  This long journey to become a master will bring you a rich set of skills. You will become skilled at learning, problem-solving, and developing a good relationship with your customers. You will learn to wield these abilities and technologies. If you go through this long road, you will realize and appreciate what being a software developer really is.

This journey would not be short. It will be a long winding road. You should have a goal. Being on this long road, you will be a software developer even when you’re old. This pattern is not gonna make you filthy rich like the other positions, but it will be rewarding. This pattern is not for everybody, there are more people who will take a higher position without blinking an eye. Everyone wants to achieve something big and probably make more money.

I don’t really agree with this pattern. I think that taking the promotion would be a better path. It is not every day that a promotion would happen or a better position would be available. So why not grab the opportunity. It will also teach you more skills since it would it is a different role, it will also have different responsibilities. You will also learn how everything is run in the company and not get stuck at just creating software. They do talk about in the solution, that this long road does not only apply to being a software developer but for any position.

This pattern is good if you see yourself doing the same thing 10 years from now. Although, in my opinion, that is not a good thing to do. I think we need a bit of variety so that we do not get tired of it.

From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

Since the last sprint retrospective, we have all finally begun to get an idea of the actual work that we are going to be doing. From the videos that were sent to us that we watched, it seems to be the case that we are going to be implementing some front end components like HTML forms and buttons using angular and javascript or typescript. Even with this in mind, though, we still have not begun writing any actual code yet. We are still in the stage of figuring out how to start on this project. Part of what was described in the videos included what appears to be an already functioning template of buttons and components that interact with the page but have no backend functionality, so my assumption is that we are expected to take this design and program the buttons to read the forms and pass the information to some function that sends it to a database. I am anticipating that we are going to need to read some of the existing ng2-amrs code so that we can have the frontend invoke the right functions written on the backend. This is all in my imagination, though; we are still not certain enough to know that that is what we are going to be doing. After trying to access the wireframe designs from the videos, they do not seem to exist in HTML – they are possibly just a graphical simulation of how they should interact. If this is the case then our work will begin first with building the pages and placing all of the components on them how they appear in the wireframe.

I think things would be moving more quickly if all of the groups were communicating more about what everyone plans on doing, since everything is going to need to be divided among the groups, and then within our group we will need to divide tasks further among ourselves. Firstly, though, we need to understand the goals better in order to be able to come up with smaller tasks to break them into so that we can work on separate pieces of it individually, then bring it together as a group, and then bring each group’s contributions together to complete the project. Progress in this regard seems to be happening very slowly. We have a vague idea of what needs to be done and we do not know what comes next, so until a lot more detail is figured out, there is only one thing to do, and that is to clarify what needs to be done and come up with some more things to do so that the work can be performed in parallel by multiple teammates.

At this point it seems like the groups have decided on one particular thing to focus on, and our group is focusing on one particular component of one page of a wireframe made in Zepplin that was demonstrated in the first video. We do not know what we are doing, but we are making progress.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

In this sprint, our group was divided into the Food Pantry project and the Foodsaver REST API project. Joshua was mainly working on hosting the Foodsaver REST API in Heroku. While the others were focused mainly on the Food Pantry software. I, on the other hand, was kind of in between both projects, trying to help out on the Foodsaver and at the same time help with planning the Food Pantry project. Our first meeting was pretty much figuring out what are some stuff that we are going to need to proceed on building software for the Food Pantry. We have decided that we are going to need the forms that they were using. This form is the one students would fill out during their first visit in the pantry. Since they were using Google Sheet to store all the information about a student that visits the pantry, we have also decided to take a look at a way to use Google Sheet API to connect to the software we are going to make. We have also decided to make our own Google Form mock just to see if that was all the information that we needed.

In our second meeting, it got a bit interesting. Remember how we were waiting for them to send the Google sheet mock with the attributes they want to collect? Well, we never received it before the break, and then they probably forgot about it during the spring break. After the break, I got occupied with trying to run the Foodsaver API and helping Joshua dealing with Heroku. Since Andy was the one who wrote the code for it, we weren’t quite sure how he set it up, but the Heroku hosting seems to be working. The Foodsaver API would appear when you go to the address Heroku gives, but when you click on the API, it does not return anything.

This sprint was somewhat uneventful for us I might say. There was a lot of waiting for the client, and a bit of miscommunication. This sprint was about patience. I learned that communication is really key to working on successful projects. There are going to be times when you would have to wait for the client to get back to you since they keep on forgetting to send things that you need to even get started. There was a lot of wait time for us, and we just kept on planning, trying to figure out ways to proceed with the food pantry project. If something like this ever happened again, I would probably not stop bothering the customers until we get what we want so that they can get what they want, and hopefully come to an agreement.

From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.