Rock Pi S Review

Christof Meerwald from cmeerw.org blog

Got a $20 voucher code for a review of a Rock Pi S SBC. Although the cost of the board is only $13.90, with shipping at just over $8, it's a bit over $22 in total. When the board arrived, I did actually wonder if shipping could have been made a bit more economical by not putting the tiny board into a huge box (175 mm x 115 mm x 95 mm) which had a plastic case (70 mm x 50 mm x 25 mm) with the board in it.

Anyway, two things to note about the board are that the serial console uses 1.5 Mbps (which is different to the more common 115200 bps used by other boards), and uses a USB Type C connector for power (like the Raspberry Pi 4, but unlike older SBCs).

Downloading the Ubuntu image and writing it to a SanDisk Ultra 16 GB MicroSD card seemed to work fine to get it to boot. One thing I did notice was that the SSH server keys seemed to have been written to the image and not regenerated on first boot. The other thing to be aware of is that the kernel being used is fairly old (4.4.143) with mainline kernel support only starting to appear now.

One thing that appears strange to me is that total memory is only shown as "MemTotal: 432280 kB" - I am not entirely sure what this isn't (much) closer to 512 MB.

Finally, power consumption seems to be quite good. With WiFi turned on, but otherwise completely idle, my USB tester shows the device using only around 0.2 W. Doing a "ping" and it will go up to around 0.36 W. Reading from the MicroSD card also uses around 0.4 W. Keeping all 4 cores of the CPU busy and power consumption goes up to around 0.85 W.

Source code chapter of ‘evidence-based software engineering’ reworked

Derek Jones from The Shape of Code

The Source code chapter of my evidence-based software engineering book has been reworked (draft pdf).

When writing the first version of this chapter, I was not certain whether source code was a topic warranting a chapter to itself, in an evidence-based software engineering book. Now I am certain. Source code is the primary product delivery, for a software system, and it is takes up much of the available cognitive effort.

What are the desirable characteristics that source code should have, to minimise production costs per unit of functionality? This is what an evidence-based chapter on source code is all about.

The release of this chapter completes my second pass over the material. Readers will notice the text still contains ... and ?‘s. The third pass will either delete these, or say something interesting (I suspect mostly the former, because of lack of data).

Talking of data, February has been a bumper month for data (apologies if you responded to my email asking for data, and it has not appeared in this release; a higher than average number of people have replied with data).

The plan is to spend a few months getting a beta release ready. Have the beta release run over the summer, with the book in the shops for Christmas.

I’m looking at getting a few hundred printed, for those wanting paper.

The only publisher that did not mind me making the pdf freely available was MIT Press. Unfortunately one of the reviewers was foaming at the mouth about the things I had to say about software engineering researcher (it did not help that I had written a blog post containing a less than glowing commentary on academic researchers, the week of the review {mid-2017}); the second reviewer was mildly against, and the third recommended it.

If any readers knows the editors at MIT Press, do suggest they have another look at the book. I would rather a real publisher make paper available.

Next, getting the ‘statistics for software engineers’ second half of the book ready for a beta release.

All about Agile on the Beach

Allan Kelly from Allan Kelly Associates

This week has been a bit of a feast about Agile On the Beach. So here is a list of this weeks writing and some previous posts.

And some older entries that explain us:

This possibly shows that AOTB takes up far more of my life than it should! 🙂

The post All about Agile on the Beach appeared first on Allan Kelly Associates.

Mimas is OpenSource

Allan Kelly from Allan Kelly Associates

256px-Mimas_Cassini-2020-02-24-11-36.jpg

That picture above is Mimas, one of the moons of Saturn – yes, I’m still a bit of a “geek”. Mimas is the name I chose for the Agile on the Beach submission system I started developing about four years ago.

I am a bit surprised that Mimas has grown to over 10,000 lines – mainly Python and HTML, a very small amount of JavaScript and a super tiny bit of CSS. O, and 239 unit tests which now take about 8 second to run. (Like so many other systems the front end isn’t covered by automated tests. This hasn’t been a big problem, the tests I have giv great confidence.)

I’m not completely surprised by the fact that four years later we are still using it.

The code has lots of failings – doesn’t every system? – but I’m immensely proud of it as more than I’m embarrassed by it. I’m particularly proud of the way the system held up to 300 submissions and 55 reviewers this year. This was the most use it has ever had.

As of last month the system is also OpenSource – MIT License. You can browse the code – and tell me about all my failings: Mimas on GitHub.

The system itself runs on the Google App Engine here. Anyone can log in and create their own conference. Although this being the post-review period, and me having some time, I’m taking the opportunity to make some improvements. If it is down it won’t be down for long. Unfortunately Google are forcing a database upgrade (NDB to Cloud NDB) on a move from Python 2.7 to 3.x (which I should have done a while back.)

Once upon a time I thought that other people might like to use the system for their conferences but nobody ever has. The offer is still there.

I’d love it if anyone else wants to help with development on the system – but I’m realistic to know this is unlikely. (If you want to help there are a lot of places in the UI where a little JS or CSS could improve things. In the backend I know a few places that could do with changes too.)

For the record this is what Mimas does:

  • Conference organisers create a conference and accept submissions.
  • Speaker details are retained for future conferences as are talk details.
  • Submissions are accepted into tracks, they can have co-speakers, formats and duration are configurable.
  • Two rounds of reviewing are supported, these are configurable. AOTB uses scoring for round 1 and ranking for round 2.
  • Reviewers can volunteer and be assigned (random) submissions to review.
  • Conference permissions allow for different users to have different capabilities.
  • E-mail acknowledgements, acceptances and declines are handled via SendGrid – you can also define custom messages via templates.
  • Half a dozen or more types of report plus export to Excel capability.
  • OAuth login currently supporting e-mail, Google and Facebook via Firebase.
  • Share reviewer feedback and comments with submitters.
  • Some conference branding.
  • (There is an open speakers directory and tagging mechanism, I should either improve this or scrap it.)

I’m currently building out a scheduler so the accepted submissions can be organised in the system too. Its half done.

There are bunch of ways I could develop it further: it could support paper review rather than conference review, it could support shepherding, it could be used for reoccurring events, and a whole lot more.

Finally, it is surprisingly cheap to run on the Google App Engine.

Anyway, its OpenSource, its live, let me know what you think.

The post Mimas is OpenSource appeared first on Allan Kelly Associates.

The wisdom of the ancients

Derek Jones from The Shape of Code

The software engineering ancients are people like Halstead and McCabe, along with less well known ancients (because they don’t name anything after them) such as Boehm for cost estimation, Lehman for software evolution, and Brooks because of a book; these ancients date from before 1980.

Why is the wisdom of these ancients still venerated (i.e., people treat them as being true), despite the evidence that they are very inaccurate (apart from Brooks)?

People hate a belief vacuum, they want to believe things.

The correlation between Halstead’s and McCabe’s metrics, and various software characteristics is no better than counting lines of code, but using a fancy formula feels more sophisticated and everybody else uses them, and we don’t have anything more accurate.

That last point is the killer, in many (most?) cases we don’t have any metrics that perform better than counting lines of code (other than taking the log of the number of lines of code).

Something similar happened in astronomy. Placing the Earth at the center of the solar system results in inaccurate predictions of where the planets are going to be in the sky; adding epicycles to the model helps to reduce the error. Until Newton came along with a model that produced very accurate results, people stuck with what they knew.

The continued visibility of COCOMO is a good example of how academic advertising (i.e., publishing papers) can keep an idea alive. Despite being more sophisticated, the Putnam model is not nearly as well known; Putnam formed a consulting company to promote this model, and so advertised to a different market.

Both COCOMO and Putnam have lines of code as an integral component of their models, and there is huge variability in the number of lines written by different people to implement the same functionality.

People tend not to talk about Lehman’s quantitative work on software evolution (tiny data set, and the fitted equation is very different from what is seen today). However, Lehman stated enough laws, and changed them often enough, that it’s possible to find something in there that relates to today’s view of software evolution.

Brooks’ book “The Mythical Man-Month” deals with project progress and manpower; what he says is timeless. The problem is that while lots of people seem happy to cite him, very few people seem to have read the book (which is a shame).

There is a book coming out this year that provides lots of evidence that the ancient wisdom is wrong or at best harmless, but it does not contain more accurate models to replace what currently exists :-(

Fruitful Opals – baron m.

baron m. from thus spake a.k.

Greetings Sir R-----. I trust that I find you in good spirits this evening? Will you take a glass of this excellent porter and join me in a little sport?

Splendid!

I propose a game that is popular amongst Antipodean opal scavengers as a means to improve their skill at guesswork.
Opals, as any reputable botanist will confirm, are the seeds of the majestic opal tree which grows in some abundance atop the vast monoliths of that region. Its mouth-watering fruits are greatly enjoyed by the Titans on those occasions when, attracted by its entirely confused seasons, they choose to winter thereabouts.

Why does AOTB have its own submission system?

Allan Kelly from Allan Kelly Associates

256px-Mimas_Cassini-2020-02-19-15-13.jpg

Anyone who has submitted to Agile on the Beach in the last few years will have used our submission system: Mimas. Like so many other conference we, or rather I, created our own system.

“Why does AOTB have its own submission system?”

Flippant but true answer: because nobody else (yet) has decided to share out system. I’m more than happy to host other conferences

Perhaps the actual question should be:

“Why create your own system when there are others out there?”

Yes, good question. Well, two (plus one) reasons really.

One: About five years ago when I got fed up of the Heath-Robinson combination of Excel sheets, Google sheets, HTML and a little Python that I was using nothing fitted. If I recall correctly Papercall was just started. While many commercial conference management systems had a synopsis module most of these didn’t do public call for papers and they cost money. I thought about using CyberChair/EasyChair but these are quite off-putting and needed hosting.

Things have changed a bit now so I might not make the same decision today.

Two: I was really very keen to give submitters feedback on their submissions and this was missing from most systems. This is an agile conference and agile is all about feedback so we should give feedback shouldn’t we?

Hillside’s Pasture can do this but is quite a niche system and I’m not sure it could handle the load we get. Similarly the Agile Alliance have a system for their conferences which gives feedback but having submitted I wasn’t impressed.

So that was then. What about today?

Having our own system has allowed us to do things we wanted: like a public review with over 50 reviewers this year. Or changing the voting system.

Of course that comes at a cost: my time to change the system, my stress in keeping the system up (a lot lately). O, there are some charges for the Google Cloud but these are trivial, a less than $1 a year and most of them are down to one report I run repeatedly during the review processes.

Those might be reasons for keeping Mimas but really my overhead should encourage me to kill it. Of course, I’ve grown to love my code and while I admit is stinks in places (the look of the UI) I’m proud of it.

But, the over whelming reason right now for not moving to Papercall (or similar) is: Speakers.

There are more speakers and potential speakers than conferences. Possibly the money to be made from a conference submission system is not from the conference organisers but from the speakers who want to submit to conferences. A bit like advertising the service could be provide for free to conference organizers if submitters paid a subscription.

And I have met speakers who tell me the go to Pepercall (or whatever) and submit to conference X. Then look down the list of other conferences they fancy and make the same submission multiple times. That is valuable to potential speakers.

But, that ease of submission is a problem for organizers. Particularly organizers who want to give feedback.

Easy submission for speakers means more work for reviewers.

As a conference organizer I don’t want every Tom, Dick and Harry submitting to my conference. AOTB already has about 300 submissions a year, and as I’ve noted before some of these smell as if the submitter really doesn’t know much about us and hasn’t thought through the submission.

The interests of speakers and organizers are not aligned.

One way of solving this problem would be for conferences to share reviews. So if a speaker submits, say, to AOTB and Agile Cambridge and Agile Alliance then each conference can see what others thought of the submission. I could imagine that working.

I can also see obstacles. First of all: data privacy.

More troublesome I wonder if that would actually make it more difficult for new speakers to break in. The same old hands, with the same good reviews, would come to dominate the conference circuit and new ideas wouldn’t get in.

So there you go. AOTB has its own submissions system and I’ll tell you more about that next time.

The post Why does AOTB have its own submission system? appeared first on Allan Kelly Associates.

Notes on Agile on the Beach submissions

Allan Kelly from Allan Kelly Associates

More notes on Agile on the Beach – this is going to go on all week, sorry but there is a lot to get on the record. Maybe only conference-geeks and those thinking of submitting to AOTB will find useful but I’d like to get it on the record and this is my blog 🙂

First off the Agile on the Beach is pretty much the same every year. Unfortunately it has grown over the years as we try and share more information with those submitting. I expect most conferences have the same problem.

Problem #1 the call for submissions is too big, problem #2 people don’t seem to read it. Actually, it is not just that people don’t read it but some people who submit don’t seem to know much about the conference.

The wrong track, Gromit

For example: lots of submissions are put against the wrong track. Many people seem to just submit to whatever track the system defaults to (and this year it looks like Agile Business was the default.)

While we can, and do, move sessions between tracks we don’t do this methodically. With nearly 300 submissions it would be too time consuming to review every session and decide which track it should be in.

Plus, some people deliberately want their submission in a particular track. Last year we had a talk on technical debt submitted to the business track. Before I moved it I happened to ask the submitter why he had gone there not software. His reply: “We deliberately did this because we want to raise the issue with managers.”

Some reviewers will mark sessions down because they are in the wrong track. That is a little unfair but understandable.

Where is Falmouth again?

One problem that seems to growing is people not knowing where the conference is. To be clear: Agile on the Beach is in Falmouth UK – lookup Falmouth on Google maps.

Falmouth is five hours by train from London. Seven hours from Manchester. Nine from Newcastle Upon Tyne.

You can fly into Newquay airport from several UK airports but you are still nearly an hour by taxi from Falmouth.

Both last year and this year we’ve accepted people who then, when they look at how long it takes to get to Falmouth pull out.

What is your conference about?

But that is not the worst.

Every year we get a few submissions, mostly from the USA , which are totally inappropriate, something like “Calisthenics for a younger look.” OK, I guess calisthenics helps make your body agile but did they stop reading at the conference name?

Mostly with some hint that the person who filled in the form is not the speaker. I suspect the semi-famous person has a PA who just submits to everything they can find.

We don’t pay

Similarly we get a clutch of submissions – again mostly from the USA – where in the synopsis the speaker say: “My feed is $1,500 plus travel expenses.”

AOTB only pays speakers a travel allowance, and we say that in the call for submissions.

OK, we do actually pay keynotes. But we choose the keynotes, usually in advance of the call for submissions. Don’t call us, we’ll call you.

During the year we get a few people – again largely Americans – who e-mail us to say: “I can keynote you conference blah blah blah…. my fee is blah blah.”

I can’t blame them, they are only trying to make a living. One day someone who we find interesting might even contact us!

(Ummm… maybe I should do it myself rather than waiting to be asked to keynote…)

I am …

A new one this year: round 1 was blind, no bibliography details. The hope was this would help new speakers and increase our diversity.

Some speakers chose to self-identification: they gave their names in the synopsis “I this talk Adam Jones will be talking about…” or even a mini-bio in the synopsis: “Sally Smith will draw on her long experience working as Agile Coach with companies such as blah blah blah”

True we didn’t tell people not to do this. Blind reviewing was an experiment so we didn’t really have any rules. But, some reviewers took a dislike to this – I can see comments which say “Would vote higher but speaker gave their name”

Please please please answer me when I call

Finally, AOTB has a two stage acceptance process.

If you get accepted you get a mail from me saying:

“Congratulations… here is the boring admin details, now confirm you can speak by clicking on this link….”

We know that a) some people can’t get to Falmouth, b) schedule change between submitting in December and acceptance in February, c) people forget they submitted, d) something in the admin details isn’t to their liking, d) some other reason.

Result: some people who submit can’t make it. That is why we ask for confirmation.

If you are accepted I need your reply. And the quicker I get it the better.

If I don’t get a reply after a few days I chase: repeat e-mails, Twitter, LinkedIn, SMS and if I need to I will pick up the phone and call you.

This year one speaker was impossible to contact, no phone number, no Twitter, no LinkedIn. My e-mail may have been going to spam. With a heavy heart I switched them from accept to decline.

Apart from this taking up my time it also delays the work of the rest of the committee, the website, the publicity, ticket sales and everything else. Until we have the programme in place a lot is on hold.

Your submission is important to us, please hold

Plus, we don’t say: “Sorry, your submission was not accepted” until we have our programme in place. When we loose a speaker we make an immediate substitution. It doesn’t seem right to tell a lot of people (about 240) that they are not speaking at AOTB and then a few days later say to one or two “O sorry, can we have you after all?”

We only send the sorries once we have all our speakers confirmed. So, if someone doesn’t reply, and we can’t get hold of them, we have no choice but to wait and try again. Which means everyone else has to wait which is not fair either.

Overall our system works. It is not perfect but I don’t think any system is perfect.

The post Notes on Agile on the Beach submissions appeared first on Allan Kelly Associates.

Agile on the Beach – update on review process

Allan Kelly from Allan Kelly Associates

294 submissions
54 volunteer reviewers
2,400 votes
2 rounds of review
40 accepted submissions

Over the weekend I did the hardest thing I do all year: I sent the “sorry your submission to Agile on the Beach has not been chosen.” The declines.

I have explained how we review sessions for AOTB before but things have changed a bit so I owe it to submitters an explanation. So here goes…

This year, as usual, we had nearly 300 submissions to speak at Agile on the Beach. There are only 40 speaking slots – the exact number varies a little because we make minor changes to the schedule.

We have two review rounds. In round one reviewers score submissions from 1 to 5 – with 5 being the best. From this we create a shortlist for each track. Rule of thumb is the shortlist is twice the number of available slots (5 slots for Thursday tracks, 4 for Friday and 9 for two day tracks, so 10, 8 and 18.)

The first change for 2020: round 1 was done blind. That is anonymously, speaker bibliography details were not shown to reviewers.

Now on the one hand this is fairer: it gives more chance to new speakers, it stops the same old names dominating the conference and hopefully promotes diversity.

On the other hand: reviewers have often seen speakers previously and know who is good and who is not so good. It also has a commercial hit because a programme with more known names is likely to be more attractive to ticket buyers. So 2020 was an experiment.

I think blind reviewing worked. Although it does mean a few regulars did not make it and I feel bad about that, they are my friends. I also think we were right to look at speaker bios in round 2.

While we set no rules about speaker self-identification (i.e. some speakers used the synopsis to give their name or even mini-bios) a few reviewers didn’t appreciate this and in their comments noted they scored such submissions lower.

Back to shortlisting… when shortlisting we look at the mean score in reviews and the median. Usually the first few, highest scoring, sessions are easy to pick. It is the border line ones which are hard to decide.

In round two reviewers are asked to rank the shortlist. There can be only one number 1. The lowest score depends on how long the shortlist is, this varies by track. (So oddly, round 2 reverses scoring, 1 is top.)

In both rounds reviewers are encouraged – but not compelled – to write an explanation of their score. This is used by us as reviewers when deciding border line submissions and provided to the submitter as feedback.

In the past this process has needed reviewers to review 70 or more submissions. A few reviewers look at everything, all 300. I stopped doing this myself about two years back. Our submission system (Mimas) tries to ensure that submissions get an equal number of reviews.

Because reviewers were reviewing so many sessions feedback declined, I suspect attention to submissions decline too but I don’t know for sure.

The other big change for 2020: we recruited more reviewers. Actually, we invited everyone who had already bought a ticket, and everyone who attended in 2019 to review for round 1. 54 people volunteers and were allocated sessions to review. About a dozen people didn’t do their reviews but we still had plenty of scores.

This created more work for me than expected. While Mimas was updated to cope with this is wasn’t completely smooth. Whats more some reviewers left it to the last minute to review which created problems and meant I had to chase people.

Round 2 reviewing was more limited. Only about 12 reviewers picked including some AOTB committee members.

Over the years, and especially since I wrote Mimas, AOTB selection has become more score dependent. This has its good and bad sides but it does mean we get it done faster.

Once round 2 is done we look at the average (mean and median again) ranks and count of from the top to fill the track. Then we apply some judgement: people who submit in two tracks normally only speak in one. We would like a male/female balance but we don’t have any hard and fast rules plus, we don’t know if we are being fair on other diversity criteria. Are dyslexics fairly represented? Ethnic minorities? and so on.

We also have a financial consideration. AOTB pays a travel allowance dependent on how the speaker travels. This year when we completed selection and looked at the costs we were in budget. That doesn’t always happen, some years we have to cut back on long-haul speakers. Some years we argue and get more money.

Finally, we send acceptances. We ask everyone who is accepted to confirm they will attend and speak. Hopefully everyone says Yes and says so quickly. However we often loose people for one reason or another. Hence there are quick substitutions – that is why we hold off sending declined. Once we have the lineup settled we send the declines.

Every year we decline some amazing sessions that we would really like to host. We only have so much space. Every sessions we accept means another we can’t accept. We have enough good material for two conferences but only have one.

Whether you have been declined or accepted for 2020, whether you are thinking of submitting in 2021 or just trying to find out how conferences operate I hope that helps.

You might also want to look at:

Finally, you can see and try Mimas our conference review system – this is now OpenSource on GitHIb. I’ll blog more about this soon.
(Now reviewing is over I have a bunch of updates to do so the system may be up and down randomly this week.)


Like this post? – Like to receive these posts by e-mail?

Xanpan

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

The post Agile on the Beach – update on review process appeared first on Allan Kelly Associates.

Patterns of regular expression usage: duplicate regexs

Derek Jones from The Shape of Code

Regular expressions are widely used, but until recently they were rarely studied empirically (i.e., just theory research).

This week I discovered two groups studying regular expression usage in source code. The VTLeeLab has various papers analysing 500K distinct regular expressions, from programs written in eight languages and StackOverflow; Carl Chapman and Peipei Wang have been looking at testing of regular expressions, and also ran an interesting experiment (I will write about this when I have decoded the data).

Regular expressions are interesting, in that their use is likely to be purely driven by an application requirement; the use of an integer literals may be driven by internal housekeeping requirements. The number of times the same regular expression appears in source code provides an insight (I claim) into the number of times different programs are having to solve the same application problem.

The data made available by the VTLeeLab group provides lots of information about each distinct regular expression, but not a count of occurrences in source. My email request for count data received a reply from James Davis within the hour :-)

The plot below (code+data; crates.io has not been included because the number of regexs extracted is much smaller than the other repos) shows the number of unique patterns (y-axis) against the number of identical occurrences of each unique pattern (x-axis), e.g., far left shows number of distinct patterns that occurred once, then the number of distinct patterns that each occur twice, etc; colors show the repositories (language) from which the source was obtained (to extract the regexs), and lines are fitted regression models of the form: NumPatterns = a*MultOccur^b, where: a is driven by the total amount of source processed and the frequency of occurrence of regexs in source, and b is the rate at which duplicates occur.

Number of distinct patterns occurring a given number of times in the source stored in various repositories

So most patterns occur once, and a few patterns occur lots of times (there is a long tail off to the unplotted right).

The following table shows values of b for the various repositories (languages):

StackOverflow   cpan    godoc    maven    npm  packagist   pypi   rubygems
    -1.8        -2.5     -2.5    -2.4    -1.9     -2.6     -2.7     -2.4

The lower (i.e., closer to zero) the value of b, the more often the same regex will appear.

The values are in the region of -2.5, with two exceptions; why might StackOverflow and npm be different? I can imagine lots of duplicates on StackOverflow, but npm (I’m not really familiar with this package ecosystem).

I am pleased to see such good regression fits, and close power law exponents (I would have been happy with an exponential fit, or any other equation; I am interested in a consistent pattern across languages, not the pattern itself).

Some of the code is likely to be cloned, i.e., cut-and-pasted from a function in another package/program. Copy rates as high as 70% have been found. In this case, I don’t think cloned code matters. If a particular regex is needed, what difference does it make whether the code was cloned or written from scratch?

If the same regex appears in source because of the same application requirement, the number of reuses should be correlated across languages (unless different languages are being used to solve different kinds of problems). The plot below shows the correlation between number of occurrences of distinct regexs, for each pair of languages (or rather repos for particular languages; top left is StackOverflow).

Correlation of number of identical pattern occurrences, between pairs of repositories.

Why is there a mix of strong and weakly correlated pairs? Is it because similar application problems tend to be solved using different languages? Or perhaps there are different habits for cut-and-pasted source for developers using different repositories (which will cause some patterns to occur more often, but not others, and have an impact on correlation but not the regression fit).

There are lot of other interesting things that can be done with this data, when connected to the results of the analysis of distinct regexs, but these look like hard work, and I have a book to finish.