all, I have a client application which is a sinatra app, but that's only part of it, some other parts will do related work like download so need to spawn in a new process, this is mostly required the gem dependencies of the same client project, so I of course using some code to load in the bundler environment:
Dir.chdir(File.expand_path(File.dirname(__FILE__)))
ENV["BUNDLE_GEMFILE"] = File.expand_path("../Gemfile", __FILE__)
require 'bundler'
env = ENV['RACK_ENV'] || 'development'
Bundler.setup
Bundler.require :default, env.to_sym,
but unfornately even with no code,like
puts 3,the sinatra app will starts and listens on 4567 which is quite irritating,
I also tried modular approach to write in the file an empty class
class MyApp < Sinatra::Base;
end
but still sinatra starts on 4567, which is
quite irritating,
do I have a way not to start sinatra? Thanks.
Find out the problem,
because in Gemfile, is:
gem "sinatra",
better use
gem "sinatra", :require =>"sinatra/base"
instead.
Related
Consider the following simple Sinatra application:
require 'sinatra'
post '/user/login' do
# login logic...
end
When deploying the application to a production environment, the url /user/login is usually changed to something else, i.e., /nitro/nutcracker/v1/user/login. And of course, the Sinatra app will not serve this url.
To cut the unwanted prefix, I've considered using a filter (i.e., before block), and routes with regex (i.e., get /*/user/login), but surely there are better solutions?
What say you?
You can mount it with rack. On the production server, create a config.ru file, and put this inside:
require_relative 'my_app.rb'
map('/nitro/nutcracker/v1/') { run Sinatra::Application } # Or your class, if it's modular
This will prefix the entire app with /nitro/nutcracker/v1/.
Then you run the server with rackup, or your application server might have a command line argument to pass a rack config file.
Am I correct that within Sinatra there is no use or mention of SINATRA_ENV? For some reason I thought there was. Here's what I think is true now:
Sinatra bases its sense of environment on RACK_ENV. If RACK_ENV is not defined it defaults to development.
If you use ActiveRecord you will also need to set RAILS_ENV because Rails modules don't pay attention to RACK_ENV and certainly not to SINATRA_ENV
Can someone corroborate this analysis?
You are mostly correct. Some developers will build a SINATRA_ENV into their applications (and set RACK_ENV to it), but it is not built into the library. Sinatra 2.0 is introducing APP_ENV, which will be preferred over RACK_ENV.
ActiveRecord appears to check RACK_ENV if RAILS_ENV is not set, so you shouldn't need to set RAILS_ENV manually. This could potentially be a problem with Sinatra 2.0, so that's something to keep in mind. A simple workaround would be to set RACK_ENV to APP_ENV for backwards compatibility with other gems, or vice-versa.
Within Sinatra applications, classic and modular, you should be using environment (or self.environment in helpers and routes) and convenience methods such as development?, production?, etc. instead of inspecting the environment variables explicitly. I've taken to using Sinatra::Base.environment (and the aforementioned convenience methods) outside of my application(s) once Sinatra is loaded. For example:
# Gemfile
gem 'sinatra', require: 'sinatra/base' # in default group
group :development do
# ..
end
group :production do
# ..
end
And:
# config.ru
require 'bundler/setup'
Bundler.require :default # this loads Sinatra, which inspects e.g. RACK_ENV
Bundler.require Sinatra::Base.environment
It bears keeping in mind that Sinatra is a tiny, tiny library (last time I checked, about 2K LOC), and it really does leave a lot of these application concerns in the hands of the developer. There aren't many hard and fast rules!
I have been trying to delve into how sinatra works, and most recently I've been trying to figure out how sinatra starts the server after processing the routes, when it is required at the top of the file. I was looking at this tutorial and they end with an example app looking like this (their version of sinatra is called nancy):
# app.rb
# run with `ruby app.rb`
require "./nancy"
get "/" do
"Hey there!"
end
Rack::Handler::WEBrick.run Nancy::Application, Port: 9292
I am wondering how you are not forced to include that last line in sinatra.
Sinatra does that by defining an at_exit callback, see main.rb
This basically says "when the ruby script is done and exits, then run the Sinatra app!"
For more information see the ruby docs for at_exit!
For serving a sinatra application you just need to execute ruby app.rb on shell.
app.rb
# install sinatra gem before everything
# by typing `gem install sinatra`
# on shell. or add sinatra to your Gemfile
# then execute bundle install
require 'sinatra'
get '/' do
"Hey there"
end
Then you'll see such output
$ ruby app.rb
Puma 2.11.3 starting...
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://localhost:4567
== Sinatra (v1.4.7) has taken the stage on 4567 for development with backup from Puma
The tutorial you've been appealing at is not about the actual sinatra - there author have built his/her own pseudo-sinatra. By the way, ruby also have a microframework called nancy
To run his/her pseudo-sinatra successfully, you need to follow the tutorial from beggining to end.
Can I use memcachier with ZendFramework 1.12 ?
The provider that I am useing(AppFog) only offers Memcachier (Memcached is comming soon from 10 Months) And My app will need a lot of caching when it starts. I don't want to stick with APC so I have no other good alternative.
So this is just a half answer right now, I'll try to figure out the rest. I work for MemCachier by the way, so please shoot us an email on support#memcachier.com if you have more questions.
PHP includes two memcache bindings by default: memcache and memcached. The first one (memcache) is its own implementation of the memcache procotol, while the second one (memcached) is a php binding to the libmemcached C++ library.
The memcached binding for php does support SASL these days (since version 2.0.0). Sadly it isn't documented. It also is an optional part of the memcached module, so you'll need to make sure it is compiled on your machine (or AppFog) with the SASL support enabled. The steps to do that roughly are:
Install libmemcached. I used version 1.0.14.
Install php-memcached. Make sure to pass the "--enable-memcached-sasl" option to it when running ./configure.
When building both of these you can sanity check the output of "./configure" to make sure that SASL support is indeed enabled, sadly right now it can be tricky.
Edit you php.ini file. Put the following line into it:
[memcached]
memcached.use_sasl = 1
I did all of this on OSX 10.8 using homebrew. If that is the case for you the following should work:
$ brew install libmemcached
$ brew edit php54-memcached
// you'll need to add the line:
args << "--enable-memcached-sasl"
// to the brew file.
$ brew install php54-memcached
Now to actually use SASL support, here is a test file that demonstrates it and is a good sanity check.
<?php
/**
* Test of the PHP Memcached extension.
*/
error_reporting(E_ALL & ~E_NOTICE);
$use = ini_get("memcached.use_sasl");
$have = Memcached::HAVE_SASL;
echo "Have SASL? $have\n";
echo "Using SASL? $use\n\n";
$mc = new Memcached();
$mc->setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$mc->setSaslAuthData("user-1", "pass");
$mc->addServer("localhost", 11211);
$mc->set("foo", "Hello!");
$mc->set("bar", "Memcached...");
$arr = array(
$mc->get("foo"),
$mc->get("bar")
);
var_dump($arr);
?>
Adapting this to work in the Zend Framework is unknown to me right now. I'm not familiar with it so may take me some time to install and figure out. It seems very doable though given one of the backends works with SASL auth.
After I touch tmp/restart.txt and my app restarts, the first request throws an error, usually something about not finding Haml::Engine or some other gem. The second and subsequent requests all work fine. I was having this problem on Dreamhost which was running Rack 0.4.1 and Sinatra 0.3.3 but after moving to my own host and running a newer Rack (0.9.1) and Sinatra (0.9.0.4) I still see the problem.
If you don't know the exact answer but have tips on how I could track it down, please let me know.
Here's my config.ru:
require 'rubygems'
require 'sinatra'
disable :run
set :environment, :production
set :raise_errors, true
require 'app.rb'
run Sinatra::Application
I'd look into making sure you're requiring all the necessary gems. Perhaps there's something about the order you're doing it that's causing it to fail the first time. Are you requiring rubygems?
It might also help if you posted your rack configuration for the app (config.ru).
The error is caused by the Sinatra gem loading too late. This is the solution:
#config.ru
ENV['GEM_HOME'] ||= `gem env path`.strip.split(':').first
ENV['GEM_PATH'] ||= `gem env path`.strip
Gem.clear_paths
require 'application-filename-goes-here'
set :environment, :production
run Sinatra::Application