So, you’ve got a web server. It’s slow.
So, you optimize your app, and implement some caching. It’s faster, but not fast enough.
So, you decide to use Varnish, the popular reverse-proxy web application accelerator. It doesn’t work.
Well, client-side cookies are for the JS on your site; your application doesn’t actually care about them. BUT – and this is an annoying “but” – if those client-side cookies are set for “yourdomain.com”, then with every single request a reader makes to your server, those cookies are sent along.
And that means Varnish won’t cache anything, because it says, “Cookies?! EEK! No caching!”
So, how do you make Varnish happy with only the cookies that you want to keep?
I just read an interesting article at BusinessInsider.com entitled Why Programmers Work at Night.
The article explains why programmers generally tend to prefer working in the wee hours of the morning.
Programming requires keeping a lot stuffed in your brain at once, and thinking about all of it all at once. This task can often be a tad difficult under normal work/life circumstances.
This is why programmers are so annoyed when you distract them.
Because of this huge mental investment, we simply can’t start working until we can expect a couple of hours without being distracted. It’s just not worth constructing the whole model in your head and then having it torn down half an hour later.
In fact, talking to a lot of founders you’ll find out they feel like they simply can’t get any work done during the day. The constant barrage of interruptions, important stuff to tend to and emails to answer simply don’t allow it. So they get most of their “work work” done during the night when everyone else is sleeping.
If you have ever programmed anything, you understand the above 3 paragraphs perfectly.
Still, there is a better way…
On 25 December 2012, Ruby version 1.9.3-p362 was released. Is that dedication, or what?
Yesterday, I decided to upgrade to this new version of Ruby that contains only bug fixes.
Sure, the site loads… But if you try to create a new record via the front-end UI, it craps out with an Internal Server Error.
Digging a bit deeper, it seems this new Ruby version causes a “stack level too deep” error in /active_record/transactions.rb – at least when using Rails 2.3.x.
So, how do we fix this little problem?
Ya know, I program a lot. I also create a lot of web sites. So, having a good text editor is kind of essential.
For the longest time, I’ve been searching for a good programmer text editor like TextMate.
Unfortunately, I shun Macs like the plague since I can build better, faster, more reliable puters myself for 1/3 the price, so TextMate wasn’t an option. And I most certainly will not run a hacked version of OS X just to get TextMate!
At first, I used jEdit. It’s okay, but not quite what I was looking for. Then, I switched to NetBeans for my Ruby on Rails stuff, and Notepad++ for everything else. Well, that worked okay, but NetBeans RoR support is pretty lacking these days.
Furthermore, I wanted to get the heck away from these darn Java-based text editors. That’s really just silly.
Enter Sublime Text 2!
If you’re like me, you still have some Rails 2.3.x apps hanging around. Yeah, Rails 3 is awesome in some respects, but that “2x performance increase” never quite materialized.
In fact, for the most part, Rails 3 is still slower than Rails 2.3. SIGH!
Nevertheless, Ruby itself is progressing nicely. Ruby 1.9.3-p0 was released a few months ago. With faster garbage collection, startup, and file load times, Ruby 1.9.3 is where it’s at.
The only question is: What do you do to make Rails 2.3 play nicely with Ruby 1.9.3?
It’s actually not that hard!
Let’s say you were using Rails 2.3.x, and you made the (wise) decision to implement heavy fragment caching. Then let’s say that you updated to Rails 3.x. At that point, you probably noticed that Rails 3 does something seriously annoying with the paths where it caches fragments.
In Rails 2, doing this:
<% cache('posts/123/123456/main') do %>
Gave you a cache file that looks like this:
However, in Rails 3, the same cache code results in a cache file that looks like this:
WTH? That’s not documented in the Rails 3 API. So what’s going on, and how do you make Rails 3′s fragment caching work like it used to instead of using those crazy hash subdirectories? Read on!
In the olden days, video games relied heavily upon sprites given the rather severe limitations of computing hardware at the time.
You can use this “old” technique to reduce the bandwidth load on your server.
Most major web sites use them, but you may never have even heard of a sprite.
But what exactly is an image sprite, and why does it save bandwidth?
If you’re like me, you’ve got a Rails 2.3.x application running on Ruby 1.8.x – or perhaps Ruby Enterprise Edition. Well, that’s all fine and dandy, but Ruby 1.9.2 is about twice as fast as even REE 1.8.7. So, you’ll probably want to upgrade to the new version of Ruby.
Problem is, you upgrade Ruby and then your Rails 2.3 app starts whining about character encoding problems. Heck, it might not even run! So you search the net in vain trying to find a simple, step-by-step explanation of what you need to do to make your app run with the speedy 1.9.x version of Ruby. And, you pretty much come up empty handed.
Here I shall endeavor to outline all the steps necessary to install and convert your Rails 2.3.x app to work flawlessly with Ruby 1.9.x.
Okay, I know this one has been done like 8 bazillion times, but this method of creating a drop shadow on elements in a web page via CSS and a 1 pixel by 1 pixel transparent PNG file actually DOES work.
You see, I tried all kinds of different methods of creating drop shadows in CSS, both with and without an image file, and there was always a problem. It would render properly in certain browsers. It would render properly, but it only worked for fixed-width elements on the page. Or, maybe it would only render properly for variable width page elements. Or, the darn thing just didn’t work at all.
Well, I got tired of all of that, so I decided to make my own version of the CSS drop shadow. It may not be the prettiest, but it works.
Every web programmer knows that UTF-8 is where it’s at these days. Even if you are coding something for only the US market, you’re still probably going to run into names, addresses, or whatever with accented characters.
Everyone knows that “all you have to do” is make your app speak UTF-8, set the character encoding in your web pages to UTF-8, and set your database encoding and collation to something like
utf8_unicode_ci, and you’re off and running… right?
Not quite. You’ve probably run into the situation where you hop into phpMyAdmin and edit some table row, and what to your wondering eyes should appear, but something like this:
Voici un article franÃ§ais.
Well, crap. That’s supposed to be a “ç” in “français”, not an “Ã§”!
And yet, when you view the web page and edit the content in your app, it looks and works fine! What’s going on here?
It’s really quite simple, and apparently something that no one bothers to mention: you have to tell your app to communicate with the database in UTF-8! Here’s how you do that in PHP and Rails…