Results for env-scripts

Use ~/.env as your source of keys/secrets/etc for your scripts

Useful for loading complex shell script environments (such as those composed when using direnv) into RubyMine.

Simplify checking pre-requisites (env. vars. & executables) for ruby scripts

With the new Jenkinsfile-approach, I wanted a small script to send notifications to IRC. Since most of the information comes from env-vars supplied by Jenkins, this is a very generic script. Packaging this a gem enables proper dependency management.

🗿 Generate both SHA256 & SHA512 checksums into the checksums directory, and git commit them. gem install stone_checksums Then, use the rake task or the script: rake build:generate_checksums gem_checksums Control options with ENV variables! Fund overlooked open source projects - bottom of stack, dev/test dependencies: floss-funding.dev

A Ruby gem which takes the pain of continuously reading data from a serial port away and lets you focus on dealing with the data received. This was written specifically for reading in data from an ID-20 RFID card reader and running custom scripts to automatically perform various tasks when patrons scanned their badge at the [MN Mill](http://mnmill.org) (logging attendance, etc). Custom scripts are loaded from `ENV["HOME"]/millworker/tasks` and are executed in alphabetical order. Each script is executed with the ID of the badge passed in as an argument. For example, a script called `tweet_id.rb` existed in the afformentioned directory, it would be executed as if you had opened up a command terminal and typed `tweet_id.rb RFID_TAG_ID_HERE`.

Most existing gems that address command execution provide a limited interface or lack notable features. In contast, Exek seeks to provide comprehensive support for all of a program's exec needs with one thoughtfully-designed library. Intended features: - A "Command" class that encapsulates argv, env, and IO options, and process state. - Easy-to-use high level interfaces with sensible defaults for running commands to completion. - Comprehensive support for low-level concerns like piping, PTYs, and file descriptor magic. - Utilities for manipulating `sh` script strings, idiomatically building argument arrays, and generating reusable interaces for common system commands. - Tracing and introspection facilities for logging and latency analysis. - Safety: does not monkeypatch external modules, encourage mixins or use eval. Attempts to guide developers away from unsafe practices like shell scripts and shell injection.

StratoEnv populates ENV from one or more AWS SSM Parameter Store paths. Multiple paths form layers, with later paths overriding earlier ones, so you can split common config from node-specific or environment-specific overrides. No Rails dependency; works in Rails, Sinatra, Lambda, scripts, or any Ruby boot process.

ROS Ruby Client: rosruby ======= [ROS](http://ros.org) is Robot Operating System developed by [Willow Garage](http://www.willowgarage.com/) and open source communities. This project supports ruby ROS client. You can program robots by ruby, very easily. **Homepage**: http://otl.github.com/rosruby **Git**: http://github.com/OTL/rosruby **Author**: Takashi Ogura **Copyright**: 2012 **License**: new BSD License **Latest Version**: 0.2.0 Requirements ---------- - ruby (1.8.x/1.9.x) - ROS (electric/fuerte) - ROS requires python2.7 or more libraries Let's start --------------- Install ROS and ruby first. ROS document is [http://ros.org/wiki/ROS/Installation](http://ros.org/wiki/ROS/Installation) . You can install ruby by apt. ```bash $ sudo apt-get install ruby ``` Download rosruby into your ROS_PACKAGE_PATH. ````bash $ git clone git://github.com/OTL/rosruby.git ``` please add RUBYLIB environment variable, like below (if you are using bash). ```bash $ echo "export RUBYLIB=`rospack find rosruby`/lib" >> ~/.bashrc $ source ~/.bashrc ``` To use with precompiled electric release ----------------------- If you are using precompiled ROS distro, use the msg/srv generation script (rosruby_genmsg.py) If you are using ROS from source, it requires just recompile the msg/srv packages by rosmake rosruby. ```bash $ rosrun rosruby rosruby_genmsg.py ``` This converts msg/srv to .rb which is needed by sample programs. If you want to make other packages, add package names for args. For example, ```bash $ rosrun rosruby rosruby_genmsg.py geometry_msgs nav_msgs ``` Sample Source -------------- ## Subscriber ```ruby #!/usr/bin/env ruby require 'ros' require 'std_msgs/String' node = ROS::Node.new('/rosruby/sample_subscriber') node.subscribe('/chatter', Std_msgs::String) do |msg| puts "message come! = \'#{msg.data}\'" end while node.ok? node.spin_once sleep(1) end ``` ## Publisher ```ruby #!/usr/bin/env ruby require 'ros' require 'std_msgs/String' node = ROS::Node.new('/rosruby/sample_publisher') publisher = node.advertise('/chatter', Std_msgs::String) msg = Std_msgs::String.new i = 0 while node.ok? msg.data = "Hello, rosruby!: #{i}" publisher.publish(msg) sleep(1.0) i += 1 end ``` Note ---------------- Ruby requires 'Start with Capital letter' for class or module names. So please use **S**td_msgs::String class instead of **s**td_msgs::String. Try Publish and Subscribe ---------------------- You needs three terminal as it is often for ROS users. Then you run roscore if is not running. ```bash $ roscore ``` run publisher sample ```bash $ rosrun rosruby sample_publisher.rb ``` run subscription sample ```bash $ rosrun rosruby sample_subscriber.rb ``` you can check publication by using rostopic. ```bash $ rostopic list $ rostopic echo /chatter ``` Try Service? ---------------------- ```bash $ rosrun rosruby add_two_ints_server.rb ``` run client with args ('a' and 'b' for roscpp_tutorials/TwoInts) ```bash $ rosrun rosruby add_two_ints_client.rb 10 20 ``` and more... ---------------------- You need more tools for testing, generating documentations. ```bash $ sudo apt-get install rake gem $ sudo gem install yard redcarpet simplecov ``` do all tests ------------------------- run roscore if is not running. ```bash $ roscore ``` and run the unit tests. ```bash $ roscd rosruby $ rake test ``` documents -------------------------- you can generate API documents using yard. Document generation needs yard and redcarpet. You can install these by gem command like this. ```bash $ gem install yard redcarpet ``` Then try to generate documentds. ```bash $ rake yard ``` You can access to the generated documents from [here](http://otl.github.com/rosruby/doc/).

# StudioGame (Alec) Jogo de terminal em Ruby com **jogadores, dados, tesouros e variações de jogadores** (Clumsy e Berserk), empacotado como gem. > Nome do gem (exemplo): `studio_game_alec` --- ## 🚀 Instalação e execução ### Rodando direto do código-fonte No diretório do projeto: ```bash ruby bin/studio_game ``` Se você não passar um arquivo de jogadores via CLI, o script usa o `players.csv` que fica em `bin/` por padrão. Também funciona passando um CSV na linha de comando: ```bash ruby bin/studio_game my_favorite_players.csv ``` ### Como gem (local) Empacote e instale localmente: ```bash gem build studio_game.gemspec gem install studio_game_alec-<versao>.gem ``` Depois rode: ```bash studio_game ``` > No Windows, o executável será resolvido pelo RubyGems. Se preferir, rode: `ruby bin/studio_game`. --- ## 📁 Estrutura do projeto ``` games/ ├─ bin/ │ ├─ studio_game # script principal (tem shebang) │ └─ players.csv # CSV padrão (nome,vida) ├─ lib/ │ └─ studio_game/ │ ├─ auditable.rb │ ├─ berserk_player.rb │ ├─ clumsy_player.rb │ ├─ die.rb │ ├─ game.rb │ ├─ game_turn.rb │ ├─ loaded_die.rb │ ├─ playable.rb │ ├─ player.rb │ └─ treasure_trove.rb ├─ spec/ │ └─ studio_game/ # specs RSpec ├─ LICENSE ├─ README.md └─ studio_game.gemspec ``` - **Namespace:** todo o código vive dentro do módulo `StudioGame` para evitar colisões. - **bin/studio_game:** script CLI com shebang (`#!/usr/bin/env ruby`). Faz _fallback_ do `$LOAD_PATH` para `lib` quando usado fora da gem. - **lib/studio_game/**: código da biblioteca (classes/módulos). - **spec/**: testes RSpec. --- ## 🧩 Conceitos principais - **Player** (`player.rb`): representa um jogador com `name`, `health`, coleta tesouros e calcula `score` (= `health` + `points`). Inclui o mixin **Playable**. - **Playable** (`playable.rb`): mixin com `w00t`, `blam` e `strong?` (altera/consulta `health` via getters/setters). - **TreasureTrove** (`treasure_trove.rb`): define `Treasure = Struct.new(:name,:points)` e a constante `TREASURES`; possui `.random`. - **Die/LoadedDie** (`die.rb`, `loaded_die.rb`): rolam valores (o carregado favorece 1,1,2,5,6,6). Ambos incluem **Auditable**. - **Auditable** (`auditable.rb`): imprime “Rolled a X (DieClass)” após cada rolagem. - **Game** (`game.rb`): agrega jogadores, carrega CSV, executa rodadas, soma pontos e salva _high scores_. - **GameTurn** (`game_turn.rb`): executa a lógica de um turno para um jogador (rola dado, aplica `blam/w00t/skip` e concede tesouro). - **ClumsyPlayer / BerserkPlayer**: variações de `Player` que modificam comportamento de `w00t` e de coleta de tesouros. --- ## 🧪 Testes Rode todos os testes: ```bash rspec ``` Principais coisas testadas: - Ordenação de jogadores por `score` (usa `<=>` em `Player`). - Cálculo de `points` e `score` (soma de tesouros + vida). - Efeitos de `w00t`/`blam` e força (`strong?`). - Lógica de turno com _stubs_ de dado (`allow_any_instance_of(LoadedDie).to receive(:roll).and_return(n)`). - Comportamentos de `ClumsyPlayer` e `BerserkPlayer`. --- ## 📦 CSVs e caminhos - `bin/studio_game` resolve o CSV padrão assim: ```ruby default_player_file = File.join(File.dirname(__FILE__), 'players.csv') game.load_players(ARGV.shift || default_player_file) ``` - Você pode passar um arquivo `.csv` via CLI como primeiro argumento. Formato do CSV: ``` Moe,100 Larry,60 Curly,125 ``` --- ## 🧾 High Scores Após sair do loop, o jogo grava `high_score.txt` com as entradas ordenadas. Cada linha é formatada por `Game#high_score_entry`: ``` <nome com padding de pontos> <score> ``` --- ## 🛠️ Dicas de desenvolvimento - Use `require 'studio_game/arquivo'` quando a gem estiver instalada. - No script binário, o `begin/rescue LoadError` faz _fallback_ para `$LOAD_PATH` local, útil fora da gem. - Para debugar I/O em testes, o spec redireciona `STDOUT` (`$stdout = StringIO.new`). --- ## 📚 Licença MIT – veja o arquivo `LICENSE`.

# Quick Start The Owner API uses the JSON format, and must be accessed over a [secure connection](https://en.wikipedia.org/wiki/HTTPS). Let’s assume that the access token provided by your account manager is “TOKEN”. Here’s how to get the list of ids of all your invoices from the first week of August with a shell script: ```bash query="end_date=2018-08-08T00%3A00%3A00%2B00%3A00&start_date=2018-08-01T00%3A00%3A00%2B00%3A00" curl -i "https://api-eu.getaround.com/owner/v1/invoices?${query}" \ -H "Authorization: Bearer TOKEN" \ -H "Accept:application/json" \ -H "Content-Type:application/json" ``` And here’s how to get the invoice with the id 12345: ```bash curl -i "https://api-eu.getaround.com/owner/v1/invoices/12345" \ -H "Authorization: Bearer TOKEN" \ -H "Accept: application/json" \ -H "Content-Type: application/json"" ``` See the [endpoints section](#tag/Invoices) of this guide for details about the response format. Dates in request params should follow the ISO 8601 standard. # Authentication All requests must be authenticated with a [bearer token header](https://tools.ietf.org/html/rfc6750#section-2.1). You token will be sent to you by your account manager. Unauthenticated requests will return a 401 status. # Pagination The page number and the number of items per page can be set with the “page” and “per_page” params. For example, this request will return the second page of invoices, and 50 invoices per page: `https://api-eu.getaround.com/owner/v1/invoices?page=2&per_page=50` Both of these params are optional. The default page size is 30 items. The Getaround Owner API follows the [RFC 8288 convention](https://datatracker.ietf.org/doc/html/rfc8288) of using the `Link` header to provide the `next` page URL. Please don't build the pagination URLs yourself. The `next` page will be missing when you are requesting the last available page. Here's an example response header from requesting the second page of invoices `https://api-eu.getaround.com/owner/v1/invoices?page=2&per_page=50` ``` Link: <https://api-eu.getaround.com/owner/v1/invoices?page=3&per_page=50>; rel="next" ``` # Throttling policy and Date range limitation We have throttling policy that prevents you to perform more than 100 requests per min from the same IP. Also, there is a limitation on the size of the range of dates given in params in some requests. All requests that need start_date and end_date, do not accept a range bigger than 30 days. # Webhooks Getaround can send webhook events that notify your application when certain events happen on your account. This is especially useful to follow the lifecycle of rentals, tracking for example bookings or cancellations. ### Setup To set up an endpoint, you need to define a route on your server for receiving events, and then <a href="mailto:owner-api@getaround.com">ask Getaround</a> to add this URL to your account. To acknowledge receipt of a event, your endpoint must: - Return a `2xx` HTTP status code. - Be a secure `https` endpoint with a valid SSL certificate. ### Testing Once Getaround has set up the endpoint, and it is properly configured as described above, a test `ping` event can be sent by clicking the button below: <form action="/docs/api/owner/fire_ping_webhook" method="post"><input type="submit" value="Send Ping Event"></form> You should receive the following JSON payload: ```json { "data": { "ping": "pong" }, "type": "ping", "occurred_at": "2019-04-18T08:30:05Z" } ``` ### Retries Webhook deliveries will be attempted for up to three days with an exponential back off. After that point the delivery will be abandoned. ### Verifying Signatures Getaround will also provide you with a secret token, which is used to create a hash signature with each payload. This hash signature is passed along with each request in the headers as `X-Drivy-Signature`. Suppose you have a basic server listening to webhooks that looks like this: ```ruby require 'sinatra' require 'json' post '/payload' do push = JSON.parse(params[:payload]) "I got some JSON: #{push.inspect}" end ``` The goal is to compute a hash using your secret token, and ensure that the hash from Getaround matches. Getaround uses an HMAC hexdigest to compute the hash, so you could change your server to look a little like this: ```ruby post '/payload' do request.body.rewind payload_body = request.body.read verify_signature(payload_body) push = JSON.parse(params[:payload]) "I got some JSON: #{push.inspect}" end def verify_signature(payload_body) signature = 'sha1=' + OpenSSL::HMAC.hexdigest(OpenSSL::Digest.new('sha1'), ENV['SECRET_TOKEN'], payload_body) return halt 500, "Signatures didn't match!" unless Rack::Utils.secure_compare(signature, request.env['HTTP_X_DRIVY_SIGNATURE']) end ``` Obviously, your language and server implementations may differ from this code. There are a couple of important things to point out, however: No matter which implementation you use, the hash signature starts with `sha1=`, using the key of your secret token and your payload body. Using a plain `==` operator is not advised. A method like secure_compare performs a "constant time" string comparison, which renders it safe from certain timing attacks against regular equality operators. ### Best Practices - **Acknowledge events immediately**. If your webhook script performs complex logic, or makes network calls, it’s possible that the script would time out before Getaround sees its complete execution. Ideally, your webhook handler code (acknowledging receipt of an event by returning a `2xx` status code) is separate of any other logic you do for that event. - **Handle duplicate events**. Webhook endpoints might occasionally receive the same event more than once. We advise you to guard against duplicated event receipts by making your event processing idempotent. One way of doing this is logging the events you’ve processed, and then not processing already-logged events. - **Do not expect events in order**. Getaround does not guarantee delivery of events in the order in which they are generated. Your endpoint should therefore handle this accordingly. We do provide an `occurred_at` timestamp for each event, though, to help reconcile ordering.

No description provided.

No description provided.