Ruby on Rails Love-In

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Ruby on Rails Love-In

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

enki42 posted:

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?

Yes, it is impossible. Ruby is dynamic front, side and back. Nothing can be done about this without making it into a new language altogether. Therein lies most of it's power, but it's also quite simply static-analysis-proof.

There are heuristic approaches that can analyze a few trivial cases statically, but nothing that is provably reliable.

# ¿ Aug 9, 2007 02:27

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 06:42

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

epswing posted:

Edit: I know almost nothing about ruby or rails, but something that keeps me from diving in head first is...well, the concept of automated db access in general. Am I really going to let something write my sql for me? I really enjoy hammering out a nice query that does exactly what I need it to do, complete with inner/outer joins, unions, subselects, likes, ins, and whatever else is necessary with the appropriate indexes. For simple "select * from table where col=value" queries fine, do it for me, I won't mind. But for anything complex, can I take over? I know Hibernate allows me to take over when necessary. I don't yet trust the efficiency of a cruise controlled database.

Yes you can always use straight up SQL. There are actually several levels of 'low level' sql you can do - it works out very nice.

Common practice is to start out using just ActiveRecord and then optimize as needed. It works very well and you'd be surprised how little raw SQL exists in even high traffic sites. Usually adding an :include clause to a find is sufficient, and beyond that query optimization won't get you very far (or rather, that amount of work is better spent integrating memcached, which is pretty much THE way to scale no matter what language/framework you use)

# ¿ Aug 9, 2007 03:00

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

Sir Chicken Caesar posted:

The major reason Rails rocks for me is that it makes good practice easy. In fact a lot of the time it's harder to behave badly. You guys have already mentioned the MVC pattern support, but you also get things like:

- Great testing support, automatic creation of functional and integration test skeletons. I'm currently investigating Selenium on Rails http://www.openqa.org/selenium-on-rails/ which looks like a good solution to getting front end tests automated as well :-)

Run away! Run as fast you can! It looks great but in practice the tests are a massive pain to write and maintain. The other problem is that it's often buggy, inconsistent across browsers and just plain not an accurate simulation of true user interaction.

For example, say you're trying to test a custom auto-complete field (like google suggest) - if you use the 'type' command you'll find that the form field gets a value but keyup/down/press events never get sent. If you send the events explicitly some browsers get both the event and fill in values while others only get the events (and some do neither). Now you have to test around browser problems, which also defeats part of the purpose for automated browser testing.

Maintainability wisely, the problem is that you write your tests as a series of commands and tests with basically no modularity or logic to them. This is about as easy to extend and reuse as assembler. The hooks for targeting a particular element are inadequate (especially when trying to locate an element that was just inserted via AJAX and whose ID depends on the database in a hard to predict way) and you end up writing a lot of tests that depend on some insignificant UI detail. If that UI detail changes, test suddenly start failing and you have to re-write and debug a whole suite, wasting countless hours, for something that shouldn't even have affected the tests.

God help you if you actually want to change the workflow of a handful of pages - you almost always have to re-write (and debug!) any tests that have anything to do with it, again, because of a complete lack of modularity. It's up to you to implement such modularity, but you'll find that the whole thing is just a real pain in the rear end to work with.

In my experience, it's not worth the investment - not even close.

quote:

- Fixtures for generating test data

Fixtures, as they ship with rails, are crap for actual unit testing. You have some records that are used for some tests but not others, and very often they make it hard to test particular scenarios, so you just end up generating test data by hand more often then not. This plugin attempts to correct this problem, although I haven't tried it yet.

quote:

- Support for multiple environments baked in

Except a lot of code depends on "development", "test" and "production" explicitly. It shouldn't, but it very often does (plugins are especially bad at this - and face it - sooner or later an if RAILS_ENV=="development" is going to slip in your code somewhere...). So even though you can make your own enviornments in theory, in practice, it's a lot more headache then just swapping out prod/dev/test through some lovely hack for different deployment targets.

quote:

- Migrations that make evolving databases easy

Except when you need a migration to also perform some data sanitation between migrations (i.e. you have a new required field and you want to somehow fill it in for existing records). A really wonderful thing happens when you try to do this: Initially it works and there are no problems. Then you keep working on your app and your models gain more fields and validations, and loose some others. Then somebody tries to apply the migrations from scratch. Well, the code you wrote a few migrations ago assumed the models to work in whatever state they were in what you wrote the migration. But they won't! Some fields will be missing and some other validation requirements will have been added, so your migration will stop halfway through and complain. Then you try to fix it, and you realize that you can't without having a migration fail earlier on, or later on, because it's absolutely impossible to reconcile versioned migrations with unversioned models.

Migrations are still really awesome otherwise, but man, they really have some glaring problems left in them that nobody seems interested in tackling.

---

Yes Rails is all sorts of <3 and puppies, but there are more then a few things about it that make you want to run up a wall in anger when you have to deal with them.

# ¿ Aug 10, 2007 20:53

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

Fork posted:

Have you tried looking at Selenium and Watir to do the type of testing your talking about? I'm personally not a big fan of that type of testing because the breakdowns usually occur on the model or controller level anyway, and like you said, it changes way too often to be of much value. Regarding testing not being worth the investment -- I have to say, I've seen some stupid things said about Rails, but that's the first time I've heard that one. I will admit it takes discipline and experience to do it correctly but it does pay off eventually and sometimes in spades.

I should probably have emphasized I was complaining about Selenium specifically, not automated testing in general.

Having said that when 60% of your code is javascript (or, more simply, most of your errors happen in the browser), the lack of proper client-side testing tools becomes a real problem and you really gotta re-evaluate your testing strategy.

# ¿ Aug 15, 2007 01:16

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

skidooer posted:

You can redefine the model within the migration to solve that problem. Not exactly DRY, but a lot better than trying to manage versioned models in an automated fashion.
code:
class MigrationName < ActiveRecord::Migration
  class User < ActiveRecord::Base; end
end

That's... actually not too bad an approach. We could even take it further and clone the whole app/models dir to db/migrations/00_migration_name/. Would bloat the gently caress out of your code base but it would be a pretty darn reliable way to have data consistency migrations that actually work.

# ¿ Aug 15, 2007 01:22

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

ikari posted:

code:
module RailsPatches
  module EnvironmentSettings
    
    def environment
      RAILS_ENV
    end
    
    %w[development test production].each do |env|
      define_method("#{env}?") { environment == env}
    end

  end
end

Rails.extend(RailsPatches::EnvironmentSettings)

>> Rails.development?
=> true
In the case that you absolutely positively unfortunately must do something like that, it reads a lot nicer and will be less of a pain if the RAILS_ENV constant is ever deprecated

RAILS_ENV should get deprecated and the above should be made the default. Until then you wouldn't be able to do it without breaking plugins.

At work we just made our own little loader script that loads a separate database.yml, and runs different test/env/prod configs for each developer and/or deploy target.

That actually works very well for us, but the way envs work out of the box is pretty sucky.

# ¿ Aug 15, 2007 01:29

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

cYp posted:

I'm either going to get started learning PHP or Ruby on rails. I'm currently leaning towards php. Will this be a mistake in the future?

Well you can either learn RoR which encourages you (but doesn't guarantee you to) use good programming practices and will (after some experience behind your belt) get you working on cool projects with people that (on average, compared to php) know what they doing, and you'll be set to head into all sorts of new directions (the skills you learn apply everywhere, even PHP dev).

Or you can learn PHP, write lovely code (which everyone always does when they start of, but...), never grow out of it, beg for poo poo work from rent-a-coder while competing against half of asia, grow insane with the cluster-gently caress of code you'll usually have to deal with and the people that wrote it, until you eventually decide you either need to take up accounting or learn a new programming skill.

It's not PHP itself that is the problem (... for the most part...), it's the environment that grew around it. It is not always the case, but most PHP 'careers' tend towards nasty, brutish and short.

It also doesn't have to be Rails you start with. Python, Perl, even Java (The Great Satan for most rails peeps) are all much more useful to learn. You could also jump into the really really really deep end and start by learning Haskell. It's not for the faint of heart but if you can gork Haskell, anything else you learn will be a walk in the park. ( it is also somewhat easier to learn haskell as your first language rather then your second or subsequent one).

# ¿ Aug 24, 2007 05:38

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

Mr. Heavy posted:

This was my first language and dear loving God do not do this

you will never fix all the damage

still better then php

# ¿ Aug 24, 2007 05:48

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

Argue posted:

Speaking of AJAX, is there some kind of way to retrieve an instance of a model as a javascript object? I mean, if you have a model called Book, and it has the fields title, description, ISBN, is there a function that will let me go myBook = theFunction(myBookId), such that I can say myBook.title, etc?

Jester is prolly overkill - just use @book.to_json

# ¿ Sep 2, 2007 21:33

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

Any of you looking for work?

If you are already getting paid for RoR work, can I steal you away? Seriously, if you have actual working experience on Rails - I am drat near certain I can get you a pretty substantial pay increase by joining our shop.

# ¿ Mar 6, 2008 02:48

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

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

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

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

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

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

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

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 :confused:

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

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

I just wanted to chime in to say that i hate ActiveRecord::Errors. I hate it. Hate it hate it hate it hate it. Actually, Rails' whole approach to validation is kinda misguided, but the errors API and message composition bits in particular are just so loving awful.

I could write at length about this but I'm too busy to really get into it now

I probably will over the winter break though, because there's just not enough political will in the rails-core crowd to fix this poo poo up properly and soon and it really needs doing.

It's been 4 (or 5, i can't quite remember) with rails now, and having been in it close to the ground floor has done truly wonderful things to my employability and salary prospects but I am, more and more, deeply regretting not having specialized in python instead

I know the grass is always greener on the other side but I dunno man, the lib support, the industry take-up, the language development process is soooo much better. Also, let's face it, speed. Whatever neat syntax tricks ruby can show off that python can't quite match simply don't justify the other drawbacks... Have you guys seen SQL Alchemy? It makes ActiveRecord look like a bad joke. Just in general, if you want to do anything other then web dev and scripting with ruby you're not gonna find much, certainly nothing of quality - it's very difficult to branch out to other fields with just ruby. RubyGame really ain't PyGame, let me tell you that. There's no high-performance or low-overhead interpreters suitable for bulk work or embedded systems. Or PEPs - wouldn't it be nice to have REPs or something you know just anything other then poorly translated updates every 3 years of the changelog matz dreamed up since the last release. Figuring out what motivated the changes is of course left as an exercise to the reader.

Anyway, these things are usually not too big a deal and I'll probably stick to ruby for quite a while longer, but some times I just run into what I've come to call "lovely ruby library bullshit" like AR:Errors and it makes me feel :saddowns:

# ¿ Nov 24, 2009 00:55

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

why what non-web thing do you do with ruby that's so awesome and at least on par with python? genuinely curious

# ¿ Nov 24, 2009 05:14

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

Actually yes, we use it extensively - it is quite nice. A friend of mine made a decent python port mind you - cuke itself isn't that complicated. I'd also mention that I've not really seen it be used for anything but testing web apps although I'm well aware it's possible.

Rspec has some neatness to it as well, so let's throw that in as well.

So what else?

# ¿ Nov 24, 2009 07:31

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

I took a crack at ActiveModel::Validations myself a while back, especially ActiveModel::Errors. I didn't have the energy to push it through though - rails-core is kinda apprehensive about big changes, and in retrospect I probably should have done something more familiar looking for starters. This is kinda the trouble with fixing it - there's a fair bit of momentum built up behind the existing way of doing things, and although it can be pushed back, it requires more then a little effort to drum up the support (that is on top of actually writing and testing the patch).

Also, I gotta say, I'm actually 100% in favour of migrations. Unless you only have one machine to develop and deploy on, or it's ok for your app to just nuke all its data every now and then, they are way way better then trying to "magically" update the schema when the model code changes. Although there are a few trivial cases you can make a fairly safe guess, like say adding a brand new column, in my experience there's usually more non-trivial operations you need to perform - like say populating that new column from existing data you have to infer or otherwise process. So in the end you really do need something like migrations anyway - and you gotta ask yourself what the auto-migration from the model really buys you, considering those kind of changes, since they are essentially trivial, are trivial to express as regular migration and auto-migrations are still prone to gently caress up and assume the wrong thing.

Even when I was using couch-db with jaxer (a pure js framework) I ended up using something akin to migrations

# ¿ Nov 24, 2009 23:36

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

I just realized what a grumpy neck-beard I've become

I blame YOU David Heinenmeir Hanson!

# ¿ Nov 24, 2009 23:38

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

NotShadowStar posted:

Yeah I really didn't know what to say to you. It looked like you were doing the argument of 'give me an example, oh well yeah okay now give me ANOTHER example because PYTHON ' and I wasn't going to deal with it.

Yeah, now that we've been looking at Rails and it's components for a few years there's some warts. Remember that all of Rails including AR was designed by DHH like 5 years ago by himself, so of course another pair of eyes is going to come up with something better on a particular aspect than that one person could think of at that time. But it's impossible to overstate how much Rails changed the way we think about web apps, poo poo even Microsoft's flagship ASP.NET MVC is so similar to Rails I was astonished when I looked into it.

I think with Rails 3 the biggest push is to be more like Merb so it's even easier to use non-defaults. Don't like AR? Use Datamapper. Like some AR and some Datamapper and some Couch? Use all of it, who cares. You can kind of do this already but you have to know what you're doing first. I would guess after sweeping Rails 3 the team would be more apt to thinking about lancing off some warts.

I know that sounded silly but cucumber really is one of the few exceptions... And it really isn't that I think PYTHON is all that hot poo poo, nor that rails far isn't perfect (django seems to have comparable levels of fuckups) - I'm just frustrated at ruby's lack of breadth and maturity and i don't think that's a headexplode.gif-worthy statement :colbert:

But like i already said, these things are usually not too big a deal... usually.

# ¿ Nov 25, 2009 00:02

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

Operation Atlas posted:

With couchdb you don't really need migrations- if you do it right you can keep older objects in the older schema and only update the database record when necessary, and when they get saved they get saved in the new schema.

Kind of hard to explain unless you've done an ORM that does that, but migrations truly aren't necessary if you plan ahead correctly.

When you do a query (i.e. make a view), don't you have to take both 'schemas' into account? Won't that get unwieldily after a while?

# ¿ Nov 25, 2009 00:03

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

if you're not switching ruby executables as well, is there any reason why it would be preferable to use rvm over simply vendorizing all your gems?

# ¿ Jun 3, 2010 23:38

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

NotShadowStar posted:

Once you go ~~black~~ without parens you'll never go back.

It's really not a bad thing at all to start using parens as the rule for methods that take arguments. You should definitely use parens whenever there might be ambiguity (and if i'm not mistaken ruby 1.9 is going to be a bit more strict about allowing ambiguous looking paren-less calls anyway), and even if a statement looks clear now, why not put those parens in anyway for when you'll replace that local var argument with a more complicated expression. It's a good style guide. Just make case by case exceptions for particular :airquote:

DSL

calls.

# ¿ Jun 17, 2010 18:47

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

NotShadowStar posted:

Also, yeah Rails does a whole hell of a lot of black metaprogramming voodoo. Much of Ruby isn't nearly that extreme. The internals of Rails 3 is much nicer as the metaprogramming is much toned down thanks to Yehuda Katz's voice of reason.

I'm going through a lot of rails 3 now as we're trying to upgrade our app which has a proprietary hacks and fixes in it and I have to to say the new codebase is a thing of beauty. Yehuda undid a lot of the stupid which was kinda grandfathered in from DHH's original coding style which, quite frankly, was suck-rear end newbie poo poo (he can be forgiven for this, he was rather new at it when he first wrote rails). I think at the top of my list is getting rid of the preposterous mechanics of AssociationCollection which goes so hard out of its way to masquarade as an Array for literally no reason other then to make everything a tremendous confusing pain in the rear end. AREL in general is long overdue and is really assuaging a great deal of python envy I've been suffering from.

The only thing they didn't fix and that I still think is wicked retarded is validation and error handling. You're still forced to show some really stupid-looking errors because you can't avoid the whole "attr name + error message" format and it's just a huge pita to translate some very implementation-detail-specific errors into something that would make sense on the user side.

I forget if I ranted about this in here before, but really I've come to the conclusion that model-level validations have been a terrible idea to begin with. I really think think Django is doing the right thing by having primarily just form-level validations on dedicated form objects - makes a lot more sense.

I can't help but blame DHH for this as well because of his misguided opposition to just using the RDMBS for data validation/integrity - it really is where it belongs. Consider validates_uniqueness_of ... it's basically always susceptible to race conditions, unless maybe you use serializable transaction isolation (which can murder your performance). OR you could just enforce uniqueness in the RDMBS and have no problems whatsoever.

So yeah, would have loved to see model validations simply die, get a new form API with validation done there, and make the migration DSL work with db-level constraints (it already does a little.... but could be expanded).

Oh and speaking of migrations, it would also be nice to deal with data-migrations (i.e. actually converting data from one format to another, like calculating a cache field for example) in a better way. It's easy to gently caress up and refer to app-level models form a migration which WILL bite you in the rear end later when your model has changed and somebody needs to run migrations from scratch. That whole approach should just be locked up. Making minimal migration-specific models is the currently prescribed approach, and it's actually not a bad way to go, but there's some neater stuff that could be done like duping your models per-migration number, or maybe simply providing auto-generating minimal-models for you so you can basically use them like raw-sql-but-not-quite.

# ¿ Jun 17, 2010 19:13

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

Pardot posted:

There's some awesome new Enumberable methods in 1.9.2 http://rbjl.net/27-new-array-and-enumerable-methods-in-ruby-1-9-2-keep_if-chunk

Enumerable � The Best Module�

Yay for combinations/permutations... they are remarkably handy.

# ¿ Jul 6, 2010 22:38

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

NotShadowStar posted:

_{You can make Javascript decent but why bother when there's Lua, IO, Lisp and much better functional languages about}

If the first HTML scripting language had been Lisp we would be living in a different world man - I am so serious.

But since that has not happened, Lisp has piss poor support and tooling (compared to, say, python), IO is too young to be taken seriously and Lua is, well Lua is good but it's not actually thaaat much better then JavaScript and JS just has a lot more momentum and mindshare.

Actually other then syntax and a few narrow and specific nit-picks (like boolean casting) there is exceedingly little to hate about JS.

We really could do a lot worse then JS!

# ¿ Dec 9, 2010 02:18

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

So after spending 3 or so really quite happy years dumping Rails in favor of Python/Django, I've been pulled back in to Rails. I just wanted to vent a little:

God drat I miss explicit imports and file-local namespaces.
NO REALLY I MISS THEM SO loving MUCH
I see certain template errors still refuse to backtrace to the actual template. Wonderful.
It somehow feels even slower then it did when I left though that's probably just the fact that I'm running it from a VM in a not-too-great HP laptop instead of a (at the time) top of the line MacBook Pro. Mind you the same VM had no problems whatsoever with Python.
Why can't anything just have a loving normal name that describes the thing that it is/does. Gems are literally random words from the dictionary. As in, I can click Random Word in vocabulary.com, more then 1 out of 3 times it will be a ruby gem.
You know what's not OK? The fact that any given block just de-rigeur will redefine the local loving scope. Because we can. Here is a library for setting up a user system (named after a random dictionary word of course) - should be very straight forward right? No of course not, you have to configure it in your routes file using magic blocks that do a sort of broken poor-man's inheritance and scope passing and it's im-loving-possible to introspect what the gently caress we actually end up with and why unless we drop into the debugger. Why. Why. Why. What possible productivity saving do we achieve that is worth so many layers of indirection and action-at-a-distance and what-you-see-is-not-what-you-get.

I used to really really like Rails - before my Django defection I had (I think) 4-5 years working with it. But coming back to it now feels like running into a high school acquaintance that failed to grow up at all for the last 20 years and it's just sad and depressing. Maybe I'm just becoming a crusty old neckbeard but I seem to be loosing my tolerance for these juvenile little hipster software projects where everything has to be cool and meta and we are far more concerned with writing executable code poems than such pedestrian concerns as consistency and clarity. Node.js I'm looking at you too here, jesus christ, talk about something with absolutely no redeeming qualities.

Ok, like I said, just venting. Yeah yeah, some people write reasonable ruby, yeah yeah language isn't as important as how you actually use it, yeah yeah, why don't I just go back to python if I love it so much. It's fine, I'll be fine, I'm just not happy about it is all.

# ¿ Nov 2, 2013 01:01

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 06:42

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

Smol posted:

I haven't seen any libraries instance_evaling a block in a while. What library is doing that evil trick? It used to be somewhat popular in the past, but I guess most people realized that it's just a bad idea.

devise is doing something weird with block_scope.

And yeah I definitely see people backing away from that mindset, I guess I was just sort of hoping it would have died by now

# ¿ Nov 2, 2013 01:50

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Ruby on Rails Love-In