If you write code for fun or for a livelihood, I recommend you check out my friend Philipp Janert’s newest book Feedback Control for Computer Systems.
Feedback Control is a topic well known to mechanical engineers, but not so much in our industry. Feedback Control is about making smarter systems that can cope with dynamic environments. Many knobs that we build into configuration can actually be automated with feedback loops.
Examples given early in the book:
- A Cache by tracking hit rate and changing the cache size
- A Server Farm by tracking request latency and changing number of deployed server nodes
- A Queueing System by tracking wait time and changing the number of workers
- A Graphics Library by tracking memory consumption and changing the output resolution
The book is well written. It starts out with practical examples and working code. It later introduces the deep theory and drops some math bombs. Don’t worry, there is Python code for everything and you don’t have to understand the math.
It gives solid advice, like don’t blindly use Feedback Control for optimization; optimization needs a higher level strategy guiding the process.
Lastly, there are references for further reading, if you do want to work through more of the theory.
It also sets realistic expectations. You’ll control one metric by changing one variable. This is no silver bullet.
The term Enterprise is thrown about, don’t let this scare you away This is a valuable book for many types of software problems. A couple I’ve brainstormed of:
I’ve been given the chance to mentor a high school student. I’ll capture details around how this goes, I’d love your input and ideas. I’ll keep student anonymous, but give many other actual details.
My friend Casey teaches Math at New Start, which is an Alternative High School for at risk youth. They have programs where a student can sign a contract with a teacher for a certain course of study and amount of credits.
He has a student, we’ll call him Billy, that is very passionate about video games and wants to learn how to make them.
I had four goals for our first meeting.
- Meet Billy and get to know his background
- Tell my story and answer any questions
- Find out what resources Billy has
- Talk about our plan and start him on code academy
The Plan (so far)
The general plan is to have him work through some of the Web Fundamentals via Code Academy.
We’ll spend quite a few weeks or months jamming on Web Maker projects. We will use these to explore different aspects of making video games (Animating Sprites, Playing sounds, physics, etc).
Lastly we’ll try to find an open source HTML5 version of one of his favorite games (like Fallout). Using that, we’d work on creating a mod or new video game in that genre. It all depends on what aspect of video game creation Billy is most interested in.
Billy has a Windows laptop, an XBox, an Android phone and paper notebooks.
I’m keeping a notebook of amazing projects as I come across them and will share them with Billy. One of them could be the foundation of a larger project for him.
Billy has to spend at least 3 hours a week on this class. Hopefully he will get obsessed with how to build games and 3 hours won’t be an issue.
It’s TBD how many weeks is a contract. I’ll let the teachers and administrators sort that out and be available as a resource.
I met in person for the first time.
Subsequent meetings will be 1 hour Skype meetings. I will also keep “office hours” two days later where Billy can instant message me with questions or ideas. Lastly he can email me at anytime, but may have to wait hours or days for a response.
I’m very lucky that Casey is a passionate teacher and is also doing the code academy exercises.
I’m also very lucky there are so many resources on the web for young people who want to make video games.
POSTED BY ozten ON November 21st, 2013. PERMALINK
One of the cool discussions at Mozilla Summit was to create a “FoxBox”.
Some flavors of this idea are 0xDECAFBAD’s Hub of Awesome, Freedom Box or the IndieBox project.
With amazing documentaries like Terms and Conditions May Apply, these ideas seem to be gaining mainstream relevance. Energy is now going into re-decentralizing the web and joining forces with existing efforts like IndieWebCamp.
I have a slightly different idea of what I think we need, which I’ll sketch out here.
The NobleWeb is a consumer oriented product (physical box and software) which allows “one click” ownership of your web identity.
Domain registration leads to a (pre-installed) Service Marketplace. You choose “Apps” to install; this locally installs the server-side components. These apps are each available on a subdomain of your personal domain.
The Operating System is automatically updated and configured as are most apps.
NobleWeb will email you if it gets into trouble.
Every year you’ll have to upgrade it’s hard drive, but otherwise it’s just that data vault next to your Wi-Fi router thing.
A typical person using NobleWeb would have MailPile, WordPress, MediaGoblin and a Dropbox-like app which they use daily from their various devices.
They send and receive emails on their personal domain. Wizards create and syndicate content directly from NobleWeb. Most people do a lot of social networking on closed platforms, but juicy bits like photos end up magically in their NobleWeb photo library.
- We value People first (over corporations or profits)
- Systems should just work with minimal care and feeding
The box has no physical user interface for daily use, you use your existing devices for UI
- The UI of apps should work on any device (Open Web Apps, Mobile First Design)
Noble Systems must be useful with other products and services, so that NobleWeb people can connect with ShareCroppers (mainstream people)
NobleWeb users will also use closed platforms and if possible we should sync data back to their NobleWeb box
- Archive data in standard, open formats is preferred
- Device does one thing well, isn’t also a Wi-Fi router, nor toaster oven, … etc
- Try to collaborate with existing open source projects as much as possible, but don’t compromise the experience
- Linux Containers are the future of webapp deployment
- Support popular web apps with legacy architectures (WordPress)
- Prefer federated open web app architecture (HTML5, Open Web APIs)
- unhosted or unhosted-like remote storage
- CoreOS running on Raspberry Pi eventually
- CoreOS on x86 with an established Linux distro to start
- 2 hotswappable hard drive bays (online and empty bay used during disk upgrade)
The box has an LED panel useful during unboxing or hardware failures. Can display scrolling text.
- Both Wi-Fi and Ethernet port
- The device has a Mac mini like form factor
- Use cloud services while disks are full
- pre-cache public web views as HTML files on disk (burst scaling and more archival)
Thinnest possible centralized service for improved UX of hard to do client-based tasks (domain registration, DNS, etc)
Provide “wizard” escape hatch for replacing centralized components
- Wizards can always install their own unique apps via Linux Containers
- Persona for authentication
- Sharing authorization via your NobleWeb contacts service
The closest thing I have come across is ArkOS, which I recently found out about.
I think there is a lot of overlap with other existing projects, but not many projects that are focused on starting with the UX. As this is a side-project, I don’t promise anything, but I’ll tag experiments with NobleWeb as I go. The long term audacious goal would be gluing together the awesome work that you are all doing in Linux, Mozilla, and across the open web.
Let’s build a foundation, for taking back the web, that everyone can use.
POSTED BY ozten ON November 12th, 2013. PERMALINK
5 and a half years ago, I was working at Amazon.com on cutting edge frontend “creative”.
I got a recruitment email from Mozilla and connected with morgamic.
I freaked out. I didn’t even know that it was possible to do stuff with Mozilla.
I knew if Mozilla offered me a position, I’d take it.
I had an in-person interview. One of my heroes was in the loop. Myk Melez. I was familiar with him through the many cool tools used to support the development of Firefox.
Myk asked me, are you a Mozilla community member. I said “No” apologetically.
Over the years, I’ve come to realize that this is a real problem with we Americans.
I thought to myself: Am I a Mozillian? I’ve never landed C++ code into Firefox, so no.
I am just a dumb web developer. Mozilla is the elite technologists.
I ignored the following facts:
* I was a passionate user of Linux, Thunderbird, and that Netscape Navigator/Phoenix/Mozilla Firebird/Firefox thing
* I had deployed MXR, Bugzilla at previous work places
* I spread the word about these projects
* I helped support other users
* I was proud of having my name in the 2004 New York Times Ad
* I was writing Ubiquity scripts and using many of the Mozilla Labs projects
* I’d spent the last decade hacking on web technologies and sharing experiments
That I didn’t consider myself a Mozilla community member… That’s just sad!
It took joining as a staff member and learning Mozillians culture first hand, to finally consider myself a Mozillian.
I think we’re doing a better story of explaining how easy it is to participate as a Mozillian, but here in the US… I think we have our work cut out for us.
We have a couple things in our culture that block people from self-identifying as Mozillians
* Imposter syndrome
* Lack of Community ethos
“I am just a dumb web developer.” Imposter syndrome said that. We all have so much to offer. You don’t even have to be a developer to be an awesome Mozillian.
It’s anecdotal, but I’ve seen some cultures have an easier time building Mozilla communities that here in the states.
Churches, boy scouts… we have a few community archetypes, but we are mostly a “go it alone” “pull yourself up by your boostraps” type of people.
Our community is now tackling the idea of what membership into the Mozilla community means.
You can read more contributor stories… How did you get involved with Mozilla? What is your story?
POSTED BY ozten ON October 28th, 2013. PERMALINK
My colleague Ryan Feeley showed me Interscope’s sign in NASCAR:
It doesn’t even fit in the dialog! Okay, to be fair, I think Interscope’s
dialog had a bug when I took the screenshot. (I tried in several browsers).
You provide all of these options, to allow people to pick a brand that they trust.
But it doesn’t scale.
You can almost hear Brody, once he’s seen how big Jaws is…
“We’re going to need a bigger boat” or
“We’re going to need a bigger race car, to host all those logos”.
I’m here to talk about life after the NASCAR. Or consider it NASCAR++.
What if there was a way for people to sign into your website with a
brand they already use and trust?
There is. It is here today and it’s called Persona.
How does it work?
During sign in the user enters their email address.
The browser then does discovery on the email address and sends them to
the authentication flow of the email provider, or to a fallback Identity provider run by Mozilla.
As a website creator, you get to integrate exactly the brand your user knows and trusts,
without the problems that a NASCAR causes.
What kind of problems?
Look at the interscope NASCAR! The first time I saw it (not the current screen shot) it had 10 buttons.
As Alice confronts this mess, should she use Facebook, Google or Instagram?
She is an active user on all three! And which one did she use last time?
Having Alice type email@example.com just seems easier.
Co-incidentally, she registered with FB, Google, and Instagram
as firstname.lastname@example.org… so it fits her mental model of her accounts.
That is how you avoid accidental account creation or abandonment.
And when she returns to your website, her browser remembers which email addresses
she used on which sites. No more confusion.
So, how did we get here?
The proto-NASCAR was a good invention:
- People didn’t want to create per-site passwords
- Most websites aren’t a brand that the visitor knows and trusts
- Using a trusted brand to sign into a new website, feels good
- Branded sign in buttons are a fast and easy registration or sign in flow
All was good in the land, when there were only 1, 2 or 3 buttons…
But the web being the web, it favors decentralization and empowering all companies to potentially be a trusted brand.
And buttons begat buttons.
And the term NASCAR was born.
And then all was not good in the land.
And much wailing and gnashing of teeth ensued.
But, I can see the path forward. A road without NASCARS, but which gives the same user benefits.
Persona. How to build websites after the age of the NASCAR.
POSTED BY ozten ON September 20th, 2013. PERMALINK
Thanks to Tim Bray for his thoughtful exploration of Persona, documented in “FC4: Persona Questions”.
Here are a few clarifications I’d make on his post:
First of all, as it stands now, the sign-in dialogue is popup-only, which means you have to have a human click something to launch it; you can’t start it programmatically, which means even if you know the email they want to log in with, the IDP they want to use, and every other relevant fact, there’s no way to just launch the freaking sign-in process already. – from Moving Target
This is accurate for the first time sign in to a website, when it is the first time you are using Persona.
The story gets better when you are:
- Returning to a website you’ve used recently
- Trying a new website, but are an active Persona user
Persona sign in is automatically triggered when a person returns to a website where they already have an active session. Let’s see how that works:
Persona remembers the email address which you have last used at a website.
Trying out new websites is cheap and easy, for people who already have used Persona recently.
Here is a quick demo of these points:
In OIDC, an essential step is that the RP registers its app at the IDP, with a human-readable label and optional graphic. And when you try to authenticate, the protocol includes an RP identifier and requires that you get a prompt asking if you’re OK with your identity being sent to that site (identified by text and graphics) before sign-in happens. – from Human Experience
Here, OIDC stands for OpenID Connect.
Persona has the same affordances, websites can specify a site logo, background color and site name, so that they have consistent branding and people know what they are logging into.
I’d argue that Persona is nicer from a developer’s perspective than OAuth or other API key based flows, because you don’t have to register your “app” and manage app secrets.
At the moment, my biggest issue is, do I want to use Mozilla for my IDP?
Question: Should Google be a Persona IDP? Why? – from IdP Experience
The fact that Mozilla is the IdP for 20-30% of our users is a bootstrapping step. We absolutely want email providers like Google, UC Berkeley, Genentech, etc to implement the IdP protocol and manage their own security.
We implemented “Identity Bridging” for Google and Yahoo, to demonstrate the benefits of people’s identities secured by the webmail provider they already trust. They get 2 factor auth, abuse-detection, etc which these awesome providers are already experts at.
If Google implements Persona IdP, the protocol is already setup so that our Identity Bridge would be circumvented and you would go directly to Google Account servers for gmail.com addresses. We’d be pleased as punch and deliver artisan donuts to the Google Accounts team.
Being an IdP is great for webmail providers as they get another branding touchpoint, to stay connected with their users throughout the day.
Lastly a note about how Tim has integrated us into his testbed:
Image copied from ongoing by Tim Bray
Persona works for any email address and removes per-site passwords.
This testbed is a NASCAR. We do not want a Mozilla button, like the dino head in this list. I’d drop the email/password section, and replace it with
If email + password is an important form based auth method to be tested in the testbed suite, then I’d put it behind a “legacy auth form” link. Persona cleanly replaces the email + password flow and is not vendor specific.
Again, thanks for the honest and fair evaluation of Persona and the BrowserID protocol.
POSTED BY ozten ON August 29th, 2013. PERMALINK
I upgrade my blog to the latest browserid-wordpress plugin.
I also fixed my janky layout. I had WordPress installed in a different location than the site url, which was causing some issues.
Great work Shane!
POSTED BY ozten ON July 19th, 2013. PERMALINK
Johannes Ernst took the time to evaluate Persona and wrote his thoughts entitled “Mozilla Persona: nicely made but who has the incentive to adopt it?”
The following is my personal take on (a small portion of) the Persona market strategy.
“Persona’s #1 selling feature is privacy.”
This was a guiding design principle, no doubt about it. It absolutely is not our #1 selling feature.
Our team wants to help mainstream users. Sadly, privacy (and security) aren’t their main concern.
Johannes makes some great points around Google’s use of OpenID, that losing information about where their users are going might be a negative in evaluating Persona.
Here’s the thing. Our team has focused on the following stakeholders:
- Websites – Relaying Parties (RP)
- Email providers – Identity Providers (IdP)
- Browser Vendors
- People using the web (Users)
For each of these, deep focus was put into the value proposition and finding the right balance in the technical details.
I’ve never been on such a large scale Open Source project that focused on User Centered Design, Marketing, and Security.
Let’s take IdPs which is Johannes’ main problem. If an IdP were to adopt Persona, they would get the following benefits:
- Organizations have the ability to control the security parameters for their domain
- Brand recognition on websites which use Persona.
- A SSO-like experience for enterprise, schools, and communities.
Without native IdP support, an organization that controls an SMTP routable domain name is subject to the email + password of the Persona fallback. They cannot add 2 factor auth. By running an IdP they can use Yubi-keys, RSA thumbdrives, or SMS verification… whatever.
Once they control the security, they would be more inclined to use Persona across their family of websites. This integration is much easier than traditional methods and lowers expenses.
The brand recognition comes by controlling the login screen. They get this today with OpenID and OAuth which I will call “Social Login” to simplify the argument. Social Login isn’t applicable to every RP.
We think that adding Facebook Connect filters out 15% of your new users. (We’d love to do a study and get reliable numbers here).
There is a long tail of websites which can’t use Social Login and will do authentication themselves. We think that Persona is viable for many of these websites. Thus a company can further spread their brand.
I agree with Johannes that Google won’t be the first large IdP. I don’t think that means Persona is irrelevant or destined to fail. Universities, email providers, and enterprise can improve their users security and smooth out login flows. Identity startups can start with a solid protocol and get Browser/Website integration for free.
The IdP is Only One Stakeholder
Those reasons are just some of the value propositions balanced against other factors during the design of Persona’s BrowserID protocol.
For RPs, there is a set. Here are a couple:
- No platform/vendor lockin (email based)
- Easy to implement (lower cost)
- Works across devices
- Improves security (DROP COLUMN password)
- Consistent sign in across the web
- Lower cost of authentication system (forgot your password, remove sending email for verification and forgot your password, etc)
Again this list is non exhaustive and I haven’t touched upon Browser Vendor or User value propositions which have been designed for.
I agree with Johannes that some businesses will avoid Persona early on. Perhaps they want a Facebook Connect sign in for extended profile information and social graph.
That is fine.
Persona can help a lot of people use the web in an easy to use and more secure manner. It doesn’t have to be everybody on day one
Johannes, you have a long history in this space. From meeting you, I know you care about user sovereignty (and many other important factors). Thanks for helping us find adoption problems with Persona.
Updated: linked to Serge Egelman’s paper. Thanks Francois!
POSTED BY ozten ON June 25th, 2013. PERMALINK
For the first time in my life… I can see well near and far. This is amazing.
POSTED BY ozten ON June 24th, 2013. PERMALINK
I’m at IndieWebCamp this weekend!
I’m publishing this blog post after logging into the WordPress admin screen with Persona Sign in.
This uses my email@example.com email address, which I’ve had since 1998. With Persona, I can keep my existing Identity.
Persona’s architecture respects my privacy, my personal data, and let’s me take control.
I’m also showing a demo of how I’m my own Identity Provider for ozten.com.
And how it works across my tools, including my brand new Persona enabled Federated Wiki.
POSTED BY ozten ON June 22nd, 2013. PERMALINK