Los Techies - Latest Comments

Re: ripple: Fubu-inspired dependency management

Friv 4 — Wed, 29 May 2013 04:35:52 -0000

So I will write about it soon

Re: ripple: Fubu-inspired dependency management

ebog — Tue, 28 May 2013 05:50:38 -0000

Thanks for this great post that you share to us

Re: ripple: Fubu-inspired dependency management

ashic — Fri, 24 May 2013 05:15:37 -0000

The documentation on the site has one glaring problem - it's doesn't say what ripple does. It says that's it's something new, and how to use it, but I clicked around trying to get a gist of what it does. Perhaps a bit more about that on the overview page would be helpful (maybe include the features you've outlined in this post and expand on them)? Just my 2c...

Re: ripple: Fubu-inspired dependency management

Matt S. — Mon, 20 May 2013 16:00:19 -0000

I just want to say, the official 1.0 release of a bunch of the fubu projects was extremely exciting. However, seeing the first docs and such starting to appear for those projects is truly awesome. Congrats on this launch, guys!

Re: ripple: Fubu-inspired dependency management

jeremydmiller — Mon, 20 May 2013 11:49:59 -0000

I'll write a post soon about FubuDocs;)

Re: Introducing FubuMVC.AutoComplete

jmarnold — Sat, 02 Feb 2013 15:13:44 -0000

No dependency at all. The OverridesFor class is in FubuMVC.Core. Is that what you were referring to?

Re: Introducing FubuMVC.AutoComplete

Gleb Chermennov — Sat, 02 Feb 2013 08:44:54 -0000

Looks awesome. But I don't quite get it - does AutoComplete depend on Validation or its just an html convention?

Re: Introducing FubuMVC.AutoComplete

jmarnold — Sat, 02 Feb 2013 00:32:53 -0000

@Travis Higley

This is pretty tied to JQueryUI at the moment. The code is so simple that I don't even know if it's worth abstracting to share much between a Bootstrap version. That said, if there's a lot of interest in a bootstrap (or other) version, I'd happily help out.

Re: Introducing FubuMVC.AutoComplete

Alex Henning Johannessen — Fri, 01 Feb 2013 18:14:58 -0000

Very nice one Josh :)

Re: Introducing FubuMVC.AutoComplete

Travis Higley — Fri, 01 Feb 2013 16:28:12 -0000

Thinking out loud here, but I noticed it depends on JQueryUI, what if there was a way to have this use a different UI Framework, for example Twitter.Bootstrap (FubuMVC.TwitterBootstrap?).

Re: Introducing FubuMVC.Validation. For real.

Matt Frear — Wed, 30 Jan 2013 15:38:40 -0000

Nice work Josh.

Re: Introducing FubuMVC.Validation. For real.

jmarnold — Wed, 30 Jan 2013 09:31:07 -0000

I'm going to be do more very soon. Would you mind posting your requests in our mailing list? That'll get more people reminding me to actually do them ;)

Re: Introducing FubuMVC.Validation. For real.

bit bonk — Wed, 30 Jan 2013 02:12:35 -0000

It'd be interesting to see in a video how localization of the validation messages (or just anything in fubuMVC) works.

Re: Introducing FubuMVC.Validation. For real.

jmarnold — Tue, 29 Jan 2013 09:17:17 -0000

That's just good ol' R# ;)

Re: Introducing FubuMVC.Validation. For real.

David Driscoll — Tue, 29 Jan 2013 02:16:08 -0000

Looks pretty cool.

One off topic question, is that an extension you're using for intellisense? It looks pretty helpful

Re: Investing in your tests–A lesson in object composition

Jef Claes — Wed, 02 Jan 2013 08:32:50 -0000

Just a quick comment to let you know the gists are also not showing up in Google Reader.

Re: Guidelines for Automated Testing: Defining Test Inputs

Artëm Smirnov — Thu, 27 Dec 2012 13:43:12 -0000

I'll be happy to read your blog post(s) about those!

Re: Guidelines for Automated Testing: Defining Test Inputs

jmarnold — Thu, 27 Dec 2012 11:08:38 -0000

Artëm Smirnov I think this applicable the *most* in acceptance test scenarios -- where you would want to use something like FitNesse or StoryTeller. That being said, I think that the underlying the goal here is simply this: "When I see a failing test, I want to read the test and understand the state of the system, the inputs, and the expected outputs as they relate to the state of the system".

The "state of the system" isn't always applicable. In most cases, unit tests are simple state-based assertions on inputs/outputs so it doesn't make sense there. Data-dependent tests are what typically get you the most. Declarative data for those tests are invaluable for maintenance.

RE: using string conversion techniques
We leverage FubuCore's model binding pretty hard. We'll often create a shorthand syntax to make the data more readable/easier to maintain.

I'm happy to blog more about those if you find them helpful ;)

Re: Guidelines for Automated Testing: Defining Test Inputs

Artëm Smirnov — Sun, 23 Dec 2012 10:44:10 -0000

"Data setup should be declarative" -- how exactly do you accomplish it in your tests -- is it ST-only, or applicable to all tests, unit and integration? Using test attributes maybe? How do you build object graphs declaratively? I'm intrigued by the idea of "using string conversion techniques" -- do you fill up the values from a JSON string? Would make the code simpler, but what about refactoring?

I'm totally into the idea that the inputs belong with your test, but I discovered that often they are worth extracting into their own context class. The name of this class should be clear enough so that we don't have to look at its code.

The bottom line is, I do put my inputs in the test class, until it's so much code that you have to scroll through it in order to get to the point.

Re: Investing in your tests–A lesson in object composition

jmarnold — Sat, 22 Dec 2012 20:31:45 -0000

Oh, absolutely. However (and I rarely take this stance), there are times when you have to weigh goals and their values of the overall design. For this particular case, I've seen what happens when the source memoization is removed and optimization gets poor. On top of that, diagnostics is a big piece of our vision and caching the mechanics makes that possible. Unfortunately, those two decisions make some of the setup a little clumsy.

It's not 50 lines of setup clumsy. It's about 5-6 repetitive lines that I wouldn't want forced on me -- especially when they require intimate knowledge of the composition. The scenario "pattern" is the best compromise I've seen so far.

Re: Investing in your tests–A lesson in object composition

David DeWinter — Sat, 22 Dec 2012 20:08:57 -0000

I think the message should be stronger; invest in your tests, yes, but use them as a sense to tell you that your design needs improving, too. When you feel your tests becoming too cumbersome to write or maintain, take a step back and re-evaluate your approach.

As an aside I can't see your code examples on my phone. :(

Re: Modularity via Bottles

Neil Sorensen — Thu, 20 Dec 2012 17:26:36 -0000

This is an old post, so I'm not expecting an update, but the FubuMVC.Diagnostics package has moved: https://github.com/DarthFubuMV...

Re: Lessons from refactoring two year old code

Jason Meridth — Tue, 18 Dec 2012 12:56:17 -0000

Excellent post Josh. Thank you for sharing this.

Re: Automated testing with FubuMVC, StoryTeller, and Serenity

Nick — Tue, 20 Nov 2012 06:15:51 -0000

Delighted that you found time to blog about this. Thanks a lot.

Re: Some foundational ideas for automated testing

jmarnold — Sun, 11 Nov 2012 15:40:13 -0000

I'll be giving a nice introduction to it in the next post, promise.