With more and more of our information being stored in social media, businesses and other organisations, data protection and privacy is becoming a growing concern. We want more ownership of our information- where it is, who wants to access it and how to control its dissemination. This is especially true of sensitive information submitted to institutions such as Local Authorities.
If you want to write a dynamic web application in 2019 then the chances are that you will reach out for a JavaScript solution, and that solution will probably be React. We compare React to Blazor, a new .NET framework allowing you to write in C# for the front and back ends.
Sometimes, when people are thinking about a new product or ways to improve or develop an existing product, their ideas aren’t fully formed. The Discovery process provides a framework for identifying the potential users of the product and investigating in detail exactly what their needs are. Each process is unique, adapting in response to where the customer is in their own thinking. Discovery outputs vary depending on needs, from specification, budget estimates and possible funding sources to prototypes to help clients see how their ideas might work.
Using Blazor, code written for the front-end has access to all the language features of C#. In particular, it may be useful to have a type hierarchy and make use of polymorphism. However, JSON objects have no explicit type, so how can we correctly deserialise a subtype?
One of the benefits of Blazor is that you can share C# objects between the server-side processing and the client-side processing. In this year’s Dev Camp we wanted to put this to the test with validation of dynamic forms.
In our Dev Camp this year we chose to experiment with Event Sourcing, using EventFlow for the solution. One task was to configure it to use an Azure Cosmos database instead of a SQL Server one. There were some hurdles to overcome. This post takes you through the attempts we made and the solution we found.
Meeting the challenges of software commercialisation is not just about the code. How do you start that journey? What needs to happen along the way to ensure the best launch? And once your product has made it into the market, what needs to be in place for its continued success?
Technology and social media mean we may now be more connected than ever. At the same time, many of us feel a greater sense of loneliness than ever before. To help combat loneliness, Ami was launched in 2016 to connect lonely people with volunteers who find fulfilment in helping others. After success in Oxfordshire, Ami is now reaching out into other counties with a vision of becoming a national organisation to help combat loneliness across the UK.
Our final day saw huge progress in the application's client and server sides coming together. This was really the focus of the day with everyone working together to solve the final challenges and get the client communicating with the server.
Development progresses on all fronts in day 4, with the client and server sides moving closer together thanks to new work on the shared classes and API.
By the end of day 3 we'd managed to get the Blazor application constructing a dynamic form based on an external set of defined fields and having those fields be validated dynamically on the client-side again based on externally defined validation rules. Here's what that looks like...
In day 2 the team continued making progress in each of their areas. The EventFlow project begins to come together, shared client and server validation plans are made, and getting Event Flow working with Cosmos DB causes frustration.
In day 1 we set up our client and server-side teams; identified useful resources and frameworks for the week; and began setting up the solution and its components.
At OCC, dev camps are a way for us to experiment with new technologies, create prototype products, and bring back recommendations to the wider company regarding the new tools and techniques we've been able to evaluate.