Breakable Toys

 We can all benefit from writing random “toy” programs to push ourselves to the limit by setting artificial limits. — Donald Knuth, The Art of Computer Programming

If you can learn as much from failure as you can from success, you need a relatively private space to look for the loss. In balling acrobatics, a performer who tosses three balls will never progress if he has never tossed five. Those who spend hours picking dropped balls until their back hurts eventually get good at it. The same lesson applies to software, where software workers often need to step out of their comfort zone to try something they’re not good at it. It is by taking bold chances again and again that you improve your skills, that you learn and grow from failure after failure. Just as a three-ball-tossing performer does not throw five balls in a formal performance, software developers often make mistakes in new areas. Software developers also need a safe place to make mistakes. It’s terrible not to have such a safe place to make mistakes. The fear and unwillingness of software developers to make mistakes make them stuck in a rut, unable to learn from failure, and thus makes the entire software development industry staid and stagnant.

Other examples of the “crunchy toy” pattern include games like Tetris and Tic-Tac-Toe. One senior I know has a habit of using every new language he learns to create a game, blog software, and IRC client. The nature of the problem is to build a toy that contains learning something new and provides an opportunity to let you in a special environment to deepen the understanding of hand tools. The environment is not only safe because you are the only or most influential users, and, even to the most powerful commercial products, you still have room to serve you as a user’s needs better.

You still have to remember that they’re just toys, and that’s why they’re supposed to be fun. If they’re not interesting, then when the initial excitement is over, they’ll just become a dusty relic, and you’ll be able to focus your energy on what you enjoy building.

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

DD path graphs

Structural testing is based on the source code of the program under test, rather than the definition. This is known as white box testing, while functional testing is known as black-box testing.

Program diagram: For a program written in an imperative programming language, the program diagram is a directed graph with nodes representing statement fragments and edges representing control flow.

DD – path

DD path: Decision-to-decision path (Miller). Begin with the “exit” of the decision statement and end with the “path” of the next decision statement.

DD chain: A path of starting and ending nodes at different points in a directed graph.

Consisting of a node, the internality =0;

Consisting of a node, externality =0;

Consisting of a node, the inner degree > =2 or the outer degree > =2;

Consisting of a node, the degree inside =1 and the degree outside =1;

Length > =1 for maximum drill

DD – path graph

A DD-path graph is a labeled directed graph in which nodes represent the DD Path of a program graph and edges represent the control flow of the Path.

For a given program, many different program diagrams can be constructed, all of which can be reduced to a unique DD-path diagram.

It is possible to generate DD paths for programs up to 100 lines, and above that size, analysis tools are generally required.

The simplest control flow diagram is the DD path. DD can be thought of as belonging to the control flow diagram.

DD path definition:

Given a program written in an imperative language, its DD path graph is a directed graph, where nodes represent the DD paths of its program graph and edges represent the control flow between successive DD paths.

In fact, the DD path graph is a compressed graph in which 2-connected components are compressed into a single node corresponding to the 5DD path.

source：

Click to access 08-PathTestingCoverage.pdf

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

DD path graphs

Structural testing is based on the source code of the program under test, rather than the definition. This is known as white box testing, while functional testing is known as black-box testing.

Program diagram: For a program written in an imperative programming language, the program diagram is a directed graph with nodes representing statement fragments and edges representing control flow.

DD – path

DD path: Decision-to-decision path (Miller). Begin with the “exit” of the decision statement and end with the “path” of the next decision statement.

DD chain: A path of starting and ending nodes at different points in a directed graph.

Consisting of a node, the internality =0;

Consisting of a node, externality =0;

Consisting of a node, the inner degree > =2 or the outer degree > =2;

Consisting of a node, the degree inside =1 and the degree outside =1;

Length > =1 for maximum drill

DD – path graph

A DD-path graph is a labeled directed graph in which nodes represent the DD Path of a program graph and edges represent the control flow of the Path.

For a given program, many different program diagrams can be constructed, all of which can be reduced to a unique DD-path diagram.

It is possible to generate DD paths for programs up to 100 lines, and above that size, analysis tools are generally required.

The simplest control flow diagram is the DD path. DD can be thought of as belonging to the control flow diagram.

DD path definition:

Given a program written in an imperative language, its DD path graph is a directed graph, where nodes represent the DD paths of its program graph and edges represent the control flow between successive DD paths.

In fact, the DD path graph is a compressed graph in which 2-connected components are compressed into a single node corresponding to the 5DD path.

source：

Click to access 08-PathTestingCoverage.pdf

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

DD path graphs

Structural testing is based on the source code of the program under test, rather than the definition. This is known as white box testing, while functional testing is known as black-box testing.

Program diagram: For a program written in an imperative programming language, the program diagram is a directed graph with nodes representing statement fragments and edges representing control flow.

DD – path

DD path: Decision-to-decision path (Miller). Begin with the “exit” of the decision statement and end with the “path” of the next decision statement.

DD chain: A path of starting and ending nodes at different points in a directed graph.

Consisting of a node, the internality =0;

Consisting of a node, externality =0;

Consisting of a node, the inner degree > =2 or the outer degree > =2;

Consisting of a node, the degree inside =1 and the degree outside =1;

Length > =1 for maximum drill

DD – path graph

A DD-path graph is a labeled directed graph in which nodes represent the DD Path of a program graph and edges represent the control flow of the Path.

For a given program, many different program diagrams can be constructed, all of which can be reduced to a unique DD-path diagram.

It is possible to generate DD paths for programs up to 100 lines, and above that size, analysis tools are generally required.

The simplest control flow diagram is the DD path. DD can be thought of as belonging to the control flow diagram.

DD path definition:

Given a program written in an imperative language, its DD path graph is a directed graph, where nodes represent the DD paths of its program graph and edges represent the control flow between successive DD paths.

In fact, the DD path graph is a compressed graph in which 2-connected components are compressed into a single node corresponding to the 5DD path.

source：

Click to access 08-PathTestingCoverage.pdf

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective II – Reporting System

I am part of Reporting System group in this project and my job is to support and secure other system through keycloak. It is a 5-person team, and my part in this group is to implement a third-party system (KeyCloak), deploying the system (using docker) and help other system by embedding in their teams. Also help with other team tasks other than IAM system.

What I think that worked well in this sprint was that we were clear on what to read and what to look for. We understood the instructions and started the work that we thought it would be useful for us to know and learn. I was able to make some progress and secure the frontend of the system. Created a realm for the reporting team and added their users. This link is a good source for anyone who is new to Keycloak and wants to know how it works. There is information for everything you might need with keycloak.

https://www.keycloak.org/documentation

Again, like last sprint something that I would say it didn’t work well it was the amount of information we had to learn and go through. Because this is a project that is new to everyone, we were kind of lost in the beginning until we selected what worked for us and what not. It is risky when you are introduced with a new tool and you get lost in the sea of information. Again, overthinking some basic stuff that didn’t need a lot of time spending on it continued in this sprint too.

I think in this team I feel comfortable and able to communicate openly with my teammates. Most of the time we spent it working individually or in groups of 2-3. The examples that were provided to us for frontend and backend has helped us a lot in this second sprint. Also, when we assigned issues, we could have left it unsigned, as long as, all issues were done by the end of the sprint.

As an individual what I could have changed is helping my team more in other issues too and discuss the problems with my team.

In this second sprint we had enough issues for a team of 5 people. Most of the issues were about building frontend, backend, and figure it out how to make the reporting system work. Issues were mostly individual but also, we had ones that we developed in group. I was assigned to creating a docker container for keycloack and securing the example frontend through keycloack. I was able to finish both issues with success and the one that were in group too. Created a project file with all my documentation in GitLab with steps I followed, to complete the work I was assigned for.

We all wrote our descriptions on the issues, what we learned and how we are going to use it in the future. The link is provided in GitLab so anyone who comes after us or want to check on what we did, can use it, and help the others too.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/keycloak-configuartion

Read the readme.md file in the project to follow the instructions. Overall, this sprint was better than the first one and we got result. If the first one was trying to understand what was happening, this second sprint was more hands on the deck sprint, with real result and projects running.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance – Apprenticeship Pattern

This apprenticeship pattern is called expose your ignorance and the name for it is kind of straight forward but it is an important matter for a software craftsman. Often times there are many things that a software craftsman does not know and the goal is to find out the things they don’t know and learn about. They need to gain more experience with the new technology and not be shy about learning. Exposing your ignorance means being able to put your ego aside and write down things that you currently aren’t capable of doing so you can move forward and learn about them. Also when working with teams, it is important to communicate to your client or product owner that the work you are doing requires a learning process and don’t just tell them you know what the technology is already. This way you will build stronger relationships over time. The goal is to find a balance between not knowing a certain thing and being able to learn it.

I think this pattern is important for software craftsmen because often times people will become certain and expert with a certain technology and want to only stay on that path. They aren’t willing to navigate in other directions but become more experts in that field. However, for craftsmen we need to keep on being interested in the journey and learn more things that we are ignorant about. The goal is to be able to learn things and as the journey goes along, you will be able to master things but it shouldn’t be the end goal. The people who are experts are aiming to be masters at the technology and learn the most they can about it because that’s their end goal and it is not about overall learning for them. This is why craftsmen need to expose their ignorance and find out things that they aren’t currently able to do. Then the next step is to figure out how to learn it and create a learning guide that will work for them. Overall, this is an important pattern for craftsmen to improve their knowledge.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 2

Hello,

welcome back.

  In todays blog post I will be writing about my second sprint developing part of my universities food pantry website. My team recently finished the second sprint, during which we focused on developing basic skeleton code with basic functionality in place for future development. I and another teammate worked on the front-end development of the project while one classmate worked on the backend and another person worked on the IAM (Identity and Access Management) Communication among our group occurred mainly through GitLab and discord. At the beginning of the sprint, we mainly had documentation on the concepts we were to begin using and now we have progressed to having multiple branches of skeleton code developed.

During the first sprint, I had begun researching REST API and OPEN API with intentions on developing that area of the project. However, due to personal health reasons I was unavailable for slightly over two weeks and was not sure if a return to the project was possible. Due to these unforeseen setbacks, my team had to switch up task assignment. When I returned, another teammate was tasked with taking on the API design, which meant I was to take on the checkout guest front-end. This set me back even further than anticipated because now I had to switch to doing a completely different part of the development process. I began researching and completing tutorials on Vue.js which ended up being quite a bit to take on whilst trying to develop something presentable with Vue.js for the first time. I learned quite a bit and am happy with the progress I made as a student. I take pride in the development of the Checkout Guest front end thus far. It is linked below under the updatedFunctionality branch:

CheckoutGuest

For the second sprint, our team faced the challenge of applying the knowledge/concepts we gained earlier studying Express, Vue and keycloak and applying it. I was uncertain of how to approach the input validation of the student ID field but ended up modifying some code for an input field. I specifically spent some time verifying that the submit button was disabled unless an input of seven digits was entered. I assumed we would work with the WSU pattern of blue and yellow and designed in this way though I was uncertain of specific design layout and appearance that other teams planned to develop. A member of my team had contacted other teams with questions regarding appearance and then refactored according to the newly acquired information. A small hiccup with practical application is to be expected when developing with new frameworks but I still think we worked well despite the initial chaos of using these new frameworks, especially the combination of multiple frameworks.

To improve as a team, we should become more comfortable and fluid working with these new concepts and frameworks by continually practicing them daily in small increments rather than in large infrequent bursts of use. This would help to solidify these new concepts in our minds and keep them fresh. To improve as an individual, I would benefit from checking GitLab daily rather than a few times a week. This will help me to stay more on top of how the other members of my team are progressing and coordinate with them on challenges or setbacks either of us face before they become a major setback.

Overall, our team is doing quite well despite the setbacks. I am grateful to have the opportunity to work with such excellent developers who have great communication skills, are not afraid to ask questions. We work well as a team, and my teammates have been very cordial with any questions or comments about the design process outside of class hours. As someone who grew up dependent on food pantries like this one, I am honored to be able to dedicate my time to the development of this project.

Thanks for taking the time to stop by.

  • John Simolaris

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Nurture Your Passion

The key focus of this pattern is founded in the all too familiar scenario where you fundamentally enjoy the subject matter you are surrounded by at your work; however, the work itself gets in the way of your passion for the subject. An example of this would be suppose you are really passionate about software design and you enjoy taking your time making a solid product using good code. While that is your passion, and rightfully so, you may find your job is more concerned about functionality and speed. They might prefer you create shoddy code in a quick amount of time that works, rather than doing the job properly. As you might imagine, if your goal was to be employed to create solid code the way you always have, this might hurt your motivation.

The proposed solution to this predicament is to search around at your work and find something that properly interests you. Involve yourself in it and put in as much time towards it as possible. Outside of work, do the same. Find and work on interesting things that satiate your passion. I would continue the prior example to demonstrate how the solution works, except that its a pretty good example for why it doesn’t. I’m sure that in the right situation, the proposed solutions are good options. In situations such as above, however, it isn’t really possible to change what you do at work to better suit your passion. If you already work in software for the company, and the software isn’t up to your standard, where in the company can you go that is up to your standard?

Many companies have a fixed structure. Often, if you attempt to either move yourself around or change the structure itself, it is easier for the company to simply let you go and find someone else. That’s one of many problems that come from jobs being rare and workers being abundant. If jobs had to compete with one another for workers, overall conditions for workers would improve. As a quick aside: in my opinion, if the government weren’t trying its hardest to support major corporations (due to being bought out by them) and got rid of regulation that solely hurts small businesses, maybe in a more free-market economy where almost anyone can start up a company jobs could be abundant and would have to compete for workers. Speaking of idealistic views that might not actually stand up in real life, a second component to the proposed solution is to work on personal projects in your free time.

This is similarly not a valid option for many situations. Often, people simply do not have the time to work a full-time job and fulfill other responsibilities. Bringing up my example once again, you can work on quality software all week long in your free time, but writing code you know is bad and that you know could be better with just a little bit more time will always drain on you. Sometimes and for some people, it can be pretty easy to work on something you don’t enjoy. It can be easy to create something worthless and bad, but it depends on the situation and, more so, the person in particular. I personally find it extremely hard to work on things I don’t care about; even if I just have to do it badly.

It can be hard to have a strong passion for something and then have other people not allow you to do it. It isn’t even a matter of them letting you do it; it would be enough for them to do nothing. But often times, they directly work to oppose what your soul wants you to do. That said, you can’t just vilify them for it. You ended up in a bad situation but in the previous example, for instance, you wouldn’t be stuck. Maybe you misunderstood what they want or maybe they misled you. But if it’s a matter of your soul, so to speak, you can always leave the job. It isn’t always that simple; we have responsibilities and bills to pay. That’s why I personally believe that if you have the opportunity, build up your savings and investments. Sacrifice some of your standard of living now so you can afford to make a change like this in the future. Do your best to prevent yourself from getting trapped in life.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Record What You Learn

The section “Record What You Learn”, found in chapter five in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye, opens with the common saying “Those who do not learn from history are doomed to repeat it”. This section focuses on the practice of keeping some sort of diary to record what you learn throughout your career. Doing so has the benefit of creating a useful resource that can be referred back to at any time. It also has the added advantage of finding like minded individuals by finding common ground in what the both of you have learned. Both authors see these benefits since they also keep records of what they’ve learned. Oshineye uses two instances of the wiki, one public and one private, to share lessons he’s learned with others and give honest feedback to his own progress respectively. Meanwhile, Hoover kept a text file of references and quotes which eventually grew to such a size that he decided to publish it online for others to use. What separates this design pattern from another such as “Share What You Learn” is that “Record What You Learn” focuses on preserving the road you took to mastery so that you or others might learn something new from it.

While I haven’t reached mastery yet, I do generally try to write down what I learn. Admittedly, I partly do so I won’t fall asleep during lectures and I also often don’t go back to older notes. But I still notice some of the benefits like how generally more of the material sticks when I write down notes since I’m paying more attention to the material writing it down. And most of my older notes still exist, either digitally in my hard drive or physically in a stack of note books I keep inside box in the corner of my room. They’re still around and I can access them at any time which is one of the main benefits to “Record What You Learn”. So, when I’m talking to someone and they bring up a concept that I somewhat remember, I can open up my notes and refamiliarize myself.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

Nurture Your Passion

This week I decided to talk about Nurture Your Passion pattern. I think this pattern apply to a lot of people in different direction.  Our success comes not so much from what we do, but how well we do it. It also illustrates that regardless of your job or your position on the company ladder, you can be successful if you have passion for your work. Regardless of your current job bringing passion to your work can lay a foundation for success. Not just success in your current job, but success for every rung you want to take up the company ladder. You may hate your job now, but the attitude you take towards it can play a pivotal role in your career.

The book describes a case where You work in an environment that stifles your passion for the craft and what solution you can follow.  It is hard for your passion to grow when exposed to such hostile conditions, but there are some basic actions you can take to sustain it. Find something at work that interests you, identify it as something you enjoy, and pour yourself into it. Join a local user group that focuses on something you want to learn more about. Immersing yourself in some of the great literature of our field can carry you through the rough spots when your passion is in jeopardy. Moving into an organization that offers career paths congruent with your own can protect your passion.

These are some good advice you can follow. It is hard to find everything in one place but at least if you do something you like you are going to be happier. Remember passion is an emotion, a state of mind so the first thing you have to do is motivate yourself. Turn to another emotion to find the motivation that you need. Once you have the motivation you can apply the passion. Remember it is not about how you feel about your job. It is about putting passion into your work. Maybe you need to learn new skills, or you just need to fully engage yourself in your work.

References:


Apprenticeship Patterns by Adewale Oshineye; Dave Hoover

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.