Intelligent Design : Technology

Hang with the Developers of Fellowship Technologies @ DC08

FTProductDev — Tue, 29 Apr 2008 17:32:00 GMT

The Development team here @ Fellowship Technologies wants to meet you @ Dynamic Church 08. We want get to know the men and women behind the screens. We've planned a few things so that we can connect with you and talk shop as well as get together for some fun time - why waste time sleeping.

Developers and non developers are welcome. Here's the schedule:

Thursday 15^th

200pm – Presentation(Rockhill) – Network Infrastructure (drez)

500pm – Presentation(Frisco 3) – Moving to REST (nfloyd)

- RESTing DEV

o Handout public keys and private secrets to all devs attending so that you can test drive the new API.

500pm – Presentation(Rockhill) – Leverage DataExchange(csimmons)

630-800pm - Group dinner – Dinner with dev - look for the tables marked "DEV" (probably in the back, away from the "normal" people)

900pm - Movie with Dev – just another opportunity to interact with other devs in an environment that we are comfortable where we don’t have to talk shop if we don’t want to.

Friday 16^th

1100am – Presentation(Rockhill) – Inside FT (drez)

1200-100pm – Birds of a feather lunch (We will be sitting @ the tables marked IT)

100pm – Presentation(Frisco 5) - Content Management (thardy)

230pm – Presentation(Rockhill) – Customizing Weblink(tcoulson)

730-930pm Concert

1000pm – Gaming with Dev – Go up against and talk trash to the Fellowship Technologies Devs in TF2. You don't want to miss this...

Saturday 17^th

1000-1200pm - Ask the experts (Frisco 5)

1. API 3 person panel discussion and questions with laptops open showing the code for the new RESTful API

2. Developers – Interact with the team responsible for building Fellowship One

Contact me with questions and let us know if we're going to see ya.

--Nick (nfloyd@fellowshiptech.com)

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

SXSW Day 3 - I know kung fu

nfloyd — Thu, 15 Mar 2007 18:27:00 GMT

Ok, so I don't know kungf u but I was able to make it to the Ajax Kung Fu Meets Accessibility Feng Shui panel. The first half of the presentation was pretty interesting. Jeremy Keith used some screen captures from the Matrix to help illustrate his points or at least make his presentation look cool. He talked about how there is a fine line when using cool new mechanisms like AJAX - a line that is often crossed making good apps go bad.

Next up was Gamer's Games: Microcontent and User Creation. My interest in this panel came from the unbelievable growth of user-generated content and how it has taken the web community by storm. What I didn't expect was the excellent discussion that we got into about the various types of content generated from users that exist outside of the normal cloud of graphics, movies, blogs, etc... things like personalities and relationships. It gave me a lot to think about regarding building community in the apps we write... good stuff.

After lunch we peddled over to Bullet Tooth Web Design: Plan Your Web Site like Pulling off a Robbery. This was more entertainment than application, and I figured that wearing black ski masks in our daily scrum probably would not go over well with management. They highlighted the "quick and dirty" on how to approach web projects...

The highlight of the day was the Yahoo! BarTab after party. Not just because there was tons of swag, or free everything, or even because we got to hear The Little Ones (they definitely were a highlight though). We had a unique opportunity to interrupt Robert Hoekman Jr. and his wife having a conversation. Originally we thought that we missed an opportunity to talk to him during his "Why we should ignore users" panel - but we successfully backed him into a corner and fired away. It was an awesome experience. It was nice to talk to someone who truly loved doing what they do.

SXSW Day 2 - Why we should ignore our users... Wha?

nfloyd — Wed, 14 Mar 2007 18:49:00 GMT

After dragging ourselves out of the hotel room (it seems that Austin has some sort of mystical property that makes you super-tired in the morning. Combine that with the time zone change = 2 grumpy coders. 2 grumpy coders + Starbucks in the convention center = :) ).

After getting some caffeine we hit the doors running and made it to the best panel of the day: Why We Should Ignore Users. Cutting through all of the analogies and acronyms the session mostly focused on ACD, err I mean Activity-Centered Design and User-Centered Design. Robert Hoekman Jr., arguably one of the best designers in the industry, provided some strong points for going with ACD. My personal opinions on it is that ACD is the way to go, it gives the team a rallying point and a solid filter to avoid creep and other project killers. A side note I definitely recommend reading Hoekman's book: Designing the Obvious - you will not be disappointed.

Shortly after I hit an unexpected jewel of a panel: Serious Games: Can Learning Be Hard Fun? Serious games can be defined as any game that provides any type of educational benefit beyond the basic entertainment value. The little goodie that came from this panel wasn't seeing them play cool games, or talk about the business side of educational games, but rather hearing them share their point of views on what happens when you involve users and the community in the software development process. The real focus of the panel ended up being how to engage your users and keep them engaged.

We then hit: ValleySpeak for the Rest of Us: Developing Apps Outside InternetVille. Pretty good stuff - the panel consisted of Dan Cederholm and Brian Oberkirch. No real hot points - it seemed that they were just trying to point out the fact that really good software can be developed outside of Silicon Valley. Right now one place comes to mind: Irving, Texas.

Uniting the Holy Trinity of Web Design capped off our day. They began talking about the 3 aspects of web design -- Data (HTML), Style (CSS), and Behavior (JavaScript) -- but later jumped into team interaction and development / design as they have experienced it...

All and all a pretty good day... more to come

Technology with a purpose

thardy — Fri, 08 Sep 2006 00:49:00 GMT

A common theme you'll probably hear about from many of us at Fellowship Tech is how we desire to use our talents and skills for a purpose. Not just any purpose will do, either. We want that purpose to ultimately be God's purpose for our lives.

I just want to give a short expression of that passion from a developer's perspective. Development is a wonderful thing. It's a bit frustrating having a mindset that is always breaking things down, analyzing scenarios, and trying to come up with better ways of doing things - such as why, with all of our vast technology, traffic lights still stop you at 1am when you're the only person on the road. I bet most people don't think long and hard about how to improve the flow through a buffet line either.

While it has its downsides, there are also a lot of benefits. The greatest and most enjoyable for me is the creative aspect. You start with nothing, and you create - something, something that does something. Hopefully that something is useful, beneficial, and improves someone's life. It's even better if it leads people to the Lord or meets people's practical needs, just like He does. I'm glad the Lord is using my skills to help His church. While I have the common developer's desire to create something elegant and useful, I also have the greater desire to reflect the glory of God and be used by Him.

I feel blessed to be able to do both, and humbled by the fact that both are still very much a process.