Pioneering and pushing technology boundaries – pretty much a given nowadays for the software-driven startup. Here are some insights we’ve observed working with a number of venture capital (VC) companies who have managed to navigate the choppy waters and successfully grow their business including winning further investment along the way.
With our deep hands-on technical expertise and pragmatic focus, OpenCredo has become a natural software acceleration partner for VC funded organisations who are looking to deliver tangible value as effectively as possible. We’ve been brought in to work alongside these innovators at various stages of their journey. As such we’ve gained an appreciation for and acquired, first-hand insight into some of the pressures and challenges faced. From getting and securing that next round of funding, to grappling with the technical decisions and challenges inherent in sensibly evolving offerings to accommodate future growth and scaling.
Back in August, we shared with you a pro-bono project we had embarked upon – the build of an application that would bring the Mental Health Collective’s vision-of-kindness to life: Technology, Kindness and Bananas.
Since then we have been experimenting with technologies, developing a platform, and implementing a solution that will allow MHC to take their initiative onwards.
(Tech stack employed: React, Amplify – DynamoDb, Lambdas, API Gateway)
As a technology leader, you’ll be aware that competitive pressures and shifting business requirements are driving changes in the technical architectures of many organisations. This means you need a new strategic approach based on the ability to continually evolve elements of your systems and architectures.
My last year or so here at OpenCredo has involved a very well-supported first foray into tech consultancy. Different engagements pose both unique, as well as familiar challenges for me as a consultant, all of which played a part in shaping and moulding the way I understand and approach problems. This blog is a brief collation of wisdom that’s helped me the most during this adventure; gained by learning the hard way, as well as that acquired from mentoring and colleagues who have gone before. The shared wisdom has made me a much more effective consultant, and kept me sane in the process, for which I’m very thankful.
As a consultant I often find myself in situations that require tricky problem solving, typically of a technical nature. Yet although it is common to approach a consultancy engagement in terms of its technical context, not all problems have a purely technical solution.
As Kotlin’s 1.1 release draws closer, I’ve been looking at some of the new language features it supports. Type aliases may seem like a relatively minor feature next to coroutines, but as I will show in this blog post, they can open up a new programming idiom, particularly when combined with extension functions.
The notorious FizzBuzz interview test was originally proposed as a way of weeding out candidates for programming jobs who – to put it bluntly – couldn’t program. The task is as follows:
Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.
It turns out that this problem has just enough subtlety about it to cause headaches to anyone who knows the basics but hasn’t learned how to think in nested structures.
As many of you know, OpenCredo are part of the global Trifork family, and as such have access to the combined knowledge and experience of many technology and business leaders throughout the group. Getting public access to all of this expertise and technical leadership can be tricky – until now. GOTO Accelerate is a one-day business focused conference that has emerged from the very successful GOTO technology events.
Akka has been designed with a Java API from the very first version. Though widely adopted, as a Java developer I think Akka has been mainly a Scala thing… until recently. Things are changing and Akka is moving to a proper Java 8 support.
It’s as simple as that – and as a consultant, it’s a problem I see all the time. Testing is always focused on functional testing. Non-functional testing, by comparison, is treated like a second class citizen. This means that functional requirements get refined, and non-functional requirements are ignored until the very end.
In my previous blog post I explained to you the Seven Deadly Sins of Project Managers. With that post in mind, I would like to share with you my views on what a project manager needs to overcome these sins and become a valuable member of the team, and ultimately helping to achieve success on the project.
In this post, I’m going to take something extremely simple, unfold it into something disconcertingly complex, and then fold it back into something relatively simple again. The exercise isn’t entirely empty: in the process, we’ll derive a more powerful (because more generic) version of the extremely simple thing we started with. I’m describing the overall shape of the journey now, because programmers who don’t love complexity for its own sake often find the initial “unfolding” stage objectionable, and then have trouble regarding the eventual increase in fanciness as worth the struggle.
People make mistakes. People can improve. People need to be told of their mistakes. Surprisingly project managers are people too… I know… in some cases it is really hard to believe it; and then they can improve too! Shocking! I have more than 15 years working in IT, occupying different roles from software development to project management in three different countries. I’ve seen really bad project managers and some really good project managers; Yes, they DO exist!
In this post I’m going to demonstrate the implementation of Complex, a Kotlin class handling complex numbers, which uses operator overloading to provide the usual arithmetic operations for those numbers. In the process, I’ll also demonstrate a Kotlin pattern which I call “complicit conversion”, and show how to implement complicit conversion between two types: Double and Complex.
In this post, I’ll demonstrate an alternative API which uses some of the advanced language features of the new Kotlin language from Jetbrains. As Kotlin is a JVM-based language, it interoperates seamlessly with Concursus’s Java 8 classes; however, it also offers powerful ways to extend their functionality.
In the previous two posts (part 1, and part 2), we looked at how Concursus uses method mapping to generate events from method calls on proxies, and to dispatch events to matching methods on event handlers and state class instances. This approach provides a concise, convenient client API to the Concursus event system; however the core of the system defines events and event-handling mechanisms without reference to any of the reflection-based machinery used to implement this API. It is perfectly possible (if comparatively cumbersome) to use a Concursus event store to read and write events without using reflection. In this post I’ll show how this is done, continuing with the “lightbulb” example introduced previously.
In a conventional RDBMS-with-ORM system, we are used to thinking of domain objects as mapped to rows in database tables, and of the database as a repository where the current state of every object exists simultaneously, so that what we get when we query for an object is the state that object was in at the time the query was issued. To perform an update, we can start a transaction, retrieve the current state of the object, modify it, save it back again and commit. Transactions move the global state of the system from one consistent state to another, so that the database transaction log represents a single, linear history of updates. We are therefore able to have a very stable, intuitive sense of what it means to talk about the “current state” of any domain object.
Concursus is an open source Java 8 framework for building distributed systems using CQRS and event sourcing patterns. One of its major differences from other such frameworks (such as Jdon, Axon and ES4J) is that it eschews a programming model where each event type is represented by a separate Java class, instead mapping event types to methods on interfaces.
This post is part of a series which introduce key concepts in successful test automation. Each post contains sample code using the test-automation-quickstart project, a sample Java test automation framework available from Github.
Raise your test coverage with automated email testing
Acceptance test suites generally are used for UI and API testing, and we have covered both these approaches in our Test Automation Quickstart project. However, an application may, for example, send registration or expiration warning emails. Often, tests related to this are left to manual testing, instead of putting them into an automated test suite.
However, there’s no need to check emails manually: it suffers from all the same problems as other manual testing. It’s slow, expensive, and inconsistent. There are many libraries available to interact with email through code – this post will focus on how to use them within an automated test suite.
In order to be able to regularly release an application, your automated tests must be set up to give you fast and reliable feedback loop. If bugs are only found during a long and expensive multi-service or end-to-end test run, it can be a hinderance to fast delivery. Unfortunately I have often seen this problem in development environments: a huge suite of clunky, flaky and slow end-to-end tests which test the full functionality of the application as opposed to being more lightweight and reflecting basic user journeys. This produces the “ice cream cone” anti-pattern of test coverage, where unit tests aren’t providing the kind of coverage and feedback they need to.
Test automation provides fast feedback on regressions. In order to achieve this tests need to execute quickly, something which becomes more of a problem as test suites grow. This is especially true of tests which exercise a user interface where the interaction with the system is slower.
A good way to address this is to have your tests execute in parallel rather than consecutively. Given sufficient resources this allows your execution time to remain low almost indefinitely as more scenarios are added to the suite.
In this post, I’ll be sharing some React/Redux boilerplate code that Vince Martinez and I have been developing recently. It’s primarily aimed at developers who are familiar with the React ecosystem, so if you are new to React and/or Redux, you might like to have a look at Getting Started with React and Getting Started with Redux.
JetBrains (the people behind IntelliJ IDEA) have recently announced the first RC for version 1.0 of Kotlin, a new programming language for the JVM. I say ‘new’, but Kotlin has been in the making for a few years now, and has been used by JetBrains to develop several of their products, including Intellij IDEA. The company open-sourced Kotlin in 2011, and have worked with the community since then to make the language what it is today.
Last time in this series I summarised all the Akka Persistence related improvements in Akka 2.4. Since then Akka 2.4.1 has been released with some additional bug fixes and improvements so perhaps now is a perfect time to pick up this mini-series and introduce some other new features included in Akka 2.4.x.
Good consulting is, by its nature, an act of collaboration. We recently helped a company with a variety of challenges – some architecture, some coding, some systems, some people, some process (normal consultancy challenges) – unique to this client. During the project, we formalised some things we had thought before, but which had never crystallised – all the work we did was transformative. Whether it’s a code review, process review, DevOps implementation, or outright transformation, the primary goal is the same – improving flow. Flow (sometimes known as throughput) is the movement of raw materials through a system to become finished goods. It’s analogy in the service industry is the movement of customer requirements through to usable solution. And we help improve it.
We announced yesterday that CloudCredo has been acquired by Pivotal. In the longer term this will probably solve one of my challenges that is the need to constantly explain the difference between OpenCredo and CloudCredo, since CloudCredo will eventually be absorbed into Pivotal. Yesterday’s announcement has created significant interest, and so I thought I would try to clear things up with a quick post.
This post introduce some of the basic features of Hazelcast, some of its limitations, how to embed it in a Spring Boot application and write integration testings. This post is intended to be the first of a series about Hazelcast and its integration with Spring (Boot). Let’s start from the basics.
Over a year ago, my colleague Tristan posted on the OpenCredo blog about a test automation quick start framework. It’s a prepackaged framework you can clone and get going with testing instantly, rather than wasting your time rebuilding your framework every single project. We have used this framework successfully used on many of our internal projects, and it relies upon a Java, Cucumber-JVM and Selenium stack.
Writing reusable roles for Ansible is not an easy task but one that’s worth doing. This post should walk you through the basics of writing reusable roles with dependencies backed by public and private git repositories.
Having completed my marathon 3-talks-in-one-day at JavaOne on Wednesday, I’m now in a position to share all of the slides and supporting material. First up is the content associated with my “Thinking Fast and Slow with Software Development” talk. I’ve already blogged about an earlier version of this presentation on the OpenCredo blog, and so won’t go into more detail here. However, I will include the video recording (thanks to the JavaOne team for this!), the latest version of the slides, and a much requested reading list!
Let’s have a quick look at the most interesting changes and new features that are now available to Akka users. As there are many new features to highlight in the new Akka release I will focus on those related to Akka Persistence first and cover other areas in a separate post.
OpenCredo is helping Skillsmatter with the organisation of the inaugural ContainerSched conference, and we were last night in attendance at CodeNode, working our way to finalising the program alongside the Skillsmatter team. I’m pleased to say that the provisional lineup looks great (speaker acceptance emails are being sent out over the next few days), and so I wanted to share the details of some of the great content we have confirmed already.
How correlated estimates make prediction in IT hard.
It’s well known that predicting how long a project/task will take in IT is hard. In this post I’ll address one aspect of this (correlation) and ask what insights a data science perspective can give us about how correlations can make prediction difficult. I’ll explain the problems that correlation poses, give some practical advice for teams & project managers and investigate possible innovations to tooling that might improve matters.
You’ve implemented a change in how things work, and people aren’t happy. You spent time investigating the problem, and putting serious thought into what the issue was, and you’ve put a fix in place that you were sure people would be happy with. They aren’t. Why not?
In this post, the last in the New Tricks With Dynamic Proxies series (see part 1 and part 2), I’m going to look at using dynamic proxies to create bean-like value objects to represent records. The basic idea here is to have some untyped storage for a collection of property values, such as an array of Objects, and a typed wrapper around that storage which provides a convenient and type-safe access mechanism. A dynamic proxy is used to convert calls on getter and setter methods in the wrapper interface into calls which read and write values in the store.
As a company, we at OpenCredo are heavily involved in automation and devOps based work, with a keen focus on making this a seamless experience, especially in cloud based environments. We are currently working within HMRC, a UK government department to help make this a reality as part of a broader cloud broker ecosystem project. In this blog post, I look to provide some initial insight into some of the tools and techniques employed to achieve this for one particular use case namely:
With pretty much zero human intervention, bar initiating a process and providing some inputs, a development team from any location, should be able to run “something”, which, in the end, results in an isolated, secure set of fully configured VM’s being provisioned within a cloud provider (or providers) of choice.
In the previous post I introduced Java dynamic proxies, and sketched out a way they could be used in testing to simplify the generation of custom Hamcrest matchers. In this post, I’m going to dive into some techniques for implementing proxies in Java 8. We’ll start with a simple case, and build up towards something more complex and full-featured.
Dynamic proxies have been a feature of Java since version 1.3. They were widely used in J2EE for remoting. Given an abstract interface, and a concrete implementation of that interface, a call to some method on the interface can be made “remote” (i.e. cross-JVM) by creating two additional classes. The first, a “marshalling” implementation of the interface, captures the details of the call in the source JVM and serializes them over the network. The second, an “unmarshalling” endpoint, receives the serialized call details and dispatches the call to an instance of the concrete class on the target JVM.
Apache Mesos is often explained as being a kernel for the data-centre; meaning that cluster resources (CPU, RAM, …) are tracked and offered to “user space” programs (i.e. frameworks) to do computations on the cluster.
When I first started programming in Scala a few years ago, Traits was the language feature I was most excited about. Indeed, Traits give you the ability to compose and share behaviour in a clean and reusable way. In Java, we tend deal with the same concerns by grouping crosscutting behaviour in abstract base classes that are subsequently extended every time we need to access shared behaviour in part or in total.
When starting a project, teams often spend their time re-inventing the ‘automated testing wheel’. While every project has it’s own challenges and every team it’s own needs, many things exist as common requirements of a flexible test automation framework.
This post introduces an effective Java test framework that can be used to quickly get started with test automation on a Java project.
A while ago I published this blog post about writing tests for mobile applications using Appium and cucumber-jvm.
In this post, I will look at an alternative approach to testing an Android native application using Cucumber-Android.
Throughout the post I will draw comparisons between Appium and Cucumber-Android, the goal being to determine the best approach for testing an android application using Cucumber. I will focus on the ease of configuration and use, speed of test runs and quality of reporting.
In many organisations, development and test teams have a ready answer for this, and that answer is usually wrong. Commonly, teams use test counts and code coverage statistics, which alone are not enough to validate a test approach and run the risk of giving a false sense of security to stakeholders. In practice, we are not able to fully prove the efficacy of our test strategy until after a release. Once software is in use, new defects highlight where our tests are failing to validate the software and where we need to invest effort to improve coverage. This is where many teams fail to learn and improve.
This post will give an overview of mobile testing using Appium. We will integrate tests for a native Android application into an existing Cucumber-JVM based set of acceptance tests and demonstrate multi platform testing from a single set of BDD scenarios. The sample code for this can be found here.
Configuration management was born in the pre-cloud era. Remember the days when acquiring a super powerful multi core server felt like winning the jackpot? Infrastructure was a slightly different place back then. Yet for all the recent developments in DevOps, its legacy is still with us.
This blog post will address the issue of slow test runs when using Cucumber JVM with web automation tools such as WebDriver to perform acceptance testing on a web application.
If your team is using continuous integration this becomes especially noticeable, forcing teams to either wait for acceptance tests to complete before deploying or having to ignore the bulk of the tests.
The sample code and description in this post will show you how to convert your suite to running tests in parallel, something which has historically been problematic with unanswered questions and outstanding Cucumber-JVM bugs on the subject. Tying the described approach in with Selenium Grid2 will allow you distribute your testing across several machines if your suite is especially large or slow.
Spring Data Hadoop (SDH) is a Spring offshoot project that allows the invocation and configuration of Hadoop tasks within a Spring application context. It offers support for Hadoop jobs, HBase, Pig, Hive, Cascading and additionally JSR-223 scripting for job preparation and tidy-up.
It is most suited for use in organisations with existing Spring applications or investment in Spring expertise. Some SDH features replicate functionality of tools in the Hadoop ecosystem that DevOps engineers who maintain a Hadoop cluster will be more familiar with.
How to create robust tests for Spring based applications
This blog post continues on from Part 1 which discussed types of tests and how to create robust tests. Part 2 will examine techniques to help whip a test suite in to shape and resolve common issues that slow everything down. The approaches in this post will focus on spring based applications, but the concepts can be applied to other frameworks too.
This API will in future be used by a mobile client and by third parties, making it important to verify that it is functionally correct as well as clearly documented.
An additional requirement in our case is for the tests to form a specification for the API to allow front and back end developers agree on the format in advance. This is something that BDD excels at, making it natural to continue to use Cucumber. This post will focus on the difficulties of attaining the appropriate level of abstraction with Cucumber while retaining the technical detail required for specification.
The practice of continuous integration in which build servers are used to build and perform testing of code is now widespread and mainstream.
While not all teams have adopted continuous integration effectively, its increasing adoption has led many to start to look for additional opportunities to improve the cost, quality and speed of delivery with which software targeted to meet business needs can be released into production environments.
Traditionally Continuous Integration addresses the question of “does the software build and pass our unit and integration test suites?”. This is often insufficient.
The first thing most people think of when they start a project with the good intentions of test driven development is: write a test first. That’s great, and something I would fully encourage. However, diving in to writing tests without forethought, especially on large projects with a lot of developers can lead to new problems that TDD is not going to solve. With some upfront thinking (but not big upfront design!) a large team can avoid problems later down the line by considering some important and desirable traits of a large and rapidly changing test suite.
Event processing Language (EPL) enables us to write complex queries to get the most out of our event stream in real time, using SQL-like syntax.
EPL allows us to use full power of aggregation of the high volume event stream to get required results with the minimal latency. In this blog we are going to explore some aspects of numerical aggregation of data with high precision BigDecimal values. We will also demonstrate how you can add you own aggregation function to Esper engine and use them in EPL statements.
Recently we were approached by a client to do some performance testing of the web application they had written. The budget allowed two days for this task. Ok. No problem. Yes, we can. Naturally I had one or another question though…
In this post we will look at the creation of a suite of maintainable acceptance tests, identifying some key issues as encountered on real projects and suggesting solutions.This post assumes some knowledge of behaviour driven development (BDD). If you are new to this concept, I’d recommend Dan North’s blog as a starting point, particularly his post introducing the concept of BDD.The idea of human readable acceptance testing championed by BDD enthusiasts is one that continues to grow in popularity, and it’s easy to see why.
Strictly Necessary Cookies
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.