Last week I attended an Alexa Dev day in Edinburgh. I’d been to an introductory session last year, but this event promised to go into more depth and also cover some notable recent additions and enhancements. The Alexa ecosystem is constantly evolving, and the tools and techniques used to build voice enabled skills are still in their infancy, so a hands-on session was just what I was looking for.
This blog runs as a static site, generated using Hexo and hosted on Amazon’s S3 storage service. One annoying issue I’d come across when publishing my site was that the content-type metadata of the uploaded files didn’t match what I was expecting. When I ran hexo server locally to check what my blog posts would look like, all was well, but as soon as I’d uploaded the content to my bucket in S3, the website wouldn’t work correctly. CSS wouldn’t be applied as expected, and links to blog posts would be treated by the browser as downloadable content instead of HTML pages.
In order to resolve this issue, I decided to create a simple app using the AWS C# S3 SDK.
Today I’ve been at an Amazon Alexa Skills Day in Glasgow. Having owned an Echo for a few months now, I’ve dabbled with creating Alexa apps, or skills to use the Amazon terminology, so when I saw this event advertised I was keen to attend. Presented by David Low, Principal Evangelist for Alexa in the EU, the event started with an overview of the Alexa ecosystem, and how successful Amazon has been in introducing its voice controlled speaker Echo over the past few years. Apparently the Echo has become such an important part of everyday life for some people that Amazon has recorded upwards of 250,000 marriage proposals to Alexa…
Null dereference exceptions are a trap awaiting even the most experienced developer. Careless use of object references can result in unhandled exceptions, security vulnerabilities and ultimately unhappy users. From the OWASP description:
Null pointer errors are usually the result of one or more programmer assumptions being violated. Most null pointer issues result in general software reliability problems, but if an attacker can intentionally trigger a null pointer dereference, the attacker might be able to use the resulting exception to bypass security logic or to cause the application to reveal debugging information that will be valuable in planning subsequent attacks.
A null-pointer dereference takes place when a pointer with a value of NULL is used as though it pointed to a valid memory area.
In this post, I’ll describe how to mitigate against the risk of null deference exceptions in Delphi code, using a concept borrowed from the world of functional programming.
I’m happy to announce the first release of the mountebank-delphi project I’ve been working on recently. It’s a Delphi client library for use with the mountebank tool, and simplifies the use of mountebank in a Delphi environment. For anyone unfamiliar with mountebank, it’s a wonderfully simple tool for mocking out service dependencies.
The main use case for this library is when setting up mock services for integration tests in Delphi. Via a simple fluent interface, you can define the expected responses from your mocked servicea, rather than having to remember the exact steps required to configure mountebank. Although this is an initial release of the library, it supports the main features you’ll want to use in your integration tests, namely responses and stub predicates.
Delphi Starter Edition is Embarcadero’s free version of the Delphi programming language and IDE, in the same vein as Microsoft’s Community Edition of Visual Studio. I use the Professional edition of Delphi at work, so I was interested to see how the free version stacked up. I’ve been working on a side project recently in Delphi, so thought I’d give the Starter Edition a try.
In the previous post, I introduced Mountebank as a way of mocking calls to services. A simple example of how to mock out a call to a real service was demonstrated, returning a dummy set of data for every call to the service endpoint. However, this example would always return the same set of data, which limits its usefulness somewhat!
In this post, I’ll show how to add some conditional behaviour to imposters, allowing you to configure the responses based on the requests you make.
Imagine you’re building a new client application, or you have a dependency on one or more services that are outwith your control. Rather than being tied to the actual implementations, or maybe even needing to wait until another team has finished building them, you really want to just stub out the dependencies in the same way as you would with a mocking framework when unit testing. When multiple teams are all working on different services in parallel, being able to validate that the piece of the puzzle you’re working on can talk to its dependencies is vital.
In the past, I’ve created simple stub services that simply return the data I want, replicating the interface that I’m expecting. These sort of projects tend to be throwaway, however, and it’s easy to fall into the trap of just hardcoding the results you expect to receive. Ideally what you want is the simplest way of configuring behaviours so you can completely control the environment in which you’re testing your code. This is where the mountebank mocking tool comes in…