|
The Haml thing is a neat idea, but in practice doesn't everything just turn into div city? There's more than one tag in HTML for a reason.
|
# ¿ Aug 9, 2007 01:59 |
|
|
# ¿ Apr 29, 2024 05:15 |
|
shopvac4christ posted:http://glu.ttono.us/articles/2006/12/19/tormenting-your-tests-with-heckle - Heckle - This testing utility mutilates your code to see if it will still pass its tests. If it does, there may be something you're not testing completely. It breaks on some things (like any code that sends conditions to the DB), but otherwise is awesome to watch. What the gently caress? This seems like a lovely and backwards way of doing things. Is it impossible to do any sort of static analysis in Ruby to get actual coverage instead of changing poo poo and waiting for it to break?
|
# ¿ Aug 9, 2007 02:01 |
|
shopvac4christ posted:You mean code coverage? Like rcov? I saw that you CAN use HTML elements, but the style seems to encourage making everything divs (as does the giant example on the homepage).
|
# ¿ Aug 9, 2007 12:44 |
|
take boat posted:Also whatever database you're using must be pretty awesome if it knows how to automatically keep an updated age field Umm, MSSQL and Oracle can both do this - I do think it's better that it's done by the business logic, but it's not exactly a way-out-there feature. Besides, it's trivial for any even vaguely OOP language to compute a fields value based on the value of other fields.
|
# ¿ Aug 10, 2007 02:14 |
|
take boat posted:Really? You can fake it in MySQL using views, I know, but do you mean they have an actual age field? I am not exactly up on databases though so either way would not surprise me. Not age specifically, but MSSQL and Oracle (I'm about 90% sure for oracle) have computed fields. Plus of course you can always use stuff like views.
|
# ¿ Aug 10, 2007 13:14 |
|
Nolgthorn posted:respond_to :html, :xml With InheritedResources it gets even more insane. Here's an entire REST controller, that talks HTML, json and xml. It auto-wires up everything to do with manipulating the models provided that your controller and models are named well. code:
|
# ¿ Nov 29, 2010 20:09 |
|
h_double posted:Can somebody recommend a good to-the-point guide on setting up a basic blog-style site with Rails? railstutorial.org is the canonical online tutorial, and a twitter style site really isn't that far off a blog (allow more characters than twitter and don't let everyone sign up for an account)
|
# ¿ Dec 4, 2010 15:27 |
|
Pardot posted:also I hope salesforce doesn't gently caress up heroku I was at the announcement keynote, and Benioff swore up and down that they're commited to not touching Heroku culture, but really everyone says that and we'll have to wait and see. One thing that could be interesting is if they pull off database.com and get it well integrated to heroku. One thing that I don't think Heroku has ever pulled off super well is a good database story - it's fine for small stuff but when you get into bigger stuff (particularly at the enterprise level) it's a bit too inflexible for my tastes.
|
# ¿ Dec 10, 2010 20:22 |
|
NotShadowStar posted:You can use Amazon SimpleDB, RDS or MongoHQ with Heroku if you like, though. Heroku's philosophy is why do something when others can do it much better? Yeah, that's true. I guess what I'm saying is that I think database.com is a bit more compelling on it's own. It's probably due to working more in the enterprise space, but having a solution for multitenancy baked right into the product is amazing.
|
# ¿ Dec 10, 2010 21:11 |
|
Plastic Jesus posted:I want to use the Linked In gem, but my app also uses Omniauth. Omniauth requires a newer version of oauth than the Linked In gem specifies, and Linked In specifies an exact version rather than '>='. This is easy to fix locally, but it'll break when I push to Heroku since Heroku will download the linkedin gem. Is there any clean way to supply a gemfile when pushing to Heroku? I had the exact same problem, and fixed it locally and forked the linked in gem and pointed it to my own git repository. You can use mine if you like: code:
code:
|
# ¿ Jan 21, 2011 13:14 |
|
Regarding scopes and where chaining in Rails 3, is there really any significant advantage to using a scope over say:code:
|
# ¿ Apr 2, 2011 15:13 |
|
I've been in a lot of dev shops that were at that level of errors, untested code and general horribleness, and while it's tempting to say "let's stop everything right now and do nothing but testing / refactoring", a lot of times that really just isn't realistic. One approach that I've found works well is to set explicit rules about how you're going to deal with technical debt, in a way that you can get buy-in from the higher-ups that it won't grind development to a halt. Here's a good list of rules to start with:
Even just 1 and 2 will go a long way to improving your codebase. You'll never have 100% coverage, but if the only areas in your code that aren't covered never change and never have issues, it's far less of a concern in my mind.
|
# ¿ May 4, 2011 14:54 |
|
Pardot posted:Unrelated to your problem, but I'd strongly advise against subdomains. They make full stack integration testing much harder than it has to be. And there's not much business value in subodmains. Most people don't know what browser they're using let alone care what the url looks like. The value in subdomains really becomes a lot more apparent when you get into multi-tenancy problems. If you can segregate / scope your entire data layer based on which subdomain is being accessed, things get a lot easier to deal with.
|
# ¿ May 10, 2011 11:44 |
|
BonzoESC posted:Anybody going to RailsConf this week? I'll be at the free Bohconf track Wednesday and Thursday. I'm there now. Tutorial day was a little dull, looking forward to the keynote today. You should head over to the GitHub meetup on Wednesday, we'll have a beer.
|
# ¿ May 17, 2011 13:07 |
|
Yeah, trying to use the ruby supplied by pretty much every package manager is the way of pain and misery. There is literally no good reason to not use RVM.
|
# ¿ May 25, 2011 04:18 |
|
Dooey posted:My irb stopper working Isn't reload! particular to the Rails console? I don't think vanilla irb has anything like that.
|
# ¿ Jun 17, 2011 12:16 |
|
If you're not getting any errors but the partial just doesn't seem to be showing up, the obvious typo to check for is using <% render instead of <%= render.
|
# ¿ Jul 10, 2011 12:14 |
|
ZanderZ posted:Everything I make is div city. I've tried doing it properly. I've done tables before, but for some reason my clients love the fact that I use divs. Wow, that has to be the king of blast-to-the-past quoting. I had to use forums search to find where my original post came from, and it's from 3 years before I was actually a Ruby dev For the record, I still like the idea of Haml, but it still puts divs up on an undeserved pedestal. A div tag should be the tag of last resort, not the default. Whenever you use a div, you're basically giving up and saying 'welp, i can't assign any semantic meaning to this thing at all.' Haml really ought to require specifying tags. Sass is the bomb though, particularly in SCSS syntax.
|
# ¿ Jul 12, 2011 19:11 |
|
skidooer posted:Or congratulate Rails. It automatically adds indexes on join columns when you create your model. Is this new in 3.1 or something? I don't remember it happening on 3.0.8. I assume you have to use :references as your column type, but is there any other trickery needed? enki42 fucked around with this message at 14:22 on Jul 14, 2011 |
# ¿ Jul 14, 2011 14:19 |
|
kalleth posted:Ruby people like one-liners Better still is: code:
|
# ¿ Jul 18, 2011 15:04 |
|
8ender posted:I really want to go to the Toronto one but damned if I'm missing paintball day. If you do manage to come, say hi. I'm Ryan, I'm running the event.
|
# ¿ Jul 18, 2011 15:05 |
|
8ender posted:drat, now I really wish I could come, especially since I have a developer here thats learning the ropes on Ruby and Rails after years of PHP and this would be some good experience. Unfortunately that developer is the owner of the farm we're all paintballing at. Well, we do run a hack night every second Thursday, and there's Rails Pub Night every third Monday of every month, and a Ruby talks meetup every month if this weekend doesn't work for you
|
# ¿ Jul 18, 2011 18:26 |
|
And in any case, you should be using inherited resources and let it do all the dirty nested route lifting for you:code:
|
# ¿ Aug 12, 2011 20:50 |
|
Tomed2000 posted:Thanks. I have another question that is probably more Rails related, though, so maybe someone can still help. I'm trying to figure out how to use check boxes to select multiple records and update them accordingly depending on what button a user presses (think GMail e.g., delete, archive, etc). One thing that a lot of people don't realize is that submit fields actually pass their value through to the server when they submit - I'm imagining you could do something like this pretty easily: (view) code:
code:
enki42 fucked around with this message at 12:35 on Aug 30, 2011 |
# ¿ Aug 30, 2011 12:31 |
|
In regards to the New Relic "trick", there's an availability monitor on NewRelic that will ping your server every 30 seconds or so - if you turn this on with a free instance, you'll never have enough idle time for Heroku to spin down your instances. On a related question, does anyone have any hints for speeding up Heroku loadtime immediately after deploys? It's probably the biggest obstacle in our way to being able to deploy fairly continuously, since every deploy means that users are going to see a loading screen for 10-15 seconds. Also, the migration setup is somewhat weird on Heroku - I'd really like to be able to do database migrations BEFORE deploying code (since 99% of the time they are additive, and code that doesn't know about the new columns will still happily work, whereas the converse is very rarely true.)
|
# ¿ Aug 30, 2011 21:52 |
|
A MIRACLE posted:I suppose you could pull/migrate/push your db but that's not really a clean solution. Yeah no, I can't really count on the database not being changed while I'm going through that. I know it's probably an impossibility, it's just more than a little painful to deal with.
|
# ¿ Aug 30, 2011 21:57 |
|
My company does a bunch of stuff like what you're describing, Newbsylberry, and we built a gem for dealing with some of it - https://github.com/bradrobertson/apartment Basically, the idea with it is that this gem will switch over to different databases (or schemas if you're using postgres on heroku) depending on something like the subdomain of the request coming in (or really whatever you want). We like it a lot better than the scoping thing everyone tends to do since you don't need to add columns like site_id to every table in your app, and once you have things set up, you don't need to think about it (other than running a different version of db:migrate)
|
# ¿ Dec 5, 2011 12:56 |
|
BonzoESC posted:Unless the sites are going to share users, I'd just put each one in a separate Heroku instance and maybe write a rake task that git pushes to each one to deploy. That way you don't have to worry about columns or schemata at all. Yeah, actually I tend to skip by this approach and it's effective as long as you're not sharing data or have a large number of sites (large being anything more than 5 or so in my experience). We actually used this approach at my company until the number of clients became infeasible to manage separately.
|
# ¿ Dec 5, 2011 13:23 |
|
It really depends on what approach to multitenancy you want to take. If you're using scoping, you will need to make some sort of script that goes through the following steps:
If you're using schemas to seperate data, you could take a similar approach, but move tables to new schemas with ALTER TABLE after moving them over. In any case, it's not going to be a trivial migration and you should plan for some downtime when doing it. To be honest, if expanding beyond 5-10 sites seems like a possibility, and particularly if you want some interaction between different clients, I would probably look into using a library from the start. Getting apartment up and running really isn't all that complicated (set up a config file, and remember to use rake apartment:migrate instead of rake db:migrate and you're set.)
|
# ¿ Dec 5, 2011 15:58 |
|
BonzoESC posted:rspec is trash Them's fighting words! Really though, I've only really ever used rspec, and I like it just fine, particularly once I grokked using subjects, contexts, and it a lot better. What does the newish stuff bring to the table? Now cucumber, there's a thoroughly useless test framework.
|
# ¿ Dec 30, 2011 14:36 |
|
BonzoESC posted:Also, I like cucumber because I can mash out a high-level view of what I want working with the site to be without giving a flying gently caress about implementation, and I generally don't have to change the feature file once it's written; just implement steps and focus on changing failure messages or making it pass. I find I can do the same with integration tests written in rspec - you get most of what you need with the capybara DSL and some sort of fixture loading / factories. Adding the seperation between test definition and implementation always felt like an unnecessary step that made grokking the tests more complicated, in my mind. And yeah, I do agree that even if you understand how rspec works, most of it is just memorization about how you should structure things rather than reasoning about the system.
|
# ¿ Dec 30, 2011 17:09 |
|
I do find that I bump up against the limits of "vanilla" ActiveRecord fairly often, but fortunately, ActiveRecord is built on top of Arel, and there's very little that isn't possible with Arel. It can seem pretty tempting to drop back to SQL, but you are losing some benefits by doing so - for starters, eager loading associations becomes a lot more of a pain, and you won't be able to chain together any pure SQL calls.
|
# ¿ Feb 1, 2012 16:03 |
|
I think Railstutorial.org starts with scaffolds, but quickly abandons them and starts over within a chapter. It's also an awesome tutorial, and there was just a new version released.
|
# ¿ Feb 11, 2012 15:00 |
|
There should be a menu option in VirtualBox for "Install Guest Additions". I think it's under devices. Alternatively, just push it up to GitHub or something and clone the repo back down to your VirtualBox.
|
# ¿ Feb 27, 2012 14:14 |
|
I'm shocked that there aren't more people using Sublime Text 2 in here. It's honestly the best parts of every text editor rolled into one super-amazing program. Plus you can get it for every platform. And the dude who makes it is insane and adds features like every night. Rest of our setup: - DB: Postgres - DB editor: pgAdmin (ugh!) - Text Editor: Sublime text 2 - Server: unicorn / thin - Gem management: RVM (I really don't get the rbenv fuss, RVM might be coded wonky but it works just fine. I guess if you really like aliasing bundle exec all over the place..) - Foreman - Git command line / GitHub for Mac for occasionally checking out some random project. - Git flow for branching / etc (with the exception that we don't git flow feature finish and use GitHub pull requests instead). Also, I like cool heroku beta access stuff too
|
# ¿ Feb 28, 2012 01:17 |
|
For those just getting into Sublime text, here's a few tips that turned it from to
|
# ¿ Feb 29, 2012 13:59 |
|
One of the only complaints I have with Heroku is that it's exceedingly difficult to do actual seamless deployments. On a normal setup, you need to push your code before you're able to do migrations, which means that your new code needs to be backwards compatible with an unmigrated database (possible, but much more difficult to do than the other way around, and can tend to lead to spaghetti code). If you're paying for a dedicated DB, it should be possible to do your migrations prior to pushing up code, but that isn't a cheap option if you're just playing around or experimenting. (we already pay an OK amount to Heroku and haven't needed a dedicated DB set up yet.) On top of that, even if you can do things perfectly seamlessly in regards to the database, when you do a push Heroku will switch everything over to the new slug before the app has had a chance to fully boot up. If you have a decent amount of gems or something slowing startup time this could be > 15 seconds before you're completely in the clear. Currently the process I'm thinking of testing out that hopefully should make things completely seamless:
It's definitely a lot of steps, but I think everything could be automated by a script, and as far as I can tell it would be truly seamless for most migrations. Some migrations might require a pre-push to live to deal with the database changing, but I usually find I'm adding columns way more often than I'm deleting them, and renaming could be a "add column, copy data, remove old column on next deploy"
|
# ¿ Mar 2, 2012 19:40 |
|
Are all of these external contacts children of some other parent relationship? If so, you could base your form around the parent relationship and use accepts_nested_attributes_for on the parent model so you can pass a bunch of external contacts into the parent.
|
# ¿ Mar 25, 2012 02:42 |
|
I think half the difficulty on installing ruby on a mac (or anywhere, really), is that there's inconsistent guidelines and no straightforward, canoncial "hey, absolute beginner programmer, here's what you should do!" Most beginners are probably going to have to deal with:
All of this is pretty much second nature to people who are used to rails, but if you're new to it, there's a lot of different options to consider, and even where there's a clear "right" option, there's still plenty of guides that refer to an outdated old option that should be avoided.
|
# ¿ Mar 30, 2012 03:47 |
|
|
# ¿ Apr 29, 2024 05:15 |
|
Pardot posted:There is literally no reason to ever use mysqlol when you have the option to use postgres. Postgres isn't a walk in the park your first time either. I open pg_hba.conf and configure it without thinking twice about it now, but the first time I installed Postgres it was a complete pain in the rear end figuring out what was going on.
|
# ¿ Mar 30, 2012 12:13 |