Project Useful Development Blog

Created by: wbhauck

New Post

Stories Need an Associated Project

Project Useful originally started as a strictly Scrum-based project management system. All functionality was designed to follow the process. However, as I used the system in other jobs and for other projects I found that not all projects would follow the Scrum process. This meant that there might not be a Story for every Task. There could be a simple Project that owned many Tasks, similar to a to-do list. I believe that Stories should only be used within a Project.

If you're not familiar with the Agile concepts, a Story is a short description of a desired feature or bug to fix. The Story is written from the end user perspective. It captures the description of the feature or bug, the desired results, and the type of user that it applies to.

To enforce the idea that Stories should only be used within a Project I added a validation to the Story model:
validates :project, presence: true

I'm going with this process for now. If in the future I find a use for Stories outside of Projects I'll make adjustments.

Adding Dates to Story

I'm not sure why I didn't include them in the first place, but I added scheduled and actual start and end dates to the Story. This will allow better scheduling as well as measuring against the estimated times.

Adding CRM Functionality to Project Useful

Project Useful is still under heavy development. As the project management side of the system matures and becomes more ... useful, I've found that there's a need for more CRM-like functionality. Tracking contacts, phone calls, emails, and text messages regarding various projects is as important as tracking the work itself. Instead of having a paper-based or electronic-yet-separate system to track the communications I decided to add this capability to Project Useful itself.

The basic CRM functions will be to track:

Products and Projects will be associated with Contacts as the client. Eventually, Users will be associated with Contacts so that Contacts can log into the system to view their associated Products and Projects in their role as client.

Rails 5.1 & Bootstrap 4

I've updated Project Useful to now work with Rails 5.1 and Bootstrap 4. The main differences for Bootstrap are the classes for navigation. The Rails changes were to add a ActiveRecord version number to migrations. Rails 5.1 requires this for old-style migrations.

Reports

What's a project management system without reports?!

I'll be starting with a basic daily status report showing all open tasks and the latest comment for each.

Completed tasks pose a difficult problem since you don't want to report on the same tasks day after day, yet you don't want to skip them. This particular portion will take some more thought.

Development Continues!

Unfortunately, I've been extremely busy over the last few months. Between starting a new position at work and home life I haven't been able to dedicate much time to this project. I also have been dedicating some project time to another project since I needed a non-Scrum based project system. So instead of working on a separate system I decided to simply add that functionality to Project Useful. It's common for an individual or organization to have Scrum-based and traditional projects so why not have one system to handle both.

Project Useful is going to be a major focus of my free time. I'm using it for home projects as well as at work, both of which are guiding the development of the system. It's pointless to build a system in a vacuum.

Organizations Added

Organizations have been added. They are very basic at the moment, just a name and description, but they will be expanded soon. Also, there are no relationships for them yet but soon!

Starting to use scopes in Models

As I learn more about Rails I learn better ways to write code. Yesterday was one such experience.

I learned about scopes in ActiveRecord models. They are very hand and a much cleaner way of ordering records, applying conditions, etc. than having a huge string of conditions in a View or a Controller, especially if you're doing the same queries in different places.

For instance, I had a hard coded ordering on blog posts ...


Old way

blog.rb; has_many :posts, class_name: "BlogPost", :order => "publish_date DESC"


blogs/show.html.erb: @blog.posts.each


New way

blog.rb: has_many :posts, class_name: "BlogPost"



blog_post.rb: scope :sorted, lambda { order("blog_posts.publish_date DESC") }


blogs/show.html.erb: @blog.posts.sorted.each

It might not seem like a big difference, but it removes the forced sorting of blog posts when showing a blog. It is also just a single change. I'll be creating a handful of scopes to return various queries in a clean and concise manner.

Rails 4.0.2 to 4.2: has_many order attribute changed

I'm in the process of upgrading from Rails 4.0.2 to 4.2, and the first issue I've encountered as the order: attribute changed.


Rails 4.0.2: has_many :posts, class_name: "BlogPost", :order => "publish_date DESC"


Rails 4.2: has_many :posts, -> { order('publish_date DESC') }, class_name: "BlogPost"


I'm not sure if there's a better way, but this way works so I'm going with it for now.

Wiki Page Progress

The original Wiki and WikiPage stuff was based on Rails' generated scaffolding. As such, it uses the id, an integer, as the primary key for the database tables as well as the identifier in the URI. The wikis that I'm used to working with use a string, generally the title, as the identifier. Or, at least, on the surface. Mediawiki, for instance, uses the title in the URI but uses an unsigned integer as the page primary key. It uses the primary key in relation tables.

Project Useful is shaping up to follow this pattern. Currently, the title is the page title as well as the identifier in the URI. The wiki_pages table uses the ActiveRecord standard signed integer as the primary key.

Some more work needs to be done on the Wiki type itself. It still uses the signed integer primary key as the table primary key as well as the identifier in the URI. This might change, but I'm not sure how. If it changes to the Wiki title as the identifier in the URI there could be significant name clash. I foresee people creating "User Documentation" wikis for individual projects. If the URI's use titles then there can only be one "User Documentation" Wiki. Unless it's tied to a specific project, which can happen. However, I like the idea of not requiring a Wiki to be tied to a Project. That way Project Useful could be used for other, non-project-specific documentation.

I'll try out some of the options and see what I like most. However, for now, it'll stay with the signed integer as the identifier int the URI.

What's Your Issue?

Issues allow users, and currently guests, to log issues in the system. Issues are meant to be the precursor to a Story. Basically, a User of the system submits an Issue when they find a bug, want an an update to an existing feature or to request a new feature. They can also request new documentation or updates to existing documentation.

The Issue will be evaluated by the appropriate Product Owner (PO). If the PO accepts the issue the Issue will be marked accepted and a corresponding Story will be automatically opened. (The automatic Story creation will be written tomorrow.)

The Issue submitter will be notified of the Story creation through the email address she entered in the Issue form.

Commits and Versions

I thought I'd mention that there are going to be a lot of commits to the Project Useful Github repository. This is due to the fact that I'm using Project Useful as my tracking system while developing Project Useful. This way I have a real-world test case as well as a tracking system that I like.

So I've realized that Ruby on Rails doesn't automatically create a VERSION number anywhere. So I'm adding one in config/initializers/version.rb. It'll get updated each time I commit and push to Github. For now I'm updating it by hand. Tomorrow I'll write a git hook to update it automatically on commit.

Products Now Have An Owner And Status

Products now have owner and status. Both of these fields are mandatory. Like the Sprint, Story, and Task statuses, the Product Status is color coded allowing you to very easily differentiate between Products in different stages of development. The styling is applied by the code of the Product Status; each code has a corresponding CSS class in the project_useful.css file. The styles can be customized to suit your needs.

Notes Are Alive, Stories have Estimated Hours

I've created the Note item type. I think it fits with Blog and Wiki. Blogs are ... well, blogs. And a Wiki is for documentation. A Note is like a scratch pad, a place you can record information for later use.

I imagine folks will say that it's overkill, but from past experience I think it will be useful. I remember going to many meetings and people scribbling furiously in notebooks or Windows' Notepad application or other such application. The problem is that the information on paper is only available when you have the paper. Local text files on your desktop or even laptop suffer the same issue. Putting the note into a Project Useful Note would make it available from any place in the world you can get online and access your system. Also, since you can set different privacy levels, you can share your Note with your team far easier than making a photo copy and handing it out.

Stories now have estimated hours, allowing you to record your guess at the time to complete the story. The actual hours will be displayed with the Story, but it will be calculated from the times recorded on the Tasks for the Story. I'll get to the task time stuff tomorrow, since it's only 21 minutes away.

Day 9

Stories and Tasks now have assignments. Each story or task can be assigned to one or more Users. Users can be added and removed independently of other users. The data is stored in a relationship table, story_id and user_id for Stories, task_id and user_id for Tasks.

You can add users to each item on the details page, but you can remove users from both Stories and Tasks from the Stories details page.

The Sprint listing now shows the status of the Sprint as well as the number of Stories on that Sprint.

Simple Form Updates

Since Project Useful is being written in Ruby on Rails and using the Rails scaffolding, all of the forms are the basic, div-per-item linear forms. The forms also use text fields for association id's. It is annoying already and I can't imagine what it'd be like when there are hundreds of Stories, thousands of Tasks, etc. So I'm updating the forms to use select dropdowns. it is working nicely, but I've noticed one unacceptable side effect: you cannot leave the field empty. For instance, the earliest living Sprint is automatically selected when creating a new Story. A Story does not need to be part of a Sprint until the team decides to work on it. Therefore, the select dropdown needs an "empty" Sprint. This will be fixed in Story 25: http://www.projectuseful.org/stories/25

Progress Continues

It's been a little over two days since Project Useful was started and it's coming along nicely. All top level items are created; they are primitive to be sure, but they exist. Today I'm working on task ownership, statuses for all items, and the "My" menu items ... My Active Projects, My Complete Projects, My Active Tasks, My Complete Tasks, etc.

You might notice "(DEVEL)" sprinkled through out the system. I'm using this as a marker to indicate that the item or section is only there during the development of the system. Once the permanent solution is developed the (DEVEL) item or section will be removed. For instance, "(DEVEL) List All Blog Posts" is being used during development of the overall Blog functions. Once complete, or complete enough, the "List All Blog Posts" menu item, code, templates, test, etc. will be removed.

Project Useful Up and Running

Project Useful was started on July 15, 2014 at 7:30:24 PM. That's when I came up with the name and registered the domain. On July 17, 2014 www.projectuseful.org was setup in Apache with the initial project code. I'm using the Project Useful to drive the development of the system itself. I currently have all items viewable by non-logged in guests so folks can follow the process and direction that the system is taking. I'll be opening it up so people can register and submit feature requests, bug reports, etc.

If you're reading this post around the publish date you'll see just how primitive the system currently is. I plan on putting at least a few hours into development each day.