ilya_gelman.md

layout	title	date	author
post	A Leanpub Podcast Interview with Ilya Gelman, Co-Author of The Complete Redux Book: Everything you need to build real projects with Redux	2017-05-18 11:00:00 -0700	len

Ilya Gelman is co-author of the Leanpub book The Complete Redux Book: Everything you need to build real projects with Redux. In this interview, Leanpub co-founder Len Epp talks with Ilya about his career, his interests, his book, and at the end they talk a little bit about writing and self-publishing.

This interview was recorded on April 11, 2017.

The full audio for the interview is here. You can subscribe to this podcast in iTunes or add the following podcast URL directly: http://leanpub.com/podcast.xml.

This interview has been edited for conciseness and clarity.

Ilya Gelman

Len: Hi, I'm Len Epp from Leanpub, and in this Leanpub podcast, I'll be interviewing Ilya Gelman. Ilya is the head of the New York office of 500Tech, a leading Israeli consultancy with expertise in Angular and React. He is active speaking at and organizing conferences and meetups around the world, including the ReactNext conference.

Along with his colleague Boris Dinkevich Ilya is co-author of the Leanpub book The Complete Redux Book: Everything you need to build real projects with Redux. As they say in the description of their book, "It will teach you everything you need to use Redux to build complex and production ready web applications." In this interview, we're going to talk about Ilya's professional interests, his book, and at the end we'll talk about his experience using Leanpub to self-publish. So thank you, Ilya, for being on the Leanpub podcast.

Ilya: Thank you for having me, Len.

Len: I always like to start these interviews by asking people for their origin story, and I was wondering if you could tell us a little bit about how you first became interested in software development, and how you made your way to the New York office for 500Tech?

Ilya: So my story might be a bit different from other people's stories, because initially I didn't want to become a programmer.

My story begins at school, when I had to select one of the subjects that I would learn through my highest grades. This is how it works in Israel. So I chose computer science, and I was really interested in it, and I loved to play with computers. I worked as an assistant for our network administrator at school, and this is one of the subjects where I did best. I think I got [my] highest grades in that subject.

But when it came time to go to the army, I received a proposal to go to the programming forces - people that just go and, for three years, for four years, they just write code in the army. And I said, "Well, I don't want to be a programmer." At that time, I wanted to be a designer. And after a few years I realized what a huge mistake I made. So it was three years in the army, and I always liked to design things and to build new tools, new products.

And I can't say that I'm a gifted designer. But sometimes I wanted to get something done, and I had to find programmers. And it was really hard to do, because good programmers are really hard to find - especially programmers that will do things for free. And I decided, "Well, that's a good time to learn some programming." So I decided to learn Ruby on Rails on my own, to be able to build my own ideas, to bring them to life. And while I was in the army, I learned Ruby on Rails, and built a couple projects.

Then, when it was time to get discharged from the army, I had to decide what I was going to do with my life. By that time I was already married, so I needed to find a job. And I had a decision between going to art school and getting a degree in arts, or getting some fast course on programming, and finding a job as a programmer. I felt confident that I would succeed in that, so I tried to find courses that would teach me some Ruby on Rails - that's the thing that I was familiar with at that time.

And I found a company called 500Tech, which organized a Ruby course, and they also promised to help with finding a job after the course. So I contacted them and I said, "I'm going to get discharged from IDF, I'm looking for a job, and I want to take your course." I was invited for an interview to see what my level is. And Adam, one of the partners, interviewed me and he said, "You know what? You don't need the course. Would you like you to join us and work with us?"

I was pretty amazed by that. Because people like me, where they have no understanding of how industry works, or what's the level of people in the industry - it's really hard to understand and to estimate your skills. So I was pretty amazed.

After a few days, they gave me some assignments. I did them, and they invited me to join 500Tech as a JavaScript programmer. They just said that, "You don't need the Ruby course, but we like your Ruby code; you are going to write JavaScript." That's how it all started.

Len: That's a really interesting story. I've got a couple of questions related to that. But first - when you mentioned joining the IDF, and doing your service for three years, you reminded me of something I encountered years ago in Greece, actually. I met a lot of young Israelis who were just about to start their military service, and I was told it was conventional for someone to go on a holiday before those years start. Is that something that I just stumbled across, and is not that normal? Or is that something that is actually quite normal?

Ilya: This is actually a pretty popular thing in Israel. Because many people, when they get discharged, they receive some amount of money from the government. And some people decide to go for a couple of months to a couple of years of travelling all around the world - just to see the world, before they start their like adult life, before they go to university, or before they get a job.

Len: Okay, that's interesting. I was talking about before you start your service - that these were kids who were sent on holiday by their parents, to have some fun before going.

Ilya: Oh really?

Len: But I've actually met at least one person who did exactly what you just described quite a few years ago in Canada. That's really interesting. I didn't know that that was common, to take some time afterwards to travel and do things.

Ilya: Yes, I haven't heard about people going to holiday before the army. But after, it's really common. I think like every other person just goes to travel around the world, just to see how it looks like, how it feels to be outside of Israel.

Len: And so, you taught yourself how to code, as a sort of side project during those years.

Ilya: Yeah, that's correct. I found there was plenty of free material about Ruby on Rails, and I was always excited how easy it is to just educate yourself in programming on the internet.

Len: I wanted to ask you about that. It's one of the topics that often comes up on this podcast, because so many of the people that I interview are developers. I find about half formally studied computer science, and half didn't. But that's not necessarily a good indicator of what they currently think the best path is for someone who might be thinking about starting out. And I was wondering what your advice would be - say, for someone who is smart and 18, and maybe doesn't have a few years of military service ahead of them, but can decide what career path to go down at that moment. Do you feel that you missed out, because you didn't do a computer science degree at a university?

Ilya: On the contrary, I feel actually that not spending a lot of time doing the degree actually helped me concentrate on building an actual skill set for the job I am doing currently. But I know a lot of people who did a science degree, and it kind of depends on what kind of company you want to work for. Because some larger companies - you're going to have a really bad time getting to an interview without a computer science degree. Because some companies just filter out all the people that don't have it.

But a lot of really talented programmers I've met, a lot of them don't have any science degree. I think it's a matter of luck on how to get good mentors, and get into a good company that will teach you and educate you on how to be a good programmer - despite your not having a computer science degree. It could help, but you have to remember that it takes you like three to four years, and that time you might use for building your experience or portfolio, so it's like a trade off.

Len: That's a really interesting perspective. I hear that from quite a few people, just keep in mind that if you want to work for a big company, they might have some formal requirements. But if you want to get into software development, it's not necessary to get a computer science degree. Especially because of all the great materials out there.

I know that actually you got into convening meetups and speaking at conferences, and organizing conferences and things like that. I was wondering - you talk about building your portfolio, that's actually a little part of that - and I was wondering if you could talk about how you got into that? I think it's something some people find a little bit intimidating to do. But from what I could tell online, it appeared to come pretty naturally to you to be involved in that way.

Ilya: I was pretty lucky to work at a company that does so much around the front-end community in Israel, and all around the world. So when I came to the company, they were already having these meetups for Angular. React didn't exist yet back then, but they ran a couple of meetups for Angular, and meetups for startups. It was kind of natural to see all the people coming on stage and giving the talks. Eventually, I started to help organize these things.

And I started by attending meetups, so I didn't just jump right in. And when I was in the beginning of my path, it was really intimidating, to think about - well one day, maybe I could go on stage and present something just as the other people are doing. Because when you are a junior developer, you don't really estimate your skills in the correct way. And then you see all these people coming on stage and speaking about some advanced concepts, and sometimes you don't understand what they speak about, because it's a completely different topic or a completely different domain. And you think, "Well, am I able to do that?"

And that's one of the reasons that my first tech talk wasn't actually technical, it was something more broad. I chose a broad topic to begin with, because I didn't feel really confident to present something really advanced. But when you do it a lot of times, you start to understand the kind of people that speak at meetups. They aren't really different from you. They speak some completely weird things on stage, and they make mistakes, and they're all people. Junior developers can sometimes teach the audience much, much more actually useful things than senior developers that maybe write less code, or are managing teams, instead of actually being hands-on in the projects.

Len: That's a really interesting observation. Speaking of useful things, I saw an interesting distinction that you made in a presentation called The Productive Developer, where you talk about how being productive does not necessarily equal being good. I was wondering if you could talk a little bit about that idea?

Ilya: I think that was my first presentation, that wasn't technical. I think what I meant by this point is - my whole talk was about getting productive as a developer. So all developers, we're speaking about the performance of their tools - how this framework is fast compared to another framework. How this software runs faster, how do we write faster algorithms? But no one actually talks about self-productivity, and how you as developer produce results faster. And you don't spend much time on using the tools, you spend time on actually creating stuff.

And so my whole talk was about - how do you get more productive? How do you produce more content in the same period of time? So it was the disclaimer that the amount of work, or the amount of lines of code that you produce over an hour, doesn't mean you are going to produce really good lines of code. And it's important to remember that before you start jumping and running and writing some lines of code right away, you have to sometimes stop a bit and think before you write your code.

So you might be really productive in using all the shortcuts, and being able to produce a lot of code. For example, you could implement a feature in a week instead of a month. But this feature that you implemented in a week, might be really hard to extend and maintain and rewrite or refactor a few months from today. Being "productive" doesn't mean being a good developer. So that's a good distinction to make.

Len: That is really good. It reminded me of someone I was talking with recently who tries to use a practice of deleting code - like deleting everything that they've done after they've solved the problem. Because once you've solved the problem, you know better than you did when you started writing that batch of code, where you need to end up. And it can sometimes be better to actually throw out all your work and start over, when you know where you're going to get to, rather than be stuck with all your mistakes, and false paths that you had before you knew the destination.

In another presentation, you talk about the banana/gorilla problem. This is a concept from the programming world that not everybody might be familiar with, and it's a colorful one. I was wondering if you could talk a little bit about that?

Ilya: Sure. I think that was one of the first presentations, as well, when I spoke about composition versus inheritance. So there's two patterns that people that learn computer science, that they are familiar with, usually. And also people working with object-orientated languages - they usually know inheritance pattern very well. And people working with functional styling programming, they know the composition very well. And sometimes those people don't know both concepts.

So I was explaining about - composition is when you have, for example, say a class. And it could be composed from some other classes. So for example, you could borrow some methods from different modules, and then compose one object or one entity. Versus inheritance, when your classes have to be children, or parents, of other classes- I've heard them called superclasses or subclasses.

So specifically the banana/gorilla problem is when one class that you import - it has so many methods inherited from a lot of superclasses that you didn't intend to import. Like for example, you could create a vehicle, right? It's really simple. But you want to make a specific type of vehicle, like for example, out of a car, you want to create a Mercedes. And this Mercedes can drive, it can honk, it can brake.

And also you can create an airship - let's say an airborne vehicle, and you have a plane. So this plane can take off, it can land, it can fly, it could have a jet engine. But what if you want to create a combined version of these two? What if you can create a Mercedes that can also fly? How do you do it? You can't really inherit from two classes - in some languages you could, but and what if these flying Mercedes should implement only the subset of the methods of these two superclasses? How do you do that?

So sometimes you don't have enough time to recreate a taxonomy, or refactor all of your structure of the model. And what you end up with is a flying Mercedes - that despite [the fact that] you didn't want it to have a jet engine, you have it just because it inherited it from the airborne vehicle. So that's kind of a problem when you only want a banana - but what you actually get is a gorilla holding a banana, and the whole jungle comes with it.

Len: I love that image.

Your book is about something called Redux, and I was wondering if you could talk about what that is, and why it merited a book being written about it?

Ilya: Oh, Redux is - if we speak about it in plain words, it's a predictable JavaScript state container. Right? But when you put it that way, a lot of people don't really understand. What does it mean, predictable? What is a state container?

So in a few words, Redux is basically three things. It means that you have a global state of your application, when you put all your data and all of your UI state - how it looks, how it works. And this global state can only be changed by instructions that you put from outside. In Redux, those instructions are called "actions", for instance.

So you say, "Okay, I have a button - and now when I click, this button should turn red." So this state now changes. And this way of organizing your state in one object, and telling how to change the state by instructions - this is basically what Redux is. And by predictable, it means that every time you send an instruction to this Redux store, you create a new store. So it can save the old one in history, and you can traverse back and forth, and see how the state changed.

And because you write in the declarative way - so instead of writing store.change() something, you just describe how store should change in response to an instruction. So to these actions, this means that you can always understand and realize how your store, or how your state would look after every single action. It is what makes it predictable. And this small library, it's - I think it's a couple hundred lines of code looking over it. I can go over it in a half an hour. And the simplicity I think is the most powerful concept about this library. And this is why it's so popular. It's so small, but it solves a really, really hard problem in creating complex UIs.

Len: I believe it came about accidentally.

Ilya: The funny story about Redux is that it's creators - Dan Abramov and Andrew Clark, really awesome guys - didn't intend to create a replacement for this Flux button that was presented initially by Facebook. They just wanted to present a new idea at React Conf, and he kind of just proposed the idea and then he sat and figured out, "well how am I doing this?"

So his proposal was time travelling in React applications. And by that time, no one did time traveling. So he kind of sat down and thought how this might work. And eventually this became - after a few iterations of course, this became a very popular library that everyone uses. Or every other person uses in his React projects.

And this is - just to mention what we talked about previously, about a lot of people being intimidated to speak at meetups or conferences - now, I've done this for some time. And I can tell a small secret to all those people that are being intimidated, and want to speak but don't really know how to approach this. A lot of people that send proposals to conferences and to meetups, they have no idea how they are going to present something that they are proposing to speak about.

So, an example of Dan, he just sent an idea, and then just figured out how to do it. I do it sometimes as well. So sometimes I propose an idea that interests me. But I don't really completely understand. And then if it get accepted, I just spend some time on learning it and building things around it and just trying to understand it and find a way to explain it in the best way I can.

Len: Thanks very much for that tip and that explanation. That's really good.

I was wondering - I wanted to ask what brought you and your colleague, Boris, who I believe is the CEO of 500Tech, and founder. What brought you to decide to write a book, which is a pretty big undertaking?

Ilya: There are a few reasons. The first and obvious reason - well I can speak for myself - first of all, we all like to share knowledge. So we had a lot of experience with sharing knowledge with other people - like free workshops, and we organised meetups. And we write blog posts, and we help people on the internet. And writing a book is just one of the ways to help all of our clients, and all the other people which come to us with the same questions - like, how to do you implement server communication? How do you implement testing? How do you structure your application?

So this is one of the ways to just answer all of the questions at once. Just give them the book, and say, "Read it," and they'll get the answer.

And there is also a reason that writing a book is a good thing to put in your resume. So when you tell people that, "Oh, I also write a book on Redux," they kind of look at you from a different perspective. But really it's not that big of a deal. Anyone can write a book. They just need enough time and investigate a topic very deeply. Yeah, putting it in your resume is one of the reasons.

And also, at the time, there was a lot of free content on the internet on how to use Redux, and how to use Redux with React. And most of these tutorials and guides, they were really basic. They explained some basic stuff, like for example, for server communication, everyone just took the easiest thing to explain, the Redux Thunk library. So just know, you have asynchronous actions.

I'm getting a bit technical here, but there are multiple ways to do server communications with Redux. And one of the ways could be done through asynchronous actions. We need to dispatch an action, which actually goes to server, fetches data and does different things.

And while this is so easy to explain - when you see it in real world applications, when you're using it, you're shooting yourself in the leg. Because testing these asynchronous actions is a lot of pain. Rewriting it, refactoring it, changing the underlying infrastructure of server codes - it's really hard when you have all these multiple asynchronous actions.

So what we came up with - well a lot of other smart people came up with - is actually using the concept of middleware for server communication. And this concept's so hard to explain. For example, if you look at the middleware functions at Redux, and how they look - you can't really understand how you start to explain it, because it's a function that returns a function, that returns a function, that returns another function. And this concept is really hard to grasp, let alone to explain it.

So a lot of tutorials online, they just don't do it. They concentrate on very low level introduction to Redux and how to work with React. So I just thought that writing an actual book from our real world experience... and we've done dozens of projects for clients using Redux, and not using Redux. We started work with React, even before Redux came to exist. So we've seen it all, and we wanted to share it with the world, for some more advanced concepts. Something that you would maybe notice along the way. Like a few months after you started building your application. But then it would be too late to rewrite everything.

Len: For any current authors or budding authors out there: you managed to reach about 13,000 new readers, just in the last couple of weeks I think. And that's something a lot of people would like to be able to do. I was wondering if you could explain if you and Boris did anything special around that promotion? Besides making the book free - the minimum price of the book free, which is always an attractive thing to people. But that is a striking amount of people to reach.

Ilya: First of all, we were surprised by ourselves, because we never expected such an outreach. But the answer is quite simple. We didn't do much to promote it. It's all the power of Twitter and famous people retweeting our tweets. We were lucky enough that Dan Abramov and Andrew - they are really nice people. When we made this book free, it - first of all, it certainly helps to make this book free. And when they just retweeted it, Twitter got crazy, and people started retweeting it, and showing to their friends.

Because now - it feels like a book is really a desired topic. Everyone uses Redux. And there aren't a lot of good quality materials on how to work real world applications for Redux. So it kind of sold itself. People just were willing to retweet it and show it to their friends. Someone posted it on some blog sites. And it kind of just promoted itself.

But maybe it's interesting to mention that - when we made this book free, we actually made more money than selling it for a reasonable amount of money. A lot of people, they see the book as free, and they understand the value and they just pay money, even though they don't have to. Which is really exciting and empowering to understand that there a lot of people that really value your work, and not just downloading it and forgetting about it.

Len: Just for those listening who might not know - when you buy a Leanpub book, there's a minimum price and a suggested price that are set by the author, or authors. And so you can actually set a minimum price of free, and a suggested price of $9.99 or whatever price you want. And it is quite common for authors with books that have a minimum price of free on Leanpub, to actually make quite a bit of money sometimes from those books.

Authors, when they discover this, often feel very empowered by it. But so do readers. They like being presented with a choice, once they figure out what's going on. And they often do choose to pay for an author's work when they don't have to. It's been one of the more exciting things that we've discovered at Leanpub over the years.

Moving onto one of my last questions - I wanted to ask you why you chose Leanpub as the platform for your book?

Ilya: This is an interesting question, because in the beginning we didn't think about self-publishing at all. All that we thought about was going to a well-known publisher, and working with them. Because - we didn't care about money. We cared more about exposure, and people to get to know us - that you wrote this book. And maybe, potentially they could reach out to us asking for help or for getting a project or something else. So we tried to reach out to a few publishers. And very quickly, we realized that this is not the best way to go.

Because all these publishers, they do a tremendous amount of work. Obviously if you don't know - publishing a book, it's not just writing a text and putting out the PDF and printing it, or selling it online. There's a lot of reviews going on. Technical reviews. And you have to show it to different people to see that you didn't make any stupid mistakes. You have to proof read it. I guess you can tell, English is not our like strongest language out of the three.

So I was originally born in Russia, and lived for my whole life in Israel. And that's why I speak English. So we had a lot of grammar mistakes, and phrasing mistakes. And you also have to design a book. You have to somehow market it. So once you wrote the book, how do you actually get it to market? How do you tell people about it? How do you make it popular? A publisher does a lot of these things, but there are some problems.

First of all, when you go with a publisher, you don't really own your book. So you work on a really tight schedule. You receive some amount of money. But once the book is published, you can never decide to make it free for a week. You can't set a price. You can't really get some copies to give to your friends. So you receive a small amount of copies, and then you have to buy your own books.

And the most intimidating part is that, the publisher usually puts a small point in the contract, that you have to update your book on demand when a new version of library comes out. You have to actually see it and write a new chapter, or update the whole book, on their own schedule. And if you don't do it, they might bring a different co-author and stuff like that. So - not owning the book, and like we didn't want to - how do I say it? Forgot the word.

Len: You didn't want to relinquish the right?

Ilya: No, not relinquish rights. We didn't want to tell them that we are going to work whenever they want us to work on it. I'll try to rephrase it. We didn't really want to give away our rights to the book. We wanted to have some freedom - making it free from time to time, or we're doing some workshops. Speaking of conferences, it's really good for us to say like, "Okay, so everyone who attends our workshops gets a free book." And everyone who was in this talk, gets a free book. This freedom was really important to us.

Also, we didn't want to sign for periodical updates, when like every time the library gets updated. And by the time we wrote a book, it took us over a year. And Redux released like 21 or 22 versions of it. And every time, if we had to rewrite the book on the publisher's schedule, we'd just - we couldn't make it.

So we tried to find the different alternatives. And I can't remember how I discovered Leanpub - maybe some friend told me about it? But we would say that - okay, we're going to try - just write it the simplest way, put it on Leanpub, see how it goes. Anytime, it could go with the publisher. So the part that I like most about Leanpub - it just give you complete freedom.

After a book gets promoted, you can take this manuscript and send it to like O'Reilly or any other big publisher, and take it off Leanpub. And they won't get offended. This freedom is really empowering us to just go and do the actual writing, and worry about all the other things later.

The only thing we did is - designing the cover, and hiring a copy editor, Rachel Head, which has like helped us a lot with fixing our grammar, fixing our English.

And Leanpub did all the rest. We uploaded the manuscript and we've got the book that we can sell and print. It was pretty amazing. We are really happy that we went the Leanpub way, and we've not ended up like with a really draconian contract with a publisher.

Len: Thanks for that answer, and for the kind words about Leanpub. We appreciate that, it's always nice to hear that. We built Leanpub for certain kinds of - I mean, it can be used in lots of different ways. But what you're describing is very particularly the kind of need that we wanted to meet.

I'm just curious if corresponding with readers is something that you were planning on doing, or you have been doing? Getting feedback from readers, and then changing the book based on that feedback?

Ilya: We were actually really surprised about how people reacted to our book. People were so kind. They were sending out these reports. They asked, "Okay, how can I help you with the book? I found these chapters that, I just misunderstood them. And I feel that there is a problem with your code." And they say, "This phrasing was not good enough." They were really supportive. They said, "We love your book. And here's a small problem we've found. Can you please fix that?"

And we're really happy to receive this feedback, because we could proofread it for days and for months, but when actual readers are reaching out to you and telling you, "Really love the book, and this is a small little typo I noticed." Or, "Small concept that you could've explained better." It's really good.

Len: And how do people reach out to you? Did you give out an email address in the introduction to the book? Or did they reach out on Twitter?

Ilya: Some of them reached on Twitter, some of them wrote an email. I think some of them used the contact the author feature on Leanpub. It's kind of a bummer that we don't have this one issue tracker, when everyone can just submit their issue in the book, and we can just go over it and prioritize them. Ftting feedback from multiple channels is kind of overwhelming sometimes. So we have to keep our own list of things to fix in the book. But yeah, it was various channels, and people reached out from Twitter, from Leanpub, from email.

Len: It's interesting. I've never quite thought about this before. I mean, we've had people talk about the issue of tracking issues and things like that, things that are reported. At the same time as it would be really useful to provide something that people could just go to on Leanpub, I'd never quite thought about it before, but you also might lose a little bit of the human side of the interaction, which can make authors feel better about what they're doing, and can make readers feel really good. I mean, when they hear back, when they get a message from an author - and especially if they see the change that they suggested incorporated into the book, it just makes them feel good.

My last question is - if there were any feature we could build for you, if you could ask us for anything?

Ilya: Oh yes, so many.

Len: Okay. Pick maybe one or two.

Ilya: Okay so - I think that one of the most challenging things, was to actually co-author the book. Because we tried to find any software or any online application to be able to write Markdown together. And then send it to a copy editor, and maybe to a reviewer. And to leave comments on that. And we haven't found any better way than just using Google Docs.

So what we did, we wrote Google Docs and then sent it to our copy editor, and she fixed some grammar and added some comments and asked them questions. And then we checked it back, and changed stuff and did a couple of more iterations every time. And then we had to convert it to Markdown. And then we just added it to our repository, to Git. And sent it to Leanpub.

And when we had any typos and we wanted to make any changes, it was really hard to do. Because writing Markdown that way is really hard. Once it's in the repository and we want to change it, we have to take all the content back to Google Docs, edit it, send it to our copy editor again. And then do the whole process all over again.

So if you could write an editor, when multiple authors can, kind of Google-Docs style, edit it live, and add some comments and make suggestions, and then get other people to collaborate on it, that would be really great, to automatically export it to Leanpub format - because all this Google Docs, Markdown conversion was really hard for us to do.

Len: Thanks for explaining that situation. Collaborating around writing documents is in itself a tricky thing. There have been entire startups devoted to that. And it's definitely something that we would like to be able to help authors with more, especially the experience you're describing where you're also dealing with a copy editor. It really presents some interesting challenges. But it's definitely something we'd like to find solutions for.

Well, thanks very much Ilya for taking the time to do this. We really appreciate it. And I want to say congratulations again on reaching so many readers with your recent promotion. And thanks for being a Leanpub author.

Ilya: Thank you for having me. Thanks for providing such a great platform for all the authors.

Len: Thanks.