Sprint Review 3/8

This week we have closed out another sprint and we are well on our way to being able to contribute to the open source OpenMRS project.

This sprint having gotten everything working the last couple sprints and beginning to receive work from our contact in the AMPATH project we were able to get more work done than in previous sprints. We joined the AMPATH Jira group where are the issues are listed and organized. This will allow us to take on issues and communicate with the team regarding those issues in the future.

During this sprint we were given a new AMPATH test server that we could use to work on and test our issues. We were all able to connect to this server for the most part. However it took some communication from the team, as well as a plugin that we found on chrome called allow control allow origin, to be able to successfully connect to and use the server.

Near the end of the sprint we were assigned an issue to work on for the AMPATH team. The issue was that when you logged into the ampath server it asked you for a location and you were able to type any nonsense and then it would save successfully as a location. For obvious reasons this should not be happening. Since we did not receive the issue until the end of the sprint we were not able to successfully resolve it before the completion of the sprint, and it has been moved to the  backlog for the next sprint.

I look forward to working with the code base and learning more about how these open source projects communicate and function as we work on and hopefully solve more issues.

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

Posted in CS-448, CS@Worcester | Comments Off on Sprint Review 3/8

Sprint Review 3/8

This week we have closed out another sprint and we are well on our way to being able to contribute to the open source OpenMRS project.

This sprint having gotten everything working the last couple sprints and beginning to receive work from our contact in the AMPATH project we were able to get more work done than in previous sprints. We joined the AMPATH Jira group where are the issues are listed and organized. This will allow us to take on issues and communicate with the team regarding those issues in the future.

During this sprint we were given a new AMPATH test server that we could use to work on and test our issues. We were all able to connect to this server for the most part. However it took some communication from the team, as well as a plugin that we found on chrome called allow control allow origin, to be able to successfully connect to and use the server.

Near the end of the sprint we were assigned an issue to work on for the AMPATH team. The issue was that when you logged into the ampath server it asked you for a location and you were able to type any nonsense and then it would save successfully as a location. For obvious reasons this should not be happening. Since we did not receive the issue until the end of the sprint we were not able to successfully resolve it before the completion of the sprint, and it has been moved to the  backlog for the next sprint.

I look forward to working with the code base and learning more about how these open source projects communicate and function as we work on and hopefully solve more issues.

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

Posted in CS-448, CS@Worcester | Comments Off on Sprint Review 3/8

The Clean Coder Chapters 13 & 14

This week i read chapters 13 and 14 in The Clean Coder by Robert C. Martin.

Chapter 13 is titled teams and projects, and like every other chapter in this book it is full of extremely valuable information. Although it is a short chapter it expresses the importance of working on a team and how valuable what he refers to as a “gelled” team actually is. Robert discusses the stupidity of assigning developers to work on more than one team and how important it is to work on one project as a unit and to make up for each others shortfalls. This is probably one of the most important things that we can take from this book because chances are that the majority of our time as software developers will be spent working with other developers on teams. My hope is that i will be able to work on a team that works as well as the ones that he describes in this chapter, a team that knows each others strengths and weaknesses and can make up for those.

Chapter 14 is titled Mentoring, Apprenticeship, and Craftsmanship. This chapter discusses how the majority of CS degrees do not actually prepare us for the real world of development. He discusses how the real world is often much different than what we are taught at university and many students are unprepared. He then goes on to talk about the idea of mentoring and how important that is to truly learning how to be a good developer. This is something that i agree with, nothing can beat one on one mentoring when it comes to learning how to develop good software. The author in this chapter discusses how doctors dont come straight out of college and start being a doctor. They first do a one year internship followed by a three year residency in which they are closely monitored and mentored. This is something that the CS community should definitely do, imagine how much better young developers such as myself could be if we were to get this much attention and help in learning our craft.

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

Posted in CS@Worcester | Comments Off on The Clean Coder Chapters 13 & 14

The Clean Coder Chapters 13 & 14

This week i read chapters 13 and 14 in The Clean Coder by Robert C. Martin.

Chapter 13 is titled teams and projects, and like every other chapter in this book it is full of extremely valuable information. Although it is a short chapter it expresses the importance of working on a team and how valuable what he refers to as a “gelled” team actually is. Robert discusses the stupidity of assigning developers to work on more than one team and how important it is to work on one project as a unit and to make up for each others shortfalls. This is probably one of the most important things that we can take from this book because chances are that the majority of our time as software developers will be spent working with other developers on teams. My hope is that i will be able to work on a team that works as well as the ones that he describes in this chapter, a team that knows each others strengths and weaknesses and can make up for those.

Chapter 14 is titled Mentoring, Apprenticeship, and Craftsmanship. This chapter discusses how the majority of CS degrees do not actually prepare us for the real world of development. He discusses how the real world is often much different than what we are taught at university and many students are unprepared. He then goes on to talk about the idea of mentoring and how important that is to truly learning how to be a good developer. This is something that i agree with, nothing can beat one on one mentoring when it comes to learning how to develop good software. The author in this chapter discusses how doctors dont come straight out of college and start being a doctor. They first do a one year internship followed by a three year residency in which they are closely monitored and mentored. This is something that the CS community should definitely do, imagine how much better young developers such as myself could be if we were to get this much attention and help in learning our craft.

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

Posted in CS@Worcester | Comments Off on The Clean Coder Chapters 13 & 14

The Clean Coder Chapters 11 & 12

This week i read chapters 11 and 12 in The Clean Coder by Robert C. Martin.

Chapter 11 is about pressure in the workplace. As someone who has not yet had a full time programming job this is not something that i have a ton of experience in so this chapter was extra interesting. I’m sure even assignments due in a small time frame cannot compare to the pressure of programming in a full time career under  a time restraint. The first tip that the author suggests is avoiding pressure altogether whenever possible. This goes back to one of the main points of the entire book, which is not committing to things that you are not one-hundred percent sure of. If there is no way to avoid the pressure, then the best way to go about it is to maintain your discipline throughout the pressure. He discusses how disciplines you abandon in times of pressure are not really your disciplines at all if you do not believe in them enough to maintain using them when it matters most. Maintaining your disciplines, remembering not to panic and communicating with your team are the best ways to get through a high pressure environment in the best way possible.

Chapter 12 is about Collaboration. At the beginning of this chapter the author goes on to describe the average programmer, someone who most likely does not enjoy working with people and much prefers machines. Although as he also said this is not all programmers, i completely agree and most of the time this is me to a tee. Working with other people causes so many complications. However as he also says not working with others can be catastrophic. As much as we would like to just sit by ourselves work on our own code and not have social interaction, that is just not possible and for good reason. He talks about something called collective ownership which is  a very good concept to have in my opinion. This means that as a team you take collective ownership for all the code in your department, not just the code that you have written. This creates a much better quality code, and helps people to work much better. Robert also talks about pair programming and how rewarding of an experience it can be and i could not agree more with this as well. Pair programming is an opportunity to learn so much from someone with more experience or to pass on your experience to someone who is new. Not to mention it can help you get past roadblocks in your code.

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

Posted in CS-448, CS@Worcester | Comments Off on The Clean Coder Chapters 11 & 12

The Clean Coder Chapters 11 & 12

This week i read chapters 11 and 12 in The Clean Coder by Robert C. Martin.

Chapter 11 is about pressure in the workplace. As someone who has not yet had a full time programming job this is not something that i have a ton of experience in so this chapter was extra interesting. I’m sure even assignments due in a small time frame cannot compare to the pressure of programming in a full time career under  a time restraint. The first tip that the author suggests is avoiding pressure altogether whenever possible. This goes back to one of the main points of the entire book, which is not committing to things that you are not one-hundred percent sure of. If there is no way to avoid the pressure, then the best way to go about it is to maintain your discipline throughout the pressure. He discusses how disciplines you abandon in times of pressure are not really your disciplines at all if you do not believe in them enough to maintain using them when it matters most. Maintaining your disciplines, remembering not to panic and communicating with your team are the best ways to get through a high pressure environment in the best way possible.

Chapter 12 is about Collaboration. At the beginning of this chapter the author goes on to describe the average programmer, someone who most likely does not enjoy working with people and much prefers machines. Although as he also said this is not all programmers, i completely agree and most of the time this is me to a tee. Working with other people causes so many complications. However as he also says not working with others can be catastrophic. As much as we would like to just sit by ourselves work on our own code and not have social interaction, that is just not possible and for good reason. He talks about something called collective ownership which is  a very good concept to have in my opinion. This means that as a team you take collective ownership for all the code in your department, not just the code that you have written. This creates a much better quality code, and helps people to work much better. Robert also talks about pair programming and how rewarding of an experience it can be and i could not agree more with this as well. Pair programming is an opportunity to learn so much from someone with more experience or to pass on your experience to someone who is new. Not to mention it can help you get past roadblocks in your code.

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

Posted in CS-448, CS@Worcester | Comments Off on The Clean Coder Chapters 11 & 12

The Software Craftsman (Chapter 1 & 2)

I am really excited that I am starting with a new book this week. The first chapter of this book is about what it means to be a software developer in the 21st century. I found it really funny when Sandro (the author) says that back in the 1990s if you wrote code that nobody understood, you were considered a senior developer. Wow! I wish that was still true today. I can easily write code that nobody understands; I even wrote a program that even I don’t understand when I look back at it today!

According to the author, seniority is relative. Having ten years of experience is not the same thing as having one year of experience repeated ten times.

To be a developer in the 21st century means that you must be proficient in many different technologies, wear many hats and be active in all phases of software development.

The second chapter of this book is about Agile. What is Agile? Agile is a combination of methodologies and techniques that can help teams and companies adapt to the changing nature of software projects and also reduce the risk associated with them. There are four goals of Agile which are summarized in the Agile manifesto and twelve principles behind the agile manifesto.

Of the twelve, I think the second principle is the most important: welcome changing requirements, even late in development. This principle I think is why we use Agile and is the most useful. In the traditional waterfall approach to software development, all of the requirements are gathered and the system is designed based on the requirements before any implementation or testing is done. And so if there are any new requirements, it is very hard to incorporate them into the existing design and would usually cost more time and money. All of these are avoided in the Agile approach to development; since the build software iteratively over small periods, we are able to catch any mistakes early on or incorporate new requirements easily.

The rest of the chapter goes on to explain why Agile has not worked at certain companies.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

Posted in CS448 | Comments Off on The Software Craftsman (Chapter 1 & 2)