Gorm-couchdb grails plugin release 0.3 1

Posted by Warner Onstine on November 16, 2009

We actually released this to the Grails plugin repository last week but haven’t had time to blog about this release. There’s a lot of good stuff in this release, some bug fixes and some new features.

Before we dive into the new features there is a short how-to on the wiki. To install the plugin you can just do a

grails install-plugin gorm-couchdb

or download from the Grails Web site.

New Features

Domain objects now assume that there is a design document with the same name as the @CouchEntity type:


@CouchEntity
Customer {
    ...
 }

This will then map to a design document named customer. So a call to Customer.queryView("byName") is the same as Customer.queryView("customer/byName").

Added count() and list() methods that call the count and list view of the domain design document. You can optionally specify the view as the first parameter, e.g. Customer.list("byName"). Also, both methods take the options parameter, so default scaffolding code like the following works:


def list = {
    params.max = Math.min(params.max ? params.max.toInteger() : 10, 100)
    [tripInstanceList: Trip.list(params), tripInstanceTotal: Trip.count()]
}

Added dynamic finders support for list, find, and count methods that take the view name from the method. Instead of calling Customers.list("byName") you can now call Customers.listByName(). The list and count methods only accept options as parameters, for example Customers.listByName(params). The dynamic finder methods assume that the keys are passed first and that the last parameter of type Map contains any options, e.g., Customers.findByName("John Smith", "John Doe", params) will query the customers/byName view for keys that equal “John Smith” or “John Doe”.

The methods findByView() and findByViewAndKeys() were renamed to queryByView() and queryByViewAndKeys() to avoid any potential conflicts.

Added a “typeFieldName” parameter to the @CouchEntity annotation that specifies the name of the type field stored in the JSON document (and CouchDB database).

Added automatic type conversion on list, find, and query results if the name is the same as a field of the domain model. A field like lastUpdated will get returned as a Date object instead of a string that you would have to convert.

Added support for @Transient annotation on transient fields. This is in addition to the already present GORM “transient” support. This also works on “read-only” fields, i.e., bean properties with a getter but no setter.

The plugin now uses jcouchdb’s svenson library for JSON generation and parsing. This gives us a slight performance boost, but more importantly, keeps us inline with future jcouchdb changes and enhancements.

Added a toJSON() method to domain objects that returns a JSON version of the domain object. Note that this could be very different from the one returned by Groovy’s JSON as id becomes _id and version becomes _rev along with other changes.

Bug Fixes

  • Now correctly read attachment’s metadata
  • Now remove the automatically injected id and version properties, and rewrite the toString() method to use the right fields
  • Now allow spaces in id values for bulk operations
  • Can now store unicode data in any field (including id fields)

What’s next?

Right now we think we have a fairly stable plugin that we have started using in actual projects and will be improving this as we run into any issues. For me, the first thing will probably be compound key support, where something like project_myProjectName as the id value of my document instead of a generated value. Above and beyond that, handling object relationships is pretty high up there – we’re just trying to figure out the best way to do it.

Our main repository is on Cory’s Github since he’s been doing most of the work at this point and I’ve shifted into more of a project management role.

For bugs, please submit any issues to the bug tracker on Github. New feature and release planning will be 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. 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.

Related Posts:

30 Day Experiment with Pomodoro: Week 2 5

Posted by Warner Onstine on November 08, 2009

Ok, here is week 2 as promised of my “30 Day Experiment with Pomodoro” (Part 1 – Why I’m doing thisPart 2 – Week 1 recap). This covers Friday, Oct. 30th – Thursday, Nov. 5th. First, I want to say that I am really enjoying Pomodoro, because I feel like I am actually getting more done before than I was when I wasn’t using Pomodoro. And I now have a much better feel for when I should be getting task at hand done instead of just surfing, checking email, etc. On a side note, I’m surprised that no one around me has said they want to strangle me because of the beeping kitchen timer (although, someone did tell me to get back to work when my 5 minute break was over). I’m glad I decided to keep using the timer and it helps to keep me on track and aware of how much time I’m spending on things – 5 minutes goes so fast!

Week 2 Scheduled and Unscheduled Pomodoros with Completed Tasks

Week 2 Scheduled and Unscheduled Pomodoros with Completed Tasks

The first graph is again my scheduled, unscheduled and completed tasks. For this week there were a few instances where the unscheduled tasks equaled or outnumbered the planned tasks. I need to figure out a good way to work with a group of people on a project using Pomodoro – that’s my major sticking point right now. It works really well when two of us are doing pair programming, but starts to fall apart when there’s frequent questions one of us has for the other and we’re not working together.

Week 2 Pomodoros Internal and External Interruptions

Week 2 Pomodoros Internal and External Interruptions

The second graph tracks my interruptions. This week I added in a new metric to track – Interrupted Pomodoros, for when a Pomodoro has been completely broken by interruptions (either internal or external). In this graph it is easy to see the correlation between external interruptions and broken Pomodoros. This week was a bad one for external interruptions – mostly calls from higher ups wanting to know the status of things that I was working on.

I’m also going to do a little time-comparison here, so I’m including two graphs showing the past two weeks together for each graph to better see how things compare.

Combined Scheduled and Unscheduled Pomodoros with Completed Tasks

Combined Scheduled and Unscheduled Pomodoros with Completed Tasks

Combined Pomodoros Internal and External Interruptions

Combined Pomodoros Internal and External Interruptions

Now, here’s a recap of last week’s goals and how I’m doing on them:

  • Integration with OmniFocus. I think I’ve worked out a good way of using this with OmniFocus which I’ll detail shortly.
  • Improve my average daily Pomodoro count. This one actually went down a little bit from 7.29 to 6.86. So, I’ve stayed roughly the same (at 7 Pomodoros/day). I have improved on handling interruptions (despite the increase in “broken” Pomodoros), but this one still needs some work.
  • Decrease my interruption rate. I am definitely improving on my internal interruptions, and I’ll try to keep my external interruptions to only the most urgent.

For next week I want to accomplish the following:

  • Improve my average daily Pomodoro count. I’d like to increase my average completed Pomodoros to 8 for next week, so I have some work to do to make sure that happens.
  • Finish integrating Pomodoro with my task system. One thing I’m still not happy about is the extra paper for the daily To do list, but I still need something to help me track my completed Pomodoros. What I think I’m going to try is to use my little LiveScribe flip notepad to keep track of this. This gives me two benefits: first, it’s contained in one notebook; second, I can digitize and keep my notes forever.
  • Finish cleaning up OmniFocus. I still have some stuff floating around in OmniFocus that’s duplicated, but I know have two primary lists: Backlog (taken from AutoFocus) and To Do Today. Other things are ideas that I want to work on, so they’re broken out by project and I move them off of there when I’m ready to work on them.

I mentioned I was going to talk about how I’m using OmniFocus with Pomodoro, didn’t I? The basis for this integration is right above. I have one project called AutoFocus, which I’m going to keep. In there I have three other projects called For Review, Backlog, and To Do Today. The For Review project has items that have become stale and I need to review. This is an artifact of AutoFocus and I will be cleaning this as I go through all of my tasks.

Here’s my daily routine:

  1. Do one Pomodoro on my Morning Pages. I write on stuff that happened the previous day, things that I want to mull over on paper, things that I want to accomplish that week/weekend or things I want to do that day.
  2. Break out a fresh To Do Today page and Yesterday’s To Do page. I then look over any planned or unplanned Pomodoros that didn’t get finished the previous day to see if they need to be moved over to today’s list, moving them either to Backlog or To Do Today. As I do this, I make sure to estimate the number of Pomodoros it will take to complete each task. If I’ve already done some work on one of these tasks, I make sure to note it in the side margins.
  3. Look over my Backlog. I check to see if there are items I want to get done today and move those to To Do Today, making sure they have estimates attached to them.
  4. Review my Backlog. I review it again to make sure there isn’t anything I’m missing. If I wrote anything in my Morning Pages, I make sure to note in either Backlog or To Do Today with a time estimate.
  5. Errands. I put these after regular tasks that I can time-box. I don’t give these estimates, as they won’t be counted in my Pomodoro count. If there’s a better way, someone tell me in the comments below!
  6. Sync with OmniFocus. The last step I take is to synchronize my OmniFocus file so that any tasks I finished are marked off and any new ones are entered. Then I sync OmniFocus on my iPhone so that that’s ready as well.

That’s about it. Would love to hear others’ thoughts on Pomodoro in the comments below!

Related Posts:

30 Day Experiment With Pomodoro: Week 1 7

Posted by Warner Onstine on November 01, 2009

I promised I’d update everyone with my progress using the Pomodoro Technique, so here it is. This reporting covers the period from last Friday, Oct. 23rd, to Thursday, Oct. 29th. It’s hard for me to see any patterns yet as it’s only been a week, but I’m posting up my two graphs for analysis.

Scheduled and Unscheduled Pomodoros with Completed Tasks

Scheduled and Unscheduled Pomodoros with Completed Tasks

The first graph is comprised of my scheduled, unscheduled, completed Pomodoros, and completed tasks (tasks that I finished with a set of Pomodoros). You can see here on days 3 and 4 I got a little overambitious with how many Pomodoros I would complete, but you can also see on those days my completed Pomodoros went way up as well. Not sure if there is a correlation there yet or not.

Pomodoros Internal and External Interruptions

Pomodoros Internal and External Interruptions

The next graph is my tracking of internal and external interruptions. As you can see, I’m still working on controlling my interruptions during a given Pomodoro.

Now, this week was a bit of an oddity because most of my co-workers were out sick at one point or another during the week, so I was able to concentrate (when at work) a lot better. Next week will be the real challenge, but I do feel better having gotten into the groove of it, so maybe next week will be ok.

There are some items that I’m tracking that I’m not sure what to do with yet:

  • Estimate vs. Actual Pomodoros per task – I have several tasks that I’ve completed and marked how many Pomodoros it actually took me to complete. Not sure if I should be putting this into a spreadsheet and if so, how should I track it?
  • Combined tasks – I mark tasks that I’ve combined into one Pomodoro, but again I’m not sure if I should do anything with it.

My goals for next week are:

  • Start figuring out how to integrate this technique with OmniFocus and some general task management. This is going to have to happen soon, as I have too many papers floating around right now. But I need to figure out how I’m going to track interruptions, scheduled, unscheduled and completed Pomodoros, etc.
  • Improve my average daily Pomodoro count. The max I can do in any one day is 20 (during the week), and probably closer to 24 – 26 for a weekend (if all I did was work, which I won’t do). My max count for the highest day was 13 completed Pomodoros. My average Pomodoro count for the week came to 7.29 or roughly 7 completed Pomodoros a day (3 1/2 hours of sit-down, concentrated work). I’d like to see if I can get that average up to about 10 Pomodoros a day for the week.
  • Improve my interruption rate. I can easily control my internal interruptions I just need to get a handle on it and write down all the little things I want to work on so that I don’t distract myself during the current Pomodoro. External interruptions I am still working on handling. We’ll see how next week goes.

A few final notes on integrating the Pomodoro Technique with my life (and other task management):

When I’m working on code stuff, I eventually do get to the point of attempting to build it on our build server. This can easily take more time than the length of one Pomodoro. But I hate to break the groove and go work on something else that will take more than one Pomodoro. And of course if the build fails, I need to figure out what caused the breakage, fix it and attempt to build again (another delay). One thought I had for taking up the rest of the remaining Pomodoro was a quick code review, but I’m not sure how far I should carry that. Or should I keep a list of quick tasks (that I can complete in one to two Pomodoros) that aren’t time-sensitive I could do while code is building and I’m waiting?

Second, how do you handle tracking things like errands using the Pomodoro Technique? Or do you? I’m thinking that Pomodoros are best when you need to either sit down and do something at your desk or at home (like cleaning, organizing, etc.) and not for running errands or shopping. It feels like a system for managing a set amount of time working on something within another system, perhaps.

Again, if you’ve tried Pomodoro in the past, I’d love to hear your impressions on it in the comments below! Especially if you’re a programmer – I’m very curious to see how other programmers have used this system.

Related Posts:

Writing Tips for PragProWriMo

Posted by Warner Onstine on November 01, 2009

First we had NaNoWriMo (National Novel Writing Month), then NaNoDrawMo (National Novel Drawing Month), now we have PragProWriMo (Writing a Tech Book for the month of November – named after Pragmatic Programmers, a tech publisher).

So, I thought I’d share a few writing tips for those of you attempting to write a tech book this month. There are also some great tools out there that you might not be aware of. I’m not familiar with all of them, but I’ve provided links and reviews for you to make your own decision.

Tools

(Apologies in advance, I’m a Mac person so most of these tools are for Mac people – sound off in the comments for other platform-specific tools you use.)

  1. Scrivener – I like this app a lot so far, because it’s great for collecting bits and pieces together and organizing your thoughts into chapters as you write. Here’s a longer review of it. You get a 30-day evaluation license (and I mean 30 days of writing, not from when you open the application). (Special deal for NaNoWriMo participants.)
  2. Storyist – This is one I would like to try, and I’m glad they’re going with the 30-day evaluation license as well (not sure if it’s like Scrivener’s 30 days of use license or not). Here’s a review of it. (Special deal for NaNoWriMo participants.)
  3. StoryMill – I’m not very familiar with this tool, but a here’s a review. (Special deal for NaNoWriMo participants.)
  4. UlyssesHere’s a review of it. (Special deal for NaNoWriMo participants.)
  5. Nisus Writer Express (or Nisus Writer Pro) – Here’s a review of Express.
  6. CopywriteHere’s a review.
  7. WriteRoom – This is a bare bones “just write it” editor. Nice to take away all the distractions and focus on writing.
  8. TextMate – This, combined with some of its plugins make this a very good tool for writing a tech book.
  9. Pagehand – This looks like a very interesting Word Processor. Not sure if I’d use it to write a tech book. It does look like it could handle layout a lot better than Word can, though.
  10. Microsoft Word (or free alternative OpenOffice.org) – Honestly, I’ve written two tech books in Word, and I would not recommend it to anyone. It is absolutely horrible. Don’t do it. Save yourself some pain and anguish, seriously. I don’t know about OpenOffice, but I would imagine it would be similar. This leads us to our next question – choosing your format.
  11. Emacs or vi – I’m not even going to go there. If you know what these are then you’re already using them (or decided not to).

What format should I write it in?

Ok, so if I’m not going to write this in Word, what do I do?

There are several format options available to you to write your tech book in.

  1. First up is DocBook or Simplified DocBook, which is an XML format. It was meant for writing books in. There are stylesheets available that will convert your book over to PDF format so you can see what it will look like written out.
  2. LaTeX is a document preparation system (which to me means you shouldn’t be writing in it) and is for the hardcore geeks among you. I wouldn’t write a book up in LaTeX myself, but if you like it and want to do it that way, go for it. Personally, I’d rather convert a DocBook document to LaTeX, and then take LaTeX to PDF.
  3. Scrivener has built-in support for the MultiMarkdown format, which is an extension of Markdown. This is a nice, lightweight format that is easily transformable to PDF.
  4. No formatting at all. This is certainly an option. Just write, get your words (and code) on paper and format it later.

How do I write (or choose what to write)?

Hopefully you already have something that you’re passionate about. If not, then I would recommend you not undertake writing a tech book. It is truly a labor of love and passion. Your passion shows through in your writing and helps readers become involved in the story of becoming a better programmer, sys-admin, photographer, etc. If you aren’t passionate about your subject, then that will show through too and your book won’t be successful in getting your readers fired up about the topic.

That said, first you should read Dave Thomas’ series on technical writing. Here are some highlights from that series. Once you’re done, come back here for some more tips.

Ok, all done reading the highlights? Good. I also recommend the “Code first, write later” technique. With this technique you pick a project that you are going to do from start to finish with the reader, walking them through the basics and helping them learn some things along the way.

Finally, we get down to the actual business of writing the book itself.

  • Never let the well run dry – This tip came from Hemingway, and I applied my own technique to it.
  • Use a time management technique to focus on writing – Using something like the Pomodoro Technique can help you during your writing phase. Just write for 1 or 2 Pomodoros (1 hour), then up it to 3 or 4. If you feel like doing more (and you can), go for it! See how much you can get written that way.
  • Set daily and weekly goals – Start small at first, then increase. Don’t try shooting for 10 pages a day right away, get a feel for how much you can actually do. 2 or 3 pages a day to begin with is a decent pace for a tech book. Once you set your goal, track it to monitor your progress.
  • Track progress on your goals – Just as with any goal, if you aren’t tracking your progress, how can you know if you are going towards it or away from it? Of course that means that your goal itself has to be trackable in the first place (see SMART goals for more information on setting goals).
  • Be accountable – Write on your blog or Twitter what your progress is – be accountable to someone besides yourself. This will help you stay motivated and want to update others on your progress (and maybe help motivate them as well).

Do you have any writing tips of your own that you would like to share? Add them in the comments!

Related Posts:

How to tell if an Open Source project is viable (right now) for use in your project 2

Posted by Warner Onstine on October 29, 2009

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!

Related Posts:
  • No Related Post

30 Day Experiment with Pomodoro 4

Posted by Warner Onstine on October 25, 2009

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:

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!

Related Posts:

6 signs your Web UI was created by a programmer 3

Posted by Warner Onstine on October 22, 2009

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.

Related Posts:

Here comes gorm-couchdb plugin for grails 4

Posted by Warner Onstine on October 21, 2009

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.

Related Posts:

Want. Very nice drawing app for the iPhone.

Posted by Warner Onstine on September 17, 2009

Posted via email from BlackBox Post

Related Posts:

Very frickin’ cool!

Posted by Warner Onstine on September 17, 2009

3D drawing with a pen, you have to watch it to believe it, very slick indeed.

Posted via web from BlackBox Post

Related Posts:

Easy AdSense by Unreal