Branding ADF Applications

Author: Infomentum

Author: Nabil Makhout

Nabil presented his tips on branding ADF applications at UKOUG’s Apps 15 conference.

Every new application created with the WebCenter Portal framework and ADF comes with default styling that you extend from an out-of-the-box skin, like Skyros. But if every time we created an application with the default style, it would be a very boring and monotonous digital world. That’s where skinning comes in to brand your application to your company guidelines!

Why branding?

First of all, it promotes recognition of your brand and sets you apart from the competition. A brand is something you build over the years; customers know what to expect from your company when they recognise your brand. Strong brands build trust and customer satisfaction. Brands give potential clients a firm idea of what they are buying before they buy it, making the purchasing decision easier. Font-family, animations, colours, layouts and so many more factors contribute to building a brand. So branding has so many benefits for your company and your application. Now, let’s have a look how to do it.

Workflow to brand your application?

Use a build tool like gulp to automate part of your workflow. This helps you to stay focused on your code without needing to pay attention to the important, but repetitive, details. These tools allow you to write your code (hopefully) once, and reuse it throughout the development process. Build tools take care of minification, different versions for different environments, and while you are writing code you can get notifications that you have an error, etc. This is just scratching the surface. There is so many more things you can do with it. Have a look at gulpjs for more information.

You can also use SVG as icons. Personally, I like to use font-icons also known as glyphicons. Essentially, you combine SVGs into a font file and you can refer them in the CSS. The nice thing about this method is that you always have a JSON backup and the images are vector based. So you can make it bigger or smaller without losing quality! The annoying thing with a sprite is that you need to recalculate the background positions sometimes. Well, that’s history with your font-icons.

Dos and don’ts in development

- Do try dropping old versions of IE
- ADF comes with a lot of interactive components, so do try to stay away from js and do try to use best practices to get the solution you need
- Don’t use inline styles

I hope this helps other developers to brand your applications to your company’s style!

Mind the Communication Gap (or how not to run a penetration test)

Author: Infomentum

When customers and vendors fail to communicate, it’s a recipe for disaster – as one company learned only too well.

A company I have been talking to recently told me about a penetration test they ran on a website. It was not, as it turned out, the most successful of penetration tests.

It started out well. The site was in the process of being developed and they wanted to make sure they were aware of any issues before it went live. They knew they needed to appoint a third party to carry out the test and were very thorough in the appointing process, meeting with multiple vendors to be certain they had chosen the right team. So, after hours of meetings, PowerPoint presentations and lots and lots of talk, a vendor was finally selected to run the penetration test. They were good to go.

The dangers of going it alone

Unfortunately, in their haste to find the best third party, they failed to invite a single member of the internal IT team to any of their meetings, or bother informing the other vendors who were in the process of delivering the website.

A mistake that turned out to have big consequences.

The tests were run and a highly-negative report was submitted by the third party. According to the report, there were over 40 holes on the website – meaning it was total disaster in these days of greater demand for security and compliance.

Assumption is the mother of all screw-ups

Given the site had failed so spectacularly, the vendors who had been commissioned to develop it received an almighty roasting over the poor quality of their work. When they asked why had they not been aware of the penetration test and where had it been run from, they were told that the tests had been run from external sources. Which is when the full magnitude of the mistake was realised.

Given that the site hadn’t yet gone live, it wasn’t available for access from outside. So the other team of vendors simply couldn’t have been able to run the tests.

Right test. Wrong site.

It turns out they’d not run the test on the new site being developed, as required, but on the pre-existing site.

So, not only had the test had been a complete waste of time, money and energy, they’d also damaged their relationship with their vendors by blaming them for something they’d not done. Not to mention the fact they’d been running a site for three years that wasn’t fit for purpose.

In short, it was an embarrassment all round.

So, what can we learn from this story?

1)         Get your vendors working together

There will often be times when you have different teams of suppliers dealing with overlapping               areas of your business. The key is to get them to collaborate – to share their skills and                           knowledge so that everyone can do their best possible job. If they’re not willing or able to work               together, you've probably got the wrong people for the job.

2)         Garbage in. Garbage out.

A test is only as good as the information you put into it. If you don't take the time to get that                  right, the test will be a waste of time – not to mention money.

3)         Talk. Talk. And talk some more.

The key to every successful project is communication. Internal and external. Make sure that                   everyone who needs to be informed is informed.

And don’t forget to write the correct IP addresses on a noticeboard so that you know what’s what!

How Not to Run a Load Test

Author: Infomentum

What can we learn from one an example of failure?

We all know that running a load test on your site is best practice. By putting demands on your systems, you can discover the true capacity of your site, as well as identify any weaknesses and bottlenecks. That’s as long as you do it right of course.

One company, sadly, didn't.

Beware the celebrity tweet

A member of the senior management team for a known brand decided they needed to run a load test on their web channel. They had good reasons – they knew a celebrity was going to be tweeting about them and expected some heavy-duty traffic as a result. So they hired a third party to run the test. So far, so forward-thinking.

But, they made one little mistake. One that added up to a colossal waste of time. They failed to let their internal IT team know what they were doing.

Maybe they wanted to see how their IT team would react under pressure – after all, it wouldn’t have been a true test if their team had bolstered their systems in preparation. Or maybe they simply forgot. Either way, it backfired on them.

Protecting the business, failing the test

When the third party ran the heavy load test and the system started to receive load alerts, the IT team did exactly what they were supposed to do. They immediately picked up the unexpected hits on the web channel and swung into action. Since they weren’t aware of any testing, it simply looked as if they were under attack. So they blacklisted the relevant IP addresses and blocked all requests from that third party.

For the IT team it was a win. They’d successfully thwarted a suspected attack and by catching and blocking the source of the hits, they continued delivering uninterrupted service to their customers.

However, in terms of the test, it was a total failure. The third party submitted a failed test report to their customer. From their perspective the site had fallen over (and done so remarkably quickly). As a result, the business learned nothing about the site’s capabilities and wasted a whole lot of money in the process. And all because they failed to communicate with their own colleagues.

So what can we learn from this story?

1) Testing is a good thing. Ambush testing is not.

Yes, you need it to be a true test. But if everyone involved doesn’t have the same clear objectives, then the test will be a waste of everyone’s time (not to mention your money).

2) Consider different scenarios for increased traffic.

There are many reasons a site might experience heavy-duty traffic, from hackers to celebrity tweets. If you have a clear idea of the possible sources, you can have a plan in place for each that doesn’t always involve blocking access.

3) Communication is everything.

Enough said.

Follow infoMENTUM on Twitter