<p>Friends sometimes ask for my perspective when considering a role in engineering, product, or venture. I needed time in each before I could summarize the differences in culture and objective.</p>
<p>In my view, the differences are broadly defined by control, coordination, and timeline.</p>
<h2>Engineering: Control, Iteration, and Coordination</h2>
<p>As an engineer, it’s easy to fall in love with the control you have over the product and the satisfaction of quickly improving it. I loved to build fast, but would also build to make a point. “I think it’d be better this way and I’ll prove it to you.” Building to prove a point can create coordination issues (I’ve grown and I’m sorry), but on the happy path you work late to make sure great features are included in tomorrow’s build.</p>
<p>There’s a lot of good that comes from proximity and speed: (software) engineering solutions only need to be good enough and if you ship fast, you learn fast. Engineers are as close to the product as possible and many have good product sensibilities. Regardless, you can almost always go back and fix things incrementally or replace them, so there’s no need to be a perfectionist when most systems will be iterative anyway.</p>
<p>But things change once you start making larger architectural and multi-team decisions. It takes a unique (almost imaginary?) engineer to quickly and individually deliver complex projects that touch many teams and features. Instead, great architects encourage engineering practices that make complex changes simpler to coordinate and then design effective solutions that minimize unforeseen costs.</p>
<p>Even with a good plan, the "will to coordinate" needs to be continuously coaxed and it's more effective to build momentum by sharing credit for the solution. Momentum becomes a valuable commodity and, when pointed in the wrong direction, a risk.</p>
<h2>Product: Managing the Vision</h2>
<p>The best product owners have an insight that leads to a grand vision, but then hold that vision gently so they can find a viable path to expressing it. At the same time, product managers own the product’s details - crafting, prioritizing, and critiquing. These are the micro and macro goals of product, although coordination often overshadows both.</p>
<p>I have great respect for those who excel at the minutiae of product. Very few people have the intellectual stamina, talent, and mandate to perfect a product. With that said, critique is an easy skill to learn and one of the most obvious skills to over index on. Even so, very few products ever really get “AB tested to death” and most products get stuck at some modest level of polish. Getting to perfect requires time that most businesses can’t afford and a dedication to craftsmanship that is hard to sustain.</p>
<p>Managing the grand vision is its own challenge. The most obvious part of managing the grand vision is turning it into a plan - feature development, business strategy, talent allocation, and roadmaps. Less glamorous, but more critical, is educating the team on the grand vision and the plan even as they evolve.</p>
<p>In order to effectively deliver product, the team needs to be continuously educated <em>on what the vision is</em> and <em>consulted on how we will get there</em>. This takes a huge amount of time and requires constant, often repetitive communication.</p>
<p>As a junior product person, you will likely spend a huge amount of time coordinating the vision and will mostly express your creativity in the minutia of the product. This can feel like rote project management, but these are critical parts of managing the grand vision.</p>
<p>Transparently, I have a lot to learn about product. I held onto specific end states too tightly instead of the grand vision. This worked well while junior, as I could easily turn the vision into a roadmap or a feature, but I was too timid while evolving plans because of the coordination and morale cost. I also should have been more humble letting customers inform (not dictate) mid term goals, and more flexible about evolutions to the vision.</p>
<h2>Venture: Low coordination, high ambiguity</h2>
<p>Venture, to which I am newer, is a different beast altogether. Venture is much lower coordination even in larger firms and success, while seemingly secured at investment, is only confirmed years later. You cannot prove your eventual success today, so great investors perfect their process.</p>
<p>I tend to bucket investors into six categories (although they overlap substantially and there are successful investors in each category.)</p>
<ul>
<li><strong>Product</strong>: Evaluating product direction and implications for market structure, intuitive understanding of the customer</li>
<li><strong>Engineer</strong>: Viability analysis and an understanding of how technical details impact market structure</li>
<li><strong>Futurist</strong>: Strong perspectives on where the world is going</li>
<li><strong>Financier</strong>: Intuitive and analytical understanding of the market and product economics</li>
<li><strong>Heat Seeker</strong>: Discover, track, and win the hottest deals</li>
<li><strong>Angel</strong>: Identify unique talent before anyone else</li>
</ul>
<p>Time spent is also highly variable by firm, stage, and strategy. As a junior investor, you're likely sourcing (happy hours, scraping LinkedIn, helping friends), diligencing (generally much more fun than I expected), and supporting general partners.</p>
<p>Personally, I spend over 50% of my time meeting founders and learning from them. Founders are usually obsessed, often brilliant, and generally well prepared.There is hardly a greater joy than learning from an articulate, optimistic obsessive.</p>
<p>As I'm no longer exclusively thinking about one vision, I have to intentionally develop a perspective on many products, categories, and themes. This is part of the process. For me, the best perspective building happens through rigorous conversations with colleagues and founders where we hammer through complicated subjects, dissect assumptions, and explore possible scenarios. Online research is foundational, but can be a black hole, while writing helps solidify ideas and forces an opinion.</p>
<p>This process informs your perspective, but unlike engineering you won’t know the right answer for years and unlike in product you don’t own the grand vision.</p>
<h2>Final thoughts</h2>
<p>This is not advice on how to succeed at each. For instance, product managers need to be obsessed with the customer, engineers need to innovate and code review, VCs need to back the right founders. This is just the advice I give to help others understand how each role feels based, of course, on my own experiences.</p>
<p>I've been fortunate to love each role, but it took doing all three to appreciate the differences. Do you want control? Like managing visions? Comfortable with ambiguity?</p>
<p>I hope this helps and, as always, feel free to reach out.</p>


Career advice for those considering engineering, product, or venture roles.

Engineering is Control. Product is Coordination. Venture is Ambiguity.

<p>There are only a few moments when I feel comfortable posting thoughts on life, but I suppose that the end of the beginning, in my case graduating from business school, moving back home, and getting married, is one of them.</p>
<p>During my  final days of undergrad at Tufts, I remember clinging to every moment. My closest friends and I built a literal bonfire out of cardboard and beer boxes in our Cambridge, Mass backyard so we wouldn’t have to go to sleep the night before graduation. Our final days were a whirlwind of harebrained schemes designed to squeeze the juice out of every day. I was so worried that these friendships would end and the feeling of our time together could never be recaptured.</p>
<p>I did not have that feeling when I left home for college. I was sad to leave my two younger brothers and my parents. I was unsure of what my future would hold, but I knew that thanksgiving, winter break, and summer would come. My family would be home and my friends would return. That’s not to say I wasn’t nervous (I was), but I knew that I barely understood myself and I needed to explore to grow.</p>
<p>Even at Microsoft, my first job out of undergrad and at a company that can support a long and stable career, I expected change. Just five months after starting work, I learned I would be moving to Microsoft’s Beijing office. A month after returning from Beijing, I presented to Bill Gates. I’m incredibly proud of the work we did with Fluid Framework and Microsoft Loop, but I was in over my head for most of those five years. Life at Microsoft never felt settled. I was certain that Kira and I would leave Seattle and the Microsoft/Fluid chapter would end.</p>
<p>Most importantly, I knew I would have to prove to myself that I could create big things rather than just be a part of them.</p>
<p>But the last two years felt different.</p>
<p>At MIT, for the first time, I felt the instinct to double down on my strengths. Software engineering projects led me to new and interesting friendships, personal interests led to <a href="https://www.youtube.com/watch?v=i3O1S6VcwCw&#x26;list=PLtBk2p55R5TsQuxhjoAaStAir-0N0nCVG">incredible events</a>, and hobbies led to the formation of new communities.</p>
<p>Over the last two years, I hosted 39 events with 4,100+ total attendees, I helped more than 20 founders find financing or create companies, and continued to create software with CRDTs, realtime consensus algorithms, local-first concepts, crypto, and AI.</p>
<p>The end of the beginning does not mean that there won’t be change: from June 1st to October 1st, I will graduate, move twice, start a new job, and, most importantly, get married to Kira, my wonderful partner of 10 years.</p>
<p>I could not be more excited to begin the middle. I will nurture new communities, build companies, learn new skills, start a family, and continue to tinker, play, and create.</p>
<p>I just plan to do so on more solid footing, with clearer goals, and a stronger sense of self.</p>


Thoughts on moving back home and the beginning my next chapter

The End of the Beginning: Thoughts on moving back home

<h2>Why build a browser?</h2>
<p>Some estimates indicate desktop users spend 60+% of their computer time in the browser. People are spending nearly 200 minutes per day with a combination of mobile and desktop web browsing. I've heard (anonymous but reliable) rumors that US office workers spend more than three hours per day in desktop browsers.</p>
<p>Clearly, all of these user eyeballs are valuable.</p>
<p>And while Chrome (and the <a href="https://www.howtogeek.com/202825/what%E2%80%99s-the-difference-between-chromium-and-chrome/">Chromium browser project</a>) are the winners today, browsers have always been a major battlefield between tech titans (see my former employer!) Still, no one seems to be seriously investigating the strategic thinking motivating browser development.</p>
<p>So let's do it.</p>
<h2>The Landscape</h2>
<h3>Tier 1 - De Facto Standard</h3>
<p>Google's Chrome dominates with 64% of the market across desktop and mobile usage†. Chrome is synonymous with web browsing for many (most?) internet users.</p>
<div class="imageGallery">
    <div class="one">
        <img src="/posts/incentives-of-browsers/chrome-with-background.png">
    </div>
</div>
<p>Developers are an important part of Chrome's network effects. Because of Chrome's dominant market share, developers focus on Chrome compatibility first. Developers have since become <em>very familiar</em> with Chrome developer tools, and there is a growing ecosystem of Chrome developer tool extensions (React, Lighthouse, etc.) These tools allow developers to build, test, and fix websites quickly. These tools also perpetuate Chrome's dominance because developers make websites that work best in Chrome. Testing in other browsers is often an afterthought.</p>
<p>Critically, Chrome's adoption has furthered the standardization of the web. Through Chrome, Google is the gatekeeper of modern web standards: Chrome's adoption of a web standard is the most important step to widespread adoption. And this standardization makes it easier to <strong>search</strong> the web. The Google web crawler (Googlebot) can more easily ingest all Chrome-compatible websites.</p>
<p>Cynically, Chrome's dominance has allowed Google to push search optimizing technologies like AMP that go against open web standards.</p>
<blockquote>
<p>At this point, it's important to remember that Chromium is different than Chrome. Chromium is the open-source browser project that powers Google Chrome, but Microsoft Edge and other significant browsers also use Chromium.</p>
<p>While Chromium browsers have some flexibility, like choosing privacy respecting search engines, all Chromium browsers use the same JavaScript engine, and most use similar developer tools and extension APIs</p>
</blockquote>
<h3>Tier 2 - The Competition</h3>
<div class="imageGallery">
    <div class="one">
        <img src="/posts/incentives-of-browsers/tier2.png">
    </div>
</div>
<p>Apple's Safari, Microsoft Edge, and Mozilla's Firefox all have less than 10% of the market on desktop. Even Apple's Safari, installed by default on iOS, has only 26.5% of the phone browser market†. Edge and Firefox are not even top 5 mobile browsers.</p>
<blockquote>
<p>On iOS, Apple runs a similar racket to Google. All iOS browsers must use Apple's WebKit browser engine. So even if you use Chrome on iOS, you're using Apple's engine.</p>
</blockquote>
<h3>Tier 3 - Legacy</h3>
<div class="imageGallery">
    <div class="one">
        <img src="/posts/incentives-of-browsers/tier3.png">
    </div>
</div>
<p>The third tier of browsers is the legacy tier. Most developers know Internet Explorer and Opera, but these browsers are doomed to irrelevancy.</p>
<p>Internet Explorer and the Trident browser engine were the de facto web standard of the early 2000s (Internet Explorer was even more dominant than Chrome in its heyday), but Internet Explorer is deprecated; Microsoft is working hard to stop supporting the application.</p>
<p>Opera has 2% of the market and an improbable path towards success.</p>
<h3>Tier 4 - International &#x26; Boutique</h3>
<p>The fourth tier is QQ browser, Sogou Explorer, and Yandex Browser, the country and language-specific browsers. These browsers are out of Russia and China, and they only have penetration in those markets. Similarly, Samsung has a mobile browser for use on Samsung Android phones.</p>
<h3>New Wave of Browsers</h3>
<div class="imageGallery">
    <div class="one">
        <img src="/posts/incentives-of-browsers/New-Wave-of-Browsers.png">
    </div>
</div>
<p>Finally, we have the experimental browsers: Brave, with a privacy focus and crypto rewards; the Browser Company, which focuses on workplace productivity; and Mighty App, which delivers substantial performance improvements via streaming.</p>
<p>These browsers are experimenting with new business models, such as charging monthly fees or changing their relationship with advertisers.</p>
<blockquote>
<p>Over the years, dozens of companies have tried to offer new browser experiences with specialty features. Typically these browsers use the Chromium engine and layer features on top. Check out <a href="https://browser.kagi.com/">Orion Browser</a>, <a href="https://vivaldi.com/">Vivaldi</a>, <a href="https://torchbrowser.com/">Torch</a>, <a href="https://spreadprivacy.com/duckduckgo-2021-review/">DuckDuckGo</a>, <a href="https://bonsaibrowser.com/">Bonsai</a>, <a href="https://github.com/dothq/browser">Dot Browser</a>, <a href="https://sigmaos.com/">SigmaOS</a></p>
</blockquote>
<p class="footnote">
† Market-share stats are from [Statcounter Global Stats](https://gs.statcounter.com/browser-market-share). They're very googleable and  consistent across tracking sites.
</p>
<h2>Strategic Motivations</h2>
<p>With browser market share in mind, let's look at the strategic choices of the companies that build our browsers.</p>
<h3>Google's Chrome</h3>
<div class="imageGallery">
    <div class="one">
        <img src="/posts/incentives-of-browsers/chrome.png">
    </div>
</div>
<p>Chrome is worth around $50B per year to Google simply by driving search traffic. After all, <a href="https://www.ped30.com/2021/08/25/apple-google-payments-15b/">Google pays Apple $15B a year</a> for just 20% of the market.</p>
<p>But let's look historically: Google launched <a href="https://techcrunch.com/2006/10/10/google-docs-spreadsheets-launches/">Google Docs (2006)</a> <em>before</em> <a href="http://googlepress.blogspot.com/2008/09/google-chrome-new-take-on-browser_02.html">Chrome (2008)</a>. Google was attempting to drive web usage by moving traditionally desktop applications to the web before investing in a web browser.</p>
<p>With this in mind, Google built Chrome because Google needed more users on the web. When Chrome first launched, there was real alignment between web users and Google: with a better, more powerful, more consistent web experience there would be more web users and more Google searches.</p>
<p>However, user and company interests have become misaligned as Google has grown.</p>
<p>I recently heard a user-hostile story demonstrating the misalignment between Chrome users and Google's business priorities. A Google engineer decreased the latency with which the Omnibox (search bar) autocompleted a URL. E.g., "Faceboo" turns into facebook.com. Well, the improved performance of the autocomplete led to a decrease in searches because people no longer searched for "Faceboo." Ultimately, the engineer was asked to roll back that feature.</p>
<p>And there are a litany of issues like this... <a href="https://en.wikipedia.org/wiki/Accelerated_Mobile_Pages">AMP support</a>, user profiles, <a href="https://www.tomsguide.com/news/new-chrome-extension-rules-could-hobble-ad-blockers">disabling ad-block</a>, <a href="https://resources.infosecinstitute.com/topic/floc-delayed-what-does-this-mean-for-security-and-privacy/">FloCs</a>. Google's consolidation of users has, at this point, given them too much control over the future of the web.</p>
<p>Again, Google built Chrome to drive traffic to Google Search and they've certainly succeeded.</p>
<h3>Apple's Safari</h3>
<div class="imageGallery">
    <div class="one">
        <img src="/posts/incentives-of-browsers/safari.png">
    </div>
</div>
<p>Apple is focused on the continuity of its ecosystem and disrupting Google's web hegemony.</p>
<p>Looking at the ecosystem, Apple's Safari is practically a platform for their Keychain Password Manager product. It almost makes sense. The Password Manager creates a very Apple-y cohesiveness in the overall Apple ecosystem. I can easily bring a login from my iPhone to my Mac if I use Apple's browser.</p>
<p>At the same time, Apple has built a differentiated and distinctly Apple-y visual offering. Love it or hate it, this continuous design language certainly makes users aware that they're in Apple-land.</p>
<p>Apple is also making sure that Apps are better than websites. This is why Apple forces all iOS browsers to use WebKit and why Apple has not moved to fix all Web Standards incompatibilities (although Safari has improved.)</p>
<p>If mobile web development were easier, mobile web apps would become more powerful and more common. Improved mobile web apps could lead iOS users to abandon Apple's App Store and move to non-platform-specific web apps, possibly leaving Apple's beautiful walled garden.</p>
<p>Apple is profitable enough. They merely need to defend their ecosystem from attack.</p>
<h3>Mozilla's Firefox</h3>
<div class="imageGallery">
    <div class="one">
        <img src="/posts/incentives-of-browsers/firefox.png">
    </div>
</div>
<p>Further down the list, we have Mozilla Firefox. Mozilla is in a tricky spot because they're a non-differentiated offering that does not have additional revenue streams the browser can reinforce. Mozilla's only product is the Firefox browser. The rise of mobile browsing, combined with Google and Apple's stranglehold over mobile operating systems, has limited user growth prospects. There are limited ways to drive revenue with the existing product.</p>
<p>Firefox is beholden to Google because Google pays for the right to offer Google search as the preferred search engine in Firefox's Omnibox. This agreement leads to a conflict of interest because Firefox's main differentiator is a better privacy model.</p>
<p>Sadly, I believe that Firefox's privacy features are mostly marketing. Without other revenue streams to point to, Mozilla can say they care about privacy, but privacy, historically, has not been a paid feature for most users. It seems unlikely that Firefox will ever earn significant adoption again.</p>
<p>Mozilla is a true browser company but needs to find paid features fast. Expect them to pander to advertisers or copy the New Wave of Browsers.</p>
<h3>Microsoft's Edge</h3>
<div class="imageGallery">
    <div class="one">
        <img src="/posts/incentives-of-browsers/edge.png">
    </div>
</div>
<p>Microsoft Edge is the continuation of three major strategic priorities at Microsoft: embrace the web, embrace developers, and build the ecosystem. Microsoft Edge uses Google Chrome's Chromium engine as the core of the browser architecture, ensuring compatibility with the de facto web standard (Chrome compatibility.) At the same time, Microsoft Edge comes with Chrome's developer tools, which allows developers to iterate on websites while remaining within the Edge browser.</p>
<p>Microsoft Edge is also Microsoft's attempt to copy Apple's ecosystem tactics. While Microsoft owned the web with Internet Explorer (20yrs ago), that effort culminated in the Browser Wars and serious anti-trust investigations. This time, Microsoft will attempt to link Edge to Office for office workers, link Edge to Windows for home users, and link Edge to VSCode and Azure for software developers.</p>
<p>Notice that Microsoft does not need to rely on pushing search for Edge to be a good investment. While increasing Bing traffic is an ancillary benefit, it is more strategically important that developers and users love using Edge <em>with</em> other paid Microsoft services. Similar reasoning allows Microsoft to focus on privacy. Privacy appeals to high-value corporate customers.</p>
<p>Perhaps most importantly, Microsoft does not want to concede the modern browser wars if further browser investment becomes a critical strategy. So they've chosen the cheapest path by embracing Chromium.</p>
<p>Microsoft can afford to sponsor a browser team, but by embracing Chromium they're simply not disrupting the browser market significantly.</p>
<blockquote>
<p>I should note that I wrote the bulk of this essay before Microsoft announced BNPL features in Edge. I don't think that the BNPL feature changes the core priorities Microsoft has with Edge, but it is a strategically confusing move.</p>
<p>I also worked for Microsoft, but all these opinions are my own.</p>
</blockquote>
<h3>Internet Explorer</h3>
<p>Internet Explorer is the first member of the third tier. As a testament to Internet Explorer's enormous early successes, people still use IE because some early internet software only runs on the IE browser engine (Trident). But, realistically, Internet Explorer already has an expiration date: Microsoft has repeatedly announced its plans to stop supporting Internet Explorer.</p>
<p>So here IE remains...</p>
<h3>Opera</h3>
<p>Opera is doing something right now, but I'm not sure it matters. It's harder to see a path for success as Firefox's little brother. Opera is another example of a company that can't drive revenue through other products. As far as I can tell, Opera has an undifferentiated product and is unlikely to grow.</p>
<h3>Regional Browsers</h3>
<p><em>QQ Browser by Tencent (China), Sogou Explorer by Sogou (China), Yandex Browser by Yandex (Russia)</em></p>
<p>This group is interesting because they come from national technology companies. However, all three mimic strategies employed by the larger players. Sogou and Yandex, Chinese and Russian search companies, built browsers to drive revenue in their search products. They drive adoption with language-specific features. Tencent is employing a strategy similar to Microsoft or Apple by hinting at future integration with WeChat and QQ.</p>
<p>These browsers seem unlikely ever to have a significant usage breakthrough, but they are likely to stick around to support their companies' strategic initiatives.</p>
<h2>New Wave Browsers</h2>
<div class="imageGallery">
    <div class="one">
        <img src="/posts/incentives-of-browsers/new-wave-just-3.png">
    </div>
</div>
<p>Now let's talk about the new wave of browsers: Brave, Mighty App, The Browser Company, and more. These companies are making new strategic choices and adopting differentiated business models. Their strategies are not to reinforce other parts of their businesses but to build a great browser that users want. Let's hope these models allow closer alignment to user needs.</p>
<h3>Brave</h3>
<p>Brave is the most established of the new browsers. Brave offers standard browser features, but also offers a new advertising model. You can opt in to <a href="https://brave.com/compare/chrome/earning/">Brave Ads</a>, where the end user (you!) gets 70% of the ad revenue. This revenue is given in the form of Basic Attention Tokens (BAT), which can be withdrawn to a bank account or given as tips to creators.</p>
<h3>Mighty App</h3>
<p>Mighty App has the most differentiated offering and costs $30 per month. While Mighty markets itself as a browser for business, its primary offering is a significant speed improvement over traditional browsers. Mighty App streams your browsing experience from a remote VM. This trade-off between streaming bandwidth versus local memory and CPU constraints is compelling for people with cheaper or older computers or those using computational expensive web apps like Figma or Jira. The Mighty App website still talks about reducing computer fan noise when using Mighty App with Figma (compared to using Chrome with Figma.)</p>
<p>If this doesn't sound appealing to you, perhaps you're not the target audience. Imagine this: You are a designer at a small company. You use Figma for work, but you were given a crappy work laptop. Your computer hangs, dies, and generally doesn't work how you want.</p>
<p>Well, with Mighty App, your IT department doesn't need to buy you a new laptop; they can provision you a new subscription to Mighty for $30 a month. Mighty immediately improves your productivity but does not require an expensive purchase or hardware depreciation.</p>
<h3>The Browser Company</h3>
<p>The Browser Company is still in private beta, but it is branding itself as the browser for work. I've only briefly used their browser with a friend and it's unclear if The Browser Company will be paid or free.</p>
<p>I can say that the experience was excellent in my testing. The Browser Company offers first-class integration with Notion/Gmail/GDocs, powerful shortcuts, a new tab model, integrated notes, and more.</p>
<p>I could see this as a paid offering where office workers pay a small monthly fee to integrate their preferred productivity and workplace applications more deeply into the browser. Still, we'll see where The Browser Company takes their offering next.</p>
<h2>What's Next?</h2>
<p>At this point, we have to talk about the incentives that lead to the best user experiences and why regulators have been active in the browser space.</p>
<p>Simply put, consumers benefit when there is an active marketplace of browser companies attempting to attract new users.</p>
<p>Right now, this is not happening. Apple owns iOS browsers and Google, whether through Chrome or Chromium, owns the rest. The investment to build a new browser engine is too large of a task. A proliferation of Chromium browsers may reduce the profitability of Google's Chrome so that Google reduces their investment in Chrome development, but that outcome seems unlikely today. Chrome's $50B annual revenue is comparable to Tesla, Xiaomi, or Nike. Even if there's imperfect alignment between company and consumer, there's enough money to invest in improving the experience.</p>
<p>Despite my cynicism, there may be a path towards browser disruption. The New Wave of Browsers is building compelling features on top of Chromium. If one of these startups gets user traction, it could kick off a startlingly sudden change in the web ecosystem.</p>
<p>I am particularly hopeful for a paid user model, as a paid model directly aligns consumer and company incentives, but a new advertising model or some web3/crytpo solution may also work.</p>
<p>Sound off on Twitter with ideas or comments. Would love to hear what you think.</p>


The strategic chioces behind the worlds most used software

Did you really think Google would just give you a browser?

<p>Very fun weekend project. With E-Ink displays coming down in price and Raspberry Pi’s getting cheaper, I wanted to play with these new toys! A simple dashboard with the weather forecast and top headlines is an easy, but useful little project.</p>
<p>Ours is now hanging up in the kitchen...</p>
<div class="imageGallery">
    <div class="one">
        <img class="half" src="/posts/raspberry-pi-weather/Vertical.JPG">
        <img class="half" src="/posts/raspberry-pi-weather/Side_Angle.JPG">
    </div>
    <p>Almost arty photos</p>
</div>
<p>If you just want to see the code, check out the <a href="https://github.com/SamBroner/e-ink-weather">repository here</a>.</p>
<p>Read below to put this project together yourself!</p>
<h2>Supplies</h2>
<ul>
<li>Raspberry Pi w/ Wifi</li>
<li>MicroSD w/ Raspbian</li>
<li>E-Ink Display</li>
<li>2.5A Micro USB charger</li>
<li>(Optional) Keyboard, Mouse, Display, &#x26; Mini-hdmi adapter or cable</li>
</ul>
<h2>Getting Started with your Raspberry Pi</h2>
<blockquote>
<p>This is my process for setting up a RaspberryPi… if you know what you’re doing here, skip to the next section</p>
</blockquote>
<h3>Turn on the Raspberry Pi</h3>
<p>There’s been many guides written here (<a href="https://projects.raspberrypi.org/en/projects/raspberry-pi-setting-up">some</a> <a href="https://www.tomshardware.com/reviews/raspberry-pi-set-up-how-to,6029.html">of my</a> <a href="https://www.instructables.com/Ultimate-Raspberry-Pi-Configuration-Guide/">favorites</a>), but here’s the sparknotes.</p>
<ul>
<li><a href="https://projects.raspberrypi.org/en/projects/raspberry-pi-setting-up/2">Download Raspbian onto an SD card</a></li>
<li>Plug that SD card in</li>
<li>Plug in a power cable</li>
<li>Plug in keyboard, mouse, and display</li>
</ul>
<blockquote>
<p>It’s easy to get lost in the weeds when you're just getting started.
Just follow one guide and keep going.</p>
</blockquote>
<p>I like to get the <a href="https://www.raspbian.org/">Raspbian</a> UI up and running so I can get readjusted to the Raspberry Pi environment and tools.</p>
<h3>Configure the Raspberry Pi</h3>
<p>Next we’re going to make changes to the raspberry pi configuration</p>
<ul>
<li><a href="https://www.raspberrypi.org/documentation/configuration/wireless/">Connect to the internet</a> - For API access and to enable github and other developer tools</li>
<li><a href="https://www.raspberrypi.org/documentation/usage/gpio/">Enable GPIO pins</a> - For the E-Ink display connection</li>
<li><a href="https://www.raspberrypi.org/documentation/configuration/security.md"><strong>Change password</strong></a> - So we don't get <em>HACKED</em></li>
<li><a href="https://www.raspberrypi.org/documentation/remote-access/ssh/">Enable remote SSH</a> - For my preferred developer tooling setup</li>
</ul>
<h3>Connect via SSH Using VScode</h3>
<p>Let’s connect the RaspberryPI to VSCode via <a href="https://code.visualstudio.com/docs/remote/ssh">Remote-SSH</a>. This is my personal preference. It just works so dang well!</p>
<p><a href="https://www.raspberrypi.org/blog/coding-on-raspberry-pi-remotely-with-visual-studio-code/">Here's a guide to getting connected using VSCode.</a></p>
<p>So download and install VSCode and install the "Remote-SSH" plugin, then connect to the RaspberryPi by hitting CMD-Shift-P and typing in Remote-SSH. Connect to host, where the host is "RaspberryPi.local"</p>
<p>In my experience, Remote-SSH can work with a RaspberryPi 2b+, but remote shell works better with the 3 or newer. Much less stuttering, disconnecting.</p>
<h2>Connect your E-Ink Display</h2>
<p>I'm using the <a href="https://www.waveshare.com/product/displays/e-paper/epaper-1/7.5inch-e-paper-hat-b.htm">WaveShare 7.5in Red/Black/White display</a>. The RaspberryPi hat pushes directly onto the GPIO pins of the RaspberryPi.</p>
<p>To test the connection, I used the <a href="https://github.com/waveshare/e-paper">WaveShare github repository's</a> Python test scripts. They're moderately well documented, so you can just run the test script appropriate for your WaveShare display.</p>
<h2>The Code</h2>
<p>The interesting part of this project is the GitHub repository. You can check out my code here: [https://github.com/SamBroner/e-ink-weather)[https://github.com/SamBroner/e-ink-weather]</p>
<p>To get weather information, I used <a href="https://weatherapi.com/">https://weatherapi.com/</a>. To get News, I used <a href="https://newsapi.org">https://newsapi.org</a>. If you use my repo, you can clone and put your API tokens in the <code>.env</code> file.</p>
<p>It's relatively well documented, but tweet at me if you have issues and I'll update the documentation. (<a href="https://twitter.com/SamBroner">@SamBroner</a>)</p>
<h2>Hanging &#x26; Framing</h2>
<p>Ultimately, I wanted this to hang in the kitchen, so I found a cheap Shadow Box frame at a used goods store near my house.</p>
<p>I cut an opening for the ribbon cable to go from the front of the matting to the back, then glued the display &#x26; the RaspberryPi to opposite sides of the backing.</p>
<h2>Conclusion</h2>
<p>Fun project. E-Ink is great and reduced prices should lower the barriers to projects like this.</p>


A simple dashboard with the weather forecast and top headlines is an easy, but useful little project.

Building an E-Ink Weather & News Display

<p>I first heard about Snowpack as a faster Webpack, but later as part of a large toolchain ecosystem. I vaguely knew that Snowpack was making a big bet on ES modules.</p>
<p>Little did I know, my friend <a href="https://twitter.com/FredKSchott">Fred Schott</a> built the tool! <strong>Mind blown.</strong> I chatted with him after writing this and he offered a few thoughts. I'll list them at the end.</p>
<p>I was particularly interested in how <a href="https://www.snowpack.dev/#get-started">Snowpack</a> and <a href="https://www.skypack.dev/">Skypack</a>, a related project, could be used to make the <a href="https://fluidframework.com/docs/concepts/containers-runtime/">Fluid Framework's</a> Container and Code Loading model easier to reason over and easier to develop. I also suspected Snowpack would speed up our developer inner loop, which is currently affected by some classic monorepo sluggishness. (<a href="https://twitter.com/CurtisCCMan">Curtis Man</a> even made us our own <a href="https://github.com/microsoft/FluidFramework/tree/main/tools/build-tools">“build:fast”</a> command, which may seem like overkill but works quite nicely).</p>
<p>If you just want the code, go <a href="https://github.com/SamBroner/snowpack-fluid-helloworld">here</a>.</p>
<h1>Why Snowpack?</h1>
<p>I believe in Snowpack because I believe in JavaScript standards (as defined by <a href="https://en.wikipedia.org/wiki/ECMAScript">Ecma</a>)  and because I believe in <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules">ES6 modules</a>. ES modules (ESM) deserve a whole post of their own, but luckily <a href="https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/">other</a> <a href="https://flaviocopes.com/es-modules/">people</a> <a href="https://hacks.mozilla.org/2015/08/es6-in-depth-modules/">have written</a> <a href="https://blog.bitsrc.io/understanding-es-modules-in-javascript-a28fec420f73">about it</a> <a href="https://www.valentinog.com/blog/es-modules/">extensively</a>.</p>
<p>Until 2015, JavaScript did not have an official standard for code reuse. We were all sitting around relying on a mountain of hacks like AMD modules, CommonJS, and UMD just to be able to import packages. (<em>UMD is particularly funny. I implore you to read the <a href="https://github.com/umdjs/umd/blob/master/templates/commonjsStrict.js">code</a></em>.) These formats and the challenge of getting people to agree on a standard are, to some degree, the reason configuring Webpack is so complicated. Webpack takes in packages with all sorts of module types and outputs them in <em>one</em> module type (UMD by default.)</p>
<p>Well, in 2015 this changed. ECMAScript () defined ESM to be the definitive and native way of importing and exporting code. By 2019 for browsers and 2020 for NodeJS, the standard has become <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules#browser_support">common place</a>. ESM has a number of benefits: a universal syntax, direct JavaScript runtime support, fewer build tools, <a href="https://medium.com/@bluepnume/javascript-tree-shaking-like-a-pro-7bf96e139eb7">tree shaking through static analysis</a>, etc. The critical take away is that the mountain of hacks is gone and your browser can <em>directly</em> understand modules.</p>
<p>Snowpack's build creates a single ES module for each dependency in your project. This is an incredibly powerful, ECMAScript standards based approach that allows you to build dependencies once. Remember, the browser can directly understand ES modules. Once the ES module is built, other files can take a dependency on that module indefinitely without recompiling the entire dependency tree. Neat.</p>
<p>Let's dive in.</p>
<h1>Getting Started</h1>
<p>The create-snowpack-app bootstrapper is very good. I decided to start with the @snowpack/app-template-blank-typescript because I <a href="https://twitter.com/SamBroner/status/1329789543827038209">vastly prefer typescript</a>.</p>
<pre><code class="hljs language-bash">npx create-snowpack-app snowpack-test --template @snowpack/app-template-blank-typescript</code></pre>
<p>I was sitting in my kitchen, which has relatively slow WiFi speeds, but the install was reasonable and the CLI dialogue was useful. Success. Hello World!</p>
<div class="imageGallery">
    <div class="two">
        <img  src="/posts/snowpack-fluid/Hello-World.png">
        <img src="/posts/snowpack-fluid/CLI.png">
    </div>
    <p> Heeelloooo World! </p>
</div>
<p>So what do we get?</p>
<p>The directory structure is somewhat bare. We have a src/index.ts which fetches a div from the root index.html file; a public with html, css, etc; and a decent number of configuration files.</p>
<div class="imageGallery" style="width:100%">
    <div class="one">
        <img class="third" src="/posts/snowpack-fluid/file-explorer.png">
    </div>
    <p>Neat</p>
</div>
<p>There’s also a curious /types folder, which I hadn’t seen in other create-react-app style templaters, but seems designed to let me extend .d.ts files natively or import common file types natively instead of using Webpack style plugins.</p>
<pre><code class="hljs language-typescript"><span class="hljs-comment">/* Use this file to declare any custom file extensions for importing */</span>
<span class="hljs-comment">/* Use this folder to also add/extend a package d.ts file, if needed. */</span></code></pre>
<p>I think this could use some documentation because it felt like an unusual solution to pre-type common file types. I could see these typings being useful in the snowpack scenario. All dependencies get imported individually, so Snowpack better assume that we’ll use <a href="https://webpack.js.org/loaders/css-loader/">css-loader</a> style semantics! The docs make this clear.</p>
<blockquote>
<p>“Snowpack supports basic CSS imports inside of your JavaScript files. When you import a CSS file via the import keyword, Snowpack will automatically apply those styles to the page. This works for CSS and compile-to-CSS languages like Sass &#x26; Less.”</p>
<p><a href="https://www.snowpack.dev/">https://www.snowpack.dev/</a></p>
</blockquote>
<p>In fact, Snowpack supports the following file types by default.</p>
<ul>
<li>JavaScript (.js, .mjs)</li>
<li>TypeScript (.ts, .tsx)</li>
<li>JSX (.jsx, .tsx)</li>
<li>CSS (.css)</li>
<li>CSS Modules (.module.css)</li>
<li>Images (.svg, .jpg, .png, etc.)</li>
</ul>
<p>Although I could have used some clearer documentation, this is in line with the type definitions from the .d.ts file and makes sense to me. The tsconfig file does make some of this clear. It imports the src and types directories. The tsconfig also references an unusual directory, “web_modules,” as a path.</p>
<h1>Web Modules: The ES Modules Story</h1>
<p>What is this doing here?</p>
<pre><code class="hljs language-json"><span class="hljs-string">"paths"</span>: { <span class="hljs-attr">"*"</span>: [<span class="hljs-string">"web_modules/.types/*"</span>] }</code></pre>
<p>Ah. Right. ES modules. Skypack. It's all coming back.</p>
<p>While I didn't verify with Fred, my assumption is that we're calling these web modules because they're part of the native ECMA (web) standard. We can take the modules from web_modules and use them directly on the web! It seems extra relevant because I know about <a href="https://www.skypack.dev/">Skypack</a>, Snowpack’s <a href="https://www.npmjs.com/">npmjs-like</a> (<a href="https://unpkg.com/">unpkg-like</a>) cousin.</p>
<p>I was particularly curious to look in web_modules and my build directory. What does a ES6 module <strong>look</strong> like?? I'm so accustomed to my messy, bundled Webpack builds.</p>
<div class="imageGallery" style="width:100%">
    <div class="one">
        <img class="third" src="/posts/snowpack-fluid/file-explorer-build-dir.png">
    </div>
    <p>Build directory of our finished Fluid + Snowpack project</p>
</div>
<p>Good god is it clean! The directory structure makes sense and the compiled code is even better. As expected, my index.js is importing static ESMs from my web_modules directory using ES6 syntax. Completely readable. Very fast. Very elegant.</p>
<p>Look how reasonable!</p>
<pre><code class="hljs language-typescript"><span class="hljs-keyword">import</span> {getDefaultObjectFromContainer} <span class="hljs-keyword">from</span> <span class="hljs-string">"../web_modules/@fluidframework/aqueduct.js"</span>;
<span class="hljs-keyword">import</span> {getTinyliciousContainer} <span class="hljs-keyword">from</span> <span class="hljs-string">"../web_modules/@fluidframework/get-tinylicious-container.js"</span>;
<span class="hljs-keyword">import</span> {DiceRollerContainerRuntimeFactory} <span class="hljs-keyword">from</span> <span class="hljs-string">"./containerCode.js"</span>;
<span class="hljs-keyword">import</span> {renderDiceRoller} <span class="hljs-keyword">from</span> <span class="hljs-string">"./view.js"</span>;</code></pre>
<p>Anyway, these files are all accessible from the dev server on <code>npm run start</code>. For example, in the create-snowpack-app template, I can see the canvas-confetti.js module at http://localhost:8080/web_modules/canvas-confetti.js. This makes sense and I suggest reading a bit of the compiled code to get a feel for 'bare metal' ES6 syntax.</p>
<h1>npm run start</h1>
<p>Even for a such a simple project the <code>npm start</code> felt unusually snappy, although I didn’t do any experiments. If we can trust the CLI, <code>npm start</code> in the “Hello World” template typically builds in 1-2 milliseconds (in watch mode.)</p>
<div class="imageGallery" style="width:100%">
    <div class="one">
        <img src="/posts/snowpack-fluid/zero-errors.png">
    </div>
    <p> 2ms!! </p>
</div>
<p>Before we get started adding the <a href="https://github.com/microsoft/FluidHelloWorld">@fluid-example/hello-world</a> to this project, I did want to examine the snowpack.config.js file and the extension model.</p>
<h1>Extensions &#x26; Plugins</h1>
<p>The <code>@fluid-example/hello-world</code> uses HtmlWebpackPlugin by default to bind in HTML and the ts-loader to compile Typescript. Based on our earlier examination of the .d.ts and our assumptions about imports, I assume we don’t need to install an HTML parsing plugin. I couldn’t find documentation specifically indicating this, but the Snowpack.config.js file does use the <code>mount</code> keyword and reference a few folders. I assume there’s some automagic happening here to pull in the HTML.</p>
<p>The snowpack.config.js <em>does</em> include the <code>@snowpack/plugin-typescript</code> plugin. This feels pretty natural and the docs indicate there are a bunch of plugins. Many of them are <a href="https://www.snowpack.dev/plugins">officially supported</a>. Very convenient having spent some time finagling community supported Webpack plugins. I also like that “plugins” can <a href="https://www.snowpack.dev/guides/connecting-tools#connect-any-other-script%2Fcli-using-plugin-run-script-and-plugin-build-script">just be CLI commands</a> (This is worth digging into, but it allows you to use tools like postcss, eslint, etc directly from Snowpack!). That feels like an obviously useful syntax for ad hoc definition of plugins.</p>
<div class="imageGallery" style="width:100%">
    <div class="one">
        <img src="/posts/snowpack-fluid/Snowpack-Plugins.png">
    </div>
</div>
<p>I took a quick glance at the <a href="https://www.snowpack.dev/#config-files">documentation</a> for snowpack.config.js. There is a decent amount that can be done here, but I didn’t take the time to understand it. I am curious about the install, proxy, and alias configurations in particular. I can’t immediately imagine what I’d want to install at the snowpack level rather than the npm level, but this may be my misunderstanding of what’s actually going on under the hood. Either way, the template I used leaves most of these blank except <code>mount</code> and <code>plugins</code> as previously described.</p>
<p>With a basic understanding of Snowpack, I started porting over the Fluid Hello World.</p>
<p><strong>Step 1.</strong> Install dependencies. Nothing to see here, this worked as expected.</p>
<p><strong>Step 2...</strong> Copy and paste the typescript files in.</p>
<p>While we have previously done some weird things with the tsconfig, the template tsconfig and Fluid Hello World tsconfigs are pretty aligned. So I figure this should work.</p>
<p>And it mostly <strong>does</strong> seem to work. Snowpack does a much better job handling <strong>new</strong> files than Webpack does. Webpack dev server always seemed to break when new files were added to the src dir.</p>
<p>My only errors are around importing types, which we do <strong>a lot</strong>. It seems like I could modify the importsNotUsedAsValues flag in the tsconfig or just be more explicit in my imports. I chose the latter and resolved the five errors.†</p>
<div class="imageGallery" style="width:100%">
    <div class="one">
        <img src="/posts/snowpack-fluid/type-errors.png">
    </div>
</div>
<p>Errors resolved, I’m not quite out of the gate. I’m mishandling a dependency from <a href="https://fluidframework.com/apis/aqueduct/"><strong>Aqueduct</strong></a>. Aqueduct is Fluid’s convenience library (get it 😉?)</p>
<div class="imageGallery" style="width:100%">
    <div class="one">
        <img src="/posts/snowpack-fluid/aqueduct-error.png">
    </div>
</div>
<blockquote>
<p>I know it's becoming standard, but I <em>do</em> like this error dialogue. While we’ll have to see how clear the instructions are, the error and source are both clear, I can click through the possible errors, and I <strong>can clear the error</strong> dialogue! What a feature! If I click the X, I see the default HTML of the page.</p>
</blockquote>
<p>I’m also getting a <em>ton</em> of polyfill errors. This is a known usability issue with Fluid and one that we’re addressing. Snowpack made the resolution <a href="https://www.snowpack.dev/#node.js-polyfills">pretty easy</a>, although I still had lingering issues with assert. Luckily <a href="https://twitter.com/christiango">@christianGo</a> just fixed this last month and an upgrade to 0.29 Fluid libraries resolved the issue.</p>
<p>With all CLI and pop up errors gone, I tried to load again and hit a pernicious issue with our nifty <a href="https://github.com/microsoft/FluidFramework/blob/0076d7e0c23fffcf5f6df042a1f49a6838c1b111/common/lib/common-utils/src/typedEventEmitter.ts">TypedEventEmitter</a> binding to scope. For some reason, the parent here doesn’t have the <code>off</code> parameter, so binding it to my scope fails.</p>
<div class="imageGallery" style="width:100%">
    <div class="one">
        <img src="/posts/snowpack-fluid/polyfill-binding.png">
    </div>
</div>
<p>Interestingly, I could try to catch and ignore this error because <code>off</code> <a href="https://nodejs.org/api/events.html#events_emitter_off_eventname_listener">is just an alias for removeListener</a>. My guess is this is an artifact from the polyfill and a quick Google <a href="https://github.com/ionic-team/rollup-plugin-node-polyfills/issues/8">confirms this</a>. I <a href="https://github.com/ionic-team/rollup-plugin-node-polyfills/pull/18">opened a PR</a> with a solution, but saved the polyfill locally to continue on with the experiment.</p>
<pre><code class="hljs language-bash">npm install --save-dev ~/Code/rollup-plugin-node-polyfills</code></pre>
<p>And imported the rollup plugin from my dev dependencies.</p>
<pre><code class="hljs language-javascript"><span class="hljs-built_in">module</span>.exports = {
  <span class="hljs-attr">mount</span>: {
    <span class="hljs-attr">public</span>: <span class="hljs-string">'/'</span>,
    <span class="hljs-attr">src</span>: <span class="hljs-string">'/_dist_'</span>,
  },
  <span class="hljs-attr">plugins</span>: [<span class="hljs-string">'@snowpack/plugin-typescript'</span>],
  <span class="hljs-attr">install</span>: [<span class="hljs-comment">/* ... */</span>],
  <span class="hljs-attr">installOptions</span>: {
    <span class="hljs-attr">installTypes</span>: <span class="hljs-literal">true</span>,
    <span class="hljs-attr">rollup</span>: {
      <span class="hljs-comment">// @ts-ignore</span>
      <span class="hljs-attr">plugins</span>: [<span class="hljs-built_in">require</span>(<span class="hljs-string">'rollup-plugin-node-polyfills'</span>)(
        {
          <span class="hljs-attr">events</span>: <span class="hljs-literal">true</span>,
          <span class="hljs-attr">url</span>: <span class="hljs-literal">true</span>,
          <span class="hljs-attr">assert</span>:<span class="hljs-literal">true</span>,
          <span class="hljs-attr">querystring</span>: <span class="hljs-literal">true</span>,
       }
      )],
    },
  },
  <span class="hljs-attr">devOptions</span>: {<span class="hljs-comment">/* ... */</span>},
  <span class="hljs-attr">buildOptions</span>: {<span class="hljs-comment">/* ... */</span>},
  <span class="hljs-attr">proxy</span>: {<span class="hljs-comment">/* ... */</span>},
  <span class="hljs-attr">alias</span>: {<span class="hljs-comment">/* ... */</span>},
};
</code></pre>
<p>Now past the initial polyfill issue, I quickly hit another. This time, my global variable is undefined in the buffer polyfill. Jeeze!</p>
<div class="imageGallery" style="width:100%">
    <div class="one">
        <img src="/posts/snowpack-fluid/global-error.png">
    </div>
</div>
<p>While I am generally curious why I’m hitting this issue, I’m eager to get my familiar Fluid Hello World up and running, so I hard coded <code>const global = {}</code>, which would bypass the error message.‡</p>
<p class="footnote">
† Fred mentioned that the importsNotUsedAsValues flag is optional and mentioned in the docs. I missed it!
</p>
<p class="footnote">
‡ Fred's comment, "Snowpack definitely rewards ESM packages that don't use a lot of Node.js dependencies by default. And those polyfills could really be improved... we may want to take over maintaining a fork just for our own use case." <a href="https://github.com/snowpackjs/rollup-plugin-polyfill-node">PR on the fork.</a>
</p>
<h1>Success!</h1>
<div class="imageGallery" style="width:100%">
    <div class="one">
        <img src="/posts/snowpack-fluid/success.webp">
    </div>
    <p>Boom. Dice Roller!</p>
</div>
<h1>Review</h1>
<p>All up... It took me about 25 minutes to get integrate the Fluid Hello World with the create-snowpack-app. This is a tad longer than I'd hoped, but felt reasonable for a build toolchain swap.</p>
<p>Snowpack is impressive and interesting. This limited exploration piqued my interest in the ecosystem (Skypack + Fluid Containers next?) and redoubled my interest in ES modules. I was delighted with the clarity and simplicity of Snowpack's build directory. I'm a strong believer in adopting standards based technology and Snowpack proves the point. It's simply a faster and more elegant build tool.</p>
<p>As more developers realize the performance benefits of the switch, I expect the OSS community will do what it does best and the cost of adoption will continue to drop.</p>
<p>The full code for this demo is available <a href="https://github.com/SamBroner/snowpack-fluid-helloworld">here</a>.†</p>
<p class="footnote">
† I should have named the repo 'Ice Water'.
</p>


Rebuilding the Fluid Framework Hello World with the Snowpack build tool

Snowpack with Fluid Framework

<h1>You want to deploy a website. Where should you start?</h1>
<p>In the last two months, I redeployed <a href="https://www.sambroner.com">this personal website</a> and deployed <a href="https://FluidFramework.com">FluidFramework.com</a> for the first time. I made some mistakes along the way, but I ultimately chose to create a static website for both. It’s been a good choice for both.</p>
<p>In this post, you will learn when and why a static website is a good choice and which tools I used for this website. Next time we’ll talk about why I chose those tools over others and how you can deploy your website using the same tools I used.</p>
<h1>Should your website be a static website?</h1>
<p>A static website is a website that is delivered to your user’s web browser as it is stored. A static website does not rely on a web server to dynamically change the appearance or functionality.</p>
<p>For instance, this blog post is stored as <a href="https://www.sambroner.com/posts/azure-static-webapps-1/">azure-static-webapps-1.html</a> in Azure Blob Storage. The sidebar to the left and footer on the bottom are added into the .html file before they are uploaded to Azure Blob Storage.</p>
<blockquote>
<p>Let’s talk about the actual delivery of files for a second.</p>
<p>My personal website delivers four types of files to your browser: .css, .html, .js, and various media files. The .html file is first. In the HTML, there are references (tags) to the .css, .js, and media files necessary to make this page look how it does.</p>
<p>Many people choose to “bundle” these assets directly into the .html file. If I bundled the assets, the .css, .js, and (although less likely) the media would be included in the .html file and there would be no need to fetch those files later.</p>
<p>This is just how <a href="https://gohugo.io">Hugo</a>, the static site generator I'm using, works and I wasn’t too picky about it.</p>
</blockquote>
<p>All else being equal, static websites are often more cost-effective to host, easier to develop, and quicker to render. For a blog like this one, these are the core attributes I was considering. I want a cheap, easy, performant personal blog.</p>
<p>There are a few other reasons you may choose to build a static website, but they were less important to me.</p>
<ul>
<li><a href="https://blog.sqreen.com/static-websites-security/">Security</a> - With no JS &#x26; no servers there’s less to manage</li>
<li><a href="https://www.netlify.com/blog/2016/05/02/top-ten-static-website-generators/">Tooling</a> - Static website generators are mature and customizable with large communities.</li>
<li><a href="https://www.slant.co/topics/2256/~best-static-website-hosting-provider">Hosting</a> - Static website hosting has also become very simple.</li>
<li>Few dependencies - no React, Vue, _.js to import</li>
</ul>
<p>Prior to the <a href="https://www.swyx.io/js-third-age/">Second Age of JavaScript</a>, many websites were static websites. The internet is more powerful and you have more choices.</p>
<h1>When shouldn’t your website be a static website?</h1>
<p>If your website will have data that changes dynamically, like Facebook.com or Office.com, your website probably should not be a static web app. In both of those cases, every user receives a slightly different HTML file from the server.</p>
<p>A lot of the modern web is not delivered as static web apps and there are good reasons for that!</p>
<p>Here are some application types that are typically harder to implement as static web apps</p>
<ul>
<li>Storefronts</li>
<li>Social Media</li>
<li>Login Pages</li>
<li>Productivity Tools</li>
<li>Games</li>
</ul>
<p>There’s a theme to this list: it would be impossible to list every HTML page. That is, if Facebook had to statically generate the HTML pages necessary for every user who visits the site, they couldn’t do it! There are an infinite number of ways to view the data on Facebook. Facebook must generate a new HTML page whenever a specific user visits a specific page.</p>
<h1>Next Time</h1>
<p>In the next post, we’ll talk about the tooling I used and how you can get started. If this post was a why and a what, next time we’ll do “which and how.”</p>
<ul>
<li><a href="https://gohugo.io/">Hugo</a> - Static Site Generator</li>
<li><a href="https://github.com/features/actions">Github Actions</a> - Build &#x26; Deploys the Hugo Site to Azure Static Website</li>
<li><a href="https://azure.microsoft.com/en-us/services/app-service/static/">Azure Static Web Apps</a> - Hosts the website</li>
<li><a href="https://azure.microsoft.com/en-us/services/frontdoor/">Azure Frontdoor</a> - Additional caching &#x26; domain management</li>
</ul>


The considerations that go into building a static web app.

Static Websites: Why and What

<p>I help <a href="https://superkidsfoundation.org/">The Superkids Foundation</a>, a Paraguayan non-profit, manage its finances. This is a fairly tricky problem! We do not have a Paraguayan bank account, Paraguayan receipts are inconsistent, and transactions are almost entirely in cash. Not to mention, I don’t speak Spanish and I live in Seattle! I can’t read the receipts or talk directly to our amazing staff!</p>
<p>While there are a bunch of interesting places I have injected technology, we'll go over just one issue in this post: how do we track receipts without adding <strong>any</strong> overhead.</p>
<p>We came up with a system that leverages our existing tools, Google Sheets, phone cameras, and WhatsApp, but integrates with <a href="https://www.twilio.com/">Twilio</a> and the Google API to make our receipts auditable, discoverable, and accessible.</p>
<div class="imageGallery">
    <div class="one">
        <img src="/posts/superkids-receipts/fundacion_superninos.png">
    </div>
</div>
<h2>What is Superkids?</h2>
<p>Outside of my work for Microsoft, I am the treasurer of the board of The Superkids Foundation. Superkids helps mobilize children as agents of change in their own communities. We train and mentor kid teachers (SuperKids!) to give back to their own communities by helping younger students learn to read. In 2019, kid teachers spent more than 7,000 hours teaching younger students through our after school programs.</p>
<p>As the treasurer, I get to spend time working with our wonderful coordinators and my colleagues on the board while managing Superkids' cashflow. We have two coordinators and seven facilitators who work out of our rented space. To operate the space, we hire cleaners, pay for office supplies, utilities, maintenance and more. We also provide transportation, snacks, and other miscellaneous goods to the kid teachers and our students.</p>
<p>Among other things, I monitor donations (from FB, PayPal, Direct, Corporate Match, etc), process and audit receipts, approve bankroll, approve marketing, and gather financial data for grants.</p>
<h2>What we did before</h2>
<p>Superkids uses Google Sheets for accounting and WhatsApp for communication. We track all of our Income &#x26; Expenses and our cash on hand against our yearly and bimonthly budgets. If you dove into our 2019 “Contabilidad” (Accounting), we had the following.</p>
<ul>
<li>“Resumen” - (Summary)</li>
<li>“Efectivo” - (Cash)</li>
<li>“Presupuesto Enero Febrero” - (Budget January February)</li>
<li>“Ingresos y Gastos Enero Febrero” - (Income and Expenses January February)</li>
<li>“Presupuesto Marzo Abril” - (Budget March April)</li>
<li>“Ingresos y Gastos Marzo Abril” - (Income and Expenses March April)</li>
<li>...</li>
</ul>
<p>Receipts were put into a WhatsApp chatt and the expenses were added to the Efectivo.</p>
<h2>The Problem</h2>
<p>By the end of business each day, every receipt had to be photographed and all expenses had to be put in the Efectivo. To audit this process, someone would need to look through all the WhatsApp history and compare the receipts to the Efectivo line items.</p>
<p>This was never going to happen! It was impossible to track and hard to use. It was too easy for us to misplace a receipt and be slightly off at</p>
<h2>The Solution</h2>
<p>A <a href="https://www.twilio.com/blog/build-whatsapp-bots-twilio-autopilot">WhatsApp bot</a> ("SuperAuditor") that receives incoming images and puts them directly into our monthly Efectivo. The rest of line item can then be filled based on the information in the receipt. By the end of the day, receipts should line up with cash on hand.</p>
<p>I was worried that we'd have duplicate photos or that the number would get spam. Luckily it's much easier (and more satisfying) to delete a line item than to chase down all the staff for receipts.</p>
<p>Twilio's generous <a href="https://www.twilio.org/benefits/">non-profit stipend</a> has made WhatsApp bot free for our non-profit. Google's API is always free at the scale we're operating at.</p>
<h2>Follow up</h2>
<p>If there's interest, I'll spend some time making the code easier to use and share it out!</p>


How I help the Superkids Foundation manage its finances with Google Sheets, Twilio, and Whatsapp.

International Auditing on a Budget: Auditing a Paraguayan Non-Profit

<p>There’s a small art gallery nestled between an alright Thai place and a yuppy cupcake shop in
Seattle’s Capitol Hill. The pieces are amazing shattered glass, perfectly reconfigured. I figured I
should try it.</p>
<p>Here’s my first attempt alongside Cassandria Blackmore’s excellent work.</p>
<div class="imageGallery">
    <div class="two">
        <img src="/posts/shattered-glass-1/image1.png">
        <img src="/posts/shattered-glass-1/image2.png">
    </div>
    <p> Guess which is which? </p>
</div>
<p>After a few attempts, I engineered something a bit more respectable. I’ll keep iterating on this, but I
don’t think I’ll quite replicate Cassandria. I’ll just have my own “inspired”
style.</p>
<div class="imageGallery">
    <div class="one">
        <img src="/posts/shattered-glass-1/image6.png">
    </div>
</div>
<h2>Attempt #1</h2>
<h5>Maybe it'll work?</h5>
<div class="imageGallery">
    <div class="one">
        <img src="/posts/shattered-glass-1/image1.png">
    </div>
</div>
<p>I went to the local Blick and bought some reasonable seeming supplies.</p>
<ul>
<li>.5” Foam Board</li>
<li>Acrylic Paint</li>
<li>Acrylic Medium (glueish stuff?)</li>
<li>Picture frame glass</li>
</ul>
<p>I figured I could paint the glass, then use the Acryclic Medium to glue the glass to the board. A quick
shatter, and I’d be done.</p>
<p>Each step of this was harder than expected.</p>
<p>Because the unpainted glass faces the viewer, the first layer of paint is the most obvious. I had some <strong>ugly</strong> early attempts.</p>
<p>Acrylic Medium is a bad glue for this job. The shattered glass is basically pulling itself off the Foam Board.</p>
<p>Most importantly, picture glass is <strong>not</strong> what Cassandria uses! It shatters into shards, not the glittering fragments pictured above.</p>
<h2>Attempt #2</h2>
<h5>Figure out the glass</h5>
<p>What glass shatters into a million pieces? Car glass! That is... tempered glass. Tempered glass is regular glass that is heat treated to give it opposing compression and tension. To simplify, a piece of tempered glass is strong while intact, but, once broken, the opposing forces rip the glass apart.</p>
<p>So I went on Craiglist and found some old tempered glass shelves to
destroy!</p>
<div class="imageGallery">
    <div class="one">
        <img src="/posts/shattered-glass-1/image7.png">
    </div>
</div>
<p>This worked much better. The tempered glass creates the pattern we’re
looking for.</p>
<p>I used the leftover paint and some left over cardboard and substituted our new glass. Everything worked, but
shattering tempered glass is hard (and <strong>dangerous</strong>.) I had to really hammer the corner
for this to work.</p>
<div class="imageGallery">
    <div class="one">
        <img src="/posts/shattered-glass-1/image8.png">
    </div>
    <p>Pictured: An idiot (me) wearing non-protecting sunglasses and sound canceling headphones.</p>
</div>
<p>At this point, issues with the cardboard became obvious. My tempered glass was pretty heavy and without the rigidity of the glass or foamboard, the pieces flopped apart.</p>
<p>At this point though, I thought I should focus on the paint.</p>
<h2>Attempt #3</h2>
<h5>Focus on the paint</h5>
<p>I watched like 30 videos on how to blend paint. They all intend for the blended paint to be seen from the
painted side of the piece (we need the other side to look blended.) It turns out this wasn’t much harder,
but I had to use a sponge to scrub the paint off the glass repeated in order to get a consistent blend.</p>
<div class="imageGallery">
    <div class="one">
        <img src="/posts/shattered-glass-1/image5.png">
    </div>
</div>
<p>It still didn’t quite work, but closer.</p>
<p>I also added safety glasses, earplugs, gloves, shoes (not pictured), and wrapped the glass in trash bags.</p>
<div class="imageGallery">
    <div class="one">
        <img src="/posts/shattered-glass-1/image4.png">
    </div>
    <p>You can hear the tempered glass continue to pull itself apart!</p>
</div>
<p>At this point, the foam board became a problem. It’s too thick to fit into a normal frame and it’s
still not rigid enough. Also, my hacked Acrylic Medium &#x26; Glue still didn’t really hold up. You can see
the edges crumbling away.</p>
<div class="imageGallery">
    <div class="one">
        <img src="/posts/shattered-glass-1/image3.png">
    </div>
    <p>You can hear the tempered glass continue to pull itself apart!</p>
</div>
<h2>Attempt #Next</h2>
<h5>Tie it all together</h5>
<p>I’ll be trying this again in the coming weeks. I believe I’ll need these supplies.</p>
<ul>
<li>Tempered Glass</li>
<li>Stiff Sheet Metal (Backing Board)</li>
<li>Good Epoxy Glue</li>
<li>A Drill</li>
<li>Safety Equipment</li>
<li>More space</li>
</ul>
<p>With a drill, I can break the glass more accurately and without throwing out my shoulder.
Hopefully the metal sheet will be stiff enough and thin enough to put the combined piece in a frame. I’m
also hoping the epoxy will bind better. In all my prior attempts there were still fragments falling off.</p>
<p>We’ll see!</p>


Making art with paint, tempered glass, and a hammer.

Shattered Glass

<p>Here's a little blog I put together. I built the website myself during the quarantine to post about a few projects.</p>
<p>Appologies if it's broken: I'm having fun.</p>


First post on this blog. Appologies if it's broken: I'm having fun.

Sam Broner

Startups in Seattle, Boston & NYC

About

Contact

Subscribe

Other Media

Posts

Tags