Joshua Flanagan (Los Techies) - Latest Comments

Re: Use gitk to understand git – merge and rebase

Mga555 — Fri, 20 Apr 2012 15:58:09 -0000

GREAT JOB! I've been struggling trying to learn Git as I go. I've accumulated a ton of bookmarked information, but I think I can throw most of it away now. Not only did you do a great job explaining Gitk, but provided a tremendous boost to my understanding of Git; just what you said you'd do!

One minor thing I did not understand. When you did the "git merge issue123", the commits shown in the "top pane" (does that pane have a name?) moved from being in line under master to being in line under issue123.

What is the significance of that shift ?

Are you thinking about a series on Git Gui?

thanks so much!

Re: Coordinating multiple ajax requests with jquery.when

HB — Wed, 18 Apr 2012 18:27:13 -0000

Excellent writeup. Thanks a lot. Your explanation clarified this in a way that the docs couldn't. Thanks again!

Re: A smarter Rails url_for helper

joshuaflanagan — Wed, 28 Mar 2012 08:27:20 -0000

First, its worth pointing out that I only need to register handlers for the "special case" models. Everything else just falls through to url_for.
The predicate approach gives me more flexibility, but it is possible I won't need its full power. The class checking will likely be the most common case. Another possibility would be a hybrid approach - first check a hash for the class of the model. If it not found there, check the model against the collection of predicates, and only after that fails, fall through to url_for.

Re: A smarter Rails url_for helper

Mark IJbema — Wed, 28 Mar 2012 05:08:59 -0000

If you have a lot of models this becomes quite expensive though. As far as I can see the lookup is O(n). If your primary usecase is checking the model class, wouldn't it be better to store the mappings in a hash, so that lookup is constant? (and then per class you could possibly still do another check, if you need to check other stuff than the model class)

Re: A smarter Rails url_for helper

Jak Charlton — Wed, 28 Mar 2012 00:51:10 -0000

If you can use a model of any kind, you can use Draper - it just decorates other models and you just replace their use with its decorator

If your models are just conforming to one generic model, then just create a view model for that use case, which has the generic properties to display, and the url to go to

Re: A smarter Rails url_for helper

joshuaflanagan — Wed, 28 Mar 2012 00:45:36 -0000

Thanks for your feedback, Jak. I didn't intend this as a patch submission to Rails, so I don't need everyone to like it. Personally, putting the url generation on the model (which is how we started) was hard for me to stomach. To each his own.
Wrapping each model in a decorator again presumes that you know the model type (I think) so that you know which decorator to wrap it with. I haven't used Draper yet, but I do agree with its intent. If it has a way to generically wrap a model with the correct decorator, without you explicitly telling it which decorator to use, it may be a possible solution.

Re: A smarter Rails url_for helper

Jak Charlton — Wed, 28 Mar 2012 00:30:11 -0000

And if you don't like the idea of using a view only property in your model, you should probably be using view models anyway, I suggest Draper, where you can then implement view only logic about models
https://github.com/jcasimir/dr...

Re: A smarter Rails url_for helper

Jak Charlton — Wed, 28 Mar 2012 00:28:31 -0000

Then ask the model

class Comment
def url
... whatever ...
end
end

Personal opinion, I really dislike your current solution - overly complicated for a really simple thing

Your assertion that "This is what url_for is supposed to do" is just wrong. There is a well founded presumption that the view knows the properties model structure it is displaying (as you would for knowing the fields for a form for example).

If your view is that generic that it is only asking about a few properties of a model via a protocol (say "title" and url link), then implement a method as in the class above - models that implement this protocol can be displayed

Re: A smarter Rails url_for helper

joshuaflanagan — Wed, 28 Mar 2012 00:19:01 -0000

The *call site* does not know the model. Yes, somewhere in my application, that knowledge exists (the config/initializer). But the point at which I need to generate a URL, I do not know the model.
I have a method that returns a collection of models. Models of different types. I want to display a list of links to those models. The code that iterates over the models doesn't know, and shouldn't have to care, what the models actually are. It just wants to ask Rails for their URL. That is what url_for is supposed to do. But it doesn't in some circumstances, like nested resources.

Re: A smarter Rails url_for helper

Jak Charlton — Wed, 28 Mar 2012 00:11:29 -0000

In what example wouldn't you know what the model was?

Your solution knows, you just moved it into a helper

If (and I have no idea why you would want to) you wanted to avoid knowing what the parent object was, you could just implement a method on comment and use that

class Comment
def parent
post
end
end

url_for [@comment.parent, @@comment ]

Re: A smarter Rails url_for helper

joshuaflanagan — Wed, 28 Mar 2012 00:07:24 -0000

I don't know, I'm asking you!
But the example you provided and linked to is NOT a solution to my problem. You know that you have a comment, so you know you have to also pass a post to get the url. I'm referring to a situation where you don't know what the model is. The problem I'm trying to solve is when you have generic code that needs to be able to handle any model, and generate a url.

Re: A smarter Rails url_for helper

Jak Charlton — Tue, 27 Mar 2012 23:56:11 -0000

Aren't you trying to recreate built in logic?

url_for [@project, @comment]

http://ryanbigg.com/2012/03/po...

Re: Use gitk to understand git – merge and rebase

Cristian Umaña Jiménez — Thu, 15 Mar 2012 11:52:53 -0000

I read a lot about rebase a don't understard a word :|

With this post I understood, cristal clear

Thanks a lot

Re: Use gitk to understand git

Cristian Umaña Jiménez — Thu, 15 Mar 2012 11:26:14 -0000

Great post it helps a lot

Re: Coordinating multiple ajax requests with jquery.when

newbreedofgeek — Thu, 01 Mar 2012 01:30:24 -0000

That's smart and it worked... thanks!

Re: Coordinating multiple ajax requests with jquery.when

joshuaflanagan — Thu, 01 Mar 2012 01:17:55 -0000

I think you would have to do something like:

$.when.apply(this, deferredCollection).done... (etc)

Re: Coordinating multiple ajax requests with jquery.when

newbreedofgeek — Thu, 01 Mar 2012 00:46:45 -0000

hi there,

Just a question on this:

I'm trying to send a collection (array) of deferred objects to .when like this:

var deferredCollection = [];
deferredCollection.push(getTweets('austintexasgov'));
deferredCollection.push(getTweets('greenling_com'));
deferredCollection.push(getTweets('themomandpops'));
deferredCollection.push(getTweets('anotherUserA'));
deferredCollection.push(getTweets('anotherUserB'));

$.when( deferredCollection).done(function(atxArgs, greenlingArgs, momandpopsArgs, anotherUserAArgs, anotherUserBArgs){
// there is an error here trying to access atxArgs etc
});

is it possible to do something like this??

Thanks in advance.

Re: Coordinating multiple ajax requests with jquery.when

newbreedofgeek — Wed, 29 Feb 2012 22:50:39 -0000

Thanks very much for this.. I have been looking for this for a long time. Your example makes it very easy to understand the complicated deferred object articles on the net. Good work.

Re: Great time to be a developer

Junkienatural — Tue, 07 Feb 2012 17:03:05 -0000

Even a monkey knows that its either 7.45AM or after 9AM on any office commute highway! :)

But awesome exercise though! Even I knew the results, I learnt few new tools!

Re: Powerfully simple persistence: MongoDB

Chad Myers — Mon, 06 Feb 2012 18:02:50 -0000

lol, I know. I'm just joshin' Josh :) He knows how strongly I hate stored procedures.

Re: Powerfully simple persistence: MongoDB

Tracker1 — Mon, 06 Feb 2012 12:50:22 -0000

Chad Myers He did say "simpler" ... Stored Procedures simply aren't.

Re: Powerfully simple persistence: MongoDB

Chad Myers — Mon, 06 Feb 2012 11:33:32 -0000

"it is hard to imaging a simpler, equally powerful, persistence strategy"
Pshaw, clearly you forget stored procedures!

Re: Great time to be a developer

joshuaflanagan — Sat, 04 Feb 2012 17:41:06 -0000

Very cool, thanks Jon!
Unfortunately, it doesn't look like they track traffic for 360 in Austin. Also, it doesn't seem very trustworthy (only *minor* slowdown on MoPac and I-35 during rush hour?)

Re: Great time to be a developer

Jon Peterson — Sat, 04 Feb 2012 15:37:15 -0000

Google's traffic overlay in Maps has historical data. Bring up the overlay, and in the bottom-left there's a new Legend that pops up. Next to where it says "Live traffic", click the "change" link, and voila.

Edit-to-add: I mean, don't get me wrong... following the theme of the title of your post, this is totally cool! But the functionality you need /is/ already available for free.

Re: Great time to be a developer

joshuaflanagan — Fri, 03 Feb 2012 08:21:05 -0000

No documented web service that I know of. That's the problem: the way I'm calling their URL is not correct, so I'm not getting correct traffic delay information.