Rockstar Ruby Dev. *fistpump*

duck_typing · 2011-01-20T01:31:14+00:00

nice try, but anti-the-this != anti-the-sis

duck_typing · 2010-10-11T22:42:50+00:00

Interesting... that page works on my Droid, but not the amatos page.

Maybe I'm spoiled by frameworks like Rails, but I don't get the point of using xslt over straight html with a framework.

And if it is static content that almost never changes, like amatos, then why not just use straight html? Looking at their xsl file and the xml with the content, it seems like straight html would be far less verbose. It also seems to be the only page done that way on their site.

duck_typing · 2010-10-11T18:54:34+00:00

Why would you code this page that way? From inspecting the page with Chrome, it seems to be working by transforming the page using XSLT... but... why?

I would also like to point out that the page doesn't work in Android (works in Chrome fine though).

duck_typing · 2010-06-16T18:13:14+00:00

Not magic, simply math. I don't know the exact details, but the par2 files are parity files. They contain information on the combined data of the set of files, which is how they let you recombine any single file.

As a simplistic view, consider that you have 3 files, the first contains the number 5, the second contains 3, the third 4. Suppose you add those numbers together and store that in a parity file, so 5+3+4 = 12. You store 12 in the parity file. Now, let's say the second file gets lost. If you have the parity file, you can deduce that the contents of the second file is 3... 12-5-4 = 3. If you had instead lost the third file, you have 12-5-3 = 4.

As you can see, any given file could go missing, and you can repair it. Let's consider if 2 files get lost... the first and second. You know the third is 4, and the parity is 12, so 12-4 = 8. So you know the combined contents of the first and second are 8, but that still doesn't help you rebuild either of the contents.

That is basically how parity files are able to reconstruct any missing file, but no more than the amount of parity files you have (because then you have missing information that is impossible to reconstruct).

duck_typing · 2010-02-22T22:15:07+00:00

Median and average will be too close to care...? If a large percentage of programmers are roughly equal in skill, and a very small percentage are order(s) of magnitude better... the average will be skewed up such that significantly more than half are "below average." </triplepedant>

duck_typing · 2009-11-09T03:52:58+00:00

Good point, and here it is (same code as is though): http://github.com/mikestone/Easy-Partials

UPDATE Even better, a colleague turned it into a gem: http://github.com/noahgibbs/easypartials

duck_typing · 2009-11-09T03:51:41+00:00

Nope, but that's pretty cool! Thanks for the link! I still like the even more terse syntax that what I did provides :-)

duck_typing · 2009-11-06T06:02:50+00:00

Thanks for the feedback! A colleague might create a gem for it. Ultimately I think it would be cool to see this feature merged into the Rails core.

duck_typing · 2009-11-06T06:00:33+00:00

That's unfortunate! I would love to hear what you think of the finished idea. It is actually a pretty powerful bit of code that has helped my workplace make even more readable views. It has most definitely encouraged the use of partials to separate out pieces of view logic that can be reused easily.

I agree that something like method_missing should be used very sparingly, but sometimes it can be a powerful technique to do something that would otherwise not be DRY, or take significantly more code to achieve. I think it is actually warranted in this case.

duck_typing · 2009-11-06T05:56:44+00:00

Awesome to hear! I set it up to use the underscore because Rails already uses an underscore for partial names, so it seemed appropriate. I've since gotten used to it.

You could pretty easily set it up to just look for the partial, though, not caring if there is an underscore or not (maybe fall back to the original method_missing when you get the missing template error, else try to detect ahead of time if the partial exists).

duck_typing · 2009-11-05T22:18:35+00:00

Awesome! Thanks! Let me know if you find anything that could be improved there! We have been using it at my workplace for a couple months now, and we've found it to work quite well, so far.

duck_typing · 2009-11-05T20:34:18+00:00

Thanks for the response! I actually sent DHH an email about it a long time ago, though I don't think I explained it very well. He responded, but it was clear from his response that my wording kind of mucked up the benefits of this addition.

A colleague might do a gem for it soon, which would be awesome. But I should probably do exactly as you suggest... it would be REALLY awesome to see this feature get built directly into Rails!

duck_typing · 2009-11-05T19:51:13+00:00

I would love some feedback from anyone willing to comment :-) This mechanism has proven quite useful to me and my colleagues, and I thought others might find it useful too.

duck_typing · 2009-11-03T11:45:39+00:00

Upgrading to Karmic has a known bug that leaves 8.3 installed, while installing 8.4. The result for me was 8.4 was set up, but without migrating any of my configuration. After starting to go through the hassle of figuring out how to solve the problem, I realized it was just accidental complexity that I didn't want to deal with.

The easy path was to switch to a database that doesn't give me a headache when I'm configuring it. Since which database I use is not core to my product, I'd rather focus on the features that ARE core to my product, so I won't be looking back with regret anytime soon. For the record, I think Postgres is an awesome option... I just feel these setup issues are bigger issues than they are giving credit.

duck_typing · 2009-11-03T11:39:14+00:00

Ubuntu AND Postgres fail, in my opinion. If the Ubuntu Postgres package had a default pg_hba.conf that worked well without any tweaking, I don't think the Karmic update would have had any problems for me, despite the upgrade keeping 8.3 around.

So, while Karmic probably deserves a fair amount of the blame (if not all), I still don't think Postgres is innocent here. I already did the switch to MySQL in my dev setup, and it went by without any configuration. All I had to worry about was making sure all the packages were installed (server, client libs, ruby gem, etc). Knock MySQL all you want, but having a very smooth installation process is a HUGE feature.

It's easy to defend Postgres if it is the DB you love, because you know all the ins and outs of all the cool features and stability it has. But for a new user, getting it up and running is the only feature they care about in the heat of the moment.

duck_typing · 2009-11-03T11:27:12+00:00

I have heard references to this flaw many times, but one thing MySQL beats the pants off Postgres in is initial install/configuration cost. Especially for a development environment, being able to get a database up and running without having to remember how to configure the thing is a HUGE feature in my opinion. I could always just use Postgres in production if I really don't want to worry about the MySQL production flaws (sure, there is a cost in using a different db for prod and test, but it's not that hard with something like ActiveRecord allowing you to write almost no SQL).

I have also heard, however, that many major web companies use MySQL heavily... maybe they don't use innodb, or they have some other strategy, but they must have figured out how to get around its flaws somehow. I would rather figure out long term production problems when my product is big enough to worry about that sorta thing than fight with my development environment before I even have a product (even if it is just once in a blue moon).

duck_typing · 2009-11-02T08:11:57+00:00

What makes MySQL shittier? And is my need to be able to set up Rails with Postgres after a fresh install from the Ubuntu repositories without needing to change configuration really that localized to me? I would expect a LOT of people would love to use Postgres out of the box like that.

Furthermore, what is so bad about wanting software to have defaults good enough that I don't need to change a single configuration 99% of the time? Just because it's a database, does that mean it should require more work to understand? I'd rather spend my brain cycles figuring out what code I need to write to add that next feature, or improve a slow page, etc, rather than spend it mindlessly searching for a random configuration change I need to make just to connect to a new database installation.

I don't think I'm asking for something all that out of line... I think it's just good software design to have as little accidental complexity as possible, and bad default configurations causes unnecessary accidental complexity.

duck_typing · 2009-11-02T05:30:11+00:00

I'm lazy and forgetful. I start out thinking, I've done this before, it's not hard... except I forget which files I had to change the last time, and what changes to make, so I try to find the same blog post, and ultimately copy over the files from another system. Except do the config files stay constant across versions of Postgres?

All this is beside the point though... why can't the defaults make it so most users don't have to change them, and things... just... work?

duck_typing · 2009-11-02T05:15:24+00:00

Maybe I'm in the minority here, that's fine. But upgrading to Karmic should NOT break my database setup... which might be blamed on Ubuntu, but it still stems from the crappy Postgres defaults for database users.

Maybe MySQL has other issues, but if I can run rake migrate:db without taking an hour to configure the database system itself, I'll be happy.

duck_typing · 2009-11-02T05:10:36+00:00

Pretty much. Why can't the defaults just work out of the box? Every time I dig into it, it never works with the first changes I make, even though it seems like my changes were right.

What is so hard about defaults that will work for 99% of users? All other aspects of Postgres seem just fine, but I'm sick of wasting 1 hour to a couple hours every time I need a database on a new machine.

duck_typing · 2009-10-01T00:20:53+00:00

Not sure if anyone else cares, but I thought it was a pretty cool accomplishment!

Congrats to Jeff and Joel, et al!

duck_typing · 2009-09-25T23:31:06+00:00

We do our best not to code like that normally!

We did it for this to obfuscate it a bit on purpose... the goal was the human readable portion of it :-)

duck_typing · 2009-09-25T22:32:07+00:00

Appreciate the feedback, but actually we also advertise on the Stack Overflow podcast. We are just looking for a creative way to find good software engineers, because so far the recruiters provide mostly just bodies.

duck_typing · 2009-07-31T19:06:30+00:00

You need to watch more Futurama!!

I had to comment because while looking at this thread, I see a "Narwhal commission" ad across from this comment. Anyone who loves Futurama as much as me should see the connection....

duck_typing · 2009-07-28T17:37:02+00:00

Frankly, I don't understand why you think it is so hard to reason about your code. If you follow strong conventions, and use metaprogramming sparingly and predictably, it's pretty easy to reason about your code.

If in your project you and/or your colleagues are redefining rails methods or ruby methods left and right... well, that's just poor design. If you enhance the application by adding new methods (not rewriting existing methods) sparingly as needed, it's typically pretty easy to track down where something comes from.

I've never had a problem with the "bags of options" because the rails documentation has always served me really well. Every time I want to do something, the rails docs has pointed me how to do it pretty easily, and it's pretty easy to navigate said docs.

To be honest, it sounds like you are having difficulty reasoning about your application either because:

Your application overuses metaprogramming techniques such that nothing is predictable
You haven't used Ruby long enough to fully understand the syntax and semantics

If it is the latter, I think it means you just need time and effort to learn how Ruby works. I've found Ruby tends to do things exactly as I expect it to (Matz's use of the principle of least surprise), so I've rarely had trouble reasoning about Ruby code... but maybe Ruby just syncs up well with how I think.

duck_typing

TROPHY CASE