More and more of the physical things that I played with as a kid are available in digital form on the web. Now that includes Spirograph. Take a few minutes to play with Inspirograph.
Lately I’ve been using MacDown for writing longer documents in Markdown. I tried a few other Markdown editors for Mac OS X and found that MacDown fit my needs the best. The fenced codeblock block support, with syntax highlighting via Prism, sealed the deal.
Bonus points for being open source – https://github.com/uranusjr/macdown.
The new Google Contacts management features look nice. Unfortunately the part with the biggest impact for me came at the very end:
P.S. The new Contacts isn’t yet available for Google Apps customers, but we’re working on it.
Not exactly the first time that Google Apps users have been left out of new features. I’m starting to regret running my main account though Google Apps.
Bryce Roberts on the temptations that distract from keeping an experiment simple and focused:
For now, we’ve been very conscious not to use any of those exciting terms to describe what we’re doing. And we’re trying our hardest to keep the spirit of the experiment as simple and no-frills as possible.
But the temptations to do “more” are many.
As with any product, there will be plenty of opportunities to tweak, add or enhance things down the road. But for now the focus is in on staying true to our intent and keeping it simple for anyone evaluating to assess.
Which is much harder to do than it sounds.
It’s so tempting to do, and say yes to, so. much. more.
But not now.
Now, we’re saying no to those many temptations to do more.
He was talking specifically about indie.vc. More often than not the early days of an experiment should reply with more no’s ( or at least not right now ) that yes’s.
Overly tight restrictions on what you can use for a password raises the little red flag in the back of my mind. Sadly banks are some of the worst at this. I recently came across the password policy page for Wells Fargo, which isn’t nearly the worst I’ve seen:
– Must be 6 to 14 characters.
– Must contain at least one letter and one number.
– May not contain nine or more numbers.
– May not be identical to your Username.
– May not repeat the same number or letter more than 3 times in a row.
– May not contain more than 3 sequential numbers or letters (such as ‘1234’ or ‘abcd’) in a row.
– May contain special characters (such as @, %, &, #).
There are several things to like about this. Avoiding sequences and repetition is good. I wonder where the requirement to use less than 9 numbers comes from.
The major pain point in this list is limiting the password length to only 14 characters. Any time I see a maximum length that small I fear they are storing it in plain text some where. Assuming reasonable hashing methods a maximum length closer to 70 characters would be significantly better.
Our redesign is here thanks to a big under-the-radar project in March 2014, when we migrated 17 active WIRED blogs into a single WordPress install. If we did our jobs right, you barely noticed that happen.
No doubt that this was a big job. Good to see it all come together, making their content easier to manage.
Unfortunately their new design includes the super annoying trend of covering up the text I was reading when I scroll up on the site:
This makes the reading experience really painful.
With the Chrome browser already making plans to retire SPDY in favor of HTTP/2 I started testing sites to see how many of them advertised support for HTTP/2. No surprise that Google does:
$ openssl s_client -connect google.com:443 -nextprotoneg ”
Protocols advertised by server: h2-15, h2-14, spdy/3.1, spdy/3, http/1.1
The response I got from Facebook turned up something interesting:
$ openssl s_client -connect facebook.com:443 -nextprotoneg ”
Protocols advertised by server: spdy/3.1-fb-0.5, spdy/3.1, spdy/3, http/1.1
I don’t recall seeing
spdy/3.1-fb-0.5 before. It comes from the Facebook proxygen HTTP library.
Chrome doesn’t check for this version of SPDY, I’m assuming no other regular browsers do either. My guess is the only clients that support this are Facebook mobile apps.
Back in November I mentioned a Chrome browser ticket to include favicon requests in the network panel:
— Joseph Scott (@josephscott) November 20, 2014
Should only be a matter of time before this shows up in stable releases of Chrome.
When you assign a DOM element an ID, that ID becomes part of the
window object. No joke, in the spec even ( emphasis mine ):
7.2.4 Named access on the Window object
The Window interface supports named properties. The supported property names at any moment consist of the following, in tree order, ignoring later duplicates:
the value of the id content attribute of any HTML element in the active document with a non-empty id content attribute.
On josephscott.org the sidebar section has an ID of “sidebar”, which is easily accessed in the Chrome Console:
document.getElementById( 'thingid' );, which is significantly faster.