All RPGs and Storygames by Tod Foley are now available at DrivethruRPG and RPGnow. Bring these games to your table!
It’s time for me to amble into my garage and offer up an assortment of the strange things that I find there. It’s a bit of a post-Christmas tradition here at the stew. I have to make room for all the coal Santa keeps bringing me for some reason… Each has an adventure seed baked in so feel free to pick them up for your players. After all, one gnome’s trash is another’s treasure.
As is tradition, I’m offering up more than one version of some of these items: a mundane one, and additional details of a more fantastic nature — suitable for use in your supernatural horror, fantasy, or sci-fi campaigns.
Paper and ink: This could be a simple sheaf of paper and an inkwell, or a calligraphy set, or in a modern game could simply be printer paper and ink. In any case it’s eye catching, high quality and a steal at the price being asked.
Mundane: Upon use it is discovered that the ink is invisible when it dries and some of the paper has already been used. The notes uncovered lead on some sort of scavenger hunt. Who set it up, and what is the end result likely to be? Is it worth tracking down all the clues?
Fantastic: This appears to be normal ink and paper, but writing or printing using the paper and ink appear normal then slowly transform into different documents over time.
A set of gardening tools: A bundle of tools for tending plants — a set of snips, a small hand rake, and a trowel — wrapped in a canvas satchel featuring a map.
Mundane: secreted in the handle of the trowel is another piece of fabric with some cryptic lines and holes that overlay the map on the satchel. Leading to buried treasure perhaps?
Fantastic: In addition to the map and the riddles, the trowel itself acts as a lodestone at various locations.
An old filing cabinet: A cabinet for keeping papers and files of common construction. A little worn out but still functional.
Mundane: A false bottom conceals a weapon, a stash of cash and a diary that may lead to more. Who did this belong to and how did it get sold at a yard sale?
Fantastic: The cabinet is haunted of sorts. Strange sounds come from it and there are flashes of movement in the corner of your eye when it is nearby. Can solving the mystery of the diary put these spirits to rest?
An animal leash: A leather leash with several sets of numbers etched on its sides, and a metal handle. The sets of numbers are coordinates. The first leads to a site off some wilderness walking trails with a grave marker and a vault door that requires more than one key to open. Maybe the other coordinates have the other keys.
A grave site: The deed to a grave site. Supposedly never used, but being sold for just a little cash. Seems worth the gamble.
Mundane: According to the cemetery, the plot is indeed unused, yet it appears to be occupied. Unearthing the site reveals only a large metal box containing a vampire slaying kit, a diary with names and locations, and a note addressed to the PCs directly. Where did this come from? How did they address it to you and is there a madman out there slaying “vampires”?
Fantastic: With a little more fantasy, those vampires are probably real and likely aren’t happy someone has all their addresses.
A vintage tool: A complex mechanical tool. Old but in good condition. It would be useful for a PC’s crafting. The tool works but It’s missing an optional part that’s complicated enough that jury-rigging one is unlikely. Local crafters can’t provide one, because they don’t know what it’s supposed to accomplish. However, they can interpret the machine’s maker’s mark, so the original craftsman can be tracked down.
At ComputerMinds we like to think that we’re all pretty good at what we do; however, nobody is perfect and this is why we always ensure that our code is properly peer reviewed as part of our quality assurance process.
Peer review is literally just what the name implies; we work together to review each other’s code to make sure that it all makes sense. This approach means that we’re able to spot obvious mistakes before they become a problem. It also has the huge advantage of allowing us to transfer knowledge between our team on a day-to-day basis.Pull Requests
The primary way we peer our code is to make use of GitHub’s pull requests (PR) feature. This means that whenever we need to do some work on a Git repo we start by creating a new feature branch which will contain the chunk of work that we’re doing. Then once we are happy with the code we’ve written in this branch we’ll go over to GitHub and create a PR to merge our branch in with another branch which we know is stable, for example the master branch. Before this merge happens GitHub’s PR tool will show all the changes between the the two branches so that they can be reviewed by another developer.
At ComputerMinds we use pull requests a lot. We don’t like to work directly on a stable branch as this way there is much more chance the bugs might slip through the net. By using pull requests we can be sure that our code is properly sanity checked before it makes its way over to a stable environment, be that a client facing testing branch or the live branch. GitHub also makes it easy to add comments directly to the pull request so any issues are full documented and feedback is clearly displayed.Face to face
When dealing with a more in-depth code change, it's particularly helpful to talk face-to-face, as it allows the original developer to talk you through their changes and the thinking behind them. This allows the reviewer to have a much better understanding of what the original developer was aiming to achieve and to sanity-check their thinking. A 'meatspace' chat can be more difficult to achieve than just getting some comments on a pull request, but it's often worth the effort.Finding the right fit
Both of these methods have their strengths and weaknesses. Pull requests are quick and easy to use; however, when dealing with larger sets of changes things may get overlooked, or may not be properly understood without knowledge of the bigger picture. Face to face reviews obviously take up more resources to conduct the review but do allow for a more in-depth review where the bigger picture can be clearly explained by the original developer.
Obviously it goes without saying that these two approaches to peer review aren’t mutually exclusive - there are plenty of meatspace chats going on around the office about various PRs.
At ComputerMinds we're still working on how we do code review. There's always room for growth and for change, and we're actively promoting discussion amongst our team to see how we can do better.
How do you do quality assurance and review on your code? Share your thoughts and tips with us below!
"Create Module On One Click"
A module which create a Simple Module with all default files like .info,.routing,.install,.module and readme files.This is very easy and fast to create a module with basic code and it is also useful for new developers to create a module.
This module also create:
Restart of Chinaâs Game Approval Process and What It Means for Localization - by Jacob Stempniewicz
IMPORTANT! This module currently requires a core patch. See "Requirements" section below.
This module allow site builders to select from a list of styles to apply to blocks that are placed via Layout Builder.
A "style" is a configuration entity with the following properties:
This module will allow LTL Freight shipments to be quoted using an active account with R&L Carriers (https://www.rlcarriers.com/).
Last week was my twelfth Drupalversary!
The first half dozen years as a volunteer contributor/student, the second half as a full-time contributor/Acquia employee. Which makes this a special Drupalversary and worth looking back on :)2006–2012
The d.o highlights of the first six years were my Hierarchical Select and CDN modules. I started those in my first year or so of using Drupal (which coincides with my first year at university). They led to a summer job for Mollom, working with/for Dries remotely — vastly better than counting sandwiches or waiting tables!
It also resulted in me freelancing during the school holidays: the Hierarchical Select module gained many features thanks to agencies not just requesting but also sponsoring them. I couldn’t believe that companies thousands of kilometers away would trust a 21-year old to write code for them!
Then I did my bachelor thesis and master thesis on Drupal + WPO (Web Performance Optimization) + data mining. To my own amazement, my bachelor thesis (while now irrelevant) led to freelancing for the White House and an internship with Facebook.
Biggest lesson learned: opportunities are hiding in unexpected places! (But opportunities are more within reach to those who are privileged. I had the privilege to do university studies, to spend my free time contributing to an open source project, and to propose thesis subjects.)2012–2018
The second half was made possible by all of the above and sheer luck.
When I was first looking for a job in early 2012, Acquia had a remote hiring freeze. It got lifted a few months later. Because I’d worked remotely with Dries before (at Mollom), I was given the opportunity to work fully remotely from day one. (This would turn out to be very valuable: since then I’ve moved three times!) Angie and Moshe thought I was a capable candidate, I think largely based on the Hierarchical Select module.
Imagine that the remote hiring freeze had not gotten lifted or I’d written a different module? I was lucky in past choices and timing.
So I joined Acquia and started working on Drupal core full-time! I was originally hired to work on the authoring experience, specifically in-place editing.
The team of four I joined in 2012 has quadrupled since then and has always been an amazing group of people — a reflection of the people in the Drupal community at large!
Getting Drupal 8 shipped was hard on everyone in the community, but definitely also on our team. We all did whatever was most important; I probably contributed to more than a dozen subsystems along the way. The Drupal 8 achievement I’m most proud of is probably the intersection of cacheability and the render pipeline: Dynamic Page Cache & BigPipe, both of which have accelerated many billions responses by now. After Drupal 8 shipped, my primary focus has been the API-First Initiative. It’s satisfying to see Drupal 8 do well.
Biggest lessons learned:
- code criticism is not personal criticism — not feeling the need to defend every piece of code you’ve written is not only liberating, it also makes you immensely more productive!
- always think about future maintainability — having to provide support and backwards compatibility made me truly understand the consequences of mistakes I’ve made.
To many more years with the Drupal community!
Remove unnecessary blocks from the block list for better system performance.
Drupal provides an extensive list of blocks, many of which you may never use anywhere, and others you won't use in Layout Builder. Improve UX and system performance by removing blocks that won't be used on your site.
Create a new token under site that allows one to grab a http header.
tl;dr: Run composer require zaporylie/composer-drupal-optimizations:^1.0 in your Drupal codebase to halve Composer's RAM usage and make operations like require and update 3-4x faster.
A few weeks ago, I noticed Drupal VM's PHP 5.6 automated test suite started failing on the step that runs composer require drupal/drush. (PSA: PHP 5.6 is officially dead. Don't use it anymore. If you're still using it, upgrade to a supported version ASAP!). This was the error message I was getting from Travis CI:PHP Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried to allocate 32 bytes) in phar:///usr/bin/composer/src/Composer/DependencyResolver/RuleWatchNode.php on line 40
I ran the test suite locally, and didn't have the same issue (locally I have PHP's CLI memory limit set to -1 so it never runs out of RAM unless I do insane-crazy things.