Full Stack Engineering - April 29th, 2014 @ Full Stack Engineering Meetup NYC
•Transferir como PPTX, PDF•
1 gostou•585 visualizações
Discussing the nature of Full Stack Engineering practices and standards at Huge. This presentation is focused on web engineers at all points of the spectrum. From seasoned developers through to new comers. Hopefully this provides some interesting insights into how to manage many stacks in an agency world.
Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (11)
Semelhante a Full Stack Engineering - April 29th, 2014 @ Full Stack Engineering Meetup NYC
Semelhante a Full Stack Engineering - April 29th, 2014 @ Full Stack Engineering Meetup NYC (20)
Último
Último (11)
Full Stack Engineering - April 29th, 2014 @ Full Stack Engineering Meetup NYC
- 1. April 29, 2014 Full Stack Engineering 45 Main St #220 BKLN / 718 625 4843 / hugeinc.com
- 2. Full Stack Engineering. @ MeetUp! April 29, 2014
- 3. 1. Huge & Me. 2. Things I’ve noticed. 3.Acronyms Don’t Matter. 4. Choosing Tools. 5. HugeBrewsApp. Agenda
- 4. Huge.
- 6. We build Huge TV’s...
- 7. And we brew beer…
- 8. Karl Stanton, Director Front-End Engineering Australian, started coding in early 90’s, have been a full stack developer since early 2000’s @karlstanton
- 9. (Photo credit: Ovidiu Ocnaru) This is how I feel…
- 11. Some things I have noticed over the past few years: 1. There will soon be no “sides”. 2. Server-side JavaScript is paving the way. 3. JSON is the dominant data format. 4. DevOps is not a career, it is a skill.
- 12. Some things I have noticed over the past few years: 1. There will soon be no “sides”. 2. Server-side JavaScript is paving the way. 3. JSON is the dominant data format. 4. DevOps is not a career, it is a skill.
- 13. Some things I have noticed over the past few years: 1. There will soon be no “sides”. 2. Server-side JavaScript is paving the way. 3. JSON is the dominant data format. 4. DevOps is not a career, it is a skill.
- 14. Some things I have noticed over the past few years: 1. There will soon be no “sides”. 2. Server-side JavaScript is paving the way. 3. JSON is the dominant data format. 4. DevOps is not a career, it is a skill.
- 15. 15 Atypical interview question: It’s the world cup. Architect a single page application that shows the top most tweets with the hashtag #GER & #BRZ
- 16. There’s no such thing as: “that’s not my job”.
- 17. 17 Don’t be a letter in an acronym…
- 19. Process does. Acronyms don’t matter:
- 20. Each stack at Huge must: 1. Have a standard. 2. Contain unit tests. 3. Be deployable at any time. 4. Be reusable. 5. Be automated.
- 21. Each stack at Huge must: 1. Have a standard. 2. Contain unit tests. 3. Be deployable at any time. 4. Be reusable. 5. Be automated.
- 22. Each stack at Huge must: 1. Have a standard. 2. Contain unit tests. 3. Be deployable at any time. 4. Be reusable. 5. Be automated.
- 23. Each stack at Huge must: 1. Have a standard. 2. Contain unit tests. 3. Be deployable at any time. 4. Be reusable. 5. Be automated.
- 24. Each stack at Huge must: 1. Have a standard. 2. Contain unit tests. 3. Be deployable at any time. 4. Be reusable. 5. Be automated.
- 25. Choosing Tools.
- 30. (Photo credit: Ovidiu Ocnaru) Remember this?
- 31. Client Express NodeJS Client JavaScript .NET/HTML SiteCore 7.0 JavaScript Linux Prototyping Stack vs. Development Stack Windows * JavaScript including jQuery Compass CSS CSS HugeInc.com Hogan/HTML Compass
- 32. Client Express NodeJS Client JavaScript .NET/HTML SiteCore 7.0 JavaScript Linux Prototyping Stack vs. Production Stack Windows * JavaScript including jQuery Compass CSS CSS HugeInc.com Hogan/HTML delivery1 author1 delivery2 Compass
- 33. Demo.
- 34. HugeBrews Demo:
- 35. 35 Objectives. • Collect beer rating data in Google docs • Check each rating into Untappd API • Store reference of beer data in local database • Display results
- 36. Client PHP/HTML Apache MongoDB Client Express NodeJS Mongoose MongoDB JavaScript Linux Prototyping Stack vs Production Stack Linux * JavaScript including jQuery Hogan/HTML HugeBrews Backbone Bootstrap
- 37. Questions?
Notas do Editor
- Thanks for having me. I’m looking forward to sharing some insights about my experiences with full stack engineering as well as how we tackle projects at Huge
- I work for Huge700+ people world wideOffices in BK, LA, DC, ATL, PDX, LDN, RIOOffice in DUMBO with lovely views of ManhattanWe’re a full service digital agency – with a strong love for technologyWe’re hiringWe sometimes make websites
- A little bit about HugeGreat maker space where we make stuffGoogle Glass, Oculus Rift, Arudino’s, Raspberry Pi’sFrom model cars to raceTo taps for our kegerator
- Left: Huge TV #2 – Weather, tech news, train schedule, beer o’clock, our twitter and honey posts- Runs on Backbone + Node and talks to a bunch of API’sCenter: Honey – our own product (www.honey.is), helps us keep in touchRuns on Python + Node , custom jQuery framework being ported over to angular Right: Huge TV Calendar – lists events by grabbing in data from a private calendar on Google – backbone node, there are several in the office that are controlled by office teamWill be open sourced shortly
- We’ve brewedStout, IPA, Milk Stout, Brown AleWorking on arduino’s to help with the fermentation processWorking on apps to show our ratings which I’ll demo later
- Been at Huge for over 3 yearsManage a team of over 20 front end engineers where our core disciplines include everything front end related but more and more full stack development which I’ll get into a little laterI’ve been working in agencies on and off for 15 years – worked on many different stacksI had a young stint in Bulletin Boards for around half a decade before the internet – my first real stack was DOS and EzyCom BBSOriginal stack was Flash / HTML sitting on top of Classic ASP and PHP 3
- If you get the metaphor, then you probably feel the same way, too … but we’ll get back to this later
- Feelin’ kinda old – some of what I’m about to talk about is obvious but I wanted to talk through a few points that are important
- Having been in the industry for a long time, there’s several trends I’ve noticedThenotion of strict client “side” vs server “side” developers are going away. The more “front end engineers” I interview, the more full stack questions I’m askingIt’s not just for engineers – I believe UX and Visual Designers will soon be expected to understand the fundamentals of web development and code and prototype on their own, and in that ilk, I would soon expect all engineers to embrace the entire stack not just their area of expertise Sure there are people who are specialists in their own right, but the line between client and server side development is very thin – you must know your stack in all directions
- The backend was mostly a foreign place for front end engineers before NodeJS. Javascriptbeing such an accessible language, it’s easy to dive into javascript in any context, whether it be building a carousel, creating a RESTful API, or writing JSON
- RESTful services, API’s and NoSQL really helped push JSON into the corporate mainstream. Less XML, more JSON.No more need for SQL architecture and SQL learnings, people can write and read JSON. What JSON goes in, you know can come out.This especially helps with working with data as direct mapping of objects to models in Backbone for example … it is fairly seemless compared to SQL
- I think this is one of the most important points we can make when talking full stack. For those fortunate to have them, It’s easy to rely on DevOps (the person) to get things done, in the same way it’s easy to lean on a front end developer to make clickable wireframes…As an engineer - without a core understanding of the platform / framework / stack you are working against, you are already at a disadvantage – which is why learning DevOps skills is so importantWe have SysOps engineers @ Huge who’s sole focus is on building and maintaining integration pipelines, platforms and systems amongst other things, but that doesn’t mean I can’t spin up a new instance on AWS, setting up my own CI pipeline, etc… it’s a skill. This is the SysOps area of expertise, but it’s a skill we all most learn to embrace
- As leaders, mentors, managers, business owners, etc … How do we achieve that shift in thinking? Well we can start by asking the right questions…[Interview Q]I love this because it opens so many doors for questioningAre you going to use search or the streaming API’s? What stack will you use? What about caching? The front end? How does it work? The conversation could go on for days… but ultimately:I want all engineers on my team to be thinking holistically about the stack, and not just their part.There’s a saying @ huge that [next slide]
- We are all responsible for the stack. If you’re delegated to work on the front end but are blocked by a service that doesn’t existing yet – dive in! Learn! Contribute to all areas! We are all here to grow and learn together, so nothing should be someone else’s job – it’s yours, it’s mine, it’s everybody’s, let’s get it done.I like this in the context of “QA”. Quality assurance isn’t a job, everyone must assure quality – but an Engineer who tests or “Engineering in Test” is a position with a core focus on testing. If you get through your sprint, feel free to jump in on stories that are ready for testingJust something to think about…
- I guess what I’m really saying is don’t be a letter in some acronym …
- You could be MEAN, LEAN, BEAN, LAMP, STAMP etc… it doesn’t matter
- So how do we tackle this in an agency environment?Huge has many projects, on many stacks… in fact many projects are different for many reasons, could be the client, could be the engineers exploring new technology, what matters most is we stay aligned with our core beliefs and standards
- While we’re not perfect, we are striving for success by making sure each stack must [read list]Coding standards are impossible to control across many projects – but each project should have a standard that they controlWe have a boiler-plate front end standards document for just the front end that covers the basics. It’s up to the lead to decide, but any engineer can contribute to that standard – so it ever evolves
- Self explanatory…
- We strive to be able to deploy to production from day one. Getting “Hello world” to production is harder than you think if you follow these rulesCan you deploy your prototype to production and iterate on it through development? There’s a lot more involved than one might think. I challenge you on your new projects to get this stack built.This allows you to constantly develop against your environment and learn its quirks.It forces you to ensure your unit tests are passing every time you attempt to commit your codeIt also allows you to ultimately focus more on features than perhaps fixing your stack, because you’re ever evolving your stack with these features
- Code must be reusable. Responsive code? Logins? Front End modules/components? Commerce? Why invent the wheel each time? Simply improve and iterate.The same applies to standing up VM’s. If we have a Sitecore or CQ enterprise build we need to focus on, we shouldn’t need to reconfigure everything again – reuse your scripts to build and configure the environment for you. We do this already by keeping our tweaked boilerplates handy in Git. Simply reuse the boilerplate, iterate on it, and away you go.
- Of course, everything must be push button automated. Easy to say, hard to do! I’ll show a few things in Grunt that makes some things easy
- All of this is easier said than done, which is why I look at stacks as tools
- [LEARNING IS HARD AND THAT’S OK – IT’S THE MAIN POINT, BUT IT’S A CHALLENGE]Not too long ago, I kicked off a new project, I thought “great, I can go and use Node and Express and Backbone and Marionette!” – Well I ended up spending a weekend researching Githubrepositories, reading about abstraction layers, digging through countless “ToDo List” blog posts and doing tutorials rather than working on the actual task at hand, and essentially lost a weekend of productivity.As soon as I went back to scratch and started to build my prototype from the ground up, everything clicked, I was building my product --- I think this is important to note as now that I have my base, I can start applying abstractions and frameworks…
- [POP THE HOOD]This is not a dis – but when people join my team, if I see MAMP – I’ll politely ask them to uninstall it and to install homebrew, dupes and sit with the engineer to help them manually configure apache, php and mysql. Also, I would go as far to say for newer stacks, don’t let bundles like Yeoman do the heavy lifting for you at first, but instead have a crack at building it yourself and understand the processes behind what Yeoman is actually doing… If you’re at the point where your project is ready for production and you don’t understand how the majority of the 3rd party modules, plugins and frameworks are working, you may come up on a severe knowledge gap when there’s a failure. Think about the wild west of npmmodules – there are 1000’s of them, can you support all of them in your stack if something breaks? Do they deploy and execute properly in your CI pipeline?The value in popping the hood and configuring your stack manually adds immense value to your skillset. I also think once you have that skillset – there is absolutely immense value in packages like Yeoman and Mean, and you should absolutely look at making an easier workflow for yourself.At first it is wise to understand the core as it is vital to proper maintenance, and stability up front.
- [MVP AND SCOPE PROBLEMS]Ifyou start to develop to your minimum viable product in a skeletal like fashion, you can easily and quickly start to identify gaps, problems, scope issues, design flaws, etc. You will be better off understanding that, then debugging a bundle, 3rd party module or framework…Some wise developer said that it could be better to spend 80% of your time developing your stack quickly to identify gaps, so you can spend the 20% tearing it down and building it again perfectly.Use the learning's to help define and shape your product. Coding is the easy part… there is way more value in spending time learning
- [CHOOSE TOOLS THAT CAN HELP YOU PROTOTYPE YOUR WAY TO VICTORY]faster results, spot problems earlierSpend time fixing problems detected early with YOUR code and scope, and not debugging a stack which you do not understandHaven’t learn symfony because when I tried, I spent all my time debugging – instead of building. Now that I’ve built my site, I can really appreciate the power of what symfony can do and apply it to my project and my problemsprototypes turn into real code via refactoringWe are talking through carving out special prototyping namespaces in production code so we can get quick and dirty results without impacting the stack, even going as far as allowing UX designers who want to code to access those namespaces and not effect core development.
- This is me, a dusty old LAMP developer … it’s my go-to stack for prototyping because I can work with it really FAST and get results QUICKLY…But I know it’s not glamorous nor cutting edge… but is that the point?
- What I loved about this stack was the ability to rapidly build out HugeInc’s templates, modules and components while the Sitecore infrastructure was being setupWe could already identify gaps in the ux and flow of the pagesWe could see cross browser problems with some of the designWe could focus on the finesse of responsive rather than any real integration problems
- What I loved about this stack was the ability to rapidly build out HugeInc’s templates, modules and components while the Sitecore infrastructure was being setupWe could already identify gaps in the ux and flow of the pagesWe could see cross browser problems with some of the designWe could focus on the finesse of responsive rather than any real integration problems
- We drink beer.
- It’s easy to stay a rusty dusty old lamp stack