My goal here is to introduce others to Node.js by basically detailing how I have learned it. In this initial post, I’ll jump right into creating a simple app-as-a-server and use that as a springboard for learning other aspects of Node.js.
In this post I’m going to be focusing on the actions that a player will take with an Inform 7 game. Those actions can be interefered with in various ways to make the game play experience more dynamic. All of this will be done using rules, which I covered in the previous post. In this post, you will see how actions are essentially a descriptive circumstance provided to a rule. When that circumstance applies — meaning, when the action has occurred — then interesting things can be made to happen.
In this post, I’ll continue on the exploration of Inform 7 that I started in the introductory post. Here I’ll continue to add to the game source text started in that post, putting emphasis on rules. Rules are one of the keys aspects — the other being actions — of how Inform 7 allows authors to interact with their game players.
In a series of posts, I’ll be writing about a gaming system I’ve been using to teach children writing skills but have also found helps testers with analysis and thinking skills. This particular gaming system is called Inform 7 and it’s used to program interactive fiction games, which used to be called “text adventures” back in the day. Inform 7 offers some unique challenges to thinking, writing, and programming such that I’ve found it to be an excellent system to explore with. Given that Inform 7 is used to create games that present puzzles to be solved, it’s been instructive for me to treat Inform 7 itself as a puzzle to be solved.
A lot of testers like to use Python. A lot of testers are on Windows machines. There is currently a large gap in the Python world between the 2.x and 3.x branch. (See more details on this.) This often puts testers in the position of having to make Python solutions that run on both versions. But, on Windows at least, this has been tricky in terms of having two Python versions installed and easily moving between them. Here I’ll talk about how the Python development team has eased this with the Windows launcher.
This is the second, and final, post in the series about starting off on a Rails application. In the first post the basis for a “Planets” application was created. I ended up with a database (model) and a functioning mechanism around that database that let me create, edit, and delete records (views). All of that was knitted together into a working application by a controller. However, those views have no validation on them. That means the database is not protected from bad data. I’ll fix that here and then focus a lot on how Rails apps are tested.
Many testers these days will find themselves in Rails shops and, even if that’s not the case, Rails is a good environment within which to build custom test solutions that require a database and a web interface. This is largely because when using Rails, you are using one of the most concise and expressive languages out there: Ruby. I plan to document some of my learning of the Rails ecosystem in two posts.
In a previous post I talked about learning Rails in a way that I wished it had been presented to me. Here I’ll focus a little on the salient facts about the framework that you will no doubt find elsewhere, but sometimes you have to distill it from surrounding material that gets in the way. Near the end, I’ll explain why any of this has relevance to me writing as a tester.
I played around with Node.js in a previous post for web framework design. Now I want to explore Rails a bit. I haven’t found tutorials that I really like on Rails, at least for those getting started. Now that I have gotten started, some of those tutorials I did find are more helpful to me, but they weren’t as helpful starting out. So here I’ll write in a way that helped me learn more about how Rails is actually working, rather than just relying on the “magic” that everyone tells me is happening behind the scenes.
In this post I want to switch around some of what we already did regarding HTML and CSS, by using “variants” of these. Specifically, I’ll look at Slim (to replace our HTML/ERB) and Sass (to replace our CSS).
Following on from the other posts in this series, here I want to focus more on the static and dynamic content aspects. This will actually be fairly tame stuff for the most part but it’s a way to make sure we can do some of the basics with Sinatra — just in time to change them all around a bit.
Here I want to focus more on the particulars of constructing a Sinatra web application. Up to now you basically have something that can serve up static or dynamic web pages. It’s time to get an application structure in place. This in turn will let us deploy our web application.