Intelligent Design : development

DC09 - DevCon Code, Slides, Videos

FTProductDev — Tue, 26 May 2009 04:50:00 GMT

We have wrangled all of the devs and gathered all of the content that you saw at the DC09 DevCon. Since we are community focused, we wanted you to have as much code and information that you'd need to get jump started for the RESTful API BETA so that you'll be able to discuss / communicate your ideas on consuming the REST API throughout the Social-Sphere. We've got much more to come with the upcoming launch of our developer community site and the general release of the REST API. Please take a moment to check out the goodies below - the whole dev team really "kicked out the ladder" so that we could give you real world, ministry focused code.

Application #1: F1Touch (Team Fire - iPhone) – 1st Party
Developers: Matt Vasquez, Chad Meyer
Description:
Our app is an iPhone application as a first party vendor open to all churches that opt in. Our application will provide the ability for church portal users to quickly look up congregants and contact them via phone or email as well as pull up Google maps to assist in directions to their house.

Content
Chad Meyer's blog post | Slide Deck | OAuth Lib

Application #2: Outreach (Team Air - Facebook) – 3rd Party
Developers: Ryan Champ, Jas Singh, Kelly Klein
Description:
Facebook is a social networking website with over 200 Million active users. How does the church engage, minister to, and help people through this social medium? Furthermore, is there a way to convert connections made in Facebook into potential church members?

We tackle the problem with a prototype of application that functions with the overarching concept of “Virtual Outreach over Virtual Church.” Not only do we aim to build an ecology of people helping each other, but by reaching out to people and helping them deal with issues that affect their lives, church ministers and lay leadership can build “social capital” and trust in the digital world. This, in turn, will make their invitations to check out the church family much more appealing. Prospects, thus invited via the Outreach app, will then be routed directly into the church’s Fellowship One database.

Content
Video | Slide deck | Code | OAuth Lib

Application #3: Listee (Team Earth – Expression Engine) – 2nd Party
Developers: Nathan Smith, Jingyi Wang
Description:
This module allows a web designer to easily include F1 data using the ExpressionEngine content management system. The benefit of this is that EE is a very popular CMS for high-end designers, because it's templating language is so intuitive.

Content
Video | Slide deck | Code | OAuth Lib

Application #4: IWANTTOSERVE.COM (Team Water - .NET MVC) – 3rd Party
Developers: Tim Hardy, Tudor Lupan
Description:
We’ve developed a “Needs board” application that allows church members (anyone with a WebLink login) to post needs and search needs to minister to each other. There is a tremendous need for a technical tool that can direct member’s willingness to serve to the valid needs of others. While several tools have attempted to provide this functionality, none have taken advantage of the tried-and-true community self-monitoring patterns established by services such as ebay. We’ve implemented a double opt-in system – the need submitter has to “Accept” a helper’s willingness to help, and the helper has to then “Commit”. Both the submitter and the committed helpers can then rate each other to curb service abuses once the need has been met or the due date expired. It completely leverages WebLink logins for authentication, and it contains a fully functional user profile editor

Content
Video | Slide deck | Code | OAuth Lib

Nick Floyd - Integration Architect

Fellowship One APIs - Past, Present, and Future

FTProductDev — Wed, 25 Feb 2009 22:42:00 GMT

With the up coming Fellowship One RESTful API we wanted to take the some time and look back on our other two APIs and reflect on what we intended them to be and what they actually became. We looked at the their interfaces, authentication, resources, versioning, protocols, logging mechanisms, "debuggability", etc... What we found out was that in the world of "API" nothing ever ends up like you intend.

Fellowship One Data Exchange: A very powerful XML RPC API that was specifically designed to address massive data import and export needs. It's ridged pinpoint interface allow users to build simple data presses, which move large amounts of data between disparate systems. A few years into the product's life we introduced the ability to do synchronous transactions - a decision that completely changed many consumer's usage patterns.

Serendipity stepped in and instantly consumers began to use this brute force application on websites to perform anything from profile updates to seamless login patterns. After seeing how much the community found value in the login metaphor we've published docs and given presentations on the best practices of this approach. We now have 3rd parties writing web applications and hosting web sites that do a myriad of things.

Being a SOAP based .NET web service, consuming Data Exchange required the language to either have a library that constructs SOAP envelopes or that the developer understand that protocol and be able to construct a SOAP message manually.

Another characteristic of this API are the logging and response mechanisms; both were intended to only be used / interpreted by the consuming application. Its authentication is based on simple credential / key maps.

Fellowship One Payment Gateway: A .NET SOAP based web service that gives churches the ability to submit giving / e-commerce transactions. The interesting thing about this service is that it was originally developed for internal consumption only and later opened up to external consumers for book stores, tithe applications, etc... another decision point that changed the way an established API was used.

Payment Gateway answered a changeling question of: "how do I get all of my billing and payments to go through one channel and be able to report on the transactions going through that channel?" Much like Data Exchange, we saw it consumed in ways we couldn't have imagined.

We used credential and signed key authentication for this API.

Fellowship One RESTful API: A REST based web application that uses several open protocols and patterns to provide consumers access to secure resources.

STANDARDS, PROTOCOLS, and PATTERNS - nothing else. Looking back, we could see where their is major value in sticking with something that is "tried and true." If we could use web based patterns and protocols for a web based API we could not only get instant adoption but gain the efficiencies and effectiveness of technologies that "just work."

This next generation of API is, ironically based on foundations that have been in place for years. We chose MVC as the application architecture, OAUTH protocol for Authentication, REST and HTTP 1.1 as the transport. This API should give web developers an tool where all they have to think about is what to do with the resources.

Thank you for partnering with us over the years; we have a lot of fun stuff up ahead and we hope to see you at the Dev track @ DC09!

Coming January - Household/Individual 2.0 (try it out now)

CurtisHarris — Wed, 19 Nov 2008 14:37:00 GMT

We started the conversation here, in this blog forum, re: the replacement of Household/Individual. The goal was to see the "whole picture", make it easier to add/edit/delete details, and provide an intuitive user interface that was easy and enjoyable to use. Our dev team took this project as a challenge to show off a development style that keeps them focused, accountable, and delivers what the user asked for; they blew me away!

Working with the dev team intimately on screen design, we then immediately shared those with you and many other stakeholders to identify exactly what was needed. Everything was broken down into “whole” tasks and allotted out every two weeks; quick 10 minute meetings were held every morning to identify progress and roadblocks. There were constant reviews to validate that what was being built was in align with the vision. Did it work? The proof is in the pudding, four short months later, with other projects that still demanded developer time, the first release of Household/Individual 2.0 is ready for the big time and I am excited! Replacing these legacy pages is important for a lot of reasons:

Establishes another key building block that plays to our vision for F1
Everyone, no matter your role, is exposed to these pages so improvements here are felt across the board
Household/Individual detail pages account for more of our bandwidth than all other pages combined; improvements here impact our overall performance
It is our constant goal to improve visibility to your congregation; this takes a big step in that direction

If you had been following the design conversations we had 4 months ago, you will undoubtedly notice that there are some things we have further improved upon, but also some aspects that are missing; this is an iterative process and you can expect improvements that further flesh some details out over the coming months.

Check out the EDUCATION tab above for detailed information, instruction, and direction to play with the new design in a safe environment.

DC08 RESTful rewind

FTProductDev — Sat, 14 Jun 2008 09:19:00 GMT

A few of you guys wanted the video from the conference on the RESTful API. We decided to go back and condense the presentation to give you a more tangible look @ the new API.

Look for more videos in the upcoming weeks to address questions and thoughts that have been coming our way. Thx guys for the awesome feedback - you guys rock!

Download here

- F1Dev

I AM DEV

FTProductDev — Thu, 10 Apr 2008 16:29:00 GMT

I'm the guy who moves stuff around in your favorite application, for what seems like no apparent reason.

My drink of choice is caffeine.

My shoe of choice is flip-flop.

My store of choice is Starbucks, which I ~~walk~~ drive to wearing my flip-flops, to get caffeine

My wife, since I am fortunate to have one, calls me her "big, strong, nerd" - never mind the catastrophic oxymoron that the phrase produces; I would prefer a better wife handle though, something like zerocool or n00bpwner

Yes, I married up; no, I did not use my geek super powers to do so…

I take things apart on purpose knowing that there is no way I will be able to put them back together.

I cringe when people use CPU or HARDDRIVE as synonyms for COMPUTER

I have more than 2 browsers installed on my CPU.

I used to think business people "ph33r’d" my elite hacking skills, but I found out they just think I am weird and that's really why they avoid me.

When given the option I would take a bean bag over a chair any day

The first rule about being a Developer is that you don’t talk about being a developer

When asked to clean the house I have to create a list and organize it so that the tasks get accomplished in the most efficient way - the list takes about 1-2hrs to prepare assuming no bugs and no interruptions (note to self: write program to generate list).

If it is worth doing it is worth overdoing.

My children still want to be like me when they grow up.

I am a keyboard cowboy - but I have no idea how to actually type.

I speak in crypto-nerd tongue to get out of meetings (works much like a Jedi mind trick only not as cool).

Crypto-nerd tongue gets turned off if I know there is a chance in the meeting that technical terms will be butchered (like using CPU for COMPUTER – high developer entertainment value) or there will be coffee.

I run out of my allotted number of words per day faster because I use Acronyms.

When faced with a challenge, I reassign the work item.

The second rule about being a Developer is that you don’t talk about being a developer.

Script is not something you read, and when you talk about Java, as a safety measure, you should specify upfront if you're talking about the tasty beverage or code.

People think I show up to work early, not true; I just leave late.

Despite what most might think I do not just copy and paste code... I change the comments too.

And, yes business users, "All Your Base Are Belong To Us"

I am dev…

A Little Christmas Coding Magic

FTProductDev — Thu, 13 Dec 2007 07:01:00 GMT

When I was a kid I loved magic - simple card tricks to Copperfield’s million dollar illusions, I was easily mesmerized and mystified. People have been bending what we THINK is reality for years. Take a look at the picture - Which way does this window face. Are the people on the inside looking to the left or looking to the right? Are you looking up into the window, or are you looking down into the window?

Same thing goes for programming – what we type out in code does not always translate to "what is" during execution; especially if you’re dealing with a compiler between what you write and assembled code delivered into production.

Take the battle between a couple of conditional processing structures provided in C# (and most other languages): Who’s “better” regarding efficiency and elegance - a switch (case) statement or If-Else conditional statement. The GoOracle would tell you this is a no brainer, and logically we would assume that switch would perform better because the framework does not have to evaluate each statement in the flow.

Let’s assume otherwise and challenge the norm given the following code in pre-compiled form:

private static void SwitchSingleCondition() {

Stopwatch timer = new Stopwatch();

timer.Start(); // Start the timer

string compare = "a";

for (long i = 1; i <= 10000; i++) {

switch (compare) {

case "a":

compare = "b";

break;

case "b":

compare = "a";

break;

default:

compare = "a";

break;

}

timer.Stop(); // Stop the timer

Console.WriteLine("Execution time for 'Switch Single Condition' was {0:F1} microseconds.", (decimal)timer.Elapsed.Ticks / 10M);

}

private static void IfSingleCondition() {

Stopwatch timer = new Stopwatch();

timer.Start(); // Start the timer

string compare = "a";

for (long i = 1; i <= 10000; i++) {

if (compare == "a") {

compare = "b";

} else if (compare == "b") {

compare = "a";

} else {

compare = "a";

}

timer.Stop(); // Stop the timer

Console.WriteLine("Execution time for 'If Single Condition' was {0:F1} microseconds.", (decimal)timer.Elapsed.Ticks / 10M);

}

When executed we get the following results:

Why did the “if statement” run more efficiently than the switch? Let’s pull back the curtain and take away the mirrors – this is what the code looks like after compilation (Reflector you rock!):

private static void SwitchSingleCondition()

{

Stopwatch timer = new Stopwatch();

timer.Start();

string compare = "a";

for (long i = 1L; i <= 0x2710L; i += 1L) {

string CS$0$0000 = compare;

if (CS$0$0000 == null) {

goto Label_004B;

}

if (!(CS$0$0000 == "a")){

if (CS$0$0000 == "b"){

goto Label_0043;

}

goto Label_004B;

}

compare = "b";

continue;

Label_0043:

compare = "a";

continue;

Label_004B:

compare = "a";

}

timer.Stop();

decimal CS$0$0000 = timer.Elapsed.Ticks / 10M;

Console.WriteLine("Execution time for 'Switch Single Condition' was {0:F1} microseconds.", CS$0$0000);}

private static void IfSingleCondition()

{

Stopwatch timer = new Stopwatch();

timer.Start();

string compare = "a";

for (long i = 1L; i <= 0x2710L; i += 1L) {

if (compare == "a"){

compare = "b";

}

else if (compare == "b"){

compare = "a";

}

Else {

compare = "a";

}

timer.Stop();

decimal CS$0$0000 = timer.Elapsed.Ticks / 10M;

Console.WriteLine("Execution time for 'If Single Condition' was {0:F1} microseconds.", CS$0$0000);

}

Are you kidding me – the “if” logic even looks more elegant! So what happened? It seems that behind the smoke, mirrors, and assumptions the .NET framework looks at the code that was written and restructures it to what it thinks will be more efficient using if-else conditions, “goto” statements, and a labeling system. Once your case statement exceeds 4 conditions the compiler will leave the code alone and execute it as a normal switch case.

It turns out that if-else-if statements can and most likely will be more efficient than switch statements when the number conditions do not exceed four. Things aren't always what they seem. Don’t be blinded by the magic – challenge your assumptions - until they become fact.

--nick

Plasma, Dog Plasma: Generics vs. Objects

FTProductDev — Tue, 04 Dec 2007 06:36:00 GMT

I came across an interesting quote from Tony Northrup regarding .net Generics:

“I haven’t been able to reproduce the performance benefits of generics; however, according to Microsoft, generics are faster than using casting. In practice, casting proved to be several times faster than using a generic. However, you probably won't notice performance differences in your applications.”

That reminded me of a 1954 cartoon called "Crazy Mixed Up Pup." There was a Doctor who was given a couple bottles of plasma but couldn't figure out which to use on the dog and which to use on the man - pure genius. While I hope I am never faced with the decision of which bottle of plasma to wire up to dog or man, I often face the struggle of pulling out the right tool for a given need.

For instance, .net has several different types of collections, not to mention generic collections introduced in 2.0, and others introduced by the community. Let's face it, our tool bags are getting bigger, more robust - what do we do when we're introduced to things like Tony's discovery?

I chose to put together a little project to see if I could reproduce his findings and dig out the right tool...

1. Created a console application

2. Then 2 classes

a. Object with two public members that where of type System.Object

b. Generic with two public members that were generic types

using System;

using System.Collections.Generic;

using System.Text;

namespace ObjectVSGenerics {

class Program {

static void Main(string[] args) {

RunTest(Console.ReadKey().Key);

Console.ReadLine();

}

private static void RunTest(System.ConsoleKey key) {

Int64 start = DateTime.Now.Ticks;

for (int i = 0; i <= 1000000; i++) {

if (key == ConsoleKey.O) {

Obj o = new Obj(1, 1);

int objInt = o.sum();//(int)o.obj1 + (int)o.obj2;

} else if (key == ConsoleKey.G) {

Gen<int, int> g = new Gen<int, int>(1, 1);

int genInt = g.t + g.u;

}

Int64 processingSeconds = (DateTime.Now.Ticks - start) / TimeSpan.TicksPerMillisecond;

Console.WriteLine(" Process time in Milliseconds " + key.ToString() + ": " + (processingSeconds).ToString());

Console.Write("Enter another: ");

RunTest(Console.ReadKey().Key);

}

This is what I found:

Build / Framework	Generic mean exec time	Object mean exec time	% Efficiency
Debug .net 2.0	32ms	77ms	58% (Generic)
Debug .net 3.0	33ms	78ms	57% (Generic)
Debug .net 3.5	33ms	80ms	59% (Generic)
Release .net 2.0	15ms	64ms	76.5% (Generic)
Release .net 3.0	15ms	58ms	74% (Generic)
Release .net 3.5	15ms	57ms	74% (Generic)

Now, while I was not able to reproduce Tony’s findings and the scenario above was not a “real world” scenario (looping and instantiating an object or generic 1 million times in a given execution) I was able to conclude a few things:

· The efficiency of the generic was higher than the object, and the efficiency of both were higher when executing Release code. It makes total sense why a release build would be faster, especially regarding recursion (the framework is less aggressive about cleaning up resources in debug code, plus other optimizations). However, why did the object stay close to the same execution mean and the generic become roughly 50% faster?

o Check out this post by the C# team. Basically this improvement is because the actual implementation is created at runtime. So when I create Gen<int, int> the JIT will see if it has previously been compiled and if it has will reuse it. Secondly the Object implementation will always require boxing and unboxing of the value type int – that simply will not change, Release or not.

· In this book Tony points out that a really good reason to use Generics is simply because they are type-safe. Meaning that during compilation if a value you’re providing to your generic does not match the instantiated instance’s definition the compiler will error. Generic code is only valid if it will compile every possible instance of the generic.

· Finally, if you notice in the code above I created a method in the Object class to encapsulate the “sum” functionality. Normally, you probably would not do this because when dealing with objects - you’re already running the risk of no type safety during runtime. But to make a point – Generics cannot perform this sort of encapsulation; operators cannot be used as logic mechanisms. When generic code is compiled it maintains its “generic-ness.” Therefore anything that would explicitly require a certain type will not compile.

The bottom-line is “real-world” forces you to use all of the tools in your tool bag, not just the cool ones. We love adopting new technologies at Fellowship Technologies; we have to ride the razor’s edge to be able to evaluate and use the best that is out there so that we can build the best.

Generics seem to have a pretty significant advantage over objects and casting - it's a tool, I think, that has the possibility of make some solid, clean, and fast code.

--nick

What do QA, a SaaS company, and Christmas have in common?

FTProductDev — Mon, 03 Dec 2007 15:32:00 GMT

Fellowship Technologies, of course!

Let's establish a baseline and start with what we know. According to Merriam-Webster, the definition of quality assurance is, "…a program for the systematic monitoring and evaluation of the various aspects of a project, service, or facility to ensure that standards of quality are being met." Fellowship Technologies, "...believes that work is a form of worship." according to just one of our many core values. Finally, and ultimately, according to scripture, Col 3:23-24 states "23Whatever you do, work at it with all your heart, as working for the Lord, not for men, 24since you know that you will receive an inheritance from the Lord as a reward. It is the Lord Christ you are serving." NIV

So, how does this all tie together? In the realm of software development, QA should be fairly simple, right? After all, it either works or it doesn't, right? And if, as a company, we are all practicing scripture and, "…working for the Lord…", then do we really need checks and balances? Yes. Allow me to explain…

A little perspective…I don't see my role, or the role of QA at FT, as checking others' work, pointing out someone's mistakes, or finding fault. QA is part of a team. The team works together to accomplish the common goal of producing a quality product allowing those utilizing it more time to manage, minister, and serve within the local church. This is what makes product development at FT team unique. We work as a team within the process of customer demand through user forums and working closely with Product Management, IT, Support and others. Not to mention the immediate attention required for unforeseen technical events, and…drum roll please…bugs.

Bugs certainly take their portion of the total pie of development challenges. This is normal. Some are found during development. Some are found during QA. And some are kindly brought to our attention through our clients. Adopting an agile work environment allows QA to be part of the product developmental process.

"On an agile , story driven project, testing is not the antagonistic activity that it becomes for many teams. There is no "I gotcha" mentality when a bug is found. There is no room for passing the blame when a bug makes it all the way to production. The highly-collaborative, we're all-in-this-together mentality of the team prevents this.

"On an agile project, we test to find and eliminate bugs; we don't necessarily pursue goals of 100% code coverage or testing of all boundary conditions. We use our intuition, our knowledge, and our past experience to guide our test effort."

Mike Cohn, (2004). User Stories Applied For Agile Software Development. p. 72

We are a team. Leaning on each other's expertise, knowledge and being accountable, we can commit to giving our best every day. We can commit to FT's core values. And finally, we can commit to living the word as closely as humanly possible to help further the kingdom. I'm proud to be a part of this effort. In the mean time, we thank God for grace and look forward to the future He has in store for us!

- Jason

Competing on the basis of speed - Being "lean" about development

nfloyd — Mon, 19 Mar 2007 12:58:00 GMT

I came across this "good and tasty" while doing some research on Agile as it is applied to the rapidly growing, and changing Game industry. Since there are thousands of different gaming software companies, only a handful of true game types (MMORPG, Strategy, FPS, etc...), and several barriers to market, the developers of these companies are realizing that development methodologies such as waterfall and RUP are arcane and wasteful. The old school methodologies can be the product killer; instead, you have to move like the web and be accurate on your delivery. ("Inspect/Test to prevent defects, not to find them").

Check out this Google Tech Talk by Mary Poppendieck on Lean software development. It is about an hour long, but well worth the time. In it she discusses set based design, testing methodologies, queuing theory, and development cycle time. The tech talk is not just for devs either - Management, QA, support, etc... will definitely find it applicable.

Drop the queue (or at least make it smaller)! Go Agile!

Old Dog, New App

nfloyd — Thu, 15 Feb 2007 19:08:00 GMT

Last night I finished my taxes. Though it was no small feat it seemed almost pleasurable - before you call the IRS / local asylums (one in the same) let me explain:

A coworker turned me on to an awesome book by Robert Hoekman, Jr named designing the obvious. Hoekman talks about practical approaches to designing web applications - nothing revolutionary, right? That's what I thought...

In the past I have always bought the tax software, downloaded it, installed it, updated it, used it (rather misused it), updated it again, submitted my taxes, then uninstalled it - never to be used again. I do this because, just as Hoekman explains, "Typically, users latch on to the first [software] tool they find that they can tolerate, and they stick to it."

Yes, I lost count of how many times the application crashed or had to be updated, and it wasn't the fastest or easiest to use, and yes I often felt like the software was telling me "you're not good enough to use me, do you even know what a 1040x is, ummm you don't need to use that field but I have displayed it there to mislead you muahaha...". But I used it none the less, not willing to try the web version.

From "designing the obvious": "When an application is designed badly, it tells you at every opportunity just how bad it is. But when it's good, you usually can't explain why it's good. You can't put your finger on it, but you know it when you see it."

I used the web version of the software this year. Initially I was insulted, barking out things like, "What!? You can't even search on which form your using", "Where are the long explanations of what fields 1-200 mean", or "Where are the gratuitous fields that are intended to mislead and distract". As I used the app I began to get it - this old dog was eating his own food.

They designed the online tax program based on the activity that needed to be preformed (Activity-Centered Design - Designing Web Applications for Use) and dropped the over abundance of "enhancements" and so called "features" its client based brother has.

After being humbled by great software design and confidently addressing the burning hot coals of Tax Season I felt good, empowered almost. "Software shouldn't force users to understand how it works so they can learn to do things with it." - designing the obvious

That's what makes good software, that's what makes an obvious design, that's what empowers users to get the job done.

Asp.Net vs. Standards

mvasquez — Fri, 02 Feb 2007 23:29:00 GMT

A few months back I converted our site template from a table-based layout to a standards based design. This was not a trivial task, in essence I "touched" every page in our app, which is more than 300 pages. Recently we released major pieces of functionality, both using standards based html and heavy client-side functionality (ajax via prototype, effects/drag drop via scriptaculous). For the entirety of the project I was in a constant struggle with asp.net and it's blatant disregard for supporting standards based design and HTML standards in general. Listed below are the issues that drove me to the edge of insanity, almost to the point of shunning off asp.net forever.

INamingContainer

I understand the need to uniquely identify objects in the control tree. But why does that id have to be persisted to the client? How are you suppose to get a reference to an element in css or javascript if you can't rely on the id? I've got an idea, stop trying to hold my hand and let me be responsible for uniquely identifying my controls. This leads to abusing the class attribute and using it where it simply should not be needed.

One form per page with runat="server"

I've been told that this has since been addressed in 2.0. In 1.1 this is unacceptable, for instance, in our site template we have a drop down within our sub navigation (don't ask me why it is in the navigation) that contains all ministries a user has rights to. This drop down should be contained within it's own form, along with a form containing all controls within the main content section. but because a) System.Web.UI.WebControls.DropDownLists must be contained within a form with runat="server" and B) only one form with runat="server" is allowed on the page; I now have to encapsulate the entire sub navigation and content in a single form. There-by sacrificing good design.

Controls render horrendous HTML

So I've just added a System.Web.UI.WebControls.DataGrid and I've set the DisplayHeader to true and HeaderText to "Name". Ok, let's see here, we have a grid that should be displayed as a table (check). We have a header for that grid/table, so that should be a table header, th tag, (che....oh wait). Where is the th tag? There are too many of these instances to list each one.

System.Web.UI.WebControls.Label renders as a span tag

Did anyone on the asp.net team even look at the HTML specification?

No support for OPTGROUP element

Seriously? I mean, come on, DID ANYONE EVEN LOOK AT THE HTML SPECIFICATION?

Quirksmode is default for new aspx pages

If you truly support web standards how can you default a document to Quirksmode.

No easy way to get HTML from a server-side control

A significant advantage of ajax is not having to render the entire page, especially if sections of the page may or may not be used. On the server an ajax request is not handled any differently than clicking a button or link. There is a significant advantage in being able to request pieces of HTML from the server and respond with that HTML to be rendered on the client (AHAH). but because asp.net controls must a) be apart of a form with runat="server" and b) cannot be rendered before the form is rendered, this is impossible. Besides creating a user control and then loading that control at runtime there is no way to get HTML from an aspx page. Well, no way that I could come up with.

System.Web.UI.WebControls.DropDownList must be contained within a form with runat="server"

Why?

Did I miss something? I'm not too terribly familiar with the machine.config or the web.config, maybe I forgot to include <standards-mode enabled="true" />? Microsoft's marketing machine can preach all they want about standards support (why do I still have to use the Holly Hack in IE7, wasn't this bug fixed? ), but marketing will only go so far. People will tell me that concessions have to be made in order to support the designer and being able to drag and drop a control from the toolbox. But you know what, I don't care, if your dragging and dropping controls from the toolbox then you need to find another profession. Creating web applications is not for you.

Does anyone else struggle with these issues?

Time is a constraint we should embrace

mvasquez — Tue, 03 Oct 2006 16:09:00 GMT

In a perfect world developers would have an infinite amount of time to create the most elegant, perfect, scalable and enterprise-quality architecture/solution ever. This, my friend, would rival the airplane. Heck, it might even rival God's greatest creation. Well, sorry to be the bearer of bad news: this is not a perfect world. Time, in anything we do in life (development included), will always be a constraint. You will never have enough time.

Time is a good constraint.

When we embrace time as a constraint, we take the first step of being real with ourselves. If we truly don't have enough time to implement what has been asked for, we have to be open about it. We have to be real about deadlines. We have to get real about project management and cut scope, change the design, or reprioritize requirements. Or we have to get more time.

If the functionality is important enough, they (customers, bosses, etc.) will find the time.

This is when we can throw all excuses out the window and begin thinking creatively in order to work within our constraints. As developers, this is where we live. Time is a constraint that we should embrace as an opportunity to be creative. So, the next time you hack together a piece of functionality, don't use time as an excuse. Be real with yourself: what truly caused you to make that decision?