Author Archives: csrenz

Confront Your Ignorance

For this week’s blog, we will talk about confronting your ignorance from the Apprenticeship Pattern book. This will be a continuation from the last blog Exposing Your Ignorance.

Now that you have let your teammates know that you are lacking in some skills, it is now time to deal with your ignorance. There are tools and techniques that you need to master but you do not know where to begin. Some of them are things that are expected knowledge from you that everyone around you already knows.

So what should you do?

The book’s solution is to pick one skill or tool and actively fill in the gaps in your knowledge about it. How should you do it is up to you. Whatever works best for you. For some, the best approach is reading all the introductory articles. Others find that looking at the code is a better way to understand it. They also recommended asking around if anyone is also trying to master these skills or ask a mentor that already have these skills and if they are willing to share what they learned.

I find this chapter interesting since it was tied to Exposing Your Ignorance chapter. To do this pattern, you will need to expose your ignorance first. Using this pattern in isolation might lead to a culture where failure and learning are unacceptable and everybody just keeps to themselves. Also, your employer has certain expectations from you and might not be understanding of your educational needs that would get in the way of the successful delivery of its project.

Confronting your ignorance is probably one of the things that you will be doing over and over again in your workplace. Most likely, your first few months in the job would be a learning curve for you. Figuring out what tools they use, how it works, and how you could use them would be the first challenge you will face.

This pattern changed the way I think about confronting my ignorance. Usually, I do everything alone and try to solve things alone. But that seems like a band-aid solution to the problem. It is better to ask people who have mastery of such skill and see if you are doing it the right way, so in the future, you will be more knowledgable and can be a master of this skill as well.

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

This week’s blog is going to be about Exposing Your Ignorance from the Apprenticeship Patterns book. This pattern tackles the problem of not knowing other technologies in the workplace. The people that are paying you are expecting you to know what you are doing at the very least. Your managers and team members need confidence that you can do the job, but you are unfamiliar with other technologies. It happens to everyone. Especially if you are a new hire.

This pattern is very interesting to read. Normally, we do not show our weaknesses to others. We tend to keep it in even when we are having a hard time dealing with something. I would assume it also happens in the software development industry. No one wants to be seen as ignorant and be looked down upon that is why sometimes you try to hide these weaknesses. But this pattern is different.

This pattern suggests that you show what you are lacking.  Telling people what they want to hear is not a good way of building relationships and them having an impression on you. Tell people the truth. Let them know that you are getting the hang of it and are still in the process of learning. Reassure them with your ability to learn and not by lying to them that you know how to do it.

The most effective way to do this is by asking questions. There are no stupid questions. That is what every teacher would tell you. But it is not easy. Sometimes, people have expectations from you and it can be hard to ask “stupid” questions. There is also a sense of pride when asking a question. Sometimes you would look around you to see if you are the only one who did not understand.

I personally have this problem. I almost never ask a question. I always thought that I do not want to bother the whole class asking a question that seems like only I have a problem with. I would usually just tell myself that I would just look it up online and answer the question myself. After reading this pattern, I would definitely try to change that habit of mine.

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

Sprint 1 Retrospective

In this blog, I will be talking about our first sprint retrospective. My team is working on making free food pantry software.  In the first few days of class, we were doing research on different food pantry software. There was not much we could find that is open source and free which kinda sucks since food pantries are not for profit. Since these softwares are not free, we could not even demo them, therefore it was hard to get an idea on what this software should look like and what functionalities it should have.

After getting assigned into teams, our first sprint started. The first day we all sat together, there was some initial set up that we had to do so that we could communicate with each other and have tasks assigned to each of the members. We set up a task board using trello, joined the slack group for our team, and shared everyone’s contacts and git usernames. In our second meeting, we were trying to figure out where to start. We know that we were working on a food pantry software but we were not sure as to what we should actually be doing since other colleges are working on the same software as well. Then I saw on the slack channel that the other channel that they needed a REST API. So we started planning.

The first thing that we talked about is what functionality this REST API would have. The only thing we know is that we need this API to read a JSON file from the USDA’s website. After looking through the file, there was a lot of information about food and their expiration and some other stuff like tips on cooking or if they need to be refrigerated. Since we know that we are gonna be hosting this API we discussed on where to host it. There were a couple of options but we settled with Heroku since there is a free tier option although it might be a slower service since it has a thirty seconds time out when your API is not being used. Then we talked about which language we are gonna use. Researching about reading a JSON file, most of the tutorials were in Java and since we all have experience using Java, we have settled on it. The next thing was setting up an initial commit on gitlab for our project. Most of it was done by Sean and he was handling most of the task board as well. While the others work on figuring out how to host our API on Heroku.

To host a Java application on Heroku you need three things:

  1. Java 8* 
  2. Maven 3*
  3. Heroku CLI and an Account

After that, we researched how to read and write a JSON file. We are using JSON.simple to parse the foodkeeper.json file.

Steps I took:

  1. Download JSON.simple jar file
  2. Import the jar file into Eclipse by adding it to your project’s build path
  3. Added json.simple dependency into the pom.xml file
    1. <dependency>
          <groupId>com.googlecode.json-simple</groupId>
          <artifactId>json-simple</artifactId>
          <version>1.1.1</version>
      </dependency>

There are a few tips on reading the JSON file.  JSON file consists of array and objects so you just have to create an object or an array depending on what you are trying to get.

ex. Array [], Object {}

A JSON file might have something like this:

“sheets”: [
{
“name”: “Version”,

“data”: [

That means that there is an array called sheets, and an object inside the array called “name”. You can get to it by creating a JSON object first and then creating a JSON array like this:

Object obj = new JSONParser().parse(new FileReader(“foodkeeper.json”));

JSONObject jo = (JSONObject) obj;
JSONArray sheets = (JSONArray) jo.get(“sheets”);

We still have a lot to do, so hopefully, on the next sprint we could implement and get all the necessary information from the JSON file and have methods to return them as an object or as a JSON file.

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

Concrete Skills

This week’s blog is about Concrete Skills from the Apprenticeship Patterns book. It talks about what to do when you are looking for a role on a talented team that will provide you with better practice and enhances your learning, but sometimes these teams do not want to be bothered. Sometimes, having a new hire means you are going to be teaching them again from the beginning and these new hires do not offer anything to the company or team yet since they do not know how things work. This section of the book talks about how to deal with it.

In this section, they talked about concrete skills. They said that it is important to have some concrete skills so that you will be trusted to contribute indirectly until you start to gain their trust. It will help reassure your team members that you can be put to good use rather than being a burden that they have to babysit. They added skills like writing build files in various languages, basic web design, JavaScript, and knowing some standard libraries in the language of choice.

I find it interesting that the book suggests that you look at the CVs of the people whose skills you respect and identify the skills noted on the CV and determine which of these skills would be useful on the team that you want to join. Implement these skills on your own project, make sure that you know how to do them and how they work.

I completely agree with this pattern. I think knowing some concrete skills will come a long way when looking for a job or when starting one. You can’t always rely on your team to teach you stuff and they can’t also just ask you to do things that you have never done before right away since they are also working on stuff and not just there to babysit you. They will expect you to work and you have to prove to them that you are capable of being on the team. That’s why I think having concrete skills is good.

 

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

Unleash Your Enthusiasm

For this week’s individual apprenticeship pattern, I chose Unleash Your Enthusiasm. This pattern talks about how to handle the enthusiasm you have for work. As a software developer, you will most likely work as part of a team. Most teams are not as passionate or overly enthusiastic about technologies anymore. Most of them are focused on delivering the next project and trying to improve aspects of the development life cycle that are causing them hindrances. That is why sometimes, unleashing your enthusiasm can get people rolling their eyes on you. Some teams are particularly not welcoming of newcomers. You should be careful when unleashing your enthusiasm. It is best to observe the team first.

I found it interesting that unleashing your enthusiasm is in the pattern. I was never really an enthusiastic person, I am more on the analyze first before I do anything side when it comes to enthusiasm. I am actually envious of enthusiastic people since they just speak their minds out and seem to not care what would happen. I always thought that being an enthusiastic person was really great but after reading this pattern it makes sense that you should be careful when unleashing your enthusiasm. Some people do not want to get bothered while working and can get easily annoyed by people asking them questions all the time. But there are also the opposites who loves hearing questions and giving you advice on what to do.

This pattern has caused me to think about ways to approach different people in the team. I think most teams have a diversity of behaviors and some would be welcoming than the other. I think that trying to get the feel for your team before you unleash your enthusiasm would be the best solution to this problem.

I totally agree with this pattern. I think it is good to know that not everybody is willing to listen to you and that you should approach the team carefully. I think you should still be enthusiastic, just be mindful of others. This pattern would definitely help anyone, not just software developers in their life.

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

Why Doctors Hate Their Computers

This blog is about the article “Why Doctors Hate Their Computers” in the New Yorker by Atul Gawande. The article talks about the complications the doctors encountered after upgrading the electronic medical record system they used to Epic.

There were some tensions that caused the system to make doctors’ lives harder than easier. It became more political than technical. Staff and doctors had different views on what should be included. Now they added more questions that are “field required” that doctors used to skip that added more time to finish. Another tension was that different doctors can modify a patients profile. Three people will list the same diagnostic in different ways. Some will just list what is required just so the system does not alert them, some are not useful to the doctors who need to know a specific diagnosis.

I agree with Gregg Meyer. He said that “But we think of this as a system for us and it’s not,”  “It is for the patients.” After reading the article, it really seems like it was not made for doctors but for the patients. It was made in a way that every patient should have a record on every required field which made it harder for the doctors to do their work. The system was also used so that patients can log into it to look up their lab results, remind them of the medications they are supposed to take and read the doctors note to the patients. There are more patients than doctors so I think Epic was made so that the patients can easily access it. 

 

This article was long but it was interesting to read. As someone who is trying to work on the field of software development, I found it interesting how important it was to know the customers we are building it for. I think for us developers, it is easy to make a system that we could understand and use relatively easy, but without the perspective of the end user or the real customer for these systems, it might not be the same scenario for them. There are still a lot of people who are not tech savvy. This lesson of implementation of this system does not only apply to Electronic Medical records systems. For example, there is a show called Silicon Valley, where they made this software for a middle-out compression solution. It was the talk of the town. It was the fastest algorithm at the time. The developer asked his friends (other developers) to look at the finished product, and they all liked it. Then the time came when they were trying to release the software. They had ordinary people testing the software and they couldn’t understand how to use it and what it does. They had to teach them for weeks and there were only a couple testers who learned from it. Moral of the story was the same in the article, for us developers, we have to pretend that we do not know anything about our system sometimes and see if it is friendly enough for others.

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

Your First Language

This blog is about the first pattern in the Apprenticeship Patterns book by Adewale Oshineye and Dave Hoover called Your First Language.

This chapter was about picking your first language as a programmer. Picking your main language is difficult. There are so many languages out there that it is really hard to weigh the pros and cons of each of them. But you have to pick one since obtaining your first job will most likely depend on your proficiency in a specific programming language.

This chapter offers different solutions to this problem. One is to have an actual problem and solve it using the language that you chose. Instead of just following tutorials and examples in a book, solving an actual problem provide your first feedback loop. One other suggestion that they have is to write simple tests to check your understanding of the language. Since test-driven development techniques are so popular nowadays, it is impossible not to find a language that does not have a testing framework. It is a great way of learning how other people’s libraries work. One can always learn about a language and try to be proficient in that specific programming language, but it is still important to find a mentor.

I thought it was interesting how they kind of emphasize on having a mentor for your first programming language. Since we keep using different languages throughout the course, it was hard to find and settle on your first programming language. Not to mention, finding a mentor. Finding my first programming language is still a problem even now. I still cannot seem to settle on one language to master since each of them offers different specialties. This pattern has caused me to change the way I think. Since I always try to learn something new, I never really “specialized” on something. My mind is usually all over the place and I am always trying to learn new things. But, the problem is that I never mastered anything. I always seem to only learn the basics and then move on to different things. After reading this chapter, I want to try and settle on one language try to be better at it before moving on to other things.

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

Apprenticeship Patterns Ch 1 and Ch 2-6 Introductions

The book Apprenticeship Patterns by Adewale Oshineye and Dave Hoover is written for software apprentices who have experience in developing software and want to take it to the next level but need some guidance. The concept of the book is based on the medieval craft model where there are apprentices who are inexperienced/beginners who help the journeymen and the masters do their work.

After reading the first few paragraphs of the introduction chapter, I thought to myself, this system of apprenticeship is similar to what we have right now. You have the apprentices interns/new hires, the journeymen or the people that are already working are experienced, then the master or the manager but in a different way. Since now, you do not have to go through years and years of training to be able to do what someone in a higher position is doing. Sometimes people are hired as a manager right away.

I really like the part where they talk about what they meant by software craftsmanship cause they talked about the different core values not just in software development but also in life. They said that it is a “community of practice united and defined by overlapping values”.  One of the values that they talked about was a need to always be adapting and changing. This applies to everything. The world is constantly changing and we need to adapt to it or else we would be left behind. They also talked about the belief that it is better to share what we know. This is really important in the software industry. You can see how most Open Source Softwares are successful because it is made for the community so there are more people who are willing to work on it. These are just some of the values that were listed in the book.

The introduction in each chapter of the book was also enjoyable and insightful. It was full of philosophical stories. The first one was about “emptying your cup”. It talks about how you should open up yourself to the different approaches of a more experienced colleague. It is often hard to get rid of our habits. I think that even though we think we know what we are doing, it is important that we respect and acknowledge that others are more experienced than us and that we should be open to new things.

The introduction of Chapter 3 was the most relevant to me. They talked about how if you think you are good at doing something, there is always someone better than you. In high school, since I did not know much English and the school system here in America, they put me in classes that were easy. After a few months, I lost interest in school and studying. I was not learning anything. This puts me in a state of mind where I think I am better than my classmates and that I do not have to go to school. But then, the year after, they put me on more advanced classes and I was challenged but, at the same time happy to know that there are way more people who are better than me.

I really enjoyed reading the introductions to each chapter. It seems to prepare us and set our mindset in the right direction before we learn the different patterns that are in the book.

 

 

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

CS448 Introduction

This is just an introduction.

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

Test-Driven Development

For this week’s blog, I am choosing test-driven development what is and what it is not by Andrea Koutifaris.

Test-driven development(TDD) is a software development process that relies on the repetition of a very short development cycle. First, developers write a failing test case then produces the minimum amount of code to pass that test and finally refactors it to acceptable standards.

There are three processes that are often described using TDD: Red/Green/Refactor cycle.

Red phase

In the red phase, you write a test that uses a piece of code as if it were already implemented. Without implementation and not thinking about production code, this phase is where you concentrate on writing a clean interface for future users and where you design how your code will be used by clients. The Red phase is the most important phase and it is the rule that makes TDD different from regular testing. You write tests so that you can write production code and not test your code.

Green Phase

For developers, the green phase is probably the easiest part of a TDD. This is the part where you write code but not the whole implementation, just enough for the test to pass. Make all the alarming red on the test report becomes green. In this phase, you do not need to worry about violating best practices since we will do that in the Refactor phase. This phase exists to make your task simpler and less prone to error.

Refactor Phase

In this phase, you are allowed to change the code while keeping the tests green. But there is something mandatory, that you have to remove code duplication. In this phase, you can worry about algorithms and such to make the program better. This is the phase where you can show off your skills to your users.

 

I really liked reading this blog and I kind of liked the idea of Test-Driven Development. I think doing it this way creates more code coverage and thus fewer bugs later on. This kind of development is a bit unique to me since I have only done behavior-driven development so far. Test-driven development changed my mind in a way. I think that doing test-driven development is more beneficial, kind of like reverse engineering, we start from something that we know is gonna work then proceed from there.

 

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