Disqus - Latest Comments for dkubb

Re: EdgeCase From Camping to Sinatra + DataMapper + Mustache (part 1)

dkubb — Thu, 29 Oct 2009 16:08:43 -0000

Great article. I haven't heard of Mustache much, so it's great to see some articles about it.

One thing I should mention is that in DataMapper, the default Resource instances respond to #[] and #[]= like a Hash, so unless Mustache does an explicit test like resource.kind_of?(Hash), you should be able to just return Tenant.all from the tenants method.

BTW If you ever need assistance with DataMapper, the mailing list is great, but the absolute best place is the IRC channel #datamapper on freenode.net.

Re: Three changes I'd like to see to DataMapper before 1.0

dkubb — Mon, 24 Aug 2009 19:56:08 -0000

One purpose of the has() syntax may not be clear is that in the future DM will allow you to specify has 0..1 for an optional relationship, and has 1..3 for a relationship that needs between 1 and 3 children to be valid. That could be represented with a has_one or has_many method, only more verbosely.

The Symbol API should probably be optional, but I disagree that it should be removed altogether. Sometimes you want to be able to write a simple query without dropping down to SQL, or having to use a more complex DSL. The Symbol API provides a nice way to query that covers 80% of the cases I encounter in a web app. Under the hood DM has a full criteria system which could handle a more complex DSL on top, something I've done with a plugin called dm-ambition.

I totally agree on the migrations. If you're interested in helping out, I would definitely appreciate it. What I'd like to see is a plugin written for the DataObjects layer that allows tables to be introspected/created/modified/deleted with a clean API. dm-migrations would then become a thin layer on top of this adding the migration DSL.

Re: Why Do Rubyists Test So Completely?

dkubb — Sun, 16 Aug 2009 22:23:20 -0000

"But are they the tickets we needed? Does SEL work? Because the 0.9.x series regressed in that there's no more pre-fetching, so SEL *must* work for it to be usable in production in a lot of scenarios."

SEL and relationships in particular ended up being the major focus of the 0.10.x (next) update. I ended up actually rewriting the relationship and SEL systems to pass the specs. My intention wasn't actually to do any of that, since I had a weak understanding of SEL and many to many relationships.

"And are there regressions between 0.9.x, 0.10.x and whatever Next is? And which should be used for production?"

Yes, I have ~4 tickets tagged with "regression", although I would expect a few more that I haven't had a chance to review and properly tag, so I'll guess there are probably about ~10 regressions. I plan to do one more RC for 0.10 to see if any more pop up, and then will do a 0.10.0 final once we resolve all the known regressions.

"I see tweets that JDBC support is passing and solid, but not on what 3 major versions."

I'm not sure precisely what you're asking for, but I should mention we have a CI server that shows which versions we are testing each time there is a commit: http://ci.datamapper.org

"I'm not blaming you for this. Clearly the biggest regression in the project history came from me in the 0.3.x to 0.9.x jump. Now that got a lot more people interested in the project with it's crazy new adapters-for-anything support, but it also broke a lot of things that were much more commonly used and long term obviously hurt the project."

I could write a list a mile long with mistakes I've made both in the code I've written, and in developing DataMapper. I think that's the whole point though, if you're not making mistakes and correcting them occasionally then you're probably not trying hard enough and most certainly aren't doing anything interesting.

Re: Why Do Rubyists Test So Completely?

dkubb — Sat, 15 Aug 2009 03:00:43 -0000

@ssmoot: I felt I should respond to your comments, although I do not want to hijack this post with something OT, so I'm going to try to keep close to the subject of testing.

I believe the decision to halt feature additions to DataMapper and fix the specs was the best decision we could've made.

One of the biggest problems that the DM 0.9.x series had is that there was no consistency in the specs or in the code submitted. People added code, sometimes with no specs, or sometimes with really bad specs. By bad I mean things like overusing mocks, to the point where it's impossible to refactor the implementation without completely rewriting the specs because the mocks know too much about the internal workings of the method. There were also things like huge "it" blocks with a dozen or more assertions for who knows what -- no one knew because the comment didn't accurately describe the purpose of the block. The only people who understood them were the original authors, and that knowledge fades quickly after a few weeks.

However, the biggest problem was that there was a lack of understanding in some problem areas by most of the core contributors, including myself. Aside from Sam, I've committed more code and closed more tickets than anyone, and if I can't make sense of how something works, either by reading it or the specs then there's a problem.

What we did was put a freeze (well not a total freeze, but close) on all new features, scrap the specs, and then start speccing the existing API. Now, the key thing we did wasn't spec how things worked, but how they *should* work. When there was a failing spec we either fixed the code, or marked it as pending and came back to it later. The important thing though is that over time we gradually rewrote major parts of DM, and ended up with a pretty solid spec suite.

The specs are not perfect yet -- I doubt it ever will be -- and we're still refining things, but we're much better off now than if we had just moved forward focusing on tickets and ignoring the technical debt we'd accumulated.

Even more importantly, we gained knowledge of most of the biggest problem areas, and just by forcing us to make the failing specs pass we resolved a ton of tickets associated with things like habtm relationships almost as a side effect.

BTW this process resulted in ~140 tickets being resolved.

I don't believe that just focusing on tickets would have had better results. Just before the spec rewrite, more and more of the tickets that were being resolved were the low hanging fruit kind, not the ones caused by fundamental limitations in the architecture -- many of which are fixed now, and those that are not are in a much better position to be resolved.

Would I do some things differently for the spec rewrite? Hell yes! For one I probably would've kept the original specs and gradually removed them each time there was overlap. Another thing I would've done is bumped the version to 0.10 immediately and started on weekly or monthly releases when possible in order to get more consistent feedback on the new code and show we were making real progress.

Re: roovo:web » datamapper - form friendly integers

dkubb — Sat, 27 Jun 2009 03:32:33 -0000

Rupert, this should actually be fixed in the new 0.10 series. The typecasting logic got a bit of an overhaul, so that now it only casts numbers to Numeric properties, and leaves everything alone so that it can be caught by validation code.

Re: Heroku | Gem Manifests

dkubb — Tue, 10 Mar 2009 17:39:48 -0000

This is awesome. You've removed pretty much the only barrier to me deploying my apps on Heroku.

Re: Magnus Holm - Nokogirl

dkubb — Wed, 04 Mar 2009 12:48:38 -0000

Hah! At least I know I'm not the only person who makes that mistake.

Re: test

dkubb — Wed, 18 Feb 2009 19:41:55 -0000

threaded reply

Re: test

dkubb — Wed, 18 Feb 2009 19:40:43 -0000

test

Re: Gem Weight

dkubb — Tue, 13 Jan 2009 07:02:20 -0000

Is there a way to figure out the free memory using ps on OS X? I tried something quick with `ps -o vsz=,rss= -p #{Process.pid}`, but the numbers didn't quite line up with yours, although they were showing the same relative sizes.

Re: Advanced Squid Caching for Rails Applications: Preface

dkubb — Sat, 25 Oct 2008 21:08:57 -0000

Alexey, you mentioned you used Squid for this, but have you tried Varnish? After hearing good things about it I experimented with it a bit with good results. I've not had a chance to test it with a high volume production system though and I'm curious to hear from others who have.

Re: An analysis of Ruby 1.8.x HTTP client performance | apocryph.org

dkubb — Sun, 05 Oct 2008 03:09:17 -0000

it would be interesting to see how an HTTP client written using Event Machine or even Revactor would perform compared to Net::HTTP and curb.

Re: http://adam.blog.heroku.com/past/2008/2/23/test_assumptions_not_methods/

dkubb — Tue, 09 Sep 2008 15:25:05 -0000

The mocks and "it" blocks appear to be standard Rspec syntax.

Re: http://adam.blog.heroku.com/past/2008/3/9/rest_client/

dkubb — Tue, 09 Sep 2008 15:25:05 -0000

I agree with your comments about Net::HTTP being too low level, and ActiveResource being too tightly coupled to the "Rails Way" of doing things.

The only suggestion I would make that would (IMHO) be even cleaner is to make it so that you create the Resource object using the URI, and then call methods on the resource.

Here's an example (please excuse the formatting if this comes out messed up):

resource = Resource.new 'http://www.example.com/users/adam/photos'
resource.post File.read('pic.jpg'), :content_type => 'image/jpg'

pic_file = resource.get

resource.destroy

Re: http://adam.blog.heroku.com/past/2008/3/14/rest_enlightenment/

dkubb — Tue, 09 Sep 2008 15:25:04 -0000

Adam, since you're getting into the whole REST way of doing things, I thought you might be interested in seeing this:

http://thoughtpad.net/alan-dean/http-headers-st...

It provides a neat flow chart detailing what status code to return for specific conditions.

Re: http://adam.blog.heroku.com/past/2008/3/18/a_taste_of_the_future/

dkubb — Tue, 09 Sep 2008 15:25:04 -0000

I love the idea of RSpec, but to me its become far too bloated. When there are problems, they are next to impossible to figure out due to the complexity of the code. It just doesn't seem like it should be as complex as it is for what it does.. or rather what I use it for day to day.

Those other projects are a break-away from the "popular" approaches. Hopefully soon we'll see a break-away from RSpec, or maybe an even a better approach from those projects themselves.

Re: http://adam.blog.heroku.com/past/2008/6/17/battling_wedged_mongrels_with_a/

dkubb — Tue, 09 Sep 2008 15:25:02 -0000

Anyone have any instructions for Merb and/or Rack handlers?

In my first attempts to use this library I tried to wrap the call in a begin/rescue block. I wanted to explicitly rescue Timeout::Error so I could return a 504 Gateway Timeout error to the client. However I seem to be unable to rescue the exception.

Re: http://adam.blog.heroku.com/past/2008/6/17/battling_wedged_mongrels_with_a/

dkubb — Tue, 09 Sep 2008 15:25:02 -0000

I'm firmly of the belief that stuff should fail fast and loudly, because problems tend to go unnoticed or ignored longer than if things sort of limp along.

I think if you set an upper timeout limit to constrain how long a request should take will only result in a better user experience. It'll also force you to think about really solving the problem by either optimizing the slow actions or offloading some of the work to the background. I'd even argue that 30 seconds is too long to wait before timing out, I tend to give up after 10-20 seconds of no activity in most cases.

Re: http://adam.blog.heroku.com/past/2008/8/29/objectoriented_file_manipulation/

dkubb — Tue, 09 Sep 2008 15:24:50 -0000

How does Pow compare to the Pathname class in Ruby stdlib?

Re: The Trifecta of FAIL; or, how to patch Rails 2.0 for Ruby 1.8.7

dkubb — Fri, 08 Aug 2008 02:57:21 -0000

Not to start a flame war or anything, but is it really the responsibility of the Ruby core developers have to know all of the ways Rails extending core classes so they know when it's necessary to warn people about their upcoming changes? On the other hand, the Ruby core team has a wealth of unit tests from popular projects like Rails and RubySpec to run tests with to see if their pending changes are going to break anything.

I'm sort of in the middle on the issue. Ruby core devs could do alot better job testing against popular ruby projects, while Rails core devs could do alot better job of not extending core classes when other options are available.

Re: Okito.net - Pipelined: Easy Event-Driven Programming for Ruby

dkubb — Thu, 12 Jun 2008 07:09:09 -0000

That's what I'd like to see the DO driver project become. Maybe you could use your influence to steer Sam in that direction? ;) I'll do whatever I can on my end with the DataMapper project to help.

Re: Okito.net - Pipelined: Easy Event-Driven Programming for Ruby

dkubb — Thu, 12 Jun 2008 03:12:07 -0000

We've been talking about making DataMapper work like this under the hood for a month or so. I'm not sure if it would be just for the DO drivers, or for all adapters, my preference would be to have this capability as widely available as possible.

If you've got any suggestions or you want to discuss this please hop onto #datamapper on irc, and ping me anytime (I'm dkubb).

Re: SOS!

dkubb — Fri, 20 Apr 2007 03:18:57 -0000

@Soundrel: I wasn't even suggesting writing a wrapper, I was more suggesting writing a "bot" that communicates with the script via the FastCGI protocol directly. You could run it directly against the app and raise any exceptions if the data comes out other than expected.

A wrapper seems like a more difficult problem to solve. A bot would simply need to simulate a FastCGI request, and log the response.

Re: SOS!

dkubb — Fri, 20 Apr 2007 01:07:46 -0000

I see no one's replied yet, so I'll throw my hat in. Not sure how much help I can be -- I'm not a PHP developer, but I have debugged PHP/FastCGI with LightTPD and Nginx before, so anything's probably better than nothing...

The weird part about this is that you tried Apache, Nginx and LightTPD and you got the same result with each. This plus the fact that strace shows PHP is sending all the requested information to the server is really weird.

Have you tried communicating with the FCGI process using a unix socket AND an internet socket? Can you eliminate the web server from the equation, and write a script that uses the FastCGI protocol to talk to the FCGI process directly?

When I hit a wall, I usually try to reduce things to the smallest number of moving parts and then try again. Close the feedback loop as tightly as possible. Eliminate the web server if you can. Try to compile PHP in FastCGI mode with no external library dependencies. Heck, even see if you can execute the script from the command-line with the ENV variables set to expected values and try duplicate the problem.