Disqus - Latest Comments for troygoode

Re: Roll20 Resolutions: Time to Get a New Look!

TroyGoode — Tue, 29 Jan 2019 20:31:49 -0000

"LAYER"... "MORE". More layers - YES, PLEASE!

Re: A gentle Introduction to Higher Order Components

TroyGoode — Wed, 05 Apr 2017 19:43:59 -0000

If you're using recompose anyway, why not use their "branch" HoC?

Re: The Fringe of .NET - You've Been Haacked

TroyGoode — Tue, 10 Mar 2015 22:44:17 -0000

Hey Phil - I've been out of the .NET world for a few years now, but this sounds an awful lot like what was going on several years ago with "AltDotNet" (which I loved, and eventually helped lead me away from .NET). Is that "movement" (not sure what else to call it) dead? Is this kind of a recreation of that original premise under a new context given Microsoft's new status quo?

Re: Minty: Razing the Pyramid of Pain

TroyGoode — Mon, 09 Dec 2013 14:21:42 -0000

This is the part I take exception to:

"The same thing is happening with my continueWith - in the zipper analogy I threw down, article2 is incapable of "jumping the queue" past article1 - because it's a queue and it's synchronous.

It can't get popped onto the queue any earlier either since Node is single threaded and will handle synchronous code inline."

The assignAuthor handler pushes the "author-assigned" event onto the queue, but only after the assignAuthor handler has finished received a response from the database. This is an asynchronous out-of-process action and you now have no guarantee of which article (article1 or article2) will have its callback fired first. In theory you'd expect the database to respond to the node.js process (and thus fire the callbacks) in the order that node.js originally made the requests, but as we all know this isn't always the case (though it probably is in your case given that you're using NeDB). If these requests were going out to a sharded database environment query2 could quite easily respond before query1.

Re: Minty: Razing the Pyramid of Pain

TroyGoode — Sun, 08 Dec 2013 19:09:10 -0000

Consensus at last! :-)

Re: Minty: Razing the Pyramid of Pain

TroyGoode — Sun, 08 Dec 2013 19:00:48 -0000

While you may not intend for multiple calls to #saveDraft to be made from the same Writer, the module as you've currently written it does not prevent this.

The race condition is that consecutive calls to #saveDraft on the same instance of Writer can contend over access to continueWith variable. If #saveDraft{X++} is popped off the even loop queue and processed while #safeDraft{X} is waiting for a call to the database to return, continueWith will be overwritten and #saveDraft{X} will not complete the way you intend it to. If you don't consider that a race condition, we'll have to agree to disagree. :-)

Re: Minty: Razing the Pyramid of Pain

TroyGoode — Sun, 08 Dec 2013 18:42:57 -0000

Yes, we're on the same page. That "zipper" effect creates a race condition if you're accessing state shared between multiple runs of the event loop, such as with the continueWith variable.

I think your best option, if you want to continue down this path, is to encapsulate the entire Writer object in another object with its own #saveDraft method. This wrapper object would be stateless and would ensure that each your actual Writer objects (which could contain state, such as continueWith) are not reused. You would dispatch WriterWrapper#saveDraft->WriterInstance#saveDraft and also listen to & re-emit each WriterInstance's events from WriterWrapper (so that you still can have your extensibility points).

I'm interested to see how you ultimately choose to handle this.

Re: Minty: Razing the Pyramid of Pain

TroyGoode — Sun, 08 Dec 2013 18:04:12 -0000

The event loop is absolutely a queue, yes. Sorry, I think I'm not doing a good job explaining myself here. :-)

Take a look at this gist:

https://gist.github.com/tro...

* run that in one tab of your terminal

* then, in another tab, run "curl http://localhost:3000" twice in a row

* switch back to the original tab and wait a few seconds to see that the console.logs are now intermingled

What I'm trying to show is that whenever node.js is waiting on an asynchronous external process (file system, database, in this case a #setTimout) it is free to process additional events from the event loop so you cannot be guaranteed that your code will execute in order.

When #assignAuthor is waiting on the response from the database, node.js *will* start processing the next event in the event loop (which may be another HTTP request).

Re: Minty: Razing the Pyramid of Pain

TroyGoode — Sun, 08 Dec 2013 17:17:07 -0000

You're correct that there is only one loop per process - but remember that there can be entry points in that process that are adding things onto the event loop. The main thing to consider here is that node.js' HTTP server adds each request onto the event loop queue as it comes in. This means what while your code path that calls #saveDraft is executing (but *before* it has called #emit) a new request could come in queue'ing up the same codepath which would then execute before your #assignAuthor function runs (because #sendDraftToDB gives up control).

Obviously if you're the only user this might not be a big deal (though keep the "accidentally double-clicked the submit button" scenario in mind), but if anyone else tries to adopt your approach they might end up getting themselves into trouble...

Re: Minty: Razing the Pyramid of Pain

TroyGoode — Sun, 08 Dec 2013 16:12:50 -0000

You’re right that node.js is single-threaded, but unfortunately that doesn’t free you up from the possibility of race conditions as node.js implements cooperative multitasking to take advantage of its asynchronous usage. Node.js operates using something called an Event Loop. What this means is that node.js queues up code that it should run, runs a segment of code from the queue sequentially, and then moves on to the next section of code once the first section has given up control, ad infinitum. This is part of what makes node.js so fast - other work can be done while waiting for the return of an asychronous call.

Note that I mentioned your code has to “give up control.” The most frequent way this occurs is by calling a asynchronous IO function (file system, network, database, etc), but this also occurs when you manually give up control and wait for the next available run of the event loop via process.nextTick: http://howtonode.org/unders....

EventEmitter’s implementation does happen to be synchronous so your #emit’s and #on’s would be executing within the same event loop IF all of your event handlers were also synchronous, but they aren’t - your handler for “slug-checked,” “article-saved,” and “article-tagged" are asynchronous. Your “chain” will be broken up into several runs of the event loop which may be interspersed with code from elsewhere in the program. This means calling Writer#saveDraft a second time on the same instance of Writer is NOT safe unless you’ve waited for previous run of #saveDraft’s chain to end.

Re: Storing LINQ Objects in SQL-Based Session State

TroyGoode — Sun, 25 Aug 2013 22:14:50 -0000

Sorry Arun - I'm not spending much of my time programming in .NET these days, and haven't thought about this particular problem in five years. Best of luck finding a solution!

Re: Rob Conery’s PagedList Class (Updated)

TroyGoode — Mon, 26 Nov 2012 09:30:55 -0000

Hi Moh,

In that case you'll want to call OrderBy before calling ToList:

var productsPaged = _products.All().OrderBy(p=> p.Price).ToPagedList(0, 10);

Re: http://4sffl.com/post/30937296510

TroyGoode — Wed, 05 Sep 2012 16:21:09 -0000

Also, Nick says he would put his faith in Mike Wallace and then proceeds to tell me to start Brandon LaFell.

Re: http://4sffl.com/post/30368039354

TroyGoode — Tue, 28 Aug 2012 19:48:55 -0000

How was Chris Johnson not on last year's LVP list?

Re: CoffeeScript or Straight Up Javascript? It’s Decision Time

TroyGoode — Thu, 22 Mar 2012 23:07:10 -0000

Fair enough, different strokes for different folks. :-)

Re: CoffeeScript or Straight Up Javascript? It’s Decision Time

TroyGoode — Thu, 22 Mar 2012 12:49:55 -0000

Computers prefer 1s and 0s - if we want to speak their language we should stay as close to that as possible (Assembly for most mortals). Higher level languages are all about giving *humans*, not computers, a language that is easier for *us*.

Re: CoffeeScript or Straight Up Javascript? It’s Decision Time

TroyGoode — Wed, 21 Mar 2012 15:59:05 -0000

Presumably you wouldn't have to port your code to Harmony, but CoffeeScript's compiler could be ported to it so your code takes advantage of it without direct changes to your source.

Re: CoffeeScript or Straight Up Javascript? It’s Decision Time

TroyGoode — Wed, 21 Mar 2012 15:54:15 -0000

Comprehensions are my "dagger" for CoffeeScript:

console.log color for color in ['red', 'green', 'blue']

The above is the equivalent of:

['red', 'green', 'blue'].forEach(function(color){
console.log(color);
}); //note that I originally forgot the closing paren here

Here is another comprehension:

colors =
red: '#ff0000'
green: '#00ff00'
blue: '#0000ff'
console.log "#{color} is #{hex} in hex" for color, hex of colors

The above is the equivalent of:

var colors = {
red: '#ff0000',
green: '#00ff00',
blue: '#0000ff'
};
for(var color in colors){
var hex = colors[color];
console.log(color + " is " + hex + " in hex.");
}

Re: CoffeeScript or Straight Up Javascript? It’s Decision Time

TroyGoode — Wed, 21 Mar 2012 15:19:00 -0000

+1 for "CS", but wanted to note that you can reduce your example further (the {} are optional):

find name: 'leto', (doc)->

Re: PagedList can haz HtmlHelperz? | troy goode | squaredroot.com

TroyGoode — Mon, 20 Feb 2012 19:39:42 -0000

Thanks, glad you liked it!

Re: NHibernate Built-in Code Based Mapping instead of using Fluent NHibernate - Kazi Manzur Rashid

TroyGoode — Tue, 04 Oct 2011 14:51:15 -0000

Interesting. Do you know if it does FluentNhibernate-style automapping?

Re: PagedList can haz HtmlHelperz? | troy goode | squaredroot.com

TroyGoode — Fri, 16 Sep 2011 15:45:46 -0000

Hey Dan,

So you're actually putting Model.HouseFeatures into an anonymous type which is being passed into Url.Action(...), and that is an object+method built into Asp.Net MVC by Microsoft - so no, I can't change how it works. ;-)

That said, what you want to do isn't too hard. Ultimately we want {"HouseFeatures", Model.HouseFeatures} to become {"HouseFeatures", "1,2,3"} (where 1, 2, and 3 are the integers stored in the Model.HouseFeatures array. The String object provides the handy Join method that will do some of this work for us:

String.Join(",", Model.HouseFeatures)

The above won't *quite* work though, because Model.HouseFeatures is an array of ints and String.Join expects an array of strings, so modify it to:

String.Join(",", Model.HouseFeatures.Select(hf=> hf.ToString()).ToArray())

And now you're rocking. The full call should look something like:

@Html.PagedListPager(Model.SearchResults,
page => Url.Action(
"Index",
new RouteValueDictionary{
{ "Page", page },
{ "HouseFeatures", String.Join(",", Model.HouseFeatures.Select(hf=> hf.ToString()).ToArray()) }
}
)
)

Re: MVC Membership Starter Kit Released

TroyGoode — Wed, 14 Sep 2011 12:45:10 -0000

@flascuba, the project just uses Microsoft's Membership Provider abstraction, which has a Windows Auth provider:
http://forums.asp.net/t/958...

Re: MVC Membership Starter Kit Released

TroyGoode — Sun, 21 Aug 2011 15:24:56 -0000

Yup, the latest release is based on MVC3 and Razor (CSHTML).

Re: PagedList can haz HtmlHelperz? | troy goode | squaredroot.com

TroyGoode — Fri, 19 Aug 2011 23:32:50 -0000

hey Foton - there have been a few fixes to PagedList & PagedList.Mvc and one of them handles certain IQueryable situations better. you may want to try it out again; the fixes may have solved your scenario