In your SQL IDE, such as PL SQL Developer it’s not entirely straight forward to access the results of an Oracle stored procedure, when the results are returned via an output parameter of type sys_refcursor.

Firstly we need to declare some variables to use. l_rc is a cursor that we will pass to the procedure, to store the output results.
l_rec is a record into which we’ll store each iteration of the cursor.

After the declaration we execute the package, populating the cursor.

We then loop over the cursor, storing the value in to record, or row, that we declared above, ending when the cursor is empty.

A group of women players I jam with were given the suggestion “rock band” in the last class. They decided to do the role of band members as men.

In another scene, a married couple are having dinner of an evening and discussing their days. The male is a judge and the woman stays home and looks after the kids.

Later, a drunk piano player’s wife enters the room and is immediately endowed with the characteristics of being a floozy and prostitute.

When improvising I do think it’s important to play to characteristics and to recognize archetypes, but I’ve noticed that women are given derogatory or subordinate, low status roles more often than not. Or, when choosing a certain type of character, such as a lawyer or a baseball coach, they will choose to play it as a man.

Why couldn’t the band members be women? Why was the male a judge and the woman a stay-at-home mum? Why was the woman in the scene automatically a floozy?

Now, the people in my class are not sexist, and would never speak or act in a derogatory way towards women in real life. And it’s worth noting these character choices were made by both the guys and girls in the class. But I do think there’s an underlying lack of respect for women characters in general in my local improv scene.

I’ve recently been giving series of presentations to large(ish) groups at work. In my opinion they’re good presentations, and I’ve received some great feedback.

While I was giving the presentations I noticed a few different categories of body language given by attendees in the room – there seems to be a spectrum of visual attentiveness.

Some people looked directly at me, and nodded as I made points, leaning forward on their chairs attentively while I explained finer points in detail with a diagram.

Other people looked mostly at the slides, even though there isn’t a massive amount of info on there – maybe a few word or an image. They tended to have a fixed focused on the projection, rarely looking at me.

There was also a third type of attendee who seem disinterested and was on their phone or looking out the window for whatever reason.

I have a few points I’d like to make about this.

Firstly, I was initially disheartened and put off by the latter type. Why weren’t they interested in my awesome presentation? Am I doing it wrong? Am I not speaking clearly? Is my subject complete and utter crap? Have they realised I’m actually just a big phony?

No, I don’t think so. There are probably lots of reasons these people were looking disinterested. Maybe they’re super familiar with the topic already? Maybe they were deep in a debugging session before the meeting, and haven’t fully context switched yet? Maybe they have something on their minds from out of work? Or perhaps that’s just how they listen and learn? For whatever reason, I think it’s important not to be distracted and dejected when presenting to people with this sort of body language – which was my initial reaction.

Secondly, the people who stared at the slides throughout the presentation. These people were fairly easy to present to. They didn’t give me much feedback, but I felt as if they were letting the information sink in, and it was easy to roll through the motions and get the content out to them.

Thirdly, the more active attendees. The people who looked at me, and nodded. The people who smiled when I made a light remark. The people taking notes. Thank you! Having some feedback or recognition really helped me. When I wasn’t sure if I had explained myself well seeing these people jotting things down in there notpads/laptops confirmed that I was on the right track. I think the more people who were like this in the room, the better my presentation went.

In conclusion, if you’re attending a presentation perhaps it’s worth considering how you present yourself. Show some interest and that enthusiasm may be fed back to you! If you’re the one doing the presentation, my advice is to be ready to expect different types of body language and don’t be too disheartened by blank faces.

I went out to shoot with some friends – sixteen hours away by car – and when I reviewed the footage at home (yes, I waited until I got home to review) I found that one of my main shots was not in focus like I had expected.

I’m sure there are lots of other things wrong with the shot, but hey, it’s all learning!

Anyway Here’s the original shot (poke the image with your mouse to upsize):

You can see the actor’s melon, in particular his hair, is not in focus at all. Check out his poorly focused shoes too. I was bummed but luckily a friend of mine told me to try the “Sharpen Tool” in Premiere.

I was sure this wouldn’t work, because I mean, if the information isn’t there, it’s just not frikken there. We can’t fix it in post. I mean, that’s like in CSI when they zoom in on a blurry face on a security camera and all of a sudden we can see the mole on the murderer’s right cheek aaaaaaaaaaand he’s guilty! Welll…IT DOESN’T WORK LIKE THAT!!! Right!

… right?

Luckily I’m a big dummy, and it does work like that.

Here is the same frame with the sharpen applied (click for embiggification):

Note the actors shoes and shoe laces, and his hair. Not perfect, but good enough for an amateur, like me.

Now I know why Adobe’s slogan is “Making Dreams Come True”…. at least that should be their slogan.

Now I fill out a long scrolling form and fill out the captcha *click*.

ERROR! Ah, I forgot to put in my post code because hardly any of the form fits in the miniature space they’ve allowed.

That’s cool… filling it in… *click*.

ERROR! Oh, they cleared out my CAPCHA… okay, filling that back in. *click*

ERROR: did I get that wrong? was that ‘p’ or a ‘b’? That ‘j’ kinda looks like an ‘s’. I’ll try the audio version *click*.

Listening… nope that. Doesn’t make sense to me. back to the written version *click*

ERROR! Ooh, I got the CAPCHA right! (Wooott!) but my email address is already registered. Thanks Microsoft, you could have told me earlier. Oh well that’s cool. Back to the log in screen. *click*

Filling in my details… guess my password *click*

ERROR! I guessed wrong. Well I’ve been trying to use different passwords for different sites for a while now. So that’s not surprising. I’ll just click the reset password button *cliiii…… nope that button doesn’t exist.

Okay… I pull up Chrome and go to the MS site. And am logging in automatically.

Okay. So I log out, try to log back in again, and FIND THE RESET PASSWORD BUTTON!

And it’s smooth sailing from here.

What I think, in order of importance:

1) Make the form smaller. Is that really the minimum amount of info needed?
2) Have a reset password link on or near the error
3) Asynchronously check my user id as I’m filling out the massive form
4) Make better CAPCHAs. Surely we have a better alternative… ?
5) Make it more obvious that the log in optional ? I just ran through the process again, and noticed a small “skip” link under the sign in button on the first screen. That’s cool, but there’s no skip button on any subsequent screens.

If you’re familiar with Netflix, or Plex, or XBMC, you’ll get a kick out of Popcorn Time. It’s this great program that acts like a slick media player with a basically complete library, but instead of hooking into a legitimate library (like Netflix) or your local files (like Plex/XBMC) it STREAMS TORRENT FILES! …hence the illegality.

Well, I guess it’s illegal… if the country you live honours American copyright law… and only if you choose to download content that is under copyright (there’s a lot of public domain stuff out there too).

But whatever. I love this thing – even though it’s not finished yet (IMO… and it’s in beta). They still need to get the search a bit better, give us some preferences around quality and, make some kind of offline mode (so we can choose some poor-health-torrent flicks to download now, and watch them when we get home).

I’d also love to see offline mode integrated with tablets and phone devices, like Plex does.

Having said all that, this is such a massive awesome step in the right direction, I’m very excited about the future.

One other interesting thing to note is it’s lack of adverts in the app. If there are no adverts to pay the pirateers, and the movies aren’t being paid for by subscribers or movie-goers… I guess no one makes money. Not a problem, since the share of Popcorn Time users is basically nil at the moment, but interesting none-the-less.

Ideally, I’d love to see something like this take off, where the movie industry can still make some money and keep making stuff I love – HAVE THE SCIENTIST WORKING ON THAT IMMEDIATELY!

I’m an advocate of Agile Methodologies, but it’s recently been brought to my attention that there is a potential downside. When this downside manifests, good developers can feel over worked, over pressured, and burnt out.

In this article I’ll give a brief outline of the problem in each situation, followed by how it could possibly be remedied.

The first case that was brought to my attention when I was was chatting to a new colleague of mine, I’ll call him Jimmy Lazerface (or JL for short). We were talking tech and he had been super enthusiastic about everything. Then I moved onto Agile – I was acting like a total Agile Fan Boy. I noticed he quieted up. Once I pressed him for details it turned out that the last job he’d had, indeed the place he’d worked only a few weeks earlier, had implemented their version of Agile, and he had had a bad experience. The Scrum Master/Tech Lead was giving very tight estimations on work and holding the developers to those deadlines – ensuring that the velocity stayed where he thought it should be.

I think there are a few parts to a solution here. Firstly, the developers should be involved in the estimation process, not just one person. Using a technique like Poker and T-shirt sizing, we can get a better, fairer, idea of how much work can be achieved.

Next, I think trying to maintain a velocity is a bad idea. Velocities should be used to help estimate. If there is a big drop, can it be explained in the retrospective? Or does your velocity need to be adjusted?

Finally, I think some responsibility can be put on the scrum master/tech lead for not not having some faith in his team (JL is one of the most switched on developers I’ve met, so I know he wouldn’t be slacking off).

The next example I came across of Agile being viewed in a less-than-positive-light was today. An older colleague of mine known as Professor Donaltron (or PD), was discussing the shift over the last few years to agile from a more waterfall/BDUF. He told me, That in the waterfall days, a project might last six months. The first month or so would be design, the next, say four, would be writing up functionality (i.e. actual coding) followed by a month of testing. The way he viewed this cycle was the work ramping up at the beginning, then ramping down at the end. He felt that with agile, his whole work-life was a busy period – no down time. Poor PD. It was obvious that he was feeling burnt out, and as a close colleague of mine I know he has been working really bloody hard.

Seeing as how I work with PD now, I have an insight that might point us in the direction of why he feels this way. I know PDs team do not use retrospectives or do much estimation. They are almost entirely R&D so instead they kind of pile on stories and move them across the agile board once they’re “completed” (which in itself is often hard to define. Everyday they have stand ups, where they have to explain what they did the day before. One card might could be XL (or more) and take a developer longer than a sprint to do. This whole time it could be perceived that PD is not making much progress, despite the fact that he could have put an enormous amount of effort in.

Since PDs team is R&D estimation is very difficult and rarely happens. In the same vein, it’s difficult for the Scrum Master/Stakeholder’s to understand how much progress was made.

I think in this case PD has to do a better job of communicating what he has done in the stand up. I actually advocate him adding new stories to the board (or sub tasks perhaps) so that there’s a visual representation of what he’s doing as movement across the board. This should then be discussed in the retrospective. This may sound like a break from agile, but I believe that agile implementations should be just that – agile. Teams should select the most useful parts of the methodology and apply that. In this particular R&D team, cannot apply many of the cool agile techniques we know and love, so must adpot a subset, coupled with anything that works for them. As long as there’s communication, openness and iteration, I can dig it.

My own experience of Agile has been overly positive, however upon reflection, I remembered when I was first introduced to daily stand ups. At the time I had been at this particualr company for a year or so, so my responsibilities included my project work, AND daily support-style work for stake holders. I remember that I wasn’t used to having to account for my time every day, so as a result I’d get to the daily stand up and have trouble talking about why I hadn’t made as much process as was expected.

The solution here is was, once I realised the problem, was to keep track of any bespoke support I’d done the day before and talk about it in the stand up. Then in the retrospective I would collate what I’d done and show that it was a meaningful amount of work. From here we started putting effort numbers on support work (kind of reverse estimation) so we could work out a kind of velocity separate to the usual project work. We then created a support roster to share the support work, and tried to focus on getting the “support velociy” down. It was a successful way to tackle that problem.

In conclusion, I think developer burn out is a worthwhile thing to note when employing agile techniques. Perhaps more emphasis should be placed on asking how developers feel during the retrospective? Did they work too hard? Not hard enough?

In Visual Studio, to access a C# class marked as internal from an external project, add this line to your properties\AssemblyInfo.cs file:

[assembly: InternalsVisibleTo("NameOfProjectAsString")]

The longer version:

When I’m doing Test Driven Development I tend end up with a lot of classes – each with a single well defined responsibility and no external dependencies*. Usually I’d write each class with a public access modifier so they can be tested, even though in the majority of cases the class will only be used in this project, and internal access should suffice.

For example consider the following simplified case for a class that might be used in a NuGetPackage:

With the above example, when accessing it from a project that includes that NuGet package, you’ll get the following Intellisense:

In this example, the only time ValueRetreiver and ContextDeterminer are used is in SpecialStringFormatter so really they are just obfuscating the intent.

Usually this isn’t a big problem since the class will probably be used by team members who would would probably know what to use, but I’m currently working on a nuget package and and I want the usage of my package to be easily discoverable with Intellisense (which is proabably a noble goal for all your code anyway).

If I switch these to internal the Intellisense looks like this:

Much nicer, don’t you agree?

Now the problem is, that my classes aren’t visible to my testing project. The solution to this it to allow access to a different project via the attribute:

[assembly: InternalsVisibleTo("NameOfProjectAsString")]

which I added to my properties\AssemblyInfo.cs file.

I also needed to give access to my mocking frame work (Moq) with this attribute, including that very specific string:

In our last improv jam we did a pretty cool exercise from Del Close’s book, Truth in Comedy.

In the exercise, both players (or, all players if you like) are to rant for the entire scene. So no pauses at all. If there’s a pause, just jump in and say something, anything, keep it moving.

The idea of the exercise is to help get yourself out of your head. To just keep pushing the scene forward, and for me it it was a real eye opener. All the scenes we did turned out really well. I think this is because we started getting all this extra detail that transformed into offers – emotion, conflict and resolution all sprung out in full force with players not holding back by over thinking.

Great fun.

We also did a variation of it in which a normal scene is played, but a the jam director yells out “rant about it” and one of the players just goes on an awesome rant. This progressed the scene in the same useful way.