-
Notifications
You must be signed in to change notification settings - Fork 67
Beta Testing
Squib is a small operation. And programming is hard. So we need testers! In particular, I could use help from people to do the following:
- Test out new features as I write them
- Watch for regression bugs by running their current projects on new Squib code, checking for compatibility issues.
The preferred way of doing this is to get Squib directly from my GitHub repository. Bundler makes this easy.
If you are just starting out you'll need to install bundler:
$ gem install bundler
Then, in the root of your Squib project, create a file called Gemfile
(capitalization counts). Put this in it:
source 'https://rubygems.org'
gem 'squib', git: 'git://github.com/andymeneely/squib', branch: 'master'
Then run:
$ bundle install
Your output will look something like this:
Fetching git://github.com/andymeneely/squib
Fetching gem metadata from https://rubygems.org/.........
Fetching version metadata from https://rubygems.org/...
Fetching dependency metadata from https://rubygems.org/..
Resolving dependencies...
Using pkg-config 1.1.6
Using cairo 1.14.3
Using glib2 3.0.7
Using gdk_pixbuf2 3.0.7
Using mercenary 0.3.5
Using mini_portile2 2.0.0
Using nokogiri 1.6.7
Using pango 3.0.7
Using rubyzip 1.1.7
Using roo 2.3.0
Using rsvg2 3.0.7
Using ruby-progressbar 1.7.5
Using squib 0.9.0b from git://github.com/andymeneely/squib (at master)
Using bundler 1.10.6
Bundle complete! 1 Gemfile dependency, 14 gems now installed.
Use `bundle show [gemname]` to see where a bundled gem is installed.
To double-check that you're using the test version of Squib, puts this in your code:
require 'squib'
puts Squib::VERSION # prints the Squib version to the console when you run this code
# Rest of your Squib code...
When you run your code, say deck.rb
, you'll need to put bundle exec
in front of it. Otherwise Ruby will just go with full releases (e.g. 0.8
instead of pre-releases, e.g. 0.9a
). That would look like this:
$ bundle exec ruby deck.rb
If you need to know the exact commit of the build, you can see that commit hash in the generated Gemfile.lock
. That revision
field will tell you the exact version you're using, which can be helpful for debugging. That will look something like this:
remote: git://github.com/andymeneely/squib
revision: 440a8628ed83b24987b9f6af66ad9a6e6032e781
branch: master
To update to the latest from the repository, run bundle up
.
To remove Squib versions, run gem cleanup squib
. This will also remove old Squib releases.
- When the version ends in "a" (e.g.
v0.9a
), then the build is "alpha". I could be putting in new code all the time without bumping the version. I try to keep things as stable after every commit, but this is considered the least stable code. (Testing still appreciated here, though.) This is also tracked by mydev
branch. - For versions ending in "b" (e.g.
v0.9b
), then the build is in "beta". Features are frozen until release, and we're just looking for bug fixes. This tends to be tracked by themaster
branch in my repository. - I follow the Semantic Versioning as best I can
The Gemfile is a configuration file (technically it's a Ruby DSL) for a widely-used library in the Ruby community called Bundler. Bundler is a way of managing multiple RubyGems at once, and specifying exactly what you want.
Bundler is different from RubyGems. Technically, you CAN use RubyGems without Bundler: just gem install
what you need and your require
statements will work. BUT Bundler helps you specify versions with the Gemfile, and where to get your gems. If you're switching between different versions of gems (like with being tester!), then Bundler is the way to go. The Bundler website is here: http://bundler.io/.
By convention, your Gemfile
should be in the root directory of your project. If you did squib new
, there will be one created by default. Normally, a Squib project Gemfile will look like this. That configuration just pulls the Squib from RubyGems.
But, as a tester, you'll want to have Bundler install Squib from my repository. That would look like this: https://github.com/andymeneely/project-spider-monkey/blob/master/Gemfile. (Just line 4 - ignore the other stuff.) I tend to work with two main branches - dev and master. Master is more stable, dev is more bleeding edge. Problems in the master branch will be a surprise to me, problems in the dev branch probably won't surprise me.
After changing your Gemfile, you'll need to run "bundle install". That will generate a "Gemfile.lock" file - that's Bundler's way of saying exactly what it's planning on using. You don't modify the Gemfile.lock, but you can look at it to see what version of Squib it's locked onto.
Install: Windows OSX Linux Cygwin
Getting Started
Important
Advanced Squibbing
- The Mighty text Method
- Layouts
- Manipulating PNGs
- Manipulating SVGs
- Vector back end
- Rendering both BW and Color
- Colors
- Configuration Options
Real Project Histories
Squiblets
- Category specific template text
- Combining Multiple Columns
- One Icon Per Location
- One Location, Multiple Icons
- Google Sheets
- Rake Rendering Modes
- Autoscale Fonts
- Marketing Materials
- Autobuild with Guardfiles
- Wireframing with an SVG Editor
- Front to Back Printing
- Versioning Practices
- Icon Library: FontAwesome
- Icon Library: GameIcons
- Combining Multiple Columns
- Combine Multiple CSV Files
- Switch card background or invert theme
Tools
Contributing