Webcenter Interaction Blogs (aka Aqualogic Interaction)

1. Jailbreak it
   use PWNageTool on Mac or QuickPWN on Windows, recommend using Cydia as package management tool, for more info, google please.
2. OpenSSH installed and service started
   Use Cydia to install, search openssh package. ATP will take care of the installation and dependencies. In addition, I strongly recommend that we install Terminal/Finder/BossPrefs/SBSettings.
   
3. Download the dictionaries you want in any language
   http://stardict.sourceforge.net/Dictionaries.php
4. iPhone connected to the same wireless network as you Desktop/Laptop
   Get the LAN IP address, we need to use SSH.
5. Any SSH tool
   Cyberduck or FileZilla for OS X
   Filezilla for Linux
   WinSCP/Filezilla for Windows
   

If you don't like the dict name, you can double tap on the name and change it to whatever you like. If for some reason they are not listed, check the prefix for the dictionary file, make sure they are the same. Hold Home for 6 seconds to force exit the app, check again, it should work.

You know, it's funny how some things can seem extremely complicated and then when you crack them open they turn out to be fairly easy to understand. Remember the mystery behind how a G.I. Joe stayed together, but then you broke one and found it was simply a rubber band holding his guts together? Turns out search server is much like that. A terribly complicated-seeming C program that, fundamentally, is held together by a rubber band.

What is a Search Node?

From my previous posts, you've probably inferred that search nodes are the fundamental building blocks of ALUI's search capability. In fact, search nodes are actually the *only* building blocks of the search capability. Everything you need to set up a clustered or non-clustered search environment is contained in one simple install, a few directories and an executable.

All this seemingly complicated system amounts to is the following breakdown:

1. An executable running somewhere listening for requests
2. An open TCP port that receives text based search queries
3. Two directories that contain everything search needs to operate: a cluster directory and a node directory.

Here's a more complicated picture of what I just listed:

Figure 1 - Search Node Architecture

Search Requests

Let's start with the executable. When you start it up using the command line (from the bin directory in a *nix environment, or via a service on Windows), it uses environment variables to find its various configuration files, starts up a process, opens a TCP socket on whatever port you tell it to, and sits around waiting for stuff to happen.

The "stuff that happens" turns out to also be fairly simple. Search server doesn't actually know anything about portals, documents or anything else for that matter. It sits around and waits for one of two things:

• An index request (put some information into the search index so it can be searched for later)
• A search request (search for something in the current index)

These two things are specified in a text-based custom language over a TCP port. What I mean is that you, Joe Six-pack, could open up a telnet session to your search server port and type a search query (index or request) freehand, were you so inclined. You would type something like the following:

( FIELDALIAS ptsearch,[2]PT1,[2]PT1_en,[0.1]PT2,[0.1]PT2_en,[0.1]PT50 ) (((ptsearch:a) TAG phraseQ OR (ptsearch:a*) TAG nearQ) AND ((subtype:"PTCARD")[0])) AND ((((@type:"PTPORTAL")[0]) OR ((@type:"PTCONTENTTEMPLATE")[0])) AND (((ptacl:"u2") OR (ptacl:"51"))[0]) AND (((ptfacl:"u2") OR (ptfacl:"51"))[0])) 

METRIC logtf [1] RESULTS 10 PRINT FIELDS parentids,ptacl,ptfacl,PT51,PT56,@type,subtype,ancestors,PT58,PT7,PT53,abstracttype,

PT1,PT1_en,PT2,PT2_en,PT3,PT4,PT5,PT6,PT8,collab_properties,collab_project_url,collab_project_name,collab_icon_alttext_index,collab_acl,publisheduser,portletid TERMS 10000 results[1-10] KWIC 15

Obviously, this kind of a query isn't very pretty or intuitive, but the point is you could type it via telnet and search server would spit out an XML formatted response to your query. You can see these types of queries in your search node logs if you set your logging levels high enough. Lucky for you, the search API takes care of all of this heavy lifting and converts those XML results into the pretty HTML you see when you perform a search in the portal.

Building a Search Index

"Okay Ross," you're probably thinking, "I can run search queries over telnet to see what's in my search index. That's all well and good, but how does all that junk get in the index in the first place?"

How indeed. As I mentioned above, that junk gets in there via an index request, which is much like a search request (runs over a TCP port, follows a specific querying language), but allows whoever or whatever to put information into search instead of extract it.

If you look closely at your Publisher content.properties file, Collaboration config.xml file or even at the portal database (PTSERVERCONFIG table), you will see an "Indexing Search Port" and "Indexing Search Host" specified. What these values really do is tell each product (Portal, Publisher, Collaboration) where to submit their new document data (i.e. when someone publishes something, uploads something to a project, or a crawler runs). That data is submitted over the same TCP port to the same type of node that handles queries.

How an Indexing Request Works

Here's a brief explanation followed by a couple of pictures:

1. An index request is submitted to a search node. Since that search node may be part of a multi-node cluster, the request goes straight to the cluster file system (remember, all nodes share this directory).
2. The request is assigned a transaction ID and added to a queue on the cluster (you can see this in the form of the requests folder in the cluster folder of your search node).
3. Every search node in the cluster independently maintains its own transaction ID, which corresponds to the last index request it processed. These nodes continually poll the shared requests folder. If they find a transaction that has a higher ID than the one they maintain, they pull the information for that transaction and add it to their local search index. They then update their local transaction ID to match the transaction they just processed.

You can actually see this process in real time by amping up your search logs and watching the transaction ID's increment when you upload a collab document, create and admin object, etc.. Here's a few Powerpoint diagrams I created of this process:

Figure 2 - Adding an index request to the cluster's transaction queue.

Figure 3 - Updating a local search index from the transaction queue.

Conclusion

As far as node operation goes, that should clear up most of the mystery. At this point, you should understand most of the how's and why's of search operation. The last piece to this puzzle is the "checkpoint" feature, which I'll review in the final exciting chapter of this blog series.

Howdy all.  With the holiday season upon us and everyone getting inundated with offers of bargain flat screen TVs at your favorite big box store and 10 spatulas for the price of 9 down at Spatula City, your friends at Function1 hope you'll save some of your hard-earned budget with this cost-saving tip:  Make your software purchases at the end of a vendor's fiscal quarter.

Here's a not-so-well-kept secret about the software business: software and maintenance is a high-margin business for vendors.  This means that there is no list price on that shiny new piece of software X that you're thinking of buying..."list price" is just a starting point for negotiating, alot like the tag in the window of a used car.  What's more, most software sales folks have a sales target each and every quarter.  The difference to a salesman between beating and missing their quarterly number is pretty significant.  Beat their number and they:

• Likely get a trip on the company to some exotic resort where they sip on delicious fruity drinks.
• Buy that new convertible weekend car that they've been eying.

Miss their number and they can expect:

• Lot's of yelling from angry VPs
• Lot's of meetings and "planning sessions" with aforementioned VPs on how they're going to make their number next quarter
• Perhaps start looking for a new job

The upshot here is that, come end of the quarter, if a vendor isn't meeting their financial targets, it's firesale time.  In short, you have leverage to negotiate a much better price for your software.  Say, for instance, you've received a quote to buy a site license for some software at $500K + 20% annual maintenance.  Let's also say that, come end of the quarter, your favorite salesman is $300K short of meeting his sales target.  Let's also say that the economy is currently in the toilet, and the vendor you're working with is in danger of missing the financial target they've given to Wall Street.  All these factors add up to a perfect storm of you saving a bunch of cash.  If you're not afraid to say, "No" to a price, there's a good chance you get the $500K software for $300K...if you buy before the end of the quarter.  So, not only have you saved $200K from your budget immediately, but you're also realizing an annual maintenance savings of $40K...that's real money.  Money you can use to:

• Take your team on a trip to some exotic resort where you sip on delicious fruity drinks.
• Throw a kick-ass holiday party
• Hire your favorite consultants at Function1 to give you a hand in getting the most out of your new software purchase

That's about all for now.  Hope you find this tip helpful, and that it saves your some $$$.  If you're really in the holiday spirit, feel free to send us a check for 10% of any money you save :)

Function1 is a growing company, but not too big that we can't take a minute out of our regular blog routine to welcome our two newest team members, Sandeep Khaneja and Hani Atalla.

Hani and Sandeep have actually been with us for several months, so my apologies for the late public welcome, but we're thrilled to welcome them to the team and have them work with our clients delivering elite AquaLogic consulting and product expertise!

Sandeep is a Plumtree/BEA Alumni with years of experience helping clients like yourselves realize their vision of a best-of-class end-user focused portal, with a special focus on strategic business planning, health checks, and technical optimization of the rest of the AquaLogic product stack.

Hani is a multi-year ALUI consulting veteran with a solid Java and .NET application development background for ALUI clients, and has been instumental in developing Watcher, our newest product - an ALUI monitoring an alerting application.

Welcome guys!

OK, now that you had your dinner and ate your meat, it's time for the pudding.  This conclusion to Stack Wars just ties up a few loose ends and walks through a "real-world" example of analyzing stack traces.  Have fun...

Making Thread dumps easier to view

Seeing as how most people's idea of a good time isn't sifting through pages upon pages of JVM stack traces, several good people have developed tools that make it easier to view and analyze complex thread dumps. Personally, I like and use the IBM Alphaworks Thread and Monitor Dump Analyzer. Pretty straight forward to use. Just save your thread dump off to a file and open it up in the Analyzer for a pretty view of all your threads that looks like this:

I've found this tool useful when I'm trying to look for patterns across many threads in a thread dump. Give it a try, you might like it.

A real world example of how all the rambling I've just gone through came in handy

Long ago, in a galaxy far, far away, I was working on a Plumtree consulting project with a large company. These folks had been having problems with their portal deployment. Periodically, the portal would start eating up 100% of the server CPU, and would never release it until the portal application server was bounced. During the time that the server CPU was pegged, users couldn't access the portal...the customer was not happy. It was one of those big deals where VP-level people at the customer were yelling at VP/Executive level people at Plumtree on a daily basis. So here I am in this high stress situation. I arrive onsite with the customer and, for three days, nothing happens. The application doesn't freak out, and all is fine. At this point, I'm starting to get cautiously optimistic that maybe we won't see any problems during my remaining two days onsite, and somebody else will have to deal with the problem later :) But, alas, it wasn't to be. About halfway through my second to last day with the customer everything went to hell. All of a sudden nobody could access the portal, so we start debugging. Sure enough, first thing we see is that the portal process is eating up 100% of the server CPU. These folks were running on a Unix platform, so I ask them to try:

kill -QUIT <portal pid>

After explaining for 20 minutes that, no, this command won't kill the process, the server ops folks generated a thread dump and sent it over to review. After about 5 minutes of looking at the portal thread dump, it was pretty obvious that something was amiss with the portal code. The stack trace for EVERY SINGLE THREAD (All 100 or so of them) was exactly the same. They were all stuck running the same native method. Just to be sure this wasn't some freak anomaly, we generated another thread dump 15 minutes later, and, yep, all the stack traces looked the same. So this tells us that there's a problem with some native C code being used by the application...a good start. Unfortunately, since the problem was in native code, we couldn't get a full stack trace from the JVM...it only goes so far as to let you know that it's making a native call. So we dig one level deeper and trace the portal process. Running a trace/truss on a Unix process spits out all the system level calls that are being made. Wouldn't you know it, when we looked at the trace output, 99% of the calls being made were:

poll(0)

Now, I wasn't an expert at interpreting this level of data, but I knew enough that "poll" had something to do with sockets, and that there definitely shouldn't be so many of those calls. Long story a little bit shorter, after a bunch of conference calls with Plumtree support and engineering, where we shared the data we'd gathered from the thread dumps and process traces, the engineering team found a very low level bug in the software and shipped a fix out to the customer...tragedy narrowly averted.

Conclusion

Did you really make it this far? If so, thanks for sticking with me, and I hope you found something of use in this long, winding post.  If you're ever stuck trying to make sense of a thread dump, feel free to drop us a line or post a comment here...we'll do our best to help.

Take care, and remember, when dealing with production troubleshooting, "Do...or do not, there is no try". (This doesn't have really have much to do with the post, but I'm kind of tired and pulling at straws for good ways to tie the Star Wars metaphor back in). Anyhow, as always, thanks for reading...see you next time.

READER BEWARE: This got long and geeky, so make sure you're really trying to avoid doing "real work" before you sit down to read.

Welcome back all, and thanks for joining me for the final installment of a three part series on decompiling Java code and analyzing stack traces. If you're interested in the back story, you can read about decompiling Java here, and analyzing basic stack traces here.

When we last left off, our hero was frozen in a block of Carbonite and left to his doom. Err...sorry, wrong story, let me start again.

When we last left off, we walked through analyzing a simple stack trace to run down a bug in a standalone Java program. This is all fine and good, but what happens when you're running a Java application server (like Tomcat or Weblogic) that has hundreds of concurrent threads running tens of different web apps? And you're just trying to figure out why your particular web application is hung?

Well, if you're lucky, the developer of your web application was a good boy/girl, and they're logging stack traces for you in a log file somewhere. If this is the case, then you can open up the log and analyze the trace like we did the last go round.

Often times though, you're not so lucky, and you have to dig a little deeper to figure out what's going on. Say, for instance, your web application just starts responding very slowly. You see from access logs that responses are being served back to users, but they're about 5 times slower than normal...WTF? Or, what if your application server starts pegging the box at 100% CPU...what to do? Or, out of nowhere, your app server starts throwing Java.lang.OutOfMemory exceptions...Gah!!! Sadly, these nebulous problems seem to happen in a production environment more often than most of us would like to admit. And when they do occur, it's usually a high stress situation because there's probably a production outage and nobody really knows why. So, how do we find a better fix to the problem than the traditional, "Let's just bounce it and see what happens" response? Why, we use "The Force", of course. Except in this case, "The Force", is just a set of debugging tips that I'm getting ready to share with you as follows:

1. Take a deep breath and don't freak out when a bunch of people start yelling.
2. Understand the severity of the situation. Figure out how much downtime you can tolerate for debugging before things really hit the fan.
3. Set expectations. Let people know when they can expect the issue to be fixed. If you know a bounce will temporarily fix the problem, then set a drop-dead time for debugging and schedule a bounce. Let folks know that if you don't find a root-cause of the problem, that they should expect to see the issue again.
4. Gather as much information about the problem as you can. What, specifically, are users experiencing? Can you reproduce? What are the symptoms? What log messages do you have? What does the server environment look like? etc.
5. Try to relate this issue to something you've seen in the past. Does this look like a problem you saw last week or last month? What did you do to fix it then? Why is it popping up again now?
6. Eliminate possible external causes. Is this actually a network problem in disguise? Is the database acting up? Is some other process on the server eating up CPU? Is the server constantly swapping because it doesn't have enough RAM to handle all its business?
7. Eliminate environment changes as possible causes. Has the server environment changed recently? Could this be causing your problem?
8. Look in earnest at your application server process. Are we bumping up against the Java max. heap size? Are we seeing lots of garbage collection? Is our thread pool exhausted? Is our JDBC pool maxed out?
9. Take a look inside of the application server JVM. Generate a thread dump to get a snapshot of how your application server is behaving. Analyze the stack traces in the thread dump, and look for points of interest, like...race conditions, stuck threads, deadlock, etc.
10. Open a ticket with the software vendor (If applicable)
11. Pray the issue fixes itself and doesn't come back
12. Find a new job so you don't have to deal with these problems anymore

Read on for more fascinating details about The Stack Trace...

Most of the time, creating a remote portlet application using the standard IDK is enough. Indeed, commonly, you just need to access user profile information, portlet ID, page ID etc... or perform simple operations exposed by the IDK PRC API.

But if you hit the limits of the IDK, it is not the end of the road. In the ALUI/Webcenter development documentation, they explain how to perform various UI customizations such as view replacement, PEI development, Activity Spaces creation or extensions, etc... All these are created within the portal application itself...Another option is to create what I call a "Native API Portlet Application". As its name indicates, this portlet application accesses directly the portal API and can perform virtually any operation that the portal can do...very powerful (but non supported :) so make sure your application is well written so that you can change the portal API access layer easily if you upgrade the portal version for example)

First, the 2 main requirements in order to create a Native API application are:

• The application needs to be on the same server as Portal, or Automation, or API service
• The application needs to reference various portal DLLs (located in /ptportal/6.1/bin/assemblies for dotnet, or /ptportal/6.1/lib/java for java). You don’t need them all. Here is the minimum list:
  
  
  
  ptportal\6.1MP1\bin\assemblies\opencache.dll
  
  ptportal\6.1MP1\bin\assemblies\openconfig.dll
  
  ptportal\6.1MP1\bin\assemblies\opencounters.dll
  
  ptportal\6.1MP1\bin\assemblies\openfoundation.dll
  
  ptportal\6.1MP1\bin\assemblies\openhttp.dll
  
  ptportal\6.1MP1\bin\assemblies\openkernel.dll
  
  ptportal\6.1MP1\bin\assemblies\openkernelsearch.dll
  
  ptportal\6.1MP1\bin\assemblies\openkernelsearchimpl.dll
  
  ptportal\6.1MP1\bin\assemblies\openlog-framework.dll
  
  ptportal\6.1MP1\bin\assemblies\openprocman.dll
  
  ptportal\6.1MP1\bin\assemblies\opensharedcache.dll
  
  ptportal\6.1MP1\bin\assemblies\opentempfile.dll
  
  ptportal\6.1MP1\bin\assemblies\openusage.dll
  
  ptportal\6.1MP1\bin\assemblies\openusage-api.dll
  
  ptportal\6.1MP1\bin\assemblies\openusage-impl.dll
  
  ptportal\6.1MP1\bin\assemblies\plumtreeserver.dll
  
  ptportal\6.1MP1\bin\assemblies\portal.dll
  
  ptportal\6.1MP1\bin\assemblies\pthome.dll
  
  ptportal\6.1MP1\bin\assemblies\ptportalobjects.dll

Important note: It is perfectly allowed to also include the IDK Dlls here too... and I find it particularly recommended if you are writing a native API portlet (for instance getting the current login token for example is fairly easy using the IDK API)

Second, you need to create the native session (everything starts from here, really):

1: String strServerConfigDir = ConfigPathResolver.GetOpenConfigPath(); 

2: IOKContext configContext = OKConfigFactory.createInstance(strServerConfigDir,"portal");

3: PortalObjectsFactory.Init(configContext);

4: IPTSession ptsession = PortalObjectsFactory.CreateSession();

To connect, 2 main options:

• Use the login token that you can simply get from the IDK API (that is prefered option if you can)

1: String loginToken = m_portletRequest.GetLoginToken(); //IDK call

2: ptsession.Reconnect(loginToken);

• Use explicit Username (or user ID) / Password to connect.
  

1: String username = "myusername";

2: String pwd = "mypassword";

3: ptsession.Connect(username, pwd, null);

Third (and Final), you access the right ObjectManager Class depending on which type of portal object you want to interact with.

When the session is created (that was pretty easy, right?), that is when you can actually start interacting with the portal internals...and a majority of actions goes through the PTObjectManager objects (IPTObjectManager interface). For instance:

1: IPTCommunityManager ptCommManager = ptSession.GetCommunities(); //for community objects

2: IPTPageManager ptPageManager = ptSession.GetPages(); //for community page objects

3: IPTObjectManager ptGadgetManager = ptSession.GetGadgets(); //for portlet objects

4: //etc...

You noticed that for portlets, there is not a IPTGadgetManager insterface....that’s ok as all the "Manager" interfaces are children of the base IPTObjectManager interface.

Although the vast majority of manager objects are accessible through a direct ptsession.Get() call, you can also get the right manager using the generic call below (using the classID of the object type you want)

1: IPTObjectManager ptCrawlerManager = ptSession.GetObjectManagers(PT_CLASSIDS.PT_CRAWLER_ID); 

2: //using     the class id of the object type you want

1: ptObjectManager.Open(objectid, lockObject);

With this call, you get directly access a particular object in the portal, and interact with it as if you were in the UI

In the next article, I will show you how I package these API call in a standalone library to minimize as much as possible any API call within the presentation layer code...

It's been a while since we touched on AJAX, but a question came up recently about it an I thought it might be good to review. AJAX, or "Asynchronous JavaScript and XML", is a way for portlet developers to create rich Web Applications that don't require the entire browser page to refresh to update content.  This is done by making asynchronous calls to the server and updating content within the page itself.  With the AquaLogic portal, this means that portlets can dynamically update content in <div> tags by requesting new content without having to refresh the entire page (and other portlets on the page).  It's a pretty simple concept; in many cases you can accomplish this without having to even change any code - you can just specify "inline refresh" on the Web Service and the portal will automatically rewrite the HTML links on the page to make AJAX calls:

The HTML rewrites cause the browser to make the HTTP request "behind the scenes", and when a response comes back, the portal refreshes the content inside the portlet <div> tag.

But there are some things to know about this AJAX stuff, so here are a couple of refresher points about AJAX:

1) The response to an AJAX request is basically just a text string to a browser, and it's up to your JavaScript to interpret it.  Often you do something like:

document.getElementById("responseDivTag").innerHTML = response.getResponse();

... to refresh content.  But note that this doesn't tell the browser to "process" the response - specifically, JavaScript that comes back in the response won't run, because all we're doing is setting the HTML to a string that comes back from the server.  In order to run JavaScript in the response, you should look into the JavaScript "eval()" method, which will take a string returned from the server and run it as JavaScript.  Just make sure you don't include the <script> tags in your response if you really are returning JavaScript and are parsing it as such.

2) The response does not have to actually be HTML!  It's just a string to the browser, and you can do anything with it.  The most common use (which all of our products use) is to return JSON, or "JavaScript Object Notation", which can then be treated as objects that your script can handle however you want.  Let's say you just want to know if there was a success or failure: you could literally just return a "0" or "1" in your response and write something like:

if (response.getResponseText.equals("1"))

   alert("success!");
else
   alert("fail");

Obviously, this just barely scratches the surface on AJAX, and you can rest assured that you haven't heard the last of it.  AJAX is the cornerstone of pretty much all future Oracle portal technologies, and if you're a web developer who's not all that familiar with it, trust me:  you will be soon.

Howdy all. Welcome to part two of three of what was originally conceived as a one part series. It's entirely possible that I'll get all George Lucas on you years from now and produce some more of these posts that are a complete letdown and affront to your childhood memories, but I digress. For now, rest assured that this post will knock your socks off as a follow-up to my last tidbit on decompiling Java code.

Without further ado, I give you...Stack Wars II: The Stacktrace Strikes Back (I'm completely aware that I'm abusing the metaphor here, but isn't that really what blogging is all about?).

Standard disclaimer: This post is intended for a technical audience with a focus on production support. Also, everything here is Java focused, but you can certainly apply some of the concepts in a .NET environment as well...you'll just have to create your own screencaps to replace the examples I've included below.

So, what is a stack trace, and why should you care? Well, one question at a time please.

What is a stack trace?

Wikipedia says a Stack Trace is, "A report of the active stack frames instantiated by the execution of a program." Now, I vaguely understand the Wikipedia definition, but I have also have a computer science degree from a second tier state university, so let me try to translate for those of you who were smart enough to get degrees in something besides CompSci: a Stacktrace is a snapshot of a program's behavior at a point in time. In the Java world, a stack trace will tell you which method was being executed at the time the trace was generated, along with its complete call stack, and usually line numbers as well. Take a look at the following simple stack trace below as an example:

Why should you care?

Good question. I'd venture a guess and say that about 99.99% of the world doesn't need to know nor care about stack traces. But here you are reading this post none-the-less, so here's why they're important:

1) Good programmers almost always print stack traces out in log files when an error in a program occurs. This gives us a useful tool to track down bugs. Whether you're just reporting information to a support team somewhere, or getting a little sassy and trying to fix a problem yourself, the stack trace is like a map for finding treasure buried deep in code. Except that instead of finding actual treasure, you're just finding a logic error. And instead of getting rich, you just get to complain about a problem, and maybe fix it.

2) You can tell the JVM to generate a stack trace for a running process. Doing so allows us to take a snapshot of the JVM at an arbitrary point in time, and see what all its threads are up to. This is useful when trying to figure out why a process (Tomcat for instance) is zombied (i.e. it's running, but not responding to requests), or when you're trying to fix deadlock issues, which are particularly difficult to run down.

Hit the jump for learning more about reading and interpreting stack traces!

As you may have noticed (or not noticed, if your read this site from your aggregator), my blog has undergone some much needed renovation. I realize that as a blog reader myself, I appreciate a dearth of "State of the Union" posts in the blogs I read. Nonetheless, there have been quite a few changes, so here's an infrequent update...

• I use Movable Type to publish, and despite its complexity, I love the customizability and performance. I found a great style from the CMR Movable Type Styles Blog, and have customized it to my liking. Finally, no more blah "Minimalist Red" scheme.
• Dev2Dev is finally gone for good, which means some of my blog images were 404'ing. Thank you helpful readers for pointing this out. I finally went back and reset them to point to my own blog.
• Bill Benac recommended we Plumtree bloggers start linking to each other, so you'll notice a blogroll on the right side of the page. If you're blogging and you want to be listed here, give me a shout.
• The blog slogan has now officially become "Tech + Caffeine = blog", since I'm tired of dealing with these product name changes. As are other people, apparently.
• That Jeep in the picture is mine, featured in some mind-blowingly isolated terrain right outside the Badlands.

So what's in store for the future? Well, I still have some posts to write in my Search Series, I have a long backlog of posts regarding various technical minutiae, and then there is your input... Thoughts?