URL: https://www.codingblocks.net/podcast/clean-code-writing-meaningful-names/

For this weeks blogpost, I will be talking about a podcast that I listened to about Clean Code. Clean Code is a book written by Uncle Bob, who has his own blog websites and talks about all different topics of Clean Coding. In this book it is by him, but each section will include thoughts and ideas from other people who helped create the book. This podcast was again talked about by my favorite Comp. Science podcast group so far, Coding Blocks. This podcast they specifically talk about meaningful names and what the book says about them, and their thoughts on them. Some of the stuff I agreed with and others not so much.      So the first thing brought up about clean code is the Two door idea. One door you open has clean code with only two WTF’s while the other door holds bad code inside of it with a lot of WTF’s. The first door is WTF in a good way, like WTF this is bad, while the second door uses WTF in a bad way, like WTF is this and WTF is that. After that they speak about their own thoughts on the Clean Code book  They go through different sections like liked and even bring up their own experiences of coding in the beginning of their careers up to now. After that their first code that they liked was brought up, “If a name reviews a comment, then that name does not reveal its content”. I found this pretty cool for a number of reasons. One, because I had always viewed comments as good since it explains what the code is doing and can help the user reading the code. Two, because my professor had just mentioned this quote in class, which I found pretty ironic was the first quote I heard about in the first podcast about Clean Code. Naming your variables can reveal the entire purpose though and can avoid disinformation. For example, if you name something that has the word list in it, and it doesn’t have anything to do with making a list, then that name doesn’t convey what it actually does. To go along with that example, remember to not use programming terms if it is not actually that. For the most park longer names do trump shorter names, but the links to the variable names should directly correlate to its scope. Small variable names in small block scopes and larger scope that that variable is available, the longer the name.      The next thing they talked about was the HUngarian Notation. The Hungarian Notation doesn’t prepend STR to available C++/ Old C programs or basics. Hungarian Notation is if you have a string name, it would b sN or a binary integer it would be bIisValid and that’s how you knew what the type was. This left problems though if someone changed the type and would leave the variable name. So you would have this bIisVariable and it was not a boolean or an integer. Hungarian Notation used to be valued but once it got multi lettered ones. It was especially hard when you had a long class name and you use the first letter as an abbreviation, you wouldn’t even know what that type is. It was simple for short primitive types back in the day and it couldn’t be done with today’s editors. It is also important to be names pronounceable. If they are pronounceable, it’ll be easier to explain to someone else. So, when you do nested loops with short names, you have to mentally map things out and if you have to do that your code is going to break down. If the scope is small, it is okay.      One thing they did mention that they had never thought about was that class names should be nouns and method names should be verbs. After this, the Factory Design Pattern was talked about and how it helps when constructors are overloaded. Everything talked about there was talked about sometime in class and I pretty much knew, so I will not go in depth about that topic. Lastly, they mentioned two quotes which I really liked. One was, that  the ‘hardest thing about choosing good names is that it rewrites good descriptive skills and a shared cultural background. The two hardest things about naming is that it can be off by a one error and cache invalidation. Naming is huge and hard. You have to be analytical and descriptive. This brings me to my second quote, “Rename things that don’t make sense when working in your code is good”. So when you see a bug, fix it.      A lot of really good points that i heard about were mentioned that I didn’t talk about with this blogpost. I definitely recommend anyone to listen since naming is such an important part of coding. I was really excited to listen to this podcast since I think Clean COde is a really important aspect anyone can gain from coding. It helps others and yourself when programming. I would really like to use a lot of these tips in the future on my code myself so when I am working with others, it will make the process go a lot smoother for all of us. 

URL:https://www.codingblocks.net/podcast/design-patterns-iterators-observers-and-chains-oh-my/

I know it may be a little redundant, but again like the past two weeks, my blogpost for this week will be about Design Patterns, but it will part three of four of the Coding Blocks Design Patterns Saga. This time though, the podcast did not focus on a specific kind of Design Pattern, but instead their favorites. In this week’s blog I will be explaining what was discussed on the podcast in detail, examples that go along with it and what I had learned from it. The three Design Patterns summarized today are Observer Pattern, Chain of Responsibility, and Iterators.     So, Observer Patterns maintains its dependences by notifying them of events by calling a method on the dependent. So in a nutshell when an object, which is called a subject in this case, maintains a list of its dependents and notifies them automatically of any state changes usually by calling one of their methods. The downside of this is that it can cause memory leaks. The class that is adding these response headers to this element has got a strong hold of these objects. If they are never disposed of or the garbage collector never gets them properly, all these objects just stay alive and never get taken away. An example is a notification example on your phone. It doesn’t care what someone else’s phone does with notifications. Notifications are sent from the server to my phone that I am subscribed to and I am notified of events in some way. I don’t care what happens on other people’s phones, but I respond in a certain. Visualize a pubsub environment, each responder of each element can happen independently from the other and it doesn’t matter how they respond. The other downside is the abstraction layer hopping. It is pretty much when the layers in between are ignored and shortcutting the system.      The second Design Pattern was Chain of responsibilities and there is no strong use case. So to start off with an example, you are part of a large company. THis company had a purchasing request. If the request was under $50, it is approved. If it is greater than $50 but under $250 the manager has to sign it off. If it is greater than $250 but under $500 the accountant takes care of it and if it is under $5000 but greater than $500 the CEO decides. So while this is a bad example of inheritance, you inherit from manager, manager inherits from accountant, and accountant inherits from CEO, so it is still inheritance. So you say if it’s greater than 50, pass to next part, and greater than 250, pass it up until you get to the designated area. What I thought was really interesting though, was when they mentioned a real world example which is exception handling.      The last one mentioned today was Iterators, which I had heard of before this. Iterators are a pattern in which the iterator is used to traverse a container and access the container’s elements but the pattern decouples the algorithms from the container. So algorithms are container specific and cannot be decoupled. It provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation and not exposing what that data is. A good example is the fibonacci sequence, since it technically does not have to do with any lists or arrays. When you want to sequentially traverse whatever that collection might be and you want to decouple that traversal algorithm away from the container, you don’t want the user to know how you’re containing that data. You still want the user to be allowed to traverse through the data. The consequence of this is that sequentially has to keep track of its location, and can have two loops accessing the same iterator.      The last thing mentioned in the podcast as usual was its resources which as always I love. It just gives me more resources that I cn had to my little library and will help me a lot in the future. Now honestly, this podcast was not as interesting as the first two for me. With the first two, I was learning about them in class, so it was cool to compare and contrast was was said on the podcast to what I was learning in my class. With these three Design Patterns, I hadn’t ever really hear of them, except iterators, and they just were a little hard to completely understand without a visual representation. I think like the other two though, knowing these Design Patterns in general will help me with my future coding and that is what is more important. 

URL: https://www.codingblocks.net/podcast/episode-16-design-patterns-part-2-oh-behave/

Like last week, I will again be talking about Design Patterns. Last week was the first podcast, specifically about Creational Design Patterns, of four that will be about Design Patterns. This weeks topic is all about Behavioral Design Patterns. Allen, Michael and Joe talk about three different kinds of Behavioral Design Patterns: Template, Strategy, and Null Object. Ironically my class started talking about Creational Design Patterns the week I had listened to that podcast, so it was cool hearing a summary about it, and then going more in depth with it. With this week’s topic, we have not yet talked about it, but it is a main subject that will be brought up in this class probably sooner than later.

So let’s first talk about Template Design Patterns. Template Design Patterns define the program skeleton of an algorithm in an operation, deferring some steps to subclasses. The example they give for this is that say a main method has an abstract class called Game. Inside that method you call to run, they have initialize some call, make move call, is end of game call and print winner. You can subclass this abstract class and override any of these methods and when you do that, the flow will always be the same. Essentially the flow is the same but each step can be customized by the sub class. This justs allows people when they write these other classes know that they are going to have to adhere to these guidelines, but then let them do what they want with these call methods. Pretty much Templates have you implement what you need and are very consistent. You need a header, body, and footer and every class that subclasses that class needs that same thing. It is more about a method, and a method already has a bunch of calls to other methods. The expectation is that you will override those other methods. Template Design Pattern is also referred to as the HollyWood Principle: Don’t call us, we will call you. The cause for this is because if you override that thing, when you call those abstract classes the wrong name, for instance, then it’s going to know based off of whatever the overrides were. It is just going to call those subclasses overridden, method call to it happens in the base class, automatically and never doing it in your own stuff.

Strategy Pattern is different and encapsulates a family of algorithms that are similar and makes them interchangeable within the family. SO pretty much, you can each of these classes contain just the algorithm and you can pass that class and change them around and call classes. The only thing is that these classe have to meet a common interface on execute method. Strategy Design Pattern is a pattern that ha probably been used before in people’s coding but was never thought about when creating that code.

Last was Null Object Pattern. If you want to provide a safe implementation that does nothing, Null Object Pattern is the right one to use. There are a couple reasons why Null Object Design Patterns are favorable. First, when you want to abstract null away from your client, you don’t want your callers to have to worry about null. You want to allow them to call your method and have it return something. It will always be safe and will work without a problem. AN example mentioned was that say you have a method and that method returns a list. Based on some condition, it does not return a list of anything in it for some reason. In that case, it returns an empty list, but in that way the caller could just automatically throw that into a for-each loop and try to iterate into it. Because the method does not call on anything, nothing happened and no harm no foul. “It almost leads you to feel safe” and kind of tricks you into not checking for null. They also mention how SIngletons and Null go together for Design Patterns. This was a bit confusing for me to understand so I am unable to go deeper into that topic. The way they end with Null is that is cleans up your code and gets rid of all the null checks. The simplicity of it is its beauty and the need for doing if-statements is lowered.

To conclude, I actually liked this podcast a lot more. Even though I liked the first podcast, it was really long and I had a hard time following along to what they were saying. There was just a lot of information to take in. This podcast was shorter by a half hour but I was able to retain a lot of it. For obvious reasons, I chose this podcast because it is what we are/will be learning in class. Although I feel like I understand a lot about what we are doing in class and what type of designs are doing what, it is nice to listen to a summary of it. In class I am learning specifically what code would look like if using that certain Design Pattern, while in the podcasts, I am learning about what they are capable of, and what they do as a whole. Also, of course, I am excited on how to use this Design Pattern in the future and how I will be able to implement it into future coding projects.

URL: https://www.codingblocks.net/podcast/episode-11-design-patterns-part-1-you-create-me/

Design patterns, specifically Creational Design Patterns. That is what my podcast for this week is about. Design Patterns can be split up into four sections: Creational, Structural, Behavioral and Concurrency. From each of these Design Patterns, there are different types. Structural Patterns include adaptors, bridges, flyweights, facades, and proxy’s. An observer, strategy, and Chain of Responsibility go along with Behavioral. Concurrency carry Blockchain, Scheduler, and frameworks. Last but not least, Creational holds Factories, prototypes, builders, and singletons. All of these part of Design Patterns are crucial to learn and understand if you want to become a better program, which was my main reason for watching this.

Now to get more in depth on the types of Creational Design Patterns, getting a rough understanding of Design Patterns first needs to be figured out. In this podcast, one of the speakers state’s first, “When I see the word factory in a code base after snickering to myself, I know what that class does, what to expect when I open that file, same thing when I see a builder, adaptor, visitor. They have meaning which allows me to shortcut reading those files, and comprehend what’s going on at a higher level”. They are used to help programmers solve a common problem by creating and designing these applications or systems. Creational Design Patterns help make a system independent on how objects are created, composed and represented.

There are many more types of Creational Design patterns, but for this podcast, Factory, Builders, Prototype and & Singleton’s were all roughly talked about. Factory was the first of the four, which was in my opinion, the hardest to understand. With Factory, it can be split up into different parts: Factories, Factory methods, and Factory patterns. From there Simple Factories were talked about, and Abstract Factory patterns. Then at the end they mentioned the pros and the cons. The pro’s being that is adheres to the open-close principle and that they can be used with inputs, mostly switch statements. The cons were that it uses but mostly can use reflection quite a bit and that it can be extremely complex.

Builders were next, which are more about having the caller put together the objects. While factories really know how to put together the object, the builder on the other hand does not really know what the user wants the object to look like. The pros of builder was that it is a great way to build complex objects and has an elegant feel to it. The cons to it were that it can be a bit more verbose and that it is like adding an ingredient one at a time and can take some time. Prototypes were talked about very shortly which is where one creates a new object by cloning the existing object at runtime. Lastly, Singletons were talked about, which is a single instance of a class, the class that restricts the instantiation of a class to only one object. The downside for this was that decisions have to be made right then and there.

I was really excited to hear this podcast for a number of reasons. One being that, now that I have learned most of the basics of coding, it is really interesting to now learn about the difference designs and learn new ways that will help me become a better coder and programmer. It is as always so easy to understand these guys and I cannot wait to listen to their other podcasts about the other topics.

URL: http://www.codingblocks.net/podcast/episode1

So for the second blog, I did end up sticking to the same website and people I had listened to last week. The reason for this was, I had found a couple other podcasts I had liked, but they were harder to hear, and I just felt like I wasn’t as interested in hearing just one person talk. I really like the setup that Coding Blocks has with three people. So the topic I chose for this week was interfaces, which I know doesn’t completely have to do with computer construction, design and architecture, but from working in Eclipse from last week, I felt like it was just a good idea to watch another kind of  “back to the basics” video. Also, interfaces was just another topic I have always had a hard time understanding and I felt like it just helped me a lot with the understanding, just like encapsulation.      Now, just like last week, the speakers started off with a simple definition of what an interface was, “A contract of what you have to adhere to in your program, if there is something in the interface, you have to make it do something”. Pretty much, how you should interact with that piece of data. A good way that one of the men put it was that it is like two different kinds of people, there is Joe who visits his grandma, and the joe who goes to the bar. They are still Joe, but just different portrayals at the appropriate times and places. After that, they went on to describe the differences between an abstract class and an interface.  In an abstract class, you want to provide some implementation as part of it, but you want to make sure some concrete information is defined and you want that user of the class to add on to that with their specific use cases and needs. Storage is assigned for members that the coder wants to have available public or private, while interfaces don’t have that and only have a declaration. Also, abstract classes have to be inherited.     What I found really interesting about this podcast though is that when they mentioned when implementing an interface, it will almost always be public, but there is that slight chance that it isn’t. This is the explicit interface case. The example that was given was that there were two different interfaces with the same method. The class needs to implement both interfaces, but when the class can’t define them both with the same method, one of them has to be defined by default will be private. I hadn’t ever heard of that before, and It was nice how in depth the podcast went on about that.      Overall, another really good podcast. The setup of CodingBlocks just makes it very user friendly, and I am able to understand what they are saying without getting too lost. With each podcast I listen to, I feel a little bit more confident in my computer science grammar knowledge and just feel more prepared for when I do have to write more complex code. 

URL: https://www.codingblocks.net/podcast/episode-23-back-to-basics-encapsulation-for-object-oriented-programming/

I chose a podcast for my first blog post, and the reason for that is because I find podcast the easiest for me to understand and the most interesting. While there are many great blogs, books, articles, etc., sometimes I have a hard time following along and understanding completely what is being said. With podcasts, they are usually less formal and more ‘user friendly’. So the podcast that I thought to start off was with a very simple subject. After we had gone over some words in class a couple weeks ago, I felt like i needed to brush up on the programming terms, i.e why I chose a podcast all about encapsulation for object oriented programming. This podcast consisted of three men, who wanted to get “back to the basics” and get a refresh on the basic fundamentals. Now for a quick summary of what they talked about, it was legitimately all about encapsulation, and how it is portrayed throughout the different languages, specifically java, c# & java-script. They mention in each of these what is it and why it matters. So their basic definition was “Bundling your stuff up that only affects your scope so that people don’t have access to everything you do”. What they meant by that was what does the coder want people to actually see that they can interact with. Then they go in depth of the different kinds. The three main being Public, Private and Protected which is used for both Java & c#. Public is “the process of hiding internal implementation of the coders data and only exposing behaviors and properties that are wanted to interact with the people”. It is available to anyone that links that coders library and is the most open. Private is only available to those particular things that are in the class and are only to be seen by the members of the class that the coder is in. Protected is “anything that is in that particular class or is an inherited subclass of it and can use and access that same variable”. Then they also mentioned Internal, which is part of c#, which are “classes inside one’s assembly, DLL, EXE, etc, and those that can talk to one’s class but nothing else outside”. After explaining all the different kinds, they went on to mention the importance of encapsulation and having global variables is never good. Having global variables mean that

anything can be accessed and modified in any shape or form and many things can go wrong from having them. The importance of encapsulation is really stated and that they not only protect the application, but guarantee certain enter and exit points within it. Lastly, they mention others like protected internal, private protected and seal and encapsulation in java script. Overall, this podcast was a really good start to the many blogs, articles, podcasts, etc. that I will be viewing/ reading and talking about. It was very easy to understand, and the vibe from the podcast was very laxed, which i appreciated a lot. I’m really glad i chose this subject too, because I have always had trouble understanding private, protected and public and the importance of it and it was just one of those subjects that has been overlooked a lot. So, listening to a full hour podcast about it and its functionalities and importance really helped me grasp the concepts. Overall, I am very pleased. 

Hello,

My name is Mia and this my first blog for my new blog website. Here you will find articles, blogs, book and/or podcasts that I have found interested and my point of view on them. More is to come in the near future, Thank you for reading! Mia