As a developer, you’re sometimes required to quickly pick up technologies that you’re not necessarily familiar with. Sometimes, that means getting to try out cool new tech that everyone’s talking about. Other times, it means learning to use something neither cool nor new.

When looking into how to use a SOAP API for a recent project that involved working with some legacy systems, I noticed there are a lot of blog posts about SOAP vs. REST and why you should never, ever use SOAP. Not very useful if you’re working on a project where you have no choice but to interact with a SOAP API.

So here’s a little primer on working with a SOAP API. Have fun!

What is SOAP?

SOAP stands for Simple Object Access Protocol. It’s a type of API that is usually found in older enterprise systems and allows you to invoke a specific set of methods on the server you’re communicating with. SOAP uses XML as a messaging format, and messages are usually transmitted via a normal web request.

Most new APIs are built as REST APIs, not SOAP. Reasons why are outside the scope of this post but include verbosity, XML serialisation overhead, and the fact that most SOAP APIs are badly implemented.

Getting going with SOAP

I’m going to show you how to get started using a SOAP API, using this number-to-words converter service as an example.

Have your WSDL ready.

WSDL (pronounced wizzdle) is short for Web Service Definition Language. It’s an XML file that describes all the methods that you can call with the SOAP API. You’ll use it to determine what you can do with the API, what kind of data you can pass to it, and what you can expect to get back from it.

The WSDL is automatically generated. To see the WSDL for the SOAP service you want to use, add ?wsdl to the end of the service URL.

For example, to see what we can do with the number conversion service, we can take a look at its WSDL located here: https://www.dataaccess.com/webservicesserver/NumberConversion.wso?wsdl

Reading the WSDL

In the WSDL, look for a subsection called <types> or <xs:types>, and within that an <xs:schema>. Here you’ll find the methods you can call and their responses.

Take a look at this extract from the number-to-words converter WSDL:

<xs:schema>
  <xs:element name="NumberToWords">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="ubiNum" type="xs:unsignedLong"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="NumberToWordsResponse">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="NumberToWordsResult" type="xs:string"/
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

We can see that there’s a method called NumberToWords that takes a parameter called ubiNum, which the WSDL says should be of type xs:unsignedLong. Looking up XML data types (on W3Schools, for example), we can see that that means it should be an unsigned 64-bit integer.

There’s also a definition of the response we can expect to receive: NumberToWordsResponse, which returns a string parameter called NumberToWordsResult. Sounds good — it’s what we might expect from a service that takes a number and makes it into a word.

Now we know what we’re working with, it’s time to try it out!

Making the SOAP request

There’s a very specific structure to making a SOAP request. The request is written in XML and sent via HTTP (or sometimes more rarely a message queue or, shockingly, email).

Continuing with our example number conversion service, our SOAP request might look something like this:

POST /webservicesserver/NumberConversion.wso HTTP/1.1
Host: www.dataaccess.com
Content-Type: text/xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <NumberToWords xmlns="http://www.dataaccess.com/webservicesserver/">
      <ubiNum>12</ubiNum>
    </NumberToWords>
  </soap:Body>
</soap:Envelope>

We’re making a normal HTTP POST request, where the content of the body is some XML that tells the service what we want to do.

Looking at the body of the request, there’s a soap:Envelope that wraps a soap:Body, within which you pass the method you want to call (here, NumbertoWords), and within that, any parameters that the method requires.

You can try this request out with Postman, using their handy guide to making SOAP requests. Just a heads up, though, because it’s not clear in Postman’s guide — make sure to set the Content-Type to ‘text/xml’ in the header as well as in the body.

Here’s the response from the request above:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <m:NumberToWordsResponse xmlns:m="http://www.dataaccess.com/webservicesserver/">
      <m:NumberToWordsResult>twelve</m:NumberToWordsResult>
    </m:NumberToWordsResponse>
  </soap:Body>
</soap:Envelope>

The format is very similar to the request format, except this time, we can see aNumberToWordsResponse which contains the NumberToWordsResult. In this case, the string ‘twelve’.

Phew, that was a little long-winded. Don’t worry though, you don’t have to write all your requests out yourself by hand.

Finding a SOAP library

Luckily for you, there are libraries out there that can help you, depending on what language you’re coding. We’ve had good experiences with:

• node-soap for Node
• Savon for Ruby
• Zeep for Python

The concept with SOAP libraries is usually the same:

1. Create a SOAP client based on the WSDL URL
2. Call dynamically created methods on the client

Check the individual libraries’ documentation for more information on how to use them. You may need an XML parser, too, to create the parameters for your calls and parse the responses, depending on how fancy your library is.

Wrapping up

Many SOAP APIs are largely undocumented beyond the WSDL, so you’re going to have to get good at reading XML. Hopefully, this guide has helped you get a better understanding of the WSDL and how to work with SOAP APIs in a relatively painless way.

Good luck!

.

.

.

Pixie Labs is a leading London-based digital product studio with deep software development expertise in Ruby on Rails, React and React Native. We design and build high-impact apps, platforms and digital tools. Let us help you make your digital product a success.

A short SOAP primer: how to use a SOAP API when you really, really have to was originally published in Pixie Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Back in January, the whole Pixie Labs team attended a refresher Agile training workshop. It was a great way to get everyone on the team thinking critically about some of the processes we use every day, and to discuss how we could make those processes work better for us.

Besides the interesting discussions that came out of the workshop and having lots of fun building animals out of Lego, we also learnt some new things, including how to predict a team’s velocity on an Agile project using the Velocity Game.

We play Planning Poker for estimating story sizes, but we didn’t really have a way of estimating team velocity for new projects where there’s no historical data to use in predictions. That’s where the Velocity Game comes in.

How the Velocity Game works

To play the game, you need an index card for each story in the project, with the story written out on one side and the story points on the other.

The project manager selects a story to show to the development team, who must agree on whether they will be able to finish it within one iteration. The points associated to stories should always be kept hidden from the team, so that they don’t influence their decisions.

When the team agrees that a story can be completed in an iteration, that story should be put aside. The project manager then selects another card from the deck to show the team. This time they must decide on whether they could complete the new story as well as the one they’ve already accepted.

Play continues like this until the team accepts no more stories into the iteration. At this point the project manager secretly adds up all of the accepted stories’ points and writes down the number somewhere, to be kept hidden until the end of the game.

Repeat the whole process a few times, with the project manager showing the team different combinations of stories each time. Eventually, the number of points in each iteration should begin to converge, giving an indication of the team’s projected velocity.

Introducing Velocitaire

Velocitaire is a tool we built for playing the Velocity Game, and it doesn’t require writing out lots of stories on index cards. Pretty sweet!

To play Velocitaire, you need the following:

• An XLSX file with the name of each story and its associated size, represented as a number
• The team that will build the thing

That’s it!

Each round in Velocitaire corresponds to an iteration. Velocitaire will show stories at random, and the team should decide amongst themselves whether they can fit that work into the iteration. Once they think they have enough stories to fill an iteration, they can end the round. After 5 rounds, the game is ended, and the velocity of each iteration as well as the average velocity, are calculated.

There are a few things to consider when playing Velocitaire:

• Because stories are shown randomly, it’s possible that some stories might never get shown to the players.
• Velocitaire ends the round after 3 rejected stories, regardless of their size.
• At the moment, there are only 5 rounds in the game, but this could be extended.

If you’ve used Velocitaire or played the Velocity Game for one of your projects, we’d love to hear about it. Did it work for you and your team? Is there anything you would change about it?

I couldn’t find the original creator of the Velocity Game. If you are the creator or know where the game is from, please get in touch for attribution.

.

.

.

Pixie Labs is a leading London-based digital product studio with deep software development expertise in Ruby on Rails, React and React Native. We design and build high-impact apps, platforms and digital tools. Let us help you make your digital product a success.

Velocitaire: estimate all the things was originally published in Pixie Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Motivation

We care a lot about learning and growth. That’s why we have Friday Kicks, one day a month, where everyone can work on anything they choose to, inspired by Google’s 20% time and Thoughtbot’s 4-day client week. It’s why we work on projects where we learn something new or build something that’s not been built before, like our Twitter-powered typewriter. During quiet periods of work, we put aside time to hone our skills, revise our existing approaches and try out tools we haven’t used before. Sometimes we build things to bridge gaps where we’ve found them and open-source our solutions, like we did with Cavy, our React Native testing framework.

As well as learning, we like to teach and share what we’ve learnt, whether that’s running sessions with Code First: Girls, coaching at GirlsCode MK, or fielding questions from fellow beginner developers through our network. We also write about the things we’ve found interesting and stuff we’ve built. We love the tech community, and being part of that community also means giving back.

How it started

In August last year, we sat down to talk about how we could share the experience we’ve gained and help people starting out on their coding journey. We’d spoken to Thoughtbot about their mentoring office hours, and it sounded like something we could offer too.

We decided to give it a go and sent out a tweet linking to a brand-new page on our website. Immediately, we got a lot of great responses, and a few people got in touch to ask to come along.

The first office hours went really well, and we decided to make it a part of our Friday Kicks, which happen on the third Friday of every month. Since then, we’ve met with fifteen people to chat about all sorts of tech-related things.

What happens in a mentoring session?

Sessions last one hour, and we encourage participants to prepare questions so that they can get the most out of the session. We also ask them to send the questions to us in advance so that we can match them with whoever is most suitable to help them find answers.

Some of the questions we’ve been asked include:

• What are some good resources for learning to code?
• How can I prepare for a technical interview?
• What kinds of projects can I work on that will help me show off my skills and get a job as a developer?
• How can I fix this broken code?
• I have an idea for x; how should I go about making it a reality?
• I’m not sure I understand what agile means. Can you help me understand it?
• Can you help me with this HTML and CSS problem?

A lot of people were also just generally interested in learning to code in some form or another. Sometimes, they’re already doing all the right things to make their career change into tech, and we’re just there to reassure them that, yes, we spend a lot of time Googling things too.

We’ve met with people who had a bad case of impostor syndrome and insisted they weren’t really developers, all while talking us through the huge React apps they’d built. Once, we showed someone a page of code and how to change the colour of text on a webpage with CSS, and it blew their mind. Another time, a mentee taught us about some cool tech we’d never tried before. Whatever the situation, it’s always rewarding to see people excited about the possibilities that open up to them through learning to code.

Impact

It’s been really fun meeting so many different people through our office hours. We’ve made friends and learned things along the way. A couple of our mentees have gone on to attend further coding workshops and courses, and one nervous mentee built up her confidence enough after chatting to us to quit her job and start a new role as a developer — our proudest moment so far.

We’re so happy with the way this has worked out and looking forward to continuing with it in 2019. Thanks to everyone who attended in 2018, here’s to many more coffees and chats!

Our office hours are held on the third Friday of every month at our London office in Holborn and are completely free to attend. If you’re interested in coming to chat with us about something tech-related, get in touch! We’re looking forward to hearing from you.

.

.

.

Pixie Labs is a leading London-based digital product studio with deep software development expertise in Ruby on Rails, React and React Native. We design and build high-impact apps, platforms and digital tools. Let us help you make your digital product a success.

Launching Pixie Labs’ mentoring office hours was originally published in Pixie Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

You’ve probably heard of Vim, the popular but impossible-to-learn editor. I like a challenge, and after speaking to a few developers who said that Vim was too scary to learn, I decided to give it a go. I’ve written this guide to help other junior developers who might have heard of Vim or have seen it in action and are interested in trying it out. For anyone who thinks Vim is too hard to learn, this guide should help make it a little more approachable.

I’m going to cover:

1. Why you should swap to Vim
2. Dipping your toes in
3. Preparing for the transition to Vim
4. Making the move

1. Why swap to Vim?

What is Vim? Why change if my current text editor works fine?

What is Vim?

Vim is a highly configurable and very powerful text editor which runs in the terminal and is included with virtually every Unix-like operating system (like Linux, or macOS). It has several modes that make moving around files, editing, inserting text and using commands all possible with just a few keystrokes. Amongst other things, it supports creating macros for common tasks, multiple levels of undo/redo memory and running terminal commands from within the editor.

How can it help me?

As a beginner Vim can seem overwhelming, but don’t go too deep into everything at the start. You just need to know whether it will be worth the effort of learning it.

So what are the main benefits of learning Vim?

• You can do everything with your keyboard; no switching between using the keyboard and using the mouse.
• You can use the command line without switching contexts.
• You’ll be able to use it to edit files directly on remote servers when you SSH.
• You’ll learn a lot about the command line.
• You’ll feel great about having learnt something new and scary.

If that all sounds good to you, let’s get started trying out Vim.

2. Dipping your toes in

Vim is confusing! How do I get started? A brief outline of what to install and what tutorials to try out, or: treat your vimphobia with exposure therapy.

Installing

Let’s get practical. A basic version of Vim usually comes installed on Mac and Linux, but you will need to install a newer version to get more features. On a Mac, you can use Homebrew to get the latest version (replacing the built-in version):

$ brew install vim

If you are not on a Mac, or this does not work for you, head over to the official Vim repo on GitHub and follow the instructions there to install the latest version.

Trying it out

Now that you have a recent version of Vim installed, work through some exercises to get a feel for how Vim works in practice.

For a fun interactive introduction to Vim’s controls, I really recommend checking out Open Vim. It’s quick and will give you a taste of what you can do with Vim.

Vim also comes with its own tutorial for beginners called Vimtutor. To try it out, open a terminal window and type vimtutor. It will take about half an hour to complete, and you can leave and come back to it later if you find it’s too much for one sitting. I also found it useful to come back to vimtutor once I’d been using Vim for a little while to top up my knowledge, as it’s hard to remember everything you learn when you’re just starting out.

Take your time and get familiar with some basic commands and movements, as well as switching between modes. Once you feel comfortable, let’s prepare for the transition to Vim!

Resources

• vimtutor — Vim’s official tutor
• http://openvim.com/ — a quick and interactive online Vim tutorial
• https://vim.rtorr.com/ — an accessible Vim cheat sheet, available in lots of different languages
• http://www.viemu.com/vi-vim-cheat-sheet.gif — a graphical Vim cheat sheet
• :help — Vim’s built-in help for when you are stuck

3. Preparing for the transition

I’ve had a go, and it seems pretty sweet. I want to try using Vim for development. Is there any other setup I need to go through?

You’ve played around with Vim a little bit and seen some of the cool things you can do with it. But before you jump right in and start developing in Vim, let’s customise it to make the transition easier.

Create a .vimrc file in your home folder, which will hold your settings. These will be different for everyone, depending on your development style, but when switching over to Vim for the first time after using a normal text editor, there will be a few things that you will have grown used to, which could be useful to configure in Vim.

Those things include, but aren’t limited to:

• support for using the mouse
• syntax highlighting
• auto indentation and setting your preferred tab sizes
• line numbering
• highlighting search results
• a way to view a tree of all the files in a project folder

Search the Internet for ways to implement these and any other features you feel will be useful, and save your settings in your new .vimrc. If you use version control, you will probably also want to add Vim’s swap files to your ignored file types too.

Take inspiration from other people’s .vimrc files, but don’t just copy and paste an entire file. Get the basic setup that you know you will need, then have a go at working with Vim, and you will find out as you go along what features are important for you. Always look up ways to implement them yourself — you will learn more that way.

Resources

• A Good Vimrc — blog post by Doug Black explaining a lot of vimrc options
• https://github.com/thoughtbot/dotfiles/blob/master/vimrc — an example .vimrc from development agency Thoughtbot
• https://github.com/scrooloose/nerdtree — NERDTree, a file system explorer plugin for Vim you might want to use

4. Making the move

Is there anything else I should know before I delete my other text editor?

You might now be tempted to delete your old text editor and dive into using Vim for everything. Hold off for now — it will likely take you some time to get fully productive with Vim, and it will still trip you up. It’s okay to switch back to your old editor to do something quickly there, which you might not yet know how to do in Vim.

Make a note of the things you struggle with, and when you have some spare time, look up solutions and practice using them. Return to Vimtutor to remind yourself of some of the possible movements which you might have forgotten and look over the user manual (:help user-manual).

You can also get all sorts of plugins for different languages, frameworks and integrations. For example, if you use Ruby on Rails,Tim Pope’s rails.vim plugin might be worth checking out.

Above all, have fun with it! Using Vim can be very satisfying, but it can also sometimes feel like it’s just too much, and you will never be able to learn it all. Don’t worry about not knowing everything; just make sure to go at your own pace and enjoy the journey.

Further reading & resources

• Seven habits of effective text editing, by Bram Moolenaar, the author of Vim. Highly recommended for anyone who uses a text editor, even if it’s not Vim!
• Vim awesome — a collection of Vim plugins, browsable using Vim-like commands
• Vim anti-patterns — some tips for being more productive with Vim
• Vim Macros and You — a look into Vim macros for beginners

We’re always optimising our workflows. Whether that’s text editor, project management, or just general business admin. That’s what lets us iterate and build rapidly to solve problems and build products. Get in touch to work with us on your next project.

.

.

.

Pixie Labs is a leading London-based digital product studio with deep software development expertise in Ruby on Rails, React and React Native. We design and build high-impact apps, platforms and digital tools. Let us help you make your digital product a success.

The path to Vimlightenment was originally published in Pixie Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Over the summer Pixie Labs celebrated its fourth birthday, and our gift to ourselves was a sparkling new website! 💃🎈🍾🎉

It’s been an exciting couple of years for us. The team has grown, most recently when I joined this summer; we’ve become an international outfit, with one of our members based in New York; and we’ve had the opportunity to work on some really diverse projects, from mobile apps and open-source software to interactive art exhibitions.

We loved our blue hue, but it was time for a fresh new look for Pixie Labs and a website that really showcases our personality and our portfolio. We wanted something polished and professional, but with a hint of our creative streak. Pixie Labs is an agile team, so we approached the challenge of building our own website in the same way we would any project — breaking down the problem and researching the best tools for the job.

On a technical side, we needed more flexibility in what we choose to present by using a CMS instead of a static website. WordPress is a good choice for this; we really like its ease of use and extensibility. On the other hand, we were less than enthusiastic about architecting and creating a custom WordPress theme and dealing with all the bloat that often goes with that — we’re more of a lean kind of gang. While looking around for inspiration, we came across ustwo’s website, which is both open-source and awesome. Ustwo use WordPress via the WP REST API, meaning they don’t need a WordPress theme. Perfect!

Using the API for our content meant that our options for building the frontend were much more open than with a traditional WordPress site. We were keen to use a modern, lightweight JS stack, and after comparing some frameworks, we decided that the best solution for us was actually to avoid using any of them and instead roll our own Node app. The site would be lightweight and we would have complete control over which templating engine, CSS frameworks and build tools to use.

With this research done, we were able to jump right in and start building out our proof of concept, starting with a barebones WordPress installation, a minimal Express app, and node-wpapi, which made calling the API really easy. Satisfied that it worked, we continued to develop and build on our MVP. We still have a custom WordPress theme, but it only serves content via the API and doesn’t render pages itself. This allows us to modify the WordPress API to include custom routes and fields. Our Node app takes care of the routing and rendering of pages, and we have Webpack for bundling Sass and other assets. We kept the PHP to a minimum, so everybody’s happy!

Along the way, we also discovered Bulma, a great CSS framework that made turning our new designs into a real, functioning website a joy. Who knew that vertical centering in CSS didn’t have to be such a daunting task?

We’re really happy with the way our website turned out, and we hope that you enjoy it too. As the new Pixie on the block, it was lots of fun working on our website and giving the Pixie Labs brand some love, not to mention getting a chance to play around with so many cool bits of tech that are new to myself and to the rest of the team. Our own lead engineer @jalada is so pleased with the result he’s using the WP REST API for all his WordPress sites from now on. We hope that others will be inspired to give it a go!

Unveiling the new Pixie Labs website was originally published in Pixie Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.