Saturday February 03, 2007
Saturday February 03, 2007
What is Web 2.0 ?
So James recently tagged me (so the next time you read this, I'll have my five things for your enjoyment), but as I was putting some of those thoughts to virtual paper, the following was forwarded to me and I had to share.
Friday January 12, 2007
Open Source Ghetto
Mark Reinhold pointed the following out to me tonight ... I think it's a good idea, anyone else ?
Posted by brewin
Jan 12 2007, 05:53:17 AM PST
Permalink
Wednesday December 27, 2006
iPod Mania
Had to laugh ... this recent article on a new building in Dubai which will be designed to look like an ipod when done. Notwithstanding the fact that the entire building will lean at six degrees (it's on top of a simulated docking station), it just makes me wonder what's next ... perhaps next door the Bose building will be built (with a connecting tunnel of course) ...
Posted by brewin Dec 27 2006, 05:04:36 PM PST Permalink Comments [1]
Tuesday August 22, 2006
Web 2005
I read with interest the blog by Dion Hinchcliffe the other day who was commenting on a rather interesting item that may have gone unnoticed by some, and that was the removal of the phrase "Enterprise 2.0" in Wikipedia (and there was, of course, associated fallout).
Ummm .... wow ...
My first thought was along the lines of some of the posts I found online (generally along the lines of "how dare they!") but upon reflection while this may seem like censorship to some, the fact that the term was entered into Wikipedia, updated/edited and then deleted should be what the "writable web" is all about. What may be different about this (and what may cause the furor) is that what we're dealing with here isn't an additive property (more information) but a subtractive one (in this case the data seems to disappear)... and worse, a seemingly arbitrary one.
(Note: the system does work BTW ... nothing is really ever deleted, it just may not be visible ... and the history of the changes are available if you just take the trouble to look)
I looked through part of the debate on the topic in Wikipedia. Fundamentally, it seems that a Wikipedian editor made a decision that the term was not notable enough and did a speedy deletion based on a prior review of the term. What strikes me as funny is the same argument about being a "neologism of dubious utility" (advice to editors: be wary of the term 'dubious' ... its negative and subjective ... 'unproven' in this case might have been more appropriate) could have been applied to the term "Web 2.0" early in it's lifecycle ...
Why wasn't it, I wonder ? Is it that enough implementation existed within the "web 2.0" space by the time the first Wikipedia entry was created ? (and in case you are curious, that was February 28th, 2005). Or do we actually believe that "web 2.0" was really something new ? Probably, but it does raise the question of who gets to be judge, jury and executioner of what's real and what's not. (I note that the following theory is evidently real enough. Cool ...)
The general point then isn't in my mind that the term "Enterprise 2.0" isn't legitimate or real ... it's whether the name as applied means anything to the people who are building or using it. It's just a name. "Enterprise 2.0" is just as real as "Web 2.0" in that sense. That enterprise architecture and set of ideas (for example, SOA, SaaS, dynamic IT and "web 2.0 technologies") that collectively is called "Enterprise 2.0" should be enough.
It should be noted that I personally prefer the application of the characteristic here rather than a version number (a door is still a door, whether it locks, slides, swings, raises, opens one way or two ways). The underlying model arguably hasn't changed, it's more of how we're using it. The difference in this case is primarily at the endpoints or nodes of the web where (for instance) the server can interpret a much richer request. Whether it's the writeable web or read-write web, it's still the web. This sort of definition by characteristics or behavior to me is much more useful ...
That said, I'm not going to get hung up on the name ... common and accepted usage and practice will be enough for me to move forward ... for now ...
Darn marketing hype ... might as well borrow from commercial branding models and just call it "Web 2005" ...
Posted by brewin Aug 22 2006, 10:19:27 PM PDT Permalink
Tuesday August 15, 2006
Java and open source ... a quick note
Been very, very busy of late ... the most important is what's happened just in the last couple of days with an update regarding our open source activities for the Java platform. Cast around to find the various pieces of news from Rich Green, Laurie Tolson, Alan Brenner, Simon Phipps, Mark Reinhold, others and myself ... pretty good stuff. Yes, it's harder than most people think (as Geir notes in his blog) ... but it's worth it and things are proceeding. I'll provide more information about exactly what we talked about yesterday in my next post (probably tomorrow ... promise!)
Posted by brewin
Aug 15 2006, 09:07:54 PM PDT
Permalink
Thursday July 13, 2006
The disposable enterprise
Just an interesting observation ... Sun just announced a bunch of new boxes, one of my favorites being Thumper, a four-way x64 server with up to 24 terabytes of storage. Finally, something big enough to allow me to packrat just about everything ... :-)
Seriously, it's an interesting idea where by using next generation file system software like ZFS, you can treat everything you have as just one big volume ... and if a disk drive fails, no big deal ... it becomes the equivalent of a marked off bad cluster on the single drive in your PC. You don't worry about replacing the drive (that's down time), just have it fail in place and leave it there. At some point when you add additional storage and migrate that data off, perhaps then you'll replace it. Given MTBF that may be a while ... so you have what is in essence disposable storage ...
The way things are going, we're fast approaching (and already there in some cases) the point where the computing environment itself is just as replaceable ... if a node goes down, processing just shifts somewhere else. You don't bother to replace or repair that node ... at least not until the impact is felt on the grid, cluster or network that it belongs to. Sending in a repairman just introduces risk ... fail in place is the way to go.
In terms of software of course this means we need to design things differently. Locality shouldn't and can't matter and you see that in the nature of current and next generation software platforms and technologies, where resources (compute, data or otherwise) are allocated from system-wide pools rather than fixed-node ones.
Brings new meaning to the disposable razor (blade that is) ...
Posted by brewin Jul 13 2006, 01:28:41 PM PDT Permalink Comments [1]
Wednesday June 14, 2006
The real next wave ...
If you haven't heard, I have a new job ... one I share with Tim Marsland (Sun Fellow and Solaris Guru), and that is of the role of CTO for Sun Software. I'll describe what I do in my next post (Tim likes to say it's "everything that starts with 'J'" ... which is an oversimplification (but it will do). Right now I'm way too busy getting a handle on everything but I expect to be able to get back to blogging within about a week. Until then ...
Posted by brewin
Jun 14 2006, 08:40:30 PM PDT
Permalink
Thursday May 18, 2006
Hell Freezing Over
The title of this article should not be credited to me, but Mike Milinkovich from Eclipse in his blog entry about a contribution to the CVS sourcebase for Eclipse. Honestly, I can't defend the contribution (personal bias) and my only comment about the usefulness of SWT in the context of portability and compatibility is that this sort of change shouldn't be necessary to use Eclipse on Solaris/x86.
Swing works just fine thank you very much.
In my mind, it proves once again that SWT is the wrong solution.
So ... Milinkovich says they won't change the name ... but consider embracing the purity of the Java platform completely by dropping SWT and perhaps the gulf between tools like NetBeans and Eclipse won't be as wide. Posted by brewin May 18 2006, 03:31:13 PM PDT Permalink Comments [10]
Wednesday May 17, 2006
NetBeans Day 2006 and the Future of Tools
So on Monday, I attended the NetBeans Day conference, an all-day event that was held the day before the main JavaOne event. The NetBeans event was an absolutely fantastic experience as usual, with attendance over-capacity (I noted someone who appeared to be a fire marshall counting heads at one point) and a lot of developers who were there to learn about the latest in NetBeans technology as well as related information from Sun developer tools and partners.
I was on the ticket to close the initial keynote and introduce the tracks however because we started late, what was a 10 minute slot became a 1 minute slot (try at cram 7 slides into that!) and I had to go through my presentation (which I had down to a well-timed patter prior to the presentation BTW) about as rapidly as I have ever had to do (so I don't believe I communicated well everything that I felt I needed to). As I mentioned up-front to the audience, I would post (essentially) my presentation here so the full effect would be captured. So here we go ...
The Sun Tools portfolio
The Sun Tools portfolio currently consists of 5 primary tool products, one being NetBeans, one being an add-on "pack" and the remaining three products as Sun-branded "Studio" tools which were built on or using NetBeans technology (this distinction is important ... save it for later). Before I talk about where we are going, a discussion about where we are today will provide some context to understand where we're going.
NetBeans. The core (and most significant part) is NetBeans. This, of course, is the open source and community-supported application which consists of a robust RCP (Rich Client Platform) and a set of plug-ins which transform the platform into the rich and extensible IDE (and foundation for other IDEs) that is NetBeans.
Java Studio Enterprise. This product was originally designed to be the "enterprise" toolset for Sun and initially focused primarily on J2EE (yes, that's not a typo) and then web services development and deployment. As we have made the transition from J2EE to Java EE, much of the functionality necessary to do Java enterprise development has been shifted to NetBeans which has allowed the Studio Enterprise (I'll refer to it as JSE) team to focus on Service Oriented Architecture (SOA) development tools.
Java Studio Creator. This product has a special place in my heart reserved for it as this was a project I initiated, designed and architected (I have to admit, for the first release I was a bit of a dictator ... ask any of the old project team ... but it was worth it in the end). Creator ("Project Rave") was originally designed to meet the needs of the audience of developers who were either new to Java or needed to be able to easily and rapidly create rich web applications consuming existing data and services.
Sun Studio. Unique in that this product is the only non-Java IDE product from Sun, Sun Studio exists for the developers trying to build native (meaning C, C++ and Fortran) applications for Solaris and Linux.
NetBeans Mobility Pack. The Mobility Pack is not a stand-alone IDE in the same sense as the others. It is designed as an add-on to an existing IDE installation (NetBeans) and adds the features necessary for developers to create rich MIDP (and soon CDC) applications in the Java ME space. It includes both some of the same rich visual experiences you get with Creator but also adds the ability to leverage the Wireless Tool Kit (WTK) from Sun, including the use of rich emulators for various devices.
It should be noted (and note that this is historical data) that while all of the above were built using "on" NetBeans, they were built (exception: Mobility Pack) on NetBeans source (as opposed to being simply binary plug-ins on top of an existing NetBeans installation). The issue here is that as a result, frequently features which existed in one tool (ex: Creator) were not usable in another (ex: Enterprise or NetBeans). The end-result is a series of non-interoperable products (except at the generated source level) which (understandably) led to the "big question" that I (and others) get asked wherever we go an showcase the Sun developer products.
The "big question": Why all these tools ? Why not one ?
Historically, the answer is pretty simple. Last year, I (somewhat) covered our strategy and rationale in an earlier blog ... as our overall Sun strategy around open source and tools has now become more publicly available, I can elaborate a little (or a lot!) more on what we're doing and why.
There is value (to the customer, which is a primary imperative) to have tools which are tightly aligned and delivered with the deployment environment (in our example this would include things like the Java Enterprise System, Solaris and/or individual runtimes or platforms like Java SE, EE or ME. There is also value in delivering tools for specific audiences. NetBeans fits somewhere in between (we wanted to align with the needs of the Java community as well as an open source community). So NetBeans and the Forte/Studio tools served different audiences and different platforms/runtimes (NetBeans the "community" audience/platforms, the Forte/Studio products the "Sun" audience/platforms).
For good reason, we wanted to keep this new "open source IDE thing" at arms length, untainted by any Sun-specific initiatives or products ... in short we wanted to give this project a fighting chance as an open source IDE and make it attractive externally without any Sun bias (or even the perception of such baggage). As a result, while we did indeed build commercial products from the NetBeans source, it was a decidedly one-way street ... we used NetBeans technology as the foundation for our tools, but sharing was limited to either the assignment of Sun resources to the open source NetBeans project or very infrequent contributions to the community from our commercial products.
History has proved that these goals aren't mutually exclusive. Face it, there is little value in an IDE that you charge money for. And the value of creating and delivering open sources and standards far outweighs the value in any proprietary system. The commercial value isn't the tools themselves (or even the runtimes), it's the applications that run on them as well as the associated services.
We have reached an inflection point, both in terms of an understanding and realization of how the industry and economy of software systems works and as well one where the underlying technology is ready to adapt to the new model. It has taken 2-3 years of work within the NetBeans and Sun tools group to reach a point where a strategy I initiated to build on a common binary NetBeans foundation has reached the point where we can now reverse the order on how we build and deliver our software.
The new model
In the old days (and, in fact, what we're doing today), the model was that technology and products were delivered in closed source and periodically (rarely in the past, more frequently today) that code was donated to NetBeans. It started with such initiatives as the collaboration technology contribution in June of last year and a more recent example of that was what is known as the NetBeans Enterprise Pack. This is a collection of the technology present in Java Studio Enterprise (UML modeling tools, service orchestration tools, etc.) which was bundled as a "pack" (plug-able into a given installed NetBeans binary). With this pack, a NetBeans user now had access to technology which used to be only available to someone who used or paid for a copy of the JSE product.
As time goes on, more and more of what has historically been proprietary or "closed" source will be contributed to NetBeans. Recently, you've seen announcements to that effect for such technology as C/C++ development and the contribution of Creator technology (WYSIWYG designers for rich web application development).
This is only the beginning. The only real barrier to all of the Sun tools technology from becoming part of the general NetBeans technology base is logistical in nature (legal, coordination and usability/workflow model standardization). I would expect that by this time next year, the majority of all code will be completely shared... which leads to the next step ... reversing the order (instead of contributing to NetBeans from what was closed-source, proprietary code-bases, develop in open source and use that common code for point products use).
Once we have created this centralized "repository of development technology" which is NetBeans, when we need to create those custom point products (the need to have tightly aligned tools which ship with specific runtimes like Java Enterprise System hasn't gone away), we will instead pull what technology from the repository we need, brand it appropriately, test it rigorously with the deployment environment, perhaps add features specific to that runtime and ship it with that runtime.
As shown here, the process of delivering Java Studio Enterprise will now be a process more of one extracting the relevant bits from a common NetBeans technology repository (which is developed in open source) rather than delivering that technology into NetBeans at a later date (which likely over time would lead to more logistical nightmares since the code wasn't developed in concert with the NetBeans source). As before, this process would and will apply to the other products as well.
The interesting and powerful result here is that the technology now shared between all of these products is now re-useable in all of these products (where before it was impossible, for instance, to re-use a module from Creator in say, NetBeans). The advantage here will be, for instance, the ability to create custom environments for specific vertical applications or specialized needs (the example here is perhaps contrived, but I hope it makes the point).
Over the next month or so I hope to describe some of the specific plans and vision of how this strategy will be realized in terms of timing and roadmap.
Enjoy JavaOne!
Posted by brewin May 17 2006, 12:23:59 PM PDT Permalink
Monday May 08, 2006
Best intentions ...
So I had intended on following up my last post regarding the "next wave" with some discussion about Sun's tools and how they are evolving to solve some for the new architectures resulting from service-based technology and a new ecology. However, I wanted to follow-up instead on my last post as a result of questions posed by some who read it ...
One question dealt with whether the increase in bandwidth might change the granularity of the services and what the effect on productivity might be. Interestingly, it could go either way ... with greater bandwidth it would of course be possible to have many more finer-grained services, however it's my contention that standard engineering requirements and practices will prevail (greater bandwidth will enable a vastly larger number of service interconnects, but that doesn't necessarily mean that the services themselves will become finer-grained).
Essentially, I don't believe that the services themselves would be much different than how we build and deliver stand-alone apps and components today in terms of granularity. We build things at coarser levels of granularity for a reason: they are easier to deliver, test, manage and design (it's also typically a side-effect of the way we organize into development teams, etc.). The difference in these new components is the distributed nature of the applications they are used in ... someone else is providing some of our logic, some of services (from "somewhere"). We have to be able to handle that not only from a deployment/management viewpoint but the development/debugging/profiling one as well.
A separate question was how the services industry will evolve. There are (at least) two models which exist (or will exist) ... the first is the "legacy" folks like SAP who take their large systems and wrap it up as a collection of larger services (what's behind, for instance, NetWeaver / ESA and the delivery of "enterprise services") ... this, of course, is happening today as companies with existing infrastructure migrate to more loosely coupled systems. The second model I believe will be that of service aggregators (as a business).
Beyond the apps-to-be-services today, we will likely first see a massive explosion of smaller services for various functions, but over time things will coalesce around larger service providers (example: travel reservations system, financial support system or supply-chain management) who perform a function of aggregating smaller services and providing the management, risk mitigation ... most of the "ilities" for the apps, consumers or heck, other services which consume them. It will lead to an interesting new business model for the new "Dot Coms" as they take on the task of providing meta-services (and likely by in turn building upon things like the Sun Grid ... why pay for all of that infrastructure yourself when it exists at a low cost-per-hour for use by you and your customer ... ) ... anyone think this could be an interesting new business ?
The short answer here is that it will be rare that someone would build a large application of hundreds of services ... there will typically be a "food chain" of increasingly coarser services that applications higher up the chain will build on.
Existing SOA tools working with services (regardless of granularity) will improve productivity (we are visual creatures by nature ... working at the XML level is, to say the least ... painful), but we still need more in this space. While we do still need additional construction / visualization tools (to work at different levels of abstraction or use-case), productivity isn't just about the "building" side of development ... the whole life cycle needs to be addressed as well (which includes, obviously, deployment, debugging, profiling, maintenance, etc.). Coarser services should help somewhat (less to manage), but there is still a lot missing in terms of infrastructure, architecture, blueprints, best-practices, runtimes (and yes tools). The good news is that we (Sun) are thinking about it and in an upcoming blog I'll describe what we're currently doing as well as where I see things moving in the future.
Next week, of course, is Java One, which will be an ideal time to describe the development landscape and the tools needed for them. So until then, keep looking forward ...
Posted by brewin May 08 2006, 06:08:08 PM PDT Permalink
Thursday March 30, 2006
The next wave of Software - Moore meets Metcalf meets Rock (and don't forget Gilder)
One of the discussions I've been having and ideas I've been promoting as I've traveled around doing various talks at conferences, customer site and universities (this week in Australia / New Zealand) is the notion that we are rapidly approaching an inflection point ... one that has significant repercussions for those of us building and maintaining software in the industry today.
Background
In these discussions, I've been using what were previously considered as hardware-only "laws" and applying the principles behind them to software development. As a refresher, the laws in question are the following:
- Moore's Law - an observation related to chip complexity and unit cost, the essence of which for this conversation is that the number of transistors we can cram onto a piece of silicon is roughly doubling every 24 months. Another way of looking at this is, of course, complexity
- Rock's Law - an observation on what it takes to manufacture those chips. Consider it the economic corollary to Moore's Law and it states that the cost of building those chips doubles every 4 years. As the chips become denser and more complex, the cost of building a new fab plant to manufacture them (as well as all the services including R&D around them) is going up
- Metcalf's Law - this law states that the value of a network is equal to the square of the number of nodes on the network. Simplistic example: if you have one phone, it's value is limited. Add a second (now you can call that other phone), the value of what is now a phone system goes up. Add a third (and so on), the value increases exponentially
One reason for the move towards clusters of lower-cost chips is the recognition and application of these laws as applied to hardware design and the systems built from them. From an economic sense, at some point it makes more sense to not build denser (and more costly) Big Hunks of Silicon(tm), but instead create clusters or networks of lower-cost chips which provide the same functionality but at a lower cost. Although Metcalf was really talking about networks, I believe the same applies when looking at these networks-in-the-small, that is that the value of those compute systems increase to the square of the number of nodes in that network
- Gilder's Law - this law states that bandwidth (the "size of the pipe") triples every 12 months. The implication is that connecting all those systems becomes even more possible and reasonable as the bandwidth goes up (and as a result of Metcalf's law, the value of the network goes up even further as the network can now scale to sizes unachievable before)
Hardware "laws" applied to Software
- Moore (complexity) - At the coarsest level, the number of components and/or services in any given application or software system is increasing year over year (unlike hardware though it's much higher than double ... the creation and use of components and services in software is inherently easier than in hardware). For the sake of argument I'm assuming that at a minimum, that number is squared (so the number of services or components available in a given software system will exponentially increase)
- Metcalf (value) - Like hardware, the value of the application or system will increase by the square of the number of services or components in the system
- Rock (cost) - The cost of building the network of services (not the services themselves ... we have a pretty good handle on that) goes up as the scale of those service-based systems increases. Simply put, it's taking a larger effort in terms of resources and time to build, deploy and manage larger and larger scale software systems
- Gilder (bandwidth) - As the bandwidth increases, this increases the number of service connections we can allow for in our software systems thus resulting in larger (and more complex) service-based applications.
The evolution of software systems and their complexity
As the software development industry has evolved, we've gradually moved from what were mostly monolithic systems built using structured programming languages (Fortran, Cobol, etc.) to mainstream applications built from collections of objects. These object-oriented systems drove not only OO methodologies and architecture but promoted component re-use ... something which wasn't used as extensively in the Days of Structure (sounds like a movie title ... )
Beyond objects (yes, all you Smalltalk folks will bring up the fact that you were already sending messages ... no offense, but I believe we're moving beyond that here), we are now moving into service-based systems of a scale unheard of in the past. It's not so much the presence of services but rather the complexity which results from the aggregation of these services from sources which frequently exist outside the firewall rather than from within it as with most stand-alone software today. The result is an explosion of services and connections to services scattered across the globe:
So services result in a geometric change in complexity ... obviously at runtime (and there are loads of folks who are building out the enterprise infrastructure to support them) but also at development and maintenance time. Without change, the scale to which these apps can grow is limited (assuming you don't want to live with the consequences of scaling quality and risk aversion as well). Building what I like to think of these new hyper-scaled systems will require a constant evolution of not only the runtime platforms they run on, but the development tools which build and maintain them.
Another interesting analogy between H/W and S/W here is how we at Sun have looked at improving the network, computing and the data center by paying close attention to three principle areas: Availability, Reliability and Scalability. The terms are pretty self-explanatory ... for software:
- Scalability - How big can I scale my system ... and it's no longer just a monolithic application ... who remembers the below chart ? These "applications" (that term needs to be replaced ... I believe applications are now passe´ ... they are services in their own right ) will be BIG ... including everything from "standard applications" to phones, your toaster, RFID tags you name it ...
- Reliability - Can I trust the services I'm using ? Remember, you don't own them ... so the presence of Identity systems, credentials and security are crucial
- Availability - I'm building an app that is dependent upon some service coming from "somewhere" ... will it be there when I need it ? What kind of guarantee do I have that it's a service I can depend on ?
All of this is going to require a new generation of development platforms (that's runtimes and tools) than exist today ... if you look at today's tools, they are actually designed for yesterday's problems (they are designed to primarily solve the structured and object-oriented languages and applications ... we can partially manage new service-based systems with them but fairly quickly now we will exceed their capacity to deal with them).
At the high level some of the changes required to both improve the ease-of-development experience in modern applications as well as to deal with increased complexity can be captured in the following:
- Languages and platforms. Extend the capabilities of the languages and platforms such that they enable easier (and less risky) development practices. The changes made in the last few years in the Java platform are prime examples of that type of improvement. For example, the use of annotations to allow for more declarative programming as well as removing the requirement for explicit specification of complicated metadata that previously had to be hand-coded. This (obviously) simplifies development but also reduces the risk for silent errors in code that have to be dealt with upon deployment and maintenance. Similarly, other changes like the addition of enumerations and other language features to the Java language reduce risk and improve the development experience
- Deep knowledge. Use the deep knowledge available to compilation, tools and runtime environments to improve the reliability of applications running on the platforms and networks. For instance, inversion-of-control changes in Java EE 5 (by this I mean letting the container do what work it can for you so you don't have to) will greatly increase the reliability and ease the development process (look, for instance, at the advantages that a system that manages persistence for you can do)
- Adaptive environments. Different tasks require different tools. Different users are using those tools. Depending on the task or the audience (or both), the tools should adapt accordingly. The simplest example ... if I'm building a web service, why do I need the GUI design tools at my fingertips ? They clutter my desktop and detract from the user and development experience. Which leads me to the next point ...
- Abstraction. As part of adaptation, use abstractions to allow for highly effective visual and non-visual modeling and development during the process of building, deploying and maintaining services and systems of services / applications. For example, while working against the same common model (my code), I should be able to work within:
A specifications view
A graphical programming view
A pattern view
A UML view
A code view
A packaging / assembly view
A business process model view
And so on ...
The general alignment with adaptation is not only should my tool adapt to my task or type of developer/development, it should provide the optimum view of what is under development at a given time ... if it's most efficient to "code" using a UML model at a specific instance in time, do so ... if I'm modeling the process, use a business process tool ... if I need to get my hands dirty let me at the code.
- Development Process. Lastly, encompass the entire development process (not just compile-edit-debug). This means, at least in part, Application Lifecycle Management (ALM). Being able to build services and systems of services using well-established processes (and pick your methodology ... which one isn't important, only that you have one) which go from requirements, to specifications and all the way to end-of-life are crucial as the ability to deliver predictability in both the development process and the end-result is a must when systems go hyper-scaled ... the results of not building these highly-scalable, highly-reliable and highly-available software systems properly will be extraordinarily expensive to fix once deployment begins.
Next time I'll "go product" (or at least "go technology") and talk a little bit about how we (Sun) are working on the next phase of "attacking complexity" within the development platform space. I would, of course, be interested in observations, criticism and real-world stories where building to the next generation system have caused a new way of looking at the computing world. Posted by brewin Mar 30 2006, 02:04:42 AM PST Permalink
Tuesday March 28, 2006
On the road down under
I'm on the road again, this time "down under" ... visiting Sydney, Melbourne Australia and currently in Wellington New Zealand. So far, it's been rather exciting as I've been meeting a number of developers who have certainly not been shy in coming to talk to me about technologies, Java and sometimes problems they are trying to solve (and wondering what Suns' position or plans are in areas which are causing them pain). This is great stuff ... one of the reasons I really love going on the road is that I learn more in a couple days on the road meeting real live customers than I do at home because these folks are solving real-world problems which I can then take back into Sun as feedback.
Getting here was a bit of a problem as (if you haven't heard about the weather) as there a number of cyclones in the area which are causing air traffic problems in areas such as north-east Australia and here in New Zealand ... I'll leave that story for another time.
After my keynote here in Sydney Brad Perriott, one of the local Sun folks, picked my up by car and took me to one of his favorite local breaks near the town of Mona Vale near Sydney.
When we arrive, the weather was warm, there was almost no one out in the water (which was around 22C) and the waves were around 2M and clean ... we surfed for what seemed like days and at the end of the day we couldn't raise our hands over our heads because our shoulders were on fire ... good thing beers don't have to get hoisted that high.
.....
OK ... not really ... (over a beer at the end of our surf session, I thought about exagerating the truth a bit, but after reflecting last night I figured that anyone who was a real surfer would have just checked one of the local surf sites and realized I was pulling their legs ... sorry Brad ... couldn't go through with the "fish story" :-) )
Everything was as above, but the waves were about 1M and mushy ... so much for the epic cyclone-driven waves but it was still a lot of fun ... I've surfed in various places in the U.S., Costa Rica, Nicaragua, Hawaii, Mexico, etc. ... never Australia (so this was a real kick). One thing to be said for the folks here in Australia is that there is a real sense of "stoke" related to surfing and pretty much everyone I've met is easy-going, nice and I didn't get any feeling of the kind of local-ism that you get at some other places like Hawaii and some breaks in California.
Here's some thanks to Brad and team for allowing me the opportunity to sample some great Australian waves and hospitality ... this weekend I'm off to go wake boarding on one of the local rivers here (and I'll let you know how that went) Posted by brewin Mar 28 2006, 11:39:18 PM PST Permalink
Monday March 06, 2006
What's in the old quiver ...
Couple of folks asked me what boards I surf on ...
Well ... I have a bunch (eight in my garage right now) ... but as with anything else, it feels like I could always have more :-)
I think my three favorite boards are:
- A 9-0 Yater longboard (unfortunately, it belongs to my wife and I rarely get to ride it )
- A 9-6 Gerry Lopez "Noserider" ... amazingly good board on bigger (steeper) waves ... probably has something to do with a certain Banzai Pipeline influence
- An 8-2 Rusty "I'm-not-sure-what-it-is" board. It's not really a funboard as it's shaped like a thruster (but bigger). Perhaps more in the category of a "Big Guy Tri" (which makes sense given my size). Nice thing is that it floats me fairly well yet given my size (I'm 6'-7" and weigh around 235) I can whip that thing around as easily as the young guns can on their little Merricks)
The land of OZ
As mentioned the last time here, I'm heading to Australia and New Zealand at the end of the month for the Developer Days conference being put on down under.
The Sun Developer Days take place over 3 consecutive days. The first day is a half day on Solaris and the rest of the event occurs on the following days in the same location. Obviously, check the site regularly for any updates (after you register of course :-)
Wellington
| Monday 27th March BONUS Solaris Half Day in the morning. Tuesday 28th - Wednesday 29th March Sun Developer Days Conference. |
Location: Copthorne Hotel, Wellington Corner Glimmer Terrace and Boulcott Street Wellington |
Sydney
| Wednesday 29th March BONUS Solaris Half Day in the morning. Thursday 30th - Friday 31st March Sun Developer Days Conference. |
Location: Willoughby Civic Centre 409 Victoria Ave, Chatswood |
Melbourne
| Tuesday 4th April BONUS Solaris Half Day in the morning. Wednesday 5th - Thursday 6th April Sun Developer Days Conference. |
Location: Rydges Melbourne 186 Exhibition Street Melbourne |
So I'll look for you down under ... and yes, of course I'm bringing a surfboard with me ...
Posted by brewin Mar 06 2006, 10:59:59 AM PST Permalink
Sunday February 26, 2006
Back at the Ranch
Just came back from vacation (North Shore of O'ahu). Rained pretty much the entire time I was there but the surf (of course) never stopped and my wife and I had a pretty nice time. For those familiar with the breaks, we spent most of our time at Haleiwa, Puena Point and Chun's Reef (our personal favorite).