April 21, 2015   |   Comments

Bug in Apple’s Command Line Tools 6.3


While trying to install therubyracer gem I ran into a problem where it couldn’t find a debug file and would not build the native extension. Google reported that there is a bug in CLT 6.3 where a file is missing which is present in version 6.2. I couldn’t seem to downgrade because I don’t have a paid developer account so I thought I was stuck. A kind soul on [http://stackoverflow.com/a/29576048])(StackOverflow) found a workaround.

1
echo '#define _LIBCPP_ASSERT(x, m) ((void)0)' | sudo tee -a /Library/Developer/CommandLineTools/usr/include/c++/v1/__debug > /dev/null

Never one to be afraid of messing with my system because hey, it’s 2am, I’m tired, and furthermore, what could possibly go wrong? I ran the command, typed in my system password, and all seemed well. I then tried gem install therubyracer and it installed, finally.

I don’t use XCode much and didn’t actually know the Command Line Tools were/are used by Ruby so that’s something new to me. I also didn’t knwo that the might Apple ever makes mistakes. Ok, I actually knew that part. They don’t make a lot of mistakes, but not everything can be magical and just work. Thankfully I found a solution and was able to get the gems installed. Now back to my regularly scheduled late-night coding.

April 15, 2015   |   Comments

The Return of the Great White Hope.


After two years of taking a step back and trying other things, I’ve returned to the land of the living and have dived head first back into all things technical. Too many years of mediocrity had taken their toll on the passion for programming I once had. First computer when I was three, second when I was eight, first website in ‘96 when I was 18, and first programing job a couple years later. The journey from novice to professional was a quick one. I went from basic html to installing scripts, then to modifying scripts, then to writing custom code. From there it wasn’t long until I was programming large sites and doing everything else involved in maintaining large high-traffic sites. I learned on the job and learned just enough as I needed it. Never getting to use the latest and greatest but always stuck with old PHP and Perl code. I knew PHP pretty well, Javascript less well, a bit of Linux, some FreeBSD, quite a bit of MySQL, and on and on. I knew enough and it got me by.

Later I would leave the self-employed world for a jaunt on the corporate side of things, where what little passion I had left would die. Working on 10 year old code that had been touched by at least as many people. Cajoling it into doing things it was never designed to do. Never able to take the time for a decent rewrite because hey, it works well enough. Well, no, it doesn’t. It has more bugs than a crack den in the ghetto but that’s ok. I’ll add in some new code and try my best to patch it together. Who care’s about quality, right?

But that was then, this is now, and a two year respite has allowed me to reset mentally. Thanks to sites like Free Code Camp, Codecademy, and The Odin Project I’m all-in and learning very quickly. My overall plan includes the MEAN stack, Ruby, Rails, and then later Objective-C and Swift. Right now I’m working through an Angular tutorial as well as the Learn You Node stuff. I like to work through two at the same time so I can switch back and forth to keep my mind fresh. I also take a quick walk if I get stuck to do a quick reset on my thinking and not just keep beating my head against a wall.

That said, I’ll end this here and see if I can get it posted. It’s been two years since I’ve attempted a blog post and I’m having to relearn how to use Octopress. I have the source code to the page but not the source of my previous posts or how I had it set up. Yea, I’m regretting deleting all of my programming stuff way back when. Would be nice to have it now.

April 26, 2013   |   Comments

HAML Is Not for ASSETS


So in my gem file I had gem ‘haml’ inside my assets block like this:

1 group :assets do
2     gem 'haml'
3     --- other gems here ---
4 end

This worked fine locally and all was well. Then I tried to push an update to AppFog and none of my HAML files loaded. Nothing showed up in the error log but there was an obvious problem. A site without any layout isn’t much of a site. I tried a few things but couldn’t get it to work so I bitched about it on Twitter:

Deff something up with @appfog not supporting haml. Works 
swimmingly on local but shits the bed after deploy. #frustrated

Yea, I was a little frustrated. So converted my files over to erb and left it at that. Then I was contacted via Twitter by Alex Parkinson from AppFog who asked me about the issue. This prompted me to look into it a bit more and right off the bat I noticed my issue with the gem file. I tried moving the HAML gem outside of the assets block and what do you know? That worked.

Thanks to GIT it was trivial to track down my previous files, merge in some changes I had made, and then push the latest up to AppFog and now all is well and I’m able to use HAML.

I apologized to AppFog via Twitter and also Tweeted about my mistake. I have to admit, I’m impressed Mr. Parkinson took the time to Tweet me about this. Had he not I likely would have just stuck with erb files and would have presumed that AppFog had an issue with HAML when all along it was my own ignorance that was screwing me up.

April 24, 2013   |   Comments

Counter Caching


As promised, a blog post detailing the proper way to handle your counter_cache columns. A bit of a recap before we delve into the new stuff: I have a need to know how many goals a user has and of those goals, how many are completed. So I have a users table and a goals table. The goals table has a user_id field and a completed field. I join the two models together with user has_many :goals and then goals belongs_to :user. From that we can query how many goals a user has, and then how many goals are completed. We can improve this a bit with eager loading however when using eager loading, we’re loading a lot more data than we really need. All we care about is the total count and the completed count. Loading titles, descriptions, and all the other data in the goals table is very inefficient.

So we decide to use a counter_cache column but discover that apparently the fine folks behind Rails don’t actually ever use this feature, or if they do, they are using it in some manner unbeknown to me as for my needs, I’m almost always going to need to know more than just one count on a particular model. Goals and completed goals or books and how many of those have been read or well, you get the idea.

After a bit of time spent googling and researching this I came across a gem that is, as far as I can tell, exactly what should be in the Rails code itself. This is how it should work by default since the norm, again just my opinion is multiple columns rather than just one. The gem is called counter_culture and if you have use for a counter_cache column, and I think a lot of you will, then you owe it to yourself to give this a try.

INSTALL

1 gem 'counter_culture', :git => 'https://github.com/magnusvk/counter_culture.git'

Then run bundle install to install the new gem.

DATABASE

The standard rails migration generator is only going to get you so far on setting up your new files. You can go ahead and generate the migration scaffold but then you’ll need to manually add some code to that. For my needs I used:

1 add_column :users, :goals_count, :integer, :null => false, :default => 0
2 add_column :users, :goals_completed_count, :integer, :null => false, :default => 0

We want the field(s) to be integers and for this to work properly, you need to set null to false and default them to 0. These settings are why the migration generator isn’t able to generate the entire thing for us. Once you have your migration setup, you’ll of course want to run rake db:migrate to get your new fields added.

CODE

Next you need to add some code to your model. This is as they say, where the magic happens.

1 belongs_to :user
2 
3 counter_culture :user,
4                 :column_name => 'goals_count'
5 
6 counter_culture :user,
7                 :column_name => Proc.new {|model| model.completed ? 'goals_completed_count' : nil}

The first line is our standard belongs_to and there’s nothing special about it here. Next we have my first counter_cache column being setup. This is the standard one that will give us the total count of goals for each user. We are calling counter_culture on the model and then giving it the column we want it to keep updated. Simple enough I think.

The next block sets up my other counter_cache column and this one is a bit more involved. It starts the same with setting up the model followed by the column name, but when we define the column name we’re using a Proc so that we can dynamically determine when the column needs to be incremented or decremented. In this case model.completed is a boolean and will return true or false depending on whether or not this goal is completed. If you have a more complex situation, you can instead do something like model.completed? and then def completed? however you want. Just keep in mind that your completed? method needs to return true or false and it should work fine.

DONE

So there you have it. Simple once you get the hang of it. I actually had some trouble getting this setup initially and received assistance from @magnusvk, the creator of the gem, who responded immediately and was quite helpful. I think you’d be hard pressed to find a friendlier community than what Rails has. People really seem to go out of their way to help each other and it’s because of that, Rails continues to thrive.

April 23, 2013   |   Comments

Rails Counter_cache Frustrations


For my bucket list site I need to know how many goals each user has and of those, how many are completed. Doing this with eager loading is easy but less than optimal. After watching the RailsCast on the subject (#23 Counter Cache Column - RailsCasts), I was intrigued. This seemed like the ideal way to efficiently solve my problem.

I quickly set things up and for total goals, it worked perfect. Create a new goal and the counter would increment. Delete a goal and the counter would decrement. Get the count for goals for a particular user and it would only hit the user table. Nice, clean, efficient. Great, I was half way home. Went to do the same thing for the second column, the counter for completed goals and ran into a problem. You apparently can’t have more than one counter cache column like this.

Normally you set up the counter cache column with the name and then _count so goals_count would be the name if you were getting the count for goals. I thought goals_count and goals_completed_count would be ideal but no dice.

After a bit of research I found a gem that does exactly what I want. I’m still in the process of implementing this gem but expect a future blog post on how to use this gem in the next few days.