`net.Server#listen()` helper that returns a Promise for async / await
Rails UJS for the react-rails gem
bootstrap-sass is a Sass-powered version of Bootstrap 3, ready to drop right into your Sass powered applications.
A framework for responsive emails
Cross-language temporary (disposable/throwaway) email detection library. Covers hundreds fake email providers.
The realtime engine behind Socket.IO. Provides the foundation of a bidirectional connection between client and server
TypeScript definitions for test-listen
A minimal node SOAP client
Unobtrusive scripting adapter for jQuery
A JavaScript library for escaping CSS strings and identifiers while generating the shortest possible ASCII-only output.
mcp-ui Client SDK
Listen to realtime updates to your PostgreSQL database
mcp-ui Server SDK
Produce URLs to test HTTP servers with ephemeral ports
An onClickOutside wrapper for React components
Companion package for the cocoon Ruby gem.
wait-on is a cross platform command line utility and Node.js API which will wait for files, ports, sockets, and http(s) resources to become available
An implementation of Amazon's DynamoDB built on LevelDB
RailsAdmin is a Rails engine that provides an easy-to-use interface for managing your data.
A message bus client in Javascript
VSCode JSON RPC over WebSocket
Warning and invariant dev-ex messaging.
Client Side Validations made easy for your Rails 7.2 and 8.x applications
Native ES6 @mentions
Automatically restart Rails server when you hack gem for experiments. You can use it for quick 'scientific' experiments with Rails core or gems.
Heel is a small static web server for use when you need a quick web server for a directory. Once the server is running, heel will use (https://rubygems.org/gems/launchy/) to open your browser at the URL of your document root. Run it right now! `gem exec heel` ----- Heel is built using (https://github.com/rack/rack) and (https://puma.io) % heel Launching your browser... Puma starting in single mode... * Puma version: 6.2.1 (ruby 3.2.2-p53) ("Speaking of Now") * Min threads: 0 * Max threads: 5 * Environment: none * PID: 11322 * Listening on http://0.0.0.0:4331 Use Ctrl-C to stop Or run it in the background % heel --daemonize Launching your browser at http://0.0.0.0:4331/ % heel --kill Sending TERM to process 3304 Done.
The DevCreek gem enables programmers to collect and transmit metrics from their Ruby Test::Unit and RSpec test suites to a DevCreek server. Please visit the DevCreek site (http://devcreek.com/index.html) for more info. == FEATURES/PROBLEMS: Supported frameworks include Test::Unit and RSpec (> 1.10). == SYNOPSIS: The DevCreek Ruby Gem is library that, when loaded, will automatically listen to and collect metrics from your Test::Unit/RSpec unit tests. All you have to do is load the DevCreek library in your code and give it your DevCreek account info so that it can transmit the metrics to the server. Here is the simplest example of how to load DevCreek: -------- #Load the devcreek gem require 'rubygems' require 'devcreek' #set your account info DevCreek::Core.instance().load_from_yaml("#{ENV['HOME']}/.yoursettingsfile.devcreek.yml") -------- There are two ways to provide DevCreek with your account settings. The first (as shown above) is to point DevCreek to a settings file. The 'enabled' attribute tells devcreek whether or not it should actually transmit the metrics that it collects. The yaml file would like this: -------- user: your_devcreek_username password: your_devcreek_password project: your_devcreek_project enabled: true -------- The other way to provide DevCreek with your settings is via a hash. So, instead of loading a yaml file, you could do this: -------- #Load the devcreek gem require 'rubygems' require 'devcreek' #set your account info DevCreek::Core.instance().load( :user => 'your_devcreek_username', :password => 'your_devcreek_password', :project => 'your_devcreek_project', :enabled => true ) -------- The first method is preferrable because it allows you to keep your account settings outside of your project (and therefore your source control tool). If you only have 1 test file, you can place the code to load devcreek in the test file and your done. However, most projects will have many test files. In this case, you need to make sure that the Ruby interpreter loads devcreek before running the test classes. This can be done via the Ruby '-r' option. For example, assuming your code to load devcreek is in a file called foo.rb, you would run your tests from the command line like this: ruby -r foo.rb test/test_* If you run your tests from a Rakefile, then you need to tell rake to include the -r option when it runs the tests (rake runs it's tests in a separate Ruby process). You can do this pretty easily in your Rakefile, like so; -------- require 'rake/testtask' Rake::TestTask.new('all_tests') do |t| t.ruby_opts = ['-r foo.rb'] t.test_files = ['test/test_*.rb'] end --------