OwlTail

Cover image of Taras Mankovski

Taras Mankovski Podcasts

Read more

9 of The Best Podcast Episodes for Taras Mankovski. A collection of podcasts episodes with or about Taras Mankovski, often where they are interviewed.

Read more

9 of The Best Podcast Episodes for Taras Mankovski. A collection of podcasts episodes with or about Taras Mankovski, often where they are interviewed.

Updated daily with the latest episodes

Episode artwork

JSJ 337: Microstates.js – Composable State Primitives for JavaScript with Charles Lowell & Taras Mankovski

Play
Read more

Panel:

  • Aimee Knight
  • Charles Max Wood
  • Joe Eames
  • AJ O’Neil
  • Chris Ferdinandi 

Special Guests: Charles Lowell (New Mexico) & Taras Mankovski (Toronto)

In this episode, the panel talks with two special guests Charles and Taras. Charles Lowell is a principle engineer at Frontside, and he loves to code. Taras works with Charles and joined Frontside, because of Charles’ love for coding. There are great personalities at Frontside, which are quite diverse. Check out this episode to hear about microstates, microstates with react, Redux, and much more!

Show Topics:

1:20 – Chuck: Let’s talk about microstates – what is that?

1:32 – Guest: My mind is focused on the how and not the what. I will zoom my mind out and let’s talk about the purposes of microstates. It means a few things. 1.) It’s going to work no matter what framework you are using. 2.) You shouldn’t have to be constantly reinventing the wheel. React Roundup – I talked about it there at this conference. 

Finally, it really needs to feel JavaScript. We didn’t want you to feel like you weren’t using JavaScript. It uses computer properties off of those models. It doesn’t feel like there is anything special that you are doing. There are just a few simple rules. You can’t mutate the state in place. If you work with JavaScript you can use it very easily. Is that a high-level view?

7:13 – Panel: There are a lot of pieces. If I spoke on a few specific things I would say that it enables programming with state machines.

7:42 – Panel: We wanted it to fell like JavaScript – that’s what I heard.

7:49 – Aimee: I heard that, too.

7:59 – Guest.

8:15 – Aimee: Redux feels like JavaScript to me.

8:25 – Guest: It’s actually – a tool – that it feels natural so it’s not contrived. It’s all JavaScript.

8:49 – Panel.

9:28 – Guest: Idiomatic Ember for example. Idiomatic in the sense that it gives you object for you to work with, which are simple objects.

10:12 – Guest: You have your reducers and your...we could do those things but ultimately it’s powerful – and not action names – we use method names; the name of the method.

11:20 – Panel: I was digging through docs, and it feels like NORMAL JavaScript. It doesn’t seem like it’s tied to a certain framework or library platform?

11:45 – Guest: Yes, we felt a lot of time designing the interfaces the API and the implementation. We wanted it to feel natural but a tool that people reach for.

(Guest continues to talk about WHY they created microstates.)

Guest: We wanted to scale very well what you need when your needs to change.

13:39 – Chuck: I have a lot of friends who get into React and then they put in Redux then they realize they have to do a lot of work – and that makes sense to do less is more.

14:17 – Guest: To define these microstates and build them up incrementally...building smaller microstates out of larger ones.

Guest continued: Will we be able to people can distribute React components a sweet array of components ready for me to use – would I be able to do the same for a small piece of state? We call them state machines, but ultimately we have some state that is driving it. Would we be able to distribute and share?

16:15 – Panel: I understand that this is tiny – but why wouldn’t I just use the native features in specific the immutability component to it?

16:42 – Guest: I’m glad you asked that question. We wanted to answer the question...

Guest: With microstates you can have strict control and it gives you the benefit of doing sophisticated things very easily.

18:33 – Guest: You mentioned immutability that’s good that you did. It’s important to capture – and capturing the naturalness of JavaScript. It’s easy to build complex structures – and there is an appeal to that. We are building these graphs and these building up these trees. You brought up immutability – why through it away b/c it’s the essence of being a developer. If you have 3-4-5 levels of nesting you have to de-structure – get to the piece of data – change it – and in your state transition 80% of your code is navigating to the change and only 20% to actually make the change. You don’t have to make that tradeoff.

21:25 – Aimee: The one thing I like about the immutability b/c of the way you test it.

21:45 – Guest: There a few things you can test. 

23:01 – Aimee: You did a good job of explaining it.

23:15 – Guest: It makes the things usually hard  easy! With immutability you can loose control, and if that happens you can get so confused. You don’t have a way to have a way to navigate to clarity. That’s what this does is make it less confusing. It gives you order and structure. It gives you a very clear path to do things you need to do. If there is a property on your object, and if there is a way to change it...

25:29 – Guest: The only constant is change no matter what framework you are working on.

24:46 – Chuck: We are talking about the benefits and philosophy. What if I have an app – and I realize I need state management – how do I put microstates into my app? It’s using Angular or React – how do I get my data into microstates?

26:35 – Guest: I can tell you what the integration looks like for any framework. You take a type and you passed that type and some value to the create function so what you get is a microstate.

(The Guest continues diving into his answer.)

28:18 – Guest: That story is very similar to Redux, basically an event emitter. The state changes on the store.

Maybe this is a good time to talk about the stability benefits and the lazy benefits because microstates is both of those things.

Stability – if I invoke a transition and the result is unchanged – same microstate – it doesn’t emit an event. It recognizes it internally. It will recognize that it’s the same item. Using that in Ember or Redux you’d have to be doing thousands of actions and doing all that computation, but stability at that level.

Also, stability in the sense of a tree. If I change one object then that changes it won’t change an element that it doesn’t need to change.

31:33 – Advertisement: Sentry.io

32:29 – Guest: I want to go back to your question, Chuck. Did we answer it?

32:40 – Chuck: Kind of.

32:50 – Guest.

32:59 – Guest: In Angular for example you can essentially turn a microstate...

33:51 – Guest: You could implement a connect, too. Because the primitive is small – there is no limit.

34:18 – Chuck summarizes their answers into his own words.

34:42 – Guest: If you were using a vanilla React component – this dot – I will bind this. You bind all of these features and then you pass them into your template. You can take it as a property...those are those handlers. They will perform the transition, update and what needs to be updated will happen.

35:55 – Chuck: Data and transitions are 2 separate things but you melded them together to feel like 1 thing. This way it keeps clean and fast.

36:16 – Guest: Every framework helps you in each way.

Microstates let’s you do a few things: the quality of your data all in one place and you can share.

38:12 – Guest: He made and integrated Microstates with Redux tools.

38:28 – Guest talks about paths, microstates to trees.

39:22 – Chuck.

39:25 – Panel: When I think about state machines I have been half listening / half going through the docs. When I think of state machines I think about discreet operations like a literal machine. Like a robot of many steps it can step through. We have been talking about frontend frameworks like React - is this applicable to the more traditional systems like mechanical control or is it geared towards Vue layered applications?

40:23 – Guest: Absolutely. We have BIG TEST and it has a Vue component.

41:15 – Guest: when you create a microstate from a type you are creating an object that you can work with.

42:11 – Guest: Joe, I know you have experience with Angular I would love to get your insight.

42:33 – Joe: I feel like I have less experience with RX.js. A lot of what we are talking about and I am a traditionalist, and I would like you to introduce you guys to this topic. From my perspective, where would someone start if they haven’t been doing Flux pattern and I hear this podcast. I think this is a great solution – where do I get started? The official documents? Or is it the right solution to that person?

43:50 – Guest: Draw out the state machine that you want to represent in your Vue. These are the states that this can be in and this is the data that is required to get from one thing to the other. It’s a rope process. The arrow corresponds to the method, and...

44:49 – Panel: It reminds me back in the day of rational rows.

44:56 – Guest: My first job we were using rational rows.

45:22 – Panelist: Think through the state transitions – interesting that you are saying that. What about that I am in the middle – do you stop and think through it or no?

46:06 – Guest: I think it’s a Trojan horse in some ways. I think what’s interesting you start to realize how you implement your state transitions.

48:00 – (Guest continues.)

48:45 – Panel: That’s interesting. Do you have that in the docs to that process of stopping and thinking through your state transitions and putting into the microstate?

49:05 – Guest: I talked about this back in 2016. I outlined that process. When this project was in the Ember community.

49:16 – Guest: The next step for us is to make this information accessible. We’ve been shedding a few topics and saying this is how to use microstates in your project. We need to write up those guides to help them benefit in their applications.

50:00 – Chuck: What’s the future look like?

50:03 – Guest: We are working on performance profiling.

Essentially you can hook up microstates to a fire hose.

The next thing is settling on a pattern for modeling side effects inside microstates. Microstates are STATE and it’s immutable.

52:12 – Guest: Getting documentation. We have good README but we need traditional docs, too.

52:20 – Chuck: Anything else?

52:28 – Guest: If you need help email us and gives us a shot-out.

53:03 – Chuck: Let’s do some picks!

53:05 – Advertisement for Charles Max Wood’s course!

Links:

Sponsors:

Picks:

Aimee

Taras

Charles Lowell

Chris

Joe

AJ

Charles

Oct 30 2018 · 1hr 18mins
Episode artwork

JSJ 337: Microstates.js – Composable State Primitives for JavaScript with Charles Lowell & Taras Mankovski

Play
Read more

Panel:

  • Aimee Knight
  • Charles Max Wood
  • Joe Eames
  • AJ O’Neil
  • Chris Ferdinandi 

Special Guests: Charles Lowell (New Mexico) & Taras Mankovski (Toronto)

In this episode, the panel talks with two special guests Charles and Taras. Charles Lowell is a principle engineer at Frontside, and he loves to code. Taras works with Charles and joined Frontside, because of Charles’ love for coding. There are great personalities at Frontside, which are quite diverse. Check out this episode to hear about microstates, microstates with react, Redux, and much more!

Show Topics:

1:20 – Chuck: Let’s talk about microstates – what is that?

1:32 – Guest: My mind is focused on the how and not the what. I will zoom my mind out and let’s talk about the purposes of microstates. It means a few things. 1.) It’s going to work no matter what framework you are using. 2.) You shouldn’t have to be constantly reinventing the wheel. React Roundup – I talked about it there at this conference. 

Finally, it really needs to feel JavaScript. We didn’t want you to feel like you weren’t using JavaScript. It uses computer properties off of those models. It doesn’t feel like there is anything special that you are doing. There are just a few simple rules. You can’t mutate the state in place. If you work with JavaScript you can use it very easily. Is that a high-level view?

7:13 – Panel: There are a lot of pieces. If I spoke on a few specific things I would say that it enables programming with state machines.

7:42 – Panel: We wanted it to fell like JavaScript – that’s what I heard.

7:49 – Aimee: I heard that, too.

7:59 – Guest.

8:15 – Aimee: Redux feels like JavaScript to me.

8:25 – Guest: It’s actually – a tool – that it feels natural so it’s not contrived. It’s all JavaScript.

8:49 – Panel.

9:28 – Guest: Idiomatic Ember for example. Idiomatic in the sense that it gives you object for you to work with, which are simple objects.

10:12 – Guest: You have your reducers and your...we could do those things but ultimately it’s powerful – and not action names – we use method names; the name of the method.

11:20 – Panel: I was digging through docs, and it feels like NORMAL JavaScript. It doesn’t seem like it’s tied to a certain framework or library platform?

11:45 – Guest: Yes, we felt a lot of time designing the interfaces the API and the implementation. We wanted it to feel natural but a tool that people reach for.

(Guest continues to talk about WHY they created microstates.)

Guest: We wanted to scale very well what you need when your needs to change.

13:39 – Chuck: I have a lot of friends who get into React and then they put in Redux then they realize they have to do a lot of work – and that makes sense to do less is more.

14:17 – Guest: To define these microstates and build them up incrementally...building smaller microstates out of larger ones.

Guest continued: Will we be able to people can distribute React components a sweet array of components ready for me to use – would I be able to do the same for a small piece of state? We call them state machines, but ultimately we have some state that is driving it. Would we be able to distribute and share?

16:15 – Panel: I understand that this is tiny – but why wouldn’t I just use the native features in specific the immutability component to it?

16:42 – Guest: I’m glad you asked that question. We wanted to answer the question...

Guest: With microstates you can have strict control and it gives you the benefit of doing sophisticated things very easily.

18:33 – Guest: You mentioned immutability that’s good that you did. It’s important to capture – and capturing the naturalness of JavaScript. It’s easy to build complex structures – and there is an appeal to that. We are building these graphs and these building up these trees. You brought up immutability – why through it away b/c it’s the essence of being a developer. If you have 3-4-5 levels of nesting you have to de-structure – get to the piece of data – change it – and in your state transition 80% of your code is navigating to the change and only 20% to actually make the change. You don’t have to make that tradeoff.

21:25 – Aimee: The one thing I like about the immutability b/c of the way you test it.

21:45 – Guest: There a few things you can test. 

23:01 – Aimee: You did a good job of explaining it.

23:15 – Guest: It makes the things usually hard  easy! With immutability you can loose control, and if that happens you can get so confused. You don’t have a way to have a way to navigate to clarity. That’s what this does is make it less confusing. It gives you order and structure. It gives you a very clear path to do things you need to do. If there is a property on your object, and if there is a way to change it...

25:29 – Guest: The only constant is change no matter what framework you are working on.

24:46 – Chuck: We are talking about the benefits and philosophy. What if I have an app – and I realize I need state management – how do I put microstates into my app? It’s using Angular or React – how do I get my data into microstates?

26:35 – Guest: I can tell you what the integration looks like for any framework. You take a type and you passed that type and some value to the create function so what you get is a microstate.

(The Guest continues diving into his answer.)

28:18 – Guest: That story is very similar to Redux, basically an event emitter. The state changes on the store.

Maybe this is a good time to talk about the stability benefits and the lazy benefits because microstates is both of those things.

Stability – if I invoke a transition and the result is unchanged – same microstate – it doesn’t emit an event. It recognizes it internally. It will recognize that it’s the same item. Using that in Ember or Redux you’d have to be doing thousands of actions and doing all that computation, but stability at that level.

Also, stability in the sense of a tree. If I change one object then that changes it won’t change an element that it doesn’t need to change.

31:33 – Advertisement: Sentry.io

32:29 – Guest: I want to go back to your question, Chuck. Did we answer it?

32:40 – Chuck: Kind of.

32:50 – Guest.

32:59 – Guest: In Angular for example you can essentially turn a microstate...

33:51 – Guest: You could implement a connect, too. Because the primitive is small – there is no limit.

34:18 – Chuck summarizes their answers into his own words.

34:42 – Guest: If you were using a vanilla React component – this dot – I will bind this. You bind all of these features and then you pass them into your template. You can take it as a property...those are those handlers. They will perform the transition, update and what needs to be updated will happen.

35:55 – Chuck: Data and transitions are 2 separate things but you melded them together to feel like 1 thing. This way it keeps clean and fast.

36:16 – Guest: Every framework helps you in each way.

Microstates let’s you do a few things: the quality of your data all in one place and you can share.

38:12 – Guest: He made and integrated Microstates with Redux tools.

38:28 – Guest talks about paths, microstates to trees.

39:22 – Chuck.

39:25 – Panel: When I think about state machines I have been half listening / half going through the docs. When I think of state machines I think about discreet operations like a literal machine. Like a robot of many steps it can step through. We have been talking about frontend frameworks like React - is this applicable to the more traditional systems like mechanical control or is it geared towards Vue layered applications?

40:23 – Guest: Absolutely. We have BIG TEST and it has a Vue component.

41:15 – Guest: when you create a microstate from a type you are creating an object that you can work with.

42:11 – Guest: Joe, I know you have experience with Angular I would love to get your insight.

42:33 – Joe: I feel like I have less experience with RX.js. A lot of what we are talking about and I am a traditionalist, and I would like you to introduce you guys to this topic. From my perspective, where would someone start if they haven’t been doing Flux pattern and I hear this podcast. I think this is a great solution – where do I get started? The official documents? Or is it the right solution to that person?

43:50 – Guest: Draw out the state machine that you want to represent in your Vue. These are the states that this can be in and this is the data that is required to get from one thing to the other. It’s a rope process. The arrow corresponds to the method, and...

44:49 – Panel: It reminds me back in the day of rational rows.

44:56 – Guest: My first job we were using rational rows.

45:22 – Panelist: Think through the state transitions – interesting that you are saying that. What about that I am in the middle – do you stop and think through it or no?

46:06 – Guest: I think it’s a Trojan horse in some ways. I think what’s interesting you start to realize how you implement your state transitions.

48:00 – (Guest continues.)

48:45 – Panel: That’s interesting. Do you have that in the docs to that process of stopping and thinking through your state transitions and putting into the microstate?

49:05 – Guest: I talked about this back in 2016. I outlined that process. When this project was in the Ember community.

49:16 – Guest: The next step for us is to make this information accessible. We’ve been shedding a few topics and saying this is how to use microstates in your project. We need to write up those guides to help them benefit in their applications.

50:00 – Chuck: What’s the future look like?

50:03 – Guest: We are working on performance profiling.

Essentially you can hook up microstates to a fire hose.

The next thing is settling on a pattern for modeling side effects inside microstates. Microstates are STATE and it’s immutable.

52:12 – Guest: Getting documentation. We have good README but we need traditional docs, too.

52:20 – Chuck: Anything else?

52:28 – Guest: If you need help email us and gives us a shot-out.

53:03 – Chuck: Let’s do some picks!

53:05 – Advertisement for Charles Max Wood’s course!

Links:

Sponsors:

Picks:

Aimee

Taras

Charles Lowell

Chris

Joe

AJ

Charles

Oct 30 2018 · 1hr 18mins

Similar People

Tracy Lee

Ben Lesh

Kyle Simpson

Yehuda Katz

Aimee Knight

Henrik Joreteg

Charles Lowell

Evan You

Joe Eames

Rob Dodson

Tanmai Gopal

Alex Eagle

Brady Gaster

Noel Rappin

Aaron Gustafson

Episode artwork

JSJ 337: Microstates.js – Composable State Primitives for JavaScript with Charles Lowell & Taras Mankovski

Play
Read more

Panel:

  • Aimee Knight
  • Charles Max Wood
  • Joe Eames
  • AJ O’Neil
  • Chris Ferdinandi 

Special Guests: Charles Lowell (New Mexico) & Taras Mankovski (Toronto)

In this episode, the panel talks with two special guests Charles and Taras. Charles Lowell is a principle engineer at Frontside, and he loves to code. Taras works with Charles and joined Frontside, because of Charles’ love for coding. There are great personalities at Frontside, which are quite diverse. Check out this episode to hear about microstates, microstates with react, Redux, and much more!

Show Topics:

1:20 – Chuck: Let’s talk about microstates – what is that?

1:32 – Guest: My mind is focused on the how and not the what. I will zoom my mind out and let’s talk about the purposes of microstates. It means a few things. 1.) It’s going to work no matter what framework you are using. 2.) You shouldn’t have to be constantly reinventing the wheel. React Roundup – I talked about it there at this conference. 

Finally, it really needs to feel JavaScript. We didn’t want you to feel like you weren’t using JavaScript. It uses computer properties off of those models. It doesn’t feel like there is anything special that you are doing. There are just a few simple rules. You can’t mutate the state in place. If you work with JavaScript you can use it very easily. Is that a high-level view?

7:13 – Panel: There are a lot of pieces. If I spoke on a few specific things I would say that it enables programming with state machines.

7:42 – Panel: We wanted it to fell like JavaScript – that’s what I heard.

7:49 – Aimee: I heard that, too.

7:59 – Guest.

8:15 – Aimee: Redux feels like JavaScript to me.

8:25 – Guest: It’s actually – a tool – that it feels natural so it’s not contrived. It’s all JavaScript.

8:49 – Panel.

9:28 – Guest: Idiomatic Ember for example. Idiomatic in the sense that it gives you object for you to work with, which are simple objects.

10:12 – Guest: You have your reducers and your...we could do those things but ultimately it’s powerful – and not action names – we use method names; the name of the method.

11:20 – Panel: I was digging through docs, and it feels like NORMAL JavaScript. It doesn’t seem like it’s tied to a certain framework or library platform?

11:45 – Guest: Yes, we felt a lot of time designing the interfaces the API and the implementation. We wanted it to feel natural but a tool that people reach for.

(Guest continues to talk about WHY they created microstates.)

Guest: We wanted to scale very well what you need when your needs to change.

13:39 – Chuck: I have a lot of friends who get into React and then they put in Redux then they realize they have to do a lot of work – and that makes sense to do less is more.

14:17 – Guest: To define these microstates and build them up incrementally...building smaller microstates out of larger ones.

Guest continued: Will we be able to people can distribute React components a sweet array of components ready for me to use – would I be able to do the same for a small piece of state? We call them state machines, but ultimately we have some state that is driving it. Would we be able to distribute and share?

16:15 – Panel: I understand that this is tiny – but why wouldn’t I just use the native features in specific the immutability component to it?

16:42 – Guest: I’m glad you asked that question. We wanted to answer the question...

Guest: With microstates you can have strict control and it gives you the benefit of doing sophisticated things very easily.

18:33 – Guest: You mentioned immutability that’s good that you did. It’s important to capture – and capturing the naturalness of JavaScript. It’s easy to build complex structures – and there is an appeal to that. We are building these graphs and these building up these trees. You brought up immutability – why through it away b/c it’s the essence of being a developer. If you have 3-4-5 levels of nesting you have to de-structure – get to the piece of data – change it – and in your state transition 80% of your code is navigating to the change and only 20% to actually make the change. You don’t have to make that tradeoff.

21:25 – Aimee: The one thing I like about the immutability b/c of the way you test it.

21:45 – Guest: There a few things you can test. 

23:01 – Aimee: You did a good job of explaining it.

23:15 – Guest: It makes the things usually hard  easy! With immutability you can loose control, and if that happens you can get so confused. You don’t have a way to have a way to navigate to clarity. That’s what this does is make it less confusing. It gives you order and structure. It gives you a very clear path to do things you need to do. If there is a property on your object, and if there is a way to change it...

25:29 – Guest: The only constant is change no matter what framework you are working on.

24:46 – Chuck: We are talking about the benefits and philosophy. What if I have an app – and I realize I need state management – how do I put microstates into my app? It’s using Angular or React – how do I get my data into microstates?

26:35 – Guest: I can tell you what the integration looks like for any framework. You take a type and you passed that type and some value to the create function so what you get is a microstate.

(The Guest continues diving into his answer.)

28:18 – Guest: That story is very similar to Redux, basically an event emitter. The state changes on the store.

Maybe this is a good time to talk about the stability benefits and the lazy benefits because microstates is both of those things.

Stability – if I invoke a transition and the result is unchanged – same microstate – it doesn’t emit an event. It recognizes it internally. It will recognize that it’s the same item. Using that in Ember or Redux you’d have to be doing thousands of actions and doing all that computation, but stability at that level.

Also, stability in the sense of a tree. If I change one object then that changes it won’t change an element that it doesn’t need to change.

31:33 – Advertisement: Sentry.io

32:29 – Guest: I want to go back to your question, Chuck. Did we answer it?

32:40 – Chuck: Kind of.

32:50 – Guest.

32:59 – Guest: In Angular for example you can essentially turn a microstate...

33:51 – Guest: You could implement a connect, too. Because the primitive is small – there is no limit.

34:18 – Chuck summarizes their answers into his own words.

34:42 – Guest: If you were using a vanilla React component – this dot – I will bind this. You bind all of these features and then you pass them into your template. You can take it as a property...those are those handlers. They will perform the transition, update and what needs to be updated will happen.

35:55 – Chuck: Data and transitions are 2 separate things but you melded them together to feel like 1 thing. This way it keeps clean and fast.

36:16 – Guest: Every framework helps you in each way.

Microstates let’s you do a few things: the quality of your data all in one place and you can share.

38:12 – Guest: He made and integrated Microstates with Redux tools.

38:28 – Guest talks about paths, microstates to trees.

39:22 – Chuck.

39:25 – Panel: When I think about state machines I have been half listening / half going through the docs. When I think of state machines I think about discreet operations like a literal machine. Like a robot of many steps it can step through. We have been talking about frontend frameworks like React - is this applicable to the more traditional systems like mechanical control or is it geared towards Vue layered applications?

40:23 – Guest: Absolutely. We have BIG TEST and it has a Vue component.

41:15 – Guest: when you create a microstate from a type you are creating an object that you can work with.

42:11 – Guest: Joe, I know you have experience with Angular I would love to get your insight.

42:33 – Joe: I feel like I have less experience with RX.js. A lot of what we are talking about and I am a traditionalist, and I would like you to introduce you guys to this topic. From my perspective, where would someone start if they haven’t been doing Flux pattern and I hear this podcast. I think this is a great solution – where do I get started? The official documents? Or is it the right solution to that person?

43:50 – Guest: Draw out the state machine that you want to represent in your Vue. These are the states that this can be in and this is the data that is required to get from one thing to the other. It’s a rope process. The arrow corresponds to the method, and...

44:49 – Panel: It reminds me back in the day of rational rows.

44:56 – Guest: My first job we were using rational rows.

45:22 – Panelist: Think through the state transitions – interesting that you are saying that. What about that I am in the middle – do you stop and think through it or no?

46:06 – Guest: I think it’s a Trojan horse in some ways. I think what’s interesting you start to realize how you implement your state transitions.

48:00 – (Guest continues.)

48:45 – Panel: That’s interesting. Do you have that in the docs to that process of stopping and thinking through your state transitions and putting into the microstate?

49:05 – Guest: I talked about this back in 2016. I outlined that process. When this project was in the Ember community.

49:16 – Guest: The next step for us is to make this information accessible. We’ve been shedding a few topics and saying this is how to use microstates in your project. We need to write up those guides to help them benefit in their applications.

50:00 – Chuck: What’s the future look like?

50:03 – Guest: We are working on performance profiling.

Essentially you can hook up microstates to a fire hose.

The next thing is settling on a pattern for modeling side effects inside microstates. Microstates are STATE and it’s immutable.

52:12 – Guest: Getting documentation. We have good README but we need traditional docs, too.

52:20 – Chuck: Anything else?

52:28 – Guest: If you need help email us and gives us a shot-out.

53:03 – Chuck: Let’s do some picks!

53:05 – Advertisement for Charles Max Wood’s course!

Links:

Sponsors:

Picks:

Aimee

Taras

Charles Lowell

Chris

Joe

AJ

Charles

Oct 30 2018 · 1hr 18mins

Most Popular

Elon Musk

Barack Obama

Bill Gates

LeBron James

Mark Cuban

Michelle Obama

Melinda Gates

Arnold Schwarzenegger

Kevin Hart

Terry Crews

Mike Tyson

Episode artwork

RRU 028: “Microstates.js – Composable State Primitive” with Taras Mankovski & Charles Lowell

Play
Read more

Panel:

  • Charles (Chuck) Max Wood
  • Lucas Reis

Special Guests: Charles Lowell & Taras Mankovski

In this episode, the panel talks with two special guests Charles and Taras. Charles Lowell is a principle engineer at Frontside, and he loves to code. Taras works with Charles and joined Frontside, because of Charles’ love for coding. There are great personalities at Frontside, which are quite diverse. Check out this episode to hear about microstates, microstates with react, OM, Redux, and much more!

Show Topics:

2:32 – Chuck: Why do we need it (microstates) and why do we need another state library?

2:42 – Charles answers Chuck’s question. Charles goes to explain that if you need to increment the number, you don’t need to do it with microstates.

3:41 – Another suggestion is given on this topic.

5:13 – The application isn’t hard in-of-itself.

6:45 – Chuck makes comments, and asks: It seems to be more like object-oriented approach?

7:44 – Objects compose much more easily. When you are dealing with pure functional code you are de-structuring and restructuring. Check-out LENSES.

9:53 – Taras makes comments. What were your inspirations for microstate?

10:27 – Charles: The personal journey it started for me started back in 2015. When I was working primarily in Ember.” Charles makes a reference to OM, check it out!

15:40 – Charles: “We had a goal in mind, and we kept that goal on mind and kept ‘dipping into the candy jar.’ We had to learn about the functional mumbo-jumbo. The goal was never to use those things. Whatever tools we needed from the functional world, we borrowed from freely.”

16:50 – Chuck asks a question.

17:00 – Taras answers chuck’s question.

19:58 – Charles (guest) keeps the conversation going and goes into detail about how to handle different scenarios with different tools.

21:00 – Question: How do you think microstate enters into this situation?

21:45 – The design of microstate is that it gives you a solution that is flexible. Other options aren’t as comprehensive like where you can use it; for example Redux.

23:49 – Another way to say it is...check-out this timestamp to hear other ideas about this topic.

24:53 – Digital Ocean’s Advertisement

25:28 – Conversation is back into swing.

Question: There is a very interesting design with people who are not developers. What are the benefits or do they play together?

26:41 – As a frontend shop, there is a very clean mapping between state machine and type. The type corresponds to the state transitions, among others. For every state you have a class, and you have a method for every transition. It’s a great design tool.

29:07 – We don’t talk about states very often, right now, but in the near future we will. The valuable goals for us are to give people tools that will work correctly for them. To help people be more productive that is a great goal. One thing from people, I’ve learned, is to ask yourself ‘what needs to change?’

33:03 – Now you are touching on the subject of teaching. What about mentoring with microstates?

33:26 – Success (to one of the panelists) is defined of how confident a person is with X program or tool. If they have ease, then they are on the right path. With mentoring in microstates the design speaks its purpose, the transitions are clear, so the panelist feels that he doesn’t really have to go into a lot of detail explaining the features.

36:25 – In the React community... 

39:12 – Curious: Would we really be able to distribute state like how we distribute components? What is out-of-reach now, is that we have the state machine for the autocomplete component.

40:27 – Chuck: Is there a way to test microstates?

41:28 – Shameless plug...check it out!

42:31 – Anything else? Microstates and Microstates with React.

42:48 – If anyone is interested in this, then we are interested in talking with these people and/or companies.

43:29 – Let’s go to Picks!

43:31 – Advertisement for Charles Max Wood’s course!

Links:

Sponsors:

Picks:

Charles (Chuck)

Lucas

  • Take care of your health!
  • Martial Arts and Jujitsu
  • Nutrition

Charles (guest)

Taras (guest)

Sep 11 2018 · 52mins
Episode artwork

RRU 028: “Microstates.js – Composable State Primitive” with Taras Mankovski & Charles Lowell

Play
Read more

Panel:

  • Charles (Chuck) Max Wood
  • Lucas Reis

Special Guests: Charles Lowell & Taras Mankovski

In this episode, the panel talks with two special guests Charles and Taras. Charles Lowell is a principle engineer at Frontside, and he loves to code. Taras works with Charles and joined Frontside, because of Charles’ love for coding. There are great personalities at Frontside, which are quite diverse. Check out this episode to hear about microstates, microstates with react, OM, Redux, and much more!

Show Topics:

2:32 – Chuck: Why do we need it (microstates) and why do we need another state library?

2:42 – Charles answers Chuck’s question. Charles goes to explain that if you need to increment the number, you don’t need to do it with microstates.

3:41 – Another suggestion is given on this topic.

5:13 – The application isn’t hard in-of-itself.

6:45 – Chuck makes comments, and asks: It seems to be more like object-oriented approach?

7:44 – Objects compose much more easily. When you are dealing with pure functional code you are de-structuring and restructuring. Check-out LENSES.

9:53 – Taras makes comments. What were your inspirations for microstate?

10:27 – Charles: The personal journey it started for me started back in 2015. When I was working primarily in Ember.” Charles makes a reference to OM, check it out!

15:40 – Charles: “We had a goal in mind, and we kept that goal on mind and kept ‘dipping into the candy jar.’ We had to learn about the functional mumbo-jumbo. The goal was never to use those things. Whatever tools we needed from the functional world, we borrowed from freely.”

16:50 – Chuck asks a question.

17:00 – Taras answers chuck’s question.

19:58 – Charles (guest) keeps the conversation going and goes into detail about how to handle different scenarios with different tools.

21:00 – Question: How do you think microstate enters into this situation?

21:45 – The design of microstate is that it gives you a solution that is flexible. Other options aren’t as comprehensive like where you can use it; for example Redux.

23:49 – Another way to say it is...check-out this timestamp to hear other ideas about this topic.

24:53 – Digital Ocean’s Advertisement

25:28 – Conversation is back into swing.

Question: There is a very interesting design with people who are not developers. What are the benefits or do they play together?

26:41 – As a frontend shop, there is a very clean mapping between state machine and type. The type corresponds to the state transitions, among others. For every state you have a class, and you have a method for every transition. It’s a great design tool.

29:07 – We don’t talk about states very often, right now, but in the near future we will. The valuable goals for us are to give people tools that will work correctly for them. To help people be more productive that is a great goal. One thing from people, I’ve learned, is to ask yourself ‘what needs to change?’

33:03 – Now you are touching on the subject of teaching. What about mentoring with microstates?

33:26 – Success (to one of the panelists) is defined of how confident a person is with X program or tool. If they have ease, then they are on the right path. With mentoring in microstates the design speaks its purpose, the transitions are clear, so the panelist feels that he doesn’t really have to go into a lot of detail explaining the features.

36:25 – In the React community... 

39:12 – Curious: Would we really be able to distribute state like how we distribute components? What is out-of-reach now, is that we have the state machine for the autocomplete component.

40:27 – Chuck: Is there a way to test microstates?

41:28 – Shameless plug...check it out!

42:31 – Anything else? Microstates and Microstates with React.

42:48 – If anyone is interested in this, then we are interested in talking with these people and/or companies.

43:29 – Let’s go to Picks!

43:31 – Advertisement for Charles Max Wood’s course!

Links:

Sponsors:

Picks:

Charles (Chuck)

Lucas

  • Take care of your health!
  • Martial Arts and Jujitsu
  • Nutrition

Charles (guest)

Taras (guest)

Sep 11 2018 · 52mins
Episode artwork

099: Funcadelic with Taras Mankovski

Play
Read more

Taras Mankovski: tarasm

In this episode, Taras and Charles talk about a project that they work on together: Funcadelic - a Functional Programming and Category Theory for Everyday JavaScript Development.

Funcadelic takes the simple idea that a single function can operate on many different data structures (typeclass oriented programming) and brings it to JavaScript. Yes, there are a lot of FP libraries out there, but this one is geared towards unlocking the magical powers of functional programming while always maintaining a tangible and accessible experience for JavaScript developers. Because if you're a JavaScript developer today, you're already using most of the structures in funcadelic!

Transcript:

CHARLES: Hello everybody and welcome to The Frontside Podcast Episode 99. My name is Charles Lowell, developer here at The Frontside and your podcast host-in-training. And with me today is Mr. Taras Mankovski. Welcome.

TARAS: Thank you, Charles. It’s a pleasure to be here.

CHARLES: Yeah. So, you are ubiquitous in the JavaScript world. You do a lot of stuff with mentoring and you are involved in a bunch of different interesting projects. I think you’re one of those developers who’s difficult to classify, which is – that’s definitely one of my favorite kind of developers. I wanted to have you on the show today because there’s been a project that we’ve been collaborating on. And there have been some interesting ideas to come out of that and solidify through that project, at least in my head. And yeah, I thought we could maybe just talk about that a little bit.

TARAS: Yeah, sounds good. It’s going to be fun.

The thing that we are going to be talking about is a project called Funcadelic. It’s more than really just a library, a JavaScript library on GitHub. It’s kind of a different way of thinking about your code. And so, I know for me, where this really became part of my workflow was, when was it? It was about three months ago or something like that? Six months ago?

TARAS: Oh, I think yeah, I think it’s probably more six months ago. I think it’s probably what, two months, I think probably December maybe?

CHARLES: Okay. But it’s hard now to imagine working without this tool on my workbench. It’s been probably the biggest game-changer for me in the last, I don’t know, definitely in the last several years.

TARAS: Yeah, it’s pretty impressive how little, how small of a library can have such a big impact in what we do day-to-day. Because it definitely makes me think differently about how I can solve problems that I solve on a daily basis when I work with React. So, it’s been pretty interesting. I think for me, having worked with this library, I think what I’m getting is an understanding of how things work in a way, and a perspective on how React works, in a way that I don’t think was available to [inaudible] Funcadelic. The funny thing is it’s not a React library, right? It’s not designed for React. It’s just that…

CHARLES: I don’t even think that – it helps you think about React, but I don’t even think it’s the way that the React developers think about React, right?

TARAS: Yeah, I don’t think so, either. I think a lot of people are on the spectrum of understanding functional programming. And I think a lot of people use, people learn how to use React, but they don’t really – I don’t think a lot of people have traveled very far. I’m talking about general, majority. There’s definitely people who know functional programming really well. And there’s a lot of really good libraries in the JavaScript space for doing functional programming in JavaScript. But I don’t think the general public, the general people that on a daily basis go into – write a render function and do ‘this.’ or like ‘product.map’ and then return an array of components. I don’t think those people necessarily think about or get the context within which they use this tool.

CHARLES: Right. And I think that’s actually kind of one of the reasons I think a library like Funcadelic is so important and fills kind of a missing piece in the ecosystem, is because it really is predicated on the idea that programmers use these concepts all the time. They really are, they’re foundational. But we only kind of see them out of the corner of our eye, in our peripheral vision, as being like a formal concept, like mapping. And giving a name to that. You know what I mean? Like you do the mapping, but you’re not thinking about: how do I generalize over it? And I think that that for me, certainly in my journey with functional programming, I thought that it was mostly about functions. Not to say that it isn’t, but that was kind of the end of the story. It’s like, keep your functions pure so that the outputs are only dependent on the inputs. And away you go. And understand closures and higher-order functions, functions that return functions or take functions, and that’s it. But I really feel that that’s only half the story.

TARAS: Part of it I think is that for people, even if you look at the kind of content that’s available around functional programming, it tends to be – trying to kind of [reach] people into this idea of thinking of map, filter, reduce, kind of operations. And I think that’s a place where everybody starts. But I think what happens is that you really are missing – and I think for most people. And it wasn’t for me, it wasn’t until you wrote the readme for Funcadelic and then I read it – up until that point I didn’t really, I was also the same. I didn’t know how these things were related to each other. Because there’s this history and wealth of conceptual depth that connects all these things together. And these things are well-understood by people who don’t – they’re probably not writing JavaScript on a daily basis. They might be like Haskell programmers or Lisp programmers or ClojureScript or something like it. In other worlds, not JavaScript world. So there is all this understanding about how functional programming works but I don’t think it’s really leaked to the general masses of the JavaScript community.

CHARLES: Yeah.

TARAS: You know? And it wasn’t until I started reading the readme – I’m like, “There’s so many answered questions that I didn’t even know these questions were asked.” You know?

CHARLES: Yeah, yeah. Yeah, no. And I think you’re absolutely right. It isn’t accessible to the general JavaScript community. And part of that is because one person’s – like when you read about these things, when I would go read about these kind of higher-order concepts, of basically classifying functions, not just of saying, “Yeah, what is the essence of a map operation? What’s the essence of an apply operation?” you know, “What’s the essence of concatenation?” things like that, I go read the documentation in Haskell or in Clojure. And first of all, it’s hard to distinguish when you’re not programming in those day-to-day, am I reading reference documentation or explanatory documentation? But even in the explanatory documentation, they’re using what seems like incredibly self-referential and abstract examples. And I don’t think that’s necessarily a knock against those communities.

I think what it is, is what’s concrete to one person is abstract to another. And it’s like, if you’re working with those things, you’re working with those sets of analogies, and then you’re working with those abstractions every day, then they’re concrete to you. In a sense that once it clicks in your mind and your mind kind of accepts it and rationalizes over it, then it moves from being, “Yes, it’s an abstraction. But it’s a concrete abstraction,” in the sense that you can have a conversation with somebody and use that abstraction as an example, as a counterpoint, and a method triangulate and reveal other abstractions. But if you’re talking to somebody for whom those abstractions haven’t clicked yet, then it’s just, it’s opaque. And it’s not helpful. And so, I think that one of the things that I realized is like we are using these abstractions, we just don’t have names for them. And so, I wanted to give them names and put them in the hands. And the names are weird, but they are really useful. And so yeah, maybe we could talk about some of those right now. Because I think that maybe now’s a good time to actually introduce some of those abstractions.

So for example, if you don’t know what a functor is, it’s worthless to talk about a monad, in my opinion. So, that was critical piece of information for me. Because that is like missing in every monad tutorial you ever read. At least, I must have read a thousand monad tutorials. And they kind of glossed over functor or didn't mention it. Whatever. Maybe they did but I wasn’t looking. And that needs to be put front and center, that there is a natural sequence to these things. It’s like, some of these abstractions are built on other abstractions and you have to – you can’t skip to monad. You have to start with functor. Again, I realize that’s probably gibberish gobbledy-goop to a lot of people. So really, this is what Funcadelic is about, what this conversation is about, is just saying – talking through it in real-world examples to make those abstractions concrete, so it doesn’t feel strange anymore.

TARAS: Yeah. It’s definitely giving names to things. I think it’s really helpful. One thing I really like about Funcadelic is that you’re not giving names that you made up. These are names that existed for 50 years. They’re historic. And so, when you talk to somebody who is familiar with functional programming and if you say ‘functor’, all of a sudden, I feel much smarter. And we’re actually referencing the same thing, because we are – because alternatively, you can say something like, “Something that is mappable,” right? Like a functor is essentially describing something that you can map over.

CHARLES: Right. That’s all it is.

TARAS: Right. But you know, having a name for it, it allows you to just describe it exactly as it is.

CHARLES: So yeah, there are tons of things that you can map over, right? Most of the time, we think about arrays as something that we can map over.

TARAS: One thing I found really interesting in starting to use Funcadelic is that when you start thinking about things as they are like abilities – like you know with an array you can map over an array. It’s something we’ve all been doing for a while – but then something that you end up doing a lot of. When you get familiar with an array, being able to use object map, mapping an object, becomes something you want to do at some point. Most of the time, what happens is that you’re like, “Oh, I don’t actually – well, I have to write this thing. How do I write this thing?” and then by the time you do this, you’re like, “I’m just going to go to Lodash and I’ll just get the map thing that will map an object.” At the end of the day, it doesn’t quite necessarily feel right because a lot of these libraries – like, Lodash has map but it feels like there is always some kind of a compromise with how these things are implemented. It’s not consistent.

CHARLES: Right.

TARAS: And I don’t remember exactly what the problem with Lodash map was. I know for a fact there are, like there’s different ways that you can map things. There are different functions available for mapping different things in Lodash.

CHARLES: There’s ‘map to’ and ‘map in’ and blah, blah, blah, blah, blah.

TARAS: Yeah. All those different variations. But I think it’s been really interesting. We’ve been using Funcadelic on a project we’ve been working on, on microstates. And just being able to use one function map that is going to map an array or is going to map an object and it’s going to do it the same, use the same function, and it’s going to do the same thing.

CHARLES: Yeah. You have one function that maps over the values. And that’s the thing, is you realize you can map over arrays. You can map over objects. You can map over observables. You can map over promises. You can map over trees. You can map – there’s literally thousands of things that you can map over. And realizing that all of these fragmented interfaces can be coalesced into a single interface. And so, it really is, I think the biggest thing is like the power of polymorphism for a function. Because that’s basically the problem that I think – it’s not I want to say basically the problem. I think it is a problem that a lot of the functional programming libraries suffer from, is that the only polymorphism is object polymorphism, which is kind of the native polymorphism in JavaScript. Whereas in systems like Haskell and like Clojure, you can have a function be polymorphic. And so, one function can operate on many different kinds of data, provided it has an interface. So, when we’re working in microstates, we use literally one function: map. The same, the actual same function, reference to the same function we use everywhere when we map. And we’re just mapping a bunch of different things.

So, I think that that’s one of the reasons that I prefer Rambda, for example, over Lodash, is because it has a form of polymorphism. Most of the things like maps and lenses and applicatives and stuff, almost everything works on both objects and arrays. That’s actually kind of nice. So, Rambda has a basic polymorphism. But I think one of the other things that is really empowering about Funcadelic is that it allows you to make the map function work on any data structure that you happen to come up with. Anything that you want. You can make it mappable and map will work on it.

TARAS: Yeah. I think for people, it’s probably quite abstract, what that actually looks like. I think one thing that’s interesting is that – so for listeners, the way that would look is you have a class, you have an ES6 class, which gives name to a certain piece of data that you have in your application. And then what you can do with Funcadelic, you can then say, “This is how you would implement – if you were to map this kind of an object, if you had an instance of this object, if you wanted to map that object, you can specify: what is the function you would use?” So, even though you would use the same – you would import map from Funcadelic and you would use that map to map whatever that object is and whatever type it is, but there’s a way for you to say, “For instances of this type, I would like to use this specific implementation of a map to map that object,” but use one function to do it. So, it’s going to use one function that you call. But you can specify, under the hood it can specify how the actual, what is actually used to map that instance.

CHARLES: Right. And then that’s nice, because then you can – anything that uses a mappable object, there’s a couple of reasons that that’s nice. Any time you can have some sort of higher-order mechanism that just requires that something be mappable, that it be a functor. And then it’s really nice because then you can have higher-order operations that they just need something that’s mappable. But you don’t have to use that one shot of actually having a map function as a property of the object. You can actually, you can kind of define wrapper classes or whatever, that then introduce a unique way that this object can be mapped. So, you can have the same structure and map it three different ways. Whereas you’re kind of constrained by that using normal OO inheritance because you have to have a map property on your object.

TARAS: Yeah. There’s something else actually, when you start thinking about this. For me personally, I think the first step when we start working with objects, having mappable objects, it was the first thing that was really helpful. But then I think really quickly, right after that, I think my second thing that I started using and I think is probably my favorite feature now, is append. I think it’s actually – yeah, so append is an implementation of a semigroup but I think it’s simpler. A simplest metaphor would be something like object assign. So, object assign is an implementation of a semigroup, except that object assign mutates the object that you pass into it. Right?

CHARLES: Right.

TARAS: It doesn’t create a new object for you.

CHARLES: Right. So again, getting to this idea that there are some universal operations. Like there’s this idea that you can take two things – I don’t want to say object because that’s an actual concrete type in JavaScript – two things and you can smoosh them together. And I think there was actually – wasn’t there literally a big controversy about this?

TARAS: Yes.

CHARLES: About like, array smoosh? I think this is nice – smooshing, right? But you can smoosh things together. And with addition, I can smoosh two integers together or two numbers together and get a third number, right? Or with objects, I can take two objects and smoosh them together by merging their keys. Or I can take two strings and I can smoosh them together and I can end up with a string that’s concatenated. Or I can take two arrays and smoosh them together and I’ve got now an array that’s been concatenated. So, what’s interesting is these are all very, very different types that I’ve just described. And yet, there is some fundamental operation about them.

And I think this is actually something that’s bad about JavaScript is there’s five different names for all those operations that we talked about, but it’s really one unifying concept. And that might seem like a small thing, but when you have five different interfaces for one fundamental construct, that leads to fragmentation and you can’t treat that data uniformly. And it ends up like, paper cuts, paper cuts everywhere. Whereas if you can unify all of these into a small, one thing, which is like we can append two objects, and then we’re going to have an implementation of append for array. And behind the scenes it’s going to call smoosh. And we’ve got a universal – we’ve got an implementation of append for object, which is going to assign the keys in an immutable way and return a new object. Or we’re going to have an implementation of append for string which is going to concatenate the strings.

You might even, I don’t know a hardcore FP nerd would have to probably correct me because this is just totally conjecture, although I know it’s probably a solved problem – is maybe you could say we append two functions together. And that returns a function which is composed, right? That might be a way that you could say – what would it look like? Is function a semigroup? Can we append two functions together? And maybe you end up with like a pipe or a function composition or something like that. But I think that highlights, when you have these universal interfaces, because literally I feel like most of the stuff that we have been working with, there’s literally five, there’s like five interfaces. And everything is one of these five interfaces.

And it kind of flips you on your head, because the classic programming wisdom that I have certainly have espoused for at least the last 10 years is that you don’t want to race to find abstractions. That’s dangerous. Because you can get locked into the wrong abstraction, right? Wait. Let the abstraction emerge. And I’m a lot less bullish on that concept now that I’ve discovered these things, because that wisdom is cultivated in a world where there are [billions] of abstractions, if you’re giving unique names to everything and the combinations between them. But if you are coming up in a world where there’s five basic abstractions, then it actually pays off to ask the question, “Is this thing a functor? Is it a semigroup? Is it a monad? What would that look like?” It’s a nice thought experiment that doesn’t require that much investment.

You can think about it for a couple of minutes. And usually, you can come up and say, “Yes, yes. It totally is,” and I can start using it. And now I’ve introduced this really powerful abstraction. Or you say like, “No, no it’s not.” And then that information is just as valuable. And so, it’s very low-cost to experiment with abstractions. And so, I kind of think of it as – I know I’m on a little bit of a rant here but this has kind of been a major revelation for me – is that when you have very few abstractions which you compose in myriad ways versus having a whole bunch of abstractions that can’t be composed very much, the cost for experimenting with abstraction and making the wrong abstraction is several orders of magnitude lower. And so, you don’t have to be as cautious. And you can actually use trying on abstractions as a tool, rather than a very, very high risky undertaking.

And just to kind of close that thought out, I think that – I don’t know if anybody else but me remembers the world before we decided we were going to make all of our web services RESTful – like when people first started building all these web services, we were just going crazy with the endpoints. And there was no rhyme or reason. Kind of weird arbitrary levels of nesting. Sometimes, you’d throw in an ID as a query param, sometimes you’d throw it in as part of the path. And then I definitely remember, it was probably around, I don’t know, 2010 for me where I listened to a podcast where James Edward Gray was talking about S3 and ‘Was it a RESTful interface?’ and the O’Reilly book. And it really clicked for me. And realizing that if you constrain yourself to thinking about your API at least as these fundamental operation of manipulating resources, and you were constrained to four verbs and everything, you want to have ID-based URLs and resources and as flat as possible, those constraints actually are very enabling for consumers of your API and for actually authoring an API. And I think it’s the same principle at work here. Anyway, so I’ll end that rant. [Laughs]

TARAS: Yeah. I think it’s, I think people could probably, for those who haven’t been in programming as long as Charles has been, it’s probably easier – Charles I think people could probably relate to what’s happening with components now, I’d imagine. Because having components essentially look the same across every framework, they all have props and they all render, return some DOM, or some variation of that. But it’s kind of the same thing. You take some data and then you return something that is going to become DOM. And I think having that as a rule for what a component is, you can then make really complicated applications using these fundamental building blocks. And then you don’t have to – there’s not really much thinking on, “Well, how am I? What interface is this component going to have?” Okay, well you know it’s going to accept props. And you know it’s going to render some DOM when you actually render it, right?

CHARLES: Right.

TARAS: That simplicity I think is really helpful. And I think it’s one of the things that – I think one of the things about Funcadelic that I really like is there’s kind of a really small set of rules that are really helpful. And these rules are actually, they make it predictable. Because one thing that I find really challenging with using Lodash or using Rambda is that because there are so many functions, it’s difficult to know what is actually going to happen when I do something. So, a good example would be like if you use omit from Lodash, Lodash omit will then, it will actually – one thing you can do is you can materialize your getters. So, if you have getters in your objects, those getters can become values on the new object that’s created. So, that’s one thing that could happen. Or if you use omit, your symbol, if you have values…

CHARLES: What does omit do, by the way? I’m actually…

TARAS: Omit is a pretty popular way to exclude functions. Basically like a filter equivalent for an object. It’s usually used to remove some props that are coming into a component. But it can do some – it can actually change the type of the object. One thing you know for sure is if you use something like omit or if you use assign, if you have an instance of something, guaranteed, working with that object in a mutable way is going to cause some really strange things. I think with omit, if you were to have an instance, it would definitely not give you an instance of the same type, like an object of the same type. It will give you just a regular [inaudible]. And there is no real way – you could create an instance. I don’t know what assign would do. I’m guessing that it would just take an instance and would put things on it.

But it’s really not – I think this kind of ambiguity doesn’t work very well when you’re trying to build something, when you really just need to know exactly how your tool behaves. I think that’s one thing that with Funcadelic, because it’s such a small API and because you know for a fact that the library is designed to be immutable and it’s designed to preserve type information, then you know that if you use one of the operations, you will get most likely the same kind of object. And you’re not – well, you will the same kind of object and it’s not going to mutate that object. And so, there are some of these guarantees that are actually really helpful and [inaudible] is liberating, I think.

CHARLES: Right.

TARAS: Especially when you’re trying to do more challenging things, not trivial, just copy some properties from one object to another. But when you’re actually doing more sophisticated things, in those use cases, having these kind of rules is extremely powerful.

CHARLES: Yeah. And I’ve definitely resisted and I think will continue to resist expanding the API surface area that much. Because it is, I think there’s only five or six functions in there. But what you get for those functions is extremely powerful and extremely predictable. I think it might help to give a concrete example. Like when you were talking about object assignment.

Like if you have a car class in your application and you want to do an immutable object assign, well the kind of stereotypical way to do that or the typical way to do that is you assign. You create an empty object and then you assign one car to it and then you assign the next car to it. And now you’ve merged these two car things, right? But then the problem is, you’re going to get an object out of that, not a car. It’s just going to be a vanilla object. Now, it’s going to have all the properties of both, but it’s not going to be a car. And that could be a problem if you’ve got any custom methods on the prototype, any computed properties on the prototype. It’s going to be a problem. Whereas Funcadelic, you can append two cars together and you’re going to know that it’s going to have both of the properties. You’re going to know that it’s going to be of type car. And you don’t have to worry about running the constructor or anything like that. It’s just going to have – the properties are going to be carried over properly.

If you’re using a library like Lodash or Rambda or something that doesn't account for type, because in order to append two things or map something, the implementation actually lives with the type, not with the function. The function is polymorphic, but the implementation lives with the type. You can then actually, you can always return the proper type. Because it’s ultimately – like if your map operation or your filter operation or your what have you operation doesn’t take type into account, then there’s no way to actually preserve type. But because we delegate in Funcadelic, it’s core to the concept. And so, it’s actually a very trivial thing to do, which is why you get that repeatability.

TARAS: One of my favorite things about append and semigroup implementation for object is that you can overload getters on an existing instance. So, what you get is you get a new instance with the getter that you passed to append applied to that instance. And this is kind of trippy but it’s actually really powerful because – so, let’s say you have an instance of an object and that instance has some getters on it. And those getters use some properties of this object to compute their value. And so, when you want – if I need to create a copy of that object in such a way that the getters still continue to work properly but I need to override how one specific getter works for one specific instance, one specific scenario, one specific use case in my code, then I can just use append. So, the first argument is the original instance, second argument is an object that has the getters that I want that I want to overload the getters on the original object. And then append will squish those things together, smoosh those things together, and give me a new instance that has the getters that I passed in, in the second argument. And all the same things that the first object had. And that object will work. This new object will be a fully-functional object just like the original object that I still have a copy of, that I can use.

But this is really interesting because one thing that I’m finding with having these kind of tools in my toolset is that I’ve had features that I needed to implement on a project. And the people that I work with are really technical. So, they know where problems are going to be. And so, the would write requirements for how something – for a feature that needs to be implemented. And knowing the problems, they’re like, “Oh, by the way. You’re going to have a problem in this area when implementing this kind of specific functionality.” And for me, I’m like, having this toolset, I’m like, “I don’t see it as a problem at all.” It’s so easy for me. Because I know that if I need to implement – so if I have something that has expected behavior, but I need to create something that behaves very similarly but slightly different in one particular use case, I can always just copy that object and then overload its behavior. And it’s still going to be a fully-functional object. And I think that alone is just not something that you can do usually. It’s not something that’s available.

CHARLES: Yeah. It’s a technique that I think was discovered. Maybe it’s not original to us. But it’s just, the tools enabled it in the sense that it’s like having a flashlight in a dark room. It’s like, that technique was always there. It’s just when it becomes so concise that it’s so easy to just append one more computed property to a thing, then you just wouldn’t have thought to do it otherwise.

TARAS: What’s interesting about this too, for me, is that – and this goes back to the context conversation that we had earlier – is that I think React brought into our lives functional programming kind of, in a big way. Because part of programming React applications is working with functional components and working with functional concepts. And a lot of the things, like Redux, a lot of these things are powered by functional programming. And they work together. They compose well together because they’re all from the same paradigm. But the problem is that there are all these concepts developed together over time. And they’ve been tested together and they’ve been formulated together in languages like Haskell. But the ideas that make all of these stuff work really well together, they haven’t really become available in the JavaScript community. And it feels like, it’s like we’re all using a language that we don’t fully understand. And it’s like we’re all – a lot of people in the JavaScript world who works, when it comes to functional programming, it’s kind of like having English as a second language. It’s like, you can use the words but you don’t understand the humor. And it’s kind of like, you can’t make a joke. It’s kind of like that. You can’t really express yourself correctly when you don’t have full grasp of the language. And I feel like how we use functional programming in JavaScript is a little bit like that.

And by starting to bring these ideas, moving the wealth of knowledge from the source into the realm where we actually need to use it now, we can actually start to take advantage – leverage all these insights that actually enables all of this. It’s not like – so, the idea of how to write React and think in a reactive way or think in a functional way, those things are not just owned by the React core team or they’re not owned by an elite group of developers who really understand how functional programming works. It’s just available to everyone. And all you need to do is just learn some of these concepts that glue all these ideas together that are fundamental pieces of how functional programming works.

CHARLES: Right. That’s a great point. And it points back to kind of the original reason that I wrote Funcadelic and then started and then continued to work on it with you, is that it really was – it was actually meant as a – it started out as an educational exercise. What would these things look like if they were translated into JavaScript? And it turned out that it rapidly became core to my workflow and way of thinking. And so, it really is, there are weird names to these universal concepts. It is true. It is a foreign language. I really like that analogy. But foreign languages sound weird, and when people are talking in a foreign language, you can feel excluded. And the really, the reason that we wrote Funcadelic and the reason it’s there is to make them accessible, these things accessible to you. So that those abstract foreign words can over time turn into concrete concepts that you’re completely comfortable with, just like any word in any language. At some point, you approached it having no idea what that sound represented.

And so, it really is trying to – the emphasis there is not to noodle about and dwell on the names of the concepts but to take the real things that you are actually doing, give them names and formalize them, to enable you to participate in this new functional world that you’re describing. Because I love that sentiment. It does not belong to the React core team. It doesn’t belong to an elite set of developers on this project or that project. It literally is a universal tool that is 100% achievable. And people don’t even realize how close – if they’ve been working with JavaScript for a couple of years, how close they actually are.

TARAS: Yeah. I think they’re really – for most people, if they were to read the readme and then – well, I think one of the problems, it kind of works with the language metaphor, is that you need an immersion, right? I think one of the reasons why Funcadelic really stuck and functors and semigroups and [filterable] and all of these things really stuck for me, and I’m thinking about how using monads and monadic operations or applicatives and all that stuff – the reason why it all stuck for me is because I’ve been able to talk to you about it. And I think for people, finding a network that will allow them to practice immersively, to think about functional programming, not just occasionally – I mean, you could do it occasionally as well, it just takes much longer. But once you really, once you have a few conversations where you try to dissect a problem in a functional way and you think about what these pieces are made of, it becomes very natural, very quickly.

CHARLES: Yeah. I think that’s actually a really great point. And the thing is, you can immerse yourself incrementally. So you can just say, “You know what? I’m just going to start using append.” Anywhere that I would concat two strings or I concat two arrays or I would do object assign – screw that. You can even just say, “Instead of using object.assign, I’m going to use append,” and start there. Or to say, “I’m just going to start with mapping.” I think also the thing that’s nice about it too, is the buy-in can be incremental. But you’re right. You do need immersion. You do need practice. You need to actually use, you need to use the functions and you need to be able to use them one at a time, so that your mind can close over them. So then, you can kind of move onto the next one.

TARAS: Yeah.

CHARLES: So, that might be one way, is to say – because you know, I don’t think I really understood. I was already using append and map ubiquitously before I really understand applicative/apply. So, you don’t have to grok it all at once. You can definitely bite it in chunks. And the best way to do that is to start with one concept and really just attack it mercilessly. And then also understand that there’s a natural sequence there.

TARAS: I would add a little bit of a caveat to that. I think there’s a thing about using – doing something for learning purposes and there’s another thing about shipping things. What’s interesting with Funcadelic and what’s interesting about a lot of these ideas from functional programming is that I think they give you benefits that you might have not previously thought. Like for example, if you’re going to concat two strings together, doing it with append is probably the most robust way of doing it, relative to just being able to use [inaudible].

CHARLES: Yeah, that’s true. You wouldn’t want to use a string [inaudible], wouldn't you?

TARAS: Yeah. But there are areas when using – there are times when things are just not possible otherwise. Like for example, if you wanted to treat an instance of a class in an immutable way, this is simply not possible in any way. So, if you’re going to say, “I’m going to work with a bunch of these instances of ES6. And I want to keep them as instances, because they have certain behaviors that I want to have. I want to have a getter, or I want to have a method on it. And I want to keep these things fully full instances, not broken, not be turned into objects. I want them to be normal instances but I want to work with them immutably. When I need to make a change, I want to get a new object and not modify that object.” So, if you set yourself that goal and you say, “This is what I’m going to do,” then you really are not left with very many options. You only really have, you have to use append from Funcadelic. And because alternatively, you’re going to implement something yourself. You might as well just use append. And [I think] that’s a good place.

I think if you’re starting to, if you need to make something lazy, if you need to delay an execution of something – so, instead of pushing that execution, instead of using object assign and then computing everything ahead of time, you can use append. And you can create a getter and you can delay the computation of that value until the point when the user actually reaches for that value. If you want to start doing that kind of stuff, you really are not left with very many options. And append is the way to do it. But that’s the thing, is when you start to set these kinds of standards for yourself, you level up in a way that is very significant. I think it’s like a natural progression of learning. You start off learning and anything goes, as long as you can make this website work, it’s like, “I’m happy.” And then over time you get better and better at it. And then when you get good at building applications, your next step might be like, “What if I was stricter about it? What if I could actually – what would that open up for me? What would that allow me to do?” I personally think about it that way.

CHARLES: Yeah. I think that’s a good way to think about it. You mentioned having a network for discussing these concepts and trying to internalize them. Let me first and foremost offer myself as somebody. If this is a hill that you are interested in climbing, and I think it is a very worthwhile hill to climb because of the perspective that you will gain from its summit, please reach out to me. You can contact me at cowboyd on Twitter or cowboyd@frontside.io. I’d be happy to discuss these kinds of things, because I think that these tools are just incredibly powerful and will improve you. So, if folks want to get in touch with you, Taras, where would that be?

TARAS: I’m tarasm@gmail.com and tarasm on Twitter.

CHARLES: Alright. Well, thank you everybody for listening. And as always, if you want to get in contact with us at Frontside, you can just email us at contact@frontside.io or give us a shout on Twitter at @TheFrontside. Thanks everybody. We’ll see you all next time for episode 100.

Apr 12 2018 · 43mins
Episode artwork

Episode 23: Taras Mankovski of This Dot uses his business brain to talk mentoring, making a company

Play
Read more

Taras Mankovski (https://www.linkedin.com/in/tarasm/), @EmberSherpa on Twitter and CTO of https://www.thisdot.co/ stops by the People Stack to talk about Mentorship as a Service, creating a Company for helping people, and how to provide meaningful assistance to backend developers making rich web applications.

Special Guest: Taras Mankovski.

Apr 02 2017 · 43mins
Episode artwork

042: Apprenticeship in Real Life with Taras Mankovski and Lennex Zinyando

Play
Read more

In this episode we cover how to handle apprenticeship, share with listeners how they can start participating in mentoring and apprenticeship in their companies and communities, and help people to understand the impact apprenticeship and mentoring can have on everybody involved.

Links:

open-source-ember-apps: A list of open source Ember apps

Transcript:

CHARLES: Hello everybody and welcome to the Frontside Podcast, Episode 42. I am Charles Lowell and with me is Brandon Hays, as well as some other really, really, really, really special guests, which I'm really excited to have on the show today.

BRANDON: Really?

CHARLES: Yeah.

BRANDON: Just really?

CHARLES: Really, really.

[Laughter]

CHARLES: I was thinking of 'really, truly' but no, I wanted to go back to 'really'. I don't know, Brandon, are you pretty stoked about the show today?

BRANDON: I am. I'm really excited today. We've actually wanted to do this for a long time and we finally were able to line it up once we've figured out that we can record a podcast more than once every six weeks. So yeah, we're really --

CHARLES: Really.

BRANDON: -- Really excited to have Taras Mankovski and Lennex Zinyando with us. We'll have you each introduce yourselves. But basically, the point of this podcast is we want to talk to you and you're doing some really cool stuff with apprenticeship through us, and Lennex is one of your earlier apprentices. From everything I've seen tremendously successful, Lennex, you're an awesome developer. So we wanted to talk to you, find out how you're doing that stuff but we'd love to have each of you introduce yourselves and talk a little bit about your background. So we'll start with you, Taras.

TARAS: I'm really excited to be here. I also feel like I need to point out the fact that this is podcast number 42. Right? That's the meaning of life and everything.

BRANDON: We would be very quite remiss to miss that. Thank you so much. We were so really excited that we forgot about this was the purpose of everything.

CHARLES: That's right. We're sitting on the main nerve right now. This is it people. This is it. It's everything.

TARAS: I'm really hoping that if you ask me questions, I'm going to answer them faster than this famous answer. I'm really glad to be here. I want to give a little bit of my story because I feel like a lot of things that I've doing over the last 10 years have been adding up to what I'm doing now. I have a pretty diverse background. Programming wasn't something I wanted to do because when I was 12, my dad gave me a Java book and he said, learn how to program and I'm like, "This is terrible."

[Laughter]

TARAS: That was a really rough introduction for me. Even though, I think I was always technically inclined and I did like [inaudible] for a long time. I did a lot of different things. Since I was a little kid, I always want to be a businessman before I think I even knew what that was. So my focus has always been on the business of things, and technology happened to be one of the only ways that I knew how to access that in a way that was actionable based on something that I could do.

I've tried a lot of different things. One of the things that I did before was a company called Positive Sum, where we spent about four and a half years trying to figure out how do you build relationships where everybody who works with you wins. When that Positive Sum company and the being as 'zero sum' for me, I end up leaving and starting from scratch.

I have another company called WRKTG, Inc which is like the mothership for EmberSherpa and that acronym refers to 'working together'. Everything that I've kind of have been doing has come from the perspective of how do we bring people to work together, and how do I make it possible for people to have a win-win-win scenarios. I think that's kind of what brings us to where we are today, with this conversation about apprenticeship.

BRANDON: Cool, thanks for that. Then Lennex, how did you get into software and what was your background? I don't know if you come from a computer science background or you were doing something else.

LENNEX: I'm Lennex Zinyando. I'm based in Harare, Zimbabwe. I've always wanted to work with computers since an early age. But then, access to computers was really hard to come by so I used to spend a lot of money going to internet cafes so that I could access the internet.

After a few years of [inaudible], I went to work with a bank for a few years and I decided to leave because I really, really wanted to become a programmer developing software. I joined a local company that does mobile marketing as a technical support person.

I worked with them for a few years and I met Taras on Twitter, sometime beginning of last year. Then, I paired with him so that he could mentor me. So now, I'm an apprentice at EmberSherpa.

BRANDON: You said you met him on Twitter and you said, "Hey, I'd like to be your apprentice," but how did that interaction actually occur? Was there like a tweet that went out and said, "Hey, I'm looking for apprentices," or you just kind of saw that he was knowledgeable and you said, "Hey, can you help me?" How did that interaction first happen?

LENNEX: Actually, I saw a conversation between him and another guy where the guy was - actually they're discussing how they could – I think they wanted to pair on it or something. Then, I just asked if I could join the process, be part of the team that was going to pair on it. Then Taras created this link for us and that's how it was started.

CHARLES: So you just said, "Hey, can I join that pairing session?" And the rest is history at this point?

LENNEX: Yeah, something like that.

CHARLES: Now, you're a world famous software developer so it seems it works.

[Laughter]

BRANDON: Well, that's really cool. I'd like to ask you, Taras. Was that sort of intentional on your part? You said your arc was bending toward community and 'greater than zero sum' type work. As you were bending that arc toward that, did you have the idea of- I mean, your name was EmberSherpa on Twitter so clearly, you had some sort of training or guidance aspect to what you're doing. Was apprenticeship part of that model by then? Or is that something you kind of stumbled on?

TARAS: I always imagine what things might look like. I imagine that there might be a scenario- I tried to do this with WordPress before which is create a scenario where I'm helping people learn and in the process they cultivate a community of people that follow what I do through helping them become like an engineer.

It didn't work very well with WordPress but it seems to have worked with Ember. It's very much an [inaudible] process. I kind of went through a bunch of hardships trying to figure out a structure that is actually sustainable. That's the really hard part, I think, about creating like win-win scenarios is that you need to be sustainable and finding a way to make sustainable. That was really tricky.

CHARLES: Yes, that's something that we're discovering as well, right? You identify these values and you say, "Hey, these are the things that I value," and then you discover how expensive they are in the process of trying to implement them and trying to do that in a way that you can keep going that doesn't basically require everything from you all the time. That's really hard.

So it was something that clearly, like you cared about, you were trying to do it in WordPress. You said you ran into a lot of painful lessons there. I'd actually be curious and dig into a couple of those things that you are finding were not sustainable.

TARAS: It's ironic actually, I found mentoring to not be very sustainable. From a business perspective, I think mentoring is a really great service but because it relies so much on people like myself who have to be like people that get to certain levels through their hard work, you end up wanting to get paid well for the work that you do. Then in that scenario, it becomes very difficult. Like offering mentoring services is very valuable but it's also a very premium service. So to be able to sustain myself and be able to offer a service, the businesses you want to pay for, and in a way that is going to benefit the company is going to benefit the apprentice and benefit me, those were difficult.

But it seems to be shifting towards apprenticeship turns out to be the answer, for me at least. It was like one of things that was right under my nose but it took a really long time for me to see that actually apprenticeship is the answer to creating this scenario. It’s really funny how something might be right in front of you but you might not see it for a year and a half.

BRANDON: What's different about apprenticeship from mentorship, basically?

TARAS: Mentoring for me is supporting a company that has a team of developers. Basically, the company is paying me to mentor their developers. It seems like a very fine distinction but the difference with apprenticeship is that the focus is on the individual and all the other things are kind of secondary.
When I stop thinking about myself as a mentor or stop talking about mentoring and I start talking about apprenticeship, it becomes about creating structures for others to be successful like making that shift on creating opportunities for others to grow. It's one of those things where you shift your focus towards something else and it makes your path forward easier. That's kind of what I found with apprenticeship.
Even though I was doing it for a while, like I started working with Lennex a year and a half before I made the shift, I really found focusing on the apprentice and making apprentice successful actually help me make my business more sustainable.

BRANDON: So basically, by defining the problem scope as, "Hey, this is about an apprentice and not about how good a mentor I am," you basically discovered -- I think all businesses go through this at some point too, like anybody with a purpose ends up discovering that the thing that doesn't scale is your time, and the only way out of that is to develop a process that's focused on achieving an outcome. So apprenticeship is the definition of the process by which somebody gets better and focusing on them rather than non-scalable Taras' time.

TARAS: Exactly.

BRANDON: Lennex, you basically came on as an apprentice about a year ago. Can you describe the process, from your perspective of like what that apprenticeship has entailed and maybe even how that evolved over time?

LENNEX: Initially, we worked on small apps. When I was trying to get the basics of Ember and to be honest, I didn't know a lot of JavaScript. So that process was kind of painful for me. It took a bit of time for Taras and myself to admit that and then I tried to focus a bit on knowing my JavaScript properly.
But then after that, things have been going on smoothly. I would pair a lot if I would get a task to do with work on open source projects, and we've done [inaudible], actually contributing [inaudible], learning the whole thing, the whole process.

BRANDON: So basically, you have commits on open source projects now out there in the world?

LENNEX: Yes, I do.

BRANDON: And how long have you've been developing software before you were basically doing that?

LENNEX: Not that long. It was just a few HTML sites, a bit of PHP, then Ember is like the first programming thing that I've done.

CHARLES: I think that's really interesting. Like part of the process, you seem to be describing as you kind of got thrown into the deep end of the pool. Like this is a new language for you, we're going to be doing open source projects that people actually use, and you were actually contributing working code into a real life. You know, thousands of people are using the code that you actually wrote in very early stages of your development career, which I think is a really interesting model.

Taras, would you say that that is part of the model or is that just sort of a coincidence of how this went down? Like is that part of the design of the apprenticeship model?

TARAS: It's certainly by design. I think there's something really beautiful about Ember, and it's the fact that it creates a possibility of an ecosystem of open source applications that solve the script problems and that is enabled by the fact that we have this collection of conventions. When I chose Ember as a technology to focus on, I kind of made a guess that this might happen. Then when I realized that Lennex needed to learn by doing real practical things, I went out looking for this applications and started off as being, first it was a HospitalRun, and I was kind of really uncertain whether the HospitalRun would even take it seriously because we're saying, "I'm going to help this person work on your application for free. Will you talk to us and tell us what we need to be able to make this happen and make it so that you can actually mark this code?"

But it's proven that this seems to be something that maintainers of open source applications are willing to do, and now we have something like... Oh, I don't know what it is, but plenty applications. I have a list of open source Ember applications that we're adding to on a regular basis, and they're all opportunities for our future apprentices to contribute and improve their skills. Actually, they have something that they can show and say, "Look, I did this."

BRANDON: So I'll grab that and put that in the show notes. That seems like something that just producing that list was important to your apprenticeship but actually, everything that you do when you do work on the public like this adds value elsewhere as well. Like that's a really cool and useful list for people to have of things that people can actually contribute to.

TARAS: Yeah, and I hope that there are other applications that we don't know about that are going to get added to this list because if we can have more apprentices helping more open source applications, I think that's something that's really great for Ember. It’s a win-win for everybody.

CHARLES: So I'm curious, you've got this big list, 20, 25 open source applications that's actually a big list and I assume there's a lot of people. You talked about how making the shift towards apprenticeship allowed you to scale but I actually am curious about that process because like how does it scale? There is only one of you so how do you manage more than one apprentice -- two, three? How many is reasonable? How do you bump that number up and get more people coming along?

TARAS: I think what's happening now is that my apprentices actually have their own apprentices. I think that's the key to scaling this because at a certain point what happens is, as I mentioned earlier, at one point, I paired with a hundred people and I realized that people have very common problems and depending on what stage they're in in they're learning, they all tend to have very similar problems. The way to scale [inaudible] a lot of people, I think, is to have the apprentice that just learned or apprentices that has a six months of Ember experience, they can support somebody who just started last week or started two months ago.

They’re actually really good persons to support that person. If I support somebody who just started Ember, it creates a situation where like I want to be able to help but I've answered this question so many times already that it becomes repetitive. It's actually takes away from the energy of me trying to explain this to the person. So having an apprentice support a new person is great for the apprentice because they get to grow. It’s great for the person because they get really personal attention.

BRANDON: I want to make a note. I feel like I should have noted this earlier. Part of the reason that we wanted to talk to you two about this is we've taken several swings at apprenticeship at Frontside, and we're in a sort of unique position in that. We don't see a lot of companies doing this very actively. I saw a company called Obtiva that had an apprenticeship model that I admired a lot. Then they got acquired by Groupon and everything that was good about that company died.

I haven't seen this done a ton and our attempts have been kind of shots in the dark on this. It’s been very challenging. Your approach to this seems to be working in a way that I have not seen happen elsewhere. What I'm hoping part of drawing out this conversation is the process of discovering what is working for you and what other people can adopt? Basically define how this is actually like it seems like a pretty successful case and how people might adopt that in their businesses, in their workplaces, and in even in their capacity. I love the concept of moving away from mentorship as a concept and toward apprenticeship where this becomes more of a defined process.

I'm sure to you it felt like you're kind of fumbling around as well. But you seem to be landing on a lot of things that really seems to be working. Are you noticing any patterns in terms of somebody you get them working on real world applications, they tend to support each other, what other tools, I guess, or patterns are you using to help that process kind of stick with people and scale because this seems to last longer than just a couple months too, which is important?

TARAS: I think one thing that I talk to our clients who - because we actually do sell apprenticeship. Part of the process of the apprentice evolving from someone who has never maybe done programming before or who is very new to Ember to actually being a good productive member of the team, is actually starting off doing something that is very low stress, doing something like open source contributions. Then, being in a situation where they're able to make a difference but there isn't a lot of pressure on them.

So one of the ways that I set that up is I tell our clients that this person is an apprentice. The reason why you would want to hire this person is because first of all, if they have a problem, they can ask me. But also, this person, like a lot of things that we do on Ember are very repetitive. Their patterns that once you've taught, you can use that pattern over and over again. I think, at a certain point, if you implemented a few tables, implementing a fourth or a fifth table isn't that different than the first three, and you don't get that much more effective at it because you're still limited by how quickly you can type.
So if an apprentice knows how to implement a table, then an apprentice is just as qualified to implement that table in Ember as I am, for example, especially if they have access to the immediate feedback that they need when they get stuck.

What I've been doing is first, I've been very, very honest with people that I work with saying like, "This is what's going to happen. This is going to be the person working on your project, and this person is going to do be doing this work." Also kind of talking about the reality of Ember work which there are a lot of things that are really difficult that very smart and experienced Ember developers can solve, but there's a lot of work that we do in large Ember applications, that there's lots of paved paths for that, there’s lots of just like assembly kind of the ground work and I think that's a really great opportunity for people who are learning Ember to get the repetition, the kind of muscle memory of understanding how to solve problems.

I think the repetition of doing like 'data down, actions up', repetition of doing like working with computer properties, and repetition of writing tests. All these are things that apprentices need to do to become very good at writing Ember applications.

BRANDON: That's actually my experience as well. I come from a nontraditional background and I knew that I got a sense for when I was trying to learn a new thing that it was a certain number of projects before I felt like somebody could give me something and I felt comfortable saying, "Hey, I can probably do that." It wasn't my first project and it wasn't like a hundred so have you kind of discovered a number in there of projects that somebody might have worked on when you talk about that repetition. Is there a number of times of repetition that you find people become comfortable with something?

LENNEX: On number of projects, for being comfortable in Ember?

BRANDON: Yeah, at what point do you start feeling comfortable and a little more confident that somebody could hand you something that you haven't seen before, and say, "Hey, I could probably tackle that." Is there a certain number of projects that you've handle before you felt like you could just jump in on that?

LENNEX: Let's say for testing for example, writing an acceptance test. I wrote the initial test for HospitalRun. The next project that I did, I was really comfortable with acceptance testing. That was just one of those thing that I could do. I think just doing it once or twice is enough for you to feel comfortable doing something. I don't know about the other stuff, but then what I've done so far, that has been okay.

CHARLES: That's interesting. What I'm hearing is you weren’t doing like the whole slice of the application. You were focusing on, "Okay, the acceptance test. That is the thing that I'm going to take on. That’s the thing that I'm going to own. I'm actually just not going to worry about everything that lies underneath it, or how to implement the acceptance test but I'm going to learn acceptance testing in an Ember application. Then once I've got that skill, now it's in my pocket and I can take it to the next problem."

BRANDON: Lennex, at what point do you start feeling these things start to click together, where you have the tests over here and you have maybe understanding the router over there and you have maybe understanding components over here? Each of these things takes time, it's difficult, and it's a new concept. At what point do you start feeling that you have a full picture of how an application works and that you could kind of attack it from different angles?

LENNEX: In my experience for HospitalRun, I did the tests and I did a lot of [inaudible] from Ember 1.X to 2.X. So I got to touch a little bit of everything. The next project in [inaudible], I implemented a feature. That feature has required me to use all the previous knowledge that I gained from HospitalRun to do something that actually [inaudible] and [inaudible] properly.

In my next project, I'm now building an [inaudible] from the ground up using previous knowledge from all the other projects. So you're always building on top of what you got before.

BRANDON: That actually sounds like an interesting pattern. Again, I don't know if this is sort of something you discovered or happens over time or even if I'm reading it right. But it sounds like you're really mixing up these tasks where some of them are kind of a deep dive on one small piece like, "Hey, I want you to write acceptance tests around this and you're familiar with acceptance testing." And then you have a thin slice of something like an Ember upgrade that touches all aspects of the code base but in a thinner area, as well as a ground up building of something, sounds like maybe later. Is that sort of mix of types of work intentional? Or is that just sort of something that, "Hey, if the work is there and if it seems like somebody can do then I'll grab it"?

TARAS: I think some of things are very intentional like the last project that

LENNEX is working on, I intentionally said that, "You now have enough experience doing all of them. You’ve been dealing with other people's problems for a while now. So I think it's time for you to make your own problems so you can actually understand that process a little bit better."

But other things that are actually just very practical things like the reason why starting with testing. Why we start with testing is because without tests in place, I don't have guarantees that the things that Lennex is doing are not breaking functionality. Then what that means is if I don't have that guarantee, that means that the chances of me being pulled into something randomly is very high and then that's the kind of risk that I can't take.

Actually what happens now is almost every conversation with new clients starts off with, "I know you guys want to do features but before we can do that, we need to build your acceptance tests suite." And so this is actually a very practical thing. I think part of apprenticeship program for us is actually teaching the things. It's a very practical thing. It's like we need to have tests to be able to do this work.

BRANDON: Yeah, I mean it's one of those things. There is some debate in the community around like, "Well, how soon do you introduce that to somebody? Is it something that is an advanced concept?" I was not introduced to testing until much later in my development career. Basically, my first introduction to testing was somebody handed me the 'can't back' book called Test Driven Development which is all written in Java before I had learned to program, and I was like, "I don't get it." So that was my last attempt at testing for about two and a half years.

It wasn't part of my process but when I did discover it, seemed like it did make everything easier. The fact that you're able to do that up front, I imagine probably saves a lot of time and frustration for people so they have something to like back up to during the course of their learning process. There's always like a place where they knew this thing was working.

TARAS: I think there's another pattern that is underneath this which is very important to give people what they need to build to move forward. So with Lennex, when he started working on HospitalRun, I spent almost half a week, maybe almost a week setting up because they never had tests so we had to make it possible for him to write test, so we need to actually read the first acceptance test. What that means is that you need to go in and find all the problems with the app that prevent you from writing acceptance test and actually fix those problems.

If I just said to Lennex, "You know, write an acceptance test for this," without giving him any paved path to do that, I think the chance of him succeeding would be very low.

BRANDON: So yeah, you basically have to pre-shave all the yaks around getting the first one going. And from that point forward, they're likely to be able to carry the ball further.

TARAS: Right.

BRANDON: I have a question for you, Lennex, in that sort of vein is how do you know when you're stuck on something that is like well outside of your capabilities versus when you're supposed to stick with something because you know there's something you're supposed to learn? Is that a skill that you've had to develop or is that something that... I don't know, like I'm not sure how to deal with that with our apprenticeship, and I'm wondering how you've dealt with that?

LENNEX: One thing that Taras has taught me is if I'm facing a challenge, I should work on it. Taras will say, "We're going for a day. If you fail, then come to me." It helps me to not give up easily. If it's beyond me, then after that day Taras is going to help me. By then, usually, I end up getting through that and finding a solution.

BRANDON: Interesting. I have worried that a day was too long of a feedback loop to let somebody bang their head. But it sounds like you've landed on a day as being kind of the approximate amount of time somebody could spend and try to solve something themselves. Taras, is that basically a fair, like wind up being a good place to land?

LENNEX: Well, for me and Taras, it will depend on different - a day usually means when you accept. So there isn’t that much [inaudible].

CHARLES: But it makes sense when I think about it. I actually wasn't thinking about it in terms of that being an appropriate size feedback loop. But when you think about what you're actually doing when you're programming, a day is actually a very reasonable amount of time to struggle with a problem. So before you say, "Oh, man. I just need to find someone to pair with this on. I've done my Googling or whatever but I need to try and like roll back and look at for some prior [inaudible] on this or try and find connect with somebody who's sharing a similar problem." I think that actually makes a lot of sense, right? That's something that we all encounter in our daily lives.

LENNEX: Yeah.

TARAS: We know from people with experience how long sometimes it takes for us to understand something.

CHARLES: Sometimes years.

TARAS: Yeah, and I think it's really tricky. It’s hard because learning takes time. That’s one of the things that I'm a little... I'm not sure exactly how this is going to work but I know if clients are paying me to mentor their team, I'm going to be available to them within half an hour to an hour to answer that question because if the client can't afford to wait a day for them to get that answer. But for a person who is learning as their primary deliverable, I think a day is reasonable amount of time for a person to try to like even sleep on it.

CHARLES: Right. It's true. It’s a tough line. I think, Brandon, one time you said something that always stuck with me. You said that learning only happens when you bang your head against the wall so that your brain is soft enough to accept the answer. And you don't achieve learning without the banging your head against the wall first.

BRANDON: Yeah, Brandon Hays, the king of violent metaphors.

[Laughter]

BRANDON: There is actually an important aspect to this that I don't want to drop onto the floor and that is the idea that part of this process is that you have people that have access to one another. That's part of how you are scaling it, that you're also kind of helping. It seems like you're helping build a small community of apprentices to help each other.

So Lennex, my question is this, how often do you wind up using that network of people versus you feel like you'll just handle it on your own? How much do you want to have accessing that?

LENNEX: I access it a lot. I usually get stuck, and then I know someone working on projects which is similar to what I'm doing. So again, I just easily ping him and then a few minutes or a few hours later, we're pairing on it.

BRANDON: That seems like a way where you're able to do that without reaching out too much to Taras. It feels like you're asking for help and figuring it out. But it means that you don't have to roll up to the most experienced person for every single question, that you kind of started to build a network of people that stitching together your own mentorship in effect, I guess.

LENNEX: Yeah, that's true. It's easier to understand the concept when someone is on your level or slightly above you when they explain it to you. Maybe for me, it's easier to understand.

BRANDON: Actually, that jives with a lot of our experience. I can't remember what book this is from. I'm pretty sure it's stolen from another book but I read it from the book 'Pragmatic Programmer' where they talk about the zone of proximal development, where it's easier to learn from people who have just a bit more experience than you because they haven't completely forgotten how they learned the thing that you're trying to learn.

After a while, expertise means that you actually internalize that to the point where you can no longer remember not knowing it. That can be really tough. I think that's actually something that a lot of mentor should probably know and recognize and understand. People that want to take apprenticeship on need to understand that you probably have lost a lot of the empathy. I know I have and it really bums me out because it doesn't feel like that long ago that I was a brand new developer. But I'll sit with somebody who's brand new and I forgot how I learned the thing that I'm sitting there trying to teach somebody, and you start getting that little burning sensation in the back of your head like, "How can you not know this?" You know that at one point you did not know this, but you don't remember not knowing it. It’s a very strange sensation to have gone through all of that and then lose that empathy. So I feel like that's must be a really important concept.

Another question I have for you Lennex is how much of your time do you wind up spending helping other people do that kind of stuff as well? Do you wind up doing participating as a mentorship stuff at this point?

LENNEX: Yes, I do. Actually now, they are about three people that have reached out to me on Twitter, wanting my help. I've paired with them when they have their own projects. They're asking me questions. One guy that I helped with Ember stuff in our local community, and maybe because of the apprenticeship that I'm doing with Taras, they think I'm an expert in Ember. But I'm actually helping other people a lot.

BRANDON: I think that's really phenomenal. That sounds like success to me.

CHARLES: Yeah, I'm actually curious. Having been through this process and experienced success at it, were there any times where you kind of felt you wanted to throw up your hands and be like, "This is not working." What were those moments of frustration or mistakes that... Not mistakes, but were there any moment’s frustration? What actually did you take to course correct on that? If not, that's fine too.

BRANDON: Yeah, if not, I'll just know you're lying.

[Laughter]

TARAS: There were definitely challenges. Lennex and I both went through some difficult learning and questioned whether we're be able to do this. I don't want to speak for Lennex but there are certain things that you have to learn to be able to work with people, and they're not programming things. I think that's because obstacles that Lennex and I had have been related to communication and being reliable for each other, I think that's the part that's been hardest. But the reality, I think, is that this is what programming is, talking to people most of the time and building a network of people. So I think we need to, as a mentor to an apprentice, I need to help my apprentice understand this, and help them understand what makes me successful in my work with our clients, for example.

BRANDON: You brought up one thing and I'm curious to get Lennex's perspective on this, which is being reliable for each other. I know it has been probably the single greatest challenge to our apprenticeship platform at Frontside, where we've brought apprentices on and the criticism that we had about our apprenticeship program is if I had 24/7 access to the mentorship that I needed, this process could have been done in three to four months. And instead, it's going to take seven or eight months.
So it takes literally twice as long if they have to fight and scrap for every minute of mentorship that they get. I'm wondering, Lennex, if you've experienced something like that and how you've addressed it, if so?

LENNEX: Maybe the thing with me is I really wanted to be part of the apprenticeship program. So I had to work really, really hard to make this work. But given that for me, this apprenticeship program has been 100% remote. There's no one standing over my shoulder or someone chasing me, asking me what I've done or whatever. I had to discipline myself so that if I get tasks that I should do, I should do then on time. Even if Taras is not available, he's not there chasing up to me whether I've done that.

The other thing is I wasn't good at communicating early on. I would shy away from telling him when things are too complicated for me. I'll try to solve everything on my own until I discovered that some things you just can't learn on your own. You have to ask for help. Since then, things have been a bit better.

BRANDON: That sounds like something almost universal to me. Every time we've attempted apprenticeship of any kind, maybe it's because we tend to select the people that we come into contact that say, "Hey, I like to do apprenticeship," tend to be people that are kind of self-starters. But they always tend to try to solve everything on their own. It becomes this coaching exercise of having to have that person communicate back to you.

Is there a sort of a platform for that? Or is that just a style that you've developed where you're willing to reach out more frequently? Or do you have check-in points or something like that during the apprenticeship that are like standard?

TARAS: We don't have anything specific. Something that I use in projects is like if you're actively working on something, if you work in a project and that's your deliverable, like half an hour or so much time you get to play around with it, and then let me know. But the emphasis is on the person building the responsibility of the deliverable and knowing what's necessary for them to build to move forward. So I'm seeing that now from Lennex which I didn't see before in the beginning but I see it now.
Now, if he's stuck, he's willing to say like, "Oh, okay. I don't know what's going on here. This doesn't make sense to me." And I think that's really important. I'm not sure exactly how to cultivate that but for whatever reason, it's worked with Lennex. But I think we need to help people learn that that they have to take responsibility for their work.

BRANDON: It seems to me that that's the process of learning to own their own thing, learning to kind of develop their own paths. Again, that's one of those things that winds up being a better apprenticeship pattern for the person and also is a thing that lends itself to making this thing scalable where you can benefit more people and have them help themselves in each other, rather than having to be the nexus point for all questions and all accountability systems and everything. So it seems to be working really well for you.

I have one more question that I want to ask from both to Taras and Lennex. What you would say to people who are intimidated about taking on a role in mentorship knowing that, "Hey, that actually does sound harder taking on a role and trying to cultivate and participate in apprenticeship." What you would recommend to that person that is interested in it but maybe intimidated by it?

Then Linux, the same question for you but from the position of somebody that's trying to break in and kind of scared and nervous that it seems difficult or scary or opaque. So can we start with you, Taras? What would you say to somebody that is like 'hey, this sounds fun and cool and everything but it sounds too hard'?

TARAS: To be a mentor or to have an apprentice?

BRANDON: Take on the idea or participate in apprenticeship in some way. Is there some way that you know that people could get involved that would not necessarily be super intimidating?

TARAS: I'm curious what the person's intention is because if you want to help people and that's the emphasis, then you have things that are uncomfortable. Especially good things in a lot of times, they're uncomfortable until you get really good at them. If you feel uncomfortable, chances are you're not growing right now.

For a lot of people that are very good technically, helping others, understand these things is the next step for them to evolve in their personal growth. If they really want to get better, having apprentice is a very confronting and a very challenging thing but it creates real opportunities to see that you're actually getting better and you're improving as a person and as a technical leader.

BRANDON: Then, as far as [inaudible] said, "I don't see the opportunity for myself." My guess is there are people everywhere that could use help. Do you have any suggestions on where they can find people to help, ways that they can get involved? Do you have a place where - are you looking for additional people to jump in and get involved on the mentorship side or suggestions for ways that people might get involved?

TARAS: I would love to help people who want to build apprenticeship systems in their companies. I would love to help those people if they're able to do that. Otherwise, I think that creating more systems in Ember community around apprenticeship, I think would be really helpful like making more systematic because right now, it's something that I do but I'd love for it to be something to the Ember community does.

Then because from that, if we engage in that conversation, then we can create spaces where it will be easy for people to do this kind of things and find apprentices and find mentors. I'd love for this to be an Ember community thing.

CHARLES: Well, it seems like this would be as good a place to start as any. So, here we are.

BRANDON: Maybe after this call, we'll figure something out and put something together and tell people to look for that. If they want to participate in mentorship and they consider themselves Ember or Ember adjacent, I'd like to see something in the next little while that lets people participate in a more systematic fashion. That sounds like an opportunity, for sure. If there are people that want to participate in that, sounds like you're the person to reach out to.

Then Lennex, for your sake, for people that kind of want to break into technology and are really intimidated by it, obviously you're in a remote part of the world and your access has been somewhat limited. Sounds like you even fight for internet access in your life, as well, which is a foreign concept to a lot of people. So what would you tell to those people that are intimidated by doing this, scared that they're going to waste somebody's time, scared that they'll fail at it?

LENNEX: I think if someone really, really wants to learn, they should find a mentor or a good apprenticeship because learning from someone who's experienced, someone who has your best interest at heart, someone who's willing to put in the effort to teach yourself, you can beat that. If you find that that someone was willing to do that, then put in the effort and go through that program because usually, apprenticeship is tailored towards a specific individual helping the apprentice. Where else will you get that?

BRANDON: And there's not a ton of access to that in the world so it sounds like that's a big problem. That's what they are fixing in the tech industry. So having you on to come here and talk about it, lend some expertise to it, and start putting some ideas, process and pushing that conversation forward, it matters a lot certainly to me personally. But also to what the point of what we're trying to do at the Frontside.

If people want to get in touch with you all, how would they do that, Taras? How people get in touch with you?

TARAS: I'm @EmberSherpa on Twitter, and Taras@EmberSherpa.com via email. I always try my best to talk to people as much as possible and be available to people as much possible. If anybody reaches out to me, I'd love to talk to them.

CHARLES: Yeah, you definitely been accessible to us which is why we're talking today and I really appreciate that. I mean, you've been genuinely super helpful. We haven't really gotten into it in this podcast but we've worked with you quite a bit and are working to improve our apprenticeship program with your help. I can't tell you how much we appreciate it.

Then, for you Lennex, how do people get in touch with you?

LENNEX: I am @zinyando on Twitter, and lennex@EmberSherpa.com.

BRANDON: Awesome. Well, thank you both very much. This was super enlightening. It's frustrating because I feel like we just barely scratched the surface. But I feel like there's some work that we need to do to put together some process around this. Maybe there's some blog posts or some further discussion around this to put this together. I would love to talk with you all again when we have something cool to share with people.

But what you're doing already is so awesome. I'd like for more people to know about it because I literally have never seen it done as successfully, as consistently as I've seen the EmberSherpa apprenticeship set up work.

Thanks very much for both of you all for putting that into the community and for sharing with us.

TARAS: It means so much to hear you, Brandon, say this because I respect both of you very much. I think you guys have a really great reputation in our community, and it means the world to me to hear you guys say that. Thank you so much for having us here.

Sep 22 2016 · 39mins
Episode artwork

S01E02 Part 1 - Angular vs Ember vs React at Netflix with Ben Lesh & Taras Mankovski

Play
Read more
Ben Lesh reveals all to Taras Mankovski (@embersherpa) and talks about frameworks at Netflix. Hear what he has to say about Angular vs Ember vs React at Netflix .Find more podcasts, videos, and online conferences at http://modern-web.org or follow us on Twitter @modernweb_.
Feb 14 2016 · 39mins