So you wanna build a Single Page Web App (SPA). What’s your angle fat guy? I just wanna help man! Ok let’s take a step back here and cool off. Let’s shift our focus to building our single page web app. One of the products best suited for developing SPA’s is Angular. What is Angular? According to this article on Sitepoint, Angular is a client-side JavaScript framework. A what? A tool that helps you develop a web application while defining how it should be designed and how it should be organized. Using Angular you’ll mainly focus on TypeScript, HTML and CSS. Wait, I thought you said it was a JavaScript framework? It is, the compiler takes the TypeScript files you create and converts them to JavaScript for display on the web. What’s the difference? Look man this will go a lot quicker if you stop interrupting. Read this article on geeksforgeeks.com to see the difference between TypeScript and JavaScript. So where do we start with our first Angular project? Let’s get our feet wet and jump in and do the Getting Started Tutorial on Angular.io It’s a great tut that walks you through creating a small ecommerce web app and introduces most of the early framework principals and techniques. Check out my next post to see some example of creating more complex SPA’s and components. #CS@Worcester #CS343
So you wanna build a Single Page Web App (SPA). What’s your angle fat guy? I just wanna help man! Ok let’s take a step back here and cool off. Let’s shift our focus to building our single page web app. One of the products best suited for developing SPA’s is Angular. What is Angular? According to this article on Sitepoint, Angular is a client-side JavaScript framework. A what? A tool that helps you develop a web application while defining how it should be designed and how it should be organized. Using Angular you’ll mainly focus on TypeScript, HTML and CSS. Wait, I thought you said it was a JavaScript framework? It is, the compiler takes the TypeScript files you create and converts them to JavaScript for display on the web. What’s the difference? Look man this will go a lot quicker if you stop interrupting. Read this article on geeksforgeeks.com to see the difference between TypeScript and JavaScript. So where do we start with our first Angular project? Let’s get our feet wet and jump in and do the Getting Started Tutorial on Angular.io It’s a great tut that walks you through creating a small ecommerce web app and introduces most of the early framework principals and techniques. Check out my next post to see some example of creating more complex SPA’s and components. #CS@Worcester #CS343
This will be two parts post, I will talk about the SOLID principles and try to cover all of them from the way I understand SOLID,
First SOLID was introduced by Robert C. Martin (Uncle Bob), in his 2000 paperDesign Principles and Design Patterns.Uncle Bob also well known for his book Clean Code, I studied this book in my CS-338 class, it was great book in changing the way of coding. and how to writ a clean code.
Going back to SOLID. SOLID is a shortening for 5 important design principles Object Oriented Programming
S — Single responsibility principle
O — Open/closed principle
L — Liskov substitution principle
I — Interface segregation principle
D – Dependency inversion principle
I will talk about the first tow principles in this post.
Single responsibility principle
It means that every class and module should be responsible
or have responsibility of a single part of the software functionality. It is
like do one thing and do it well. Uncle Bob defines a responsibility as a ‘reason
to change’ which means that the class or the module don’t need more than one reason
to be change.
For example lets look to this code:
This code violates the SOLID first principle, the method CreateBlog() has to do many responsibilities, create a Blog, and log an error in the DB and also log an error in the file. which is absolutely the opposite of the Single responsibility principle
class Author
{
void CreateBlog(Database db, string publishtText)
{
try
{
db.Add(publishtText);
}
catch (Exception ex)
{
db.LogError(“There is an Error: “, ex.ToString());
File.CheckAllText(“There is a Local Errorn in.txt”, ex.ToString());
}
}
Lets try to fix the problem in the code above.
class Blog { private ErrorLogger errorLogger = new ErrorLogger();
class ErrorLogger
{
void log(string error)
{
db.LogError(“There is an Error: “, error);
File.CheckAllText(“\There is a Local Errorn in.txt”, error);
}
}
We created two classes each one of them will handles one responsibility,
and that will no longer violate the single responsibility principle.
Open/closed principle
It means that the software entities (classes, modules, functions, ….) has to be closed for modification however has to be open for extensions.
We know from the Object-Oriented Programming or OOP, the polymorphism , and I posted a blog explaining about polymorphism. In another word we need to create inheritance or implementing an interfaces in the code to make sure it is compliant with the open/closed principle
lets look to this code and see whether it is applying the Open/closed principle
class Blog { void CreateBlog(Database db, string publishtText) { if (publishtText.StartsWith(“!”)) { db.AddAsTag(publishtText); } else { db.Add(publishtText); } } }
What we want in this code is to do a exact one thing which is the every time a published Text start with the character ‘!’, the code is violates the open/closed principle. If in the future we needed wanted to include mentions all the published text starting with ‘#’, then modifying the class with an another ‘else if’ is a must added to the method().
Lets try to fix the problem in the code above.
class Blog { void CreateBlog(Database db, string publishtText) { db.Add(publishtText); } }
class TagText : Text { override void CreateBlog(Database db, string publishtText) { db.AddAsTag(publishtText); } }
It is much easier to create extended behavior to the Blog object by using inheritance and overriding the CreateBlog() method.
That is all I have for this week, and next week I will continue on the SOLID principles and talk about the other three principles .
For my last blog for this course instead of taking one
particular course subject, summarizing it, and theorizing about what actual
implementations may look like – I’d like to look at the whole course and do the
same. More specifically, I would like to cover how bugs or defects are actually
addressed, or not, in Software Development and Testing. To do this I have found
some interesting blog posts which argue that 100% of bugs may be able to be
fixed, but shouldn’t be. Instead, one should focus on serving the vast majority
of users under expected circumstances.
Both blogs
focus on how impractical, and expensive, maintaining 100% stability or up-time
is. In the first focusing on bugs specifically they give many reasons why this
goal is unadvisable. The first is the prevalence of Agile Development,
dominating nearly the entire software development landscape. As such, the constraints
of this fast-paced development style limit the ability to do traditional QA testing;
if a program can have several revisions in a week, maybe even a day, then how
could a team reasonable test all these iterations. Instead, the author suggest
a stability monitoring tool to automatically test each revision.
In
addition, they suggest that eliminating 100% of bugs would eliminate many which
users would never see, so why waste resources addressing them? Even if you
could fix everything how could you possibly know? This focus is reinforced when
considering the truly incredible breadth of devices that one may have consider,
and specifically in mobile development: where they cite the over 24,000
different android devices on the market. One must focus on the average expected
user experience and not waste time fussing with the outliers until, presumably,
a bug report is filed.
The second blog discusses
defects in systems in a similar way, covering more or less the same points, although
mentioning a rather obscure possibility: being legally challenged for claiming
that your product has no defects. Instead, what I believe they are trying to emphasize
is that products are always fallible, and the amount of resources required to
get them even close is impossible or impractical. As a result, as we move
forward in this class and towards graduation I think we should resist the impulse
to try for complete perfection and instead focus on what is achievable and
provides the best experience for the majority of users.
Let’s start by discussing javascript a bit. Javascript is currently a must know programming language in the computer science world. It is widely used for web development on both front-end and back-end development. Javascript can also be found in many other fields of development including mobile apps, desktop apps, and game development.
Javascript language is quite user friendly and can even be considered easy to learn but it doesn’t come without its concerns of course. The same code you’ve written may work differently when used in different browsers such as Google Chrome versus explorer, or safari, for example. Javascript is also very stripped down so it can be easy to create errors by mistake especially for beginners. An example of this is that Javascript is dynamically typed. Programs don’t know the types of variables until they are assigned at runtime and then they must do an awful lot of referencing to figure out the type depending on the size of the program. Since types are not required there are no compiling errors or messages to tell you what you are doing wrong. It leaves a hard traced error if or not careful when working with your code.
Now moving on to Typescript!
Typescript is a superset of Javascript which means it contains all the same functionality of Javascript as well as added features. Typescript compiles to plain Javascript so any code you write in Javascript will run just fine in Typescript, as long as you have written it correctly of course. The big additions of Typescript are type annotations, interfaces, and classes.
As opposed to Javascript, which is dynamically typed, Typescript uses static typing. Static typing means that things like variable types can be checked at compile time since variable annotations are available. The code will still run if you have an error but you will receive a message warning you about the specific error that was detected. Also depending on your IDE it may offer the function of displaying errors to the user while they are typing. If you want to take advantage of this functionality then you can check out the Visual Studio Code IDE, which contains that function.
I chose to blog about this subject because I am a newcomer to this language and material. I figured if I did some research on my own and actually typed out the words then it would all become more clear to me what the relationship of Typescript was to Javascript and what they are used for in the real world. I feel now that I have this general overview and understanding of the language and its use that I can now conceptualize my own uses for it. I’m looking forward to implementing what I have learned about Typescript into my own projects.
Lease, Diana. “TypeScript: What Is It & When Is It Useful?” Medium, Frontend Weekly, 31 Jan. 2018, medium.com/front-end-weekly/typescript-what-is-it-when-is-it-useful-c4c41b5c4ae7.
In my Testing class we are constantly learning some new techniques and ways to test software, although there is some hands on testing on actual code a lot of it is more theoretical or to be more specific it is describing how we can test. It is all useful I know it but as a CS major I do want to write code if possible, less theory please, more practice. End of rant? Maybe for now.
This week was about Define-Use Testing. It is somewhat simple concept and I am glad that I can learn about it. It showed us some of the ways that today’s compilers work and make comparisons to display errors in the code. The whole concept of Define-Use testing is all about visual inspection and checking of the code. This will be some useful information for certain aspects of Computer Science field.
TypeScript, is it really a better
version of JavaScript? If you are like me and you never used JavaScript before
and then were told that TypeScript is better you will probably have the same
reaction, “OK, so what?”. Well it turns out it is a very useful thing, it is a wrapped
version of JavaScript that will pay attention to the types of variables used
and so on, hence the name. In my search for some answers I have stumbled upon THIS blog by Valentino
Gagliardi named TypeScript Tutorial For Beginners: The Missing Guide (2019).
Like it says it is a whole tutorial, but it also explains in some simpler words
what TypeScript is and why it is useful with a lot of examples. I will go through
it and then look for some more. What helped me right away was Valentino’s explanation
of what is TypeScript: “The definition from the official website says: “a typed
superset of JavaScript” but it assumes you know what a “superset” is and what
“typed” means. Instead to keep things simple you can think of TypeScript as of
“a layer on top” of JavaScript.”
Most of the blog is what it is
supposed to be, a Tutorial, and in my opinion it does it in a very good way, he
starts in an easy way to show certain things, even when somethings is not right
away understandable Valentino comes back to it later and explains in more
detail, what is a plus for me as well is that he does in somewhat humorous way
and that makes the whole learning a more easy going process. Having those kinds
of Tutorials is very helpful for me because knowledge can be learned but what
needs to happen is also the understanding of when and where to apply said knowledge
and with this blog post I’m starting to understand that about TypeScript.
Learning in school about best tools to perform today’s jobs and being able to see it in action before I am thrown into the deep end is a huge plus for me and it should be for everybody else as well. I am always very grateful for the opportunities like this one. I have found out that the TypeScript is used at my work in other departments which tells me it is a good thing to learn and maybe use to further my career. I cannot wait to start writing some more advanced programs in this format, but everything needs to be done slowly, you must learn to walk before you can run and I do intend to be able to run eventually.
This week let’s take another peek at the FoodKeeper API. We’ll review the endpoints and how to submit a request to retrieve data. Before we jump into this you need to download and install a REST client. I highly recommend Insomnia, the app not the sleep disorder, (download it here) I’ll wait… Now that you have Insomnia installed let’s talk about endpoints. Last week we covered the four primary HTTP verbs used with REST. Did you have a chance to visit https://www.restapitutorial.com despite the name of the website these aren’t tutorials on how to make REST calls but more like development guidelines for developers writing REST API’s.
So why did I recommend it? Because understanding how a good RESTful API is designed will make it easier to craft your REST calls. So the 4 basic HTTP verbs (POST, GET, PUT and DELETE) are CRUD (Create, Read, Update, Delete) operations. · POST = Create · GET = Read · PUT = Update · DELETE = Delete Kind of makes sense, right? These also make up the endpoints you access with your REST client. In JAVA we add an annotation to the class and the getter and setter methods to define the endpoint. For the FoodKeeper API we are using the Spring Framework (https://spring.io/) to help setup the Rest components. After all the imports are declared the class must be annotated with @RestController so that the compiler knows how to process it. Each endpoint must be annotated to reflect what it does. A POST endpoint would be annotated like this: @PostMapping(“/list/new”) The part in parenthesis indicates the URL path that you would pass as part of the REST Client call and is the actual endpoint. Let’s look at an online example. In a new tab on your browser go to: http://dummy.restapiexample.com/ The site lists 5 public endpoints you can practice against: · GET /employee · GET /employee/{id} · POST /create · PUT /update/{id} · DELETE /delete/{id} Note the curly braces with id in between them – this indicates that you will be passing a value.
Open your REST client, in Insomnia you would type in the URL in the White field in the top center of the screen and select the REST Method to the left of it: Click the Send button and watch the Right hand column you will see it populate with employees. This is the first entry in the list that was returned for me: Play around and get familiar with your REST Client and hit some of the other endpoints at
http://dummy.restapiexample.com/ TIP: For the endpoints above with {id} just append the url string with a number like this: http://dummy.restapiexample.com/api/v1/employees/6821 All right go play and learn something! #CS@Worcester #CS448
This week I have chosen to deepen my understanding of REST API. The article, “RESTful API Design Tips from Experience” by Peter Boyer, goes over good RESTful design practices. The article covers many topics, including some I do not have experience with but are still useful for a greater understanding overall.
The article proposes that the API should state its version
in the URLs. The author suggests adding a prefix to all URLs to specify API
version. This makes the eventuality of version updates easier to handle.
A simple tip mentioned in the article is the use of plurals.
When designing endpoints, plurals should be used instead of the singular form.
This is to avoid possible misunderstandings of what the endpoint is used for.
Example: /orders/customers VS /order/customer
Another tip in the article is to use nesting for
relationship filtering. From what I understand, it is better to have multiple
path variables for filtering than the use of query strings. The example in the
article is very clear on the tip. Following this advice will make your
endpoints easier to read.
The author advises to keep your API as flat as possible. He
suggests that creating and fetching data should have a longer resource path
than updating and deleting data. I do not really understand why this is the
case. My best guess is the shorter path reduces unnecessary processes.
The next tip I found interesting was the important, if not
obvious, idea for pagination of results. When working with larger databases, requests
can have thousands of results. Since it would be impossible to display all the
data, it makes sense to partition the results into pages and return one page at
a time. Pagination can also significantly reduce the expense of a request.
The last tip I will mention from the article is the usage of
status codes. HTTP status codes should
be used consistently and properly. This means the status should use the proper
code and provide additional details when necessary: an error code with a
message of why the error occurred.
Overall, I found Boyer’s article to be very informative. I
only mentioned a few of the topics raised in his article but all the topics are
interesting and useful. Reading through this article gave me a better
understanding of the nuances of RESTful API design and has helped me comprehend
my current coursework (CS343) better. I suggest to anybody that is new to REST
to read this article.
This week in CS-343, I was introduced to TypeScript, a
scripting language that uses typed variables to prevent coding errors caused by
mismatching data types. My introduction to TypeScript was my first time working
with a scripting language, and I am really looking forward to learning more
about it and using it to write new kinds of programs. However, the tutorial I
did in class was rather simple, as it only showed how to set up a basic project
in TypeScript. To learn more about this new language, I decided to research
TypeScript’s other features. I eventually came across a useful blog post by
Nwose Lotanna titled “New Features in TypeScript You Didn’t Know Exist.”
As the title suggests, this blog post discusses several
features of TypeScript that were introduced between versions 3.0 and 3.4. Each
feature has a short description that explains why it is useful, and many are
also demonstrated using example code. The post seems to be targeted at developers
who are experienced with TypeScript, which made it difficult for me to
understand every feature it discusses. However, there are a few features listed
in the blog that I could definitely see myself and other newcomers to TypeScript
making use of even in simple programs. I chose to discuss this blog to help spread
information on these useful but often overlooked features.
The first feature discussed in this blog is project
references. As of TypeScript 3.0, it is possible for one TypeScript project to
reference another by referencing its tsconfig.json files. This feature is
heavily reminiscent of the import feature in Java or the #include
feature in C, which have proved invaluable in my experience. Having the ability
to reference code in other files helps keep projects simple and organized, which
will undoubtedly be just as important in TypeScript as it is in other
languages.
Another feature discussed in the blog that caught my
attention is TypeScript’s BigInt object. BigInt was introduced in
TypeScript 3.2 and allows programs to use numbers greater than 253.
While I can’t recall a time where numbers that large were necessary, it is nice
to know that the option exists in TypeScript. There are certainly potential
uses for such large numbers, such as the Fibonacci function that Lotanna uses
to demonstrate the feature. Should I ever need to write a program that uses
numbers of this magnitude, I would certainly take advantage of TypeScript’s BigInt
feature.
A third TypeScript feature that I expect to be useful is the const assertion. Since TypeScript 3.4, it has been possible to declare
arrays and objects as read-only constants using the syntax demonstrated by the
example code in the blog post. Though the syntax is different, this feature
seems to function just like C’s const and Java’s final keywords.
Having used these features frequently, I expect TypeScript’s const
feature to be useful in many programs to ensure that the values of certain variables
cannot be changed.
