6 Things You Should Stop Hiding From Your Personal Trainer

Posted on by azhiganov
A great trainer can be so inspiring and motivating—and ridiculously fit—that it’s easy to be less than honest about your nacho-centric diet or your boredom with her workout plan. But here’s the deal: Working with a personal trainer is about improving your health, and you wouldn’t lie or withhold information from your doctor and expect her to treat you effectively, right?
“You cannot give your trainer too much information,” says personal trainer Hannah Davis, CSCS, founder of Body by Hannah and author of Operation Bikini Body Training Program. Davis starts each new client relationship with a detailed questionnaire; the answers to which help her understand her clients’ real and perceived strengths and weaknesses. And this shouldn’t be a one-time conversation, she says. At the beginning and end of each workout, check in and volunteer relevant info, even if your trainer hasn’t asked. Here, the six things Davis says you just gotta divulge to your personal trainer to get the most out of those sessions—even if it makes you more uncomfortable than using the thigh adductor machine.

1. Your personal life is a little crazy right now.

If a family member is sick or you’re transitioning to a new job or home, your head is not going to be 100 percent at the gym. You don’t have to give your trainer any details you don’t feel comfortable sharing, but let him know you’re stressed. You know that’s trickling down to the way you eat, sleep and train, so your trainer needs a heads up so they can adjust your workouts accordingly. “I’m there to help your physical body, but because it’s very connected to the emotional self, it’s important that we address both in order to get the best physical results,” says Davis.

2. What you actually thought of the workout you just did.

Personal trainers are working for you, as the boss you need to give feedback on what you think of their performance. So don’t keep your trainer in the dark about the moves you’re less than fond of—though we can’t guarantee they’ll completely nix them. “If you absolutely hate an exercise, tell me! You should enjoy your workouts and there are many ways to work the same muscle group,” says Davis. Explore your options with your trainer until you find something that’s effective and fun.

3. Everything you’re really eating. And drinking.

Most of the time we don’t even think we’re lying about this stuff—we just do a lot of generalizing. And while not all trainers are nutritionists, they need to know what you’re putting into your body. Get granular about it. Does “healthy eating” include details about your daily sugary Starbucks habit? Davis says learning about these diet details usually leads to a breakthrough in her clients’ training. “Once a client can be totally honest about how they eat, I can help them make small changes that add up and help them get the most from their training sessions.”

4. When you’re more than sore.

If you continue to say your workout was great—and ignore that stabbing sensation in your foot—your trainer will continue to create your workouts based on the progress it appears you’re making, or you should be making. When that injury comes on full force, you’re going to be set back more than if you’d asked for a modification from the start. “Generally, a client won’t tell me their knee or shoulder hurts until I figure it out on my own, or it becomes just too unbearable,” says Davis. “Then, I am able to address it with corrective exercise techniques and when it gets better, they’re able to get stronger and build more muscle.” Of course, always address sharp pains or if something doesn’t feel quite right in the moment.

5. When someone you’re close with isn’t on board.

A mini cheering squad makes all the difference when you’re making a major physical change or lifestyle commitment. If your friends, family, roommates or S.O. isn’t providing that support, your trainer wants to know. When this happens, Davis says she works with her client to find ways to keep them motivated and accountable or she creates a plan to get the other person on board.

6. Your biggest fears.

Even if those fears are about the program you’re starting. Davis says this is one of the best insights she can have into how to help her clients improve the physical and mental aspects of their training. “Is it that it didn’t work last time? Are you afraid to fail? Are you afraid of heavy weights? I want to know!”

Does your trainer know the answers to all of these questions? If not, time to start sharing. Don’t be afraid to get personal—it’ll only make your workouts better for the both of you.

Visit our website and join the mailing list. Our app is coming soon: https://www.fitradar.me/

P.S. Source: https://www.self.com/story/6-things-women-hide-from-their-personal-trainers

Let’s keep the distances

Posted on by dzidai

In my last article I mentioned that we had cases when we needed to split our back-end application across several processes and as a result we gained more flexibility when we needed to scale the application. This time I want to keep sharing some insights on why we try to keep some parts of the application loosely coupled. This time I wanted to talk about loose coupling at design time when the whole application might run in the single process. According to one of the definitions ”loosely coupled system is one in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components”. In object oriented paradigm, that we are using to create our Fitradar application, most of the code is spread among various classes and therefore the smallest component that we consider is a class. And since classes are just containers for data and functions then we usually see the loose coupling as a way how to call a function of another class with little information as possible.

The simplest way how to call a method on the other object is to create that object from a class (in Java and C# we do that by new operator) and call the needed method. But it turns out there are many cases when it is undesirable to know the class name of an object or even a specific method name during the design time and therefore there are several methods how to reduce the knowledge of a class we are going to use and a method we are going to call:

  • We can replace a class with an interface or an abstract class and in such way reduce the information about the class to the subset of methods that the other classes are interested in. In Object Oriented programming this is known as Polymorphism and is one of the OOP cornerstones. It is really hard to express how important this OOP feature is. I think back in a day that feature was one of the selling points of OOP that pushed out the procedural programming. The biggest gain of using Polymorphism is a flexibility. Now we are not bound to a single code execution flow, because every function that is presented in the execution flow via interface or abstract class can be replaced with other implementation through the configuration or dynamically during a runtime. This in turn opens whole bunch of new possibilities. And the one I like the most is Unit testing. Now days it is hard to imagine how much work it would require to isolate the piece of code and test it without the interfaces that can be mocked.
  • Sometimes we are interested only in one method of the other class and we don’t want to be bound to single class that implements this method, and we want to replace that method implementation. In order to reduce the knowledge about the other class to single methods signature we can use delegates in C#, functional interfaces in Java, Kotlin or function pointers in C\C++. Not all OOP languages provide such constructs though then we should use more verbose interfaces or abstract classes. A delegate can bee seen as placeholder for a method. And once we start to focus on a method without accompanying class we start to enter the realm of Functional programming where function implementation can be written as lambda expression (anonymous functions) and its return type and arguments can be other functions. The most common areas where the function placeholders are used are events and callbacks. And once Linq came out everyone who got to know this library really started to appreciate lambda expressions
  • In cases where Interfaces and Anonymous methods are not enough to describe dependency, for example we don’t want to restrict a method description in our execution flow with a single signature and want to use different rules to describe the method or a class that contains the method, then we can use Reflection. Although Reflection is very powerful tool that allows to achieve a great flexibility, usually it is not recommended to use because it adds an overhead at runtime and degrades the performance

On the larger scale where components are not anymore single classes but the whole systems the loose coupling further can be achieved by introducing the middle-ware like Queues and Service Buses.

As we can see making a method call something that is not bound to a single implementation opens up a dozen of options how to design and build an application in very flexible way.

P.S. Visit http://fitradar.me/ and join the mailing list!

Stay Loose

Posted on by dzidai

Recently our team finished the work on FitRadar booking system. That was quite a challenging task and I decided to share some insights and knowledge we gained during the design and development of this system. Already on the early stage of designing and requirement gathering it was clear that ticket booking system on the back-end should be independent from the rest of the Fitradar system because we wanted to introduce Event Sourcing for such entities as Order and Payment. Since these two entities are responsible of money charging and money is always a very sensitive topic, we wanted to make sure we can always track down the state changes in booking and payment processes. But to what degree it should be independent was the question we had to answer.

Let’s start with a simple case we considered – one process application. In this kind of applications all communications between objects occur within one process and it means all libraries needed for application are loaded in single process. Usually when we talk about the client side applications – Android, iOS or client side JavaScript, then most of the time these kind of applications work within one process and rarely leave the boundaries of that process set by OS. In such case the isolation can be introduced on the code level, like implementing the new feature in a new library, but at runtime we are somewhat limited. Since all objects share the same process:

  • fault in one object might lead to crash in another object
  • the load of a single object affects the whole process, so we can’t assign PC resources to separate app components. It means you can only scale the whole application, usually by creating a new instance of the application. This starts to play a big role when app is hosted on cloud environment like Azure, Google Cloud or AWS where we must pay for used resources.
  • It is hard to apply new technology or framework to the new feature. Usually the whole application is build based on single architectural pattern like MVC and CRUD or MVC and CQRS and it is hard to introduce one more pattern (if we already using simple Data Access Objects for working with data coming from web, then it will take some time to introduce CQRS with Event Sourcing) in the same application. It is much simpler to create a new application.

So there is very little we can do about object decoupling at runtime in single process application case, but do we really need to deploy a booking system in a separate application? Maybe we can just isolate our booking system in a separate library and still run it in the same process with the rest of FitRadar libraries? And so we started to investigate it. Very quickly we noticed that our ideas of making booking system independent from the rest of application strongly reassembles the principles of Microservices architecture . And since now days there are a lot of talks around the Microservices we thought that our project might be a good candidate to move to Microservices architecture. But just because something is promoted doesn’t mean it fits your needs. You usually don’t start the development of application as a distributed system, unless it was a requirement from the beginning. Applications usually mature to the state when Monolithic Architecture doesn’t satisfy the initial requirements and a team starts to consider switching to Microservices Architecture. And we wanted to make sure that this is the time when the new feature requires us to switch to the new Architecture to make the development easier in the future. Here are the advantages of Microservices Architecture that really attracted our attention:

  • it gives us a smaller code base to work with. It is a really huge benefit if you consider that at certain point a team more and more starts to think about how properly structure the project (how to write the Clean Code), that any new developer could easy understand it and navigate it. And putting a Booking system as a separate solution would allow as to reduce the code complexity and as result would allow developers navigate faster and add new code faster. If you have ever worked on enterprise scale application development then you know how much time it can take just to figure out where to put your new code.
  • Web API end to end tests and Integration tests can run much faster because there is no need to load all of the Fitradar system libraries only those related to booking system. This advantage really starts to shine when we enter the test phase.
  • It allows us to scale booking system and the rest of the back-end application independently. The booking system is more focused on data writing in the database on the other hand main back-end application is focused on data serving. We expect thousands of data requests a day while user will be navigating around in mobile application and just few bookings a day.
  • Improved fault isolation

And for our project it seemed that we will gain more than loose if we will treat booking system as separate application and deploy it in a separate process. So we gave it a try.

Visit our website: http://fitradar.me/ and join the mailing list. Our app is coming soon!