MyInnoQBlogtag:www.innoq.com,2010:/blog/dp/232008-07-12T18:06:38Zby Daniel PietzschMovable Type 3.31Got Backup?tag:www.innoq.com,2008:/blog/dp//23.34792008-07-12T18:05:36Z2008-07-12T18:06:38ZOn thursday morning, my hard drive died at the age of (almost) 4. I’m really glad I’m backing up my data every hour. So the whole process of getting everything up and running again was really inconvenient, but was no...Danielhttp://www.innoq.com/blog/dp/
So: don't be careless and backup regularly!]]>
Statustag:www.innoq.com,2008:/blog/dp//23.34782008-07-11T15:09:29Z2008-07-11T15:12:00ZIt’s been a long time since I last updated the blog. I have been really busy creating the in-house application (here at innoq) for invoice management and time reporting. And as this is my diploma thesis, too, I’m now occupied...Danielhttp://www.innoq.com/blog/dp/
Note to self: I should update this blog more regularly!]]>
Lesson learnedtag:www.innoq.com,2008:/blog/dp//23.34592008-04-29T18:30:30Z2008-04-29T18:31:36ZA part of my ER-Model is not correct: The many-to-many association between Projects and Users is simply wrong. Imagine a simple case of an deletion of a relation between an User and a Project - for example the user/employee stopped...Danielhttp://www.innoq.com/blog/dp/
The many-to-many association between _Projects_ and _Users_ is simply wrong. Imagine a simple case of an deletion of a relation between an _User_ and a _Project_ - for example the user/employee stopped working on that particular project - causes the project also to disappear from _Timereports_ in the past.
And this is fundamentally wrong, **because he surely did work on that project**!
And so the connection should be between _Projects_ and _Timereports_!!! Like this:
I'm pretty sure this has to be modelled this way.
Now if the user stops working on a particular project, it's no problem to do that deletion.
Project has_many :timereports, :through => :projects_timereports
######
Timereport has_many :projects, :through => :projects_timereports
######
ProjectsTimereports has_many :timereportentries
Ok, now I'll have to re-code that and I hope it won't me drive nuts to do this, because I really could have avoided it!]]>
ActiveResource and Associationstag:www.innoq.com,2008:/blog/dp//23.34582008-04-23T18:39:50Z2008-04-23T18:47:10ZOk, it’s been quite a while since the last post popped up here; that’s because I struggled with the innoQ internal timereporting- and invoicing-application I’m working on, which is my diploma thesis, too. And here’s one of my problems I...Danielhttp://www.innoq.com/blog/dp/
'projects_users'
In a class which inherits from ActiveResource this is not supported/allowed.
Ok, in my _project_ model these statements would work, because it is an ActiveRecord object. But all the methods you gain through this won't work either, because they don't know the you are referencing a model of type ActiveResource and all finds will fail.
So what to do?
Here's what works for me (so far).
But I'm sure there are many more ways out there to solve this, and I'd really appriciate every comment on this topic, 'cause I am curious if there's a more elegant solution. So, there you go:
### My solution
Remember the initial situation:
Project (ActiveRecord - in my app) (M)-----------(has)----------(N) User (ActiveResource - remote app)
So first of all I created a join table and the corresponding join model by typing (in the console, of course):
script/generate model projects_users
This creates a model for me with along with a migration file. Inside this file I write these lines:
class CreateProjectsUsers < ActiveRecord::Migration
def self.up
create_table :projects_users do |t|
t.integer :project_id, :user_id, :null => false
t.string :color, :null => false
end
end
def self.down
drop_table :projects_users
end
end
An advantage of join models is that you can store additional attributes in the join table. The only thing I store along the _project\_id_ and the _user\_id_ is a _color_. That's just relevant for the front-end to display the project in the correct color, so don't get irritated. ;-)
Then, I ran the migration:
rake db:migrate
Now, let's head over to the association part.
As you can't put any associations in a ActiveResource model, there's nothing to do in the _User_ model.
In the _Project_ model I put a _has\_many_ statement:
has_many :projects_users, :class_name => "ProjectsUsers"
(Note, that in my case I had to explicitly tell the _class\_name_ of the join model class, because Rails assumes this to be singular, i.e. _ProjectUser_.)
In the _ProjectsUsers_ model I wrote the following two lines:
belongs_to :project
belongs_to :user # so far this isn't used by me, but it may be useful some day
Now the interesting part: How can you get all users for a given project in a way like _project.users.find(:all)_?
In _project.rb_, define a method called _users_:
def users
user_ids = self.projects_users.find(:all, :select => "user_id")
users = user_ids.collect { |projects_users| User.find(projects_users.user_id) }
end
Now via _project.users_ you'll get all the users you need.
(I'm pretty sure you can rewrite this, so that it works the _railsway_ and you can call _project.users.find(:all)_ instead, but I haven't tried it, yet)
Ok, the other way round, meaning obtaining all projects for a specific user, I faked it a bit, and I'm sure you can do better here, too. But it works!
Instead of creating a _projects_ method in the _User_ model, I coded a method called _self.find\_by\_user\_id_ in the _Projects_ model:
def self.find_by_user_id(userid)
project_ids = ProjectsUsers.find_all_by_user_id(userid, :select => "project_id")
projects = project_ids.collect { |projects_users| projects_users.project }
end
You can call it this way:
user_projects = Project.find_by_user_id(2)
And _BOOM!_, you have all projects for the user no. 2.
That's all folks!
This was my solution/workaround for integrating a REST-Resource via a many-to-many association in Rails. Hope you liked it. :-)]]>
Rails and in_place_editor issuestag:www.innoq.com,2008:/blog/dp//23.34542008-04-05T14:58:40Z2008-04-05T15:16:48ZOk, so the last few days I had a bit of a struggle concerning the script.aculo.us in place editor and the corresponding plugin/helper in rails. So here are my links that really helped me solving these issues: InPlaceEditing in Ruby...Danielhttp://www.innoq.com/blog/dp/Euruko this weekend! [UPDATE]tag:www.innoq.com,2008:/blog/dp//23.34432008-03-27T19:32:39Z2008-03-30T15:19:50ZThis weekend the Euruko conference takes place in Prague. It's all about Ruby and I'll gonna be there. I'm quite excited, as this is my first (big) conference I'm going to attend. I think most of the talks will be...Danielhttp://www.innoq.com/blog/dp/
Euruko conference takes place in Prague. It's all about Ruby and I'll gonna be there.
I'm quite excited, as this is my first (big) conference I'm going to attend. I think most of the talks will be pretty advanced for a Ruby beginner like me, but I think I won't get dumber... ;-)
Unfortunately we'll probably miss Matz' Keynote, because our flight arrives at 09:30 in the morning and to think we'll be in the center of Prague at 10 o'clock would be really optimistic...
**[UPDATE]**
We managed to get to prague university almost in time, so we saw most of the keynote:
I'm also looking forward to visiting Prague again, 'cause it really is a beautiful city - and affordable, too. That's why I'll stay until late tuesday. :-)]]>
More ER-Modellingtag:www.innoq.com,2008:/blog/dp//23.34352008-03-11T12:19:54Z2008-03-11T12:21:49ZOnce more, I improved the model of my application. I wasn’t satisfied with the fact, that I was indeed able to store the time report data for each day of the month, but have an UI on a monthly basis...Danielhttp://www.innoq.com/blog/dp/
That's exactly how I wanted it to be from the beginning. I don't no why this took me this long...
Now it's also no problem to get nice URLs for a *TimeReport*. For example like this: *http://.../TimeReport/DanielPietzsch/2008/3/* for March 2008.]]>
Third (and probably last) time reporting mockuptag:www.innoq.com,2008:/blog/dp//23.34302008-02-28T17:27:54Z2008-02-28T17:29:10ZBesides thinking about how to model my database I continued working on the UI: Ok, maybe you don’t see that much difference since the last mockup, but I refined most of the div-structure beneath the surface and did some minor...Danielhttp://www.innoq.com/blog/dp/
Ok, maybe you don't see that much difference since the last mockup, but I refined most of the div-structure beneath the surface and did some minor design changes.
But the biggest improvement is, that the calendar is now based on real dates. I must admit that the [calendar helper plugin](http://agilewebdevelopment.com/plugins/calendar_helper "Plugins - Calendar Helper - Agile Web Development") helped me with the code.
The bullet-points on the 28th are a representation for all calendar fields, where you entered any hours. If you didn't enter an other number than *0* the day cell stays empty (for display). If you want the add or modify hours on a particular day, you click the cell and via an in-place editor you can enter your information. (That's the plan).
I'm not quite sure if the coloring of the weekends will stay that way...I think I'll decide later, since this is not the most important decision to make.
Now I think I should concentrate on the real app, meaning all the functionality and model behind the UI.]]>
Altered ER-Model [UPDATE]tag:www.innoq.com,2008:/blog/dp//23.34272008-02-26T14:08:03Z2008-03-04T17:46:59ZI altered a part of my ER-Model concerning the implementation of the time-reporting: There’s no longer an entity called “Arbeitszeit” (working time). All the worked hours and days should now get stored in the extra many-to-many-table that’ll be created in...Danielhttp://www.innoq.com/blog/dp/
There's no longer an entity called "Arbeitszeit" (working time). All the worked hours and days should now get stored in the extra many-to-many-table that'll be created in between "Stundenzettel" (timesheet) and "Projekt" (project). That table might have the following attributes: *StundenzettelID, ProjektID, workingTimeTotal, dailyTimes, notes*.
So far I'm not sure how to store all the hours to their corresponding days in *dailyTimes* (because that's at least about 30 values every month and user), but I might use a plain text field which contains a somehow-delimited list of working-hours (ascending from the 1st to the last day of the month).
The "Mitarbeiter" (co-worker) entity is also the applications entity for storing login- and user-information.
What you see on the [latest mockup](http://www.innoq.com/blog/dp/2008/02/second_ui_mockup.html "Second UI mockup (MyInnoQBlog)"), is in Rails the update- or new-action/view for the "Stundenzettel"-controller. I think there won't be any implementation of a read- or delete-action for "Stundenzettel" (timesheets).
So, I hope this will work for me...
And yes, next time the ER-Model will be in english, too, that I don't have to bother you (and me) with this language mix. I also code in english, so this makes sense anyway.
[UPDATE]
After talking to [Tim](http://innoq.com/blog/tk/) and [Phillip ](http://ghadir.de/blog/) *and* considering [Stefans Comment](http://www.innoq.com/blog/dp/2008/02/altered_ermodel.html#comment-251726), I think this is the right way of modelling the Entity Relationship:
So, in the *DailyReport* entity there is the attribute *Date* which is an additional primary key to the *ProjectID* and the *UserID*. This way the *WorkedHours* are stored for every day. So you have a table for every day, employee and project.
The same with *notes*. This may be useful to describe your tasks on that day, for example. This way I think I'll have to reengineer the UI, 'cause notes do not get stored on a monthly basis. I already have something in mind for that.
[/UPDATE]]]>
Second UI mockuptag:www.innoq.com,2008:/blog/dp//23.34242008-02-22T17:52:41Z2008-02-22T17:53:25ZThe second mockup of the applications UI. I thought I stick to the design of innoq.com, so co-workers are somehow familiar with the layout. The (div-)structure underneath is quite different than the one of innoq.com, but I copied some design-elements...Danielhttp://www.innoq.com/blog/dp/
In the top-right corner you now have the ability to add one or more projects you're currently working on. They'll be differentiated by colors. In the calendar you'll find the corresponding fields for these projects. Again: I think I'll hide most of these field in normal view, using an in-place editor.
I'm still really curious what your opinion is...]]>
First UI mockuptag:www.innoq.com,2008:/blog/dp//23.34222008-02-18T15:47:02Z2008-02-18T15:53:22ZAs far as Unified Process is concerned, I already clarified some of the Business Modeling and Requirements a few month ago. See my blogposts here and here. Well, I think I had a flash of inspiration: in order to “get...Danielhttp://www.innoq.com/blog/dp/
That is the first screen for the colleagues out there in customer-projects for doing their time-reporting.
Ok, it is still made up of standard fonts, there are no fancy graphics etc., but I think it represents the image I have in mind when I think of that part of the app.
What bothers me a bit are all the input fields in the calendar. I think I'll hide them using some AJAX in-place editors, so they won't be that distracting.
I don't really know what will be next. Either I start implementing this feature or I go for another UI-mockup. Maybe I'll know more in one hour or so...
Stay tuned and feel free\* to comment on the UI-mockup!
\*actually, I would force you to comment, if I could!]]>
Prefacetag:www.innoq.com,2008:/blog/dp//23.34212008-02-14T13:28:09Z2008-02-14T13:39:09ZThe first draft of what my diploma thesis will be about (in german): Arbeitsthese (PDF)...Danielhttp://www.innoq.com/blog/dp/
Arbeitsthese (PDF)]]>
Years of irrelevancetag:www.innoq.com,2008:/blog/dp//23.34142008-02-05T18:48:51Z2008-02-05T19:03:33Z"Requiring X years of experience on platform Y in your job posting is, well, ignorant." DHH on the 37signals blog. I found this post really interesting (including the comments). As a student I never applied for a job that required...Danielhttp://www.innoq.com/blog/dp/
"Requiring X years of experience on platform Y in your job posting is, well, ignorant."
DHH on the 37signals blog.
I found this post really interesting (including the comments).
As a student I never applied for a job that required X years in experience on a specific platform, but I sometimes wondered how hard employers insist on such a point on a job offer.
I mean, it really depends on the single person. There a definitely programmers (not to say geeks ;-) ) that are better in programming X after one year of experience than others are after - say - 3 years (IMHO).
What do you think?]]>
Hell yeah! I'm done...tag:www.innoq.com,2008:/blog/dp//23.34102008-01-30T17:35:30Z2008-01-30T17:45:30Z...with written tests for university! Today i wrote my last and now I can fully concentrate on my diploma thesis (and innoq.com, too). By the way: innoq.com is running on Rails for almost 3 weeks now, and I think it's...Danielhttp://www.innoq.com/blog/dp/
innoq.com is running on Rails for almost 3 weeks now, and I think it's doing fine, isn't it, Stefan?
I think I'll have a beer right now...! Cheers!]]>
Got Math?tag:www.innoq.com,2008:/blog/dp//23.33722008-01-03T09:34:02Z2008-01-03T09:40:41ZAmy Hoy: "No, [math is] not a prerequisite for most programming, and especially not web development as a whole. The more I watch people struggle with programming, the more I think that synthesis and intellectual flexibility are far more important...Danielhttp://www.innoq.com/blog/dp/
"No, [math is] not a prerequisite for most programming, and especially not web development as a whole.
The more I watch people struggle with programming, the more I think that synthesis and intellectual flexibility are far more important skills than the ability to write small, isolated, brilliant bits of code."
Really good article and discussion on the link between math and programming skills.
Be sure to read the very interesting comments as well:
http://www.slash7.com/articles/2008/1/2/got-math]]>
So: don't be careless and backup regularly!]]>
Note to self: I should update this blog more regularly!]]>
The many-to-many association between _Projects_ and _Users_ is simply wrong. Imagine a simple case of an deletion of a relation between an _User_ and a _Project_ - for example the user/employee stopped working on that particular project - causes the project also to disappear from _Timereports_ in the past.
And this is fundamentally wrong, **because he surely did work on that project**!
And so the connection should be between _Projects_ and _Timereports_!!! Like this:
I'm pretty sure this has to be modelled this way.
Now if the user stops working on a particular project, it's no problem to do that deletion.
Project has_many :timereports, :through => :projects_timereports
######
Timereport has_many :projects, :through => :projects_timereports
######
ProjectsTimereports has_many :timereportentries
Ok, now I'll have to re-code that and I hope it won't me drive nuts to do this, because I really could have avoided it!]]>
I'm also looking forward to visiting Prague again, 'cause it really is a beautiful city - and affordable, too. That's why I'll stay until late tuesday. :-)]]>
That's exactly how I wanted it to be from the beginning. I don't no why this took me this long...
Now it's also no problem to get nice URLs for a *TimeReport*. For example like this: *http://.../TimeReport/DanielPietzsch/2008/3/* for March 2008.]]>
Ok, maybe you don't see that much difference since the last mockup, but I refined most of the div-structure beneath the surface and did some minor design changes.
But the biggest improvement is, that the calendar is now based on real dates. I must admit that the [calendar helper plugin](http://agilewebdevelopment.com/plugins/calendar_helper "Plugins - Calendar Helper - Agile Web Development") helped me with the code.
The bullet-points on the 28th are a representation for all calendar fields, where you entered any hours. If you didn't enter an other number than *0* the day cell stays empty (for display). If you want the add or modify hours on a particular day, you click the cell and via an in-place editor you can enter your information. (That's the plan).
I'm not quite sure if the coloring of the weekends will stay that way...I think I'll decide later, since this is not the most important decision to make.
Now I think I should concentrate on the real app, meaning all the functionality and model behind the UI.]]>
There's no longer an entity called "Arbeitszeit" (working time). All the worked hours and days should now get stored in the extra many-to-many-table that'll be created in between "Stundenzettel" (timesheet) and "Projekt" (project). That table might have the following attributes: *StundenzettelID, ProjektID, workingTimeTotal, dailyTimes, notes*.
So far I'm not sure how to store all the hours to their corresponding days in *dailyTimes* (because that's at least about 30 values every month and user), but I might use a plain text field which contains a somehow-delimited list of working-hours (ascending from the 1st to the last day of the month).
The "Mitarbeiter" (co-worker) entity is also the applications entity for storing login- and user-information.
What you see on the [latest mockup](http://www.innoq.com/blog/dp/2008/02/second_ui_mockup.html "Second UI mockup (MyInnoQBlog)"), is in Rails the update- or new-action/view for the "Stundenzettel"-controller. I think there won't be any implementation of a read- or delete-action for "Stundenzettel" (timesheets).
So, I hope this will work for me...
And yes, next time the ER-Model will be in english, too, that I don't have to bother you (and me) with this language mix. I also code in english, so this makes sense anyway.
[UPDATE]
After talking to [Tim](http://innoq.com/blog/tk/) and [Phillip ](http://ghadir.de/blog/) *and* considering [Stefans Comment](http://www.innoq.com/blog/dp/2008/02/altered_ermodel.html#comment-251726), I think this is the right way of modelling the Entity Relationship:
So, in the *DailyReport* entity there is the attribute *Date* which is an additional primary key to the *ProjectID* and the *UserID*. This way the *WorkedHours* are stored for every day. So you have a table for every day, employee and project.
The same with *notes*. This may be useful to describe your tasks on that day, for example. This way I think I'll have to reengineer the UI, 'cause notes do not get stored on a monthly basis. I already have something in mind for that.
[/UPDATE]]]>
In the top-right corner you now have the ability to add one or more projects you're currently working on. They'll be differentiated by colors. In the calendar you'll find the corresponding fields for these projects. Again: I think I'll hide most of these field in normal view, using an in-place editor.
I'm still really curious what your opinion is...]]>
That is the first screen for the colleagues out there in customer-projects for doing their time-reporting.
Ok, it is still made up of standard fonts, there are no fancy graphics etc., but I think it represents the image I have in mind when I think of that part of the app.
What bothers me a bit are all the input fields in the calendar. I think I'll hide them using some AJAX in-place editors, so they won't be that distracting.
I don't really know what will be next. Either I start implementing this feature or I go for another UI-mockup. Maybe I'll know more in one hour or so...
Stay tuned and feel free\* to comment on the UI-mockup!
\*actually, I would force you to comment, if I could!]]>