- White Hat’s Dilemma (Google Docs) — amazeballs preso with lots of tough ethical questions for people in the computer field.
- Chinese Hacking Team Caught Taking Over Decoy Water Plant (MIT Tech Review) — Wilhoit went on to show evidence that other hacking groups besides APT1 intentionally seek out and compromise water plant systems. Between March and June this year, 12 honeypots deployed across eight different countries attracted 74 intentional attacks, 10 of which were sophisticated enough to wrest complete control of the dummy control system.
- Web Tracing Framework — Rich tools for instrumenting, analyzing, and visualizing web apps.
- CoreOS — Linux kernel + systemd. That’s about it. CoreOS has just enough bits to run containers, but does not ship a package manager itself. In fact, the root partition is completely read-only, to guarantee consistency and make updates reliable. Docker-compatible.
Velocity 2013 Speaker Series: Focus on Web Apps, Not Web Pages
We’re not making web pages anymore; we’re building web applications. Gone are the days of a few script tags in the <
head>. Apps today are a complex web of asynchronously-loaded content and functionality. In the past decade, we’ve progressed from statically-loaded HTML to AJAX-ifying all the things. However, the way we’ve been measuring real user performance of our apps hasn’t changed to reflect our new state of art.
At what point during page load do users consider an app to be “ready enough” to start using? If we use standard performance metrics, we have to choose one of the following:
1) When the HTML document has been completely loaded and parsed, but before stylesheets, images, and subframes have finished loading (
2) When all synchronous scripts, stylesheets, images, and subframes have finished loading (
If we pick
DOMContentLoaded, it quickly becomes clear that there’s no inherent correlation between the app state at that point and what a user would consider “ready.”
Velocity 2013 Speaker Series
You wake up one morning to discover your team has gotten a dreaded alert: your web application is performing badly. You dig through your code, but don’t see anything that stands out, until you open up Chrome’s memory performance tools, and see this:
One of your co-workers chuckles, because they realize that you’ve got a memory-related performance problem.
Modern Security Ethics, Punk'd Chinese Cyberwarriors, Web Tracing, and Lightweight Server OS
Security Sensor, Mobile Speed, Rate Limiting, and Self-Assembling Drone
- Canary (IndieGogo) — security sensor with video, motion, temperature, microphone, speaker, accelerometer, and smartphone remote control.
- Page Speed is Only The Beginning — 73% of mobile internet users say they’ve encountered Web pages that are too slow. A 1 second delay can result in a 7% reduction in conversions.
- Rate Limiting and Velocity Checking (Jeff Atwood) — I was shocked how little comprehensive information was out there on rate limiting and velocity checking for software developers, because they are your first and most important line of defense against a broad spectrum of possible attacks. It’s amazing how many attacks you can mitigate or even defeat by instituting basic rate limiting. (via Alex Dong)
- Self-Assembling Multicopter (DIY Drones) — The true accomplishment of this research is that there is not one robot in control – each unit in itself decides what actions to take to keep the group in the air in what’s known as Distributed Flight Array. (via Slashdot)
These blinders derail Drew Crawford’s detailed rant on Why mobile web apps are slow. It turns out that “slow for what?” is a key part of the question, as Crawford reveals near the very end:
It may also be true that the browser vendors have optimized their performance as far as they can, at least in the relatively stable fields of HTML parsing and processing, and CSS selectors and formatting. Adding
So how can we optimize mobile web development?
Velocity 2013 Speaker Series
One important thing that shapes the overall single-page application performance is instrumentation of the application code. The most obvious use-case is for analyzing code coverage, particularly when running unit tests and functional tests. Code that never gets executed during the testing process is an accident waiting to happen. While it is unreasonable to have 100% coverage, having no coverage data at all does not provide a lot of confidence. These days, we are seeing easy-to-use coverage tools such as Istanbul and Blanket.js become widespread, and they work seamlessly with popular test frameworks such as Jasmine, Mocha, Karma, and many others.
Instrumented code can be leveraged to perform another type of analysis: run-time scalability. Performance is often measured by the elapsed time, e.g. how long it takes to perform a certain operation. This stopwatch approach only tells half of the story. For example, testing the performance of sorting 10 contacts in 10 ms in an address book application doesn’t tell anything about the complexity of that address book. How will it cope with 100 contacts? 1,000 contacts? Since it is not always practical to carry out a formal analysis on the application code to figure out its complexity, the workaround is to figure out the empirical run-time complexity. In this example, it can be done by instrumenting and monitoring a particular part of the sorting implementation—probably the “swap two entries” function—and watch the behavior with different input sizes.
DevOps is as much about culture as it is about tools.
Operations professionals live in a wind tunnel. If you can imagine one of those game show glass boxes, where a contestant stands inside, the door shuts, and money blows around in a whirlwind, you’ve got a good idea of what Operations feels like much of the time. While you’re trying to grab one technology, another has forced itself across your eyes demanding attention.
The incredible growth of an industry that didn’t really even exist fifteen years ago has provided us with endless opportunity and innovations. It’s also required us to be on the forefront of many new technologies in a way other professions aren’t. The constant drive towards the next technology, the next platform, and the next idea has stratified our organizations, creating specializations in areas like networking, storage, security, data sciences, and a myriad of other functions that challenge our ability to work with our colleagues as a cohesive team.
Tweet Cred, C64 History, Performance Articles, Return of Manufacturing
- Credibility Ranking of Tweets During High Impact Events (PDF) — interesting research. Situational awareness information is information that leads to gain in the knowledge or update about details of the event, like the location, people affected, causes, etc. We found that on average, 30% content about an event, provides situational awareness information about the event, while 14% was spam. (via BoingBoing)
- The Commodore 64 — interesting that Chuck Peddle (who designed the 6502) and Bob Yannes (who designed the SID chip) are still alive. This article safely qualifies as Far More Than You Ever Thought You Wanted To Know About The C64 but it is fascinating. The BASIC housed in its ROM (“BASIC 2.0″) was painfully antiquated. It was actually the same BASIC that Tramiel had bought from Microsoft for the original PET back in 1977. Bill Gates, in a rare display of naivete, sold him the software outright for a flat fee of $10,000, figuring Commodore would have to come back soon for another, better version. He obviously didn’t know Jack Tramiel very well. Ironically, Commodore did have on hand a better BASIC 4.0 they had used in some of the later PET models, but Tramiel nixed using it in the Commodore 64 because it would require a more expensive 16 K rather than 8 K of ROM chips to house.
- The Performance Calendar — an article each day about speed. (via Steve Souders)
- Mr China Comes to America (The Atlantic) — long piece on the return of manufacturing to America, featuring Foo camper Liam Casey.
A/B with Google Analytics, Lego Rubiks Solver, TV Torrents, and Performance Tools
- ABalytics — dead simple A/B testing with Google Analytics. (via Dan Mazzini)
- Fastest Rubik Cube Solver is Made of Lego — it takes less than six seconds to solve the cube. Watch the video, it’s … wow. Also cool is watching it fail. (via Hacker News)
- Fairfax Watches BitTorrent (TorrentFreak) — At a government broadband conference in Sydney, Fairfax’s head of video Ricky Sutton admitted that in a country with one of the highest percentage of BitTorrent users worldwide, his company determines what shows to buy based on the popularity of pirated videos online.
- Web Performance Tools (Steve Souders) — compilation of popular web performance tools. Reminds me of nmap’s list of top security tools.