Breakable Toys

-

In this apprentice pattern, I took a look at "Breakable Toys."  I think this chapter is really interesting since it encourages developers to gain as much experience as possible through failures within a field that only a small gap for error. The pattern first presented the contradiction where developers are not allowed to make much mistakes, but those mistakes are the one that teach us the most in order to be better. The author moved on to present a simplest solution, which is to create our own safe space to experiment with new technologies by doing personal projects. I think this is a must do for a lot of developers who wants to improve themselves as it not only gain experience through making a lot of trials and errors, it can act as some kind of record to show employer that we are competent at this particular skill, technology, or language. Then the author talks about the main thing of this pattern, which is “breakable toys.” The term sounds confusing at first, but it seems to just simply be a wiki, calendar, address book that allows ourselves to store what we learn so that we can look back when we forget about it. Another concept for “breakable toys” that the author mentioned are games like Tic-Tac-Toe, blogging software or IRC clients, which allows us to experiment and get knowledges from other.

The reason why I chose this pattern because I think this is essential for myself, as well as a lot of developers to know about. I do use a lot of “breakable toys” and I think they are pretty neat to have in a lot of situation. Until this day, I still have a lot of unfinished personal projects in my backlog and those I can always use as a reference when I could not remember how to solve a problem, and a lot of them are featured in my resume to shows employers what I am capable of, which significantly boost my position in this competitive field.

After reading this pattern, it made me realized the importance of “breakable toys”, and also provide me with some more brilliant ideas like wikis for problems or building a game of choice out of every language that I learn. This pattern also helped me see more about the importance of practicing outside of work environment, provide myself a much better opportunity to experiment and make errors without having to worry about getting in trouble.

Comments

Post a Comment

Popular posts from this blog

Mock testing

-
Mocking, or mock testing, is a really well known method in writing unit tests. With "mock" in English is to imitate or replica something, a mock object in programming can be seen as a place holder for another object that has the exact same behavior. With that being said, mocking would enable developers to use the mock object to simulate the real behavior of the real object in order to perform without having to worry about dependencies of the real object.

With a little help from mock frameworks that available for the majority of the languages, mock testings has become easier and more efficient to use. The first type of mock framework is Proxy based frameworks, and it would usually creates a mock object to be called by the test, and it can handle that call by delegate it to the original object, or do operations by itself. This type of frameworks is commonly used as because of its simplicity but still does have its own drawback. For instance, proxy based frameworks can neither …
Read more

Path testing

-
Path testing is widely used to design test cases. Path testing process has 4 steps, which is to draw control flow graph, calculate Cyclomatic Complexity, make set of paths, and then create test cases for the those paths, which would use this formula: E - N + 2P (where E is number of edges, N is number of vertices and P is program factor). Path testing usually use control flow graph, which would help developers find sets of linearly dependent paths of execution. Path testing also use Cyclomatic Complexity to determine the number of linearly independent paths and each path should be a separate test case.

Besides control flow graph, path testing can also use different techniques like decision to decision path, where control flow path can be broken into various decision to decision paths and collapse into individual nodes, and Independent paths. There are various advantages of path testing like making sure that tests are isolated and not redundant to each other, it helps developers focus …
Read more

Code coverage

-
Code coverage is a subject that has recently come up in my Testing class and it did catch my attention for its useful functionality. So what's code coverage? Code coverage is how much of the code that has been executed during the testing process. This process is not only check for every line of code, it also checks if all the branch of conditional and loops is covered. With this process in place, it would surely decrease the number of bugs.
With that being said, how would developers be able to apply this into their code? There are a lot of system and plugins out there that would help doing this job correctly, I will take JaCoCo plugins for Gradle as an example in this post, since I think it is a really good system that gives excellent reports. To enable JaCoCo, add this line to build.gradle:
 apply plugin: 'jacoco' 
What is greater about JaCoCo is that it let user define thresholds or conditions that the code coverage has to pass in order for the build system to return pass…
Read more