|
shopvac4christ posted:That's what I've heard, but I haven't had a chance to actually try it. That's what I'm asking. Where are people deploying their projects? Their one-off, unimportant stuff? I'm not shelling out 400 dollars a month for an Engine Yard slice. I'm still in college, you know? Like I said, slicehost is pretty decent. You could also setup a machine in VMWare or whatever and treat it as a remote deployment box just to mess around with.
|
# ? Jun 30, 2008 16:18 |
|
|
# ? May 15, 2024 03:54 |
Oooh, a VM image is a good idea. But Slicehost is looking pretty tempting. I don't want to just run Rails apps, since I'm a Merb and Camping guy, too. I have a feeling I'll get plenty of mileage out of a VPN.
|
|
# ? Jun 30, 2008 16:42 |
|
I use slicehost, they are awesome. Highly recommended.
|
# ? Jun 30, 2008 16:45 |
|
jonnii posted:I use slicehost, they are awesome. Highly recommended. Thirded.
|
# ? Jun 30, 2008 16:53 |
|
Grob posted:No, some of us have Rails projects in production. Forumwarz, my MMO, is deployed on a dedicated host. Off-topic: Forumwarz is awesome. You guys do great stuff on the JavaScript side.
|
# ? Jun 30, 2008 16:56 |
|
I can chip in on deployment advice for medium-larger apps (no single point of failure etc.). Main stuff I've deployed: 1. Software as a service web app that just launched ( nginx load balancers/asset servers -> apache + fcgid -> memcached + replicated mysql). Only architecture that could work for us, long story. 2. Highly dynamic(uncacheable) public site (nginx -> mongrel cluster -> memcached + oracle) I love nginx & memcached. I've only deployed on dedicated/larger virtual servers, so I can't really advise for smaller slice based arrangements.
|
# ? Jul 1, 2008 13:32 |
|
savetheclocktower posted:Off-topic: Forumwarz is awesome. You guys do great stuff on the JavaScript side. Thanks, that's mostly due to Prototype and Scriptaculous making it so easy!
|
# ? Jul 2, 2008 19:45 |
|
Oh no! It all works fine on iMacs at work – no spec failures or this out of memory stuff, but my poor old macbook just can't handle it. Probably an issue with my ruby or something, but who knows. It's kinda funny just how bad it broke.
|
# ? Jul 4, 2008 08:03 |
|
Never seen anything like that. Also you have shitloads of tests going on there. How long does it take to run and why so many?
|
# ? Jul 4, 2008 13:21 |
|
I don't think that's all of the specs, because it blew up. There are a few old tests too that are slowly being moved into tests. On the dev machines, the tests+specs take about 5-6 minutes I think. That defiantly needs to be sped up. There are also about 15 min worth of selenium tests, but usually you just let the ci box run those, except for the ones you know you're hitting. The ci box is an old mac mini, and poor thing takes like 50 min to run through the specs, tests, selenium, and javascript tests. Why so many? It's a very large and complicated app. We have something like 10k lines of code and 35k of tests, though I don't think rake stats counts some of the stuff. Some could argue that it's overkill, but it just happens that way because of BDD.
|
# ? Jul 4, 2008 20:04 |
|
I have a $5/month account at https://www.railsplayground.com and host 4 small applications on it. What is all this dedicated talk, shared hosting is sufficient for a blog, band website, small business website and extraneous test or staging application. geez
|
# ? Jul 7, 2008 09:17 |
|
For those of you that use autotest (you do use autotest, don't you?), Growl configuration on OS X just got quite a bit easier: http://growl-glue.rubyforge.org/ code:
code:
|
# ? Jul 7, 2008 22:18 |
|
So I'm trying to get into programming 2.1 however a lot of material is either for rails 1.2/1.4 or some older version of rails. Is there a site that discusses the changes between previous version of Rails and what Rails is at the moment?
|
# ? Jul 8, 2008 00:51 |
|
Well, for general api reference http://rails-doc.org is awesome. Hopefully it will be as good as php.net one day. There's pretty significant jump from 2.0 to 2.1 so old 1.* rails are almost irrelevant. http://weblog.rubyonrails.org/ is pretty alright if you want to follow wtf is happening (although most of the discussion is about Edge Rails that takes a bit to become stable). But for 2.1 changes check this out: http://weblog.rubyonrails.org/2008/6/10/free-rails-2-1-book
|
# ? Jul 8, 2008 03:10 |
|
Strong Sauce posted:Is there a site that discusses the changes between previous version of Rails and what Rails is at the moment?
|
# ? Jul 8, 2008 16:15 |
|
Sup rails-goons, no idea how many of you are core wannabes, but in case the answer is 'some' - check out my request for comments for a validations refactor: http://groups.google.com/group/rubyonrails-core/browse_thread/thread/4cce3966cd61f278 (link to github contained within) I think it's a step in the right direction (well OBVIOUSLY - since i wrote it and whatnot) but I'm getting awfully tired of working on it and it sure would be nice to have some help, especially in the form of patches Did You Know: Contributing rails patches makes you ridiculously employable, and also free blowjobs.
|
# ? Jul 9, 2008 02:27 |
|
Mr. Wynand in the linked post posted:One thing that (IMO) causes a lot of confusion (in a general sense) is how .errors[:whatever] can sometimes return an array of strings, and sometimes just the string. NOTHING ELSE EVER DOES THIS IN RUBY. EVER Spot on. I hope this gets merged in. I came across a thing with AR's sql generation that I may write a patch for. I wasn't sure it'd be worth it, but if you say there'll be blowjobs, than it just might be!
|
# ? Jul 9, 2008 08:24 |
|
I have a large hash of values which is an intermediary for simpler calculations. This object needs to be stored because it takes so long to generate. I can do this with PStore but is it more advisable to use ActiveRecord, or something else? Seems a bit overkill to use relational database to store something relatively simple, but speed may be important.
|
# ? Jul 10, 2008 20:59 |
|
Carabus posted:I have a large hash of values which is an intermediary for simpler calculations. This object needs to be stored because it takes so long to generate. I can do this with PStore but is it more advisable to use ActiveRecord, or something else? Seems a bit overkill to use relational database to store something relatively simple, but speed may be important. Memcache.
|
# ? Jul 10, 2008 23:37 |
|
Pardot posted:Spot on. I hope this gets merged in. I came across a thing with AR's sql generation that I may write a patch for. I wasn't sure it'd be worth it, but if you say there'll be blowjobs, than it just might be! It's surprisingly easy to get a patch included provided you include unit tests with it. Basically you just post a ticket with the .diff file in lighthouse and then you need 3 people to review it ("+1"ing - anyone can do it - not just core peeps) which will force a core guy to look at it and include it. Depending on the severity of what you're doing this can happen over night or over a few weeks, but pretty much everything that is well tested doesn't try to do something silly (like build-in LDAP support or some poo poo, i.e. stuff that should be a plugin) makes it in eventually. For work we have our own rails branch which includes any patches we contribute before they are actually accepted. We've gotten to the point where they are equivalent several times now (i.e. all our patches, or something equivalent, makes it to upstream).
|
# ? Jul 11, 2008 01:33 |
|
Is there a way to explicitly set the id, instead of letting it auto_increment, when creating a record with AR? I'd prefer not to do this in actual SQL, but whatever if I have to I have to.
|
# ? Jul 11, 2008 02:52 |
|
manero posted:Memcache.
|
# ? Jul 11, 2008 03:30 |
|
dustgun posted:Is there a way to explicitly set the id, instead of letting it auto_increment, when creating a record with AR? I'd prefer not to do this in actual SQL, but whatever if I have to I have to. I don't know of hand, but are you absolutely sure you have to? I hate to give such a "DHH answer" but I've usually found it to be the case that no, setting the ID manually is not required. (PS: the times where it's genuinely required usually entail hardcore scale-across-a-cluster issues, and if you're having THAT kind of problem you should probably be using your oodles of VC cash to hire a core guy)
|
# ? Jul 11, 2008 03:30 |
|
Carabus posted:But memcached doesn't offer persistent storage like PStore, it is designed to be used in conjunction with something like a database. At least that's my impression. Probably I should store the thing with ActiveRecord and use memcached for long iterations. But you just said it's an intermediary value that can be regenerated If persistence is actually more important, just stick with AR it will probably be fast enough. If it's setting up the schema that bothers you and you're sure you won't ever need to retrieve your value by anything other then a single key (which sounds likely), dump the object in 1 column using yaml or something. If you really truly need something that is both ridiculously fast AND persistent you can look into 'document databases' like hadoop or couchdb. But you very very very likely don't.
|
# ? Jul 11, 2008 03:38 |
|
Mr. Wynand posted:But you just said it's an intermediary value that can be regenerated
|
# ? Jul 11, 2008 04:31 |
|
Mr. Wynand posted:I don't know of hand, but are you absolutely sure you have to? Crap, that's a horrible explaination. Eitherway, it's something I started doing and then sort of wondered if you could do it with AR
|
# ? Jul 11, 2008 04:40 |
|
Mr. Wynand posted:hire a core guy code:
|
# ? Jul 11, 2008 16:52 |
|
skidooer posted:I don't think you need a core guy for something so simple. This is bad because eventually it will randomize to an existing id and go boom. code:
Concurrency may not be a problem in your app, but this also opens it up for a race condition where you check for an id and not find it and try to set the id, but another process used up that id in the split second before you save. (more likely when the pool of available ids grows slim) I'm not saying it wrong to do something like this (I do something similar in one of my apps), but there are reasons why auto-incrementing id's are good.
|
# ? Jul 12, 2008 05:25 |
|
Lets say I have about 20 tables that include more or less each a set of options for 20 different select boxes. These will change rarely, I have set up all the functionality required to display these select boxes and show the user's selected options somewhere all over a page someplace. What is the best way to ensure there aren't 20 hits to the database on every edit request and a further 20 hits to the database on every page view where these results are displayed? I can use page caching where the results are displayed but I am a bit dumbfounded by the idea of caching the select boxes that allow the users to change these settings as they need to be pre-populated with the values the user has selected. Is the best way to just page cache on the edit page as well? Because the chances are that any time a user visits the edit page, they will be changing something that will clear the cache anyways. Nolgthorn fucked around with this message at 09:39 on Jul 18, 2008 |
# ? Jul 18, 2008 09:35 |
|
Nolgthorn posted:Lets say I have about 20 tables that include more or less each a set of options for 20 different select boxes. These will change rarely, I have set up all the functionality required to display these select boxes and show the user's selected options somewhere all over a page someplace. In your controller, cache the results from the database calls. If you're on Rails 2.1, caching is pretty easy to set up with a variety of stores (I can't recommend Memcached enough.) http://www.thewebfellas.com/blog/2008/6/9/rails-2-1-now-with-better-integrated-caching
|
# ? Jul 18, 2008 15:31 |
|
GroceryBagHead posted:Well, for general api reference http://rails-doc.org is awesome. Hopefully it will be as good as php.net one day.
|
# ? Jul 18, 2008 16:34 |
|
Tziko posted:Just a heads-up: Rails-doc 2.0 was released today. The update includes multiple improvements, including documentation for the different versions of Rails. Hopefully it'll shape up to be the php.net of Rails... Hooray, I asked them for hi res icons to use with Fluid, and they did http://rails-doc.org/about
|
# ? Jul 18, 2008 18:46 |
|
Two dirt-simple Ruby questions: 1) Let's say that I have a string that's "ENTRY9_blahblah". I need to pull out that 9 as an integer. There must be a better way to do this than either code:
code:
2) I have a bunch of numbers stored as fixed-width strings in hex. For example, I'll have "12345678abcdef01" which I want to extract as 1 number with a value of 0x12345689, 1 number with a value of 0xabcd and 1 more number with a value of 0xef01. Currently I'm doing this: code:
|
# ? Jul 20, 2008 03:45 |
|
Plastic Jesus posted:Two dirt-simple Ruby questions: (/ENTRY(.*?)_.*/.match(str))[1].to_i code:
|
# ? Jul 20, 2008 04:11 |
|
Hop Pocket posted:There might be a simpler shorthand for regexes, but you would want to use a regex instead of unpack to do this. Cool, thanks. I would probably do code:
|
# ? Jul 20, 2008 07:02 |
|
Plastic Jesus posted:Is there an easy way to find out in irb which method is faster in these situations? I'd like to know that the performance difference is for regex v. unpack v. anything else. And while we're on the subject, does Ruby use the old-style (and much faster) Bell Labs DFA regex algorithm or the weird (and slower) perl-style algorithm? code:
code:
|
# ? Jul 20, 2008 10:45 |
|
drjrock_obgyn posted:So unpack might be the fastest, but marginally. I'd use the regex for readability. Hrm, interesting. I'd not played with benchmark before. I found out that my ugly-looking current approaches are actually the fastest by a long shot: code:
VVVVVVVVVVVVVVVVVVVVVVVVVV Plastic Jesus fucked around with this message at 19:12 on Jul 20, 2008 |
# ? Jul 20, 2008 15:11 |
|
Plastic Jesus posted:I found out that my ugly-looking current approaches are actually the fastest by a long shot: skidooer fucked around with this message at 16:58 on Jul 20, 2008 |
# ? Jul 20, 2008 16:49 |
|
In case anyone is interested, I just released Kawaii, which is kind of like a script/console web-front end for those of you like me who hang out in a console all day while developing in Rails. It's open source, hosted at Github. Any feedback would be appreciated!
|
# ? Jul 20, 2008 21:59 |
|
|
# ? May 15, 2024 03:54 |
|
So, um. Why would I want to use Kawaii instead of, you know. A terminal window? This reminds me of Campfire's reinvention of IRC because "it wasn't a Web site" (and then of course a client-side app, Pyro, to interface with the Web site, making it even more ...) That said, I'm sure it was fun to make, and it looks neat, so good job at any rate!
|
# ? Jul 21, 2008 00:10 |