Sam Bryan

For my final blog for “Software Design and Architecture” this semester, I decided to research time management for doing software projects. This is an issue that I ran into creating my final project, and I thought it would be worthwhile to learn from my experience while it was fresh in my mind. I thought this would be particularly helpful because I would like to do a few projects for fun over the winter break. I don’t think that I’m alone in that without a looming deadline, what little time management skills I have tend to go out the window. I hope this will change this time. I doubt reading an article will transform me into an extremely productive person, but at least it might point me in the right direction. I can only hope. The article that I found was from *codeproject.com* and was titled “Time Management Tips for Developers.” I thought it gave some good pieces of advice. Even if you are not a software developer, you could benefit from all the advice given. I will focus on three

For my last blog for this class — Software Quality Assurance and Testing — I decided to look at what I could find about the subject in the news. After searching around, I found an article from Forbes  that came out only a few days ago — December 17. The article was titled “AI In Software Testing: Will A Bot Steal Your Spot?” My first impression before I read the article was, “Of course not! There will always be people whose job it is to test software.” Software is growing to touch every corner of our lives, and even if AI is incorporated, I would think it would be unlikely that they would entirely, or even partially, replace testers. Halfway through the article, the author confirmed my skepticism by saying, “While it’s unlikely the testers will be wiped out, I think machine learning and other branches of AI will significantly alter the way software testing is conducted.” The article seems to have a misleading title. The article goes on to give several examples of how robots will

For this week’s post for software architecture, I decided to explore pursuing it as a career. I have focused several of my posts in this blog to going into a career for software architecture and quality assurance, but software development is very appealing to me as well. Although I have found this class more difficult than the quality assurance class, I find the work we have done in this class very satisfying, and I would like to do something like this in my career. I found an article from “Lifehacker,” where they interviewed a software architect Harrison Ambs on what it was like to be a software architect. It focused less on what a software architect is, and more gave general career advice for someone in the industry. The final question in the interview said, “What advice would you give to those aspiring to join your profession?” He gave a paragraph with some good advice. (Starting with, “Always be willing to learn something even if you know you’ll be terrible at.”) However, I w

For this week's software quality assurance Blog, I would like to revisit software testing as a career, because it is something that I am interested in pursuing. I found an article, “Software testing is big business,” from a South African website, “itweb.co.za”. In the article, it stresses the importance of quality assurance in software. I think I have said here in this blog how fickle customers can be with software that is buggy and jump ship at the first chance if the code causes them even a slight inconvenience. If I have not said it here, I know I have read something similar before. The article repeats this sentiment, and it is probably something worth repeating.  The article continues and says that developers often rush to add new features, while leaving quality assurance as an afterthought. The article claims that when companies allocate resources properly, about one third of IT budgets are allocated to software quality assurance and testing. The article says tha

For this week’s blog on Software Architecture and Design, I will revisit the same assignment that I have blogged about before. For the assignment, I had the option between three design patterns to write a tutorial for. I picked the proxy design pattern, and then I blogged about the decorator design pattern. Now, I would like to watch a tutorial on the third design pattern, facade, so that I might learn about all three. I chose to use the same YouTube, Derek Banas, that I used before for the other blog. I found his videos engaging and informative that I would like to learn about it again. I also like that it is fairly concise (11.5 min), which makes it much easier to rewatch sections that I don’t get the first time around.  It turns out that I did not understand it after finishing Derek’s video, so I turned to another video by another Youtube channel by Christopher Okhravi. Derek went straight into coding, whereas Christopher just drew diagrams and did not code. I needed more

For this week’s blog on quality assurance, I wanted to review what we learned most recently in class. I decided to watch a relatively short (24 min) tutorial on Mockito. It has been over a week since I’ve seen it, and there’s another few days until we meet again. I could use the refresher before then. The tutorial I chose to watch was by a YouTuber named Walter Schilling. I thought he explained the concept very well. I will definitely bookmark his page for other concepts that I find challenging. I thought it was a little bit of a complicated set up. I don’t think it was necessary to see the UML diagrams or as extensive of a walkthrough of how his code worked. He didn’t go excessively in depth, but I understood it pretty well after he gave a  demonstration of the final code in action. (He typed in some inputs and showed what the output would be.) I didn’t need to know as much information on his example code. That’s not what I had come to see. When he got to the mockito section, I

For this week’s blog for quality assurance and testing, I decided to read an article from Wired Magazine that focused less on the testing process itself and more of how a company can benefit from it. The article I chose is a little less than a year old about Apple’s securities and vulnerabilities. The article confirms some of what I had hoped — that Apple still has a strong reputation for security. However, some vulnerabilities have damaged how the company is perceived by many.  In High Sierra, all that you had to do to gain root access was type the word “root.” They fixed it impressively quickly. However, the article wonders if the security flaws like this are emblematic of deeper problems. There have been many more bugs and vulnerabilities found, such as wonky autocorrect on the iPhone. Although not every bug (like the autocorrect) is not always a security issue, it is incredibly irritating.  One advantage that Apple has over its competitors is that most of its customers up

For this week's blog on Software Design, I decided to watch a short tutorial on one of the design patterns I didn't pick for a previous assignment. I picked Proxy Design pattern to cover before, and now I'm going back to learn about Decorator Design Pattern. It is only a thirteen minute video, so I won't be going as deep as I would had I picked it for the assignment. I am also going to talk about my reflections on it rather than create a tutorial, so I am not going to reteach it to the person reading this blog post. The tutorial I chose was made by Derek Banas on YouTube. He used an example of a pizza parlor to illustrate the wrong way to code it by using inheritance. He shows the problem with this because you would have to create a very large number of subclasses for all your objects (in this case pizzas). Composition, on the other hand, is a dynamic way of modifying objects. Instead of creating as many subclasses, you add functionality at run time. It has th

I decided to take a somewhat different tack for this week’s post for software quality assurance and testing. Instead of focusing on testing itself, and all there is to it, I found a video from a tester in the field, Alan Richardson, on his advice for someone who is interested in getting into the field. He strongly urged someone getting started not to think of a position in quality assurance as a “stepping stone” to being a software developer. If you do, you will inevitably find yourself in a dead end because you really aren’t interested in the field. “If you want to be a software developer, start as a software developer.”  He encourages the viewer to read everything they can on the subject. A lot of it is free, so there is no reason to necessarily buy anything. However, he gives some book recommendations. He gives a good insight why books can be so valuable to learning. “An expert in the field took a year to concentrate everything they know into those pages,” (paraphrased).

For this week’s blog on Software Architecture, I listened to Episode 3 of the “Software Architecture Radio” Podcast, which featured Mark Richards, an independent software architect. He has 32 years in the industry, with more than twenty years as a software architect.  They mostly talked about the evolution of software architecture. Although some of the things they talked about went a little over my head, I was able to pick up on the majority of what they were talking about.  He divided up the evolution of architecture into five stages. He talked about evolution happening in vertical and horizontal slices, that is within each layer and one layer affecting those above and around it. The layers were (1) hardware, (2) software, (3) human interaction, (4) social interaction, and (5) the environment, such as the internet of things. He said one thing in particular, need, drives change the fastest. As an aside, he also said that that’s the best way of teaching something in this fi

https://joecolantonio.com/testtalks/223-testing-dream-journaling-smashing-sand-castles-with-noemi-ferrera/ In this blog for software quality assurance and testing, I decided to return to the “Test Talks” podcast, presented by Joe Colantonio, for another episode (#223). In it, he sat down with Noemi Ferrera, a software tester for a Chinese mobile gaming company to get her take on the subject. Noemi gave a few interesting metaphors that I appreciated for how to look at testing. In one, she gave the example of going to a movie where you had already read the book. It was different than how you imagined it while reading it, and testing is a way of making the “movie version” fit the way you envisioned it playing out.  The other metaphor for testing that she gave was, if you were children at the beach, the developers would be the ones building the sandcastles, whereas the testers would be the ones destroying them. I don’t know if that would be the most accurate way of looking at

For this week’s blog on software design, I chose to watch a video presented by Dr. Steve Bagley on some fundamentals of object oriented programming (OOP). I’m embarrassed to say that although I am taking several upper-level computer science classes, I am unsure I would be able to give a good definition of what object oriented design was. To be fair though, it has been several years since I have taken CS 101, and it seemed like such a foreign concept at the time. I felt silly learning about something so elementary again, but it made a lot more sense when I’ve had as much exposure to OOP as I have now. For the video, he uses a game of “Pong” as an example of how OOP might use objects to represent the “ball” and “paddles.” From there, he talked some about inheritance and touched on a few more topics, albeit briefly. The main reason why I didn’t understand the benefit of this way of programming is that I didn’t know how else you would do it. I didn’t realize that without declari

For this weeks blog for the topic Quality Assurance and Testing, I read an article titled “5 Reasons you are wasting your testing time.” That is not to say that testing is a waste of time, but rather as the first sentence says, “Not all our testing time is spent effectively.” The blog goes on to list the five reasons that a programmer might be using their testing time ineffectively, which are as follows: (1) “You don’t set a clear goal for your testing task;” (2) “You don’t understand the value of the feature for your End User;” (3) “You do not keep track of what you tested, your findings and the other ideas you got while testing;” (4) “You do not consult existing information to get insights into your test;” And (5) “You do not do post-test reviews and feedback sessions with your peers.” These are all straightforward ideas, but I’m sure most programmers testing their code have fallen into several of these, if not all. This list provides a framework to avoid these pitfalls. In class

I was interested in what someone from such a large website, eBay, would have to say about its architecture. There was a lot of takeaways from it, summarized in four main ideas: partition everything, use asynchrony everywhere, automate everything, and design the system keeping in mind that everything fails at some pint in a large distributed system. Although this is an older talk (from 2007), these all seem to be sound systems to design something so large. He referenced a theorem from 1998 that he said took a while to get traction. Likewise, I am sure his design principles have proven true for the last ten years. To be completely honest, there was a lot of industry-specific jargon used that went above my head. I took a lot of notes though, and looked up the terms I did not know. I still found it very interesting, though. I found it the most interesting that someone designing one of the largest websites in the world was incredibility realistic of the shortcomings of everything designed

In this episode (number 219) of “Test Talks,” I was able to hear Shailesh Rao’s insight into having quality software. He compared it to a “paper-free office” or a “stress-free life,” both worthy goals, but are hard to achieve. They can be strived towards, but it is near impossible to get it 100%. He brought up the issues that bad software can pose to potentially millions of users. Bad software can open the doors to hackers, who might be able to take down websites like Twitter or Reddit. Also, it might stop airlines from being able to function — an annoyance to most, but Mr. Rao asked, “what if there was time-sensitive and lifesaving medicine onboard?” I found this podcast brought up some aspects that I had not thought of before when if comes to quality assurance. I suppose that I’ve thought about the various things he brought up, but as a consumer and never as a creator of the software. A very thought-provoking topic brought up was the fickleness of consumers. They don’t have the

In computer science, there are a lot of things we would normally take for granted, but it might not be so easy to program. Take time, for instance. If we wanted to create an app to calculate how many seconds ago a time and date was, it seems straightforward. Of course we would account things like leap days, but as I discovered, it quickly becomes a lot more complicated than that. As Tom Scott explains in an episode of the YouTube Channel, “Computerphile,” a simple-sounding app like this can be jarringly complicated. For starters, to create this app for a worldwide audience, it seems reasonable to make it available in all time zones. To adjust it for each time zone seems straightforward enough. All you have to do is take the Greenwich Mean Time and add or subtract hours based on the time zone that the user is in, right? Not quite. Take daylight savings time, for instance. It varies from country to country when daylight savings starts, and then there are some states/countries that

Hello again! This is my first post for 343. Equally excited for this class as the other. Excelsior!

Hello world! This is my first post for CS-443. I am very excited for this semester and what's to come!