Blog

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.

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.

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.

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.