Posts tagged ruby
During my teaching, one obvious effective tool for learning Ruby is the Interactive Ruby Shell (IRB). It helps students figure out how to play with Ruby’s syntax before they go on to write their first script. I’d heard about Pry before, but it wasn’t until lately that it came up on my radar again. Here is a small collection of links to blogs, resources, and screencasts that I have found helpful in understanding how powerful it is in development.
I can’t see myself using it just for a plain Ruby program, but it definitely is better than the basic Rails console.
I just use it like this from within the base of my project:
$ bundle exec pry -r ./config/environment
I’m in the midst of teaching an introductory 8-weeks course on Ruby and Ruby on Rails over at General Assembly in Manhattan. Per the course material, we have them install RailsInstaller, an “all-in-one” kit that is meant to get a novice developer up and running in a development environment as quickly as possible.
Acting as teacher, I felt it was good to lead by example and go through an installation of RailsInstaller. After I clicked the install button though, I immediately had flashes before my eyes of this tool over writing many hours of work of painstakingly pruning and preening my dot files, configs and preferences for RVM and git. I pretty much regretted that I did that, thinking it may compromise many of my personal and volunteer projects dependent on having a flawless development environment. (If you’re familiar at all with my Github profile, you’ll know that I have a few projects devoted to my obsessive collection of laptop configuration scripts and dot files.)
Honestly, I have been using my personal MacBook Air for a week now and haven’t noticed any issues in my development environment using the incorrect versions of Ruby, Git or RVM, but I still have this paranoid suspicion that I may have done something by installing RailsInstaller over everything I’ve curated. (Yes, very paranoid.)
Which led me to try to research on where RailsInstaller actually installed these files and how in the world I could remove them!
After a cursory search, I came up pretty empty-handed because on the RailsInstaller main page, it doesn’t give you any information on how to uninstall it! (Maybe a ploy for you to never uninstall it?? *cue evil laugher!*)
It seems Google Groups is the place to be for me in finding necessary information lately, so I came upon this thread asking about a “clean uninstall” for Mac OS X. (Finally!)
If you have an old version of RailsInstaller, you can run this simple command:
If you have a recent version like mine, that App doesn’t actually exist in that path and is actually within the ~/Applications folder. D’oh! (Now you know how often I actually peek into that folder versus using Spotlight.)
And there you go, it runs through a similar process that you ran when installing, except this time removing the files you previously installed and you can happily watch as all that extraneous overhead is removed over a cup of tea!
I’ll apologize to Brandon first for writing this because I am sure when he reads this blog post he will roll his eyes or puke at the thought of me brining this up.
My junior CSU670 “Software Development” class with Matthias Felleisen at Northeastern will forever be one of the most tortuous ordeals I will have ever lived though – but also probably the most rewarding. To this day, I still wake up from nightmares of me sitting at one of the Solaris boxes in the CCIS computer labs talking with other classmates and they ask me what other classes I am taking that semester; lo and behold I can’t even remember one of the 3 or 4 other classes I am supposed to be taking that semester, all I can think about is Software Dev and that I LIVE in this computer lab!
After passing the class from hell, a few of my friends and I made a pact of sorts that we would (one day) continue on with our code from the class and improve on it, because it really was probably one of the largest projects we had ever worked on.
If you have never heard of Squadron Scramble, no worries, I don’t think anyone in the class had ever heard of the game either. It’s a rummy style game but you use aircraft cards with aircrafts from World War II (oh, so appropriate since our professor is German.) Our class rules were modified from the original game, but the basic premise is that you collect three of an aircraft type and can use that to “shoot down” other aircraft trios with a few other wild cards thrown in for good measure.
We were required to pick a programming language and work in pairs and practice paired programming. I had mixed results in past course with paired programming but in this course it was absolutely critical that you have a well functioning team to carry out each week’s assignments, otherwise you would be behind for next week’s tasks because every week built on the weeks before it.
The tasks finally built up to us creating our own game server and administration as well as clients to connect to our server and other student team’s servers. We also had to create dumb artificial intelligence and come up with “player” strategies to try and beat each other with our “players.” And this was all using ugly XML syntax and we were only allowed to use the aging and severely out-dated Solaris machines. We also had to come up with a GUI interface, and did I mention that yes, it all had to work on the grossly out-dated Solaris machines?! That means using Tcl/Tk instead of all the new flashy goodness of anything else developed within the last decade.
With that said and done, my buddy, Ventz, asked me earlier this week if I had time to develop a Ruby client and server and bring the project back to life. My one request was that instead of XML we use JSON instead to make our lives easier. He was going to take a stab at re-writing a Perl version of the code and hopefully get a few other ex-CSU670ers to chip in a Java version and whatever other version they’d want to contribute. My first task is probably to write out a proper spec and improve upon on some of the universally despised guidelines in Matthias’ original spec.
If you’re interested in seeing the final code I wrote in the class, hop on over to my Subversion repository: http://svn.rachelober.com/csu670/ I think this is pretty much the final version of the code that I submitted in the class. I’m almost certain this will not run on anything unless you can get your hands on one of CCIS’ old Solaris servers (which have since been “taken out back” and summarily assassinated,) but I’ll add a disclaimer anyway that the code is provided “as-is” and under no warranty. If it screws up something on your system when you try to run it, sucks for you!
Maybe one day we’ll get some kind of game server to run and we can all play some crappy aircraft card game over the internet.
This has been a pain in the ass for the past 2 weeks for me. At work I do a combination of iPhone objective-C programming and Ruby on Rails programming. Just about everything broke and I’ve been pulling my hair out and patching things with scotch tape just to get it into some kind of working shape. I haven’t had to time to back everything up and just reformat the damn machine and install everything compiled properly to the 64-bit system but here are some links that have helped me wobble along until I can fix things.
The Xcode muckiness wasn’t as bitchy to overcome by just fiddling with some of the settings to get it to work with my company’s code – but the problem also was that the new Xcode that ships with Snow Leopard totally got rid of all the previous iPhone SDKs I had. My company still runs most of our iPhone apps off of 2.2.1 and Xcode for Snow Leopard only does 3.0. Unlike my co-worker who practice more forethought than I do (so what, call me ignorant), I didn’t have a backup of the previous Xcode stashed somewhere else. Adam showed me a tricky trick in the new Xcode and you are able to still use the new 3.0 SDK but set the deployment target to whatever the heck you want.
OF COURSE, with the new iPhone 3.1 SDK, they’ve included all the previous iPhone SDKs to work with the new Xcode 3.2, thus eliminating my rage, but a little too late for the heartburn I was experiencing earlier this week.
Now, getting ruby on rails and our projects running on my laptop has been a bitch and a half and I’m still pulling teeth just to get things working locally. I was being a tool and just deploying all of my test code to the integration server to test for the past week and a half just so I could get some actual work done before Labor Day. I’m sure my co-workers didn’t appreciate that. :-p
Getting PostgreSQL working with ROR and installing the proper gem. I used to use pg but that was not working. I’m instead using postgres-pr and that seems to get mongrel up and working on my local environment. Make sure to change your ARCHFLAGS to ‘-arch x86_64′ if you originally had it set to i386.
I had to totally uninstall things like my MacPorts and rubygems and postgres and install everything from scratch again. I also had problems with my paths and I was constantly pulling up the wrong version (i.e. Snow Leopard’s version) of ruby and postgres.
Originally I had thought that just by recompiling everything the Ruby on Rails guys suggested, I’d be golden. But that just didn’t work out for me.
I think I am just going to reformat everything this weekend and follow this guy’s advice. What a mess!
Oh well, rant over. Hopefully I can post about a more successful Snow Leopard install next week.