|
ANAmal.net posted:Breakpoints and the Script Console are pretty neat, too. I like that they made RoR apps as easy to debug as they are to program in the first place. I probably shouldn't even post in this thread, not having used Rails yet (started reading Ruby tutorials the other day, though, as my new job may have me doing some Rails work) but: how are the mentioned tools different from using e.g. Firebug or the Web Developer FF extension? I'm a Django person, so if anyone who's well versed in RoR wants to have a discussion about the differences/similarities between the two frameworks or their approaches to problems, I'd be game. (...and will I be the only RoR user who has a dislike for the David Hanssen style of "arrogance and overstatement is awesome" showmanship?  )
|
#
¿
Aug 8, 2007 22:06
|
|
|
|
| # ¿ Apr 19, 2024 02:14 |
|
|
ANAmal.net posted:They're different in that they run on the server. Interesting. In Django you can use the Python shell to do the same things you just described, so in a general use-case ("let me modify object X or get a count of how many Y objects I have") it doesn't sound terribly unique. However, the ability to set breakpoints in a web development environment is nice; I'm sure there's an analogue in Python but it would probably require using Django's development runserver (similar to but not intended for real server use as Mongrel) and plenty of 'pdb' usage. I'll have to root around and see if anyone has thought of something like that for Django  ANAmal.net posted:No, that's actually a big turn-off for me, too. I kind of stopped reading the 37Signals blog after his little conference stunt. Yea. I also found it telling that the copyright info on rubyonrails.org mentions David first and the community second: rubyonrails.org posted:Ruby on Rails was created by David Heinemeier Hansson It also mentions 37signals, but that makes sense, as few large open source projects can have decent development/marketing/hosting/etc without a genesis at a company - Django's is the Lawrence Journal-World, a Kansas newspaper, and it says so on the Django site. However, that's all that is mentioned there - the core development team tends to not care too much about getting their names out in the way that David does. That said, there's no question that David's marketing and personality have played a large part in getting Rails the mindshare it currently has, which is only a good thing for Web development as far as I'm concerned. The less people using regular code-soup PHP, even if it means they just move to a PHP MVC framework, the better.
|
|
#
¿
Aug 9, 2007 18:45
|
|
|
skidooer posted:In most popular web development languages you write a program. In Ruby you write programs that write programs. The latter lends itself very well to web development. The only problem I see is that these Ruby idioms usually are not apparent to the Ruby novice, so they end up writing PHP-like code, only with Ruby syntax, and fail to see what the big deal really is. This is the same with any framework, especially Ruby/Python ones: it's not just different syntax and different organization, it's different ways of thinking about the problems and approaches to solving them. I say "especially Ruby/Python" because those sorts of languages encourage doing things in an intelligent manner, both by virtue of what their syntax allows as well as the communities and tools surrounding them.
|
|
#
¿
Aug 9, 2007 19:24
|
|
|
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
|
|
|
OK, that's pretty cool Does Ruby have a pretty-print module of any kind? I haven't done much Rails work lately but I do know that the typical inspect output of objects in the Ruby console struck me as overly verbose and/or poorly formatted. Python, for comparison, tends to print out very little info unless you ask for it (typically just the class name and a memory ID) or if the object in question has a human-readable string rep (most do, unless the dev who made the class in question was a lazy arse). E.g. Django specifically has a tradition of defining such a string rep method for all classes so it's easy to tell objects apart in the shell, so you'll do something like (making this a one liner for brevity, and let's say it's a Person class) def __unicode__(self): return "(%s) %s %s" % (self.id, self.first, self.last). Aside from class instances' string reps, simple objects like dicts (hashes) and lists can have nested versions -- which are typically hard to read in the same way Ruby objects can be -- and for those there's a pprint module which lets you print things out in a nicer indented form. Anyway, all that babble aside, I'm glad you pointed it out, I only looked at the first screenshot on the site so I wasn't aware of this extra functionality. I'm okay with wheel reinvention as long as one does something extra on top of it
|
|
#
¿
Jul 21, 2008 01:43
|
|
|
Nolgthorn posted:What the heck I'll just GeoKit it, this seems to be the new way of doing things. FWIW my workplace seems to use GeoKit for the newer sites and they seem to like it fine. (I haven't gotten to the geocoding part of the site I'm updating yet, so can't speak about it myself)
|
|
#
¿
Oct 21, 2008 04:40
|
|
|
In my limited experience, Passenger is definitely better than Mongrel, including being easier to manage, and faster. I'm updating a Rails 1.2.5 site; it used to use Mongrel and is now on Passenger and there's definitely a bit of a speed increase even on our dev/staging hardware. Pretty sure we have at least one or two production sites using it now too. Not to mention the fact that, at least where I work, they've had to constantly monitor the Mongrels with God or Monit because the Mongrels leak memory like a sieve and go down more often than a Saigon hooker Passenger seems free from both these problems (given that it's an Apache module, I'd hope so...) and is easier to set up, to boot.Amusingly the Django community's moving towards a Mongrel-esque platform (mod_wsgi) but I think it's probably more stable than Mongrel, otherwise it wouldn't be drawing people away from an entrenched Passenger-like situation (mod_python).
|
|
#
¿
Nov 18, 2008 14:44
|
|
|
Evil Trout posted:your only choice is to touch the tmp/restart.txt, where it shuts down all processes and starts up again, preventing any requests from completing for up to 30 seconds. My users definitely noticed that! What do you mean by "completing"? And I don't think I've ever seen an Apache reload or restart take longer than perhaps five seconds; are you saying it takes Passenger 30 seconds to actually spool up its Ruby processes?
|
|
#
¿
Nov 19, 2008 06:06
|
|
|
Panic! at the Fist Jab posted:Based on my experience, this is essentially accurate. It also takes about 30 seconds to hit a site after something like 2 minutes of no one accessing it. Phusion Passenger is absurdly slow and no amount of tinkering with the configuration seems to be able to ameliorate it. What kind of site are you running with it? The one I've been updating (which isn't terribly efficient either, and is Rails 1.2-based) loads pretty quickly after e.g. /etc/init.d/apache2 restart.
|
|
#
¿
Nov 19, 2008 19:07
|
|
|
Panic! at the Fist Jab posted:Rack-based Sinatra. No more than 300 lines of code, and nothing to warrant the spool-up times that I was getting. I switched to Lighttpd proxying out to Thin and now site loading is near instantaneous. Welp, my experiences (multiple production apps) and Hammertime's (???) would suggest your scenario was an aberration of some kind, although I don't know how different Sinatra is from Rails (i.e. perhaps there's some bizarre incompatibility that causes it to run poorly on Passenger).
|
|
#
¿
Nov 20, 2008 21:45
|
|
|
Using a source control system like SVN is basic development practice these days no matter what you're working in; there's really no excuse for not doing so, regardless of the size of your site. If your code's not based out of an SVN/Git/etc repo, you're doing yourself a major disservice. (Reasons include: it keeps a backup of your code for you so it's not all just sitting on your workstation or web server; it does make change sets much easier to work with; gives you a history of what you've worked on; allows for rollbacks when you break poo poo; etc) As for deployment itself, the reason it's so complicated is because of all the moving parts involved -- the server setup (Mongrels or at least the Passenger gem for Apache), the database creation, running the migrations, copying the files, etc. That's all basic stuff any Web app needs to run, of course, but then Rails adds more on top such as keeping multiple checkouts of your code for rollbacks and shared assets and so forth. These things are not strictly necessary, though, but I get the sense it's a Rails best practice which is why everyone does it (N.B. still learning how Rails folks do things).
|
|
#
¿
Dec 12, 2008 22:34
|
|
|
Flobbster posted:I guess it's just a shift from what I'm used to that I need to wrap my head around, from using source control on an already-configured site like SourceForge to maintain my code separate from where I'm developing it, versus setting up my own repository and using it to actually deploy the site to the location it's going to run from. Hmm. I haven't used SF's SVN but I don't get what the difference is. Where the SVN is hosted has no bearing on any of this, so long as you are able to commit to and check out from the repository in question. In terms of "deploying from SVN", the only difference I can think of is that you might be used to manually copying files from an SVN checkout locally, to the server, versus doing the SVN checkout on the server itself. Not really a huge leap and the benefit is that if you ever need to, you can connect to the server and see what SVN version is currently checked out, svn up it, or svn switch between release tags (which is what I usually do -- even wrote a plugin with Cap tasks for doing SVN "the right way" with branches/tags/deploying tags to the server/etc.)quote:Thanks for all the advice, I suppose I should bite the bullet and try setting it up The Right Way from the get-go. I guess my confusion stemmed from assuming this would be like, say, PHP where I just dump the code somewhere and I'm done. Yea, I got the impression that's what you were comparing it to. PHP is the most stupid-easy deploy setup anywhere and is one of the reasons it has the popularity it does. Unfortunately, it means you get used to that way of doing things, so anything more robust like deploying with mod_rails/mod_python/Mongrel/WSGI seems crazy complex by comparison. Trust us that these solutions are more complex because they offer more power and more flexibility, not because they suck (Well...Mongrel exempted...it does suck. Use Passenger/mod_rails.)Really, PHP vs Ruby/Python is the same story on both the language and deployment fronts: PHP is "easier", but lacks a lot of the power and flexibility the others have, and in the long run is generally a lesser solution.
|
|
#
¿
Dec 13, 2008 02:07
|
|
|
Nolgthorn posted:There does seem to be a trend towards Ruby but Ruby is a really really good high level programming language. Well, the "trend towards Ruby" is largely (IMO) because many Ruby/Rails folks can't stand to use anything else and will generally bend over backwards to rewrite perfectly decent and integrate-able existing tools in Ruby. Not Invented Here Syndrome to the max! (For example, God, which is also a terrible, awful name for a piece of software.) Not that other languages don't have NIHS, of course, but it seems to be worse for Rubyists. And to be more on-topic, Haml gets a lot of love from the Rails guys where I work, and they're relatively down to earth, so it must be pretty good I haven't been able to work with it myself yet, still stuck in the Rails 1.2 / ERb maintenance ghetto when I'm on the programming side.
|
|
#
¿
Feb 22, 2009 14:43
|
|
|
plasticbugs posted:You're right. I wasn't calling save on the right instance. Seems to be working as advertised, now. Thanks. The main thing to grasp here, and this goes for any ORM, not just Rails', is that there's your in-memory object and your database row, and they're actually completely distinct from one another until something happens to either read from, or write to, the database. (N.B. re: the following, my knowledge may be out of date -- I am cursed to maintain a poorly written Rails 1.2 project at work these days, it's my albatross.) In this case, as mentioned, you needed to explicitly save the record to the database after modifying it in the Ruby shell. Conversely, once you've gotten an object out of the database by doing Console.first or Console.find, it won't reflect any changes made to other copies of the same object elsewhere in memory, or in the database, unless you call its reload method or otherwise tell it to refresh itself. Rails tends to make this more confusing than it could be, because some actions are implicit, like assigning some related objects. After reading the most recent API docs I wonder if I'm misremembering or if it changed in Rails 2, but I believe assigning to a "parent" object (e.g. game_instance.console = console_instance) often saves the child right away. Certainly, going by the link, there are still some examples of automatic saving around, even if the one I just gave isn't correct.
|
|
#
¿
Oct 12, 2009 02:39
|
|
|
Evil Trout posted:Unicorn is worth a look. You can do a rolling restart pretty much out of the box by sending your master process a USR2. Unicorn looks like has some excellent ideas behind it, but practically speaking I don't see any obvious benefits it has over Passenger for the average deployment situation. E.g. a soft restart is as easy as touch-ing a file or doing /etc/init.d/apache2 reload. If you migrated to Unicorn from Passenger I'd be interested in hearing why
|
|
#
¿
Dec 29, 2009 22:48
|
|
|
Two almost entirely unrelated questions: 1. Any interest in a plain-old-Ruby thread? Based on the general traffic of this one, I'm guessing there's no need, but figured I'd ask. I could see some (a few...maybe one or two...OK, maybe just me) people interested in a thread about Ruby that doesn't assume Rails use. 2. How do people develop Ruby code for distribution? Meaning that if I'm working on a project that's intended to be used via a script or imported as a library into other code, what's the best way to get it into the system load path and executable path and so forth? (As opposed to using e.g. ./bin/myscript every time, or having client code hard-code the full filesystem path to the library, etc.) I know there's stuff like Jeweler and Echoe that involve gem building and provide rake tasks, but it looks like all such tools include tons of extra junk I don't want (e.g. forces Github use, becomes a hard dependency of your code, barfs crap all over your tree, etc.) plus it's still unclear whether I'd have to run a Rake task every time I want to "reinstall" my code. Starting to wonder if it comes down to a choice between manually symlinking everything, or making a shorthand alias for gem build && gem install myproject.gem and mashing it all the time. (Python has a great solution to this called python setup.py develop which "installs" your code via symlinks -- so you only have to do it once.)
|
|
#
¿
Jan 7, 2010 02:47
|
|
|
Good to know. I might try my hand at an OP, but I'm still on the road between neophyte and intermediate user so unsure if I'm the best person for the job. (Plus I'd have a hard time resisting lots of [serious, possibly useful, not snarky] comparisons to Python, as that's my "main" language. I kinda doubt there are a lot of others with that particular orientation.) OTOH now I'm having lots of possibly good ideas, so maybe I'll write up a test one and post it in here or something. We'll see
|
|
#
¿
Jan 7, 2010 15:12
|
|
|
Does RVM provide anything other than one "bucket" per Ruby version/implementation? I.e. how exactly does it compare to Rip or (Rip's inspiration) Python's virtualenv? It sounds like that it makes it easy to switch the default Ruby interpreter/loadpath/gempath between e.g. 1.8.6/1.8.7/JRuby/etc...but what if you wanted to have a couple different projects all using e.g. 1.8.6 but each with different sets of gems/libs? (Which is the use case for Rip/virtualenv -- each project can have a "clean" set of packages instead of clobbering each other's dependencies or dealing with multiple versions of the same gem.) It still sounds like a rockin' way to achieve the base/obvious use case, though.
|
|
#
¿
Feb 3, 2010 21:11
|
|
|
NotShadowStar posted:You read the goddamn documentation. A Ruby project with documentation?  (It actually looks quite thorough, for a change. Nice. I guess I'll...read it! And then decide if I want to manhandle it.)EDIT: According to the gemsets page it does indeed have mechanisms for multiple "environments" per interpreter. Cool beans. Will definitely have to look into it, I've been pining for a virtualenv-a-like, and tried out Rip previously which was too unstable. bitprophet fucked around with this message at 02:44 on Feb 4, 2010 |
|
#
¿
Feb 4, 2010 01:03
|
|
|
Not a huge Rails user, but I have been following Rails 3 with some interest -- Katz seems like a heck of a guy, and they're clearly drawing some inspiration from e.g. Django, which can only lead to good things. So I'm glad to see that not only were those pre-release release notes published, but the Rails 3 beta is out now
|
|
#
¿
Feb 5, 2010 16:01
|
|
|
Re: Ruby on Ubuntu: I've gotten along just fine with the stock Ruby/RI/RDoc/IRb, but do install RubyGems from source, since (AFAICT) that's the component that clashes with how the OS maintainers want to organize things. That said, RVM is pretty nice and would obviate any need to backport newer core Ruby packages on the LTS releases, and I'm planning on investigating it more. Its support for mini-environments with distinct gem installations (gemsets) is something Ruby sorely needs, but when I tried it about a month ago, the actual UI for manipulating them was extremely flaky. Here's hoping it improves or Rip version 2 gets going sometime.
|
|
#
¿
Feb 26, 2010 00:31
|
|
|
512MB is probably sufficient, especially if you give Ruby Enterprise Edition (terrible name, apparently solid kit though) a try, when paired with Passenger you're supposed to get a very decent reduction in total memory footprint. For reference I run two Redmine instances, a couple tiny Django sites, a couple instances of a Python-based wiki engine, and various other odds and ends, all on a VPS with ~512 MB -- and I'm not even using Ruby EE -- and it generally works fine. The nice thing about VPS plans is you can often upgrade when necessary without a reinstall/reformat. Any VPS host that says "no we cannot up your ram allotment easily with just one quick reboot" is not a host you should be considering anyway
|
|
#
¿
Mar 5, 2010 15:22
|
|
|
RVM is great, I've found it to be a passable analogue to Python's virtualenv. It's still kinda flaky in spots, mostly just that the invocation syntax is clunky, but it does work. I used to stay on Ruby 1.8.6 because it has the strongest OS-level support, but since discovering RVM I've been more apt to play with 1.8.7 and all its new shinies, at least for non-server-oriented projects. (Haven't yet looked into how to integrate it with eg Passenger. I assume it can, just like how mod-wsgi Web apps can leverage virtualenv in the Python world, but haven't verified this.) Combined with Bundler it makes setting up per-project environments and gemsets pretty easy. No more worrying about an enormous list of global gems stomping all over each other.
|
|
#
¿
May 15, 2010 19:20
|
|
|
NotShadowStar posted:There's very little reason to use 1.8 anymore. (Thanks for the confirmation re: Passenger.) 1.9 is still way too new for serious deployment IMO, certainly at any outfit which has to maintain codebases that are more than a year or two old, and/or which deploys to servers not running on the bleeding edge. And since I tend to not like bouncing between various different versions of X often (where X is a language or a program or OS) I tend to try and pick something that's old enough to be stable and readily available but not SO old that it lacks any feature parity whatsoever. Thus, 1.8.7 fits the bill pretty handily. (The Web stuff at my job is all still 1.8.6; for us, moving to that version's REE is considered a big step, even. We don't have much manpower available for R&D or support, otherwise we probably would've moved to 1.8.7 by now. Meh.) bitprophet fucked around with this message at 23:45 on May 15, 2010 |
|
#
¿
May 15, 2010 23:42
|
|
|
Evil Trout posted:I disagree. I've been running 1.9.1 in production for well over a year on a codebase that's 4 years old. The upgrade took maybe 3 days of work and resulted in a huge speed improvement (average of 2x as fast). I guess it depends a lot on where you work; I rarely have the free time to sink hours/days into a project for upgrading unless there's a need, and there's significant pressure to avoid needless hours billed to clients (or eaten internally). So in that kind of environment, one settles on a specific (old, readily available on most Unix distros) version and stick with it for quite a while  Re: 1.8.7 marshal segfaults: I just got bitten by those recently, albeit in Sass (and via Nanoc, not Rails). Thankfully RVM let me set up 1.8.7-HEAD easily which seems to have fixed the issue. Speaking of RVM, anybody using the latest-n-greatest rip (i.e. the prerelease v2)? Still not a big fan of RVM's clunkiness w/r/t gemsets.
|
|
#
¿
Jun 1, 2010 03:22
|
|
|
If you just want to learn how to write Rails apps (and are fine with staying with the exact components they offer) Heroku is, as mentioned, your best bet. If you want to learn how to administer a Rails-capable Web server (or want to work with a different set of tools) then you probably don't want to use Heroku because they abstract everything away for you. Basically, development vs operations/systems administration. If you definitely want to learn the systems side of Web dev, read on! Rackspace Cloud is probably the best combo of quality/price for virtual servers. You're charged pennies on the hour, which means if you spin up a new instance to play with Technology X and then decide to nuke it a day later, you've lost less than a dollar (and they often don't even bother charging for short-lived instances, in my experience.) And you can create/delete/update instances on the fly via a control panel. Amazon Web Services (EC2, S3 etc etc) is another, similar (and older, and more "enterprisey") setup, but it's a bit more work to cobble together a simple working server, and more expensive, at least on the low end. On the other hand, AWS experience is useful to have, career-wise. If you want a more "classic" VPS setup (heh...now I feel old. VPS as classic?) which gives you more "static" instances that are charged monthly, Linode or RimuHosting are excellent providers. Linode may also have a cloud-style control panel, though I think it's limited to reimaging a handful of specific instances -- i.e. you pay monthly for X amount of RAM/HDD space and might have to go through billing to spin up more servers. I'm sure some of the other posters can clarify this.
|
|
#
¿
Sep 1, 2010 03:32
|
|
|
Obsurveyor posted:Use rvm. Ubuntu's package management for ruby sucks balls. This. The default Debian/Ubuntu Ruby interpreter itself tends to work fine, it's the gems that has the big bruhaha surrounding it, so I typically aptitude install ruby1.8 ruby1.8-dev ri irb etc etc but don't include rubygems here and then install rubygems from source (grab tgz, unpack, ruby setup.rb install). RVM has a bunch of neat features like gemsets, though, and makes it stupid easy to manage different Ruby versions. So if your server is going to host multiple apps, especially ones that might need different Ruby versions among them, it's totally the way to go.
|
|
#
¿
Sep 24, 2010 23:05
|
|
|
Yup, need libmysqlclient15-dev (or whatever it's named in 10.10, that was the name back in 8.04) and also ruby1.8-dev. I think those two plus build-essential covers everything.
|
|
#
¿
Oct 15, 2010 19:37
|
|
|
Nolgthorn posted:I just watched the Railscast for Mongoid and MongoDB. Now I am considering updating my entire almost complete very complicated Rails application to use it. The general rule of thumb is that if you have to ask "should I use (Mongo|Couch|Cassandra|Riak|whatever)", you don't need to use (Mongo|Couch|...). NoSQL is not a magic panacea that will suddenly make your application more awesome or sparkly or whatnot. Such tools fill a specific niche of use cases (and all of them slightly different ones, too) and it seems that most legit uses are are situations where the devs go "ugh, my current application/infrastructure using an RDBMS is falling down here and there and oh man, if only I had a distributed key-value store, I could do this and it would work so much better!". Can't say for sure without knowing more, but that doesn't sound like you Honestly, by using Postgres instead of MySQL you're already ahead of the game, I'd stay there. Playing with NoSQL is always great, but I sure as hell would not switch a production or near-production app to a NoSQL setup without a clear understanding of what RDBMS failings you're addressing by doing so.
|
|
#
¿
Nov 29, 2010 20:16
|
|
|
NotShadowStar posted:http://railscasts.com/episodes/209-introducing-devise Oh good, screencasts. I love using Ruby, but it seriously irks me that the community's idea of "documentation" is one of: read a simple-rear end Hello World style README, pay money for a book, watch a (sometimes for-pay, almost always limited in scope) video, or learn the source code inside and out. Heaven forbid the author take the time to write some comprehensive usage + API documentation so non-trivial non-common use cases aren't left out in the cold. One of these days the Ruby and Python communities should switch places for a bit so Python can learn how to have usable test frameworks and Ruby can learn how to document their projects. I'm not bitter, who's bitter?
|
|
#
¿
Jan 19, 2011 23:24
|
|
|
NotShadowStar posted:I LIKE screencasts I'm sure they're well executed (I actually don't watch very many and probably should check out more), I just would much rather search or skim text documentation than watch an hour long video in the vain hope that the info I need is at the 45 minute mark And aren't most screencasts just a glorified README? Or do some of them actually go in-depth? quote:Most of the time with Ruby code, all you need is the basic idea and the RDoc. Ruby code is mostly self-documenting unless it's loving horrible, then nobody uses it. Eh, many Ruby projects link to an RDoc with a bare skeleton of actual information (as in, great, I can see that X class has foo, bar and baz methods, but none of them actually have any documentation, just the function signature) and call it a day. Especially recently when some very nice doc oriented tools like YARD exist, there's just no excuse not to flesh out your API content and throw in at least a few pages' worth of prose docs explaining the relationship between the classes. quote:Now, if you want to talk about 'give us money because our poo poo is so hosed you can't figure it out', I'm getting into Drupal and holy gently caress. See also Magento, EZPublish, and probably every other huge PHP project  It's true, I'd much rather wade through Ruby source code to figure something out, than use PHP -- but I still shouldn't have to.As mentioned, though, nothing is perfect. Python spoils me on documentation and so I get frustrated trying to put Ruby stuff together on a deadline; and when I'm working in Python using basic JUnit-style unit tests, I look back at rspec/cucumber/etc and cry a little.
|
|
#
¿
Jan 20, 2011 01:45
|
|
Especially Railscasts, they're very well done. Show, don't tell.
|
HIERARCHY OF WEEDZ posted:Uhh, if you had gone to any of the Railscasts pages, you would see that every one has a complete transcript located on ASCIIcasts: http://asciicasts.com/episodes/209-introducing-devise Where did I say I was doing Rails work?  (Yea, I know, it's technically a Rails thread...but it's not like there's a regular Ruby thread or I'd post in there. Another one of my beefs...Ruby the language is way too overshadowed by Rails.)Good to know that there are sometimes transcripts, anyway. I'll keep an eye out for such offerings next time I find myself looking at screencasts. bitprophet fucked around with this message at 19:11 on Jan 21, 2011 |
|
#
¿
Jan 21, 2011 16:40
|
|
|
NotShadowStar posted:To be fair people were doing wacky as hell things to the syntax and structure of the Ruby language until ActiveRecord and ActiveSupport. I maintain the LDAP library and holy crap, Ruby code from 2003-2004 is bizarre. I love Yehuda, he's awesome. (He's also not ashamed to look at what Python and Django did right and to steal ideas, which is cool. And Rails 3 struck me as sort of a Rails version of Django's 2006-2007 "magic-removal" upheaval.) And I'm not saying that Rails is bad or that its influence on Ruby has not been a net positive; just that as a not-usually-Rails dev using Ruby, it's frustrating that everything out there (blog posts, documentation, the way stuff is packaged, answers to questions etc) often assumes a Rails context.
|
|
#
¿
Jan 21, 2011 19:14
|
|
|
NotShadowStar posted:In that case, install Homebrew and then do 'brew install sqlite'. Unless the Tiger fork is more robust than I remember, brew is Leopard and up Seconding the point that a PPC Mac is...really not very feasible for modern development. You can almost definitely pick up an early Intel system for cheapish nowadays...
|
|
#
¿
Feb 13, 2011 05:09
|
|
|
enki42 posted: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. This, though I will point out that before RVM came around, I made do with finding a distro-compatible third-party Ruby build (e.g. a Yum repo or Ubuntu PPA) that was new enough (takes a short bit of searching / vetting), and installed Rubygems from source (easy as falling off a log). Worked pretty well.
|
|
#
¿
May 25, 2011 05:11
|
|
|
Dooey posted:I did not realize they were different. And so it goes. Still wonder where Ruby would be today without DHH turning it into a slightly more expressive PHP...  My guess: much less popular, but also much less pigeonholed and overshadowed by a single framework. Meh.
|
|
#
¿
Jun 18, 2011 03:57
|
|
|
|
| # ¿ Apr 19, 2024 02:14 |
|
|
Obsurveyor posted:Care to expand on that or are you going to leave it at vague musings? I meant more about how both are essentially consigned to be Web-only languages, except Ruby is actually an excellent general-purpose language but still gets pigeonholed into "lol Rails" / "lol Web" because of the inordinate influence Rails has on the Ruby ecosystem. So you end up with a flood of coders who only know the Rails DSL and don't even realize there is a distinct, not-Web-only language underneath, and I think that's a real shame given how great a language Ruby is. This isn't a 100% true thing, of course -- look at the CLI and server related tools that have come out of Ruby over the last few years -- but it still grates that every Ruby discussion is full of folks e.g. assuming you have ActiveSupport installed, or pointing you to Rails plugins for X when you wanted a generic solution for X instead. By comparison, in the Python world, only the newbiest of newbies confuse Django for Python, and even though Django does bring a number of new Python coders into the fold, it doesn't dominate the landscape like Rails does.
|
|
#
¿
Jun 18, 2011 06:33
|
|