Results for course-specify

travis-blink1 is a simple sign by blink(1). When you specify a repository travis-blink1 checks your pull request and it shows signal by Travis CI is passed or not. Of course gree sign is passed and red is not.

This program is a game written for the Ruby course at pragmaticstudio.com. Excellent course by the way if you are considering learning Ruby. I highly recommend both learning Ruby and this course. The game is fairly straight forward. Players are loaded by default from a players.csv file, however a different players file can be specified on the command line. A custom players file would be a .csv with a player's name and initial health being the two fields on each line. The game starts when the main studio_game program is run. The players take turns and are randomly w00ted, blammed, or skipped depending on what number is rolled by a die. The one running the game can choose how many rounds to play and then quit. When the game quits, the stats are printed to the screen and the game exits. Enjoy, PeterPiper

This is a game developed during the Pragmatic Studio Ruby course. After running the game, the user is prompted for the number of game rounds. Each round, players are strengthened or weakened based on their type and the roll of a die. Additionally, players find treasures at random each round. At the end of the specified number of rounds, the user can type 'quit' to view player statistics.

This was my bonus project for the Ruby course at pragmaticstudio.com. The program tracks projects that have funds randomly added or removed. The randomness is driven by Coin class since funding is either added or removed from the project during each funding round. The program runs with either a default projects file, or one can be specified at the command line as a file with title,target_funding,initial_funding. See the default projects.csv file for examples. Enjoy! PeterPiper

Baby mix-in for Test::Unit which allows one to specify manual test cases with steps. Manual test cases are a necessary evil in this world and something that I feel is missing sorely (but not sadly) is the ability to keep your manual test cases coupled with your automated test cases. Manual tests playing with automated tests. Of course, the goal of Moonit is to not interfere with automated tests so it is necessary to tell ruby you want to execute your manual tests alongside your automated tests at runtime.

Simple game simulation Ruby program written for the online Ruby Programming course from The Pragmatic Studio. Create a csv file (or use the provided file 'players.csv') that contains the player names and their initial health, and give that file as an argument to bin/studio_game. The game simulation will add two specialized players and then run a user-specified numbers of rounds, randomly assigning, or inflicting, game events on the various players, printing individual round results and a final summary at the end.

== FEATURES/PROBLEMS: * Order types supported: buy, short, sell and cover * Pulls real-time stock quotes from Yahoo! Finance == SYNOPSIS: Fantasy Stock Exchange app on Facebook (by HedgeStop.com): http://apps.facebook.com/hedgestop/ As of this writing, the Fantasy Stock Exchange application on Facebook does not allow one to place stop-limit orders or otherwise automatically trigger a buy/sell or cover/short order based upon specified prices. FSX Trader, when combined with a periodic cron job, can make these trades for you. Simply configure your trades in the '~/.fsx_trader.yml' file and they will happen automatically whenever FSX Trader is run AND conditions for making a trade (as specified via the config file) have been met. Note: fsxtrader of course depends upon the external HTML form variables of the FSX App and Facebook login page. If these variables have changed, fsxtrader be temporarily broken until the gem can be updated. A programmatic API into FSX would be ideal, but is currently not yet offered by HedgeStop. == REQUIREMENTS:

This gem will play rounds of a made up game that will w00t or blam players. The default players are listed in the bin/players.csv file. You can use your own players by specifying a csv listings of the names and health of each player. Example: Thomas,100 Michael,110 Judi,105 Then to use the file for execution, simply type in studio_game <path to file here> Many thanks to the folks at Pragmatic Studios for their help in assisting me with this gems creation. If you want to create a gem similar to this you can visit Pragmatic Studios and sign up for one of their classes. This is an example application used in The Pragmatic Studio's Ruby Programming course, as described at http://pragmaticstudio.com This code is Copyright 2014 Michael Nickey and The Pragmatic Studio. See the LICENSE file.

## YardGame A simple game app created with ruby. ## Table of Contents * [General info](#general-info) * [Technologies](#technologies) * [Setup](#setup) * [Sources](#sources) ## Introduction YardGame was while taking course by Nicole and Mike, the Pragmatic duo. Its a game that allow player earn points on treasures found in the yard. Points are added to the player's health to gain higher scores. It involves a random die roll. ## Technologies * Ruby 3 * Rspec 3 ## Setup To run this project, install it locally. $ gem install yard_game_1.2.0.gem You can load players from the command line in a CSV file. You can also run the game without specifying a player file. A default players.csv file is packaged in the gem. ## Sources This app was inspired by Mike and Nicole Clark of The Pragmatic Studio.

A simple, text-based crowdfunding simulator. Run a group of projects through a series of funding rounds, in which they either receive or lose funds, or are skipped. They also receive a random pledge. Grant projects never lose funds. Match projects have all future funding matched after they reach half-funding. Statistics are printed to the console at the end of the simulation. The normal projects can be specified in a '.csv' file that is given as a command line argument when loading the program, or the default projects can be used. The format for 'csv' entries is Project Name,Goal,Initial_funding with a comma and no spaces between entries and underscores in place of commas within larger numbers (e.g. Your Project,10_000,0). The option is given to save a list of underfunded projects upon exiting the program. The list is saved in 'underfunded.txt' in the top-level folder of the application. Created as a bonus project while completing the Pragmatic Studio Ruby Programming course.

== README.md: #ScheduledResource This gem is for displaying how things are used over time -- a schedule for a set of "resources". You can configure the elements of the schedule and there are utilities and protocols to connect them: - Configuration (specification and management), - Query interfaces (a REST-like API and internal protocols to query the models), and - A basic Rails controller implementation. We have a way to configure the schedule, internal methods to generate the data, and a way to retrieve data from the client. However this gem is largely view-framework agnostic. We could use a variety of client-side packages or even more traditional Rails view templates to generate HTML. In any case, to get a good feel in a display like this we need some client-side code. The gem includes client-side modules to: - Manage <b>time and display geometries</b> with "infinite" scroll along the time axis. - <b>Format display cells</b> in ways specific to the resource models. - <b>Update text justification</b> as the display is scrolled horizontally. ## Configuration A **scheduled resource** is something that can be used for one thing at a time. So if "Rocky & Bullwinkle" is on channel 3 from 10am to 11am on Saturday, then 'channel 3' is the <u>resource</u> and that showing of the episode is a <u>resource-use</u> block. Resources and use-blocks are typically Rails models. Each resource and its use-blocks get one row in the display. That row has a label to the left with some timespan visible on the rest of the row. Something else you would expect see in a schedule would be headers and labels -- perhaps one row with the date and another row with the hour. Headers and labels also fit the model of resources and use-blocks. Basic timezone-aware classes (ZTime*) for those are included in this gem. ### Config File The schedule configuration comes from <tt>config/resource_schedule.yml</tt> which has three top-level sections: - ResourceKinds: A hash where the key is a Resource and the value is a UseBlock. (Both are class names), - Resources: A list where each item is a Resource Class followed by one or more resource ids, and - visibleTime: The visible timespan of the schedule in seconds. The example file <tt>config/resource_schedule.yml</tt> (installed when you run <tt>schedulize</tt>) should be enough to display a two-row schedule with just the date above and the hour below. Of course you can monkey-patch or subclass these classes for your own needs. ### The schedule API The 'schedule' endpoint uses parameters <tt>t1</tt> and <tt>t2</tt> to specify a time interval for the request. A third parameter <tt>inc</tt> allows an initial time window to be expanded without repeating blocks that span those boundaries. The time parameters _plus the configured resources_ define the data to be returned. ### More About Configuration Management The <b>ScheduledResource</b> class manages resource and use-block class names, id's and labels for a schedule according to the configuration file. A ScheduledResource instance ties together: 1. A resource class (eg TvStation), 2. An id (a channel number in this example), and 3. Strings and other assets that will go into the DOM. The id is used to - select a resource _instance_ and - select instances of the _resource use block_ class (eg Program instances). The id _could_ be a database id but more often is something a little more suited to human use in the configuration. In any case it is used by model class method <tt>(resource_use_block_class).get_all_blocks()</tt> to select the right use-blocks for the resource. A resource class name and id are are joined with a '_' to form a tag that also serves as an id for the DOM. Once the configuration yaml is loaded that data is maintained in the session structure. Of course having a single configuration file limits the application's usefulness. A more general approach would be to have a user model with login and configuration would be associated with the user. ## Installation Add this line to your application's Gemfile: ```ruby gem 'scheduled_resource' ``` And then execute: $ bundle Or install it yourself as: $ gem install scheduled_resource Then from your application's root execute: $ schedulize . This will install a few image placeholders, client-side modules and a stylesheet under <tt>vendor/assets</tt>, an example configuration in <tt>config/resource_schedule.yml</tt> and an example controller in <tt>app/controllers/schedule_controller.rb</tt>. Also, if you use $ bundle show scheduled_resource to locate the installed source you can browse example classes <tt>lib/z_time_*.rb</tt> and the controller helper methods in <tt>lib/scheduled_resource/helper.rb</tt> ## Testing This gem also provides for a basic test application using angularjs to display a minimal but functional schedule showing just the day and hour headers in two different timezones (US Pacific and Eastern). Proceed as follows, starting with a fresh Rails app: $ rails new test_sr As above, add the gem to the Gemfile, then $ cd test_sr $ bundle $ schedulize . Add lines such as these to <tt>config/routes.rb</tt> get "/schedule/index" => "schedule#index" get "/schedule" => "schedule#schedule" Copy / merge these files from the gem source into the test app: $SR_SRC/app/views/layouts/application.html.erb $SR_SRC/app/views/schedule/index.html.erb $SR_SRC/app/assets/javascripts/{angular.js,script.js,controllers.js} and add <tt>//= require angular</tt> to application.js just below the entries for <tt>jquery</tt>. After you run the server and browse to http://0.0.0.0:3000/schedule/index you should see the four time-header rows specified by the sample config file. ## More Examples A better place to see the use of this gem is at [tv4](https://github.com/emeyekayee/tv4). Specifically, models <tt>app/models/event.rb</tt> and <tt>app/models/station.rb</tt> give better examples of implementing the ScheduledResource protocol and adapting to a db schema organized along somewhat different lines. ## Contributing 1. Fork it ( https://github.com/emeyekayee/scheduled_resource/fork ) 2. Create your feature branch (`git checkout -b my-new-feature`) 3. Commit your changes (`git commit -am 'Add some feature'`) 4. Push to the branch (`git push origin my-new-feature`) 5. Create a new Pull Request

:title: The Ruby API :section: PYAPNS::Client There's python in my ruby! This is a class used to send notifications, provision applications and retrieve feedback using the Apple Push Notification Service. PYAPNS is a multi-application APS provider, meaning it is possible to send notifications to any number of different applications from the same application and same server. It is also possible to scale the client to any number of processes and servers, simply balanced behind a simple web proxy. It may seem like overkill for such a bare interface - after all, the APS service is rather simplistic. However, PYAPNS takes no shortcuts when it comes to completeness/compliance with the APNS protocol and allows the user many optimization and scaling vectors not possible with other libraries. No bandwidth is wasted, connections are persistent and the server is asynchronous therefore notifications are delivered immediately. PYAPNS takes after the design of 3rd party push notification service that charge a fee each time you push a notification, and charge extra for so-called 'premium' service which supposedly gives you quicker access to the APS servers. However, PYAPNS is free, as in beer and offers more scaling opportunities without the financial draw. :section: Provisioning To add your app to the PYAPNS server, it must be `provisioned` at least once. Normally this is done once upon the start-up of your application, be it a web service, desktop application or whatever... It must be done at least once to the server you're connecting to. Multiple instances of PYAPNS will have to have their applications provisioned individually. To provision an application manually use the `PYAPNS::Client#provision` method. require 'pyapns' client = PYAPNS::Client.configure client.provision :app_id => 'cf', :cert => '/home/ss/cert.pem', :env => 'sandbox', :timeout => 15 This basically says "add an app reference named 'cf' to the server and start a connection using the certification, and if it can't within 15 seconds, raise a `PYAPNS::TimeoutException` That's all it takes to get started. Of course, this can be done automatically by using PYAPNS::ClientConfiguration middleware. `PYAPNS::Client` is a singleton class that is configured using the class method `PYAPNS::Client#configure`. It is sensibly configured by default, but can be customized by specifying a hash See the docs on `PYAPNS::ClientConfiguration` for a list of available configuration parameters (some of these are important, and you can specify initial applications) to be configured by default. :section: Sending Notifications Once your client is configured, and application provisioned (again, these should be taken care of before you write notification code) you can begin sending notifications to users. If you're wondering how to acquire a notification token, you've come to the wrong place... I recommend using google. However, if you want to send hundreds of millions of notifications to users, here's how it's done, one at a time... The `PYAPNS::Client#notify` is a sort of polymorphic method which can notify any number of devices at a time. It's basic form is as follows: client.notify 'cf', 'long ass app token', {:aps=> {:alert => 'hello?'}} However, as stated before, it is sort of polymorphic: client.notify 'cf', ['token', 'token2', 'token3'], [alert, alert2, alert3] client.notify :app_id => 'cf', :tokens => 'mah token', :notifications => alertHash client.notify 'cf', 'token', PYAPNS::Notification('hello tits!') As you can see, the method accepts paralell arrays of tokens and notifications meaning any number of notifications can be sent at once. Hashes will be automatically converted to `PYAPNS::Notification` objects so they can be optimized for the wire (nil values removed, etc...), and you can pass `PYAPNS::Notification` objects directly if you wish. :section: Retrieving Feedback The APS service offers a feedback functionality that allows application servers to retrieve a list of device tokens it deems to be no longer in use, and the time it thinks they stopped being useful (the user uninstalled your app, better luck next time...) Sounds pretty straight forward, and it is. Apple recommends you do this at least once an hour. PYAPNS will return a list of 2-element lists with the date and the token: feedbacks = client.feedback 'cf' :section: Asynchronous Calls PYAPNS::Client will, by default, perform no funny stuff and operate entirely within the calling thread. This means that certain applications may hang when, say, sending a notification, if only for a fraction of a second. Obviously not a desirable trait, all `provision`, `feedback` and `notify` methods also take a block, which indicates to the method you want to call PYAPNS asynchronously, and it will be done so handily in another thread, calling back your block with a single argument when finished. Note that `notify` and `provision` return absolutely nothing (nil, for you rub--wait you are ruby developers!). It is probably wise to always use this form of operation so your calling thread is never blocked (especially important in UI-driven apps and asynchronous servers) Just pass a block to provision/notify/feedback like so: PYAPNS::Client.instance.feedback do |feedbacks| feedbacks.each { |f| trim_token f } end :section: PYAPNS::ClientConfiguration A middleware class to make `PYAPNS::Client` easy to use in web contexts Automates configuration of the client in Rack environments using a simple confiuration middleware. To use `PYAPNS::Client` in Rack environments with the least code possible `use PYAPNS::ClientConfiguration` (no, really, in some cases, that's all you need!) middleware with an optional hash specifying the client variables. Options are as follows: use PYAPNS::ClientConfiguration( :host => 'http://localhost/' :port => 7077, :initial => [{ :app_id => 'myapp', :cert => '/home/myuser/apps/myapp/cert.pem', :env => 'sandbox', :timeout => 15 }]) Where the configuration variables are defined: :host String the host where the server can be found :port Number the port to which the client should connect :initial Array OPTIONAL - an array of INITIAL hashes INITIAL HASHES: :app_id String the id used to send messages with this certification can be a totally arbitrary value :cert String a path to the certification or the certification file as a string :env String the environment to connect to apple with, always either 'sandbox' or 'production' :timoeut Number The timeout for the server to use when connecting to the apple servers :section: PYAPNS::Notification An APNS Notification You can construct notification objects ahead of time by using this class. However unnecessary, it allows you to programmatically generate a Notification like so: note = PYAPNS::Notification.new 'alert text', 9, 'flynn.caf', {:extra => 'guid'} -- or -- note = PYAPNS::Notification.new 'alert text' These can be passed to `PYAPNS::Client#notify` the same as hashes

No description provided.

No description provided.