Category Archives: cs-wsu

The Importance Of Clean Architecture

In Episode 68 of the CodingBlocks podcast,  they talked about the latest book, Clean Architecture by Robert Martin (colloquially known as Uncle Bob).  In the podcast, they explained the benefits of a clean architecture and why it matters. They said that the benefits of a clean architecture is that it can minimize efforts when it comes to adding features to the program.  Their functionality is maximized and changes are easy. It can reduce the number of people needed to write the software and adding features. They also added that there is no difference in design and architecture when it comes to a program. That the architecture should be incorporated into the design as well.  Throughout the podcast, they keep using the analogy of the Turtle and the Hare. They quoted that in the book, Uncle Bob added that “the only way to go fast, is to go well”. I think that this is a really good quote. Often we are bounded by the due date or time. In the podcast,

Also, in the podcast, they also said that “coding is easy, but managing our code when new features are added is the real challenge”. They said that maintaining cleanliness is better than cleaning it after the problems are piled up. Michael also talked about how sometimes, they say that the developers are not working. Which isn’t really the case. The problem lies in the architecture of the product since it does not support the changes that the product manager or client wants. They also talked about how sometimes company X comes to the market first but company Y is more successful because they were able to add more features faster than company X.

They also tackled the problem of rewriting the code, which most of us think would be the solution to the architectural problems. They said that rewriting is not the answer. Most of the time, we would rewrite the program to fix the problem. You will feel good about yourself when rewriting it since you are doing it really fast. But still not thinking about how to solve the architectural problem of your program. They said that the quality of your products should be taken seriously. Since developers are constrained by time most of the time, they forget the risk that are involved by being “fast”. Sometimes unit tests are not done and the code is not reusable anymore.

I chose to listen to this podcast because I wanted to learn more about Software Architecture and what are the benefits of having a good architecture versus just having a code that works. I  actually questioned Dr. Wurst about this, having done his first assignment for us. I asked him why we needed a better architecture even if the amount of classes in the program looks like a cluster. After listening to this podcast, it finally makes sense to me now. A product that have a better architecture is easier to change or add programs. In the long run, a better structured program is better and would be easier to manage than a program that is done “fast but not well”.

From the blog cs-wsu – Site Title by csrenz and used with permission of the author. All other rights reserved by the author.

UML Diagrams

 

In this blog, Mohamed Elgendy talked about why do we use model and some of the different kinds of diagrams used in UML.  Mohamed started off by explaining what UML is. He said that “UML is a set of standardized (Unified) diagrams, just like construction has front elevation, electrical diagram, floor plan, etc., UML offers different views of the same system.”. Which basically means that  UML is just a blueprint. In software development, we use this blueprint to better communicate with other people rather than software developers  in a way that they could understand.

In the blog, Mohamed explained different type and use of each diagrams and which team members are responsible for creating the diagram.

Class Diagram describes the structure of a system by showing the system’s classes, their attributes and the relationships among these classes. It display what interacts but not what happens when they interact.  The Class Diagrams are created by the Architects or the Technical Leads.

Component Diagram  are composed of one or more classes or interfaces. It is used to depict how various components of a system show dependencies. The Component Diagrams are used during the technical design and is also created by the Architect or the Technical Leads.

Deploying Diagram shows the physical relationship among the software and the hardware components in the system. In many cases, the component and deployment diagrams are combined in a single diagram. This is also created by the Architect or the Technical Leads.

Package Diagram shows the group of classes called “package”. Similar classes are grouped together if they do the same thing. Sometimes developers choose to display individual classes inside the package for better clarification. The Package Diagrams are created by the Architect or the Deployment Specialists.

Statechart Diagram describes the behavior of a system where  it shows the possible states  an object can be. It is typically drawn for objects that typically have a lot of dynamic behavior.  Statechart Diagrams are created by the Architect.

Object Diagram depicts a complete or partial view of the system at a specific time. Object Diagrams are created by the Developer.

Sequence  Diagram displays the sequence of events between entities of the system to show the dynamic view of the system. It is executed line by line showing the time ordering of messages.

Activity Diagrams describe the sequencing of actions and system’s logic. The starting point of this diagram is indicated by a large black dot and uses arrows to point to the order of actions.  Activity Diagram is typically used for objects are more complex that you would like to present clearly.

I selected this particular blog since we are using UML in Software Construction, Development, and Architecture class. I was actually a bit confused about how we used the diagrams in class. I was thinking that diagrams are just one program like we did in class, but diagrams are actually made to connect with other diagrams to explain how they interact with each other. In this blog, Mohamed added which team members are responsible for each diagrams. After reading this blog it is clear to me now that there are different responsibilities and types of people in a team. I thought that a team would be composed of all software developers, but in reality, some modeling diagrams are done by other professionals.

 

 

From the blog cs-wsu – Site Title by csrenz and used with permission of the author. All other rights reserved by the author.

Mobile App Development

Jonathan Stark on Mobile App Development podcast

This podcast talks about the process of developing a mobile application and the different aspects to consider before creating one. Jonathan Stark talked about the general things needed to develop an app. Jonathan was saying that deploying a mobile app requires so much more than what people think. When you deploy an app in the app store, whether is google play or itunes. Your app would be reviewed by the store on whether your app is reliable, perform as it should, and free of offensive materials. Apps are reviewed based on technical, content and design of the app. He also said that sometimes it can hinder investors since even though you have a very nice app, but it didn’t pass the review, it is worth nothing. Jonathan also talked about using Progressive Web Applications (PWA) versus the Native Apps. He talked about the advantage of using PWA and coming from a web developer background, how it is better than the native apps that most are developing. Jonathan said that PWA is faster, more secure, reliable and most importantly it is like a one size fits all. Developers would not need to develop multiple apps across multiple platforms anymore. While in the Native apps, you have different apps for different OS, whether it is iOS or Android. He also talked about React Native. React Native is a real mobile app it is not a “mobile web app”. In React Native you can create apps the traditional way, just like using Objective-C and Java. Jonathan also talked in this podcast about the importance of design while building an app. Since phones don’t come in one size, you have to consider how your app would work in different phones. Sometimes you might have to move the interfaces from your app across different phones. There are many more things to list here about mobile app development that they talked about in this podcast.

I chose the topic of Mobile App Development since everybody, I feel like uses a smart phone nowadays and that we are basically using applications every time we open our phones.

From this podcast, I learned different things to be considered while making an application. That even the smallest thing like, what if you are trying to click on the menu but your finger covers the options while doing it. Things like these that I never considered before was just as important as coding the actual app.

From the blog cs-wsu – Site Title by csrenz and used with permission of the author. All other rights reserved by the author.

Data Science

This podcast is about the field of Data Science but also talked about team building.  I chose this podcast because I saw that she(Angela Bassa) was the Director of Data Science at iRobot and because I am using iRobot’s Create on my robotics class. There was a part in the podcast that I thought was funny but is important when it comes to team building. Angela said that “you cannot have a team full of  unicorns(programming gods basically)”. That was a pretty bold statement. She said that it will take time to get a team full of unicorns and a lot of resources. Then she referenced the “super chickens” who were a group of only the best chicken, but what ends up happening is they killed each other.  I learned that balance is important in everything that we do.

Data Science with Angela Bassa

From the blog cs-wsu – Site Title by csrenz and used with permission of the author. All other rights reserved by the author.

Artificial Intelligence API’s

Really interesting talk about Artificial Intelligence API’s used by Salesforce Einstein for image recognition and recommendation system.

https://softwareengineeringdaily.com/2017/09/05/artificial-intelligence-apis-with-simon-chan/

From the blog cs-wsu – Site Title by csrenz and used with permission of the author. All other rights reserved by the author.

Introduction

Welcome.

This is the first blog post for CS-343 Software Construction, Design and Architecture.

 

From the blog cs-wsu – Site Title by csrenz and used with permission of the author. All other rights reserved by the author.

The Software Craftsman, Chapters 15 & 16

Chapter 15 goes over why quality code doesn’t have to come with a big price tag. Mancuso discusses that while managers and clients want everything done as cheaply and quickly as possible, they still expect a decent amount of quality to be in the software they are getting. Mancuso explains that coding does not have to suffer from being or poor quality if people stick to simple practices that will continue to help keep the code clean and easy to test. Again, very similar to the last book and previous chapters, he re-iterates the importance of TDD and how much time it saves. He also goes into why it is important to refactor code when and where you can to make sure that it was cleaner than before. I think the best thing in this chapter is the Four Rules of Simple Design; passes all tests, minimizes duplication, maximizes clarity, and has fewer elements. Keeping these rules in mind would greatly help programmers on track for keeping code as clean and simple as possible, and keeps TDD in mind.

Chapter 16 basically just sums up what being a Software Craftsman means and how they look at furthering their careers. A good portion of this chapter is common sense; knowing that being a good developer requires passion, and the urge to want to learn more about the software development field. To that extent, Mancuso goes over how to build your career and how to look at jobs to make sure you are aiming for positions that will help you later down the line. I did find some of the questions that he asked himself before applying to a job useful (again probably later down the line when I’m able to be more picky about where I apply to). I have also come across many people that graduate from this profession and admit that they don’t know what they want to get into. Again Mancuso provides some good, even if obvious, advice on how to ix this issue; simply get out there and talk to people. Overall I think that this book has provided some very useful information from how to stay passionate about your work to some really good advice about help to further your career in the industry. I would definitely recommend this book to anyone thinking about getting into the software development field, or even to someone that may already have some experience in it.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

The Software Craftsman, Chapters 13 &14

Chapter 13 continues on the topic about how to keep people on your team motivated and interested in the software development field. I think this chapter has to be one of my favorites so far. All of the suggestions that are made about how to keep passion going in a team were interesting to go over, and just reading about them makes me want to give them a try. I think that my favorite idea, out of those suggested, was just switching projects for a few hours. This one is so simple and can be done a once a week, so it shouldn’t interfere with anyone’s work, but it is an easy way for team members to get invested in one another’s projects, and also encourage the learning and use of other softwares/ways of thinking in their own projects.

Chapter 14 mostly focuses on how to deal with different types of people that may end up on your team and how to encourage them to keep up with technical practices. I found that this chapter really just boils down to “know what you are talking about.” If you completely understand what you are trying to change, whether it is implementing TDD or trying to use a new language, the more you know about it the easier it is to explain it to everyone else. However, this doesn’t mean that everyone will except it just from your knowledge allow. Being able to also show your teammates and company how effective your change will be is also very important. In the end, to change the minds of the people that you work with, you want to make sure that you can clearly communicate with them, listen to what they have to say, and present these new changes in a way that will hopefully persuade most of your members to adopting them.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

The Software Craftsman, Chapters 11 &12

Chapter 11 was mostly for people that are the interviewer at their company. It basically went over what an interviewer should and shouldn’t do to a potential candidate. For example, brainteasers don’t work to attract good developers, and doing anything that makes a potential partner look like a fool will make it so they don’t trust working for you. Again this is a chapter that isn’t helpful to me right now, but the information in this book may be more helpful further down the line in my career.

Chapter 12 talked about how to low morale can kill productivity and passion in developers, and also talked about how to bring passion back into a company. Mancuso talks about how, after awhile, some developers just give up on projects and become lazy because they just see their job (as he put) as “just a job.” This type of thinking definitely becomes an issue because then people are not meeting deadlines and can lead to wasting tons of company money. However, I don’t see an issue with wanting to make sure that you have hobbies and time that are separate from your work life. As long as you maintain a balance between the two it should be fine because I believe that if you fill everyday with the same thing, that will burn you out faster than anything else might. He then goes onto say how to bring back motivation to a low morale team. I like his idea of talking with people at the end of the stand-up meetings about new things they found. This not only gives people the opportunity to discover new posts or websites they have never heard of, but it also brings the team closer together.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

The Software Craftsman, Chapters 9 & 10

Chapter 9 goes into detail about recruitment for software development jobs and some of the issues with it. Mostly what I took away from this chapter is how to recognize what possible companies and business know what kind of developer they are looking for versus a company that is just looking for anyone who might fit their need. The rest of this chapter seemed to mainly target people that were in the position to hire people, and what their focus should be to make sure they attract and get the best developer that they can. For right now, I didn’t find those parts too useful, but hopefully this knowledge will be useful later on in my career.

Chapter 10 focuses on the interviewing process and what recruiters are looking for in a potential addition to their team. Mancuso list a bunch of useful things to be aware of when going into an interview. Some of the things that I found useful were ask questions about the company and the team, make sure to highlight your achievements as well as point out issues that you’ve dealt with, and make sure to talk about want you want to achieve in your career and how you believe that this position will help you. He also points out different ways to analyze an interview to see what they might be looking for and how they judge new candidates. Mancuso points out that, during an interview, it’s ok to make sure that you are being asked questions that are relevant to the position you want. There were also different ways that an interview could be held, from pair-programming interviews to even having pre-interview coding exercises. Some of these I’ve heard of before, but I thought that this book did a good job of pointing them out and explaining them so that graduates would be aware that they might end up in one of these scenarios. Overall this chapter was extremely useful for people that are just graduating, and I definitely took away some of the things to look out for in interviews (mostly about what to say ad bring up during an interview since I’ve done so few of them).

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.