https://blog.bitsrc.io/9-best-practices-for-optimizing-frontend-loading-time-763211621061

So last week I wrote a blog post on good practices for REST API design so naturally I had to follow it up with a blog post on good practices to follow on optimizing frontend performance since we’re working with frontend stuff this week.

This week’s blog post is about a blog post from bitsrc.io from Nethmi Wijesinghe titled “9 Best Practices for Optimizing Frontend Performance.” In this blog post, she writes about 9 best practices that will be useful to the reader to optimize frontend data loading. The 9 best practices she lists are: minify resources, reduce the number of server calls, remove unnecessary custom fonts, compress files, optimize images, apply lazy loading, caching, enable prefetching, and use a content delivery network.

To summarize the 9 practices:

1. Minify Resources: remove unnecessary, redundant data from your HTML, CSS, and JavaScript that are not required to load, such as code comments and formatting, etc.
2. Reduce the Number of Server Calls: More calls to server, more time to load. 3 ways to reduce the number of server calls include: using CSS sprites, reducing third party plugins, and preventing broken links.
3. Remove Unnecessary Custom Fonts: Self explanatory, but also you can take these 3 actions when using fonts on your website like, converting fonts to most efficient format, subset fonts to remove unused characters, and preloading fonts explicitly required.
4. Compress Files: Compress files to save loading time since larger files = longer loading time.
5. Optimize the Images: Images improve user engagement but make sure they are optimized to save loading time.
6. Apply Lazy Loading: Lazy loading allows web page to load required content first and then remaining content if needed
7. Caching: Allow caching so browsers can store the files from your website in their local cache and avoid loading same assets when revisiting
8. Enable Prefetching: Prefetching loads the resource in anticipation of their need to reduce the waiting time of the resource.
9. Use a Content Delivery Network: Using a CDN (group of servers distributed across several geographical locations that store a cached version of the content to deliver fast to the end-user) allows you to optimize loading time as well.

I picked out this blog post because we were using frontend in class during Activity 15-16 and I wanted to follow up with practices to optimize your frontend. This was one I found that was interesting but also introduced new terminology to me. Things like lazy loading, prefetching, and CDNs I didn’t know about until this reading this post. Also, I haven’t had any web dev experience prior to this class and doing the in class activities made me more interested because it was something new to me I had never touched. I knew web dev things existed I just never knew how complex it can actually get and it’s actually made me more interested in possibly pursuing a web dev position instead.

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

Hello everyone, hope you are all doing well. As this is the final week, I would like to wish you all Goodluck with your finals. In this week’s blog, I would like to talk about Refactoring as it is one of the important parts of programming. Refactoring is a process of restructuring code while making sure it does not change the original functionality of the code. The main goal of refactoring is to improve internal code by making small changes without altering the code’s external behavior.

Computer programmers and software developers refactor codes to improve the design, structure, and implementation of software. Refactoring improves code readability and reduces complexities. It also helps software developers find bugs or vulnerabilities hidden in their software. Refactoring improves codes by making them more efficient by addressing dependencies and complexities, becomes more maintainable and reusable by increasing efficiency, makes the code cleaner which then makes the whole code easier to read and understand, these are a few purposes of refactoring.

Refactoring can be performed after a product has been released, this should be done before adding updates and new features to the existing code or it should be done as a part of day-to-day programming. There are several benefits of refactoring like it makes the code easier to read, encourages a more in-depth understanding of code, improves maintainability. It also comes with various challenges like this process will take extra time if the development team is in the rush to finish the product and refactoring is not planned for, without clear objectives refactoring can lead to delays and extra work, Refactoring cannot address software flaws by itself, as it is made to clean code and make it less complex. There is various technique to refactor the code some of the examples include moving features between objects, Extracting, refactoring by abstraction, and composing. The best practices to follow for refactoring include Planning for refactoring when a project starts, Developers should refactor first before adding updates, refactor in small steps, Test often while refactoring, fix software defects separately, Understand the code before refactoring, focus on code deduplication, use of Automation tools make refactoring easier and faster.

I choose this article because it has a clear definition of refactoring and purpose of refactoring, benefits of it, explains different techniques to perform code refactoring, and gives best practices to follow for refactoring and since it is very helpful for software engineers, in the future these practices will help me do my job easier and help me do my job in an effective way.

Article: https://searchapparchitecture.techtarget.com/definition/refactoring

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

https://derisking-guide.18f.gov/state-field-guide/basic-principles/

Something I struggle with quite a bit is directing my personal software projects. Staying committed, composing large pieces of code with each other correctly, and even figuring out what I want to do in the first place are all things that I just sort of play by ear, with limited success. In an attempt to gain some insight, I found this article published by a technology and design consultancy for the US government, directed at non-technical project managers. The gist of it is that these managers must understand six concepts: user-centered design, Agile software development, DevOps, building with loosely coupled parts, modular contracting, and product ownership. I won’t go into all of these, since some are still more technical than others, but I want to highlight a few.

One of my favorite points in the article is something that I’ve believed for a long time, which is that all development should be centered on the needs of the end user, rather than stakeholders. Project risk is reduced by ensuring the software is solving actual problems for actual people, and the problems are identified via research tactics like interviews and testing for usability. It would be kind of silly to interview myself, but I think this is a good mindset to have. It kind of sounds meaningless when stated so directly, but if you want a product you have to focus on creating the product, rather than daydreaming about every possible feature it could have.

Another point I liked was the discussion of Agile software development. Without getting too into the weeds on details, the basic problem it seeks to solve is that detailed, long term plans for major custom software projects generally become incorrect as the project proceeds and new technical considerations are discovered. To combat this, agile developers plan in broad strokes, filling in details only as necessary. In a way, it kind of reminds me of an analogy I heard once to describe Turing machines – an artist at their desk, first drawing a broad outline and then focusing on specific sections and filling in details (it may or may not be obvious how this is related to Turing machines but that’s not relevant). The primary metric is how fast documented and tested functionality is delivered.

I found two other somewhat related points useful as well, both of which deal with modularity. The first is the idea of “building with loosely coupled parts”, which essentially boils down to the idea that if one agile team is in over their head, they should split the work into two or more distinct products each with its own dedicated team. Modular contracting is just applying this concept before even beginning a project. Together, I think this a helpful way of possibly connecting all the small fleeting app ideas I have – rather than one unfocused monolith, I could work on a small ecosystem with a shared API that I add and remove things from as needed.

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

When we write code, we try to think ahead to what possible changes we may need to implement in the future. There are many ways that we can implement these changes, ranging from slapping together a quick patch, methodically going through the code and changing all the affected parts, or writing the code in such a way that anticipated changes can be added in with just one or two small adjustments. This last method is what “encapsulate what varies” means. Writing code will often cause us to think about what future changes we need, and by isolating those parts of the code we can save ourselves time in the future. I found an article that does a good job explaining this concept, and while reading through it I was reminded of a recent project where using encapsulation ended up saving me a lot of time and headaches in the future.

The specific event that the article caused me to remember occurred during my most recent internship. One of the projects I worked on was a script that would automatically assemble 3D CAD models of of any of the systems the company was working on at the time. This script needed to read the system specifications from a database and then organize that data, identify key parts of the system, and figure out how it is assembled so that it can then send those instructions to the CAD software and create the 3D model. It was a big project, and I and the other intern working on it were daunted by the amount of ever changing data that would need to be accounted for. Many systems were of a unique design, and as such we couldnt use the same exact code for all systems. The engineers we were attatched to for this internship introduced us to something called python dataclasses. These essentially allowed us to structure parts of our code that we knew were going to be subject to change in such a way that adding or removing certain data points from the database doesn’t break the overall program. If any changes arise, we only need to alter the related dataclasses for the rest of the code to be able to work with the new change. Without these we would have had to create new methods/classes for each unique change every time it came up; which is not something anyone wanted. I am glad I found out a way of “encapsulating what varies” since I can now write better and more future-proof code by isolating the parts that I believe will be changed the most often.

https://alexkondov.com/encapsulate-what-varies/

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

SQL databases use tables and relations to store data which makes them rigid in the way data is managed. Developers are forced to store data in a predefined way according to the table and database specifications. This strictness makes working with the data easier in the future because the data is highly structured. Given the table properties, a developer will be able to know the properties on each row of the table. The downside of the rigidity of SQL databases is that making changes and adding features to an existing codebase becomes difficult. In order to add a field to a single record, the entire table must be updated and this new field is added to all records in the table. In PostgreSQL, there can be JSON columns where unenforced structured data can be stored for each record. In this way, it is a workaround for the highly structured nature of SQL databases. However, this approach is not ideal for all situations, and querying data within a JSON field is slower than if it was in a table. SQL databases use less storage on average than NoSQL databases because the data is standardized and can be compressed using optimizations. However, when a SQL database grows, it usually must be scaled horizontally. Meaning the server running the database must have upgraded specifications rather than spreading the resources throughout more instances.

NoSQL databases use key-value pairs and nested objects to store data making them much more flexible compared to SQL databases. One of the most popular NoSQL databases is MongoDB. In these databases, tables are replaced with collections and each entry is its own object rather than being a row in a table. The document-based storage allows for each record to have its own fields and properties. This allows for code changes to be made quickly. The downside of having no enforced structure is that required fields can be omitted and expected data when it is not present on the object. MongoDB fixes the issue of no enforcement with features called schemas. Schemas are a way to outline objects with key names and the data type associated with them. Ensuring each object in a collection follows the same format. NoSQL databases are scaled horizontally easily, easing the resources by distributing the workload on multiple servers.

I selected this topic to learn more about the different use cases between SQL and NoSQL databases such as MongoDB and PostgreSQL. I will use what I learned on future projects to ensure I select the right database technology for the project I am working on.

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

As a trend from the previous posts, I am still working with JavaScript, and I am still learning more and more about it. In this article I learn some best practices around JavaScript itself. Some new things and some things common for any programming language.

https://www.w3.org/wiki/JavaScript_best_practices

There is not much to summarize for this article as it is simply some best practiced coding techniques for proper JavaScript coding. Like mentioned earlier it does include some things that by now I should already know and practice. As in comments should be as needed but not in excess, naming conventions should be simple and understandable, Big O notation matters and to optimize your loops and avoid nesting them and keeping to clean code style of one function one purpose instead of excess purposes inside a function that might be iterated out later or nonsensical to someone code reviewing. But there were some more JavaScript specific practices that were more related to web development.

                Progressive Enhancement is a concept that I get on a basic level just thinking in terms of providing a service to someone means going through the barriers of your platform to make sure they have access to it, like Microsoft office products working on mac. In this article it mentions the idea that when scripting or perhaps even JavaScript itself is not available to a platform that you need to manage the code in a style that will work with any platform. To me that seems easier said than done but it does make sense that if the interface to the user can be managed by something else before scripting is done then you achieve your goal of progressing your user base and opening your code up.

                Another practice I learned was regarding data security. That at any time any data being passed through my code should be checked first. I have heard examples of specific businesses being hacked due to a very specific fault in the design itself that left open vulnerabilities which lead to personal information being stolen. Most cases I have heard is simply the human aspect in security vulnerability where a hacker just calls to get access to a password for an account that can then access that data. But in the examples given in the article it is specific to making sure that the data passed to you does not fault in error and that there is some methods that allow you to discern data types from another to avoid further conflicts or generally avoid validation on the users end to prevent them messing with your own websites code.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

This week I read a blog post that I thought really related to the class about custom software development. The blog started with a section about the process of custom software development. It consists of research, UI design, MVP development, testing, maintenance, and monitoring/support. The blog then goes into why it can be for you. It gives reasons like how it makes your business more unique, and personalized to the needs of your business. The next section finally goes into the 7 benefits. They are a personalized process, cost-effective, reliable, continuous support, flexibility, seamless integration, and exclusive ownership. I see all those benefits as a definite win, especially how you would be making it your own, and nobody can take it from you. The blog ends by going over how the advantages outweigh the negatives, and how they are too evident not to use.

 I selected this blog post because software development is my dream job, and I thought it would be interesting to read about custom software development since I have never heard of it before. This blog did not disappoint in that aspect, and I think it will help tons of others as well.

 I think this blog was a great read that I recommend for many reasons. One reason I would recommend this blog is because it goes in-depth on the different benefits. It makes a section for each benefit, and explains how it is a benefit. An example of this is with the cost-effectiveness benefit. The blog writes about how this is a huge benefit because since it is custom, you will only be paying to make it, but in the long run it will last you the entire time. Another reason is because custom software development could be something that you will need to know to do in the future, and it is good to know why it is so important. Then, when the time comes in the future, you will be ready. The final reason I will be going over is because it shows how the benefits outweigh the disadvantages. If anyone thinks custom software development is not worth it, maybe this blog could help them change their mind.

This blog taught me about how custom software development is really beneficial, and it should be used the most often. The material affected me heavily because it showed me that custom software development will be widely needed in the future, so I got to understand it. I will use this knowledge to try and further software development in my future.

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

DRY, or “Dont Repeat Yourself” is an approach to writing code that emphasizes avoiding repetition in your code. In other words, “Dont Repeat Yourself” is essentially a way to tell developers to write methods for anything they think they might need to use in more than one place. For example imagine you are writing a program where certain parts of the code need to do similar things. One way to approach this problem is to write a segment of code to do the necessary task each time the need for it comes up. While this would work in practice, it is far from the best way to approach this issue. Solving the same problem by creating a separate method that achieves the intended goal and can be called whenever it is needed is a far better and more time efficient solution. Geeks for Geeks has a great concise article about this, and even gives some example using java code.

And that really it as far as “Dont Repeat Yourself” goes. Its a straightforward rule that helps keep developers from wasting time writing repetitive code snippets. While it may seem simple to implement, I know for a fact that I have had plenty of experience writing repetitive code. During my first internship especially. The issue came down to the ever changing project requirements, and my need to adjust my code to meet those requirements. In doing that I know that I definitely wrote repetitive code that could have been its own separate class or function, however as I was working on many different files and pieces of the code, it didnt resonate with me at first that some of this code can be written as one method and called as needed. Eventually while I was polishing up some of the code I realized this mistake and corrected for it. I wrote functions that accommodated most of what the repetitive code was supposed to do and replaced that code with calls to these new methods. This ended up causing many small bugs to pop up however, and I had to spend more time looking for them and fixing them. Had I slowed down when writing my code I would have been able to plan ahead and create these functions from the get go; saving me time and energy in the long run. Going forward I try to be more careful with the code that I write; and try to think ahead to what may need to be reused. Once I figure that out I can create a function for it and save myself time and energy later on.

https://www.geeksforgeeks.org/dry-dont-repeat-yourself-principle-in-java-with-examples/

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