Craft over Art is a drastic change in tone from the rest of the patterns I have covered. All of the previous patterns I have read have been about how to advance myself as a developer, while this pattern is more how to act as a developer. Craft over Art stresses the importance of providing a useful product for a customer instead of a wildly experimental one that might not work. I would argue that this still is about advancing myself as a developer, but in a different, more practical way.

Obviously I should continue to do everything else discussed in these patterns, but I feel like Craft over Art will be the most immediately useful. This pattern can be implemented day one of your first job. It also is the most important pattern for your employer, since they care about actual products. I would imagine many apprentices are very excited to enter the industry and make something amazing, but this is simply not the reality of the profession. Real customers want products that work, do not need complicated maintenance, and are industry standard.

Craft over Art then goes on to explain that when you are rushed to deliver a product you must make compromises between beauty and utility. These compromises will inevitably lead you to a mistake, and you will need to fix it. This is a good thing, the pattern argues, since only by fixing things do we realize which compromises are the correct one.

This idea is a liberating one for me. The fact that I need to mess up in order to learn means that people will expect me to mess up. I feel like this takes a weight off my shoulders. The stress of working on real products with real customers is one I think is very common.

I am glad I read this pattern for my last blog post. I did not plan it, but it was a very nice surprise. Over the course of a semester reading about how I should improve myself, it is a nice shift to learn about how to provide a useful product for my customers.

From the blog CS@Worcester – Ryan Blog by rtrembley and used with permission of the author. All other rights reserved by the author.

Stay in the Trenches is about how you must stay on your path and focus on learning rather than promotions. If you are offered a promotion which takes you away from what you want to do, you should reject that promotion. This of course does not mean that you should never accept promotions or advancement, but you should always remain focused on what you want to do with your career. This pattern implies that you want to program, and I do, but I can see this pattern applied to many more disciplines.

Over the course of all these patterns one thing has been emphasized more than anything else: as an apprentice, your primary goal should be to learn. This pattern spells that out more than any other. This pattern is a very tough pill to swallow, but it is very good advice. Sometimes you need to be told things you don’t want to hear, and should listen to advice from people who have made mistakes before you.

I like this pattern since I am a very promotion oriented person. I can see myself taking the quick promotion and I needed this pattern to guide me on the right path. Throughout my working career I have taken the promotion when I should not have. This is different from what Stay in the Trenches is talking about, but it shows what kind of person I am. I need to be aware of that going into the future.

One thing I wonder about is when should I take the promotion? You are always able to learn, when have I learned enough? Fortunately I don’t have to worry about this for a while, and I think that it is an easier decision than I’m thinking it is. Right now I do not have the experience to tell what I want to do, and what I’m ok with not doing.

The pattern also suggests that instead of taking the promotion you should work with your employer to find other, more advanced tasks that you can take on. I like this idea since it allows you to continue programming, but it also might not offer the same pay or benefits.

Overall I like this pattern, it is one of the better ones I have read so far. I think my favorite patterns are the ones that tell me things I don’t want to hear; things I already agree with is not really teaching me anything. It is easy to take the advice of work hard, but not so much to pass up promotions.

From the blog CS@Worcester – Ryan Blog by rtrembley and used with permission of the author. All other rights reserved by the author.

One thing that the field of Computer Science is rather notorious for is that, for new learners, the entry level may seem incredibly low for someone who is interested in pursuing programming in any degree. Given the abundance of freely available resources for learning programming languages, this should not be that much of a surprise. It is easy for someone to find a tutorial online on how to implement inheritance in JAVA, with such tutorial presenting this concept through some oversimplified example. This, in and of itself, is not a bad thing; it is important to learn things in smaller steps. However, some software development apprentices may take to simply memorizing the knowledge they acquire and how to simply implement the tools available to them without much understanding, thus acquiring only a superficial understanding compared to a deeper, more thorough understanding, which in the future may become a habit that can interfere during the development of bigger projects. This situation is introduced as a pattern titled “Dig Deeper”.

What this pattern means for an apprentice developer is that, oftentimes, they may have found themselves in part of the development where their technical knowledge at that point in time may seem to be lacking because the superficial knowledge they have gained during the learning process was not sufficient to provide meaningful contributions in a project of a larger scale, especially in a professional environment. For example, someone who may be working on deploying a web-based application may run into this pattern. The apprentice, though they may know a bit about how REST APIs may work, they may still find themselves struggling because the project they are working on presents concepts that are impossible to cover in a simple tutorial. The apprentice may know how to implement functionality on the backend, but have neglected to get a  deeper, understanding of how such functionality may impact the frontend. Thus, when something in the frontend fails because of the backend, the apprentice may provide a solution that in the long-term does little to solve that problem. Overall, an apprentice who, regardless of their proficiency in their area of expertise, does not take the proper care to understand how such expertise may interact with other areas can hinder the long-term maintainability of a project, as well as have a negative impact on the apprentice’s own learning process.

While it is impossible to be an expert on every single concept and tool that exists ,not only within one’s area of expertise, but also for every single area that may constitute a bigger project, it is still important to take the time to gain a deeper understanding of how other areas work in conjunction to one’s expertise.

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

Similar to prior weeks, you have a basic set of skills, and your understanding of software development is narrow and small. Expanding your bandwidth allows you to further expand your horizons and learn more. The best step to solve this is to take in new information, but it is important to do so carefully, as it is easy to be overwhelmed in the information intake.

Some examples of ways to gather the new information is through following software development blogs, following software developers on social medias like Facebook and Twitter, and subscribing to a software development mailing list, just to name a few. There are also many hundreds of online courses and videos as well, so there is no shortage of information to be had. Following software developers can key you into new technologies before they become widely popular, which can give you a head start into the game before others. There are also national conferences that you could attend as well, and another great thing to do is to read any books some of the speakers have written in the past, so you can help get an idea of what they will be talking about and their software development history.

However, it is just as important to know when to expand your bandwidth then just how to as I explained above. It is possible to get stuck with the gathering of information, and it can easily happen where you get stuck researching and learning and never go back to creating any software. It is important to use this skill to accelerate your learning, but it is also important to not get stuck with the learning, learning is a means to an end, you must come back when you are done with the learning. Usually it is recommended to not spend more than a few months with this learning process, as that allows you to not get stuck in the learning process, as it is not too long, but it is also not short enough to the point where you do not learn much of anything at all.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.

Rest API are a common method for integrating applications in their services to provide more reliability and to be flexible where possible. I chose to use stackoverflow.blog as my blog because they are filled with information in regards to many programming languages, AI, databases, especially Rest Api and etc. The blogs also discuss and provide certain authors that give explained details on the processes and focus on implementing, as well as common problems that may erupt with certain solutions that can lead an aid to a professional career in software development world. As this website have given me a clearer perspective while in my Software Construction architecture class along the way working on our Food pantry project.

As for Rest Api, they are a common web service used in today’s technology. Allowing the client (person making the request) to communicate with the servers (receiving the client requests) with is the Rest Api that is connected to a database. To keep in mind, when creating an API, we use always separate the client from the server to made to interact on one way because due to fact that clients can make requests but not responses, while server can make response but not requests. We use HTTP methods as an action for the client wants to make. GET Method allows the clients to request the information from the backend. POST Method is creating or listing the information. PUT Method is editing the information. DELETE Method allows the deletion of information.

JSON (JavaScript Object Notation) is a basic format to help the programmer to easily read write out code for the computer to understand and generate the output and cache the responses. API endpoints are the end of the communication, which utilizes the services or the response. For example, when making a request on the API rom the browser or an application, the response will then be received that reaching that point will be the endpoint. 

After learning about REST API in my CS-343 class and working along the course. I start to begin to gain more confidence and gain more insight on how the process works. And designing the API which gave me complications for the backend and frontend as well. Realizing even the slightest misspelled command or wrong path can leave you clueless on fixing the problem but understood why the situation erupted. This material could’ve been useful for my database course I have taken previously to implement the databases on the server to be integrated along with providing the appropriate security from the client side with restrictions, while the backend is able to store, modify if allowed. 

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

Front end and back end development get thrown around a lot, but I never really understood the difference. Therefore, I decided to do some research and figure out what front end development and back end development are, and what the difference between them is.

Let’s start with front end development. Front end development, also known client side development, deals with the user interface. The user interface, or UI for short, is what the user gets to see and interact with. Front end developers are responsible for designing and creating the user experience elements in a program. Front end developers may find themselves using technologies like Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), and JavaScript to implement features such as buttons, menus, pages, and so on. The goal of front end development is to create attractive, simple, and easy to follow interfaces for users. However, achieving this goal can get quite complicated due to a major challenge. This major challenge is the sheer amount of variance in devices. Not all devices are the same. There are devices that are big and small, fast and slow, and new and old. Guaranteeing a consistent experience across all devices and platforms is a very difficult task but is an essential one. This gets further complicated with the rapidly evolving technologies, standards, and practices.

Now, back end development, as you might have guessed is the complement of the front end development. If front end development deals with things that the user can’t see then back end development deals with things that a user cannot see. Back end development, also known as server side development, deals with servers that provide data on request, the applications which channel those requests, and the databases which organize the information. Back end developers might find themselves using databases such as IBM DB2, MySQL, and NoSQL as well as a bunch of programming languages and frameworks such as Java, Python, and C++. The goal of back end development is to design and create applications that can accurately locate and deliver data to the front end as smoothly as possible.

While developers usually just specialize in either front end development or back end development, sometimes employers need developers who are proficient on both ends. This is known as full stack development, and these highly specialized developers are known as full stack developers. Their job is to use their deep knowledge to suggest ways to make the development process more efficient.

https://www.conceptatech.com/blog/difference-front-end-back-end-development

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

In class, we’ve been using vue.js. Vue.js seems to have many similarities to React, so I thought it would be informative to briefly discuss how to implement React components. Vue.js seems to also use components, so I thought it would be helpful to explain a common concept that seems to exist between the two.

I open visual studio code, and open the terminal. To create a react app, I typed the following commands:

• npx create-react-app reactapp
• cd reactapp
• npm start

After React finished installing, I changed my App.js to this:

This component’s render() function will display the content on the webpage using JSX¹. There is currently nothing but an empty screen. Instead of writing everything inside a component, we should segregate the information into separate components, that would then be called in this central component.

For this example, we’ll create a webpage with four parts: a header, a navbar, a side pane, and a main pane. Each component will contain its own js file. Since we’re making a very simple web page, the header will be a simply designed bar. I created a blue bar in Paint, and I imported it using CSS. The header will contain a title, and compose the top of the web page.

Below the header should be the navigation bar. For the sake of example, the navbar here will just display the formatted text on it. The navbar would in practice function as a transition between web pages.

Next is the side pane. This side component on a website could function as a way to automate section traversal, as is done on a wikipedia page. If the main section has a title such as “Lorem Ipsum”, it would list “Lorem Ipsum” with the ability for a user to highlight and click on it. Like the navbar, we’ll only create a very simple display.

The final component is the main component. This component will be where we put our text. I created a title called “Lorem Ipsum”, with some body text.

We now need to add our components into our previous App.js file. The top will contain the header and the navbar, and the body will contain the side pane and the main pane.

Finally, we need to create the CSS. For my design, I am using this inside of the App.css file, which is then imported into App.js.

For our product, we get this (the bottom part was cut in the screenshot for space):

While it’s not winning any awards, it’s a draft of a simple website design. This illustrates how components work together, in a library like React, and I hope this helps with understanding vue.js too.

Link:

1. https://www.youtube.com/watch?v=w7ejDZ8SWv8 (For discussing how components and JSX work, so I could make this guide!)
2. https://reactjs.org/tutorial/tutorial.html (ditto)

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