Forgive me if this is a noob question with an obvious answer, but what's the point of using rack-flash in Sinatra?
It feels like rack-flash functionality could easily be written yourself and a gem is a little overkill. Is there something Rack provides that I'm missing?
The README addresses this:
flash[:notice] = "You can stop rolling your own now."
It feels like rack-flash functionality could easily be written yourself and a gem is a little overkill. Is there something Rack provides that I'm missing?
Yes:
It's distributed as a gem, so you don't have to copy your flash implementation across projects. This reusability is key.
The interface is consistent with Rails, so future maintainers of your code won't have to study your idiosyncratic implementation.
It's well tested and developed in a community.
You're not wasting your time reinventing a small cog.
Unless your app's core functionality is flashing messages, this little ~100 SLOC gem that provides the above benefits is hardly overkill.
I just add a message to my session data and flash it if it's there. That's what rack-flash does too. I looked at it once and the time I need to look up its API is the time I need to write it myself over and over again. Maybe I'm missing something here but iirc one of the flash gems broke over some Sinatra update and that's where the pain starts if you depend on a gem.
Related
Is Ruby primarily only used in ruby on rails? Is it used on the server side for general work like php is? Also, I haven't seen a lot of hype about rails anymore. Is Ruby and/or RoR dead or fading away?
I ask because I was interested in RhoMobile for building mobile apps, but I didn't want to get into using an antiquated language.
Thanks.
edit: Can i use Ruby for web pages if I don't want to use rails? (I do not mean another framework. I mean like php.)
Regarding your question about Ruby and/or RoR dead or fading away, look at the job trends
There are many web-frameworks for Ruby, not just Rails, Sinatra being one of them.
You shouldn't be deciding to use a language or technology, because there is or there is not a hype around it.
If a product is able to solve your problems, then you should use it. I know people building stuff in Smalltalk nowadays (who would have thought, right?), because it's great and it works.
Take a look at Sinatra, for example.
Also there is a lot of tools written entirely in ruby.
any usable ruby code to interact with the safe browsing API from google?
i did search at google but i didn't find any mature and solid code.
I have 3 points:
(0) I'd say that This looks alright, as does this
(1) Having used quite a few ruby gems for various obscure things, I find bugs all the time. It helps the open source community and the world if you find a gem, fix a bug, and let the rest of the world benefit by submitting a pull request. Tests make the life of a contributor sooooooooooo much easier, and guarantee that your fix works, so use gems with extensive tests where possible, even if they are not mature and you half-expect them to fail.
(2) From experience, gems which have lots of objects encapsulating something can sometimes be counterproductive. This has tripped me up in the case of the ruby mail gem and the tire gem (though that's not to say that they are not good and incredibly useful gems.). This applies to you if you only need to make one type of API call, say, and take a simple action. Using the simplest gem is sometimes advantageous, and for this purpose you might not need to use any gem at all! Just write a class that uses Net::HTTP to call the HTTP API: https://developers.google.com/safe-browsing/lookup_guide
My feeling is that the differences between Camping and Sinatra are not very significant and that you could safely choose either one and be ok. But I want to ask the Ruby experts if this is true. Are there in fact any important differences between the Sinatra and Camping microframeworks? And how would you go about deciding which one to use?
The only significant difference that I'm aware of is that Camping is based around the MVC pattern like rails, and is coupled to ActiveRecord. Sinatra is more agnostic.
Camping also is no longer maintained, while Sinatra is under active development. That alone is probably reason enough to look at Sinatra first.
edit: Thank you for the correction Philippe, and great to hear that Camping development is ongoing. Apologies for indicating otherwise.
One thing to consider is that Camping is somewhat of a golf exercise. It was 4k but judofyr has gotten it down to 3k. Try reading the source, I dare you. Now, there's also the unabridged version which gives you decent comments, but the code itself is still painfully obfuscated.
With Sinatra you can pretty comfortably dig into the internals and find idiomatic ruby. That's pretty darn important, IMHO, especially if you ever need to patch something.
(Keep in mind that Camping is eccentric by design, I'm not aiming to pass judgment.)
Camping is being maintained. Since _why was concentrating on Hackety-Hack/Shoes until he kind-of-vanished, and (as semanticart writes above) Magnus Holm (judofyr) has been working on Camping. The unabridged version has some useful documentation. It works fine for me and, although I've yet to really stretch it, some Camping apps out there (like Cheat) run fine.
You might also like to check What are the main differences between Sinatra and Ramaze? which has some useful links to Sinatra and other lightweight Ruby frameworks.
For reasons beyond my control, I'm being tasked with Ruby web development that does NOT use Rails or really any other heavyweight framework such as Merb. I'm wondering if anybody else has encountered this and can recommend best practices or resources that describe best practices for such a problem. I'd like to avoid the dreaded
out.print('<td class="foo">'+some_data+'</td>')
style of web development. A coworker has suggested Rack as a light framework but the documentation is sketchy and it seems unproven in the market.
Take a look at Sinatra. It's a framework, but not that heavy.
Look at Rack and Sinatra or Waves. Rack is not unproven in the market. Rails is built on top of rack these days! It also isn't a framework, it allows frameworks to focus on their differentiator rather than the low level busy work.
You can also use jruby and the java servlet api directly. btw, all the rack based frameworks can easily be run on jruby.
Rack isn't an application framework so much as a server interface. You will probably want to use it for this project, but it won't solve your problem of wanting a framework without using a framework. At any rate, if you want to "avoid the dreaded out.print('<td class="foo">'+some_data+'</td>')", you're going to have to use a template system at the very least. There are many available, such as ERb (which Rails uses by default) and Haml.
Go with Ramaze. I'm using it in production, running on JRuby and Glassfish.
Ease of development, rock-solid community support. No cruft. Like Ruby, it gets out of your way.
I can join in with everyone who's recommend Sinatra. It's compact, a joy to code with, and it deploys on Rack, which means you really get it running in whatever stack you fancy most (Mongrel, FCGI, Thin, Passenger, etc.)
I tried out Sinatra when I needed to get a project up fast and it's scaled & performed so well that I'm still using it today to handle over 80,000 heavy requests a day.
As always good ol' cgi.rb is available.
Have you had a look at Sinatra? It is a framework, but not as heavy as Rails. I haven't tested it out myself, but it seems to be very easy to work with.
Also, Ramaze seems to be nice and modular, not sure if it is what you look for though.
I don't know how easy it is to use Ruby directly as a cgi, but it should be quite possible to separate layout from code with that as well. There are quite a few Gems that can do that without using a framework.
My personal choice and recommendation is Ramaze -- it's as simple as possible, but no simpler. Clean and concise without sacrificing power. Dances well with your choice of JS lib (jQuery, Prototype, Mootools) or ORM (Sequel, Datamapper, M4DBI) or templating engine. Also, don't forget about static generators like nanoc.
It's very possible, my entire website runs on pure ruby.
I haven't encountered any problem. I begin my application with
require "mysql" # module | mysql
require "cgi" # module | cgi
require "date"
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Have you used Sinatra successfully? What kind of a project was it? In what situations would you recommend using Sinatra instead of Rails or Merb?
I've dabbled with Sinatra, but haven't really written anything serious with it.
As you said above, there's a list at http://www.sinatrarb.com/wild.html, although a lot of the applications listed there seem to link to GitHub pages, which I assume are often people experimenting with Sinatra and publishing their results online. Then, there's also the Sinatra mailing list, where you might find links to some interesting projects.[*]
As for your question on when to use Sinatra, I personally would answer "for smaller projects." When you want something up and running very quickly, it seems like Sinatra is an excellent choice. It's also great for people who like Ruby. With that I mean, when you're doing something in Rails, you have to do it "The Rails Way". Rails is the framework upon which you're building your application, and you have to adhere to its customs and conventions. Sinatra, on the other hand, feels like a library. You feel like you're writing Ruby, if you want to connect to a database, you use the library you like/think is appropriate for the job, if you want to output HTML you choose the templating library you like, and if you want a simple web framework, you choose Sinatra. Sinatra is not something upon which you build your whole application, it's something you use beside the rest of your application.
So, as you may have gathered, I'm quite fond of Sinatra, and I would use it for personal (or small-scale) projects. It's easy to set up and easy to use, as long as you know what you're doing. Looking through http://www.sinatrarb.com/wild.html, it seems like that's what most people are using it for, see for example Is Lost on yet? and Calendar About Nothing.
[*] Edit: I found a thread here, with people linking to their projects. There seem both larger and smaller projects. Very interesting stuff.
There is a list at http://www.sinatrarb.com/wild.html.
Still, I'd like to hear a bit more about them. I also suspect that there are lots of successful Sinatra projects outside that list.
I just released TweepDiff (http://tweepdiff.com) written in Sinatra. Anything else would have been overkill but I would use Sinatra for bigger projects too.
I think sinatra is best suited for micro-applications development (no big surprise, it's a micro-framework)
Sinatra provides you with a sufficient level of abstraction to build almost everything you want quickly. And what I like about sinatra is that the framework gives you tight control over what your app is actually doing, you can really "feel" what you are writing. So, I would say Sinatra is a subtly balanced framework.
I also think Sinatra is attractive for "people who likes writing Ruby" as said before. You start writing ruby class before implementing a sinatra interface. (good exemple of this kind of workflow here : http://dev-logger.blogspot.com/2009/01/ric-rac-roe-in-soup-of-technologies.html)
I wanted to be able to run succinct self-contained Ruby scripts from my web server. As far as functionality goes, it would be similar to a CGI library. Sinatra was perfect. One sinatra app later and I have a collection of scripts accessed through simple sinatra style routes.
Whenever I need to write a web application that doesn't depend on a database, I suspect sinatra will be my first port of call.
I'd have to echo most of the above comments. We're in the process of implementing a Sinatra/HAML stack for browsing and basic reporting on data.
I really like the combination of simplicity and direct connection to Ruby. If something isn't working in the browser, it's pretty easy to port it out to a straight Ruby program for debugging.
There's definitely a feeling of building a dog house with Sinatra versus the Taj Mahal with Rails. It's easy to comprehend (it's also helping me understand the need for MVC and Rails).
Altogether very cool stuff and very fast. I haven't stressed it yet, so I can't say how well it'll behave in the real world.
I made http://istay.com using sinatra, all I can say is that it is a fantastic little framework for any site that doesn't directly use or doesn't have a database.
Though I do feel sinatra has reach it's limit with the current site, and any extensions will be written using Rails or other framework.
I use Sinatra for small 'one function' kinds of apps (My current blogging engine might be a good example). I think the simplicity of Sinatra works best for little utilities and basic API front-ends (Twitter apps, etc).
For larger scale apps there is even the Sinatra-based Padrino Framework with some of the niceties that you would usually reach for Rails to provide.