yoy.be "Why-o-Why"

2018 ...

januari februari (2) maart (2) april (2) mei (2) juni (3) juli (4) augustus (3) september (3) oktober (2) november (3) december (3)

GMail: make the labels list compacter

2018-06-08 10:32  GMailLabelsCompacter  coding internet werk  [permalink]

If you remember from before, I have so much labels in GMail that I didn't like that the box to change the labels on a message with, is so small. Stylus to the rescue.

Now there's this new GMail design, and even in compact display, the list of labels on the left doesn' fit my screen. Also I don't like the font the subject line is rendered in. So a bit of inspection later, I add these lines to my overrides:

.z0 {
  margin: 0px;
  height: 32px;
  padding: 0px 0px 0px 64px;
}
.z0>.L3{
  height:24px;
}
.ha>.hP {
  font-family: "PT Sans", sans-serif;
}
.aim {
  height: 18px;
}
.J-N {
  padding: 0px 12px 0px 32px;
}
.J-LC
{
  padding: 0px 12px 0px 48px;
}

→ twitter reddit linkedin facebook

Delphi project and subversion: set the build number to revision number

2018-06-09 09:37  dsvnbuild  coding delphi werk  [permalink]

At work, we have a number of interrelated projects in a single subversion repository. We've agreed to change the build number in the project's version properties to the current revision number of your work folder. And specifically not the revision number you might predict your changes will land in when you commit them.

We're currently a rather small team so it may be tempting to assume you'll just get the next revision number, but we stress newcomers to ignore that urge. As long as we're a small team, this works manually, but if we grow we should move over to scripted version resource entries and commit hooks that update the build number automatically.

So with a major and minor version of 2.0 for example, and a release number of 8, the full version could look like "2.0.8.51873".

This way of working has a number of advantages.

The binaries that get used in production, but exert a bug in their behaviour, show with their full version number (and the previous version number from before the bug occurred) the vicinity of revision numbers that introduced the code change that may lay at the cause of the bug. To get the exact revision number, you need to look up the SVN log (or blame) of the .dof or .dproj file, but it's quite sure it's a number closely above the number in the version. We've stressed second line support personnel to list this number when reporting the bug, which helps when researching reproducibility.

But even long before that, when it happens two (or) more of us inadvertently make changes to the same project, we either started from the same revision number in the work folder and see when comitting that something has to get merged and it does so automatically or we get a merge conflict; or we started from different revision numbers and get a conflict right away or a message that we're over due for an update to or work folder.

As I said we're a small team for the moment and it rarely happens so it saves us an update task with risk of conflict before we commit, and in general we can split the work that needs to be done between us so we shouldn't make changes to the same projects.

Then again, if the team would ever grow to something like really big, we would probably have to switch to something else than subversion, or even repositories per project, who knows...

→ twitter reddit linkedin facebook

DirDiff v2.0.4.535

2018-06-23 00:31  dirdiff535  freeware  [permalink]

→ DirDiff v2.0.4.535

There was a bug when diff-ing more than 2 files or folders, where lines matching between other files than the first/left one would show as matched.

→ twitter reddit linkedin facebook