Category Archives: Week-14

Getting Started with JavaScript and the DOM

Christian Shadis

As I transition into the final semester of my undergraduate degree, I plan to learn Javascript. In my Software Construction, Design, and Architecture class, we briefly explored and edited some frontend code in Node.js and Vue.js. Using my prior knowledge in Java, I was able to understand how most of the code was functioning. As Javascript continues to rise in popularity, it would be a valuable language to add to my skillset. One of the fundamental aspects of learning Javascript, or so it seems, is to understand the Document Object Model (DOM). Having used his book HTML & CSS: Design and Build Web Sites to supplement my knowledge in web design, I decided to consult the fifth chapter of Jon Duckett’s Javascript and JQuery: Interactive Front-End Web Development to learn more about the DOM.

Duckett first specifies the DOM as a set of rules, separate from the HTML and CSS of the website, which “specifies how browsers should create a model of an HTML page and how JavaScript can access and update the contents of a web page while it is in the browser window” (Duckett 184). In other words, the DOM acts analogously to an API in that it facilitates or enables real-time communication between JavaScript code and the HTML page. Duckett proceeds to describe the DOM tree, the benefits of caching DOM queries, and how to traverse the DOM tree. He also described how to access, update, add, and delete HTML content from the page using the DOM. The chapter included a bit of bonus information such as cross-site scripting attack prevention and how to view the DOM in each of the major web browsers.

Reading this chapter was useful in contextualizing how the different parts of a webpage interact with each other. In addition to learning the fundamentals of the DOM, I also gained experience reading JavaScript code, which is a great way to learn how a language works. What stood out to me most about the material was the parallels between the DOM nodes and the LinkedList data structure. Having coded an implementation of the data structure in a previous course, it was intuitive to see how traversal of the DOM tree worked.

I plan to continue to learn JavaScript, and plan to read the remainder of the book. Web design is becoming more ubiquitous by the day, and thus a more valuable tool for developers to have. I would highly recommend this book and others by Jon Duckett to developers – the design is pleasing, he provides sample code, and offers excellent simplistic explanations.

Duckett, J. (2014). Document Object Model. In JavaScript & JQuery: Interactive Front-end web development (pp. 183–242). essay, John Wiley & Sons.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

GRASP

Resource Link: http://www.kamilgrzybek.com/design/grasp-explained/

For this blog post I wanted to explore the GRASP principles. GRASP is an acronym for 9 principles that apply to object oriented design in programming, and it stands for General Responsibility Assignment Software Patterns. The 9 principles are: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Indirection, Polymorphism, Pure Fabrication, and Protected Variations.

First, the Information Expert principle states that an object should have all the functionality and logic that pertains to it. For example, if a class has a list of objects, then it should also have all the logic for functions that pertain to that list, such as adding items, removing items, etc.

 Next, the Creator principle states that an object should be created within the scope where it’s used. This means that if a certain class A relies on another class B to function, and B is unique to A, then B should be created within class A.

Next, the Controller principle states that the first object behind the front end UI layer should control the backend operations. This helps to separate the front end functionality from the backend functionality.

Next, the Low Coupling principle states that objects should be designed in such a way to where they can be isolated and reused without changing many other components. This helps to avoid rewriting code that could be useful in multiple places, instead making it generic so that it can fit into many different applications.

Next, the High Cohesion principle states that objects should only contain data and functionality that pertains to their function. This helps to avoid overloading a class with extraneous information and logic that isn’t necessary and should be abstracted or put into another class.

Next, the Indirection principle states that instead of directly coupling two objects, an intermediary object should be used between the two to handle the coupling. This helps to avoid a direct dependence relationship between two objects, instead having them both rely on an in between class that handles the relationship, so that change can be localized to that one class.

Next, the Polymorphism principle states that objects should be generalized so that they can handle support for different object types. For example, an animal class would have functions that pertain to all animals, and then subclasses could have functions that are more specific to certain kinds of animals.

Next, the Pure Fabrication principle states that shared functionality between classes should be placed within a separate class rather than in a class that it only roughly fits into. This helps to abstract functionality that could be repeated among many classes, instead putting it into a single shared class.

Finally, the Protected Variations principle states that systems that are likely to change should be protected as to not affected other systems. This helps to avoid breaking systems that other systems rely on, instead making sure that systems which other systems have a dependence on are protected and not susceptible to change.

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

Software Framework

For this week’s blog post, I have found an article discussing software framework. Varvana Myllarniemi, Sari Kujala, Mikko Raatikainen, and Piia Sevonn, the authors of the article, say on software framework, “Software frameworks are nowadays extensively used to develop different kinds of software applications efficiently. For example, using a framework, such as Spring, Django, Node.js or Angular.js, is the de facto standard approach for developing web software.” (Varvan Myllarniemi, et. All). When selecting a framework, you will need to keep in mind that it will be a critical design decision. This is because the framework will control the application’s architecture.

There is a drawback that does come when selecting to use a framework. Due to frameworks being very complex and involve specific designs, they are very hard to learn. The current research on frameworks focus on is technical abilities more than anything else. So, there is very little research on how frameworks are picked for use in development. However, when thinking about APIs provided by the framework, there is a plethora of research from different viewpoints. The reliability and usability of the API have been the most studied. This has been more studied to it being able to reduce programmer frustration and potential bugs.

For most companies, customer need cannot be solved by development. Hence, by opening software ecosystems they can give up part of their control for faster speed and wider coverage. A definition on software ecosystems from the article can be seen below,

A software ecosystem is defined as “a set of businesses functioning as a unit and interacting with a shared market for software and services, together with the relationships among them, where relationships are frequently underpinned by a common technological platform or market” (Jansen et al. 2009).

A software ecosystem revolves around a central technology that is often now referred to as a software platform (such as an operating system, end-user application, etc.). These kinds of platforms can be accessed by end-users but also by software developers.

A platform owner will also need to provide a platform boundary resource, so a developer can build off the software platform. The authors of the article say on platform boundary resources, “The platform boundary resources are a way for the platform owner to control and influence what happens in the software ecosystem, while benefiting from the generativity of external application development.” (Varvan Myllarniemi, et. All). This is also good from companies that are also looking for a way to collaborate on similar application builds.

https://jserd.springeropen.com/articles/10.1186/s40411-018-0050-8

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

Breakable Toys

This week I looked at the pattern “Breakable Toys”. According to this pattern you have to fail at least as much as you succeed. The problem with the workplace is that failure is not supposed to happen, so if you want to learn you have to do it on your own time. You can do this by building smaller projects that are similar to what you have to do and work on them knowing that it is okay if something goes wrong. A personal wiki is a good example of a breakable toy that can teach you a lot. Even Linux was created as a breakable toy.

I like this pattern because it reinforces the idea that failure is okay. I initially disagreed with the premise that the workplace does not allow failure. Many people will fail at work and that is okay, especially if you are new in a certain field. After thinking about it I came to agree more with the author. While failure in the workplace happens, it is tolerated not encouraged. It is okay to make mistakes but you do not want to make mistakes all the time. If you are working with a breakable toy in your own time you can have catastrophic failures with nothing on the line but your own time and sanity.

This is a pattern I should try to fit into my own life. My friend David, who is also in this course, is always making some kind of breakable toy and it is really admirable. He has been doing it for years though so I should not expect to be on his level just yet. He’s even making his own programming language right now which is something I can’t even imagine myself doing.

Making breakable toys is definitely the way forward for me to improve my programming skills. More than anything I need to write more code. I need to learn more and be forced to solve more problems. Even though I have been in the CS program for three years, I do not feel I have written very much code – especially code from scratch. Most things are 80% done by the time they are assigned to me; I just put the finishing touches.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

Dig Deeper: Depth not Breadth

Photo by Laura Stanley on Pexels.com

Learning things is difficult much of the time, and when being pressured to learn something (or even multiple things at a time) for some impending deadline or project responsibility, it can feel like there just isn’t enough time to warrant building a truly deep understanding during that period. The more items on the todo-list, the less time then is able to be spent on each item, leaving a very shallow understanding which is simply good enough to satisfy the given problem or context exactly.

The idea of learning in a shallow sense versus learning deeply is discussed in chapter 6 of Apprenticeship Patterns. Dig Deeper refers to the idea of making an effort to learn about tools, languages, or other areas of study to more than just the necessary degree to complete the current project. The authors argue that to always remain focused on finding a solution, rather than learning about why that solution works can make the overall understanding of the subject relatively shallow. Focusing solely on “your part” of the project can leave you lacking in comprehension regarding everything else, and so it is beneficial to look into relevant context, supporting ideas which build the foundations of the solution to the problem, and the documentation associated with the solution. The idea is to focus on depth of understanding, rather than breadth of topics covered.

In practice this seems difficult to implement one-hundred percent of the time, as time constraints will likely impede any efforts to understand everything in a way which is absolutely comprehensive. But for important ideas, subjects which will likely form integral, foundational aspects of a program or project, it makes sense to learn as much as possible about them so that if something goes wrong, you will have the knowledge to fix it. Choosing which topics to use this sort of approach for is a judgement call which should most likely rely heavily on context (as with most of the patterns discussed in this book).

While I wouldn’t necessarily want to use this approach all the time, I can definitely see the benefit of learning about the context and deeper ideas associated with topics such as new programming languages, database management, or frameworks like the .NET framework, which is associated with Windows-based development. Topics which are especially interesting in this regard (in my opinion) are game development and GUI frameworks, where there are often a large array of interconnecting components, panels, windows and tools associated. Learning the tools becomes almost like learning another language within the language itself.

Book referenced:

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman

https://learning.oreilly.com/library/view/Apprenticeship+Patterns/9780596806842/ch06s04.html

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

Apprenticeship Patterns – Stay in the Trenches

The problem in this pattern is an extremely simple one; you are a programmer at a company and you are offered a promotion that will take you away from programming. The provided solution is basically to just stay in programming despite the opportunity.

I would say I mostly agree with this pattern. This reminds me of Star Trek Beyond (2016) where spoilers, Kirk is offered a promotion to, what I believe is, Admiral which would mean he would no longer fly. After a long adventure, both him and Spock realize that where they belong is on the Enterprise together with the crew. So Kirk turns down the promotion. I think this situation – in a very decent film that most people seem to overlook – is a great match for this design pattern. The motivations are only partly the same, however. In the film, Kirk chooses the Enterprise because he is driven to explore. This design pattern, however, cares primarily about your future career and skills.

There is obviously an implication that the software craftsman enjoys programming, but the main reason they give for turning down the promotion seems to be that you need as much software experience as possible. If your career goal is to be in software, then being in a higher level position at some company you’ll probably leave in a few years doesn’t help you as much as being in programming. There are also potentially alternatives to a promotion that still accrue you the benefits you’ve earned.

Overall, I would say I’m in agreement with this pattern. You need to focus on your long term goals. In this scenario, that is most likely to become a good programmer. That said, its up to you to gauge the opportunity in front of you and determine whether or not it matches your goals. Perhaps the company you are at is a solid position with little fear of losing the job. Then, maybe you should take the promotion and simply keep climbing up. Its okay to change your plan in the face of new opportunities. The key is that you’re thinking rationally and properly about the situation at hand. After all, its your future.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Craft over Art

The problem of this pattern is a very common situation; virtually any time you are building something for a client. You are tasked with producing something that will solve the client’s problem. While you could follow a basic, common method, you also could explore new solutions and build something more custom. The pattern then determines that the solution to this problem is to rely on the tried and tested method. The justification is that your job is to create something functional and you must prioritize that over all else.

I’m not sure how I feel about the proposed solution to this. I would say I overall disagree. Firstly, just because you’re trying something new doesn’t mean its entirely original. There are varying degrees to which you could try something new. So I disagree with the absolutism of the statement. Next, I don’t think that taking the time to create something new is entirely selfish. Just because you could hack together something functional quickly and deliver it to the client doesn’t mean that they won’t have a successful, or even better product from you creating something original. In fact, I think in a sense it shows how much you care for the client. Rather than giving them something cookie cutter, you chose to think specifically about their problem rather than force it to match some other problem. When it comes to coding, that practice might significantly aid performance, for example. Cookie cutter solutions to intensely computational problems can’t be as efficient as specified unique solutions.

Lastly, not all developers have the time to create original content in their free time. If developers spend all of their time copy pasting the same projects, how will the industry as a whole ever advance? So once again, it isn’t just about advancing your own individual skills. I feel there is a disconnect with this pattern. The author seems to be referring specifically to artifying the job, but their descriptions are much more vague than that and can encompass less “negative” practices. When it comes to treating every job like a unique art piece, I’d generally be against that since I don’t think it is a good business model. However, it depends mostly on what the client wants. Perhaps the client wants that level of connection with the craftsman.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Confront Your Ignorance: Filling in the Gaps

Photo by Ann H on Pexels.com

Software development often involves a large variety of interconnected tools, patterns, standards and ideas which must be understood at a functional level to be able successfully apply them to the project at hand. Sometimes the sheer number of things which require your understanding can feel overwhelming, and going into a project without knowing absolutely everything you might need to know often leads to stress regarding the gaps in knowledge versus what is required.

The pattern discussed in chapter 2 of Apprenticeship Patterns, (link: https://learning.oreilly.com/library/view/Apprenticeship+Patterns/9780596806842/ch02s06.html) discusses the idea of confronting your ignorance, by which the authors mean that you should seek out and eliminate any holes or gaps in your knowledge, rather than allowing the “ignorance” to be a detriment to yourself. More specifically, the pattern describes the process of picking one skill, language or technology to focus on at a time, and working to better your understanding of that one idea. Rather than trying to focus on everything at once, you focus on learning one skill at a time, generating a more “precise” understanding of it than if it were being lumped together with other subjects.

This idea makes a lot of sense, intuitively you might think it would be second nature to begin learning a new topic by focusing only on that topic instead of trying to do everything all at the same time, but often that is exactly what ends up happening. Whenever there is a larger “stack” of tools to learn, I sometimes find myself actively trying to absorb everything all at once, because I feel that maybe slowing down and taking each single tool or topic on by itself might slow things down too much. This hesitance not to “multitask” when learning new ideas makes it harder to really focus on any one thing when trying to become familiar with a large number of tools and ideas in a short timeframe.

Overall the major ideas of Confront Your Ignorance are simple, and easy to implement , the big drawback being the time it will likely take to focus exclusively on one topic can often take time away from other activities. Like most patterns discussed in Apprenticeship Patterns, finding an effective balance between this pattern and others is important and likely dependent on context most of the time.

Book Referenced:

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman

https://learning.oreilly.com/library/view/Apprenticeship+Patterns/9780596806842/ch02s06.html

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

Apprenticeship Patterns: Dig Deeper

Another issue I have been facing as of late is related to my understanding of the systems and software that I use. I often find that I am able to learn just enough to meet the requirements for my assignment, but lack perspective of exactly what is going on behind the scenes. One class in particular that this was true for would be data structures, which was quite challenging considering I had no experience with any facet of it before then. This resulted in me learning exactly what I needed, nothing more or less, to succeed. Upon reflection of this class, I decided to choose the Dig Deeper pattern to discuss this week.

The first major tip given is one that I have often encountered in other patterns, being to break a problem down to its most abse form. As stated in the pattern, most programming issues can be broken down to an incorrect algorithm. Once the problem is broken down, you can examine each part of the problem in great detail, giving you a more in-depth understanding of both the problem and the tools used to solve it. Furthermore, the pattern states that you should focus on reading as much original documentation as possible since many articles may lose some information in translation. As for retaining knowledge, once again breakable tools are referenced, which I have discussed further in a previous post. Any new understanding can be represented in the form of a fun hobby program or blog post. Throughout the process of reading these patterns I have realized how interconnected they are, often relying on each other to result in well rounded software design principles.

One thing to note is that it does feel a bit strange to try and relate to these patterns, particularly because they are very clearly written for someone currently in the workforce in a software development position in mind. Regardless they still have some knowledge that will likely benefit developers at a variety of levels. This perspective being less relevant to me is my only real complaint, other than this I have found these patterns quite helpful! This will be my last post for the time being, but after everything I have ready I may have to return to this blog later on. Thank you for reading and, as always, if you want to read this yourself it will be linked below!

Source: 

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch06s04.html

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

What is the difference between a software framework and a software architecture？

Software frameworks are reusable “semi-finished” software for domains (such as ERP, computing, etc.) that implement common parts of the domain and provide well-defined points of variability to ensure flexibility and extensibility. In other words, the software framework is the softwarenation of the results of domain analysis and the template for the final application in the domain.

With the expansion of software scale, wide application and the development of software reuse technology, the software reuse based on subroutine and class has a lot of shortcomings:

(1) The library of the subroutine is becoming more and more huge, which makes it difficult for its users to master

(2) Most classes are too small to do all the useful work by themselves

It is for these reasons that a set of classes (modules) are considered as a whole in reuse, resulting in a software framework. The software framework contains at least the following components:

(1) A series of modules to complete the calculation become components

(2) The relationship between components and the interaction mechanism

(3) A series of variable points (hot spots, or adjustment points)

(4) Behavior adjustment mechanism of variable point

Developers through the software framework behavior adjustment mechanism, peculiar to the general application domain software module bound to the variable point of a software framework, and got the final application system, this process is called software example of a software framework, the existence of software framework allows developers will be the main energy on the development system of the module, so as to improve software productivity and quality.

The behavior adjustment mechanism of the software framework refers to how to adjust the variable part of the framework for the specific application and how to add the method and rules of the specific application module at the variable point.

Ii. Software architecture

Software architecture is a sketch of a system. The objects described by software architecture are abstract components that directly constitute the system. The wires between the components describe the communication between the components explicitly and in relative detail.

Software architecture, by definition, is divided into two camps of ‘constituent’ and ‘decision-maker’, which are described as follows:

The componentized view of software architecture is that the system is described as computing components and their interactions. It has two very obvious characteristics:

Focus on the object of architectural practice — software, with the software itself as the object of description.

This paper analyzes the composition of the software, and shows that the software is not a whole in the sense of “atom”, but a whole composed of different parts connected through a specific interface, which is very important for software development.

Decision-makers believe that software architecture involves a series of decisions, mainly including:

Organization of software systems

Choose the structural elements that make up the system, the interfaces between them, and the behavior that these elements exhibit when they cooperate with each other

How do you combine these elements so that they gradually synthesize into larger subsystems?

The architectural style used to guide the organization of the system: these elements and their interfaces, collaborations, and combinations

Software architecture is concerned not only with the structure and behavior of the software itself, but also with other features: usage, functionality, performance, elasticity, reuse, understandability, economy, and technical constraints and trade-offs.

Personal understanding: When software engineering has a certain scale, software development does not exist in the form of data structure + algorithm, but “divide and conquer” software based on many factors such as technical choices and user needs. The main task of the architect is to divide the software into different modules and define the interfaces between modules.

Sources:

https://softwareengineering.stackexchange.com/questions/229415/difference-between-an-architecture-and-a-framework#:~:text=An%20architecture%20is%20the%20the,that’s%20designed%20to%20be%20extended.&text=Frameworks%20are%20specifically%20designed%20to%20be%20built%20on%20or%20extended.

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.