DEV Community: Adam Moore

Top 5 Web Portfolio tips the Internet agrees on

Adam Moore — Mon, 13 Dec 2021 17:18:16 +0000

The transition from solely learning to job seeking and continued education can be overwhelming. There is something to be said about knowing how to build a web application and understanding the crucial elements a web application should gather in order to capture a visitor and ensure they want to dive deeper into your content. This knowledge is at the forefront of many goals a web developer's portfolio sets out to achieve. A web portfolio is much like a visual skills representation of an entire resume; it allows a visitor, hopefully a potential employer or recruiter, to gather information about a web developer in a creative and dynamic way before they actually interact with them. This can leave a lot of responsibility to the web developer to both design and implement best practices and creative ideas into their portfolio to ensure the visitor wants to take the next step in contacting them for an interview. Below are five tips that various websites agree are 'must haves' in a web portfolio to make a developer stand out and become one of the few chosen.

Tip # 1 => Be yourself

Being yourself may seem like a simple sentiment both friends a family give to everyone pursuing a career and looking for employment; but really its true. A web developers portfolio is an extension of themselves and their work, it showcases who they are in a concise and creative manner in order to entice potential employment. If you have a favorite language, a skill you're proud of, hobbies you enjoy outside of coding, or CSS you enjoy using, implement them into your portfolio. Allowing your personality to shine through your portfolio will give the visitor a feeling of who you actually are! They wont think you're coding all day in a basement just knocking on employment's door --but if you are bring some humor to that, owning where you are in life and who you'd be around the office, or in a zoom call, will make certain they know who they're contacting for an interview. Many interview processes involve a 'cultural fit' interview with other developers, so be transparent and put your personality into your portfolio and the interview process --this can help them know whether your a good fit, and leave it up to you to decide if they are in return.

Tip # 2 => Keep it simple

In a world where designs, information, and resources are abundant, we find ourselves as people wanting to get to the bottom line of everything as fast as possible. Dynamic and 'shiny' websites are fun to look at, but at the end of the day if we don't get the information we've came for in about 5-15 seconds those nice looking styles and creative designs go out the window. Most visitors to a web-developers portfolio come for three main reasons: checking out the competition, critique for improvement, or to gather information needed to pursue an interview with the creator. Don't get me wrong, you do need to have an eye appealing presentation when it comes to your portfolio as HTML and JavaScript wont get you hired or keep visitors on your page long. However, some developers lean a lot on the design and how it looks but leave the actual information about them to be desired. This is paralleled with other developers having decent designs but then the information within the portfolio is hard to locate or involves a marathon of clicks to reach. Keeping a web portfolio simple in the sense that the design is clean and eye catching, and the content is either self explanatory or the navigation of reaching a developer's information is intuitive are must haves. Most people are visiting for the first time, unless your portfolio rocks and they came back, so keeping the site effortless to navigate and gather information will leave every visitor exiting with a sense of unwasted time.

Tip # 3 => Lean on your projects

At the end of the day for all web developers, what you've built will get you hired. Your projects should be the focal point of your portfolio, right next to a contact form. Now, this is all only true if you have good projects; projects that are deployed, have good documentation and function properly if a visitor decides to navigate to one of them are essential. The projects located in a portfolio should be the absolute best in your arsenal for displaying skills, creativity, attention to detail, and the ability to have them go live without glitching or erroring out. Afterall, most employers who come to your portfolio and review your projects are their because they are looking for competent developers to build other projects for them. A portfolio is usually a front-end picture frame of who you are and what you've built; next to the actual creator (you) is the work you've done and the possibilities of what you can do for future employers. Remember most people have never heard of your project, and you wont be there to explain them in person, so make your project's documentation clear and concise as well as those sites intuitive for first time users. Employers will appreciate best coding practices and creative ideas that are deployed to the public and actually accomplishing why the project was built in the first place. The effort in being a competent developer with real world application is more important than what the actual project was built for. Show off them skills!

Tip # 4 => This is a visual resume --be creative!

Most web developer portfolios are strictly front end, the functionality and what you've hardcoded in are what the user can see and interact with. If someone has navigated to your portfolio you've done half the work, they are already there so make it an enjoyable experience. Display your skills, experience, education and who you are in creative ways that catch the visitors attention, but still gives them what they came for. This can be as simple as click events that display more detailed information regarding topics, or transitions from one resource to the next, even displaying your name in a creative way can catch a visitors attention. This site is an opportunity for you to take a normal paper resume and turn it into actual art. Now, if styling isn't your true niche there are plenty of templates out there to get the bones of a creative site looking better. However, never leaning just on a template is best practice, tweaking a template or even bootstraps library to fit your personality can lead to some under the hood creativity on your part and ensure that your not showing yourself in the same light as everyone else whose used that same template or bootstrap class. There's a balance between what you have to show them and how you show it, just remember something is better than nothing and designs can always be improved!

Tip # 5 => Ensure that everything works

At the end of the day, the last four tips do not matter if your portfolio is broken. We've all been there, we navigate to a website, start exploring, and something breaks --oops! Most people will leave due to frustration or disappointment, some devs will wonder why it broke and explore further, unfortunately most hiring managers are like most people. A lot of pressure is on web developers to have a functional, error free web portfolio --after all it's kind of a part of the job. Once you deploy your site, visiting at least once a day and running through all of the functionality will make certain that everything is in working order for future employers. On the development side this is where best practices for different browsers come into play, building the site to be mobile friendly or run on explorer, firefox, and chrome is essential for any potential employer to navigate to your site from anywhere or on any device and actually see what you've done and who you are. A sentence to remember: if it's broke then you're broke, and if it works then you'll work.

These five tips are at the upper echelon of what the internet agrees make for a good web portfolio. Implementing them into your website will make for a better experience for both you and all of the visitors that come to check it out. This process can be overwhelming but with the right mindset, tips, and skills everyone reading this can be hired as a developer.

Resources :
https://toggl.com/blog/web-developer-portfolio

https://brainstation.io/career-guides/how-to-build-a-web-developer-portfolio

https://arc.dev/developer-blog/web-developer-portfolio/

https://www.creative-tim.com/blog/education/web-developer-portfolio-website/

CRUD REACTion with RUBY Sinatra API

Adam Moore — Thu, 18 Nov 2021 19:16:32 +0000

Ruby Sinatra is a smaller alternative to Ruby on Rails, it was created and open-sourced in 2007, and has been used by companies such as Apple, LinkedIn, and GitHub. This 'microframework' focuses on creating a functional backend to frontend interface with minimal effort. When paired with REACT, it can be quite painless to maneuver and debug during CRUD (Create, Read, Update, Delete) operations.

For example, if you were to fork and clone this repo from GitHub you would have a file structure set up with ActiveRecord and Sinatra, among various other gems, after you ran the command 'bundle install' within your terminal. This paired with creating a REACT APP would give you all of the file structures necessary to begin a full-stack web-application. For the explanations on CRUD below, I will assume you've had experience in creating migrations, seeding data, running the backend server within Sinatra and building out a front-end interface as well as running the browser from a REACT application. Examples of all of these tasks can be found in this frontend repo and this backend repo, both of which are built to work together for a group project within my coding bootcamp.

The below examples will be for CRUD operations from a React front end to a Sinatra backend. These examples are different from the ones used within the frontend and backend repos, they are used as in-depth explanations to the functions and operations being used within this project

Create (POST)

//REACT FRONTEND
//Callback function to handle post request from client
//has new blog post object passed as parameters(name doesn't matter)
 function addBlog(newBlog) {
//Server URL with appropriate request endpoint
    fetch('http://localhost:9292/blog_post', {
//method stated for server.
      method: 'POST',
//headers clarify what type of content is being passed through request.
      headers: { 'Content-Type': 'application/json' },
//body turns object to string format for backend readability, 
//object has keys(params in ruby) that match columns for blogs table.
// newBlog will be destructured
// and 'POST'ed to backend before being returned.
      body: JSON.stringify(newBlog)
    }).then(r => r.json())
//returned data sets state variable to be all blogs
//including newly posted blog.
.then(data => setBlogs(data))
  };

#RUBY BACKEND
#Request type is specified before URL endpoint.
#URL endpoint points to all blog posts
post '/blog_post' do

#creates new instance of a Blog for the Blog class and blogs table.
   Blog.create(title: params[:title],
                content: params[:content], 
                author: params[:author])
    # return all blog posts as well as newly posted one.
    #Requests turned to JSON, for REACT readability.
    Blog.all.to_json
end

Read (GET)

//REACT FRONTEND
//React component mounts, useEffect runs a GET request to
//the Sinatra API.
 useEffect(()=> {
//Server URL with appropriate request endpoint
    fetch('http://localhost:9292/blog_post')
.then(r => r.json())
//returned data sets state variable to be all blogs
.then(data => setBlogs(data))
  },
 []);

#RUBY BACKEND
#Request type is specified before URL endpoint.
#URL endpoint points to all blog posts
get '/blog_post' do
    # return all blog posts after request
    #Requests turned to JSON, for REACT readability.
    Blog.all.to_json
end

Update (PATCH)

//REACT FRONTEND
//Callback function to handle patch request from client
//has new blog post object passed as parameters(name doesn't matter)
 function editBlog(blog,id) {
//Server URL with appropriate request endpoint
    fetch(`http://localhost:9292/blog_post/${id}`, {
//method stated for server.
      method: 'PATCH',
//headers clarify what type of content is being passed through request.
      headers: { 'Content-Type': 'application/json' },
//body turns object to string format for backend readability, 
//object has keys(params in ruby) that match columns for blogs table.
// blog will be destructured
// and 'PATCH'ed over in backend before being returned.
      body: JSON.stringify(blog)
    }).then(r => r.json())
//returned data sets state variable to be all blogs
//including updated(PATCHed) blog.
.then(data => setBlogs(data))
  };

#RUBY BACKEND
#Request type is specified before URL endpoint.
#URL endpoint points to specific blog post with ':id'
patch '/blog_post/:id' do

#finds appropriate blog post using :id endpoint
 update_blog = Blog.find(params[:id])
#updates the blog instance to requested params.
  update_blog.update(title: params[:title],
                content: params[:content], 
                author: params[:author])
    # return all blog posts as well as newly patched one.
    #Requests turned to JSON, for REACT readability.
    Blog.all.to_json
end

Delete (DELETE)

//REACT FRONTEND
//Callback function to handle delete request from client
//has blog post object passed as parameters(name doesn't matter)
 function editBlog(blog,id) {
//Server URL with appropriate request endpoint
    fetch(`http://localhost:9292/blog_post/${id}`, {
//method stated for server.
      method: 'DELETE',
//headers and body not necessary for DELETE request
    }).then(r => r.json())
//returned data logged to console
//including updated(PATCHed) blog.
.then(data => console.log(data)
  };

#RUBY BACKEND
#Request type is specified before URL endpoint.
#URL endpoint points to specific blog post with ':id'
delete '/blog_post/:id' do

#finds appropriate blog post using :id endpoint
 blog = Blog.find(params[:id])
#Destroys instance of Blog found from blogs table and class
    # return all blog posts, with deleted blog no longer there.
    #Requests turned to JSON, for REACT readability.
    Blog.all.to_json
end

Hopefully these links and CRUD examples have been helpful to you and your full-stack application endeavors. The project links wouldn't be possible without the help of others working on the project Jane and Amy both of whom are great up-and-coming web-developers. Feel free to check out their GitHub profiles and repos, as well as mine. Happy developing!

Producing the MVP vs Becoming the MVP

Adam Moore — Wed, 27 Oct 2021 19:32:03 +0000

As web developers we can all agree that most of us enjoy programming because it allows us to build beautiful, dynamic, applications from practically nothing but a keyboard, monitor and an internet connection. Lets face it, typing a few lines of code and getting visual confirmation almost instantaneously is pretty cool! On the other hand, with this great power comes great responsibility, most of us are learning these skills constantly to become employed either as a freelancer or as part of a team of other developers --both of which do carry some responsibility. This is where being the MVP and making the MVP are two different hurdles that all of us will have to overcome. Personally in just the first few phases of Flatiron's Bootcamp I have come face to face with this challenge on many occasions.

What do I mean by MVP and MVP, are they not the same? Letter wise, yes. Acronym wise, absolutely not. Becoming the Most Valuable Player on your team (even a team of one as a freelancer) and making the Minimum Viable Product are vastly different when it comes to setting out project goals and achieving your deliverables for a client, employer, or your instructor. Personally, I have succumbed to the allure of wanting to code 15-30 different ideas all at once and make the next epic web page the internet has ever seen...for a project that had 3-5 deliverables required to satisfy expectations. Those deliverables are the Minimum Viable Product, and are nonnegotiable.

The urge to become the MVP of your team can be challenging to resist. When it comes to road mapping towards the deliverables and trying to finesse solutions to code bugs along the way, ideas are great. However, a lot of ideas in the beginning, paired with excitement for a project, can lead to you and your team spending precious time coding the 'many' instead of coding the 'few'(main deliverables). Its been my experience that the best course of action is to write out what you need (the minimum viable product). Once that is clear to everyone involved, a wire frame --or drawing-- of the components that will render the content, data, and functionality in your app to meet the the core deliverables can act as your road map. This is not to say that brainstorming ways to accomplish the MVP goes without some creativity; coding is a learned art where many paths can lead to the same goal. New and seasoned programmers just need to strive for and meet the goals set by the MVP first, then the framing and additional goals can be accomplished.

An individual or team that meets the standards as the minimum of their goals first, then stretches them with new ideas and creative thoughts are the real MVPs. They all just have to...

Iteration in JavaScript-Array.forEach() & Object for...in

Adam Moore — Wed, 06 Oct 2021 16:52:57 +0000

Intro

Its early in the morning, you're in some week during the beginning of your coding boot-camp journey--learning JavaScript of course-- and you have a coding challenge that day. cue background scream!

^^^Okay definitely not that kind, but you get my point.

Of course you may feel prepared with what you've learned about the language so far; so you give it your best shot "....deliverable 1...check....deliverable 2....uh oh..." That 'uh oh" moment happened to me on the first code challenge of my software engineering education. Deliverable 2 had many requests to rendered data to the web-page, all of which relied on the JavaScript method of iteration. I of course blanked, spending well over half the allotted time with 'null' to show for it. <=See what I did there?

Anyway, to put it simply: iteration allows the developer to move through elements of an array or an object's properties/values they may need in order to render content onto a web-page.

You might be asking: "What is an Array or Object?"

An Array is a data structure that can be linked to a variable and used to store different elements, the elements are stored within square brackets => []. each element within an array has an index number, beginning with 0, and those elements can be accessed via [] notation. EX: console.log(myArray[0]) would log '//=>1 ' to the console.

An Object, on the other hand, is a data structure that is standalone, although can be assigned to a variable, and has properties(keys)/values. Object's properties(keys)/values are stored within curly braces => {}. These key/value pairs can be accessed with Bracket notation [], or Dot notation '.' Ex: console.log(myObject.key1) would log '//=>hello ' to the console as its accessing the value using Dot notation. All examples from here will utilize Dot notation. #writers_picks_the_preference

=>#Secret_Tip = Arrays are classified as Objects.

Not to delve too deeply into the technicality of each data-type and their many(MANY) uses, for this post all we need to know is whether you have an array of objects, or a large object containing many key/value pairs, iterating through the nested levels or stretch pairs is essential to accessing the data you need for the deliverables that may be required of you in your career --or schooling.

.forEach()

For this example lets assume you have a basic understanding of GET requests from an API or local JSON file using fetch(); you have converted all of data into a response that you can use inside your Example() function, and it just so happens that the data is a large array containing objects. Example() is being used as a callback function, the parameter of the function can be named whatever you like --in this case parameter -- as you are already passing the data off as this 'parameter' within the fetch().then().then() request. Keeping the name of the parameter as the name of the data being passed through, you now have to utilize the .forEach() method inside the function to access the objects within the large array.
.forEach() only gives the developer access to the elements (Objects in this case) but not what those elements actually contain---just their face-value if you will, the 'element' within the .forEach() is used much like the parameter in this case as it represents each individual object within the array.

=>#Notes = .forEach() doesn't inherently return anything, it requires a callback to be passed through it.

From the 'element' we can pass a call back function (I prefer this to be written as an arrow function, but use what you feel comfortable with). The function we're passing is declaring a variable that finds a container within our HTML document using its #id., then its declaring another variable to be equal to a created HTML 'tag'(element); from there it gets pretty cool: the '.textContent' of that variable is then set to the element.property (Object.Key) which in turn will set the '.textContent' to that particular value. Okay, that may not seem very cool when typed out, but the kicker is that it does this for EACH of the objects within the array. <=no still not funny?

So, basically, if you have an array containing say 1000 objects with text or numbers as values to a key inside the object and you wanted every value to be placed inside 'variable1' ....6-8 lines of code can perform that task for you!

=>#Work_smarter_not harder

for...in

In the previous example we assumed you were utilizing a GET request with fetch() and implementing the .forEach() within your callback function. This example is going to be done using only a JavaScript and HTML file and the console. As you can see we have declared a variable of 'myObject' and set it equal to an object with keys of "key1: and key2" and corresponding values of "hello and bye." This object is going to be our 'data' that we will pass through the function exampleFunction(). Within this function we have a form of object iteration called, you guessed it, for...in.
The structure or this method can be broken down as:

for(variable declaration - key value iterator - in -the object)

from that method we are creating an 'h1' element set to the variable of 'variable2' and setting the '.textContent' of that variable to the values of each key in the 'myObject.' the 'console.log' within the function will log a separate 'hello' and 'bye' to the console. As you can see I may have lied about only using Dot notation during this post, as this particular example required Bracket notation to access key1's and key2's values.

This method allows us as developers to access an object's key's values and implement them onto our webpage. Useful if we need to have the values of all the keys in that particular order, and all of them rendered to the page, but definitely not the best or most efficient way to iterate objects. There are many different methods that can interact with Arrays and object, perhaps a more indepth topic for another time. Thank you for reading, and wish me luck on the code challenge retake!

Best, Adam

“Continuous learning is the minimum requirement for success in any field.” - B. Tracy

Resources

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...in

https://www.w3schools.com/js/js_objects.asp

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach