This past week ClariFit’s own Martin D’Souza partnered up with Dimitri Gielis from APEX Evangelists to enter the Oracle Social Network (OSN) Developer Challenge competition at Oracle Open World. Despite the short amount of development time these two Oracle ACE Directors used their APEX talents and won the competition!
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.
We’re pleased to announce that both our CEO, Cameron Mahbubian, and CTO, Martin Giffy D’Souza, had their abstracts selected and will be presenting at the world renowned technical Oracle conference Kscope 12. Cameron’s talk is called “APEX A CEO’s Perspective” which is geared towards executives and managers planning to adopt APEX. Martin, who is last year’s Kscope presenter of the year, will be giving two talks on “Building a Better Team” and “APEX 4 + HTML 5 = Awesome II“.
ClariFit’s CTO, Martin Giffy D’Souza, will be giving a presentation at the Calgary Oracle User Group (COUG) on April 19th.
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
On December 14th, 2011 at 1:30 PM EST, Oracle ACE Martin Giffy D’Souza and Oracle Certified Associate Chris Hritzuk of the ClariFit development team will be hosting a live “Ask the ClariFit Experts” webinar. Whether you are stuck on a problem that currently has you stumped or you just want to learn more about a feature or technique we’d love to hear from you. Between now and November 30th we will be accepting questions on APEX, SQL, and PL/SQL by email at AskTheExperts@ClariFit.com. We will be choosing the top questions from the pool and will demonstrate and explain step-by-step solutions during the webinar. We will also be allocating some time at the end of the session for attendees to ask any further questions that arise during the demonstrations.
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…
Over the years I’ve been in very tight situations where things could have either failed miserably or succeeded. In each all of those situations I’ve seen two types of attitudes with the members on the team: negative and positive.When you have people that focus on those points they can resolve just about any issue and help the business succeed. They may not always produce the best (i.e. gold plated) results but they make things work while others may still be complaining about things.
A great example of this is when I lead a project to design the security layer for a new reporting application a few years ago. When I presented the solution to the entire development team not one person had a positive thing to say about it. Most of them had a negative attitude towards the project rather than providing constructive criticism and focusing one how it would help the business.
So the next time you encounter a problem or start on a new project ask yourself “What attitude am I going to take?”. You’ll be surprised with what happens when you focus on the positive.
For those of you wondering what happened with the security project, it was successfully implemented and, from what I hear, is still being used.
One of my biggest pet peeves when attending a presentation is that the presenter spends most of the time looking back at the screen and talking to it instead of the audience. The second they do that the entire presentation has lost its focus and the audience has lost interest.
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
Ok, I may have over exaggerated with the title but I do have an interesting story behind it. Before continuing I think it’s important to quickly cover what code reviews are.
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.
For those of you hoping that this post will cover all the different financial options while buying a house you may be slightly disappointed. This post is about comparing some programmers philosophies to how most people rent or buy property.
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!
