I was working on another post today and noticed that I had just exceed the 400,000 pageviews milestone! The next thing that caught my eye is that it has been 5 years to the day since my first post. So I thought I'd write an article reflecting the past five years.
I started this blog (initially called apex-smb.blogspot.com) to simply post some of code I was working on and elicit feedback from the community. Seemed simple to me: post some code and get free feedback. Over the life of this blog I certainly did get a lot of feedback. I also got a lot more than I had imagined. Since my initial post I have achieved many milestones that I didn't think were possible or hadn't even thought of when I first started. These include:
- Co-founding ClariFit
- Writing several books
- Becoming an Oracle ACE, then later ACE Director
- Working on various open source projects
By far the best outcome is the relationships I've built with people in the Oracle community around the world. This is especially true with the people that I looked up to (and still do) when I first started working with APEX (called HTMLDB back then).
I'm not going to say that this blog is the sole reason for everything that took place over the past 5 years. There were a lot of people that helped support and encourage me along the way. Without their continued support I don't think I'd be in the positive situation that I am in today.
This blog started out as a fun side project with no real motive other than to share code and help improve my writing skills. Turns out it changed a lot for me and went well past its initial intentions. The only "negative" thing (and I use the term very loosely) is that over the past few years I haven't had the same amount of time that I would like to allocate to writing articles at the same pace when I first started. This is primarily due to running a company, writing various books, working on open source projects, and my speaking engagements (and yes I realize that these are all "first world problems").
Going forward I plan to still continue writing. It's something that I really enjoy doing and I hope you, as a reader of this blog, enjoy as well.
Looking forward to the next 5 years!
- Martin
Wednesday, July 31, 2013
Thursday, July 18, 2013
APEXposed en Montreal - Sept 10/11
This fall ODTUG will be in Montreal for the 2nd annual APEXposed conference. Like last year, there's a star-studded lineup of speakers including Oracle's Director of Software Development, APEX's product manager, and Oracle ACE and ACE Directors. The one difference compared with last year is that we have some local speakers from Montreal and Toronto.
Some of the presentations that I'm looking forward to are:
- Joel Kallman's (Oracle Director of Software Development) talk on APEX 5.0, giving us an inside look of what's coming up in the near future.
- David Peake's (APEX Product Manager) talk on how to leverage some of the new features in 12c with APEX.
- Roel Hartman's (Director at APEX Evangelists) presentation on building mobile applications in APEX.
- Steve Feuerstein's (Dell) keynote. I just talked to him about it, should be great!
And, as shameless plug, I'll be giving two talks: "Instrumenting your PL/SQL and APEX Applications" and "APEX Development Best Practices". I'm really excited about the talk on code instrumentation as I'll be highlighted some of the new features that I've integrated into the 2.0.0 version of Logger and also share some of the new upcoming features.
If you're interested and yet haven't already registered for the conference you're in luck. It's still not to late to sign up for this 2 day (September 10th and 11th) conference. To register simply go to http://www.odtug.com/apexposed and sign up.
See you in Montreal!
Friday, July 5, 2013
It's up to You - Oracle and APEX Open Source Projects
At ODTUG Kscope 13 last week I got to moderate the APEX Lunch
& Learn experts panel. One of the questions that came up was
when a certain feature was going to be added to Peter Raganitsch's APEX Developer Addon.
This sparked a bit of conversation around open source projects in the Oracle and APEX communities. They're a few people who create and maintain these open source projects. Unfortunately they're not a lot of other people who contribute to these projects. Because of this, projects don't get upgraded and enhanced as quickly as they could.
It's up to all of us in the community to enhance open source projects. Next time you need a new feature added to a project, instead of asking for it, I encourage everyone to add it yourself then contact the developer with the changes so it can be implemented to the project.
On a personal note, I'm heavily involved with several open source projects. The two most popular ones are Logger and the ClariFit APEX Plugins. I just moved the ClariFit APEX Plugins to GitHub yesterday to make it easier for others to contribute to.
This sparked a bit of conversation around open source projects in the Oracle and APEX communities. They're a few people who create and maintain these open source projects. Unfortunately they're not a lot of other people who contribute to these projects. Because of this, projects don't get upgraded and enhanced as quickly as they could.
It's up to all of us in the community to enhance open source projects. Next time you need a new feature added to a project, instead of asking for it, I encourage everyone to add it yourself then contact the developer with the changes so it can be implemented to the project.
On a personal note, I'm heavily involved with several open source projects. The two most popular ones are Logger and the ClariFit APEX Plugins. I just moved the ClariFit APEX Plugins to GitHub yesterday to make it easier for others to contribute to.
Tuesday, June 4, 2013
Logger 2.0.0 - Released!
After several months in Beta, I'm please to announce that Logger
2.0.0 is now officially released! You can download the zip file from the
2.0.0 release page.
Over the past few months I've blogged about some of the significant changes we've made to Logger. Here are all the articles describing some of the new functionality:
If you've never used it before check it out, best of all it's free and open source!
Over the past few months I've blogged about some of the significant changes we've made to Logger. Here are all the articles describing some of the new functionality:
- Alpha (contains some high level change notes)
- Beta (contains some installation upgrade notes)
- Enable Session Specific Logging
- Session Specific Logging - Advanced Features
- Logging Parameters
If you've never used it before check it out, best of all it's free and open source!
Wednesday, May 8, 2013
Logger 2.0.0 - Session Specific Logging - Advanced Features
In preparation for the release of Logger 2.0.0 I've decided to write a few posts highlighting some of the new features.
In my previous post I covered how to set and unset session specific logging based on the Client Identifier. In this post I'll cover some advanced options for this functionality. Before continuing, please be sure to read the previous post or else this won't make sense.
In the previous post the demo code to set a session specific logging level only used two parameters: the logging level and the Client Identifier. In logger.set_level they're actually four parameters:
p_level
This is the level to set. If p_client_id is null then it will set the system level configuration in logger_prefs > LEVEL.
The additional parameters are only valid if p_client_id is defined.
p_client_id
If not null, will apply p_level for the specific client_id only. If null then p_level will be applied for the system level configuration.
p_include_call_stack
Determines if the call stack should be stored. If null then will use the default setting in logger_prefs > INCLUDE_CALL_STACK. Valid values are TRUE and FALSE (strings).
p_client_id_expire_hours
Will end session specific logging after set hours. If not defined then the default setting will be used logger_prefs > PREF_BY_CLIENT_ID_EXPIRE_HOURS. Note that this will not be exact as a job is run hourly to clean up expired session specific logging that has expired for a given client_id. Instead of waiting for the job to clean up expired sessions you can explicitly unset them.
How to View All Client_id Settings
To view the system level settings you can use the logger.status procedure. There was debate as to whether or not we include all the client_id settings in this procedure. In the end we did not include it list them in this procedure as the list may get very long. To view all the session specific logging configurations use the following query:
Renewing
When calling logger.set_level with a client_id that already exists in logger_prefs_by_client_id it will update the values and update the expiry date (i.e. you extend the setting).
In my previous post I covered how to set and unset session specific logging based on the Client Identifier. In this post I'll cover some advanced options for this functionality. Before continuing, please be sure to read the previous post or else this won't make sense.
In the previous post the demo code to set a session specific logging level only used two parameters: the logging level and the Client Identifier. In logger.set_level they're actually four parameters:
p_level
This is the level to set. If p_client_id is null then it will set the system level configuration in logger_prefs > LEVEL.
The additional parameters are only valid if p_client_id is defined.
p_client_id
If not null, will apply p_level for the specific client_id only. If null then p_level will be applied for the system level configuration.
p_include_call_stack
Determines if the call stack should be stored. If null then will use the default setting in logger_prefs > INCLUDE_CALL_STACK. Valid values are TRUE and FALSE (strings).
p_client_id_expire_hours
Will end session specific logging after set hours. If not defined then the default setting will be used logger_prefs > PREF_BY_CLIENT_ID_EXPIRE_HOURS. Note that this will not be exact as a job is run hourly to clean up expired session specific logging that has expired for a given client_id. Instead of waiting for the job to clean up expired sessions you can explicitly unset them.
How to View All Client_id Settings
To view the system level settings you can use the logger.status procedure. There was debate as to whether or not we include all the client_id settings in this procedure. In the end we did not include it list them in this procedure as the list may get very long. To view all the session specific logging configurations use the following query:
select * from logger_prefs_by_client_id;
Renewing
When calling logger.set_level with a client_id that already exists in logger_prefs_by_client_id it will update the values and update the expiry date (i.e. you extend the setting).
Subscribe to:
Posts (Atom)