TMP – Team Management Project
Today I am announcing a series of blog posts related to building a project I will call, so far, TMP – Team Management Project. TMP is something I have been working on for several last days to help our team to work more efficiently.
In these blog posts I want to talk about awesome pieces of software libraries, services, etc. I used to build that software and that allowed to deliver something we find useful.
Yes, this is the first and most crucial question. Why on earth are you writing “yet another” team project management application?
Because we can!!
No, really. We evaluated several existing team scheduling solutions, and eventually settled on one that seemed to fit our needs. After using it extensively for a while, it became clear that we wanted more.
We wanted better support for automation in most of our use-cases and we were interested in tracking additional meta-data is specific to the inner-workings of our team. Moreover, we wanted an open solution that could integrate with our other tools (both internal and external).
Since OpenShift provides everything we need in order to quickly build a custom SaaS solution, we decided that designing our own tools from scratch was worth a shot.
And now you are thinking “Hmm, so you are that specific? Well, tell me about it, I wanna know – I am using product X and it works well.”, right? I will not be detailing all the things we want the system to do, but a few.
Our team works on a point-based system. Each member is required to do some tasks and then he opts for some asks. For every task there is well-defined point value. Each member is required to
- complete required tasks in timely manner
- collect required value of points per month
A lot of our work is connected to attending events. We need to track when and where those events are. We need to track the costs associated with each of those events. We need to share information and cooperate on arrangements. We need to connect events with our point system. And so on.
Everything can be simplified down to a task – title, description, assignee, due date. That’s why we used the previous system. However this simplification gave us some headaches because we need to track more information then this and in the end you end up with huge messy description or a lot of comments on every task. And hell, how to filter through those?
That is some of our requirements and there is much more that will be covered thorough the series.
What is it gonna be about?
The primary technologies I will use are
- Ruby as a language of choice
- Ruby on Rails framework
- PostgreSQL as storage backend
- OpenShift for deployment
and I am already contemplating adding some more
- MongoDB to store non-relational data
- Node.js for real-time components
Some of the libraries that will be covered
- Closure Tree – Tree structures for ActiveRecord
- Kramdown – fast & extensible Markdown for your Ruby project
- MultiJSON – depend on JSON parsing/encoding libraries cleverly
- Chronic – parse date/time from strings
- iCalendar – export to your favorite PIM
- ice_cube – calculate schedules for repeated events
- Parslet – PEG based parser in pure Ruby
Yes, there are well knows libraries and some not that well know. The point of this series is to provide information on ways how to use these libraries to expand the feature set of your application or how to make your application more portable and flexible.
Next episode will be about Closure tree and tree structures for ActiveRecord.
What is the expected result? I want to share my experience with some very, very interesting libraries and in the end we plan to release this application as an open-source project to the community. So in this series you can stay up-to-date on what is coming.