Announcement: propertyset-storage-toolkit plugin has been released

Hi folks,

I assume many of you are Jira developers and I think I will express the overall feeling that configuration data storage in the Jira is a tricky moment many of you spent a lot of time on.

propertyset-storage-toolkit - is plugin to rescue from boilerplate configuration data storage coding. The plugin itself is more like library for configuration data persistence and retrieval (and a sample application along to start rolling).

Hopefully you will find it as useful as I do. The reason for me of creating one is - to help newcomers come on board the Jira Plugin Development process.

This said, here theere are list of feature available:

• Database persistence using PropertySet for underlying data storage
• Has no additional JIRA dependencies and provides enhanced PropertySet API sub-set
• Could be used both as JAR dependency bundled with your plugin OR as separate plugin, depending one your current needs.
• Provides a rich set of out-of box list of Scope objects. (Scope defines the sandbox of the PropertySet storage instance). At the moment following configuration options are supported

If you are interested to use, provide a feedback, review or any type of comments - you are always welcome to contribute.
Readme file is your place to start.
Hopefully with the help of you guys, will end-up with something really useful.

PS> Really enjoyable and productive weekend at the end of the day 

Jira - How to Include JSS and CSS resources on every page

Hi all,

Unit tests, What they should be like? (2)

My humble opinion only

Automated Tests, Unit tests, Pros (1)

• Improves design.

At least +1 client, decoupling from the Application.main([]) method.

• Regression tests, cost of running them VS cost of manual retesting.
• Difficult to test by mortal hand areas

(multi-threading issues, timing, DB connectivity loses). As extra point, the cost of such hand-made tests are extremely high and won’t disappear on 2nd/3rd/… run. Not my opinion, but I share this point of view

• Easier to explore internal (unclear from user point's of view) Grey Areas or Unpredictability Corners (more commonly known as old plain Boundary Values).

It’s not always clear from User Story or User Interface that the boundary values would be, or other subsystem boundary values influence on this particular component. Or the boundary value application will eventually hit is very-hard to prepare by mortal hand. For example tester should repeat Long.MAX_VALUE operations to hit this one.

Google Best Practices

See Presentation: Agile Project Management: Lessons Learned at Google.
From a lot of another parts, one item which grabbed my attention:
At Google - they have per-person wiki/html page to list the work they are doing now and their plans for the next 3 months. It “helps to share the information and find the right person for the right job/ask question” …

I think it’s a wonderful idea an every company which has internal KMP (Knowledge Management Portal) or smth like that should follow this practice. Not making devevlopers to follow this one, but just suggest this. Who knows, may be their staff will like that and theit internal processes and communication will rock :)