What's up, guys? In today's episode, we're going to take a look at Google Material Design, how you can build beautiful products faster. I'm going to go over it as quick as I can, and don't forget to stick around to the end.  Let's go. What's up, guys? In this episode, I'm going to give you the quickest overview of material.io that I possibly can. So let's get straight into it. Links in the description. What is it? Material Design is a design language created by Google. So we know in all these big companies at the moment, there's design languages going on. I helped develop the ones for Barclays. And what it is, as a designer, you'll go into these companies, and you won't be able to go in, change the buttons, make Barclays red, or an example of anything crazy like that. All this work's been done. It's been the zone to keep, I guess, the whole thing in sync. So you're going Android. It'll be a better user experience because everything will be the same. This is Google's version of it, heading over to material.io. That's the website. And it's good as a designer to understand all of these things and to understand what it's all about. On the website, they've gone through a lot of pain in creating really, it's the best documentation in class that I've seen. And what they do is they tell you everything about Material Design, what it is, and how you can get started. So you can go in, you can see what's new. So what's new this month is they've got a new dark theme. So if you're making an app, dark theme is the hottest thing at the moment. They talk about all of the different colors you can use, how they break it down, they talk about where your toggle should be. And a lot of these things, I get people coming to me show me designs, and they say, hey, can you check this out? And a lot of the time people waste time really in reinventing the wheel on things just to be a designer. But a lot of things are designed thinking rather than design application. So you should be thinking about the user flow thinking about how your app works. You need to understand material designers of designer. And then the outcome is actually quite quick. But all of that knowledge gain takes time by reading stuff like this. And you know, by you checking out this overview, it's a good introduction to it. So we can have a look at what the foundation is first for material design and how the whole thing is based is based on real world physics. So a lot of it is to do with depth. So there's different layers on the applications and those layers cast shadows. So it's not 3D, but it's it's more like drop shadow ish. If you go on here, you can see how when things are elevated and on layers above other things, the shadow acts like it does in real life, they did a lot of research into this. And it's something that you really need to understand all the dos and don'ts about how things are on in the physical life here. Then they talk about elevation and how you know, when something slides over something else like a menu slides in, all of the shadows come into play and it's it's kind of like science in a way. It's all the doing is it's trying to mimic the real life. And whenever you're designing something for Android, you should really check it out. And before I say that, if you want to develop for Android, check out Android Studio developer.Android.com. It's something that you can take these designs that you do in whatever format you put them in. It's got a visual editor in there. If you know a bit of code, it's something that you can it's something that you can definitely check out. So that's developer.Android.com. Then if we go in, we can have a look understanding the layout, how the grid works, how the pixel talks about pixel density on different, there's different resolutions or displays. It talks about how Android works all that out. So you can see if you design something, it's the same size on the different screens. That's something that Apple did quite cleverly. So I remember designing for the iPad one and then the iPad two came out and it was double the resolution of the iPad one. But that's something that Android have nailed here. Then they're talking about like responsive grids and how, you know, different, the same app can work for a tablet or a mobile, different sizes. So you've got your grids in here. Then Android talks about navigation.  Don't reinvent the wheel here because you just won't be able to use it anyway. So understand how all of these different menus come together and create a beautiful experience. Then we have color. So we talk about the different colors within Android Studio. There's different places you can go. So they've got this theme editor. As part of the resources, it's a plugin you can download for Sketch. So you can put it in, you can put your own colors in and it helps shape the identity of, you know, of material design. Like it's not, you're not all stuck to these greens and stuff that Google use. Like you can see here, changing the color palette changes the bottom and so on. Then you can check our components. So you can see things like all these top bars. You can see, you know, you can see cards, tables, you know, so much time I spend on figuring out tables, when I've been working in companies before, dialogue boxes, sliders. I mean, there's so much stuff for you to go in here and understand. And the fact that it's all been done for you is something that you should praise. You don't need to spend a year making something like this. But that is honestly the amount of time it takes figuring out things like menus and even simple things like lists, the amount of time that they've got into doing research for it, making sure it works, you know, buttons, they've got all the styles here. You know, there's little, it's quite cool the way you can, you can change it here so you can see what it looks like with an icon or not. That's all in material design. Then it's got its own whole type system. So whenever you're designed something for a digital device, you have type hierarchy. So H just means heading, you have heading one to six. And that's just your main headings on a website. So for this, you can see like these big titles are all probably H3 or H2. The main title on your page is a H1. And then you have body copy here, which is the main font. Then you'll have caption here, which is a smaller version and so on. You just need to learn all these, all these different styles, but you can download the fonts that Google use from here. They've also gone in, in this new release talking about sounds.  So you can, you can understand when to use sound on a website. Never really use it as a background. It's a bit too intrusive of someone's in work. They don't want French rap to be blasting out over the speakers like I did for a university project once, which yeah, I'll never use sound again. But you know, if you add something to a cart, maybe you can have a sound, which is a bit reassuring.  So you might not think about looking on it, but look at how this mail icon was made. First, they actually did it in real life. Then they looked at the lighting of it, because a lot of this is a lot of material design is lighting. Then they did this prototype and then they added color onto it. And that's how they got, that's how they got that design. So you look at it and you think it looks simple, but it's actually not on a lot of folk goes into it. And then here you can talk about how you can make your own design different shapes to use, where to put it. It's something that you need to know when you when you're creating things like icons. Then, you know, there's all about how to work with shapes. You know, different shapes can be used for different things like this cut out here at the bottom. Then they have these, you know, just different shapes are used for different things like this around the corner might be used to indicate someone's been selected or not. And they have a whole philosophy around there. You know, there's iconography as well. So you've got all your system icons. So don't bother spending time making a shopping cart. Google have their own version of that like here. They just have really simplistic ones. Don't make it look like a fun make it look more geometric. A lot of this is basic shapes, basic geometry. Other things to think about is how motion is used. So sort of the think about when you're designing these tools, you can add motion in now. So maybe try and make it as realistic as possible. So it helps your developers out. But, you know, they can't work magic. They have to work with the animations that Android Studio allows of them. And as a designer, it's good to understand all of that by checking it out here. And and then the last thing that they have on here is about interaction. So pinch and zoom, gestures, what, what type of things to do. So they talk about what to do, not do. So don't delay it. Like we've seen on a lot of these websites now where someone follows you around with delay. It's something that I really, I really don't like. They talk about indicating gestures. So little hides and stuff on a website.  It's something that is an unreal resource for you. If I was designing for Android now, I would spend a whole day or a week learning this. And then what I make at the end, it might take me a few hours to make. But compared to like spending a week messing around with it and half the stuff I won't be able to do anyway, I think that's a better time. So work smart, not work, you know, doctors work for the sake of it. Spend your time doing this research. And now what I promised you, it's going to save you loads of time. If you're working under Adobe XD, it's also got this for Sketch and for Figma. Going over, going over to Adobe's XD page, heading over to UI kits, material design, click get the kit, then open it up in XD. And what the good people at Google have done, they've spent the time and they've made for us designers all of these interactive things, all with layers, all beautifully done. It's going to send you so much time making a page.  It's all been laid out properly. This is something I spend weeks and weeks and weeks designing for different clients for their own versions. But if someone comes to you for an app design, bang, you've got all this done, change a few colours, then spend your time as a designer, thinking about how the system works, thinking about the design, rather than spending time fumbling around, remaking all this stuff. Great for university students. It's going to look great when you put it together in your portfolio. Guys, I hope you enjoyed today's lesson. Let me know in the comments what you think. Are you going to be using Google Studio? If you haven't already, check our school.antonycomboy.com. I've got loads more in-depth tutorials like this. There's a little course on there that will get you up and running in UX and UI very, very quickly and you'll get a certificate at the end.  So, go over there and check it out at school.antonycomboy.com. Think about subscribing to the YouTube channel. I'm going to be putting out lots more content like this. Let me know your content ideas below and until next time, keep designing.


Everyone had a bunch of issues with my mic today that I've been trying to work out. I just gave up. I'm no longer using a mixer, I'm just using my straight up mic here. So it might sound a little different. I'm running out of time to make a video though, but I wanted to get to this really quick today. If you joined us for last night's VP debate over at D Live, you know. It was fun, by the way. I'm thankful for everybody who showed up. It's always easier if you can share your pain with others, if you know what I mean. It was minus a couple good zingers by Pence. I found the entire thing to be pretty boring and it probably didn't change many minds. But I do think that Pence won the debate. And why would I say that? Well, just based solely on the reaction from the media, just the insane amount of like lobbying, the accusation of mansplaining, which is just something that's completely made up. It's not even a real thing.  And of course they did, right? That's what tells me he won. They think that he did well and they felt the need to circle the wagons for Harris because that's the media's job, right? And we're gonna get into that as far as fact checkers. And are they actual fact checkers? No, I don't think so. But before we get into this, give me 30 seconds for a quick capitalism break from this episode's sponsor, Noble Gold. If you worked for a company for years before COVID came around and you were let go, you might have left some treasure behind. Your old 401K or IRA could be worth thousands and it's still working for your old firm, not you. So if you're a bit uncertain about what the future holds right now, you should call the team at Noble Gold at 1-877-646-5347. And if that's not incentive enough, with each qualifying IRA, you'll get a solid silver, five ounce Apollo 11 coin, free. So it's worth jumping on the phone and calling<PHONE_NUMBER> now. That's<PHONE_NUMBER>. So let's get right to it. I'm not gonna cover all the fact checks because there's a dozen fact check articles out there from different networks and a slew, maybe 12 fact checks. So I'm not gonna go through all of them. And the main reason why is because once we start digging into why these fact checks are complete fraud, it pretty much discredits the entire thing. So I mean, it's not even really worth looking at at that point. Now, when I say that these fact checks are fake, what I'm really saying is that they're not really checking facts. There may be like one or two legit fact checks and then the rest are just like PR spin from the Biden campaign. I mean, these fact checkers really may as well be part of the Biden campaign. So like I said, maybe there's like one or two legit fact checks in there. I'm not saying that politicians don't lie, of course, but then the rest are fake. It's the best lies have an element of truth to them. So I've gone through all these supposed fact checks as you can see there now. And it's all the major media organizations here. I got USA Today, AP, CBS, WABC, the BBC in there. And that'll be something special about all of this involving the BBC. And then of course we have CNN. And let me just be clear here. I'm not saying that I think Mike Pence is incapable of lying or being misleading. All politicians are unworthy of unearned trust and should be scrutinized. So that's not my issue here. Fact check, legitimate fact checks of Mike Pence all you want. But that's not what we're seeing here. No, no, that's not what we're seeing. Pence is being scrutinized to the point that most of the fact checks look more like what you might hear from a Biden campaign spokesperson as a guest on the Brian Stelter show. And a great example of what I'm talking about when I say that these are fake fact checks that's more just like a Biden campaign spin job is here from the New York Times and on their fact check article from the debate. And it's from Coral Davenport. I'm not really sure, or Coral, Coral Davenport. I'm not really sure who she is, but she's one of New York Times' fact checkers. And she said that this was false. From Mike Pence, quote, they want to abolish fossil fuels and ban fracking. Mr. Pence, false highlighted there. Which is a pretty, I mean, that's a pretty strong claim. You're saying that he just lied, okay. Well, let's see what she has to say. She says, Mr. Biden's climate change plan would end new leases for hydraulic fracking or fracking for oil and gas on federal lands, but it does not ban existing fracking on public lands or new or existing fracking on private land. Okay, this is spin, because unfortunately for the Biden supporters in the media, we actually have Joe Biden on record, on video saying that his ultimate goal is to get rid of fracking, get rid of fossil fuels all together. I am not banning fracking. Let me say that again. I am not banning fracking, no matter how many times Donald Trump lies about me. Thank you, Mr. Vice President, just to clarify, would there be any place for fossil fuels, including coal and fracking in a Biden administration? No, we would work it out. We would make sure it's eliminated and no more subsidies for either one of those, either any fossil fuel. No more, no new fracking. And by the way, on the Recovery Act, I was able to make sure we invested $90 billion in making sure we brought down the price of solar and wind that is lower than the price of coal. That's why not another new coal plant will be built. So when we look at this fact check, it is spin, it's campaign spin. Biden said what his ultimate goal was. He made no bones about it. He said, no more new fracking. And so anything after that, that you hear from the media or Biden's campaign is pure subterfuge. So they don't scare away the moderates because a lot of this election is gonna come down to peeling away moderates who sway whichever way the wind blows.  I do wanna go through one other one, which kind of exemplifies what I'm talking about. It's a fact check of Camilla Harris on behalf of the Biden campaign. So it's kind of crazy. Like Camilla Harris said something that they're afraid, again, that may peel moderates away from Biden so they're doing damage control. The supposed fact checker quotes Camilla Harris as saying, on day one, Joe Biden will repeal that tax bill referring to the Trump tax cuts. He says, this is false. Everybody else just said false. He said, this is false. Just to add that extra umph to it. And he says here, Mr. Biden's stated campaign plan proposes to repeal some, but not all of the tax cuts. Mr. Trump signed into law in 2017. The House and the Senate would have to pass new tax legislation to accomplish that. This is just, it's just funny to me because it's another example of these fact checkers really just acting as part of the Biden campaign. They're actually going after Camilla Harris who is part of the Biden campaign saying she's wrong. When she's really just staying, she's on one hand, she's saying what the left wants to hear, but she's also stating what they actually want to do. And these fact checkers don't like that. They're doing damage control. So now that we got all of that out of the way, this is the big lie that I really wanted to focus on. And the reality of this is that we are talking about an election in 27 days where last week, the president of the United States took a debate stage in front of 70 million Americans and refused to condemn white supremacists. Not true. And- Not true. It wasn't like he didn't have a chance. He didn't do it. And then he doubled down. And then he said, when pressed, stand back. Stand by. And this is a part of a pattern of Donald Trump's. He called Mexicans rapists and criminals. He instituted as his first act a Muslim ban. He on the issue of Charlottesville where people were peacefully protesting. The need for racial justice where a young woman was killed. And on the other side, there were neo-Nazis carrying tiki torches, shouting racial epithets, anti-Semitic slurs. And Donald Trump when asked about it said, there were fine people on both sides. This is who we have as the president of the United States. That's the main lie that was told. I mean, she just literally rattled off like five or six lies there that the media and the fact checkers have completely ignored. Right after this, she went on to see an end with Jake Tapper, went around all the networks really and sold the same lie over and over again without being fact checked.  So it's a big mystery why American media wouldn't do that. But the fact is he has condemned white supremacists going back to before the campaign. He condemned the white nationalists and neo-Nazis who were in Charlottesville. He did not call Mexicans rapists. He said that a subset of illegal immigrants coming across the border are criminals and rapists. There's a huge difference in those statements. So she's just all over the place there, but the media is not gonna fact check it. And the reason is pretty obvious because they're in on it. They're really invested in the big lie.  So I found it odd when I started looking on all the fact checks. Well, I guess it's not odd, it's expected. But going on to all the fact checks, you can see none of them actually address that at all. None of them call Harris out for lying or defend Trump saying that, hey, at least 20 times. And if you haven't seen the videos, I've done several videos on this now. At least 20 times, maybe more. But looking on all of these fact checks on all the major networks, USA Today, CNN, New York Times, whatever it may be, they don't talk about it. But guess where I did find a fact check of this lie? Once again, once again, because this has happened one on the time, but on the BBC, it says right there, Harris, Trump said that there were fine people on both sides in far right protests. Now, they don't get to everything here, but they say that the quote is correct, that he did say the fine people on both sides, but that Trump said that in the same press conference is actually like the next sentence, that he was not referring to neo-Nazis and white nationalists. They put the quote right in here. However, at the same press conference, Mr. Trump went on to say, I'm not talking about neo-Nazis and white nationalists because they should be condemned totally. How completely insane is it that we as Americans have to go to international news for the truth? We have to go to British state media to get the truth about politicians in our own country. And then she also makes the claim that Trump, when given the opportunity to again condemn white supremacists, you know, for the 20, 30th time now, who knows why he has to keep doing this, but she claimed that he had the opportunity during the Fox News debate and did not. I'm sorry, but that's not true either. And here's the proof. But are you willing tonight to condemn white supremacists and militia groups and to say that they need to stand down and not add to the violence and a number of these cities as we saw in Kenosha and as we've seen in Portland? Are you prepared to do that? So there's tons more of these fake fact checks just like this. And I'll link them all in the description if you want to take a look. Like I said, as far as I'm concerned, all those fact checks are from organizations that are completely untrustworthy. That's about all I have to say on that. Like I said, I just wanted to hit on that major fact check that all the media ignored and just show that these fact checks in general are just completely untrustworthy. But I do also want to invite you all to my D-Live and my Discord tonight for horror movie night, which will be starting at 8 p.m. Eastern. You can find all the links for that in the description and pinned comment. Thanks for watching. Keep coming back.


Okay, hey everybody. My name is Patrick O'Daherty, and I'm an engineer at Intercom in San Francisco, and today I'm going to be talking to you about how you can start your own Ember revolution at work. So this talk is based on our own experience at Intercom of adopting Ember and migrating a large existing code base into a new Ember application. So for those of you who might be unfamiliar with Intercom, Intercom is the one place for every team in a internet business to communicate with their customers personally and at scale, whether that be on your website, inside your web or mobile application, or even by email, and our mission is to make web business personal. So Intercom started life back in 2011 as a Rails application like any other and grew quickly over the years as a large monolithic code base powering both the suite of APIs for our messenger platform and SDKs, as well as the web application used by our users to communicate with their customers, and back in 2014, we undertook a complete rewrite of this web application, deciding to rebuild it from scratch using Ember. I know that selling the merits of Ember at EmberConf is a little bit like preaching to the choir. I'm sure you're all well familiar with how Ember is going to be able to help your team. But I do want to take some time to give a little bit of background and that went into the decision of adopting it at Intercom. So at the point that we started using Ember, Intercom's web application had grown to comprise of over 40,000 lines of template and JavaScript code alone. And this combination was becoming quite unwieldy at the time. These tightly coupled JavaScript classes ended up being problematic in a number of ways. They were hard to test, they would interact in unexpected ways as they manipulated DOM elements and maybe changed jQuery selectors, that sort of thing. And ultimately, they accounted for a really significant portion of our technical debt at the time. We were also beginning to hit some of the inherent performance limitations of relying so heavily on server-side rendering. As our product pages grew to be more comprehensive and show more and more information, re-rendering each page, querying for the same large dataset over and over for every minor change in rendered output was just unacceptable. And the combination of all of these issues caused us to start questioning our Rails-based front-end stack. This was particularly important as we were planning to expand our product considerably over that coming 18-month period. And we're worried about building on what we were beginning to consider shaky foundations. And on top of that, we felt very much that we had reached a tipping point both in kind of application performance, but also in developer productivity. Zooming out, however, and taking a look at the wider development ecosystem of the time, there had been a considerable amount of change in even the three-year period since Intercom had begun development. In particular, the emergence of numerous stable feature-complete JavaScript frameworks like Ember and Angular and Backbone, they completely changed the landscape for us and offered a whole range of new alternatives to this server-rendered JavaScript augmented development pattern that we had come to rely on so heavily. Now, it's not at all uncommon in industry and especially on sites like Hacker News to find people with a somewhat dogmatic sense of belief in their tools of choice. And while we're still very big fans of Rails at Intercom and we still use it to develop the APIs that power both our new Ember application and our Messenger platform, we did want to be a little bit more practical about our technology choices when it came to this primary web application. Another really important factor that went into making this decision was that adopting Ember allowed us to build much more ambitious products. At this time, internally, we were iterating very heavily on the shared inbox in Intercom, which is one of the more crucial components or destinations in the application. It's where the majority of our users spend a lot of time every day working collaboratively as a team to message back and forth with their customers, reply to conversations, work through issues with customers. It's a really primary workflow and it was really important that we nail it. And I want to give an example of just to compare and contrast the product that we were able to build with Rails and then Ember. And this is a screenshot of the inbox. This is one of the final iterations of the inbox that we made in our Rails code base before we adopted Ember. And to contrast, here is a screenshot of one of the earlier versions of the inbox that we rebuilt in Ember. And I hope it's immediately obvious that it's like a much more ambitious application. You can see much more information about what's going on in your team. There's a lot more information displayed, it's easier to switch back and forth. And this was much more ambitious than anything that we would have been previously able to develop. We thought that things like this were kind of out of our reach. And I really do want to make that point. This would have been really more than impractical to develop with our old development patterns. We wouldn't really have even attempted it. Even with all of the potential benefits of your new tool and framework and all of the sunshine and rainbows that you see in the future, not all teams are very receptive to such large change and certainly managers don't all jump in the light when they hear the word rewrite out of their teammates' mouths. And so all of this adds up to make introducing new tools like Ember somewhat difficult. But I hope that these lessons that we've learned can help you both with the technical and also the social aspects of introducing Ember to your team. So the first lesson that I really want to hammer home is that when you're introducing a new tool like Ember or any new tool in your business, it's important that you create your own hype. Start with your friends, your colleagues, all the people that you work with, chat to them about your new tool, get them excited about it. Have them thinking, this is great. It's going to solve all my problems. And not only that, make them think about how it could be used in their everyday work. You really, really want to gather this bottom-up momentum. And indeed, the story of how Intercom got started with Ember starts with only a single engineer, Gavin Joyce. And so Gavin joined Intercom right at the beginning of 2011 and was originally tasked with refactoring the user data APIs that we use to query and present data rather in the user list in Intercom. And this is a screenshot of the user list as it appeared in Intercom at the time. It's a feature in the application that allows you to view all the users of your web or mobile application and quickly filter them based on either their activity in your application or on information attributes that you record about your users in Intercom. And so Gavin started on this rewrite. And while the backend component of the rewrite was relatively straightforward and fell into place, Gavin kind of hit a roadblock with the, whoa, oh my God, Java. That is the most inappropriate time to ever prompt somebody for an update. So Gavin hit somewhat of a roadblock seeing that decoupling this soup of ERB templates and highly coupled jQuery that we'd written to accompany these old APIs was going to be a really significant like uphill challenge. And in this he saw a really clear opportunity for Ember to provide a much better solution to this problem. So to start this little movement, Gavin put together a really rough and ready prototype of what a user list might look like if it was developed in Intercom. And shared it alongside with this other demo that he'd created called Ember Beats. So Ember Beats is a drum machine application. Gavin's a really big music lover and he made this to really demonstrate just the potential there was for Ember to build really amazing applications. And so he shared this mock-up and the Ember Beats application around the team basically with the aim of convincing everybody that we should give this a shot. At the time, given our experience, JavaScript was kind of an anti-pattern in our minds. We didn't really want to rely on it too heavily. But seeing this demo really awakened us to just how much potential there was to build really great products and really amazing experiences with Ember. And got us thinking about how we might be able to introduce it into Intercom. So based on this, Gavin lobbied for us to start a little experiment.  And the brief was very, very simple. To build a new, faster user list in Ember to fail quickly if things weren't going to work out.  Nobody wanted to spend time on work that wasn't going to work out. But on the other side, if it was looking like things were going to work out well to plan for success and really give a lot of consideration as to how this would be more widely deployed internally at Intercom. So it might seem a little obvious, but this was a resounding success. Even before the end of the first week, everybody was just really buoyed by the opportunity to use Ember at Intercom. And the user list that this little team ended up building was not only simpler to build and drastically smaller as a code base. It was also much, much faster. Simple actions that previously took around five seconds due to server-side rendering and, you know, refetching all this data were now down to a second or less. And I know while five to one, you know, on a purely numbers basis is relatively impressive, it also dramatically changed the experience of using the user list, particularly as people were able to quickly iterate on the searches that they were doing and really, you know, narrow their user list down to exactly the people that they wanted to message. You know, this was just so much better than previously where every minor change was a five-second turnaround. You'd lose the context, it would flash, you know, this was just chalk and cheese. It was really, really much better. So the next thing that I want to talk about is, you know, when you're starting a rewrite or introducing a new pattern or technique, it really helps to form your own internal team of experts, you know, for the rest of your engineers to kind of gather around and use as a resource. So almost immediately after the user list experiment wrapped up, we made the decision to completely junk our existing roadmap of the time and put all of our efforts into rewriting all of the product that we had in Ember. And, you know, facing down this long rewrite road, it was quite a daunting prospect, and it was made more so by the fact that, you know, Barr Gavin and the very small group of engineers that had built this user list, nobody internally had a lot of expertise or experience developing with Ember.  We kept them together to provide kind of like a reference point for all of the other product teams as they took their own parts of the application and started planning how they would build their own features in Ember. And this was really, really crucial to kind of like getting the ball rolling and, you know, allowing people to, you know, plan for success and not make simple mistakes and have to throw out a lot of work. We also recruited outside help in aiding to build this, you know, bootstrap this expertise. And we asked Tom Dale to join us for a few weeks as we began this rewrite in earnest.  You want, you know, product A but in new technology. But it's important to keep in mind that you're also racing towards this goal, this tipping point where it becomes easier to build new features and products exclusively in your new application as opposed to, you know, adding them to your old.  And we wanted to make sure that each of the product teams had every opportunity to, you know, get started and build up some early momentum as they, you know, took ownership of each of their own product features and migrating them one by one into Ember. We also wanted to make sure, you know, that they were free to focus on this, you know, without any of the other distractions that might have been provided by, you know, maintaining the old code base or working on issues, anything like that. We really just wanted to clear the path.  And there's a real risk that if you don't manage your time well and if you don't think about it a lot, that you might end up prolonging this. You know, every line of code that you add to your old code base should be viewed as technical debt because what you're actually doing is creating more and more work for your team to, like, move this into your new application. And so to prevent any, you know, accidental prolonging or, you know, needless time waste of this kind of period of double work, we decided to effectively freeze feature development on the Rails code base and just completely clear the path for the product teams to focus entirely on this Ember migration, which brings us to my favorite lesson, lesson number four, fake it while you make it. So it's important to, you know, as with any product, to get it into the hands of your users early on. You want to get your Ember rewrite out the door as quickly as possible, you know, allow yourself to fix bugs, iterate on things, catch them early, all of that. And shipping a giant rewrite all in one go, you know, it's just, it's a really daunting software task. We're not very good at it. It's much riskier you end up dramatically increasing the likelihood of, you know, shipping multiple bugs at once and otherwise causing a, you know, a really bad customer experience for people who, you know, get on this early alpha. But, you know, when you're rewriting an existing web application, you actually have a lot of freedom. Because you're replacing existing pages, you can actually be pretty cheeky with what you deploy. And indeed, we decided to take advantage of this a lot as we shift early parts of our Ember application. So, you know, given the fact that you're replacing all these pages that already exist, you can actually, you know, mix in bits of your new and old code base together.  You can entirely ship, you know, one page at a time and use your existing code base to kind of give the illusion that you've built this massive product, you know, all very quickly. And so, when we were released, rather, the new Ember user list, we very deliberately left out a considerable portion of functionality. And this just gave us a little bit of time, you know, to catch your breath and focus on getting things done right first. And so, to give an example, here is the user list as we originally shipped it in Ember. And I want to point out that all of the functionality on this page, you know, the main functionality of looking at your users, sorting them, filtering them, saving segments, switching between them, all of that, that was all, you know, that was the core of the Ember application. And all the while, all of these other pages, you know, in our product, they were still running this Rails code base. And so, the vast majority of the links on this Ember page actually directed you back into the Rails application. So, for instance, if you wanted to create an auto message to the users that you just filtered, or if you wanted to, you know, check your conversations and see, you know, how people were responding to messages, or catch up on your manual or auto messages, see their progress, monitor their statistics, you know, all of these pages straight through to the settings and documentation, they all didn't change at all. They were, you know, completely the same as before, all in our Rails code base. And so, this allowed us to, you know, feature by feature, move things into Ember, you know, with providing the same experience to people. Another really amazing tool, and I think sometimes web developers have this, they're kind of hesitant to use iframes. Certainly, they've gotten a lot better in recent years. And they were a really invaluable resource during this time, as it allowed us to mix new and old parts of the application onto the same page. And so, we made very heavy use of them in our Ember application to render some of the Rails pages that we had been maybe slow to migrate into the Ember code base. And we would render these pages in components in various Ember writes. And so, this was great at giving the illusion that all of these pages that you were navigating to, you know, very quickly back and forth were all in this one Ember application. And you can also use it to go the other way. And so, we made somewhat creative use of iframes to embed the Ember application into our old Rails app. And the one really strong use case that we had for this was some of our payment flows are modal-based. And so, we wanted people to experience, you know, the same purchasing experience in InchCom no matter if you were in the old Rails code base or in the new Ember one. And so, we would do this by rendering a hidden iframe on the page, booting the Ember app in the iframe. And then any time that you wanted to enter any of these modal experiences, we would open this specific modal write in the Ember application and overlay the frame on the page, giving the impression that all of this was being driven, all of this live experience was being driven by the Rails application. Another really wonderful choice that we made that really saved us was that we decided to keep the URL structure in the application exactly the same as it was in the Rails app, you know, as we moved pages into Ember. So, for example, this is a URL for the page that shows your default user segment where you go to see all of your users. And this is in the Rails application. And this is the same URL, but for the Ember-based page. The only difference being that we would prepend this small prefix to the path to direct users to this new Ember experience. And this doesn't seem like much, but coupled with a feature flagging system, this allowed us to application by application opt people into this new Ember experience. And this was great for controlled rollouts. You know, it allowed us to experiment internally without any danger of, like, releasing accidental bugs. But more importantly, it allowed us to, you know, grow the audience of our Ember application as our confidence increased. We've talked elsewhere and, you know, we've written a number of blog posts on our really heavy reliance on continuous integration and continuous deployment at Intercom. And this pattern allowed us to iterate really, really quickly on the Ember application as we built it. It wasn't uncommon, and it still isn't uncommon, rather, to ship new releases of the application dozens of time a day. And, you know, this was really important for us because we wanted to be able to move quickly, but also in confidence that we weren't, you know, introducing bugs and shipping, you know, awful, awful broken experiences to our users. And this pattern is something that we, you know, we developed previously but really, you know, refined in our migration to Ember. And it's been something that has allowed us to really move quickly with Ember in the approximately two years since we've adopted it. So here's a short timeline of the, you know, product development that we wanted to do in the 18 months after we started using Ember, starting all the way back with the user list in April 2014, straight through to the end of last year. And, you know, betting on Ember has just been instrumental to all of this change. You know, so many of these features were going to take, you know, twice as long if, you know, if not longer to build in this Rails code base. And the patterns and conventions that Ember came with, all of these great decisions made out of the box, just promoted this, like, really quick pace of work. Oftentimes many of these features were able to make very heavy components which Ember, like, really gets, you know, really does it well. And it's just been a great pattern of code reuse all the way through the application, which is great not only for speed, but also in providing this, you know, consistent experience all the way throughout the application. And so I want to leave you just with these four lessons. They've been really instrumental in guiding us through our own Ember journey and looking back, embracing Ember has been probably the best technical decision that we've made as a company. We've built one of the largest Ember applications in deployment in the last two years, and it's been a fantastic journey, like, each step of the way. And so I hope that these lessons, you know, hopefully they'll resonate with you and they'll also be helpful with you as you start your own Ember Revolution at work. And so with that, I'm going to wrap up and thank you so much for your time. It's been really great to have an opportunity to share all this with you. If you have any questions, please feel free to reach out to me either on Twitter or via email. You know, we'd love to help. We very much believe that the more people using Ember and better tools, the better for us all. So thank you.


Lobbying is something everyone has an opinion about, but not everybody knows what lobbyists can and can't do. We're going to talk briefly about what lobbyists are allowed to give to the people they're trying to influence, which includes what travel they can pay for. We use the federal rules as an example because each state has their own variations. At the federal level, there were almost 13,000 registered lobbyists spending over $3.3 billion in 2011. Now, before we go any further, let's be clear on what lobbying is. Here, we're talking about spending money to convince a politician or a senior federal official about a specific law or regulation, either one-on-one or as a group. Just talking about things you would like to see happen or issues that concern you isn't considered lobbying. Spending money to build a grassroots campaign for or against a law or regulation isn't considered lobbying either. This means that while federal funds given to organizations can't be used to support lobbying efforts, they could be used to support grassroots outreach, though federal agencies are not allowed to spend any money on grassroots campaigns. Lobbyists can still donate money in politics like anyone else. They can also form political action committees to take donations and give them to candidates. Lobbyists can also contribute money to ballot initiatives, though in all cases they have to disclose anything they give over $200. For more information about how campaign finance works, check out the video on this very channel. Better to give than to receive, right? But there are some gifts lobbyists just can't give at all. Politicians can't accept gifts from lobbyists to any organization they control, like a charity, business, or foundation. They also can't accept contributions to charities made for them. Politicians are also not allowed to accept contributions that are legal defense funds from lobbyists, though they can't accept contributions to legal expense funds for legal expenses associated with their official duties. One would assume that being politicians, trying to stay out of jail would count as an official duty. Politicians and their staffs may only accept gifts valued at $50 or less at any one time, and may only get gifts valuing less than $100 from any one source in a year. They also can't accept gifts that are just money or its equivalent like stock or gold. Nor can they accept gifts to a concert or sports game with a fake lowered value. Finally, they can't accept any gift in a situation where someone will believe the gift was influencing their performance of their jobs. Because, you know, the lobbyists just want to be nice. Because these are politicians we're talking about, there are exceptions to these rules. They can accept the gift if they pay market value for it, or if it's something given ordinarily as part of an outside job or business of their own, or of their spouse, or if it's a gift from a friend or relative, or from another politician, or from the politician's staff on holidays or special occasions. They can accept retirement benefits from a previous job, or honorary degrees and any food or lodging for the ceremony, though they do have to disclose it if it is valued at more than $250, or informational materials, or products from their home state that they show off in their offices like Hershey's chocolate for Pennsylvania politicians. Or any prize open to the public, or any expenses from attending training except food and lodging. They can accept gifts from foreign governments, though anything valuable will be displayed by Congress. And they can attend any public event for free. They can take free hospitality from anyone who's not a lobbyist, or small amounts of food and small items like t-shirts and greeting cards. The House and Senate ethics committees can also grant waivers allowing politicians to accept a gift. Because if there's one side of people you can trust to watch politicians, it's other politicians. Senior federal agency officials can use some of these gift exemptions as well, but not all of them. Paid travel is not treated much differently than gifts. All official travel paid for by an outside group must be approved by the ethics committee and posted to a public database. Politicians are required to pay the going rate for any aircraft they use, even if it's someone's private aircraft. Members of the House of Representatives are only allowed to fly commercial. Usually lobbyists aren't allowed to pay for official travel unless they work for charities or colleges, but they can pay for one to two-day trips as long as there's an actual event to attend, and then only if the lobbyists are only a part of side meetings and not the official event. Other private entities can pay for official travel if it's related to an official purpose and to what the entity does, and if the location was chosen because of the purpose of the visit and not because it's near a bunch of golf courses. The travel must be less than three to four days domestic or a weak international. Any expenses must be for travel or lodging and must be reasonable. Entertainment is only allowed if it's for everyone who comes, including non-politicians, and politicians may only bring one relative. Now, if it's just regular private travel, other people can pay for politicians and their staffs, though the person paying is not allowed to do it because of their position, and the trip has to be the same version of a trip that anyone else would get. A politician's friend can pay to send them somewhere for less than $250 any time, or more than that with a waiver from the ethics committee. These are friends much more generous than mine. A local or state government can pay for any kind of travel for congresspeople that it wants to, and there are not that many restrictions on the kinds of official travel that congress can give itself. Odd how that worked out. And there you have it.