A few days ago, Sean Cassidy of Praesidio released an application called LostPass that exploits phishing vulnerabilities in the LastPass password manager.

See here: https://www.seancassidy.me/lostpass.html.

Do not use a password manager to store anything important. You can do better than that.

This recent report of a TrendMicro vulnerability is very serious, but it made me laugh as I imagined the recipients of Tavis’ pithy wisdom scrambling to react.

The time-worn phrase “There must be a bug in the compiler” is usually a red flag.  When I hear this I hear “There’s something wrong with my code, and I’m either too lazy or too inexperienced to figure out what it is.”

An ex-colleague of mine a few years ago approached every problem by reinstalling his software. His compiler, his IDE, maybe even Windows 7. Needless to say, it hardly ever fixed his bug, but that didn’t seem to curb his enthusiasm.

Once he got lucky and a SQL Server reinstall solved all his configuration issues. That was a happy day for him.

What reminded me of him today was this article on recent Intel CPU bugs. He’ll love that, I must send it on to him. I can hear him now: “There’s a bug in my CPU. I need a new laptop.”

But he’s not the only one affected. The increasingly serious implications of CPU bugs are summed up by this line ‘…“unpredictable system behavior” has moved from being an annoying class of bugs that forces you to restart your computation to an attack vector that lets anyone with an AWS account attack your cloud-hosted services…’

I recently came across this article by Dennis Stevenson on why technical debt isn’t necessarily a bad thing, which struck a chord with me.

Personally, I’m all about the refactoring.

One startup I worked with around 2000 had a market-leading product. It was fun, different, simple to use and facilitated a unified approach to employee help in the corporate environment. The company had a dynamic sales force selling the product in the US. They had a foot in the door of some of the very big players.

The code was kind of kludgy though. It didn’t work quite right here; there was an issue or two there. The lead developer, who reputedly was a genius (he was gone by the time I got there) decreed that everything should be torn down and rewritten.

Better.

This was duly done, by him. Commercial databases weren’t fast enough apparently, so he wrote a proprietary flat-file DB system that rendered the entire contents of the DB inaccessible except through his code. (In fairness to the man, this was around 2000 and SQL Server was only on version 1, or 2, or maybe 5 or 6 or something, and MySLQ was only a tiny baby, but Oracle was out there. And there was Sybase…)

As regards the GUI and business layer, he used his comprehensive knowledge of C++ to create an incomprehensible structure of classes and templates, bristling with design patterns added in the name of extensibility. A pattern in the right context is a thing of beauty. But…patterns piled in together to deal with imaginary future needs create unnecessary problems for everyone who’s not the program author.

Anyway. That was all lovely. At the end of a year or so Version 2 was unveiled.

It was a joy to behold.

Um.

There were a few new bugs that hadn’t been there before. There were a couple of Version 1 features that hadn’t made it in yet. And no actual new features, as such (unless you count the shiny, proprietary, and infinitely corruptible flat-file database, and the design-patterny code in the background).

But no worries, because it was so much more extendable now. And blazingly fast because of the DB (actually, it wasn’t blazingly fast but there was probably some non-DB-related reason for that).

Then he left.

I was one of the army of software consultants hired to fix the bugs, provide out-of-application access to the DB and maybe add a feature or two.

There were a few UML diagrams of the new DB structure, but (as always happens in my experience) every detail you might actually need to know when accessing it was undocumented. These had to be figured out the hard way. There were so many unnecessary bells and whistles in the business layer, added for future extendibility, that it was extremely difficult to figure out how to add any features.

Coincidentally, the Agile Manifesto was launched around then. Too late, alas, for us.

The writing was on the wall. Customers were sick of waiting for absolutely essential features. To give one example, you couldn’t select multiple files in the GUI. If you wanted to move a few files from one project to another you had to drag them one by one. And the most enthusiastic customers had hundreds of files in their projects.

Soon the company could no longer afford its new developer army.

Soon afterwards, it went bust.

(Some years later, I got a job creating a system to stream real-time stock-market data. One of the things I was told on my first day was that conventional DBMSs weren’t fast enough… I’ll tell you my antennae sprang up damn fast. It was true in that context though.)

So, what would have happened if the Big Rewrite hadn’t?

Well, I wasn’t familiar with Version 1, but here’s what I think:

– Developers would have refactored where they could, as they went along

– Someone would maybe have spent a month or two figuring out how to speed things up WITHOUT a proprietary DB system

– New features would have been added a year earlier. And then more new features, and then more…

– The users would have been happy, and would have pushed for the software to be retained by their employers

– The company would have had some small chance of riding the .dot con storm that was on the horizon

So yes. Version 1 was littered with Technical Debt, but Technical Debt, as Stevenson says, can be a good thing. It means you’ve been around long enough to evolve past Version 1, and you’re still here. Keep your Sensible hat on, bank that debt, and get yourself a copy of Michael Feathers’ ‘Working Effectively with Legacy Code’.

When I started in one role, I found that there was no source control or issue tracking system in place for my very small team.

No source control was something I hadn’t seen since 1997. I absolutely could not write code without source control. I had Git set up after a couple of days.

Then I turned my attention to issue tracking. My constraints were as follows:

1) No management support

2) No budget.

When considering a choice of issue logging system I had the following criteria in mind:

1) Free (that ruled out Jira and TFS, the two systems I’d used most recently)

2) Source code integration

3) Windows OS

4) Can create tickets

5) Can see history

6) Can view reports

7) Easy to install (there was no time allocated for me to do this)

8) Easy to use (or I wouldn’t get buy-in from my new colleagues)

9) Easy to extract data if upgrading to e.g. Jira later

I hunted around and made up a list of potential candidates. I quickly ruled out the following, which at a glance had looked promising:

BugLogHQ – provides a unified view of error messages sent from applications and servers – not what I wanted.

LogDigger – is to monitor your Java app health

Bugify – not free

More research yielded the following table:

By this stage I was starting to abandon my scientific approach. There was something attractive about Trac. Intending to check out more details of the other systems later, I started fiddling around with the Bitnami Trac install. Surprisingly quickly it was up and running on my machine. IJW. I like it.

Although I explained to my new team what it was and what it was for, Trac was regarded with suspicion at best. The first few defects were all logged by me. There’s no way to force adoption of these things. (At least, there’s no way to force it if you’re a software consultant who’s only just arrived in the office.) Progress was slow, but the interface is clean and quick and easy to use, so I had high hopes.

Then the work started to happen.

By the end of the first year. over 900 issues had been logged and processed via Trac. It never gave us any issues. After a few months I transferred it off my PC to a vm, easily and quickly with no loss of existing data.

It’s highly extendable but everything we needed was there out of the box. I only added one plugin, to change the workflow to allow for a ‘testing’ status.

The source code integration is simple, gives you lots of unexpectedly useful tools including colour-coded revision logs, and provided a great sanity check for the status of our central Git repository.

I highly recommend it.

I had to do this recently, and Googling wasn’t much help. So in case any of you are in the same boat…

Do a search and replace (Ctrl+h).

In the ‘Find what’ box, leave the text blank. Click the ‘format’ button and choose ‘font’. Select the particular font, font-size, bold etc combination used for the heading you want to convert to a style.

In the ‘Replace with’ box, also leave the text blank. Click the ‘format’ button and choose ‘Style’. Click ‘Replace all’.

All your selected text should now be set to the relevant style.

You may find that the style isn’t properly applied. For example, the colour may have changed but the font and font size may have stuck.

To correct this, open the Styles pane. Right-click the desired style and choose the ‘Select all x instances’. Then left-click the style. All your newly-converted text will fully update to the desired style.

Shipping was charged twice for my product by the WP e-commerce plugin when shipping was set to ‘flat rate’.
I googled it and found that this problem has been recorded, but with no solution posted and the discussion closed.
Turns out it’s not a bug, it’s just a configuration issue. I incorrectly entered a base shipping charge as well as a product-specific shipping charge.
The solution is to set all charges to zero in the Settings – Store – Shipping – Shipping Modules – Flat Rate – Settings screen.
Set the shipping charges you want in the product-specific screen.
Then, of course, test thoroughly to ensure you have the charges you expect.

In VS2008, I set up a SQLDataSource and bound it to a GridView. The Gridview row had five editable fields and several read-only fields. I set up the SQLDataSource to use a stored procedure for database updates. I had some trouble binding the fields to the stored procedure, checking data types etc but eventually that was all resolved and the sp stopped returning errors such as ‘Too many parameters’.

All seemed to be going well, but the sp was not actually updating my record.

The problem was (ahem) that the sp was a shell I’d thrown together earlier and didn’t actually have an update statement yet…

Once that was fixed I assumed my troubles were over, but no, still no update visible in Management Studio.

I only used this sodding data binding because it’s suppose to save trouble, I thought, should’ve hand-coded the blooming thing like in the old days.

However, I fired up SQL Server Profiler. Things rapidly improved. I realised that my sp was indeed being called, but all my read-only values except one were being passed in as NULL. (Earlier, I had resorted to passing in all my grid columns to the sp to get around the ‘too many parameters’ problem. The unneeded ones were simply ignored).

Hmm.

After some more poking I discovered that the lucky field that was being passed correctly had been set as the DataKeyName on my GridView.

I changed the DataKey name on my GridView to the two fields that I actually needed for my sp’s where clause, and bingo!

It worked.

I think the DataKey may have been set automatically. The select might have picked up the issue, except I was using an sp for that too, with parameters read from textboxes.

I know, I know, RTFM.

In VS2008, I created a new file but it had no code-behind. Chose ‘File – New File – Web Form’. Several times. Tried loads of stuff. No code-behind – the aspx top line was: <%@ Page Language=”VB” %>.

I was thrown because I haven’t used VS2008 for ages. I’d only just installed it and a trawl of Google threw up all kinds of suggestion such as a VS reinstall.

Which wasn’t needed. It turns out you have to add the file via the Solution Explorer to get the code-behind. As in, right-click on the project and choose ‘Add – New Item’.

I stumbled across this while experimenting. Having no code-behind in files added from the File menu is probably a ‘feature’, and so well-known that no-one has bothered documenting it anywhere. Which is why I’ve mentioned it here – hope this helps someone.