gdp's Comments

Wizards of Smart : Help us choose a Fracture I/O logo!

Tue, 20 Sep 2011 19:08:12 +0000

Thanks for voting. Option #1 was our winner!

Wizards of Smart : Help us choose a Fracture I/O logo!

Thu, 8 Sep 2011 21:13:45 +0000

These results look like polls in American politics.

Wizards of Smart : The Frank application signature is curre...

Tue, 5 Jul 2011 16:33:37 +0000

Example using Iteratee via IterIO, which claims to be a simpler model, complete with HTTP support.

Looking at this and Snap Framework, I see that an Iteratee is essentially a ~~single-threaded event loop model for I/O~~ fold monad driven by an enumerator (value producer). Notes appear to indicate that truly lazy (async) models can leak resources as the resource isn't always appropriately closed, as Anton noted above.

Wizards of Smart : The Frank application signature is curre...

Thu, 30 Jun 2011 14:02:34 +0000

I thought Tomas\\\' AsyncSeq fit this description. I have yet to use Lazy types outside of MEF, but it appears to make sense. You appear to be lazily constructing the response, if I\\\'m reading that correctly. I had thought AsyncSeq would fulfill the desire to not block when sending data back across the socket, but I now see that such a view is reversed to reality.

Wizards of Smart : Here's another question related to Fran...

Thu, 30 Jun 2011 05:56:15 +0000

I like the points you make. I initially enjoyed the freedom monads provide of not having to pass along a common object, but I do it all the time in C# and don\\\'t think twice. You are correct that it provides a more approachable api for those unfamiliar with monads. It also resolves the cases where a MonadTransform would be required, which is not available in F#.

Fwiw, I\\\'ve updated the FSharp.Monad project to use the unwrapped versions so that the developer can choose his/her own approach.

Wizards of Smart : The Frank application signature is curre...

Thu, 30 Jun 2011 05:50:35 +0000

While on Stream, the reason we didn\\\'t go with that in OWIN was due to the bulkiness of the abstract class. I noticed in your gist that you used an ArraySegment<byte>. Was that intended to represent the entire stream or just an element?

Wizards of Smart : Here's another question related to Fran...

Thu, 30 Jun 2011 03:47:42 +0000

@mausch I\\\'m glad you have that perspective. I noticed that in your Reader use, noted by Anton. I added the wrapper types to FSharp.Monad based on Matt Podwysocki\\\'s blog series, among others. I am inspired to remove them (as I did originally).

Wizards of Smart : The Frank application signature is curre...

Thu, 30 Jun 2011 03:29:01 +0000

That\\\'s an excellent point. The current stuff comes from working with some of the OWIN guys previously, where I started getting caught up with byte[] and ArraySegment<byte>. I initially started with Stream and then TextReader and TextWriter. I hadn\\\'t made my way back to Stream, but it\\\'s probably time. Thanks for the nudge. :)

Wizards of Smart : The Frank application signature is curre...

Wed, 29 Jun 2011 03:45:40 +0000

Among other things. :) I need to probably add additional types, including `obj`, but I thought bytes were best to start. Xml and Json can be represented as strings, and with the desire for conneg, I don't really want to allow direct serialization into a specific format. I might bend on that. Given that all adapters will implement the extensions to modify what the app functions actually do, it should be easy to write a function that takes some input object and returns an output object, applying the extensions to mold and shape the inputs and outputs to the source system's requirements. In other frameworks, this is done "magically"; here, I want to explicitly apply the transformation functions.

Wizards of Smart : Here's another question related to Fran...

Tue, 28 Jun 2011 22:21:15 +0000

You are quite right. However, while I'm providing support for OWIN, I'd like to provide the familiarity of other enviroments. I quite like the HttpRequestMessage/HttpResponseMessage objects used by WCF. I thought about building something similar or even using those for my implementation, but others prefer the HttpContext(Base) approach or the OWIN abstractions. All are welcome... or so I hope to make happen. :)

Wizards of Smart : Which do you prefer for Frank routing gist...

Fri, 25 Feb 2011 03:19:08 +0000

Adam mentioned that the pattern matching enabled a lot of flexibility when I chatted with him earlier. Now looking again, the main reason for wanting to change appears lost with the pattern match approach. How do I correctly detect whether a given uri supports multiple methods so that I can return a 405 when appropriate?

Wizards of Smart : Which do you prefer for Frank routing gist...

Thu, 24 Feb 2011 23:58:29 +0000

~~@mythz voted for #3~~Nevermind; Demis voted below.

Wizards of Smart : Which do you prefer for Frank routing gist...

Thu, 24 Feb 2011 23:58:05 +0000

@granicz voted for #1

Wizards of Smart : A New Web for .NET

Tue, 25 Jan 2011 20:44:13 +0000

No idea. I haven't tested the throughput on it yet, and now that I'm switching to using the SocketAsyncEventArgs, it'll be awhile yet before I'll know. For those who haven't seen it, Dave's got a more complete implementation he's been sharing on his blog: http://moiraesoftware.com/

Hanselminutes : Hanselminutes

Mon, 20 Dec 2010 05:07:37 +0000

Scott, thanks for having Benjamin on and for giving Kayak and OWIN some great publicity. We'd love to have your input in the discussions. Kind regards and happy holidays, Ryan

Wizards of Smart : Wizards of Smart – Episode 7 Performance

Tue, 8 Jun 2010 17:42:10 +0000

I like the idea! I noticed you were inspired by underscore.js. What's yours add to the mix? (I haven't dug into underscore yet, just glanced the high level.)

Wizards of Smart : Refactoring with the Decorator Pattern

Wed, 26 May 2010 16:38:42 +0000

Yes, there were in fact several typos. I think I have now fixed them all, as well as finally written my follow-up post:http://wizardsofsmart.net/patterns/decorator-revi...

Wizards of Smart : ANN: Houston Dynamic Languages User Group

Thu, 3 Dec 2009 04:47:19 +0000

I'll be posting a follow-up announcement soon, but I'll state it here, too. Our first meeting is Tuesday, January 5th at the Microsoft office in Houston. Follow @hdlug on Twitter and join sign up for the mailing list at http://hdlug.groups.live.com.

Wizards of Smart : Model Validation

Fri, 18 Sep 2009 13:15:03 +0000

I think you are right for simpler scenarios. We started that way and eventually had 1000-2000 line classes, half of which were business rule methods for validation. I don't favor that approach, myself. Our business rules were always complex, but we tried that as an initial step. For the types of validation you mentioned, I would agree they are fine on the model, though I would still ask whether that is a SOLID design choice. As for AOP--absolutely! The problem is the additional dependencies required for AOP, so I like finding other, OO ways of getting around the problem if I can. Also, the rules aren't the same for everything, so while the validation process is AOP-able, the rules still have to be applied somehow. I've generally seen that happen with attributes or config files, both of which make sense. Have you seen other approaches?

Wizards of Smart : The Manifesto for Software Craftsmanship

Tue, 12 May 2009 17:30:54 +0000

But how do I know if I want a static method or a command pattern? Both are very simple, but which do I choose? If I start with a console app, do I start by writing code in the Main method, or do I start by creating methods in the Program class and call them in Main? Are they static? This is what I mean by "whose definition of simple."