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.