The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
As the specs point out, and admirably don't try to hide, there's a 16:1 ratio of distance:measure-spot.
I don't know it's actual operations, but the lasers are only for targeting. It's almost certainly measuring IR emissions from the target area. The columnating optics just aren't the greatest. If you did have your 200m reach (in a sense you do if it is IR radiance) then the spot size would be 12.5m - a bit bigger than your car (I think?) and you'd be averaging in a mass amount of background emissions. The note that it "averages" is just a nice way of spinning of that it's not a pinpoint measurement. For my windows, I stood close.
They also give a little chart about emissivity for various materials. That would take into account the black-body characteristics of the materials. My version just said it's not accurate on certain types of materials. Remember: it's IR not visible light that it's measuring. Your view of the color (glass) and it's perspective will only occasional coincide.
Since you're rolling in cash, you could get an IR imaging system so you can get a 2D view of an area. Particular good for knowing if your woman's 'really in the mood'.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
2006 was an amazing year for Porcini, we picked the whole trunk of the car full. So ok it wasn't the biggest car, but still last for quite a while
And my wife is of the kind that can make a meal out of just mushrooms and butter!
I agree with you all that more than anything it's a workflow issue and now finally I have taken out time to fix the workflow issue once and for all.
I am going through various documentation about SVN workflow best practices and a bit confused what should be the ideal structure.
First I will explain our development environment -
5 developers working from one location and 4 developers working from offshore location. Apart from this 2 product managers may need to push small css changes every now and then like colour change etc
Now my questions are:
1. Should I really consider distributed version control like GIT or stick to SVN as other team members are familiar with SVN more than GIT. So there will be learning curve for all if we switch to GIT also server is all set up for SVN so bit of cost issue as well.
But if it really adds value (like merging is way more easy in GIT) then I am sure I can try to convince to move to distributed version control.
2. If I stick to SVN what is the recommended way to structure Trunk, Branch and Tag?
We have now the same issues somehow. It is getting clearer, that Git wins because it has more advantages because branching and merging is better. And rebasing cleans up with messie trees.
Our tree will be more like different developments trees (sprints) and a master tree, which will get tags. After some discussion we are convinced that branching is temporary because every branch gets (somehow) merged in the master.
Press F1 for help or google it.
Greetings from Germany
Where I work, we used a versioning tool similar to SVN and then we transitioned to GIT mainly due to reliability issues in the tool we used but also somewhat due to merging issues. The learning curve for most of us was steep and there was a lot of training given. For the most part, it seems that we are getting better at using GIT. One of the big advantages is the submodule functionality so that multiple projects can reuse one submodule which may be at different branches at different times. So that allows us to consume submodule changes only when we want to.
Things that GIT doesn't do too well:
1. History is important to us and the GIT merge feature basically rewrites history. So we decided to use only use rebase.
2. We have also had problems when rebasing on top of large number of changes. GIT did not merge/rebase correctly and it didn't give any indication that something went wrong.
3. GIT does not handle binary files very well - uses more space
4. It often happens that 2 developers try to rebase and push their changes at the same time and when pushing, they get an error that their branch is out of date and so they have to do that whole process again. After doing that a few times, I have abandoned the practice to make sure that everything still compiles before pushing. This has resulted in some build instability (not only due to me )
5. It is not easy to find what version of a given file is actually included in a given build without first checking out to the SHA-1 of that build. This is more of an annoyance because you may need to check something while you are in the middle of modifying files. One of my pet peeves with GIT is that you can't tell from two SHA-1's of a file, which is the earlier version.
Having said all that, I would tend to stick with SVN for your situation but that may just be that I'm old school
With regards to the Trunk, Branch and Tag, I would only use a separate branch if there would be a lot of changes made before a new release is ready for the production server. We used a 'development' tag to indicate that a particular file was locally tested and deemed fit for production. This tag is then used to build a stable version of code. Changes could be made to the file and checked in but the development label would not be pulled up until local testing (whatever that entails) has been completed.
I hope this long-winded response helps. All the best with the decisions you need to make.
Last Visit: 21-Oct-20 8:51 Last Update: 21-Oct-20 8:51