Skip to content

Instantly share code, notes, and snippets.

@potench
Created June 20, 2012 16:45
Show Gist options
  • Save potench/2960870 to your computer and use it in GitHub Desktop.
Save potench/2960870 to your computer and use it in GitHub Desktop.
Review of TXJS 2012

Front-end Meeting June 20 2012

Agenda

  • Summer Schedules
  • show current resource board from Donna
  • not everyone has been updated on their upcoming projects - get feedback and make changes where appropriate
  • support / developer roles and levels
  • TXJS review
  • Taka and James present Ford Mustang Customizer

Weekly Links


Overview of TXJS

It's good to think about what you want to get out of something before throwing yourself into it. Obviously, keep an open mind to learning something completely off your grid, but you should be prepared to seek out answers to things you want to know about... here's what I wanted to get out of TXJS

  • find different development approaches / theories / work-flows / or ideas
  • see new development technology - (executions / frameworks / tools)
  • hear other's perspectives / solutions / or approaches to the same development problems -
  • get an inside look at common issues across other development teams

Not going to cover every last presentation... but here's a few gems.

Rebecca Murphey - the new baseline

A great way to start the conference - Rebecca takes us on a tour of development tools that you should be using to improve your workflow / efficiency / and product quality.

  • Nice to see that at RED we've discussed all of the tools mentioned and are actually using about 95% of them
  • Here's a list of tools that I want to leverage more (if you already use/understand these tools then consider giving a demo of them at our meeting)
  • AMD - rosy already promotes loose coupling - but we should continue to research pros/cons of implementing a requirejs type script-loader
  • Grunt - we use rake for most of our task management - consider migrating Taka's jake work to grunt
  • Test your javascript - should use qunit right out of the gate - don't wait to write your tests - get used to using qunit (or make a case for using another test suite)
  • Debugging your javascript - utilize stepping / breaking / debugging in chrome dev tools more often.
  • underscore - 4k min'd - comes with a lot of functions that we already use maybe we should standardize on them
  • Take-aways -
  • we should continue sharing new tools with each other to keep our baseline current
  • mostly an individual effort to communicate with one another / do you want a twitter account to post URLs to or a common place to archive links?

Marcin Wichary - Google home page doodles

Marcin gave more of an inspirational talk showing aspects of his work with the Google logo. You'd gain more by watching his presentation than me providing insight on it.

  • http://aresluna.org/ - check out his work
  • Attention to detail / caring about your product / really shows in the end and is very rewarding - people will notice
  • Sacrifice standards to achieve an effect - be willing to break the "rules" to improve your work - the experience is your standard.

Tom Dale - Ember JS

  • Choosing solutions that are too simple - Sproutcore is too complex (learning cliff vs learning curve) VS solutions that are often too simple and wrong -
  • file size is important - but correctness, ease of use and productivity are more important.
  • "is nodejs better" - talk from jsconf in az that tom recommends - http://blip.tv/jsconf/jsconf2012-brian-ford-6091521
  • conventions over configuration: / why are conventions good - eliminate trivial choices /
  • spend time arguing choices that matter within your specific application not with the problems that have already been solved / the problems that are unique to your app
  • reduces code - (# of bugs per line, so less bugs)
  • increases predictability -
  • Tom goes into detail on their view hierarchy and routing
    • View hierarchy - handling teardown and child-management in framework - dont rewrite the wheel
    • Routing: bring convention to state management - serializing and deserializing URLS becomes trivial
    • state charts - hierarchy is a great way to model state - explicit state objects -
    • create the richer model to describe your app state - then derive a URL to signify that (so use routing instead of URLs and URLS will fall into place)
  • Takeaways:
  • Implement a routing system... unifies our approach to app development and web development and you get URL mapping for free.

Dan Webb - Web Applications / Managing Trade-offs

  • "the web sucks" - zed a. shaw - http://vimeo.com/43380467 - angry about lack of facilities the web has for making applications /
  • maybe the web (web technology) isnt really the best place to make applications - "can i center some shit!!" - HTML5 isnt the best tool to build an app - but the web is -
  • shareable / indexable / interlinked and intertwined / masshups / accessible (as in anyone can get to it) - the web is amazing and the "web" part of "web applications" is why we try to do build in HTML
  • web development is mainly about trade-offs (somewhere between crap and shit) - making all the right-tradeoffs (being standalone vs server side - trades off scalability)
  • Twitter moved rendering back to the server --- why? -- performance / stability / maintainability - (the trade off)
  • Performance: performance is highly contextual (what is "fast"?) - performance is the perception of the user -
  • Measurement: Navigation Timing API gives the javascript a broken down timing of when things are visible between connecting, getting a response, rendering a response
  • Make your own tradeoffs - identify problems and apply and execute solutions to the problems - not just the latest tech

Jacob Thornton - twitter bootstrap and documentation

  • be willing to explore the source code -
  • stimulate people to explore - dont pave the path so much - stop being afraid
  • "Don't stop at the documentation"

Side notes

  • @fats presentation (please link if you find it) while an absurdest view does prove that the speakers and conference goers were willing to bounce new or un-formulated ideas to start discussions - they were willing to be controversial.
  • We're doing good things at RED - we're using tools / technologies as they come out and trying to push ahead of the curve, but maybe we could share more feedback or direction on how we use these things (best practices kind of thing)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment