Welcome, everyone. This is the Jenkins User Experience Special Interest Group meeting. It's the first day of February 2023. Thanks for attending. So topics for today. We had included security reviews for UX pull requests. Tim's probably not here. Vada, is it okay if I put you on the on as that topic? Yeah, for sure. Okay. Collecting general feedback on UI and UX regressions was a topic we had before. What's happened recently in UI improvements, what's coming in additional ones, and improving keyboard usability. Christina, I'm prone to move this one higher on the list to be sure we get to it if that's okay. Yeah, I have a short update, not a huge one. Oh, good. Okay, great. Well, so then I'm going to move it upwards. And Vada, we had a topic on feet user feature flags from the past. Is that something you would like to do further in this meeting or no. I don't think there is a lot of discussion to have there the pull request is still waiting to be merged. It was mainly reviewed and partially approved. I had a topic to add. Close to the bottom of the list, which is deprecation of Jenkins JS libs. It's, it's has something to do with the work I've been doing on the pipeline groovy plugin. Great. All right, so deprecation of Jenkins JavaScript libraries and pipeline Ruby plug in. I improvement work. Okay, great. Thank you. All right. And specifically here it's ace editor moment JS and others right. Yeah. Okay, great. And, okay, and Uli is the app are ready for build actions. Thanks for proposing it that's good. I'm not sure if that makes sense if never young or, you know, Tim is there, but we will see. And I think let's, if you're okay with it, let's put it to keep it on the agenda. And, and we may decide to defer to next meeting, that's okay as well. Great. Great. All right. Let's do that then and see Kayla. Okay, good. All right, any other topics that need to be on the agenda. Okay, then security reviews for UX pull requests vatic which you're okay if I open this one. Thank you. Thank you. All right. So as you can see there, there are only two pull requests that are waiting for security review both of them are mainly stalled in terms of the development so we are not reviewing them if they are not ready to be reviewed in a sense. If you open the first one, it will be especially interesting to see there, something that I would like to avoid for the future is mainly. It's mainly it was approved. But there were some change that were added to the pull request, we need to have the need security review level to be going back at that point otherwise we could have some vulnerability introduced as well. At the bottom of the page, you will see, as a potential future that there was a vulnerability introduced after the security review. So it's a bit lucky that we were able to review, to review that and to catch the vulnerability. But it just to highlight the fact that if we introduce a vulnerability in a pull request, it could be very expensive for the security team to do a security release for Jenkins core control to just waiting a bit to review pull request and doing that during the pull request like I was. And I apologize that my page is not I see this, the bar moving across the screen still vatic and I'm not sure what's going on with GitHub today. You know, the don't know about the top is just an indicator, there is no real information behind. Oh, okay, so agenda and do not care about the data. I want it so that's the main point. Okay, great. Thank you. Any concerns from any others on how security reviews are progressing I like the suggested the recommendation, please ask again for security review. I assume that's what you're envisioning there is that the plug in, or that the author of the pull request should put the need security review label on again, after they've made significant changes. Yep. And I would say not necessarily substantial change, but just something that could be interesting for us, meaning if you corrected a typo, we do not care. But if that typo is a HTML part that is using a variable, please ask for a review. Good, that makes sense so apply your judgment as the author of the call the pull request to decide yes I'd like another review. And in case of doubt, just ask. Great. All right. When in doubt. Ask, or when in doubt set the label and you'll clear the label if you think it doesn't justify it. Okay, or set the label and rely on security to on the security team to clear it. Good. Thank you. Anything else on security reviews. And next topic then was collecting general feedback on UI and UX regressions and I believe the last time we discussed it was continuing to use JIRA as the collection point. Were there other things that we need to discuss here on this topic, or should I drop it from future agendas. I think we can drop it. Okay, great. The feedback there is also related to the user feature flag. If you're able to provide a feature that is broken just disable the flag, and that information could be collected in the future automatically with the telemetry, so that we know if a feature is broken for some people or not. Looking forward to have the true request being merged to apply some telemetry. Okay, it makes sense. So that's on general feedback. Next topic then improving keyboard usability Christina. Now Christina do you want to share your screen what what would you like. Not this meeting so bit of a background on this so we know that we have a few accessibility issues to resolve on CI in general, some of them originate from the open source. Jake, we have to work out a few details just around how we want to handle pull requests from the community and work out our process there before I start. I want to get that sorted before I start to create tickets and bug people. None of the changes that are needed are heavy lifts, it's all front end facing around keyboard accessibility, mostly for this round anyways. And I can certainly provide guidance around what's needed. So there will be tickets coming. We're working out our own process around that right now just because it needs to kind of align with some work that we're going to do internally as well. So they're coming plans getting in place and then I'll create tickets for the open source. Great. And of course, like I'm very open to feedback on how that works down as we go to to to flesh out a process that works for all of us. Right, so, so I think what I'm hearing is we can look forward to some initial reports of hey here are some accessibility issues detected, and later we'll look forward to some pull requests and here are the pull requests that resolve some of those accessibility issues. Yeah, we have a laundry list of requests from clients. And some of them are issues that are more pressing than others. So for this initial round we're really looking to just deal with the kind of the show stopping issues where say a user who's relying on accessible technologies. We cannot navigate. We're looking to fix those first and then we can work through the kind of then don't a couple of nice to haves they're all, you know, we're supposed to accommodate them but the ones that aren't quite as our roadblocks in the same way. Great. Super thank you. Anything else or any questions from others. Okay, thank you. Next topic then was what's happened recently in UI improvements and I don't have a story to tell here are there others who would like to highlight recent changes or things that need to be discussed. There was a single recent fix, and it was related if I remember correctly Uli in app bar right in some portion that involved in that bar, but I don't remember the details. Actually, I don't remember the details. I've seen that a fix was in the last release but actually I don't know what's exactly broken there. Okay. Great. And the what's coming in UI improvements. I know that young and Tim had been working on further removal steps for Yahoo UI and that there are some things in flight there. I think it's a good lead into our next topic the deprecation of the JavaScript libraries unless there are others who have topics they want to discuss on what's coming in UI. So Basel let's take the next one deprecation of Jenkins JavaScript libraries you want to share with us what what you've learned and what you've proposed etc. Yeah, and it's not just me working on this. It started back a couple months ago when the pipeline stage view plugin was updated to remove its dependency on handlebars. And since then, it's also been updated to remove its dependency on moment JS. And then I've also yesterday proposed a change to remove the AC editor from pipeline groovy. These are the last three big dependencies on the Jenkins JS Libs plugin, which is dates back to 2015 and has not really been maintained since then. So we've been deprecating these older library plugins like moment JS handlebars, hopefully AC editor will be deprecated soon as well. Once we stop using it from pipeline groovy. So the only thing I wanted to highlight here in this meeting was there's still some bits and pieces left in Jenkins core that have something to do with this subsystem. And I, I haven't figured out what they are, or if they're still needed. But the less and less we depend on this less likely I think that they are needed. So, maybe it very well might be the case that once we rep out AC editor from pipeline groovy think that's the last or close to the last plugin that's using the subsystem. We might also be able to remove the bits and pieces that are in Jenkins core that only exist to support this framework. I'm not really sure one way or another. So that's why I wanted to bring this to more people's attention. Since I don't know much about this, but I think there I think there's more cleanup that can be done. And this has some security impact because these libraries are all pretty old and even if none of them are vulnerable right now. They put us at risk for future vulnerabilities just because of their age. So it would be good to get rid of these little bits and pieces, if we can. I think there's also still a plugin that's using this that nobody has fixed yet, which is the GitHub. One of the GitHub plugins forget which one. I want to think one of the GitHub plugins is still using one of these Jenkins JS Libs plugin from 2015. So you know we could decide if we, if we think that it's important enough to patch or if we could leave it behind but I think so there's there's still more cleanup we're not done with the cleanup work is what I'm saying. There's still plugins left, even though they're obscure that are that are using the stuff and then there's still bits and pieces in core. So, definitely something that we'd like to to get fully deleted, so that we don't have to worry about it. Great. Does that mean that we don't use moment chairs anymore or just the chairs lips wrapper. So you're doing your own most, most of actually, you know what I did with pipeline groovy was it already had its own webpack build. So I just integrated a CE editor into that. And in general that's essentially an equivalent to Jenkins JS Libs is stuff like these modern technologies like webpack they're doing the same thing as what Jenkins JS Libs was doing, or similar. But it's just that these are now standardized industry wide rather than something that our project developed seven years ago that's not maintained anymore. And one thing would be good if you can have a look at the developer documentation, if we still have some references to use JS Libs. I think. Yeah, there's always docs. Yeah, this this more cleanup that needs to be done here. So definitely looking for people to help with cleaning up some of the long tail of this. You know, I think I definitely definitely put a dent in the problem with pipeline groovy plugin yesterday but yeah there's still more left. Because if I remember correctly when I started to use some modern child scripting libraries in my plug ins. I found these that I should bundle them with JS Libs and there is a really a good water tutorial and I think we should remove these from our web page. So nobody will find them anymore. Yeah. Yeah, thank you. Thanks Willie. All right. Any other points on the, the deprecation of Jenkins of those outdated jump Jenkins JavaScript libraries. Thanks Basel. So next topic we had body. You want to take just a brief moment on the user feature flag status report. I don't think it's really necessary at this point and there was no status report at this point it just user feature flag. It's a pull request element just to provide the feature. So if it's not adopted there was no interest to have any report of this kind of thing again. Got it. Okay, thank you. All right, then last topic on the agenda was is the app bar ready for build actions only. Could you give us some some overview for those of us who may not know what that bar is like me, and, and let's talk for that. So maybe I can share my screen. You bet. Stop sharing. Okay. I think you see my browser now. Yes. Okay, good. Okay, I think what I want to show is that recently we, let's go to the minute this a little bit bigger. So I think Tim and young and proposed some kind of new scheme to, yeah, to have some new fuse that use the sidebar on the left here. So, the plugin manager now has separate sidebar with updates available plugins installed plugins and so on, and a lot of let's say managed Jenkins fuse are using this new scheme. This scheme is having a new sidebar and having an application bar where you have some buttons to, you know, to change the few or they look and look and feel. And I'm wondering if this concept should be used for build actions as well. So, let's have a look at this is one of my bills from, you know, from one of my plugins. And we have a lot of summaries here in this screen. And what I would like to know is if, if I am, for instance, going to the code coverage results. Typically you have a few which shows the code coverage results. And this is just an experiment. So it's not really ready. What I've a normal sorry, let's start from beginning. Normally if you click. Into the summary of a build, for instance, we are looking at the test results. Normally you have the same on the left, you have still the old application or the side panel is the same on the left. So I'm wondering if I should change that in the same way as we have done that on the plugin manager so when I click mutation coverage, I have a new side panel, which shows only the details of my few. So, and this is a question if we should go this way or not so I'm just experimented a little bit with it. Before that change I have a tabs here where you can see the overview you can have the line coverage and so on I'm using tabs to show different elements of my few. And now I'm wondering if I should rather use this sidebar to show these results for instance if I click here on fires. Then I have only the fires and I should click on overview I see only the overview and vote that's not really clear for me if I should go this way or not. And that is more a little bit of question for young and Tim, if we should use that in bills as well. And if we use that in bills I think we need some guidelines on how to use it for instance, should I have buttons there for the previous build and the next build. Yeah what else buttons should I have that are common to all plugins because when I use this concept in the code coverage plugin I should use it in the warnings plugin. You should use it in the test plugins or all plugins which show information should use the same way. And, you know, I'm not sure which way is the correct way. So the action buttons that you've listed there's primary control hello and secondary. Those are those buttons that perform some change on things. These. Yeah, okay. These are just some from the Hello World. I've just integrated but actually I would like, for instance, I'm here you normally see the code coverage of the whole project. And I would like to use a button to show the coverage of the changed files only. Okay, so you will click here. It's not read implemented but this is my idea to have a, for instance, a list box to a button and toggle button where you can select show only the coverage of the changed files or show the coverage of the whole project. Or another thing is when you, let's say, you can see here the line coverage. And maybe it's simpler if I have a toggle button where you can switch to the branch coverage or the mutation coverage or something like that so you don't have so many tabs. You just have one tap and you have some other element to select what you actually would like to see. So this is something I'm experimenting so it's, you know, it's not really finished so it's I thought it makes sense to discuss it before I'm start working on it. Otherwise. So, so for me, I've recently been using exactly these pages and have been very deeply happy with the data I get from them so I'm interested would then this would mean line coverage branch coverage and file coverage in one model would move to the or in one idea would move to the left and be along the sidebar and I would click through them to get to those so that, so that instead of a top level list of tabs, it would be immediately the coverage page with coverage data. Yeah, yeah that was the idea, especially now I've integrated for instance we have a code coverage from Chacoco. So this is line and branch coverage and I've also integrated mutation coverage using the same model now. And this is a concept I'm using in my warnings plug in as well I've had results for check style for find bugs for PMD, etc. It would be simpler if I have them in control in one side panel and show only the results I'm interested so when I'm looking at code coverage I want to see only code coverage and now warnings, and if I'm looking into my warnings plugin. I don't want to see the test results so maybe we can focus more on the details I'm interested for now when we are using the sidebar. Currently, you see the sidebar is very long. It's even longer when I let's say let's see if I have a project which is a little bit longer. So, when I'm opening now it's not longer I think my plugin is not loaded my final warnings plugin so typically the sidebar can get very long so you need even scrolling and you know this is something I would like to avoid. And it would help if I replace the sidebar with thumbs and this was a special sidebar for my plugins. So I'm not sure if that makes sense or not so. I need a little bit feedback for that. So maybe this is something we can, you know, have a look at the next session as well. I think we should let's bring it to the next session I think we could also benefit by by pointing young and Tim to the recording of this session, so that they could see the the concept that you were envisioning and your question so that they may be able to to prepare and have their thoughts gathered in ready for our next session. And one thing maybe that's interesting is what's also important for me which does not work currently, I would like to have the screen of 100% for my plug in. And currently if I set the size of my frame to 100%. It's an overlay with the bottom bar. So, I think it would be really helpful for plug ins if I can say, please let my few fill the whole few. And young, but not the bottom here so I'm not sure if this is an overlay, why this is not calculated correctly here. So these are, I think as a plug in outer I need some advice on how to do special things and we don't have these advices yet. So, maybe this is something we should work on. Currently the app bar and these changes all are only applied to the system settings part, which is, you know, for some people it's an important part for but not for me for me I'm interested in the build results, and we should spend some time on improving these results as well. I like that I think that's a great idea let's, let's plan it for a conversation for our next meeting. Thanks very much. Okay. Any other questions here. Okay, thanks. Thanks, any other topics that need to be discussed today. Alright, thanks everybody.


Our next speaker is Lily Morse, whose presentation will address the title, Exposing Fraud Vulnerabilities in Client Auditor Relationships. Okay, so I'd like to begin by asking everybody to take a look at the picture frame on the left.  This could be the face of a friend, maybe not a best friend, but somebody that you're familiar with, that you trust, and that you know for a period of time. And while you're thinking about this person, I want you to think about what you'd be willing to do for this person. Would you be willing to engage in bad behavior, potentially illegal behavior, in order to help this person out? Do you think that this person would be willing to do the same for you? And while we're asking ourselves these questions, I'd like to apply them to a context in which they're particularly relevant, accounting. So I'd like to direct your attention to the picture on the right. On the right you see Ken Hanna, who was chair of the Audit Committee at Tesco. For those of you who are unaware, Tesco was a multinational grocery chain based in England. And what's interesting about Ken Hanna and Tesco is that last fall, they were involved in an accounting scandal. And the accounting scandal was that they found that they had Tesco over-reported their financial income for the year by $391 million. And so when we hear about accounting scandals like these in the media, we might ask ourselves what leads these companies and people like Ken Hanna to engage in this sort of behavior known as financial statement fraud. And what my research does is it attempts to answer this question by looking at the relationships that these companies, people like Ken Hanna have with the people who review their income statements known as independent auditors. And so what I do is I bring participants into the lab and I assign them to the role of either a company manager or a reviewer, an auditor. And what the company manager does is he or she prepares a financial statement and auditors review these financial statements for accuracy.  The first, they're interacting with an auditor who is a friend. And in the second, they're interacting with an auditor who is a stranger. And what I find is that managers when interacting with an auditor, managers are much more likely to cheat or over-report their financial statements when they're interacting with an auditor who is a friend compared to interacting with an auditor who is a stranger. And likewise, reviewers are more likely to allow over-reporting to occur. They fail to catch a report over-reporting when the manager is a friend compared to a stranger. And what's more interesting than that is that managers use different tactics and different strategies to over-report depending on the type of relationship they have with an auditor. So managers are much more likely to try to use deceptive tactics trying to shrink the auditor when the auditor is a stranger, whereas with managers when they're not going to be with a friend they're much more likely to attempt to collude with them and try to share profits. And so what this shows us is not only that the interpersonal one-on-one relationship between managers and auditors not only does that matter because it can tell us when these parties are likely to over-report or commit illegal behavior, but also it influences the strategies that they use to try to accomplish this sort of behavior.


Welcome to the U.S. Naval War College, the Navy's home of thought. NWC Talks features our world-class experts examining national security matters. We hope you enjoy the conversation. Earlier this year, a group of cruise ship passengers hoping for a glimpse of arctic wonders got entirely more than they bargained for. Harrowing seas, howling winds, precarious rescues. The Viking sky's voyage from the arctic city of Tromsø ended abruptly when the ship encountered high seas and the captain had to issue a made-a-call. The ship came within 300 feet of running aground near the rocky shores of Hustadvika, Norway. The winds were 69 miles an hour, waves reached 40 feet, lifeboats had to turn back because of what one pilot called brutal conditions. Only 500 of the 1,300 passengers were airlifted by helicopter at night and with high winds roaring and experienced the mostly elderly passengers described as terrifying. No one died, but there are plenty of YouTube clips of sliding furniture, broken windows, and old folks getting winched up into helicopters. This is not a one-off. The melting ice has spawned a wave of so-called last chance tourism, bringing more than a million visitors a year to the arctic. I'm Mary Thompson Jones, a professor of national security affairs at the U.S. Naval War College. This is NWC Talks, and I'm inviting you to join me in imagining the arctic. So let's consider a few of the lesser-known facts about the arctic region. The arctic ocean is the world's smallest and shallowest. The arctic is a desert, virtually no precipitation. The arctic, by far, is not the coldest place on earth, Antarctica is. The arctic also has the world's least salty ocean. The arctic is both a sea and a terrestrial area, and only a small percentage of the arctic has actually been charted to modern international navigational standards. Most importantly of all, the United States has 1,100 miles of arctic coastline on the north slope of Alaska, making us a true arctic nation. So speaking of geography, where exactly is the arctic? Technically, the arctic begins at 66 degrees 34 minutes north latitude. Why there? Because that's the point at which the sun is visible at both of the solstices. Nations to the south find this 66 degree line somewhat arbitrary. The U.K. has been active for centuries in the arctic, and it calls itself a high north state, routinely sends its Royal Navy out into arctic waters. China declares itself as a near arctic nation, and it has charted a polar silk route to underscore that point. So who gets to be a so-called arctic state? Well, it helps to tilt the grove and take a circular tour from the top down, starting at the north pole. You see the Alaskan and Russian land masses reaching out to each other across a mere 51 miles of the Bering Strait, making the arctic ocean on the western side appear almost to be a lake. The sturdy solidness of Canada dissolves into some 19,000 islands, with the Russian side arcing around more than half of the arctic ocean seemingly more cohesive. Russian land is clearly closer to Canada than to Europe. Iceland floats alone, unattached, barely whisking the man-made dotted line labeled Arctic Circle. Norway stretches Evernorthward, cutting off arctic ocean access for its arctic neighbors Sweden and Finland. But the arctic is more than just a maritime domain. It has a terrestrial aspect with mountains, tundra, rivers, wildlife. The arctic is a stew of fresh and salt water. Its icebergs form far away on land, made of frozen freshwater, travel hundreds of miles until they break away and float into the ocean. Let's go back to an earlier image from 2007. In August 1st, Russian submarines descended more than two miles under the arctic to plant a Russian flag near the North Pole on the Lomonosov ridge. The event was extensively covered on Russian television, and two parliamentarians on board crowed about the significance declaring that this act proved the arctic is Russian. The rest of the world was skeptical. The Russian stunt lingers because it was an early salvo in what has revved up to be new evidence of great power competition. The United States is unprepared and is being challenged in the arctic as never before, militarily, economically, politically, and environmentally. So let's talk about the environment. Let's use a phrase that is uniquely suited to describe what is happening in the arctic right now, ice melt. For more than a century, the US and other arctic powers were able to relegate the region to the back burner because it was frozen, nearly solid, nearly impenetrable, and most people thought it had little strategic, economic, or political value. Then, in the early 1980s, satellites began photographing the region on a regular basis. Soon, analysts had trend lines showing how dynamic the region really was. The photos corroborated many other kinds of scientific data painstakingly collected year by year. Within a few decades, the photographic evidence began to mount, and today it is incontrovertible. We can still debate the why, but the fact is vast amounts of ice are melting in changing the arctic at such a rate that many parts of it will be ice-free very soon. There is less ice this year in the Beaufort Sea, which lies just above Alaska, than at any time in the last 40 years. Greenland is losing about 250 billion tons of ice each year. Old ice, much of it lost forever, has been replaced by much thinner new ice, which forms and melts within a single year. What would an ice-free arctic look like? Well, economically, there would be shorter shipping routes that are access to undersea oil, gas, and minerals, changing fishing patterns, and an increase in global investment. The human dimension would include an increase in human activity, including tourism, but it would also include damage to the infrastructure that would be particularly difficult for humans. There would be thawing permafrost, buckling roads and buildings, population migration, erosion and potential loss of coastal villages all along the arctic sea coast. Environmentally, we'd see more icebergs, we'd see an increase in extreme weather events, and unpredictable changes for animal and plant species. But the real issue that we're interested in is the political and military dimension. We'd see the entry of more out-of-region competitors, an increase in great power competition, and inevitable militarization of the region. Let's go back to the 2007 moment when Russia planted that flag. And fast forward to the present. What has happened in the intervening time? Well, the numbers tell the story of Russia's push to dominate the region. Vladimir Putin has created a new arctic command, four new brigade combat teams, 14 new airfields, 16 new deepwater seaports, and boasts the world's largest fleet of 40 icebreakers with 11 more on the way. Russia has refurbished old bases, created new ones, just open, severity-clever on Kotelnay Island has the largest building in the circumpolar arctic. Russia has been robust about using its assets, going beyond what is purely defensive, sometimes harassing neighbors in the Baltic, creating friction and unease with Norway, Sweden, and Finland. It has hosted massive exercises and contributed to a sense that the arctic is becoming militarized. Russia's industrial dominance in the arctic, based largely on oil and gas, has also grown as it builds new technology to handle liquefied petroleum and liquefied natural gas from a massive new terminal on the Yamal Peninsula, largely financed by the Chinese. But Russia has two other assets that greatly improve its position. One is the North Sea route, which hugs the Russian coastline and is becoming evermore navigable and ice-free. Russia and other trading nations are eyeing it as an economic and time-saving alternative to the Suez Canal. Russia has something else too, which the West lacks. Russia has people. It has cities such as Murmansk, Borkuta, and Norilsk. The population of these cities is larger than the entire U.S., Canada, and Greenland towns and villages combined. Russia is heavy investment not only in Russia, but Iceland, Sweden, Greenland, and elsewhere, which is coming as well from China. So let's talk about the U.S.'s other competitor in the region. China put the world on notice in early 2018 that it considers itself a near-arctic state. China's white papers and subsequent policy papers have put words to the deeds. China has invested heavily throughout the Arctic region in a bid to build a Chinese silk road and make an economic foothold. Its entry into the Arctic domain belies its claims of being only interested in commerce and shipping. China bought its first icebreaker from Ukraine, then built a second, and is now building a third that is nuclear-powered. And China's steadily increasing economic investments may well lead to a military presence in order to protect them. So what does all this mean for the United States? The flippant answer is very little, unless and until Americans embrace their identity as an arctic nation. America's lack of factual knowledge about the Arctic has created a real vacuum in understanding the region. Typical public misperceptions include the notion that the Arctic is always dark, always cold, and always full of ice. Traditional public opinion polls show Americans' knowledge of the Arctic with dismaying results. Only about 18% of respondents were able to correctly answer and identify the United States as a country which has territory with thousands of people living north of the Arctic Circle. But lack of public knowledge is directly related to a lack of national discussion and lack of direction as a crucial issue. There are signs that the U.S. has begun to grapple with the problem of the Arctic. Often the conversation dwells on a single issue, such as America's astounding lack of icebreakers. Various branches of the military, the Coast Guard, the Navy, the Department of Defense as a whole have all taken a stab at writing arctic strategy papers. Members of Congress, not surprisingly the Alaska delegation, have proposed everything from a deep water port in Nome to a national arctic agency. Think tanks have weighed in, and the volume of white papers, blue ribbon panels, and conferences has exploded. Beyond Washington, NATO has staged military exercises at the largest since the end of the Cold War in the Arctic. And indigenous people from several countries, Americans among them, are speaking out on how their lives have been affected by the melting ice. Scientists are making more effort to explain their findings to policymakers, and through better websites they are reaching out to the larger public with more easily understandable data. There have been a few stumbles, too. The U.S.'s opportunity to set a new course at the Intergovernmental Arctic Councilmeanor Stereo in Finland in 2019 fell flat, as it stumbled very publicly over wording on climate change. An attempt to showcase a new diplomatic presence in Greenland was sidelined as the Secretary of State was pulled away at the last minute to more pressing issues in other regions of the world. These developments, both good and bad, come late in the day. There is no single state in the United States, no single government agency that can possibly reorient the nation's attention to the North. It has to come from Americans themselves, imagining the Arctic and realizing their own Arctic heritage. Thank you for spending time with me today, imagining the Arctic. I'm Professor Mary Thompson Jones, and this has been NWC Talks.


This is Mises Weekends with your host, Jeff Deist. Hey ladies and gentlemen, if you know Dr. Guido Hulsman, he tells us that while it's possible to read everything Mises ever wrote, it's almost impossible to read everything Rothbard ever wrote. And even today in 2018, we are still opening boxes full of Murray Rothbard's personal letters, book reviews, editorials, you name it. And as a result of all of this, of course, are one of our resident scholars over the summer, Patrick Newman was able to put together the Progressive Era book by Murray Rothbard, which we released last year, but there's still more coming. A fifth volume of Rothbard's Conceived in Liberty, which is his epic history of colonial America, is being edited by Patrick even as we speak. So there's still new Rothbard being released. And so Patrick gave a talk at our recent supporters event on just that sheer output and relevance of Rothbard, even still today, almost a quarter century after he's gone. So you'll enjoy this talk from a real up and coming Rothbardian, Patrick Newman. So thank you everyone for being here. So the title of my talk is Murder Rothbard in the 21st century. And one thing I'll just note, sort of the tie in with Peter's discussion was that Rothbard, if you didn't know, was a very low tech person. So he always used the typewriter even till the very end, he sort of cling to his old fashioned typewriter. And I can only imagine if he was giving Peter's talk, he would have a little bit more emphasis because not only are these companies very anti-free market, but I still can't imagine Rothbard with an iPhone or going on Facebook or something. I could see him still around. He would type up a Mises Daily on a typewriter and he would give it to someone here and they would have to type it up. So at least that's an interesting point. So in this talk, we all know where Rothbard, enormously influential Austrian economist, libertarian scholar, he wrote in the 1950s, the 1960s, all the way up into his untimely death in the mid 1990s, 1995. And really talk about one, the 21st century, how is it author who wrote a lot of his work 30, 60 years ago, how is he still relevant? Why is he still relevant? Why should people still read Rothbard and how does works still have this sort of this timeless message? And I'll be talking a little bit how this relates to sort of the works I discussed earlier, the Progressive Era in the fifth volume of Conceived in Liberty. As I said, I don't want to give too much information about those because then no one will buy the works. So I have to, you know, keep everyone just always wanting a little bit more. So one of the things I'll first do is talk about some of his work that is actually still cited, not only by you might say Austrian economist or libertarians, but even sort of mainstream scholars.  And while it is true that he hasn't been, you know, given his sort of his just rewards and properly cited, some of his work actually still is very influential and is very significant. One of them that I'll mention is actually his dissertation, which is the Panic of 1819, Reactions and Policy. So he wrote this dissertation in the 50s. He got his PhD at Columbia University. He defended in 56 and the book was published in 62. And this is still, it's actually quite remarkable. It's still sort of an undisputed reference book on the Panic of 1819. So if you look at authoritative works on history or economic history and they're talking about the Panic, nine times out of 10, Rothbard is always cited. So whenever I look, I look in the bibliography at the back and I see Rothbard, Panic of 1819, I go, all right, there we go. We got a win. And so just as at least a couple of examples, the Oxford history of the United States, sort of a multi volume series, one of the works on Jacksonian America by Daniel Walker Ho, what a half God wrought, which came out in 2007, uses Rothbard's book. So it cites Rothbard's book, a book more on monetary history by two economic historians, Charles Calomiris and Stephen Hopper, Fragile by Design, came out in 2014 and they cite Rothbard's book on the Panic of 1819. And actually recently, someone just contacted the Mises Institute. They have a podcast on Jacksonian America, sort of affiliated with Stanford University and they asked if someone could speak about it. And I'll be speaking about the dissertation, hopefully in a week or two. It's called The Age of Jackson. And I mean, it's actually quite remarkable that someone's dissertation written 50 plus years ago is still, people still wanna talk about it and people still actually read it. I have enough trouble getting people to read my dissertation and I wrote mine three years ago. So actually, when I teach class on my syllabi, I say, if I catch students cheating, I don't fail them. I just have to make the right of book review on my dissertation and no one cheats in my class. I gave a copy to my dad and I asked him if he's ready. He says he keeps it right by his bedstand. So if he has trouble going to sleep, he opens it up, knocks them right out. He's on page three right now and I gave him two years ago. So anyway, I mean, as a side point, I mean, it's actually very interesting that his dissertation is still read and it's still used. I mean, that really shows and you look, he was very influential in the primary sources. He was a true historian in that sense. And to do that for your first work into something that you didn't even really use that much before really just shows how much of a polymath and how skilled he was. The second work just briefly sort of mentioned that it still gets occasional references. It might not be as approving, but it's still cited as sort of the Austrian reference on the episode was America's Great Depression, which he wrote really in the mid 50s, about 56 to 57, and then it came out in 1963. And the much more famous Freeman in Schwartz volume, a monetary history of the United States, came out the same year was certainly more influential, but it's still heartening to know that occasionally Rothbard gets citations by mainstream scholars on sort of the Austrian discussion of the issue and sometimes even approvingly when they have a pro credit expansion, causing the cause of the Great Depression. So as an example, there was an article that came out in the Journal of Macroeconomics just two years ago on a new history of banking panics in the United States by Andrew Jalil. And he cites Rothbard as sort of the authoritative analysis, just a brief mention, but I mean, you'll take it when you can get it, getting Rothbard in the Journal of Macroeconomics. And then for any of you who know Barry Eichengreen, who wrote a famous book, Golden Fedders, sort of a well-known Keynesian economist, he had an article that was published in an economic history volume with Chris Michner on credit expansions as a, the Great Depression, excuse me, as a credit boom gone wrong. And he actually takes sort of a pro, the Federal Reserve had easy monetary policy in the 1920s and that contributed to the Great Depression. He takes a very sort of Keynesian view of the Great Depression, but again, still cites Rothbard and it's still, at least for the 1920s bubble and it's still heartening to know again in the 21st century, not only by Austrians or libertarians, but also by mainstream scholars, Rothbard's work that was cited, that was written 50 plus years ago is still cited. So it's still good to know and it just shows the significance of him as an author. So sort of moving on aside from those, listing some of his work that's been important, what is actually sort of the importance of his writing? So why should people still read his work and people still do read his work? Just from laymen, just getting into economics or political philosophy or even scholars later on. I mean, this is something that's important because especially now, science is becoming increasingly at least economics where an article is written five or 10 years ago, it's out of date, it's no longer got the most up-to-date literature citations or methodology, so it's just put it in the dustbin. But why should people, and why do people still read Rothbard? Well, the first thing is that Rothbard was a great writer. He was very clear, he was concise. Most academics are terrible writers. Reading a lot of academic work is kind of like passing a kidney stone, it's very painful, you sort of force yourself to do it, you go, oh, it's just this bad process. And on the other hand, Rothbard, he can really make the most uninteresting subject interesting where he can make it funny. He can emphasize the points he can drive at home. He uses italics, which is great. So he knows how to emphasize points. He's entertaining. And it's someone that regardless of the work that you read of him, a layman can understand it, a young scholar can understand it, as well as a technical scholar. So for example, we'll talk about a little bit, man economy and state has this importance. As an example, Rothbard also, just as ports of a writing, I mean, just if you read it, you'll learn all these great phrases and great illustrative ways to describe things. One of my favorite Rothbardian phrases is architectonic edifice. It's sort of this structural, systematic, building block for something. So I've always tried to use architectonic edifice when I write or just, I encourage you to try in your daily life to even use architectonic edifice one time. You say, let's say you make breakfast. I went to the buffet at the hotel and I had this architectonic edifice of breakfast. I had sausage and bacon and eggs and toast and cereal and strawberries. And the best part was I didn't have to clean any of it up, which was great for me. Another great word for him is scintillating. He uses, describe, he says something scintillating and I remember presenting a paper one time and someone commented because I had a block quote from Rothbard and I said, Rothbard scintillatingly described something and blah, blah, blah. And someone said, well, you really shouldn't, something not scintillating, blah, blah. And I immediately interject and I say, how is it not scintillating? It's brilliant. And then everyone laughed. And I said, I'm gonna use the word. That's very illuminating. There's nothing wrong with using sort of value-laden terms when it's, you wanna emphasize something. And that's something Rothbard did. And that's again, it just helped you be a better writer and it's still very important conveying ideas. Talk more about the ideas. So with man economy in state at least, it truly is an architectonic edifice of economics. And it's, I did use it once. And it is something that, again, a layman can read it, as well as a person. I've, man economy in state, one of the most influential books, probably the most influential book I've read. I still open it up and I still find gems of insight. And I still deal with all of Rothbard's books. And again, it's an economic book. It was written in the 1950s. And the fact that still people read it, again, most economics books, most papers, no one reads them. You look at the, you know, the count, it goes into a journal.  All right, well that's two for this year. You know, that's how bad it gets sometimes. At least turning to the economic history, sort of talk a little about the influence of the two books I mentioned from before. You know, why are they still important? So you think of the progressive era. It's about period, you know, roughly over a hundred years ago, Rothbard wrote it in the 1970s. You know, why is it still important? Is it just history for its own sake? Or does it actually have lessons about today? Well, as Peter described, you know, Rothbard really sort of goes into the emergence of the modern sort of what's known as the alliance of throne and altar.  So if you think today, and Peter went through this with a lot of the tech companies, sort of these very sort of favored businesses, and also various Wall Street firms, they donate heavily to sort of various political parties. They always seem to have the appropriate, they're so large, they can handle the regulations, the compliance costs don't hit them as well.  So CNN, the New York Times, the Washington Post, MSNBC, where if you disagree with those, where you're just biased, et cetera, they're the ones really conveying the truth. And then big government where, you know, you have the Democrats and the Republicans, just sort of the whole Beltway, which is really protective of its power and sort of the pelf it has over, that's another great Rothbard word, pelf.  I thought Rothbard sort of goes into this, you know, how this developed, you know, how this sort of modern, you know, corporatism came into being, it just didn't happen out of nowhere. It didn't begin with the Reagan tax cuts in the 1980s, despite, you know, what Piketty says or something about that. You know, it was around for a lot longer before then. And, you know, at least to go briefly into sort of, you know, conceiving the Liberty Vol. 5, so then you go, okay, even farther back, why does something about the 1780s still have relevance today? So, you know, at least from one perspective, you know, Rothbard tells the story about the founding of the, you know, of America's Constitution. And it's something I mentioned before, he really tries to hammer home the point that a lot of people today still, they, you know, they find it very uncomfortable to believe, but that the state is a coercive entity. It's not a social contract. It's not a unanimous social contract where outside of its anarchy and then people sort of voluntarily sacrifice some of their rights, you know, it really is sort of a coercive theory and states emerge through conquest. And he goes through the process of basically how the United States, you know, how the Constitution was formed and how a lot of the state ratifying conventions really a majority of the people didn't want it, but do the various reasons, sort of delegate switching sides, media propaganda, which I'll get into more, or even in cases outright coercion, the states sort of joined the union. One of the most fascinating cases, this sort of gets, we talk about trade retaliation yesterday. Lou Rockwell, Ron Paul talked about this, was that, you know, after George Washington became president, two states were still holding out. It was North Carolina, it was Rhode Island. And little Rhode Island was the last state, it was held out until the very bitter end. And it just so, you know, the government, the United States said, well, we might just have to take them over if they don't join. And at one point when the ratifying convention was going on in Rhode Island, in the Senate, a bill basically was passed that was going to enact retaliatory trade legislation against Rhode Island. If they didn't join, they wouldn't be allowed to become a free trade zone.  And even then, despite that, Rhode Island barely ratified by two delegate votes, 34 to 32, it was just, you know, really out until the bitter end, they're going to hold on, which is, you know, as Rothbard would say, it was heroic. You know, it was the last stand. You know, I'm like, great force is a liberalism.  One other thing that we can sort of learn from the period that Rothbard goes through that I was sort of heartened to define, you know, to read, you know, when Rothbard's work is that, you know, this isn't the only time the media has been very biased in favor of big government. One of the advantages of the Federalist forces during the ratification of the Constitution is that they really had control of the press. They had control of the press. And more importantly, despite really knowing using it now, they had control of the post office, which is very important where a lot of the postmaster generals were heavily Federalists. And so the Federalists had greater communication. They were able to, you know, propagandize much more. They would sometimes only list, you know, pro-Federalist articles and newspapers. If newspapers issued anti-Federal articles, people would stop their subscriptions. They'd get threats. Sometimes the newspaper buildings would be ransacked. I mean, that's one way of persuading them to stop, basically.    Yeah, and so in a sense, you know, with Google or other, you know, okay, having favored searches or when you type something into favored website, oh, you get a totally different perspective, at least now, you know, it's a lot easier to convey information. You know, before you only had newspapers or pamphlets and it was a lot harder. So it's interesting to note that the media has always been an instrument, basically, of propaganda for big government. It's always been basically pushing that. It was something sort of a theme you sort of read in Rothbard.  One last point that I'll mention is sort of another project involving the Rothbard archives, working on with Joe Salerno. Sort of there was a book that came out a couple of years ago called Strictly Confidential and had some of Rothbard's writings on, you know, when he was for the Volcker Fund about economics, political philosophy, but, you know, political science history. We're working on sort of another volume that sort of has more of Rothbard's economic writings.   It still shows, you know, a great writer. He still gets some citations, obviously by Austrians and libertarians, but also by mainstream scholars and he still, the ideas he talks about has enormous influence in their, you know, they're very inspirational. And so this is basically why you should all read Rothbard. Thank you very much. Subscribe to Mises Weekends via iTunes U, Stitcher and SoundCloud, or listen on Mises.org and YouTube.


So, let me tell you about the work I've been doing over the past few years with Lina and Prakash. This work aims at generalizing by simulation from discrete time processes to continuous time Markov processes, and we ended up with a bunch of behavioral equivalences. So the first question is what do we mean by continuous time? The well-known label Markov processes and Markov chains are step-based processes. So in the case of L&P, you're in a certain state, you do a jump every step, and you end up in a new state with a certain probability. In Markov chains, there is a clock associated to each action, and you have a generalized clock that synchronizes all those clocks. When one clock reaches zero, the process does jump and re-initializes the clock associated to that action. These are normally called continuous time Markov chains, otherwise they do not have that clock business going on. So whenever I say Markov chain in this talk, what I really mean is continuous time Markov chains. So in both cases, it's very based on jumps happening at steps. However, in continuous time, we do not have next steps, but we have two transition functions that correspond to this notion. The first one is maybe looking more familiar with respect to L&Ps, and it tells you what is the probability in time t of going from a state x to a set c. The other one, which is kind of new here, pxb, b is a set of trajectories, and this one tells you what is the probability that a trajectory starting from x is in the set b. There are, however, key differences. You could think, okay, we're just going to make the time very small, and the distance between each step very small, and we'll end up with the same thing. It's not the case. Let me illustrate this on entry points. So in discrete time, it's very simple to be talking about entry point. Here you see in two steps, my process enters the blue area. In Markov chain, it's a bit similar. I'm spending five seconds in the first state, then 25 seconds in the second state, and then I reach the blue area. So I need 30 seconds to reach the blue area. In continuous time, well, it seems to be fairly obvious. I'm starting on the left, I'll reach eventually the blue area, and this tells me what my entry point, entry time is. In discrete time, it's also very convenient to define second entry times. You're just waiting for the step where you enter, then the state where you exit, and then when you re-enter. So in this example, it takes me five steps to re-enter the blue area, enter, exit, enter. And similarly, with the Markov chain, each state, I spend a certain amount of time in that state. I just add up all the different times, and if I'm not mistaken, it takes me one minute and five seconds to re-enter the blue area. Here in continuous time, in my example, at time t1, I enter the blue area, at time t2, I exit the blue area, and at time t3, I re-enter the blue area. So it seems fairly simple, right? Well, not so fast. Obviously, there are times when this is harder. So for instance, now the boundary is not in the blue area, and at time t2, the trajectory is exactly on the boundary. So it exits and re-enter right away, the blue area. So what would be the second entry time of this process, of this trajectory, sorry. So you could expect it to be t2, however, I would argue that it is t4. And indeed, what you would want to do in that case would be to define a black area that's inside my blue area, and a green area that's outside. And you would have that thickened border, and you would consider the, so the second entry time you would consider when the process goes from the green area to the black area, then from the black area to the green area, and then again into the black area. So that would be in that case t4, and not t2. And finally, another not. So in 20th example, here you have a trajectory that reaches the blue line at time t1, and then weagles around the blue line. And here you see that the second entry time would be t1, and the third one same and same and same. So this is not something that you would expect to see in an LMP or a Markov chain. So these, these example give us hint that continuous time doesn't behave quite like discrete time. So the second term that's in the title of my talk is behavioral equivalences. By simulation in discrete time, we have two conditions. The first one is based on the fact that we have atomic repositions with distinguished particular areas on the state space. So in order to be by similar, we want to have the same atomic repositions. And then we have the very familiar induction condition x and y is if they are by similar, then after a step, their probability of reaching our closed sets equivalence classes are exactly the same. Let us look at an example, random walks. We have a state space, which is the integers, and a Markov kernel. That Markov kernel tells me that if I'm in the state n, with probability one-half, and I'll do minus one, and with probability one-half, I'll do plus one. So in that example, when our two states n and m by similar, well, zero is singled out, and then I look at the probabilities of reaching zero in n and m steps. If these are not equal, then n and m cannot be by similar. Indeed, if I look, if n is strictly less than m in absolute value, and I look at the probability of reaching zero in n steps, then from n, I have a nonzero probability of reaching zero in that amount of steps. From m, I have zero probability of reaching zero in that amount of steps. So I end up with n and m are by similar if and only if absolute value of n is equal to absolute value of m. I have to prove that this is a batch simulation, but it's fairly simple. So this is my first example. We can now move on to continuous times.  Well, if I take random walk and I make the time between each jump and the distance between each state, increasingly small, then I'll end up with permanent motion. So the state space is the real line. Zero is still carrying an atomic proposition, so it's still singled out. But the dynamics of the system is a diffusion-like. It's exactly actually a diffusion. So after time t, my probability of being in a certain set is given by this density function, which really tells me my best estimate is still x on my process. However, how certain I am of what my process is kind of fades away with time. So this is the reasoning that showed us that n and m can only be by similar if they have the same absolute value. Can we adapt this to brilliant motion? As I said, zero is still singled out. This works if I feel the same. We have no reason of changing the initiation condition up early. But the question is, how do we replace steps? Well, there's a fairly simple solution. We just say, let's let time t go by. However, there is a big problem with this. And if I start in any state, and I wonder what is my probability of being in zero after time zero, then this is zero. You have a zero probability of being precisely in zero at time t starting from z. So we end up with just two equivalence classes, zero, and the non-zero reals. This is indeed by simulation if I generalize by simulation that way. So let's just call this attempt not a success. We cannot just replace steps by time steps. But I could have rephrased my question slightly differently. I could have asked, what is the probability of having reached zero between the kth and the k plus one steps? Or what is the probability of having reached zero at some point during k steps? And here you see that you are starting to see entry times in the picture. So the thing is, we need more than just a single time step. We need actually to have more information. We need trajectories.  By simulation circled in red here is the notion that we introduced in 2019. We thought at the time that it was analog of discrete time by simulation. However, we realized later on that we didn't understand well enough what happened to trajectories. And now we realize that it's not quite right. A very exciting notion is that of group of symmetries also. Because most of our examples exploit group of symmetries. There are really a bunch of functions that need the dynamics unchanged. So this is pretty exciting. I'm not going to give any details in this talk in formalism. I would rather refer you to our paper, which is carefully detailed and technical. We used fellow dinking processes, which is a class of continuous time processes. That are crafted to account for a wide range of continuous time markup processes. So if you remember discrete time by simulation, I had the initiation condition, which tells me that if x and y are by similar, they have the same ops. And the induction condition that is stem based. So where are we going to put trajectories in here? Well, if I put trajectories in the induction condition, this is the definition of bisignation that we gave in 2019. As if we put trajectories in the initiation condition, this is going to give us temporal equivalence. So first, bisignation, as I said, we do not change the initiation condition. If x and y are related, then they have the same observables, the same atomic propositions. And the induction condition becomes a condition on the trajectories. So if I have a set of trajectories that are closed, so since it's a trajectory set, we call it time are closed, then the probability of having a trajectory starting from x being in that set is exactly the same as having a trajectory starting in y being in that set. For temporal equivalence, we keep the induction condition from discrete time, but instead of just being a step, it is a time t step, but we change the initiation condition, which amounts to trace equivalence. So if we take a bunch, a set of states that is time ops closed, so instead of being r closed as before, it's having the same observable, then x and y have to agree on that set. And we end up with a bisignation is a temporal equivalence. And if two states are temporal equivalents, then they are trace equivalent. Note that we can have several bisignation and temporal equivalences, but there's just one trace equivalent. Let's illustrate that on an example. In particular, the first example is interesting because it gives a counter example to trace equivalence implies temporal equivalence. So the first arrow cannot be reversed. And it's the fork. So here you have the state space. On that state space, I have a deterministic drift process that goes from left to right. And when I have a fork, the process with quality one half goes up and one half goes down. I have two atomic propositions, the blue one, which is at the end of the upper branch and the black one, which is at the bottom of the lower branch. And here you see that the two states that I have marked intuitively, they are by similar. It makes sense, right? And indeed, if I replace the orange branch by the other orange branch, I won't see any differences. And similarly, if I exchange the purple branch with the other purple branch, I won't see any differences. However, you can see that the point that's right at the fork in the upper section cannot be by similar to any point in the lower section. And this shows that x0 and y0 cannot be by similar either. This is actually, if you have recognized it, a generalization of the vending machine example. And why is this interesting in this case? It's because x0 and y0 aren't, they're not by similar. They're not temporarily equivalent, but they are trace equivalent. Let us look at another interesting example back to thrown in motion. But this time, the atomic propositions are on the integers. So you're not able to tell which integer is, but you're able to say, oh, it's an integer. And here, intuitively, you'll realize that what makes the difference is the distance to the closest integer. So two states are by similar if and only if they have the same distance to the closest integer. So proving that this is a bisimulation is not that tricky, or proving that the greatest bisimulation is trickier. However, there is something very interesting happening in the computations that this is a bisimulation. First, we realize that if we just shifted everything by an integer, this isn't changed. The whole process isn't changed. Similarly, if we do a symmetry around an integer, this is also, this leaves the process also unchanged. And similarly, if I do a symmetry around a half integer, the process isn't changed at all. And this has led us to the definition of group of symmetries. A group of symmetries is a group of homeomorphisms on the state space that commute with ops. So here you see that I do not change the value of the atomic propositions satisfied by a state. And it leaves the dynamics of the system unchanged. So let me advertise our paper a bit. There are a lot of open questions still. For instance, we do not know if temporal equivalents and bisimulation are equivalent or not. I personally believe they are equivalent for a surgeon class of processes. But in the paper, we do give a game interpretation for basimulation and temporal equivalents. We provide a lot more example. And maybe more interestingly, we studied that relation to discrete time. And this is where we actually realized that actually temporal equivalence is the notion that best extends bisimulation from discrete time to continuous time.  The first of which is understanding sets of trajectories. It is really technical and hard. We're also interested in finding relevant metrics, bisimulation metrics, temporal equivalence metrics and so on. And also the philosophy of the clock. So we think that we can say a lot about just by looking at clocks, like when is a process entering something, exiting something for as much as we can define those notions. However, these are still open questions. Thank you for listening to this talk to the end. This is a very technical subject, as all our reviewers have noticed. But it is very subtle and very, very interesting. So I hope I have managed to share this with you and that I'll have made you want to read our paper. Thanks a lot.


With Meg giving birth and Lois cheating on Peter, Family Guy has slowly but surely paved a different path over recent years, and that is more than likely directly due to one particular man, creator Seth McFarlane, stepping away from the writing staff and coming in solely to voice his iconic characters. Since then, McFarlane has delved into many other creative ventures, movies, more television, jazz, and most recently the number one peacock series, Ted, based on the movies of the same name. But was all this at the cost of his breakout series? Back when I was a kid, I used to stay up on a Wednesday night to watch The Simpsons followed by Futurama, The Cleveland Show, American Dad and my favourite part of the night, a double app of Family Guy on a weekly TV event they called here in Australia. I'm only realising now how many of these shows came from McFarlane. Out of Seth's cartoons, the short lived Cleveland show had its moments but more so American Dad, which has carved out a loyal following of its own and rightfully so when they have a character like Roger. But Family Guy has been through every stage of popularity you can possibly imagine, from cult classic, to cancelled, to popular, to cancelled again, to pop culture phenomenon, to meme, to hated meme, to regaining a decent popularity on newer seasons on TikTok, and of course Fortnite. But let's rewind from current day season 22 back to season 9 when McFarlane left the writers room on the show and the show saw a polarising change in direction. As mentioned we've seen Meg get pregnant and give birth as a surrogate for Bruce and Jeffrey, Lois is no longer unconditionally loyal to Peter, and we even saw Brian die for half a season, which in itself wasn't a bad idea and was actually quite a beautiful send-off. But it had two glaring flaws, one was Brian's replacement Vinny being more obnoxious than Brian can be at times, and then they backpedaled the whole thing in that year's Christmas special. Brian being brought back to life by Stewie and Seth McFarlane saying, and thus ended our warm fuzzy holiday lesson. Never take those you love for granted for they can be gone in a flash. Since then there have been a bunch of characters who have been recast or shunned all together as they didn't necessarily age well. Peter has had more than three new bosses and there's a new nemesis for Stewie, Doug who adds absolutely nothing to the show. A newer character that I do like though is Joanna, but they later retconned her and named her Elle just to make a World War 2 joke which was odd. The giant chicken even got an episode fleshing out his story. Since the death of the incredible Adam West or in the show Mayor Adam West they've introduced Mayor Wild West who really just feels like a placeholder and the hook for most of his jokes is that it just sounds funny when an old man with a deep voice says modern things. But if The Simpsons is anything to go by, unusual semi-permanent plot choices is what can happen when you are 22 seasons in which is no small feat in itself. All this to say the show isn't without some newer memorable episodes. Some personal favourites that come to mind is season 21 episode 4 The Munchurian Candidate which went viral in the scene where Lois catches Peter accidentally hypnotised into sleeping with her mother. And season 20 episode 17 All About Alana which guest stars McFarlane's personal friend and real life singing partner Liz Gillies even featuring some snippets of their duets. Which leads me to Seth's other projects which began after him leaving the writers room to work on Ted One, A Million Ways to Die in the West and Ted Two. The first Ted movie really being the only one that's stuck in the minds of Family Guy fans which is a shame as I personally love his other two movies, especially A Million Ways to Die in the West, a star-studded western parody where McFarlane just basically plays a modern day man complaining about his life in the Wild West. But anyone who has seen more than a couple of episodes of Family Guy is very aware of McFarlane's love for show tunes and the great American songbook and being able to perform them beautifully. This led to passion projects which include multiple solo jazz records and more recently with Liz Gillies releasing a record during the pandemic entitled Songs from Home. Again this past Christmas with We Wish You the Marriest, continuing performing together right now in Vegas. But since Family Guy and before the Ted Prequel show, Seth had or maybe still has a Fox and Hulu show The Orville, McFarlane's more serious brainchild which is more or less his version of Star Trek, his passion for the show also being obvious in many episodes of Family Guy. The Orville is a great show too, way more wholesome than you've come to expect from a McFarlane show, in a good way though. It covers important real life political concepts and has a great cast of characters including the principal from Ted and more notable the dad from Ted, Scott Grimes, who you may also recognise as Steve from American Dad and you'd never guess it from Ted but he also has the singing voice of an angel. But filming for the third and most recent season of The Orville was interrupted for a significant period due to the pandemic and a fourth season has yet to be officially confirmed, which is a shame but the third season did provide a relatively satisfying wrap up for most of the story arcs. So in the meantime, Seth shifted focus once more as Peacock came knocking wanting to green light a seven episode prequel series showing the high school years of John Bennett and his foul mouthed bear, capitalising on the success of the 2012 film of the same name. Now this series felt like a true return to form for Seth McFarlane style comedy and really is a live action family guy, the witty and ongoing small talk, the offensive yet well written one liners and my personal highlight, the totally unhinged side characters actually played by the side characters of Family Guy by the way such as Mike Henry who previously played Cleveland before being recast but still plays a spattering of others and John Viner one of the funniest and most recognisable voices in Family Guy, I've always loved that Seth sprinkles in his familiar colleagues in almost all of his shows, the fresher face cast fit right in here too, the mum was an absolute scene stealer and I feel the whole family really had amazing comedic chemistry from start to finish. From a full length film to a television episodic format with almost an entirely new cast, Ted managed to transition perfectly, due also in part to being a 20-40 minute time frame you can really watch as much or as little as you'd like and it never overstays its welcome. On a more technical level the CG on Ted is absolutely incredible, the fact the actors performed alongside really nothing and made it seem like Ted was genuinely in the room with each of the characters is an amazing filmmaking feat, a credit to the Australian animation team Framestore in Melbourne for composing the VFX. Composing the musical score was another friend of McPhail and Walter Murphy who Seth worked with not only on the Ted movies but also does the music for Family Guy, specifically the little play-ons you see in the establishing shots which is Signature Family Guy. Since the series became one of the highest streamed series on Peacock in just a weekend, Seth has said himself that if there's an appetite for the character he will do more and I think the ratings speak for themselves at this point. But does this show have enough momentum to become an instant classic? Could this become a syndicated series that will be rerun for years to come? If the quality of writing keeps up then I don't see why not. But what do you think? Let me know, I'll be down there in the comments. You can also see what I'm watching by following me on TikTok, X and Letterbox which are all linked in the description. But if you haven't already be sure to subscribe for videos covering the best and worst of movies, television and pop culture. If you subscribe during this video then welcome aboard and if you had a good time hanging out then SPANK that like button. This is Matt Rogers and that is all.


Welcome to the Mac RubyMotion presentation. I'm very happy to be here today. And just one thing, I really like Seattle, so it's a very nice city.  So I can't go to each of them, so we need to return eventually. So yeah, this is a presentation about RubyMotion. Just a few things about me. Yeah, Shane just said it, but I'm a longtime Ruby enthusiast. I've been using Ruby for about 10 years. Before doing Ruby, I really liked Per as my favorite I-level language, but I realized Ruby was a better alternative. So I decided to stick with Ruby. And I work on a few things about Ruby, like the Ruby GNOME 2 bindings, which are Ruby wrappers for all the APIs of the GNOME desktop. Then I did Ruby Cocoa, which is the bridge between Ruby and the Mac runtimes. I did a bridge between Ruby and Apperscript called Ruby OSA. I think it's dead now, and you shouldn't use it anyways. But when we did Ruby Cocoa, the goal was to make sure that you could write full Mac applications in Ruby. But it turns out that it wasn't possible with Ruby Cocoa, so there were so many problems, performance and stability issues, just related to the fact that it was a bridge, some sort of middleware between two separate frameworks. So I stopped working on Ruby Cocoa and I did Mac Ruby, which is supposed to be a better Ruby Cocoa. But Mac Ruby is different in the sense that it's a true Ruby implementation on top of Objective C, so it's no longer a bridge, so it works much better. Yeah, I'm a programming language nerd, so I like programming languages. I really like that. My last employer was Apple. I worked for a few years there on iLife, OS then. I work on the Unix layer, so it's basically what powers Macs and even iOS devices these days. Yeah, I was responsible to introduce Ruby Gems in Leopard, but I'm not responsible for the fact that Mountain Lion ships with Ruby 1.8, so it's not my fault. It's not my fault, so you need to blame the other guy now. But I left my job at Apple to do a startup. I left my well-paid job in Silicon Valley to do a company, which is crazy, right? But yeah, it reminds me of what Shane said yesterday. So quit your job and do something better or different. So if you're working for your employer and you think you can do something different, I think you should take the chance and do it. Especially a startup is very, very funny. So Ruby Motion. So I think that you guys probably heard about Ruby Motion. How many people heard about Ruby Motion here? Okay, there are people who don't know what Ruby Motion is. So, Ruby Motion is basically Ruby in your pocket. So that's the title of the presentation. So it's basically a toolchain that lets you write applications for iOS devices, such as iPhone or iPad or even iPod Touch, but using Ruby, only Ruby, exclusively Ruby, so no other languages. So why would you want to do iOS applications?  You probably use Rails on a daily basis. So why would you want to do mobile apps? Well, it turns out that it's a very recreative market. At the latest WWDC, Apple announced that they sold more than 365 million iOS devices since the very beginning. They also say that there is something around 400 million iTunes accounts. Of course, there are more iTunes accounts than iOS devices because people use iTunes on different platforms. But I think it's safe to accept that most iOS devices are actually connected to the iTunes store, to the App Store. So there is a huge market and a huge opportunity to create applications. And because of that, there is a huge demand for iOS developers, especially in the considerate business. At the same time, it's also possible to make pretty good money just by working on applications, publishing your apps in the App Store. And the great example is Paro. It's an email client written by friends of mine in France. So they sold the company to Google. But their investors leaked some information on Twitter. They said that Paro was generating something like $60,000 per month, which is nice for an email client. So it's perfectly possible to make pretty good money just by doing applications of the store. And there is no technical reason why Paro could not have been written in Ruby with RubyMotion. So what RubyMotion is basically Ruby as a language, but we implement it on top of iOS. It's also statically compiled, so it's very different from the Ruby implementation you probably use today. The entire tool chain is actually based on the terminal. So there is no UI. You don't need to learn anything new. You just get to use the terminal. And you also keep using your favorite editor. So it doesn't come with an IDE. So that's actually a design goal. And finally, there is an amazing community. So I'm going to go through these five points very quickly because we only have 30 minutes. So the runtime. A very interesting thing about RubyMotion is that both RubyMotion is Ruby and Ruby and Objective-C are actually using the same technologies, the same foundations. So what does it mean is that when you reuse RubyMotion, when you create a class, it's actually going to use the same machinery, the same foundations as if you create a class in Objective-C. So a class in Ruby is the same thing as a class in Objective-C. It's actually using the Objective-C runtime under the covers. So when you create a method in Ruby and you pass an instance of that class, that would respond to that method to an Objective-C API, the Objective-C API can call that method as if it was written in Objective-C. So there is no bridging thing happening. Everything is truly native. And at the same time, the building types of Ruby, such as string, array, and hash, have been rewritten on top of foundation types. Foundation is a framework that ships with iOS, and the framework comes with basic types like NS strings, NS arrays, and NS dictionaries, which are the same thing as array, string, and hash in Ruby. But in RubyMotion, we decided to rewrite these classes based on their foundation counterparts so that when you use an API in Objective-C that expects an industry, you can simply pass a string to create in Ruby. So again, this is really for performance reasons. So we don't want to convert objects when you try to use the APIs of iOS from Ruby. And this old design is actually, I call it the unified runtime. There is only one runtime. When you use RubyMotion, it's the Objective-C runtime. So it is very different from bridging technologies where you tend to have a different programming language with a different VM, a different garbage collector, a different set of classes, and a different object model. And then you get the native platform that you want to access. And this is very similar to our experience with RubyCoco. RubyCoco was that sort of thing. It was a bridge between MRI or CRuby, which is called these days, and the Objective-C runtime. It was very painful to keep both object systems alive at the same time, and caching objects when you cross the bridges. And here with RubyMotion, it's really native. So an application written in RubyMotion is truly the same as an application written in Objective-C. If you look at the code that's generated, it goes into the same APIs at the very end. But you would say, why should I use Ruby? I mean, if there is already Objective-C, you could just learn Objective-C. And the thing is that Ruby is much more concise. Well, I'm not going to explain that to you. You already know that. But this is a very basic award in Ruby, a basic class, and with an accessor, and you can initialize the class, and then you can code the same method. And the same thing in Objective-C would have been written like this. As you can see, it's already twice the code, more or less. For about the same thing, I mean, just printing a message in the terminal. So there is a lot of boilerplate code that you need to write when you create a class, when you create an accessor. Of course, you also need to keep two separate files, one for the interface and one for the implementation. And it can get very bloated even if it does only the same thing, like this NSLog method at the very end. We have users of RubyMotion reported that they actually converted their IS applications from Objective-C to Ruby, and they say that generally they get rid of 50% or 60% of the code at the very end. That's only when using the same API. So that's not even using a DSL or a library, just using the same APIs, like removing all the craft or the boilerplate code that Objective-C forces you to write. So that's a very cool example. So RubyMotion lets you call into the Objective-C APIs, natively, but you can also use C APIs because they are pure C libraries and frameworks in iOS. And one of them is OpenGL. OpenGL is purely C, so there is no Objective-C stuff there. And that's an example of RubyMotion calling into OpenGL. So I haven't written this because OpenGL is very... I can understand OpenGL. It's very tough. But so basically what's happening here is that it's actually calling the same C functions of OpenGL, but from Ruby. So this glclear color is actually a C function that you can call it as if it was a Ruby method. The compiler is going to generate some sort of stub that we call the C function. And the constants that you see, like gl underscore color underscore buffer underscore bit, it's actually a C enumeration in the header file of OpenGL. So if you're familiar with a C, it's actually described in the header files of OpenGL. But it's available in RubyMotion as a Ruby constant. And then you have all these magic things like... Sometimes in OpenGL you need to pass a magic cookie, which is a value, and you cast it into a VoidStar pointer. So I'm not going to explain, but it's basically a hack to pass some magic value into the real pointer to an object. And in RubyMotion you can use the pointer magic cookie method to do that. And so the whole thing is working. I think it's a very simple game that shows a cube that rotates and you can click on it and it divides and some sort of things. But it works so. I was very surprised to see people using OpenGL in RubyMotion. So let's take a look, let's talk about the compiler now. By the way, this is the LVM logo, which is the most awesome logo ever. Awesome, right? So basically it's called static compilation. I think that Remotion is probably the only Ruby that is statically compiled. Maybe, I don't know, yeah. It's one of them, at least. So the idea is that we take Ruby code and we generate machine code at the end. And the machine code is completely pre-compiled. There is no more evaluation, interpretation when you run the code. And everything is self-contained. So that's the goal. And in RubyMotion, applications are always statically compiled. So when you use an RubyMotion app on your device, it's always going to run the code that you wrote and you cannot evaluate code at runtime. We disabled that for, actually, for a reason because I'm not really comfortable with the Apple guidelines about that. So it's basically that it's really all statically compiled. But how does it work exactly? Well, it's Doug's programming computers. Well, no. So I'm going to explain a little bit. So first we start with Ruby. So here we can create a class, HelloView, which inner is from your issue. It has a method. That's RubyText, right? And the compiler is going to process the code into a syntax tree. So a syntax tree, as known as the AST, is basically a huge tree of expressions inside the code. So here, for instance, we have... So here it's basically an array. I'm using Ruby here as a representation syntax, but the compiler is not written in Ruby. It's basically an array. So we have a class, HelloView, then we have a superclass, then we can... Well, we have a method, so it's a DefN. We start with a new DefN tree. So it's a tree of trees. And then we have the drawWake symbol, which means that we are defining the drawWake method, and it goes on. The entire code is compiled into this data structure. If you're not familiar with ASTs, there's a gem called parse syntax, parse tree. No, parse tree, yeah. I think it was written by ZenSpider. It should be somewhere here. Okay. You mean the... You mean the 1.9 extension? Okay. There is a... Okay. Anyway, if you want to play with ASTs, there are gems, and they will give you these kind of things inside IRB, so you can see how Ruby is actually compiled under the scene, so it can be interesting. So then from the syntax tree, we actually convert it into LVM IR. So IR stands for Intermediate Representation Language. So we are actually going to compile the syntax tree into this language. So LVM has its own internal language. That is... So it let us... So it's basically an assembly language, but it's a platform or architecture agnostic, more or less. So we actually implement the syntax tree using this language. And first, the great thing about LVM is that there are so many optimization passes that you can apply on the IR. LVM comes with a huge load of optimization passes, and we apply a great deal of them. For instance, we can eliminate that code. We can reorganize if statements. We have... We have optimization for constant lookups, instance variable access. So we wrote also most of the optimizations, but we can actually reuse a lot of LVM ones. We also have an optimization for a... which is called TCO, a tail call optimization. So if you have a method that ends with a call to the same method, we are actually... We remove the call and we actually jump through the beginning of the method. So you can do a functional programming in RubyMotion, which is great. But the great thing about the LVM IR is that it's agnostic. So from it, we can target different platforms. And so we only target two platforms, Intel 32-bit, which is a platform when you run the simulator, and ARM for the devices. ARM versus 6 or 7. So we get assembly there, and so I'm not going to explain what it is. So it's basically a machine code, and it's compiled to machine code right after. So at the very end, you get true machine code from your original Ruby source code. So, yeah. So this is an app I wrote with a friend. It's called Mustachio. It's a very basic app that actually uses face recognition, and the API is in iOS to add a Mustachio to all the faces it can find in a picture. This is my kid, by the way. This is my son, Alexis. Sadly, the application is no longer in the App Store. Not because it's written in Ruby, but I forgot to renew my Apple account. So I actually used my wife's account for this app, and I forgot to renew it, so they removed the app. Which is weird, right? I mean, I didn't even got an email saying, well, we'll remove your app. So, anyway. So I'm going to resubmit it, but you can find the source code on GitHub. But the most interesting thing about this app, at least in this context, is the application size. So perhaps you can't see it, but the size is 0.9 megabyte. And it's a RubyMotion app that ships with runtime and all the source code of the app. So this is really great. So you can...  So let's talk about the tool chain now. The tool chain is all based on the terminal. So you get to use the terminal to create new project in RubyMotion. And then every project is based on rake. So there is a rake file, and if you want to change the configuration of the project, you just edit the rake file. So it's very simple. And then the rake file has a few rake tasks by default. And one of them can push the application on the simulator so that you can see in real time what's happening. You can also push the application on your device if you have an iOS device connected for development. With USB. Or you can create an archive, an IPA archive for an app store submission. But it's all based on rake. Sorry.  What about Xcode? I'm not sure if you guys know what Xcode is. But basically Xcode is Apple's IDE. So it's basically the IDE Apple wants you to use for iOS development or Mac development. So it's actually a great IDE for Objective-C. It's very nice. It's re-optimized for Objective-C.  It's very sad to say that. First, the editor is not extensible, so there is no way to add functionality. There is no debugging support for Ruby or other languages in Xcode. So if you want to write a Ruby debugging Xcode, you can't. There is no plugin interface, no API. The Ruby support of Xcode is also very poor when it comes to syntax. It's very, very bad. I'm pretty sure they use regular expressions to colorize the source code. I don't know. For instance, when you have a Ruby file in Xcode that has a regular expression, and inside the reggaps you have some sort of keyword that's defined in the Ruby language, like if, then the whole source code would be messed because Xcode, we think that the if token inside the reggaps is actually a statement in the syntax. Sorry about that. Anyways, we don't think Xcode is a great environment for Ruby, which is why we prefer people to use their own editors. And at the same time, in Xcode, you get to use the IDE to create core data models and user interfaces. So there is a way to use Xcode to create the database of your application, which is based on core data. So basically you can create the tables with your mouse. You can create the fields inside each table, the relationships. And at the end, Xcode will generate a binary that will ship inside your app. And the binary will be parsed at runtime by core data. And the same thing happens with user interfaces. You can use interface builder, which is some feature of Xcode. And you can create the UI with your mouse. You can drag views, create actions and outlets to connect the UI with your code. And then at the end, it generates also a binary that will be parsed at runtime by UI keys. But I'm not really comfortable with that because it's a binary. There is no way to see what's happening. I mean, when you put it in source control, it's very easy to break things. For example, it's very easy with your mouse to forget to disconnect something and then you just break something. It feels very magical. Like this. I have been using Xcode for a very long time. Before it was even called Xcode. It was called Project Builder. And I always feel like this when I had to use interface builder or core data. It feels too magical for me. I prefer to see what's happening. So that's why it's perfectly possible to use core data or to create user interfaces programmatically. And I think Ruby is a great language for that because Ruby allows layered abstractions. You can easily create domain-specific languages. And at the end, you can very easily create very complex UIs in code. Or you can also create database entities in code. The perfect example, of course, is Active Recorded Raves. You guys don't use an interface to create the database. You can use Ruby directly. Oops. Ah, yes. And it wouldn't be a real screenshot of Xcode without the crash window. Because it crashes all the time, sadly. So in Ruby Motion, you get to use the editor you really like. So personally, I use Vim. But they are support for all the editors. And if you go to the developer center, you will see that you can install plugins to have, for instance, auto-completion of the APIs. The iOS SDK, I mean, these APIs were designed for Objective-C. So they are super long names. And it can be very tedious to type all the characters. So they are plugins to have auto-completion. There are also plugins to interface with the tool chain so that you can, with shortcuts, run the simulator, push on the device. So it can be very handy. So they are very support for Vim, but also for a text mate, sibling text tool, which is another editor. Red Car, that's the fourth one. It's actually very nice because it's a Ruby editor written in Ruby. Using G-Ruby. So if you have never used Red Car, I recommend that you give it a try. It's all open source, and it's very nice. And then there is Emacs, which is some sort of operating system. So it's not an editor, I don't know. I have never used it because my... I never had a computer fast enough to load it. Well, I just got... So we use Emacs. Yeah, yeah, yeah. I don't know. I just got SSD, so maybe I can try it now. No, I'm joking. Well, there is support for RubyMotion in Emacs, if you really like it. But Vim is much better, I think. No? Anyways. So there is a huge community around RubyMotion. It was very amazing to see so many people using it because that's nice transition. There is more than 500 projects on GitHub. So most of these are samples. People are just working with it and doing a set of things. But there are also libraries, DSLs, and for instance, the support for these text editors were written by the community. So that's really amazing. So I'm going to show a few libraries or a project written by those folks. And the first one, which is very interesting, I think, it's called T-Cup. So it's a DSL to create user interfaces with RubyMotion. So they follow the CSS way of styling the user interfaces. So they created a DSL to style basic elements like text fields, search fields, and so on the first part of the code you can see that they provide a custom style sheet for these elements, and then at the second part they create a view controller and then they can apply the style sheet that they defined earlier. So I assume that it's going to use the same style there. So it's very interesting and their DSL is actually very... I don't think it's mature yet, so they are still iterating on it. Okay. So the RAP is another project. It aims at wrapping all the iOS APIs using Ruby. It aims at providing Ruby abstractions, so that's what I was talking about. In this very specific snippet they wrapped all the HTTP and the JSON support of iOS in Ruby. So it feels like Ruby. When you read this, it's actually using the iOS APIs. So it's a library, it's a layer on top of iOS. So it can be very convenient and they have wrappers for a lot of things. So double wrap. Another one is for motion. It lets you write this kind of UI which is very common on iPhone applications. And if you want to write this by hand, it's super hard. You need to create a table view with custom cells and if you're familiar with iOS development you know that it's very hard. And some guy created this DSL which looks like a hash. It's basically a huge hash and then it generates what's on the right side. So it's very cool. And I don't think I would have time for the demo, I'm sorry. But if you can, if you have any questions you can ask me or I can show you a demo later. And that's all. RubyMotion.com