For this sprint retrospective there isn’t much to talk about because we were just going over the basics of how we are going to work together and setting up the server for our team to work on. During the sprint meeting we talked about the little things that we would like to change. Such as how we can change how our trello board works such as we put up all of the things we need to do and then put our names on the corresponding things we had done and did. Next, we talked about how we are going to push any of the code that we will be doing ourselves onto the git hub and when we should do it. We all decided to push it whenever we meet at least for now since we are still getting to know how each other works as a team. Finally, we went onto the google doc at the end of the meeting and just talked a reviewed the stories for ng-amrs. Just trying to keep ourselves ahead of the curve and started talking about how we can do this project. Throughout the week I just worked on the assignment leading up to setting up the server and getting to know my team more. Some of the things that did help me out throughout the sprints are the slack board and my teammates. For now I don’t see any issues working with my team they are all great people and we are testing the waters of how we should be coordinating how we work and what we should do.
This week I am going to write about the single pattern form the book which first starts off with “your first language” this pattern talks about people who first want to start to program or have very little experience programming so that only know one or two languages. In this pattern the problem that these people face is that they feel like they must write programs in a specific programing language and be up to the same standard as their teammates however they don’t know much or as well as the other people working in their group. This part of the chapter tells the readers that they should just pick a language and become fluent in it. No matter what language you choose the basic problem-solving skills that you get from it would be able to be used in other langue’s. One of the major tips that I believe works really well is that you don’t have to learn this language by yourself. Find someone who has mastered the language and talk to them about it. You should be able to ask them for tips and tricks about the programming language. Even though you don’t see them every single day if u see them once a week it can improve your knowledge of the language. Once you learn enough code to start writing your own stuff you can start running test, tweaking, and experimenting your code. With this you can learn what can break the code and learn the limit of the code. You also aren’t limited in learning the language you can also learn about how other people’s libraries work and over time you can test points to new library’s and see the functionalities of them. A really good advice that this pattern talks about is talk to people who have mastered multiple languages and get their input on how and why they choose whatever language to learn first. I like this pattern and what they talk about because with this people who want to start programming it isn’t something that you have to naturally gifted to be able to learn and understand. This shows that people like them struggles to learn these things and all they had to do was choose one program and find someone to be able to talk to about it. Everyone learns at their own pace and their own language so that way anyone can learn programming and its not hard to do.
Chapter One of Apprenticeship patters was a very helpful and interesting reading. For the most part I agreed with mostly everything this chapter has talked about. I love the idea that programmers are broken down into three different categories which are the apprentice, the journeyman, and the master. Within these different categories I still believe that I am an apprentice. As an apprentice I aim to keep learning new programming languages and to expand my knowledge for me, myself, and I. So, I am always looking for tutors, “masters”, and any kind of outside sources to help me learn as much as I can. Next stage would be the journeyman. These people are still trying to improve themselves and their knowledge of programming language however they are educated and experienced enough that they can talk to other journeyman and interact with other people. Finally, there are the masters who has reach the point in their lives that they are proficient enough in programming (however still learning because you can always teach an old dog new tricks.) these are the people who become mentors, teachers, project heads. They are the people that the apprentices and journeyman aspire to be and look to for help.
There was also a section of the chapter where it talks about the community of practice united and defined by overlapping values. Few of them are things I believe that a lot of new programmers should follow which is “A willingness to experiment and be proven wrong.” This is very important because we should not be afraid to make mistakes. With mistakes comes a learning/teaching experience. This shows you that there are things that you don’t know and that is fine because you are not supposed to know everything. If you are willing to make those risks then that just means that you accepted that you are not the best and is willing to learn from others. I also like the value that talks about “A belief that it is better to share what we know than to create scarcity by hording it.” I honestly think that this is something a lot of people should follow I understand with today’s society money rules the world. However, knowledge should not cost an arm and a leg to get. With education we should be able to get information from others to help each other out and to increase productivity with each other.
This is the introduction post for class CS-448
Finally, for this week I decided to write about Data Flow Testing. I found a blog site called Ques10 and there was a question about what is data flow testing. The blogger Ramnarth ansered the question by explaining what Data Flow Testing is. Data Flow Testing is a test that tells us that a programmer can perform a number of test on data values which are collectively known as data flow testing. With data flow testing it can be performed at two levels static and dynamic. Static testing is performed by analyzing the source code and doesn’t involve in running the source code. It is performed to reveal potential problems in the programs which are also known as a data flow anomaly. And with dynamic testing it looks at the path of the program from the source code and with this you would draw a data flow graph of the program select a critical testing area, then identify the paths in that data flow and test the derive inputs. He talks about how testing critical section on the data flow chart by breaking it down into paths and tests such as how we did it in class. Were we would look at the DU-Paths and look at all the edges and nodes to see if they make sense. I like this blog because it does involve some of the things that we did in class such as DU-Path testing, edges, and node testing. I like that the things I learned in class is also reflected into real life things we can do. I think data flow testing is just something we could be doing because it is just a bunch of tests that you run through so that way you do multiple test at the same time.
For my last week I decided to write about Don’t Repeat Yourself design principle. I found a blog called dotnetcodr and there was this blog about (DRY) written by Andras Nemes where he talks about (DRY). The idea behind (DRY) is that you should not add repetition of logic in multiple places in the code. He talks about the motto that you should be following “Repetition is the root of all software evil.” Repetition does not just refer to writing the same piece of logic in two different places but also the repetition testing, debugging, deployment, ect.
He then gives an example of repetition where he writes out the person and then where the live as well. In this code he hard codes everyone’s name and address. This way it is a very good example of reputation because since he is just copy and pasting whenever he would need to add or remove a person or address he would have to go back into the code and manually change it himself.
I found this blog to be very informative because it is very true you do not want to repeat yourself and the logic of a certain code in multiple places and multiple times. There are times where I do this a lot because I find it much easier to repeat the code since it is going to be the same every time I want to call something. I think the thing I get out of this the most is that I will start to try and not repeat myself when writing code. Also I can use this for future knowledge when I do write things that do call things multiple times and like it shows in the blog we can make stings that have getter and setters that would make a 40 line code down to a 10 line code which would save much more space and time as well.
This week I looked up Software Complexity blogs. I found a blog called “Five Reasons You MUST Measure Software Complexity” written by Jonathan Bloom. This blog talks about how sometimes complex code aren’t the best thing. He gives you a few methods developed for measuring software complexity. Which are Cycomatic Complexity, Halsted Volume, and Maintainability index. With these methods companies and use the information found by them to capitalize how they are writing the code such as. Greater predictability because knowing the level of complexity of the code can make it easier to maintain and show how much maintenance a program will need. The software risk mitigation which manages the software complexity lowers the risk of introducing defects into production. Reducing cost because with lower mateine cost the origination can spend that money on other things. It extends the value of the programs because excessive complex application causes issues. With this it keeps the software in cheack and keeping the complexity of it in check. Finally, decision support with this it allows the owner the information to tell if it is worth the cost of even fixing the code or if writing new code be worth it.
The benefits of software complexity analysis are that it improves code quality, reduce maintenance cost, heighten productivity, increase robustness, and meet architecture standards. Because of this a lot of bigger and smaller business try to add this analysis to make sure that they are not losing money because the software is too complex for what they need. I like this blog because it backs up one of my other blogs that talked about keeping code short and sweet. We should do code as basic as we can to keep things neat and organized and don’t make it crazy so that way we don’t waste time doing things we didn’t have to do. I think I will keep this in mind when I move on to my next step of my life. Keeping code nice and simple is the best way. I also think that I will keep this in mind when I am working on the final project for many of my classes because we don’t want to write too complex programs for our robotics class and our software constr class as well