Category Archives: Programming

Week 10 Blog Post

Searching for an article this week I looked for something relating to mocking. Considering last week I did the negatives on mocking I think it’s valuable to have various perspectives. Seeing multiple ideas with mocking can give us an idea of how to implement them in the future. The writer of this article is a reliable source being a Java script developer. Getting information from someone in the industry can give a perspective inside the workforce and how people inside see different ideas. Not everyone may agree with using the same coding language but seeing how developers see different concepts can give an idea of the drawbacks to stuff and where in our own experiences can we improve. Overall this article is a great way to see how mocking is seen inside the workforce by an experienced professional.   

In this article, Eric Elliot focuses on the drawbacks of excessive mocking. He points out how brittle tests and how they can be easily broken. There broken simply just from the change of implementation even though the behavior stays the same. Another point is a false sense of security because of there lack of accuracy that occurs from not using accurate real behavior. This is a fault in the test because the test will pass even if it isn’t supposed to. Third, he focuses on complexity overload which is just adding too much complexity can make the code harder to understand and maintain. Elliot still believes in mocking but a more balanced approach can overall help the program. Mocking should be used sparingly and when there actual weight for its use. All together Elliott wants the audience to create a strategy that will have confidence in their code correctness while also minimizing any negatives of excessive mocking. 

Reading this article at first I thought it would be more of a pro mocking but it’s more in between. It says its flaws while still sharing the positives. After reading this article I understand that mocking can cut time but it can bring flaws to testing. The best time to utilize mocking is when time is scarce and later it can updated with time. It still isn’t the ultimate be-all to testing but with a balance, it will work. Understanding these flaws can foresee issues that may come up when mocking. Mocking should never bring up complexities that can complicate the code and should always have a priority in simple to understand and easy maintenance.

https://medium.com/javascript-scene/mocking-is-a-code-smell-944a70c90a6a

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

Week 8 blog Post

For this week I found an article about writing code considering we have been writing classes for the past few classes. The article I found stuck out to me because of its title “Writing Code an Art Form”. People always use the analogy of code being like learning a new language but I never heard anyone consider it as art. From the countless articles I could have chosen without this title, I may have never chosen it to begin with.

This article first starts with a background of how the idea of this article came to be. The setup was that the author was working as a junior developer who had to get a recently hired senior developer with 10 years of experience acquainted with their program. I can only imagine how that interaction was set up and whoever was leading the group should have probably reconsidered who should help the new employee. Even though the senior developer had far advanced experience his code was not easily readable. The author was even taken aback because the senior developer commented how the author likes to write pretty code. The author goes into detail on how poor documentation must be taken into account because other flaws can arise from bad naming conventions for variables/functions, spacing, and having the mindset to problem-solve. Keep the code easy to maintain, read, and debug don’t write spaghetti code.

Now reading this article gave me insight into the inner workings of the tech field. I would have never assumed that a new employee would be getting trained by the second recently hired. I would have assumed that someone with more experience with the project would have filled in the new person but maybe it could be that there both coming from similar places. Both of them are the newest employees and could be easier to help another person adapt to the environment. Reading this article has also reinforced ideas that keep your code simple and clean. My main takeaway was whenever you write code don’t just write it for yourself to understand but for everyone. Let’s say you are working on a project on your own you might just get enclosed in how you understand code nobody but you will be able to update it. Even if you don’t care that someone else will update it in the future your code can be so unreadable that future you may have no idea what you created. In a way, code is like writing notes and there is an art to writing good notes.  

https://hinchman-amanda.mehttps://hinchman-amanda.medium.com/writing-code-an-art-form-e41e459bd2f6dium.com/writing-code-an-art-form-e41e459bd2f6

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

Week 14 – Token #2 – CS-343

For this blog, I specifically wanted to look into how this class relates to the preferred field I want to go into, which is Game Design. I wanted to see what kind of languages would be used, what kind of design elements are implemented, and even in the case of frontend vs. backend, how online games employ servers.

However, it seems like I had a misunderstanding that these two positions were similar omewere, as I find many sources that say software design vs. game design are a completely different beast, which only made me more interested. I did some more research, and this lead me to end up reading this article below:

Specifically I noticed that software development has more rigidity when it comes to designing and delivering a product. Software engineers are usually employed to design a software to meet consumers demands, which usually entails specific features and options they’d want in the software you’re developing. Whereas with game design, you have a much more flexible development cycle, as theres a lot more creativity involved. You’re less focused on making sure specific features are available and more focused on delivering a product that is unique and interesting for consumers, and keeps them engaged.

Game developers also rarely work with programming languages when it comes to development of products. Game developers mainly use engines, which are interfaces that employ programming languages to create building blocks to build off of to create a video game. Software engineers mainly work with the code directly at almost all times, making sre each line is properly written. That’s not to say some game devs don’t work with code directly, some do, and many Triple A companies actually write their own engines using their own code, like in the case of Epic Games’ Unreal Engine, which is used to power their famous game Fortnite.

Something this article notes is that software developers may not need to worry about performance compared to game developers, and I can understand why they might say that. Games rel on having a fluid and enjoyable experience, and that is dependant on the performance of a game, making sure theres no glitches, bugs, or lag. However, I would argue that performance is still a factor within software design too, because what if a simple calculation process in a program takes multiple minutes? Consumers will still have an issue with that. While I do think it’s definitely a lot more important in game development, that’s not to say it’s not unimportant in software design.

And that’s all my blogs for this semester! I’ll be taking another of Professor Wursts classes next semester, so I’ll likely be writing again then. See all you readers come January!

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Week 14 – Token #1 – CS343

For this blog I’ll be using one of my tokens for this class so I can hit the 6 blog minimum before the semester is over.

In this blog post, I wanted to look more into JavaScript since I didn’t really know too much about it. I struggled with the backend homework we had because I never knew anything about the syntax or language at all. So, I want to learn a bit more about this language within this blog. For this, I consulted this website, and gave it a good hearty read:

https://developer.mozilla.org/en-US/docs/Web/JavaScript

This site gives an overview of JavaScript and the applications in which it is used in general, and what benefits and downsides it has compared to other languages.

What I found very interesting is that I originally knew that JavaScript was mainly used for website development and coding, but this site gave some examples of applications such as Node.js and Adobe Acrobat. I believe we’ve actually utilized Node.js before in our classes, but I can’t quite put my finger on what exactly we used it for, but I recgonize the name appearing in one or more of the repositories we’ve been working with.

It seems like JavaScript is much like Java in the sense that it can use object oriented code, but I think the similarities between the two end there. In the past, I always heard that JavaScript was a completely different beast from Java, and after look more into it, I see why. This site below describes the differences:

https://www.lighthouselabs.ca/en/blog/java-vs-javascript

JavaScript it object-orientedcode, whereas Java is object-based. That may sound the same as each other, but there is some very specific distinctions between them. Java relies on objects to function, whereas JavaScript has functionality for objects and suggests use of them with it’s language, it is not required. JavaScript is also a lot more fluid with it’s syntax, and has a lot more free-form and flexibility with it, which reminds me a lot of what I’ve heard about Python. Java is a lot more rigid, and requires specific pre-set uses of it’s syntax.

But back to JavaScript, it seems like its The language for web design, as a lot of it’s language is made with web design in mind. My future for this area of study is some form of design in technilogical areas, so it would be possible I go into Web Design. If I do, I’ll definitely have to teach myself more JavaScript. It seems like a really useful language to have on hand in that case.

I will be posting one other blog today, using another token, so stay tuned for another!

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Suggested Standards for (basic) REST API Calls

In the past few weeks, we’ve finished the CS-343 semester focusing on designing/implementing REST API calls and interacting with back- and front-ends. During one of our classes, I recall a discussion about the fact that there are no unified across-industry “best practices” for writing API’s. Specific API structures and rules are common within teams but can vary from organization to organization, however there are some general habits and strategies. So I decided to do some searching and focused on a blog post on the website for Swagger, the REST API view/interaction software we’ve been using in class: Best Practices in API Design.

The post discusses some general best practices on creating consistent, well-designed API’s by focusing on three key characteristics: 

  1. Being easy to read, understand and work with
  2. Being hard to misuse, and in turn more intuitive for users
  3. Completeness and Conciseness – something which the post acknowledges frequently happens over time as developers build on top of existing APIs

Alongside some other basics on CRUD operations and how they correlate to standard REST API calls (get, post etc.), the post also dives into practices for writing effective call response messages. The codes for responses should follow the HTTP standards, where client-side errors return 400-level (4xx) codes versus server-side errors return 500-level and successful calls return 200-level. 

Arguably most important is providing thorough and clear explanations in response messages. For error responses, this entails providing detailed messages describing the error that occurred and suggestions/tips to address and debug it. As a part of this, it’s worth considering putting an example of a successful call to show proper syntax and passed parameters – handholding users will pay off with smoother API interactions long term. To reinforce this, the blog post recommends providing examples for all possible GET responses to demonstrate successful data access calls.

While specific implementations will vary by project/system, these are some good strategies and habits to keep in mind. The importance of providing examples for each individual GET response really sticks out and hits home for me. I can imagine with more complex systems and calls that may contain various request, query or other parameters it could quickly become confusing for users to navigate and access information they need. It seems worthwhile to also provide an example of a successful call in the error response for some specific situations, such as an Error 400 – Malformed Requested → providing an example successful request. 

Below, you’ll also find a link to a “glossary” of REST API parameters with explanations on their purpose and uses – a resource I also recently came across and have been finding valuable. If you have any other suggested “best practices” to keep in mind when designing REST API calls, please let me know in a reply or E-Mail.

  1. Blog Post: https://swagger.io/resources/articles/best-practices-in-api-design/
  2. Parameter Glossary: https://rapidapi.com/blog/api-glossary/parameters/

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Welcome!

Hi, I’m Josh! I’m currently a 20 year old college student who’s studying Computer Science and this is the first blog I’ve ever had. I was never much into blogs, however I can see the benefits of consistently updating a log of your progress, thoughts, or ideas. Whether people read it or not, it’s a great way to express yourself!

With this blog, I hope to track my learning, personal projects, and the ever evolving world of technology we live in today. It’s easy to get lost in all the news and different technologies, so this might be my way of navigating through the ocean of programming/tech and keeping up.

That’s all I have for now. Have a great day!

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Capstone: Sprint Reflection 6

Sprint 6 was the final sprint of the semester. We rounded up this sprint with an unfinished solution to issue APTS-254. Over the course of this sprint, we were feeling really good on our understanding of this issue. We required quite a bit of clarification from the Ampath team. After getting some really good clarification we found that the code we needed to work on was in an entire different directory from the one we had been previously working in. Once we finally found where we should be working, we began digging in deep into the issue. The first thing we noticed is that this issue was associated with their ETL server implementation. None of us on the team had previous understanding of what an ETL server was so we I did some digging. I found a few resources online (Here’s a good brief description) that I summarized for the group. The idea was fairly simple, except the way the Ampath team was using ETL was basically by skipping the Load portion and just passing the transformed data to the end user as a notification.

I had a really good understanding of the issue at this point and even began writing some code that I thought might work for this specific issue. Part of the major issue that stopped us from being able to test this solution was the fact that we were unable to test that our solutions actually worked before committing changes. In order to test our solutions we were going to need a running ETL server. In the end I was kind of bummed we weren’t able to resolve another issue before semester’s end. But I felt good in the things I learned from trying to resolve this issue.

I would love to continue working on these issues in the future but with all my personal projects and the fact that I will be starting a new job (as a Software Developer) on the 22nd, I don’t plan on having a lot of extra time. All in all I really enjoyed working on Angular 2 and seeing how a large scale project like Ampath was built.

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

The Software Craftsman: Chapters 5 & 6

Cahpter 5 resembled Chapter 2 from Robert C. Martin’s book The Clean Coder which has many of the same themes as this book. This chapter mostly covers the fact that as a professional you occasionally need to say no. If you don’t say no when you should say no, things can get ugly quick. I won’t talk too much on the reasons why here because I talked about it in more detail here.

I do want to talk briefly about one thing that was said in this chapter. With good managers, there should never be a “us and them” attitude. This could never be more true and I recently experienced the downside to an “us and them” attitude. I was on a job with the the VP of Stack Testing in Bridgeport, CT. We were working as contractors for a fairly large power generation company, we’ll call them “Big Guys”. So Big Guys have so many power plants that instead of contracting companies like us to do their stack testing, they have an entire team of internal stack testers. However, an issue came up where Bug Guys’ stack testing team didn’t have some special analyzers that my company has. This equipment is very expensive and very complicated to use. So we arrived on site and immediately the upper management of Big Guys made us feel threatened. The upper management made multiple comments about how if we screwed up even the slightest bit that they were going to throw us off site and hire a different contractor. That was the first sign this was going to be a rough few days. Anyways, we ended up meeting Big Guys stack testing team, we’ll call them “Little guys”. All of the stack testers from Little guys were incredibly nice and welcoming to us. They were excited to have us on site and really excited to see our equipment in action.

After a 16 hour day of testing along side Little guys, we started seeing some trends. Big Guys management kept referring to the testing that was happening as “Your tests”(Directed towards Little Guys), like somehow Little Guys are requiring them to test when the reality it that the State of Connecticut was the one requiring THEM (Notice the beggining of the Us and Them mentality). Then we noticed that Big Guys were not giving Little guys any information until the very last second. Each time they did this the sent Little guys into a frenzy getting ready for the next test. Same things like this kept happening throughout the day.

We arrive on site the next day to find out that after the previous day, Little guys were upset and disgruntled about the previous days happenings. They began venting to myself and my boss. The “Us and them” mentality become so apparent when they started go against what Big guys were telling them to do. Towards the end of the second day, Big guys told little guys on their last hour of tests to pause their tests. Big guys eventually told us why they paused the test and the reason was completely strange. They had us pause for reason that were 100% unrelated to what we were doing at that moment. Little guys made a unilateral decision to continue testing so they could leave before 7 pm. Obviously Big guys were furious when they found out and there was a yelling match (Thankfully neither my boss nor I were present for) between Big guys and Little guys. The moral of the story is if they had not had this us vs. them mentality I am almost positive the days would have been smoother and we there definitely would have been less contention.

 

Chapter 6 talks about Craftsmen as gardeners. I really appreciate this visual. There certainly is a difference between someone who plants and someone who gardens. Someone who plants prepares their base, digs their holes and plants their plants and then moves on. If you do this as a gardener then you will quickly find your plants getting choked out by weeds or overgrowing other plants. This is not okay. One of the most interesting points made was the mindset of developers thinking the didn’t have enough time. I never realized it, but I have done this. Multiple times. Working on small projects I could have saved my self countless hours if I had simply taken the time to create unit tests. I see that now. I know that now. But I still don’t always do it. Why? “CAUSE I THERE’S NO TIME FOR THAT!!”. Really? Really, Tyler? Don’t you remember last time you said that? You spent hours debugging a simple logical error that could have been found in seconds using unit tests. ….Yeah, I still skipped unit testing to push features “faster”. This is something I am trying to break for sure and this chapter was a good reminder that it’s a time saver for everyone if I simply write unit tests and take the time.

Guess what, Tyler. There. Is. Time. Write Unit Tests!

I have the written on a sticky note on my monitor at home.

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

The Software Craftsman: Chapters 3 & 4

Chapter 3 of The Software Craftsman is spent defining what is a Software Craftsman. The earlier parts of the chapter are spent on talking about the history of Software Craftsmanship, that is all very interesting but I’d like to discuss the Software Craftsmanship manifesto.

Not only working software, but also well-crafted software

Not only responding to change, but also steadily adding value

Not only individuals and interactions but, also a community of professionals

Not only customer collaboration, but also productive partnerships

So, lets take a look at this line-by-line. The first line states “Not only working software, but also well-crafted software”. I think we can all agree as some form of software developer this is the best thing to strive for. The question then becomes, how do we get here? Sandro makes a statement that is truly interesting. After describing what any good developer would know to be truly well-crafted software, Sandro states “In order to evolve applications, developers must not shy away from changing them.”. This statement is so intriguing to me because it simply makes sense. You can’t have evolution without change, and you want your software to evolve to “well-crafted”, right? Well in order to do that, you’re going to have to make changes to the code, sometimes that may be big. Other times it may be small.

The next line says we should be steadily adding value to the project. This is again something that no one can refute as a good thing. However, I think as developers, we many times find it hard to “Leave it cleaner than we found it”. As you are reading this I can almost guarantee that you are thinking back to a time where you made a bug fix, but that bug fix made things just a little bit messy. I am sure whatever reason you had for putting in that bug fix messy like that was valid. However, this starts becoming an issue when everybody working on the project adds some messy code here and there. Eventually the system becomes maintainable and it’s an unfortunate side-effect to us being humans. However, as software craftsmen we need to strive to not get caught in this net and constantly clean up the code.

The next line says we need to be a community of professionals. I really like this piece. I’ve worked with people on both ends of the spectrum (not in the software field). On one end there are people out there who will give you the bare-bones, need-to-know information to get the job done. I am unsure as to why anybody would want to do this. Flip the coin and I’ve worked with people who are delighted to share their knowledge and understanding of the given subject matter. I think mentor-ship is incredibly important. If no one ever mentored a young developer and didn’t pass down the knowledge that’s been attained over their long career, then the young developer is going to fall into all the same pitfalls that has plagued software development for years.

This final line in the manifesto, is essentially stating: In order to succeed you will need to act as a professional. It also talks about the flip side of your manager needing to act as a professional and expect you to act as a professional. We should want to strive to produce the best possible products we can and in doing just that, I think a lot of the time the customers or the employers are more willing to work with you through issues. They are able to see past you as their employee or contractor and begin to see that developing software is a partnership. In order to create good software there needs to be professionalism on both sides of the coin.

 

 

Chapter 4 talked about attitude of the software craftsmen. More so the chapter discussed our attitude towards pursuit of knowledge. The pursuit of knowledge should be a personal burden and not a burden you try and place of your employer. It is your sole responsibility to continuously improve skills and knowledge as a craftsman.

Many of the ways to improve this were discussed in an earlier blog covering “The Clean Coder” book. I won’t re-hash something I’ve already discussed. But as a brief summary, some good ways to extend your knowledge is through books, blogs, podcasts, training events, seminars, meetups and coding challenges.

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

Capstone Project: Sprint 2 Reflections

Another sprint down! This sprint was much more exciting then previous sprints. This sprint we were finally able to get OpenMRS and Ampath running locally on our machines so we could fiddle with it! I have a tendency to probe things I don’t understand until I either 1, understand them or 2 break them. Luckily this time was the former over the latter. Part of our previous sprint was to re-write an Ampath module, specifically the authentication. This was to help us learn how the REST API works and to generally learn how Angular works. We broke our sprint down into a few steps.

  1. Remove all traces of an authentication module from the Ampath directory tree.
  2. Attempt to rebuild a basic html/css of the original Ampath login page.
  3. Creating the Authentication routing so when we visit localhost it will successfully show us the html page we had just created.
  4. Make sure the login button successfully authenticates the user.

These four basic steps were what we felt as a scrum team, each individual could finish in the time we had for the given sprint. Unfortunately for me, because I enjoying coding and learning new things so much, I finished this by day 3 of our approximately 8 day sprint cycle. This left me with nothing to do, but plenty of time on my hands. I took that time to start researching TDD inside of Angular and how to write Karma tests. I really like the Karma framework and the way you simply declare what a test should be doing. I feel that it makes your testing output extremely easy to read, which is especially nice when you are showing it off to your wife who is by no means a software developer. But in the case of the real world, it gives someone A LOT of insight into what your code is supposed to do by them simply running test.


Tomorrow we start Sprint 3. From my understanding we are going to become familiar with JIRA and Ampaths issue tracking, so we can start (hopefully) resolving some issues for them! I am very exciting to be finally diving deep into this project and I hope to make some significant changes!

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