Author Archives: Nhat Truong Le

“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.

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

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.

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

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.

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

“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.

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

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.

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

“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.

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

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.

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

The IncreEdibles Sprint 2 Retrospective

This is the Sprint 2 Retrospective for team The IncreEdibles. We got assign to food pantry development, but we didn’t give any specific task. Big part of our team is design program and listen to the food pantry owner. There are two projects that we are working on, one is the make API that support other project where they can pull any information that they want. The other project is to work with Worcester State University food pantry.
As a group we decided to focus on WSU food pantry since we see more potential in this project. First, we want to know what the important features that costumers want. We learned that setup with costumers is not easy, not just to set the time and place for meeting. We have setup our communication on Slack, but most of the costumers are not in tech they don’t want to install complicate software. They want to have program where simple “plug and play”, so their energy can focus on what important to them. This is the problem that I think we always face with customers. We as developers before the meeting need to have set of question to ask, not all customers know what they want. We had meeting with Joanne, the professor who run the program. She wants to know who goes in and how much they take out the food, keeping track with the amount of food (by weight) is the main feature.
We took notes from the meeting and make email as direct communication that convenient for both parties. These features are important, but we must think of the design future features as program getting update. Features that they don’t think they need at this moment, that mean we must track data. These are sensitive data, we must be caution. The features seem not difficult as keep up with the weight of the food, but we want to have reliable program where it’s simple and easy to prepare/add feature.
There are few techs that our group need to know, OneCard swipe machine, we need to know that it is operative and how to implement to our program. How to export from the “sign up” Google Form. Export form that the costumer can export to submit to Worcester Food pantry. And most important is design our program where it is simple, clean and it do what it’s supposed to do.
Our next step is researching all the techs to make all priority feature work. Make a mock program, and present/sell it to the costumers. In this sprint we want to know how far we can get this program to work. There is other group in different section also look at this program, our problem is time difference and communication. If they have the same direction as us, we should find a way to divide the program into two parts that two group could work on. We find that the communication is one of the biggest problems even with members in the same group.

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

“Expand Your Bandwidth”

This is blog post on chapter five “Perpetual Learning”, the book build on software development is composed of two primary activities: learning and communication. “The Perpetual Learning patterns are applicable for your entire career, but with the apprentice’s emphasis on learning”. For new developer, learning is the most important part. In this “Expand Your Bandwidth” pattern, they are talking the most important process for most of developer. Expand your learning, in this continuous new information business. We will never stop learning, so learn how to learn without being so overwhelmed is extremely important. I think this is important skill to have, although everyone learns differently.

In software developer, there is no “know all” skill. We are learning as we go, we learned the basic skill at school and more specific as doing project/job. So how to learn while working. The book suggest that we develop expanding our ability to take in new information. “The discipline and techniques necessary to efficiently absorb new information, as well as to understand it, retain it, and apply it” and this is what really think is the CSS learning model. We must be active learner; we use the tools we must keep up with news/ learn new skills/ communicate with others. They also suggest that we understand when to Expand You Bandwidth. This is different to everyone, but if you test out your methods and see which work best for you.

I am agreed with most of the points of this pattern. Computer science is active learning, there are million thing we could learn. We need to know to pick and learn what we interesting and benefit to our career. I heard on a tech podcast, one way to learn is to try use technology for a week. After that move to different tech and see which one is for you.

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

“Sweep the Floor”

To continue with chapter four “Accurate Self-Assessment”, int his chapter we learn how to assessment ourselves. We learn our value in the team, how to work with each other. Everyone is beginner of craftsman at one point. We all at some point is a new apprentice on a project. This is where you’re unsure of your place on the team, and the team is unsure of you. This is not just when you are new software developer, its also apply to you are new to the group.

“Sweep the Floor”, a job not a lot of people want to do. Everyone in the group should contribute same amount of work, but that’s not always the case. Most people would want to be the best craftsman, but there are other important job that need to do. One way I discover while at school, to get group trust when you are newbie to the group is be active volunteer for work. We want to show our desire to work, it is the easy way for group get to know you. Also, a great way gets to know how the group operate/code design from bottom up. For example in the book, task as “maintaining the build system, production support, responding to maintenance requests, bug fixing, code review, eliminating technical debt, setting up the project wiki, updating documentation, acting as a sounding board for other people’s ideas, and so on.” This is do so for the group benefit. There are also a few negative consequences, your teammate also takes you wrongly as someone who doing job that no one else will do. You will not have opportunity to do changeling one. If we know our value, though our hard work we can earned their trust. With this mentality, we have the flexible to be in any environments. This also apply when there is other new addition to the group, you can understand them and show them the right way.

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