For this post, my assignment was to read chapter 1 as well as the introductions for chapters 2-6 of Apprenticeship Patterns by Adewale Oshineye and Dave Hoover. We weren’t required to read anything in addition, but I was interested, so I read the first model from each chapter as well.

This book models a framework for someone to master the discipline. Mastering something can be challenging, and it is easy to give up when faced with some obstacles. Fortunately, this book looks like it will provide a good framework for someone like me.

I liked all the values presented in the introduction. These are a few of my favorites. (1) “Having a growth mindset.” Like many things I can glean from this book, this is a good quality to adopt for all of life when faced with any obstacle. (2) “Share what we know.” I believe that we are stronger when we work together over getting ahead by trampling others to get ahead.

(3) “Willingness to experiment and be proven wrong.” This perhaps was the most important thing that I learned working in groups last semester. Invariably I would go into a project with a range of quality of ideas. Some were good, but many were not. I had to have the humility to admit when an idea I was defending was not a good one. I grew as a person because of that.

For the “emptying the cup” metaphor, I related to the young philosopher quite a bit. I try hard not to be this way, but I find I can have the tendency to give my two cents when in the presence of someone who knows a lot more than me. I should be a lot more willing to listen and learn over speaking what I know. Usually what I have to say is nothing compared to what I can learn.

The advice to “be the worst” made me feel more at ease at the prospect of getting an internship or a job. I am overcoming a fear of being the worst developer at a company. This advice makes me think of it in another way, which is that I will grow so much more as a developer if I surround myself with people that are better than me

I appreciated the C.S. Lewis quote about seeking knowledge “while conditions are still unfavorable. Favorable conditions never come.” This struck very close to home for me, coming from a vacation where I had set maybe a dozen goals for myself. I ended the vacation only finishing a couple of them. I should have forced myself to set aside the time before the fall semester was over to start to accomplish these goals. If I had excuses during the semester, I should have foreseen that I would have excuses over the break.

I am excited to read more about each section. These topics that we will explore truly seem like they will be enjoyable to learn.

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

So excited for the start of another semester.

I will be publishing to this site regularly over the course of the next few months. And perhaps when I get around to it, I’ll update the layout of this blog, but we’ll see!

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

Self-documenting code is one of the biggest myth in the software development industry. It is common for someone to think that their code is pretty much self-explanatory, either because it is so simple or they are the author so they should have known it better than anybody else. However, not all of us can realize the fact that while the code is pretty transparent for ourselves, other would not have the aspect as we do despite how much experienced they are in the field. In this blog post, I would like to reason that code comments have a lot of value and documentation has more value than just explaining how functions / software works.

From that all of us can understand, code documentation is basically a collection of descriptions to explain what the codebase does and how it can be used. It can be a simple explanatory comment that locates above a function or a block of code, or a full fledged developer handbook, usually complete with prescriptive style dos and don’ts overviews of each part of the application, and approaches to the most common types of coding task. Like a lot of people would think, the general reasons why we think our code is “self-documenting” mainly because our applications can be boiled down into functions or objects that have one specific task and that task should be represented by the name of the functions or the objects and for me, this is not true at all, especially with large project with lengthy codes and potentially has functions that is named a little bit similar and have some common traits with each other. What we mostly don’t really think about is that code without comments is basically force the reader to go through the how it is implemented to figure out the why. With that being said, we can see that documentation are important to transfer the knowledge of what that function really do so that people can reuse it by just not knowing how it was implemented and that is fine. Not just giving user the instruction, code comments are also used to provide example usage of the code, provide the trade offs or pros and cons of the current implementation, marking the possible improvements in the code, possibly how to use it effectively with others APIs, and it serves as the most effective communication between authors and readers.

Another flaw of self-documenting code mindset that we usually think is that because we are standing in the developer-only point of view. To be clearer, what I meant is that we only seeing the value of documentation as allowing people to understand how the code works and documentation should be for every possible user. Developers only think about developers when it comes to software. It is true that a vast majority of the software users are end users and by having a good documentation can make the software more approachable by users that are not developers.

Article reference can be found here.

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

Javascript has been around for awhile and it is a simple yet powerful client-side language and now with the help of frameworks and platforms, it can also be used as a server-side language. Nowadays, more and more frameworks and platforms are released and that leaves us a tough decision to choose. Today, I would take Angular framework and NodeJS platform in consideration, since they are both powerful for front-end and back-end development. They feature rich cross-platform web app and enable developers to make a Single Page Application easier while maintaining Javascript as the main language, instead of AJAX, which is a whole new set of syntax to learn. Let’s dive into it.

Angular in general is an open source web application framework that is maintained by Google. It comes with two forms (or versions) which is Angular 1.X, which is usually referred as AngularJS, and the rewritten version of itself Angular 2+, which used mostly Typescript. With AngularJS, it can be added to a HTML page with the <script> tag and its general purpose is to help user in adding the dynamic views in the web application and integrate with Model – View – Controller structure, providing the flexibility to the framework. The application is usually built up form combining different modules together and more often, these modules have different logic and different purposes as the main module connect them by a general logic. The more you think about it, the more you will see how helpful this is. It speeds up the development process a lot since the application can be cut into pieces that does not have anything to do with each other for teams and then simply combines all of them by just some line of codes. Without it, imagine every time you write your component on others’ file and push it to git, you have to manually merge it without losing the functionality of other components. Not to mention it is so easy to use as it offers many features like directives, filters and automatic data bindings, which support us with optimizing our code.

NodeJS is an open source, cross-platform runtime environment for developing server-side and networking applications. While Angular are available in both Typescript and Javascript, Node can only deal Javascript. However, that does not make Node worse or better. According to Google Trends, after 2017, less and less people are interested in Angular while Node stays the same. NodeJS provides a rich library of various Javascript modules, simplifying the development process of the web applications to a great extent. NodeJS is highly scalable. By using one of two ways – Horizontal Scaling and Vertical Scaling (you can read more about it here), this helps improving your application performance a lot. Moreover, Node also offers Unit testing with any Javascript testing frameworks like Jasmin, server development with different types like HTTP server, DNS server, TCP server, etc. and better performance, since it uses V8 Javascript engine.

In conclusion, Angular and Node are both useful open source tools to build web app, while Node are more server-sided. This blog is based on this article.

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

In the early stage of software engineering, there was no such thing is composition or inheritance, it only exist in the context of object-oriented programming. When object-oriented programming was introduced, every one pretty much ignored it until user interface heavily based on it. One of the most popular object-oriented design principles is to favor composition over inheritance.  I have been asking people about the advantages of using composition over inheritance and the answers always suggest that it makes your code so much simpler and increase its flexibility. That is somewhat an acceptable answer, but I thought, to convince you, I would need more than just simpler and maintainability, so I found a this article that provide five reasons and I will summarize it.

Firstly, there are a lot of object-oriented programming languages out there, but let’s take Java for consideration, since a lot of developers (including the new one) know how to use it. With composition, when class A uses the functions of class B, it doesn’t inherit class B, but instead, it sees class B as a variable or an object. This is why it is called “composition”. It is suggested to use composition and that does not mean inheritance is completely useless. While inheritance is referred as IS-A relationship, composition suggests more of a HAS-A relationship. With IS-A relationship, an instance of the sub class to a function as a parameter, which accept instance of the super class, offer somewhat of the flexibility.

On the other hand, the fact that people prefer composition, especially in Java, is that most of the time it does not support multiple inheritance. To be clearer, sometimes you need to use multiple function, but you can only extend one of the two classes that offer these two functions, that would cause a lot of pain to go through. For example, if you want to read and write a file, you probably want to reference the two objects and call the function from there, while it is almost impossible to extend the read and write class at the same time to call their functions. Composition also offers more test-ability than inheritance. While you only need to create a Mock object that represent the composed class for testing, in order to test the sub class, you would need the super class to be available at the same time. Flexibility is the most important one to talk about. Although both allow developers to reuse code, inheritance is more likely to break encapsulation. Because sub class heavily depends on the super class, even a slightest change can alter or break the functionality of the sub class.

There are a lot more reasons to consider composition over inheritance and you probably will discover it by yourself on your way making your own program. However, it is important to keep in mind these reasons so that you would not make a mistake when you start developing.

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

In this week blog, I’m going to write about anti-pattern, mainly because I have seen the term a lot and think to myself that I should at least know something about it. This week blog is based on this article.

For a start, we need to understand what algorithm and pattern is. Algorithm has been around for a really long time and considered to be the most fundamental concepts in software engineering. The early concept of algorithm as it is written in “Fundamental Algorithms” by Donald Knuth, which was published in 1968, mainly provides Calculus-based proofs of its solution and code examples in outdated language like Algol or MIX Assembly. However, a lot of the subject was covered is still widely used today, for example like singly / double linked list, garbage collection or trees, etc. and it remains to be valid solutions to common software engineering problems for more than 5 decades and still going strong.

A “pattern” can be seen as a more general form of an algorithm, while algorithm may focusing on a specific programming task, pattern would offer more advantages in areas such as reducing defect rates, allowing an effective teamwork or even increasing the maintainability of the code. Four common patterns that are used in the industry are:

   – Factories: A concept in object-oriented programming that would eliminates the need for the creator of an object to know everything about it ahead of time, in other words, it would generalize the object as a square instead of knowing what details that contains in it. This pattern certainly simplify the program and encourage more efficient teamwork.
 
   – Pub / Sub: It is an async process between sender and receiver. Instead of having the sender to send the messages directly to the receivers, the sender publishes the messages to a queue. This pattern allowed multiple receivers to subscribe and retrieve those messages. The queue also have the ability to handles details such as transmission errors or resending messages. While factories pattern is more code-oriented pattern, pub/sub suggest to be more architectural in nature.

   – Public-key Crytography: A really useful and commonly used for security like in SSH or git server. It is a mechanism that allows two parties to communicate securely without interception without exchanging the secret encryption keys. Usually, each party maintain a pair of keys (public and private), and the public key can be shared anytime as needed.

   – Agile: A philosophy that establishes a set of guiding principle for software development to emphasize the customer satisfaction. It also embrace the need for flexibility and collaboration and promote the simple and sustainable development practices.

If a “pattern” suggest the solution to common software engineering problems, then should “anti-pattern” be the exact opposite? Anti-pattern actually is a term to establishes the concept of failure to do the right thing, maybe some of the choice in the development process seems right, but they would lead to problems in a long term. Wikipedia define anti-pattern as a common response to recurring problem that is usually ineffective and risks being highly counterproductive. As the sentence proposes that this is a common mistakes and they are nearly always followed with good intentions. Just like pattern, anti-pattern can be really broad or specific, depends on what we are considering.

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