Search Blog

Blog

Get the latest on what's happening at itomic

Informative commentary on the web industry from the experts at Itomic.

ross | Itomic Web Design Perth & Melbourne March 16, 2018

Itomic doubles data for hosting clients

By Ross Gerring

Today, Itomic has (at least) doubled the monthly data available to shared hosting clients, at no additional cost. Enjoy!

Package Before After
Basic 1Gb 2Gb
Economy 2.5Gb 5Gb
Business 5Gb 10Gb
Enterprise 10Gb 25Gb
Corporate 25Gb 50Gb
Global 50Gb 100Gb
Global Plus 100Gb 250Gb

 

More details here: https://www.itomic.com.au/services/website-hosting/


ross | Itomic Web Design Perth & Melbourne

Google Chrome to mark all HTTP sites as insecure from July 2018

By Ross Gerring

 

An image hosting how Google Chrome will mark HTTP sites as not secure from July 2018There are two types of websites: HTTP and HTTPS

The ‘S’ signifies that the data being exchanged between the site (where it’s hosted) and the people (or robots) interacting with the site is encrypted. If it is encrypted, then it’s safe from prying eyes, malicious or otherwise.

Let’s take the example of when you fill out a ‘Contact Us’ form on an HTTP website. When you click ‘Send’, this information is being transmitted across the internet, in plain text, between your device and a web server. Arguably, this level of privacy – or lack thereof – isn’t a huge deal for the information you might provide on a ‘Contact Us’ form. But privacy becomes much more of a huge deal when more sensitive/confidential information is being exchanged. Like medical records, financial information, and suchlike.

Where to draw the line between what’s confidential and what’s not? What should be encrypted and what doesn’t need to be? There’s no single answer, because clearly there’s a lot of room for subjectivity.

Solution: encrypt everything, just to be sure. Encourage ALL websites to be HTTPS and not HTTP.

The good news is that Google, using its Chrome browser, is doing just this, from July 2018. If your site isn’t on HTTPS from July 2018, then Chrome will clearly mark it as “Not secure”.

Remember: SSL certificates are like condoms: you can have one, you don’t have to use it, but you should.

Itomic hosts multiple websites. We will be working with our hosting clients to ensure that all the sites we host are HTTPS by July 2018.

Further reading:


ross | Itomic Web Design Perth & Melbourne January 22, 2018

How Much Project Planning is Enough?

By Ross Gerring

Man wearing black and white striped shirt looking at bits of paper on wall, planning his next project.You’ve got this brilliant idea for a new web-based thingy. “The Next Facebook”, if you will. Let’s assume the basics such as:

  • You have some funds available to give it a shot.
    You’ve done sufficient research to convince yourself that there’s a place in the market for your thingy.
  • What now?

Compare these well-worn business quotes:

Vision without action is a daydream. Action without vision is a nightmare

Failing to prepare is preparing to fail

The first one doesn’t mention planning at all, but emphasises the criticality of both Vision and Action.

The second makes it patently clear that if we don’t plan (prepare), then we’re setting ourselves up for failure, which no one wants.

So let’s take Vision and Action as a given.

But how much planning to do? How much is enough?

Which of the following are you?

Person A: “We’re Americans. We don’t plan. We do!”

A wonderful quote from the movie “Night at the Museum: Battle of the Smithsonian”.

You’d better make sure that:

  • Your vision is very clearly defined and understood by your developers.
  • Your developers are the type who like the freedom to innovate towards a common goal. Some developers dislike this, much preferring a detailed plan before they write a line code.
    You’re checking in very regularly on the project to make sure it’s staying on track.
  • You choose an Agile project management methodology

Person B: The Perfectionist

You like to plan out everything in advance, down to the last nut and bolt, and you’re not going to start development work until it’s all down on paper.

  • Will your project ever see the light of day, because you are striving for perfection? Accept that sometimes close enough is good enough.
  • Detailed planning takes time and energy and focus. The world is changing while you’re nutting all this out. Will the world have moved on in the meantime?
  • Who’s to say that your perfect plan is perfect? Assuming you’re taking feedback during development, then what gets built will be different to some degree from your specification, guaranteed. Thus your document is a guideline, not a gospel.
  • Choose a Waterfall project management methodology with its well defined structure and phases.

Person C: Somewhere in between

Just like in politics, a blend of both is likely to be your better bet for project success.

  • Your Vision still must be clear in advance. Never compromise on that.
  • Study Lean project management.
  • Focus your planning on the fundamentals/foundations of what you want to achieve, not the window dressing. Use the MoSCoW method to help decide what’s truly important, and what’s not.
  • Have the courage to validate your project in the marketplace, sooner rather than later. At least plan for your MVP (minimum viable product).
  • Learn and adapt accordingly. Ensure your developers know to expect change, and to code accordingly, allowing for flexibility. Some developers are much better at this than others. The technical team lead will know the difference.
  • Accept that change costs money. Remember that one of the most commonly quoted reasons that software projects fail is because of insufficient funding.

There is never a guarantee of business/project success, but that doesn’t stop approximately 11,000 new books per year being published on the subject in the USA. You might be a visionary like Steve Jobs or Richard Branson. But behind those great leaders you can bet there’ll be planners, and their plans.


ross | Itomic Web Design Perth & Melbourne October 12, 2017

SSL certificates are like condoms: you can have one, you don’t have to use it, but you should.

By Ross Gerring

Website with ssl certificate - green address bar in browser window

Like condoms, there is a major difference between having an SSL certificate, and using that SSL certificate. If you have one, but don’t use it, then you don’t enjoy the benefits.

Using an SSL certificate for your online site or application is a good and important thing. How do we know this? Because Google says so.

How do you check if you have an SSL certificate and, critically, whether it’s any good?

Here’s our favourite test using our own itomic.com.au domain name by way of example. Just replace our domain with yours:

http://sslshopper.com/ssl-checker.html#hostname=itomic.com.au

You should see all ticks, and no crosses. If you see any crosses for our domain name, please let us know!

If there are any crosses (failures) in the sslshopper report, then you want to get those fixed. No point using a condom if it’s got holes in, right? Speak with your web developer and/or hosting provider.

How do you check if you’re using your SSL certificate?

If you visit the http (non-SSL) version of your site, e.g. http://www.itomic.com.au, does it immediately auto-redirect to the https (SSL) version, e.g. https://www.itomic.com.au? If it doesn’t, then you might have a good SSL certificate available for use, but you’re not using it, and you need to be. Speak with your website and/or hosting provider.

FYI this auto-redirection from http to https is known as “Always On SSL” (AOSSL) or “HTTPS Everywhere“.

Further reading:

Secure your site with HTTPS (Google)
What is SSL, TLS and HTTPS
(Symantec)


ross | Itomic Web Design Perth & Melbourne September 13, 2017

Help Me Help You. What makes a great software bug report

By Ross Gerring

At Itomic we love helping our customers.

Tom Cruise saying "Help Me Help You"

We know that they love the convenience of being able to send an email to our support email address. This action automatically creates a support ticket for them. Thereafter, they can choose to continue the support conversation 100% via email. And/or they can choose to login to our support ticket system to view and manage all current and historical tickets.

But there’s a problem.

By allowing emails to be sent as support requests – instead of forcing clients to fill in structured online forms – the helpfulness of the information initially provided can vary a lot. Often our first (human) response is to ask them to provide all the missing information that will help us to help them better and faster. Anyone who’s ever been the recipient of tech support requests via email will know what we’re talking about.

What’s the solution?

Education. Helping our clients to help us to help them, by letting them know what a great software bug report looks like.

But we can’t expect clients to remember this all the time, to keep a bug report checklist pinned to their monitors.

So this is what we’ve done: each time a new support request is received by email, the auto-response received by the sender contains a brief list of what makes a great software bug report. Sure, it might be too late for the support request they’ve just made.  But we reckon that, over time, this information can only produce better and better results – for everyone.

And what does this checklist look like? Here it is:

  1. Does you website appear to be down (offline)? Is so, use this excellent tool to see if it’s down for the rest of the world, or just you: https://geopeeker.com/
  2. A screenshot is worth 1,000 words.
  3. Impact? Is this a mission critical showstopper, or more of an annoyance?
  4. When was the issue first spotted, approximately?
  5. If you’re seeing an error message, please tell us exactly what it says (if the screenshot doesn’t).
  6. Steps to reproduce the issue? If someone else reported this to you, can you reproduce yourself? If we (Itomic) can’t reproduce it, then the issue is *probably* localised to a single PC or your local area network, and you may need to contact your local PC/network support person for additional support.
  7. Is the issue intermittent or permanent?
  8. URL (website address) where the problem is occurring?
  9. Do you have to be logged-in to see the issue? If so, which account are you logged in as (typically an email address)?
  10. Can you think of anything that’s happened recently to your site that might have triggered this issue? Major content edits? Users being added/deleted? New add-ons installed?

Suggestions for improvement always welcome!