My main website languishes, having no significant updates in over a decade. I repeatedly give up on my attempts at building even simple new games. And now even this crappy blog goes nearly two years without any updates. Why? Because I’m pretty much in an abyss of hellish real-life stressy balls of shit. A huge part of my lack of motivation (I think) is my day job. Continue reading “I’m not dead! Sadly, neither is Rails…”
This just in: DHH is still a douchebag
Ah, DHH. A lovely series of articles showing off your inexperience once more.
And this from an “industry leader” who should know better.
There are some wonderful quotes from the father of Rails that tell me he’s still the same douchebag he’s always been, and still has no idea how quickly complex projects go bad when built with his OMFG COUPLE EVERYTHING YAY mentality. Continue reading “This just in: DHH is still a douchebag”
HI IM RAILS I CAN HAZ MAGIC?
Again, why I hate all you fucking Ruby developers
I have a serious issue with Ruby magic.. no, wait, Rails magic… hmm, well no, maybe magic within the funky “sub-framework” I use?
Oh FUCKIN’ A, I don’t know. There’s a project I work on and it uses Rails. And it’s using an unnamed and incredibly shitty “sub-framework” (referred to henceforth as “Cyclops”) that forces us to use very specific gems whether we like it or not. In some cases the gems are cool, and in some cases they are the fucking devil himself. Continue reading “HI IM RAILS I CAN HAZ MAGIC?”
Dependency injection by any other name… still means you’re an idiot
Summary for those who don’t want to read yet another angry nerd rant
Dependency Injection is still Dependency Injection even if you use an approach that’s specific to Ruby 2.1 and decide to call it “Interception Injection”. Just like incompetent developers are still incompetent even if they start inventing fake patterns. Continue reading “Dependency injection by any other name… still means you’re an idiot”
Automated testing saves the day
I’m working on a Ruby on Rails application, where automated testing is an absolute must. Unlike Java or C++, you don’t have any kind of useful compile-time warnings and errors to tell you where you’ve screwed up, made a typo, etc. Most errors in a Rails web app happen when a user interacts with your code, so if you don’t test, you don’t know about bugs until it’s too late. This is one of many reasons I’m wishing for a nice C++ project to play with… but that’s another topic for another day…. Continue reading “Automated testing saves the day”
mod_rails (Phusion Passenger) Second Impressions
After my initial setup problems with mod_rails, I never really paid much attention to the thing.
It should be noted first and foremost that all of my problems setting up Passenger appear to indeed be my own fault.
So why no follow-up until just now? The thing has been running for around six weeks and I’ve yet to talk about it since that initial setup. Did I give up on it and go back to mongrel?
Definitely not. Continue reading “mod_rails (Phusion Passenger) Second Impressions”
Why Ruby is so sexy-awesome, part XXXIV
I use Ruby whenever I can. Not specifically with Rails – Rails extends the language and adds some nifty things, but the beauty is all Ruby’s.
Today I was using Ruby (in a Rails app, as it happens), and I had this “API” that returns generic hash data. I want to be able to take data from any source (Oracle, flat text, web service) and return data that’s in a very simple and easy-to-use format, so I chose to just convert data to a hash on a per-source basis.
But how do I handle typos in hash keys? What if somebody asks for “person[:name]” when they’re supposed to ask for “person[:full_name]”? They just get blank data and wonder WTF happened…. I can’t live with this situation, because it’s just too easy to forget a key’s name, or make a simple typo. I could return default data from the hash, such as “YOU FUCKED UP WITH YOUR KEY, SIRS”, but that could find its way into production and then I’m out a job.
So after a tiny bit of digging, I discovered that a Hash can not only have a default value, but also call a default block when a nonexistent key is requested:
irb(main):001:0> a = Hash.new {|hash, key| raise "#{key} not found!"}
=> {}
irb(main):005:0> a[1] = :foo
=> :foo
irb(main):006:0> a[1]
=> :foo
irb(main):007:0> a[2]
RuntimeError: 2 not found!
irb(main):008:0> a.default = nil
=> nil
irb(main):009:0> a[2]
=> nil
Normally I’m good with non-strict default data, but in this case it’s great to know I can actually validate data in a way that makes it hard to miss typos.
It’s not as safe as C++ (edge cases are only caught at runtime), but it’s far better than Perl (and nicer to read or write than both, IMO).
Phusion Passenger – first impressions
Okay, as I recently mentioned, I’m tired of Mongrel for my Rails apps, so I’m going with Phusion Passenger.
The install was actually tremendously more difficult than they claimed, but I attribute that to my own lack of smarts. I am running on Debian, and installed ruby via the source, but had another version of ruby I’d installed via apt-get (it’s over two years old, hence my desire to install from source), and libopenssl-ruby also installed via apt-get. Somehow or another the ruby I installed from source didn’t pick up openssl support, but debian thought it was there, so when Phusion Passenger’s install told me Just type ‘apt-get install libopenssl-ruby’, I got frustrated fast…. I removed the packages and reinstalled ruby from source and all seems to be well now.
Another minor issue, and one I still don’t fully get, is that while Passenger is supposedly running as my main user, it can’t seem to read things that aren’t world-readable, even if I am the file’s owner! A few permissions tweaks (chmod -R 755 app_dir did the trick, but I’m not sure it’s the best idea) fixed this, but it was still a small point of confusion.
The really interesting issue with Phusion Passenger is that if you’re security-minded like I am, it does not work. My base Apache config includes this:
# Tighten access to the file system.
<Directory />
# Forbid default access to file system locations
Order Deny,Allow
Deny from all
Options -Indexes
</Directory>
Well, I’m a dummy, so I don’t realize why my Passenger-driven apps are “running”, but unable to access their javascripts, style sheets, images, etc. After a long while of searching, I found that the errors were happening because my default behavior was to disallow everything from being viewed. The really bad part here? It’s clearly spelled out in the troubleshooting section of their guide….
Now, in a normal Rails app, the Rails code handles static files, so you can keep your blindingly-high security in place. But Passenger is meant to be speedy, and letting Apache just serve static content directly is way faster than letting Rails do it.
So to fix this, one just has to say that the given app’s directory is allowed to be viewed:
<Directory /path/to/rails/app/public>
Options FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
</Directory>
The following of symlinks and AllowOverride settings are of course a matter of personal preference and security, but you must have the other two lines to let Apache server your static content!
Okay, I’ve had things running for a few hours now, and I’m having a few weird issues. One time when I restarted apache, Passenger simply didn’t start up for some weird reason. A new Rails app I built kept thinking it had bad permissions – I reset the whole dir tree to 777, then 755, then all was well again for no obvious reason. (Yes, I had already set it to 755. I think. Maybe.)
So aside from these issues (which are hopefully just due to my almost nonexistent linux admin experience), so far I’m liking Passenger. I have no idea how it would handle a traffic spike or if it has issues with rarely-used apps, but its Rails-centric approach makes it much nicer for a dummy like me to use. Configuration is a breeze, it auto-spawns and auto-destroys Rails processes as necessary, keeping me from needing to manage memory, it spawns the Rails framework separately from the app, allowing a huge memory savings on multiple apps that use the same Rails version, and it has a really helpful memory stat tool to see how much my apps are really hurting things.
Only the coming months will tell if it’s as solid as Mongrel usually was, but even if it’s only as good (i.e., crashes for no obvious reasons once in a while), I’m sticking with it for its nice configuration options.
A new day, a new blogging app
Typo seems cool to us Ruby on Rails jerks. Because it’s Ruby on Rails. It has sexy live searching. Um… and like… did I mention it’s Ruby on Rails?
So… yeah. After the thing sucking time and again, and eating too much memory and having funny stability problems, I’ve given up. I have enough annoyances with Ruby on Rails apps (I truly hope mod_rails helps here – stay tuned for my upcoming first impressions) that I wrote myself – no need to make things worse with badly-built open source.
So here I am on WordPress. I’m willing to bet it’s just another badly-build open source app. The difference, though, is it’s been around the block, and seems to have some stability under the hood. It wasn’t written with the “do what’s cool right now!” approach – it has been more geared toward functionality. So as much as I despise PHP, I can’t deny that this app is much nicer to deal with than Typo ever was. Even the conversion of my old articles was about a 10 minute process, thanks to Will Bridges. And with some minor tweaks, I now have a (hopefully) nicer URL structure.
Yeah, I’ll lose some SEO in the mean time – major site change, loss of something like 50 old URLs, but hell, it’s time for something that isn’t a headache.
I’m sick of Mongrel
I’ve been running my Rails apps (this blog as well as Bloodsport Colosseum) via mod_proxy and mongrel. Run a mongrel server at a given port, tell Apache to redirect a given virtual host to said port. Takes a lot more knowledge than a noob like me has, so even though it’s better than dealing with fastcgi + Apache or lighttpd, it’s still annoying.
Once I got it up and running, however, I figured it was good enough – everything worked, so all was well. Until I had apps that weren’t hit very often. Bloodsport Colosseum is hit pretty regularly, and this blog seems to get pinged by random sources all the time, so both worked well. But my now-deceased fanmail app (granted it was really far too simple to warrant the RoR framework, but that’s a whole different story) was hit maybe every few days.
Mongrel did not like this for some reason. It seems that any app that isn’t getting regular hits just dies after a while. I read somewhere that it was mysql’s fault, closing the socket or something like that. Interestingly, my PHP apps that use mysql don’t have that problem, and on my last server (privately hosted by a friend and using fastcgi), my Rails apps didn’t have that problem.
Okay, fanmail app was kind of unnecessary anyway – I can just put my smart and not at all fat fan’s letters of praise on the main site, run via PHP, and that’ll be good enough.
Then I for once blogged a popular topic – the Network Solutions “scandal”. I was actually #3 on google for the search “network solutions domain name front running” for a little while. But the next day when I checked how things were going, I noticed that mongrel was “running”, but not responding, much like what I saw when an app wasn’t hit regularly. The process list would show a mongrel process using almost no memory (very atypical of a Rails app), and Apache would give an error that the proxying couldn’t happen. So the one time I’m really getting visitors (About 100x normal traffic levels for my shitty blog), within about an hour mongrel had decided it had enough.
I don’t believe mongrel can’t handle large traffic loads, I just think my lack of skills combined with mongrel’s funky behavior problems caused issues.
All in all, I’m tired of that – Mongrel keeps misbehaving, and I’m DONE. Time for something new. I’m trying out Phusion Passenger tonight and we’ll see how it goes.