Building a Multiplayer Backend: OAuth Authentication [External]

Unknown — Tue, 22 Oct 2024 00:00:00 +0000

I authored a technical blog post on Authentication for Catena Tools.

Check it out here</a>.

Building a Multiplayer Backend: Authentication [External]

Unknown — Thu, 15 Aug 2024 00:00:00 +0000

I co-authored a blog post on Authentication for Catena Tools.

Check it out here</a>.

Catena Tools, A Multiplayer Engine for Game Developers. [External]

Unknown — Fri, 12 Jul 2024 00:00:00 +0000

I recently wrote a blog post for Catena Tools, a new toolkit we are building out at Wolfjaw Studios to help game developers bring their games to new audiences through live services.

Check it out here</a>.

Simple Security for Personal Projects

Unknown — Tue, 18 Jun 2024 00:00:00 +0000

I am occasionally asked to build scripts for people (or I offer to do it just for fun). Usually these scripts tackle simple, menial things like geocoding addresses into latitude longitude points to put pins on a map for something like the Shuttle Tracker</a>, or a simple transaction ledger for budgeting. These scripts are almost always driven by a flask app to provide a basic UI for my less technically savvy friends and family, sending a URL that just works is much easier than any other method of distribution.

Sometimes these data are sensitive, or calls an API that will cost me money, and I get uncomfortable publishing it to the general internet without some type of security. Despite my searching, I have not found a simple way to do this type of blocking.

In response, I decided to create my own tailor-made solution. 

Introducing auth-proxy-gate</a> (name pending). This project aims to be a simple OAuth login protected proxy, if you are logged in, your requests will be proxied to whatever service we are protecting, otherwise you get a 401.

Tech</h3>
I wanted to be able to write this in an afternoon, so I picked simple tech I'm familiar with:

Go</li>
Boltdb</a></li>
Templ</a></li> </ul>
I have also limited the initial implementation to just Google OAuth Providers. 
How it works</h3>
First set up a Google OAuth Application</a>. I have requested pretty minimal permissions since I really only need an email to verify. 
In my case I set up two redirect urls these can be set on the credentials tab of the oauth consent screen configuration:
`http://localhost:8081/api/v1/auth/callback?provider=google https://s.lyon.lol/api/v1/auth/callback?provider=google </code></pre> After which grab your Client ID and Client Secret. We can then run the application like this:`templ generate; go build . ./auth-proxy-gate --secret "GOOGLE SECRET" \ --redirect "http://localhost:8081" \ --clientid "GOOGLE_CLIENT_ID" \ --secretKey "replace_me_with_a_secret" \ --proxy "https://www.google.com" \ --allowList "[email protected]" </code></pre> This is super simple, but effective. I will run this on the VPS where the app is running. My app will run listening on localhost, and the proxy will listen on whatever domain I chose to set up, for example https://geocode.lyonsoftworks.com</a>. I will also add any authorized users to the allow-list. My next improvements will be to switch to a sqlite database, add a config file, and then add additional oauth providers.

Productively Unproductive Unknown — Fri, 19 May 2023 00:00:00 +0000 I'm still here. I was close to burning myself out. After taking on a new role at work, handling a move, familial obligations and more, I found my battery to be completely drained. Some of my other goals (like this blog</a>) took a backseat. In the past I would have felt guilty, like I'd let myself down. I have often found it difficult to pare back what I am working on to a sustainable level. I often was drawn in by the productivity posts on Linkedin or Hacker News. They would often peddle the notion that you should grind through the challenge in order to come out on top. I still feel there is a time and a place for this attitude, but you must acknowledge the cost that comes with it. One of my goals with this blog was to work on it in a sustainable way, so that I could keep up the habit. Until recently I would've forced myself to grind through writing posts along with all of the other pet projects I wanted to do in an effort to make myself feel productive. Inevitably this would lead to me feeling burned out and I eventually would stop doing all of it. Taking a beat and scaling back has worked wonders. I've had more fun at work than ever recently and I feel like there is more space for me to get done the things I really care about. Being productively unproductive when I can has really given me the space to focus on the things I want to get better at. I am feeling more focused and productive than I have in a while, making my goals feel much more achievable. Contributing to a Collaborative Environment Unknown — Wed, 29 Mar 2023 00:00:00 +0000 I have recently been reading "Think Again" by Adam Grant. One of the topics he talks about is Relationship Conflict (more interpersonal conflict, "I don't like this person") vs. Task Conflict (conflict about solving the problem at hand). Focus your team's conflicts on the tasks at hand vs. interpersonal conflicts and fundamental identity-based disagreements. This idea resonated with me, and I recognized this concept immediately as a principle I developed in my work without realizing it. It's a skill that I hope to cultivate more deliberately going forward. Focusing on Task Conflict and avoiding Relationship Conflict is something I can admit I've performed poorly at in the past. I have found that sometimes it's hard to detach yourself from your ideas, making it easy to fall into the trap of being personally attached to your idea, resulting in a worse conflict. I can vividly remember a time in college while working on the Shuttle Tracker</a>, when I found myself getting worked up over a code review. I was taking what was constructive criticism personally. Admittedly, I was new to the language and web development then, and I knew my code was not up to par. Looking back on this, I cringe at my behavior. I was in a Relationship Conflict mode-my identity was being attacked when I should have been in Task Conflict mode. Once I learned to let go of my attachment to specific details, I could take an analytical look at my solution and start to learn how to improve. Once I let go, I could utilize my colleagues' reviews to learn different perspectives, ideas, and strategies for developing software. I eventually came to realize often, in software, There is no "right way," and learning how other people solve a specific problem has given me an appreciation for the focus and drive that others put into their work, even if they don't do things the way I would have. As my career and open-source contributions developed, I learned to detach from the specific implementation and ideas while focusing on the overarching task. After I learned to do this, I made significant strides in my abilities as a software engineer and learned and adapted to new roles. Now I try to keep the following in mind: Strive for a solution (hopefully the best solution). Not necessarily your solution. Look at all solutions as objectively as possible.</li> Teams can only effectively work together when they can discuss tasks with each other and disagree on implementation. </li> Hurt feelings have no place in software development. </li> Striking the right balance here is crucial.</li> </ul> Note: very real interpersonal conflict issues can crop up, but here we are focusing solely on engineering problems. Cultivating a task-based culture is crucial to working collaboratively and building an effective team culture. This Task Conflict style only works if everyone buys in. I have tried to bring this attitude to the table when joining a new team as an IC and found it can be infectious. I have done this through very explicit communication about the fact that I am focusing on the task, not the implementation. I do this on teams that I'm on by coming into every conversation about a code review and framing my suggestions as us working together to find the best solution. This works best for me if I can incorporate people's solutions into my suggestions. Highlight the areas where they did well and frame suggestions as questions to build a better product. For example: "This solution is great; I like how you structured the data here; what do you think about leveraging that data structure more cleanly with a map-reduce instead of a for loop." By explicitly communicating your common goal repeatedly and often, you can direct focus toward that goal. It helps keep the team focused on the bigger picture during these discussions. Going forward, I plan to define better how to maintain this team culture and keep everyone focused on a common goal. Meetings Arent All Bad* Unknown — Thu, 16 Mar 2023 00:00:00 +0000 *But they definitely can be The sentiment "I'm an engineer, and meetings just hamper my productivity" is pervasive. Many engineers you talk to (including myself) will likely say something similar to this when prompted on their opinions about meetings. My opinion on this has changed, but what's critical is to make sure your meetings are effective. You need to focus on three major facets when deciding if you need to have that meeting or if it's wasting everyone's time. They are scheduling, content, and takeaways... Scheduling: Who? Where? and When? are the most important questions to ask here. Keep the invite list small but allow others to join if they want additional context. I have found that often if people aren't required to be there, they will sometimes join because they want to learn or feel they have something to contribute. Your mileage may vary depending on the team's culture, so find what works for you. Nowadays, the "where" is usually online, but I often enjoy the in-person brainstorming or explanation meeting when wrapping my head around more complex topics. In-person, meetings are also less exhausting to me than video calls, but this also varies from person to person. When? I have acted the least strategically in this area, but I want to get more deliberate about it. My hunch is that timing doesn't matter as much, but avoid lunch breaks, be conscious of time zones, and respect people's focus time. The most important thing here is to keep the meetings as short as possible without being pointless. If you dive deeply into specific topics, most meetings only need a full hour. Content: "What are we actually talking about?" Every meeting should have an agenda. This is rarely a shared agenda, but that is a valuable tool I want to introduce into my arsenal. I usually have a list of talking points on a piece of paper on my desk that keeps me focused. For example, suppose I have a meeting where I am trying to glean more information about an existing metrics service owned by another team. In that case, I might have the following on my agenda (granted, this is a contrived example): Describe My assumptions about the service and my needs</li> Are there any examples of using this service in the wild?</li> What are any pitfalls and gotchas about the service?</li> Will I be able to use the service as I'm expecting to?</li> Recap Action Items</li> </ul> I will work through the list, noting any notes and crossing off items as they are covered. If you cover everything on your list, end the meeting. Try to spin up side conversations only if the other meeting members are receptive or are pushing for it and everyone has time. This keeps you away from having meetings that drag on where most people aren't engaged. Doing this, it's very common for me to have a meeting that could've easily dragged on to an hour and be done in 30 minutes or less. Takeaways: If you can't come up with a few takeaways or "action items" for both parties in the meeting, you probably shouldn't have had the meeting in the first place. Take a moment at the end of every meeting to deliberately recap what you talked about and the action items. Usually, this will include a summary document, as well as a note to create Jira tickets or change a specific feature. For example: Create a ticket to modify service X to batch writes to the metrics service.</li> Update documentation of service X to mention the new dependencies on the metrics service.</li> Schedule a follow-up in 2 weeks to discuss the integration.</li> </ul> This is the strategy I am trying to follow now, but I always want to take a look and revise my approach. If you agree or disagree with anything here, don't hesitate to get in touch with me. I'm always open to new ideas. What Makes an Effective Team Lead Unknown — Tue, 07 Mar 2023 00:00:00 +0000 I (re)started at Wolfjaw Studios in August 2022 after a stint as a Software Engineer at Bloomberg. Tasked with leading a team of 2 engineers I was excited to dip my toes into Engineering Management as this had been a goal of mine for some time. Transitioning into this role has been an ongoing learning experience as it differs somewhat from my experience as an Individual Contributor. Writing on this blog keeps me accountable and straightens out my thoughts. Disclaimer: every situation is different so your mileage may vary. I will do my best to document this journey here. Since my first day as a Team Lead, one of my driving questions has been: "What does a good engineering team lead actually do?". I'd imagine many people who are just stepping into this role have the same question. I have found this to be a surprisingly difficult question to answer, and I probably don't have a perfect answer. Given this I try to keep the following at the forefront of my mind in an effort to achieve the goal of being a "good" team lead. Provide consistent communication and feedback to your direct reports.</li> Highlight and Broadcast direct reports (and team's) achievements and blockers.</li> Communicate the progress of your team to stakeholders.</li> Give feedback and make contributions to the technical product of your team (review and write some code).</li> </ul> There is much more that goes into it but keeping the above in mind with everything you do will provide a good guiding light to keep you focused on improving yourself and your team. Note things like "write jira tickets" and "prescribe tasks to engineers" are missing. These are something you will likely need to do at points however it is outside the scope of this post. I do feel it's important to highlight that those are collaborative processes and not something you should be dictating, (although one person doing 80% of the work creating tickets before that process goes a long way). Provide consistent communication and feedback to your direct reports</h2> One of the most important things a team lead does, if the people that report to you don't feel seen or communicated with, things can fall apart really quickly. This point is deceptively simple and is one of the biggest challenges to being a team lead in my opinion. Achieving this is challenging. Without going into specific cadences, my strategy is as follows Go into every meeting with a list of topics to cover, write them down, keep on track and take notes. Write down everything, even the most simple things, you will forget.</li> Always deliver feedback as constructively as possible, there is generally no reason to negatively refer to someone's work, rather highlight what can be improved by framing it as a constructive process towards building something great.</li> Always slow down when addressing your responsibilities. If you are context switching frequently or working on some code task, put it down and prioritize this. It's better to keep communication consistent and if you are overwhelmed or burned out it's likely noticeable by your team and will rub off on them before long.</li> </ul> Highlight and Broadcast direct reports (and team's) achievements and blockers.</h2> Another hugely important facet of leading a team, this point is crucial. In my opinion it's always worth it to highlight your team member's achievements over your own and over the teams. Be as humble as possible for yourself and make sure they are getting the credit they deserve. Their achievements will speak for you. Reflect your team's successes up the ladder, highlighting their accomplishments to your manager makes you look good, and gives your team the credit they deserve. Keep in mind the culture of the company when communicating outside of your team, a big part of your Job is navigating the org structure for the benefit of your team. </li> Immediately raise blockers and try your best to remove them. No one likes to be blocked and if it reaches you it's probably something you need to help handle. Removing them may be as simple as making yourself available for a quick Q/A with the engineer to rubber duck it out or provide a new perspective.</li> </ul> Communicate the progress of your team to stakeholders.</h2> This is simpler but critically important. Take in the information you gather from your reports and distill it into a digestible format (either a document, email or meeting). This goes hand in hand with highlighting accomplishments but also keeps stakeholders in the loop on what you are doing. Taking clear and concise notes throughout the week is a very good way to do this and they can be used for writing this document. Admittedly I am occasionally worse in this department than I'd like but I get around it by looking at the artifacts (Jira tickets, Code Reviews, commits, 1:1s) that are produced through the week. Give feedback and make contributions to the technical product of your team (review and write some code).</h2> Last but not least this is probably closest to what you did as an IC, but you are doing it at a slower pace as it is no longer your only priority. Accepting this decrease in velocity is crucial and something that is very difficult to reconcile as you are likely used to seeing a concrete output (code & documentation) every week. Trust me, you are still delivering value and providing feedback through design discussions, setting priorities, and the communication you are providing. The work you are doing on the project should be distributed and intentional to give you context that can be used to provide feedback in technical discussions. These are just four points that come to mind as I'm on this journey. I intend to write a few more articles in this series on some other lessons learned and goals I wish to achieve on my team to serve as a repo for myself and others to learn from and iterate on. I also want to write about:</h3> Conducting effective meetings</li> The importance of writing things down</li> Helping your team grow and setting a culture</li> Jira-ing when and how</li> </ul> If you want to hear about any of these in particular first or just want to chat shoot me an email: [email protected]</code>. Infrastrucure Time Unknown — Tue, 14 Feb 2023 00:00:00 +0000 Continuing the meta blog-about-blog trend I will go into how I run the infrastructure used to host this site and other small things I'm working on. When working on personal projects I usually don't want to think too hard about deployments while still not being limited by my infrastructure. As such, this site and most everything else I put online is on a $4 DigitalOcean VPS with Docker and Dokku</a> installed. Shout out to @sidney</a> for introducing me to it years ago. Dokku is a great go-to self-hosted PaaS for simple projects. It works nicely with Docker and Buildpacks to provide a simple git push</code> deployment mechanism with zero downtime deployments. Deploying an app with SSL is as simple as running: # On the VPS $ dokku apps:create [name] $ dokku domains:set [name] name.lyon.lol $ dokku letsencrypt:auto-renew [name] # Locally $ git remote add dokku [email protected]:[name] $ git push origin main:master </code></pre> After this, my new app will be hosted at https://name.lyon.lol</code>. If I want to deploy a new version I simply git push again. To facilitate this I've set up a few DNS records, namely a wildcard A record for all subdomains on lyon.lol Host IP Type TTL @ 68.183.102.12 A 5m * 68.183.102.12 A 5m </code></pre> This site is a great example of how this infrastructure is very powerful and quick to iterate with. The source is located on github</a>. Content updates are just a git push</code> away. I write the content, compile it with Zola</a> and commit the whole output to the repo, at which point I push to dokku. For example: docker run -u "$(id -u):$(id -g)" -v $PWD:/app --workdir /app -p 8080:8080 -p 1024:1024 ghcr.io/getzola/zola:v0.16.0 build git add . git commit -m "Update content" git push dokku master </code></pre> This keeps it simple and low overhead to maintain. Another Software Engineer With a Blog Unknown — Sun, 12 Feb 2023 00:00:00 +0000 I intend to start casually blogging here to keep me on track with my goals and to satiate people's desire to add blogs to their RSS readers. I plan to very casually write about the projects I am working on or just write my thoughts in a more long-form format to improve my writing and communication skills. This is moving very slowly, but it is moving. To kick things off... I am making an effort to contribute more to the Projects I use regularly, and just putting the crappy prototypes out there. I often find I'm limiting myself by thinking that I shouldn't bother doing something because no one will use it or that it's already been done better than I can. I have found this has hindered my progress or willingness to work on things I want to in multiple ways. Most Recently... Proto</a> - A WIP command line tool to manage protobufs and eventually deploy them to a PaaS platform.</li> GRPC-Kotlin Bazel Build Windows</a> - An upstream contribution to support building GRPC-Kotlin on windows using Bazel.</li> </ul> I'm in between Github Profiles at the moment so my contributions are split between @jlyon12345</a> and @jlyon1</a>.

Building a Multiplayer Backend: OAuth Authentication [External]

Building a Multiplayer Backend: Authentication [External]

Catena Tools, A Multiplayer Engine for Game Developers. [External]

Simple Security for Personal Projects

Tech</h3> I wanted to be able to write this in an afternoon, so I picked simple tech I'm familiar with:</p> Go</li>

Productively Unproductive

Contributing to a Collaborative Environment

Meetings Arent All Bad*

What Makes an Effective Team Lead

Infrastrucure Time

Another Software Engineer With a Blog