Jake, from the OSN team posted a great recap article about the competition. OTN also interviewed Dimitri and Martin after the competition:

ClariFit is proud to be a Premier Sponsor at ODTUG‘s Oracle APEX 2-day APEXposed conference in Montreal this fall on Sept 11-12th. The conference is entirely focused on Oracle Application Express (APEX) and features some of the world’s top APEX experts. Not only will you get a chance to learn from these experts you’ll be able to discuss your current issues with them and network with other conference attendees.

ClariFit’s own Cameron Mahbubian and Martin D’Souza will be giving several talks at the conference covering APEX for CEO’s, Plugins, and HTML 5. The complete list of presentations can be found at http://odtugapextraining.com/presentations.html

The Early Bird rate for the conference is $399 USD, but using the discount code “CLARIFIT” will save you $50 off registration! For $349 it’s an amazing deal and we look forward to seeing you there.

Title: Common Questions DBA have about APEX

Abstract: DBAs have many responsibilities managing the databases in their organizations. The introduction of Oracle Application Express (APEX) has added some more items to their already demanding list of tasks. This presentation will answer some of the common questions DBAs have about APEX.

APEX items to be discussed include: development best practices, release management, automatic backups, and web server configurations. This presentation is also relevant to developers and they are encouraged to attend.

Date/Time/Location:
April 19th 8:30am (registration starts at 8:00 am)

Suncor Energy Centre (West Tower)
150 6th Avenue SW
17th floor – Room A/B

Download Slides

In order for us to be in a position to provide a complete answer to your question please include as much detail as you can about your issue in the email.

Even if you don’t have a specific question we encourage you to attend the webinar as we expect some interesting questions that everyone can learn from.

To sign up for the webinar, please click HERE.

We look forward to hearing from you!

About the Presenters

Martin Giffy D’Souza is an Oracle ACE and Senior Developer at ClariFit. Martin is an award winning presenter and a prolific blogger and author on all things APEX. More about Martin…

Chris Hritzuk is an Oracle Certified Associate and Senior Developer at ClariFit. Since 1999, Chris has been architecting and developing Oracle based enterprise solutions for a wide variety of industries. More about Chris…

We’ve all been through these types of presentations before so I won’t discuss why you shouldn’t do it. Instead I’ll focus on why it happens and how to get around each issue.

Too Much Content
When you have a lot of text on a slide the natural tendency is to turn and read the slides. Everyone else in the room is doing that so it’s only natural that you, as a presenter, do the same.

If you’ve read any book, blog, tweet, etc on using slides in presentations they’ll all say to reduce the number of words on your slide (or even better don’t use slides). The easiest way to do this is create 2 slide decks. The first will be for handing out (with all your notes). The second should use “visual aids” to help emphasize your current talking point.

You’ll notice immediate impacts by doing this. Instead of everyone focused on reading the slide they’ll be looking at you. As a result you’ll naturally look back at the audience rather than turning around and staring at the screen.

Complex Data
I once had a manager who gave weekly meetings about how we were allocating our time. Some of the charts that were on his slides had so much content that I could barely read it a few meters away. Of course he had to spend the entire time looking at the screen to decipher everything rather than facing the group.

When you put up charts and graphs that are complex the same thing happens as when you put too much content. You’re pulled into facing the screen to decipher what is going on.

To get around it either don’t put up the chart/graph or put up a very simple chart and highlight the key areas. You can easily do this by greying out everything except for the one key element that you’re talking about. Using this simple technique you won’t feel the need to turn around and decipher what is going on in the chart/graph.

Not Enough Preparation
I’ve met some people that are proud when they say “I whipped that presentation up in 30 mins”. I groan when I hear this since I already know how the talk is going to go. These presentations tend to have slides with (you guessed it) too much content and complex data. They use their slides as a guide for them rather then something to help you, the audience.

If you’re going to present to other people the least you can do is practice. By practicing you’ll find that you don’t need to litter your slides with reminders for yourself. If you do need some reminders then use some sticky notes with key words.

Don’t be fooled into thinking that clear and concise presentations are quick and easy to create. They’re the ones that take the longest to create since the presenter has given a lot of thought into the flow and structure of the talk.

How much time should you practice and prepare for? Well, it depends. For internal meetings estimate the total man hours your presentation will cost the company. For example if your talk is 1 hour long and 10 people are going to attend, spend 10 hours on it. Some managers will gawk at that amount since it seems like a lot. The total time spent will be 10 hours (your prep) + 1 hour x 10 audience + 1 hour x 1 presenter = 21 hours. Seems like a lot but look at the results. That’s 21 hours and the result is that 10 people know a lot more about the topic you just discussed. The alternative is that you spend 2 hours (prep) + 1 hour x 10 audience + 1 hour x 1 presenter = 13 hours total. For 13 hours no one gets anything out of it, people get bored, and the company just wasted time and money.

Public talks (conferences, webinars, etc) are slightly different. I tend to spend anywhere between 40 to 60 hours (sometimes even 80 hours) preparing when I give public talks. It may seem like a lot but it really isn’t. If there are over 100 people in the audience then they expect a good, entertaining, and educational talk.

Conclusion
Please remember, talk to me … and not to the screen

Code reviews are when a developer reviews another developers work. They look for bugs, ensure standards are met, efficiencies, etc. This is common practice in some work place environments but not all of them. As you can imagine not all developers enjoy having their code reviewed so they tend to dismiss all the benefits about code reviews.

Now back to the story behind the title. A friend of mine works at an international oil and gas company in Calgary. He recently had to drive to Edmonton (three hour drive) for work. I was shocked when he told me some of the organization’s procedures when traveling for work:

- They must inform a supervisor before they leave and when they arrive.

- Any planned breaks must be submitted and scheduled ahead of time

- They must not exceed the speed limit while driving (the company cars have GPS trackers that log speed)

If they break any, yes ANY, of these rules they will be fired immediately! That’s right, if they drive a bit over the speed limit while on the job they’ll get canned.

At first I thought this was a bit excessive until he started to explain the logic behind these rules. Each year the company sustains work place injuries ranging from minor injuries all the way up to death. Most of the serious and fatal injuries occurred because of a series of several small mistakes that lead to an unfortunate situation. The company has spent a lot of time and effort to reduce the small mistakes which in turn has helped then reduce the number of injuries, and deaths, in their organization.

What the company found is that if you reduce the number of small injuries, which are caused by small mistakes, there’s a direct correlation to a reduction in the number of deaths. Another way to think about this is to compare it to a triangle. The base represents minor injures and the top represents death. If you trim the bottom down the triangle becomes smaller and this the number of deaths are reduced.

How does this relate to code reviews? Most major software bugs that I’ve encountered are usually triggered by a very small mistake or a set of small mistakes. If you can reduce the number of small mistakes ahead of time you can reduce the number of bugs, both minor and severe, in your final product. Code reviews can help catch these mistakes before they get to a test environment. The bonus is that two developers can learn from the mistake: the developer and the reviewer.

I’ve met and worked with some excellent developers throughout my career. The one common thing I’ve noticed is that the more they know about a programming language and design, the harder it is for them to write “imperfect” code which the business may need at the time.

A classic example of this is developing a new product. “Perfectionist” programmers tend to focus their attention toward ensuring the data model and code architecture are rock solid. This of course takes time and can significantly delay getting the product to market. Even worse you may spend all that time on the code and no one will ever use it. The alternate approach is to develop something that is good enough (don’t get this mixed up with sloppy work, there’s a difference between them) and get it into the clients’ hands as soon as possible. I won’t go on any further since they’re a lot of posts that already discuss the benefits of delivering products in a timely fashion.

If you ask these developers why the code and design have to be perfect the answer is usually along the line of “well if you had situation xyx then the code won’t scale and you’ll end up paying more”. Where xyz is a situation that you’d only encounter in a very long time assuming your business/product really takes off.

This approach by developers is very odd since I don’t think they put their money where their mouth is. Most of the programmers I know have a mortgage on their home. If they believe in the philosophy of perfection why didn’t they wait to buy their house and pay it off right away? After all they’ll end up saving money by not paying interest. Instead they put a down payment  (building an initial base product) and then make monthly payments (product upgrades) which include interest (cost of adding on to a base product and modifying it to scale accordingly).

As with all things in life you should take this with a grain of salt. I find the best way to approach perfectionists is to listen to their point of view and then discuss some of the business needs around your requirements. You can usually come to a consensus that makes both the developer happy and supports the business. Of course if that doesn’t work ask them how they’re financing their house!