Disqus - Latest Comments for nstults

Re: AmberBit :: Introduction to Rack middleware :: unique web & mobile applications

nstults — Sun, 08 Nov 2009 01:45:22 -0000

Beautiful shrimp! I miss ASCII art. Reminds me of my BBS days. Anyone remember THEDRAW? Thanks for the article, I enjoyed working through it.

Re: So you want to learn IronRuby? – Chapter 1 – “The Back Story”

nstults — Thu, 29 Oct 2009 13:21:10 -0000

Good point. That is a big benefit of Ruby in almost any usage scenario, but particularly one where you are doing what we were doing and adding scripting to your application. I don't know what metaprogramming mojo Python has, but Ruby makes it absolutely trivial to throw together a relatively elegant, expressive DSL.

Re: SimpleServiceBus on CodePlex (a fork of nServiceBus)

nstults — Tue, 27 Oct 2009 14:17:31 -0000

Dan, I'm glad you like it. However, I would be careful about skipping over a careful review of NServiceBus because of my descriptions here - this post is quite old, and NServiceBus is now maintained by a team, evolves rapidly, and has a very active community. Many of the shortcomings in this post have been overcome in recent versions of NSB. I'm not steering you away from SSB, I'm just cautioning that NSB also deserves your time in a thorough evaluation, because the very active development team and thriving community are huge assets that SSB simply does not possess.

Re: Simple ASP.NET MVC Ajax Proxy

nstults — Thu, 10 Sep 2009 18:04:08 -0000

My understanding of JSONP is that the script that wants to access remote data (which is expected to be javascript, I presume, whereas in this example the payload is a binary (png) stream) needs to be aware of the JSONP arrangement, whereas in this case the goal is allow a third party component (OpenLayers) interact with a map server on a different domain without having to write and specific client side or server side glue code to make it happen, we can just give the OpenLayers control a url to a WMS server and everything works as expected. Also with JSONP (as I understand it) the cross-domain resource needs to be aware of the protocol, whereas with a proxy, the cross-domain resource does not need any modification whatsoever. But I only briefly looked at JSONP at your mention, so I have a very light understanding of its capabilities.

Re: Just add "Crazy" to your adjectives, and be done with it.

nstults — Mon, 04 May 2009 12:46:39 -0000

That's good news, I look forward to reading your posts. Congratulations on the kid cranking. People say things like "I cranked out a few kids" as if it was just another thing, when really we should be using language like "I plunged into a terrifying and beautiful portal of insanity in which human life emerged from nothing whatsoever and my perception of reality and depth of feeling were permanently and dramatically expanded beyond anything words can describe" Of course, that only works for the first kid, the cranking metaphor works well enough for subsequent children.

Re: SimpleServiceBus on CodePlex (a fork of nServiceBus)

nstults — Mon, 27 Apr 2009 12:11:25 -0000

I keep a loose eye on NSB to see if parts of what I've done can be reused as NSB components, but in reality while this project started out life as a fork, it really ended up being a nearly total rewrite. I'm not sure there is any nServiceBus code left, although the overall architecture remains vaguely the same, so a "merge" is certainly no longer possible. Even if it were it is extraordinarily unlikely Udi would accept my changes, our styles are just too different.

Re: About The Freak Parade

nstults — Wed, 25 Feb 2009 02:00:13 -0000

I'm flattered, but I'm having the time of my life where I'm at :) I've heard great things about Neuron though, I hope to take it for a spin someday.

Re: Content Management Systems (CMS) for the .NET Platform

nstults — Tue, 04 Nov 2008 19:54:23 -0000

ASP.NET MVC :)

Re: I don’t know but I’ve been told, ETL is gettin’ mighty old. BAM! BAM! EDA! I want my data right away!

nstults — Mon, 27 Oct 2008 15:01:02 -0000

I'll definitely check that out, thank you for the pointer

Re: Flowing Identity from a Client to a Service when using RESTful WCF Part 2 - A Solution

nstults — Thu, 23 Oct 2008 17:19:21 -0000

I think you may be reading into the Identity Metasystem too specifically - in my understanding, client or server is not the question, simply the relative, identity related roles of whoever is participating in an identity transaction. I see no reason a smart client (such as a Win Forms app) couldn't play the role of a Relying Party. You can't really compare a web browser front end to a smart client front end as if they were counterparts - a smart client may, for instance, require the users claims to appropriately render its UI (i.e. hide or show certain features based on access rules), whereas a web app will rely on the "server" to fill this role as the server generates the user interface. I can't imagine client side code in a browser being able to examine claims, or wanting to, but it is not at all unreasonable for a smart client to do so. In other scenarios a web app may actually be acting as a "client", delegating to a distributed service layer for its business logic and concerning itself only with rendering a UI, and in that scenario the web app may also want access to a users claims. If the front and and back end are just tiers of a single application, I don't think this is a problem. I could be misunderstanding some very important point here, though, that has been known to happen.

Re: Flowing Identity from a Client to a Service when using RESTful WCF Part 2 - A Solution

JoeG — Thu, 23 Oct 2008 15:23:44 -0000

Thanks for the clarification of the "Subject" concept; a lot of this stuff is still gelling in my brain. I guess where I'm still a little fuzzy on what you're trying to achieve comes from the phrase, "On the client side...a representation of the user along with her claims can be found at Thread.CurrentPrincipal." I'm not so sure this is the case with the Identity Metasystem model I have been reading about as of late. As I understand Zermatt, IClaimsPrincipal and IClaimsIdentity are concepts that don't apply to the client-side of things (thinking of the client as a web browser in the ASP.NET world, and a Windows Form in the rich client world).

Re: Flowing Identity from a Client to a Service when using RESTful WCF Part 2 - A Solution

nstults — Wed, 22 Oct 2008 20:12:15 -0000

In my example there isn't actually an Identity Provider involved - the service consumer (the Windows Forms client) is acting as the IP, which is where your confusion comes from. In a real scenario the service consumer would likely facilitate the retrieval of an encrypted token for the logged in user from a real IP and then use the technique I described to flow that token to the service. In my simplified example, however, the service consumer is constructing a dummy token because this sample isn't concerned with that part of the Identity relationship. And I don't think you would call any piece of software the "Subject" - the Subject, in my limited understanding, is the conceptual entity being authenticated, i.e. a user. Usually the RP and the application the user is logging into are the same, so the application itself is the Relying Party (RP). In my sample, logically, the windows forms application is just the user interface to a distributed application, and the whole thing could be considered the Relying Party. The role of the Identity Provider is somewhat obscured by the fact that the UI (service consumer) is pretending to be the IP.

Re: What Lao Tse thinks of TDD

nstults — Tue, 30 Sep 2008 01:13:05 -0000

I appreciate the compliment. I agree, my analogy was just one aspect of TDD, whereas it is a much larger practice than that. It's a strange practice - it is has immense value, and I agree that part of its difficulty is the lack of any counterpart in usual experience. It goes against the natural grain of logic - how can you test something you have only vaguely conceived? But you should. One of the things I love about software development, though, is its uniqueness - software as a medium is so pliable, so flexible, that it defies the usual approaches to engineering, which is why I think people have started calling it a "craft" - but it's also engineering - hard to pin down :) Thanks for the comment, and I'm glad you appreciated the post.

Re: CrapOverflow? Really? Oooooooook then… (Or, the fallacy of elitism)

nstults — Sun, 14 Sep 2008 12:03:47 -0000

Heh - yes that's exactly what I'm say, we all have Asperger Syndrome.
http://www.udel.edu/bkirby/asperger/aswhatisit....

Re: Deciding Between ASP.NET MVC and WebForms

nstults — Fri, 12 Sep 2008 16:35:57 -0000

I agree that a flow-chart may not be the best decision making tool in this case. I do like the idea of weighting the pros and cons, but a flowchart strongly suggests a single path, in which decisions at one node will determine your next steps, and this implies a sequential relationship among the decision points. In a situation such as this, that just isn't the case, and so a flowchart has the potentially to be extremely misleading. A weighted set of priorities that products a score for each choice would be somewhat better. Personally, I think the decision comes down to the skill level and experience of the dev team, and how critical use of third party UI libraries is. If you *need* a third party UI suite like Telerik's, Infragistics or DevExpress, you can't choose MVC. If you have very junior developers that will rely heavily on copious documentation, books, training from MS, you probably can't choose MVC. Otherwise, MVC is a very good choice and will pull your team into a new (very health) paradigm of software development because most of the community activity around MVC is practicing TDD, DDD, using ORM's, etc.

Re: Flowing Identity from a Client to a Service when using RESTful WCF Part 2 - A Solution

nstults — Mon, 08 Sep 2008 13:49:15 -0000

That looks to be a much better approach, thank you for posting the suggestion and link. How is your prototype going? Does it work?

Re: Simple Expression Evaluator project now on CodePlex

Ayende Rahien — Thu, 04 Sep 2008 09:54:46 -0000

Great reason to write it, mind you.
I wanted to know that you are aware of the other options.

Re: Simple Expression Evaluator project now on CodePlex

nstults — Fri, 29 Aug 2008 11:16:15 -0000

Ahh Mr. Rahien, I do love how you sugarcoat everything you say. One day you'll walk into a blog and say just what you mean and shock everyone out of their boots.

I wasn't actually aware of BooParser.ParseString until just this moment. It looks to me, though, like the method gives you an AST tree, which you could then optionally compile and run. This is fine, but I'd still either need to compile the AST tree to my own object model or do a good bit of mucking around with the Boo AST to make sure custom variables were expanded properly, custom functions, etc. I am not sure it would have been any less work at the end of the day, and probably a bit more opaque.

That being said, I'm *not* sure Simple Expression Evaluator has a strong value proposition when compared to the two already existing Expression Evaluators on CodePlex, FLEE (uses dynamic code generation) and LazyParser (uses reflection). Both probably would work as well as mine, and existed before I wrote this. But I wanted a good excuse to try out Irony.net, and I selfishly wanted full control of the API. And, of course, I like this crap, and enjoy the tinkering (something I'm sure you could never understand :) ) Whether or not it provides anybody with a new and better expression eval library (probably not) it can serve as a pretty textbook example of one common approach to turning an AST into an object model and evaluating it.