I did so again now and when Page Speed Insights tells me to optimize images and cache things better the only unoptimized, non-cached things they point me to are Google Maps assets.
It would be rather nice if Page Speed would separate things they know I can't fix from things I might be able to fix and Google Maps seems like a thing that Google can certainly be very aware of that I can't be "fixing" (and my guess is also that there is no "fixing" to be made but that the unoptimized images and the non-cached assets are that way for some specific reason – otherwise I'm sure it would have been fixed a long time ago).
My solution – a test pinger: https://github.com/voxpelli/node-webmention-testpinger
By containing copies of real world mentions that are locally altered to target the site I'm testing and pinged to a local copy of my WebMentions code I can ensure that my parsing works well for a wide variety of mentions from around the web.
Currently there's only an example from my own site included in the public repository, but I've added more locally (See that neat little .gitignored .gitignore file? https://github.com/voxpelli/node-webmention-testpinger/blob/master/.gitignore#L2 A good way to selectivly and secretly keep some content out of your repositories) Hopefully more people will allow me to add their sites to the tool as well so that it can become a more extensive test for your WebMention code.
I've thanks to this little tool now been able to easily test my WebMentions service, https://webmention.herokuapp.com/, against many of the major sites within the #indieweb community to ensure that all mentions following the patterns of their sites are presented nicely by it.
PS4 + WebKit + WebGL = exciting stuff
I wanted to address some comments and clarify what is actually running WebGL with some development screen grabs. Each is highlighted accordingly. PS4 store is done completely in WebGL so I didn't attach anything related to that.
WebKit or Blink? We're a WebKit shop currently as people figured out from the PS4 license. The Blink/WebKit split happened after we were deep in development. My personal preference is Blink but that's not my decision to make.
UI framework is in house tech. I handled the layer below that it uses for its rendering which is all WebGL. Will be talking more about everything at that level during my talk at .
After some discussions on Twitter it was narrowed down to be something about the repaints of the menu so I set out inspecting it with the Safari Web Inspector tied to the iOS simulator.
My finding was:
1. The position: fixed menu is promoted to its own layer in iOS Safari and only repainted on the end of a manual scroll.
2. An animated scroll is made up of many window.scrollTo() calls, one per each "animation frame", that each scroll the page a small amount proportionate to the length of its animation frame.
The conclusion of those findings are pretty obvious:
If the fixed position menu is repainted on the end of a scroll and an animated scroll is made up many frames per second of which every one is a small scroll, then an animated scroll will mean a lot of repaints and thus a danger of the menu starting to flicker.
So unless there is a way to make an animated scroll be interpreted as a single scroll, I don't see a way to avoid a possible flicker of a sticky top menu.
Thanks to for his pointers on Twitter, pointing me in the right direction.
I'll be opting for an ordinary animated scroll rather than this CSS-emulated one since there will be some flicker/flash anyhow and I prefer a simple common solution if the effect is mostly the same.
It's of course open source and the hosted version is free for everyone to use (although with an account limit initially).
So a static blog or a lack of plugin for a CMS is no longer an excuse to not be part of the IndieWeb movement – now it's as easy as two button clicks and two snippets of code. Join!
Not being as cool as the coolest guys out there I haven't yet made the jump to Sublime (and not to Vim either for that matter) – still using TextMate 2 and loving it (having built up some nice bundles over the years https://github.com/voxpelli/goodold-tmbundle).
Latest find is how to use Composer and the latest in PHP coding standards, PSR-2, within TextMate to easily ensure that your code complies to the expected styles.
Here's the steps I followed:
1. Install Composer using Homebrew: http://getcomposer.org/doc/00-intro.md#globally-on-osx-via-homebrew-
2. Run "composer self-update" to ensure latest version
3. Install PHP CodeSniffer using Composer: https://github.com/squizlabs/PHP_CodeSniffer
4. Configure your PATH to include "~/.composer/vendor/bin/" and do the same with your TextMate path (Preferences > Variables)
5. Clone https://github.com/Drarok/php-codesniffer-tmbundle to your TextMate bundle directory (~/Library/Application Support/Avian/Bundles)
6. In the TextMate bundle directory (~/Library/Application Support/Avian/Bundles), symlink the bundle to the correct path (ln -s php-codesniffer-tmbundle/PHP\ CodeSniffer.tmbundle)
7. Configure a TextMate "PHPCS_STANDARD" variable to be "PSR2"
8. Done. Run the bundle command and get a full coding standards report for your current file!
This works for other coding standards as well. Found eg. this Drupal guide to be helpful in figuring it all out: http://www.nuams.com/blog/installing-drupal-code-sniffer-textmate
To find out which coding standards you have installed, run "phpcs -i" from the command line.
Apparently, all the of the (good) sentiments behind the reasons for choosing XMPP as the protocol for Google Talk (https://developers.google.com/talk/open_communications) are no longer the driving force behind the decision making regarding its replacement Google Hangouts. All that talk about Client Choice, Service Choice and Platform Choice has been replaced with "if the other big players don't play, why should we?". So all those "thousands of other ISPs, universities, corporations and individual users" Google Talk used to federate with are no longer important.
On top of that, XMPP is blamed for not keeping up with the times:
"When XMPP was designed, smartphones and social networks didn't exist. Yet both trends essentially transformed communication but the standard remains unchanged. For example, mobile has several requirements around bandwidth and battery that are simply not part of the standard. And audio and video integration are not well defined," [a Google spokesperson] said.
This glances over the the fact that the X in XMPP stands for eXtensible, which still results in proposals for new protocol extensions every month. The XMPP Council, which I am currently serving on, watches over XMPP extensions in the XEP series (http://xmpp.org/xmpp-protocols/xmpp-extensions/) of the XMPP Standards Foundation. However, as XMPP is built on distributed technologies, everyone can invent their own protocol extensions in private, too. Something that Google should be fully aware of, as they have created a bunch of their own protocol additions, of which some are documented here: https://developers.google.com/talk/jep_extensions/extensions.
To go into even more depth, at various times, battery and bandwidth constraints for mobile use, have been discussed within the XMPP community at several times, since at least in 2008 and possibly before, with protocol proposals like Roster Versioning (XEP-0273, now part of RFC 6121), SIFT (XEP-0273) and background information on XMPP on Mobile Devices (XEP-0286).
Meanwhile, Google never participated in any of these discussions (https://plus.google.com/116276248303121270590/posts/V7LzUzj8R4D). Instead, they invented their own protocol (google:queue) for delayed presence delivery, much like but slightly simpler than what SIFT proposes. Had Google just participated, that protocol had likely been remade into a true XEP, for broader use in the community. This would have prevented, for example, Facebook, from also creating its own protocol for the same thing (https://bugs.freedesktop.org/show_bug.cgi?id=38943).
Of course none of these concerns for mobile are applicable for server federation. As far as I know, the Google Talk client on Android doesn't even use XMPP as the client-to-server protocol.
Google did cooperate with the XMPP community on standardizing Jingle (http://xmpp.org/extensions/xep-0166.html), a suite of protocol extensions for initiating and managing peer-to-peer media sessions between two XMPP entities. Ironically, this includes *audio and video integration", the very thing Google now says is not well defined, where Google was by far the largest driver behind it. And then Google Talk also never fully implemented the standardized protocol, causing other implementations to add custom, non-standard, workarounds.
Likewise, there are several proposals and even IETF drafts (for enhancing network security, including spam prevention, that Google didn't bother to implement. As an example, whereas as many other server operators would have wanted to start verifying X509 certificates on the TLS encrypted connections between servers, Google still doesn't check certificates or serve up properly signed ones themselves, allowing rogue servers to come in play.
The XMPP community even tried to accommodate some of the harder issues with serving up proper certificates for large numbers of hosted domains, explicitly including Google Talk, resulting in this IETF draft: http://tools.ietf.org/html/draft-saintandre-xmpp-dna-02.
From personal experience with building federated social networks on top of XMPP at Mediamatic Lab, I can name several other protocols that would benefit some of the newer features in Google Hangouts, including Publish-Subscribe (XEP-0060) and the related Personal Eventing Protocol (XEP-0163), that Google just ignored.
How didn't the standard (XMPP) change again?
As was quoted in the TechHive article, we will just move forward.
- BloglovinWeb Developer, 2014 - present
- Pelles KodfabrikWeb Developer, 2006 - present
- ValtechWeb Developer, 2013 - 2014
- FlattrWeb Developer, 2010 - 2012
- Good OldWeb Developer, 2008 - 2011
Pirate Bay-grundare kan tvingas bära sin pappas kista i handfängsel
The Pirate Bay-medgrundaren Peter Sunde dömdes 2010 till åtta månaders fängelse för medhjälp till upphovsrättsbrott. Eftersom han sedan höll
Lheurt's devblog: Listen to Postgresql inserts with node.js
I've been playing with node.js a lot these last few days, and one of the things I've been trying to accomplish is to push live notifications
To avoid Android pitfalls, Mozilla shoulders Firefox OS update burden
Mozilla doesn't want Firefox OS users to have out-of-date versions of the mobile OS, so it's working to offer updates itself over Wi-Fi conn
Why HStore2/jsonb is the most important patch of 9.4
There are a bunch of features which are pending for 9.4, still, and a bunch of features which are already committed. Given how interesting s
Postcard For iPhone Lets You Post To Any Social Network At Once, Even Yo...
A new application, Postcard, launching today, will help you cross-post to various social media websites, but with a few unique twists. Unlik