Our fifth grandchild is coming. Even as I write this, Erin is at the hospital in sore travail. Julene and I will drive up to Salt Lake City this evening to see what we may.
We're excited to welcome this little munchkin into our lives!
Tuesday, May 31, 2011
Lady Lennon is arriving!
Our fifth grandchild is coming. Even as I write this, Erin is at the hospital in sore travail. Julene and I will drive up to Salt Lake City this evening to see what we may.
We're excited to welcome this little munchkin into our lives!
Defeat reversed...
Some time ago I wrote that Defeat is inevitable when dealing with oven manufacturer JennAir.
Last week, I hit KSL-TV's classifieds list and purchased a five-year old, little used GE built-in oven to replace my prized JennAir. I dropped it in last Saturday with my youngest son. It took all of 20 minutes and we were puttering. Four twists of the wire nuts.
The new oven is a couple of inches narrower than the old one. This means I'll have to go back with a piece of maple to close the gap in the cabinet.
The new oven is pretty nice. Other than being narrower than a nominal 27" oven (as was the last one), its features measure up including the (missing) meat probe. I wonder if the one I conserved from the JennAir won't work? Convection, programmable, etc. all the features are there.
As I said last time, I will never buy a JennAir again. And I saw plenty to choose from in the classified offerings.
Monday, May 23, 2011
Eclipse and sources under control...
Of late, I've set up a team source code-control repository from scratch for my work group. This is the first time I've done this for anyone but myself; it's always already been done by the time I joined a team. I haven't been too pleased with the uncertainty at the places I've worked so far--always policy, but never understanding why that policy. Hence my saying something to clear the smoke. There are two camps out there on the web: one for committing the hidden files to source-code control and the other for not committing them. Both are wrong in my opinion.
It seems clear now to me that the following should be the way to do things regarding the “hidden” files in the Eclipse project source base. I'm using Git; the same holds for CVS and Subversion.
.project
It appears you don't want to commit .project to source-code control. You want to create the initial project, then make a copy of this file as .project.sample, and commit that. As each checks out the project source, he or she copies .project.sample to .project, then imports the project in Eclipse.
.gitignore
.project should be marked “ignore” by listing it in the .gitignore at the root of the project. Also in this file are build, bin, etc. since we do not want to include build subdirectories and .class files. I think it’s not a bad idea to include the ignore file, but by doing so, we’d be precluding that anyone maintain a separate, different copy.
.classpath
This is modified by each user's Eclipse, but only when changes such as the addition of a new JAR are made. Therefore, this file should be committed. However, care must be taken not to corrupt this file by adding JARs just any which way.
Addition of new JARs
This must not be done except via copying the new JAR to an internal subdirectory such as WebContent/WEB-INF/lib or other adding via Build Path -> Configure Build Path -> Libraries -> Add JARs (and never Add External JARs).
This ensures a) that the JAR is in the project (there might be a reason not to do it this way with ivy: there certainly is with Maven, but I'm talking old-fashioned stuff here) and b) no full path is added to .classpath.
It's a simple matter thereafter to check out the project (git clone, svn co, etc.), copy .project.sample to .project, then import into Eclipse (File -> Import -> General -> Import existing...) and away you go.
While there are somewhat analogous things going on in NetBeans, and they just may have done it the right way, nevertheless, Eclipse rules. Yes it does.
August 2011 update:
There's little to add except that based on some really bad experiences, I've learned that you absolutely do want to keep the .settings subdirectory under source-code control (in Git or anything else). At very least, the Eclipse Dynamic Web Project is so complex, that gone missing what's in there will make sharing a project pretty much impossible. I tried doing it and not doing it. This is what I learned.
It seems clear now to me that the following should be the way to do things regarding the “hidden” files in the Eclipse project source base. I'm using Git; the same holds for CVS and Subversion.
.project
It appears you don't want to commit .project to source-code control. You want to create the initial project, then make a copy of this file as .project.sample, and commit that. As each checks out the project source, he or she copies .project.sample to .project, then imports the project in Eclipse.
.gitignore
.project should be marked “ignore” by listing it in the .gitignore at the root of the project. Also in this file are build, bin, etc. since we do not want to include build subdirectories and .class files. I think it’s not a bad idea to include the ignore file, but by doing so, we’d be precluding that anyone maintain a separate, different copy.
.classpath
This is modified by each user's Eclipse, but only when changes such as the addition of a new JAR are made. Therefore, this file should be committed. However, care must be taken not to corrupt this file by adding JARs just any which way.
Addition of new JARs
This must not be done except via copying the new JAR to an internal subdirectory such as WebContent/WEB-INF/lib or other adding via Build Path -> Configure Build Path -> Libraries -> Add JARs (and never Add External JARs).
This ensures a) that the JAR is in the project (there might be a reason not to do it this way with ivy: there certainly is with Maven, but I'm talking old-fashioned stuff here) and b) no full path is added to .classpath.
It's a simple matter thereafter to check out the project (git clone, svn co, etc.), copy .project.sample to .project, then import into Eclipse (File -> Import -> General -> Import existing...) and away you go.
While there are somewhat analogous things going on in NetBeans, and they just may have done it the right way, nevertheless, Eclipse rules. Yes it does.
August 2011 update:
There's little to add except that based on some really bad experiences, I've learned that you absolutely do want to keep the .settings subdirectory under source-code control (in Git or anything else). At very least, the Eclipse Dynamic Web Project is so complex, that gone missing what's in there will make sharing a project pretty much impossible. I tried doing it and not doing it. This is what I learned.
Monday, May 2, 2011
With Usama bin Laden gone, ...
...it will be up to the State Department or someone deeper in the soup to pick the next object on which to focus our attention in order not to see the sleights of hand.
Our lives would be such bliss were the foundation of such only so simple a thing as to find and assassinate worms like bin Laden.
The whole aim of practical politics is to keep the populace alarmed (and hence clamorous to be led to safety) by menacing it with an endless series of hobgoblins, all of them imaginary.
H. L. Mencken
Our lives would be such bliss were the foundation of such only so simple a thing as to find and assassinate worms like bin Laden.
Subscribe to:
Posts (Atom)