on version control Usually I check-in at the end of each day, each file separately (documenting the changes in each module). If you work together with other people you will have to see that your check-in does not break things. Because of that you might not check-in one or the other thing at the end of the day (others depend on working dev version!) but things are checked in when they are fairly stable.
Do not use version control for synchronizing, e.g. you code on you local machine and write code for a server, so whenever you change 2 lines of code you want to see if they work and you do a local check-in and an update on the server. For this you can use a sync tool like rsync or unison. My rule of thumb is. In the morning and update of all file. In the evening a check-in of all changes. On Jan 11, 9:17 pm, selecta <gr...@delarue-berlin.de> wrote: > Ok here goes another one > Features of a bug tracker that I use: > Rank (high priority - low priority) > Staus (open/close) > Assign to (some team member) > (what I think is nice too is: duplicate of) > > This works well in a small project > I guess the other features are needed in a larger project where you > need a finer control > > On 11 Jan., 21:10, selecta <gr...@delarue-berlin.de> wrote: > > > > > I was short on time so I will continue now with how I/my group deals > > with spreading the work. In most cases it clear who will do what since > > everybody has some special knowledge in a part of the software that he > > created. If the assignment is close to what one of my colleages is > > doing the bug or feature is assigned to him. > > > But every month or so we do something we call a paper snake. I picked > > this up in an wikipedia article about rapid development or some goole > > tech talk or something like that, probably has some better name > > already. The paper snake works like that: Everybody gets together and > > writes his TODOs and ideas on a queuecard (really just anything that > > comes to mind what should/could be done) then after 5 minutes or so > > all the cards are collected and we sort them together, first filtering > > out the doubles. Then we put them in the order they should be done and > > make some extra cards with deadlines. So we have a list of > > deliverables that should be done till a certain date. Now we go > > through the list (cards on top each other on the table) and assign > > each card to somebody in the group. Some cards nobody wants to do > > (usually: updating the user documentation) in these cases you need > > somebody with authority that will decide who has to do it. In most > > cases somebody is suggested and a compromise is found. In a final step > > we staple or glue together the cards and end up with a nice paper > > snake that we hang up where everybody can see it. This is very visual > > and also a bit fun. You can rip of cards from the bottom when things > > are done (yeay!) ... assuming that the earliest todos are at the > > bottom of the snake. > > > I introduced this technique to our group and we kept it since it works > > quite well to get an overview and plan > > > Similar things are also good to explain your software to other people, > > paper hacking is very underestimated in my opinion ;-) > > > On Jan 11, 6:12 pm, rondevu <ranjeev...@gmail.com> wrote: > > > > Thadeus, thanks for asking these questions! > > > I am loving the answers here. > > > And, to all who answered here, many more thanks for the advices. > > > Replies on this thread is really useful for a programming newbies like > > > me and creates a good direction for organised work. > > > > Would love to hear more. > > > > On Jan 12, 12:28 am, Thadeus Burgess <thade...@thadeusb.com> wrote: > > > > > Version control is a gimme... Which I currently use Mercurial, the > > > > main repo is on our fileserver which gets replicated to an off-site > > > > backup server. > > > > > I guess I sidetracked myself, I am not too concerned with the > > > > technical differences between one system or another, I am more > > > > interested in ways to get the most out of a bug tracker / feature > > > > tracker / roadmap, and what features are really important to get the > > > > most productivity out the door. > > > > > Is integration with your SCM a key feature to look for? > > > > How do you use this integration, assign each commit to a feature or bug? > > > > Does this mean commits should happen at every small step that gets > > > > completed instead of one that includes everything? > > > > > I really appreciate the feedback! It is helping me get a sense of this > > > > whole "project management" area and an idea of where I would like to > > > > start. > > > > > -Thadeus > > > > > On Mon, Jan 11, 2010 at 8:58 AM, selecta <gr...@delarue-berlin.de> > > > > wrote: > > > > > I work in a scientific environment, so not exactly what you want to > > > > > do > > > > > but I do things similar to what was already described > > > > > > I use Version Control (Currently SVN) > > > > > Log History show nicely what has happened lately > > > > > > I use a bug tracker and a feature tracker > > > > > Shows even better what should be done (features) and what has to be > > > > > done (bugs) > > > > > > If you work open-source you get everything in a nice package from e.g. > > > > > SourceForge > > > > > here is my feature tracker of a recent project that I do > > > > >https://sourceforge.net/tracker/?group_id=293913&atid=1241702 > > > > > Even though there is not much on there yet you can see that tracker > > > > > items have a priority (which can be assigned by the people that pay > > > > > you :) they are in control) and a status (that shows them what has > > > > > been done so far) > > > > > > For version control there are nice GUI tools (e.g. for SVN: > > > > > tortoisesvn > > > > > (win), RapidSVN (Linux)) which will get you up and running in no time > > > > > (you need to know the basics check out, commit, update ... but you can > > > > > read about that in about 2 hours) > > > > > > You should waste no time and get both for your project immediately. > > > > > The trackers will also help you organize and prioritize your work > > > > > which will make you work faster! The version control, if you use it as > > > > > a single person, will give you at least a well documented backup that > > > > > can come in handy if your hd crashes (assuming the version control > > > > > server is on a different machine). With a diff tool like meld (linux) > > > > > you can even show how much new code you wrote to somebody that does > > > > > not know how to hack in a nice and visual manner. > > > > > > And while we are talking about this subject, why buy a tracker > > > > > software when we have web2py? We can write a web2py plugin for that. I > > > > > want do it in the next few month but if somebody goes first I would > > > > > love to also use it. If somebody is interested we could even make a > > > > > open-source project out of it. So respond to this post if you want to > > > > > start the tracker project with me ... or wait for a couple of month, > > > > > till i will release what I did :) > > > > > > On Jan 10, 4:04 pm, rev <reneversch...@gmail.com> wrote: > > > > >> > Currently I am the only programmer in the company. My goals are > > > > >> > two-folded. One, I need a way to show my non-technical superiors > > > > >> > that > > > > >> > I am working and making progress. > > > > > >> Being able to show submits in your version control app is one way of > > > > >> showing that you did something. > > > > >> Many submits doesn't automatically mean much work, but non-technical > > > > >> superiors tend to look only at numbers... > > > > > >> Always try to split your work up into small clearly defined chunks. > > > > >> Try to estimate how long each of these small tasks will take to > > > > >> implement (yep, that's hard to do). > > > > >> This will give you an estimate how long it will take to complete the > > > > >> project, and you can see the progress. > > > > >> It doesn't matter what tool you use to track this (paper, > > > > >> spreadsheet, > > > > >> issuetracker, project management tool). > > > > >> Just start doing it and meanwhile start reading and playing with > > > > >> other > > > > >> tools. > > > > >> You'll get experience in what works for you and what not. > > > > >> Project management is not something you learn overnight, you should > > > > >> study and learn by doing. > > > > > >> I can't tell you if trac (or any other app) is right for you, nor if > > > > >> JIRA is. > > > > >> Just try it out. > > > > >> There are some free apps out there, nowadays you can get JIRA > > > > >> 10-users > > > > >> for $10 (plus another $10 if you want the GreenHopper plugin for > > > > >> scrum). > > > > > >> To store documentation you again have several options. > > > > >> One is to store them in your version control app, you could use a > > > > >> dedicated document control app, or store everything in a wiki. > > > > >> Again there are several free/cheap apps out there > > > > >> Storing digitally + backups should be sufficient. > > > > > >> rev > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > > Groups "web2py-users" group. > > > > > To post to this group, send email to web...@googlegroups.com. > > > > > To unsubscribe from this group, send email to > > > > > web2py+unsubscr...@googlegroups.com. > > > > > For more options, visit this group > > > > > athttp://groups.google.com/group/web2py?hl=en.
-- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
