Admin Your App: Or Why Internal Tools Matter
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 20 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/35003 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EmberConf 20145 / 20
3
6
13
15
17
18
20
00:00
Correlation and dependenceVideoconferencingPresentation of a groupContent (media)BuildingSystem programmingMobile WebSpreadsheetSoftware developerProduct (business)Function (mathematics)Component-based software engineeringCodeContent management systemBlogHill differential equationOpen setAuftragsspracheStaff (military)WordCellular automatonQuicksortUniverse (mathematics)Physical systemStudent's t-testProduct (business)Group actionSynchronizationMedical imagingComputer architectureCodeTask (computing)View (database)Error messageMultiplication signPlanningFunctional (mathematics)Particle systemTrailSet (mathematics)MereologyClient (computing)Control flowCircleBuildingCartesian coordinate systemFraction (mathematics)Data managementFigurate numberInternet forumBit rateEvent horizonSoftware developerPhysical lawProcess (computing)Streaming mediaDialectSoftware frameworkEndliche ModelltheorieRouter (computing)Revision control1 (number)Standard deviationPoint (geometry)Numeral (linguistics)WebsiteAtomic numberWeb browserLevel (video gaming)Mobile appSpecial unitary groupDigital photographyState of matterCASE <Informatik>Interactive televisionNatural numberSeries (mathematics)Theory of relativityWell-formed formulaInstance (computer science)MultiplicationRow (database)CuboidSingle-precision floating-point formatMathematicsCross-correlationMessage passingExtension (kinesiology)System callImage resolutionBitNetwork topologyMonster groupSpacetimeDependent and independent variablesMilitary baseNormal (geometry)Logical constantStrategy gameArchaeological field surveyMathematical analysisVideo gameHypermediaINTEGRALFront and back endsPattern languageAnalytic setInternetworkingGame controllerExterior algebraContent (media)Personal digital assistantConcentricFormal languageBranch (computer science)Regulator geneMehrplatzsystemDirection (geometry)Computing platformConnectivity (graph theory)Data structureVotingForestRight angleLattice (order)Library (computing)Form (programming)Electronic mailing listDataflowAuthenticationTable (information)NumberSoftware development kitExecution unitDifferent (Kate Ryan album)RootTemplate (C++)Goodness of fitSheaf (mathematics)DatabaseWeb 2.0TwitterCanadian Mathematical SocietyoutputWeb pageMobile WebDebuggerAlgebraic closureComponent-based software engineeringSpreadsheetContinuous integrationLatent heatLogic gateProgramming paradigmBlogTouchscreenParameter (computer programming)Musical ensembleParallel portVideoconferencingSoftware testingRadical (chemistry)Shooting methodShift operatorMixture modelField (computer science)Proxy serverFacebookXMLComputer animation
Transcript: English(auto-generated)
00:24
I'm part of the content engineering group. I'm an engineer there. Live Nation, if you haven't heard of us, is a concert promotion and ticketing website. We actually own Ticketmaster and House of Blues. So our work is primarily in the ticketing and concert space.
00:42
Live Nation Labs' primary responsibility is around livenation.com, which is the flagship website. It's currently an event listing site and we've started to do some integration with content. I also work with our content creation team. The content creation team is responsible for sponsorships and partnerships.
01:04
We actually do events in venue where we would collect social media at the event and then through an administration tool, we curate that, moderate it, and then present it on the screens in the actual venue.
01:20
So we get people, as they're at the concert, being able to experience what other people are seeing. We also have, when we spin those up, we also have websites that go along with them so people who aren't at the venue can see what's going on at the event. The content team is also responsible for our onenation.livenation.com blog.
01:42
This blog is a music and tour blog. They do photos, they do videos. The content production team also will go out to venues and shoot video of the actual artists. They'll do things in the crowds, backstage, and we have writers who then write up content that actually goes on the blog.
02:01
Now one of the mandates and one of the reasons the content engineering team was pulled together was we wanted to get this content that was being created pulled into the livenation.com website. So we started that process this year by having our curated photos that our professional photographers go to the venues and take
02:20
show up on our artist pages and our event pages. So we built the system so that we could make sure that all the photo galleries were set up and were then consumed through our website. Our team is also responsible for the Live Nation iOS app and future mobile products that are coming.
02:40
Today I'd like to tell you a story, and that story is kind of the creation of how we got to where we are with Live Nation Labs. It starts in 2012 when Labs was first being found. I was asked to join Labs in January of 2012. I didn't end up joining until February. And when I did, our first mandate was to take livenation.com,
03:02
which up until that point had been a re-skinned version of Ticketmaster.com, and re-brand it as a pure Live Nation experience and make it more flexible. Because the problem that they were seeing with the skinned version of Ticketmaster.com was we weren't able to innovate, we weren't able to try things out
03:23
because it would take weeks or months to get anything changed on the site, it would take weeks to get a meeting to talk about it, and then months for anything to happen. So we wanted to find a way to be flexible, a way to do things fast, and fail often, and then fix those failures and move forward.
03:41
So we decided the initial build was going to be in a Rails environment, so we had Rails from the front end to the back end, we were using Haml for the templating language, and it was really a standard Rails application. Client server, interactions, not a lot of JavaScript.
04:00
And as we were going through the process, we discovered that we had these images that we had to handle, artist images and tour event photos that were not necessarily handled, weren't static, they were going to be changing all the time. So we added active admin to the mix. Now, what active admin got us at the beginning was us not having to build the admin tool, and basically just hooking into our Rails app and being able to address it directly,
04:25
which was great for where we were right then. But then Rails Conference 2012 happened, and a lot of things changed for us after that, because that was the first time that we were really introduced to Ember. One of our engineers went to Yehuda's talk at RailsConf,
04:43
and it was at version 0.9.8 about. This was before the router, before pre-1 release, and he came back very excited, because he saw... We'd been looking at JavaScript MEC frameworks, and those frameworks, none of us were getting very excited about them.
05:01
We looked at Backbone, we looked at Knockout, and while they did part of what we wanted to do, there were trade-offs and the amount of code that you had to rewrite every single time, they just weren't appealing to us to move forward with. But with Ember, we saw the beginnings and the foundations of a really good system to build out our application and treat it like a client,
05:20
the same way that the mobile app was a client of our backend. That got me very excited, because one of the things that I've been trying to do for a long time is treat the web the same way that people treat mobile. So not just have it be part of the full stack, and then, OK, we're going to have to build an API on top of this. Really treat our backend system and our data as an API-first system,
05:43
and have all of the clients then interact with the API, and not go through, have different ways of dealing with the data, depending on which client you were. So this changed the way that we were building out our ecosystem. We moved away from kind of a monolithic Rails app,
06:00
with frontend backend altogether, to smaller systems that ended up talking to each other. And these systems were a mixture of Rails and Python, because we had acquired another group that was Python engineers at that time. So we had our platform, which was our event listings, and then we had our user system, which handled our user credentials and people logging in and their likes from Facebook.
06:23
We had a recommendation engine that basically took what the users liked, and then discovered new artists for them to be interested in. And the other piece that we added was an API proxy. An API proxy allowed us to talk to all those subsystems from the clients by going through one in place, basically acting as a traffic cop for the rest of the systems.
06:43
So we had API endpoints then that served both web and mobile, and the web was really the pioneer when it came to using our API, because the mobile app didn't come for about a year later. So we were breaking ground on making sure that the API endpoints worked, did what they needed to do, before we got the influx of mobile traffic that we knew we were going to get,
07:02
because our mobile apps get far more traffic than our web systems. And we didn't really change the way the admin worked. Active admin stayed in place, talking to the platform system the exact same way it always had, was talking directly, using the same model. So we didn't evolve the way we dealt with our internal tools.
07:22
We had changed the whole paradigm of how we were developing the website, but didn't change anything else. So we modified our architecture, but we didn't update how we dealt with our internal tools. This led to kind of three problems right out of the gate. Our admin wasn't being updated, which means we were not able to go in and maintain it,
07:45
to add things, because the code was becoming very stagnant, and it was becoming out of sync with what we needed it to do. The next one, which was a big one, was we had a very vocal group of content creators who could not do their job. They could not get into the tool and make it work for them.
08:03
The images weren't being updated. They were having to, instead of delegating the tasks, which should have been easily repeatable to people, to other content creators, or even just content interns, they had to take on that responsibility themselves, and eventually throw it back up to our product owners,
08:21
because the tools wouldn't work for them, and they didn't have time to deal with it. Eventually, after that, the engineers had to begin maintaining the content, because the system got so out of whack that we were having to do things in Rails console. This was the worst possible situation, because you had engineers who should be developing features, updating content directly through the terminal.
08:43
That's when we went, okay, we need to take a look at this and see what we can do. That brings us up to 2014. We had a shift in the way that we view what we're doing with our administrative tools. We have principles that we develop on, basically, in our group.
09:01
Those principles are API-driven, which means all the things that we do, we work through APIs. We deal with the systems through APIs. That's our gold standard. Everything is testable. The APIs are tested and run through continuous integration. Our front end is tested and run through continuous integration. Mobile app is tested.
09:21
We have test code everywhere to make sure we're not going to deploy things that break. Trackable. Everything must be trackable in the system. Our product owners are very good about using analytics to make sure the features that we build are the features our customers want, and that as we add new features,
09:40
we're not breaking down the customer's experience, and we're adding things that they find valuable. Making sure that every time we add a new piece to the system, we track it, has become incredibly important. The last one is the one that we've added recently. Everything is administrable. This is right now a goal more than something that is an actual practice.
10:01
What we want to be able to do is that if there is a system that requires any sort of content maintenance, we need to make sure that the event listing names are always correct. We need to make sure that the artist photos are always correct. We put in systems at the beginning that allow us to hand that off to non-technical people,
10:23
to non-engineers, to content creators. They can hand those off to other people that can handle the content administration without having to understand how the underlying system works. This kind of dovetails into our new goals that our internal users deserve good tools.
10:43
Our products, we take a lot of pride and put a lot of work in putting out good products for our end users. Our internal tools need to be seen the exact same way. When we create our product, we create a system alongside of it to maintain that product, and it has to be of equal standards.
11:04
Now, this point is a little bit different, and it's something I'm trying to really advocate, is that to stop treating our data, our content, as merely rows in the database or rows in the spreadsheet. One other thing about using Active Admin or a number of the CMS tools
11:21
is they present data in the same way, a table that zebra strikes records from the database. That's not really the way that our data is displayed on the site because we're pulling data from multiple systems and pulling those together and presenting them as one unit. So what we have to do with our admin tools
11:41
is treat our data as content, as those content packages, and make sure that as we administer them, we don't just make them function as rows in the database. If we need images at certain resolutions, we need to always display all the images that they could see. We need to do production quality previews of the data
12:03
as it will be seen on the site. It takes a little bit of coordination, but it allows us to fix problems before the end user sees them, which is one of the major goals, is to make sure that we catch anything before anybody outside of our group does. And the final point is that admin tools must be easy to add to
12:23
and extend by other developers. We took time to look into fixing active admin when we were starting to have these problems. And the issue that we hit was we couldn't add the things we wanted to add simply, and we had to basically go back
12:42
and almost decode what other engineers had done because we did not have a good system in place. Because it wasn't the tool that did this. It was us not planning properly. It was us not documenting it well and saying, OK, well, we need to add a new section. Here are the steps that you need to do. So we want to make sure that we have a system in place that allows other engineers to come in,
13:01
add new functionality, and not have to take an inordinate amount of time. And one thing that I'm really pushing is that internal products and tools can be as important as the one you build for your customers. And I really think that they are, because before I worked at Live Mission Labs, I did work in more B2B space.
13:20
And our tools were all for internal users. We would have maybe six or twelve users top someone of our tools, and it didn't change the amount of work that we put into crafting those experiences because those six or twelve users were responsible for giving product out to millions of people. So treating our admin tools as,
13:40
yes, this is a small set of users, we know that we can kind of fake it if we need to, but really not doing that. Treating these as full-fledged products with requirements and user base and make sure we serve them up. So we now are working on a new plan of attack for how we go about building these admin tools.
14:02
Kind of taking it from the way that Ember is being put together, using small libraries for common functionality. So the way that Handlebars and the Runtime, all those are separate libraries that interact together to make Ember, we want to build our authentication system as a library that we can then use,
14:20
not only in our admin tools, but in other tools as we need to build them. Because there are talks about, oh, we want to build an intranet site. And having a code base that we can plug in and build other tools with is important so we don't recreate the wheel every single time we go in. Using Ember components. This is something I'm very excited about
14:40
because I think that when we start using Ember components as these consolidated pieces of code that you drop in and say, OK, here's my text field. I do this the same way every single time. Making it very clean and very easy for people to add components and making those components almost like a toolkit of here's all the pieces we know an admin tool needs.
15:02
We know it needs form fields and check boxes and a wizard system that we can plug in. Having those be Ember components allow us to reuse that code without having to have every single developer kind of do it his own way and making sure that it's documented well enough so that we can hand someone a document that says,
15:22
here's how you build out your admin tool and they can get it done in an afternoon. And that also goes along with this idea of consolidating the code. We don't want to have admin systems spread all over the place. Right now we do have some admin systems that are very specialized. We want to make sure if we do have a specialized tool, there's a way from a centralized system
15:41
we can access it or at least pass through it so we don't have the problem that we have now of an abandoned admin tool that we need once every six months and when we hit it in six months, it doesn't work because the other tools have moved on. So we want to make sure that we keep everything fresh and in the same place so that we can maintain and migrate. Now, there was a lot of talk
16:01
before we got to the place where we said, yes, we're going to build these the way we build other tools with Ember. First one was, let's use an established CMS. And I question really hard against this because all of the tools that we looked at did the thing that I talked about earlier where they treated our data as rows on the table,
16:22
not necessarily the data objects. And working with Active Admin, one of the things that the other developers and I found was that sometimes it would take more effort to try to get the other tools to do exactly what we wanted because we had a very specific use case than it was if we had just started from very simple, small tools
16:41
and added pieces onto them. So that was kind of the reason we moved away from an established CMS. I talked a little bit about fixing Active Admin. The developer and I lost two days of our life to try to fix what we had done with Active Admin. And it wasn't Active Admin's fault. It was really stale code.
17:01
It was, we didn't maintain our code base well enough. We didn't stay on top of it. We had looked and there hadn't been any, but our Active Admin system had been down for a month and no one knew because we didn't need it. So fixing that system, the amount of time that we'd have to spend to fix it
17:20
made more sense to invest in creating tools that were going to be very specific for what our needs were. Another piece that was brought up was, well, okay, if we're going to build this, why don't we build this with things we're not familiar with, new technology? And my argument against that is really Admin tools for products that are in production
17:43
should be built in parallel the same way. That way if you have someone building your production tool and building the Admin component that goes along with it, they don't have to thrash and figure out, okay, well, I'm doing this in closures over here and I'm doing it in CoffeeScript over here and okay, what am I doing? And you can have people, people will be in the same track,
18:02
okay, developing at the same time. That's not to say we should not have internal tools that we can experiment with before we do things in production, but treating our Admin tools as part of the production framework, playground, really is kind of the way that I feel like we should be. So what's next for our group? Well, we're in the process of building our Admin tools
18:21
in Ember from scratch, but instead of trying to build everything all at once, we're going to start moving features over one at a time. The reason we're going to do this is we don't want to have, this Admin tool be a bottleneck for new feature development. And the real piece that we're going to take over is something that's not even in our ecosystem yet.
18:42
We're moving the One Nation blog into our main site and in the process of doing that, we are going to absorb it into our platform and build our first Admin tool because it's going to be a blog, which means it's fairly standard, fairly easy to get that updated. There's not a lot of image manipulation that we need to figure out how we're going to handle with the API.
19:01
It's a lot of text and a lot of user permissions, and those are two foundations that we're going to build everything else on top of. There's a couple things that we have to solve, and more than anything, it's solved so that we can do this the way I want to do it, not necessarily for any other reason. I want to be able to isolate feature code.
19:20
I want to be able to say, I have a section on the Admin, let's say Artist Administration, and it is all in one folder so that my templates are used in controllers, and all that code can then be encapsulated so that someone comes in, they can find everything very easily. I've been using Ember App Kit. It doesn't necessarily let you do that very easily
19:43
because it wants things in the root folder with views, controllers, and templates. So that's one thing to figure out. One, if the way that I'd like to do it makes sense, and then alter our build tools so that they work that way. The other piece that I'm really interested in pursuing
20:01
is trying to see if using Bower, which is an internet, which is a web packaging tool, kind of the way that npm works, using Bower to wrap that code. So we could say, because one thing that has come up is that we may need to spin this up for other territories, and if we do that, they may not need all the components that we have.
20:22
So being able to say, okay, I want to install the artists, I want to install events, but I don't need blog, and I don't need photo galleries. I just need these two things, and I want them to have their own separate admin with their own separate users, being able to define that in package.json and then firing up the admin. I haven't figured that out yet, and that's something that I'm going to be actively working
20:41
to see if that makes sense to do that way. But I do want to wrap up by saying that one of the things that's taken away from all the work that I've been doing and all the thinking I've been doing on this is that as we build our product, we have to make sure that we build the infrastructure alongside of it to maintain it. Because if you don't build the infrastructure as you go,
21:02
you will end up building it later. And if you pay that tax up front, if you say, okay, I'm going to spend time to really focus on making sure both of these things work well, you reap the benefit later when it's time to add new features, and you don't have to slow down to build up that element. So thank you very much.
21:23
Again, I'm Michael Becker from Live Nation Labs. You can find me at MichaelSBecker on Twitter. Thank you very much.