BlackBox

Since I’ve done a lot of this over the years, I thought I would share with you my experience in evaluating and picking Open Source projects to use inside closed-source companies. (It may very well be different at companies that Open Source their own stuff – I don’t know.) This isn’t to say that I always pick winners – I’ve definitely been burned. Hopefully, though, my experience will help in making the best decision you can with the information you have at the time.

What should you be looking for when you don’t want to reinvent the wheel and want to use something someone else has done in his or her free time? (Yes, I’m being a bit facetious, as I know that several companies stand behind Open Source projects; however, most of them are still maintained by volunteers.)

• Project inception date – when was this project started?
  • This doesn’t tell you anything on its own, but combined with some of the other criteria below, it can help you. Are they young, un-tried? Or are they old and stable? These two criteria are probably more viable than if the project is old and hasn’t had a release in over a year.
• How many developers?
  • Is there one lone developer working on it? This is a bad sign in general.
  • Does it have 4 or 5 solid developers who are contributing regularly to it? Is there good feedback from the community and other developers? This shows a much healthier project.
• Mailing list size/questions/activity
  • How active is the mailing list? What kinds of questions are being asked on the list? A healthier project will have a lot of questions on a mailing list, with a fair amount being “How do I…?” questions, with timely responses by non-core developers/users.
  • If recent activity has slowed check to see when they last made a software release. If a release hasn’t been made in a while, it’s probably a good idea to move on.
• When did the project last make a software release?
  • If it was more than 6 months ago, check the mailing lists. If those are dead it’s probably a good idea to move on. If they’re still active then take another look, but be wary.
• How frequently do they release?
  • Do they make a release every few months? Do they have a project roadmap (that’s current?)? If neither of these is true, then you might want to be careful in picking this one.
• Is it stable?
  • How long has the project been around? More than a year, with multiple releases? Good. Also look at bug reports. How quickly are they being fixed and released into new versions?
  • Also something to keep in mind: does this project continually change it’s API in the name of progress? If yes, then it isn’t necessarily a good choice for what you want, as upgrading to a new version down the road may be a huge pain.
• What are your needs for the tool/library?
  • Does it have all the hooks or features you need? Or 90%, 80%…?
  • Can you easily modify or extend it to use in your project?
  • Is it language-compatible? Can your developers understand it easily enough, or get up to speed on it quickly?
  • Is the software license compatible with your existing software?
  • What is the cost of support? Do they have any support options available? Are there other companies that support this library/framework? (A yes is a good sign of a healthy ecosystem.)
    • Support can also mean a good, active mailing list
    • Or, support can take the form of training, companies that make money off training for said framework/library can be seen as a good sign (generally speaking, but it can also speak to the complexity of said framework/library)

Do you have any other criteria that you use when you’re choosing an Open Source library or framework? Please share in the comments below!

I decided to try out the Pomodoro Technique after hearing various people mention it (can’t remember who first mentioned it – maybe Peldi from Balsamiq?) and I just recently saw the book announced on Pragmatic Programmers. Last Thursday I finally sat down and read the free PDF book on the Web site (good introduction and gave me all the tools I needed).

Why am I trying out the Pomodoro Technique? (And other GTD techniques I’ve tried)

Before I dive into the how, I want to dive into the why of trying this technique out. I’ve struggled with time management for years; I’ve tried a variety of techniques, including:

• Getting Things Done (GTD)
• Autofocus – all of its current incarnations
• Treadmill Journaling
• Scheduled/Planned Procrastination (I found a lot on this, but not the original comment I found somewhere)

With GTD I had all the folders laid out, I created my giant list. In fact I did this several times in order to try and truly “do” the system. But even all the gadgets, software programs, etc. couldn’t make me want to do the system. It was too much for me, it really was. The system got weedy and I stopped using it.

Then along came the Scheduled Procrastination, where you work on something for 15-20 minutes, take a break for 5 minutes and then do another stretch. This is similar to the Pomodoro Technique, but instead of stopping at 25 minutes if you feel the desire to keep working you keep working. What happens is that after doing a few 15 minute stints you get on a roll with what you’re doing and you don’t want to stop.

Then came the Autofocus system. I’ve been through all the various iterations of the system. With each iteration I was like, “Oh this will work much better than the last one!” (My wife got tired of hearing that one I’m sure.) I used this in conjunction with the Scheduled Procrastination at work (along with a variation of Treadmill Journaling to track my progress on tasks). But old items I didn’t want to touch got shuffled around and still ended up on the back-burner for so long they got neglected.

What are some of the reasons why I am trying to improve my time management skills in the first place? The truth of the matter is I’m a huge procrastinator. There, I admitted it to whole blogosphere. Unfortunately, I don’t feel any better about it. Another reason is to actually finish some of my personal projects. There are a ton of these that I’ve left in my wake that I started and never went back to because they got hard or there was something shinier elsewhere. Both of these aren’t good qualities to have as a software developer, or as a potential startup partner. So, ultimately, I want to get better.

Why will this be any different?

Now, here I am with the Pomodoro Technique. Why do I think this time will be any different? This time I’m going to make a concerted effort to try this. From what I’ve heard it takes at least 30 days to instill a new habit, so I’m starting with the goal of doing this for a full 30 days. Second, and most importantly, I’ve laid out some very specific goals and will be tracking the progress of those goals throughout this experiment.

1. Better management of my time while at work
2. Be more productive at work
3. Minimize distractions at work
   • E-mail
   • Interruptions from co-workers
   • Instant Messages
4. Managing my non-work, non-free time
   • Homework
   • Open Source projects I’m working on/participating in
   • Business ideas/work
5. Unstructured Time – making sure that I have enough unstructured, free time to recharge my mental batteries

What attracts me to the Pomodoro Technique? There are several things I like:

1. Structured and Un-structured time – this concept really appeals to me
2. Focus on one thing until it’s done – Autofocus kept me hopping from one little task after another until they were magically done. The procrastinator in me liked this, but it didn’t work for me at all – stuff never got “finished”.
3. The Pomodoro (time-unit of 25 minutes) cannot be broken – I like this a lot. It really forces you to sit down and focus on one thing (or 2 or 3 little things) to bang them out. So far I feel really accomplished with this.
4. Mini-breaks, followed by a longer break after 4 Pomodoros – this gives me the opportunity to catch up with Twitter, E-mail, IMs, etc. and gives me a nice mental break from the task at hand. This goes hand-in-hand with what I’ve been reading and following (roughly) for a while now. Helps me to recharge a little in-between things, but keeps me on track with finishing stuff.

My implementation of the system

I’ve chosen to implement this using some minor modifications:

• Digital Timer (instead of the ticking analog timer) – For a couple of reasons:
  • It’s a visual reminder of the time I have left.
  • I wouldn’t be able to hear the ticking anyway since I work with headphones on most of the time.
  • It’s a visual and aural reminder to my co-workers that I’m “on a Pomodoro” so please don’t bother me unless it’s urgent. Admittedly, this will take some work, as everyone feels free to interrupt at any time in my workplace (including myself). I’ll be explaining this to them tomorrow when I setup everything.
  • It has a dual-timer function on it so I can set one for my break as well as my Pomodoro.
• For now I’m using the paper templates provided on the site. As I get more used to the system, I’ll be reincorporating it into OmniFocus in some fashion. I’ll detail what I come up with when I do it.
• Excel spreadsheet for tracking progress with specific tasks and Pomodoro compliance.

Being accountable

Over the next few weeks I’ll be putting up a weekly recap on this (going to shoot for Sundays to keep this to a schedule). I’ll post up some of my Pomodoro pages and some of my tracking results as well to keep myself honest and let others see how they can work with the system. If you haven’t already, download the book (or buy the Pragmatic Programmer book – “Pomodoro Technique Illustrated“), get a timer (I personally like the idea of something physical I have to work with, but there are several apps/widgets that will do this for you too) and get back to work!

If you’ve tried Pomodoro in the past, I’d love to hear your impressions on it in the comments below!

This post was inspired by “The 7 signs your UI was created by a programmer” post on Voyce.com.

1. Your Web UI consists solely of CRUD (Create, Read, Update, Delete) screens – no matter how complex the user interaction is, it can always be boiled down to CRUD. Right?
2. Everything is in Times New Roman – who needs a nice-looking font anyway?
3. Everything is using the latest JavaScript library with UI functionality – what do you mean not everyone is running the latest FireFox beta?
4. It uses tables for layout. Everywhere. Because CSS sucks to debug (on top of that, “Screw the Semantic Web!”).
5. The form fields validate, they just don’t have any errors next to them when they fail – because the user should know what they did wrong.
6. And forms themselves go on and on and on …

I could only come up with 6, but I’m sure there are many more. Add your favorites in the comments below!

I’m also hoping to turn this into a somewhat regular series on Web Developers and tips and tricks for designing usable, non-ugly interfaces. If you have any tips, let me know in the comments and I’ll be sure to credit you.

Well, crazy or not I actually (somehow) convinced someone to help me out. And boy did he help! I got some of the basics going and then Cory took off with them. He’s put a lot into this plugin and for that I wanted to publicly thank him.

Now, onto the nitty-gritty. This is an alpha release, so it’s still missing some features (mainly object inheritance and any kind of relational mapping right now). Basically what you can do is to create an object and save it in a CouchDB database. We have some configuration options and some other cool things that you can try out like loading/reloading of views in your database.

Here are some of the basics of what you can do with the gorm-couchdb plugin

• Save a class as a CouchDB document
• Specify the type of document you want to save (special field in the database)
• Save attachments with a document
• Specify a custom id an version field to use for your class/document
• Load and reload .js views directly into your database when they change

There is a short how-to on the wiki. To install it you can just do a

grails install-plugin gorm-couchdb

or download from the Grails Web site.

We’ve switched the main repo over to Cory’s since he’s been doing most of the work at this point and I’ve shifted into more of a project management role. I’ll get to down to some more development of features I really want (like composite keys) in the near future.

For bugs, please use the one on Github, we will be doing all of our release planning over on PivotalTracker. We haven’t setup a separate mailing list but both of us are on the grails user and dev lists. If you would like to become more involved contact either of us through the Github system.

Finally, if you are developing a different NoSql grails plugin we want to talk to you. Primarily we want to see if we can coordinate our efforts and if there’s any common ground we can agree on so that we aren’t all reinventing the wheel.