Microsoft Surface 3

I have recently been blessed at work with a new Microsoft Surface 3, instead of the old PC I used to have (which was 5 years old).

Setup

We are currently using it as a VDI client (which seems a shame, really).

Spec sheet¹

• CPU: 1.9GHz Intel Core i5-4300U (dual-core, 3MB cache, up to 2.9GHz with Turbo Boost)
  
• Graphics: Intel HD Graphics 4400
  
• RAM: 8GB LPDDR3
  
• Screen: 12-inch, 2160 x 1440 multi-touch (ClearType, 3:2 aspect ratio)
  
• Storage: 256GB SSD
  
• Ports: One USB 3.0, Mini DisplayPort, microSDXC card reader (up to 128GB), headphone/mic jack
  
• Connectivity: 802.11ac Wi-Fi, Bluetooth 4.0
  
• Camera: Two 5MP webcams (1080p HD video)
  
• Weight: 1.76 pounds
  
• Size: 7.93 x 11.5 x 0.36 inches (W x D x H)

References

TechRadar - Microsoft Surface Pro 3 review

http://www.techradar.com/reviews/pc-mac/tablets/microsoft-surface-pro-3-1249750/review/2

Professional Scrum Developer I

Well, I managed to get my certification for Professional Scrum Developer on Thursday, the 16th of July 2015. Wasn't terribly hard.

References

Scrum.org

https://www.scrum.org/

PSD I Assessment

https://www.scrum.org/Assessments/Professional-Scrum-Developer-Assessments/PSD-I-Assessment

Professional Scrum Developer I Certification List

https://www.scrum.org/Assessments/Certification-Lists?AssessmentName=PSD%20I

Disappearing Exceptions

Quoting from [1]:

If the catch block completes abruptly for reason R, then the finally block is executed. Then there is a choice:

If the finally block completes normally, then the try statement completes abruptly for reason R.

If the finally block completes abruptly for reason S, then the try statement completes abruptly for reason S (and reason R is discarded).

(Emphasis mine)

	@Test
	public void testExceptionInFinallyBlock()
	{
	try
	{
	throw new RuntimeException("Reason R");
	}
	finally
	{
	throw new RuntimeException("Reason S");
	}
	}

view raw finally.java hosted with ❤ by GitHub

Conclusion

It is unwise to NOT catch Exceptions or throw Exceptions in a Finally block. An exception that is thrown in the finally block, may cause an exception in the try to be discarded. This can lead to errors that obscure the original error.

I can imagine how easy this can happen, for example, if there is an Exception in the try in such a fashion that the closing of resources in the Finally clause will also throw an Exception.

In fact, that is what happened at work, and threw me for a loop when attempting to debug.

Addendum

Luckily, with Java 7², when using the try-with-resources statement, this problem belongs to the past. Of course this only belongs to the past, if your try-catch-finally can be replaced with a try-with-resources.

To be specific, when using try-with-resources only the exception in the try is thrown. Subsequent exceptions, caused by the closing of the resources, are suppressed. But even these exceptions can still be recovered, by requesting all suppressed exceptions from the exception thrown in the try block³.

(Addendum added: 23 july 2015)

References

[1] JLS - 14.20.2. Execution of try-finally and try-catch-finally

http://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html#jls-14.20.2

[2] The Java™ Tutorials - The try-with-resources Statement

https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html

[3] JavaDoc - Throwable.getSupressed()

http://docs.oracle.com/javase/8/docs/api/java/lang/Throwable.html#getSuppressed--

Markdown

This is just here for me as a fancy bookmark, on how to write proper Markdown formatted files for GitHub^{1 2}.

From the source⁵:

Markdown is a text-to-HTML conversion tool for web writers. Markdown allows you to write using an easy-to-read, easy-to-write plain text format, then convert it to structurally valid XHTML (or HTML).

Thus, “Markdown” is two things:

1. a plain text formatting syntax; and
2. a converter which formats the plain text to HTML.

References

[1] GitHub - Markdown Basics

https://help.github.com/articles/markdown-basics/

[2] GitHub - GitHub Flavored Markdown

https://help.github.com/articles/github-flavored-markdown/

[3] Markdown Cheatsheet

https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet

[4] Original Markdown Location

http://daringfireball.net/projects/markdown/

[5] Wikipedia - Markdown

http://en.wikipedia.org/wiki/Markdown

Gliffy vs Plantuml

At work we have used Trac³, especially it's wiki, as well as PlantUML², which fitted seamlessly inside Trac.

Recently we have moved over to Confluence³ and a different diagram tool called Gliffy (which company makes an excellent plugin for adding Gliffy to Confluence)¹.

After working with both PlantUML as well as Gliffy, I thought I'd write down some points in favour of both.

PlantUML

UML Images are generated by interpreting a simple and intuitive language.

Gliffy

a Web-based drawing tool for diagrams

PlantUML

Pro	Con	Comments
Layout is handled by the tool itself	Influence of user on layout is limited	makes it easy to create diagrams quickly
	software with required libraries without UI
possible integration via commandline, for example batch jobs, software buildscripts to generate documentation automatically (javadoc for example)	difficult integration with Confluence
a simple and intuitive language makes it easy to create diagrams quickly	it is a markup language, and therefore more suited to software developers
strong focus on UML	limited number of diagram components, strong focus on UML
very easy to change existing diagrams, even very complex ones

Gliffy

Pro	Con	Comments
Layout can be adapted in every little detail	You get stuck having to draw instead of simply create diagrams	makes it difficult to create or change diagrams quickly
Web tool - no obvious software needs to be installed (only on the server)	Responsiveness is not great in a web browser
excellent integration with Confluence by means of a plugin
even managers might be able to use it	which is a really really bad idea.
lots and lots of diagram components, including UML
	very difficult to change existing diagrams, sometimes things need to be redrawn5

Conclusion

If you wish to draw UML diagrams quickly, and integrate them into your build process, PlantUML is the way to go.

If you need all the flexibility you can get and you don't mind having to draw and layout things yourself, Gliffy is the way to go.

References

[1] Gliffy

https://www.gliffy.com/

[2] PlantUML

http://plantuml.sourceforge.net/

[3] Confluence

https://www.atlassian.com/software/confluence

[4] TRAC - Integrated SCM and Project Management

http://trac.edgewall.org/wiki/TracWiki

[5] impossible to change the type of a component in Gliffy

work around is to delete the entire component, and create a new component of the correct type