Photo by Ed Telling during FullStackCon 2017.
In Part 1 of this series we looked at #FullstackCon 2017's JS parts, but in this post we will look at the rest, but as it is a JS conf, still related in some way to Javascript, but just more high level or conceptual.
Before joining the open keynote, after my coffee and conference breakfast, I picked up some of the "conference swag". Instead of a t-shirt, I chose a copy of Douglas Crockford's book: "Javascript: the good parts", so I was looking forward to hearing what this keynote had to offer.
It was a technical talk on numbers, starting with the history of number systems and problems with current systems and languages. For example Java32 and how some mathematical functions in Java and Javascript, which uses this number system, can cause discrepancies and incorrect numerical results. This is why a system relying on accurate numerical operations should not use Java or Javascript in most cases.
Douglas had developed a newer numeric system which he has open sourced. DEC64 is a decimal floating point format for the next generation of application programming languages.
Dave Benson starts by informing us that by using some “sneaky” CSS, we can improve the use of form controls without a single line of JS.
By making the label do the job of the input field, we can hide the input and style the labels with pseudo elements, as shown in his "Very boring CSS styled radio and checkbox inputs" codepen example.
Using CSS only (without JS) we can:
* For similar content heights, otherwise animations are at different speeds. You can use a different class per speed, but that is not ideal.
Amie Dansby is a maker and game developer, working with ragdoll physics.
Photo by Ed Telling during FullStackCon 2017.
Amie has an RTFD chip implanted in her arm and is heavily involved in the maker community. She introduced what Makers are, the community and purpose: to create items that do not exist or are not readily available / easily accessible. It is a movement about contributing things to be used for greater good.
She has learned through experience how to apply the perspective of a user to development. E.g., after 3D-printing and spending time developing a wand only for it to be broken immediately by the user doing something it was not originally intended to do.
Amie has burned out many boards and suggests to other makers start out:
Use the Rasberry Pi simulator on GitHub when 'making' so as not to fry your boards
Daniel Demmel
compares shared wells and waterways to centralised app server paradigm (eg. LAMP).
In the traditional model: App server, App code, and content DB, scaling requires a lot of thought.
With the more modern approach, having distributed asset delivery and a Serverless Computing architecture, static assets are compiled down, dynamic content is made available through APIs or CDNs, eg. Netlitfy (as it is only serving files it can be very quick). In this way, Serverless architecture is minimal, as it is on demand only, however, it is more scalable in nature.
Kevin Hoyt, an IBM developer advocate starts by highlighting the application that everybody most likely knew: Bitcoin — the 1st application built on blockchain.
Kevin suggests to think of Blockchain as a database or datastore, with special characteristics:
The blockchain is distributed store with decentralized consensus, but who creates the consensus and guarantees transactions?
“Proof of work” — a similar idea to CAPTCHA to guarantee integrity. This is where “Mining” comes in.
"Smart contracts" (often called chaincode): computer programs that facilitate, verify, or enforce a contract. Most of these are written in Go programming language.
For building Blockchain based applications, Kevin mentions Hyperledger Fabric Composer.
Hyperledger Composer is an Open Source toolkit for build Blockchain based applications. It is written in JS mainly and allows author watching for transactions, etc.
Athan Reines starts by providing a brief history of the web and specifically touching upon Applets and how Java applets gave improved performance over JS initially. Then ActiveX came along, allowing native code to be run, but that was not really cross-platform, being Windows only.
Following that, there was NaCl (Native Client), PNaCl (Portable Native Client), and Asm.js (A reduced subset of JS).
Now, there is WebAssembly, a Binary format for the web agreed by vendors, with a portable compilation target.
In working with WebAssembly, your C/C++ gets transformed to an IR (intermediate representation) then to WASM and finally the compiled format: x86/ARM.
It has advantages such as being Compact, Parsable, Typed, Optimized, Lower-level, and Performant.
This is the main tool, the SDK: Emsdk is around 10GB and can be used to compile C++ and output emscripten.
Following compilation, you can load the emscripten file in JS, read it into a buffer and call a new WebAssemblyModule, either setup with a pool of memory, or a wrapper around a C function.
Other options are Binaryen or WebAssembly Binary Toolkit.
Athan believes we are not going to start writing websites in WebAssembly and it will not replace JS, but that it will complement it, particularly for gaming, but that you have to manage and reuse heap memory well.
From a Developer perspective, if you have an existing C++ codebase and want to run it in the browser, the only way is WebAssembly or asm.js. On the serverside, it is not clear there is a benefit to using WebAssembly, as Node.js native add-ons are much faster.
Laura Carvajal talks about her experience with accessibility and how it is something that should be fundamental in any website. She shares the lessons learned along her path in this area.
Accessibility allows people with various impairments, Physical, Visual, Hearing, and Cognitive to use the web.
Accessibility benefits people on the full spectrum, for each of the above areas, e.g., not just a deaf person, but someone with an ear infection or even bartender who works in a loud bar that has reduced hearing.
Laura mentions some really helpful tips which I have outlined below:
The color contrast issue is the most common fault, as it needs to be at least 4.5:1, and the
2nd most common is missing alt attributes on images. So, training people to be aware and reduce the number of these can save considerable time.
Add role=”presentation” to images with blank alt attributes to ensure screen readers skip, as some screen readers still read out "image".
longdesc will be deprecated, so linking to an alternative format, e.g., HTML. Even better, use SVG with charts to take benefit of all markup.
Add the required attribute on required input form elements.
Ensuring tabindex is -1 for iframe and adding aria-hidden=true (same for duplicate content, e.g. footer repeating another block)?
Add visually hidden content to buttons with same names O-visually-hidden, n-visually-hidden, as display: none in CSS can hide content from screen readers.
A recommended intro into Web Accessibility is through taking the Free Web Accessibility Course by Udacity.
You can use your keyboard instead of the mouse or even the Mac Accessibility Options to DIY accessibility test.
Do not take it all on yourself and become a bottleneck, get everyone involved and up-skilled.
Raise awareness by talking about accessibility whenever you can. Spread the good word!
Avoid litigation, look at things from a business perspective and protect your company by doing good for others, Win - Win!
Team member on their team, Ben Fletcher, who is deaf and blind on their team who prioritized integration of Pally and set them as a company on this course.
For custom components that do not suit native, you can use Aria to make them behave like native components.
Recommended automated tools to check out are Pa11y and Pa11yCI.
A tool that runs through markup and checks against web accessibility guidelines. Install by running: npm install -g pally
Laura believes it is good for small sites, but not for larger dynamic sites.
Integrate Pa11y into CI processes for larger sites using a simple wrapper script in a make file for Continuous Integration: make a11y - see:
http://engineroom.ft.com/2016/10/21/the-case-for-accessibility
Will Monk in this Lightning Talk starts by stating that based on his experience, if you are creating a new project dependent on many npm packages, or splitting an existing project into separate npm packages, neither work.
Specifically, when versioning, start with the most depended upon module and then push up the version number, then work the way down to the least. This takes a long time and can cause conflicts or discrepancies.
The solution to this, the Monorepo!
Lerna, as we saw in Part 1 of this blog series, was again recommended.
lerna import takes all contextual commit history into new repolerna run & lerna exec runs npm command across all packageslerna bootstrap bring all packages together and links them all togetherFrom work with IoT, Nick Hehr believes that many IoT ideas are not quite in the right direction today. The Twitter account Internet of Shit shows some of these failures and lack of purpose for IoT ideas and products.
Security is not so solid in the IoT space (e.g., Teddy bear that leaked voice messages via MongoDB patch)
Photo by Ed Telling during FullStackCon 2017.
Nick then provided a Demo using a Webcam and Weather service using NodeJS, connecting to Webcam via a mounted device, discoverable over WiFi and connectable over PubSub service.
Using PouchDB to provide offline syncing and developed using offline first.
Christian Heilmann believes that many apps are mobile first and that they stay mobile first, e.g., they have massive buttons on larger devices. He recommends not to just show everything and then just hide items using media queries. Rather, show things if the user has the space on their device.
Chrisitan reminds of an old security risk where renaming HTML files to app.hta which cause massive issues.
Windows 8 allowed HTML as apps, but stuck on IE10
We can see where we are today in this regard by visiting: https://whatwebcando.today/
Do not use HTTP anymore at all, people can spoof your website, and you can end up in court.
Photo by Ed Telling during FullStackCon 2017.
PWA does not need to 100% replicate native; it should allow features in a logical and user-friendly way. It should focus on core purpose tasks and ensure it works on as many devices as possible. There should not be any tech restrictions or barriers to access: Progressive Enhancement. E.g., Google search bar with no JS, then with JS, with Geolocation, etc.
Service Workers much more in control of caching by defining and clearing yourself rather than relying on traditional browser cache which was unpredictable.
Service work cookbook from Mozilla, tutorials from Google. Fallback to push service, firebase, etc. Use a Service Worker instead of Local Storage (synchronous).
Add stores can search and index apps via manifest.json. Otherwise, use robots.txt to disallow it. The PWA Ingestion Process is passive.
For testing your PWAs, Microsoft has Sonar and Google has Lighthouse.
At the end of the day as Christian states, don’t make it a big marketing hype: it's just an app, make it work as quickly as possible.
This talk by Evgeny Poberezkin, was the only one I missed at the conference itself that I intended to go to originally, but I ended up in a different talk. So, I caught up on the video, as I thought it was an interesting topic.
They help us work faster, easier, and it is easier to maintain. They make us feel better and more professional.
There are bad parts! So, using tools like ESLint, you decide what is right and what is wrong for the project.
"If you follow dev guidelines, then every developer's code is your code" — you can follow it.
Writing tests that give us code coverage brings us closer to a Test-first v.s. Debug-later scenario.
Should we commit to master or commit via PR? Both options have merit, but we should have guidelines for which you follow in what situation.
“Semantic commits” — yet to find proof that it works, but Evgeny uses them on their work projects.
Using tools like GitMagic and GitMonitor.
When working with these tools, you can set rules for repos, rules for teams, and rules for organizations.
npm run ghlint -- --tap
It can create, update, reopen, etc. issues via command line with failing causes, eg. "pr not approved", "master not protected", etc.
Can run per team or per organization, can override rules per repo though.
At the end of the talk during questions, a person recommended looking at https://github.com/open-bot/open-bot, which seems worth a deeper look, if interested in going further with this topic.
This was an enjoyable conference, it being my first JS based con, I was impressed. I found it to be diverse and informative, covering many areas, with something for all interests and skill levels. It is much recommended, and I would go again if the opportunity arises. You can Signup for #FullstackCon2018 here. Hope to see you there!