-
-
We were hoping to ship one day early but a few delays in getting some updated artwork and some of the upgrade documentation caused us to ship yesterday on the scheduled day. Secret Server has never missed a launch date since first being released in November 2005 - this is something we attribute to Test Driven Development, Pair Programming and an agile planning schedule. Usually this means reducing scope slightly as the launch date approaches - this time we had to drop a fix for supporting backup when SQL Server is not on the IIS box but it will come in an update in early January.
So what is new in 4.0?
Theming
Theming allows you to create your own company theme for Secret Server - this was a popular request with customers.
We also shipped two new themes with 4.0 - Blue Chrome and Corporate.
Inherited Permissions on Folders
Managing permissions on secrets and folders is tedious. 4.0 brings permission inheritance across secrets,sub-folders and folders. This makes it possible to specify who has access at a high level and allow those rights to cascade through the hierarchy.
Additional Highlights
- Optional, customizable Login Policy Statement for corporate environments
- Migration from the Microsoft .NET Framework 1.1 to 2.0
- Ability to search by sub-folder
- More...
Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC. Our product, Secret Server is a enterprise password manager system for teams to secure their passwords. Is your team still storing passwords in Excel?
-
-
What does your code terrain look like? Are there bodies of dead logic lying here and there? Maybe they helped briefly while you worked towards a better solution or perhaps they just fell victim to changing business rules.
At a recent Code Camp, there was a question about code generation and I answered that we (as developers) are required to love every line of code (it drew a laugh from many). But love isn't cheap ... it takes time, care and hard work. Therefore we should only love and care for the lines of code that we absolutely need. Anything not being used should be removed.
What excuses are there to keep unused code?
- We may need it in the future
- The classic argument - the typical agile response being YAGNI.
- Keeping it in the code-base takes maintenance in the form of understanding it, updating associated tests and working around it to add other functionality.
- It will always remain in source control should we ever need it again
- If it ain't broke, don't fix it.
- Bob Martin sums this up well when he defines what "broke" means: Code should 1) work 2) be maintainable and 3) communicate its intent. Clearly dead code violates 2 and 3.
- This idea also defeats the goal of loving every line of code - leaving something alone for no good reason is neglect.
I just spent a good half hour cleaning up some code and mostly removing unused code. It was annoying since it wasn't even being used but at least I am happier with the code now. A good tool when investigating code you suspect may be dead is ALT-F7 using Jetbrains Resharper - you can easily find all usages of a method or class even in large code-bases. A cheap alternative is to use "lean on the compiler" (as discussed by Michael Feathers) - this is simply changing a class name or method name by one character and try to compile (the compiler will then let you know what is depending on that code).
Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC. Our product, Secret Server is a enterprise password manager system for teams to secure their passwords. Is your team still storing passwords in Excel?