How much code can you generate in a day?

We are actively recruiting participants to take place in a developer event (“Dev Derby“) that pits one language against others. It is a day-long programming challenge where teams of developers work to create an application serving a real-world need. Five teams will represent different programming languages—PHP, C#, Ruby, ColdFusion, and Java—to produce a demo application that will be released as open source software.

http://devderby.com/application/

Team Leaders for each language will review applications and select competitively balanced squads. There is no cost to enter, but spots on teams are limited. Winning teams can win prizes and all participants are eligible for discounts to other tech events taking place that week.

The Dev Derby will start and end on Saturday, September 11, 2010, in Bloomington, Indiana. It is part of The Combine (http://thecombine.org), the area’s first major technology conference, and at the start of the BFusion/BFlex conference (http://bflex.info). Dev Derby involves an intense six-hour coding session.

Each challenge submission will be judged by knowledge leaders and representatives of the non-profit organizations benefiting from this work. The criteria spans Design (features and UI choices made), Technical Efficiency (code and performance), Communication (documentation and presentation), and Practical Value (use, adoption, and maintenance).

Prizes will be awarded at the end of the day, following a panel discussion about the development process and the future of application programming.

Dev Derby is situated in The Combine along with other technology-related events, such as Tech Cocktail, Ignite Bloomington, and a variety of of other gatherings. It is hosted by the BFusion/BFlex conference, a two-day hands-on training event from the experts of Adobe Flex and ColdFusion. Dev Derby is inspired by our experience with Startup Weekend in 2008, but with a short day of coding and focused on a specific challenge.

Apply now: http://devderby.com/application/

The team leaders for Dev Derby have been asked to list what we consider valuable professional reading. Our book selections are not limited to our respective Languages. I thought I would share my list with everyone.

The first 2 (GoF design patterns and Patterns of enterprise application architecture) really just need to be in every developer’s library. The rest are a collections of books I’ve read and liked as well as recommendations from developers I like and respect. Keith Casey pointed me in the general direction of a lot of these books.I suspect that some of the Dev Derby people will end up contacting various publishers to solicit swag sometime soon.

In other news about Dev Derby, I think that an application for teams should be available to announce sometime soon geneerinen cialis. I do know we have a deadline for selection approaching and it’s kinda hard to select without people to select from.

GoF design patterns:
* ISBN-10: 0201633612
* ISBN-13: 978-020163361

Patterns of enterprise application architecture:
* ISBN-10: 0321127420
* ISBN-13: 978-0321127426

Code Reading:
* ISBN-10: 0201799405
* ISBN-13: 978-0201799408

Guide to PHP Design Patterns:
* ISBN-10: 0973589825
* ISBN-13: 978-0973589825

Building Scalable Web Sites:
* ISBN-10: 0596102356
* ISBN-13: 978-0596102357

Peopleware:
* ISBN-10: 0932633439
* ISBN-13: 978-0932633439

Mythical Man Month:
* ISBN-10: 0201835959
* ISBN-13: 978-0201835953

The Pragmatic Programmer:
* ISBN-10: 020161622X
* ISBN-13: 978-0201616224

Code Complete:
* ISBN-10: 0735619670
* ISBN-13: 978-0735619678

Zend PHP 5 Certification Study Guide:
* ISBN-10: 0973862149
* ISBN-13: 978-0973862140

Guide to PHP Security:
* ISBN-10: 0973862106
* ISBN-13: 978-0973862102

Guide to Enterprise PHP Development:
* ISBN-10: 0973862181
* ISBN-13: 978-0973862188

Guide to Programming with Zend Framework
* ISBN-10: 0973862157
* ISBN-13: 978-0973862157

Related articles by Zemanta

• Dev Derby (phpprotip.com)

What is Dev Derby?

The Combine (http://thecombine.org) is a tech event in Bloomington, IN going on from Sept. 9th-12th. On Sept. 11 there will be a “Dev Derby”. This is a one-day programming event which challenges teams, representing different programming languages, to build a web-based application for use by non-profits. The code will be released as open source, giving it life after the day has ended. There will be 5 teams competing. My suspicions say that there will be a Rails team and a CF team in addition to the PHP team.

I’m not sure how finalized some of the information I have on the details are but here is what I do know:

• Each team will be limited to 7 people (including myself). Depending on demand by Combine attendees, they may allow up to 3 additional “walk-ons”.
• The nature of the challenge won’t be revealed until Sept. 8.
• As team leader, I will be participating in the planning of this event, helping shape the challenge scope, defining the technical environment and determining the judging criteria.
• From the sound of things, we will have some sort of requirements spec to work off of and plan the project from.
• A designated team member or myself will be in a panel discussion sharing the team process and debating code with other team representatives.
• The Combine will have a recruiting campaign with a link to an application to collect names of interested developers. (If you’re impatient and want to be part of the glorious PHP team, hit me up)
• We will be provided with a food an d beverages that day. NOMS!
• There will be prizes. Some just for participating.

Team PHP

Until I start having to sift through applications for team members, I’m wondering who I’d need to hit up for some elePHPant T-Shirts for Team PHP to have. Also, we need a better pseudonym than “Team PHP” or at least some sort of awesome slogan to bring fear and envy into the hearts of our opponents. Join me and together we shall rule the galaxy in the fun and help crush our enemies, see them driven before us and hear the lamentation of their women show the awesomeness that is PHP.

From my point of view, the discussion centered around what is the best ‘default’ visibility to use for methods. Another thing touched upon is the Open/Closed principle, which I think I subscribe to or may subscribe to(this depends on my ability to determine what half of the words in the entry mean).

Out of the whole discussion, here is the points I got (aka understood) out of it. Please correct me in the comments if I’m off base in any way.

Methods should only be public when necessary. This is to help reduce the amount of side-effects that can occur because of method overrides.

K, I can accept that and in thinking about my past code, I use to use protected more than private. I used public very sparingly.
Now I find, since I started unit testing, that I have a large amount of public functions than I’ve had in the past. That is because I can’t figure out how to test private methods. One way that I can think of is to create public methods that allow you to test the private ones. Unfortunately, this makes me wonder why the method isn’t public to begin with since it seems redundant and wasteful to have these public methods to access private methods.
Please note the key word methods, property accessors are a different story.
The best solution (I can think of) to testing private methods is Mock Objects. Unfortunately, even though I’ve started to use mocks/doubles more, I’m unsure if my implementation is correct. Until I’m confident in my understanding of mocks/doubles, I worry about having false positives in test results.

Another assertion that was made in the discussion was that private methods allow you to preserve the class’ core functionality.
Unfortunately, no matter what the visibility of the method is, you’re able to override it (and potentially mess with the core functionality you were trying to preserve).
Example:

class foo{
    private function foobar() {
        echo "foo\n";
        return "foo foo\n";
    }
    
    public function bar() {
        echo "w00t ";
        return $this->foobar();
    }
}

class bar extends foo{
    private function foobar() {
        return "bar\n";
    }
    
    public function baz() {
        echo $this->bar();
    }
    
    public function wut() {
        echo $this->foobar();
    }
}

$f=new bar();
$f->baz();
$f->wut();

By running the above code, you get:

w00t foo
foo foo
bar

If preservation of core functionality is your main concern, then you’re better off using final.

So after all that rambling, you’re probably wondering what I’m trying to get to. It still comes down to visibility’s effect on inheritance. The way I see it, unless you declare the method as final, you can’t lock down the parent functionality because private methods can still be overridden. Trying to figure out what level of visibility for a method is a situational call. There is no correct ‘default’ visibility. Sure private is safer because of least privilege but it makes testing a bear (or at least a bear at my current skill level in testing). Public potentially opens you up for abuse or misuse.

What I would still like to know is, how do you do class method visibility? How does that affect your testing methodology? Can someone give me an example (that isn’t a singleton) where private is a better choice over protected? I like protected because it seems less limiting to me and my current coding style appreciates that degree of flexibility.