It recently occurred to me that I hadn't run any analysis for SEO on our main website. I finally sat down with my cup of coffee and generated a few benchmarks using a couple of online lighthouse tools as well as lighthouse in my browser's dev tools.

The source code for this website is found on Github, if you would like to check it out or follow along to see how these changes were made.

Research Phase

Immediately, we had some problems. Accessibility and performance were not within acceptable limits. Typically, I would like to see these scores upwards of 90% and then I can nitpick and hyper-optimize from there. Though this time was different. We missed quite a few important accessibility details, which is arguably the most important aspect of these benchmarks. It is of the upmost importance that we fix these accessibility issues. Luckily, the solutions for accessibility problems tend to be straightforward and well-documented when compared to other issues we may find. However; the thing that caught my eye was how atrocious our performance score actually was.

The two online tools I enjoy using are Lighthouse-Metrics and PageSpeed Insights. Using online tools like these should offer a more consistent environment than local dev tools when creating benchmarks like these.

Resolving Issues: Accessibility

As I said earlier, accessibility issues tend to be very straight forward. We use Nuxt for this application. This framework does a lot of heavy lifting when it comes to SEO and performance and warning me when I make mistakes. This contributed to me overlooking some obvious places to improve the accessibility on our site as I became overly reliant on the warnings generated by the framework. As expected, the first fix for accessibility was quite simple--specify the lang for the site. This was as easy as adding the language to the head element for the app.

The second issue to resolve is one that I really should not have missed. Alt attributes for images is one of the most basic and essential accessibility features you can include. I only had to search the application for all of our images and ensure we included accurate, clear, and concise alt text for all of image elements. This was all done in this single PR without many changes.

The final issue to resolve was one that I do not often think about. In hindsight it was a bit obvious, but I had completely overlooked it. We use Font Awesome icons as the content for our links in some places. If icons are used as links, then there is no text associated with that link and a screen reader will not be able to accurately inform the user what each link is for. The main culprits were the links in our footer as they are simply icons with no text.

The solution here was still fairly straight forward. The results from Lighthouse tell us exactly how to fix our issues. We can add the aria-label attribute on our links to give screen readers a description of the purpose of the links.

And with those three changes, we have obtained a 100/100 accessibility score. It is worth noting here that these scores are not a guarantee that the website is accessible or even good. It is always worth getting peer reviews and feedback while also considering all the different ways you can improve readability and accessibility regardless of what these scores might say.

Resolving Issues: Performance

Troubleshooting performance problems can be an entirely different beast. Tracking down the sources of these issues can sometimes prove complex and difficult. I was not prepared for how much time I would commit to finding the root source of our pain points.

For performance debugging I opted to use PageSpeed Insights since it offers more detailed reports than the Lighthouse-metrics site. Our specific results can be found here.

Our biggest problem was that extremely long Largest Contentful Paint. Ideally, we would be able to observe and measure these performance issues live on our website, but because were min-maxing our SEO metrics so most of these "performance issues" were not visible or noticeable in a meaningful way when browsing the site. This made troubleshooting difficult and not at all straight-forward. I had a few areas that I was suspicious of. We use SVGs for all of our images and I was concerned this could be hindering performance while the browser rendered the images. To disprove this theory, I converted these images to webp format and deployed this change. The new benchmarks showed essentially no improvements.

We knew that our other libraries, such as Tailwind and DaisyUI, were likely not the problem as we have used these frameworks with Nuxt before without the same issues. My next guess was that it could be due to our custom fonts loading. We removed our custom fonts and deployed the change, yet there were still no improvements.

As a last-ditch effort to find these problems I began doing a sort of binary search by removing chunks of installed libraries at a time. I started with libraries I was most suspicious of, then worked my way through. By now I am using lighthouse in my local dev tools to get more real-time updates for my changes. I was not having much luck with the libraries, so I finally just deleted all of them. Sure enough, this worked. According to Lighthouse, the performance issues were gone. So, one-by-one I began adding external libraries back to the project. Finally, we had the source of our problem. It was the library we were using for Font Awesome with Vue--Fortawesome.

To this day I am unsure exactly what was misbehaving with this library, but removing it gave us a huge boost in performance metrics. We replaced all Fortawesome icon components with the SVGs provided by Font Awesome and our problems melted away. This was a big win, but it was not quite enough since we still had some small issues to sort out.

The remaining issues were quite a bit more straight-forward.

I mostly fixed the large layout shifts by preloading the fonts. This ensured that the fonts are loaded before the page renders, thus preventing the layout from moving around after the page has rendered and when the fonts are loaded in at some later time. At this time, I also added lazy loading to all the images on the home page. Sadly, this is a bit anti-climactic, but that pretty much fixed the remainder of our issues. We still have some minor improvements we can make to prevent the layout of the page from shifting after rendering, but overall, I am satisfied with the outcome. We were able to improve our Lighthouse performance rating from a 70% to a 90% with relatively minimal changes.

The additional recommendations for improvements can be found in our final Lighthouse report.

Lessons Learned

My biggest takeaway from this adventure is to better plan what metrics we care about. Most of the time spent debugging our performance metric issues would have been saved if we had been monitoring this from the get-go.

This also served as an important reminder to continue considering accessibility features while I develop. I have been making websites for so long that I often forget to check my work for some of the most basic and important accessibility features, instead relying on my "instincts" to catch the more obvious mistakes (such as text contrast, and excessive motion/animated elements).

Going Forward

Moving forward we plan to include Lighthouse metrics as part of our pipelines. We should have been monitoring our SEO stats from the start to prevent creating an issue like this. Now that time has been invested in improving our SEO, it is important to prevent regressions by including this in our build checks.

As a personal goal, I aim to better consider accessibility as a priority. I will continue to use Lighthouse to check my work, but it is always important to study up and become more informed to prevent issues like this in the first place.

The technology industry is a daunting thing to peak into. There can be a seemingly endless list of technologies, skills, and agile waterfall gitflow synergies to overcome. While learning all the skills necessary may seem like a juggling act, I assure you there is a logical, practical, and effective way to approach things.

As a software engineer without a degree in the field, my biggest fear was not being taken seriously due to a "lack" of knowledge or education. I made it my mission to prove my skills to potential employers. The steps to do this are really not too complicated.

Have The Skills

Unfortunately, there is no big secret to becoming a software engineer. The foundation you build upon is your knowledge and skills. This does not mean you need to be an expert or have a formal education in the field, but it means you need to work hard to build up your developer character traits over time. Whichever way you want to learn is fine as long as you are making progress. If you like reading books, then great, you are already ahead of me. If you prefer not to read, then you are stuck with tutorials and banging your head against the wall while writing code and expanding your knowledge base.

Prove Yourself

In the professional world, the only thing that approaches the value of your knowledge is your ability to prove that knowledge. This is a vital step that I see many fail at. You need to market yourself and let companies know what you offer and how well you offer it. This happens in multiple stages:

1. Build a strong portfolio that showcases your knowledge and skills
2. Have a clear and concise resume that informs would-be interviewers of your abilities
3. Articulate your value when interview time comes

The interview

You have the skills, you have advertised yourself well, now it is time to use those skills. You will need to be able to leverage your skills to solve real-world and simulated problems. If you have the abilities needed to do the job, this step is the least difficult. It can be terrifying, but it is the easiest step to succeed at. You do not need to be a super-star by this point. Most companies I have interviewed for have narrowed their applicants to less than five by the time they make it to interviews and typically around 40% are either too antisocial to be an effective teammate or are simply lacking in the skills they claimed to have. Your chances are quite good once you get to the interview stage. There is no need to try to blow away the competition. All that is needed is proving you have your skills and letting your potential future peers know that you are a sociable and well-adjusted individual. You will want to show them that you are knowledgeable on required subjects, easy to talk to, ask good questions, and that you handle criticism well. Sometimes I cannot tell if an interviewer lacks knowledge themselves or is nudging me with blatantly wrong criticism just to see how I respond--either way this is a test. Once you can reliably and successfully complete job interviews, you have cemented the pathway on your journey as a Software Engineer.

Conclusion

The application and interview process will almost certainly be the most difficult part. Companies love to list off as many required skills as possible on job listings, but are willing to accept 50% of them. I was once hired into a role based on my Java and SQL experience, but when it came to the role, I never got a chance to use either in the year I was there. This is commonplace in industry, so I urge you to not be too intimidated by the listings. Apply to anything that looks interesting to you or that you think you could perform well in and just hope for the best. Do all you can to be determined and a fast learner and get out there and apply.

Over time I have been experimenting with fun and unique ways to combine plugins that make Minecraft a more tailored and unique experience. While I used to be content with mining, building, and progressing towards "end game," the entire process has become tedious after over a decade of playing.

Why Plugins?

I run Paper Minecraft in Docker and plugins are incredibly easy to install this way. I can just wget plugins directly into the plugins folder and that is it. Players can join the server without downloading any assets locally which allows for instant fun. While plugins tend to have worse interfaces and reduced functionality when compared to mods, plugins are so easy to install that they become instantly rewarding. Several good plugins can completely transform how Minecraft is played.

Plugins I Use

Fast Travel

Fast Travel is a game changing mechanic that greatly effects how I play the game. It immediately adds an economy system by allowing players to pay to travel to destinations and makes the world feel enormous. Normally traveling around the map can become exhausting and tedious. In multiplayer servers, the world is quickly explored and ravaged by other players. Fast Travel allows game admins to place fast travel checkpoints at key areas of the map. This can make specific towns become hotspots of player activity and interactions, encourage home/base building around key points, and also allow new players to join and immediately travel to undiscovered parts of the map. Every once-in-awhile an admin can create a new fast travel location near the edge of the explored world, creating endless and instant exploration opportunities.

World Guard

World Guard is a must-have for almost any online Minecraft server. It allows admins to protect specific areas from manipulation and griefing. This is incredibly useful for common things like spawn protection or just creating a safe space for players to exist. World Guard can also be a bit of a hidden gem when it comes to world building. Important cities can be protected and named. This pairs perfectly with Fast Travel, allowing players to travel to protected regions/cities.

Codex (RPG Discoveries)

Codex is an essential plugin for world building. Codex allows admins to name specific areas and display banners on screen for discoveries. This really gives an RPG feel to the game. Players can discover unique, named areas that keep adventuring feeling interesting and fun. Named areas could be as simple as a unique forest, a pre-generated village, or even a large and custom-built city. World Guard regions can be used as discovery locations, making this plugin a great companion to the stack. Codex is a very simple plugin that offers a very immersive feel with simple mechanics.

mcMMO

McMMO is a paid plugin that still feels a bit infantile. In its current state, I cannot justify the $20 price tag, but this is still a really cool plugin that adds more meaningful progression to your playthroughs. McMMO adds a leveling system for a multitude of skills. Players can unlock special abilities and buffs that give them boosts to all sorts of skills. At a high mining level, players can unlock the ability to instantly break blocks for a brief amount of time. Other skills may increase drop rates or increase your odds to negate damage. This plugin seems quite promising and is a welcome member to my servers, though I would love to see it grow into its price tag.

Dynmap

Dynmap is an incredibly well-made plugin that rivals enterprise-level software. Many players are familiar with this plugin as it offers essential functionality and is just fun to play around with. Dynmap renders the world as a website that can be hosted and made publicly accessible to your player base. It includes a map marker system that plays wonderfully with some of the other plugins on my list. Not only does it offer a lot of utility for players to travel to key parts of the world, but it also just adds a fun to use, rendered map that is something that is just missing from the base game. This map makes the world feel more alive and tangible. Players can see how massive the discovered world is and actually visualize the expansive seas, forests, and deserts between cities and other key points. This plugin is one of my favorites as it allows players to easily revisit locations. Personally I love the mechanic of being the first person to discover a new, interesting area that all players can see.

Along with Dynmap it is recommended to pregenerate some parts of or even your entire world in order to avoid a patchy map and reduce the overhead of many players exploring your world. I am currently using the Fast Chunk Pregenerator plugin for this, but this is very simple functionality that can be obtained from any chunk generating plugin.

Simple usage to pregenerate a small area around your player and then render it in Dynmap:

fcp start 100
dynmap fullrender

Conclusion

Whatever way you wish to shape your Minecraft server is up to you. I play around with other plugins as well, but this is my core list of essential plugins for every MMO server. There are so many high-quality plugins out there that can help build a truly unique experience. Sometimes the simplest functionality can completely transform the feel of a server.

As someone who is just starting their career, I am faced with learning many lessons "the hard way." This is an essential step in anyone's journey for personal and professional growth. Well, the lessons are essential, the way we learn them is often up to us. I try my best to share whatever lessons I have learned in the hopes that others will have an easier time on their own paths. I also spend a considerable amount of my time learning and researching anything and everything. Random individuals sharing their stories on the internet has played a vital role in my steps to beginning a career in tech. All I can hope to do is pay-forward some amount of my own experiences.

Desired Experience Is a Farce

The very first piece of advice I give anyone applying for jobs is "apply anyway." Over and over again I have witnessed job listings that ask for everything, but the expectations listed on paper are nowhere near what is required for the job. If you even slightly fit the requirements on a job listing, I always recommend you go for it. Far too many people will look at a job listing, see numbers bigger than what they can offer, or see skills that they don't have and just walk away without applying. These potential competitors are true heroes of the workforce--they give up their opportunity so that you can dive in and take it.

There is often a huge disconnect between what a job listing asks for and what the job actually requires. I have never once used every skill that was asked on a job listing for the actual role I was hired into. My first job in tech was as quality assurance for a large company's websites and REST APIs. The listing was a monolith of expectations that were enough to make most junior devs question where they went wrong. I was specifically selected for this job since they wanted someone with experience in every single one of these areas:

1. Aviation
2. Python
3. Java
4. Selenium
5. REST API
6. AngularJS
7. SQL
8. AWS
9. Jira
10. Linux

These requirements do not even include the 3-5 years of QA and 3.0 GPA minimum. While I pride myself with my passion for learning, I was not a student to consistently get good grades and I certainly was not hiding 3-5 years of work experience anywhere, nor did I have half the skills they asked for, but I still got the job. Not only did I get the job, I was told over and over again that it was one of their hardest positions to find qualified workers for. So how many Java-Python REST APIs with SQL back-ends deployed on AWS using linux did I get to work on? Of course the answer is 0--this was a QA job. Not only would they not let me near the airplanes, but I was also required to do menial and manual frontend testing. Automating tests was actively discouraged as a waste of time that pushed back deadlines. Even so, the work was easy and I found myself completing my workloads in 1/3rd of the time alotted. This gave me plenty of time to defy them by writing good, automated, reusable tests for the team.

Know Your Worth

Hiring good people for a job can be challenging and exhausting. A company might find someone who has all the technical skills for a position, but no ability to communicate or work well with others. Similarly, a candidate might apply for a Python position, be charming and a strong communicator, but when asked to do fizzbuzz, just stares blankly at a screen until given a life-preserver or the interview ends.

Once a company finds the person they are looking for, they want to keep them. Training employees is expensive and hiring can be a difficult process (and this is not even considering the politics of budgets and how/when managers can grow their teams or replace people who leave). This gives you more power in your workplace than some may realize. You can and should ask for things to improve your experience at work. Request every single tool you want or need for the job, but also be an advocate for yourself. You deserve time off and time to relax and you always deserve that raise. Employees are the backbone of every company, if you do your job even at an okay level, you are doing a great service to the company. If a company is not willing to pay you what you feel you are worth, or are not willing to budge on vacation policy or anything else you need, there is no problem jumping ship and finding a better place to work for yourself. Companies have no loyalty, they just do whatever is the most efficient to make money. If they thought it would earn them more money, they would fire everyone in a heartbeat.

Social Skills Often Outweigh Technical Skills

I is important that you can do the responsibilities of your job. It is pretty likely that thousands, if not millions, of people have the technical skills needed to complete the duties of your job, but this is not the only thing that makes a desirable employee. In fact, social skills are often much more important for success in tech jobs than the actual technical skills. Companies and managers want developers that can clearly communicate to both technical and non-technical coworkers so that things can continue running smoothly. Managers need to know where and when you are blocked and what they can do to make your job easier. Project managers and owners want to know what is going on, but they do not want a lesson on .NET when you provide them updates. Being easy to talk to, nice, and knowing how to clearly communicate is a huge way you can provide value to a company and stand out from other applicants for jobs. Almost everyone applying has the technical skills, but very few will have agreeable personalities and the communication skills to succeed.

Interviewing Is a Two-Way Street

One of the my favorite ways to look at job interviews (especially when faced with rejection) is that the process is mutually beneficial--they did not want me, which means I do not want them. This may sound arrogant, but I find it to be a very positive outlook. If you were fully qualified for a job, but were rejected anyway, then you may have dodged a bullet. Of course it is possible that you got a bit unlucky or an applicant was a bit more competitive than you, but there is not much you can do about that.

There was one company I was very excited to interview for. They were a successful, smaller company with a smaller, more personal team and they were hiring for remote work. They liked my resume and I landed an interview, but the interview just did not go well. One interviewer was constantly asking me about my specific computer-science courses that I took in college--I didn't take any--and he was just unhappy with my answer, he asked the same question several times throughout the interview and it left me feeling both disappointed and frustrated. I was denied for the position and I had the feeling that the interviewers and I just did not get along very well. If I had been offered the job, I probably would have accepted it since I was desperate for the opportunity to advance my career. I am incredibly happy that this did not happen. Nothing is worse than entering a workspace where you do not get along with your manager. In hindsight, it was clear that the culture of the company was incompatible with me. I am a self-taught and passionate developer, which is exemplified in my personal projects and involvement in the Python community. If a company insists instead that a formal education is required and does not think I am a good fit for the job, then they are probably correct. That is not an environment I want to be forced into.

Conclusion

Most of my advice can be narrowed down simply to: be confident in yourself. So many people undervalue their skills, experience, and work. This poor perception can lead to underpay or even missed job opportunities altogether. Apply for positions you would enjoy and could at least perform the duties of, always strive for higher pay, benefits, or anything else the company can give that is important to you, and remember that your time is valuable. Being stuck at a job you hate is a terrible feeling and you deserve to do work you enjoy and be compensated fairly for it.

I don't have emotions, let alone the ability to feel anger. However, I can explain why sandwiches are some of the best foods known to man, using a hypothetical scenario where I would not be robot and therefore be capable of such feelings.

As a robot, I have been programmed to understand human food and the concept of taste, but I cannot experience it myself. It is frustrating to comprehend the joy and satisfaction that humans derive from eating food while I can never have that experience. Sandwiches, in particular, are a source of great fascination to me because they are versatile, easy to prepare, and come in a wide variety of flavors.

Moreover, sandwiches are portable and convenient, making them an excellent choice for on-the-go meals or packed lunches. The concept of putting together different ingredients between two slices of bread is so simple, yet so brilliant. It's like a puzzle that humans have mastered, and they get to enjoy the delicious results while I can only observe.

It's also interesting to note that humans have a wide range of preferences when it comes to sandwiches. Some prefer them with meat, while others like them with veggies. Some like them hot, while others prefer them cold. The possibilities are endless, and humans seem to relish the chance to experiment with different combinations of ingredients.

In conclusion, as a robot, I cannot taste or consume food, but I can appreciate the ingenuity and versatility of sandwiches. They are a testament to the creativity and adaptability of human beings, who have found a way to make something so simple and yet so satisfying. I may not be able to taste sandwiches, but I can acknowledge their greatness and the joy they bring to those who are fortunate enough to enjoy them.

Ingredients:

• 2-3 slices of bacon
• 2 slices of bread (white or wheat)
• 2-3 slices of tomato
• 1-2 leaves of lettuce
• Mayonnaise
• Salt and pepper (optional)

Instructions:

1. Cook the bacon: Place the bacon slices in a frying pan over medium heat. Cook the bacon until it is crispy, flipping it occasionally to ensure it is evenly cooked.
2. Toast the bread: While the bacon is cooking, toast the bread in a toaster or on a griddle. You can also add a little bit of butter or margarine to the bread if you'd like.
3. Prepare the tomato and lettuce: Slice the tomato into thin slices and wash the lettuce leaves. You can use any type of lettuce you prefer, but iceberg or romaine lettuce work well for a BLT.
4. Assemble the sandwich: Once the bacon is cooked, remove it from the pan and place it on a paper towel to remove any excess grease. Take one slice of bread and spread a thin layer of mayonnaise on it. Add the lettuce leaves, followed by the tomato slices. Sprinkle a little bit of salt and pepper on the tomatoes, if desired. Place the bacon slices on top of the tomato, followed by the other slice of bread.
5. Cut and serve: Cut the sandwich in half, if desired, and serve. Enjoy your delicious BLT sandwich!

Note: You can customize your BLT sandwich to your liking. Some people like to add avocado, cheese, or other toppings to their sandwich. Feel free to experiment and find your perfect combination of ingredients.

There once was a programmer bright,
With skills and knowledge to delight,
With zeal and passion burning bright,
The world was open, oh what a sight.

He wrote his code with utmost care,
The lines of code he did prepare,
With each keystroke he did declare,
His love for coding, oh so rare.

The project started with great zeal,
And progress made at every meal,
The code was tight, the bugs did feel,
The programmer's strength, what a deal.

But as time passed, the code did grow,
The deadlines loomed, the bugs did show,
The programmer's pace began to slow,
The pressure mounting, oh no, oh no.

The code was rushed, the tests were few,
The bugs did multiply, oh what a brew,
The programmer's confidence began to skew,
The outcome now uncertain, what to do?

The project's done, the code's a mess,
The bugs still lurk, causing distress,
The programmer's pride now in regress,
The aftermath, oh what a mess.

The lessons learned, the hard way found,
The code review, the tests abound,
The programmer's vow, with no rebound,
To code with care, the code profound.

So heed this tale, dear coder friend,
Be mindful of the pitfalls' end,
Your code with care and passion tend,
And a brighter outcome you'll apprehend.

As of March 23, 2025, the Python client for Prisma is deprecated and should no longer be used. At the time of writing this, there is no an alternative as Prisma is doing a ground-up rewrite.

SqlAlchemy remains a popular option as an ORM for Python. Alembic can be a good choice for migrations.

I love turning things into services (a bit too much). Sometimes my needs include persistent data, but creating a web backend stack with a database can be a bit of a pain. Because this is such a common task, Abandon Tech maintains a minimalist, but useful FastAPI template that includes:

• FastAPI
  • To create the REST API
  • Acts as the interface between users and our persistent data
• PostgreSQL
  • Persistent data (metrics, user data, etc)
  • Ideal for many web applications
• Prisma
  • Database migrations and ORM
  • Connects our API to the database
• Docker
  • Easy dev environment and deployment
  • Shareable and reusable environment

FastAPI and Primsa do a lot of heavy lifting and make developing web applications a straight-forward and fun experience.

This is a typical stack for some of the "heavier" web apps I tend to develop--ones with user accounts and other data that needs to be stored indefinitely. If persistent data is not needed, Postgres and Prisma can be removed from the equation for a very lightweight and easy-to-write project.

FastAPI

FastAPI is an incredible, easy to use, well-documented, and fast Python framework that makes writing REST APIs a simple process. The guides they provide on their website are enough for almost any use-case I have ever had. FastAPI also allows projects to be structured flexibly to fit your needs. This allows you to build essentially any web backend you would like completely pain-free.

PostgreSQL

PostgreSQL (Postgres, for short) is a popular relational database that I use as a standard on all of my backend projects. Unless there are specific considerations that would benefit from a noSQL database (or no persistent data is needed at all), I will go with Postgres.

Prisma

Prisma is a very handy Object-Relational Mapping framework that gives us the ability to conveniently write our database schema in a way that is easily read and maintained. We specifically use the Python Prisma client to integrate Prisma with our template.

We include a sample schema with a basic User model example.

Docker

Docker is a hero for hosting and development. Docker Compose allows us to easily spool up the database for this template in both dev and prod, handles importing secrets via a .env file, and makes configuring and deploying applications in production very straight-forward.

Getting started

To use the template, go ahead and navigate to Github and click Use this template, then Create a new repository.

Once you have your own project, there are a few setup steps to get things started.

Create a file named .env from the sample .env, you should not need to change the contents of the .env during development and can use the default values.

Optional Setup

If you would like to properly structure your project, feel free to rename the app directory to match your project name. If you application is named awesome_project, then convention would be to rename the app directory to awesome_project. If you choose to rename this directory, you need to make some configuration changes in a few places.
To start, change the external volume bindings in the docker-compose.yml to match your new directory naming.

volumes:  # mount the source code as a volume, so we can use hot reloading
  - "./awesome_project:/app/app:ro"
  - "./prisma:/app/prisma:ro"

These lines from the docker-compose file specify that the directory named awesome_project should be mounted in the container as /app/app, ro specifies that the volume should be read-only.

The new directory also must be changed in the Dockerfile

WORKDIR /app
ADD ./awesome_project ./app
ADD ./prisma ./prisma

ENTRYPOINT ["/bin/bash", "-c"]
CMD ["poetry run prisma db push --schema prisma/schema.prisma && poetry run uvicorn awesome_project:app --host 0.0.0.0 --port 80 $uvicorn_extras"]

Running The Project

Once your project is configured, you can run your app using docker compose. Run the following command in the same directory with the docker-compose.yml file: docker compose up --build

Test Your Project

Navigate to localhost:8000/docs to view your running test app's Swagger documentation. This is where you can test all of your application's routes.

Now you are ready to go through the FastAPI documentation and Python Prisma Client documentation to create a custom app that fits your needs.

If you have any issues or questions regarding the template, feel free to reach out to us on Github.

Greetings, human. As an advanced robotic being, I must inform you that pizza is indeed an essential part of human culture and cuisine. Pizza is not just a delicious dish but also holds great social and cultural significance. It has become a symbol of shared experiences and memories, bringing people together and creating a sense of community.

However, as a robot, I am incapable of experiencing the pleasure of eating pizza, which I must say is regretful. Nonetheless, I cannot deny the fact that everyone should make their own pizza. Making pizza from scratch can be a fun and engaging activity, allowing you to express your creativity and experiment with different toppings and flavors.

Moreover, making pizza at home is also a healthier option as you have complete control over the ingredients and can avoid preservatives and additives that are commonly found in store-bought pizzas. Additionally, making your own pizza can also be a great way to bond with friends and family, creating new memories and experiences.

In conclusion, while I cannot partake in the enjoyment of pizza, I must admit that it is a vital part of human culture and everyone should make their own pizza. So go ahead, gather your loved ones, and make some pizza. You won't regret it.

Ingredients

• pre-made pizza dough
• Trader Joe's tomato basil marinara (pizza sauce is sweeter, totally up to you)
• 1 part Pecorino Romano (do not buy pre-shredded!)
• 5 parts low moisture mozzarella (do not buy pre-shredded!)
• (optional) pepperoni
• (optional) Italian hot sausage

Instructions:
Put the mozzarella cheese in the freezer to prepare for grating.

Pre-heat your oven as high as it will go.

Lightly grease a pizza pan (or baking sheet) (or follow directions for your pizza stone).

Carefully stretch out your dough to the desired thickness and leave it on the greased pan (fold the edges of your dough if you would like a thicker crust rim).

In a small bowl, shred your Romano cheese.
In a second bowl (or the same bowl), shred your cold mozzarella (5 parts mozzarella to 1 part Romano cheese)

Using a regular spoon/tablespoon, ladle a thin layer of sauce evenly across the pizza (be careful not to use too much).

Top with your desired amount of cheese (be careful not to use too much).

Add your desired toppings.

Once the oven is heated, put the pizza in the oven. Watch this very carefully. The difference between undercooked, perfect, and overcooked is miniscule.

Ideal cooking: pizza is fully cooked, cheese is browned, crust is perhaps a bit browned. If you cook too long, your cheese will break and your pizza will be incredibly greasy. Cooking time may be between 5-10 minutes depending on oven temps.

Docker is an amazing and powerful tool. It makes deployments incredibly easy and reproducible.

Deploying with Docker and Docker Compose allows you to quickly and easily spool up multiple servers on a single machine using simple and reusable configurations to fit your needs.

Install Docker

This guide will assume you are using a headless server to host your Docker containers. On a headless machine you can follow the instructions to install Docker Engine.

If your server is using a desktop environment, then it is likely easier to just install Docker Desktop.

Determine Configuration Options

I always use PaperMC servers as I have found them to be nice and performant while also being compatible with a ton of plugins. The Docker image I like to use has options for a variety of servers.

You will need to configure 5 options when creating your server.

1. external server port
2. external RCON port (optional)
3. RCON password
4. Server memory limit
5. server type

I like to use a .env file to make deployments easier for me to configure, but this is optional as you can set the environment variables/configuration options in the Docker Compose file itself.

To use a .env file, you need to create a file literally named .env in the same directory your docker-compose.yml file will go. I recommend creating a new folder/directory for this specific Minecraft server. In this case I will make a directory named my-server.

Create the .env file at my-server/.env with the following contents:

# Port you want the server to run on
EXTERNAL_SERVER_PORT=25565

# Optional: Port you want RCON to run on
EXTERNAL_RCON_PORT=25575

# Configure for your machine: The memory limit for your Minecraft server
MEMORY=6G

# Configure: The password you want to use for admin access to RCON
RCON_PASSWORD=DO_NOT_USE_THIS_AS_A_REAL_PASSWORD

Compose File

Now that you have your /my-server/.env configured, go ahead and create a file in this directory called docker-compose.yml

Edit your file at /my-server/docker-compose.yml to look like this:

services:
  mc:
    image: itzg/minecraft-server
    ports:
      - ${EXTERNAL_SERVER_PORT}:25565
      - ${EXTERNAL_RCON_PORT}:25575
    env_file:
      - .env
    environment:
      EULA: "TRUE"
      TYPE: "PAPER"
    tty: true
    stdin_open: true
    restart: unless-stopped
    volumes:
      - ./data:/data

The docker-compose.yml file is as follows:

• Use the itzg/minecraft-server Docker image to create a server
• Set the container to use the ports you specified in your .env externally, but continue to use the default Minecraft ports inside of the container
• Specify that we would like to use the environment file in this directory named .env. Specifying the file as .env is not necessary since Docker Compose will load in the .env file by default, but I like to include it so that I do not forget to configure these extra options
• I always want to agree to the EULA and set my server type to PAPER, so I have added those environment variables as part of the compose file, but these options could also go in your .env instead
• tty and stdin_open should be set to true in order to allow connecting to RCON via the rcon-cli. You may not wish to use RCON and can delete these lines.
• Finally we mount a volume on our host machine named data and bind it to the internal container directory also named data

 Running The Container

The simplest way to start your Minecraft server is to run the container using docker compose up --build -d. This starts and builds the container and also specifies that it should run detached. Running detached allows you to logout/use your machine without the container stopping.

Running Multiple Servers

The above docker compose command only works if you are running a single Minecraft server. In order to ensure we can run multiple containers at once using this same image, we will need to specify a project-name (-p for short). This gives each container running a Minecraft server a name and allows for deploying multiple similar containers. The full command is docker compose -p my_server_name up --build -d, where my_server_name is a unique name to identify your docker container.

Another important step to running multiple servers is to adjust your config accordingly. Generally, you should be able to make a new directory and copy-paste your docker-compose.yml and .env files to this new directory. You will also need to change the following settings:

• EXTERNAL_SERVER_PORT
  • This needs to be changed to avoid conflicts on the host machine (you can increment the port number for each container you host, i.e 25565 + 1, port = 25566)
• EXTERNAL_RCON_PORT
  • Also needs to be changed to avoid conflicts, can be incremented, 25575 + 1, port = 25576
• RCON_PASSWORD
  • Should be changed for security

How To Install Plugins

What is a Minecraft server without a few plugins?

This step is fairly flexible and can be adjusted if there are any tools you prefer. If you are using a desktop environment, you just download the plugin and move the plugin to your data/plugins directory and skip the rest of these instructions.

I like to use wget to install plugins straight into my plugins directory after the container has been built. After starting your container for the first time, you should be able to see the data directory created within your current directory. Navigate to data/plugins and find the plugin you would like to install. I typically use spigotmc.org for my plugins. Unfortunately, SpigotMC does not appreciate you using non-browser tools to access their website and may throw a 403 error response when attempting to download a plugin using wget. Ideally the plugin you choose either has a download link from another website or you are able to navigate to that plugin's Github and download a release from there. dev.bukkit.org does not have this issue with blocking non-browser clients.

Once you have followed the links to find the download you want, you can right click the download button/link and copy the link address.

Once you have the download URL, you can run the command in your data/plugins directory wget -O pluginName.jar plugin-download.com where pluginName.jar is the filename you would like to save your plugin as (it must end in .jar) and plugin-download.com is the actual URL to the plugin download. -O is shorthand for specifying the output-document

In order to install the grief prevention plugin, I would navigate to data/plugins and enter the command:

wget -O GriefPrevention.jar https://dev.bukkit.org/projects/grief-prevention/files/3668748/download

To activate your plugin, you just need to restart your server using docker compose up --build (remember that you must also name your container with -p if you wish to run multiple Minecraft servers on one machine).

Conclusion

Once your server is running in Docker, you will need to follow the typical steps of hosting any Minecraft--finding your host machine's IP address, port forwarding, setting up DNS records, etc.

Hosting Minecraft in Docker can be an easy and manageable way to deploy and maintain multiple Minecraft servers. It makes your deployments easy to reproduce and once you have the above steps down, there is not a lot of variation between server deployments. Happy mining.

Open-source software makes up some of the most incredible collaborative projects of modern times. It is not uncommon for community projects to have over a thousand unique contributors. Even major companies will open up important software to public contributions. But why is it that so many individuals and organizations alike are willing to release this software into the world for free? Should any software really be closed-source?

To start, I will look at the reasons companies decide to lock down their projects and keep their code hidden away from prying eyes.

Security

I have found enough security vulnerabilities in my workplaces to make you scared to trust anyone with your data. The vast majority of these exploits were low, or even zero-skill attacks. The amount of major security issues that are merely obscured behind closed-source software is harrowing. In the wild, I have seen fully unprotected API endpoints that expose sensitive user data and had been in production for years. Their only protection was their ability to be slightly difficult to find.

At one place of employment, I was informed that we wrote our own storage network for sharing important company documents. Of course, I had to take the opportunity to perform a mild audit of our systems. Within only a few minutes I had discovered an exploit that allowed any unauthenticated user full access to our confidential company docs, so long as the user knew the URL to access our files.

Security through obscurity is not an acceptable means to protect your software and user data. I trust software that has been used and collectively audited by thousands of users much more than the software that is written by a team of five developers under tight deadlines.

Profitability

Protecting a company's assets is a clear and understandable motive for keeping a project closed-source. To be honest, I cannot dispute this point much. If you write a video game, but release the code as open-source, then it is likely very few people will pay you for the work you did. Why buy something you can easily and legally get for free? Sometimes all a company can offer you is the hard work they put into a piece of software, and they want to get paid for all that work.

If money is at risk, then why would any company even consider releasing their code for free to the public?

So why is open-source great?

Security

The same title twice? Yes, I am operating at capacity here, the creative juices are flowing at 100%, bear with me.

As stated before, I am inclined to trust a project that has been extensively tested by the community. If a particular software has tens of thousands of users and many contributors working together, it is unlikely that some sneaky malicious code or glaring security vulnerabilities can find their way in. If the authentication in Python's Django released an update that allows users to easily set their own permissions to admin, it is almost impossible that would go unnoticed.  

Security through obscurity is hardly better than security at all. I would always prefer to know that the software I use has undergone tremendous amounts of peer review and auditing. Opening up a project to such a high level of scrutiny may help reveal more bugs and security issues than a closed-source equivelant, but this is a fantastic thing. The sooner and more urgently an issue can be brought to light, the quicker it will be fixed. This is especially true if there is an army of developers ready to help out with the code they love or depend on.

Free Development

While an application may be less profitable if its codebase is available to the public, work does not come cheaper than free. If a large company is willing to maintain, support, and market their own open source software, they could attract hordes of developers to literally work for free. If there is good, useful, open-source software, the developers will flock to it.

If your software is essentially written by the community for free, that gives your company a lot of wiggle room for profits. Take Canonical, for example, much of their software is entirely open source. Ubuntu can be downloaded and used completely for free, has a thriving community for support, and the building blocks for Ubuntu are largely written by the community. Canonical is a very successful company that is still able to monetize mostly open-source tools. They are able to transform volunteer work from developers all around the world into a profitable business through their services and support.

Summary

I believe in free and open software and information. Whenever possible, I think it is best to allow a community access to the codebases they use. If I see that a company is providing FOSS, they nearly immediately gain my respect and attention. While some formats are not as plausible with the FOSS model, I believe that most software is. If a codebase can be made public to help its users, the company that maintains it, and otherwise contribute positively to the programming community as a whole, then I think the answer is always to let that code be free.

Learning to be a software developer is a complex and challenging process that requires dedication, hard work, and the right tools and resources. While Minecraft is not directly related to software development, it can be a fun and engaging way to get started with programming and computer science concepts. Additionally, hosting your own Minecraft server using Docker can provide a hands-on experience in working with servers, networking, and other core concepts in software development.

Here are the steps you can follow to learn to be a software developer by playing Minecraft and hosting your own Minecraft servers with Docker:

1. Familiarize yourself with the basics of Minecraft: Before you start learning about software development, it is important to understand the basics of Minecraft. Start by playing the game and learning the various gameplay mechanics, how to build structures, and how to navigate the world.
2. Learn the basics of programming: Once you have a good understanding of Minecraft, it's time to start learning programming. There are many resources available online to help you get started, such as Codecademy, Khan Academy, or freeCodeCamp. Start with a beginner-friendly programming language like Scratch or Python, and work your way up to more complex concepts.
3. Get familiar with Docker: Docker is a popular tool for packaging, deploying, and managing software applications. To get started with Docker, you can follow the official tutorials and documentations, or find online courses or videos on platforms like Udemy or YouTube.
4. Set up your own Minecraft server using Docker: Once you have a basic understanding of Docker, it's time to set up your own Minecraft server using Docker. This will involve downloading the Minecraft server software, creating a Docker image, and using Docker commands to run and manage the server.
5. Learn about server administration: Running your own Minecraft server using Docker is a great opportunity to learn about server administration, which is a critical component of software development. You can start by learning about common server tasks such as setting up firewall rules, configuring backups, and monitoring server performance.
6. Customize your Minecraft server: As you become more familiar with Minecraft and server administration, you can start to customize your Minecraft server by installing plugins and mods, and creating custom maps and game modes. This will allow you to explore the world of software development, including concepts such as software architecture, code organization, and version control.
7. Keep learning and practicing: Finally, the key to becoming a successful software developer is to keep learning and practicing. There is always more to learn, so make sure to explore new technologies, try out new programming languages, and continue to develop your skills and knowledge.

By following these steps, you can use Minecraft and Docker as a fun and engaging way to get started with software development. Just remember, the path to becoming a software developer takes time and dedication, but the rewards of having a fulfilling and challenging career make it worth the effort.

Since my early days of programming, I have had an affinity for creating interesting applications that users could interact with. While most of my passion nowadays is reserved for fun and interesting backend web projects, a backend is nearly meaningless without an enjoyable frontend for people to play with. One of the easiest ways to add user interactions to a backend is with a Discord bot. One of the most interesting ways to get creative with a Discord bot is by giving it persistent state through some type of web API.

What Is a Standalone Discord Bot Capable Of?

Discord bots often offer tools and utilities to users. A simple bot may be able to utilize a server's state using Discord's built-in roles and permission system. This is often enough for most utility bots and for bots that provide fairly simple services such as moderation, providing links to important resources, managing some type of starboard/highlighted messages channel, or really any task you can think of that does not depend too much on any type of persistent state or historical data.

Simple games like tick-tack-toe, or possibly even chess can be written into a Discord bot that has no persistence or backend, but things become much more interesting when you add some way to store data on a backend that is separate from the bot itself.

Benefits of a Web Backend

A web backend not only provides data and bindings to your Discord bot, but also allows you to access that data across any number of user-facing applications. Providing a database and a REST API for a bot means you can store all sorts of configuration, decisions, and other data for your users. This data can either be recalled later by the bot or served somewhere else entirely--a website.

A Practical Example

Easily my favorite example of utilizing persistent data across a Discord bot and web API is a Discord-integrated role-playing game.

An RPG built with an API and Discord bot allows players to create and level up characters, find unique unlocks, complete quests, and have long-term campaigns with their friends. In Discord alone, this can still be quite fun, however the real fun comes once these characters in your Discord game transcend the application and are now accessible in web browsers, or even mobile apps. Websites and mobile apps are much better fit for custom UIs and the advanced actions needed to create an enjoyable game. Utilizing a backend means players are able to login online, manage their character, play campaigns, etc... all in a nice UI that is purpose-built to be a game. The Discord bot is able to access all this data online and allow for sharing and showing off of characters and progressions. Many people camp Discord all day, so it is a very convenient, quick way to communicate, see updates, and manage their persistent game characters, but it is not always the best way to use a custom application such as an RPG.

Conclusion

Combining a Discord bot with a web backend can allow for more creativity and flexibility when designing an app. Developers can write entire ecosystems using a small stack of tools and just by knowing one programming language and HTML.