Author Archives:

Confront Your Ignorance

For this week, now that I have read through “Expose Your Ignorance” in the Apprenticeship Patterns, I continue on to read through “Confront Your Ignorance”, as they seem to go hand in hand with each other. To sum up this chapter, it mostly talks about the advantages and disadvantages when taking action to fill up our knowledge once we identified the gap.
The problem posted for this chapter is that while we have a lot of tools and techniques available out there that we can get our hands on, a lot of developers like us do not know where to start and a lot of common things that people know, we are expected to have those knowledge when we start working. I feel like this is the exact current state of a lot of new people who just got into the field and this chapter seems to be important to know about when we get started. The solution that the author presented, which is picking one skill, tool, or technique to actively learn about it, caught me off guard as I would never imagine it to be a simple answer. It is true that we have a start somewhere and using those as foundations to learn others. He then moves on to explain that to do whichever ways work best for us like reading articles and FAQs or constructing Breakable Toys and ask around for people who knows better or simply just people who are looking to acquire the same skill. The best part of this pattern is when he stated that we don’t have enough hours to get all the skill we need, and making trade-offs is necessary in order to get better. This is what I always think about whenever I get into learning something new because I might potentially forget part of what I know now and there will be more and more to learn once I get used to new skills. The author begins to explain that confronting the ignorance can be done in private, but then it would promote the bad habit of being failure or openly learning something in a work environment is unacceptable. And worse side effects that can be found by applying this pattern would be to let our personal gain for knowledge affect the team and we should keep in mind to separate them when we do.
I do agree with every point that the author put out on this pattern as I am sure that it will prove to be helpful when I am required to learn something new. With such simple solutions and tips, I think this chapter is pretty straight forward telling us to keep on practicing ourselves outside of work time, which still keeping up with the team progress so that we can become better without stubble upon failing what we are supposed to do and I think it is useful for new developers to know.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

For this week, I continued reading the Apprenticeship Pattern and the first one that I got into is “Expose Your Ignorance”. To simply explain this pattern, it encourages the readers to basically no being afraid of feeling ignorance and stupid when asking about what we don’t know.

The problem of this chapter is presented with an example of a work environment that requires the developer to be familiar with required with technologies, but we simply just don’t have any idea how to use it. I like how the author says that it happens to everyone because it is true that people can’t know everything and this would let the readers know that it is common, furthermore encourage them to not be afraid and expose their ignorance. With the question of how should one exposing himself/herself to be the most effective, the author gave us one simple solution, which is to show other people that you might not know about it, but you are willing to learn how to do it during the process of delivering software. Leading off as the author acknowledge the common feeling that the societies are increasingly dependent on the competence as a developer and we just have so many zones of ignorance, the author shows us that we still shouldn’t be afraid to tell people the truth despite feeling those pressure. According to him, to let people know that you are in the process of learning that particular technology is important to either build a strong relationship with people or build your own reputation of our learning ability. I would say that this is very true because the fact that people would appreciate the time that we put out to try to learn and use it properly rather than just lying about it and then forcefully use it the way it’s not intended to or finding a walkaround. The author then encourages us to ask questions and adopt the ability to learn as it is the easiest way to get to know something. It is rather an uncomfortable process, but it’s probably the most efficient way to learn in the end.

I can see myself completely agree with what the author said to exposing my own ignorance. I believe that it is what a lot of people in the past did in order to be at their position right now and I also believe that a lot of apprentice like us should not afraid to be judged and do the same, just to get ourselves better every day. I know that I myself do suffer from the fear of asking. Sure, I do want to learn, but I also want to prove to others that I know a lot too, and this chapter helps me to realize that actively learning is also another way to positively prove to other people, and I should not be avoiding it when needed.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Reflect as you work

For this week Apprenticeship Pattern, I chose to read about “Reflect As You Work”. When I read the title, my first thought is that this habit is pretty necessary, but it should not be too hard to have a chapter dedicated to it and turns out I was entirely wrong about it. The pattern starts with putting out the question of whenever a developer can consider themselves as “experienced” and how would that process be in order to reach that destination. The author then went straight to the point to explain how just reflecting our own work would be a best way for us to gain more experience. He explains several techniques like making a Personal Practice Map, which would involve writing down all the practices that we do during the development process and share with others, and mimic what they do in order to be better in the field. I think this particular technique would greatly help a lot of new developers in the field who does not know what to expect when developing and would end up doing what they think is the best without having a chance to consult everyone about that decision. The author also mentioned that this reflecting would involve a lot of observation on the practices and the processes of journeyman and master craftsman on the team, which I would say highly beneficial for everyone, not just the newcomers. He also gave out some examples of practices that was not discussed before, but then becoming more popular as everyone has proven it to be a lot useful. The author then concluded that people would start called us experienced if we hang on long enough and it should not be our goal to earn that title. Experienced should mean that we survive through long enough and our dedication to exploring, not necessarily how much we learned. He also made a really good point that anti-experience, or developing bad habit, can also happen too and we have to keep that in mind to set out goal to be “skilled”, not “experience”. This I would say the best thing I’ve read in patterns so far, since it is directly related to what I am doing as to earn the same amount of experience as anti-experience while doing personal projects alone, without any guidance of any journeyman or master craftsman. I can say that I do learn quite a lot from this pattern and I certainly would keep in mind these suggestions that the author made.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

At the beginning of this week, we finally reached the end of our second sprint, once a again, completing the back end for the LibreFoodPantry Approve module. My thought on this sprint is that our team did fall behind quite a bit on the goals we set out to finish at the beginning of the sprint due to the fact that we ran into much more problem than we expected and we don’t really have much time to meet up with each other like the last one. Nevertheless, we were still able to achieve a decent amount of goal and almost reach the point to be deployable as a product for just the back end.

List of what I accomplished during the last sprint:

– Successfully implemented CI/CD in every main repositories and get it up and running to check for merge requests build

– Adding all the required endpoints for the REST API system and set it out as a base for the front end to access data

– Successfully established connection between REST API and mySQL database on each member’s machine with a customizable config file to fit with multiple server setup

– Completely overhaul and clean up code for REST API to be more optimized and modular

– Front end wise, John and Kevin was able to make a few basic component to display guest information, made a lot of effort to learn about Material design, and experimenting with communication with the REST API

With a lot of work putting in developing the back end, I learned a lot about how to make connection between REST API system and mySQL. There are a few small things that I can pick up through this run too, like the differences between Docker Desktop and Docker Toolbox, making CI/CD script with different images, and so on.

During this run, it went really smoothly and we only ran into multiple communication issue, and small things during the development process like the date and time is behind when data point is fetched from the database because of timezone differences for some reason, or having to deal with numerous bugs that the default date object in Java caused. Other than those, I think we’ve done it pretty well. 

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

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.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

At the middle of last week, our team finally concluded our first sprint, working on user approving system for the LibreFoodPantry. Overall, I think our team did pretty good on doing a lot of initial setups and communicating with other teams to make sure we can have a consistency on data across databases. For me personally, I did quite a lot of work on setting up repositories, researching on making the back-end database, and helping my teammate, as well as people from other teams on the problems that they have that are related to our module.

List of what I accomplished during the last sprint:

– Setting up repositories, including ApproveGuestWebUIApproveGuestService, and isApprovedWebUI, which regarding to tasks like forking from templates, enforcing rules for making changes to the source code, and informing the team about that policy.

– Researching about how mySQL database can be initialized on Docker containers, import – export existing mySQL container for future usage, and communicating to it from outside of the container (wiki page is available at link)

– As I am more interested in getting the back-end to finish in the early stage of development, I helped one of my teammate, Tyler, to make documentation about REST API endpoints and further getting feedback and making suggestion with other teams on those endpoints (wiki page is available at link).

– With all that endpoints in place, I setup the schema to potentially be what the mock and the actual database looks like and getting appropriate changes to it to match with the Register Guest module (wiki page is available at link).

– Finally, I had a lot more time towards the end of the sprint than I expected, so I dug deeper in setting up Spring Boot for the REST API and making a few objects within the program to lighten the amount of work for the next sprint.

With a lot of work that is put into initializing the project, I also learned a lot. While I did have a chance to experience SCRUM on my last internship, this time we use Gitlab as a tool to log all of our work, which I really the simplicity but professional and effective, rather than Jira and Confluence, which are more corporate driven software. I also learn to operate Docker, which I delay on getting to know it for a while as I though to myself that virtualization is a most optimal way to go, and after the last sprint, both are now under my consideration for future projects. And lastly, I learn that communication is really important, especially in the early stage of development, as a lot of data structures have to be defined and unified among the teams.

There is also the excitement, and at the same time,  frustration, of planning what to do to optimize the time and the work needed to get the job done as we had a list of questions without a clear answer on where we should head to. Although on Gitlab, we got really few comments put up, the teams had a lot of face to face conversations to make decisions on problems, and that I think is a problem that we need to record more of our conversation during the next sprint. At the end of the sprint, we are able to finish every issue tickets that we put up initially and we got quite some spare time afterward so I think we did a really great job on what we set out to do and I think the more sprint that goes on, we would be able to take a much heavier workload.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Pratice makes permanent

Apprenticeship Patterns is a really interesting book to read and I actually learned a lot from it. For this week, I read about the pattern “Practice, Practice, Practice” and there are a few interesting things I found about it. The pattern starts with a quote by George Leonard saying that masters they don’t just get better by devoting in a particular skill, but they practice getting better and the it gets more enjoyable to perform basic moves over again once they are better. I can definitely agree on this as I think we all have been through a rough beginning of doing something, but when we are better, we would think back how easy it is to do those basic task and we would do those rather than more complex problems that we have to face later on during the process of mastering a skill.
Then the author went on to talk about practice is a long process and it has to be done without interruption, and in a comfortable environment of making mistake. At this part, it is interesting to learn that practice in software development can be in a stress-free and playful environment. For me, I always think that the best way to practice is to join a group project, and there would be one or another thing that would stress me out so easily like if I work in a small group or alone even on a small size project, at some point we would be overwhelm with the amount of work that we have to deal with, or too much concern about security, features, accessibility, etc. and after reading this chapter, it makes me question about my priority on different aspect of the program and maybe I should change in order to get better.
The author also brings up another interesting point is to try to do a bit different for each time we practice and choosing the right thing to practice is very important. In my opinion, I think that should be the most optimize way to discover new things and not to miss out any important things while we are still on the basic level.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Thoughts on Apprenticeship Patterns at first glance

Apprenticeship Patterns: Guidance for Aspiring Software Craftsman by Adewale Oshineye and Dave Hoover is a really fascinating book that I’ve read throughout the weekend for my software development capstone class. At first, the book seems to be a lot more intimidating as I did not know what to expect from it, but while reading the first chapter and the introduction of five other chapters, there are some interesting contents that I found.
For the first chapter, or the introduction for the entire book, it starts off with the author of the book trying to tell how he started with BASIC and Java afterward and failed to find any interests in them due to the fact that they are not really beginners friendly and I think this applies to a lot of new developers that are constantly trying to get into the field but unable to do it by themselves. He then proceeds to move on to tell about how he found his success years later in Perl and use that leverage to dive deeper into software development such as Extreme Programming and Agile, which I think would encourage new developers to be patient on learning the basic and reading through this book may put them in the right path. I really like this story as it holds true for myself and it reminds me when I failed to learn Pascal, which in that time was described to be one of the easiest languages to start, when I was younger, and it really made me question myself to fit in this field. The author goes on to explain what apprenticeship and craftsmanship as known by everyone and how it is applied to software development. I honestly like how he ties this concept into software development to describe it to be a really long-term process, as we have to learn from other people through being an apprentice and a journeyman to be able to “masterwork” their ability, not just putting together codes and it is certainly not common to think software development in this way.
When I read the second chapter introduction, I think that it has a really great story in the introduction to make help us put aside everything that we know, or empty our mind and be exposed to the material of this book because we might be able to learn something new, whether we are new to software development or not. It is a good transition into the main content of the books that can either help beginners to understand further about concepts of software development, or veteran to solidify these concepts.
With chapter three, the message from the author is pretty clear that it can be really scary to not know a lot at first and we can also find it intimidated to know that there are a lot of people that know much better about what we are doing and it is important to be able to learn from them.
For chapter four and five, I think the authors are trying to say that there will always be more to learn and improve even when we excelled in a lot of fields. I think these chapters should be the most relevant one for graduating student like us as we might know a lot already and even be very good at it, but there will also be a lot more to learn when it comes to work in a real project for a real company.
And finally, with chapter six, the authors suggest that all developers should have their own curriculum to always expand our knowledge in the field. It is important to be able to find resources to read and learn on our own time and it is up to us to catch up with never ending developing technology. It is certainly an interesting chapter to read about to be more efficient on improving ourselves.
Overall, I think it should be a really useful book to read and it certainly be useful with a lot of aspects that it covers for each chapter. I am pretty excited to read more about it.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Familiarize myself with LibreFoodPantry

For the project LibreFoodPantry, although it is pretty new, its main page already includes a lot of useful information about the project as well as related topic such as licensing, code of conduct, and the change log, which I think is really important for users, and developers, establishing professionalism.

What I found the most useful item in the website is the Principle behind the Agile Manifesto. This item provides a really brief, but essential core principles for developers to correctly used Agile. As Agile documentation can be a lot and frustrated to go through, I think that this would be an better way for the team to understand them and to make good decisions on the project. These principles pretty much emphasize the value of customer satisfaction, encourage the team to work together as much as the project requires, improving the work environment for developer and operation team, and at the same time cut major costs for the project.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Software Development Capstone

CS-448, or Software Development Capstone, is one of the last classes that I have to take before graduating this Spring 2020. I am really excited to be able to work in this community project LibreFoodPantry as it can be a great experience to be exposed to skills that are needed to get the job done in the Computer Science field like leadership, teamwork and Agile. I hope that I, as well as everyone that are taking this class can make a huge contribution in this project so that it can be in used soon.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.