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…

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…

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…

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…

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,…

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…

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…