[This post is a bit of a long one, so grab a snack, a drink, and enjoy the trip!]
I've spent years helping software teams deliver solutions with high confidence, but always under someone else's vision: mentors, CEOs, VPs, even the occasional know-it-all developer. Now, however, I'm on my own. Freedom Finally? Except... there's a persistent echo chamber in my head, a chorus whispering doubts. (à la you are on the stage for The Voice competition, no coach is turning their chairs around, and your song is almost over!)
Stirred, not Shaken
The other day a recruiter delivered a brutal truth bomb: my resume is a jumbled mess, and therefore a "difficult hire in this economy." It stung, because there was truth in it. I'd been clinging to the idea that my diverse experience was a strength, a selling point. Maybe it was. But right now, it read I am a talker with no action. In today's world, without resources and the ability to turn ideas into reality, you can feel pretty worthless in the business game. Hold on, let's re-frame that. Your inherent value isn't tied to your bank account. That recruiter's "worthless" comment? A wake-up call, not a coffin.
The truth is my diverse experience wasn't random. It stemmed from a long-held dream of launching my own business. Even before my career in Information Systems. I wanted my own business. The 'so what do you really want to do?' question in interviews always throw me, even to this day. Part of me craved the stability and learning a traditional job offered, a way to reliability provide for the family my wife and I had created while gaining the practical skills needed to eventually strike out on my own. But the other part, the all consuming part, yearned to turn my ideas into reality. Maybe the hiring manager wouldn't understand this internal struggle, but that recruiter's comment was a turning point. It forced me to confront my own fear and take action. It's time to bridge the gap between my vision and the resources I need to make it a reality. Even with limited resources, there are ways to navigate the "rules of the game" and find the tools you need. I know it is possible because I have done some of it and witnessed all of it due to my decade of living the start-up life.
What I Plan to Post
On this platform, I plan to document my journey towards launching a web services business. We'll explore strategies to start a business in today's economy, identify alternative resources to keep costs down, and ultimately, turning those brilliant ideas into reality. I've seen firsthand how promoting features that aren't built can lead to failed projects – the dreaded vaporware. To avoid that fate, I need to build demos of the digital products I plan to sell. Today, I will start by creating a development environment on my home network...
Here are my Goals for today:
- Build a Next.js Demo - Why? It is the ideal framework (e.g., SEO-friendliness, server-side rendering, and general ease of building frontend interfaces) for landing pages and marketing websites. This is the first market I plan to target.
- Setup Minikube - Why? need a reliable environment to test these demos across various devices, something browser developer tools can't fully guarantee. Minikube will simulate a production environment for thorough testing.
- Dockerize the Demo - Why? So I can deploy it to the cluster. Less obivious but more importantly, it creates a standardized and portable image for deployment (bonus: > dependency control) ready to deploy to Minikube.
- Deploy the Container to Minikube - Why? It puts everything together. A successful deployment on Minikube will be a valuable learning experience, allowing me to replicate these steps for deployment on any cloud platform, even a private one, in the future!
Okay, lets get started... (its gonna a long one so buckle in!)
Building with Next.js
As I mentioned above, the Next.js framework, is the ideal framework for landing and marketing pages. While I think it holds true at the time of writing this post, I don't this will always be true. Also I don't think this is true for everyone. For those with Django experience, it is very likely creating a landing page or marketing site using the Django framework may be much easier than using Next.js. The same goes for anyone with experience with other languages or framework. Here are the reasons I chose to use Next.js as my first framework to create demo sites to show potential customers.
The Documentation Fits My Eye and Mind - The showcases on their site, the templates offered by their maintainers, Vercel, and the how their documentation reads allows me to get started quickly but deep into customization where and when I want it. The other framework documents give me the feeling that their maintainers expect me to get excited about reading before doing, or at least have the skills to manage the doing and the reading. If you have ever learned something new, this is a skill. At least for me, I just want to do and don't open the manual until I get stuck. I believe the Next documentation and examples follows that mentality.
Above I picked on Django a bit but in reality it is because I like the python language and I have gone through the Django tutorial, a few times, and at the end of the tutorial I thought, "Now what?" Although I don't think it is a knock against the framework but rather it just doesn't fit my brain and if there is another option, I am going to try that (of which I have tried several).
Javascript is the Language of the Web - As much as I tried to avoid learning Javascript (mostly because of all the horror stories told by the Java Zealots, and almost every other fanboi out there), the truth is that if you are building a digital product for the web then chances are that you will NEED Javascript to make your product feel modern and interactive (especially client-side). It is the prevailing, dominant language for all things web development (don't worry fanbois, I totally plan on building demos in other frameworks).
I have to Start Somewhere - Frankly I am just tired of trying everything else and am deciding by popularity. Nextjs is the most popular React Framework, React is most popular *library for building interactive applications (sorry Preact, Vue, Angular, Svelte and others if anyone decides to leave it in the comments), and Javascript is the most popular for building web applications.
Ok so now you have the context(ALL OF IT), here is now I built a landing page using Next.js.
Prepping the Environment for Development
- Install NVM, NPM, Node, and NextJS - this is what I needed to manage the versions of node, install the nextjs framework, and manage any dependencies I may accumulate while building the landing site demo. Although some may think some of this is an optional step, I don't really share that opinion. All enterprise software shops version control the crap out of any and all artifacts. Why? Simply put: you don't work on enterprise product alone, and likely not even the same method. As a career quality assurance guy, this is best practice. If you find yourself or a co-worker sharing source code over an email, a dm on chat, etc. be very worried as this is always short-sighted. It is only a matter of time before that code implodes in production and when you have no way to roll the version back (because you have no version control) well let's just say it will be a late night for you as you rewrite the application, or worse, uncover what caused the implosion and attempt to pull that piece of code out. So just add version control at the start. This is what I am doing here. I am an engineer (or as I like to say, an aspiring engineer) and engineers build with failure in mind. If you are not, you aren't an engineer, you are a developer, a writer, dooming your product to fail terribly in the hands of your clients and having no way to quickly reconcile it#HotTake
Side Note
I am not going to make this tutorial about getting a node development environment up and running. This is document of my journey. I know how to install nvm, npm, node, and NextJS. If you are looking for a decent guide, I quickly curated a few:
NVM
a. NVM Git
b. freeCodeCamp
c. Node's site (as if you needed any other proof that this is a best practice)
BONUS
A list of useful nvm commands
Node
(see section c under NVM)
NPM
Here is picture of my terminal, which might date me a bit. If you can tell what I am using and think I should use something different, let me know in the comments. I am not always the best but I want to be better: for me and for others.
There isn't much to ramble on about installing NextJS. To me the hardest part is past you at this point. You can go here to get started. Actually there is one minor step here: You should probably think about where you are planning to host this code. For me, I created a directory called 'develop' in my 'home' directory. This is mostly arbitrary really. Its your local environment. Some of you may have this already running in VM, a container, nixOS, or use an IDE. For me, the terminal is my environment. It is because it is where I am most comfortable on the computer. I have been using terminals since the Commadore64, and when I thought being a network engineer was my career path, I dug into using shell. Old habits die hard ya know!
As you can tell this is not exactly the same as what the document says and that is okay. For me I know to expect this and you should too. Whenever relying on a static document to show you how to use an ever-evolving software application, it will come to pass that the document has become stale. If that gives anxiety, just remember the words of the brillant Donna Haraway and, "... lean into the trouble, " it is what makes us human. The final part of this section is that I just accept the defaults. I am doing this because this is a 'green field' build and from my experience deviating from the defaults means a few things:
a. You already know what you want and the defaults ain't it
b. Your team lead knows what you need and the defaults ain't it
c. You are experimenting with the framework but are confident in your react, express, node, and/or js skills.
d. None of these, the catch all because this list is already too long.
BONUS
Notice in the image above that there are warnings, usually this is ok and can be ignored usually. In my experiences as a QA resource, I would not like this and I would put a ticket on the board. Those tickets usually ended up in the backlog and were not touched until it caused an outage in production. This is where speed and quality just don't mix but guess what I am not wearing my QA hat just yet and just as a developers do sometimes, I am going to ignore them until they become a problem (either in my testing or post-deployment). Hopefully I don't eat my words here.
- Change into the project's directory, run npm run dev, Delete the Boilerplate, and move some files around - Now that the local development environment is installed, I can change directories (cd for *nix users) and run
npm run dev.
Now I delete.
I mean delete the html. I learned a long time ago that this is right move. If you are concerned about deleting code, you may want to reconsider your desire to be developing software. Revel in deleting code. Your boss will love you. Just make sure it works afterward.
Next we make some directories for our styles and components because as your scripts and styles grow, it gets challenging to keep it all in your head. Also this is just best current practice and component-based development is the current standard in react-derived frameworks.
Next I made a styles directory and move globals.css into the new directory.
You should get an error but that can easily resolved by updating the globals.css import in the layout.tsx file.
Now we can get into the fun part: writing some html, css, and js to build the demo landing page... well almost. We probably do a simple wireframe for this demo. Design, even if you have a designer on the team, is a great practice to get into. In my case I believe the wireframes will be an excellent way to interact with clients, even if it is to send pre-made mocks via email.
Here is what I think these are the basic components of a landing page.
Now I have designed the basic components. Don't worry I can add more as needed because its software. The barrier to create, update, and delete (most of CRUD) is much lower than say if I were building a house. With that said as an aspiring engineer I always attempt to build something I can repeat and easily maintain in the case it needs an update or removal.
Here are my basic components
- Header - where the navigation bar and navigation options will be
- Body - where the content (e.g. the hero section, the about section, contact section, and so on) will go and selections from the nav will route too
- Footer - where I can put social media links, copyright info, etc.
Now I can start writing...
- I am going to start at the top with the Header.
- In my components directory, I use touch to create header.tsx
- VIM-ing into the header.tsx, I write some html and some css with tailwindcss. I also added my new header component to the layouts.tsx file also.
- Now just repeat that process for the footer component. But before we do, the styles in the globals.css file is starting to bother me. Has it started bothering you yet? Well, it is no problem.
Just delete most of the boiling plate... again. This time it is in the globals.css file.
Now lets rinse and repeat that footer component. Then add it to the layout.tsx
- Time to stamp out some content. For this demo, I am adding a few content sections that I believe every landing/marketing page should have: a. Hero - The attention elevator pitch for why the business has value. b. Service - The section that provides an elevator pitch for each service the business provides c. About - Where the business tells potential clients why. Why the owner started the business. Why current clients like their services. Why potential clients should pick this business d. Contact - A call to action. The business needs close the deal here.
Now that the basics of the landing page demo is marked up and running. Let's switch gears to infrastructure.
Dockerizing the Demo
Originally I thought that I could write this but I couldn't. Instead I used the example from the vercel repo. It worked. There were some warnings, I will eventually address, but for now I have a working container. It was also too easy.
Deploying to Minikube
Well I thought I could just do this without much guidance. I figured I would set up minikube the way I wanted and just be awesome... and I was totally wrong. I worked on this with just the kubernetes, nextjs, and docker documentation for a couple of nights. It was a challenge. A challenge that I decided was for someone else, maybe even a past version of me, but now. This ain't it Chief!
I ended up following this post it worked like a charm. Well mostly worked at a charm. I am still having issues with exposing the container to my LAN. I could get to it locally but not from another device on the network. I triple checked my values in etc/hosts and yaml files. What was I going to do? Well honestly I think I need to end this post. It is so so so long.
Final Thoughts
Well as it turns out, it costs like $48 per month for Digital Ocean to manage a public-facing Kubernetes Cluster. One idea can't be that expensive and so I am going back to the drawing board. I have a droplet running my static pages and my mind is telling me I can deploy the nextjs app as a systemd service and configure the nginx service to expose it as a *.declared.space (thinking it will be something like nextjs.declared.space or something like that).
Cary On
I would be lying if I said I am happy with how this post is ending but I know this isn't the end. Despite my disappointment I know I am going to keep trying. At the beginning of this post I was confidence (and maybe a bit unreasonably so) that I was going to be ending this with announcing that I got my client but that isn't what happened. With that said I now see that part of my story to tell is one of trial and error. My story to share here is the reality for most aspiring software developers that try to do what I am trying to do. Where I think most post only their success, I am here to share it all. I am here to embody the code in public mentality. This is how I learn: believing I am capable of more than what I am doing today, constantly reaching, constantly falling short of perfection, but never giving up. I will be back with another post about this. This forever series of climbing. As the wonderful artist, Thundercat, sings on their song, The Climb:
Every time that I turn around, something trips me up
Soon as I feel I got a grip, shit starts to slip
When everybody wonders where I've been through all of this
All that I'm reminded of is that I just can't quit
It's for sure and up to fight, and downhill you fall
If you're gonna get scarred up anyway, then you might as well climb
Justification and Invitation
I went back and forth on whether or not I should break this up. All the LLMs I collab'ed with encouraged I should but I wanted to pour it all out there for this one. I am an emotional being. I am told by some that it is a blessing and a gift, but with every gift there is a cost. Please sub my profile (or whatever it is for this platform) to get notified when I post again. I know it will be better organized. Next up, setting up this app as a systemd service and exposing to the public webs via NGINX. I am also on Medium (although their platform is a bit annoying). I am posting on these platform to get used to blogging with the intention to eventually house this content on a server I maintain because that is all the internet really is: content on someone's computer. Oh yeah also check out my personal page here.
Top comments (0)