Jump to content

User:Pablo Grass (WMDE)/conferences/IJS2019 Munich/day2

From Wikitech

Day 2 was the first "real" coference day started with an introduction on the co-existence of PHP and JS and the quite different paths of development/adoption the two languages took.

I happened to learn that zend server is still around (was an enterprise user back at version 6) and shared some anecdotes with the consultant visiting the PHP part of the conference.

Key note, Jessica Mauerhan @jessicamauerhan, Skillshare

An emotional plea to make so called "soft skills" a hard requirement, and to practice and demand them.

  • personal history of education, stack overflow
  • "RTFM" often defended as "teaching people to ask better questions"
  • anti-social condecending attitude is what non-programmers think when they hear this
  • "in the tech community it has been accepted for too long that good programmers have to/can be shitty human beings"
  • Linus Torvalds mentioned repeatedly
  • explains her own shortcomings (e.g. rejecting unit testing) in earlier days
  • "rise of the expert beginner" (reaching a level and then stuck in a bubble) is referenced
  • best people know how to share w/o making you feel like an idiot
  • powerful example of building a vue app (in 45mins) to detect blinks in a post-coma patient
    • poor quality code
    • yet got the job done
  • we get angry at people who
    • we think are a threat
    • waste our time
    • question the way we think about the world
  • we tend to become defensive in areas where we are the most insecure
  • belittling words "simple, just, easy" are brought up
  • people with empathy and compassion acting as a role model can make a difference
  • "it's easier to be kind even if it takes 3 times as long [...] as it's a long-term investment"
  • empathy is: understand others' emotion (cognitive empathy), and the ability to react accordingly
  • (self-dignosed?) aphantasia
  • efficiency types could think: "does me being mean to someone solve a problem?"

Design Systems: Developer Point of View, Yael Balla, Amenity Analytics

  • "the big promise of the UI world"
  • compares design system with LEGO: consistency, documentation
  • design systems help designers and developers not "re-invent the wheel" time and again
  • design system definitions
    • standards
    • documentation
    • implementation
  • product can't be the source of truth b/c it evolves over time and has intentional inconsistencies
  • design system is the source of truth of how we want things to behave - today
  • shows many examples listed at https://designsystemsrepo.com/design-systems (no "wiki" on there!)
  • IBM's carbon as example
  • admits setting it up is quite an investment
  • still thinks having a design system is worthwhile for small organizations
  • steps for adoption
    • alignment inside the org
      • buy-in across dev, design, product
      • inventory of what is, build consensus of what is the goal
    • scope the project
      • deliverables: framework-agnostic CSS file, component lib, ...
      • governance model: shared effort or dedicated team
    • define building blocks
      • atoms = "named ???"
      • "design tokens" = property value pairs with semantic meaning (e.g. $color-success: $color-green;)
    • implement the components
      • not every shared component should be part of the design library - that should be a dedicated lib to share across projects
    • share across org
      • use package manager, apply semver
  • honorable mention of 'styled-system' for selectively adding style types (like mix-ins) in react components
  • "no more one-offs"
  • actually started by using/wrapping an existing component library and continuously adding customization
    • naturally, there needs to be a lot of common ground
    • be sure to put all customizations in one place
  • demo: "theming" (via a config) material ui for react
  • advocates designer base their suggestions on what is currently possible (source of truth), not some photoshop illusion
  • storybook mentioned alongside doxy, styleguidist
  • demo: storybook, incl addon-info
  • we are not done thought - maintaining the design system is an iterative process
    • ensure shared language (component naming, ...) is practiced
  • recommends (visual) testing, building change notification to the design team into CI/CD on changes to visual outcome
  • wild thought: "design ops" would be responsible for staying on top of it
  • "the human side, engaging all roles, is the hardest about introducing it"

todo

  • can 'semantic-release' package help us?

Need for Speed – Web Performance Optimization, Jecelyn Yeen @JecelynYeen, GULP

  • why fast? user happyness, for them not to leave (if you have competitors), SEO
  • mentions lighthouse
  • lighthouse as npm package
    • budget.json to specify limits for build sizes
  • image optimization
    • is it important? does it block reading?
    • SVGOMG ('svgo' package)
    • webp as stand-in for png or jpg
  • explains webp and how a <picture> tag with a source and <img> can replace traditional images
  • media feature in webp for different devices
  • loading="lazy" on img in <picture> (native not JS) - currently only chrome but no downside in others
  • how to avoid FOIT (flash of invisible text), rather have FOUT (flash of unstyled text) `font-display: swap`
  • shows font size optimization when using google font API
  • split and lazy load javascript
  • advocates for preloading components based on likely user journeys through the application
  • guess.js/quicklink can do predictive preloading (bundle accordingly) based on analytics data
  • differential loading (e.g. polyfills) based on target
  • swtich out some expensive libs (e.g. babel-preset-es2015 -> babel-preset-env)
  • Bundlephobia can help track bundle size
  • webpack bundle analyzer is helpful in understanding the contents of bundle contents
  • call to continuously optimize performance: measure, improve, monitor, improve

todo

  • add lighthouse budget to apps' CI
  • check state of the union of webpack bundle analyzer - with or without vue-cli
  • look into the methods mentioned, in particular: differential loading

My browser does what?, Joel Lord @joel__lord, Red Hat OpenShift

  • recently rewrote talk after many browser APIs having changed
  • https://ezurl.to/browser-what - presenter unlocks different features on everyones phones during the speech
  • websockets
    • not a browser API
    • noteworthy as it is the basis of this presentation
    • form is unlocked on all screens at once - sweet
  • notification API (not to be confused with push)
    • requires Notification.requestPermission()
    • can be simple text or body, icon, ...
    • on mobile devices one needs to register a service worker
    • again nice touch: pushing notification to all participants
  • geolocation
    • get coordinates once or "watch" for position change via events
    • requires https for many browsers which can be a challenge in dev
  • page visibility
    • document.visibilityState
    • visibilityChange event
    • e.g. to pause a video if tab is left
  • speech API
    • txt2speech
  • navigator.online
  • device orientation & motion
  • vibrate API
  • clipboard
    • highlights poor support and associated security risks
  • getusermedia (camera, microphone)
  • audio
  • gamepads connected
  • bluetooth API
    • runs about stage to show change in connected heart rate monitor

todo

  • consider navigator.online for our save buttons

Advanced Progressive Web Apps: Push notifications under control, Christian Liebel @christianliebel, Thinktecture AG

  • key criteria to identify as PWA
    • responsive
    • linkable (state in URL)
    • discoverable (via maniphest)
    • installable (e.g. on home screen)
    • app-like (e.g. nav)
    • connectivity-independent
    • fresh (content even if using cache data)
    • re-engageable
    • progressive (doing something in older browsers)
  • focus on re-engageable, push notifications in particular
  • interactive talk: https://pwa.liebel.io
  • explaining push as "hollywood principle" i.e. "don't call us, we will call you"
  • notifications and push are different things (as mentionined in the "My browser does what" talk)
  • spoilers that the way user notifications are requested might change in the future
    • mozilla and google are exprimenting with how permissions are requested
    • goes to show the presenter is in the know
  • recommends "double permission" approach i.e. little explanation of what permission will be requested, only really ask then - like gmail does it
  • explains difference between non-persistent (created from the web app) and persistent notifications
    • persistent notifications, i.e. "push notifications" are sent via a service worker and even work if user does not have the app "open"
  • "service worker" is somewhat not part of the website, can "wake up" even if the website is closed
  • explains service worker lifecycle
    • push events "wake up" service worker which then (maybe) shows something via the notification API
  • each browser vendor has its own push service
    • HTTP Web push comes to the rescue to prevent having to implement against all push services - IETF/RFC:8030
  • HTTP Web push features
    • receipts, urgency, TTL, message replacement
    • GDPR-compliant
    • encrypted and signed
    • mentions VAPID which complements it by allowing for dev to (voluntarily) authorize
    • "silent pushes are not going to be allowed" `userVisibleOnly: true` is mandatory
  • shows https://pwapraxis-push.glitch.me/ as a way to send push messages for testing
  • iOS "polyfills" (all more or less hacky)
    • SMS
    • wallet notifications
    • native wrapper (cordova)
  • presents "project fugu"
    • notification trigger (e.g. to schedule future calendar events)
    • badging API (showing amount of events)
  • mentions "runtime push" (e.g. to trigger data refresh by letting the app fetch)
    • via websockets
  • praises https://onesignal.com to gain insights (opening rates, ...)
  • mentions PWAbuilder to create an artifact to submit to app stores to make it discoverable for users who search there
  • "uninstalling" (removing from home screen) is "currently" not trackable
Retrieved from "https://wikitech.wikimedia.org/w/index.php?title=User:Pablo_Grass_(WMDE)/conferences/IJS2019_Munich/day2&oldid=1842920"