All good things must come to an end, am I right? And with Stack Overflow's second round of layoffs this past week, I figured I'd finally write something. My tenure at Stack Overflow ended prematurely. Unfortunately, I was affected by its May 2023 layoff, and truth be told, I was heartbroken. No workplace is ever perfect, but I loved working at Stack Overflow. I was proud of the impact I was making, an impact on the lives of millions of developers around the world. To say I was blindsided by the layoff is an understatement.

It’s been radio silence on my site for almost two years. Since my last post, I got hired by one of my dream companies: Stack Overflow. I have always enjoyed building tools to make the developer experience easier for everyone, so it should be no surprise that working at Stack Overflow has always been a dream of mine. I have actually applied to Stack Overflow twice in my life; the first time, I didn’t even make it to the phone screening. The second time, I got hired. If at first you don’t succeed, give up. Or something like that, right?

I have never worked retail in my life and for that, I am very grateful. Trust me, with my sarcasm and attitude, you do not want me working in retail. If you work in retail, you have my full respect; I could never do what you do. Working on a college campus, something I see very often is that employees forget who we're working for and who our customers are.

This year had a really rough start and had a bumpy ride everywhere in between due to personal problems. BUT! It’s okay, there’s a lot of other stuff that happened this year that made things interesting and enjoyable for me. Well, I’m sure a lot more stuff happened but these are the only things I remember or am willing to share.

When I was much younger, I'd get excited about receiving messages from recruiters on LinkedIn. I thought to myself that I was actually in demand. The ignorance of youth, am I right? Truthfully, I'm not popular enough or patient enough to get anything out of LinkedIn; so to me, it's mostly a joke and I treat it as such.

For roughly 9 months, I had been working on the new website for the BZFlag project with the help of some awesome contributors; the planning and early work started in July 2018 but full speed development didn't really start until November 2018. On April 1st, 2019, the site was made live! I love a good and elaborate April Fools' joke, so what better way of participating this year than by launching a completely redesigned website for a project close to my heart? I mean, I also finally released my AOLer plug-in this year to troll but that's beside the point.

A month ago, I went on a rant about showing your contributors some love and while I stand by that sentiment, I've learned something new in the past month: the importance of a community manager/advocate. Or just community engagement, in general.

I've been lurking around the open source community for about a decade now. I say lurking because I feel like I lurk more than I actually contribute. Though, judging by the little squares on my GitHub profile, I am by definition: fairly active. My favorite time of the year is Hacktoberfest because I do my best to find a community I don't typically hang around and see if I can contribute. Sure, I could always go to those "we'll accept any PR during Hacktoberfest" repositories, but where's the fun in that?

I've been wanting to write something on my blog because I haven't written anything since May and for me, that's a long time. So I decided I'd write about why I decided to create stakx.

Despite all my efforts for developing the next major version of stakx, I come bearing gifts for the Jekyll community. When building websites with long pages, it has become the standard to include a table of contents that link to headings. Up until jekyll-toc, the only way to achieve that was through a Jekyll plugin or JavaScript. Now, the current solution for adding clickable links next to headings is to use JavaScript. Let's change that.

Over a year ago, I wrote a table of contents generator for Jekyll websites, on a whim, using nothing but Liquid. There was a need for being able to generate table of contents for pages from a layout without relying on a plugin or JavaScript and without having to include {:toc} in every single markdown file. I never had a need for this feature, it was one of Docker's employees who was asking if a solution existed. I was intrigued by the problem and so I wrote my solution on a whim as a proof of concept; I really just wanted to know if I could achieve the same thing by using just Liquid.

Happy new year! ...in March. It's a new year and I come bearing gifts as your resident BZFlag Santa Claus from beautiful Southern California: the place with a Starbucks in every corner and misspelled names on coffee cups in every trashcan. I'm here to bring you a surprise new chapter for BZFlag Plug-ins for Dummies covering world weapons, custom flags, and the latest improvements to the world weapon API.

It's been a busy semester, I just completed my second to last semester of my college career. The end of 2017 is approaching and what I have accomplished in the past year? Looking back, I don't really feel like I accomplished anything significant but here are some highlights.

It only took until I reached my final year in college to finally find a class I found challenging and actually learned from (excluding GIS classes). I've always been fascinated by cryptography and have always wanted to learn but never found the time to do so on my own. Until I took this class, I had no knowledge of how crytography actually worked. I found this assignment to be incredibly fun because it was challenging for me.

I never expected the BZFlag Plug-ins for Dummies series to get much traffic due to its nature; a very small community, few to no developers, etc. With regards to the current status of the project, I feel that I have covered enough of the API and plug-in writing to be helpful to new developers. For this reason, I'll be putting this series on hold for a while; by doing so, it'll allow me to focus on other projects that require my attention.

A common task to achieve in plug-ins is to have a countdown or time delayed functionality. As an example, a plug-in introducing a custom game mode such as Last Tank Standing will need a countdown for the last 5 seconds of each round and will need to kick a new player at a set interval. This is C++ so there's no magic setTimeout() function that we can use and there's no API function; instead we'll have to make use of the bz_eTickEvent and time_t objects.

The next topic I'd like to cover regarding plug-in writing is how to create custom map objects. Have you ever played the King of the Hill (KOTH), All Hands on Deck (AHOD), or Jumping Skills? In this chapter we'll be building a plug-in that knows when players enter a specified zone to control the hill, capture the flag, or save at a check point. Prior to May 2015, you would have to write all of the logic and math yourself if you wanted to support custom zones. Thanks to the bz_CustomZoneObject class, courtesy of yours truly, all of the math and logic has been moved to the API and requires no effort on your part.

In honor of my latest commit, of adding a new parameter to bz_addURLJob(), this chapter will be covering making URL requests and handling the return data. Why would a plug-in need to make URL calls? Well, a plug-in may need to communicate with an API but don't expect instant results, there'll be a small delay. A common plug-in that makes use of API calls would be my own League Overseer, which communicates with the league's API to report matches automatically. There are two different ways of doing URL jobs in a plug-in.

If you've been following my BZFlag Plug-ins for Dummies series, you may have noticed the radio silence for the past two weeks. Don't worry, the project is still alive and scheduled to continue. The past two weeks have just been incredibly busy for me with work, summer school, and projects so I haven't had time to write any new chapters; heck even my GitHub contributions graph has been quiet. I've got a new chapter for that series planned for July 29, so don't worry you'll be able to continue writing plug-ins.

After last week's pretty long chapter, this'll be shorter in comparison. So far we've written simple plug-ins where the behavior we define is all the behavior the plug-in gets. But what if we want to allow the server owners or map makers to control the behavior of the plug-ins. This can be done in several ways but in this chapter, we'll be covering using configuration files.

It's the 4th of July and you know what that means for me, right? It means I do my best to avoid spending time with friends and extended family. Today, I spent time improving my docs.allejo.io domain, which is used for hosting the documentation for my projects/libraries.

For those of you who think I write these chapters ahead of time, you're wrong.

We've both made it to chapter 3; we should be proud. You, because you've made it this far. Me, because I've been able to write this on a weekly basis without missing a day thus far. Today, we'll be talking about slash commands. Don't worry, like always, we'll be going step by step.

I told you it wouldn't take another 2 years until the next post. We're back and in this chapter we'll be discussing player records and modification API events.

Back in 2015, I said I'd write this series. Well, here it is. Better late than never. Right? In this first chapter, I'll be going over the structure of a plug-in while building our first sample plug-in.

So Fridays are typically my days off from work and school; they're awesome and I'm always looking forward to them. However, this morning I woke up to a not so awesome Friday. Everything on my computer had crapped out.

So on Tuesday, I was on #jekyll like any other day and a user by the name of misty came in asking about using {:toc} in a Jekyll layout instead of a markdown file. It makes sense, on large websites with a lot of markdown files, you don't want to make sure you include {:toc} in each document and if you do manage that, you're restricted with where it will be rendered—alongside the content. There's another problem with {:toc}, it won't work separately from the markdown file because Jekyll doesn't give Liquid the raw markdown so you can't prepend {:toc} and markdownify the combination nor can you combine {:toc} with HTML. I'm well aware that there are several Jekyll plugins out there and JavaScript solutions to this problem but there are two problems with each:

Welcome to a new year. Only 15 days late but, whatever. Looking back at 2016, it was a pretty awesome year for me with regards to all of the projects I participated in. Here are some of my projects and accomplishments for 2016:

I'm often curious to see other people's personal websites and am disappointed when I notice that their websites are dated or unmaintained. The pot calling the kettle black, huh? My personal website has become the most neglected project I maintain but I plan on changing that. I intend on writing more often, hence this post.

A while back, I mentioned that I was working on my own static website generator and that I was going to post about it later. For the past 6 months, I've been working on Stakx on and off and I've finally reached a point where I can easily and efficiently build a website with Stakx.

I've been wanting to write about the Santa Monica Youth Tech Program (YTP) for quite some time and what my experience was like as a participant in 2012 and now as a staff member. After searching for posts regarding YTP, all I could find were articles written by program partners and guest presenters.

I have spring break coming up in about 2 weeks; while that would typically have me excited, I'm too distracted and drained for any unnecessary emotions. I've been in a rather odd slump the past few months with where I'm at.

For those of you who don't know me, my sense of humor is quite cynical, sarcastic, and satirical at times. The number one thing I absolutely loathe when scrolling through my newsfeed—whether it be Facebook, LinkedIn, or Twitter—is seeing clickbait. Ok, on Facebook or Twitter it's to be expected but on LinkedIn also? These are three titles of articles I saw on LinkedIn before I quit my browser:

Since I've started taking more computer related classes and have met some pretty cool people, the most common question I keep getting is: "how did you learn all of this?" As a friend pointed out a few days ago, I've been fooling around with code and technology for almost a decade now; I'm not entirely satisfied with the progress I've made, since I wish I had time to learn so much more.

I've recently been working with joining Wufoo and DaPulse together happily in marriage and have made solid progress. However, one problem I encountered was the lack of consistency between Wufoo's POST data and API responses for their date fields. For example, I would get dates formatted as YYYYMMDD from the POST data received from their webhooks but I'd get YYYY-MM-DD whenever I sent an API request.

At one of my jobs, we have recently moved from Asana to DaPulse for task management and collaboration. I'm not part of either's marketing team nor am I sponsored by either of them so I won't advocate for either or say one's better than the other. We also use Wufoo for forms and we used to use Zapier to automatically create entries in Asana and assign them to my coworkers and myself based on the entries. At the time of writing this, Zapier falls unbelievably short with their support of DaPulse to the point where it's actually quite embarrassing and they shouldn't even be offering it in the first place.

Throughout my time with BZFlag, I have written a large amount of plug-ins. Nowadays, I have adopted the API as my child. By this, I mean that I have started to contribute a lot to the API and documenting it for others to use. I have also shaped certain parts of it to my liking mainly so it benefits my plug-ins.

It's been an eternity since I launched my Jekyll based website (this one) but up until now, I hadn't done much with it nor had I done much with Jekyll. It wasn't until recently where at both of my jobs, I started using Jekyll a lot more and was able to experiment and discover some better practices. I'm no Jekyll expert but I finally feel comfortable enough with Jekyll and Liquid to work with it efficiently to get a product out. Better yet, I am comfortable enough to be able to assist on #jekyll; that's an IRC channel for you youngins who only know Slack.

I'm very proud to announce the birth of a new project and its first release! It's called PhpSoda and it's not for the type of soda that you drink (even though I love soda), it's actually an acronym for the Socrata Open Data API. What's Socrata? Well they're a pretty neat company that hosts a lot of open data for governments. They host open data for the US Federal Government and for local governments like the City of Santa Monica, where I work at the time of writing this.

A really long time ago I posted that I was an underachiever and sorry to disappoint but I still am. Well... Sorta. Maybe. Mostly.

Well I never thought the day would come where I'd move away from WordPress for my personal website. I've been using WordPress since 2009 and it has changed a lot since I started using it. Don't get me wrong, I still love WordPress and I do plan on contributing to it, but I want to give Jekyll a try. The main thing that drew me to Jekyll is the use of markdown and YAML for everything and I definitely love both of those things; using this combination definitely beats writing a WordPress plugin to handle custom data. I will admit, making a theme for Jekyll is far simpler especially since I've started working with Symfony which uses Twig; Liquid is very similar to Twig so it's incredibily simple for me to get used to. Adding real time information to Jekyll is a pain since there is no server side processing; everything is static (no shit, sherlock). By using JavaScript and APIs, I can get by with having some dynamic content; although for the 1% of people who don't have JavaScript enabled, you just can't fully experience my awesome site.