We've all been there, you have changes that haven't been QAed, but there's a hotfix that needs to go out yesterday. Pantheon is a great host, but it has one major gotcha: you can't switch code branches. The way Pantheon works is the Pantheon Remote git library gets one, and only one branch. There's no way to switch branches. Code can only be promoted from staging->test->live. This is problematic, especially if you're coming from various deployment management utilities that let you switch branches or platform-as-a-service like Heroku.

Image Credit: Pantheon, Use the Pantheon Workflow

Pantheon does offer multi-dev which essentially creates a separate branch for testing (and which can be promoted to the main chain) but still doesn't fix the hotfix issue.

Pantheon Hotfix Flow

1. Create a local branch and reset to the last commit that was made live (this is a pain as Pantheon doesn't show last commit git hashes)
2. Make changes locally. Commit the changes to your new branch.
3. git push -f Pantheon YOURBRANCHHERE:master
4. Promote from Dev -> Test -> Live from the control panel
5. Make sure your hotfix is merged into your master local (and your origin)
6. Reset Pantheon’s Dev to the master branch git push -f Pantheon master:master

Despite being warned that you should never use git force, this is the cleanest method. You can push up your desired hotfix and leave it on the live environment until your normal deploy chain overwrites it.

Using the magic of @media print, I've included a mild update to this blog to be more printer / PDF friendly, mostly for a singular post, The Definitive Mac Pro Upgrade Guide that drives the majority of my traffic.

• Images are now capped to 75% of the page width as my images are only double density, optimized for screens, not printers.
• The main content now expands to the full page width, so users can set the margins within their print prefs.
• The main body copy, and line height has been reduced from 16px to 15px, and 2 em to 1.75 em.
• I've included a link back to the original blog post at the top of each page, visible when printed so PDF users can easily return to the blog post in a web browser.

Happy printing, you weird PDF-loving bastards!

My 2017 MacBook Pro stopped charging and refused to accept power from any power supply on any port. I was restoring my My computer to my previous laptop, a 2015 MacBook Pro and encountered the above. I tried using the day-before's back up, but this didn't work.

I received the following message when booting from a Time Machine drive:

An Error Occurred Restoring from Backup

To Try Restoring from a different backup, click choose other Backup.

To reinstall macOS, click install macOS. During the install you can chooes to restore your information from a Time Machine Backup.

To Boot from an existing macOS installation...

I've seen some high tier fixes, like harryfear.co.uk's fix but there's an easier route and the clue is in the error message.

More carefully reading the message, I booted off the Recovery partition and then reinstalled macOS. Then once completed, on the Migration Assistant I selected the option to transfer information over from my Time Machine drive. This isn't a true 1:1, I noticed some things missing such as /etc Apache2 modifications but some of the geek stuff like, HomeBrew and its many CLI applications (Heroku) made the cut. Beyond renewing SSH keys and running Docker builds, my computer was good to go. Standard Mac applications had no issues.

Summary

If a restore fails, fear not. Restores are faster but you will not lose your important files.

1. Boot off a recovery partition, reinstall macOS
2. At the end of the installation, you will see the Migration Assistant. Select transfer files from another computer/device/Time Machine then select your time machine drive

I suspect for most users, self-included, the harryfear fix is overshooting the problem and Apple's solution is "good enough".

Sometimes you encounter something that'll surprise you, and yesterday was one of those days: Chrome does not support inline media queries on the source tag within videotag. (you can test it here) Worse, plain media queries will not stop multiple videos from loading, which effectively doubles your data, so it requires a JS solution. CSSTricks has an article from 2012 using jQuery, but there's no follow up and I wasn't that enthralled. I saw, thenewcode: Make HTML5 Video Adaptive With Inline Media Queries but it fails to mention Chrome's refusal to support it.

Javascript to the rescue

First, I wanted to prevent any request to be made, so I created an empty video tag with my two videos as attributes. Easy right? Now that all major browsers support MPEG4, I could safely assume the only legacy users are IE and Safari as the browsers are tied to OS updates, whereas Chrome and FireFox are not thus very few users would not be using a recent browser. Safari and IE both support MPEG4. There's not a good reason for me to want to support WebM.

<video
  preload="auto" autoplay="" loop="" muted="" playsinline=""
  data-desktop-vid="https://iconaircraft.s3.amazonaws.com/ICON_Web+4.0_Loop_16x9_DRAFT190723_26sec+3700.mp4"
  data-mobile-vid="https://iconaircraft.s3.amazonaws.com/ICON_Web+4.0_Loop_1x1_DRAFT190723_26sec-mobile.mp4"
  >
</video>
  

I didn't want to rely on any framework, jQuery document ready meant the JS wouldn't fire until the rest of the page loaded, and es6 meant leaving out old browsers. Thus, I'm limited to ES5.

First, I needed to get all the videos on the page. This creates a variable that contains an array of objects, even if only one is found on the entire page.

//get all vids
var video =  document.querySelectorAll('video')

Next, I needed to create a source for the video tag. The source tag needs an src and type. After that we need to append the newly created DOM element back to an element. This function doesn't need to know how many videos are on the page or what the screen size. It just will return a source to a video tag.

//add source to video tag
function addSourceToVideo(element, src) {
    var source = document.createElement('source');
    source.src = src;
    source.type = 'video/mp4';
    element.appendChild(source);
}

Next is where the logic happens. If a screen size over a predetermined value, I will load the desktop or mobile version. Since I have two data-attributes to work off of depending on the screen size depends on which one I want to use. If the screen is above a certain size, it will grab the desktop version instead of the mobile version, to feed to addSourceToVideo. Easy enough, right?

//determine screen size and select mobile or desktop vid
function whichSizeVideo(element, src) {
	var windowWidth = window.innerWidth ? window.innerWidth : $(window).width();
	if (windowWidth > 800 ) {
		addSourceToVideo( element, src.dataset.desktopVid);
	} else {
		addSourceToVideo(element, src.dataset.mobileVid);
	}
}

Now that we've written code to determine write sources to empty video tags, it needs to init and be able to handle multiple videos. Remember our array of objects? It's time to use it. There's no point of running the code if there aren't any videos on the page, so we need to check to see if the var videos contains any data. If it does, then we need to loop over our array and return an individual video in case we have multiple videos on our page.

//init only if page has videos
function videoSize() {
  if (video !== undefined) {
  	video.forEach(function(element, index) {
  			whichSizeVideo(
  				element, //element
  				element  //src locations
  			);
  	});
  }
}
videoSize();

Notably, you could tie the above code to a resize event incase a user resizes the window and have it trigger videoSize. I chose not not to for simplicity. You can see the working version of the above code, on CodePen. I didn't embed it in this post, so those using a slower connection aren't being hit with 30 MB of video data. Place this script inlne or as seperate file below your videos, but before the rest of your JS payload for maximum performance.

I'm always drawn with complete morbid fascinating with "influencer" culture as I largely have avoided social media. I have exactly one social media account of the major, Facebook (arguably the worst of them all) but deleted the app off my phone about 4 years ago. I'm including YouTube in this, as it should be considered a social network and reddit, which I avoid. I'm convinced that vast majority of social media is an anecdoche.

So when I read about influencers asking for free meals at restaurants, I experience a clash of contradictory thoughts simultaneously: "Who has the gall to cold-call a restaurants for a free meal because they have 50,000 Instagram followers?", "I'm surprised this happens", "I am not surprised in the least bit", "this is scam verges on genius", "major brands will give famous people free shit, why not small businesses give those with tiny soap box for cheap advertising?", and "everything about this is idiotic" followed by general self-satisfied feeling of being above it all, despite my immediate desire to share/discuss it with my friends.

Over marketization of all facets of life has made even the most mudane activity a transactional exchange that can be sold thanks to social media. Its all viewed through the nihilistic world view that anyone has a "personal brand". Any experience, even a wedding proposal is a marketing opportunity, and people flock to toxic lakes. The irony is influencers are internet points that may or may not mean a damn thing, an influencer with 2 million followers couldn't sell 36 t-shirts.

If there's one thing that is certainly true, it's further evidence of the enshittening.

There's plenty of tutorials on creating your own custom Gutenberg blocks, but I found that the between beginner and advanced was lacking. I'm going to skip the basics but rather a short list of things to understand to more effectively work with Gutenberg. So from a trial-by-fire experience of working on two Wordpress 5.0 Gutenberg websites, here's what I've learned. The guiding principal is to re-use functionality when possible and try to replicate the Wordpress UI.

Rule 0: Understand React's role

Wordpress chose to use React to create it's UX for its new Gutenberg block editor. However, instead of using React directly, Wordpress uses Element, an abstraction layer over React. If you're wondering why someone would want to do this, Wordpress has a very concise list:

• In many applications, especially those extended by a rich plugin ecosystem as is the case with WordPress, it’s wise to create interfaces to underlying third-party code. The thinking is that if ever a need arises to change or even replace the underlying implementation, it can be done without catastrophic rippling effects to dependent code, so long as the interface stays the same.
• It provides a mechanism to shield implementers by omitting features with uncertain futures (createClass, PropTypes).
• It helps avoid incompatibilities between versions by ensuring that every plugin operates on a single centralized version of the code.

This means you'll be writing code and making imports to wp.element, wp.components and wp.blocks. React only exists in the admin side of things, and all the content found within a block is saved statically meaning you won't be able to create React experiences simply by creating Gutenberg blocks. The

Rule 1: Bundle your custom blocks in one plugin

It's pretty easy to bundle all your custom blocks into one plugin. Unless you're looking to distribute your custom blocks across many sites, it's saner for development and deployment to make one master plugin for all your blocks. On the dev side, this means a single webpack instance to spin up as opposed to one for each block. A good example of this in action is Zac Gordon's WPForJSCourse example. While his course isn't free, this plugin is. This includes everything you need: A sane structure, a webpack config and a setup. All the custom blocks are registered in one nifty index js file.

It's pretty easy to do, but it was a design pattern that I didn't realize would benefit me when I started in on Gutenberg.

Rule 2: Learn Innerblocks and reuse core blocks

Most tutorials seem to stop short of innerblocks, and Innerblocks are probably one of the most important features of Gutenberg. Innerblocks allow you to load blocks inside of blocks. Below is a super basic example for a slideshow, allowing the user to enter as many images using the core/image Gutenberg block but restricting the user from entering any more.

    edit: props => {
        const { attributes: {selectControl},
            className, setAttributes, isSelected, } = props;
            const ALLOWED_BLOCKS = [ 'core/image' ];
        return [
            div className="slideshow-super-simple">
            <strong>Note: </strong> all slides are visible in editor<br />
          <InnerBlocks
            allowedBlocks={ ALLOWED_BLOCKS }
          />
          </div>
        ];
    },
    save: props => {
        const { attributes: { selectControl } } = props;
        return (
            <div className="icon-simple-slideshow" >
              <div className={ selectControl} ><InnerBlocks.Content /></div></div>
        );
    },
    

Innerblocks aren't simply limited to allowing and restricting other blocks, they can also accept templates, which is a set of pre-defined blocks. This allows assembling a very complicated UI or layout widget out of any number of prebuilt or custom blocks. There's no reason to reinvent the wheel as Wordpress gives you quite a few different blocks. Below I've included a list of all the common blocks by category.

Common blocks category

• core/paragraph
• core/image
• core/heading
• (Deprecated) core/subhead — Subheading
• core/gallery
• core/list
• core/quote
• core/audio
• core/cover (previously core/cover-image)
• core/file
• core/video

Formatting category

• core/table
• core/verse
• core/code
• core/freeform — Classic
• core/html — Custom HTML
• core/preformatted
• core/pullquote

Layout Elements category

• core/button
• core/text-columns — Columns
• core/media-text — Media and Text
• core/more
• core/nextpage — Page break
• core/separator
• core/spacer

Widgets category

• core/shortcode
• core/archives
• core/categories
• core/latest-comments
• core/latest-posts
• core/calendar
• core/rss
• core/search
• core/tag-cloud

Embeds category

• core/embed
• core-embed/twitter
• core-embed/youtube
• core-embed/facebook
• core-embed/instagram
• core-embed/wordpress
• core-embed/soundcloud
• core-embed/spotify
• core-embed/flickr
• core-embed/vimeo
• core-embed/animoto
• core-embed/cloudup
• core-embed/collegehumor
• core-embed/dailymotion
• core-embed/funnyordie
• core-embed/hulu
• core-embed/imgur
• core-embed/issuu
• core-embed/kickstarter
• core-embed/meetup-com
• core-embed/mixcloud
• core-embed/photobucket
• core-embed/polldaddy
• core-embed/reddit
• core-embed/reverbnation
• core-embed/screencast
• core-embed/scribd
• core-embed/slideshare
• core-embed/smugmug
• core-embed/speaker
• core-embed/ted
• core-embed/tumblr
• core-embed/videopress
• core-embed/wordpress-tv

Pictured: Mock up of a hypothetical user page

Let's break down the above design: It's two columns consisting of:

Paragraph (custom)

With Gutenberg, simple layouts like the above can potentially be done using the code block, but it isn't desirable as it requires a bit of mastery of Wordpress, with a high margin of error if it taps into using custom CSS. We have a two column design, consisting of an Image in the first column, and two fields in the second, followed by text beneath the columns. So let's look a template code.

     edit: props => {
            const { attributes: { paragraph },
                className, setAttributes, isSelected } = props;
                const TEMPLATE = [
                  [ 'core/columns', {columns: 2,className: "profile-outer-column"}, [
                      [ 'core/column', { className: "profile-inner-column" }, [
                        ['core/image', { className: "profileImage"}],
                      ], ],
                      [ 'core/column', {className: "profile-inner-column"}, [
                        ['mycustomblocks/profile-title', { className: "profileTitle"}],
                        ['mycustomblocks/profile-name', {  className: "profileName"}]
                      ],],
                  ],],
                  ['mycustomblocks/profile-bio', { className: "profileBio"}]

                ];
            return [
                <div className={ className + " my-profile-editor"}>
                  <InnerBlocks template={TEMPLATE} />
                </div>
            ];
        },
        save: props => {
              const { paragraph,className } = props.attributes;
            return (
                <div className={className + " my-profile"}><InnerBlocks.Content  /></div>
            );
        },
   

Using the templates, I'm able to place inside columns a mixture of custom and factory Gutenberg blocks! Innerblocks aren't infallible, you can template lock blocks so users cannot add more blocks but occasionally this creates issues. Also, the custom styling for blocks does not work on any block that features an innerblock (yet). Perhaps this will change but as of writing this, it hasn't.

Rule 3: Restricting dependent blocks

Often you'll create a block that shouldn't appear in your list of plugins from the Wordpress gutenberg GUI. Any custom block can be easily restricted to being only accessible from a certain block type. In my previous example I had two custom blocks, mycustomblocks/profile-title and mycustomblocks/profile-name. These two blocks are very simple blocks, but I do not want them polluting my list of Gutenberg blocks. This only requires declaring the parent

export default registerBlockType(
    'mycustomblocks/profile-title',
    {
        title: __( 'Profile Title', 'mycustomblocks' ),
        description: __( 'This field is for the user profile's job title.', 'mycustomblocks'),
        category: 'common',
        keywords: [
            __( 'text', 'mycustomblocks' ),
            __( 'MediaUpload', 'mycustomblocks' ),
            __( 'Message', 'mycustomblocks' ),
        ],
        parent: ['mycustomblocks/slideshow-slide'],

See the parent flag? It really is that easy.

Rule 4: Learn to use the custom toolbar and form fields

To truly make a plugin feel native, you'll need to tap into the UX that Gutenberg uses, the toolbar and the sidebar containing form fields, using InspectorControls and BlockControls. Again, Zac Gorden's JSForWordpress tutorial repo has a great example of each.

InspectorControls appear in the sidebar of a block, zgordon also has a nice tutorial on it as well as Eudes' medium post. Also, be sure to see the official documentation on InspectorControls.

          <InspectorControls>
              <PanelBody
                  title={ __( 'High Contrast', 'jsforwpblocks' ) }
              >
                  <PanelRow>
                      <label
                          htmlFor="high-contrast-form-toggle"
                      >
                          { __( 'High Contrast', 'jsforwpblocks' ) }
                      </label>
                      <FormToggle
                          id="high-contrast-form-toggle"
                          label={ __( 'High Contrast', 'jsforwpblocks' ) }
                          checked={ highContrast }
                          onChange={ toggleHighContrast }
                      />
                  </PanelRow>
              </PanelBody>
          </InspectorControls>

BlockControls appear in the editable area of a block as inline controls. Also, be sure to see the official documentation on Toolbars and Inspector

<BlockControls>
    <AlignmentToolbar
        value={ textAlignment }
        onChange={ ( textAlignment ) => props.setAttributes( { textAlignment } ) }
    />
    <Toolbar>
        <Tooltip text={ __( 'High Contrast', 'jsforwpblocks' )  }>
            <Button
                className={ classnames(
                    'components-icon-button',
                    'components-toolbar__control',
                    { 'is-active': highContrast },
                ) }
                onClick={ toggleHighContrast }
            >
                {icons.contrast}
            </Button>
        </Tooltip>
    </Toolbar>
</BlockControls>

It will feel a little strange but the edit return is returned as an array, for the main editable area mark up.

As a minor (I stress minor) pundit on all things Mac Pro after my definitive Mac Pro Upgrade guide I figure I should weigh in to the ever expanding sea of opinions. For the first time in a very long time the WWDC really hit the right notes: the iPad is growing up, the Photos app is beautiful and even more compelling, iTunes is no more and finally broken apart, the Watch has a de-tethered experience, Mac OS now will sport screen mirroring natively on an iPad, but Apple seemed to sense that the most important announcement was the return to the professional with the almighty Mac Pro.

Pictured: Apple feeling itself with the new Mac Pro. Don't be fooled by the monitor, it's 39.7 lbs/18.0 kg

Apple delivered but for $$$$

The presentation was oh-so-Apple like, and then it wasn't. Apple talked big numbers, lots of numbers, the kind of numbers that make average-people glaze over in boredom: 8k, 6k, 3.0 16x PCIe, billions of pixels, 2000 audio tracks, GPUs, multiple GPUs. It's enough to make someone throw up their hands and rhetorically ask: Who cares? But we care. We always have. There was a surreal moment when Apple showed how the case opened. They invited you inside, and look, there are slots! So many slots. What-in-the-name-of-Ives was going on?

The new Mac Pro is a monster, there's no other way to say it:

• Up to 28 Cores
• Up to 1.5TB of RAM
• Eight PCIe slots
  • Two "MPX" slots with Thunderbolt 3 passthrough (optional 16x ports if the slots aren't obfuscated with large cards)
  • 3 full length slots (1 16x, two 8x)
  • 1 half length slot (8x) with I/O connectivity from factory
• Two SSD slots (unclear if natively NVMe)
• Two 10Gb Enet
• Two USB-C / Thunderbolt 3 / two USB-A ports front facing
• Two Thunderbolt 3 ports on I/O card
• Headphone jack, internal speaker
• 802.11ac/Bluetooth 5
• Custom additional co-processor for video that allows for three 8k streams to be played back at once.

It's an absolute monster beast of a computer. Dare I say, this may very well be the best-designed desktop Apple has done. Visually, it may be a little too avant-garde. It's alien-looking but with a very clear nod and a wink to the cheese grater. It's built to last, just like how my 3.1 Mac Pro still works a decade layer. The hitch is the entry price of $5999.... ouch, oh and that pretty monitor? $4999 with a very understandable groan from the audience when the stand price tag of $999. The monitor is too much but I guess time to start saving for the Mac Pro. It's been a very long time since I've had this level of interest in a computer.

I've been following social media conversations and have some additional thoughts that I felt necessary to expand on.

More thoughts on price

The Mac Pro 2019 was what the people wanted, Xeons are more expensive than ever, with the CPU itself making up for roughly 1/3rd of the price even in the entry model. The Mac Pro 2019 also is the most upgradable Mac we've seen on several accounts. The PowerMac 9600, a monster in its own right had six PCI slots, twelve RAM slots, SCSI, ethernet and a serial port (3x 5.25 inch drives), debuting in 1997 at $3,700 (Roughly $5800 adjusted for 2019). The 2019 Mac Pro may lack the drive bays (only two SSD slots), it also has eight PCIe slots with an additional four Thunderbolt 3 ports. Let that sink in, Thunderbolt 3 adds the rough equivilent of four more 4x PCIe slots. It's better to think of the Mac Pro 2019 as having twelve PCIe slots. It has effectively double the physical PCIe slots of the Mac Pro 2006-2012, triple if you consider Thunderbolt 3, and far more CPU configuration options despite one CPU (which can scale to 28 cores, 56 virtual cores). You are effectively getting double the computer than the previous generation Mac Pro. It's expensive. Really expensive but go look at other Xeon workstations. It's price competitive. You wanted upgradable? Here it is.

Lastly, part of the price hike problem is the stagflation for most workers. This isn't to say that the problem isn't with Apple's price-point as even in 1997 a $3700 computer was a bitter pill to swallow, rather that it is exacerbated by the lack of meaningful raises that'd make investments like this more attainable. Also Mac users haven't kept up with the current Xeon prices, they are damn expensive. There's not really an affordable gap between an Intel i9 and the Xeons sadly. What a bulk of users wanted (self-included) was a $3000 Mac Pro. The i9 line certainly provides the CPU horse-power but is handicapped in the I/O department, only 40 lanes of PCIe and maximum memory and 128 GB. However, at 68 lanes maximum is certainly beefy enough but still locked at 128 GB of RAM, less than the 2010 Mac Pro.

As for the monitor? Nope, I can't justify it. Charging $1000 for the stand is not a good look. While a 6k true-10 bit display is impressive, I'm sure within 2 years we'll see equal displays for less money. Also for wallet injury, Apple had the gall suggest connecting 6 of these monitors to the Mac Pro, $36,000 worth of displays. Riiiight.

Thoughts on GPUs

If you hoped for NVidia support, well.... you placed your hopes on the wrong company. Apple and NVidia have not reconciled. There was absolutely no reason to expect them to resolve their issues. Expect to remain disappointed for the foreseeable future. I want NVidia as much as anyone, but it's not happening. Should Apple allow NVidia GPUs? Of course. Will they? Probably not. I've been wrong about a good many things though.

Thoughts on chipset

I'm not crazy about the Xeon price tags, and I've seen several people arguing that Apple should have gone AMD with like the thread ripper series. So far the Threadrippers are limited to: max 128 GB/s of RAM, 64 PCIe lanes and no Thunderbolt 3. While personally, these specs would be fine for me on a desktop (in fact I'd personally like a more modest config for affordability), they aren't for the target market: too few PCIe lanes, not enough ram and no Thunderbolt 3 is a deal breaker.

Also, the commitment to Xeons lends credence for a personal theory of mine, that the mac lineup might end up a split CPU architecture. Windows already is. The MacBook and MacBook Air line could end up on ARM where the I/O abilities of ARM are much less and the limitations of size mean that an Apple GPU would be more viable than Intel's built-in offerings. Is this true? Who-the-hell-knows outside of infinite loop but Apple speculation is a past time and I figure I should put this in writing just to see how accurate I really am.

Thoughts on I/O chipset

Now here's one that took me for a loop and I'm surprised that no-one I've seen has talked about this: The I/O card has two of the Thunderbolt 3 ports. This means (possibly) that more ThunderBolt 3 ports could be added to the computer or better, possibly whatever I/O (thunderbolt 4?) could be added down the road. This certainly improves the shelf life.

Thoughts on Power Draw

It's an easy target for people to skewer Apple on, but GPUs need juice. Their power requirements aren't going down anytime soon with 8k and VR. Perhaps focus on performance-per-watt will become needed in soon in the desktop arena as watts-in = heat out, creating issues for everyday users but we haven't seen the worst of it yet. The real question is the idling power, which is bound to be much lower than the ma

Thoughts PCIe 3.0 / DDR4

A few people are angry about the lack of PCIe 4.0 and DDR4. This one is easy. PCIe 4.0 isn't a shipping spec and Intel may skip it altogether, DDR5 is still more than a year out. The Mac Pro delayed even further. The real test is will Apple update to PCIe 4.0 and DDR5 when it comes time? If you hoped for Thunderbolt 4, it isn't even a thing yet.

Thoughts on looks

I find it strange, not hideous, but beauty is in the eye of the beholder. I won't lie; it made me smile though that they brought back the cheesegrater motif. Long as its quiet and doesn't glow with neon LEDs, I'm happy. Maybe I'm an odd man out, but my Mac Pro is on the floor next to my favorite piece of furniture, a drab grey McDowell & Craig 1940s all-American all steel desk that weighs roughly 200 pounds that inherited from my grandfather. It'll look just fine next to it but each to their own.

Something happened that seemed unshakable even a year ago. To say I have a lot of opinions about web browsers is putting it mildly as someone who's spent the last decade his life coding for them. Like most web devs, I went Chrome around 2009-2010 and stayed. Chrome started feeling less like a choice but a natural law. I already felt like too much of life was encapsulated by Google, from Gmail, to maps, to Chrome, not mention my dev accounts for API keys and the usual dev related nuggets of info Google has on me. I've tried to de-google myself, but each active choice seems to have me crawling back. I used Bing for years and still sorta, but it doesn't work for my daily workflow. DuckDuckGo lasted all of a week before I switched back to Google. Apple Maps has been mildly successful as an iPhone user. I still end up using Google Maps 75% of the time making it my most successful de-googlifcation attempt. I haven't even bothered with Gmail. However, something happened. My primary home browser is now FireFox. Unlike previous attempts, I didn't wake up and eschew Chrome but gradually over time I've found myself using FireFox more. Why?

Reason #1: FireFox Quantum is radically more performant

The guys at Mozilla knew that the performance was an issue, and it was even more so on MacOS. In a previous generation, the best way to experience FireFox was Chimera/Camino, a beautiful port of FireFox's Gecko to Objective C. FireFox has never felt mac like, and always laggier than other browsers. When Safari shook up the browser world, it was clear how much better of an experience Safari was than FireFox on OSX. It was fast. Ever since Safari, FireFox has been a 2nd tier experience on macOS. The lack of multi-threaded support was a big kicker as Webkit added this years ahead of Mozilla. Quantum brought this with its new Stylo CSS engine, and it shows. It's fast, is it faster than Chrome or Webkit? Probably not, but its damn close.

Reason #2: FireFox has containers!

I'm not much for social media. Name a service, and I probably don't use it (although I do like GoodReads and Untappd). I do however have FaceBook account dating back to when I first signed up for it in college. Facebook easily the most problematic of the social media companies. FireFox Quantum has a concept called containers, a way to isolate browsing experiences (cookies/caching) from other portions of the browser. The FaceBook container effectively puts FaceBook in jail, and I love it. Sorting sites also means placing various experiences separately from each other to prevent cross tracking. It's effective and wonderful. As much as FireFox touts privacy, it's never really been able to differentiate from Apple on this front.

Reason #3: Better UI

It's a goofy complaint, but the UI of FireFox before Quantum was relatively ugly and had a lot of wasted space. I wouldn't call the new FireFox beautiful, but it's solid and minimal, and I actually do not mind it at all. It has a distinctly Windows X look, but it's a big step up.

Reason #4: DNS over HTTPS

Chrome and FireFox are both adding this, but FireFox has it without having to use flags right now. DNS for years has been overexposed, so it's about time we have DNS over HTTPS.

Bonus reason: Firefox screenshots

Honestly, I don't use this as much as I should, relying on OSX's wonderful screenshotting but it is a nice feature.

Here's a post that hopefully saves someone a few hours of googling. I have a client who has a React-based Kiosk application and they want to use Pardot Forms to capture leads. This seems like a relatively straightforward, even reasonable ask and I assume, you dear reader thought so too. So you've probably tried something like this, assuming that you can post to a form like some jackass who expects a modern framework that assumes that this is feasible and you envision and/or wrote something like the following in beautiful ES6/ESnext syntax:

submitSignup(e) {
     const data = new FormData(document.getElementById('signupForm'));
     fetch('url-to-form-paradot-submission', {
       method: 'POST',
       dataType: 'jsonp',
       body: data,
     });
  }

This seems like it should work but, of course, it does not. Instead, you'll be greeted with a wonderful CORS error but the Pardot forms do not have any CORS controls. There's little information, and the developer documentation is sparse but I was able to unearth from the salesforce docs the following:

Submissions Using Ajax

Pardot doesn't support submitting data to form handlers via Ajax requests. When attempting to submit data to a form handler using Ajax, you will likely see errors like:

XMLHttpRequest cannot load {www.site.com/FormHandlerURL}. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin '{page from which form handler should be getting submitted on client's website}' is therefore not allowed access.

This is what's known as CORS (Cross-Origin Resource Sharing). Pardot doesn't currently support CORS or JSONP for form handlers. It is possible to simulate a JSONP response by setting the Success and Error URLs for the form handler to be JavaScript URLs that execute Success and Error callbacks, respectively.

So the answer is that it doesn't support AJAX and the only way is to hack the form responses to trigger JS scrips. I managed to find a GitHub project where a user created a Pardot Form AJAX Handler which shows an example with callbacks. Oy.

Bonus: As total newbie to Pardot, I found these videos helpful for navigating the Pardot interface. They're out of date, the UI has changed, but the core features can mostly be found in the same places.

At the event, Apple also plans to debut new software features for its devices, including a dark mode for easier nighttime viewing and new productivity tools for the iPad. The company has also internally weighed previewing a new version of the high-end Mac Pro, according to people familiar with the deliberations.
- Apple Plans on Combining iPhone, iPad, Mac Apps by 2021, Mark Gurman, Bloomberg

Buried in the bombshell is something of particular interest to me and this blog. I find this worrisome, Apple really doesn't seem to get it. The Mac Pro should be a boring box with the latest whatever internals with a few drive bays and PCIe slot with big numbers that people like myself only care about. What it shouldn't be is worthy of a press event or representing a paradigm shift or some other Jonny Ives goofball design. Want a beautiful shiny "wow-your-clients" pro computer? That's the iMac Pro, not the Mac Pro. What people want is user upgradable storage, ram, and PCIe: for NVMe storage, for GPUs, for esoteric I/O upgrades. How do I know this? There's certainly a demand as I've had well over 40,000 different users access my Mac Pro Upgrade Guide, and my blog isn't even a blip in the digital ocean.

Here's a fun one for any web developers out there, you can play with a JS reconstruction fo the WorldWideWeb Browser (the first web browser) for the NeXT OS. Go to worldwideweb.cern.ch.

Its fun in it's own right, but the CERN browser is a good measuring stick of how accessible a website truly is without CSS or Javascript or even a full HTML 1.0 spec. Without any support of POST methods, WorldWideWeb can't even interact with forms but information is often visible.

Take, for example, my blog. It's easy to consume, meaning anything can traverse it and index it with minimal effort. Anyone with an out-of-date browser arguably can access it. Incredibly many news sites are usable albeit awkward, like CNN.com and NYTimes fair well. ABCNews does not, nor will anything requiring a form like Google.com.

Information architects should take note; there's something to be said about resilient markup languages are.

As noted in the MacRumors Buyer's Guide and discussed in the MacRumors forums, it has now been 602 days since Apple last updated its iMac lineup, a new record for the longest span between iMac refreshes ever. The previous record was 601 days between October 2015 and June 2017 refreshes. - Joe Rossignol, MacRumors

Ouch. Just as I was spit-balling the future of the Mac Pro, Apple has let another computer rot in the supply chain. Apple's major press-opuses should be relegated to only large scope updates, and frequent refreshes with much less fanfare, assuming this is even a bottleneck. Really though, we should see nearly yearly updates with CPU and/or GPU refreshes to keep in step with PC manufacturers. This isn't even a particularly astute observation or even remotely original. I'm guessing this has more to do with maximizing profit vs. the hassle of changing the magical JIT manufacturing. It's not a hopeful sign if even Apple's signature desktop has been given the cold shoulder. There's a feeling among the Mac faithful that Apple doesn't care about the Macintosh. With numbers like these, it's easy to see why.

Today the Macintosh is 35 years old. Rather than a retrospective, I'm more interested today in the future of the Macintosh as my most trafficked blog post I've written is an upgrade guide the classic Mac Pro which are now 13-7 years of age depending on the model. In mid-2018, Apple announced that the Mac Pro would be revamped in 2019 and yet many Mac loyalists were irked that at the WWDC Apple didn't announce a Mac Pro. It was never going to be a one-more-thing, as it's very unlike Apple to announce a schedule for a future product.

Apple's desktop line up is far more crowded than it's been in some time, with the revamped Mac Mini, iMac, iMac Pro, and Mac Pro (which is half decade without an update). The Apple mainstay has a been at two or three computer company per formfactor, squarely divided between desktop and laptop (and briefly servers and eMacs) since roughly 2005 for desktops (Mac Mini), and 2008 for laptops (MacBook Air). The formula has been (outside of the illfated G4 Cube):

Classic Era (2000 - 2005)

• Entry Level - (iMac/iBook)
• Professional - (PowerBook / PowerMac)

Intel Era Line Up (2006-2016ish)

• Budget/Small form factor - (Mac Mini/MacBook Air)
• Mid-level - (MacBook / iMac)
• Profesional - (MacBook Pro / Mac Pro)

Current Era (2017ish - Current?)

• Budget - (Mac Mini, MacBook Air, iMac 21 Standard Definition, MacBook?)
• Mid-level - (MacBook? MacBook Air? / MacBook Pro 13 / iMac 4k/5k)
• Profesional - (MacBook Pro Touchbar / Mac Pro / iMac Pro)

Any iteration of the Mac Pro is going to confuse the Mac line-up further. The MacBook Air, MacBook Pro, MacBook are all within $100 of each other at for base models and 1.4 pounds, 1 hour of battery life and 1 inch of screen size. The Pro is clear-cut as the performer and the MacBook as the traveler and the Air as the bridge... for some reason. It'd only really take adding a second port (perhaps Thunderbolt) to the MacBook to negate the under performing Air.

The iMac Pro is undoubtedly a powerful machine but at a king's ransom, starting at $5,000. If a Mac Pro lands with anything resembling a dedicated PCIe slot, user serviceable RAM and CPUs, I can't imagine anyone opting for an iMac Pro and especially if starts at the still very expensive $3000 entry point as previous Mac Pros have. The iMac Pro is powerful but also, at it's price-point with non-upgradable GPU, and terrible user serviceability, hardly a compelling buy. Then there's the Mac Mini, if the Mac Pro keeps its current G4 Cube influenced hostile-to-power-users design, then anyone who can survive on more modest CPU and 64 GB of RAM is likely to eat the cost of a Thunderbolt PCIe case (or do the same with an iMac 5k). Based on my interactions with the Mac power users of this planet, we're all after the same thing: PCIe, User serviceable RAM, and upgradable CPUs and storage. This really should be Apple's most straightforward release year-over-year, the form factor of the classic Mac Pro is perfectly fine. Dust it off, update the ports from FireWire/USB2.0 to Thunderbolt and USB 3.x, slap in a modern motherboard with the latest specs and call it a day. Ideally, Apple would sunset the iMac Pro as a nice experiment in industrial design. As much as Apple dislikes user-control, the one segment where the users know better than Apple is professional work, see the fiascos of Final Cut Pro X and the Mac Pro 2013 which lead to the deep pockets of Hollywood abandoning Apple for the likes of PCs and AVID. The iMac's DNA never has been to be performance monster, although it evolved from entry level to a nice mid-level computer, sporting a beautiful integrated display. If the Mac Pro is modular, than the iMac Pro becomes the next G4 Cube.

Recently though, with the reintroduction of the MacBook Air, Apple has shown a willingness to confuse the Mac line up with no clear price point. This should be a bad thing but it isn't for the Mac Pro. So where does that leave us? I'm mildly hopeful. Just mildly.

Edit 01/29/19: NYTimes writes A Tiny Screw Shows Why iPhones Won’t Be ‘Assembled in U.S.A.’, which blames Mac Pro production yields on a lack of a certain screw. The idiocy here is the over-engineering and probably a healthy dose of hostility to user serviceablity, to echo myself Right To Repair Law Should Be The Rally Call Every Mac / iPhone User.

"Any national privacy law must provide clear, consistent protections that both consumers and companies can understand, and the FTC can enforce. That is why my bill leans heavily on the Privacy Act framework," Rubio wrote.

Rubio's bill would have the FTC establish a process in which individuals can contact companies to request access to their personal data. Companies would have to either provide the data to consumers or delete the data. If a company lets an individual view the data, the company would have to correct any mistakes if the person demonstrates that the records are "not accurate, relevant, timely, or complete." Companies would only have to delete the data if they choose not to provide it to consumers upon consumers' requests.

-- Jon Brodkin, Sen. Marco Rubio wants to ban states from protecting consumer privacy, Ars Technica,

This isn't even a "protection", as it's often unclear who even has your personal information and places all the onerous labor on the consumer. Deleting the data just means the company has to re-collect the information.

This is on the heels of Tim Cook's call for comprehensive US privacy laws and Motherboard's bombshell, U.S. Carriers Are Selling Customers’ Real-Time Location Data . We've seen time and time again how callous and morally bankrupt companies can be when it comes to selling personal information time and time again. There shouldn't even be an argument, there's clearly a need for privacy protection... and yet here we are, in the midst of a Kakistocracy. For those keeping score, congress voted in 2017 for a rule to remove a FCC privacy rule, and The Verge compiled a list fo the 265 members of Congress and how much it cost to buy them off. All were Republicans.

On the other side of the isle, Oregon's own Senator Ron Wyden has proposed a privacy law send company execs to prison for 20 years.

Anyone who gives one royal damn about internet privacy should best review the sharp divide among party lines, such as the fight over municipal broadband. If there's one thing that's been apparent when it comes to digital rights advocacy, you can count on the Republicans to oppose it.