I’ve been trying for years to find the ‘one true way’ to capture all my todos and notes and stuff. I’ve tried a few systems that worked fairly well, but there were always some catches.

Using a Hipster PDA, I had to make sure I had it with me. I had to remember to pack it. It didn’t handle long notes, nor electronic notes.

I’ve used Things by cultured code. It’s great, because I always have my iPhone in my hand. It syncs with my Mac and my iPad. It has recurrence, long notes, and notifications. It is great. But it misses out because I can’t use it on my computer at work. Out of sight, out of mind.

I tried TaskPaper from HogBay software shortly after getting my first Mac. It was really cool, because it used a plain text file that is human readable and stupid easy to parse. I’ve even used it as an example in a DSL talk I once gave. I could use the same todo file both at work and at home. But I had to carry that file around on a thumb drive.

Until I came to a recent revelation. There is a TaskPaper for iOS that syncs to Dropbox. I use Dropbox. Taskpaper’s file format already has a Vim plugin at work. It works with task paper on my home Mac. It works on my phone and iPad. It is simple and easy to use. And flexible enough for just about anything.

Just for fun, here are some Taskpaper vim commands. And so I can find them again.

\td – Toggle Done – @done(2012-1-24)
\tx – Toggle Canceled – @cancelled(2012-1-24)
\tc – Show Context
\ta – Show All
\tp – Fold All Projects

What are the next steps?

• It doesn’t give me reminder, so I need a helper app to find things due today and alert me. It’s easy to parse and just needs a command line app run by the OS scheduler that sends an email with today’s agenda.
• It needs to quickly open my dropbox file and a work only file that doesn’t sync over Dropbox (google Export Controlled). This will most likely just be a shortcut on my desktop to vim and two files.
• Vim isn’t the prettiest user interface, so I may get sucked back in to some side project WPF development.

I’ve only been doing this for, like, a day. Let’s see how it goes!

Here are some questions to ask yourself about common organizational behavior.

• Rules are there for you. Does everyone help others in the organization achieve through proper channels? Short-cuts lead to bad mistakes.
• Passion is of utmost importance. Do people make time to share how the current task at hand effects them personally? Do they feel safe communicating their agreement even after a decision has been made?
• Two heads are better than one. Are simple decisions still taken as an opportunity to get input and feedback from others? Ideally from five or more people?
• It’s all interconnected Do we cross-check the impact on even the most seemingly unimportant and tangential issues? Complex systems have complex interactions.
• The devil is in the details. Are words in minutes, resolutions, mission statements, requirements, etc chosen carefully? Are they discussed until no other possible meaning can be accidentally read from them?
• The world is constantly changing Are old issues contantly being reviewed for their fitness in a rapidly changing world? Even matters decided in the last meeting can be cast in new light by the speed of modern change.
• Failure is not an option. Mistakes can be costly and lose people their jobs. Are people constantly reminding each other to be cautious and reasonable? Success may fade, but bad PR lives forever.
• There is no vacuum. Are people aware of the overarching goals of the organization? Is there discussion of whether your group is the appropriate source for this decision, or should it be elevated to those with a beter strategic understanding of the organization’s goals?

I’ve been thinking about this because I heard a song shuffle up on my iPod, but also because I’ve been discussing how organizations function with several folks in and around the Indy tech community. And some in other fields. And some discussing politics.

The list uses golf scoring, by the way. One or two isn’t bad. But If you’ve managed to score a perfect eight, your organization may be its own worst enemy. Wait, why am I saying that? Because those eight checkpoints are variants of an eight step list of how to sabotage an organization. Brought to you by the OSS (Office of Strategic Service), the precursor to the CIA, this list was developed to help occupied French and other nationalities slow the progress of the Axis war machine durring WWII. And no, I’m not the first to see this. See page 28 for the details.

There is a balance to be struck. But remember, the process that keeps you from making a decision and doing work is a process that is killing your organization.

This week’s blog battle has begun!

We, those of us who fancy ourselves serious developers, like to disparage the enterprise developer who specializes in a class of application called Forms Over Data. The Business needs to save some data, so they have the DBA lay out a table. The developer then points their IDE at the table and drags input element on to the form and bind columns to text boxes and BAM!, they are done. System.DraggyDroppy. It doesn’t scale to Real Development. Not when I have a rich set of domain objects.

When I started full-on professional development, the summer before my senior year, I wrote web pages. Each page was a thin veneer over the database. Until I had to add more logic and added a bunch of ifs and elses in to the page. The fact remains, the data I was manipulating was pretty anemic. I’ll call this Pages Over Data. The difference is I have an implicit Fat Controller in my CGI script that the forms over data didn’t.

As I’ve done more desktop and mobile development, I’m starting to see that I’ve just done the same damn thing. Over and Over. It’s how I’ve always done it.

Recently, I have heard several people talk about software architecture. James Coplein has been promoting DCI. At work a few of us have been thinking about rereading Eric Evan’s Domain Driven Design. Despite none of these texts exploring a new idea, despite none of these ideas being things I heartily agree with, despite having evangelized and touted these ideas; I’m not very good at it. I keep finding myself doing pages over data.

What am I seeing? In one case, we had to stand up a bunch of screens for a user study so we’ve stuck a bunch of logic in Android Activity classes. While we’ve been refactoring this out, the odds are good we will always have some of that sticking around. In another case, we had a “business layer” that another team managed and UI designed a screen at a time. Our ViewModels had a lot of logic that we decided didn’t belong in the BL as that was a representation of only the data to be saved in the file and enough logic to ensure consistency and validity and undoing edits.

I can’t put my finger on WHY I don’t like these things, but I don’t. I’m on a quest to overcome the architectural momentum I’ve developed. Here’s what I’m going to do about it. I’m reading a bunch of architecture stuff. Reading along is only so good, so I’m writing a pet project a few times to explore each architectural style I’m working with. Hopefully, this will give me a better understanding of what I’m feeling and how well these styles work for me. So the next time I’m done with a project I don’t look back and say, “it’s just Pages over Data.”

This weeks Blog Battle was a song title. Just to make a point, here’s a video!

When I has a young software engineer, I was a Perl hacker. I could do amazing things because I spent so much time learning the ins and outs of the language. I blame, in part, Dave Mott for showing me what was possible. But also people like Damian Conway for things like Lingua::Romana::Perligata, a library that allowed you to write code with Latin grammar rules, because they showed me how to make the world a slightly crazy place with their code. And to enjoy code for its own sake.

I used Perl, not only in direct project work, but to slice and manipulate any data I had to deal with. I didn’t have a machine without it installed. At least is was not long until it was installed. When I did use it, odds were I would write code that others would call messy and dangerous. Calling methods that don’t exist. Rewriting the symbol table for just a little while. Writing code that changes file without opening them. It was there I learned that it can be easy to solve problems with a dash of black magic.

I started learning Ruby because all the cool kids were doing it. I’d heard about Rails, and I had seen it mentioned in both the Pragmatic Programmer and Extreme Programming Adventures in C#. I stayed for a while because of things like Rake, rSpec, and people like Why the Lucky Stiff, who, like Damian Conway, made the world a little stranger and a little nicer.

I explored “block” and finally understood what all that crap I was doing in Perl was now that “metaprogramming” had a name. Wrote my first internal DSL because I hated the language I was targeting. I learned that code needs to be ‘ergonomic’ and easy to understand. I still used magic, but I kept it in a corner of the code.

The weapons I’ve been looking at recently are mot because they are inherently useful to me, but because they make me think differently. Haskell, Erlang, Clojure, and F# are not things I can as immediately push in to a project, but they teach me about the form and movement of their usage. You see, C# is no longer as pure an OO language as version one was. You can make an argument that it never was pure, but it is taking so much more from other language paradigms because of people like Erik Meijer. And they have helped me write very different C# that is more expressive and succinct than anything I would have been able four years ago.

But what serves me best? In each case, I try to understand the language for what it is, not for what is is expected to be. Each feature should be approached with the beginners mind and explored from several angles. Each is different and can be used in a variety of ways. A master swordsman can strike with any part of the sword.

As I get older I realize my weapon of choice is not any specific language. I have favorites and some I understand better than others. Those are matters of fashion and taste. A master swordsman understand the sword so well, he can turn any object in his hand in to a weapon.

That’s my weapon of choice; what ever is close at hand.

A colleague bemoaned how Project Euler was far too mathy and not at all practical. He felt there needed to be a more useful version, like display a number of items on a web page. I mentioned that this sounded like a koan.

Koans? What are They?

Koans were first put together by EdgeCase as a series of exercises that used a test framework and heavily commented code to teach Ruby. They cover several topics; array manipulation, functions, exceptions, classes, etc. Many other language evangelists have attempted to use the Koan format to teach there favorite language. And for this, they are very well suited.

I loved the Ruby Koans. I enjoyed the Haskell Koans. However as far as they go teaching you how to use a real framework to do real work, they were anemic. But I still think there are some great things to learn from them. Especially if I want to teach some frameworks.

So, what are the principles if Koans and how can they be used to teach long-form ideas? And can I pick on an existing set of koans as either good or bad examples? Can I back up what I was talking about with real code?

Principles of Koans

Koans run quickly. They run until they find the next lesson, usually a broken test. There test errors should give you a file name and a line number. The lines near the error are filled with comments explaining what you need to know to make the next test pass.

Koans lead you down the path. Each step builds on what you’ve learned and adds a new twist. While they break in to larger topics in each file, then slowly build out the knowledge of that test.

Koans I’ve run, the good and the bad.

Speedy turn around is where the Haskell koans fell flat for me. First off, I had to compile several files before I found out if my solutions were correct. They weren’t, but I had to use the number of trues an falses output and the number of assertions made to figure out where I had made my mistake. I got it wrong, and you’re not helping! I would drop the Literate Haskell file type and just use the runhaskell command to fail the first file before the next even gets compiled.

One of the things I liked about the ruby koans was their simulation of TDD to guide the completion of a project. Yeah, it was a simple project, but still. It was me writing actual code to do actual work. It spiced up the exercise and was a nice island of diversion on the ‘path to enlightenment.’

Halfway There

I taught WPF for a company class. The project I had them work on was an iTunes clone. Each week I’d ask for them to get a little bit more done. Each week, I’d put a little more business logic up for them to use in their app. But I don’t scale. Don’t get me wrong, I’m not the best WPF guy in the world. I might even be average. But I want to share what I know.

What keeps my project from being a Koan is a lack if automated tests. If I had some test failures mixed in that would guide them to success, then we’d have a winner. But I couldn’t use plain old NUnit to handle it. I’d need to deal with leading them in steps to writing code that I can eventually compile against. It is possible that the C# 5 compiler as a service will help smooth this out some for my WPF example, but reflection can help. As for Matt’s world, odds are he will get this for free by using a dynamic language like Python or JavaScript.

A successful take on this was the Rails for Zombies project. So what Matt Swanson and I are proposing isn’t anything new. It just takes time and planning, trying to make everything build out in an order that allows learning and several small projects to actually live and breath.

I’m not sure I’m sure where to go with with this week’s blog battle, Engineering Over/Under. But, a deal is a deal, and I’m still posting more than Moseng! By the way, this post has no answers, just some ravings.

I participated in the Science Olympiad when I was in high school. I did well in two competitions, orienteering and clock building. The other task I had but didn’t do so well in was bridge/tower building. I’m sure my bridge would have been the most efficient, but for safety reasons there was a limit to how much weight they would put on my bridge. The bridge was over engineered. In order to win, you need the most efficient bridge that will fail. If it stands, there were inefficiencies in the system.

There isn’t much to that story that has to do with software. Over engineering is about costing too much for the job at hand.

The truth is what we call over engineering in software is about picking the wrong things to build. It isn’t over engineering to put a ferris wheel on a bridge, it’s just wrong. But to build N-tier web services when all you need it to catch responses from an employee survey? We call that over engineering for some reason. No one complains if you make it too fast. But these additions to our software take more time and money and often make your software worse.

So what do we do about this? Focus on what you really need to build. Try not to get caught up with arbitrary requirements about how this needs to be web-scale or have zero latency. Now, the trick is balance. These are valid concerns that may be important, so you can’t paint yourself in to a corner where you can’t easily address them in the future.

Wait, what? Not make it right the first time? When architecting a real building, it is possible to design a building with rooms and features so specific to a certain layout that you can only use those spaces in specific ways. The obvious examples are bathrooms and kitchens (I’ve been thinking about a remodel for a few years), but auditoriums are also problems. The real treasure in building architecture is making flexible spaces that can be used for many purposes and occasions. Have you ever really looked at a great museum’s architecture? The galleries can usually be reconfigured in very short order to accommodate new collections or events.

In software, we like to try to keep our business logic free of our persistence or display technologies, just like rows of theater seats and a stage make it hard to repurpose a room. Some times the Smart Forms pattern is actually the answer. And sometimes it may be okay to do a little work in the UI thread.

Once again the gauntlet has been thrown. I have taken up arms and the Sep blog battle has been joined. Because I’m a better person than you.

That is a common refrain around my office, “because I’m a better person that you.” Okay, I’ll fess up. It is actually just me and it’s not that often. It is also all a lie. I’m not better. I am actually a recovering fraud hiding behind my insecurity.

There is an a branch of theology that essentially states nothing you do matters, salvation comes to an elect few through no action of their own. This was practiced by the lay members of the early American churches as, “If you got away with it then God loves you. If your crop die or you lose your job you are evil.” This is less innocuously practiced today with phrases like, “I can’t draw. I’m not talented.” Or, worse, “I don’t care, I live a charmed life and can do what ever I want.” It is, in my mind, a cop-out. It means free-will is suborned to some other will. It means my choices are pointless and I may as well just sit on the couch and count flowers on the wall.

When this hit me professionally I had just had a contentious run with a project lead and felt exiled when I moved to my next project. I looked around at the situation and made a discovery, several of the people I graduated with had accelerated their career and I had stalled mine. Some of this was an accident of our exposure, but some what about realizing what’s important. I realized that I was focusing in the wrong things. I changed my focus and got back on track. I now know I was the perfect fit for that exile and I learned awesome perspectives there. I would do it again for the first time.

I can’t promise you that you will be the best, but I can promise you that you can be your best and do things you never thought possible. When studying the luminaries of our industry, most of them have worked hard to be able to do the things that have changed our world, but I’m not sure they are that different from us. Anyone can write a database engine. Anyone can write a programming language. Now, making it good requires effort. And achieving awesome means you stop telling yourself you can’t and never will. At a more personal level I know what keeps me from being a better artist. I don’t draw enough.

So the next time someone notices the fruit roll up in your lunch and expresses envy, let them know the only reason you have it and not them is that you did the work of putting it there in the first place. You know, “because I’m a better person than you.”

So, why do I strive to get better? The choices I make matter and I use those choices to make a better relationship, a better home, a better career, have better fun, and build a better me. I get better so that one day I can say, without a trace of irony, “Because I’m a better person than I was yesterday.”

For a while, I’ve been putting some git repos on a thumb drive. It is a practice I have evangelized around the office and it caught some traction, so I figured now is the time to really explore it.

Why? As a developer, I use source control. As a responsible developer, I should use source control even on my crappy little projects and utilities. Since I code both at home and at work, I’d like access to my code in both places. Also, it is damn handy to have a backup.

Why not just use github? At my current level of use, paying for git hosting doesn’t gain me anything. Using github’s free services require that I expose all my code. I like open source, but there is a time and place for NOT opening your source. For example, if you are writing an rpg app that uses material copy written by Wizards of the Coast, it is best to keep that for personal use. It may also be far too early to release because the idea is half baked at best.

Okay, what’s the workflow? How does this work? I pull from the thumb drive, check out what ever branch I want to work on, do stuff, commit locally, and then push to the thumb drive.

Here’s how:

1. create a git repo in your project’s working directory
   git init . && git add . && git commit -m "initial commit"
2. create a bare repository on your drive
   f:\ && git init --bare myproj.git
3. let your local repository know about the thumb drive
   c: && git remote add thumb f:\myproj.git
4. push to the thumb drive.
   git push thumb master
5. (optional) install portable git on your thumb drive.

I can tell when the gauntlet has been thrown down. This is part of the SEP Blog Battle.

Shortly after I started dating Sally, I took her out to dinner for her birthday. I said she could go wherever she wanted. She wanted to go to Applebee’s. Really? Are you sure? I meant where ever, even St. Elmo’s. Okay, Applebee’s it is.

We have eaten at Applebee’s often since, and while it is comfy and familiar, I have a theory that their cooks aren’t actually cooks. Okay, that’s kinda snotty. Their cooks aren’t chefs. They are line cooks that mix frozen and prepared meals until warm and tasty. I kinda see them as a slightly more professional version of me dumping a frozen bag of ‘dinner for two’. It’s the little things like, “we are out of the mozzarella sticks,” or, “we will only have the pecan chicken salad until we run out of what’s in the freezer,” or the fact the food never looks like it does in the picture (the menu has pictures?). This style of cooking lacks creativity. There is no room for interpretation. In a either a small family place, or a high end restauraunt, the chef can alter the menue based on what’s in season. By the way, have you ever noticed that the seasonal veggies are always broccoli and squash in places like Applebee’s?

Now, let’s take a look at fortune 500 IT departments. Some of the fourtune 500 have advanced tech groups doing amazing custom things to change the world. Those aren’t the IT staff I’m talking about. I’m talking about the guy who was asked to write a quick desktop app to let catering know who’s flying today and this week and what they need to have stocked in the galley. that’s the guy who knows how to wire a web service to a data grid and call it a day.

That’s not why I’m here. People come to SEP to make a solution tailored to their needs. You come to SEP because your in-house IT would make your application show up on the programmer version of There, I Fixed It. I may use off the shelf components, but you want me adding a dash here and there because, quite frankly, I know this “kitchen” better than you and THAT is why you came to see us and not your own IT staff for this development project.

I love to cook and bake. Often, it is how I get exactly what I want. I also eat at a lot of chains, fast and casual dining both. But I adore the chance to eat food prepared with care by someone with an opinion. In software, that is why I’m here. For food near Indy, may I recommend the following; Zest, St Elmo’s, la Mie Emilie, Bazbeaux’s, Yats, The Loft at Trader’s Point, Pizzology, and Bub’s.

It seems some of my esteemed colleagues decided to have a “Blogging” contest. They have, therefore, pressured me in to posting a couple of blog entries. I hates them so.

I’m a regular at the Indianapolis Code and Coffee. If you’re local, join us at 7:00 am on Thursday! Korff and I started doing some Project Euler problems in Haskell this week. Matt Swanson made a comment about Euler being way focused on math and wanting Project Euler for “practical” things. His idea of practical was, as an example, displaying a list of items on a web page. Hrm… Reminds me of Ruby Koans or Rails for Zombies. I’ll get to that post in a few days.

I’ve done some of the Euler problems and they are really math oriented. The point of these exercises really is to think about math and the relationship of numbers. What a programmer can take from these exercises is focusing on algorithmic implementation and optimization. It is not that we solve it, but that we tweak and re tweak our implementation to be faster or more expressive. It is a great way to learn about a programming language in the small.

Koans are small guided steps. Where Project Euler expects a single number as an answer with out regard to HOW you got the answer, koans are all about the journey. They are usually language specific. They are a series of automated test failures that allow a conversation of learning similar to The Little Schemer. Again, koans are about learning small concepts a little at a time.

Katas are also about the journey. The problems that katas use are actually incidental. It isn’t important that I’m dealing with an incomplete simulation of a bowling game, or pricing some children’s books. It is about the things you do around the problem. Katas are about the red/green/refactor cycle.

All of these have their place and appeal to different people for different reasons. But they deal with software in the small. Like writing short stories, they teach you how to communicate more effectively. These lessons can be taken to larger structures, but they can also teach a kind of tunnel vision. A short story is not a novel and their structures are different. With that caveat out of the way, enjoy yourself. If you’re pressed for time, they can be great bite-sized puzzlers and exercises. They can also teach you to take care with the smallest parts of your code.