I should have specified that, I do not necessarily think it is a bad product, but it did frustrate me a lot when trying to set it up. I'm sure it has saved a lot of developers time, but I speak for myself and myself alone, and the cost-benefit for me was way off.
Same here. I am planning my wedding, and Pinterest has been invaluable! Protip: If you can find the founders email (I can't remember of the top of my head), you can ask for an invite directly, instead of rotting away on the invite list.
"Based on the _libpurple_ protocol library, Adium can connect you to any number of messaging accounts on any combination of supported messaging services (see further down for the list) and then chat with other people using those services." (Emphasis mine)
"Libpurple is the library which provides network-level connectivity for most services in Adium. Like Adium itself, it is licensed under the GPL. In addition to Adium, libpurple is the core of the Linux and Windows IM clients Pidgin and Finch. (...)
Libpurple was previously named Libgaim. "
So yeah, Pidgin is an option, because neither Adium nor Pidgin speak IRC, libpurple does. The support should be ~the same~, of course depending on the version of the library used.
I wanted to switch to Pidgin a while back because it had support for the kind of encryption I wanted (public key) and Adium didn't, but I ended up not doing it and I thought the reason was because Pidgin doesn't do IRC.
"Pidgin is compatible with the following chat networks out of the box: AIM, ICQ, Google Talk, Jabber/XMPP, MSN Messenger, Yahoo!, Bonjour, Gadu-Gadu, IRC, Novell GroupWise Messenger, QQ, Lotus Sametime, SILC, SIMPLE, MySpaceIM, and Zephyr."[2]
Yep: Pidgen has supported IRC so long that back when I was still using it, and the project hadn't yet been renamed from Gaim, it already supported it; it had a few stupidities, and didn't support userhost-masks for buddy bindings (something that simply "makes sense" if you use IRC enough), but it definitely worked and still does (I have friends who use it all the time for IRC, and one who even contributes patches to it).
I find it surprising that Padrino hasn't gained more popularity. For me, it's perfect for the times when you need something more robust than Sinatra, but lighter than Rails. (& being Rack-based it's pretty easy to port a project to either platform if needed).
I would love to hear your take on how we can improve on the first 2 aspects. I am not too worried about Rails because I use Rails and I use Padrino but despite the increasing modularity, using Rack/Sinatra/Padrino is a qualitatively different development experience.
I think you raised one of the primary issues in your response. "Padrino is Sinatra", meaning the documentation is split between Sinatra and Padrino.
There isn't primary source for Padrino (similar to Rails Guides). Also Sinatra's documentation isn't fantastic either, I often find myself jumping between blog posts, sinatra's website, "the sinatra book" constantly.
Also Rails has a much more mature community with screen casts and blog posts being produced constantly. That is probably difficult to 'create' short of DHH style evangelism.
I agree with you that our documentation isn't as thorough as Rails guides but I would argue that the Padrino guides we do have and the blog tutorial + screencast are not a bad tool to get started. I recognize though that to get started with Padrino you do need to have some basic handle on Sinatra. I would love to improve the beginner's documentation even further and I hope that Sinatra's docs get better over time as well possibly with our help.
As Florian touches on, Padrino is fundamentally about embracing the power of modularity. Understanding Rack, Rack Middleware, Sinatra, Padrino and a suite of chosen tools does ultimately become necessary. However, like Sinatra you can also learn the basics within 15 minutes. I like to think that Sinatra/Padrino can grow with you as you need it.
If anyone reading this has any interest in helping us with documentation, please let us know. Especially if you are a beginner. We are a very open community and would love some help or even suggestions on how to make our framework more inviting.
The problem is that this would mean rewriting/covering a lot of Sinatra (although I find the sinatra book/readme pretty complete). We just haven't got the manpower for that. This is the fate of a modular framework.
On my Padrino stack, I usually have to switch between roughly 20 documentation stacks (Padrino, Sinatra, Rack, DataMapper, Warden, 2-3 template languages and a lot of other Rack Middleware), so "one more" doesn't really matter to me.
Maybe some documentation on how to work with or to learn Padrino would be wise. Well, more work for us. :)
For most consumers a internet set-top box for TV is a completely new type of technology purchase (similar to a tablet purchase). Set-top boxes don't have the "cool-factor" of other technologies (smartphones/tablets) to drive sales, and TV === Cable mentality is already ingrained, so the barrier to adoption is price. The price needs to be low enough that the consumer is willing to take the risk of adopting a new (possibly dust-collecting) gadget.
E.g. I really wanted a GoogleTV, but the price-tag was high for something I was sure I'd use a lot. Instead I got an Apple TV for $99. It doesn't have everything I want, but it suits my needs 90% of the time. (also see eBook readers)
IMO you may want to re-think emphasizing "a very polished UI", currently Geckoboard's UI is much more "polished"[1]. Instead, play up the tangible benefits over Geckoboard (realtime, data export).
Right now it looks* like rails_admin is a bit more feature complete as far as CRUD administration goes (+ history of edits). While ActiveRails has feature like comments which may be more relevant to less technical users.
* Disclaimer: I'm more familiar (and probably biased) with rails_admin
Most of the CSS3 browser compatibility came from Paul Irish's awesome CSS3please tool (http://css3please.com/). You should definitely check it out if you're coding css without a framework.
Yeah I see your point, but when I said 'one line' I meant more like 'one word.' jQuery-ahm just uses a 'ahm' class on the html link to the Ajax endpoint. like <a href='/tooltip3' class='ahm'> and that's it. The line of jQuery you wrote is still very dense.
Take bricestacey's advice, use RVM. I was in the same boat as you when getting started with Ruby - it seemed like I was always fighting with gems and other dependencies - "there has to be a better way!", I thought. And there was...
