When people hear the phrase “profanity filtering” their minds typically go directly to the gaming industry. Certainly gaming has a very strong need for filtering as communication between players in chat and forums is a key component of how companies can build and grow an online community. Many of our early clients came from the gaming industry.
The Gather API enables websites, apps (desktop/smartphone), anything really, to fully interact with user generated content stored in Gather. The use cases are limitless. Here I’ll show how Gather’s search API can be integrated into a browser-based game to enhance the user experience.
Let’s assume you’ve built an amazing game that has revolutionized in-browser role-playing. It’s called Candide 3D. In the first six months after launch both the game and the community website have been wildly successful. The website community allows users and administrators to create game guides, post tips, answer questions, and more. The community content has become so valuable that your users are asking for a way to access the content from inside the game. The game-play experience, best played full-screen, is hindered when users must: minimize the game, run a community search, commit relevant results to memory, and finally, return the game to full-screen. Certainly not a great user experience. Good thing you chose to build your community with Gather!
Here’s an example screenshot of what we want to end up with:
If you’re not a developer or some other breed of nerd, you may be asking “What the heck is an API and why does everyone keep talking about them?” An API is defined as an ‘Application Programming Interface’. That definition doesn't help much for for the non-technical, so in practical terms it is simply a documented way for one application to talk to another application.
Why are we talking about APIs? Because they are cool! Yes, APIs are cool. Let me explain.
API vs. Ford Model T
For the unfamiliar, you may more easily identify with a user interface and understand the importance. When you get into your car, unless you’re one of the few remaining Ford Model T owners, you don’t have to cross wires and yank on pulleys to operate your vehicle. These manual steps are not required because the designer built a user interface for you to operate your vehicle. The interface includes the steering wheel, gas and brake pedals and even some knobs to turn up and down the heat to keep you comfortable. The better this user interface is designed, the easier and more enjoyable it is to operate your vehicle.
One of the main concepts in software development is releasing. There is a distinct lack of good solutions for releasing software as most build tools drop the ball when it comes to releasing.
Before we dive into how you configure Savant to perform a release, let's first talk about publishing artifacts. Savant defines a repository structure that is similar to the Maven repository structure. This structure uses the artifact group and project names as well as the project version to define the target directory and the artifact name, version and type form the file name.
Here's an example for the artifact com.mycompany:database-project:mysql:3.0.1:sql:
In order to configure your Savant project to publish artifacts, you must include a publications definition. This definition is broken into two groups. The first is the main group and the second is the test group. The main group are the primary publications of your project that are used at runtime. The test group are the publications of your project that are used at test time.
Savant is a bit different than other build tools. Savant doesn't allow plugins to define build targets. This was a major design decision that we made based on our use of various build tools over the past 10 years.
Here's the reason we decided not to allow plugins to define build targets. Let's say that we are using the Java, Groovy and JRuby plugins and that our project has source code in all three languages. Let's also assume we have tests written in all three languages. The Java plugin defines two build targets: compile and test. These targets compile the Java source code in the directory src/main/java and src/test/java and then execute the tests.
Now, let's assume that our Groovy and JRuby plugins also define these exact same targets. However, our project's Groovy classes use our Java classes and our JRuby classes use our Groovy classes. How do we ensure that our plugins are executed in the correct order?