The best advice I can think of is to build one. There really aren't any general rules. Everyone's needs (and languages/platforms/tools) and experiences are going to be different, which is great to learn from, but isn't going to present you with prescriptive advice.
However, since microservices are, by definition, small, building something basic is not complex or time-consuming. I'd suggest tackling something fundamental, such as user login and restricting service actions based on, say, a user's role.
This is all well-established stuff in web-based apps via sessions, etc., but presents a number of issues when using microservices. For example, you'll probably want some sort of token (for the user) and a way to manage it.
Going through those steps will get your brain ticking over about any number of problems and will provide you with much learning.
Since you are using Rails, I'd suggest creating a User service (one rails app) and a Blah service (another rails app) that requires authorisation to access some actions. Building that, and thinking through the issues, and building solutions, will give you a lot of feel for building microservices.
Rails (specifically v4 in API-mode, which avoids a lot of MVC stuff) is actually quite cool for microservices, where you can leverage its filters and gems to provide cross service functionality -- like the token handling I alluded to above.
(As an aside: if you do do the above, you'll probably find that you need some sort of "system/root" user access to some services. The "obvious" solution is to create such a user with super powers (that only the system can use). However, think through the implications of this -- massive potential security hole -- and other ways in which you can provide the required services. Actually, thinking about it, that might be a prescriptive rule: never create a super/root user -- that's not to say that a user can't have, say, an admin role.)