Ready to discover a way to generate usable Java classes from WSDL files and check how they are structured? That is precisely where this blog post will get you.
Finishing the last line, you’ll be equipped with all the necessary schema files and the ready-to-use service.
Sounds promising? Only if you know what WSDL files are, which will be explained too.
When a software collapses, it’s usually due to it being no longer maintainable because of complexity. Brian Kernighan, the creator of AWK programming language, puts it quite explicitly: "Controlling complexity is the essence of computer programming".
We have successfully adopted the Gerrit workflow for pre-commit code review in Evojam. We believe that this a foundation of high quality of our solutions. After two years we have worked out a complete approach for the pre-commit review with Gerrit, branching model and application provisioning. Now I have realized the there is no definite cookbook for the newcomers. This led me to the idea that it may be worth to share this approach with the community. This is not totally unique but may save a newcomer a bit of time.
We've been using Play Framework with Elasticsearch and elastic4s for a while. Getting it all to work together requires some boilerplate code, though. We decided to create a small library that would make things easier in future projects. We learned some lessons about building Scala libraries along the way.
Pre-commit code review can provide some tremendous benefits: It improves quality of the final code, it helps team members to learn from each other. It also propagates knowledge about projects and best practices. But it also generates additional problems. Here's how we dealt with them.
There are three popular possibilities – jsDoc (with e.g. Google Closure Compiler), Facebook Flow and Microsoft TypeScript. First one uses comment like annotations – does not corrupt pure JS – while next two extend JS so they have to be transpiled. I will compare them briefly in a moment.
We're mostly building web applications these days. Even standalone apps have their UI layer written as a single page app in JS and communicate with their backend using REST. Let's explore the process of designing the REST API for such an app.
The abundance of all the tools and resources makes building web applications seemingly effortless. The framework will handle the routing, the library will process the requests and the template engine will take care of any UI you need. This is all very convenient, but it doesn't deal with the greatest risk of all: having your web service destroyed before you start coding.