gdp's Comments

Incremental Thought : When life gives you class vi rapids…

Sun, 3 Jul 2011 18:13:36 +0000

Steve - I'm trying to work in time for reflection on so many levels - even problem solving at work. I saw a great video recently (http://bit.ly/mOCZpW)" target="_blank"> (http://bit.ly/mOCZpW) by the creator of a recent language called Clojure - in which he challenges his audience (of guys like me) "When was the last time spent an hour thinking about a problem? Or a day? Or week?" I've been making the habit at work to step away from the desk, go to whiteboard and *think* through things. It's really paid off. Now I hope that I can translate that to other areas of life! You give me too much credit on WWF. Clearly my prowess is only noticeable because of all the training that your defeats foisted upon me. :-)

If & Else : Making Knockout.js Support External Templates

Sun, 26 Jun 2011 00:50:51 +0000

Toby - my apologies for taking so long to respond to your comment (things have been a bit hectic schedule wise for me). I checked out your git repo and have a couple of thoughts. Sure, it's certainly possible to do things the way you are, but I believe you're making some assumptions and trade-offs that aren't worth the risk. First, if you were to build a Knockoutjs app like this, you now effectively have two entry points for templates - the manual route you're taking, plus what KO provides. KO is by no means the perfect framework, but the point of a framework is to provide a consistent abstraction over the problems it's attempting to solve. By handling templating outside KO core, you are forced to apply bindings each time you load a template. You've also ruled out the option for nested templates - unless you manually recurse them, and apply the bindings on each one. Ultimately, by then time you write the code to handle all these issues, you will have solved the same issue Steve Sanderson has already solved in context of working with templates inside KO. While I'm not crazy about the sync call to get an external template, it's a one-time hit per template, and you have the option to time it out - I consider those far less of a disadvantage as having to solve the same problems in my own code that KO already solves for me, and still lose the advantages that templates have working through a template engine that has been implemented for KO specifically (like the stock one, or the one I created, or any of the others out there). It's also a reasonable course of action to fork KO and submit a pull request with changes that allow for a callback to be invoked prior to retrieving a template, that takes a 'continuation callback' as an argument. I've voiced this frustration before - if that were possible, then a sync call wouldn't be necessary. As it stands, though, KO was written with the assumption that template retrieval would be synchronous. Anyway - I think it's good that you're exploring this, but I don't think I would go the route you're recommending. If you're going to work with a framework like KO, I would either fork and modify to extend it to do what I want it to do, or abandon it and roll my own (or go with another) - rather than code a large of part of a separate framework and run it along side one that already has the facilities to do what I've coded as well. Hopefully that makes sense! Thanks a ton for giving me your feedback and for visiting the blog...

If & Else : Direction, Questions and Values

Wed, 4 May 2011 20:30:07 +0000

Great questions - thanks for the response! When I left the 'comfy job' in 2008, we knew it was going to be tight for a bit financially. It put things on hold that we hated to delay. But I'm blessed with an understanding spouse who saw me dying a bit each day inside, and was ready for me to get into something more fulfilling. Who knew the new company would collapse 2 years later? But learned valuable skills from that - learning to balance between commitment to a job, and commitment to my career. I know any company is going have it's bad days (if not seasons!), so I try to not to jump to conclusions, but I'm not a blind loyalist either. That doesn't rule out the very real chance of working for another idiot, but it might lessen the damage (and limit the length of exposure). This is also a driving reason behind why I'm trying to be more involved in OSS. I read a bit of your thoughts on OSS and certainly understand your frustrations (I used to have a lot of the same ones!). But I'm finding that OSS involvement has sharpened my skills more than I had expected, and has exposed me to other developers that I've learned a ton from (as well as providing a relationship-network for the next time I'm looking for work). I agree about Nashville - tons of great talent there (I was sad to leave!). There are great companies (like Firefly), but they're not getting the name recognition they deserve, IMO.

If & Else : Knockout.js vs. Backbone.js - Part 2

Wed, 27 Apr 2011 04:07:16 +0000

Diego - thanks for the comment. I read through your blog entry. I can understand your points regarding mixing HTML and JS - but when it comes to binding, it's going to happen at some point. Even if you use templates with Backbone, you still have to write a render method. The main difference (and this is what I think drives the decision for what most devs are comfortable with) is declarative vs imperative binding. You also brought up an interesting point about how Knockout.js doesn't directly address the model. This is because it's entirely situational. The model is the most malleable and fluid piece in MVVM, since it's the domain model effectively. Some MVVM frameworks might provide a level of 'scaffolding' for models, but too much and it becomes too prescriptive, making the model less expressive. I think you're right in suggesting the KO could benefit from additional infrastructure for save/validate, etc. (I'm actually working on a validation framework to plug into it.) I've used amplify.js for request/communications in my KO apps thus far and have been very happy with it. I also agree that there's much less overhead in changing template engines for Backbone - hopefully as other developers write template engine plugins for KO, this will improve. I've actually written one for KO - http://www.ifandelse.com/?p=100. (still jQuery templates, but allowing for them to be loaded externally). Thanks for sharing the link to your site. I look forward to checking out more of the work you're doing there!

If & Else : Knockout.js vs. Backbone.js – Part 1

Tue, 19 Apr 2011 16:24:23 +0000

Thanks for the info - I will check it out!

If & Else : Knockout.js vs. Backbone.js - Part 2

Sat, 16 Apr 2011 18:58:13 +0000

Joel - thanks! I've been meaning to check out javascriptMVC as well but hadn't had time yet. I agree on KO having a much quicker learning curve. The main complaints I've heard leveled at KO are things like "It doesn't have a built in way to talk to a RESTful server" or "It doesn't have built in validation", etc. Those things really don't bother me, since there are js projects out there than can be adapted to KO without much pain. One of my friends at appendTo recently told me about amplify.js - a library they're working on to abstract request, storage and pub/sub functionality. Something like amplify has been a great fit in my own tests in coming up with a consistent & clean way to have my KO projects talk to servers and storage, etc. I'm also working on a rough idea for a validation framework that will plug into KO (it will be viewmodel driven, and notify any subscribers in the UI of the results). I mention all that to say that I love how easy KO is not only to learn, but to extend!

If & Else : Making Knockout.js Support External Templates

Sat, 16 Apr 2011 18:51:49 +0000

Ryan - thanks for the input. I *love* the idea of just adding a hook to KO core and passing a callback. I'm going to mull that over this weekend and try to get something submitted early this week. It's funny you mentioned the idea of adding an 'init' function - I started to go that route twice and stopped myself (and can't for the life of me remember why I stopped). I hear you on forcing the ajax call to be synchronous! It left a queasy feeling in my stomach - but I didn't see a way in the existing code base to handle it asynchronously (without significant forking). I think a great thing for all of us KO devs to consider long term would be re-factoring key pipelines to operate async - it would probably provide an easier way to extend the core via injected callbacks (like your idea above). Also - just wanted to say that when I first stumbled onto Knockout.js, I read through a lot of your discussion board posts, and some of your site and I've seen the commits you've made on github - GREAT work man!

If & Else : Knockout.js vs. Backbone.js – Part 1

Tue, 12 Apr 2011 19:10:25 +0000

Andrew - thanks so much for the comment! My preference would be to use templates to avoid any html-embedding if I were to move forward with a project using backbone. I purposefully made one of the render functions use concatenated html to reflect the frequency with which I saw other backbone examples take that approach. I definitely see your point in arguing that the Knockout approach is no better in separating the concerns, but I disagree primarily because most web developers are already used to, for example, hooking DOM events up to js handlers via element attributes - and this fits that paradigm closely. Another reason why it's less intrusive to me, admittedly, is that declarative bindings are the norm in WPF and Silverlight - and I spent a good amount of time in WPF at my last job. When you have views driven primarily by declarative code, attribute bindings seem to be a more natural fit (in that they are readable, and provide a concise way of saying "Hey - I'm hooking this view into your model *here*.") than sifting through the behavior of a imperative-based view to see what declarative elements get emitted (or are referenced, in the case of templates). Of course - that's just my opinion. :-) While I personally lean towards frameworks like Knockout, I'm impressed with what I've seen done with Backbone - and I agree, the auto-REST loading & saving (plus the history features) are strong points for Backbone.

If & Else : Knockout.js vs. Backbone.js - Part 2

Tue, 12 Apr 2011 18:59:00 +0000

I haven't tried using view engine templates yet - but I think that will make for a great post after I talk about the template engine plugin!

If & Else : Knockout.js vs. Backbone.js – Part 1

Tue, 12 Apr 2011 05:52:24 +0000

Agreed - I'm not a fan of emitting (or embedding) any more HTML into JS than is absolutely necessary. This is one of the reasons the declarative binding approach of KO is so compelling. It feels (and looks) cleaner & helps separate the concerns.

Incremental Thought : Gratitude

Sat, 2 Apr 2011 00:08:39 +0000

Seth - thanks for the kind words! I'm sorry it's taken me so long to reply....life has been dense and busy (next thing I know, months have flown by and I haven't blogged a bit!).

If & Else : So You Want to Interview for a Senior Developer Position....

Tue, 23 Nov 2010 18:09:55 +0000

Several years ago, the CIO of the company I was working for and I brought a guy in for an interview who claimed he knew 35 programming languages. We *had* to bring him in, if solely for the entertainment value. As we suspected - he (along with his 11 page resume) was full of crap.

If & Else : So You Want to Interview for a Senior Developer Position....

Mon, 22 Nov 2010 21:24:40 +0000

WOW. Can't get over the fact that someone put "with an IQ of 168" on their resume. Ouch.

If & Else : So You Want to Interview for a Senior Developer Position....

Mon, 22 Nov 2010 18:51:11 +0000

Rob - I understand the argument many organizations make on standardizing platforms, etc. I think the problem with this approach in many instances is that it's driven by a vendor (who is also selling the platform) and not necessarily an objectively informed business. Not every organization really needs to have teams working in Java, .NET, Ruby and Erlang. But I think that businesses as a whole would fare far better by focusing their technology budgets on hiring top talent, rather than believing vendor hype that all their 'interoperability' woes will disappear if they just buy their products. When has this *ever* been true in anything beyond the simplest of applications? (I'm talking to you, organizations that decided SharePoint was a viable enterprise application development platform.) Also - good point on the dangers of talent moving on and taking knowledge with them. Just like distributed app architects will tell you that you MUST plan for failure (accept that it will happen, and code accordingly), businesses have to plan for this as well. Hiring top talent that can code expressively (following SOLID principles) and adopting methodologies that keeps the code as close to expressing the business domain as possible will make it much easier for new employees to get up to speed on the code base. But hiring a cowboy who doesn't feel the need to learn good architecture and implementation will be far more painful to the company both while he/she remains employed (since you're bound to run into issues with scalability and division of labor) and when they leave (since some poor soul is going to have to figure out why they wrote multiple triggers that all loop over inserted rows and call additional procs for each iteration....). My $.02. :-)

Stephanie Cowart : And Finally….a Date Night!

Wed, 17 Nov 2010 02:45:00 +0000

True, but Keanu Reeves kind ruins that equation. I'll take Denzel and Pine ANY day over Keanu.

Stephanie Cowart : Goodbye, Vox! Hello, Wordpress!

Sat, 4 Sep 2010 02:25:35 +0000

Yeah! So glad we finally got you set up on Wordpress.....hopefully you'll find more time to blog than I have....

If & Else : CouchRS - Building Your First Report against CouchDB using SSRS

Wed, 7 Jul 2010 01:09:30 +0000

...I definitely see tremendous potential for KPIs and targeted metrics (CouchDBs mapreduce functionality in views is great for this, so my latest post: http://ifandelse.com/2010/07/05/couchrs-creating-... but I don't think Type 1 and 2 SCDs are going to be addressed without some sort of ETL. The potential advantage though, is that an ETL that based in a higher level language like C#, and using a NoSQL store like CouchDB or MongoDB as both source and destination, could be incredibly fast. CouchDB also versions it's documents - so it's possible to programmatically examine the change history of a document over time - this has interesting implications not only for SCDs, but for rebuilding a warehouse from the ground up using current production data....

If & Else : CouchRS - Building Your First Report against CouchDB using SSRS

Wed, 7 Jul 2010 01:09:20 +0000

Jan - all great questions! I have a background in data warehousing (primarily using the Kimball/Star Schema method), and have been thinking through some of the same questions you asked. For me, part of the journey of CouchRS (and soon to be MongoRS) is to keeping pushing and see how much similar functionality (to a normal DW) I can produce from a NoSQL store. Regarding the question of Type 2 and 3 dimension changes - I'm not sure, yet, if a similar approach can be taken in a NoSQL store that would act as a workable substitute. I have no doubt as I work towards answering these types of questions that I'll be faced with the reality that data warehousing, necessarily by nature, imposes a different type of data model than what a typical domain model (on the app side) or relational model can provide... (more cont'd in next comment...)

Incremental Thought : From Community to Cult

Thu, 24 Jun 2010 05:25:31 +0000

Shawn - your wisdom is deeply appreciated. What a great translation of 2 Cor. 1:24! Thanks for the links as well, definitely going to check them out.

Incremental Thought : From Community to Cult

Thu, 24 Jun 2010 05:24:14 +0000

Thanks so much for the comment Jason - well written, as always! "There's such a danger in living bits & pieces of the Bible" - great way to phrase that! Paul warned that if we didn't have love, we're no better than a 'clanging cymbal'. I've seen churches hurt many believers because they stopped making the effort to live out a Biblically-based life in LOVE.