“Record What You learn”/”Share What You Learn”

This is the last blog post for Individual Apprenticeship Patterns, I want to end with “Record What You Learn”. Most of what we were talking about was learning and how to apply it to the real world. I thought this is important because I am also doing this in daily basic. I keep making same mistake, and I learn to avoid it slowly. There are issue I just need to more practice to avoid, but there are mistakes I could have learnt. The book suggests that some platform to write down. Ade uses two instances of the same wiki, one for his private thoughts and the other for stuff he wants to share with the world. That is the good idea, some from my mistakes I didn’t want lets other to know about it. But after this book I wouldn’t mind others to check on my mistakes. They could help me to fix it or at least I will learn from it.

By said that, I also want to connect this to the next pattern “Share What You Learn”. Like I mention above, we could become a journeyman, the ability to communicate effectively and bring other people up to speed quickly. We learn what need to be share and what shouldn’t. It does not matter what you take note for yourself. Before share to others, you need to think if that will have negative effect to them or even to the team. This could damage the relationship of the group. They also suggest that shared as blogpost about the lesson which is soft of what we are already been doing. In blogpost we also could share our solution and have conversation with other.

This is my final thought of the book. I think this book is good on the guideline on the ethics side of the industry. I also have honest advice from experience people. They gave short good example/advice that easy to ready. I am will read the rest of the patterns and keep this book with me.

Advertisements

The IncreEdibles Sprint 6 Retrospective

This is sprint retrospective blog post number 6 for the IncreEdibles team. This is our final sprint blog, and we got the website to work. Which was our goal, there are a lot more we could improve, but this is good start. We got mostly front-end to operate, the form and report. The other jobs left are setup server and database.

As I mentioned last blog, my task is creating Ages of Household Members feature on the form. this feature take input on what are the age range of people in household. There are 4 age groups: from 0-4, 5-17, 18-64, 65 and up. I created these group to variable name ageGroup1, ageGroup2 …user will can options of drop-down menu from 1 to 10. We will have record of how many people in the household and their age range. I ran into issue where the list from drop-down is register as a string. That’s mean I can’t compare to the Number of Household Members; I must change input to integer. So, I changed user input to simple typing number. By compare input integer with Number of Household Member component, I can have warning sign to lets user know if they have same number of Members. The warning sign will disappear when they are same number. It was interesting. I learned a lot specially how to work with other.

There are few points I took from it, the way we fill the form is top to bottom. It is important that we create components based on how we fill it. A lot of components are standalone, also components are connect with other component. That may create conflict if we have separative developer create different things. Developer need communicate with each other to make component effective. One other thing would make the job easier is good design before implement. This way we know which component is important and is priority.

For final presentation, we will have meeting and create represent what we did and learned. I think the most important is to have system for the future class. We should have tips and system for the next team better production. We have issue with beginning, because we were the first to try out this system. This is the step can easily avoid by having a system. We did learn a lot from these roadblocks, how to communicate with product owner and customers, also with teammates. As this is the final sprint retrospective blog, good luck to you all with future career.

The IncreEdibles Sprint 5 Retrospective

This is sprint retrospective blog post number 5 for the IncreEdibles team. After we moved to Github as our main issues board, we list all the features/tasks in one place. In out front-end we have the website interface. This is what our customer sees on their computer, after customers come to the food pantry office, they will give OneCard ID number to the front desk. We are trying to implement the scan swipe into out program. It will automatically fill in to the ID box. There are three sections for our customers, first section is sign up “Intake form” for the first timer. They need to fill out the form with information such as zip code, household’s situation, number of people in household, etc.. We can to make this easy and clear as much as possible. We created each features of this form on Github, then each of us will pick one to work on. To work on these issues, we create its own branch with the name relate to these issues. By this way we can work and review each other work without create conflict to the master branch. I picked issue number 39 “Intake Form: Ages of Household Members”, this feature take input on what are the age range of people in household. There are 4 age groups: from 0-4, 5-17, 18-64, 65 and up. I created these group to variable name ageGroup1, ageGroup2 …user will can options of drop-down menu from 1 to 10. We will have record of how many people in the household and their age range.

The second section is the form for return customer, they will input ID number as usual. The front desk operator will input how much food they take. We will keep record the time and date, and how much food they take. By this way we can keep track on how much food we have left in the food bank. The third section is the weight form, this is for Theas Food Pantry operator, they can input how much food in come in. They can track how much food is come in and come out, and what is left in the food bank. We also need backend which are the database and webhost for our website. We go though these progress to create food monthly report to the Worcester County Food Bank. It is convenient our operator to print out report.

This is the most productive sprint we have yet. I feel really good about this sprint. Although I feel like we could get this going earlier. But design and planning is big part of software developer. Hopefully we will have decent program when the end of semester.

“Breakable Toys”

The third and final of “patterns grow out of an exposure to new information or a desire to acquire new knowledge: whether you’re practicing a new technique, building something in an effort to learn a new platform, or studying the source code of an innovative new open source tool.”. As this pattern “Breakable Toys”, is also important as 2 last blog posts. “Success is built on failure”, this is a well-known quote. But in the environment that sometimes does not allow for failure, we need to be both or leave some room for failure. We need to learn keep trying after failure, to be the kind of people who can succeed when faced with difficult problems.

Budget for failure by designing are good for side project. We want to have failure in the manage area, they need safe place to make mistake. When implementing the Breakable Toys pattern, make your systems relevant and useful to your life. This is good for our own personal project. In these project, we allowed to fail, we can try out new ideas and techniques. The person who get effect by these failure is us, not to others. The book suggests that a classic example of the use of this pattern build our own wiki. I think this is good idea, this require a lot of components work together: HTTP, REST, parsing, web design, caching, full-text search, databases … we can learn a lot from it. They need maintaining, so there will have thing to do, plus we could keep adding feature. This is great long-term project.

Failure and things go wrong are always happen in the tech industry. The important part is how to fix it and what did we learn from it. It is good for business to know this and leave some room to fall back in, like a backup system or good security team.

The IncreEdibles Sprint 4 Retrospective

This is Sprint 4 blog post for the IncreEdibles team. Since we have changed our direction of the project. We moved our plan to Theas Food Pantry; we also moved our stories from Trello to Github. We also got the OneCard swipe to work it our program.

On Trello, we have Product Backlog, Sprint Backlog, Doing, Review and Done. We placed all stories into these categories. By doing this we can assign and to keep track with our work. Product backlog is where the bigger features, big stories. Sprint Backlog is where we place all of the stories, we plan to do during the sprint. The last categories are for the progress and review. But by this way, it is difficult to know which story is task or epic stories. We are also work with other team; we don’t know which stories they are doing because we are not on the same storyboard. So we moved into planning on Github, because we are the first to try out this system. We are tester to set the rules of how the classes operate later. We came across a few problems while set this up. The tag feature in Github is good but we didn’t know where to place our stories. There are two repositories, we got confused to where to place stories on CS-448-Theas-Pantry or LibreFoodPantry/Theas-Pantry. After we test and try it, we think that LibreFoodPantry/Theas-Pantry is for big stories such as Epic and Story. And tanks are what we are working on individual, small tasks to make one story/feature. Other problem is branches, we are not used to work together on one project with many people. There are few people including me still confused about branch, but we will figure it out after using it.

Github have many positive features we need to work on this project. We now can create tasks and share between two groups. We can pick and working issue on our storyboard, also we can view other team board. We able to work on your own branch, without change master branch and review each other work. There is still confusion about the way we setup, but we are moving along. Hopefully we have the set of rules, work system so the future classes have better start. For next sprint, I hope to contribute more to this project. This is really way to understand how software development, we will meet roadblock as team communication , product owner … not just the technical side.

“Practice, Practice, Practice”

After “Expand Your Bandwidth”, we learned how to learn skill set. To make those skills better, I don’t know any other way than “Practice, Practice, Practice”. This is no secrets in life and coding is no exception. Once you learn, practice is the way that you can apply, and deeper understand from your mistakes. There is no point learn language without apply it to practice.

This is good point, if we take the time to practice our craft without interruptions, in an environment where you can feel comfortable making mistakes. When we don’t code with other people, we don’t feel pressure to get it right. When we make mistake, we just debug to fix and learn from it. The “deliberate practice” seem nice but we do not live in ideal world. Although it would be great, if there are program that learn from our coding and suggest exercise base on us weakness. It is better if we have stress-free and playful environment to practice, I would feel more comfortable doing in this area. Because I do feel the pressure coding in classroom. Although it is comfortable and less tress when we are coding alone. It is having its downside, to get better we need someone else to look at our code. Good code is not just the code can run or not. Code is good code when it is clean and efficient, by other developer look that our code. They could tell us where are our strong and weakness. We correct them and repeat the process; this is how we are getting better. As in the book suggest, each time should be a bit challenge. Take what we have learn and devise it to the next level. As I am graduating soon, this is one of my goals. I will try to practice more as well as learn new technology.

The IncreEdibles Sprint 3 Retrospective

This is Sprint 3 blog post for the IncreEdibles team. Since we have changed our direction of the project. We moved our focus to WSU Food Pantry, we thought that creating smaller scale is more effective to learn. We are trying to understand how the food pantry operating. We also need to know more about how our costumer operating. It is not simple, we had some difficulty on the communication. We don’t have direct communication to the costumer.
Since this project is new, even for our customer. It’s still updates and revolving. Our costumer doesn’t know how to implement technology to their project. We need to know what they are looking for, and what feature they are going to need in the future. We got to the first meeting with the costumer recently. That clear a lot more with our understanding with the project. Though our first meeting, we learned how our costumer set up. Although its simple, their way is not as effective. Which is good for us, we can help and problem solving. We run into few problems, as planning. First, our costumer problem with the technology as I mentioned. Second is the Onecard system, we want to know how to implement to our program. What happen when the card swipe? How to get that information to work with our program. It is difficult because it is also sensitive information. It deals with people information; the school don’t want this information to wrong doing. We want to build our program to be more effective and convenience. When person with one card come in, swipe the Onecard will display their info and make easy to input their food outtake. We hope the IT department with help us with that. Third, we still have question about the operation. After the 2nd visit we got more comfortable with your costumer. We feel we can ask our customer. Other food pantry team on other session is also working on similar project. We need to have communication with them, so we have work together. It is also not easy, since they have different timeline. And the online communication, Slack, is not as effective as in person.
In our next meeting we are planning into what are the next step. We will wait the team-fig response, so we know what teams are working on. And how to divide our work and who to help each other. I want to fully understand the food pantry operation. Then we have implemented important feature correctly. The next steps are design and build interface for the website. We want to have an interface design that simple and effective. We want to learn about manage database and print out report as customer want. We want to learn how developers work together in team and on project.