Anyone interested in getting into front- or backend development (or DevOps) should take a look at this learning roadmap from medium.com. It gives a complete chronological outline of what someone getting into these fields should be learning and how to connect them together. They lay out a path of topics to learn in order to build up a robust and marketable skill set for modern web development.

To me these step by step roadmaps are something I never realized I needed. I’ve always looked things up and learned new pieces of the web dev puzzle as I needed them, and never really had a direction to go in. There are holes in my abilities that I didn’t necessarily know were there, and areas I knew I was lacking in but never knew how to work my way into them. These roadmaps give me direction to fill in these gaps in my knowledge.

In addition to giving a step by step list of topics to learn and explore, many steps give the reader choices in what to learn. For example, for the backend developer roadmap, it starts the reader with picking a language to learn and gives examples of different scripting and functional languages to learn. For relational databases it recommends at least learning MySQL and PostgreSQL but gives additional options for someone looking to learn more in that area.

Instead of learning whatever I need for a project or picking up whatever is trendy at the moment, I have a list of things to learn that lead up to that topic and provide a better foundation of understanding to connect each topic together. Not only do these roadmaps give lists of topics to learn, but they offer some guidance on how to explore them and apply these newly learned skills, like contributing to open source projects in various capacities. I think I’m now able to better understand why each topic is important and how it connects to each other piece of the puzzle, and where to take my web development education given my current skills.

From the blog CS@Worcester – Adventures in Computer Science by zachstevens2808 and used with permission of the author. All other rights reserved by the author.

In his blog post titled The Myth of the Full-stack Developer Andy Shora, a front end web developer from London, explains how he feels about web developers that claim to be “full stack” developers. Many web-based applications used to be built on a relatively simple “LAMP” (Linux, Apache, MySQL, PHP) stack, but in recent years the number of frameworks and architectures and frameworks available to web developers has grown enormously. Shora believes that with the modern abundance of software layers and architectures, developers can’t have enough of a mastery of each to really consider themselves full-stack.

It’s easy to become disillusioned with your own skill level in a field. While interviewing junior web developers, they were asked to rank their mastery of six different areas of development (UX, HTML, CSS, JavaScript, SQL, and a back end scripting language) on a scale from 1 to 10. They tended to rate their skill level in each area between 5 and 8, considering themselves full-stack developers with a moderate level of understanding in each area. When given 30 points to distribute between the six areas, instead of maintaining the same ratio between the skills they tended to highly rate some and rate others far lower. While they considered themselves full-stack developers it’s clear that they all understood that they had their strong skills and they had their “good enough” skills.

If you create some app that a lot of people end up using, it’s easy to get an inflated sense of your skills. While you might have created something that works in the end, it’s highly unlikely that you did so with full mastery of every single layer of your application. It’s possible to only have a minimal enough understanding of every piece of an application to put them together in a way that, at the very least, works.

I think it’s only becoming more and more difficult to really be a “full-stack” developer on today’s web. As more frameworks and architectures and layers are continually added, it’s almost impossible for one person developing every layer of an application to have a full mastery of all of them. I don’t think this is a bad thing, and I think this article has helped me realize that. While it’s important to be able to understand how different parts and layers of an application work together, I think that’s best left as its own role on a team. Everyone is able to specialize in their own area and someone else’s specialty is to coordinate how they come together.

From the blog CS@Worcester – Adventures in Computer Science by zachstevens2808 and used with permission of the author. All other rights reserved by the author.

In developing a project for my data mining class, I kept asking myself how I could objectively measure the similarity between two objects. These objects happened to be Magic: The Gathering trading cards, and I was attempting to build a card recommending system not unlike those used by YouTube or Netflix to recommend videos, TV shows, and movies. Essentially I wanted the user to be able to pick any card that exists, and have the system respond with a short list of the most similar cards. I knew the hard part was going to be determining what makes cards “similar.” The most important attributes on the cards are entirely text, and considering that there have been almost 20,000 unique cards printed since 1993, I didn’t even know where to start. All I had was a CSV file of every card ever printed with each card’s text attributes such as card name, card type (creature, sorcery, etc), and the actual effects and rules of the card.

This is where machine learning engineer Christian S. Perone’s blog Terra Incognita comes in to save the day. He explains the use of tf-idf to convert a textual representation of data (like my Magic cards) to a vector space model: an objective, algebraic model of a card’s attributes. The tf-idf of a document (trading card) is the product of two statistics, the term frequency (tf) and the inverse document frequency (idf). The term frequency measures how often a term appears on a specific card, while the inverse document frequency essentially measures how important the word is to that card; if a word is frequently used on a card but appears on most cards, it doesn’t provide us with much information. Now that we know about this tf-idf statistic, we can construct a matrix that contains a tf-idf measure (i.e. how important a word is) for every word on every card.

Now that we have a numerical measure of importance for every word on every card, we need to find cards with similar tf-idf vectors to the card selected by the user. Perone explains the popular cosine similarity method, which takes two vectors and returns a real number value between 0 and 1. We just have to find the cosine similarity between our chosen card and every other card ever printed and return the most similar cards.

Perone very clearly explains these techniques in both plain English and with precise mathematical notation. The entire process has taught me an enormous amount about processing textually represented data, and mathematically following human intuition about what makes two things “similar.” I know that the skills learned through this project are going to be invaluable to me, and they’ve certainly changed the way I think about textual data.

From the blog CS@Worcester – Adventures in Computer Science by zachstevens2808 and used with permission of the author. All other rights reserved by the author.

Having done very little work in JavaScript, our recent use of TypeScript in class has had me wondering what benefits the language brings over plain old JavaScript. In addition to the numerous concrete benefits of the language that one could look up, Llorenç Muntaner, front end engineer at Onedot, gives a different reason for using TypeScript. Muntaner’s praise for TypeScript as a language stems from his opinion that it has made him a better developer.

Types make he developer think carefully about the code.

Muntaner makes the point that adding the parameter and return types for a function makes it easier to understand, and static typing in general makes it clearer what models you are working on. This is how static typing helps a developer think about and gain a clearer understanding of their work: code becomes more easily readable, and the developer can more quickly understand and make changes to existing code.

I think that these benefits easily outweigh the “burden” of having to write the types. As someone who mostly uses Python for person projects, advocating for a language that specifically adds static typing to JavaScript may sound hypocritical but what I like about both languages is their focus on readability for developers. However both languages accomplish this goal in different ways.

One of Python’s most frequently touted features is its easy readability do to its use of plain English keywords and its lack of curly braces. This makes the language easier to read while allowing developers to focus more on what their code should be doing. TypeScript offers a different kind of readability, in almost the exact opposite way. Since TypeScript is a superset of JavaScript and generally uses its syntax, the more complete and robust syntax feels almost like its missing something without static typing. Instead of the feeling of a clean readable syntax that Python brings, JavaScript’s dynamic typing feels more like an ambiguity. TypeScript removes that feeling of ambiguity with its static typing, leaving developers to know at a glance what they’re working with.

From the blog CS@Worcester – Adventures in Computer Science by zachstevens2808 and used with permission of the author. All other rights reserved by the author.

An API, whether designed for private internal use or public use, needs much careful consideration during development to be useful. It requires to not only implement the desired functionality, but it must also be reliable, well designed, and easy to use.

The RestCase blog post titled REST APIs: From Idea to Release outlines the creation of a “minimum viable product” (MVP). This is the minimum implementation of a product with enough features to release to early users for testing. Many companies will opt to create an MVP the easy way, building functionality into the initial release of an API without building in the necessary reliability and usability. A proper MVP should provide both the minimum functionality as well as the reliability and usability of a final product. However it can be difficult to build a good MVP for an API considering the applications that depend on them. If applications are developed that depend on an early MVP of your API, it can be hard to update and improve on it without breaking those applications. A common downfall of APIs is a constant release of updates that break integration with existing applications.

Taking the time to test your API can be a big investment, but it is an important one. Getting feedback from your core users about your API early in its development cycle can help shape the API to their needs. If you commit yourself to a design or an implementation before testing, it could be too late or too expensive to change it based on feedback. This testing/feedback cycle sacrifices speed for quality, but ensures a functional and usable API based on what your users need.

One useful testing cycle for API development is slowly opening up new versions for testing to specific groups. Start by organizing a developer focus group, which opens up your API to developers that will actually use it. After, follow up by publicly mocking up the feedback from the developer focus group, and use that to start a beta or invite only testing group for real-world testing. After building a beta/invite community and updating based on their feedback, it’s finally time to release your new or updated API.

From the blog CS@Worcester – Adventures in Computer Science by zachstevens2808 and used with permission of the author. All other rights reserved by the author.

Hi, my name is Zach and here I’ll be sharing my experiences through my education at Worcester State University and beyond!

From the blog CS@Worcester – Adventures in Computer Science by zachstevens2808 and used with permission of the author. All other rights reserved by the author.