Hacker Bits, March 2016

hacker bits
March 2016

new bits
Wow! What a month! Thanks to you, the first issue of
Hacker Bits has been viewed over 2,000 times! We
are beyond thrilled (and surprised!) by the reception
the magazine has received and so without further ado, here’s
what we have in store for the 2nd issue of Hacker Bits!
As always, this month’s issue comprises a round-up of the
biggest tech stories that have set the Internet ablaze, including
Paul Jones’s insightful analysis on Apple’s declining software
quality, and Ricky Yean’s heartfelt account about privilege and
inequality in Silicon Valley.
There’s also a fascinating report on t-shirt sizes by Threadbase
and a mind-bogglingly inventive commentary on mail
forwarding by Rémi Parmentier.
So dive in and enjoy the issue! And don’t forget to let us know
what else you’d like to see in Hacker Bits!
— Maureen and Ray
us@hackerbits.com
2 hacker bits

hacker bits
March 2016
Steve Ridout
Ricky Yean
Threadbase
Rémi Parmentier
Cory House
Paul Jones
Cam Jackson
Jessica Abel
Giles Clement
Mike Hadlow
Joe Armstrong
6
8
12
16
22
26
29
36
39
43
46
3 years as a one man startup
Privilege and inequality in Silicon Valley
T-shirts unravelled
Super Mail Forward: An email that evolves
as you forward it
Angular 2 versus React: There will be
blood
Apple’s declining software quality
9 things every React.js beginner should
know
Imagining your future projects is holding
you back
I built myself a 16×20-inch camera in 10
hours
Heisenberg developers
A badass way to connect programs
together
hacker bits
3

contributor bits
Steve Ridout
Started programming as a kid, copying
BASIC games line-by-line from
computer magazines. After getting his
PhD he worked at a university creating
software to simulate mechanical engineering
problems, and later at Mendeley
where he helped create reference
management software used by millions
of researchers around the world.
Readlang is his first attempt starting an
online business of his own.
Cory House
Author of “Building Applications with
React and Flux”, “Clean Code: Writing
Code for Humans” and multiple other
courses on Pluralsight. He is a Software
Architect at VinSolutions and
trains software developers internationally
on software practices like frontend
development and clean coding.
Cory is a Microsoft MVP, Telerik
Developer Expert, and founder of outlierdeveloper.com.
Paul Jones
Programmer, writer, and technology
enthusiast based in New York City.
Paul blogs about Apple, software
development, and the technology
industry.
Cam Jackson
Software development consultant who
loves working across the full stack -
from UI design and development all
the way to infrastructure automation.
He has spoken for audiences large and
small, including at 1stConf, DevOps
Melbourne, Melbourne Functional
Users Group, and as a university guest
lecturer. He writes at camjackson.net.
Jessica Abel
Author of the graphic novel La Perdida
and the comics documentary Out on
the Wire, works with creative people to
implement tools that help them actually
make their work instead of just dreaming
about it. Get a free worksheet to
discover how you can work smarter and
with less anxiety, here.
Giles Clement
Nashville-based photographer who’s
often found touring the country with his
furry four-legged friend Zeiss and a van
full of cameras and lights. He specializes
in portraiture, primarily done using
tintype photography. You can find more
of his work on his website, Facebook,
Twitter, Instagram, and Flickr.
4 hacker bits

Mike Hadlow
British software architect and developer.
He is the author of a successful
open source project and specialises in
building large-scale back-end systems.
He lives in Sussex near the south coast
of England with his wife, son and
daughter.
Joe Armstrong
Inventor of the programming language
Erlang. He has a PhD in computer
science, and is Adjunct Professor of
computer Science at the KTH Royal
Institute of Technology. He has worked
for many years as a Programmer, Academic
and Entrepreneur.
Threadbase
A new company on a mission to help
you find clothes that fit.
Rémi Parmentier
Web developer with an affection for
emails. http://www.hteumeuleu.fr
Ricky Yean
Co-founder and CEO of PRX.co, a Y
Combinator–backed startup offering
PR on demand. Previously, he started
Crowdbooster, a social media optimization
service. Yean graduated from
Stanford in 2010 with a BA in Science,
Technology, and Society and serves
on the board of BASES, a student
entrepreneurship organization. He is a
former entrepreneur-in-residence at the
Stanford-StartX startup accelerator.
Ray Li
Curator
Software engineer and data enthusiast
who has been blogging at rayli.net
for over a decade. He loves to learn,
teach and grow. You’ll usually find
him wrangling data, programming and
lifehacking.
Maureen Ker
Editor
Writer, editor, enthusiastic cook and
collector of useless kitchen gadgets.
She has authored 3 books and over 100
articles. Her work has appeared in various
children's and adult publications,
including the New York Daily News.
hacker bits
5

STARTUP
6 hacker bits

3 years as a
one man startup
By STEVE RIDOUT
I’ve spent most of the past 3 years
creating one language learning
web-app, Readlang. I wrote about
my struggle to get this off the ground
almost two years ago and was thrilled
with the response on Hacker News and
elsewhere. I’ve been meaning to write
a followup for a long time, but would
always convince myself to wait…
Just a couple more tweaks and
usage will explode. Then I’ll
have something to write about!
Well here I am, three years later.
Usage didn’t explode, but grew in fits
and starts. I’ve worked hard for 3 years
and am still making less than minimum
wage. But that’s not as bad as it might
sound.
Money
To survive as a bootstrapper, revenue is
essential. But it’s often taboo, despite
being very useful information. The
problem is that if you report a low
revenue, you may not be taken seriously.
If you earn a lot, people listen but it
invites competition and jealousy. I’m
still on the low side, so here goes…
New signups grew from 2,800 in
year 1, to 9,300 joining in year 2, and
36,800 joining in year 3. Revenue was
roughly $700 in year 1, $4100 in year
2, and $16500 in year 3. Expenses are
low so the profit in year 3 was about
$14500. That’s roughly equivalent to
£9,700 British pounds. I’d earn more
working 28 hours a week at minimum
wage. I worked a lot more than that, so
as an experienced software developer
have paid a high opportunity cost.
Will I continue with
Readlang?
I regularly question my decision to
continue pouring so much time into
Readlang. I wonder about the lucrative
life of a contractor, or the cushy
job of software developer at a large
tech company. I wonder if I’m hurting
my chances of future employment by
working so long on my own.
On the other hand, profits have
grown 480% over the past year. If this
continues, the future looks good. In
year 4 (2016) I would make a typical
UK software developer salary, and
by the end of year 5 I’d be financially
rewarded for the risk I’ve taken
compared to being employed. But that’s
still two years away. And is it even
realistic to expect the trend to continue?
I don’t know, but I’m making a bet
that while I continue to work on it, the
answer is yes.
There are easier ways of making
a living. But I’m proud of what I’m
making, and it seems to genuinely help
people to learn languages. Here are
a couple of the many quotes I’ve received
by email within the past month:
En primeras palabras quiero
decir, que me gusta muchísimo
tu pagina. Es de verdad grande
trabajo.
If your Spanish isn’t great, try reading
the above quote on Readlang.
I’m in a polyglot group, and we
all try different language tools
constantly (Memrise, Anki, FluentU,
etc), but I think Readlang
has been the “stickiest” for the
majority of us.
On top of that, prolific language learner
Alex Rawlings recently wrote of
Readlang:
This simple tool has changed the
way I learn languages forever.
Feedback like this assures me that I’m
doing something right.
Readlang is ramen profitable, helping
more people every day, and there’s
still plenty of room for improvement.
Of course I’m continuing. •
Reprinted with permission of the original author. First appeared at medium.com/@SteveRidout.
hacker bits
7

STARTUP
Privilege and inequality
in Silicon Valley
Why “few successful startup founders
grew up desperately poor”
By RICKY YEAN
My co-founder David and I
both grew up in poverty and
can call ourselves “battle-tested”
when it comes to both life
and startups, so when the talk in the
Valley turned to income inequality, our
ears perked up. For a moment, our two
worlds were colliding. Here’s a quote
from Paul Graham that got our attention.
8 hacker bits

“
test
One example of a poor mindset is to minimize
conflict because fucking up is costly
and opportunities are hard to come by...
“Closely related to poverty
is lack of social mobility. I’ve
seen this myself: you don’t have
to grow up rich or even upper
middle class to get rich as a
startup founder, but few successful
founders grew up desperately
poor.” (link)
Graham was right, and it’s a truth
we’re intimately aware of as startup
founders. Not only are the cards
stacked against us to even have the
opportunity to found a startup, but
building and sustaining a company that
is “designed to grow fast” is especially
hard if you grew up desperately poor.
David and I have been fighting this
very idea since starting our company
in 2010, and we’ve gotten pretty good
at it. The main problem is what David
and I call mindset inequality. To really
understand it, I need to put you in my
shoes. Let me take you on a personal
journey.
How I got here
When I was 11, I moved to the United
States with my dad. We were broke
in Taiwan. I picked up the English
language. My dad did not. He also
didn’t work, so I started working
when I was 14 by doing all kinds of
odd jobs. On top of that, I did all the
things immigrant kids are familiar with,
like translating or simply handling
all the business with landlords, bills,
government services, insurance, etc. I
was smart, but I wasn’t very good at
school, and not knowing the language
definitely didn’t help. My standardized
scores were bad enough that when
I decided to take school more seriously
in high school, my counselor actively
discouraged me from taking even just
one honors-level course. I had to bring
my dad to the office the next day and
told him to pretend to say some words
in Mandarin while I just demanded that
I get put in an honors-level English
class.
I remember getting a B in that
class, and that was enough to start
taking some AP courses the next year.
Unlike a lot of my peers at Stanford,
high school was no joke for me. I was
so underprepared and didn’t know
how to learn that I basically committed
to sleeping only three hours a night
and re-read the same chapters in the
textbook three times to force myself
to memorize the material. I came to
school every day with blood-shot eyes.
One time I got a stress-induced bald
spot that was pretty embarrassing, so I
learned to develop a sense of humor.
I found out about the SATs in
10th grade. I took a mock test and
scored around a 900 (out of 1600) and
panicked. I took the money I made, and
instead of helping to pay the bills, I
paid for a few SAT classes at Elite Education
Prep in my neighborhood. When
it came time to renew, I told them I
couldn’t pay anymore, but the amazing
folks at Elite decided to just let me take
classes for free and supplied me with
all the study materials. I ultimately
scored high enough that they put my
picture up on the window to market to
more students.
You can imagine how lucky I felt
when I got into Stanford on basically
a full ride (Go Card!). I spent my first
year perpetually awe-struck. All these
amazing individuals to talk to. All these
great resources to access. Stanford
successfully created this physical and
financial bubble around me that, for the
first time in my life, I didn’t have to
think too much about money. That was
extremely empowering. I felt like I was
just like my peers and that I could do
anything. I can’t emphasize this enough
so I’m just going to say it again. During
my first year at Stanford, I felt so empowered
I believed I could do anything.
Of course, that was an illusion.
Reality quickly set in. I took an
“elective” course about Contemporary
African Politics my first quarter and I
received a C+ despite grade inflation.
I didn’t know how to talk in a small
discussion-based class of 12 students.
I was scared. I was quiet. I didn’t
know how to read or skim the volume
of reading we were given, so I was
stupidly trying to read Week 1 materials
word-for-word during Week 4. I didn’t
know how to think critically about what
I was reading. At one point, Professor
Weinstein sat me down during office
hours to ask me what was wrong and
how he could help. I didn’t even know
what to tell him. In the dorm, where I
was constantly inspired by my peers, I
noticed that everyone I talked to played
an instrument, which made me feel out
of place. Instead of moving on, I surveyed
the rest of my dorm to see who
else played an instrument only to learn
that I was the odd one out. Just a poor
kid out of place. Not good enough.
Sophomore year was when it all
fell apart. Like many of my peers, I
hacker bits
9

She’d say,
“We’re not meant to be successful,
so what you’ve achieved
“is good enough!”
didn’t know what I wanted to do, so
like them, I decided to do everything. I
joined a bunch of clubs while the classes
got harder. Soon enough I fell into
a slump. When you’re in a slump, you
start to look around and find even more
ways to show yourself that you’re not
good enough. I’d go to the same classes
with friends and dormmates, but then
I’d notice how fast they were learning
the concepts while I was struggling. I
asked one of them to tutor me, and even
then I wasn’t keeping up. On top of
that, the extracurricular commitments I
picked up totally overwhelmed me, so I
shirked many of my club duties. I also
noticed that, in order to keep up socially,
I had to spend money to participate
in a lot of activities like going out to
movies or dorm ski trips — and that
was on top of having to buy my own
books. I remember having to borrow
a few hundred bucks from one of my
best friends while I applied for another
loan to cover the expenses. I remember
running to the student loan office
crying because I felt so bad. I told the
loan officer I needed the money as
soon as possible because I didn’t want
the lack of money to ruin friendships
the way it had ruined so many other
things before. I spent the next 48 hours
basically stressed as fuck until the loan
money showed up in my account and I
paid him back. He’s still one of my best
friends to this day.
The money problem was hanging
over me the entire time in school. I’d
get calls from home about money, but
there wasn’t much I could do other than
picking up a side tutoring gig. I remember
lashing out at my dad on the phone
because I didn’t want to carry him
around as baggage while I was trying
to get through Stanford like a “normal”
student. I didn’t want to have a lesser,
second-rate experience. I so desperately
wanted to maintain the illusion that I
was on equal footing. I wanted to believe
that there wasn’t anything holding
me back from achieving and that I’d
get through this.
I did.
I went on a trip led by Kimber
Lockhart and Andi Kleissner to visit
social enterprises in the Bay Area. I
learned about entrepreneurship through
companies like Kiva and World of
Good. The two of them suggested that
I join BASES, the Stanford student
group for entrepreneurial minds. Then
I fell in love. I attended Y Combinator’s
Startup School the same year
Jeff Bezos announced Amazon Web
Services. I ended up finding my niche
at Stanford as the co-president for both
BASES and AKPsi, a coed pre-business
fraternity. I worked as a young VC at
Alsop Louie Partners, where Stewart
Alsop gave me my first Apple product
(his old Macbook), then I interned at
Eventbrite, where Kevin Hartz saw
something in me that I wasn’t even
aware myself. I started working on
side projects with a very impressive
individual I met named David Tran. I
became “that guy” on campus who was
the most gung-ho about entrepreneurship.
I learned how to execute, and then
I learned how to lead. Our side project
became a startup that got funded by Y
Combinator. We raised money, built
Crowdbooster to profitability, and now
we’re building PRX, which is an even
bigger idea to offer PR services on demand.
It’s well on its way. We can talk
about that in my next post.
Mindset inequality
With that story in mind, now let
me explain mindset inequality and why
“very few successful founders grew up
desperately poor.”
I was lucky that I found something
I loved in entrepreneurship, which
helped me focus my energies away
from academic classes. I was lucky I
found out that I was good with people
and loved organizing and leading teams
to achieve great things. I was lucky
there were no other traumatic events
that knocked me further into the deep
end. I could’ve easily given into the realities,
dropped out, or just given up the
illusion and adjusted my goals — except
I chose to start a company. Starting a
company for me was the ultimate declaration
that I wanted to hold on to the
illusion and continued to believe that I
could do anything.
But because I fought hard to maintain
this illusion for myself all through
Stanford and while building the startup,
I’m extremely aware of the disconnect.
The world is clearly not a level playing
field. Just with myself and my experi-
10 hacker bits

ence, I can see a lot of buggy code in
my mind’s operating system that isn’t
conducive to building a successful
startup. Here are some of the issues
with my default mindset that I’ve had
to fix over time.
One example of a poor mindset is
to minimize conflict because fucking
up is costly and opportunities are hard
to come by, so it’s been a challenge putting
my ideas out there and defending
them. I often hear about people having
intelligent conversations at home with
their parents. I never ate at the dinner
table because we didn’t have one in the
one-bedroom apartment that I shared
with my dad. You can imagine how this
translates to pitching your startup. The
idea
“
of putting my grand idea out there
and vigorously defending it to investors
trying to tear it apart was new and
counterintuitive.
Related to that, a poor founder
tends to be less confident. My mom,
who didn’t go to college, used to say
this to me, and it bothered me a lot.
She’d say, “We’re not meant to be
successful, so what you’ve achieved
is good enough!” Compare that level
of confidence to a kid with successful
parents who’d say something along the
lines of “If you can believe it, you can
achieve it!” Now imagine walking into
a VC office having to compete with that
kid. He’s so convinced that he’s going
to change the world, and that’s going to
show in his pitch. You can’t just muster
up that confidence on the spot.
Then there’s knowing how to
manage resources. Being poor makes
you suck at using money as a resource.
My time was always cheaper growing
up, so I’d rather spend time than
spend money. I had to fix this when we
raised our first seed round, but it took
quite some time. A simple decision
to hire, for example, took a very long
time to the point that it cost us growth.
Then there are also human resources,
networks of people who can help you.
Again, growing up poor meant that
there weren’t successful aunts and
uncles who could show me the ways of
the world or even give me a little nudge
in the right direction. I’ve had to learn
to work the room, to talk to and talk
like a successful person, and to know
how to ask for help.
I’ve also noticed the huge difference
having some built-in resources can
to work at safer and more lucrative careers
that would be of more immediate
help to your family. It’s very irresponsible
to pursue the startup path, and even
if you do succeed in upgrading your
mind software to get rid of all the bugs
I mentioned above, you start to sound
and act differently from the people
you grew up with. You might even get
accused of losing your identity. This is
why successful rappers are told they’re
turning their backs on their communities
all the time.
All of this contributes to the mindset
inequality that founders like David
and me have to overcome. We think
this is the reason why poor founders
tend not to be successful. Fortunately
for us, we consider this the biggest
...inequalities that live in your mind
can keep the deck stacked against you...
make. I don’t have “friends and family”
money to get going. In fact, I’m
sending money to my dad every month
from the measly income I take out from
my startup. Knowing that you have
“friends and family” money to get going
or even some family money to help
you when you fail makes it that much
easier to be more risk-seeking and build
the appetite for hyper-growth startups.
Most of the time, potential founders
who share my background tend to work
at lucrative jobs in finance or tech until
they can take care of everyone in their
families before they even dream about
taking more risks — if they ever get
there.
Finally, there’s the constant guilt.
If you have a Stanford degree and share
my background, you’re likely the only
one they can count on at home. You
most likely would have the opportunity
chip on our shoulders. Known bug in
our mind software. We’ve overcome so
many of these issues, and we’ll keep
chipping away at it until we win. But
for others, I think it’s important to note
this: tangible inequalities — that which
can be seen and measured, like money
or access — get the majority of the attention,
and deservedly so. But inequalities
that live in your mind can keep
the deck stacked against you long after
you’ve made it out of the one-room
apartment you shared with your dad.
This is insidious, difficult-to-discuss,
and takes a long essay to explain.
David and I are living proof that if
we can upgrade and improve the way
we think, and overcome our mindset
inequality, then maybe we can help others
do the same. For me, that starts with
sharing my story so far. Stay tuned. •
Reprinted with permission of the original author. First appeared at medium.com/@rickyyean.
hacker bits
11

STARTUP
T-shirts unravelled
By THREADBASE
We washed, dried, measured
and weighed 800 of the
most popular men's t-shirts
available online. The shirts included a
wide variety of price points ($5-$50),
sizes (XXS up to 6XL) and fits ("slim",
"tall", "relaxed", etc.). After compiling
the data, we worked with beta testers
in NYC to develop an algorithm that
could recommend t-shirt brands and
sizes for a wide range of body types.
We're still tweaking the math on that
algorithm, but in the meantime, we
thought we'd share some of the data
that has surfaced from our project so
far.
12 hacker bits

Figure 1: Evolution of 10 different t-shirts over 16 washes
T-shirts widen and shorten
over time
T-shirts change in consistent ways over
time. Each time a t-shirt is washed,
it shrinks, and each time it is worn, it
expands. The expansion in the chest is
almost 2x more than the expansion in
the length and most of that expansion
happens in the first two hours of wear.
What surprised us was that over
the course of many wash cycles, the
chest and waist will drift wider and
the length will drift shorter. The chart
in Figure 1 shows the evolution of
10 different t-shirts over 16 washes,
averaged to one line. (We calibrate our
search results to the dotted lines shown
below).
A Zara XL is like a
J. Crew Medium
No two brands have the same sizing
system, and the differences between
them can be vast. The chart below pro-
vides a breakdown of chest measurements
for sizes Small, Medium, Large
and XL. The chest is measured as the
distance between the shirt's arm seams.
See Figure 2.
Expressed as chest x length, the
average Small is 19.0" x 26.3", the
average Medium is 20.5" x 27.1", the
average Large is 22.0" x 27.8", the
average XL is 23.5" x 28.6". The length
breakdown is provided below. See
Figure 3.
Fabric weight and price
have no relationship
One of our assumptions going into the
project was that cheaper t-shirts would
weigh less (per square yard). In fact,
heavier t-shirts were less expensive, on
average, than lighter ones (overall the
correlation is very weak). Commodity
cotton is cheap right now (only $0.70/
lb), so raw materials comprise only a
tiny portion of a manufacturer's cost
structure. See Figure 4.
The culprit is
manufacturing variance
You may have had this experience before:
You buy two identical articles of
clothing. They are the same brand, style
and size -- maybe even the same color.
They are exactly the same except that
one fits, and the other does not. The
problem is manufacturing variance.
To test manufacturing variance,
we measured 20 identical new t-shirts.
These shirts were priced in the $20
range. Figure 5 depicts the distribution
in chest width and length, which each
have a standard deviation of about one
fifth of an inch.
It's probably more helpful to think
about the size of a particular shirt as a
distribution, rather than an exact number.
Maximize your chance of success
as a consumer by buying t-shirts where
the average is a good fit. This way only
extreme outliers won't fit you well.
hacker bits
13

Figure 2: T-shirt chest width
Figure 3: T-shirt body length
14 hacker bits

Figure 4: Fabric weight vs. price
Figure 6: T-shirt shrinkage from first wash
Figure 5: Distribution in chest width and length
It's the dryer, not the washer, that
shrinks t-shirts
One thing you hear everywhere is that washing clothes
in hot water will cause them to shrink. While hot water
may cause shrinkage in wool garments, for cotton and
polyester t-shirts, the washer settings don't make a big
difference. The biggest determinant of shrinkage is
whether the shirt went in the dryer or not. (We wash and
dry all t-shirts using a warm wash and normal/warm dry
cycle). •
Reprinted with permission of the original author. First appeared at threadbase.com.
hacker bits
15

INTERESTING
Super Mail Forward:
An email that evolves
as you forward it
By RÉMI PARMENTIER
Last year, Litmus held a community
contest which theme was
“Emails Worth Forwarding”. In
order to participate, I created an email
I called Super Mail Forward. It’s an
email you can forward between the
desktop webmails of Gmail, Yahoo,
Outlook.com and AOL, evolving with
each forward. It’s a fantastic exercise
that taught me a lot of things specific to
these webmails. Here are a few details
to the right.
The email is composed of four
question blocks (from Super Mario
World). Every time you forward the
email on the expected webmail, in the
right order, the first unopened block
will be transformed into a mushroom of
a different color. If you send the email
on one of the four supported webmails,
but not in the expected order, the
question block corresponding to the
expected position for this webmail will
turn red.
I wanted to make this exercise in
order to see how many times you could
Super Mail Forward
16 hacker bits

If you send the email first in Gmail, the block corresponding to Gmail’s order turns red
forward an email before its code, transformed by webmails,
would become an incomprehensible mess. And to my biggest
surprise, you can go pretty far.
In fact, webmails like Yahoo, Outlook.com or AOL don’t
deteriorate the HTML code of an email when forwarding it
more than when they receive it in the first place. This means
that since Outlook.com filters the CSS background-image
property, this property will also be absent when you forward
an email from Outlook.com.
The only exception to this behavior is Gmail. On top of
filtering any class or id attributes (which is in itself already
pretty annoying), Gmail will remove any tag and
any attribute usually supported (like lang or aria-labelledby)
when you forward an email. So I quickly realized that if I
wanted to include Gmail in my list of webmails supported by
my email, it would inevitably be in the last position.
I also picked AOL as the first webmail early on, as it’s
the most permissive webmail regarding styles filtering. And
after a lot of tests and hesitations, I picked Yahoo in second
position and Outlook.com in third position.
Each block of the email is composed of sixteen lines
and sixteen columns. Each cell has a background color that
changes depending on the current case :
• either we’re on the right webmail in the expected order,
• or we’re on one of the four supported webmails but not
in the expected order,
• or we’re not on one of the supported webmails.
By default, each cell has a background property in a
style attribute corresponding to its final state as desired in
Gmail. The display in other clients is then handled with a
play on classes. The final code for each cell looks like this:
First step : AOL
When landing on AOL, the webmail prefixes each selector.
Thus, the selector .foo becomes .aolReplacedBody .foo.
In order to target AOL and activate the first block, I used
a filtering bug on AOL I discovered back then. When a
background property contains a url() to an image within a
tag, AOL incorrectly replaces the path of this image.
Thereby, the following code…
hacker bits
17

AOL
.block-fff {
background:url('http://i.imgur.com/6qtuIRR.
gif');
}
background:#fff;
…is transformed by AOL into the following:
.block-fff {
background-image:url("http://i.
imgur.com/6qtuIRR.gif");
}
background:#fff;
Yes. AOL adds HTML higgledy-piggledy in a styles
declaration. This behavior is quite inconvenient because it
will cause modern browsers to ignore any following styles.
But in my case, that suit me fine, and I was able to use this
bug to my advantage. With the following code, I activate the
mushroom for the first question block in every browser (with
the rules .step1 .mushroom-X). And then, I immediately
reactive the colors of the default block for the first step (with
the rules .step1 .block-Y). But thanks to the background
image bug, AOL will ignore these styles, and keep the mushroom
colors.
.step1 .mushroom-transparent {
background:transparent!important; }
.step1 .mushroom-000 { background:#000; }
.step1 .mushroom-fff { background:#fff; }
.step1 .mushroom-efe3af { background:#efe3af; }
.step1 .mushroom-ee1c25 { background:#ee1c25; }
.step1 .block-fff {
background:url(‘http://i.imgur.com/6qtuIRR.
gif');
}
background:#fff;
.step1 .block-f8d81f { background:#f8d81f; }
.step1 .block-d89f37 { background:#d89f37; }
.step1 .block-000 { background:#000; }
Since the making of this email, this bug was reported
to AOL and they recently fixed it! This is a good news,
of course, except that this means my forwardable email
wouldn’t work anymore. Fortunately, I was able to find
another hack in order to target AOL. Turns out AOL will
18 hacker bits

Yahoo
remove any tag that contains what it interprets as
a wrong image URL for a background. Thus the following
styles, redefining the colors of the question block, will be
completely removed by AOL.
.step1 { background:url(‘#’); }
.step1 .W { background:#fff!important; }
.step1 .X { background:#f8d81f!important; }
.step1 .Y { background:#d89f37!important; }
.step1 .Z { background:#000!important; }
Second step : Yahoo
When landing on Yahoo, the webmail once again prefixes
each selector. The initial .foo selector now looks like the
following.
#yiv9876543210 .yiv9876543210aolReplacedBody
.yiv9876543210foo { }
Targeting Yahoo is a bit easier. Since last march, Yahoo
supports media queries. But not every media queries. And
when it encounters an unknown type of media, Yahoo will
remove the aforementioned type. Thus, the following CSS
code…
@media yahoo {
}
.step2 .mushroom-fff { background:#fff; }
…is transformed by Yahoo into:
@media {
}
.step2 .mushroom-fff { background:#fff; }
The styles contained in this media query will then only apply
on Yahoo, and stay there for the next forward.
Third step : Outlook.com
When landing on Outlook.com, the webmail once again
prefixes each selector. The initial .foo selector, transformed
by AOL, then by Yahoo, and then by Outlook.com now looks
like the following:
hacker bits
19

Outlook.com
#ecxyiv9876543210 .ecxyiv9876543210aolReplacedBody
.ecxyiv9876543210foo { }
In order to persist until the next forward to Gmail, the
activation of the mushroom on Outlook.com is handled with
inline styles. Since the beginning, a second background
property with an image was used to force the colors of the
default block for this step. Outlook.com will remove this
second property, leaving only the first one with the desired
background color. The code of the following cell…
…is thereby transformed by Outlook.com into:
The problem is that this also applies for the last question
block (supposed to be triggered only in Gmail). In order to
fix this, I redefined styles in a tag with the colors of
the default question block.
Since the making of this email, Microsoft started phasing
out Outlook.com to replace it with the same webmail as
Office 365. In order to target Outlook.com to display a red
question block when the email is not sent in the correct order,
I used some CSS rules prefixed by .ecx. Since this was done
only on Outlook.com, I had to find another way to target the
new Outlook Web App client. It turns out that it will strip any
attribute selector in a CSS rule. Thus, the following selector:
[owa] .W { background:#fff!important; }
…is transformed into:
.W { background:#fff!important; }
This is a pretty convenient way to target only Outlook Web
App clients.
Final step : Gmail
When landing on Gmail, all the class attributes in the
HTML are removed. There’s no longer any rule in a
tag that applies. Only inline styles are left, corresponding to
the final result desired.
20 hacker bits

Voilà!
Optimizations
The longest part in creating this email was optimizing the
code in order to not exceed the 100Kb limit above which
webmails block part of the content. My first version was way
above 160Kb. So I applied the following optimizations:
• Use lang attributes instead of aria-labelledby for
Gmail. This makes eleven characters less for every
single cell.
• Use shorter class names. I preferred using .A, .B, .C,
… instead of .mushroom-black, .mushroom-white,
.mushroom-red, …
• Optimize the pixels grid in order to merge cells having
a same color on both models (block and mushroom).
The pixel grid is now composed of 155 cells, instead of
256. It’s probably the most efficient optimization I made,
but also the most complex to set up. In the end, the grid
looks like this:
Conclusion
I spent around eight hours to create this email. Half of that
time was spent to create a proof of concept, and the other
half was to reproduce the pixel art and fine tune everything.
The result is still very experimental, and I doubt there’s any
application for this in a real email without spending another
whole lot of time. But this was a fun way to learn new
things. And it even helped AOL to fix a bug in their parser
along the way!
You can grab the full code of the final version here. Try
playing with it and sending it to your own email adresses
with services like Putsmail. •
Optimized pixel grid
Reprinted with permission of the original author. First appeared at medium.com/@hteumeuleu.
hacker bits
21

PROGRAMMING
Angular 2 versus React:
There will be blood
By CORY HOUSE
Angular 2 has reached Beta and
appears poised to become the
hot new framework of 2016.
It’s time for a showdown. Let’s see
how it stacks up against 2015’s darling:
React.
Disclaimer: I enjoyed working
in Angular 1 but switched to React in
2015. I just published a Pluralsight
course on React and Flux (free trial).
So yes, I’m biased. But I’m attacking
both sides.
Alright, let’s do this. There will be
blood.
You’re comparing apples
and orangutans!
Sigh. Yes, Angular is a framework, React
is a library. Some say this difference
makes comparing them illogical. Not
at all!
Choosing between Angular and
React is like choosing between
buying an off-the-shelf computer
and building your own with offthe-shelf
parts.
This post considers the merits of these
two approaches. I compare React’s
syntax and component model to Angular’s
syntax and component model.
This is like comparing an off-the-shelf
computer’s CPU to a raw CPU. Apples
to apples.
Angular 2 advantages
Let’s start by considering Angular 2’s
advantages over React.
Low decision fatigue
Since Angular is a framework, it
provides significantly more opinions
and functionality out of the box. With
React, you typically pull a number of
other libraries off the shelf to build a
real app. You’ll likely want libraries for
routing, enforcing unidirectional flows,
web API calls, testing, dependency
management, and so on. The number of
decisions is pretty overwhelming. This
is why React has so many starter kits
(I’ve published two).
Angular offers more opinions
out of the box, which helps you get
started more quickly without feeling
intimidated by decisions. This enforced
consistency also helps new hires feel at
home more quickly and makes switching
developers between teams more
practical.
I admire how the Angular core
team has embraced TypeScript, which
leads to the next advantage…
TypeScript = Clear path
Sure, TypeScript isn’t loved by all, but
Angular 2’s opinionated take on which
flavor of JavaScript to use is a big win.
React examples across the web are
frustratingly inconsistent — it’s presented
in ES5 and ES6 in roughly equal
numbers, and it currently offers three
different ways to declare components.
This creates confusion for newcomers.
(Angular also embraces decorators
instead of extends — many would consider
this a plus as well).
While Angular 2 doesn’t require
TypeScript, the Angular core team
certainly embraces it and defaults to
using TypeScript in documentation.
This means related examples and open
source projects are more likely to feel
familiar and consistent. Angular already
provides clear examples that show
how to utilize the TypeScript compiler.
22 hacker bits

(though admittedly, not everyone is
embracing TypeScript yet, but I suspect
shortly after launch it’ll become the
de facto standard). This consistency
should help avoid the confusion and decision
overload that comes with getting
started with React.
Reduced churn
2015 was the year of JavaScript fatigue.
React was a key contributor. And since
React has yet to reach a 1.0 release,
more breaking changes are likely in the
future. React’s ecosystem continues
to churn at a rapid pace, particularly
around the long list of Flux flavors and
routing. This means anything you write
in React today is likely to feel out of
date or require breaking changes when
React 1.0 is eventually released.
In contrast, Angular 2 is a careful,
methodical reinvention of a mature,
comprehensive framework. So Angular
is less likely to churn in painful ways
after release. And as a full framework,
when you choose Angular, you can
trust a single team to make careful
decisions about the future. In React,
it’s your responsibility to herd a bunch
of disparate, fast-moving, open-source
libraries into a comprehensive whole
that plays well together. It’s time-consuming,
frustrating, and a never-ending
job.
Broad tooling support
As you’ll see below, I consider React’s
JSX a big win. However, you need to
select tooling that supports JSX. React
has become so popular that tooling
support is rarely a problem today, but
new tooling such as IDEs and linters
are unlikely to support JSX on day one.
Angular 2’s templates store markup in
a string or in separate HTML files, so it
doesn’t require special tooling support
(though it appears tooling to intelligently
parse Angular’s string templates is
on the way).
Web component friendly
Angular 2’s design embraces the web
component’s standard. Sheesh, I’m
embarrassed I forgot to mention this
initially — I recently published a course
on web components! In short, the
components that you build in Angular
2 should be much easier to convert
into plain, native web components than
React’s components. Sure, browser
support is still weak, but this could be a
big win in the long-term.
Angular’s approach comes with
its own set of gotchas, which is a good
segue for discussing React’s advantages…
React advantages
Alright, let’s consider what sets React
apart.
JSX
JSX is an HTML-like syntax that
compiles down to JavaScript. Markup
and code are composed in the same file.
This means code completion gives you
a hand as you type references to your
component’s functions and variables.
In contrast, Angular’s string-based templates
come with the usual downsides:
No code coloring in many editors,
limited code completion support, and
run-time failures. You’d normally
expect poor error messaging as well,
but the Angular team created their own
HTML parser to fix that. (Bravo!)
If you don’t like Angular stringbased
templates, you can move the
templates to a separate file, but then
you’re back to what I call “the old
days:” wiring the two files together in
your head, with no code completion
support or compile-time checking to
assist. That doesn’t seem like a big
deal until you’ve enjoyed life in React.
Composing components in a single
compile-time checked file is one of the
big reasons JSX is so special.
For more on why JSX is such a big
win, see JSX: The Other Side of the
Coin.
React fails fast and explicitly
When you make a typo in React’s JSX,
it won’t compile. That’s a beautiful
thing. It means you know immediately
exactly which line has an error. It tells
you immediately when you forget to
close a tag or reference a property that
doesn’t exist. In fact, the JSX compiler
specifies the line number where the
typo occurred. This behavior radically
speeds development.
In contrast, when you mistype a
variable reference in Angular 2, nothing
happens at all. Angular 2 fails quietly
at run time instead of compile-time. It
fails slowly. I load the app and wonder
why my data isn’t displaying. Not fun.
React is JavaScript-centric
Here it is. This is the fundamental
difference between React and Angular.
Unfortunately, Angular 2 remains HT-
ML-centric rather than JavaScript-centric.
Angular 2 failed to solve its most
fundamental design problem:
Angular 2 continues to put “JS”
into HTML. React puts “HTML”
into JS.
I can’t emphasize the impact of this
schism enough. It fundamentally
impacts the development experience.
Angular’s HTML-centric design
remains its greatest weakness. As I
cover in “JSX: The Other Side of the
Coin”, JavaScript is far more powerful
than HTML. Thus, it’s more logical to
enhance JavaScript to support markup
than to enhance HTML to support
logic. HTML and JavaScript need
to be glued together somehow, and
React’s JavaScript-centric approach
is fundamentally superior to Angular,
Ember, and Knockout’s HTML-centric
approach.
Here’s why…
React’s JavaScript-centric design =
Simplicity
Angular 2 continues Angular 1’s
approach of trying to make HTML
more powerful. So you have to utilize
hacker bits
23

Angular 2's unique syntax for simple
tasks like looping and conditionals. For
example, Angular 2 offers both one and
two way binding via two syntaxes that
are unfortunately quite different:
{{myVar}} //One-way binding
ngModel="myVar" //Two-way binding
In React, binding markup doesn’t
change based on this decision (it’s handled
elsewhere, as I’d argue it should
be). In either case, it looks like this:
{myVar}
Angular 2 supports inline master templates
using this syntax:
{{hero.name}}
The above snippet loops over an array
of heroes. I have multiple concerns:
• Declaring a “master template” via
a proceeding asterisk is cryptic.
• The pound sign in front of hero
declares a local template variable.
This key concept looks like needless
noise (if preferred, you can use
var).
• The ngFor adds looping semantics
to HTML via an Angular-specific
attribute.
Contrast Angular 2’s syntax above with
React’s pure JS*: (admittedly the key
property below is React-specific)
{ heroes.map(hero =>
{hero.
name}
)}
Since JS supports looping natively,
React’s JSX can simply leverage all
the power of JS for such things and do
much more with map, filter, etc.
Just read the Angular 2 Cheat
Sheet. That’s not HTML. That’s not
JavaScript. It’s Angular.
To read Angular: Learn a long
list of Angular-specific syntax.
To read React: Learn JavaScript.
React is unique in its syntactic and
conceptual simplicity. Consider iterating
in today’s popular JS frameworks/
libraries:
Ember: {{# each}}
Angular 1: ng-repeat
Angular 2: ngFor
Knockout: data-bind=”foreach”
React: JUST USE JS. :)
All except React use framework
specific replacements for something
that is native and trivial in JavaScript:
Contrasting how Angular 2 and React handle a missing closing tag
24 hacker bits

a loop. That’s the beauty of React. It
embraces the power of JavaScript to
handle markup, so no odd new syntax
is required.
Angular 2’s syntactic oddities
continue with click binding:
(click)=”onSelect(hero)"
In contrast, React again uses plain ‘ol
JavaScript:
onClick={this.onSelect.bind(this,
hero)}
And since React includes a synthetic
event system (as does Angular 2), you
don’t have to worry about the performance
implications of declaring event
handlers inline like this.
Why fill your head with a framework’s
unique syntax if you don’t have
to? Why not simply embrace the power
of JS?
Luxurious development experience
JSX’s code completion support,
compile-time checks, and rich error
messaging already create an excellent
development experience that saves both
typing and time. But combine all that
with hot reloading with time travel and
you have a rapid development experience
like no other.
Size concerns
Here’s the size of notable frameworks/
libraries, minified (source):
Angular 2: 566k (766k with RxJS)
Ember: 435k
Angular 1: 143k
React + Redux: 139k
Edit: Sorry, I had incorrect numbers
earlier that were for simple ToDoMVC
apps instead of the raw frameworks.
Also, the Angular 2 number is expected
to drop for the final release. The sizes
listed are for the framework, minified,
in the browser (no gzip is factored in
here).
To make a real comparison, I built
Angular 2’s Tour of Heroes app in both
Angular 2 and React (I used the new
React Slingshot starter kit). The result?
Angular 2: 764k minified
React + Redux: 151k minified
So Angular 2 is over three times the
size of a React + Redux app of comparable
simplicity. (Again, Angular 2 is
expected to lose some weight before
the final release.
Now that said, I admit that concerns
about the size of frameworks may
be overblown:
Large apps tend to have a
minimum of several hundred
kilobytes of code — often
more — whether they’re built
with a framework or not. Developers
need abstractions to build
complex software, and whether
they come from a framework or
are hand-written, they negatively
impact the performance of apps.
Even if you were to eliminate
frameworks entirely, many apps
would still have hundreds of
kilobytes of JavaScript. — Tom
Dale in JavaScript Frameworks
and Mobile Performance
Tom is right. Frameworks like
Angular and Ember are bigger
because they offer many more
features out of the box.
However, my concern is this: many
apps don’t need everything these large
frameworks put in the box. In a world
that’s increasingly embracing microservices,
microapps, and single-responsibility
packages, React gives you the
power to “right-size” your application
by carefully selecting only what is necessary.
In a world with over 200,000
npm modules, that’s a powerful place
to be.
React embraces the Unix Philosophy
React is a library. It’s precisely the
opposite philosophy of large, comprehensive
frameworks like Angular
and Ember. So when you select React,
you’re free to choose modern best-ofbreed
libraries that solve your problem
best. JavaScript moves fast, and React
allows you to swap out small pieces
of your application for better libraries
instead of waiting around and hoping
your framework will innovate.
Unix has stood the test of time.
Here’s why:
The philosophy of small, composable,
single-purpose tools
never goes out of style.
React is a focused, composable,
single-purpose tool used by many of
the largest websites in the world. That
bodes well for its future (That said, Angular
is used by many big names too).
Showdown summary
Angular 2 is a huge improvement over
version 1. The new component model is
simpler to grasp than v1’s directives, it
supports isomorphic/universal rendering,
and it uses a virtual DOM offering
3–10x improvements in performance.
These changes make Angular 2 very
competitive with React. There’s no
denying that its full-featured, opinionated
nature offers some clear benefits
by reducing “JavaScript fatigue”.
However, Angular 2’s size and syntax
give me pause. Angular’s commitment
to HTML-centric design makes it
complex compared to React’s simpler
JavaScript-centric model. In React, you
don’t learn framework-specific HTML
shims like ngWhatever. You spend your
time writing plain ‘ol JavaScript. That’s
the future I believe in. •
Reprinted with permission of the original author. First appeared at medium.freecodecamp.com.
hacker bits
25

OPINION
Apple’s declining
software quality
By PAUL JONES
26 hacker bits

“ Software quality is a nebulous and
divisive topic. There are many
parameters to software quality
– reliability, speed, user experience,
design, discoverability, and more – and
a move towards any of these virtues
leads to sacrifices in others, especially
on a limited time schedule.
Additionally, a number of forces
influence software quality over time,
like accommodating for different use
cases, changes in platform, changes in
hardware, changes in design preferences,
changes in market, changes in expectations,
and more. Finally, software
is not like digging a hole, say, where
more people really can dig a hole faster
than fewer people: in fact, more people
can often slow down a software project.
Nobody knows this better than
the technology titans of today: Apple,
Google, Facebook, Amazon, Microsoft,
IBM and Oracle have all experienced
unanticipated software problems, regressions
and high profile bugs. These
are organizations with thousands of
programmers writing and maintaining
millions of lines of code for billions of
devices. And these devices are machines
which require perfection: one
slight ambiguity of intent, any minor
breach of contract, any single unexpected
0 where there should be 1 or vice
versa has the capability the bring down
the whole system. In fact, it often does.
Countless kernel panics, stack
overflow errors, null pointer exceptions,
and memory leaks are plaguing
poor users, tired system administrators
and overworked programmers right
now. Machines are fast, but they can be
awfully dumb.
...it’s time to admit that Apple
has flown too close to the sun.
And no company is feeling the
pain of software’s nebulous nature and
hardware’s mindless computing more
than Apple right now. The underdog
that many loyal fans rooted for is now
the world’s (perhaps previous) most
valuable company.
With that, comes insanely high
expectations: they need to grow the
world’s biggest company every quarter
to keep Wall Street happy, and even
harder, they have to keep those nerds
that kept them alive through the hard
times happy too. And with release
after release of the most revolutionary
operating system ever, it’s tempting to
picture Apple like an actual Titan, in
particular Atlas, holding the world upon
his shoulders. But it seems more and
more every day that another Greek tale
is more fitting: it’s time to admit that
Apple has flown too close to the sun.
Walt Mossberg, technology journalism’s
elder statesman, has this to say
about Apple’s software quality:
In the last couple of years,
however, I’ve noticed a gradual
degradation in the quality and
reliability of Apple’s core apps,
on both the mobile iOS operating
system and its Mac OS X
platform. It’s almost as if the
tech giant has taken its eye off
the ball when it comes to these
core software products, while
it pursues big new dreams, like
smartwatches and cars.
On OS X this is especially true:
OpenGL implementation has fallen
behind the competition, the filesystem
desperately needs updating, the SDK
has needed modernizing for years,
networking and cryptography have seen
major gaffes. And that’s with regards to
the under-the-hood details, the applications
are easier targets: it’s tragic that
Aperture and iPhoto were axed in favor
of the horrifically bad Photos app (that
looks like some Frankenstein “iOS X”
app); the entire industry has left Final
Cut Pro X; I dare not plug my iPhone
in to my laptop for fear of what it might
do; the Mac App Store is the antitheses
of native application development
(again a Frankenstein of a web/native
app); and iCloud nee MobileMe nee
iTools has been an unreliable and slow
mess since day one.
This isn’t the first time that a prominent
member of the Apple community
has criticized Apple’s software quality.
Here’s Marco Arment from January of
2015:
Apple’s hardware today is amazing
— it has never been better.
But the software quality has fallen
so much in the last few years
that I’m deeply concerned for its
future. I’m typing this on a computer
whose existence I didn’t
even think would be possible yet,
but it runs an OS with embarrassing
bugs and fundamental
regressions. Just a few years
ago, we would have relentlessly
made fun of Windows users for
these same bugs on their inferior
OS, but we can’t talk anymore.
This is still as true today as it was
last year. Macs and iPhones have got-
hacker bits
27

ten thinner, more beautiful, and more
powerful; the Apple Watch and the new
Apple TV are magnificent additions to
the product line up. But I’d speculate
that part of the problem Apple is having
is that if it took 1,000 engineers to
write software for Mac when that was
the only product, it doesn’t necessarily
take 4,000 people to write software for
four product lines. In fact, 10,000 of the
same grade of engineers might not even
do it, especially without proper management
and unified goals. Apple may
not have listened to rockstar developer
Marco Arment, but Walt Mossberg will
definitely get their attention. Here’s an
“
anecdote about Steve Jobs from the last
time that Mossberg complained about
Apple’s software quality:
In Fortune’s story, Lashinsky
says Steve Jobs summoned
the entire MobileMe team for
a meeting at the company’s
on-campus Town Hall, accusing
everyone of “tarnishing Apple’s
reputation.” He told the members
of the team they “should
hate each other for having let
each other down”, and went on
to name new executives on the
spot to run the MobileMe team.
A few excerpts from the article.
“Can anyone tell me what
MobileMe is supposed to do?”
Having received a satisfactory
answer, he continues, “So why
the fuck doesn’t it do that?”
Jobs was also particularly angry
about the Wall Street Journal’s
Walt Mossberg not liking MobileMe:
“Mossberg, our friend, is no
longer writing good things about
us.”
It really is time for Tim Cook to
take action as drastic as this regarding
software quality on Apple’s existing
platforms. What worries me is that
the AAPL stock ticker and Apple the
company are in a (self-driving) crash
course with one another. AAPL needs
to launch new products to drive growth
and Apple needs to improve the products
that have already shipped. The
most valuable asset that Apple owns is
their brand, and that’s the brand that’ll
drive sales of any car that may or may
not be in development. If that brand
name is tarnished by regressions and
performance problems, what consumer
would buy a car from the brand? In
fact, anecdotally, talking to my friends,
the Apple Car already has an uphill
battle with the kerfuffle surrounding the
Maps launch.
Jim Dalrymple, in response to
Mossberg, writes:
I understand that Apple has a lot
of balls in the air, but they have
clearly taken their eye off some
of them. There is absolutely no
doubt that Apple Music is getting
better with each update to the
app, but what we have now is
more of a 1.0 version than what
we received last year.
John Gruber, in response to Dalrymple:
Maybe we expect too much from
Apple’s software. But Apple’s
hardware doesn’t have little
problems like this.
The best thing for Apple to do is
to re-take their position as a leader of
software quality before it’s too late:
consumers know that Apple’s hardware
is the very best, but more and more
they’re using apps made by Google
and Microsoft and Facebook. If this
trend doesn’t turn around, Apple will
find their breakout product and all of its
Apple can do this. It’s not too late.
growth will be owned by competitors.
And when the time comes to
launch their car, they’ll find that loyal
fans and everyday consumers will have
lost trust in the brand. Having said that,
I’m still a Mac user at home and at
work, my iPhone is a wonderful device
that enriches my life, and I’m still
finding new ways to make use of Apple
Watch. And to give credit where credit
is due: Logic Pro X has improved a lot
recently, and Music Memos is a welcome
addition to Apple’s music line up.
I even use Apple Maps. Apple can do
this. It’s not too late. But for the sake
of all us poor users, and Apple’s tired
system administrators and overworked
programmers, I hope they had started 6
months ago. •
Reprinted with permission of the original author. First appeared at sudophilosophical.com.
28 hacker bits

PROGRAMMING
9 things every React.js
beginner should know
By CAM JACKSON
I've been using React.js for about 6 months now. In the
grand scheme of things that's not very long at all, but
in the ever-churning world of JavaScript frameworks,
that just about qualifies you as a bearded elder! I've helped
out a few people lately with React starter tips, so I thought
it would be a good idea to write some of them up here to
share more broadly. These are all either things that I wish
I'd known when I started out, or things that really helped me
'get' React.
I'm going to assume that you know the absolute basics;
if the words component, props, or state are unfamiliar to you,
then you might want to read the official Getting started or
Tutorial pages. I'm also going to use JSX, because it's a much
more succinct and expressive syntax for writing components.
1. It's just a view library
Let's get the basics out of the way. React is not another MVC
framework, or any other kind of framework. It's just a library
for rendering your views. If you're coming from the MVC
world, you need to realise that React is just the 'V', part of
the equation, and you need to look elsewhere when it comes
to defining your 'M' and 'C', otherwise you're going to end up
with some really yucky React code. More on that later.
2. Keep your components small
This might seem like an obvious one, but it's worth calling
out. Every good developer knows that small classes/modules/
whatever are easier to understand, test, and maintain, and
the same is true of React components. My mistake when
starting out with React was underestimating just how small
my components should be. Of course, the exact size will
depend upon many different factors (including you and your
team's personal preference!), but in general my advice would
be to make your components significantly smaller than you
think they need to be. As an example, here is the component
that shows my latest blog entries on the home page of my
website:
const LatestPostsComponent = props => (
Latest posts
{ props.posts.map(post => ) }
);
The component itself is a , with only 2 s
inside it. The first one has a heading, and second one just
maps over some data, rendering a for each
element. That last part, extracting the as its
own component, is the important bit. I think this is a good
size for a component.
3. Write functional components
Previously there were two choices for defining React components,
the first being React.createClass():
const MyComponent = React.createClass({
render: function() {
}
});
return ;
... and the other being ES6 classes:
class MyComponent extends React.Component {
}
render() {
}
return ;
hacker bits
29

“
React 0.14 introduced a new syntax for defining components,
as functions of props:
const MyComponent = props => (
);
This is by far my favourite method for defining React components.
Apart from the more concise syntax, this approach
can really help make it obvious when a component needs to
be split up. Let's revisit the earlier example, and imagine that
we hadn't split it up yet:
class LatestPostsComponent extends React.Component
{
render() {
}
const postPreviews = renderPostPreviews();
return (
);
Latest posts
{ postPreviews }
renderPostPreviews() {
return this.props.posts.map(post => this.
renderPostPreview(post));
}
renderPostPreview(post) {
return (
title}
{post.
{post.posted}
more...
React is...just a library for
rendering your views.
{post.blurb}
Read
}
}
);
This class isn't too bad, as far as classes go. We've already
extracted a couple of methods out of the render method
to keep things small and well-named. And we've encapsulated
the idea of rendering the latest post previews pretty well.
Let's rewrite the same code using the functional syntax:
const LatestPostsComponent = props => {
const postPreviews = renderPostPreviews(props.
posts);
};
return (
);
Latest posts
{ postPreviews }
const renderPostPreviews = posts => (
);
posts.map(post => this.renderPostPreview(post))
const renderPostPreview = post => (
{post.
title}
a>
);
{post.posted}
{post.blurb}
Read more...

ever, for me, that makes a big difference. In the class-based
example, my eyes see class LatestPostsComponent {, and
naturally scan all the way down to the closing curly bracket,
concluding "that's the end of the class, and so the end of
the component". By comparison, when I read the functional
component, I see const LatestPostsComponent = props
=> {, and scan only to the end of that function. "There's the
end of the function, and so the end of the component", I think
to myself. "But wait, what's all this other code sitting outside
of my component, in the same module? Aha! It's another
function that takes data and renders a view! I can extract that
out into a component all of it's own!"
Which is a very long-winded way of saying that functional
components help us identify ways to follow point #2.
There are also optimisations coming to React in the future,
which will make functional components more efficient
than class-based ones. (Update: It turns out that the performance
implications of functional components are much
more complicated than I realised. I still recommend writing
functional components by default, but if performance is a big
concern, then you should read and understand this and this,
and figure out what works best for you.)
It's important to note that functional components have
a few 'limitations', which I consider to be their greatest
strengths. The first is that a functional component cannot
have a ref assigned to it. While a ref can be a convenient
way for a component to 'look up' it's children and communicate
with them, my feeling is that this is The Wrong Way
to write React. refs encourage a very imperative, almost
jquery-like way of writing components, taking us away from
the functional, one-way data flow philosophy for which we
chose React in the first place!
The other big difference is that functional components
cannot have state attached to them, which is also a huge
advantage, because my next tip is to...
4. Write stateless components
I would have to say that by far, the vast, vast majority of pain
that I've felt when writing React-based apps, has been caused
by components that have too much state.
State makes components difficult to test
There's practically nothing easier to test than pure, data-in
data-out functions, so why would we throw away the opportunity
to define our components in such a way by adding
state to them? When testing stateful components, now we
need to get our components into "the right state" in order
to test their behaviour. We also need to come up with all of
the various combinations of state (which the component can
mutate at any time), and props (which the component has no
control over), and figure out which ones to test, and how to
do so. When components are just functions of input props,
testing is a lot easier. (More on testing later.)
State makes components difficult to reason about
When reading the code for a very stateful component, you
have to work a lot harder, mentally, to keep track of everything
that's going on. Questions like "Has that state been
initialised yet?", "What happens if I change this state here?",
"How many other places change this state", "Is there a race
condition on this state?", to mention a few, all become very
common. Tracing through stateful components to figure out
how they behave becomes very painful.
State makes it too easy to put business logic in the
component
Searching through components to determine behaviour is not
really something we should be doing anyway. Remember,
React is a view library, so while render logic in the components
is OK, business logic is a massive code smell. But
when so much of your application's state is right there in the
component, easily accessible by this.state, it can become
really tempting to start putting things like calculations or
validation into the component, where it does not belong. Revisiting
my earlier point, this makes testing that much harder
- you can't test render logic without the business logic getting
in the way, and vice versa!
State makes it difficult to share information to other parts
of the app
When a component owns a piece of state, it's easy to pass it
further down the component hierarchy, but any other direction
is tricky.
“
React is a view library...
while render logic in the components is OK,
business logic is a massive code smell.
hacker bits
31

“
Of course, sometimes it makes sense for a particular
component to totally own a particular piece of state. In which
case, fine, go ahead use this.setState. It's a legitimate part
of the React component API, and I don't want to give the
impression that it should be off limits. For example, if a user
is typing into a field, it might not make sense to expose every
keypress to the whole app, and so the field may track its own
intermediate state until a blur event happens, whereupon
the final input value is sent outwards to become state stored
somewhere else. This scenario was mentioned to me by a
colleague recently, and I think it's a great example.
Just be very conscious of every time you add state to a
component. Once you start, it can become very easy to add
'just one more thing', and things get out of control before you
know it!
propTypes add a lot of safety...
frankly I see no reason not to use them
all the time.
5. Use Redux.js
In point #1, I said that React is just for views. The obvious
question then is, "Where do I put all my state and logic?" I'm
glad you asked!
You may already be aware of Flux, which is a style/pattern/architecture
for designing web applications, most commonly
ones that use React for rendering. There are several
frameworks out there that implement the ideas of Flux, but
without a doubt the one that I recommend is Redux.js*.
I'm thinking of writing a whole separate blog post on the
features and merits of Redux, but for now I'll just recommend
you read through the official tutorial at the above link,
and provide this very brief description of how Redux works:
• Components are given callback functions as props,
which they call when a UI event happens.
• Those callbacks create and dispatch actions based on
the event.
• Reducers process the actions, computing the new state.
• The new state of the whole application goes into a single
store.
• Components receive the new state as props and re-render
themselves where needed.
Most of the above concepts are not unique to Redux, but
Redux implements them in a very clean and simple way, with
a tiny API. Having switched a decent sized project over from
Alt.js to Redux, some of the biggest benefits I've found are:
• The reducers are pure functions, which simply do
oldState + action = newState. Each reducer computes
a separate piece of state, which is then all composed
together to form the whole application. This
makes all your business logic and state transitions really
easy to test.
• The API is smaller, simpler, and better documented. I've
found it much quicker and easier to learn all of the concepts,
and therefore much easier to understand the flow
of actions and information in my own projects.
• If you use it the recommended way, only a very small
number of components will depend upon Redux; all
the other components just receive state and callbacks
as props. This keeps the components very simple, and
reduces framework lock-in.
There are a few other libraries that complement Redux extremely
well, which I also recommend you use:
• Immutable.js - Immutable data structures for JavaScript!
Store your state in these, in order to make sure it isn't
mutated where it shouldn't be, and to enforce reducer
purity.
• redux-thunk - This is used for when your actions need
to have a side effect other than updating the application
state. For example, calling a REST API, or setting
routes, or even dispatching other actions.
• reselect - Use this for composable, lazily-evaluated,
views into your state. For example, for a particular component
you might want to:
––
Inject only the relevant part of the global state
tree, rather than the whole thing.
––
Inject extra derived data, like totals or validation
state, without putting it all in the store.
You don't necessarily need all of these from day one. I would
* Depending on who you ask, Redux may or may not be 'true' Flux. Personally I feel that it's aligned well-enough with the core ideas to call it a Flux
framework, but the argument is a semantic one anyway.
32 hacker bits

add Redux and Immutable.js as soon you have any state,
reselect as soon you have derived state, and redux-thunk as
soon as you have routing or asynchronous actions. Adding
them sooner rather than later will save you the effort of retro-fitting
them in later on.
beforeAll(() => {
console.error = error => {
throw new Error(error);
};
});
6. Always use propTypes
propTypes offer us a really easy way to add a bit more type
safety to our components. They look like this:
const ListOfNumbers = props => (
);
{
}
props.numbers.map(number => (
)
{number})
ListOfNumbers.propTypes = {
className: React.PropTypes.string.isRequired,
numbers: React.PropTypes.arrayOf(React.PropTypes.
number)
};
When in development (not production), if any component
is not given a required prop, or is given the wrong type for
one of its props, then React will log an error to let you know.
This has several benefits:
• It can catch bugs early, by preventing silly mistakes.
• If you use isRequired, then you don't need to check for
undefined or null as often.
• It acts as documentation, saving readers from having to
search through a component to find all the props that it
needs.
The above list looks a bit like one you might see from
someone advocating for static typing over dynamic typing.
Personally, I usually prefer dynamic typing for the ease and
speed of development it provides, but I find that propTypes
add a lot of safety to my React components, without making
things any more difficult. Frankly I see no reason not to use
them all the time.
One final tip is to make your tests fail on any propType
errors. The following is a bit of a blunt instrument, but it's
simple and it works:
7. Use shallow rendering
Testing React components is still a bit of a tricky topic. Not
because it's hard, but because it's still an evolving area, and
no single approach has emerged as the 'best' one yet. At the
moment, my go-to method is to use shallow rendering and
prop assertions.
Shallow rendering is nice, because it allows you to
render a single component completely, but without delving
into any of its child components to render those. Instead, the
resulting object will tell you things like the type and props of
the children. This gives us good isolation, allowing testing of
a single component at a time.
There are three types of component unit tests I find myself
most commonly writing:
Render logic
Imagine a component that should conditionally display either
an image, or a loading icon:
const Image = props => {
};
if (props.loading) {
}
return ;
return ;
We might test it like this:
describe('Image', () => {
it('renders a loading icon when the image is
loading', () => {
const image = shallowRender();
{
});
expect(image.type).toEqual(LoadingIcon);
it('renders the image once it has loaded', () =>
const image = shallowRender();
hacker bits
33

“
expect(image.type).toEqual('img');
});
});
Easy! I should point out that the API for shallow rendering
is slightly more complicated than what I've shown.
The shallowRender function used above is our own helper,
which wraps the real API to make it easier to use.
Revisiting our ListOfNumbers component above, here is
how we might test that the map is done correctly:
describe('ListOfNumbers', () => {
it('renders an item for each provided number', ()
=> {
At the moment, my go-to method
is to use shallow rendering
and prop assertions.
const listOfNumbers =
shallowRender();
describe('TextWithArrayOfClassNames', () => {
it('turns the array into a space-separated
string', () => {
const text = 'Hello, world!';
const classNames = ['red', 'bold', 'floatright'];
const textWithArrayOfClassNames =
shallowRender();
const childClassNames =
textWithArrayOfClassNames.props.children.props.
className;
expect(childClassNames).toEqual('red bold floatright');
});
});
expect(listOfNumbers.props.children.length).
toEqual(4);
});
});
Prop transformations
In the last example, we dug into the children of the component
being tested, to make sure that they were rendered
correctly. We can extend this by asserting that not only are
the children there, but that they were given the correct props.
This is particulary useful when a component does some
transformation on its props, before passing them on. For
example, the following component takes CSS class names
as an array of strings, and passes them down as a single,
space-separated string:
const TextWithArrayOfClassNames = props => (
);
{props.text}
One common criticism of this approach to testing is the
proliferation of props.children.props.children... While
it's not the prettiest code, personally I find that if I'm being
annoyed by writing props.children too much in the one
test, that's a sign that the component is too big, complex, or
deeply nested, and should be split up.
The other thing I often hear is that your tests become too
dependant on the component's internal implementation, so
that changing your DOM structure slightly causes all of your
tests to break. This is definitely a fair criticism, and a brittle
test suite is the last thing that anyone wants. The best way to
manage this is to (wait for it) keep your components small
and simple, which should limit the number of tests that break
due to any one component changing.
User interaction
Of course, components are not just for display, they're also
interactive:
const RedInput = props => (
/>
)

Here's my favourite way to test these:
describe('RedInput', () => {
it('passes the event to the given callback when
the value changes', () => {
const callback = jasmine.createSpy();
const redInput = shallowRender();
redInput.props.onChange('an event!');
expect(callback).toHaveBeenCalledWith('an
event!');
});
});
It's a bit of a trivial example, but hopefully you get the idea.
Integration testing
So far I've only covered unit testing components in isolation,
but you're also going to want some higher level tests in order
to ensure that your application connects up properly and
actually works. I'm not going to go into too much detail here,
but basically:
1. Render your entire tree of components (instead of
shallow rendering).
2. Reach into the DOM (using the React TestUtils, or
jQuery, etc) to find the elements you care about the
most, and then:
• Assert on their HTML attributes or contents, or
• Simulate DOM events and then assert on the
side effects (DOM or route changes, AJAX
calls, etc).
On TDD
In general, I don't use TDD when writing React components.
When working on a component, I often find myself
churning its structure quite a bit, as I try to land on the simplest
HTML and CSS that looks right in whatever browsers
I need to support. And because my component unit testing
approach tends to assert on the component structure, TDD
would cause me to be constantly fixing my tests as I tweak
the DOM, which seems like a waste of time.
The other factor to this is that the components should be
so simple that the advantages of test-first are diminished. All
of the complex logic and transformations are pulled out into
action creators and reducers, which is where I can (and do)
reap the benefits of TDD.
Which brings me to my final point about testing. In this
whole section, I've been talking about testing the components,
and that's because there's no special information needed
for testing the rest of a Redux-based app. As a framework,
Redux has very little 'magic' that goes on behind the scenes,
which I find reduces the need for excessive mocking or other
test boilerplate. Everything is just plain old functions (many
of them pure), which is a real breath of fresh air when it
comes to testing.
8. Use JSX, ES6, Babel, Webpack, and
NPM
The only React-specific thing here is JSX. For me JSX is a
no-brainer over manually calling React.createElement. The
only disadvantage is that we add a small amount of buildtime
complexity, which is easily solved with Babel.
Once we've added Babel though, there's no reason not to
go all out and use all the great ES6 features, like constants,
arrow functions, default arguments, array and object destructuring,
spread and rest operators, string interpolation, iterators
and generators, a decent module system, etc. It really
feels like JavaScript is beginning to 'grow up' as a language
these days, as long as you're prepared to spend a little bit of
time setting up the tools.
We round things out with Webpack for bundling our
code, and NPM for package management, and we're now
fully JavaScript buzzword compliant :)
9. Use the React and Redux dev tools
Speaking of tooling, the development tools for React and
Redux are pretty awesome. The React dev tools let you inspect
the rendered tree of React elements, which is incredibly
useful for seeing how things actually look in the browser.
The Redux dev tools are even more impressive, letting you
see every action that has happened, the state changes that
they caused, and even giving you the ability to travel back
in time! You can add it either as a dev dependency, or as a
browser extension.
You can also set up hot module replacement with webpack,
so that your page updates as soon as you save your
code - no browser refresh required. This makes the feedback
loops a lot more efficient when tweaking your components
and reducers.
That's it!
Hopefully that will give you a bit of a head-start on React,
and help you avoid some of the more common mistakes.
If you enjoyed this post, you might like to follow me on
Twitter, or subscribe to my RSS feed.
Thanks for reading! •
Reprinted with permission of the original author. First appeared at camjackson.net.
hacker bits
35

OPINION
Imagining your future
projects is holding you back
By JESSICA ABEL
Do you have a big creative
project in store? Do you lie
awake sometimes, thinking
about what might go into it, what the
characters or environment might look
like, how it will touch the audience in
a whole new way? Do you imagine
what it will feel like to have this project
under your belt, and what kind of effect
it will have on your life?
Let me tell you about Forest Lords.
Forest Lords is a series of ten
fantasy novels, each a 1000-page brick,
about the epic adventures of Greenleaf
Barksley, elf proletarian, and his journeys
to attain the Golden Leaf and save
his homeland from the scourge of the
Curse of the Titaness Denox.
The thing is, none of this series
exists—not even Forest Lords Volume
One: The Elven Soul. There are binders
and binders of “lore.” There are a hell
of a lot of character designs (that look
suspiciously similar to Elfquest characters).
There is the vivid, lively picture
the putative author has in his head of
how it’s going to feel to write a fantasy
series that has everyone panting for the
next book or movie or TV show.*
But there is no book. There is only
Idea Debt.
* As a matter of actual fact, there are no binders either. This concept was invented by Benjamin Frisch when he was a snotty teen to poke fun the massive
Idea Debts being racked up by others he encountered in the comics scene.
36 hacker bits

What is idea debt?
I got this term from Kazu Kibuishi
when I interviewed him for Out on the
Wire episode 7: Dark Forest. His name
for the concept was new to me, but it
solved a huge problem: what to call this
struggle with creative sunk costs that
I understand all too intimately. Here’s
Kazu:
I try not to to look at what I’m
going to do as this amazing
great grand thing. I’m not just
fulfilling some old promise that
I made a long time ago. Now
I’m actually solving problems
in the moment, and that’s so
much more exciting than than
trying to fill years of what I like
to call my “idea debt.” That’s
when you have this dream of this
awesome thing for years. You
think, “Oh, I’m going to do this
epic adventure. It’s going to be
so great.” The truth is, no matter
what you do, it will never be as
great as it is in your mind, and
so you’re really setting yourself
up for failure.
I like snowboarding, and I used
to like hitting all the jumps.
And when I would go down
the mountain, I would notice a
bunch of young snowboarders
who were waiting at the top of
the jumps.
They may look like they’re waiting
their turn. But in fact that
they’re waiting there because
they’re afraid to hit that jump.
And what they don’t realize is
that, over time they’re getting
colder.
The Idea Debt of having to make
that jump, and land it, and be
impressive, is getting greater
because of the amount of time
they’re investing, waiting there,
getting colder, at the top of the
hill.
By the time they actually do it,
they’re probably not going to
fulfill that dream. So I learned to
just hit the jump or pass it. Do it
in the moment, or not at all.
Idea Debt is when you spend too
much time picturing what a project is
going to be like, too much time thinking
about how awesome it will be to
have this thing done and in the world,
too much time imagining how cool you
will look, how in demand you’ll be,
how much money you’ll make. And
way too little time actually making the
thing.
If…
• You tell 15 friends about your
screenplay idea, but devote zero
time in your week to facing the
blank screen.
• You buy a domain name, spend
weeks or months researching and
reading up on how to build a website,
but you don’t actually install
WordPress.
• You have a drawer full of half-finished
stories and novels and a todo
list item every week that reads,
“work on writing.”
• You’ve read 15 free online guides
to blogging, built three editorial
calendars, have notes on a dozen
posts, but you haven’t gone live
with your blog.
• You have “binders of lore” and no
book.
…you’re living with serious Idea Debt.
I’ve seen so many students struggle
for years with Idea Debt. Carrying
that debt crippled them. They were
“
Idea Debt is when you spend
too much time picturing
what a project is going to be like...
hacker bits
37

...the only way I will ever find out
whether my project represents
Idea Debt or Idea Investment
is if I create a plan
that breaks down the project
“into actionable steps...
beholden to their 12-year-old selves,
who had imagined their grown-up
future selves as famous manga authors
with 40-volume series under their belts.
But they did not have the tools yet to
actually make the work happen. And so
they invested more and more into this
grand idea, making it less and less likely
that they’d ever be able to pay it off.
They had binders of lore.
If you recognize yourself, you are
definitely not alone. There’s nothing
crazy about having Idea Debt. It’s the
most natural thing to result when you
have big creative ideas, but no real plan
for actually working towards making
them happen.
Even if you’re extremely productive,
you can have Idea Debt. There are
only so many hours in a week, and you
have to make choices. But all of those
undone things weigh us down, make it
impossible to think clearly about what
we should devote our time and energy
to now.
I carry a huge amount of Idea
Debt. But I’m thinking it’s about time
to dump it. So many of the projects on
my “someday/maybe” list belong to
other, earlier versions of me, not the me
of today.
• Screenplay of one of my books?
2007. No one is asking for it, and
I haven’t been in that headspace
since at least 2009.
• Ebook series of my unpublished
YA novel? 2006. Does that mean
I’d have to actually read it again?
• Sequel in a series? 2009. After the
first one didn’t work? Why would I
do that to myself?
• Literary graphic novel idea? That
one has been hanging around since
1998 or so.
I do have a very large idea debt
that I want to pay, however. I have a
concept for a series of paintings that
I’ve been mulling over for probably
close to 10 years. I have no plan for
showing, much less selling them. I
just want to make them so I can see
them. I can picture them so clearly. I’ve
thought about color, shape, size, even
where I’ll hang them in my house. That
I am not currently living in.
I’m not in a position right now to
start on something like that (my paint
is in that same house in Brooklyn). I
haven’t tested to see if this work will
actually be exciting and satisfying
to me. It might be pure Idea Debt.
But perhaps, it’ll turn out to be Idea
Investment, where all that dreaming
will pay off big time. (I absolutely want
to acknowledge: Idea Investment is a
crucial stage of some of your biggest,
most ambitious projects. I’ll get back to
that concept in a future post.)
And the only way I will ever find
out whether my project represents Idea
Debt or Idea Investment is if I create a
plan that breaks down the project into
actionable steps, and then actually take
those steps.
You’ve grown up. You’ve changed.
And all those old ideas you keep
returning to and investing more in just
because you feel like you ought to — I
mean, they’re your ideas! They need
care and feeding! When you kick them
all out of the house, you’ll recover
massive amounts of psychic energy.
And that energy is what you will focus
on the one thing you actually do want
to be doing, right now. •
Reprinted with permission of the original author. First appeared at jessicaabel.com.
38 hacker bits

INTERESTING
I built myself a 16×20-inch
camera in 10 hours
By GILES CLEMENT
Syndicated from PetaPixel.com
hacker bits
39

While sitting in a coffee shop
last Friday, I really didn’t
want to answer any more
emails so I went to a bar instead,
ordered a pint and sketched out a bit of
a doodle for a big camera. I then called
my buddy Zach who shares my open
schedule and vague ability with power
tools, and he stopped by my studio an
hour later.
I explained what I wanted to do
and showed him my napkin doodle. I
think his reaction was something along
the lines of “I have no idea what you’re
talking about… but sure”. So we went
to Home Depot and bought a bunch of
wood and some screws.
Ingredients
My napkin drawing wasn’t exactly a
plan and the camera kind of built itself
by what materials we found walking
around the aisles: 1/2×3” poplar for the
back standard, 3/4×1” pine for the main
rail and front standard, some in-floor
heating tube and dowels for the bellows
supports and really poor quality 1/4”
plywood for the lens board. The most
expensive thing was the bellows plastic,
6 mil black, which I’d used before
for making a darkroom in my old studio.
They only sell it in 100’ rolls and
that was $70.
Total cost for materials was $168.
Building the camera
Back in the studio we turned on a
playlist of James Bond theme music,
cracked open several beers and began
cutting stuff. The back standard came
first since that would more or less decide
the rest of the design. The standard
was just a simple 16×20 frame with 1/4”
stickers nailed around the inside to hold
the ground glass and actual ambrotype.
This was then fixed to a couple of 12”
rails on the bottom which would fit
snuggly to the bottom main rail with
thumb screws to lock the focusing
and a couple of lips on the bottom to
prevent rocking.
40 hacker bits

I’d roughly calculated how long
the camera would have to be to make
a portrait, around five feet total, so I
made the bottom rail that length. It’s
just a couple of 1×3/4” boards with four
spacers glued and screwed evenly along
the length.
We needed a ground glass and
while I’d read a bit about making them
awhile ago, the process of using grinding
compound sounded time consuming,
so I just used an orbital sander and
some 100 grit paper to grind the glass.
At some point I’ll work on a better one
since this isn’t super easy to view but it
is functional.
Next was the front standard — just
a couple of pine sticks framed out with
a 1/4” piece of plywood with a hole
for the lens. So far so good. My main
worry with building a camera of this
size were the bellows, I’d seen people
spend hundreds or thousands of dollars
either making or ordering bellows and
I wanted nothing to do with that. I’d
also told my friends that I was going
to build the camera in three hours, so I
didn’t have the time.
My solution was to put a telescoping
support on all four corners between
the front and rear standard. It’s just a
piece of 1/2” plastic tube on one end
and a 1/4” wood dowel on the other
end. This allows the whole camera to
slide back and forth for focusing while
retaining the traditional shape of a large
format camera.
This brought us to the bellows. My
friend Tristin had been helping out and
cut four panels to size, then taped the
bottom and side panels together. This
was then fitted to the camera and we
realized that we had two staple guns
which didn’t work. Both guns were
tinkered with, cursed at and hit several
times, all to no avail. So we taped
the bellows to the camera. Not ideal
but functional. The top bellows panel
was fitted and the lens was bolted to
the front which pretty much made a
camera.
hacker bits
41

Shooting the first photos
It was 2am and we were pretty tired but
I didn’t want to wait for the morning
so we cleaned off a piece of glass
and poured a plate. I should probably
mention, if it hasn’t already become
clear, that I wasn’t exactly prepared
for this whole thing. I had managed
to run by my local camera shop to get
some 16×20 trays but they only had
one and we’d need three: one for the
silver nitrate, one for the rinse, and one
for the fixer. So I scoured the studio
and came up with a huge tupperware
storage bin and one of my pelican cases
to use instead.
I had been a little nervous about
pouring a plate this large. If you’ve
ever tried the ball maze game, pouring
a plate is a bit like that. You pour collodion
on the plate and then move the
plate around till the liquid flows evenly
and completely across the surface without
losing any over the edge and then
pour the rest back into your collodion
bottle.
I definitely lost some collodion
to the ground on this one and will
definitely install a larger vent fan in my
darkroom but it wasn’t nearly as bad as
I’d thought. The glass plate was then
submerged in the silver tray to sensitize
and we went back in the studio to
adjust the lights and get focus.
Most large format cameras use
a film holder which is light tight and
allows the transport of the film to the
camera. I hadn’t had time to build a
holder so the plan was just to turn out
all the lights and walk the sensitized
plate to the camera, fire the strobes, and
pray. Which we did.
If you’ve ever sat in front of a
studio strobe you know they’re bright.
Now try turning out the lights for two
minutes and then setting off one of the
bigger commercially available strobes
four feet from your face. Tristin’s
exact words right after exposure were
“F*****k that was bright.” Trooper.
The rest of the process was the
same as smaller plates, pouring an iron
sulfate developer over the surface,
waiting for an image to appear, rinsing
and then fixing. I wasn’t really that
optimistic that we’d get an exposure
due to bellows factor and the generally
haphazard approach to this camera but
sure enough, a negative appeared and it
looked great. A little overexposed due
to the extended time it took to rinse of
the developer on such a big plate but
way better than I had expected.
I’ve made a couple of plates since
then and they’re getting better. They’re
still not perfect but that’s why I’m in
the wetplate game in the first place.
Here’s the photo-making process,
from start to finish: 16x20 Ambrotype.
My next step is to make a proper
film holder so we don’t have to subject
people to such a massive change in
light when taking photos and I’ll
probably get a staple gun and attach
the bellows properly. And if I can find
a bigger lens, I’ll probably drink a few
more beers and try to make a 20×24
camera. Because I still hate answering
emails. •
Reprinted with permission of the original author and PetaPixel.com.
42 hacker bits

OPINION
Heisenberg
developers
You cannot observe a developer
without altering their behavior
By MIKE HADLOW
First a story
Several years ago I worked on a largish
project as one of a team of developers.
We were building an internal system to
support an existing business process.
Initially things went very well. The
user requirements were reasonably
well defined and we worked effectively
iterating on the backlog. We were
mostly left to our own devices. We had
a non-technical business owner and a
number of potential users who gave
us broad objectives, and who tested
features as they became available.
When we felt that piece needed
refactoring, we spent the time to do it.
When a pain point appeared in the software
we changed the design to remove
it. We didn’t have to ask permission
to do any of things, so long features
hacker bits
43

appeared at reasonable intervals, everyone
was happy.
Then came that requirement. The
one where you try to replace an expert
user’s years of experience and intuition
with software. What started out as a
vague and wooly requirement, soon
became a monster as we started to dig
into it. We tried to push back against
it, or at least get it scheduled for a later
version of the software to be delivered
at some unspecified time in future. But
no, the business was insistent, they
wanted it in the next version.
A very clever colleague thought
the problem could be solved with a
custom DSL that would allow the users
“
out of a problematic feature, the new
guys would argue against it, saying it
was ‘ivory tower’, and not delivering
features. The PM would veto the work
and side with the new guys.
We became somewhat demotivated.
After loosing an argument about
how things should be done more than
a few times, you start to have a pretty
clear choice: knuckle down, don’t
argue and get paid, or leave. Our best
developer, the DSL guy, did leave, and
the ones of us arguing for good design
lost one of our main champions.
I learnt to inflate my estimates,
do what I was told to do, and to keep
my imagination and creativity for my
What started out as a vague and wooly
requirement, soon became a monster
as we started to dig into it.
themselves to encode their business
rules and he and another guy set to
work building it. Several months later,
he was still working on it. The business
was frustrated by the lack of progress
and the vaguely hoped for project
delivery dates began to slip. It was all a
bit of a mess.
The boss looked at this and decided
that we were loose cannons and the
ship needed tightening up. He hired a
project manager with an excellent CV
and a reputation for getting wayward
software projects under control.
He introduced us to ‘Jira’, a word
that strikes fear into the soul of a developer.
Now, rather than taking a high
level requirement and simply delivering
it at some point in the future, we would
break the feature into finely grained
tasks, estimate each of the tasks, then
break the tasks into finer grained tasks
if the estimate was more than a day’s
work.
Every two weeks we would have a
day long planning meeting where these
tasks were defined. We then spent the
next 8 days working on the tasks and
updating Jira with how long each one
took. Our project manager would be
displeased when tasks took longer than
the estimate and would immediately
assign one of the other team members
to work with the original developer to
hurry it along.
We soon learned to add plenty
of contingency to our estimates. We
were delivery focused. Any request to
refactor the software was met with disapproval,
and our time was too finely
managed to allow us refactor ‘under the
radar.’
Then a strange thing started to
happen. Everything slowed.
Of course we had no way to prove
it because there was no data from ‘pre-
PM’ to compare to ‘post-PM’, but there
was a noticeable downward notch in
the speed at which features were delivered.
With his calculations showing that
the project’s delivery date was slipping,
our PM did the obvious thing and
started hiring more developers, I think
they were mostly people he’d worked
with before.
We, the existing team had very
little say in who was hired, and it did
seem that there was something of a
cultural gap between us and the new
guys. Whenever there was any debate
about refactoring the code, or backing
evening and weekend projects. I found
it odd that few of my new colleagues
seemed to actually enjoy software
development, the talk in our office was
now more about cars than programming
languages.
They actually seemed to like the
finely grained management. As one
explained to me, “you take the next
item off the list, do the work, check it
in, and you don’t have to worry about
it.” It relieved them of the responsibility
to make difficult decisions, or take a
strategic view.
The project was not a happy one.
Features took longer and longer to be
delivered. There always seemed to be
a mounting number of bugs, few of
which seemed to get fixed, even as the
team grew. The business spent more
and more money for fewer and fewer
benefits.
44 hacker bits

Why did it all go so
wrong?
Finely grained management of software
developers is compelling to a business.
Any organization craves control. We
want to know what we are getting in
return for those expensive developer
salaries. We want to be able to accurately
estimate the time taken to deliver
a system in order to do an effective
cost-benefit analysis and to give the
business an accurate forecast of
delivery. There’s also the hope
that by building an accurate
database of estimates verses
actual effort, we can fine tune
our estimation, and by analysis
find efficiencies in the software
development process.
The problem with this
approach is that it fundamentally
misunderstands the nature of software
development. That it is a creative and
experimental process. Software development
is a complex system of multiple
poorly understood feedback loops and
interactions. It is an organic process of
trial and error, false starts, experiments
and monumental cock-ups. Numerous
studies have shown that effective
creative work is best done by motivated
autonomous experts. As developers we
need to be free to try things out, see
how they evolve, back away from bad
decisions, maybe try several different
things before we find one that works.
We don’t have hard numbers for why
we want to try this or that, or why we
want to stop in the middle of this task
and throw away everything we’ve
done. We can’t really justify all our decisions,
many them are hunches, many
of them are wrong.
If you ask me how long a feature
is going to take, my honest answer is
that I really have no idea. I may have
a ball-park idea, but there’s a long-tail
of lower-probability possibilities, that
mean that I could easily be out by a
factor of 10. What about the feature
itself? Is it really such a good idea?
I’m not just the implementer of this
software, I’m a stake holder too. What
if there’s a better way to address this
business requirement? What if we
discover a better way half way through
the estimated time? What if I suddenly
stumble on a technology or a technique
that could make a big difference to the
business? What if it’s not on the road
map?
“
Simple:
give them autonomy.
As soon as you ask a developer to
tell you exactly what he’s going to do
over the next 8 days (or worse weeks or
months), you kill much of the creativity
and serendipity. You may say that he is
free to change the estimates or the tasks
at any time, but he will still feel that
he has to at least justify the changes.
The more finely grained the tasks, the
more you kill autonomy and creativity.
No matter how much you say it doesn’t
matter if he doesn’t meet his estimates,
he’ll still feel bad about it. His response
to being asked for estimates is twofold:
first, he will learn to put in large
contingencies, just in case one of those
rabbit-holes crosses his path; second,
he will look for the quick fix, the hack
that just gets the job done. Damn technical
debt, that’s for the next poor soul
to deal with, I must meet my estimate.
Good developers are used to doing
necessary, but hard to justify work
‘under the radar’, they effectively lie to
management about what they are really
doing, but finely grained management
makes it hard to steal the time in which
to do it.
To be clear, I’m not speaking for
everyone here. Not all developers
dislike micromanagement. Some are
more attracted to the paycheck than
the art. For them, micromanagement
can be very attractive. So long as you
know how to work the system you can
happily submit inflated estimates, just
do what you’re told, and check in the
feature. If users are unhappy and the
system is buggy and late, you are not to
blame, you just did what you were told.
Finely grained
management is a recipe
for ‘talent evaporation’.
The people who live and
breathe software will leave
– they usually have few
problems getting jobs elsewhere.
The people who
don’t like to take decisions
and need an excuse, will stay. You will
find yourself with a compliant team
that meekly carries out your instructions,
doesn’t argue about the utility of
features, fills in Jira correctly, meets
their estimates, and produces very poor
quality software.
So how should one
manage developers?
Simple: give them autonomy. It seems
like a panacea, but finely grained
management is poisonous for software
development. It’s far better to give high
level goals and allow your developers
to meet them as they see fit. Sometimes
they will fail; you need to build in
contingency for this. But don’t react to
failure by putting in more process and
control. Work on building a great team
that you can trust and that can contribute
to success rather than employing
rooms full of passive code monkeys. •
Reprinted with permission of the original author. First appeared at mikehadlow.blogspot.cl.
hacker bits
45

INTERESTING
A badass way
to connect
programs
together
By JOE ARMSTRONG
What is OSC?
Open Sound Control is a binary
protocol for exchanging data between
machines.
Open Sound Control is just
about the worse possible name
for a protocol since I’d thought
for a long time that this protocol
could only be used to control
sounds. Nothing is further
from the truth. OSC should be
renamed OAC [Open Anything
Control] which would be a far
better name since it can be used
to control anything.
OSC-over-UDP is just OSC packed
data sent over a UDP connection. My
first serious encounter with OSC-over-
46 hacker bits

UDP was when I attended strangloop
and talked about The Mess We’re In.
I bumped into Sam Aaron, the
unstoppable force behind Sonic Pi.
and said that it would be really cool to
control Sonic Pi from Erlang…
Sam told me that to control Sonic
Pi all I had to do was send it OSC
encoded messages over UDP.
I was first rather skeptical to using
OSC-over-UDP but have rapidly came
to believe that this is a really-really
good way to proceed. My initial dislike
of OSC-over-UDP was colored by my
JSON-over-TCP experience. TCP is
session based which make life easy (for
some of us) and JSON is popular. On
the other hand UDP can suffer from
packet loss and OSC is an obscure protocol
- digging deeper I found myself
being more and more attracted to OSCover-UDP.
Why do I like
OSC‐over‐UDP?
To start with OSC is beautiful and what
I call “simple by design” — more on
this later. A complete OSC encoder is
tiny and can be written in any decent
language in a few pages of code. My
(incomplete) implementation osc.erl
is tiny. It’s trivial to implement and
extremely efficient. JSON on the other
hand is not so easy to implement.
I’ve always been attracted to things
that are simple and powerful. Simplicity
means they can be implemented in
few lines of code. Fewer lines of code
mean less possibility of errors and less
to maintain.
Session based TCP programs are
trivial to write in Erlang but a bugger in
any sequential language. TCP uses the
idea a session and the only rational way
to program a session is as a process or
(horrors) as a thread.
In Erlang session management
is easier than falling off a
log — one session equals one
controlling process and as many
sub-processes as you feel like.
In most other languages session
management involves mutable state
concurrency. A program that is a dozen
lines of Erlang escalates into a mess of
locks and mutexes or callbacks which
in most languages is a thin layer over a
pthreads implementation.
For those of you who haven’t
written a multi-threaded TCP socket
server in C using pthreads I can only
say “don’t go there, it’s not a pleasant
experience.” I’ve been there done that,
and have the grey hairs to prove it.
UDP is a lot simpler than TCP
and is far easier to use in sequential
languages. There are no sessions in
UDP only messages. Servers don’t have
to be multi-threaded to support sessions
but can be interrupt driven and run in a
single thread. This is wonderful news
for systems like Node.js whose concurrency
model is non-existent and whose
idea of having a fun time is throwing
promises into the future and hoping that
nobody breaks them.
Well as anybody who has watched
Casablanca knows, promises can be
broken.
For many years I’ve been saying
that it would be nice to collaborate by
sending message to each other and not
by grocking around in each other’s
messes. I basically don’t want to know
how you’ve implemented your pile of
shit, I just want to send it a message to
tell it what to do. I’d naively assumed
that something like Anything-over-TCP
would be fine and easy to implement,
so I made a system called UBF which
is a layered on top of TCP and hoped
that everybody would use it.
I guess I’d underestimated the
difficulty of implementing Anything-over-TCP
in a sequential
language. Just because it’s really
really easy in Erlang doesn’t
mean to say it’s easy in sequential
languages.
TCP sessions map 1:1 onto Erlang
programs and the programs are trivial.
But in a sequential language they map
N:1 onto a single process, which is a
pain in the butt.
For easy of implementation nothing
I know of beats OSC-over-UDP -
it’s really easy.
My first experience with this was
at the Strangeloop conference in St
Louis in 2014 — I bumped into Sam
Aaron and we got talking. I asked him
if I could remote control the Sonic Pi -
and he said “sure just send it some OSC
messages.” We sat down, I Googled a
bit and found an OSC library for Erlang
and ten minutes later we were collaborating.
I could collaborate with him by
sending him OSC messages over UDP
and didn’t have to understand one iota
of how his application was built and
structured. It didn’t matter all I had
to do was understand the messaging
protocol.
Time passed and I’d almost forgot
about this, but the other day I started
wondering how to make sounds. I’d
done this in Fun with Swift, and Midi
and wondered idly how the Sonic Pi
did this.
I thought to myself “I know what
I’ll do, I’ll build the Sonic Pi from
the sources and in doing so get to
understand how the sound generating
works.” Well as we all know building
from the sources is not easy. I tried and
failed and tweeted.
I’m now at an impasse — I’m
mailed some guys on the Sonic Pi list
who have what we think to be an identical
setup — only the build works for
them and not for me. Does that sound
familiar? You bet your sweet lives it
hacker bits
47

does. And why does it work for them
and not for me? Answer: Because the
initial state of our machines is different
and we have know way of describing
what the initial state is.
A little more digging in the Sonic
Pi code revealed that it was really the
SuperCollider scsynth program that
was making the noises and that this
talked to the Sonic Pi by sending OSCover-UDP
messages - I wonder where
Sam Arron got this idea from.
Time to learn the
SuperCollider and trace
the OSC messages
Sam helped me trace the OSC messages
to the SuperCollider and after a few
hours hacking I could send messages to
sysnth with OSC-over-UDP messaging.
Now I can build my project
without having to build nor understand
that internal structure of the scsynth or
even the Sonic Pi.
Sam wants to add a few features to
the Sonic Pi and we’ll try and do this
with an OSC-over-UDP component
written in Erlang. If this works it will
show that we can collaborate without
messing with each others code.
All of this made me realize that the
conventional way of collaboration is to
mess with each others code, simply because
it’s technically rather complicated
to build session based servers using
Anything-over-TCP semantics so the
way we collaborate is an unintentional
consequence of a bad (or nonexistent)
concurrency model.
Now I’m quite excited - the SuperCollider,
Sonic Pi and Pure Data are
all insanely great projects - if we can
get them all talking together through
communication channels when we can
make a new way of interworking not
based on the silly idea of performing
open brain surgery on other peoples
code.
We can send messages to things
and ask them to do things.
Sending message to things to get
them do do things is the central idea in
OO programming, as Alan Kay wrote.
Pity nobody does this properly for
purely local applications.
I’ve always thought that people
should be allowed to program in their
favorite programming language - if
they like Badtran-7 they they should
program in Badtran-7 but If want to
collaborate with them I should not be
forced to program in Badtran-7.
I like to write my code in Erlang
so to collaborate I’ll write my code
in Erlang you write your code in
Badtran-7 and we’ll communicate in
Anything-over-Whatnot. For ease of
implementation OSC-over-UDP looks
really good.
So what’s so good about
OSC?
To explain why I like OSC I’ll first
back off and talk about Tag-Length-
Value encodings.
Tag-Length-Value (TLV) encodings
are used to describe data structures in
packets that can be send “on the wire”.
TLV data structures are simple and
look like this:
+-----+--------+-------+
| Tag | Length | Value |
+-----+--------+-------+
Tag says what the type of the data
which follows is, Length is the size of
the data and Value the data itself.
One slight problem with TLV encodings
is alignment. If we’re sending
4 byte integers or 8 byte IEEE floats
we’d want the items to be aligned on 4
byte boundaries.
For languages that don’t care about
word alignment (like Erlang, Smalltalk,
and a few others) byte aligned TLVs
are efficient and extremely easy to
implement.
For word aligned languages, we
want to align on word boundaries.
The OSC protocol (Open Sound
Control) protocol takes a different
approach. It it’s Verb-Tag*-Value*
encoded.
First comes a Verb which is a zero
terminated string padded to a four byte
boundary. Then comments a sequence
of tags (which is also encoded as a
string) then a sequence of values - each
value corresponds to a single tag.
The tags are i for an integer d for a
double s for a string and so on.
So the tag string iisif means
that the values in the packet are int32
int32 string int32 float in that
order. Both the encoder and decoder
know how these data types are encoded
so no additional information is necessary.
The tag string also suffices as
a type descriptor that accurately
describes the type of the data in the
message - yes OSC is strongly typed.
48 hacker bits

Simplicity by design
The interesting thing about OSC encoding
is that:
• It is extremely efficient.
• Encoders/decoders can be implemented
in a few lines of code.
• It is strongly typed.
• Complex nested data structures
cannot be represented.
The last point is interesting — it means
that we’ll have to restrict our messages
to flat data structure built from simple
things like integers and strings.
To my mind this is a good thing -
this is simplicity by design. Most applications
that I have seen do not require
deeply nested complex data structures
in the communication protocols - and
if they use such data structures they’ve
probably been designed by a committee
(and yes 3GPP I’m looking at you :-).
Let’s compare this to JSON -
JSON is flexible, untyped, tricky
to parse and represent and
wasteful of space on the wire.
In other words JSON has everything
that a wire line protocol
should not have.
hacker bits
49

Why binary protocols are
important
2014 was the tipping point, where
more people access the Internet though
mobile terminals (phones) than wireline
terminals (fixed computers). For
mobile data, every bit counts. The radio
spectrum is a limited resource. Within
a given mobile cell the total bandwidth
available is a finite and fixed amount,
and this must be divided by the number
of device in the cell that are simultaneously
communicating. This is why
everything slows down in peak periods
when everybody is connected up at the
same time.
It is therefore essential not to waste
bandwidth — I think it is totally crazy
to send JSON or XML “over the air”
since this will degrade the performance
of the applications giving a bad user
experience and higher bills - since ultimately
we pay for every bit of data.
Even in fiber nets we pay one
way or another - here the costs are in
terms of energy - it uses more energy to
encode/decode verbose data structures
than well designed ones.
In the Telcomms Industry there’s
been a great deal of effort to minimize
the overheads in communication protocols
— ASN.1 sweats blood to save bits
— which are then wasted by programmers
sending JSON down the wire.
Not only does JSON/XML on
the wire waste energy, and costs more
— the user experience in a congested
net is degraded — applications that
minimize net bandwidth will there be
more attractive in a congested net than
applications that waste bandwidth.
When writing a distributed application
where the components send messages
to each other, you’d better know
well in advance exactly what messages
you’re going to send and receive and
what their types are.
OSC messages with type signatures
seems to be the perfect
balance between power and
expressiveness.
They are expressive — but not too
expressive (limiting the types to flat
sequences of atomic types) seems a
good idea — it certainly gets the job
done and are “good enough” for most
purposes.
If a protocol cannot be expressed
in sequences of OSC messages it probably
should not be used.
Finding an appropriate level for
encoding messages is difficult.
At a low level of abstractions we
could just send integers over the wire
but this would be too low level. At a
higher level we could use some form
of S-expression (like XML or JSON,
which are just verbose S-expressions)
but this is too expressive.
OSC seems to strike the right
balance.
OSC has an additional advantage
— the internal representation of
an OSC message in the programming
language of your choice is easy - why
is this? Precisely because OSC does
not have deeply nested recursive data
structures.
If you parse XML or JSON you
need to map the parse tree onto some
object structure in your language, and
since the parse trees in complex, the
object in your programming language
will be complex.
The intrinsically flat structure of
OSC is attractive, since not only the
protocols are simple, but the code to
handle then will have a simple flat
structure — again simplicity by design
rather than accident.
We could also stick OSC messages
in files, which would be easy to parse
and again have the balance of expressiveness
contra simplicity.
One measure of how good a protocol
is is the size of the implementation
and the time it took to
write it. As I said implementing
OSC is really easy, thanks mainly
to the simplicity of the design.
I’ve written a number of XML
parsers in my time, and it is not easy
and there are some unpleasant edge
cases. JSON parsers are also cumbersome
beasts.
To see just exactly how easy this is
I’ve made a lttle GitHub project where
to test these ideas. The (incomplete)
OSC encoder is in osc.erl.
The library is being used to connect
to three diffent programs and is
described in Controlling Sound With
OSC Messages. •
Reprinted with permission of the original author. First appeared at joearms.github.io.
50 hacker bits

food bit *
The waspy truth about figs…
If you have ever eaten figs, then chances
are you’ve eaten fig wasps as well. That’s
because figs are pollinated by fig wasps
that burrow deep into the fig fruit to lay their
eggs and live off the sugary bounty. This form
of you-scratch-my-back-and-I’ll-scratch-yours
relationship is known as mutualism as it benefits
both fig plant and fig wasp. But not all fig wasps
will make it out of the fig – some die and their
remains are absorbed by the fruit. And that in a
nutshell, is how we end up eating fig wasps.
* FOOD BIT is where we, enthusiasts of all edibles, sneak
in a fun fact about food.

hacker bits
HACKER BITS is the monthly magazine that gives you the hottest technology and startup stories straight from Hacker
News. We select from the top voted stories for you and publish them in an easy-to-read magazine format.
Get HACKER BITS delivered to your inbox every month! For more, visit hackerbits.com.