A quick way to scan a bunch of WordPress installs for the Docs virus. Not sure of the real name since I can't find a reference to it on the net.

dir /s /b *.php | find "docs.php"

A more thorough search is:

findstr /sim /c:"chr(base_convert(substr" *.php

This looks for the actual code that decodes the virus.

Either method could produce some false positives so apply some comment sense before deleting files.

Removing

Removing the virus consists of checking the first line in the function.php file for each theme and removing the junk after <?php

Then delete the Docs plugin.

You will need to do this with your site disabled as the plugin will reinfect the functions.php files and the functions.php extras will reinstall the plugin.

Analysis

I haven't spent too much time trying to figure out what it does exactly. However, this is what I do know.

The code added to the theme functions.php

First it checks to see if the wp-content/plugins/docs/docs.php file exists and if not it downloads a copy from http://lamulata.biz/cript_doc.php

Next if the docs.php file exists it checks to see if it is activated. If not it activates it.

docs.php

Registers a daily cron job which is used to update itself.

Uses the docs_wp_plugin_active_list_update action to hide itsoft from the plugin list.

Hooks the wp_head action which seems to send some data about the current request to http://178.132.204.58/index.php

Ultimately it seems to fetch some content from a remote site and includes it in the page content or completely replaces the content.

One of the side effects is that it looks for a writeable tmp directory and caches data there. I found over 25,000 files in one cache folder.

Once I found the actual file that was the issue I developed a better command to detect any other infections:

findstr /sim /c:"'](NULL)" *.php

Read More

Abstract

In this study, the authors used 111 time series to examine the accuracy of various forecasting methods, particularly time-series methods. The study shows, at least for time series, why some methods achieve greater accuracy than others for different types of data. The authors offer some explanation of the seemingly conflicting conclusions of past empirical research on the accuracy of forecasting. One novel contribution of the paper is the development of regression equations expressing accuracy as a function of factors such as randomness, seasonality, trend-cycle and the number of data points describing the series. Surprisingly, the study shows that for these 111 series simpler methods perform well in comparison to the more complex and statistically sophisticated ARMA models.

Accuracy of Forecasting: An Empirical Investigation, Spyros Makridakis, Michele Hibon and Claus Moser, Journal of the Royal Statistical Society. Series A (General), Vol. 142, No. 2 (1979), pp. 97-145.

Here is the bike with the tire removed. No big surprises here except the shop manual doesn't say what size the axle nut is (30mm) and I had to go buy one.

Here you can see the end results next to the old tire - definitely time for a change.

Total time to change the tire was about 3 hours. Mostly because I was being careful and it was about 98F. I expect next time it should take me about an hour. The Dyna Beads seem to work great.

My early metrics book, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982), played a role in the way many budding software engineers quantified work and planned their projects. In my reflective mood, I’m wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no.

-- http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf

If that doesn't rock you back on your heels, then you need to re-read that paragraph.

Next you need to go read the whole article (2 pages).

As someone who prefers the agile approach I have been pushing the value based approach over the control based one for nearly a decade now. But to see someone like Tom question publicly what he (and we) have been doing for the last 30 years makes me respect Tom even more, and give me hope that as an industry we are heading in the right direction.

Jack was of the opinion that:

the more one spends time tracking metrics, the less time there is for development

While I have some sympathy for this point of view having worked for larger organizations in the past, I have come to realize that you do need some type of metric that is understandable to the rest of the organization. All the other departments in your organization have an overriding single number that describes how they are doing, why not software development?

As I mentioned in my No More Iterations post, throughput is my metric of choice. The cost of collecting this metric is so low that it doesn't matter.

Now I have been asked to provide all sorts of low level metrics in the past not knowing how they were going to be used. I was not inclined to cooperate in those cases since the time required to collect them was never going to be offset by any value coming back to my teams. And this is most likely what Jack is protesting.

I like being proactive and providing a metric I think is useful, rather than waiting for someone who doesn't really understand software development ask me to have my teams track actual effort against estimated effort in units of 0.1 hours (really I have been asked to provide this!).

You can find my presentation here.

I also wanted to provide some links to some of the books and sites I referred to during the talk.

• Software by Numbers: Low-Risk, High-Return Development

• Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (Coad Series)
• Lean Software Development: An Agile Toolkit (Agile Software Development Series)

This year's class was great. Lots of good question and a nice level of engagement. You could tell several of them were really thinking about how Scrum is so different than a waterfall style approach.

As promised here are the slides I used.

There were a few requests to post my "slides" which I have done. Be sure to check out Prezi, the company who is making this cool presentation tool.

I also wanted to provide some links to some of the books and sites I referred to during the talk.

• Book: Software by Numbers: Low-Risk, High-Return Development

• Book: Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (Coad Series)

• Book: Lean Software Development: An Agile Toolkit (Agile Software Development Series)

• Site: The Agile Manifesto
• Site: Real Options (podcast)
• Tool: Trichord

Update 3/28 - I forgot to give credit to Karl Scotland for a couple of the diagrams - Sorry Karl!

Things have been slow for a year. Next year isn't looking any better. Not that this is a unique experience. The company is generally fine, but with everything on a downward trend we want to stay healthy financially.

My budget is about 98% people. The other 2% was examined closely last year, and while I was able to take out another couple of tenths, it just wasn't going to cut it.

My team doesn't have performance issues to speak of, so there is no easy out.

I've made my decision and acted on it. A challenging part of my job, but maybe the least enjoyable.

For those of you in my position how do you choose what to do?

Now enter Sybase SQL Anywhere. Aka Sybase ASA or iAnywhere.

First off there are 2 different JDBC drivers. JConnect (jconn3) and the iAnywhere JDBC driver (jodbc). It turns out that only the iAnwhere driver actually works with the high availability option (although not documented).

Also it turns out that the iAnywhere driver is really an ODBC bridge and you have to specify another driver in the JDBC URL.

While a little confusing at first due to the lack of documentation eventually you can dig up an example.

jdbc:ianywhere:driver=SQL Anywhere 10;dbn=mydatabase;eng=myserver;

Everything works and you move on with life.

Except that eventually you want to deploy your new code to the server. BAM nothing works. All sorts of errors about no suitable driver found.

After thrashing around for a few days you discover that the JDBC URL must be different on Linux! (this is the only page on the Internet that specifies this).

jdbc:ianywhere:driver=libdbodbc10.so;dbn=mydatabase;eng=myserver;

Of course your application now works on Linux, but not on Windows.

Now if I were writing my own code that needed to talk to the database there wouldn't be much problem as I can use one of several techniques for figuring out which driver I should be using.

However, this URL used to configure some enterprise reporting tool which uses that same URL whether doing local report development or running from the server.

So now I have 3 options.

1. Install the reporting server on every developers workstation.
2. Stand up a Windows version of the reporting server.
3. Create ODBC DSNs on all affected systems.

While option #1 is enticing (I like developers to have a local copy of all dependencies if at all feasible). Feasibility plays into the picture here because of license costs.

Option #2 is certainly doable, but I am not a big fan of adding the overhead of administering another server and keeping it in sync with all the others.

Options #3 is simple and works well. However, DSNs represent another thing that needs to be set up on every developer and qa system. This also breaks my rule of being able to check out the source tree and go, even on a new computer (for reasons of continuous integration and easy new team member set up).

Ultimately we will go with #3 because it is low cost in dollars, and low cost in time (we'll write an Ant target to do the DSN setup).

Now wasn't that easy? It only took 3 days to work through in real time.

Agile Open NW 2009 has been scheduled for Feb 10-11, 2009 at the Ambridge Event Center in Portland, OR.

I'll be there again. If you are anywhere near Portland and have an interest in all things agile, this is a can't miss opportunity.

Agile Open Northwest, an alliance of agile practitioners in the US Pacific Northwest region, presents Agile Open Northwest 2009.

We invite you to our third annual conference. Our first conference in Portland brought together members of the Northwest Agile communities. We held our second annual event, Agile Open Northwest 2008, last year in Seattle and enjoyed another great success.

Please join us this year as we host 100 experienced, collaborative, committed agile practitioners from the Northwest U.S. (and beyond) in tackling the issues around our theme "Agile for Real."

Your commitment to arriving at the beginning and staying until the end both days will ensure we build on conversation after conversation as we engage important questions like:

• What is agile really?
• What does agile development look like in the real world?
• Who practices agile philosophies, methods, principles or practices in the Northwest, and what's the impact?
• What does agile or agility look like in organizations?
• What new technical challenges face agile?
• How does agile co-exist with project management, process control and other governance structures?
• How do we adapt agile practices to our organizations without diluting them?
• Can agile methods work in big, risky projects? How?
• When distributed teams use agile approaches, what changes?

When an organization chooses a transition to agile, what really changes?

The Northwest has a wealth of practitioners with years of real-world experience with agile methods and self-organizing teams. Agile Open Northwest offers an opportunity to strengthen our community of practice and co-create the future for agile development in our region. Feel free to browse the list of currently registered participants.

Your hosts designed this event to allow practitioners like you to meet in self-organizing groups where we can share our latest ideas, challenges, hopes, experiences and experiments. We follow an Open Space format to foster collaboration and allow the conference to take its direction from the participants themselves.

• What: An Open Space event discussing agile practices and techniques.
• Where: Ambridge Event Center, *new* location near the Convention Center and Max line, 1333 NE MLK Blvd., Portland Oregon
• When: February 10 and 11, 2009
• Who: Anyone with some degree of experience in agile methods.
• Cost: $125 per person, including lunch both days

A comment from a previous attendee:

"These two-day Agile Open Northwest conferences are an extremely good value. ..[Y]ou learn directly from practitioners in the agile community what works and what doesn't. I attended the first two of these conferences, they were stunningly good... loads of practical, useful stuff and stimulating discussions." -- Ian Savage, PNSQC Program Chair

I'll be covering a different project management approach to product line development that includes:

• Reduced meetings
• Clear priorities
• Minimal multitasking
• No estimating

After riding the other bikes this summer there was just something missing from the KLX 250. Primarily my wife. We were both missing the enjoyment of heading out for an hour or two on the weekends or a warm evening riding tandem. We know this might be an issue we we purchased the KLX, but figured we'd save up some money and deal with it next summer.

Fast forward to the present. I'm hanging around the dealership waiting for the service department to put some new tires on the KLX. The showroom is completely dead and I didn't bring anything to occupy my time, so I'm wandering around admiring the bikes. One of the salesmen strikes up a conversation as they are likely to do. Eventually he gets around to asking me what kind of bike I'd be interested in if I was really looking.

I'm honest with him. I say I'd be interested in something for riding 2 up. I've been here a few times and know they don't really have much in that category, but I've got time to kill and salesmen always have a bunch of good stories. He takes me through their limited inventory - a FJR, and a Concours. Both are nice bikes, but I'm not really into buying new off the showroom floor.

He detects my lack of real interest and asks what I'd really want. I say I'd be really interested in a Ducati ST4, knowing that the local Ducati dealer has this market pretty wrapped up. To my amazement he says hesitantly I think we have one of those.

I'm stunned for a moment. Then I come back to my senses. Most Ducatis are sports bikes, not touring bikes, it is extremely doubtful they really have what I'm looking for. Nevertheless I follow him outside where some of the used bikes are on display.

We walk down the line of bikes and by this time I'm not expecting much, but then I see it. A 2001 Ducati ST2 in yellow! Now ideally I would love to have on in Ducati red, but at this point I don't really care to much. It has only 5,500 miles and the price is reasonable, but not amazing. I hem and haw. He asks me how much I'd be willing to pay. I tell him a ridiculously low number. At this point he reveals that it is a consignment bike and if I want we can write up an offed. What the heck, I've got time to spare and worse case I go home with nothing.

While we're writing up the offer my wife shows up (she was going to take the old, but still serviceable KLX tires home). I give her the tour and the salesguy finds the key so we can listen to it. It sounds fantastic with the Fast By Ferracci carbon fiber pipes on it. She is excited, I'm excited. We talk, we decide how much we'd really be willing to pay. The salesman comes back with a counter offer and is willing give up the consignment fees.

We now own a nice yellow 2001 Ducati ST2.

The next weekend wasn't so nice but a few of us went for a ride anyways. We got wet, but had fun just the same.

Interestingly each one of us owns a different kind a bike, a standard, a cruiser, a dual sport and a sports bike.