Making a reusable footer in React

freeCodeCamp's new front-end technologies content is still under construction, but they have released a few lessons for their React fundamentals. You can click here to find the referenced lab activity from this blog post.

React is a JavaScript library that focuses on the UI of a website. To put it another way, it is concerned with the "View" of a page. It is component-based, and the components can be written in two ways: (1) Class-based components, and (2) Functional components. The first way is an older style that apparently is no longer used as much. Functional components is the current "in" way to create components. Instead of using JavaScript classes, you instead use a JavaScript function.

I've created a few React applications in the past, but this was my first using the newer Functional components. freeCodeCamp provided the index.html file already, however the CSS and React code was all up to me. Here is the completed code in a Github Gist page.

I started with the React part and made sure to finish the bones of the page before writing up the CSS. You really do not get a lot of leeway on the "how" here, as freeCodeCamp's user stories specifically ask for a certain setup.

Index.jsx uses one functional component to return a <footer> element. JSX only lets you return one top-level element. While I used <footer> here, most of the time you can use <Fragment> or simply < >. Inside the <footer> is an unordered list. I added a quick <div> there so I could separate the list from the copywrite paragraph below. The entire component is exported with the keyword at the top of the component.

With that code in place, technically I would pass the challenge (it does not check for styles). But where is the fun in that! So I added some CSS code. In order of how the selectors are written:

• I gave the footer a calming light blue background
• I removed the bullet points and default padding for all list items in my list
• I gave each specific list item some extra padding to spread out the items
• I centered my copywrite and made sure there was some bottom padding between it and the footer border
• I turned the list container into a Flexbox and gave it space around each unordered list

After all that, it looked good! Below is a picture of the final product:

It's basic but functional. Below the copywrite, I can include social media links in the future as well as remove some of the default browser styling for links (the blue color and underlines). Overall though, I'm pretty happy with how it turned out! I did a project a few years ago which involved a footer and it was very cumbersome to put together. Having a reusable component with this CSS will make it easier to include the same footer on every page of a future site.

Reviewing HTML concepts and establishing a habit

 In my planner each week I write out three things automatically.

1. Some sort of motivational theme or (soon) a bible verse as my "theme of the week"
2. A task each day to exercise
3. 30 minutes of freeCodeCamp

Exercising is still something that I need to improve on the habit front. Last week was a bit of a downer, and I think partially it's because I didn't drink enough water, exercise, and eat healthy (hello popcorn for lunch twice).

But with freeCodeCamp, I've been able to establish a nice rhythm. Either in the mornings or during my lunch break, I'll set aside 30-45 minutes to work on the new full-stack developer content they recently released (linked in my previous blog post). I decided to just do everything in the cert, even though I've previously finished their HTML/CSS content and most of their vanilla JavaScript content. It's good review, and I'm a completionist I suppose.

And I'm glad I've taken time to review the HTML content. First off, it's been way more in depth than their previous courses. There is a much higher focus on accessibility and semantic HTML. A few things which have stood out:

• Presentational vs Semantic HTML: Presentational is older and includes elements that are no longer supported, and it's main focus is just on the look of the content on the screen. CSS has made most of these elements relatively pointless now. Semantic HTML involves using elements that are more descriptive in their purpose (as opposed to the older <div> element), and they are better for accessibility and website SEO.
  
  
• HTML Forms have four states:
• Default: which is editable
• Focused: when you're in one of the form inputs specifically (i.e. clicking into a text field and the box highlighting a blue border)
• Disabled
• Read-Only
• (The HTML Form states sort of mimic what I'm used to with Harness rules in Pega, so I found it interesting.)
  
  
• HTML Entities: these provide a way to write out certain symbols that are usually code in HTML. For example, if I want to write out <div> in HTML text, without HTML entities I cannot accomplish this because the browser will think I'm trying to start a new <div> container. With HTML Entities, I can use a combination of letters and/or numbers to have the browser render symbols like < and >. These combinations are called references:
• Named character references start with "&" and end with a ";"
• &lt; is the < symbol
• Decimal numeric references are similar but use numbers instead of letters
• Hexadecimal numeric references are similar but use hexadecimal instead

I'm currently going through the lecture video series for accessibility, which is a deeper dive into screen readers and tools that come native with operating systems to help with viewing or listening to content. Additionally freeCodeCamp is reviewing various peripherals like larger-text keyboards and different input devices like trackpads and mouse-balls and joysticks. All must be taken into consideration for modern development.

That's all I have for this week. I'm also glad I could sit down for 20 minutes or so and type this out this week. I want to blog (ideally) every week, so this week was a success!

Setting 2025 developer goals

2024 is behind us and 2025 is here. New year. Clean slate. Last year was my first full year as a developer and it was full of learning, moments of extreme doubt in my abilities, and some fantastic moments as well. To recap, I attempted the Pega SSA exam three times and fell one question short twice. At some point I plan to study and take the exam again, but I'll be taking some time off from that.

My overall personal goal in 2025 is using a planner for the full year and being more organized through consistent planner use. That sets up the foundation for smaller goals that I hope to achieve this year for myself, which are listed below.

So without much else to add, below are the developer goals I hope to achieve in 2025. Unlike last year, I'll try to keep the blog updated with my progress.

1. Blog more. This is sort of a gimme. I blogged just a handful of times in 2024, mostly because I was busy studying or working. Taking a break from studying will hopefully allow for more casual learning and time to write. My goal is one post a week, and I'll review at the end of January to see how that goes. I may adjust it in February if needed.
   
   
2. Work through freeCodeCamp's new curriculum. freeCodeCamp just released new updated content and have started focusing on free developer certifications. The content includes video lectures, workshops, labs, quizzes, reviews, and one large final exam. I'm very excited for this, and will probably write more about it in the future, but I think this is the type of setup I've been waiting for. Currently I'm in the HTML section doing review before moving on to CSS, but once we get to more advanced topics, I think this will be a massive help for my learning. Most blogs will probably be geared around new things I've learned while going through the certification program. While I won't be spending a lot of time each day on it (due to life and such), I'm going to be extending this into 2026 and hope to earn the certification during that year.
   
   
3. Pass the Pega SSA exam. This will be in the later part of 2025, but I want to attempt the SSA exam again and hopefully pass. It's not required for my job, but everyone else on the team has it at this point and I want to be able to say the same. Related, I'll need to renew my Security+ this year as well, as that's an exam I never ever want to take again!
   
   
4. Read more. I'm aiming to complete six books this year - an average of one book every two months. That's a good goal for me, but it's also something I can also surpass pretty easily. I'll be writing on some books I read this year here on the blog, so be on the lookout for some of those. I've started 'Chip Wars' by Chris Miller, which my manager read and said it was very good. President Obama as well mentioned this book as one of his favorites in 2023. But I won't be reading just tech-focused books. I hope to read a fiction book or two, or maybe some random non-fiction historical books. I'm taking it one book at a time.

So there we have it - these are the developer goals I'm shooting for in 2025. These are not resolutions, and they may not all happen. But it's something to work towards and share with others. 

What goals do you have for 2025?

My software development journey

A few months ago, I accepted my first software development position with my company. It was a really cool moment, and it was a culmination of around four years of work, practice, courses, and being swayed back and forth on different languages and techniques. Several people in my life now have learned that "I work in I.T." and ask about how I made the career switch, and when you get the same question several times you know what comes next - a blog post!

Below will be a brief recap of my career, what I did and my motivations for doing it, and a few lessons I've learned along the way that I would give to anyone else looking to get into I.T. or software development more specifically. 

Where I started

I went to school for Sports Management. I wanted to work in the front office of a major sports team. That was the line I repeatedly told anyone who asked. I did not have a specific role in the front office defined in my goals but usually would default to something like "probably sports marketing." That's a role that has a sexy title but keeps you away from being in sports sales. Funny enough, sports sales has the highest number of job positions available and seemingly the lowest amount of people interested.

I graduated from school (both a bachelors and masters degree in Sports Management), and found positions with the Washington Nationals first (Inside Sales) then D.C. United (Account Executive) where I spent roughly the next four years of my life. I loved it at D.C. United despite the atrocious stadium we had to work in (that could be another blog post, but we were young and could work through anything). But I spent almost four years in the same job and knew that sales just wasn't my thing. And with life changes occurring in my late 20s, I needed to find something new that would fit the life I wanted. I guess that's a vague way of saying I wanted to be paid more and work a normal amount of hours in a week (sports can have you work way over 40 hours per week and the salaries can be heavily diminished due to "demand" of people wanting to get into the field).

The interest in I.T. begins

In 2018, I made a bold jump to take my first job out of the sports management career. It was scary, since I felt I was starting over at 28 and even though, yes, I was still young, I didn't feel young. But I found a position at a real estate tech startup (Compass) as a Customer Success Manager for the real estate agents. I loved it there. While at Compass, I started editing the HTML for our Agent's profile pages. I was just following a script made my someone else, so I didn't know exactly what I was doing. But my interest in learning about HTML started there. In the summer of 2019, I enrolled in my first HTML course at Codecademy and built the brown bear website. I think that course, as of this writing, is still there today - good times! I found freeCodeCamp shortly after and did their HTML/CSS course, and I did a short Python for Data Science course to close out 2019. I was hooked - I wanted to be a software developer.

But how could I do it? Bootcamps are quick but were expensive and I'd have to leave my job, plus take the extra time after the bootcamp to find a job. That's a lot of money to spend/lose and the opportunity cost could be very high. Learning on my own is mostly free, but it can take much longer to make that transition. And as much as I would have loved to go and get my Computer Science degree, that's another 2+ year commitment that would cost a lot of money that I didn't have. For the time being, I would learn on my own.

The strategy

In 2020, I left Compass due to moving out of the area, and in early 2021 I joined Cybrary as a member of their customer experience team. It was a good role that gave me access to a lot of online training for I.T. and Cybersecurity. On one of Cybrary's podcasts, they invited Meg West onto the show. She described how she was able to get her first Cybersecurity role by laterally moving within her company from her non-I.T. position to a cyber role. The hardest part is getting that first job, and sometimes the best opportunity to land that first role can come at the place you're already working. That was a lesson which sticks with me to this day.

One of my good friends in I.T. recommended that while at Cybrary I should get my Security+ certification. It's a great entry-level certification, and it's a door-opener for I.T. roles of all types. It took about four months of hard studying, but I passed the test! Almost immediately a service desk position opened up at my friend's company that required the Security+, and I applied and got it. With Meg's story in mind, I got to know our software development team within the first few months and started studying the tools they used to maintain our applications.

While at the service desk, I worked as hard as I could to learn the job, build a reputation of consistency and excellence in the office, and be open about my career goals with my manager. My manager told me he expected that his service desk technicians would want to move elsewhere in tech and he envisioned the service desk as a training ground for better things. I told him early on I wanted to be a software developer, and if there was ever a fit I would want to check out opportunities within the company. 

The Offer

Over the summer of 2023, I worked to earn two required certifications for our software development team. I didn't know if anything would materialize, but I wanted to put myself in the best position in case an opening came up. The manager on our development team included me on some of the team's meetings, and I was given a small application assignment to work on while having down time at the service desk.

In the fall, I was informed that a position would be opening shortly that would be using Pegasystems for development (it's a low-code Platform as a Service (PaaS) for creating business-process apps). The position required a certification for Pega that I did not have (Pega Certified System Architect), but I started studying while going through the application process. The exam was hard, and I failed the first time by one question. The second time, I passed and was offered the role on our software team - I had made it! My first day was December 1, 2023.

The lessons I learned a long the way

It's been a few months since I started my position on the development team at work. I have loved it, but it's been the hardest job I've had. There is a lot still to learn, but my team is really great and has helped me when I have questions or get stuck something. I tried to be as brief as possible while providing as much context as I could, but there were a lot of things I left out in the essence of time. But below are several lessons I want to pass on in hopes that it can help someone else who transitions careers like I did.

1. Look at where you currently are: if you are already working at a company, see what types of software development opportunities already exist. Find the manager of the Dev team and let them know about your interest. Ask to shadow someone for a few hours, or if there are any volunteer projects you can hack on. Also, ask if you can join their meetings every once in awhile. Also, look at the job board on your company to see what job requirements are provided for the role you want. After you gather this type of information, start studying those languages and tools.
   
   
2. Don't be afraid of the service desk: the service desk is a great place to get your foot in the door. There are many in the I.T. field who will absolutely refuse the service desk ("I just don't want to work with customers"), but don't be that person. The service desk is a straight-up skill-builder and will only help you get better.
   
   
3. You don't need a Computer Science degree or to be some sort of math genius to code: you may already know this, but a CS degree and exceptional math skills are not required. They certainly help for sure, and being good at math is needed if you want to be on the cutting edge of AI and machine learning. But a software developer does not need to have a CS degree. Math-wise, know what PEMDAS is and some basic logic, and you'll be good. Those who require a CS degree are, frankly, way behind the times.
   
   
4. Consistency is the king of learning: having discipline and consistency in learning, especially if you're self-taught, is crucial. Make a goal of spending X minutes a day coding based on your schedule, and really try to hold yourself to it. In 6-8 months of being consistent with learning, you'll be thrilled at the process you have made. (Check out Atomic Habits by James Clear by the way- fantastic book).
   
   
5. Build your portfolio of work: This is a mistake I made and will not make again. When I applied for the developer role at work, I didn't have a portfolio saved to show them what I had done. That almost cost me the job. If you haven't started one yet, start saving your projects to Github. Proof of learning and building side projects is very helpful.
   
   
6. Build your reputation wherever you are: my last piece of advice is almost one of the most important - build your reputation at work. Be professional. Be on time. Find the metrics that you are judged at for work and exceed them. Be friendly with everyone and also be present and visible in the company. This can greatly help you later on. And this is possible even being 100% remote! I was 100% remote at Cybrary and in a vastly different time zone, yet I was active on the company Slack and I went to as many company meetings as possible.

So that's it! That's my story up to this point. I was as brief as I could be, and I left out other things that I may write about in the future (tutorial hell, being distracted by the next shiny object, imposter syndrome). All of these topics happened to me along the way as well. Thanks for reading, and I'll see you at my next post!

Learning about the Luhn Algorithm

While learning to code, more experienced programmers and senior developers will say that in addition to knowing coding languages, syntax, and general computer knowledge, having a firm understanding of algorithms will really help you in a coding interview. There are established algorithms out there in the world that exist to solve problems, and it's good to know they exist, when to use them, and how to implement them.

The Luhn Algorithm was created by Hans Peter Luhn, who was an IBM scientist, and patented in 1960. It's used to verify a string of numbers, and mostly it's used for credit card numbers a long with various IDs. The Wikipedia page for the algorithm has a list (unsure how up to date it is) of the types of IDs it's used for.

It takes a string of numbers, and starting right to left it doubles every other digit, then adds the digits up at the end. If the sum of all the digits ends in a 0 (i.e. it's divisible by 10), the number is valid. Otherwise, the number is invalid. This seems simple, but there is one extra step. If the doubled number is two digits (greater than 9), you replace the double number with the sum of it's two digits.

For example, if you double 6 you get 12. 12 is greater than 9 and is a two digit number. So instead of using 12 in your sum, you add it's two digits: 1 and 2. So you end up with 3.

If you didn't get that the first time you read this, that's okay. I didn't either when I was first reading about it. Luckily, James Hamblin has a fantastic video on Youtube that explains the algorithm with a credit card example, and he does a fantastic job at it. Below is the example he uses in the video.

 

As you can see, starting from the right and going to the left, we begin at 5. 5 is the first digit, so we leave it alone as the "Product."

The second number is 9, so we double that and get 18. But since 18 is greater than 10, we add the two digits instead. 1 + 8 = 9. Thus, 9 is the "Product" for 9.

The third number is 7, which we leave as is.

The fourth number is 8, which we double to make 16. Again, 16 is greater than 9. So we add 1 and 6, and we end up with 7, the "Product."

We continue to follow this pattern all the way through the end of the string of numbers. Then we sum all the numbers on our Product line. The sum of the "Product" numbers is 70, so this number is indeed valid!

Now what happens if we are missing one of these numbers? The Luhn Algorithm will be able to give us the correct number because of it's rules. 

The current sum of the "Product" line is 73. We know that the furthest right number has to be multiplied by only 1, per the rules, and we don't have negative numbers. So we have to get our Product sum to 80. The difference we have to make up is 7, and the only way to get 7 with the weight of 1 is...you guessed it: 7! 

So this is how the Luhn Algorithm works. In my next post, I'll write up how I went about doing this in Python from a freeCodeCamp course I took. Thanks for reading!