Talks

When we build a website these days, there’s a 110% chance that it’s got some form of JavaScript on it. Whether it’s a full framework, for animations, to trigger a popup or as a tracking script, JavaScript is all around us.

But what if I told you that you didn’t have to use JavaScript at all? Not even as a build process? Thanks to updates in browser technologies, there’s now a plethora of native browser features that allow building modern, functional websites, sans JavaScript.

So together, we’ll build out a completely static website, a collection of HTML and CSS files, no tracking, no scripting, no servers, no third party resources. Let’s build a website the way we used to (but no marquees).

While testing is important, we’d much prefer if we didn’t have to think about it, if it just happened like magic.

We know we have to write tests to make sure the buttons can be clicked, the data can be received and the page continues to look the way it should, but once the tests are written, are they actually being run?

We’ve been integrating our end to end tests to ensure they run on every commit or every pull request, but front end tests require a live version of our website to run tests, you can read CSS code in a pull request but that doesn’t tell you if it’s affecting the website the way you intended it to. Thankfully GitHub Actions makes it easy to fix this, to get a live version of our website and run our front end tests against it before the code gets merged and deployed.

Together we’ll build out an action workflow (that can be integrated with your existing end to end tests if you’ve got them), write some front end tests and put together a bulletproof continuous deployment pipeline.

In a world where technology use is becoming a necessity rather than a shiny toy, gone are the days where a household didn’t even own a computer, instead everyone over the age of 5 is expected to have at minimum a smart phone or tablet.

But as we build the digital tools that people need for their day-to-day, we can accidentally put barriers in the way of those with disabilities, preventing them from using the tools, preventing them from being a part of our technology dependent society.

Not everyone uses technology the same way, which is why making sure we’re building accessible technologies is so important, why we need to ensure that everyone can use it, even in ways that are different from how we expect.

Join me as we look at how we can make our technologies more accessible, who benefits (spoiler alert, it’s everyone) and why it’s everyone’s responsibility to make this possible and not just “someone else’s job”.

Over the years, WordPress has gotten a bit of a bad rep with web developers, and it’s easy to understand why. We’ve all come across that one WordPress website, with 40 plugins, most of which are out of date, four which are abandoned and 6 which have security vulnerabilities. The website was probably built 10 years ago, and has a visual builder thrown in on top of a theme with outdated support available.

What if I told you that there was another way? That you could have WordPress running on your computer with the click of a button (ok, maybe 2 buttons), with all the local dev features we know and love, like hot module replacement, scoped styles and easy to build custom components? If you want (and have the skills in house), you can even build live updating React components that integrate directly with WordPress for things like advanced search and filtering without reloading the page. And once this is all done, you can deploy your changes via continuous deployment.

Join me as I take you on a journey to rediscover what WordPress is capable of, and together we’ll build a functioning, maintainable, easy to use WordPress website, with only a handful of plugins.

Quokkas are the happiest animal in Australia that surprisingly isn’t trying to kill you. But can you really be sure that what you’re looking at is a Quokka and not something more dangerous?

Let’s look at how we can build a quokka identifying chatbot, combining Twilio’s WhatsApp, MMS and SendGrid APIs with machine learning based image detection powered by Microsoft’s Custom Vision API.

Join me as we learn how to train and then link up an ML model across multiple communication channels to create an engaging, accessible chatbot. And of course lots of photos of quokkas.

We’ve all heard a lot in the last year about a new advancement in the world of CSS, called CSS Grid. Starting at whispers, we’re now starting to hear it as a deafening roar as more developers write about it, talk about it and start using it. In the world of front end, I see it everywhere I turn, but what does it mean for non front end developers and why should you care about it?

The reason CSS Grid is gaining so much attention is because it’s a game changer for layouts. No longer do you have to fight for hours to align things properly on the page (eventually turning to Bootstrap), with a few simple lines of code we can now create dynamic and responsive layouts. While a lot of people are calling this the new “table layout”, CSS Grid gives us so much more (and is easier to use).

While there is so much to worry about when developing an app, CSS Grid means that you can worry less about building the layout on the front end, and more about making sure the back end works well. Let me show you how the magic works.

Ever feel like everything’s a struggle? Like you’re constantly overwhelmed by life? While we can endure it and pull through, this is hardly sustainable. Sometimes, it’s just too ducking hard.

We’ve all been there. Thankfully, there are simple things you can do to not only reduce the stress factors, but sometimes eliminate them altogether.

Join me to learn about setting (and sticking) to your boundaries, identifying which worries help and which ones harm, and most importantly, how to manage your ducks. These are personally vetted, tried and tested steps for being a more sustainable you.

Testing is important right? Your project can’t be run unless all your unit and integration tests are written (and pass), but are you also testing the front end?

There are so many different tests we need to be running on the front end - accessibility testing, performance testing, user testing, HTML validation, visual regression testing - it’s hard to work out what you need to test for and how to set it up.

Join me to learn about the different types of front end tests and find out where you need to use them, while I show you how to set them up in a live example application.

Accessibility is a word often thrown around, but what does it actually mean? As framework starters (like Create React App) start including accessibility testing plugins in their out of the box tests and fill our consoles with warnings, we’re starting to see more people include aria attributes, and make sure their images have alt tags, but is this really helping?

While it’s tempting to do whatever it takes to stop the warnings, there are times when the recommendations aren’t clear and lead you to including un-needed code or even making the application unusable!

Let me show you how to decipher these warnings, and how to make sure you’re not actually making your app more complex and less accessible than it needs to be. Find out what tools you can use to include accessibility in your existing testing and what you really need to be doing with your code to make sure you’re building a good experience for all users.

You’ve built yourself a web app and now it’s time to deploy it somewhere. But it’s only CSS, HTML and maybe some JS, so what’s the best place in Azure to host that?

Failure has a lot of negative connotations and is something we actively try to avoid. But failure is an important part of life, we need to change our relationship with failure and embrace it, rather than avoid it.

We are faced with failure every day, it gives us a chance to learn from our mistakes, to reassess the situation and try again. Just as we claim ‘bugs’ are ‘undocumented features’, we can re-brand ‘failures’ as ‘learning opportunities’ and take the chance to make ourselves better.

In my life, I’ve had my fair share of failure. Some are just a slight blip, while others can be a little soul destroying. But the common factor from all these failures is that I’ve learnt from each and every one of them.

One of the reasons I’ve been able to bounce back from these failures is that I’m also prepared to fail. This doesn’t mean sitting around and expecting that you’re going to fail but being prepared is always a good step to take; having a ‘just in case’.

I’ve already learnt from my failures, now you can learn from them as well. Let’s stop being afraid of failure and learn to take a chance, give it a go so that you can learn something new. The only way you truly fail, is if you fail to try.

When we begin learning about building the web, HTML is the best place to start. HTML is used in every website there is and gives us elements to use with other languages like CSS and JavaScript. We've all learnt HTML and know how to use it right?

But the truth is, we often don't finish learning HTML, and it's not something we go back to down the track. Once you've covered divs and spans, is there really any more to learn? How often do you hear someone say that they're going to brush up on their HTML before they can start on something else?

Semantically correct elements not only help you to make sure your code is structured properly, it can help reduce the need for extra styles that the browser might include automatically. Writing semantically correct code also makes your site more accessible to people using assistive technologies as the tool knows what to expect from certain elements.

So let's go back to the beginning, back to where we started, and let me reveal how to achieve more from your HTML.