How can a crappy site with boring games waste more space?
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”
I love people. Everybody who knows me is aware of how much I respect and admire the average person. Software folks are no different. Most of them are very intelligent and never say stupid things regarding topics about which they have almost no experience.
So while I wasn’t terribly surprised to see that XML is still crap, I was utterly shocked to see that people still defend it.
PEOPLE, LISTEN THE HELL UP. It’s very simple. XML was built to mark up documents, not to store data. Here are some choice comments from really smart people:
XML became the default because of its flexibility in data formatting. And, because it has become so ubiquitous, almost all programming languages have built in ways of easily parsing XML. In fact, I do almost all of my web output using XML and then use XSL style sheets to transform it into HTML. I remember some blogger, can’t remember his name, blathering on about MVC and how you should make your output “skinable”. Well, if you produce XML output, your webpages are extremely skinable.
The problem here is that you’ve apparently killed most of your brain cells by listening to idiots tell you what to do all your life. XML is flexible for sure, but the problem is how it’s abused. XML is used for everything. SOAP is the worst example. XML is not for data storage. It is not okay to store data that isn’t meant to be human-readable in a TEXT-ONLY FORMAT. Have you ever seen how much smaller binary files are than text files?
Skinnable websites = marked-up documents. That’s what XML was built for. I don’t even like it for that very much, but it does work fairly well in that capacity. Marked-up data is a completely different situation.
I’m afraid I couldn’t disagree more. No, XML isn’t the easiest to read (by humans) of all the infinite number of alternatives out there. No, XML isn’t the most efficient in terms of space. And yes, perhaps it has been forced into places it was never intended to go. But you miss what I think is the most important point: it is rapidly becoming a standard way of representing information. I would argue the value of having a standard far outweighs the inefficiencies in most cases.
I would argue that you’ve been brainwashed by people who are only slightly stupider than yourself. XML as a standard isn’t a good thing, but even here your “logic” is nothing but a straw man argument. The author of the post didn’t say standards were bad, and didn’t even say XML didn’t make sense anywhere. He said XML wasn’t the best choice for every place it’s being used, which you have already admitted!
You’re an embarrassment! It’s not good to have bad standards! Look at SOAP! It is good to always look for a better choice. Where the fuck would you be without people ten times are intelligent as yourself always looking for better options? You’d be a fucking caveman. We evolve, we look for better options, we find better ways to get a job done! Standards are fine, but without constant analysis and reconsideration of those standards, our industry would never go anywhere. How can you claim to be an IT person and yet not understand this?
Following a link from that site to an old JSON vs. XML debate, I found even more idiocies. But one in particular just shouts out about the morons who’ve managed to become part of my industry:
As Dr Phil asks — What were they thinking?
No doubt I can write a routine to parse this, but look at how deep they went to re-invent, XML itself wasn’t good enough for them, for some reason (I’d love to hear the reason). Who did this travesty? Let’s find a tree and string them up. Now.
This is bad. This guy is a total moron. I mean, he didn’t even bother to investigate JSON before he said this most absurd of arguments. Not only is he saying, “Let’s not reinvent the wheel for any reason, ever” (which should be a blasphemy to all computer science disciples), but he’s saying JSON makes no sense for anything, ever. JSON may not be your cup of tea, but it’s faster than XML when used in Javascript (eval vs. parsing XML – sorry, but if you can’t figure that out, you’re just a dildo – only you probably get less sex) and for the most part, more human readable and writable.
Oh, but Dave Winer (Whiner?) gets even worse:
Dan, where are the benchmarks that say that on a processor capable of running Flash apps or playing Youtube videos that it can’t parse XML “cruft.” If you’re going to use an engineering argument, be prepared to back up t your assumptions with data. I’m pretty sure you can’t because I ran my own benchmarks on the end-user CPU of the late 90s and the overhead of parsing XML was negligable then, and now..? Geez Louise. How many gigahertz to people have these days??
XML parsing is a monumental task. This is clearly the ramblings of some dumbshit who’s never actually used SOAP, XML-RPC, or even plain old XML with XSLT on large data sets. Parsing tens of thousands of records (serialized from the Oracle DB because XML is so great) at my current job is a nightmare. XSLT transforms in some cases take 5 minutes or more, on blazing-fast hardware, using a C++ library (libxml and libxslt). In the late 90s, you’re going to try and tell me XML parsing had “negligable” (IT’S FUCKING SPELLED “negligible!”) overhead? What did you parse, “<hello />world” or something?
Fucking idiots. There’s a reason enterprises that were stupid enough to follow the XML trail are now buying XML-parsing hardware.
My comment is this – if you’re in the computer industry, don’t shoot your mouth off about things you’ve only thought about for 2 minutes while you jerked off to pictures of your dad. You sound like a moron when you do. Me, I’ve used XML in the real world. And a tiny bit of JSON, and a good deal of YAML (I even jerk off to YAML now and again). For marking up documents, XML is fine. For data that needs to be human-accessible, YAML and JSON are so incredibly superior, it’s a joke. Try them out in real situations before you make a total ass of yourself. Yes, I’m talking to you, Dave.
(Yes, I read his “ooh I dun learnt alot in that there diskusshins” follow-up. Ignorant bashing is ignorant bashing, regardless of your “oops” responses later, people)
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).
I’m sure I’ve bitched about open source plenty of times, but I have to rant once again. Dotproject is my project management application of choice. It does everything I want, and in particular allows for very awesome time estimation which was extremely useful for Bloodsport Colosseum. I was able to break down every task into subtasks and really get a feel for how much effort was left by looking at the accuracy of past estimates.
But it’s programmed by idiots. I mean, these guys are actually pretty stupid compared to the average rock. I’m sorry, it’s a great tool designed by somebody who had a head for project management, but programmed by idiots.
After not using dotproject for a while (after the death of bloodsport colosseum, I had little to track), I got a contract job that really needs careful design. So I jumped back into a semi-recent version of this awesome/disgusting app, and found that it uses overlib for popup help! (No, that isn’t the problem. Overlib is actually really nice for web-based hover-help) But the dotproject devs by default chose to make the popups STICKY. That is, when you hover over a link you think is just a link, a popup shows up that will not go away until you explicitly mouse over the “close” button.
This is revolting.
So I know overlib. I’m not phased a bit. I used it for Bloodsport Colosseum and it’s really a pretty straightforward JS library (a rarity these days). It’s open source, so it probably sucks monkey balls, but as a user of the tool, I liked it.
Overlib has a central area to put all your app’s default preferences for things like font, colors, opacity, and, of course, sticky. To override the defaults, you can actually specify “commands” in your call to the overlib methods, which is handy for special cases.
The dotproject dimwits actually ignored the defaults altogether, and put the exact same preferences into their HTML in seven different places. I’m not sure what can happen to a programmer where they learn the number one failing of software. The first thing you learn in your first CS class is about code reuse. Functions, code centralization, that sort of shit. HOW can somebody be so stupid as to ignore these amazingly simple principles when the library already provides a really easy and central place for this stuff?
Then I remembered my first dotproject disaster – an old version had some broken SQL for calculating the % left on a task, and to fix it I had to change this SQL in 3 or 4 places, and rewrite a couple rather large sections of code.
No, that memory didn’t comfort me, but at least I was able to say, “Oh yeah, they’re just dotproject developers. They didn’t know better.”
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.
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 can’t believe this. Simply amazing.
I really can’t.
I’m not even sure this is good enough to fall under my usual “Awesome Software Discovery” banner.
So I work at a place where we use Ruby and Perl a lot, right? The above site is supposedly a “conversion” of O’Rielly’s Perl Cookbook into Ruby. Good idea. But here’s the thing – if you don’t know your ass from a hole in the ground, maybe you shouldn’t be writing a programming guide. Maybe. I don’t know. Am I being too harsh?
The introduction shows this example:
# $defout (or its synonym '$>') is the destination of output
# for Kernel#print, Kernel#puts, and family functions
logfile = File.new("log.txt", "w")
old = $defout
$defout = logfile # switch to logfile for output
puts "Countdown initiated ..."
$defout = old # return to original output
puts "You have 30 seconds to reach minimum safety distance."
There is no fucking excuse for this kind of programming style. Even a total noob should look at this and say, “What the fuck?”
In any case, here’s how you write to a file in Ruby without making the guy who reviews your code cringe and then stab you in the fucking eye (note that it’s not only safer, but also easier to read and generally doesn’t make you look like a moron):
# $defout, $stdout, and other magic variables are NOT TOUCHED!
logfile = File.new("log.txt", "w")
logfile.puts "Countdown initiated..."
puts "You have 30 seconds blah blah I'm a monkey licker."
Neat!
As I previously mentioned, I like AutoIT a great deal, but I like decompiling other people’s stuff even better. Just a couple days ago, the genius who brought us the only 3.2.6 decompiler released a new version, 2.2. I haven’t kept up like I should, but if cw2k ever gives me the okay, I’d gladly keep up a mirror as he releases new versions. For now, at least, I’ll just try to remember to check back regularly and grab the latest versions.
So if you want my local copy of myAutToExe 2.2, it’s here. If you want to get it from the source, check out either the main forum thread or the actual angelfire site.
Enjoy!
I’ve been using Perl professionally for about four years now. I never really loved the language, but I certainly didn’t hate it quite so much before this job.
There are many obvious reasons to hate Perl:
* The hacked-in OOP never impressed me much, but gets really old after working on a very large application for a while.
* Exporter is evil – being able to pollute somebody else’s namespace just by their use of your module is truly horrific. Most modules are smart enough to only export things as requested, such as use Foo qw|cool_function|; or use Foo qw|:cool_functions|;. But the fact that you can choose to have your module muck up others’ namespaces is terrible. And the fact that there’s nothing akin to the C++ using namespace Foo; in Perl makes it highly annoying to do things the proper way and not pollute your namespace.
* The lack of real exception handling is amazing. Look at how the Error module works sometime if you want to be disgusted. The way it works is so awful, and has some really nasty side effects if you’re not careful (like not being able to return from a try “block” because it’s really a function and not just a code block — or how a missing semicolon generates no errors, but can do some incredibly strange things).
But today a more insidious problem struck. I wanted to make a mock class based on the BerkeleyDB class. When we write a unit test, we need to test that our program logic works, not that the BDB class works, right? So I’ll just write a mock, right?
WRONG! The method we use the most is $bdb->db_get($key, $value), and due to the magic of XS bound to C, the second parameter, $value, gets set to the given key’s value. In a normal Perl function, you must send a value by reference in order to have it changed by a function: normal_method($key, \$value). But we can’t change the calling convention for this mock class to work – the point of the mock is to make it a drop-in replacement used just during testing!
So I looked into method prototypes to fix this for me. A method prototype in Perl is a powerful thing that can allow you to “convert” a normal argument into a reference, such that my mock BDB class would be able to keep the same calling conventions as the real one (which is kind of essential for a mock class). So I did something like this:
# db_get takes two or three arguments - the second is by-reference
sub db_get($\$;$) {
my ($self, $key, $value, $flags) = @_;
$value = $self->{$key};
return 0;
}
Beautiful solution, considering how annoying Perl can be. Just one little problem: class methods can not use prototypes. There is no warning, no errors, no indication of what’s wrong whatsoever. The prototype is simply ignored. Silently. After reading the documentation a while, a coworker was able to point out the problem, and I was forced to use the real BDB class instead of a mock in order to complete my unit testing.
I could, of course, write some XS and C in order to get a mock class built, but that’s just an absurd solution to the problem.
I could also write a wrapper and retrofit all our current code to use the wrapper, such that I have complete control of the new API. The new API for the real and mock wrappers could easily be kept in sync. This, however, is even more absurd a solution, because it requires a lot of code to be changed.
That the inconsistent nature of Perl causes such headaches is just one more reason that Perl sucks. A whole lot.
Now to be fair, Perl wasn’t really meant for large-scale applications when first built. But instead of fixing things the proper way, new features seem to be done in a very band-aid sort of way, instead of fixed properly. Perl 6 will deal with a lot of this, but I suspect the conversion won’t be worth it, considering how many better options there are nowadays.
I’m a huge fan of AutoIt – I think the program is a wonderful tool for administrators as well as casual programmers who just like to mess with stuff. However, I recently discovered that the developer of AutoIt, in an ongoing quest for “security,” has disabled the ability to reverse-engineer autoit scripts!
Now, I’m all for security when people write software, but giving scripts this level of security actually introduces security risks! I just don’t like running some random AutoIt script without being able to look at the source code. If I run a “normal” compiled app, my virus scanner will generally let me know if it’s safe to run. But a script written in AutoIt can so easily be a trojan (or other destructive tool) and nothing can likely catch it because of the nature of scripted programs.
Yes, I’m aware somebody could write a C++ app that’s just as dangerous as AutoIt can produce, but this requires a lot more intelligence and effort than just writing an AutoIt script. AutoIt is made to be pretty friendly for non-programmers.
So to me, this is an absurd limitation – all scripts should be reversible for the sake of security! Luckily for the world, somebody has written a usable decompiler called myAutToExe, and I’m providing a local copy of 2.00 Alpha since the site is hard to find and hosted on Angelfire. For the original and latest versions, go to http://defcon5.biz/phpBB3/viewtopic.php?f=5&p=5735.
Note: I haven’t contacted the author of myAutToExe about this (the page has no contact information). I can’t imagine he’d complain, but if anybody knows a way in which I can contact him, I’m all ears. I’d love to set up a proper mirror.
UPDATE: I’ve updated the link to the latest version since being contacted by cw2k (the author of myAutToExe).
UPDATE UPDATE: Fixed the URL for getting the latest version – apparently the forum site moved.