2019 University API Winter Workshop: Day 2
A couple of weeks ago, I attended the University API Winter Workshop put on at Brigham Young University (BYU). I really enjoyed my time there, and you can read more about my first impression and what happened during the first day of the conference in my last post.
To recap a little, the workshop is an unconference where attendees decide on the content of the sessions when they arrive in contrast to the traditional way of posting a conference schedule months in advance. In my last post, I mentioned that at least a couple of day-two sessions came from discussions over dinner about what happened during day-one sessions. I’m not entirely sure how much the sessions I attended on the second day were altered from input gained on the first day, but I still think its pretty cool that the unconference format allows for the discussions to be as up-to-date and impactful as possible.
Beaker Browser (Brian Ollendyke @ Penn State)
During the first day of the conference, Brian gave a session on his Headless Authoring Experience (HAX) project where he live-published a change to a site using HAX that then showed up over the network. He let out a concerning frantic giggle when he saw something change on his demo site, and after we confirmed his health was, in fact, okay he told us what the Beaker browser was and why seeing something change on the internet was, in fact, exciting.
Beaker is an experimental peer-to-peer browser with support for the dat:// protocol.
Beaker allows you to publish local files on your computer that anyone with an internet connection can consume. That might not sound so cool at first when you think of how easy it is to send a message to someone with the swipe of a thumb these days, but what did your thumbs actually do in that case?
They initiated an action, but then Google, Facebook, Twitter, Amazon, etc. turned that action into a sequence of steps that ended up allowing me to read what your witty thumbs had to say. In fact, my fingers have such a small, small part in getting my words out to you on Medium right now…and I know some of you will say “well if you actually OWNED your own content Alex, then you’d have a much better idea of what’s going on, you 🦃!”
While that is true, I bet that imaginary person uses AWS or some file storage system to serve their files…so they’re kind of full of shit from the perspective of owning everything and IMHO should just focus on getting content to their readers in whatever way works best for them🤗! Me, well I’m a cheap date.
With Beaker, you actually can feel proud of owning and publishing your content. Via the DAT protocol, you and the people seeding your files are the ones with the power, not a giant corporation with a massive amount of centralized servers sitting somewhere just waiting to get DDOSed or hacked by Jeff Bezos’ haters. DAT allows you to store files in a decentralized, distributed manner with features akin to version control and nice cryptographic security. I’m not even going to attempt to explain the DAT protocol, but they have a nice set of docs where you can learn more.
Now that I’ve pumped you up so much, let me tell you the sad story of the Beaker docs becoming unavailable as we were trying to figure how it all works…yep, the documentation for the P2P browser went down right in the middle of the session. Beaker is really experimental right now, so you’ll probably experience issues with spotty connections like we did. We may have been too dumb as a collective group to realize that we needed to switch to HTTP mode to read the docs when this blip happened, but nevertheless, it was sad to see a core part of Beaker become unavailable as we were exploring.
While that moment did suck, we were able to connect to files that Brian was seeding and then become seeders of those files ourselves. That was pretty cool. I also loved noodling through the debugger, because it was chock full of information I could mumble under my breath while stuff flew across the screen and made me feel like I was part of Mr. Robot. I totally know I’m not that cool, but when you try out the Beaker browser for the first time you just might feel the same way.
Low-code Options (Paul Eden @ BYU?)
“Low-code platform” was actually a new term for me, and it sparked my interest enough to gather more info. In 2019, it looks like there are 10.31 billion reasons to know what a low-code platform is and what gap it fills, and in the future, there will be many more billions of reasons to learn more about the available contenders.
Low-code is in contrast to the typical amount of work and time it takes a development team to build out an application. Instead of picking a language/framework, running through a lot of design exercises, and then finally writing the code to deploy, the low-code platform allows you to offload all of that work onto platform conventions and only focus on the problem you need to solve.
BYU invited several low-code app development platforms to their campus for a challenge to build out a locker reservation system in two hours that took their internal team three months to build…Wut? And that’s one of those taglines that makes you want to call “Shenanigans!” right off-the-bat, but I can assure you that no one was lying and that Paul’s test was genuine and turned out to be a very smart move.
True to its name, low-code platforms are supposed to be much more streamlined and efficient than the traditional development processes. Some people claim 3x to 20x faster development than the traditional way of developing, deploying, and maintaining the app yourself. Of course, you’ll have to give up some freedom of choice to get that productivity and maybe embrace some platform defaults you hate, but there’s no other way to gain that amount of productivity and eat your cake too.
Over the course of a couple of months, Paul’s team saw demos from several vendors. Mendix and OutSystems performed the best creating an MVP meeting 80% of the requirements in two hours time. Not too shabby. There were plenty of other vendors mentioned that did a decent job but didn’t match the top two performers: Appian, ServiceNow, Salesforce, Pega, Microsoft Power Platform.
Of course, low-code platforms shouldn’t be considered for every project, and Paul lumped projects into three buckets he considers when deciding whether to explore low-code for a project: core, supporting, and generic.
Core projects are ones that are crucial to your organization’s mission. You’ll never want to use a low-code platform for these projects no matter how much the sales team tries to bend your ears. It’s just not worth it. Core projects also contain a lot of custom business logic and aren’t the type of needs you could match exactly to another organization.
Generic projects, on the other hand, are ones where your peer or competitor organizations are probably going to go about building out the same solution. A great example of this can be a website platform. Most university sites are brochureware, and so you can easily buy a product from a vendor that works as-is and meets your need for information dissemination. No special sauce…hell, no sauce involved at all. ‘Tis a bit dry.
In the middle of the pack, sit the not so generic and not so crucial/core projects where you know what you need but you don’t see any product you can buy to fill the need. That’s where low-code platforms shine. Your proverbial locker reservation systems are already out there in the wild, you’ll just need to click a few buttons to “lock things down.” Slam dunk pun!
Some of the more gray-bearded developers in the room mused on how the low-code movement was going to make all of their jobs irrelevant in five years just like the visual programming languages did back in the day…
Sorry if I’m pessimistic about “visual programming with blocks”, but what you are describing was how Microsoft’s Visual Interdev was suppose to work in the 1990s. Create your UMLs in Visio, get feedback before coding, then click a button and the db and objects would be created for you…
Other session-goers had some reservations about these platforms allowing you to get 90% of a project done quickly only to find out the other 10% is impossible to complete. Essentially, “They’ll lock you in forever” or “they’re just toys” as retorts. But the only way to know for sure is to try them out, and I’ve certainly given you enough links to explore these “toys” until Toys-R-Us comes back into business. Cause I’m a low-code-r-us kid 😀!
Web Component Factory (Brian Ollendyke @ Penn State)
I mentioned Brian in a few other sessions I attended during the conference. The dude is everywhere. As an extension to his talks on HAX, he made a “Web Component Factory” project that helps you generate scaffolding for building custom web components (WC).
If you’re coming from using React/Vue/Angular, then creating WC that have state management integrated into them from the start can be challenging. Every time I started trying to create a WC from scratch I got stuck on how to observe changes to the properties inside the WC. Using Vue, all I have to do is declare a computed or data property and then add that to a template. Vue does the rest for me.
With WC, you end up having to do a bit more work to observe changes to properties and manage state like you may be familiar with if you’ve used React/Angular/Vue or similar libraries or frameworks. The Web Component Factory (WCF) allows you to pick from eight different templates in creating custom element scaffolding many of which include data binding support.
Once you pick a type of element, then you can include additional options and add some properties via the WCF CLI tool. After running through the prompts, all you have to do is run something like yarn start and you’ll have a working example of the WC you just generated.
It is interesting to explore the eight different templates to get a sense of the nuances of different flavors of how you can implement the WC standard. You can find out more about the Web Component Factory and generate some custom elements yourself by visiting the project’s repo on GitHub.
WebVR Workshop (Mike Potter @ Penn State)
At the end of my day, I revisited WebVR and the A-Frame project with Mike Potter from Penn State. Mike had given a session on the previous day about the general concepts behind WebVR APIs and how the A-Frame project can help you use those APIs via Web Components.
In this session, we actually wrote some code based on one of Mike’s examples to demonstrate how you can create a “scene” in A-Frame. We went over how some of the tags work within a scene including how to compose them within hierarchies, like a camera and a cursor, as well as alter attributes on the tags to obtain desired effects, like the position or scale of an entity.
<a-scene environment renderer="antialias: true; gammaOutput:...">
// Can load models via src URLs.
<a-box hide-seek material="src:https://cdn..."></a-box>
// wood-ball is component registered elsewhere.
// We can change the scale and position of it within the scene.
<a-entity wood-ball scale="0.1 0.1 0.1" position="2 2 -10"></a-entity>
// The cursor is composed within the camera component.
<a-camera>
<a-cursor></a-cursor>
</a-camera>
</a-scene>Most of what we went over is in the last section of my day one post, and you can view the sample code we saw and played around with here: https://glitch.com/edit/#!/deserted-objective
That’s all I got folks. As a reminder, the 2020 University API Winter Workshop. tickets are still only $99 so get yours today before the early bird special runs out.
