πŸ—» James Van Dyne

✈️Trips πŸ—ΊοΈMaps ✏️️Blog πŸ”—οΈοΈLinks πŸ‘‰Now πŸƒRuns
  • 🏑Home
  • ✈️Trips
  • πŸ—ΊοΈMaps
  • ✏️Blog
  • πŸ”—οΈLinks
  • πŸ‘‰Now
  • πŸƒRuns
  • ✏️Articles
  • πŸ“€οΈReplies
  • πŸ’¬Status
  • πŸ”–οΈοΈBookmarks
  • πŸ—ΊCheckins
  • πŸ“…The Week
  • πŸ–₯Tech
  • 🌲Sustainability
  • πŸƒRunning
  • 🧠Thoughts
  • πŸ‡―πŸ‡΅Japan
  • πŸ’‘TIL
  • β›°Tanzawa
  • 🏑Home
  • ✏️Articles
  • πŸ“€οΈReplies
  • πŸ’¬Status
  • πŸ”–οΈοΈBookmarks
  • πŸ—ΊCheckins
  • πŸ“…The Week
  • πŸ–₯Tech
  • 🌲Sustainability
  • πŸƒRunning
  • 🧠Thoughts
  • πŸ‡―πŸ‡΅Japan
  • πŸ’‘TIL
  • β›°Tanzawa
  • Checkin to Tully's Coffee

    Tully's Coffee 35.42963851058279 139.5575962904548
    Nov 01, 2020
    by James
    in Yokohama, Kanagawa, Japan

    Used to visit this Tully’s regularly in 2009 - 2011. These days not so much.

    πŸ”—permalink
  • Oct 31, 2020
    by James

    The sunset tonight in Yokohama is fantastic. Lovely Mt. Fuji. Days like this I really love where I live, never gets old. πŸŒ…πŸ—»



    πŸ”—permalink
  • Checkin to Starbucks

    Starbucks 35.42861 139.506997
    Oct 31, 2020
    by James
    in Kanagawa, Japan

    First cup of black coffee in days.



    πŸ”—permalink
  • Lazy Load Images Without Javascript

    Oct 31, 2020
    by James

    Sustainability of websites is mostly determined by how much electricity the website consumes. All websites consume electricity 24/7. There's a server powered up, listening for requests. They consume it by proxy transferring bits to the client and they consume it on the visitor's computer by rendering the content.

    You can't do much about electricity consumption of a server being online 24/7 beyond simplifying your hosting infrastructure (you don't need a load balancer). What's easier to control is the the number of bits you send to clients who visit your website.

    Images are a large source of unnecessary bits. We shouldn't be uploading raw uncompressed 40MB images designed for a poster to display on a smart phone. They'll load slow, chew through our visitor's data plan, and consume unnecessary electricity to transfer and render such a large image. You should resize your images for the web.

    Traditionally images are input into a website with a simple image tag like below:

    <img src="https://jamesvandyne.com/wp-content/uploads/2020/10/voted.png" alt="Ballot approved" border="0" width="600" >

    You tell the browser where the image is, give it some alt text for cases where the image doesn't display / accessibility purposes, and maybe even set a size. Once your browser encounters this tag it will dutifully download and display the image. Life is good.

    But what if that image is halfway down the page and completely off screen? Doesn't matter - still downloaded.
    It doesn't matter that they may not scroll down far enough to see the image, it's in your markup the browser downloads it. This is a waste of electricity and bandwidth.

    There are methods using Javascript to dynamically change the src attributes of your image tags when the user scrolls near, but then your simple image tag now requires Javascript and client side computation just to display. It's not an elegant solution.

    Turns out there's a better way without Javascript using the loading attribute on your images. Support is in all major browsers since mid 2019 / early 2020. It works out of the box on Firefox/Chrome, but it must must be enabled in Safari under the Advanced > Experimental Features settings for now.

    Graph displaying caniuse data for the loading attribute

    By simply adding loading="lazy" to our image tags the browser will lazy load our images, i.e. it won't download the image until is nearly in view.

    So by modifying the example above to

    <img src="https://jamesvandyne.com/wp-content/uploads/2020/10/voted.png" alt="Ballot approved" border="0" width="600" loading="lazy">

    we can reduce the number of data transfers, reduce total transfer size (unless they scroll the image into view), reduce electricity consumption across the board, and improve page load times. It's a win-win-win.



    πŸ”—permalink
  • Thinking about Thinkpad

    Oct 29, 2020
    by James

    I recently mused about how my next computer should be a Thinkpad running Debian. I still half-think that, but I feel conflict on the issue. Let me explain.

    My first Mac was an iBook G3 running OS X 10.1 in 2002 and I've been on Apple computers exclusively since. I came from running desktop Linux (Gentoo at the time) and a major reason why I switched to OS X was the unix environment without the fiddling.

    Over the years I starting developing native apps and valuing apps that take the time and effort to be consistent with the systems. The consistently between apps made the entire system feel cohesive and easy to use. "Mac Apps Behave / Are Designed Like This". I was hooked. I am hooked.

    But the world has changed since those days. We're now connected to the net with fiber rather than dialing in for a ~couple~ all hours of the night. Web browsers have become the new platform to target and Every app is cross platform and nothing is native.

    Hardware is a growing concern for me as well. Apple makes some of the best laptops. I look forward to the Apple Silicon Macs. But repairing your Mac often means replacing the entire unit and paying more than purchasing a new one. They're no longer upgradable and filled with glue.

    Contrasting with Thinkpads you can upgrade the ram, swap out the hard drive, add in LTE modems, and even change the display. If something breaks you can replace just that part. Expandability should allow the machine to have a longer life. I can even get them fully supported with Ubuntu or Fedora Linux.

    If the software I use on a regular basis no longer native, not designed for the Mac, and everything is inconsistent, what's the advantage of using them on the Mac?

    πŸ”—permalink
  • The Week #16

    Oct 27, 2020
    by James


    • I started experimenting more with IndieWeb Post Kinds. I tried a bookmark and a reply to James' post about RSS, but I'm not sure if it sent webmentions like it should've. One thing's for certain my blog needs some style adjustments - replies don't have enough space between them and the next post. Finding a good mapping between Wordpress "Kind" and the IndieWeb "Post Kind" is difficult, as well.

    • I've rearranged the footer of my site. Site meta was deleted, Categories was moved to the right, and I've added post kinds to encourage me to use them more. While I backfeed all of my Swarm checkins to my blog, I filter them from my homepage and main rss feed as it creates too much noise. But I still wanted a place to list them on my site, so my most recent 5 checkins are listed as well.

    • I've been ignoring my Bedtime and watching Long Way Up/Down/Round. While it's been good to have some time to travel with my mind it's been bad for daily energy levels. This week I'm going to try and get to bed on time so I can wake easier.

    πŸ”—permalink
  • Oct 26, 2020
    by James

    Surveillance capitalism is outlawed tomorrow: how does the web react? Do web directories come back? Does the web re-decentralize?

    πŸ”—permalink
  • Oct 25, 2020
    by James

    Ran along the river in Fujisawa today. Started in Fujisawa this time so didn’t need to run 3 km just to get there. Nice 5km. πŸƒπŸ™ŒπŸ»






    πŸ”—permalink
  • Checkin to DEAN & DELUCA

    DEAN & DELUCA 35.33859806415866 139.4471050805835
    Oct 25, 2020
    by James
    in Fujisawa, Kanagawa, Japan

    Kema curry



    πŸ”—permalink
  • πŸ”— The Map

    Oct 25, 2020
    by James
    Gary Hustwit (of Helvetica, Objectified, and Rams fame) has made a short (10 minute) film about designing the MTA's new live map for the New York subway system called The Map.
    I love how it discloses more detail as you zoom and the little moving train icons.
    map_animated.gif 1.39 MB
    1. Tagged with
    2. video
    3. design
    4. map
    πŸ”—permalink
Previous 178 of 367 Next
Reply by email
Powered by
πŸ”Tanzawa

← An IndieWeb Webring πŸ•ΈπŸ’β†’
Photo of James Van Dyne James Van Dyne Japan

Web developer living in Japan.