Category Archives: Week 8

Apprenticeship Patterns – Learn How You Fail

People are going to have failures in their field of expertise at one point or another. There is simple no avoiding it. If someone claims that they have never made a mistake I am willing to bet that they are lying or have never even remotely pushed themselves in any way, shape, or form. The pattern Learn How You Fail in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye discusses failure and how to handle failure.

The key message this pattern is trying to convey is how to learn from your failures [AP]. People are always going to be weak in certain areas [AP]. The key is to identify where your weaknesses are and be able to recognize when you are heading into one of those areas [AP]. If you can do that, then you are heading in the correct direction. However, simply identifying where your weaknesses is only one step [AP]. Not taking it any further than that is like a dentist saying you have a cavity and then not repairing it. Once you have found an area of weakness you need to be aware of what is causing that weakness and trying to improve that skillset [AP].

Knowing your weaknesses also allows you to set realistic boundaries [AP]. It allows you to keep your goals in sight without getting too side tracked on other matters that you are probably wasting your time on [AP]. That is not to say you should totally avoid your weaknesses. You are going to have to tackle some of them to get where you want to go.

I generally agree with this philosophy. I have always viewed failures as things that happen naturally and in most cases are a good thing (unless there is a deadline). If you never make any mistakes how are you supposed to learn? Be able to recognize quickly when you have made a mistake so you can take advantage of it. Failure is a bad thing if you never take anything from them. You’ll just end up making the same mistake over and over again. The pattern also suggests keeping a list of your skills and limitations to help yourself recognize when you are heading down the right path and more importantly, when you are heading down the wrong path [AP]. I think keep a list like this is a great idea. It allows for people to more easily recognize what they are good at. I may think about doing this myself. This pattern provides some great advice that I certainly will try to follow and I hope others will as well.

 

Link to pattern in book: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch05s09.html

 

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Money Shouldn’t be the (Only) Motivator

While money is certainly important, and should be a consideration – it should never be the primary motivator for choosing a particular career or even for choosing particular projects or roles in a position. Making decisions based on financial considerations alone is a quick way to end up hating what you do and having little opportunity to improve your situation. Making the correct choices about what you use at motivating factors to drive decision-making can help make software craftsmanship a more rewarding and valuable career. Following some of the advice given by Hoover and Oshineye in Apprenticeship Patterns should allow a new or aspiring software craftsman to identify the motivating factors that drive success in the position and lead to a satisfying career.

It is easy to stay motivated when things are going your way and you are working on projects that you find engaging, fun, and adequately challenging without being overly difficult. The problem that the Sustainable Motivations pattern is hoping to address, rather, is when things get a bit more difficult. Sometimes it becomes difficult to see the passion in software craftsmanship. For example, sometimes in the course of developing the necessary technical skills to become a master craftsman, the aspiring develop will be faced with hurdles such as ambiguously specified projects, or shifting and conflicting demands of customers. It’s times like these, argue Hoover and Oshineye, where the motivation and determination of the aspiring craftsman are truly tested.

While I feel lucky to be actively interested and continuously challenged by my current work, I am sure that my luck will run out at some time in the future. I will be presented with a project that I find tedious, frustrating, and maybe even exhausting. I am confident in my ability to remain focused and motivated on working towards the end goal of becoming a craftsman, however. I feel that as Hoover and Oshineye mention, if I ever begin to have doubts they will easily be overcome by a need to continue earning money or the desire to maintain a reputation as a technologist. These motivators should keep me in the craft until my situation improves and passion returns as my primary motivating factor.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Breakable Toys

Problem

You work in an environment that does not allow for failure. Yet failure is often the best way to learn anything. Only by attempting to do bold things, failing, learning from that failure, and trying again do we grow into the kind of people who can succeed when faced with difficult problems.

Solution

The solution the text offers is to build “toy systems that are similar in toolset, but not in scope to the systems you build at work.” Experience is build upon failure and success, having a more or less private space to seek out failures in order to learn from them. When implementing this pattern, the text suggests making your systems relevant and useful to your life as an apprentice. Suggestions include building a wiki, calendar, or address book.

“Breakable Toys is more about deliberately creating opportunities to learn by stepping beyond your boundaries and single-handedly building complete software projects.”

The projects you take on may be excessive and not complete but having the ability to fail, and find solutions trial and error will benefit you in the long run. Maintaining a wiki leads you to learn about things like HTTP, REST, parsing, web design, caching, full-text search, databases, concurrency, and possibly data migration. Other forms of breakable toys include games like Tetris and Tic Tac Toe, blogging software, and IRC clients. The intent of Breakable Toys is learning new things and allowing yourself to learn from roadblocks that might occur.

The idea of building a wiki to record what you learn is similar to this blog in that I am tracking my progression as an undergraduate seeking employment and mentors to help become a software craftsman. I’ve been using WordPress for some time and have slowly learned more about PHP, HTML, CSS, and SQL databases. I think the Breakable Toys pattern is an essential part of learning new and complicated projects. I liked the idea of creating other tools that help you in other aspects of life, like making your own calendar or address book. My first angular 2 project could be considered a breakable toy, I didn’t know anything about Angular and very little about Javascript but having the time to sit down and create a workable web app helped me learn about something new and has prepared me more for the Angular project I’m working on now.

The post Breakable Toys appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

HTML (Hypertext Markup Language) and CSS(Cascading Style Sheets)

HTML which stands for hypertext markup language and CSS(Cascading Style Sheets). Are what i decided to read about since with our final project with the typescript and angular , we will need HTML and CSS for it to work properly. Also giving it a better graphical look or user interface with the help of CSS.  Hope you viewers enjoy the article.

 

HTML stands for Hypertext Markup Language, and it is the most widely used language to
write Web Pages.
* Hypertext refers to the way in which Web pages (HTML documents) are linked
together. Thus, the link available on a webpage is called Hypertext.
* As its name suggests, HTML is a Markup Language which means you use HTML
to simply “mark-up” a text document with tags that tell a Web browser how to
structure it to display.
Originally, HTML was developed with the intent of defining the structure of documents like
headings, paragraphs, lists, and so forth to facilitate the sharing of scientific information
between researchers.
Now, HTML is being widely used to format web pages with the help of different tags
available in HTML language.

HTML Tags
As told earlier, HTML is a markup language and makes use of various tags to format the
content. These tags are enclosed within angle braces <Tag Name>. Except few tags,
most of the tags have their corresponding closing tags. For example, <html> has its
closing tag</html> and <body> tag has its closing tag </body> tag etc

A typical HTML document will have the following structure:

Document declaration tag
<html>
<head>
Document header related tags
</head>
<body>
Document body related tags
</body>
</html>

HTML Attributes

Attributes provide additional information about HTML elements.

  • All HTML elements can have attributes
  • Attributes provide additional information about an element
  • Attributes are always specified in the start tag
  • Attributes usually come in name/value pairs like: name=”value”

 

Now let get into CSS(Cascading Style Sheets).

CSS(Cascading Style Sheets) describes how HTML elements are to be displayed on screen, paper, or in other media. It saves a lot of work. It can control the layout of multiple web pages all at once

CSS is designed primarily to enable the separation of presentation and content, including aspects such as the layout , colors , and fonts . This separation can improve content accessibility , provide more flexibility and control in the specification of presentation characteristics, enable multiple HTML pages to share formatting by specifying the relevant CSS in a separate .css file, and reduce complexity and repetition in the structural content.

Separation of formatting and content makes it possible to present the same markup page in different styles for different rendering methods, such as on-screen, in print, by voice (via speech-based browser or screen reader), and on Braille-based tactile devices. It can also display the web page differently depending on the screen size or viewing device. Readers can also specify a different style sheet, such as a CSS file stored on their own computer, to override the one the author specified.

Changes to the graphic design of a document (or hundreds of documents) can be applied quickly and easily, by editing a few lines in the CSS file they use, rather than by changing markup in the documents.

example of Css

<!DOCTYPE html>
<html>
<head>
<style>
body {
background-color: lightblue;
}
</style>
</head>
<body>

<h1>Hello World!</h1>

<p>This page has a light blue background color!</p>

</body>
</html>

output:

Background will turn lightblue. try it!

Even though i know much about this article. It really helped me refreshed my mind on some stuff i forgot. now with no doubt , i know i will utilized this info to work better on my final project. Hope you guys also find this article very useful.

references : 

https://www.codecademy.com/courses/web-beginner-en-HZA3b/0/1?curriculum_id=50579fb998b470000202dc8b

https://www.w3schools.com/css/css_intro.asp

https://en.wikipedia.org/wiki/Cascading_Style_Sheets

 

From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.

7 Ways to be an Efficient Software Tester

Link to blog: https://testlio.com/blog/how-to-be-an-efficient-software-tester/

Currently as a college student majoring in Computer Science, I made the decision that I wanted to do a concentration in software development instead of data analytics. This is because my passion is to become a video game developer. While learning on the concepts of how software is designed and tested, I wondered what would be the necessary fundamentals of being an efficient software tester besides learning all of the test cases, techniques and terminologies. In this blog written by Willie Tran, he explains the seven tips on how an efficient software tester should be.

First, Tran identifies that sometimes, testing software can be chaotic and relates it to those who have experienced it in working in the field.

“Anyone who has been working in the field for any extent of time has experienced unreasonable lack of organization, poor scheduling, and daunting bug reports. Working through this mess is a task of its own. The best way to avoid this situation is to create order in your own habits. If you can create a common and consistent order for any work you touch, then you will set an example for your colleagues.”

Later, he highlights the tips that a software tester should do to be successful and efficient. These tips include organize everything, write detailed bug reports, write clear test cases, take part and communicate, ask yourself questions, be positive, and don’t test.

Organize Everything:

Creating an organize structure is important. When you create an organized structure to store all of the important details, it is easier to gather the relevant details and and perform the right testing strategy for the specific assignment you’ve been given.

Write Detailed Bug Reports 

Writing clean, detailed bug reports helps a lot, especially if you’re working in a team. This means that if you do this, your team will be able to understand more clearly on what it is you are writing and what bugs that you’ve identified in your project. Tran also adds that the three points that he stresses when it comes to writing these reports are:

  1. Write with detail
  2. Write with clarity
  3. Write for others

Write Clear Test Cases 

Don’t create long test cases. Try to simplify as much as you can to avoid problems and save time.

Take Part and Communicate

If you are working in a team, communication is key. This makes it so that testing is a team effort. If everyone knows what they are doing with each other as well as what their tests do, the testing process will be successful.

Ask Yourself Questions

Asking questions to your self is also important in a sense that you are checking yourself as you go to see what can you do to improve the tests and make them more efficient. Ask yourself what the tests are answering and doing.

Be Positive 

Testing with a positive attitude, especially in a team can be a huge factor and contribution. If your team sees that you have confidence in your work, everyone can become successful in the effort towards creating tests.

Don’t Test

Don’t test at all at the start. Once you make the tests, see what parts of the tests need improvement. Once you’ve done that, then you can test.

This blog by Willie Tran helped me understand on what an efficient software testing looks like. I picked this blog because I wanted to know more about what makes a software testing efficient besides knowing all the concepts of software testing. Knowing these tips will help me in the future to become a video game developer because most of the time, I’ll be working in teams when testing and creating game software. It will be important for me to communicate with my team and stay positive throughout the process when I work and test the softwares.

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

11/6/17 Software Development

Manifesto for Adaptable Software Development

This post is from the same blogger as last week’s. This post is about the manifesto of software development. The blogger gives a list of activities in to columns. The left columns are activities that faces challenges on the right column in software development. The blogger briefly goes over what they mean and gives an example of each. Experimentation instead of Specification: Instead of writing software program with specifications, write a software program with room to experiment and make changes along the way as needed.Example: Build a minimum viable product which allowed the programmer to delay decisions until the last responsible moment. Sound engineers build flexible software platforms to support cost effective experiments.  Evolution instead of Implementation: Instead of writing the system for implementations write it where there is room for it to evolve over time. Example: Domain modeling allows users to capture the essential aspects of an application while enabling future specializations. Adaption instead of modification: Write code that can easily be changed over time when needed, instead writing code with the modified changes and no room to make future adjustments. Example: Frameworks with several alternative components that may be chosen at a time needed. Extension instead of growth: Instead of writing a system for allowing the code grow overtime, create extensions making easy access to change the code when needed. Example: Plug-ins allow the user to add new features to an existing application without increasing its size or complexity.

This was an interesting blog. This blog how software development changes over time and how to keep up with the new changes. I like the example the blogger gives for each item on the list. They gave me an idea on how to adjust code when needed. This also give me a better idea of what plug in are. I’ve seen the word in the past on my computer when I try to run a game or a video on the internet. Shortly after that I am notified to update the flash on my computer and then usually the gam or video starts working again. Sometimes it does’t but that’s when the computer is old and outdated. Framework is something I already knew from this class and several other previous classes I took. This blog gave me a better idea on how frameworks can help make adjustments to coding over time, by being able to add and move parts at different times when needed.

From the blog CS@Worcester – My Blog by rens14 and used with permission of the author. All other rights reserved by the author.

Test Automation

Source: http://www.cigniti.com/blog/why-you-should-take-automated-testing-seriously/

This week I decided to write about Test Automation. I found a blog that talked about Test Automation. However I have never heard of test automation before so I had to do some research and find out what it was at 1st. from what I read online test automation is basically testing programs by using other testing software outside of the application itself. Test automation has been around ever since the computer industry has been out. Testing is not like what programmers do where they just run their code in different situations and different fields and input and outputs. These test automations were people who were dedicated to testing out software not like debugging it but running it though tests. This was a much larger and more complex system that even was to be thought of as a discipline worthy of study apart from programming.  With testing it was not just some AI testing the programming for incidentally, accidently but inherently for human errors and human interaction with the program. Test automation cannot reproduce the thinking that testers do when they conceive of tests, control tests, modify tests, and observe and evaluate the product. Test automation cannot perform sapient testing. Therefore, automation of testing does NOT mean automation of the service provided by the software tester. With Test Automation it should not be programmers testing out the code themselves and seeing if things work but people who have no idea about what they are working with or doing to test these codes and seeing how human action affects the program they are using.

This topic I read was kind of interesting because it talks a bit about what the first testing there was in the computer science world. To me I think that this kind of testing should be used a bit more because I don’t think that the people who are writing the code should test it all the time because there could be mistakes that you don’t notice and especially programs that are going to be used for the public having someone who has no idea about what code is and how to read it test out the program is useful. I think I would use this in real life situation when doing testing for code I write because like people say old but gold.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

Refactoring

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

behavioral vs Structural Testing

Behavioral

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

Podcast Highlights

https://www.codingblocks.net/podcast/clean-architecture-programming-paradigms/

This podcast, coding blocks episode 69, talks about various aspects of coding paradigms. So in this post ill summarize some of the topics i found interesting and insightful.

firstly, before their main discussion they talked about a question from a viewer that is definitely worth mentioning. The viewer is a project manager with the question: “if there is a room full of programmers working on a project, and another room with just a handful of programmers, which room is more productive and why?” The general consensus from each of the hosts concluded that there is a lot of valuable communication that gets streamlined through having just a few people, and blocked by having too many people. However, there is a certain threshold where obviously 300 people can do more work than say 50. So the answer really depends on the situation, which is up to the project manager to decide based on the project itself.

Skipping a few minutes down the podcast, around 40 minutes they start discussing interfaces. Allen states his basic rule for using interfaces, where if your coding something that doesn’t have any behavior, just a bunch of data, there is no reason to use an interface. In any other case however, if your coding something that has any behavior at all, it should be an interface. He says that even if you never use that interface for inheritance, the effort isn’t wasted in assuming that you might use it for something later. Joe jumps in by saying that using interfaces makes it much easier to change or debug your code with less volatility, overall if you don’t know if you should or shouldn’t make an interface, its probably a good bet that you should.

Later on towards the middle-end of the podcast, they start talking about the open closed principle. In this concept, changes can be made to code only by extending it and nothing can change the original directly, in this way all code is completely additive. This concept is very good because literally perfect base code is created and cannot be changed in any way, but still widely used. Joe remarks that some companies actually have a problem where developers are too scared to change base code that they may not fully understand, so they create a copy of it and only change the copy which leads to clutter. however, when done correctly, this concept is extremely efficient and easy because the coder doesn’t have to rewrite certain segments.

I recommend listening to this podcast, these guys are easy to listen to and know a lot about many different subjects of computer science. I’m sure you can learn something new with every podcast as these three hosts have both fun and educational banter.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.