I have a funny habit with our code in the front end, where if something’s just too complicated, but i cant see the better solution yet, I’ll give its pieces long descriptive names. It’s basically so they’ll stick out later, we’ll think ‘why is this thing so ugly and complicated’, and it’ll help us remember to revisit it. (btw, I’m not claiming that this is good development practice, it’s just a trick i use, faintly reminiscent of the blue-wire red-wire stuff in the Mythical Man Month).

So anyway, I bring it up cause Johnvey saw one of it’s cousins out in the wild, taking the whole concept to an extreme. Check it out.

Arguably though, this is so extreme that it’s not reallyDescriptiveNames at all, but closer kin to a sort of passiveAggressiveWorkplaceSabotageAdapter.

There’s lots of subtle things that are required for good user experience. Simplicity, speed, comprehensibility, consistency. These are the core value of any software, and there’s a spectrum on which they’re at the other end from ‘Features’.

Features are cool. They make you sound smart. Whether you’re a customer talking to a sales guy, or an engineer fleshing out an idea you had. New stuff tends to show up in sentences as the word ‘feature’. It’s exciting. Sure it has a certain cost in speed or something. It tends to not color entirely within the lines. But that’s OK. It’s new, therefore it’s cool.

Jumping forward many years though, everything at some point was new, and gets old and those costs start to suck. After a while these intangibles have pretty much been sacrificed away and you’re in large-company hell, sitting in endless meetings trying to figure out how and when everything got all bloated and slow.

So, we’re trying to swim against this current as we scale (no kidding). We’re trying to prioritize speed and simplicity. We’re trying to keep talking to users in the trenches. We’re fighting off checkbox-itis, we’re trying to have new corner-case features built in offshoot, quasi-standalone manners, we’re trying to use the extensible architectures we have, and create more of them when needed.

In short, we’re trying to keep that thing about Splunk that is cool. That you can get going quickly, you can set it up quickly, you can change directions quickly. It’s yours to drive. When you want to do something with Splunk for the first time, it generally makes sense and doesnt take very long.

So enter YOU! We sometimes suck at all this, and could use your help to suck less. And if you the user want to talk to

Im a pretty nostalgic guy, so hanging out with me there’s a lot of ‘back in the day’, ‘onion on my belt’ kind of stuff. You have been warned.

So my history at splunk — I started here in March ‘05. First UI Developer, inheriting the front end built by our notorious founder Erik Swan. They brought me in as a dHTML guru and gave me free reign (crossed fingers notwithstanding). But for better or for worse Splunk has always been pretty different on the client-side. Even the alphas and private betas all were all client-side XSLT and had that holy crap moment where you wonder why the hell everything is clickable and lighting up on mouseover.

Then during the sprint to 3.0 we ran off in even crazier directions, and did all the things we’d talked about doing, but held back from (eg endless pager, free form charting in Flash, rethinking the timeline interactions, replacing the tabs with more compact layers).

From this point forward though, there will be more building out and less building up if that makes sense. ie no more monolithic single all powerful UI, but rather links between quasi-standalone bits. And on the monolith instead of bolting on new features Instead we’ll be solidifying things, cleaning, improving, fixing.

That said, there will still be a lot of unusual and useful interactivity. Actually probably more so overall if the monolith-maintenance burden falls as expected.

So interesting times here at Splunk. More news as it comes.

And oh, we are hiring. We are extremely hiring. If you are interested, or you know someone who’s interested, or a friend of yours is really smart and you think he needs a new job… Send them our way.

iIf you only ever care about the last few hours or the last day of your data, this simple change will speed up your search results tremendously. Until our next big release which will basically be this way by default, here’s how you can do this in 2.1 code.

This is a change in three places, but fortunately very fast to make, and all in the same file.
$SPLUNK_HOME/share/splunk/search/dynamic/main_ui.html

Note: The example here will set your UI to search only the past 6 hours by default. After doing this it should be easy to see how to change it to search 1 day, or 45 minutes etc…

Note: Also you dont need to restart the front end to see these changes, but you DO have to refresh your browser by clicking the refresh button up top.

step 1) around line 70, change
<div class=”#productVersion#Version landingPageState #userType#User noTimeFields eventsTab relativeTimeMode #dynamicallySetStates#” id=”outerWrapper” />

to
<div class=”#productVersion#Version landingPageState #userType#User eventsTab relativeTimeMode #dynamicallySetStates#” id=”outerWrapper” />
(basically this removes the ‘noTimeFields’ state so the time controls are now open by default)

step 2) around line 122 of the same file, change
<input type=”text” id=”relStartTime” />

to
<input type=”text” value=”6″ id=”relStartTime” />

(now the UI will load with “6″ already entered into the relative start field)

step 3) around line 125, still in the same file, change
<option value=”hours”>Hours ago</option>

to
<option value=”hours” selected=”selected”>Hours ago</option>

(this means that hours will be selected by default. instead of minutes

That’s it. You’re done. Refresh your browser and the UI will now restrict it’s searches to the most recent 6 hours by default. If you really only ever care about the last 2 hours, switching it to 2 hrs may speed you up even more.

This is a quick update to Mark’s post from 10/9/2006

Again, to reiterate Mark’s qualifier - this is all assuming you understand that by doing this, you send users and passwords in clear text and the risks involved.

So, uncommenting the 2 lines as described in Mark’s post will only get you the first part, ie the ability to send a GET request that logs you in. We’ve had people ask if that request can go further and also return results right away for a particular search they also pass in. Obvious request but somehow we didnt anticipate it.

So until we wrap this feature up in a bow in a release, once again this involves editing python by hand. And this time it’s more than just uncommenting two lines. It’s cut and paste, and if you know python you know that tab-indentation is meaningful, and this seemingly simple action can be deadly. You have been warned. Back up the file and proceed carefully.

Alrighty, still with us? =) Find the 2 lines that Mark blogs about uncommenting. (this will be XMLResource.py, line 395 - 400 ish depending on which 2.1 release this is)

Now replace those two lines with these lines below. NOTE: REPLACE HYPHENS WITH SPACES. wordpress seems to insist on removing leading spaces.

--------if ("usr" in request.args) and ("pwd" in request.args) :
------------logger.info("user is attempting login on GET")
------------if ("q" in request.args) :
----------------logger.info("user attempting login on GET is requesting redirection to a permalink")
----------------sessNS = request.getSession().sessionNamespaces
----------------sessNS["postLoginRedirect"] = "/?q=" + request.args["q"][0]
------------return self.render_POST(request)

now restart the python front end using splunk restartss (a full splunk restart is not necessary)
And now you’ll have the ability to embed URL’s like this in the webapp of your choice

http://your.host/login?usr=username&pwd=password&q=interestingTerm1%20interestingTerm2

UPDATE——

as pointed out in the first comment (thanks!!) the above snippet will happily fall into a recursive loop if

Everybody wants this, and until the day when it’s built into the UI somewhere, you can use this little bookmarklet to do it in about a minute.

So. the link below is your friend. (If you’ve used bookmarklets before you know what to do. Otherwise, read on. )

Instead of clicking this link though, right-click it or option click it, and choose ‘bookmark this link’.
splunk 30 second refresh

Once you’ve done that, then whenever you have Splunk loaded, clicking that bookmark will run the tiny little script, and the upshot is that the UI will start autorefreshing in 30 seconds and every 30 seconds thereafter.

And if you want to change the 30 seconds, edit the bookmark, find the 30000 and change it to whatever.

Full speed ahead for the next big round of improvements and fixes and we’re all going cheerfully bonkers. I was especially cheerful/bonkers today because I spent the morning prototyping some SVG stuff. In particular, since the splunk ui runs almost entirely on xml and client-side xslt, I was looking into how feasible/fast/stable it would be for our client-side XSL to just generate SVG directly, and for javascript to clone those svg nodes into a big complex DOM.

The answer is - omg it works well. Fast, seemingly stable, it can be pushed. Even in a big javascript front end like ours, the event handlers on svg elements pass right up into our existing framework. Some small tweaks had to be made to accomodate it, but no showstoppers. And it is rare for such a complicated thing to present so few obstacles in practice.
So thanks to Mozilla for being generally awesome, and particularly for turning on SVG in their release builds . Of course i have absolutely no idea if any svg will ever appear in the product … We do after all have a great deal of other more mundane improvements in the works. =)

Also, my apologies for not talking about skins. I had wanted to post a big treatise on skins, but since I’m rewriting and reworking all the css right now, it would be way too cruel; any skins you made would die with the upgrade to 1.3. So Im saving the post for another day.

Until then, for the indomitably curious, suffice it to say that the ‘invert’ link hidden in the footer actually cycles through the skin list, and the fact that there are currently only two skins shipping in the product does not prevent you the user from hacking the front end and making a third, fourth

First post, so i’ll begin at the beginning.

Im the front-end guy. From the xsl,js,html and css on the client side, up to the python in splunkSearch, I am responsible (read: to blame) for the current implementation, and also for much of the interaction design. I’ve worked here just over a year now, and I have no noticeable scars or weird tics to show for it, so I guess I’ve got that going for me.

What possessed me to come work here: Essentially all of my experience before splunk was at services companies, and for the prior 3 or 4 years specifically I had become this sort of high-throughput template builder and dhtml-specialist. Boring stuff I know, but I mention it because I came to splunk partly to get away from this. You can build lots of really complex front ends while at services companies. You can do build for flexibility and simplicity all you want, but when the project is over you never really see the code again (or worse the code never gets updated or changed by anyone and so it never evolves at all). So outside of maybe some escalated issues, you never really know what were the good parts of the implementation and what were the bad. And the development pain induced by changing requirements, the codebase evolution and accidental devolution, the day to day suffering really, you get spared from all that and that sucks.

So here at splunk I get all that too. I’m not just some head-in-the-clouds master-template builder, I’m actually the poor slob responsible for maintaining it too. =)

One nice silver lining is that sometimes I’ll get rewarded with these little gems of code that have been going on a journey towards the nonsensical. Where say, at one point it did something simple and made