[Music]
so uh next up we have jessica lord i'm
so excited that jessica could come and
come and speak here today traveling all
the way across the country from new york
um even though she did you know used to
reside here
back in the day uh when jessica worked
at github um chances are you've you've
used uh some application that you know
jessica's sticky fingers were involved
in making along the way jessica uh
let the electron team uh or started the
electron team uh github and so you know
if you've been working on anything
that's had
been built as a desktop application that
uses javascript html css all of those
good things uh has been packaged up and
used on the desktop app there are lots
of them around um
are we going to oh we're going to lunch
okay
thank you
thanks for your talk jessica
so yes you may well have encountered
jessica's work already also um jessica
now works in new york at a company
called splice uh who do um kind of
tooling and resources for musicians uh
heard it described as
github for musicians so uh the mind kind
of boggles there i've seen jessica talk
a bunch of times before and always
really enjoy her take on like culture
and the uh like the way teams work
together uh and so i'm very very excited
to be able to welcome here to stack uh
conference uh please make it very very
welcome jessica lord
thank you
thank you so much phil
um
yeah thank you
that's full seven my name is jessica
lord i work at
a company called splice in new york city
i work on the back end and a bunch of
very not jammy stuff
at all
and
but i'm so i'm not talking about any of
that today today i'm going to share some
stories about very jammy things
i worked on when i github and i code for
america and github is a code sharing
site and code for america if you don't
know is a nonprofit based here in san
francisco
for
writing open source software for city
governments that city governments can
use and
be better at governing
but first i want to
go into
this statement and and really why i'm
thrilled to be here and a part of the
jams.conf and really love this area of
the web
the most and excites me is because i
really truly believe that everyone is a
developer that everyone could be a
developer
that everyone might be a developer they
might be on their way they will be a
developer soon or they actually already
are a developer but they're afraid to
call themselves that
our profession is really
special that way for those of us who do
this professionally
it's it's different that we actually
have people not doing it professionally
doing the stuff that we do
professionally
that's different it's not like rocket
science or heart surgery and i don't
mean in terms of complexity right
because that's not to say that the work
we do isn't important revolutionary
remarkable it is
um and that's what's really exciting for
me about it and it's not to say that
there aren't really brilliant people
doing amazing things but you don't need
to be on the bleeding edge fringe of web
development
to make something meaningful and
empowering and
there aren't heart surgery hobbyists
there actually might be and it's
definitely illegal
but it's it's one of these ways in which
our profession is different than other
people's and i might really regret this
metaphor later so
we'll see
um
because unlike heart surgery the web is
bigger than what we do professionally
and
unlike heart surgery the web is better
when it's approachable for more
people
the work we do every day is also done by
tinkerers by activists by people on
their weekends by people teaching
themselves
by community leaders all these people
who aren't considering themselves a
professional developer they're still
using the tools that we have built and
contributed and
are using
but
i think it's important that when we
build the tools we do and create the
environments we do for web development
we think about these tools in the
context not just of other developers
exactly like us but
for people not developers um
but aren't developers people yes
but they're a subset of people who could
would and should be
developing and so for me and why i love
the jam stack and
a lot of the work i do is because i want
to build things so that there's more
people building things and i think
it's it inflates everyone it is better
experience on the web when more people
can use the web
there's this quote i love from anil dash
who is the ceo of glitch formerly far
creek but now fully in on glitch um it
seems more important than ever to
encourage a diverse community of
creators to experiment with their
broadest set of ideas i think that's
so
true and
to me
it's really important because coding is
a powerful literacy and
and it's not just
the broadest people out there who
might be developers or who aren't
developers but i mean it's also the
people you work with because you
probably work with people who aren't
developers or people who haven't been
developers their whole lives or people
who are developers but came from a
totally different stack than what you're
working on now and so
i think
it's really important that we don't
think of a professional developer as the
only kind of developer and that everyone
can benefit from building things on the
web
because html cms and javascript they
still work and
like monica showed us browsers do
amazing things like we have these tools
already
and it kind of doesn't need to be more
complex than that um
so
where's my screen um i have
this kind of scale of web things
where if you imagine the two extremes of
a single page site and then a really big
web app
i think we focus on this far end and we
make it seem like this is web
development this is where you need to be
to be putting stuff online
and it's just not true
there's all this spot in space in the
middle
and i've actually used this diagram
before
but now it's really clear to me that
this is the jam
spot
of things and so this is the area full
of
things you can do that don't have to be
super complex and i
want there to be more activity here
because sometimes our projects make it
out into the world and other people
interface with them and those other
people need less overhead and then
sometimes a project doesn't it stays
internal but your teammates need less
overhead too
um so
all right the first part is
the story of making an electron a thing
electron is a library that github
maintains that is for building desktop
apps that work on mac windows and linux
using web technology
but it used to be called adam shell
and it was a dependency in adam which is
github's text editor and it lived there
and github didn't want to do anything
with it there was no vision for it there
was no plan and
i had been at github and
recently had moved on to the atom team
and as i dove deeper into the atom
code and onboarded
and learned that the thing making
everything happen was this thing called
adam shell
i started to think it was actually
more game changing than adam itself i
think adam is a great text editor
but adam schell felt really changing to
me and so
i started to
fight for it um and you might be
surprised that there was pushback
because there was really no vision for
this to ever be anything like adam was
the dream and
there was just
like
no there was no plan for this and i kept
pushing and i wrote up
road plans and reasons why it should be
its own thing and i finally as the first
step got the okay to spend my full time
working on electron stuff and the stuff
that i had put on my road map and so
adam shell
the core library that is now electron
was built and maintained by a guy named
chang and so he still worked on the core
library and then i
worked on all this other stuff that i
had put on my road map as a sort of like
prove to github that electron could be a
thing that was worthy and stand on its
own and the first thing i started with
was documentation i wanted there to be
one source of truth and luckily there
was already pretty good documentation in
the electron project
but i didn't want to over complicate
that i wanted there to be one source of
truth for documentation i wanted to
standardize it with a style guide
because
it needed standardizing
and i want to make the most of markdown
and css and html i've been on projects
that have
like adam where documentation is this
whole other thing it lives in another
repo it's dependent on
a whole other tool chain for
documentation and a whole other
templating library and there's a whole
other hurdle into onboarding
just to fix the documentation and i
wanted to make the most of what exists
now which i felt was good enough
and then of course a static site
generator
i was at github so i used jekyll and
what i ended up doing was the electron
documentation lives inside of electron
the repo
and so whenever you
download electron you get a copy of the
documentation it's all marked down um
and so i want to start from there that
is the one source of truth all changes
to documentation happen there and then
so i never
learned ruby at github so i put a bunch
of node scripts into my jekyll site that
basically
took the tar file from an electron
release would stream out the docs folder
read the file path read the content of
it which had now been standardized so it
was predictable
and then generate the front matter and
all the things that jekyll needed so
that it could then take all of those
things stream them out of the repo and
then put them nicely into a jekyll site
in the way that jekyll wants them
and
so yeah like i mentioned the style guide
was really important so that the format
of the documentation could be
predictable
so that incoming changes could
maintain this name the same
format and also
because of wanting to make the most of
css knowing that i was going to be
putting it on this jekyll site
and i would have the benefit of css so
it could make
the legibility of the documentation a
little bit better than just reading the
markdown files and so
the
style of all the documentation had to be
really thought through and predictable
and so
on the documentation on the site there's
also a few things that are a little bit
electron specific but
because it's pulling the docs from the
releases of electron we get to have
versioned
documentation on the site and then
there's a tldr line on all of the pages
because i feel like documentation often
times you go to the page and you have to
read through two long paragraphs to even
figure out if you're on the right page
or not so i wanted people to have
right at the start a place to go and
know if they're in the wrong place or
not
and then
electron blurs the lines between what's
front-end and what's back-end
and then introduces new complexity with
having two processes and so there's a
main process and a renderer process and
so
each of the documentation
tells what process it belongs to
and then because
when we're on the site and we have the
power
of css to improve readability we can do
things like
make it more clear when a method or an
event is something that only happens on
a mac system or a windows system
but it's really important to do this
without forsaking the original markdown
because i didn't want to do something so
that it looked good on the site but then
was horrible to read as markdown because
the markdown is the source of truth and
it's what ships with every
download of electron and so everything
that had to be done like pushing the
limits of
mark down and thinking about how i'm
going to style this
in css but have it not look terrible in
the markdown
and so that was
the bulk of the documentation
the next thing i worked on was what was
going to be people's first electron app
and
there are some other people at work were
like of course we'll do an electron in
it and it should be a scaffolding system
and i pushed back on that
first of all electron apps can be
anything they can be
a menu bar app that does one tiny thing
with a window this big that i mean that
tells you the time or the weather
it can also be slack so there's a huge
gulf in the kind of electron apps you
can build
not to mention you can pick your flavor
of front-end framework and all of this
stuff and so i felt like that's a huge
undertaking to build a scaffolding tool
that's going to support all these
permeations of
an electron app and even if it doesn't
support all of them then who are we to
say like well we think you should use
react we don't and if you have a tiny
menu bar app like you don't need any
framework at all and so
i went with the keep it simple approach
and you clone it it's a bare bones
electron app with an almost empty
starting window you clone the repo you
npm install you npm start
and you get an almost blank electron app
you can open up the dev tools and you
can start to poke around in it and you
can
especially i wanted to think about
people who weren't coming
from
the desktop app space because people who
are already in this space who are maybe
working at a startup that used like
chromium embedded framework and things
like this they already got it so i don't
care about them like i care about the
people who were front-end developers or
people who didn't think that they could
ever build a desktop app i wanted people
to know that in electron it's html you
can open it up you can use
the
chrome dev tools like you're used to and
start doing the things that you already
know how to do and so
with this little
easy to clone and launch app you like
very instantly almost instantly nothing
it's not that instant
you can start digging around and
changing an electron up
but i wanted to go beyond that because
it still was really hard to get across
to people what is electron why would i
use it what are the kind of things that
i can do with it and so
the next thing i did was
build an electron app that demos the
electron api
um
and i think it worked out really great
it was actually a really good tool for
this
so that you can
you can
download this app and you can go through
it and you can view the demos of the
different kind of common things that you
would do interfacing with the different
desktop system uis and
demo things like opening a new window
and so that it makes really clear like
what this stuff
means like what what's a dialogue if
you're not coming from the desktop
application world like
what you might not know exactly what a
native dialogue is so this app lets you
go in and start actually seeing these
things
in real time and i
also wanted this app to be a learning
tool inside and out and so
the code itself is structured in a way
where everything is organized and named
so that you can match it up so when i
mentioned earlier about there being the
two processes
an electron here when you open up
the code for the app you can
find exactly the name the matching name
for a feature that happened and find the
corresponding renderer and main process
files
and because
it's an electron app
and because we have node available in
our html
what each page does is actually uses
all of the sample code the app gives you
is the code itself
so we use node to read the file and then
append it to the dom and so there's also
one source of truth here so once you
update the app's code the demo app is
updated there's not they're not ever
going to be out of sync and so that was
huge for me being one person doing a
bunch of the stuff and so
that is
essentially all of the ground work that
was done and
to me
this the jam stack was essential like
keeping it simple from the start was
essential so that i could advocate for
the project so i could actually build
these things so that i could maintain
these things and it was easy to onboard
people once it became a real team and we
got more people on it it was easy to
grow from there
um
you might find yourself in a position
like this too so it's not it's not
always an altruistic thing of like i'm
doing this for the good of humankind but
you might find yourself in a position
where you need to maintain less and
onboard people faster
all right so the second part is about
spreadsheets something i love to talk
about
and this goes back to
my background is actually urban design
and architecture and i was an urban
designer at the city of boston in the
urban design technology group
and from there i went to do the code for
america fellowship which i mentioned
earlier for building open source
software for city governments and
something i took with me from city hall
into this fellowship was
a real desire to make it so that people
could edit their own content so that
there wasn't this bottleneck places
where it had to do everything because i
felt like
the web was further than that the web
was at a place where people shouldn't be
so afraid to edit their own content
and so
after that year
and a grant from mozilla i ended up with
a little library called sheet cjs for
visualizing
google spreadsheets on a website um but
i'm not going to go into sheetzy really
i just want to talk about how great
spreadsheets are
and so back to this diagram again and i
think this space is such a great space
for spreadsheets because
spreadsheets are a database with no
setup that almost everyone already knows
how to use
and if you just sit with that for a
second
like how many libraries like we talk
about the hurdles of learning the modern
web stack and
all the tool chains and all of this
stuff and even if you're already a
developer
you have to onboard into a new system
and learn how everything works and so
something that exists with no setup
and you don't have to teach people how
to use it
that's amazing
um
and so i am mostly talking about google
spreadsheets here when i say
spreadsheets but really a lot of the
stuff you could do
if you're i mean if your spreadsheet is
in
microsoft office on excel like if you
can get it to json you can still do a
lot of these things um
so websites
they have problems and so even if you're
a professional developer who
knows how to do all of this stuff there
are certain projects where these become
hurdles even for you and they're hurdles
for people who aren't
full-time developers and spreadsheets
make a lot of this easier or not a
problem at all especially when you think
about are am i going to have a
collaborator am i going to be working
with someone who's not a developer
and that's one of my favorite things
about spreadsheets is
because they are so approachable that
people are using them to do radical
awesome things in the very scary times
in which we live and so
i think there's so much untapped
potential about what we can do
that involves so many people with
spreadsheets
okay one library i want to talk about is
called tabletop js and tabletop
basically gives you the data you would
expect from the google api which the
google api doesn't give you
if you try to if you use it directly to
get your spreadsheet stuff you get a
bunch of extra stuff that you don't want
and so tabletop
clears cleans that all up for you and
returns your columns and your cells to
you
as json in a way that seems reasonable
and it's on npm you can also just use a
client side it's on a cdn
and it's pretty simple but it has
some few some options so you can use
multiple sheets if your spreadsheet has
multiple sheets you can also only use
some of the sheets if you have multiple
sheets
you can use an auth key so you don't
necessarily have to make your
spreadsheet public for everybody you can
use proxies
and so it is a great and handy library
and i loved that that's because
sometimes i feel like i'm just the
spreadsheet loving person in my own
corner
and the docs
for tabletops say like imagine it's a
read-only javascript cms that you can
edit through google docs it's like
christmas or any other gif giving
celebration
up in here and that's how i feel at
least
and i want to be clear that i'm not
talking about
using a spreadsheet to just make a
website that's a better design table or
a grid of
cells
because once you have it as json all
your data you can go wild with your css
and do whatever you want and represent
it in really cool ways so this
for example is a
tool lending library site
and if you use a google form
you also
can
one prevent people from messing up your
spreadsheet if that's a concern
but you can also
make it even more approachable to people
if you don't want people to have to look
at a spreadsheet a google form will feed
into a spreadsheet and then you can hook
that spreadsheet up to a website
and there's also no deploying like any
time someone visits your site they're
getting the latest from the spreadsheet
and that's fantastic
you can do mapping you can turn your
spreadsheet data if you have if you have
latin long data in your spreadsheet you
can turn it to geojson which sheets you
will do for you you can also go to
geojson.io if you want to learn more
about that format but then you can
feed your spreadsheet data into mapbox
maps or use leaflet or
google maps
you can also just avoid other libraries
altogether and just
use query strings and this isn't just
for mapping but
anybody that has a query string that
matches the data you have you can start
using
and then you can do totally static data
too which i have done for projects if
you have a spreadsheet that isn't going
to change that often
and doesn't have that many editors you
might want to do this you can
use the version of tabletop and node to
pull down the spreadsheet json write it
to a file and then use it as static data
with your site and you can also use it
to backup things
that way
there's also a site called if this then
that that lets you turn like almost
anything you do today into data on a
spreadsheet and i
what i like the most is that you can
kind of have your own
copy of your data essentially and like
there could be another discussion
because technically it's like on google
and i don't know the legalities of that
but in a way you have your own data and
so you can do things like
totally
display your social media in the way
that you want and or just archive it
like you will have a copy of everything
you've done
and
a space that i think is also really
interesting and to me could just expand
is the spreadsheet as a cms right like
a spreadsheet can be a cms you could
write blog posts in a spreadsheet you
could have css properties saved in a
spreadsheet and it can all feed and
alter to a website
and lastly i wanted to
just mention the site glitch which
monica mentioned too if you have not
played around with glitch
it is a great way to put
your projects in a space where people
can avoid a dev setup can just go
straight into your code start playing
with it and making their own version of
it and so it's a really approachable
onboarding experience for people i have
the spreadsheet url on glitch
so that's mine um but check out glitch
and
lastly i hope that these have been some
interesting ideas and that
you think about keeping it simple from
the start because you might be in a
position where it benefits you to keep
it simple from the start it will benefit
your teammates and it will benefit the
people
outside too as we grow this space for
all the people who don't think they are
developers but they are because everyone
is a developer
so thank you
[Music]
[Applause]
[Music]
you