Older · View Archive (32)

WordPress Death

Goodbye Wordpress

I think we all were first exposed to blogs via Wordpress. So many templates to choose from, and underneath the fact that everything was stored in a database(mySQL no less) made it seem like genius.

But the problem you come to realize, at least for me, is the constant SPAM. Each time you go into your admin, it just seems like that are dozens of messages with nothing but gibberish.

Or my favorite…“Your website is the best I have ever seen, but I can make it ever better!” Just on and on. I think I even PAID some entity to stop the spam…what a ripoff..they are probably sending it.

In addition to that was the speed. Seems in the old days WP blogs were pretty fast, but I guess after years at the keyboard, you become microwave sensitive to the speed and bandwidth. Whenever I went into my blog to make simple changes…everything was just too slow. And everytime I wante to do some type of small CSS related change..well…you had to dig deep. There was a lot of code (PHP) they you just needed to get past the learning curve on. Ahh…The infamous Loop!

I wanted a blog for my Ruby on Rails career, because..I mean…in open source you gotta have a blog right? At my previous gig which was IBM iSeries…well…we never had a blog. EVERYTHING was in the manual! But times have changed. These days many parts of your life and business are an open book to the world, and I suppose you have to play or you must be hiding something.

My ISP account expired in my WP blog, so I decided to go another more simple path. It was right in front of my face…GITHUB..which led me to Jekyll. This is my first post under my new path, and I really like it. And to top it off…I have complete control of my content/data as well as my code. It’s great that under the surface its Ruby which is icing on the cake.

My old ISP wanted $75 to restore my old blog content, and you know based on principle I just could not do it. I decided to start totally fresh. So that’s how we got where we are. Time to go. Happy New Year.

1
2
3
def say_goodbye_wp
puts "Good Bye."
end

Newer

RVM tips

RVM Tips

Anyone who sets up a ROR rails environment sooner or later will bet directed by some link or comment to RVM. I for one initially found the website documentation hard to read and find things, but I guess that’s because I did not know RVM.

Usually when you are learning rails, the last thing you want to do is start up yet another learning task. But this is one that probably you need to do first, and save the others for when you get going.

I will list the things I find most convenient and helpful about RVM. Most for my own reminding because there are tons of sites out there that go way more into it. There are other things out there(rbenv being one), and I actually wanted to try it. But it is not compatible with RVM on the same box, so go figure. You can’t go wrong with any, just choose one.

RVM implode

This may happen to you, and it did happen to me. I somehow got my environment messed up, or I guess you could say somehow my gems and dependencies got out of sync. No matter what I tried, I kept getting some weird error message everytime I tried to build and run my application.

I figured i needed to start from scratch with a fresh install. But how?

Used rvm implode from the terminal to remove all traces of RVM. If for some reason it does not get everything, it will tell you just to manually delete your .rvm directory.

After that, just reinstall RVM. By the way, this action will also remove all of your existing GEMS etc that hopefully you installed with RVM in the first place. Install RVM(which will install ruby), and then install rails. With each you do have the option to say what version of ruby and rails you want, and in fact, in my case I went back to one that I know was working with what I was previously doing. I think somehow the latest version of Ruby was not playing well with my Jekyll.

1
2
3
4
def use_RVM
puts "rvm implode"
puts "To remove all traces of RVM installs and start over"
end

What RVM is good for

In a nutshell, RVM will let you switch between different versions of Ruby. This is good when you want to check out something under an older version(maybe you are maintaining an application that is not upgraded yet), and also when a new release comes out. You want to be cautious just in case it breaks something in all the things you are currently working on.

Secondly, RVM lets you manage your GEMS as collections. As you know a rails application uses many gems, all with versions. And with many of them having dependencies on other gems, just updating or installing one can quick lead to some kind of mess where you don’t know where you are, especially with something does not work.

So what you can do is, for each new Rails application, create a “gemset” that will be a compartmentalized environment built just for that application. In that way when you install or update the gems, it will have no impact on the other apps you may be working on.

Now to me, that always seemed a bit redundant, in that often times you are installing the same gems over and over. But in the long run, using this little bit of extra storage will pay off in a more clear and trouble-free workflow.

Here are some quick RVM commands to know before we get into setting up gemsets:

1
2
3
rvm list(to see a list or Ruby versions on your machine)
rvm gemset list(to see a list of gemsets)
rvm gemset use gemsetname(switch between gemsets)

Creating Gemsets

Let’s say you are checking out a Rails application you download from Railscasts, and its asking for some GEM version. You jump into terminal and grab it. Did you know that without using Gemsets, you just updated or changed that Gem for your other rails apps you may be working on? Thats because without Gemsets, your “rails environment” which is composed of gems may change each time you update or download a gem.

If you use the RVM gemset feature for each project, then each project will have its own specific set/versions of rails. So the way I do it, for newer stuff where I always want the latest, I use the latest gems.

But in some cases when I am testing out something that maybe be several releases old, I will set up an environment just for that app.

One way to create a gemset is as follows: Let’s say you have ruby-2.2.0 and want a gemset for your new app call “myapp”

1
2
3
rvm use ruby-2.2.0@myapp --create
gem install rails 
rails -v

This will create a gemset with the name “ruby-2.2@myapp” using ruby 2.2 and the version of rails installed. Each time before you go into your app directory, you will issue the rvm USE command, unless you create a “sticky gemset” which I recommend.

If you want a specific version of rails, change the “gem install rails” to “gem install rails –version=##.##” where ## is the version number.

Sticky Gemsets

As you saw once you create a gemset, you need to set it or “use” it each time before you go into your app directory. A better way is to create what is called a ‘sticky gemset.”

RVM gives us a convenient technique to make sure we are always using the correct gemset when we enter the project directory. It will create hidden files to designate the correct Ruby version and project-specific gemset.

Enter this command to create the hidden files:

1
rvm use ruby-2.2@myapp --ruby-version

This will create

1
2
.ruby-gemset
.ruby-version

The –ruby-version argument creates two files, .ruby-version and .ruby-gemset, that set RVM every time we cd to the project directory. Without these two hidden files, you’d need to remember to enter rvm use ruby-2.2@myapp every time you start work on your project after closing the console.

(see RVM website on using gemsets)