[W]in Tech

CS SERIES (9).pngOver the weekend, I had the chance to sit down and listen to another podcast episode by Developer Things. The title, Women in Technology (with Megan Horton), caught my eye as I am always on the lookout to learn about other women’s experiences in technology.

The podcast series’ goal is for people to learn new developer things each time they listen so here’s what I learned on the career side related to software construction, design, and architecture:

  • The stigma of “nerds” begins in elementary school so girls start to stray away from STEM even in the limited amount of programs there already are for computer science in earlier education years. This eventually results in the number of females in CS in universities–like mine–is so low along with the numbers of those who move onto the software development workforce.
  • There are jobs out there like writing software for watering fields based on whether the sun is up or down or varying weather conditions. It reminded me a bit about how we used duck stimulator as an example to learn UML diagrams and had different actions performed for each duck.
  • Career advancement is not always a straight path. People tend to switch into computer science as a major or switch into technology when they want a career change. I’d like to point out how the host of this episode took the opportunity to say Horton came from the funeral business to killing software bugs.
  • You won’t always have to write code: there’s so much out there–you could have a passion for anything and do something tech-related in that setting.

The content has caused me to think more deeply about what I will do in technology, I mean of course I’m going with software development or software engineering but what is the overall goal throughout my career timeline going to be? What kinds of companies will I end up working for? What projects or passions will I follow along the way? Overall, I enjoyed the podcast with Horton as she discussed the ups and downs of being a female in technology and her experiences in the industry so far.

I don’t think I was there for the time when people would be kicked off the internet because someone needs to use the phone as discussed in the episode but I do experience times when my connection isn’t consistent. It really makes me sit back and think about how technology relies on constant power and a steady internet connection.

A major takeaway that I continue finding myself writing about is how we will always be learning something new in technology as things are always changing–as long as the power is on.

Podcast: https://stackify.com/podcast-women-technology/

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

Good Methodology for user testing methods and boosting app development

 

For this weeks blog post I found an interesting blog that listed 6 user testing methods that may seem unusual to others. User testing is a very important part of any good software project, it reveals any bugs you may have skimmed over or glitches for that matter because of this you can make a cleaner product. Using a prototyping tool to user test with interactives wireframes and high-fidelity prototypes you will know exactly how users interact with your app before the real thing is even built. If you were to publish something, then change it later it’ll be much more expensive to change the finished product than a product. The site goes on to mention computer-based testing software but goes on to say human testing is much better considering you are making something for humans to consume/use. The first method they list is participatory design, this essentially is when end users are involved from the very early stages of the design process, working together with you or the design team to define the product you make. Instead of the you are imagining yourself in the shoes of the user, you put the user in the shoes of designers. The second testing method they list is something bit unusual, Drunk people. This may not be the best but what they list is a pretty interesting idea. The testing method involves you testing you own wireframes. Interactive prototypes such as wireframes and more are the way to go when it comes to testing, these prototypes will help you introduce user testing throughout the various stages of development helping you along the way. The next testing method they list is Triading, which is essentially you trying to get the user to compare and evaluate 3 different alternatives without you influencing them with your questioning. The 5th method they go on to explain involves the users creating their own user tests. Here they referenced a Ted talk by Luis Von Ahn describing massive scale online based collaboration. The final testing method they mention is product reaction cards which is almost as simple as it sounds. Essentially the user gets exposed to the piece of software then given cards with adjectives written on it where they are asked to describe the software using 3 – 5 of the cards. This is a super simple and helpful user based testing method that I like a lot actually. All in all this blog post was very interesting with all the simple user based testing methods anyone could conduct.

 

https://www.justinmind.com/blog/user-testing-6-methods-you-hadnt-thought-of/

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

Good Methodology for user testing methods and boosting app development

 

For this weeks blog post I found an interesting blog that listed 6 user testing methods that may seem unusual to others. User testing is a very important part of any good software project, it reveals any bugs you may have skimmed over or glitches for that matter because of this you can make a cleaner product. Using a prototyping tool to user test with interactives wireframes and high-fidelity prototypes you will know exactly how users interact with your app before the real thing is even built. If you were to publish something, then change it later it’ll be much more expensive to change the finished product than a product. The site goes on to mention computer-based testing software but goes on to say human testing is much better considering you are making something for humans to consume/use. The first method they list is participatory design, this essentially is when end users are involved from the very early stages of the design process, working together with you or the design team to define the product you make. Instead of the you are imagining yourself in the shoes of the user, you put the user in the shoes of designers. The second testing method they list is something bit unusual, Drunk people. This may not be the best but what they list is a pretty interesting idea. The testing method involves you testing you own wireframes. Interactive prototypes such as wireframes and more are the way to go when it comes to testing, these prototypes will help you introduce user testing throughout the various stages of development helping you along the way. The next testing method they list is Triading, which is essentially you trying to get the user to compare and evaluate 3 different alternatives without you influencing them with your questioning. The 5th method they go on to explain involves the users creating their own user tests. Here they referenced a Ted talk by Luis Von Ahn describing massive scale online based collaboration. The final testing method they mention is product reaction cards which is almost as simple as it sounds. Essentially the user gets exposed to the piece of software then given cards with adjectives written on it where they are asked to describe the software using 3 – 5 of the cards. This is a super simple and helpful user based testing method that I like a lot actually. All in all this blog post was very interesting with all the simple user based testing methods anyone could conduct.

 

https://www.justinmind.com/blog/user-testing-6-methods-you-hadnt-thought-of/

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

What You Need To Node

https://presencepress.presencepg.com/javascript-and-node-js-continue-to-eat-the-world-d41918a0615b

For me working with Node.js is a new and exciting journey we have ventured down. You can see from simple webapps the ability that Node.js has at influencing Javascript code. According to Dale Knauss in his blog about the NodeSummit2016 that opinion was shown as fact. As Walmart one of the largest retailers in the world primarily uses Node for its Walmart.com traffic. 98% of that traffic is directed through Node APIs. Accompanied by their sister company SamsClub who 100% of their traffic is through Node. The exclusive use by such a massive company surly speaks for the viability of Node. The reason that Walmart is exclusively using Node is so that their development team can all develop for their “entire stack”. Allowing for faster speeds of updates, and web retrieval. Dale states the major change is: “Where before they needed dedicated front end, back end, mobile, and devops developers, they now are able to have each member of their team work on any of those positions.” Another exciting prospect of Node is that NASA is beginning to use it in non-mission critical methods. The government agency that sends people to the moon is using a Node program that we are beginning to implement. Major companies are beginning to use Node or fully switching over and for good reasons.

Those reasons according to Dale are the empowerment of developers, it’s perfect for micros services, its lightweight and scalable, constantly improving, and its performance. Developers are being empowered because frontend is being handled by Javascript as well as reusable tools that developers can all use. The best tooling for micro services in the industry is developed and implemented by node. Micro services paired with rapid development and open source library that makes Node lightweight is what really streamlines development with Node. Node is also updating and being consistently maintained as well so the service is always up to date. To attest to the performance the example that Dale really puts it into perspective “ PayPal, moving their mobile servers from Rails to Node resulted in going from 30 servers to just 3 and performance that was up to 20x faster.” After reading over this article and seeing how relevant and powerful Node is I am excited to be diving in and exploring the uses for myself.

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

IoT Testing Types

https://testfort.com/blog/iot-testing-types-best-practices-through-reliable-testing-strategies

This blog post is about testing types and best practices for IoT devices. The market for these devices is growing at a fast rate and is continually changing. However, IoT testing is difficult because it requires a large base of physical equipment and knowledge about smart devices, IoT systems, and IoT test environments. Proven IoT testing approaches include compatability, security, beta, usability, and performance testing types.

Compatibility Testing

Compatibility testing should be a priority because IoT applications are run on innovative types of devices. This type of testing is necessary to protect software from vulnerabilities and system failures. An IoT testing team should have a well-equipped testing laboratory or take advantage of cloud environments.

Security Testing

It is important to test the security of IoT applications. There are three levels of testing:

  • IoT device testing – makes sure that devices are protected from breaches related to APIs, authentication, updates, and setting configurations
  • Network testing – protects the application from attacks on the network layer
  • System testing – ensures that user data is protected from leakage and hacking

Usability Testing

Usability testing ensures that software is easy to use and intuitive. IoT testers need to make sure that an application is perceptive and configurable.

Performance Testing

Performance testing is used to test an application’s speed within an environment with large data loads. Testers can use cloud platforms to simulate large loads and generate non-standard scenarios to see how an application performs.

Beta Testing

Beta testing involves the development of realistic scenarios for IoT testing. Discovering failures and usability issues during beta testing helps increase the chances of a successful product release.

Overall I thought this blog post was interesting as I have never really thought about the special considerations for testing IoT applications. While I think this post did a good job explaining why testing IoT software is difficult, it could have benefited from being more specific. The author does not go into much detail as to how these testing strategies are uniquely used by IoT software. It serves more as a general overview for the goals of these testing methods. Regardless, after reading this blog I am interested in learning more about IoT software development and testing.

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

Comparing REST and SOAP, which one should you use?

For this week blog post, I will write about the basic and differences between REST APIs and SOAP. Some people would say one is better than another, but that statement, for me I think, is incorrect because each protocol does have its own advantages to make use of and of course, there would also be a lot of annoying disadvantages that we all have to deal with. For this blog, I will have my information based on this article.

Firstly, I would go through a quick overview for both protocol. For stater, they both provide an answer to a same question, that is how to access to web services. SOAP stands for Simple Object Access Protocol. It has been around for a while and originally designed by Microsoft. While Distributed Component Object Model (DCOM) and Common Object Request Broker Architecture (COBRA), which are old technologies, fail because it rely on binary messaging, SOAP is designed to replace them as it works better over the internet. SOAP was initially released and submitted to Internet Engineering Task Force (IETF) and they standardize it. So how does SOAP works? SOAP heavily relies on XML to provide messaging services. It is also designed to support expansion and they have an abbreviation associated to their name such as WS-Addressing, WS-Policy, WS-Security, etc. and you can find out about these standards here. The reason to use SOAP is because it is highly extensible. For example, if you have a web service that you would like everyone to have access to it, then there is no need for WS-Security, but in case you change your mind, you can always add in to your service.

Let’s look at REST APIs. REST or Representational State Transfer is somewhat simpler to use and also known as a lightweight alternative. Instead of having just XML, REST APIs usually relies on the URL and sometimes Javascript Object Notation (JSON), XML, EDN or some other type of body is required. REST can use four different HTTP 1.1 verbs, GET, PUT, POST and DELETE to perform a single task. Unlike SOAP, REST doesn’t use XML to provide the response, it can have the data returned as Command Separated Value (CSV), JSON or Really Simple Syndication (RSS). The point of REST is not just because it is lightweight, but also because it returns the data in a form that can easily parsed within the language that you are using.

There are a lot of reasons to put one over another, it depends on how you see it and also depends on what your project is about. It is actually really hard to choose between these two, so I will compare them and let you decide.

Consider the using SOAP over REST, SOAP does have the feature that allow user to use without using HTTP or in another word, it has the language, platform and transport independence. You can read more about using SOAP with Simple Mail Transfer Protocol here. Another point to consider is that SOAP works well with distributed enterprise environment, which REST always assume it is going to be just point-to-point communication. SOAP does have to potential for extensibility, it is standardized along with a built-in error handling and it has the automation when using certain language products. 

How about REST, after disadvantages about it, should you still use it? The answer is absolutely because it does not required expensive tools to interact with the web service. Moreover, it has much smaller learning curve to go through, so if you are new to the field, you might want to consider having this on your project. I did point out that while SOAP is using XML that makes it so complicated, REST makes it more simple to just return a form that can easily parsed by most language, which simpler and decrease the time of the development process.

Overall, I think both are very powerful protocol for developer to make use of. It is true that sometimes you should consider one over another, but to understand that each protocol has definite advantages and equally problematic disadvantages is very important. I think it is amazing that we were given two choices to fit our project needs.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Angular Testing

https://blog.angular.io/angular-schematics-unit-testing-3a0a9aaab186

Recently as we have been working more with Angular I was interested in what king of testing was available for Angular code. The blog post on angular website does a good job of explaining how to get these tests done. To get started you need to mimic the application environment and set up the object you are testing in the case of this blog post they use a tree. Now it is time to actually set up the tests and that begins with an “it” statement.

AN EXAMPLE OF THEIR CODE:

it(‘fails with missing tree’, () => {

      expect(() => testRunner.runSchematic(

      ‘simple-schematic’, {name: “test”},

      Tree.empty())).toThrow();

});

               This code example asserts that an error was thrown because of an invalid tree. You can also assert invalid parameters as well with additional code shown in the blog post. The actual code for testing the outcome is the “expect()” function which can be used to test your code. Inside of the () is where you put the test you are running. In the case of this example we test to make sure all the expected files that’s are expected to be created with the expect(tree.files).toEqual([(files)]) to makes sure all created files are added to the array.

You can follow the blog for a direct example of the testing in Angular it is a bit complex in comparison to Java because you have to do a lot of set up instead of just creating a junit test. Over all I can see the benefit of wanting to test parts of your webapp without having to load up the app every time, but without a bit of practice Ill be hitting the refresh button a lot.

 

-Computing Finn

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

Getting Some REST with a Bar of SOAP: Which Web Service Access Protocol is Better?

When I was reading about REST APIs, the acronym SOAP kept coming up. In this blog post, I wanted to learn more about what SOAP means and how it compares to what I’ve already learned about REST. The article that I am pulling information from, https://smartbear.com/blog/test-and-monitor/understanding-soap-and-rest-basics/, is a thorough resource, detailing features of each service and how each can be considered “better” than the other.

SOAP (Simple Object Access Protocol) uses XML, a language like HTML, to send requests to a server and receive responses. SOAP was designed to be extensible, with multiple acronyms coming with it to support different usages of the services, such as “WS-Security” or “WS-Coordination.” However, when using free, public web services, these extensions may not be necessary to come into play; it is simply convenient to provide extra functions if needed.

One potentially problematic feature of using SOAP has to do with the entry of XML for requests. Because the complexity of XML code to make requests, some programming languages have built-in support to handle such requests. However, some are not as forgiving and require manual building of the XML code. While SOAP has error handling (which helps to identify where the request went wrong, as well as potentially automate fixing such errors using standardized codes), it is still intolerant to errors caused from incorrectly building the XML. REST has more of an advantage here, because of its reduced difficulty when creating requests; instead of having to program an entire XML file (depending on whichever language you use), REST just uses requests through the URL. This results in faster performance with REST.

With this in mind, though, SOAP does provide other advantages. Coming with built-in error handling is certainly a leg up from REST, along with flexibility of services with other extensions that have different functions. While REST focuses more on quick performance and a lack of complexity, SOAP increases functionality and handles errors effectively.

It is also important to note that unless a developer is making their own Web service, most free and public Web services make it clear which access protocol they use, whether it is SOAP or REST. Even if the Web Service that I access for my final project already has a defined access protocol (which is REST), I am glad to understand more about other options out there for different services available.

 

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Compiled vs Interpreted

I am writing in response to the blog post at https://www.guru99.com/difference-compiler-vs-interpreter.html titled “Compiler vs Interpreter: Complete Difference Between Compiler and Interpreter”. A compiled language is a language that requires a compiler to convert it into another language or format, like bytecode or native machine code. An interpreter translates the program to machine code as the program is running.

The blog post describes a compiler as a program that translates code into executable machine code before it is run, and an interpreter as a program that translates each statement into machine code when it is run. I think that this description is somewhat of an over-simplification. For C, compiling a C program means translating it into an executable program, which is comprised of machine code that is native to the platform it was compiled for. Compilation in general does not always refer to this particular process, though. A compiler may exist to compile one language into a different language, or even into the same language. The key is that the resulting compiled program is semantically equivalent to the original source code. If an interpreter existed for both programs then the result of interpreting the original program should be the same as the result of interpreting the compiled program.

Another detail that was not addressed by the blog post is the concept of “just in time” compilation. C programs are compiled “ahead of time”, where the code is compiled into another program before it is run. Instead of doing this, just in time compiling occurs in run time and compiles blocks of code as the program is running. This allows for a different perspective for an optimizing compiler to make the program run faster in instances that would not be possible for an ahead of time optimizing compiler that does not run in run time. Java is one such language that uses just in time compiling. The blog post does mention one detail about Java, and that is that it is both compiled and interpreted. Java is compiled into bytecode, which is portable because it is not specific to one platform’s native architecture, and then that gets interpreted into native machine code by the JVM when it is run.

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

Full Stack Developer

I am writing in response to the blog post at https://www.guru99.com/full-stack-developer.html titled “What is Full Stack Developer? Skills to become a Web Developer”. A full stack developer is somebody who is able to work in both front end and back end development. We have worked with back end development in CS 343 with our work in REST APIs, and we have also worked with front end development using Angular JS and TypeScript. Full stack development involves writing both ends.

The blog post describes a full-stack web developer as somebody who can work on both the front end and the back end of an application. It provides a tiered model of application layers that the developer should be familiar with: the presentation layer, business logic layer and database layer. We have briefly discussed the concept of a layered application model in class before. The presentation layer is the front end that handles the user interface, and the business logic layer and database layer correspond to the back end.

Some average income statistics are provided in the blog post, which shows that a “back end developer” earns more on average than a “full stack developer”, which seems counter-intuitive because a full stack developer, in theory, is capable of accomplishing the same tasks as a back end developer and more.

A clarification is made about the expected duties of a full stack developer; a supposed myth is that a full stack developer is going to be writing all of the code by themselves, writing both the front end and back end for a single large application because both jobs are within their skill set. In actuality, it is not the job of a full stack developer to produce everything alone. The blog post describes a full stack developer as a sort of a bridge between front end developers and back end developers who are working on the same project, because the full stack developer has a good perspective of both ends and how they interact with each other. In this sense, it is clear that a full stack developer in a development team is particularly beneficial for communication.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.