Author Archives: zachstevens2808

Becoming a better developer with TypeScript

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.

REST API Development & Release Cycle

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.

Introduction

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.