Reuse, Recycle: One Team’s Journey from Projects to Products
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
Bostwick, Sarah
When building app after app at what point do you stop mining your past projects to quickly prototype and commit to maintaining a configurable product? This is a story of building a successful digital agency in a sea of tech startups by figuring out how to transition from one-off Ember SPAs to maintaining reusable products.
 Okay. Let's get started. My name is Sarah Bostwick. I work at Pixel Agency in downtown Los Angeles. We make websites and web apps for movie studios to promote their movies. For those of you who are not familiar with the term creative technologist, it's kind of an unusual title, but it's very applicable in our agency. Basically, I have to do my dev job, but also bridge the gap with the creative team and the business team, and pitch technology ideas and create prototypes and be an advocate for the dev team in general. Before becoming a developer, I was a fine artist for many years, and I'm really interested in how web, film, and gaming are converging into one experience of storytelling. As an artist, I was a documenter. I cast and carved down colloquial architecture where individuals made decisions, and their history was recorded in the objects they used every day. When I became a web developer to pay for my art career, I thought I would naturally be a creative developer, which is true, but not in the way that I originally thought. As an artist and a freelancer, I got a bit lonely, so I started working at Pixel as the sole developer, which didn't really help, but then our team quickly grew. We're now about 20, with like four or five developers and contractors. At Pixel, I fell in love with designing front-end systems. I worked on the front-end for Foxmovies.com, UniversalPictures.com, Battle of Events.com, where I really learned how to work with templates and work with scaling systems. So this is my background. These are PHP apps, but it's the same concepts of components, like these sections that can be reused on movie pages for these three sites. Each component can be moved around on the page and have different amounts of data. I'd had to account for there being absolutely no data for a movie and then being so much and having it look good at every stage. And then from this, working on these types of projects, our company learned how to create libraries. So this is the social plug-in that we use, reused in each project, improving it along the way. This is Swiper.js, which I love, I put it everywhere. It's a responsive carousel JavaScript plug-in. And then we also do one-off sites for movies that are done in Ember. So Ember, the way we use it as an agency, it's not to create ambitiously large apps, it's to create ambitiously fast. They made apps because our creative team comes up with solutions in very short timeframes because we'll get the art from the studios and then immediately we need to make something with it. So this is an example where the user can make a custom movie poster with their face in it. And then you can customize the text on it. And internally we call this app the face-in-hole, so it's sort of like the boardwalk and you have the cutouts of the mermaid and you stick your face in. It's like an early selfie idea. And so this is the same code base, but it's for animal ancestry. This is my cat Buster as Diego. This is Zoe as Idris Alba's girlfriend for the Mountain Between Us. And this was something we did in February just when we thought this code base was never going to be used again. They were like, we would like this in a week. So here is a promotion for Love Simon, which is a teen coming out story so you could create a Valentine that posts on social media. So this is last year's survey, but I'm thinking it didn't change too much. And this sort of idea that most people in this room are working on a product. And I think as a freelancer or an agency, we do much smaller scale things, but Ember still works really well for us. So I wanted to tell this story of how our agency learned about product development through Ember. So we're in the 10 to 13% of doing client work category. So some of the terminology I'm going to use in the talk is when I'm talking about products, I'm talking about something that is built and then sold. So the features are defined. There's an MVP as created. The product is sold. And then features are added and it just continues on. And then projects are sold and then built. So like a project has a scope of work, a client agrees to pay for the project and the project is executed. So these are totally different business models. So why would you, you know, turn projects into products to make more projects? Let's see here. Trying to go to the next. So who is this talk for? These consultancies, freelancers, like anyone using internal tools for repeated projects. So why would you follow this project to project to project to project to project pipeline? One reason is to create company assets. So as an agency or consultancy, you're in the service industry. So your assets are the talent in the room. So how do you hold on to that knowledge? One way is to create libraries and templates and add them that you can pass on to the new developers. It's a way to revisit your work, your past work in an organized way. And you can make incremented document improvements to that. And also, you know, the boilerplate features are done. So then you can spend time polishing and being more creative. So the outline of the talk, I'm going to have a case study of face and haul sort of, and then provide a checklist to decide when to commit because it is a lot of work and at what point is this a good idea? Tips for templatizing a project, some pitfalls you can run into, templates versus add-on, when to choose between the two types of internal products, and some resources. So this is an app that we made for I say it's two years old, so if there's any bugs, don't tell me about it. It's like I built on Ember 2.3, but it was the most fun example, so that's why I picked that one. So this is actually a video walkthrough, so I wouldn't get hung up here. So the app has like a little intro showing you why you would use it, kind of explaining what happens if you upload a picture and the result you're going to get. So they kind of play with the characters. So you upload a picture of your pet, basically, and you can transform them. Okay. So here I'm uploading a picture of Tomster, and he goes on to an H. Will 5 canvas, and we use Fabric.js library, so it can be cross-prouser. It makes everything easier. And then you can add pictures on top, but the same app, like you can add text on top, you can have branded pictures behind, and it's easily adapted for new use cases. But the thing that we wanted to remember was that the user wants to go to the next section or they want to be able to go back and fix their app, so these decisions were, they were all pre-made, and slowly they came into a llama. Sorry. I got kind of into it in the video. He's still going. Add a tail. So he's got a lion tail now. But luckily, I think this is the end here. Oh, no. Ears. Okay. So then we can add his name, and then we can make that sort of leaderboard of what animals, what characters Tomster is now. And then we don't create the share asset right away. We do it when the user clicks the share button. This is a COPA compliant app, so like children are already going to be using this, and there's laws against social activity for children. So we generate the share asset with PHP when you push the button, so we didn't have to create so many pages, but we wanted to have this metadata page with the Facebook share asset that's custom to the one that you made. And then you have a pre-populated tweet, and then you can also just download the asset because it's a square asset that you can share on Instagram. And there it is. So that's the basic app. So why I feel like this work is a good example is it has consistent functionality and user flow. So we were able to talk well between all of our teams, and they kind of stuck with what we had already, the base features that we already had, and then they just added onto that. And this template was easily, we could customize it really easily because it's all in one code base. Like we had all the projects are branches off of master, so I could see all my past work in one place, or our whole team's past work in one place. And then when we had different clients, we just pushed to another remote because you can push to different remotes. And I worked on other projects where this didn't work as well. It was too locked in. I was afraid to change anything because it would affect other projects, but this way it's all siloed, and you can do whatever you want with it. And then we kept it up to date, which is a small miracle. And it has good documentation. There's versioning, Wiki installation guide. I made some of these things for the talk, but they exist now, and we're going to keep going with it. And also evangelism. I mean, these are all things that I've learned from Ember, and why we all like to use Ember's because we know how to use it, and we know what features exist, and I think we can learn a lot from that and use that in our own companies. So this is a picture of the GitHub, just all the projects we've ever done. There's like 20 branches of it. And here's the Wiki. This is my first Wiki. This is only good for new developers, but because my creative team is never going to go to the GitHub and read up on my products, but it's good for contractors and new devs so they can see what the app is about. And I had links to asset requirements and design templates and features that exist and things I want to change. And there's the user flow that I made for this talk that was really fun. I used Lucidchart. I originally thought this was out of my domain, but I think probably a lot of you in this room have written user flows, and it's a good way to say when is it going to be safe to database, and also the creative team can look at this and they know what's available to them. And I also made this UX doc because all of our projects are so fast. People will just look at past projects and then make a design really quick because there's no time. So I actually made this UX after I've made the app many times. So I really understood the general idea and how to... I don't want to just keep making the same thing over and over again. I want to keep it open enough so people can make creative decisions, but I do want them to tell the introductory story and show the user what they're going to be making and the fact that you can add pictures or tags and the share flow. And the whole point of the app is these end assets that the user is going to share. And here's a Photoshop template, but what I liked about this is each layer is a state of the app. So it's all in one place. And it's kind of open. They can do whatever they want to it. This is what the app looks out of the box. It's not beautiful. I wanted to keep it sort of unstyled so you don't get locked into certain decisions and you can make whatever you want with it. And these are all the available options. So a new developer can just spin this up and they can see that you can upload a photo or use a webcam or use photos from Facebook. Here I use the webcam in middle of the night. And you can change the exposure. You can add pictures, text, and then... Anyway, so moving on, this is my first attempt at versioning. So I just followed Ember's example. I used the GUI on GitHub. That was really easy. And you just type in your tag here, your title, and your description. And then there's this helpful documentation off to the right saying exactly how semantic versioning works, which was really helpful. This is just a picture of our internal wiki, which I hesitate to do because I'm duplicating information from the GitHub and also doing it in internal wiki. But my design team, again, is never going to go to GitHub. They don't even have GitHub accounts, so it's really important that they understand what's available and that this tool exists and that there's these templates that they can start from, so they don't have to reinvent everything every time. This is an example of... I feel like my documentation is really serious. And I think it's helpful, and I want people to read it, but my colleague, Azu Ruli, wrote three pages of documentation about Fox movies, and then I came across this. And it's just some general advice about staying hydrated. And you would think it's just sort of this extra thing and it could get in the way, but I mean, obviously, if you're on the wiki, you don't know what you're doing, so it's kind of nice to have this little friendly language in the middle there, so you actually read closer because you're looking for the jokes. Because I feel like when I read documentation, I just skim it. So I thought this was good advice. And it's good advice to stay hydrated. So sort of a project to product checklist. You have similar projects requested multiple times. You have faster around that would benefit from boilerplate. You're revisiting your password for the good parts, and if it's mostly the same thing, you're just copying the app and then changing it. Like that might be a good template, but if you're picking and choosing little pieces from different projects, maybe those are good add-ons or libraries. So here's a quote from Robert Jackson. So you can, NPM can easily install from Git. There's no need to publish an add-on to NPM to consume it. Obviously, at Ember Comp, we're going to encourage everyone to make their add-ons public, but if they were needed to be private, like you can include them in your repos this way. So if you wanted to make internal tools, this is a good way to include it. You just have your repo name and your address and then some tag, some point in time in your library. So some pitfalls that you can run into. The designs and functionality changed too much. So maybe you didn't communicate with your whole team exactly what existed, and they made something crazy, and you can't even use your template, so you should just start over. Maybe their product is too general. Like you're recreating WordPress, and you could just use WordPress. So choosing between a template and an add-on, like we have a lot of libraries that we can piece together quickly to create these custom websites for our clients, but maybe we could piece together commonly used ones, so you have sort of this combination add-on and template together. So what do I mean by templating? I'm talking about something that has like a base app with a defined user flow. So not just like handlebars templates, which maybe some people are just thinking about, they're all slow templates. But I think the key to good templating is to be specific but open. So having your class names and JavaScript language be specific to the functionality, open enough to be used in different places. So as the saying goes, naming things is hard. Some things for templating that I found helpful were to print out the wireframes and cut them up. This is like an idea from Atomic Design, where you can piece, by cutting up these physical pieces of paper, you can kind of see where the repeated patterns are, and you can just write on those little pieces of paper, like what they're called. And also you can work with your UX designer to name things, so you're all agreeing to call things the same thing. So we've gone so far as to make a Google Doc to share with the client. So when you're talking about a component, like they know what you're talking about, and they're not calling it a module or a section, and everyone's on the same page. I'm also a big fan of EM. I know Functional CSS is very popular too, and they're not mutually exclusive, I don't think, but I think EMBER really lends itself to this namespace component structure. And so I really enjoy that style of CSS, because it enables you to scale your applications. And also EMBER really made it possible to have a living style guide. I've always read about it and wanted to do it, but it didn't seem quite like I was going to keep it living. But for EMBER, you just put all your components on a page, and you have to feed it the data so you can see the components. But you can actually see when your styles change or your components change, and you can share it with your designer, and they can see what components exist in your app. And so when they create a new page, they can just reuse what's already built. Some tips about template configuration. Like we use setting style sheets, initializers for the JavaScript, and services for data. Our apps don't use EMBER data most of the time, because they're so small, but it is nice to have a configuration file so when you can switch out the title and the metadata really quickly. So this is just an example of how I set up my CSS. I mean, obviously the component folder might change after this week, yesterday. But we have a color settings file, a default, typography, mix-ins, animations. This is an example of a typography config file in component style sheets. So the reason why I like BAM is because you can just take the component name and put it as a class name on the component itself and name the style sheet the same name so you can find everything. And I thought about creating an extension of the Blueprint generator to just automatically add that class to the components so then I have a starting place. And then, we have a root type. There's two types, application initializers and application initialize, instance initializers. For the face and hole we have an application initializer to configure Fabric.js so you can set the corner shapes and things like that before the application boots. And then services, a service is an Ember object that lives for the duration of the application and can be made available in different parts of your application. So this is an example from face and whole, like just have, we call it API, it's not an API, but we call it that just in case we turn it into one. So I just make a constant with all of my data in it and then resolve it in a promise so that if we do fetch it, eventually it would all work. So we have like settings for like the hashtag and the URL of the website and this sort of, you can see like where it's configured, there's the love Simon information. So some resources are write the docs.org. I really like this resource. It's a wiki with resources for all types of documentation. So for like technical writers, engineers, scientists, they have a conference and a Slack channel and local media meetups. And it's kind of nice to talk to other people who actually enjoy documentation because so few people do. And also I really enjoyed the closing keynote from last year's EmberConf. It was basically about refactoring without permission and I found that really inspiring because I did ask permission once and it didn't work out. So you just have to basically clean your room and your code so you don't live like a hoarder and it's great advice. So like maintain a product as part of Project Scope. So when you start off internal product development, you obviously need some time dedicated to that. And to port back features to master, I mean you should be responsible for that. That's part of your job. And also to give presentations to your team and let them know that it updated or give it an announcement. Like let everyone know that this exists. So lastly, just wanted to mention product development terminology which I'm sure everyone in this room uses but it was new to me working in an agency. So we checked them all out like product life cycle, product teams, owner, product manager, agile scrum, stories, ethics, tasks, sprints. There's all this new terminology and once I realized they were collective fictions just so we could work together. They're not... Well, I'm sure everyone's very opinionated about these words. But I mean scrum master, I didn't want to say it. It was hard. So I read this great article. I can't pronounce the name of this blog but it was called my 20-year experience of software development methodologies and it kind of just explains that you can try everything and pick and choose what works for your team because if you're all sitting in a room together you're going to have a very different needs than a very distributed team. So I was very comfortable about that. In conclusions, in conclusion, agencies and consultancies are service industries, internal products are assets. So you can spend time inventing instead of repeating boilerplate specific to your company. Take the wisdom of Ember and apply the same principles of documentation and evangelism to your own internal products and get people to use the tools that you create. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Finally guys here, if we could have another video of our carpetability, exactly where we'll be making our pies. Someone maybe even thought that the shape of that existe does have a target of a
 Okay.  Let's get started.  My name is Sarah Bostwick.  I work at Pixel Agency in downtown Los Angeles.  We make websites and web apps for movie studios to promote their movies.  For those of you who are not familiar with the term creative technologist, it's kind  of an unusual title, but it's very applicable in our agency.  Basically, I have to do my dev job, but also bridge the gap with the creative team and the  business team, and pitch technology ideas and create prototypes and be an advocate for  the dev team in general.  Before becoming a developer, I was a fine artist for many years, and I'm really interested  in how web, film, and gaming are converging into one experience of storytelling.  As an artist, I was a documenter.  I cast and carved down colloquial architecture where individuals made decisions, and their  history was recorded in the objects they used every day.  When I became a web developer to pay for my art career, I thought I would naturally be  a creative developer, which is true, but not in the way that I originally thought.  As an artist and a freelancer, I got a bit lonely, so I started working at Pixel as the  sole developer, which didn't really help, but then our team quickly grew.  We're now about 20, with like four or five developers and contractors.  At Pixel, I fell in love with designing front-end systems.  I worked on the front-end for Foxmovies.com, UniversalPictures.com, Battle of Events.com,  where I really learned how to work with templates and work with scaling systems.  So this is my background.  These are PHP apps, but it's the same concepts of components, like these sections that can  be reused on movie pages for these three sites.  Each component can be moved around on the page and have different amounts of data.  I'd had to account for there being absolutely no data for a movie and then being so much  and having it look good at every stage.  And then from this, working on these types of projects, our company learned how to create  libraries.  So this is the social plug-in that we use, reused in each project, improving it along  the way.  This is Swiper.js, which I love, I put it everywhere.  It's a responsive carousel JavaScript plug-in.  And then we also do one-off sites for movies that are done in Ember.  So Ember, the way we use it as an agency, it's not to create ambitiously large apps,  it's to create ambitiously fast.  They made apps because our creative team comes up with solutions in very short timeframes  because we'll get the art from the studios and then immediately we need to make something  with it.  So this is an example where the user can make a custom movie poster with their face in it.  And then you can customize the text on it.  And internally we call this app the face-in-hole, so it's sort of like the boardwalk and you  have the cutouts of the mermaid and you stick your face in.  It's like an early selfie idea.  And so this is the same code base, but it's for animal ancestry.  This is my cat Buster as Diego.  This is Zoe as Idris Alba's girlfriend for the Mountain Between Us.  And this was something we did in February just when we thought this code base was never  going to be used again.  They were like, we would like this in a week.  So here is a promotion for Love Simon, which is a teen coming out story so you could create  a Valentine that posts on social media.  So this is last year's survey, but I'm thinking it didn't change too much.  And this sort of idea that most people in this room are working on a product.  And I think as a freelancer or an agency, we do much smaller scale things, but Ember  still works really well for us.  So I wanted to tell this story of how our agency learned about product development through  Ember.  So we're in the 10 to 13% of doing client work category.  So some of the terminology I'm going to use in the talk is when I'm talking about products,  I'm talking about something that is built and then sold.  So the features are defined.  There's an MVP as created.  The product is sold.  And then features are added and it just continues on.  And then projects are sold and then built.  So like a project has a scope of work, a client agrees to pay for the project and the project  is executed.  So these are totally different business models.  So why would you, you know, turn projects into products to make more projects?  Let's see here.  Trying to go to the next.  So who is this talk for?  These consultancies, freelancers, like anyone using internal tools for repeated projects.  So why would you follow this project to project to project to project to project pipeline?  One reason is to create company assets.  So as an agency or consultancy, you're in the service industry.  So your assets are the talent in the room.  So how do you hold on to that knowledge?  One way is to create libraries and templates and add them that you can pass on to the new  developers.  It's a way to revisit your work, your past work in an organized way.  And you can make incremented document improvements to that.  And also, you know, the boilerplate features are done.  So then you can spend time polishing and being more creative.  So the outline of the talk, I'm going to have a case study of face and haul sort of, and  then provide a checklist to decide when to commit because it is a lot of work and at  what point is this a good idea?  Tips for templatizing a project, some pitfalls you can run into, templates versus add-on,  when to choose between the two types of internal products, and some resources.  So this is an app that we made for I say it's two years old, so if there's any bugs, don't  tell me about it.  It's like I built on Ember 2.3, but it was the most fun example, so that's why I picked  that one.  So this is actually a video walkthrough, so I wouldn't get hung up here.  So the app has like a little intro showing you why you would use it, kind of explaining  what happens if you upload a picture and the result you're going to get.  So they kind of play with the characters.  So you upload a picture of your pet, basically, and you can transform them.  Okay.  So here I'm uploading a picture of Tomster, and he goes on to an H. Will 5 canvas, and  we use Fabric.js library, so it can be cross-prouser.  It makes everything easier.  And then you can add pictures on top, but the same app, like you can add text on top,  you can have branded pictures behind, and it's easily adapted for new use cases.  But the thing that we wanted to remember was that the user wants to go to the next section  or they want to be able to go back and fix their app, so these decisions were, they were  all pre-made, and slowly they came into a llama.  Sorry.  I got kind of into it in the video.  He's still going.  Add a tail.  So he's got a lion tail now.  But luckily, I think this is the end here.  Oh, no.  Ears.  Okay.  So then we can add his name, and then we can make that sort of leaderboard of what animals,  what characters Tomster is now.  And then we don't create the share asset right away.  We do it when the user clicks the share button.  This is a COPA compliant app, so like children are already going to be using this, and there's  laws against social activity for children.  So we generate the share asset with PHP when you push the button, so we didn't have to  create so many pages, but we wanted to have this metadata page with the Facebook share  asset that's custom to the one that you made.  And then you have a pre-populated tweet, and then you can also just download the asset  because it's a square asset that you can share on Instagram.  And there it is.  So that's the basic app.  So why I feel like this work is a good example is it has consistent functionality and user  flow.  So we were able to talk well between all of our teams, and they kind of stuck with what  we had already, the base features that we already had, and then they just added onto  that.  And this template was easily, we could customize it really easily because it's all in one  code base.  Like we had all the projects are branches off of master, so I could see all my past work  in one place, or our whole team's past work in one place.  And then when we had different clients, we just pushed to another remote because you  can push to different remotes.  And I worked on other projects where this didn't work as well.  It was too locked in.  I was afraid to change anything because it would affect other projects, but this way  it's all siloed, and you can do whatever you want with it.  And then we kept it up to date, which is a small miracle.  And it has good documentation.  There's versioning, Wiki installation guide.  I made some of these things for the talk, but they exist now, and we're going to keep  going with it.  And also evangelism.  I mean, these are all things that I've learned from Ember, and why we all like to use Ember's  because we know how to use it, and we know what features exist, and I think we can learn  a lot from that and use that in our own companies.  So this is a picture of the GitHub, just all the projects we've ever done.  There's like 20 branches of it.  And here's the Wiki.  This is my first Wiki.  This is only good for new developers, but because my creative team is never going to  go to the GitHub and read up on my products, but it's good for contractors and new devs  so they can see what the app is about.  And I had links to asset requirements and design templates and features that exist and  things I want to change.  And there's the user flow that I made for this talk that was really fun.  I used Lucidchart.  I originally thought this was out of my domain, but I think probably a lot of you in this  room have written user flows, and it's a good way to say when is it going to be safe  to database, and also the creative team can look at this and they know what's available  to them.  And I also made this UX doc because all of our projects are so fast.  People will just look at past projects and then make a design really quick because there's  no time.  So I actually made this UX after I've made the app many times.  So I really understood the general idea and how to...  I don't want to just keep making the same thing over and over again.  I want to keep it open enough so people can make creative decisions, but I do want them  to tell the introductory story and show the user what they're going to be making and the  fact that you can add pictures or tags and the share flow.  And the whole point of the app is these end assets that the user is going to share.  And here's a Photoshop template, but what I liked about this is each layer is a state  of the app.  So it's all in one place.  And it's kind of open.  They can do whatever they want to it.  This is what the app looks out of the box.  It's not beautiful.  I wanted to keep it sort of unstyled so you don't get locked into certain decisions and  you can make whatever you want with it.  And these are all the available options.  So a new developer can just spin this up and they can see that you can upload a photo or  use a webcam or use photos from Facebook.  Here I use the webcam in middle of the night.  And you can change the exposure.  You can add pictures, text, and then...  Anyway, so moving on, this is my first attempt at versioning.  So I just followed Ember's example.  I used the GUI on GitHub.  That was really easy.  And you just type in your tag here, your title, and your description.  And then there's this helpful documentation off to the right saying exactly how semantic  versioning works, which was really helpful.  This is just a picture of our internal wiki, which I hesitate to do because I'm duplicating  information from the GitHub and also doing it in internal wiki.  But my design team, again, is never going to go to GitHub.  They don't even have GitHub accounts, so it's really important that they understand what's  available and that this tool exists and that there's these templates that they can start  from, so they don't have to reinvent everything every time.  This is an example of...  I feel like my documentation is really serious.  And I think it's helpful, and I want people to read it, but my colleague, Azu Ruli, wrote  three pages of documentation about Fox movies, and then I came across this.  And it's just some general advice about staying hydrated.  And you would think it's just sort of this extra thing and it could get in the way, but  I mean, obviously, if you're on the wiki, you don't know what you're doing, so it's  kind of nice to have this little friendly language in the middle there, so you actually  read closer because you're looking for the jokes.  Because I feel like when I read documentation, I just skim it.  So I thought this was good advice.  And it's good advice to stay hydrated.  So sort of a project to product checklist.  You have similar projects requested multiple times.  You have faster around that would benefit from boilerplate.  You're revisiting your password for the good parts, and if it's mostly the same thing,  you're just copying the app and then changing it.  Like that might be a good template, but if you're picking and choosing little pieces  from different projects, maybe those are good add-ons or libraries.  So here's a quote from Robert Jackson.  So you can, NPM can easily install from Git.  There's no need to publish an add-on to NPM to consume it.  Obviously, at Ember Comp, we're going to encourage everyone to make their add-ons public, but  if they were needed to be private, like you can include them in your repos this way.  So if you wanted to make internal tools, this is a good way to include it.  You just have your repo name and your address and then some tag, some point in time in your  library.  So some pitfalls that you can run into.  The designs and functionality changed too much.  So maybe you didn't communicate with your whole team exactly what existed, and they  made something crazy, and you can't even use your template, so you should just start over.  Maybe their product is too general.  Like you're recreating WordPress, and you could just use WordPress.  So choosing between a template and an add-on, like we have a lot of libraries that we can  piece together quickly to create these custom websites for our clients, but maybe we could  piece together commonly used ones, so you have sort of this combination add-on and template  together.  So what do I mean by templating?  I'm talking about something that has like a base app with a defined user flow.  So not just like handlebars templates, which maybe some people are just thinking about,  they're all slow templates.  But I think the key to good templating is to be specific but open.  So having your class names and JavaScript language be specific to the functionality,  open enough to be used in different places.  So as the saying goes, naming things is hard.  Some things for templating that I found helpful were to print out the wireframes and cut them  up.  This is like an idea from Atomic Design, where you can piece, by cutting up these physical  pieces of paper, you can kind of see where the repeated patterns are, and you can just  write on those little pieces of paper, like what they're called.  And also you can work with your UX designer to name things, so you're all agreeing to  call things the same thing.  So we've gone so far as to make a Google Doc to share with the client.  So when you're talking about a component, like they know what you're talking about,  and they're not calling it a module or a section, and everyone's on the same page.  I'm also a big fan of EM.  I know Functional CSS is very popular too, and they're not mutually exclusive, I don't  think, but I think EMBER really lends itself to this namespace component structure.  And so I really enjoy that style of CSS, because it enables you to scale your applications.  And also EMBER really made it possible to have a living style guide.  I've always read about it and wanted to do it, but it didn't seem quite like I was going  to keep it living.  But for EMBER, you just put all your components on a page, and you have to feed it the data  so you can see the components.  But you can actually see when your styles change or your components change, and you can share  it with your designer, and they can see what components exist in your app.  And so when they create a new page, they can just reuse what's already built.  Some tips about template configuration.  Like we use setting style sheets, initializers for the JavaScript, and services for data.  Our apps don't use EMBER data most of the time, because they're so small, but it is  nice to have a configuration file so when you can switch out the title and the metadata  really quickly.  So this is just an example of how I set up my CSS.  I mean, obviously the component folder might change after this week, yesterday.  But we have a color settings file, a default, typography, mix-ins, animations.  This is an example of a typography config file in component style sheets.  So the reason why I like BAM is because you can just take the component name and put it  as a class name on the component itself and name the style sheet the same name so you  can find everything.  And I thought about creating an extension of the Blueprint generator to just automatically  add that class to the components so then I have a starting place.  And then, we have a root type.  There's two types, application initializers and application initialize, instance initializers.  For the face and hole we have an application initializer to configure Fabric.js so you  can set the corner shapes and things like that before the application boots.  And then services, a service is an Ember object that lives for the duration of the application  and can be made available in different parts of your application.  So this is an example from face and whole, like just have, we call it API, it's not an  API, but we call it that just in case we turn it into one.  So I just make a constant with all of my data in it and then resolve it in a promise so  that if we do fetch it, eventually it would all work.  So we have like settings for like the hashtag and the URL of the website and this sort of,  you can see like where it's configured, there's the love Simon information.  So some resources are write the docs.org.  I really like this resource.  It's a wiki with resources for all types of documentation.  So for like technical writers, engineers, scientists, they have a conference and a Slack  channel and local media meetups.  And it's kind of nice to talk to other people who actually enjoy documentation because so  few people do.  And also I really enjoyed the closing keynote from last year's EmberConf.  It was basically about refactoring without permission and I found that really inspiring  because I did ask permission once and it didn't work out.  So you just have to basically clean your room and your code so you don't live like a hoarder  and it's great advice.  So like maintain a product as part of Project Scope.  So when you start off internal product development, you obviously need some time dedicated to  that.  And to port back features to master, I mean you should be responsible for that.  That's part of your job.  And also to give presentations to your team and let them know that it updated or give  it an announcement.  Like let everyone know that this exists.  So lastly, just wanted to mention product development terminology which I'm sure everyone  in this room uses but it was new to me working in an agency.  So we checked them all out like product life cycle, product teams, owner, product manager,  agile scrum, stories, ethics, tasks, sprints.  There's all this new terminology and once I realized they were collective fictions just  so we could work together.  They're not...  Well, I'm sure everyone's very opinionated about these words.  But I mean scrum master, I didn't want to say it.  It was hard.  So I read this great article.  I can't pronounce the name of this blog but it was called my 20-year experience of software  development methodologies and it kind of just explains that you can try everything and pick  and choose what works for your team because if you're all sitting in a room together you're  going to have a very different needs than a very distributed team.  So I was very comfortable about that.  In conclusions, in conclusion, agencies and consultancies are service industries, internal  products are assets.  So you can spend time inventing instead of repeating boilerplate specific to your company.  Take the wisdom of Ember and apply the same principles of documentation and evangelism  to your own internal products and get people to use the tools that you create.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Finally guys here, if we could have another video of our carpetability, exactly  where we'll be making our pies.  Someone maybe even thought that the shape of that existe does have a target of a
Reuse__Recycle_0_383.png Reuse__Recycle_384_527.png Reuse__Recycle_528_1007.png Reuse__Recycle_1008_1235.png Reuse__Recycle_1236_1571.png Reuse__Recycle_1572_3095.png Reuse__Recycle_3096_3311.png Reuse__Recycle_3312_5735.png Reuse__Recycle_5736_6563.png Reuse__Recycle_6564_9563.png Reuse__Recycle_9564_10163.png Reuse__Recycle_10164_10871.png Reuse__Recycle_10872_11411.png Reuse__Recycle_11412_11459.png Reuse__Recycle_11460_11531.png Reuse__Recycle_11532_15239.png Reuse__Recycle_15240_24167.png Reuse__Recycle_24168_24407.png Reuse__Recycle_24408_25487.png Reuse__Recycle_25488_27743.png Reuse__Recycle_27744_28727.png Reuse__Recycle_28728_29291.png Reuse__Recycle_29292_29339.png Reuse__Recycle_29340_29663.png Reuse__Recycle_29664_29771.png Reuse__Recycle_29772_30035.png Reuse__Recycle_30036_30359.png Reuse__Recycle_30360_33947.png Reuse__Recycle_33948_34871.png Reuse__Recycle_34872_35003.png Reuse__Recycle_35004_35303.png Reuse__Recycle_35304_35711.png Reuse__Recycle_35712_37415.png Reuse__Recycle_37416_37955.png Reuse__Recycle_37956_38567.png Reuse__Recycle_38568_38687.png Reuse__Recycle_38688_38802.png