Jump to content

User:Pablo Grass (WMDE)/conferences/IJS2020 Munich/day3

From Wikitech

Using Data Visualization to Fight COVID-19, Gil Fink, @gilfink

  • attendance: 52
  • shows a prototype to visualize COVID infections, how and when they arrive in Israel which is used as Business Intelligence in politics
  • putting numbers on a screen is not helpful, meaningful visual representations need to be found
  • suggests d3, deep dive into an example using it
  • shows https://github.com/d3/d3-force which was shown to visualize the network of infected people
  • ~5mins technical hick-up of the conference live stream
  • shows how to pair d3 with react - react handling data updates and redrawing d3 when this happens
    • states that huge data sets can pose a problem
  • encourages people to look at PixiJS and how to combine it with d3
  • mentions different d3 visualizations
    • hierarchy tree - visualize infection chains
    • force graph
    • bubble charts
    • aggregate - connections between age groups, ...
  • demos the ready made application (localized in Hebrew)
  • built a nice filter panel (memories of query builder)
  • encourages people to build their own visualizations for things they care about
  • Q (myself): "If and how do you re-apply the user manipulation (drag) upon updated data?"
    • A: information is lost as react redraws entire d3
  • Q (myself): "Was the use of open source software a requirement (given that government money is spent) or did you pick it on your own?"
    • A: Good q. We used open source and plan to publish it as open source as well - the authorities are ok with this.

Did not know d3 hierarchy tree. Great to see that OSS is used to equip our decision makers with important information in these trying times.

Sulu: Das Fullstack Symfony Content Management System, Roland Golla, @cleancode_devel

  • attendance: 16
  • mentions https://github.com/drud/ddev for local setup of PHP projects
  • will present https://sulu.io/ (repo) as framework to add CMS features to existing (symfony) projects
  • in an HTML template in PHP storm used some shortcut of generate markup from an xpath like string "div>p>a" (emmet)
  • shows how to add a new section to the template and thus making it editable in the CMS backend, and how to customize the backend layout a little
  • shows the different live preview modes (desktop, mobile, ...) in the backend when changing content
  • has quite an interesting workflow of having memorized editor templates to do his programming while apparently not fully being on top of their outcome
  • using twig to place the backend info into the template - no surprises
  • shows that he integrates his wordpress blog information, loaded via the API, on his homepage's home page - and how this positively impacts his search engine credibility
  • suggests maintaining a piece of information in a single location and reusing it in multiple places across the website
  • Q: "Welche Vorteile hat Sulu im Vergleich zu z.B. Typo3?"
    • A: for me the key argument is speed. My development speed with sulu is highest
  • Q (myself): "Wie speichert das CMS seine Daten? Sind diese versioniert? (audit trail)"
    • A: seems to be files on disk but I don't know the details. Don't know about versioning
  • Q: "Macht es sinn, bei jeden Seitenaufruf die Blogeinträge abzurufen? Falls der Blog nicht erreichbar ist, funktioniert deine Seite auch nicht. Sollte man diese nicht über ein Cronjob holen und lokal cachen?"
    • A: many layers of this stack have cache ability. do it where it makes sense
  • Q: "Wie sollte man eine hybride Architektur aufbauen, wenn man Webapplikationen mit Content verbinden möchte? 1. WebApplikation in Sulu integrieren oder umgekehrt 2. Sulu-content in die Webapplikationen einbinden?"
    • A: Not sure I got the question. Maybe it is about headless CMS and how frontends can connect to it?

Learned it exists, a little about ddev, and found dependency-cruiser when looking at the repo - so there is that.

A Deep Dive into RxJS Subjects, Michael Hladky, @Michael_Hladky

  • attendance: 24
  • about https://rxjs-dev.firebaseapp.com/guide/observable
  • a subscription glues together 2 parts: a producer and a consumer
  • subscription is the result of invoking subscribe on a producer
  • a subscription has an unsubscribe method, but also an add and remove to wrap other subscriptions
  • the problem this solves: protect the user of the observable from having to track the completeness of the internal subscriptions
  • differences between a subscription and a promise https://medium.com/javascript-everyday/javascript-theory-promise-vs-observable-d3087bc1239a
    • "a Promise is eager, whereas an Observable is lazy."
    • "Observable can be synchronous"
    • "Observable can emit multiple values"
  • interesting: shows the tearDown function for producer clean-up which automatically gets called when unsubscribe is called (prevent memory leaks)
  • a subject helps to create dedicated producer functions, only if a subscription exists for a value (thrown against an array of subscribers) it is relevant
  • mentions unicast and multicast depending on how the subscribers are set up
  • mentions different subjects and (very high level) use cases
    • BehaviorSubject - re-subscription results in the list of all signals at once
    • ReplaySubject - interesting when combined with a cache with a time or size limit: emit only parts of the values upon late subscription
    • AsyncSubject - is not sure where
  • "diagrams are based on a standard that I created"
  • closed on asking the audience to find and send him use cases in the real world

Positively excited speaker presenting a computer science solution to problems which partially still have to be invented. Very entertaining but possibly also useful to look into more the next time something repeating or push-related comes up.

Responsive Design Best Practices, Elad Shechter, @eladsc

  • attendance: 34
  • advocates to organize CSS in components
  • explains our journey from "desktop first" to "mobile first"
  • where to put the CSS media queries? separate placement in a long file is bound to cause problems. media rules inside the component makes it much more maintainable
    • advocates the use of a CSS preprocessor to help us repeating the needed selector
  • resulting repetition of media rules (and its hard coded values) should be countered by moving break points into variables
  • advocates against the terms e.g. "mobile", "tablet" and "desktop" as names for break points because of varying sizes and differences between portrait and landscape mode
    • in real life we should use names like "small", "large", ...
  • differentiates between open and close break points
    • open break point - start but no end position, e.g. only a min-width
    • closed break point - start and end position, e.g. a min-width and max-width
  • suggests to only use closed break points (except for the last ones) - use multiple media rules as selectors to style all of them alike
    • ease debugging because less "strike through" values in the browser
    • allow custom settings for the break points in the middle
  • conclusion: "desktop first" or "mobile first"?
    • neither. Too many overrides are not a good idea. "Basic first" is what he suggests
  • only put styles which apply to all break points alike outside of media queries - no overrides
  • Q: "Whats your take on library-specific solutions like styled-components for react, where the styling is put together with the javascript component logic directly and there are no more separated codebases?"
    • A: I'm not a big fan of CSS in JS. Makes it very unreadable.
  • Q: "Regarding the menu, why not have 2 different React components, one for mobile and one for desktop, in case they have a complete different structure and styling ?"
    • A: ?
  • Q (myself): "Thinking about component libraries and responsiveness. Should the ("leaf") components still manage their own size, or should they grow and the container manages their size?"
    • A: (slightly misunderstood the question) Would be great if CSS evolved to have better control for parent elements over the size of their children.

Reassuring run-down of best practices. The "Basic first" approach might feel like it is putting the "Cascading" out of CSS but the point he is making is valid - makes reasoning simpler.

REST, GraphQL, gRPC what should I use to build my APIs?, Phil Wilkins, @PhilConsultant

  • attendance: 21
  • speaker could not make it so we are seeing a video from a former conference
  • how did we get here - inter-process collaboration ("API") technology over time
  • puts focus on gRPC as a recent addition to the list of tools
  • reiterates REST properties and building blocks
    • selected pros
      • no requirments on HTTP version
      • well established
    • selected cons
      • can be too terse (overfetching, underfetching)
      • versioning not built in
      • no compression beyond HTTP defaults
  • reiterates graphql properties and building blocks
    • interestingly mentions that it has "ideas around handling versioning" - the opposite of how I thought about it, seeing REST having the upper hand there
    • selected cons
      • can't leverage HTTP features as the request is in the body
      • strong typing could result in developers tempted to send their persistence data straight through the API without a layer of abstraction in between
  • explains gRPC
    • mentions similarity to Apache Avro
    • mentions how schemas a more involved, having to e.g. order fixed size properties above dynamic size (e.g. strings)
    • selected pros
      • very bandwidth efficient (data only, client has the payload schema)
    • selected cons
      • http 2 requirement
      • tough requirments on the client, not for 3rd party consumption maybe
  • recommendation
    • use a checklist
      • addresses my needs
      • gives value to the consumer, not primarily the provider
  • shows factors in play (in case of internal and external use) and how to use them in a decision matrix
    • rules of engagement
      • commercial factors
      • monetization
      • legalese
      • auth
    • ease of use/consumption
      • SDKs
      • test framework
      • consumer-focused docs
      • (ex)samples
  • says that everyone has to make their own call for their individual use case

Unagitated inventory of the status quo and how we got here. Tongue in cheek: feels like he is presenting gRPC as the boogeyman to make graphql look established, so we can all finally use it in production.

Content Security Policy: Yesterday, Today, Tomorrow, Christian Wenz, @chwenz

  • attendance: 28
  • explains that CSP is another layer of security, no replacement for other measures (defense in depth)
  • shows the different CSP directives (script-src, img-src, ...)
  • browser support is shown for different CSP 1 & 2
  • mentions that the report-uri feature is quite neat
    • encourages audience to collect those and set up a process check the entries
  • also encourages audience to start green field project by "disallowing everything and see what fails" (set default-src, form-action, frame-ancestors, report-uri)
  • mentions the nonce approach to make scripts run, even if a hash approach is hard to achieve (dynamic scripts, ...)
  • reminds that tightening security is possible by specifying multiple directives
  • lookout CSP 3
    • navigate-to looks helpful

Nice primer to get started on the topic and a compelling argument to adapt CSP early in any project as retrofitting is much harder than getting it right from the start.

Retrieved from "https://wikitech.wikimedia.org/w/index.php?title=User:Pablo_Grass_(WMDE)/conferences/IJS2020_Munich/day3&oldid=1956604"