Planet Linux Australia

Syndicate content
Planet Linux Australia -
Updated: 1 hour 14 min ago

Andrew Pollock: [life] Day 337: New Years Day, another movie outing

Fri, 2015-01-02 20:26

The long awaiting Penguins of Madagascar had come out, and I'd made plans with Kim for us to see it with her family.

After breakfast, we biked down to Bulimba and watched the movie together. It was really well done. I'd go so far as to say it was a great adult comedy that also happened to appeal to kids, but that could just be me. I've always enjoyed the penguin characters in the other Madagascar movies.

After the movie, we biked back home and had some lunch.

After lunch, we went out and did the grocery shopping. Woolworths was a ghost town, which made the shopping nice and easy.

After that, Zoe watched a bit of TV while we started on dinner.

Jonathan Adamczewski: The benefits of not lingering in eddies, and of learning from your own mistakes

Fri, 2015-01-02 17:27

I recently watched the CppCon 2014 talk by John “JT” Thomas:

“Embarcadero Case Study: Bringing CLANG/LLVM to Windows”


The presentation brought a few things to mind about which I have opinions :)

Don’t let upstream get away from you

If you’re going to build upon a codebase that you don’t own, a codebase that others are adding enhancements to, where those enhancements are visible to your customers and are available to your competitors — why would you do anything but keep as close as possible to that upstream development?

“JT” argues in favor of following upstream more closely than they did. I’ve read [it seems like] many articles that insist that the only sane way to do Linux kernel driver development is the same — at least if you ever want your changes to be merged, or you want them to be maintainable into the future.

Playing catch-up is hard work, not made easier when upstream is highly active (as is the case for LLVM/clang or the Linux kernel). Investing developer time into regularly integrating changes from upstream is far more palatable than the epic upheaval that comes from chasing major releases.

It seems like regularly integrating has some tangible benefits:

You get the new features as soon as possible. (Also, you get the new bugs. This is software development.)

More manageable schedules. Regular integration will be far more predictable in terms of the time it takes to adapt your branch. There is a limit to how much change can happen upstream at one time. Smaller, regular changes are more predictable, and less likely to cause huge timesinks for programmers i.e. it’s better from a project management perspective.

Reveal conflicts closer their source — it’s better to fix code recently written than having to rewrite it months later.

And, if you’re doing it from the outset, it means the team can become comfortable with that workflow, and develop the skills and judgement to maintain it. Trying to learn those skills after working in a stable branch/dreamworld is only going to increase the friction when the change takes place.

Consider the full cost of contractors

Don’t pay someone outside of your team to develop intimate knowledge about your systems — you’ll need to pay for it again when members of the team have to learn how to maintain and extend those systems at some point in the future.

This is partial text from a slide at around 50:50 in the presentation:

Initial contract work led to slow integration

  • Core compiler team took time out to integrate and get up to speed
  • This type of initial work would have been best done in house or with much closer interaction

Using contractors to add features to your software comes at a cost to the team: no one on the team will know what the contractor learned while completing the task — not the way that the contractor does. No one will have full insight into why decisions were made the way that they were. If you want your team to be able to support the code after the contractor is finished, you’ll need to set aside more time to develop familiarity.

In many cases, it’s better to kill two birds with one stone: let someone familiar with your codebase do the work of learning about the new area. You’ll keep the expert knowledge on the team, and any newly written code will have a better chance of fitting in with existing standards and practices of the codebase.

If it’s something that you expect to be using and maintaining into the future, keep it in-house. Or expect to keep paying the contractor, and plan for the cost of poorly integrated code.

Andrew Pollock: [life] Day 336: New Years Eve

Fri, 2015-01-02 17:26

It was a hot day, so I figured getting out of the heat and seeing a movie would be a good idea, so after Sarah dropped Zoe off, we didn't spend too much time at home before walking down the road to the cinema to watch Big Hero 6.

Zoe had already seen it with Sarah, but I was pretty keen to see it anyway, and Zoe didn't seem to mind seeing it a second time. She gave me a bit of a running commentary throughout.

After the movie, we dropped into Ooniverse for lunch. I learned that Nicky Noo is pulling up stumps next week, and moving to Western Australia to manage a bar in the mines. She said it's time for Nicky Noo to take a bit of a break. Ooniverse was nothing fancy, but it was a nice thing to have within easy walking distance of home, and Nicky always remembered us whenever we dropped in. I'm glad we got the opportunity to say goodbye.

After lunch, we went home, and Anshu came over. We went and picked up her new bike from the bike shop, and went for a little test ride at home. Zoe's been asking for her training wheels back on her bike for a while, so I finally caved in and put them back on, and she did a lot of pedaling.

After that, we got some pizza for dinner, and settled back to wait for the 8:30pm fireworks. Zoe and I watched them from the balcony, but Zoe didn't seem that into them, and went to bed after they finished.

I was nodding off on the couch watching a movie, so we went to bed before midnight ourselves, so much for seeing in the New Year.

Maxim Zakharov: Happy New Year 2015!

Thu, 2015-01-01 22:25

Happy New Year to everyone with best wishes from Sydney!

Here is the culmination of Sydney New Year’s Eve fireworks:

Michael Still: Urambi Trig

Wed, 2014-12-31 22:28
Another day, another trig. This time with Doug, who got to play with his new radio at the top of the hill.


Tags for this post: blog pictures 20141231-urambi_trig photo canberra tuggeranong bushwalk trig_point

Related posts: A walk around Mount Stranger; Taylor Trig; Walk up Tuggeranong Hill; A quick walk to Tuggeranong Trig; Wanniassa Trig; Another lunch time walk

Comment News: Happy New Year 2015

Wed, 2014-12-31 21:28
The team at LCA 2015 would like to wish all of our friends in the FOSS community a Happy New Year for 2015 and safe travels to New Zealand!

(Tickets for LCA 2015 are still available - we can't wait to see you!)

Michael Still: The Martian

Wed, 2014-12-31 11:29

ISBN: 9780091956141


I bought this book because of a review I saw online recently, and I have to say I loved it. Its interesting, humorous, and a generally fun read with a story line that I haven't seen before. Its refreshing to encounter a new author who has some genuinely new ideas to explore. I highly recommend this book.

Tags for this post: book andy_weir mars colonization exploration space_travel space_station

Related posts: Marsbound; Starbound; Red Mars; Mars: A Survival Guide; Earthbound; The Moon Is A Harsh Mistress Comment Recommend a book