Disqus - Latest Comments for dkubb

Re: Canadian Sony PlayStation 5 (PS5) Pre-order & In Stock Tracker - NowInStock.net

Dan Kubb — Sat, 28 Nov 2020 17:01:33 -0000

I could code one, but the problem is it'd be cheaper just to pay the scalper price. It only really makes sense to write a bot if your time isn't worth very much or you plan to become a scalper yourself. :(

Re: Shellshock BASH Vulnerability Tester

Dan Kubb — Fri, 26 Sep 2014 12:06:25 -0000

A slightly nicer way to append text to /etc/shells is:

echo "/usr/local/bin/bash" | sudo tee -a /etc/shells

Re: Liskov Principle & MiniTest

Dan Kubb — Thu, 18 Jul 2013 18:07:33 -0000

I've wished there was a way to inherit an existing RSpec example, rather than having to break it out into a shared example explicitly. It does feel clumsy compared to MiniTest's inheritance approach.

Re: Customize Attribute Accessors on Ripple Models

Dan Kubb — Thu, 12 Jul 2012 13:16:56 -0000

Did you mean for the first argument to property() above be the Symbol :stuff instead of stuff?

Re: Optional Observers With Rails 3 and RSpec

Dan Kubb — Thu, 12 Jul 2012 11:42:47 -0000

Disagreement isn't trolling. Someone taking the time to disagree on a blog post is an opportunity for learning, even if no one's mind is changed. It's good to have alternative approaches in your toolkit so you can weigh them against the familiar or convenient.

Brian already mentioned making side effects explicit in a method. Another technique that works well is to have an explicit service object that handles orchestrating sending messages to multiple decoupled objects. James Golick has a good article on this: http://jamesgolick.com/2010...

Another approach is to use a state machine to model side effects. I don't mean the state machine type gems which jam a status field and a bunch of DSL code into your models; I mean having an object to represent each state, and then having methods that handle explicit transitions to other states. It's usually the case that the side effects happen when moving from one state to another, so the transition methods are a good place to have side-effecty code.

The common complaint (especially in the Rails community) is that alternatives like the two I mentioned require lots of overhead or ceremony. I will agree there is a bit more code, but if done well it's not so significant that it automatically invalidates the techniques. It's especially common to violate SRP for convenience, and I would argue that sometimes the "Rails Way" is less clear than doing things explicitly.

I've used Brian's and the techniques above to significantly improve the understandability of code with side effects, and I highly recommend considering them next time you're considering callbacks or observers.

Re: solnic.eu

Dan Kubb — Mon, 09 Jul 2012 15:44:53 -0000

Yeah, there was some initial question on twitter on whether or not Piotr should post this article. Like maybe this had been done to death.

I can understand why some people might feel that way, but at the same time, like you said, there are a shockingly large number of people who haven't developed basic TDD skills. They still view it as a primarily verification tool, rather than a design tool.

Maybe it's not a basic skill then, maybe it's an advanced one.. I dunno. I just know we need more articles attacking things from different angles, so we can discuss our approaches out in the open and come to a better understanding of what does and doesn't work for people.

I'm not interested in finding "the one true way", but I am interested in hearing the things that work for people and what doesn't so that I can try them out for myself.

Re: Engine Yard is Teaming with Red Hat on JRuby

Dan Kubb — Tue, 22 May 2012 19:17:14 -0000

It could also be something that aids in hiring too. For example, Aaron Patterson, Ryan Davis and Eric Hodel all work for AT&T interactive and (according to Eric at Ruby on Ales), they're all paid out of the recruiting budget. For many developers, working with the same people who develop the tools you use everyday is quite a draw. I've taken a few jobs that I wouldn't have otherwise considered because I was able to work with people whom I already know are excellent developers from their oss work.

Re: Get Rid of That Code Smell – Duplication

Dan Kubb — Tue, 15 May 2012 17:24:07 -0000

I should also mention that the code Piotr shows that was not a good refactoring has since been changed, no longer includes that questionable code and is now much simpler: https://github.com/solnic/v...

Re: How to get four times the throughput out of Heroku with Unicorn

Dan Kubb — Thu, 10 May 2012 17:13:59 -0000

I wonder about using unicorn w/ree on the bamboo stack. Since it's behind nginx (or is it varnish?) it wouldn't be susceptible to slow client attacks. Also using ree might allow for more efficient memory usage in the forked children due to the benefits of COW (Copy on Write).

EDIT: I mistakenly said the "cedar" stack when I meant "bamboo", which is the one that offers ree and a front-end proxy.

Re: Static code analysis will do you good — Rendered Text

Dan Kubb — Mon, 23 Apr 2012 23:17:51 -0000

I've gone through this exact process too, and I highly recommend it. It's really easy to dismiss some smells as not important, but trying to dig in and resolve them will teach you a lot.

For an existing project one approach I've used successfully is to use the current state of the code as a baseline. I promise myself that no matter what I won't let the code quality regress and I won't let any new smells get introduced.

Next, I setup a site.reek file and add exceptions for anything that it flags so that reek passes. Then I'll start slowly ratcheting the settings and remove one exception from the config so it causes reek to fail, then I go and fix the problem. Rinse and repeat.

It's not an overnight process, but if you spend (say) a few hours every week it's amazing the progress you can make after a short time. It's also a great way to start off a coding session and especially effective at working around coder's block.

Re: Ruby 2.0 Enumerable::Lazy

Dan Kubb — Fri, 23 Mar 2012 13:20:08 -0000

I'm working on some patches to backports to bring this to 1.8/1.9 users https://github.com/marcandr...

The process with backports is you make use there is rubyspec coverage for the feature (which there isn't, but I'm working on it), and then you submit the patch to backports. I should have something within the next few days though.

Re: Ruby 2.0 Enumerable::Lazy

Dan Kubb — Wed, 14 Mar 2012 12:36:31 -0000

I'm considering sending a pull request to the backports gem so we can have this feature in 1.8 and 1.9: https://github.com/marcandr... .. I don't know if it'll be accepted, but I'm pretty optimistic since it does backport lots of other 1.9 Enumerable features.

If anyone has any feedback or suggestions on the code spike I've written I'd be happy to hear it.

Re: Ruby DataMapper Status

Dan Kubb — Fri, 17 Feb 2012 12:32:08 -0000

Yes. When I designed the RDBMS adapter for Veritas I was thinking about how to support prepared statements and designed it so it should be easier to add in the future. I still need to work with Dirkjan on DataObjects (our database driver) to get it supported there, but once it is I don't think it'll be to difficult to integrate.

Re: Web and mobile consultancy specializing in Ruby on Rails ~ DockYard

Dan Kubb — Thu, 16 Feb 2012 13:36:13 -0000

I use this exact system too. For me it's not so much about performance, but about communicating my intention. If I have a single quoted string, you know that nothing is going to be interpolated in it, so you don't have to scan it looking to see how it's going to be modified at run time. With a double quoted string, it requires a bit more effort to understand because you have to scan it looking for the #{thing} inside it.

Re: Yes, You Should Write Controller Tests!

Dan Kubb — Thu, 02 Feb 2012 14:58:39 -0000

Justin, I know you're on the rspec team and I wanted to ask if you think the way Piotr is declaring/using the subject above in a way that was intended?

Piotr and I work together and while we both follow this style, there was question a few months ago on whether or not we were abusing subject. While we were using it to describe the method that was under unit test, it was thought that the subject should be the main object under test.

Re: Ruby DataMapper Status

Dan Kubb — Mon, 16 Jan 2012 21:35:43 -0000

We chose code names for many pieces to discourage usage except by the early adopters and the people helping get things in order. Many of the libraries will be renamed when we're ready to actually start the alpha/beta process.

Re: Ruby DataMapper Status

Dan Kubb — Thu, 12 Jan 2012 15:49:34 -0000

That's a really good question, one that I wish more people were asking. Believe it or not, you're the first person who's mentioned this to me about DM2 as a whole even though we've been planning it for a while now. People have mentioned it about one piece I've been working on called Veritas, but I'll get to that a bit later.

Many of the libraries in the Ruby community are based around the idea that an object handles validation, persistence, business logic, and other responsibilities at the same time. Most ORM/ODMs in Ruby follow that pattern (including DataMapper 1), and the libraries make similar assumptions. In a proper Data Mapper the pieces should be decoupled and usable by themselves. You should be able to test your domain objects separate from the mapper and persistence layers for example.

It's actually kind of funny that you mention other libraries like ActiveModel and validation gems. DM1 provided separate gems for those things several years before most of the overlapping gems and gems extractions were released, as far back as 2007/2008. If you go through and look at their introduction blog posts, you'll usually see one or two comments asking "Why didn't you use DataMapper for this?" or "There's a DataMapper gem that does this".

We've experimented with many different approaches for quite a while, and we know the strengths and weaknesses. What we're planning is basically just the next step of our evolution.

Another part that deserves attention is the part I've been working on called Veritas. It's a relational algebra library which allows you to describe queries for the datastore. Some people have asked me why I didn't just use ARel. I think it's is a powerful library, and it inspired much of my work, but for pragmatic reasons it's evolved into primarily an SQL generator rather than a relational algebra library. Internally it uses an AST that directly models an SQL SELECT statement. There's nothing wrong with that, and it had some nice advantages especially when it comes to generating SQL. It works great with ActiveRecord because it's an abstraction layer tightly coupled (by design) to relational databases.

With Veritas I wanted something that would model each relational algebra (RA) operation in an AST, and then allow me to translate those to SQL or other query languages. I think RA is absolutely beautiful, and I wanted to use that as a foundation for the queries rather than something less consistent. I did not want something tightly coupled to one datastore, but something that can be used to describe complex queries in a more abstract way.

Veritas has an interesting design, which I don't think has been executed in quite the same way before. In Veritas each node in the AST may be wrapped in a datastore specific adapter object. The adapter can use the RA operation to generate an SQL query (for example) and execute it. Each node knows to process results in-memory (so for example a Join knows how to join the left and right operands in memory). The beautiful thing is that we can ask the tree to evaluate itself, the native queries are executed, and as the data propagates to the "root", we can process anything remaining in-memory. Essentially we can do things like cross-datastore joins with ease.

This might sound really complex, but the beauty of RA is that each operation is small, simple and only has one function. Here's an example of the Join operation, probably one of the more complex operations: https://github.com/dkubb/ve... and for contrast here are the Intersection https://github.com/dkubb/ve... and Union https://github.com/dkubb/ve... operations. As you can see these are extremely simple, yet so powerful.

I haven't even mentioned the coolest part yet, the veritas-optimizer gem. It can "walk" the tree of operations and rebalance it into something equivalent but more efficient. I could say more about this, but it's worth checking out more.

TLDR; DM1 already has all the pieces that implement the Active Record pattern in place; everything and more than what can be found in ActiveModel and other validations gems. What we're working on now is the next step in the evolution of the library.

Re: DataMapper, an alternative to ActiveRecord - Codegram

Dan Kubb — Fri, 04 Nov 2011 12:32:59 -0000

David, which features were those?

Re: GitHub - Server Error

Dan Kubb — Wed, 19 Oct 2011 16:48:12 -0000

Keep in mind that in ruby "$" anchors up to the first newline only. So for example, the following will match:

/^#{URI::regexp(%w(http https))}$/ =~ "http://example.com\nsome random extra junk"

Which is most likely not what you want. What you probably want to use is "\z", which anchors to the end of the string. I usually pair this with "\A" because it's easier to remember, eg:

/\A#{URI::regexp(%w(http https))}\z/ =~ "http://example.com\nsome random extra junk" # no match

Re: Haruki Zaemon | How To Write eql?() in Ruby

Dan Kubb — Mon, 26 Sep 2011 14:54:11 -0000

BTW a little bit nicer way to write self.class.equal?(object.class) is as: instance_of?(other.class)

Re: Command-Query Separation in Ruby

Dan Kubb — Fri, 05 Aug 2011 19:14:42 -0000

In ruby the convention I use is that a command returns self, and a query returns some state of the object without modifying anything, or in other words it is idempotent.

A nice advantage of this convention is that I can now chain commands together in series to perform a specific state change

Re: Demeter: It’s not just a good idea. It’s the law.

Dan Kubb — Thu, 07 Jul 2011 14:19:03 -0000

This is a great post Avdi, but I have a question about the following point you made:

"There’s nothing wrong with having a large API, so long as individual collaborators only talk to well-defined subsets of it."

I'm not sure if you mean API, as in the interface for all the classes and methods in a system, or for just one specific class. I think when you have a class with a large API, it's a sign it's doing too much and possibly an SRP violation. I would consider breaking up such a class into smaller classes that handle one responsibility each.

Re: RSpec Tip: let and nested describe/context blocks

Dan Kubb — Wed, 22 Jun 2011 13:02:17 -0000

I really like subject blocks for making explicit the code I'm testing and it also simplifies the "it" blocks and allows me to use "its" too.

Shared specs are also awesome to reduce duplication and centralize common concepts. I use them extensively in controller specs to check for things like authentication/authorization, HTTP status tests, and proper error handling.

Re: Virtus – Attributes For Your Plain Ruby Objects

Dan Kubb — Sun, 12 Jun 2011 11:30:09 -0000

@solnic I wonder if there's way we can conditionally add #attributes in only if it doesn't already exist in the target class? That would allow ActiveRecord users to declare their attributes using the Virtus API (maybe with an additional thin shim) for the type coercion and other benefits.

Re: Virtus – Attributes For Your Plain Ruby Objects

Dan Kubb — Sun, 12 Jun 2011 11:27:27 -0000

I second @solnic's suggestion of joining #datamapper. I've often wished I could converse with the Og developers given how many things we cribbed from it and included in DM. It would be awesome to get your perspective on things and learn a bit more about hidden gems like this.