Dungeon Crawl Stone Soup

Dungeon Crawl Stone Soup is an open-source, single-player, role-playing roguelike game of exploration and treasure-hunting in dungeons filled with dangerous and unfriendly monsters in a quest to rescue the mystifyingly fabulous Orb of Zot.

I’m a sucker for for retro games and Dungeon Crawl Stone Soup looks like a solid roguelike. It can also be played online via SSH and it’s open-source to boot. Win-win-win.

Copyright Infringement or Copyawesome?

I’m a huge supporter of BlackCoin, and back in April I made a few images to show the community my support. To my surprise I recently found out that one of the images is being printed and sold as a magnet in a BlackCoin promo kit!

And you know what?

I don’t even care. I want the community to thrive and if this will help spread awareness of BlackCoin and its potential, then I’m all for it! I’ve ordered my own kit and can’t wait to put stickers up around my city.

I’ve uploaded the pictures in case you want to spread the love too. They make decent backgrounds!

 

 

Running Webmaker On Mobile The Hard Way

So you just finished installing the Webmaker suite of apps on your local machine and you’ve suddenly been overcome with the desire to hack away at the web on your tablet.  Or maybe you’re a developer and you want to help Mozilla improve Webmaker on mobile platforms (good on you!). In either case, you’re going to have to do a bit of configuring to get your machine to serve pages to your mobile device. We’re going to do this by exposing localhost to the internet such that any device connected to the internet can view your pages. To accomplish this we’ll use Pagekite, a service that gives local servers public DNS names. It’s free for a month after which it costs $3/month BUT if you’re a developer of open source software they’ll give you a free account! You’ll need Python to run the script so make sure you have it installed before downloading Pagekite. The quickstart guide will get you set up with an account so do that before continuing.

Now we need to know what ports the services/apps are running on so we can create pagekite pages for them. Currently, the ports are:

  • http://localhost:3000 – login.webmaker.org
  • http://localhost:3500 – thimble.webmaker.org
  • http://localhost:5000 – makeapi
  • http://localhost:5050 – htmlsanitizer.org
  • http://localhost:7777 – webmaker.org
  • http://localhost:8888 – popcorn.webmaker.org
  • http://localhost:12416 – goggles.webmaker.org

For this example I’ll briefly explain how to expose Thimble. If you open up the .env file in your thimble.webmaker.org directory, you’ll notice a block of code like this:

# hostname for this server according to your browser
# if they don't match then Persona will not work
export HOSTNAME="http://localhost:3500"

# Persona single sign-on host
export AUDIENCE="http://localhost:7777"

# User bar is hosted at:
export USERBAR="http://localhost:3000"

# where can we access the webmaker loginAPI?
export LOGINAPI="http://testuser:password@localhost:3000"

# make API url
export MAKE_ENDPOINT="http://localhost:5000"

You’re going to want to replace all instances of http://localhost:#### with a pagekite page that you set up. My main page is called stanica, so I first got thimble up there by running

python pagekite.py 3500 stanica.pagekite.me

inside a terminal. This exposes http://localhost:3500 to the internet via http://stanica.pagekite.me Now we can make sub-domains for each of the other apps. Note that each command needs to be run in its own terminal window.

python pagekite.py 3000 login.stanica.pagekite.me

python pagekite.py 5000 makeapi.stanica.pagekite.me

python pagekite.py 7777 webmaker.stanica.pagekite.me

Now we simply go back to the .env file in the thimble.webmaker.org directory and replace all the localhost instances with our pagekite kites.

# hostname for this server according to your browser
# if they don't match then Persona will not work
export HOSTNAME="http://stanica.pagekite.me"

# Persona single sign-on host
export AUDIENCE="http://webmaker.stanica.pagekite.me"

# User bar is hosted at:
export USERBAR="http://login.stanica.pagekite.me"

# where can we access the webmaker loginAPI?
export LOGINAPI="http://testuser:password@login.stanica.pagekite.me"

# make API url
export MAKE_ENDPOINT="http://makeapi.stanica.pagekite.me"

The final step is to go to each of the folders for webmaker, makeapi, etc and make the same changes in their respective .env files.

 

Good luck!

 

Release 0.1

I just finished the patch for the bug I’ve been working on. The end result was only a few lines of code but getting my environment set up was ridiculously time consuming. The instructions for setting Webmaker-suite up were specific for Windows 7 so naturally I ran into some problems on my Windows 8 machine. I filed a bug with a potential fix in case anyone else was having issues. With Webmaker suite set up I then had to find a way to get Thimble and its various dependencies accessible on my iPad. Unfortunately, even though the server was running locally on my network I couldn’t access Thimble on my iPad no matter how I configured my network. I ended up having to expose my localhost to the internet. I wrote a post outlining a rather brute force method though it’s probably not the best way.

 

With my environment set up and pages viewable on my iPad, I first attempted the JavaScript fix I proposed in a previous post. Long story short, it didn’t work. There isn’t a way to apply the “touch” value to the -webkit-overflow-scrolling property. I found a rogue Stack Overflow post that suggested using style.WebkitOverflowScrolling = ‘touch’; but it didn’t work. While looking for solutions I found a simple CSS media query that targets mobile devices (iPads in particular) with a screen width of 768 pixels.

@media only screen and (device-width: 768px) {
  .thimble-project-container {
    /* For iOS scrolling within iframe.*/
    overflow: auto;
    -webkit-overflow-scrolling: touch;
  }
}

 

By using the device-width property, we can target mobile devices instead of laptops with smaller screens. I posted a pull request tonight and I’ll message someone tomorrow to take a look.

[Bug] Thimble pages not scrollable on iOS

The Bug

I got my first bug assigned to me! I tried to pick an easy bug so I could more smoothly familiarize myself with Thimble. The issue is fairly straight forward – I tried Thimble on my iPhone and iPad and indeed pages were not scrollable. Jon Buckley actually posted the CSS required to fix the problem:

body {
  -webkit-transition: top .2s ease-in-out;
  -o-transition: top .2s ease-in-out;
  -ms-transition: top .2s ease-in-out;

  /* For iOS scrolling within iframe. Safariiiiiiii */
  overflow: scroll;
  -webkit-overflow-scrolling: touch;
}

According to Buckley this causes two scrollbars to appear in desktop browsers. I made a test page in jsfiddle to see if I could replicate the two scrollbars but was unable to. The box does have kinetic scrolling on iOS 7 but I only see one scrollbar in Chrome and Safari so the issue might be Thimble-specific. Embedding my previous test page inside an iFrame inside jsfiddler did result in two scrollbars, but they were there regardless of the iOS CSS. I’ll have to add the code directly to Thimble to see what Jon meant.

The Fixes

Javascript

Assuming that Buckley is correct I’ll need to check what browser is accessing the page and apply the CSS conditionally. The simplest way to do this is by retrieving the user agent and applying a regular expression to determine the browser.

var userAgent = window.navigator.userAgent;

if (userAgent.match(/iPad/i) || userAgent.match(/iPhone/i)) {
   // iPad or iPhone
}
else {
   // Anything else
}

 CSS

Alternatively, I could use the screen media type query to detect a mobile browser and apply a style sheet specifically for mobile devices.

<link media="only screen and (max-device-width: 480px)" 
      href="mobile.css" 
      type= "text/css" 
      rel="stylesheet">
<link media="only screen and (-webkit-min-device-pixel-ratio: 2)" 
      href="retina.css" 
      type="text/css" 
      rel="stylesheet">

 

Since this is a small bug, I’ll try the JavaScript route first as it’s the least intrusive. If there are many mobile-related bugs and it’s decided that mobile support is going to be taken seriously, then an external style sheet will probably be the most flexible solution.

Aside: There seems to be an issue with -webkit-overflow-scrolling: touch being broken in iOS7. It worked for me but I’ll keep it in mind moving forward.

Project Decisions

The time has come to choose this semester’s project for DPS909. I’ve always had a passing interest in user interface (UI) and user experience (UX) design so I was pleased to see that some of the projects involved working on UI. One project that stood out in particular has to do with improving Webmaker for mobile/tablets. Back when I was working on the Popcorn project, a colleague and I actually got Popcorn working on an iPad as part of a skunkworks project. I loaded up Webmaker on my iPad 1 to see how it ran and found that although the page loaded and rendered correctly, none of the tiles were clickable. This is likely because the tiles respond to a hover event that can’t be replicated on a mobile device. Popcorn Maker also loaded and rendered correctly, but I was unable to load a YouTube video for remixing. Thimble was the finickiest of the lot, failing to bring up an onscreen keyboard when tapping in the editor. I was able to bring up the keyboard in a roundabout way, by tapping an HTML element and then tapping the orange “?” that appeared. It’s clear that none of these websites have been optimized much less designed with a mobile interface in mind, so there is a lot to be done in that regard. There weren’t any specific bugs for this project so I’ll have to see just how much they want to improve. Another interesting project is one to improve the Thimble UI. I looked at the listed bugs and they seemed manageable compared to some of the other projects’.

 

Hopefully I’ll get to work on one of these projects!

DPS909 Introduction Post

For the first assignment in Topics In Open Source Development, from here on referred to as DPS909, I had to read one open and one close-sourced end-user license agreement (eula). I must have accepted hundreds of these in the past, yet never once bothered to read what I was actually agreeing to.  I imagine the vast majority of computer users are in the same boat as me – reading a eula from start to finish is an exercise in superhuman patience. The two eulas I read were Apple’s iOS Software License Agreement for iOS 6 and The MIT License.

The first thing I noted about Apple’s agreement is something that, while obvious in retrospect, had never occurred to me prior to reading the agreement.

“The software (including Boot ROM code and other embedded software), documentation, interfaces, content, fonts and any data that came with your iOS Device … are licensed, not sold, to you by Apple Inc. (“Apple”) for use only under the terms of this License”

It’s strange to think this device that I paid hundreds of dollars for does not fully belong to me. I may own the hardware (although I’m sure that comes with its own caveats as well) but all the software running on the phone belongs to apple and with it the right to terminate my service any time I fail to uphold the agreement. Again, this should have been painfully obvious from the start, but I wonder how many iPhone users are aware that when they say “this is my iPhone” they actually mean, “this is my expensive computer that’s useless without Apple”.

 

The other noteworthy part of the agreement was how Apple handles the consent to use my data. For the most part, they’re pretty good at letting you opt out of certain data tracking. For instance, there’s a global option to limit ad tracking that prevents third party developers from using your data and information to send targeted ads. Safari, the built in web browser, also has settings for disabling third party tracking cookies. Where it gets interesting is Apple’s stance on location-based services.

“By using any location-based services on your iOS Device, you agree and consent to Apple’s and its partners’, licensees’ and third party developers’ transmission, collection, maintenance, processing and use of your location data and queries to provide and improve such products and services.”

It’s unfortunate that this is the case because location services are such an integral part of the smart phone experience. Using Google Maps without giving it my location renders it almost entirely useless. One of my most used apps, NextBus, would have me wading through menus to select the correct bus route and stop should I disable location services. I exaggerate, of course, but there’s a lot to be said about the fluidity of applications knowing where you’re located and subsequently delivering information to you based on this location. Disabling location services in an attempt to boost my privacy just isn’t an option (at least for me) after having paid a premium on a phone and a recurring monthly fee.

 

The MIT license was the second license I looked at and it’s almost comical in its simplicity.

“Permission is hereby granted, free of charge, to any person… to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software…”

It essentially allows anyone to do anything with the software as long as they include a copy of the MIT license in “all copies or substantial portions of the Software”. I’m assuming that the license must only be included for “substantial portions” of the software, and not all portions of the software, such that if you were to sell or license copies you could do so in a way that protects you from releasing all of your code online.

 

An interesting read, no doubt, and one that opened my eyes to the sneakiness that is end-use license agreements.

Week of July 28th

I had a lengthy discussion with Chad last Friday and again this Monday regarding using session variables versus using a class to store session data. Chad doesn’t like session variables so he suggested I make a class to store all session data. The upside is that we can now store different data types in the class – session variables are limited to string data. Having never worked with a system that’s supposed to support so many people simultaneously, I started wondering how efficient it was to store so much information in a single class for each user. We created methods that query the database and return data in lists. We don’t have methods that return each individual field in the database, but instead that return chunks of data relevant to what we need. For instance, the getUserInfo method will return fields containing the user’s first name, last name, email, settings, etc. However, I found that I needed specific fields from that method in other parts of the website. The solution was then to either create specific methods that return just the fields that I need, or to populate a UserSession class with all the data I may ever need upon user log in. I went with the latter solution. I don’t know if this is necessarily the most efficient route, so we’ll have to run metrics later on.