Free Software/ Open Source Projects

• helps to have a buddy/ally.
• Working for non-profits is a good way to do a pet project. They give you incentive, etc.
• Tell family that you’ll give them some reward when you  complete a project
• Put new ideas in Evernote and go on, then later go thru them and complete them.

SOLID / anti-SOLID

Startups

Javascript

Practicing Progrmming

1. They should be able to talk their craft and, if you’re not a master yourself, they will lose you and go over your head and talk about things you don’t understand. This was from a child’s view, but I interpret it as “They must be able to talk up their craft”.
2. They should be able to create a sample on demand. He was thinking about small crafts when he mentioned it, but when we talked about bigger things (like skyscrapers), we decided a small test problem would suffice.
3. (and this I think is the most important one) They should show you their previous work. They should be able to say, “Look, I created these high quality things in the past, so I can create high quality things for you in the future.”

The book Software Craftsmanship book mentions that to be a master, you must have a masterpiece. To claim that you’re a master, you must be able to show some really good work. So in our discussion of how do you tell a master craftsman, the answer is simple: look at their work.

When you hire an artist (painter, photographer, sculptor, etc.), you look at their portfolio. All artists have one, and it’s how they get work. So, if we’re craftsman, we should have portfolios. Résumés are similar to portfolios, but a) they don’t emphasize actual completed works enough, and b) they’re dry and boring. So maybe we need to start making multimedia portfolios to highlight our abilities as a craftsman. I picture web sites with screen shots, customer testimonials, sample code, links to your blog and other sites, and links to free software or other non-work projects you’ve created.

The key here is, if you want to convince someone that you’re a master craftsman, show them your work and your masterpieces.

Ron “Ziroby” Romero
www.ziroby.com (which has some portfolio elements, but needs to talk about my actual for-pay work)

[cross-posted to the Software Craftmanship list at http://groups.google.com/group/software_craftsmanship/browse_thread/thread/a9a03d96ff298a26 ]

The flow goes like this: One of the coders writes a failing test.  Lately we’ve discussed the proper API in detail during this step.  I think we’re trying to learn the wisdom of proper test structure.

Once the test fails, that person sits down, and someone else goes to the keyboard.  That person solves the test, does any refactoring, and writes a failing test.  Then they pass the keyboard.

It continues like that, with each person doing “Fix it.  Refactor. Break it.  Pass Keyboard”.

We’ve been working in very small groups of about 3-5.  In that size, everyone sees what’s going on and gets a chance to drive.  We don’t have a projector, which isn’t too bad since the groups are small. (But if someone wants to lend us one, it could be useful.)

We allow discussions and suggestions and comments at any time (not just on a green bar), but the rule is “the person at the keyboard is supreme dictator”.  They can choose to ignore everyone else, or go with whatever suggestion they choose.

We’re still working out the bumps, but we seem to have a good system going.  If you’re in Austin and have a Monday evening free, come join us at Genuine Joe’s Coffeehouse from 8 – 10 pm.

I’ve been doing TDD katas and dojos for a while now, and I think I’ve learned the first lesson.  I know the cadence of “break it, fix it, refactor”.  I understand Baby Steps and The Simplest Thing That Could Possible Work.  I get the importance of test choice in guiding the evolution of design.

So what’s my next lesson?  What’s the next thing the katas and dojos can teach me?  Maybe I need to figure out how to test UIs, and how to make testable UIs. The Humble Dialog Box may provide insight and direction there.  A coworker suggested that I need to learn mocks, maybe JMock or RhinoMocks.  I think there’s a kata in there somewhere.  I’ve tried the Publish/Subscribe example from JMock, but that feels too simple, a Hello World of JMock.  What’s a more complex kata that needs mocks to solve?  Or maybe I need to find a way to incorporate Design Patterns into my solutions.  So far I’ve evolved very simple designs, so they haven’t needed Design Patterns.

So what’s the next lesson to learn from code katas?  I know there’s a lesson in there somewhere, and I feel like I’m on the verge of learning it.  What is that lesson?

The order that you come up with the tests really matters.  The tests drive the solution and shape what it will be.  Starting with simple tests (or tests with simple solutions) is crucial, but the order you progress is also important.  There’s a certain art involved here, and I think that’s one of the things we’re learning.

The names of the tests really matter, too.  First, they organize your thoughts when you’re initially writing the tests.  Second, when a test fails, especially one you didn’t expect to fail, the test name should tell exactly what happened.  So, for example, if frobnicatingAnEmptyFoobarShouldThrowAnException fails, you know frobnicate()  isn’t throwing an exception when passed an empty Foobar.

The early phase of a TDD kata is about creating the API.  We tend to spend a lot of time on the API, because it is very important.  For example, at one point we were working with a complex method-driven API, and it was getting complicated, and it felt like we were getting into design.  We switched to a simple string input/output API, and suddenly it was easier to get through those first tests.  Design moved back into the solving-the-test phase.  Those early tests created the API, and we had to get them right to proceed.

The reason we divide tests and solutions is because they are two different domains.  When we are writing the tests, we are working in the problem domain.  What is this program supposed to do?  When we are fixing the tests, we are working in the solution domain.  How is this program going to do it?  Separating the two ensures that you’re not mixing, that you’re not designing in the problem domain, nor defining in the solution domain.

You should envision the eventual architecture of the program, but that’s just a road map.  It’s not where you start, it’s the route you think you’ll take.  And, like a map, once you get out on the road, you might find yourself taking a different approach.

We’re still working on all of this, and learning more and more about TDD and programming in general.  Please, come join us.

Austin Code Dojo
Mondays, 8pm to 10pm
http://groups.google.com/group/austin-code-dojo

Genuine Joe Coffeehouse
2001 W. Anderson Lane
Austin, TX 78757

Computers are much better than humans at some things, like looking ahead a few  moves in chess, or computing odds in poker.  But there are some things computers can’t do, like long term strategies, or deciding if someone’s bluffing, or any of the psychological aspects of the game.  So put them on a team, and each handles the part they’re best at.

In practice, this will work out as a player typing in moves or cards into an analysis engine, reading the probabilities, and selecting a move or bid.  In poker, a computer can compute the exact probability that each player has a winning hand.  It can even compute the maximum amount you’d want to invest in a particular hand.

So then Cyborg Poker Night works like this: Invite over some friends for poker.  Everyone should bring a laptop, and the host should point the guests at some poker engines, so they can install one beforehand.  Then you can use physical cards, or a program like Maptool to deal.  Each person types the cards into the program (or the server broadcasts them).  The programs make recommendations, but ultimately it’s the human who decides what to do.  I think it’s important that, even if you have a game server, everyone should be in the same room, so you can gauge their reactions.

Cyborg Poker could give a better quality of game, with a higher skill level, by taking advantage of the strengths of both a human player and a computer odds engine.  The Cyborg Poker Night would be a lot of fun, and an opportunity to find, develop, and tune poker probability software.  Who’s in?

http://www.youtube.com/watch?v=oXYw-ppevA4

The new moon is the time for beginnings, for starting on a new project, so sprints start the day of the new moon.  The new moon lasts three days, so the beginning activities — sprint kickoff, sprint planning, sizing and estimating, story collection — all take place in those first three days.  By the end of day on the third day, everyone should be working on a task.

The waxing moon is generative, creative.  Most of the work on the sprint takes place during the waxing moon.  The emphasis is on new code, new stories, and new bug fixes.  The team members should be working quickly, taking new stories, working on them, testing them.  These are the activities that normally take the bulk of time in a traditional sprint.

The full moon is the height of power and creativity.  In magick, that’s when the greatest spells are cast.  Expect a greater velocity on these days; if anyone works extra hours, it will most likely be during the full moon.  The full moon is considered to last three days.  At end of those three days, the sprint should be feature complete.

The waning moon is designated for restorative activities.  It’s contemplative and reflective.  Here we complete and polish the work we created during the first half of the sprint.  All stories should be completely tested and any bugs found get fixed during this phase.  Code refactoring and reorganization can occur; documentation should be looked over and completed.  No new features can be added during the waning moon.  The last several days of the waning moon contain completion activities, such as the customer demo, retrospective, and release, and when the waning moon phase ends, the sprint should be “done done”.

The three days before the next new moon are considered the dark of the moon. In magickal thinking, almost no spells should be done during the dark of the moon.  So we take these days as a break from sprint work.  The team can work on tools, or environment issues, or training — activities to enhance their abilities, but no work directly on project.  You could also throw a “sprint is done” party to provide closure to the sprint.

Using the moon as a guide gives an internal structure to the sprint.  The moon phase sprint will follow a natural rhythm, a sort of inhale-exhale, yin-yang structure.  Giving a time to create and a time to reflect makes sure both activities get equal attention, and can create a powerful, sustainable cadence.

A dojo is a coding practice session, an instance of deliberate practice.  We work through a simple coding problem TDD style.  After talking through the problem description, someone writes one failing test.  Then another person gets the keyboard, solves the test, refactors, and writes the next failing test.  Then they pass the keyboard and repeat.

Austin Code Dojo

Monday, June 21, 2010
8pm to 10pm

Genuine Joe Coffeehouse
2001 W. Anderson Lane
Austin, TX 78757

Cost: free, but please buy some drinks and/or food from the Coffeehouse

We don’t have a projector yet, so if someone can borrow one from their work, or if someone owns one, that’d be great.

The analogy goes like this: Memory management is like a car’s transmission. C++ and similar languages are manual transmission. The developer must “shift” by hand, explicitly allocating and freeing memory. Languages like Java and C# manage memory for you, like an automatic transmission. Joel says that there is only one case in regular driving where a manual transmission gives the driver a real advantage. Therefore, one should prefer an automatic transmission and, similarly, a memory managed language.

But there’s something more subtle about it, both with driving and with programming. True, a standard does not give a direct, explicit benefit, but it does provide an indirect value. When I drive a standard I feel more connected to the road, more involved in driving. I have to pay more attention to the engine, to know when to shift. Since I’m paying more attention to the engine, I pay more attention to the road, to the other cars, to driving in general. I am more involved in driving, and that makes me a better driver when I drive a standard.

It’s the same way with programming. If I’m doing memory management myself, I pay more attention to which objects own which other objects, to object lifetimes, to the program in general. Managing my own memory forces me to pay more attention, and that makes me a better developer. Sure, I could let the language handle that for me, but that would let me be a little more detached.

Granted, automatics remove a whole class of errors. You can’t grind the gears, or shift into first on the highway. You can’t leak memory or access freed memory. But those are beginner errors. When you get good, you tend to not do that. And if you do, the car or the program tell you that you messed up. You can’t say that you know how to drive a standard until you stop grinding the gears. And that leads to the next advantage.

You have to be a better programmer to work in a language where you’re responsible for managing your own memory. When a C++ program is written wrong, it dumps core. When a Java program is written wrong, it runs slow. You can write Java that has all sorts if inefficiencies in it, and it works. But to be able to successfully write C++, you have to write it better.

So which should you use? Like everything else, it depends on the task at hand. But I strongly believe that all developers should learn C++ and Java or C#. Just knowing both will make you a better developer. But which is “better” to use? It depends. To paraphrase something that used to be said about C and Lisp, C++ developers think that memory management is too important to be left to the language, and Java and C# developers think memory management is too important to be left to the developer.