project, bug, tools

ting å vurdera: trac, ny mantis

dersom me vurderer svn: trac

The Trac Project - Trac

Trac is an enhanced wiki and issue tracking system for software development projects.
....
provides an interface to Subversion, an integrated Wiki and convenient reporting facilities.
....
A timeline shows all project events in order, making the acquisition of an overview of the project and tracking progress very easy.

kan også koplast (litt) til mantis...

Also, it's quite simple to write a plugin to redirect ticket references
to your legacy ticket system: e.g. mantis_tickets.py.

ny mantis - utvalg av nye features:

• Wiki Integration (#7075): This involves integration with a Wiki where issues, projects, project versions, and users have Wiki pages.
• project page
• Limit width/height of Image Previews (#6252)
  - It is now possible to configure the maximum width and height of an
  image preview. This is useful for keeping the issue readable when users
  attach big screenshots.
• Screenshots for Mantis (#7053)
  - This is not really a Mantis feature, but a plug-in was developed for
  the free Cropper screen capture tool to simplify the process of taking
  a screen shot, cropping it, compressing it and attaching it to a Mantis
  issue. This tool is for Windows users and requires .NET 1.1 framework
  to be installed.

jf mantis, xp-plan, etc

stikkord: wiki, prosjekt, bugs, estimering, eclipse-plugin, mm

FogBugz

FogBugz is a complete project management system designed to help software teams communicate. It helps them work together by tracking, prioritizing, and coordinating the thousands of small tasks a development team has to do.

godbitar: eclipse-plugin, automatiske release-notes

om estimering

FogBugz displays a probability curve of ship dates
....
it will show you each developer’s ship date graphically so you can find bottlenecks
....
FogBugz combs over historical data to build a statistical model of how good each developer is at estimating
....
By adjusting a slider, you can see how implementing low priority features would change your schedule.

bottlenecks - rett inn på critical chain-tenkning...

ms ie 6 duplicate characters bug

moglege fiksar (av eigen erfaring):

• setja layout på div m/zoom:1
• placeholder-div etter problematisk div

IE Duplicate Characters Bug - CSS fixes and workarounds

Internet Explorer 6 has a puzzling bug involving multiple floated elements; text characters from the last of the floated elements are sometimes duplicated below the last float. This bug is a real headbanger because there seems to be nothing triggering it. However, by now everyone should know that IE needs no excuse to misbehave.
....
any elements .... that don't actually display for some reason [will induce the bug]. Apparently the act of hiding a source element is the critical trigger for this bug.
....

Fixes and Workarounds

One easy fix is to put a -3px right margin on the last left float. The
opposite can be done for layouts with right floats.
....
Another fix is to give the container element 3px of extra width, so that it is 3px
larger than the last float.
....
conditional comments may be used in place of normal HTML comments
....

Special Info

The murky veil surrounding the need for a box dimension to prevent so many IE bugs has been partially lifted, due to the discovery of a heretofore
obscure page in the massive Microsoft website. There is no real explaination of this
"hasLayout" property, but now there is at least some structure to the madness that has been inflicted on us by Microsoft, for what it's worth. Apparently a box needs "Layout" or all heck can break loose, bug-wise. MS does not state that specifically, but their browser behaviors leave no doubt whatsoever.

hasLayout, ms ie-bugs

On having layout — the concept of hasLayout in IE/Win

A lot of Internet Explorer's rendering inconsistencies can be fixed by giving an element “layout.”
....
“dimensional bugs” ... can often be solved by applying a width or height.
....

The hasLayout problem affects designers (and coders) at
all experience levels. Layout has unusual and hard to predict effects
on the display of boxes, as well as implications for their descendant
elements.

Consequences of an element having, or not having “layout” can include:

• Many common IE float bugs.
• Boxes themselves treating basic properties differently.
• Margin collapsing between a container and its descendants.
• Various problems with the construction of lists.
• Differences in the positioning of background images.
• Differences between browsers when using scripting.

slik bør gode utviklere jobbe...

Slik jobber de beste utviklerne - digi.no

En god utvikler holder sin egen kode i hodet ... Det gjør det mulig å bearbeide programmet på en helt annen måte enn hvis man hele tiden er nødt til å skrive ned og lese gjennom koden.
....
[det tar] som regel en halvtime bare å komme inn i rett modus. Det er ikke mulig hvis man hele tiden blir forstyrret .... i et åpent landskap, er dette gjerne en praktisk umulighet.
....
utviklere gjør det best når de får sitte i fred og jobbe mange timer på rad, mens de hele tiden har programmet og alle dets detaljer i hodet. 12 timer er en passe arbeidsøkt, ifølge Graham. Han ser ikke noe galt i å strekke det helt til 36 timer, hvis det føles riktig for utvikleren.

- Hvis man ser på hvordan programvare blir utviklet i bedrifter, ser det nesten ut som om de med vilje prøver å gjøre alt feil
.... organisasjoner stort sett behandler individene som jobber for dem som utskiftbare deler, noe som fungerer bra for parallelliserte oppgaver, som å utkjempe kriger, men som på ingen måte fungerer når det er snakk om å komme opp med gode ideer.

- Det å ha ideer er ikke parallelliserbart, og det er det programmer i virkeligheten er: Ideer
....
Slik bør gode utviklere jobbe, ifølge Graham:

1. Unngå forstyrrelser
   
2. Jobb lange skift
   
3. Bruk kortfattede programmeringsspråk
   
4. Omskriv programmet mange ganger
   
5. Skriv lesbar kildekode
   
6. Jobb i små grupper
   
7. Ikke la flere jobbe på den samme koden
   
8. Start i det små