Google Blogoscoped: "Google Chrome is Google’s open source browser project. As rumored before under the name of “Google Browser”, this will be based on the existing rendering engine Webkit. Furthermore, it will include Google’s Gears project."
That's a mobile play.
David Anderson on Infoq, Future Directions for Agile. I think maybe this is the best material I've come across on Agile since v2 of Extreme Programming. It floored me.
I didn't like this presentation to start with, but it sucked me in. Give it 10 minutes (I know, that's *forever*). Agile these days is like food and drink, but not everyone today will know the conditions Agile grew out of and what needed to be fixed. The first half hour is an excellent history lesson. There are two underlying themes. First is that Agile needs to become predictable, a science, and not devolve into a cargo cult. The second is that Agile needs to grow beyond the programming part of the software business.
The presentation really kicks off about 35 minutes in when some new
principles get derived from lean techniques. I'd like to say the answer
is to expand towards Lean, because it addesses so many lifecycle, quality
and scheduling problems, and this is a landmark presentation, but there's more to it than that.
"in knowledge work problems, coordination costs grow non-linearly with batch size".
It's funny how things work. The first time I heard of Kanban was in 2001, on a work placement; another student who was in manufacturing explained how crates of parts were being pulled from a shelf when the production needed them; when that shelf was pulled from that caused part orders to come in from outside. That was a good 5 years before starting my CS degree. At the time I knew nothing about programming; I just thought it was cool seeing how dental floss boxes were made (I was told that the one-piece dental folding floss box itself was an industrial design breakthrough).
"If you multiply what we know we can get out of agile and lean methods and what the SEI and academic communities know you can get from software product lines, you get a 100-fold. improvement, an improvement on the same sort of scale, that we've seen in manufacturing over a hundred years as they moved from mass manufacturing to lean manufacturing."
Anderson refers to cloud computing and says architecture and design will be back in fashion in a few years. I'd say it already is, but in the guise of splitting out heavy infrastructure work from development, and starting to rely on DSLs, not the old way of trying to make things perfect upfront and visual/4gl programming.
Last quote: "Get it out of your mind that high maturity and agile are incompatible. If you like maybe CMMI levels 2 and 3, and the antipatterns they create are very incompatible with agile, but high maturity levels, 4 and 5, that's what we've aiming for all these years"
The presentation ends with some stuff on real option theory (as opposed to the last responsible moment), the part about how people prefer making a decision over being right alone is worth it.
Kellan Elliott-McCrae: "You can already specify that you want the output format of a Flickr API call to be REST (POX), XML-PRC, SOAP (shudder, not sure that one still works), JSON, or serialized PHP. We always wanted to support formats like KML, or Atom but we were never quite sure how to represent the results of a call to flickr.photos.getInfo() or flickr.photos.licenses.getInfo() as a KML.
Last week we finally got around to pushing out our 80% solution — an experimental response format for API methods that use the standard photos response format that allows you to request API responses as as one of our many feed formats.
You can now get the output of flickr.photos.search(), or flickr.favorites.getList() as Atom, or GeoRSS, or KML, or whatever.
The syntax is "&format=feed-{SOME_FEED_IDENTIFER}" where the feed identifiers follow the same convention you use when fetching…feeds."
Marc Andreessen, 2007: "You have to provide a runtime environment that can execute arbitrary third-party application code. You have to build a system for accepting and managing that code. You have to build integrated development tools into your interface to let people develop that code. You have to provide an integrated database environment suitable for applications to store and process their data. You have to deal with security in many different ways to prevent applications from stepping on one another or on your system -- for example, sandboxing. You have to anticipate the consequences an application succeeding and needing to be automatically scaled. And you have to build an automated system underneath all that to provide the servers, storage, and networking capabilities required to actually run all of the third-party applications."
Gina Bianchini, 2008: "Third party widgets and applications are entirely separate from Ning. We cannot be responsible for them nor guarantee that they will continue to abide by our Terms and therefore be available. Moreover, our policy not to discuss the details of violations publicly limits not only what we can say after an event, but the advanced warning that we can provide before it.
We would have loved to provide ample warning to Network Creators about this decision. The difficulty is that I'm not sure there would have been a way for us to do so that didn't violate the privacy of parties involved."
Steve Loughran said a while back that you can't just treat the cloud as a cloud because you have to know where your data is, for non-technical reasons. So it looks like this nascent industry has some policy issues to work out, but I still find Andreessen's "level 3" vision inspirational:
"I believe that in the long run, all credible large-scale Internet companies will provide Level 3 platforms. Those that don't won't be competitive with those that do, because those that do will give their users the ability to so easily customize and program as to unleash supernovas of creativity."
Handling a path based URL in Java, with Jersey, Spring2.5 and StringTemplate:
@Path("users") @Singleton
public class SingletonUserResourceWithSpring
{
private static final String OPENSOCIAL_MEDIATYPE = "application/atom+xml";
@Inject private UserAccountService userAccountService;
private StringTemplateGroup templates;
public SingletonUserResourceWithSpring() {
templates = new StringTemplateGroup("templates");
}
@GET @Path("/{uid}")
@Produces(OPENSOCIAL_MEDIATYPE)
public String getByUID(@PathParam("uid") String uid) {
UserAccount account = userAccountService.findByUID(uid);
return renderToResponse(account);
}
private String renderToResponse(UserAccount account) {
StringTemplate userxml = loadTemplate("templates/user_opensocial");
userxml.setAttribute("accountName", account.getAccountName());
userxml.setAttribute("uid", account.getUid());
userxml.setAttribute("email", account.getEmail());
userxml.setAttribute("firstName", account.getFirstName());
userxml.setAttribute("lastName", account.getLastName());
userxml.setAttribute("render_summary_flag", "yes");
return userxml.toString();
}
private StringTemplate loadTemplate(String template) {
return templates.getInstanceOf(template);
}
}
That's not bad. It could be even tighter in Groovy. Tip of the hat to javakaffee and Paul Sandoz.
Brendan Eich: "One point about Trace Trees (as opposed to less structured kinds of tracing): you get function inlining without having to build interpreter frames at all, because the trace recording must reach the loop header in the outer function in order to complete. Therefore, so long as the JITted code stays 'on trace', no interpreter frames need to be built."
Fast JIT for JavaScript - wow. Let's have some Devo:
Loads of stuff in the release: Release Notes. It's marked beta; I'd expect some API changes between now and 1.0.
First impression: faster. These days IDEA is a beast of an IDE. I find 7 much better than 6 in terms of features and speed. But 8 is nippier, especially for starting up and compile. Second impression: stable. I've been banging at it for 3 days and it hasn't crashed once. EAP for 7 was flakey at times. I'll probably switch over fully to 8, even with the loss of plugins. The UI is slightly cleaner, especially around the tabs area. but nothing radical (which is fine).
At the moment Groovy or Ruby support isn't available, and inbuilt Python and Scala support will arrive. I use Eclipse/PyDEV for Python, but I'll be very interested to see what if anything they do for Scala refactoring, especially given the power of its type system. Apparently Grails and Struts2 will be supported - good. The SQL/MySQL support is very handy.
I haven't had a chance to use the Jersey/JSR-311 support yet, but I'm buzzed about proper support for *something* other than query parameters in Java (JSR-311 is close to going into final call, os it should be safe to integrate the IDE) - Jersey is a tidy piece of code. I hope the major web frameworks will follow up and support it (especially Spring MVC). There's also full blown support for Freemarker and Velocity; it's very nice to see something other than JEE/JSP sanctioned templating.
All in all, it looks very good. You can find out about the EAP here: IntelliJ IDEA 8 Milestone 1
Damien Katz: "Simpler is better, and REST is generally simpler than SOAP"
It's hard to imagine anything simpler than SOAP:
<SOAP:Envelope
xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"/>
<SOAP:Header />
<SOAP:Body />
</SOAP:Envelope>
there you go. That's as simple as its gets, TSTTCPW. Way less cruft than Atom or RSS. It even says its simple - the Simple Object Access Protocol. REST is not that simple; you can fit the basics into a few slides, but
it's purpose is to induce simplicity into the right places, not be simple.
No, the issue isn't relative simplicity; it's how complexity is organised. Talking about something being simple when not actually looking at how inevitible complexity is going to be dealt with, is asking to get into the weeds. Tesler's Law is very real. REST is an architectural style described in architectural style talk - talk of principled design, constraints, derivation, quality properties. It's the kind of language you expect from cathedral enterprise architect types and IEEE diehards whose idea of a program manager is probably Gene Kranz. The kind of people Spolsky called astronauts; surely not for desperate Perl/Python/PHP hackers and smart people getting things done on the Web. REST like any architectural style is very much about managing the complexity that won't go away. It's ironic that system like the Web, often frowned upon by architects, is so well articulated in its architecture, whereas the WS-* and previous EAI technologies that are used by architects have precious little to say about their overall effect. The important thing about REST is not that it's better or worse than SOAP/WS-* - the important is that REST is architecture turned up to 11, done right, not the self-indulgence that neccesitated Agile.
So here's the thing for me - REST works. It does what it says on the tin, which is describe an approach to building a class of systems. It can be reasoned about. You can predict what might happen if you relax one constraint or introduce another. That process of taking away and adding to, is about as close to engineering as you can get in our industry (with the exception of continuous testing). Having REST was enormously when useful I worked on the Atom Protocol, and probably even more so on the Atom format (feeds are a kind of iterator, whereas the web is kind of decentralised hashtable; these are very different and a design tension results, that you wouldn't see with XMPP where feeds aren't needed). When it comes to designing APIs, having a well understood canon to 'spike' protocol designs against is FTW. I've found REST, and the approach it uses to define architecture, valuable, again and again since I came across the thesis. Want to take away uniformity? Put state in a particular place? Have servers invoke clients? Introduce write-thru cache? Sessions? Ok, we can reason about how that might work out or what the cost/benefits might be. I've never seen anything like that for WS-* or most middleware tech - it's all voodoo and sacrifice by comparison. You use a canon like REST the way building architects and masons once used De architectura.
There is a hype cycle around REST, which will be a problem for a while and then it will go away as hype cycles do. In the meantime the REST canon won't be rewritten to suit 65 day business cycles or strategic vendor concerns. I think sometimes that the problem people have with REST is that it's so well-defined; it's not witchcraft, it's not a cargo cult. You can't argue with it on a relativistic basis or apply clever rhetoric or continously redefine what it means. An architectural style isn't "good" or "bad" - you have to decide if it's the right fit for your problem space and if not, you have to come up with a more appropriate one.
I linked to "Beyond REST? Building data services with XMPP" recently, where REST is described as non-Newtonian physics. Which is an excellent line, but if we are going to say that, and say there is something up with constraints when we need to hit a server on average 500 times to get an interesting event, we eventually have to show up with another physics. That's how an engineering science should work. One that offers explanation and predictability. XMPP I think is a great protocol, but it is not a complete architecture (it's interesting in the IM world, there's no named equivalent to "the web"). Happily there is a candidate - Rohit Khare's Extending the REpresentational State Transfer (REST) Architectural Style for Decentralized Systems. This will be important reading for people who are hitting a scale wall on the client server constraint of REST (as found on the Web), now or the next few years.
update: TechMeme have picked this up.
T-Mobile are going to launch an application store according to Silicon Alley Insider's article, T-Mobile's Big Idea: An iPhone-Like App Store For Every Phone:
"Like all wireless carriers, T-Mobile needs its subscribers to start doing more with their phones than just making phone calls and sending text messages. So, perhaps inspired by the early success of Apple's iPhone App Store, it's reportedly making a smart decision: Opening up its phones to more mobile software, and making it easier to download apps." .
It'll be interesting to see how they organise the UI - the iPhone appstore arguably has a few iterations to go . The article goes on to describe the benefits to T-Mobile's customers:
"What does this mean? In theory, more apps and a better shopping experience. That's good news for consumers, and if it gets more people to buy apps and sign up for mobile Internet access plans, good news for T-Mobile, too.
This is a no-brainer for T-Mobile's smartphones, like the Sidekick series, its forthcoming phone running Google Android, and whatever Windows Mobile phones the carrier sells."
A few weeks ago I suggested we'll see other application stores after the iPhone launch; I expect there'll more of these. Being able to decouple a launch from an embed date and allow 'hits' a la the games industry are game changers.
Dion Almaer has some issues with Javascript 2. Enough to use Perl6 as a foil, which is never a good sign.
"I would love an import/include statement."
So would I. This kills me about JavaScript - so many powerful programming features, but no way to mange code properly. I think this more than anything is what results in thousand line .js monstrosities.
"I am also not a fan of the optional static typing."
I though this was bad, in the context of Python, a few years ago, when the idea was being floated for that language. Having experimented with Scala and Cobra late last year, I think types in function arguments are a fine idea. Mainly because they're the 80/20 point for type verbosity, performance, tooling and code maintainance. Type args give the compiler a lot of information for optimising calls, they help with an important class of automated refactorings, they help with IDE tooltipping/browse-ahead, and they document function calls in the code for the next guy - not knowing the types of functions is a problem imvho for Python codebases - or at least it is for me.
(update: 20008/08/08 Blaine Cook reminded me that Twitter have had an XMPP firehose for a while)
if you enjoyed Kellan Elliott-McCrea and Evan Henshaw-Plath's presentation "Beyond REST? Building data services with XMPP", here's a dose of links:
(Jabber) as a transport in ActiveMQ.")
Hadoop's test suite takes a long time to run. Steve Loughran and Doug Cutting have done some work to speeding them up: see HADOOP-3694. In the meantime if you want to focus on a particular test, follow Steve's HadoopUnderIDEA instructions on the wiki, and add a "test.include" property to build.properties. For example to focus on just TestCLI.java, add the property "test.include=TestCLI*". The ideal thing would be to have IDEA pick up a global test config, but I haven't figured out how to do that yet.
Eric Burke: "A few years back, we had a case where a 3rd party library had embedded JDOM beta 8 into their JAR, but they did not change the package names. When we tried updating our applications to JDOM 1.0, we ran into conflicts because the old JDOM was embedded into one of the JAR files we needed. This is exactly the kind of problem that Jar Jar Links can eliminate."
If there was a single thing I wish jar/war files had it'd be this - a "conf" standard folder. That way sysadmins could stay sane while managing a configuration that wasn't sourced from the build itself. Not all of us are running container middleware.
So Dare has, in trademark fashion, rubbed the OWF people up the wrong way.
At the end of the day, I've seen no good answer forthcoming on the substance, namely, why does the OWF need to exist? I can see why a group of likeminded people wanting to retain control of the overall social and technical direction of a spec would want to stay outside them - a bit like kicking off your own OSS project (though I draw no significance from the OWF being unveiled at OSCON). I've done some work in the IETF, JCP, and the W3C, and been on the edge
of OASIS. I think you absolutely have to have your act together going
into any of these organisations, technically and politically -
politically, because technology specifications aren't like OSS projects insofar as they have a strong economic slant - iow, someone's lunch is at stake. Maybe that's why the OWF exists, who knows. That said, I can't imagine why anyone would want to redo the process
and IPR stuff that is required of globally deployed technology; it's
critically important and absolutely no fun whatsoever.
I think I will blame the microformats and WHATWG crowds for this; they are communities that work insofar as producing useful web oriented specs go and have demonstated an actual alternative to the W3C. From a distance they make it look 'easy' to produce technology specs (except it's not). And there's a mild trend of important web work consciously not being done though the W3C - Atom, AtomPub, Microformats, OpenSocial, HTML5*, in conjunction with criticism of signficant work being done in there - RDF, WCAG2, WS, XHTML2. Maybe it's time for the W3C to look at the consortium aspect and address concerns about "openness", perhaps by having an auxilary to provide the kind of structure and governance that would not require something like the WHATWG to exist.
* fwiw, I know about the dual headed IP thing with the W3C
