Google Maps recently visited the Automattic Lounge. Now you can walk through the lounge using street view:
The Automattic Lounge in Google Maps
Leave a reply
Page Visibility
The W3C recommendation on Page Visibility was updated this week. Being able to detect if a tab currently has focus is an opportunity to adjust features and performance accordingly.
The HTML5 Rocks tutorial on Page visibility has example that automatically pauses a video when the tab is out of focus. The Mozilla Developer Network also uses the video pause example for Page Visibility. Must be the “Hello World” of Page Visibility examples.
Another example would be to turn down the update frequency when a tab is out of focus. No point in updating a page every second, even with a websocket, if the tab is in the background. The Page Visibility API makes it easy to dial the frequency down to something more modest, like once a minute, then turn it back up again when the tab gets focus.
Browser support for the Page Visibility API is pretty good in current versions. The two exceptions are Opera Mini and the Android Browser.
To deal with cross browser differences check out Visibility.js.
Ionicons Icon Font
Nice to see another open source icon font – Ionicons. I like the look of the Genericons better, but Ionicons has a much larger set of images.
Listen for SSL and SSH on the Same Port
Many corporate firewalls will limit outgoing connections to ports 80 and 443 in a vain effort to restrict access to non-web services. You could run SSH on port 80 or 443 on a VPS or dedicated server, but if you have one of those you are probably already using it to host a small web site. Wouldn’t it be nice if your server could listen for both SSH and HTTP/S on port 80 and 443? That is where sslh comes in:
sslh accepts connections on specified ports, and forwards them further based on tests performed on the first data packet sent by the remote client.
Probes for HTTP, SSL, SSH, OpenVPN, tinc, XMPP are implemented, and any other protocol that can be tested using a regular expression, can be recognised. A typical use case is to allow serving several services on port 443 (e.g. to connect to ssh from inside a corporate firewall, which almost never block port 443) while still serving HTTPS on that port.
Hence sslh acts as a protocol demultiplexer, or a switchboard. Its name comes from its original function to serve SSH and HTTPS on the same port.
Source code is available at https://github.com/yrutschle/sslh.
For small uses cases this may come in handy. If you were constantly needing to SSH to port 80 or 443 then I’d recommend just spending a few dollars a month to get a VPS dedicated to that task.
If you are stuck in a limited corporate network another tool you may find useful is corkscrew, which tunnels SSH connections through HTTP proxies.
Apple Should Stay Focused
It is no secret that Apple has lots of money in the bank, currently listed at $147 billion. It is also no secret that Carl Icahn wants Apple to spend a chunk of that money buying back their own shares. All Things D is reporting on a letter from Carl Icahn strongly recommending a larger scale buy back program:
With such an enormous valuation gap and such a massive amount of cash on the balance sheet, we find it difficult to imagine why the board would not move more aggressively to buy back stock by immediately announcing a $150 Billion tender offer (financed with debt or a mix of debt and cash on the balance sheet).
The current buy back program is $60 billion over three years. Why recommend more than doubling it? Goosing the stock value of course:
if you execute this buyback as proposed, we expect the share price to appreciate to $1,250, assuming the market rewards EBIT growth of 7.5% per year with a more normal market multiple of 11x EBIT.
Icahn has made a ton of money in the investment world, I have no doubt of his ability to continue to make more. That said, I’m going to disagree with his recommendation to have Apple spend more money on a buy back program.
A large scale buy back program sends a message that they’ve run out of their own investment ideas and the only thing left to do is to try and optimize the stock value based on current products and revenue. If the best return Apple can get by spending $90 billion is to purchase their own stock then that is a sign that they have started to give up.
Apple has done well because they’ve been able to make products that people want to buy, not by trying to tweak their stock value. Apple should stay focused on improving the products they have and developing new ones.
lockrun
Two years ago I mentioned Solo, which uses TCP/IP port binding to prevent a program from running more than once.
For those that don’t want to use up ports or would rather stick to file locks for other reasons you can accomplish the same thing with lockrun.
An example cron entry using lockrun:
*/5 * * * * /usr/local/bin/lockrun –lockfile=/var/run/cacti.lockrun — /usr/local/bin/cron-cacti-poller
IMPORTANT: Be sure to place the lockfile in a directory that only that user has the rights to, and not in /tmp (as this Tech Tip has previously suggested). If a different user has the ability to write to the directory, s/he could create a symbolic link from the target lockfile to some system file that uses locks the same way, and get the cron job to foul up the locking.
The file used, /var/run/cacti.lockrun, is created (if necessary), the lock acquired, and closed when finished. At no time does lockrun perform any file I/O: the file exists only to be the subject of locking requests.
Overall I like the Solo approach better, but it might not be a good option in every situation. In those cases lockrun looks like a good alternative.
The Weakest Link, Routers and Switches?
Wired ran an article last month about the NSA compromising routers and switches in their spying efforts:
According to the Post, the government planned to expand the program to cover millions of additional foreign machines in the future and preferred hacking routers to individual PCs because it gave agencies access to data from entire networks of computers instead of just individual machines.
This totally makes sense. More often than not the most interesting data is what is transmitted over the network. Also saves on having to compromise multiple computers, instead just breaking into the central point they all share.
Given the revelations of the NSA spying on U.S. citizens this year, it would seem likely that they would use the same approach domestically. There are hundreds of thousands ( if not millions ) of wifi routers, switches, and cable/DSL modems deployed across the U.S. in homes and businesses. Now combine this with the number of reports of simple compromises on some of these devices and you have a recipe for domestic spying on a large scale.
What sort of simple compromises do some wifi routers and switches have? Checkout a report this week on a few Netgear models, and another report earlier in the month about certain D-Link models. Even if these vendors released updated firmware revisions that fixed all of these issues, when is the last time you updated the firmware on your home router, cable/DSL modem, or switch?
PHP Security
Code security is one of those things that we need to have regular reminders about. This reminder is for PHP, but several of the issues apply to any language – Survive The Deep End: PHP Security.
The “Basic Security Thinking” section has a good general list of principles:
- Trust nobody and nothing
- Assume a worse-case scenario
- Apply Defense-In-Depth
- Keep It Simple Stupid (KISS)
- Principle of Least Privilege
- Attackers can smell obscurity
- RTFM but never trust it
- If it wasn’t tested, it doesn’t work
- It’s always your fault!
Personally I’d replace “Attackers can smell obscurity” with “Never underestimate the amount of time or resources your attacker has”, but the overall list still gets you in the right frame of mind.
If you deal with PHP code the rest of the document is definitely worth the time to read.
Live Concert Opportunities
Raanan suggests concerts should go from hypocrisy to opportunity:
I do get the argument that someone holding up their phone for 2 hours is a distraction to the other concert goers – so I think some common sense rules would be good. Like only take photos at the beginning or end of a song, and step into the aisle to take a longer video clip.
But I’d go even further. Why don’t live concerts have a professional photographer walking around who can take great shots for sale later. And why not offer a live audio or video recording of the concert?
After the concert all I saw for sale were CDs (!) and t-shirts. What if they had for sale a USB with raw HD video of the show plus high quality MP3s and online access too? I would be tempted to drop $40-$60 for that.
Embracing the concert recording idea and doing it at a higher quality sounds like a good move. The concert photos and videos could also be sold online for those who weren’t able to make it to the concert.
There may be a fear that selling recordings of the concert will reduce ticket sales. Perhaps, but with people recoding it any way with their mobile devices you can either lead and profit from the trend or watch it happen from the side lines.
Reminds me of the news paper industry during the 1990s.
Books: The Year Without Pants
I finished reading Scott Berkun’s book The Year Without Pants. The book tells the tale of Scott’s time at Automattic as the lead of Team Social, which worked on WordPress.com. I’ve never read a book about a place that I’ve worked at, so I was curious to see things from his point of view.
I’ve worked at Automattic for over six years, well before Scott started there. We were always on separate teams and I never worked directly with Scott on any projects. As a result some of the things Scott talks about in the book take on a different angle than my own. While reading through the book I made notes on things that I wanted to expand on a bit, provide a different point of reference for, or just struck me as interesting. I’m including the page number for easy reference.
Page 10, talking about how for many people Automattic was the largest company they had ever worked for. I definitely didn’t fall into that camp. Oddly enough I’ve alternated between large and small companies, though not on purpose. Before Automattic I worked at a university that had thousands of employees. Before that I was at small regional ISP that never had more than 10 full time employees. Going back one more job I was at a large international company with more than 10,000 people across the planet. And the job before that was at a company with 20 people. That pretty much covers all of the jobs I’ve had as an adult.
Page 15, about IRC being an ancient chat program. When I mention to other people that we use IRC I’ll often describe it as being “as old as dirt”, meaning 1988. Being old doesn’t change the fact that it is still one of the best solutions to the problem of text based chat.
Page 16, about Automattic demanding great communication skills. In some ways we have to overcommunicate in order to make up for not all being in the same building.
Page 20, Caturday. Long running thing at Automattic from the world of LOLcats. On page 25 Scott shows a screenshot of some stats, and the week ends with Caturday. Some time ago a new hire at Automattic “fixed” the typo by changing it to Saturday. We had to explain the joke, then had them revert it back to Caturday :-)
Page 25, experts don’t go back to regular jobs because regular jobs are hard. This is worth keeping in mind the next time you read an article or book from a professional expert.
Page 28, on jamming practices from one culture into another. This is a hard lesson to learn and I think most who have learned it have only done so through experience. Culture isn’t something you can easily transplant. Culture, like trust, is hard to build and easy to destroy.
Page 29, about trust. Trust is a really big deal in any company culture. The lack of it usually results in grinding political structures. High degrees of trust can result in the whole being so much more than the sum of the parts.
Page 42, remember how I mentioned that I described IRC being as old as dirt? I’m not the only one who thinks that way :-)
Page 43, about many things at Automattic being inherited from the open source WordPress project. I don’t think it is an overstatement to say that this is one of the core attributes in the formation of Automattic. In many ways it looks like a group of people working on an open source project that just happens to also involve money, sometimes.
Page 46, about the WordPress theme P2. One day I’ll write a separate post about how P2 came to be. Naming things can be hard, and sometimes beyond your control.
Page 48, on the communication break down between P2, IRC, Skype, and email. The ratio varies between teams. For my experience I’d say P2 and IRC are closer to 50 / 50, Skype and email nearly rounding errors. IRC was good for talking about something right now ( synchronous ) and P2 was good for things that weren’t nearly so time sensitive ( asynchronous ) or needed a better way to be tracked.
Page 54, about the size of a company being the ultimate goal. I’ve had conversations with people about companies that stay intentionally small. In the technology field it isn’t often that you come across people who want to have a limit to how big their company gets. I think there is an idea worth exploring in there.
Page 61, regarding killing a project or experiment. It isn’t easy to shutdown something that you’ve put energy into. That said, we could be better about letting go.
Page 104, data-influenced culture versus a data-driven one. I’ll give an example of one experience I had that shows how this worked. A new A / B test was launched around a signup flow and I was fairly certain that the new version was going to do worse because the resulting experience was so bad for the user. It quickly became clear that the new version resulted in more revenue. As a team we talked it over and decided against using the new version, even though it meant giving up some of that increase in revenue. I was happy we were able to agree on that because the user experience in the new version was one I’d never want to use. The results of the A / B test were one part of our decision making process, but it wasn’t the only consideration.
Page 111, vision. Someone having a clear vision of where things are going as a whole is a different dynamic in a company that focuses on individuals being super proactive about coming up with their own ideas on what to work on next. Not that you can’t have it, just that at some point you realize everyone can’t do everything. See also page 126 regarding clarity vs. quantity of ideas.
Page 132, “Without the time machine, all choices have the possibility of being wrong.” I need to put that on a t-shirt. Sometimes the value of making a decision outweighs any of the potential outcomes of the decision itself.
Page 134, on not being tied down too much by a pre-selected process. I’ve been asked before if Automattic uses [ insert current trendy methodology here ]. My answer has always been no. We work out what works best for us as a team, then start moving forward, adjusting along the way as needed.
Page 136, “To start big projects, you must have the capacity for delusion.” Probably also worth a t-shirt. At some point after going through enough big projects you learn that you always underestimate them at the beginning. Then after even more of them you learn that under estimating them is sometimes a good thing, because if you didn’t you would never actually start them.
Page 152, about work environments. When I talk with people about Automattic being a distributed company, I usually end up explaining that like most things it is about trade offs. Distributed vs. non-distributed is often less about which one is better and more about which trade offs you want to work with. The same is true of individuals. Not everyone is going to excel in a distributed situation, and that is fine, it doesn’t make them bad at what they do or who they are.
Page 171, talking about Team Social being stretched even further. When Scott joined Automattic I started working on the Akismet team. Our team was always stretched, with people in Melbourne ( Australia ), California, Utah, North Carolina, and England. From UTC that is +11, -7, -6, -4, and +1 for everyone playing along at home. Not the same broad and even distribution that Team Social ended up with, but not always easy either. But we made it work.
Page 198, a reference to the bike shed problem. Long time FreeBSD users will remember the bike shed post by PHK.
Page 200, on few people being willing to dive in and make changes. That is pretty much the opposite of my experience.
Page 200, about broken windows for good and bad. I think our ability to fix a bug that came up quickly is a good thing. There obviously has to be some balance with other things, but I would never want to lose our ability to go from getting a ping from a friend about something on our service being broken, to being able to reply that it has now been fixed, often in a matter of minutes.
Page 201, some people being afraid to post on a P2 because they think it is a megaphone and everyone is reading it. What is funny about reading that is that before we had P2, there was just one internal blog for all of Automattic and it was rarely used. It was common for it to only get one post per month. P2 changed that dramatically.
Page 225, “No one should be expected to carry the burden of a secret their peers would love to know.” Not worth putting on a t-shirt, but something that every leader should remember.
I could comment on every page in the book, but these were the points that I noted specifically as I read through it.
The book itself is an enjoyable read, and easy to get through. If you’ve ever wondered what things are like at Automattic, The Year Without Pants, is a pretty good window. Just keep in mind that it is from one point of view and that each team has a high degree of flexibility in doing things in a way that works best for them.
If you would rather live it than read about it, Automattic is hiring.
