Configuring SONAR with Maven on Mac

I had this issue a few times:

  • you get SONAR installed and the web client working fine (e.g. you can go to http://localhost:9000 and see the dashboard).
  • you have a project to analyze with a Maven POM, to which you add the sonar target as described here.
  • you start the Maven run and it returns in short order saying:

Can not execute SonarQube analysis: Unable to execute Sonar: Fail to download [http://localhost:9000/api/server].

Turns out for some reason this is a problem with the default Ruby install on OSX. The workaround is to use JRuby instead of Ruby, best done with RVM, e.g. rvm use jruby. Someone mentioned this online, and I cannot find the post now, but thanks.

I use Sonar with Homebrew, by the way, which has its log files at /usr/local/Cellar/sonar/<version>/libexec/log/sonar.log.

Leave a comment

Filed under Uncategorized

The Circle, a novel

The Circle is a novel about the tech/social networking industry, where fictional company the Circle plays the role of Twitter, Facebook and Google combined. The topic is certainly ripe for the satirizing, but I didn’t think Eggers pulled it off very adroitly. Either he was going for the brutal, over the top parody like Jonathan Swift’s A Modest Proposal, or he was writing it very quickly and perhaps in anger. The characters felt a little flat and one-dimensional (Mae for example was unbelievably naive) and the conspiracy (or ‘logical extension’ perhaps) was hard to believe—Americans are fiercely proud of being independent and private, so the idea that they would willingly join in with mandatory Circle membership felt off. 

Some points I thought were well made. For example, the skewering of the “campus culture” of tech companies which privileges the already-privileged while the drivers of the busses and local inhabitants are worse off. The technocrats who think technology presents a simple solution to all problems (witness the Gates Foundation and educational testing, for example) are an unfortunate reality today. Parts of the book raised good and thought-provoking questions about understanding social media tradeoffs. Some of the reasons why privacy is important are really poorly outlined (but perhaps the question is wrong on its face—why should I justify my need for privacy?). There really are things that technology has improved dramatically—every time I use Skype with my parents I realize this. Tracking my friends on Facebook is a nice thing to do and brings them more into my life as well. 

I appreciated that aspect of the novel, and it has given me a new perspective on being a ‘user’/’product’ of social media tools. Overall, this is a topic that cries out for a sustained and subtle approach and I felt The Circle was too facile and, for the Valley cognoscenti who most need it, too easy to dismiss. By the way, there is a certain irony in posting my thoughts about this novel online, but doing so on my own blog feels somewhat different. I hope. 

Leave a comment

Filed under Uncategorized

13 Great Software Architecture Papers

In the paper “The Past, Present and Future of Software Architecture”, the authors (Philippe Kruchten, Henk Obbink, and Judith Stafford) have a sidebar in which they list their selection of “Great Papers of Software Architecture”. I’ve tried to collect these papers and links thereto for future reading. Here is a bibtex file for full citations. I’ve also included the parenthetical comments of Kruchten et al. in italics, and my comments in bold. Unless otherwise noted I’ve linked directly to the PDFs (please let me know if a link breaks).

Foundations

Precursors

Architectural views

  • D. Soni, R. Nord, and C. Hofmeister, “Software Architecture in Industrial Applications,”This article introduced Siemens’ five-view model, which the authors detailed in their 1999 book Applied Software Architecture
  • P. Kruchten, “The 4+1 View Model of Architecture,”Part of the Rational Approach—now known as the Rational Unified Process—this set of views was used by many Rational consultants on large industrial projects. Its roots are in the work done at Alcatel and Philips in the late 1980s.

Process and pragmatics

  • B.W. Lampson, “Hints for Computer System Design,” This article and the next gave one of us (Kruchten), a budding software architect in the 1980s, great inspiration. They haven’t aged and are still relevant.
  • J.A. Mills, “A Pragmatic View of the System Architect,” paywall
  • W.E. Royce and W. Royce, “Software Architecture: Integrating Process and Technology,” —This article articulates the connection between architecture and process very well—in particular, the need for an iterative process in which early iterations build and validate an architecture. Not online, sadly.

Two more for the road

Leave a comment

Filed under Uncategorized

Virtual Conferences

The virtual conference has many benefits in terms of GHG emission reductions, cost savings, and accessibility. Jon Pipitone and Jorge Aranda co-organized a very small event with me in 2011 around climate change and software. We used Skype and instant messaging to connect climate researchers with software researchers, but my feeling afterwards was that virtual worlds like OpenSim were the way to go. 

It’s cool to see Crista Lopes has managed a relatively large-scale event. 

Leave a comment

2013 September 11 · 13:31

Knowledge and complexity

Somewhat inspired by +Rob England, I tried a mapping of Rumsfeldian terminology to Cynefin (yes, i know this predates the SecDef!).

Known knowns – either a simple or complicated case. If simple, we do it routinely. E.g. landing an aircraft in good weather.

Known unknowns – we have a plan for accommodating it. E.g. landing an aircraft in Edmonton with high crosswinds.

Unknown unknowns – we are in a complex domain and we have to see how things should work with experiments e.g. edge of envelope flying. One of the things that the Kennedys made clearer for me is how experiments have to be well conceived, in particular, by controlling variables properly (see their SysEng Journal paper).

Unknown knowns – we didn’t realize we could plan for this but now that we sense it, we can delegate to existing routines, or perhaps adapt to it. That pathway is available but unused. The example would be .. looking through the manual and realizing the system can actually do this (maybe the Apollo 18 case? There they did the exaptation that Snowden often mentions.)

Snowden would no doubt criticize my limited understanding, but there is some use in seeing how these frameworks co-exist, for me at least.

Update: Dave Snowden replies with a pointer to his HBR article with Cynthia Kurtz in which “knowns” are discussed. Summary: simple contexts are the domain of known knowns, complicated contexts are the domain of known unknowns, since experts are required. Unknown unknowns are the domain of complex contexts. Interestingly, they categorize the Apollo 13 case as being in the complex context. In the sense that there was no clear answer, that makes sense, but to me, it also highlighted that idea of unknown knowns: that is, these skilled engineers did “know” the answer (since the astronauts survive), but not consciously. So we could perhaps characterize that as relying on the “expert within”.

Leave a comment

Filed under Uncategorized

Some Advice on Doing a PostDoc in Software Engineering

Post-doc positions in CS are a growing part of the research landscape, as seen in this figure from the CRA:

CRA 2011 Research positions

So if you are a senior doctoral student, should you take a post-doc offering? Herewith a few tips based on my own experience (7 year doctoral student in Toronto, 1.5 years postdoc at UBC, now with SEI as researcher).

1. Figure out your long-term goal. Do you want a research intensive faculty post? Or a teaching-intensive job? Industrial research lab? Industry development job? I would not bother with a post-doc if I wanted a programming job (even a PHD is a hindrance here, in most cases).

2. Think about networking. Most of the people who get the top jobs in the field are well-connected to the main community, via supervisor connections, industry internships, collaborations. You will need to secure 3-4 people who will write highly of you. You need to get onto the short list. I am assuming you already understand what the bar is for high quality research.

3. Avoid teaching positions if you want to do research, and vice-versa. I did a dual position, and while I love teaching, research suffered. There is plenty of time to think about teaching later, and in my experience, top research schools almost never ask about teaching experience. On the other hand, if you apply to teaching universities, then demonstrable ability to manage a large class should serve you well, as will good evaluations.

4. Evaluate how well the position will accommodate your existing research contributions. You simply do not have time in the standard 2 year postdoc to shift your research interests dramatically. To me this is one big difference with life science postdocs, where you get lab experience and the positions are typically for 3-4 years. Ideally, you will be able to submit to ICSE, CAV, FMCAD, PLDI etc. immediately after starting. I’m not convinced that hiring committees are at all sympathetic to *any* gaps in your publication record.

5. Be realistic about the quality of the lab’s past research. Are they publishing in the top venues? Is there a history of collaborative work, where you might be able to tail along on a paper as you start your post?

6. Finally, all the other criteria: is it a nice city? Are the people friendly? What is the salary? 50K Canadian is at the upper end for most positions.

These tips are mainly pragmatic and from a research hiring point of view, where the main reason to do a post-doc is to improve your publication record and increase your social network. That being said, one of the things I most liked about my postdoc was meeting and working with great people. That sticks with you longer than any paper submissions will.

EDIT: I’ve been reminded of another criterion, namely, does your partner (if any) support your decision!

2 Comments

Filed under Uncategorized

The fuzzy notion of “business value”

Software development is rife with references to business value, particularly in agile approaches: the Agile Manifesto declares that “Our highest priority is to satisfy the customer
through early and continuous delivery of valuable software.”

The trouble is that it isn’t clear what ‘valuable’ means. I’m sure that the point of this phrase, as with most of the Manifesto, is to start a discussion rather than to behave as a prescriptive methodology. I believe “value” is inherently context-dependent, so in that sense it is reasonable to leave it vague.

On the other hand, many people refer to business value as the Holy Grail of software development: this is what you are supposedly optimizing in Scrum. Other methodologies help focus on “impact”. Lean approaches have one remove ‘waste’ from the value stream. And yet no one has ever pinned value down, as Racheva et al. have shown [1] (in the software domain, anyway – many attempts have been made in economics).

Business value does have the nice property of communicability, though. It gives developers that one number to sell the project to the business, and allows for a conversation about scope, cost of delay, and prioritization that is difficult to do with purely qualitative methods. And for the mathematically inclined, it lends itself to algorithms like linear programming for optimization.

One paper does try to break business value into more reasonable components, which I quite liked. It is by Heidenberg et al. [2]. They break business value into five dimensions, each of which is ranked on an ordinal scale with four possible categories:

  1. Monetary Value – this is the number calculated by, say, a business analyst.
  2. Market Enabler – does delivering this feature create new market opportunity?
  3. Technical Enabler – does this feature help prepare the company for other features?
  4. Competence Growth – measures how much the work will improve the team’s skill.
  5. Employee Satisfaction – do the developers like working on this feature?
  6. Customer Satisfaction – how much will customers appreciate this work?

One of the big problems with agile planning is that making categories 2, 3, 4, 5 visible is often hard. It is comparatively easy to sell a customer a feature that ranks highly in monetary value or customer satisfaction – these are the slick and cool UI widgets, the mission-critical Word reporting function, and so on. But making architectural work (category 3) visible is very challenging. If we had this six-factor model, prioritizing important architectural work would be easier.

[1] Z. Racheva, M. Daneva, and K. Sikkel, “Value Creation by Agile Projects: Methodology or Mystery?,” presented at Product-Focused Software Process Improvement, 2009, vol. 32, no. 12, pp. 141–155.

[2] J. Heidenberg, M. Weijola, K. Mikkonen, and I. Porres, “A Model for Business Value in Large-Scale Agile and Lean Software Development,” presented at EUROSpi: Systems, Software and Services Process Improvement, 2012, pp. 49–60.

2 Comments

Filed under Uncategorized