Category Archives: Software Development

Software Capstone: Apprenticeship Patterns Post 1

Hello again readers.

So, what is a pattern as is described in the book Apprenticeship Patterns by Adewale Oshineye and Dave Hoover? Patterns are ways in which we program or otherwise do our work/solve problems repeatedly. When applied correctly, patterns allow us to easily overcome many problems/obstacles we face in our jobs and personal hobbies.

The patterns in the book make their approach based on the context, problems, and possible solutions. “The context sets the mood… problem statement identifies the problem being solved by the entirety of the pattern. The solution usually begins with a one sentence resolution for the problem…” (Pattern Form, Apprenticeship Patterns)

Developing a pattern allows for the mass production of programs, buildings, and other structures, whether physical or metaphysical. It is intended to further the abilities of the novice to moderately advanced programmer. One model/pattern for programming is using a master node and slave nodes: the master node controls what slave nodes do (which instructions the slave nodes undergo.)

 

This book was written for “software apprentices” (as put forth by the author.)  The three tiers of the programmer go from apprentice, to journeyman, to a master craftsmen. The apprentice believe that there is always a better way to do what they are doing. The journeyman focuses inwardly as well as on teamwork and connecting with others. The master does this all as well as attempt to move the industry forward.

 

On to the review of this pattern. I find taking instructions from a singular source and running processes on many smaller sources of computing power to be interesting: you can get vastly more processing power by adding many slave or sub-nodes to a master or dominative node. I haven’t really found that it changes how I will approach programming in the future but I may look back on this way of programming for reference. Finally, I have no disagreements or other takeaways from the first chapter and pattern of this book.

I hope you’ve enjoyed my first post about Apprenticeship Patterns, I will see you next time.

 

-SMR

From the blog CS@Worcester – Sean Raleigh's CS Blog by sraleigh62 and used with permission of the author. All other rights reserved by the author.

Adapt or Git Left Behind?

CS SERIES (15)As my last fall semester comes to a close, I wanted to write about an article on something pretty interesting I learned about in my software construction and design course.

On Stackify, Thorben Janssen wrote Design Patterns Explained–Adapter Pattern (with code examples). Overall, this article re-instilled how design patterns make it easier to write more well-structured and maintainable code.

I found it useful to see how Janssen discussed the two different versions of the class adapter; the class adapter pattern (which implements the adapter using inheritance) and the object adapter pattern (which uses composition to reference an instance of the wrapped class within it).

Similar to how we learned the concept in class, something I appreciated is the “real-life” example or comparison used to describe the physical adapters we use when traveling. When we are traveling and do not have compatible power sockets, we must find a way to be able to charge our use our devices without having to change the whole make of it. A way of doing so is by using adapters; which does not change the overall product or device, it just allows you to be able to plug it in.

An situational example that I can think of when explaining adapters is if you have ever been zip-lining or done a ropes course (like Go Ape) where you are attached to a harness. When you are transferring from one line to another, you can use a metal contraption which helps guide you while connecting and disconnecting from paths. That metal contraption serves as an adapter, not changing what you are but allowing you to use something.

I agree with what message Janssen is trying to express about how great design patterns are (the adapter pattern specifically) when it comes to writing code. His content allowed me to think about real life situations in code form when he introduced the basic and premium coffee machines to brew coffee using the adapter pattern. One of the best ways of learning concepts, in my opinion, is to compare it to a real-life situation and then show people visualizations to help them better understand what you are trying to explain and the article did both.

Article: https://stackify.com/design-patterns-explained-adapter-pattern-with-code-examples/

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Test Yourself Before You Wreck Yourself

CS SERIES (14)Testing, testing. I may need your approval on this article I read by Software Testing Magazine on Approval Testing. Approval testing, as defined by this article, is a way of software testing that results in presenting the before and after of an application for a user (ex: software development team) to review it and potentially approve it. It’s more of a visual representation of testing and one of the major cons is how the results have to be checked manually.

Some testing tools mentioned include: Approval Tests, TextTest, Jest, Recheck, Automated Screenshot Diff, Depicted (dpxdt), and etc.

The main purpose of the software testing tool, using TextTest for example, is checking that the text output after running program from the command line in different ways.

What I found interesting is how a user can see that a test technically could have “passed” or “failed” but still decide to mark it as the other because they choose what feature they are looking for in the end. This makes it a little more flexible to use approval testing as it is more of a guide or guideline for a user instead of only seeing one word and then a short description of what could have gone wrong. I think this process is much more transparent or descriptive with a user about what could have gone wrong or what went right.

One way the content has changed how I will think about the testing is how there are so many more types of software or programs out there than we can imagine which help us better code or create our own software and programs. This one is especially good for visual coders and testers who like to see their results firsthand to compare what they are expecting with what they actually got.

Overall, I found this article was useful because it introduced me to thinking about a better way of logging the differences between what the reference result is versus the actual result. I did not disagree with any of it since it showed us how we can use approval testing to our advantage while still being honest about its limitations.

Article: http://www.softwaretestingmagazine.com/knowledge/approval-testing/

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Top 5oftware Architecture

CS SERIES (13)When using architecture patterns, how will you know which one to choose? Peter Wayner, an independent author for TechBeacon takes five architectures that the majority of programs today use and broke them down into their strengths and weaknesses. Through this, it seems like he is hoping to guide users to selecting the most effective software architecture pattern for their needs.

If this article does not clear up enough information, Wayner also brings up a book, Software Architecture Patterns by Mark Richards, which focuses further on architectures commonly used to organize software systems.

The fives types discussed in the article are:

  • Layered (n-tier) architecture
  • Event-driven architecture
  • Microkernel architecture
  • Microservices architecture
  • Space-based architecture

The one I found most interesting is space-based architecture because at first when I thought of space, I was thinking of the other kind. The one with the sun and the stars and the moon. But then I realized–what does that have anything to do with software architecture? Space-based architecture is listed as “best for high-volume data like click streams and user logs” and I think this one is pretty important, especially during times like Black Friday and Cyber Monday. I personally experienced the frustration of not being able to access a site (adidas) due to high volume and it really does not help a business.

Another architecture I found thought-provoking is micro-services architecture because of the way Wayner introduced the concept, “[s]oftware can be like a baby elephant: It is cute and fun when it’s little, but once it gets big, it is difficult to steer and resistant to change.” The author providing an example of this made me think about how a site with so many users and things happening at once actually just had many different separate services but they were put together as one. I was a little surprised to think of Netflix in that way after all the times I’ve used it but it makes much more sense now.

Overall, I found all of the information pretty useful and clear to understand as Wayner described what they were and then listed the caveats and what they were best for. I would recommend using this as a reference or quick review of common software architecture designs if someone needs it.

Article: https://techbeacon.com/top-5-software-architecture-patterns-how-make-right-choice

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Software Blog

CS SERIES (12).pngThere are lots of “rules” we must follow in object-oriented software development and the article The Genius of the Law of Demeter by Javadevguy summarizes how they are useful. From what I put together, it seems like the Law of Demeter took abstract concepts and basically put them into a universal set of rules for Object-Oriented code.

I thought that the law of demeter must be a big deal if someone decided to sit down and write a lengthy blog post about it. This content ended up being interesting as it tried to convince readers why they should obey this “law.” The Law of Demeter basically paves the way for what users can do to a given method. It is kind of like considering the restrictions or possibilities based on the method. One of the takeaways I got from this is how there is a lot of focus on communication between two objects.

The rules listed in the article are as follows–noting that it says “For all classes C, and for all methods M attached to C, all objects to which M sends a message must be”:

  1. self (this in Java)
  2. M’s argument objects
  3. Instance variable objects of C
  4. Objects created by M, or by functions or methods which M calls
  5. Objects in global variables (static fields in Java)

Another useful takeaway I got from this article came from observing the code examples Javadevguy included; how Rule #1 covers that any method can be called on the current object. I also noted when there would be an instance where the law would prohibit something is not “sending a message” to any already existing object that is held in instance variables of other classes.

This will affect the way I continue to do work as an Object-Oriented developer. I mean, in life when you learn there is a more useful or structured way to help you achieve more effective results, you would want to try or follow it, right? For my future use, I will acknowledge (like other blogs and articles) that the Law of Demeter is less of a law and only a suggestion or a guideline.

Overall, I would say that the content has helped further solidified my understanding of some Object-Oriented coding concepts. I agree with the content as it is trying to help people become better developers or better understand the Law of Demeter in general.

Article: https://javadevguy.wordpress.com/2017/05/14/the-genius-of-the-law-of-demeter/

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

The D-Sign of C-Sci

CS SERIES (6)In my software design course, I recently learned about how using design patterns helps you code better. I thought it would be a good review to go over the concepts this article introduces and potentially link it to things from class and maybe even add some things we did not get through during class.

The three categories Frederico Haag, a computer science engineering student at PoliMi, wrote about are creational patterns, structural patterns, and behavioral patterns.

Based on the design pattern I chose to work on for my individual assignment, I wanted to focus on the facade section–which is a structural pattern. The main take-away of the facade is how it “provides a simplified interface to a larger body of code.” I like how the name itself actually relates to the word facade’s definition: “an outward appearance that is maintained to conceal a less pleasant or creditable reality” (Dictionary.com). As a person who likes the aesthetic side of things, this seems like a convenient design pattern, especially if people who are not working on the code end up seeing it; it may be less overwhelming to some.

Another one of the options my class had for the same assignment above is for the decorator class–which is also a structural pattern. This “adds behavior to an object dynamically without affecting the behavior of other objects from the same class.” For some reason, when I imagine this concept, I think of a decorated cake. Since it is useful for adding the same behavior to many classes; it’s like when you add a spread-out layer of fondant or frosting to a cake, it could either cover the whole section(s) of cake or just some, but it doesn’t mess up the inside of the cake.

Overall, I found this content very useful to reiterate what I had learned and Haag incorporated visual UML diagram examples along with actual snippets of code to help us compare and contrast what he was showing. The content has not changed how I think about the subject because there is no arguing here, it just shows different ways people can structure their code overall. I do appreciate how Haag also listed “typical use cases” for some of them as it makes it easier to imagine.

Article: https://medium.com/federicohaag/coding-better-using-design-patterns-4d7385a9e7ac

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

No Ragrets(sion) Testing

CS SERIES (5)“Forget about automating your regression tests” is some bold advice from Bas Dijkstra, who has experience as a test automation consultant. It made me wonder what exactly led him to making this kind of statement on regression test scripts and his article, On Ending the Regression Automation Fixation, covered various reasons why.

Two reasons why Dijkstra says starting with automating your regression tests is not ideal includes regression scripts being too long and how regression tests are written from an end user perspective. I find this interesting as a lot of software bloggers are saying automation is not always going to be the answer and their answers have yet to make me disagree.

Sam CS (10)

The reason I chose this is because I am drawn to honesty; two examples above were explained with scenarios with failures Dijkstra has faced from creating inefficient or “plain worthless” cases.

This content will change the way I think about creating potential testing cases as there will be questions to ask myself before proceeding with the task(s) at hand. There will be a lot of reflecting on what could be consuming my test time, which parts are too repetitive, or what can just be done better. I mean of course I’ve already been considering these questions but now there will be a more conscious effort to think about them.

Dijkstra’s process especially considers the difference between how many scripts there could be when a computer is trying to translate what a human could have performed when testing. I realize how that would be an issue when trying to understand what could have went wrong or does not match up fully when there is less (specific) feedback when it comes to automation.

Thanks to this article, I will also try to predict how many layers of regression scripts would be too much of a hassle to develop ways for communication between what is being tested under the application. Overall, this information was useful as we should be reminded that “automation is meant to make your life and testing applications easier”; it should make sense and not be done at random, especially for regression testing.

Article: https://www.ontestautomation.com/on-ending-the-regression-automation-fixation/

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

TheCurrentStateOf, SD 01110

CS SERIES (4)As someone who will be graduating within the next year, I’m always interested in what software development is currently like. Ekaterina Novoseltseva uses some 2018 statistics and presents interesting facts about software development through Apiumhub—which is a software development company based in Barcelona. The data in this article comes from a collection of over 300 answers from different countries around the world; starting with the challenges in software development.

The information collected on programming languages was interesting to me as Javascript, Java, and Python are the top three current primary programming languages for those companies. On top of that, Go is used around 6% and of the companies who are considering using another programming language in the next 12 months, Go is the second on that list. I like seeing this data to know what is currently popular and may be an upcoming popular language as this is constantly changing. Novoseltseva points out how about 37% “of respondents said they’re not planning to use any new programming languages in the coming 12 months” and it makes me wonder whether it is because they do not want to change their ways or if they are already so on top of the updates that they do not need to for now. It also makes me wonder how companies in the New England region are doing in terms of exploring new languages or ways to keep up to date on their projects.

Although I knew of the current trend(s) for the most part, I was surprised to see what Apiumhub had to conclude on software outsourcing. It shows an infographic where of the people who did outsource software development fully or partially, only 10.06% of them were “absolutely satisfied” and 51.57% were “somewhat satisfied.” Based on what I’d been hearing of people being worried of getting all the tech jobs outsourced, maybe the scare isn’t as bad as people led it on to be. I mean of course, the total majority of responses from that fall under “satisfied” but it was not fully satisfying—this would probably be best for quick, short-term fixes or work. Which shows how there is still more to people-to-people communication in the company’s direct workforce and it puts my mind at ease a little more.

Article: https://apiumhub.com/tech-blog-barcelona/interesting-facts-software-development/

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

if (two < one) {

CS SERIES (2)According to music artists, two is better than one. When it comes to designing code that has two parts, this may not be the case. In Max Kanat-Alexander’s article, he explains how he has a personal rule of needing to know how generic his code needs to be. He describes it as if he were designing an audio decoder and started out with supporting WAV files and then later needed to add support for MP3 files. His solution was for what he only needed on its own instead of having to copy and paste the common parts for the format; he emphasizes that “it’s not just two implementations that are bad, but also two locations.” Another rule Kanat-Alexander has for helping this stay consistent is to create code well enough to ensure you would ideally never have to go back and change it if another part of the code has to be modified.

I found this information useful because I believe that developers are always striving to be the most efficient coders they can be. In order to do so, using two of Kanat-Alexander’s methods would help them plan to code more effectively. Just imagine the potential headache of realizing you have to go further back to code you thought was finished and then even further back when you notice a change on top of what you originally needed to make. This will probably affect how I will work in the future as it will make me sit back and think beyond the task at hand. It would allow me to save room for potential add-ons without them crisscrossing, which would allow me to skip out on having to do more rework.

At the end of the article, Kanat-Alexander notes that the reader does not have to take this as a “hard and fast law of the universe” and I appreciate how he tries to help the reader but does not try to push them to do it his way. In terms of the subject, I do not think my thoughts have changed too much as I do want to learn how to code better and I would like to continue finding out about people’s coding structure process.

Article: https://www.codesimplicity.com/post/two-is-too-many/

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Testing, Testing. QAn You Hear Me?

CS SERIES (1)To kick off this series, I wanted to introduce why Software Quality Assurance (SQA) testing is important not only for testers to understand, but for developers as well. From my experience, I’ve become familiar with manual testing and exploring different types of automated testing for web applications. I wanted to know a little more about how being a good developer also includes being a good tester and found an article on SimpleProgrammer which reveals the importance of knowing how to test.

John Sonmez, the founder of SimpleProgrammer, says that he “owe[s] a large amount of the success [he] ha[s] had in [his] career as a software developer to [his] background in testing.” I can see why he feels that way, as using just a little more time to double-check what you have created could save you even more time in the long-run. For instance, if something you have spent hours working on seems complete and you do not double-check it and pass it on to a QA team, you have to wait for someone in QA or a testing platform to check it. That could take anywhere between minutes to a few days or more. Once it is QA tested, maybe a bug is found and your task falls back into your hands again.

Could the scenario above been preventable? Yes and no. It is a true that “you can never find all the bugs or defects in a piece of [theoretical] software and you can never test every possible input into the [theoretical] software” but you can try your best. This doesn’t necessarily mean having to do your own end-to-end regression testing through the entire software each time you add a minuscule feature but you should thoroughly check what you have changed and the features directly connected to it.

The article continues to describe common testing forms and what they each mean for developers. Sonmez supports the Agile cycle of software development and describes it in the article as well.

Article: https://simpleprogrammer.com/software-developers-know-testing-qa/

 

From the blog CS-Series by samanthatran and used with permission of the author. All other rights reserved by the author.