DEV Community: Jared Weiss

Introducing Songzy: The Fun New Way to Share and Explore Music!

Jared Weiss — Mon, 27 May 2024 06:56:18 +0000

This is a submission for the The AWS Amplify Fullstack TypeScript Challenge

What I Built

Hey everyone! I’m excited to share my project Songzy with you!

Given the tight time window and only being able to work on this part-time, it’s obviously a work in progress, but I’m really proud of how it has come along. Songzy is an app where you can upload your own music and explore new tracks in an innovative way.

The explore page is my favorite part — there's a slider that lets you zoom out to see more songs, creating a giant, interactive grid of cover art. It’s a fun way to discover music, and I hope you’ll enjoy it!

Demo and Code

You can visit the deployed project here and the code here.

Here is a screenshot tour of the app so far:

1. Login

2. Upload a song with title, cover art, and audio file

3. See your songs

4. Explore others’ songs. Just hover (desktop) or click (mobile) on one to play it.

5. Drag the slider and see even more songs!

Integrations

Authentication

Amplify's Authenticator component made handling user login and sign-up processes incredibly simple.

Data

I utilized Amplify’s defineData function and schema creation to set up and manage the data models for Songzy. This approach allowed me to hook up the schema and generate queries effortlessly. Figuring out the authorization allowances took a bit of time, but once sorted, it provided a straightforward solution for managing access.

An Interesting Use Case

On the Explore Page, I needed to programmatically adjust my query as the slider is dragged. I enjoyed that Amplify’s querying syntax made it simple enough to:

Filter out songs that did not belong to the user.
Limit the number of results based on a calculation of how many songs could fit on the screen given the screen size and slider position.
Use the nextToken to avoid repeating song retrieval in the query.

Functions

Image Compression Function: I configured my storage access to allow a function called compressImage to create and read files triggered by the onUpload event. Initially, I faced several challenges with image compression libraries in the function, but I eventually found a solution using a combination of the jimp and jpeg-autorotate libraries (the latter prevented unwanted image rotation). Additionally, I encountered an issue with the function running recursively due to replacing the same file key repeatedly. I solved this by using the Metadata property to mark compressed images and prevent the function from reprocessing them.

File Storage

For file storage, all images and music files are securely stored in Amazon S3:

I used the StorageManager component in Amplify Forms to handle song uploads. This integration allowed me to connect a GraphQL query seamlessly, creating database entries and properly uploading files to S3. The S3 file link is tightly integrated with the database entry field for new songs.
The StorageImage component made it easy to retrieve images from S3, and I used the getUrl function to handle the retrieval of audio files.

Thoughts

Overall, I loved how I didn't need to configure much in Amplify's UI, although I believe more documentation on the nuances and different possibilities of the code configuration would be beneficial.

I loved the sandbox - it made developing with a realistic backend so simple. Unfortunately, I was not able to determine if there’s a visual way to see the data and logs in the sandbox. I should have asked in the help thread. If this is not possible, that would be a great addition to the feature.

Lastly, the experience of having everything connected so seamlessly, including deploys tied in with Git, was awesome.

Connected Components

Authenticator: This component made it super easy to handle user sign-ups and logins.
Amplify Forms: To handle song creation.
StorageManager: To manage file uploads.
StorageImage: To display images stored in S3.

Feature Full

Songzy includes all four key integrations: data, authentication, serverless functions, and file storage.

Future Features

I wanted to add a section here to communicate my full vision since it’s been such a fun idea and project.

Ability to like songs on Explore Page, and they show up in your Liked Songs Page.
Ability to create your artist name (at first) and personalize your profile page (later).
Optimize audio: Compress the audio files.
Optimize images: Have the image compression function create images at different sizes so that the Explore Page set to the fullest will load songs faster.
Optimize loading files in general: Use CloudFront in combination with S3.
Have the explore page show songs completely at random, or at least ordered by newest to oldest.
And lastly, the UI could use more work of course - unifying theming, adding proper routing, adding better loading placeholders for songs, ensuring that the explore page’s song modal shows up in the right place regardless of screen size and device, etc.

Conclusion

Leveraging AWS Amplify's powerful suite of tools made it possible to bring my vision to life quickly and efficiently. From handling user authentication and tightly coupling forms to data to file storage to functions, the experience was quick and efficient despite the occasional roadblock (usually caused by configuration issues that were difficult to find documentation on).

While there are still areas to improve and features to add, I'm excited about the foundation that's been laid with AWS Amplify Gen 2. I very much appreciate the code-first approach to architecture. This project has not only deepened my understanding of the AWS tech suite but also highlighted the potential of what can be achieved with the right tools.

Lastly, I invite you to explore Songzy. It would be so cool if everyone created accounts and uploaded songs with nice cover art to grow the Explore Page!

Your feedback and interaction will be invaluable in encouraging me to continue to refine and enhance the app.

Thanks for reading!
Jared

Finally Understand Responsive Design!

Jared Weiss — Thu, 11 Apr 2024 15:39:27 +0000

Intro

In the realm of web development, the concept of responsive design often presents a steep learning curve for beginners. Even after moving on to more advanced topics, many still struggle to fully grasp the essence of responsive design, a shortfall that becomes evident in their projects.

Responsive design is an elusive goal for many engineers, primarily because the crunch of deadlines often shifts their focus to functionality and how the project looks on their personal device. This narrow focus can lead to oversight of how a website or app performs across different devices.

Even established websites can falter in responsiveness. Personally, I find that the proverbial amazon.com loses its aesthetic appeal when I shrink the browser on my laptop.

That said, I don’t believe it’s too difficult nowadays to achieve a decent level of proficiency with responsive design. I just think there has been a lack of educational focus on the topic, and in presenting it in a clear comprehensive way. That is what I intend to do in this article / video.

I’ve identified seven CSS properties/concepts that one must know in order to achieve almost any responsive design. While there may be additional techniques to enhance responsiveness, these seven are comprehensive enough to tackle most scenarios. Unless you’re making your app ultra-complex, you should be able to understand and apply these concepts in a reasonable amount of time.

Of course, to truly understand these concepts, practice is essential. That's why I've put together a video tutorial to complement this guide, offering a practical demonstration of the principles discussed. Remember, with each practice session, these concepts will become more intuitive.

Here are the main topics I’ve identified as crucial:

Size units
- Relative to screen - vw, vh - Relative to other elements - %
The max-width and min-width properties
Flexbox
CSS grid
Media queries
Responsive images properties
JavaScript for more complex responsive behaviors

Size units

Most beginners focus on creating a design that fits their screen nicely. Therefore, they don’t realize the downsides of specifying elements’ size, padding, margin, etc in exact terms, usually with pixels (px). The problem is that those elements will never change size as the screen size changes. Transitioning to using less absolute units like percentages and viewport units (vw/vh) is key for a flexible design.

Percentages

Beginners must be careful with percentages. It takes time to understand the concept of parent-child relationships and that when a percentage is given to a child, it is a percentage of the size of its parent/container (interchangeable terms), not the whole screen.

Another point here is that all the outside elements that seemingly “don’t have a parent” actually do - the <body> element. And the body’s size is as follows:

Width - the width of the screen
Height - the height of the content inside of it (0 if nothing is in the body)

Viewport width/height (`vw`/`vh`)

When you want an element to be sized relative to the screen, thus having no relation to the size of its direct container, you want to use vw and vh.

One example is the following. Let’s say your website is meant to have a <header> then a <main> section, and you want to specifically size the height of the header and have the main section take up the rest of the screen’s height.

One way to accomplish this is the following:

header {
    height: 300px;
}

main {
    height: calc(100vh - 300px);
}

One vh unit is basically 1% of the viewport height (the height of the screen). Therefore, 100vh means 100% of the height of the screen, and thus calc(100vh - 300px) means “100% of the screen height minus 300px.”

This ensures the main section will take up the remainder of the height of the screen after the header.

You could also achieve this result with flex, but I’ll talk about that later. In this specific case, I think either is fine. Maybe one method will prove better as the project grows in complexity.

When to use px

Having these other options and the ones I will detail below definitely do not mean that the px unit has no place in CSS nowadays. There are still many situations in which you want something to have a specific size that doesn’t change along with the screen.

Many elements in a UI design may prefer a specific size that will never change. Often buttons are sized this way, for example.

The `max-width` and `min-width` properties

These properties become useful when you want an element to grow or shrink in size, but only to a certain point.

One common scenario for this is with search bars at the top of the UI. The search bar will likely take up the majority of the screen width on mobile devices. And though the search bar will be bigger for a laptop than a mobile phone, once the devices get larger, you won’t want the search bar to remain almost the full screen width.

Take a look at how Airbnb’s input bar changes (just the width of it, I mean) as the screen grows.

Mobile:

Tablet:

Big tablet / small laptop:

Laptop:

It's a little hard to tell with these images, but on mobile, the search bar takes up most of the width of the screen, but is still small in terms of px). Then it grows for tablets and small laptops. But at a certain point, it stops growing more as the screen further increases in size.

Flexbox

I count myself very lucky to have not had to learn CSS before flexbox was invented. “Flex,” for short, is an amazing method of relating elements to each other in terms of position and size.

With flex, you write display: flex; on the parent element, then it becomes a “flex container,” and all of its direct children become “flex items.” There are several intuitive flex-related properties you can set on the flex container to describe how the flex items should behave. There are also properties you can set on the flex items themselves to distinguish their styling from the rest of the flex items.

It is common that beginners don’t understanding that the flex relationship is strictly between parent and child. Not parent and grandchild, and so on. You can have flex items that are also flex containers themselves. All that means is one element has display: flex; and one of its children also has display: flex;.

Here are two of the most common scenarios in which flex becomes handy:

Flex allows you to create positional/spacial relationships between elements that are all next to or on top of each other. So if, for example, you have a few items in a row, you can space them evenly from each other in that row with just one or two simple CSS properties.
With flex, you can easily change the direction in which sibling elements are positioned. By direction, I mean from horizontal (row) to vertical (column), or vice versa. For example, think links in a nav at the top of the screen that become organized vertically under a hamburger menu for mobile.

CSS grid

There is one shortcoming of flex, and that is when you are trying to control elements in two directions (x-axis AND y-axis) at the same time. Flex is all about defining properties for elements that are aligned along the same one axis (x-axis OR y-axis). The most common scenario for wanting to do this is when making a grid of items.

You may run into trouble when trying to ensure they’re all the same size. See the below image for an example of this.

With grid, you can just apply one or two easy CSS properties, and bam, problem solved. See below.

#card-container {
    padding: 20px;
    display: grid;
    grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));
    gap: 20px;
    justify-content: center;
}

Note - Some people actually choose to use grid for the entire layout of their website. To be honest, I have never spent enough time to explore this option because I learned flex first (grid came out later), and flex is good for 95+% of my needs. I really have only needed grid for actual grid layouts, which are typically a subsection of my websites, if I need them at all.

There is nothing wrong with using flex and grid in different parts of your UI!

Media queries

In almost any design, you will need things to change more drastically when the screen hits a certain size. Small screens favor vertical scrolling. With larger computer screens, you can fit more elements horizontally.

With media queries, you can define what are called “breakpoints” - points at which some styles are to be overridden to accommodate the tweaked designs for other devices.

You have a choice to either create the mobile or desktop UI first, then create a breakpoint at which you define new styles to override the existing ones for the platforms that you didn’t initially design for.

Let’s use the example where for mobile devices, certain elements should be organized in a column, but on larger devices, they should be organized in a row.

Let’s assume that we have chosen “mobile first design,” which means designing the mobile UI first, then figuring out the responsiveness to achieve the larger devices’ designs. This choice, rather than designing for laptop/desktop first, is considered better today since the populus spends more time on phones than larger computers, and a company will prefer to make more users happy.

Well, the way to tell your app to change its appearance at tablet width and larger is to basically - with a media query breakpoint - say, “at this pixel width and higher, change the organization of these items to be a row now.”

This change may mean just changing a flex container’s flex-direction property from column to row, as shown below:

#flex-container {
    display: flex;
    flex-direction: column;
}

screen and (min-width: 768px) {
    #flex-container {
        flex-direction: row;
    }
}

This snippet means that the element with ID “flex-container” will have flex-direction: column; for screens less than 768px in width, but for screens with width 768px and above, the element will have flex-direction: row;.

Side note - There are relatively standard pixel widths for each device, so you can look up the pixel width at which to set a breakpoint to indicate a transition from mobile to tablet, tablet to laptop, and so on.

Responsive images properties

Often a combination of the above properties will be used to dictate the size of images in your website, and no further CSS will be needed.

However, there are times when the image is not scaling property with the screen. I wanted to provide a couple properties you could explore when this happens.

One property is aspect-ratio. This property allows you to define a preferred aspect ratio for images so that it always maintains the same height-to-width ratio across different screen sizes.

Another property is object-fit, which can take values such as fill, contain, cover, none, and scale-down, allowing for flexible control over how images adapt to different screen sizes.

JavaScript for more complex responsive behaviors

Finally, JS plays a crucial role in responsive design for more dynamic and complex adjustments that CSS alone cannot handle, allowing for custom behaviors based on user interactions or device specifications.

With JS, you can react to more event types than just screen size changes, such as button clicks, scrolling, dragging and dropping, and more.

With JS, you can write logic to dynamically adjust the sizes of elements based on whatever conditions you want. For example, you can adapt content based on the user's device, behavior, preferences, and/or location.

JS will be the bulk of the code for your UI, so if something is not easily attainable with HTML and CSS, often the solution will require JS.

Conclusion

Achieving responsive design is a balancing act, requiring a blend of CSS finesse and strategic JavaScript. By understanding and applying the seven key concepts outlined above, developers can create websites that are not only visually appealing but also adaptable across all the necessary devices.

The journey to mastering responsive design is one of continuous learning and practice. To see these concepts in action, don't forget to check out the accompanying video tutorial.

Remember that responsive design is within reach, and with each project, the process becomes more intuitive.

Hopefully I have managed to make responsive design a less foggy and daunting concept for you with this article and video.

I wish you the best of luck with your future projects, and I thank you for reading.

Until next time,
Jared

Become a Frontend JavaScript Pro in Steps - A Series

Jared Weiss — Tue, 02 Apr 2024 10:26:14 +0000

Hey y’all,

I created a 4-part video series where I build a frontend app in increasingly professional coding paradigms.

I think this will be a huge breakthrough for beginning developers in learning how to write code as a professional would - taking into account maintainability and scalability.

Level 1

I recreate a design from frontendmentor.io.
When implementing the JS, I rely on the DOM nodes themselves as the state of the application.

This is the most common sense approach for a newbie. The downside is that for every feature you want to implement, you have to react to a user action, take stock of the DOM elements on the screen, then update the right ones.
This will likely require messy, nit-picky logic that gets difficult to maintain as the project grows.

Level 2

I restructure the JS to represent the state of the application as stored JS data.
The process becomes: the user does something, I update the state data, and then I render out the UI according to the data.

This makes the rendering logic more modular - if things aren’t rendering properly, I can isolate the rendering logic more easily.
Also, the rendering logic will be largely the same for new features, so making new features becomes faster as the project complexity increases.

Level 3

I note that neither approach thus far has led us to a fully functional frontend app.
We have hardcoded the user’s data, and upon refreshing the browser window, we are back to where we started. The user’s progress is not recorded.
We fix this by using localStorage as our place to store the user’s updates, allowing us to bring the user right back to where they were if the screen is refreshed.
I end by noting that by this point, you know all you need to deploy a legitimate and potentially successful application, mentioning the game “2048” as an example.

Level 4

I take you on a massive refactoring journey and paradigm shift to make your code as clean, maintainable, and scalable as possible.
I start simply with the latest JS syntaxes and tricks, then I go deeper into how to structure your project to be less buggy and more maintainable/scalable as it grows - by:
- Implementing naming conventions
- Implementing Object-Oriented Programming (OOP)
- Breaking the project into modular folders and files
- Using Webpack to bundle and minify the files for optimization

By the end of this journey you will be a significantly better developer who understands more professional levels of thinking, which will help with your future projects and communication in interviews, and separate you from other beginners.

Here’s the link to the beginning of the series - https://youtu.be/Ksu7ks6U9mA

I hope you like it! I know it’s long, but it’s worth it!

Best of luck,
 Jared

From JS Basics to Actually Building Stuff

Jared Weiss — Tue, 06 Feb 2024 04:43:41 +0000

Intro⁣

⁣I often get/see the question of how to go from understanding the building blocks of JavaScript (data types, variables, conditionals, loops, functions, etc.) to actually building things. Hopefully I can offer some help here.⁣⁣

Most people give the advice to start with small goals and work your way up. I would say exactly the same if I were limited by text and time. ⁣⁣

But let's be honest, figuring out what those small projects should be can be a challenge in itself. It’s tough as a beginner to know how to experiment.

⁣⁣I'll expand to the best of my ability in this post with text, but I will link the YouTube video I made at the bottom in case you want to see a code demonstration with more detail that is difficult to accomplish with words.⁣

Explanation⁣

Defining Small Goals⁣

⁣Anyway, to expand a little in words while we're here, I believe it's easiest to learn through frontend JavaScript, interacting with HTML and CSS. This way you can apply variables, functions, loops, and conditionals to practical, visible things. ⁣

You can play around with text, lists, cards, forms, drop-downs, images, modals, and more. Think of changing visibility, size, color, boldness, capitalization, item addition/removal, and so on. These small goals will reinforce your understanding and provide a foundation upon which you can build more complex applications.⁣⁣

The Mentality⁣

⁣Also, transitioning from learning to doing requires a mindset shift. Embrace experimentation and don't fear making mistakes. Accept that you will initially have no idea how to accomplish these tasks, but they're so small that with repetition, you can start to see the patterns in how the JavaScript building blocks are used. Don't be afraid to look at the answers, but make sure you take the time to understand the answers (Don't just copy and paste them then move on.).⁣⁣

Scaling Up⁣

⁣As you gain confidence with small projects, start scaling up. Eventually try to replicate real websites' UIs, then you can try using sample data from free APIs. Before you know it, you'll have confidence in your frontend abilities, and you will have learned how to use the JavaScript basics along the way.⁣⁣

Then you will be able to create your own applications, utilizing a combination of JavaScript fundamentals. This might be an interactive game or a web app that fetches data from an API. Remember, every complex project is just a series of simple steps combined. With every next project, you will see this breakdown more easily.⁣⁣

Thanks for Reading!⁣

⁣Here's the YouTube video link: https://youtu.be/S7_ApcLsRv4?si=c7CZ3aEATuQkHZ6x⁣

DEV Community: Jared Weiss

Introducing Songzy: The Fun New Way to Share and Explore Music!

What I Built

Demo and Code

1. Login

2. Upload a song with title, cover art, and audio file

3. See your songs

4. Explore others’ songs. Just hover (desktop) or click (mobile) on one to play it.

5. Drag the slider and see even more songs!

Integrations

Authentication

Data

An Interesting Use Case

Functions

File Storage

Thoughts

Connected Components

Feature Full

Future Features

Conclusion

Finally Understand Responsive Design!

Intro

Size units

Percentages

Viewport width/height (vw/vh)

When to use px

The max-width and min-width properties

Flexbox

CSS grid

Media queries

Responsive images properties

JavaScript for more complex responsive behaviors

Conclusion

Become a Frontend JavaScript Pro in Steps - A Series

Level 1

Level 2

Level 3

Level 4

From JS Basics to Actually Building Stuff

Intro⁣

Explanation⁣

Thanks for Reading!⁣

Viewport width/height (`vw`/`vh`)

The `max-width` and `min-width` properties