Good afternoon. I have the honor, for which I thank Professor Hoppet to give the last speech today, the topic of riches on some new psychology facts in economics. And indeed, when economics is seen as similar in nature to natural sciences, as it is nowadays, it is likely to be exposed to permanent swings in research trends. That is, to new facts. This must be the case because the methodology of the natural sciences, empiricism, which is largely adopted nowadays in economics, implies a never-ending testing of assumptions in the quest of the valid one, that which will allow to make the better prediction. New facts then appear almost naturally, nourished by the discovery of new testing techniques or by the application of new assumptions. Now, this could well be viewed as the normal way of how science in general, and economics in particular, should make progress, if not for a major problem. This problem is that the very objective study of social sciences, that is human action itself, cannot be subject to any meaningful measurement and testing. Human action consists in preferring one choice to its possible alternatives, all of which are not only purely subjective and in permanent change, but also hidden to external observers. Yet it is precisely from this invisible and non-quantifiable relation between choice and its counterfactual alternatives that individual values, market prices, and most of economic laws are derived. Hence, it is not possible for any new knowledge in economics to come out of this empiricist, positivistic cradle. But then, when this cradle is professed, new facts must be resurrected errors. This is what I would like to show in two particular cases, that one of neuroeconomics and that other one of reciprocity economics. Both research areas have gained momentum and substantial popularity for the last two decades, especially under the leadership of Professor Ernst Fehr. Of Austrian descent, Professor Fehr is director of the Department of Economics at the University of Zurich, again, which is hosting the Laboratory for Experimental and Behavioral Economics, as well as the Laboratory for Social and Neurosystems Research. He has been recipient of the Marcel Bernard Prize in 2008, which is the Swiss equivalent to the Nobel Prize, and he has been suggested as a possible future laureate of the Nobel itself. Even though he has not published a treaty yet, which is something common for mainstream economists, he has produced an impressively long list of articles in the top economics journals. I will first deal with neuroeconomics, which purports to add a new measurement technique to the economics toolbox, and then I will turn to reciprocity economics, which proposes to replace the assumption of self-interested behavior by the hypothesis of social preferences. In the own words of Kevin McCabe, who is a leading expert in neuroeconomics, neuroeconomics is the study of how the embodied brain interacts with external environment to produce economic behavior. Research in this field will allow social scientists to better understand individual decision making and consequently to better predict economic behavior end of point. Neuroeconomic uses a number of brain imaging techniques, in particular PET scans, in order to determine how the brain regions and the neural circuits interact and communicate to determine individual behavior. By showing how the brain operates biologically and physiologically, it aims at improving the economist's assumption of just given preferences. It purports to enlarge standard economic theory by the inclusion of biological variables among the factors that determine individual behavior. Neuroeconomics is expected to be path breaking because a direct measurement of thoughts and the feelings would allow researchers to build a theory that would explain hitherto postulated preferences and beliefs. That way, the microeconomic foundations of economic theory would be made more solid. Professor Fer even believes that if a grand, unifying theory of economics would ever be achieved, it could only be done via research in neurobiology. The purported advantages of neuroeconomics are reminiscent of the early debates about the foundations of marginal utility. While Jevons expressed reservations about the major ability of utility, Edgeworth imagined the development of a hedonimeter that would exactly quantify the amount of happiness, pleasure, and of pain experienced by each individual. He also expressed the view that for utility analysis to become relevant for the real world and not just an abstract thinking, it should find a way to somehow measure utility. This is a view with which Fisher, who has contributed significantly to the development of mathematical economics, did not disagree. He doubted indeed about the possibility to find a direct psychological measure of utility, but yet he believed that utility could be indirectly inferred from the individual's observed choices, and this would be crucial for conducting welfare analysis. Now, the present-day neoclassical economics, even though it has abandoned the attempts to measure utility, still considers utility as an extendable and therefore measurable quantity. It assumes that the number of utils that is a variable quantity of something could be ascribed to any combination of bundles of goods and services. Then the individual's choice is being explained as the one that maximizes this quantity, other things such as prices and revenues being given as constraints. Neoclassical theory could avoid the search for an exact measure of utility because its interest has been elsewhere, namely in the explanation of choices. However, in doing so, it has accepted to be grounded in a psychophysical conception of utility within which it was bound to remain a pure theory of choices. As a matter of fact, by its very research program, namely the explanation of choices, neoclassical economics is akin to a branch of psychology, a kind of mathematical psychology. From this point of view, the integration of neoclassical economics with neurobiology into the new field of neuroeconomics appears internally consistent. Yet the crucial point is that another approach to utility theory and to economics in general is not only possible, but appears to be significantly more fruitful. The Austrian theory of economics has developed a subjective value theory that is fully independent of psychological and mathematical assumptions. Starting from the observation that the acting individual ranks the satisfaction of his subjective needs, it is a straightforward conclusion that the last available unit of a given resource will be used for the satisfaction for the less valued goal. The decreasing marginal utility then is no longer a mere assumption that should be tested indefinitely. It becomes a logically necessary implication of the very concept of human action. And this praxeological economics is not concerned with explaining choices, but with explaining the logically necessary implications of the very fact of human action, of which choices are just the visible part. Praxeological economics thus achieves the separation of economics from both psychology and the natural sciences, and results in the development of a very specific and unique kind of knowledge. Moreover, it relies on logical thinking about a near-refeatable evidence, namely the reality of human action. And because of this, its reasoning to the extent that it avoids any logical error implies the discovery of laws of human action that are applicable without any distinction to time, place, race, or gender. Progress in economics is then achieved when logical errors are corrected or when hitter-to-unforeseen implications of human action are being spelled out. The key point is that praxeological economics, which has developed quite elaborate theories and relevant also for the real world of prices, capital, investment, economic fluctuations, is indifferent to the motives behind individual choices. But what then is the possible positive contribution of neurobiology and neuroeconomics to praxeological economics? Simply none. Neurobiology could neither invalidate nor confirm any of the causal relations established by praxeological economics. Even if it ever managed to define a perfect correspondence between neurobiological processes and individual choices, still it is doubtful that this would improve our capacity to make less uncertain predictions. First, future prices do not depend exclusively on individual choices. But they are also influenced by changes in the very circumstances of action, some of which are completely outside of human control. Second, the human mind is not the last black box to be opened before discovering the deterministic laws that govern the universe, if any. One will still have to discover the laws that determine any single configuration of those factors which govern the neurobiological processes. As it could then be expected, the innovations contributed by neuroeconomics up to date are rather meager. Let me refer to what I found to be the two most relevant discoveries. First, brain scans suggest that monetary gains and losses activate similar reward areas in the brain as the so-called primary reinforces, like food and drugs. This, according to neuroeconomists, implies that, quote, money confers direct utility rather than simply being valued only for what it can buy, end of quote. Well, this conclusion was reached by Ludwig von Mises already in the 1940s. Actually, Mises went much beyond and developed a detailed analysis of the determinants of money and money certificates value in the very different cases of commodity, credit, and fiat monies. The neurobiological discovery that money is independently valued strikes by the absence of any discussion of the implications of this discovery. For the sake of a second example, experimental neurological tests suggest that backward induction may be neutrally unnatural. This would imply that game theory may be using an unrealistic concept for finding out the outcome of strategic interactions. Once again, while this might be troubling for game theory, none of the deductions of praxeological economics depend on the use of backward induction. If anything, individuals' forward-looking expectations are what matters, for instance, for the formation of prices of durable goods or of financial assets. Let me now turn to the second psychological fact, namely reciprocity economics. Reciprocity economics, of which Professor Fer is the originator and the world-renowned promoter, is grounded in the observation that individual behavior is not guided exclusively by selfish material motivations. It replaces the neoclassical assumption of homo-economics, that is of a selfish individual interested exclusively in his own material well-being, by the assumption that individual preferences are social or other regarding. In other words, the individual is concerned also with his material situation relative to other, so-called reference agents. Social preferences may be of different types. They may be a preference for reciprocal fairness, for inequity aversion, for pure altruism, or just envious preferences. In short, social preferences consist in a positive or a negative reciprocity towards others. In reality, both selfish and socially-motivated individuals are assessed to coexist, and part of the research agenda is to determine which type of preferences is prevailing in the social outcome. The primary goal of reciprocity economics is to increase the degree of realism of neoclassical economics by diversifying the types of behavior that are being analyzed. Now, the starting point of this approach is laboratory experiments of interactions between individuals as stylized by game theory. Game theory predicts that in the so-called ultimatum game, where a proposer must offer to a responder a distribution of a given resource, the proposer will always offer a tiny fraction to the responder who will accept the deal because it still makes him better off than getting nothing. A similar reasoning implies that in the public good game where individuals must choose which fraction of their income will contribute to the provision of a public good, no public good would ever be privately provided. When these types of interactions are tested in laboratories, the experimental results suggest systematically actually systematically contradict the game theoretical predictions. For instance, it appears that about half of the ultimatum interactions reject a proposal for redistributing less than 20% of the pie. Reciprocity economics takes these contradictions for a confirmation that individuals are not motivated exclusively by selfish preferences, but they also take care for others too. At the second stage, new game theoretical conclusions are derived mathematically from this new assumption that individuals have reciprocal preferences. And finally, these new predictions are again tested in laboratories in order to validate the theoretical predictions under the new assumption that is of the new model. Hence, reciprocity economics is a branch of experimental behavioral economics. Experimental economists fully accept the positivistic cradle, but maintain that data available from the directly observed reality, the so-called field data, does not allow for a proper testing of assumptions and thereby validation of theories because of the multitude of factors being involved. They see the controlled environment of laboratory tests where supposedly the intervals of a single factor is being isolated as a refinement in methods. Now, notwithstanding the overwhelming success of this approach, controlled experiments in economics raise a number of issues. First and foremost, is it really purposeful human behavior that is being examined in experimental games? Action means choosing between alternative goals and therefore using scarce resources. It can be conceived of only in a world where individuals do not have complete knowledge of the future. Action by necessity spans over the temporal flux if only because past choices have a definitive and irrevocable impact on the present and the future. Hence, human action cannot be contained into a single isolated point of time. It is always planning for the future. Now, controlled experiments by construction fail to reproduce these crucial features of human action. Reciprocity games are explicitly designed as one-shot interactions for otherwise the experimental divergence from the predictions of the self-interest assumption could be attributed to individuals in tensions to build long-term relationships and not anymore simply to reciprocity preferences. More fundamentally, experiments cannot grasp the notion of loss in heads of profit and uncertainty as participating individuals are not putting their own property at stake. Participants can never exit an experiment with less wealth than they entered into. These considerations lead to a crucial question. To what extent data generated by controlled experiments could possibly hold the purified essence of the much too complex real world? To raise the question, in a sense, is to answer it. Economic experiments do not reproduce reality into a controlled and analytically simplified environment. Rather, they misrepresent it by means of artificial interactions that are inspired by mathematical game theory. Some of these interactions, for instance, the ultimatum game, have no relevance whatsoever for the voluntary exchange transactions of the real world. The data generated by such experiments is not at all a proxy for reality. This in itself implies the failure of reciprocity economics to bring more realism into the neoclassical analysis. But also, how can the experimental economists be sure that all participants, even though they share a common knowledge of the rules of the game, interpret the game and other's actions identically? Each participant enters a game with his prior experience of the world and his own expectations for it, and also with the knowledge that he is simply playing a game. Hence, there can be no guarantee that participants are not at all playing a different game, each of them. This implies that the most basic assumption of reciprocity economics, namely that a particular type of motivations is being tested, is invalid. Individuals may well be moved by social preferences, but this cannot be controlled for in a laboratory experiment. What is then the positive contribution to praxeological economics of the analysis of reciprocal preferences and of behavioral experiments in general? Simply none. Praxeological economics is not built on any particular assumption about the actual content of individual preferences and motivations. It develops a price theory in which it does not matter whether one is buying a Peugeot car because he wants to resemble to his French neighbor or out of calculated hatred for the competitiveness of Germany's car industry. All that matters for price theory is that a Peugeot, rather than a Mercedes, is chosen. Once again, it is actually the Austrian's greatest achievement to have freed economics from psychology and erected it into a specific branch of knowledge about the individual and society. Yet, behavioral economics appears as a legitimate endeavor within the neoclassical approach. This approach is not neutral to individual's preferences. It does give an exclusively materialistic content to the post-it of self-interest, partially due to its mathematical and formalistic inclination. In this analytical framework, it makes sense, or at least so it appears, to enlarge the notion of self-interest. But then, why not adopt praxeological economics from the very outset, given that it has not imprisoned itself into a narrow conception of the self? According to Professor Fair, reciprocity economics has applications to a number of areas, most notably the provision of public goods, implicit contracts, wage rigidity, and the optimal allocation of ownership rights. Now, I could not go here through a detailed analysis of the reasoning behind all of these applications, but I believe that a more detailed analysis would undoubtedly conclude that the entire approach exhibits a bias for collectivism. This must be the case because the notion of reciprocal behavior is not value-free. Indeed, when the economist defines of scale of individual preferences relative to others' well-being, he is de facto making a venue judgment as to how people should feel about others and how they should act accordingly. At the outset, the notion of a preference or fairness or for inequity aversion may appear quite general and deprived from a netical meaning, but in order for these concepts to become operational, they must receive a more precise meaning, in particular in terms of wealth distribution. Professor Fair has then no problem to declare that, quote, in experimental games, a natural first approximation for the relevant reference outcome is the equality of material payoffs, end of quote. Fairness then becomes equated with egalitarianism and this is what it is all about in reciprocity economics. As it could be expected, its proponents do not attempt to explain how individuals heterogeneous capacities, intentions, and beliefs could naturally result in egalitarianism ever becoming the motivation that drives action or simply what is unfair with inequality. Fundamentally, egalitarian preferences are rooted in Professor Fair's neglect for private property rights. Indeed, in what he sees as one of the main applications of his approach, public goods would not be under provisioned in a voluntary cooperation setup if non-contributors know that there would be retaliation against them by contributors who would feel their preference for fairness has been hurt. This same line of reasoning leads to the conclusion that the threat of retaliation, which is really rooted in the fairness preferences being hurt, is a powerful implicit conflict in Folsom that would make material incentives that is conventional contractual obligations superfluous if not harmful. However, what is retaliation not foreseen by a contract if not a sheer instance of violence? This is immediately obvious in the public goods setup where retaliation takes the form of a monetary penalty imposed on non-contributors by contributors. How could such a setup, which de facto allows for forced taxation, ever qualify for a case of voluntary cooperation? The modeling of fairness preferences as preference for egalitarianism is not merely a side issue. Reciprocity economics is trying to explain social outcomes by the particular type of individual's preferences. By ascribing a specific ethical content to these preferences, Professor Fer is no longer conducting an impartial analysis. As a matter of fact, he is legitimizing concrete social norms, namely the acceptability of forceful expropriation. This is in full contradiction with the Austrian value-free approach, which is the greatest achievement of subjectivist analysis that made it possible for economics to expand as a positive science. In a sense, reciprocity economics is a case of regression from economics. In conclusion, both neuro and reciprocity economics are grounded in a conception of our science that sees the explanation and prediction of human behavior as its main task. This indeed has been the main research project of neoclassical economics, which from its very beginning has been rooted in a psychophysical theory of utility and value. Hence, these two facts are fully consistent with the empiricist understanding of scientific progress. The trouble, however, is that economics is not an empirical science. Accordingly, neuroeconomics and reciprocity economics can hardly be seen as an improvement of our existing knowledge. If anything, they keep alive persistent errors. But I believe a greater bet should be awaited from this type of multidisciplinary research that Professor Ferre and others are actively promoting. This whole multidisciplinary endeavor consists in grounding the same object, scope, and method to both economics and psychology and even beyond. Such an attitude goes against the very basics of a scientific approach which tries, first and foremost, to delimit and classify what is subject to inquiry and how inquiries should be conducted. The psychology and economics multidisciplinary facts fundamentally reject this conception of science. Nothing but loss of knowledge would be expected from it. And this in itself, I believe, is another strong reason to reject these facts. Thank you.


In this video, we provide the solution to question number three for the practice final exam for math 1050. We have to expand the logarithm, well the common log of x cubed times the square root of x plus 1, all over x minus 2 quantity squared. So first of all, this is a fraction inside of the logarithm. So using the second law of logarithms, this would expand to be the log of x cubed times the square root of x plus 1 minus the log of x minus 2 quantity squared, like so. In the first logarithm, there is a product going on here. You have x cubed times the square root of x. So we're going to break that up with regard to the product there. So that gives us the log of x cubed plus the log of the square root of x plus 1 minus the log of x minus 2 squared. And so then with all the remaining logarithms, there are exponents that can be pulled out. The x cubed, the exponent comes out as a 3. For the square root, it will come out as a 1 half. And then for the minus log of x minus 2 squared, that 2 would come out as a coefficient. So the correct answer we're looking for would then be 3 log of x plus 1 half log of x plus 1 minus 2 log of x minus 2. For which we see that's exactly choice a, just like we said a moment ago, 3 log of x plus 1 half log of x plus 1 and minus 2 log of x minus 2. So using the three laws of logarithms, we're able to correctly expand this logarithmic expression. Thank you.


We live we are live recording pursuant to chapter 20 of the acts of 2021 this meeting will be conducted by a remote means members of the public who wish to access the meeting may do so in the following manner by emailing steve mccarthy at mccarthy s mrst ma.gov that's m c c a r t h y s mrst ma.gov now in person attendance of members of the public will be permitted but every ever will be made to ensure that the public can adequately access the proceedings in real time by a technological means in the event that we are unable to do so for reasons of economic hardship and despite best efforts we'll post on the mrst website and audio or video recording transcript or other comprehensive record proceedings as soon as possible after the meeting. And so we'll call the meeting to order at five o'clock PM and take a roll call of attendance Hallie here Dylan here and I'm here so the three are here and Doug and Gaston or absent. Okay, is anyone here for public comment that's general public comment unrelated to any of the hearings. or anything else on the agenda, so if you have something related to one of the items on the agenda just hold off until your time comes up, but if not it's general raise your hand. No, okay. Recognize you can click the raise hand button on the bottom or free on the phone, you can press star nine. That's right, thank you, Steve. Um, okay, so moving on to our special short terms, these are both UMass top of the campus with. Jen Lynn Fontaine is anyone here from the university. This is these are just the lacrosse games right which we've done before. Yeah, there was this little scheduling snafu last time so all but two were approved. Okay, so there's that the agenda last time. All right, so this is sst dash 23 dash 12 and sst dash 23 dash 14. Are there any questions or comments about these from either anyone here. No, if not, is there a motion to approve. So moved. Thank you Dylan, is there a second. I second. Thanks, Hallie will take about Hallie. I feel in. I and I vote I. So that is sst dash 23 dash 12 and dash 14 are approved three to zero with two absent and then. We move on to, so we're going to do nil camp next to you or the common Vic, why don't we push to nil camp. Okay, so this is a new liquor license applications. Amendment of approved application nil camp associates LLP doing business as country crossroads six university drive manager achar hotel and. We are people here for that. Could you just run through this?  So we received this letter from the ABCC and it's kind of a confusingly space, but they checked that the investigator represents no application or return to the licensing authorities with no action because there was a couple of things missing. They wanted a correction to be made here, which the applicants done and here we we did that on the, these are just check marks saying it won't be pledged and and that they're the the applicants has not had any history of violations just in check boxes that were missed on the core reforms missing notary stamp they actually were notarized but it was the the superior, in my opinion, old fashioned on paper embossing notary and not the stamp so they might not have been visible so. So I will try to point that out to the ABCC and this section was that there is bank statements provided for a new time, but then tell and they're asking for more information about this and an affidavit being required in the person that they will not have an interest in a license. So the applicant has provided those things. The ABCC requests that all corrections and documents before to the Amherst licensing board and after review and approval, the board will afford all documents ABCC so this this entry on your agenda is for that review and approval and Dick and Akshar are you able to hear us and talk. Yes, I can hear you can hear me. Yes, I can. Well, good. Thank you Steve I think that was an accurate summary. And I would just like to ask if anybody knows what la I stands for. I, I think they are referring to the. It does not have those initials I don't remember exactly what's called off the top my head but there is a local. There is a form that they used to be called a form 43 that the town fills out. And I think they call a licensing authority certification now so I don't know if that's some kind of jargon that they use internally or outdated terminology but there is a check box and that for reconsideration so I am almost certain that's what they're referring to. Okay, when you return the documents would you point that out and. Yes. Ask them to let us know if that's not the right thing. Yes, I will. Thank you all for allowing these, these tweaks to be fixed here. I think we're going forward smoothly. Oh, sure. Thank you. Okay. Does anyone have any questions about the documents corrections. No, if not, Steve, what do you need a motion to look like. I guess you could. Move to approve the, the new documents being submitted and forward them to the ABCC. Right. Reiterating your earlier decision. I would like to make that motion. The moves. All right. Thank you, Dylan. Is there a second. I second. Thank you, Halle. Any further discussion. If not, we'll take a vote. Halle. I Dylan. I vote aye. I vote aye. That is three to zero with two absent and they've been approved. Thank you. Great. Thank you so much. Thank you. Mr. Evans and Mr. Patel. Thanks for coming in. Okay. So what is up next? Are we doing this? Continuing the. Yeah, I guess why don't we. Why don't we just do the official. Move to continue the spokes and they, yeah, they did express that they were in for anybody in the audience for you for this. So we had a bit of a, a hiccup with the scheduling today. So we will only have quorum for 20 minutes and thank you for our board members who were able to make it so we can get through a few things today. The board was already scheduled to meet next week. So given the short amount of time we have here. I would suggest the board continues and the applicant has assented to do so to continue both of these spoke applications to next Thursday at five o'clock. Okay. So the one is already open. And then, so we're just going to continue that one. And then the next, the change of manager, do we open and then continue it? I believe you would. Yeah. Okay. All right. So is there a motion to continue the hearing for the new liquor license application for the spoke LLC doing business. It's as spoke live. 111 pray street all alcohol on premises. Manager Colin Hughes to be continued to April 6th. Thank you. Dylan is there a second. Thank you, Hallie. Take a vote. Hallie. I. Dylan. Hi. So I three to zero is too absent. That is continued to April 6th. So now we're going to open the hearing for the change of liquor license manager application for the spoke LLC doing business as the spoke 35 East Pleasant street. Manager rich. Loop hold. Is there a motion. Motion to open the hearing. So moved. Thank you. And a second. Thank you, Hallie. We'll take a vote. Hallie. I. Dylan. I. And I vote I three, which is three to zero is too absent. The hearing is now open. And this will be continued to April 6th. So is there a motion to continue the hearing for the spoke LLC at 35 East Pleasant street from to April 6th. Thank you. And a second. Second. Thank you, Hallie. We'll take a vote. Hallie. Hi. Dylan. Hi. I vote I three to zero with two absent. That hearing is continued until April 6th. Okay. So what is next? We do have this common Vic application is a, is David Dolly in the audience. Are you here for the blue mango application? If so, can you please raise your hand? All right. Yeah, we can. We can move on to that one then. Okay. Does this require and this doesn't need an open hearing. No, it's just a common Vic, but just a common Vic. Okay. All right. Mr. Dolly. Welcome. Could you explain, give us a little. Introduction to the blue mango. Yeah, hi. Can you hear me? Yep. Okay. Great. Yeah. So we would like to open a dessert cafe downtown. And it's basically we're going to serve coffees, teas and various desserts, such as ice cream, crepes. Shaved ice desserts with fruit. And some cakes and cupcakes. And that's, and also, you know, the tea on smoothies and bubble teas. So that's basically what, what the, the menu is. And also we have some area for seating. So we're going to be doing some table service as well. So people can come in and sit down and someone will. Take your order. And that's yeah, it's basically a cafe with also a sit down area. And we hope to be open. The plan is like until 10 o'clock on weekdays. And until 11 o'clock in the evening on Friday and Saturday evenings. Okay. So that is the plan. Okay. Wonderful. Thank you. Does anyone have any questions for Dylan? Yeah. I just wanted to get to the quick question. 103. That's the same building with a coronation cafe and Pita pockets and panties. That building. Correct. Got it. What, maybe I just, I'm not seeing it in my agenda. Just what was the, the, where's your story in relation to all the other ones? It was previously hair East hair salon. Oh yeah. Okay. Yeah. Excellent. All right. I would just ask, do you have previous experience running a hair salon? Yeah. Yeah. I'm the original founder of the crazy noodles cafe. Oh, wonderful. Yeah.  That's great. So we did crazy noodles for about five years. And then we got tired and sold it to my wife's sister. And so now we're going to try to get back into it. Wonderful. Okay. Dylan. I was going to say, well, in that case, I guess I'm going to say I, I look forward to it by making the motion to approve. All right. Great. Thank you. Is there a second? Second. Thank you, Halle. Any further discussion? Hearing none. We'll take a vote. Halle. Hi. Dylan. Hi. And I vote I that is three to zero with two absent of the common Vic for blue mango is approved. Thank you so much for coming in. And best of luck with your new venture. Thank you so much. Thank you. Bye. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Okay. So. That's what we're doing. That's it. Should we do. We could do the renewals really quickly. Yeah, we could do the renewals. We could also, um, the farmer winery application. I told her not to come today, but it's kind of the same thing as they do every year. So you could, if you felt like you could approve it, you could, or we could push it next week. Both of those really quickly. I just want to, I just wanted to, I just wanted to make sure that we're doing the right thing. I just wanted to make sure that we're doing the right thing. I just wanted to make sure that we're doing the right thing. These are just renewals. Um, as there are a motion to approve the common big renewals for CB dash one 19 one 20 and one 21. Duncan donuts, Mojite and Sibys. So moved. Thank you. Dylan second. Thank you, Kelly. We'll take a vote. Kelly. I still in. And I vote I that is three to zero with two absent. That application has been approved. Okay. Great. So that knocks off everything except for the spoke, right? Yeah. We've done that a few years. It's okay. Um, is there a motion to approve the farmer winery. License for Lori. Perkins doing business as home fruit wine. So moved. And a second. Second. Thanks, Kelly. Um, We'll take a vote. Kelly. Hi. Dylan. Hi. And I vote I three to zero is too absent. That application has been approved. Um, okay, great. Okay. We'll take a vote. Okay. Okay. Okay. So, um, we'll take a vote. Um, except for the spoke, right? Yes. Yes. All right. Great. Um, oh wait. So, uh, topics not. Reasonable anticipated. Um, Anything. Yes, I guess I will. Surprisingly. The biggest updates we've had in a while. I'll be quick though is, um, the remote meetings has been continued for two years. The town is looking into ways to potentially offer hybrid as well. Um, and, um, the state has approved, um, has also extended for a year, the outdoor, that kind of easy permitting of outdoor dining and the, um, alcohol outdoor alcohol service and the, um, the, uh, Um, Uh, take out alcohol as well. So. Okay. Great. Um, I have the, so next time on the sixth, we're also going to be talking about rental registration. Um, so, um, um, Um, Um, I told Steve today, I have to leave at six next week. Okay. All right. We're as speedy as we can.  I'll be here. Alrighty. Okay. Check a little more thoroughly next time. Thank you all for coming in and appreciate it. And, um, the, uh, the spoke wasn't, um, wasn't really upset at all. So. Oh, great. Okay. So we should be able to give that a good thorough review next time. Fantastic. All right. Is there a motion to adjourn? So moved. And a second. Thanks, Hallie. Um, we'll take a vote. Hallie. Hi. Dylan. Hi. And I vote aye. That's three to zero. Two absent were adjourned at five 15. All right. Good work. Thank you. Thank you all very much. All right. See you next week. Bye-bye. Bye-bye.


If you have any questions, go ahead and raise your hand, he's going to repeat the micropone. So, with that. Yeah, awesome. Thanks very much. Can I have any warnings on time? Yes, please. I need, let's say, five minutes before. I would appreciate that you tell me. Yeah, good. Thank you. So, thanks all for being here. My pleasure being here. So this talk, and I have a lot of content. So I'm going to run. It's going to be recorded so you can watch it like even faster on YouTube later or slower if you'd like. That's the good thing about things that go to YouTube. So this talk is on four reasons why you need Istio. Or I took a different spin about talking about basics of distributed systems, right? I think most people, when they're developing applications today, especially if they're in the microservice world, they kind of forget that they entered the realm of distributed systems and they don't realize that, and that's the problem, right? So that's my perspective. Things that you will not be seeing today. You will not be seeing source code. You will not be seeing cats if you're expecting pictures of cats. And you will not be seeing an introduction to Istio. So there's a friend of mine here that's actually going to talk maybe a little more introduction to Istio tomorrow. Is that correct? Right, Saturday? Sunday. Sunday. All right. So go there. So I will talk. So this is not an introduction to Istio sessions. Awesome. So my name is Diogenes Bertori. I work at Pivoto. This is my Twitter handle. You can feel free to follow me on Twitter. Mostly you tweet about technology every now and then. A few personal things, but it's a good place to catch up on things. So let's go to distributed systems basics, right? I think the first we let's talk about the advantages of writing distributed applications. So what was once a big application? Let's see the advantages of distributing. Often distributed systems, they become more reliable. They become more scalable just by the nature that was what was once a single piece and hard to scale. It's now distributed in smaller pieces that can probably, should at least, probably scale individually, right? Now the problem with that is that the engineering skills required to write and develop distributed systems, they are much more complicated than you would write a single monolith app. If you're writing an application that's composed by 15, 20 different pieces, that is more complicated than writing an application that's going to be packaged as one file and run on a Android or mobile phone, for example. Just the basics of that, right? Also, when dealing with distributed systems, there's an increased need for tools and patterns that facilitate, right? So on patterns, I recommend a very good book by Brandon Barnes, one of the creators of Kubernetes. He wrote a book on distributed, designing distributed systems. It's like a short read that you can probably read in a day. It's not even 200 pages, but I strongly recommend. And I'm going to address some of the patterns that he talked about in this book in this session. So it's going to be good for that, right? Let's continue talking about bad news on distributed systems, right? It's hard, right? So one of the other bad news in distributed systems is that you're often dealing with chains of calls. So what was once a call, or let's say many operations calls to functions that happen inside a single application, a single package, now these calls, they're happening across distributed networks of applications, right? And the problem with that, and when there's a problem with, let's say, one of your components, it becomes certainly much harder to debug. You can't just open a debugger and see what's going on with that specific piece of technology because first you have to know where things are fading, right? So that is a problem. So like, how do you know exactly where the problem's happening? So this is one of the problems with distributed systems. Just identifying where the fault is. Another problem that makes distributed systems hard is that you're dealing with different types of protocols. Again, if you had one big monolith, most of the calls, they were internal calls, library dependencies, or just calling a function from another function. You don't necessarily have to deal with different types of protocols. But again, when dealing with distributed systems, some communications, they're going to be message-based. Some are going to be HTTP-based. Some are going to use Protobuf, GRPC. Some are going to use a file-based. So like, just the nature that you are now dealing with also different types of protocols makes it hard to develop distributed systems, right? So have that in mind when you're writing microservices applications that they're realme are in. It's in the realm of distributed applications, which brings you to a very important piece of this talk, which is the fallacies of distributed computing, right? These are mistakes that developers make when they're developing applications without thinking that they are now part of a distributed system network of applications. So have that in mind. Most of these concepts, they were from the 80s, and one of them was incorporated in the early 90s, right? So they're old concepts that exist in software development, but they are very important. First of them is that we often developed thinking that the network, and they're eight, the network that we're dealing with, it's a reliable network. They look and somehow trust the network. I'm going to talk A to B, and as a developer, I expect, yeah, the call is going to get there, right? So this is a problem. We develop thinking that that's not the case. Another problem is that bandwidth is infinite, and not only bandwidth as in the ability to transmit information, but the ability to process that information. Because bandwidth stops being a problem, the moment whoever's receiving a call doesn't have the ability to process that information. So more than bandwidth itself, just the ability to process information. Funny note on bandwidth is that while, from a technology perspective, we've been able to increase bandwidth and communications by more than a thousand times for the last 10, 15 years, the latency is still a problem, right? Just so you know, like the amount of time it takes from one ping, one, let's say, if you make a call to a service from New York to London and back, without zero, zero, zero processing time, it's 38 milliseconds, just in latency, right? So often we don't think about it developing applications, especially distributed systems. So only in physics, basic speed of light, it takes 38 milliseconds for a ping back, ping back from New York to London. So that in mind, the second way is that we often think networks are secure, networks are not secure, and I'll give you like a few interesting, some interesting examples later on. Topology doesn't change. This is one that's like myself as a developer in my early days of development, I never thought about it, and I'll talk about it. Why? Latency zero, I mentioned it about latency as well, that like we think that communication is going to immediately get where we think. And again, like as developers, I don't remember myself thinking like 15 years ago about this when developing an application. I assumed everything here was true in my source code and the things that I developed, which is wrong, right? Continuing, there is one administrator, right? So that essentially means like, oh, there's one person I have to talk to, there's one, let's say there's just a single system, but there's one group of people. And then this has become, let's say, not so much of a problem lately, but when it was created, yes. Another one is that transport cost is zero, like how much, how many times we think about the payload versus the overhead of a call or request when we make it, right? I don't think we do it that often, right? Unless you're dealing with, let's say, unless that is a problem or impacts your business. And often we see people doing, when that starts to impact business, oh, my network bill for AWS is starting to become a little bit complicated. What am I doing? How can I bring down the number of bits that I transmit? And the other one is that the network is modular, so the network doesn't change. So these are all fallacies. These are all things that I did, when developing applications, that I forgot to think about that this are all lies, right? So have that in mind. And of course, this is a presentation on Istio, so I'm going to talk about four things in Istio that I believe Istio help you with. Now, Istio can certainly help you with one of them, but I want to touch, especially given the time, I want to touch on four of these, right? That the network is reliable. And please forget that this is, what's here is not true. They're all fallacies. So every single thing that's here is a lie, okay? Let's talk about network reliable, just introducing the concepts a little bit. If there are a few ways you can think about network, if you just consider MTBF, main time before failure of network equipment or servers, that is already a measure of things that things go fail. There's the stacking that can be applied. If you stack routers or network components in parallel, then you probably get twice the MTBF, but if you make them serial, then you get half, right? So this again, there's just a physical nature of harder failing. And this is a switch, by the way. And there's also the aspect that every single network that we run today is some sort of virtual network, not necessarily a cable directly connected to a switch, but you have to also factor that the machines that are running the networks, they're processing many, many other things as well. Like any Linux operating environment can have a virtual machine, and that's the main thing. So we don't think about that when developing the applications, that the actual networks, they are not necessarily reliable. And these are servers. They look very bad, but they're servers. And now the second point which I'm going to address is that the network is reliable. And I made, let's say, using some poetic freedom here. I just changed the word network from the endpoint, is that many, many times we think that when we're connecting or interfacing with an external application or endpoint, we tend to think that that endpoint is going to be there for you. It's going to be right. And we don't often design applications thinking that whatever endpoint I'm connecting to, might not be available to handle my request. So I'm just switching a little bit this one from the network is reliable to the endpoint is reliable. And a big mistake that I did, which is a very strong recommendation that I give it to you, is that I always design for reliable endpoints, assuming that whatever I was going to interface with was going to be there always, all the time. So I never had to deal with, let's say, alternative error flow for applications when integrating with other systems. Because during testing, we assume if these applications are not running, my application is not going to work. These do systems that need to work together. If they're not up and running, then my application is not going to work. But many, many times I ended up compromising the experience of my application. I'm the owner of BA because the application of BA was not running there. So a very important recommendation is design for unreliable endpoints. Design for endpoints that might not be there when you're developing. And again, especially in microservices, please also hear distributed systems and distributed computing, because that's what's really happening. The fourth policy that I'm addressing, and hopefully I'll talk about what Istio has to do with them as well. I'm okay with time, it seems, is that the network is secure. And this is especially interesting, right? And not necessarily talking about the network itself, whether or not a communication, let's say a physical channel, a physical network channel is secure or not, but whether or not the communication between applications is secure, right? Now, how many of you remember the Equifax breach about... It's not even a year ago, right? I'm sure those of you that live in the U.S. think you have to at least spend one hour of your time thinking, like, how does this will impact me, right? Am I going to sign up for the package that Equifax is offering? So, like, all these things we have to think about. And when you think about, like, what created that, it was, like, okay, you can sort of blame the unpatched struts vulnerability. That's how people got access to technology. But then there is unpatched software every day, right? Like, we need to keep patching our software or fixing bugs every day, right? So, is it enough that I, as a developer, can just blame unpatched software to vulnerability like this? That's so naive to tell, right? Because we all know that security is not a one-time exercise. It's a practice that you need to have. And I spent some time, invested some time reading a little bit more about, like, what and how the vulnerability happened. And what was happening is sort of like this. So, like, there was an application, there was, like, users here, like, evil users here. I should have, like, put a sad face here. Talking to a external-facing app that was using struts, struts was great technology back then. The patterns in struts are still used. It's a mother-view controller pattern, great for separating constraints inside applications. Now, this struts app was running inside the DMZ, which is often the type of network that separates an internal network from an externally-assessment network, right? And this strut app has access to a DMZ, the middle horizon, right? So, now, the thing is that, when I say that the application network is secure, is that this struts app had unrestricted access to other applications that it should not, right? So, that's how the failure happened, is that someone got access to use the vulnerability to have access to the struts application. And then this strut app, even though it had a specified flow of information issue, it also had access to other types of components inside the application, which were then exploited to get our data, right? So, that tells me that whatever application network we had here was not secure. So, when you have that in mind, that you're not necessarily talking about the physical communication networks, but also, like, how much information are you exposing from your application to networks? Should a database allow million subscribers to be retrieved? Should that have raised an alarm? Probably. Should I receive a call from a user that I don't know who that user is? From I receive tons of calls from a user that should not be making those sorts of calls. So, those are all, let's say, red alerts that we should have that something wrong and weird is going on. So, have that in mind, application, it's not secure. Now, the other one, it's, you're developing your application. So, this is you developing your application and your stack overflow because you don't know what you're doing. And then you develop your application and then it runs in your machine and it's great. We always test some aspect of the application on our machines. Just using this example to justify that topologies do change, right? The topology of the network in which your application participates in your machine, then in itself, in QE in production, right? So, we often think that topology is not going to change, but like just from the developing environment, the application that I'm running here, Java application, C, Golang, just the network of that environment is going, it's different than the network of other environments. So, from the moment you're developing an application to the moment you're going to run that application, either in a QE environment or in a production environment, the application topology is going to change, right? They are different. Now, there are more complications, right? In terms of topology, it doesn't change. If you are dealing with sensitive information, either from, let's say, PHI, which is patient health information, under a HEPA compliance or PCI DSS payment car industry, I forgot the designation for DSS, there are rules that tell you that cold running in production should be separated from cold running in a QE environment, which often can say something that the topology of a production environment of the network is likely going to be different, right? So, this is a slide from a recent presentation given at the Boston Kubernetes Meetup that I run and I love this because it was someone talking about how they run Kubernetes in a PCI DSS environment. So, like, how to run Kubernetes in an environment where it's going to be handling and dealing with credit card information. And there is a rule in the PCI DSS that says that separate development, test environments for production environments and enforce separation with access controls. This is again, just to find that, yes, topologies are different. If you're developing, assuming that the way things look in your laptop, by the way they look in a production, that's not probably a good assumption. Now, with the fact that topologies do change, another problem comes to us, which is how do we deal with changing topology in an effective manner. And this is where bad news comes, right? This is data from the last DevOps State of DevOps report 2017. And this tells that only 28% of the high-performing companies, high-performing companies have automated configuration management for their applications, right? This is very bad because the very high-performing companies, what does it mean for that? At least in that context one of the metrics is that you're able to turn in a code change in production in less than one hour, right? And this is not how long does it take for you to deployment. It's like from the moment a code is pushed to a repo, how long does it take for that code to be packaged, tested, and deployed and run in production, right? So companies do that and that's the effective method because companies, they do that in less one hour. This metric is called the lead time, right? So the lead time between a fix is fixed or a new feature is implemented. It's in code, it's in a repository and from the moment that reaches production. So the lead time, it's one hour. So companies that are ultra-high-performant they do that in less than one hour. So it's one hour from the moment the code is there to the code is running in production, right? Passing, of course, many gates, many checks, sometimes there are even manual checks. But the problem is that dynamic configuration management is hard and I tell you it's hard because the very high-performing companies only 28% of them do that. So it's it's complicated. It's very complicated. So there is again manual steps involved in that. And the fact about, the point about the policy changing and dynamic configuration management is that you should be able to dynamically know where things are running, right? So if you need to someone to change the IP of a database manually that's not necessarily dynamic configuration, right? Happening. If the point of an application changes from one IP to the other and someone has to do that manually if the part changes if someone has to do that manually that's not dynamic configuration management, right? Hopefully you know that there are ways to do this. And to talk about bandwidth is infinite but I'm going to have to derail this conversation a bit so that's why the tracks and apparently you're narrow that you're getting off tracks. Good. So again, concepts from the distributed systems designing distributed systems there are three ways you can sorry, three patterns for designing distributed applications three groups actually, right? So there's a single node group which is a technique that you apply to applications running close to each other in a single node so even though it's distributed systems you can take advantage of running patterns such as sidecar pattern or ambassador pattern which is you bring some sort of intelligence close to the workload that you're running. There's also serving patterns which is the more popular one so you have like a web server and you replicate that web server you have 10 copies of that web server that is a distributed system pattern and batch which the name says it's batch, right? So again, the stateless it's very popular you don't have a stateless application and you need to do something with it you replicate as many copies as you'd like because they don't handle state or state is handled somewhere else, right? State is always handled somewhere so stateless is kind of complicated to say there's always state being handled somewhere you just make many copies of the exact same application and you're good with that, right? Now sharded it's another pattern for distributing and sharded especially used when there's a very large amount of data involved because think about that, if the data is small enough that you can have copies of data keep them consistently like in many nodes if it's small enough then there's advantages in keeping that but when you have large pieces of data and it's expensive to keep copies of all all the data then you start thinking about sharding which is when you distribute the data you get the data distributed so that you don't have to store all the data all the time in all the replicas, right? If you're doing sharded write you should always think that having one replica of the data it's not enough, if that goes down you're going to have disruption, you don't want disruption so often sharded data deployments they come together with replicated data models so there is some part that's sharded and you're also replicated part of that data somewhere, right? The scatter and gather, this is more for processing if you heard of map reduce similar patterns where you try to distribute the processing you load into many leaves it's in a tree model, you distribute to the leaves and after you finish processing at a point in time you're going to then reorganize that data in a way that makes sense so when you're dealing with processing data that's also coming and then there's my batch batch is another one of course that's very popular, you just normally schedule jobs you can use batch model for that now my favorite in the session right before this one was a little bit about this it's event based so for me in my opinion the largest the ultra great advantage about serverless is that it's event based it's not request response based, it's an event you're going to process, you're going to consume capacity hopefully when you get an event you're going to do that often messaging based systems they are event based so as I said today very common types of distributed computing that are event based is serverless and function as a service have you ever seen a serverless data center? this is how serverless data center looks like it's amazing right how did they do that, we don't know oh sorry I can't I know I lied so congratulations you are now certified distributed system developers I even have my certificate that I printed for me so after finishing this part presentation I am now officially certified distributed system developer by the distributed system institutes of course I just made this up but the point is that you know like the some of the hard problems that are involved in developing distributed systems you should factor that in your development, in your day to day activities now finally like I only have like I don't know 10 minutes a little over 10 minutes and I'm finally going to talk about like something that was in the title of this presentation but for me it was very important to give you the idea that yes microservices development is distributed systems there are tools and patterns that make your life easier when developing microservices applications this is one of them this is a very good one right so the first thing that I'm going to address using Istio and when I took the picture of this slide apologies for the lack of focus there is that the network is secure so assuming so this is a lie so the network is not secure so what do we do then to make sure that we can handle the problem of networking security so one of the things that Istio has out of the box it's ability to support mutual TLS mutual transport layer security that means that if you're talking from endpoint A to endpoint B they know each other they are trusted and you have formally established that they can communicate with each other and you know why this is important because if we assume the network is secure it's not it might be the case where an application like this app that access another one and you know as an architect that that show flow should not have happen so again there are technologies Istio with mutual TLS can help you with that so that it allows you to formalize the information flow so if you as the data architect for the application or the architect you know what systems should be used for a specific business functions then that should be formalized this application can only talk to this one and no one else and under what circumstances so have that in mind that Istio with mutual TLS allows you to specify a secure communication channel formalized so it's not only like okay I'm gonna add transport layer security and everybody has transport layer security but everybody has can talk to me you're actually specifying who are you expecting to be interfacing with so that calls you reduce the risk again security is a practice so you always have to do the sorts of exercises the other it's on topology doesn't change that we all believe now that topology does change is that okay so you understand that from just from your basic development environment from the QE environment that your application topology is going to change and in order to help with that you need to have in mind dynamic configuration management which is hard but if you have dynamic configuration management in mind and you do that as part of your activity you're gonna have you let's say in less trouble so one of the things that Istio does with the addressing dynamic configuration management is that there's a piece of there's a component in Istio called pilot that knows where the endpoints are and when as new endpoints come and go they get notified of their existence so if endpoint foo version 3 comes up it will notify pilot that there is an endpoint foo version 3 up is available and anyone that wants to interface with that endpoint pilot will know exactly where that endpoint is and all the diversions that are available for that endpoint and even more like how many times we can call that point and under what circumstances so again to address the fact that topology does change and dynamic configuration you still can help with that so that was reason number 2 for Istio dynamic configuration management of endpoints very good so this is the example though ok let's say my application running in node A under a certain IP under a certain network changes it's now running in a different network under a different IP still pilot is going to be notified of this change and you can have access to that information if you want to call that application right again topology will change because because it does change now I think the network is reliable on is also very interesting because sometimes we think about compromising our application because we didn't necessarily provide the real users of our application with the necessary priorities that they need so in case I have an application from A to B and again as owner of application A do I want to disrupt my own experience because B is not running and what sometimes happens is that we knowing that some things are failing we still wait for fader like I'm going to talk to application B I know it's down I'm still going to wait for a time out I'm going to talk to application B I know it's down I'm still going to wait for a time out so the user experience the end user experience gets disrupted even when you know that the other application that you're interfacing with it's not responding so why wait for fader if you could know right now that's not working and keep the call local right so one of the things that Istio does is that through the circuit breaking it opens the circuit it knows that that application is not responsive and every many calls or every many minutes you can then call that application again to see it has come back up right so the fact that you're not waiting for fader increases the overall response time of your application right because you're not waiting waiting for things to go down to fail and then do something you know that they are down right so and then the fact that there's a centralized repository that knows the applications that are up or not any new application that wants to access the same application we also know that the application is failing and then can keep the call locally right again increasing reliability you know having to wait for fader and to address the bender with is infinite is it's rating limiting the rating limiting is mostly an often associated to API management but I think API management is changing a bit it was only seen as a technology for external APIs but more and more we see internal APIs if you're dealing with microservices multiple applications distributed systems you actually have multiple APIs internal to your applications in the same way that you would only let's say if you have ever used the Google Maps API if you want to make more than five calls I think per second you have to pay you should also have that level of that level of control inside your organization there are more important applications inside your organization and you should prioritize those in the sense that let's say if you have a mission critical application and others you should probably give that mission critical application the ability to receive more requests than just a regular application imagine that you might have other applications impacting mission critical application so one of the things that you still can do as well is the ability to add rating and limiting to your application so that you don't necessarily fall into the fact or fall into assuming that your bandwidth is going to be infinite you can give each individual user and you can do that in a job base like json web token base individual users you can give them different levels of permission to your application in terms of number of requests and requests per second so given that I have two minutes let's go to the summary so addressing the four distributed system policies that I talked about network is not reliable and for that recommendation is that you can use circuit breakers the network is not secure recommendations that you can use mutual TLS topology changes the recommendation is that you use dynamic configuration management discovery if you can do that and the bandwidth is finite so the recommendation is that you use rating and limiting for that so that's it twitter handle is retory and that's what I wanted to talk to you today thank you very much now we do have a couple minutes for questions so if you have a question I can repeat the question then four minutes alright I'll be in the back if you want to talk to me individually and this is a topic I'm very passionate about so feel free to reach out to me thank you very much have a good day


We are discussing the air sterilization system that is the second part of the oxygen delivery system. So, as we have seen that the Teflon filters are mostly used on a small scale fermenter, but the sterilization of the inlet and the exit air in large scales bioreactors more than 10,000 litre capacity that can present a major design problems because on a large scale filtration is very expensive process. The filters also have a very expensive material and then they are their other problems. So, it is very difficult to make and the make the filter and then their energy requirement that is very considerable factors while designing, while selecting the filtrate material or a different filter for large scale fermenters. As we know that heat sterilization is an alternative option apart from the filter system heat sterilization system is also used. So, the steam can use to sterilize the air in older style compressors it was possible to use heat generated by the air compression process to sterilize the air because sometimes when the compressor compress the air in that process heat is also produced when that heat is produced. So, that is automatically helped to sterilize the air, but at that time the heat is required and the temperature is required created by that compressor should be that must need the sterilization requirement. But if we say if we use that compressor heat just for the sterilization of the air then before supply to the fermentation vessel then that has to cool down to the required temperature that is needed inside the fermenter. So, that is why before injecting into the fermentation vessel that there should be a multi-device cooled system is required that is attached to the fermentation. So, that is very critical mostly the in a small scale reactors we can see here that these are the small Teflon type, but in case of the high scale large scale this is the mostly the HEPA filters. Before talking about this we are discussing about the sterilization of air through heat either through the dry heat either through the compressor heat, but here I want to talk here about this that on a large scale fermenters that mostly the HEPA filter high efficient particular particulate resistance filters are mostly used. You can see in this slide the arrangement and the packing of that material just to have the pore size of 0.2 micron to 0.45 micron. But this is a small size of HEPA filter that is mostly used in different fermentation and other biomedical equipment, but as we know that we are talking about the air sterilization and then the condenser is needed just that is the simple heat exchanger through which the cool water is passed around the air chambers that just to maintain the temperature. So, in such case there is another problem when the air has to exit from that then there is the volatile substances and then air has to pass through that then there is the fermenter should be attached with the condenser. So, before exit the air outside then that should pass through the condenser and condenser should be linked with the chilled water. So, that is why that minimize there are two role of that condenser one is that reduce the escape of the volatile compounds on other hand that also reduce the evaporation loss through the fermentation. So, the dry the air also prevents the blocking of the air exit air filter with the water. But in problem of using the filter on the exit point because when the air pass through the medium that mostly become wet and that is the more chances of the choking or the blocking of the exit filters. So, in such case we have to be very careful because sometimes when there is a blockage of the air from the outside in an exit point then what happen there is a continuously rise of the pressure. So, in case of the laboratory scale fermenter when the vessel is made up of the glass then there is a chance of burst. So, we have to be very careful while maintaining that the pressure on exit point.