Speed Up Development with Logger: Part 2

Last week I wrote about how to speed up development with Logger using text expanders. Today's post will show you how to leverage Logger's method template to quickly create procedures and functions.

I'm a big fan of SQL Developer for most of my Oracle development, however I do leverage other text editors for some functionality when developing. Atom is an an open source text editor with builds for Windows, Mac, and Linux. If you've used Sublime before, it's very similar. They're a few features of Atom that I regularly use such as column editing (modifying multiple columns of text at the same time) and global text replace (in real time, not via a find & replace dialog). 

When creating a new function or procedure I usually use the Logger Template and modify its TODO items. The video below shows how I quickly start developing a new method and leverage all the features of Atom.

A few things to note about the video:

  • I used some text expanders to quickly insert my name (ome) and the date (otoday).
  • I used a lot of shortcuts in Atom which are quickly shown on the screen. A complete list of shortcuts are available here.

 

Speed Up Development with Logger

One of the first reactions we get when introducing Logger to developers and managers is that it will slow developers down by having to write additional logger.log statements. This couldn't be further from the truth.

Instead of manually typing out each log statement you can easily use a text expander. Text expanders allow you to register shortcuts which then auto expand when you're developing.

For example, when I type ologl (the prefixing "o" stands for Oracle shortcuts in my setup) in any editor it expands to logger.log('', l_scope);. The following video demonstrates some shortcuts that I use (full details below):

Popular ones I use are:

ologe

logger.log_error('', l_scope, null, l_params);

ologv

logger.log(logger.sprintf('TODO: %s', TODO), l_scope);

olog5

select *
from logger_logs_5_min
where 1=1
  and scope like '%%'
-- and client_identifier like 'MD%'
--  and id > TODO
order by 1 desc;

oproc - This will expand to a procedure template as defined in the Best Practices document.

Of course you can use the same technique for other code snippets that you frequently use.

They're lots of great apps out there for text expanders. Some that I recommend are:

  • Mac: aText
  • Windows: PraseExpress
  • SQL Developer: Jeff Smith as a great blog post about using the built in text expander in SQL Developer.

Feel free to recommend other text expander apps in the comments.

For more development tips please read the entire series:

Logger 3.0.0: Developers Guide

It has been great to see so much interest in Logger and people's willingness to contribute to the project. One thing that has stood in the way with helping has been the ability to get started developing with Logger. 

The development process has never been well documented before. Starting with Logger 3.0.0 there is now a Development Guide to help developers get familiar with the development process so they can help enhance the project.

For those interested in helping develop and shape the future of Logger we hope this new document clarifies any issues you may have had in the past. If there's anything that isn't clear or that you find missing please submit an issue and we'll clear things up.

Once you've read the Development Guide and you're ready to help out, take a look at the issues in the upcoming releases for some items to work on.

Logger 3.0.0: log_warn and log_info shortcuts

If you use logger for an extended period of time it may be frustrating to write out the full name for logger.log_warning and logger.log_information. Starting in 3.0.0 you can now use the shorter form version logger.log_warn and logger.log_info.

We must thank Github user @hronek for submitting this idea and pull request.

Logger 3.0.0: Global Level Names

In the past, when setting the level in Logger you needed to use text names. For example:

exec logger.set_level('DEBUG');

Going forward you can (and should) use the global names for the different levels. From the above example, you can now use the following to set the level:

exec logger.set_level(logger.g_debug_name);

One small thing to note is that all procedures that take a p_level parameter now accept both the number or text value for the level. The following does the exact same thing as above, but uses a number rather then name for the level.

exec logger.set_level(logger.g_debug);