- Everything You Wanted to Know About Synchronization But Were Too Afraid to Ask (PDF) — This paper presents the most exhaustive study of synchronization to date. We span multiple layers, from hardware cache-coherence protocols up to high-level concurrent software. We do so on different types of architectures, from single-socket — uniform and non- uniform — to multi-socket — directory and broadcast-based many-cores. We draw a set of observations that, roughly speaking, imply that scalability of synchronization is mainly a property of the hardware.
- Raspberry Pi as Low-Cost Security Camera (Instructables) — $120 HD motion-sensing web-viewable security camera.
- Inside YouTube’s Fame Factory (FastCompany) — great article about the tipping point where peer-to-peer fame becomes stage-managed corporate fame, as Vidcon grows. See also Variety: If YouTube stars are swallowed by Hollywood, they are in danger of becoming less authentic versions of themselves, and teenagers will be able to pick up on that,” Sehdev says. “That could take away the one thing that makes YouTube stars so appealing.”
Introducing updated HTTP client support and JSON API integration.
Java 8 may only have been released a few months ago, but Oracle has already announced the first set of features that will be targeted for Java 9. On August 11th, Mark Reinhold, a Chief Architect for Java, made available an initial feature set to subscribers on the jdk9-dev mailing list.
The crop of features are being run under a relatively new process, known as Java Enhancement Proposals (JEP). This process allows new language and VM features to be prototyped and explored without the full weight of the normal Java standardization process, although the expectation is that suitable, successful JEPs would go on to formal standardization. There will, of course, be many other new features that will be introduced in Java 9, but in this post we are going to focus on two major enhancements — and examine how they relate to features added in Java 7 and 8.
Charting the progress towards AngularJS 2.0
AngularJS, for me, was a revelation the first time I encountered it. I was coming from using GWT (Google Web Toolkit), and seeing our large application shrink in lines of code by 90% was close to a spiritual experience. I was a convert from day one, because I knew how bad things were otherwise. Ever since, I have been associated with AngularJS in one way or another, and have seen how it makes things absolutely simple with data binding, templating, routing, unit testing, and so much more. But the more I used it, some things didn’t make sense, from naming to concepts. I got the hang of it, but I never really got to like why directives needed to be so complex, or how the built-in routing was quite limiting. While AngularJS made it trivial to write applications, it also made it trivial to write slow, hard-to-maintain applications if you didn’t understand how it all worked together.
Site speed is essential to business success, yet many pages are getting bigger and slower.
Earlier this year, I was researching online consumer preferences for a client and discovered, somewhat unsurprisingly, that people expect web sites to be fast and responsive, particularly when they’re shopping. What did surprised me, however, were findings in Radware’s “State of the Union Report Spring 2014” (registration required) that showed web sites, on average, were becoming bigger in bytes and slower in response time every year. In fact, the average Alexa 1000 web page has grown from around 780KB and 86 resources in 2011 to more than 1.4MB and 99 resources by the time of the early “2014 State of the Union Winter Report.”
As an experiment, I measured the resources loaded for Amazon.com on my own computer: 2.6MB loaded with 252 requests!
This seemed so odd. Faster is more profitable, yet companies were actually building fatter and slower web sites. What was behind all these bytes? Had web development become so sophisticated that all the technology would bust the seams of the browser window? Read more…