pixelhandler.dev

Systems of Building, Not Building Systems

2026-03-05T00:00:00+00:00

Systems of Building, Not Building Systems

On containment, focus, and the practice of examining how you work

The tools are moving fast. Faster than any stretch I can remember — and I've been through a few cycles. Learn the new thing, adapt, keep building.

This time feels different. It's not a new framework or editor. It's a new relationship with tools entirely. I have an AI pair that can read my codebase, run my tests, and draft a pull request while I think through the next problem. That changes things — not just what I can build, but how I think about building.

Somewhere in the past year I noticed I was spending less time learning new libraries and more time thinking about process. How do I structure a work session? How do I make sure the code that gets generated actually holds up? How do I stay focused when the tooling makes it easy to scatter?

I think more about systems of building than building systems. There's a paradox in that. I spent years focused on designing and building systems — the software itself, the architecture, the data models. Now I find myself designing systems of building — the workflows, the feedback loops, the practices that shape how things get made. The craft evolved from what I build to how I build it.

Containment Enables Quality

That phrase — containment enables quality — comes from how Stripe designed their coding agents. They put AI into quarantined environments with clear boundaries: one task, one branch, one set of constraints. The containment isn't a limitation. It's what makes quality possible.

I've been applying that idea to my own workflow at a personal scale, across three dimensions.

Containing Conventions

Most teams have conventions. They live in a wiki, or an onboarding doc, or in the heads of senior engineers. The problem is that none of those places are where you're actually working. When you're in the middle of a commit or structuring a PR, the conventions aren't present.

I started encoding my development lifecycle — plan, implement, test, commit, PR, review — into a skill file that my AI tooling reads automatically. Not aspirational process. Honest process. How I actually work, what I actually name things, where artifacts actually go.

The effect is consistency without willpower. The conventions show up at the moment they matter — when I'm planning, when I'm committing, when I'm reviewing. They evolve as I learn. When I discover a better pattern, I update the file. It's a living record, not a frozen document.

The key insight: conventions that live where the AI can apply them are conventions that actually get followed. Everything else is aspiration.

Containing Attention

The second dimension is focus. Creating room for deep work on a single problem, without context-switching contamination.

I set up isolated environments per issue — a fresh clone, unique ports, a separate database. The skill file scopes the session to this ticket, this plan, this branch. Everything outside that boundary disappears. Spin up an environment, do the work, tear it down.

This isn't about delegating work to AI. It's about creating the conditions where you — with AI — can do focused, uninterrupted work on one thing. The isolation removes the temptation to check on other branches, fix that unrelated bug, or chase a tangent.

Creating room for focus is a deliberate engineering practice, not an accident. You have to build it.

Containing Risk

The third dimension is quality assurance — making sure that what gets built actually works as intended. Not "the tests pass" quality. Visible, verifiable proof that a solution solves the problem it claims to solve.

I picked up browser automation recently, learning Playwright as a new skill. The motivation wasn't testing for testing's sake. It was a desire to tip the balance of AI-assisted development toward delivering quality solutions. When code gets generated quickly, the risk shifts from "can I build this?" to "does this actually work the way users expect?" A passing test suite isn't enough to answer that question. You need evidence — screenshots that show the before and after, recordings that walk through the behavior, assertions that verify specific claims about what the user sees. The goal is a body of proof that you can point to and say: this works, and here's how I know.

Outside-in test-driven development became the discipline. The idea is simple: instead of starting with the smallest unit and building up, you start from the outermost layer — what the user actually sees — and work inward. As Harry Percival describes in Test-Driven Development with Python:

Working outside-in enables you to use each layer to imagine the most convenient API you could want from the layer beneath it.

Percival also makes the connection to AI-assisted development:

The best way to work with AI, you'll find that it performs best when working in small, well-defined contexts, with frequent checks for correctness.

And the classic TDD cycle — red, green, refactor — takes on new weight. As Percival puts it, you need:

The "refactor" step to try and improve the often-terrible code that the AI produced.

Working with generated code means more refactoring, not less. Automated PR reviews surface issues early, which leads to another round of cleanup. The cycle tightens: test, implement, refactor, review, refactor again. It's more work on the quality side, but that's exactly where the work belongs.

There's something else I didn't expect. Using Playwright to drive the browser — watching it click through flows, fill forms, verify results — is a refreshing break from console-based REPL (read–eval–print loop) cycles. After spending so much time in the terminal, seeing the browser do the work is wonderful. It reminded me why I got into this craft in the first place: building things people can see and interact with.

Write a failing test that asserts the behavior you want from the user's perspective. Implement until it passes. Then verify with evidence — not just green checkmarks, but proof.

Learning browser automation gave me new skills I didn't have before — screenshot comparison across branches, scripted demo recordings, and automated smoke testing. These aren't just testing techniques. They're tools for building evidence. Three layers of evidence changed how I think about quality:

Behavioral assertions — automated smoke tests that walk through user workflows. Does the record appear in the list? Does the form save correctly? Does the filter show the right results? Each assertion answers a specific question about the application's behavior.

Visual screenshots — captured against both the main branch and the feature branch, then compared side by side. You can see exactly what changed. Unintended regressions show up immediately. The visual diff is honest in a way that passing tests alone aren't.

Demo recordings — scripted video walkthroughs that document how the feature actually behaves. These serve as proof artifacts for PR review and stakeholder communication. When someone asks "what does this change do?" you have a recording, not just a description.

The outside-in workflow has natural checkpoints — moments where you pause, review, and confirm before moving forward. Capture the baseline. Review the failing tests. Verify they pass. Compare the screenshots. Each checkpoint is a decision point: does this look right so far?

Some lessons came the hard way. You learn by doing, and the doing reveals assumptions you didn't know you had. The testing practice forces you to understand how your application actually works, not just how you think it works.

In Practice: Outside-In Development with AI

Here's the current iteration of my workflow — what I actually follow today:

Ticket
  → Plan
  → Implementation (feature branch, TDD)
  → Test Data Script
  → Manual Testing (localhost, step-by-step with URLs)
  → E2E Testing (automate manual test scenarios)
      → Assertion tests (verify expected behavior)
      → Visual comparison (screenshots: main vs feature branch)
      → Demo recording (stakeholder walkthrough video)
  → Commit (specific files, descriptive message)
  → Push + Draft PR
  → Self-Review (read findings, do not post)
  → PR Comments (annotate hard-to-understand areas)
  → Team Review → Address Feedback → Merge

Outside-In TDD variant (for UI changes):
  → Plan
  → Phase 0: E2E Test Triage (new file vs existing)
  → Phase 1: Test Data Setup
  → Phase 2: Baseline Screenshots
    ── CHECKPOINT: review baseline ──
  → Phase 3: Failing E2E Tests
    ── CHECKPOINT: review failing output ──
  → Phase 4: Implement
  → Phase 5: Verify E2E Tests Pass
    ── CHECKPOINT: review passing output ──
  → Phase 6: Screenshot Comparison
  → Phase 7: Unit/Integration Tests
  → Phase 8: Demo Recording
  → Phase 9: Update Plan Doc
  → Commit → PR → Review

Browser automation brought these QA practices into my AI workflow — each one solving a real problem:

Problem	Solution
Manual QA is slow and unrepeatable	Automated smoke tests run the same checks every time
No visual regression detection	Screenshot comparison captures baseline and current states for side-by-side diff
Feature demos are ad hoc	Scripted demo recordings produce consistent walkthroughs
Bug hunting requires setup	Bug reproduction specs encode the exact steps to reproduce
No outside-in acceptance gate	Write a failing Playwright test before implementation, then make it pass
Cross-branch comparison is manual	Run dev servers on different ports per clone and compare side-by-side

With modern tooling — where AI can generate implementation code rapidly — outside-in discipline matters even more. It's what keeps the speed honest. Without it, you're shipping fast but blind. I can point AI agents at my running application and let them drive the browser — clicking through flows, capturing screenshots, hunting for regressions. During bug hunting, I reproduce issues systematically and verify fixes visually. During feature development, I have proof artifacts before I ever open a pull request.

The iteration of writing scratchpads — markdown files where I journal the problem, sketch the approach, document what I tried, record what I learned — that iteration is the system. Each scratchpad becomes a reference. Each reference shapes the next session. The workflow isn't a fixed process I follow. It's a living practice that evolves every time I sit down to work. I expect it will keep evolving.

The Practice

The tools will keep changing. The frameworks, the AI capabilities, the testing libraries — all of it will be different in a year. What compounds isn't knowledge of any specific tool. It's the habit of examining how you work.

I journal a lot — in notebooks, in markdown files, in plan documents that start as scratch and evolve into reference material. The skill file itself is a kind of journal. It records how I work today, and the diff over time shows how my thinking has changed.

Being comfortable with re-thinking is part of the practice. Adam Grant's Think Again is built around this idea — that the willingness to reconsider what you know is more valuable than the knowledge itself. A workflow that felt right three months ago might need revision. A convention you were sure about might not hold up under new constraints. That's fine.

As Brené Brown put it:

"Yes, learning requires focus. But, unlearning and relearning requires much more — it requires choosing courage over comfort."

That resonates. The small adjustments — observing your own behavior, noticing what's working and what isn't, journaling the process — those take more courage than learning a new tool. The point isn't to arrive at a perfect system. The point is to keep examining, keep adjusting, and enjoy the journey.

Freestyle skier and physicist Eileen Gu put it better than I can:

"I'm very introspective. I spend a lot of time in my head, and it's not a bad place to be. I journal a lot. I break down all of my thought processes. I think I apply a very analytical lens to my own thinking, and I kind of modify it because it's so interesting. You can control what you think. You can control how you think, and therefore, you can control who you are."

That's the real system of building. Not the tools, not the workflow, not the skill file — though those matter. It's the willingness to look at how you think, break it down, and modify it. The containment that matters most is the one you apply to your own thinking: scoping it, examining it, refining it.

The tools will keep evolving. Build the practice of examining how you use them, and the rest follows.

Turning Your Spreadsheet Budget into a High-Performance Gearbox

2026-01-20T00:00:00+00:00

Turning Your Spreadsheet Budget into a High-Performance Gearbox

How Gnar.li Budget lets DIY budgeters keep total control while ditching the copy-paste grind

There is a particular kind of satisfaction that comes from a well-organized spreadsheet. Every dollar mapped to a row. Every formula aligned. The numbers reconcile, and for a moment, you feel completely in command of your finances.

Then month two rolls around. And month three. And suddenly that satisfaction curdles into something else: the copy-paste grind.

The Spreadsheet Trap

I've spent years building financial models in Excel and Google Sheets. I love the visibility, the control, the ability to trace exactly where every dollar flows. But somewhere around the tenth monthly import, the ritual started feeling less like financial mastery and more like data entry purgatory:

Manual CSV imports — dragging a bank export into a sheet, hunting for the right column, fixing date formats, hoping I didn't shift a decimal.

Error-prone categorization — one typo in a category sends a whole batch of expenses to the abyss.

Monthly maintenance overhead — rebuilding the same budget skeleton, reapplying the same formulas, wondering if I missed a line item somewhere in the chaos.

The spreadsheet gave me control, but it extracted a tax: my time, every single month.

What If You Could Keep the Control and Ditch the Chores?

That question led me to build Gnar.li Budget — a web app that lives inside the same mental model spreadsheet users already have, but automates the repetitive plumbing that never changes.

The philosophy is simple: every dollar gets a job. Capture, setup, review—a habit loop that keeps you in control of your money, not the other way around.

Gnar.li Budget keeps that line-by-line visibility and explicit tagging you love. It just removes the copy-paste ceremony that makes budgeting feel like a chore.

The Story Behind the Code

Gnar.li Budget started as a Rails 8 prototype to scratch my own itch. Early on, I added the features I was missing in my spreadsheets:

Eight-step onboarding that mirrors the spreadsheet setup you already perform — add accounts, map CSV columns, define categorization rules, schedule recurring bills, set a payroll-aligned budget period, then import your first batch of transactions.

TagMatcher engine with 12+ default categorization rules you can edit, extend, or replace with regex patterns. They work like your custom IF statements, but you write them once and they apply forever.

63+ default spending tags organized into seven groups (Income, Bills, Giving, Savings, Debt, Flexible Expenses, and Transfers) — the same categories you'd build in a spreadsheet, pre-configured and ready to use.

Automatic transfer matching — the double-entry bookkeeping you manually enforce in a sheet now happens behind the scenes, keeping assets and liabilities balanced without extra rows.

Scheduled and upcoming transactions — recurring bills appear as future rows so you can forecast cash flow without adding placeholder entries yourself.

Every piece is opt-in. If you prefer to hand-code a rule, you can. If you want the app to suggest a tag, it does so without overwriting your choice. The result is a zero-access, privacy-first environment that never reaches out to Plaid or any third-party aggregator. Your CSV files stay on your machine until you upload them. Your bank credentials are never shared.

Feature-by-Feature: Spreadsheet to Gnar.li Budget

Here's how each feature maps to the workflow you already know:

Manual CSV Import — replaces VLOOKUP column alignment, date format fixes, decimal hunting
TagMatcher Rules — replaces reusable IF/THEN formulas that auto-categorize rows
Transfer Matching — replaces manual double-entry rows for credit card payments and cash withdrawals
Scheduled Transactions — replaces copy-paste placeholder lines for recurring bills
Upcoming-Through Forecast — replaces adding a "future" column to project balances
Budget Cloning — replaces copy-paste last month's budget rows into a new sheet
Budget Averages Report — replaces AVERAGE formulas across historical spending to suggest amounts
Snapshot Views — replaces filtered pivot tables for specific spending categories
Insights Dashboard — replaces hand-built charts for monthly trends and category breakdowns
Custom Reports — replaces building and exporting reports to CSV for downstream analysis
Split Transactions — replaces manual row splitting when one purchase spans multiple categories
Statement-Anchored Balances — replaces reconciliation formulas that anchor to bank statement closing balances
Complete Data Isolation — each user's data is completely separated via authorization policies
Multi-User Account Sharing — replaces emailing spreadsheet copies or sharing credentials; invite family or partners with View Only or Manage access levels

How the Workflow Actually Feels

Create a new budget — click "New Budget." The app automatically sets the date range based on your payroll schedule and clones the previous month's line items. No copy-paste required.

Import your CSV — map the columns once (checking, credit, cash). The import runs TagMatcher, flags duplicates, and creates upcoming transactions for any future-dated rows.

Tweak line items — just like editing a cell. Change any amount, and the app instantly recalculates totals, cash flow, and the projected balance.

Add a one-off transaction — hit "Add Transaction," fill the fields, done. No need to open a separate sheet or scroll to the right row.

Split or transfer — select a row, click "Split" or "Transfer," and the double-entry entries appear automatically. One $50 grocery trip that included $10 of household supplies? Split it in two clicks.

Forecast forward — set the "upcoming through" date and watch projected balances extend into the future, exactly as if you'd added a "future" column in your sheet.

Review insights — jump to the dashboard for a visual sanity check (monthly spending trends, top categories, income vs. expenses), then dive back into the transaction list to adjust any line.

Share with family — invite a partner or family member to view or manage specific accounts. They see only what you share, with granular View Only or Manage permissions.

All of this happens without losing the audit trail. Every transaction still lives as a discrete record you can edit, delete, or recategorize at any time.

The Gearbox Metaphor

Think of Gnar.li Budget as adding a high-performance gearbox to the car you already built.

The engine — your spreadsheet mindset, your line-by-line control, your explicit tagging — stays exactly the same. You still decide every gear change.

The gearbox — Gnar.li Budget — handles the clutch work: syncing imports, auto-matching transfers, projecting cash flow, surfacing insights. All while keeping the driver firmly in control.

You're not handing over the wheel to an algorithm that decides where your money goes. You're offloading the repetitive plumbing so you can spend more time analyzing, optimizing, and iterating on your budget strategy.

Learn the System: The "Every Dollar's Job" Course

If you want a guided walkthrough, check out the free Every Dollar's Job course — nine modules designed to mirror the workflow spreadsheet users already follow:

Preparation — gather take-home pay, fixed expenses, variable costs, and debt information
Why a Budget Matters — the philosophy of zero-based budgeting
Gather & Clean Data — import CSVs, set opening balances, create basic TagMatcher rules
Build Your First Budget — use the Budget Averages Report to suggest amounts based on actual spending
Fine-Tune TagMatcher — advanced rules with priority ordering and regex patterns
Scheduled Transactions & Goals — automate recurring bills and budget for savings intentionally
Daily Tracking — 2-5 minute check-ins using snapshot views and cash flow forecasting
Insights Dashboard — analyze spending patterns, category trends, and income vs. expenses
Sustain Your Budget — statement reconciliation, habit formation, and long-term maintenance

Each module runs 10-15 minutes. Complete them at your own pace. By the end, you'll have a working budget system that runs faster than any spreadsheet you've built.

Getting Started

Sign up at budget.gnar.li — the first 100 monthly active users get free access
Walk the 8-step onboarding — accounts, import maps, tag matchers, scheduled transactions, payroll schedule, budget, import
Generate demo data — three months of realistic sample transactions to explore risk-free before importing your own
Take the course — Every Dollar's Job walks through the entire workflow

TL;DR

You already know how to track every dollar. You've built the spreadsheets. You've written the formulas. You've done the work.

Gnar.li Budget keeps that control — the line-by-line visibility, the explicit tags, the audit trail — and adds automated CSV import, rule-based categorization, transfer matching, scheduled transactions, cash flow forecasting, and a clean insights dashboard.

Stop copy-pasting. Start analyzing.

Give it a spin, clone your first budget, and see how many minutes you shave off the monthly grind. The spreadsheet you love stays intact; the app just makes it run faster.

Happy budgeting!

Next Steps

Join the beta — explore the onboarding and let me know which rule or report saved you the most time
Share feedback — input from DIY budgeters like you shapes the next iteration
Stay tuned on Gnar.li Budget Insights for deeper dives into supported features

Remote Work

2020-03-10T00:00:00+00:00

This is what I propose as a distributed (remote) workplace manifesto...

Results only work environment is the way of the remote worker, make that common.
Help everyone with meeting online, have a zoom # (video conference) in all meeting requests, have someone available on the Slack chat to reach out to be sure everyone can join, as a fallback use the dial-in phone number. Everyone can use Slack on their phones.
Meetings need a facilitator to be sure the agenda is on track and all voices have an opportunity to communicate, including onsite and distributed team members.
If it didn’t happen online, it didn’t happen. Use collaboration tools such as the Paper/Google Docs/Discourse/Notion to capture and share dialog – to provide easy access to meeting notes/agenda and take away actions.
Status meetings are for connecting not just status, come prepared. It’s a good idea to copy status into a Slack chat before/after the meeting - anyone can do this, and everyone benefits.
Flying solo is not sustainable (like scuba diving alone is not safe). Remote team members should have a pair whom they can collaborate with; someone who understands how to work remotely or is willing to learn. Remotes can help demonstrate how.
Favor asynchronous communication, when synchronous dialog is needed, send a calendar invite.
Being inclusive of remotes is encouraging diversity. A good idea can come from anywhere and anyone, a diversity of ideas and workplace experiences strengthens culture.
Build a rapport with the team. During the 1st year, a remote team member should work onsite 2-4 weeks. Bond in real life.
Deal direct, don’t save a conversation for someday down the road. Remote collaboration does not come without challenges, keep the discussion open among team members.
Empathy is key, we don’t know others’ situations - so be sure to understand, use video calls (zoom) often as you need. Much of our communication is non-verbal; and can be done remotely, not just in-person. By understanding another person’s situation, we can avoid the “fundamental attribution error.”
Say thank you, remote team members miss the “water cooler” chatter; which is good for focus. A quick “thank you” helps recognize effort, commitment and results – it’s an easy way to make a connection. Do it with Tacos in Slack as well.
Be patient. “If a thing is worth doing, it is worth doing badly.” Skills are sharpened by practice.

For the occasional work from home experience (flexible schedule) not all of the above apply. Below are a few tips...

Not every meeting needs to include video (or face-to-face) interactions. Make sure you keep communication open and timely. For online meetings set a backup plan, perhaps the primary tool will be an online meeting and the backup may be a conference (call-in) phone number. Decide this in advance of the meeting start time
Show up and dress for work, wherever that is. Choosing where to work affords who has the privilege of interruption. Working at home can mean that loved ones are close by; don’t shut them out, agree on a time to connect. And give them some hugs too.

Working remotely does come with some challenges and an adjustment for both onsite and remote individuals.

Perhaps one of the more difficult parts is for people who are accustomed to a realtime synchronous conversation (shoulder to shoulder). The minor audio delay in zoom meetings throws them off. Most audio/video conferencing tools have a slight audio delay. Knowing when to interject or speak up can be a challenge. A moderator can help, a visual signal can help too - 1 finger up for next, 2 fingers up for 2nd. Finding a place to meet via zoom is a hurdle for HQ desk workers. Onsite team members can help by using a good headset and overcoming hurdles of chatting via zoom while at their own desk. they're not interrupting (local) coworkers when meeting online with a (remote) coworker at their own desk.

One thing I advocate is taking breaks, a change of context can be valuable. I take a walk to get away from my laptop. Over the years, I’ve walked and talked when having tough conversations. Walking raises my heart rate, increases blood flow and causes changes in my breathing pattern, which forces me to focus and choose my words carefully.

For those with loved ones at home… the biggest adjustment is not just you working from home. The adjustment may be difficult for loved ones who’s home has been interrupted with work. If you have a door use that when you are in a meeting or need focus; otherwise, keep the door open for loved ones to come and visit with you. It’s ok to be present at home. I would listen as my kids stopped by to chat, validating their wishes. At times a pet would accompany me while I work, even in meetings. One thing I practice for my little ones… ask them what they wanted to do after lunch, so they knew I would make time for them. Being present lets them know you care. Helping your family with expectations helps them adjust to you working in the home. It’s also very rewarding, one day they may no longer be close by - enjoy the people close to you.

Regardless of working onsite or remotely, one important concept that I advocate for is... I share with my team - how to work with me. What my hours are, how best to communicate, e.g. slack, calendar invite, text/call, and my cell phone number. I tend to over-communicate as well. I’ve learned that people are not always tuned in, so it’s ok to repeat your message. But any communication that seems lengthy when typing out worth meeting face to face, rather than a chat or email.

As for tools, a good headset and microphone make a big difference when using online conferencing tools. I use Beats noise-canceling headphones and a Blue Yeti USB microphone with multiple modes. Some also use a pop filter or foam windscreen as well. This makes my audio clear, podcast quality. I also use a stand-up desk that converts my traditional desk to a standing workstation.

I think some of the biggest advantages are:
- Results-oriented focus on getting things done
- Establishing boundaries between work and life, sticking a schedule that fits your life
- Learning to be intentional about connecting with co-workers by initiating dialog other than task-oriented conversations
- Taking ownership of your health, getting up and walking, using a standup desk
- Being present both at work and at home, engaging community both online and where I live
- Ad-hoc quality time with loved ones
- Embracing asynchronous converstation, and prioritizing tasks
- Becoming a great manager of one, autonomy
- Being open and honest about effort and results
- Learning to empathize with others' situations and think the best about them

In summary, remote work is not about isolation. It is a lifestyle that prioritizes creating a great experience for everyone in your life. My opinion is that we are wired to connect with other people. Sometimes I see a face in the oddest things, especially in the design of cars. By working remotely you have the priviledge to design your community. Spending less time commuting means the freedom to accomplish more things that matter to you.

Highlights:

Working from the beach

Afternoon walk

EmberJS2018 – A Few Suggestions

2018-05-31T00:00:00+00:00

Community

At EmberConf 2018 I finally participated in the mentorship program. Back in the early days, I remember how the community was small and it was easy to connect with the developers involved in working on the framework itself. As time has passed, some faces have changed. However, the community has done a great job of reproducing it’s culture of shared opinions and solutions; and has retained it's values of kindness and openness. At the mentorship program event, I saw how this happens. It amazed me as I saw new members of the community show the same camaraderie – it’s contagious!

So for 2018, though Ember makes us productive and happy, it can be easy to pass up participation at local meetups or to become less active on the chat and forums. My hope is that we will continue to hand off the baton of the community values to developers who are new to Ember.

Marketing

I hope developers building with Ember can make it a point to share why they enjoy building with Ember. Instead of sharing only how and what we build. We can tell the story of why we build with shared opinions and solutions.

I find that Ember makes me productive and happy. The tools for testing have grown better and better over the years; and the Ember ecosystem proves to help me develop quality and stable software with JavaScript. These shared solutions help me to find common solutions and patterns which have already found success. For example, addons like ember-concurrency and ember-cli-typescript push me to use patterns that others understand, are documented well, and work great. This has been common place in the Ember community for years.

I can keep up with current releases or stick with an LTS version for a time if I need to.

To summarize my message, “Ember in 2018 is not the Ember I remember.” The applications I work on continue to evolve as tooling and shared solutions mature. I can avoid bespoke code yet with addons I can still experiment with new ideas and solutions. I’ve enjoyed implementing features with a unilateral and immutable data flow. I really enjoy being an early adopter of building with TypeScript in Ember applications; as well as using (experimental) decorators. Using classes, decorators, and TypeScript in the applications I develop looks very different from the applications I worked on in 2017. They do feel very modern. At the same time, these tools make it easier for developers, who are less familiar with Ember, to understand the application code.

Standards

I hope that Custom Elements are first class in Ember, and that Ember components can upgrade a custom element just adding template bindings. It will be amazing when Components as just baked on the Web Components standards.
- Custom Elements

Regaring actions, I know they work fine and are documented well. But, I find as new developers begin working on Ember applications actions are confusing. It seems that "closure actions" (using the action keyword in templates) is a goto solution. And, we often pass actions down (since they can talk back). The idea of "data down actions up" has evolved to "data down plus actions down too". I wonder how we can simplify this concept of handing events? I think that perhaps sticking closer to standards may help. I wonder, are we doing too much with actions when we should be authoring events? E.g. using built in events, plus custom events.

Bugs

I hope more developers can help triage Ember issues. Helping the core teams find a better signal to noise ratio from the Ember issue tracker on github will go a long way with seeing more bugs closed out. It takes a village. Simply looking over issues and helping developers reproduce their issue with an working example or even creating a failing test would be awesome.

Documentation

Ember leaves the model layer up to the needs of the problem domain which developers strive to provide their solution for. Ember data is a great example of how to leverage an ORM and to work with a common API standard, i.e. JSON API. And it provides solutions for custom adapters and serializers to fit just about any need. The abstraction is good. However, I have worked on various applications where the data layer did not fit the solutions Ember data provides. I would like to see more solutions as official documentation that use the Fetch API, or a simple XHR solution. Perhaps developers should be encouraged to follow the data patterns in the domain which their applications live in - versus conforming to an abstraction to an ORM solution. For example, using eventual consistency via a CQRS pattern (for persistence) is very different. What about real time data? How about examples using web sockets?

Also, I’d like to see more examples of using domain/business logic in a UI model layer with components which are simple in scope - the components just leverage data and methods of models (instead of implementing domain specific login within components). I think unit test for models run fast - as they do not need to render anything. And for component tests, domain logic can be stubbed in rendering tests for testing component behaviors.

One thing I find, is that business logic can be sprinkled all over an application - a bit in the component, a bit in the route, a bit in the controller, a bit in the model, and a bunch more in the template(s). I think that the Ember framework provides patterns for developing single page apps which are great. Perhaps, we also need some encouragement as a community to model solutions thoroughly and utilize framework objects to connect to our business logic - that is through our UI model objects vs. complex components and service combinations.

I get that Ember provides Service and Component objects which can be leaned on heavily; as well as a default solution for data models (persistence). These are great tools for building applications on.

Ember.Object

Can we just use class, I do. The ember-cli-typescript addon encourages the use of classes and extending EmberObject. I think current appliation code should utilize class syntax vs. EmberObject.exend().

A11y

Good solutions exist for accessibility (A11y) provided through addons. As a commnity I hope we can leverage these and share our success stories more.

Routing

There are lots of bugs in the issue tracker for routing. I know Ember has gone though various router implementations. But, what if the router was an addon? And, a simple alternate option existed as well? Perhaps a router that just has a function to match the request URI and a function to render. Maybe ember-simple-router?

Code splitting

I am sure everyone is like yeah is there a way to break up the large assets and load modules on demand? Is that solution the ‘engines’ solution? Well, I imagine someone is working on this and I look forward to using it one day :)

Wrap up

I am so happy be be a part of a JavaScript community which advances standards (e.g. JS modules) and tooling - while keeping me productive and happy. I like that there is room to experiment as well. And, since the framework evolves by learning from the success of other libraries and tools our applications do not grow stale; we can avoid becoming legacy developers (even though that is a sign of some success, maintaining a legacy application that is). Some things I’m interested in, but have not explored with Ember, are using tools like RxJS or other reactive patterns.

Change, everything will be fine

2017-09-04T00:00:00+00:00

Let’s be honest 2016 was a tough year for everyone. Along with that craziness, I gave my job to a friend and began a journey of consulting and eventually back to full time employment. I valued my former position and looked forward to growing my leadership skills in a software developer manager role. Well that all changed. While consulting, I looked forward to using my experience as a positive influence to benefit the clients which I had the privilege to serve. And eventually, I accepted a position for a company in Texas as a developer. Exercising leadership would look differently now. I’ve worked for companies in Los Angeles, San Francisco, San Diego, Minneapolis, North Carolina. And I’ve worked with people around the globe. The people in Texas have been kind to me. In response to Hurricane Harvey, I’ve witnessed the level of support Texans naturally give to their fellow Texans, a few co-workers on my team spent their Labor Day weekend helping hurricane victims. Cheers Texas, you know how to take care of others better than most. I think I landed well; that makes me happy. A software company in Texas does behave differently than other software companies I’ve worked for. And it’s good, I’d say “even better” (just learned about that phase this year).

Previously in 2016, I lived in a huge house, about 3,700 sq. ft., had a great home office, and had hopes to buy that house. Oops, that didn’t work out, we down sized and moved out of town. (It even took about a year to get back a $4K deposit.) I still work remotely, but now share my office space with another room. I moved to another community in Southern California, I’ve found many kind people, fresh air (yes in CA), and I can see the stars every night. (Not so much before.) Today, friends from our church helped us pull weeds and clean our back yard - on a holiday too, so kind. I miss my big house and the community around my old place, there were kind people there too. I have a big yard and am so happy to see my family work so hard together to prepare for an upcoming back yard party we’re planning. We do not have as much room inside anymore. A friend offered to lend us a tent, which really will make the yard a nice atmosphere for our party. We’ve made some new friends and have kept some old ones too.

I’ve been a Mac user for a very long time, I previously worked for the company that produced those Mac vs PC advertisements that were so funny. I also previously worked for the company that provided ecommerce solutions to the company whose operating system has achieved world domination, and was like the only developer with a mac officially provided by the company, back then PCs were standard issue to developers. I worked on the online store and try/buy solutions to buy Office for Mac. In school, I learned to type on an Apple II (my only personal computer was a Commodore 64). I’ve bought a ton of macs for myself and my family over the past 18 years. And during that time, I only purchased one PC. At one of my old jobs we only supported the Safari web browser; which of course comes on a Mac. So, at my new job I asked for a Mac. Everyone on the team had one, there was one caveat - we run services using Windows based technologies. Also in late 2016, I was issued on of those new Macbook Pro computers with the touch bar (surprise, I really did not like that computer). Then another one, what else would I use? I got to thinking, we run Parallels for the Windows based web services we use. Why not just develop on a Windows machine, I remember I used to before, but it has been almost 10 years. Then I was often the developer who insisted on using a Mac, and now I’m the guy in a large crowd of developers and their Macbook Pros why askes for a PC. So now, I use a Dell laptop at work and a Lenovo laptop at home. Windows is different now, I’ve pleasantly surprised – I’ve been away for some time. And with the Creators Update the Windows Subsystem for Linux works pretty well. I keep telling myself I’ll just run Linux only one day, well for now I step into Ubuntu from Windows 10 using the bash command. Also, I even use a touch screen on my PC. What, the whole screen is a pointing device? Heh, I kind of like that.

The team I work with builds with ASP.Net Core technologies. So, Visual Studio or VS Code is the go to IDE/Editor. My favorite text editor, up to now, was Vim. I still like Vim, but VS Code is really good. I used to laugh at TypeScript; it seemed to me that TypeScript was a misfit within JavaScript; since dynamic types do work. Now I think… types are great, can I build with TypeScript? I recently worked on a feature and chose to use immutable data (in a JavaScript application). What could be wrong with state in a thick client (JavaScript) application? I like the immutable data flow much better now. Thanks to Elm for catching my interest in using types, functional programming, and immutable data. For almost 5 years I have built applications with the Ember.js framework which itself has been through many changes. And now I’m so excited about Web Components, the v1 specification and polyfills are coming along great. Maybe soon I’ll develop mostly with Web Components. I miss some aspects of Rails, Django but look forward to learning the concepts around Domain Driven Design (DDD). The team I’m on, favors many of the concepts and solutions which stem from the DDD methodologies. We value capturing the behaviors within a software system and the ubiquitous language among stake holders/clients than we value how a technology system typically functions. I’ve come to recognize that so many CRUD based solutions were short sighted. I’m interested in RxJS, Cycle.js, and I think I will tinker with these reactive and functional approaches to software development. What has not changed is that I still write a bunch of tests, and keep advocating the importance of writing automated tests, both for developers and users alike.

For the past few years, my wife was a conservator for her grandfather, he suffered from Alzheimer’s. He recently passed. It was a privilege to care for him and know him during his final years. He would say, “you all must be my kin, you are so kind to me”. We’d have a partly and he’d have a surprise more than once during the event. He would become lost and alone, then I’d walk him around the room and re-introduce him to his family, and he was suddenly so happy to be surrounded by people who love him. We will miss him; the responsibility was significant, now that also has changed.

We keep a mini zoo at home, but for the past 18 year we have not had one cat that become our pet, ever. This summer, we adopted a kitty. He is so cute, curious, and cuddly. A few months back we lost the best dog we ever owned, she was incredible. There are five of us at home (in 2016 we launched 2) we came up with five names for the cat, I just call him “Kitty”. I know he will grow up, maybe I’ll call him “Gretsky” then; he likes to play with lids like they are hockey pucks.

In the last year what changed? The political landscape for one. The “twitterverse” seems very polarized and promotes echo chambers. I changed… jobs, roles, computers, operating systems, backend solutions (programming languages), text editor of choice, work for a Southern organization vs Costal, share office space vs personal office, frequency of travel, lost a pet, tried a kind new pet, lost a team, gained a team, downsized our home (in half), launched two children, training (Krav Maga), communities, cities, churches, schools, neighbors, friends, family, responsibilities, health, and eyesight. I am sure I forgot something that belongs on this list. That that is enough. I have not changed much, everything around me changed drastically - I still think different and am one of the crazy ones who thinks they can change the world. Two constants have been with me this past year: change and kindness. Even though I had a tough year in 2016, 2017 has been much better. Don’t get me wrong I get serious threats to my safety and security; and, I do notice the anger around the USA. But, I choose my comfort zone within the storms of life - kindness works well. In fact, kindness is battle tested with withstands change. No wonder when I look back at all the changes that I experienced this past year (and over my career)… I found kindness within the chaos.

I typically blog about software development for the web. The title of this posts may appear off-topic. But I’d like to challenge your perception, would you challenge your own perception? I do, I find it a practice that helps me transition though change. Change happens. It’s your ability to navigate change and show your resilience though it - which makes a difference in your personal and professional life. (These days, these two cross-over anyway). So regardless of the environment you live/work in, regardless of the group think echoing from your social(media) circles - think about your course of action and resolve. Will you be the thermometer who simply reads the temperature; or will you be the thermostat that influences the temperature? My story from ’16 thru ’17 is not unique, change is a dominant force and is inescapable.

In my mind, this post addresses a key principle that is important to software craftsmanship: the ability to embrace change (to extend and receive kindness through it) will help us all build solutions that are not mediocre. Attitude reflects leadership, be the leader and make room for kindness as a constant, aside ongoing change. Building good software includes dealing with people as much as it is does computers, your resolve will result in work that is mediocre or resilient. Be the change that results in delivering even better software solutions.

Working Remote, Somewhere Between Bliss & Distress

2016-09-27T00:00:00+00:00

Before I get into the details working somewhere between bliss and distress. it’s worth mentioning some motivations for working with a remote developer. Some markets are saturated and it’s difficult to find local talent. At times, teams are seeking to hire senior talent and looking for ways to make it more attractive for developers to make change. In some cases, a project is short term; and hiring a contractor or consultant is the best way to help a project take flight (we’ll build the airplane in the air). Other times, its more strategic, why invest capital in brick and mortar, in headquarters, when you can put cash into infrastructure and teams? For developers, the motivation may be to make up for lost time and stay closer to home; or, to make time for travel. There are a wide range of motivations why companies and their employees decide to work remotely.

I’ll start with a tale of… when it fails. Simply put… no one at the company is really convinced that they will benefit from the learning it takes to work with a remote team member. Or a remote developer has no real interest in being a team player. It’s more of a compromise… “This is a talented person, how could we pass him/her up?” Or, “We can figure out how to work with a remote employee. How hard can it be?” Alternatively, “We already work with contractors in this or that location, and that works fine.” It starts like so… “We’d like to extend you an offer that I think you can’t refuse, we are happy to work with you remotely and although we don’t have any employees who work 100% remote we’ve had success working with contractors. We can build on that.” Here is the error, an employee is not a contractor, there isn’t a fixed date as a finish line, nor is there motivation from the business to gain an expected outcome like there is with a consultancy. If the business thinks it’s ok to treat the remote employee like an offshore developer, it just won’t last. Not only will it fail fast, the work may not even matter. I worked at one company and for the first 3 months another developer basically threw away all the code I contributed toward browser compatibility (for their beta product). What a waste of effort and resources. In this scenario the business does not posses conviction about the value they gain from learning how to work with a distributed team, it’s more of an experiment. There’s no real skin in the game. When you recognize this, it’s time to make a change, do it gracefully and swiftly. For this (solo) remote developer on a team, the experience is dominantly characterized by distress. In this scenario, there is nothing healthy for either the business nor the “second class” employee, known as the remote developer on a team of in-house developers.

Please note that there is a huge difference between “working from home” as a privilege and “working remote” as a lifestyle. Because a team has a flexible schedule that does not mean it can maintain success with a distributed team. If one team member is distributed everyone needs to know how to collaborate or the work suffers. In-house team members blame the remote developer and don’t include the remote team member in discussions about the project, or design of the product, etc. Having a remote employee means finding a way to make that employee a “first class” employee vs. a “second class” one. The result of treating remote employees as first class is that the organization benefits from the investment in learning how to work with one or more remote team members.

There is another scenario when… it half works. Some in the company like the benefit of having remote workers; however, they see remote work as a privilege. Based on this perception they reserve some aspects of working together for only during in-person exchanges. This is closer to working with a flexible schedule than to removing remotely as a lifestyle. The business has made a compromise; for what ever reason, maybe desperation. It is normal to plan for remote workers to have some face time with the team. But in this case, the business sees work from home as a privilege and incapacitates potential learning and advantages gained by working with a distributed team. Many conversations are saved for in-person exchanges instead of embracing successful practices of distributed teams, e.g. asynchronous communications. The in-house staff find ways to insist on synchronous communications. Since that can rarely happen, communications are extremely limited. The result is mismatched expectations and failure to work effectively toward common goals. Working remotely requires solid communication on both ends; and partial effort, does not lead to success, you get out what you put in. Sooner or later in this scenario, the remote employee gets burned, or becomes the scapegoat.

A third, and somewhat more honest approach is …trying to learn how to add remote workers to a local team. This happens when… some at the company realize there are benefits from learning how to change their current work patterns by the addition of remote workers. It is ok to not to have it all figured out – both onsite and offsite parties understand that the rewards are deferred – until there is a change that takes place, which makes it possible to reap the benefits from a new way of working together. This is still somewhat experimental; but for all parties, it affords growth and discovery of new patterns for success. The circumstances around when to begin this experiment may not matter as much as having skin in the game. Both employee and employer gain from this investment of time and labor toward expanding a team beyond their current geographic limitations. By hiring a remote employee who has experience in both succeeding and failing when growing a distributed team, the company can side-step some pitfalls of figuring this out for the first time. The in-house team and collaborators will need to learn new habits; and find ways to include others that are remote. Open communications and making time for in-person team events, e.g. a week in the office each quarter, a few lunch events or off-site activities can help provide course correction along the way. As long as everyone stays engaged in this effort, eventually the remote employee is just a normal employee who only comes in on occasion for social or strategic meetings.

The final scenario is… when it just works. This can be blissful for remote workers and company in-house staff as well. Many at the company have confidence in the reaping the benefits from working with remote workers. Stakeholders, in-house, and remote team members (whether located primarily on- or off-site) all have found a way to operate and communicate effectively and successfully. Location is not a factor which limits communication and collaboration. Teamwork is typically successful when someone in upper management / or in a position of leadership and influence fully embraces the practices that support working with a distributed team. When planing meetings, there is always an online meeting option, and call-in phone number as a back up plan. Teams use online tools to collaborate. One quote is, “if it didn’t happen online, it didn’t happen”. Artifacts necessary to communicate scope of work or specifications for features (or systems) are readily sharable using online tools. Communications are most often asynchronous, The chat rooms are used by both on- and off-site team members. Everyone is included in conversions and when not possible, those who were out of the loop are filled in with the necessary details to be successful within their team. This does not happen by accident, but instead by intention.

The choice between working with remote vs. in-house developers is not a business decision that makes or breaks a company. Though it does seem to be a question many ask, should we consider hiring remote developers? I would say that is not the right question at all. Business decisions that impact how well people succeed at working together or how quickly they fail at working together are comprised of a wider set of choices regarding how the business interfaces with it’s workforce. What do we gain from learning how to communicate and ship features for our product while working as a distributed team? That, is a much better question to ask.

Once a team embraces a distributed workforce, fully or partially remote with some or none on-site, there are valuable lessons to learn. Communication is important, it takes as least two. Foster communication and open collaboration; succeed and fail openly. Asynchronous communication is the way to encourage collaboration. Interruption is not. There is a time and place for synchronous communications; but that should be limited to when it’s altogether necessary and agreed upon by all parties. A good VOIP phone; or a plain old cell phone with a good service plan works fine. Slack has a decent call feature. Not every meeting needs to include video (or face-to-face) interactions. Just make sure you keep communication open and timely. Choose your tools for process and collaboration wisely; the tools should not be the subject of your pain points. For online meetings have a backup plan, perhaps the primary tool will be an online meeting and the backup may be a conference (call-in) phone number. Decide this in advance of the meeting start time. Chat apps work great; and help teams connect and collaborate. Reach out for help; pair program with team members. When working remotely, avoid isolation. Explore the surrounding areas, or travel. Rent a shared work space as needed. Keep yourself motivated. When working from home, be careful to plan your work hours and plan your life away from work too. Choose and communicate working hours. Draw a boundary for yourself between life and work. Be an effective communicator and set reasonable expectations. Avoid distractions, find a time management system that works for you, perhaps use the Pomodoro Technique®. Focus and flow facilitate great work, protect that. Show up and dress for work, wherever that is. Choosing where to work affords who has the privilege of inturruption. Working at home can mean that loved ones are close by; don’t shut them out, agree on a time to connect. And give them some hugs too.

One final suggestion is… know your limits. Sometimes an experiment fails, find a way to make lemonade from the pile of lemons you were sold. If working as a remote employee isn’t working, try contracting. If working as a fully distributed team is going bonkers, rent an office space and move toward flexible hours. Learn not only from your own mistakes but also from the mistakes of others. Perhaps hire contractors instead of employees when you decide to expand your team beyond the walls of your office. A consultant, worth her/his rate, will make the team they work with shine; by transferring her/his knowledge and experience as each opportunity presents itself. If you fail – don’t give up, try something new.

Managing Developer Happiness

2016-09-08T00:00:00+00:00

To manage developers you need to find them first. What attracts quality people and talent worth giving your best for?

That is a loaded question, it depends on the individual. Typically I hear “I want to work with smart people.” I do to. The reality is, as managers we need to surround ourselves with people we can sharpen and who sharpen us. Be honest about your team’s skill and what a values you expect a candidate to bring to your team. Developer’s values vary: flexible schedules, autonomy, working on ambitious products, modern technology, low technical debt, etc. Just ask, it’s ok to have a variety of personalities who team up to build great software, it’s about respecting one another’s values.

Now that you have a team, how do you keep them engaged, motivated and interested in working with your organization?

What keeps their interest? Is it the technology stack? Or, work-life balance? How about owning a piece of the business? Contributing to open source projects? Twenty percent time? Training opportunities? It varies, do your best to meet individual needs and provide a path for growth that fits the expectations of your team. Don’t shut down dreams by refusing to make goals a reality. Go to bat for your team, get them what they need - so that they can focus on work that matters.

As a manager, are you meeting the expectations of your development team?

What do they expect from you? Trust. No micro-managing. A good manager lets the rubbish roll up instead of flow down. Move obstacles and barriers that prevent your team from focusing on their best effort. Flexibility. Support for work-life balance that - Just Works™. Create time to focus on objectives, avoid meetings and keep communication channels open. Provide an opportunity to learn, enjoy life, refresh and recharge, to go to conferences and support local software user groups. Communications should have a frequency that works for the individual. Don’t over-do or under-do what matters to your team. I call this servant leadership. My objective as a manager is to provide the necessary support, whatever it may be, so that my team can shine and take pride in the product of their investment of time, thought, labor and sweat – ultimately shipping valuable software products for users to enjoy.

Do you know what developers expect from work, from the business?

How about a challenge to tackle? A finish line to cross. People to collaborate with, an excellent project manager or business owner. A roadmap that inspires great work. And of course, time away from work! “All work and no play makes Jack a dull boy” –Jack, The Shining. Maybe, work from home. For some, work at work; away from home. For others, a flexible schedule that affords putting family first. Many developers would really like to work for a remote friendly organization. Work is for work and quitting time is for play. It’s fine to mix it up a bit; but remember the company is not your family (aside from a family business that is).

So you’re a manager of developer happiness, what should you do?

Act as a servant, a leader, help your team do their best work. Lend a hand when you are asked, get out of the way when you recognize you're not helping anything. Ask good questions about code, be involved in peer reviews. Set standards and practices that reflect the values of your team and organization’s needs. Put people first, before policies/protocols. Filter out the bull, run the interference your team needs so they can focus on development. Remind your team to go home; the work will be there tomorrow. Question your assumptions and the assumptions of others – in a positive way. Ask about what is best for the team, the company, and the individual. At times all three are not in harmony, find a workable compromise. Take responsibility. If necessary deploy, do the QA work, write CLI tools, write documentation, release notes or create diagrams for systems information. Be a coach, show stakeholders how to work with a development team, how to motivate them. Communicate the value your team brings to the business. Have an opinion, and welcome the opinions of others. Be who you are and respect others for being who they are. When push comes to shove, fight on behalf of your team. Show up and flip tables when it’s the right thing to do – when the benefit outweighs the cost, for everyone. You are the leader, act like it. Have a life outside work, but make work fun too. And, have a sense of humor, you will need it. Expect great days and horrible days – both will pass, keep a steady and positive attitude about a plan forward, regardless.

What about process?

How will your team succeed at getting things done? Do only what works! Experiment and learn along the way. Tools and process should not get in the way, choose wisely. Provide guidelines on how and what your team should prefer, based on team values. For example, a code standards document or style guide helps establish a bar you can raise when needed. Layer work that is dependent, for example only two of these three will likely succeed when in flight concurrently: 1) UI/UX design 2) API contracts 3) Feature development. Working on two of these at a time works to move toward a solution but all three in flight together invites chaos and likely failure to meet goals. Favor process that has proven to be successful elsewhere. Don’t re-invent process for the sake of bespoke ideas. To codify how your team will focus on what is important… adopt successful process that can blend with the footprint of your organization. Pick naming conventions that can work; conventions do not have to be perfect. Perhaps use “git flow” or simply borrow the parts that work for your group. Use Scrum / Agile practices that people recognize, so that you do not have to explain “how“ your team get things done. In order for your team to deliver results that matter, surface actionable work - which brings value when you ship it. And, avoid working on features that are not well defined. Define done.

What about the size of your team?

Prefer a small team, or many small teams if you work in a large organization. This affords leading by example, so you can still write quality code as a manager. It also limits collisions of code and incongruent methodologies from hijacking the work. Align strengths, front-end, API, style wizardry, software design and automated testing chops too. TDD that stuff together or plan a perfect system - various strengths can sharpen the team. Let people do what they do best.

There are some things a manager should avoid.

Only do what you can succeed at, based on your resources. Don’t become the project manager or product owner, focus on developing successful and shippable solutions. “Real artists ship” -Jobs. Don’t get mixed up in company politics, delivering results carries weight and should be the leverage you need when you need to play your cards. Don’t work on the stories that challenge your team, let them enjoy a challenge and come up with a win. Don’t go dark, embrace interruption, help move obstacles for your team. Avoid saying “yes” to anything that is not already groomed, actionable and committed to work on. No means no. An untimely yes means no to what you already said yes to. It takes a lot of “no” to get the best “yes”. Avoid being selfish, we all can be. The team has to succeed, period. Don’t be a jerk, people have feelings, empathy goes a long way. Don’t cave in to pressure for late hours and work through the weekend. You set the example, work smart, not hard and long. Which only results in starting more fires and a fosters a culture that rewards and recognizes people for putting out fires - instead of a culture which avoids starting fires and which focuses on adding value to your product or business. Long/extra hours are a distraction that drips poison into quality software.

You’re a manger of developer happiness, how does a manager sharpen oneself?

Surround yourself with other leaders, at your company or in the software community, both if you’re so fortunate. Take time to have conversations with other leaders. Talk about what makes you tick and listen to the experience of other leaders. Seek mentorship in all areas of you’re life, they seem to blend a bit anyway. Becoming a better leader at home leaks into being a better leader at work and vice-versa. Be helpful where you can, others will recognize that and return the favor, “pay it forward”. Treat others as you would like to be treated, it takes practice. Reflect the best character traits that you’ve seen modeled by mentors or your former managers. Volunteer to get involved with a local software user group, or online development community. Solve other people’s bugs, give back where you can.

Don’t miss this… what must a manger get right?

Say “Thank you.” It matters, people deserve a kind word, especially when they give their best. Recognize valuable contributions. And, have a plan forward, when the tech debt is high, roadmap is steep, the backlog is thick, or you have no clue what’s next. It takes a plan to maintain forward momentum. Maintain and display a positive attitude, “Attitude reflects leadership” (Remember the Titans). Listen. When in doubt, listen some more. Celebrate finishing well. Learn from the past, success and failure both provide valuable lessons. Succeed and fail transparently. Balance work and life commitments for everyone on your team, including yourself. Help others give their best effort, “Yes you can” motivates others, tell yourself that too. Challenge others to grow, provide specific and reachable goals. Do the hard things, you’ll recognize them when they come - and they will come. Don’t be a coward. Set the temperature for your team, like a thermostat, not a thermometer only reading a value. Respond to change instead of reacting to it. Be a leader both at work and outside the workplace, it takes effort. Elevate others, provide a blueprint for growth and provide the experience that is valuable anywhere, and also provide a reason for your teammates to stick around.

There are many stories I could tell of how good managers have taken time to coach me, they have invested their experience and knowledge in me; and helped me to become better at my craft. They stepped in when I was down and propped me up toward success - by believing in me and challenging me. Mentors and business coaches have challenged me personally to be my best. I still tell myself, “you can do better,” because the race is not over yet. Also, I’ve worked with some managers who were so obnoxious I could just puke. I learned to move forward when I must. If all fails, be a manager of one, and start over again. Ahead, there are battles to win, competitors to face, and most importantly a team at your side - to make work and life more interesting. Do what you can for the people who look to you for leadership and remain teachable, surround yourself and your team with the best people you can mobilize, and build great software. Users everywhere are depending on it, they need it - we all do.

Developing Ember Addons: Next Generation CSS with PostCSS

2016-02-24T00:00:00+00:00

My Goals:

A) In an (Ember CLI) addon - add PostCSS processing to my (Ember CLI) application's build (and utilize a few selected PostCSS plugins for conversion of upcoming CSS syntax for today's browsers). I am digging PostCSS! I'm very satisfied using next generation CSS syntax in my applications today.

B) To move common styles out of various applications and into one single Ember CLI addon. (I still want to continue using PostCSS).

I ran into a snag, the Ember CLI addon to process I used did not Just Work™ as I hoped.

I have used Broccoli as a build pipeline for a JavaScript library, So I thought - "How hard could it be?"

I found that it is not trivial. Fortunately, there are other developers who have already crossed this bridge. I found help in the embercommunity.slack.com chatrooms (#ember-cli and #need-help), sign up here.

The question of "Where in the addon do I put my styles?" did confused me. I tried using addon/styles/addon.css then tried app/styles/addon.css vs. app/styles/app.css. What surpised my was that when I put styles into addon/my-file.css and processed it with broccoli-postcss (an npm module) the styles were built into the dist/vendor.css file. At first, this didn't make sense to me. My assumption was that files in the addon's app directory would be merged with the files in the consuming application's app directory. However, that was not the case.

Someone in the chat channel, posted a link to an issue for an ember-cli thread that went back a year or so; which included discussion about how styles behave in addons as well as what magic surrounded processing CSS in an Ember CLI addon. So, my first thought was - "avoid the magic"; like I avoid the plague. So, I continued to setup a customized build solution in a new addon (for common styles); and to simply use CSS files within a styles directory in the addon root directory. That worked for me. Well it did seem that I should begin to look for a pattern in existing Ember addons that include CSS styles as the primary solution, like a UI kit.

Apparently, it's a thing to place CSS files in an addon inside the app directory. And by doing so, the CSS files are built into the dist/vendor.css file. Ok, that's how the magic works, nice :) - it follows that the consuming applications can import the addon's vendor styles into the application's own vendor directory.

Perhaps I have a handle on unravelling this "mystery" of where styles go, how styles are built, and how a consuming application imports the addon's stylesheets. (This was not obvious at first.)

I thought "oh, I should build an addon for processing PostCSS, for addon development". Well, the solution was less than 100 lines of code. Maybe it's better to just use this solution as boilerplate code instead of creating yet another addon. (emberaddons.com already has over 2,000 NPM modules.)

I read an article, titled Kill Your Dependencies, which emphasized owning code that you can, exercising caution when selecting a dependency, and advocated responsibility for library developers. At this point, I discouraged myself from writing Yet Another Library™ for processing PostCSS. It's responsible, for now, to simply share my solution and to explain how Ember developers can customize a Broccoli build pipeline, within an Ember CLI addon, as a solution for processing CSS, perhaps with PostCSS.

My Use Cases (Wish List)

I want to use an Ember CLI Addon as a library for common styles for various applictions that can share a common set of styles. This addon will become the shared styles for a group of application engines within the platform I work on.
I don't want to publish this addon on NPM, I want to use a URL to the git repository.
It would be great if I could distribute the CSS file and have a common URL to load the styles from, so that the browser caches common URL.
As the applications grow, I want to remove common styles from various applications into this library of common styles.
I like versioned dependencies, even for a CSS library.
I want to use modern CSS today, PostCSS provides that. Perhaps one day, the modern CSS I write today will become standard; then I can remove the custom processing.
I'd like to just install the addon for my stylesheets, and the CSS should Just Work™. I'm ok with owning that.

If you're curious about how this solution turned out for me…

Once I understood how Ember CLI addons proccess CSS in the build pipeline it was fairly simple to add custom processing with Broccoli.

TLDR; see the repositories below:

The xyz-styles addon is utilized by the xyz-foundation app.

PostCSS processing in an Ember CLI Addon

Below is an explaination the solution I found, starting from the end of the story (the part where it just works).

First an application needs to install the addon (for common styles).

ember install git+ssh://[email protected]:pixelhandler/xyz-styles.git

This command results in adding dependencies to my package.json. I moved the 'styles addon' to dependencies (from devDependencies):

https://gitlab.com/pixelhandler/xyz-foundation/blob/master/package.json#L50

The output was…

version: 2.3.0
Installed packages for tooling via npm.
installing xyz-styles
install packages autoprefixer, broccoli-funnel, broccoli-merge-trees, broccoli-postcss, postcss-cssnext, postcss-import
Installing packages for tooling via npm..caniuse-api: Generation ok
Installed packages for tooling via npm.
Installed addon package.

In order for this command to work, the addon needed a blueprint…

/* jshint node: true */
/* global module */
module.exports = {
  description: 'xyz-styles',

  normalizeEntityName: function () {},

  afterInstall: function () {
    return this.addPackagesToProject([
      { name: 'autoprefixer', target: '^6.3.3' },
      { name: 'broccoli-funnel', target: '^1.0.1' },
      { name: 'broccoli-merge-trees',target: '^1.1.1' },
      { name: 'broccoli-postcss', target: '^2.1.1' },
      { name: 'postcss-cssnext', target: '^2.4.0' },
      { name: 'postcss-import', target: '^8.0.2' }
    ]);
  }
};

My afterInstall hook in the index.js file adds required dependencies for processing CSS files using PostCSS and a couple plugins for cssnext and import.

Learn more about Ember CLI's Addon Hooks.

With these NPM modules in place, this "xyz-styles" addon can utilize them to process the CSS which utilize next generation CSS syntax.

An Ember CLI addon uses it's index.js file to provide hooks for the consuming application. The consuming application can process the modern CSS syntax provided within the addon's code though the included hook. This hook in the addon is used by the consuming applicaiton as the entry point to build the stylesheets into the application's vendor.css file. The vendor CSS will be imported into the consuming Ember application's vendor styles.

Below is the xyz-styles/index.js file:

/* jshint node: true */
/* global require, module */
'use strict';

module.exports = {
  name: 'xyz-styles',

  getCssFileName: function () {
    return this.name + '.css';
  },

  isAddon: function () {
    var keywords = this.project.pkg.keywords;
    return (keywords && keywords.indexOf('ember-addon') !== -1);
  },

  included: function (app) {
    this._super.included(app);
    if (!this.isAddon()) {
      app.import('vendor/' + this.getCssFileName());
    }
  },

  treeForVendor: function (node) {
    if (this.isAddon()) { return node; }

    var path = require('path');
    var Funnel = require('broccoli-funnel');
    var mergeTrees = require('broccoli-merge-trees');
    var compileCSS = require('broccoli-postcss');

    var styles = path.join(this.project.nodeModulesPath, this.name, 'app', 'styles');
    var inputTrees = new Funnel(styles, { include: [/.css$/] });
    var inputFile = this.getCssFileName();
    var outputFile = inputFile;
    var plugins = this.getPlugins();
    var sourceMaps = { inline: true };
    var css = compileCSS([inputTrees], inputFile, outputFile, plugins, sourceMaps);
    node = (node) ? mergeTrees([ node, css ]) : css;

    return node;
  },

  getPlugins() {
    var autoprefixer = require('autoprefixer');
    var cssnext = require('postcss-cssnext');
    var cssimport = require('postcss-import');

    return [
      { module: autoprefixer, options: { browsers: ['last 2 version'] } },
      { module: cssimport },
      { module: cssnext, options: { sourcemap: true } }
    ];
  }
};

The treeForVendor hook above utilizes the PostCSS modules and a few Broccoli.js modules - to build the CSS with the build pipeline of the consuming application. I used a getPlugins method to setup the options for the broccoli-postcss module to compile the CSS with.

The proccesing by the included hook will only occur in the case where there is a consuming app including the addon. There are two points of interest… when the consuming application includes the addon…

using the treeForVendor hook, the addon's app/xyz-styles.css file is processed and written to vendor/xyz-styles.css, and
the processed styles are imported using app.import within the include hook of the addon. That's it.

What if I want to build the styles without a consuing app?

In the example repositories, linked above (see TLDR;) - the xyz-foundation application consumes the xyz-styles addon. What if I want to share the processed styles with a older application, that is not using Ember CLI yet? The ember-cli-build.js file is the build recipe for the addon, including its "dummy" (or test) application. This build recipe is not used by a consuming application. So I could use it during development to build a distribution CSS file from this styles (library) addon. Potentially, Ember CLI's build could be used to build generic CSS libraries too, nice :)

Notice that the ember-cli-build.js file is very similar to the index.js file…

/*jshint node:true*/
/* global require, module */
var EmberAddon = require('ember-cli/lib/broccoli/ember-addon');
var autoprefixer = require('autoprefixer');
var cssnext = require('postcss-cssnext');
var cssimport = require('postcss-import');
var Funnel = require('broccoli-funnel');
var compileCSS = require('broccoli-postcss');
var path = require('path');

module.exports = function(defaults) {
  var options = {
    plugins: [
      { module: autoprefixer, options: { browsers: ['last 2 version'] } },
      { module: cssimport },
      { module: cssnext, options: { sourcemap: true } }
    ]
  };

  var app = new EmberAddon(defaults, { postcssOptions: options });

  var file = 'xyz-styles.css';
  var styles = path.join('./', 'app', 'styles');
  styles = new Funnel(styles, { include: [/.css$/] });
  var css = compileCSS([styles], file, 'vendor/' + file, options.plugins, { inline: false });

  return app.toTree([css]);
};

The build recipe above uses the same strategy as the build setup in the addon's index.js file. It utilizes a file xyz-styles.css as the target for input, and outputs the same filename inside the dist/vendor directory.

Next Generation CSS syntax using PostCSS

The xyz-styles addon's app/styles directory is setup with a file named xyz-styles.css as the main file to process. The build recipe utilizes a plugin, postcss-import to concatinate the files that are imported. The postcss-cssnext plugin allows the use of modern or next generation CSS syntax, like color: var(--name);.

See these example files:

app/styles/xyz-styles.css uses the import plugin
app/styles/colors.css uses the cssnext plugin for variable definition
app/styles/elements.css and app/styles/classes.css assign a CSS variable

The consuming application (xyx-foundation) uses a similar file structure as the css addon (xyz-styles). This demonstrates how an Ember CLI application handles the load order for app/styles in both the application and and addon codebases. By default, the styles defined in the app/styles directory of the application, are built into the application's CSS file, xyz-foundation.css. This file is loaded after the CSS imported from the addon(s) - which are built into the vendor.css file. This default order of loading styles in the applicaiton's index.html file ensures that the vendor CSS styles are the base and the applicaiton's CSS styles can redefine or extend those vendor style declarations from withing the applicaiton's own CSS app.css file(s).

In this example, the xyz-foundation app defines a body style with the color as blue. And the addon, xyz-styles, also defines the body style but with color as red. The foundaiton app defines a CSS class named blue and the styles addon defines a CSS class named red. In the foundation application's template, app/templates/application.hbs, these classes can be used.

<h2 id="title">Welcome to <span class="red">Ember</span></h2>

The red class above is introduced to the application's vendor CSS by the styles addon. The title text is blue since the vendor CSS set the text color to red, but the application's CSS defines the body text as blue.

Ember.js: Handling Failure Using Route `error` Substates

2016-01-19T00:00:00+00:00

Practical Example…

At the top level, where all error events bubble to, is the ApplicationRoute.
An application_error substate can be added using a combination of both an
application-error route and application-error template. If you only display
the error.message and have no need to use a condition to set a title on the
template, then you could use the template alone (without an error route substate).

The application error template below handles any error thrown by a route that is
not handled by a child route's error substate.

The app/router.js file will not need any error routes added, they are built-in.

Since the model is passed to the setupController(controller, error) hook,
the error.message property can be rendered to notify the user of the error.

app/templates/application-error.hbs

<h1>Oops, the app is borked…</h1>
<p>{{model.message}}</p>

Alternatively, when a substate is not used to display an error notification,
your application template can display any messages that you set on the
application controller; e.g. errorMessage and errorDetails.

app/templates/application.hbs

{{#if errorMessage}}
  <button class="error-message" {{action 'dismissErrorMessage'}}>
    {{errorMessage}} {{errorDetails}}
  </button>
{{/if}}

{{outlet}}

If you want to vary the error notification text of the error substate template,
use the setupController hook to set a title property for the template.

In a route (below the application), e.g. the PostRoute, an error substate can
be used to branch the display of the title to differentiate between a client
and server error like so:

app/templates/post-error.hbs

<h1>{{title}}</h1>
<p>{{model.message}}</p>

The title attribute of the controller is used in the above template. It is
customized depending on the error code.

app/routes/post-error.js

import Ember from 'ember';

export default Ember.Route.extend({
  setupController(controller, error) {
    let title = 'Oops, this post is borked…';
    let code = error.code || error.get('code');
    if (code) {
      if (code >= 500) {
        title = 'Oops, there was a server error…';
      } else if (code === 404) {
        title = "Opps, can't find this one…";
      }
      controller.set('title', title);
    }
    this._super(controller, error);
  }
});

Since the application template may be used for errors that you do not need to
transition to an error substate, the user will need a way to dismiss. An
action dismissErrorMessage can be used to clear application error properties.

app/routes/application.js

import Ember from 'ember';

export default Ember.Route.extend({
  errorMessage: null,
  errorDetails: null,

  actions: {
    dismissErrorMessage() {
      this.controllerFor('application').setProperties({
        'errorMessage': null,
        'errorDetails': null
      });
    }
  }
});

The application_error substate will be used to display any 500 errors, or
a 404 error. However, in the case of a specific client error like 400 or 422
that your application should handle without making a transition, conditions will
need to be added to branch the behavior between using error substates and the
application error template.

If you use any nested routes, for example admin/edit and admin/create,
you can define specific error substates at that level in the route structure,
(below the application's default error handing).

app/templates/admin/edit-error.hbs

<h1>{{title}}</h1>
<p>{{model.message}}</p>

Notice the template above is the same as the 'post-error.hbs' template. The post
error template handles the display of non-admin errors; the "/admin/" directory
is used for editing and creating resources.

The route hierarchy used in this example is below. When using the error substates
you do not need to add any routes to the router.js file. Error substates are
built into the Ember.js Router.

app/router.js

import Ember from 'ember';
import config from './config/environment';

const Router = Ember.Router.extend({
  location: config.locationType
});

Router.map(function() {
  this.route('index', { path: '/' });
  this.route('post', { path: '/:post_id' }, function () {
    this.route('detail', { path: '/' });
    this.route('comments');
  });
  this.route('admin', function () {
    this.route('index');
    this.route('create');
    this.route('edit', { path: ':edit_id' });
  });
});

export default Router;

To assit with testing the error substates - I set the PostController of the
backend (API) to respond with an error. This is the repo for the API application:
blog-api using a branch 'ember-jsonapi-resources-testing'. See the commented
code I used to send error responses.

I used the setupController hook to set a relevant title for the notification
and used a console warning for a condition that should not be handled by a
transition. In an effort to build a solution for the desired user experience,
it can be helpful to log the error conditions.

app/routes/admin/edit-error.js

import Ember from 'ember';

export default Ember.Route.extend({
  setupController(controller, error) {
    let title = 'Oops, this post is borked…';
    let code = error.code || error.get('code');
    if (code) {
      if (code >= 500) {
        title = 'Oops, there was a server error…';
      } else if (code === 404) {
        title = "Opps, can't find this one…";
      } else if (code === 422) {
        Ember.Logger.warn('Not expecting to handle 422 in an error substate');
      }
      controller.set('title', title);
    }
    this._super(controller, error);
  }
});

The post form component sends an update action to persist changes via the Post
resource endpoint.

app/templates/admin/edit.hbs

<p><strong>Edit a Blog Post</strong></p>
{{form-post post=model isNew=model.isNew on-edit=(action "update")}}

The action is triggered after the user exists the field, this prevents a flood
of updates from every keystroke - caused from binding a model property to an input.

app/components/form-post.js

import Ember from 'ember';
import BufferedProxy from 'ember-buffered-proxy/proxy';

export default Ember.Component.extend({
  tagName: 'form',

  resource: Ember.computed('post', function() {
    return BufferedProxy.create({ content: this.get('post') });
  }).readOnly(),

  isNew: null,
  isEditing: true,

  focusOut() {
    if (!this.get('isNew')) {
      this.get('resource').applyChanges();
      this.set('isEditing', false);
      let action = this.get('on-edit');
      if (typeof action === 'function') {
        action(this.get('post'), function callback() {
          this.set('isEditing', true);
        }.bind(this));
      }
    }
  }
  /* … */
});

The admin.edit route responds to the actions send by the form component. After
the API request is made successfully, the callback function, sent with the action,
is called. Or, an error may be caught by the failed promise.

In the case of an error, the changes to the model are rolled back and the error
response is handled by the route. It depends on the error code whether or not
a transition will be made to an error substate. When an error is not thrown by
a route's model hook, then a transition needs to be made explicitly via catch.

In the example below, it may be a bad user experience to transition away from the
admin form the user is editing - due to a client error (such as "Bad Request" 400,
or an "Unprocessable Entity" 422). Instead, error properties are set on the
application controller which results in a dismissible error notification.

app/routes/admin/edit.js

import Ember from 'ember';
import ApplicationErrorsMixin from 'jr-test/mixins/application-errors';

export default Ember.Route.extend(ApplicationErrorsMixin, {
  model(params) {
    return this.store.find('posts', params.edit_id);
  },

  setupController(controller, model) {
    this._super(controller, model);
    controller.set('isEditing', true);
  },

  actions: {
    update(model, callback) {
      return this.store.updateResource('posts', model)
      .finally(function() {
        if (typeof callback === 'function') {
          callback();
        }
      })
      .catch(function(error) {
        model.rollback();
        this.send('error', error);
      }.bind(this));
    },

    error(error) {
      if (error.code === 422 || error.code === 400) {
        this.handleApplicationError(error);
      } else {
        this.intermediateTransitionTo('admin.edit_error', error);
      }
    }
  }
});

So that both the admin/edit and admin/create routes can use the same behavior,
the method handleApplicationError is defined in a mixin.

This mixin is used to parse the error responses and format error details.

app/mixins/application-errors.js

import Ember from 'ember';

export default Ember.Mixin.create({

  handleApplicationError(error) {
    let details = this.handleUnprocessableEntities(error);
    details = details || this.handleBadRequest(error);
    this.controllerFor('application').setProperties({
      'errorMessage': error.message,
      'errorDetails': details || undefined
    });
  },

  handleBadRequest(error) {
    if (error.code !== 400 || !error.errors.length) { return; }
    // See https://github.com/cerebris/jsonapi-resources#error-codes
    let errors = error.errors.filterBy('code', 105);
    errors = errors.mapBy('detail');
    return (!errors) ? '' : errors.join(' ');
  },

  handleUnprocessableEntities(error) {
    if (error.code !== 422 || !error.errors.length) { return; }
    // See https://github.com/cerebris/jsonapi-resources#error-codes
    let errors = error.errors.filterBy('code', 100);
    let fields = errors.map(function(error) {
      let paths = error.source.pointer.split('/');
      let attr = paths[paths.length - 1].split('_');
      attr = attr.map(function(str) {
        return Ember.String.capitalize(str);
      });
      return attr.join(' ');
    });
    return (!fields) ? '' : 'Invalid fields: ' + fields.join(', ') + '.';
  }
});

For the admin/create route no error substate template was needed. For handling
500 errors the parent application error substate will be used. And, for
handling 400 or 422 responses it makes sense to display the errors "in-context",
without making a transition to a substate. The only reason the admin.edit_error
substate uses the admin/edit/error.hbs template is to handle a 404 and a 500
response. That is not the case with the admin.create route; the parent substate,
application_error will work just fine.

Notice the naming convention used with ember-cli, the substates use a . period
and _ for the substate name and the templates use / and -. So, to transition
to the application error substate use application_error like so:
this.intermediateTransitionTo('application_error', err), or to a nested substate:
this.intermediateTransitionTo('admin.edit_error', err).

Take-Aways…

The ApplicationRoute error action handler can be used to catch and handle
various errors and delegate the notification of the errors to the
ApplicationController and accompanying HTMLBars application template. Or, an
applicaton_error substate with an applicaton-error template may handle
route error events.

Also, you may combine both error substates and error action handling strategies
in a creative way my sending the error event when the error occurs as the result
of another action; instead of by a model hook method, e.g. model, beforeModel,
afterModel, etc.

I favor the using error substates as the primary strategy for fault tolerance
in an ember application. I also like the fact that the error action may be
utilized creatively as a secondary strategy.

In the Ember JSONAPI Resources addon a ErrorMixin defines error types for:

ServerError - handles 50x
ClientError - handles 40x
FetchError (default failure) - handles 30x

The error objects thrown by a resource's service includes the error code.
You can use the code to determine how to present the error notification, use
the error type, or use the error.name property. The error.code the most specific.

Based on the error.code the route error action can transition to a custom route
to handle that specific error type. In the first example, a transition is made to
a /not-found route, that could have used an intermediateTransitionTo to keep
the URL unchanged.

However, there is a catch when using a route's error action, by doing so the route
error substates are not used. The second solution does not use use the
route error action. Instead, it uses route error substates with error templates.

Using the error substates allows the use of the route-name_error state and
associated route-name-error template. The setupController hook of the *_error
route receives objects: controller and error (as it's model). Using the route
error substate to define properties for the error template is a good way to
customize the display of the error notifications, depending on the error code.

When the error is not thrown by one of the route model hooks, perhaps by a custom
action, you can decide how to handle the error. If the error is recoverable
perhaps set properties on the application controller for display by the application
template. Or, if the error is not recoverable perhaps fire the error event on
the route, e.g. this.send('error', resp);

(One caveat - the current state of using an acceptance test for an error substate
is that the test may fail. Any error may cause your test adapter to fail the test.
See 12791.)

The ember-jsonapi-resources addon uses custom error objects to make fault tolerance
first class in your ember application.

My Battle with Data Persistence in Ember Apps

2015-06-20T00:00:00+00:00

Project Wars

I worked at an agency on a complex single page application in JavaScript that was a product finder. We built the API so that is was discoverable, parameters came in and choices came out in JSON with URLs for the next available choices or actions. After a few steps, maybe seven or so, the user would have a narrow set of products that met the search criteria and geographic availability. The application loaded JSON files to configure the steps it took to walk the user through the various product finders. The functional spec was in the range of 350 pages, and the project was a MICROSITE. The end result was an order page. There shoppers could begin the purchase process and customize the products' size, to fit the shoppers custom measurements. How did we do this? We used Backbone.js and built all of our application logic on top of it. Just prior to this project I had developed a front-end framework on top of Backbone that did have many similarities to Ember.js. It supported building modular packages with AMD using Require.js. Those were the days of the Wild West, when we rolled our own JavaScript front-end frameworks. Hallelujah, those days are gone. I say, "Good riddance."

JavaScript frameworks provide a way to build; and some will dive into the data layer, while others leave that to the developer. I have to say that, the data side of building single-page (JavaScript) applications is still a lot like that last paragraph, in the Wild West. Building on top of something that mostly works but doesn't answer the direct needs of my application. Basically, building with an alpha/beta library and chasing a solution.

The Awakening

So after about two years, full-time, of focusing on building applications with Ember.js and doing battle with complex data needs (lots of read/write, multiple users in an app, big data, legacy data, magic data, think of a gem, and simple data)… I am now extremely thirsty for a common specification that works well for applications speaking JSON over HTTP. I'd like a specification, or format, that works really well in a JavaScript application and allows for data services to have the flexibility and freedom to own the data needs entirely. Those data services simply give a representation of resources as the client requests them - as well as provide operations to those resources' attributes, state and relationships via REST. Specifically, I would like the client to have no requirement to duplicate the ORM (Object-relational mapping) or to mimic how the backend maps relations (foreign keys). Ideally, services that provide a solid format for JSON data, are discoverable (provide URLs), and have a pattern for operating on the resources, etc. And of course, without the need to battle over data contracts between client and server (teams).

The Menace

So back to my history. After building the antithesis of a microsite, I worked on an email application built with Ember. We built an Ember app inside an Ember app for editing an HTML document (email template). We broke down an HTML document and turned it into editable views; then persisted the changed document so that it is ready to merge with data for mail delivery. Ember Data was in its first iteration and had a concept of a transactions, and still needed to define how to work with polymorphic data. The team was an early adopter of Ember.js, pre 1.x. The team fought with bugs in basically alpha software for data persistence but still managed to ship a beta product. Well, it turned out that that the team was not the right fit for me; and I moved on. However, I was able to adopt Ember.js early, before it hit a stable 1.0 release, this made me happy.

Attack at the Agency

Next, I took a position about 300 miles closer to home but still about 60 miles away. I do like working with Ember.js so tried to continue that effort. This was a small team, who previously built apps with SproutCore, the predecessor to Ember.js. The data relationships were complex, the need was for lots of reading and writing, as well as dealing with sparse record collections. There was a pattern of caching related data to be used in a list view by requesting an incomplete representations of a resource (for large lists) and reloading some records to refresh for detail views. We managed the state of resources in both the client and the server. We embedded snippets of data across various documents, managed the relationships of the data on the client, and we wished for id-only records (to deal with the sparse collections). We persisted collections of related records in batches, and disabled editing during the transaction.

There was the need to overhaul Ember Data and then it happened. The library abandoned transactions and embedded records. We tried to press forward anyway, our data needs did not change, the library changed its feature set. Perhaps the ambition needed to be simplified; we had dreams of a super ambitions data solution. So, we hacked up our feature set on top of the library we chose, Ember Data. We thought that this was the happy path for us.

Also we tried out a move to Ember Model, perhaps a lightweight solution would be sufficient. JSONPatch became appealing to us, as we fought with data inconsistencies from throwing around complete representations of objects asynchronously for both attribute changes and relationship changes. We spent about six months on a fork of an adapter/serializer combination that fixed the embedded records solution for Ember Data. It was a happy day when that work merged back into Ember Data. A sweet win for us and others who had similar needs for embedding records. Then the contract ended, another transition for me - I really wanted to work closer to home. (I have a big family.)

Big Data Strikes Back

Next, I moved to another early adopter of Ember.js, to work on ambitions applications utilizing big data. The apps consumed a big data set. Some data was input via file uploads, from UI input, and other data was changed/added by another source in the cloud platform - all of the changes require the app to be refreshed. This was another complex data solution using an early version of Ember Data which required a server solution to re-format the data accordingly to the client (data) conventions. Next, we built newer and smaller apps, yet as a collection of tools still ambitions in scope. We abandoned Ember Data for this work and built custom adapters to connect with our data services. With a big set of data… endpoints vary across the platform. Some of our requests require two or more requests to compose the resources in order to hand them off to the client application. We built "thick" client apps that work with many endpoints to capture slices of the large data set.

From these examples, I can see why there is not a single solution for everyone's use cases for data persistence. And why anyone working on a common data persistence solution is required to build a complex abstraction to address so many options to communication JSON resources via HTTP.

The Return to the Agency

Strange as it may seem, I actually went back to my old job. A friend opened up his seat making a way toward the flexibility I needed with my family and a stretch goal in my career in accepting a management role. I thought I'd never do that. On the microsite project I had a lead role. During that season I hardly wrote any code and ended up frustrated, the deadlines were nutty and the tech debt was steep. I really do like to build stuff, especially web applications. Now, I'm back in LA. I work remote most of the time and lead a small team. We have a handful of Ember apps that have lived for one or two years. These apps use a core library, so there are many shared components/views/controllers for UI needs, including managing large collections of resources. I am really happy :)

We still have a lot of work ahead of us. The apps we work on were sort of built in start-up mode. We need automated tests, this will help us stabilize change - and some refactoring. We'd like to move to Ember CLI quickly. We now have Ember 2.0-beta to embrace; so basically there are huge shifts that we need to make on our platform. To move to the new "Ember Way" because Ember 1.x is so last year. By the way, if you thought there was such a thing as an Ember Way, I'm sorry to disappoint you there is no such thing. The Web platform is moving fast these days and Ember.js does strive to skate to where the puck is going. So yeah change happens, well it happens a lot, that's the Ember Way. We usually ride canary or beta versions of Ember then when an app ships track to the current release. Over the past few years our apps made it all the way to 1.10. I've seen others that have not made it that far.

More Movie Puns

I have seen a few big Ember apps frozen (I know what you're thinking, "Let it go"). The freeze was due to loads of features that integrate with lots of data (while making big bets on Ember Data). When Ember Data was revamped the first time, there became too much effort to revamp the entire app and freeze shipping user stories. Perhaps it was just unfortunate timing for the product backlog. Just because the library changed, doesn't mean the business was ready to freeze the backlog while overhauling the app's data persistence solution. (To the product owners it sounds a lot like asking "Do you want to build a snowman?").

Maybe my experience is unique; however, I've heard similar stories where a major refactor had to take place, and was required to continue feature development. That makes sense, when the framework/library changes significantly, upgrades should be planned accordingly. Perhaps that is an early adoption tax, par for the course. Also, every project has an end of life; that's the perspective of the long game. One of my business coaches told me, "You always need an exit strategy". So I try to plan for how an app will end and make trade offs accordingly. At times it's ok not to track the current framework release and at other times that would kill the product.

The Good Bad and the Ugly

Experience teaches me to learn from the good parts… What would my ideal data persistence solution look like? Is there actually one? Or, does the journey always depend on the project requirements? That may be true. Most projects are not done perfectly the first time, maybe the second, or perhaps the third. The Ember Route had three big overhauls and so did the view layer.

Over the past month a few quotes have captured my attention…

“Don't try to be the smartest developer. Instead, be the most tenacious one.  Be the one who doesn't give up until the problem is solved.” –Dana Jones @danabrit Jun 4, 2015

“Anything worth doing is worth doing poorly until you learn to do it well.” –Zig Ziglar

“Success is when people who don't understand your tool are using it – so you have to plan for that” –@stubbornella #theMixinJune2015

As I have considered the idea of starting from scratch I collected a list of what I think would be needed for my current projects and future work.

The Bucket List

Here's a few things that I imagine would be included in my ideal persistence solution…

My API server defines the resources for my client application(s) to consume
My client application(s) understand & treat resources as first class, having no need to transform the resource to yet another representation
Wait, no transformation? Yeah, unless I want to, I do not want to be forced to.
Only define my ORM concerns in one place on the server, not two (again on the client)
I expect that less code means less bugs (I've seen a lot of bugs in data persistence layers)
A thin codebase with nomenclature that is shared with the API format for a resource and it's operations
During introspection of the representation of a resource within the client app, the object should have the same structure and nomenclature that the server defines for the resource
My client app(s) should define the caching concerns for the requests resource(s) and have the option to honor the cache headers; 304's are fine. HTTP has solved caching already
Optionally minimize redundant requests when making a query for a group of related resources
Perhaps the caching strategy can be a mixin that works together with the resources which have properties to indicate when they are expired
I want a service object that is injected wherever I interact with the resources, and a singleton for each service that has an event bus to communicate with all the resource instances of the same type. For example to make updates as close to real time as possible by PATCHing the resource
I want to define the resource's states, some common states will work like isDirty
I want the resource to know when it has changed and send that event to the service
I need a simple way to compute properties from the resource attributes to meet the needs of the client application
I want relationships between resources to be defined in a simple way and for the resources to know how to operate on its relations, like adding/removing relations as independent actions, totally separate from persisting the attributes of the resource itself
I'd like a store service that is a facade to all the services that are used by the various resources, one point of service to call methods for fetching, crud operations, as well as operations on the resource's relation(s)
I'd like each service to house it's own cache for it's type (entity) as well as track any meta data associated with the collection or per request
The resources should keep track of their own meta data, relationships and links. The service(s) should not need to construct URLs for all the operations on a resource
Oh, and I want URLs to be first class, The API server sends the links that the client should use
Perhaps I can abandon XHR and go with window.fetch

Back to the Present

Now let's fast forward to today… Meet JSON API, version 1.0 - A new specification. “Your anti-bikeshedding weapon.” Wow, two years of hammering out a specification for representing objects in JSON over HTTP (REST). The spec looks solid, I've taken it for a test drive over the last year - kicking the tires and testing out the spec as it has taken shape. I'm very impressed and happy with this specification. I imagine that it should last for some time, perhaps years to come. Maybe I'll bring my current projects up to the spec and later build out new application servers using a different language but use the same JSON API specification. Sounds promising, doesn't it!

But wait, aren’t you supposed to use  Ember Data? My suggestion is that you don’t let someone decide for you. Seek a solution that fits the problem domain of your project needs. That might be Ember Data, for me it is not; at lease not at 1.x or 2.x. Maybe the 3rd time will be the charm. What I'm interested in is a simple solution that is written from the ground up to fit the format of the JSON API 1.0 Specification, period. So, I can just get straight to work… shipping user stories (doing less bug hunting in the data library).

I've convinced myself to build a persistence solution, even though there is one that has existed for a couple years and has had about 300 contributors, including myself. And even though that solution has hit a (stable) release tag of v1.13, while also tagged for 2.0-beta on the same day. Seriously I'm not bitter or anything, Ember Data is an excellent library. But what I've come to realize is that Ember Data does not provide the solution I am looking for. Ember Data provides a great adapter/serializer pattern to connect any type of data service to your Ember app. Ember Data thinks like an active record ORM; at least in nomenclature; belongsTo and hasMany remind me that Ember Data needs foreign keys as a primary way to connect relationships vs. URLs. I'm a web guy, I like URLs. URLs are the main selling point and reason I adopted Ember.js in the first place. The Ember.Router has great URL support from the start.

A Battle Plan Emerges

So here’s my plan… Do only what the server's specification defines for it's resources, and do only that. To simplify the mental model  for the client(s) that collaborate with the resources via server app(s). To fire the middleman, reduce the abstractions, reduce barriers for developers to ramp up on a project, minimize the code base which is responsible for the data layer. To build a direct path from point A to point B (client/server). I will use a solution that is direct and concise, with a strong set of features, proven solutions, and reserve the freedom add in my needs for caching and acting on state/events that make sense to the application's needs.

Actually this is not that hard, Ember.js has great primitives for some very advanced behaviors, like the Ember.PromiseProxyMixin, Ember.Evented, Ember.Service and Ember.Object prototypes. It would be hard if I did not have a few years of experience with the framework. With that experience I find a lot of power in using the Ember.js framework. Dependency injection is easy, the concept of services are first class, the testing story is excellent now, the application.container is my friend I can create factories for my resources and register singletons for my services.

So now I am taking the posture of a Samurai Warrior –  “dying before going into battle.” The warrior enters combat event without fear of death,  acceptance of his own death in advance. I tell myself, “Don't become like water my friend, instead become a dead man walking”.   I will unconditionally commit to success in battle  without worrying about survival. What I am about to describe is my tactical response to adopting the new JSON API specification, from the ground up. Yes, going forward, I will roll my own data persistence library – because I can and it's no longer hard to do. If the project dies so be it.

A Man Can Change His Destiny

“The perfect blossom is a rare thing. You could spend your life looking for one, and it would not be a wasted life.” –Katsumoto (The Last Samurai)

Well I don't believe there is a perfect data persistence solution and won't suggest that I can create a perfect solution either. But, I will pursue it.

The Nitty Gritty

Let's just assume that I could create an elegant solution. How would I do that using Ember.js?

First I'd get intimate with the JSON API format Then I'd create a Resource Object as my base model prototype in an Ember app. I will begin by building an Ember CLI addon for the Resource and whatever else I need.

A Resource Object

A Resource (or 'model') can resemble the structure of an object as defined by the JSON API 1.0 Specification. The Resource prototype creates hashes for: attributes, relationships, links, meta, and has attributes: id and type. The properties and structure of a model created by extending Resource closely follow the objects defined by the JSON API specification.

It would be used like so:

export default Resource.extend({
  type: 'post',
  service: Ember.inject.service('posts'),

  title: attr(),
  date: attr(),
  excerpt: attr(),
  body: attr(),
  slug: attr(),

  author: hasOne('author'),
  comments: hasMany('comments')
});

I want helpers to get and set the attributes, I'll use an attr() helper method to set that up. That method can track changes as properties are set and manage the current/previous attributes so I can know whether the instance has changed attributes. And by injecting a service I can emit events like attributeChanged so the service can persist the change in as close to real time as possible.

The Ember CLI addon can define generators so I can scaffold the prototypes for my resources, like the above example. I can just use ember generate resource entityName

The resource can have addRelationship and removeRelationship methods to compose the relationships that the resource is associated with. The hasOne and hasMany helpers can setup the computed properties that utilize the Ember.PromiseProxyMixin to find the related resource(s) based on the URLs in the resource's relationships object which contains links object(s)

The resource can have an isCacheExpired property so that if the service keeps a reference or cache of it, the 'staleness' of the data can be found out.

And using the attributes hash of the resource instance I can compute properties from it for using in my templates that are read-only like so:

export default Resource.extend({
  type: 'comment',
  service: Ember.inject.service('comments'),

  body: attr(),

  date: Ember.computed('attributes', {
    get() {
      return this.get('attributes.created-at');
    }
  }).readOnly(),

  commenter: hasOne('commenter'),
  post: hasOne('post')
});

A new resource may be generated in a route model hook like so:

model() {
  return this.container.lookup('model:posts').create({
    isNew: true,
    attributes: { date: new Date() }
  });
}

Notice that the attributes hash is used to set initial properties. The computed properties created with the attr() helper are used as accessors to get/set rather than to create. That's how the resource was represented in JSON from the server anyway, resource attributes belong to the attributes object, I'll just keep it like that for the sake of simplicity.

Now that I have a base model or Resource with helpers to compose the properties that are meant to be used in the user interface (given to the template) I can setup an Adapter to fetch resources from a API server.

An Adapter Object

This should be a singleton instance for each type of entity (or resource) that can be fetched and/or persisted.

Given that an Ember.js app may be hosted as a stand-alone client application and may choose to use use a proxy to bring an API server into it's own domain. It's likely that I may need a couple hooks manipulate the URL's in the relationships object of a resource - since it's required in a browser to work within the same domain. Unless you really want to use CORs (cross-origin resource sharing).

Imagine I have a ApplicationAdapter that is already setup to work with my JSON API server, I could use something like this:

import ApplicationAdapter from './application';
import config from '../config/environment';

export default ApplicationAdapter.extend({
  type: 'post',

  url: config.APP.API_PATH + '/posts',

  fetchUrl: function(url) {
    const proxy = config.APP.API_HOST_PROXY;
    const host = config.APP.API_HOST;
    if (proxy && host) {
      url = url.replace(proxy, host);
    }
    return url;
  }
});

Well I need to define at least one URL for the service, from there I can use the relationships' links' objects.

Perhaps the methods my Adapter needs are: find, findOne, findQuery, findRelated, fetch, createResource, deleteResource, updateResource, patchRelationship, and cacheResource. And a couple properties: type and url. That should make for solid interface to speak JSON over HTTP.

Now that I have an Adapter I'll need a Serializer object to serialize/deserialize resources, basically I need to make Resource instances after I fetch and will need to serialize changed attributes to patch the resource to meet my goal of persisting changes as close to real time as possible.

A Serializer Object

Well I think since I've followed a solid specification, JSON API, the needs for this prototype will be simple.

Perhaps the interface will include methods to: deserialize, deserializeIncluded, deserializeResource, deserializeResources, serialize, serializeChanged, serializeResource.

I may use a private method for how the resources are created perhaps like:

/**
  Create a Resource from a JSON API Resource Object
  See <http://jsonapi.org/format/#document-resource-objects>
  @private
  @method _createResourceInstance
  @param {Object} json
  @return {Resource} instance
*/
_createResourceInstance(json) {
  const factoryName = 'model:' + json.type;
  json.meta = json.meta || {};
  return this.container.lookupFactory(factoryName).create({
    'type': json.type,
    'id': json.id,
    'attributes': json.attributes,
    'relationships': json.relationships,
    'links': json.links,
    'meta': json.meta
  });
}

Like I said earlier the Resource should closely resemble the specification. No need to change it around and confuse things for developers.

Well this may be different that what people are used to, but the JSON API spec is sweet - so going with that. Notice that the properties created with the attr() helper are not used during .create() all the attributes belong in the attributes object, period; that sould be protected, that's how the spec defines attributes.

Using an initializer, I can register this factory in the application container and inject a singleton instance as dependency into the Adapter singleton. Oh, did I mention that I'd register and inject the Adapter factory? Yeah these two work in tandem.

Please be patient my friend, I'll get to all the details about initialization soon. I think I'm still missing a couple pieces, like a strategy for caching.

A Cache Mixin

Well now this is a can of worms. I thought HTTP and browsers already solved this problem. Yes, and now is my opportunity to get out of the business of managing a distributed cache by blindly pushing everything into memory and dancing around that.

Managing a distributed cache requires flexibility. When a client application receives a representation of a resource from a server, the client should be able to expire that cached object (in the browser application) based on the server's response headers; or by whatever means the developer chooses.

Perhaps the caching plan for a service is simply creating a ServiceCacheMixin that can be easily customized and has some basic defaults. I recall that Akamai defaults to about 7 minutes, or at least when I used it that was our default. How about that, I'll setup a property for the Resource prototype with an expires time e.g. cacheDuration and a computed boolean for isCacheExpired.

The cache mixin will need a property to hold it's contents, e.g. cache and some methods like: cacheControl, cacheData, cacheLookup, cacheMeta, cacheResource, cacheUpdate.

The cacheControl method can track the response headers from the request and mark some timestamps like the server time and the client time, for our simple expire in X minutes approach.

Why would I want to cache the data in memory anyway? I mentioned that was a solved problem, no?

I want to fetch a resource that hasMany other resources and in my template will reference that like resource.comments so that the related resources are fetched (asynchronously and on demand). Those related resources may have a common relation, let's call it a commenter. For example a post has a bunch of comments, cause you know it was popular. An there was some dialog so a few people commented a fews times in the discussion. Well I don't want to fetch those same commenters over and over do I? I don't mind the option to cache, but also like the option not to. To cache or not to cache that is a question for the server and perhaps the developer. That's where the default expires time comes in handy. As the developer I can set the rules for how long a resource is temporarily cached in memory and when I just want to trust the cache headers and lean on 304 responses.

If the caching strategy is simply a mixin it's a great hook to do something more advanced like using the cacheData, cacheMeta and cacheLookup to keep offline copies in localStorage if I want to be 'offline ready'.

Hum, so now that I have an adapter, a serializer and a cache mixin it seems like that would be a good recipe for a Service object to manage the combined solution for data persistence. Perhaps so…

A Service Object

A service for a resource can work to persist an instance of that entity using crud operations with HTTP verbs: CREATE, PATCH, GET, DELETE. The service can be named after the nouns of my JSON API server. For example a post resource (entity) may be requested using GET /api/v1/posts or GET /api/v1/posts/1. A service instance can be a singleton that is registered on my application's container using a pluralized name for the entity, e.g. 'posts'. Again we'll need to use an initializer to put this service into play and may also inject the service at will, for example on the resource prototypes using Ember.inject.service('posts')

Perhaps Service objects are "evented" to facilitate close to real-time updates.

When an attr is set and the value has changed the resource may emit an event for attributeChanged on the resource's service object. The adapter can listen to this event and respond with a call to updateResource which in turn sends a PATCH request with only the data for the changed attributes (a payload created by the serializer's serializeChanged method).

That would be a good way for the collaboraters, the fantastic four (adapter, serializer, cache and resources), to form as a service to act out the requirements for the application's data persistence needs.

A PostsService object may be as simple as this:

import Adapter from '../adapters/post';
import ServiceCache from '../mixins/service-cache';

Adapter.reopenClass({ isServiceFactory: true });

export default Adapter.extend(ServiceCache);

With the injection of this service into the Resource instances there is an event bus for these collaborators to work.

Now that these four prototypes have taken shape let's get into the business of dependency injection using an initializer.

The Resource Blueprint

Since I am building an Ember CLI addon for this data persistence solution I can create blueprints for all the things.

The resource blueprint is a generator for an initializer, a resource, an adapter, a serializer, and a service - all created by using the command ember generate resource post

So here is what the initializer can look like to set all these objects into motion:

import Service from '../services/posts';
import Model from '../models/post';
import Adapter from '../adapters/post';
import Serializer from '../serializers/post';

export function initialize(container, application) {
  const adapter = 'service:posts-adapter';
  const serializer = 'service:posts-serializer';
  const service = 'service:posts';
  const model = 'model:posts';

  application.register(model, Model, { instantiate: false });
  application.register(service, Service);
  application.register(adapter, Adapter);
  application.register(serializer, Serializer);

  application.inject(model, 'service', service);
  application.inject('service:store', 'posts', service);
  application.inject(service, 'serializer', serializer);
}

export default {
  name: 'posts-service',
  after: 'store',
  initialize: initialize
};

Did you notice that, this initializer executes after the store initializer, but I did not create a store yet. Oops, I sould do that. Developers like having a store.

“Let’s put a smile on that face!” -Heath Ledger’s Joker (The Dark Knight)

The Store Service Object

A store service can be injected into the routes. This is similar to how Ember Data uses a store, but the resource should be referenced in the plural form (like my API endpoint), easy peasy.

The interface for a store service can be a simple facade for the services created for each resource in the application. I can call the store method and pass in the resource name, e.g. 'post' which interacts with the 'posts' service for my 'post' resource.

An example route hook to find all post resources from the posts service:

import Ember from 'ember';

export default Ember.Route.extend({
  model() {
    return this.store.find('post');
  }
});

This Store object is a facade to the various other Service objects in the application. Each service will be injected into the to store service. So it can be a service of services. One interface for all my persistance needs.

In the example above, the store object can pluralize the type, to lookup the resource's service object, i.e. 'service:posts'.

Wait, isn't that how Ember's Route#model hook works anyway? Yeah basically, this.store.find('post', '1') or I can use a query object: this.store.find('post', {sort: 'desc', filter: 'blah'});

I'm not sure if you think this solution would be a lot of work or not. I would work toward create a solid test suite as well. Perhaps that can be a follow up post - on testing a data persistence solution. Now that Ember CLI makes unit testing simple and easy to embrace testing should be fairly straight forward to achieve. Well in addition to the tests there is a dummy application that can be built as demo; even utilized for my manual testing needs - like using a proxy to a live JSON API server. That's what I would do, test all the things, both automated unit tests and manual using an app.

(Spoiler alert) This app is running with a JSON API server and this data persistence solution – so here is your demo and proof of concept.

Take Aways

I recommend getting to know the JSON API 1.0 Spec. I propose that your data persistence solution can be a direct line between your client and server while still utilizing a robust feature set which is inline to accompany the way your application server defines and operates on resources.

Whether you adopt the JSON API 1.0 spec or not… this example (addon) can be a template for creating a data persistence solution for your Ember.js application – which models the domain of your API server without any extra abstraction.

One of the primary drivers for keeping my data layer thin is this concept e = mc², that is Errors = (More Code)². I'd like less code and only code that fits my use cases.

Start Today

I hope you caught on, in this post I used a verb tense as if I will need to build out this solution. But actually, I already have. Here is a review on emberobserver.com

The README
Demo App (this blog is also a demo of using the solutions linked below)
Developer's Guide
Code Documentation
Travis builds

JSON API Implementations

JSON API implementations
Ember CLI Addon - Ember JSONAPI Resources
Ruby gem - JSONAPI::Resources

Practical: Deploy an Ember App with ember-cli-deploy

2015-04-25T00:00:00+00:00

Lightning-Approach Workflow

This approach is the default setup when using ember-cli-deploy and uses a Redis
store for the versions of your index.html file that you deploy. This strategy allows
for (pre)viewing any deployed version using an URL parameter.

For the application's asset files (CSS, JavaScript, images, etc) this workflow pushes
them to an S3 bucket.

Below is the documentation and includes a diagram of the approach:

See Documentation

Deploy an App with ember-cli-deploy

How to use…

ember deploy --environment production
ember deploy:list --environment production

Pick a version to deploy

ember deploy:activate --revision chat-app:XXXXXX --environment production

You can preview a version using the index_key parameter, like so
http://chat.pixelhandler.com/?index_key=cde6f62 where the parameter represents a
commit hash that has been deployed (but may not be activated yet).

Firebase

Create your own firebase account, signup here.
Then your app will have a real-time backend. In your app config use your account url:

Mine is: https://pixelhandler.firebaseio.com/
I set the above URL in the config/environment.js file of my Ember app

Security & Rules

In your Firebase Application Dashboard, setup the rules for your data. The collection
that the application uses is messages.

{
  "rules": {
    ".read": true,
    ".write":false,
    "messages":{
      ".read": true,
      ".write": true,
      ".indexOn": "timestamp"
    }
  }
}

Setup an Ubuntu box with DigitalOcean

DigitalOcean has excellent guides on using their hosting service. See this guide
which details the setup of an Ubuntu box:

Guide: Initial Server Setup

Install Node.js

I recommend using NVM, Node Version Managager, to install versions of Node.js

See NVM
Use forever to continuously run a Node.js app

Install Nginx

Guide: how-to-install

You may need to edit your nginx config file or perhaps view the logs…

Config

sudo vim /etc/nginx/nginx.conf

Logs

tail -f /var/log/nginx/access.log
sudo tail -f /var/log/nginx/error.log

Restart

sudo service nginx restart

Install Redis

Guide: how-to-install

See the Redis downloads page for the current version:

http://redis.io/download

Post Install Setup

Setup your redis server with a script…

cd /usr/local/src/redis-3.0.0/utils
sudo ./install_server.sh

I used port 6379 which setups up a config file at /etc/redis/6379.conf

Config

Bind your IP address for the server your app runs on, mine is on 107.170.232.223.

vim /etc/redis/6379.conf

bind 107.170.232.223 127.0.0.1
requirepass yoursecretkeyshouldbeverylongyouknowredisisfastright

Notice in the config file that you are encouraged to use a long passwords

Connecting

I'm using an environment variable for my redis password

redis-cli -h pixelhandler.com -p 6379 -a $REDIS_SECRET

Or locally on the Ubuntu box:

redis-cli -h 127.0.0.1 -p 6379

Then enter the AUTH command followed by your secret key

Start/Stop

sudo service redis_6379 start
sudo service redis_6379 stop

Show the keys

Once you deploy a version you can connect then list the keys that are stored:

keys *

Install Git

If not already installed setup your box to use git:

Guide: how-to-install

AWS S3 Bucket

I created a bucket named chat-app to host the application assets: the app JS & CSS as well ass the contents of the public directory of the client application.

My Endpoint: chat-app.s3-website-us-east-1.amazonaws.com

Bucket Policy

I used the policy generator tool in AWS to setup a bucket policy for any
Web visitor to read the assets in the bucket for the chat-app:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPublicRead",
      "Action": [
        "s3:GetObject"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::chat-app/*",
      "Principal": {
        "AWS": "*"
      }
    }
  ]
}

I tested an upload of a simple index.html file to be sure the setup works, which will
get clobbered by the deployment anyway. The index.html file that gets pushed to the
bucket will not be used to serve the website.

Bucket User

This is a good tutorial on configuring your S3 bucket for deploying
assets for your Ember application:

Example setup: deploy to s3

You'll need to setup an user that can write to your bucket, use the AWS console tools
to create new user for your S3 bucket:

IAM policy, services -> IAM -> Create New Users
- AWS users

You'll need to copy the access key and secret access key to use in your deployment
config for pushing assets to your S3 bucket.

User's Inline Policy for the bucket, notice that the bucket name is the same as
my app name:

{
  "Statement": [
    {
      "Action": "s3:*",
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::chat-app",
        "arn:aws:s3:::chat-app/*"
      ]
    }
  ]
}

Environment Variables

The chat app's deployment script will use environment variables for:

AWS_ACCESS_KEY, AWS_SECRET_ACCESS_KEY
See AWS users for your user's access keys

Chat App

Running at http://chat.pixelhandler.com/
Source for server app: ember-lightning
Source for client app: ember-cli-screencast

Server app needs config setup in an app.json file, copy the app.example.json
on your box.

Client app is using environment variables in the config/deploy.js file, I created a dot file that I source when running the ember deploy command. See deploy section above, which lists out the deployment commands.

Clone the example app and install the dependencies:

git clone [email protected]:Ember-SC/ember-cli-screencast.git ./chat-app-client
cd chat-app-client
npm install
bower install

Try out ember server locally and visit http://localhost:4200

If the app works get ready to deploy to your production box.

First setup your server with Node.js & Redis to try out your first deployment with
ember-cli-deploy. The following section explains the hosting setup for your
production server…

Vhost Setup

Using nginx I setup a proxy to the port that the node application will run on.

See: host multiple node.js apps

DNS

I used Amazon's Route 53 product for my DNS. So I added a subdomain on
my hosted zone:

chat.pixelhandler.com.
A
107.170.232.223

Serve up the Index.html page

When using ember-cli-deploy-redis, versions of your app will have a key that
is a combination of your app name and the commit hash of the release.
Your Redis DB will store the various deployed versions of your index page.

See ember-cli-deploy adapters for existing index adapters

I setup a www directory in my home user, then used git to clone the
example [ember-lightning] app which connects to redis and serves up the
index.html page in a node.js app. The app also accepts an URL
query parameter to get the version of the index.html to send back to the browser.

See: ember-lightning

cd ~/www/
git clone https://github.com/Ember-SC/ember-lightning ./chat-app-server
cd ./chat-app-server

Run with forever…

nvm use 0.12.2
npm install
forever start -c "node --harmony" -o ~/www/chat-app-server/out.log -e ~/www/chat-app-server/err.log --spinSleepTime 10000 --minUptime 10000 ~/www/chat-app-server/index.js >> ~/www/chat-app-server/out.log 2>&1

Nginx config for the chat-app

Create a conf file for your vhost, e.g. /etc/nginx/conf.d/chat.pixelhandler.com.conf

This uses a proxy pass to the IP and port that the node.js app runs on. I'm running
on port 8787.

server {
  listen 80;

  server_name chat.pixelhandler.com;

  location / {
    proxy_pass http://107.170.232.223:8787;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
  }
}

Restart nginx

sudo service nginx restart

Recap

I used an Ubuntu box to deploy a client Web applicaiton that uses Firebase as a
backend. These notes provide an exercise in learning to deploy an Ember.js
application built with Ember CLI.

See the screencast on building the chat-app by Sara Robinson of Firebase
My fork of the source code
The server app the renders the current version and allows previewing other deployed versions: ember-lightning fork

I chose a Node.js app to serve up the index.html page in anticipation of
the FastBoot addon to render an Ember.js app on the server.

Consider using my referal link to sign up for DigitalOcean and try out
ember-cli-deploy yourself.

Some alternatives to setting up your own box are:

So if you what to chat about this article visit chat.pixelhandler.com.

How Much Faster is HTMLBars Than Handlebars?

2015-03-08T00:00:00+00:00

When I shared the data with Kris Seldon, he asked whether I had normalized the data and calculated the geometric mean, since that would be a proper way to compare benchmarks. I found the document How not to lie with statistics, The correct way to summarize benchmark results by Philip J. Fleming and John J. Wallace. So, I wrote a query for my data set that would group the metrics data in an effort to normalize the measurements taken from actual users on various devices and group the measurements into the benchmarks that I could generate some reporting data from.
To itentify the benchmarks I could report on I wrote some filters for the various userAgent strings within my metrics data. I considered the combination of the operating system and the browser, e.g. Safari on Macintosh, or iPad combined with a type of metric, e.g. index_view. Then I compared the Ember versions.

With the normalized set of data, I created a query that would take the latest measurements, up to 100, from the normalized data set and calculated the geopmentric mean for the various benchmarks. I calculated the product of each duration in the normalize set; then raised that value by an exponent that is the reciprocal of the number of factors in that product. (Geometric Mean: multiply the numbers and then take the nth root of the product.) The calculation looked something like this Math.round(Math.pow(2 * 3 * 5 * 8 * 13 * 21, 1/6) * 1000) / 1000 (I rounded to the nearest thousandth). As for the normalization of the data, the metrics can be reported by the Ember Version, platform (Macintosh/Windows) and browser (Chrome, Safari, Firefox, iPad, iPhone, Android) for the specific metric type, e.g. index_view, post_view or the metric_table (for the long list of 1,000 items).

I'd like to share my measurements and calculations…

Performance Report

For the upgrade on my site to HTMLBars from Handlebars 1.3…

Across the board, for the benchmarks I am intersted in, it looks like HTMLBars brought a 10-22% gain in rendering speeds

Index View: Home Page

Platform	Browser	v1.8 Mean	v1.10 Mean	Difference	Gain/Loss %
Macintosh	Safari	162.343	86.653	75.69	47%
Macintosh	Chrome	183.794	187.945	-4.151	-2%
Windows	Chrome	136.289	211.616	-75.327	-55%
iOS	iPhone	450.503	352.764	97.739	22%
Overall	206.89	186.73	20.16	10%

Post View: Article Pages

Platform	Browser	v1.8 Mean	v1.10 Mean	Difference	Gain/Loss %
iOS	iPad	801.595	375.945	425.65	53%
iOS	iPhone	348.711	302.05	46.661	13%
Android	Various	850.716	862.627	-11.911	-1%
Macintosh	Safari	109.321	117.684	-8.363	-8%
Macintosh	Chrome	145.244	163.481	-18.237	-13%
Windows	Chrome	203.063	232.081	-29.018	-14%
Macintosh	Firefox	147.432	140.634	6.798	5%
Windows	Firefox	200.542	163.704	36.838	18%
Overall	262.68	237.34	25.34	10%

Metrics Table: Long List of 1,000 Records

Platform	Browser	v1.8 Mean	v1.10 Mean	Difference	Gain/Loss %
iOS	iPad	3323.655	2170.638	1153.017	35%
iOS	iPhone	1580.537	1268.771	311.766	20%
Macintosh	Safari	448.611	302.707	145.904	33%
Macintosh	Chrome	903.33	646.06	257.27	28%
Windows	Chrome	812.356	829.604	-17.248	-2%
Macintosh	Firefox	865.249	743.429	121.82	14%
Overall	1069.48	832.20	237.27	22%

The Details

Below is a look at the calculations for each of the benchmarks that I included in the summary above.

The Index (Home) Page

Safari on Macintosh

HTMLbars shaved of 76 milliseconds, a 46% gain in rendering speed

{
  fast: 32.94,
  geometric_mean: 86.653,
  measurments: 100,
  name: "index_view",
  slow: 819,
  emberVersion: "1.10",
  platform: "Macintosh",
  browser: "Safari"
}

{
  fast: 105.18,
  geometric_mean: 162.343,
  measurments: 4,
  name: "index_view",
  slow: 244.669,
  emberVersion: "1.8",
  platform: "Macintosh",
  browser: "Safari"
}

Chrome on Macintosh

Only a 4 millisecond difference, a 2% decrease in rendering speed

{
  fast: 65.41,
  geometric_mean: 187.945,
  measurments: 100,
  name: "index_view",
  slow: 9547.233,
  emberVersion: "1.10",
  platform: "Macintosh",
  browser: "Chrome"
}

{
  fast: 90.804,
  geometric_mean: 183.794,
  measurments: 70,
  name: "index_view",
  slow: 550.173,
  emberVersion: "1.8",
  platform: "Macintosh",
  browser: "Chrome"
}

Chrome on Windows

Handlebars 1.3 was 74 milliseconds faster, a 35% gain in rendering speed

{
  fast: 81.023,
  geometric_mean: 211.616,
  measurments: 100,
  name: "index_view",
  slow: 1397,
  emberVersion: "1.10",
  platform: "Windows",
  browser: "Chrome"
}

{
  fast: 95.374,
  geometric_mean: 136.289,
  measurments: 13,
  name: "index_view",
  slow: 172.329,
  emberVersion: "1.8",
  platform: "Windows",
  browser: "Chrome"
}

Android

Only had measurements on Ember v1.10.0

{
  fast: 520.524,
  geometric_mean: 841.979,
  measurments: 18,
  name: "index_view",
  slow: 1382.816,
  emberVersion: "1.10",
  platform: null,
  browser: "Android"
}

iPad

Only had measurements on Ember v1.10.0

{
  fast: 155,
  geometric_mean: 484.614,
  measurments: 34,
  name: "index_view",
  slow: 1120,
  emberVersion: "1.10",
  platform: null,
  browser: "iPad"
}

iPhone

HTMLBars shaved off 98 milliseconds, a 22% gain in rendering speed

{
  fast: 143,
  geometric_mean: 352.764,
  measurments: 62,
  name: "index_view",
  slow: 1490,
  emberVersion: "1.10",
  platform: null,
  browser: "iPhone"
}

{
  fast: 330,
  geometric_mean: 450.503,
  measurments: 7,
  name: "index_view",
  slow: 588,
  emberVersion: "1.8",
  platform: null,
  browser: "iPhone"
}

So for the index page the gains from HTMLBars I noticed were on Safari on Macintosh and on the iPhone. However using Chrome on Windows Handlebars was faster.

I didn't have lots of data for the home page in Ember v1.8.1 but did get loads of traffic on some of my posts, let's see how the individual posts pages did.

Post (Article) Pages

iPad

HTMLBars shaved off about 426 milliseconds, a 53% gain in rendering speed

{
  fast: 116,
  geometric_mean: 375.945,
  measurments: 100,
  name: "post_view",
  slow: 2051,
  emberVersion: "1.10",
  platform: null,
  browser: "iPad"
}

{
  fast: 193,
  geometric_mean: 801.595,
  measurments: 18,
  name: "post_view",
  slow: 1449,
  emberVersion: "1.8",
  platform: null,
  browser: "iPad"
}

iPhone

HTMLBars shaved off about 47 milliseconds, an 11% gain in rendering speed

{
  fast: 8,
  geometric_mean: 302.05,
  measurments: 100,
  name: "post_view",
  slow: 2139,
  emberVersion: "1.10",
  platform: null,
  browser: "iPhone"
}

{
  fast: 174,
  geometric_mean: 348.711,
  measurments: 32,
  name: "post_view",
  slow: 985,
  emberVersion: "1.8",
  platform: null,
  browser: "iPhone"
}

Android

Handlebars 1.3 was 12 milliseconds faster, no rendering speed gains from upgrade to HTMLBars

{
  fast: 204.868,
  geometric_mean: 862.627,
  measurments: 100,
  name: "post_view",
  slow: 4610.199,
  emberVersion: "1.10",
  platform: null,
  browser: "Android"
}

{
  fast: 275.503,
  geometric_mean: 850.716,
  measurments: 74,
  name: "post_view",
  slow: 2747.738,
  emberVersion: "1.8",
  platform: null,
  browser: "Android"
}

Safari on Macintosh

Handlebars 1.3 was 8 milliseconds faster, no rendering speed gains from upgrade to HTMLBars

{
  fast: 20.164,
  geometric_mean: 117.684,
  measurments: 100,
  name: "post_view",
  slow: 5616.18,
  emberVersion: "1.10",
  platform: "Macintosh",
  browser: "Safari"
}

{
  fast: 50.377,
  geometric_mean: 109.321,
  measurments: 100,
  name: "post_view",
  slow: 2551.46,
  emberVersion: "1.8",
  platform: "Macintosh",
  browser: "Safari"
}

Chrome on Macintosh

Handlebars 1.3 was 18 milliseconds faster, no rendering speed gains from upgrade to HTMLBars

{
  fast: 19.82,
  geometric_mean: 163.481,
  measurments: 100,
  name: "post_view",
  slow: 4220.102,
  emberVersion: "1.10",
  platform: "Macintosh",
  browser: "Chrome"
}

{
  fast: 18.673,
  geometric_mean: 145.244,
  measurments: 100,
  name: "post_view",
  slow: 2884.554,
  emberVersion: "1.8",
  platform: "Macintosh",
  browser: "Chrome"
}

Chrome on Windows

Handlebars 1.3 was 29 milliseconds faster, no rendering speed gains from upgrade to HTMLBars

{
  fast: 31.697,
  geometric_mean: 232.081,
  measurments: 100,
  name: "post_view",
  slow: 13214,
  emberVersion: "1.10",
  platform: "Windows",
  browser: "Chrome"
}

{
  fast: 56.472,
  geometric_mean: 203.063,
  measurments: 100,
  name: "post_view",
  slow: 3696,
  emberVersion: "1.8",
  platform: "Windows",
  browser: "Chrome"
}

Firefox on Macintosh

HTMLBars was 7 milliseconds faster, only a minor gain in rendering speed

{
  fast: 45.745,
  geometric_mean: 140.634,
  measurments: 100,
  name: "post_view",
  slow: 1247.685,
  emberVersion: "1.10",
  platform: "Macintosh",
  browser: "Firefox"
}

{
  fast: 71.173,
  geometric_mean: 147.432,
  measurments: 62,
  name: "post_view",
  slow: 387.791,
  emberVersion: "1.8",
  platform: "Macintosh",
  browser: "Firefox"
}

Firefox on Windows

HTMLBars was 37 milliseconds faster, an 18% gain in rendering speed

{
  fast: 73.865,
  geometric_mean: 163.704,
  measurments: 100,
  name: "post_view",
  slow: 1860,
  emberVersion: "1.10",
  platform: "Windows",
  browser: "Firefox"
}

{
  fast: 69.896,
  geometric_mean: 200.542,
  measurments: 100,
  name: "post_view",
  slow: 1305.268,
  emberVersion: "1.8",
  platform: "Windows",
  browser: "Firefox"
}

Metrics Table (long list of 1,000 records)

iPad

I only had a couple measurments…

Looks like HTMLBars can be 1153 milliseconds faster, a 35% gain in rendering speed

{
  fast: 2062,
  geometric_mean: 2170.638,
  measurments: 2,
  name: "metrics_table",
  slow: 2285,
  emberVersion: "1.10",
  platform: null,
  browser: "iPad"
}

{
  fast: 3103,
  geometric_mean: 3323.655,
  measurments: 2,
  name: "metrics_table",
  slow: 3560,
  emberVersion: "1.8",
  platform: null,
  browser: "iPad"
}

iPhone

HTMLBars was 312 milliseconds faster, a 20% gain in rendering speed

{
  fast: 675,
  geometric_mean: 1268.771,
  measurments: 8,
  name: "metrics_table",
  slow: 1568,
  emberVersion: "1.10",
  platform: null,
  browser: "iPhone"
}

{
  fast: 871,
  geometric_mean: 1580.537,
  measurments: 8,
  name: "metrics_table",
  slow: 5380,
  emberVersion: "1.8",
  platform: null,
  browser: "iPhone"
}

Safari on Macintosh

HTMLBars was 146 milliseconds faster, a 48% gain in rendering speed

{
  fast: 239.835,
  geometric_mean: 302.707,
  measurments: 13,
  name: "metrics_table",
  slow: 416.321,
  emberVersion: "1.10",
  platform: "Macintosh",
  browser: "Safari"
}

{
  fast: 287,
  geometric_mean: 448.611,
  measurments: 6,
  name: "metrics_table",
  slow: 568.253,
  emberVersion: "1.8",
  platform: "Macintosh",
  browser: "Safari"
}

Chrome on Macintosh

HTMLBars was 257 milliseconds faster, a 28% gain in rendering speed

{
  fast: 414.107,
  geometric_mean: 646.06,
  measurments: 27,
  name: "metrics_table",
  slow: 1584.423,
  emberVersion: "1.10",
  platform: "Macintosh",
  browser: "Chrome"
}

{
  fast: 457.012,
  geometric_mean: 903.33,
  measurments: 27,
  name: "metrics_table",
  slow: 1564.946,
  emberVersion: "1.8",
  platform: "Macintosh",
  browser: "Chrome"
}

Chrome on Windows

Handlebars 1.3 was 17 milliseconds faster, a 2% decrease in rendering speed

{
  fast: 615.905,
  geometric_mean: 829.604,
  measurments: 3,
  name: "metrics_table",
  slow: 1142.15,
  emberVersion: "1.10",
  platform: "Windows",
  browser: "Chrome"
}

{
  fast: 765.64,
  geometric_mean: 812.356,
  measurments: 2,
  name: "metrics_table",
  slow: 861.923,
  emberVersion: "1.8",
  platform: "Windows",
  browser: "Chrome"
}

Firefox on Windows

I did not collect enough measurements to make a comparison

Firefox on Macintosh

The data is limited to 2 and 4 measurements, I've incluced the metrics, and unique userAgents to show the individual measuremnts within the normalized set, for example the Firefox versions include versions 33.0 and 37.0.

In this limited set, HTMLBars is 122 milliseconds faster, a 14% gain in rendering speed

{
  "durations": [
    696.713,
    903.421,
    660.65,
    734.586
  ],
  "fast": 660.65,
  "geometric_mean": 743.429,
  "measurments": 4,
  "metrics": [
    {
      "date": "2015-02-17T06:04:15.251Z",
      "duration": 696.713,
      "emberVersion": "1.10.0",
      "id": "8b6994ee-268b-43ce-8f26-96ddfcf466a7",
      "pathname": "/metrics"
    },
    {
      "date": "2015-02-17T06:04:06.243Z",
      "duration": 903.421,
      "emberVersion": "1.10.0",
      "id": "28bad254-c3b9-462e-9966-4bc2fcc8fc63",
      "pathname": "/metrics"
    },
    {
      "date": "2015-02-17T06:02:24.487Z",
      "duration": 660.65,
      "emberVersion": "1.10.0",
      "id": "11dfee70-d635-41fd-8e69-2df4f1c70dc1",
      "pathname": "/metrics"
    },
    {
      "date": "2015-02-17T06:02:24.021Z",
      "duration": 734.586,
      "emberVersion": "1.10.0",
      "id": "b58722d9-c9eb-4ab2-bac7-41ba187a3646",
      "pathname": "/metrics"
    }
  ],
  "name": "metrics_table",
  "slow": 903.421,
  "userAgents": [
    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:33.0) Gecko/20100101 Firefox/33.0",
    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Firefox/37.0"
  ],
  "emberVersion": "1.10",
  "platform": "Macintosh",
  "browser": "Firefox"
}

{
  "metric": {
    "durations": [
      746.559,
      1002.809
    ],
    "fast": 746.559,
    "geometric_mean": 865.249,
    "measurments": 2,
    "metrics": [
      {
        "date": "2015-02-17T03:02:27.682Z",
        "duration": 746.559,
        "emberVersion": "1.8.1",
        "id": "d828e5b6-c5c2-4fee-8bf3-2d08d97ed36d",
        "pathname": "/metrics"
      },
      {
        "date": "2015-02-17T03:02:11.844Z",
        "duration": 1002.809,
        "emberVersion": "1.8.1",
        "id": "e65effb9-4756-4642-8397-1757c4f3be15",
        "pathname": "/metrics"
      }
    ],
    "name": "metrics_table",
    "slow": 1002.809,
    "userAgents": [
      "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:33.0) Gecko/20100101 Firefox/33.0",
      "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Firefox/37.0"
    ],
    "emberVersion": "1.8",
    "platform": "Macintosh",
    "browser": "Firefox"
  }
}

Perhaps I'll use the queries and API endpoints for my metrics collection and reporting to see how the next version of Ember.js does, or see how a feature change impacts performance.

EmberConf 2015 - March 4th (day 2)

2015-03-04T00:00:00+00:00

Closing Keynote: Chris Eppstein, 5:30 — 6:00 PM

@chriseppstein, maintenance of @Compass; works at LinkedIn

Storytime, Once upon a time…

Rails Conf in Portland years ago
Sass, had a few patches
Have you heard of SproutCore? It's gonna be hard, frameworks are hard to maintain

Ruby Sass in the JS World

Hasn't been fun
Announcing: "Eyeglass", distribute SASS extension as NPM modules for LibSass (C++ implementation of SASS compiler)
LibSass is much faster than Ruby Sass
Compass is kind of "end of life" at this point, but it's not disappearing right away
Eyeglass, developer preview, is not a bunch of mixins, e.g. autoprefixer; get the extensions in an let you use them in the JS world

Community is You

It's what makes software great
Be excellent to each other, how hard is it just to be nice?
Actually it is hard, "Turn the other cheek." - Jesus H. Christ
"Don't be a Sasshole." - Chris Eppstein
JavaScript community: You're kinda of Jerks to each other
"You are not your OSS contributions" - Don't take it personal
Know when it's time to step away from the keyboard

Conundrum

How to compete without being negative
Attack their weaknesses but ignore their strengths - bad idea.
Respect your competitors
Learn how to disagree and be disagreeable the secret of getting along

Confidence

Is knowing you don't need to engage.

Why is Ember going to Win?

Leadership, Us, backwords compatibility, tooling

What does "Win" Even win?

Find a job you love and you'll never work a day in your life
If you use a framework you love you'll never work a day in your live
Congrats you may have already one
If winning means being #1; the default choice, support is way harder, community? good luck
Being #2 is the sweet spot, people pick you because your are a good fit
The community you create is more awesome if your people fit
Focus on your strengths
LESS kind of collapsed under its own community
Don't stop learning from others but don't view it as a competition
Do what you do because you love it.

Physical Design: Edward Faulkner, 4:45 — 5:15 PM

A talk about UX for the end users of our app, and for us developers.

Abstract - (Almost) infinitely Flexible
Physical - Constrained by Physics

Bring in constraints to our abstract applications the represent our physical world.

Material design, spec - check it out, kick the tires on how it works
- "Without breaking the rules of physics."
- "Motion respects and reinforces the user as the prime mover"

How does this fall into Ember's broader Architecture?

Animations and motion in general, in reaction to the user's input. They live in the gaps in between what was and what becomes.

Liquid-fire

https://github.com/ef4/liquid-fire

Version 1.0 - Coming soon
Showing off some animations in the EmberConf application
Liquid Outlet notices what is inside and manages changes / transitions
A Transitions module defines your animations similar to how the router defines routes
Goal Create extensible animations to share animations as Ember Addons
Liquid Fire organizes how you setup and when you call your animation library, firing off transitions e.g. before, after with the template content already positioned absolutely
Velocity.js is one recommended animation library that Liquid Fire can use to define modular animation and transitions
The animations are just functions you can receive arguments.
Each transition has an old and a new element.
Animation have a forward and reverse path to transition to your before and after states
The explode animation is pretty sweet, and the fly to is great
Tried out re-implementing the fly-to api with Web Animations API, instead of Velocity
liquid-with & liquid-each - helpers for adding before and after elements when your model/properties change
An animation (function) can have many constraints and is triggered when all constraints match

Perhaps checkout: http://miguelcobain.github.io/ember-paper/

Minitalks: Leah Silber, 4:00 — 4:30 PM

Sorry you had to be there :) nice variety of short talks on experimenting with Ember

Building Real-time Applications With Ember: Steve Kinney, 3:00 — 3:30 PM

@stevekinney | [email protected]" target="_blank" rel="noopener noreferrer">[email protected]

How I chose Ember:

Lazy Twitter: Ember.js or Angular
wykatz - Ember.js, Although I'm biased ;)

A Story about Web Sockets, about user sessions, GeoLocation, 3rd party Libraries

What is a Web Socket? RFC 6455, Duh.

Tradition: Request and Response cycle, but the server has to wait for a request, some clients may poll the server.

A Web Socket is a two-way Pipe
Can I actually Use WebSockets? YEAH, except the Opera Mini browser.
Lots of libraries to give you fallbacks to long polling, e.g. Socket.io, Faye

Demo of building a chat app

We need a server, Ok - A Web Socket server in 14 lines of code with Node.js
Ember allows you to build your application and the DOM becomes a representation of your application
ember generate controller websocket to create a controller, setup the socket on init
- Create (un)subscribe handler and a send method
Use needs to utilize the websocket controller
Add an action to respond to user's submitting a message to the chatroom

You share the struggles of making a better app with the community

How to you bring the web socket behaviors and support into a service? search the forums, Oh there's Services, nice.

ember g service websockets then refactor the controller into a service
Instead of extending controller, extend Ember.Object
websocket: Ember.inject.service()
For Lulz bring in Socket.io with libraries on the client and server.
Server app can bind to events socket.on('message')
In the client app subscribe to the messages and broadcast messags

Let's play

http://bit.ly/jspoll | code at: stevekinney/emberconf-chat

Building Custom Apps with Ember Cli: Brittany Storoz, 2:15 — 2:45 Pm

@brittanystoroz

What were our needs? (Firefox OS Requirements)

Generage and validate a manifest file
UI components
publish to the marketplace

The above use cases make for a good use case for using EMBER CLI Addon

Demo: an EMBER CLI application, selecting timezones and local times

Walkthrough creating an Addon to make the app a Firefox OC app

Generate the Manifest (Creating blueprints for this purpose)

ember generate blueprint name-of-module
Generates files an folders, named the blueprint after the name of her app
In the blueprint's directory mimic the file structure of the app, including the manifest
Put some files into the public directory
The blueprint affords using variables to generate application code that ships as your addon
There are hooks to utilize, e.g. postProcessTree, runs at the end of the build process, right before the app is written to the dist directory
You can use that hook to mutate the variables in the blueprint from a config file, e.g. update the name and the version of the application in its manifest file
Not only make the bower package available but also use the package, using the included hook to call app.import()

UI Components

FxOS UI (Gaia): Building Components, a work in progress
bower install gaia-components/gaia-tabs
Setup the components (bower dependencies) and make them available to the consuming application, which needs to know it also requires the dependencies
Use the blueprint's afterInstall hook to add the bower package to the app
In the addon create an Ember.Component (with setup and teardown logic) then tell the consuming app to use that component, so in the app directory import the addon/component-name and export, now the app can use the component, it's registered in the app's container now.
Also add a template for the Component, in the demo a template was needed for the clock and timezone elements in the app

Validation and publishing

Adding commands, need finer controller for when things happen (jobs)
In the lib/commands directory create the command (name, alias, run method)
A command to validate the manifest file, create a command and let the app know that the command can be used
hook includedCommands require and return the imported lib/commands
ember fxos:validate & ember fxos:publish does the custom work needed!
A property of commands is availableOptions as options hash in the method, e.g. pass in a dist target, the production marketplace, sweet
- App created, app ID, you can see it in the marketplace

Interaction Design With Ember 2.0 And Polymer: Bryan Langslet, 1:30 — 2:00 PM

Blur the lines between native and Web to create an immersive experience.

@blangslet shared a reel of integrations between Ember and Polymer, continuous flow in an app, giving users context clarity and focus

Also showing off great demos of using Ember and Polymer together. "Demo with Pirate Music" is awesome!

Demo App on github: blangslet/treasure-hunt
Champions Web Platform nicely running inside native app built with Cordova iOS

Dream Stack

Ember for routing
Polymer layout grid, flexbox
Ember Components + Polymer
Polyfills

Ember going forward

Use tomorrows tech today

Web Components

Extend the browser itself
Encapsultation
Declarative
True reusability and portability

Ember vs Polymer Use Cases

Developer productivity
Conventions and developer happiness
Brilliant community
World class router
Polymer pushing the spec forward

Web Animations API

Best of both CSS and JavaScript animations
Run outside the main thread

The Web Platform

Turmoil in the Web landscape
Never underestimate the underdog, "Cool Runnings"
I'm a huge believer of the Web, everything has to be connected to the Web
Web Performance is on the rise, getting closer to native performance, still a ways to go, but rendering engines are getting faster
A lot of heavy lifting is moving to the client (JavaScript runtime)
Yes Native apps are fast, but what about the best tools available for the job, Web tools are getting awesome!

A Path forward, stand on the shoulders of giants, Ember, Polymer, Web Components, etc.

Ember-Flow

A shift in adding animations and transitions to Ember Apps

Growing Ember One Tomster at a Time: Jamie White, 11:30 - 12:00 PM

Ember London is growing 600 members on meetup.com, 2 events a month

The Tomster wasn't overly done, there are still choices to be make and things you can contribute to.

The code is a snapshot of the best ideas in our community, we're trying to create the best possible home for our idea

Community design and API design are the same.

Roles in the Community

organizer, documenteer, contributor, mentor, student, explorer, critic, etc.
loads of roles inside and outside the community

Community Interface

Is a README enough, How about a website

A consistent visual language build trust in your community, setting expectations across projects

Once an established visual language is set it becomes a tool for contribution, e.g. the redesign of Ember community pages (easier to find a meetup location)

Analogy

Consider promises, thing about other things while you know that asynchronicity is taken care of

Language - words stick

"Stability with out Stagnation" - terse and describes a larger idea

How about reframing the term 'hack night' to 'bring your own project' its a vocabulary that is more open to women and men.

How did a tech community become this vibrant?

design and engineering (the community that is not the software)

The Tomster, an illustration to characterize the project, developer friendliness and productivity

The Ember release cycle is inspired but the Chrome build release cycle but has no characterized illustation, (Is this for me?)

You can affordable commission and license a Tomster for your community!

Doing the right think should be easier than doing the wrong thing

Ambition is not normally aside the concept of Friendliness, yet you can put a Tomster face on Ambition

Aligning Ember with Web Standards: Matthew Beale: 10:45 - 11:15 AM

Ember community survey

201-created.com/ember-community-survey-2015
75% of user are using the latest version of Ember.js

Standards are a two-way street

Strategy for adopting new features of JavaScript

provide legacy wrapper
use syntax as a carrot
private use can start sooner

It's not a straight to adopt pure ES Classes as some concepts still need to be supported, e.g. calling this._super

For example: Decorators

class Car {
   attr('attachThings')
}

Ember's Object Model

Process of change to Ember's primitive for Objects

stable
a good pattern
implemented correctly
implemented performantly

Three new tools…

Classes

Gotchas:

new syntax
super semantics change
mixins
setUnknownProperty
merged /concat
transpiler output?!

This is not the first time we had to move across standards

"Polyfill" - Remy Sharp (inspired by spackle to fill the nail holes in your wall)

Some things can be pollyfill'd and some new spec cannot
Transpile that new ES2015 code with Babel (not born to die)

Standards…

are portable
reflect best practices
endure

Participants win!

Promises and ES6 modules are things the Ember picked up early

Standards Story

WHATWG + W3C
TC39 + Ecma International
In 2008 WHATWG given the task of creating HTML5, realized HTML would never be done
- Moved to a new model… A Living Standard, increments over time
ES3 (used in IE8), then there was an attempt to create ES4 but that failed
- So a few years later and + Web 2.0 they came up with ES5
Then A new giant release for ES6, instead now we have ES2015, moved from a giant hover boat approach to a sailboat, sailing into 2015, then 2016, etc.

Process for JavaScript releases

Strawman
Proposal (polyfills)
Draft (experimental),
Candidate (Compliant)
Finished (Shipping)

Javascript will come out every year! (try it out early Babel as es6ro5)

Fault Tolerant UX: Dan Gebhardt, 10:00 - 10:30 AM

Links

Twitter: @orbitjs
IRC: #orbitjs
github/orbitjs
Soon http://orbitjs.com

Ember Orbit

EO.Store - Synchronous and Asynchronous interfaces
EO.Model - informs Orbit of the Schema
Orbit Sources DRIVE model state
Client-first development
Pluggable Sources
Data synchronization
Editing Isolation, Editing Context
Undo / Redo

Orbit.JS and JSON Patch

Transformable and Requestable interfaces
Synchronous Event Handling - Promise aware (async blocking, sources opt-in)
Non-Promise aware (non-blocking, sources opt-out of promise)
Connect events between Sources
Memory, Local Storage, JSON API, + More +
Orbit will be JSON API compliant, v 1.0 of JSON API tomorrow

Engineering Fault Tolerance

Ember provides Simple Elegant Patterns for building a Consistent UX
Ember Data: Consistent + Durability
ACID is hard: Atomic consistent Isolated Durable
Rethink Assumptions and Primitives
Disparate Sources
Disparate Data
Common Interfaces
Normalized Data
Evented Connections

Applications should try to Provide a forgiving UX, Please :)

Persist transient data, while still being edited, e.g. editing a comment in a code review
Undo and Redo, oops didn't mean to do that, e.g. Gmail can undo
Provide offline support, applications which are editing data in isolation, no immediate response from server is required, so your user should not be blocked from editing.
Asynchronous non-blocking interface, not blocked by request/response cycles from the server.

Applications MUST NOT Violate the Rules of Transactional UX, OR ELSE

Don't break your users' trust

Shield our users from environmental stresses that our application encounters

A transactional user experience, like a database has to reliable in committing data: ATOMIC
Atomic means "all or nothing"
A transaction should be consistent, it should move across all states - partials should not be come inconsistent
Transaction should be isolated and allow concurrent changes
Submit and cancel should just work, the change is isolated from the rest of the application, the change is done in isolation, separate from the canonical represtation

Fast forward to today

We're building complex systems and launching them into users browsers
Our Ember Apps allow users to navigate quickly and efficiently
Fault Tolerance in our environment can become stressfull - Browser wackiness
Plus some very optimistic users

Day tells the story around the beginning of his career working on ships.

Regulatory organizations must certify a ship, its controls and operational stability, etc.
Left that work for working on the internet in the 90s
Serious engineering and fault tolerance was expected on the server side
But the client side was much less serious.

EmberConf 2015 - March 3rd (day 1)

2015-03-03T00:00:00+00:00

Test-Driven Development by Example: Toran Billups, 5:30 - 6:00 PM

Maybe there are other people at the conference who build Web apps like I do, this is for you - Pro Tips about TDD…

Your tests should still pass between design iterations!

Let's build a Kanban board, TDD style

Live coding building a mini app from scratch using Ember CLI, and using test-driven development.

Using an ember-cli app, start by generating an acceptance test, assignment
visiting /assignment use ember test --server start with failing test 3 unassigned items
Define a route 'todos'
Red -> Green -> Refactor; it's OK to keep using Red for immediate feedback
Add a "todos" controller with the ember generator
Create the unassigned property, return an array with 3 items in it
Test result is green
In the acceptance test add a specific assertion for a seletector you'll use in your template
Add some sample data in the controller, 3 objects each with a projects property
Oops the tests were dependent on the HTML markup, instead remove any specific assertions about the layout (elements), use classes instead
Add the assigned property to the controller to iterate on the acceptance tests
Fixup the template to include the property that was in the test/assertion
Add a new property to the model object for the status
Rip out the mock model objects from the controller and paste into the Route's model hook
Add the status property to the template
Acceptance testing is great to show the happy path flow from your route to controller
Time to break out of acceptance testing and into unit testing so explore the transition between a status of 'unassigned' to 'assigned'
Unit test run in isolation, you can run just one test, ember test --filter='todo'
Create a Todo model and a computed property for status, match up the lingo your template to a boolean property of the status_code
Every piece of test code is code you maintain, it is ok to delete a test, if another test already tests the same behavior
Write another acceptance test for toggling the status from unassigned to assigned
Test code documents your app, so it's a good idea to tell the before and after story
- Create some assertions for the state before (in the arrangement) you act, then assert.
Figure out how to mock the XHR and move out the hardcoded model from the route's model hook
In the route hook add the code to make the XHR request
Mock the XHR and in your test simulate the response
Add a new acceptance test to show the details for an item, visit, click, andThen
Add a link-to helper in the template for the details, give it a class that your test can use for a selector
Add a nested route for /todo/:todo_id
Oops the test breaks, the data set needs an ID property
Assume that the details info is hidden, so update the test so assert that the content is hidden
When the URL is toggled then the details content hides or shows
Check the current route name to see what the URL is represented by (in your test)
Go back to the template and add an outlet

Dynamic Graphic Composition in Ember: Chris Henn, 4:45 - 5:15 PM

When is the Grammer of Graphics appropriate?

You decide how much of this abstraction you would like to apply
General purpose plotting library vs. App with one visualization

Considerations

Interactivity?
Animations and Transitions
- The how point of the visualization is to convey data, use transitions (D3)

Breaking graphic down into parts allows you to add simple snippets of interactivity or transitions.

What does this look like in Ember

Data to Aesthetic mappings
Scales: a constructor / function ( including its inverse)
- in Ember can use a computed property (macro)
Layers: each layer as a separate component
- Generalizable, like playing with Legos
Geometries: SVG

How to we split a statistical graphic into parts?

Faceting: How to compose data visualizations
A coordinate system, e.g. plots, circular plane
Layers: Geometry / Stat / Optional Data to Aesthetic mapping
Representing the mappings as points, the Geometry
For every data to aesthetic mapping there is a scale, a mapping function
A Simple scatter plot with 3 mappings (data to aesthetic mapping)
Grammer of Graphics, Hadley Wickham
Need: a flexible system
Adding a block param layer and adding multiple layers
Do heavier cars get worse mileage? (DEMO - scatterplot)
- Graph: Horizontal:weight / Vertical:mileage
Encourages custom visualizations
Suggests the aspects of a plot that are possible to change
Lets change one feature of the graphic at a time
Tackle it with composition

Use Ember to take advantage of visualizations

http://chrishenn.net | Twitter: @cwhnn | github: chnn/composing-graphics

Bring Sanity to Frontend Infrastructure with Ember: Sam Selikoff, 4:00 - 4:30 PM

(latest updates flow in at the top)

Develop successful solutions for solid primitives is found in iteration and innovation

Give developers the tools to tinker
Deliberately fold in shared solutions
Innovate and Share!

Acme was right to start with a monolith, but over time they would identify the right abstractions and solutions for their framework and tooling.

Ember CLI - future freshness baked in

The Ember community is relentless about finding and promoting best practices as they emerge as standards
Trust: new standards and best practices from the Web community will eventually land in the APIs found in Ember CLI
Overall architecture is more flexible so sub-sets of the system can be swapped out
semver + CLI conventions

Process

Identify Redundancies and Abstractions

It's important to have a process around discovering the right abstractions

Testing

ember generate factory
Addon for data concerns, e.g. http mocks; more consistency in the ecosystem
More similarities emerged, mocking data, proxies
ember test provides a test harness that is common

Solutions Ember CLI brought for deployment concerns

manual
shared script
deploy addon
deploy server

Deployments

ember-deploy was all they needed to ship applications to production, various components were created as addons (pluggable)
Push an index.html and JS/CSS, backend can work with that consistency
Wrote a script for CI (continuous integration)
Conventions for building clarified how to distribute the application

Ember and Ember CLI

Ember brings in solid conventions for frontend application development
Command line tools: ember new, build, generate
Reduce boilerplate, eliminate trivial differences that hold us back

A story about the growth of a codebase, from monolith to various services, data layers and frontend interfaces (UI)

One day the frontend teams adopted Ember CLI and immediately had common solutions
Frontends interfaces each had resulting choices/adoptions with variations and incompatibilities
Every time they needed a new interface the programs had to make a lot of decisions about libraries, architecture, build pipeline, testing solutions and delivery systems
The Frontend didn't just split up and scale
Backend systems grew and spawned independent services, smaller and focused; developer were productive and happy

Ambitious UX for Ambitious Apps: Lauren Tan, 3:00 - 3:30 PM

Good Design is Reactive, Playful, Informative and Intuitive…

Design is not how it looks and feels its about how it works

Slides

Drag and Drop

Ember.js and HTML5 Drag and Drop

Design of a Messaging Service

ember-cli-flash
Ember Flash Message Demo ember-cli-flash
Can use a lifecycle for a message instance using .destroy()
Ember.Object for the message model - can have methods for the supported macros
Messages can be wrapped in a component and queued in a service object for application notifications
Flash messages or growl messages
Visibility of system status, Jacob Nielsen

Using Services

demo of inserting a clever shower thought in to a loading message
Inject macro that is not cached and randomized

Think about good UX

If your shirt isn't tucked into your pants then your pants are tucked into your shirt
Reddit - shower thoughts
Clever loading messages

FRP in Ember

Observers invoked when dependent properties change
Ember.computed.X see the api docs
Computed properties and Observers, write macros too
Bacon.js - FRP, but Ember is different - the observer pattern
Functional Reactive Programming (FRP) - event streams and properties
- A sequence (stream) of events and properties, consider the mouse movements, and it's properties for it's physical position on the screen

What is Good Design

Ember enables reactivity via observers
Reative programming: continous flow of data and maintaining the relationships between the data
It's reactive

Design is how it works

It doesn't matter what we think as developers, we need to consider what our users think. Design is really important
Give clear answers to your users, don't mess with their experience
But I'm not a designer

About Lauren

Lauren - Designer and Front end developer at Homely ( in Austalia ) @sugarpirate

The Art of Ember Deployment: Luke Melia, 1:25 - 2:45 PM

Awesome new story for deploying an Ember application: ember-cli/ember-cli-deploy

Real Artist Deploy

We still need some collaberation

Let's talk… how will this work with FastBoot?
What is the relationship between the FastBoot server and your application server

Roadmap for ember-cli-deploy

After initial release
- deploy to named buckets, deploy config instead of HTML, e.g. manifest from static build, let server drive what is sent to the client
Usage: builds, deploys assets, can rollback, deploy targets, e.g. staging, give you a preview URL
- Activate using an identifier after testing on live
ember-cli-deploy plugins should use one or more of the hooks, willDeploy, build, updateAssets, updateIndex, activate, didDeploy, list
New pipeline, hooks and plugins architecture, similar to Ember Addons
- e.g. Post deploy hooks
Documentation for plugin developers
Release the end of this week
Update existing plugins

Pluggable deployment solutions

Paving the cow paths…
Merged the 3 projects, one awesome project ember-cli/ember-cli-deploy with a team of six maintainers
ember-deploy has the biggest eco-system
projects: ember-deploy, ember-cli-deploy, front-end-builds, etc

New Possibilities when deploying a JS App independently from server apps

Notifying connected clients, hey user - it's time to refresh
How about serving various version of an app simultaneously
Dynamic HTML Rewriting, e.g. a Rails controller
- CSRF tokens, dynamic analytics, A/B testing, feature flags
Add a new level of confidence by going live once the app is tested on production
Preview the new version of the application

Modern Flow for deploying Web apps…

How about Redis, deploy the HTML (index page for a single page app) into Redis, Rails server reading out of Redis and assets deployed to S3
Do we deploy the built JS app to S3, but S3 reads can be slow, need speed
Deploying JS apps should be decoupled from server application deployments and restarts, basically UI deploys independently from backend
Caching should be minimal to none, so new users get the latest versions
HTML apps need fingerprinted assets for JS/CSS, specific config data for that current version of the app
For connected clients consuming a changing API they need the previous version running. Can we do the same for our Ember Apps?
During deployment need two apps running concurrently, how about versioning API and client app together? (its a fallacy)
Long-lived session and API changes
- in the deployment cycle users may get an incorrect data representation
Keep static assets working during rolling restarts
- deploy old assets to a CDN and keep for awhile

Looking back at how we deployed software

We no longer deploy individual files to the Web, Fetch app
We no longer use CD ROM duplicators to deploy web software
So how do we deliver software to the Web?
Then came the internet
Managing software over time… cassettes, cartridges, etc.
Luke organizes NYC Ember meetup and runs @YappLabs.

Hijacking Hacker News with Ember.js: Godfrey Chan, 1:30 - 2:00 PM

if @chancancode so can you…

New project (joke) CocoaBars, has 0 commits so get to work :)

Chrome Extension: https://chrome.google.com/webstore/detail/hn-reader/emgghjnnkkopedbjfajejpkidaiedhlf

The power of the Adapter pattern in Ember allows you to customize your data mapping needs. You get small libraries to build your custom solutions on top of. Even if the frameworks opinions don't fit your needs the Adapter pattern opens up limitless possibility.

Adapter Patterns

Used Ember.Observable get, set, addObserver to wrap localStorage API
use localStorage API to back data in the extension routes
Ember.History (Location API in the router) has getURL and formatURL hooks
Extension needed 100% URL compatibility with Hacker News website
Router API has flexibility on how you name your outlets
Ran into a problem with URL's as Ember Data is opinionated about how to construct URLs
Adapter is responsible for talking to server, and Serializer is responsible for transforming data
Drop in an Adapter to talk to your local store needs in an extension even though the adapter is not talking to an API
JSON API / Ember Data work together well, but what about a custom data source?
Today Ember Data is a local object store so can use an Adapter the way you choose
Now that we can get JSON data on the HN domain, can we store locally?
Extension is running on the HN domain so no need to cross-domain or API calls, just XHR /get
In the case of a chrome plugin app there is not necessarily a backend, fetching HTML and parsing from the Hacker news server in json

Demo of HN Reader App

hn-reader
Submitting extension to Hacker News in real-time
Chrome extension to hack the Hacker News website

Canadian Programmers

Had some fun and laughs talking about Canadians talking to Americans…

gem install canada
isEmpty.eh()?

Designing for Ember Apps: Steve Trevathan, 11:30 - 12:00 PM

Coming soon… Tools of the Trade - a free design pattern library - http://toolsofthetrade.dockyard.com

Create Repeatable Design Methods & Patterns

Offline Mode - "Goliath mode"
- When a lost connection is restored then make doable updates (patches)
- Responding Optimistically
- Connection lost, but you can still use the app
- Disallow editing? NO!
Micro > Macro - Core interactions become a symbol of your app
- iPhone thumbprint scanner, standard authorization step, repeated
- The game "THREES" has one way to interact with the app
Reuse Core interactions, e.g. card formats with common interfaces
Carry Context - don't leave me waiting at the bus stop
- Can be a major save, imagine an online trade (investment) and your computer fails, so you pick up your phone and complete the transaction
Skeleton UI - thinning out the spinners (e.g. gridlines where a map is loading tiles)
- Draw an empty card format then fill in the details
Gradual engagement - reducing the perceived risk

Mental Models: Use them explicitly and break them when you must

Remember the original iPod interface, a micro interaction on the wheel

Digital Experiences

Borrowing metal models is different that copying an application
Build a framework for understanding some applications have a difficult learning path
Take from existing models and meet expectations, both macro and micro, e.g. chat apps have been around for a while
The past: Razor phone, Instant Messanger app, chat app

Micro Models

How I think it works

Mental Models:

Can challenge or reinterpret incorrectly, be careful about pushing the limits of UX/design
What is "home" ? - Match peoples idea of what a home is and what you are building
Can be changed / updated
Influenced by experiences from my past

How to we stop our users from spitting all over us? we don't marry them, but we do try to understand their mental models.

I'll be your "pain in the ass user" - I'm gonna hate the front door you build me

Metaphor We're designing a house - as we build an application with Ember. We're dealing with a large perhaps infinite number of use cases.

… loading presentation …

Ember.js Performance: Stefan Penner, 10:45 - 11:15 AM

Mis-alignments to fix…

Combine approaches
Benchmarks can trick you
Premature optimization is not a good idea
Ember.Object.reopen - slowly augment objects; solution: limit reopen to only work until the constructor has it's first instance
- actionsFor, need to optimize the instances for meta - listeners (subscription)
- Meta is 'live' inheriting - this is a problem
- Meta, every class and every instance has a meta, it's the meta for the instances that kill performance
init/super - need to embrace super
- pass in args to init(args), this._super(args); use arg.prop || 'default';
Actions Up, bindings down
improved clarity makes the app faster

About the runtime and your code

Reasonable code should have reasonable cost
Allocation === cost, closures, unoptimized code allocates more objects
If the runtime believes the code is stable and predictable then it can optimize speed
Mad Science: Types + Stabiltiy
Need to understand the runtime, e.g. V8 or others
- E.g. specialize type, specialized compiler methods - efficient native code
"Mechanical Sympathy" - Jackie Stewart, align the car with the driver
"Only a sith uses abosolutes" - what are the performance questions that need to be answered?
Guided evolution
- We have some choices to make.. productive for developers vs performance
Why? we confuse ourselves and the runtime, we should understand the runtime
We still have work to do, the ceiling is still high
Bluebird, Promises made faster
- Done without external API change or breakage
- Did less work, allocate less objects, align with the underlining primitive
- Promises using normal for loops is fast

Myth? performance is about enumerating arrays

Opening Keynote: Yehuda Katz & Tom Dale, 9:45 - 10:30 AM

Your Antidote to Hype Fatigue

Introduction

625+ people in attendance and about 24 countries represented.
Ember is really growing this year, new apps built in Ember… Ghost, Beatport, Intercom.io, Customer.io, The Nest Store and more
The number of meetups has grown around the world
Special guest in the house an a Tomster mascott
Epic meetup video showing with a super long intro. <3
The core team is represented my many companies, 3 new people added today… Martin, Mixonic, & Edward

Report Card

Last year we made lots of big promises, and guest what we shipped them.

Early adopter of ES6 (ES2015) features… plan to be an early adopter of ES2016
Ember Data
- Adapter Ecosystem
- Relationships are always Async, build with async loading in mind
- Data can come at any time and people really expect that data relationships are updated
- On client get relationships on demand
- Relationship Syncing, easy on the server not easy on the client (browser)
- SSOT branch landed
ES6 Modules, drive making the spec awesome but early adoption, helps out TC-39
Testing
- At the end of 2014 and into 2015 has an awesome testing story
- Out of the box with Ember CLI, functional and unit with great async support
Ember CLI
- Add whatever test harness you like
- Scaffold new app instantly, and use various tooling to your liking, e.g. Coffeescript
- Ember Addons - 663+ and growing, a single install command
- testing, performance, stubbing, server proxy, content security policy, transpile with Babel, source maps,
Ember Inspector
- Thanks Teddy Zeenny
- Firefox support, nav bar, bookmarklet
- Performance pane
- Promises pain has decreased
- Ember Data pain has decreased
RIP script tags as metamorphs
HTMLBars: At compile time your templates are validated and error feedback is reported; full compliant HTML parser
<calendar-day> can remove {{…}} mustache syntax; TLDR - rebuild the render engine
Context of blocks, component scope… use block parameters today
HTMLBars <a href={{url}}>
Rapid Release has worked really great, please run the beta release channel and report bugs
- Robert Jackson http://getrwjblueabeer.com
- RFC process, a couple dozen submitted

Ember FastBoot

Bend the load time curve and front load the HTML
Can curl a Ember.js app, fastboot can be installed as middleware in an Express app
Ember is running as expected, but on the server
Lynx user now can user your Ember Apps, JavaScript disabled in the browser
Live demo of FastBoot, woot! "Musing of a Thoughtleader"
Boot up your app in a node process, hit the API server and render, just running on a different computer, not the browser
Run your app on the server and extract, abandon progressive enhancement

Performance

Ember release 1.13 will include Glimmer and will be compatible with your current apps
Is Ember Fast Yet? http://is-ember-fast-yet.firebaseapp.com
Glimmer, the new rendering engine built with HTMLBars
Confirm Ryan Floreance's complaint, stress test
Alternative Approach to Virtual DOM
- Dirty checking for dynamic properties in the declarative syntax, we can know what parts will be changing
- Only check for diff sets in the the changing pieces of the template
- Handlebars, render the template, emit the DOM; while rendering track all the dynamic content (curlies {{…}})
Virtual DOM
- Batch changes, since DOM is the bottleneck, smart refreshes
- Manages rendering only the change sets, done in memory
Render Virtual DOM and compare the DOM, diff then draw (ReactJS)
You can do a lot in JavaScript and less in DOM
Never say no to a feature, giving a reason of performance is not there

What's next in 2016

Ember FastBoot
Release Dates, beta candidates
- ListView June 12th
- Ember Data 1.0 is June 12th
- Ember Inspector is June 12th
- Ember 2.0 release is June 12th
- concrete dates
Ember Data
- Ship It! we need a 1.0
- Pagination & Filtering need first class support in JSON API transport
- JSON API out of the box
- JSON API designed from the ground up for what Ember Data needs
- [json:api] spec, Steve K and Dan G. working hard on the spec
Ember 2.0, the release plan is the Feature, rolling out in 1x release and under way
- Keep up the rapid release pace, notify of deprecations often, remove on major releases
Async & Routable Components
Liquid Fire @ef4 working closely so that HTMLBars is compatible
<angle-bracket> Components, already in Canary
ListView (emberjs/list-view on github)
RFC: Engines, encapsulate application code for larger teams
Next Version: Ember CLI included in the guides
Versioned guides, live today, http://guides.emberjs.com

A Bet on Web Components and Ember.Component Synchronicity

2015-03-02T00:00:00+00:00

This article is a brief overview of both Web Components and Ember Components as well as a comparison of the two. You will see examples of blurring the lines between native Web Components and Ember components. Bits and pieces from the various specification(s), documentation sites and tutorials are highlighted (copied straightaway, follow links to see the full details). The HTMLRocks tutorials were borrowed (copied) from heavily.
With the Ember 2.X Evolution under way, you will have a new generation of first class citizens for your DOM, Ember.Components. Perhaps this overview will help you to design your Ember Components with future standards in mind, learn how to use native Web Components in synchronicity with Ember Components, and learn how to upgrade a native Web Component to an Ember.Component.

An Ember.Component

An Ember.Component is a view that is completely isolated.

Property access in its templates go to the view object
Actions are targeted at the view object
No access to the surrounding context or outer controller
All contextual information must be passed into the component

Commonly Used Properties, Methods & Events…

tagName, layoutName, willInsertElement, didInsertElement, actions, sendAction, targetObject, willDestroyElement, $, on, off

A Web Component

A Draft of Specifications:

Template (HTML5)
HTMLImport (Working Draft)
Custom Element (Editor's Draft)
Shadow DOM (Editor's Draft)

Template

The Template element is used to declare fragments of HTML that can be cloned and inserted in the document by script.

When web pages dynamically alter the contents of their documents, they may require fragments of HTML which may require further modification before use, e.g the insertion of values appropriate for the usage context.

template.content Returns the template contents, which are stored in a DocumentFragment associated with a different Document (to avoid the template contents interfering with the main Document).

The template element doesn't provide data binding. <template> provides an ability to insert 'inert HTML tags' into a document, using inert HTML tags.

Inlined scripts won't be executed without being stamped out
Resources such as <img> or <video> won't be fetched without being stamped out

To define a template, simply wrap your content with a <template> tag.

In order to stamp out the <template>, you'll need to write a bit of JavaScript.

^{Some content in the summaries above were taken directly from the W3C docs and the HTMLRocks Tutorials}

More info

HTMLImport

HTML Imports are a way to include and reuse HTML documents in other HTML documents.

Imports are HTML docs, linked as external resources, from another HTML doc. The document that links to an import is called an import referrer. An import has an import referrer ancestor as its import referrer.

An import referrer which has its own browsing context is called a master document. Each import is associated with one master document.

The URL of an import is called the import location. In the import referrer, an import is represented as a Document, called the imported document. The imported documents don't have browsing context.

The set of all imports associated with the master document forms an import map of the master document. The maps stores imports as its items with their import locations as keys.

^{Most of the content in the summaries above were copied directly from the W3C docs and the HTMLRocks Tutorials}

Mozilla won't ship HTML Imports

Custom Element

Custom Elements provides a way for Web developers to build their own, fully-featured DOM elements.

It's possible to create DOM elements with any tag names in HTML, but these elements aren't very functional. Custom elements inform the parser how to properly construct an element & to react to lifecycle changes.

Rationalize the platform. The spec ensures that all of its new features & abilities are in concert with how the relevant bits of the Web platform work today

Lifecycle: Types of Callbacks

createdCallback - invoked after custom element instance is created and its definition is registered
attachedCallback - whenever custom element is inserted into a document
detachedCallback - whenever custom element is removed from the documen
attributeChangedCallback - whenever custom element's attribute is added, changed or removed.

^{Most of the content in the summaries above were copied directly from the W3C docs and the HTMLRocks Tutorials}

Shadow DOM

"A particularly pernicious aspect of the lack of encapsulation is that if you upgrade the library and the internal details of the widget’s DOM changes, your styles and scripts might break in unpredictable ways." -HTMLRocks tutorial

Shadow DOM addresses the DOM tree encapsulation problem.

Elements can get a new kind of node associated with them, a shadow root. An element with a shadow root is a shadow host. The content of a shadow host isn’t rendered; the content of the shadow root is rendered instead.

With Shadow DOM, all markup and CSS are scoped to the host element. CSS styles defined inside a Shadow Root won't affect its parent document, CSS styles defined outside the Shadow Root won't affect the main page.

^{Most of the content in the summaries above were copied directly from the W3C docs and the HTMLRocks Tutorials}

Tutorials

Compare & Contrast…

How do the two components line up? Can they work together? What are the differences?

Ember.Component

Scope is isolated, only knows the context passed in. Compared with a view that knows the scope of the current controller. Body of component (between the opening and closing tags) is in the same scope of the template it belongs too.
No encapsulation of styles, best to use a custom element and define a base style for the component.
You can use in an Ember App today, in any modern browser.
Specification - only works with Ember.js
Can use a 'layout' (template); compile with your build pipeline, e.g. ember-cli
Built-in data-binding (using Ember)
Lifecycle callbacks (Events): didInsertElement, parentViewDidChange, willClearRender, willDestroyElement, willInsertElement
Create components that extend from other components
Bundle custom functionality into a single component
Use a custom tagName (custom element)
How do you distribute components, the Ember CLI 'addons' story is still in its infancy but becoming more attractive

Web Component: Custom Element

caniuse Custom Element
Feature detecting is a matter of checking if document.registerElement() exists
The most important API primitive under the Web Components umbrella
Define new HTML/DOM elements
Create elements that extend from other elements
Logically bundle together custom functionality into a single tag
Extend the API of existing DOM elements

var XFoo = document.registerElement('x-foo', {
  prototype: Object.create(HTMLElement.prototype, {
    bar: {
      get: function() { return 5; }
    },
    foo: {
      value: function() {
        alert('foo() called');
      }
    }
  })
});

Lifecycle callback methods:

createdCallback an instance of the element is created
attachedCallback an instance was inserted into the document
detachedCallback an instance was removed from the document
attributeChangedCallback(attrName, oldVal, newVal) an attribute was added, removed, or updated

Web Component: Shadow DOM

caniuse Shadow DOM
Shadow DOM is 'really' completely isolated, both in scope (context) and style.
The shadow root has it's own stylesheet.
There is a way with CSS to define styles outside of the component using ::shadow pseudo-element.
By 'really' isolated we mean there is only a couple backdoors e.g. ::shadow or /deep/ using CSS or JavaScript (querySelector)
You can use only in Chrome
Specification is a work in progress

For example, if an element is hosting a shadow root, you can write #host::shadow span {} to style all of the spans within its shadow tree.

(Code samples borrowed from HTMLRocks tutorials)

<style>
  #host::shadow span { color: red; }
</style>
<div id="host"><span>Light DOM</span></div>
<script>
  var host = document.querySelector('div');
  var root = host.createShadowRoot();
  root.innerHTML = '<span>Shadow DOM</span>' + 
                   '<content></content>';
</script>

Using JavaScript can the shadow tree be accessed? Yes, with the power comes the responsibility to respect encapsulation.

document.querySelector('x-tabs::shadow x-panel::shadow #foo');

Do the ::shadow pseudo-element and /deep/ combinator defeat the purpose of style encapsulation? Shadow DOM prevents accidental styling from outsiders but never promises to be a bullet proof vest.

Developers should be allowed to intentionally style inner parts of your Shadow tree...if they know what they're doing. Having more control is also good for flexibility, theming, and the re-usability of your elements.

^{Some of the content above was copied directly from the W3C docs and the HTMLRocks Tutorials}

Web Component: HTMLImport

caniuse HTML Import
To detect support, check if .import exists on the element 'import' in document.createElement('link')
How many imports to you want to link to in the head of a document.
Perhaps you still need a build pipeline to minimize http requests
An import is just a document. The content of an import is called an import document $('link[rel="import"]')[0].import;
Script in the import is executed in the context of the window that contains the importing document
Imports do not block parsing of the main page
The HTML Template element is a natural fit for HTML Imports
An ideal way to distribute Web Components

Web Component: Template Element

caniuse Template
Looks good to go in modern browsers (not Internet Explorer)
No built-in data-bindings, use Object.observe
caniuse Object.observe
Feature detect <template>, create the DOM element and check that the .content property exists - 'content' in document.createElement('template')
Content is effectively inert until activated
Content within a template won't have side effects
Content is considered not to be in the document
The .content property is a read-only DocumentFragment containing the guts of the template
Create a deep copy of its .content using document.importNode()

var t = document.querySelector('#mytemplate');
// Populate the src at runtime.
t.content.querySelector('img').src = 'logo.png';

var clone = document.importNode(t.content, true);
document.body.appendChild(clone);

Blurring the lines between Web Components and Ember.Component

Below are a few code samples showing how to use the tagName of your Ember component that is based on a Custom Element (Web Component).

See the jsbin and github repos for demo links to inspect and see the code in action. Checkout the shadow root in your developer tools to see the shadow root of the Web components.

Upgrade a native Custom Element into a Web Component

See jayphelps jsbin (code samples below copied from this jsbin)

<script type="text/x-handlebars">
  {{input value=value}}
  <x-ember class="blue"></x-ember>
  <x-native foo={{value}} class="red">
    {{value}}
  </x-native>
</script>

<script type="text/x-handlebars" data-template-name="components/x-ember">
  I am an ember component
</script>

Setup component generation...

window.EmberENV = {
  FEATURES: {
    'ember-htmlbars-component-generation': true
  }
};

Create a native Web Component...

// Native Web Component
function XNativeElement() {}

XNativeElement.prototype = Object.create(HTMLElement.prototype);

document.registerElement('x-native', XNativeElement);

// Upgraded to an Ember Component using `x-native` element
App.XNativeComponent = Ember.Component.extend({
  tagName: 'x-native',
  attributeBindings: ['foo']
});

Upgrading a Web Component to an Ember.Component

alert-box-web-components - see examples/app.html

I found that in Chrome, which supports Web Components, I can use a Custom Element as the tagName for an Ember Component. I reap the benefit from the behaviors provided by the native Web Component and the bindings provided by an Ember Component.

Alert Box Web Components Demos

These three demos show examples of using only Web Components, upgrading a Web Component to an Ember Component, and converting the Web Component to an Ember Component.

pixelhandler/alert-box-web-components - Repository for a native Web Component
Web Component only - Example of the native Web Component in action
Ember.js app using (native) Web Component - Upgraded Web Component to an Ember Component
As an Ember.Component only - Borrowed styles and behavior from the Web Component but only done in Ember

Alert Box Web Component Code:

<!--
  Web Component: Alert Box
-->
<template id="alert-box">
  <style>
    html {
      box-sizing: border-box;
    }
    *, *:before, *:after {
      box-sizing: inherit;
    }

    /* alert-box */
    :host {
      display: none;
      width: 400px;
      margin: 15px 0;
    }
    :host(.ready) {
      display: block;
    }

    section {
      background-color: #337ab7;
    }
    :host(.red) section,
    :host([type="danger"]) section,
    :host([type="fail"]) section {
      background-color: #D9534F;
    }
    :host(.orange) section,
    :host([type="warning"]) section {
      background-color: #F0AD4E;
    }
    :host(.green) section,
    :host([type="success"]) section {
      background-color: #5CB85C;
    }
    :host(.blue) section,
    :host([type="info"]) section {
      background-color: #337ab7;
    }

    main {
      color: #fff;
      background-color: transparent;
      font-family: 'Fira Sans', sans-serif;
      overflow: visible;
      display: flex;
      flex-flow: row;
      height: 60px;
    }
    section {
      border-radius: 4px;
      margin-right: 2px;
      padding: 0;
      display: flex;
      justify-content: space-around;
      align-items: center;
      flex-flow: row;
    }
    section.notice {
      flex: 10.5 10%;
    }
    section.action {
      flex: 1 10%;
    }
    section.action:hover {
      cursor: pointer;
    }
    aside {
      flex: 1 10%;
      padding: 6px 0 0 0;
    }
    article {
      flex: 9 10%;
    }
    div {
      flex: 1 auto;
      align-self: center;
      text-align: center;
      padding: 6px 0 0 0;
    }
    div .close {
      text-align: center;
    }
  </style>
  <main class="alert-box">
    <section class="notice">
      <aside>
        <content select=".icon"></content>
      </aside>
      <article>
        <content select=".message"></content>
      </article>
    </section>
    <section class="action">
      <div>
        <content select=".close"></content>
      </div>
    </section>
  </main>
</template>
<script type="text/javascript" charset="utf-8">
  document.addEventListener('DOMContentLoaded', function () {
    'use-strict';

    window.AlertBoxElement = document.registerElement('alert-box', {
      prototype: Object.create(HTMLElement.prototype, {
        createdCallback: {
          value: function () {
            this.addEventListener('click', this.clickHandler);
          }
        },
        attachedCallback: {
          value: function () {
            if (this.innerHTML !== '') {
              var template = document.getElementById('alert-box');
              var clone = document.importNode(template.content, true);
              this.createShadowRoot().appendChild(clone);
            }
            this.classList.add('ready');
          }
        },
        detachedCallback: {
          value: function () {
            this.removeEventListener('click', this.clickHandler);
          }
        },
        clickHandler: {
          value: function (evt) {
            evt = new CustomEvent('alert-box-click', evt);
            this.dispatchEvent(evt);
            this.parentNode.removeChild(this);
          }
        }
      })
    });
  });
</script>
<!--
  Web Component: Icon Info
-->
<template id="info-icon">
  <svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
    viewBox="0 0 100 100" enable-background="new 0 0 100 100" xml:space="preserve">
    <g>
      <path fill="#FFFFFF" d="M51.833,39.464c0,0.919-0.68,1.68-1.76,1.68c-1.04,0-1.72-0.76-1.72-1.68c0-0.92,0.68-1.68,1.72-1.68
        C51.153,37.785,51.833,38.544,51.833,39.464z M48.954,67.899V46.983h2.32v20.917H48.954z"/>
    </g>
    <circle fill="none" stroke="#FFFFFF" stroke-width="2" stroke-miterlimit="10" cx="49.95" cy="50.198" r="29.416"/>
  </svg>
</template>
<script type="text/javascript" charset="utf-8">
  document.addEventListener('DOMContentLoaded', function () {
    'use-strict';

    window.IconInfoElement = document.registerElement('icon-info', {
      prototype: Object.create(HTMLElement.prototype, {
        attachedCallback: {
          value: function () {
            var template = document.getElementById('info-icon');
            var clone = document.importNode(template.content, true);
            this.createShadowRoot().appendChild(clone);
          }
        },
      })
    });
  });
</script>
<!--
  Web Component: Icon X
-->
<template id="icon-x">
  <svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
    viewBox="0 0 100 100" enable-background="new 0 0 100 100" xml:space="preserve">
    <g>
      <path fill="#FFFFFF" d="M61.059,64.036L49.884,49.837L39.005,64.036h-3.058l12.35-15.459L37.182,35.303h3.176l9.585,11.972
        l9.467-11.972h3.059L51.59,48.451l12.643,15.585H61.059z"/>
    </g>
  </svg>
</template>
<script type="text/javascript" charset="utf-8">
  document.addEventListener('DOMContentLoaded', function () {
    'use-strict';

    window.IconXElement = document.registerElement('icon-x', {
      prototype: Object.create(HTMLElement.prototype, {
        attachedCallback: {
          value: function () {
            var template = document.getElementById('icon-x');
            var clone = document.importNode(template.content, true);
            this.createShadowRoot().appendChild(clone);
          }
        },
      })
    });
  });
</script>

Upgraded Web Component to an Ember.Component...

<!--
  Upgraded Web Component (to an Ember.Component) used within a template...
  Ember Components utilizing native `<alert-box>` Web Component.
-->
<script type="text/x-handlebars" data-template-name="components/countdown-info">
  <p class="message">Info Alert Box, Countdown is Over.</p>
  <icon-info class="icon"></icon-info>
  <icon-x class="close"></icon-x>
</script>

Ember.Component template for content of native template...

<script type="text/x-handlebars" data-template-name="components/countdown-warning">
  <p class="message">
    Warning Alert Box w/ Countdown:<br>
    <span class="minutes">{{minutes}}</span> minutes 
    <span class="seconds">{{seconds}}</span> seconds.
  </p>
  <icon-warning class="icon"></icon-warning>
  <icon-x class="close"></icon-x>
</script>

Ember.Component upgrade from Web Component...

// AlertBoxComponents and components that extend it upgrade
// a native Web Component `<alert-box>`

// NOTE: without alert-box being defined in ember...
// The feature for `ember-htmlbars-component-generation: true`
// would bug out on `<alert-box>` used in a template
App.AlertBoxComponent = Ember.Component.extend({
  tagName: 'alert-box',
  attributeBindings: ['type'],
  type: 'info'
});

App.CountdownWarningComponent = App.AlertBoxComponent.extend({
  classNames: ['fixed'],
  attributeBindings: ['minutes:data-minutes', 'seconds:data-seconds'],
  layoutName: 'countdown-warning',
  type: 'warning',
  minutes: 0,
  seconds: 0
});

App.CountdownInfoComponent = App.AlertBoxComponent.extend({
  classNames: ['fixed'],
  layoutName: 'countdown-info'
});

Ember.Component only (not using the Web Component)...

<script type="text/x-handlebars" data-template-name="components/alert-box">
  <div class="notice box">
    <div class="left">
      {{partial iconTemplateName}}
    </div>
    <div class="middle">
      <p class="message">
        {{yield}}
      </p>
    </div>
  </div>
  <div class="action box">
    <div class="right">
      {{#if hasCloseContent}}
        {{closeContent}}
      {{else}}
        {{partial closeTemplateName}}
      {{/if}}
    </div>
  </div>
</script>

I'm betting Ember and Web Components…

I'm really happy with the Shadow Dom and the encapsultation it provides for DOM elements. However, since I can't use that across the board I'm stoked that Ember Components do follow the general patterns for native Web Component.

I can use a custom tagName and benefit from using a custom HTML element. And write CSS that provides the default styles for that Custom Element. Even though the Ember Component does not encapsultate the component's DOM like Shadow DOM does using a shadow root, at least the Ember Component has an isolated scope.

I enjoyed test driving Web Components by authoring an Alert Box Web Component, and was able to borrow from that experiment code that is projection ready, the custom element styles and markup.

I am looking forward to the specification for Web Components taking shape and being implemented in more browsers than just Chrome… so I'm placing my bets that Web Components and Ember Components will live in synchronicity at some point in the near future. Web Components doing all the things they are designed to do, working together with Ember Components providing a simple way to stamp out Web Components and provide some useful data bindings as well as work together, perhaps with Custom Events.

Thanks to…

W3C for publishing the Web Component specs
HTMLRocks Tutorials for publishing great tutorials on Web Components

To provide a brief overview of Web Components, I borrowed the content from the two sources above to provide a short summary as highlights of the specifications under the Web Component umbrella.

Measuring Performance with User Timing API, in an Ember Application

2015-03-01T00:00:00+00:00

For more info on Handlebars and HTMLbars see:
* Compiling Templates in Ember v1.10.0
* Feature-by-Feature Review

Using the renderTemplate hook to mark, measure and report metrics

In an Ember application, there are various hooks between routing a request and drawing HTML on the DOM. The renderTemplate hook is the most desireable hook to utilize for marking, measuring and reporting the performance metrics captured while presenting HTML to users. The renderTemplate hook is called after the model hooks and setupController hook compose your data for your template bindings. Combined with the run-loop, specifically the schedule for afterRender the renderTemplate hook can mark the beginning of the work to render a template and, in the afterRender queue, mark the completion of the work. (Ember.run.queues lists the queues that are scheduled by the run loop: ["sync", "actions", "routerTransitions", "render", "afterRender", "destroy"])

Mark, Measure and Report User Timing Metrics

I created a utility with an interface to mark, measure and report measurements taken with the User Timing API. I did use a polyfill for browsers that do not implement the performance specifications.

I used the mixin below in various routes, e.g. Index, Application, Post etc. to collect and measure the statistics for reporting on the timings that an Ember application renders HTML.

import Ember from 'ember';
import config from '../config/environment';
import { mark, measure, report } from '../utils/metrics';

export default Ember.Mixin.create({

  measurementName: Ember.required,

  reportUserTimings: true,

  renderTemplate(controller, model) {
    var beginName = 'mark_begin_rendering_' + this.measurementName;
    var endName = 'mark_end_rendering_' + this.measurementName;
    if (config.APP.REPORT_METRICS) {
      mark(beginName);
      Ember.run.scheduleOnce('afterRender', this, function() {
        mark(endName);
        measure(this.measurementName, beginName, endName);
        if (this.reportUserTimings) {
          report();
        }
      });
    }
    return this._super(controller, model);
  }

});

Utility Module for Metrics Collection and Reporting

This mixin wraps the window.performance methods and provides functions for reporting the measurements using an XHR request and Google Analytics to report User Timings.

What is amazing about the performance measurements is that the API uses high-resolution timing with sub-millisecond resolution.

/*jshint unused:false*/
import Ember from 'ember';
import config from '../config/environment';

export function mark(name) {
  if (!window.performance || !window.performance.mark ) { return; }
  window.performance.mark(name);
}

export function measure(name, begin, end) {
  if (!window.performance || !window.performance.measure ) { return; }
  window.performance.measure(name, begin, end);
}

export function appReady() {
  return measureEntry('app_ready');
}

export function appUnload() {
  return measureEntry('app_unload');
}

export function pageView() {
  return measureEntry('page_view');
}

function measureEntry(name) {
  if (!window.performance || !window.performance.getEntriesByName ) { return; }
  var markName = name + '_now';
  mark(markName);
  if (window.performance.timing) {
    measure(name, 'navigationStart', markName);
  } else {
    measure(name, markName, markName);
  }
}

export function report() {
  if (!window.performance || !window.performance.getEntriesByType ) { return; }
  window.setTimeout(function() {
    send(window.performance.getEntriesByType('measure'));
    clear();
  }, 1000);
}

function send(measurements) {
  var measurement;
  for (var i = 0; i < measurements.length; ++i) {
    measurement = measurements[i];
    post(measurement);
    gaTrackTiming(measurement);
  }
}

export function post(measurement) {
  var payload = createMetric(measurement);
  return Ember.$.ajax({
    type: 'POST',
    url: endpointUri('metrics'),
    contentType: 'application/json; charset=utf-8',
    data: JSON.stringify({ metrics: payload }),
    dataType: 'json'
  });
}

function gaTrackTiming(measurement) {
  if (typeof window.ga !== 'function') { return; }
  window.ga('send', {
    'hitType': 'timing',
    'timingCategory': 'user_timing',
    'timingVar': measurement.name,
    'timingValue': measurement.duration,
    'timingLabel': measurement.emberVersion,
    'page': measurement.pathname
  });
}

function createMetric(measurement) {
  return {
    date: Date.now(),
    name: measurement.name,
    pathname: location.pathname,
    startTime: Math.round(measurement.startTime),
    duration: Number(Math.round(measurement.duration + 'e3') + 'e-3'), // round to thousandths
    visitor: window.localStorage.getItem('visitor'),
    screenWidth: window.screen.width,
    screenHeight: window.screen.height,
    screenColorDepth: window.screen.colorDepth,
    screenPixelDepth: window.screen.pixelDepth,
    screenOrientation: (window.screen.orientation) ? window.screen.orientation.type : null,
    blogVersion: config.APP.version,
    emberVersion: Ember.VERSION,
    adapterType: (config.APP.USE_SOCKET_ADAPTER) ? 'SOCKET' : 'JSONAPI'
  };
}

function endpointUri(resource) {
  var host = config.APP.API_HOST;
  var path = config.APP.API_PATH;
  var uri = (path) ? host + '/' + path : host;
  return uri + '/' + resource;
}

function clear() {
  window.performance.clearMarks();
  window.performance.clearMeasures();
}

Learn more about User Timing API to Measure Performance

Reporting the metrics

At first I decided to add a /metrics endpoint to my API, then later realized that Google Analytics can collect and report on User Timing measurements as well (I'm using both). I prefer the data in my own database, I can create very specific queries to search the userAgent string to compare measurements for mobile, iPad, iPhone, etc.

In addition to collecting measurements for rendering templates I collected metrics on finding data (via an adapter). The metrics I report on are named app_ready, application_view, index_view, post_view, page_view, app_unload, archive_view, and find_posts.

An Example Metric Resource:

{
  adapterType: 'SOCKET',
  blogVersion: '3.3.8.fa3fbaf8',
  date: '2015-02-08T06:29:17.368Z',
  duration: 113.35,
  emberVersion: '1.10.0',
  id: '1a9864a2-4011-49d8-9233-fa76d26e9040',
  name: 'post_view',
  pathname: '/posts/refreshed-my-blog-with-express-and-emberjs',
  screenColorDepth: 24,
  screenHeight: 900,
  screenOrientation: 'landscape-primary',
  screenPixelDepth: 24,
  screenWidth: 1440,
  startTime: 391,
  userAgent: 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) .... Safari/537.36',
  visit: '22d5d2b0be4067ac3af57f4b14fcbb4b4d89fe34b1eeeaab910c259e7b9c55aa',
  visitor: 'c56f439e-646b-4f6a-b91b-5c119e21efba'
}

I created endpoints on my API for /metrics/impressions and /metrics/durations that accept queries that use regular expression matching to search for data based on the object properties of the metrics. For example I can search the pathname, userAgent and emberVersion when reporting on the metrics data.

More info on these endpoints:

Metrics: Rendering with HTMLBars vs Handlebars

I consider the fact that the user only needs a single full screen at a time. So my app loads records in chunks when the user scrolls to the end. I'm not as interested in how well a large table of a thousand records performs; I don't think that users will enjoy waiting for the data anyway. But, for those interested in that kind of pain… I created a page on my site that has 1,000 metrics records, a long list. I collect metrics on rendering that metrics table as well. I'm not convinced that this metric really matters to users. Maybe, if I had a complex data visualization that had a 1,000 data points it would matter. Well, then I'd likely use a data vizualization library (like D3) to render the data instead. So, I'm not convinced that rendering a long list is really of any value to any user. Whether that (long list) measurement is relevant as metric for comparing a template library, my vote is thumbs down.

I am convinced that measuring the perceived performance of web application matters to my users. I think that with these measurements, I can identify trends and make some informed assumptions about how these metrics apply to other Ember applications I work on.

Below are some measurements I took, I gave about a week of web traffic to both template library solutions. I measured the timings for rendering views in my app running both a) Ember.js v1.8.1 with Handlebars v1.3 and b) Ember v1.10.0 and HTMLBars (the initial release).

I was able to collect a good sized data set, so that the average (speed) durations are good comparison between various facets of the metrics data, e.g. emberVersion and userAgent. I can report on the average of all user agents, or on a specfic type of userAgent. Since the timings are measured after data is fetched and the application is ready, I am confident that the metrics captured do reflect the timings that actual users experience.

A few comparisons (Ember.js v1.10.0 and v1.8.1)

The measurements below highlight some gains and losses as a result of the upgrade from Handlebars to HTMLbars in my application…

All userAgents, desktop and mobile

Index (home) page in v1.8.1

//Ember v1.8.1
{
  average: 154.41764912280703,
  durations: 114,
  fastest: 5,
  pathname: "/",
  slowest: 914
}

Index (home) page in v1.10.0

// Ember v1.10.0
{
  average: 244.7352818181818,
  durations: 220,
  fastest: 5,
  pathname: "/",
  slowest: 1854.635
}

The most visited (post) page in v1.8.1

/metrics/durations?name=post_view&pathname=mongoose&emberVersion=1.8

// Ember v1.8.1
{
  average: 251.42101618705053,
  durations: 1668,
  fastest: 8,
  pathname: "/posts/develop-a-restful-api-using-nodejs-with-express-and-mongoose",
  slowest: 3696
}

The most visited (post) page in v1.10.0

/metrics/durations?name=post_view&pathname=mongoose&emberVersion=1.10

// Ember v1.10.0
{
  average: 232.02967880485514,
  durations: 2142,
  fastest: 8,
  pathname: "/posts/develop-a-restful-api-using-nodejs-with-express-and-mongoose",
  slowest: 5726
}

Long list (1,000 metrics) in v1.10.0, in Chrome

/api/metrics/durations?name=metrics_table&emberVersion=1.10&userAgent=Chrome

// Ember Version 1.10.0
{
  average: 690.5488399999999,
  durations: 25,
  fastest: 427.563,
  pathname: "/metrics",
  slowest: 1142.15
}

Long list (1,000 metrics) in v1.8.1, in Chrome

/metrics/durations?name=metrics_table&emberVersion=1.8&userAgent=Chrome

// Ember Version 1.8.1
{
  average: 682.4195625,
  durations: 16,
  fastest: 457.012,
  pathname: "/metrics",
  slowest: 991.684
}

On Mobile

Index (home) page in v1.10.0, on Mobile

/metrics/durations?name=index_view&emberVersion=1.10&userAgent=Mobile

// Ember Version 1.10.0
{
  average: 580.4696976744186,
  durations: 43,
  fastest: 160,
  pathname: "/",
  slowest: 1490
}

Index (home) page in v1.8.1, on Mobile

/metrics/durations?name=index_view&emberVersion=1.8&userAgent=Mobile

// Ember Version 1.8.1
{
  average: 515.881875,
  durations: 8,
  fastest: 330,
  pathname: "/",
  slowest: 914
}

Long list (1,000 metrics) in v1.8.1, on Mobile

/metrics/durations?name=metrics_table&emberVersion=1.8&userAgent=Mobile

// Ember Version 1.8.1
{
  average: 2179.4,
  durations: 10,
  fastest: 871,
  pathname: "/metrics",
  slowest: 5380
}

Long list (1,000 metrics) in v1.10.0, on Mobile

/metrics/durations?name=metrics_table&emberVersion=1.10&userAgent=Mobile

// Ember Version 1.10.0
{
  average: 1617.4285714285713,
  durations: 7,
  fastest: 1014,
  pathname: "/metrics",
  slowest: 2285
}

What I learned about my Performance in my Ember app

I have not read "How not to lie with statistics, The correct way to summarize benchmark results". So, the measurements I've taken at this point, are only an exploration of a data set that is not normalized.

From jayconrod.com… "The geometric mean is intended for averaging ratios (normalized data)" … "Don't bother summarizing raw data without normalizing it."

So, I can't make any conclusions at this point, I can only ask more questions. For example, how do I normalize the data I've that I've captured and calculate the geometric means?

UPDATE: 3/8/15 I've calculated my findings in a new post: How Much Faster is HTMLBars Than Handlebars?

Regarding the upgrade from Handlebars to HTMLbars…

Looking at the average speed of rendering the home page did not seem to show a performance gain, but the data set is not normalized
The same can be said for the speed of rendering the templates on my post pages
Though I don't believe that rendering a long list doesn't matter to my users, after experimenting with a long list I did notice notice any big gains in performance looking at the fastest rendering times in the data I collected

However what appears to be good news, is that the fastest speeds did improve, and even more so on mobile.

On Mobile…

It appears that…

I may expect a 25% - 50% gain in performance for the fastest time to render. The performance gains my users will benefit from (after the upgrade) are limited to the users who have newer mobile devices

Thanks to the hard work of the Ember.js contributors and core team its my expectation that users browsing my site should see a boost in performance.

Since I found these measurements valuable, I'll continue to collect them and review as I try out various beta versions of Ember.js. Recently another release of the 1.11.0 series was released, so I'll give it a try soon.

Once I discover how to normalize the metrics and calculate a proper geometric mean then I can draw some more definitive summaries about the measurements.

At this point, I am very satisfied to have these metrics available from a production build, on a production server from a wide set of users, I get around 10,000 unique users and 30,000 pageviews per month on my blog app. This is not huge, but does provide some good insight into trends I can expect from previous, current and future releases of Ember.

I gave a talk on this topic, here are my presentation notes

Develop Ember.Components for Sharing as Ember CLI Addons, A Practical Example

2014-11-25T00:00:00+00:00

Converting a Micro Library of Components to an Ember CLI Addon

I have a simple micro library of components that I wanted to convert to an Ember CLI Addon. The Ember Off Canvas Components repository contains a group of Ember.js Components that interact to create an Off Canvas layout for use in a web application (powered by Ember). Here is an example of that interface included in another library: UIkit Off-canvas. I'm betting on the idea that most developers would rather pick a component (for the needs in the application they are creating) versus pick an entire UI library that has some common functionality.

I was inspired by the Liquid Fire packaging which includes standalone files with each release for developers who are not yet using Ember CLI. The developing addons documentation for Ember CLI outlines the process of creating an Addon. I found that the packaging scripts in the Liquid Fire repository were straight forward and a good template for including a secondary build of a standalone release.

Prior to converting the off canvas components library to an addon I used Emberella Component Blueprint which provided great tooling for component development. Most of the successful platforms or content management systems that I've used over the past ten years has some type of a marketplace, bundle or packing solution for extending a framework. The Ember Addons website aggregates and provides a searchable collection of ember addons (NPM packages tagged with the ember-addon keyword). Which is a desirable way to share and find extensions for developing applications with Ember.js.

I was on the fence for some time about using Ember CLI addons for components, at first it seemed that addons should be for tooling only; specific to extending the functionity (tooling) that Ember CLI provides. However, after some consideration and after using the standalone release of Liquid Fire it seemed to me that the time was right to give components (as addons) a chance. I've used Ember CLI for some time and now use it during my day job too. I've found that using a common set of development tools is desireable. I like using Testem, Broccoli, Ember QUnit helpers; for me, (my personal) developer happiness increases when I can standardize the way I develop for both applications and libraries. I expect that it would also be a nice-to-have for developers who may eventually work on code I've shipped, perhaps someone like Elad https://twitter.com/Elad/status/537037555154554880.

A Practical Example

So here is a practical guide on how to develop an addon for a component or group of components that work together...

The Ember 2.0 RFC mentions "...communication between components is often most naturally expressed as events or callbacks." which resonates with me. The off-canvas components addon facilitates communication between components using browser events (and bubbling). I did not use any bindings between components or a special dependency as an evented mediator between the components. The browser already provide events, so the components simply talk via custom events which need to be registered with Ember.Application.customEvents

Since I've already shipped the off-canvas components library and it's used in a production application, I thought that it would be a valuable exercise to convert from a custom build to a more common build using Ember CLI. So, I started with following the docs for developing addons. But, I quickly found myself scratching my head. As I followed the guide, questions like "How do I..." and "Why do I do this..." began to interupt me. I hope that this replay of the process I found successful (in buiding an addon of components) will help others find some clartity.

If you are interested, perhaps peruse my commit history while converting over. from commit/0df9223 on 11/19/14 thru 63b84d8 on 11/22/14.

As I followed the docs and attempted to create an addon, I took note of a few topics that interested me or caused some curiosity.

I took the approach of using the addon folder for the components source code and importing the prototypes in the app directory. This seemed like the best way to provide a component that can be used as-is; and can be easily extended or changed at-will by the consuming application developer who may need to extend or re-open the prototype in their own application source code.

Start by Generating the Files you Need

The docs suggest using the ember command to generate an addon then to generate the building blocks you will include in your addon.

ember addon ember-off-canvas-components is the command I used to kick off the scaffold of my converstion to an addon.

Next, use the ember generate component command to create the basic files you need for a component, including unit test files.

You can update the test with any test code you've already written or perhaps take the opportunity to mint a fresh new test.

To begin, a super simple test should fail, if you add an assertion for using Custom Elements. (Web Components use Custom Elements, right?)

import { moduleForComponent, test } from 'ember-qunit';

moduleForComponent('on-canvas', 'OnCanvasComponent');

test('it renders element with tagName on-canvas', function() {
  expect(3);

  var component = this.subject();
  equal(component._state, 'preRender');

  this.append();
  equal(component._state, 'inDOM');
  equal(component.get('element').tagName, 'on-canvas'.toUpperCase(), 'matches `on-canvas`');
});

Then I copied over the code for this component (this is the simplest one, all I needed was to use a custom element). After the ember generate component on-canvas command I copied the generated code into the addon/components directory.

import Ember from 'ember';

/**
  To use this component in your app, add this to a template:

  ```handlebars
  {{#on-canvas}}
    {{#off-canvas-opener}}
      <i class="fa fa-bars"></i>
    {{/off-canvas-opener}}
    <div class="on-canvas-body">
      On Canvas Contents
    </div>
  {{/on-canvas}}

@extends Ember.Component
*/

export default Ember.Component.extend({
/**
The type of element to render this view into. By default, samples will appear
as <on-canvas/> elements.

@property tagName
@type String

*/
tagName: 'on-canvas',

classNames: ['on-canvas-default']
});
```

Next, I changed the module that was generated, app/components/on-canvas.js, to only import the prototype from the addon directory.

import OnCanvasComponent from 'ember-off-canvas-components/components/on-canvas';

export default OnCanvasComponent;

What About Initializers?

I mentioned that the components talk using custom events, well the Ember Application will need to register the customEvents.

For example on click the component may toggle the display of the off canvas panel like so:

click: function (evt) {
  var eventName;
  if (this.get('useToggle')) {
    eventName = 'toggleOffCanvas';
  } else {
    eventName = 'expandOffCanvas';
  }
  Ember.$(evt.target).trigger(eventName);
  return false;
}

This requires an initializer to register the custom events I used in the group of components: toggleOffCanvas, expandOffCanvas, and collapseOffCanvas.

Again, using the command ember generate initializer custom-events creates the file I need in the app/initializers directory. I did the same thing I did with the component, I copied the generated file to addon/initializers/custom-events.js then pasted and updated the initializer code.

import Ember from 'ember';

export function initialize(container, application) {
  var customEvents = application.get('customEvents') || {};
  Ember.String.w('toggle expand collapse').forEach(function (prefix) {
    var name = Ember.String.fmt("%@OffCanvas", prefix);
    customEvents[name] = name;
  });
  application.set('customEvents', customEvents);
}

export default {
  name: 'ember-off-canvas-components/custom-events',
  initialize: Ember.K
};

The initializer exports the initialize method which I import in the application. This will be come handy as I will need to import this initialzer in the app directory for apps consuming the addon as well as utilize the initializer in the packaging scripts for the standalone release to accompany each release of the addon.

In app/initializers/eoc-custom-events.js I added:

import { initialize } from 'ember-off-canvas-components/initializers/custom-events';

export default {
  name: 'eoc-custom-events',
  initialize: initialize
};

I used a different name for the initializer, as I had some errors in the browser console about the name of the initializer 'custom-events' already being registered. So, I didn't fight it, just added a prefix.

Initializers can be tested too; the ember generator already setup a unit test file. In tests/unit/initializers/custom-events-test.js:

import Ember from 'ember';
import { initialize } from 'ember-off-canvas-components/initializers/custom-events';

var container, application;

module('CustomEventsInitializer', {
  setup: function() {
    Ember.run(function() {
      container = new Ember.Container();
      application = Ember.Application.create();
      application.deferReadiness();
    });
  }
});

test('it sets customEvents on the application', function() {
  expect(1);

  initialize(container, application);

  var expected = {
    toggleOffCanvas: "toggleOffCanvas",
    expandOffCanvas: "expandOffCanvas",
    collapseOffCanvas: "collapseOffCanvas"
  };

  deepEqual(application.customEvents, expected);
});

What About an Example App for gh-pages?

Ember CLI includes a dummy app that you can work with during development with the ember server command or use as a demo app with the ember build script which builds the dummy app in your /dist directory. Here is the demo I created with the dummy app.

In tests/dummy there are folders for app, config, and public, the makings of an ember application. In the dummy directory I added a few files I had already used in the previous iteration of this library (the pre-ember-cli version) as an example app. So I created the needed index controller and route, as well as templates for the application, index and a partial off-canvas template. I copied a few styles to the dummy app too. I needed to update the tests/dummy/config/environment.js to add a custom contentSecurityPolicy with settings to squelch some noisy errors in the browser console since I used font-awesome, 'style-src' needed 'unsafe-inline' and a cdn link. Perhaps research contentSecurityPolicy to setup your demo (dummy application) to your liking.

Like developing a application with ember-cli, the ember server command rebuilds the source of the dummy app as you edit the code.

I used the ember build command then copy the output from the /dist directory to a separate gh-pages branch to share a demo app with the repository on Github.

So you want to use SASS, me too

I had to consider a few concerns and curiosities in order to include node-sass as a dev dependency. After some trial and error, I found...

Brocfile doesn’t import vendor files, index.js does
I need a custom script for compiling CSS with node-sass and execute the compile step in the Brocfile
No need to include the generated CSS in the repo - .gitignore the compiled CSS file(s)

I ended up writing a script to compile the SASS to CSS and write the style sheet for the custom elements in the /vendor directory.

For SASS I used a directory addon/styles/scss for the .scss files, and setup config/environment.js with paths for compiling/output.

The compile-css.js script:

/* global require, module */
var sass = require('node-sass');
var path = require('path');

module.exports = function (env) {
  env = env || 'development';
  var configPath = path.resolve(__dirname, 'config/environment');
  var config = require(configPath)(env);
  var cssFile = 'vendor/' + config.addonPrefix + '.css';
  var vendorFile = path.resolve(__dirname, cssFile);

  sass.renderFile({
    file: path.resolve(__dirname, config.sassMain),
    success: function(/*css*/) {
      console.log('node-sass compiled', vendorFile.split(__dirname)[1]);
    },
    error: function(error) {
      console.error(error);
    },
    includePaths: [ path.resolve(__dirname, config.sassIncludePath) ],
    outputStyle: (env === 'development') ? 'nested' : 'compressed',
    outFile: vendorFile,
    precision: 5,
    sourceMap: (env === 'development')
  });
};

I added a sass script to the package.json file, which uses the above compile script, "sass": "node -e \"require('./compile-css.js')()\"".

The compile script is called from the Brocfile I expect that the css will be compiled on each change.

/* global require, module */
var EmberAddon = require('ember-cli/lib/broccoli/ember-addon');
var app = new EmberAddon();

require('./compile-css')(app.env);

module.exports = app.toTree();

Since the repository now has a dependency to compile SASS to CSS I added a postinstall script in the package.json using a shell script postinstall.sh:

#!/bin/sh

echo "postinstall..."

echo "installing bower dependendies"
npm install bower
./node_modules/.bin/bower install

echo "installing node-sass"
npm install node-sass

echo "compiling CSS to /vendor with node-sass"
./node_modules/.bin/node-sass ./addon/styles/scss/main.scss ./vendor/ember-off-canvas-components.css

Ok, Ship It!

If your only targeted users are ember-cli users then just edit the package.json file, perhaps add a .npmignore file and surprise the travis config just works out of the box.

So are you telling me that I can develop Web Components and ship them with Ember CLI. No and yes, wait. I plan to do a followup post on using Native Web Components with an Ember component utilizing the strengths of Ember bindings. That's another topic for Custom Elements, HTML Imports, Template and Shadow DOM. Ember Components are currently isolated views, "An Ember.Component is a view that is completely isolated... There is no access to the surrounding context or outer controller; all contextual information must be passed in". But remember the Ember 2.0 rfc topic is filled with plans for components. That said developing component will become a significant area of focus for developers working with Ember.

That said, the genterated package.json file is already tagged with the ember-addon keyword. So you can login and publish at will.

npm login follow the prompts, of course you will need a npmjs.org account
npm publish . from inside the root directory of your addon

Build, Test and Release

I wrote a script prepublish.sh to use in the package.json scripts do the prepublish tasks of cleaning, building and executing tests.

#!/bin/sh

echo "clean vendor directory..."
rm -fr ./vendor/*

echo "build and test..."
ember build
ember test

echo "building global/shim dist files..."
rm -fr ./dist
cd ./packaging
../node_modules/.bin/broccoli build ../dist

After considering what will be published and trying out the prepublish script I made a few more tweeks:

Packaging builds standalone library files (.js and .css) to the main /dist directory. See the Standalone section for more details on packaging.
config/envrionment.js file needs development and test envrionment definitions
Add a .npmignore file to ignore the client dependency files for the NPM release.
in package.json set the main file to index.js

Before I actually published the a release on npmjs.org I wanted to provide a standalone release for developers not yet using Ember CLI. You can too, read on...

I added a clean script to the package.json and use the clean and prepublish scripts to npm publish a version (npm login req) so prior to npm login and npm publish . I run npm run clean. The prepublish script will be run with the publish command.

Can any Ember Developer Use my Addon?

If you take a few steps to learn Broccoli to package up a standalone release. Hey someone has already done the heavy lifting. I'm hoping that the Liquid Fire packaging scripts will themselves become an addon.

A Standalone Release

With the Ember Off Canvas Components addon/library I included a copy of the Liquid Fire packaing scripts with a few customizations and generalization changes. See the ember-off-canvas-components packaging and packaging README.

The Brocfile.js, registry.js, and wrap.js have a couple generalization changes to use the addon config

Then there is the custom needs for shipping a library aside from Ember CLI. The standalone release of the addon will need to register the components in the Application continer so you can use the fancy helpers in the templates, e.g. {{#off-canvas}}{{/off-canvas}} (once HTMLBars lands that will look much more like a component). Also the standalone release will need to run any initializers you provide in your addon.

Exporting to a Global

Create an index.js in the addon folder for exporting the library attached to a global variable with a standalone build, like so:

import EOCViewportComponent from './components/eoc-viewport';
import OnCanvasComponent from './components/on-canvas';
import OffCanvasComponent from './components/off-canvas';
import OffCanvasOpenerComponent from './components/off-canvas-opener';
import OffCanvasCloserComponent from './components/off-canvas-closer';

export {
  EOCViewportComponent,
  OnCanvasComponent,
  OffCanvasComponent,
  OffCanvasOpenerComponent,
  OffCanvasCloserComponent
};

This above export is not needed by an addon, but I guess you could use it as an entry point if you choose to.

The Glue

The packaging scripts utilize a glue.js file to meet the needs of shipping a standalone release.

The following is used to ship the library code and provide access on a global variable, window.EmberOffCanvasComponents it uses the index.js file in the root of the addon directory to import assign. It also uses a shim to add the container references. Finally, I wrapped the addon's initializer to register custom events using a ember-off-canvas-components-shim initializer.

/* global define, require, window */
var addonName = 'ember-off-canvas-components';

define('ember', ["exports"], function(__exports__) {
  __exports__['default'] = window.Ember;
});

var index = addonName + '/index';
define(addonName, ["exports"], function(__exports__) {
  var library = require(index);
  Object.keys(lf).forEach(function(key) {
    __exports__[key] = library[key];
  });
});

// Glue library to a global var
window.EmberOffCanvasComponents = window.EOC = require(index);

// Register library items in the container
var shim = addonName + '-shim';
window.Ember.Application.initializer({
  name: shim,

  initialize: function(container) {
    require(shim).initialize(container);
  }
});

// Register Custom Events on the Application
var customEventsInitializer = 'ember-off-canvas-components/initializers/custom-events';
window.Ember.Application.initializer({
  name: customEventsInitializer,

  initialize: function(container, application) {
    var customEvents = require(customEventsInitializer);
    customEvents.initialize(container, application);
  }
});

That's a Wrap

Well now that the repository has tools available using ember and npm run on the command line. A few scripts were needed for post installation, pre-publishing, compiling CSS, and building a standalone release. Now, the Ember Off Canvas Components addon can be found on Ember Addons or with npm search. Developers can use the library with npm install --save-dev pixelhandler/ember-off-canvas-components

Without too much effort, the micro library of Ember Components can be created, tested, released and consumed by application developers.

I'm looking forward to developing and sharing more components as Ember CLI addons.

How to Use 404 Page in Your Ember.js Application

2014-08-29T00:00:00+00:00

Cases when a 404 page is needed

When the URL does not match any defined routes, the application should render a 404 page.
When a route's model hook has a call to this.store or Em.$.ajax and the result is a promise that is rejected perhaps the application should show a 404 page.

For example, when your adapter cannot find the resource that a route is expected to fetch. Ember.js routes may use an error action to transition to a 404 page. This will support a route which fails to transition due to a rejected promise caused by one or more of the route's hooks, e.g. model.

Catch-all route

To address the first case (above), when a given url doesn't match any route, define the last route in your router using a wildcard globbing route.

I setup a route for not-found in my router. The last route uses the wildcard /*path to catch any text string not already matched by other routes or resources. See the 'not-found' route in the router example below.

Router.map(function () {
  this.route('about');
  this.resource('posts', function () {
    this.resource('post', { path: ':post_slug' });
  });
  this.route('not-found', { path: '/*path' });
});

When the wildcard path matches a url that should result in the application rendering a 404 page, the (404) not-found route utilizes the redirect hook in order to transition to the url /not-found. My app has a Route prototype (app/routes/not-found.js) which is mapped to the 'non-found' route:

import Ember from 'ember';

export default Ember.Route.extend({
  redirect: function () {
    var url = this.router.location.formatURL('/not-found');
    if (window.location.pathname !== url) {
      this.transitionTo('/not-found');
    }
  }
});

The result is that the application renders a not-found template (templates/not-found.hbs) with a link to my archives page.

<h1>404 Not Found</h1>
<p>
  Perhaps you have a link that has changed, see {{#link-to 'posts'}}Archives{{/link-to}}.
</p>

Error in a route hook

Any route having a hook (e.g. model, beforeModel, afterModel) that results in a rejected promise, can use the error action to transition to the 404. See the Ember.Route error event doc page.

Define the action, log the error and transition to the '/not-found' page

import Ember from 'ember';

export default Ember.Route.extend({
  actions: {
    error: function (error) {
      Ember.Logger.error(error);
      this.transitionTo('/not-found');
    }
  }
});

Here is my 404 page: http://pixelhandler.com/not-found.

Real-time Data for an Ember.js Application using WebSockets

2014-08-20T00:00:00+00:00

Following the release of Orbit.js, Ember Orbit was announced at the Wicked Good Ember conference. Again, I became excited about using smaller JSON Patch payloads (media type "application/json-patch+json"), see RFC 6902. I started a new branch and decided to support a REST source first; then later tackle a WebSocket source. I am a fan of the JSON API specification which does include patch support. Once I had a JSONAPISource working with Ember Orbit on my branch I updated my SocketSource prototype (class) to follow the JSONAPISource prototype so they could share the same serializer. Also if the client's browser doesn't support a WebSocket or perhaps in the case my socket server gets wacky the application can initialize with the JSONAPISource instead of the SocketSource prototype as the connected source to the application's MemorySource.

A Few Reasons to use WebSockets

Push support in a browser application can be used to provide real-time updates site visitors. Waiting for a client's next request or page refresh to provide updates works great when you expect frequent reloads. However, when an application is shipped as a single page (an Ember.js application) push support is attractive.

Web Sockets (TCP)
- Potentially closer to real-time interations compared to REST
- Ships with All modern (popular) browsers, see caniuse.com/#search=Socket
- Gets around CORS
Smaller payloads (partial representation of a resource)
- JSONPatch, jsonpatch.com
Connecting multiple storage adapters
- Memory <-> localStorage <-> Web Socket (remote db)
High availability (in a distributed computing system)
- Weak consistency with higher availability
- Choose liveness (eventually there) over Safety (always right)

JSON Patch

See: jsonpatch.com ...

Simple example

The original document:

{
  "baz": "qux",
  "foo": "bar"
}

The patch:

[
  { "op": "replace", "path": "/baz", "value": "boo" },
  { "op": "add", "path": "/hello, "value": ["world"] },
  { "op": "remove, "path": "/foo}
]

The result:

{
   "baz": "boo",
   "hello": ["world"]
}

Operations

Add, Remove, Replace, Copy, Copy, Test

Add

{"op": "add", "path": "/biscuits/1", "value": {"name": "Ginger Nut"}}

Adds a value to an object or inserts it into an array. In the case of an array the value is inserted before the given index. The - character can be used instead of an index to insert at the end of an array.

Remove

{"op": "remove", "path": "/biscuits"}

Removes a value from an object or array.

Replace

{"op": "replace", "path": "/biscuits/0/name", "value": "Chocolate Digestive"}

Replaces a value, equivalent to a “remove” followed by an “add”.

JSON Patch payloads used by this blog app

An add operation...

{"op":"add","path":"/posts/-","value":{"id":"a4d213d6-5595-4686-9817-169a7eddbda1","slug":"test","title":"test title","date":"2014-10-29","excerpt":"test excerpt text","body":"test body text","links":{"author":null}}}

{"path":"/posts/a4d213d6-5595-4686-9817-169a7eddbda1/links/author","op":"add","value":"5c9b62ec-1569-448b-912a-97e6d62f493e"}

{"path":"/authors/5c9b62ec-1569-448b-912a-97e6d62f493e/links/posts/-","op":"add","value":"a4d213d6-5595-4686-9817-169a7eddbda1"}

A delete operation...

{"op":"remove","path":"/posts/341207e0-cfd9-4d3a-a5ab-d2268ab2e472/links/author"}

{"op":"remove","path":"/authors/5c9b62ec-1569-448b-912a-97e6d62f493e/links/posts/341207e0-cfd9-4d3a-a5ab-d2268ab2e472"}

{"op":"remove","path":"/posts/341207e0-cfd9-4d3a-a5ab-d2268ab2e472"}

Compare with the JSON API payloads

Orbit.js

Let's take a look at the [ember-orbit-example] demo app.

Watch Dan give an intoduction to Orbit.js. (YouTube video from the Jan '14 Boston Ember Meetup)

How Orbit works

Orbit requires that every data source support one or more common interfaces. These interfaces define how data can be both accessed and transformed.
The methods for accessing and transforming data return promises.
Multiple data sources can be involved in a single action

Orbit.js uses JSON / JSONPatch by default.

Sends partial data
Uses multiple stores

Orbit interfaces:

Requestable
- for managing requests for data via methods such as find, create, update and destroy
Transformable
- Keep data sources in sync through low level transformations (using JSON PATCH spec)
- transform is the method your data source (prototype) object needs to implement

Requestable

Events associated with an action:

assistFind, rescueFind, didFind, didNotFind

Transformable

A single method, transform, which can be used to change the contents of a source.

{op: 'add', path: 'planet/1', value: {__id: 1, name: 'Jupiter', classification: 'gas giant'}
{op: 'replace', path: 'planet/1/name', value: 'Earth'}
{op: 'remove', path: 'planet/1'}

TransformConnector

A TransformConnector watches a transformable source and propagates any transforms to a transformable target.

Each connector is "one way", so bi-directional synchronization between sources requires the creation of two connectors.

RequestConnector

A RequestConnector observes requests made to a primary source and allows a secondary source to either "assist" or "rescue" those requests.

The mode of a RequestConnector can be either "rescue" or "assist" ("rescue" is the default).

Document

Document is a complete implementation of the JSON PATCH spec detailed in RFC 6902.

It can be manipulated via a transform method that accepts an operation, or with methods add, remove, replace, move, copy and test.

Data at a particular path can be retrieved from a Document with retrieve().

Ember Orbit

"A library that integrates Orbit.js with Ember.js to provide flexibility and control in your application's data layer"

Video: Building Autonomous Web Applications with Ember and Orbit

This project uses ember-cli, to the modules below use ES6 syntax, see the ES6 draft.

Initializer

Configure Ember-Orbit with an application initializer that sets up Orbit and registers a "main" store and schema to be available in routes and controllers.

initializers/ember-orbit.js

import Orbit from 'orbit';
import EO from 'ember-orbit';
import JSONAPISource from 'orbit-common/jsonapi-source';
import ApplicationSerializer from '../serializers/application';
import SocketSource from '../adapters/socket-source';
import Ember from 'ember';
import config from '../config/environment';

Orbit.Promise = Orbit.Promise || Ember.RSVP.Promise;

function jsonApiStore() {
  Orbit.ajax = Ember.$.ajax;
  return EO.Store.extend({
    orbitSourceClass: JSONAPISource,
    orbitSourceOptions: {
      host: config.APP.API_HOST,
      namespace: config.APP.API_PATH,
      SerializerClass: ApplicationSerializer,
      usePatch: true,
    }
  });
}

function socketStore() {
  return EO.Store.extend({
    orbitSourceClass: SocketSource,
    orbitSourceOptions: {
      host: config.APP.SOCKET_URL,
      SerializerClass: ApplicationSerializer,
      usePatch: true,
    }
  });
}

var Schema = EO.Schema.extend({
  idField: 'id',

  init: function (options) {
    this._super(options);
    this._schema.meta = Ember.Map.create();
  }
});

export default {
  name: 'ember-orbit',
  after: 'socket',

  initialize: function(container, application) {
    application.register('schema:main', Schema);
    application.register('store:main', EO.Store);
    if (notPrerenderService() && canUseSocket(container)) {
      application.register('store:secondary', socketStore());
    } else {
      application.register('store:secondary', jsonApiStore());
    }
    connectSources(container);

    application.inject('controller', 'store', 'store:main');
    application.inject('route', 'store', 'store:main');
  }
};

function notPrerenderService() {
  return window.navigator.userAgent.match(/Prerender/) === null;
}

function canUseSocket(container) {
  return window.WebSocket && container.lookup('socket:main');
}

function connectSources(container) {
  var primarySource = container.lookup('store:main').orbitSource;
  var secondarySource = container.lookup('store:secondary').orbitSource;
  // Connect (using default blocking strategy)
  setupConnectors(primarySource, secondarySource);
}

function setupConnectors(primary, secondary/*, local*/) {
  new Orbit.TransformConnector(primary, secondary);
  new Orbit.TransformConnector(secondary, primary);
  primary.on('assistFind', secondary.find);
}

Sources

"Source are very thin wrappers over Orbit sources"

adapters/socket-source.js

import Ember from 'ember';
import Orbit from 'orbit';
import OC from 'orbit-common';
import SocketService from '../services/socket';
import JSONAPISource from 'orbit-common/jsonapi-source';

Orbit.Promise = Orbit.Promise || Ember.RSVP.Promise;

var SocketSource = JSONAPISource.extend({

  init: function (schema, options) {
    Orbit.assert('SocketSource requires SocketService be defined', SocketService);
    Orbit.assert('SocketSource requires Orbit.Promise be defined', Orbit.Promise);
    Orbit.assert('SocketSource only supports usePatch option', this.usePatch);
    this._socket = SocketService.create();
    this.initSerializer(schema, options);
    // not calling super, instead calling template/abstract prototype init method
    return OC.Source.prototype.init.apply(this, arguments);
  },

  initSerializer: function (schema, options) {
    // See JSONAPISource
    this.SerializerClass = options.SerializerClass || this.SerializerClass;
    if (this.SerializerClass && this.SerializerClass.wrappedFunction) {
      this.SerializerClass = this.SerializerClass.wrappedFunction;
    }
    this.serializer = new this.SerializerClass(schema);
  },

  // using JSONPatch via WebSocket
  usePatch: true,

  // Requestable interface implementation

  _find: function(type, id) {
    if (id && (typeof id === 'number' || typeof id === 'string')) {
      return this._findOne(type, id);
    } else {
      return this._findQuery(type, id);
    }
  },

  _findLink: function() {
    console.error('TODO, SocketSource#_findLink not supported yet');
  },

  // Requestable Internals

  _findOne: function (type, id) {
    var query = this._queryFactory(type, { id: id });

    return this._remoteFind('find', type, query);
  },

  _findMany: function () {
    throw new Error('SocketSource#_findMany not supported');
  },

  _findQuery: function (type, query) {
    query = this._queryFactory(type, query);

    return this._remoteFind('findQuery', type, query);
  },

  _remoteFind: function (channel, type, query) {
    var root = pluralize(type);
    var id = query.id;
    query = JSON.stringify(query);

    // handle promise resolution serially, pass off return to next then handler
    var records;
    return new Orbit.Promise(function doFind(resolve, reject) {
      this._socket.emit(channel, query, function didFind(raw) {
        if (raw.errors || !raw[root]) {
          reject(raw.errors);
        } else {
          resolve(raw);
        }
      });
    }.bind(this))
    .then(function doProcess(raw) {
      return this.deserialize(type, id, raw);
    }.bind(this))
    .then(function (data) {
      records = data;
      return this.settleTransforms();
    }.bind(this))
    .then(function () {
      // finally send back the records
      return records;
    })
    .catch(function onError(error) {
      console.error('SocketSource#_remoteFind Error w/ query: ' + query);
      console.error(error);
    });
  },

  _queryFactory: function (type, query) {
    query = query || {};
    query.resource = query.resource || pluralize(type);

    var attrs = Ember.String.w('limit offset sortBy order resource withFields');
    attrs.forEach(function (attr) {
      query[attr] = query[attr] || Ember.get(this, attr);
    }.bind(this));

    return query;
  },

  // Transformable Internals

  _transformAdd: function (operation) {
    var type = operation.path[0];
    var id = operation.path[1];
    var remoteOp = {
      op: 'add',
      path: '/' + pluralize(type) + '/-',
      value: this.serializer.serializeRecord(type, operation.value)
    };
    return this._remotePatch(type, id, remoteOp);
  },

  _transformReplace: function (operation) {
    var type = operation.path[0];
    operation.path[0] = pluralize(type);
    var id = operation.path[1];
    var remoteOp = {
      op: 'replace',
      path: '/' + operation.path.join('/'),
      value: this.serializer.serializeRecord(type, operation.value)
    };
    return this._remotePatch(type, id, remoteOp);
  },

  _transformRemove: function (operation) {
    var type = operation.path[0];
    operation.path[0] = pluralize(type);
    var id = operation.path[1];
    var path = '/' + operation.path.join('/');
    var remoteOp = { op: 'remove', path: path };
    return this._remotePatch(type, id, remoteOp);
  },

  _transformUpdateAttribute: function (operation) {
    var type = operation.path[0];
    operation.path[0] = pluralize(type);
    var id = operation.path[1];
    var remoteOp = {
      op: 'replace',
      path: '/' + operation.path.join('/'), // includes attr in path
      value: operation.value
    };
    return this._remotePatch(type, id, remoteOp);
  },

  _transformAddLink: function (operation) {
    var type = operation.path[0];
    operation.path[0] = pluralize(type);
    var id = operation.path[1];
    var link = operation.path[3];
    var linkId = operation.path[4] || operation.value;
    var linkDef = this.schema.models[type].links[link];
    var path;
    if (linkDef.type === 'hasMany') {
      operation.path.pop();
      path = '/' + operation.path.join('/').replace(/__rel/, 'links') + '/-';
    } else if (linkDef.type === 'hasOne') {
      path = '/' + operation.path.join('/').replace(/__rel/, 'links');
    }
    var remoteOp = { path: path, op: 'add', value: linkId };
    return this._remotePatch(type, id, remoteOp);
  },

  _transformRemoveLink: function (operation) {
    var type = operation.path[0];
    operation.path[0] = pluralize(type);
    var id = operation.path[1];
    var path = '/' + operation.path.join('/').replace(/__rel/, 'links');
    var remoteOp = { op: 'remove', path: path };
    return this._remotePatch(type, id, remoteOp);
  },

  _transformReplaceLink: function (operation) {
    console.error('TODO, SocketSource#_transformReplaceLink not supported yet');
  },

  _remotePatch: function (type, id, remoteOp) {
    var records;
    // handle promise resolution serially, pass off return to next then handler
    return new Orbit.Promise(function doPatch(resolve, reject) {
      this._socket.emit('patch', JSON.stringify(remoteOp), function didPatch(raw) {
        if (raw && raw.errors) {
          reject(raw.errors);
        } else {
          resolve(raw); // doesn't matter what raw is, socket called back w/o errors
        }
      });
    }.bind(this))
    .then(function doProcess(raw) {
      if (raw && Array.isArray(raw)) {
        return this.deserialize(type, id, raw[0]);
      }
      return null;
    }.bind(this))
    .then(function (data) {
      records = data;
      return this.settleTransforms();
    }.bind(this))
    .then(function () {
      // finally send back the records
      return records;
    })
    .catch(function onError(error) {
      console.error(error);
      var e = "SocketSource#_remotePatch Error w/ op: %@, path: %@";
      throw new Error(e.fmt(remoteOp.op, remoteOp.path));
    });
  }

});

// TODO use Ember.Inflector https://github.com/stefanpenner/ember-inflector.git
var pluralize = function (name) {
  return name + 's';
};
// borrowed from 'orbit/lib/objects'
var isObject = function(obj) {
  return obj !== null && typeof obj === 'object';
};

export default SocketSource;

Stores

"Stores extend sources and are also repositories for models. All of the data in a store is maintained in its internal source."

Below are a few examples of how I use the application store in a Route:

Custom query for posts

model: function () {
  var query = { offset: this.get('offset'), limit: this.get('limit') };
  return this.store.find('post', query);
},

List of posts

model: function () {
  return this.store.find('post');
},

A specific post by id

model: function (params) {
  return this.store.find('post', params.edit_id);
},

A post route that can find a post from the store's memory or ask the secondary source (adapter) for the resource

model: function (params) {
  return new Ember.RSVP.Promise(function (resolve, reject) {
    var found = this.store.filter('post', function (post) {
      return post.get('slug') === params.post_slug;
    });
    if (found.get('length') > 0) {
      resolve(found[0]);
    } else {
      this.store.find('post', params.post_slug).then(
        function (post) {
          resolve(post);
        },
        function (error) {
          reject(error);
        }
      );
    }
  }.bind(this));
},

Push Support

Routes can use a mixin for push support for real-time update to connected clients.

mixins/push-support.js

import Ember from 'ember';

export default Ember.Mixin.create({

  beforeModel: function () {
    this.socketSanityCheck();
    return this._super();
  },

  socketSanityCheck: function () {
    // Sanity check, is socket working? check output browser console.
    var socket = this.socket;
    socket.on('hello', function (data) {
      console.log(data);
      socket.emit('talk-to-me', 'I like talking.', function (msg) {
        console.log('back talk', msg);
      });
    });
  },

  // Template methods...

  onDidPatch: Ember.required,

  patchRecord: function (operation) {
    this._patchRecord(operation);
  },

  addLink: Ember.K,
  replaceLink: Ember.K,
  removeLink: Ember.K,
  addRecord: Ember.K,
  updateAttribute: Ember.K,
  deleteRecord: Ember.K,

  // Use in template methods...

  _patchRecord: function (operation) {
    operation = (typeof operation === 'string') ? JSON.parse(operation) : operation;
    if (!operation.op || !operation.path) {
      console.error('Push error! Invalid patch operation.');
      return;
    }
    if (operation.path.match('/links/') !== null) {
      if (operation.op === 'add') {
        Ember.run.later(this, 'addLink', operation, this._delay);
      } else if (operation.op === 'replace') {
        Ember.run.next(this, 'replaceLink', operation);
      } else if (operation.op === 'remove') {
        Ember.run.next(this, 'removeLink', operation);
      }
    } else {
      if (operation.op === 'add') {
        Ember.run.next(this, 'addRecord', operation);
      } else if (operation.op === 'replace') {
        Ember.run.next(this, 'updateAttribute', operation);
      } else if (operation.op === 'remove') {
        Ember.run.next(this, 'deleteRecord', operation);
      }
    }
  },

  _addLink: function(operation) {
    var model = this._retrieveModel(operation);
    if (model) {
      var type = operation.path.split('/links/')[1];
      var relation = this.store.retrieve(type, { primaryId: operation.value });
      if (relation) {
        model.addLink(type, relation);
      }
    }
  },

  _replaceLink: function(operation) {
    console.error('TODO replaceLink not supported yet', operation);
  },

  _removeLink: function(operation) {
    var model = this._retrieveModel(operation);
    if (model) {
      var path = operation.path.split('/links/')[1].split('/');
      var type = path[0];
      var id = path[1];
      var relation = null;
      if (id) {
        relation = this.store.retrieve(type, { primaryId: id });
      }
      model.removeLink(type, relation);
    }
  },

  _addRecord: function (operation) {
    var type = this._extractType(operation);
    var id = operation.value.id;
    var model = this.store.retrieve(type, { primaryId: id });
    if (!model) {
      this.store.add(type, operation.value);
      this.store.then(function() {
        model = this.store.retrieve(type, { primaryId: id });
        var name = this.get('routeName');
        var collection = this.modelFor(name);
        if (collection && !collection.contains(model)) {
          collection.insertAt(0, model);
          this.controllerFor(name).set('model', collection);
        }
      }.bind(this));
    }
  },

  _updateAttribute: function(operation) {
    var type = this._extractType(operation);
    if (!type) {
      return;
    }
    var typeKey = this.store.schema._schema.pluralize(type);
    var path = operation.path.split('/' + typeKey + '/')[1];
    var id, attribute;
    if (path.indexOf('/') !== -1) {
      path = path.split('/');
      id = path[0];
      attribute = path[1];
    }
    var model = this.store.retrieve(type, {primaryId: id});
    if (model && attribute) {
      model.set(attribute, operation.value);
    }
  },

  _deleteRecord: function (operation) {
    var model = this._retrieveModel(operation);
    if (model) {
      var name = this.get('routeName');
      var collection = this.modelFor(name);
      if (collection) {
        collection.removeObject(model);
      }
      var controller = this.controllerFor(name);
      if (controller) {
        controller.removeObject(model);
      }
      if (model.constructor.typeKey) {
        var type = model.constructor.typeKey;
        var id = model.get('primaryId');
        Ember.run.later(this.store, 'remove', type, id, this._delay);
      }
    }
  },

  _extractType: function (operation) {
    var path = operation.path.split('/');
    var type = this.store.schema._schema.singularize(path[1]);
    if (!this.store.schema._schema.models[type]) {
      console.error('Cannot extract type', path);
    }
    return type;
  },

  _retrieveModel: function (operation) {
    var path = operation.path.split('/');
    var type = this.store.schema._schema.singularize(path[1]);
    var id = path[2];
    return this.store.retrieve(type, { primaryId: id });
  },

  _delay: 1000

});

Routes using the push support mixin

routes/application.js

import Ember from 'ember';
import PushSupport from '../mixins/push-support';
import config from '../config/environment';

var ApplicationRoute = Ember.Route.extend(PushSupport, {

  model: function () {
    return this.store.find('post');
  },

  /* some code not included here */

  // Push support...

  onDidPatch: function () {
    this.socket.on('didPatch', this.patchRecord.bind(this));
  }.on('init'),

  addLink: function (operation) {
    this._addLink(operation);
  },

  removeLink: function (operation) {
    this._removeLink(operation);
  },

  addRecord: function (operation) {
    this._addRecord(operation);
  },

  updateAttribute: function (operation) {
    this._updateAttribute(operation);
  },

  deleteRecord: function (operation) {
    this._deleteRecord(operation);
  },

  /* some code not included here */

});

function lookupSocket(container) {
  if (!window.WebSocket) {
    return false;
  }
  return container.lookup('socket:main');
}

/* some code not included here */

export default ApplicationRoute;

routes/index.js

import Ember from 'ember';
import RecordChunksMixin from '../mixins/record-chunks';
import ResetScroll from '../mixins/reset-scroll';
import PushSupport from '../mixins/push-support';

export default Ember.Route.extend(ResetScroll, RecordChunksMixin, PushSupport, {

  /* some code not included here */

  model: function () {
    var posts = this.modelFor('application');
    if (this.get('offset') < posts.get('length')) {
      return posts;
    } else {
      var query = this.buildQuery();
      return this.store.find('post', query);
    }
  },

  // Push support...

  onDidPatch: function () {
    this.socket.on('didPatch', this.patchRecord.bind(this));
  }.on('init'),

  addRecord: function (operation) {
    if (operation.path.split('/')[1] === 'posts') {
      var posts = this.model();
      var controller = this.controllerFor(this.get('routeName'));
      if (typeof posts.then === 'function') {
        posts.then(function (_posts) {
          controller.set('model', _posts);
        });
      } else {
        controller.set('model', posts);
      }
    }
  },

  deleteRecord: function (operation) {
    if (operation.path.split('/')[1] === 'posts') {
      this._deleteRecord(operation);
    }
  }

  /* some code not included here */

});

Socket.IO

The push support is provided by an adapter on the server which uses Socket.IO and interacts directly with a document storage database.

server/lib/socket_adapter.js

/**
  @module app
  @submodule socket_adapter

  db adapter using Socket.io
**/

var db = require('./rethinkdb_adapter');
var debug = require('debug')('socket_adapter');
var config = require('../config')();

/**
  Exports setup function

  @param {Object} express server
  @return {Object} `io` socket.io instance
**/
module.exports = function(server, sessionMiddleware) {

  // options: https://github.com/Automattic/engine.io#methods-1
  var options = {
    'transports': ['websocket', 'polling'],
    'cookie': 'connect.sid'
  };

  var io = require('socket.io')(server, options);

  io.use(function(socket, next) {
    sessionMiddleware(socket.request, socket.request.res, next);
  });

  io.on('connection', function (socket) {
    // Simple sanity check for client to confirm socket is working
    socket.emit('hello', { hello: 'world' });
    socket.on('talk-to-me', function (data, cb) {
      cb(data);
    });

    socket.on('isLoggedIn', function (callback) {
      var user = socket.request.session.user;
      if (!!user) { debug('isLogggedIn', user); }
      callback(!!user);
    });

    socket.on('login', function (credentials, callback) {
      credentials = JSON.parse(credentials);
      if (!credentials) {
        return callback(false);
      }
      var uname = credentials.username;
      var pword = credentials.password;
      var session = socket.request.session;
      if (uname === config.admin.username && pword === config.admin.password) {
        session.user = uname;
        debug('login: %s', session.user);
        session.save();
        callback(true);
      }
    });

    socket.on('logout', function (callback) {
      socket.request.session = null;
      callback(true);
    });

    socket.on('findQuery', findQuery);

    socket.on('find', find);

    socket.on('patch', function (operation, callback) {
      if (!socket.request.session.user) {
        debug('patch tried without user session');
        return callback(JSON.stringify({errors: ["Login Required"]}));
      }
      var _callback = function (error, payload) {
        if (error) {
          debug('Patch Error!', error);
          callback({errors: error});
        } else {
          payload = payload || JSON.stringify({code: 204});
          callback(payload);
          debug('didPatch...', operation, payload);
          socket.broadcast.emit('didPatch', operation);
        }
      };
      patch(operation, _callback);
    });

    socket.on('disconnect', function () {
      io.emit('error', 'User disconnected');
    });
  });

  return io;
};

/**
  findQuery - uses query to find resources

  @param {String} JSON strigified query object `resource` property is required
  @param {Function} callback
  @private
**/
function findQuery(query, callback) {
  debug('findQuery...', query);
  if (typeof query === 'string') {
    query = JSON.parse(query);
  }
  var resource = query.resource;
  delete query.resource;
  var _cb = callback;
  db.findQuery(resource, query, function (err, payload) {
    if (err) {
      debug(err);
      payload = { errors: { code: 500, error: 'Server failure' } };
    }
    _cb(payload);
  });
}

/**
  find - uses query to find resources by id or slug

  @param {String} JSON strigified query object requires `resource`, `id` properties
  @param {Function} callback
  @private
**/
function find(query, callback) {
  debug('find...', query);
  if (typeof query === 'string') {
    query = JSON.parse(query);
  }
  var resource = query.resource;
  delete query.resource;
  var id = query.id;
  delete query.id;
  var _cb = callback;
  var errorPayload = { errors: { code: 500, error: 'Server failure' } };
  db.find(resource, id, function (err, payload) {
    if (err) {
      _cb(errorPayload);
    } else {
      if (payload[resource] !== null) {
        _cb(payload);
      } else {
        db.findBySlug(resource, id, function (err, payload) {
          if (err) {
            _cb(errorPayload);
          } else {
            if (payload[resource] !== null) {
              _cb(payload);
            } else {
              _cb({ errors: { code: 404, error: 'Not Found' } });
            }
          }
        });
      }
    }
  });
}

function patch(operation, callback) {
  debug('patch...', operation);
  if (typeof operation === 'string') {
    operation = JSON.parse(operation);
  }
  var path = operation.path.split('/');
  var type = path[1];
  var id = path[2];
  var prop = path[3]; // REVIEW support sub-path?
  if (prop === 'links') {
    var link = path[4];
    patchLinks(type, id, link, operation, callback);
  } else if (operation.op === 'replace') {
    var payload = {};
    payload[prop] = operation.value;
    db.updateRecord(type, id, payload, callback);
  } else if (operation.op === 'remove') {
    db.deleteRecord(type, id, callback);
  } if (operation.op === 'add') {
    db.createRecord(type, operation.value, callback);
  }
}

function patchLinks(type, id, linkName, operation, callback) {
  debug('patchLinks...', type, id, linkName, operation);
  find({resource: type, id: id}, function (record) {
    if (!record || record && record.errors) {
      var errors = (record) ? record.errors : [];
      debug('Error finding resource for patchLinks action', errors);
      callback(errors);
    } else {
      var path = operation.path.split(linkName);
      path = (path) ? path[1] : null;
      var value = operation.value;
      var op = operation.op;
      var payload = record[type];
      payload.links = payload.links || {};
      payload.links[linkName] = payload.links[linkName] || [];
      if (op === 'add' && path.match(/\-$/) !== null && value) {
        payload.links[linkName].push(value);
      } else if (value && op === 'add' || op === 'replace') {
        payload.links[linkName] = value;
      } else if (op === 'remove') {
        var linkId = path.split('/');
        if (linkId.length > 1) {
          linkId = linkId[1];
          var idx = payload.links[linkName].indexOf(linkId);
          payload.links[linkName].splice(idx, 1);
        } else {
          payload.links[linkName] = null;
        }
      }
      db.updateRecord(type, id, {links: payload.links}, callback);
    }
  });
}

// TODO Use Ember.Inflector or other Inflector?
function singularize(name) {
  return name.slice(0, name.length - 1);
}

function pluralize(name) {
  return name + 's';
}

We are EmberConf 2014

2014-03-30T00:00:00+00:00

I may have missed a few segments of the presentations or been distracted during a few talks so I apologize in advance to the speakers if I have not included notes from your talks in this article. I can honestly say that I did find value in every presentation. (That has not always been the case when I've attended a conference.) The headings I use in this article may not match the speakers presentation titles. This article captures what I learned from the conference so I've taken liberty to create new headings and combine common topics; besides "Keynote" as a heading lacks context ;)

Speed, Efficiency, Productivity...

The take away is that by adopting the conventions of the Ember.js framework a developer gets "Speed, Efficiency, Productivity..." by default.

Flows are just as important as screens. With Ember you control (users') flow through your Web application using the Router. The routing features that Ember provides are more than just URLs. This was proven by more that one presentation on the topic of routing. There was a very impressive presentation later on fnd.io which used every model known by the application to route any type of object that a search application could identify. And another presentation that injected additional logic to manage transitions between complex states in a banking like Web application.

"Get rid of sinkholes, use commonality" Routing provides strong defaults in how to organize flow and state in a true Web application.

My experience with the router has been that once I grok how to use it the next time I start an application the productivity is noticeable and satisfying. The same can be said of other conventions that Ember.js provides. The concepts in the router are simple and complex at the same time; but the net take away is that using this common way of managing flow and state yields productivity. There is a reward for investing time in learning and using the conventions of routing for a browser application.

Frameworks are Designed to Nudge You in the Right Direction

The Vine app for sharing videos is built with Ember and it turns out that using many many videos on a page can be a bit of a challenge in a Web application; especially for creating a snappy user experience. Data visualization can be a complex chore for a team with varying strengths. Ember Component can be used to encapsulate complexity of using a 3rd party library like D3 for pretty data on screen. Application code can be built with more than one recipe to deliver a different experience by only changing the dependency for a router file.

I find that once I get the concepts of using components to isolate behavior and reuse it in various contexts that is a very powerful and valuable convention. And Web components are in the not so far off future already.

Welcome to the future :) (Not really.) But I do think that using Ember components is a peek into what will likely be a shared way build reusable components on the Web in general.

Contributing

The contributing presentation provided great details on how to get involved and help the community. The TL;DR summary is do try to make it easy for the core team to help you help the community.

It would be a good idea to subscribe to the security email list. Also you can enable feature flags in the beta/release channels of Ember but DON'T DO IT. The fixes to bugs found in new features will not be patched onto those release channels. It's best to use Canary to try and contribute to new features or bugs.

I think this talk exposed a common and priceless value of the Ember community in general... there is a huge value that is given by the core team members as well as those who decide to contribute and any level. This value is sacrificial and comes at a very high price, the time belonging to loved ones. I would conclude that there is a genuine passion for the project itself as well as the people who use the project's codebases.

The fast track to helping with the community is an attitude of others first. Adopting the conventions on how to commit code for a feature or a bug makes peoples lives better.

Love Trolls

Trolling is common on the interwebs, love trolling not as much. Well, unless you're at EmberConf.

The phase "Just Stop" is all it takes to find common ground between such a wide variety of world views within the development community.

I think this expression represents a care for humans in general, like... "Hey my friend, please don't make a fool of yourself" or, "Hey I just need you to know I'm not ok with that, can we move on to common ground".

Just as we are capable of introducing bugs to a codebase, we are all capable of hurting others. More important than an awesome framework are awesome people who aren't left out.

This idea rises above political correctness and just puts others before self; a valuable ethic for any community. And, it's found in the Ember community.

Data Persistence

...A Hard Problem

Data Transformation
Asynchrony
Caching
Locality
Relationships

The above are the objectives that Ember Data achieves to solve for Web applications. However it's not as easy as one would expect. When all the above happen together, there be dragons.

The premise of the Ember Data project are...

Easy problems should be locked down less often (give developers more flexibility)
Lock down API for hard problem

...You're Building A Distributed Computing System

We received a lecture on math theory related to distributed computing systems. There is a trade-off between availability and consistency. Safety (always right) or liveness (eventually there), how would you like your data? A good goal is to build weak consistency with higher availability. Something to consider is that once you send data to a client it immediately becomes a cache of that data (and most likely to become stale quickly).

I forgot how much I enjoy mathematics and theory, it was refreshing to think about the client-server data caching problem from this perspective. A server-based data driven application should know how to manage the data cache sent to it's clients, or perhaps a client application should know it's contract for the data it receives. One thing I'd like to work on is using sockets to manage multiple data stores (caches): perhaps a memory store, a local store (disc) and a remote store communicating with clients via Web sockets.

Tooling: Build Your App with Broccoli

Remember those little veggie trees? Your application's modules (files) live in trees (folders), the broccoli build library only knows about trees, read, read, and cleanup. The API is small leaving room for adding specific sets of functionality by writing plugins. You can have many plugins and build targets as well as a mergeTrees method to package up your application.

Broccoli is for working with files in your repository it's not a task runner. Integration within your tool set can be achieved as you choose, perhaps a grunt task kick off the build.

The benefit of using broccoli to build your application is... only files with a change in last modified date are re-processed so the result a super speedy build with each change; even when you have a large set of files (modules) composing your application.

Broccoli is the newest choice of tooling for generating a build for a JavaScript application. And its likely the fastest too. What a considerable contribution to the Ember community. I am looking forward to a speed boost in my development cycles.

Animation and Transitions, Janky Not Allowed

Why animate? Just because developers understand crazy abstractions, not everyone is "freakish like that". Providing some direction to flow by animating a change gives users a sense of where they are navigating to and how to go back to where they've been. If every link just immediately appeared users would have a limited sense of what the application's flow is. As users transition between screens or even parts of a screen, animation provides some directional context that makes the application feel more natural.

Using Ember there are two types of animations. One is a simple animation within a single route, done with CSS (based on class attributes that belong to a component on the screen). The second is a complex animation between route transitions.

To avoid jankiness in an Ember application it is a good idea to silence browser events so that your application is not listening or responding to irrelevant event handlers. One solution is to add back in needed event handlers by wrapping the code needing the events with a component which does listen for the event. A couple concepts to hook into so wrangle complex animations are using willTransition and also named outlets. For thinks like a modal using query-params-new allows you to bypass router and reuse the same modal anywhere.

Angular's Transclusion is not a Misnomer

Transclusion is the inclusion of one thing into something else. It's like using an Ember.Component instance with yield. I think the goal of using a directive with transclusion is to encapsulate HTML, CSS and JavaScript, to roll your own reusable widgets. Perhaps a dependent select box is a good example of a Web Component that would utilize Angular directives and transclusion; alternatively, an Ember.Component would be used for the same.

I'm not sure that I really know why there was a Talk on Angular other than to call out that in some cases we are working on common solutions in both development communities; however the techniques and naming may be quite different to achieve the same goal. I did like how the speaker tackled a couple topics which those in the Ember community have poked fun at perhaps at the expense of those in the Angular community. At the end of the day we're all JavaScript developers.

I think that the speaker on the Angular topic was quite brave to take on this topic for a decidedly "Ember" audience. For me the take away is that there are different strokes for different folks; and that's just fine; perhaps we'll learn something from each other of find some common ground in an area like Web components.

Doing Better with Available API's Using Ember.js

Searching the iTunes Music Store and App store can be at times not so great of an experience, especially on the Web. Apple's API's to query media types make a good source to build an application built without a backend, and perhaps do a better job on the Web than Apple has done. Fnd.io is the example that takes on Apple's search experience on the Web platform head on.

A talk was presented on how to model iTunes Media using Mixins and Ember Data. Using composition to model various data types found in the stores' API gave some flexibility to identify types from an API where it's not always clear what things actually are typed as. The fnd.io site focuses on product search rather than document search.

The value Ember provided was beautiful URLs with a fast product search tool that rivals any experience searching for iTunes and App store products on the web.

"Tapas with Ember" (Brunch recipe) may have been a result of this project which uses Brunch for a build tool.

2X-3X Performance Boost Coming Soon: HTMLBars

The project is still in an alpha stage; though it was not possible to release an alpha version for EmberConf2014 serious effort was made to do so. The promise is 2X-3X times speed gains once HTMLBars ships. I'm looking forward to kissing metamorphs good-bye and saying hello to "fast" with HTMLBars.

Some of the differences in HTMLBars are:

Unlike Handlebars HTMLBars understands your markup
Builds DOM fragments instead of Strings
No more script tags (MetaMorphs)
Large lists are much more performance, as the source uses clone
Binding update order
Stop recursion / Limits re-render (anti-pattern)
Simplicity in the markup, removes the need for helpers like bind-attr

Ultimately the goal of HTMLBars is to step into a simpler primitive.

I could tell that the team working on the project was a bit spent and also sensed that a significant sacrifice of personal time has been invested in toward increased performance for the Ember community. Thanks for the hard work guys; and thanks to your loved ones for leasing you to the Ember community for this project.

Reusable Views: Components

A couple questions to ask when considering to create a component are:

Does it have behavior?
Does it need to use a specific class or action?

Good examples are form with input type=submit; and select with option. The behavior of a form change when there is a submit input element.

Some advice given regarding building with Ember:

Don't build large components with big templates
Do use composite components; lean on using no templates
Test and develop with dynamic data
Build native Ember components rather then using Bootstrap
Child components should inform parent they exist to change behavior, willInsertElement is a good hook to use

ic-tabs and ic-menu component micro-libraries were demonstrated. I good goal for an architect of an application is to measure success by the frequency that your team asks how to use the apis provided to the application developers. Using components to abstract complexity and provide consistency may reduce the amount of support needed. Also using method names that define the action and combining the .on('eventName') extension to the method helps communicate the how and why of the methods contained in your components. Thank you Instructure team, for contributing these components to the Ember community.

Ember AppKit Gives Birth to Ember CLI

ember-cli is the child project conceived by the bleeding edge work done on Ember App Kit (EAK). While creating new tooling for Ember projects, the EAK project tackled various problems and paved the way to abstract many solutions. Using Ember App Kit allows developers to ship real stuff and also experiment with solutions at the same time. It's my opinion that good things come from real apps. So, thank you to those to felt comfortable living on the bleeding edge, your pains have born ember-cli.

Some of the byproducts of the EAK project are:

Problem: Coupling / Solution: Inversion of control, resolver knows/finds in container
Problem: Assemble Source / Solution: Build Tooling
Problem: Upgrade nightmares / Solution: Better abstractions, hide nearly all the complexity
Problem: Copious bugs / Solution: Thorough test suite
Problem: Build Stability / Solution: Tool choice, build pipeline with Broccoli

"When a problem comes along you must whip it" - My perception of EAK's theme

ember-cli is the single place to focus using the solutions above. You can help too! A call to action was echoed from the podium, "we need a good story for fingerprinting". (Perhaps using md5 hash in asset filenames and updating links to assets using the same hash.) This is not a new problem but needs a good story for JavaScript applications.

Perhaps the most noticeable result of EAK was the adoption of using es6 modules in Ember applications today. (Welcome to the future.)

Give Back, You Can Make a Difference

You can teach a web development class as long as your students can type. DeVaris Brown did just that, and proved that it's possible to teach 16 to 19 year old kids Web development. His story was amazing, heartfelt and received with many cheers and tears alike. As developers we have a highly valuable skill and DeVaris has carved out curriculum for teaching the basic building blocks of Web development to kids. Sounds like madness no? Well for Devaris there were more than a few magical moments. He said that the kids "liked the magic of the Ember.js framework". This was caught after kids asked if there was another way beside copy and paste to create Web pages. Aha, you can build dynamic web pages with Ember.js; magic right! It appears so.

What Devaris strived to do was make a difference for underprivileged kids using what he knows. He learning that the basic requirement for accepting students is the ability to type; he discovered that people can do good in their communities. The kids worked on a project to support connecting people, foodbanks, and food providers; how awesome that is!

Imagine explaining the DOM to kids and teaching HTML, CSS, and JavaScript basics. Devaris committed to sharing his curriculum (a collection of Markdown files) on github. He also mentioned that he found typing.io to be a good tool to help with the typing challenges, "kids only use a few characters while texting".

I was very impressed with how Devaris hung in there until that aha moment when the kids caught it; Devaris was like "Thank you Jesus!" and we all were clapping and crying. Nice work Devaris, you made a difference and inspired others to do the same.

Who Owns Query Params, Router or Controller?

Mr. Router thought that the Router should own query params, yet there was a convincing case for the Controller to manage these variables. query-params-new has a controller-centric API.

There is a problem to solve, controller property stickiness, perhaps a new primitive "model dependent state" may be the resolution. This concept (vaporware at this point in time) would scope controller state to a model instance. The issue of controller stickiness is not unique to query-params.

My take away is that things that seem simple can become hard; and until a feature becomes stable it remains behind a feature flag like query-params-new.

Ember.js Testing is Not Hard, It's Unknown

The ember-qunit project has a great concept that makes testing an Ember application much easier that is has been in the past. The resolver is used to pluck out the subject of the test into an new container which sets up a sandbox for unit testing.

Ember's testing backstory (the happy path using QUnit) was presented with funny slides. It's been a year since we've had the ember-testing package, and there has been additional helpers added to the project as well.

Integration testing is fairy straight forward and now with ember-qunit unit testing has an improved story. To setup and insert the test helpers call setupForTesting() and injectTestHelpers() on your application namespace. The (global) helpers are visit, click, fillIn, find, findWithAssert, keyEvent, andThen; the newest are: triggerEvent, currentRouteName. See the API docs for more info on using the helpers.

Perhaps the best way to get started with reading example tests:

And also, don't forget to checkout the new guide in progress:

Initial PR for ember testing guide redux

I had taken a stab a writing a testing guide awhile back, website/pull/610, which I closed out as the testing story was still a bit painful and we really needed something like ember-qunit to evolve and simplify isolating tests.

Thanks to everyone involved in helping the Ember testing story evolve from painful to simple; I'm looking forward to an awesome testing guide.

Controlling Flow in the Router

Traversing routes to enforce a specific flow event with optional flows can be achieved. The example presented was a login flow to a backing application with various options that depend on the user's choices made while stepping through this flow.

When designing flows, start by a) listing every single permutation, b) inventory all routes, c) list linear paths, d) contain state modification on nodes, by describing state on each node; finally e) traverse backwards (back button). The route's replaceWith method is well suited for using custom flow.

The project presented is ember-flows; which is a great example of extending functionality by injecting an object into your application container.

The object used in to define flow strategy has properties for from (route path), to (route path), weight (number), and conditions (Array). And the hook used to enforce the flow is beforeModel like so this.get('flow').check();. The flow object injected into the application can make a choice about when to change paths in the router using replaceWith. Well hopefully I grokked it correctly see the ember-flows project if you'd like the details.

Again I's great to know that there are solutions that are essentially plugin-able to being shared that are based on solutions to complex problems.

Snappy Performance Makes Users Happy

How fast is fast?

16ms : 60 fps is Fast
300ms: is Snappy
1s+ is like I'm waiting
10s+ is bad, you just lost a visitor

When working with Ember applications remember that the Ember part is a subset of the code that affects Web performance (page speed). A good goal is to provide a snappy response which is under 1 second; about 300 milliseconds. When measuring page speed, the visual performance, how a visitor perceives responsiveness should be considered as well. Recording a video of the page load and marking when the page looks ready is an indicator that should be weighted along other speed measurements like first load time, document ready, etc.

Methodology

Gather Facts
Analyze and Theorize
Change a Single Thing
Confirm your Theory

Also when testing it's a good idea to disable browser extensions. "Browser Networking" is a book we should all own and reference. Getting familiar with the browser's development tools for performance is what is needed to analyze and test performance optimizations. The flame chart in a render snapshot can expose problematic cycles of re-rendering and performance sinkholes. Also property change notifications can affect performance. Instead of looping over a collection and inserting or setting properties during each iteration, look for ways to complete enumerations then make an assignment of a collection to an object property.

I think it was mentioned that there should be a book on this topic coming soon. See the speakers post on the talk here: Performance in Ember Apps

Evolution: The Extensible Web

Open source is awesome! Remember when Netscape pushed it's source code to the Web. That was a Revolution. The JavaScript development lifecycle is still evolving.

Focus: don't re-invent the universe
Consistency: keep unified development model
Adoption: gradual adoption with polyfills, compilers

One example of evolution is the use of "use strict"; developers can opt-in. But we know opt-out is better, so ES6 modules are strict by default.

The cycle of evolution is: a) study the text then b) interpret the text, next a) study the text, and b) interpret the text. Repeat A then B until the delta between the two (study/interpret) becomes small enough to ship. As developers we like to move fast and break things. The loop we work in is: build, ship, evaluate, repeat while it's all good. When talking about standards we need to add a step, "don't break the web". So the cycle becomes: build, ship, evaluate, oh, don't break the web then repeat while everything is still good.

The aim of the Extensible Web is to tighten the feedback loop between the editors of web standards and web developers. It's critical for developers to be involved with browser vendors during this cycle. That's why we try new thinks and sometimes there's some breakage until those deltas become closer.

The key story of The Extensible Web is:

Add missing primitives
Enable userland polyfills & compilers
Work together to design the future

One think I noticed about the Ember community was the adoption of ES6 modules. I've seen some breakage in Ember Canary while this shift has been happening. It actually bothered me a bit I was thinking aren't there bigger fish to fry, like data persistence? After this talk I see how these minor growing pains do contribute to the development community as a whole. We've been hungry for modules and they've just about landed in browserland for new we're using a transpiler to AMD but this exercise not only shows browser vendors the value of modules it gives us a chance to put the concepts into flight as the standard is adopted.

Just Stop

This topic was introduced at the onset of the conference; and I did already touch on it once; I'd like to emphasize the importance of the community. The core team of the Ember community came to an agreement about what rules we should adopt as a development community.

In practice... if someone says something that offends you, do speak up for yourself by saying "Just stop." Likewise, if a friend says something that you think might offend another friend, we're all friends by the way, in case you didn't know, speak up for your friend by saying "Just stop."

Simple isn't it.

Rules were made to be broken right, well we're all human and I think that is the point. We are all capable of saying something we might regret so when we adopt to play by this rule we can help our community flourish and also benefit from the results of a thriving development community that is basically re-inventing the Web platform.

Whether you are a religious Jew, someone who doesn't drink, are born of a minority race, or you belong to any facet that composes a diverse community of people having a varying (even conflicting) set of world views; you can show respect toward others, so can I. I really like this concept of thinking about others first. I think that this idea is already engrained within the Ember community. Just think about how much sacrifice has already been poured into the framework that we use; and together iterate and improve upon.

Post Hoc (After the Buzz Settles)

The Ember community is more than a group of people working on a framework; the community is composed of professionals, hackers, entire families (contributors are leased by their loved ones to the community). We're not born of the same country, same blood or race, not in the same timezone; nor do we have the same native language. But we all write code for the Web platform. We have a common goal to make the Web a better platform and we use Ember.js to do it.

Ciao, my extended Ember family, talk to you on IRC. Please do comment on this post if you'd like to share your thoughts.

Links

Thanks to Ember Weekly Issue 51 for collecting the buzz on EmberConf 2014...

Other EmberConf 2014 Notes/Summaries

EmberConf 2014 Presentations

Day 1

Day 2

pixelhandler.dev

Systems of Building, Not Building Systems

Systems of Building, Not Building Systems

Containment Enables Quality

Containing Conventions

Containing Attention

Containing Risk

In Practice: Outside-In Development with AI

The Practice

Turning Your Spreadsheet Budget into a High-Performance Gearbox

Turning Your Spreadsheet Budget into a High-Performance Gearbox

The Spreadsheet Trap

What If You Could Keep the Control and Ditch the Chores?

The Story Behind the Code

Feature-by-Feature: Spreadsheet to Gnar.li Budget

How the Workflow Actually Feels

The Gearbox Metaphor

Learn the System: The "Every Dollar's Job" Course

Getting Started

TL;DR

Next Steps

Remote Work

EmberJS2018 – A Few Suggestions

Community

Marketing

Standards

Bugs

Documentation

Ember.Object

A11y

Routing

Code splitting

Wrap up

Change, everything will be fine

Working Remote, Somewhere Between Bliss & Distress

Managing Developer Happiness

Developing Ember Addons: Next Generation CSS with PostCSS

My Use Cases (Wish List)

TLDR; see the repositories below:

PostCSS processing in an Ember CLI Addon

Next Generation CSS syntax using PostCSS

Ember.js: Handling Failure Using Route `error` Substates

Practical Example…

Take-Aways…

Further Reading…

My Battle with Data Persistence in Ember Apps

Project Wars

The Awakening

The Menace

Attack at the Agency

Big Data Strikes Back

The Return to the Agency

More Movie Puns

The Good Bad and the Ugly

The Bucket List

Back to the Present

A Battle Plan Emerges

A Man Can Change His Destiny

The Nitty Gritty

A Resource Object

An Adapter Object

A Serializer Object

A Cache Mixin

A Service Object

The Resource Blueprint

The Store Service Object

Take Aways

Start Today

JSON API Implementations

Practical: Deploy an Ember App with ember-cli-deploy

Lightning-Approach Workflow

Deploy an App with ember-cli-deploy

Firebase

Security & Rules

Setup an Ubuntu box with DigitalOcean

Install Node.js

Install Nginx

Config

Logs

Restart