By a reference from a fellow quality engineer, I watched GTAC 2014 keynote video by Ankit Mehta on how different engineering and cultural practices help Google to move fast and NOT break things (almost). Overall Google’s test engineering goal is set to build an infrastructure and tooling to enable rapid launching of high quality innovative products that delight end users.
If you have a problem of bamboo agents running out of space and wondering why build expiry doesn’t help you – welcome to the club :)
I too have bumped into this problem several times and naively thought that this is configurable via Bamboo Admin by Build Expiration setting. Still, our jobs would fail with “fatal: write error: No space left on device” quite too soon. Agent’s home folder was full and running Build Expiration manually with “133 builds affected” result didn’t help a bit. Still full. Most, like in 99%, of space being taken by checked out source code.
Continue reading “Cleaning up Bamboo Agents”
“Did I do something good today?” – question I asked myself after a day of refactoring a long and repetitive test suite and ending up with TestSuite and TestSuiteOld. Was it a good time investment? Yes, I did spend more time than I planned working with this 2500+ lines monster, but looking at our goals next time we would change this component wouldn’t be soon. The old suite worked just fine and now we have two files, different styles and a day spent not on testing new features or working on items from automation backlog (I’m a Quality Engineer a.k.a. Software Developer in Test). Was it worth it?
Gut feeling told me – yes, it was. First of all, I (finally) learned how this component works. More important, I’ve lighted a guiding light for creating less testing debt – tests for this component are now easier to create: common code is moved to setUp and private methods, tests are on average 7-15 lines shorter and work with data providers.
Few weeks ahead (surprise!) we need to change this exact component. Today on retrospective my team members told me they were happy that I managed to write several good cases that caught issues. All thanks to refactoring, it was so easy to create those tests that I was surprised it was mentioned. All I had to think is what data to put in new data providers. For me real issue was why it was me who caught these issues, but that’s another story.
Test/check automation code should be treated same way as production code (1, 2) and should be clean. It wil give you shorter cycle time, less bugs and happier team. To stop creating technical debt “Stop Writing Crappy Code“, stop it right now and write it good this time. It will pay of rather soon.
Today evening I wanted to quicly upscale one SD video to HD with ffmpeg, which was my encoder of choice for quite a long time.
But it ain’t easy. First, default Ubuntu 12.04 ffmpeg didn’t support h264. Switching to VP8 didn’t help as output quality was awful and several how-tos had unsupported options. It all looked like ffmpeg was outdated. And it was. Ubuntu ships Libav, a fork of ffmpeg, v 0.8 w/o x264 support.
Luckly, there’s a ppa with latest version (0.10) of original ffmpeg on launchpad. Using
ffmpeg -i in.mov -acodec copy -vcodec libx264 -crf_max 7000 -q 50 -s 960×720 HD.mov
I could convert my 4:3 ratio SD file into 720p one. I wish I used Avidemux and hopefully it would just simply work.
A bunch of good articles worth reading. Topic covered – testers in agile team, patent monopoly, buccaneer learning, good and bad manager patterns and improcing your restrospectives (and other repeated things)