21. May 2016

Code Koalas - Training Fridays

At Code Koalas we have brought back company lunch & training Friday's a couple of weeks ago. Everytime I make a presentation I'll post it here.

So why are we training people? That seems like a simple and dumb question but lots of companies don't invest in training. A good quote shared by Robert Manigold on this subject is:

CFO to CEO "What happens if we invest in developing our people and they leave us?" CEO "What happens if we don't, and they stay?"

McDonald's trains their employees how to make hamburgers, why shouldn't we train our people the proper way to program?

We came to a point in our company where we were able to make the decision of whether we start hiring more senior people or if we stick with junior people and teach & train them to be better. We decided that our company culture was one where we hire people who are forever learners. So then the next question was how do we encourage this?

We bought everyone a Kindle Paperwhite and give them a $50 a month (per person) for learning purposes. We said they can buy books, training videos, take people out to lunch who are smart basically just whatever it takes to get better.

We also every Friday have three presentations by team members to raise the general knowledge of everyone in the company. One person speaks about programming fundamentals like HTML, CSS, JavaScript or PHP. Another person speaks on something cool they learned or built this week and shows it off. The finally someone does a walkthrough or QA of a product that's supposed to be ready or almost ready for launch.

So far I think this has been going well and it will help raise everyone's knowledge and willingness to learn & grow.

:wq

*This blog was written while on narcotics as I crashed my motorcycle two days ago and I'm still recovering.

12. May 2016

Using Paragraphs to Weave a Beaufitul Content Tapestry

Paragraphs is a pretty great module for making landing pages or reusable components that get thrown in multiple spots on a site. I've been using it for probably 6+ months and we've used it on multiple pages in production. this session made me realize some thing I could do to do it better.

Presented by David Needham & Les Lim. View the slides! also view the session page on Drupalcon.

Why would you use Paragraphs? You want two columns on a page, but you want it to be easy for the author. Don't do HTML in the body field, that's a blog and not nice.

  • Blobs
    • bad for computers
    • bad for non-coders
    • bad for maintenance
  • Alternatices to blobs
    • fields & template files
      • extremly felxible
      • difficult to change
      • difficult for non-coders
    • fiels & display suite
      • UI interface available (to admins)
      • reusable templates
      • doesn't need custom code (but it helps)
    • panels
      • just don't it is the worst (my words, not theirs)
    • Paragraphs!

Paragraphs lets site builders weave together beautiful (good for people) pages using clean, ordered, XML-friendly (good for computers) content.

How Paragraphs work

  • Paragraphs replace the Body field
  • Many paragraph types can be created
  • each paragraph type can have a different set of fields
  • some examples of paragraph types:
    • "Content" Paragraphs
      • Text
      • Pull Quote
      • Image
      • Video
    • "Layout" Paragraphs
      • Aside
      • Accordion
      • Two Column
    • Pony
      • Specialized use cases for your particular client

At this point my mind has been blown on how to make Paragraphs easier for clients. Spliting layout & content into seperate things would be a great idea!

Using in Drupal 8

  • Installed
    • Paragraphs
    • Entity References Revisions

12. May 2016

Real Talk on Front End Performance

Well this session started off with the presenter Josh Koenig singing so you know it's good. See the session page.

Time is holy and every moment previous! We have been trending in the wrong direction with web performance.

All the wonderful things you do on the backend don't matter if your site's front end sucks!

Your server response time does not matter if your user experience is super sucky.

Performance is moving up the stack.

Having websites perform faster means everyone wins and mkaes more money, that is important and stake holders need to know this.

How fast?

All the research says there is a 100ms threshold, 1s theshold & 10s threshold. The 100ms threshold is awesome! It makes people feel like they're directly interacting with the product. The 1s time theshold is pretty good, it doesn't break the train of thought. There is then the 10s theshold, is as far as you can go before people just leave, you lost them!

Delays like this

  • 38% increase in heart-rate
  • compraable to watching a horror movie
  • significantly more stress than waiting in line at a store

If this was easy I wouldn't be here giving this talk to you.

HTTP2 is awesome, but it's not pixie dust!

You cannot just throw varnish on something and call it good.

REAL TALK! You cannot beat the speed of light. A trip from SF to NY = ~4000km, light is 66% speed in fiber, 42ms round trip, ping time 81ms. So you're already at your 100ms tipping point just with how fast the internet could be in best case scenario.

Most people are on mobile on crappy internet, and you're ignoring them!

The average web page is now the size of Doom... What the heck is wrong with people?

30+ images, 15_ scripts, 4+ stylesheets.

Don't just create an average website, Make the internet great again!

The 1% know this matters. The top 10% of websites aren't trending back down in file size because they know it's important.

We are the 99% of websites (most likely) we need to know about this and do the trend too.

Percieved performance is the only performance we should actually care about. If the server is slow, you're screwed, but most likely it's your frontend that's bloated.

The DOM is your dominion, we are responsibilty for what goes down the wire. Don't let Drupal put 1000 divs!

Need to obtimize your images!

Even when developing locally you should run on 3G for a little while just to know how it works.

Queueing on Chrome means you hit your limit of how many things you could download at the same time.

You cannot beat the speed of light, but you can use a CDN!

HTTP2, it doesn't resolve us of all of our sins, but it is great!

  • http2
    • http1 is a bunch of back and forth
    • http2 request pipelining and everything just dumps through that.
    • we can now push at the protocol level

BigPipe! Most sites on Drupal 8 will be able to take advantage of the performance increases without having to do too much.

Previously before BigPipe Drupal had to render out the entire page before the user could see it. With BigPipe we can send out the parts that are cached immediately and then send the slow sutff later.

Drupal 7 & the web in general is a jungle out there, so many decisions to make and so few good instructions. Drupal 8 will give us much more to go on, there will be structure. You can stop wasting your time on a bunch of stupid crap.

None of this is free. (paying for things is good, we're not Bernie supporters here)

Checklist!

  • Set performance goals
  • analyze DOM render waterfall
  • mobile perormance testing
  • inventory and cost page elements
  • target next stable state
  • mesaure change after releases

Get good data & analyze it!

We are all frontend developers!

11. May 2016

The New New PHP

PHP 7, it's new, released last fall and makes life better. PHP 6 never happened it was just PHP 5.3. This talk was by Larry Garfield of Platform.sh

What is new?

One of the most important releases in a decade, biggest change since PHP 5. You can view the slides to this presentation on his website

  1. Return Types
    • As of PHP 7 we have return types.
    • not nullable (good)
      • helps with error handling because Type system will handle weird edge cases
    • Returning false on error is a big 'screw you' to your users
  2. Type Specs
    • full type list with new new type specs
      • int *new
      • float *new
      • string *new
      • bool *new
      • array
      • callable
      • any class name
    • random zip codes need to be strings because some start with 0 and integers cannot start with 0
    • Strict vs Weak mode
      • in Weak by default
        • string -> int may E_NOTICE
      • Strict
        • ```php

        declare(strict_types=1);

  class Address inplements AddressInterface {
    public function _construct(string $street, string $city, string $state) {
      // ...
    }
    public function getZip() :string {
      // ...
    }
  }
  ```
  - Int convers to float automatically if needed.
  - When should you use strict types
    - 90% of the time
    - (everywhere except input)
      - on input everything is a string to start
  - Also, Documentation
    - Stict typing makes it so you don't need too much documentation
  1. T_SPACESHIP <=>
    • Does cool stuff
  2. NULL coalesce!
    • $username = $username ?? 'Anyonmous';
      • returns username is it is defined & not null.
      • used to be: $username = isset($username) && !is_null($username) ?: 'Anyonymous';
  3. CSPRNG! (Crypotgraphically Secure Psedudo-...)
    • Cryptography is hard!
    • rand() isn't actually random - DONT USE THIS FOR CRYPTOGRAPHY!
    • mctypt() don't use that either
    • openssl is hard to use
    • $junk = random_bytes(16);
    • $val = random)int(1, 100);
    • Only use random_byes() random_int()
  4. Fakes
    • Mocking is hard
    • Fakes are easy
  5. Type Errors
    • Fatal errors Suck!
    • Recoverable errors... aren't actually recoverable
    • You can actually catch type errors

    -

     try {
       // ...
     }
     catch (\ParseError $e) {
       // ...
     }
    
    • Exceptions: the user screwed up
    • Errors: the coder screwed up
  6. Expectations
    • Assertions suck
    • it makes assert not suck
  7. Generators
  8. Uniform varialbe syntax
    • Always Left-To-Right

    - ```php $foo()'bar'; [$obj1, $ob2][0]->prop; getStr(){0} $foo['bar']::$baz;

(...)['foo'];
(...)->foo;

(function() { ... })();
($obj->closure)();
```

PHP 7 is really really fast! How did it do that? Too nerdy... basically the PHP engine rewrote most of the PHP engine to be faster.

Drupal on PHP 7 is WAYY faster than Wordpress like 3+X faster! You can see 50% improvement in speed just by switching to PHP 7. If you take away nothing else from this switching to PHP 7 is the best performance boost you can do. PHP 7 is the most tested .0 release of PHP ever, it's safe.

PHP 7-ready hosts: 34 listed on phpversions.info/php-7 meaning you can run Drupal 8 on PHP 7 today!

PHP 7 is the correct way to run Drupal 8

11. May 2016

Creating a Lean, Mean Drupal 8 Theme

I figured I should learn the proper way to make a Drupal 8 theme so I can make other people do that! See the thing on the Drupalcon site

Drupal Themes Can be Complicated!

  • Why are Drupal themes complex?
  • Looking at our Drupal 8 theming toolset
  • Manging and limiting the complexity

Where does the complexity come from?

  • Drupal theming is very flexable
    • "of course Drupal can do this!"
    • Need lots of different layouts
    • We can add templates!
    • Need to add display logic
  • configuration interacts with the themes
  • implimenting a design (and designers suck!) ;)
    • Specific Design Specs?
    • We can write tons of CSS & JavaScript

Drupal Configuration is Powerful

We don't want to hard code everything in the theme.

  • Display content on the site in varying ways. View Modes
  • Layout Variations
  • Panels or Display Suite

Designers... yuck

Not all designers take into consideration the need for consitancy... for real!

  • Designers like inconsitent buttons
  • lots of random layouts
  • site have different layouts for the same type of content
  • specific page on the site will impliment the design slightly differently.

Enter Drupal 8

  • Libraries for loading CSS/JS
  • Twig Templating
  • More Templates!
  • Core Base themes: Calssy and Stable
  • Breakpoints
  • No Javascript by default
  • ...

So all our problems are solved!? No... you can still really screw things up if you suck at life.

Using your Frontend toolkit

  • Stable & Classy themes
    • Stable -
  • Libraries
    • `{{ attach_library('mytheme/search-styling') }}
    • Contextual CSS
      • global CSS
      • search css & js
      • store css & js
      • but don't go overboard
      • you already only loading that CSS on a single page or whatever there is no reason to be too specific
  • CSS + Sass
    • don't nest your selectors when you don't have to (like I've been saying you fools)
    • never use IDs you idiot
    • name your variables like a real person
    • review the CSS that gets generated to figure out how you could simplify your Sass
  • Templates
    • More templates than ever before!
      • mo' templates mo' problems. You of all people should understand that Stanley.
    • Don't create so many templates
    • Use Twig Blocks
      • Twig looks nice {{ content.links }} me like
  • Preprocess functions
    • Transform content before it gets rendered in templates
    • link one field to another
    • bad ways
      • formatting fields types
      • overrides that depend on a node ID
      • database calls to style past events and 'on tour' events differently
      • commerce line item calculations for currencies
      • hiding results of a view
    • preprocess
      • adding logic
      • adding new variables
      • when the output dependson the context
    • templates
      • adding classes
      • changing markup
  • View Modes
    • now in core
    • don't use view modes as a switch
      • are you a flipping idiot?
  • Theme settings
  • Regions
    • There are always extra ghost regions that never get used (guilty)
    • turn off regions that aren't being used

Closing

  • Be consistent
  • recognize complexity
    • Adding template suggestions to create more templates
    • adding a lot of classes and IDs
    • a libray for every page
  • How had will this be to maintain?
    • how much work will it be to apply this to a new content type?
    • what if the branding changes?
  • Documentation
    • regions that don't get displayed everywhere
    • preprocess functions that are complex
    • templates that are weird
    • comment you libraries to say why you added them
  • Refactor
    • if you come across a theme that's very complex, refactor it before it's too late
    • tools

11. May 2016

Offline-capable, decoupled Drupal 8 with React.js and React Native

Offline capabilities is great, it's awesome to be able to load your site while on internet then be off internet and it still work. Also using React. See full talk on Drupalcon site.

  • Deploy suite
    • Multiversion
    • Replication
    • Workspace
    • Deploy
    • RELAXed
  • ReactJS
    • tries to make life simple
  • Redux
    • unidirectional flow
      • store
      • componsent
      • reducer
        • only place store is editable
      • action
  • Architecture overview
    • server
      • drupal 8
      • RELAXed
    • browser
      • PouchDB
      • React web app
  • Demo
  • What we learned
    • REALXed + PouchDB
      • powerful combination
      • full DB availalbe in the browser
      • up to 50MB on phone
    • No easy features from drupal
      • everything in the webapp is built from scratch so you lose a lot of what Drupal does for you
    • Separate styling setup
      • Reactjs has it's own special way of stlying
      • then React Native has even weirder styling
    • Little reusability between web and native apps
    • Distribution ES2015 libraries is still painful
      • very painful
      • can be done, but it's not easy

10. May 2016

Ask Not What Open Source Can Do For You...

This talk was really good but I totally failed at taking notes for it.

You can watch this on the Drupalcon site! Talked about why being involved in open source is important.

Innersource use the lessons you've learned and then write about that and open source your lessons. So you're not giving away code but you're giving away lessons.

10. May 2016

DrupalCon New Orleans Driesnote

These are my notes while listening to Dries talk to open up Drupalcon New Orleans 2016. It is probably full of typos and weird things, I'll be cleaning this up later (hopefully).

Drupal 8

  • We actually realeased Drupal 8!
  • tripled contributors compared to Drupal 7
  • Also released Drupal 8.1 on time
  • Drupal 8 had 60,000 sites in 3 months, much faster than the 7 months it took for Drupal 7.
  • Port more modules!

Market Perspective

  • Richness
    • How many capabilities it has
  • Reach
    • How many people use it

Things like Angualar have a lot of reach, but not a ton of richness because it's new and doesn't have the thousands of APIs that Drupal has. Then there are things like enterprise solutions which are full of features but don't have much reach because they're so expensive. Drupal hopefully is moving towards somewhere in the middle, lots of reach and lots of richness.

Thousands of Drupal sites small & large:

  • Cisco built a customer service portal in Drupal and is saving tons of money from this solution.

Survey Says

2,900 people answered Dries survey from a very broad range of backgrounds. (should pull his blog to put here).

  • Who should we favor when making product decisions?
    • Mostly needed to improve for the non technical positions (content authors, site builders)

Proposed Initiatives

We will look at the survey data and look at our vision which is, build the leading platform to assemle the world's best digital experiences. Also need to look at the market, and have a discussion because collaboration is the essence of Drupal.

Lets propose some initiatives!

  • Media Initiative
    • Authors and editors need simple drag & drop media interfaces
  • Workflow Initiative
    • Give autohors and editors easy to use tools to share, review and approve, stage and collaborate on content before it's live.
    • This already has a team working on it. (link to blog about details)
  • Blocks and layout Initiative
    • Give sitebuilders an easier way to manage blocks & layouts. (totally missed what he said here, it was so fast).
  • Data Modeling tools Initiative
    • Add create content types & relationships super easy.
  • API-First Initiative
    • Integration with o... bleh
    • consolidate our rest api modules into one module to make things simpler.
    • Tesla powers their app using Drupal 8
  • Theme Componenet Library Initiative
    • wow he's really flying through these
    • Atomic design
  • Cross Channel
  • Orchestration

Showed some cool video about using Alexa to tie into a Drupal 8 site.

Need to think about editing content beyond pages.

Key Takeaways

  • Doing better than Drupal 7
  • We can reinvent ourselves and leapfrog over the competition.
  • We're playing the long game, but we will win.
  • We measure sucess not by a module making it to core, but wy it being easy for people to use.

10. May 2016

Becoming A TPM

This Drupalcon session is about managing your projects from a technical level. I'm not really a project manager but I'm trying to get better at managing large projects so I can make sure me and my developers make the right choices.

The Dos and Don'ts of Technical Project Mangement

Definition of a Project Manager - hearding cats. Hopefully the audio & slides get posted on the Drupalcon site.

Taming two lions:

  • Clients
    • need proper expectations
    • need educations
    • need big dreams brought to reality
      • firm empathy
  • Developers
    • Don't need distractions
    • Communicate red flags to the client
    • Need to fed words of encouragement

Technical Project Manager

  • competent folks who worked up the technical ranks
  • became project leader through wit and skill
  • able to communicate clearly to the non-technical
  • Time <> Money <> Features
  • Trying to figure the actual solution
  • Daily life
    • write a few status reports
    • compose a dozen emails, take more calls, chat on slack, send more emails
    • help team prioritize the latest set of technical issues
    • assist in identifying the problem at the root of several technical issues
    • employ one or more mitigation strategies for technical risks
    • !!! pull at least one person out of tempting rabbit-hole

Transitioning to a TPM

  • PM -> TPM
    • Understanding Drupal
      • Structure: Learn the Drupal Basics
      • Tools: How Development is done
      • Investigation: How to find the problem
    • Research
      • Dismantle to learn
      • Stack exchange, Stack overflow, drupal.org
      • Learn the fine art of boolean search operators
      • get thee to meetups! (I like this one as an idea for people to learn)
    • Hands-on Learning
      • Dive into techincal support
      • Create documentation
      • Assist during emergencies
      • Take notes, ask questions, take on tasks
  • Dev -> TPM
    • Mental shift of what a workday looks like
    • keep troubleshooting skills sharp
    • develop empathy and interpersonal skills
    • verbal judo (how to verbally de-escalate)
    • Challenges
      • Communicating clearly, non technically
      • document ALL THE THINGS
      • balancing thinking time vs talking time
        • Don't book meetings back to back
        • every half of meeting you have you need at least that much time to do the work
      • people coaching skills
        • Don't bully your developers

How to rock as a TPM

  • Quick tips
    • clear your inbox before EOD
    • understand priorities
    • stay close to the code
    • own your mistakes and your developer mistakes
    • be available, be calm
      • sometimes it's good to help out randomly late at night
    • double your estimate, both time & money
    • know when to ask for help
    • be humble, curious and unexpecting
    • know when to shut it off
  • Trust your gut
    • if you think we're going to be late, talk to them early.
  • Know how to read people
    • Face-to-face meetings are best with clients
  • Understand balance
    • balance clients needs with your developers skills

Getting into the weeds

  • Creating Tasks
    • understanding the problem
    • co-create the solution
    • write testing criteria to define done
    • determine estimate
    • check in on developer early
  • Create a User Story
  • Estimation
    • You're going to mess up a lot!
  • Toolbelt
    • Channels of communication
    • development methodologies
    • project management tools
    • automated reminders
      • set a reminder the second you say you'll do something at a particular time
    • testing, testing, testing
  • firefighters
    • intense client situations
    • budget / timeline / scope changes
    • magic words
    • keep calm

What does success look like?

You never know if you've made it, just like everything else in life.

Takeaway

They said "hey it's just a website" which is what we've been saying which is awesome! Being a TPM is a big thing, curious if this is sort of the role I'll be falling into or not. I did find some good things I'll be sharing with our product owners.

:wq

10. May 2016

Next-Level Drupal - Applied progressive decoupling with JavaScript

This is my first Drupal session I attended about decoupling Drupal from the frontend and using a JavaScript framework. This is interesting to me because I sit on the fence as a Acquia Certified Drupal Developer & a JavaScript developer who wants to do everything in JavaScript these days. Once again this is uploaded right after the session so probably has typos.

This talk was presented by:

  • Matt Davis (Mediacurrent)
  • John Kennedy (Acquia)
  • Preston So (Acquia)

This talks page is up on the Drupalcon site where there will probably be more good info.

Risks & Rewards

Decoupled Drupal is the process of employing a difference front end from Drupal's own (most often in a JavaScript or native application framework). This decopuled front end speaks to Drupal via RESTful API.

Using Drupal soley as a data serive is not a new concept; Services modules existed on Drupal 6 & 7. It can be used to do lots of things but we're really just focusing on the frontend today.

With Drupal's page model you have a full page refresh on every page load which is what using a JavaScript framework would solve.

Decoupled Drupal is important because you can use whatever language you want to accomplish your site. Freedom! You can have a single REST API that handles lots of different frontends.

Rewards

  • Seperation of concerns.
  • Content syndication (write once, publish everywhere)
  • Differentiated deelopement velocities between front and backend

Risks

  • Additional point of failure
  • No cross-site scripting or input sanitization
  • no in-place, in-context edition or administration
  • no layout and display management
  • no previewable content workflow
  • no modules affecting the front end
  • no system notifications
  • no BigPipe progressive loading or cache tags
  • no accessible markup or user experience benefits.
    • Drupal 8 has built in accessibility :)

When should you do this?

  • A site powering one of more other sites
  • a site powering one of more other applications
  • a site powering multiple sites or applications
  • you don't need the overhead of a decoupled architecture to power a standalone site or application

Why progessivly decouple Drupal

Don't use the JavaScript framework on it's own, put it in Drupal and let Drupal serve it up a bit too. Most of things are served up by Drupal with parts handled by a framework.

Rewards

  • no additional point of failutre
  • cross-site scripting protection
  • in-place , in context editing and administration
  • layout and display management
  • previewable content workflow
  • modules affecting the frontend
  • system notifications
  • BigPipe progressive loading and cache tags
  • accessible markup and user experience benefits.

Weather.com

Weather.com has been progressively decoupling Drupal for a couple years.

Before Drupal

  • 144 origin servers in three data centers
  • 50 million page views per day, half going to origin
  • forecasts for over 2.9 million locations
  • hundres of dynamic weather maps

considerations

  • performacne and caching
    • split page up into wrapper and panes
    • same wrapper from origin to everyone
      • header & footer is cached and same to everyone
    • edge computations using ESI
    • client-side rendering using Angular
  • frontend developer team in house
    • JavaScript developers want to write JavaScript
    • don't want to learn Drupal APIs
    • want to keep up with JavaScript
  • editional team
    • want intuitive ways to create pages
    • want to work indepndently

Solution

  • Presentation framework
    • mechanism for putting components into pages
    • supports Angular, PHP, and static templaces
    • modules served by Drupal or ESI
  • why panels?
    • variants and selection rules
    • reusable and exportable pans
    • context
    • drag & drop interface

Framewordk-agnostic progressive decopuling

Goals

  • give JavaScript developers flexibility
  • keep some guard rails in place
  • preserve strong editorial experience

in Drupal 8

  • Decoupled Blocks module in development
    • Built on top of blocks
    • Already supports Angualr 2 and React, more comingi
    • developers can tightly copule component functionality to Drupal's exising system of rendered entities.

Final thoughts

My notes on this were pretty rough, but this semes like what we need to start doing on our sites, wanted to for awhile and it's the mix people now talk about where you get server & client rendering. The module they're working on seems cool because you can make rich dynamic blocks and people can just throw them wherever they want on the page.