Archive for the 'Programming' Category

Sep 02 2010

Ruby lovers rejoice! Net::YAIL 1.4.0 released!

Published by Nerdmaster under Programming

I suspect there are still some bugs, as I only have one bot I use to test the thing, but there’s a lot of really good new stuff. I’m trying to move everything that makes sense into github, so the changelog is available on the Net::YAIL github wiki. Highlights: there’s finally a topic-change event, you can now register a block as a handler, some core issues are fixed in parsing, and I’ve paved the way for object-based handlers and filters. Continue Reading »

No responses yet

May 26 2009

Diminishing Returns in Game Design: Exponential Decay and Convergent Series

Published by Nerdmaster under Programming

Finally, another exciting episode of NAME… THAT… DIMINISHING RETURNS FORMULA!!! Today we look at exponential decay and the convergent series, both of which are in my mind the only limit-based formula that should be considered for 99% of situations. Continue Reading »

2 responses so far

May 11 2009

Diminishing Returns in Game Design: Roots and Negative Exponents

Published by Nerdmaster under Programming

Okay, first off, this was supposed to be up a good while ago, but a combination of real life and work got in the way far more effectively than I had planned. Anyway, today’s diminishing returns formula is roots. Continue Reading »

3 responses so far

Apr 24 2009

Diminishing Returns in Game Design: The Logarithm

Published by Nerdmaster under Programming

For the first topic in programming a diminishing returns formula, I present: logarithms! Continue Reading »

4 responses so far

Apr 20 2009

Diminishing Returns in Game Design

Published by Nerdmaster under Programming

Diminishing what?!?

Okay, first of all, what is this concept of “diminishing returns”? Put simply, “diminishing returns” is the concept of getting less out of some system the more times you put in a constant amount. In the real world, diminishing returns are all over the place. Take, for instance, your body’s tolerance to alcohol…. Continue Reading »

4 responses so far

Apr 08 2009

myAutToExe and Ruby for the win!

Published by Nerdmaster under Programming, Security

As I’ve mentioned maybe once or twice before, I like myAutToExe a good deal. It’s great for tinkering around with AutoIt programs that have been “secured” by compiling to tokens. In some situations, being able to decompile these scripts is an absolute necessity Continue Reading »

2 responses so far

Jul 02 2008

IRC in Ruby still sucks? Check out Net::YAIL, the choice of a new generation

Published by Nerdmaster under Programming

After posting my super-deluxe-awesome-sexy actionscript hover tooltip code, I felt dirty. I mean, me, giving away the source code to something that I could surely have sold for at least $1.50 a shot! It was really disgusting to see such charity from the likes of myself. Continue Reading »

5 responses so far

Jun 23 2008

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 »

2 responses so far

May 16 2008

XML is still evil

Published by Nerdmaster under Opinions, Programming

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)

No responses yet

May 14 2008

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).

No responses yet

Next »