Friday, September 28, 2012
We spruced things up a little bit, created a new UI, and also created some new features & sections - some on the front end, others on the back end. What many people will notice is that the APEX URL syntax is missing. We decided to use mod_rewrite rules to give each page a more search engine friendly URL. How we did all of this - and how it requires zero maintenance - is a great subject for future post.
Have a look and let me know what you think! I'll be the one in the corner feverishly working on my OOW presentations.
Monday, September 24, 2012
During my research, I came across what is perhaps the best step-by-step document for configuring Oracle Wallet that I have seen. Jeff Hunter's blog walks through the process in great detail, accounting for even the most minor of details. You can see his Oracle Wallet post here: http://www.idevelopment.info/data/Oracle/DBA_tips/PL_SQL/PLSQL_19.shtml
While this is definitely not something that I'll need daily, it's definitely getting bookmarked for the next time I'm faced with configuring Oracle Wallet.
Wednesday, September 19, 2012
Sunday, September 16, 2012
With the introduction of the iPhone 5, one new feature has more people abuzz than any other: the new adapter. Instead of the traditional 30-pin dock connector that has become ubiquitous in everything from consumer electronics to luxury cars, Apple has opted to introduce a new, proprietary 8-bin connector dubbed "Lightning". I think that I speak for most of us Apple product owners when I say that as soon as this was announced, you did a mental tally of all of the devices and cables that would eventually have to be replaced, and I wasn't too happy with the resulting number.
Yes, it will be a pain to replace all of my cables and devices that use the older connector, but we'll all complain about, get angry, and eventually over time, forget about it. Like the CD drive. Or floppy drive. Or the replaceable battery.
My point here is not to get into a "who innovates more" argument, but rather highlight a type of innovation that is very much organic to Apple and its overall strategy: platform innovation. Apple is more than willing to take the bold step of admitting (or what some may consider dictating) when a feature or product has seen better days, and simply eliminate that feature entirely.
Let's start with the floppy disk. With the original Mac, Apple bucked the industry and chose a newer, smaller format for it's floppy disk. In this case, different was good, as it had a higher capacity and was much more durable that it's 5 1/4" counterpart. It took a few years, but eventually, Macs and PCs alike both standardized on the 3 1/2" floppy as their standard drive.
Despite Apple's introduction of the 3 1/2" drive, it was also the format's assassin, as as they eliminated any floppy drive on the original iMac. At the time, this seemed like a dangerous move, as a lot of software was still distributed via floppy disks, and almost all documents were saved on them if they needed to be moved to another workstation. But over time, all other manufacturers followed suit, and now you'd be hard-pressed to find any PC or Mac with a floppy drive.
Next, consider OS X. Initially, any older Mac application writen for System 8 or 9 would run in an emulator dubbed Rosetta. This was great and even necessary, as initially there were few native applications built for OS X, and Apple needed to ensure compatibility. But at some point - and I can't remember the specific release - Apple said no more emulation. Many of us grumbled that we'd have to re-purchase the same software for the newer OS, but we all did, and I think that OS X is better for having eliminated this type of legacy support.
Apple also killed the removable battery - first in the iPhone, and later in the MacBook line. This decision allowed for larger, more expensive batteries that would in theory give you more usage time. I do believe that the verdict is still out on this one, as Apple's competitors use this as a weakness to this day, as few others have adopted this strategy.
This brings us to the new dock connector. Of course, its too early to tell what will happen as a result of this. My prediction - given past history - is nothing. Once the 3rd party market starts cranking out $5 adaptors, this perceived pain will vanish, and we'll forget about any impact that this decision has made. Apple will, once again, benefit from being able to determine if and when something is no longer useful, and force that decision upon its customers, for better, worse, or nothing at all.
This strategy can be applied to how we develop applications, too. There will come a time when an old technology or feature or even method simply does not apply anymore. The pain of removing the outdated component is always perceived to be high, but the relief of a better alternate approach over time will benefit everyone.
Implementing a platform innovation is never easy, and often they are done in the wrong places. But when they are done properly and in the right places, we all benefit in the long run.
Friday, July 27, 2012
If you missed out on this year's KScope conference, you missed out on a tremendous amount of APEX content. You missed the APEX 4.2 preview and discussions from Oracle. You missed great sessions on the APEX Listener, jQuery, Dynamic Actions, etc. You missed the opportunity to actually meet some of the best APEX experts on the planet.
Fear not! APEXposed has you covered!
APEXposed is a 2-day conference focused exclusively on APEX technical sessions. A subset of the presenters from KScope will be presenting their sessions again in Montreal, Quebec this September 11th & 12th at the Centre Mont Royal. And the best part? You can attend this 2-day conference for as little as $350! That's less than $30 per session!
If you register by August 15th and use the discount code ENKITEC, you'll get the $350 price. If you wait too long, the standard conference rate of $450 will apply, but the discount code will still be good.
Hope to see you in Montreal!
Saturday, July 07, 2012
CREATE TABLE widgets (widget_type VARCHAR2(10)) / DECLARE z NUMBER := 1; BEGIN FOR y IN 1..10 LOOP FOR x IN 1..10 LOOP INSERT INTO widgets VALUES ('Type ' || z); z := z + 1; END LOOP; z := 1; END LOOP; END; /If you wanted to sum them based on type and just see the first five types, you can use a simple SQL statement like this:
SELECT NULL link, widget_type label, COUNT(*) value FROM widgets GROUP BY widget_type ORDER BY 2Which will in turn, produce a chart that looks like this: Clearly, not what you may expected, as you only wanted to see the top 5 widgets, not the top 5 plus all additional records grouped into an "other" slice. Visually, this may be misleading to the user. To get just the top 5 records, we have to use an inline SQL statement that will select from our original SQL statement and limit the results to just 5 records:
SELECT link, label, value FROM ( SELECT NULL link, widget_type label, COUNT(*) value FROM widgets GROUP BY widget_type ORDER BY 2 ) WHERE rownum < 6With this approach, we let APEX create the chart and append the Other slice to the results. We then siphon off just the first five records, which in this case, will not include the Other slice. The result is something closer to what many users would expect: Using this approach, the value of the Maximum Rows can be set anything greater than or equal to the value compared to ROWNUM in the last line of the second SQL statement, as we will be using the WHERE clause to limit how many records are displayed.
Thursday, June 21, 2012
Well, it's official. I am no longer a small business owner.
Starting today, I will be working for Enkitec, heading up their APEX products division. Here, Doug Gault and I will be responsible not only for our existing APEX products - the freshly renamed eFramework and eSERT - but charted with bringing several more to market in the next few months.
I'm as excited as they are about this acquisition, as the match makes a lot of sense. A great deal of their business is based on services, so our APEX knowledge will come in to play daily there. We'll also be able to get some additional resources for our products & training verticals, so expect to see more announcements on that front - some as soon as next week!
Wednesday, June 13, 2012
Page Zero in APEX is a powerful tool. For the uninformed, it allows you to put APEX components on it and have them render on every other page in your application - unless conditionally set to do otherwise. Components supported on page zero include regions, items, buttons, branches, computations and dynamic actions.
For years now, anytime that I needed a region or item or button on more than one page, I would put it on page zero, and if needed set the condition to display as needed. It saved a lot of time, as I would only need to create the component once, and was a lot easier to manage as there was only one copy for multiple pages. As you needed that component to render on additional pages, all that was required was a small change to the condition.
Thus, the combination of Dynamic Actions on Page Zero is quite powerful, as once you define a Dynamic Action, it would be available on each and every page. Add a couple of Dynamic Action Plugins to the mix, and you can create some powerful, reusable components in your APEX applications.
But like almost anything else, too much of a good thing is also bad for you. I recently started using a plugin that allows you to pop open a region on a page via dynamic action in sumnevSERT. Initially, our requirements were simple - show a single region and allow the user to edit a couple of fields. But as development progressed, the requirements got more and more sophisticated. In some cases, the region needed multiple conditional items and even a report.
At this time, we took a step back and had a look at page 0, and it was a mess. Over 30 dynamic actions, several regions, items and buttons - all of which would render on almost every page - were present. Since we didn't know which dynamic action or region would be required, we had to render most of them on most of the pages in the application, thus reducing performance and adding a whole lot of complexity.
We fast realized that there had to be a better way. After some research, we found a different plugin that supported popups based on pages, not regions. While it did take some re-tooling, it was a lot easier to manage these popups as individual pages, as development could use almost all default functionality and require few, if any, conditional components. Since the page would only render when requested, the application became much more efficient. We reduced the number of dynamic actions on page 0 to 8 and eliminated all additional regions, items and buttons. This was a huge savings not only for immediate performance, but for overall manageability of the application.
Lessons learned here - don't get too attached to any specific plugin or technique that you become blinded by it. I've often advocated the use of page 0 and will continue to do so, but that recommendation should be taken as such, not as an absolute rule that can not be bent. If you find yourself in the same scenario, it may be time to retool your approach as well.
Thursday, May 10, 2012
Joel Kallman has an interesting and amusing reaction to a recent Gartner paper authored by Mark Driver posted here. After reading Joel's reply and Mark's paper, it got me thinking a bit about what was both in and not in the Gartner review and conclusions regarding Oracle Forms migration paths.
But before that, let's consider the longevity of Oracle Forms. Oracle has pledged support for Forms time and time again, and despite the negative stigma that Forms usually drags along with it about being an older technology, it's a perfectly good place to leave any existing applications and perhaps even build a few new ones. Thus, if you have no immediate need to urge to migrate, then simply don't do it. In fact, a new version of Oracle Forms - 12c - is already in development and will integrate with Fusion Middleware 12c.
If you're a Forms customer and for whatever reason want out, there's a number of different options that you can take, all of which are highlighted in the paper:
- Migrate to Oracle ADF
- Migrate to Oracle APEX
- Migrate to a non-Oracle platform
I'm going to ignore the third option - not because it's not a viable one, but my point lies elsewhere.
Given that exclusion, which works best as a Forms migration platform - ADF or APEX?
In the paper, Driver makes a very clear case for ADF over APEX. He considers APEX a tool targeted at "citizen developers" and considers it "less suited for elements of Oracle Forms applications with more complex business logic requirements". He also states that APEX has "very limited support for advanced software development life cycle (SDLC) and application life cycle management (ALM) feature and best practices (e.g., no team support and no direct source code versioning).".
Five years ago, I may be tempted to agree with some or part of that. But clearly not today. APEX 4.1 is a major upgrade from what was available in versions 3.2 and prior. While it definitely excels at building small, "quick hit" type applications, all - not some - but each and every one of our clients are also using APEX for mission critical and essential systems on a daily basis; Applications that drive their primary business operations, whether those are academic, commercial or governmental in nature.
Since 4.0, APEX has incorporated a "Team Development" module, aimed at facilitating the development, bug tracking and release process of APEX applications. The APEX team at Oracle actually uses this tool to track the development of APEX itself. APEX can also work quite well with any source code control system, although not directly. But since most developers put their business rules in PL/SQL, that tends not to be an issue, as all popular PL/SQL IDEs have direct integration with source code control.
While those misstated facts are bothersome, I don't believe they are intentional. I can easily get past them, as we all make mistakes from time to time. What I have a harder time accepting are the misleading statements in the following excerpt:
Select a migration target platform carefully. We believe the least risky (and often the least costly) migration path forward from Oracle Forms is Oracle's JDeveloper IDE and ADF — especially for application leaders who plan to retain their existing programming staff.
Now I have taught countless APEX training classes and have talked to many, many Oracle customers over my 15+ years of working with Oracle products. Never have I ever heard a single person highlight how much easier Java is than APEX. Some put APEX on par with ADF, and others think that ADF as a whole is better suited for enterprise development, and I can't say that I disagree with those assessments. Clearly there is some bias in my sample, but the most vocal of the group were those who were professional developers, not "citizen developers".
As for costs, I'd like to see some figures or numbers behind that argument. Not only is there the possibility of saving some license costs by moving to APEX, but many of our customers actually save on consulting costs by being able to take full ownership of the applications once we deliver them. They don't need to hire consultants to continue to maintain their applications, as they almost always learn how to do that themselves, either from training or their own experience with APEX.
Unless Driver advocates firing your existing staff and starting anew with fresh college graduates for about half the salary, I don't see what basis he is using for his point about retaining programming staff. Allow me to be blunt for a moment: most Oracle Forms developers know PL/SQL and the Oracle Database very well. Given the age of Oracle Forms, most Forms developers are closer to retirement than they are their first day on the job. What type of developer is willing to forego 20+ years of experience in any technology and start fresh learning another technology 3/4 of the way through their career?
The key factor that was largely ignored in this and so many other migration papers is simple: people.
APEX gives developers a new lease on life, so to speak. It gives the PL/SQL developer a chance to once again shine by building web-based applications that their customers will not only love, but want to use. It keeps resources in place with minimal training, and also preserves the years and countless dollars invested in the PL/SQL packages that have been finely tuned over the years.
Java - much like any other programming language - takes years to master. I have tremendous respect for those who have done so. Experts are not made overnight, they are crafted over many, many years of experience. No book or class can substitute for that. Driver's advice assumes that a PL/SQL programmer is the same as a Java programmer, or at least a PL/SQL programmer can easily be made into a Java programmer with a couple weeks of training and a good book. This assumption is just plain wrong, and almost fatally damages his justifications against APEX as a viable Oracle Forms alternative.
As soon as I posted this entry yesterday, I thought of a few additional "rules" that probably should have been included. Pitor's comment also spurred on an additional rule. So without further adieu, here they are:
Learn 'em and stick to 'em. Period! Most modern browsers do pretty well with them, so the closer you are to them, the better off your site will be in the long run.
Ignore Old Browsers When Possible
Take a page from the Apple playbook here, and simply stop supporting browsers that are too old, despite the fact that they may still be in use. (I'm looking at you IE 6 & 7…) Be careful with this one, as you may have no choice but to support some of the older browsers, based on your customers or potential customers. We wanted to be sure to provide support for at least IE 7 and above, and that decision did add some time and effort to our design process. We did this because some of our existing and potential customers - at least for the short term - are running IE 7. Not having support meant not having customers, so the decision was quite simple.
On the other hand, not for a single second did we consider supporting IE 6. At the beginning of the development cycle, we did have a couple of prospects on IE 6, but we took a gamble that by the time we were production, they would be on at least IE 7. That gamble paid off, and we saved countless hours by avoiding IE 6.
Identical Look & Feel Across Browsers in Unachievable
This is another rule to address up front to save a lot of time later. Your application will look a little different on IE than it will on Firefox or Chrome or Opera. And that's OK. In fact, it's unavoidable. Throw in the way that the Mac renders and smooths fonts vs. how Windows or Linux does it, and you'll have even more differences.
Thus, making the site look similar across browsers is a more achievable goal than striving for perfection. Unlike most developers, most users are are "single-browser" users, so they will never know the difference at all.
When in Doubt, Hire Someone
Either you're a graphic designer, or you're not. If you're somewhere in between the two, then it will take your users about 2 seconds to realize that. Thus, know your limitations. There's plenty of free or low cost templates that you can use, and a decent graphic designer also won't set you back too much. At the end of the day, the way your application looks and feels is critical, and will make a lasting impression on your users and potential customers. Don't cut corners here and don't be afraid to seek assistance from a professional.
Wednesday, May 09, 2012
However, when designing a product, you simply don't have that luxury anymore. Your application must now not only run but look good on all popular versions of popular browsers: MSIE, Chrome, Firefox and maybe even Safari. And if you think that these browsers behave exactly the same on different operating systems, you're completely wrong.
As we put the final touches on sumnevaSERT v2.0, I wanted to share some of the experiences that I went through over the past few months with regards to user interface - mostly so that you can learn from my mistakes and plan accordingly.
Design and stick with a Design PatternThis is the most important step. If you skip it, or do it poorly, it will flow throughout your entire project and come back to haunt you on a daily basis.
Simply put, a design pattern is how different components will be laid out on the page. It's OK and quite often that you have two or three variations of this (one-level tab vs. two-level tab, sidebar vs. no sidebar, etc.).
Once a design pattern is defined, do all that you can to not stray from it. If you designed the HTML & CSS to work with 2 columns of reports, then stick to that. APEX templates are flexible to a point. Once you cross that point, not only do your applications start to look "busted", but issues with usability will start to arise on at least one of the browsers.
It helps tremendously to use a tool such as Balsamic Mockups to come up with a design pattern for your site.
Design and test the Templates firstOnce you have a design pattern, it's time to convert that to APEX templates. While this is also one of the most important pieces of advice, it's also the one that you will undoubtedly fail on. It's 100% impossible to get this all done up front, so set your expectations accordingly. However, if you can get some portions of the templates done before you start adding content, that will go a long way later on.
While designing your templates, keep the HTML as clean as possible - do not use any inline styles or other tags that could be interpreted differently by different browsers.
Also, I usually start with a clean Theme, and only use the APEX provided templates as a guide. There is no application out there that needs all 75+ templates that the APEX themes provide. Thus, I typically start with a brand new theme and build that up as needed.
Another trick that I have used forever is how I name my templates. APEX template names are too specific - "Form" region, "Report" region, and "Chart" region all look the same to me - and they should! Thus, I create a single region called "Content Region", and use that for all content - Forms, reports, charts, trees, etc. If I need a second region, it's likely going to be called something like "Content Region - Narrow" - and as the name implies, will be narrow. This small change will go a long way in keeping the templates as usable and compact as possible.
Start your cross-browser testing NOWDon't wait until you more than a few days into development to start testing on different browsers. In fact, delegate a different browser for each day of the week for both development and testing to ensure that your application works well in all of them.
My advice: make Friday "IE day", as happy hour will never be happier.
Two (or more) CSS filesCritical when supporting most browsers and IE, you'll need to have at least two CSS files. I can't imagine putting all CSS classes into a single one and having all browsers play nice with it. You can start out with a single one, and when you hit a point where you'll have to clone it, at least you'll have a good solid base.
If you use a STYLE tag, you will payDon't use a STYLE tag. Can't emphasize this enough. It will come back to haunt you, as one browser will be OK with it, and others (i.e. IE) won't. At that point, you'll have to retro-fit your HTML to use classes, add them to both files, and re-test.
You'll be most likely tempted to do this when rendering HTML from PL/SQL, as if you use a STYLE tag, you don't have to open up another application to add the class, etc. Don't be lazy.