my $last_base_index = ( length $fields[$SEQUENCE_INDEX] ) - 1;
The parenthesis are needed!
Tuesday, 14 June 2011
Friday, 3 June 2011
Bingo!
Last year, my dad, as the Chairman of the local community association says that what might be a good fund raiser is a bingo evening.
Initially, my thought was, who are they going to get to run that then?
But he continued, and came up to the question of sourcing a bingo machine. This is were I came in and said,
'Oh, that's easy, I could write one in a couple of weekends on the computer, we jsut hook my laptop up to a big screen and that's that.'
Can you see where I'm going with this?
So, time passes, I had a quick stab last November, but stopped as Christmas was coming up, and I was writing a perl course for work...
Until March, when Dad turns round and says
'Are you going to be able to write the bingo machine in time for Annual fundraising week? What day of the week is best for you to run it?'
Eeep.
Still, never one to back down from a request to do something, I set to work. Went back to github, and decided to scrap most of what was there, start a new Catalyst project, and a couple of weekends later, I have a bingo caller, with big ball images, and a pretty simple interface.
It could still do with a pretty looking interface, but it does the job, and should run nicely next week - assuming I can sort out Moose
https://github.com/setitesuk/Bingo-Caller
Initially, my thought was, who are they going to get to run that then?
But he continued, and came up to the question of sourcing a bingo machine. This is were I came in and said,
'Oh, that's easy, I could write one in a couple of weekends on the computer, we jsut hook my laptop up to a big screen and that's that.'
Can you see where I'm going with this?
So, time passes, I had a quick stab last November, but stopped as Christmas was coming up, and I was writing a perl course for work...
Until March, when Dad turns round and says
'Are you going to be able to write the bingo machine in time for Annual fundraising week? What day of the week is best for you to run it?'
Eeep.
Still, never one to back down from a request to do something, I set to work. Went back to github, and decided to scrap most of what was there, start a new Catalyst project, and a couple of weekends later, I have a bingo caller, with big ball images, and a pretty simple interface.
It could still do with a pretty looking interface, but it does the job, and should run nicely next week - assuming I can sort out Moose
https://github.com/setitesuk/Bingo-Caller
Wednesday, 16 March 2011
Interesting bug
I have just discovered an interesting bug, which took a lot of staring at to fathom out exactly what is wrong here:
Some of you may have spotted it straight away, but others may not.
The problem comes from a bit of
1) copy and paste programming (there is a read 1 as well)
2) not paying attention
Had I not had the if ( $self->is_indexed ) block, then Perl::Critic would actually have saved me here, with a unused variable error, but because $args (lexically scoped) , is used in the block, we skip that.
Simply, when you go to the trouble of defining your args outside of the call to the method, then use the args, don't rewrite. (Bangs head against wall to try to remember the fact).
The bug in production is that we always get a calibration table name with read 'sanger_read_two', when it should be read 'illumina_read_two' on an indexed run.
(These are config variables, which actually equate to 2 and 3 respectively)
So a change to:
and all is fixed.
if ( $self->is_paired_read() ) {
my $args = {
dir => $arg_refs->{dir},
position => $position,
read => $self->general_values_conf()->{sanger_read_two},
job_dependencies => $arg_refs->{job_dependencies},
control => $is_control,
is_spiked_phix => $is_spiked_phix,
};
if ( $self->is_indexed() ) {
$args->{read} = $self->general_values_conf()->{illumina_read_two};
}
$bsub_command = $self->_calibration_table_bsub_command( {
dir => $arg_refs->{dir},
position => $position,
read => $self->general_values_conf()->{sanger_read_two},
job_dependencies => $arg_refs->{job_dependencies},
control => $is_control,
is_spiked_phix => $is_spiked_phix,
} );
if ( $self->verbose() ) {
$self->log( $bsub_command );
}
push @{ $job_ids }, $self->submit_bsub_command($bsub_command);
}
Some of you may have spotted it straight away, but others may not.
The problem comes from a bit of
1) copy and paste programming (there is a read 1 as well)
2) not paying attention
Had I not had the if ( $self->is_indexed ) block, then Perl::Critic would actually have saved me here, with a unused variable error, but because $args (lexically scoped) , is used in the block, we skip that.
Simply, when you go to the trouble of defining your args outside of the call to the method, then use the args, don't rewrite. (Bangs head against wall to try to remember the fact).
The bug in production is that we always get a calibration table name with read 'sanger_read_two', when it should be read 'illumina_read_two' on an indexed run.
(These are config variables, which actually equate to 2 and 3 respectively)
So a change to:
$bsub_command = $self->_calibration_table_bsub_command( { $args } );
and all is fixed.
Monday, 7 February 2011
Perl Course help!
I need some help as to whether or not to do include something in a beginners perl course I am writing to run at work.
Courses I went on and textbooks I have read (including the excellent Modern Perl) mention the idiom '0 but true', to have a true 0.
Everyone in my office when I asked either went 'what?', 'why?' or 'just something not needed and is confusing'.
Personally, I agree with the 'why?' and 'confusing', so I'm inclined to leave it out. However, what do the community at large think? One of my colleagues has been programming Perl for 15+years, and has never seen it. Is this generally the case?
Thanks to any responses in advance that support either side of the argument, particularly with good reasoning.
Just to confirm my 4 reasons for leaving it out:
1) Never seen it used
2) Too confusing to explain to people experienced in Perl, let alone Newbies
3) Too confusing to read in code
4) Won't be automatically assigned to a variable when answer is 0 (4-4), so better to use defined
Andy
Courses I went on and textbooks I have read (including the excellent Modern Perl) mention the idiom '0 but true', to have a true 0.
Everyone in my office when I asked either went 'what?', 'why?' or 'just something not needed and is confusing'.
Personally, I agree with the 'why?' and 'confusing', so I'm inclined to leave it out. However, what do the community at large think? One of my colleagues has been programming Perl for 15+years, and has never seen it. Is this generally the case?
Thanks to any responses in advance that support either side of the argument, particularly with good reasoning.
Just to confirm my 4 reasons for leaving it out:
1) Never seen it used
2) Too confusing to explain to people experienced in Perl, let alone Newbies
3) Too confusing to read in code
4) Won't be automatically assigned to a variable when answer is 0 (4-4), so better to use defined
Andy
Friday, 19 November 2010
Talk to Software East - Aglie Analysis Pipeline
Last night I gave a talk to the monthly Software East meeting, held by Mark Dalgarno at RedGate Software.
Big Thanks to Mark for inviting me, and everyone who showed up for an interesting discussion on Agile techniques. Also, thanks to RedGate for hosting.
The slides have been uploaded to Slideshare:
It was a great talk, and the first time I didn't get groans outside of work about having used Perl :)
Looking forward to the next Software East meeting in January, which will be Rachel Davies talking about Agile Retrospectives.
I saw Rachel give the second day's keynote at Agile Cambridge, and she was brilliant. She was also very nice to chat to at lunch that day. She has written the book Agile Coaching (Pragmatic Programmers) so for fear of overloading the session with people, I can thoroughly recommend going to this.
Big Thanks to Mark for inviting me, and everyone who showed up for an interesting discussion on Agile techniques. Also, thanks to RedGate for hosting.
The slides have been uploaded to Slideshare:
Agile analysis development
View more presentations from setitesuk.
It was a great talk, and the first time I didn't get groans outside of work about having used Perl :)
Looking forward to the next Software East meeting in January, which will be Rachel Davies talking about Agile Retrospectives.
I saw Rachel give the second day's keynote at Agile Cambridge, and she was brilliant. She was also very nice to chat to at lunch that day. She has written the book Agile Coaching (Pragmatic Programmers) so for fear of overloading the session with people, I can thoroughly recommend going to this.
Labels:
agile,
agile cambridge,
agile development,
perl,
software east
Tuesday, 2 November 2010
Monday, 18 October 2010
Day 2 of Agile Cambridge
After far too little sleep, again I got the first bus out of Haverhill off to Cambridge, luckily not feeling bad after too much beer.
Arriving about 8.30ish, I chatted with a couple of people from the previous day, and we went through for the second Keynote, Building Trust in Agile Teams - Rachel Davies. Rachel is the co-author of Agile Coaching, and talked a lot about trust. What is trust, how do we trust people (both socially and in the work environment), and how do we build trust. Examples included borrowing £20 of a member of the audience, and doing the falling backwards into a group of peoples arms (which worked, and Rachel actually seemed a bit scared of the volunteers going through with). This was an excellent keynote. Rachel is a great speaker, and presented the material in a very easy to understand way.
After a coffee break, for me it was back into the Gilb Theatre for Scrum/XP Add-ons workshop, presented by Jon Mullen and Paul Fairless from BSkyB. The organisation of this was different, in that, with a bit of PowerPoint trickery, they were able to allow us to choose the order of the presentation topics. We did some voting (What we preferred, what our teams did agile), we choose the order we would put 'stories' based on complexity (I clearly thought that baking and decorating a cake for 20 was more complex than washing and waxing a car). The method of this though was (I thought) better than story poker). A story card is put on the table, then each person in turn either puts a new card either side (or between), or moves a card. This continues until an order is established of complexity. After this, the cards are then graded 1->8 for measure of complexity. They gave an excellent description of the way that they work (1 week sprints, pair programming, office layout), and a great little video (with sweets!) of a scrum (that had a number of things wrong with it). It all finished with an attempt to win a bottle of bubbly, in a game like they play on a Friday afternoon.
Next was lunch, and possibly the biggest thing ever to render me speechless. Rachel caught me and complimented my talk on the Pomodoro Technique. I was quite shocked, and as such completely failed to mention how much I had enjoyed her talk (Sorry Rachel). Here was someone who is experienced in presenting, complementing me on mine. After a little discussion about how I might start bringing Agile into my team here (including the idea of a taskboard, that needn't be on full display the whole time), she moved off and I had another Chat with Martin from Aptivate who was telling me about the work they had gone out to do in Zambia bringing women out there up to speed with IT, including the setting up of an Internet Cafe and training staff. It's great to hear about people doing this sort of work, and a shame that they possibly aren't getting as much funding this year to do it as fully as they have done in previous years.
After lunch, the final workshops session. I opted for Visual Management for Agile Teams - Xavier Quesada Allue. In this, we were tasked with creating a Taskboard which would be the focus of the scrum, and would keep track of stories, tasks, if we were on track, who was doing what and backlog.
Here is the one my team came up with

Although, as we went around the room, no two boards were the same. One team (featuring Conny) opted for a Kanban approach

But the coolest had their stories on hearts, which moved along a track. If they stopped, they picked up hairs (a rolling stone gathers no moss) or broke if they were blocked in any way.

This was a great way of getting on task with using a board, and showed that I think if the team is involved in the design, it probably adds more ownership and encourages it's use more.
Xavier also showed us some pictures of taskboards he had helped develop for teams. This was an excellent workshop, and well worth attending.
After the final coffee break of the conference (a chance to make sure people had my twitter alias - setitesuk), we headed back into the Gilb theatre for a panel Q&A session 'Creating a Development Process for your Team: What, How and Why'. The panel was led by Giovanni Asproni, who I met the previous day in Bob Marshalls workshop, and who previously worked at the EBI (so right next door to me!). Beforehand he admitted that he was happy to do lead the session, since he didn't need to do much talking (I must remember that trick next time).
The panel consisted of a number of the speakers from the 2 days (although I can only remember the names of Rachel, Allan Kelly and Willem). The main topic eventually was a debate around pair programming, although other aspects of Agile got mentioned (and even the Pomodoro Technique got dropped in as noting it had become a discussion point - yay me :) ).
I must say, that after two days I was starting to flag a little, so picked up the least amount from this session, but it was interesting nonetheless, and rounded off the two days in a great way.
Mark closed off the conference, and we all left (after grabbing more choccies from the RedGate guys!)
Overall, the conference for me was a great success. An opportunity to find out lots about Agile process. A steep learning curve in places, and just a great opportunity to meet others who are producing great software. My favourite workshop/talk has got to go to Gojko and David for 'The Specification Game', for the great way of teaching us all what we do wrong (it is certainly true that you learn more getting it wrong than right), and favourite snippet goes to James A. Whittaker for being so surprised that so many of us Brits still use a phone book.
Of all my sessions that I had my time again, I would have chosen not to go to, would be Code Debt. As I mentioned in my previous blog, not because it was lacking, but that it was the least relevant to Agile.
Thanks to Mark Dalgarno and his team for organising a great Conference, at a fantastic venue. Thanks to all the speakers that I saw, if I could present even half as well as you all, I'd be happy, and your material was in general excellent. Thanks to everyone I met for engaging discussions, and thanks to RedGate Software for the beers!
I look forward to next year.
Arriving about 8.30ish, I chatted with a couple of people from the previous day, and we went through for the second Keynote, Building Trust in Agile Teams - Rachel Davies. Rachel is the co-author of Agile Coaching, and talked a lot about trust. What is trust, how do we trust people (both socially and in the work environment), and how do we build trust. Examples included borrowing £20 of a member of the audience, and doing the falling backwards into a group of peoples arms (which worked, and Rachel actually seemed a bit scared of the volunteers going through with). This was an excellent keynote. Rachel is a great speaker, and presented the material in a very easy to understand way.
After a coffee break, for me it was back into the Gilb Theatre for Scrum/XP Add-ons workshop, presented by Jon Mullen and Paul Fairless from BSkyB. The organisation of this was different, in that, with a bit of PowerPoint trickery, they were able to allow us to choose the order of the presentation topics. We did some voting (What we preferred, what our teams did agile), we choose the order we would put 'stories' based on complexity (I clearly thought that baking and decorating a cake for 20 was more complex than washing and waxing a car). The method of this though was (I thought) better than story poker). A story card is put on the table, then each person in turn either puts a new card either side (or between), or moves a card. This continues until an order is established of complexity. After this, the cards are then graded 1->8 for measure of complexity. They gave an excellent description of the way that they work (1 week sprints, pair programming, office layout), and a great little video (with sweets!) of a scrum (that had a number of things wrong with it). It all finished with an attempt to win a bottle of bubbly, in a game like they play on a Friday afternoon.
Next was lunch, and possibly the biggest thing ever to render me speechless. Rachel caught me and complimented my talk on the Pomodoro Technique. I was quite shocked, and as such completely failed to mention how much I had enjoyed her talk (Sorry Rachel). Here was someone who is experienced in presenting, complementing me on mine. After a little discussion about how I might start bringing Agile into my team here (including the idea of a taskboard, that needn't be on full display the whole time), she moved off and I had another Chat with Martin from Aptivate who was telling me about the work they had gone out to do in Zambia bringing women out there up to speed with IT, including the setting up of an Internet Cafe and training staff. It's great to hear about people doing this sort of work, and a shame that they possibly aren't getting as much funding this year to do it as fully as they have done in previous years.
After lunch, the final workshops session. I opted for Visual Management for Agile Teams - Xavier Quesada Allue. In this, we were tasked with creating a Taskboard which would be the focus of the scrum, and would keep track of stories, tasks, if we were on track, who was doing what and backlog.
Here is the one my team came up with
Although, as we went around the room, no two boards were the same. One team (featuring Conny) opted for a Kanban approach
But the coolest had their stories on hearts, which moved along a track. If they stopped, they picked up hairs (a rolling stone gathers no moss) or broke if they were blocked in any way.
This was a great way of getting on task with using a board, and showed that I think if the team is involved in the design, it probably adds more ownership and encourages it's use more.
Xavier also showed us some pictures of taskboards he had helped develop for teams. This was an excellent workshop, and well worth attending.
After the final coffee break of the conference (a chance to make sure people had my twitter alias - setitesuk), we headed back into the Gilb theatre for a panel Q&A session 'Creating a Development Process for your Team: What, How and Why'. The panel was led by Giovanni Asproni, who I met the previous day in Bob Marshalls workshop, and who previously worked at the EBI (so right next door to me!). Beforehand he admitted that he was happy to do lead the session, since he didn't need to do much talking (I must remember that trick next time).
The panel consisted of a number of the speakers from the 2 days (although I can only remember the names of Rachel, Allan Kelly and Willem). The main topic eventually was a debate around pair programming, although other aspects of Agile got mentioned (and even the Pomodoro Technique got dropped in as noting it had become a discussion point - yay me :) ).
I must say, that after two days I was starting to flag a little, so picked up the least amount from this session, but it was interesting nonetheless, and rounded off the two days in a great way.
Mark closed off the conference, and we all left (after grabbing more choccies from the RedGate guys!)
Overall, the conference for me was a great success. An opportunity to find out lots about Agile process. A steep learning curve in places, and just a great opportunity to meet others who are producing great software. My favourite workshop/talk has got to go to Gojko and David for 'The Specification Game', for the great way of teaching us all what we do wrong (it is certainly true that you learn more getting it wrong than right), and favourite snippet goes to James A. Whittaker for being so surprised that so many of us Brits still use a phone book.
Of all my sessions that I had my time again, I would have chosen not to go to, would be Code Debt. As I mentioned in my previous blog, not because it was lacking, but that it was the least relevant to Agile.
Thanks to Mark Dalgarno and his team for organising a great Conference, at a fantastic venue. Thanks to all the speakers that I saw, if I could present even half as well as you all, I'd be happy, and your material was in general excellent. Thanks to everyone I met for engaging discussions, and thanks to RedGate Software for the beers!
I look forward to next year.
Labels:
agile,
agile cambridge,
agile development,
agilecam,
perl,
pomodoro technique,
scrum,
xp
Subscribe to:
Posts (Atom)